_____ _ 
 / ____| |           Sebastien LOVERGNE
| (___ | |           /blog.txt
 \___ \| |           /projects.txt
 ____) | |____       /awesome.txt
|_____/|______|      /blogroll.txt


===========================================================================
                     My list of 𝗔𝘄𝗲𝘀𝗼𝗺𝗲 things
===========================================================================

This is  a curated list  of things I  have discovered on the web and  found
useful or thought-provoking, there is also some fun stuff. 

Potential  subjects  include,   but  are  not  limited   to,   programming,
engineering, technology, and woodworking. 

The list  is  sorted by date  of  addition  (latest  first),  expect for my
favorites wich are pinned. 

  ┌────────────────────────────┐
┌─┤ ♥ Putting the “You” in CPU ├──────────────────────────────────────────┐
│ └────────────────────────────┘                                          │
│  A deep dive into how exactly your program can "run"on a machine. It's  │
│  simple question but it will lead you to explore a lot of  interesting  │
│  things: what's is an instruction?  How can we  multitask on a  CPU if  │
│  its execution  is sequential?  How do memory isolation between kernal  │
│  and different process work? What is a  dawn syscall actually? And how  │
│  to become an Elf-lord?                                                 │
│                                                                         │
│  It's   well  written   and   beautifully   presented  which  make  it  │
│  approachable  despite  being  very  detailed  (  if  you  wonder  how  │
│  detailed,  there  is  a  function by function  analysis of  how linux  │
│  implement system call in  chapter 3). If you're anything  like me and  │
│  want to understand how your programs run all  the ways down from your  │
│  code to the hardware level then, this is  for  you. This has actually  │
│  improved  my understanding of how computers work and what the role of  │
│  an kernel is. I cannot recommend reading it enough!                    │
│                                                                         │
│  PS: I realised after reading  the entire thing the  the  research and  │
│  the writing was done by a 17 year old with the help of hackclub. This  │
│  person probably has a bright future ahead of her, I wish I could have  │
│  been so dedicated when i was 16 year old!                              │
│                                                                         │
│  PPS : there is another one by same person about networking called how  │
│  did I  get  here?[1].  ~~It's on my  reading list!~~. It's  also very  │
│  cool.                                                                  │
│                                                                         │
│  [1] https://how-did-i-get-here.net/                                    │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────────┐
┌─┤ ♥ Schemathesis ├──────────────────────────────────────────────────────┐
│ └────────────────┘                                                      │
│  Schemathesis is an incredible fuzzer for REST and GraphQL API. It can  │
│  be used through CLI  or  integrate  directly  with your unit  test in  │
│  python. Thanks to it's property-based testing, I  have found numerous  │
│  bug,  including inside my dependencies, .  It also  help me catch bad  │
│  documentation  with  it's response  schema  validation.  I  definitly  │
│  integrate it inside my CI/CD pipeline whenever I can.                  │
│                                                                         │
│  If you have been impressed by schemathesis capability like me and you  │
│  want to know more about it's conception I would recommend reading the  │
│  paper published by  its  creators  "Deriving  Semantics-Aware Fuzzers  │
│  from Web API Schemas" by Zac Hatfield-Dodds and Dmitry Dygalo.         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────────────────────────────────┐
┌─┤ VSCode workspace shortcuts with .desktop files on Linux ├─────────────┐
│ └─────────────────────────────────────────────────────────┘             │
│  One big  frustration I have with my workflow currently is that I open  │
│  all my  apps with the app  launcher (the menu that appears  when  you  │
│  press the  command key  `⌘`)  except one: VSCode[^clarification]. And  │
│  that's a big  "but"  because this is probably the  app I use the most  │
│  after  my browser.  Instead, I  open a terminal  and  type  `code-oss  │
│  repos/name-of-my-repo`; if  I don’t, it  just  opens VSCode with  the  │
│  last workspace instead of the one I specifically want. But  today, no  │
│  more!  Today  I  fixed my  workflow  with a simple  hack:  generating  │
│  `.desktop` files.                                                      │
│                                                                         │
│  ────────────────────────────────                                       │
│   But what is a `.desktop` file?                                        │
│  ────────────────────────────────                                       │
│                                                                         │
│  A `.desktop` file, or rather a desktop entry  file, is a very  simple  │
│  config that applications can use to register themselves with GNOME or  │
│  KDE's application system. For example, the reason you can find VSCode  │
│  in the app  launcher  is because when you installed it, it  created a  │
│  file called `code.desktop` in one of the following locations:          │
│                                                                         │
│    • System package: `/usr/share/applications/code-oss.desktop`         │
│                                                                         │
│    • Manual install: `~/.local/share/applications/code-oss.desktop`     │
│                                                                         │
│    • Snap:                                                              │
│      `/var/lib/snapd/desktop/applications/code-oss_code-oss.desktop`    │
│                                                                         │
│    • Flatpak:                                                           │
│      `~/.local/share/flatpak/exports/share/applications/com.visualstudio.code_oss.desktop`   │
│                                                                         │
│                                                                         │
│  The content of `/usr/share/applications/code-oss.desktop`  on  Alpine  │
│  Linux is:                                                              │
│                                                                         │
│  ```null                                                                │
│  [Desktop Entry]                                                        │
│  Name=Code - OSS                                                        │
│  Comment=Code Editing. Redefined.                                       │
│  GenericName=Text Editor                                                │
│  Exec=/usr/bin/code-oss %F                                              │
│  Icon=com.visualstudio.code.oss                                         │
│  Type=Application                                                       │
│  StartupNotify=false                                                    │
│  StartupWMClass=Code - OSS                                              │
│  Categories=TextEditor;Development;IDE;                                 │
│  MimeType=application/x-code-oss-workspace;                             │
│  Actions=new-empty-window;                                              │
│  Keywords=vscode;                                                       │
│                                                                         │
│  [Desktop Action new-empty-window]                                      │
│  Name=New Empty Window                                                  │
│  Name[de]=Neues leeres Fenster                                          │
│  Name[es]=Nueva ventana vacía                                           │
│  Name[fr]=Nouvelle fenêtre vide                                         │
│  Name[it]=Nuova finestra vuota                                          │
│  Name[ja]=新しい空のウィンドウ                                                    │
│  Name[ko]=새 빈 창                                                         │
│  Name[ru]=Новое пустое окно                                             │
│  Name[zh_CN]=新建空窗口                                                      │
│  Name[zh_TW]=開新空視窗                                                      │
│  Exec=/usr/bin/code-oss --new-window %F                                 │
│  Icon=com.visualstudio.code.oss                                         │
│  ```                                                                    │
│                                                                         │
│  As you can  see, it contains a lot of  metadata to  help your desktop  │
│  environment present  and  launch the app correctly. Here  is  a quick  │
│  presentation of each field:                                            │
│                                                                         │
│    • Name: the label of the application                                 │
│                                                                         │
│    • Comment: a short description for tooltips                          │
│                                                                         │
│    • GenericName: what category of application it belongs to            │
│                                                                         │
│    • Exec: how the application is launched. Note here that  `%F` tells  │
│      the system  that VSCode can  open one or  multiple files at once.  │
│      This is why when you  select  some  files,  right-click, and then  │
│      click on "Open With," VSCode appears as an option                  │
│                                                                         │
│    • Icon: the icon of the app; can be an absolute path or, as in this  │
│      case, a URI compatible with the icon-themes specification[1]       │
│                                                                         │
│    • Type: whether it's an application, a directory, or a link          │
│                                                                         │
│    • StartupNotify: this one is a little bit complicated and is linked  │
│      to the startup-specification standard[2].  What you need to  know  │
│      is that `false` only means  that it is  up to the application  to  │
│      manage its own startup notification, not that it won’t notify you  │
│      on start. I really wish it would just stop startup notifications   │
│                                                                         │
│    • StartupWMClass: an  ID used to  know which  windows belong to the  │
│      same application                                                   │
│                                                                         │
│    • Categories:  like  GenericName,  it's  a categorization,  but  it  │
│      follows  the desktop-menu specification[3] instead of being  free  │
│      text                                                               │
│                                                                         │
│    • MimeType: a list of MIME types that the application can open.  In  │
│      this  case,  VSCode  registers  its  own  custom  MIME  type  for  │
│      workspaces, because listing  everything VSCode can open would  be  │
│      too long—as it can basically open anything                         │
│                                                                         │
│    • Actions:  a list  of custom actions the  application can perform.  │
│      You  can  see  the  `new-empty-window`  in  your app launcher  by  │
│      right-clicking on the VSCode icon                                  │
│                                                                         │
│    • Keywords:  a  list  of  strings  that  can be  used  to match the  │
│      application when searching. In this case, while the app is  named  │
│      "Code," I can still type "VSCode" and find it in the app launcher   │
│                                                                         │
│    • [Desktop  Action  new-empty-window]: this  section  describes the  │
│      custom action with internationalization details                    │
│                                                                         │
│                                                                         │
│  If  you are  interested, there are  other  options for more  advanced  │
│  functionality described in  the desktop-entry specification[4].  Most  │
│  of those options won't be very useful to  us, but it's always good to  │
│  know what we are working with.                                         │
│                                                                         │
│  ─────────────────────────────────────────────────                      │
│   How does that help me open a workspace quickly?                       │
│  ─────────────────────────────────────────────────                      │
│                                                                         │
│  We could add a custom action to VSCode to open a specific folder, but  │
│  the  downside  of  that  is  that  the  action  is  hidden  behind  a  │
│  right-click and is not directly searchable.                            │
│                                                                         │
│  Instead, whatwe're going  to do is create a  `.desktop`  file for our  │
│  workspace  with a custom `Exec` to open this specific folder. Here is  │
│  an example:                                                            │
│                                                                         │
│  ```txt                                                                 │
│  # ~/.local/share/applications/code-tinyfeed.desktop                    │
│  [Desktop Entry]                                                        │
│  Name=tinyfeed workspace                                                │
│  Comment=Open the repository directly with code                         │
│  GenericName=Text Editor                                                │
│  Exec=code-oss "/home/sebastien/repos/tinyfeed"                         │
│  Icon=com.visualstudio.code.oss                                         │
│  Type=Application                                                       │
│  StartupNotify=false                                                    │
│  StartupWMClass=Code - OSS                                              │
│  Categories=TextEditor;Development;IDE;                                 │
│  Keywords=vscode;                                                       │
│  ```                                                                    │
│                                                                         │
│  Let's analyze it step by step:                                         │
│                                                                         │
│    • The  file  is  located  in  `~/.local/share/applications/`.  Most  │
│      `.desktop` files are located  in  `/usr/share/applications/`, but  │
│      using  `~/.local` allows us to scope the application  to only the  │
│      current  user,  which  I   think  is   preferable  for  workspace  │
│      shortcuts. Also, it does not require root access.                  │
│                                                                         │
│    • The icon is simply the VSCode icon reused.                         │
│                                                                         │
│    • The  label  is the  name  of the  workspace,  making it  easy  to  │
│      distinguish  from the actual VSCode  app as  they have  the  same  │
│      icon. "workspace"  is at  the  end  because  the  name  is  often  │
│      truncated.                                                         │
│                                                                         │
│    • An  absolute path to our workspace  replaces  the `%F`  argument.  │
│      It's important  that the path is  absolute, as `~`  would not  be  │
│      expanded.                                                          │
│                                                                         │
│    • The rest of the metadata is kept from the base file.               │
│                                                                         │
│                                                                         │
│  This gives us the following search result in  the app launcher when I  │
│  search for "tinyfeed[^self-promotion]":                                │
│                                                                         │
│  illustration: /workspace-shortcut-1.avif                               │
│                                                                         │
│  And  when we  press  `Enter ⏎` it  will open the  tinyfeed  workspace  │
│  successfully                                                           │
│                                                                         │
│  ─────────────────────────────────────────────────────────────────      │
│   Okay but now I need to manually maintain a file for each repos?       │
│  ─────────────────────────────────────────────────────────────────      │
│                                                                         │
│  Indeed,  maintaining that by  hand  would be  annoying  but  you  can  │
│  trivially   write  a  bash  script  to  automate  the  generation  of  │
│  `.desktop` files:                                                      │
│                                                                         │
│  ```bash                                                                │
│  #!/bin/sh                                                              │
│                                                                         │
│  # Ensure the script exit on error or unbound variables                 │
│  set -eu                                                                │
│                                                                         │
│  # Configuration                                                        │
│  REPOSITORIES_DIRECTORY="$HOME/repos"                                   │
│  APPLICATIONS_DIR="$HOME/.local/share/applications"                     │
│                                                                         │
│  # Ensure the applications directory exists                             │
│  mkdir -p "$APPLICATIONS_DIR"                                           │
│                                                                         │
│  for repo_path in "$REPOSITORIES_DIRECTORY"/*/; do                      │
│      REPOSITORY=$(basename "$repo_path")                                │
│      DESKTOP_FILE="$APPLICATIONS_DIR/code-$REPOSITORY.desktop"          │
│                                                                         │
│      cat > "$DESKTOP_FILE" <<EOF                                        │
│  [Desktop Entry]                                                        │
│  Name=$REPOSITORY workspace                                             │
│  Comment=Open the repository directly with code                         │
│  GenericName=Text Editor                                                │
│  Exec=code-oss "$REPOSITORIES_DIRECTORY/$REPOSITORY"                    │
│  Icon=com.visualstudio.code.oss                                         │
│  Type=Application                                                       │
│  StartupNotify=false                                                    │
│  StartupWMClass=Code - OSS                                              │
│  Categories=TextEditor;Development;IDE;                                 │
│  MimeType=application/x-code-oss-workspace;                             │
│  Keywords=vscode;                                                       │
│  EOF                                                                    │
│                                                                         │
│  done                                                                   │
│  ```                                                                    │
│                                                                         │
│  This script  will create a templated `.desktop` file  for each folder  │
│  in the  `~/repos` directory. This  means you need to have all of your  │
│  workspaces inside a single directory in a flat manner for it to work,  │
│  but you  can probably adapt it with a more advanced directory listing  │
│  algorithm if you need.                                                 │
│                                                                         │
│  Then you only have to call it  in your  `.bashrc`, and your workspace  │
│  shortcuts  will be updated every time you open  a terminal. You could  │
│  also just do it in a cron job if you prefer.                           │
│                                                                         │
│  This is the final result, all my workspaces are searchable in the app  │
│  launcher:                                                              │
│                                                                         │
│  illustration: /workspace-shortcut-2.avif                               │
│                                                                         │
│  Just for completeness:  another  solution could  have been to  use  a  │
│  customizable  app   launcher   like   Ulauncher[5]   with   a  VSCode  │
│  extension[6], but I like to keep my setup as standard as possible for  │
│  portability.                                                           │
│                                                                         │
│  [^clarification]: VSCode vs Code-OSS vs Codium: In this article, when  │
│  I refer to VSCode I  actually  refer to code-oss[7], the  open-source  │
│  version  of  VSCode—not   the  proprietary   version,  and  also  not  │
│  Codium[8],  the open-source and slightly modified version of  VSCode.  │
│  It  matters  because  I  launch it  with the  command `code-oss`, not  │
│  `code`. You might need to adapt my scripts accordingly. Same goes for  │
│  file paths.                                                            │
│                                                                         │
│  [^self-promotion]:  Check out tinyfeed[9],  a minimalist  self-hosted  │
│  RSS reader that generates static HTML pages for your consumption.      │
│                                                                         │
│  [1] https://specifications.freedesktop.org/icon-theme-spec/latest/     │
│  [2] https://cgit.freedesktop.org/startup-notification/tree/doc/startup-notification.xml  │
│  [3] https://specifications.freedesktop.org/menu-spec/latest/           │
│  [4] https://specifications.freedesktop.org/desktop-entry-spec/latest-single/#recognized-keys  │
│  [5] https://ulauncher.io/                                              │
│  [6] https://ext.ulauncher.io/-/github-brpaz-ulauncher-vscode-projects  │
│  [7] https://github.com/microsoft/vscode                                │
│  [8] https://github.com/VSCodium/vscodium                               │
│  [9] https://github.com/TheBigRoomXXL/tinyfeed                          │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────────────┐
┌─┤ Computer, Enhance! ├──────────────────────────────────────────────────┐
│ └────────────────────┘                                                  │
│  An  excellent performance-Aware programming course by Casey Muratori.  │
│  If you're not  familiar with him,  Casey Muratori is a programmer who  │
│  specializes in game engine research and development. He has extensive  │
│  knowledge  of CPU  and GPU micro-architecture and  how they  interact  │
│  with software performance.                                             │
│                                                                         │
│  This course is designed for programmers who already  know how to code  │
│  but want to learn how to maximize hardware performance. The course is  │
│  language-agnostic,  focusing on  five optimizations applicable to any  │
│  program:  waste  reduction, instructions per clock, single operation,  │
│  multiple data (SIMD), caching, and multi-threading.                    │
│                                                                         │
│  The course is updated weekly with a Q&A for the previous  week, a new  │
│  lesson, and homework  assignments  for  the upcoming week. It  is not  │
│  free; it  costs  $9 per month.  I  recommend checking out some of the  │
│  free  episodes  available on  his YouTube  channel[1]  or  one of his  │
│  interviews[2] first to see if the course is right for you.             │
│                                                                         │
│  [1] https://youtube.com/@mollyrocket?si=HEWDx_HjvBjrD3uK               │
│  [2] https://youtu.be/Zr09I5OlOjs?si=oM1tmYGWNE6EGaxX                   │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────────┐
┌─┤ What makes concurrency so hard? ├─────────────────────────────────────┐
│ └─────────────────────────────────┘                                     │
│  The short  version: Concurrency is difficult due  to  the state space  │
│  explosion  that  occurs very  quickly when  you distribute a  system,  │
│  which exceeds our ability to model.                                    │
│                                                                         │
│  The  author provides a neat demonstration of this  hypothesis, and it  │
│  really resonates with my own experience.                               │
│                                                                         │
│  Recently, I’ve been thinking about this idea a lot since I discovered  │
│  Residual  Theory[1]. In this theory, we begin with too  many possible  │
│  states  to create an  accurate  model,  but  progressively reduce the  │
│  complexity by focusing  on attractors[2],  solutions that cover large  │
│  areas of the state space,  so  that  unforeseen states already have a  │
│  solution.                                                              │
│                                                                         │
│  [1] https://youtu.be/_MPUoiG6w_U?si=-G54W3aPhlvWTiQd                   │
│  [2] https://en.m.wikipedia.org/wiki/Attractor                          │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────┐
┌─┤ Models All the Way Down ├─────────────────────────────────────────────┐
│ └─────────────────────────┘                                             │
│  "Models  All  the Way Down"  by Knowing  Machines[1]  is  a  detailed  │
│  investigation  into  the datasets  behind our current foundational AI  │
│  models, the methods used to create  them, and  the  inevitable biases  │
│  they produce. The results of this investigation are presented through  │
│  a  stunning  visual  display  based  on  the   collected  data.   The  │
│  storytelling is excellent, allowing readers to understand the subject  │
│  progressively, even if they are novices.                               │
│                                                                         │
│  All  the  data  from  their  investigation  has   been  published  on  │
│  GitHub[2].                                                             │
│                                                                         │
│  [1] https://knowingmachines.org/about                                  │
│  [2] https://github.com/NYUEngelberg/models-all-the-way                 │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────┐
┌─┤ Glory is only 11MB/sec away ├─────────────────────────────────────────┐
│ └─────────────────────────────┘                                         │
│  A  good  article  against  the  necessity  of  horizontal scaling and  │
│  deploying on the edges.                                                │
│                                                                         │
│  Indeed, I think that for most applications you  might want horizontal  │
│  scaling but  you  don't actually  need  it, worst  than that, it  can  │
│  actually  hurt your application by adding  unnecessary complexity and  │
│  remember what Grug[1] told use: complexity is the enemy.               │
│                                                                         │
│  [1] https://lovergne.dev/archive/grub-brain                            │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌───────────────────────────────────────────────────┐
┌─┤ A Distributed Systems Reading List by Fred Hebert ├───────────────────┐
│ └───────────────────────────────────────────────────┘                   │
│  Distributed systems are everywhere now,  if you  are working on a web  │
│  application now, chances are  it is  distributed or someone  will ask  │
│  you  to make  it  distributed  at some  point. Probably most  systems  │
│  should  not be  distributed,  as it  adds  an  incredible  amount  of  │
│  complexity, but  the promises of fault tolerance  and scalability are  │
│  hard to ignore, we are  only human after all, and we have a hard time  │
│  not imagining the grass is greener elsewhere. Also, sometimes systems  │
│  actually need to be distributed to meet some constraints.              │
│                                                                         │
│  But  distributed systems are  hard and often counterintuitive. So I'm  │
│  currently trying to  learn  more  about distributed systems theory so  │
│  that I  don't shoot myself in the foot when I try to design and build  │
│  them. This reading  list is a good place to start, as it references a  │
│  lot of  foundational  papers. But more  than the  references,  what I  │
│  really  like  about this page are  the definitions. On this page, the  │
│  author defines  most of  the vocabulary  commonly  used to talk about  │
│  distributed  systems. These  definitions are concise, understandable,  │
│  and often accompanied by insights into what a concept actually  means  │
│  for real-world  applications.  I highly  recommend reading the  whole  │
│  page before you start reading papers, it will give you the basics.     │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────┐
┌─┤ Excalidraw ├──────────────────────────────────────────────────────────┐
│ └────────────┘                                                          │
│  Excalidraw is  amazing. It's  very  simple, it  doesn't have  all the  │
│  features of other big diagramming tools, it doesn't even have a grid,  │
│  and yet you'll make better diagrams faster with it. It's like using a  │
│  real whiteboard, expecting  that it's infinite and you don't  have to  │
│  rewrite everything if you've misplaced something.                      │
│                                                                         │
│  Excalidraw is  such a good example of UX:  you open it  and  you  are  │
│  ready to go,  no need to  register, no need for a  tutorial. It's low  │
│  fidelity style will make all your  diagrams beautiful without  effort  │
│  and without the need  for precision. All the  tools are intuitive and  │
│  immediately usable, yet when you  start using exclidraw more you will  │
│  discover  a  lot of  shortcuts  to work faster  (see  the help in the  │
│  bottom right corner for a full list of keyboard shortcuts).            │
│                                                                         │
│  Excalidraw is also  fully collaborative  with it's Live Session: just  │
│  share the link and you can instantly see other people working in your  │
│  workspace. Then  there is  the fantastic  library  functionality that  │
│  allows you to share and reuse components with ease.                    │
│                                                                         │
│  Finally,  there  is  the  mermaid  support,  which  will   turn  your  │
│  text-based,  simple-version,  easy-to-maintain but  ugly diagram into  │
│  something nice and pleasing.                                           │
│                                                                         │
│  It's lovely.                                                           │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────┐
┌─┤ Restic ├──────────────────────────────────────────────────────────────┐
│ └────────┘                                                              │
│  Restic is the tool you should be using for your backups:               │
│                                                                         │
│   1. You can always find  what you need in a restic backup  because it  │
│      uses incremental snapshots (like git).                             │
│                                                                         │
│   2. It's safe, because your data is always encrypted.                  │
│                                                                         │
│   3. It's  painless, because it always checks your files for integrity  │
│      and consistency.                                                   │
│                                                                         │
│   4. It's  efficient, because it not only uses  incremental snapshots,  │
│      but also compresses them.                                          │
│                                                                         │
│   5. It's flexible, because it can integrate with virtually any remote  │
│      storage backend (I personally use Backblaze B2).                   │
│                                                                         │
│   6. It's  long-lastings, because the Restic repository format has its  │
│      own open specification and other multiple implementations.         │
│                                                                         │
│   7. It's easy to  set up and  maintain,  because it  has  a good  CLI  │
│      interface and good documentation.                                  │
│                                                                         │
│   8. It's fast and CPU efficient, because it's in Golang.               │
│                                                                         │
│                                                                         │
│  Restic, what else?                                                     │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌──────────────┐
┌─┤ Wizard Zines ├────────────────────────────────────────────────────────┐
│ └──────────────┘                                                        │
│  A series of vulgarisation comics on all  sorts  of topics  related to  │
│  programming.  I  think  it's  an  excellent  ressource  for  beginner  │
│  programmers,  it lets you ask  some questions about basic things that  │
│  you usually don't  have time for  or, maybe too afraid to ask,  like:  │
│  what is http?[1] or what is memory allocation?[2]                      │
│                                                                         │
│  [1] https://wizardzines.com/zines/http/                                │
│  [2] https://wizardzines.com/comics/memory-allocation/                  │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────────────────────────────────────┐
┌─┤ Hey: tiny program that sends some load to a web application ├─────────┐
│ └─────────────────────────────────────────────────────────────┘         │
│  When I deploy a new app in production, I like to do a quick load test  │
│  to have an idea of how much traffic I can support while staying under  │
│  my latency target.                                                     │
│                                                                         │
│  Hey is an  excellent  CLI tool for that. You give  it  the URL of the  │
│  page you want to test  and it will generate some load for it. You can  │
│  easily  configure  the   load  (number  of  requests,  headers,  rate  │
│  limit...) with flags. Once the  loading is  finished,  you received a  │
│  very readable  report with  the  latency distribution  and  other key  │
│  indicators.                                                            │
│                                                                         │
│  Another practical tool to have in the toolbox!                         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────────────────────────────────┐
┌─┤ HTMHell: collection of bad (and good) practices in HTML ├─────────────┐
│ └─────────────────────────────────────────────────────────┘             │
│  I considered myself pretty up to  date with the functionality offered  │
│  by  HTML  but HTMLHell  show me I was wrong. Notably I discovered the  │
│  existence of  download links[1] (how did I miss that all this time?!)  │
│  and how to use <picture> for progressive enhancement[2].               │
│                                                                         │
│  The site has two main section:                                         │
│                                                                         │
│   1. Hell: where you find bad, but not obviously bad, examples of HTML  │
│      code                                                               │
│                                                                         │
│   2. Heaven: where you discover little-known but very  useful features  │
│      of HTML                                                            │
│                                                                         │
│                                                                         │
│  There is also an  advent calendar with tips and tricks in December. I  │
│  highly recommend exploring  this  site  if you want  to  deepen  your  │
│  understanding of what HTML has to offer.                               │
│                                                                         │
│  [1] https://www.htmhell.dev/tips/download-links/                       │
│  [2] https://www.htmhell.dev/tips/the-avif-image-format/                │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────────────────────────────────────────┐
┌─┤ Tinystatus: a lovingly simple monitoring tool. ├──────────────────────┐
│ └────────────────────────────────────────────────┘                      │
│  Sometimes, you have a basic  website  or a small application, and all  │
│  you need is a way to receive alerts if  it goes down. In such  cases,  │
│  you probably don't want to deploy the entire OpenTelemetry stack with  │
│  all the required  infrastructure and integration. Sometimes, all  you  │
│  want is something simple. This is where "tinystatus" comes into play;  │
│  it couldn't be simpler.                                                │
│                                                                         │
│  Tinystatus is a compact  130-line Bash script  that queries a list of  │
│  URLs  and generates an HTML report. You can effortlessly set it up in  │
│  cron  or  systemd  and  direct  your  HTTP  server  to the  generated  │
│  `index.html`. Voilà, you've got yourself a status  service. Moreover,  │
│  by redirecting its `stderr` output to a mail service, you can receive  │
│  real-time alerts if your website or app experiences any downtime.      │
│                                                                         │
│  Because  it's  so  concise,  you can  easily  customize  it  to  your  │
│  preferences  by adding extra checks  or tweaking the  styling. And if  │
│  you don't  want  to deal  with  setting  up cron, systemd  or the web  │
│  server,  it's  also  available as  a  Docker  container  or  as a  Go  │
│  implementation, aptly  named  "go-tinystatus", which embeds  the HTTP  │
│  server for your convenience.                                           │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────────────────────────────────────────────┐
  │ FoundationDB: Distributed Unbundled Transactional  Key Value  Store │
┌─┤ (2021)                                                              ├─┐
│ └─────────────────────────────────────────────────────────────────────┘ │
│  FoundationDB  is a distributed transactional key  value store created  │
│  in 2009 wich guarantee ACID transactions at scale.                     │
│                                                                         │
│  This is  paper published  by  the FoundationDB team summarising there  │
│  approach to building a distributed  database 10  years after building  │
│  it.  There is a lot of  interesting things inside it but here  are my  │
│  main takeaway:                                                         │
│                                                                         │
│    • They  built  the simulation and testing framework before starting  │
│      to  build  the  actual  database.  This   really  highlights  the  │
│      importance  of extensive testing  capabilities  if  you  want  to  │
│      achieve consistency and robustness in complex systems. I find the  │
│      idea  of a  simulation  to continuously test  and find  bug in  a  │
│      system trully amazing and I  hope  I will have the  chance to  do  │
│      something similar one day.                                         │
│                                                                         │
│    • FoundationDB  offers a minimal and carefully chosen  feature  set  │
│      and  instead  realy  on  a layered  architecture to enable  other  │
│      developer to implement  there own  feature  and data-model.  This  │
│      approch has seen a lot of success as  FoundationDB  has been used  │
│      as  a  literal  foundation  for  other  paradigm  of  distributed  │
│      databases: semi-relational databases, document and object stores,  │
│      graph databases and more.                                          │
│                                                                         │
│    • I  am way  over  my  head with the internals  of the  transaction  │
│      system.                                                            │
│                                                                         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌──────────────────────┐
┌─┤ Why is CSS so Weird? ├────────────────────────────────────────────────┐
│ └──────────────────────┘                                                │
│  Because the web has been build with a set of value at it's core : the  │
│  web  is open, it's for  everyone  and everything. By accepting  those  │
│  value  we must, at the same time, accept that we loose some degree of  │
│  control,  we don't choose  who will look  at  our website and on what  │
│  devices.  That lake  of control means we must build  websites for  an  │
│  infinite  canvas  with  unknown  constraints  and  capabilities.  But  │
│  designing for the unknown is hard, for that, we need flexibility, and  │
│  this is where CSS come in.                                             │
│                                                                         │
│  The Cascade in Cascading Style Sheets is the  process  of  assembling  │
│  styles  from  different  inputs.  You  gain  from  that  process  the  │
│  capability to merge intent  from different  sources: the  Author, the  │
│  Browser and remarkably, the User.                                      │
│                                                                         │
│                                                                         │
│                      AUTHOR     BROWSER      USER                       │
│                        │           │           │                        │
│                        │           │           │                        │
│                        │           ▼           │                        │
│                        └──────► CASCADE ◄──────┘                        │
│                                    │                                    │
│                                    ▼                                    │
│                                  STYLE                                  │
│                                                                         │
│                                                                         │
│  "Author, browser, and user styles consolidate into one style throught  │
│                                cascade"                                 │
│                                                                         │
│  It also allows us to fail gracefully by cascading upward wich is good  │
│  for resilence  and backward compatibility. But the  tradeoff  is that  │
│  your instructions can be overridden, they became suggestions. This is  │
│  one of the  pitfalls of CCS  and why  we sometime  have  to  use  the  │
│  infamous  `!important`.  The other consequence is that everything  is  │
│  hierarchically linked. This is great, as one  style can be reused  in  │
│  many  similar places to achieve consistency, but this is also another  │
│  big pitfall of CSS  as  a style might impact  elements  it was  never  │
│  meant to.                                                              │
│                                                                         │
│  Overall some  might  think that we made a  bad tradeoff  with CSS  by  │
│  loosing too much control, but I don't think so. As John Allsopp said,  │
│  "Control[...] is  a  limitation of the  printed page", when a book is  │
│  produce and sold only the editor can make it accessible, and he fails  │
│  to do it most  of the time whether it's diagrams with bad contrast or  │
│  the absence of braille editions or other things. But with the browser  │
│  and CSS the  user has the last word,  he can make it feet  it's need,  │
│  whatever it is.'                                                       │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌───────────────────────────┐
┌─┤ Every Layout: relearn CSS ├───────────────────────────────────────────┐
│ └───────────────────────────┘                                           │
│  One of the best resource I could find on modern CSS practice. It goes  │
│  deep  on  how css  properties function  and  interact,  provide  some  │
│  general  design rules and propose solution to a lot  of common layout  │
│  problem in a flexible and reusable way.                                │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌──────────────────────────────────────────┐
┌─┤ WAVE: Web Accessibility Evaluation Tools ├────────────────────────────┐
│ └──────────────────────────────────────────┘                            │
│  A collection of  tools  to test website  accessibility. There browser  │
│  extension is  great  and give an  instanious  and detailed feeback on  │
│  accessibity isssues on a web page. (Try it here and you wont find any  │
│  error!)                                                                │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────────────────────┐
┌─┤ The Grug Brained Developer ├──────────────────────────────────────────┐
│ └────────────────────────────┘                                          │
│  A fun guide on managing  complexity  in software for all of us  small  │
│  brained developers. Remember: complexity is the enemy;  complexity is  │
│  very, very bad.                                                        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────────────────────────────────┐
┌─┤ RFC9457: problem details for HTTP APIs ├──────────────────────────────┐
│ └────────────────────────────────────────┘                              │
│  There are currently no  standard ways for API  to  communicate  there  │
│  domain specific error where HTTP status is not enough. This RFC hopes  │
│  to remedy  that  with a  proposed schema for error  response. I think  │
│  it's  a good proposal, it give  enough  feedback and it's flexibility  │
│  enough  to work in most API. The  one thing I really like is  that it  │
│  forces you to document your  API's specific errors because  a link to  │
│  documentation about the error is included in the schema.               │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────┐
┌─┤ Adminer ├─────────────────────────────────────────────────────────────┐
│ └─────────┘                                                             │
│  Minimalist,  fast,  single-file,  UI  for  RDBMS. phpmyadmin but  way  │
│  better. I love there interface, it's very clear and readable. Adminer  │
│  is simple but also fully featured. It  is customizable and extendable  │
│  throught themes and plugins. It also integrate very well  with docker  │
│  and  help access the database for debugging. Overall a very practical  │
│  tool to have in the toolbox.                                           │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────┐
┌─┤ Alpines.js ├──────────────────────────────────────────────────────────┐
│ └────────────┘                                                          │
│  Make  the  web  simple  again! Alpine.js  provide DOM  reactivity and  │
│  two-way data  binding thought a  lightweight framework. It's build on  │
│  top of the `@vue/reactivity` package, which is  it's only dependency,  │
│  and the whole  framework is ~16kb minified and compressed.  Alpine.js  │
│  work very well on it's  owm but I think it would  be very interesting  │
│  to see if it synergize well with HTMX for the place where client site  │
│  reactivity is absolutly needed.                                        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────┐
┌─┤ CSS Bed ├─────────────────────────────────────────────────────────────┐
│ └─────────┘                                                             │
│  CSS  Bed is a collection of classless CSS theme, it let you test each  │
│  of them by  effortlessly changing the stylesheet of the site. I am  a  │
│  big fan  of classless  CSS for small  and  static  website (like this  │
│  one), it reduce unnecessary complexity  by not having to  think about  │
│  class  at  all  and only  concentrate  on semantic  HTML. Also modern  │
│  framework provide CSS isolation wich mean class are not as much  of a  │
│  necessity to avoid colision between components.                        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌──────────────────────────────────────────────────┐
┌─┤ The Moral Character of Cryptographic Work (2015) ├────────────────────┐
│ └──────────────────────────────────────────────────┘                    │
│  In  reaction to the  Snowden's revelation  in 2013,  Phillip  Rogaway  │
│  started  to  reconsider  his  role  and  social  responsibility  as a  │
│  cryptographer. This paper focus on the discipline of cryptography but  │
│  the first part does an excellent job at explaining why any technician  │
│  has a social impact, whether that's on purpose or  not, and therefore  │
│  should be conscious of his political responsibility.                   │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────────────────────────────┐
┌─┤ Shields.io: concise, consistent, and legible badges ├─────────────────┐
│ └─────────────────────────────────────────────────────┘                 │
│  Most practical badge generator I have used yet.                        │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌───────────────────┐
┌─┤ Voronoi generator ├───────────────────────────────────────────────────┐
│ └───────────────────┘                                                   │
│  This is  an  online  and  open-source  tool  for  parametric  voronoi  │
│  generation. Voronoi is a diagram derived from a mathematical equasion  │
│  that  look like cells,  there is a lot  of applications for it, but I  │
│  mostly use it for visual  design. With the real  time editing and SVG  │
│  export it's really handy for that use case.                            │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌─────────────────────────────────────────────────────┐
┌─┤ The Rise of Worse is Better by R. P. Gabriel (1991) ├─────────────────┐
│ └─────────────────────────────────────────────────────┘                 │
│  This   article  discusses   the   trade-off   between  implementation  │
│  simplicity  and  interface  simplicity   and   argues   in  favor  of  │
│  implementation simplicity. Despite being published more than 30 years  │
│  ago it is  still interesting and relevant. If you find it interesting  │
│  you can also read the counter argument "Worse is  Better is Worse" by  │
│  Nickieben Bourbaki (it's the same author under a pseudonym).           │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌──────┐
┌─┤ HTMX ├────────────────────────────────────────────────────────────────┐
│ └──────┘                                                                │
│  Make the web simple  again! HTMX is a framework for building frontend  │
│  with  the  hypermedia design philosophy.  It's  dependency  free  and  │
│  weight  only ~14k minified  and  compressed wich is really nice. It's  │
│  not for every project,  for example if you want offline  support it's  │
│  not what you should use, but it can  be used in way more applications  │
│  than  people  realize,  especially CRUDish  apps or  data exploration  │
│  apps.                                                                  │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────────────────────────────────────┐
┌─┤ Dreamberd: the perfect programing language ├──────────────────────────┐
│ └────────────────────────────────────────────┘                          │
│  It's perfect, what else is there to say?                               │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘






















───────────────────────────────────────────────────────────────────────────
  The bottom of every page is padded so readers can maintain a consistent
                                 eyeline 
       You can navigate to /awesome.txt, /blogroll.txt and /rss.xml