Yeah, that's about it. Ironically, considering my job, I'm not a very online person.
that I made.
Thread local storage without the gcc/libc runtime
A few options for implementing thread-local storage (on x86_64) without support from the gcc or libc runtime.
CPU Wavefront/SIMT Multithreading
Brief(-ish) demo implementing the fork-join multithreading style usually associated with GPU compute programming, but entirely on the CPU. Also, it's completely, 100% dependency free.
Dependency-free Hello World on Linux
No dynamic linker, static executable, no dependencies, no standard library. The very first assembly instruction executed is your code.
Short example of how you might implment an Odin/Zig style context system in plain C.
Odin & C Calling Each Other in WASM
Short example of how to get C and Odin able to call each other when compiled to WASM.
Hand-written ELF file in NASM assembly that responds to TCP connections with an HTTP response.
Using Unsupported x86_64 Instructions in Odin
Notes on using x86_64 instructions that Odin doesn't support, in Odin. Specifically vpmovmskb.
Automating GDB restart on program build.
Basic example showing how to get GDB to automatically restart the program whenever the compiler successfully rebuilds the program.
Simple sysv64-compatible asm routine that disables stdin line buffering on x86_64 linux.
A daemon that connects to Telegram and lets you write bots in any language that can speak over stdin/stdout. A throwback to classic CGI.
A simple Rust library for writing some pixels as a .bmp file.
A simple Rust library for creating & parsing signed & encrypted cookies.
A simple Rust library for parsing PCF files - a format for bitmap fonts.
Some useful bits of code/info that I find myself needing occasionally on different systems. This is a convienent place I can always find them wherever I am.
My preferred css reset flavor. Tries to reset all styles for all elements to black text. No margins, no padding, no backgrounds; not even on buttons.
Not my full vim config. Just a few things to make raw vim useable on a system without my full config.
A post-receive hook for a bare git repo that will checkout the newest version of the repo into a worktree somewhere on the file system whenever updates are pushed. Because I can never remember the exact command.
Simple tool to help memorize Bible verses.
Simple fish script to create a new rust project and open it in an editor. Like a local alternative to the rust playground.
that I use.
A calculator.
A hex editor.
A text editor.
A git GUI.
You should still learn git though.
A debugger.
Another debugger.
A terminal.
A linux flavor.
A scrolling window manager.
A shell.
A keyboard.
A mouse.
A tool to learn keyboard sightreading.
A tool to learn anything.
A search engine.
A pencil.
A hosting platform.
A web browser
A Firefox privacy plugin.
A password manager.
Since the original site is no longer available, I'm hosting a patched & working version of the DCPU-16 IDE by John McCain (dangermccann). I've found DCPU-16 assembly to be among the easiest assembly language for new programmers to learn due to its simplicity, lack of an operating system, and this dead-simple browser ide.
Original IDE source code on Github
DCPU-16 & various hardware specifications
Since the original site appears to be down, I'm hosting a working version of the Elm Package Browser originally written by pravdomil. It's an alternative to the official package browser that is much nicer to navigate and use.
The original code base appears to be gone. I managed to track down a copy of the repo online somewhere which I resurrected here.
Seriously, you have to play this game. As soon as possible.
I consider these papers must-read material for all programmers.
Out of the Tar Pit by Ben Moseley and Peter Marks
Complexity is evil. See also: Simple Made Easy, a lecture by Rich Hickey
A Relational Model of Data for Large Shared Data Banks by E. F. Codd.
This paper forms the basis of all SQL & all relational database systems. It's also surprisingly short and readable.
Reflections on Trusting Trust by Ken Thompson
The security of your code is a lie. No, it's not your fault. No, there's nothing you can do it about it.
The largest collection of Actually Useful tutorial material on programming that I know of. Even just the first 5 Intro to C on Windows videos contain more valuable information than at least two programming books I've read. The rest of it is targeted at game development, but I've found much of it to be useful everywhere.
Melissa O'Neill on Random Number Generators
Good video on Random Number Generators and how they are constructed.
A staggered pinky-finger column because that finger is shorter than the rest, and chorded symbols because using shift to type programming symbols makes me sad.
Talks that changed the way I think about programming by Oliver Powell
Great collection of talks that Oliver has put together.
Benchmarks by Max Slater for various hashtable implementations to give you a rough idea of their general performance characteristics.
Things I want to write down, but don't have the time or inclination to explain or support.
Don't use first_name and last_name fields when storing user names. Names have no structure. Some people don't have a last name. Some people should be called by their last name rather than their first name. Even if your user base is limited to the US. Using first_name and last_name fields in your database will make you sad at some point.
Instead, use legal_name, display_name, and sort_name fields.
See this.
Don't convert times when receiving them from the user. Store them as-is, as a string, exactly as entered. Convert to UTC or local time as necessary during display, not when the data is stored.
Design is something you can learn. Like most things, it requires study and practice. (Yes, even programmers can learn it.)
Microservices are not the answer.
Complexity is the largest issue with nearly all modern software by a huge margin.
See Out of the Tar pit in the papers section above.
Structuring your program's memory management around a global heap allocator like malloc produces bad, and often slow, code. There are almost always better allocation strategies to use. Try a Bump allocator, a freelist, or just allocating on the stack if possible.
Libraries should not allocate unless they absolutely positively must allocate.
Rust libraries should be #[no_std] and not allocate by default. They should only depend on the standard library if they have a reason to.
Programmers' apparent unwillingness to spend money on software tools is ridiculous. Buy a text editor or debugger if it's good. $99 for something you use almost every day is a steal.
Type systems are indispensable when writing maintainable software.
Writing a production software application (which includes server software) in a language that doesn't have a strong type system is bad engineering. The benefits outweigh the costs by so much that there shouldn't be any question.
The placement of Control, Alt, & Meta makes no sense on modern keyboards. They require way too much contortion to use with the regularity that programmers need them, and often lead to wrist pain over time. Use a keyboard with thumb-clusters or home-row-modifiers.
The placement of the arrows, home, end, page-up, and page-down keys makes no sense on modern keyboards for text editing. They're used more frequently than most other keys, and must all be pressed with your pinky-finger on most keyboard layouts.
Use a keyboard with a navigation layer that places them where your index, middle, and ring fingers are, or, if possible and you want to learn them, use vim bindings.
Modern membrane switches are actually pretty nice. Acceptably clicky with a pleasingly short travel distance.
hjkl for navigation with vim bindings doesn't actually make sense. It should be jkl;. See this.
You shouldn't change the default though. The normal vim bindings are too common in other software and you can't change it everywhere.
A Proper Programmer should be able to type. 50wpm with symbols at a minimum. 70-80wpm would be better.
A Proper Programmer should be able to type approaching 100% accuracy. (Accuracy can and should be practiced if necessary.)
A Proper Programmer should understand C.
A Proper Programmer should understand assembly.
A Proper Programmer should know how a CPU functions, at least at a high level. What is a register? What is a core? What are the performance characteristics of the L1, L2, and L3 caches? What are the performance implications of a cache miss? (And how does that relate to the performance characteristics of a linked list vs an array?) What is a SIMD register?
A Proper Programmer should be able to implement a Linked List without googling.
A Proper Programmer should be able to implement a binary search without googling. (Not because they need to know how, but because if they can't work through the logic and derive the algorithm without googling, something is wrong.)
A Proper Programmer is something that a Web Developer should be.
A Proper Programmer takes years to become. Probably somewhere around 10 +/- 3. Definitely more than 4.