Bruce Eckel's tour de force on typing

What an essay! Bruce Eckel writes on typing in Java, Python, C++ and other languages.

Automate everything

A lesson from J2EE development that is widely ignored, especially in corporate environments, is automate everything. In particular, Carlos Perez notes the phenomenal productivity of this approach in Mildly Complex Webapp in 2 Man Months!?.

Pallada: IntelliJ IDEA 4.1 (build 2002)

I just downloaded the latest EAP build from IntelliJ of IDEA 4.1 (build 2002)—4.0.2 is the current stable release—and am quite pleased with it. My subjective impression is that it is rather faster than 4.0 for my most common task: opening classes and files by name (C-n and S-C-n, respectively) and browsing classes from within source (C-Mouse-1). It seems to be about the same with memory usage for a largish project I work on most times. So far, I'm quite pleased and am looking forward to trying out the new JDK 1.5 support features on Wisk.

(See §B.5 of the GNU Emacs Manual for an explanation of notation for key bindings.)

UPDATE: I am having trouble with C-Space not working when there is a declaration of an as yet unimported class. Back to 4.0.2 for a while.

UPDATE: It turns out that C-Space does work, it just doesn't work the same as it used to. You need to now move the mouse over the type needing import, and 4.0.2 is the same. It used to work if the mouse was simply nearby.

Implements broken

Brian McCallister posted a clever idea: mark your borken objects with the Broken interface to support testing for known bugs. When the test fails, you know the bug was unexpectedly fixed:

Where it came up was in a discussion about my practice of writing test cases that are designed to pass if a known-bug which is not going to be fixed yet is allowed to stay in a source tree. The test passes if the bug still exists, fails if the bug has been fixed (so that we know -- this is typically done to document bugs in 3rd party libraries). The benefits of doing this compared to maintaining a seperate src/bugs set of tests which are known to fail wre under discussion (and being determined to be a hack). Instead the suggestion to use a tag to indicate the test is a known and acceptable bug is preferred -- hence implements Broken.

The guantlet

An outstanding challenge from Leo Simons:

The open source community is giving you a choice: either we all work together, and you release a complete JVM under an open source and/or free software license, or we're going to do things on our own. In the latter case the java community will split and the linux desktop community will fragment further as well. There's a big chance microsoft will win as a result. And like before, you'll have only yourself to blame. In the former case, there's a big chance microsoft will lose, open source will win, and you'll reap the profits.

May the powers be listening.

Us thoughtworks assholes with shitty boring jobs

Wowie, zowie! I'm not even sure I like Groovy (I'm a Perl guy myself and Python has a lot of appeal to us Linux hackers), but this time, it's personal:

Whimsy has its place, it's known as perl and other such hacky toys. Leave java to the professionals. If you thoughtworks assholes have shitty boring jobs where you're forced to code in java, don't foist your crap onto the rest of us. Go be perl, ruby, or python monkeys or something suitably hacky that is more egofondlefriendly.

Actually, I find the entire thing rather amusing. The fellow has his point: why is Groovy part of a JSR? Let Groovy be Groovy, not an appendage of Java. That it is built on top of Java is nice and all, but it should be its own thing as much as Perl, Python or Ruby are. I really like that Groovy shares a byte-code interpreter and environment with Java, but that isn't enough to make Groovy a JSR. If that were enough, why not beautiful, elegant Jython? Now that has some groove in it.

Geek envy

I too am a very creative individual; I am a very competent programmer; I too need project management skills. Where's my software architect job? :-)

The success of crap

Charles Miller writes about good projects failing and bad ones succeeding. I also learned what IKIFNI means. I think he left a word out.

Wither wisk?

Wisk is my current SoureForge project. Wisk is The Web Starter Kit, a straight-forward base project for staring Java web projects with a current toolset: Maven, Hibernate, XDoclet and their ilk. However, it also has toy examples of designing enterprise web applications based on my projects at ThoughtWorks. I work with a very bright group, and try to absorb from them as much as I can: it's like grad school for real-world programming. I've discovered that I should have read Martin Fowler's Patterns of Enterprise Application Architecture earlier—what a book! (And that's not just bootlicking.) So I'm looking to gear my toy examples in Wisk towards the terminology and practises in PoEAA. Hopefully that will make Wisk more useful.

Already Wisk helps shave Iteration 0 down quite a bit since one needn't setup the build environment from scratch but can start with a working, tested build and immediately begin developing. Qapla'!

Bruce Eckel on 1.5 suckiness

Bruce Eckel has some tart but accurate complaints against 1.5.

A great discussion on hiring great open-source developers

TheServerSide.COM has a great ongoing discussion on how to hire great open-source developers. This is exactly the sort of internal discussion we frequently have at my company. We are filled with top-quality staff and take only the toughest assignments; without open-source our company would be dead, or at least missing most its staff.

Value objects

What is the correct design for value objects? I'm not talking EJB, but general user types for any kind of large application which takes external input. Some points I think on:

• In a language like Java, should value objects be the equivalent of typedefs, that is, embody no knowledge?
• If a value object has integrity checks in the constructor, what should it do on bad input?
• In Java, if the value object constructor throws on bad input, should it throw a checked or an unchecked exception?
• When mapping value objects to persistent storage, should the mapping match the underlying native type or should it also reflect input restrictions?

Colleagues and I have been discussing this since I joined my current project, and we settled on the most restrictive options: in Java, throw checked exceptions for bad input and in the persistence mapping use the most restricted storage type with integrity checks when possible. I understand the conservative thinking behind these decisions, but I also see that it leads to greater maintenance costs.

Was this the right thing to do?

All hail YAGNI

Wading into the YAGNI discussion, my current client would be much better served by YAGNI than "plan for the future". Why? Who knows the future at a Fortune 100 business? Buyouts. Changing requirements. New management, sometimes several times during the same year. Changed IT environments. Trying to plan for that is a guarantee that you will discard a large amount of expensive work. It is cheaper and better engineered to refactor and design iteratively than to spend large chunks of the front of your project on planning and heavy design. Worry not about change, but about ever making it to delivery. Did I mention cancelled projects among the risks?

If you are stuck in hostile territory and cannot refactor freely, you are forced to increase risk even further and plan up front as much as possible—you only get one swing at the ball when this happens to you, so you have to aim for the bleachers each time. Of course, this means you strike out far more often than need be, but a client opposed to refactoring gets what's coming to them.