12/3/07

Quote of the month

"Object-oriented programming is like money, as the old joke has it: It's not everything, but it's way ahead of whatever's in second place."
Objects have not failed - Guy L. Steele Jr.

11/18/07

Javascript, the underdog

I'm back working on some JavaScript, just like the old times, adding client-side UI dynamics. In spite of still being hard to work and debug (at least in IE), it allows me to play with a different language. I realized the worst thing you can do with JavaScript is use it like Java, it works but you'll miss the interesting features like prototyping and higher order functions.
This week I found that Mozilla JavaScript implements useful iteration methods were you can pass functions to operate on the collection:
filter, forEach, every, map, and some:

filter
Selects the elements of the collection that satisfy the function

forEach
Applies a function to all the elements of the array

every
Returns true if every element of the array satisfies the function

some
Returns true if at least one element satisfies the function

map
Creates a new array with the results of calling a provided function on every element in this array.

As an example, you can easily write:

funtion doSomethig(element){ /*whatever*/}

and then:

aCollection.forEach(doSomething)

Suddenly, JavaScript coolness factor has increased for me :-)

Those functions are standard in Mozilla JavaScript, but they provide the source code, and is small enough to include it if you're using another browser. And as the objects are “open” and you create new ones by prototyping, you just need to add the code to the object you want (as long as is “array” like) it will work.

11/9/07

OOPSLA keynotes podcasts

Very interesting software engineering pioneers's podcasts from the OOPSLA 2007 conference:
David Parnas
John McCarthy
Frederick Brooks

I couldn't recommend them more!

9/19/07

IT Architect skills library


I’ve been in IASA’s IT Architects Regional Conference (ITARC) in Atlanta. Great event, with very interesting events with the topics which the architects want. Some of the presentations were very good, others not that good, but I got many good ideas from all of them. I’ll post on the topics later.
Meanwhile, I want to share IASA’s project of creating an IT Architect skills library: http://www.iasahome.org/web/home/skillset. Is an ongoing project, but is worthwhile to take a look at it.

8/24/07

Quote of the month

"Any fool can write code that a computer can understand. Good programmers write code that humans can understand."
Martin Fowler, "Refactoring: Improving the Design of Existing Code"

8/21/07

Language "wars"


I'ts me or we are at "war" again?
As the old history goes, in the nineties, OO Warlocks fought each other from their towers, everyone claiming to have The Methodology, until some of they settled for the "Unified Philosopher Stone" or something like that... (I always thought it was strange that the outcome of a methodology war as a notation, but I digress)
After that, came the agile jihad, trying to burn the non-believers in the stake, all in the name of the eXtremellyPurity religion, causing great havoc in the process world (and every process guru claimed "I'm agile too!", probably to satisfy the angry mob... but agile waterfall got burned anyway). Is funny now how many experts now say "XP is very good, but if you do < insert your favorite common sense practice >, is even better!"

And now, the languages!
Well, is not really a war, I guess is more like in the OO-java-roman.net empire, encounters with the Rubyites or the functional programming tribes and similars(the Haskells, Lisperers, or Schemitas) are getting more common... their hordes always roamed in far away places, but they are getting closer and closer. Even the habitants of island of JavasCriptya turned out to be part of the FP tribes! Granted, the Enterprisey temples, aqueducts, and coliseums will not easily fall or be overrun by them, but I guess some interesting things will happen. Maybe with an unifying Domain Driven lingua franca we can get the best of each other, because frankly, Java (the kingdom of thousands frameworks) is hard
I forgot to mention the mythical lands of Translathia, where their habitants write using symbols instead of words, and through their magic, they materialize what they just described... they have all their stuff decorated with their hieroglyphs. Mythical as it sounds, I happen to know two respected sages from that land...


Now, seriously... I'm seeing a lot of noise/cool-stuff from the FP camp, probably thanks to the concepts introduced by Ruby, and I think it would be good to learn a new paradigm.

8/14/07

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"); %>

8/10/07

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…)

8/6/07

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.

7/25/07

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!

7/10/07

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.

7/6/07

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)

7/2/07

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

6/22/07

JSF code snippet: Page scope with Tomahawk save state component

JSF code snippet: Page scope with Tomahawk save state component
By default, JSF backing beans can be only in session or request scope. Having a "page" scope is very useful, so the state is maintained between requests, but is discared when you abandon the page (and not kept in the session). You can easily achieve this by using the UI save state component from MyFaces Tomahawk project.
The bean saved by saveState must be serializable (if you have a dataModel don't forget to declare it transient) and declared of request scope in faces-config.xml

In the jsp
< t:saveState id="saveState" value="#{BackingBean}" />

In web.xml
< context-param>
< param-name> javax.faces.STATE_SAVING_METHOD < /param-name>
< param-value>client < /param-value>
< /context-param>

< filter>
< filter-name>extensionsFilter < /filter-name>
< filter-class> org.apache.myfaces.component.html.util.ExtensionsFilter < /filter-class>
< /filter>


In faces-config.xml
< navigation-rule>
< from-view-id>/myScreen.jsp < /from-view-id>
< navigation-case>
< from-outcome>cancel < /from-outcome>
< to-view-id>/myScreen.jsp < /to-view-id>
< /navigation-case>
< /navigation-rule>
< managed-bean>
< managed-bean-name>BackingBean < /managed-bean-name>
< managed-bean-class>myPackage.BackingBean < /managed-bean-class>
< managed-bean-scope>request < /managed-bean-scope>
< /managed-bean>

The navigation rule to the same screen on cancel has the nice effect of clearing the saved values. That makes implementing a "Clear" button just that easy.

6/21/07

JSF code snippet: No data found message for a table

A short one: display a message when there's no results to display in the dataTable

< h:dataTable value="#{BackingBean.tableModel}"
... rest of the dataTable configuration
>
..... dataTable columns ...
< /h:dataTable>

< h:panelGrid width="100%" rendered="#{BackingBean.tableModel.rowCount == 0}">
< value="#{msgs.noResults}">
< /h:panelGrid>



The datatable will render only the column titles, and then the panel grid with the message will be rendered

UPDATE: I just noticed that while posting, the JSF tags got completely messed up, should be fixed now

6/19/07

JSF code snippet: parent-child lists

(I'm extracting a collection of JSF code snippets from my projects to keep them in a easily accessible place)
Here is an example of parent-child drop downs with multiple child selection, and the list of childs is not rendered until a parent is selected...

In the JSF page:

code:

...
< h:selectOneMenu id="parent" immediate="true"
value="#{BackingBean.selectedParent}"
valueChangeListener="#{BackingBean.changeParent}"
onchange="submit()" />
< f:selectItems value="#{BackingBean.parentsList}" >
< /h:selectManyListbox>

...
< h:selectManyListbox id="childs"
value="#{BackingBean.selectedChilds}"
rendered="#{BackingBean.parentId !=-1 }"
size="4" >
< f:selectItems value="#{BackingBean.childsList}" />
< /h:selectManyListbox>

...

In the backing bean:

code:


...
public void changeParent(ValueChangeEvent event)
{
Long parentId = (Long) event.getNewValue();
selectedChilds=new Long[0];
childList = getChildList(parentId);
}

...

6/8/07

My recipe for OOAD with UML


How do you go from requirements to coding?
Everybody has different alternatives. Working on my SCEA assignment, I'm using OOAD with UML.
I choose to have an intermediate point: I'm not formally doing the OOA first (only in my head) and the OOD doesn't have much detail.
Ingredients:
  • Enough Use cases
  • A Busines domain model (small)
  • Some Aditional requirements
  • Pen and paper (could be relpaced with a whiteboard)
  • A working brain (hard to find, I usually manage without it ;-) )
  • Plenty of coffee
  • A beer

Read the use cases and requirements, stir that in your head for a while Get a piece of paper and draw the "map of the world" (existing components, outside systems, etc) to give your brain something to think about.
Create a very basic class diagram based on the domain model
Select one of most the complex use case and create a sequence diagram for it:
  • Put the actors involved
  • Choose the interface/style required to interact with them (web, Thick client, Messaging, etc.)
  • Use the identified objects from the class diagram to fulfill the requirements from the use case
  • Each object will have their responsibilities in the use case context.
  • You will need to add more objects and/or split existing ones to better distribute those responsibilities
  • Drink a cup of coffee
  • Write your assumptions
Once you fulfilled the requirements of the use case, let the sequence diagram cool for a while.
Dump all the classes you identified in the class diagram and mix them with the existing ones.
Think how you can better organize it (if smells like refactoring, you’re good, but don’t expect any “code smell” we’re far from the code). Once you’re satisfied with the result, go back to the sequence diagram and adjust it so it conforms to the new class structure. If your class diagram grows too big (maybe # of classes >7+-2) organize it in layers: put one layer of services classes, one layer of domain classes, one layer of application classes, etc.
Once the class diagram is ready, group those classes in components of the component diagram (you can add lollipop notation for the interfaces, is a nice touch)
Rinse and repeat for the other use cases.
When you’re done, you can serve the components inside deployment units in a big deployment diagram.
Now you can take a break and drink the beer!

DISCLAIMER: as with most recipes, the real process is completely different

5/28/07

Yourdon's top ten software engineering ideas

While I'm busy working in SCEA part 2, I wanted to share this ideas from Yourdon.
He has a mindmap presentation about the top ten software engineering ideas (you can download the pdf here).
What he talks about?
1 - You can't control what you can't measure
2 - Peopleware
3 - Incrementalism
4 - Iteration
5 - Repair costs increase
6 - Tradeoffs are non-linear
7 - Reuse is important
8 - Risk management provides insights
8 - Consistency trumps brillance + death march
10 - Don't reinvent the wheel

Lots to comment on each one (he shows Brooks's "The Mythical Man-Month" and DeMarco's "Peopleware", I must agree!).

5/15/07

Waterfall, RUP, XP... and one process to bring them all, and in the darkness bind them

What happens if you have a big project to execute and your organization mandates Waterfall? Of course, you can try to follow the mandated process, and hope everything goes fine (bad news: chances are not).

As a rule, you must ALWAYS adopt/adapt the process to fit your project (and not the other way around)

A big project will be less risky using RUP, but if you can't convince the outside groups (typically management, QA, overzealous SPEG/SPI group, maybe the customers too) to use it, you can use RUP and make it look like a waterfall from the outside (but ONLY form the outside). BTW you should try to convince those groups that waterfall only looks good on paper and modern processes can yield better results, but it takes time, and probably you need to start right now with the project. How do you map RUP and Waterfall? Don't do the classic mistake of Inception=Requirements, Elaboration=Design, Construction=Coding & Unite testing, etc... you will be in trouble when at the end of Inception, the outside groups will ask for the complete requirements for review!

The trick here is map the end of Elaboration to the end Requirements phase, so you can collect all the requirements but also implement the critical ones. You can map the end of the Design phase to somewhere in the middle of Construction (or at the end if you can get away with it). When you're done with Construction, you can release your code to the outside QA team to do whatever they want. Probably is a good idea to have customer involvement early so he can try the system and provide valuable feedback (that's the whole idea!).

You will end with an oddly shaped (in time/effort) “Waterfall-looking” schedule but still all the advantages of an architecture centric iterative incremental methodology like RUP. And if you can't live without doing XP and will complain if you can't do it, you can safely do XP inside each RUP iteration...

BTW, by no means TRANSITION=TESTING!!!!

5/14/07

What's your project score?

The Standish group's CHAOS report has a table of success factors:
Success Criteria Points
1. User Involvement 19
2. Executive Management Support 16
3. Clear Statement of Requirements 15
4. Proper Planning 11
5. Realistic Expectations 10
6. Smaller Project Milestones 9
7. Competent Staff 8
8. Ownership 6
9. Clear Vision & Objectives 3
10. Hard-Working, Focused Staff 3
TOTAL 100

The study is not new, but still is valid. This are the critical factors for a project success.
Mapping it to your current project, will let you focus on the areas that will improve your chances...
What is your current project score?

5/13/07

Software Engineering Radio


I really like this site. Software engineering podcasts in english from a german team of experienced software developers and architects. I really enjoy (almost) all of the episodes, some refreshed concepts (like architecture) and others gave me an idea of new topics (I'm fascinated with MDSD/DSL stuff, but still I couldn't try it). Some of the topics covered are Architecture, Patterns, Model Driven Software development, Agile process, SOA, Dynamic languages, etc (and very good interviews too).

The podcasts are intended as a reference resource, not technology specific or a news podcast.

My only complaint is that I have my MP3 player totally full because of their podcasts (guess I should get a bigger one) :-D

Bottom line: totally recommended, don't miss it... go now!

5/11/07

Sun Certified Enterprise Architect part 1 completed!


Good news! I just passed the first part of SCEA with a score of 89%.
Now comes the assignment part, it should be less stressful as there is no time limit and involves arhitecting a solution for a small system and document it in UML diagrams (that’s what I’m supposed to do for a living! :-) )
I must say it didn’t feel very difficult. First I bought Mark Cade’s “Sun Certified Enterprise Architect for J2EE Technology Study Guide” is a little bit short, but is a great overview of the topics and expectations of the exam. Is a truly study guide. I got good notes also from scea yahoogroups list. The mailing list is almost useless, but the files section has good resources.
www.moelholm.com has the best (free) exam simulator, if you pass the mock tests, surely you’ll pass the exam. www.leocrawford.org.uk has a very good review of the important stuff . I read it the day before the test. If you want more links, comments, details, let me know, I'll be happy to share them...
Now, I want to start the part 2 ASAP :-)

(UPDATE 05/14/2007: More links)
Java certification success, Part 4: SCEA
Good (although the stateful session bean lifecycle diagram is incorrect), can be a study guide similar to Cade's book but even shorter. You need to register to download it
Pete Morgan's Sun Certified Enterprise Architect Part 1 Notes
Nice notes, once you learned the topics, this will help you to keep them on your mind
CertMag on the Web Programming Success: The SCEA Certification
A guide to the certification and useful links, some of them old though

And of course, there's plenty of discussion in Javaranch's saloon, like this notes.

(UPDATE 05/17/2007: More links)
I found also this collection of links at Ideartis

4/30/07

Caffeinated soap (or Caffeine can kill your creativity!)

This has nothing to do with software development, but seems to cool to left it uncommented: Caffeinated soap!
Feeling too sleepy in the morning and need an extra kick?
In a hurry and without time to shower AND have your morning coffee?
This looks more practical than getting in the shower with your favorite coffee mug:
you will absorb the caffeine through your skin while showering!
(ok, maybe it has something to do with software, it comes from ThinkGeek, and most of the it workers I know are totally hooked up on coffee… myself included)
But use it with caution, as caffeine hurts your creativity!
Yes, my friends, that wonderful black beverage, your companion of many lines of code, is not your best friend when you need to innovate… looks like creativity is associated with alpha brain waves, but the alertness state provided by coffee is associated with beta brain waves (focus, high attention), so when you need to create a solution, leave the coffee aside (or drink the bare minimum to keep you awake)
BTW music seems to have a similar “creativity killing effect”, but that is because listening to music occupies your right brain (the one you need to be creative!). Maybe is all pseudo-science, but if you’re drinking coffee while listening to music, don’t expect to have your “eureka” moment… consider yourself warned!

4/27/07

RUP and risk management

I must admit that I like the Unified Process. The more non-trivial the project is, the more I think is applicable.
Typically, RUP is presented as a use-case driven, architecture first, iterative-incremental process divided in four phases: inception, elaboration, construction, and transition.
Somehow, using a manufacturing metaphor (I know, I know... usually are the worst ones, and can't go too far), the project can be divided into 2 major stages: "engineering" (inception and elaboration) and "production" (construction and transition).
The good thing is "engineering" aims to reduce significantly the risk level of the project. The biggest uncertainties at the beginning of a project are usually related to requirements (and scope) or technical ones, and they have a big impact because they’re the major sources of cost and time overruns. The traditional approach like the “waterfall” process is to pinpoint all the requirements and then complete the design to the detail (what the “agilists” call “Big Requirements Up Front” and “Big Design Up Front”). I will not beat the “Waterfall” straw man, it has its niche (albeit a lot smaller than most people think). Other option is ignore them and hope that the team is “agile” enough to respond to the risks when they materialize.
In the case of RUP, there’s an explicit intention to “defuse” those risks, by exposing and validating the assumptions as soon as possible:
  • the inception phase main goal is to discover what it should be done (usually identifying most of the use cases, and detailing the most critical ones)
  • the elaboration phase main goal is to define how it should be done, by defining the architecture of the system (based on the critical use cases)
After those phases are completed, you will have the architecture of the system, feedback from the most critical use cases, a clear view of the scope, and no technical surprises awaiting. At this point you should be able to have an accurate estimation of the total project effort, and the total risk exposure of the project should be significantly lower...

Lego blocks and Software development


When I was a kid I spent hours playing with Lego. Back then, they were expensive and hard to get :-). I slowly grew my collection by a couple of small sets a year. Usually I assembled the original model only the first time, then I put all the pieces in a pool and I assembled many different things.
Now in a different place (and many years after), I bought one and started to play around. Then it struck me: is no surprise that I enjoyed building things with lego and now I enjoy building software. Usually I started with some idea in my mind of what I wanted to build (a plane, a spaceship, a robot) and then scrubbed the heap of parts looking for the right ones, and slowly assembly them together into bigger ones (always spending a significant amount of time looking for the right piece) until I created something that wasn't what I envisioned originally, but at least could pass for it :-D.
Don't you think the process is very similar to write a program nowadays?
You start with something in your mind, and start putting together small pieces (lines of code), search for the right part (in the APIs), group them together (in methods, classes and packages) following your mind, until you get something working that is not what you wanted at the beging but it serves it purpose!
(well, I guess most of the creative activities share common things, but I think is an interesting metaphor... )

Microsoft Certified Architect


I just came from the IASA Atlanta chapter meeting where the Microsoft Certified Architect (MCA) program was presented. Very interesting. The basic idea is having an architecture peer certification that doesn't get diluted. The process involves a presentation of a previous project and then go through hard questions by a panel of 4 fellow MCAs. They're going to look for evidence you have the skills to be an architect, and they want to know what decisions you made in the project and why. As I understood, is not only for Microsoft based technologies.
Seems very though, they're aiming professionals with at least 10 years of experience...
At least looks like it would be more meaningful than the Sun Certified Enterprise Architect (SCEA) in the sense that for an MCA you must be an architect already, and for the SCEA not (you will be architect after the exam).

4/25/07

JavaServer Faces in the real wolrd


I wrote a paper presenting the JSF framework: JavaServer Faces in the real world. I used JSF last year to build custom functionality integrated into a workflow portal. I'm pretty satisfied with the result. I know JSF has been criticized an some of the points are valid, but I think is better than Struts and far better than JSP/Servlets alone. The ability to integrate components from different libraries (like the Tomahawk components) makes development very easy. Also AJAX integration is very promising (although is not as straightforward as it should be).
Read the paper and tell me what you think...

4/24/07

Books


I just added a list of the books I own that I consider important. Of the list, I consider "The Mythical Man-Month" and "Peopleware" two fundamental books that everybody involved in software development. Reading "The Mythical Man-Month" is almost sad when you discover how little our industry has learned. Ok, some organizations learned, but I know a lot that don't. And those looks like the dinosaurs struggling in the tar pit of software development. "Peopleware" is a great complement of the other book, very good ideas and the focus on the most important component of software development, the people! I think somehow Tom DeMarco provides the elusive "silver bullet" formula: smart and motivated teams will succeed in software development. Sometimes, "Peopleware" looks a little unrealistic and unsound, but I believe is part of the idea of the book, it should inspire to look beyond, to the people who creates software.
I must say I had the opportunity to at least try to apply the basic ideas of team gelling and the results where great. (I really enjoyed leading the "13 Guerreros"...).

“Protected” considered harmful (ok, not harmful… useless)


Currently I’m refactoring an old java code (ancient… almost prehistoric I must say). It was obvious that when they wrote it, java wasn’t mature enough and the techniques applied neither. As an example, it had a deep inheritance hierarchy (a classic OO beginner mistake… been there, done that ). I don’t want to bash the current code (or submit it to the daily WTF), because when I look at old code, I usually think: “hmm… that should be better if we did it this way…” (well, who doesn’t think his way is THE way ?), and now I have the opportunity to really do it, so I’m enjoying it.
The code also had a lot of protected methods intended to be invoked by subclasses. I remembered when I started learning OO (10 years ago? Darn, I feel a little old now…) that we should avoid protected.
Protected is like public but for some classes…
For fields, if you adhere to the philosophy that no field should be public, I think protected should be avoided for the same reasons that public should be avoided for fields (I should blog about it later). For methods, is a little more tricky, but if you think that the method could be used the object, why not make it public? If not, should be private. A special case maybe is when you want to provide special access to methods to modify the private structure but only in the context of a subclass.
After discussing it in comp.object, I came to the conclusion that with protected one can do nice implementation tricks, but it should be avoided because it asks for maintenance problems.
The only place I could think where protected doesn’t looks bad is for providing the callback points for a template method.
Well, maybe I have it all wrong, what do you think? :-D

3/3/07

First post!


Welcome to my blog.
I'll try to post here what I'm discovering about software development.
I promise to talk about Java, JSF, RUP, OOAD, UML, and a lot of acronyms more that nobody remembers what they mean. :-)