by Mark Quezada

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.

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:

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

defpublish_to_api(data={})# retry up to 3 times3.timesdobeginDataLibrary.publish(data)logger.info"success!"break# it worked, break out of the looprescueDataLibraryFailureException=>elogger.info"Oh Noes!"endendend

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.

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:

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.

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:

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.

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 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.

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.

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.

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.

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.