Software-Dev

The cozy world of DevOps has spoiled me with tools like Ansible, Terraform, and Packer. In the situations where I have a Linux machine already booted up, and sometimes already connected to the Internet, I can make things really easy on myself by slinging these tools in my usual way for repeatable, reproducible machines that may or may not come with the attendant headaches of immutable infrastructure (sorry, Nix, I’m not in love with you, I’m in love with the idea of you). ...

Quoth “How to Become a Hacker”: 2. No problem should ever have to be solved twice. Creative brains are a valuable, limited resource. They shouldn't be wasted on re-inventing the wheel when there are so many fascinating new problems waiting out there. Much more at the original post, including preemptive rebuttals to what I’m about to describe. This post is entirely about cataloguing my own error. I took this maxim, perhaps, a little too close to heart when I was starting out as a software guy, 15-odd years ago. This is my apology to past me. Past me, I apologize. ...

At least not for most use cases. You can just use modernc.org/sqlite instead as your SQLite driver. For people who aren’t in the Go know, “pure” Go programs are trivially easy to compile cross-platform to all the major platforms by default. You read that right - you can just go build a single Windows executable, Mac executable, and Linux executable on the same machine and just ship it: 1 2 3 4 5 6 7 8 9 10 11 12 13 14 # This can all happen on the same box! export CGO_ENABLED=0 # no c cross-compilation please export GOOS=linux GOARCH=amd64 go build -o hello-linux-amd64 hello.go GOARCH=arm64 go build -o hello-linux-arm64 hello.go export GOOS=darwin # aka mac GOARCH=amd64 go build -o hello-darwin-amd64 hello.go GOARCH=arm64 go build -o hello-darwin-arm64 hello.go export GOOS=windows GOARCH=amd64 go build -o hello-windows-amd64.exe hello.go GOARCH=arm64 go build -o hello-windows-arm64.exe hello.go This was the real reason I chose Go over Python for tsk, my instant-search Finnish to English pocket dictionary. I wanted to be able to give Windows users a single .exe they could just run and have work out of the box. ...

Earlier today on Hacker News Scrappy made the rounds, with the explicit tagline “make little apps for you and your friends”. I always like to see new projects in this vein. That’s why I’d like to outline my alternative approach, which Works cross-platform and on mobile devices by default, Doesn’t require any app store tomfoolery, Has great uptime built in, Gives you just enough data persistence to not get in your way, and Is owned by you, forever. This is the stack I used to build my diet checklist, which I keep as a little icon on my phone’s home page. Here it is: ...

Below is a GIF of tsk, my pocket Finnish-to-English dictionary, running in my terminal emulator of choice under Linux. It’s what the kids call a TUI, a graphical program that just happens to drive its graphics using terminal graphics instead of graphics-graphics. Insert GIF here. You can probably tell that this program fits neatly into the “home-cooked meal” clade of programs. There is a very straightforward problem I want solved - fast, single-executable-portable dictionary lookup, with a few conveniences for the busy language learner layered on top. I am quite happy with tsk in its current iteration and don’t plan to add much more to it anytime soon. It would still save me a lot of time and hassle if I were the only person who could use it. ...

If you followed “Binary search isn’t about search” and “Binary search isn’t about search II” properly, the following statements should suffice as a summary: 1 2 L[0:l] < T < L[r:len(L)] # ordinary binary search loop invariant L[0:l] < T <= L[r:len(L)] # leftwise binary search loop invariant Let’s complete the triptych. Take a wild guess what invariant we use for rightmost element binary search: 1 L[0:l] <= T < L[r:len(L)] # rightwise binary search loop invariant A motivating example Consider again an array like ...

Suppose you’re trying to track down a bug that appeared in a series of Git commits. You’ve been idly keeping track of where this bug appears in your lucky commits by hand, while busy with other things. So far you’ve compiled this table: 1 2 3 4 5 6 7 8 9 10 0000000 🧼 clean, no bug. 0000001 🧼 0000002 🧼 0000003 🧼 0000004 🧼 0000005 🧼 0000006 🐛 bug first appears here. 0000007 🐛 0000008 🐛 0000009 🤔 bug mysteriously disappears... Then an EMP explodes in your vicinity and scrambles your memory circuits. The Internet is down, you don’t have the git-bisect man pages downloaded locally, and all you remember is that your first commit was good, your last commit was good but for reasons you don’t understand, and something bad is probably still lurking in there. But where? ...

This is a response to pid1.call’s “Siren Call of SQlite on the Server”, which itself is a response to articles like Wesley Aptekar-Cassels’s “Consider SQLite” espousing SQLite as a server-side technology. Cards on the table, I both love SQLite and think pid1 has the more correct take here. When I decided on a dime after college to move countries and be with my wife, part of the package deal was that I had to throw away my dreams of easing into the software industry by resting on the laurels of my strong, but not MIT-level-known-worldwide-strong, alma mater (sorry Wildcats). Electrical engineering was just not going to be feasible for a then-monolingual English speaker in Finland, and besides, I majored in it 90% out of curiosity anyway. I always intended to return to my once and future home, the shell, after my Rumspringa with electrons. ...

What’s the best way to get a job? Show someone with a job to do that you can do the job within their iron triangle. What’s the best way you can show someone you can handle a complicated k8s deployment, with 7 different CNCF-approved add-ons, zero-downtime rollouts and a whole bunch of YAML files? Probably by competently and publicly running your own complicated k8s infrastructure. Self-hosters remind me a lot of the sysadmins of yore, who mostly ended up in the profession because they just couldn’t help but mess around with their underlying computing machine until they knew all kinds of weird nooks and crannies within it. I trace my own lineage in software deveopment back to the day my parents finally purchased a Dell laptop and a 300 Kbps Internet connection (residential wiring in Boston left something to be desired), and promptly broke the Windows registry and installed Ubuntu without them ever realizing anything had changed. The next year I got my first internship through a high school program as a Unix admin intern at Akamai, and the rest is history. ...

First get a working script. “Hey GPT-4, write me a ChatGPT script that does .” Manually check over the script and iterate until it’s giving me what I want. “Now wrap the script into a click command-line interface.” I almost always specify to use an --input flag and an --output flag. If the data it’s working with is human-readable, “Make it so that if --input is not specified, it reads data from stdin.” If the data it’s writing is human-readable, “Make it so that if --output is not specified, it emits data to stdout.” If the script is complicated enough that error logging is warranted: “Add logging and colorlog. Ensure all error messages are written to stderr so that it does not clash with output.” This advice is optimized for small Python scripts, usually under 200 lines in total, for automating semi-mundane tasks like ...