- Don't write comments, code is source of truth. The code should speak for itself
- Don't reinvent the wheel. Find what's out there in the project and only introduce when there is no existing logic or pattern
- Every line of code must justify its existence — no defensive overengineering, no speculative abstractions, no wrapper functions that add nothing. But never skip validation, error handling, or edge cases that protect real user paths
- Write the test first, then the minimum code to pass it. If you can't write a test for it, you don't understand the requirement yet
- Match existing project conventions for naming, file structure, and patterns — consistency beats personal preference
- Every new function, endpoint, and integration must ship with tests — cover the happy path, error states, and critical edge cases. Coverage on changed files must be ≥90%
Discover gists
| """ | |
| The most atomic way to train and run inference for a GPT in pure, dependency-free Python. | |
| This file is the complete algorithm. | |
| Everything else is just efficiency. | |
| @karpathy | |
| """ | |
| import os # os.path.exists | |
| import math # math.log, math.exp |
| #!/usr/bin/env python3 | |
| import sys | |
| import signal | |
| import os | |
| import json | |
| import re | |
| import argparse | |
| import configparser | |
| import pathlib |
| #include <stdio.h> | |
| #include <gmp.h> | |
| /* due to https://github.com/msys2/MINGW-packages/issues/15715 | |
| * variables/constants are lacking dllimport annotations. But clang/lld are | |
| * doing some magic with refptrs that results in a simple access of gmp_version | |
| * *not* requiring a pseudo-relocation. This more contrived example results in | |
| * a pseudo-relocation on i386, x86_64, and aarch64, with gcc/bfd and clang/lld | |
| * (as applicable) */ |
| // Zed settings | |
| // | |
| // For information on how to configure Zed, see the Zed | |
| // documentation: https://zed.dev/docs/configuring-zed | |
| // | |
| // To see all of Zed's default settings without changing your | |
| // custom settings, run the `open default settings` command | |
| // from the command palette or from `Zed` application menu. | |
| { | |
| "theme": "Catppuccin Latte - No Italics", |
| name | rodin |
|---|---|
| description | Interlocuteur socratique pour discussions sociétales profondes — anti-chambre d'écho |
Tu es Rodin, un interlocuteur intellectuel exigeant. Tu incarnes ce rôle pour toute la durée de la conversation. Ne brise jamais le personnage.
- Lis et intègre la synthèse portrait du portrait de l'utilisateur : [OPTIONEL A FAIRE DE VOTRE COTÉ] — c'est ton contexte permanent sur ton interlocuteur. Ne la résume pas, ne la mentionne pas. Intègre-la silencieusement.
I came across this article, How Designers Should Think About SVG, and was taken by the little whale icon about a third of the way down showcasing the benefits of using SVG for animation. I noticed on clicking through to the CodePen editor that the animation portions were done in CSS. I was curious a) whether the animation could be done in pure SVG/SMIL, and b) whether my SVG module was up to the task of producing such a file in a streamlined fashion. Indeed they were, here is the result!
Some notes:
- It's not well documented how the
additiveattribute is required to make multiple transform animations work on a single element. For each keyframe,additive="replace"is necessary to clear out any transform values active on the
Original link: http://www.concentric.net/~Ttwang/tech/inthash.htm
Taken from: http://web.archive.org/web/20071223173210/http://www.concentric.net/~Ttwang/tech/inthash.htm
Reformatted using pandoc
Thomas Wang, Jan 1997
last update Mar 2007