Learned Today: Rails is a Harvested Framework

From ASP.NET MVC in Action (chapter 11):

Unlike many other MVC frameworks, Ruby on Rails is a harvested framework, one that was extracted from a real-world application: 37signals’ application Basecamp. Because Ruby on Rails is a harvested framework, all its features have been used in a production environment ...

Never heard the term "Harvested Framework". I think that is a good terminology to contrast the every so often encountered "ivory tower framework".

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

Michael C. Feathers: Seven Blind Alleys in Software Design

Michael Feathers (author of Working Effectively with Legacy Code) gave an interesting talk at the Norwegian Developer Conference:

Seven Blind Alleys in Software Design.

The video of the talk can be found on this page.

Here is a short transcript of the seven dead alleys he identified:

1. Programming in Pictures

This has been a pipe-dream for years and years in the software industry.

"Anybody remember MDA?" (note the notion of the past ;-)

Some complexity is irreducible.

Pictures are not necessary better than words!

Word language symbolism vs. letter language symbolism. Thats the options we have, regardless if visual or textual.

Where are the real systems?

Think about the edge-cases.

2. Metaprogramming

A result from the notion that it is hard to change code.

The promise is that it is easier to change data that represents things in the code.

We have to remember that code is data anyway.

Flexiblity vs. Understandability

Complexity is not reduced with flexibility.

Its hard to figure out what's going on in production.

3. The Ultimate Abstraction

It always just seems one step away.

Believing in perfection

People don't want to make compromises

Programmers are abstraction junkies

Striving for the grand unified theory

Indicator: attempt to unify one and many

Deadlines and budgets help

4. The perfect taxonomy

Do not try to create it upfront. Let it evolve and hope that it eventually will become stable.

Do not generalize too early -> failed framework projects.

Abstractions just have to be good enough not perfect.

English is ambiguous, programming ought not to be.

5. Modeling the real world

Software is really different, it is subject to tighter constraints than the real word

If we can borrow concepts from the domain for our code, then that is great, but we don't have to.

Behavior is key. We can't always find a metaphor. We don't have to be limited by the concepts in the domain. We can make stuff up.

Why would you want to model the real world, thats where the problems are!

Classical example: Liskov substitution princple (Square/Rectangle)

6. Code generation

Accept: You are never going to be complete! Don't be ambitious!

Traps! Can be shaping the code in bad ways.

Effect: De-skilling development

Encodes advanced knowledge of the domain which is likely to be wrong - workarounds are inevitable and get even the norm the older the system gets

Cruft buckets - Places where developers are forced to put their code. No design freedom possibe! Complexity cannot be tackled!

7. Natural Languages

Business people are never going to be able to program - even in plain english

Programming is always going to be more constrained than plain english is

English seems easier, it does read better, but you have to think like a programmer!

I can't say that I always agree, but this presentation really allows you to take a step back and reflect. Michael addresses a lot of current and reoccurring hypes, and lets us remeber that there is no silver bullet.

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

Learned Today: From the Caves to Rambo

Today I came across some funny programmer classifications on the c2 wiki:

	Cave Programmer
Cowboy Coder
	Rambo Coder
Guerilla Coder

Update: Thanks pablohess for pointing me to this: 10 types of programmers you'll encounter in the field

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

Announcement: Zühlke Blogstream Transfer

I will be leaving Zühlke at the end of August. The Zühlke Blogstream I aggregated, will be maintained by Stefan Jäger.

Stefans aggregated Google Reader URL is here.

The RSS-Feed has not changed: http://feeds.feedburner.com/zuehlke

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

Writing Unit-Tests for Java in Groovy: Not so brilliant after all?

Update 2009-08-18: I did only get halfway to true enlightenment... Dierk König was so kind to correct me in his comment (see comments bellow). Thanks!

There is advice out there, that it is a good idea to use Groovy for unit-testing your Java code. The following developerWorks article is a good example for this idea: Practically Groovy: Unit test your Java code faster with Groovy

There is even the opinion, that writing tests in Groovy can be a good starting point to secretly sneak Groovy into your Java project.

Dierk König was giving an interesting talk at gr8conf presenting "Seven Groovy usage patterns for Java developers".

Using Groovy for unit-testing would best fit the "House Elf"-pattern, along with using Groovy for build automation, deployment and functional tests.

But Dierk König did not mention unit-testing in his presentation!

When questioned about that, Dierk König gave an interesting answer:

Unit-Tests are ideally realized with Test Driven Development (TDD). But TDD is more about design than about testing, the resulting unit-tests are just a convenient by-product of the process.

So unit-tests should be a design tool, a mean to drive and evolve the underlying code.
Dierk König argued, that ..

...in order to achieve the goals of TDD, unit-tests should be written in the same language as the underlying code.

Sounds pretty obvious to me...

It is clear that this is only valid for true unit-tests. Integration-tests and functional-tests are a completely different story. I think thats the area where more expressive languages like Groovy can shine.

Thats probably also a reason why the real BDD scene seems to prefer Ruby and Groovy...

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

Book Review: ActiveMQ in Action

Manning was so kind to send me a copy of ActiveMQ in Action.

Note that this review is based on the July MEAP version of the book. Not all chapters are available in this version yet.


Chapter 1: Understanding Message-Oriented Middleware and JMS
This is a solid introduction to JMS. The chapter first touches briefly the topics of Enterprise Messaging and Message-Oriented Middleware and then dives into an overview of JMS. The core concepts of JMS are explained and the main Java APIs are introduced.
For readers who don't know JMS, this chapter offers a clear and concise overview. It is written in an easily understandable way which helps to get you a kickstart on the topic. If you have already worked with JMS, then this chapter offers nothing new, but it can be a valuable repetition.


Chapter 2: Introduction to Apache ActiveMQ
This chapter first gives a theoretical overview over ActiveMQ: What is it and why, when and where should you use it. Then the chapter explains how to set up a basic installation of ActiveMQ and how to run the basic examples. Finally some usecases are explained, that will be used as reference throughout the rest of the book.
This chapter is very hands on. Don't expect any grand insights. But it provides a quick and reliable way to get ActiveMQ up and running.


Chapter 3: Understanding Connectors
This chapter takes a profound look at connectors, which provide the core mechanism for communication in JMS. The chapter explains the different configuration options that are available and the advantages and disadvantages of them. The provided information is quite detailed and extensive. There are a lot of code examples that illustrate the different configuration options.
While this chapter is quite low-level (meaning it deals a lot with networks protocols) it also provides the base concepts for different broker topologies, which is one of the major design decisions when creating a messaging system.


Chapter 4: Message Persistence
At the beginning of this chapter there is a short theoretical explanation about the differences concerning storage for Queues and Topics. The rest of the chapter is again a hands on. It explains the different storage options that are provided by ActiveMQ and discusses their advantages and disadvantages. Again a lot of code examples illustrate how to configure the different persistence options.
This chapter gives you a good overview and is useful a reference when you have to evaluate and set up ActiveMQ in a concrete project.


Chapter 5: Securing ActiveMQ
This is rather short chapter that discusses the security mechanisms that are provided by ActiveMQ and shows different strategies for authentication and authorization with concrete examples. The chapter is a pragmatic introduction to the topic, don't expect anything fancy about security concepts or how to secure applications.


Chapter 6: Creating Java Applications With ActiveMQ
Up to this chapter the book dicusses ActiveMQ as an infrastructure that could be run standalone or embedded. This chapter bow shows how to integrate ActiveMQ in a Java application. Two ways of integration are shown: basic Java integration and Spring integration.
This chapter is quite short. I was a bit disappointed, because I hoped for some information or guidelines about the architecture and design of applications using ActiveMQ (or more generally MOM/JMS). This kind of high-level overview is not part of this chapter. The chapter simply explains how to instantiate, configure and get running ActiveMQ with plain Java or with Spring.


Chapter 8: Connecting to ActiveMQ With Other Languages
This chapter is mainly a big collections of examples how to use ActiveMQ with other languages/platforms. In this use-case ActiveMQ is set-up as a MOM-service and different clients are used as message producers and consumers.
There are examples for the scripting languages Ruby, Python, PHP and Perl. Those are using the text-oriented STOMP protocol and some third-party APIs for the respective language.
The examples for .NET and C++ use the NMS resp. CMS APIs that are also provided by the ActiveMQ project.
Finally there are examles for the REST and Ajax interfaces that ActiveMQ provides out of the box.
The chapter is a good overview and tutorial to get up working examples with the different clients. However the examples are very simplistic, and I guess for a real world project some more information will be necessary very soon.


Chapter 12: Tuning ActiveMQ For Performance
This chapter shows and explains some different factors that can influence performance in a system based on ActiveMQ. Different options and configurations are discussed and a complete example is shown.
The discussed options reach from low-level network/protocol configurations (like cacheSize, tcpDelay ...) over application-level design-options (like embedding a broker in the same VM) to system-level considerations (like transactions or flow-control from producer to consumer).
In my opinion that is the most interesting chapter of the book, since it treats some topics that have an influence on the architecture and the design of a system that is based on ActiveMQ (or more generally MOM/JMS).


Chapter 14: Administering and Monitoring ActiveMQ
This chapter shows several ways how to monitor and manage ActiveMQ at runtime. This starts with discussing the possibilities to get or set information via JMX and shows how to get monitoring information by special JMS-Messages ("Advisory Messages"). Then several tools for monitoring/managing are shown: command-line, JConsole, and WebConsole. Especially cool is the possibility to use a XMMP-chat-client instead of the commandline. Finally logging configurations for client and broker are discussed.
Again, this is a very hand-on chapter. The different options are explained in great detail with the necessary code-examples and screenshots.


Conclusion:
This is a very solid hands-on book, that lets you smoothly dive into the details of ActiveMQ. However do not expect an epiphany while reading the book.

This is the perfect book if you have one of the following goals:

Get to know the features of ActiveMQ

Get ActiveMQ up and running

Get a reference and explanations for the most important configurations and options that ActiveMQ offers

Get guidance for advanced usage scenarios when using ActiveMQ

However do not expect the following from the book:

Learning how to architect and design applications/systems that use ActiveMQ (or generally MOM/JMS)

How to evaluate if ActiveMQ is the right technology for a new system

For me the book did not contain any real eye-openers nor did I feel that it did widen my horizon (unlike other Manning titles like Grails in Action or jQuery in Action)

There is not much to learn if you are just a plain "user" of JMS and it is not your task to run the JMS infrastucture.

If the above criteria matches your needs, I can fully recommend ActiveMQ in Action.

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

Essential, accidental and fabricated complexity

Programming consists of overcoming two things: accidental difficulties, things which are difficult because you happen to be using inadequate programming tools, and things which are actually difficult, which no programming tool or language is going to solve.

Joel Spolsky

Recently I realized that there is a third kind of complexity that is especially dangerous:

Fabricated complexity

Fabricated complexity is very similar to accidental complexity, but its worse in the sense, that it is not only not necessary, but it was added deliberately and is now generally accepted for some reason that is not questioned.


Fabricated complexity is one of the common underlying reasons for environments where efficiency is confused with effectivity.


The reality loop symptom is the extreme form of this, where people just are concerned with satisfying fabricated complexity and are not producing any additional value any more.

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

Learned Today: Maven Plugin Configuration

There are different options for configuring maven plugins in a POM-hierarchy.

A plugin can be defined and configured in a parent-POM. Then it is executed for the parent itself and for all its children.
This is achieved in the build->plugins section of the POM.

A plugin can be configured only in a parent-POM and selectively included in any child of the parent. Then the plugin is only executed in the respective children.
Configuration happens in the build->pluginManagement->plugins section of the parent POM.
Activation in a child happens in the build->plugins section of the POM.

References:
Maven Doc: Plugins
Maven Doc: Plugin Management
Sonatype Blog: Optimal Maven Plugin configuration

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

Learned today: Reverse Ajax

Issue 1.09 of Javamagazin has an interesting article about DWR.

Particularly nice is the explanation and overview of Reverse Ajax.

There are three techniques how to realize Reverse Ajax:

Polling - bases on continuous requests by the client, if the server has data he can put it in a response.

Comet - based on long requests, there is always a request available on which the server can send a response. Comet itself can be realized in two ways:

Long Polling: Server sends a complete HTTP Response. Request is closed. Client immediately sends a new request.

Streaming: The server returns only a Partial HTTP Response, the initial request is not closed.

Piggyback - fully passive, client events are needed. Server sends additional data on top of a normal response.

First steps in creating an internal DSL with Groovy

Sten Anderson has a great post about creating an internal DSL with Groovy: A Text Adventure DSL in Groovy.

The "domain" of this example DSL is old-school adventure games like King's Quest.

The post shows the different steps how to transform the following Java-like code...

game.look();
game.go("north");
game.take("dagger");
game.take("sword");
game.take("key");
game.take("axe");

... into the following statements:

look
go north
take dagger
grab sword
hold key
yoink axe

Both of the above snippets are valid Groovy code that can be executed on the JVM!

To understand and learn about the implementation of internal DSLs I implemented this DSL example.

The project can be browsed and downloaded on my github account. The project is fully mavenized, and should easily be buildable and runnable with Maven.

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