Homebrew Build and Unit testing tools

On IFM, alongside the application development, we develop a suite of tools to enable versioning, releasing and unit testing.

IFM is a complete Internet banking front end, implemented using Microsoft's DNA toolset. It consists of several layers of processing, and UI elements. A core project that implemented the majority of functionality is then customised and extended for each client in separate implementation projects.

The development model is loosely based on xProgramming and jUnit. In practice this consists of a modular processing tool to build and unit test the system directly out of source control. The build tool runs several stages of processing to merge customer specific features & design with core functionality, apply UI templates, compile C++ and VB6 code, produce documentation and initial configuration and finally generate a completely automated deployment package.

The next stage of the build tool is unit testing. There are several classes of unit tests: Install routine tests, back end server tests, business logic object tests, database tests and the most recent addition: a programmable http spider to test the system via the web UI.

A dedicated server continuously runs build/test cycles on all projects and reports any regressions (usually caused by development). A developer must then review these and either fix the code or the test.

Key benefits of this approach are:

• 95% of Regression testing, a repetitive, boring and error prone task is automated and can be repeated often
• A high level of confidence exists before any manual testing is undertaken; this shortens the number of test/debug cycles.
• The System wide impact of changes can be seen immediately
• The exact differences between any two versions can be mapped precisely.

There are of course costs. In addition to the fixed overhead in creating the build tool, there is the cost of maintaining the individual test scripts. This can be as much as 20% of development time. However, the benefits easily outweigh the costs.
In practice very little manual testing is required to maintain high quality of deliverables. Development cycles are shorter and there is no bottleneck for testing. The testing is mostly the developer's responsibility; the people who work most closely with the system. Testing becomes an interesting and challenging job instead of a dull, repetitive one. As a result it is much more likely to be done, and done well.

Trying Again To Make Books Obsolete - New York Times

Trying Again To Make Books Obsolete - New York Times

This is one of the only devices in the last couple of years that I am really aching to have. I've been waiting for the E-Ink display technology for a long time and despite the quirks, $350 seems very reasonable.

The last device to get me this excited was the HP TC 1100. A compact yet fairly powerful tablet PC. Initially it was a lot of fun. But after a while I stopped using it. The software didn't take advantage of the touchscreen, the handwriting recognition wasn't very good and it was never practical in a meeting which is what it was designed for. The device was too clumsy and heavy and got hot so you couldn't hold it for long periods of time and so in the end I decided it didn't offer enough to justify the effort in using it.

As excited as I am about the Sony Reader, I doubt it will replace books any time soon. It seems the traditional medias die very slowly - reading and writing have had a long time to mature and are very entrenched and hard to digitise. In contrast recently created medias, the Audio cassette, VHS Tape and even Cd's and DVDs are dead or dying.

Dyson DC16 Root 6: The First Handheld Vacuum That Does Not Lose Suction » werty dot net 4.0

Dyson DC16 Root 6: The First Handheld Vacuum That Does Not Lose Suction » werty dot net 4.0

It's a really slow day today. So when I saw Werty's post about a Dyson handheld cleaner that costs 5 times more than the competition I perked up. Our Dyson like vacuum cleaner (which was rubbish) died a couple of years ago. So i asked Kate, who used to clean our flat, what kind of Dyson to get. She looked at me with a deep look of pity reserved for the mentally challenged and said she didn't know.
When pressed she suggested I get a Henry. "A what?!" i said. "A Henry" she said "I use it in one of my other jobs and its much better than any Dyson".

I looked into it. It has a smiley face painted on it and comes in especially naff shades of red, green, yellow or blue. These things are the dogs bollocks: small, light, powerful, cheap, reliable, easy to use. They're what professional use. You don't even have to use a filter if you prefer. Just not cool and not marketed very well and they have these silly smiley face painted on them.
It's a vacuum cleaner for Christ sake.

Could a 30-in. monitor help you do your job faster? - Yahoo! News

Could a 30-in. monitor help you do your job faster? - Yahoo! News

This story is about research commissioned by Apple: They claim you can save up to 50% of the time spent in operations involving dragging content from window to window (a few seconds).

This sort of commissioned research is a great way for companies to get cheap marketing - but in this case the reporter didn't play along. The article goes on to quote several experts disputing the claim, they say the saving are 5% at best. What's more, they recommend a better alternative: two, much smaller screens.

Better luck next time Apple...

Schumacher fastest at Jerez

F1Racing.net - Every day updated Formula One news! (For Formula 1 news, results, photos and more!) I was told no Blog is complete without a reference to red Ferraris. So there!

IE7 to debut in October | The Register

IE7 to debut in October | The Register I have had IE7 installed on my desktop at home for the past couple of months. It's a strange world where I am constantly reaching for Firefox to get sites to render properly. IE7 is still very much in beta, it's slow, crashey and just not very nice at all. I can't see how this can possibly be ready yet.

Why i like .Net

Microsoft is deeply disliked by many, especially developers - and for good reason, many of their products are second rate.

One area where Microsoft products shine is in the business they started out in: development tools. There are many options in the marketplace for developers to choose from and while Microsoft leads in some areas such as desktop development it is far behind in things like databases engines and web development and servers.

Microsoft is making a huge effort in these areas. It has looked closely at what people do and the problems it's customers were facing. The offerings are nearly addictive in their productivity and ease of use.
With the most recent round of tools, especially .Net 2.0/VS2005 and SQL 2K5 it is possible to bang out a complex solution with breathtaking ease.
For example: in developing web applications, ASP.Net under VS2005 offers a rich, event driven programming model and broad array of UI controls as well as powerful tools to handle templateing, configuration, user management, navigation and so on. This stuff works beautifully and is intuitive and easy to access and learn as you go along. VS2005 offers a set of wizards designed to ease the task of accessing your data. These allow you to model your database in native objects with varying degrees of control and you can then link these object to controls in practical ways, allowing even fairly complex forms to be created with very little code. The wizards are smart and feel somehow transparent. Having used these features extensively, they feel stable, flexible and are well worth the effort of working within the constraints they enforce.

Microsoft's business practices are obviously harmful to consumers and business. As Microsoft gains control of a market, competitors disappear and progress grinds to a halt. I hope Microsoft's competitors at Sun and in the FOS arena stop sneering and take a close look at these tools and evolve their own offerings to make sure the competition keeps going.

Planning software development

Creating software is often said to be an art – this is true to some degree, but at its core, building software is an engineering task. Software is usually made to serve a purpose or solve a problem and as much as possible, functionality, delivery dates and costs should be known in advance and met when the software is delivered. To do this you need to spend time up-front gathering requirements, working out the technical details and breaking the work into manageable tasks; and then costing it. This will help you make promises you know you can keep and may mean the difference between success and failure.

Before you begin

Talk and think about the project. Talk to users and client and gleam as much information as possible. Try to get them to put as much as possible into writing. Clients are usually not software professionals so they will omit things; work with them to get a clear picture of what they really want to do. Don’t worry about the implementation at this stage, just think about the real world implications of what they want.

Requirements

Once you have an initial understanding of the requirement start creating a Requirements Definition (RD). The RD will contain an overview of what the problem is, and the proposed solution. This should be understandable by everyone involved in the project.

Cover all the tangibles: benefits, features, efficiencies, etc. that should be delivered. Then describe the solution. It is often a good idea to scope the development and mention what isn’t covered too. Be as detailed as possible but use judgement - there is no point writing a 20 page requirement document for a 2 days project.

In a big project, it’s often a good idea to break the requirement into several stages that can be built consecutively but are useable on their own. This will allow the client to control her costs and force prioritisation.

It’s important to get the RDF approved. Make sure the person signing-off understands it and make sure it is as close as possible to their initial dream. It is often necessary to revise this a few times and move feature in, out and around.

Technical Design

The audience for this is mainly internal; this is meant as a guide for the development process. Its purpose is to allow you to budget and schedule and may feed back into the requirements documentation. It is then used by the developers implementing the software.

The most important thing to cover here are the processes in the software. The business rules, algorithms, data models, etc that your software will implement. Don’t try to capture every detail of the program, by the time you’ve done that – it’s already written. Only cover things that aren’t obvious. The size of the project is a guide to how detailed this should be.
In addition to a written document you may need to produce some of the following: Use cases, data models, screen designs, class designs and state diagrams.

Work Order

This should be the final output of the design process. The work order is a list of tasks and materials needed to build the software. This can be broken down in various ways. By the headers in the RD, by type of professional or anything else that makes sense.
A separate work order should be created for each phase of the development. Some items to include in addition to project specific ones are: testing, documentation and training.
If there are any third party requirements: hardware, software or otherwise, mention them here.

We have done a considerable amount of work at this stage but still no software has been produced. It’s a good idea to make the client aware of this in advance and try to agree a fee in case they decide not to go ahead with the project.

Finally

In practice it is very hard to think of everything in advance and the price of a project is usually decided by what the customer is willing to pay. Focus on understanding what’s impotent to them and what they want to achieve. Be sure to build enough time into your estimates for anything you’ve missed during the design phase. Allow time for reworking based on customer feedback. Use your gut but don’t rely on it. If the algorithms are complex or if the requirement is to use a piece of third party software: it may be a good idea to spend time proofing the solution first so you are confident that you aren’t getting into something you can’t control.

Talk to your customers and users during the development process, show them youre progress and make fine adjust as you go along. On the other hand – don’t be tempted to rip everything up and start again. Identify problems and address them directly as quickly and painlessly as possibly – using as few resources as possible.

Good Luck!