Time Flies When You’re Landing Code

post1

Disclaimer: I’m a writer, but I find blogging very uncomfortable. I’m terrible at keeping a journal. This might get weird. Or be super boring. Or both. Bear with me.

Two weeks into my Outreachy internship with Mozilla, and I can’t believe how quickly each day passes! I’m happy to be working with the Web Compatibility team, a distributed group of folks who work tirelessly each day to make websites work as intended for everyone—anywhere, on any browser (though with a focus on Firefox), on any device. (Sounds both noble and overwhelming, right?)

I will eventually be building at least one dashboard to display various project metrics. The specific measures are still to be determined, but may include things like a live list of outstanding high-priority bugs, burn-down rate, usage of the webcompat.com site and its various add-ons, and/or Firefox telemetry data. However, since the details of that project still need to be hammered out, I’ve been warming up by tackling smaller tasks. So far I’ve landed some bug fixes and enhancements to the extensions that allow users to report web page problems directly from their browser, made some attempts at diagnosing reported page issues, and spent a lot of time reading up about JavaScript specifics and tools (not especially tantalizing teaser: there may be a future post contrasting documentation quality between, oh, I don’t know, Webpack 👍 and Intern 👎) used in the project’s code base.

Toward the end of last week, my mentor Mike suggested building a web application that would make it fast and easy for someone to determine the most urgent webcompat bug in the queue. This app would fetch open issues from the GitHub and Bugzilla APIs and prioritize them automagically (interesting: Apple’s dictionary thinks this is a word, Firefox’s … not so much) so that a user can click a button and be told instantly (ish) what problem to attack next without having to sort through and weigh priorities on their own every time. Since it would involve a similar structure on a smaller scale (a back-end processing data retrieved from the APIs and a dynamic front-end delivery system), this sounded to me like the perfect transition to the bigger dashboard project. Plus, since he said I could build it however I wanted, I can really take ownership and play around with possibilities. (It’s a credit to Outreachy, Mozilla, and Mike that after less than two weeks, this sounded super fun instead of terrifying.)

After a long day Friday of online research, bookmarks, scrawled notes, and head scratching*, I’ve decided to get started with the idea of trying to use a MEVN stack (a variation on a MEAN stack using Vue instead of Angular). This is sort of intentionally overkill (I think I could probably do everything with just jQuery, maybe?), because I think it would be a good refresher for full-stack thinking and a hands-on way to learn more about Vue. The creators claim it’s approachable and scalable and that “learning enough to build non-trivial applications typically takes less than a day” … so we’ll see if I wind up being typical, I guess! Fingers crossed.

* This included a demented half an hour wherein I contemplated trying to build the back end in Haskell or Go … but thankfully recovered my sanity.

🤓 links: