My selenium scripts had been working on the theory that I'd already started the selenium server, i.e. relying on me running a .bat file containing
java -jar "C:\Program Files\SeleniumServer\selenium-remote-control-1.0.1\selenium-server-1.0.1\selenium-server.jar" but after reading this article I changed my project to use the SeleniumTestBase code example which allows me to use the firefoxProfileTemplate argument to tell firefox which profile to run under. All of my tests now inherit from SeleniumTestBase and the selenium server starts as part of the test which feels a lot cleaner. Oh, and the tests over the self-verified SSL certificate work too.

• Choose the menu option Debug -> Attach to Process
• In the Attach to Process dialog look in the Attach to: section, if it says "Automatic Native code", then click on Select and choose Managed and Native
• Select the aspnet_wp.exe process
• Press Attach

As of October 26th 2009, Geocities will be closing down it's freely hosted sites. The site I've referred to in the past for Balda Baldixette details is such a site. As such, I'm taking the pertinent details and putting them here for my, and anyone else's references - I haven't taken any of the photos across, just the text. I'm sure this is tantamout to content theft, and if the owner of the information (jgpyke?) has hosted this information somewhere else that I haven't spotted then I'll gladly remove this post and re-direct people to the new page. Just let me know!

Built some time in the 1950's by Balda Werk, in West Germany (BRD), it is a typical 1950's 6x6 camera, pretty much the point-and-shoot variety. In many ways, it is similar to the old Diana or the contemporary Holga. However, the optics are considerably better than the Holga, although that's not much of a comparison. The build quality is much higher than the Diana or Holga: it is nearly all metal with a minimum of plastic used, and there are no light leaks nor vignetting whatsoever. In addition, it has a pressure plate inside to keep the film flat.

The Baldixette has two aperture settings, f9 and f16. The two-element Baldar lens is a little soft overall, especially at f9, but stopped down to f16, it produces acceptable pictures for the type of camera that it is, with minimal distortion. It has two shutter speeds: 1/60 (designated as "M" on the camera), and B, for timed exposures.

The oddest feature of the camera is the retractable lens plate, which pops out to the ready position by touching the button on top of the camera next to the film advance knob. The extending apparatus is a cylindrical and spring loaded chrome housing, and it retracts by simply pushing it back towards the camera. This "folding" action adds to the Baldixette's portability, as it loses more than an inch in profile when retracted.

Simple "modifications" that I have made on the Baldixette include using a lid from a pill bottle as a lens cap and adhering a laminated exposure chart to some Velcro (which, in turn, covers the red window on the back of the camera). I also affixed an updated film speed reminder to the top of the camera, using paper and tape.

Overall, it is a decent camera for the price. If you want a sub-$20 camera and had considered the Holga or Diana, I would suggest that the Baldixette is at the top of the class for these types of shooters. Disassembly of most of the camera for cleaning is quite intuitive for even the novice.

One of the useful modifications that is referred to is the updated ISO film chart. As I haven't taken the photos across, I'll lay this information out in tabular form.
On the /10 DIN area of the wheel:

• Ensure you have Adobe Digital Edition installed
• Disconnect your Cool-er eBook reader - it doesn't need to be attached at this point
• Buy eBook in ePub format from Waterstones (actually don't cos the process sucks, but if you have already...)
• Click Download
• File downloaded will be something like URLLink.acsm
• Click on this file, the eBook should then open in Adobe Digital Edition (you may need to authorise Adobe Digital Edition)
• Go and get a beer, you've done well
• Quit Adobe Digital Edition
• Connect your Cool-er eBook reader
• Open Adobe Digital Edition
• Your Cool-er eBook reader should be displayed in your Library - mine appears as NTX_EB600
• Select your eBook and drag it onto the eBook reader
• Disconnect the Cool-er eBook reader (which in itself is a challenge on the Mac as it remounts itself constantly)
• Look on your Cool-er eBook reader - your newly purchased eBook should be on your Cool-er device in the Digital Editions folder
• Go and get another beer and enjoy your book

This really shouldn't need a blog post of instructions, it should just work, but it didn't, and that's hugely disappointing. I want eBook readers to work - this is my first purchase (I've only read free eBooks up until now), and I wanted it to be smooth and lovely, but it wasn't and it cost more than I could get it via Amazon in print. *sigh*

It turns out that blogger has added script tags to all the posts, so viewing source on this page will show
<script type="text/javascript" src="http://www.blogger.com/static/v1/common/js/327583163-csitaillib.js"></script>

<script>if (typeof(window.attachCsiOnload) != 'undefined' && window.attachCsiOnload != null) { window.attachCsiOnload('ext_blogspot'); }</script>

This isn't a problem for this blog, my photography blog or the Brighton Bloggers blog but destroys the JaneandRichard one - this blog was set up years ago and we use blogger to output XML rather than HTML based on the following template:

<blogs>
<title>Recent blog: latest happenings</title>
<Blogger>
 <BlogDateHeader>
  <day date="<$BlogDateHeaderDate$>">
 </BlogDateHeader>
 <blog time="<$BlogItemDateTime$>" by="<$BlogItemAuthor$>" id="<$BlogItemNumber$>">
  <title><$BlogItemTitle$></title>
 <body><$BlogItemBody$></body>
 <permalink>http://www.janeandrichard.co.uk/blog/archive/<$BlogItemArchiveFileName$></permalink>
 </blog>
 <BlogDateFooter>
  </day>
 </BlogDateFooter>
</Blogger>
</blogs>

The xml produced by the system now also includes the script contents, which, obviously, then fails parsing and breaks the rendering engine. Blogger are aware of the issue and have provided a work-around, but I'm a bit too scared to try it as it will result in Richard having to work some more perl magic...

Yet another in the note to self category.

When using App_offline.htm files to take down a site in IIS, if the file size isn't 512 bytes of content or greater then IE may choose to default to the "Show Friendly Http Errors". Comments count towards the byte size so client side comments will work too.

There is more about this at ScottGu's blog

We've done some more work on integrating FxCop into our development process this week, and today Mike and I have sat down and started work on choosing which rules to validate against initially. To do this, we've based our starting set on the rules that Microsoft have switched on internally. Thus far we've been through the Design, Naming (mostly left switched off until the coding standards review is complete) and Performance rules.

Having set these up in a .FxCop project, I then wanted to be able to make use of the Post Build event to get the assembly analysed according to a predefined set of rules. This took a bit of research but I think I've got it sorted now:

Instead of using:
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"
I'm using
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" /project:"C:\Program Files\Microsoft FxCop 1.36\DefaultRules.FxCop"
and so am making use of the "/project" flag to specify the .FxCop file to run, and no longer specifying the /r (or /rule) tag to indicate where to find the rules. It is important that the .FxCop file doesn't contain any targets of its own, as otherwise both the assembly produced by the build AND the assemblies targetted in the .FxCop file will be analysed, which could lead to a lot of head-scratching when you try to work out why a source file that doesn't exist is causing problems :-)

More information on the options for the FxCop Command Line version is available here.

This is a tool I've used in the past with success, but which I found frustrating by the lack of integration into the IDE, instead relying on its own, slightly gawky interface.

Configuration

Rules can be switched off, switched on, and also custom rules can be added - read this tutorial for some useful hints and tips. Rules can also be supressed on a project by project basis, or globally by updating the FxCop.targets file - this will be really handy for how we want to set our chosen tool up.

Error detection

I left the rules as default, so they are based primarily on the Microsoft Design Guidelines. When run through the FxCop IDE a helpful link is provided to online documentation explaining the issue in more detail - for instance AssembliesShouldHaveValidStrongNames - and giving example fixes. The quality of errors returned were much better than CodeIt.Right, referring both to coding standards (naming of variables etc), but also performance and security improvements. There is no automagic correction meaning that developers learn from the warnings.

Automation

There is a command line version of the tool available which can be built into an automated build process. Additionally, this can be added as a post-build event outputting the results into the Warnings tab of the Error window in VS2005 and VS2008.

I started with working out the command line version of what I was trying to do -
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"C:\Working\MyTestApp.exe" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"

Which is, basically, call FXCop (version 1.36) using the Rules dlls specified in "C:\Program Files\Microsoft FxCop 1.36\Rules", and use the XSL file in "C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl" to formulate the output.

Moving on from this, I put this working command line into the Post-build event command line as:
"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"

Where $(TargetPath) gets equated to the generated dll/exe etc in the build process.

Behind the scenes, this gets recorded in the .csproj file as:
<PropertyGroup>
  <PostBuildEvent>"C:\Program Files\Microsoft FxCop 1.36\FxCopCmd.exe" /c /f:"$(TargetPath)" /r:"C:\Program Files\Microsoft FxCop 1.36\Rules" /consolexsl:"C:\Program Files\Microsoft FxCop 1.36\Xml\VSConsoleOutput.xsl"</PostBuildEvent>
</PropertyGroup>

And bingo, the errors get reported into the warnings window. From here they are clickable etc.

On today's cycle ride, it tells me I got a speed of 42.1mph (which does not match what my cycle computer says - 21.7mph). I've started hunting for tools to spot and remove anomalies from GPX or KML files, but in the meantime have come up with a workable alternative.

1. Export the file in CSV format
2. Also export the format in GPX format
3. Open the CSV file and sort by the Speed column
4. Look for any readings that look extraordinary - in my case I had lots around the 20, 21, 22 mph mark, and then 3 at 37, 38 and 41 mph - obviously incorrect. Make a note of those numbers, they'll be used in a minute
5. Open up the GPX file in an editor
6. Search the file for "Speed " and use the numbers recorded above
7. For every anomaly you spot, remove the whole trkpt node (see example below)
8. Save the GPX file
9. Head over to Sports Tracker and upload the new file
10. Check that the file looks about right

After working through these stages, I now have an uploaded trail that looks more accurate.

Sample trkpt
<trkpt lat="50.824980" lon="-0.148063">
<ele>91.0</ele>
<speed>0.07</speed>
<course>193.8</course>
<desc>Speed 0.2 mph Distance 0.00 mi</desc>
<time>2008-01-13T13:50:34.95</time>
<name>2</name>
</trkpt>