Setting the goalposts for my rehab project
A collection of parts made by the lowest bidder, flying in loose formation
The subtitle of today’s post, which will be the first in a series of weekly updates, comes from the famed slur against the C-47 Skytrain, the WW II version of the Douglas DC-3. It was said that the Skytrain was a collection of parts, all made by the lowest bidder, flying in loose formation. So shall my first project be, at least sort of.
Here were my basic objectives.
First, I didn’t want to join an existing OSS project because then, on top of learning all the tooling, I’d have to learn the project and deal with the non-technical people and process factors that every project always involves. Doing all this would be basically 90% the work of taking a new job.
Second, I wanted to build something that would be useful as a learning experience for me, but not necessarily a full stand-alone project.
Third, I wanted something that would force me to start from scratch and build something using a typical modern combination of cloud services and tools.
To tell you what I decided on, first let me tell you a story. I once worked on a product where we had a very skilled and talented architect. He was awesome, your basic 10x engineer made flesh. He had a fatal flaw, though… he hated to admit that something wasn’t done or was behind schedule. Any time you asked him when something would be done, the answer would usually be either “well, I can probably finish that tonight” (and he would, which is why everyone loved him) or “it should be done {in this sprint | in the next one | in two weeks}”. In that latter case, more often than not, what happened was that the thing didn’t ever get done. So it was with adding push notification support to our product. It was two weeks away for months, and then he left and we never did get push notifications.
So that’s what I’m going to do: build the push notification component that I wish this product had had. That means I’m going to need a few parts….
a server application to send the notifications in the first place.
a notification service; normally that would be APNs or the Android equivalent but I think I’m going to use Azure notification hubs instead.
a mobile client app to receive the notifications. Since I have a little iOS background, I plan to do this using Swift on iOS.
a way to build and deploy all these things, probably using something like Pulumi or Bicep. Some of the things I need to do could be done with ARM templates, which I’m familiar with, but a more flexible toolkit would be nice, plus it would teach me some more stuff.
tests for all of the above
a way to track my work, progress, and bugs. Pretty clearly this will be Azure DevOps, since I use it daily.
a way to keep my work under revision control. Github FTW.
This is just the bill of materials, by the way. Some of these parts have their own dependencies or things they need; for example, my server application needs to be hosted somewhere (in a container? in a VM? serverless?), and of course I’ll have to choose a language and/or framework to write it with, and then there needs to be some kind of way for me to talk to the server to tell it to do things, and on and on.
Phew, after writing out that list, it seems like a lot for someone who already has a family, a full-time job, hobbies, and a side gig. So it’ll probably take a while.
For the t hree or four people who may be reading this, I invite your feedback in the comments. If you have biases for or against specific tools, languages, etc that you feel like sharing, I’d love to hear them.
Next Friday, I hope to have a little bit of progress to report on at least one of the above items. Until then, keep drinkin’ coffee.