Now on your door mat: Wicket In Action

Finally, we’re done! Wicket In Action, the dead tree edition, is out! Order it from the publisher, Manning, get it from Amazon, or maybe even a store near you. I hope it will be useful for people. First reviews have been good. If you like the book, please don’t be shy rating it on Amazon and other sites :-)

Wicket In Action almost done

Honestly, the book – Wicket In Action – is aaaallmost done. We’re doing the very last edits, and most of the chapters are in the production stage. Incredible, what a huge amount of work goes into writing a book. Without the help of Manning’s excellent staff, I would have been very close to giving up tbh.

The good thing about being done (well almost) is that for the first time in two years, I’ll actually be able to have some spare time without feeling guilty. And what I’ll do with that? Play music of course! I’ve played guitar forever, and have been singing for a few years (which finally is getting a bit better, thanks to my awesome coach), and I recently bought a bass guitar, keyboard, couple of mics and a decent multitrack recorder. Man, I’m ready to have some fun! :-)

Anyway, for all of you who bought the early access version and/ or have been patiently (very patiently I might add) waiting until the book is done, thanks for hanging in there, and thanks for supporting Wicket!

Wicket and Tapestry compared

Here is an excellent comparison between Tapestry and Wicket. One of the best parts: “Despite the fact that there is a similarity between frameworks’ architectures (both are component-oriented with clear separation of concerns), their implementation is quite different”. And what a breath of fresh air to not have to read about number of job listings, books and other quasi-managerial comparison pollution.

No more explanations needed on the Wicket user list and forums like The Server Side; we can just point to this article from now on :-)

One big difference between the two frameworks that isn’t mentioned in the article is the fact that Tapestry’s component tree is static, whereas Wicket’s is dynamic. The advantage of a static tree is that it is easier to handle and optimize. I guess this is true for having a declarative programming in model. The advantage of a dynamic tree is – obviously – flexibility. For examples of what you can do with a dynamic tree, check out this post and this rant. Also, components like wizards and tab panels make heavy use of this in Wicket, and while I’m sure there are workarounds available in Tapestry, the ability to arbitrarily replace components makes it very easy to implement things like detail screens and such.

Thanks Artem, Jim and Ilya for taking the time of publishing a thorough comparison.

RunJettyRun version 1.0.1 released

There were a couple of bug reports that were solved for this second release of RunJettyRun. Unfortunately, I messed up the first release, and you can’t just update the plugin. If you want to install this, you’ll have to manually deinstall the 1.0.0 version and install 1.0.1. Next time, automatic updates should be working ok.

See http://code.google.com/p/run-jetty-run/ for instructions and the change log.

Open Source software has nothing to do with communism, and it is not free either

This line caught my eye (and I have no idea how I got there in the first place):

Open source just looks like the future to me. Who would’ve thought, but it is pure communism! If people are willing to give such sophisticated solutions away for free, businesses are going to adopt them and there’s no way commercial products will be able to compete.

There is so much wrong with those sentences that I need to let this rant out or I won’t sleep tonight. :-)

First there is the assumption (which is repeated several times in that article) that open source software is ‘free’. Wrong.  Open source means that the source is publicly available. It has nothing to do with pricing. And, even though you can download software without paying for it, using that software is not necessarily free. You need to take into account what the cost of things like maintenance, education and customization are, and heck, you might even end up paying more for using open source software than would for using proprietary software.

More disturbing is his use of the word: ‘communism’. Communism is classless – at least in theory. Open source software is not classless, not in theory nor in practice.  Open source software has nothing to do with project organization. But if you’d had to say something about it, you could say that many open source projects are meritocratic and community driven. People are encouraged to participate, and it is this shared effort that often makes projects great, but people earn official positions (i.e. get commit and voting rights) through demonstrated talent and competence.

Also, for an open source project to reach adulthood, it typically needs lots of input (bug reports, feature requests, patches, discussions, promotion) from hundreds or even thousands of users. But ultimately the project owners decide what to do with that success, as they have got the legal and physical rights (access to servers etc) to do so. Regular users can suggest and complain or they can even branch the source code (in which case they could run into trouble with the license) into a new project, but usually have no final say in the project. Hence, the ownership of the means of production lies in the hands of a few, which is contrary to the communist ideal.

For the companies that I worked for, cost was hardly a decisive factor when evaluating open source vs proprietary software products (except for choosing MySQL maybe). Not being dependent on a single vendor for bug fixes, the often better quality of open source projects (coded by motivated professionals, peer review, many test hours, transparency) and the option of having a say in the direction the software is going, are often more important.

Take that, Ruby On Rails

The Digg entry for Wicket’s 1.3 release announcement on The Server Side has an interesting comment: “I recently converted a Rails site to Wicket. Wicket really cuts down on template spaghetti code. I can honestly say that wicket’s OO approach is the right way of doing things for web application development. If anyone is interested in the site I mentioned, http://fabulously40.com/ “.It’s good to read a statement like this in public for a change.

And finally, here is a new Eclipse/ Jetty plugin

No, I didn’t have time for this. But I just couldn’t help myself, really. I took another shot at an Eclipse/ Jetty plugin.

Out of annoyance with another Eclipse plugin (unrelated to Jetty, and I won’t mention which one), I realized how annoying it must have been for the users of JettyLauncher to not have had any updates the last, what, two years? The thing basically didn’t work for any recent JDK/ Jetty/ Eclipse version. Maintaining it just wasn’t a priority for me (it still isn’t, frankly), and I hoped one of the new guys of the project would pick it up and release something workable. That never happened, and I wasn’t happy with how the plugin was setup in the first place.

So… the feeling of guilt finally took over and I coded a new Eclipse plugin for running web applications with Jetty today. The difference with JettyLauncher is that this plugin is more limited – yes, I consider that to be a good thing, as it is simpler to maintain – and that it ships with Jetty (6.1.6 currently). You can find the project here. I’m back to writing Wicket In Action again now :-)

Tagged , ,

Pre Print “Programming in Scala” available

For all of you following Scala, the first real book is out now! I just bought/ downloaded it, and it looks good. You can get it on the Artima website. Where do I get some time to actually read it. :-)

If you have plans to dive into Scala and you are new to Functional Programming (like I am), I’d recommend you to also learn Haskell to get a good foundation. At least I found that when reading Programming In Haskell, some Scala constructs started to make more sense to me.

Selecting languages and frameworks for developing web applications and the Blub paradox

Via a post on the Scala list I read about the ‘Blub paradox‘ (which roughly stands for the fact that most programmers tend to stick with the languages they already know and/ or go for middle-of-the-road) for the first time, years after it was written. There are a couple of fantastic quotes in there, like:

“You can’t trust the opinions of the others, because of the Blub paradox: they’re satisfied with whatever language they happen to use, because it dictates the way they think about programs.”,

and:

“But if you work for a startup that doesn’t have pointy-haired bosses yet, you can, like we did, turn the Blub paradox to your advantage: you can use technology that your competitors, glued immovably to the median language, will never be able to match.”.

I particularly like the first quote. Most web application framework comparisons I know of sum up things like the number of job listings, downloads, list activity and ‘famous references’. And while Wicket is doing pretty well with at least a couple of these numbers, I believe they are crappy arguments. The only thing in favor of even considering those numbers is that when you evaluate technologies, you’ll typically want to know you’re buying into something that has the kind of support you need (bug fixing being the most important part of that). For the rest… it is entirely possible that 100,000 people are just plain wrong.

So what should a good framework comparison look like then?

First of all, match technology with goals. Maybe you are already using a certain combination technologies, and you experience problems with them. Define what these problems are, and seek technologies that try to address these things. The main reason I ended up using Wicket was the inability model 2 frameworks to scale the development effort. But your goals might very different, ranging from delivering as quick as you can, to addressing scalability concerns of your site, to being able to outsource part of the development.

Secondly, the comparison should not be confined to just one language. Compare Wicket with GWT with Rife with Lift with RoR with Django with Seaside first. The language a framework depends on is important, but look at the complete picture.

Third, look at the quality of the framework. When you read (the better) language comparisons, often a fair amount of attention is given to how expressive and elegant certain choices are. And whether what you would produce with that language would be maintainable and easy to read. Include such considerations in that framework comparison. What can you say about the framework’s conceptual integrity? What would your code look like, and what do you think about the framework’s code? Considering the quality of frameworks is largely ‘art’, and – except for undeniable excellent libraries like Guice and Joda Time – it probably comes down to what your taste is. But try to form an idea on this regardless.

Fourth, just bother with the promising ones. A common complaint of people is that there is too much choice. It’s a known economical principal that too much choice makes people less happy with whatever they chose. But it is also known that competition drives innovation, which of course in the end will produce frameworks that will make your life as a programmer better. A complicating factor here is that in the real world, companies go out of business when they fail. That’s not true for open source software. Which is both good and bad. It is good because a library can work great for you, even if it never got a lot of attention. Pnuts is an example for this: it doesn’t seem to be particularly popular, yet I’ve used it in a couple of projects and I am very happy with it. On the other hand, some software should just go away. While Google will hide the greatest losers for you, unfortunately, bad ideas can stick around for a long time. Don’t include Struts 1 in your comparison: it sucks. While it was a helpful project a few years ago, by now there are many far better alternatives. Accept the fact that Struts is a victim of creative destruction. Struts is not alone either, but you can decide that for yourself.

Fifth and last (at least for this post), there is no substitute for trying stuff out yourself. It is never a waste of time to learn a new language, and in a similar fashion, I thnk spending a few hours with a framework you might consider isn’t wasted either.

Tagged , , , , , , , , , ,

Our NYC office is hiring

We’re looking for people for our Manhattan office. Sorry for being lazy, but I’ll just copy the job description here:

Junior Software Engineer(Java)

Teachscape, Inc. is looking to hire a Junior Software Engineer to work in our downtown New York office. We have a small, very experienced and talented team. We work with cutting edge technology and frameworks to deliver professional development to teachers online. This would be a great opportunity for a junior developer to learn and grow from working closely with best-practice software development and world- class Java developers.

Requirements:
* 0-3 years as a software engineer
* BS in Computer Science, or equivalent experience
* experience with server-side Java programming and related frameworks

Core Responsibilities:
* Participate in the development and maintenance of the company’s software systems
* Participate in the creation and maintenance of specifications and documentation

Additional Requirements and Responsibilities:

* Detail-oriented and thorough
* Excellent communication and interpersonal skills
* Experience with client-side web development is a plus
* Engineer will be exposed to the following technologies, any prior experience is a plus: Java, Spring, Wicket, Hibernate, MySQL, Eclipse IDE, Jetty, J2ME, Adobe Flex, Maven, Subversion, Linux, Apache

We’re hoping to get some reactions. We have an interesting team and some very interesting things to build. Please drop me a line if you’re interested or you know someone who might be!

It’s also on DICE.

Follow

Get every new post delivered to your Inbox.