We added a big feature to The Zooniverse mobile app. You saw a lot of it in our coding live streams. Now, the feature is ready. It’s time to finish responding to pull request comments, open issues for unrelated concerns, merge the code into master, do manual testing, and deploy!
*Wait, I’m lost. What are we doing? Read about why I do live coding.
Show Notes: Shipping Large Changes
Professional software engineering isn’t all about slingin’ code. Sometimes, it’s a healthy dose of thoughtful communication and good ol’ fashioned patience.
In these streams, you’ll see me get about as close to screaming at a computer as I get (due to an incredible stroke of luck, I had accidentally muted myself for the part where I got mad). You’ll also see a lot of switching from one activity to another as we wait for something to finish. Then, when we run out of other activities, we straight up wait. It’s a glamorous job ;).
In this post, you’ll find:
- Two embedded live coding videos. At one point we had to update XCode, and I didn’t want to sit onstream while we waited. So I did an encore stream later to finish the job.
- A link to the pull request that we merge in the live stream, so you can review the code yourself.
- An outline of the topics we talk about in the live stream, with links to time stamps on the video.
You can explore the code!
This repo is public on github, so you can see each commit we make, including the commit message and the full change set. If you’d like to review what we worked on, you can check out the PR right here.
You can also get a transcript or closed captioning for either of these live streams.
In this post, I explain how you can get those things in one or two clicks on YouTube.
Here’s the First Video:
Outline: What we cover in this live stream
0:47 – The work starts here. We just finished a recap of what feature we’re building and where we’re going next.
1:10 – Pull Requests as Documentation, and how to produce a self-documenting pull request
2:20 – Making a change in response to a pull request comment
4:06 – Responding to manual testing issues in the PR. In addition to the code comments, my colleague also noted some odd functionality he noticed in the app. Here we go through the steps of verifying a bug report:
- Reproduce the issue
- Make a hypothesis
- Test the hypothesis (and repeat 2 and 3 until cause of issue is found)
In the course of doing this, we also have an aside to discuss something else:
8:50 – I see a fair number of articles from JavaScript bloggers along the lines of “never use inheritance.” Here, we talk about why I never say never—discussing a specific example, reviewing why I made the stylistic choice that I did (to use inheritance), and considering what would have convinced me to choose a different approach than the one I chose.
At the end of this part I mention this talk about the technology and psychology of refactoring.
Back to verifying the issue that Will found. Once we find the cause of the issue, we verify the expected behavior with an expert, and then we propose a course of action.
This isn’t coding: it’s Slack messages, GitHub comments, et cetera. But this kind of communication plays a critical role in a collaborative software project.
22:00 – A second example of verifying an issue.
He said left, Chelsea. Wait, I am going left! What is right? What is left??
25:50 – Another example. Here, we make an issue that would be good for someone who wants to ramp onto the project! Tweet on the subject here.
32:39 – What is a bug? Here we discuss what it means for software to have a bug. Hint: it’s more specific than “this thing doesn’t do what I wish it did.”
43:21 – Committing our final changes from PR review. Once that’s ready, we push up in preparation to merge!
48:18 – break
55:30 – Merging in!
57:43 – Here, we talk about the relationship between software engineering and grace. At the end of this section, I mention Avdi Grimm’s work. which you can check out right here.
1:01:00 – Time to do some manual testing of our merged code. We’ll be doing beta tests on a few different devices, so a cursory spot check happens here to ensure that things still appear to be working on the simulator.
1:05:10 – Time for us to release the app! Here, we package it up for both Android and iOS. We start iOS first, then at 1:07:19 we start the process for Android. We move forward switching back and forth between these two; when we’re waiting for one, we look at the other. This helps us stay productive and on task while things build. We even take some wait time at 1:12:05 to compose a tweet we talked about writing earlier.
1:21:35 – Here is where we set up release for Android in the Play store.
1:33:55 – Now we’re doing iOS. For iOS, in order to release, we had to reboot XCode, and then…
1:45:30 – The aforementioned silent screaming. Here, you get to watch me learn of a recent issue with XCode that prevents us from releasing our app with version 11.2. Instead, we need to go to the Apple Developer Console and download XCode 11.2.1, which is not available in the App Store yet (explaining why we were unable to find it when we checked for updates ourselves.
This took a while to download, so I stopped recording while it downloaded. Then I started again:
Outline for This Video
0:03 – The work starts here. We do the exact same thing we did in the previous video, but this time with XCode 11.2.1. And it works!
2:05 – We switch topics for a second. I share a little bit about my process for making these live streams: how I choose streaming versus recording, what I do with videos once they’re finished, and what I do once the videos are made!
I also show you where to find all the live coding show notes. That’s right here.
I might have also sneaked in a recommendation for this cover by Luca Stricagnoli of “Snow (Hey Oh)” by the Red Hot Chili Peppers. I really hope Luca doesn’t end up in the news in a way that makes me regret making this recommendation. That happens sometimes.
8:46 – Time to go to the app store and make sure that our app made it up! It did. Some processing has to happen, and then we start preparing for release on the app store. We put a version on TestFlight to allow our team to check out the new build. We also go ahead and submit a production release for review by Apple’s manual testing team. This process often takes a few days, so we want to get this started before a media preview we’re doing in one week.
New For this Live Stream:
- A lot of waiting. You see how I handle this by switching between tasks, but when I was down to one task left, we did a lot of sitting in silence. I’m not sure what to do with that time. Should I switch topics and talk about something else? Show you code on a different branch? Wax poetic with my deepest thoughts?
- I did some video effects on part 2: namely some blurring, plus removing part of the break period where we wait for the App Store to process our submission. We’ll see if we need these again.
That’s it for this session, y’all. See you soon!
If you liked this piece, you might also like:
This post on my entree into live coding (plus, how to get a transcript of a YouTube video)
This series about Structure and Interpretation of Computer Programs—in which I share what I learned in a week-long course on the classic book
The listening series—Unrelated to live coding, but hopefully useful 🙂