Need help with your conversations?

The concept of conversations is crucial when developing web applications.

Conversation is quite a new buzz-word in the industry. It fits somewhere between stateful-navigation, flow-control and Unit of Work.

I first came across the concept when I was looking into Seam.
I think the developers of seam heavily coined the term and the importance of the concept.

In the Java world the foremost concern of conversations is to integrate the UI-framwork with your persistence-framework.

Apart from Seam others have tackled the challenge. Currently I am specificlly looking into the following two frameworks:

Spring Web Flow

Apache MyFaces Orchestra

Of course Grails (based on Spring Web Flow) offers also concepts that go in the same direction.

Samurai techniques

Have fun with this: Confessions of a Samurai Coder Also in the same category falls the following quote from Extreme Programming Refactored: When you follow the Samurai debugging technique, you start with a blank screen. That's not what you want, so you start debugging it, and you continue debugging it until your program does exactly what you want it to do.

Hammers and Monoculture

I get nervous when I ask someone what they do and they say "I am a Java programmer". Because that's kind of like asking a builder what they do and they say "Hammers". They are all tools and we should as professionals use the appropriate tools for the job. The real danger I see right now with programming languages and developers is this idea of monocultures [...] I strongly encourage developers to diversify. -- Pragmatic Dave, InfoQ

I am not alone!

I blogged about me heading for madness and my invented elsewhere syndrome.
But today I discovered that I am not alone! There are people out there, that are suffering with me... maybe we could form a support group and share ourselves?

I felt completely understood when I was reading the first chapter of Seam in Action and came across this:

Just when you've made a decision, a new framework arrives on the scene promising to bury its predecessors.
These choices can be harmful, especially to productivity. Barry Schwartz argues in The Paradox of Choice that having a bewildering array of options floods our already exhausted brains. The result is that your ability to write a quality application stalls. You keep believing that the best framework is the one you haven't tried yet. As a consequence, you spend more time researching frameworks than you do designing functional applications. The search consumes you. You develop a false sense of how busy you are. While you may appear busy, the fact is, you aren't accomplishing much.

Skype me!

Finally I am on skype...


[skypename: jonas.bandi]

Spread the word!

I blogged about my religion before...

Now I have been told to set out and spread the word again:

Behold the day is near! A divine manifestation is coming upon us!

Eric Evans, the author of Domain Driven Design is speaking at the SET Conference in Switzerland on May 6, 2008.

I hope my poor soul will be worthy to witness this transcending revelation and find its path to epiphany.

But I have to confess a certain nervousness, since my last divine encounter has put my faith to the test... severely...

Invented elsewhere syndrome

Is there something like the opposite of the "not invented here syndrome"? If there is, I think I am suffering from it...

Each time somebody shows me some code that looks slightly frameworkish, a home-brewn solution that looks toolish or a self-made process-assistance, I start thinking "you should not have to do this ... there must be an existing solution for this ... you must not do this if somebody else already solved this ..."

And I compulsively start investigating and digging on the net looking for existing solutions and trying to understand them ... evaluating different alternatives ... trying to find the optimum ... spending a lot of time and energy, while not doing anything productive.

I think I have to find a better balance between this "invented elsewhere syndrome" and plain pragmatism!

Jimmy Nilsson about DDD

Jimmy Nilson, the author of Applying Domain-Driven Design and Patterns, has a series of short articles about the motivations for doing Domain Driven Design:

Focus on technology or semantics?

Collaboration and feedback-focus

Do you prefer better or worse code over time?

O/RM might potentially save manual code/time

TDD-supporting

Dealing with complexity

Throw it away!

For a lot of projects a throw-away prototype would be the right thing to do... but people are very afraid of throwing away software. -- conversation at work

Elegance vs. Simplicity

It's a balancing act: balancing elegance of design vs. simplicity. Simple is frequently a lot easier to maintain than elegant. You have to pick somewhere in between. In an ideal world all the code would be very simple and very elegant. Unfortunately you don't have enough time to do everything ideally. Because this is not about delivering perfect code, its about delivering business functionality! If I could spend an infinite amount of time working on a project, I would make perfect code... but I am spending somebody else's money working... --Jeff Norris, IT matters #2

Welcome to the Family

I just could not resist ...