Company Wide Language Standardisation

This is recent slashdot article on Company Language Standardisation.

Over a couple of years the company that I work at has through acquisition managed to move from having 3 main languages in use to 6 main langauges. This has made development and maintenance more difficult, especially as some of the acquired code was produced by less experienced developers.

I can see the need for having appropriate languages for their problems.
However there should not be two langauges in the same niche.

A company should either pick VB.Net or C#.

Personally I would lean towards C# but then I have had some bad experiences with the quality of VB.NET code that I have seen.

There are  some arguments for allowing Java and C# within an organisation to allow the use of the associated technology stacks.

A company also needs a native language for the platforms that they are using (for those times when the frameworks don’t cut it) – for windows Delphi or C++ cover this field.

I would also recommend the use of a scripting language for support tool purposes.
Currently I use a mix of Tcl/Tk/Expect and Python.

Overall a company should use a limited set of languages to maximise the number of developers that can work on a given project. There should be one language in any given niche – but don’t limit youselves too much.

XSLT Considered Harmful

Warning XSLT can seriously twist your brain.

XLST was hailed at the end of the 90’s as being the uttimate tool to transform XML.
Theoretically you can use it to transform any XML into any other other format.

It can be very powerful (look at Code Generation).
However it needs to be treated especially carefully and be properly supported by unit tests of the transforms. Just because some clever code can be written does not mean that it should. Don’t take too many shortcuts.

Here is a useful python script that will make life a little easier:

import os

def XPathToXML(XPath):
   s = XPath.split(“/”)
   for x in s:
      print (“<“+x+”>”
   s.reverse()
   for x in s:
      print (“</”+x+”>”

if __name__ == “__main__”:
XPathToXML(os.argv[1])

This little beauty will take an XPath fragment such as
a/b/c and return:
<a>
<b>
<c>
</c>
</b>
</a>
Which is just what the doctor ordered when creating XSLT test data.

Pros and Cons of Stored Procedures

Recently I have been a heavy user of stored procedures.
There is a big debate going on about the benefits or otherwise of stored procedures.
I would not argue that they are faster than inline sql (these days that is a moot point).

Pro
Individual sp’s easy to replace this provides many places for system expansion/correction.
There are great security benefits. An app that exlusively accesses a db via
sp’s can have much tighter control over it’s data access.

Con
Not portable.
Sometimes limited error handling.
No use of constants.

What is three tier design

Recently I heard the preposterous claim that a three tier application that uses stored procedures is not really three tier.

A three tier application splits it work up into distinct tiers (Here is an example):

1. Presentation Layer
2. Business Layer
3. Database layer

While this is harder initially to set up it does provides a range of deployment, security, development and maintenance benefits.

Just because the database layer uses stored procedures does not in any way invalidate this model.

For deployment, with a corrrect design it is possible to only require detailed configuration once on the server as opposed to every client.

For security there are more oppertunities for security in depth (you only need grant database access to the Business Layer or Database Layer not every user).

For development there are more incentives to reuse code since the layers provide a some decoupling. In a two tier application there is far more room for code duplication. The layers also provide a point for performance tuning.

For maintenance having distinct layers means that a patch can be better isolated.
If you don’t change the interface only a single changed component needs to be deployed.

Very useful .NET debugging aid

The following can be very useful when debugging a service or any other .NET app

At an appropriate point in your code you add:

if ( !System.Diagnostics.Debugger.IsAttached )
{
System.Diagnostics.Debugger.Launch();
System.Diagnostics.Debugger.Break();
}

It will search for a suitable debugger which would include the IDE that you have open on your code.