All Change

by david 10/4/2008 11:46:33 PM

So it’s been a while since I blogged, but not without reason – I’ve returned to the world of permanent employment.  After a year contracting and generally planning for world domination a perm offer came along that seemed too good to turn down.

I’ve been working at Conchango for about 2 months now and already worked on some great projects.  I first came across Conchango when I was at Avis; I was looking to help bring in a structured software process and after reading Ken Schwaber’s brilliantly concise book on Scrum decided it was the way to go.  Long story short, I did my Scrum Master certification at a course organised by Conchango and ended up using their TFS Scrum add-in.  Being a big fan of Scrum myself, I had unwittingly become a fan of Conchango too and the Scrum goodness they were spreading, so when a job came along with them – it was too good to turn down.

As for what this means for this blog I haven’t entirely decided.  I still have a number of side projects which I intend to pursue and blog about here as time permits, quite how much time will be permitted remains to be seen.  What’s more I now have a blog on Conchango’s blogging site too: http://blogs.conchango.com/davidwynne/ it is, as yet, devoid of content but I have a pretty cool post up my sleeve to kick things of over there so watch this [read: “that”] space.

StyleCop Goes Public (finally)

by David 7/30/2008 2:37:00 PM

One of the things I missed most from my days at MS was StyleCop - a simple (internal) tool to make following coding guidelines second nature and end all (read: "most") arguments about whether your constants should be uppercased or not (etc).  In a nutshell StyleCop plugs into VS.Net and gives you build errors if it detects your code is not conforming to the configured coding standards - simple.  A silver bullet for enforcing coding standards across a team.

It's been more than a couple of years since I moved on from MS, but in May they finally released it to the masses (thanks to Howard for the heads up on this).  There seems to have been some confusion over the naming; initially being released as Source Analysis and then reverting back to StyleCop hence URLs still refer to Source Analysis.

More info here:

.Net RegEx Tools

by David 7/30/2008 2:13:00 PM

Regular Expressions tend to be one of those things in development that are rarely mastered, but rather cobbled together or "borrowed" at the point you know what you want to do is best accomplished with a RegEx, but you don't quite have the smarts to write and test the full expression yourself.  I've been trying to improve this personal trait of late, by going back to basics and learning the syntax properly from the basics up.

Anyone doing the same or simply authoring a RegEx will want a tool to help.  I've been using Rad Software's Regular Expression Designer and it's pretty good (and free).  Firstly it's all about .Net RegEx's (a lot of tools are not) and it has a pretty handy Language Elements panel that breaks down the various language elements, allowing you to easily insert them into your expression - perfect when you can't quite remember the correct syntax.  The UI layout can be a bit funky, but I can live with that.

If you're on the move and/or need something quick and simple - then Derek Slager's online .Net RegEx Tester is also pretty handy.

MobileMe teething problems

by David 7/25/2008 11:08:00 PM
Despite Apple taking a side swipe at MS with their new MobileMe service - it seems MS are not the only ones to occasionally release things when perhaps they could do with a little more testing...

Tags:

Windows

Off-Topic: Half Life 2 Physics Engine

by David 7/25/2008 9:45:00 PM

I've been playing Half Life 2 lately on my 360 and have been pretty impressed with the physics engine, but this was so amazing I had to take a picture.  I shot this poor fellow from a mile away using the telescopic scope on the crossbow.  When I finally made my way across to his location I was amazed to find that the crossbow arrow had gone through him and lodged into the bridges scaffold work pinning him up of the ground.  Impressive stuff!

   

 

Why haven't I got Vista SP1?

by David 7/17/2008 11:32:00 AM

I've been reading up on the ADO.NET Entity Framework - the latest preview of which has been released as part of the VS08.Net SP1 & .Net 3.5 SP1 Beta.  As has become expected, ScottGu's done a detailed job of explaining exactly what's in it.  I was going to install it and play around, but Scott notes you should have Vista SP1 installed first:

"If you are running Windows Vista you should make sure you have Vista SP1 installed before trying to install .NET 3.5 SP1 Beta.  There are some setup issues with .NET 3.5 SP1 when running on the Vista RTM release.  These issues will be fixed for the final .NET 3.5 SP1 release - until then please make sure to have Vista SP1 installed before trying to install .NET 3.5 SP1 beta."

I wasn't entirely sure I had SP1 installed.  It was RTM'd in Feb 08 and I have my Windows Update set to download automatically, but I hadn't seen it listed as available to install.  Start > type "WinVer" > Enter will being up the About dialog and give you that answer.  Version 6.0 (Build 6000) if you don't, Version 6.0 (Build 6001: Service Pack 1) if you do.  I didn't.  Pour quoi?

The full story can be found in this KB article - but the headlines are essentially:

  • Vista SP1 will only be offered in Windows Update if all the drivers you have installed are compatible.
    • If Windows Update is displaying optional drivers to install, select them and see if SP1 then appears.
  • There are a number of drivers that aren't compatible, if you have them - you won't see SP1.
    • The KB article lists them; check your manufactures website for an update.

For me; I needed to install an optional display driver via Windows Update and update my soundcard driver via my manufactures website.  SP1 then magically appeared in my Windows Update list.

Apple disses IE7

by David 7/15/2008 10:59:00 PM

Try browsing to Apple's new online sync service (http://www.me.com) in IE7 and you'll get the following message:

 

Ouch.

LINQ to SQL Query Visualizer

by David 7/15/2008 9:25:00 PM

When you start looking at LINQ to SQL you'll no doubt be a little concerned as to what SQL is being generated for your queries - especially when it comes to debugging.  By default when you hit a breakpoint in your code and hover over your return value you'll see the SQL that was generated:

Cool - but when your queries get more than just a little complicated this ain't gonna cut it.  Luckily, if you installed the samples when you installed Visual Studio you'll have a Visualizer in your midst that can make life much easier.  Find the CSharpSample.zip file in C:\Program Files\Microsoft Visual Studio 9.0\Samples\1033\ and extract the LinqSamples\QueryVisualizer directory within it.  Follow the ReadMe.html contained within to get it setup.

Next time you hit a breakpoint and hover over your returned variable you'll get the visualizer magnifying glass, clicking it brings up a new dialog that not only shows the SQL that's been generated but also allows you to execute it - bonza!

 

Vista Gadgets Part 2 – Script, Settings and Events Too!

by David 6/12/2008 2:33:00 PM

In Part 1 we made the simplest gadget one can imagine to demonstrate the basic moving parts.  In Part 2, we’re going to keep things simple and build on the code from Part 1 to demonstrate how to introduce some script and settings.

When it comes to functionality you’re going to deliver that using JavaScript, what’s more you get access to a gadget API (again via JavaScript) that gives you access to a multitude of functionality and system properties such as file, network and OS information – it’s the ability to build on top of this API that gives most gadgets purpose.

To demonstrate how to incorporate JavaScript and settings, we’re going to create a settings fly out that allows the end user to specify what message to display, lets start by writing the code that get’s our message displayed dynamically.

  1. Open Windows Explorer and browse to: C:\Users\ [User] \AppData\Local\Microsoft\Windows Sidebar\Gadgets\jacksTest.gadget that we created in Part 1

  2. Open jacksTest.html and add an empty DIV within the <body></body> tags:

    <body>
        <div id="messageDiv"></div>
    </body>

     
    This gives us a container to target, in which we can place our message.

  3. Create a directory called scripts.

  4. In the new directory, create a file called jacksTest.js

  5. Add the following content:

    function OnInit()
    {
        messageDiv.innerHTML = "Coolio";
    }

     
    This is basic JavaScript, but notice we can refer to our DIV without needing to use the document.getElementById() function.

  6. Return to jacksTest.html and add a reference to our script file within the <head></head> tags:

    <script type="text/javascript" language="javascript" src="scripts/jacksTest.js"></script>

  7. Now hook-up the OnInit() event handler to the onload event in the <body> tag:

    <body onload="OnInit()">

    Save everything and try re-adding the gadget, all being well it should now say “Coolio” instead of “Hey Jack!” – this being the case our message is now being set via code.  Eventually we'll be able to pull the value from a setting, so let’s move onto creating our settings fly out.

  8. At the same level as jacksTest.html, create a new file called jacksTestSettings.html – this is the UI host for the settings panel.

    This is going to follow the same pattern as jacksTest.html with it’s own style sheet and JavaScript file, with that in mind we can go ahead and put in the references to these files, which we’ll create in a minute and hook-up the onload event.

    <html>
        <head>
            <meta http-equiv="Content-Type" content="text/html; charset=Unicode" />
            <link type="text/css" rel="stylesheet" href="css/jacksTestSettings.css" />
            <script type="text/javascript" language="javascript" src="scripts/jacksTestSettings.js"></script>
        </head>
        <body onload="OnInit()">
            Message:<br />
            <input type="text" id="messageTextBox" />
        </body>
    </html>


  9. Create a file called jacksTestSettings.css in the css directory with the following content:

    body
    {
        width: 300px;
        height: 80px;
    }

    #messageTextBox
    {
        width: 200px;
    }

     
  10. Create a file called jacksTestSettings.js in the scripts directory with the following boilerplate code:

    function OnInit()
    {
    }


    We now have all our components, we just need to tell our gadget which file to use for the settings panel.  It would seem logical that this went in the manifest, but it doesn’t.  Instead you have to assign it to a static property in the API when your gadget loads.

  11. Open jacksTest.js and add the following line to the top of the OnInit() event handler:

    System.Gadget.settingsUI = "jacksTestSettings.html";

    Save everything and try re-adding the gadget.  Hover the mouse over the gadget and you should now get a spanner icon underneath the close x; click the spanner and the settings panel we just created will fly out.



    Typing something into the message text box doesn’t accomplish anything at this point, we need to write the code that will persist values entered in this box and also retrieve them to display in the main gadget.

  12. Gadget settings are basic name/value pairs written/read via the gadget API.  They are always stored and returned as strings.

    Return to jacksTestSettings.js in your editor.
    The gadget API exposes an onSettingsClosing event which we can hook an event handler up to.  In this event handler we can manage the saving of any alterations to the settings.

    In the OnInit() event handler, add the following line:

    System.Gadget.onSettingsClosing = SettingsClosing;

  13. Now let’s create the SettingsClosing event handler, add the following function bellow the OnInit() handler:

    function SettingsClosing(event)
    {
        if (event.closeAction == event.Action.commit)
        {
            System.Gadget.Settings.writeString("message", messageTextBox.value);
        }

        event.cancel = false
    }


    This code will take care of storing the value entered in our textbox if the user presses OK.

  14. Return to jacksTest.js where we’ll handle retrieving the settings value and display it in our gadget.  We need to handle two events to accomplish this; the initial load, which we’re already doing with the code in the OnInit() event handler, albeit hard-coded at the moment.  Secondly a new event triggered when the settings fly-out closes where we can pick up any setting changes.  Essentially these two events will be doing the same thing, pulling a stored setting value and displaying it, so we’ll refactor our jacksTest.js code to look like the following:

    function OnInit()
    {
        System.Gadget.settingsUI = "jacksTestSettings.html";
        System.Gadget.onSettingsClosed = DisplayContent;
       
        DisplayContent();
    }

    function DisplayContent()
    {
        messageDiv.innerHTML = System.Gadget.Settings.readString("message");
    }


    We’ve created a DisplayContent() function which we hooked-up to the onSettingsClosed event and also call within OnInit.  Within DisplayContent() we’re retrieving the “message” settings value via the gadget API.

    At this point you can now control what message is displayed in the gadget via the settings fly-out.

  15. You will notice that when you bring up the settings fly-out, you still get an empty textbox rather than the current message being displayed.  To tidy this up simply return to jacksTestSettings.js and add the following line to the bottom of the OnInit() event handler:

    messageTextBox.value = System.Gadget.Settings.readString("message");

Whilst we still have a fairly useless and if we’re honest, a far from great looking gadget, we have covered 3 fundamental steps in developing gadgets; the introduction of script, hooking up to events in the gadget API and the use of settings.

There are few other titbits of information to take note of too:

  • Unlike the main gadget, if you’re working on files within the AppData folder you don’t need to re-add the gadget to the sidebar to test changes to your settings UI.
  • All settings are stored as strings, in fact they’re stored as plain text in the following file: C:\Users\ [User] \AppData\Local\Microsoft\Windows Sidebar\Settings.ini
    If you add our test gadget, add a display message of “Test”, then open the above ini file and scroll to the bottom you should see message=”Test” at the bottom of the file.
  • Naming – we’ve kept our naming convention so jacksTest.html, jacksTest.css and now jacksTest.js all clearly relate to each other.
  • Folder structure – we’re keeping things tidy by creating a scripts directory for all out script files.

You can download the files for this example here:  jacksTest Gadget Part 2.zip (3.27 kb)

In Part 3 we'll either look at making our gadget look more respectable or refactor reading/writing settings values into an abstracted SettingsManager JavaScript object. 

IETester - Multiple versions of IE in one place

by David 6/10/2008 11:32:00 AM

Testing your site in the various different flavours of browser is by far one of the most tedious and hit or miss experiences every web developer will face.  This is probably truer of IE than most.  The only real way to test properly is to have multiple machines (or VMs) with original installs of each version.

For quick testing as you develop however, wouldn’t it be great if you had a desktop app that emulated all the different versions?  Well this is what IETester claims to do.  I’ll admit that I’ve not tested it a lot, but a quick browse through some sites that I know have IE 5.5 issues seems to suggest it’s doing it’s job.  IETester claims to emulate not only the rendering engines of IE8 beta 1, IE7, IE6 and IE5.5 but also their JavaScript engines.  It’s currently only in Alpha but if they manage to pull of what they’re claiming this is a killer web dev tool.

On a similar theme another impressive, but slightly less useful testing tool can be found in http://browsershots.org/ - given a URL it will produce screenshots of the site on a dizzying number of browser versions and platforms.  There’s no emulation here, but rather a network of physical machines each installed with a different browser version.  Whilst impressive, it has drawbacks; you only get a screenshot of one page in your site, that page has to be public and it can take a while to process.  It’s still a cool project though.

Powered by BlogEngine.NET 1.3.0.0
Theme by Mads Kristensen