Streaming Open Source Work: One Hour, One Day at a Time, Live on Twitch

It started as an experiment: I had a semi-functioning stream for my personal work, and we decided to start streaming our IOpipe open source lab projects.

The hardest part was getting the A/V setup to work on both sides (Zoom video chat became an unlikely, but indispensable, part of our toolkit) — mostly because problems only ever seem to arise when we were live!

If you think I’m kidding, take a gander at the equipment we use: We both use 2 machines — a Windows machine for the actual stream, and a separate laptop for coding. Erica uses 2 separate microphones and webcams, whereas I’ve managed to make it work with one of each. Erica uses an HDMI capture card to send the video from her coding machine to her streaming machine.

We use Zoom in a roundabout way: I join with my coding machine, and my Windows machine if I’m running the stream, and Erica joins with her Windows machine, which outputs her coding machine from the HDMI capture card. Then the driver screen shares via Zoom — this allows the Windows machine to stream the code, and the remote control functionality allows for pair programming.

Turns out, juggling multiple machines can sometimes cause issues.

However, several weeks and streams later, we’ve found some success. Nearly every weekday morning, Erica and I log in and go live, broadcasting and recording our pair-programming, open-source adventures.

We set some ground rules for ourselves right away:

• We go for an hour each morning
• We’re pair programming; one of us drives, one watches and comments, searches and encourages
• We work on open-source initiatives
• We interact with our audience, answer questions
• The underlying purpose is, and has always been, to teach by doing; by making mistakes and building and not hiding or polishing our process

These rules worked for us in our context, but if you do your own code stream, you should figure out what works best for you!

So far, we’ve worked on:

• a RequestBin-style service that runs on AWS Lambda functions — we were sad to see the publicly-available RequestBin site go, so when we needed a good real-world example for serverless application, we couldn’t think of a better example than a RequestBin service written to run in AWS Lambda functions.
• eva, a cli tool for emulating AWS events — Eva is a CLI application that enables developers to work with events to store, replay, deliver, and proxy. It is designed to work with event-driven serverless systems. It can generate events, store and dispatch, and even replay events, and is aimed at being a tool for serverless architectures.
• grassbian — a Raspbian Linux image meant to work with AWS GreenGrass right off the image burn. We’re working off of pi-gen to create an image where you burn it to SD, add your credentials to the root filesystem of the card, and the image handles the rest on the first boot of the raspi, saving potential AWS GreenGrass users quite a bit of time.

We’ve worked in JS, Golang, and Bash scripting. We’ve gone from 20 minutes getting the mics to work to 60 full minutes of code and code-adjacent activities: git commits, reviews, quick lessons. We’re constantly working on our technique and banter to provide a rewarding experience for our viewers.