thoughts and inspiration on designing, programming, and writing for the web
This blog's design has remained roughly the same the past two years. I tweaked the style a lot, but changes were incremental and stay true to the neutral black and white style. Codebases rot over time, and small changes slowly but surely introduce technical debt. I started cleaning house, and before I knew it I was embarked in a full redesign.
I shiver at the sight of a function packed with too-many-to-read-at-a-glance arguments without a description.
A few weeks ago a spec change for an application we're working on forced us to refactor part of the codebase. It was food for thought about the flexibility granular interfaces provide, and choosing the right abstraction at the right time. This is a short writeup on the thought process we went through as we updated our logic to support a new feature now and allow more options in the future.
How to write HTML in Hugo without losing markdown capabilities.
Sometimes you want to store data in your Alpine component without wrapping it in a JavaScript proxy (which is how Alpine keeps everything reactive).
For example, third party libraries might have issues when wrapped in a proxy. Chart.js is one of those. If you store a Chart.js instance in Alpine data, the chart will error.
Laravel 9 is fresh out the door, and it contains a small contribution of mine: a new callOnce method for database seeders.
An overview on view models in Laravel
The other day I needed to sort a dataset in MySQL and ensure one value was always at the end. I never fully understood how order by works, so I did some research on how to solve my problem and how order by behaves.
I use Model::findOrFail a lot in Laravel. Recently, I realized it's not always the best option.
I want to talk about something I've been chewing on for a while: the monetization trap.
I've been thinking a lot about work-life balance lately. I used to see it as a balancing scale that should remain on the same position at all times. However, I believe a better mental model is to see it as ebb and flow.
Backlinks, or bi-directional liks, are becoming table-stakes for productivity apps since they've been popularized by Roam. It's a simple concept: when you create a link from page A to page B, page B will also reference page A. With traditional hyperlinks, page B wouldn't know about page A unless you explicitly link it back.
Backlinks allow a graph of knowledge to grow organically. When you create a doc for Orders, and mention Products, a Products page will be created or updated with a backlink. Even when not actively documenting Products, readers can get an idea of what they entail because of the linked references.
Sometimes you want to spin up a process, but the port it wants to bind to is already in use. Or a port isn't listening to a process as you expected. lsof is a debugging life saver in these situations.
In most projects, we use git flow to some extent — depending on the project and team size. This includes feature branches.
Feature branches (or sometimes called topic branches) are used to develop new features for the upcoming or a distant future release. When starting development of a feature, the target release in which this feature will be incorporated may well be unknown at that point. The essence of a feature branch is that it exists as long as the feature is in development, but will eventually be merged back into develop (to definitely add the new feature to the upcoming release) or discarded (in case of a disappointing experiment).
Working on a project with a lot of interdependencies between features with a bigger team comes with a new set of challenges dealing with git.
We've recently set up a new guideline: if it's not directly tied to your feature, don't put it in your feature branch.