Software bricoleur, word wrangler, scientific skeptic, and logic lumberjack.
In the past I've written and participated in the development of several of our courses.
I wrote the prose for this short course with a lot of help from the rest of our team and Matthew McCullough.
We tried to keep the scope of this project small since most people don't like or are afraid of using the command line. We reproduced a shell (thanks to Adam Rensel's hard work) that would execute git commands and produce realistic output.
I still remember when we released this on July 4th, 2012 and GitHub announced it on their blog. I had to scale the Heroku dynos for the course from my bed using Nezumi because I could tell we were starting to be slammed with visitors.
This was the first Code School course I ever had to teach in front of a camera, and that along was more than a little bit stressful. Aside from some limited exposure, I learned most of what I know about RSpec while working on this course. I also received a lot of useful advice from people like Envy Labs' Nathaniel Bibler who had written and taught our previous testing course: Rails Testing for Zombies.
My second Code School course as a teacher. Although I didn't participate much in the writting, I spent a lot of time working on the slides with Gregg Pollack to make sure we properly presented the concepts of staging, remote repositories, branching, and especially rebasing.
The Tron-inspired design and illustrations that Justin Mezzell created for this course, aside from being gorgeous, helped quite a bit by allowing us to identify some concepts — through iconography for instance.
I created Shields in January 2013 in a bout of constructive rage against bad open source repository metadata badges. I'm a bit amazed by how shiny that rage diamond turned out to be.
One fatelul day in May 2014 I decided I'd had enough trying to decipher the Git commits from one of my application's dependencies. The dependency in question wasn't some obscure repository. It was something likely used by thousands of people, and yet it didn't have a proper CHANGELOG to speak off. Instead the maintainers did a git log diff between two version tags and dropped that into something they called a "CHANGELOG".
That wasn't a CHANGELOG. A CHANGELOG is a thing for humans who already know how to make a git log diff if they need to. But they don't want to because git log diff are utterly useless to understand what has changed in a release at a high level. This frustration led me to write down what I believe are guidelines for a human-friendly CHANGELOG.
In late 2012, after nearly a year of working at Code School, I noticed that while our team was growing, certain questions kept being asked to the same people over and over again. Being an early member of the team, I had to repeatedly explain simple things that weren't necessarily related to code, but often spun out to include company traditions, vacation policies, our customer support philosophy, etc.
Orientation was born out of the desire to concentrate as much knowledge as possible in a single point of entry that did not create interruptions for our small team, allowing us to remain as focus as possible; collaborating when it's necessary and not to answer a single question. The idea was that people would go to Orientation first — the same way web developers tend to go to Stack Overflow — before giving up and asking for help. Better, I wanted to make the act of documenting something easy enough for anyone to participate in: if you have a question not answered by Orientation, simply create a new article with that question as the title and send the URL to the team or the person you believe holds your answer. Instead of answering one person at a time, this allows knowledge holders to release that knowledge from the sillo of their brain. It's better for them because they'll be less interrupted, and it's better for the team because knowledge is not concentrated in single individuals who may have a meeting, go on vacation, or leave the company with that knowledge still stored in their head.
It took me three years to finally open-source Orientation and I'm incredibly glad I did because the influx of excitement and participation has allowed some great feature like article subscription to be added. It allows every single person who relies on a piece of information to be notified when an article is updated, creating hyperlinks of sort between mostly static information and the people who depend on it.
A spiritual successor to Ruby5 since it ended, Ruby Facets is a short and sweet Ruby news podcast that covers new releases, interesting blog posts, and relevant events in the Ruby and Rails community.
I met Anthony Colangelo when we were both students at Full Sail University in 2010. I've always loved having deep conversations with him on the phone. And one day we decided to start recording these conversations. The Multilogue was born.
We don't do much editing but record on quality audio hardware so that you don't have to suffer our rants while your ears beg for mercy. It's called The Multilogue because I tend to monologue quite a bit and Anthony can hold his own too. That said, I believe we often arrive at thoughtful conversations about topics we care about: technology, attention to details, self-expression, open source software, iOS development, responsive design, impostor syndrome, etc.
I first started podcasting with Gregg Pollack and the rest of the Envy Labs & Code School team that rotates on the show. Over time I've become a regular co-host, until the show ended on September 20th, 2016.
I started Ruby Facets to carry on what I loved most about Ruby5.