A lot have been said about the PHP Community this year, and the latest article on Zend Developer Zone is the perfect example of why it’s important to take part in this community. If you’re still wondering why you should get involved, take some time to read Move That Bus!.

Syntax coloring have been added on this blog. I was jealous that Steve had syntax coloring on his website but not me (but hey, I still have a theme, when do your css naked day end?).

I was already using a markup language (PHP Markdown) to write post, as it is easier to write technical documentation using markup than HTML or an HTML WYSIWYG editor. So, I’ve downloaded GeSHi, which is a Generic Syntax Highlighter. I have then patched my markdown.php file to add the parsing of code block by GeSHi. Now, when I create a code block, I just add a first line which is the language of the code between square brackets (i.e. [php])

Here’s the patch to markdown.php v1.0.1m, note that the require_once() line needs to be adapted to point to the location of your geshi folder.

--- markdown.php    2008-06-21 08:58:10.000000000 -0400
+++ markdown-geshi.php  2009-04-26 11:45:39.000000000 -0400
@@ -1083,12 +1083,21 @@
        $codeblock = $matches[1];
 
        $codeblock = $this->outdent($codeblock);
-       $codeblock = htmlspecialchars($codeblock, ENT_NOQUOTES);
 
        # trim leading newlines and trailing newlines
        $codeblock = preg_replace('/\A\n+|\n+\z/', '', $codeblock);
 
+   // if there's a language tag, use GeSHi to convert the code
+   if (preg_match('/^\[(\w+)\]\s*/', $codeblock, $match)) {
+       require_once(realpath(dirname(__FILE__).'/../geshi/geshi.php'));
+       $codeblock = str_replace("[${match[1]}]\n", '', $codeblock);
+       $geshi = new GeSHi($codeblock, $match[1]);
+       $codeblock = $geshi->parse_code();
+   } else {
+       $codeblock = htmlspecialchars($codeblock, ENT_NOQUOTES);
        $codeblock = "<pre><code>$codeblock\n</code></pre>";
+   }
+
        return "\n\n".$this->hashBlock($codeblock)."\n\n";
    }

Advocating Markdown

Markdown is a really nice format to work with, as the resulting file can be read even if you don’t have a converter. Quoting the Markdown website:

The overriding design goal for Markdown’s formatting syntax is to make it as readable as possible. The idea is that a Markdown-formatted document should be publishable as-is, as plain text, without looking like it’s been marked up with tags or formatting instructions.

For those lucky enough to work on Mac, support for Markdown in TextMate is realy great, the bundle can convert to LaTeX, HTML, RTF, and PDF.

If you’re more the command line type, the original implementation of Markdown is in Perl and is really easy to use too.

And if you want to convert Markdown to almost anything from the command line, Pandoc is wonderful and is available from MacPorts, with capabilities to convert to reStructuredText, HTML, LaTeX, ConTeXt, PDF, RTF, DocBook XML, OpenDocument XML, ODT, GNU Texinfo, MediaWiki markup, groff man pages, and S5 HTML slide shows.

These days, I’m a developer on a project managed with a central CVS server. And there’s no way I could convince the team to switch to a VCS that makes more sense (imho). I’m not really allowed to do branches either, and merging probably sucks anyway with CVS, so that’s perfectly fine with me if I can’t try. But I do miss branching, it’s just so helpful to develop big new feature or to try really experimental stuff.

My main experience is with Subversion, but I don’t think that mixing Subversion and CVS is a good idea. I’m also coding a lot with my laptop lately, which most of the time don’t have internet access. Buses in Gatineau and Ottawa don’t provide free wireless internet for their users . So, a decentralized version control system like Git or Mercurial seemed like good solution for me. It’s not the best scenario, but using a DVCS on top of cvs checkout seemed is a possible solution.

I’ve tried Mercurial and Git for some time, and Git was a winner in my case. Honestly, they seems to have the same capabilities, I don’t think one is better then the other. Coming from SVN, Mercurial is the easier to learn/work with. But strangely, I have decided to use Git for the single reason that there’s some really nice looking GUI tools for it on OS X. Who knows, maybe a cool app could convince the other developers to try it (I can’t believe they love the look of MacCvs)

Here’s some notes on my setup. Mainly to act as a reminder for my own personal use. This is not intended to be a tutorial for anybody, but It may be useful to some.

there’s some nice tutorial on learn.github.com too

Git config

First thing to do is to present myself to my Git installation

git config --global user.name 'John Doe'
git config --global user.email 'johndoe@example.com'

and then activate the colors on the console

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

Creating the git repos

It’s as easy as running git init at the root of the codebase. This will create a .git folder the the Git data.

Ignoring useless files

The codebase I’m working on is a CVS checkout, and I’m using Eclipse on OS X so I have created a .gitignore file at the root of the project that contains:

CVS
.DS_Store
.cache
.settings
.buildpath
.project

GUI for OS X

Some gui are bundled with Git on OS X, they are gitk and git-gui (once opened, pressing command-+ a couple of time increase the font to a reasonable size). They’re really useful, but they don’t look that great. I’m mainly using GitX in the hope to impress my collegues, but GitNub looks cool too, I want to try it someday.

Backup (aka Dropbox)

I’m backing up my repository on a shared drive

git clone --bare /dev/coolproject /Volumes/SharedHome/gitrepos/coolproject.git

The ‘–bare’ argument is used to create only the repository without a checkout. I also use the same technique to backup and share some project with Dropbox. This way I can share with people I know. They can git pull my project without me having to create a public repository on github or setting up the necessary stuff on my web server.

Now I’m ready to push to this repos with

git push /Volumes/SharedHome/gitrepos/coolproject.git

I can also set this remote as the origin (or any other name)

git remote add origin /Volumes/SharedHome/gitrepos/coolproject.git

And I will be able to push using a shorter command

git push origin

this idea have been stealed from this great blog post titled Version Control Makes You A Better Programmer

Git and CVS

Git have a nice feature that let you commit with different author information. When I update from CVS to get new code from my coworkers, I can commit stuff to Git with

git commit -a --author="cvs <dev@cie.com>"

after it have been done once, I don’t need to type the full author info, name will be enough

git commit -a --author=cvs

I have an alias in my .profile (.bash_profile) to make it faster

alias gitcvs='git commit -a --author="cvs" -m "cvs"'

This way, everything coming from CVS will be easily identifiable. Obviously, every commits in the CVS don’t translate in a commit in Git, but I don’t really care, as I will use cvs log if I really need to digg something. I’ve heard about git-cvsimport, but that sound too complicated for my simple needs for now, will take a look at it later. Now I have to get some work done.

Before running cvs update, I usually commit all my stuff to Git and CVS. Even better, with Git I can just ‘stash’ my modifs (git stash) run cvs update and then re-apply the stash (git stash apply). The stash is like a temporary placeholder for your code. I need to read more on it.

To be continued

Let’s see if this setup will stay usable and useful for me in the near future. Stay tuned