This was a part-time gig, where I would make myself available on a schedule for one-hour mentoring sessions for web development bootcamp students. These thrice-weekly one-on-one mentoring sessions would supplement their classes and project work. I covered html, css, and React, but focused on the fundamentals of javascript, especially functional programming.

There were often situations in which I needed to tally a series of numbers, to add up, and/or get an average. But a calculator doesn't easily allow me to visually track the numbers (for example, when counting collections of things), nor edit them, nor get multiple calculations (like sum AND average, etc). Spreadsheets let me do that, and they can be available online. Still, these are "heavy", enterprise apps, designed for processing large quantities of figures, and supporting complex math. It felt awkward to spin one up to estimate my grocery bill. I couldn't find something in between a calculator and a spreadsheet, so I came up with Microtables. It's optimized for mobile use, ephemeral by default, and meant to be easily invoked to punch in a few numbers and get the answers you need.

I wrote the whole thing from scratch in clojurescript, with the notable exception of the math "engine" itself, which is supplied by mathjs. I had to figure out a data structure that would allow for sparse data entries, quick lookups, and easy references. As I discovered (having never been involved in the development of spreadsheet programs before), that last detail was very important. Any time one cell contains a formula that references another cell (or a whole range of cells), there needs to be a link between those cells. If there are any cycles, then it causes problems. The map of references must form a DAG, which determines the order of evaluation. It was fun to figure out (and all this was done before AI, and before I used clojure in my day job).

Although the absolute basic functionalities work, this project is still incomplete. Future features will include a more mobile-friendly interface (ie: a wide range of functionalities made available for fat fingers), a dynamic spreadsheet size (it could be infinite-scrolling in both dimensions, but I capped off the size for my demo), other interface conveniences (like an always-present sum for columns), and visual polishing. This being a side project, AI will definitely help with these.

I had a need to manage playlists of videos to watch or listen to without logging in to any service, so I created a browser plugin for it. It consists of three "parts": a context menu button, a background script, and a popup window. The context menu button lets me right-click a link, and add it to one of the playlists. It does its best to attach a title to the link (usually, the innerText of the a-tag itself). The background script watches for video-tag events (like play, pause, and ended). When a video ends, the script checks if the currently playing video is in a playlist, and if it is, it navigates to the next link in the list. Finally, the popup window lets me manually edit the playlists.

There are other little features, like tracking a viewing history, exporting the playlists and the history as a json download, and importing json data to restore a set of playlists. Some more bespoke features include copying to the clipboard a wikitext-formatted link to the video (mainly for my digital commonplace book), and saving the channel to another custom service that I run. Future development may include communicating with a remote server, which would take the place of downloading data as json files.

This project was almost exclusively AI-coded. I was originally experimenting with a tool called codemcp (mainly to save on costs), though I have since switched to claude code. The style of development was giving the LLM very small tasks, and with few exceptions which I corrected manually (or through further prompting), I had no problems with the outputs. It also made some initial recommendations in technology choice, like alpine.js, which I had not heard of before, but found to be just right for the job. I also asked it to record the context for each session - though it usually only summarized the work done. I thought it could help me understand how the models improve over time, though I doubt I'll have the time to study it.

I've maintained a journal and/or a daily log since I was in high school. I enjoyed tracking the data in my life. In addition to thoughts and feelings, I focused a lot on events: what I did, and what happened. I also recorded how many steps I took (using a pedometer clipped to my belt). At first, it was all in plain xml files (why??) so that it would be structured, and potentially machine-readable. This was before I really knew that databases were, but I also wanted to read them easily. I even pulled the day's weather data (I think from Yahoo or something) to include - all to help my future self understand my state of mind and being.

I upgraded my very first client (which, if I recall, was in Flash Actionscript) to a web-based form, which submitted the inputs to a mySQL database. Years later, I scrapped it and started a new system from scratch. This is the one I have today.

The visual interface is based on a dynamic timeline - a single line that stretches from top to bottom, and which is punctuated by dots which represent the events that happen, at the time they happen. Items that don't have specific hours or minutes (like that day's steps, or thoughts I want to record) go on the side of the timeline, next to the day that this data was recorded. There's a different section which compiles and displays statistical data, such as number of hours of sleep and fuel prices. There's also a feature which lets me take a snapshot of my face from the webcam. The timeline is "infinite": I can click to request any day, and it will load onto the timeline without refreshing (with a visual break in the timeline representing elided days). To add an event, I click on a "plus" button that's near the hour I want, edit the exact timestamp, add an event type (there are several to choose from, like generic event, meal, sleep start or end, etc), then write in the content of the event. There is also a separate mobile-optimized web app that I created to support the quick insertion of new entries (see the section on "Daily Instant").

There are a lot of features I'd like to add (many of which have been sitting on the to-do list since time immemorial). These include a robust search feature (I'm currently accessing the database directly for searching), and more sophisticated event content payloads. I'd also like to open-source the project, though I (foolishly) hardcoded some security features and server details early on. Still, my target market (aka: me) has been pretty happy with it.

Part of the mission of the bitcoin consultancy I worked at was to make blockchain more accessible to people. Many of the people they worked with were investors or business executives - intelligent, but not necessarily tech-savvy people. I took it upon myself to help explain how the fundamentals worked, since that greatly helped me demystify the blockchain, and understand what value it was producing.

I created a website with several tabs, each one covering a different component of the foundations of blockchains, like hash functions, public key cryptography, or block mining. I tried to demonstrate visually what was happening with the data. I also made it interactive by letting the user input the data or deciding what to do with it. I think the coolest part was the block mining demo, which ran a mining simulation right in the user's browser (though of course, the difficulty was scaled down for convenience).

Future plans included adding a textual explanation (or audio description that interacted with the demo itself) to each of the tabs, and move on to further concepts, like how the Lightning Network worked. In the end, although I had the support of management, we soon after moved on to other projects (like timestamping and blockchain auditing) before I was able to "complete" this one.