it's bad form to expect people to write code on the weekends, or assume that the only people who are good at programming are the ones who pursue it as a hobby in their own time.
i used to write a lot more code when i wasn't so burned out, and of late i've come to realise that the best programmers i've worked with are the ones who handle the social aspects well, and that's something you don't really get much practice in when you're working by yourself on hobby projects.
that all said and done, people in tech regularly have their own little side quests, if only to scratch an itch, write code they want to write, or just experiment with things they'd never get to use otherwise.
i've been that kind of programmer a few times, often going "this sucks, i wonder if i could do better" and then adhd-ing myself both into and out of the project. this post is my attempt to capture my own little potted history of the random distractions i've engaged in in the last decade or two
most of the side projects don't bear more than the briefest of mentions. like many abandoned prototype models, or some experiments in java to understand arrow/monad style composition. there's just a few i want to highlight, and I guess it's all part of the same thread
especially because i've written a lot of RPC systems.
the best place to start is back when i wrote a distributed web crawler, and that involved hacking some god awful RPC together. and frankly i'd already gotten sick of it. i'd already lived through soap, wsdl, rmi, and even some corba. every single tool promised you "code generation" and then you'd end up wrapping that code on both the client and the server.
it was usually easier, quicker, and far less frustrating to just bodge something up yourself. so that's what i did. no regrets.
my coworker and I had been playing with 'representational state transfer' because it was in fashion at the time, and stumbled onto something i haven't seen any other rpc or hypermedia-like system do.
the tl;dr? it looked more like a website and a screen scraper. you'd write the server code, and through the magic of reflection, the server would generate a webpage with all the methods on it. the client would fetch this webpage, and once again through magic, you'd generate a client stub.
in other words, we'd gotten rid of schemas entirely. you could connect to any service in the system, look at the methods and objects available, and just start debugging without having to ensure you had the right wsdl, soap api, or boilerplate. every service used the exact same client library.
it was so nice that i ended up hacking on it several times over, under various names, exploring different feature sets, and just wondering what i could do to convince anyone else it was worthwhile.
at one point i even added tab-complete to the rpc command line tools. you have no idea how nice it is to sit and explore an api from the command line when you can just browse through it by hitting tab.
the proof of concept code was called trpc https://github.com/tef/trpc, if you're curious, but one day i'd like to trick the proto/grpc people into doing something similar. there's already some extensions out there to make apis a little more self documenting.
aside, the tab complete stuff came from another project, one written mostly as a joke. "textfree86", or a network transparent cli library.
the idea was you'd write some command line program, and you'd get a client side wrapper for free. it would let you run your program on another machine or sandbox, and interact with it locally, passing in files as arguments, and it magicked the problems away for you. it was worth it for the pun alone.
it also ended up using one of the encoding formats i'd hacked up many years prior.
in one job, i needed to send bytestrings and unicode, and json just didn't work out. i shrugged and copied over bittorrent's bencoding, because it's a dirt-simple type-length-value style serialization format. it's something i'd willing do again, the code is absolutely trivial and it's a lot easier than trying to base64 things into json.
it really is damning that most of my side projects have been around rpc hacks and encoding protocols, but there was at least one side project that was sufficiently different than anything that came before
i wrote my own version control system.
someone i used to know had been hacking on git, documenting things as they went, and for a laugh, i figured i could join in, in my own stupid way. git isn't like earlier control systems, which carefully tracked history through a series of patches to apply. git just goes "here's a snapshot of whatever's in the project" and it's a lot simpler to implement.
that wasn't enough for me. i wanted to make something better, so i added in undo and redo.
i also added in tab complete. i made everything output through less. i renamed commands to reflect what the user was trying to do, rather than how they were implemented. i made it so that authors were stored as uuids, so you could change your name or email, and not have to rewrite history. i even made subtree checkout work, as well as stashing changes automatically when you switched branches.
it was kinda nice, but in the end i got bored of hacking around git's limitations, and i didn't want to implement diff or patch. you can see it for yourself over here, https://github.com/imbal/vex if you're curious.
and predictably enough, i wrote my own clone of json to store settings and config. i added in comments, trailing commas, and let you tag objects with custom names.
you can see it yourself over at https://github.com/imbal/rson and honestly it's one of the most polished turds i've written. i hummed-and-hawed over many of the design choices, and tried my best to walk the line between must-haves and nice-to-have things that would have made it impractical. (and in some ways, it's a near direct descendent of the bencoding knock-off i wrote several years prior.)
the other thing that vex kicked off was an improved cli toolkit. i wanted something much nicer than just "dump plain text into less." i wanted to be able to resize my terminal, and not lose my place in the output.
so i decided to write my own cli toolkit that handled terminal resizing. you can find it over here https://github.com/tef/toyparser2019 but it's very much a proof of concept.
the thing was, after writing my own rpc clients, writing tab complete in numerous forms, and playing around with textfree86, i'd stumbled on a really nice way to write cli programs: write them a bit more like a webapp. turn the command line into a request, pass it into a router, call the command you find, and format the output.
it's honestly one thing i'd like to see other people try out, i found it much nicer than wrangling argument parsers, writing my own main loops, and best of all, when i resized the terminal, the document got reflowed and i didn't lose my place in the output.
... and predictably enough
i wrote my own markdown variant in order to do it. markdown has tables in some variations, and some other extensions, but no generic latex-alike way to say 'this block is an aside' or 'this list is a todo list' or 'this thing is a section' without breaking out into html.
(and in order to do it, i wrote my own parser generator for peg-like grammars that supported indentation, and then wrote a commonmark parser to test it out first. i'd been hacking on the design ideas for almost seven years, after one job writing children's workshop materials and finding markdown absolutely painful to use)
... and that's what i've been hacking on of late
it does feel a little silly to say "well, i wrote my own object serialization format, so i could have a dom for a custom markdown format, so i could reformat text in a terminal on resize, so i could have a nicer cli toolkit for writing a custom version control system, which uses my own rpc design based around representational transfer" but that's how the yak gets shaved
