At the time of writing, Zerigo DNS is being hit by a DDOS attack (reference starting here on Twitter).

I was able to migrate our company’s services – SocialGrapes and SocialGrapesLAB – to DNSimple pretty quickly, mainly because I remembered most of our DNS settings. But still, I had no idea about some of the finer details, like mail server settings, and didn’t immediately remember to put back the records for our CDN.

So in the process of fixing all of this, I decided to add two simple tasks to my rake backup task. They may be useful to you too:

I think it’s pretty funny that the last article on my blog is 3 years old, and starts with “I haven’t been blogging much lately” :-)

I haven’t been blogging much lately. I’ve been too busy with some vacation time and, of course, work.

This is going to change, but it’s not all going to happen on Programblings.

It’s been a long time coming, but giraffesoft finally has a blog. We’re going to kickstart our blog with a week of open source releases.

At giraffesoft we like DRY code. We all know that creating Rails plugins is barely more work than actually implementing the functionality inside of a specific application. For that reason, we create plugins all the time when working on projects.

So this week, we’re going to polish up a few of them – big and small – and officially introduce them to the world.

For now, please let me direct you to the brand-spanking new giraffesoft blog.

If you’re too lazy to read the introductory post, here’s the punchlines:

• follow our RSS feed or
• follow us on Twitter.

I guess we’ve all heard last week’s sad news about Engine Yard diminishing the awesome support they’ve given the Rubinius project. That’s personally how I see it: they’ve put the project on steroids for roughly a year, rather than “they’re now cutting back” x people.

As Brian Ford pointed out, Rubinius is a community project. And Rubinius is not going away. A lot of people can’t wait to have a Ruby written more in Ruby than in C or C++. Koichi Sasada (lead developer on Ruby 1.9) even recently projected that Rubinius would eventually be the Ruby implementation of choice.

Seen on a git 1.6.0.4 installation (dunno about previous versions), installed through MacPorts ¹ with the +bash_completion option.

$ git config #tab
apply.whitespace               core.compression        ...
branch.                        core.fileMode           
clean.requireForce             core.gitProxy           
color.branch                   core.ignoreStat         
color.branch.current           core.logAllRefUpdates   
...

Tonight I’m trying conciseness.

Editor’s note: I failed.

I recently decided to test my git_remote_branch gem with Ruby 1.9, for the heck of it. Well, I was making sure it ran on a bunch of platforms: Windows, Ruby 1.8.7 and with the most recent Git version (1.6.0.2, get it). So it seemed fitting to check it out under Ruby 1.9.

On Leopard, the only missing dependency to Ruby 1.9 is readline 5.2. This article will present the installation of both. And help heat up your apartment.

Josh Knowles recently suggested that maybe I could merge grb’s functionality to the github gem.

Both gems being command-line tools that help you use Git in a friendlier manner, the question makes a lot of sense. It makes so much sense in fact, that I decided to blog about it. A post about it will scale much better to answer other users who may potentially ask the same question.

So here’s a slightly edited excerpt from the answer I gave him. And yes, I also ramble in email.

Awesomeness for the masses

git_remote_branch 0.3 has been released!

Previous releases were pretty much only usable by rubyists on OS X.

No more. This release is mostly focused on making sure git_remote_branch works on a broader range of platforms. A few actual features squeaked in, but nothing big like introducing new commands.

To install any ruby gem which has a command-line interface on Ubuntu 8.10, you have to add a path to your PATH environment variable. In your .bashrc file, add the following line:

export PATH=$PATH:/var/lib/gems/1.8/bin

Also worth noting is the fact that the default ruby interpreter on 8.10 is back to the 1.8 branch: it’s 1.8.7 (1.9 was the default on 8.04 iirc). 1.9  also be installed right besides 1.8.

$ ruby --version
ruby 1.8.7 (2008-08-11 patchlevel 72) [i486-linux]
$ ruby1.9 --version
ruby 1.9.0 (2008-06-20 revision 17482) [i486-linux]

Neither comes installed by default, however. You must install them explicitly.

sudo aptitude install ruby irb rubygems

While I’m at it, why not mention that rubygems 1.2.0 is installed by default. It doesn’t want to update to 1.3.0 with the usual “gem update –system” command. Since it’s not my main machine I didn’t investigate further, but the suggestion is to use apt-get or aptitude. The repos don’t seem to be up to date with 1.3.0, but rather with a version named something like 1.3.0really1.2.0.

In praise of Shoulda macros

Shoulda contexts let you to share setup code between different tests. This is for me one of Shoulda’s most attractive features.

When you combine this with the technique of defining your own macros to encapsulate assertions or setups that come up often, you end up with seriously DRY and readable tests.