Half Object plus Protocol Design Pattern for Portlets

Switching from one portlet to another results in losing the state of the first portlet. Due to this behavior of portlets, it becomes difficult to use them for rich client applications. Author Marc Domenig suggests half-object + protocol pattern (can't they think any better name?) can be useful in such scenarios.

Rich-Client Portlets And Half-Object Protocol Design Pattern

We have never faced such kind of requirements in our projects so I am not sure in what situation it can be useful. But It will be good to see similar support directly in portal servers.

What do you think? Have you faced similar problems in your projects?

Note: For those who are new to "Half Object plus Protocol (HOPP)" design pattern can have an introduction to it at http://jan.netcomp.monash.edu.au/distjava/hopp/lecture.html.

In these interviews, Erich Gamma, the famous Gang of Four (GoF) member and co-author of the landmark book, Design Patterns, talks about various design principles -

• In Part I: How to Use Design Patterns, Gamma describes gives his opinion on the appropriate ways to think about and use design patterns, and describes the difference between patterns libraries, such as GoF, and an Alexandrian pattern language.
• In Part II: Erich Gamma on Flexibility and Reuse, Gamma discusses the importance of reusability, the risks of speculating, and the problem of frameworkitis.
• In Part III: Design Priciples from Design Patterns, Gamma discusses two design principles highlighted in the GoF book: program to an interface, not an implementation, and favor object composition over class inheritance.

Hope you will find them useful.

Agile Training

Building human resources is one of the biggest challenges being faced by IT companies today. Irrespective of the location, IT companies are finding serious scarcity of human resources. Most of the times, after several attempts to hire the right skill-set, companies conclude that it is easier and cheap to build than buy.

Building resources has not proved cakewalk for the companies. The traditional methodologies are failing and we are feeling a need of some new training methodology. In fact, I didn't like the traditional idea of training at all. I often utter that 'Training cannot train people'. If you will take the statistics of IT training success, you will know the truth. In fact, I don't like the word "Training" at all. The word training shows some force and opposite of the human psychology. Whenever we try to train someone, it is bound to fail. The method of teaching should not be the force oriented but involvement oriented. Due to the lack of the expressive power in the word training, I will try to use the term KBP (Knowledge Building Process) in rest of the document. I am an old agile programmer. Though not a trainer, I have good IT industry experience and experimented with different training methodologies. We can call my new methodology, agile methodology. Here is a quick note on agile training -

1. Pair training
It is similar to pair programming of XP. One junior resource should be coupled with one senior resource. It is similar to one mentor-one mentee approach used by many companies.

2. It must be project centric
We should not confuse project with training assignments. Dummy projects means dummy learning all the time. To teach real one will have to work on real project.

3. It must be QA intensive
How you will ensure the quality of codes by some junior resource. Here QA comes into the picture. The mentor of the mentee must QA all the codes, s/he does for the project. Mentor should point-out the mistakes and technique flaws pretty early in the learning cycle.

4. Discussion Oriented
In an IT organization knowledge is everywhere and with everyone. Merely mentor-mentee approach cannot guarantee a learning environment. It is the major drawback with the mentor-mentee approach. To make it usable, it should be tied with Agile methodology. For example, ask all the team members, junior or senior, to participate in the daily meeting (scrum). The daily meeting the one of the best place for discussion based learning.

5. Imbue agile methodology from beginning.
Agile methodology is now already proven methodology and requires no argument in its support. As with any other kind of teaching, I have seen the best time to teach agile methodology is in the beginning of one's learning stage. Company can choose any methodology say XP, FDD or Scrum best fitting to the company. The concepts like TDD and metaphor can be best taught in early stage of learning.

6. Well define training objective.
OK, this is not that much agile but important. The objective of training must be very clear to mentor and mentee.

7. Close monitoring.
Again it is extended part of point one and three. The mentee should be monitored very closely and supported to bring him/her quickly to the project pace which is the final objective of the training.

8. No evaluation approach.
In my opinion, the evaluation is always inaccurate and disheartening. Different people do have different strengths of weaknesses. You cannot compare William Shakespeare with Venus Williams. In fact, the company should value resources than evaluate them.

9. Extension of Mentoring Chain
When the mentee has learnt and advanced reasonable, s/he should be allotted a junior with him. This will enhance the learning rate and responsibility gets distributed across the organization.

Note: I am involved closely with the Yash Technologies for the last two years in resource building process for enterprise portals and other latest technologies. This initiative has played very important role in above methodology.

References:
1. Agile Methodologies
2. Mentoring Methodology

Head First Design Patterns

Due to persuasion and positive review of the book "Head First Design Patterns" on javalobby, I decided to give a shot to the book. I downloaded the chapter three of the book and start reading it and after going through the book, I got convinced by the reviewer that this is going to be the java best seller. Here is how reviewer utters it -

I have to say this is one of the best books on Java programming I have ever read, and that I am a much better programmer now than I was before I read it. Most Java books focus on Java syntax, and on Java's support for object oriented programming. However, they fall very short when it comes to actually teaching how to apply object oriented programming. Many computer science courses also fall short when it comes to teaching how to actually apply object oriented programming, hence we end up with programmers who over-use inheritance and thus write code that is very difficult to maintain. That is where Head First Design Patterns come to the rescue.

So what are my comments? :-) The same as the reviewer. The book is excellent book on design patterns. Go and download the free chapter and let me know your opinion.

Java Design Patterns

 

One of my fellow blogger  pointed me towards these articles on Java Design Patterns. Good to have a look on these basic GoF design patterns implementation on Java. Here is the link - Java Design Patterns.

OK, Now after studying many different processes and methodologies, I stopped bothering too much about them. I found the best process for software development and no prize for guessing; it is nothing but - "Common Sense." Whatever methodology you follow, keep in mind that common sense is the most important aspect of Enterprise Software Architecture. If you will try to be too much artifact oriented, you can risk your project. Same is true if you will try to be too less process oriented i.e. too much agile; it is again risky. You will have to find a mix of agile and artifact oriented approaches.

Even then just to keep myself updated, I was finding few more things to confuse myself and in one paper on the topic - "Architecting Enterprise Software", I found them. Here are few things that paper was talking about -

1. Zachman Framework ?
2. POSA (Pattern-Oriented Software Architecture)
3. RM - ODP (Reference Model - Open Distributed Processing)
4. Rational's 4+1 View Model

I was not aware of Zachman Framework and RM-ODP and found these topics non-sense in my first reading. But so what, all software architectural approaches looks that way :-). I'll try to write more about them in future.

Also, while surfing, I also come to know about another good resource point for RUP and UML. Here is the link -

http://www.rspa.com/reflib/UMLRelatedMaterials.html

Bye for now.

AspectWerkz and AspectJ comparison

There are two aspect animals in Java AOP world. One is AspectJ and other one is AspectWerkz. Both have implemented AOP for Java but using altogether different methodologies. I am in touch with AspectJ for quite a while now but haven't checked AspectWerkz at all. I found very good introduction of AspectWerkz in the from of comparison on Val's blog. Here is AspectWerkz and AspectJ comparison.

UML 2.0 Join & Merge FAQ

Can someone explain the difference between an implicit merge and an implicit join, and how this makes it harder to use UML 2.0 activity diagrams for modeling the control flow?

Think of a join as AND, where all incoming transitions have to fire, and a merge as an OR, when any one of them can fire, for progress to be made. The concern over the change of behavior can be alleviated by not relying on implicit assumptions. Always be explicit: when you want to join, use the join node (the thick bar) and when you want to merge, use the merge node (the diamond). This way everyone (who can real UML Activity Diagrams) will know what you mean.

MDA: Risks and Benefits

The Server Side has published one article titled "MDA: Nice Idea, Shame About the…" describing MDA & risks and benefits associated with it. I found that the author, Mr. Dan Haywood, has done a great work by going in-depth of MDA.

You can check the article here.

If you want to make god really laugh, show him your framework design.

Yesterday I was reading the book "If you want to make god really laugh, show him your business plan" by Barry J. Gibbsons, former CEO or Berger King. But I think, I have a better way to make god really laugh. :-)

GoF Design Pattern Resources

Found the reference of this website at pattern central. You will find some interesting discussion on all GoF Design Patterns.

I am planning to post some important and interesting terminology related to the subject of this blog. You would have seen few of them already. Here is another one -

software entropy

The tendency for software, over time, to become difficult and costly to maintain. A software system that undergoes continuous change, such as having new functionality added to its original design, will eventually become more complex and can become disorganized as it grows, losing its original design structure. In theory, it may be better to redesign the software in order to support the changes rather than building on the existing program, but redesigning the software is more work because redesigning the existing software will introduce new bugs and problems.

source -> webopedia

UML and OOAD Resources

It is an extremely good resource on UML, Design Patterns, Methodologies and related stuff. You will also find some PDFs on UML. Please check it here.

Design Patterns: The AOP way

Like lots of others AOP enthusiast computerist (aka developers, architects, leaders etc.), I am also still looking for some good examples on Aspect Oriented Programming (AOP). Last time a have written a little about AOP but frankly speaking I am still not very sure about the usability of AOP especially in business applications. We talk a lot about exception handling and logging but these covers only a small portion of actual software.

In portal world, eXo and Jetspeed are using AspectJ in their code but I have still to check where exactly are they using AspectJ and for what purpose.

I got this paper from OOPSLA. Here the author of this paper has tried to re-implement famous GoF Design Patterns with the help of AspectJ, the AOP tool in Java. You can get the PDF here.

Important Terminology for Architects and Designers

Today is Sunday. I didn't read, write or thought too much. So just for your (and of course mine) timepass I am giving some useful vocabulary for architects.

Surface Area
Surface Area is a term used to describe the way in which components interact withy one another in a defined way. It’s important to note that the greater the surface area, the more ways a change in one component can affect another.

Boundaries
Boundaries are the areas where two components interact.

Brittleness
Brittleness is the degree to which small changes will impact large portion of the system. Software tends to be unwieldy for many reasons, but a primary reason is brittleness. The distance between the ideal computers architects imagine and the real-world computer systems we know and work on is unfortunate and due in large part to brittleness.

Capabilities, Friction, and Layering
Capabilities are the non-functional, observable systems qualities including scalability, manageability, performance, availability, reliability, and security, which are defined in terms of context.

Friction refers to how much interaction occurs between to components. Friction is measured based on how a change in one component affects both components.

Layering is a hierarchy of separation.

Object Oritented Estimation

Managing estimation and keeping with deadlines is always a art than a science. But it doesn't mean we can not utilize the science at all for project management. Robert Martin suggests us two charts that can be very useful hanging on wall -
"Velocity Chart" - illustrating, week by week, how much work is actually getting done?
"Story Points Chart" - week by week, how much work remains to be done in the project.

He also suggests - fitnesse.org, an acceptence testing framework.

In OOP we have standard UCP formula found in the book Applying Use Cases.

For those who doesn't have any idea here is the illustration - The UCP formula assigns each use case a complexity level of simple, medium or complex, based on either the number of scenarios in the uc or the number of analysis classes used to realize the use case (once that info is available). Each UC rank has a number of points associated with it. Actors are also ranked. For project estimation purposes, these points are added up and have a few other factors applied to them to convert them to man hours.

Sample "Velocity Chart"

Sample "Story Point Chart"

You can dig the details at -
http://www.sdmagazine.com/documents/s=8958/sdm0312f/sdm0312f.html

Suggested Reading for Design Patterns (Beginners)

On the newsgroup few suggested following links, which I also found useful.

Object Design Tips 1

Object Design Tips 2

ObjectMentor.Com

You can also check the discussion thread on google groups. I guess, the link should work.

Patrick Rahmoune suggested this new coming book - "Design Patterns Explained: A New Perspective on Object-Oriented Design" by Alan

My Tips For Understanding Design Patterns

Recently I saw a post on object newsgroup asking same good old question i.e. how to understand patterns. Here are my short and concise tips –

1. Read "Applying UML and Patterns" by Craig Larman once. Just take an overview.

2. Keep reading "Design Patterns: Element of Reusable Software Design" by GoF till you understand it. I think it will take around one month. Keep reading it like a novel, even if you are not able to understand.

I am sure, more the stuff and more you will be confused. So try to stick with these two.

Punit Pandey

Finally RSS Feed

I have created one more blog which will contain all my articles which I post here. What more, you can get RSS feed too. The link is Software Methodologies

CRC Cards for Methods?

Yesterday, I was thinking that there is a way namely CRC Cards to visualize Classes and their responsibilities. But is there any way to visualize methods, their functionality and responsibility. I got following solutions from comp.object newsgroup.

* TDD (Test Driven Development)
* Writing down post condition, pre condition, parameters, return values
* CRC itself
* Flow charts, Nassi-Schneiderman charts, State Transition Diagrams and Decision Tables
* Sequence Diagram
* Object ineraction/sequence diagrams, message diagrams, state diagrams and lastly if you *must* (as even the UML authors suggest) activity diagrams.
* Use Case Scenerio extended in structure chart
* Skill Driven Notation

I'll try to write about this and provide some link in future. Menawhile you can go throuhg the thread at google groups here.

Punit Pandey