Executive Summary: Use a formula in an NHibernate mapping to facilitate searching the entire string, “LastName, FirstName”, for a User object.

Will see how long this Executive Summary thing lasts. Getting tired of people wasting my time by posting comments saying I’m wasting their time. (I’m also working on an idea for curbing “Smells like fail” comments as well but it’ll involve some serious changes to your browser. Or, based on the average age of people that say things like that, a call to your parents to discuss how much time you spend on Facebook.)

When I’m not Google Web Toolkittin’, I have a nice side project that I use to keep my .NET skills sharp, keep one foot in the door, and whatever other reason I can think of to avoid saying the real reason, which is “pay the bills”. Because one thing start-ups ain’t got a lot of is stable (read: any) income.

In said project, I have a page with an auto-suggest feature to search for users. I.e. you enter some text, and it finds any users with the entered text in the name and displays them in a dropdown. I’d show a screenshot but in the time between when I developed it and when I wrote this, the feature was dropped.

The mechanics of the auto-suggest might be the subject of another post but I doubt it because it’s been covered to death (though not so much in ExtJS which is what we’re using). I’m going to talk about what happens in the back-end. That is, how do I get the data from the database with NHibernate.

We’re using Linq to NHibernate so my first pass was straight-forward:

public IList<User> Search(string searchText) {
    var session = NHibernateSession.Current;

    return ( from w in session.Linq<User>()
                where w.FirstName.Contains(searchText) || w.LastName.Contains(searchText)
                select w).ToList();
}

This works exactly as one would expect. If the user enters "will", it will display "William F. Buckley" and "Ted Williams" and "William 'Wild Bill' W. Williamson" in the search results. Or rather, it will show "Buckley, William F.", "Williams, Ted", and "Williamson, William 'Wild Bill' W." because that's how we're displaying our search results.

And to facilitate that display, we have a Name property on the User object:

public string Name {
   get { return LastName + ", " + FirstName; }
}

Problem is that this search doesn't cover a common scenario. What if the user types 'Williams, T'? This would be a natural thing to do. They want Ted Williams, so they start typing Williams. The search results are too big and they are showing items in the "Last, First" format so it makes sense to keep typing and try to narrow it down further.

The code above will return zero results for such a search. Really what we want is to search the Name property, like so:

public IList<User> Search(string searchText) {
    var session = NHibernateSession.Current;

    return ( from w in session.Linq<User>()
                where w.Name.Contains(searchText)
                select w).ToList();
}

Which doesn't work either because Name isn't a database field and as yet, NHibernate is not able to parse formulas in your properties and convert them into SQL or Criterion.

But NHibernate *does* allow formulas if you describe the formula to it in the mapping. We're using Fluent NHibernate (assuming it hasn't been merged into the NHibernate project yet and completely replaced mapping files, which it should be):

public class UserMapOverride : IAutoMappingOverride<User>
{
    public void Override(AutoMapping<User> mapping)
    {
        mapping.Map(x => x.Name).Formula("LastName + ', ' + FirstName");
    }
}

And update the Name property in the User object accordingly:

public virtual string Name { get; private set; }

Now, our Search function works the way I want.

Kyle the Formulaic

Bug tracking probably means something different to you than it does to the Hillbilly but if it gets you half as excited as it gets me, be sure to wander on over to http://youtrack.codebetter.com. As a sister-aunt service to http://teamcity.codebetter.com, we’re now offering a free issue tracking service to OSS projects, courtesy of the gentle folk at JetBrains.

Hadi Hariri has more details on how to sign up. Despite doing all the work, he also graciously thanks me for all my hard work and if replying to emails with “Good idea” and “Let’s do it!” and “If you think I’m supporting all these &*%$ whiners and their ‘issues’ then you’d better add ‘Hadi’s Personality’ to the project list ‘cause you got issues of your own” is all it takes to get gratitude these days, then I’m owed a whole lotta appreciation.

Happy bugging!

Kyle the Etymologist*

*Yes, yes, I know. I’m trying to be subtle here.

As I continue to work on the 'nu' story, one of the things I am thinking about a lot is how we are going to make this happen. Last week I also had the pleasure to spend some time talking about version management with Udi Dahan and Chris Patterson while they were both in Kansas City. While we discussed a variety of topics one of the things we discussed was how to manage dll dependencies. After this discussion I have come to my current 'thought.'

We should use ilmerge internal more. I have no doubt it has its issues but let me work this out. And then you can tell me what you think.

I am currently working on a new area of the Magnum project that is adding a nice abstraction on top of the file system. One of the features is handling zip files. For this I am using a third party library to handle all that nastiness. It was been a pleasure so far to work with. The problem is that in order to use this you now have to reference 3 assembilies:

• Magnum.dll
• Magnum.FileSystem.dll
• Ionic.Zip.dll (DotNetZip)

So, some of this is due to the Magnum core philosophy that we are going to take dependencies with this library. So because I want to use Ionic.Zip I have to now have a new dll Magnum.FileSystem. That's fine but adding 3 references sucks. Not only that but I now have to add a new gem dependency for magnum as well. :( As I thought about this it occurred to me: "Why does the user care about Ionic.Zip?" the user never interacts with this library and if I replaced it with the next hot thing you wouldn't even know. :) Ok, so what if I just 'ilmerge' this bad boy in. What would happen? Well I think I would have fully encapsulated my code. And if I ilmerge internal it, you could actually use your own version of 'Ionic.Zip' and we wouldn't conflict with each other! How cool is that? Once, I have ilmerged that in I can probably just either drop the Magnum.FileSystem project or I can just ilmerge it in to Magnum as well. Suh-weet.

So lets take a second and think about what this would do for us as a process. Lets look at NHibernate:

• NHibernate.dll
• Antlr3.Runtime.dll
• Iesi.Collections.dll
• log4net.dll
• YourByteCodeProvider and its dlls

NHibernate.dll of course that guy is going to stay around, he's the beef! What about Antlr3.Runtime.dll? If you are going to use Antlr3.Runtime in your own project do you want to be limited/constricted to whatever NHibernate is using? I would think not, so that puppy gets ilmerged in. Iesi.Collections? Gotta be honest, I should probably use more set based classes, but I don't; and when I do I use HashedSet<T> which I am pretty sure NH supports at this point. But because this dll isn't fully encapsulated, I am pretty sure we can't just absorb this guy in. Question? Why don't we just merge the Iesi code base into NHibernate, I have never used it outside of NH. Have you? Last we have log4net, the venerable work horse of logging. This is another dll that I see us having a hard time with, we could merge it in, but configuring it would get interesting and I really like the log4net story. So that gets us from 4 -> 3 dlls. Not to much of a win.

So lets take a look at MassTransit. A fully configured MassTransit setup (at least as of now) could put the following dlls into your mix:

MassTransit.dll

MassTransit.Infrastructure.dll

MassTransit.Transports.{YourTransportChoice}.dll

MassTransit.{YourContainerChoice}.dll

{YourContainersStuff}.dll (from 1 to possibly 4 dlls)

That a whopping 5 dlls, and if you use the saga support that is another 7-8 dlls, bringing the total to what could be 13 dlls. Schnikeys!

 

So as you can see, its not a 100% win, but I THINK the idea is going in the right direction. Framework builders, lets try to encapsulate our dependencies and ilmerge internal them. It will give our users a better experience and should make our out of the box experience that much better.

 

Please let me know what you think. Is this trash? Or is it good?

 

 

My talk from MvcConf is up on Viddler at:  http://www.viddler.com/explore/mvcconf/videos/15/.  I was disappointed with how it turned out, but other people were asking me about when it would be up, so here you go.  At a minimum, it does show some of the significant differences of the Fubu approach.  One of the criticisms I heard repeatedly was that I didn't really do a good job of comparing FubuMVC to ASP.Net MVC and showing the warts on both frameworks.  I constantly get asked for the comparisons between Fubu and MSMVC anyway, so at some point in August I'll publish a longish write up explaining my criticisms towards ASP.Net MVC, why I don't like the technical approach it takes, the opportunities I think the ASP.Net MVC misses out on because of its architecture, and a bit about how we think the Fubu approach helps to solve those problems.  Don't worry, I'll try hard to keep it grounded and avoid being unnecessarily inflammatory.

I think the weaknesses of Fubu are much more obvious (flat out missing functionality, limited community support, very little documentation, no VS integration (which doesn't concern me per se, but others do care), no real "warmup" / "storyteller createproject MyNewProject" bootstrapping yet -- but it's coming).

 

 

Executive Summary: With all of our experience in Microsoft technologies, why did we choose Google Web Toolkit over other technologies for our start-up?

Almost six months ago, I described my initial reaction to Java coming from ten years in the Microsoft world. At the time, I tastefully glossed over the reason we ended up using Java, or more specifically, Google Web Toolkit saving the discussion for a time when all I really wanted to do was make sure there were no gaps in the list of months in my Archive. Plus the original post inspired would-be blog-reviewer, Dinesh Gajjar, to comment on the lack of content, a position that leads me to believe he’d only recently started reading my blog. In any case, one of his concerns was that I didn’t explain “why I chose what” which I will assume means “why I chose GWT” (and apologies, Dinesh, if by “what”, you really meant “to waste time that could be spent writing comments on other people’s blogs”).

When first deciding on how to proceed, our default was .NET, which led to some obvious options. MVC seemed a no-brainer and since I was involved in Sharp Architecture, my first reaction before we even finished the conversation was to run the Sharp project template. “But,” says we, “we’re pragmatic programmers. Why do we automatically reach for .NET? This is *our* project!”

Thus explains why my resume says I have two days of experience with Ruby. I played with it for (almost) that long before we changed our minds again. As we discussed the nature of the application, we discovered it would rely *very* heavily on JavaScript. So we wanted something that would facilitate that.

At the time, we were also a little apprehensive about the learning curve with Ruby. Not that we wanted to shy away from it. But this wasn’t some fictitious client’s money we were playing with. It was hours. “Learning on the client’s dime” had a more ominous effect when the client’s dime was my dime.

So we ventured back to .NET being familiar territory and telling ourselves “it’ll help us get this out the door faster.” We also looked seriously at OpenRasta because it seemed to facilitate our view of having the server serve up resources rather than the default view of serving up pages. Our intent was to have a single page and dynamically modify the various pieces view JavaScript. We weren’t looking forward to managing history support for something like that but we felt it offered the best user experience, which is more important than our nagging little technical problems.

One nagging aspect to this approach was testing the JavaScript, something I had little experience with. I did some smoke tests with WatiN and was encouraged a little but it always felt a little uncomfortable, especially trying to run the tests on a CI server. And both my partner and I (admittedly, he more than I) were concerned about the costs of long-term maintainability and were pretty adamant on making the app testable and following a strong focus on quality while we built it. WatiN didn’t give us that warm fuzzy feeling and I don’t believe we looked at Selenium at the time.

Around this time, my partner discovered Google Web Toolkit which looked tailor-made for the type of application we wanted to build: A single page with various pieces updated based on user clicks. And you could write it all in Java, which was easily testable. And better yet, it had history support built in.

So we both did smoke tests and decided it was the way to go. To summarize, it gave us (in order of importance):

• an AJAX application with a good user experience
• history support (also important for user experience)
• easily tested
• strong community and many resources

In retrospect, it seems there is a fine line between “pragmatic” and “indecisive”. There’s a good chance that not all of our decisions were the right ones, just the ones we made at the time with the information available to us. As I reflect on it, maybe we dismissed Ruby too soon. Or maybe we could have built the app faster in .NET and still made it maintainable. Or maybe or maybe or maybe…

Truth be told, writing this post is about all the reflecting I’ve done on it. Because I have no regrets using GWT whatsoever. It’s lived up to its promise. Yes, we’ve run into issues but none that have been insurmountable and certainly no more than we would with .NET (can’t speak for Ruby).

More importantly, it’s because we use Java/GWT that we have the team that we do and, with all due respect to the awesome team I worked with on my first Livelink project a couple of years ago, it is by far the best team I’ve been in in my twelve years of consulting. And this from a guy who gets along with everyone (almost).

Kyle the Indefinite

By now I’ve got rid of most of the soot resulting from the reactions on a previous post. Flames were pointed at my need for a case selector. In this post I will delve a little deeper into that. I’m only presenting the core of the problem, the point where the case seems unavoidable and hoping for any more elegant solutions from you. I’m on a tightrope between an (over-)simplification of the problem, a strict NDA and you as a critical reader. Nevertheless I think the problem is worth some reflections so I am giving at a try.

The domain

The domain of our system handles the reselling of licenses. A subscription has a any number of running licenses, to which it’s not much more than a key and an expiration date. Which makes a simple model, a subscription has a list of licenses. The crooked part is (and should be) completely invisible to the subscription. It is where we buy these licenses, we have several suppliers for them. Each license supplier has a completely different way we should interact with them. For one we do the complete administration and send them an Excel sheet every three months. For another one they do all administration themselves, every detail is communicated over a web service. For yet another one there is another different scenario. The list of these suppliers will grow over time. Adding another supplier will require writing specific code, but this code should affect other parts of the system as little as possible.

Having data stored in different ways (db table, web service, spreadsheet) per entity is not that great a problem; there is a vertical split. The core of our problem is that we have the data of one entity stored in a variety of ways; we have a horizontal split.

Consequences for the implementation

Having such different ways to get to the data has the consequence that the internal behavior of the license in the domain depends on the supplier of the license. The external behavior of the license should be the same for all licenses. It is highly undesired for the subscription-customer entity to know where the licenses where bought. (That’s where the profits are made :))

To make things more complicated, implementing the behavior of some suppliers will result in dragging in all kinds of code which should be completely unknown to the domain model. All solutions you presented me, including the nice one using lambda’s, would result in just that. For instance: when it comes to the web service based supplier we need things like credentials which are stored in the db. To get those you need the repository. You don’t want the domain model to depend on the repository; that’s even technical impossible. As a repository depends on a domain model that would result in a cyclic dependency.

A factory as man in the middle

These are the main parts (assemblies) of the solution together with the parts they depend on

• Domain model
• Repositories (domain model)
• Communication with supplier1 (domain model, repositories)
• Communication with supplier2 (domain model, repositories)
• UI (domain model, repositories)

As stated before the main problem is how to get the supplier specific data of a subscription into the UI (and other parts) without knowing anything about specific suppliers. Our solution is a subscription factory. Only this factory has knowledge of the specific suppliers. It has references to all underlying layers, that is the domain model, the repositories and all supplier services.

When creating a new subscription object it queries all suppliers for licenses

public static Subscription Subscription(int customerId)

{

    var repository = new SubscriptionRepository();

    var subscription = repository.Subscription(customerId);

    subscription.Licenses = new List<Licence>();

    subscription.Licenses.AddRange(LicenceProvider1.GetLicences(customerId));

    subscription.Licenses.AddRange(LicenceProvider2.GetLicences(customerId, "UserName", "Password"));

    return subscription;

}

The repository provides the plain db data for a subscription. The LicenceProviderX classes handle all supplier specific things. One class will just dive into our own repositories, the other one dives into the web to talk to the suppliers web service. Adding a new supplier leads to adding another line here.

This factory has to provide post production services as well. To do something with a license, like renewing it, requires talking to the license’s supplier. It’s up to the factory to do the magic of finding out who the supplier was. We use a database Id which is mirrored in an enum in code. (This is the dreaded enum this quest started with)

internal enum SupplierIds

{

    Supplier1,

    OtherSupplier

}

A helper method FindSupplier takes a license and returns the enum member. Using this the factory has a member to renew the licenses in a subscription

public static void OneMonthMore(Subscription subscription)

{

    foreach (var license in subscription.Licenses)

    {

        SupplierIds supplierId = FindSupplier(license);

        switch (supplierId)

        {

            case SupplierIds.Supplier1:

                LicenceProvider1.RenewLicence(1);

                break;

            case SupplierIds.OtherSupplier:

                LicenceProvider2.RenewLicence(1, "UserName", "Password");

                break;

        }

    }

}

And there is the switch. And IMHO it is a justified case.

Winding down

I don’t think I have presented you anything exiting at all. Which is IMHO good, because we do have a complicated problem. This solution works well in two ways. It is pretty easy to understand how it works and it is pretty easy to maintain. Adding another supplier boils down to, having written all specific code for that supplier, to adding another case. I hope I have made my point that there is a case for that. No doubt there are more elegant solutions. Please strike your matches. And enlighten me.

I know there is a large subset that reads this blog and/or follows me on twitter and/or is on the ddd list but for those who are not in those sets.

In hope of bringing the DDD list back to a focus of DDD I created a second list for Event Sourcing/CQRS/etc type discussions as I am sure many of the people on the DDD list feel spammed with the ideas. The list already has some great discussions on it and I think will become a great resource for those looking to learn the ideas.

 

Update link http://groups.google.com/group/dddcqrs/

Cross posted with http://devlicio.us/blogs/tuna_toksoz/archive/2010/07/27/codebetter-devlicio-us-msdn-ultimate-giveaways.aspx

UPDATE: Our friends from LosTechies also wanted to participate, and they donated a number of licenses (6 and counting). Thank you guys

In an internal discussion we had, an interesting idea popped up. MVP bloggers we had at CB/DL were generous enough to donate some of their MSDN subscriptions they were given as part of MVP program. Currently we have 7-10 licenses available, and this number may increase if we get outside donations. The subscriptions are for one year.

We decided to give them away to successful/promising OSS projects that are in need of licenses. The rules are simple.

1. The project has to be opensource
2. The project has to be in need of MSDN license. We’ll trust your word in this.
3. The selection will be based on our discretion, we’ll do our best on being fair.
4. We may change the number of licenses available during the selection progress.

You can send me an email (tehlike (hat) gmail (hot) com) with title starting with [CD/MSDN], or DM me on twitter (@tehlike) if you want to participate. You have to include

1. Public URL for the project page
2. Your name and your position in the project

Good luck!

Automated testing became mainstream something like 5 years ago. Nowadays, in 2010, automated testing is somehow accepted by most serious developers.

Design by Contract exists for 2 decades, first supported by the Bertrand Meyer’s Eiffel language. Thanks to the recent Code Contract .NET v4 library, there is nowadays, some buzz about Designing by Contract in the .NET community.

My point is that one developer shouldn’t abide by one of these practices, without adhering to the other. Especially, if you already practice automated testing, you ethically cannot ignore Code Contracts. I have the chance to be relentlessly serious in practicing Code Contracts AND Automated Testing for 5 years now. My conclusion is that, in appearance different, Code Contracts and Automated Testing represent pretty much the same thing.

Code Contracts and Automated Testing share both the same primary goals:

• Check often for code behavior correctness
• Trigger obvious failure in case of broken correctness found
• Document code behavior

Assertions put inside the code through Code Contract are really the same thing than assertions put inside test code. This advocate for a central point: Code Contracts assertions should raise obvious failure when violated during the execution of some automated tests.

Often I hear or read that just few tests covering a large portion of the code is not a valuable thing, since few tests contain few assertions and thus, there is a high chance for a bug to remain undetected. In other words, some pretend that high test coverage ratio of the code is not so much valuable. But if the large portion of the code contains a well-written set of code contracts assertions, the situation is completely different. During the few tests execution, tons of assertions (mainly Code Contracts assertions) have been checked. In this condition, chances that a bug remains undetected are pretty low. Chances that a bug remains undetected are pretty close to 0 when the code is both 100% covered by tests and contains an optimal set of contract assertions.

More concisely Contracts are not a replacement for Tests and vice-versa: both should be practiced seriously.:

• Contracts need Automated Tests to be exercised often in a repeatable way.
• Automated Tests need Contracts as a much finer way to check code behavior correctness, inside the code itself.

Finally, some might discuss that unit tests are class oriented, that integration tests are modules oriented that Design by Contract is class collaboration oriented, bla bla bla. While I agree that there should be a clear frontier between the set of quick unit tests (ran in seconds), and the set of slow integration tests (ran in minutes) I am not so strict about the scope of tests and contracts. My mission as a developer is to write bug-less code in a competitive time. Relentlessly applying both automated tests and Design by Contract is so far, my best weapons to achieve this task.

I was just reading Patrick Smachia's great post on High Test Coverage and I have to say I agree nearly 100%.

 

I have a presentation up from a few years ago that covers some of the relations between TDD and DbC http://www.infoq.com/presentations/TDD-in-a-DbC-World-Greg-Young that might be worth watching for some people checking out these ideas.

 

As some of you may know though I did not announce it on my blog I ran an online course yesterday for the first time.

 

The class was full day and about the evolution involved with CQRS and Event Sourcing. It was an interesting experience as it was my first time utilizing the medium. Here are some thoughts from my perspective on how it went.

 

The good. 

 

• Registration was good. EventBrite was relatively painless to work with. Registration filled up very quickly.
• I liked the donation model for people. Some people came in for free others were very generous. I like that it gives opportunities to people who may otherwise not be able to receive the content
• No crashes thankfully with livemeeting.
• Good questions from group.
• Lovely setting to work from (outside by Darrel Miller's pool in the sun :))

 

The not-so-good

 

• Medium is far less interactive than I prefer to be.
• It is quite weird to sit and talk to a computer for 8 hours.
• I feel I need to change some content + build a few additional slides, I am too accustomed to just grabbing a whiteboard
• Need to break out more distinct "chapters" for the online version

 

 

Overall I kind of question the benefit of doing things in the online format. Overall I think I will do it one or two more times but I feel that once I get the format nailed down I would probably be better off to just record the 8 hour session and put it up for download etc. The main reason for this is that the medium is much more so uni-directional and lacks in large amounts of interaction. Having questions is a good thing but its not nearly as interactive as say a classroom setting where I can just whip out a pen and start drawing on the whiteboard to answer the question. Going with the recording a think a venue where people could ask questions would generally suffice for most of the interactions that happen live.

 

 

Frequently when reviewing code I see one of my pet hates appear and that's a direct dependency on the ConfigurationManager.  The ConfigurationManager provides a way to access values in the Web\App.config. Yet, like any dependency, they generally bite you at some point – generally when you attempt to write the test.

Let’s imagine that our web.config has a value like below:

EnableNewsletterSignup = “false”

This value defines if we should hit the live web service. During development\systest we don’t want this to happen, however we do in UAT and Live. As a result, our code will generally look like this:

public bool Signup(string email)
{
    if (!Boolean.Parse(ConfigurationManager.AppSettings["EnableNewsletterSignup"]))
        return false;

    return true; // technically this would go off to an external web service
}

Simple, yet with multiple problems

Firstly, we have a magic string value which relates to the key in the config. If we wanted to change this value we would have to perform an error-prone Search\Replace. Secondly, we have to manually parse the string value to a boolean – again, this is error prone as we’ll need to protect against bad data. This additional logic hides the true intent of what the method is meant to be doing which increases complexity. To make matters worse, we have a major problem when it comes to testability.

The configuration manager will automatically detect the config file based on the executing assembly, this means that your test assembly’s App.config needs to match your implementation’s (web.)config with all the values pre-configured for testing purposes. Having pre-configured values offers you very limited flexibility and in the example above we would be unable to test both paths (without our tests changing the value directly)? If we had multiple possible paths, this would cause us a very real problem.

This week I came across the issue were I required an AppSetting value. Not wanting to face the issues above I looked for help.

Thankfully, help’s available

The Castle Dictionary Adapter removes these problem for us. Given an interface and a dictionary of values, the adapter will create an object with all the properties populated for us. Our interface will match the settings in our config file.

public interface IApplicationConfiguration
{
    bool EnableNewsletterSignup { get; set; }
}

The same implementation mentioned before becomes this, with a dependency on the above interface instead of the concrete ConfigurationManager. Notice our ‘if’ statement now uses a strongly typed property without all the noise associated.

class NewsletterSignupService
{
    private readonly IApplicationConfiguration _configuration;

    public NewsletterSignupService(IApplicationConfiguration configuration)
    {
        _configuration = configuration;
    }

    public bool Signup(string email)
    {
        if (!_configuration.EnableNewsletterSignup)
            return false;

        return true; // technically this would go off to an external web service
    }
}

Testing!

The real advantage arrives when you look at the problem from the testing point of view. Because it’s an interface, we can use Rhino.Mocks to produce a stub, allowing us to test using any possible value.

var stubConfig = MockRepository.GenerateStub<IApplicationConfiguration>();
stubConfig.EnableNewsletterSignup = true;

We also no-longer need to maintain the App.Config as everything is driven by stub config objects, making life easier all round.

The next level comes when you use it with an IoC framework such as Castle Windsor. When an object defines a dependency on IApplicationConfiguration, they will be provided with an object created via the DictionaryAdapterFactory with the values coming from our actual AppSettings.

WindsorContainer container = new WindsorContainer();
container.AddFacility<Castle.Facilities.FactorySupport.FactorySupportFacility>();

container.Register(
    Component.For<IApplicationConfiguration>().UsingFactoryMethod(
        () => new DictionaryAdapterFactory()
             .GetAdapter<IApplicationConfiguration>(ConfigurationManager.AppSettings)));

As a result of implementing the adapter together with it’s use in Windsor we have more control, less complexity and a more maintainable solution going forward.

But it’s not only for AppSettings, the Castle Dictionary Adapter works on a number of different directories and collections meaning you no longer need to index into them using strings. If you want to know more, then CastleCasts has a great screencast on this at http://castlecasts.com/Episodes/3/Show/dictionary-adapter

In order to implement this in your own codebase, Castle Dictionary Adapter is currently a separate single assembly with no external dependencies that you can download from http://www.castleproject.org/castle/download.html

Going forward, it will be part of Castle Windsor 2.5 with some interesting improvement as discussed at http://devlicio.us/blogs/krzysztof_kozmic/archive/2010/07/05/castle-windsor-2-5-the-final-countdown-beta-1-released-and-core-dynamicproxy-dicitionary-adapter.aspx

 

The code for the above example is available at http://gist.github.com/486603

 

We’ve covered a bit recently with conditional and looping operators on the Reactive Extensions for JavaScript, but I want to step back just a minute and cover exception handling.  This post will cover how we can compensate for errors as they happen in several ways and will largely follow Bart de Smet’s post on the same topic, but instead of covering the Interactive Extensions, we’ll stick primarily in JavaScript.

Before we get started, let’s get caught up to where we are today:

• Introduction
• Creating Observables
• Creating Observers
• jQuery Integration
• Composing Callbacks
• From Blocking to Async
• Wikipedia Lookup
• Composing Deeper
• Bing Maps and Twitter Mashup
• Drag and Drop
• jQuery Live Event integration
• jQuery AJAX integration
• A Separation of Concerns
• Aggregates – Part 1 and Part 2
• Join Operators
• Going “Parallel” with ForkJoin
• Refactoring a Game
• Async Method Chaining
• Custom Schedulers
• Countdown Timers
• Wrapping the Dojo Toolkit
• MooTools Integration
• Conditional Operators
• Looping Operators

 

Error Handling

When writing safe programs, we have to be mindful of exception handling.  Typically for imperative code we have try/catch/finally blocks which allow us to try a certain behavior, compensate for exceptions and do any cleanup that is necessary.

try {
    // do something
}
catch(exception) {
    // handle error
}
finally {
    // clean up
}

When it comes to asynchronous programming, the job becomes a bit harder.  How do we reliably do exception handling that doesn’t litter our codebase during each and every callback?

doAsyncAction1(data, function(result1) {
    // Handle exception here?
    
    doAsyncAction2(result1, function(result2) {
        // What about here?
        
        // What about more callbacks?
    });
});

Alternatively, some might have separate callback handlers for exceptions which further muddies the waters:

doAsyncAction1(data, 
    function(result1) {
    
        doAsyncAction2(result1, 
            function(result2) {
    
            },
            function(error2) {
                // handle this error
            });
    },
    function(error1) {
        // Handle it way down here
    });

With the Reactive Extensions for JavaScript, we have some mechanisms at our disposal for error handling and compensation.  Say for example, we have a safeDivide method which instead of producing infinity as the result of a divide by zero, instead we throw an exception.

function safeDivide(dividend, divisor) {
    var result = dividend / divisor;

    if (!isFinite(result)) {
        throw "Cannot divide by zero";
    }

    return result;
}

How can we use the Reactive Extensions to compensate for any such exceptions that happen?  Using our knowledge from previous posts, we’ll not only handle the OnNext part of our Observer, but also the OnError as well.  Let’s walk through a simple example of using our safeDivide.

var array1 = [3, 2, 1, 0];

Rx.Observable.FromArray(array1)
    .Select(
        function (next) {
            return safeDivide(100, next);
        })
    .Subscribe(
        // OnNext
        function (next) {
            $("<p/>").html(next).appendTo("#results");
        },
        
        // OnError
        function (err) {
            $("<p/>").html("Error: " + err).appendTo("#results");
        });

From this, we’ll get the following results in our web page:

33.333333333333336
50
100
Error: Cannot divide by zero

When the Select method above hits the condition where the exception is thrown, our observable sequence calls OnError handler on our observer and then immediately quits.  In this post, we’ll go over some of the compensation techniques outside our this standard OnError handler we have above.

Before we do so, let’s cover one more operator that will help us later on in the post, which is the ability to have the observable sequence throw an exception via the Throw function.  The Throw operator creates an observable sequence, when subscribed to, will call OnError with the given exception.

// exception : The exception to throw
// returns : Observable

Rx.Observable.Throw = function(
    exception);

We can see this in action by simply passing in a message such as the following:

Rx.Observable.Throw("oh noes!").Subscribe(
    function() { },
    function(msg) { alert(msg); }); // Shows oh noes!

Having seen that, let’s move onto our first compensation…

Catching the Exception and Moving On

The first operator we’ll cover is the Catch operator.  This operator allows us to continue an observable sequence that is terminated by an exception with the next observable sequence.  We have two overloads of the Catch as defined below with one being an instance method on the observable sequence and the other is a static method which takes an array of observable sequences and an optional scheduler.

// obs : varargs array of observable sequences
// returns : Observable

Rx.Observable.prototype.Catch = function(
    obs1, obs2, obs3, ...);

// items : Observable[]
// scheduler : an optional scheduler
// returns : Observable

Rx.Observable.Catch = function(
    items,
    scheduler);

The first version is much like an imperative version of a try/catch block which allows us to compensate and compose our workflows.  Now, let’s say you had an observable sequence that can cause the OnError to be fired like the following code will:

var couldThrow = Rx.Observable.FromArray([1, 2])
 	.Concat(Rx.Observable.Throw("oh noes!"))

What we can do to compensate is use the Catch function to continue on with the next sequence so that we end up with the numbers 1-5 printed on the screen where the last three values were from the compensation sequence.

couldThrow.Catch(Rx.Observable.FromArray([3, 4, 5]))
    .Subscribe(
        function (next) {
            $("<p/>").html(next).appendTo("#results");
        });

Just as well, we could just chain together sequences with compensations.  Below, I have an example of chaining together some values, exceptions and compensation values which will yield me once again the sequence of 1 through 5.

 var couldThrow = Rx.Observable.FromArray([1, 2])
    .Concat(Rx.Observable.Throw("oh noes!"))
    .Catch(Rx.Observable.FromArray([3, 4]))
    .Concat(Rx.Observable.Throw("not again!"))
    .Catch(Rx.Observable.Return(5));

couldThrow.Subscribe(
    function (next) {
        $("<p/>").html(next).appendTo("#results");
    });

The second version of the Catch operator allows us to have an array of observable sequences which allows us to compensate for sequences until no more errors occur.  Let’s take a look at an example of using this below.  What will be printed on the screen?

var exn = Rx.Observable.Throw("yup yup!");
var couldThrow = Rx.Observable.Catch([
    Rx.Observable.FromArray([1,2]).Concat(exn),
    Rx.Observable.FromArray([3,4]).Concat(exn),
    Rx.Observable.Return(5),
    Rx.Observable.Return(6)]);

couldThrow.Subscribe(
    function (next) {
        $("<p/>").html(next).appendTo("#results");
    });

If you guessed once again, the numbers 1 through 5, you would be correct.  Why?  The answer is simply that once 5 was yielded to us, there was no compensation needed, so 6 was not yielded.  Had the sequence which yielded 5 also thrown an exception, then I would have yielded 6.

And Finally…

Now that we’ve covered the Catch part of the equation, how about cleaning up resources at the end of our workflow?  How can the Reactive Extensions help us here?  Through the use of the Finally operator, we’re able to do just that.  The signature that follows shows that this takes a function with no parameters and has no return value. 

// finallyAction : () -> ()
// returns : Observable

Rx.Observable.prototype.Finally = function(
    finallyAction);

Let’s look at a regular workflow where we start with an array of 1 and 2.  Then we’ll add a Finally function to indicate that we are complete.  This will print out 1, 2 and then Finished!

Rx.Observable.FromArray([1, 2])
    .Finally(
        function() {
            $("<p/>").html("Finished!").appendTo("#results");
        })
     .Subscribe(
        function (next) {
            $("<p/>").html(next).appendTo("#results");
        });

How about we mix this up a little bit and show a bit more advanced scenario?  Let’s walk through the code in pseudocode before we begin.  The idea is that we yield the first two numbers and then have an exception thrown.  We then will print out “Finished”, followed by the outer catch yielding the next three values. 

try {
    try {
        yield 1;
        yield 2;
        throw "y'arr!";
    } 
    finally {
        print "Finished!";
    }
}
catch(exception) {
    yield 3;
    yield 4;
    yield 5;
}

The overall result should yield us: 1, 2, Finished, 3, 4, 5.  Let’s look at how that might be done using the Reactive Extensions for JavaScript.

Rx.Observable.FromArray([1, 2])
    .Concat(Rx.Observable.Throw("y'arr!"))
    .Finally(
        function() {
            $("<p/>").html("Finished!").appendTo("#results");
        })
    .Catch(Rx.Observable.FromArray([3,4,5]))
    .Subscribe(
        function (next) {
            $("<p/>").html(next).appendTo("#results");
        });

There’s more to cover here including more cleanup routines and compensation that we’ll get to in the next post including Using, OnErrorResumeNext and Retry.

Conclusion

Dealing with asynchronous programming has been in the forefront of many minds in the JavaScript community.  At JSConf, there were several examples of frameworks trying to get around the idea of callbacks and instead lean more towards composition.  By utilizing the Reactive Extensions for JavaScript, we’re able to compose together asynchronous and event-based operations together and transform the results in interesting ways.

When we start creating more advanced workflows through the Reactive Extensions, we also need ways of handling errors as well.  We have the ability do handle errors and compensate as they happen through a rich set of operators including Catch, Finally, Using, OnErrorResumeNext, Retry and more.

So with that, download it, and give the team feedback!

A little while ago I decided to move my blog to openmymind.net. I owe a lot to Brendan and CodeBetter, but I have an itch to talk about a broader set of topics than what I feel is appropriate here. I'm also becoming increasingly disenchanted towards MS and .NET and I know the constant nagging is seen as noise by a lot of people. If you're interested, I hope you'll follow me there.

Also, in less than 8 days, I'm packing a couple suitcases and moving from scarcely populated Canada to densely populated Hong Kong. I'll be joining a talented team of Java and .NET developers in the financial industry. The offer was appealing in a number of ways, but their intense focus on TDD, their ALT.NET mentality and their desire to bring in Rails was really appealing.

See you on the virtual and geographical flip-side.

Just stumbled on this twit by Jim Holmes

NDepend is wonderful. Except when it shows you the truth. Maybe it should have a "JustLieToMe" setting.

 

In addition to Just Lie To Me, we are mulling over new other features including:

• Dont Tell My DAL Code Depends On UI Code I Am Asking Pay Rise
• Pretend A Lot Of Code Has Been Developed Recently Since I Spent My Time Looking For Another Job These Last Days
• Please Tell Me Where This %*!){$"# Bug Comes From I Dont Want To Spend My Night On It

but so far NDepend only has the feature

• Help Me Convince My Manager That The Code Is So Ugly That We Should Take The Time To Refactor It And Write Tests

 

 

So, wow! A lot of thoughts and comments about nu yesterday, and is it the right tool for .net. That it doesn't solve the rat's nest of assemblies that OSS projects use, etc. So I just wanted to take a second to respond to these basic questions.

Q: Is it the right tool for .net?

A: Does it work? Does it do what you need? If so then yes it is. If not then that's cool too. But the gems infrastructure is SOOOOO nice. I have been working on this problem on and off for almost 3 years now. Every time I start and get a little bit further but ultimately it comes down to where are we going to host these things. And I get demotivated and let it sit on the shelf. Last week I started to program in Ruby just to spread my wings a little bit. Its a PITA (because its new) but there are things that I like. Namely gems. So curious, I wrote my first gem and pushed it to rubygems.org. It took 5 minutes. Seriously. At this point, I went back on all of my 'we don't need no stinking gems' and started to head down code 'nu' in ruby. I spent more time looking up the Gems api than I did actually coding it. So is it the right tool? it is for me. It was just too easy.

Q: It doesn't solve the utter mess that .Net OSS projects are about dependency tracking.

A: No kidding. That challenge is not going to be solved by a better tool. Its a human problem. We as developers (myself included) need to get better about sticking to released builds. If the ruby guys can do it, then I am pretty sure we can too. With gems it is so simple to push a new release and to spec a version that I hope the decreased friction alone will help people out. The rails guys have a 3-4 line ruby script that pushes their new releases. It could be a part of your build process.

gem push yourproject-1.0.0.gem

That all it takes.

So lobby your OSS projects, help out and submit the patch, if we can get the projects released builds up and running we can start to make this happen. FYI, rubygems is even working on the concept of early releases so you can say things like

gem install rails --pre

How fricking cool is that!

Ok, I feel better now.

-d

Its been a long time coming, but I finally sat down this week and wrote the tool that I hope will become the 'gems' of .net. Its a humble tool right now and doesn't do much other than leverage the existing support of the gems framework in ruby and copy files around. But its my hope that from this start great things can happen.

It requires Ruby to be installed on your machine, there is a very simple install here for windows that will make things very easy. Once that is installed you can simply type a few commands in your preferred command shell and be up and running.

gem update --system #to make sure you are on the latest and greatest

gem install nu #this is the app that I am writing

gem install log4net

Now you can go to your project directory and type

nu install log4net

and it will copy the log4net dlls into './lib/log4net-1.2.10.0' - if the 'lib' folder doesn't float your boat you can say

nu lib YourDirectory

and it will set its configuration file to store that value (which is stored at '.nu/config.yaml'). Its a humble tool that I offer to you, anyone can put a gem up on rubygems.org so why don't you take the 5 minutes to create your first gem, put it up for everyone to grab and bask in the polyglot glory of gems and nu - best buds since last week ;)

If you have any questions I have started a group on google so feel free to drop on by and let me know what's going on or you can check the tweets at #nuproj.

Have a great weekend everyone.

Also, my buddy Rob has some good posts about gems and .net when thinking about 'nu' that you should go and read as well if this is interesting. :)

http://devlicio.us/blogs/rob_reynolds/archive/tags/Gems/default.aspx

-d

In the discussion following my last post Full Coverage by Tests Driven Development , thanks to relevant questions I had the chance to dig dipper into my thoughts. Let me elaborate a bit.

So basically, if one wishes to cover 100% of a portion of code with test, one typically will spend 20% of the effort to cover 80% of the code and the next 80% of the effort to cover the 20% of the code remained uncovered. This is an occurrence of the well known 80/20 law. The conclusion of this law is usually, spend 20% of your effort to get 80% of the result and forget the 20% remaining result which is hard to get.

Here comes the interesting finding: if it is hard to write test to cover a portion of code, it means that the semantic of this portion of code is complex and/or is not well coded. Such code represents edge-cases often neglected by developers, like error treatment or very rare and unlikely cases. All of these advocate that the 20% of code that is hard to cover by tests, is also pretty error-prone. And indeed, in my experience, I often stumble on unexpected issues while struggling to cover the few remaining percents of a portion of code.

So now we have another side of the 80/20 law. 80% of the effort is spent writing tests to cover the 20% of the code remained uncovered, but 80% of the issues and bugs are found during this effort. This is another reason why I found it worth to cover 100% of a portion of code. I exposed some others reasons in the post High Test Coverage Ratio is a good thing, Anyway!, including:

• Using code contract coupled with high coverage ratio leads to checked correctness.
• A bug discovered in tested code is easier to fix.
• High test coverage guides mechanically the developer to potential flaws in the code.
• Code fully covered by test is less subject to code erosion.

 

One of the biggest desires of the community around the Reactive Extensions for JavaScript (and .NET as well) has been a guide on how to get started (well that and complete documentation).  With that, the Reactive Extensions team and I have created hands on labs for both JavaScript and .NET to get you started incrementally with the Reactive Extensions.  Both labs largely follow each other in terms of format and what areas are covered.  For the JavaScript lab we’ve created, a little bit of jQuery knowledge around selectors and AJAX support are desired.

The JavaScript lab has the following sections:

• Exercise 1: Getting Started
• Exercise 2: Creating Observable Sequences
• Exercise 3: Importing DOM Events into Rx
• Exercise 4: A First Look at the Standard Query Operators
• Exercise 5: More Operators to Tame the User Input
• Exercise 6: Bridging the Callback Method Pattern in Rx
• Exercise 7: SelectMany – the Zen of Composition
• Exercise 8: Testability

Hope you find these useful and give us feedback on what we did right and wrong and what you’d like to see from us in the future!

The other day I was talking with Kyle Baley on twitter and I gave an example of how it is possible to store "highly critical" data only in memory. I mentioned to him a similar problem, here it is.

 

The basics of the problem are that:

we need to support 10000 concurrent queries, we can reject any past that immediately

we are given a latent but extremely high bandwith that guarantees packet ordering

we are only allowed to store 10 of the 100000 objects of the dataset in memory per instance

 

Feel free to email me with your potential solutions to this problem (or put them in comments). 

 

Some questions:

 

What did I not specify that we need for the solution to work? Is there anything that would make it easier?

What is the latency of a query in your solution?

How do we handle fail-over situations?

What is the total general purpose memory needed on our machine?

How would we scale to supporting 10,000,000 concurrent queries?

What happens if we need to support 1,000,000 objects?

What happens when we can change data not just query it?

Can we implement a unique constraint on say the id of our data? If so how?

Have fun guys :)