Blackberry Storm

I’ve had the (fortunate) experience of living my life with a Blackberry Storm. These are my experiences with it.


To start off with how this review should end: it’s the worst phone in the mobile phone universe. Ever. I mean it. I’ve used Nokia’s, Sony Ericssons, Blackberries, Samsungs, you name it, but this one is worst. Why?

  1. The click-screen interface. The SurePress screen. While in general it might seem that the apparent lack of touch-feedback from other touch screens is a problem, in this case the solution is far from optimal. The screen moves away, which decreases the accuracy of the click itself.
  2. The accuracy is quite bad for the SurePress screen, which seems to be a contradiction in terms.
  3. It looses contact with the SIM card. Ehm. Yes, I’ve had to reset the phone (as in: remove the battery) about every three days. That breaks requirement number one for a mobile phone: being able to place or receive a call. It also breaks the second requirement for a smartphone: to have connectivity with the net.
  4. The GPS works. When you’re not using it, that is. If you start google maps, it’s able to find your location once. After that, remove the battery for a good reset.
  5. The SmartEntry/SmartKey (I can’t remember what the sales term was), is sort of a good idea to enter information (SMS, phonenumbers, etc) because it can more or less predict what you’re going to write. But when you don’t want to type what’s suggested, you’re going to have to get around that, and when you’re not really paying attention to what’s on the screen, but only to what you want to say, that can be very annoying.

These five points made me quite crazy. It made me give back the Storm and get something else.

End review: 3 out of 10.



TheMacBundles has an offer for a few utilities which are quite nice. But the killerapp, parallels, I’ve already bought, so that’s sort of an un-offer for me. Also, the rest of the tools doesn’t quite appeal to me, mostly because the tools replace some other shareware of payware tool I’ve already got.

One thing made me curious though: DragThing. I’ve had it on my mac before, but I dismissed it rather swiftly the first time around. And I couldn’t think of any reason why I did that in the first place. So, this article contains my testingresults for the DragThing tool.

First off, DragThing is supposed to be a Dock replacement. Some people don’t like the dock, at all. Personally I’m rather indifferent. It’s nice to know which applications are running at any given time, and for that purpose it works. I use too many tools, like shells, mail, browser, textmate, etc. open in various configurations that I’m not using the dock for keeping the most-frequently used tools (other than mail (postbox at the moment, but that’s for another article) and safari. Which got upgraded today to a real 4.0, instead of 4beta. It didn’t crash, so that counts as good). I’m really not using the document stacks.

In DragThing, you can keep drawers for your apps, documents, folders, urls etc. All nicely together in a thing called a Dock. Of which you can run two incarnations (in the non-paid-for version): one for holding apps, docs, etc and one for the ProcessDock, which has a list of all running processes. The paid-for version also has a disk and window dock, which might come in handy when you have too many safari windows open. Personally I don’t expect much from that, because I use tabbed browsing, so I don’t have many windows open from one application.

You can associate hotkeys with certain things you want to have done, but, frankly, I’m all out of hotkeys right now. Probably the first thing I’m really needing is a two-key hotkey (like emacs with Control-x as prefix), but that’s a topic for another time.

All in all, I’m of the opinion that DragThing is not what I need to manage the stuff I do. It’s not particularly nice looking (a big, who cares topic, but on a mac, well, I do care), and the other needs aren’t that big to have them satisfied by purchasing DragThing.

Gems documentation

When trying metric_fu, gem told me quite gently, though persistently, that it did not know about metric_fu. Blimey. You’ve got to look around the Intarnetz, but then you can find the stuff you need to get more than one repository.

So, what’s the trick?

gem sources

lists the sources that are already available.

gem sources -a

adds that source to the other sources. Jay! That’s what we needed,

RSpec and Forensics

I’m currently reading the beta edition of the RSpec book by David Chelimsky Because a book like this can only be comprehended when actually using the content, I’ve decided to start documenting a new project I’m doing with it.

So far, it has been about Behavior Driven Design (BDD), which is an acronym I’ve head before, but I didn’t have the time to read more about it.

It feels a bit weird specifying stuff using mostly natural language, but on the other hand it’s naturally very cosy to do so. What’s really neat is that you start using the api you want to specify right up, instead of first formalizing a design for it. That way you known that all the methods in your api really belong there and actually work.

While I was busy to code up some small project I received the new linux journal, which had an article on metric_fu. It contains a lot of code that can measure the quality of your code. That is always good to do, because the more checks you perform on your code, the bigger the chance that you run into a bug waiting to happen. Of course, you also run into false positives faster, and most people stop using checks like these because they run into false positives too often.

But reading the article I was thinking to myself: why don’t we use BDD combined with something like metric_fu on hour one-off tools we create to solve a case? Most forensic practitioners I know are bound to run into the situation where all the available tooling is not adequate to perform a certain job. Things that come to mind are refiling images based on camera, but oh wait, based on resolution first, or extracting all email addresses from an image and compare them to some filter, These things should be rigorously tested before put in use, because a simple code snafu can dump all your stuff in the bin and will cost you valuable time to clean up again. There is in this case an obvious tradeoff between codingtime, solvingtime, clean-the-errors-time and the time you need in court to explain that you did everything in your power to not botch up the code. For that last part you would ideally show testing output that shows that your testcases have a 100% coverage and pass every test you thought was possible.