Posts

Every developer has lived through this scene: the adrenaline spike when a production incident is announced. That mix of dread about what you are going to find and frenzy to collect any piece of information that will let you understand and then fix the problem. It happened to me again a few days ago. I can still picture myself rushing to the logs, and I still remember the frustration of finding nothing but basic information and an unhelpful error message: “Unable to load cache”.

This morning, I had fun compressing time.

But before you picture me as a theoretical physics genius or a crackpot in need of a straitjacket, let me explain.

I am currently working on Metarc, a metacompression tool (understand: applying smart transformations to certain structures before handing off to a classical compressor like zstd). If you have never heard the term, you will understand in 5 minutes. If you are a compression expert, hang on, you might find food for debate.

…and How AI Made Him a Mason

My psychological profile is INTJ¹, also known as the Architect, and I spent a good part of my life proving that this label fit… in the worst possible way.

Years of having a multitude of ideas

• on analysis systems (Blockchain, Productivity)
• on personal development methods (Memory, Discipline, Learning)
• on algorithms (routing, metacompression, encryption)
• on tools (format conversion, project management, system administration)

Years of producing hundreds of ideas in a row, for nothing, or worse, only to see some of them realized by others years later.

What if the real gain wasn’t at the byte level?

I have always been fascinated by compression algorithms — I was 15 when I “invented” Run Length Encoding (before learning it had been discovered more than 20 years before I was born).
I marveled at the visual simplicity of Huffman coding, and at the cleverness of Lempel-Ziv which dynamically builds its dictionary.

These algorithms are powerful, and it is no coincidence that they are continuously improved and combined to produce increasingly more powerful algorithms: Brotli, zstd.

Introduction

In computing, the aphorism “Less is More” comes up often. With Jujutsu (jj), it takes a very concrete form: a simpler mental model can reduce the daily friction of version control.

In this article¹, I will not try to “prove” that jj is superior to git. I will show, on a concrete case, why some common operations: interrupting work in progress, reorganizing changes, fixing a non-atomic commit or resolving a conflict, become more natural with jj.

Sometimes an investigation tells a different story than the one you expected.

That’s what happened to me recently while investigating why a pod was ending up OOMKilled two to three times a day.

A quick look at the memory of the incriminated pod doesn’t show the typical rising curve of a memory leak. I’m missing data just before the OOM (because it’s always when your metrics system is migrating that this kind of incident happens), but with the day’s data, the cause seems to lie elsewhere.

Faced with an AI capable of compiling our intentions into working programs, I ask myself: does our craft reduce to assembling syntax, or does it hide a dimension that is by nature beyond computation?

I was 17 when I finally got my hands on “The Art of Computer Programming” by Donald Knuth. At the time, in 1989, reference books on programming were rare and the 4 volumes of TAOCP had the status of a “bible”; it remains for me a reference work that every computer scientist should read.

Lately, chance has had me hearing a lot about Test Driven Development.

Often around the old “TDD is dead” theme (https://dhh.dk/2014/tdd-is-dead-long-live-testing.html) and with the same questions resurfacing:

• What is the definition of the different types of tests?
• What is the ideal code coverage percentage?
• How do you handle flaky tests? Slow tests?

And if I address these questions quickly today, it is more for completeness than out of real interest. These questions are not specific to TDD; they are common to software testing as a whole.

What is the average salary for Perl programmers in 2020?

If I have no definitive answer on this, the Business Insider has some insights:

HackerRank polled 116000 developers about their salaries and got interesting results:

• Perl is associated with an average global salary of $84,025.50 (54.2% higher than the global average salary)
• Scala is associated with an average global salary of $77,159.60
• Go is associated with an average global salary of $72,691.30
• Python is associated with an average global salary of $56,670.90
• JavaScript is associated with an average global salary of $55,690

Without more information about the polled panel it’s hard to state this results as “Truth” but they seems to confirm personal beliefs:

Today I’ll start a series of articles dedicated to Vim:

“Just enough Vim to be efficient”

The main idea should be obvious from the title. Learn the bare minimum to produce useful results (and hopefully motivate you to dig even further)

This article is dedicated to Vim macros, an often overlooked feature of Vim.

But let’s start from the beginning what is a macro? and why is it useful?

And if the answer to the first question is simple: A macro is just a recorded sequence of keys.