DevLog, April 24 2020

jfhbrook profile image Josh Holbrook ・8 min read

In my last post, I said I wanted to write blogs semi-regularly, and I totally failed at that. You'll notice that it's dated nearly two months ago! Womp womp.

In my defense, COVID has been a big distraction. I like to think that I'm pretty good at working from home and that I can self-manage effectively, but I won't lie - those first few weeks were intense. Other people smarter than me have pointed out that working from home and working from home during a global crisis-level pandemic are very different things, and as someone with a lot of experience working out of my apartment I can definitely corroborate that.

That said, I have been keeping busy, and I do have a lot of updates!


One of the reasons I didn't get to writing before things went sideways is that I decided to make a VIDEO about IHydra:

I wrote about IHydra before I finished the dev work on it:

The project is still in-progress with probably another week or two of off-and-on development, but the end is in sight. I have issues completing projects, so I'm hopeful I can actually ship this one. Keep an eye out - I'll have more to share soon!

Spoiler alert: I didn't actually reach the point where I can release an exe. At first, I was really bummed out about this! If my goal was to "ship", then on some level I failed. While I was able to get to some definition of code complete (testing aside - I still don't know the best way to do testing with electron and webpack) I ultimately ran into an electron-builder issue that I couldn't figure out, and never did figure out.

In general, I found the electron + webpack stack really difficult to debug and I found trying to get help for it even worse. Part of this is because mashing those two things together is "hard mode" - more than the sum of its parts for sure. If I was working with either one in isolation - either writing vanilla JavaScript in electron, or writing webpack code for a real website - I think the experience would have been a lot smoother.

Some of it, though, is due to an attitude within these communities that's a little hostile to giving volunteer assistance for the kind of problems I ran into. It seems like the people who actually work on these projects feel like support is a burden. The issue creation page for electron-builder, for instance, explicitly talks about prioritizing support for people that pay for it. At the same time, users of these tools think that people trying to use them should RTFM and become experts at webpack. This led to a pretty negative experience overall.

I try not to be an asshole about this. I'm not a frontend developer by trade so I'm naturally going to have a tougher time than people who do this daily, and as someone who has maintained JavaScript open source I know how thankless it can be. I probably sound really salty, and in the moment I definitely was, but I'm a little more understanding now.

Rather than beating myself up over not meeting my goal, I decided to move the goalposts instead. After all, I wasn't really on the hook for anything and this project was always "for me" - and if my fun hack project wasn't so fun anymore, then what was I even doing?

Making Videos with MoviePy

The way I made the video was actually pretty cool. I was messing around with Google and found a library called MoviePy that lets you make videos using a DSL in a Jupyter notebook!

I haven't actually made any videos since the Lego Studios days. People I talked to told me that using MoviePy was going against the grain on this, and based on my memories of making shorts in the aughts that's probably true. That said, doing this work in Jupyter was a positive experience. I actually really enjoyed it!

I think this is for two reasons. One is simply that I was doing something truly creative and artistic for the first time in a while and that it felt good to stretch those muscles. The other would be that Jupyter works well with my brain already and that I was able to use this interactive experience I was familiar with but in this other context. These things combined made for a good time.

I will say though that there were some rough edges. MoviePy uses ffmpeg and imagemagick under the hood, which can be a really grouchy piece of software sometimes! I particularly had difficulty finding encodings that worked well. Eventually I settled on .mp4s with .mp3 sound and suspect that this is the happy path in general. I was also doing this on Windows, which makes installing these dependencies more difficult - if I was editing on OSX I could have probably installed ffmpeg and imagemagick with homebrew and have been off to the races, but it was all a bit of a chore with Windows.

Emacs, org-mode and Literate Programming

As I mentioned in my last post, org-mode is among many many other things a literate programming environment. The way it works is that you insert inline source blocks a lot like you would in a markdown document, but with some metadata attached that says which file to write it to. If you did it right, you can tangle the file by typing C-c C-v t.

I've been using this a lot recently. For instance, I now manage my Emacs configs using org-mode and org-babel:

Another use case I had was for working on LeetCode problems. I wanted to be able to mix my notes together with my implementation, and for that it worked really well. I was also, with some finagling, able to get org-mode to tangle multiple files into a single output, giving me something akin to modules. I wrote out the details in a separate blog post.

PowerShell and Emacs

I run Emacs on all my devices, and that includes a Windows 10 machine. Emacs is fundamentally written with *nix in mind, so while setting it up is butter smooth in Linux and workable in OSX, there are a lot of rough edges in Windows. For instance, while in Linux you can run the Emacs daemon using good ol' systemd (don't at me), Windows services have a special interface and you can't casually turn a regular exe into one. The answer documented in the wiki is to put a batch file in the autostart directory, which works but is a little janky. I wanted something better. There are other issues too, way too many to detail here.

I'm in the process of writing a PowerShell module that will manage installing and updating Emacs for me, running the daemon, collecting and rotating logs, and exposing a systray applet using a NotifyIcon:

I'm also using org-mode for this project, alongside powershell.el. There are aspects of how I have powershell set up that seem a little rough around the edges - in particular for long source blocks it forces my cursor to the very bottom of the screen for some reason - but organizationally it's a great fit and I really like that the project is self-documenting. It's certainly the largest source file I've ever created, at over 3600 lines and counting, but because org-mode has collapsing headers it feels surprisingly good.

This one's a work in progress - almost done! While it's going much more smoothly than IHydra did, there's still a lot of yak shaving. When it's done I'll be sure to do a write-up!


While taking a break from working on my Emacs PowerShell module, I decided to write a little Azure Function to scratch an itch I've had recently.

When you write functions in PowerShell, the names are supposed to follow the format of {Verb}-{Noun}. Some official examples of this are Get-Item, Invoke-WebRequest and Start-Process. While the nouns are fairly freeform and often are less a noun per se and more of "the rest of the sentence", the verbs all come from a list of Microsoft-approved verbs. The combination of this format with these approved verbs makes it so that functions all have a very consistent naming convention, that semantic meaning of actions is well-understood, and that functions that do certain actions are more discoverable.

That said, the list of approved verbs is relatively short and it can sometimes be tough to find the right verb for the job. There have been at least a few scenarios where I've shrugged and said "I guess I'm just using invoke". Microsoft's documentation is pretty good here and with some digging you can usually pick the right word, but I wanted to make it easier.

I discovered that Merriam-Webster has a thesaurus API, which is really really cool! So I had the idea of taking this API and wiring it up to the Get-Verb function in PowerShell to give me a thesaurus specifically tailored to looking up PowerShell verbs.

At first I was going to just make this a PowerShell function, but when signing up for API access I realized that API keys were intended to be tied to an online application and I didn't want people to have to manage their own keys. So, I wrapped it in an Azure Function.

Azure Functions are basically Microsoft's answer to AWS Lambda. It's very much the same idea - similar web editor, similar pricing model, similar cold start characteristics (womp womp) - but Microsoft flavored and with support for .NET languages such as PowerShell.

So basically I have an Azure Function that takes a ?query querystring parameter, calls the thesaurus API with that word, and then inner joins the results with Get-Verb. I then serialize the response with ConvertTo-Json and send it back to the user. I can then call it with Invoke-WebRequest, use ConvertFrom-Json to go back to PowerShell objects, and print to screen.

As an added bonus, I manually coded a secondary lookup against Microsoft's suggested synonyms in the documentation, which yields more results than if I used the thesaurus API directly. This is because some words are only synonyms in programming - for example, "new" and "create" are basically synonymous as far as lifecycle actions go, but are definitely not the same thing in day to day English.

Unlike many of my recent "hack projects" this one was really quick - A few hours one evening to get the POC online and another few hours a day later to add the secondary lookup. I also did most of the work inside the web editor and inlined the API key - no git, no config files, just a single form field. This was really refreshing.

I have a README for the service plus a script you can use for querying the Verbtionary, as I call it, in a GitHub gist.

What's Next?

In the short term, I plan on wrapping up my Emacs manager for Windows, after which I'll probably start working on improvements to my org-mode GTD workflow.

I'm also starting to look for work in earnest, with a particular eye on freelancing. If you have a need for sound data engineering advice, some work on a project or anything else, feel free to hit me up!

Posted on Apr 24 by:

jfhbrook profile

Josh Holbrook


I'm a software developer with expertise in backends and data. I live in Brooklyn with my pet budgie, Korben.


markdown guide