DEV Community: Mat

Reviving an old Macbook Air with Ubuntu MATE

Mat — Mon, 02 Jun 2025 18:54:08 +0000

I recently installed Ubuntu MATE on my 11 year old Macbook Air as a way of keeping it running, given that Apple are no longer supporting the device. My idea was to replace it with Linux, while preserving the look & feel of the Mac as much as possible.

Below are my notes of what I needed to do. The exact model is MacBookAir6,2 (MacBook Air (13-inch, Early 2014)), but I think the process should be pretty similar for other MacBooks made around the same time.

hi MATE

I settled on an Ubuntu variant because:

it's familiar to me
Canonical do a reasonable job at making things usable
it's easy to find help online.

I chose Ubuntu MATE¹ over basic Ubuntu, as I liked how you can configure MATE to look a lot like MacOS.

The install process

Installing linux on this device was much like installing it on any device, except for some issues with WiFi. I cobbled together these instructions from various blog posts such as this one and this one:

Before doing anything, back up your files.
Make a bootable USB stick with Linux on it.
Boot from the USB. The WiFi didn't work for me, but I fixed that later. The keyboard and trackpad worked fine. At this point I also tested that the SSD was detected ok.
Proceed with the install. I made the mistake of tethering to my phone at this stage, which caused the installer to fail part way through. But it worked fine when I switched off the wifi.
After booting into Linux, you need to tether to a phone via USB, then install the proprietary broadcom drivers so that you can connect to WiFi. Run sudo apt install broadcom-sta-common broadcom-sta-dkms then restart.
Run sudo apt install mbpfan to ensure the CPU fan works.
Run sudo apt install ubuntu-restricted-extras to install proprietary stuff.
Run sudo apt update && sudo apt upgrade to update all the packages.

Colour profiles

I didn't seem to need this for the laptop's display but if you have an external monitor you can optionally restore the colour profile from an .icc file.

Brightness buttons and backlights

On MacOS, the F5, F6 buttons affected screen brightness, but in MATE only the F1, F2 do screen brightness, and F5, F6 manage the keyboard backlight brightness. This confused me a lot but ultimately it all works.

Info from the Mactel team in 2015 mentioned needing a custom kernel module for the backlight but this is no longer accurate.

Don't set the acpi_backlight kernel parameter. I found some older info recommending setting this to video or something but this broke the brightness control for me. More info on backlight settings.

Webcam issue

The webcam didn't work out of the box. I got it working using by compiling the facetimehd kernel module.

Tweaking things

MATE comes with a tool called Mate Tweak. Under "Panel", select the Cupertino layout and enable the dock for a Mac-like experience.

Customise the dock in "Plank preferences". I made the icons bigger. If you want to get rid of an icon that doesn't have a "keep in dock" checkbox, you can click and drag it out of the dock to remove it.

You can change the colour scheme in the "Appearance" app. I switched to the dark variant of the MATE default theme.

In "Keyboard preferences", the layout should match your Locale, e.g. "English (UK)". The "Keyboard model" in my case is "MacBook/MacBook Pro (intl)". Minor annoyance: on UK MacBooks, the "#" is the third symbol on the "3" key. Normally to type it you use the left alt, but on Linux you have to use the right alt.

Also on the Layouts tab is an "Options..." button. This contains a lot of useful key remapping features. Under "Alt and Win behaviour" you can select "Ctrl is mapped to Win and the usual Ctrl". This is the best way I've found of making Mac-style Cmd+C, Cmd+V etc shortcuts work on Linux. Just bear in mind:

It will no longer be possible to type the "Super" key, which breaks some default shortcuts².
You can't use it for copying from a terminal, because Ctrl+C will still send the ^C byte to trigger a SIGINT. I configured Gnome terminal to use Ctrl+Shift+C (Cmd+Shift+C) for Copy, and Ctrl+V (Ctrl+Shift+V) for Paste³.

I also used "Ibus Preferences" to configure a second input method, and I use Ctrl + Space as the key to toggle them.

mDNS search domain issue

Out of the box I couldn't use shortnames to ssh to other machines on my local network, because the search domain was set to "home", where previously I was using "local".

I fixed this with resolvectl domain wlp3s0 local, where wlp3s0 is the interface name.

Linux touchpad drivers suck

The touchpad works out of the box, but the usability is rubbish compared to MacOS. Ubuntu MATE uses libinput, which has an intentionally limited feature set. It doesn't have "momentum scrolling" or smooth scrolling. The older Synaptics driver is a lot more configurable but it's no longer maintained. I haven't tried using it myself yet but I'm curious if it's worth tinkering with to get a better touchpad experience.

If your laptop is even lower spec than mine, you might consider the Xubuntu or Lubuntu flavours, which have much lower minimum requirements. ↩
If you want to keep one of the command keys as super, and map the other to control, you can instead use xmodmap to do the remapping, but this is very confusing to configure. ↩
I think it should be possible to remap the key combination that the terminal emulator uses for ^C (e.g. to Ctrl+Shift+C), but I couldn't find a way to do this in Gnome terminal. ↩

Some thoughts on when to use LLMs

Mat — Sun, 05 Jan 2025 18:58:17 +0000

As with any overhyped technology, I think it's wise to be a bit skeptical about claims made by companies pushing large language models (LLMs).

The eagerness to add AI to everything over the last couple of years reminds me of the hype around "big data" when that was a thing. The technology was useful, but teams were uncritically adopting them even if more established technologies would have been fine in their business context. There is definitely pressure to do the same with LLMs and AI in general, but as technologists we should consider what these things are actually good at and what they're not good at.

With that in mind, here are some observations from the sidelines, based on my personal usage of ChatGPT as a senior developer, how I've seen LLMs being misused, and my attempt to follow along with the general discourse.

Reasonable use cases

Speeding up work tasks

If you don't mind some manual review, LLMs are good at things like:

coming up with names for things
classifying items in a long list (example)
formatting data (e.g. converting to CSV/JSON, or different date formats)
data extraction from unstructured text (e.g. email addresses or URLs)
rephrasing or adjusting the tone of your writing

Code assistants

LLMs can be good for quick prototyping, providing you can understand the code they are generating. You will likely have better results if you split the task into very small steps and commit often. Perhaps consider using the Mikado method with the LLM.

If AI is generating the code, I believe you should write the unit tests yourself, so that you are forced to check its correctness.

Be careful not to use code assistant tools or paste non-public code into LLMs without your employer's (or the copyright holder's) permission.

I think code assistants are a bad idea for learning new frameworks and libraries, for several reasons:

it discourages you from reading the docs and forming a good mental model of how the thing works
it's not always smart enough to fix bugs for you or explain why your code isn't working
you can't recognise when the coding style is outdated or there is simpler way of doing things

I think refactoring is best done by hand unless you want to apply a single refactoring many times across a large codebase. AI generated refactorings are not safe and need checking for correctness.

Retrieval-augmented generation (RAG)

A RAG is a multi-step process that first uses word vectors to fetch content from a knowledge base, and then feeds it to an LLM to answer a user's question. For question answering, I'd expect this to outperform traditional search in cases where information is scattered amongst a lot of similar looking documents, for example slack messages or helpdesk tickets. It only really makes sense if your knowledge base is large enough that it would be costly for a technical writer to trawl and summarise.

I'm a bit skeptical of building such systems in-house though - as opposed to something like RunLLM - it feels like this effort would be better invested in improving your own product/service or its documentation.

Questionable use cases

LLMs are not oracles

LLMs are not good at:

doing research for you
communicating factual information
weighing up evidence

It is nonsense to ask an LLM for opinions on ideas, because LLMs can support any position depending on their prompt and context.

Building user-facing services on top of LLMs is risky

LLMs are costly to train and run due to the amount of compute required. This has a high energy cost, to the point that big tech companies have walked back their commitments to carbon neutrality in order to expand data centres. I wouldn't be surprised if companies hike up prices as the technology matures.
LLM outputs cannot be trusted to be free of copyrighted or sensitive data without more transparency over how they were trained
Allowing LLMs to act as "agents" is open to abuse from prompt injection attacks, and they can be misled by untrustworthy information
LLMs will happily lie to customers
It might be possible for AI to perform more complex reasoning by chaining many LLM operations, but I think this is unproven and expensive at this point(?)

A quick way to run axe-core from python

Mat — Tue, 13 Feb 2024 19:13:05 +0000

I used this code snippet today to run axe-core from a python selenium test. It calls out to the command line interface, using npx so I don't have to worry about managing node packages:

    def check_for_accessibility_issues(self):
        command = ["npx", "@axe-core/cli", "-q", self.selenium.current_url]
        output = subprocess.run(command, capture_output=True, text=True)
        self.assertEqual(output.returncode, 0, output.stdout)

This should work with anything that runs your app in a browser, not just selenium.

Axe is an automated tool to detect some (but not all) web accessibility issues. It's not a substitute for actual usability testing with real people, but it's still useful. For a rough idea of what it can do, check out this blog post: Axe-Core vs PA11y. In the author's testing, axe-core detected 27% of known issues on a test page.

I was originally hoping to use axe-selenium-python for this. It uses selenium's execute_script to inject the axe javascript into the page, similar to this method. Unfortunately, axe-selenium-python has been unmaintained since its author left mozilla. It looks like some nice people are going to take this over, but I wanted a workaround in the meantime.

Note: There is also Deque DevTools, which appears to have python bindings, but this is not open source. 😞

How to avoid meetings and take a day off

Mat — Sun, 07 May 2023 09:36:17 +0000

Recently I've been experimenting with recording videos to asynchronously relay information to my team, instead of waiting for a meeting.

The videos I've made have been really well received by my team, and I've also appreciated when other coworkers have done this for my benefit. We tend to use it when we have been investigating problems by ourselves, and need to present information back to the rest of the team. Anything that can be presented in a real time meeting or video call can be recorded as a video instead.

Async video vs live meetings

The main disadvantage of async video is you can't respond to feedback right away and adapt the content to the audience on the fly. So for it to be useful you need a good understanding of what your audience need to know.

That said, async provides a lot of flexibility:

when you are working part time, it's a way to check in with your team when you're not working
when you have leave coming up, it can function as a handover
if the team have different schedules, it can be quicker than finding a time when everyone can meet
team members know up front how long it will take to watch and can watch at a time that suits them

If you have a lot of information to present, you can chunk up the content into smaller videos. If not all of the information is relevant to the whole team, then you can target videos to different audiences and tell the team to skip any they don't need to watch.

Video vs text

Another alternative to video is preparing written documentation. Sometimes this is more appropriate, but I think video has a number of advantages:

it's likely to be less formal and easier for people to consume
it's multi-sensory: you can show things at the same time as talking about them
it's sometimes quicker to produce or just fits the content better, e.g. when demoing a product feature

You can always combine the two by providing slides or written notes alongside the video. I recently prepared a quick presentation in markdown, presented it via the Obsidian slides plugin and then shared the raw markdown alongside the video recording.

How to record video

Loom is a tool that is built for this, but they limit the number of recordings and video length unless you pay for a license.

Another option is to join a video call with just yourself, and record it. This gives you much of the same functionality as loom, but it's a bit fiddly if you want to restart the recording. I've done this with Zoom, but I think Google Hangouts or other tools would work equally well.

I like this solution because it comes with automatically generated subtitles. This doesn't work perfectly, but it makes the content more accessible for anyone who is hard of hearing or doesn't speak english as a native language. When I post one of these recordings into slack, it also generates a transcript, allowing people to skim the talk or jump ahead.

If you are using a mac you can also record your screen in quicktime.

8 tips to make code reviews less painful

Mat — Fri, 03 Feb 2023 15:01:46 +0000

Teams use code review in different ways, and your experience may vary depending on who is doing the code review, but there are always things you can do as an author to make the process go more smoothly.

When submitting changes for review, you should try to reduce the cognitive load on the reviewer. As an author you have spent way more time thinking about the problem than the reviewer will, so what is easy to read for you isn't necessarily easy for them.

Why it matters

It's always tempting to take shortcuts and throw something up for review quickly, but I think it's always worth pausing first and considering what we are demanding of our teammates. Bear in mind people don't operate at 100% all the time. Your reviewer may be having a bad day, they may be tired or sick, they may be context switching between different tasks. Make their lives easier.

Complex pull requests are also slower to resolve. At best, you have to wait ages for feedback (which is frustrating if you want to move onto new tasks), at worst, the reviewer focuses on surface level details, rather than giving you feedback that is actually useful (e.g. about the correctness of the solution, or maintainability).

If your team follows Github Flow, or similar workflows where reviews block merging, then the longer reviews take, the less frequently work is integrated, the more unfinished work is hanging around. In my experience this leads to extra work in the form of conflicts, deployment issues, and coordination between engineers. By doing a bit of extra work up front, you can avoid extra work later on.

Tip 1: Start with small commits

Development can be messy, and the code we start with is not necessarily the code we end up with when we are ready to push our changes. But it's easier to combine lots of smaller commits later than it is to break apart big ones, so commit early and often.

Capture your reasoning as you go. You can include

any assumptions you're making
anything you've learned about the code since the previous commit
things you've thought about but not changed

This is stuff you will forget if you don't write it down.

You can rewrite these messages before you push the code, so it's better to overexplain than leave something out and then forget about it.

Passing a -p (or --patch) flag to git add is really helpful. It breaks your changes into "hunks" and you type y or n after each one to choose what gets staged. That way you can create more than one commit even if you've changed multiple things since your last commit.

Tip 2: Learn how to rewrite your git history

When you're committing as you go, you might end up with a
simple sequence of commits where each commit builds on the previous one. This is great, because the reviewer can look over the work commit-by-commit, focusing on one thing at a time. Essentially, your commits tell a story.

If you're working on something complicated, your commits will probably be messier than this, but that's fine if you rewrite the git history before sharing. This way, reviewers don't need to relive the whole journey you took to arrive at the solution.

I regularly use some combination of:

rebase to remove conflicts with the main branch
interactive rebase to squash many commits into one or edit commit messages
cherry-pick to pick out commits I care about into a fresh branch which can be reviewed separately
reset to completely redo some commits while keeping the code I have in my working tree

These commands can be pretty confusing, but they are worth learning, and you can undo almost anything in git if it goes wrong.

Tip 3: Squash commits that don't provide new information

Similar kinds of changes can be squashed together before sharing for review (see above). You might do the work in stages - so you have lots of checkpoints to rollback to - but then present it as one logical step in the PR. This makes it much easier for the reviewer to check that the change was done consistently across the codebase.

Prefer commits that are small in scope but "complete". If you are aiming to write tested, documented code, then the perfect commit might contain implementation, tests, and documentation.

Don't push code where you try something in one commit and then undo it in another. This is confusing: it adds noise to the commit history that makes it harder to review the individual commits in your PR. Each commit should make sense on its own.

I deal with these problems using an interactive rebase:

git rebase -i <commit you branched from>

This asks you what to do with each commit on branch. squash combines it with the previous commit, drop removes it entirely, edit lets you amend the commit (which you can use to change the commit message).
Imagine you were doing the work from scratch - which steps would you take? If you make the existing commits match those steps then somebody else should be able to follow along.

Tip 4: Stop when you have something useful and deployable

The more changes you have on a branch, the riskier it is to deploy and the longer it takes to review.

If your branch gets out of control, look for any commit part way through that is deployable. Make that your pull request, get it reviewed and deployed, and then come back to the following commits once that it is merged.

git checkout -b <new-branch>
git reset --hard <deployable-commit>

This can feel slower, because you're waiting for things to happen before doing the next part, but it's actually faster. You can get code into production earlier, reviews happen quicker, and if something goes wrong you can fix it quicker.

You may find that if some refactoring was done first, then the rest of the pull request would be simpler to understand. In that case, you can raise one PR for the refactoring, and then redo the original PR. That way, the first review only needs to consider whether the code functions the same as before, and the second review only needs consider the impact of the new change.

Tip 5: Review and edit your commit messages

The commit message should help reviewers review your code quickly.

Reviewers need to

understand what has changed
understand the bigger picture of what your change enables
follow your thought process

So provide this information in an easy to digest form.

When code is presented without context, the reader has to rediscover the context themselves and make assumptions about what you were trying to do (which could be wrong and waste time).

If you reference an older commit, include the commit hash. Then anyone can find the commit using the CLI, and it will be hyperlinked in github.

If the work was prompted by a ticket, link to the ticket. But it's worth also including a summary of what you are trying to achieve, so that people looking at the repo in the future can still understand your code, even if the ticketing software is no longer used.

If you fixed a bug, link to any external information you used to understand the problem, e.g. manual pages or CVEs.

Tip 6: Keep pull request descriptions short and to the point

If the commit messages are detailed, then your pull request description can be a short summary or introduction, to give the reviewer a basic understanding of what you set out to do and why before they dive into the details.

Other things you can include in a PR description:

A discussion of the problem you are solving and how chose to approach it
Specific questions for the reviewer, or areas you want to highlight
A discussion of trade-offs you made
Screenshots for any UI changes

The pull request is for the team right now, whereas the commit messages are part of a permanent record that your future self/team can refer back to.

Tip 7: Refactor code to eliminate confusion

If something is unclear to the reviewer, use the opportunity to make it clearer, for example by:

improving how you name things
splitting or inlining code
improving commit messages
adding comments to the code

Tip 8: Don't bite off more than you can chew

If you're starting something complicated, consider treating it as a spike and then redo it from scratch once you know how you want to implement it. I like this approach because the whole team understands that the work is experimental and can be abandoned if it's not going to be worth the effort to continue.

It's ok to throw everything away and start again, building on what you've learned about the problem so far.

How to break up a rails monolith

Mat — Fri, 20 Jan 2023 18:17:39 +0000

My last couple of jobs have both been with companies that were struggling with complex rails applications. There was nothing fundamentally wrong with the technology choices, the software had just organically become difficult to work with.

In this kind of an environment, engineers are unhappy with the technical debt, product are unhappy with the slow delivery. But it's not easy to fix.

There is a temptation to start over with a big rewrite, but rewrites take ages, and divert resources away from improving the user experience.

These are some notes I've gathered about improving the structure of these rails applications without rebuilding the system from scratch or spinning up new infrastructure.

Context

your rails app is turning into a big ball of mud
you need to think about everything to change anything
it's hard to understand what the intended structure is supposed to be.

Goals

reduce cognitive load on engineers
enable teams to work autonomously and take ownership of components
this might be a preparation step for rebuilding functionality or extracting separate services

Enter the modular monolith

Modular monoliths are applications that are deployed as one service but whose code is split into loosely coupled components. This allows you to reduce levels of coupling at coding time, without having to change runtime behaviour, infrastructure etc.

Domain driven design helps establish boundaries

You can start introducing new structure by modelling the different business contexts and reflecting that in your code. Each context comes with its own special terminology. If you get together with domain experts, you can agree shared terms (a.k.a a ubiquitous language) and a shared model that both the software engineers and the domain experts understand. You can then use this to decide where to split the application.

Decide where to start

If you are starting from a monolith, then you can gradually evolve the system towards a modular monolith by

organising code into logical components or packages
strengthening boundaries and decoupling the components from each other

There are different ways of going about this.

Option 1: Depth first

One way is to pick out one or two candidate components to focus on, follow the steps below to decouple them from the rest of the application, and then continue component-by-component.

The advantage of this option is it doesn't require a huge up-front commitment, and you can earn buy-in from stakeholders over time. A small number of people can work on it and then present the results to the rest of the engineering team. You then have good examples for other engineers and teams to follow.

Option 2: Breadth first

An alternative is to do a very rough pass over the whole codebase, that introduces the desired structure, but accepts that the interfaces are poor and components are still tightly coupled together. You then refine the components.

The advantage of this approach is that engineers can start to benefit straight away from code being easier to navigate. But there's a risk that you never finish the work. You can mitigate this by implementing tooling to inform engineers of issues that need to be corrected, and showing them why it is important.

Steps to introduce a component

Move the existing code, including models
Establish a public API for the component
Make sure all calls to the component use the public API
Introduce an "anti-corruption layer"
1. Introduce value objects for the component
2. The anti-corruption layer transforms from ActiveRecord models into value objects of the component
3. The public API can now be changed to accept and return value objects, not ActiveRecord models
4. Prevent outside code from instantiating component models directly
Modify calling code so you no longer need the anti-corruption layer (by using the modified, ActiveRecord-free API directly)
Remove associations between component models and outside models
- If you depend on data outside of the component, then access it through a method call that returns a value object (avoid ActiveRecord)
- Remove foreign keys that cross the component boundary
- Prefer polymorphic associations for linkages to things outside of the component. This inverts the dependency
- (optional) This isolation can be enforced by migrating data to a separate schema
Remove cyclical dependencies between components (Acyclic dependencies principle)

Useful tools

https://github.com/Shopify/packwerk allows you to make dependencies between components explicit
Rails engines are another way of organising a rails app into components

Additional resources on this topic

Starting my new job NOT in lockdown

Mat — Tue, 12 Jul 2022 18:49:43 +0000

Last time I started a new job, everything was on fire and I unexpectedly became a remote worker. And it was fine (eventually). I kept working from home and I didn't actually meet most of my coworkers until my very last day when the tech team in London met for a picnic.

Since I am very bothered by loud noise, having my own space makes it a LOT easier to focus on my work and be productive, without feeling completely exhausted at the end of the day. Not having to commute 2 hours a day and being able to take short breaks to cook, clean, take a walk or answer phone calls massively improves my quality of life.

(Elon Musk can go fuck himself)

So this time, I made the deliberate decision to look for a company that supported full remote working, and I knew a little of what to expect. I am also continuing to work part time (4 days a week). I started this arrangement in my previous role and it has helped a lot with my mood and anxiety levels. It gives me extra time to unwind and I can use the extra time for study or travel. Currently this is worth more to me than 20% of my salary.

The onboarding process here was ok but not as good as my previous job. I initially felt very overwhelmed with information - it's an unfamiliar industry and I'm having to do a lot of intros with different parts of the business. There seems to have been a lot of turnover, just like my previous company, which is challenging for figuring out what's going on and how to get stuff done.

The nice thing is that technically they are in the process of transitioning to microservices, and they are quite well set up for this, having leaned into Domain-Driven Design and with engineering management starting to think about the structures needed for teams to work autonomously without pulling in different directions. This is very interesting to me and is a nice continuation of the work I was doing in my previous company to break apart a large monolith by establishing bounded contexts.

My team are working on authorization, so I have a well defined problem area to work within but I will also get to interact with a lot of other teams since authorization affects the whole platform.

Two weeks in I am starting to get the hang of things and have picked up a couple of tickets. I always find it a bit of a shock going from quite high understanding of a codebase to zero understanding, but it's helped to slow down a bit and dig into the codebase. This week I realised I didn't fully understand the data model I was working with so I spent some time creating an entity relationship diagram in mermaid and figuring out all the constraints (this is now built into github and gists!). I feel like there is a lot of pressure to pair a lot when onboarding, but going through this process by myself helped make things click for me in a way that I don't get from just pairing.

Get linux samba shares to show up in windows again

Mat — Fri, 17 Jun 2022 08:45:55 +0000

I have a media server that runs ubuntu, and today I wanted to copy some files off of it from my windows laptop. But the samba shares weren't showing up in file explorer (but they showed up on fine on my macbook).

I thought the whole point of Samba was compatibility with windows, so I was confused why this doesn't work now.

After a bit of googling, it seems like this compatibility might have stopped working after the 2017 wannacry vulnerability was discovered.

In the past windows used a broadcast protocol called NetBIOS for discovering samba shares. When windows removed support for earlier versions of the SMB protocol (vulnerable to wannacry) they also switched off this discovery mechanism.

Apparently WINS is another mechanism for discovering network shares, and you can configure samba to use it, but it's a bit shit as it requires you to set up a separate server that resolves names to hosts on the network (a bit like DNS).

The solution I found was to use a newer protocol called "WS-Discovery" (WSD).

This is not built into samba, but there is an open source package you can use called wsdd. I followed the ubuntu/debian installation instructions and then ran it with wsdd -v. My samba share instantly appeared on the windows machine.

I don't know if this is the best long term solution, but as a quick fix to let me copy some files, it worked!

Please stop using ||= all the time

Mat — Mon, 18 Apr 2022 18:17:08 +0000

In ruby code I often see people writing code like

def foo
    @foo ||= 'bla bla bla'
end

Instead of

def initialize
    @foo = 'bla bla bla'
end

attr_reader :foo

The duck operator ||= is used to lazily initialize the instance variable, instead of initializing the instance variable in the initialize method.

This is possible in ruby because assignments are also expressions, and all methods have an implicit return value. So @foo ||= 123 always evaluates to 123 but never assigns to @foo more than once.

While this is very concise, I found it odd when I first came to ruby after coding in other languages. It feels like a very roundabout way of doing things. If you are initializing instance variables why not use the initializer?

The lazy initialization pattern is one way to avoid running an expensive computation that might not be needed. However, if you know that the initialization is always going to be required for the object to be usable, then there are no performance benefits to structuring it this way.

Structuring code like this makes dependencies a bit harder to notice just from looking at the class. Users of the class might be misled into thinking that the object is fully initialized when it is not, and this can make it harder to initialize objects in a test or in other parts of the codebase.

In practice, I get suspicious even when the initialization is optional, because the optional initialization is still separate from the initializer and so it is less obvious when reading the code. Optional behaviour can also be sign that the class has more than one responsibility.

You can always refactor the class to avoid this. For example, consider using dependency injection to depend on the result of the computation instead of doing the computation internally.

def initialize(foo: nil)
    @foo = foo
end

# ...
# methods that use `foo`
# ...

private

attr_reader :foo

Lazy initialization is a special case of temporal coupling: the behaviour of the class is allowed to vary depending on what order you call its methods in. The more complex the behaviour, the harder it is to reason about the code and the easier it is to introduce bugs. In this case, if other methods of your class depend on the instance variable, then they could read nil if the initializer method isn't called first.

Side note: I see this problem a lot with rails controllers, which do not get initialized on a per-request basis, and force you to set instance variables within your action methods as a way to communicate with the view. This design is unfortunate, but you can still avoid the problem elsewhere in your codebase.

On the other hand, if all the initialization for the class is handled by the initialize method, it's quite easy to make the behaviour of the class predictable. You can use command-query responsibility segregation (CQRS) to ensure that messages you send to the object either ask for information, or change the objects state, but not both.

Photo by Francesco Altamura from Pexels

Turn Windows into a usable development environment with WSL

Mat — Sat, 12 Dec 2020 15:19:30 +0000

I recently set up a development environment on my windows computer, using Windows Subsystem for Linux (WSL).

This lets you effectively install a Linux OS on top of windows that works seamlessly with windows tools, and it's so much better than my previous experience of trying to develop on windows.

Basic setup

Install WSL
Install a tabbed terminal (Optional - I expect this will be fixed eventually, but the current default terminal is pretty useless)
Set up Visual Code to work with WSL
Install Docker into WSL

These steps will let you work with Visual Code and terminals, and things will mostly just work as if you were actually working on Linux.

You can also run any Docker command from within WSL (after running apt install docker) and it will use the Docker daemon provided by Docker for Windows.

(Optional) Configure the tabbed terminal

The terminal is a bit fiddly to configure as it requires editing a JSON file. You can open it by pressing CTRL+,

The profile settings look like this:

{
    "guid": "{2c4de342-38b7-51cf-b940-2309a097f518}",
    "hidden": false,
    "name": "Ubuntu",
    "source": "Windows.Terminal.Wsl",
    "colorScheme": "One Half Dark",
    "fontSize": 15
},

At a minimum I would recommend changing the color scheme. Even after swapping out the terminal app, I found the default colors hard to read against a dark background.

For more info about the options you can refer to the Windows Terminal documentation.

WSL is pretty cool

So far I've been really impressed with how well this all works.

If you want to know more about WSL, I recommend this Hanselminutes podcast: Inside Linux on Windows with WSL and Tara Raj

Windows 10 runs Linux natively! How is that possible? Scott talks to Microsoft's Tara Raj, the Program Manager for the Windows Subsystem for Linux. How does this technology work? Tara explains the internals of WSL to Scott in this episode.

Please stop saying agile all the time

Mat — Tue, 10 Nov 2020 13:34:59 +0000

I try and avoid the word "agile". It gets used too much as a buzzword (by consulting companies and tech leaders) or as a euphemism for "whatever we're currently doing, but faster."

At best, it's a vague, useless term, and at worst it can shut down valuable conversations.

Agile Methodologies != Agile

People talk about agile methodologies and frameworks - SCRUM, Kanban etc. But regardless of how useful these things are, they are not really the spirit of "agile". They are just ways to organise teams that come with some "agile" baked in. Kind of like how Ruby on Rails isn't the same as "a well built web app", but having a framework can make it a lot easier to get started (providing you know what you're doing).

Just like developers can still build shitty rails apps, managers can implement half-arsed agile without really embracing the mindset.

The good stuff behind agile

If we're going to pick a meaning of "agile", we could do worse than look at the agile manifesto, which proposed the idea in the first place.

The writers of this manifesto came up with 12 principles.

The agile principles

Our highest priority is to satisfy the customer through early and continuous delivery of valuable software
Welcome changing requirements, even late in development
Deliver working software frequently
Business people and developers must work together daily throughout the project
Give team members the environment and support they need, and trust them to get the job done
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation. (IMO, this one is less important now we have better tools for remote working)
Working software is the primary measure of progress
The sponsors, developers, and users should be able to maintain a constant pace indefinitely
Continuous attention to technical excellence and good design enhances agility
Simplicity–the art of maximizing the amount of work not done–is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly

The agile principles stand on their own

Each of these principles is clear and objective.

As a team you should be able to reflect on any of them and ask "are we really doing this?"

If you really value early and continuous delivery of valuable software, you should expect to be prioritising work based on value to the customer. If not, then why not? This is a far more interesting and productive conversation than simply "are we agile?"

If you value delivering working software frequently, alarm bells should be ringing if there are long delays between writing and testing code, or if deploying code to production is too scary to do every day.

If you value simplicity, you should be able to challenge scope creep. If you value technical excellence, then you should have things like code review, tests, linters etc. which enforce a standard.

If working software is really the primary measure of progress, you should spend time measuring how well your software is actually working for the people that use it! If the things you measure and reward just relate to inputs, like velocity, tickets completed, or lines of code written, then you probably don't value working software as much as you think.

This is still relevant

This was written in 2001, but for the most part it's still very relevant today.

Ron Jeffries said in 2010 that the agile manifesto states an ideal, and the industry has fallen short of it. I agree - we should be able to do better.

Ultimately, it doesn't matter what you call things, you can implement any of this advice to your own team with or without calling it "agile", and doing some of these things is still better than doing none of it.

How to make a comfortable face mask

Mat — Sat, 29 Aug 2020 16:33:48 +0000

So I decided to learn to sew my own face masks. It's been a good project to take my mind off the apocalypse.

When I first started I had never used a sewing machine before, but I learned a lot through trying stuff out and starting with something simple. This is a good way to learn things!

5 Patterns of Varying Difficulty

So far I've just been focusing on making masks for myself that fit well, since better fitting masks are a) more comfortable
and b) more effective. I've experimented with various different ways of making masks, and I've now tried 5 different patterns.

Rectangle

How to sew a rectangular face mask

For the very first mask I used a simple rectangle pattern, because that meant I only had to sew straight lines. This worked surprisingly well, but it wasn't that comfortable because the fabric bunches up.

Although I didn't make more of these, it's easy to sew (I was still figuring out how my machine worked when making it) and all the stitches are on the inside of the two layers so it doesn't matter if it's messy. My biggest mistake was mismatching the grain of the 2 fabric layers, and then sewing the nose wire to the wrong side so the visible design ended up upside down. Whoops.

Pleated (I)

How to sew a pleated face mask

The pleated pattern is the same as the rectangle one, but it allows the mask to be shaped to the face instead of laying flat against the mouth. In practice, I found this quite tricky to make and my sewing was very messy. I made some mistakes sewing the pleats. The end result didn't fit very well and I only wore it once. I didn't use a nose wire with this one which also didn't help. Although the mask wasn't very good, it taught me a new technique (adding pleats), and it prompted me to get a seam ripper to fix all my mistakes.

Duckbill

How to sew a duckbill style face mask

I see people wearing masks like this a lot. Each layer is made from 2 pieces of fabric stitched together in the middle. This is harder to sew because of the curves and it's fiddly to sew the layers together. It seems like with these masks it's harder to get a good fit, and I made a few of these while trying to adjust the size for my face. I found that if the straps weren't pulled tight there were a lot of gaps around the mask, and it was a lot more comfortable with a behind the head strap. By making more of these masks I got better at using my machine and I also learned how to adjust patterns.

Boat shape

How to sew a boat shaped face mask

With this pattern there is a piece of the mask that is flat against the mouth, and then there are bits above and below it that go over the nose and chin. I found this fit me a lot better than the duckbill style pattern, and it's my favourite pattern overall, although it's not so great for talking because it doesn't leave room around the mouth or stretch vertically.

This pattern doesn't need to use curved lines but I still found it very tricky because you need to fold parts of the mask a certain way, which broke my brain a bit.

Pleated (II)

How to make a pleated face mask (hybrid pattern)

This one is similar to the first pleated pattern I tried, but part of the mask folds backwards to fit over the nose. I found this one reasonably comfortable but it left some gaps at the top of the mask. I'll probably make some more of these.

Materials

For all the masks I've made so far I've used 2 layers of cotton. I've mostly got this from Spoonflower.com which lets you select from lots of custom designs people have contributed. This has motivated me to learn Adobe illustrator so I can try creating my own design as well.

Some of the patterns have an optional pocket to put a filter in, but I skipped this, since I didn't have anything to put in it at the time. I've since found you can buy filters for masks on amazon though.

The instructions for the duckbill style mask mention that you could add some interfacing material to the fabric to make it hold it's shape better. This is material you iron on, and it makes the fabric thicker, like a shirt collar. I tried this a couple of times because some of the early masks I made deformed quite a lot when I breathed in and out. However, the thicker fabric makes it a bit harder to breathe through and I had better results changing the sewing pattern instead of the material.

There is a study by Abhiteja Konda et al which compares how effective different materials are at filtering droplets and suggests that some lighter fabrics can be as effective as quilter's cotton. Apparently you can create really comfortable masks out of a material called "stretch chiffon", which is made of silk and lycra, but I haven't tried this yet.

Nose wire

I found that the nose wire is essential for getting a good fit, but the wire should be quite flexible so it fits around the nose rather than digging into it.

Originally I was using some bits of electrical wire I had lying around. I also bought some wire strips that you can stick to the outside of masks, but I found them to be too stiff, and they look pretty ugly.

The wire I'm using now is 20 gauge floristry wire. The higher the gauge the thinner/more flexible it is.

Most of the patterns that feature a nose wire have you stitch the wire in place, but this means you can never replace it. The pleated pattern is nice because it leaves a little channel for you to insert the nose wire into at the end.

Straps

Some patterns have you sew a piece of extra fabric around either side to thread the straps through, but when I've used bias tape it's turned out much neater. I think the masks I've made this way are less likely to fall apart.

For all the masks I've made the straps are replaceable. I originally made ear straps, but I this makes the masks really uncomfortable to wear for extended periods of time, and you have to make sure that both straps are more or less the same length.

The alternative is to create straps that go behind the head, which is simpler and more comfortable. To make this I thread 50cm piece of elastic through both sides, instead of a shorter piece on either side.

So far I've just been tying knots to create a loop in the straps, but ideally I'd like to make them adjustable as well. I bought some toggles (like you get on drawstrings) that can be used to make an adjustable head strap, but they are a bit bulky. I think there is probably a way to make some kind of adjustable knot without using a fastener like this but I don't know how to do that yet (I'll update this post if I figure it out).