Finally! I'm a Sun Certified Enterprise Architect for J2EE Technology

I got the final results today, and now I can say I'm a SCEA!
First I took the multiple choice test, then I submitted the assignment (a UML design for a J2EE system) and finally an essay about the assignment.
The fact that is based in the 1.2 spec of J2EE is not THAT important, as is only 20% of the total. I learned many things and validated some other things I already knew.
Later I'll post more details on the assignment.

At least somebody else says that I'm an software architect too!

Yes, design patterns are!

Lately they seems to be some kind of critique of design patterns (like singletonitis, even a discussion in comp.object). I agree that's some pattern abuse is occurring.

I just read Cedric's defense of design patterns

Mainly about this presentation from M. J. Dominus ”Design Patterns aren't” (http://perl.plover.com/yak/design/samples/slide001.html).

I believe that Dominus's presentation (or the title) misses the purpose of the GoF design patterns. They are object oriented design patterns and Alexander's patterns are architectural design patterns, (architectural in the sense of building, not software). They refer to a different design..

So, yes: design patterns, are!

What they are? Common solutions to OO design problems (not a library of C++ templates!).

New languages (or not so new) with greater flexibility make some of the GoF patterns unnecessary, because they're solved by the language itself and the problem doesn't appear.

Granted, lot of people will jump directly to apply the pattern without understanding what are the forces behind that particular pattern leading to apply the pattern in the wrong context. Maybe that's a downside of the popularity of the GoF patterns: people just apply the patterns without bothering to learn OOAD. A pattern should be the “missing piece of the jigsaw” that when put in place unifies all the forces harmoniously.

For me, one of the greatest value of the design patterns was to show the usefulness of the patter format to capture reusable knowledge: naming common solutions for recurring problems and the implications of that particular solution. As an example, (software) architectural patterns are an easy way to convey an architectural style by just mention the pattern name (e.g. layers, pipes and filters, blackboard, etc.)

Along the success of the GoF book, a whole pattern movement emerged for software and now we have architectural patterns, high level design patterns, low level design patterns, technology specific design patterns (like the J2EE patterns), analysis patterns, even business modeling patterns.

I somewhat agree that people went overboard with the patterns and need to stop overusing them and get past the 25 patterns of the book. (Every book now seems to need “patterns” in the title... and “agile” too... if I have to title a book I would name it “Agile Patterns of Refactoring Driven Design with UML”)

So, in spite of the criticism I really see value in patterns.

My restatement of "No silver bullet"

(this is my interpretation today)
The essence of software development is capture the domain information and translate it to a computer for execution.
("simple" enough, eh?)
"The most radical possible solution for constructing software is not to construct it at all" (Frederick P. Brooks)

Learning Ruby

I've been trying to learn Ruby since a long time but never seemed to have the time or the right tutorial. It looks a nice way to get into the dynamic languages way of thinking (and clean some of the java stuff in my brain), and a very fun language to program.
Yes, I toyed with the online ruby interpreter try ruby!, played with Ruby on Rails on my computer, and read some tutorials, but I didn't got enough momentum. I have a good idea of block, closures, mixins, everything-is-an-object, etc, but I want to see them in action ( and the whole idea of DSL in Ruby looks VERY promising).
Guess is harder when you don't need to use it daily, but having missed the opportunity to learn Smalltalk, I feel that Ruby will be a better choice now.
At least, my search led me to get back in touch with an old friend.
On the other hand, Java seems to be acting like a huge borg, assimilating and digesting everything that seems to be useful to program, probably with ugly results but I'll enjoy using them anyway.
But while waiting for the results of part II and III of SCEA, I felt ready to try again, and I found a wonderful guide:
"Why’s (Poignant) Guide to Ruby", I just read the first 2 chapters, and I loved it (is a lot to say, because I already knew the stuff covered!). For me, it felt somewhat similar to "Head First" series, but with a lot less caffeine :-), really like the style.
I'll tell you at the end if I finally learned Ruby, and what I'm going to do to not forget it, but meanwhile, I'm enjoying the read...