03 Dec 07 Powerup your development workflow with Git :D

Every one and their dogs use Continuous integration today …
And thinking about the developers and companies that are serious about software quality, they use some sort of TDD or at least write the unit tests for the written code too …
Most of them, at least the one I’m working now, do peer review too (ok, this post does not apply if you are lucky and doing XP)

With this scenario the standard work flow is:

Write the test

write the code

remember to run the test

if the test passed commit the code to the central repository

warn some one to do the peer review

the reviewer checks out all changes from the central repository (your and any other commits )

the reviewer looks at your changes (after he/she separates it from the other commits)

the peer review asks for some changes

you change the tests

you change the code

you run the tests

you commit the changes to the repository

In this workflow we have a great problem …
During all the time in bold the code in the repository probably has problems, or is not yet revised by QA …
Other problems in the standard version control systems are for example:
You cannot access the repository, and cannot commit your work if you are offline, this will cause problems, because your next commit will have more than one change set, so, it will be harder to track what commit caused a bug for example

Of course this approach has benefits too, but if you are using it, you may know its benefits

The idea of this post is to propose a little different workflow, that need a different approach to version control …

The workflow described above is very close to the one used with a centralized version control system, like CVS, Subversion, …

The one I’ll describe, needs a Distributed Version Control System, like Bazaar and Git, I chose Git because it is very fast
I still use a central repository as you’ll see bellow …

Write the test

write the code

run the tests

if test passed commit the code to your local repository

ask some one to do peer review

the reviewer will push your version from your machine

the reviewer will look at your changes

if he asks for some changes

change the test

change the code

run the tests

if test passed commit to your local repository

push your changes to the main repository

As you can see, this workflow is a little different from the previous one, and we have the following benefits:

The commit, checkout, create branch, merge branch operations are a lot faster and cheaper because they are done locally
The “central server” version has always a working version, because you only push your changes there after the peer review, this ensures the build server version is always ready for a demo
The reviewer of your code pools directly your development branch, what makes easy to find your changes, the changes he/she needs to review
Merge is really easy

Of course there are drawbacks too, for example:

You need to learn another version control tool (if you are not using Git yet)
There is no access control for parts of the repository, every programmer has all the version history of the source tree, but this is easily addressable if your permission system is by project
In a DVCS there are more concepts than just commit and update, push is not the same as commit and pull is not the same as update
There are no good GUI tools for Git yet

I have wrote another post about synchronous continuous integration here, and you’ll find a rake task to help you if you are working with Ruby too.

So, I think that is it.
What do you think about this approach? are you using some thing like this?

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: development, git, productivity, scm, version

Filed in productivity with 1 Comment

19 Oct 07 Why do you need a laptop? Try PortableApps.com

Ok, it will not really replace your laptop, but it is really useful, and can even be fun

The picture above is a screenshot of the PortableApps installed on my flash drive, I can use any installed software at any windows machine I’m using at the moment.That is great, because I love my Kubuntu box at home, but in most of my clients the machines I need to use (most do not allow me to use my laptop at their networks) do not have my preferred softwares, so I carry them with me.

OpenOffice 2.0 – this one is very useful at speeches and trainings.
7-Zip – The best windows archive manager
GVim – My Ruby On Rails editor of choice, I use it on linux, and now I carry it on my pocket to use when I’m in a windows machine, the only problem is that it was not compiled with omnifunc support, so it does not have code completion.
Firefox – Simply because I can’t use IE, it is not for me
Putty
WinSCP
VNC Viewer
Sumatra PDF (A very lightweight PDF reader)
VLC
MPlayer

Now I can bring every thing I need with me (ok, almost every thing)

So, if you liked the idea, take a look at PortableApps.com download it, choose what software you want with you all the time, and be happy!

Versão em portugues aqui.

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: freeware, mobile, opensource, postable, productivity, windows

Filed in productivity, windows with 1 Comment

17 Oct 07 Synchronous continuous integration with Rails/Rake

Versão em portugues aqui

I think that everyone agrees that continuous integrationis a need for any and every software project, but the asynchronous integration largely used has some problems, like:

The code is commited even if the developer forgot to run the unit tests
The tests are executed after a while on the integration server, only after that the team will know if the tests passed or not
The developer is probably working on something else when he/she get the message telling that a problem ocurred with the build, and needs to stop what he/she is doing now to correct the error, or let the error on the repository for a while probably breaking the updates for other developers

I’m not telling that you should no have a build server, you will have a build server to enable every involved on the project to get the latest version of the application, and to generate reports about the source code, these reports usually take a long time to generate and you there is no need for the developer to wait this generation to start the next task, but I do not think that the integration of the developers work are the responsibility of this server.

In other words, you do no need an integration server, just a build server if you are using synchronous integration!

The ideal is that during the commit process, the developer update his source code to the latest version, then run all tests and only if all tests passes he can commit the code to the repository.

Of course you can improve this process adding some restrictions, for example a minimum test coverage, but in my case, I wrote this Rake taks for a project where I’m working alone, and I’m using GIT for version control (I’ll write a post about GIT this week if I have the time), I’m using synchronous integration in some Java projects too, in other opportunity I’ll write about this process in java projects.

I’m adopting this synchronous integration practice for all new projects in my company and in every client that likes the idea.

Back to this post subject, it is really easy to implement synchronous integration in a Rails project, you just need to follow this two steps:

1 – create a ‘git.rake’ file in the directory lib/tasks with the following content:

namespace :git do
  desc "Update every thing before the tests"
  task :update do
    puts "Lets update it all, but we are using GIT so we already have the latest source for this repo"
  end
  desc "Run all tests, if all are OK, then commit every thing to the git local repository"
  task :commit => [:update, :test] do
    puts "No test failures, now we can commit it all"
    exec 'git commit -a'
  end
end

As you can see, this Rake task is very simple, and I’m sure it will improve a lot your projects quality.

2 – at the and of each task, instead of running “git commit -a”, run the command: “rake git:update”

That is it! using that you are now using synchronous integration

Of course this Rake task can be improved, you can configure it to pull from a central repository, or update your source code if you are using subversion for example, but I think this one is already a good start point.

It all tests are OK, GIT will open VIM for the developer to write the commit message, and after that, the code will be committed with every thing working, and good bye integration problems!

And you, what do you think about synchronous versus asynchronous continuous integration? what approach do you think is best? why?

If you enjoyed this post, make sure you subscribe to my RSS feed!

Tags: integration, productivity, rails, rake, synchronous

Filed in productivity, rails with 2 Comments

17 Jul 07 Use your S60/Symbian phone to solve your memory problems

I just found this great piece of software called TotalRecall ™, that records all calls in or out from my N80.
Ok, and why this title for this post?
Well, because I always forget the name of the attendant I was talking when I call any 0800*** number …
I forget the time of the meeting I have just scheduled by phone.

and things like that.
So this software is really helping me out.
(OK, I think that this capability should be built-in the phone, I do not know who was the “great” engineer that created a phone sound recorder that cannot record a phone call, does it sound as stupid for you as it sounds to me?)

A little review of the software …
Features

Record in AMR format

Unlimited recording length

Record to the internal memory or external memory card

No Beep While Recording

Intuitively named clips

What could be better?
I have only two suggestions for them (in priority order):