I love Hashicorp’s Consul and I use it extensively in my infrastructures. I also love Monit and I use the two to keep up-to-date on the services running on my servers and remain confident that they’ll stay up. Though both products have server dashboards (Atlas and mmonit respectively) it can be very helpful to see the result of checks immediately upon logging in. Something like this:

After a bit of hacking I set up a little Ruby script that outputs exactly that using the magic of a pam_motd banner, so that when you log in you can immediately see how your system is doing. Getting it going is pretty easy and I’ve found it quite helpful so far – if you’re interested in running it as well, here’s how!

Compiling software takes a long time. The worst offender, for us, is usually Ruby, but it could be anything – recently we had a client that wanted to install ffmpeg on each server, with compilation times upwards of five minutes. The answer to getting around long compilation times in a standardized server environment is, of course, packages! So we developed a Chef-based solution to create packages with the really excellent fpm, upload them to S3, and then download them on target servers: all without needing anything other than a few gems.

Want to do it yourself? Then read on.

Testing infrastructure is as crucial to the success of a business as testing applications. Yet most infrastructure is untested and validated only occasionally, and only by hand – this is especially a tragedy when chef is used, because chef has many high-quality tools to provide testing coverage from static analysis to unit testing and even full convergence runs.

At Symonds & Son, we spent a lot of time and energy integrating our tests on CircleCI into a continuous deployment process that begins with three layers of testing and ends with automated cookbook deployment to the chef servers we manage. I’ll discuss chef continuous deployment in a later article; here, I’ll cover how we got Foodcritic, ChefSpec, and Test Kitchen all running seamlessly in Circle.

I’ve always loved reading behind-the-scenes articles about people’s businesses: where their money came from, where it went, and what they learned from operating their companies. Since I recently finished closing the books on my business for 2014, I thought I’d make that sort of post for my own company – real numbers and real thoughts from a real business.

I’ve fallen in love with consul. At first glance, it’s a bit like zookeeper or etcd – it handles service discovery, health checking, and even features a very simple k/v store. But consul does much more than merely expose a lovely DNS interface: one of its more powerful features is its ability to do cluster orchestration, efficiently and effectively propagating messages to all nodes. One of my client projects runs on a dozen servers across two applications; here’s how I integrated CircleCI, chef, and consul together to make any GitHub commit run a deploy only to the targeted application, without needing to know any application server’s name or IP address.

It’s been a few years since I last went to Windy City Rails, despite the fact that it’s oh-so-convenient and there are so many high-quality Ruby and Rails developers in Chicago. I decided to go this year and, for those not able to come, provide small synopses of the presentations. So, without further ado, I present: Windy City Rails 2014, Day One.

So you want to become a programmer, huh?

Maybe it’s because President Obama told you to learn computer science, and you’re not gonna argue with the President.

Or maybe it’s because you hunger to make something – a product other people use – and you’re tired of a job where, at the end of the day, you wonder what exactly you did or why it even mattered. And hey, making software is easier and cleaner than making furniture.

But realistically it’s probably because of the money. Glassdoor claims that software engineers make a median salary of $85,000, which is nothing to sneeze at. Even the lowliest programmers can look forward to taking home about $60k, and if you have a talent and drive for programming, then the only limit to your salary is your ambition.

All well and good. But how do you go from a casual smartphone owner and recreational computer user to actually making software? And then how do you turn making software into real money that appears in your wallet and bank account?

After my article on consulting in Rails, easily the most-asked question I received was: “How do I become a programmer, and what do I do when I get there?” No one is born with a keyboard strapped to their hands: every programmer you know learned how to do it. I did too. Here I’ll describe what I found most helpful for getting into programming, how I’d do it again if I had to, and what you should keep in mind if you decide to set off on the programmer’s path.

This post is extremely long. But hopefully by the end of it, you’ll have some clear ideas and inspirations for how to turn yourself into a real, honest-to-goodness programmer.

I don’t usually call out articles on Hacker News for being exceptionally silly – if I did I wouldn’t have the time to write about anything else – but I saw one in particular tonight that bugged me, titled Your Job Is Not To Code. It was filled with the sort of engineering platitudes that one can reliably expect from HN: you must be an engineering ambassador to your company from the strange and incomprehensible Codingverse. It’s up to you to interpret and reinterpret the requirements of your project, hopefully better than its stakeholders, and tell them what they’re doing wrong. Your technical skills must be married to the sort of interpersonal skills that would make ambassadors and diplomats blush.

This is all bunk.

If you’re an engineer, then your job is to code. Your job is to be good at it. No, more than that: your job is to be great at it. Anything less is a disservice to the people who’ve hired you and a disservice to yourself. You should work constantly to succeed at your job. Working towards anything else is a distraction.

As developers, we spend a lot of time in our shells: making them fast and responsive improves our productivity. I play around with a lot of development tools (as I mentioned in a previous post) trying to find the best combination of intelligence, responsiveness, and fun. Recently I was investigating alternatives to oh-my-zsh, which is a wonderful set of Zsh packages but suffers from weird slowdowns and, unfortunately, requires a lot of configuration. I stumbled upon prezto and I love it – originally an optimized fork of oh-my-zsh, it’s now its own project, and it is fast, beautiful, and leverages the full power of Zsh. It looks like this:

You should get it. And when you do, use these configuration settings to make your experience even better.

I’ve been creating a complicated OpsWorks server setup for a client, as I mentioned in my last post, and I’ve been really enjoying the process. OpsWorks, while still a beta service, has a lot to recommend itself: it couples the best parts of chef to the power of the impressive AWS APIs. Using OpsWorks, it’s easy to make processes that seem almost magical.

How magical? Well, imagine super-fast command line deploys, seamless cookbook updates, great chatbot and application integration, then marry all those things to AWS autoscaling via elastic load balancing. One use case for my client: TravisCI automatically creating servers, running remote acceptance tests on them, then destroying them afterwards – all while notifying chatrooms of its progress. Now that’s assurance your code will work in production! Really, the sky’s the limit here for awesome integrations.

I’ve learned a lot in the process of implementing this setup. If you’re looking to give OpsWorks a go for your next project, here’s some hints and tips to make get started on the right path.