Vaccuum Your Firefox

This has been blogged about in the usual places already, but for those who haven't seen it:
There's an addon for Firefox that defragments its sqlite database, called Vacuum Places. I recently gave this a whirl and was pleased with the results. The responsiveness of my address bar was noticeably improved. Now, bear in mind that I use Firefox a lot. I have over 4000 bookmarks -- its kinda getting out of control. Those who don't use it as much probably won't notice much of a difference, but give it a whirl and see what it does for you. Note that there is a disclaimer saying to backup you profile (easily done with MozBackup), but I haven't had any issues with it.

Some other addons you might want to check out:
Adblock Plus - never see another ad
SkipScreen - auto waits on file upload sites
DownloadHelper - download youtube videos, a page of images at once, and more

DownThemAll! - download everything on a page, based on filters (all pdfs, all images, etc)
Greasmonkey - run custom javascript in website to do all sorts of nifty things (use Greasefire to light up when scripts are available on the current site or get some here)
Stylish - loads custom css into sites (get some here)

Tab Mix Plus - one of the biggest reasons I use it is for the 'duplicate tab' option, but the 'close other tabs', 'close right tabs', and 'close left tabs' are pretty nifty too.

Duct Tape Programmers

Wednesday there Joel blogged about the first chapter of Coder's At Work, where he admired duct tape programmers that were willing to skip unit tests and code quality in order ship on time. I don't really have much to say about it that Uncle Bob and his commenters have said. I agree with just about everything Bob said except for

I found myself annoyed at Joel’s notion that most programmers aren’t smart enough to use templates, design patterns, multi-threading, COM, etc. I don’t think that’s the case. I think that any programmer that’s not smart enough to use tools like that is probably not smart enough to be a programmer period.

In an ideal world, this would be true. And as the industry matures, I think this is becoming increasingly true. However, there are still some programmers out there that aren't very talented and probably shouldn't be programming, and yet they still are. Now I'm not an advocate of making your life difficult to weed out the less talented, but our ever increasing toolbox is lowering the barriers to entry. This isn't necessarily a bad thing. I have a fair amount of faith in the invisible hand and if this allows businesses to get their needs met, then so be it. Just be aware there are people programming that aren't the sharpest knives in the box out there, and they may even be getting away with it...at least for now.

Don't Bother Testing for Null?

This appeared on Rainsberger's blog a couple of days ago

Unless I’m publishing an API for general use, I don’t worry about testing method parameters against null. It’s too much code and too many duplicate tests. Besides, I would be testing the wrong thing.
When a method receives null as a parameter, the invoker—and not the receiver—is missing a test

I think I've got to disagree with him on this one. Unless I'm misunderstanding 'general use'. It might be OK not to test for null if it's just your code calling your code (of course what happens when this gets pushed out, maybe serviceized and suddenly others are calling it?) Even if you do not guarantee the right results if the method is passed a null, I would think you should at least make sure that it doesn't blow up. If it fails, it should fail gracefully. It's true that it's not the responsibility of the receiver to make sure the invoker is calling it correctly, and I wouldn't expect a test for every conceivable possibility necessarily. But nulls happen all the time, its not unreasonable to expect a quick check. There wouldn't even be a lot of code. something like
if (someVar == null) {
    Log.error("it was null");
    return;
}
would do nicely. I do agree there is test duplication between the reciever and invoker, in that both are testing for the null condition on the same variable, but this doesn't really bother me. It seems to me there are lots of tests that have overlap or dependencies. Maybe I'm just crazy. I left a comment on the post.

Extending NTFS with Bad Sectors

I wanted to grow an NTFS partition to use unallocated space this weekend on an XP machine. If it were Vista or Win7, I would have used the built in resizing ability in disk management, and I found I could not do so with my usual tool of choice (GParted Live CD). The error message said that it could not complete the operation because of two bad sectors, and to run chkdsk (which I did) and then use ntfsresize with the --bad-sectors option. When I tried this, it said it couldn't grow it unless I make it bigger with fdisk. The only way I know how to do this would be to create an entirely new partition (which would mean all the hassle of reinstalling windows and the needed apps). I was finally able to do it with EASEUS Partition Master Personal. Unfortunately, it is not open source, but it is free and it did what I was trying to do without restarting in minutes.

Types of Reviews

An interesting discussion was started in this month's section meeting about code reviews. People brought up the point that catching flaws in design implementation requires knowledge of the requirements and that not having such knowledge allows the reviewer to only look for bad programming practices in general. Of course, I'm new to all this, but it seemed logical to me to have three kinds of reviews.

- Design Review

- Implementation Review

- Code Review

The purpose of a design review would be to review the design of the system. This is a higher level view and shouldn't involve any code. The purpose of an implementation review is to review how well the code meets the requirements (somewhat similar to acceptance testing), this test is probably the most time intensive of the three. A code review is a review of the code itself (perhaps with some context, but not at the level of an implementation review. This should focus on errors in logic, and adherence to accepted coding standards (not style). Am I missing something that should be reviewed?


I think when I prepared code for review, it helped when I attached an overview of the classes and what their purpose and general relation to each other was. If a class is very large (probably needs refactored), it may also help to attach an overview of it (at least for the methods most important to complete its job).

It was also pointed out that having people read over requirements and code would take a fair amount of time, which is time not spent on other tasks. An unanswered question was whether pair programming should complement standard reviews or replace them altogether, and how time could be used most efficiently. Everyone agreed that in some way the feedback loop needed to be shortened, whether that be through pair programming or reviewing more often over smaller amounts of code or some other means.

Why Cowon is Awesome

The COWON S9 is infinitely more awesome than the iPod and the Zune. Here are a few reasons why: AMOLED touch display, video playback, FLAC and OGG compatibility (though unfortunately no apple lossless), a completely customizable interface (flash/actionscript), Themes and more themes, games and apps, drag and drop file syncing (no iTunes or special software required), highly customizable equalizer. And they regularly provide free updates. On August 17, they updated the firmware with even more features (previous update was July 24). It also has a microphone and a radio. I also hear they are working on porting rockbox to COWON.

I was a bit nervous when I purchased this, I carefully read reviews and so forth about it, but its a Korean brand I had not heard of before. I've owned it for about three months now and I have absolutely no regrets. It doesn't have quite the storage capacity of iPod or Zune (30GB), but don't think I could fit my entire collection on them anyway. I keep my music in three different places on my computer, some mp3, some flac, some ogg. With my S9, I can just drag and drop whatever in there and it maintains the same folder structure so you can easily find things (ever try making sense of the organization iPod uses?). I'm using my music collection in ways that were simply not possible with my old iPod. If your iPod or Zune has recently bit the dust, I highly recommend.

The Not So Answered Variables in GPathResult

A while ago, I posted that I had gotten the answer on how to get the number of records in an xml file using XMLSlurper (or XMLParser) by passing a variable. It turns out, it was not so answered. This only worked for elements that are immediate children of the root. It seems XMLSlurper and XMLParser can't get longer paths from a single String, it needs to be broken up. (Not sure why it was implemented this way). Fortunately, our own brilliant, Jonathan Baker noticed this and suggested the solution below. It's not complicated once you figure out that the String has to be broken up:

def xmltxt = """
<file>
  <something>
    <record>
      <name>nakina</name>
    </record>
    <record>
      <name>buaboe</name>
    </record>
  </something>
</file>"""
 
def xml = new XmlSlurper().parseText(xmltxt)
def fullPath = 'file.something.record'

def pathElements = fullPath.tokenize('.')
pathElements -= xml.name()
def root = xml
pathElements.each {node ->
    root = root."$node"
}
return root.size()

You could also use split, as John Wagenleitner suggested in response to my comment on his answer on StackOverflow:

def xmltxt = """
<file>
  <something>
    <record name="some record" />
    <record name="some other record" />
  </something>
</file>"""
def xml = new XmlSlurper().parseText(xmltxt)
String foo = "something.record"

def aNode = xml
foo.split("\\.").each {
  aNode = aNode."${it}"
}
return aNode.size()

My thanks to you both.

After talking with Josh, I understand why the Groovy people had to do what they did. Dots (.) are still legal in XML element names, as long as the name doesn't start with a dot. (Actually, other punctuation is allowed as well, though it is not recommended). I don't think they could use forward slashes as XPath does because of how Groovy has overloaded the operators and dots had to be allowable, so this is what we're stuck with. Maybe they should have used spaces instead, since those aren't legal in element names. I don't know the impact this would have on other classes.