Eclipse TPTP is a waste of time

I wasted many hours of my precious weekend to get the Eclipse TPTP Profiler to work. My scenario was a simple standalone Java application.

Conclusion: it's not worth it, trying TFTP to work is an extremely frustrating experience. My life's too short for this kind of thing and I'm not the only one.

Android API: Can't touch this!

From Ed Burnette's blog entry on the Android SDK M5 update:

But my favorite addition to M5 has to be a function called “getDataFilePath()”. The documentation says:

DO NOT USE THIS FUNCTION!! Someone added this, and they shouldn’t have. You do not have direct access to files inside of a content provider. Don’t touch this. Go away.

MapReduce: is it really "a step backwards"?

Some database people are not too happy about MapReduce starting to win the hearts and minds in academia.

The rhetoric smells like yet another religious war. This is where I spit my morning beverage on the keyboard:

Given the experimental evaluations to date, we have serious doubts about how well MapReduce applications can scale.

Furthermore it seems like they ignore that MapReduce tries to solve a very different problem than an RDBMS. One, for which a traditional DBMS doesn't provide a good solution right now.

MapReduce: A major step backwards by David J. DeWitt and Michael Stonebraker


via Artima.com

The Java closures controversy

Although I didn't have time yet to study all the alternatives in detail, I've read a few blog posts and watched the video of Joshua Bloch's presentation at Javapolis about the BGGA Closures proposal.

I tend to agree with him. Rushing into a closures implementation and adding yet more complexity to Java is a great chance for the Java community to shoot itself in the foot and turning Java into another C++. In my opinion one strength of Java has always been the ability to say no to new features until there was a convincing solution.

Dalvik: Google's workaround for Sun's JVM

Mobile programming suddenly got a lot more interesting

Dalvik: how Google routed around Sun's IP-based licensing restrictions on Java ME

Dalvik is a virtual machine, just like Java's or .NET's.. but it's Google's own and they're making it open source without having to ask permission to anyone (well, for now, in the future expect a shit-load of IP-related lawsuits on this, especially since Sun and Microsoft signed a cross-IP licensing agreement on exactly such virtual machines technologies years ago... but don't forget IBM who has been writing emulation code for mainframes since the beginning of time).

The Android SDK does not compile your Java source code into Dalvik's bytecode directly, but it first uses a regular java compiler to generate regular java bytecode (say, javac or the built-in Eclipse compiler) and then converts that bytecode into Dalvik's bytecode (the "dx" tool does this: convers .class/.jar into .dex files).

[...]

there is no need to ship a java virtual machine on your Android-powered phone and you can use your regular Java standard edition to develop your phone application (means, you don't need to use Java ME anywhere at all).

Working / reading retreats

John Carmack says:

Once or twice a year I go on "working retreats", where I lock myself in a hotel room for two weeks with no internet connection for completely focused work.

Many-many years ago when I read about Bill Gates' twice-yearly "think weeks" I immediately realized how much I needed such a thing. Either reading or working would be fine. Just go completely offline, no phone, no emails, no feeds, no internet, no TV.

I'll try do do one full offline weekend for practice sometime. :)

Hudson

For almost 5 years we've been using CruiseControl for continous builds. Last time I actually fiddled with the setup it was very buggy for such a widely used open source project but I learned to live with it because there were no convincing good alternatives.

Currently my company is evaluating the commercial Anthill for managing build reports for projects based on both Java and Microsoft technologies. Anthill seems nice, but it's commercial and closed source software and I would prefer something open source.

So I spent some time looking at Hudson. It seems really nice, with tons of features, GUI configuration and support for several issue tracking and build systems.
I especially liked the weather report like overview as seen on deadlock.netbeans.org.


Unfortunately I stumbled into a problem while trying to connect to our SVN server so I can't recommend it for our project just yet.

Software Engineering Radio and public speaking

I recently discovered Software Engineering Radio and added it to the list of podcasts I regularly listen to during my commute.

There are 2 interviews in the archives with none other, than Prof. Doug Schmidt, who works at the same institute where I do (he is the creator of the ACE/TAO framework and the author of the Pattern Oriented Software Architecture books among others.). Unlike most of us nerds, he is a truly brilliant public speaker. I admit sitting in during some of his talks where the topic itself was not all that interesting for me, just to listen to him talk.

Well, today, I realized one of his secrets. Well, in addition to being smart of course. And having a good sense of humor. His other secret is: he talks fast. A high words per minute count doed make you sound more interesting and even smarter.

See also GeekBrief TV's episode 166, where Cali Lewis talks about why learning to talk fast is important. [Update: the archive doesn't go back enough to see that episode. Oh, well.]

Passed the SCJP exam

Many years ago I wanted to get an SCJP exam, but changed jobs before I could take it and later forgot about it somehow. Last month I decided that I'd take care of this unfinished business.

It took me a bit less than 2 weeks to prepare spending about 1 hour a day on average reading the book and solving example questions.

The exam is not hard if you have a lot of Java experience (I started developing in Java back in 1997 with JDK and 1.0 and Applets...) but it does have a few trick questions. The format is typically: what does this program print, but since "compilation fails" and "an Exception is thrown at Runtime" are almost always among the possible choices you have to look at the code carefully.

Some of the things I learned during the preparation are pretty much useless, like watching out for silly mistakes that modern IDEs, such as Eclipse catch for you immediately as you type the code.

Other questions test your knowledge of corner cases in the language that I've never encountered in my many years of coding, such as whether catch (Exception e) will catch AssertionError or whether this abomination compiles:

long[][] a[] = new long[3][][];

(It does.)

So now I'm certified (I got 90%) and know much more about the java.util.Scanner class than I'll ever need to. :)

Code reviews, automated testing, static analysis

There was an interview on The Java Posse podcast where Brian Goetz (whose book is great BTW) said something about software QA which made me nod heavily in agreement. (It probably looked strange standing alone in the bus stop). I liked it so much, that I'll transcribe it here:

"If you ask most developers on the street 'why do we test code' you'll get an answer something like: 'to find bugs!' Finding bugs is good, but I think finding bugs is a happy side effect of writing tests. [...]

Writing tests is one of those necessary things but it exhibits diminishing returns. The first 100 hours you spend writing tests are probably going to be more effective in terms of improving your confidence in the code than the 100 hours from 1000-1100. [...]

A better way to think about the kind of testing that we do is not that we're looking for bugs it's that we're looking to buy confidence. [...]

Writing tests is a form of buying confidence that exhibits diminishing returns.
Code review does the same thing. [...]

And if you try to apply portfolio theory to optimizing the QA budget [and] you observe that both of these buy you confidence with diminishing returns and they're uncorrelated then the optimal portfolio is to have some mix of testing and code review rather than putting all your eggs in one basket or the other.

Static analysis yet a third thing we can do [...] that tends to find different kinds of bugs than either testing or code review. So it's something that should be part of everybody's development lifecycle, ererybody's arsenal, everybody's toolkit."

I'm a huge fan of FindBugs and other static analysis tools I wish there were more ways (ie. a richer set of annotations) to make things in Python (and even in Java) more explicit, so that these tools could catch stupid mistakes for almost free and immediately rather than letting them slip through and manifest as hard to find bugs further down the road.