Thursday, February 19, 2009

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.

Monday, February 16, 2009

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.

Thursday, February 12, 2009

Modular Web Apps with Wicket & Eclipse

I finally got around to experimenting with Eclipse & Wicket. I wrote up the results on my website.

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.

Thursday, November 20, 2008

Crisis, what crisis?

Everybody I talk to seems to agree that I have picked the worst possible time to start my own business (with the financial crisis and all). I tend to agree, but still: thanks to my friend Ralph I actually got my first contract pretty easily. I am currently working a Tonbeller AG in Bensheim, Germany on a designer for business intelligence cockpits. Where the financial crisis seems to kick in, is that the contract runs out at the end of the year. I guess they're going to put the breaks on development in order to see whether the new product gets any traction in the market place. I can't say I mind too much, since I'm really looking forward to spending some time a home in Zürich.
I figure the exact same scenario is playing out all over the world right now. Everybody is a bit worried about the downturn, and by keeping back on spending (on me, dammit!) they bring about the recession they are worried about.

The good news is that this is is your chance to hire me. If you need an expert (alumnus committer, actually) for Eclipse or Wicket in the new year, give me a shout.

Thursday, July 17, 2008

Being Scammed

I recently registered my company, Devotek IT. In Switzerland, company registrations are published by the registry office. Not surprisingly, people scan these publications in order to hit you with advertising, etc. And of course, you get the scammers. So I got a very official piece of correspondance from a company called the "Institut für Wirtschaftspublikationen" (or "institute for economics publications" in englisch). They were trying to get me to pay roughly 500.- CHF for the privilege of being listed in their company register. Of course, it's a complete scam. I doubt anyone ever looks at the register. I take it as a rite of passage. People consider me worth of being scammed. That means I'm a real enterpreneur, woot! Surprisingly, that kind of scam seems to work quite well despite being well publicised in Switzerland. So kids, don't do that at home!

Monday, June 23, 2008

It's Official: Samsung Sucks

I got a reply from the escalating adress at Samsung (remember, the 24" with the red pixel). I'm not surprised to see it came to nothing. They just quoted ISO 13406-2 at me which means, basically, "fuck you". They didn't even send the mail with a working reply-to adress, which means, basically, "fuck off".
Don't buy Samsung monitors. Buy Dell, they offer a warranty against bright pixels. Harumpfh!

Tuesday, June 17, 2008

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.