How can I have too much praise for this band? I have been listening to their album recently and I can't get away from the fact that these people aren't rock-star millionaires even thought they should be.
Last year I celebrated my 25th wedding anniversary to my beautiful wife Chrissy and we decided to hire a band to play music at the event.
Chrissy found Brian's band through an internet search and we decided to hire them, even though the price at the time seemed high. We had gone to the trouble of finding the venue of a French castle for the party so we figured that a band should at least try to fit in.
Unbeknown to us we had hired a band of such incredible quality and skill that we were totally and utterly blown away by their music.
Brian's voice has a soaring quality that one would expect from Freddy Mercury or Stevie Wonder. The band's music is tight and professional and the lyrics rip your soul from you and leave you with the feeling of having been drowned and brought back to life in the same moment.
The Brian McCoombe Band is a celtic rock band with roots in Scotland, Ireland and the Finistere region of France. Their music is original and astounding. Seek them out and be amazed!
Sunday, April 13, 2008
World class Software
For almost three years now I have worked in the commercial finance industry and have been advising banks and insurance companies on how to write software that stands the test of time.
Institutions such as banks have a client lifetime measured in decades so the idea that software should be robust and reliable is taken for granted. The reality is however, that the software produced in companies that really ought to be irreproachable is often somewhat less than mediochre and that the attention to code quality is less that one would assume.
My rules for world-class software are simple:
#1 All code must be documented with inline comments and white-papers that describe the motivation behind the implementation. When this is in place the superhero programmer cannot die in a skiing accident or be headhunted by the company up the road and leave the development team wondering how the code works.
#2 All code must be tested. Unit testing, black-box testing and white-box testing ensure that the software performs as intended. All three types of testing are needed because none of the individual techniques cover all of the usage scenarios. Testing is a serious business so, rather than leave testing to novice programmers, companies should hire the most expert and devious code-killers possible to test the software. These people are few and far between and should be paid a lot!
#3 Software factories that do continuous build and test are essential. Without these, mistakes in the build can go unseen for days, weeks or months, depending on the release cycle of the application.
#4 Source-control rules must be draconian. Developers must not be allowed access to the same file at the same time. If they need to then you probably have the situation of more than one class in a file. This is totally unacceptable. Checking in of a file that breaks the build should be accompanied by public ridicule in stand-up, daily or weekly meetings. A great thing to do is to have people wear a stupid hat if they break the continuous build.
#5 Code should be monitored on a daily basis. Companies I advise often have code metric analysis tied into the daily builds so that it is easy to see whether a class has become bloated with too many methods, methods are more than a certain number of lines, cyclomatic complexity is too deep or there aren't enough comment lines in the code.
If you're company is in Australia and you need a seriously dedicated architect drop me a line...
Institutions such as banks have a client lifetime measured in decades so the idea that software should be robust and reliable is taken for granted. The reality is however, that the software produced in companies that really ought to be irreproachable is often somewhat less than mediochre and that the attention to code quality is less that one would assume.
My rules for world-class software are simple:
#1 All code must be documented with inline comments and white-papers that describe the motivation behind the implementation. When this is in place the superhero programmer cannot die in a skiing accident or be headhunted by the company up the road and leave the development team wondering how the code works.
#2 All code must be tested. Unit testing, black-box testing and white-box testing ensure that the software performs as intended. All three types of testing are needed because none of the individual techniques cover all of the usage scenarios. Testing is a serious business so, rather than leave testing to novice programmers, companies should hire the most expert and devious code-killers possible to test the software. These people are few and far between and should be paid a lot!
#3 Software factories that do continuous build and test are essential. Without these, mistakes in the build can go unseen for days, weeks or months, depending on the release cycle of the application.
#4 Source-control rules must be draconian. Developers must not be allowed access to the same file at the same time. If they need to then you probably have the situation of more than one class in a file. This is totally unacceptable. Checking in of a file that breaks the build should be accompanied by public ridicule in stand-up, daily or weekly meetings. A great thing to do is to have people wear a stupid hat if they break the continuous build.
#5 Code should be monitored on a daily basis. Companies I advise often have code metric analysis tied into the daily builds so that it is easy to see whether a class has become bloated with too many methods, methods are more than a certain number of lines, cyclomatic complexity is too deep or there aren't enough comment lines in the code.
If you're company is in Australia and you need a seriously dedicated architect drop me a line...
Thursday, March 27, 2008
It might be architecture, but is it art?
At work today I remarked to a friend that the name "Architecture" can apply to some software in the same way that "Building" can apply to a beaver dam.
Both seem to have been thrown together by animals, subject to the forces of nature, inherited by a long line of animals with differrent ideas on how building should be done, do the job they are intended to do with results that depend on the weather or the phase of the moon and are often adversely affected by rot.
The only good thing is that you can get rid of bad software without dynamite and without upsetting a bunch of bleeding-heart ecologists.
Both seem to have been thrown together by animals, subject to the forces of nature, inherited by a long line of animals with differrent ideas on how building should be done, do the job they are intended to do with results that depend on the weather or the phase of the moon and are often adversely affected by rot.
The only good thing is that you can get rid of bad software without dynamite and without upsetting a bunch of bleeding-heart ecologists.
Sunday, March 23, 2008
Wonderful internet again.
Here's how the Internet is the most wonderful thing that ever happened to the human race.
I've been married for over 25 years to a fantastic lady who I met one afternoon in a farmyard on the Isle of wight. Just before I met her she had been involved with a not incredibly famous progressive rock band called The Enid. This band played all manner of pieces ranging from classical composers to covers of The Troggs Wild Thing and The Sex Pistols Pretty Vacant as well as their own compositions which are pretty good too.
They did a gig in 1978 in Farnborough England where a Swedish fellow by the name of Hans recorded the only recording of some of their music. My wife who was 16 years old at the time was in the audience making noise.
Thirty years later, Chrissy has a MySpace page, contact with the ex band members and through the power of the Internet, Hans. This means that the one and only recording of that gig, made on a handheld tape recorder and never heard elsewhere can live on and enrich the human experience.
You may not imagine that this is important in any great scheme but that data is digital. Ok, the original recording sucked but it was real and it existed for couple of hours. It made memories for a bunch of people that have lasted for thirty years so far and now will be available amongst the petabytes of other data that the human experience has created. Maybe someone a thousand years from now will hear a bit of music that has my wife singing in the background when she was a kid. Maybe someone a million years from now will still be able to hear it.
When all human experience becomes digital and storeable and transferrable and copyable and shareable maybe we will all become immortal.
http://www.myspace.com/theenidsociety
I've been married for over 25 years to a fantastic lady who I met one afternoon in a farmyard on the Isle of wight. Just before I met her she had been involved with a not incredibly famous progressive rock band called The Enid. This band played all manner of pieces ranging from classical composers to covers of The Troggs Wild Thing and The Sex Pistols Pretty Vacant as well as their own compositions which are pretty good too.
They did a gig in 1978 in Farnborough England where a Swedish fellow by the name of Hans recorded the only recording of some of their music. My wife who was 16 years old at the time was in the audience making noise.
Thirty years later, Chrissy has a MySpace page, contact with the ex band members and through the power of the Internet, Hans. This means that the one and only recording of that gig, made on a handheld tape recorder and never heard elsewhere can live on and enrich the human experience.
You may not imagine that this is important in any great scheme but that data is digital. Ok, the original recording sucked but it was real and it existed for couple of hours. It made memories for a bunch of people that have lasted for thirty years so far and now will be available amongst the petabytes of other data that the human experience has created. Maybe someone a thousand years from now will hear a bit of music that has my wife singing in the background when she was a kid. Maybe someone a million years from now will still be able to hear it.
When all human experience becomes digital and storeable and transferrable and copyable and shareable maybe we will all become immortal.
http://www.myspace.com/theenidsociety
Saturday, March 22, 2008
Web idiocy
Please enter your e-mail address...
Please confirm your e-mail address...
How idiotic can you get? If someone enters the wrong address it's their fault and why should you care?
This has become an annoying habit with many webmasters and i bet they do it just because everyone else does.
Please confirm your e-mail address...
How idiotic can you get? If someone enters the wrong address it's their fault and why should you care?
This has become an annoying habit with many webmasters and i bet they do it just because everyone else does.
Monday, March 03, 2008
Vista 64 and performance.
After upgrading to a new graphics card and more memory I get a performance report of 5.0 on my Vista ultimate 32 bit install.
At the same time, I bought a new hard-disk upon which I decided to install Vista 64 bit but this gives me a lower performance rating of 4.3 and crashes every few seconds with a display driver freeze.
I am interested in using Vista46 because I want to take advanage of the 4 gigabytes of memory that is now in my system. My experience so-far however shows that it's buggy, unstable and has serious compatibility and driver issues. It took me five attempts to install a version that even boots without a bluescreen. I accomplished this with the latest vista install with integral service pack one direct from MSDN.
As an MVP I get access to software for free but I can say unequivocally that had I bought Vista64 ultimate I would be a very unhappy customer.
Saturday, March 01, 2008
Growing up with technology
The first computer I ever had, I built myself. It had a Zilog Z80 processor and 2K of static RAM. I understood it at a fundamental level and when I learned to program I did it in pure machine code. It was some time before I used even an assembler let alone a high-level language like C.
This gave me a very machine oriented view of the computer. I understood that integers were stored as binary ones and zeros in a specific order in a register. I understood that a mathemtical operation was different from a bitwise logical operation and even today, when I think of an integer or a byte I see a little shoebox with a certain number of pebbles ranged in sub-divided partitions for the bits. Consequently, I find myself surprised when programmers go through their working lives without ever understanding this.
Now, a university student or technical college student immediately sees the high-level language view of the system and may not undertand the implications of the circuitry that carries the signals back and forth along the busses.
I find this to be both interesting from an anthropological viewpoint and disquieting from a professional one. From the first viewpoint its interesting that we don't fundamentally need the deep-down knowledge of the systems we work with anymore. We can work at such a high level that there is no need to understand the mechanism of an interrupt or consider an integer like an array of bits. It's disquieting because there is still a lot of code that relies on these principles so when a new-age programmer sees these techniques in use, they may not immediately understand what the implications are and so make an adjustment that is completely at odds with the architecture.
I wonder how long it will be before even the discipline of logical problem solving and algorithm creation is obsolete? I bet it's less than twenty years.
This gave me a very machine oriented view of the computer. I understood that integers were stored as binary ones and zeros in a specific order in a register. I understood that a mathemtical operation was different from a bitwise logical operation and even today, when I think of an integer or a byte I see a little shoebox with a certain number of pebbles ranged in sub-divided partitions for the bits. Consequently, I find myself surprised when programmers go through their working lives without ever understanding this.
Now, a university student or technical college student immediately sees the high-level language view of the system and may not undertand the implications of the circuitry that carries the signals back and forth along the busses.
I find this to be both interesting from an anthropological viewpoint and disquieting from a professional one. From the first viewpoint its interesting that we don't fundamentally need the deep-down knowledge of the systems we work with anymore. We can work at such a high level that there is no need to understand the mechanism of an interrupt or consider an integer like an array of bits. It's disquieting because there is still a lot of code that relies on these principles so when a new-age programmer sees these techniques in use, they may not immediately understand what the implications are and so make an adjustment that is completely at odds with the architecture.
I wonder how long it will be before even the discipline of logical problem solving and algorithm creation is obsolete? I bet it's less than twenty years.
Sunday, February 17, 2008
Living in the past
The Chinese have a curse; May you live in interesting times. The 1990s certainly were interesting for programmers. A vast proportion of applications coded during those years were written in Visual Basic and, believe it or not, these applications are still hanging around today.
I imagined that finding a team that programs almost exclusively in a language as crippled as VB6 is in these days of frameworks and massive API's would be rare in itself but it seems that they are not so rare as I imagined. Trying to train such a team to change working practices to encompass .NET 3.x and C# is a challenge.
Over the years I've seen many .NET projects written by VB programmers and it seems that the pattern is always the same. No layers in the architecture, code factored by functions - not by classes, no concept of encapsulation or inheritance, every dirty trick possible to create global objects and globally accessible functionality.
I never realised that object orientation was something that was still on the frontier of programming practices. Maybe the millions of VB devlopers out there really do need help.
I imagined that finding a team that programs almost exclusively in a language as crippled as VB6 is in these days of frameworks and massive API's would be rare in itself but it seems that they are not so rare as I imagined. Trying to train such a team to change working practices to encompass .NET 3.x and C# is a challenge.
Over the years I've seen many .NET projects written by VB programmers and it seems that the pattern is always the same. No layers in the architecture, code factored by functions - not by classes, no concept of encapsulation or inheritance, every dirty trick possible to create global objects and globally accessible functionality.
I never realised that object orientation was something that was still on the frontier of programming practices. Maybe the millions of VB devlopers out there really do need help.
Saturday, February 16, 2008
On patterns...
I responded to a post in one of the Microsoft newsgroups the other day where someone asked "Is MVC a good pattern to use and should I port my old implementation of it to my new C# application" (I am paraphrasing here).
The answer is; Yes, MVC is a great pattern and NO! don't port it. it's built in to .NET. They just call it databinding.
When pattens became popular in the 90's I was working as a team lead in Stingray's C++ development department and I remember long and fraught discussions about the MVC pattern because my boss saw MVC as somthing that worked on a macro level, the whole view, the whole model and the whole controller. I on the other hand imagined MVC as a light and super granular pattern that only really applied well to individual controls or bits of data. Because he was the boss, Stingray went on to provide an MVC implementation that worked well enough but that encouraged hefty logic built into views and complex interactions with data that sort of spoiled the simplicity and grace of my MVC vision.
Looking at the world now I feel vindicated because databinding is indeed granular and simple and, as I mention in my previous post, is the only thing that Microsoft have really retained between Windows Forms and WPF.
I strongly advise that you don't fall into the trap of trying to reimplement MVC on a .NET platform. I saw an example of this just a short while ago when a very competent and sane C++ programmer was given the thankless task of porting an old C++ program that implemented Stingray's MVC pattern to C#. He spent weeks messing with it and then was disturbed to discover that all that effort could have been avoided with a few simple lines of databinding code.
The answer is; Yes, MVC is a great pattern and NO! don't port it. it's built in to .NET. They just call it databinding.
When pattens became popular in the 90's I was working as a team lead in Stingray's C++ development department and I remember long and fraught discussions about the MVC pattern because my boss saw MVC as somthing that worked on a macro level, the whole view, the whole model and the whole controller. I on the other hand imagined MVC as a light and super granular pattern that only really applied well to individual controls or bits of data. Because he was the boss, Stingray went on to provide an MVC implementation that worked well enough but that encouraged hefty logic built into views and complex interactions with data that sort of spoiled the simplicity and grace of my MVC vision.
Looking at the world now I feel vindicated because databinding is indeed granular and simple and, as I mention in my previous post, is the only thing that Microsoft have really retained between Windows Forms and WPF.
I strongly advise that you don't fall into the trap of trying to reimplement MVC on a .NET platform. I saw an example of this just a short while ago when a very competent and sane C++ programmer was given the thankless task of porting an old C++ program that implemented Stingray's MVC pattern to C#. He spent weeks messing with it and then was disturbed to discover that all that effort could have been avoided with a few simple lines of databinding code.
Friday, February 15, 2008
Powering the presentation layer...
Ok, I know this is a tagline for Infragistics but I think they'll forgive me because they are pals of mine. The thing I'd like to expound today is just what is a "presentation layer"?
In many people's opinion, The guys at Infragistics included it seems, this smacks of UI and graphics. For me however, this couldn't be further from the truth. For me, a presentation layer is totally non-graphic and is really a buffer between the data and the graphical layer.
One thing that I have learned over the last, oh, thirty years in the business is that the graphics always change, it's the data that remains the same. Consider the current situation; We have a world full of applications based on the hype of Windows Forms and the reality of WPF looming, well, more than "just this side of" the horizon. What does this mean for the application developer? Yup, you guessed it, a massive re-write of everything. Or does it?
Over the last little while, I have been working in the financial sector where data is old and entrenched in massive databases. These financial institutions however need up to date applications to run their decades old loan deals. Recently, the emphasis has been on windows forms but now WPF is taking the world by storm and people have been wringing their hands about re-writing all those applications again. On many of the projects I have worked on, the presentation layer has been the key to success in migrating applications to WPF. Here's how it works:
The MVP pattern suggests a model a view and a presenter. This is a great pattern if only people could get the presenter bit right. In implementations such as CAB, MVP is really crippled and has a poor definition but with a little bit of work we can have a perfect system in which the model is isolated from the view by a "presenter" that is really a two-way buffer between the UI and the data. I say two way because the presenter must play the role of a data conditioning filter that runs both ways. Here's a scenario for you.
The database of a bank contains reprsentations of money values. the database actually holds the value of, say, 124,000,000 but, because this is a bank and banks don't deal in piffling small change, when a bank agent see's a loan or mortgage he actually sees the numbers 124.0. Traditionally the conversion between 124,000,000 an 124..0 would be done in the view where some clever code resides. However, if this operation is done in the presenation layer and the presentation layer is databound to, say a textbox in the view, then the presentation layer "presents" 124.0 to the view and when the user types in 125.0 the prsentation layer "presents" 125,000,000 to the data model.
An even better example of this is when the presentation layer synthesizes data. Take for example the need for a number to be of a certain colour. In the database we may see a representation of 100,000,000 that is seen in the UI as 100.0 with a colour of white for the textbox background. When the value is -100,000,000 then that value really should show up in bright red. Where is the colour gnerated though? That's right, in the presentation layer. The UI doesn't have to have business logic in it to translate colours, it just databinds the value to the presenter and the colour of the textbox background to the presenter's synthesized colour data.
So now, what does this all mean for the future? Well, when Microsoft introduced WPF they threw out everything that we knew about UI and replaced it with something else. Well, actually, everything except databinding, which, incidentally, they made more powerful. This means than that if your applications had a model and bi-lateral presentation layer then you could rip out the 10% of code that was your old UI and databind in a shiny new WPF UI in a few days and come up smelling of roses.
In many people's opinion, The guys at Infragistics included it seems, this smacks of UI and graphics. For me however, this couldn't be further from the truth. For me, a presentation layer is totally non-graphic and is really a buffer between the data and the graphical layer.
One thing that I have learned over the last, oh, thirty years in the business is that the graphics always change, it's the data that remains the same. Consider the current situation; We have a world full of applications based on the hype of Windows Forms and the reality of WPF looming, well, more than "just this side of" the horizon. What does this mean for the application developer? Yup, you guessed it, a massive re-write of everything. Or does it?
Over the last little while, I have been working in the financial sector where data is old and entrenched in massive databases. These financial institutions however need up to date applications to run their decades old loan deals. Recently, the emphasis has been on windows forms but now WPF is taking the world by storm and people have been wringing their hands about re-writing all those applications again. On many of the projects I have worked on, the presentation layer has been the key to success in migrating applications to WPF. Here's how it works:
The MVP pattern suggests a model a view and a presenter. This is a great pattern if only people could get the presenter bit right. In implementations such as CAB, MVP is really crippled and has a poor definition but with a little bit of work we can have a perfect system in which the model is isolated from the view by a "presenter" that is really a two-way buffer between the UI and the data. I say two way because the presenter must play the role of a data conditioning filter that runs both ways. Here's a scenario for you.
The database of a bank contains reprsentations of money values. the database actually holds the value of, say, 124,000,000 but, because this is a bank and banks don't deal in piffling small change, when a bank agent see's a loan or mortgage he actually sees the numbers 124.0. Traditionally the conversion between 124,000,000 an 124..0 would be done in the view where some clever code resides. However, if this operation is done in the presenation layer and the presentation layer is databound to, say a textbox in the view, then the presentation layer "presents" 124.0 to the view and when the user types in 125.0 the prsentation layer "presents" 125,000,000 to the data model.
An even better example of this is when the presentation layer synthesizes data. Take for example the need for a number to be of a certain colour. In the database we may see a representation of 100,000,000 that is seen in the UI as 100.0 with a colour of white for the textbox background. When the value is -100,000,000 then that value really should show up in bright red. Where is the colour gnerated though? That's right, in the presentation layer. The UI doesn't have to have business logic in it to translate colours, it just databinds the value to the presenter and the colour of the textbox background to the presenter's synthesized colour data.
So now, what does this all mean for the future? Well, when Microsoft introduced WPF they threw out everything that we knew about UI and replaced it with something else. Well, actually, everything except databinding, which, incidentally, they made more powerful. This means than that if your applications had a model and bi-lateral presentation layer then you could rip out the 10% of code that was your old UI and databind in a shiny new WPF UI in a few days and come up smelling of roses.
Saturday, December 08, 2007
Internet rules!
I so love the internet. I messed up my satellite dish today and needed to know where to point it so I found this... http://www.dishpointer.com/
What a brilliant idea! I found that all I need o do is point the dish at a landmark nearby and wiggle the elevation till it locks on. Too cool!!
What a brilliant idea! I found that all I need o do is point the dish at a landmark nearby and wiggle the elevation till it locks on. Too cool!!
WPF FAQ
I am working on my new WPF FAQ which will be available on my site shortly.
Although I know there are many out there, in my new role as a WPF developer I will use it as a target for noting down all those things I find useful during my learning curve.
Hopefully it will benefit others too.
Although I know there are many out there, in my new role as a WPF developer I will use it as a target for noting down all those things I find useful during my learning curve.
Hopefully it will benefit others too.
WPF same-old sameold.
I am currently trying to immerse myself in WPF from a practical and useful standpoint. My usage of this new system has been fairly light and fluffy up until now, I have been puzzled by some of the new concepts, realised that the framework has taken a totally different direction recently and been have wowed by the promise of "A New Hope" or, if you'll forgive me, a paradigm shift.
However, when I began seriously looking into what can be done on a practical level with XAML and how data and XML can be used to build pretty cool applications I find myself coming to the conclusion that its all really business as usual in the world of the programmer.
When you look at XAML and the various cool looking demo applications that are out there you will see in fact that XAML is only as good as the components you can use on your pages and windows. The supply of these components requires programming skills that are firmly based in traditional methods and despite the fact that XAML provides a declarative way of creating an interesting look and feel, when one begins writing a custom control, one is still forced to roll up the sleeves and get to work with good old C# or Visual Basic in the codebehind file.
Certainly XAML is a great way of defining a user interface and incorporating the design elements we need now but the need for strong architectural skills and a supply of high quality controls for all these markup-jockeys to consume is still of paramount importance.
Thursday, November 08, 2007
Problems with source-control and ItemGroup entries in .CSPROJ files
Here's an interesting one that just happened to me.
I work in a ClearCase source control environment and recently had to have access to a VOB from another team so that I could do a bit of trouble shooting.
The problem arose as soon as I tried to compile their code; the source-control complained that the xxx.csproj couldn't be written because it was write protected. This was normal because I hadn't touched anything or made any checkouts.
The problem was that the system seemed to want to overwrite the files that were not checked out.
After much detective work I found that the XML:
was being inserted into the IN_MEMORY copies of the CSPROJ files.
After some detective work in the registry I found that this was associated with something called STextTemplating which has to do with the template system in Visual Studio and seems also to be associated with Domain Specific Languages (DSL)
After more searching I found that it was necessary to remove the following keys:
{B4F97281-0DBD-4835-9ED8-7DFB966E87FF}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0Exp\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924}
After this, the problem went away.
Here is the link I found after about two hours of digging and pain...
http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework/topic61709.aspx
I work in a ClearCase source control environment and recently had to have access to a VOB from another team so that I could do a bit of trouble shooting.
The problem arose as soon as I tried to compile their code; the source-control complained that the xxx.csproj couldn't be written because it was write protected. This was normal because I hadn't touched anything or made any checkouts.
The problem was that the system seemed to want to overwrite the files that were not checked out.
After much detective work I found that the XML:
was being inserted into the IN_MEMORY copies of the CSPROJ files.
After some detective work in the registry I found that this was associated with something called STextTemplating which has to do with the template system in Visual Studio and seems also to be associated with Domain Specific Languages (DSL)
After more searching I found that it was necessary to remove the following keys:
{B4F97281-0DBD-4835-9ED8-7DFB966E87FF}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924}
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\VisualStudio\8.0Exp\Packages\{a9696de6-e209-414d-bbec-a0506fb0e924}
After this, the problem went away.
Here is the link I found after about two hours of digging and pain...
http://www.devnewsgroups.net/group/microsoft.public.dotnet.framework/topic61709.aspx
Thursday, May 03, 2007
2.NET|!2.NET
Arthur C. Clarke once said "Any sufficiently advanced technology is indistinguishable from magic"
A few times recently, I've been in a situation where I just wanted to hold my head in my hands and groan "Noooo not again!! make it stop!!". Why? Well, because even after seven years of .NET people still don't get the idea of what advantages there are in fully embracing the framework's philosophies to create really great applications or components.
Imagine dumping a medieval man into the middle of London. Aside from the obvious initial shock, he'd become used to the idea that cars travelled about without horses attached to them, he could even learn to drive a car. He would become used to the idea of lighting without flames and he'd eventually become a consumer of fish and chips or MacDonald's burgers without necessarily understanding how it all happened or what made it all tick. After his short period of adjustment that went from screaming fits and soiling himself with fear, we would eventually get someone who can function just fine in the environment. Whether he could design a car or grasp the concepts of electricity would be however, a different subject entirely.
This is the sort of thing that happens when someone who is "expert" in 1990's technology gets hold of the concepts of third millennium .NET framework. They become a perfectly adequate programmer, able to apply their concepts of programming to C# or VB.NET and as long as their efforts are contained within a single sealed up application all is well and you can't tell the difference from the outside.
What happens however when that person, however innately intelligent they may be, applies 1990's ideas to .NET architectures and has the responsibility for creating, say, a huge data management framework of industrial proportions? You guessed it. A complete and total disaster that does nothing but make people groan with disbelief.
For me, the best aspects of .NET architecture are the ones that don't fall readily to mind, even if you're a world-renowned C++ guru and have 20 years of experience in your field. For example, the idea that your objects may take part in a design time environment. This was not even a possibility in the old world of C++ but now you should seriously consider whether your objects should at least carry the attributes such as Browsable, Description, Category etc. Furthermore, you should ensure that your object has a type-conversion strategy, should implement ToString correctly, provides a design-time editor, possibly a graphic editor, certainly a smart-tag, some designer verbs and so-on.
When designing an architecture today, we also need to look to current trends in data-binding. It used to be that tying an object to a GUI was a laborious process that required either brute-force, the preferred C++ method, or implementation of some pattern such as Model View Controller (MVC). Any remotely skilled Windows Forms engineer will immediately use data binding which neatly sidesteps these issues. However, the objects in question need to either provide changed events for properties or implement INotifyPropertyChanged. So, I hear everyone reading this beginning to say "Well, if the object is some deep part of a framework and not exposed to the GUI, why bother?" The answer here of course is that data-binding is no longer a GUI only issue. .NET 3.0 and 3.5 already has data binding that can take place between any two properties so that otherwise invisible objects can be bound. This is not only interesting for WPF maniacs but for anyone who has an object that receives input from another.
Finally, meta data and reflection coupled with new type description systems are so powerful that it adds vast new aspects to object orientation that are so outside the realms of the classic Encapsulation, Inheritance, Polymorphism triad that classes have ceased to become immutable definitions and have entered the realms of chimeric virtual objects that appear to be one thing when they are, in reality, something totally different.
If you're an architect and expecting to create a framework for your flagship product by all means pick .NET. Just don't go blundering about like a medieval peasant when you could be using magic instead.
Saturday, February 10, 2007
A strong business case for WPF?
Hot issues in the computing universe include the advent of Vista and the .NET framework 3.0 including technologies such as Windows Presentation Framework (WPF). Even the most disconnected developer will be aware of the hyped images of videos playing on the faces of spinning cubes and photo-albums that float in a plasma-filled void. All very pretty, amazingly attractive to geeks who understand what it takes to do such a thing, but how do you explain the need for early adoption of such a technology to someone who doesn’t see the need for these sorts of things in their application?
Recently I’ve been working in a company where I’m responsible for the GUI end of a complex data architecture and I am faced with diverse problems on a daily basis. Firstly, the company is a large institution with a phenomenal IT overhead. Everything must be certified; everything must be accepted and verified. As a result it’s only recently that the company moved onto Windows XP systems and even more recently that Service Pack 2 has been accepted and even that is installed on a very few machines. Imagine then how difficult it might be to persuade the people in the system to adopt such a new technology as WPF. When we see WPF we see video games, we see spinning cubes, we see applications that are so much fluff and that have little or no use whatsoever for a company that just needs to display values from a database in a grid. A project manager who sees such demonstrations will dismiss them out of hand, indeed, they have.
However, the managers are very hot on the subject of performance. The data architecture I work with has the possibility to swallow and process large amounts of real-time data. This data comes from complex calculation systems that can change a couple of hundred lines on a data grid in a matter of moments. Using conventional systems, the best commercial grid software we can find and every optimisation technique available to us we still see processor consumption rates climbing to the 100 percent mark on simple machines and the 50 percent mark - this is to say one processor totally consumed - on multi-core systems. Why is this? Simply, because instead of using the processor for doing work, we’re using it to paint the constantly changing cells in a grid. Our graphics and our UI are destroying our ability to do work.
Where does this leave us? In order to liberate the processor we need to stop it from drawing the graphics. We still need the graphics so this implies that they need to be managed somewhere else. By the graphics card itself possibly.
Strangely WPF is here with a system that can make even the most bogged-down two dimensional application fly. With the power of graphics processors on even simple display cards today, the rendering of a grid can become a trivial matter, even when it’s data-bound to a constantly changing stream of data.
Forget spinning cubes, forget cards that bounce and shatter in a waterfall of broken shards, forget plasma fields with smiling babies and dogs catching Frisbees. Show the managers in your company the benefits of freeing up those expensive processors for doing real work and leave the graphics where they belong, on the video card.
Sunday, January 28, 2007
What is the most important technology today?
With the recent release of .NET 3, Vista, WPF and the WCF systems one might think that the choice was large. However, from everything I've seen recently the most impressive and important technology of today isn't what one might imagine.
I think that there is only one truly outstanding thing in all of todays new technologies and in fact it's probably one of the most fundamental concepts because, after all, what we do as programmers is normally to enable our users to visualise otherwise cryptic data.
The technology of which I speak is, of course, data-binding.
As an architect of systems that manipulate otherwise boring and complex data, I've found that the method of databinding used can make the difference between a mediochre application and a truly fantastic one.
Data binding techniques are in the process of evolving. Look at the ideas in .NET 3.0 and you'll see that not only can the properties of data objects be bound properties of user-interface objects but just about any property may be bound to any other.
The binding mechanism is also becoming more of a presentation mechanism with the ability to add inline bi-directional conversions to the data so that raw data in a property may be treated in some way before it gets to the user interface.
These ideas may seem to be spurious at first glance. Who needs to bother how data binding works on a deep level? The answer may surprise more than you imagined. Why? Consider this.
For many years, since the early days of MFC and since the work of The Gang Of Four, design patterns have been talked about in the industry and many attempts have been made to implement them correctly. The Document-View model in MFC, the implementation of patterns such as MVC (Model, View, Controller) and more recently MVP (Model, View, Presenter) as used in the CAB (Composite Application Block) have all been the subject of various implentations attempts that were more or less successful.
My own experience with these classic patterns is that the ideas are usually great, the pattern has a logic and a simplicity that suggests that the implementation should render good results but the implementation, when left open to developers who use classic quick-and-dirty methods or just don't understand the architecture, usually falls short of expectations. One of the biggest problems I've seen in many applications is the blurring of the line between the boundaries of the pattern components. The way that we build applications, such as an MFC, Windows Forms or even WPF application, leave so much open to interpretation that developers will often write complex code into a form, dialog or user-control so that the functionality of what should be only, say the view, becomes part view, part controller, part model.
How does databinding solve this problem of interpretation of a pattern and the consolidation of an architecture? Well, the way we use databinding enables us to remove all aspects of business logic from the view and to move the intelligence of the application into the presentation portion where it belongs.
I'm in the process of preparing a number of articles on this subject which I will be posting over the next few weeks. If you're interested in the follow up to these ideas, watch this space.
My own experience with these classic patterns is that the ideas are usually great, the pattern has a logic and a simplicity that suggests that the implementation should render good results but the implementation, when left open to developers who use classic quick-and-dirty methods or just don't understand the architecture, usually falls short of expectations. One of the biggest problems I've seen in many applications is the blurring of the line between the boundaries of the pattern components. The way that we build applications, such as an MFC, Windows Forms or even WPF application, leave so much open to interpretation that developers will often write complex code into a form, dialog or user-control so that the functionality of what should be only, say the view, becomes part view, part controller, part model.
How does databinding solve this problem of interpretation of a pattern and the consolidation of an architecture? Well, the way we use databinding enables us to remove all aspects of business logic from the view and to move the intelligence of the application into the presentation portion where it belongs.
I'm in the process of preparing a number of articles on this subject which I will be posting over the next few weeks. If you're interested in the follow up to these ideas, watch this space.
Monday, July 31, 2006
Sandcastle
I am a documentation freak. I do /// style docs by habit whenever I code and until recently I've used NDoc to generate the final output.
Microsoft have been amzingly quiet about documentation. The old doc generator from visual studio sucked and NDoc seemed to have been its far-superior successor so I was waiting eagerly for a version of NDoc that would do generics and all that good stuff. Sadly, I recently read a post that said that the developer of NDoc was giving up because it was obvious that although it was far superior, NDoc couldn't compete against Microsoft's new Sancastle doc generator.
There are two things here that are a real shame. First, NDoc rocks yet the guy never recieved anything like the amount of support he should have. I mean, a 5 buck donation on paypal from everyone who used NDoc would have allowed him to work on the project full time and finish up NDoc 2.0. Did this happen Not on your nellie.
Secondly, not wishing to belittle the Sandcastle effort in anyway but given that Microsoft has a huge fund of cash available, why didn't they just buy NDoc and integrate it into Visual Studio? I guess that would have been too simple.
Anyway, the Sandcastle CTP is out...
Microsoft have been amzingly quiet about documentation. The old doc generator from visual studio sucked and NDoc seemed to have been its far-superior successor so I was waiting eagerly for a version of NDoc that would do generics and all that good stuff. Sadly, I recently read a post that said that the developer of NDoc was giving up because it was obvious that although it was far superior, NDoc couldn't compete against Microsoft's new Sancastle doc generator.
There are two things here that are a real shame. First, NDoc rocks yet the guy never recieved anything like the amount of support he should have. I mean, a 5 buck donation on paypal from everyone who used NDoc would have allowed him to work on the project full time and finish up NDoc 2.0. Did this happen Not on your nellie.
Secondly, not wishing to belittle the Sandcastle effort in anyway but given that Microsoft has a huge fund of cash available, why didn't they just buy NDoc and integrate it into Visual Studio? I guess that would have been too simple.
Anyway, the Sandcastle CTP is out...
Monday, July 24, 2006
How much does a meeting cost?
I've been working for the last few months for a huge company who shall be nameless.
Managers in this company like to call team meetings so that the team can bring the manager up-to-speed on what's going on and how progress is. The typical team meeting will go on for an hour and a half and there will be between nine and twelve people sat around the conference table basically reiterating stuff that could have been said in e-mail in under five minutes.
The main problem is that the managers themselves are non-technical and have more responsibility for administrative tasks than for getting the product out the door. This company prices all its work in man-days and a manager who called todays meeting was recently heard to say that the team had spent 150 man-days this year on project X and "nothing had been done"
Well, apart from the fact that the whole team has moved from C++ to C#, had courses in Windows Forms, changed the development practices from "useless hierarchical" to XP / Scrum and defined a .net application architecture, each person on the team spends more than four hours a week in meetings.
Half a day per person per week means 8 lost man-days per week. On a six month project, this means 200 man-days lost out of a budget of 2000. This also means paying a developer to sit and do nothing but scribble on a jotter for two-thirds of a year.
Managers in this company like to call team meetings so that the team can bring the manager up-to-speed on what's going on and how progress is. The typical team meeting will go on for an hour and a half and there will be between nine and twelve people sat around the conference table basically reiterating stuff that could have been said in e-mail in under five minutes.
The main problem is that the managers themselves are non-technical and have more responsibility for administrative tasks than for getting the product out the door. This company prices all its work in man-days and a manager who called todays meeting was recently heard to say that the team had spent 150 man-days this year on project X and "nothing had been done"
Well, apart from the fact that the whole team has moved from C++ to C#, had courses in Windows Forms, changed the development practices from "useless hierarchical" to XP / Scrum and defined a .net application architecture, each person on the team spends more than four hours a week in meetings.
Half a day per person per week means 8 lost man-days per week. On a six month project, this means 200 man-days lost out of a budget of 2000. This also means paying a developer to sit and do nothing but scribble on a jotter for two-thirds of a year.
Friday, July 15, 2005
Speed freaks...
I've been working for a client who had a Win32 based application that did some graphics creation tasks for a consumer product. They wanted to update the look and feel of the program and hired someone to create a new application for them. This engineer did a pretty good job but, through lack of personal funds and the availability of a freebie, wrote the application using the C# express beta for C#2.0.
The customer took delivery of the partial code and then discovered that to release it to their customers they'd have to back-port it to .NET version 1.1 and finish up the program. Because of the highly graphical nature of the application and because the original implementation was rather slow they asked me to pep it up a bit.
After solving many of the drawing issues and getting the application up and running we got to the stage where people were installing it to test and everyone who saw it was horrified at the startup time. Some machines saw a 35 second wait between the initial first click and the appearance of the application window. They had never seen a fat .NET app before.
There were two problems with the whole scenario. First, the cycle was to install a new copy of the app, to click the application icon and sit there with a stopwatch waiting for something to appear. This meant that every time they saw it it was going through the process of creating the native image copy for the application cache. Secondly, even though the application had a splash screen this was a part of the application that needed JIT compiling too so often it didn't appear for some time. This encouraged the user to click a second time.
To solve these problems I've tried two things. To make the splash screen appear instantly I wrote a small program launcher that just displayed the desired image and then used Process.Start to launch the real program. This gives the user the feeling that something is happening and discourages them from clicking the icon again and again. Secondly I wrote a custom installer clas that used ngen, the .NET framework native image generator, to create the native-code compiled version of the program at install time. This meant that the first run of the code already had the native image in the cache and reduced load times to the barest minimum. On a test machine I got the load time from 30 seconds down to 6 seconds total using this method.
Subscribe to:
Posts (Atom)