Nothing like a Microhoo! Frappe in the morning to cheer me up. Chuckle. I reckon Fivebucks should invent a new lip-smacking drink called Microhoo! Frappe, as they hark from the same corner of the planet, then we could all have a laugh at this whole ridiculous escapade on a regular basis, while parting with our hard earned currency. What has this got to do with Java I hear you ask? Uh, they’re both drinks, right?
I just love this quote from Rod Johnson: “The Entity Bean technology somehow ignored every piece of prior art, with the result that you had two generations of completely failed technology … The cause of object-relational mapping probably lost at least six years because of that, and [it caused] billions of dollars of wasted development.” I recall quiet distinctly the first time I looked at the EJB 1.0 specification and played with an implementation. I remember taking a sharp dislike to the technology and thinking that I would never use it. And I was right, I’ve never once used any EJBs (neither entity nor session beans) in any product or project I’ve worked on. There was always a more suitable and easier to use alternative.
The Eclipse runtime folks are beavering away on Equinox and server side focused tooling. Wayne has more details. I’m looking forward to trying this stuff.
Workday, the On-Demand Enterprise Services provider, is to acquire Cape Clear, read the announcement here. Read more from Annrai, and learn more about Integration On Demand. I’m very excited to be part of the Workday team, software delivered as services is the future, and integrating into and in the cloud is a vital component in realising that future. I’m really looking forward to helping make this happen and making it simple to achieve, enabling more and more enterprises realise the benefits, cost savings and new opportunities that software-as-a-service brings.
I do believe the slow burner is coming out on top, there is now a huge amount of very healthy activity around Groovy and Grails. Some good points at TSS: Groovy and Grails testimonials.
09
Jan
Big Switch to the Cloud
I’m eagerly awaiting my copy of The Big Switch, ordered from Amazon.com as it has not been published in Europe yet (plus with the exchange rate its cheaper anyway). Michael Cote has just started reading it and has some thoughts on the big switch and the Cloud. Mentions ESBs as the gateway, but does not mention Cape Clear (we’re not clients). This is a big focus for us and we’ve had considerable success solving this key issue with Workday and their customers using the Cape Clear ESB. Jeff Kaplan has a good post on the Top Ten Reasons Why On-Demand Services Will Soar in 2008.
I’ve been watching with interest the moves towards a proposal for an Eclipse Runtime project, to focus efforts around Eclipse as a runtime platform, with Equinox/OSGi at its core. OSGi is the Java component specification on which the Eclipse platform is built. In fact, Equinox is the reference implementation for the OSGi R4.1 framework and JSR 291. The other work I’ve been following with interest is the Spring framework’s OSGi integration, namely Spring Dynamic Modules for OSGi Service Platforms. The combination of an Eclipse Runtime and Spring as a runtime platform has huge potential, and it is potential that can be realised and exploited today. Apart from the proven dynamic component model and advanced classloading capabilities of OSGi, and the rich development environment that Eclipse provides for it, and the productivity advantages of developing on the platform that is also your runtime, and the Spring framework as a whole, and the wonderful power and simplicity of inversion-of-control and dependency injection, one of the key use cases I keep coming back to when I think about this is hot service re-deployment, being able to update services other components are using without having to bounce the server and without those components missing a beat. In the always-needs-to-be-on, software-as-a-service cloud of the rapidly approaching future, this is a key business operations requirement. I agree with the assertion that the Java market will continue to fragment, but I think a lot of people will head in this direction.
One of my Cape Clear Studio team colleagues works remotely (very remotely, the other side of the world in fact). I installed Jing a few days ago and used it for the first time in anger today, while working out a problem with a new feature. Jing allows you to instantly share screenshots and desktop movie captures. Haven’t tried the movie sharing yet, but the screenshots work great. Its free right now, but clearly they (Techsmith) are going to charge for it in the future. I like it, I might well sign up.
We’re very test driven here at Cape Clear, we develop automated tests for everything we do. We’re not strict about writing our tests first, I for one write my tests with my code, iterating between one and the other in the course of realising a story (we follow Scrum, a lightweight wrapper process on agile/XP). I wouldn’t dream of writing code without some level of automated test coverage, to me it is meaningless - how do I know the feature code works if I don’t have something that proves it works now, and as I refactor the code base through iterations of the product? Writing tests makes me many orders of magnitude more productive as a developer. I still hear the “lack of time and resources to write automated tests” excuse from developers I know in other companies. Sometimes I argue with them, sometimes I just smile benignly: you don’t need more resources or time to write tests, writing tests gives you more resources and time, and of course results in far superior quality software. But the fly in the ointment for us has been automating the GUI testing of our Eclipse-based tools. We have extensive junit tests for the non-GUI parts of the tools, like our (WTP) facet install delegates, our builders, our models etc. Eighteen months ago we chose Eclipse TPTP, the GUI recorder and playback toolkit, to automate our GUI tests. Maybe others have had more success with TPTP than we have, but our experience was less than satisfactory. In the end we only achieved a tiny amount of coverage with it, and it is difficult to keep these kinds of tests passing and running continuously across multiple branches of the product. In general GUI recorder/playback tests are very brittle to even minor changes in the user interaction. Several things happened recently that made me realise we could and should drop that approach. We started to push our (PDE) junit tests up into the UI, specifically in relation to testing our GMF-based SOA Assembly Editor. We wrote tests that did things like clicking on all the tools in the palette and checking that the edit parts and model elements were created correctly. PDE junit tests run in the UI thread. It struck me that we already had 99% of what we needed to automate our GUI tests from junit. What we did not have was:
- a test framework, test APIs, which read like a GUI test specification
- the ability to automate the testing of blocking UI elements, namely wizards and dialogs
The first was easy, I took a couple of our WSDL-to-Java project wizard GUI test cases and prototyped the kind of APIs I wanted, they read just like we write our test specs. Then I implemented the APIs, most of which were very thin (but more test friendly) facades on existing APIs and existing test code. That left me with the wizards and dialog problem. When you launch an SWT wizard or dialog from a PDE junit test, it blocks because its waiting on input from the SWT event queue. The blocking happens in the open() method of org.eclipse.jface.window.Window, from which WizardDialog is derived. In an automated test, we want the input to come from the junit test code, not from the SWT event queue. Fortunatly, open() is public. I will resist going off on a tangent here about one of my pet gripes: the excessive marking of methods as private and classes as final etc. - let me decide how I want to specialise your code, you cannot see all ends and mostly I know what I’m doing. Anyway, back on topic, so now we have our own CcWizardDialog (which extends WizardDialog), and the code looks like this:
public int open() {
if (this.cctest == null) {
return super.open();
}
else {
return doTestOpen();
}
}
protected int doTestOpen() {
Shell shell = getShell();
if (shell == null || shell.isDisposed()) {
shell = null;
create();
}
shell = getShell();
constrainShellSize();
shell.open();
ICcWizard ccWizard = new CcWizardImpl(getWizard(), this);
cctest.testWizard(ccWizard);
return getReturnCode();
}
The cctest member is an object that implements a simple callback interface, typically its the junit test itself. There is no difference in adding these kinds of test hooks to code and doing test-driven development. We write our code to be testable by code. Remember that we’re not trying to test SWT or core Eclipse platform components, we know they are well covered, stable, mature - basically: we know they work. And of course we do manually test and use our tools too. The ICcWizard interface looks like this:
public interface ICcWizard {
ICcWizardPage getCurrentPage();
ICcWizardPage next();
ICcWizardPage back();
void finish();
void cancel();
IWizard getWizard();
boolean isNextEnabled();
boolean isFinishEnabled();
}
And (an abbreviated) ICcWizardPage interface looks like this:
public interface ICcWizardPage {
void setTextValue(...);
void selectComboValue(...);
void setCheckBox(...);
void setRadioButton(...);
...
}
Now you can start to see how the junit test reads, just like you’d write a GUI test spec: launch the wizard, set a value in a text box, select a value in a combobox, go to the next page in the wizard, select a radio button, press finish. After which the call stack unwinds back to the junit test, which can then use project APIs to verify the results. I’ve been deliberately vague about ICcWizardPage. How that works is also quite interesting, and very simple. I will detail this and more in another posting. What I really like about the whole approach is that the tests are quick to write and simple to maintain.
01
Nov
The invisible shed
Rarely do I read something which really makes me laugh out loud: invisible shed.
