JSF code snippet: integrating JSF pages into a plain old JSP

A simple way to include a JSF page into a bigger JSP (sure there's other ways, but this one is easy):
the JSF page must be a subview:

<%@ taglib uri="http://java.sun.com/jsf/html" prefix="h"%>
<%@ taglib uri="http://java.sun.com/jsf/core" prefix="f"%>
<f:subview id="myJSFSubview">
.....
</f:subview>

The tricky part is how to include it in the JSP, in a way that is independent of the main JSP. But you just need to include like this:

<% pageContext.include("myJSFpage.jsf"); %>

Project (and people) over Process

Thinking in my previous post with the RUP sample documents (or artifacts), I don't want to perpetuate the myth of RUP being a document-driven heavyweight process. Using templates involves a trade-off: you have a common format for the documents and guides you to the questions you need to ask (who? why?). On the other hand, the template comes in a "one-size-fits-all" format, and you need to adapt the template contents to your project (but to be fair, RUP includes a small project vision template).
The process of discovering what should be in a document is as important (if not more) as the document itself, you’ll find what should be in the document and what shouldn’t be while gaining insight in the problem. Specially true for analysis and/or design artifacts
The goal for every artifact is communication, unless you reached the point when it can be automatically translated into an executable form. And remember:

• You DON'T need to fill every template that a process provides.
• You DON'T need to follow blindly every activity that a process describes.
• You NEED to adapt the process to your project.
• You NEED to follow the process that makes sense for your project in the context of your organization.

(Yes, if you have a process group, you’ll need to convince them…. And yes, that includes not always doing test first, not always pair program, etc…)

RUP sample documents: Inception

Here are sample RUP documents I created for a training I gave:

The requirements set:

BOSBusinessCase.pdf

BOSVision.pdf

BOSGlossary.pdf

BOSUCOrderBizcochos.pdf

BOSUCRetrieveConsolidatedOrder.pdf

The management set:

BOSSoftwareDevelopmentPlan.pdf

BOSRiskList.pdf

The most important ones are the vision document and the use cases. One thing I really like about the vision document is the problem statement, defining clearly the problem to be solved by the system.

One important thing I see missing in many “processes” is an explicit focus on finding what the user needs (can be very different of what the user wants), clearly stating the problem to be solved helps a lot in that direction.

Also you need to have some alternatives identified. How many projects are started without a clear problem to solve? Sometimes they're successful, but you must be VERY lucky to pull this off.

Also the alternatives are important: developing good software is very difficult: sometimes, something like excel is good enough!

Basically, it boils down to clearly defining the problem and have the alternatives in mind instead of jumping blindly into a development project.

BTW, the problem statement is not exclusive of RUP, they're just requirements management good practices. Even is included in the IEEE 830 SRS standard.

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...