FubuMVC Webinar - Compositional and Convention-based Web Development

I just gave a webinar yesterday for JP Boodhoo’s Develop With Passion® webinar series on Compositional and Convention-based Web Development with FubuMVC. The recorded session is now posted online with a slew of referenced and related links. I apologize for the sound quality and will make corrections if I get another chance to do another webinar/screencast. Here is the link to the recording:

http://webinars.developwithpassion.com/webinars/3

I didn’t mention this in the screencast but before we began switching our company’s production website to FubuMVC, we first devised a way to get the benefit of FubuMVC Behavior Chains while still on the ASP.NET MVC framework. Please feel free to read more about that successful venture at Bob Pace’s blog post on the MvcToFubu project.

View Full Article

FubuMVC Behavior Chains - The BMVC Pattern

For the last several months at work, we have been gradually migrating our production website to use the .NET open source FubuMVC web framework. Before committing to a whole new infrastructure for our site, some brilliant talent on our team decided to improve our experience on the ASP.NET MVC framework by integrating in one of FubuMVC’s most compelling features, behavior chains. Bob Pace originally blogged about the process in a two part blog post series (part 1 and part 2); since then, he has created a packaged solution called MvcToFubu which he just recently started another blog post series about.

Behavior chains are by far my favorite feature of FubuMVC. I believe they single-handedly revolutionized our use of the MVC pattern in a web environment. In fact, I like to think of it as a whole new pattern, the BMVC Pattern (I was told by a coworker that the ‘B’ should stand for “Better”, and while that’s true, I’ll stick with “Behaviors”). No, I’m not sincerely trying to coin yet another design or architectural pattern buzzword. However, I am most sincerely not joking when I say behavior chains add a whole new dimension to how I design web architectures. I find myself creating composable pipelines of cohesive, testable components in lieu of monolithic controllers and actions.

What are Behavior Chains?

Have you ever looked at your controller actions and thought “Man, there’s a lot going on here!” (validation, authorization, transactions, ORM setup, logging, caching, etc.)? If you haven’t, I urge you to take a conscious look at your controller actions and try to identify code that doesn’t directly relate to the purpose of the page (or sub-view of the page). Shouldn’t there be a way to move some of this secondary infrastructure code out of our controller actions and have it be applied conventionally to the correct actions/routes? Yes, and this is exactly what Behavior Chains are meant to accomplish, the ability to create composable pipelines of reusable behavior nodes for each route in your site.

Behavior chains can be built up in any order you want for each route via Conventions and Policies, which are extension points that allow you to inspect and modify the entire Behavior Graph that was built by FubuMVC during startup bootstrapping. The behavior graph is the modifiable collection of all behavior chains in the site, initially built with just a few default behavior nodes for each route. A typical behavior chain by default usually has an ActionCall node (representing the call to a controller action) and an Output node (often a tie-in to a view rendering engine, but can also be JSON or anything else). Other behavior nodes can be sprinkled into the pipeline in any order in front of or in between the ActionCall and the Output nodes. As mentioned before via the use of Conventions and Policies, it is common practice to filter your list of behavior chains using LINQ extension methods and then add a specific behavior node into the matching chains at a specific location in the chain. This truly elevates coding to conventions to a new level; some of the filtering criteria regarding controller actions that you may come up with could be as follows:

  • Action method names that contain a certain word.
  • Actions methods that are located in a particular controller or namespace.
  • Action method signatures that contain an input/output model that implements a specific interface.
  • Action method signatures that contain an input/output model that contains a property of a certain type or have a particular C# attribute applied to it.
  • So on, so forth…whatever you can dream up!

One more aspect of behavior chains that is important to point out is the logistics in how behavior nodes are chained together. The chains are not merely a linked-list of behavior nodes that are traversed linearly. Instead the makeup of the chains is better conceptualized to be an outer behavior node wrapping around an inner behavior node, which is then itself an outer node wrapped around another inner node, and so on. In fact, the FubuMVC developers like to refer to this chaining architecture as the Onion Layer Model or the Russian Doll Model (conjuring up a mental image of the nesting Russian doll toy called a matryoshka doll or a babushka doll). When an outer behavior node has finished executing it’s logic, it can then optionally execute it’s inner behavior node logic (or stop the behavior chain entirely in order to return early with a response, an error, or even transfer to a different route and behavior chain). One of the key advantages that this wrapping architecture can afford is the ability for an outer behavior to run additional logic or clean up code after all inner behavior nodes have completed (i.e., transactions can be committed, connections can be closed, sessions can be disposed, etc.).

How does this change the way I code my controllers?

I find that my controller actions are much thinner and more focused on the base case and the successful code path. All the exceptional code paths and edge cases have been identified and deal with by the other behavior nodes in the chain, prior to my action call being invoked. My action call can now focus on the essential logic that differentiate this route from others. That essential logic doesn’t get lost anymore in the necessary infrastructure code that should be a secondary concern. And all of this logic can be broken up into cohesive, reusable components within a flexible request/response pipeline that can be built up automatically by coding to whatever conventions you deem beneficial. Behavior chains really do add a whole new first-class citizen to the MVC design pattern. Do yourself a favor and check out the MvcToFubu solution mentioned at the top of this post, and bring some FubuMVC behavior chain goodness to your ASP.NET MVC website. I think you might be as impressed as we were and yearn for the other killer features of FubuMVC as well.

View Full Article

.NET Needs More Apprenticeships

It came to my attention recently that there are a few companies in other dev circles with all-star developers who give back to their communities by doing apprenticeship programs or open door programs at their workplaces. Basically the idea is to let people come into your workplace and pair program with them, sharing knowledge and best practices. I believe we need more of this sense of community going on in the .NET space. I’m sure I’ve probably overlooked something (or perhaps I’m about to spout off craziness and heresies), but it just seems like we should be able to work out the logistics to make this a reality.

The interesting thing is that this really isn’t a new concept in other professions. For example, the culinary world has had the idea of staging for quite a while. Sometimes it’s a final part of an interview process and other times it’s just to swap techniques and recipes. As mentioned above, I was recently informed of a few dev companies that have taken this idea to our profession. In the Rails community, Hashrocket has an apprenticeship program where you can apply to be a part of their team for a week and soak in some of the awesome skills and techniques they possess. It appears they vet their candidates a bit to ensure they get the right kind of people coming in who are motivated and ready to learn, and also because the code being worked on is for real Hashrocket projects for their clients. In the Node.js space, Joyent has a program called Office Hours where devs can register for free in advance to bring in something to work on with a Joyent employee at end of work day and get their feedback & expert advice. They provide snacks, drinks, and a comfortable work environment.

I think these ideas are brilliant and foster real community among developers. Although this idea alone can improve the interview and hiring process, I think it can go further than that to help our profession mature in the sharing of best practices and proven techniques. For most .NET companies out there, I’m willing to bet there are few legitimate roadblocks that would prevent instituting programs like these. Being completely honest with yourself, how much of what you work on each day is top secret intellectual property that is core to the success of your company and absolutely cannot be seen by outsiders? Even if there are parts of your code that should not be seen by strangers, I’m sure there are projects and tasks to be done on the other parts of code that will still prove instructive for your invited guests. I encourage our dev community to do whatever it takes to make this happen: have the visitors sign non-disclosure agreements, interview and re-interview potential candidates to meet satisfactory requirements, don’t allow them to hook up thumb drives to your machine and steal your secrets, whatever! It doesn’t matter if it’s a week-long thing or a few hours; let’s realize we’re all in this together and build this community up to have a higher standard of software craftsmanship.

View Full Article

Develop with Passion bootcamp course - Denver 2011

A very talented coworker and I recently went to JP Boodhoo’s Develop with Passion bootcamp training course (previously known as Nothin but .NET). I had originally heard of the course from Dave Tchepak who attended the course nearly two years ago. This blog post is a wrap-up of my thoughts and feelings about the course itself, JP Boodhoo as the instructor & experienced craftsman, and the .NET development community in general.

My prior impressions of the course from what I had read was that I would be in awe of JP's coding and design skills and very overwhelmed with the feeling that I didn't really know how to code; also that I would get no sleep at all that week, going from early morning to past midnight every day. I had also heard from a previous course member (off the record) that JP’s organization and direction with course material was a bit disorganized back then (luckily this has changed significantly since he had taken the course). I was really excited to see some good BDD in action, get my TDD passion ignited again (I had actually mentioned on twitter recently that my motivation for test was waning as of late), and see JP's mad Vim skills (since I have gotten into that the last few months).

Overall, I was pleasantly surprised with the fulfillment of most of my positive expectations and initial impressions going into the course. JP's personality and passion are infectious, and his teaching skills are pretty top-notch. The course material was well-structured and there was a clear direction for what we hoped to cover throughout the week (and yet, he was still flexible enough to be able to briefly entertain an off-topic direction the students wanted to take the course). He stayed true to the advertised 9am-9pm every day no matter what. He said that when he did the late nighters with previous courses, people came back the next day with little sleep and trashed as far as coding & learning capabilities go.

Watching him code so efficiently is quite a treat. He automates anything he does more than once so that a particular task doesn’t ever get in his way and hold him back the next time. His AutoHotkey scripts and automation tools that he has put together are absolutely incredible. He briefly touched the mouse two times the entire week, and it only for when one of his programs or Windows VM was wigging out. Screens and dialogs flew by so fast, you could tell he wasn't going to let any UI (even Visual Studio) get in the way of his productivity to code. He mentioned he will be open sourcing some of his scripts that he uses to keep his development environment consistent across OS platforms. Definitely cool stuff.

As far as JP's actual coding/design skills, I am absolutely floored. He certainly understands C# and .NET well. But it's his Object-Oriented design skills that blew us away. I've realized I don't really know OO design. I think too mechanically about the implementation of the solution instead of focusing on breaking down the problem into smaller manageable chunks. His TDD skills (both Top Down Design and Test Driven Development) are amazing. I've never been a fan of the TDD samples and intros I've seen (where the instructors do the absolute dumbest thing to make the test pass; JP admitted that style didn’t jive with him either). I've always thought that Behavior Driven Development and Top-Down Design were the way to go if I were to have tests drive my designs (or have tests at all for that matter; I'm still having trouble finding enthusiasm for tests written after development for modules and units). So it was great to see a master at that particular craft. It made me excited to use tests as a tool to guide my OO design, behavior discovery, and problem solving.

Some of you may recall that I had previously investigated BDD, Machine.Specifications, and Top-Down Design a year and a half ago doing the Anagram Code Kata. I think I can recognize better design and responsibility break-up and assignment nowadays. I likely will blog on these subjects again this year with new & improved passion and knowledge.

There was one sad takeaway for me personally from the course, which was a sense of disappointment in the .NET development community in general. Giving myself some time since the course to really think it through, I’m realizing I’m probably being too tough on our community, as I know each Dev community out there suffers from it’s own set of problems. But I don’t want to excuse our shortcomings either; rather, I would like to point them out so that we can focus on them and root those weaknesses out. I think our community in specific is unique in that there is a big shot company that dictates the direction our community should take, sometimes taking credit for all the innovation. Things are improving lately no doubt; it appears Microsoft is listening more and more and trying to let outsiders get involved and contribute.

But we as .NET devs need to step up and take matters into our own hands, we need to take better control of the code we write and encourage best practices within the realms of our responsibilities and influence. I believe many .NET shops rely on the tools sent down from above so heavily that we don’t really solve problems anymore. JP’s focus on problem solving and code katas from the course attack this deficiency at its core. I do somewhat blame our university Computer Science programs for not teaching real OO (a great discussion on formalism versus hermeneutics in a book I highly recommend, Object Thinking), but at some point we have to take what we were given and no matter our current standing, focus on sharpening our skills through practice and continuous learning. It boils down to individual responsibility for our current skill set and progression as a software craftsman. JP’s course does a terrific job of waking you up to that realization and inspiring you to be a better professional at your craft.

I have a few takeaways from the course that I’ll publicly spell out now. First, I (and hopefully our whole team) need to better understand design patterns and have them become integral to our code discussions. JP was all about efficiency in keystrokes and related dev tasks, and it seems natural that our language and code discussions could benefit from more efficient communication using design pattern terminology to convey a lot about a specific design concept in only a few words. Second, I hope that I (and our team again) can really put our tests to work for us, helping us recognize the problem to be solved or the behavior that needs to be captured, and then guiding us toward a simple solution. The third takeaway is related to that last part, and that is to have simple solutions that are distributed across simple object implementations (focusing on behaviors) that adhere to SOLID principles. It appears the key is to not focus on implementation specifics until the very last responsible moment; if done right, the implementations to create should be so clear cut and trivial, almost spelled right out in the tests themselves. It’s hard to put into words, but it seems crucial to focus first on the collaborators needed while designing code at the higher levels, finding ways to offload as much responsibility as possible (at least that’s what it felt like) onto dependencies that have yet to be designed and implemented. Designing Top-Down in this way gave such simple and elegant solutions that were totally extensible and adhered to the Open/Closed Principle better than any other code I have ever seen before. Perhaps as I blog more about this, I’ll be able to better put this style of coding into words (especially as I try to better understand it myself; it all seems so magical still!).

Overall, a great course that I highly recommend to all. JP has mentioned doing a similar course in Ruby, which I personally find especially interesting, given the same design/coding techniques would seem to run against a lot less friction compared to the heavy reliance on interfaces and mocking that C# require.

Stay tuned as I try to put some of this stuff into practice!

View Full Article

LINQ Query Syntax and Type Argument Inference

In LINQ, you can query in-memory data collections using Method Syntax (the IEnumerable extension methods) or Query Syntax (the SQL-like, declarative syntactic sugar on top of the underlying method calls).  I was using the query syntax to join a few in-memory collections and then project (like a SQL SELECT) the denormalized data into a new object that only contained a few pieces of information from each of the separate data collections.  The code could look similar to this (we'll go with a shopping example in honor of the upcoming holiday season):

var shoppingLists =
    from person in people
    join wishlist in wishlists on person.Id equals wishlist.personId
    join store in stores on store.Id equals wishlist.storeId
    select new
    {
        PersonName = person.Name,
        StoreName = store.Name,
        NumItems = wishlist.Items.Count
    };

However, I ran into the following intellisense red squiggly error in the Visual Studio C# code editor on the second join statement:

The type arguments for method 'IEnumerable<TResult> System.Linq.Enumerable.Join<TOuter,TInner,TKey,TResult>(this IEnumerable<TOuter>, IEnumerable<TInner>, Func<TOuter,TKey>, Func<TInner,TKey>, Func<TOuter,TInner,TResult>)' cannot be inferred from the query.

The error might also end with a statement that says "Try specifiying the type arguments explicitly."

Let’s Take a Closer Look…

The underlying problem is best understood by examining the method signature of the LINQ Join extension method and how the LINQ query syntax for the keyword join maps to that method call in the compiler.  The type signature for the extension method is as follows:

public static IEnumerable<TResult> Join<TOuter,TInner,TKey,TResult>(
    this IEnumerable<TOuter> outer,
    IEnumerable<TInner> inner,
    Func<TOuter,TKey> outerKeySelector,
    Func<TInner,TKey> innerKeySelector,
    Func<TOuter,TInner,TResult> resultSelector)

Consistent with all extension methods, it is public static and has a this keyword in front of the first method parameter, allowing you to call the Join method as if it had been declared in the original definition of the IEnumerable<> class or one of its inheriting children classes.

The first two parameters are the two data collections being joined, and in the case of my LINQ query above, they would be the joined collection of people & wishlists and then the stores collection, respectively.

The next two method parameters take delegates or lambda expressions that select the key value from each collection participating in the join, outer collection key selector first and then the inner key selector second.  The key values of each item in each collection will compared to each other for equality.  It will use the normal definition of the Equals method for your object type (or if you specified a custom one in your class definition), or there is another Join extension method signature that takes in another method parameter that an object that conforms to the IEqualityComparer<TKey> interface.  The key selectors from our LINQ query sample would be the two member access expressions in the "on store.Id equals wishlist.storeId" statement.

The last parameter is a delegate or lambda expression that takes in a item from each participating data collection and projects the items into a new form (like the Select LINQ query method and its SQL equivalent).  The two items being passed into the Func have passed the equality comparison of each item’s key value, exactly the same as how rows from two tables match up in an inner join statement in SQL.

As for the generic type parameters in this extension method definition, TOuter and TInner are the types from the two collections participating in the join.  TKey is the type returned by the key selectors; notice that in order to compare the equality of each key selected, they need to be of the same type.  In our example, TKey is likely int or long (or maybe Guid) since we’re dealing with Id properties of all of our objects.  TResult is the type returned by the projection Func<TOuter,TInner,TResult> resultSelector; in our case, we returned an anonymous type consisting of three properties (PersonName, StoreName, and NumItems).

Ok, So Where Did I Screw Up Then?

To answer this, let’s take a look one more time at my LINQ query syntax, how it would map to LINQ method syntax, and the Join method signature again all side-by-side:

var shoppingLists =
    from person in people
    join wishlist in wishlists on person.Id equals wishlist.personId
    join store in stores on store.Id equals wishlist.storeId
    select new
    {
        PersonName = person.Name,
        StoreName = store.Name,
        NumItems = wishlist.Items.Count
    };

// Equivalent LINQ method syntax
var shoppingLists2 = people
    .Join(wishlists,
        person => person.Id,
        wishlist => wishlist.personId,
        (person, wishlist) => new { person, wishlist })
    .Join(stores,
        store => store.Id,
        something => something.wishlist.storeId,
        (obj, store) => new
        {
            PersonName = obj.person.Name,
            StoreName = store.Name,
            NumItems = obj.wishlist.Items.Count
        });

public static IEnumerable<TResult> Join<TOuter,TInner,TKey,TResult>(
    this IEnumerable<TOuter> outer,
    IEnumerable<TInner> inner,
    Func<TOuter,TKey> outerKeySelector,
    Func<TInner,TKey> innerKeySelector,
    Func<TOuter,TInner,TResult> resultSelector)

The issue is lines 19 and 20 above; they need to be switched.  The compiler can’t properly infer the generic type parameters because we have our key selectors out of order in the argument list when invoking the Join method.  If you wanted to be explicit about your generic type parameters assignments, then Join<TOuter, TInner, TKey, TResult> would be Join<Temp1, Store, int, Temp2>, where Temp1 and Temp2 represent the magical type definitions that the compiler creates underneath the covers when you use anonymous types in your C# code.  Notice the outerKeySelector needs to come before the innerKeySelector.  It appears the "on store.Id equals wishlist.storeId" syntax is not a commutative operation.

One last thing, I just realized that the error(s) given in Visual Studio when you actually compile the code are different than the intellisense red squiggly error message.  It appears an actual build of the code is able to be a little more omniscient than the quick compile that intellisense does as you type.  The error (and intelligent suggestion) the compiler offers says something like this:

The name 'store' is not in scope on the left side of 'equals'.  Consider swapping the expressions on either side of 'equals'.

Additional Info

While reading the MSDN article on the LINQ Join method, I thought the "Remarks" section has some really great stuff about deferred execution, default equality comparison, differences from SelectMany, sort order perseverance, and so on:

This method is implemented by using deferred execution. The immediate return value is an object that stores all the information that is required to perform the action. The query represented by this method is not executed until the object is enumerated either by calling its GetEnumerator method directly or by using foreach in Visual C# or For Each in Visual Basic.

The default equality comparer, Default, is used to hash and compare keys.

A join refers to the operation of correlating the elements of two sources of information based on a common key. Join brings the two information sources and the keys by which they are matched together in one method call. This differs from the use of SelectMany, which requires more than one method call to perform the same operation.

Join preserves the order of the elements of outer, and for each of these elements, the order of the matching elements of inner.

In query expression syntax, a join (Visual C#) or Join (Visual Basic) clause translates to an invocation of Join.

In relational database terms, the Join method implements an inner equijoin. 'Inner' means that only elements that have a match in the other sequence are included in the results. An 'equijoin' is a join in which the keys are compared for equality. A left outer join operation has no dedicated standard query operator, but can be performed by using the GroupJoin method. See Join Operations.

Thanks, I hope this proves helpful to someone, as it was certainly eye-opening to me.

View Full Article

Maybe Monad Extensions

I learned a lot from my last foray into implementing my own Maybe Monad.  Apparently, it got noticed by and was actually useful to Derick Bailey, as it was one of the resources he used in his own personal exploration into Monads.  Of course, Derick did the topic a bit more justice, as he has a propensity to do.

Nonetheless, I have done as I said I would and reworked my Murray Monads into a cleaner, more concise implementation using extension methods, much like the implementation I introduced from Dmitri Nesteruk in the last post.  So without further ado, I’d like to introduce you to the MaybeMonadExtensions.

Monads 2.0 - “These Go To Eleven”

If you want to get an introduction to what Monads are and how I got to where I am today with this little library, then you really should check out the previous post on this topic.  I will however give a few brief code samples to show you what it can do to tidy up all those null checks using the Maybe Monad.

Here is code we tend to write all the time:

string postCode;
if (person != null)
{
  if (HasMedicalRecord(person) && person.Address != null)
  {
    CheckAddress(person.Address);
    if (person.Address.PostCode != null)
      postCode = person.Address.PostCode.ToString();
    else
      postCode = "UNKNOWN";
  }
}

It can look like this with some Maybe Monad love:

string postalCode = person.If(HasMedicalRecord)
  .Access(p => p.Address)
  .Apply(CheckAddress)
  .Access(a => a.PostCode)
  .Convert(pc => pc.ToString(), "UNKNOWN");

I know!  Groovy, huh?!

The source can be found here:  http://bitbucket.org/murrayondotnet/maybemonadextensions/

Let me know if you put this to good use!

View Full Article

Maybe from Murray Monads

Off and on for the last six months, I have probably seen and read at least a half dozen introductions and tutorials on monads, a functional programming construct based on the mathematical monads from category theory.  Monads are known for their headache-inducing explanations, and I’ve had my fair share.  Every tutorial I’ve committed time to mentions the endless possibilities of using such constructs to improve your code, but I’ve had a hard time finding real-world examples of using this stuff out in the wild (much like this Stack Overflow poster, whose link I only found just now).  It has recently become a quest of mine to find some C# code we all write that could be improved by a monad.

I am now going to attempt to introduce a Maybe monad that I cooked up, but I warn you that I have no idea what I’m doing or if I’m staying within the rules for what makes a monad by definition a monad.  Don’t worry though, you have nothing to lose; I’m the only one taking a risk at looking foolish, and it’s all at the expense of my reputation and not yours.  Should be fun!

“It is not the spoon that bends, it is only yourself”

From the Wikipedia article linked to above:

“In functional programming, a monad is a kind of abstract data type constructor used to represent computations (instead of data in the domain model). Monads allow the programmer to chain actions together to build a pipeline, in which each action is decorated with additional processing rules provided by the monad. Programs written in functional style can make use of monads to structure procedures that include sequenced operations, or to define arbitrary control flows (like handling concurrency, continuations, or exceptions).

“A programmer will compose monadic functions to define a data-processing pipeline. The monad acts as a framework, as it's a reusable behavior that decides the order in which the specific monadic functions in the pipeline are called, and manages all the undercover work required by the computation.”

The promised tenets of monads are increased code readability and algorithm composability, an example of preferring declarative code over imperative, procedural code.  In the case of the Maybe monad, it is a wrapper around types that might have an invalid state like null or nothing.  The lure of the Maybe monad is the ability to deal with values that might be in this invalid state without having to explicitly check for null before continuing or exceptions being thrown in your algorithms.

I first found a post by Rinat Abdullin where he introduced his version of a C# Maybe monad.  I downloaded the library and attempted to figure out how to use it in code I could possibly write any given day.  I tried mimicking the HttpContext.Request.Params collection commonly used in ASP.NET pages and HTTP handlers to retrieve the passed in query string or post values on the Request object.  If you ask that collection for a parameter that was not passed in on the request, it returns a null instead of the string value.  Common practice is to then use a bunch of if statements and key off the fact that certain query string or post parameters may or may not exist.

The problem I ran into with Rinat’s implemenation is that I wrote the code using the monad how I thought it should help me, and then ran into compiler errors and runtime exceptions because of the expectation that Maybe objects couldn’t be constructed around null values.  Here is the twitter conversation I had with Rinat in regard to this misconception that I had:

murrayondotnet's avatar
murrayondotnet says:
@abdullin Can you make your MaybeMonad in Lokad lib accept null at construct or explicit/implicit cast? Maybe<SomeType> monad = varThatsNull
abdullin's avatar
abdullin says:
@murrayondotnet No, this would violate the idea of MaybeMonad (as in Lokad libs). But you can copy code and tweak it to your needs locally.
murrayondotnet's avatar
murrayondotnet says:
@abdullin Figured this was case; what does it violate? I'm still new to monads. Thought one would be able construct monad around maybe null
abdullin's avatar
abdullin says:
@murrayondotnet check out the article on Maybe monads in Lokad libs: http://bit.ly/1GJlNN
murrayondotnet's avatar
murrayondotnet says:
@abdullin Thanks for the link, thats actually how I found your lib. I didnt see where you say why cant construct maybe monad on null. Help?
abdullin's avatar
abdullin says:
@murrayondotnet in essence monad in Lokad guarantees: there will be no nulls around (hence no need to check for them), it replaces null.
murrayondotnet's avatar
murrayondotnet says:
@abdullin I may try to create my own implementation that hides whether null or not. If so probably base mine off of the nice things in yours

And so I did.

Introducing MurrayMonads

I don’t even like the name.  I’m also not sure this code will ever be used again…by anyone, let alone me (especially since I like some other guy’s implementation better; read on to watch me embarrass myself).  But whatever, Visual Studio asks for a project/solution name and so there it is.  I need some cool theme like Rhino, as used by Ayende.

Speaking of Oren (I will use his proper name instead so that he doesn’t get stuck at the airport unable to board his flight), he posted a link on Twitter to an article where Dmitri Nesteruk created his own version of the Maybe monad, just as I was starting my experiment.  He used extension methods instead of an explicit monad object wrapper in order to enable the pipelining composability that you can also do with Rinat’s implementation.  Really clever, but there was one small thing that bothered me a bit, and that is how the monad chaining begins with Dmitri’s API.  (Actually, I’ll prove I’m wrong by the end of the post; this is the cause of upcoming embarrassment mentioned above, hooray!)  Because of this, I decided to use his example problem as the basis for my sample that I will show, in order to increase comparability.

So I set off to try and merge the good points of both Rinat’s and Dmitri’s implementations.  I have put my source code up for viewing at Bitbucket.org:  http://bitbucket.org/murrayondotnet/murraymonads

Are We There Yet?!

Yes, we are.  Let’s see some code finally.

Here is the code we don’t like writing all the time:

string postCode;
if (person != null)
{
  if (HasMedicalRecord(person) && person.Address != null)
  {
    CheckAddress(person.Address);
    if (person.Address.PostCode != null)
      postCode = person.Address.PostCode.ToString();
    else
      postCode = "UNKNOWN";
  }
}

This is actually code that you wrote; I took it just yesterday from your current project at work.  I know you’re feeling a bit defensive because of this, but I’m here to help so put down the attitude please.  We’re gonna make your life easier…I hope…

All in all, it’s code you see every day and there’s not much really wrong with it per se.  I just think it could be cleaner I suppose.  So using Dmitri’s extension methods, you can get that logic down to this:

string postCode = this.With(x => person)
  .If(x => HasMedicalRecord(x))
  .With(x => x.Address)
  .Do(x => CheckAddress(x))
  .With(x => x.PostCode)
  .Return(x => x.ToString(), "UNKNOWN");

As long as that last ToString method call doesn’t return a null (which one of my use cases does in the TestConsoleApp included in my source code), you will either get the value or “UNKNOWN”.  Looking good!

So my version of the Maybe monad comes out pretty close to this last one:

string postCode = person.If(p => HasMedicalRecord(p))
  .Access(p => p.Address)
  .Apply(a => CheckAddress(a))
  .Access(a => a.PostCode)
  .Convert(pc => pc.ToString(), "UNKNOWN");

// or even
string postalCode = person.If(HasMedicalRecord)
  .Access(p => p.Address)
  .Apply(CheckAddress)
  .Access(a => a.PostCode)
  .Convert(pc => pc.ToString(), "UNKNOWN");

The difference between Dmitri’s and mine being how the chain is first started, on the Maybe person object instead of Dmitri’s use of the this keyword.

Here’s what you’ve been really waiting for where I eat my own words.  Dmitri’s code can also be written like this:

string postCode = person.If(HasMedicalRecord)
  .With(x => x.Address)
  .Do(CheckAddress)
  .With(x => x.PostCode)
  .Return(x => x.ToString(), "UNKNOWN");

…which appears to take away any advantage of my library.  I officially like his solution better, I just don’t like some of the method names.  So perhaps I will create another blog post and Bitbucket repo with a new library of extension methods instead.  I will leave up this mess-of-a-post public (as well as the source code) so that perhaps others can see the process I went through and learn from my mistakes.

Your Turn to Criticize Now

Let me have it.  Let me know how crazy I am or if this is even useful.  Let me know if I’m completely misusing the monad principles.  Or, by some weird miracle, let me know if I’m on to something.  Actually, if Dmitri is on to something.  Either way, I want to hear from you.  Thanks.

Additional Monad Learning Resources

View Full Article

F# Pipeline Operator in C#?

I am currently reading the Real-World Functional Programming book from Manning Publications. It’s mostly an exercise in learning F#, but also to improve my C# code as well. I finally learned what the F# pipelining operator (|>) is all about, and I was so impressed I thought I would try to figure out how to bring it into C# if possible.

Introducing the F# Pipeline Operator

Here is some F# code that defines a list of integers and a pair of functions.  They are then used in a few “higher-order” functions (functions that utilize other functions as parameters or return values, according to my book).  List.filter is equivalent to the LINQ IEnumerable.Where() extension method, and List.map is equivalent to IEnumerable.Select().

let numbers = [ 1 .. 10 ]
let isOdd(n) = n % 2 = 1
let square(n) = n * n

List.filter isOdd numbers
List.map square (List.filter isOdd numbers)

The interesting part is the last line of code, where it is argued that you lose a little bit of code readability because the function that is actually executed first (List.filter) is found second in the expression statement.  Enter the F# pipelining operator:

let squared =
  numbers
  |> List.filter isOdd
  |> List.map square

Even though we’re no longer a compact, one-liner expression, I think we’ve gained some code readability.  It says to take the list numbers and perform the following manipulations in the exact order listed.  Cool stuff, if I say so myself.

“There is No Charge for Awesomeness…or Attractiveness”

(Sorry, I’ve been watching the movie Kung Fu Panda a lot with my kids lately.  Funny stuff.)  So can this awesomeness be brought over into C#?  I opened up Visual Studio and tried to see if I could figure out how to define my own operator or reuse one of the existing ones.

I realize C# is a pretty tough language to flip keywords and operators around and invent new syntax with (ok, it’s impossible), but I tried anyway.  The type of code readability issue I wanted to remedy is the same as with the F# code snippet above.  I thought it would be nice to make C# code like the following statement more readable and digestible (especially the execution order):

Convert.ToInt32(Context.Request[“requestParam”].Trim());

As I started to (unsuccessfully) beat out some pretty rough code, I ran into problems with trying to make extension methods that are operator definition overloads and errors saying “One of the parameters of a binary operator must be the containing type.”  It just wasn’t working and then I began to realize that C# already has a pipelining syntax, even if only in one small subset of the .NET API.  You can find a decent pipelining syntax with the Fluent Interface used for the LINQ extension methods.  Its power is in the fact that the functions return the object type that was passed in and acted upon, so that more functions can be chained on afterward in a composable manner.  The ability to do things like collection.Where().Select().OrderBy() is a much more declarative and functional solution to imperative for loops (and it makes it more readable and intention revealing in my opinion).  It’s a difference in describing more what you want to be accomplished rather than how it is to be accomplished (especially when the how in programming languages is more readable to a computer than it is a human).

So the good news is that you indeed can have a nice pipelining syntax in C#, especially for APIs that are designed with Fluent Interfaces like LINQ.  However, it doesn’t solve code readability issues with code snippets like the C# fragment I showed above.  For those regular, non-fluent method calls in the rest of the .NET API, you must use old-fashioned Object-Oriented Programming practices of breaking code up into meaningful, atomic units of statements and naming and encapsulating functions cohesively in order to get more readable code.

View Full Article

Reactive Framework Finally Explained

I have been intrigued by the Reactive Extensions for .NET (Rx Framework) for quite a while now, especially the fundamental shift from a “push” data model as opposed to the “pull” model most familiar to us.  I have thought to myself that this must be a game changer in how data and events are consumed in every-day software.  I didn’t quite understand how it all works or how to use it from the few samples I had seen, but I knew if I gave myself a little time to really sit down and look at it, my life would be changed forever.

However, after reading some articles, watching some recorded presentations, and even attending a MIX ‘10 session in-person on the Reactive Extensions, I felt increasingly lost and confused by what this framework could offer me.  I wasn’t understanding some fundamental ideology of the framework and it was jading my learning experience when watching/reading sample code.  Well, I think I have finally figured out what the mental roadblock was and will attempt to explain the framework here as I best as I understand it, in hopes that it can be of help to others not getting what the fuss is all about.  I can sense that I’m not the only one who has been turned off by the unsuccessful attempts by Microsoft to explain this revolutionary framework to the average developer.  Apparently those who had a hand in designing the framework are just so incredibly intelligent that they are having a hard time discerning that the common man is not immediately getting it.

IEnumerable<T>, Meet IObservable<T>

Essentially what Microsoft did is create a mathematical dual of the IEnumerable and IEnumerator interfaces using Category Theory, and named them IObservable and IObserver respectively.  In its bare simplicity, this is done by merely reversing the direction of your arrows in your mathematical functions and compositions.  The following images of a few slides from Erik Meijer’s MIX ‘10 Session that were the best visual explanation I have seen:

Duality Example with De Morgan’s Laws

rxSlide2

Creating a Dual of IEnumerable

rxSlide3

Creating a Dual of IEnumerator

rxSlide4 

The reason the mathematical proof part is significant is because we can guarantee that LINQ syntax and operators will work on these new collection and data subscriber interfaces, just like they did with IEnumerable collections in LINQ-to-Objects.  This new LINQ provider is commonly called “LINQ over Events.”

Reacting to Data is Asynchronous

This is actually where I think some of the confusion came in for me.  Mostly what I didn’t understand is how you can write LINQ queries into pushed data (already sent and also yet to be sent), when essentially that task is indeterminate by nature.  What I have figured out is that the LINQ syntax is not entirely for the data being pushed, but also used for molding the subscriptions themselves.  What the LINQ syntax provides you is a way to compose, filter, project, aggregate, and throttle data and event subscriptions in a powerful, declarative way.

A common workflow seems to be to create one or more observable collections (and there are many ways to do so) and then customize and compose a subscription based on the subscription(s) using LINQ syntax.  All that’s left then is to set the subscription in motion, giving it some sort of callback or lambda expression to be called as data is asynchronously pushed in and processed.

Here is a very simple code example that illustrates this process quite plainly:

using System;
using System.Linq;

namespace TestRX
{
    public class Program
    {
        public static void Main(string[] args)
        {
            var oneNumberPerSecond = Observable.Interval(TimeSpan.FromSeconds(1));

            var numbersTimesTwo = from n in oneNumberPerSecond
                                  select n * 2;

            Console.WriteLine("Numbers * 2:");

            numbersTimesTwo.Subscribe(num =>
            {
                Console.WriteLine(num);
            });

            Console.ReadKey();
        }
    }
}

It is interesting to watch the code run and think about what it’s actually doing.  It sits on the Console.ReadKey() line while the observable collection is asynchronously pushing data to the lambda expression containing the Console.WriteLine() statement.

It looks like the Reactive Framework is not just a better way to handle events and pushed data, but it also appears from what I’ve read that it could be used as a nicer API for sending off asynchronous process threads.

Additional Reading

Microsoft DevLabs has created the Reactive Extensions for .NET (and it’s associated languages), but it has also came up with the Reactive Extensions for Silverlight and JavaScript (can be found on same webpage).  This proves very interesting as JavaScript (and Silverlight) tends to be quite event driven because of its close interactions to UI elements in HTML (or XAML).  In fact, one of the most encouraging example use cases that I’ve heard was that of having some HTML text field that you wanted to auto-search as the user types, but not until the user pauses for a second; they can also hit Enter.  What the Reactive Framework could provide you is a way to aggregate more than one event source (alphabetic and Enter key strokes and the timer) into a single event handler using clear, declarative framework statements.

Here are other links I would recommend for additional examples and explanation:

Enjoy!  Let me know via comments if you start using it for something real cool and useful.

View Full Article

Parallel.For Loops in .NET 4

I was having fun working on the Toughest Developer Puzzle Ever 2 when I came across a problem that asked for the coordinates into a grid of numbers of the upper left corner for a 4x4 sub-grid with a magic sum of 34, meaning all rows, columns, and the 2 diagonals all sum up to 34.  Instead of trying to figure it out manually, I probably did what many programmers would do and wrote a quick and dirty program to accomplish the task for me.

I didn’t try to use any optimized search algorithm or anything, as I knew that the problem space was very small and specific and that computers are really fast.  So I figured I would just write a brute-force iterate through every row and column type of an algorithm (in Big O notation being O(mn) or just O(n2) if the original grid is square), knowing it would return in milliseconds.

I quickly realized that each iteration was not dependent any previous iteration for its calculations, so I decided it might be a good time to try out the new Parallel.For loops in the .NET 4 Framework that would multi-thread the iterations of the loops.  Here’s the implementation I threw together:

using System;
using System.Linq;
using System.Threading.Tasks;

namespace Find34Grid
{
    public class Program
    {
        private static readonly int[][] Grid = new []
        {
            new [] {16,3,2,13,15,10,3,6,41,15,14,4,12,8,7,1,12},
            new [] {5,10,22,8,4,5,16,7,9,7,6,12,5,11,10,8,5},
            new [] {9,6,7,12,14,11,2,13,16,3,2,13,15,10,3,6,5},
            new [] {41,15,14,4,12,8,7,2,5,10,11,8,4,5,16,9,15},
            new [] {16,3,2,13,15,10,3,6,15,10,16,2,3,13,16,2,3},
            new [] {5,10,11,8,4,5,16,9,4,5,5,11,10,8,5,11,10},
            new [] {9,6,7,12,14,11,2,13,14,11,9,7,6,12,9,7,6},
            new [] {41,15,14,4,12,8,7,1,12,8,4,14,15,1,14,15,1},
            new [] {9,7,6,12,5,11,10,8,5,11,10,3,6,41,15,14,4},
            new [] {4,14,15,1,9,7,6,12,9,7,5,16,9,9,7,6,12},
            new [] {12,8,13,13,4,14,15,1,4,14,11,2,13,16,3,2,13}
        };

        private const int MagicSum = 34;

        public static void Main(string[] args)
        {
            Parallel.For(0, Grid.Length - 3, i =>
            {
                Parallel.For(0, Grid[i].Length - 3, j =>
                {
                    int[] sums = new []
                    {
                        Grid[i].Skip(j).Take(4).Sum(), // Row 1
                        Grid[i+1].Skip(j).Take(4).Sum(), // Row 2
                        Grid[i+2].Skip(j).Take(4).Sum(), // Row 3
                        Grid[i+3].Skip(j).Take(4).Sum(), // Row 4
                        new [] { Grid[i][j], Grid[i+1][j], Grid[i+2][j], Grid[i+3][j]}.Sum(), // Column 1
                        new [] { Grid[i][j+1], Grid[i+1][j+1], Grid[i+2][j+1], Grid[i+3][j+1]}.Sum(), // Column 2
                        new [] { Grid[i][j+2], Grid[i+1][j+2], Grid[i+2][j+2], Grid[i+3][j+2]}.Sum(), // Column 3
                        new [] { Grid[i][j+3], Grid[i+1][j+3], Grid[i+2][j+3], Grid[i+3][j+3]}.Sum(), // Column 4
                        new [] { Grid[i][j], Grid[i+1][j+1], Grid[i+2][j+2], Grid[i+3][j+3]}.Sum(), // Diagonal 1
                        new [] { Grid[i][j+3], Grid[i+1][j+2], Grid[i+2][j+1], Grid[i+3][j]}.Sum() // Diagonal 2
                    };

                    if (sums.All(x => x == MagicSum))
                    {
                        Console.WriteLine("y (row): {0}\nx (column): {1}", i, j);
                    }
                });
            });

            Console.ReadLine();
        }
    }
}

Nothing special and certainly did the job.  I didn’t really notice a performance improvement in anyway, but that was expected for such a small problem.  I don’t really expect a whole lot of feedback on such straightforward code, but if there is a cleaner or more efficient way to utilize Parallel.For or Parallel.ForEach, please don’t hesitate to let me know via commenting to this post.  Thanks!

View Full Article