Certification to become braindead?

The following question and solution is from the preparation for the Sun Certfied Enterprise Architect (SCEA) from the Sun Learning Center:

You are architecting a real-time system with high usage and high volumes of transactions. You need an MVC application with quick presentation times resembling a thin client and will have several pre-populated views that can carry across several pages. The users must be able to quickly navigate between different sections of the system.

Which three technologies will you need to implement? (Choose three.)

A) MDB

B) Swing GUI controls

C) JSP

D) EJB3 Entities

E) Stateless Session Beans

F) JCE

The solution:
Options C, D, E are correct.
Option A is incorrect because it is a real-time system, and MDBs are asynchronous.
Option B is incorrect because swing components are notoriously slow.
Option F is incorrect because nothing is mentioned about security requirements.

"Swing is notoriously slow" as the reason to create a web application??? C'mon ... is that the well-grounded professionalism you are expecting from an architect?

Tidbits from Adam Bien

I was attending Adam Biens workshop 'Designing The Boundary - Rich UI Meets Efficient Java EE Backend' at the workshop-days of /ch/open.

I blogged his comment about rich- vs. anemic domain models here. Here some more tidbits:

If an application has more than three layers this is suspicious...

There is a trend towards rich-client applications! The hype around platforms like FLEX/AIR, Java FX, Eclipse RCP, Google Chrome are a clear indicator of this.

There are good reasons to keep your business-logic close to the persistence.

There are a lot of arguments for stateful web applications. For typical inhouse enterprise applications with ~1000 users performance problems resulting from keeping the conversation state on the server should not be an issue.

The DAO-Pattern is dead ... as are many other classic J2EE patterns. We have to rethink our patterns.

Some applications are just not suited for service-orientation. These are typically problem-solving applications. Just think of a SOA-version of eclipse... typical workflow applications on the otehr hand are predestined for service-orientation.

Applications with high user interaction are a typical indicator against service-orientation and for local business-logic close to the persistence.

Whenever possible deploy into one single VM. Separated VMs for Web- and EJB-Container make hardly ever sense (performance can even be worse, scalability is better achieved with load balancing at the front ...)

Thursday: Meeting Day

Since reading Adrenaline Junkies and Template Zombies I find me spotting for patterns of project behavior...

My hall of fame:

All roads lead to design.

The parade of left parentheses.

Lately I am spotting some traces of a Nanny.

Making money getting real ...

37signals shows us an elegant way to make money ...

... a nice fact to throw into the face of the next one who claims there is no money in Ruby on Rails.

About elitism

Interesting point of view about elitism:

Ask yourself: how has "elitism" become a bad word in American politics? There is simply no other walk of life in which extraordinary talent and rigorous training are denigrated. We want elite pilots to fly our planes, elite troops to undertake our most critical missions, elite athletes to represent us in competition and elite scientists to devote the most productive years of their lives to curing our diseases. And yet, when it comes time to vest people with even greater responsibilities, we consider it a virtue to shun any and all standards of excellence. When it comes to choosing the people whose thoughts and actions will decide the fates of millions, then we suddenly want someone just like us, someone fit to have a beer with, someone down-to-earth—in fact, almost anyone, provided that he or she doesn't seem too intelligent or well educated.

From this article about Sarah Palin.

Is this opinion valid in a broader sense? Some alpha geeks [Ayende, Jay Fields] have their own slice of elitism.

Pairing: keeping you focused

This is an interesting post about pair programming.

It kept me focused and on task. I had someone looking over my shoulder, so I couldn’t let my mind wander and wonder what the blogs were saying today, just because I reached a small breaking point. What is normally a disjointed coding process for me became a smooth, continuous experience.

This is totally my problem. Some pair-programming would probably do me good... else Google will end up making me stupid.

The guys at hashrocket go to the extreme:

"pair all the fucking time!"

Cosmetic makeover

I am updating the layout of my blog.

Two sidebars means even more possibilities to take part in the realityloop :-)

BTW: Bringing Blogger to a three-column layout closely resembles plastic surgery ...

Feedback for my ORM-workshop

The feedback for my ORM-workshop at the workshop-days of /ch/open is online. You can find it here.

The workshop was fully booked with 21 participants. Generally I think I can be content with the results. The only thing intriguing is that someone found that I did not address the questions of the participants...? Well, he seems to be pretty alone with this impression, but anyways ...

Anemic but progressing

Last week I was attending Adam Biens workshop 'Designing The Boundary - Rich UI Meets Efficient Java EE Backend' at the workshop-days of /ch/open.

The workshop was very insightful. I probably will write several posts about it.

Adam made one very interesting observation abut the debate of rich domain models vs. anemic domain models.

In order to start implementing a rich domain model, you have to understand the business.

When implementing an anemic domain model, you can start with the implementation without really understanding the business. You just have to know the structure of the domain. Then you can jump headfirst into work and implement all the CRUD logic. For a project that early gives the impression of progress. The real business logic can follow later ...

... except that this is often an excuse for not really concentrating on the business-problems but focusing on technical implementation details. Only later on it becomes clear that the project does not really deliver what the business really needs.

Defining the name of a sequence with JPA annotations

Last week I was giving another workshop about object-relational mapping at the workshop-days of /ch/open.

I got quite positive feedback from several participants and I am curious about the official ratings.

During the exercises there was the question how to define the name of a sequence when using the strategy GenerationType.SEQUENCE.
I did not know the answer then, but here it is:

@Entity
@SequenceGenerator(name="PROD_SEQ", sequenceName="product_seq")
public class Product {

    @Id
    @GeneratedValue(strategy = GenerationType.SEQUENCE, generator="PROD_SEQ")
    long id;
    String title;

    ...
}

Two, who needs more?

The Two Generals' Problem is reality, but the computer industry says, it doesn't believe in mathematics: Two phase commit always works! -- Joe Armstrong, Inventor of Erlang

And continuing:

... Microsoft is good at some things, but breaking mathematical theorems: don't do it!

Realitycheck: any bugs in your world?

There seem to be very different perceptions of reality in the software-development industry... I just stumbled across those two completely opposite statements:

From this discussion about asserts:

Professionally written production code is bug free, so there is no need for asserts.

From the brilliant Google Chrome comic:

 

So, which world are you living in?