Right is right, right?

Management is doing things right; leadership is doing the right things.

-- Peter Drucker

follow me on twitter, I need some friends :-)

Provocative: MDSD vs. Platform

Two controversial statements about MDSD from the 'Zühlke Late Afternoon Talk: Quo vadis software modeling?':

If you have a good platform then you don't need a modeling tool.

If you have a good modeling tool, your platform becomes irrelevant.

So where lies the truth? Obviously the boundary is flowing ...

I my opinion 'modeling' is a very broad concept, so I would not necessary agree that you can trade between modeling and platform.
But when you replace 'modeling' with 'code generation' I am pretty convinced, that both quotes apply, and they represent quite opposite approaches to software development.

As I stated in Musing about Code Generation, MDSD and DSLs, I think the current trends in enterprise platforms lead to the first statement.

In my opinion code generation is less and less needed on modern application platforms, and since MDSD currently is so tightly coupled with code generation (at least in my experience) I think MDSD in its current manifestation is getting more and more irrelevant.

I think MDSD should somehow better adjust to the notion that "the code is the model" and provide additional abstractions (for different intentions) on top of that.
I think the current DSL-movement is an effort in this direction.
Visualisation would be another promising aspect.

I know this is a provocative statement. Many MDSD evangelists are convinced by their approach... but I just have not seen the light until now, that does not mean that I am not open for an epiphany.
So please leave a comment...

follow me on twitter, I need some friends :-)

Groovy Grape: Problem resolving xalan

There is a problem in Groovy Grape: It fails resolving xalan 2.7.1.

The following grape declaration for instance leads to the error:

@Grab(group='net.sourceforge.htmlunit', module='htmlunit', version='[2.4,)')

The reason is, that htmlunit has a dependency to xalan, and xalan cannot be resolved...

The problem can also be reproduced on the commandline: grape resolve xalan xalan 2.7.1
The following error is printed on the console:

[FAILED ] xalan#xalan;2.7.1!xalan.jar: invalid sha1: expected=sha1(xalan-2.7.1.jar)= computed=75f1d83ce27bab5f29fff034fc74aa9f7266f22a (9927ms)

The underlying reason is the follwing bug in Ivy 2.0: IVY-1006.

The bug is supposed to be fixed in Ivy 2.1, but Groovy 1.6 bundles Ivy 2.0.

Meanwile a workaround is to manually download serializer-2.7.1.jar and xalan-2.7.1.jar from the maven repository and copy it at the place where grape would put it: ~/.groovy/grapes/xalan/serializer/jars/ respective ~/.groovy/grapes/xalan/xalan/jars/ on OS X.

follow me on twitter, I need some friends :-)

reCAPTCHA / Crowdsourcing

reCAPTCHA is an interesting idea.

Seemingly 150'000 hours are spent every day, solving Captchas. This is quite a waste of intellectual energy. reCAPTCHA now tries to recycle this intellectual energy... something like a mental wind-power-plant...

follow me on twitter, I need some friends :-)

Upcoming Review: JBoss Portal Server Development by Ramanujam Rao

Packt Publishing was very kind to send me a copy of their new Book 'JBoss Portal Server Development' by Ramanujam Rao for review.

Book description:

Complete guide with examples for building enterprise portal applications using the free, open-source standards-based JBoss portal server

Quickly build portal applications such as B2B web sites or corporate intranets

Practical approach to understanding concepts such as personalization, single sign-on, integration with web technologies, and content management

I will publish my review on this blog as soon as I have read the book.

If you are interested in the book, here are some online resources:

The homepage of the book at Packt Publishing

The table of contents

Chapter 6 'Portals and AJAX' is freely available online

Sticky open source?

Open source today is often just a lazy attempt to create a public standard. Throw some code at a wall and see what sticks.

- Jan Erik Paulsen
Sun is pulling a “Netscape rewrite” with JavaFX

follow me on twitter, I need some friends :-)

Maven inside: say hello to Groovy Grape!

Actually the title should be 'Ivy inside' - but the coolest thing about Maven is its dependency management... the part that Apache Ivy provides.

Groovy 1.6 has a very cool new feature: Grape - The Groovy Adaptable Packaging Engine

Example:

import org.mortbay.jetty.Server
import org.mortbay.jetty.servlet.*
import groovy.servlet.*


@Grab(group = 'org.mortbay.jetty', module = 'jetty-embedded', version = '6.1.0')
def runServer(duration) {
    def server = new Server(8080)
    def context = new Context(server, "/", Context.SESSIONS);
    context.resourceBase = "."
    context.addServlet(TemplateServlet, "*.gsp")
    server.start()
    sleep duration
    server.stop()
}

runServer(10000)

The @Grab annotation will resolve and download the embeddable jetty servlet container and all its dependencies ... just as we are used to by good old Maven, just without all the pom-hassle!

Place a simple hello.gsp in the same directory, and access it at http://localhost:8080/hello.gsp ...

Very cool, isn't it?

On second thought though we should not overestimate the feature. For one thing it exposes the known weaknesses of Maven (accessibility to needed repositories, availability of all dependencies ...).

On top of that it shifts these problems from build-time (Maven) to run-time (Grape). This can be problemetic since resolving and downloading dependencies can be quite an overhead, that is not always desirable at runtime. And the fact that Grape is not giving any feedback, what is going on (at least not per default) does not improve the situation ...

Considering this, I think Grape is a cool feature for developing and exchanging simple apps/scripts and for prototyping ... but I would not consider it for a productive app.

follow me on twitter, I need some friends :-)

Uncle Bob: The Renaissance of Craftsmanship

Uncle Bob hits the nail on the head once again in his Oredev 2008 keynote.
Great talk, recommended for anybody involved in software construction. My favorite quotes:

Avoid turgid, viscous architectures.

The enterprise architecture that solves world peace vs. minimal architecture

Bad schedules can be redone, bad requirements can be rewritten, bad teams can be reorganized, bad code stays.

Nothing makes a system more flexible than a comprehensive suite of tests! Far above good architecture and good design!

Debugging is a skill that should not be desired!

What does it mean to be a craftsman? It means to take personal responsibility!

You will not ever do things right! - The only solution is to continuously improve!

follow me on twitter, I need some friends :-)

OS X: Quick Look for Groovy

Update: The info in this post is deprecated, check out my post Quick Look for Groovy with Syntax Highlighting.


Quick Look is one of the coolest features of OS X Leopard.

Unfortunately it only supports a limited range of file types.
I blogged before how I got Quick Look to display .properties files.

Lately I am playing a lot with Groovy... and .groovy files are also not supported by Quick Look out of the box.

Finally I got Quick Look working to show .groovy files. But it has been quite a hassle.

In the following I am using TextMate, but this should also work with another text-editor like Smultron or TextEdit.

This is what I did:

I navigated into the TextMate package (right-click->Show Package Contents).

I edited Contents/Info.plist with a text-editor.

I added the follwing snippet at the end of Info.plist (just before the ending </dict> </plist>)

	
	UTExportedTypeDeclarations
  
    
      UTTypeConformsTo
      
        public.text
			public.plain-text
      
      UTTypeDescription
      Code
      UTTypeIdentifier
      com.macromates.textmate
      UTTypeTagSpecification
      
        com.apple.ostype
        TEXT
        public.filename-extension
        
          properties
          groovy
        
      
    
  

Then I set TextMate as the default editor for .groovy files.

Then I did the following steps on the command-line, without really knowing what they do. Probably not all of them are necessary:

touch /Applications/TextMate.app

qlmanage -r

touch ~/Library/QuickLook/QLColorCode.qlmanager

/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -f -v ~/Library/QuickLook/QLColorCode.qlmanager

The result is that QuickLook at least displays .groovy files as plain text:

Next on the wishlist would be syntax-highlighting. Unfortunately this does not work with the qlcolorcode-plugin since Highlight does not support Groovy.

Last tip: To find out which Quick Look generator is configured for a file type you can use the following command: qlmanage -p Greet.groovy 2>&1 | grep 'Generator used'

I collected these infos mainly from here and here.

follow me on twitter, I need some friends :-)

Temporal coupling?

When you group things together just because they have to happen at the same time, the relationship between them isn't very strong.

- Michael C. Feathers
Working effectively with legacy code

follow me on twitter, I need some friends :-)