This is definitely a comment worth sharing.

Now that Apple has released Leopard (Mac OS X 10.5.0) many blogs start talking about the missing JVM 1.6. Here is a quote from one of them:

Om Malik's Broadband Blog in Stale Java for the Mac Faithful:

Mac releases of Java lag those for Linux and Windows, and release 1.6 speeds up applications considerably, something Java needs in its fight with Adobe (ADBE) and Microsoft. Apple teased Java developers at its worldwide development conference with details on how Leopard would work well with Java and the community got its hopes up.

Part of the problem is that Apple insists on developing the JDK for MacOS. But another part is the company’s attitude towards innovation: That’s Apple’s Job.

As a company that makes both the hardware and the operating system, Apple has imposed more restrictions and regulations on its products than other computer manufacturers.

It’s possible that giving developers tools and open access to platforms will further reduce Apple’s control over the desktop. But by limiting development tools Apple is playing a risky game that may send developers looking for more friendly development platforms.

Currently I'm using Java 1.6 for a project on Ubuntu Linux. The IDE of choice is Eclipse 3.3 with a small number of plugins (Subclipse, M2Eclipse and Spring IDE). My experience so far is that Eclipse crashes arbitrarily with the latest JVM 1.6 upgrade 3. It's probably two or three times per day. That never happens with Apple's JVM 1.5 on Mac OS X (Tiger). On OS X I never close Eclipse throughout the week. I simply close the lid of the MacBook Pro, go home, use the laptop to surf the web in the evening and when I open it the next day I simply keep using Eclipse at the point where I left it.

So from my point of view I'm not so eager to use JVM 1.6 at this point in time. Speed improvements are one thing. But developer's productivity decreases drastically, if the tools are not stable. It's cheaper and easier to buy more powerful hardware, than to find skilled developers. I like to focus on my development problems and not on solving problems with the computing environment. In the end that saves a lot of time and money.

The following is a quote from a blog post that made my day. The basic message is that agile development requires top-notch developers who use the best engineering practices known to make it work.

James Shore in It's the Software, Stupid!:
It's time we brought back the early emphasis on great engineering practices. If you're using Scrum or another agile method that doesn't include engineering practices, realize that your method is incomplete. Scrum, for example, intentionally creates an environment in which your team is expected to self-organize and define its own practices. If you aren't doing that--if you aren't talking about engineering practices, what's working, what's not, and how to improve--you're going to run into trouble someday. Probably someday soon.

And he goes on to say:

It doesn't really matter where you get your agile engineering practices from, though. (XP does provide a nice, clearly-defined bundle that's a good starting point, plug, plug.). Whatever you do, don't forget that agile development requires agile engineering. It's not enough to stand around and talk about your iteration plans. You have to code.

And if you're going to code, why not create amazing code, code that's endlessly malleable, a joy to adapt and modify?

That's interesting news. HP is not the only multinational company to move something important to Panama.

HP Press Release: HP to Open Global Services Delivery Center in Panama:
Panama City was selected due to its well-developed information technology infrastructure, large pool of skilled workers, and government and university support.

The telecommunications infrastructure is indeed very good. We have Ethernet over fiber to the Internet and it works without any quicks.

This sounds quite interesting:

Josh Catone in Adobe Demos "Thermo" RIA Design Tool to Delighted Crowd:

The presenters really got the MAX crowd rocking by showing off Thermo's "Convert artwork to..." feature. In a matter of a couple of clicks, a text input box on the UI went from static image to actual form field with the MXML code rendered automatically. Thermo even preserved styling of the form element from the PSD mockup.

The code view for Thermo is actually the full Flex Builder application, which means that it is a powerful development tool for programmers, as well. The idea is that developers can write underlying business logic for a Flex application while designers work on look and feel all from inside the same environment, and the process is as painless as possible for both sides.

But I have my doubts. That awfully sounds like code generation and as to the best of my knowledge that's usually a one-way street. You use a tool to generate the code and once you start making changes to the generated code you can't use the tool anymore or have to reapply the changes again.

On the other hand if that "Convert Artwork To ..." function creates a component, that would be a good solution. I might have to look into Adobe Flex a bit more to understand what's going on here. But at the very least this is an interesting idea and I'm going to see whether we can adopt it a bit and make use of it in our collaboration with a designer we've just added to our Savila development team.