Last Post on Blogger

This is my last post on Blogger, I'm moving to Wordpress.

The new blog is on http://www.mathieuberube.net/blog

Those subscribed through Feedburner should not have anything to do. Others will need to resubscribe to get new posts.

See you there!

Make Amends with Git

I've always been a fan of small, concise commits. I strive to make my commits as small and concise as possible.

However I often fail... Very often I commit and... discover that I yet again forgot to fix a typo. Or remove a blank line. Nothing major. But it's pretty annoying to have every other commit log reading 'fixed typo' or 'formatted code'.

With Git, I don't have this problem anymore.

If I want to add some changes to the last commit, I simply type:

git add somefile

git commit --amend

Tada! I just modified my last commit to include new changes.

The other option I like to use from time to time is the rebase interactive mode. I use it to merge various commits into one. It has more powerful uses (like removing commits entirely) but I never used these (yet).

git rebase -i origin

Of course  you have to use these commits before pushing anything to a remote repository. 

With these these two commands, I can keep my commit log a little bit cleaner.

Why Katas Work

Musicians, singers and athletes have something in common - they do a lot of practice to become the best. They may have a show or a competition from time to time, but they practice every day.

Martial arts practitioners do katas over and over. At some point it becomes a form of art.

Can the same be done with code? Can you practice to code a certain piece of software over and over until it becomes art? Uncle Bob certainly thinks so. I started doing some katas a few months ago but a question was still nagging me : do they really help me become a better programmer? Does practice matter?

According to The Talent Code, the answer is probably yes.

The book explains how to harness your talent, how to become an expert in your field. And it seems that all world experts, no matter their field of expertise, have spent a lot of time (10 000 hours) practicing. Not just any kind of practice - you can't just play around and hope you'll learn something. There is a concept of 'deep practice'.

There are three parts to deep practicing:

• Chunk things up - slow things down, do a simple part of the whole
  
• Repeat - a lot
  
• Learn to feel what you are doing
  

I think that's what I've been unconsciously doing with katas. I wrote the same application every time. But every time I was improving, basing the next iteration on past experience. I was using more keyboard shortcuts, less code, better idioms to express myself. I was learning from my mistakes and becoming more efficient.

I believe that katas help me to  'deep practice'. It forces me to reflect on what I've done and learn from my mistakes. In the end I believe it helps me to improve.

That's good enough for me to keep doing it.

Switching to the Penguin

Finally it's done.

After months of talking about it, I finally dropped Windows and installed Ubuntu.

I decided to switch because I was tired of reinstalling Windows every year or so otherwise my machine was slowing to a crawl. Plus I mostly use open source software anyway. And I kept installing utilities to help me have a real prompt (I can't live without grep anymore...).

My first impression is that apt-get makes it a breeze to install a new machine from scratch. No need to download all the apps separately like I did on Windows, pretty much everything is one apt-get away.

A very positive experience so far!

Git Part 2 - Share Code with (a few) friends

In my current project we shared code among a few team members without impacting the others using Git. Since it happened twice and I already forgot it once, I put it here as a personal reminder. Hopefully it will help you too.

Imagine you're working on a feature and a teammate wants to use your code. But you're not finished, your code might break the build or some other functionality is broken. You have a few choices. You can send a patch. You can accept that the build is going to be broken. Or you can use Git and create a temporary branch for the sub-team to work on.

Setting up

Let's say you need to work on a new feature. First you create your branch:
git checkout -b myfeautre

The feature takes longer than expected. And you need help. But your changes will break the application and you don't want to impact every one. So you push your branch back to origin:
git push origin myfeature

Get work done (with some help)

Those who want to help you can create their own local branch.
git fetch
git branch myfeature origin/myfeature

I suggest you delete your own local branch and create another one as above. Your new branch will be linked to origin/myfeature so push/pull will work as usual. If you know another way to do this without deleting your branch, please tell me.
To sent your changes back to origin/myfeature, simply do
git push origin myfeature


Now everyone involved in the feature can commit as they wish.

Cleaning up

When you're ready to merge back to master:
git checkout master
git merge myfeature

Then delete your old branches once everything is working:
git branch -d myfeature # deletes your local branch
git push origin :myfeature # deletes the remote branch

Gotcha:
If you push using git push, it will push every thing from every branches, including master. Make sure all your branches are in a stable state when pushing. Otherwise you can push a single branch:
git push origin myfeature

I you feel I missed anything, don't hesitate to tell me.

Discovering git - How to have fun with a SCM (again)

I started using git about three months ago. I just love it. I had lost touch with the joy of using a VCS from the prompt. I was getting pretty used to CVS at the time. Then I entered the dark era of Clearcase. Most features were available from Windows Explorer so I got used to that. And I continued after for about a year using SVN with Tortoise. I could have gone back to my beloved prompt but I had lost my way.

Then came Git. And a host of neat little features that made me want to switch right away.

The first thing I loved about Git : you don't have any .svn folders in your project tree. Only a single .git folder at the root. Which means that you can use any tool you want to move and rename your classes and git will figure it out somehow. With SVN you had to be more careful - it happened in two of my project when someone (once it was me) thought it was a good idea to move a folder without a tool blessed by the SVN Gods. Bad idea - since the .svn folder is also moved, SVN still believes that it is committing files to the old directory.

With Git that's a thing of the past. It's a small thing but only this made me want to switch.

Then on my first Git project we merged two completely different repositories preserving the history of all the files. Nice.

And it's very easy to get started. No need to setup a remote repository. You can have most of the power of git with a local repo. 'git init' and you're ready to start. I now use it with all my projects, not matter how small.

And from then on, Git became favorite source control.

What are you waiting for? Try it! You won't regret it!

Inspiration

If you read yesterday's post and wonder where you can find motivation to start to practice, look at this. It's a screencast of Uncle Bob doing a Code Kata. A simple exercise, but if you look at the screencast you can guess he practices more than a few times.

I was tired tonight, but that's going to keep me going :)