Monday, 12 January 2015
A while back I moved from WordPress to Jekyll. Overall Jekyll was a
lot better than constantly fighting with WordPress, but I missed many of the
niceties of developing in Rails.
That's when I discovered Middleman. Middleman has many of the
great features of Rails development baked in to a static site generator.
It was very easy to migrate everything from Jekyll to Middleman. Overall, I'm
liking it much better so far. There's also great support for deploying with
Heroku which was something that was lacking when I first got up and running
with Jekyll.
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.
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.
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.
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.
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:
- Create a private branch off a public branch.
- Regularly commit your work to this private branch.
- Once your code is perfect, clean up its history.
- 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.
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.
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.
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.
Wednesday, 01 February 2012

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.