August 27, 2017

Google Summer of Code: Wrapping Up

Photograph of the app I developed running on a smartphone, with the bluetooth beacons it uses around it

Today marks the end of the coding period of Google Summer of Code 2017. As part of this program, I have worked with the Physical Web team to design and build a Content Management System for museums & galleries utilizing Physical Web and Web Bluetooth technologies.

The idea is that an employee of a museum, gallery or other space installs the app and then in-app: enrolls the beacons and creates an exhibit. This allows them to associate multimedia content with each beacon, the sum of which is displayed when to visitors on their smartphones when in proximity to a beacon. If they have the client app installed, it will even show them the content specifically for nearest beacon as they walk around the space.

My work has been centered around 3 Github repositories I created for this project:

  1. Android app to set up exhibits and configure beacons
  2. Python program to fetch exhibit contents and process them into HTML pages
  3. Android app to display beacon content to visitors, updating as they move around

All code in these repositories, with the exception of the code in util package in the first repo, was developed as part of my Google Summer of Code 2017 project.

A timeline of the development process can be found here.

Highlights

Of the original goals set out in the proposal, we have been able to fulfill all the outcomes, including one out of the two stretch goals.

I enjoyed learning about new technologies over the course of the project: I was introduced to ORM frameworks and used one for the first time, instead of writing plain SQL queries. Bluetooth Low Energy is surpringly capable, more than I had expected.

This project is the most ambitious, most complex I’ve attempted in my career. The project utilizes Java, Python, and HTML/CSS/Javascript and comes in at just over 15,000 lines of code and markup; I am quite satisfied with how well all these components function togather to work as an end-to-end solution.

Challenges

Working with hardware devices was a unique challenge I had not experienced before. Sometimes the Bluetooth connection is flaky, sometimes they run out of battery and often they are real-life black boxes. I managed to overcome these challenges, but they were not something I had to deal with in the past, working on purely-software projects.

Another challenge was syncing with Google Drive. As far as I could tell, the Google Drive API for Android only facilitates uploads and downloads of individual files - I had to write a recursive algorithim to sync folders, resolving conflicts on the way.

I also learned that writing tests is not always practical, as some functionality is hard to unit test - and integration tests end up being flakey, espicially as I was developing internet-enabled code on a poor network connection.

I also had to work around a number of bugs in Android. The diversity of hardware is a strength of the platform, but also a pitfall.

Future Efforts

Once the Web Bluetooth scanning API is implemented in major browsers, the Android app for visitors will no longer be required, as what it does could be replaced with a simple javascript file. So that would definitely be an avenue for improvement for the future.

Perhaps the programs could be extended to use storage backends other than Google Drive, for users who would prefer the content uploaded to say, an FTP server. This shouldn’t be too difficult as I’ve aimed to write reasonably decoupled code.

June 9, 2017

Google Summer of Code: the Application

I recently received news that my Google Summer of Code 2017 proposal has been accepted. So I thought I should write a series of posts as this summer passes to chronicle my experience with the program. This first post is an outline of the process I followed in creating a successful proposal; I hope future applicants - or those just curious - find these tips helpful.

My project this summer will be to develop a content management and presentation suite utilizing Physical Web technology. The novel concept behind the Physical Web project is to utilize web Bluetooth to allow interactions with inexpensive physical beacons from the browser - in other words, IOT without the hassle of apps. My task is to develop an Android app (and an accompanying web app) to enable exhibitors, museums and the like to organize galleries that use these beacons. Visitors will then receive a notification when they unlock their phones, which will lead them to the webapp that displays media relevant to the exhibit piece they are looking at. Find the official description here. You can find the final text of my proposal here.

Before we get any further, I would like to extend my thanks to Andreu Ibáñez and Julio Bondia (from the Physical Web team) for their thorough proposal feedback and their patience with my questions. None of this would have been possible without their help!

Checklist for Applicants

  • Choose selectively and early
    • This year, 201 organizations participated in GSoC. Starting out, the sheer number of possibilities is overwhelming — make sure you have enough time to browse through all the organizations that interest you and decide.
    • Google allows you to apply to up to 5 organizations. However, I strongly suggest that you apply to one, or at most two organizations. There are many applicants for GSoC, so the key to standing out to an organization is a high quality proposal. Five ordinary proposals are likely to get lost in noise. Personally, I only wrote one proposal.
  • Get feedback early and often
    • This step is not optional. It is my firm believe that it is almost impossible to get accepted in GSoC if you have not had at least one round of feedback. Feedback allows you to address issues before your proposal is more strictly reviewed.
    • Communicating with the community also helps you understand the expectations in term of work quality, application tone, etc.
    • I think a key reason my proposal was successful was the ~1000 words of feedback exchanged between me and the organization members over the course of a week or so.
  • Set concrete deliverables
    • Outline a set of measurable goals for your proposal, so that what you want accomplish is clear. For example: Using the Google Drive API, the Android app will allow the user to authorize their Google account so the app can upload content.”
    • It might be helpful to have two separate lists, one for technical/code deliverables and one for non-technical deliverables, like documentation or tutorials
  • Polish your proposal
    • Participating organizations and the Google team will spend time combing through your proposal. Show them that you respect their time by writing clearly and professionally.
    • You can test clarity by asking someone technically inclined to read your proposal and explain it back to you. Rewrite the parts they get wrong.
    • Have others proofread your proposal. Here you’ll want someone who’s good with English, technical understanding isn’t necessary. Many universities will have a writing center which can help you.
  • Highlight your experience - or create experience
    • Prove to the reviewing team that you can accomplish the deliverables you set out in step three.
    • Linking to open source code is the best way to do this. For example, in the deliverable above I mentioned using the Google Drive API. To prove I can do this, I linked to some toy Python code I wrote a while ago that used the Drive API.
    • Another good way to do this is find the issue tracker the organization uses and fix some small bugs listed there. Mention this in your application.
    • Some organizations will have a coding test. Mine did: here is the prompt, and you can find my solution here. Note how the code is both documented and has tests implemented.
  • Throw a penny in a wishing fountain
    • In the end of the day, getting selected involves some amount of luck. Work hard on the proposal and hope for the best!
April 28, 2017

Open letter to the Paul G. Allen School of Computer Science

Photograph of the atrium of the UW computer science building, during a high school outreach event

A few days ago, I was surprised when my friends taking University of Washington’s introductory programming course - CSE 142 - described an assignment they had this week. Called Admissions, the assignment exemplified some of the main problems the field suffers. I hope to explain why this assignment should be changed and why this small detail matters a lot.

Admissions is a homework task where the students write an algorithm that decides whether a student gets admitted to college or not. After the user enters an SAT score, an ACT score or a GPA for two students, the program plugs those numbers into a formula and spits out a message along the lines of the first applicant seems to be better.”

Having taken a similar introductory sequence at UW - one that didn’t have this assignment - the part I recall most vividly was the last lecture of the second course. Having covered all the material for that quarter, my instructor turned to us and said, at the end of the course, that his hope was to to have dispelled the notion that we are ostriches that bury our heads when we come across other fields.” This was accompanied by a video of soccer robots playing in the background.

The main problem with assignments like this one is that they promote writing algorithms without considering what effects they have from the perspective of other disciplines - exactly what I was warned against two quarters ago. Sadly, this is very common. For example, online advertisers are six times less likely to show advertisements for high-paying jobs to women than they are likely to show them to men. This is likely caused by some code written in Google AdSense to optimize for number of clicks, all other considerations be damned.

I think the greatest damage being done here is to the students who are taking the introductory sequence but are not pursuing a career in CS. They might come away with the impression that is it acceptable to deploy algorithms like this in the real world; without exposure to CS courses that cover why this might be problematic, they would probably discover this problem too late, if at all.

I understand that this assignment has been part of the homework rotation for many years, maybe even before problems like this where well known to the public. Nonetheless, I encourage you to modify or retire this assignment, if only to signal that narrow modes of thinking are no longer enough in our field.

Yours Truly,

Mohammad Kayali
Undergraduate Student, Class of 2020