Jiby's toolbox

I’ve previously spent some time implementing wordle, and since then enjoyed watching others discuss how to solve the game using programming, especially the solutions based on information theory.

I like to explore data, as can be seen in previous posts.

I’ve written a lot about Termux in the past, and since then, have continued to refine workflows around Android terminals, trying to push it to extremes.

Today I want to celebrate niche tooling that makes life more comfortable on the computer.

I’ve been thinking a lot about risk registers recently.

I’ve written in the past about using Makefiles for build automation and documentation.

The packaging workflow of Python has historically been a bit messy, starting with pip being just good enough, and virtualenvs being a great idea but a bit unwieldy.

In the software world, tickets (as implemented in Jira, etc) often have a bad reputation, and I think it’s undeserved, once we reframe what, or who tickets are for.

In programming, there are patterns everywhere: patterns of building code, patterns for organising components, even patterns for how to test things.

Since my earliest university days, I’ve spent a lot of time trying to get better at computers, immersing myself in the world of Linux, and generally improving my software development skills.

Every now and then, at work, I find myself discussing git worfklows, commit messages, branching, releasing, versioning, changelogs etc.

The most boring part of setting up a new code project is typing the boilerplate: it’s easy to forget bits, so we just copy the last project’s folder and “file the serial numbers off” on the project name.

Last Friday, I performed a presentation to my colleagues about Makefiles, and I want to share it to the public.

Let’s explore how a file-format design exercise turned into reinventing the wheel, and let’s all appreciate how lucky we are that the protocols that the internet are built on have fantastic public documents called RFCs.

I’ve recently written a series of articles about Gherkin: its usage for requirements gathering, about its uses in BDD, and a lower-tech alternative to Cucumber, which I’m still experimenting with.

In the previous post, I showed how Gherkin Scenarios provide a great framework for acceptance test definition.

In the previous post in this series on Gherkin, I showed the tools that Gherkin Features provide for requirements tracking, and mentioned ambitious goals for the Behaviour-driven Development (BDD) movement.

The most common mistake I see developers make is building the wrong thing: Not tracking exactly what is required from the start, and instead getting excited about the cool technical problems ahead.

Here’s how attempting to export images off a Word Document led to a quest for data deduplication and classification using the shell.

Like many developers, I keep track of my configuration files in version control, to make moving to new machines is simpler and share code with others.

I was trying to convert bank-issued CSV files that have a weird data layout, for automatic processing by the excellent ledger.

In order to troubleshoot a bug in the very early history of a project using git, I needed a way to show the git diff from “nothing” to the first commit.

I’m writing code to back up my user data off a website that lets me see all of my info (including querying by time, account etc) but doesn’t have export features (officially).

Get a cool graph of commits from the command line!

When writing long sentences in documentation repositories, git tends to show really unhelpful diffs.

Last night, I presented about Termux to EdLug, the Edinburgh Linux User group (see the event page on meetup.com) in a talk titled “The freedom of shelling out on Android”.

Who am I?

Welcome to my website!