existence, refactored

I thought I’ve already done this to all of my machines but it seems that I haven’t done it on this laptop I’m using right now.

Anyway, I use gitk for my graphical git browsing because I’m too lazy to download other graphical packages. Unfortunately, gitk looks like this:

(click pic for larger version)

The solution to this is to install tk8.5 and tell gitk to use it instead of 8.4. From SU:

To fix this the Debian (Ubuntu) way:

$ sudo apt-get install tk8.5
$ sudo update-alternatives --config wish

And then pick the wish8.5 alternative.

Here’s the result:

The guy I’m mentoring right now in one of my freelancing gigs is fairly new to software development so I decided to give him a couple of guidelines (conveniently posted on the project’s wiki) on how to properly use git.

Hopefully this should spare me the horrible flashbacks to the days when everyone I was working with was consistently breaking builds everyday.

Best Practices

• Commit often. The more you commit, the easier it is to do stuff like rolling back changes or pinpointing where a change was committed.
• Put a meaningful comment every commit. You’ll be thankful you did that 3-6 months down the line when you’re trying to verify if a certain piece of code is a bug or a feature.
• Push with care. Follow the procedure below to avoid breaking the build i.e. pushing a version of the code which doesn’t work.

Proper Version Control Procedure

Before you push your code to the repository, please follow the following procedure:

• If you still haven’t done it yet, commit your changes to your local repository (git add and/or git commit -a -m).

1. Pull the changes from the remote repository (git pull).

2. In case of conflict, manually edit the conflicting files.
   • You may have to collaborate with the other dev for this.
   • After fixing the conflict, commit the merged changes and go back to step 1 (git pull).
3. Run the DB migrations.
4. Run the RSpec tests.
   • If the specs fail, either fix the code or fix the specs.
   • After fixing the failing specs, commit the fixes and go back to step 1.
5. Run the Cucumber tests.
   • If the specs fail, either fix the code or fix the features.
   • After fixing the failing features, commit the fixes and go back to step 1.
6. Do a simple developer test. Open the server, log in, and open a couple of pages.
   • If the system doesn’t work, find the problem and fix it.
   • After making the system run smoothly again, commit the fixes and go back to step 1.
7. You can now push your changes to the remote repository using git push.

You might notice that we’re using RSpec and Cucumber in our project. I’ll talk more about them in a later post.

Distributed Version Control Systems (DVCS) have been gaining popularity in the recent years. Here’s Linux creator Linus Torvalds talking about Git and why developers should consider moving to DVCS from traditional centralized repositories.

Personal thoughts below the cut.

continue reading…

Anyone who codes programs without revision control is stupid. Seriously.

The trade-offs are so high that there’s almost no reason not to use a version control systems (VCS) when programming.

–

“So what is revision control?”, you might ask.

At its very core, revision control deals with tracking down changes to your work. That definition, however, is a bit misleading. For software development, it’s better to think of revision control as similar to the computer gaming concept of multiple saves.

As gamers will know, one save slot is not enough for larger games like epic RPGs or RTS games. It is not uncommon to encounter a scenario where a player realizes that he has made a terrible mistake 3-4 saves ago. If the game has only one save slot, that player is pretty much screwed as the save has already been overwritten. On the other hand, this won’t be a problem if he has saved on different save slots.

A similar problem pops up often when developing programs. A developer might realize that he made a terrible mistake in the code he wrote some time ago. Without a VCS, the developer only has one “save”: the one currently saved on his computer. He will have to search his files manually in order to pinpoint the location of the problematic code and fix or revert it.

With a VCS, however, the developer is given the ability “save” the current state of his code. As long as he commits (“commit” is “save” in revision terms) often, the above scenario is not going to be a big problem. Instead of manually searching each file for the change, he can look at the revision history which will tell him which files were changed. He can then use the various tools in the VCS to inspect and fix the problem. What would have taken the developer minutes or even hours to fix might only require a few seconds if there was a VCS in place.

continue reading…