Firefox 3

I recently upgraded my Ubuntu laptop to 8.04, which just happens to include a beta version of Firefox 3. Despite the fact that a couple of my favorite plugins, Firebug and GoogleBrowserSync do not have FF3 versions yet, and that I had to get a development release of the del.icio.us toolbar for FF3, I figured I'd run with the new version anyway. Now, I don't know what FF has under the hood in terms of new features or what it has for a plugin API, but I gotta say, this thing is lightening fast and has a small footprint. After seeing how fast it ran on my laptop, I figured I'd give FF3 a try on my work Macbook Pro. The result? I don't have the numbers to prove it, but pages are loading roughly twice as fast and I haven't seen my physical memory footprint go above 200MB yet!

Sweet.

Highlight Aggregator Plugin for Weechat

This morning I just wrapped up an initial release of a weechat python plugin that I have been meaning to write. I would go in depth about it here, but I setup a project on for it at for it at google code instead. There is a full description of it there. It's released under the GPL3 license. You can also pull it from the weechat plugins page.

Subversion Quirkiness

Here's one thing that irks me with subversion: moving the contents of a child directory into the parent directory.

Let's say you have a parent and child directory of foo/bar/ and foo/ is completely empty with the exception of bar/. The normal filesystem, operations for moving the contents of bar/ into foo/ would just be a simple `mv foo/bar/* foo/; rm -rf bar`.

However, in subversion, you can't operate on files by globbing - which sorta makes sense when you consider that each file is a resource that is url mapped to something in the subversion repository. That rules out `svn mv foo/bar/* foo/`. So to actually perform this move, you have to go through this five-step process:

`svn mv foo/bar foo.new`
`svn rm foo`
`svn commit`
`svn mv foo.new foo`
`svn commit`

...and this is just the case for when foo/ only contains bar/.

Visual LINQ Builder... really?

Is it me or is does this Visual LINQ builder seem like *two* very large steps backwards. The first thing that turns me off is the tool. The second thing is LINQ itself.

Firstly, instead of encouraging developers to actually learn SQL or the LINQ dialect of SQL to perform queries, this looks like yet another hand-holding tool that people who use crutches (e.g. Visual Studio) would take advantage of instead of really learning and understanding the tools they have before them.

Secondly, I'm still unconvinced by this whole LINQ thing, as it doesn't seem to solve any other problem except trying make writing SQL or, in this case, a SQL-like syntax in code much more easier. Perhaps I just don't grok it. Since I don't use Microsoft development tools at all, I'm not one to sip on the kool-aid of Anders Hejlsberg - thus I don't have any real incentive to grok it either. LINQ seems to be useful for simple hand written DAO's, but isn't that why we have object relational mappers for relational databases these days? What will end up happening with LINQ is really a continuation and further propagation of a mess of SQL dialect embedded inside business logic, which is precisely the thing that should be avoided in any well designed and decoupled database driven application.

First Post!

... and much like slashdot first posts, this one is completely meaningless. I consider it my "hello world".