I’m currently working in an assingment as a Business Analyst, I view it as a bit of a sabbatical from proper work like career development for development team members and proper techie stuff like web architectures, knowledge management etc. Anyway, whether I see myself working long term as a BA, I still think it is an essential role in the development of solutions using technology.

Unfortunately it is also a bit of a thankless task if you have any inclination to doing it “properly”, for instance the term analysis paralysis comes up. Two options ring home in the wikipedia description, bureacracy and inexperience. What is unclear is the particular area of inexperience they mean. Is it lack of time in the role? Is it lack of business awareness? Raw analysis skills, or time management?

The wikipedia has a good section on requirements analysis which discusses some of the issues, some of which although recognised over two decades ago are still around in the industry.

Don Box has made an excellent point about XAML. A few years ago the PDC 03 attendees were keynoted with an introduction to XAML in one of the WinFX presentations.

At the time I didn’t quite get it. The dudes that did the whole UI thing with xslt and well formed xhtml weren’t going to get bogged down doing all that windows stuff in xml. And the dudes that I know could kick about in C# or whatever with all the Javascript crafting they could do.

So we come to Don’s point. He claims (in his usual style) that 100% of the users will be using a domain-specific editor. I.e. all the UI dudes will be staying away from XAML and doing it in the editor. Excellent, it makes sense now, but raises the question of why we got hit with the raw XAML experience so soon after breakfast.

I guess it must have been recognition of the audience at the PDC – loads of techies, loads of programmer and developer types. The people planning the programme content probably thought “We’ll get the specification out and get the developer types putting a nice editor on the front.”

Of course, I’ve now got a bit of catching up to do. This kicks a few questions into my mind, which I may answer in posts or I may leave hanging.

1. Is this the only way of doing “windows” UI in longhorn, i.e. to build the pages associated with the application?
2. Or do we have the .NET style of forms, build up by inheriting all those form object classes?
3. Do we still have the same kind of code compilation going on in the background with the UI?

This just reflects my ignorance on Longhorn, and more specifically WinFX, but what the heck – I’ll try and catch up. I think I’ve missed the changes between the UI and the OS.

Spence is over in Seattle attending the MVP Summit, and getting grief for keeping it all quiet. Too right too, tell us more!!!

If you don’t know, Spence is an MVP for Content Management Server and is appearing at a CMS Newsgroup near you, of course thats when Stefan isn’t diving in there first.

I was attempting to pull together a “master” list for my CV the other day. The company that I work for relies heavily on them for the bidding process, so compiling and keeping them up to date is a necessary thing. That process of rediscovery reignited thoughts of my experiences with Microsoft Commerce Server.

And hot off the heels of his visit to the PDC, Spence posts a history, perspective and view of where Commerce Server is going.

Frankly, until reading Spence’s article reminded me, I’d forgotten about the Merchant Server heritage. As his post describes, Site Server introduced a michmash of products, with its inherant nightmare of licencing and installation. Rolling forward to the last PDC, which I was priviledged to attend under the old Cedalion banner, nothing at all was said about Content Management Server, Commerce, MSIB, whatever. The only inference from the introductions to .NET 2.0 was that the mixed feature bag spread over the MSIB products was going through another Microsoft checkpoint, and the essential bits being pushed down to become standard platform features.

Roll on another few years, and release date realities mean that we see what is actually going to appear in .NET 2.0 with regards to identification, personalisation etc. But back to my title, Commerce is still out there on a limb and is likely to do so for a while, which in some ways is a shame. It is a shame because learning how to work with it can be a real pain, and consistency in the other Internet products just exascerbates that. On the other hand, it is a relief that all that investment getting the most out of Commerce features will still pay off.

I’ll study the materials out there on Commerce 2006 and I’ll post again if I think I have been talking Baloney, or form some other opinions.

Kevin’s recent post about the pain of ASP reminded me to post about a recent system rebuild I had to do recently. I had to get a line of business application up and running, with data backup only and a new clean hard disk.

The application concerned is part of company history where I work, was created many many years ago by the founding director and the small team of developers that made up the company at the time. Well, history is history and he and the original devs are distant memories for those of us still around.

The application could be described as a special stock control system, not for car parts but for a section of a financial service that has to be strictly controlled. At the time it was conceived, the architecture was designed with the latest Microsoft Web technologies, bundled together under the excellent name of the NT 4.0 Option Pack. This included Microsoft Transaction Server and IIS 4.0. (The download page cracked me up – remember when Microsoft Servers supported intel and alpha?)

The application itself in total uses NT 4.0 Server, IIS 4.0 (Active Server Pages), Microsoft Transaction Server to look after the VB5.0 middle tier component, SQL 6.5 looking after the data side of things and a service written in C++, listening on a named pipe for print commands.

The application has “history” everywhere you look. For one thing, it comes with a support contract that has held since the application went in to production. This provides challenges when naturally the developers these days are all C#, ASP.NET, all gearing up for 2.0 of course and would probably start a wee headache having to work with VBScript. I’m just glad off the back of that that the two compiled parts of the application have remained intact, I’d hate to have to recompile with those tools.

For those of you who haven’t had to deal with these things, this means that you have to fix an application written by someone else in a technology you haven’t used for 5 years. That is if you were working 5 years ago!

Another part of the history is that the system is now only single user. We have a classic web application; IIS, Middle Component, and DB  all sitting on one server, the same machine that the user now sits down to. And to call it a server is going a bit far, it runs on an old Compaq desktop with a tape drive. A machine so old that getting parts is a nightmare, and the new RAM it recently got was cannibalised from other old machines failing. Although the architecture is over-engineered for a single user, it was an excellent opportunity at the time to explore the technology, and the original plans involved several users accessing the web application over the network. The web setup also gave opportunity for the customers of the company involved to access the application directly, giving an element of self service. Unfortunately the great plans didn’t come together, and quite terminally. I’m not sure of the exact reasons, but the application isn’t even allowed on the network, so it now sits on its own chugging away.

The rebuild was interesting. For one thing it was a hunt in the office to track down the base CDs, NT4.0 Server, NT 4.0 Option Pack, and SQL 6.5. You tend to hit daft stuff like boot problems etc when working with the combination of an old machine and old o/s. I ended up building the three boot floppies for NT, and working from there. I found the cd-writer on my laptop was a godsend, moving the various service packs and application parts on to that was excellent. I found to my disappointment that there was only a token-ring card in the machine, so no use in these days of Gigabit ethernet!

Thank goodness I had taken copies of the application files a few years ago when the disk had been flaky, these could be recopied back on to the machine and the rest was configuration and dependencies. I found the two and half days getting it back was a mix of triumph and disappointment, but I got it done. It developed into a three hour cycle of problem discovery and fix. It was a good opportunity to ponder the improvement in Microsoft software over the years. The installation of the NT Option pack wouldn’t complete properly and it was the old technique of applying the latest service pack that got it working. I’d forgotten how challenging NT4 could be straight out of the box, it wasn’t just all those install / deinstall cycles that fragged things.

The rest was ok when you knew the idiosyncrasies of the various bits. There was an old setup wizard package with the dependent rdo files packaged with the component, so that was the only way of getting the VB component on and working. Then I deregistered that and put a newer version on. Adding a service is harder than it looks, in the end I found that the registration routine was part of the executable itself. Otherwise, you are relying on the NT4.0 resource kit to give you the “add a service” command line util. Then a small tweak to make sure the service account was correct.

So, got the app together in the end, restored the tape backup and then bang – the application onsite hit an update problem. Cue some major head scratching. I couldn’t get onsite due to other committments, so cue a session in front of my laptop with the source code out of sourcesafe, mobile phone on and bluetooth headset stuck in my left ear.

We were getting a javascript error on an update. That happened after hitting a button above a blank screen. Quick look at the code, put in some rubbish to kick the validation in to check the code was running, and the right error message came up, so it wasn’t that. The blank screen is a clue of course, so do a “view source” in IE 4.0 to see if the page really is blank. There was the error, not coming through to the browser because it wasn’t valid html. This indicated a syntax problem in an ADO update. The update involved a table with a date column – incorrectly formatted date. Check the locale – US English – drat! The date formatting in VBScript is pretty rudimentary, coming down to either long or short, and wholly dependent on the context. You can get really twisted up working from ASP through the layers trying to establish the locale, and in the old days used to try to write my own functions to get round any internationalisation issues. Thank goodness this is taken on properly in .NET and is also considered appropriately in the development process. So the fix on the box was to change the system locale to UK English, but doing that needs the system CD – on the other side of Scotland.

Hats off to the chap who was onsite and on the other end of the phone who made arrangements to get the CD, but another reminder from him, copy the system CABs on to the machine concerned, for daft stuff like that, and also recent service packs. The recent OSs are a lot better, but system guys are a lot better at remembering the field practice like that.

So, application running again, support contract still going, but I now know how to rebuild the thing. Phew, time for a rest.

Not my rant, but Spences. Check out post 1 and post 2 for the latest.

I have my sympathies with him here. Having worked for Microsoft Partner orgs, I’ve worked with a lot of devs that start each project by unrolling the current copy of Visual Studio, SQL Server, a bit of IIS and go from there. They might reuse components between projects, you know the components – they are called ADO.

Show some of them an application server and fine, they’ll install it and the documentation set. Then they notice SQL Server as a prerequisite, then they fire up enterprise manager and go straight to the stored procedures. On a bad day they hit the tables direct. On another bad day they fix the stored procs.

MCMS, Commerce Server, Sharepoint they all get it. I guess SMS doesn’t because devs don’t get near that sort of stuff.

Spence calls them codeheads and I agree, I grew away from this early on when I was in application development. Frankly I got fed up taking all the support calls when I was on my new project and the old stuff was hanging around. A bit like kev’s closing comment in Spence’s second post.

I can’t believe that MS missed this out from the original list, but Barry shows how to get asp 2.0 to recognise the w3c validator and deliver compliant xhtml.

Don’t know about the w3c html validator? Shame on you!

Ok, run this site through it and it barfs – such is, I’ve done compliant stuff on other sites 🙂

And yes, run idunno through it and it passes. Good dogfood.