Spin, as in Bespin

I've just come across this. These people have too much time on their hands. They implemented a text editor in Javascript. They implemented a text editor and UI framework based on the Canvas tag. From Scratch! It won't even run on Internet Explorer. And it looks like crap! Excuse me, but couldn't they just have used Java and run an Applet? While I have nothing against Javascript, it just seems like such a complete fucking waste of time.
Back in the 90ies, the hype was that Java in the browser would supplant Microsoft as the next Platform (with a capital P). Now it seems that Javascript is going to be the thing. Except with a weaker security model, no real modularity story, etc. I think a common runtime across platforms would be nice, but does it have to be Javascript in a Canvas? I want my Betamax back!

Wicket: truly OO

Object orientation has been the great software success story of the 1990's. If done well, OO programming allows to save on development costs by fostering code reuse and by improving maintainability through reduced coupling. In the next paragraphs, I'll show what is necessary to support these techniques in a web framework and how Wicket has exactly those properties.

Code reuse is achieved through polymorphism and abstraction. Polymorphism allows to share code among object that are almost, but not quite the same. You define a common superclass for those objects and override methods to implement the behaviour specific to a particular subclass. Abstraction, on the other hand, works by allowing an algorithm to treat various object the same, even if they are implemented differently. We call this programming to an interface. In Java, for example, you can call methods on an interface, even if you don't know the implementing class. But this is only possible, if we do not depend on the implementation of the object. In particular, the state representation of the object must be private to the object.

The same mechanism of encapsulation also allows to reduce coupling between modules. If I do not know how an object is implemented, I cannot have a dependency on that implementation, and I'm therefore free to change the implementation without consequences in the rest of the system. The biggest maintenance nightmare is the class that nobody will touch, because the smallest change may have unforeseeable consequences.

Since Wicket components are simply Java objects, it is trivial to apply the OO mechanisms of code reuse to create new components. There is no tag library to implement, and existing components can be customized simply be overriding the appropriate methods. In other component oriented web frameworks, there is usually a clear distinction between creation and use of components. In Wicket, there is no such distinction. You cannot write a Wicket application without creating at least one component: the home page.

Wicket's use of controlled serialization for implementing private component state, plus a couple of associated techniques (markup inheritance or the component id scheme, for example), allows for truly "black box" components. The best prof of this is the usual installation instructions for wicket component libraries: you just drop the jar on the class path. The component needs to do the rest.

The Business Case for Wicket

I believe that Wicket is a very economical choice of web framework for various reasons. It supports an object oriented, modular architecture in exemplary fashion. That makes code reusable and easy to maintain. The philosophy of "no magic" and the restriction of scope to the realm of web user interface make it possible to understand for the framework on a deep level. Wicket is written entirely in Java. This allows the programmer to debug his web application from end to end. It also makes for a very shallow technology stack: there is simply less code to understand and debug. That in turn expands the talent pool if you're trying to find programmers: you can concentrate on hiring the right people instead of the people with the right buzzwords on their resumes.

I have been complaining on the wicket-users list that more could be done to push wicket for business reasons. In future posts, I'll expand on the above points and try to show why Wicket could be right for your business.

Wicket Requests as RPC

When you look at a Wicket URL, it's usually something like this:

<prefix>:page:version:<path to elmement>:AnInterface

The first part is an identifier of a particular version of an object, the second the method to be called. So in a general way, we can understand a request of a Wicket URL as a remote method invocation.

Closed Source is like DRM

My friend Ralph works to further the Eclipse ecosystem in Europe. He argues a lot on the business side of things, and one of the stories he tells in his dog and pony show is how a big company had a large investment in some particular development tools. The supplier of these tools was then acquired by a competitor, who understandably had no interest in supporting those tools. The only way forward for the company was to convert their development process to new tooling, because they couldn't get bugfixes etc. anymore.
The same thing happens when you buy DRM-encumbered media. You effectively give up control of the media to the company you buy them from. Let me illustrate: the new car I bought last year comes with a great feature: the audio system has a USB port where you can plug in a stick with MP3s. I quickly put all of my music on and now I'm sometimes embarassed by the crap I used to listen to in the eighties. The point is: my CD collection goes back to around 1983. I can carry that music forward with me as far as I like because I have it in a reasonably open format. If you buy media that are DRM-infested, the seller still controls it. Just remember when Microsoft pulled the approval servers for it's "Plays for sure" scheme.
The point here is: if, as a company, you rely on some critical piece of software, it really makes good business sense to go with open source software. If you rely on closed source software for a critical piece of your infrastructure, you have just outsourced control over a critical piece of your business to someone else. With open source software, you always have the option to take control of the code yourself. Chances are, you're not the only one relying on the product, so the chance of continuing the development over a long period in time is much higher.

Prose vs. Javadoc

I've been thinking about documentation lately. I believe we often concentrate too much on the small scale documentation. We write Javadoc for every method, but what is usually sorely missing is documentation about the big picture. And I don't mean UML diagrams, I mean good old prose describing what a system does and how it goes about that.
Any reasonably competent programmer can figure out what a method does if he or she understands how a system works in general.

Why Wicket Is Different

Eeelco Hillenius says it well on the Wicket mailing list:

Wicket supports private state for individual components, whereas the
traditional (REST) pattern assumes to take the state out (to string
based request parameters) and up to the request level. The big
difference is that without using a framework like Wicket, you can't
really create self contained components. You have to ensure that state
gets passed in any URL that is generated on a page, ensure the
parameters are properly scoped, have to worry about how to serialize
and de-serialize (from regular objects to strings and vice versa),
etc.

You can test this by creating a Struts app where you create a pageable
list. You'd append parameters for e.g. the page number and query to
every URL that passes back to the page, even if the link you are
constructing has nothing to do with the pageable list. Just the fact
that it is on the page means you have to pass the parameter. That by
itself is doable - though destroys encapsulation -; the problems
really start when you decide to move/ reuse the 'component' to/ in
another page, and when e.g. you add more things to the pass that need
to pass state like for instance tabs.

That really sums up my experience, too: you can use the wildest components and just not care about how they are implemented.

Why Eclipse Is Pointing At Your Big Toe

Rob Williams complains that Eclipse plugins suck. Unfortunately he is right. Most plugins (and that includes some projects hosted at eclipse.org) don't come anywhere near the quality of the Eclipse SDK. Rob asks in a comment why the unwashed masses of plugin developers are allowed to shoot themselves (and the whole Eclipse install) in the foot. As usual, it seemed like a good idea at the time (an still may be).
One of the basic tenets of eclipse development is that there are no privileged clients. The idea at the time was to migrate all IBM dev tools onto a common platform. This would include web tools, c, cobol, you name it. It should be possible to write a state of the art tool for all these problem domains. At the same time, the platform should allow for all these tools to seamlessly integrate into the same workbench. It was felt that the platform would only end up with the appropriate degrees of freedom if the developers of the Eclipse SDK would themselves have to live by the same rules as all the "third party" plugin writers (a practice called "eating your own dogfood"). That meant that if the JDT or the update manager or whatever SDK plugin could plug in some functionality into the workbench, anybody else could do so, too. Voila a whole bunch of loaded guns conveniently pointed at your foot ;-)

Visitors Not Welcome

The Register carries this story today. Am I the only one offended by this? Oh well, I'll just not visit!