I've been at Bluecrew for a month now and one thing I'm actively improving is their continuous integration (CI) strategy. Every team has values around their code and systems. The existential question I ask about each value is this: does CI enforce the value? If not, the value does not exist. You could think of this as an all or nothing CI strategy.
I first heard about test-driven development (TDD) around 2006-ish and I still hear about it often. TDD encourages you to write effective tests because you always see both states: the failing state and the passing state. This is great but it's easy to write the wrong code for a feature as you learn more about it. Duplicating that exploratory effort on tests is a waste of time.
After many years of building software on small to medium sized teams, I prefer a leaner approach that accomplishes the same goal: something I call spike, test, break, fix.
When studying Sound and Film at art school, I spent most weekends renting as much equipment as possible, wheeling it into my dorm room, and staying up late creating work. I've been called a workaholic for this kind of behavior and maybe it's true; I really love working on meaningful projects.
Bluecrew creates apps for on-demand staffing (temp work) but with a twist: workers receive W-2 status and everything that comes with it. This includes minimum wage protection, overtime / sick pay, workers' comp., eligibility for healthcare, etc. Bluecrew connects people to jobs like light industrial work, hospitality, and logistics, providing opportunities at varying skill levels.
I originally sent this as an all-company email. Below is an edited version.
After 9 fantastic years I’ve decided to move on from Mozilla. Here are some reflections about what makes Mozilla such a special place to work at.
My first commit was a simple right to left localization fix on addons.mozilla.org -- wow, I couldn't believe I was shipping a web app used in 40 languages! It has been an honor to make such a powerful impact in so many people’s lives all over the world. Thanks to Mozilla for inviting me to be a part of their unique and crucial mission. Since then I've had the chance to work on many different projects and technologies, most recently in UI engineering.
Working in the open has been fascinating to me...
At Mozilla, the Add-ons team hosts a casual show & tell each month. It's a public meeting and we invite community members to share their work.
This time I demo'd some of the work I've been doing to profile and optimize our code manager, a tool that the review team uses to make sure add-ons are safe for Firefox users. It's a code viewer that looks like an IDE: a file list on the left, code in the middle, and a file overview on the right. The UX is similar to reviewing a pull request on GitHub but the main difference is we integrate our automated scanning tools to provide hints about potential problems.
The big challenge we ran into is how to display very large code files and diffs without lag...
A skeleton screen is a technique of rendering placeholders for text, numbers, and other parts of a UI that haven't yet loaded. As a user interacts with the UI, they immediately see the illusion of new screen states—the skeleton—and this makes the app feel very fast. The skeleton layout is typically animated in some way to convey that data is still loading.
My team at Mozilla built addons.mozilla.org with skeleton screens for all loading states. This article covers some of the details about the techniques and approaches we took and some gotchas. It focuses more on the concepts rather than the implementation...
React first emerged as a powerful way to build living, breathing client side web applications. When my team at Mozilla set out to build a React frontend for addons.mozilla.org in 2016 we knew we needed server side rendering (SSR) for SEO and performance but we underestimated how much of a challenge it would be.
This is a deep dive into how SSR is fundamentally different from what React was designed for...
I wrote an article for Mozilla Hacks about testing React / Redux apps.
- Setting up a test for a Redux connected component is simple:
just dispatch the actions needed to enter a desired state.
There's no need for mock objects or API calls.
If you need to assert that the component dispatches an action
in response to a UI event, you can spy on
- Shallow rendering lets you run fast,
For example, breakage in an
<Icon>component (that might be used all across the app) would not break your entire test suite.
- Testing component interfaces rather than complete end to end coverage
improves encapsulation and makes tests more maintainable.
For example, if the component under test passes an
onSubmitprop to another component, it's better to simulate the integration by calling
otherComponent.prop('onSubmit')(). There's no need to fully mount the other component.
- I recommend using static typing with these testing strategies to ensure all components are integrated correctly.
I've been working remotely from a home office with Mozilla since about 2010 (4 years so far) and although it has challenges I still enjoy it. It requires some discipline and most importantly a routine. Matt Gemmell's article on this has excellent pointers on routines and setting up an isolated work space at home. I wanted to add a few things to his post from the perspective of working as a software engineer (my profession)...
The OpenSSL heartbleed bug was a serious kick to the Internet's collective ass. This video provides a quick overview if you want the details. In summary, an attacker could craft a payload with a fake size (up to 64k) and trick openssl into sending a random chunk of server memory. WTF?! To understand how bad this was I spent a minute hacking on this script that was going around. I pointed it at login.yahoo.com (which is no longer vulnerable) and tried to see if I could catch a username and password flying by. I had one within 30 seconds. That's how bad it was; you could read random parts of the server's memory which may contain passwords, private keys, or whatever else OpenSSL was processing for current site visitors.
I had stolen someone's credentials. Game over, right? How do you protect yourself against something as bad as this? ...
Oh, hey! I almost forgot I have a blog. I wanted to write a quick note about where you can find stuff I write.
- Short and frequent updates! @kumar303
- On the Mozilla Hacks blog: https://hacks.mozilla.org/author/kmcmillanmozilla-com/
- On the Mozilla WebDev blog: https://blog.mozilla.org/webdev/author/kmcmillanmozilla-com/
- Modern funk I find on SoundCloud: http://claptracks.tumblr.com/
- Pictures of stuff, mostly album covers: http://instagram.com/kumar303
David Lowery wrote a piece on how downloading music is hurting musicians (which is a response to Emily White's piece on admitting to not buying music). Here is my response.
Music is a really interesting "product," especially when distributed digitally for $0.001 cents per download (that's my snarky guess at the production costs of a download: bandwidth, storage, etc). The real production costs are for the time put in by the artist, studio fees, and creativity. Besides the creativity part, that formula sounds a little bit like the FDA drug market, right? It costs about $0.001 cents to manufacture a pill so the hefty price tag goes to recoup the money spent on drug research. Or does it? Pharmaceuticals is a messed up industry...
In this article, a coffee shop entrepreneur laments a more "celebrity" entrepreneur who launched a similar startup but got more traction.
His conclusion: "The difference between the guy in the coffeeshop and the celebrity entrepreneur isn’t just press connections, money, and experience; ultimately it is this combination of factors."
I don't think this is true. A successful startup has very little to do with money and connections...