Cleaning Up Revision Histories

A post in the the bazaar email group described a better approach (than I had been using) to manage merges from personal working branches. For example; If I wanted to commit a change to the project 'Foo', according to the post, I'd do something like this...

$> bzr init-repo foo-branches
$> cd foo-branches
$> bzr branch http://example.com/foo-trunk trunk
$> bzr branch trunk workbranch
$> cd mybranch
$> # hack, commit, hack commit, repeat as necessary
$> cd ../trunk
$> bzr pull
$> bzr merge ../workbranch
$> bzr commit
$> bzr push

What I've done above is to first create a shared repository. I do this because I'm going to be working with multiple branches of the same project. Then I branch Foo's trunk into my new shared repository. Next I branch the trunk (that's in the repository) to my personal working branch, make all the changes and as many commits as I want. When I'm done I go back to the trunk. Pull it to make sure it's up to date. Then merge in my changes. Once I've done that I commit them and push them up to the server.

If you're worried about disk space you can remove the working trees for any branch you're not currently working in.

Inspirational Speeches

My feeds contained a blog post from Sean Tierney in which he links to a couple of excellent speeches, both very much worth taking the time to watch. He also mentions an older post of his about publicly sharing your goals. Which I agree is an excellent idea and easily done with 43Things.com. You can find my recently started list here.

Modeling Magic

I never dreamed I'd ever come to find business software an interesting domain to study but that's exactly what's happened.

Like it was for many people, I first got interested in programming because of games. In fact I can trace my interest to a specific event; I was about 10 and I was playing a game on an Atari 400 computer and realized I had absolutely no understanding of how it worked. Prior to that moment I thought there was nothing in the world more complex than a light switch but after that moment I wasn't so sure. I had to learn how it worked; was it magic or a light switch?

Well of course it was a light switch, a gazillion of them all packed on to a chip in fact, but while I was learning that I came to a realization, apparently one all programmers make; The only way to demonstrate your understanding of something was to model it in software.

So now I find myself trying to model business processes but I'm not 100% sure there's not a bit of magic in this light switch.

Before Filtering HTTP Method Types

Previously I wrote the post 'Method Not Allowed' which is about how I decided to handle unsupported HTTP request method types in my actions. Today I realized I should DRY up my code and put this logic into a before filter.

Bzr to Git

I think it's safe to say that the Rails community has decided git is the distributed revision control tool of choice. Unfortunately for me I've been using bzr for the last year or so. Lucky for me it's easy migrate from bzr to git using svn as an intermediary.

svnadmin create --fs-type fsfs /path/to/svn/project
cd /path/to/bzr/project
bzr svn-push /path/to/svn/project/trunk
git-svn clone  -T /path/to/svn/project/trunk /path/to/git/project

GNU Apps On Windows?

There's a story circulating that Microsoft is going to provide a GNU compatible tool chain for Windows. This would in theory allow pretty much any *nix application to run on Windows with very little or no change.

I seriously doubt there's any truth in this mostly because it would create a horrible rift with their third party developers who'd they'd be throwing to the wolfs, but you never know, anythings possible. There is no technical reason it can't be done. Hell, from Microsoft's perspective, I'd think it would actually be easy. After all both MinGW and Cygwin already provide this functionality. In fact all they'd really have to do is provide a standard re-distributable C library and compiler.

Even though I think it's a bogus rumor I really do hope Microsoft does this. I've always thought it was the one thing they could do that would guarantee them another 25 years of market dominance. In fact it's the only thing I can think of that could buy them enough time to switch away from the "Software As A Product" business model.

They just better hope other people are more forgiving than I am. While I really want this to be true, it makes it easier for software I write to run on Windows, I have no personal interest in ever doing business with them again. Any vendor who doesn't always try and do the right thing for their customers is not some one I want to give money to.

After a decade of bullying everyone in the sandbox it's a bit hard to accept they really want to share there toys now and even worse for them I've come to realize most of the alternatives are significantly better.

Marketing Open Source

Zed Shaw gives a talk about Mongrel where he touches heavily on how to market an Open Source project. It's worth watching if these things interest you at all, at the very least you'll learn what yak shaving is.

http://www.infoq.com/presentations/zed-shaw-mongrel-loc-economics

Patch Bombing and Change Stashing

I ran across the term 'patch bombing' today, which could be defined as; "multiple application logic changes all rolled into a single source code commit", it's the opposite of an 'atomic change'

I found the term relevant to a background thought I've been pickling over lately....

It's not uncommon for me to be in the middle of adding a new feature when I run across a bit of crufty code that needs to be refactored. Which poses the problem; How do I do the refactoring with out mixing the change sets?

In the past I'd just make both changes and write one fat commit message explaining everything but I always thought this approach smelled bad. Then, Jay Fields blogged about 'using patch as subversion's stash' and turned me on to 'the power of git-stash'.

It turns out that Bazaar, which I'm using for my current project, doesn't directly support this operation either but Jay's patch-stashing approach works just as well for bzr as it does for svn.

Method Not Allowed

Quite a bit of my old code just redirects when an action gets a request with an unsupported method, for example; 'get' requests to 'destroy' actions. While my old approach prevented anything bad from happening it always seemed wrong. It also made maintaining my tests a tiny bit more complicated because each seemed to have a different location they redirected to.

So I decided to clean up the code in my current project today. The obvious choice was to render an error template and return the proper status code.

 # file: app/controllers/parts_controller.rb
 def destroy
   unless request.delete?
     render :layout => false, :template => "errors/405", :status => 405
     return
   end
   begin
     Part.find(params[:id]).destroy
     flash.now[:success] = "The part has been successfully deleted."
   rescue
     flash[:failure] = "Unable to delete part."
   end
 end

This also simplified my tests.

 # file: test/functional/parts_controller_test.rb
 def test_destroy_get
   get :destroy
   assert_response 405
   assert_template("errors/405")
 end

The Application Appliance

This post is the continuation of a thread that started with: Opportunities

The hardware it's self would not be remarkable in anyway and since I'm really only interested in the software stack the logical choice is to resell some other vendors machines preconfigured to meet my needs.

At this point I'm not exactly sure who's machines I'll use but I'd prefer it to be a vendor that sees Ubuntu (or maybe Debian) as a first class target. My short list at the moment really only contains System76 so if anyone has any other suggestions I'd love to hear from you?

The software on the other hand is much more interesting. The software will be delivered through a private apt repository as customized packages and include specifically configured base tools such as Apache, Postgres and Ruby as well as management tools for deployment, monitoring, replication and backup.

Now obviously there's nothing special about this approach, in fact that's kind of the point. I don't want to have to re-think the simple standard parts I want to focus on the newer more unique parts. The management tools, replication and fail over to cloud services, etc...

More later....