This is fun: What it means to deploy

Releasing new code is extremely fun. Never take it for granted. The moment you're bored shipping new code is the moment you should consider finding a new gig.

Here's why: 

1. Shipping new code means people can use and see it immediately.
2. Each time you deploy, you're shipping a NEW VERSION. 
3. You get emails thanking you. 
4. People notice. 
5. If you break something, you'll know. 

People thank you for your work.

This is motivation alone. Your entire team, the people that brainstormed, planned, designed, implemented, and shipped that new version - you get to be thanked by people who love what you do. Every day.

Never take that for granted. 

What else can you be doing where this happens? Garbage men don't get thanked every day (although they should). The mailman surely doesn't get thanked every day (although he should). 

Realize what you do is powerful. You're inspiring people. They care about what you do. 

You might be making their business better. Maybe, you're the entertainment in that person's life. You might even be helping them through a tough time. 

Just realize you're communicating to people. You may never meet them. You may never say a word to them. But they're thinking about you.  Trust me.

Handling subdomains for Rails in your development environment

We built Tula with subdomains from the beginning, so we needed a nice way to handle subdomains in our development environments. We used pow for some time, but that wasn't the perfect solution for me. That's because I wanted a few things out of a solution: 

• Configure it once and forget about it
• Know exactly when my server was started and stopped
• Use whatever I wanted as an app server i.e. unicorn

It took us awhile to settle on this solution, so here it is. It uses a combination of Apache (or nginx) and dnsmasq which I've become a huge fan of. 

The first part is simple. You'll want to install and use dnsmasq. It's a nice, lightweight and local DNS provider that will run on your machine. You can serve the names of local machines which are not part of the global DNS. 

It's easy to install on both Linux and Mac. 

# On Ubuntu Linux
sudo apt-get install dnsmasq

# On Mac with Homebrew
brew install dnsmasq

Once installed, you'll want to add the following to your dnsmasq.conf file. This will resolve any domain with a TLD of .dev to your local machine. This is handy if you have a lot of projects (Rails or otherwise) in the same directory. 

Next, you'll want to configure Apache (or nginx) as the following. The key for Apache is VirtualDocumentRoot. It allows you to set the document root based on various parts of the domain name. In this case, I've taken the main part of the domain name as the document root. The domain name will resolve to a project in my Projects directory. This will always work if I continue to use my Projects directory for Rails projects.

If you set this up once for your Rails projects, you'll never have to worry about adding anything to your hosts file, nor will you have to worry about port numbers. It's all taken care of for you.  You can access your subdomains as you would normally. It's important to note that unicorn is running on port 5000 in this example.

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.