Scoring lower against Java

Hoover’s Online has reposted a rather unfortunate article called Scoring Higher with Java talking about how Java has not “turned into the ‘Windows killer’ that it was once supposed to be”. This is clearly not an article from a technology source:

Not only has the impact on Microsoft been minimal so far, Java now faces a growing threat from the open source Linux operating system. Even IBM, a strong supporter of Java in the early years, is now focusing on Linux and was noticeably absent at JavaOne this year.

Err, yeah. This might be true if Java were an operating system, but it’s not. Linux has had huge growth on the server side and, indeed, Java use has grown right along with it. If Linux ever starts catching on in desktop computing, it is entirely possible that we’ll see an increase in usage of Java-based desktop apps. The rise of Linux only helps cross-platform application environments like Java.

It’s a real shame the publisher, New Straits Times of Malaysia, didn’t get a geek to look at this article before posting it. Who knows how many businessfolk might read this and get the wrong impression of the value of Java-based apps.

REBOL/Core is free now

This isn’t completely new news, but it’s new to me. As of the REBOL/Core 2.5.5 Release from March 10, 2003:

This release also amends the end user license agreement to allow the free use of REBOL/Core for commercial and educational purposes. Separate licensing for such end uses is no longer required.

I always thought that REBOL looked like an interesting scripting language because of its simplicity in handling Internet tasks. But, I never thought it was so much more interesting than Perl or Python that I would want to actually license the core language for a project.

It seems like a good licensing move for REBOL, because it will bring more people in to the language. The more users they have for REBOL/Core, the more likely it is that people will buy add on libraries.

Agiledox and I’ve been doing it wrong

Joe Walnes writes about Agiledox, and the first tool Testdox. Testdox creates documentation from unit test method names. More often than not, I’ve been naming my tests based on the method they are testing. This is sometimes descriptive, because I tend to write more small methods instead of fewer large methods. However, I like what Testdox does and the implications that has for using a TestCase as documentation for how to use a class.

Anthill looks pretty spiffy

Looking to turn on automated builds, I started looking at Cruise Control yesterday. The documentation left a little to be desired and before I had gotten too far I searched to see what other docs there were. That’s when I encountered Anthill, which is an automated build system that runs in a webapp. Anthill is available in both open source and commercial versions. Deploying Anthill was very quick and easy, and all configuration could be done through the web.

I did run into a problem with JDK versions, because we have one project that is 1.3 and others that are 1.4. Anthill Pro ($1,299) allows you to select which JDK to use for each project (plus many other features over the open source version). We’re not ready to commit that much money to the tool. It looks straightforward to add that one feature in, though.

Which leads to an interesting question… Does a vendor with open source and commercial versions of a product accept patches to the open source version that add features that previously only existed in the commercial one?

Kent Beck interview at DeveloperWorks

IBM DeveloperWorks gives us Working smarter, not harder: An interview with Kent Beck. It’s not a very long interview, but there are some decent quotes:

So, simplicity is about acknowledging the tricks exist but not using them. Wouldn’t it be cool if we could use the Java Security Manager here? Yeah we could, but let’s just put the name of the class. I used to feel proud of myself when I used something no one else knew about. Now I’m disappointed — I apologize when I can’t think of a simpler way.

Also of note: Beck said that he and Erich Gamma are working on a book about Eclipse.

IDE Bloat addendum

Yesterday, I responded to talk about bloated IDEs by saying that they make me more productive. I forgot about Joel’s great article on the topic. Joel says that 80% of the people use only 20% of the features of the product, but it’s a different 20%. He’s right, and the same rule applies to IDEs just as much as it does for word processors and spreadsheets.

That’s why plugins are a good thing for IDEs. Not everyone cares about UML, but those who do can get an Eclipse plugin for it. Even with all of the available plugins, Eclipse is still a large package, because even the basic platform needs to support many different styles of working, coding conventions, etc. That’s why Eclipse has so many preferences. But, we’re all programmers, right? Big tabs of preferences don’t work well for consumers, but we’re a bit better at grokking how features are configured via preferences.

I’m not trying to convince anyone to start using an IDE. Do whatever gets the job done for you. My point here is that there is a reason that IDEs are large and may seem “bloated”.