Somewhere out there, there's a poor soul giving a business presentation who's going to call up Google Docs on the projector and get a bit of a shock.
For the rest of you, well, I guess I can live with a Valentines-themed Google Docs as long as next October 31st, I get black cats, ghosts, skeletons and the like to compensate.
I wonder what St. Patty's day will bring?
Thursday, February 14, 2008
Wednesday, February 13, 2008
I hadn't noticed that VMWare had added a teams feature whereby you could set up a series of virtual machines with a particular network configuration and have these be loaded together. As a result, you could create an entire cluster configuration, such as a master/slave MySQL configuration, a firewall, a cluster of application servers, another firewall, and some client machines.
Once this is configured, you could deliver this VMWare team to someone who could do load and failover testing, deployment/upgrade testing on the cluster, and so forth. Seems like a nice option to have available.
Any of you making use of this?
Tuesday, February 12, 2008
Wow - Summer 2008 is going to be a killer Toronto summer for Conferences. We've got:
Thursday, February 7, 2008
A friend of mine, having some troubles with the Data Tools Platform, asked me if I knew much about it. I didn't -- even though I've often had Quantum installed, I usually fall back on standalone tools, either gui tools like like Oracle SQL Developer, command-line clients (mysql, sqlplus), or even generic tools like DbVisualizer.
On a whim, I decided to take a quick look at the Data Tools platform and see what I thought. After all, it might be great.
Turns out, it's ... very Eclipse. It's as if they took someone who'd barely used a database in their life, and certainly not other database tools, and yet was quite familiar with Eclipse. Setting up database connections for the first time is a little bizarre, as there are all sorts of database definitions without the required driver JARs, for which the JAR name is defined, but not supplied.
Once you've got that done, there's a data source explorer which isn't bad - lets you explore the structure of the database and metadata about the database. There's also a SQL Results view, again somewhat in keeping with other tools.
Where it gets really bizarre is when you want to do a Query. For many database tools, this is the central metaphor. There's a query box, you type in it, execute it and get results. For some tools, the idea of running scripts is secondary. That's because doing database development is often very exploratory and iterative, and it's not uncommon to build a query in pieces, executing it as you go, until you arrive at the final query that you intended from the beginning.
However, Eclipse has buried this idea deeply. You can either create an SQL file which you may edit, then right-click to execute, or you can create a launch configuration of 'adhoc query', which you can run in the Run menu. This isn't really ad-hoc, of course, because the query is defined in the launch configuration and not easily changed without going through a multi-step process. Both of these could be useful if the supplemented a simple query view which seems to be bizarrely missing.
Does this strike anyone else as a little queer?
I've gotta say, I'm tempted just to uninstall this, as it's clearly using up space my disk and possibly in memory for no reason at all. In its current form, I wouldn't bother with it.
It's getting surprisingly common for projects (e.g. Enunciate, CXF) to bundle Spring amongst their dependencies, which is creating a bit of "DLL-hell" - having to make exclusions for various versions of Spring and make sure that all the projects can agree on a particular version of Spring.
Requiring Spring to work at all makes these projects spring-dependent in a way that I'm not entirely happy with. Personally, I'd prefer them to be spring-enabled, whereby they are well-suited to being injected in your project, but can operate without Spring, and therefore, don't come with their own version of Spring with which you have to negotiate.
I'm not opposed to there being multiple modules available -- a module that is spring-enabled for projects already using spring, and a module that's spring-dependent for projects not otherwise using spring or not worried about the particular version of Spring. That seems like a handy way around the problem.
Enunciate's case is somewhat forgiveable, in that it's generating a WAR that includes Spring MVC code. I haven't investigated CXF's dependency on Spring, but it's causing some grief for a colleague.
I don't disagree with netzooid's conclusions:
Please keep in mind that REST and SOAP programming models don’t mix well. There is this complete fallacy going around (I succumbed to it too at one point) that you can use the same service class or description to build a RESTful and a SOAP based service. However, the interactions and mappings should end up being completely different from one to the other! One is message based and one is resource based. You’re going to have to design your service differently as they’re two completely different beasts.I largely agree with this. What I will say is that if you've already got a REST or a SOAP API and you have the capability to expose that API through the other technology, it's often possible to do so. While this might not truly be a REST or SOAP api, it's close enough for many people.
That said, the natural approach for REST and the natural approach for SOAP are quite different, and to do a good job of both, you'll find that your services end up being quite different, even if they're layered on top of the same basic infrastructure.
I've used Restlet, and I'm relatively happy with it. It's still maturing, but it's basically ready-to-go. I've been watching Jersey interestedly, and it seems to be shaping up well, but there's always time for the JCP to mess it all up before a final release. I've also used Enunciate, which is capable of generating both SOAP and REST. It's an interesting concept, although I do believe it needs more time to be mature enough to recommend.
Monday, February 4, 2008
Having tried a few different approaches for Object/XML mapping over the years, from SAX/DOM manually coded work, through Rails' (ActiveRecord) toXml, JAXB, XStream, Hibernate, etc, I'm constantly surprised by the idea that most of these frameworks seem to assume that most people are going to want a single representation of an Object in XML form.
In almost every application I've ever built that did any kind of Object/XML mapping, I've wanted to have multiple representations of the objects. In particular, I'm most likely to want these three:
- A simple reference - in this form, I'd like to link to the object, and provide almost no additional information. This is usually used to link from one object to another.
- A summary - in this form, I'd like to provide just enough information to populate a list, or a combo-box, but no more. I'd usually use this to populate a list or a combo box.
- The full details - in this form, I'd like to provide most or all of the information about the object. This is for detailed views of the object.
- Reference<contact id="123" href="http://my.rest.context/api/version/contacts/123.xml" />
<address>1 Yonge Street, Toronto, ON</address>
I've not yet run into an Object/XML mapping framework that made this kind of control easy (do feel free to recommend some, if you like), so I've often felt like a templating approach, the same kind of approaches one uses to generate HTML, makes as much sense as any. In Rails, this takes the form of RXML templates. In Java, this could be Velocity/Freemarker, or something of that ilk.
Suggestions for another approach are welcome.
I've never really understood it, and since I've installed Java SE 6.0 Update 4 about five times in the last few days, it's really started to become irksome. When you install a JDK on Windows, it installs one JRE under the JDK directory (e.g. %JAVA_HOME%/jre) and then, having finished installing the JDK runs out and installs another JRE in a different directory.
Why? What's the point behind this? I realize it allows you to uninstall the JDK and leave the JRE intact, but isn't that like having Microsoft install Office as a suite, and then Word, Excel, etc into different directories so that you can uninstall Office without uninstalling Word, Excel and Powerpoint?
It's weird, and silly. Is there a rationale that I'm missing?
Friday, February 1, 2008
Used to be, when you released software, you did so in major and minor versions, and sometimes patch releases: 8.0, 8.1, 8.1.1. These are the version numbers I grew up with.
These days, it's all over the map. Windows "XP" "Service Pack 2". Java SE "6 Update 4". And let's not even talk about Java 2, Standard Edition, 1.4, Update 1. OS X 10.5
Was the old system so bad? Is there some reason that Java can't be Java SE 6.4, or, if there's an undesired implication of changed functionality, Java SE 6.0.4?
I wonder, have we done this to ourselves in some way, or is there some kind of regulation of which this is the unintended consequence? Has SAS70 compliance scared corporations into ignoring the old versioning approaches because they have become burdened with regulatory issues?
Or is this simply a case of marketing gone wrong?
When Microsoft gets bored of trying to acquire Yahoo and goes back to contemplating how to get away from Windows Vista, I'd like to make this suggestion: Windows 10.0.
After all, Windows 3.1 was followed by Windows 95 (Windows 4), Windows 98 (Windows 5), Windows 2000 (Windows 6), Windows ME (Windows 7), Windows XP (Windows 8) and Windows Vista (Windows 9). I know things get complicated if you look at Windows NT 3.5/4.0 and Windows 2003, so I'll leave those out for the sake of simplicity.
Besides, Apple seems to think that 10 is a good number. I'm looking forward to OS X 10.12, Sabertooth.