Santa Barbara—October 2016

@r00k and @ehmorris learn Elm in Santa Barbara

This Codecation had a lot of dodging and weaving. It took a few solid days to figure out what we wanted to work on. Here's the path we took.

Enriching Customer Data

First, a product idea: what if you could learn a bunch about your customers without surveying them?

We took a collection of FormKeep customer emails and fed them into Clearbit's data enrichment service.

We then imported that output into Google Sheets to use its "explore" feature, which automatically generates interesting graphs about your data. Turns out, there were some interesting things in there! Stuff like most common industries served, average customer size, etc.

We made a landing page for a potential product that would do this automatically for non-technical types. We got a few initial emails, but in the end, neither of us were really excited about the project, so we ditched it and turned our attention to a lovely little language called Elm.

Multi-player Pong

For our first task, we decided to create a multi-browser version of Pong. We started with this already-written single-player version. Our goal was to use WebSockets to send the paddle information between browsers. We did indeed get a simple version working, but quickly realized our implementation (keeping states on both clients and trying to keep them in sync) was inherently flawed. The next logical step would have been to move logic and state to the server, but we wanted to keep learning Elm (client-side only), so we switched projects once again.

Genetic Image Generation (in Elm)

Finally, we found the project that we'd spend the rest of our trip on.

Inspired by this excellent JavaScript implementation, we decided to build an Elm version.

This proved to be tougher than we first imagined (duh). Some particularly thorny bits were handling the randomization and making sure the UI actually updated while we were in our computation loop.

You can see how we handled these issues in the source code, but be warned that you're looking at how two relative newcomers solved these issues.

What you're seeing is a collection of 125 randomly-generated polygons. With every iteration, we mutate some of them at random and see if our mutant is more similar to the goal image than previously. If so, we save that mutation and mutate it. If not, we just try again from our previous best.

(Note: this demo currently only works on retina screens due to a frustrating bug around pixel densities. If you're seeing only green on the right, that's the issue.)

Genetic Image Generation (in ClojureScript)

Frustrated by the difficulty of using randomness in Elm, and the difficulty of creating memory-only canvas elements, we tried re-writing our solution in ClojureScript. This is actually still in WIP status. While ClojureScript was delightfully permissive in letting us interop with JavaScript directly, we deeply missed the strong typing and quality error messages from Elm. Before finishing, we decided to return to our Elm implementation for some final improvements.

Though we spent most of our time inside on computers, we did get out. Here we are on the "Fisherman's Wharf" of Santa Barbara, after renting bikes.
Edwin stared intently at the beach wondering why Elm's markup functions are so frustrating.
Here's Ben enjoying our very deep outdoor couch.
Here's Edwin caught in a candid moment posing normally.
Garden views.
We spent many quiet moments at night shouting "FUCK" and inserting the keyword Random wherever we hadn't tried yet.
After 20 minutes Ben discovered that you need to run JavaScript after document load to access the document.
We tried working from a courtyard, but a local dog tipped us off that we were being watched by a drone, so we left.
Ground we covered in Santa Barbara.