Running this in nushell will give you an error like:

This happens because \ is not recognized as an escape character in Nushell.

The temporary workaround I found was to drop to zsh and run the command. But it was not an acceptable, long-term solution.

So here is a little snippet I found on Github to solve that issue. I added this to my config.nu file, in the keybindings array:

So now, I just paste the multiline snippet, hit control-enter and voilà!

All credits go to Rondimesquita

When I start working on a new ticket, I usually create a new revision for it, with the ticket number and description, along with a bookmark, like I described in my previous post.

The next step is to start planning my work ahead. And JuJutsu makes it easier by allowing me to split my ticket into multiple sub-tasks, each matched to its own revision. That way, I can start working on one sub-task, then the next one, and so on.

This is what it can look like in practice:

Keeping that habit is very useful because it forces me to think things through before I start coding. When working with an agent, it also gives it the context of the piece of work I am doing, and allows it to focus on the right sub-task, instead of trying to solve the whole ticket at once.

What often happens it that when editing a revision, I realize that I have to change something I had not anticipated in the previous one. In that case, I just go back to it and edit it. If that change is important and requires a lot of work, I usually create a new revision on top of the previous one, and squash it once I am happy with the result.

The icing on the JJ cake is that if those changes lead up to conflicts, they do not block me. I can follow my train of thought, and resolve the conflicts later, when I have more time / energy to devote to it.

Once everything is done, I can squash all the revisions into one, or keep a few of them as logical milestones in my work if I want to keep track of the progress I made.

I also use JuJutsu as my main VCS. I love it for the UX, the UI, and the commands.

Say what you want, I’m a tech romantic.

So let me share a little bit of NuJutsu love with those two small Nu functions I use daily at work:

On a side note, Elisp (is a (nightmare (of brackets (you) need to (follow through) (and count) (which (I suck at))))) — more on that in another post about programming language UX and why I love Ruby. But in the end, I can live with a few crashes here and there as I get lost in the bracket maze when editing my config.el. I can count.

That said, there is some friction involved when using Emacs. MacOS integration is not perfect, especially when it comes to managing the emacs daemon. I cannot make Dape (the DAP mode for emacs) work with ruby. I also find the UI to be a little slow: typing has a tiny slight delay which kind of gets annoying in a subtle way. And that slaps you in your face when you open Neovim.

I’m a TUI nerd, so Neovim is one of the alternatives I turn to when I get bored or annoyed at Emacs. Like Emacs with Doom, Neovim has the LazyVim configuration layer to ease most of that side of things. Lua has a much better UX than Elisp, and man, the whole beast is blazing fast, both in terms of loading time, overall snappiness, and typing rendering. Some plugins are really better than the Emacs stuff (thinking about vim-dadbod-ui — what a funky name, btw), some less (try to beat Vertico + Marginalia + Orderless). Debugging ruby stuff works out of the box.

I have made my Neovim as similar to my Doom emacs configuration as possible, so switching is close to seamless. But I miss a good integrated terminal experience - I am not very happy with how :terminal behaves, and it feels kind of odd to open a terminal inside an IDE which lives in a terminal. I am trying to find a way to overcome this, but for now, this is where some of the friction comes from.

This is usually when I open Zed.

(Well, sometimes, I will start a Helix session, get excited by the speed and simplicity, and then get frustrated for the lack of a plugin system — mainly for git/JJ, running tests and that stuff — read the 11-month-old release notes and related issue/PR threads, realize this is not going anywhere, and only then, open Zed.)

Zed is cool. It is like VScode stripped of the bloat and all the Microsoft cringe. It is sexy. Its development is moving fast. It features AI as a first-class citizen, but does not shove it up to your face without asking you first, and you can ignore it altogether. Zed respects its users by trying to serve them with a good product, not shove <paste the latest hype> junk down their throat to get ready for the next VC fund. At least for now.

Zed is not a TUI, but it is damn fast. I get all the snappiness of Neovim, along with most keybindings. I get a rich plugin ecosystem. But it is still somewhat limited compared to Emacs and Neovim — I am not blaming the Zed team, though, I am comparing a 4-year-old project to IDE veterans (considering Neovim and its ecosystem is built on the foundations of Vim).

Zed is currently lacking a Telescope-like picker (but it is coming), a merge tool, and a more capable plugin system to be able to connect to, and manage your database, for instance, or offer the possibility to manage Jujutsu natively (you can do some of that stuff with workarounds, mainly with tasks). But the main friction comes from the Vim keymap integration: it is good, but it is not available everywhere…​ like, you cannot do some stuff when in menu mode. So if you want a mouse-less experience, it just does not cut it.

So I launch Emacs…​ Emacs is where I feel at home, wearing my comfy slippers. I am editing the final draft of this post in Emacs right now, actually.

But that’s until I get frustrated again and decide to launch Neovim again…​

What is wrong with me? 🙄

What does this tool use, already? Is it Yarn? Make? Or framework-native commands? How do I launch a console? Update snapshots when I run the tests? Lint or format the code? I usually roam through the readme, or the Makefile, or whatever makes senses to get to the command I was looking for.

What if I had just one command to remember per action? One command that would be valid for every single project I am working with?

Mise allows you to define tasks globally, or locally in your mise.local.toml.

I have defined a set of basic mise tasks that cover most of my needs in most projects. In my global config, they default to my most common setup/language. For instance, mise run server will alias to bin/rails server, mise run test will alias to bundle exec rspec. This will be fine for most of my rails projects.

But some projects I work on use Minitest. So I will create a mise.local.toml in the root directory of that project and change the command to bundle exec test.

The front-end application server will also be configured locally to run yarn dev or whatever makes sense to that project.

The same goes for linting, formatting, building, or any other task.

The mise.local.toml file is globally git-ignored, so it is just my own sauce, and I am not bothering any of my co-workers with my private commands.

I have recently decided to re-focus on old creative activities I have somehow stopped doing over the years of becoming a father, a partner, changing career and more. These include music, electronics and writing.

I am starting this daily notes habit. I will write every day. Not each session will produce a note here, though. Some of my writings will go to this blog, but I hope to start another, more personal one quite soon. Some posts also will be deeper and longer, and require a few day’s work and research.

Another promise I made myself: I will NOT use AI. Neither for ideation, proof-reading, or rewording. Yes, the content I will produce will sometimes be clumsy or unclear, but it will be my content. It will be me. So please forgive me if my thoughts sometimes seem hard to follow — it is just who I am. I will be learning a lot in the process, and hopefully see improvements along the way.

I am currently just starting this series, and I hope I can stick to this effort for a long time.

I’ll keep you posted 😜 !

But lately, I must admit I felt the urge to make sure I did not read like one. Let me explain:

I am the kind of developer who loves clean code and knows the POODR book by heart in 7 languages (I don’t, but you get the idea). I always thoroughly document my code with Yard. I stick to TDD as much as I can. I try to write extensive commit messages and PR descriptions.

On the other hand, I love to try new, shiny things. I change patterns when I feel like it (my latest personal coding-style hype was inlining private keywords in ruby method definitions). My tests never look exactly the same. I am, in some ways, inconsistent.

When I code, I often go the extra mile and refactor stuff along the way, which makes my PRs a little fatter and less laser-focused than they should.

But lately, as I was writing a very detailed commit message, with lots of bullet points and em-dashes to make it extra-clear what my intent was, it occurred to me that all of these made me sound like a LLM. In fact, the whole thing I was about to ship could appear as vibe-coded — it was not.

What will the reviewers think of my work? What will they think of me? A vibe coder? No way.

Let me get this straight: I do use AI. But it is my pair programmer, my assistant, my rubber duck, my intern — with one caveat: I have to make my own coffee.

I am in charge. I code. I write tests.

So, for a moment, as I was proof-reading that commit message, I was tempted to add a few inconsistencies, remove the em-dashes and keep a few typos…​

I didn’t.

Screw it, I am not a robot.

So I have found a way to alter my git config based on the directory I am working from. All you need to do is add these lines to your ~/.gitconfig:

And edit .gitconfig-work:

I think this also applies to other git config values, so feel free to experiment!

I used to have this. I used to track every access to all of my posts on this blog. And sometimes often it was frustrating to see that some posts didn’t get the attention I thought they deserved — take that, hubris.

I used to write in order to reach an audience or increase my visibility on the internet for professional purposes or gain recognition in the Ruby community.

Now I don’t care.

I just write because I enjoy it. These posts are merely my thoughts, laid out in words. And…​ I don’t track my thoughts. I don’t copyright them or monetize them. Why would I do it here? This is my personal tech journal that just happens to be publicly available.

You may read this blog. You may not. You may subscribe to my RSS feed or follow me on social media. You may like what you read, some, or none of it. You may find my thoughts bland or outrageous. But you may not change them. I will not adapt to an audience based on what "works".

That’s also why there are no comments here either.

If you really want to start a conversation and interact with me, you can find me on Mastodon or Bluesky (or even LinkedIn — why not).

And you know what? Writing this way is freeing. I have absolutely no pressure, except for my own desire to write and make it a sane habit.

I obviously hope people enjoy reading this. But I firmly believe that my posts will be all the more interesting if I am not writing for anyone, except for myself.

Jujutsu is a version control system UX that builds upon multiple VCS backends (Git, Mercurial, Breezy…​). Jujutsu (or JJ) provides a user-facing abstraction that makes your git workflow much more flexible.

For instance, there is no such things as branches. The closest equivalent is bookmarks. But bookmarks are more akin to mutable git tags. Git commits belong to a branch, and move when the branch gets merged into another. JJ puts this the other way round: bookmarks behave the way you’d expect a bookmark to behave: they can be moved around revsets (the jj equivalent of git commits). This alone opens a wide range of possibilities.

One of the key difference with Git is that you do not have a staging area. Instead, you tend to use revsets as throwaway commits to keep track of your work in progress. You can then squash them, or move them around, or abandon them. You can come back to an earlier revision and edit it! It’s as simple as calling jj edit nf (nf being the shortcode of the revision you wish to edit) and go modify your code. No commit needed. The revision is edited as is.

No stashes either. I have a list of bookmarks with a stash prefix that I use as stashes, but they are just revsets that I can move around and manipulate as I wish.

Other killer feature: conflicts are not blockers. You can have a conflict in your code, but you can still commit and move on, dealing with the conflict later on. Especially useful when you are working on a feature branch and want to keep up with the main branch. You can just merge the main branch into your feature branch, and deal with the conflicts later on, when you have more time to focus on them.

The icing on the cake is the undo/redo feature. Yes, you read that right. JJ provides an operation log (jj op log) that tracks all your operations, including commits, merges, rebases, splits, etc. Calling jj undo will undo the last operation.

JJ lives on top / besides of your git repo. All you have to do after you install JJ is cd into your repository and run jj git init. Voilà, you can now use JJ with your git backend.

It provides you with home-made, yet efficient diff and merge tool, but you can also use your own (Meld, Neovim, Ediff, you name it). It is designed to be very user-friendly from the command line — much more than git — but a few TUI clients and IDE integrations also exist. More on that in a later post.

I started using JJ a few weeks ago, and I never looked back. I really feels it makes my VCS workflow much less of a burden.

I will probably post more about the way I use it day-to-day, along with configuration tips and tools. Stay tuned!

Pretty bad news. As a full-remote engineer, this means I will have to rely on the flaky 5G network I get round my house to work and communicate with co-workers.

I realize that I will have to write code in a completely gated environment, which, two days after writing a post about unplugging AI and reclaiming my thinking, means that I will have to code without the help of AI. This is a good test, a kind of reality check. What does it feel to code like it’s 2010 again?

And what a good idea for a blog post! I am going to write down my thoughts here along the way.

I kind of felt lazy all day, so I decided to rely on agents to leverage most of the work I had to do. The result is that I now feel totally depressed and tired. Everything was wrong with that day’s work.

It was tempting, at first. I thought I would have AI do the boring bits, type less on my keyboard and become an orchestrator. I thought it would give me more control over my priorities and help me dash through the day like a warrior, like a knight proudly riding his horse.

Now it’s 6 p.m. It feels like the horse has been trampling on my back all afternoon and is now chewing on my hair.

What did I get from today’s coding session? I remember giving instructions to the agent. I remember waiting for it to reply. I remember being unsatisfied with what it proposed as a solution. I remember guiding him step by step through the process. I remember looking at the screen in disbelief as it took five minutes to move a piece of code from one file to another.

I could have done it in seconds. Still, I was kind of relieved not to do the boring chores.

Looking back, I feel that what really happened is that I switched off my brain and surrendered it to the Machine. Now I feel ashamed.

All that time the machine was thinking. I wasn’t.

If you want to learn more about what it is, check out this video. The TL;DR is that my attention doesn’t work like most people’s. It’s either scattered in a thousand directions or laser-focused on one topic.

I’m the guy who goes to the store for milk and comes home without it—​not because I’m stupid, tired, or forgetful. It’s not a one-off thing; I have an attention disorder.

In our app, we have a deeply nested hash called public_data that’s often used to render a record’s JSON payload, along with its associations, in the controller.

This public_data hash is built from a mix of attributes and model methods. However, it also calls the public_data methods of associated models, which might, in turn, call back to the original model’s public_data. This circular complexity has been a challenge, and while we’ve started transitioning to the Barley serializer gem for better structure, we still rely on this method in parts of our codebase for backward compatibility.

So when @user.public_data is called in the controller, it often triggers a long chain of database queries. Tracking down where a specific relation is being called—​whether in User, Profile, or Subscription--can be daunting.

While Rails logs are helpful, they require sifting through the output to correlate the log entry with the SQL query. This becomes even trickier when debugging in remote environments and searching through extensive logs in tools like New Relic or CloudWatch.

Enter ActiveRecord::Relation#annotate…​

This simple method lets you add comments to your SQL queries, embedding contextual information directly within the query.

Here’s how it works:

This provides a clear indication of where the query originated. You can also include additional context, such as the current locale, user, or order ID, depending on your needs.

For example, adding an annotation inside the public_data method on my Subscription model makes it much easier to trace where the query originated in the chain.

Another great feature is the ability to stack annotations. Let’s say we add an annotation in the active scope of the User model:

Calling the same query as before would generate:

Neat, right? This approach brings more clarity and structure to your logs, making them easier to query and group in log viewers. Additionally, these annotations appear in your database logs, offering a seamless way to correlate them with application logs.

Possible applications include:

That said, annotations come with a slight tradeoff in query readability. It’s essential to be deliberate about what and when to log, and to periodically review whether the annotations remain relevant and valuable.

Even if used exclusively for local debugging, SQL annotations are an excellent addition to your toolbox.

Read the f***ing error messages!

So I encourage all of you learners to actually take a long look at the error messages that are thrown right in your face just as you were expecting a successful compilation. Take the time to read them. Take the time to look at those weird symbols that show up here and there. And you know what? You may not get to the point quicker at first, but you will gain a deeper knowledge of how your language is actually built, how it works internally. You might look at your fellow programmers increase their skills faster on the surface, but your understanding of error messages will eventually turn you into a Code Jedi Master.

What made me really stop overlooking error messages was reading Ruby Under A Microscope by Pat Shaughnessy, a most excellent book about the way Ruby is actually written in C, the way the language parser works and the way it turns the words you write into machine-understandable concepts.

Somewhere in the first part of the book that introduces how the parser works, the author talks about language tokenisation, which is - very basically - how the parser takes words and understand how to match them with a feature. And here they were, in a code example, my long-seen-yet-so-little-known error message friends, namely tSTRING, tCONSTANT and tINTEGER.

If only I had known what these correspond to before, error messages such as these would never have had me google for an answer.

But how could I know? When you google for ruby tString, you get all sorts of results, mostly skipping the preceding t. In order to get to the real stuff, I should have taken the time to actually read the error messages and wonder:

What is the language trying to tell me?

And if that sounds awkward, just remember that your programming language is actually a computer program written by other humans, and ask yourself:

What is the author of the language telling me to look at?

Chances are he is trying to get you to look at features of the language that may not be plain to see, but a little hidden from sight. And if he is trying to have you look at these, you might just as well do it. And learn.

I’m not going to talk about that code, because it’s so easy to spot and there is no need to write blog posts about it. What I’m interested in is code which looks fine when you have finished typing, but will bite you in the back someday. It ends up being hard to maintain, extend or even understand. After years of coding, I have come up with a set of warnings that alert me whenever I am heading for a dead end.

Six months later, the Heroku-Kubernetes transition is now over. I have gained a lot of experience. And I feel it’s time to share it.

I have this Caregiver model within a nested form and I need to create it along with a User entity in my form, to be able to populate the fields. The problem is that creating an after_initialize callback (even with :new_record? will break the general behaviour of my app, and I don’t want to run through all the specs and fix FactoryBot issues etc.

So I just decided to create a small method in my Caregiver model:

Then I just need to call it in my view like this:

This makes the code in my view simpler, more explicit, while avoiding the dreaded callback hell.

I recently had to make a semi-complex check on a string to validate it.

Basically, I have this model method which produces a serial number based on the ID of the object. Valid returned values for this method are L00000002, L00000587 or L00014522. In short, they should be constituted of a capital L followed by 8 digits composed of the id of the object padded with zeros.

So I had to find a way to simply created a matcher for this to use in my model spec. I could have built two expectations, one for the length, and one for the composition. But I just decided to believe that regular expressions are powerful enough to do both at the same time. So I headed to rubular and started fiddling and googling around.

The solution I came up with was the following (with an id of 12, for instance):

What this does, is - after the starting ^L character - create a condition matching whatever follows the ?= inside the parentheses. If this condition is true, then the rest of the expression is read. So I just check for any digit ([0-9] - it could have been \d but readability make the first option a better fit IMHO) exacty 8 times ({8}) and then the end of the string with $. If this is matched, then I check any number of zeros (0*) followed by the id (12) and the end of the string ($).

Now I could use this expression in my spec, using the Regexp.escape method on my model’s id within a string interpolation:

Don’t you just love regular expressions?

As I mentioned in a previous post, I’ve started the journey of a career change. After two failed attempts, I’ve finally landed a job as a fullstack developer at a really great company in the Poitiers area. The leave request was sent out yesterday, all my colleagues are now aware, and I find myself facing a new challenge in the form of a fresh start. And honestly — it’s pretty unsettling right now.

I’m caught between two worlds: I’m over 40, I know myself well, I have extensive professional experience and recognized skills — and yet, here I am, a beginner again, stepping into a completely different world from the one I knew in public education.Of course, I knew there were big differences between the public and private sectors before making the leap, but those differences hit differently when you’re signing at the bottom of an employment contract. This time, those differences feel personal. I’m used to being accountable to students — now I’ll be accountable to a boss. I’m used to working my own way — now I’ll need to fit into a company workflow. I’m used to setting my own pace — now I’ll need to meet deadlines. I’ll ultimately have less control over my days than I used to, even if a developer’s job still allows a good deal of autonomy. But beyond the actual work I’ll be doing day-to-day, what really stands out is how this shift might shake up my entire routine — and its impact on my family, our lifestyle, and habits we’ve built over the last 20 years. That’s the real unknown. I’m not afraid of this new future at all. Sure, there’s a little knot in my stomach now and then, but it’s more like stage fright — the nervous energy that comes with excitement — than anxiety rooted in regret. I wanted this change. I made it happen. Now it’s time to take that step — not into the void, but into the unknown. So good.

I am about to release a huge rails project I have been working on for quite a while. This project is meant to replace an old app that manages a database of customers with emails. The new rails project uses Devise for authentication.

Before we push the final update to the production server, we need to find a way to import the users without sending confirmation emails, but still keep them unconfirmed until they actually login to the new system and provide a password. New registrations should also still be confirmable.

So I had to find a way to override an instance method. This is easy to do with a simple module:

What this basically does is alias the send_confirmation_instructions method to a new return_false instance method we can inject into our model like this :

Therefore, my users will still have to confirm their account at first login on the new system, but won’t be notified when I import the database a few days before launch.

This can easily be adapted to serveral use cases, whenever you need to override an instance method in an exisiting Ruby class, as seen in this GitHub gist.

"It’s about time!", my friends will probably say.

If I stayed a teacher in the French National Education system for so long, it’s because I never really listened to them.

Since the goal of this post isn’t to share my 19 years of fascinating wanderings, I’ll just say that I chose teaching more out of pragmatism than passion. That, in itself, was a mistake.

So the time has come to leave teaching and turn to full-time software development. For now, nothing is set. I’m still in my job, grading papers, running classes…​ My colleagues, my superiors, and my students know nothing about my decision. Their time will come.

I intend to come here regularly to reflect, to share my thoughts on this transformation—​both to help me formalize my own evolution and to give a hand to others who may be in a similar situation.

Here is the very first interim assessment of my process, in the form of observations that are also a bit of advice:

Here is a wallpaper I made. Feel free to download…​

Here it is in 1080x1920 resolution