Chris Hannah

Programming


Engineers Should Write

Ryan Peterman on Engineers needing to write:

The way I worked started to change around when I became a mid-level engineer. I led a small workstream of a few engineers and to get my work done, I was writing more and more without realizing it. Soon writing became a significant part of my work outside of coding. This became even more true when COVID hit since most conversations moved to async chats and word docs.

Almost everything software engineers do requires writing. We need to write when we ask technical questions, comment on code reviews, or create design docs. This is because writing software is collaborative. The better you are at writing, the more effective you will be at building software.

Being a software engineer and a writer, my opinion is likely biased in favour of this opinion. However, I have noticed that as I have progressed in my job, I have found writing to also be much more important. Whether it's writing documentation, reviewing code, planning features, analysing future architecture, or even just helping other engineers. There's a huge benefit to being able to write clearly, and to be able to explain your thoughts to your future self, and others.

I wrote about this last year when I talked about having a culture of writing at work. I won't repeat everything here, but here are the five benefits I said come from a good culture of writing:

A Few Things I Use the Command Line For

I’ve noticed myself using the command line a lot more recently, at home, and work, so I thought I’d share a few of the little tools and handy commands that I use on a day to day basis.

Note: I use ZSH as my shell, with oh my zsh, so they may differ slightly if you’re using something different.

Aliases

The most helpful commands that I use have to be aliases for the most minor commands. But because they’re used so often, it saves so much time.

The majority of them are for two things - moving to common directories, and launching applications.

Here are a few examples of directories I have set up with aliases:

That’s just a small snippet, but usually, I have most projects set up with a very small alias. But even if I don’t have one set up for each project, I’ve got one that puts me at the root of my developer folder anyway.

As for applications, I’ve got a few that I use a lot:

Git

Being a developer, I use Git quite a lot. And that is where oh my zsh comes in handy, as it comes with a huge number of aliases for common Git commands. Here’s a great cheatsheet.

Here are the ones I use the most, and also what the full command is:

I’m aware that those are pretty minor commands, but they’re so much easier when they’re just one two or three letters.

Also, oh my zsh does come with an alias for committing changes with a message, but it’s gcmsg and that’s longer than just using gc with the -m option.

The most used Git command I use though has to be a little ZSH function I made myself:

function gacp {
    gaa; gc -m $1; gp
}

It stands for “git add commit push”, and as you can probably tell, it adds and commits the following changes, with the supplied message, and pushes it to the remote repository.

Most of the time I’m doing stuff like this:

gacp "JIRA-123 fix tests"

Woops!

FTP

I don’t use these a lot, but I do have a few aliases to update various websites. They basically use the scp command (secure copy) to transfer files from a local directory to a remote server. Guide.

This isn’t exactly what I have, but they all follow this rough syntax:

scp -r /Users/chris/website user@123.123.123.213:../var/www/

This will recursively upload the contents of a local directory to a remote server. I use this whenever I update changes to my blog theme.

HTTP Requests

Whether I’m working on a mobile app or REST API at work, I’m usually testing various requests throughout the day. And while I sometimes use a tool like Postman, especially when I’m building a collection for QA testers, I do find it a bit cumbersome sometimes. So that means I end up resorting back to the terminal.

I’ve seen a tool called httpie which does seem to be quite good, but I’ve found curl to be good enough for my uses.

Tip: If you’re stuck with the syntax and don’t have time to wade through documentation, I’d recommend using a tool like Postman to build the request, and you can then export the curl request.

Most of the time I’m just performing GET requests, so the syntax is simply:

curl https://dev.chrishannah.me/feed.json

If you need just the headers of the response there’s the -I option, and if I want both the headers and body it’s a lowercase -i.

Environment Variables

Usually, I’m using the command line because I want to test quite quickly, and with slight tweaks, so I find making the command as short as possible helps with this.

The first one for me is to use environment variables. So for example I’ll use one for the base URL of the API, and usually a few for any variables that need to be in the path, especially if these are user account numbers, as it makes it a lot easier to quickly test different scenarios.

This means that a request like this:

curl https://company.com/api/account/2a3e4832-14e6-430d-8c34-748f4626e864/transactions

Can be made a lot shorter by using two environment variables:

export base=https://company.com/api 
export account=2a3e4832-14e6-430d-8c34-748f4626e864/transactions

Which means it can look like this:

curl $base/account/$account/transactions

The biggest benefit I find is that allows you to edit the command much easier.

Using Files

Another tip I have for curl is that if you have a bunch of headers that you need to use, then it helps to have these stored in a file.

You can do this by using the -H command followed by @ and then the filename. For example, this command will read the headers from a file named headers.txt:

curl https://website.com -H @headers.txt

The header file needs to be in this format:

Key: Value

So something like this would work:

Content-Type: application/json
Authorization: Bearer [token]

This is especially handy for me as most of our APIs at work require various authorisation tokens that can be quite large.

You can also use other options to use files for storing the body of the request, but I’ve not had much experience of that, so I’ll have to defer to google.

JSON

This goes hand-in-hand with making HTTP requests, in that the responses are usually JSON. For that I use the JSON processor, jq.

Most of the time, I’m just using it to “beautify” data from a curl request, so I pass through the response to jq by piping the output from curl to jq like so:

curl https://dev.chrishannah.me/feed.json | jq

What that does is take the response from the curl request and output a pretty printed version of it.

But you can also use jq to parse the JSON response and pick out certain fields.

So for example, a request to my blogs JSON feed at https://dev.chrishannah.me/feed.json will return a fair bit of JSON data. Something like this:

{
  "version": "https://jsonfeed.org/version/1",
  "title": "Chris Hannah's Dev Blog",
  "home_page_url": "https://dev.chrishannah.me/",
  "feed_url": "https://dev.chrishannah.me/feed.json",
  "description": "A devlog by Chris Hannah",
  "author": {
    "name": "Chris Hannah",
    "url": "https://chrishannah.me"
  },
  "items": [
    { ... }
  ]
}

But say I only wanted to read the author object, I’d just need to use this command:

curl https://dev.chrishannah.me/feed.json | jq '.author'

Which will return just this:

{
  "name": "Chris Hannah",
  "url": "https://chrishannah.me"
}

There’s a lot more it can do as well, and I’d recommend checking out these examples.


I’m sure there are tons of other resources that go into far more detail on what you can do with the command line. But I thought I’d share a few things that I use it for, just in case it might prompt others to find some ways to save themselves time!

Textastic Code Editor 9

I wrote about wanting an offline capable Visual Studio Code app for iPad yesterday, and while I haven’t found an app that I feel to be equal, Textastic does seem to be the best code editor app I’ve found for iPad.

How to use Visual Studio Code on your iPad

Thord D. Hedengren, shared a great tip on his Switch to iPad blog on using VS Code on an iPad:

One of the most popular code editors for web developers today, is Visual Studio Code, or VS Code for short. It’s made by Microsoft and is available for macOS, Windows, and Linux. Unfortunately, there isn’t an official iPad app just yet, but that doesn’t mean you can’t use VS Code on your iPad. At least not if you use GitHub to manage your codebase.

How you access it is pretty inventive:

Now, assuming you’ve got a GitHub account, and a repository, you’ll also need a keyboard. Any bluetooth keyboard will do, just as the Magic Keyboard if you’re on an iPad Pro.

Navigate to your repository in your web browser (you might want to use Safari to be safe), then press the period (.) key. Yep, that’s it, now VS Code will load up your repository, in your web browser window, just like that.

VS Code is an app I use a lot at my day job, for all use cases where I’m not using Xcode to write Swift, or IntelliJ to write Java. I also use it when modifying my blog theme, and playing around with random text files.

I’d love it if the app could come to the iPad as an app. It’s built on web technologies so it wouldn’t be fully native, but as much as I’d love to use the web version of VS Code, I don’t want to be reliant on an internet connection to edit a local file.

Programming Sucks →

I just read one the funniest and accurate essays by Peter Welch, which was shared by Sarah Drasner on Twitter:

Every friend I have with a job that involves picking up something heavier than a laptop more than twice a week eventually finds a way to slip something like this into conversation: “Bro, you don’t work hard. I just worked a 4700-hour week digging a tunnel under Mordor with a screwdriver.”

They have a point. Mordor sucks, and it’s certainly more physically taxing to dig a tunnel than poke at a keyboard unless you’re an ant. But, for the sake of the argument, can we agree that stress and insanity are bad things? Awesome. Welcome to programming.

It was published over four years ago (April 27th, 2014), but it’s interesting to see how relevant all the points still are. If you have 10 minutes to spare, then I highly recommend giving this a read.

I’m definitely adding this blog to my RSS reader for future reading.

Bill Gates on Tabs vs Spaces →

Straight from his sixth AMA on Reddit:

When I code I use tabs because you want the columns to line up. For some word documents I use tabs. You want things to adjust when you go back and edit them and tabs help.

🔥

Reddit Comment
Full Reddit AMA

A Backend Engineers Experience on Switching to an iPad Pro →

Jannis Hermanns took on a rather interesting challenge recently, and it was all about working from an iPad Pro.

But unlike most people that make the switch, he’s not a writer, manager, or a designer. Jannis is a backend engineer, that uses some terminal in some hardcore ways!

In the summer of 2017, I wanted to know what it would be like to use an iPad Pro as my main computer. I found out that it can actually work, thanks to an iOS app called Blink, an SSH replacement called Mosh, iOS 11 and running stuff on a server.

His perspective/experience I find, is different than most other macOS to iOS switching articles, as there was a lot more technical issues that had to be solved.

But nonetheless, he managed it in the end.

Sadly for myself though, this switch isn’t something that I could do myself any time soon, as I develop 99% of the time using Xcode. Sure, I could probably run that on a Mac, and use a iPad to operate it. But what’s the point in that.

Read the full post.

My App Store Clear-out

As I’ve been getting back into development for Hydrate (a water intake tracker for iOS), I’ve been thinking about the sort of representation of myself as a developer.

When I think of a great developer, they usually have a small number of apps. Sometimes they’re all at a really high standard, but most independent developers I see, have one or two main apps, and a few more fun ones.

I have been developing for iOS/macOS for quite a few years, and I have to say most of them are dead, stale, or heading in that direction. So it’s time for a clear out. This might not be a very interesting article, but I certainly think the act of me writing this, will aid in the process.

For some background information, here is the list of apps that I’ve made for iOS/macOS, and their current status.

Name Platform Status Description
Hydrate iOS/watchOS Available. My current work-in-progress, a water intake tracker.
Pretty Regular Expressions iOS/macOS Available. Regular expression tool for macOS/iOS. Very simple.
Pixels Sticker Pack iOS Available. Some pixel art iMessage stickers!
AniMatchers iPhone Available. Just a fun memory matching game, with cartoon animals.
Bill Splitter iOS/watchOS Available. A super basic bill splitter. Mainly a small project so I could check out the watch SDK.
Qwiki macOS Available. My wikipedia menu bar app, which is one of my best projects in my opinion, which I will hopefully update soon.
Tap Gap iOS Available. A quick game for iOS, where you try and tap the screen when a line is between a certain gap.
Floppy Turd iOS Available. An awful, but funny remake of Flappy Birds. It took a sunday morning to create, and that was where I left it.
TinyMe iOS/macOS Removed. One of my first few apps, they used the goo.gl api to shorten longer links, but they aren’t an issue anymore.
Postie macOS Available. I used to blog on Scriptogram, and this was a basic Markdown editor with publishing built in. The service has unfortunately shut down.
The Girlfriend Helper iOS Removed. I think the first app I made. It was an app that suggested message you could send to your girlfriend depending on the event type.
Halloween FX iOS Removed. Basic soundboard app, which also featured a timer so you could hide your phone and scare someone.
The Farm iOS Removed. Even more basic soundboard app, just contained farm animals.
Bug Splatter iOS Removed. This was a weird one, there’s multiple levels of bugs/difficulty, and the aim was to splat as many of them before they reached the end of the screen.
Whack iOS Removed. A pretty simple whack-a-mole game, but with pixel art, and funny noises.
TextShot macOS Never made it. This was a really fun project to work on, it was going to be an app where you could select a bunch of text, and it would generate a picture from it, even including multiple different styles. Sadly the MacBook I was using at the time died completely, and I wasn’t clever enough to think about source control back then.

Okay, I didn’t actually know I already removed a few of these already. But there’s still some clearing out to do.

My aim is to have a small number of applications, that either are stable, and need hardly any maintenance, or ones that I can regularly keep updated, and are proven to be worthwhile.

So if you just take the apps I have available, there’s 9. Well one isn’t released yet, but it’s in progress.

  • Hydrate
  • Pretty Regular Expressions
  • Pixels Sticker Pack
  • AniMatchers
  • Bill Splitter
  • Qwiki
  • Tap Gap
  • Floppy Turd
  • Postie

If I separate them into the groups I mentioned before, I’m left with this:

Maintainable Apps:

  • Hydrate
  • Qwiki
  • Pretty Regular Expressions?

Minimal Effort/Stable Apps:

  • Pixels Sticker Pack
  • Tap Gap

Left over:

  • AniMatchers
  • Bill Splitter
  • Floppy Turd
  • Postie

That was pretty quick and easy, and it sort of represents what I already had in my head. Out of the four left over, they all have very good reasons why I don’t want to support them anymore. Low download numbers, super old code, and lack of interest to work on them again.

So, they’re be removed.

That leaves just five remaining apps, three I feel that are maintainable, and the other two are kind of eternal to an extent.

Of course Hydrate will stay, I mean I haven’t even released it, and it’s still in active development. Qwiki is stable, and my most popular app, so that will also stay.

Pretty Regular Expressions however was initially well taken, but I haven’t had any desire really to go back to it, and improve it. I will have a look at the code again, and hopefully I can add something to make the app even better soon.

Pixels Sticker Pack is a bunch of images, and I can’t see myself ever needing to update these. They’re fun, and I still enjoy using them!

That leaves Tap Gap, it’s a simple game, that still works fine. I’ll certainly make a few changes and support the iPhone X soon, but that is only a minor issue.

So the remaining apps, along with their pricing are:

Name Price
Hydrate Not decided.
Qwiki £2.99
Pretty Regular Expressions (iOS/macOS) £0.99
Tap Gap Free
Pixels Sticker Pack Free

Not a bad bunch!

I’ll be checking out a few of these projects today, and maybe even get thinking about the changes/updates I can make!

If you want to follow on with more detail, just follow me on twitter!

Creating .gitignore Files the Easy Way

If you’re a programmer, you’re probably aware about version control and Git, and maybe even what a .gitignore file is.

If you don’t:

A gitignore file specifies intentionally untracked files that Git should ignore. Files already tracked by Git are not affected; see the NOTES below for details.

Anyway, creating these files can be annoying to write manually, and there a bunch of templates all over the internet to make this much easier.

I however, found a much better solution for creating these files, and it’s gitignore.io. It’s a website that you can use to generate a .gitignore file, but also a command line tool that you can use, so you never have to leave your terminal.

It has support for operating systems, IDEs, and programming languages. So my standard file will be generated from macOS, Xcode, and Swift, since that’s how I roll.

You can type (with autofill of course) whatever templates you want to make use of straight into the website, and then hit ‘Create’.

For the command line, you’ll have to first install it, and then the gi command will be available. All you need to do is type gi followed by a comma-separated list of the same items you would use on the website.

So mine would be:

gi macos,xcode,swift.

The command would of course, output this out via the standard output, so you can direct it straight into your .gitignore file by writing something like:

gi macos,xcode,swift >> .gitignore

It’s super easy, and it saves a lot of time.

As a little bonus, there’s also a quick video on how to install and use the command line tool.

I’ve Been Writing Server-Side Swift!

I made my first API today, and I used Swift to do it!

Basically, I got bored this afternoon and decided to have a little research into server-side Swift programming. I’ve heard about this before, but I’ve not gone too deep into it myself.

The problem with me tying things like this, is that I ever really have a good idea, or scenario which I could use to learn the new thing. Well as you may already know, I’m slowly working on a title casing application for iOS and macOS, and therefore I’ve already created a few functions to format text.

So far the base TextCase functions are:

  • Uppercase
  • Lowercase
  • Title Case
  • URL Encoding
  • Mocking SpongeBob (yes, like the meme)

From these formats, the only ones I could see being useful are Title casing, and the fun SpongeBob format.

From making use of various APIs myself, I knew that all I needed was a super simple HTTP server, which had support for a few GET requests.

Perfect was the tool I used to write the server side code, and I found a quick tutorial which explained the basic HTTP server that I needed. I must say it was really easy for me to create this, as I’m already familiar with Swift, so the only thing to learn was the “Perfect” way of doing things.

Because it was in Swift, I could also reuse my main TextCase class which handles the formatting. There was a slight exception, where the arc4random_uniform function isn’t available on Linux, but I found a Linux suitable replacement for this.

There are also a few more reasons why I wanted to try this out, but they’re rather meta. For example, I’m a big fan of Swift, and it feels good working with “low-level” Swift if you can really call it that, and also because I just love the look of Swift in the default Xcode theme, with the SF Mono font 😍 (weird, I know, but it’s the truth).

The final code (as in what I’ve done so far), is three endpoints, which are actually just two. /title/{input text} is to return the given text in title casing, /spongebob/{input text} is for the SpongeBob case. The third one is just /{input text}, and it returns the text in every format available, which is just the two I mentioned so far. The results are in plain JSON, and also include the plain value that was sent in the request.

For example, here is an example response to the / endpoint:

{
    "plain" : "what the hell is this",
    "title" : "What the Hell Is This",
    "spongebob" : "wHAT ThE Hell iS thiS"
}

Anyway, you can view the project over at GitHub, and if you want to suggest any new formats (or even write some yourself), just let me know on Twitter at @chrishannah