Month: August 2007

J2ME: Write Once, Be Disappointed Everywhere

We developers and other nerdy folk are used to using strange and klunky applications that do something special, and we’re used to that trade-off.

Eclipse is an IDE so it’s hard to imagine it not being baroque and difficult to use, requiring weeks of effort to become productive. JBidWatcher has saved me a lot of money on eBay so I could probably put a dollar value on how much it’s worth to endure its bizarre UI. Azureus is fairly fugly also but it does a very good job and has a deep, sophisticated UI that’s fairly easy to understand, so despite the eyesore, it’s at least fairly clear. The common thread among all of these is that they are all written in Java, and that they are so valuable that it’s worthwhile to overlook the ugly UIs.

Now imagine those sorts of trade-offs, but on already difficult to use mobile devices, and aimed at consumers. Are you making a strategically wise choice by sacrificing usability and control over the user interface, and probably access to platform-specific features such as dialing the phone, in order to save money on development? Adam Breindel talks about this in When Building a Smartphone App, Resist the Siren Song of J2ME.
Continue reading “J2ME: Write Once, Be Disappointed Everywhere”

“Ruby faster than Python and Perl!” ORLY?

Ruby faster than Python and Perl! cries the headline. This is based on a benchmark that tests i = i + 1 in a loop, so it’s a particularly useless benchmark, even in a world of benchmarks designed to test unrealistic scenarios that make the benchmark author’s product look good.
Continue reading ““Ruby faster than Python and Perl!” ORLY?”

Bad, Bad Code

I’ve written before about tips for offshoring. One specific thing I said to watch for is the bait-and-switch of talent: during the sales process you’re shown rockstars, but the real code you get is written by clueless newbies. When you set up a project such that you’ve minimized the cost per hour of development, but you don’t have anyone checking the work product (i.e. code reviews) coming from the subcontractor, very bad things happen.
Continue reading “Bad, Bad Code”

Rails, Fixtures, the Test DB, and Test::Unit

From what I’ve seen, Rails’ weakest features lie in the way it prepares the test database and test data, and Ruby’s Test::Unit isn’t much better than the awful but ubuiquitous JUnit that Java developers are accustomed to. I set out this week to impose my preferences on Rails in this area, and that took some effort. Here’s what I did.
Continue reading “Rails, Fixtures, the Test DB, and Test::Unit”

Rails and the notion of Stupid Databases Being a Good Idea

For the last few days I’ve been struggling to bend Rails to my will regarding the proper way to assure data consistency. Today I made some progress. This builds upon some research I did a few months ago, and hopefully this is a more or less complete solution to the problem of making Rails work the way I want it to regarding test databases.
Continue reading “Rails and the notion of Stupid Databases Being a Good Idea”