The long way round…

I have moved my blog to http://www.clevegibbon.com/blog. I done this because I am playing around with new plugins and stuff and I cannot do that safely on the corporate blog.

Sorry, been offline for a bit with project work. Anyway, we are entering a new phase of a project that is heavy geared towards web services and interoperability between the .NET and Java platforms. After a little bit of digging around I found this very useful utility, SoapUI, that people like, so I gave it a go.

Not bad. Not bad at all. For the .NET guys, bear with the Java looking GUI and look to its ability to quickly and easily test web services.

Neat.

I’m a big fan of wikis and as a company we use them extensively. The cost benefit ratio simply cannot be ignored. One person solves the problem, publishes the answer on the wiki for X number of people to apply and tweak as time goes by. The only real hit is on the person publishing the content in the first place. That ain’t going to change, but…

…traditional wikis tend to be hosted on a web server. This is both good and bad. The good is accessibility, the bad is the dreaded HTTP request/response and the loss of client-side interaction. Now I wouldn’t consider myself a lazy person, but as I get older I strive to do more with less. When I have to add content to the wiki, the first thing I do is sigh. Why? Because its going to take at least 10 client/server round trips to navigate to the place I need to be, and then to add/edit the page, preview it and save it. As a content provider this sucks for me. There just has to be something better.

Then I found tiddlywiki. Nice! A client-side, highly interactive, javascript on steroids, wiki in a single file. Yep. A single file that you can transport around with you anywhere. Now for personal wikis this is great. But for team based wikis we need some sort of server but without giving up on the flexibility and interative nature of tiddlywiki. This is future work.

There have been some great innovations with tiddlywiki. Take for example, this Getting Things Done site. A few more plugins here and there and we could do some really neat project-specific stuff. For example, user story plugins and project tracking tools. The navigation is cool and the ease of downloading the entire wiki is sublime! If you wanted to mess about with tiddlywiki I suggest reading the tutorial and hosting your site at tiddlyspot.com. And last but by no means least, brush up on those Javascript skills…

What a can of worms!

In Java this is what you tend to do:

• Get yourself an J2EE application server to host your business objects.
• Implement your business objects with Spring (or EJB 3.0 and above).
• Persist your objects with Hibernate (or suitable ORM technology or JBDC)
• Job done!

On the Microsoft Platform, the story is a lot fuzzier. Basically, the proposed solution is not here yet. People are waiting for, (well keeping an eye on), Windows Communication Foundation (WCF) that will replace all the legacy (can you believe that) distributed applicaton environments that are used today, namely, COM+, DCOM, .NET Remoting (boy this has only just come out) and MSMQ. The problem is, WCF is Beta and so hard for a client to swallow and have faith in today.  But you can see what is waiting for you in the future…

…but…

…working in the here and now, what are the recommendations for delivering distributed applications on the Microsoft Platform. Well at my previous placement, we found that you have to pretty much roll your own framework to make up for glaring errors and/or omissions in the Microsoft Platform. Simple things like service discovery for .NET Remoting endpoints. Not there. So if your system requires its backend services to seamlessly failover/failback on behalf of its clients, you need to write this yourself. This takes time. Furthermore, .NET Remoting is not the quickest, where the most common recommendation is for the HTTP channel and BinaryFormatters for encoding the payload. Of course, you can distribute your services using Web Services, but speed is a concern here.

I hear you say Enterprise Services and ServicedComponents over DCOM. Yep, that is a possibility, but if your services are behind a firewall, problems! Remember CORBA. Now I’m not complaining here, but more trying to get a clear story on common architectural patterns for distributed applications on the Microsoft Platform. So I take my hat of to Rockford Lhokta and his write up on Middle Tier Hosting. Then sprinkle in some .NET Remoting Use Cases and Best Practices from ThinkTecture and I’m starting to see the light. Unfortunately, it ain’t pretty.

Basically, it boils down to what Rockford explains as layers and tiers. Layers being the logical application groupings (presentation, business and data ) and tiers being the phyiscal. The rules are thus:

• layers cannot span tiers.
• mulitple tiers leads to tears.
• a host provides an environment for tier(s).
• your choice of host (Enterprise Services, IIS or Custom) depends upon the protocols you plan to use.
• The available protocols are DCOM, Web Services and Remoting.

So let’s just whittle down the possibilities here. For the most general cases in application development for customers that I’ve built systems for, the following holds:

1. I need my clients to access business services through a firewall and I don’t want every client machine to have to register our server COM components on their local boxes. Rollout nightmare. Yuk. Yuk. Yuk. DCOM is out.
2. I have no time to invest in writing a Custom environment to host my application services. This is costly and you have only yourself really to sort out the problems.

These two simple requirements have made me realise the following:

1. It rules out Enterprise Services and Custom as possible hosts.
2. Why the majority of .NET server applications involve IIS - there is simple no other alternative that I can think of. Please if someone has one, I would love to hear from you.
3. The importance of standing firm and implementing clear layers of responsibility, given that the recommendation is really to stick to a single tier unless to want to take on the complexity of multi-tier application development. It’s possible, but its just damned hard.

Back to the story. So with IIS as the host environment and Web Services and/or Remoting as the protocol, we can implement our business services using .NET assemblies, ServicedComponents, SWC (Services Without Components), and take advantages of some of the neat .NET 2.0 Enterprise Service APIs, namely distributed application transactions (you need SQL 2005 in place for this).

Okay, I’m happier knowing this. But will also keep my eye on WCF and the migration path it proposes for code that I’m about to write that is already deemed legacy…

Oh I did laugh when I read Uncle Bob’s post on the speed comparisions between Java, C++ and Ruby. I still hear the mutterings from C++ guys saying that Java is soooo slooowww. I also hear it from Windows programmers on the VB.NET platform. Sigh! I put it down to ignorance the wilful neglect to open ones eyes and smell the coffee…

Although Ruby brought up the rear, by some way, that’s the way things start. Walk before you can run and all that. It will get better but just looking at the code snippets, there was only one clear winner there. Well done Ruby…

It’s that time again! Sell the house. We do this every 2-3 years to stay on our toes and just to do something different. People call us mad. Maybe. But its interesting to move to a completely new place, with a bunch of new neighbours, gossip and shops to get your head around and with the added bonus of leaving the less desirable people you happened to be positioned next to at your previous address. It’s all good fun.

Anyway, selling a house is all about applying the 6 P’s - Prior Planning Prevents Piss Poor Performance. And when someone says the word planning, I reach for my index cards. On each card we wrote the name of a room, plus non-rooms such as cellar, loft, garden and car. We stepped through house and brainstormed what tasks needed to be completed to best market each room. For example, remove pizza boxes (I can’t believe I still do this - grow up Cleve), clean the toilet (mental note - assign this one to the missus), paint ceiling, and so on. These were added to that room’s the index card. Once all the cards were completed, we sat down agreed effort estimates in undisturbed hours and cost in pounds sterling. We quickly added up the effort estimates and costs, and got a completion date and overall budget.

Now, a week into this and we are ahead of schedule. Sweet! And, having done this 4 times before, this is by far the most enjoyable prepare for sale experience we have ever had. Why? Because it is not ad-hoc like all the other times that we have done it. We know how much more we have to do before we are done. Basically, there are two piles of index card above our fireplace - the completed and not completed pile. A simple but clear visual reminder of outstanding work. Also, if I have a spare couple of hours, I trot downstairs, pick up a card and start work. No need to liase with the missus on what I should do or what she is working on - if the card is on the “not completed” pile - take it and do it! It’s that simple.

Another really interesting aspect to it is the budget. Because we are tracking estimates against actuals, and because we are currently underspending, we are able to hire workmen to do work we planned to do ourselves to bring the completion date in. This is proving to be very useful indeed.

Anyway, enough already. I’ll let you know how things are progressing in a couple of weeks time…

I would be the first to admit it. I’m a geek. I love technology. I think well written software is an absolute thing of beauty. There is no better feeling than being a member of team (coding solo is not really my bag) that cuts quality code that can be adapted to meet future (read as unplanned) requirements. That simply rocks my world.

That said, these days I’ve found hidden value in not being a part of the coding team - the engine. I’m no longer a part of the engine but more the oil in the engine. Basically, if there are guys that are better than you, the that best thing to do is let them get on with it. However, an engine needs tuning here and tweaking there to deliver the best results possible, in the shortest space of time. Every team needs oil, without it, things get stuck and engine stops performing. More to the point, you’re either oil or a part of the engine. You cannot be both, or something, somewhere will break!

So ask yourself, in your team, what are you - oil or part of the engine?

I’ve just come back off holiday with the missus and 3 kids. It ended up being a fanastic break, but started off as a right old howler! The middle kid, India, can be nightmare and morphed into a some demonic, adult munching, seven legged monster on day one of the holiday. That same night the missus and I discussed the issues and formulated plans to improve the situation. Day two was an improvement and again that night we revised our plans. Day three was even better and so on and so forth. Happy holidays…

When I got back from holiday it suddenly dawned on me that I was applying the stuff that I do when running software projects to my homelife. Sad, but true! There are many different names for this (not my sadness), but I like the term used within Crystal Clear - Reflective Improvement. It you think of the holiday as a release, then each day was an iteration within that release. Intra-day we were doing Reactive Improvement, bascially dealing with issues as and when they arose. Inter-day, we were doing Reflective Improvement.

You need a heathly dose of both reactive and reflective improvement. With reactive improvement, you are making tactical adjustments within an iteration to steer it to a successful conclusion. However, tactical adjustments are not as effective unless they are made within the context a strategy. The strategy defines objectives and success criteria, however formal or informal you wish to make them. Moreover, the strategy needs to be made outside of an iteration so that the team can discuss the issues as if looking down on the battlefield from the highest mountain, rather from in the frontline trenches.

The sad truth is that the majority of software projects I’ve encountered, I may be unlucky, deal purely in the reactive improvement and reflect only once as an post-project post mortem exercise. What the hell use is that? If I had I done that on holiday, India would surely have completely devoured by left big toe, and heaven knows what next.  But don’t worry, I’m fine…

I’m not agile, but I have agile tendencies. I’m not test-driven, but I am a firm believer in writing tests as you develop. Treat your tests as your source code keeps you honest and on your toes. So why the post? I’m starting yet another project and I wanted to give Test Driven Development (TDD) as shot. That’’s all.

Some background. The project we have is tight. No changes there. It has a couple of releases, that we have further broken down in iterations. We are currently in the second iteration of the first release. The first iteration was to provide a live end-to-end mock up of the web site we are developing for our client. As a proponent of user-centric design, I’m keen to get the application in front of the end-user as soon as is humanly possible. As a result, and as expected, the requirements shifted quite a bit after iteration one but we, customer and us - the team - are now happy with the screen flow. Major bonus point.

Given the project is heavily database focused and it requires us to connect to legacy data, the second iteration is all about domain modelling. The technology base is comprised of all the usual suspects being Java, Spring, Log4J and WebWork as the presentation layer. My task was to take the end-to-end mock up and write the first DAO. In doing so, it would bring Hibernate to the party. So I started by writing a test.

Step 1: Create the test!

Our application has auditing requirements. Write a test to store an auditable event into the database and verify that it can be retrieved at a later date.

Status:

• Test completed. Cannot compile code

Time Taken:

• 3 minutes

Current feedling:

• I’m in a dark place - this is going to take some fixing. I feel sick.

Step 2. Make the test compile

A number of classes were created such as the DAO and methods required to save and get back auditable events.
This amounted to the AuditableEventDao, the AuditableEvent POJO, an exception class to report errors and suitable documentation for these classes and interfaces.

Status:

• Code base compiles. Test fails.

Time Taken:

• 5 minutes

Current feeling:

• I feel dirty. This design feels all wrong. This test driven approach has pushed me down a certain design track. I don’t like being pushed.

Step 3. Refactor

Not happy with a couple of structures so I spend some time thinking and making things a bit neater and tidied up the comments in the process. Got the tests firing up within spring.

Status:

• Code base compiles. Test fails.

Time Taken:

• 5 minutes

Current feeling:

• Happier! A lot happier. I know where I’m going but still a long way from home. Time for a coffee.

Step 4. Make test succeed

This part was just plain tedious. Nasty. It was all infrastructural stuff. Getting the in-memory database running (hsqldb), writing the hbm files, configuring spring to work with hibernate, fixing the maven2 pom files, and so on. However, that said, having the test in place focussed the mind and swiftly pulled me back to the main run when i drifted off-piste experimenting with stuff.

Status:

• Code base compiles. Test succeeds

Time Taken:

• 15 minutes

Current feeling:

• Pretty good. I’m out of the tunnel…but not done.

Step 5. Refactor
This was the part I enjoyed the most. The tests are succeeding and I’m tinkering with the test framework. Making things better. Removing stuff here. Adding stuff there. Running the tests to check that I haven’t dropped the ball. It’s all good stuff.

Status:

• Code base compiles. Test succeeds. Added more tests.

Time Taken:

• 15 minutes

Current feeling:

• Smug. Game over. I want to write more tests…

Okay, I enjoyed myself. However, this is not the first time I’ve done this. Its just that I don’t do it all the time. More importantly, I don’t always write the test first. Will I going forward? I doubt it. But that would be the exception, rather than the rule. You can’t always develop in a TDD manner. You cannot have complete test coverage for your codebase. Any who says they have, I’d like to see it. But that doesn’t mean you cannot have a test framework that provides you with means to be make changes with confidence. For me, that’s the biggest win and the reason that we must move forward with writing more tests and if TDD helps in the battle, then I will use it where appropriate.

In a previous post I talked about the pain I’m in trying to give up Intellij and move over to Eclipse. I was just about there this week when this happens…damn, damn and double damn!