Speaking of secrets, here’s how I keep them in the shell. Why do I have secrets in the shell? Typically, they are things like API keys and passwords for web services that I use in scripts. For example, I have a script display issues that are assigned to me on the desktop using Geektool. Or scripts to tweet from the command line, when I’m in a command line kind of mood.

Last time, I looked at keeping environment specific configuration using YAML files and Rails.application.config_for. One big issue with this approach is security. It’s very common to have different sets of API keys and API settings for different environments. A simple example is credit card processing. Outside of production you use a sandbox and test cards. Only in production are live API credentials needed.

We need a way to securely handle this information.

Previously, I looked at the simply way of creating Rails stages that shared same configuration with Production by simply importing production.rb into the new stage:

1

require Rails.root.join("config/environments/production")

This is a good start, however it makes a bad idea, stage conditional code, worse:

1

if Rails.env.staging? || Rails.env.beta? || Rails.env.production?

A quick tip — When I’m deploying Rails apps to Staging or Beta I try to keep the configuration as close to Production as possible. I’ve gotten bitten one too many times by things that only break in production due to configuration (assets for example).

The simple way to avoid this issue is to use the exact same configuration for those extra environment, but there’s a wrong way and a right way.

Well, I might as well round out my Server Name Indication (SNI) sort of series by taking a look an nginx. Does your nginx support SNI? You can check by running nginx -V, but unless your nginx was built when dinosaurs roamed the earth, you should see:

1

TLS SNI support enabled

Last time, I looked at configuring Server Name Indication (SNI) with Apache. It just so happened I needed to set up SNI with the HAProxy Load Balancer last week, so let’s take a look at that.

I covered Server Name Indication (SNI) a while back, but it still surprises me how little people know about it. So, it’s time to look at configuring Apache to use SNI.

As a quick refresher, SNI allows multiple web sites to live on the same IP address, IPs being relatively expensive resources. SNI has been around for a long time (Apache has supported it since 2009), but was generally ignored do to the perception of a lack of browser support. However, it’s been hitting the big time with PAAS like Heroku and CDNs like CloudFront making it their default for HTTPS.

Ever gotten a disk full error, only to run df and not see any full disks? After banging you head against the wall for a while, you remember to run du -i and low an behold you are out of inodes.

Sometimes you have to write a new Rails app for old data. One approach is to keep the old format and carefully craft your ActiveRecord models to work with the existing schema. But, odds are the old schema has become a mess overtime and wasn’t particularly Rails friendly to start with. When time and resources allow, I prefer a do-over.

That means Extracting, Transforming, and Loading (ETL) the old data. And for that, I like a Rake task.

An update to an older post about using the iOS Simulator from the command line.

The Simulator ships with Xcode to provide a way for developers to test their iOS apps without the pain of loading into on to a physical device each time. The Simulator can emulate all manner of Apple Hardware. It ships with whatever the current version of iOS is, but you install older versions as well.

The advantage of the Simulator if you are not developing iOS apps is that it ships with Safari installed. By launching the Simulator and opening Safari, you can test you web apps from the comfort of your own desktop.