Category Archives: software engineering


2024 Reading list (updated as we go)

MS/DOS 4.01 is open source

Contents shortage for AI :

Meta, for instance, trained its new Llama 3 models with about 10 times more data and 100 times more compute than Llama 2. Amid a chip shortage, it used two 24,000 GPU clusters, with each chip running around the price of a luxury car. It employed so much data in its AI work, it considered buying the publishing house Simon & Schuster to find more.

Stop doing cloud if not necessary (I’m saying this since years..)

Redis forks (after the licence change) :
– redict : Drew DeVault + others?
– valkey : backed by AWS, Google, Oracle, Ericsson, and Snap, with the Linux Foundation; more to come imo.

nginx new fork (others forks are openresty)

Too much hype about Devin : Debunking Devin: “First AI Software Engineer” Upwork lie exposed!

Matt Mullenweg buys Beeper (already owns and Element (New Vector)) consolidating his position in based messaging services :

golang fasthttp (replacement for standard net/http if you need “to handle thousands of small to medium requests per second and needs a consistent low millisecond response time”. “Currently fasthttp is successfully used by VertaMedia in a production serving up to 200K rps from more than 1.5M concurrent keep-alive connections per physical server.”

Back to basics 🙂 Bloom filter

1 billion row challenge :

golang : alternative to cgo ?

Command line benchmark tool :

New jpegli, jpeg-xl derived :

Edge CDN techniques : Shielding from fastly i.e. use a designated edge cache instead of origin on a edge cache miss.

Apple car not interesting anymore :

golang error handling the Uber way :

nginx forking : Maxim Dounin annouces on the nginx forum,299130

Quad 9 free dns :

UI testing the netflix way :

Check it out : the new super-ide

Lex/Yacc today :

Inside Stripe Engineering Culture, a series a posts :

I find truly interesting the point around promoting a write culture (Execs/Directors in tech blog, SWEs on tech blogs/internal technical documents) :
I’m a long-time believer that writing clarifies thinking more than talking and writing persists information, makes it searchable, talking does not. “Verba volant, scripta manent” as the Latins use to say. But this idea shifted into “just enough” documentation (which means it is not necessary) in SW engineering latest methodologies so it is interesting that a multi billion company like stripe is going totally against the tide.


The charm of complication

(or the Attraction for Complexity) There is a very common tendency in computer science and it is to complicate solutions. This complication is often referred as incidental/accidental complexity i.e. anything we coders/designers do to make more complex a simple matter. Some times this is called over engineering and stems from the best intentions :

  1. Attraction to Complexity: there’s often a misconception that more complex solutions are inherently better or more sophisticated. This can lead to choosing complicated approaches over simpler, more effective ones.
  2. Technological Enthusiasm: developers might be eager to try out new technologies, patterns, or architectures. While innovation is important, using new tech for its own sake can lead to unnecessary complexity.
  3. Anticipating Future Needs: developers may try to build solutions that are overly flexible to accommodate potential future requirements. This often leads to complex designs that are not needed for the current scope of the project.
  4. Lack of Experience or Misjudgment: less experienced developers might not yet have the insight to choose the simplest effective solution, while even seasoned developers can sometimes overestimate what’s necessary for a project.
  5. Avoiding Refactoring: In an attempt to avoid refactoring in the future, developers might add layers of abstraction or additional features they think might be needed later, resulting in over-engineered solutions.
  6. Miscommunication or Lack of Clear Requirements: without clear requirements or effective communication within a team, developers might make assumptions about what’s needed, leading to solutions that are more complex than necessary.
  7. Premature Optimization: trying to optimize every aspect of a solution from the beginning can lead to complexity. The adage “premature optimization is the root of all evil” highlights the pitfalls of optimizing before it’s clear that performance is an issue.
  8. Unclear Problem Definition: not fully understanding the problem that needs to be solved can result in solutions that are more complicated than needed. A clear problem definition is essential for a simple and effective solution.
  9. Personal Preference or Style: sometimes, the preference for certain coding styles, architectures, or patterns can lead to more complex solutions, even if simpler alternatives would suffice.
  10. Fear of Under-Engineering: there can be a fear of delivering a solution that appears under-engineered or too simplistic, leading to adding unnecessary features or layers of abstraction.

Just Scotland

RIP Niklaus Wirth

We all know Pascal language (less know about Algol or Oberon OS) and we might have heard that

 “software is getting slower more rapidly than hardware is becoming faster”

or that

“What Intel giveth, Microsoft taketh away”

I prefer this quote :

“Reducing complexity and size must be the goal in every step—in system specification, design, and in detailed programming. A programmer’s competence should be judged by the ability to find simple solutions, certainly not by productivity measured in number of lines ejected per day. Prolific programmers contribute
to certain disaster.”

You find them all here “A plea for lean software“. if you make code please read this 1995 paper.

Web design patterns


You’ve probably seen these acronyms around : SSG, SSR, MPA, SPA, PWA. Web design is getting complex and this tries to explain (with the help of other good content) what these acronyms mean :

  • PWA : Progressive Web App, web apps developed using a number of specific technologies and standard patterns to allow them to take advantage of both web and native app features. Not sure if this is a web design pattern
  • MPA : Multi Page Application, every operation requests data from server, receives a new page (html+css+js) and renders the data in the browser.
  • SPA : Single Page Application, performs inside a browser and does not require page reloading during its use. Initial html+cs+js is obtained from the server and then all login is done in js browser side.More info here and here
  • CSR : Client Side Rendering, all rendering happens in the browser. Use when UI is complex, lots of dynamic data, you need auth and SEO contents are not that many.
  • SSR : Server Side Rendering, as the acronyms imply, renders content in the server and sends ready .html+js files to the browser. Browser still executes js to reload pages. Use when UI has little interactivity, when you need best SEO and faster loading.
  • SSG : Static Site Generating, all pages are already generated and rendered server side.

There are several popular frameworks that can be used for static site generation (SSG) and server-side rendering (SSR).

For SSG, some popular options include Gatsby, Next.js, and Jekyll. These frameworks use a variety of technologies, such as React, Vue, and Ruby, to generate static HTML pages from dynamic content.

For SSR, some popular options include Express, Flask, and Hapi. These frameworks use Node.js and other technologies to generate the HTML for a page on the server and send it to the client.

Overall, there are many different frameworks available for both SSG and SSR, and the best choice will depend on the specific needs and goals of the project. It is important to carefully evaluate the features and capabilities of each framework to determine which one is the best fit for the project.