Git: working with branches

The way we work with git is that for every remote pair programming session we create a separate branch. We give it a name after the feature we're working on.

git checkout -b feature1

It automatically switches to this branch.

During our work we tend to checkin our changes quite often. We do it with:

git checkin -a -m "created some specs for class A"

After we finish our session, we do two things.
First, we merge our branch to master:

git checkout master
git merge feature1

Then, we delete the branch we were working on:

git branch -D feature1

That's it.

If you happen to delete the branch BEFORE you merge it, don't panic, there is a solution.
In order to undelete a branch just after you deleted it, do:

git checkout -b new_branch_name HEAD@{1}

Andrzej's Rails tips #11

Today I'm going to show you two tips, both related to Rails controllers.

Use the current_user object whenever you access its data

Instead of

@order = Order.find(params[:order_id])

do this:

@order = current_user.orders.find(params[:order_id])

Thanks to that, you don't have to check whether this order belongs to the user, you just need to handle ActiveRecord::RecordNotFound exception.

Move all the logic from your controller to the model

I know you already read this statement many times, but I will repeat it anyway.
In your actions you shouldn't manipulate your model objects, do it in the model class itself. Here's a simple example:

BAD CODE:

class OrdersController < ApplicationController
 def update
   @order = current_user.orders.find(params[:order_id])
   if params[:order][:amount] > 0
     @order.prepare_invoice
     @order.send_email
     @order.mark_as_paid
     @order.notify_producers
   end
 end
end

BETTER CODE:

class OrdersController < ApplicationController
 def update
   @order = current_user.orders.find(params[:order_id])
   @order.pay(params[:order][:amount])
 end
end

class Order < ActiveRecord::Base
 def pay(amount)
   if amount > 0     
     prepare_invoice
     send_email
     mark_as_paid
     notify_producers
   end
 end
end

Andrzej's Rails tips #10

form_for and namespace route

When you use a namespace route like the following:

  map.namespace :admin do |a|
    a.resources :users
  end

then if you want to use form_for @user, this is the correct way:

<% form_for([:admin, @user]) do |f| %>

2 minutes with David Chelimsky and RSpec stories (video)

David Chelimsky at Railsconf 2008 from Gregg Pollack on Vimeo.

Story Driven Development

If you are interested in testing and the TDD/BDD movements, then you may find Bryan Helmkamp presentation on "Story Driven Development" worth watching. Bryan explains the differences between unit testing and scenarios. He also shows Webrat, a tool he works on, which makes defining stories in Rails apps very easy.

I like the title that Bryan has chosen for the talk. The name "Story Driven Development" makes it clear that it's a lot about defining requirements, and not only about testing. Additionally, I think it's clear that it focuses on the acceptance level of tests without mentioning unit tests.

He also provides a quote from Robert Martin:

Unit tests: “Make sure you write the code right.”
Scenarios: “Make sure you write the right code.”

You can watch the slides here, or grab the PDF version (which has correct code examples).

| View | Upload your own

"TDD with Rails" - the slides from my talk at RuPy 2008

| View | Upload your own

Google App Engine and dynamic languages

Google has launched Google App Engine. It's a big news. But look at this:

"Although Python is currently the only language supported by Google App Engine, we look forward to supporting more languages in the future."

You see, Python is their first choice as the main language for Google App Engine. It's not that surprising, Google is known to be a Python company. I'm pretty sure that Java, .Net and Ruby support will be available very soon as well. I wonder when will be the first time that some of the Google (or other companies) services are available only with dynamic languages.


What is my point here?

If you are serious about your career in IT then you have to start learning how to develop software with dynamic languages.

Python or Ruby seem to be good candidates. If you ask me - if you come from .NET world go for IronPython, if you come from Java choose JRuby. That's a good start. Good luck!