Thursday, February 26, 2009

matchit.vim's b:match_words for template toolkit

I put the following in my ~/.vim/after/ftplugin/html_snippets.vim:


let b:match_words = b:match_words . ','
\. '[% \<\(IF\|FOR\|FOREACH\)\>:[% \<E\%(LSIF\|LSE\|ND\)\>:[% \<END\>'


I love vim.

Thursday, February 19, 2009

I like git

There's a feature called 'bisect' in git.

Basically it works like this:

Your're at HEAD, testing out the application, and suddenly
noticed that a bug has been introduced sometime ago (could
be hours, days or weeks or months or years).

How to find the guilty commit?

Git bisect takes the pain away from finding that one commit
that introduced that bug. It performs a binary search along
your history on that bug.

The best thing is that if you can come up with a script that
returns true or false to indicate the presence or absence of
the bug, then you can automate the process of finding that
bug.

And when it comes to scripting, the possibilities are
endless.

Example: Let's say suddenly there's a band of blue pixels
suddenly appearing in the webpage, that you know is not
there a few weeks ago. To find the guilty commit, write a
script that queries that location in your browser
(automatically refreshing the page) for the existence of the
area and returns true or false accordingly, then use git
bisect to find the first commit that introduced that blue
pixels. The script doesn't have to be all automatic, it
could even ask you whether you can see the band or not, then
returns true or false according to your y/n response.

There's a nice article about git bisect at LWN.

Technically this 'bisect' could work as well for svn
(there's svn-bisect on CPAN), but if your svn
repository is not local, then it will take much longer
compared to git since svn needs to checkout each revision as
it is bisecting whereas in git all the history are stored
locally.

But once you found the guilty commit you still have to
manually bisect/debug it to isolate the buggy code.