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


===========================================================================
                     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.         │
│                                                                         │
└─────────────────────────────────────────────────────────────────────────┘


  ┌────────────────────┐
┌─┤ 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