Mixer Mayhem

The Terrible Ideas Hackathon is a time to encourage seeing things through. Often, we place so much importance on the success of our projects that we are uncompromising in its features and paralyzed by its scope. Good ideas warrant reasonable effort, and they demand to be delivered correctly. This hackathon encourages us to "just make something" by confining participants to make something clearly terrible, freeing us from the pressures we place on good ideas.

Given my track record, it's abundantly clear that I have no issue pursuing terrible ideas. This hackathon was no different, with a devilish plan to punish our friend and event coordinator for the hack, Zac.

The plan: A community-controlled automated bartender.

An execution with many moving parts

Project planning can make or break a hackathon entry. Every team member should be on board with the scope of work the team is committing to for the weekend and which stretch goals come next. We outlined a clear list:

• Poll the audience for an ingredient to add.
• Poll the audience for the amount to add.
• Track how much was added and assemble the drink.
• Get Zac to drink it.

Available to us were three peristaltic pumps, but we wanted more than 4 combinations. Hayden, the Unleash Makerspace resident "making" expert, team member, friend, and ex-colleague, quickly fashioned a "flavoring" module using a pipette and servo. The servo would actuate the pipette to deploy the flavoring, and we would manually refill it after a few uses. We were able to assemble four of these, poking the ends through a hole drilled in the top of our container; a microwave. The last component was a small vegetable glycerin heating chamber (effectively a vape) attached to an air pump. After making a drink, we could fill the microwave chamber with smoke for dramatic flair.

We had nearly 30 combinations in total. Users could add up to 3 "base liquids" and 4 "flavorings."

Microcontrolled delivery

The implementation for this was kept as simple as possible. Each of the servos and pumps was attached to its own GPIO control pins, and the code contained a specific function for each one. In a hackathon, we often write suboptimal code; the most important thing is delivery. There is no expectation of maintenance so long as the initial project scope is laid out clearly. In this environment, there are limited advantages to writing good code in small components.

The application would receive a formatted command over serial, such as "L3S1", meaning "liquid 3, serve 1". Equivalent inputs were made for the flavorings. The simple string input over serial meant that it was easy for the microcontroller to parse and easy for the server to produce.

The server

We were expecting many clients, who would all need to receive updates from the server as the status changed. Given the scale of this application, we could have had the front-end poll the API for the updated state but instead decided that the duplex connection of WebSockets (in the form of Socket.io) would provide us the best experience.

Our clients need a publicly resolvable hostname to connect to the server. Due to peer isolation, we couldn't host our application on the network at the venue, so it needed to be deployed to the cloud (AWS).

A common problem I've experienced while working in hackathons is the issue of CICD. The hassle of setting up a CICD pipeline for a backend service is usually relatively high, and even though services like Railway aim to make this easier, it's often still not worth the hassle. Despite this, no CICD means that multiple contributors need a way to deploy their changes for testing in "production." I have historically avoided this issue (for backend services), by using a slightly unusual pattern:

Click to reveal...

The WebSocket server deployed on AWS Lightsail parrots all payloads from all clients to all other clients. Without authentication, one client connected to the server is responsible for implementing all required business logic.

As a pattern, it could never last in a production environment. Still, it's the perfect simplicity required for this use case. All those contributing to the application can test against the real web socket server, code deploys are as simple as git pulling on one client, and network hassles are avoided by moving the entry point off-site.

The beginning of the end

With only four hours remaining, something catastrophic happened. Someone pulled, rebased incorrectly, and force-pushed to the main branch. Attempting to help fix this, the rest of the team working on this component pulled the main branch. In an instant, hours of progress were demolished. Likely, all of those commits live somewhere in the git, headless, waiting to be recovered. Despite my best efforts, it was lost.

A somber hour dawned on us as we discussed what to do next.

It was decided. We still wanted to engage, and we already had a functioning terrible idea - the machine - so we ran the demo anyway, manually surveying the crowd, inputting the commands, and serving the concoctions from the hazy microwave chamber. Zac consumed his milk, orange juice, Coca-Cola, and Tobasco nightmare, and our initial goals were complete.

Conclusion

Reflecting on how the hackathon ended, it's a reminder that the most crucial first step is early market validation when building something new. We often talk about MVPs, but they're not the first step to validation. The P, product, means that you've already found "traction," as the lean startup tells us. Although we devastatingly lost a large amount of work, and what was delivered at the end differed from what we had envisioned, the functionality remained the same. We had effectively delivered on the goals we set out for initially.

I chose to focus on hardware during this hackathon. I rarely find myself allocating the time to embrace the physical "maker" in me. My contributions could have been more valuable had I worked on the software. Still, the team was already comprised of aspiring engineers eager to make things with their newfound skills. As always, I'm available to support those team members with anything they struggle with.

In light of what happened, we built a fun and engaging automated bartender, worked with amazing people with whom I hope to work later in my career, and achieved the goals we set out to achieve. There are lessons to be learned in preventing these kinds of losses from happening in the future, and we'll take them into our next endeavor.

I'll miss the next (and first) global Terrible Hack in late 2023, but I'll ensure my attendance at the next one.