My tmux configuration with tmuxinator

We're a small, remote engineering team (only 3 people), so we haven't developed a standard for our development machines yet.  We have 1 person on Mac, 1 person on Ubuntu (me), and 1 person on Manjaro (Linux).

We're always experimenting with new tools and adding new ones to our toolbox. The one I want to talk about today is tmuxinator. 

If you're familiar with tmux, it can be a bit of a pain to script your tmux sessions. For example, if you want one pane to run vim, another to show a log file, and a third to run the rails console, it takes a bit of time to script. 

The goal is this: When I turn on my machine in the morning, I want to type one command to do the following: 

• Start vim in the right directory.
• Give myself a command prompt in the right project directory. 
• Start the Rails server. 
• Start a tail of the development log. 
• Start the Rails console. 
• Start spork for running specs.

You can easily script all of this with tmuxinator. 

Using the script above, you end up with a tmux layout like so.

When I start my terminal for the day, I run the command mux tula   and I'm off and running. A tmux session is started and I end up with the following:

• vim running in the top window
• a prompt on the bottom for playing with git, bundle, etc. 
• the Rails server running on window 1
• the development log tail on window 2
• a Rails console on window 3

You're up and running for development in no time. 

As a bonus if you work on multiple projects, simply detach from this tmux session and run another. Your session is saved (until you restart your computer), so switching between projects is a breeze. 

I haven't played much with this layout and I'm sure it's not perfect. It's a much better solution to what I was doing in a previous life. If you have any of your own tmux layouts, I'd love to hear from you in the comments below. 

And, by the way, if you need a great tmux primer, I recommend  TMUX – The Terminal Multiplexer.

Bootstrapping in America Interview

The fine folks over at the TastyTrade network had me on their Bootstrapping in America show last week.

We chatted for about 15 minutes about business, marketing, and building software.

Make your Rails views easy with select

Recently, we were writing a new report for Tula. We needed to query for all users that had purchased a particular pass and when they purchased it. 

Here's what we came up with first: 

Well, that doesn't make it very easy to display in our view. We want a view as simple as this: 

Now that we had the simple view code with our favorite interface, we had to implement that interface. How would we do that? (By the way, you may notice we have date formatting in our view. You may want to try a decorator so your view is even simpler.)

By adding a select to our query, we can select all of the user attributes AND the pass attributes we need. We can add these attributes to the user (if you're familiar with SQL, we're essentially merging the join table attributes with the user being returned). You might want to read more about selecting specific fields.

Now, we've got a nice interface to work with that keeps our view super simple and not doing any extra work. We can access pass_name  and pass_purchase_date  directly from the user.

You should notice that we have a query in the controller. For simplicity, I kept it in the controller. You should really have this query in your model or better yet, in a single responsibility query object (see #4). 

If you have any questions or comments, please let us know in the comments section below.

Your code sucks, mine is better, and why code review doesn't have to be painful

We've been experimenting with different ways to make code review part of our culture. Although we'd like to, we don't pair program regularly for a variety of reasons. We're a remote team in 6 different time zones and we currently have 4 different projects for only 3 engineers. As a result, we try to keep context switching to a minimum, but code review naturally drives context switching for us.

Code review is a great way to improve code quality! 

Well, that's great, but how do you do it?  We set out to seek an answer to that question.

Image Credit: http://www.flickr.com/photos/theredproject

First of all, it's important to realize that all organizations are different. The people are different, the projects are different, the tools are different, etc. Sure, many of us share similarities, but for the most part, everything is slightly different. Although you can read and read about how other organizations do it, you have to find your own way through your own experimentation.

Experimentation is fun. If we find a new tool we'd like to use or a new idea we'd like to add to our workflow, we try it. We don't have a formal experimentation period. We just try it. If we like it, we find a way to keep it. If we don't like it, we throw it out. 

For example, we recently wanted to try Blossom. Up until that point, we were exclusive to Basecamp for project planning. We knew Basecamp was missing something, but transitioning clients to Basecamp has been pretty easy. Blossom has started to fill the hole in our hearts and we've decided to keep it. A word of warning though: some of your clients won't love your tools as much as you do. Not all of our clients liked Blossom. 

Like Blossom, code review is a specific piece of our workflow we're actively experimenting with.  We've tried a few different things so far, and we haven't been completely satisfied yet. That doesn't mean we've given up. We're just adapting and changing our experiments to make us happy.

Experiment #1  - Code reviews live on GitHub

This is obvious. All of our code is on GitHub. Their collaboration tools and commenting system is easy and if you've worked on open source, it's pretty easy to work with. We can review the code and comment inline on the lines of code in question. We can open up issues when we see them and suggest ways to refactor. 

Long ago when we first started doing this, we knew it was a success right at the start. To improve quality, this was definitely a win. 

One of the advantages of using GitHub for your code reviews is the rich history. If you're constantly talking about your code and using pull requests to signal when code gets merged, you'll have a rich history of discussions, bug fixes, and screenshots. If you practice continuous deployment, you'll have a history of deployments as well.

History is invaluable. You'll be able to answer questions like, "why did we do it this way?" You'll be able to see screenshots of the app as its being built. The history will serve as a seed to help you recall much more about the code written.

Although reviewing code on GitHub is great, code review comes with a price. We're a distributed team and sometimes only one engineer is online. How do you practice code review if you value the speed at which you execute? This was one of the problems. If we wanted to integrate code review into our organization, how do we do it in these cases? Do we sit and wait until another engineer comes online? This was a problem we didn't know how to address.

Experiment #2 - Assigning a code review todo on Basecamp 

Reviewing code on GitHub was definitely becoming part of our organization; however, we wanted to make sure we were doing it. Since we were using Basecamp at the time, we decided it was a good idea to create a todo on Basecamp and assign it to someone for code review. That person would be notified and they would review it, right? 

Much like Experiment #1, we still needed someone to be online. If one of our engineers completed a bug fix and no other engineers were online, what happens? The todo gets created and the code sits there until that person gets online. 

Another problem for us was context switching. If someone was online, should they immediately switch and do a code review? It doesn't seem like a good idea, does it? 

Experiment #3 - Added a code review step in Blossom 

As we started to use Blossom, we started to ditch our usage of Basecamp. We setup our kanban flow and decided to add a code review stage. It seemed like a code review stage was just what we needed.

We placed our code review stage after our QA stage (we're big fans of having a QA person to test the code as a user).  Over time, we started to see quite a bit of friction in our workflow. Code reviews weren't getting done "on time". We were ending up with code that had passed QA, but wasn't reviewed by another engineer.

We had been accustomed to merging code upstream as soon as something passed QA, and we were feeling pain now. The workflow wasn't working. 

Experiment #4 - Continuous code review 

After all of our experiments so far, we finally realized that code review shouldn't be a formal part of the process. Instead, we should train ourselves to do it all the time. We call this continuous code review.

We review code earlier in the process. Sometimes, we'll write some code, open the pull request, and pair up with another engineer to review. If code is in the QA stage before the first code review, we've failed.

If I had to come up with a rule, I'd say you should do your first code review halfway through implementation.  We don't really like rules though. Smart engineers can use their own discretion and figure out when a review would help them out. This has helped as immensely so far, but it's still too early to tell if this is the experiment we'll call a success.

Our goal is to ingrain code review in our culture. We know it improves quality. We know it makes us smarter. We know we want to do it. So do it.

Judge receiving kickbacks for imprisoning children gets 28 years

Judge Mark A. Ciavarella, 63, serves as an example of why the private prison industry can do more harm than good. Ciavarella worked alongside owners of private juvenile facilities to ensure that the prison remained occupied. The more prisoners equated to more profits for the owners of the prison.

As a result, Ciavarella would sentence offenders with small offenses to months and, at times, years behind bars. He once sentenced a teen to three months in jail for creating a MySpace page that mocked her school’s assistant principal. Ciavarella also sentenced another teen to 90 days in jail after a simple schoolyard fight.

Disgusting.