Monthly Archives: August 2010

How to handle metadata for UI screens representation

Case: There are multiple graphs to be displayed, depending on a few parameters selected by user graph type, its details and other UI related stuff vary a lot, what remains common is data.
Solution 1:
Create a UI screen for each type of representation, depending on parameter supplied by the user use a particular screen will be loaded
Pros: Very simple, Client is Dubm, each screen has a datasource which gets populated by data send by the server
Cons: Lot of duplication
Solution 2:
Keep metadata, say in XML or DB, about user selection and related UI representation. With help of this metadata prepare a value object containing all information for a graph to be plotted.
Pros: Generic solution, Very flexible
Cons: More coding needed, UI is metadata driven, if UI representation changes alot, this may not be the best approach, Client and server needs to be in contract –how to parse the Metadat, this is client is not that dumb.

What I have used:
I preferred second solution fro following reason:
1. In our team, UI development and Server side development is not segregated, hence having a Smart client is not an issue.
2. Represented metadata in XML and then used JAXB to get Object representation, with help of contract, a single class at client is driving the UI
3. No duplication, all changes are limited to either or all of 1.> Metadata XML, 2.> UI class (fulfilling the contract) or 3.> UI Screen

Using in hibernate

What does this tag do :

It tells hibernate to automatically sync up the table structure –Pojo to DB layer schema. There are couple of options which can go here:

validate: validate the schema, makes no changes to the database.
update: update the schema.
create: creates the schema, destroying previous data.
create-drop: drop the schema at the end of the session.

I suggest not to use this tag even for development, using it in production is any way nothing less than sin.

In a stressed environment (as it happened with me today), one might forget that this small tag is doing some magic and “automatically” changing the DB structure/deleting/ records et all.

1. I was running a test (DB layer test) for validating a schema change –and it was supposed to fail, because SQL has not been run.
2. Instead all the tests were passing, see even great news sometime smell bad.
3. A couple of tests later, When I verified the DB schema I saw all the DB “Automatically” updated with new schema.
4. As I had earlier worked on hibernate, It clicked and I verified the config file and got the answer to mystery.
5. Same would not have happened if I did not had experience in ORM, or at least it would have taken some time/help.

Testing the DB layer

How to write Junits for DB layer?

One fundamental concept of TDD is that tests should not be interdependent –how do we apply this for DB, A typical step for DB layer test is –emphasizing am talking about the DB testing:

Test that DB server is up
Test that DB exists
Test that Table exists
Add a record

If the first one fails, all other are bound to fail.

For integration tests we can mock these aspects and get going. For now my tests are interdependent and if one fails all fails –indicating that DB layer is not UP. Am continuing till I get a better solution.

My agile experience

I started my career in 2005, and in my very first project we were told that we will follow “Agile”  methodology. Today after spoiling my self for more 5 years in this industry I thought I should reflect upon the “crimes” people do in the name of Agile. Again this is my perspective and I do not have a definite answer to questions I am raising. Okk –no more introduction ..
Fresh from academic, we had heard of waterfall, iterative and other methods –but Agile –what’s that. We were briefed on what is Agile (No formal tarining):

  • Continuous release i.e. at end of iteration, we would have a working software.
  • Representation from each stake holder -client, developer and testing team.
  • Writing Junits for each of the functionality, something called “Test Driven Development”.
  • We should be ready to incorporate client feedback, no reluctance to rework, scrapping days hard work et all (No one really values a “fresher’s” time )

We did some self study on methodology and yeah – it’s action time, we started:

Continuous delivery

  • This we championed or rather say we “outperformed” –only glitch –it was a manual build process. Development team was responsible for releasing the build in first half of the week  which would be validated by testing team. Commit to SVN was not really necessary as long as the “Lead” developer releases the build.


  • Started with tests
  • Timeline became tight and we postponed few of the test
  • Client had demos coming up, and he badly needed the feature to outsmart the competitor –ohh other reason we pushed Juints –after all for what is the testing team being paid?
  • After 3 weeks we were quiet out of sync with the Junits –they have become functional and interdependent.

Stakeholder representation

  • Okk, everyone would be present for the meeting, but it turned out to be nothing more than a formality –testing team was testing a release a couple of days old, while dev team would use the status meeting time to brainstorm the new feature implementation pros and cons  — a total waste of time.

Client Feedback

  • It ensured that we got a new build every week ..quality and reliability of software, I am quoting the client “That’s why we have a testing team” and did anybody said bad code cannot pass testing cycle?
  • So much of releases meant we were in constant pressure, and code was being churned out –quality? As long as testing team approved it was fine.
  • We raised a flag about the code maintenance, response, again I would like to quote the client “Give me a release that I can show to prospective buyers –If I can sell I will pay to re write the whole code again”

Lesson learned
Any one who has followed agile would comment where is the “Agility” in above process –ok, I am on the same page. Agility is a mindset, “way of life” which should be adopted and realized by each of the team member –It should never be “forced”. Agility means adaptability to real time circumstances without compromise on quality –teams tend to overlook the later aspect.

  • Project Manager should have guts to take bold decision, if needed questioning clients’ feedback rather than blindly giving in.
  • Every feature which will go in next release should be agreed upon by all the stakeholders and never should be “forced”.
  • Team should come up with alternative if the circumstances are pushing towards compromise on quality.
  • “If I can sell I will pay to re write the whole code again” –This is an unwanted attitude from client –Project manager/team should have boldness to counter this attitude.
  • Status meeting should be just status meeting –scrum master must take a tough call when there is deviation. Why waste others’ time.
  • Never depend on manual build –why? Have you commented a couple of Junits or tweaked a exception block because there is a “forced deadline” –why? Release must go and you have  not slept for 30 hrs? __ I have done this, no prize for guessing that build had to be scrapped but we released it in first place –right?

I am a great fan of agile process, in fact I always wondered how can all the requirements be known in advance, how people could follow waterfall –But if execution itself is faulty, greatest weapons will fail.