The sneakernet in git

by Laust Rud Jacobsen on February 27, 2011

There are many ways to backup a git repository and shuttle sets of changes around. If you just want an offline copy for safe-keeping, this method is very simple and convenient:

$ git bundle create blog-dump.bundle master

This creates a file blog-dump.bundle with the full history for master, including all parent commits. You now have a single file, which can effectively be mailed, downloaded via SCP or FTP, or simply moved to Dropbox (affiliate link) for safe keeping, or otherwise shared with others. Single files are easy to archive and backup.

Thawing a bundle

When you want to restore from such a bundle backup, you simply clone from it. The steps include creating a new repository, and then pulling from the bundle, like you would a remote repository:

$ git init
$ git pull blog-dump.bundle master

Your repository now holds all commits that were stored in the bundle. For more usage-scenarios see the official git bundle help or just type:

$ git bundle --help

Possibly related posts

Idiomatic shared state in RSpec

by Laust Rud Jacobsen on February 17, 2011

RSpec is an extremely convenient tool for structuring and writing specs, and I use it on all my ruby-projects.

One set of built-in helpers I’d like to cheer on a bit are let and let!, as they can greatly simplify setting up state for multiple examples. They exist to provide a simple and convenient way to create and share state between examples. When not using these methods, specs with a bit of shared state typically look like this:

context "with a bit of state" do
  before :each do
    @user = User.create!
  end

  # The following specs assume the user has already been created
  it "should be the latest user" do
    User.last.should == @user
  end

  # .. more examples reusing the @user
end
view raw old_style.rb This Gist brought to you by GitHub.

This is easy to get started with, and when there are only a few variables in the before block, things are fine. But if you have a typo in an example where you intended to use the @user instance variable in an example, but you accidentally typed @usr, you just get a nil value, instead of a helpful error message regarding an unknown indentifier. This minor problem can be avoided by using let instead, as you get an unknown indentifier error instead of a nil value. Another issue is that all variables in the before block are evaluated, whether or not they are actually used in the examples.

The excellent official RSpec 2 documentation has the following to say on let, before showing clear examples of use:

let and let!

Use let to define a memoized helper method. The value will be cached across multiple calls in the same example but not across examples.

Note that let is lazy-evaluated: it is not evaluated until the first time the method it defines is invoked. You can use let! to force the method’s invocation before each example.

The fact that results are both memoized and lazy-evaluated means no extra effort is expended if the value is not used in a given example. Performance win!

Use let or let!?

Please use the correct helper method – I’ve seen examples like this:

context "with a bit of state" do
  let(:user) { User.create! }

  before :each do
    user
  end

  # The following specs assume the user has already been created
  it "should be the latest user" do
    User.last.should == user
  end

  # .. more examples reusing the user
end
view raw verbose_spec.rb This Gist brought to you by GitHub.

The exact same thing can be expressed directly and become more readable, just by adding a !:

context "with a bit of state" do
  let!(:user) { User.create! }

  it "should be the latest user" do
    User.last.should == user
  end

  # .. more examples reusing the user
end
view raw concise_spec.rb This Gist brought to you by GitHub.

The let and let! helpers are available in from versions rspec 1.3.1, and rspec-core 2.0.0 onwards. In a nutshell, this means they are available for use in Rails 2 and Rails 3 projects. Take them for a spin if you haven’t already, and tell me how it goes.

I recommend having a quick look at the RSpec 2.5 documentation now, as you’ll probably discover one or more neat new solutions to recurring issues when writing specs.

Possibly related posts

Identify what your Ruby process is doing

by Laust Rud Jacobsen on February 2, 2011

Quick diagnostics of production issues become a lot easier with a direct way to inspect the running process. Ever wondered exactly what the program is doing right now, without adding a lot of slow logging? With this gem in place, you can get full stacktraces for all threads in the system, while the process keeps running, in production. This means you can do this a few of these dumps, and then look for recurring patterns to identify the currently largest bottlenecks. It’s much easier to fix a problem when you know exactly where to look.

Soon you’ll be back on the road to awesome.

Simply install and load the xray gem, then add this to your Gemfile (or similar):

gem "xray", :require => "xray/thread_dump_signal_handler"

Next, you need to start the ruby-process, and find the PID (process identifier):

$ ps ax | grep ruby

You can now invoke:

$ kill -3 1234

where 1234 is the PID of the ruby process. Note this does not terminate the process. Instead, you immediately see a full stacktrace for current thread written to standard out of the process. If you’re using the Ruby Enterprise Edition runtime, you will get a stacktrace for all threads, a big win. If you are running the process interactively, you see the output directly in the terminal. For service-processes in production, you will need to check the appropriate logfile.

Thread dumps for Phusion Passenger with RVM

You can see all running Phusion Passenger instances, including their individual PIDs with this:

$ rvmsudo passenger-status

Then move in for the kill -3, and have a look at standard out for Passenger. By default on OS X 10.6, this ends up in the file /private/var/log/apache2/error_log, so have a look there. Notice the use of rvmsudo instead of regular sudo – this is because I’m using RVM to manage my ruby-versions.

I hope you found this useful – what is your stacktrace-aided war-story?

Possibly related posts