Matthew Lindfield Seager

📖 Alex Cross’s Trial - James Patterson and Richard Dilallo (

This isn’t an Alex Cross book, nor (arguably) a James Patterson book. Despite the cynical marketing ploy, it was a pretty good, albeit dark at times, read

📖 Bad Luck and Trouble - Lee Child (

Another enjoyable Jack Reacher novel. Lots of action and intrigue… and the baddies seemed like more formidable opponents than others he has faced.

📖 Scarecrow and the Army or Thieves by Matthew Reilly -…

Over the top, ridiculous and impossible to believe. Exactly what I was hoping for to start my holiday reading 🙂

Is Your Ticketing System a Tool or a Weapon?

In the hands of a carpenter, sportsperson or chef, hammers, bats and knives are all useful tools. In other hands, or even just other circumstances, they are useful weapons. In fact, just about all tools and technologies can be used constructively or destructively.

A ticketing system is no exception. At its best, a ticketing system helps agents collaborate, facilitates communication with customers and ensures issues aren’t forgotten.

At its worst, a ticketing system can be gamed by agents to avoid work they don’t like (or colleagues they find annoying), they can be weaponised by customers to prove how poor the service they received was or they can simply devolve into a distraction from the actual work of helping people.

Some quick rules of thumb I have for running a ticketing system are: - never ask someone who has just told you about a problem to log a ticket… they made the effort to visit you or call you to tell you there’s a problem, don’t make them tell the story all over again to an impersonal ticketing system - focus on solving their problem, not closing the ticket. If the problem is solved and the customer is happy, the ticket can stay open forever for all I care, just as long as it doesn’t stop you from noticing the next ticket - don’t use the ticketing system as a wishlist or backlog. Anything that hasnt been touched for two weeks (and probably isn’t going to be in the next two weeks) doesn’t belong in the ticketing system; it just gives the customer false hope and the agent unnecessary stress - if you can fix it straight away, just do it, no ticket required. We’re here to solve problems, not track time or put notches in our belts - try to fix problems and have conversations in person (or at least on the phone). Put a (very brief) summary of the conversation or solution in the ticket for collaboration/posterity - find ways to measure what matters, rather than what’s easy to measure - ignore any or all of these rules when doing so makes more sense or gives the customer better service

A Tale of Two MacBooks

My 2016 MacBook Pro had keyboard problems within about 6 months.

My 2019 MacBook Air (less than 5 months old) is having keyboard problems.

My MBP was owned by work and came with an on-site (edu) warranty.

My MBA is owned by me and has a back to base warranty.

I kept using my MBP right up until the tech arrived… and I had it back in less than an hour!

My MBA will be out of action for a predicted 5-7 business days.

My livelihood as a salaried employee was completely independent of my MBP. If it failed, I would still have been paid (AND I could have immediately borrowed another Mac from work).

My livelihood as a self-employed contractor is highly dependent on my MBA. To be without it for over a week is hugely inconvenient and potentially very costly.

Despite (or perhaps because of) my MBP experience, I used to think the tech uproar about Apple’s keyboard problems was overblown. After all, “it’s only affecting a small percentage of users” and Apple (Unisys) fixed mine almost instantly.

Now that I’m experiencing it on my almost new MBA with a third generation butterfly keyboard, and facing more than a week without THE crucial part of my toolkit, I’m feeling a lot less forgiving.

It’s just a shame my 2010 MacBook Pro can’t run a modern operating system! Other than dreadful battery life and a spongey trackpad its hardware is still going strong! (Including the keyboard, despite spending six months in the dust and grime of Afghanistan, a literal war zone)

I had a couple of hours to kill in Parramatta so I dropped into UWS’ new building near the station. They had lots of good workspaces, comfortable furniture, plenty of 240V/USB power outlets and clean facilities 👍

The table tennis table in the quiet zone made me chuckle though

The Internet generally and YouTube specifically can be pretty amazing!

This evening I was told I needed to learn how to make balloon animals… in 45 minutes I progressed from zero to confidently (even if not competently) making dogs, swords and even 2 colour flowers!

Two items for the “you could but probably shouldn’t” category and Postgres:

Scripts to Rule Them All

Today I configured a new Rails app with Scripts to Rule Them All. It’s a “normalized script pattern that GitHub uses in its projects” to standardise projects and simplify on-boarding. It’s probably premature for an app I’m working on solo… but if you can’t experiment on side-apps, when can you? 😜

I ran into a catch-22 where, the first time you setup the repository, the setup script tries to initialise the database, which relies on the database server being available. The support script that starts the database relies on the setup script (or more specifically, the bootstrap script it calls) already having been run to install the database server. But the setup script relies on the support script… etc, etc

Rather than get fancy I decided to let the developer deal with it. The setup script is idempotent so there’s no harm in running most of it the first time and then all of it the second time. After DuckDuckGoing how to check if Postgres is running and how to write if/else statements in shell scripts I settled on this clause in the setup script:

if pg_isready; then
  echo "==> Setting up database…"
  bin/rails db:create db:reset
  echo "==> Postgres is not running (this is normal on first setup)."
  echo "==> Launch ‘script/support’ in another console and then try again"
  exit 1

echo "==> App is now ready to go!"

I’ve been helping with a POS implementation on Vend (

It’s just a delightful application to use with amazing attention to detail! The way they gracefully handle data imports is a great example of how they understand what their customers need.

While searching for my POODR ebook, I stumbled across some notes I wrote last time I read it… I took notes and I still don’t remember reading it! 😬

This (U.S.) thanksgiving weekend I’m thankful that several podcast hosts are having a break, letting me catch up on my backlog a little 😆

I’ve been enjoying reading Noah Gibbs’ thoughts on deliberate coding practise:

Following his encouragement, I think my next book will be 99 Bottles of OOP

German from Thoughtbot with a great post demonstrating a pattern for a generic (SMS) client with multiple adaptors… Nice abstraction with the added benefit of being able to mock an adaptor for testing:…

Ruby Science by Thoughtbot:…

Another awesome resource from Thoughtbot, and made all the more accessible since they reduced the price of all their content to $0

Extracting classes decreases the amount of complexity in each class, but increases the overall complexity of the application. Extracting too many classes will create a maze of indirection that developers will be unable to navigate.

Enjoying the practical advice in Ruby Science!

Bookmarking this clever approach to re-using an ActiveRecord scope (i.e. at the class level) within an instance method to prevent duplication…

I had some fun reading about pangrams and lipograms after reading this Twitter thread about self-referencing pangrams:…

I’m a little disappointed with WatchOS 6… I’m experiencing two significant bugs, one with the alarm complication and one with the Activity app; both of which are key features of the watch.

Seems like Apple’s hit a bit of a rough patch with software stability in their new OSes

Yesterday I subscribed to a few repositories on CodeTriage. It sends an email each day with an open issue and/or snippet of documentation from projects you care about. My goal is to build it into a small daily habit of supporting open source projects

Manton Reece is knocking it out of the park with! The new auto-categorisation feature is an awesome addition!!!…

I might have to trim down my podcast subscriptions… my feed is starting to overflow now the Northern Hemisphere summer is over!

I’m currently reading The Well Grounded Rubyist 📖…

I think I probably should have read this one BEFORE Ruby Under a Microscope… it’s a lot more practical and down to earth 🙂

It wasn’t really the point of the latest Code[ish] but I was once again struck by the sheer volume of effort that goes into open source development tools…

Sure beats pirating REALBasic as a kid because you want to code but can’t afford a license!

Apple Arcade

We’ve been enjoying Apple Arcade! It’s so nice to let the kids try new games without having to warn them about manipulative game mechanics and exploitative in-app purchases (IAP) or worry about them seeing mildly inappropriate in-game ads!

My favourites so far are Mini Motorways and WHAT THE GOLF?.

Naomi has been enjoying Spek.. This morning I was surprised to hear her, unprompted, say “Augmented Reality is fun!”

Ben’s favourite so far is Kings League II. He has always enjoyed games with constant levelling up that are never too difficult.

We’ve never been big into games (I’ve only owned three game systems in my whole life: a Sega Master System II, a second hand Sega Game Gear and, more recently, a Nintendo Wii) but I am mildly tempted to buy a game controller or two for Christmas to play some of the more involved games with the kids.

Which leads me to my only “complaint” with Apple Arcade… so far I haven’t found any games that dont require somewhat constant attention. When I’m on the train I tend to prefer slower paced games where the game waits for me to take my next turn. I’m keen to see whether Apple Arcade fosters (directly or indirectly) more quality, casual games like in the “good old days” of the App Store.