Technology articles from code to teams to organisational transformation by Luke Morton.
Introducing trunk-based development and it's relationship to the widely used practice continuous integration. If you do continuous integration, you should be doing trunk-based development.
In which I ask questions about the ways that a team might approach Clean Architecture in a way you can still benefit from the productivity of a framework.
On the reasoning why and how you might use a Clean Architecture approach in Rails applications. Warning: it's nuanced and full of compromise.
In which I try to untangle the differences in Clean Architecture implementations.
On the trouble you can encounter when trying to separate your domain logic from a framework like Rails.
On building lightweight Docker images for Go applications.
A walkthrough on how to use Docker to deploy a Go app on Zeit's Now realtime global deployment platform.
On structuring Rails apps for growth. Often a tricky area this article will walk you through a refactor and hopefully you'll walk away with a few more ideas for structuring your business logic.
A story of fight over flight. Or how doing the things you're uncomfortable with can help you in the long run.
In which I outline a strategy for Feature testing with rspec and capybara.
In which I provide a few links to help scale the M in MVC, the ActiveRecord in rails.
Where I explain what I've been up to.
An explanation as to why I don't like more than one public method per class.
That's right. It's time to leave your frameworks behind you.
Introducing the Interaction, Data and View design pattern.
Some thoughts on application interaction. This is your application logic and controllers.
Some thoughts on the data triad. That is mappers, models and actions.
Some thoughts on the view triad. That is templates, models and template engines.
This is my take on using hashes to transfer data between behaviour. You might know hashes as maps or associative arrays.
This is my take on data and behaviour. The two intertwinning components that make our programs.
This is my take on the single responsibility principle and how we can take it further.
Feel free to go home now here.