Mozilla All Hands Meeting

Mozilla Web Compatibility group

Mozilla Web Compatibility group (All Hands Summer 2017). Photo by Dennis Schubert. CC by SA-2.0.

Summary

  • I enjoyed having a chance to meet everyone in person, especially those I only knew through their github handles when I was previously a contributor
  • I’m grateful to Mozilla for their generosity with having the interns attend
  • I’m grateful to the entire Web Compatibility group for being kind to me (and Bea, co-intern); in particular Mike T. was extremely generous with his time and planning for everyone to have mornings and evenings filled with interesting things to do
  • Additional thanks to everyone in the group for the generosity of their time and knowledge share (in particular Karl, Tom, and Guillaume)

Highlights

  • We had an interesting impromptu talk about running functional tests for webcompat.com (Bea clarified the use of running the server in test mode for required fixture files); quote of the week: “This is like space…”
  • Enjoyed listening to all of the engineering group presentations on the last day (especially the Software Architecture group which had clearly articulated slides)
  • Enjoyed Espresso ice cream at Ghiradelli Chocolate shop and jogging through Golden Gate Park (although I could not walk down stairs properly for the remainder of the week)

Group Appreciations

  • Adam: very down to earth and pleasant to chat with
  • Bea: very fun, understanding, and smart to boot
  • Dennis: wickedly funny and smart
  • Eric: pragmatic and interesting to chat with
  • Guillaume: a very nice sense of humor and patient with my questions
  • Karl: a good listener/reader (thank you), smart teacher, investigative reporter of code, and a strong work ethic
  • Mike: makes being a leader look easy, makes big things happen, patient with my D’OH coding moments (more details in a future blog)
  • Ola: humorous, intelligent, and productive; a bold thinker
  • Tom: balances a sense of humility, confidence, and intelligence in his communications; service-oriented in his work outlook

One general observation about the group is that everyone is highly technical but also quite verbally articulate. There is a very interesting balance of qualities…

Coding: The Good, The Bad, and The Ugly

Recently my mentor, taught me about how to conceptualize programming solutions at different levels. In my recent experience, I was used to developing fast hack solutions which I feel is not correct but given short deadlines, I felt little choice about. But instead of thinking about a problem as having only a hack solution or an ideal world solution, my mentor suggested considering the following:

  • The fast and hackey solution (AKA The Bad). Sometimes this is not a bad solution but some time should be taken to document why/how it was done and how it may be refactored when time permits.
  • The middle ground solution (AKA The Ugly… OK, it is more Middle than Ugly). This is often an ideal solution.
  • The ideal world solution (AKA The Good). This is like a “perfect” programming solution (if you had unlimited time and resources). Most likely this solution is going to going to have maximum flexibility for current and future use cases.

Recent Problem and Application

Recently I was working on a webcompat.com issue where there were some record types returned in github issue searches that should be filtered out. The solution that I came up with doesn’t exactly fit within the 3 categories described above (maybe it is somewhere between the hackey solution and the middle solution).

Since the data was coming from 2 Github API types, 2 approaches were needed:

  • For the Github search API, it is possible to intercept the user’s search query, append a custom string (negative label filter since the undesired data had a specific Github label attached) and send the resulting query with the Github API request
  • For the Github issues API, it is hypothetically possible to filter the Github API’s returned JSON results using a JavaScript function. This is not an ideal solution because it causes other issues (such as throwing off the expected records count per page) but it is a possible line of thought for exploration.

Resources