As the Covid-19 crisis picked up steam, my brother and I became concerned that immune status could become a gating factor for future employment and physical movement. We wanted to make sure that if immunity became a necessary condition of work or travel, it was shared privately, securely, and voluntarily, rather than tracked centrally by world government systems similar to the Chinese Social Credit System.

We partnered with a group of volunteers to build out an open-source and highly secure system for the voluntary sharing of immune or infection status. As of May 2020, the research on both immunity and testing is insufficiently conclusive to support this tool, and it thankfully looks likely that the world will continue to open up without restrictive "Immunity Passports" or a future defined by government control of movement and employment.

With the virus continuing to spread and devastate communities, however, and with dependable data remaining illusive, we pivoted to build out a tool that we felt would help individuals contextualize and understand their testing results (currently just in the US).

Based on a number of conversations with healthcare officials, entrepreneurs, and biostatisticians, we focused on building out a lightweight web app to help doctors and patients apply Bayesian analysis to better interpret testing and get a more conclusive sense of whether they have the virus, have recovered from it, or are shedding.

Two friends and I founded Left Coast Sauna in 2016, hoping to bring sauna culture to the Bay Area and "build community through sweat." We built out our first offering -- a 6-person, 13-ft-long cedar barrel sauna -- affixed it to a trailer, upgraded to a 40,000-BTU propane furnace, and drive it around for pop-ups and events around the Bay Area.

Our mobile sauna has been a blast to share and has built a significant weekly following in Noe Valley, where we run a weekly street-side pop-up. Most exciting for me, the community we were aiming to create has coalesced around the sauna pop-ups, where a sizable group of regulars from the greater Noe area comes by every week to sweat it out and hang with the sauna community.

I was heavily involved in Bernie Sanders's primary campaign during the 2016 US elections. As the primary and the election progressed, I became increasingly invested in and concerned about the security, auditability, and transparency of our electoral process.

After looking for non-partisan ways to invest in a more democratic electoral future, I found the Open Source Elections Technology Institute (OSET). OSET is working to build a full suite of quality open-source elections tools which will be afforable and transparent alternatives to the closed, outdated, and non-auditable technologies the sold by current elections-tech vendors.

Volunteering for OSET, I built out a fully-functional, accessible, cross-state and cross-platform ballot-marking application designed to slot into OSET's ecosystem of elections tools. The app -- built in React Native for both Android and iOS phones -- takes variably defined elections specs (rank-choice, etc), and turns them into a custom, and customizable, voting flows resulting in data blobs to be handed onto the next link in the OSET technology chain.

My brother and I worked on PlanIt for roughly 9 months, during which the concept evolved considerably. Originally conceived of as a tool for ordering and displaying travel itineraries, it morphed into a tool for bookmarking and sharing wishlists of places at home or abroad. Shortly before we let go of the idea, we began working towards another version: An app for browsing friends' and other trusted sources' recommendations, bookmarking the exciting ones, and then taking the final location-based list offline for use abroad.

I wrote a post about what I think we did wrong, and why we dropped the idea, but a considerable amount also went right. The two of us (one of whom had no coding experience at the start of the project) planned, designed, and built a substantial amount of pretty nifty software.

Our final application included a bookmarklet which could be used to scrape relevant travel data from nearly any website (including ordered multi-location narrative data like the New York Times' 36-Hours series), and then send that data back to our site, where it would be parsed for its locational components, "completed" by running selective portions of it through a series of APIs, and then added to the user's relevant lists.

We streamlined the list concept by auto-clustering locational data by Geonames units, which we further abstracted into more sensible colloquial location units, and then displayed this data for browsing in an interactive world map (powered by Angular/Leaflet) that allowed for differential interactive behavior at a high-level (country-wide browsing), and a low-level (location-centered browsing/addition of individual restaurants, museums, etc).

We layered on top of all of this a robust and completely hand-rolled Angular SPA architecture, which allowed users to move from world-level browsing to city-level note-addition or bookmarking, without ever reloading the page. Users could toggle between map and list views, take a large variety of actions, and manipulate a large and growing body of frontend data, all of which was lazily cached and shared between the "horizontal" and "vertical" layers of our SPA.

To spare our server and keep the user experience fast, we backgrounded a large number of application tasks -- place addition, bookmarklet functions, note-taking, bulk actions -- while maintaining the interactiveness of the platform by opening a line of communication between backgrounded and current tasks using Pusher and an internal API.

Throughout, we maintained Rails/Angular best practices. Our largest model file (by a mile) was less than 200 lines long (and our largest controller roughly 100). Instead, we consistently moved our logic into serializers, decorators, and a large number of interrelated, namespaced, and extensively unit-tested POROs, which isolated data completion, scraping, information interpretation/display, internationalization, and more.

Our extensive test suite was just short of 100 feature, request, controller, and unit tests, and was optimized to run in roughly 1 minute. It included automatically changing tests (for the scraper, which would periodically re-scrape data to test whether our expectations were current with external changes), and several meta-coded site-wide tests, including one which automatically made requests under a variety of user roles to every page and API endpoint in our website and set expectations for the response.

Although we eventually dropped our idea rather than pour additional time and capital into it (more about that decision), I am extremely proud of the quality of the work we did on PlanIt, and I know we both learned a huge amount in the process of testing and building it out.

Unfortunately, we stopped working on PlanIt in buggy mid-stream, and I've since stopped paying for hosting the non-functional site. If you're interested in walking through a demo, let me know.

My first web app. A tool for allowing groups of people to easily purchase part of a whole cow, pig, lamb, or goat, greatly simplifying the process of purchasing any quantity of meat directly from a farmer.

An attempt to merge the monetary and transparency benefits of direct-from-farm CSA meat purchasing with the ease and choice of retail, MeatUp, allows users to purchase specific cuts -- prepared however desired -- from specific animals. It then handles all the back end of the purchasing process, contacting farmers and butchers and coordinating pricing and weight calculations in an attempt to sell off the whole animal in a quick and simple online 'auction'.

I began working on MeatUp during Bloc, and tackled its wide range of coding difficulties as the curriculum progressed. The site involves five user roles -- purchaser, admin, host, butcher, and rancher -- each with separate permissions to separate data and sub-pages. It requires a self-updating mechanism (the real proportions of each animal affect future calculations) for calculating animal cuts based on size and breed, which I had to create from available data and vary by animal type and weight. It has a custom e-commerce solution, built using Javascript and Rails and dependent on four interacting 'models' representing the animal data. It has integrated email, purchase timers, blog, and more, all wrapped into a custom design scheme.

The site was a difficult and exciting first project, one which I feel represents not only my abilities but my excitement about tackling new and difficult problems and turning them into elegant solutions.

Christian Schlensker and I built the Bloc Office Hours chat application (nicknamed "Tweed") over several days to address a wide variety of concerns elucidated at length in this post.

We'd been using a private HipChat app, but found that no option -- paid or free -- allowed us all of the funcationality we needed to offer functional and trackable office hours. So we decided to build our own.

Tweed was built on the foundation of a basic Meteor chat app like that described in Tom Coleman and Sacha Greif's wonderful tutorial. But then we layered on considerable additional functionality:

• We had each chat message and entrance/exit of rooms send out individualized event notifications to a Bloc-built event tracker, to enable us to identify peak and trough hours and effectively triage mentor hours.

• We integrated with a meteor Markdown plugin to render code snippets.

• We added audible and visual notifications for messages.

• We built a variety of rooms -- one for each course -- and a permissions system that varied room visibility/entrance by student/mentor type and role (student/mentor/admin)

• We set up secure cross-site authentication, so that each Bloc user had unique Tweed login information, which would automatically sign them in and out, and which passively expired at the end of the course, but could be extended on command.

• We added private chat, exclusively at the command of mentors, so that mentors could keep track of the "queue" of questions while addressing them with minimal confusion one (or multiple) at a time.

The app was my first foray into Meteor, as well as Christian's first major Meteor app. It immediately saved considerable amounts of time and money, as well as improving student experience and admin insight. And it taught me a good deal about Meteor and server-side JavaScript frameworks.

Unfortunately, Tweed is no longer up to demo or record live (which would, at any rate, invade student privacy). I pushed to replace the Tweed Office Hours with a Stack-Overflow-integrated QA system (for a variety of reasons, mostly focused on learning quality) shortly before I left Bloc. So all I can share is this GIF I made locally.

AVA Describe is an NPM package for nesting tests in AVA (a very lightweight testing runner/matching library) into more human-readable describe and context blocks, like those common with other JavaScript testing tools.

Shape (technically, matches-shape) is an NPM package for asserting and testing object shape in JavaScript. It provides a simple syntax for declaring what an object structure should be, and for testing that declared shape against the received object, and storing any failures for easy access. Particularly useful for testing the output of inconsistent APIs.

Redux Request Manager is an NPM package which simplifies the staging and throttling of API requests through Redux API Middleware. It tracks API requests and provides a simple set of methods for making API requests only in certain cases (if a request hasn't been made before, for instance, or hasn't succeeded in the last 5 minutes).

RS Components bundles together a set of React components that we reuse at Redshift across a range of projects. They're all coded to be as flexible as possible -- our Dropdown, for example, allows for single and multiple selection and arbitrary visible content -- and are built to work out of the box in a React-Redux project. Clone the repo and see the React Cosmos playground to explore the components.

PG Clone is a stripped-down wrapper for Heroku's PG Backups tool that makes it simple (and worry-free) to pull down production data and restore it to a local database, either in the command line or the Rails console.

MeFirst is another Ruby gem designed to make Active Record reordering a no-brainer. Using a simple ActiveRecord-like pattern, a coder can declare a given database column as an attr_orderable, and then easily reorder objects by that table column. MeFirst takes care of the insertion, re-ordering, and table collapsing, keeping your data neat, and removing the need to re-think table ordering app by app.

Falcon Deploy is a simple wrapper to make it easier and less nerve-wracking to deploy to Heroku and roll code back when you mess things up. From the command line, you can simply orchestrate a deploy, a deploy with migrations, and a rollback of your latest code, on Heroku. Falcon will keep track of deploy tags and make it easy for you to batch deploy/migration and to roll your code back when you mess something up.

A dead simple app built in a day, Quote Owl was a simple response to my desire to be regularly, simply reminded of the quotations I found meaningful.

Rather than buying into a preexisting quote list, or dealing with a clunky interface, users can build a list of their own, through a simple email interface. Every day, a quote is sent out by email, and that same address can be responded to to add any new quotes.

A simple point tracker ensures that you don't see the same quote too frequently, and a basic subscription system allows multiple people (ex: me, my brother, and my uncle) to subscribe and add to the same list of quotes.

Lightweight and straightforward, this one-day Rails app has added a lot of happiness to my life.