Posts
We all know the ritual. You finish a batch of changes, run git add, type git commit, and then… you stare at the blank terminal. Fifty characters to summarise hours of work. Then a longer description that nobody will read. If you follow conventional commits, there’s the added overhead of picking the right type prefix: feat:, fix:, docs:, refactor:, etc.
Let’s be honest. Most of the time I just write “fix stuff” and hit enter.
We all remember AJAX (Asynchronous JavaScript and XML). I’ve spent many hours and many days creating XMLHttpRequest objects and using jQuery’s .get and .post methods to connect HTML to a PHP backend to achieve that true “no full page load” magic. That’s still possible today… It’s also even simpler with HTMX, a small library that makes HTML dynamic. At its most basic, HTMX queries endpoints and updates HTML elements with the returned content (usually text or HTML).
Software development is dead. We’ve all heard it. But is it true? My opinion is that it depends on how you define software development.
If for you software development means sitting down with Vim or Visual Studio Code and writing APIs from scratch with ExpressJS, then yes, it’s dead. AI can do that. Better? Unlikely, but just as good as you. Faster? Way faster than you.
Today, you tell an AI tool that you need an API to query and manage customer profiles.
Ever since I started looking for work, something has become extremely clear – while I am familiar with the practical aspects of software design and development, a lot of the theoretical patterns are beyond fuzzy.
To address this, I have gone back to studying some of the basic design patterns and principles, starting with SOLID, which came to light in the early 2000s.
Single Responsibility Principle The first of these five software design principles is the “Single Responsibility Principle”.
$ rsync -a --delete --info=NAME <path to blog subdir in Obsidian vault> <path to hugo-managed site>/content/posts/ $ cd <hugo-managed site> $ hugo $ git add . $ git commit -m "<Commit Message>" $ git push $ git subtree split --prefix public -b public_site $ git push origin public_site:public_site --force $ git branch -D public_site
Handling MySQL Connections in TypeScript: The Good, the Bad, and the “Too Many Connections” Error When building a TypeScript application that talks to MySQL, how you manage database connections matters more than it might initially appear. A seemingly harmless pattern can quietly work its way into production and, under load, bring your application down with the dreaded:
Error: Too many connections
In this post, we will look at a bad but common approach to handling MySQL connections, why it causes problems, and then contrast it with a simple, effective approach that leverages ES modules and the Singleton pattern—without classes.
Hello and welcome to my personal blog! My name is Martin Lefebvre, and I’m a full-stack software developer with a passion for technology that has spanned over two decades. With 20 years in software development and 30 years of experience with Linux, I’ve had a front-row seat to the incredible evolution of our industry. This blog is where I’ll be sharing my insights, experiences, and thoughts on the ever-changing world of tech.
Dependencies What an entity depends on to perform it’s tasks.
Example: A bus carries students to and from school. Each student is assigned a seat on a dedicated bus route.
Each student depends on the bus to get to and from school. So the bus is a dependency of the student.
The bus doesn’t need the students to do its thing (drive around)
Without dependency injection, two scenarios are possible:
Blog Writing Agent — Implementation Goal Create an opencode skill at ~/.config/opencode/skills/blog-writer/SKILL.md that produces blog posts indistinguishable from Martin’s writing style.
Steps Plan approved by user Create ~/.config/opencode/skills/blog-writer/SKILL.md — main skill definition Skill metadata (name, description, trigger conditions) Author persona section (full style guide distilled from 10 posts) Iterative workflow instructions (outline → draft, 2-pass) Front matter generation rules Tag inference rules Quality checklist for self-review before presenting Verify the skill is discoverable by opencode Test with a sample topic Review After implementation, the skill should be loadable via skill tool and produce posts matching the analyzed voice, structure, and habits.