Logs on your development machine can quickly grow to a silly size, especially if you have long running projects.

An easy cure for this is to set-up logrotate (newsyslog on OS X) to rotate the logs once they grow past a certain point (1MiB in the example below), after all most of the time you’ll only be interested in the last few lines of your logs…

Create a new file in /etc/newsyslog.d called dev-logs.conf with the following contents:

# logfilename [owner:group] mode count size when flags [/pid_file] [sig_num]
/Users/USER/Programming/**/log/*.log USER:staff 644 2 1024 * G

You’ll need sudo rights in order to do this (the config file should be owned by root:wheel).

Note:

1. Replace /Users/USER/Programming with the full path to your projects folder, e.g. /Users/bob/Programming
2. Replace the USER in USER:staff with your username, e.g. bob:staff

The globbing pattern explained:

MockSMTP (€8,99) and MailCatcher (open-source) are great tools when you’re trying to debug emails, but not everyone on your team necessarily has one of them installed (or maybe you just don’t have one of them running constantly).

In case you don’t know what MockSMTP and MailCatcher do: they’re essentially SMTP servers for development. Instead of sending emails to their intended recipients, they collect them and give you a nice UI where you can inspect them at your leisure.

Using MailCatcher or MockSMTP conditionally in development is actually pretty easy and only requires you to add a few lines of code to your development.rb file:

require "net/smtp"

ThanksForAllTheFish::Application.configure do
  # … other settings redacted …

  # Try to sniff out if MockSMTP or MailCatcher is running
  begin
    smtp = Net::SMTP.start "localhost", 1025
    if smtp.started?
      smtp.quit
      puts ">> WARNING: Found an SMTP server on port 1025"
      puts "   Assuming that it is MockSMTP or MailCatcher..."
      puts ">> Emails WILL be sent to the SMTP server on port 1025"

      config.action_mailer.delivery_method = :smtp
      ActionMailer::Base.smtp_settings = {
        address: "localhost",
        port: 1025
      }
    end
  rescue Errno::ECONNREFUSED
  end

  # … other settings redacted …
end

What does this code do? First of all we require NET::SMTP so that we can use it to detect whether there is a server on port 1025 (luckily both MockSMTP and MailCatcher use port 1025 by default).

Secondly we try to start an SMTP connection to port 1025. If the connection starts, we know that there’s an SMTP server running there and thus we can configure Rails to use it to send emails. If the connection doesn’t start, we don’t need to do anything.

Port 1025 isn’t a standard port for SMTP, so there’s little danger that we’d end up sending real emails to people from our development machine. If someone has a live SMTP server running on a non-standard port on their development machine we can assume that they know what they’re doing and can deal with the consequences.

If you’d like to see your actual signal strength (in dBm) on your iPhone instead of the normal little signal strength baubles, this is possible (though it’s a bit of a hack).

1. Enter Field Test Mode

Open up the Phone app and dial in *3001#12345#*, then hit Call .

Field Test Mode will open up immediately and you’ll see the signal strength in dBm in the upper left corner of the screen. Tapping the number (or baubles) will toggle between dBm and little baubles.

2. Make it stick

If you hit the home button and return to the home screen, the baubles will return, so don’t do that.

To make the signal strength stick:

1. Hold the power button until the “Slide to power off” overlay appears, then:
2. Release the power button and then hold the home button until the Field Test Mode quits

The signal strength should remain visible in the upper left corner of your screen, though I had to go through the whole procedure a few times before I got this to work (the first couple of times Field Test Mode just restarted instead of quitting).

What do the number mean?

• Use Field Test Mode to See True iPhone Signal Strength as Numbers Instead of Bars on OS X Daily (specifically the “How to Read the Field Test Signal Indicator Numbers” section)
• Field Test Mode: What it is and How To Enable it on Your Phone on UberSignal
• Received signal strength indication

I just pushed an update to my nordea gem bumping it to version 2.0.1 .

The main news here is that the gem is now compatible with money 5.1.1 and above.

• rubygems.org/gems/nordea
• matiaskorhonen/nordea

If you’ve ever wondered why email parsing (or email address parsing) is so terrible, you should watch this video.

Ricardo Signes at YAPC::Asia Tokyo 2011

ngrok is a handy tool that let’s you tunnel your local ports on your development machine to the public Internet. In that way it’s similar to Progrium’s localtunnel, except it comes with a cherry on top: request introspection

When you start up a tunnel with ngrok (e.g. ngrok 3000), it also gives you access to a sweet web interface which let’s you inspect requests made to the tunnel.

ngrok has binaries available for Windows, Linux, and OS X (I created a pull request to Homebrew to add a formula for ngrok, so installing it should be easier on OS X soon).

After you’ve checked out ngrok, you should have a look at my hobby project: Piranhas

⚠️ This article is outdated, please see the Middleman on Heroku – 2017 edition post for a more up to date guide on how to deploy Middleman sites to Heroku.

In case you haven’t heard of it yet, Middleman is a Rack-based static site generator built in Ruby. It’s super nice to use, but deploying it to Heroku can bit of a black art.

This guide assumes a few things:

• You already have Ruby, RubyGems, and bundler installed on your system
• You know the basics of Git
• You already have the Heroku Toolbelt installed and configured
• You already have an Heroku account
• You know the rudiments of creating apps on Heroku

Step 1: Install Middleman locally

If you don’t have it yet, you should install Middleman on your development machine:

gem install middleman

For more details on this step, read the the Middleman documentation.

Step 2: Generate a new Middleman project

Generate a new skeleton Middleman app with a name of your choice (I chose clever_like_a_fox)

middleman init clever_like_a_fox

This will generate a ton of output, like this:

Ignore this for now, and just do cd clever_like_a_fox and open the project directory in your editor.

Step 3: The Gemfile

Modify the Gemfile to look something like this (the Middleman version may vary):

# If you have OpenSSL installed, we recommend updating
# the following line to use "https"
source 'https://rubygems.org'


ruby "2.0.0"


gem "middleman", "~>3.0.13"
gem "rack-contrib"
gem "puma"

As you might notice, three lines have been added (ruby "2.0.0", rack-contrib, and puma). If you’re not using Ruby 2.0.0, you should set the Ruby version to the correct version.

Finally (for this step), run bundle install in terminal.

Step 4: The config.rb file

Next, we want to configure our app so that we get pretty URLs (no .html at the end).

In the config.rb file, around line #50, above the set :css_dir and set :js_dir lines, add the following:

activate :directory_indexes

Save your changes…

Step 5: The 404 page

We need to be able to give our users a nice error page if they go to a URL that doesn’t have content, so let’s create a simple 404 page file in the source folder (source/404.html):

<!DOCTYPE html>
<html>
  <head>
    <meta charset="utf-8" />
    <title>Page not found</title>
  </head>
  <body>
    <p>The content you were looking for cannot be found.</p>
  </body>
</html>

Once again, save your changes.

Step 6: The config.ru file

We’re almost there, just a little bit of configuration left!

Create a config.ru file in the root of your project and paste in the following code:

require "rubygems"


require "rack"
require "middleman/rack"
require "rack/contrib/try_static"


# Build the static site when the app boots
`bundle exec middleman build`


# Enable proper HEAD responses
use Rack::Head
# Attempt to serve static HTML files
use Rack::TryStatic,
    :root => "build",
    :urls => %w[/],
    :try => ['.html', 'index.html', '/index.html']


# Serve a 404 page if all else fails
run lambda { |env|
  [
    404,
    {
      "Content-Type" => "text/html",
      "Cache-Control" => "public, max-age=60"
    },
    File.open("build/404/index.html", File::RDONLY)
  ]
}

Again, save your work.

Step 7: The Procfile

Create a new file called Procfile in the root of your project with the following contents:

web: bundle exec puma -p $PORT -e $RACK_ENV

Step 7: Deploy to Heroku

Woot! Almost there.

Add this line to the .gitignore file in the root of the project:

/tmp

Run git init . in the root of your project, then commit all the project files:

git add .
git commit -am "Initial commit"

Create a new app on Heroku:

heroku create

Deploy your code to Heroku:

git push heroku master

Open the URI given to you by Heroku, or run heroku open in terminal in order to open the site in your default browser.

You should be greeted by a site that looks something like this:

Notes

Heroku recommends using Unicorn to serve Ruby/Rack apps, but I chose Puma instead as it is simpler to configure. This will probably work well for most use cases.

The source code for my sample app is available on GitHub: matiaskorhonen/middleman-on-heroku. The code changes after each step have been tagged, in case you want to browse through the history.

By the way, you should also take a look my hobby project, Piranhas.