Code Formatter Plug-in for Windows Live Writer

Version 1.0.0.4 of my plug-in for Windows Live Writer (WLW) is now available.  This version is for the released version of WLW.   As with the previous version, the following languages are supported:

• Assembly
• BatchFile
• CSharp
• CSS
• HTML
• INIFile
• Java
• JScript
• Lua (pronounced LOO-ah)
• MSIL
• Pascal
• Perl
• PHP
• PowerShell
• Python
• SQL
• VBDotNet
• VBScript
• XAML
• XML

Download it now from my tools page.

 

Thanks to everyone who left comments and feedback;  this addressed two issues reported - 1 with inserting pictures and then editing a block of code, and the other was with duplicate scroll-bar options.

New version of the Code Formatter Plug-in for Windows Live Writer.

Version 1.0.0.3 of my plug-in for Windows Live Writer is now available.  This version works with the new Beta 3 version of WLW (and also older versions).

Languages now include:

• Assembly
• BatchFile
• CSharp
• CSS
• HTML
• INIFile
• Java
• JScript
• Lua (pronounced LOO-ah)
• MSIL
• Pascal
• Perl
• PHP
• PowerShell
• Python
• SQL
• VBDotNet
• VBScript
• XAML
• XML

Download it now from my tools page.

If Agile is so good, why haven't we always done it?

Fred George has an interesting post on his successfulness with Agile processes.  He asks, if Agile is so much better, why didn't it emerge earlier?

He thankfully rules out stupidity and instead lists the three enablers that we have today that we didn't have back then (Fred goes back to the 70's, but I'd say these were just as relevant for most of the 80's):

1. We didn't have the languages (Java, C#, Ruby) and techniques (OO, rules engines) to write code that could be changed. Our paradigms were actually the opposite: Design your data structures, and the code writes itself.
2. JIT (Lean) hadn't made it out of the automotive manufacturing sector.
3. We didn't have the horsepower. I have more memory in my watch than I had in my first computer. And don't think of comparing an entry iPod to the first PC.

I'm trying to imagine how horrendous it would be to try and mock some behavior written in 6502 assembler in a unit test, on the Commodore 64! 

Challenging Conventions with Test First Development

I've just read a great post over at Tim Ottinger's blog.  In it he discusses how test first development challenges conventional development.  He makes several interesting points, some of which include:

Point 3: Private makes less sense than it used to. You can’t test anything that’s private.

This is something I often ponder over.  Making things private makes your intent very clear, which I think is very important.  But private implementation is still a unit of code that needs testing.  Then again, as described in Test Driven Development: A Practical Guide,  unit tests should test the facets of behavior.  As Dave Astels puts it in this blog post:

"... the idea of “unit” is a major problem. First of all it’s a vague term, and second it implies a structural division of the code (i.e. people think that they have to test methods or classes). We shouldn’t be thinking about units… we should be thinking about facets of behaviour."

To me, the term 'facets of behaviour' reads that 'behaviour' has 'facets', and that private implementation makes up each facet.  So by testing the facets of behaviour, you are really testing units of private implementation (i.e. private methods).  This point may be worthy of a new post...

Point 4:  The fat constructor argument list is a concession to the need for isolation and testing with mocks...

Good comment.  I always refactor any code I see with a fat parameter list so it takes a 'property bag' instead.  In ReSharper, this refactoring is called 'ExtractClassFromParameters'.  The benefit of this is cleaner, more separate code, and also overcomes C#'s limitation of not having default parameters (i.e. you leave it null/default in the property bag).

Point 7:  Hard to use class interfaces are now hard for you to use...

Exactly.  Which is why I find TDD a great way to figure out 'how to design an API/Framework' rather than 'how to implement the API/Framework to achieve something'.  Something that made a lot of sense when reading the Framework Design Guidelines is to forget OO when designing the public interface to an API - i.e. design it so it's easy to use for the most common scenario.  Exactly what is achieved by practicing TDD.

Handy .NET Cheat Sheets

John Sheehan has some great cheat sheets on string formatting, ASP.NET Page Lifecycle and Visual Studio code snippets.  Very handy.  I'm sure there's a medical explanation as to why it's impossible to remember string formatting parameters for more than 1 minute after you've discovered them!

Getting 'code://' hyperlinks into FlexWiki

Reflector, when installed, adds a "code://" protocol handler, enabling hyperlinks to specified types in assemblies.  This handler is similar to http:// or ftp://, but instead of taking you to a web site, it takes you to a type in an assembly!

For example, code://System.Web/System.Web.UI.WebControls.WebControl will launch Reflector and navigate to the WebControl type in the System.Web.UI.WebControls namespace.

Custom types can also be navigated to, although the associated assembly must be loaded first.

By default, FlexWiki does not handle all protocol handlers. To get it to handle the code:// protocol, a recompile is needed.  I'm working with version 2.0.0.41. Later versions are now available, but the code should be in a similar place.  So, for version 2.0.0.41, changes are needed to the file:  FlexWikiCore-2.0.0.41-src\EngineSource\Formatter.cs.

Change lines 1706 and 1707 - adding the 'code|' segment next to the https?| text:

static string urlPattern = 
  @"((https?|code|ftp|gopher..." ) ;

static string urlPatternInBrackets = 
  @"((https?|code|ftp|gopher..." ) ;

I must say, it's very handy for your team to be able to navigate directly to code from a Wiki entry.

ReSharper 3.0 released

The new release of ReShaper has a great set of new features and seems to be very stable.  The only downside:  it doesn't yet run in  Visual Studio 2008 (Orcas).  This is planned for version 4.0 which is planned for release at the end of the year.  The lack of ReSharper may just put off beta testing the new Visual Studio.  If I hear of how to get it to work, I'll post it here.

Framework design lecture avaliable for download

Krzysztof Cwalina, co-author of the excellent Framework Design Guidelines book, did an API design lecture a little while back and it's now available for download here.

Object Oriented vs Test Oriented

Roy is debating this very topic - that is - for any API that needs to be unit-tested, do we forego OOD principles, such as hiding irrelevant stuff, in favour of testability? 

To summarise Roy's case:  he's using public bits of the FxCop API to automate (unit-test) his custom rules - but... the FxCop team have realised they've got a bunch of types that shouldn't be exposed and will be making them internal in the next 'Orcas' release.  This means that Roy's unit-tests will not compile against the new API.

I think the issue here is Roy using something in the API that wasn't intended to be exposed but is rather useful; that is, offering an API to automate custom rules. From what I can see, the FxCop team are quite correctly 'concealing' types that shouldn't be exposed; I for one would be glad of this decision if I were looking through their API 'contracts' - I wouldn't want to spend time creating and trying to use an exposed type if it weren't mean to be exposed.

I do see the need to automate testing of custom rules, but I think this should be designed as appopriate additions to the API for that particular purpose (rather than relying on accidentally exposed types spread throughout the API to acheive the same thing).  This way, the API stays tight, and also enables a more succinct, targeted API for automating tests for custom rules.

Of course, this doesn't anwser the more general question "How do I design an API that hides irrelevant stuff but also enables the irrelevant stuff to be tested?"

In fact, in the paragraph above, I was going to use the term 'How do I design an API that is both OO and easily tested', but, as Framework Design Guidelines correctly states, API's are not meant to be Object Oriented (the implementation is OO, not the public API).

So, I suppose the question really becomes 'How do I hide my OO implementation but make it easily testable?"

One way is to have the unit tests in with the implementation. I'd prefer not to do this, but I've done it in the past. I've also taken the other route and made the odd type here and there public instead of internal so I can test externally.

I've been toying with the idea of having a 'Unit Test Facade' object in my OO code/API. Anyone use the 'API' can see my intent from what's exposed, and anyone running unit tests can exercise the implementation via the facade. Of course, this adds overhead, but does make the distinction between the API and implementation.

Uploading to an FTP server with parameters

This post will have a limited audience (even more limited than my normal posts!), but if you're searching for a solution to this particular problem, I hope you'll be glad you found this.

I was recently tasked with uploading a file to an FTP server. I optimistically estimated that it shouldn't take long as we're using .NET 2.0 and there's FTP stuff in 2.0.

But, the particular server I had to write to took parameters on the PUT command (something I'd never seen before). The put looked something like this:
PUT thefile.txt %destinationFilename.txt%param2%%param4

The parameters tell the server things like what 'mailbox' to use, what account to use to write the file, etc. etc.

A quick bit of info on FTP:  you first send the PUT request, and get a response, followed by other requests (for things like credentials), followed ultimately by sending a STOR command.

The .NET 2.0 implementation of FtpWebRequest does not take into account differences between the 'request (PUT)' parameters and the 'command (STOR) parameters'.

To get around this, one must use sockets directly.  I found a Microsoft KB article that contained just that.  The sample demonstrated using pluggable protocol handlers.  I removed the bits that weren't relevant and modified it to handle command parameters.

I fronted all this with an FtpTransfer class that deals with just uploading files. Typical usage looks like this:

FtpTransfer ftpTransfer = new FtpTransfer( 
    new Uri( @"ftp://serverRequiringParameters" ), 
    @"yourUsername", 
    @"yourPassword" );

ftpTransfer.UploadFileWithParameters( 
    @"c:\temp\ftptest.txt", 
    @"destinationFilename.txt", 
    @"%destinationFilename.txt%PARAM2%PARAM3" );

The source (and a Visual Studio 2005 project) can be download here.

Beta Testing Windows Home Server

Time to try another beta OS from Microsoft. This time, Windows Homer Server.  Thirty seconds in and I'm getting my first error (well, it's better than waiting 30+ minutes like back in the days of the Windows 2000 beta!)
The error was "Could not initialize UI subsystem". I looked around the forums and found suggestions to try and set the DVD
as the first boot device. Mine already was. I then found a suggestion to use different DVD burning software. Rubbish I thought and carried on searching.
Having come to a dead-end, I tried what was suggested and downloaded the free 'ImgBurn' utility. This software is great. Not only did it fix the installation problem, but it's also a light-weight utility to burn stuff to CD's and DVD's (190mb for Nero 7, 1.5mb for ImgBurn!).  Sold!

Framework Design Guidelines

Framework Design Guidelines is a fantastic book about er, guidelines for designing frameworks (API's). Krzyztof, one of the authors, has now posted a video of a talk he did about this very subject.

Running unit tests in Visual Studio Express

The brilliant TestDriven.net can't run in Visual Studio Express (well, from what I've heard, it can, but Microsoft asked for it to be removed).

Therefore, to run unit tests in Visual Studio Express, you must set your debugger application to point to NUnit.exe (or the brilliant MBUnit).  This isn't straightforward in Express and means editing the .csproj file by hand and telling it to run the NUnit exe.

Today, I wanted to run and debug some unit tests I'd written in the XNA Game Studio Express (Visual Studio Express with some XNA bits bolted on).  I couldn't have the excellent right click/run unit test feature and I thought there's got to be a better way than editing the .csproj file manually.

So I changed the unit test project to be a console application and added this to the Main method.

    public static void Main( )
    {
      AppDomain.CurrentDomain.ExecuteAssembly( 
        @"C:\Program Files\NUnit-Net-2.0 2.2.9\bin\NUnit-console.exe",
        null,
        new string[ ] { Assembly.GetExecutingAssembly( ).Location } );
    }

And it worked.  Which was nice.

Update:

Jamie recently left a message saying that the new Beta version DOES support Express editions!  Read his post here and get downloading straight away!

Email certificate popups

I recently switched to Vista and Office 2007.  I set-up Outlook with the details of my email certificate.  The trouble is, whenever sending a message, Vista pops up a dialog asking whether to grant or deny permission to the certificate.  The exact text is:

"Grant or Deny this application permission to use this key".

The way around this is to not use Outlook to install the certificate but to right click on the certificate in Explorer and let Vista install it.  Another important thing when doing this is to NOT click the Strong option - this is what causes the prompting - leave it as Medium.

To reinstall the certificate:

• Go to Internet Explorer/Tools/Option/Content/Certificates then Export your certificate (checking the box to delete it after export). 
• Then, right click from Explorer and select Install. 
• When this is done, reselect the certificate from Outlook - Tools/Trust Center/E_mail Security.

A tool for converting animated GIFS to spritemaps

I'm having a lot of fun playing around with the XNA development kit. One day I'll get around to learning 3D but for now I'm still having too much fun with sprites! I wanted a tool that took an animated GIF and produced a spritesheet (a bitmap with each frame of the GIF).

From this:

... to this:

I couldn't find a tool forthis (although I'm sure they exist), so I did my own and uploaded it to my tools page

New version of the Code Formatter Plugin for Windows Live Writer

Version 1.0.0.2 can be found here.  This update adds the ability to change the font - including the font name, size, style, and weight.

A New Version of Microsoft Terminal Services Client (Remote Desktop) Version 6 of MSTSC now supports multiple monitors(!) as well as wide-screen resolutions and other features that I haven't yet tried. This is the version that comes with Vista but it's worth noting that there is a download for Windows XP SP2 and Windows Server 2003. It's also worth noting that the new features are only available if the machine you're connecting to is Vista or Longhorn Server.

FluentInterface

I've posted before about the StringBuilder tip in .NET.

Martin Fowler describes this as an ExpressionBuilder pattern.

More formal terms are described in his post, for instance, a FluentInterface which allows code like this:

customer.newOrder() 
	.with(6, "TAL") 
	.with(5, "HPK").skippable() 
	.with(3, "LGV").priorityRush();

I personally like this style but agree that if every object had these strange looking methods it would certainly pollute an API.

Another formal term describing how not to pollute an API is CommandQuerySeparation.  Basically, this means that a method that changes the observable state of an object shouldn't have a return value. 

The ExpressionBuilder pattern is the solution to this:  it is a seperate object that defines the FluentInterface and yet doesn't pollute the API. 

I'm glad that I now know more than 3 patterns, the Factory pattern, the Visitor pattern, and the Submarine pattern.