A couple of weeks ago, Kirill Osenkov posted an interview question that got the attention of a few .NET developers, myself included.  Like a moth to a flame, we were all eager to present a solution to this interview question:

In a given .NET string, assume there are line breaks in standard \r\n form (basically Environment.NewLine).

Write a method that inserts a space between two consecutive line breaks to separate any two line breaks from each other.

Roughly 20 answers were given in the comments to Kirill’s post, some with subtle differences, some with completely different approaches.  Some were even written in F#.

When I first saw the interview question, I very quickly came to my answer:

   1: string output = Regex.Replace(input, @"(\r\n)(?=\r\n)", "$1 ");

My answer uses Regular Expressions, which is a concise language to search text, sometimes in complex ways.  I first became aware of Regular Expressions in 2004, and I was immediately enamored with them.  I had always written complex search functions using operations like IndexOf() or directly accessing character arrays.  Text searching always seemed slow to me, but I later realized that it was just my poorly written code.  Very quickly I dove into learning the Regular Expression language (at least the dialect in .NET), and found many uses for it.

I’ve found since then that many developers are either unaware or fearful of Regular Expressions.  I’ll admit, some expressions that I’ve seen look very cryptic and intimidating.  But they are very powerful.  Plus they have the benefit of usually being very fast (although you can write slow ones).

During the discussion in the comments of Kirill’s post, it became obvious that performance is something to be considered in such a routine.  As a result, Rik Hemsley commented that he had created a benchmarking test bed to run each suggested solution.  Here are the results:

My solution came out as the best performing.  I say this, not to gloat - because in reality I’m just using what Microsoft wrote for us to use. I say it because I wanted to show that knowing about and using Regular Expressions is important when you need to parse text.  I’m sure that someone could come up with a better performing solution, but for a one-liner, Regular Expressions are hard to beat.

If you interested in learning about Regular Expressions in .NET, the MSDN documentation is pretty good.  Plus there are books that you can read on them as well as sites that have examples.

Jason Bock recently wrote a post on turning WPF Binding errors into exceptions.  When I first started to get into WPF development, I too found that the binding system was significantly better (i.e. actually worked) that Microsoft’s previous attempts to do UI binding.  That said, I also found, as Jason did, that WPF’s binding system was less than helpful when you fat-fingered a binding.  I did learn that there we many ways that you could get debugging output from the binding system, but I never took it to the level that Jason did and turned the binding errors into exceptions.  I’m sure I’ll find his binding extension useful in the future.

Sometimes Invisible Binding Errors are Okay

However, I did make a comment on Jason’s post that later on I found a use for not having exceptions be thrown on data binding issues errors.  There is a pattern that I’ve used on one or two WPF applications where I host a collection of “screens”, which are just UserControls, in a single Window, and the visibility of the UserControls is driven by the DataContext of the Window.  The DataContext is both a ViewModel in the Model-View-ViewModel pattern, and an implementation of the State pattern.

The difference is that, in a traditional State pattern implementation, you typically have a base class or interface that defines all of the input or operations that all the states need to respond to.  However, with a state-based ViewModel and WPFs dynamic binding system you will see this is not necessary.

Let’s start with a simple scenario, a wizard-like, step-by-step WPF application for taking simple feedback comments from users.  Let’s say the list of states is: AskForComment, CaptureName, CaptureEmail, CaptureText, and Thanks.  Clicking the next button will transition from one state to the next, changing the DataContext of the Window to the new state.  As the state changes, the WPF binding system will be notified of this.  It will attempt to rebind the visibility of all the UserControls to the new DataContext, which is the new state, and depending on the state, different UserControls will be visible.  The UserControls that are not visible, will have binding errors, but since they are not visible and thus not in use, the errors can be ignored.  The user can happily enter information into the newly visible control, unaware of any errors.

I’ve created a sample application that shows one way this could be implemented. If you look at the MainWindow.xaml, you will see five UserControls that represent the different views as the states change.  Each of them has their Visibility property bound to the current state through a StateVisibilityConverter.  Inside each UserControl, various elements are bound to properties on the DataContext that may or may not exists, depending on what state you are in – but again, that doesn’t matter – if the properties don’t exist, the UserControl should not be visible.

The key takeaway is that sometimes you can use the lack of exceptions on WPF binding errors to your advantage, and I would venture a guess that Microsoft decided not to throw exceptions on binding errors to enable scenarios like this.

If you’re at all interested in Oslo, you may be looking forward to the 2009 PDC to see the direction it is going to take.  As of yesterday, we got a small preview of that direction – and to be honest, without having all the nitty-gritty details that I hope will come out of the PDC, I’m concerned and disappointed – and I’m not the only one who feels this way.

“M” Interacting with the Database – Please Don’t!

I understand that using DSLs and modeling is an excellent way to capture and manipulate data that can be used by applications.  However, this quote from Doug’s post is what concerns me (emphasis is my doing):

Time after time we heard that “M” would make interacting with the database easier

The “M” language and tooling should have absolutely nothing to do with interacting with the database.  The fact that Microsoft has heard “time after time” that people would like to use “M” to interact with the database strikes me as a problem with many people not understanding what I believe “M” was envisioned to do and should be used for.  “M” (MGrammer, MGraph, MSchema) and its supporting tooling should be about the definition and runtime representation of models and languages used to create and manipulate instances of models.  It is my strong opinion that this functionality should have no direct dependency on databases or database interaction.  The core foundational value I saw in Oslo was a shared platform providing:

• A DSL definition language (MGrammer)
• A lowest common denominator representation of a model (MGraph)
• Model schema definition and validation (MSchema)
• Tooling (Intellipad, m.exe, possible VS integration, etc…)

What is so sadly ironic is that Microsoft recognized this from the beginning.  During many presentations at the 2008 PDC, the bond between developers and text and text editors was mentioned.  Microsoft knew they needed to have a first class story to tell when it came to text, and that was how “M” was born.

The Repository and Quadrant

My opinion of Repository is that it is a mistake to try to tackle Repository with the first release of Oslo.  Even during the 2008 PDC presentations it felt like the Repository was a solution in search of a problem.  I understand the value in being able to use models to define runtime execution characteristics of an application (e.g. HTML, XAML, WCF Service Descriptions, etc), but how many have you seen that execute their models from a SQL Server database?!?!? There might be a small class of applications where it makes sense to store and execute a model from a database, but my guess is that more often than not a model would either be stored in or transformed into something that looks nothing like a database.  Perhaps it would be embedded into an application redistributable as code or an embedded resource or persisted as a file.  Perhaps it is never persisted.  Regardless, if the model is to be persisted, that should be a separate responsibility.  Repository is a “nice to have”, but honestly I can’t see using it much, if at all.

As for Quadrant, I don’t feel versed enough in Quadrant’s capabilities to voice a strong opinion.  I do see value it having a common tool for visualizing and manipulating models.  However, I would spend my “development dollars” less on Quadrant for Oslo’s first release, and more on the “M” language and tooling.

Concerned, but Hopeful

Douglas has made it clear that there is more information coming about the “M” and DSL story.  I for one hope that “M” can stand alone from Repository, Quadrant, SQL Server, and anything to do with databases.  If this is not the case, I hope the Oslo team hears loud and clear that it should make some fundamental changes.

However, if “M” does stand alone, this post and the comments from others should help to keep it that way – even when “time after time” people associate “M” with database interaction.

The last time I talked about iSynaptic.Commons was in July of 2008.  Basically I said that I was putting the release on hold.  Well, I’ve finally released it under the MS-PL license.

My reason for releasing it is by no means because it is complete.  It is no where near there.  I’ve got a lot of work yet to do on it, and I’ve got many things that I want to completely change or remove.  So my recommendation is that you don’t go use the code in a project you intend for it to keep stable, because it is going to be a moving target for now (i.e. there will be breaking changes).  Especially the Text.Parsing namespace and the Xml namespace.  Those were very naive and simplistic, and I will be replacing.

However, my primary reason for releasing it is to get feedback.  I don’t expect much at first, but I want it to be something I can talk about in this blog, and solicit direct feedback about specific parts of the framework.

Finally, I talked about iSynaptic.SolutionBuild and iSynaptic.Modeling in my previous iSynaptic.Commons post.  SolutionBuild exists and is in partially working order.  I will, at some point, be working on moving this into a public repository.  I may even change SolutionBuild to be based on PowerShell, and possibly psake.  As for the Modeling project, I’ve re-envisioned it under a different project I’m calling iSynaptic.Core.   Currently Core doesn’t exists (other than the repository being stubbed out), but what I wanted to accomplish with the Modeling project will be wrapped into the Core project.  Core will depend on Commons (Commons being a lower-level framework).  Likely, some of what is in Commons will be pushed into Core – I want to keep Commons lightweight, but useful.  Besides rolling Modeling into Core, details on what Core will be is something for a future post.  I don’t necessarily want to talk about it, until I have something to show.

Initially, my activity on all of these initiatives will be light.  I have numerous projects that are work related that I need to complete, and other non-development personal obligations as well.  This is just me taking the first step…

Nate Kohari, of the Ninject fame, and his bride Nicole have just launched a new company and a new product, Agile Zen.  Agile Zen is a project management tool that emphasizes lean principles, drawn from the work done in the Toyota Production System.  I’ve not been able to interact with the site yet, but from the feature walkthrough it looks very clean and very powerful.  Having had a chance to look at the source code of Ninject and see the genius in its design and implementation, I can only expect the same out of Agile Zen.

I’ll be keeping an eye on this one!

Advertisment for Typemock Isolator ASP.NET Bundle:

Unit Testing ASP.NET? ASP.NET unit testing has never been this easy.

Typemock is launching a new product for ASP.NET developers – the ASP.NET Bundle - and for the launch will be giving out FREE licenses to bloggers and their readers.

The ASP.NET Bundle is the ultimate ASP.NET unit testing solution, and offers both Typemock Isolator, a unit test tool and Ivonna, the Isolator add-on for ASP.NET unit testing, for a bargain price.

Typemock Isolator is a leading .NET unit testing tool (C# and VB.NET) for many ‘hard to test’ technologies such as SharePoint, ASP.NET, MVC, WCF, WPF, Silverlight and more. Note that for unit testing Silverlight there is an open source Isolator add-on called SilverUnit.

The first 60 bloggers who will blog this text in their blog and tell us about it, will get a Free Isolator ASP.NET Bundle license (Typemock Isolator + Ivonna). If you post this in an ASP.NET dedicated blog, you'll get a license automatically (even if more than 60 submit) during the first week of this announcement.

Also 8 bloggers will get an additional 2 licenses (each) to give away to their readers / friends.

Go ahead, click the following link for more information on how to get your free license.

Ayende Rahien (of the Rhino Mocks fame) wrote a post on his blog about “burning” Common/Utility libraries.  I have to agree with his reasoning on why his Rhino Commons library should be “burned”.  As I understand from his post it is a “garbage bin” or dumping ground for any random functionality that might be reusable.  He pointed out that his library has very low cohesion, or in other words the library isn’t really focused on a fixed, finite set of responsibilities.  Again, I agree with this reasoning.

However, I’m concerned that this might also encourage the other extreme: never creating common libraries and copying/pasting code from one project to the next!  In my opinion, this is just as bad or even worse that having a common library.

Having a common library can be both useful and powerful, but it needs to be treated as its own project – or shipping product, if you will.  Versioning, backwards-compatibility, proper API design, application of common API patterns, cohesion – these are just some of the things that you need to think of when designing a library.  Designing a library requires at least one, if not more, architectural and design minded developers to really manage and ship a common library throughout its lifecycle.  One thing often overlooked is deleting/obsolescing code, as well as reorganizing (or refactoring – what ever parlance you prefer) code into different namespaces and assemblies.  Also, one must not shy away from moving library code into different Visual Studio solutions (or whatever solution/project system being used) or to different locations in your source code repository.  Reorganizing applies not just to the contents of your library code, but also to how you work with your library code.

This is even the case with .NET itself. Granted, Microsoft doesn’t always get it right, but they’ve done a decent job.  If you look at the Base Class Library shipped with .NET, there is a TON of functionality, broken into assemblies, namespaces, and types.  This I think is very important when you are designing a library or suite of libraries – organization.  How you break functionality apart, especially at the assembly level, can have a huge impact on the usability and perceived maintainability of a library.

I would argue that Common/Utility are not dead, but rather that is something that is difficult to do well and requires practice and disciple.

I wanted to take a moment to assure my handful of readers that I am still very much involved/interested in software development on the .NET platform.  I’m actively learning jQuery, ASP.NET MVC, and I’m looking forward to spending some serious time in Visual Studio 2010 (and related releases) when they make Beta 1 available (I’m not dealing with the VPCs).  I’m just a little more inclined to write about my hardware escapades because such things seem to get less coverage in the blogosphere.  However, if I do come across something novel or interesting in the software-only space, I’ll be sure to write about it.

A new friend of mine wants to collaborate on building a new .NET based testing framework.  I know, I know, there are plenty of testing frameworks out there.  Just to name a few: NUnit, MbUnit, xUnit.NET, nSpec, etc.  Each of these has their own strengths, weaknesses, and implicit/explicit testing methodologies associated with them.  So why would I bother saturating the market further with another testing framework?

I think I have a semi-unique idea.  I say “semi”, because the underlying design idea is applied in other technology areas, but it would be unique in its application to testing.  I think it’s has enough of a fundamental difference from all of the existing testing frameworks to justify building it.  A by-product of the design would mean that it would be mostly compatible with existing testing frameworks (and in fact I would try hard to maintain that quality, but not in all scenarios), but would also open up avenues for experimenting with new ways to represent tests.

So, the reason for this post (besides encouraging a barrage of people telling me not to put yet-another-testing-framework out there) – what do you think is missing from testing frameworks today that you would like to see in the future?

That’s all that needs to be said:

http://channel8.msdn.com/Posts/PDC-2008-is-cominghellip-and-I-canrsquot-wait/