While at the NFJS Software Symposium this weekend, I attended a talk given by David Hussman titled: Creating, Telling, and Tracking User Stories.  Not having any prior knowledge of this concept I was very intrigued by what he had to say.

Apparently, user stories are an XP method that facilitates and drives requirements gathering, release and iteration planning, and the creation of solid acceptance tests.  Basically, user stories are a compilation of a few sentences that are compiled by the actual users describing what they need the system to do in order for them to do their job effectively.  Having these user stories allows us to live a day in the life of that specific user.  This can open up some new doors when it comes to how we develop.  If we have a better idea of what the users actually need, then we will be ahead of the game.  Anyways, David made some very good points during his talk and I thought it was an interesting concept and worth looking into.

More cases than not, a project will have requirements that will not always be complete.  At times, clients seem to think that they can provide you with a set of requirements, come back in six to eight months, and get a quality system. Because of this, it is difficult to make your client understand that they are vital to the success of the project.  In my personal experience, the way to cross this bridge is through communication.  Here are some examples of practices you can put into effect on your project to increase client-contractor interaction:

The ADF framework boasts some pretty sweet built-in functionality when it comes to user driven events. However, the table selection functionality that is currently built-in has some potential for improvement. When a user selects a specific row, there are a number of potential scenarios that I may want to code for. For example, I may want to do a combination of the following:

• Refresh one or more tables based on the user's selection.
• Update the URL of a button’s action with one or more parameters from the selected row.
• Fill out additional input components on the page.
• Perform validation on the user’s selection. For example, if the user selects a row to either delete or edit. We can perform custom validation to see if that row meets specific criteria.
• Set a value into the session.

ADF/UIX simply does not have the built-in functionality to efficiently handle a combination of these events. With this in mind, I recommend creating a custom Java event with the combination of Oracle’s Partial Page Refreshing to handle the action of a user selecting a row in a UIX table. Let’s take a look at how to do this.

There has been a lot of talk lately about agencies wanting to move towards the development of enterprise applications under a Service Oriented Architecture (SOA). However, moving forward with this initiative poses a fairly large problem: How do we integrate all of our different applications under the umbrella of a large SOA? In order to do this, there needs to be some type of communications framework to provide your old and new components with the ability to interoperate as an enterprise system. This is where Mule comes into play.

Mule is a message passing framework based on the Enterprise Service Bus (ESB) architecture. It is based upon the concept of UMO’s (Universal Message Objects). UMO components are your business objects. You may think that the UMO appears to be a Mule-specific component; instead, they are simply POJO’s that sit between application that receive and process messages. In order for a UMO to process these messages, we must have a means of communication that will connect an application to a specific UMO component. In Mule, this communication is facilitated through message endpoints. Similar to your stubs and skeletons in CORBA, these endpoints contain all information necessary to interface technologies such as JMS, SOAP, Xmpp and many others.