Devlicio.us

Asynchronous Execution, Animation and more in MVVM with Caliburn

Rob Eisenberg — Fri, 10 Jul 2009 04:21:24 GMT

On the Silverlight Insiders mailing list there’s been a discussion about the difficulties of handling animations when trying to use an MVVM architecture. I’m not going to go into the details here, as I am going to cover this more fully in a future blog post, but still, I could not resist showing off the elegant way that Caliburn solves this problem. Here is some XAML:

<TextBox x:Name="username" />
<PasswordBox x:Name="password" />

<Button Content="Login"
        pf:Message.Attach="Login(username.Text, password)" />

And here is the code from the ViewModel that Caliburn execute when the user clicks the button:

public IEnumerable<IResult> Login(string username, string password)
{
    _credential.Username = username;
    _credential.Password = password;

    var result = new Result();
    var request = new GetUserSettings(username);

    yield return new ProcessQuery(request, result, "Logging In...");

    if (result.HasErrors)
    {
        yield return new ShowMessageBox("The username or password provided is incorrect.", "Access Denied");
        yield break;
    }

    var response = result.GetResponse(request);

    if(response.Permissions == null || response.Permissions.Count < 1)
    {
        yield return new ShowMessageBox("You do not have permission to access the dashboard.", "Access Denied");
        yield break;
    }

    _context.Permissions = response.Permissions;

    yield return new OpenWith<IShell, IDashboard>();
}

Please note that the 1st, 2nd and 3rd yield statements above are all *asynchronous*, but the code within this action is executed in sequential order. The 1st yield also triggers an animation...I can also do things like this:

yield return new BeginAnimation("MyCoolAnimation");
yield return new BeginAnimation("This animation is next");
yield return new BeginAnimation("This animation plays last");

This gives the View Model a declarative way to handle animations without a need to reference the view. Also, it should be noted that the above action relies on several UI services, but I can unit test this action without needing to mock anything. The declarative nature of the action allows me to iterate over the results and simply use normal Asserts on the values. Async programming becomes synchronous and playing Animations is peachy ;)

More on this later, but I just had to show some code because I’m not sure many people know you can do this with Caliburn. On my current Silverlight project, we are making extensive use of this. It makes calling web services a breeze.

Querying on Child Count With NHibernate

Tuna Toksoz — Thu, 09 Jul 2009 23:23:00 GMT

This is a recent question raised in NHibernate Users Group. The user wanted to realize the following query with Criteria api.

var result = db.Person.Where(x => x.Pets.Count > 0 && x.Alive)
                      .OrderBy(x => x.Name);

This is not a simple query, but it has a solution

  
DetachedCriteria crit = DetachedCriteria.For(typeof (Person), "p2")
    .CreateCriteria("p2.Pets","Pets")
    .Add(Restrictions.EqProperty("p.Id", "p2.Id"))
    .SetProjection(Projections.Count("Pets.Id"));

ICriteria c = s.CreateCriteria(typeof (Person), "p")
    .Add(Restrictions.Gt(Projections.SubQuery(crit), 0))
    .Add(Restrictions.Eq("p.Alive",true))
    .AddOrder(Order.Asc("p.Name"));

What we had to do is to create a DetachedCriteria and on that execute CreateCriteria so that we can do querying on our collection.

I hope this helps.

Is that a Property or a Method?

Derik Whittaker — Thu, 09 Jul 2009 14:28:00 GMT

This is just a quick little rant on my part. In my opinion a property should be used for simply getting/setting of a value. You should NOT have any logic inside your getter/setter (ok, I will add a 'caviot' to this rule and say that I am ok with doing string formatting on the getter). If you need to have logic in either your setting or your getter I think it is about time to use a method, not a propery.

WHY?
Because, once you start adding behavior to the property you are masking this behavior and a method will better convey your intent.

Again, this is just my thoughts/opinion, but I like to convey intent of methods/logic and wrapping logic inside a property does not convey intent.

Till next time,

MVVM – Philosophy and Case Studies - Introduction

Rob Eisenberg — Wed, 08 Jul 2009 02:49:00 GMT

There’s been a lot of talk lately about MVVM (Model-View-ViewModel) in the WPF and Silverlight space. Recently, Ward Bell had an interesting post on the subject where he digs into some of the patterns he is using to support his MVVM triads. The WPF/Silverlight community is constantly droning MVVM, but almost no one goes beyond stating their use of the pattern or giving an overly general description of it. That’s why I enjoyed Ward’s post. He’s trying to get into the nitty-gritty of his UI architecture rather than just chanting “I'm using MVVM" and leaving it at that.

I’m pleased that the WPF/SL community is taking UI architecture seriously, but I think we have a long way to go. We need to dig deeper into the “how” of the MVVM and realize that a solid implementation is more that just creating a model and binding it to a view, with a dash of the Command pattern thrown in for good measure. In fact, saying you are using MVVM for WPF/Silverlight is sort of like saying you are using MVC for web development. It more or less states the general design approach you are taking to the UI architecture, but doesn’t say much about how the pattern is implemented or how individual features are represented within the context of that design. If you’ve been following the blogs on ASP.NET MVC, you’ve probably discovered that there is a lot more to it than just having Models, Views and Controllers. It is easy to use the MVC pattern very poorly and the same goes for MVVM.

Speaking of context…

When I first read the GoF book, I was baffled by its insistence that patterns were not tied to implementation. Sure, I understood that the Iterator pattern would be implemented differently in C++ than in C#, but I didn’t understand that other context-specific factors had a massive affect on the details of its implementation. This “phenomena” manifests itself in greater degrees with respect to how high-level the pattern is. A high-level pattern like MVC is a fine example of this. Consider how the implementations would differ between a WinForms and an ASP.NET implementation of this pattern. They would not resemble each other much at all. The WinForms version would likely look a lot like an Observer or Mediator while the ASP.NET version would be very similar to a Strategy. In fact the WinForms version would look so different, you might not even call it MVC anymore, though you started out with an MVC mindset. You could force the WinForms and ASP.NET implementations to look alike, but you would be creating a leaky abstraction by forcing an artificial context for your design to live in.

In the next couple of posts I am hoping to examine MVVM within the context of WPF/SL. What does the base form of it look like? What do more complex forms look like? Why is this pattern a good fit for WPF/SL? How does this pattern relate to MVP and MVC?

MVVM – A Simplistic View

If we take MVVM as a high level pattern, like MVC, then it becomes our general approach to architecting user interfaces. It means that we will have components in three of the following broad roles:

Models – These are the business-oriented components that are intended to be displayed or manipulated by the application. They might be traditional business objects rehydrated from the DB, messages from a web service or anything else that has business meaning independent of presentation.

Views – WPF/Silverlight is a view framework and is thus intended to provided these components. Their role is to display something on the screen. Nothing more, nothing less.

View Models – This is a special type of model, intended to be an abstraction of the UI. You can think of it as a logical representation of the UI. It is “connected” to the view at runtime through databinding.

My guess is that you probably feel pretty comfortable with the idea of a Model or a View. You can picture them in your mind. But when it comes to View Models, things get foggy. It means that we need to have a lot more discussion around what our View Models look like. But, we cannot just discuss them abstractly. We must look at specific scenarios and see how ordinary design patterns interplay to create a meaningful model of the UI. In a few words, here’s my general philosophy and what I hope will become clear as we proceed:

The same OOD techniques you use to build your backend systems are used to construct your View Models.

To that end, I am hoping to put together several posts on the subject. I am planning to contact several of my previous clients with the intention of gaining permission to discuss small portions of their applications; or to discuss them at a very high level. I want to show specific problems and demonstrate how we used common design patterns to build a rich View Model. It is my hope that this will begin a richer discussion on the topic within our community.

How to copy an entire folder tree with Nant

Derik Whittaker — Tue, 07 Jul 2009 15:43:54 GMT

Ok, so this sounds like it should be drop dead simple and it is, however it is not (at least to me) 100% intuitive how you could accomplish this.

Here is what I wanted to do. I wanted to be able to copy ALL of my compiled dlls from my build to a ‘staging’ location and I wanted to do this in a simple manor. The first thing I did of course was to jump out to the nant project page to refresh my memory on the <copy> feature. Sadly after reading the doc, i did not find anything that stuck out and said ‘hey, if you need to copy an entire folder structure do this’.

However, with a bit of googling I was able to figure out a simple way to do it.

  <target name="copy.nightlyBuild.to.staging.location">
    <property name="dir.nightlyBuild.destination" value="C:\NightlyBuilds_Output\Build" />
    <mkdir dir="${dir.nightlyBuild.destination}" if="${not(directory::exists(dir.nightlyBuild.destination))}" />

    <copy todir="${dir.nightlyBuild.destination}" includeemptydirs="true" overwrite="true" verbose="true">
      <fileset basedir=".\SOME_FOLDER_TO_COPY_FROM">
        <include name="**/*.*" />
      </fileset>
    </copy>
    
  </target>

What makes this process work is the **\*.* in the include section. the **\ tells nant to do a recursive copy.

Hope this helps

Till next time,

Upcoming Local UG Meetings

sergiopereira — Mon, 06 Jul 2009 17:07:00 GMT

Here are two user group events that are happening soon and that I'm directly involved.

July 8^th, Chicago ALT.NET

0-60 With Fluent NHibernate
See the full description of the session over at the Chicago ALT.NET home page. We will have Hudson Akridge tell us all about Fluent NHibernate, a project that has been instrumental in getting people on NHibernate by simplifying a lot of that ORM's configuration chores.

The Chicago ALT.NET meetings start at 6PM in the Sears Tower. Check the website for complete location details.

July 14^th, WI.NET

JavaScript - Beyond the Curly Braces
I'm taking my little JS presentation to the WI.NET UG in Milwaukee. The group's website hasn't been updated with the presentation details yet but it's basically the same presentation given at other local UGs.

The meeting starts at 7PM. Come ready to be surprised.

What is a build script? Writing MsBuild Scripts - Part I

Tuna Toksoz — Sun, 05 Jul 2009 18:36:00 GMT

I was thinking of writing post series on NAnt but then I decided to write some on MsBuild first.

This post will briefly introduce you the basic concepts of automation of build, why we need build tools/scripts, and what alternatives we have.

Let’s first start with the definition of build script/tool.

What is a build script?

A build script is all about automation. When we compile projects, we also want to perform some other steps such as running tests, compiling documentation, create an examples package, move some files from one location to another, and in the end zip them, or create an installer for the project. Doing them by hand is not really an option, and you may have thought of preparing a batch file/shell script before you learnt the build files.

For me, Makefile was the first place that I heard about the term “build script”. It is mainly used in Linux to compile applications.

When we take a look at a sample makefile


OBJS = main.obj io.obj
CC = bcc
MODEL = s
CFLAGS = –m$(MODEL) 



project.exe : $(OBJS)
	tlink c0$(MODEL) $(OBJS), $(.TARGET),, c$(MODEL) /Lf:\bc\lib

main.obj : main.c
	$(CC) $(CFLAGS) –c $(.SOURCE)

io.obj : io.c
	$(CC) $(CFLAGS) –c $(.SOURCE)

  	$(OBJS) : incl.h

First we have several properties which we’ll use later, they are like variables.
Then we have some targets which has “:” on the right. On the right of “:”, we have their “dependencies”. A dependency is a unit that has to be run before the dependent, or a file that our file depends on. For example, main.obj depends on main.c and in case main.c is modified, we will run that target again. The lines after the target are the commands which will be run as part of the target.

This dependency idea is key to every build system and main points in writing a build script is to find dependencies of your project. After you define them, the rest is a piece of chocolate cake!

OK, i spoke too much Linux for a .net blog :) Let’s turn to our beautiful .net World.

In .net world, there are 2(AFAIK, if not please comment) build tools written specifically for .NET. One is the famous NAnt, and the other is MsBuild. NAnt is usually used in OpenSource project. MsBuild is being used since VS 2005, and it is part of the framework. Your csproj files are actually MsBuild files.

Most people say that that nant is more flexible and mature, but they also say that the nativeness of MsBuild into visual studio is a plus. Some they say that they delegate the build to MsBuild while using Nant for other stuff.

In the next post, we’ll write(and use .csproj) a basic MsBuild script.

If you like the post, please kick it and shout it.

TeamCity Remote Runs / Personal Builds

Tuna Toksoz — Fri, 03 Jul 2009 12:44:00 GMT

This is a killer feature of TeamCity against other CI servers, I believe.

TC allows you to test your changes before committing them to the Source Control Repository, which means that you don’t have to worry about breaking the build, because you won’t :)

I needed this in order to try a fix that I had for an issue in NH, it worked on my machine but not sure if it works on another one.

Krzysztof Kozmic told me in the same evening that he’s going to try a fix against DP with personal build, and I thought it was a great idea!

Then it runs your changes on one of the build agents.

There we go! Patch didn’t break anything (even though it may not be how it should be)

Keep up the good work, JetBrains!

Ignoring files/folders when committing to SVN repository

Tuna Toksoz — Fri, 03 Jul 2009 12:43:36 GMT

This feature of SVN is very handy. After you build your projects, there will be dlls in bin folders etc which you don’t want to commit.

Using svn:ignore property of SVN, you can eliminate the possibility of committing those files!

As many other things, I learnt this from NH :)

Code Contracts Primer – Part 5: Utilizing Object Invariants

Derik Whittaker — Wed, 01 Jul 2009 10:03:13 GMT

If you are not familiar with the Code Contracts library which is coming out of Microsoft R&D labs, you need to check this pretty cool little library out. As of Vs2010/.Net 4.0 this library will be making the jump out of the R&D labs.

Over the next few blog posts we will be taking a look at the topics below.

Downloading and setting up the contracts library
Handling Legacy Code
Providing Support for Unit Tests
Utilizing Pre & Post Conditions
Utilizing Object Invariants (this post)
Performing checking in base classes/abstract classes

In this post we are going to take a look at what I think is one of the coolest features of the Contracts Library. The concept of Object Invariants.

What is Object Invariant validation?

This part of the library ensures that when the state of an object is changed that the object remains in valid state. If the state of the object is to become invalid then your contract would fail and this would be an issue.

Imagine you have a class called ReportCard, this class is used by a timekeeping system and is used to store instances of daily report cards (a daily report card holds the time/hours worked for that employee). We want to setup a rule which says that depending on the employee type they are not allowed to work > 40 hours (the actual number is not important). We also want to setup the ability to ensure they do not work < 0 hours.

Prior to code contracts you would need to create your state checking method and then place calls to the validator at location where the state changes. This is both tedious and error prone because as your add more code (hopefully you follow the Open/Close principle and extend the class not keep piling on new code, but that is a different post) you have to remember to add the state checking logic. With invariants you do not need to do that. All you need to do is below.

[ContractInvariantMethod]
public void EnsureReportHoursIsInValidRange()
{
    Contract.Invariant( EmployeeID > 0 );

    var totalHours = TotalHours(); // Calcs total hours

    Contract.Invariant(totalHours >= 0);
    Contract.Invariant(totalHours <= 40);
}

Taking a look at this code there are a few things you should know

The [ContractInvariantMethod] is what makes this method the invariant checking method
You MUST use Contract.Invariant to do your assertions
You can only have 1 method in your class which has the [ContractInvariantMethod] attribute (which just makes sense, but thought I would mention it)
The code weaver will add calls to your invariant logic ANY place the state changes in the object.

Here is the same code above, but this time POST code weaving.

public void AddDailyReport(DailyCards dailyCards)
{
	this.DailyReportCards.Add(dailyCards);
        this.EnsureReportHoursIsInValidRange();
}

[ContractInvariantMethod]
public void EnsureReportHoursIsInValidRange()
{
	if (!this.$evaluatingInvariant$)
        {
            this.$evaluatingInvariant$ = true;
            try
            {
                __ContractsRuntime.Invariant(this.EmployeeID > 0, null, "EmployeeID > 0");
                double num = this.TotalHours();
                __ContractsRuntime.Invariant(num >= 0.0, null, "");
                __ContractsRuntime.Invariant(num <= 40.0, null, "totalHours <= 40");
            }
            finally
            {
                this.$evaluatingInvariant$ = false;
            }
        }
}

The key thing to notice when looking at the reflected code is how the weaver added the call this.EnsureReportHoursIsInValidRange(); in the AddDailyReport() method.

2 Things to watch out for when utilizing the Object Invariant

Remember to make sure that your state validation logic is light and runs quickly. Because the validation logic will be called EVERY TIME the state changes this logic could be called often. If your validation does things like reach out to the DB or any other dependency your experience with this will suffer and your performance will also suffer.
When debugging your invariant logic your ‘debug experience’ will not be the same as normal. When I first started to use this I was confused by the fact that when i would run the code in real time it all worked. However when I stepped into the code it did not appear to be working correctly. I have never figured out the EXACT reason for this, but I am 99% sure it has to do with the way the weaver alters the code.

Till next time,

Hangin the with guys from Thirsty Developer

Derik Whittaker — Wed, 01 Jul 2009 00:22:00 GMT

A few weeks back I sat down with Larry Clarkin to record an episode of the Thirsty Developer (a podcast that he and Dave Bost put out) prior to my doing my SOLID session with the WI-Ineta group. Larry and I sat down at a local starbucks to chat about the session as well as just talk shop (Dave was off on assignment some place, but was there in spirit).

Well, Larry went off and actually released the episode (hey, when you chat with me the quality mileage may vary :) ) back a week or so ago while I was on a 2 week hiatus from the net (1 week vacation and 1 week of client visits for work) so I am a little behind in making the announcement about this.

Anyway, if you want to listen to our conversation you can check out here. I hope you like it and I am looking forward to sitting down with them in the future to chat again.

Till next time,

Also, if you do not currently subscribe to their RSS feed I would strongly suggest you give them a listen, they are great guys and a ton of fun

The "Risk" of Open Source Software Support

Tim Barcz — Tue, 30 Jun 2009 03:18:00 GMT

Quite often there is a fear that surrounds open source tools and frameworks. For most shops the deciding factor against open source software is the apparent "risk" that is associated with a framework/tool that is not attached to any business entity.

In this post I want to share an interaction that occurred this last weekend to show you that the open source ecosystem is alive and very healthy. And while I won't go so far as to say the "risk" doesn't exist (you have to come to that conclusion on your time when your own fears are allayed) I do hope that this post puts some of those fears to rest.

Saturday morning before I went off to work there was a question posted to the RhinoMocks mailing list (for those who don't know RhinoMocks is an open source mocking framework). Before the end of the day the problem was resolved to a satisfactory conclusion. The "solution" (I put in quotes because there appears to be a bug but at least now we know there is a bug...hence "solution"). The result is not as important as the events that transpired to reach that conclusion below is the timeline.

12:22 AM - Kenneth posts the problem he is encountering

6:53 AM - I respond on the mailing list back to Kenneth with my findings and let him know that I will get some experts in DynamicProxy involved

6:56 AM - I enlisted the help of Krzysztof Kozmic on twitter (Krzysztof is a committer on DynamicProxy by Castle as has a great tutorial series on Dynamic Proxy)

8:38 AM - Fellow Devlicious blogger Tuna Toksoz (also a committer on the Castle project) hopped on the case and reported his findings

9:22 AM - Krzysztof responds to Tuna's findings reporting back on the root cause

10:23 AM - Kenneth reported back with feedback of Tuna's fix

Ultimately, as I mentioned earlier the fix was that it was found that RhinoMocks "relies on the buggy behavior, hence the error" (Krzysztof's words). Again the result here isn't what is important but rather the journey. Often people fear the support ecosystem around open source software but the exchange above and the players involved should give you some bit of confidence in the support of open source. It is worth pointing out that all of this happened on a Saturday, something you'd pay a premium for in a closed source model.

Whatever your roll in the software world is, one aspect you have to consider when choosing any solution is risk. The traditional thought has been that with commercial software the support would be better when backed by a reputable name. I think the exchange showcased above demonstrates that support for open source software can compete (and potentially surpass) support that any commercial piece of software could offer. Keep that in mind the next time you are evaluating commercial software versus open source software.

A Craftsman sometimes has to create his own tool

sergiopereira — Sun, 28 Jun 2009 15:15:00 GMT

Today I was reading the latest one of the many excellent blog posts Patrick Smacchia has put out on the topic of code metrics and caring for your code's quality.

The passion this guy has for that topic is such that he has created the best tool for analyzing your code. But he doesn't stop there. He wants to make sure we understand what is going on behind the seemingly magic CQL queries that ship with NDepend. He wants you to understand your code's DNA; with the added bonus that you can actually improve that DNA.

That's Science with capital S.

First you understand the problem that you are trying to fight (code complexity/unmaintainable software,)
you research ways to quantify it (the metrics,)
you create some tool or device to extract that information from your subject,
you extract the metrics from a familiar subject,
you apply your knowledge of how #2 relates to #1 and improve the subject under analysis,
you use the tool to verify the metrics have improved,
time shows you that the changes you made indeed reduced the problem at #1

I simply hate when someone criticizes Patrick's posts as being just marketing material for his product. Let me tell you this. If I had that much dedication for software quality, to the point that I had created a great product to empower everyone, I'd also be trying to explain the problem to you using the tool I wrote. Heck, I'm pretty sure if someone else had written NDepend Patrick would still be writing about these things and using the tool in the process.

I like code metrics and static analysis a lot as well, not nearly as much as Mr Smacchia though. I'm very excited that very soon I'll get to use it in our code base, in our CI server. I can't wait to learn more about this science and inflict positive changes in our code. Like everybody else, we know there's dirt and bad smells in our code and it's just awesome that there's a tool that can help us clearly identify, mitigate, and track it.

My hope is that I'll be able to come back here and share what I've learned about my code and how the process we went through to improve it.

Grooving with my new toy

Derik Whittaker — Sat, 27 Jun 2009 18:55:37 GMT

Ok, so it is official I have jumped on the ‘gotta have a mac bandwagon’. The week prior to father’s day my lovely wife decided that I could get a new MacBook Pro (well, Dimecasts was going to pay 75% of the cost and she would pay the other 25%). I decided that I was not going to make this new machine my primary box, so I went small and picked up the 13.3 model.

So, why did I get one? Because I could silly :). No, mostly to learn and play. I want to learn how to code in a different environment and with different languages. On my list is Ruby (of course), Objective-C and maybe some playing with Java. I do plan on building a iPhone app for Dimecasts (just need to find the time now).

With about 2 weeks of using/playing under my belt and I have to admit the transition has been pretty easy. About the only real annoyance is the fact that they keyboard is a bit different than a PC, but over time.

Anyway, thought I would share with the world that I got a new toy. BTW, Windows 7 runs SUPER fast under VM on this box.

Till next time,

Fluent Interface for NH Facility – Take 1

Tuna Toksoz — Sat, 27 Jun 2009 11:39:00 GMT

We’ve been getting many requests on having fluent configuration for NHibernate Integration Facility, and as I like programmatic configuration more than XML configuration (did I mention that I hate XML?), I decided to work on it. After 2-3 hours, I got the below more or less working

container.Register(
Fluently.ConfigureFacility()
    .Id("nhibernateFacility")
    .DefaultConfigurationBuilder<DefaultConfigurationBuilder>()
    .DefaultConfigurationPersister<DefaultConfigurationPersister>()
    .AddFactory(
                    Fluently.ConfigureFactory()
                        .Alias("myAlias")
                        .Id("myId")
                        .UsingConfiguration(
                        FactoryConfigurator.DefaultBuilder()
                            .ConnectionProvider("…………………………")
                            .ConnectionDriver("…………………………")
                            .ConnectionString("…………………………")
                            .Dialect("…………………………")
                            .ProxyFactory("…………………………")
                            .Assemblies("…………………………")))
    .AddFactory(
                    Fluently.ConfigureFactory()
                        .Alias("myAlias")
                        .Id("myId")
                        .UsingConfiguration(
                        FactoryConfigurator.XmlBuilder().File("myFile.xml"))));

The pieces in Italic are not necessary to write as they have their defaults, also we have some generic overloads for things like Dialect, ProxyFactory and ConnectionProvider.

What the above interface does is that it actually converts all the above configuration to IConfiguration and add them to the container as Facility Configuration, this is actually what is done behind the scenes when you use XML configuration.

I asked for a review over the syntax from several tweeps (@kkozmic, @dagda1, @mikehadlow, @chriscanal) and from one other NH Facility user, German Schuager, and got great feedback.

One of the issues that they pointed out with the above interface is that it is less discoverable. You have to find Fluently class, and then FactoryConfigurator class. Another issue is that it feels less natural to configure the facility like this. Instead, they prefer the configuration take place right on the facility.

This one is what German Schuager has suggested

container.AddFacility<NHibernateFacility>("nhibernateFacility", cfg => cfg
        .DefaultConfigurationBuilder<DefaultConfigurationBuilder>()
        .DefaultConfigurationPersister<DefaultConfigurationPersister>()
        .AddFactory("id1", f => f
                .Alias("myAlias")
                .UsingConfiguration<DefaultBuilder>(c => c
                        .ConnectionProvider("………")
                        .ConnectionDriver("………")
                        .ConnectionString("………")
                        .Dialect("………")
                        .ProxyFactory("………")
                        .Assemblies("………")
                ))
        .AddFactory("id2", f => f
                .Alias("alias")
                .UsingConfiguration<XmlBuilder>(c => c
                        .ReadFrom("myfile.xml")
                ))
 });

and similar one from Krzysztof Kozmic.

Looks like i was the only one that is fan of Castle Microkernel style Fluent Interface.

Let’s see what I’ll come up for the second take, If I ever do it.

Two VANs on Castle Project

Tuna Toksoz — Sat, 27 Jun 2009 09:25:00 GMT

I like VAN meetings, and I believe I am gaining a lot from them. Due to some time zone problem, I remember waiting 1 hour in front of the PC :) I had even plans for presenting something on those VANs but nah things don’t go like the way I want. Zachariah Young informed me that there are 2 VANs in the following two weeks that cover some topic on Castle. I believe it would be a good idea to join to those meetings, even if you’re using some other framework or don’t use anything at all.

Ryan will be doing a two part series on the Castle Project. Mark your calendar for some Castle Project fun.

A little information on Ryan Svihla
Ryan Svihla has been working as a C# developer Farm Bureau Bank in San Antonio since September 2007. Before that he worked as a Consultant in Lincoln, NE for 3 years, where he had working experience with Php, some Perl, Python and of course C#. Attemping Agile since early 2008 as an eager student with a focus on making programming more useful and relevant for the end user.

IoC and Dip through Castle Windsor
I assume readers have some familiarity with IoC and DI, so I skip description
Central Daylight Time
Start Time: Web, July 1, 2009 8:00 PM UTC/GMT -5 hours
End Time: Web, July 1, 2009 10:00 PM UTC/GMT -5 hours
Attendee URL: http://snipr.com/virtualaltnet (Live Meeting)

Web Development with Castle Monorail, Active Record and Brail view engine
Have a look at the first popular MVC .Net based web framework. Also will be covering persistance with ActiveRecord, and view templates using Brail. Bonus, will demo a plugin framework for building CMS like applications.
Central Daylight Time
Start Time: Web, July 8, 2009 8:00 PM UTC/GMT -5 hours
End Time: Web, July 8, 2009 10:00 PM UTC/GMT -5 hours
Attendee URL: http://snipr.com/virtualaltnet (Live Meeting)

For more info on VAN go to www.virtualaltnet.com

I’ll try to join those, see you there!

Just Be Honest and Tell the Truth

Jeff Perrin — Thu, 25 Jun 2009 00:27:00 GMT

I just read Ron Jefferies latest post entitled My Named Cloud is Better Than Your Named Cloud and it got me riled up enough to post something I've been meaning to write about for at least a couple of years. His post touches on the point I'd wanted to make, but doesn't quite say it as simply as I think it can be said. Here's what I'm thinking:

If we could just always be honest with ourselves, as people, team members and organizations, software development wouldn't be that hard.

There. Simple. Think about it for a second. All this stuff that we label and group together under methodologies and processes is really there so that we can do One Thing. This one thing, I'm assuming, is usually to create software that fulfills a need. Let's pretend that a software team has been assembled to create an application that fulfills such a need. They've chosen to use the XP methodology while writing this application. I'll go through some of the tenets of XP and run them through my honesty filter:

Pair programming: The team realizes that people will come and go on a project for good (quit, fired, etc), or for short periods of time (maternity leave, vacation, illness, etc). They want to minimize the risk, so they make sure everyone is familiar with every piece of the code base. They also realize that sometimes even the best developers do stupid shit for no good reason, and believe that having two sets of eyes on the screen at all times will lessen the likely hood of this happening.
TDD: The team realizes that writing software is hard, and that stuff that worked last week will have to be changed this week. Since they want to ensure that stuff they worked on earlier still works when they make these changes, they write tests, and ensure that no code gets checked in unless all the tests are passing. They also hope that these tests provide some form of documentation to any developers (and perhaps users/clients) that may come later or who never worked on the feature originally.
Incremental design: The team realizes that there are unforeseen forces that may threaten a project at any given time. A big project entails a large amount of risk for both clients and developers. If features can be developed in incremental fashion, hopefully in an order representing the importance of each feature, then risks can be mitigated. The team is always working with a usable application, so that if something comes up that stops the project, at least the client will have something to work with.

Now obviously there is more to XP than what I've listed. The point is that those three things exist to handle a need that most teams, if they are really honest with themselves have:

Knowledge transfer. Nobody wants to have to rely on one person to get something done. Sooner or later, this always bites us in the ass. Pairing is one way to handle this.
Developed features continue working. Nothing is more frustrating (to users and developers) than having something that used to work perfectly stop working. Testing is one way to handle this.
The need to guarantee that something will come out of all the money we're spending. What happens if the development shop you've contracted goes bankrupt before they've finished your application? Incremental design is one way to handle this.

Listen. We have methodologies and processes for a reason (I hope). Some of these processes may work for you. However, maybe only some parts of a process work for you. The point is, it's not about the process. If you can understand why you're using a particular piece of a process, you can assess whether it's useful for your team. Who cares whether you're doing XP, Scrum, Lean, Kanban, Waterfall, or Hack 'n' Slash. Those are just names. Identify your pain points, problems, worries, etc, and try to fix them. Honestly.

We Are Not Doing DDD – Part Two - CQS

Jak Charlton — Mon, 22 Jun 2009 16:32:58 GMT

From the beginning of my current project we have been working under some horrible constraints, many imposed by legacy systems, many by late decisions that would have speeded things immensely if made earlier, and many imposed by decisions that are outside of my control.

This lead us early on to make decisions on architecture that eliminated any possibility of using DDD heavily, and as I mentioned in my original post about this project it is also essentially a glorified CRUD system - we read data from databases, we modify it a bit, and we put it back again.

What We Are Doing – Command Query Separation

The first architectural choice that I made, and in hindsight got accepted with relative ease, was to employ CQS to simplify the system.

Earlier projects had suffered quite badly from being abstractions of legacy systems with new functionality bolted on. As

far as possible I wanted to eliminate this problem from our project, as I was all too aware that this was an easy trap for the team to fall into, and would burn a lot of development time very fast.

To make the system simpler I chose to separate our query mechanisms from the "domain" type stuff, our commands and data writing/updating code.

CQS is a pretty simple concept. One path through your system is responsible for querying of anything much more than "Get By ID" type calls. This side of our system is responsible for reading data from legacy systems, reading data from legacy web services, and for reading data from our application database.

Querying

The Query side deals largely in DataTables, DataSets and a very very limited number of DTOs. This data is largely and essentially used for display purposes, it is the contents of search results, the results of postcode lookups, the information to populate dropdown lists and tables.

The Query side of CQS does not need strongly typed entities, nor does it require strongly typed DTOs - as it is largely ad-hoc data maintaining these entities and DTOs would consume a disproportionate amount of development time for something a DataTable can deal with more than adequately.

Our Query side actually uses the Query Object pattern, most of which encapsulate a call to an Oracle DB, some of which wrap simple NHibernate criteria and a few of which sit around web services. These are fronted by a WCF facade, which allows us to put these queries out of process, and to cache them aggressively should be need.

What we do not have in the system anywhere, and especially in the Query side, is any big entity model – we have two very small entity models (5 entities in total) used for very specific functions within our application.

Command

The Command side of the CQS equation is a little different. Firstly, it deals with anything that is essentially a request to "go do something". In our case these are commands like "SaveDraft" and "CancelPolicy"

The Command side can write data to the databases, the Query side is not allowed to.

If we were doing DDD, this is where our Domain would sit - and in fact we have been referring to this as "the domain" for most of this project. But, we aren’t using DDD and we don't really have a Domain Model. It is however where most stuff we could describe as "logic" lives. This is primarily a bunch of application services, most of which operate in response to messages fired over MSMQ using NServiceBus.

This side of the architecture has a number of listeners that are responsible for pulling messages from various MSMQs and for dealing with the specific requests, for example pushing data back to our legacy systems, for logging, and eventually for notifications.

Benefits

Early on, the use of CQS paid for itself easily. By removing the complications of maintaining read and write models together, we quickly managed to get working prototype up and running, with no need for a "domain" or entity model up front.

As the project has progressed, this decision has helped simplify decisions that otherwise would have involved structural or fundamental changes to the architecture – but more importantly, it has helped all of the developers think in terms of a command driven system, rather than viewing the system as CRUD over a database.

One day with Balsamiq Mockups: a review

Christopher Bennage — Fri, 19 Jun 2009 04:03:00 GMT

We’ve just started a new Silverlight project and since ~~our~~ the UI guy is not on site with us, I ended up with the task of producing screen mockups. Some interest was expressed in using Balsamiq Mockups, and this seemed like a good time to really take it for a test drive.

What does it do?

Balsamiq is a tool for quickly authoring mockups of applications and websites. My favorite tool for doing mockups is pencil and paper (turns out that it’s really, really good). However, we needed something that we could readily show during a review meeting and my sketches don’t photocopy well.

Nevertheless, I did my brainstorming on paper and I used it for my first round of reviews with the team. This left me with about a dozen pages storyboarding the core of our application.

After the first review, I began recreate it with Balsamiq.

In Balsamiq you start with a blank, gridded canvas and drag various UI elements from a library onto the canvas. It reminds me of Visio a bit, but without so much pain. All of the elements are styled to look like hand-drawn. This is important because it prevents anyone from assuming that the application is “done” when you’re just presenting mockups.

The elements in Balsamiq are impressively intelligent. Most elements allow you to type in some content and they react intuitively to that content. I was amazed a couple of time at how smartly they responded. Balsamiq ships with about 75 elements in its library and there are more being posted all the time. You cannot really extend the library yourself however, though you can incorporate your own images.

Each mockup screen is a single file. They are XML so it’s source control friendly. If you are mocking up an entire application (like I was) you can link the files together. Many of the elements have a link property that you can point to any other Balsamiq files in the same directory. Once you’ve linked up some files, you can “run” your mockups in presentation mode. This allows you to navigate around the application and toggle annotations (like the sticky note in my screen shot). The presentation mode is really cool.

Should you buy it?

I think that mocking up the UI is a very useful exercise. It helps to expose the behavior of the application that you are going to build and surfaces many insights into what it really needs to do. I still prefer to use paper and pencil for the initial pass. However, I found that following this up with Balsamiq forced me to think through the entire flow of my appplication. My paper storyboards had holes in them that I did not realize until I attempted to express them in Balsamiq.

The reviewers were really excited to see the Balsamiq mockups and being able to walk them through the application was a definite plus for them. The tool is easy to use. I would say that any ~~designer~~ developer doing UI work should be using a tool like Balsamiq.

What it offers for $79 is really hard to beat. Admittedly, I don’t know what other tools are out there and how they compare. By itself, I think it definitely worth it for anyone doing UI work.

Of course, there is SketchFlow. It is coming. I think that SketchFlow looks very promising, especially for us XAML guys, but it’s not available yet. I’ll let you know what I think about the overlap once I get a change to actually use SketchFlow.

Little Things

I had a couple of annoyances that are worth pointing out.

First, you cannot create reusable components. For example, I had certain elements of the application that appeared in several places. I had to clone these elements, but when I needed to change them, I had to make the change in each element. (Another reason to start with pencil).

I think that it would also be nice if there was a “back button” in presentation mode. Within my mockup I had a few screens that you could get too in multiple ways, however I did not have an easy way of returning the the previous screen.

I also get the impression that the community around Balsamiq likes to poke fun at us PC guys. I smile politely.

Finally, Balsamiq likes to keep all of the linked files open. You’ll notice an excessive number of tabs on the bottom of the screen shot. Those are all the screens within the application I was mocking. It became a little difficult to find that right one.

On the whole, Balsamiq is a smart application and I expect to see great things as it matures. Many of its features are intuitive and “just work”, and that’s how I like my software to roll.

:-P

VS Addin: Fast Add Reference Dialog - No more Coffee Break!

Tuna Toksoz — Thu, 18 Jun 2009 20:28:00 GMT

UPDATE 2: Now solution folders and some other stuff are done, thanks to Huseyin Tufekcilerli

UPDATE: I updated the dlls and the source in the link, now it doesn't crash VS. Hopefully the only problem left is that solutions with multiple solution folders won't be reflected in Projects tab.

I have spent a couple of days on implementing a fast add reference dialog box for Visual Studio (with some help from an existing addin). The time of adding a reference has been a great time to have some coffee, to have lunch, or even a way to save economy (remember, developer time costs money!). If you don’t believe me, take a look at what tweeps say.

It is actually easy once you find some of the extension points of Visual Studio.

In my case, I had to implement IDTExtensibility2 which contains method signatures to be called when a plugin is loaded, unloaded etc.

As first step, I had added “Add Quick Reference” item to the context menu when a project is right clicked. This is the most tricky part as there is almost no documentation on that.

The method that we should implement for this is:

public void OnConnection(object application, ext_ConnectMode connectMode, 
                         object addInInst, ref Array custom)

The type of the application parameter implements DTE2 interface and the addInInst parameter implements AddIn interface, which has all we need.

The DTE2 interface has CommandBars property which gives us access to various VS stuff. The matter is to find the right one. After for-looping all CommandBar item, i found that the place I should add my custom item is “Context Menus”->”Project and Solution Context Menus”->”Reference Root”. Man this is hard to locate! Looking forward to MEF in 2010!

applicationObject = (DTE2)application;
addInInstance = (AddIn)addInInst;
CommandBars cb = applicationObject.CommandBars as CommandBars;
CommandBar bar = cb["Context Menus"];
CommandBarPopup cbarControl = bar.Controls["Project and Solution Context Menus"] 
                              as CommandBarPopup;
var commandBarControls = cbarControl.Controls;
this.referenceRoots = commandBarControls["Reference Root"] as CommandBarPopup;

button = this.referenceRoots.Controls.Add(MsoControlType.msoControlButton,
                           System.Reflection.Missing.Value,
                           System.Reflection.Missing.Value, 1, true) 
                            as CommandBarButton;
button.Caption = "Add Quick Reference";
button.Click += oControl_Click;

There is one thing to be careful about: If you want to handle events of a button, for example, you should hold a reference in your class. Local method variables wouldn’t work. This situation is better told here

Now, I am done. I should now design the dialog itself that looks very similar to the original one. There is another problem: There is no "Windows Explorer Like” control for Windows Forms. There is OpenFileDialog but it is a dialog, not a control. I found the most similar one at GongShell Project which is licensed under GPL.

My current screen looks like the one below:

Very similar, even if I say so myself.

One thing to notice here is that the first tab is browse(.NET in original dialog), second is .net (Browse in original dialog) and third one is Projects. I haven’t written “Recent” part as I don’t want to deal with I/O really.

I believe that Browse window is more frequently used than .NET tab. There can be more improvements on that screen, such as having “common” tab which does the copying of commonly used references to a new project but hey this is a demonstration only ! :)

The items in the .NET tab are loaded in the background, and once it is loaded, it will be cached during the lifetime of the application.

I won’t comment more on the code, go grab it and try it. I wont continue developing this little addin, so you are free to do it on your own. Just drop me an email when you do it, though.

I just warn you: Com stuff is like walking on a mine field, and I am not taking any responsibility in case you loose data.

Download the code and the binaries here and put the binaries into Documents\Visual Studio 2008\Addins folder. Have fun!

If you like the post and the tool, please Kick! and Shout! it below!

Code Contracts Primer – Part 4: Utilizing Pre & Post Conditions

Derik Whittaker — Mon, 15 Jun 2009 19:29:55 GMT

Over the next few blog posts we will be taking a look at the topics below.

Downloading and setting up the contracts library
Handling Legacy Code
Providing Support for Unit Tests
Utilizing Pre & Post Conditions (this post)
Utilizing Object Invariants
Performing checking in base classes/abstract classes

In this post we are going to take a look at what might be considered the most basic usage scenario for the contracts library, Pre and Post condition validation.

What is a pre-condition validation?
This is when we want to validate the state of the world (parameters or other state holding values) is valid prior to running a method. Pre-condition validation is done by utilizing the Contract.Requires(…) or Contract.Requires<CustomExceptionHere>(…) method.

The code below is what your pre-condition code could look like the code below:

public ReportCard GetDailyReportCard(Int32 employeeId, DateTime dateForReportCard)
{
	Contract.Requires(employeeId > 0);
	Contract.Requires<ArgumentOutOfRangeException>(dateForReportCard.Date == DateTime.Now.Date);


	// do something meaning
	var reportCard = new ReportCard(employeeId);

	return reportCard;
}

The code above shows 2 different ways you can use the contracts libray. The first simply uses the standard .Requires() logic and is meant to ensure that the employeeId is always > 0. The second uses the overload of .Requires<>() and will provide the exception type which should be thrown if a contract is violated. As we have mentioned before, the contracts library uses Code Weaving to do its magic. Lets take a look at how it re-wrote the .Requires() for us on the back end (via reflector).

public ReportCard GetDailyReportCard(int employeeId, DateTime dateForReportCard)
{
	if (__ContractsRuntime.insideContractEvaluation <= 4)
	{
		try
		{
			__ContractsRuntime.insideContractEvaluation++;
			__ContractsRuntime.Requires(employeeId > 0, null, "employeeId > 0");
			__ContractsRuntime.Requires(dateForReportCard.Date == DateTime.Now.Date, null, "dateForReportCard.Date == DateTime.Now.Date");
		}
		finally
		{	
			__ContractsRuntime.insideContractEvaluation--;
		}
	}
	
	return new ReportCard(employeeId);
}

As you can see the code has changed, but not too much.

Now that we have mastered pre-conditions it is time to take a look at post-conditions

What is a post-condition validation?
This is when you want to validate the state of a method when that method terminates. With post conditions you can assert that the return value so the caller can be assured the values will always be within range when returned. Post-Condition checks can be done with the Contract.Ensures() method and can take a special command which is Contract.Result<> which allows you to specify the result type and its condition.

The code below is an simple example of how you can create your post-condition check.

public ReportCard GetWeeklyReportCard( Int32 employeeId )
{
	Contract.Ensures( Contract.Result<ReportCard>() != null );
	
	var reportCard = new ReportCard( employeeId );
	
	return reportCard;           
}

In the check above we are simply trying to ensure that the return value from this method will never be null. Of course this is just a simple example and you could validate over types of items as well.

As we did in the pre-condition, lets take a look at the code as it exists after code weaving:

public ReportCard GetWeeklyReportCard(int employeeId)
{
	ReportCard reportCard = new ReportCard(employeeId);
	ReportCard CS$1$0000 = reportCard;
	ReportCard Contract.Result() = CS$1$0000;
	if (__ContractsRuntime.insideContractEvaluation <= 4)
	{	
		try
		{
			__ContractsRuntime.insideContractEvaluation++;
			__ContractsRuntime.Ensures(Contract.Result() != null, null, "Contract.Result() != null");
		}
		finally
		{
			__ContractsRuntime.insideContractEvaluation--;
		}
	}

	return Contract.Result();
}

Again you can see that the weaver did its magic, but this time it did a bit more work. The good news for us is that the code still works as intended so there is nothing too much to worry about.

Now that we have taking a look at both pre-conditions and post-condition checking with the contracts library you are more than on your way to utilizing this library in your code.

Till next time,

Spotlight on JavaScript at the CNUG

sergiopereira — Mon, 15 Jun 2009 18:09:00 GMT

This Wednesday, June 17^th, the Chicago .NET Users Group, CNUG, has invited me to bring my JavaScript presentation to their monthly meeting.

Despite of what the event description might lead you to believe, the talk is hardcore JavaScript, not much specific to Ajax at all, although I believe the material will greatly help you with the Ajax work as well.

You can read the complete talk description and register for the event. Hope to see you there.

Joining NHibernate Transaction with ADO SqlTransaction

Derik Whittaker — Mon, 15 Jun 2009 16:35:54 GMT

Recently (ok, today) I needed to drop down into ADO to call a procedure in our code. I was not too happy with it, but either my lack of knowledge or lack of will to figure it out mandated it. What I needed to do was create a build-insert process and using NHibernate was not the right solution for performance reasons.

When I first created my code, seen below my tests worked fine.

public void AssignNewDestinationToPatients( Destination destination )
{
    var connection = (SqlConnection) Session.Connection;
    
    var sqlCommand = new SqlCommand
                         {
                             CommandType = CommandType.StoredProcedure,
                             CommandText = StoredProcedures.DO_SOMETHING,
                             Connection = connection,                                     
                         };

    sqlCommand.Parameters.Add( new SqlParameter( "DestinationID", destination.DestinationID ) );

    sqlCommand.ExecuteNonQuery()    ;
}

However, once this call was wrapped around an NH transaction i would receive the following error:

{"ExecuteNonQuery requires the command to have a transaction when the connection assigned to the command is in a pending local transaction. The Transaction property of the command has not been initialized."}

Of course the first I tried to do was cast the NH transaction to a sql transaction and provide that to the command object. However, that is NOT possible. The great news for me was the NH has the capacity to enlist a sql commmand and add it to its transaction. The code below shows how to do this.

public void AssignNewDestinationToPatients( Destination destination )
{
    var connection = (SqlConnection) Session.Connection;
    
    var sqlCommand = new SqlCommand
                         {
                             CommandType = CommandType.StoredProcedure,
                             CommandText = StoredProcedures.DO_SOMETHING,
                             Connection = connection,                                     
                         };

    // this is the magic code
    if ( Session.Transaction != null && Session.Transaction.IsActive )
    {
        Session.Transaction.Enlist( sqlCommand );
    }

    sqlCommand.Parameters.Add( new SqlParameter( "DestinationID", destination.DestinationID ) );

    sqlCommand.ExecuteNonQuery()    ;
}

So, if you need to drop down to ADO from NHibernate and you need to use transactions, this solution should work out well for you.

Till next time,

P.S. If there is a better, simpler way please let me know.

Code Contracts Primer – Part 3: Providing Support for Unit Tests

Derik Whittaker — Sat, 13 Jun 2009 14:46:00 GMT

Over the next few blog posts we will be taking a look at the topics below.

Downloading and setting up the contracts library
Handling Legacy Code
Providing Support for Unit Tests (this post)
Utilizing Pre & Post Conditions
Utilizing Object Invariants
Performing checking in base classes/abstract classes

In this post we are going to take a look at how you can setup your unit tests to handle violations from your contracts. If you do not provide any additional support in your code and you violate a contract at test time you will see a dialog like the one below:

The problem with having a dialog like this appear during your test runs should be apparent. Any type of dialog will cause any automated build/test system to pause and wait until there is some user interaction, this is BAD.

The good news is that resolving this issue is actually simple and can be done with a few lines of code. All we need to do is hookup the event listener which the contracts library provides and trap for the violation. The code below shows us how to do this.

private bool _contractViolationHandled;

[SetUp]
public void Setup()
{
    Contract.ContractFailed += (sender, o) =>
                                   {
                                       o.SetHandled();
                                       _contractViolationHandled = true;
                                   };
}

[TearDown]
public void TearDown()
{
    _contractViolationHandled = false;
}

As you can see from the code above, wiring to handle the violations is simple. But we should point out a few lines to pay attention to.

o.SetHandled(); – If you do not set this you will still be able to handle the error, but it will continue to bubble up and you will still get the dialog
[TearDown] – because we are setting a global variable in the setup, we MUST rest that value other wise you may get false errors in future test runs.

There you go, if you need to trap hand handle contract violations in your unit tests, you can utilize the technique above to avoid getting the violations dialog.

Till next time,

Caliburn v1 Release Candidate

Rob Eisenberg — Sat, 13 Jun 2009 04:19:00 GMT

On Friday I published the Release Candidate for Caliburn. You can get it here. I’m hoping to only do bug fixes and a few minor changes between now and release. There have been quite a few important changes since the Beta:

Refactored assemblies for greater ease of use.
Implemented an Application base class that supports model-first development.
Introduced IViewStrategy and the View.Model attached property.
Added CommandSource triggers
Tweaked the implementation of Actions/Commands so that it performs better and is more intelligent
Updated dependencies on other OSS projects
Added a WPF version of the LOB Sample
Factored out mini-frameworks for the both the WPF and Silverlight LOB samples.
Implemented binding validation of hierarchical path notation.
Fixed many bugs throughout the framework.
Lots of other random features and improvements…

I hope that if you are building WPF or Silverlight applications you will take some time to evaluate Caliburn and give me some feedback.

Devlicio.us

Asynchronous Execution, Animation and more in MVVM with Caliburn

Querying on Child Count With NHibernate

Is that a Property or a Method?

MVVM – Philosophy and Case Studies - Introduction

How to copy an entire folder tree with Nant

Upcoming Local UG Meetings

July 8th, Chicago ALT.NET

July 14th, WI.NET

What is a build script? Writing MsBuild Scripts - Part I

TeamCity Remote Runs / Personal Builds

Ignoring files/folders when committing to SVN repository

Code Contracts Primer – Part 5: Utilizing Object Invariants

Hangin the with guys from Thirsty Developer

The "Risk" of Open Source Software Support

A Craftsman sometimes has to create his own tool

Grooving with my new toy

Fluent Interface for NH Facility – Take 1

Two VANs on Castle Project

Just Be Honest and Tell the Truth

We Are Not Doing DDD – Part Two - CQS

What We Are Doing – Command Query Separation

Querying

Command

Benefits

One day with Balsamiq Mockups: a review

What does it do?

Should you buy it?

Little Things

VS Addin: Fast Add Reference Dialog - No more Coffee Break!

Code Contracts Primer – Part 4: Utilizing Pre & Post Conditions

Spotlight on JavaScript at the CNUG

Joining NHibernate Transaction with ADO SqlTransaction

Code Contracts Primer – Part 3: Providing Support for Unit Tests

Caliburn v1 Release Candidate

July 8^th, Chicago ALT.NET

July 14^th, WI.NET