A grey water experiment

We are constantly told that investing in a water butt to water our gardens is a good thing, it saves water and hence the planet. What is never mentioned is the fact that when you need it most, your water butt is probably not going to be much use to you. When it hasn't rained for several weeks and the inevitable hose-pipe ban is in place, you water-butt won't have a drop of water in it. Because of this, my water butt isn't getting filled up with rain water. Although the general consensus seems to be that using grey water for watering your garden may not be a good idea, as ever I decided to ignore any advice given to me and hooked our water butt up to the outlet from our bathroom. I'm not sure all houses are configured like ours, but the used water from our sink and bath goes out through a couple of pipes into a drainpipe so using this for the water butt was very simple.

And it seems to work fine. The water can smell a bit, but it doesn't seem to kill our plants and we can water the garden without feeling any guilt. One thing, remember not to wee in the shower... Although I'm sure you'd never do such a thing.

More on JScript exceptions

I don't know much about JScript, so when I need to find out anything I head off to Google. So that's what I did when I wanted to know about throwing exceptions. Almost every example I've seen shows something like - 

throw "something went wrong";

Initially I thought this would be wrapped up as an exception by the JScript runtime, but it turns out it is actually a string that gets thrown. Which may be fine in some cases. The problem comes when you want to catch exceptions. If you want to catch all exceptions thrown in a bit of code (yeh I know, bad idea, but this is JScript not software engineering...) then things will get complicated. The runtime will throw exceptions but your own code is throwing strings, so you have to deal with them differently. Turns out the solution is pretty straighforward -

throw new Error("something went wrong");

Now everything is an exception and life is good.

As a side note, I've not considered throwing anything other than an exception before. C# doesn't allow it, although I guess IL probably does since it needs to support JScript.NET. Delphi partially allows it, you can throw any object you like but not strings since they aren't proper objects in the Delphi world. But it's not clear to me why you'd ever want/need to do it...

The new Google Analytics

So there's a new version of Google Analytics available which is lovely and shiny and new. But they seem to have removed the ability to show data by month or hour. Monthly data is useful to get an overview of how traffic is increasing/decreasing over time, since daily data is too volatile. Hourly data is great to see what's happening on your site today.

Why I'm not using UAC

Lots of people keep saying I should switch User Access Control on. So I thought I'd give it a try since I wanted to see how painful it was or if it was actually not so painful after all. And of course I'd like my software to run with UAC enabled without causing any issues.

But here's the problem. Vista is already screwed up on my machine, what with no sound, a SonicWall VPN client that screws up TCP/IP and complete machine freezes every couple of days. And UAC makes it even worse! Internet Explorer has some serious problems when UAC is enabled. It won't print, links that open new windows don't work and the dropdown menu on the back button doesn't work. Explorer always opens folders in a new window, even though it is set up to reuse the same window. Lots of applications won't work at all unless I run them as administrator (Visual Studio being the obvious example) which rather defeats the point of UAC. And these are the problems I've found after using UAC for about two days so there are bound to be more.

And of course I've not even mentioned the annoying dialogs that appear fairly regularly to disrupt my workflow.

So in principle using UAC may be a good thing and dogfooding it constantly with my own code would be a nice thing to do, but in practice it is too painful and I'm putting it back in its box until SP1 comes out. 

How the web was won

In one of my previous jobs I was responsible for helping to develop a native Windows client. At the same time, a web client was developed by another team. Although the native client had some advantages (it was much quicker and generally more reliable*), the web client was much more successful. I suspect this was mostly down to the deployment issues you have with a native Windows client. Even now in a world of ClickOnce deployment, web clients are still preferred by a lot of customers.

But one thing that has become apparent to me since doing more integration work is that web clients also have one other major advantage over native clients. Whether you intend to or not, when you develop a web client you get a plugin architecture for free. Doing the same thing in a native client takes a lot of thought and development time, but anybody can hack around with a web client to make it look like they want or do what they want, via CSS, Javascript or even server-side hacks with some systems. Yeh, these hacks may well break between releases, but it still makes web stuff very attractive to integrators. To do the same thing in a native client would likely involve going back to the vendor to ask for a change in functionality or an extensibility point where code can be plugged in, which might take months, rather than an afternoon of fiddling around. And that I reckon is the killer reason why the web has won.

* This was no reflection of the development team working on the web client. It's just that, all other things being equal, writing a native Windows client is much simpler than writing a web client.

Virtual Earth vs Google Maps part 3

Many moons ago I tried out Windows Live Local (now called Virtual Earth I think) and decided it didn't meet my needs since it didn't show any London tube stations or train stations which made getting round London kind of difficult. I checked it out again today and it now has got tube and train stations. This is actually a step ahead of Google Maps that only show tube stations. However it seems to be a bit buggy currently since sometimes stations appear at one zoom level, disappear when you zoom in, then re-appear again after more zooming, which I presume is not by design. Check out Herne Hill.

So finally these Web 2.0 sites have almost caught up with Streetmap, which I don't think has been updated in about 5 years. Kind of shows up the 'we move in a fast moving industry' mantra as a complete lie.  

Even more on tick marks in HTML

It's always the seemingly simplest probems that have the most long-winded solutions. So my last post was wrong, although that solution worked in some HTML docs, as soon as I switched to HTML 4.01 FireFox started showing extra crud, as you'll notice if you're viewing this in FireFox. So here's a solution for tick marks in HTML 4.01, still using conditional comments, which works in IE6, IE7 and FireFox 2, probably...

<![if !IE]> &#10003;<![endif]>
<!--[if IE 7]> &#10003;<![endif]-->
<!--[if lt IE 7]> <input type="checkbox" disabled="disabled" checked="checked" /> <![endif]--> 

And to complete the whole thing, here's an XSLT template to put a tick mark in your HTML output.

  <xsl:template name="outputTickMark">
    <xsl:text disable-output-escaping="yes">
      &lt;![if !IE]&gt; &#10003; &lt;![endif]&gt;
      &lt;!--[if IE 7]&gt; &#10003; &lt;![endif]--&gt;
      &lt;!--[if lt IE 7]&gt; &lt;input type="checkbox" disabled="disabled" checked="checked" /&gt; &lt;![endif]--&gt;
    </xsl:text>
  </xsl:template>

and here's a tick mark that might work this time.

✓

By the way, I found this article on conditional comments particularly useful.

Update: The absolute final word on this subject is here

More on tick marks in HTML

My original post about displaying a tick mark in HTML is one of the more popular hits on this site. This fact and the increasing usage of IE7 and FireFox drove me to come up with a nicer solution than the one proposed there (using the lowest common denominator checkbox input field).

Internet Explorer supports something called conditional comments. Using these you can serve up different content to different browsers directly in your HTML, rather than doing funky server-side things. I have to use this approach since I'm generating a static HTML file. So here is the markup -

<!--[if IE 7]><!--> 
&#10003; 
<!--<![endif]-->
<!--[if lt IE 7]>
<input type="checkbox" disabled checked>
<!--<![endif]-->

The if IE 7 comment will be rendered by IE7 and any other browser. The if lt IE 7 comment should only be rendered by IE6 and below. I've tested it in IE6, IE7 and FireFox 2, which covers enough bases for my needs. And here is the output, which hopefully should show some kind of tick mark.

✓

Update - there's a more up to date and correct version of this available here

JScript try catch syntax

I alway forget the syntax for JScript exception handling and searching on the web always seems to bring up the wrong thing, so here is an example as my own personal reminder.

    try
    {
        // do stuff
        return "blah";    
    }
    catch(e)
    {
        return e.message;
    }

Yeh, I know, I should be able to remember that... I blame it on the crap JScript editors, none of which provide the mental crutch of code completion.

Remember too, JScript requires the e, you can't use catch().