Designer's are *still* bad, M'kay?

The main thrust of the latest post over at fairview is that code designers, code generation tools, etc are bad.

Well, I agree, mostly.

My biggest hangup with the Visual Studio designer is it's destructive nature - as discussed before.

I see where Sam's coming from, too. But just because GUI designer tools aren't living up to their potential is no reason to dismiss them. And yet...

Visual Studio is surprisingly schizophrenic in this area - it's quite difficult to write code wihout some form of graphical helper butting it's way in sometimes (hiding files from the user is a particularly bad habit of VS.Net), and I've seen some demo for the new intellisense helper, and it looks way to complicated, with filters on member type, protection level, object type - stuff I might only ever use when I'm investigating a new class.

The form designer is poor at outputting maintanable code, and the idea of writing a whole application just using the GUI designer is laughable, given its shortcomings.

But sometimes, it is nice to drop a control onto a form and see all of the tedious stuff done for you... but I guess this is something that could be added to the code view.

I spend most of my time when I use a new PC hiding all of the GUI stuff, making sure everything defaults to code view, then hiding all of the other windows so the code view occupies almost all of the screen. I think, however, that one reason I do this because I distrust the Visual Studio designer based on experience, otherwise I might be happy to drop controls onto the page, then switch to code view to make everything just so. I could never live with just the designer though.

The Petzold article is fantastic. Over 60,000 properties and methods in Framework 2.0? Wow! I'll store that one for the .Net quiz.

Developer Day

I missed the Developer! Developer! Developer! day. Again.

There's a good review over at Sam's blog:

Sam's Review of Developer! Developer! Developer!

I know there is also a regular event held in London for the dotNet developer user group, website here: London DNUG

Now I've linked to another post on Sam's blog, will this increase the worth of mine...? :-)

My Blog is worth...

My blog is worth $999,999,999,999.99
How much is your blog worth?

Although I may have overestimated (a little).

:-)

XPathNavigatorReader

I've recntly worked on a project where I've replaced the existing XML-XSLT engine with one that is more performant. The existing system took a large Xml document, in some cases larger than 80Mb, and performed multiple XSL transformations against it.

It was written in VB6 and used MSXML. The main work was done by the transformNodes method, but several steps were involved before hand in reaching this point - generation of the XSLT based on the main XML for example. The output from these transformations usually resulted in tens, even hundreds of HTML documents.

It wasn't performant, and it used alot of memory, a consequence of DOM based processing, especially for large documents. Typically processing time would be in the minutes, tens of minutes in some instances. As the process was an asynchronous publishing system triggered by results becoming available, performance wasn't the most important thing (except that if lots of requests came in at once, the system would *really* slow down, and there were occasions where a client would have expected some results to be available, but they hadn't finished yet).

Analysing the application, I could see that a major performance hit came from loading the Xml documents into memory. C# is the main language I work with these days, and I throught I'd use the XPathDocument class along with the XsltTransform class. Simple choice, really, as the process is about transforming the document, so I don't need a DOM - I'm not altering the original Xml tree in any way.

My first experiments got the process down to performing about 700 XSL transforms in 27 seconds. This is a vast improvement, and memory usage was lowered too. Still, I could see that a lot of time was spent in moving between nodes using the MoveNext() method. Also, awkwardly, I still needed to get at the Xml of certain nodes within the document, something that the XPathDocument/XPathNavigator combo doesn't really cater for easily.

I did some research and discovered the XPathNavigatorReader (in the MVP.Xml namespace). Apparently, it adopts many of the features of the Xml classes found in Framework 2.0.

It's cool, as it allows me to efficiently move through the XPathDocument and get at the Xml when I need too. Implementing this over the XPathDocument further increased performance - about 700 transformations in 3 seconds.

Which was nice.

Faster Google. Kill! Kill! Kill!

An interesting coffee break read on news.bbc.co.uk.

The comment about why there is little UI homogeneity between Google apps was an interesting one - how the culture has brought about a diversification of UI's - with the main suggestion being that, at least at first, that a google app is about bringing an idea to fruition. For me, a Google app is recognizable as a Google app because of the Google logo - instantly distinctive, as well as the colour scheme. Most Google apps have an ergonomic hook for me - maps the scrolling, suggest the immediacy, gmail the keyboard shortcuts...

I was also amazed by the Ballmer-Google thing. I mean, is that conversation becoming public domain kind of embarrassing? Throwing a chair? Is it even true? Or is it jus a ploy by Kai-Fu Lee's legal team as part of the Microsoft-Google dispute over his employment at Google?

Microsoft could kill Google. Google could kill Microsoft. And yet, owning the desktop - is that more powerful than owning the browser? And Microsoft kind of own both, but...

Google seem fast already? Faster? We'll see.

Jagged Little Pill

In yet another seemingly (well, actually, actually) pointless posts about stuff I like, I thought I'd mention another of my favourite albums. As the title indicates, it's Jagged Little Pill, by Alanis Morissette.

In particular, I recently bought the acoustic version (from Tesco, where I seem to buy a lot of music these days.), and, I was impressed. It sounded fresh, different, and alive.

Great album. My favourite track is "Hand in my Pocket." Don't know why.

GMail to GoogleMail

Hmmm...

http://www.theinquirer.net/?article=27051

MP3 Players

I remember letting a friend at University know that I liked R.E.M. They loved R.E.M.

I never thought I would be a massive fan, though, liked to listen to their music, never thought I'd be as devoted as they were (who, it must be said, is very unlikely to be reading this).

I was going through my CD collection last night, when I noticed something strange. I have a about 8 million R.E.M. CD's! Well, not quite that many, but all the albums, a few bootlegs and some other stuff. Arghhh, I've somehow managed to become a compulsive album collector!

However, the main thrust of this post is not to reveal that I own the Cheeky Girls CD (although I don't, no, really, I don't), but to mention how awkward it is to transfer all my CD's across to my MP3 player. It's a pain in the backside. In. Rip. Tag. Transfer to Player. Out. Repeat with next CD.

Sonic Stage (Sony's music management software) is a fine example of how to write a piece of software based on how you think someone will use something without ever using it yourself. Unghhhh.

And now I've noticed something else. Now it's on the player, the music has lost something. It's too immediate. Gone is the joy of selecting a CD at random, pulling it off the shelf. Instead, I now have to navigate through a UI that isn't really any good at managing large number of songs and select the music I want to hear with a button press.

Ho hum.

How not to write your documentation (1)

I'm developing some software to run under a 3rd party infrastructure.

This infrastructure supports components written in a variety of languages. Java, .Net, C++, blah, blah.

Unfortunately, when the company who decided how they were going to write their documentation, they decided that they would try and produce 1 document, covering how to do each bit in each language.

They've ended up with a mess. .Net implementations next to java implementations next to... for each and every bit, or well, for each and every bit where they've felt like providing an example in your language. Well, if you can do that bit in your language, of course.

It would have made everybody's life easier if they'd produced separate documents for your language. E.g. a .Net developers guide, a Java developer's guide, and so on.

Grrrrrrrrr.