Recently I started using PHP Markdown Extra in order to format my posts. I decided to make the switch mostly because I find writing Markdown slightly more natural than writing HTML; more than that though I find reading and editing posts I’ve previously written using Markdown to be as easy as reading a regular word document or a book. Of course, the readability of Markdown text was sort of the point of the syntax so my observations seem a touch obvious. The crux of my point stems from my reasons for switching so it felt necessary to elucidate my position.

Through the course of learning the Markdown Extra Syntax I found it supported footnotes, for me this was exciting because I have a tendency when writing to have a lot of tangential thoughts. I usually¹ use parentheticals to capture these ancillary musings but I have noticed this tends to detract from the primary issue during reading. Clarity is something I strive for when writing² and so I figured it would be better to store my tangents away from the rest where they wouldn’t detract from the point I was trying to get across.³

I jumped into using footnotes with both feet and had soon written two posts⁴ making liberal use of footnotes. Upon inspection of the posts on the front page I noticed the references didn’t behave correctly. After some brief investigation I discovered the ids were the same for every set of footnotes which was frustrating for a couple reasons.

1. The footnotes aren’t much use if they don’t actually work
2. Duplicate ids means the document won’t validate, which makes me sad.

I immediately descended on the problem in an attempt to rectify the situation. To make a long⁵ story short I ended up creating a SHA1 hash of the footnote’s text and using it as an identifier for the references and ids. This works quite well for my purposes since it seems fairly unlikely I’ll be using the same footnote text over and over again⁶, however there are some pretty obvsious weaknesses to this strategy, which I’ll outline below. But first I wanted to provide a downloadable patch of the changes I made in order to make this footnote stuff work: you can get the Wordpress Friendly Markdown Footnotes patch and apply it in order to get this working for yourself. I created the patch using git, so if it proves difficult to apply let me know in the comments or via one of the contact methods on my about page and I’ll fix it up lickity split.

Now about those weaknesses; the major problem comes about if you want to use the same footnote text a couple of times. I could see this coming about more on a site publishing research papers than here but that isn’t the point. A better method would have been to use the Wordpress post id via <?php the_ID(); ?> because then the footnote references for the post are all constrained by a shared value. This was in fact my first idea but it seems core Wordpress loop functions are not available inside filters. This made me wonder if perhaps there wasn’t another way to get the post id, either from a filter argument or from some other magical place. Needless to say I couldn’t figure another way out or I would have used the post id method instead. Another issue, though I guess it’s not really a weakness, is the SHA1 makes the references a bit long and unsightly, not to mention meaningless. However, I was just happy to get the thing to work.

That is all for now, I’ll post updates if I make any improvments or changes.

Google released their first version of Chrome this afternoon and while I am quite disappointed to see only a PC version I can certainly understand it given the vast differences in market share.

Having said that I did fire up my handy dandy virtual machine in order to download and take Chrome for a spin. The first place I went was the Motorola USA Phone Browse page because I wrote most of the JavaScript for it and I wanted to see how it would perform in the version of WebKit Chrome uses. Much to my dismay the display of the page is horribly wrong and it looked like some errors were generated. This made me sad so I rapidly vacated the area and started looking at some other oft-used pages of mine¹ just to get a general feel for how things were operating. Everything felt quite zippy on those two sites but that is really to be expected.² So then I decided to check out Processed Tower Defense which is a pretty intense JavaScript application and it ran surprisingly well especially considering I’m doing this in a virtual machine with limited memory resources allocated to it.³ To be honest though I expected the JavaScript execution speed to be impressive, the thing I’m really curious about is how the garbage collection performs compared to other browsers.

The thing I found particularly impressive though was how useful the ‘omnibox’ was, I daresay it was quite a bit more awesome than Firefox 3’s ‘awesome bar’. I’ll go ahead and say a great deal of this is because I really dislike the ‘awesome bar’, I think it falls far short of it’s lofty goals whereas Chrome’s ‘omnibox’ delivers. A big part of the reason I feel the omnibox delivers while the awesome bar falls short is something mentioned in the comic on page 20. Essentially you don’t have to hit the down arrow to get what auto-completion is suggesting because it does it inline and you will only go to URLs you have explicitly typed before.

The feature John Resig dubbed ‘the killer feature’ is something I believe is pretty awesome but it will take a while for the impact John foresees to come to fruition. After all of the six tabs I have open in Chrome right now⁴ Gmail is consuming by far the most resources and Google is often hailed for it’s lightweight applications.

In conclusion, I actually like Chrome in a virtualized environment better than Firefox 3 which is running natively which I think says a fair bit. Of course I’ve also been using Camino over Firefox 3 so perhaps it is just Firefox 3 doesn’t really do it for me.

As I wrote earlier I’ve been using git at work via git-svn with a Subversion repository. At first I thought this was brilliant and would solve my continuous branching and merging ails. As it turns out I wasn’t entirely correct¹.

See, while I like git and how easy it makes branching and merging git-svn doesn’t play quite as nicely² with branches and merges and rebases as I hoped. Maybe part of my problem is that I needed to keep some of the git branches (which didn’t originate as SVN branches) in sync across a couple computers. In order to do this I set up my server³ to store the git repository related to my work’s SVN repository. The problem with this is every time I fetched and merged from the repository hosted on my server and then did a git svn rebase I wound up having to go through and ‘resolve’ all the conflicts coming from a the svn commits pulled in from the rebase on another computer. Not only was this incredibly annoying but it also meant there was the distinct possibility of winding up with double commits when I next did a git svn dcommit.

I’m not too ashamed to admit I had this problem a couple of times before I figured out I needed to use one branch to keep everything synced up with SVN (site_trunk in my case) and another, or several others as the case may be, to do the development work in. This way I use git svn rebase and git svn dcommit from only the place which is following the SVN branch and do merges as necessary to keep other branches up to date with work which has been done. As a result the ’svn branch’ is only used to contact and deal with the SVN repository all other work is done elsewhere. Since I adopted this process I have had no problems with rebasing or double commits.