The long way round…

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?

Okay, okay, I admit it, I’ve been slack. No one is too busy to blog, but this one I’m going to keep brief.

One of the big issues I have when building software artefacts is getting the release number into the product as part of the build. The current product we are working on is a Java web application that uses Maven 2 as its build system. Now, thanks to colleague of mine, Master Merlyn, who also beat me up over my lack of blogging, we have a solution. Enter version 2.0.1 of the maven-war-plugin. What this little beauty does is enable you to apply filters to resources within your webapp as part of the build that give you access to elements within your pom.xml file. For example:

<build>
…
<plugin>
<groupId>org.apache.maven.plugins</groupId>
<artifactId>maven-war-plugin</artifactId>
<version>2.0.1</version>
<configuration>
<webResources>
<resource>
<directory>src/main/webapp</directory>
<filtering>true</filtering>
<includes>
<include>**/*.jsp</include>
</includes>
</resource>
</webResources>
</configuration>
</plugin>
…
</build>

Now if I want to add the version number (or any other pom element) to any of my jsp files I do the following:

<p> My Application Version: ${pom.version}</p>

Sweet!

But there are a couple of things to note:

1. Use version 2.0.1 of the maven war plugin.
2. Narrow the scope of the files you filter with <includes/>
3. Binary files - exclude them!

That’s it. Enjoy.