I was recently tasked with taking an exploratory look at the mobile rendering capabilities of SharePoint 2010 to get a feel for it.  The short of it is that it's sad to say that in 2010 (the year, that is), we are still doing not much better than 3-4 years ago.  Of course, this raises the question of whether it's an issue with the browser or an issue with the software (SharePoint 2010).  Based on my early experience, I have to say it's an issue with 2010 - it seems like the SharePoint team simply took the easy way out.

If you've ever used the Gmail web page from a mobile browser (like Opera), you'll see that there is a "mobile" version and a "basic HTML" version available (links on the bottom).  For all intents and purposes, the "basic HTML" version looks and works pretty much like the full web version (minus the fancy drag/drop stuff, chat, etc.) and loads fine on my nearly two year old HTC Touch Pro.  This is what we should expect from a company as big as Microsoft with vast resources at their disposal.  This is what we should expect from them given that it's 2010 and the mobile space is an increasingly bigger piece of the pie. 

What's worse is that there's no apparent way from the browser client to access the "full view".  What happens when more capable mobile browsers are deployed that can match the capabilities of the current desktop browsers?  Seems like you'll have to make configuration changes on the server to enable proper browser detection but it would be much easier to simply have the option, like on mobile Amazon.com, to load the full view in lieu of Microsoft actually offering a more usable "basic HTML" view.

Alas, instead, we get neutered functionality and weak rendering to mobile browsers for a product that's supposed to carry us to 2013 or 2014.

The following screenshots are taken using my desktop IE8, Microsoft's Windows Mobile 6.1.4 emulator, and RIM's Blackberry 9630 emulator:

Lading Page

List View

Calendar View

New Event

In analysis, I think what makes matters worse is that they've dramatically increased the capabilities of the desktop browser version, but neglected to carry forward some of the basic functionality that seems like it wouldn't be too had to implement like the ratings or tagging functionality.  This discrepancy makes the shortcomings of the mobile offering all the more apparent.

Certainly, I'm not expecting that the desktop experience to be fully emulated on a mobile device, knowing the limitations of the small screens and limited resources and capabilities of mobile browsers.  That said, I would expect a more worthy effort than this.  I would expect something similar to Gmail's "basic HTML" option and a link to the full version.  It's an embarassment, especially the new event screen; at the least, the developers could have aligned the fields (it's pretty offensive).

It's just sloppy and lazy all around and I suggest Microsoft spend some time with the mobile browsers from their competitors.  People are accustomed to a certain level of mobile browser capabilities these days and it's nowhere near as low as Microsoft would like to believe.

For comparison's sake, here's Gmail's rendering in "mobile" and "basic HTML" mode:

Gmail desktop browser, "mobile", and "basic HTML" rendering

This is much more usable and a much more congruous experience across platforms.  Come on Microsoft, stop being lazy!  As Mark Jackson would say "You're better than that!"

On a side note, working with the emulators was a bit challenging.  If you'd like to try it out for yourself, here are some resources:

Mobile IE 6

• Windows Mobile 6.1.4 Emulator Images.  These are nifty, ready-to-run emulators for Windows Mobile 6 devices.
• Windows Virtual PC Network Driver extraction and installation.  You'll need this if you're working on an OS like Windows 7 or Windows Server 2008, where you won't be able to install Windows Virtual PC 2007.  It's puzzling why Microsoft would take the standalone install down from their site (all you get is a text file telling you that the file is no longer there...........).
• Getting network access configured.  Bruno Terkaly's guide for developing for the mobile emulator (including instructions for configuring network access).

Blackberry Devices

• Blackberry Smartphone Simulators.  You start by downloading one of these packages based on the device that you want to target.  To run the simulator, you need to click on the ####.bat file (where #### is the device number) in the directory where the files are unzipped to.
• Backberry Email and MDS Services Simulator Package.  You will need this to connect to the network.  You should start by running the run.bat file first and then start your device emulator.
• You'll also need a minimum of JDK 1.5.

My experience is that working with the Blackberry emulator is extremely frustrating because you'll want to click on the screen with your mouse but then you remember that the devices don't support touch so it would only be logical that the emulator doesn't either.  However, this logic leads to a hair-pulling experience when working with the emulator.

As I've been working with a client which has demanded rigorous sequence diagrams as deliverables for the design phase of the project, I've started to use WebSequenceDiagrams.com more and more.

I've blogged about it previously, but I've only come to truly appreciate it after having to use Visio for a few days before I convinced the client that I could deliver the content faster and in an easier to maintain format (well, text) using WSD. 

What Visio Gets Wrong

I ran out of connection points.  Yes, it's possible; for a long activation sequence, you can actually run out of connection points.  One could argue that this calls for a refactoring of the diagram in the first place, but then I would say that you've never tried to actually refactor a Visio diagram...I still find it hard to believe: the activation box ran out of connection points; I wouldn't have believed it if I didn't see it myself:

I kept having to resize the page.  By default, you can't really fit much on the page.  But as I started to build my sequence up, I found that I had to keep toggling around with the paper size just so that I would have a grid.  This was annoying since it also involved then zooming out so that I could select everything and reposition it to the top left corner of the page then zooming back in.  You'd think that Visio would be smart enough to do this, but it isn't...

I kept having to move elements around.  Want to add a new step?  What about introducing a new actor in between two existing actors?  Prepare for some carpal tunnel my friend.  There's simply no easy way to do it aside from zooming out, grabbing everything to the right and shifting it around while counting gridlines and getting your result some 10-20 clicks later.  What's worse is that you end up having to scroll around horizontally (reordering actors) and vertically (reordering steps) while dragging a bunch of stuff around.

I kept having to fix connection lines.  This was absolutely mindboggling: if I extended an activation, it would cause the first connection on the activation to jump, which would then require me to manually drag the connection back to where it belonged.  I probably spent a good 10% of my time simply fixing these connection points as a adjusted activations:

This is an incomprehensible design flaw; I have no idea how people work around this in Visio since I adjust activations multiple times as I'm working through a diagram.

There was no representation of alternate paths or optional steps.  I ended up having to draw a rectangle and manually managing the size of it as I changed steps and added more steps.  What made this even more annoying was that having the rectangle, even though I sent it to the back, then made it difficult to select elements that were enclosed by the rectangle like a message line or a connection point or a note; I'd end up selecting this stupid rectangle instead.

I had to keep managing the location of notes.  The notes don't seem to anchor to anything and it's not clear to me how that's supposed to work.  That meant that I had to keep moving notes around as I changed activations and modified connection points.

The lifelines didn't synchronize.  For the life of me, I couldn't figure out how to get the lifelines to synchronize in length so I didn't have to manually go back and drag each one down to the same length.  You can't actually CTRL+click two lifelines, as one would think you'd be able to do, and drag them both to extend them simultaneously.  I mean, this seamed like pretty basic stuff to me.

So yeah, all in all, I'm not sure why anyone would want to subject themselves to the pain of creating sequence diagrams in Visio.  Maybe if it's a final product and you don't plan on touching it ever again and you've already done most of the work on paper or something, but it's a terrible tool if you're just trying to think an idea out and see it visually.

What WebSequenceDiagrams.com Gets Right

I can't speak to the console program or the DLL (yet), but I decided that the only way that I could do this right was to do it in WSD first and then just use Visio to render the final output.  While doing it in the browser is fine, I found it much easier to do it in EditPlus, my text editor of choice.

The first step was to create a syntax and auto-complete file so that it was a little more user-friendly.

Here's my .stx syntax file:

#TITLE=WSD

#DELIMITER=,(){}[]+*%/="'~!&|<?:;.
#QUOTATION1="
#LINECOMMENT=note
#CASE=y

#KEYWORD=Activate
activate

#KEYWORD=Deactivate
deactivate
destroy

#KEYWORD=Alias
as
participant

#KEYWORD=Notes
note
over
right
left

#KEYWORD=Control
alt
else
end
opt

#KEYWORD=Newline
\n

#KEYWORD=Transition
->
-->
#

And my .acp auto-complete file:

#TITLE=WSD

#CASE=y

#T=act
activate ^!
#T=de
deactivate ^!
#T=pa
participant ^!
#T=alt
alt ^!
    
else
    
end
#T=opt
opt ^!
	
end
#

What I get from this is:

I know what you're thinking: Chuck, that looks like code!  By golly, it does!  And -- at least to me -- that's the beauty; all of a sudden, a frustrating, time consuming, mouse-centric activity becomes a keyboard-centric, coding-like activity.  Moving objects around becomes a matter of moving lines of text.  Reordering actors involves moving your participant declarations around.  Notes stay in their context if you add a step since everything gets pushed down.  There's no manual resizing of anything.  There's no fixing connection points.  There's no stupid.  It actually makes working with sequence diagrams, beyond just whiteboarding, much more useful and much more productive as it lets you kind of think out the code by actually writing pseudocode.

I highly recommend downloading EditPlus (you can keep using it for free, perpetually, if you're a cheap bastard or pony up the $20 for such an awesome editor).  For me, EditPlus is a perfect pairing for WSD due to the easy to create language syntax/autocomplete files and the handy split-document feature so you can easily reference your participants at the top.

Simply create a new file type and add the .stx and .acp files I defined:

Now the downside of this whole affair is that you have an extra step of having to copy out the text and pasting it into the browser, but even with that extra little bit of annoyance, the time and frustration saved over working with Visio is more than worth it.

The next step, once I get my hands on the command line tool, is to hook it up to the external tools feature of EditPlus for a quick hit.  I'm also considering writing an integration for Visual Studio for custom rendering within VS or at least something quick-and-dirty like an add-in.

One additional note is that WSD has an HTML/Javascript API whereby you can render a diagram inline with your HTML by simply using a set of <pre></pre> tags and a reference to a Javascript file.

What's cool about this is that now you can use the standard CTRL+B/CTRL+E shortcut keys to preview without a copy/paste step!  For free!  That's pretty awesome.

Of course, the downside is that using this method, there is a limit to the size of the sequence that you can send up as well as the fact that you need some additional hijinks to make the syntax highlighting work (I gave up on that part ) .  But if were doing it in the browser to begin with or using notepad and you don't care for the syntax highlighting, then this is a huge upgrade.

Conclusion: stop using Visio Now I'm just looking forward to WebERDiagrams.com, WebStateMachineDiagram.com, and....well, you get the idea.

My EditPlus .stx and .acp files for anyone that wants 'em: wsd-files.zip (.52 KB)

As I've been starting on a new project recently, I've been delving into Mercurial (hg) as an alternative to Subversion (svn).

I've been using svn for about 3 years now, and - for the most part - it has been way better than Visual Source Safe (whatever last version I used...it sucked), it clearly has some pain points that make daily workflows difficult.  The most important of these are the speed of commits, the fact that a commit is global, reverting to a version, and branching/merging (painful...so painful).

hg addresses each of these pain points:

• Speed of commits and local commits: Mercurial has two separate concepts of commit and push.  A commit in hg creates a local commit as opposed to a global commit in svn.  This is useful because you can work->work->commit->work->commit->work->revert->commit without affecting anyone else's work stream.  In other words, you don't have to wait to commit until you have flawless, working, compiling code.  You can commit as much as you want and keep your work intact; this is a big win as it encourages experimentation.  When you're ready to share your code, a push operation (the equivalent of a svn commit) pushes it to a shared location for others to pull.  Of course, to some degree, you can accomplish this with svn as well using a branch, but...
• Branching/merging: OMG, so much easier and more intuitive than svn.  I can't believe it.  In comparison, svn is a giant charlie foxtrot.  Branching and merging in svn pre-1.5 was an exercise in futility.  It was extremely difficult to remember the right procedure (always requiring a lookup to the docs) and very much error prone.  So difficult, in fact, that it discouraged branching for fear of wasting a good half day trying to merge it back in later.  Maybe it's better with 1.5?
• Reverting to a version: ever try it in svn?  'Nuff said.  It's counterintuitive and always confuses the heck out of junior devs or devs new to svn.

I've only been using it for a few days now (primarily TortoiseHg), so perhaps hg has just as many warts as svn, but I'm going to stick with it and find out.

Some good resources on hg/git vs. svn (or DCVS vs CCVS):

• http://seeknuance.com/2008/07/06/mercurial-vs-subversion/
• http://www.b-list.org/weblog/2008/jul/28/lets-talk-about-dvcs/
• http://robwilkerson.org/2008/04/05/subversion-or-git/
• http://tomayko.com/writings/the-thing-about-git (his point about "you should have" as a core issue with svn is very relevant as it was quite a common occurence on FirstPoint when someone would commit some feature that broke the build or a stable feature)

I'll post new entries as I learn more about hg in daily use :)

P.S. WebFaction is a pretty awesome webhost.  For the low, low price of some $10 a month, I can host my own hg repository, svn repository, Trac, and (note: not or) my web app.  Hot damn, that's awesome!  Although svn was significantly easier to set up with WebFaction than hg, I've read that they are close to officially supporting hg and it should be just as easy in the future.

In software development, it's incredibly useful to be able to visualize your code interactions using sequence diagrams and data flow diagrams and what not.  Not only is the visualization a plus, the act of generating one helps tremendously in terms of working out the outline of the logic that you need to implement.  One of the biggest problems I've come across in this area are the tools: they're simply too heavy and too complex for general diagram drawing tasks in addition to being generally rigid as well.

Today, as I was about to download and install Visio, I decided to spend a few minutes checking to see if there was a web alternative.  Enter websequencediagrams.  This is an all around awesome little tool to add to your toolbox.  Not only is it free (free is always awesome), it's text based.  At first blush, this seems terrible; there's a whole syntax to learn and lots of typing.  But the syntax is incredibly easy and simple while powerful and easy to understand.

Here's an example (I've bolded the syntax to make it easier to distinguish):

And here is the result:

There are also a variety of pre-defined styles you can choose to render your diagram.  It's all sorts of awesome and a real time-saver compared to traditional tools.  I personally love that it's text based; I've found that when working with Visio (and other such tools), more than half of my time is spent arranging things just to get them to line up.  A text based approach works well for sequence diagrams and gets rid of that layer of unnecessary complexity.

In working on some SDK-style developer documentation for FirstPoint, it occurred to me that we needed a way to create some all encompasing documentation which covered not only our code base, but also our markup, our JavaScript controls, CSS, and so on.  We currently have most of this stuff in Trac wiki pages, which is a great place to put them, but our Trac deployment is going away and being replaced by Jira...or so I'm told.

In light of this, we needed a way to create portable, useful, developer documentation which included a mix of some auto-generated content and hand crafted documents as well (how-to's and stuff, which would be really terse if placed in code comment).  There aren't really any do-it-all tools, but I stumbled across NaturalDocs which seemed to be the most well rounded tool of the ones I looked into (i.e. JSDocs, YUI Doc, a few others - it started off as a search for a tool for documenting UI conventions, markup, and script usage for our team) because of the fact that it allowed for the inclusion of loose .txt files which would essentially be treated like wiki pages.

You can see an example of the output at the MapQuest API documentation site.

One of the main reasons I liked NaturalDocs is because of the support for code blocks and how easy it is to write them in the loose text files.  However, the downside is that the generated output is pretty...boring.  Here's an example:

You can see that it has no intelligence with regards to the language.  Doing a little digging around the 'Net, I found a ticket for a request for support for syntax highlighting.  So I ended up rolling my sleeves up and solving this myself.  I decided to integrate against the SyntaxHighlighter JavaScript library since I've used it previously and I like the output .

Here is the end result:

I hadn't touched Perl in quite some time (since college), so I had to dig around in there for a bit but I was able to integrate it after a few hours of flailing.

The steps required are as follows (these steps assume you use framed mode):

In the file FramedHTML.pm, you will need to add the following lines to the method BuildFile after the call to $self->ClosingBrowserStyles():

. '<script language="javascript" src="' . $self->MakeRelativeURL($outputFile, $self->HighlighterShCore(), 1) . '"></script>'
. '<script language="javascript" src="' . $self->MakeRelativeURL($outputFile, $self->HighlighterShBrushCSharp(), 1) . '"></script>'
. '<script language="javascript" src="' . $self->MakeRelativeURL($outputFile, $self->HighlighterShBrushXml(), 1) . '"></script>'
. '<script language="javascript" src="' . $self->MakeRelativeURL($outputFile, $self->HighlighterShBrushCss(), 1) . '"></script>'
. '<script language="javascript" src="' . $self->MakeRelativeURL($outputFile, $self->HighlighterShBrushJs(), 1) . '"></script>'
. '<script language="javascript" src="' . $self->MakeRelativeURL($outputFile, $self->HighlighterShBrushSql(), 1) . '"></script>'
. '<script language="javascript">'
. 'SyntaxHighlighter.config.clipboardSwf = "' . $self->MakeRelativeURL($outputFile, $self->HighlighterClipboard(), 1) . '";'
. 'SyntaxHighlighter.all();'
. '</script>'

Next, to support the new getters, you will need to modify HTMLBase.pm and add the following lines:

sub HighlighterShCore
	{
	my $self = shift;
	return NaturalDocs::File->JoinPaths($self->JavaScriptDirectory(), 'shCore.js' );
	};

sub HighlighterShBrushCSharp
	{
	my $self = shift;
	return NaturalDocs::File->JoinPaths($self->JavaScriptDirectory(), 'shBrushCSharp.js' );
	};

sub HighlighterShBrushXml
	{
	my $self = shift;
	return NaturalDocs::File->JoinPaths($self->JavaScriptDirectory(), 'shBrushXml.js' );
	};

sub HighlighterClipboard
	{
	my $self = shift;
	return NaturalDocs::File->JoinPaths($self->JavaScriptDirectory(), 'clipboard.swf' );
	};

sub HighlighterShBrushCss
	{
	my $self = shift;
	return NaturalDocs::File->JoinPaths($self->JavaScriptDirectory(), 'shBrushCss.js' );
	};

sub HighlighterShBrushJs
	{
	my $self = shift;
	return NaturalDocs::File->JoinPaths($self->JavaScriptDirectory(), 'shBrushJScript.js' );
	};

sub HighlighterShBrushSql
	{
	my $self = shift;
	return NaturalDocs::File->JoinPaths($self->JavaScriptDirectory(), 'shBrushSql.js' );};

You should add more to handle whatever syntaxes you need to handle.

By default, the code blocks are generated as <blockquote><pre></pre></blockquote>.  To support SyntaxHighlighter, we'll need to change this to allow customizing the class name on the <pre> tag.  I decided to use the suggested syntax for including this in the markup: (start code <language>).  For example: (start code js).  The first module that we have to modify to support this is Native.pm.  In the method FormatBody, I made the following change to support the extra token:

# If the line looks like a code tag...
# [CHUCK] ORIGINAL: elsif ($commentLines->[$index] =~ /^\( *(?:(?:start|begin)? +)?(?:table|code|example|diagram) *\)$/i)
elsif ($commentLines->[$index] =~ /^\( *(?:(?:start|begin)? +)?(?:table|code|example|diagram) *((?:\w+)?) *\)$/i)
	{
	if (defined $textBlock)
		{
		$output .= $self->RichFormatTextBlock($textBlock);
		$textBlock = undef;
		};
	# [CHUCK] ORIGINAL: $output .= $tagEnders{$topLevelTag} . '<code>';
	$output .= $tagEnders{$topLevelTag} . "<code class=$1>";
	$topLevelTag = TAG_TAGCODE;
	}

You can see that I've introduced a capturing group to the regular expression to grab the language type (matching SyntaxHighlighter's language strings).  The next step is to modify the generation of the intermediate <code> tag to include a class attribute. 

If you stop here, the output generation doesn't work correctly since this only affects the intermediate output.  We need to jump to HTMLBase.pm and modify the method NDMarkupToHTML so that we can generate the proper tag structure.  Here are my modifications:

# [CHUCK] ORIGINAL: my @splitText = split(/(<\/?code>)/, $text);
my @splitText = split(/(<\/?code *(?:class=[^\>]+)?>)/, $text);

while (scalar @splitText)
	{
	$text = shift @splitText;

	if ($text =~ m/^(?:<code *(?:class=([^\>]*))?>)$/i)
		{
		$output .= "<blockquote><pre class=\"brush: $1\">";
		$inCode = 1;
		}

You can see that here, I changed the regular expression used to split the intermediate output into chunks to properly split on the new markup structure.  In the if-statement, I changed the eq comparison to a regular expressoin match with a capturing group and inserted that into the output <pre> tag (for the win!).

Now be warned: this is not a complete fix.  While this addresses the major issue, generation of the proper output, I did not make changes to copy the image files and JavaScript files required by SyntaxHighlighter (sorry, you're going to have to do that yourself :-P).  The next set of steps are to:

1. Copy the images associated with SyntaxHighlighter to the \output\styles directory (or whereever you like).
2. Copy the scripts required for SyntaxHighlighter to the \output\javascript directory.
3. Modify the paths in the CSS for the icons used with SyntaxHighlighter (in the shCore.css file).

Of course, the themes and CSS files are easy to include since you can specify those at the command line.

That's all there is to it!  Happy documenting!  I've attached sample files (including the modified source) for SyntaxHighlighter 1.5 and 2.0.

natural-doc-sh2.0.7z (315.01 KB)
natural-doc-sh1.5.7z (281.7 KB)

I've previously posted on how to move compiled binaries into a remote GAC automatically from your development environment to your SharePoint environment using SysInternal's PsExec utility.

But what about moving content files from your SharePoint environment to your development environment?  When I'm developing content for layout pages (ASPX, js, css), for the most part, I don't want to develop in Visual Studio; I will usually use EditPlus (my weapon of choice) and edit the files directly on the remote server.

However, this poses a problem: synchronizing files between the SharePoint environment and the development environment.  It's quite time consuming and painful to do it manually since you may have to dig through various directories and keep tabs on which files you've edited on the server.

Enter 2BrightSparks' SyncBack utility.  Using this, I can create a synchronization automation between my SharePoint environment and my development environment.  And because I've set up my files to have the same structure on both sides, it's easy to set up the synchronization settings.

The image above shows the layout of my project. You can see in the image below at the directory layout mirrors the project layout, making automated synchronization a snap.

Working smarter > working harder.

I've come across a small number of AJAX animation progress generators and a few pages with a fixed listing of generators, but Ajaxload is by far the best one I've found so far:

Very well designed (and useful) little utility.

The best devtool ever? Or the best devtool ever?  You decide; I present the fantabulous Terminals.

Once you've lived with it, you can't live without it.

It addresses several shortcomings with the default RDP/Terminal Services client in Windows, namely:

• Lack of support for tabbed viewing of connections (who likes to have 5 different Remote Desktop windows open?).  Terminals supports tabbed browsing of Remote Desktop connections.
• The need to save one .rdp file for each connection...what a pain in the butt!  Terminals supports saving of the client connection information for you automatically.  Not only that, it can add configured connections to a toolbar for easy access (instead of hunting down saved files).
• Lack of tools for connectivity testing.  With the default MSTSC, it requires you to jump to the command line to run ping and other utilities when testing for connectivity.  Terminals has it built in!  Awesome.
• No support for connection groups.  Quite often, when working with VMs or remote machines during development, you have to access the same group of machines at the same time (for example, a server and a client).  With the default MSTSC, you have to manually start the two connections or write a batch file to open them at the same time.  Terminals has a grouping feature which allows you to initiate grouped connections automatically.

During development, even with VMWare running locally, I prefer to use a terminal services connection instead since it's way more responsive to user input.

Terminals is definitely awesome.  There are still a few issues like auto-scaling and auto-resizing which don't work quite right yet, but otherwise, it is fantastic.  Note that it also doesn't support connecting disks and printers and what not (maybe next release).

Okay, so this isn't strictly a development tool, but Gantt Project has a pretty nifty, free, project management application.

With GanttProject you can break down your project into a tree of tasks and assign human resources that have to work on each task. You can also establish dependencies between tasks, like "this task can't start until this one is finished". GanttProject renders your project using two charts: Gantt chart for tasks and resource load chart for resources. You may print your charts, generate PDF and HTML reports, exchange data with Microsoft(R) Project(TM) and spreadsheet applications.

The site also mentions a good point with regards to Project:

• Good (and growing!) set of basic features. This set is enough for most people (remember that 80% of MSProject customers use 20% of it's numerous features)
• Easy learning. You don't need thick manuals to start working with GanttProject. If you are familiar with the notion of tasks, assignments and dependencies, you'll become an expert in GanttProject in a couple of hours.

Check it out if you're in the market for a free, simple, task based project management.

Wow, it's been a looong time since I've added one of these.  I have a whole backlog of tools that I could add, but let's get to one of the important ones:

One of the really annoying things about Visual Studio is that renaming a project in the IDE doesn't change the name of the directory in the file system (or your source control).  Of course, updating the string in the code files is not so bad, but then you also have to go through all of the project and solution files to change all of those occurrences.

That's where the _REPLACE.EXE utility comes in.  Using a series of commands like the following:

_replace.exe "<old-string>" "<new-string>" /i /s /ext=.csproj
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.sln
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.cs
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.resx
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.config
_replace.exe "<old-string>" "<new-string>" /i /s /ext=.xml

You can pretty much replace most of the string names in your project by using that set of commands (and additional ones for any other file extensions).  What's cool is that you can also use the /t command line switch to do a dry run.

Very handy indeed.  Do keep in mind that you still have to go in and manually change the directory names but it's far more efficient than twiddling around with a text editor to replace the string in each of the project/solution files.

So my interest in NHibernate is picking back up again.  The 1.2 beta release that's circulating now (the candidate release has been out since February of this year) addresses various issues with NHibernate in my previous time with it.

Specifically, the biggest issue was native support for generic types.  In addition, it seems like there are various other goodies in the 1.2 release such as stored procedure support.

And to think, I just got the team to standardize on Microsoft Enterprise Library 3.0.  I'm wondering how to break this to the team.

I guess in a sense, they are not completely incompatible.  Roll your own queries and data access routines are still the way to go for more complex queries (does NHibernate handle FOR XML EXPLICIT?) and anywhere high performance is critical.

The beauty of this whole thing is that as NHibernate has gained traction since the first time I used it like 2 years ago, the tool support has evolved tremendously.  Combined with MyGeneration and user templates, I was up and running (although the generated output had some minor errors in the XML mapping file) in minutes.  Not only has the tool support improved, the documentation has improved as well.

There is still some conflict, internally, as I was just ragging on LINQ last week with another group of developers for the simple fact that it creates a tight coupling between code and the raw data.  Whereas with stored procedures, you can have dedicated DBAs write highly performant code and you can modify the underlying data retrieval and layout so long as you maintain the same resultset, with dynamic queries, you lose a lot of that flexibility.  In addition, you lose a bit of testability as well since many times, it's just really helpful to be able to test the SPROC independently of any code (or perhaps breakdown subqueries in the SPROC to test small subsets of data).

In actuality, I think that having the mappings as XML is probably better than using LINQ since the XML mapping files can be loaded at runtime, meaning that the deployed mappings can still be manually updated whereas LINQ would necessitate a recompile of the source (my understanding of it).

So if you haven't checked out NHibernate for a while, now's a good time to get a refresher and re-evaluate the library.  I think it will still stick around even after LINQ is released.

Anyone who has used the .Net XmlSerializers have surely encountered the dreaded namespace bloat which makes the serialized objects grow to ridiculous sizes.

There's a nice little article over at TopXML on how to deal with this bloat.

If you're using WSCF, on the client stub, I've gotten into the habit of writing custom serialization overrides in partial classes which ensure that if the client needs to serialize objects into XML, I'm doing so in an efficient manner.  It'd be nice to see it added to the server side class constructors as well.  Add your vote for this feature over at the WSCF dicussion boards.

Spring.Net is an application framework which has its roots in the Spring Framework for Java.

Now first of all, I know many developers have an averse reaction to the use of the phrase "application framework" and immediately reject such things without second consideration.  I always hear tales that begin like so: "Well, on this one project, we used an application framework and it ended up not doing anything exactly the way we wanted and we had to modify it anyways..."

Four thoughts on this:

1. No two applications are exactly alike.  If that were so, we'd all be out of jobs as software engineers because it'd probably have already been done before.  As well, no two application frameworks are alike (although on some level, Spring is interchangeable with Castle).
2. Spring, I have found, does not restrict me in anyway in terms of my solution design.  If anything, it frees me to use more flexible designs and allows me to create much cleaner and better designs.  Inversion of Control is your friend.
3. Spring includes the source.  Dude, if it doesn't do exactly what you want it to, you are 100% free to modify and reuse it (and maybe even resubmit it to the project if it's well written and useful).
4. The documentation and development team on Spring (and Castle to a lesser degree) are great.  The documentation is very thorough and well organized and the developers are constantly monitoring the discussion forums and reaching out to users.  Many times, with any sort of large library, you may be under the impression that it doesn't do something (thus leading you to believe that you have to write it anyways and believing that it was pointless to use the framework), but it may actually be the case that you simply haven't found the facilities in the library to accomplish your task.

On top of this, the support forums and developers working on the framework are great resources for hashing out design ideas (outside of one's normal circle of peers).

Yes, it's true, Spring requires the use of what can become massive XML configuration file(s).  Yes, it can be difficult for first timers to grasp inversion of control, understand what exactly it is that Spring offers, and in general, find anything in Spring that would significantly make one's life easier as a developer without a learning curve.  Yes, Spring is huge; it encapsulates a lot of "stuff" that can be confusing and seem like bloat one's first time encountering it (I myself only ever use a small subset of the features of Spring).

However, in the end, I think Spring brings so much to the table (too much for me to list here), it's hard to discount it without at least giving it a real evaluation.  For any sort of non-trivial application, Spring allows the designer to add much more flexibility and decrease the complexity of the codebase by encapsulating a lot of the dirty work.  (I would agree that there is a complexity cutoff where if your application sits below this cutoff, it's simply not worth it to include Spring in the discussion, as the time it takes to understand and find its usages in your scenario would not be worth it).

I've been using Spring for almost a year now and I simply can't imagine writing an application without it.  With the latest release, the introduction of the data access library, Spring becomes even more compelling by removing a lot of the boilerplate code that one would write when performing data access.  Admittedly, in a sense, it is a replacement of one set of boilderplate code for another, but it is a much more elegant design than using raw ADO or even Enterprise Library for that matter.  Spring introduces the usage of a delegate/callback pattern for "rendering" the returned data rows and sets into domain objects and sets.

I use the term rendering because this is the same exact pattern that I've been using with regards to the JavaScript that I've been writing for my AJAX enabled applications.  It's an elegant pattern that, in JavaScript, allows for decoupling of the code to retrieve that data from a web service and the code that renders the data.  In a sense, Spring does the same, except, instead of rendering a UI, it renders a domain object (or set) using the delegate, which decouples the data access plumbing from the building of the domain object.

Having used NHibernate previously, I have to say that in many cases, I still prefer performing my own data access code and domain object rendering as it allows me much more flexibility and control.  There is less processing overhead and not to mention (when I last checked) NHibernate still does not natively support generic types.

I've mostly been sticking with Enterprise Library, which is basically just a step above raw ADO, but I'm gonna give this a shot since it's yet another step or two above Enterprise Library.

On another note, it seems like Microsoft's Patterns and Practices Group is finally releasing the next version of Enterprise Library.  In a sense, EL is a "necessary evil".  As far as 2.0 goes, I cannot say that it does anything particularly better than other libraries that fill the same purpose as any given block, but what it does do is it encapsulates multiple functional spaces (logging, data access, exception handling, configuration) into one.  In addition, having the Microsoft Seal of Approval also helps with acceptance.  As an example, the rolling flat file trace listener has had a counter part in log4net since I've been using it (over 1.5 years now).  The data access application block, while it does clean up data access code, is still pretty close to raw ADO.Net usage patterns; in other words, it brings almost nothing to the table (almost; I still endorse it over raw ADO.Net to be sure).

It'll be interesting to see what this Object Policy Application Block actually does.  It seems like it's conceptually similar to Spring's IApplicationContext or Castle's Windsor Container.  I'm not one to latch onto a product simply because it's from Microsoft's P&PG, so I'm hoping they can actually bring something new to the table to make their library more compelling than Spring or Castle (both of which are much more mature by now and encapsulate a far greater set of features).

As for the any concern over the longevity of Spring and Castle, I feel pretty confident that what happened to NDoc, will not be happening to Spring or Castle.

Welcome to another entry of Random DevTools!  It's been quite a while since the last post, but the wait is worth it!

Well, what we have today is a general tool that's sure to help anyone out.

As a developer, I spend so much time launching a variety of applications.  Visual Studio, web browers, digging through my project directories, Query Analyzer, and so on.  It can be quite tedious to have to trod through the Windows Start menu.

Fortunately, there are a variety of application taskbars out there like ObjectDock, for example.  But I've found ObjectDock to be a little too fancy for my simple needs and a little too resource intensive on my laptop.  In addition, I recently had a weird error with it on my wife's laptop where it would cause the task bar to disappear (even though I did not set the option in ObjectDock)...took quite a while to figure out that it was ObjectDock causing it.

Enter Kana Launcher.  This is exactly what I've been looking for in terms of application task bars.  It's small, simple, lightweight, easy to use, and performant.  What I like best about it is that the little floating task bar shows up where your mouse is, so getting to the application you want to launch only requires the minimal amount of mouse movement.

Kana Launcher also has a full size listing (like a context menu) with folders where you can organize all of your applications and what not (the floating task bar is a subset of the full list).

Best of all, it's free (and we always like free on the Random DevTools list)!

Note that you can add all sorts of launchers to it.  You can open up to a specific folder.  You can open up FireFox or Internet Explorer to a specific URL.  You can
launch command line applications with arguments in it.  All you have to do is create an application shortcut on your desktop and then drag it over to the Kana Launcher.

Web development in IE just got a whole lot better (well, at least for me).

Enter Microsoft's Internet Explorer Developer Toolbar (link).

This is one area where IE has been just left behind in the dust by FireFox.  But this is definitely a nifty add-on!

Just a short outline of the features:

• Built in validation from a dropdown.  Nifty and convenient.
• Built in onscreen ruler!  This is awesome.
• Ability to quickly resize the window.
• DOM browser like FireFox.

And a ton of other stuff.

If you make webpages for a living, then all I can say is: Must. Download. Now!

Note that after installing it, you have to enable it by selecting it from the View->Toolbars menu item (it's instinctive to look in the Tools menu and get baffled by the lack of new menu items).

Update: there's also a non-Microsoft, FireFox analogue.

Today's entry is Windows Installer XML (WiX for short), an open source project (the first?) from Microsoft that is used internally by Microsoft development teams for building installers for many of their products.

I first used it more than a year ago when I was at Merrill Lynch.  I had to build an installer for a Windows Serivce and I wanted the service to auto-start after installation.  I was totally baffled by how to do this in the VS installer projects (is it even possible?) and somehow ended up stumbling across WiX.  It worked great It was a little rough going because there was so little documentation and Net knowledge regarding usage.

Since then, I haven't really had a reason to look beyond the built in VS installer projects, but I'm working on another complex installer scenario now and decided to check in on WiX again.  To my surprise, there still doesn't seem to exist a UI to design WiX installation packages (at least none that I came across via googling).

However, I did find a very well done tutorial.

Of course, Rob Mensching's blog is full of news and developments on WiX.

Rob mentions in his first post on the subject of WiX that:

Internally, teams such as Office, SQL Server, BizTalk, Virtual PC, Instant Messenger, several msn.com properties, and many others use WiX to build their MSI and MSM files today.  When someone encounters a bug, the community tracks the issue down and fixes it.  Now, via SourceForge.net, you have an opportunity to be a part of the community as well.

I guess it's also good to note that WiX just celebrated it's 2-year OSS status recently.

Oh yeah, we're kicking it up with the DevTool entries.

That's typically what happens as I ramp up on a project; I'll end up coming across a whole slew of awesome tools that I end up aggregating in my C:\Program Files directory (my application menu is about to go past the second page...I had to uninstall a lot of stuff previously to get it back down to two pages).

Today's entries are tools to help you think "contract first".  I hadn't really thought of XsdObjectGen.exe as a tool that helped you work in a contract first fashion, but Peter Bromberg seems to think so and so does David Truxall.

Unfortunately, XsdObjectGen.exe, as great as it was, is ill suited for .Net 2.0 and the introduction of generic types and lists.  I briefly contemplated using it for my .Net 2.0 project that I'm on now, but couldn't bring myself to it; there must be a better way, right?  Well, up until now, the only other .Net solution that I had come across was Matias Wozloski's GAT implementation (with slight modification?) of Daniel Cazzulino's (kzu) version of XsdObjectGen.  Having looked at that and the new xsd.exe that ships with VS2005, I have to say that I'm sorely disappointed in both since they rely on the XmlSchemaImporter and XmlCodeExporter classes to do their dirty work.  The resultant markup is not nearly as nice as the output from XsdObjectGen.exe.  As I've mentioned in the past (see the end of my workshop on XsdObjectGen.exe), while kzu's implementation is obviously much more flexibile since you can create new extensions and what not, it is ultimately somewhat clunky and not as easy to work with.

I briefly contemplated extracting the source from XsdObjectGen.exe and rewriting the codebase (it uses sort of an "intelligent templating" approach) to utilize some of the .Net 2.0 code features and generate better code, but after digging through it with Reflector, I realized I didn't have enough time (and I probably didn't have the rights) to extract and rewrite the codebase.

Enter dingo and thinktecture's WSCF.  While dingo is still strictly a .Net 1.1 tool, the project leader has a recent news item that claims forward development will continue this summer after some more work on a rules engine (anyone know of .Net APIs for working with RuleML?).  WSCF, on the other hand, looks like it's good to go with respect to .Net 2.0.

So have a look at WSCF.  I'll be downloading and evaluating it today and keep this updated with my take on it.

Update: See comments.

I installed an updated version of the NUnit VS add-in (aka: TestDriven.Net) today and discovered this little tool called NCoverExplorer.  Curious, I started to dig into it and that lead me to NCover.  NCoverExplorer is a GUI interface to NCover output files. 

What is NCover?  It generates code coverage information when it runs your NUnit tests so that you can see how much of your code base your tests are really touching (I perfer the output from Cenqua's Clover.Net, but I guess that's just a matter of using a better XSL transform?).

Both are great tools and should work their way into your development cycle!

It helps to have a simple batch file to run it:

"C:\Program Files\NCover\NCover.Console" "C:\Program Files\NUnit-Net-2.0 2.2.7\bin\nunit-console.exe" "..\bin\debug\SomeProject.Tests.dll"

PAUSE

In an automated environment, you'll want to take out the PAUSE.  It's only there so that if you're running it manually, you can watch the result of the run.

Every developer/graphic artist hybrid like me eventually comes across the need for some spiffy icons to go with our badass applications.

Good icons are hard to find.

Good free icons are harder still.

So it's a rare moment when I come across good, free icons.  So I must share

http://www.famfamfam.com/lab/icons/

Excellent icons.  Enjoy.

While browsing the Dojo Toolkit site today, I noticed their bug tracker.

Hey now, this looks sharp!

Turns out it's this product called Trac by Edgewall Software.  Best of all, it's open source!  Looks good.  I'll have to see if I can convince anyone to use it.

I have to say, I've taken a long look at Bugzilla and the thing that turned me off (I know, it's rather shallow of me) is the sub-par interface.  I guess it was designed to be highly portable across browsers and platforms.  But damn, it looks like they didn't even bother making it a bit more attractive.

The TracBrowser feature is great too!  Code browser, HTML diff viewer, and all hooked into Subversion.  Incredibly awesome.

Maybe it's a good time and incentive to learn some Python? 

Random link: some Python IDEs reviewed.

(Random) Update: I spent some time whipping together a nifty little Subversion _svn directory cleanup script It's great.  Simply download the file or copy the contents into a new .vbs file.

I've been meaning to do this for quite a while.  It's written in VBScript and based off of another script (which, for the life of me, I cannot remember where the original source is from).  You will need to have Windows Script Host installed (I believe) to be able to run this script.  Simply place it in the root directory of your project and it will remove all "_svn" directories in the context directory (directory you placed it in) and recursively into the sub-directories as well.

There is one confirmation dialog that allows you to change your mind and cancel the deletion if you double click it by accident.

Just the thing you need when zipping up and sending a project to someone without a Subversion client installed.

Enjoy!

I'm feeling a mighty JavaScript kick lately.

What's interesting is that the more C# evolves, the more it starts to resemble JavaScript.  What with anonymous methods, type inference (it even uses var), and the LINQ syntax, my JavaScript juices are flowing.

There are a few things that I never wrapped up with my JavaScript development experience.  I think the most glaring one is JavaScript inheritance.  Some would argue that JavaScript inheritance is purely fluff (see second comment); it's not needed and JavaScript is probably more powerful for not adhering to OOP principles.

I dunno...it seems like one of those things that would be useful for building certain structures and UI elements.

I've been aware of Douglas Crockford's implementations for quite a while now.  I came across it when I first picked up on JSON about a year and a half ago, but I never particularly liked it since it "looked weird".  So today, as I was looking around to see if any alternatives have risen due to the recently revived JavaScript development, I came across a posting on SitePoint.  I rather like the simplicity of it all and it looks like it works, so I'll have to keep that in mind if I need to use it.

As I'm also thinking about writing a major web based rich UI application in the next few months, I've also been looking at some of the JavaScript libraries, toolkits, and frameworks that are out there.  I came across the Dojo Toolkit today and it looks fairly interesting.  I especially like the bind() syntax.  However, the toolkit does seem somewhat incomplete at the moment...I'll have to take a look at it in more detail and see if it has the features I need.  It's currently lacking any demos, which makes it hard to evaluate without a deep dive.

This brings up another interesting issue that has annoyed me with the proliferation of all of these JavaScript and AJAX libraries: instead of pooling talent and building The Best Possible Solution, we have teams going off left and right building 15 different impelementations of the same thing with 15 different design principles and 15 different philosophies.  Now this isn't necessarily a bad thing, as there are times when you would prefer a lighter implementation to a heavier one, for example, but it would make a hell of a lot of sense to have at least a common convention in terms of naming, package layout, and what not.  Ideally, what I'd like to see is some of these development tracks merge so that we may have more complete frameworks/libraries/toolkits.  Have one mega package that comes in mega-lite flavor, you know? 

With so many libraries/frameworks floating around, it makes it difficult to find the exact set that does what you need and if you do, you need to start worrying about whether they'll play nice.

I'll stop, because I'm just ranting now

I've been doing some WinForms work lately (I'm primarily a WebForms developer) and had a lot of trouble working with the WinForms DataGrid.  Primarily, the DG just seemed very difficult to customize in terms of behavior and look & feel.  Whereas with the WebForms version of the DG, the declarative model and the power of CSS makes it a snap to do these things, the WinForms version just took way too much work.

So after looking around and trying a few open source controls, I finally stumbled on DevAge's SourceGrid3.  I really like it.  It allowed me to do things with a grid that simply were waaaaay too time consuming/difficult with the out of the box WinForms DG, which is just too tied into the DataSet model and doesn't work very well with custom business objects and typed collections.

It does take some time to pick it up, but the MVC design of the library makes the code very clean and extremely flexible.

The Source Pack also comes with a variety of other controls for WinForms development.  Definitely worth a look for any WinForms developers looking for more flexibility in grids.

DHTML Edition.

Came across an awesome listing of DHTML resources today via weblogs.asp.net.

Just a short snippet:

• 3 Column Holy Grail.  For good reason, clean, search engine optimized CSS layouts have been hot in the web design space for quite a while.  I really got into it when I was working at Factiva.  Up until that point, I didn't even know that such techniques existed.  Well it seems like someone has finally pulled it all together into one super clear layout.  I marvel in the simplicity...
• Qooxdoo.  Wow.  I am blown away by what's capable with this library.  Definitely worth a look, particularly the windowing capabilities.  The last two web based projects I've built have used custom windowing libraries which are definitely not as well developed as these libraries are.  Now I'm salivating to build something cool with it
• dp.SyntaxHighlighter.  I've actually been thinking of writing just this!  Amazing stuff, really.  At the moment, I'm mostly using an external tool to colorize my code and pasting it as HTML...this looks like a much better solution.
• DOM-Drag.  Looks good.  Last DHTML front end project I was on, I spent way too much time making drag-drop work.  However, the performance does seem a tiny bit laggy on some of the demos.
• Nifty Corners.  Looks interesting...people seem to like the rounded corners look...I've always been too damn lazy to make rounded corners
• moo.fx.  This library looks great...very performant and easy to use.
• script.aculo.us.  A more heavyweight and full featured effects library.
• Behavior.  I'm really digging this one...check out how clean the demo pages are.  Very nice.
  

And there's also a boatload of AJAX libraries listed as well...way too many, I'd say.

But I digress.  Some of these libraries just make me giddy.  But I'm weird like that.

Just one entry for today.

I was looking around for a free XPath expression tester online.  Surprisingly, it took me at least 20 minutes to find a free one.  Altova XMLSpy Home Edition, while free, does not include an XPath evaluator (it's an add-on in the professional edition).

However, I did find Dimitre Novatchev's excellent (though ugly as hell) XPath Visualizer.

Great tool (although the UI is ugly)!  And you just can't argue with free

From time to time, as I'm working on projects, I invariably come across great sets of tools that make my life just a bit easier.  My plan is to list the tools, test them out, and rate them somehow after I get some usage.  I guess this is my way of sharing with the world

So for the inaugural entry, we have two tools and one library:

• FaceID Browser.  When creating custom add-ins for Office applications, you can create a command bar button (CommandBarButton) and apply an existing Office icon using the FaceID property.  This tool allows you to visually map the integer values to the icons.  I've tested it to work with Office 2003.
  
• Xsd Generator with GAT.  For some reason or another, I like the idea of working with XML schemas when building an object model; schemas seem much more natural to me than working with classes in code.  In addition, you get nice XML serialization markup for free Matias Woloski has written a custom generator for .Net 2.0.  I'm gonna give it a look-see. [Update:1] The binaries that are currently on the GDN website are not compatible with the RTM versions of VS2005. [Update:2] Holy crap.  After several hours of fiddling, I finally got it to install.  Damn, the December CTP of GAT extensions is still buggy as hell.  For some reason or another, uninstalling the Xsd Generator after installing it would also remove all traces of the Microsoft.Practices.RecipeFramework dlls. WTF? So this would necessitate reinstalling the GAT extensions.  On top of that, the December CTP changed the default namespace on the configuration file from http://schemas.microsoft.com/pag/ipg-core to http://schemas.microsoft.com/pag/gax-core took me at least a half an hour of digging to find this info.  The other really stupid thing is that you can't change the config file after install without reinstalling...another big WTF; I mean, isn't that the whole point of having an XML config file?  I also had to rebuild the references in two of the projects and add a missing reference to Microsoft.RecipeFramework.Common.Library.  But in the end, it's worth the effort!  I dig the fact that it generates generic lists instead of typed collections (typed collections are soo last gen. ).
  
• Microsoft Updater Application Block.  Looks useful for anyone currently building lots of application add-ins for any of the Office applications as it will allow you to keep clients up-to-date without having to redeploy with each update.  There's an article over at TheServerSide.Net on usage and details.
  

That's it for now.  Look for more installments in the future.