Jekyll requires blog post files to be named according to the following format:

YEAR-MONTH-DAY-title.MARKUP

Where YEAR is a four-digit number, MONTH and DAY are both two-digit numbers, and MARKUP is the file extension representing the format used in the file. After that, include the necessary front matter. Take a look at the source for this post to get an idea about how it works.

Jekyll also offers powerful support for code snippets:

def print_hi(name)
  puts "Hi, #{name}"
end
print_hi('Tom')
#=> prints 'Hi, Tom' to STDOUT.

Check out the Jekyll docs for more info on how to get the most out of Jekyll. File all bugs/feature requests at Jekyll’s GitHub repo. If you have questions, you can ask them on Jekyll Talk.

• I started my own software company in april 2010 called Porkepic Solutions (the name is a play on the french word for porcupine). We make software for contractors in the construction industry. (twitter) (blog)
• Our first product is C3 - a crm/project management solutions for contractors. (twitter)
• We just launched our second product: ontakeoff - simple quote & estimate, cost control and easy invoicing for busy contractors. (twitter)

You can follow me on:

• twitter
• linkedin

That’s right, a garden gnome. (Apparently, some British dude had trouble saying the name of our company.)

It is with great pleasure that I announce that a new gnome has joined the team: Pierre Olivier Martel. PO is our first rails garden gnome guru-to-be. Welcome aboard PO!

(Mad Libs are are the ultimate tool to create a job posting.)

Ruby on Rails Guru

We are looking for a Ruby on Rails guru. You have a couple of projects under your belt (a black one). Everything you ever wrote ended up in a plugin. You’re just that good. You should be the one writing this job description and telling us what a real Rails guru is all about.

Ruby on Rails Refugee

We are looking for a Ruby on Rails refugee. You have a couple of years of experience in web development in Java or .Net. One night, you built a small project in Rails, wanting to know what the hype was all about. It was love at first sight. Now, you loathe your day-time job and all the unnecessary complexity involved. It’s time for a change.

Ruby on Rails Guru-to-be

We are looking for a Ruby on Rails guru-to-be. You have built at least one small project in your spare time using Rails and fell in love. You are now aspiring to have an international career as the next rock star of ruby development. But you need someone to give you a chance.

For more information, visit http://jobs.codegenome.com

One more thing. The best part of this job is that you get to work with me, the only ruby witch doctor in Montreal. Oh, and if you feel guru is overused, you get to call yourself whatever you want: ninja, kung fu master, sith lord, drunken monkey cowboy of hell, papa smurf, or the ultimate, zombie ninja pirate. Nothing beats a zombie ninja pirate.

Well they just launched the Network Graph Visualizer and it rocks! Now you can quickly see the branches/forks and know if they are active or not. Also they added commit comments.

So they fixed their most important flaw and they add features that should make collaboration easier. This makes me really hopeful for github’s future. Github is the place to be for open source projects!

When I started using using subversion five years ago, version control faded to the background. Subversion greatest strength is its simplicity. After a while, you get used to its quirks and it just works. Sure, some operations are painful, like merging back a branch, but you learn how to do it (and try to minimize to number of times you have to do it).

But five years is a pretty long time in computing terms. Maybe something better has come along. Maybe the reasons you chose something five years ago don’t hold anymore. This applies to everything. Sometimes you come across a company policy that looks stupid. At the time the decision was taken, it might actually have made sense. But things changed (as they tend to) and nobody took the time to check if the assumptions used to make the decision were still true today.

I suggest you use all the hype around git, and the discussions it generates, to revisit, to question all your assumptions about what is version control and what it can do for you. Is version control about sharing code with other developers and having some kind of history and backup? That’s something that, yes, it provides, but it can do so much more.

Have you ever used a VCS that required you to lock a file before editing, to avoid conflicts if two developers edited the file at the same time? If you’ve used any system that doesn’t require it, you just know that it’s a not a real problem. However, how do you explain it to the developer that is convinced that it is a very real problem? That’s the problem I have with git right now after using it for six months. I don’t how to convince people to try it when they raise objections. I can only say that it’s awesome and that going back to subversion from git would be more painful for me than going back to locking file from subversion.

You need to think in terms of how you want to modify your graph. My what you say?!? A git repository is a directed acyclic graph of commits (the nodes). Huh?? Read this article: Git for Computer Scientists. Do not continue reading before you understand that article. Everything falls into place when you understand that all git commands manipulate these four basic structures: blobs, trees, commits and tags.

From now on, before typing a git command in the shell, try to picture in your head how you want your repository to look after the command. Your best friend is gitk for visualization (use the –all option to see all branches). Run it before and after each command you do with git. Here is what you should be thinking when using these commands:

• git commit: I am creating a new node in my graph, linked to the current node.

• git branch branch_name: I am tagging a node with a name.

• git merge: I am creating a new node that will link two parents nodes, one for each branch I am merging (could be more than two).

• git fetch remote_repos: I am adding all the nodes from a distant repository to my graph.

• git push: I am sending all the nodes I created to a distant repository.

• git pull: I want to fetch all remote nodes AND merge.

Once you think like this, “advanced” git stuff becomes trivial. For example, this morning one coworker realized that his last three commits actually belonged to a branch. Try to visualize the solution. When you think about it, nothing has to change about the actual graph, just which nodes the tag (the branch name) needs to point at. So you just create a branch where you are, on the last commit, and then you can use the reset command to move back the other branch to the correct commit.

That’s the core of git. There are maybe two other things to worry about when using git. The first is the index, which is sort of a staging area where you prepare your commits. The other thing is the way git configuration works and the way it names and references branches (and the special reference HEAD) and remote repositories. Check out the git user manual.

• James Golick explains why distributed version control matters to you. James writes very well and it should make you understand why you should release your next rails plugin with git.

• This guy is confused about why distributed version rocks so much. He first needs to read James’ article. Then you guys with the same feelings toward git need to read the comments.

• Dr Nic tries to explain git, if you want to understand how to contibute to an open source project.

Hopefully all the links provided should help you understand git from different perspectives. One last goodie for the week: Carl Mercier released a small script to help work with remote branches. If you want to script common git tasks in ruby, take a look at Ruby/Git.

• Ssh is you friend for security. If you do not want to provide shell access to everyone, you can setup one git user and use ssh keys to provide access. If you go that route, take a look at gitosis, which is a bunch of python scripts that automates part of administering that kind of setup. Gitosis gives you a git repository to configure access and projects. It’s very nice.

• Another option is through http. You need webdav for that.

• Git daemon comes with git and is perfect if you only need to quickly give public read access.

• There are couple of git hosting site that are popping up. Check out repo.or.cz and Github (invitation only for now but has a sexy look).

Now let me remind you of your homework for the week (it leads toward the path to git enlightenment):

• Listen to Linus Torvalds git talk at google. It really helps understanding the design of git.

• Install git.

• If you are currently using svn, see my guide on how to start using git while keeping a central svn repository.

• Explore parallel universes with branches. Develop a new feature in a branch. Try out a plugin in a branch. Have a branch with rails edge. Do some crazy experimental refactoring in a branch, including renaming files (yes! git will correctly merge).

• Play with git. Set up local “remote” repository to experience what distributed version control is all about. Try out strange branching scenario just to see how git will handle it.

• Read the documentation. See if you can find how to: commit only part of file, send your last 3 commit to another branch, change your last commit (there are 2 ways actually).

I got carried away there. Git rocks.