jonmagic.com ...nuf said

Business With Pleasure

2013-05-15T14:20:35-04:00

Hi, my name is Jon. I'm an addict. It does not matter what it is if it makes me feel good I do more of it.

But I Love It So Much!

I love my job, or more specifically, I love the work I get to do every day. Combine my love for work with my addiction problem and I end up working too much and spending too little time with my wife, or reading a book, or taking a walk.

When things are going well at work I have a sense of accomplishment, which feels good, and I want more. How do you get more of something? You just keep doing the same thing over and over again that got you that good feeling right?

Being Honest With Myself

Right now I have no problem identifying that my line of thinking, doing more of something will result in more pleasure, is wrong. When I am in a destructive cycle I am completely blind to this fact.

A destructive cycle is wanting one thing too much and being blind to the costs of achieving it. We also call this being obsessed with something. Ultimately these destructive cycles lead to some sort of meltdown for me when increased input does not lead to an equal increase in output.

During a cycle I can’t stop thinking about whatever I’m obsessing about; I bring it to the dinner table, I bring it on a date, I go to bed with it. This damages my marriage and my mental health.

Thankfully I am getting better at recognizing and breaking these cycles. I can’t take the credit though, my wife usually notices and starts to warn me early on. Learning to listen to her concerns is something I need to get better at. My last obsession lasted about ten days before she got through to me and I recognized the error of my ways. That was yesterday.

Shortening the Cycle

There are a few things I am going to try to shorten this cycle. The first is obvious, listen to my wife. But what if you don’t live with someone?

Recognize the signs. If I am spending less time doing things that relax me, like reading, walking with my dogs, or doing chores around the house, these are pretty good signs I’m not balancing work and life very well.

I’m trying out a checklist of sorts. It is just a long list of non-work things that I can do each day. I made this list by observing what has been healthy for me in the past. I’m not going to check off everything on the list each day, but doing three or four a day is a good sign, and doing one or none is probably a bad sign.

Make yourself accountable to your peers. If you know your signs ask a coworker and friend to watch out for them. Most of the time someone other than yourself will recognize the signs much sooner than you will. There is a caveat, if you are going to make yourself accountable you have to be willing to listen when they warn you.

Getting it right feels great too. Excuse me while I add blogging to my list of non-work things to do.

Focus

2012-09-07T16:32:38-04:00

We just finished shipping a six month long milestone on one of our support tools at GitHub. One lesson I learned along the way was focus.

Make a Commitment

When I first heard about this project, the tool that handles all incoming support requests at GitHub, I was immediately intrigued and volunteered myself to help. Sitting down with the person who had developed the tool to that point and the support team, we came up with a few core things that had to happen, plus a lot of higher level todos.

At the time, our support tool was just a front-end to a popular customer care service called Tender, that was actually built by a couple GitHub employees in their previous lives. The service had done its job for a long time, but it was clear that our needs were changing, and that we couldn’t rely on a third party service to meet them.

So, I made the commitment to help achieve this goal and get our support system running on its own as a full fledged application inside of GitHub. I am not actually sure if I would have made this commitment if I had read through the codebase and understood what a long road it would be. Thankfully, in my gung-ho sorta way I just signed up on the spot.

Frame All Questions & Answers

Having made the commitment, I dove into the project head first. I quickly became the primary developer on the project, with people coming in from other teams to help for a few weeks before returning to their other work (thankfully @spicycode joined later as a full time member of the team). Along the way I learned that being the primary person responsible also meant that people came to me with their needs and wants.

Initially, being a people pleaser, I did everything in my power to fulfill their wishes and desires or promised to work on what they needed later. Quickly this became unsustainable and I became frustrated with my inability to fulfill those requests.

Then I learned the right way to answer questions when asked. I had to frame every question, every want, every wish, in the context of my original commitment. Would satisfying their need further our core goals, and did I have the resources necessary to accomplish it?

Learn To Say No

Most of the time during the last six months that answer ended up being no. This was especially tough for me, I hate saying no, but I had to learn how to do it or risk losing my sanity and disappoint a lot of people.

Thankfully in many cases I didn’t have to say a flat no – instead, we would channel the energy and idea into a feature request that we could talk about more down the road. All of these feature requests were recorded in GitHub Issues and revisited over the following months, taking new shapes, and in some cases being made obsolete by better and newer ideas.

Along the way, we implemented just enough to keep our support team happy, with all of their hair intact. Mostly, we focused on our core goals.

Conclusion

Last night at midnight we flipped the switch to route all support requests thru our new backend. We still use Tender in a limited capacity for old discussions that are still open, but as time passes those will be archived and eventually we will be able to remove Tender completely as a dependency.

In six months, we laid a solid foundation for the future of support at GitHub by staying focused.

HUBOT img me woman laughing alone with salad

2012-05-19T19:30:21-04:00

In the past month I've had the opportunity to present this talk twice, first in London England and then in Verona Italy.

Before joining GitHub I met Zach Holman from GitHub at a conference in Colorado and heard about Hubot. As soon as Hubot was released as open source we started using him at Ordered List and I blogged a simple script writing tutorial which is still my most popular blog post day to day.

After joining GitHub I got up the nerve to write and submit a talk proposal and low and behold two out of three of the conferences I submitted to accepted my talk. I gave this presentation first in London at DevsLoveBacon and you can find the video of my talk on their site. A few weeks later I traveled to jsDay in Verona Italy and presented a second time!

Here are the slides from my presentation.

If you have any feedback on how I can make the talk better or any questions about Hubot please send it via Twitter @jonmagic.

My Trip to Verona

2012-05-20T12:15:53-04:00

As my plane broke through the clouds, descending into Verona, my eyes were met with seemingly endless farm land, a patchwork quilt, broken up by small patches of trees and wandering erratic roads.

Day 1

We landed at the small airport and for the first time in a decade I felt like a foreigner. I was in Verona for jsDay, having been given the opportunity to speak.

After exchanging dollars for euros I hailed a cab. My driver must have been training for the grand prix as we zigzagged and raced around cars at 140km/h. The exhilarating ride ended at the hotel and my original notion that Verona was mostly flat was thoroughly dispelled.

Soon I met with my coworker and his wife who were in Verona on holiday and we jumped on a bus for Lago di Garda. We spent the afternoon catching up, enjoying the scenery, and eating the local fare.

Jet lag began to sneak up on me as the sun moved into the western sky. We returned to the hotel and began making dinner plans, but before we could execute I ran into other speakers from the conference.

Introductions were made, plans were changed, and the spritz began to flow. At a local Pizzeria, one among hundreds in a several kilometer area apparently, we feasted on thin crust delicacies.

We talked into the night, closing the pizzeria and then the hotel bar. A rag tag group of many nationalities, daring each other to try the grappa.

Finally around 3am I collapsed into bed, exhausted from the last 37 hours of travel and new culture acclimation.

Day 2

The conference began with a spritz. The talks were great and it was refreshing to catch up on the world of Javascript since I’ve been so deep in Ruby for the past six months. Twice I had to retire to my room to lay down for a bit, jet lagged and exhausted.

Lunch was catered by the conference center and I mostly feasted on salad, cuts of meat and cheese, carrots, and cooked greens. Red wine was served and rivaled anything I’ve had back home.

At this point I must have been meeting new people at a rate of six or more per hour. English truly is the international language, at least in the programming community.

In the evening they took all of the speakers to the tallest tower in Verona, where I scaled 368 steps and then faced one of my worst fears, heights. It is so strange that I have no problem getting in an aluminum tube that hurtles around the world many thousands of feet above the ground without a second thought, but looking down from a twenty story tower makes me weak in the knees.

After descending we walked across the piazza and sat down at the finest restaurant in Verona. The first glass was filled with Prosecco and I began meeting everyone around the table. Two Californians, a few from Italy, a couple from Germany, and the GitHub delegation.

We all enjoyed conversing, the three course meal and dessert, and of course more red wine. The meal was good but I felt like it was not much different in style or quality from what my wife and I cook at home. The dessert on the other hand, a cream with nuggets of pure chocolate heaven, was fantastic.

After dinner we were bussed back to the hotel and a large number of us headed back to the pizzeria from the pervious night to join the conference attendees. I met more people, sampled the local beer, and once again we closed the place.

Once back to the hotel I settled in at a table in the bar with a Norwegian living in Italy and a Belgian living in Switzerland. We talked into the wee hours of the morning over a couple of beers, discussing everything from nationalized healthcare to the perfect bolognese recipe.

I finally climbed the four flights of steps to my room around 4am and kissed the mattress.

Day 3

Going to bed so late prevented me from waking up in time to see Douglas Crockford talk in the morning, which was definitely a disappointment. I did make it to a few talks however and it was interesting to see what libraries and tools people were using around the world.

Right before my talk I took a power nap and awoke with an idea for how to engage my audience a bit more.

Before leaving my room I grabbed some mostarda I had purchased and on the way to the conference rooms I ordered a spritz from the bar.

As I began my talk about Hubot the robot butler I walked out into the audience and asked whether they liked it when someone did something nice for them. They didn’t answer immediately so I singled out one young lady and asked her if she would like the mostarda or the spritz. She said either so I gave her the spritz and then held up the mostarda and asked who wanted it. A gentleman in the back said sure and I passed it to him and then headed to the front to start my talk. I had broken the ice, demonstrated a servants heart (a butlers heart!), and calmed myself down in the process by having some one on one interaction with the audience.

It felt like the rest of my talk went really well, my energy level was high, I didn’t stumble, and I actually hit my allotted time perfectly! There were even a few questions and light applause. But later I noticed there was only one tweet and no one really came up to ask me more about Hubot, so I’m wondering if either I spoke too quickly and was hard to understand or if my audience just didn’t really need their own robot butler.

After the talk the usual wave of relief washed over me mixing with the waning adrenaline. Now it was time to prepare for hosting a GitHub drinkup!

I found a group to have dinner with and we began our trek across the city. We sat down to a nice meal and the conversation was relaxed. Then I left them a bit early to ensure our venue was ready for the drinkup.

Arriving at the Kulmbacher Bier-Haus I found my coworker and his wife already there. I went inside and made friends with Tony the bartender, an energetic young fellow with blond hair. The entire staff were dressed up in cheesy Bavarian garb that put a smile on your face.

As the designated hour approached people started arriving and we took our place in the back of the restaurant. My coworker and I took turns greeting each new group that wandered in, asking them what they were working on, what they were excited about in their careers, and answering any questions they had for us. One question was oft repeated: “how do I sell my boss or clients on using git.” I honestly struggled to come up with anything they hadn’t already tried. Definitely something I need to study more and work on, as I haven’t ever had to sell git to a boss or client, I just started using it and didn’t give them a choice. Unfortunately that doesn’t work for everyone.

After the successful drinkup a small group of us migrated to a quiet watering hole down the road, continuing unfinished conversations over a grappa.

The bar closed and we walked back to the hotel, me in the lead, arriving back at nearly 4am. With jsDay over I rested my head on the pillow and had my first good long night of sleep since arriving.

Day 4

As my eyes opened I realized it was nearly lunchtime, so I jumped up, dressed, and grabbed my Kindle. Leaving the hotel I found myself heading back to the trusty Pizzeria San Marco. I ordered wine and a pizza with prosciutto, fungi (mushrooms), and mozzarella. I spent my lunch reading Objects on Rails and thinking.

When I was done a nap seemed in order so I returned to the hotel and layed down for a few more hours. Waking up for the second time that day I wasn’t sure what to do so I loaded my messenger bag with laptop and Kindle and headed towards the city center. It was a fascinating hike with beautiful sites and delicious smells, set to a soundtrack from my iPhone. I started with Rome and then moved on to The Sulton of Swing.

While crossing over the Ponte Pietra bridge into the touristy center I saw many people with Gelato so I tracked down the source and bought a small cup of Strachiatella, then found a bench overlooking the river and took my time enjoying the purchase. Around dinner time I found a touristy place and had a somewhat awful meal (never go touristy!).

Dinner complete I trekked back to the hotel and found a table in the bar to sit, read, and relax at. I enjoyed my last glass of wine in Italy (for this trip at least) and read Practicing Ruby articles and watched Destroy All Software videos. Completely exhausted from socializing I avoided the party that night and retired to my room early.

After a few short hours of sleep I rose, packed, and grabbed a much more relaxed cab ride to the airport.

As my plane rose into the sky I said “Ciao Verona” and began writing my tale.

Speaker Deck Goes Full-screen

2012-04-04T12:09:34-04:00

I'm really excited to let you know that we've added full-screen support to presentations on Speaker Deck. This feature has been percolating for awhile, going thru several iterations before we found a solution that we really liked.

We are using the new full-screen API’s available in Webkit based browsers and Firefox. There were a few obstacles we had to overcome, mostly just learning how the API’s actually worked, specifically how to make an element inside an iFrame go fullscreen (make sure to add the allow flags to your iframe tag).

In the process we learned a ton of great stuff that will let us do some pretty cool things in the future. The way we designed full-screen will let us use higher resolution slides in the future as well (you know, in case we decide to start encoding them at the resolution of that new device Apple just released).

Here’s a presentation I did awhile back, check it out in full-screen!

Scriptular

2012-03-05T12:25:26-05:00

Ever since Hubot was released I've been regular expressing myself. Here is a tool I built to make testing regular expressions in javascript easier.

Rubular was my go to for testing regex in the past, but its targeted at Ruby so I went in search of a nice editor for javascript regular expressions. Unfortunately my search yielded no results. Fortunately I had the tools and experience to build one!

Scriptular is the fruits of my labor. I modeled Scriptular after Rubular with one major difference. It doesn’t have a backend service, everything runs in the browser.

I am really excited about Scriptular, I think it will be useful for developers everywhere. With its current implementation you can test how a regex reacts in any browser by loading Scriptular in that browser and testing the regex. In the future I would also like to have a backend service for testing server side javascript implementations like V8.

So go kick the tires, give it a spin around the block, and let me know what you think. If you would like to help on the project please check it out on GitHub.

Update: Thanks to @bkeepers for contributing the design.

New Tabs and Cucumber

2012-02-07T13:37:28-05:00

While working on an internal app at GitHub I had to write a cucumber scenario that ran expectations against a new tab that was opened. Here is how I did it.

The Code

Searching around the internet, I finally found a tip on StackOverflow that got me moving in the right direction. In this context tabs are referred to as windows.

page.driver.browser.switch_to.window(page.driver.browser.window_handles.last)

This code grabs the browser object and calls switch_to window on it and passes in the last opened window.

Now all we need to do is wrap this in a step so we can use it in our scenarios.

When /^I access the new tab$/ do
  page.driver.browser.switch_to.window(page.driver.browser.window_handles.last)
end

The Caveat

This will only work if you are using selenium-webdriver. It will not work with capybara-webkit unfortunately. So I switched to selenium, but I told it to use chrome instead of the default firefox and it still works great!

Capybara.javascript_driver = :selenium
Capybara.register_driver :selenium do |app|
  Capybara::Selenium::Driver.new(app, :browser => :chrome)
end

The Finale

Now its time to see the step in action. Notice I had to tag the feature with @javascript so that it uses the selenium webdriver.

@javascript
Feature: Open a discussion

  Scenario: staff opens a discussion with the mouse
    Given the following users exist:
      | username  | email                |
      | test-user | integration@test.com |
    And I am on the triage page
    When I follow "Can't get git running on my mac"
    And I access the new tab
    Then I should be on the discussion page for "5786909"
    And I should see "Can't get git running on my mac"

The link that I follow opens the new page in a new tab, I select the new tab, then run my expectations against it.

Being acquired doesn't have to suck

2012-01-08T17:36:54-05:00

It has been a month since Ordered List was acquired by GitHub and our team of 5 joined their team of 50, and it hasn’t sucked at all. Here are some observations on how to remove the suck from acquisitions.

The Suck

My general attitude towards acquisitions the past few years has been fairly negative. I’ve seen too many people and products we love be acquired and the people only stick around until their stock vests and the products are shut down or perverted into something hideous.

With all that negative sentiment you would think I would have fought for Ordered List to remain independent, but I assure you everyone on our team was not only on board with the acquisition but also excited about the opportunity.

The number one problem after an acquisition are differences in culture. From how the individuals and teams work, to how they interact, how they are led, and how they are motivated.

We would not have even considered joining GitHub if there were large differences in culture and any company looking at an acquisition should make sure this is the first thing they research and consider.

The Reality

Both sides in this acquisition did their homework and didn’t just jump in without lots of serious consideration. Putting in this work ahead of time has made the actual integration of our teams virtually frictionless.

My day to day work has not changed and yours shouldn’t have to either. This is definitely something to think about before an acquisition. Do they know what you do best and will they give you the opportunity to continue doing it? Thankfully I’m still working on the products I love and now I have a pool of talent and knowledge 10x greater than before to draw from.

There is definitely more to keep track of since there are more people, more products, and just more going on in general, but the time I spend on that is a lot less than the time I used to spend on client work to make sure my salary got paid. Acquisitions can and should give you more opportunities to concentrate on what you are passionate about.

Yes, its only been a month, how can I be sure this acquisition won’t suck? I feel like I’ve been working with these people for a long time, and in a way I have. I have been hanging out with them at conferences, working on open source code with them, and having conversations with them on Twitter for much longer than I’ve been their coworker.

In the tech industry we have and should take advantage of those opportunities. We can follow and get to know people through their code (a great way to use GitHub!) as well as on social networks and at conferences. Do your best to know the people you are getting into bed with.

Conclusion

My attitude towards acquisitions has definitely changed, but only because it’s clearer to me what works and what doesn’t.

Avoid merging teams with drastically different cultures, understand the strengths and weaknesses of the teams on both sides and be committed to letting them do what they do best, and know the actual people you will share the future with.

Assimilating Contributed Code

2011-12-30T12:59:59-05:00

This year I authored several RubyGems and just this week finally learned how to work with a contributor.

UPDATE: @bryckbost points out that the github-gem does exactly what I wanted to do. See the Fetching and Evaluating Downstream Changes section of the README.

Of course GitHub has the great Merge pull request option when an auto-merge is possible, and I use that quite often, but the workflow on OSS projects sometimes requires you to run the tests locally and make any modifications before merging it.

A quick search didn’t turn up any easy to read instructions, and I’m no git guru, so it took me a few minutes to figure out a simple workflow.

Here is how I checked out, tested, modified, and merged a massive pull request for Ghee from Ryan Rauh this week.

1. Clone my repo and create a feature branch

git clone git@github.com:jonmagic/ghee.git
cd ghee
git checkout -b repos_support master

This creates a new branch called repos_support, based off of master, and checks it out.

2. Pull contributors code into your local branch

git pull https://github.com/rauhryan/ghee.git repos_support

This pulls the repos_support branch from the remote repo and merges it into the branch you have checked out (which we also called repos_support).

3. Run tests, make modifications, commit changes

bundle exec rake
touch OHNOES.txt
git add OHNOES.txt
git commit -m "Added OHNOES"

4. Checkout master, merge feature branch, push

git checkout master
git merge repos_support
git push

Conclusion

This workflow follows the kiss principle, so it worked quite well for me.

Please give me feedback. I would love to hear about how other people accomplish this task, so I encourage you to leave links/tips/tricks in the comments below.

Also be sure to checkout Ryan’s awesome work on Ghee, a simple ruby client for the GitHub API V3.

Twelve (gauge)

2011-12-09T18:27:05-05:00

Today I hacked together an easy to use gem for accessing the Gauges API.

When I started this morning 12-gauge was the first thing I thought, so I called the gem Twelve (silly I know).

I had fun figuring out the API (with a little help from Brandon) and then writing the gem using some of the proxy object and method missing stuff I was learning a few weeks ago.

Installation

gem install twelve

Usage

Get the client ready:

access_token = "abcd1234"
bfg = Twelve.new(access_token)

Request your Gauges info:

bfg.me

For me I got this back:

{"name"=>"Jonathan Hoyt", "urls"=>{"self"=>"https://secure.gaug.es/me", "gauges"=>"https://secure.gaug.es/gauges", "clients"=>"https://secure.gaug.es/clients"}, "id"=>"...", "last_name"=>"Hoyt", "first_name"=>"Jonathan", "email"=>"jonmagic@gmail.com"}

Next try these:

bfg.clients
bfg.gauges

GitHubber

2011-12-05T13:04:23-05:00

Today the whole crew from Ordered List joins GitHub!

Ordered List

Last year was a big year for myself and Ordered List. Steve and John launched Harmony in August, I started hanging out with them on a regular basis and began work on Speaker Deck, and the end of the year saw Brandon Keepers and I leaving our own businesses to make OL four strong.

This year was even bigger, launching Gauges and Speaker Deck, adding Matt Graham to the team, and beginning the journey of learning how to work as a cohesive unit. While we learned each others strengths and weaknesses I began my own journey of becoming a full-time programmer that could not only contribute to the growth of our company, but also lead in certain circumstances.

We all dreamed of taking over the world, and we knew we could do it together. We also know it takes time to build something great and that as time goes on new opportunities present themselves. Every once in awhile those opportunities get you even more excited than the dream you are currently living. One year (minus a day) after I joined Ordered List our entire team has accepted the opportunity to join GitHub.

GitHub

This company and the team behind it has been near and dear to our hearts for years. I had the chance to meet and hang out with a few GitHubbers over the last year and have really come to appreciate them as programmers, professionals, writers, and people. When they started talking about their culture at conferences I marveled even more, excited about how they were changing the rules, hiring tons of awesome people, and just kicking-butt.

When the opportunity to join GitHub materialized it sparked an epic discussion about the possibilities. It made sense in so many ways, but whenever you entertain the chance to change course you can’t help but wonder how far you can get on your current trajectory. There were a lot of factors to consider and in the end Steve and John decided that our personal and collective futures with GitHub seemed greater.

Over the past few weeks the details were hammered out and during that time we’ve each had a chance to reset our dreams for the future, while trying to keep the whole thing a secret.

The Future

Right now I have no idea what the future holds, except that it is going to be great. I am most excited about the journey, learning new things, powering thru the hard times, accelerating during the good times, and building something that we can all be proud of.

Thanks again to everyone involved in making this a reality. Watch out world.

How We Work

2011-11-29T06:00:11-05:00

I've been working at Ordered List for almost a year now and wanted to share some observations on how we work.

Ideas

We launched two products this year while continuing work on our first. The ideas for these products came from spending time together hanging out, brainstorming, drinking a few beers, and talking about services we already used that caused us great pain.

The idea for Speaker Deck was born out of a frustration with other slide sharing services. Over a scotch or two Steve and John outlined what they envisioned a slide sharing service would look like, with me listening in intently.

When the conversation was over I had a pretty clear idea of what the initial product could look like and quickly volunteered to start working on it. At this point Ordered List was still just Steve and John, but this conversation, and my willingness to work on the product, eventually helped with them hiring me.

The ideas and visions for our products have varied greatly during our brainstorming sessions over the last year, but we always come back to the pain that inspired the product in the first place and execute on that first before moving on to some of the grander ideas we have.

After a product has shipped our users feedback begins to inform our decisions moving forward. We do our best to make it easy for them to share their ideas so we can add it to our brainstorming process.

Execution

We have very few processes that help us in executing our ideas, which is great, because it makes it easy for me to share them with you now!

Building The Right Team

I think the most important process at Ordered List is how Steve and John choose the people they want to work with.

They built their team with people who could work autonomously and take ownership of their products and client projects, filling in the gaps where necessary and taking leadership roles when called to. They built a team of unique individuals, each with different strengths. We have starters and we have finishers, visionaries and those not afraid to do the grunt work, those obsessed with the beauty of the code and those preoccupied with the beauty of the UI.

Over the past year we have been learning each other strengths and weaknesses and how to ask for help when we know another person on the team is better suited to make a decision or offer guidance. This has not been easy, but is essential to how we execute.

Whoever is the most passionate in an argument is the person that has put the most thought and research into it, so they usually win.

Minimum Process

We do not avoid processes in our work day, but we definitely do not go seeking them out. The processes we use day to day are there only because it was more painful to operate without them.

We write tests first and implement second, except when we don’t. We use staging servers. We make sure deploying is easy and can be done by anyone on the team. This process of well tested code and a place to easily deploy it and make sure everything works as intended removes the fear of deploying code to production and having it bring down an entire service.

Using pull requests on Github has changed the way we work. Even more autonomy when implementing, but you still get asynchronous feedback once you get a feature to where you think it should be. We even switched to Github Issues for all of our products so that all of our conversations around code happen in the same place, next to the code.

Probably the most important but least obvious process that has emerged as we’ve coalesced as a team is how we communicate. Setting up team@orderedlist.com made starting email threads trivial, Hipchat made chatting during the day easy, and iChat or Google+ video chats kept us face to face with our two remote team members. Recently we’ve been using iMessage to text back and forth like a bunch of fourteen year old girls. Seriously.

Shipping

We try not to ship a feature before it is ready, we prefer well thought out features, but some days we’ll ship six, seven, eight times if we’re fixing small things. There is no pressure to ship or not ship, when our intuition says its ready, it ships.

Everyone on our team likes shipping things we are proud of right out the gate. This doesn’t sound very agile, but since we’re building products that we use ourselves, we have a pretty good sense of what to build in the first place. Yes, sometimes things change once the feature is out in the wild, but this is not a common occurrence.

We take ideas, we boil them down, we build them, and then we ship them.

Celebration

There is one other process I want to mention, my favorite one. We love to celebrate. Once a feature has shipped things have come full circle, the ideas that were born over a few beers have become a reality, and now we gather again, drink a few beers to celebrate, and start brainstorming the next big idea.

Finish Weekend

2011-11-12T23:08:48-05:00

While I initially had issues with the concept of Finish Weekend, I'm really glad I participated and believe everyone involved is better off for it.

The Who

My friends at Collective Idea have apparently been talking about doing a Finish Weekend for a few years and this is the year they made it happen! They put out the word thru Twitter, friends, collegues, and a ton of people signed up and showed up!

I met folks from Detroit, Chicago, South Bend, and even as far away as California! There were programmers, designers, editors, math geeks, marketers, and testers just to name a few.

The Why

Finish Weekend was born out of a personal and professional frustration with starting things and never finishing them. What if there was a weekend dedicated to taking something you’ve started, never found time to finish, and actually finish it. Even better, what if there were people around to help you finish it!

Many folks showed up with projects to finish, but what really surprised me were how many people showed up to help other people finish! This brings us to my issue with finish weekend.

My Issue

When first told about Finish Weekend immediately I reacted negatively because I believe we should be working hard to finish things every day. I love finishing things. Finishing projects is hard (that last 5% can be excruciating) but the joy you get from shipping feature X, or accomplishing goal Y, is greater than the joy I personally get from starting a project (as much fun as that is).

When I finally got over myself and realized that Collective Idea was trying to help people learn how to finish things I signed up and made the trek to Holland Michigan. I did not regret it.

The Outcome

Today I saw a great group of people with greatly varying skillsets and backgrounds come together with one purpose, to finish things. We had people building video based web apps, crazy poetry recombinators, iPhone apps, and even a bond trader learning Python to automate a process that has taken him 1.5 hours every work evening for the last two years in Excel.

I was able to teach basic programming concepts, performance measuring and optimization, even cut up a mockup into html/css, and paired with my coworker on some tech that will hopefully help power our products into the future.

Collective Idea nailed it with Finish Weekend and my hope and desire is that we take the relationships and spirit of pitching in together to accomplish big and small things and carry it into the rest of our lives and not relegate it to a weekend.

Of course we’ll need reminded every so often. See you at the next Finish Weekend :)

hubot Scripts Explained

2011-11-03T12:52:28-04:00

Ok, so now you've got your shiny new hubot up and ready to listen to your every command. But what should we tell him to do with our nonsense!

Basics

Scripts for hubot are written with CoffeeScript. This is what a basic script looks like:

# hubot greeting.
#
# (hi|hello) - say hi to your butler

module.exports = (robot) ->
  robot.respond /hi|hello/i, (msg) ->
    msg.send "Howdy!"

Lets break this script down. The first line is just a description of the script. The third line tells hubot what to include in the help (when you ask hubot for help).

The actual code starts on the module.exports line. Every script you make will start with that line.

module.exports = (robot) ->

The next line tells hubot to respond to hi and hello.

robot.respond /hi|hello/i, (msg) ->

It uses a regular expression to parse the text, looking for the words hi and hello. The i after the last slash tells the regular expression to not be case sensitive, so it will also match Hi and Hello.

I like to use rubular for writing and testing regular expressions. Its quick, easy to use, and while javascript regular expressions aren’t exactly like ruby regular expressions I haven’t run into any inconsistencies yet.

Finally we tell hubot to take the message and send a message back.

msg.send "Howdy!"

Respond vs Hear

I didn’t discover this at first and thought that hubot only responded to commands directed at him, but then I discovered robot.hear! Whereas robot.respond only matches messages directed at hubot, robot.hear will run your regular expression against any chat message!

# Hubot has an attitude

module.exports = (robot) ->
  robot.hear /tired|too hard|to hard|upset|bored/i, (msg) ->
    msg.send "Panzy"

See what I did there :) Any time someone in our chat room says they are tired, that something is too hard, upset, or bored, hubot tells them they’re a panzy. Oh yeah. This robot butler has an attitude.

Random

I saw this used first in the shipit script, which displays a random shipit squirrel for your viewing pleasure whenever someone says the words “ship it” in your chat room.

# Rodent Motivation
#
# ship it - Display a motivation squirrel
#

squirrels = [
  "http://img.skitch.com/20100714-d6q52xajfh4cimxr3888yb77ru.jpg",
  "https://img.skitch.com/20111026-r2wsngtu4jftwxmsytdke6arwd.png",
  "http://cl.ly/1i0s1r3t2s2G3P1N3t3M/Screen_Shot_2011-10-27_at_9.36.45_AM.png",
  "http://shipitsquirrel.github.com/images/squirrel.png"
]

module.exports = (robot) ->
  robot.hear /ship it/i, (msg) ->
    msg.send msg.random squirrels

Notice the array that we create with 4 different shipit squirrel images. Then notice this line:

msg.send msg.random squirrels

The msg object has a random method on it which we can pass an array and it will pick a random item from that array! Super handy to keep things from getting repetitive.

Reply

You can reply to a user by changing the send command to reply like this:

msg.reply "Why thank you sir!"

Replies will be directed at a specific user, example: “@hoyt Why thank you sir!”

Http

So far we’ve only talked about how to make hubot listen and respond in various ways. Hubot really starts to get interesting when we empower him to go out and do our bidding in the larger world though. This is where hubot really starts to become powerful!

# Whois for gems, because gem names are like domains in the 90's
#
# gem whois <gemname> - returns gem details if it exists
#

module.exports = (robot) ->
  robot.respond /gem whois (.*)/i, (msg) ->
    gemname = escape(msg.match[1])
    msg.http("http://rubygems.org/api/v1/gems/#{gemname}.json")
      .get() (err, res, body) ->
        try
          json = JSON.parse(body)
          msg.send "   gem name: #{json.name}\n
     owners: #{json.authors}\n
       info: #{json.info}\n
    version: #{json.version}\n
  downloads: #{json.downloads}\n"
        catch error
          msg.send "Gem not found. It will be mine. Oh yes. It will be mine. *sinister laugh*"

This script is doing quite a bit so we’ll dissect it line by line.

robot.respond /gem whois (.*)/i, (msg) ->

This tells hubot to look for messages directed at him that have the words “gem whois” and then some string.

gemname = escape(msg.match[1])

Now I grab the gemname from the regular expression. msg.match with an integer will match the captured item from the regular expression. You use parenthesis to capture strings in regular expressions, and they get numbered left to right by however many there are. In this case its the first one, so we pass 1 to msg.match and then assign it off to our variable gemname.

msg.http("http://rubygems.org/api/v1/gems/#{gemname}.json")

Next we tell the msg.http object to use this url, with the gemname interpolated in it.

.get() (err, res, body) ->

The .get() function kicks off the request and returns 3 objects, err, res, and body. In this case we’re only interested in body.

try
  json = JSON.parse(body)
  msg.send "   gem name: #{json.name}\n
    owners: #{json.authors}\n
    info: #{json.info}\n
    version: #{json.version}\n
    downloads: #{json.downloads}\n"
catch error
  msg.send "Gem not found. It will be mine. Oh yes. It will be mine. *sinister laugh*"

If JSON.parse is able to parse the body then it displays the gem information, if it errors we get the “Gem not found” message.

Advanced HTTP

What if you want to hit an API that requires authentication? Here is a script that uses http basic auth when hitting the dnsimple api to check domain name availability.

# Domain availability via DNSimple, requires you set
# DNSIMPLE_USERNAME & DNSIMPLE_PASSWORD environment variables
#
# check domain <domainname> - returns whether a domain is available
#

module.exports = (robot) ->
  robot.hear /check domain (.*)/i, (msg) ->
    domain = escape(msg.match[1])
    user = process.env.DNSIMPLE_USERNAME
    pass = process.env.DNSIMPLE_PASSWORD
    auth = 'Basic ' + new Buffer(user + ':' + pass).toString('base64');
    msg.http("https://dnsimple.com/domains/#{domain}/check")
      .headers(Authorization: auth, Accept: 'application/json')
      .get() (err, res, body) ->
        switch res.statusCode
          when 200
            msg.send "Sorry, #{domain} is not available."
          when 404
            msg.send "Cybersquat that s***!"
          when 401
            msg.send "You need to authenticate by setting the DNSIMPLE_USERNAME & DNSIMPLE_PASSWORD environment variables"
          else
            msg.send "Unable to process your request and we're not sure why :("

We do the same thing as the last example, grabbing the domain name that is captured by the regular expression, but then things get a bit different.

user = process.env.DNSIMPLE_USERNAME
pass = process.env.DNSIMPLE_PASSWORD

Here we grab some environment variables and assign them to variables. If you are deploying hubot to Heroku then setting environment variables is crazy easy:

heroku config:add DNSIMPLE_USERNAME=john@doe.com DNSIMPLE_PASSWORD=4w3s0m3p4ssw0rd

Next we have to create the auth string that we’ll stuff into the authorization header.

auth = 'Basic ' + new Buffer(user + ':' + pass).toString('base64');

Creating that auth string is some javascript voodoo that took me awhile to figure out, finally finding an article on stackoverflow that had the magic I needed.

msg.http("https://dnsimple.com/domains/#{domain}/check")
  .headers(Authorization: auth, Accept: 'application/json')
  .get() (err, res, body) ->

The really interesting line in the code above is the .headers() line. We can set headers for the http request before calling .get(), allowing us to configure the Authorization and Accept headers! Now the last bit.

switch res.statusCode
  when 200
    msg.send "Sorry, #{domain} is not available."
  when 404
    msg.send "Cybersquat that s***!"
  when 401
    msg.send "You need to authenticate by setting the DNSIMPLE_USERNAME & DNSIMPLE_PASSWORD environment variables"
  else
    msg.send "Unable to process your request and we're not sure why :("

The response (res) object has a statusCode method on it which we can use to match http response codes. Based on the dnsimple api I was able to make a simple switch statement with the correct replies for each status code.

Conclusion

I hope this is helpful to some folks out there. I can’t wait to see what other hubot scripts people write!

Make sure to fork the hubot-scripts repo, add your scripts, and do a pull request once you’ve got them working. The gem whois and dnsimple scripts above have already been accepted into the hubot-scripts library!

Enjoy :)

HipChat, hubot, and Me

2011-11-15T11:24:29-05:00

How you can give Siri her very own robot brother with some help from Heroku and HipChat.

Github released hubot this week and geeks the world over have been transfixed by his awesomeness. He’s the second robot butler to enter my life lately, Siri being the first. Together these two fulfill my every wish (not quite) and are at my beck and call day and night (too true).

UPDATE: for a slightly different take try these instructions by @martinciu

NOTE: to learn more about writing hubot scripts read this

Getting Started

The first step is to head on over to the hubot downloads to grab yourself a copy of the latest hubot tarball. Download it and then open your command line to your download folder. It looked something like this for me:

cd Downloads
tar zxvf hubot-1.1.3.tar.gz
cd hubot

Make sure you have node.js and npm installed. I used homebrew to accomplish this.

brew install node
brew install npm

Then you can just run the hubot binary and it should install all the necessary packages and fire right up.

bin/hubot

If you run into any issues at this point please consult the hubot Issues page on Github, because someone has probably already run into the issue.

Configuring Heroku and HipChat

First we need to initialize git for our hubot so he’s actually stored in version control.

git init .
git add .
git commit -m "spawning my first robot!"

Next we create a new instance on the Heroku cedar stack (assuming you already are setup to use Heroku).

heroku create my_hubot_app_name --stack cedar

Then we need to setup hubot and Heroku to connect to our HipChat account.

This requires creating the user in HipChat and then going to your account page in HipChat (https://mycompanyhere.hipchat.com/account/xmpp) to get some values that we’ll need for configuring Heroku.

You’ll also need to go to the Group Admin in HipChat and the API tab to create an API Auth Token. Run the following commands replacing the values with the ones that match in the HipChat settings:

heroku config:add HUBOT_HIPCHAT_JID=<Username>

heroku config:add HUBOT_HIPCHAT_NAME=<Room nickname>
# example: heroku config:add HUBOT_HIPCHAT_NAME="Geoffrey Butler"

heroku config:add HUBOT_HIPCHAT_PASSWORD=<Password you created for hubots user>
heroku config:add HUBOT_HIPCHAT_TOKEN=<Token from Group Admin and API>

We also need to add the RedisToGo addon. (Thanks to Graham Siener for pointing this out)

heroku addons:add redistogo:nano

Now that Heroku is configured we need to slightly modify our Procfile to use the right adapter and name. Mine looks like this:

app: bin/hubot -a hipchat -n "Geoffrey Butler"

Replace Geoffrey Butler with whatever you named the user in HipChat. This should exactly match the Room nickname we set above. Once you’ve updated the Procfile and saved it we need to commit it with git.

git add Procfile
git commit -m "updated Procfile to use hipchat adapter and hipchat room nickname"

Deploying to Heroku

Now we should be ready to deploy.

git push heroku master

This step failed for me at first. I had to edit package.json and change the dependencies section to look like this:

"dependencies": {
  "hubot": "1.1.0",
  "hubot-scripts": "1.1.0",
  "optparse": "1.0.1"
}

The latest version of hubot-scripts blows up on the Heroku Cedar stack unfortunately. So after this step I committed my changes one more time and deployed.

git add package.json
git commit -m "changed dependencies"
git push heroku master

Woot! It worked! Now that its deployed we just need to start it up.

heroku ps:scale app=1

Inside our HipChat rooms Geoffrey suddenly appeared and I was able to talk to him.

@geoffrey help
(thanks|thank you) - say thanks to your butler
<keyword> tweet - Returns a link to a tweet about <keyword>
<user> is a badass guitarist - assign a role to a user
<user> is not a badass guitarist - remove a role from a user
animate me <query>  - The same thing as `image me`, except adds a few
ascii me <text> - Show text in ascii art.
check domain <domainname> - returns whether a domain is available
convert me <expression> to <units> - Convert expression to given units.
gem whois <gemname> - returns gem details if it exists
haters - Returns a random haters gonna hate url
help - Displays all of the help commands that Hubot knows about.
image me <query>    - The Original. Queries Google Images for <query> and
map me <query> - Returns a map view of the area returned by `query`.
math me <expression> - Calculate the given expression.
mustache me <query> - Searches Google Images for the specified query and
mustache me <url>   - Adds a mustache to the specified URL.
remind me in <time> to <action>    - Set a reminder in <time> to do an <action>
ship it - Display a motivation squirrel
show storage - Display the contents that are persisted in redis
show users - Display all users that hubot knows about
translate me <phrase> - Searches for a translation for the <phrase> and then
translate me from <source> into <target> <phrase> - Translates <phrase> from <source> into <target>. Both <source> and <target> are optional
who is <user> - see what roles a user has
youtube me <query> - Searches YouTube for the query and returns the video

Awesome! Enjoy :)

jonmagic.com ...nuf said

Business With Pleasure

But I Love It So Much!

Being Honest With Myself

Shortening the Cycle

Focus

Make a Commitment

Frame All Questions & Answers

Learn To Say No

Conclusion

HUBOT img me woman laughing alone with salad

My Trip to Verona

Day 1

Day 2

Day 3

Day 4

Speaker Deck Goes Full-screen

Scriptular

New Tabs and Cucumber

The Code

The Caveat

The Finale

Being acquired doesn't have to suck

The Suck

The Reality

Conclusion

Assimilating Contributed Code

1. Clone my repo and create a feature branch

2. Pull contributors code into your local branch

3. Run tests, make modifications, commit changes

4. Checkout master, merge feature branch, push

Conclusion

Twelve (gauge)

Installation

Usage

More Documentation and Examples

GitHubber

Ordered List

GitHub

The Future

Links

How We Work

Ideas

Execution

Building The Right Team

Minimum Process

Shipping

Celebration

Finish Weekend

The Who

The Why

My Issue

The Outcome

Links

hubot Scripts Explained

Basics

Respond vs Hear

Random

Reply

Http

Advanced HTTP

Conclusion

HipChat, hubot, and Me

Getting Started

Configuring Heroku and HipChat

Deploying to Heroku