Pow Update Brings Wildcard DNS Functionality For Any IP

Thursday, 07 June 2012

Pow is an awesome “zero-configuration web server for Rails development on OS X.” If you’re not using it, you should be. It makes managing different Rails projects locally brain-dead simple.

With the latest update, 37signals has also launched xip.io:

Pow 0.4.0 has built-in support for xip.io, a free service from 37signals that provides wildcard DNS for any IP address.

With xip.io you can access your Rails apps from devices on your local network, like iPads, iPhones, Windows VMs, and other computers. No configuration required.

A great solution to a longstanding frustration. Check out the blog post for more info.


Cleanly Retrying Blocks of Code After an Exception in Ruby

Friday, 25 May 2012

Recently, I had to write some Ruby code that would publish data to an API endpoint. Sometimes this endpoint would fail due to bad network conditions so I wanted to retry the request a few times before marking the attempt as failed.

Ruby has a very nice syntax for doing this sort of thing, but it wasn’t obvious to me at first. Let’s walk through a contrived example and attempt to refactor this method so that it automatically retries on an API failure:

def publish_to_api(data={}) 
  begin
    DataLibrary.publish(data)
    logger.info "success!"
  rescue DataLibraryFailureException => e
    logger.info "Oh Noes!"
  end
end

Without knowing any better, the naive ruby developer (me, in this case) might add the ability to retry a failed request like so:

def publish_to_api(data={})
  # retry up to 3 times
  3.times do
    begin
      DataLibrary.publish(data)
      logger.info "success!"
      break # it worked, break out of the loop
    rescue DataLibraryFailureException => e
      logger.info "Oh Noes!"
    end
  end
end

Hmm… this is starting to look pretty ugly right? Let’s try to clean it up a bit by using some of the nicities of the ruby language.

The first thing we can do is use the retry keyword:

def publish_to_api(data={})
  tries = 3
  begin
    DataLibrary.publish(data)
    logger.info "success!"
  rescue DataLibraryFailureException => e
    tries -= 1
    if tries > 0
      retry
    else
      logger.info "Oh Noes!"
    end
  end
end

We removed the awkward enclosing loop and replaced it with retry. It reads a little better, but it’s actually more code than before. Another nice feature of ruby is that def can be used in place of begin for a rescue block so we can actually clean it up a bit more by removing the explicit begin call, like so:

def publish_to_api(data={})
  tries ||= 3
  DataLibrary.publish(data)
  logger.info "success!"
rescue DataLibraryFailureException => e
  tries -= 1
  if tries > 0
    retry
  else
    logger.info "Oh Noes!"
  end
end

Much better. One thing to note here is that we changed tries = 3 to tries ||= 3 so that tries will only be set to 3 if it hasn’t already been set. Otherwise we’d have an infinite loop when the block is retried and tries is set to zero again.

We can still clean it up a bit more:

def publish_to_api(data={})
  tries ||= 3
  DataLibrary.publish(data)
rescue DataLibraryFailureException => e
  if (tries -= 1) > 0
    retry
  else
    logger.info "Oh Noes!"
  end
else
  logger.info "success!"
end

Here we’ve moved the implicit success call (logger.info "success") to an explicit else clause. This else clause is only triggered if a rescue doesn’t happen. It can be thought of as “rescue, otherwise do this thing.” Also, we’ve dropped tries -= 1 directly into the if statement.

This is looking much better than our original attempt at adding retry on failure. It’s clean, concise and easy to read.

If you only care about the success case, you could shorten it even further:

def publish_to_api(data={})
  tries ||= 3
  DataLibrary.publish(data)
rescue DataLibraryFailureException => e
  retry unless (tries -= 1).zero?
else
  logger.info "success!"
end

There are a number of gems (retriable for example) that attempt to abstract this ruby idiom away into a cleaner DSL but they all seem a little heavy-weight to me. I find the standard ruby way of doing this very flexible and succinct. You can learn more about the begin, rescue, and end syntax at the Pragmatic Programmer’s Guide.


Vim University

Friday, 17 February 2012

I just stumbled across a fairly new site called Vim University. Like Vimcasts it looks like a good resource for Vim tips and tricks.

What I don’t necessarily like is the old-standard Learning Vim is going to be horrible for a while but you’ve just got to grin and bear it advice given in the Surviving Your First Week In Vim post:

The first hundred vim commands you execute will be your most painful, so get through them as quickly as possible. Don’t leave vim except in for major emergencies.

And:

After just three weeks, most people are significantly faster than they were in their old editor. Don’t put off learning this awesome tool any longer.

Like Yehuda Katz this type of advice is exactly why I could never jump into Vim. In the real world, you need to get stuff done and three weeks is a really long time to be fighting with a new tool. Inevitably I’d give up, frustrated and discouraged, and swear to never try learning Vim again.

Eventually I did learn Vim, but for me the sticking point was when I started using Janus which essentially makes Vim look and act like TextMate out-of-the-box. Eventually I started exploring more of the power that Vim has to offer, but I was able to get comfortable using Vim as my everyday editor quickly and grow into using more powerful features as time went on.


Fountain: Markdown for Screenwriting

Friday, 17 February 2012

Fountain:

Fountain is a simple markup syntax for writing, editing and sharing screenplays in plain, human-readable text. Fountain allows you to work on your screenplay anywhere, on any computer or tablet, using any software that edits text files.

Taking its cues from John Gruber’s Markdown, Fountain files are eminently readable. When special syntax is required, it is straightforward and intuitive.

Though I’m no screenwriter, I could have used something like this while working on a script for a friend’s Kickstarter campaign video.


Understanding the Git Workflow

Friday, 17 February 2012

I’ve used several version control systems over the years: SVN, Mercurial, Bazaar and even Perforce. (Shudder.) Usually I’d have to learn whatever system was already in place before I was brought into a project. For the most part I would only learn what was necessary to get work done with the tool. More recently though, I’ve been using and really digging into Git.

I came across Benjamin Sandofsky’s article Understanding Git Workflow and it blew my mind a lil’ bit:

In a perfect world, every change in your revision history is succinct and stable. There are no checkpoint commits that create line noise. There are no giant, 10,000 line commits. A clean history makes it easy to revert changes or cherry-pick them between branches. A clean history is easy to later inspect and analyze. However, maintaining a clean history would mean waiting to check in changes until they’re perfect.

[…]

Git is revolutionary because it gives you the best of both worlds. You can regularly check in changes while prototyping a solution but deliver a clean history when you’re finished. When this is your goal, Git’s defaults make a lot more sense.

I was intrigued because he very accurately describes the Git workflow I use (and worse yet, the one I’m used to) and explains all its warts. He then explains the new-to-me intended workflow:

  1. Create a private branch off a public branch.
  2. Regularly commit your work to this private branch.
  3. Once your code is perfect, clean up its history.
  4. Merge the cleaned-up branch back into the public branch.

It’s step 3 that I was missing. I guess coming from an SVN background, rewriting history seems a bit taboo to me. He shows some great, practical examples in the “Guidelines and Examples” section including how to use Git’s powerful interactive rebase mode.


Making Rounded Rectangles Look Great

Friday, 17 February 2012

Mike Rundle on designing rounded rectangles:

If you really think about it, most interfaces (especially for iOS apps) use tons of rounded rectangles in different shapes and sizes. Long and skinny ones with lots of shine. Squarer, flatter ones with some texture. Smaller, slightly inset ones with photos inside. The list just keeps on going.

He lists some great tips and even has some example Photoshop documents to download and check out.


iMessage Comes to the Mac

Thursday, 16 February 2012

Along with the announcement of the next version of OS X (dubbed Mountain Lion) Apple has posted a beta of the new Messages app that will replace iChat:

  • Send unlimited iMessages to any Mac, iPad, iPhone, or iPod touch.

  • Start an iMessage conversation on your Mac and continue it on your iPad, iPhone, or iPod touch.

  • Send photos, videos, attachments, contacts, locations, and more.

  • Launch a FaceTime video call and bring the conversation face-to-face.

  • Messages supports iMessage, AIM, Yahoo!, Google Talk, and Jabber accounts.

I’ve been looking forward to this type of integration with the Mac since iMessage was first announced.


Zach Holman: Scaling GitHub

Wednesday, 01 February 2012

Zach Holman on Scaling GitHub:

A month after launching, GitHub hosted one thousand repositories. Three years later, we host over three million. In the same time we’ve gone from one thousand users to over a million.

An interesting look at the technical and organizational practices that GitHub uses to keep their team lean, happy and productive.


Magnus: Ten One Design's New iPad Stand

Wednesday, 01 February 2012

Magnus iPad Stand

I love the minimalist design of Ten One Design’s new Magnus iPad stand:

Magnus is first machine-crafted from pure aluminum and then hand-finished using the latest manufacturing techniques. After that, customized magnets are installed into the base, and rubberized feet are fitted to the bottom surface.

Unfortunately it only supports landscape mode since it leverages the iPad’s own built-in magnets.


How To Work From Home Like You Mean It

Friday, 13 January 2012

Kevin Purdy:

Dressing for work and “arriving” on time, eating lunch on a rigid schedule, shaving, brushing, and so on seems pointless at first. But not doing these basic preparations is the start of a steep, Teflon-coated slope to all kinds of other transgressions. If you’re not dressed well enough to greet the UPS delivery person, you’re giving yourself license to hide. If you’re hiding, then you imagine nobody can see Netflix open on your second monitor.

Telecommuting sometimes feels like it’s equal parts blessing and curse. On one hand you have total freedom. On the other hand, you have total freedom.

I had been working for myself for many years before taking an actual office job. (You know, the kind you have to get up and drive to.) The lack of freedom was a big shock at first but it taught me that often productivity and structure go hand-in-hand. After leaving that job and going back to working for myself I found that I craved a structured schedule. Yes, it helps me be productive during work hours, but another great — even if unanticipated — outcome is that it helps me define boundaries for time I shouldn’t be working.