Dependency Free POCO Controller With ASP.NET vNext

After peaking my interest that ASP.NET vNext can run on Linux and Mac via mono. I decided to spend a little time to see what else has changed.

One of my favorite aspects of working with FubuMVC was the POCO-style controllers that removed a lot of the cruft of framework and cross-cutting concerns out of your controllers.

Why are POCO controllers good?

It’s a fair question and the answer isn’t black and white. If I’m writing code that matches the standard way in which view location is wired up 90% of the time. I can probably lean on that a bit and reduce the repetition and noise inside my controller and make something that does this for me. However, just removing the base-class doesn’t quite get us to where we need to be to reduce this repetition. Ideally, we would also want to return a simple POCO model as well and have something later in the pipeline do the repetitive stuff for us. This would also have the added benefit of making tests easier to write because you wouldn’t ever have to wire up any framework goop to get things going.

Is this just another post on the same topic I’ve already seen?

This isn’t the first time someone has mentioned the ability to do this, so how is the fubu-style different? To my point earlier, injecting things like ViewDataDictionary and returning an IActionResult isn’t really reducing the framework friction. However, MVC now has an interface called IOutputFormatter that is there to support content negotiation. This is how fubu’s view engine worked under the covers. In the same way that you output serialized JSON when the accepts header uses “application/json”. You can also choose to render HTML when the accepts header is “text/html”.

Controllers the “fubu” way

I started with the yeoman generator template that gives you the almost standard ASP.NET MVC bootstrap start page. I mentioned I’m running on a Mac right? This approach will work with Windows and Visual Studio as well. I’ve adapted the yeoman generated application in my sample to look like the following.

Now if you browse to the home route you’ll likely see XML rendered to the screen instead of the view. Let’s fix that. First let’s setup something that can render a view for content negotiation.

Last we’ll wire up our new output formatter in Startup.cs

Now if you refresh the page you should see the same html output you started with, but without the repetition and framework code in your controller.

I’m interested to see if others find this approach useful. Would you find value in this? Or are you more happy to be explicit regardless of repetition?

Swimming Upstream or Up Shit Creek Without a Paddle

Golang is gaining a lot of momentum. I don’t think a day goes by without hearing that another company has switched from some other language or platform to go. In my last post I mentioned that we chose node even though we were pretty fond of go during our research. We felt the web development community in go specifically needed some maturity. The web development community seems like a bunch of isolated islands with 1 or 2 inhabitants all shouting to the world about how awesome their island is. I almost fell into the same trap myself as you can see. What I created was technically quite nice and performed better than anything else we found, but we would be swimming upstream for everything we needed. This is something we have already done in the past as most of us have been active maintainers and contributors of other OSS projects. However, we knew it would be a recipe for eventual burnout. Without just throwing in the towel I thought I would try and express my concerns and see if others feel the same way and whether or not there is merit to cleaning up the mess as a community and not just on a single isolated island.

One of the primary principles for us in any approach is that testing is easy, both unit testing as well as integration testing. We want the fastest feedback possible. You might be tempted to only do integration tests due to how fast things typically run. However, if an integration test fails it can sometimes be difficult to find out where the failure is. If a unit test can provide a tighter feedback loop then it has done its job.

Another principle we tend to lean on heavily is that you shouldn’t make runtime decisions for things you already know at startup. A small simple example below. The code shouldn’t have any condition at all for devMode. Instead there could be DevRecovery and LogOnlyRecovery. Why? I would say why have branching logic at runtime when we knew what to do while bootstrapping our application? I think you get the point.

  func (h *Recovery) ServeHTTP(rw http.ResponseWriter, req *http.Request, next http.Handler) {
            defer func() {
                    if err := recovery(); err != nil {
                            if (devMode) {
                              //render development time error page

            next(rw, req)

I’ll talk briefly about a few of the frameworks and approaches we tried out. My goal isn’t to bash any particular project or approach, but rather call out that yes we did see (insert framework here), and felt that they conflicted with our goals and all suffer from the same underlying problem.


Revel was one of the first frameworks we looked at and until we knew better, it had a built-in testing module to run tests in the browser. However, after spending some time with golang and realizing how good the default testing tools are the approach seemed confusing and unnecessary. In addition, it seemed that they were intended only for integration tests and not unit tests. We came across a discussion about changing filters / interceptors (revel’s middleware) to get simplified for the project maintainers. In summary, if you wanted middleware applied to a single route or action it required you to add conditional behavior based on the name of the function. This conflicted heavily with one of those principles I mentioned and at this point we were concerned about choosing revel for our project. This is probably a classic example of fitting your code into the mold of a framework, or to bolt on additional behavior through libraries in your own idiomatic way.


Martini also seemed promising initially. After getting into our comparisons though we noticed that it was significantly slower than all the other frameworks we were trying out. Upon seeing other criticisms and an acknowledgement from the author that martini was not idiomatic go we decided to move on. I think the authors response to the criticism was humble and demonstrated something that you don’t see too often in the go community. A willingness to listen to constructive criticism and really hear it. I feel though that the new project he created in response to the criticism took things from one end of the spectrum to the other. I think there’s likely still a middle ground somewhere that hasn’t been discovered yet, but I’m hopeful.

Idiomatic Go – Aka http.Handler

After spending quite a bit of time researching and writing some samples in various frameworks it dawned on me that maybe the go community was right. Maybe you can get anything done with just the standard http.Handler interface. We got a lot of traction and began to realize how nice this could be until we started to try and find existing middleware that we could use. I’m not going to say it’s impossible to find, but it’s pretty scarce. We would find one and get excited until we would realize it’s not compatible with the standard http.Handler interface. Or it would be specific to martini, or negroni, or insert project here.

Why on earth would middleware be taking on dependencies to a specific framework? This is a solved problem in most other communities, heck even Microsoft is getting this right with their latest changes. The problem in my opinion lies in the inflexibility of the http.Request object to facilitate some common use-cases. Take a given route that looks something like ‘customer/:customerId’. That’s easy it goes on req.RouteParameters, but wait it doesn’t exist. Or perhaps when middleware might need to pass information through to another piece of middleware or the handler. That’s easy too, use Gorilla context. Sorry, global state is nasty, not to mention that it encourages a ton of repeating yourself all over the place. The request object seems again like the most logical place to put this code. These are the main reasons that each framework needs it’s own Context struct and why every framework re-implements the same solutions over and over.

One of the best libraries in node in my opinion is passportjs. Sure for the simple basic authentication it might be overkill, but in my experience it’s never that simple. There are typically multiple authentication schemes and sometimes the need for SAML. Authentication and security in general is something you want additional eyes on. If you’ve ever gone through a security audit, you’ll agree that they’re not as easy as you might think. Why should everybody re-implement and go through the same learning experience? Why not move forward together?

Maybe that example is unfair given the age of the community? Okay, let’s take a few common cases. Logging, and panic recovery for example is reimplemented in every lib / framework I ran across. Why not come up with something slick that the whole community can use throughout? What about gzip compression? I don’t think I’ve ran across a comprehensive library for compression yet that didn’t take on a framework dependency, or didn’t have tests, or was an incomplete implementation. This project had the right idea, but without the entire community it’s a lost cause.

Golang has implicit interfaces and is a HUGE advantage to solving this problem, but unfortunately nobody is using them. I propose the community discuss what the standard contract be for all middleware and stick to it. Until the go web development community stops re-implementing the same ideas over and over with a slightly different take on the same problem it’s going to be all upstream or possibly worse.

We Chose… For Now

We are starting a rewrite of a project that has lived for close to 7 years. The original project was a desktop application for Windows using WPF. We feel pretty strong that desktop applications are not only harder to support, but also in the case of WPF it limits our ability to easily support anything but Windows. In the case of the current application we have turned away business that otherwise might have added significant value because of this.

You might have also realized that our company has heavily invested in FubuMVC over the last several years. However, when a “rewrite” was mentioned our CTO suggested doing a holistic evaluation of our current stack rather than starting with our typical one. This lead us to come up with a set of primary goals that we would be looking for in a new stack were we to make a switch. DISCLAIMER: These goals were important to us and we understand that opinions are subjective and depend on the context. Don’t use our opinions to shape your own. Instead I would recommend that you come up with your own goals and do a similar evaluation. Maybe you’ll find the opposite to be true.

  1. Testable – Testing in .NET, and specifically TDD in .NET often feels like an awkward second class citizen. We want TDD to feel as natural as possible. Ideally some sort of auto-test runner would help in that regard. In addition to unit tests though, integration tests are extremely important and should run in isolation from each other not dependent on any shared state or database.
  2. Fast feedback – One thing for sure that we have learned is that the tightest feedback loop keeps us the most productive. Auto-tests for the testing portion, but in the case of building the webpage(s) using something to auto-reload the page on file save would also be ideal. We should stay in our editor as much as possible and never need to lose focus on the task at hand.
  3. Simple editor – Many of us in the office are already VIM users and although many IDE’s have vim emulation it often just left us wishing for the real thing. For others, textmate, or Sublime Text shouldn’t be out of the question either. The big theme for us though is that it’s just text and we shouldn’t be waiting on our environment to begin typing.
  4. Good OSS community – This is commonly one of the largest complaints about .NET (although it’s improving) and we want to experience and participate in these communities we so often hear about. An additional criteria was that the community was growing and not shrinking (but still large) like the ruby community.
  5. Scalable – While this project specifically has a very fixed scale, the longer term possibilities of using on other projects is a strong liklihood if things go well.

With that set of criteria we spent some time researching what our options were with a few obvious contenders on the list. The primary contenders that we spent time with were Node, Scala, and Golang. Others that we gave less serious time, but still evaluated were F#, Erlang, Haskell, Rust, and Dart.


Scala from the outside seems to be growing in popularity with some big name companies on their list of adopters. This was a strong favorite going into the evaluation and to many of us seemed like it would win in the end. Several of our developers have taken both the Scala course and the course on reactive programming from Coursera. Upon completing those courses a couple of our folks began to build a project with the Play framework and Akka. The project itself was a dashboard for github statistics that were more organization and team specific rather than repository specific.

During the process of building something real there was a very real cost of learning vs. being productive. The two people we had working on this are two that are probably the most experienced and competant people we have. Despite their competancy the ratio of learning and understanding vs. doing was probably somewhere around 4 to 1. Some of this can be explained by the JVM being relatively new to us. However, complexity complaints is not a new thing for the Scala community. Before building something real I think the mindset was a bit of arrogance that sounds like “we laugh in the face of complexity, others are just not smart enough”. The complexity is real and one that even extremely experienced Scala developers have mentioned as well. Surprisingly some of the complaints in that rant that are “edge cases” that should be hidden away are things we ran into in the first week. How did it do against our goals though?

  1. Testable – This was honestly one of the most time consuming parts of our research. Although there is a rich set of testing tools. Techniques on how were often never mentioned, or required extensive time digging through the sources to find the implicit variables that would cause us to trip up. There’s plenty of people testing in Scala successfully sure, but it’s still something we considered lacking or at least not better than what we had in .NET.
  2. Fast feedback – Most of the time Scala compilation and feedback loop seemed as fast or faster than what we had experienced in .NET land. However, there were several times that we would see spikes in compilation time that would take as long as 18 seconds for a very small project.
  3. Simple editor – 1 person had success with this in VIM Scala workflow, but others felt it was more natural with IntelliJ.
  4. Good OSS community – There is a good community in Scala and a lot of really smart people solving complex problems. The statement is also made that you’re inheriting the Java community as well. However, in practice we found that consuming Java libs in Scala never quite felt right. Nice if it was necessary, but often we looked for Scala libs first and only if we couldn’t find a good one would we fall back to Java.
  5. Scalable – I don’t think there’s a lot of question on the scalability of Scala.

All in all Scala isn’t bad. It didn’t measure up too well against our goals though. When we were running the website with auto-reload and our auto-tests going the feedback loop averaged around 10 seconds. Not awful if only comparing against .NET, but as we’ll see in with Node and Golang it wasn’t in the same league anymore.


When we began this research Golang wasn’t even on our radar. However, with the popularity of docker, etc. it naturally brought some attention to golang and is why we added it to our list of things to evaluate.

Golang is ridiculously fast both for compilation and during runtime. The memory footprint is also very small compared to our .NET experience. Golang felt as fast as a dynamic language, but provided the compile time safety we were used to. Overall it felt very promising even though it had never been on our radar before. I spent two days learning the language and honestly felt extremely productive, but how did it measure up to our goals?

  1. Testable – The testing tools out of the box are awesome. Other communities need to pay attention because this was one of our favorite aspects about golang. Goconvey is what I used while learning the language, and flowed right into my workflow when I began spiking real work. In addition, the standard testing tools provide coverage and benchmarking capabilities which keeps the decisions on which tools to use dead simple.
  2. Fast feedback – Like I mentioned previously, golang is FAST. Nothing we tested compared to the speed of golang. When using auto-reload as changes were made I never saw any request go over 12ms and more typical I would see requests around 6ms. It was the first time I’ve really considered things in terms of microseconds.
  3. Simple editor – I initially started using Sublime Text 3 with golang and found it to stand up pretty well, but later switched back to vim due to some flakiness in some plugins that had been updated. I landed on the vim-go plugin and felt that it kept me very productive and had features I wouldn’t have expected in a text editor.
  4. Good OSS community – The community is gaining a lot of popularity and it seems that a day doesn’t go by without hearing about another company switching to golang. However, in our opinion the golang community, specifically for web development needs a bit of maturity.
  5. Scalable – It’s claimed that golang will be the language of the cloud for a reason. The speed alone buys you a lot in terms of scale, but in addition golang makes concurrency extremely simple and elegant.

While as you can tell from my tone that I was a big fan of golang. I couldn’t disagree with my colleagues that the web development community needed to mature a bit. Even though it wasn’t a primary goal, we didn’t want to do a ton of road paving. Before anybody goes on a rant and mentions revel, beego, martini, or “you don’t need anything more than HandlerFunc” we felt that each one of those frameworks or approaches came with drawbacks that conflicted with one or more of our goals. My next post will go into much more detail about how and where I think the golang web development community could improve because it’s not the point of this post and it deserves a lot of detail. In a somewhat unfair opinion though, I could summarize a lot of the community is full of individuals writing “frameworks, non-frameworks” and shouting at the world “look how awesome this is” and reinventing the same wheel all over again. I almost fell into the same trap myself as you can see . I bet you’re surprised that it wasn’t because golang doesn’t have generics. If you’ve heard those things and dismissed go, I would spend some time writing some real code with it and see if you still think it should be ignored.


Node was an obvious thing to evaluate. The community has a ton of popularity and is where it seems that much of the ruby community has migrated. One of the drawbacks in my opinion is the single thread programming model. While it simplifies things in some cases it complicates things in others. However unlike ruby, node scales very well even with the single threaded model due to it’s non-blocking async by default nature. How did it stack up?

  1. Testable – The testing tools are very good as well. Generally, I think testing tools in dynamic languages tend to be beter than static ones because they are absolutely necessary. Don’t read into that and draw conclusion that I’m saying testing is less necessary in compiled languages, but I do think people get away with it much more often (even if I consider it unprofessional to do so).
  2. Fast feedback – This is also one of the natural outcomes of a dynamic language. No more compilation step necessary so the feedback loop was very fast.
  3. Simple editor – We found nothing hindering our ability to write Javascript in a text editor. In fact, many of us already use vim for most of our Javascript editing anyways so this was no surprise.
  4. Good OSS community – Also obvious that the community would be good. There’s a ton of momentum in node and some really great projects. For example passportjs is something that the golang community is severely lacking. That’s just one simple example, but the ecosystem was one that we felt confident that we wouldn’t have to do much road paving in.
  5. Scalable – We have small concerns around the longer term scale questions, but for our immediate project needs there’s no question that it can handle the demand. Even with our longer term concerns we know it’s not a question of can, but rather how and at what cost of complexity.

For this reason, we chose node for the next project. It met all of our criteria and is an easy choice for us to adopt because many if not all of us already know Javascript and doesn’t come with the learning curve that Scala had.

Why the “For Now”? I honestly think within a year or two golang will be nearly impossible to ignore. It has a lot of momentum and if the community can learn to move forward together and use those implicit interfaces they’re so fond of there will be no stopping it from getting more adoption.

Feature Toggle With FubuMVC

Some people and organizations prefer to do feature toggles rather than branching by feature in their source control system. Regardless of your opinion on which way is best, this post will demonstrate a “fubu way” of doing feature toggles.

I’m assuming in this post that you already know how to get setup. If not, have a look at this post, or this one.

Here is a list of the goals we would like to accomplish to setup feature toggles.

  1. Specify features in web.config via AppSettings (although other options should be possible)
  2. Make an extension point in a page for which to expose pluggable features
  3. Avoid feature coupling as much as possible
  4. If possible, avoid runtime conditions when rendering page for feature area

We are going to leverage a bottle called FubuMVC.ContentExtensions, so start with installing this extra nuget.

Install-Package FubuMVC.ContentExtensions

Then let’s setup our page to look like the following.

The WriteExtensions method is what will accomplish goal #2. The named area is optional, but allows you to expose various other extension points if necessary.

Now let’s setup the infrastructure for our extensions. Add the following code to your project.

The interesting piece here is in the FeatureActivator. I’ve added a couple different pluggable features to demonstrate different ways you can render content through the ContentExtensions. Jeremy has a post on some of the finer details here. Another subtle detail is that the conditions for rendering features is done while bootstrapping instead of at runtime accomplishing #4 of our goals.

Last let’s deal with the AppSettings. I’m going to leverage a bit of StructureMap magic stolen from my co-workers here to eliminate some of the coupling to AppSettings directly, but as you can see this is pretty flexible so feel free to plug in your own way of doing things.

With that you should now be able to render the page and play with the values in the config file to see the features appear and disappear.

FubuMVC’s modularity story really makes this type of thing nice. I’ve seen others do this in different frameworks, but usually the result is coupled features and boolean values that get passed around through all the various layers of your application and the final condition ends up being placed inside the view. Unfortunately this makes testing even harder. Testing this for the most part would only be testing the FeatureActivator and some service registrations.

In the future ContentExtensions won’t require extending only a IFubuPage<TModel> page. They will allow for a regular IFubuPage, and we may create extension points inside the view engines for content areas or sections in Razor so that ContentExtensions can fulfill that content as well.

I hope this post gives you some ideas and shows some of the benefits FubuMVC brings with regard to doing feature toggles.

Getting Started With FubuMVC.Razor on VS2012

A bit premature on this post due to a little bit of rework I’m doing to FubuMVC.Razor. However, this past week I’ve heard a bit of gripes with how much the Razor implementation sucks and that it should just be dropped all together. Therefore, this post is really just to address how to get intellisense up and working for VS 2012.


This is still running System.Web.Razor 1.0. Don’t try to update, if you do and feel pain I told you so. Currently the implementation is leveraging RazorEngine to handle the rendering of templates and it hasn’t been updated for 2.0 yet. More on this a little bit later.

Step 1 – Initial Project Setup

Follow the instructions similar to the getting started guide here. Stop before adding any views and we’ll continue here with Razor specific instructions. In my sample I chose to use .NET 4.5.

Step 2 – Add Nuget References

Again, using the Fubu private nuget feed add a reference to FubuMVC.Razor.

Step 3 – Add Razor Views

Now add the following views assuming you followed the steps from earlier and already added everything else like HomeEndpoint etc. To simplify things modify you FubuRegistry to change the default route like below.

Make sure to place mypartial.cshtml, and Application.cshtml in a Shared folder at the root of the project. Also note, that adding in your template Layout = “Application” is optional as it defaults to Application if it isn’t specified. This is different than the ASP.NET MVC behavior.

Now if you run your application you should see a working page that renders markup from the page, layout, and partial. Also note, don’t use Include(“name”, model) overload it currently isn’t supported. More on that later.


Oddly enough there’s a few hoops to jump through to get the Visual Studio intellisense. None of this is required to actually render the views.

  • Add a reference to System.Web.Mvc, yes folks “@model TypeName” doesn’t work without it. Because this is only useful in MVC projects?
  • Make sure any references you bring in don’t require System.Web.Razor 2.0 for instance MVC 4
  • Modify your web.config to include what’s below. This information will inform the tooling which template base class to use, and which namespaces to import so you can get the proper intellisense.
  • At this point your tooling should begin to work, if not restart Visual Studio for safe measure.

The Proof

The proof

In Closing

Hopefully this will help some get started using Razor with FubuMVC. I am currently working on updating to Razor 2.0 and should be done in the next week. In doing so I have decided to remove the dependency on RazorEngine. This should clean up some of the template API and make things more discoverable going forward. I plan to also change Include to be RenderPartial to be more consistent with ASP.NET MVC and I may begin to support the overload I mentioned earlier.

FubuTransportation First Thoughts

We have been using FubuMVC for a while now and one thing for sure is that it’s like a drug and when you start using you don’t want to stop. The conventions, behaviors, model binding, diagnostics, all of which is pluggable makes for a very good platform to build upon.

A while back we kept thinking it would be really nice to have FubuMVC w/ behaviors for our message handling pipline on our service bus (which is currently using Rhino.ServiceBus). I then began a proof of concept and it turned out to be completely possible.

This proof of concept demonstrated a few possibilities and seeded ideas for others with the help of Dru. Listed here are a few them.

  • POCO message handlers including sagas which no longer requires implementing ConsumerOf<T>
    • Instead of _bus.Reply(message) message handlers just return a message
    • Instead of _bus.Publish(message) message handlers expose an event Action<object> Publish to invoke instead
  • Custom error handling beyond retryCount = 5
    • Handle specific error and place back in the queue at the end of the line
    • Handle any errors that don’t make sense to retry
    • Redirect to another chain / handler for error conditions
  • An HTTP Server and framework for each deployed endpoint
    • Bottles to begin leveraging more modular based deployments
    • FubuMVC.Diagnostics for every message handler
    • FubuMVC.Instrumentation (an extension to the diagnostics) to give us performance metrics on all of our message handlers
    • Possibility to have a runtime management UI around Rhino.Queues, which is one area it lacks pretty severely

We have since began to use FubuTransportation running inside FubuMVC.SelfHost and are already getting many of the benefits described above. Someone has already mentioned getting this working for NServiceBus, and I have talked with Dru about MassTransit and looks to be possible there as well. In future posts I will start talking about more specifics on how to wire up something like this in one of your own applications.

Getting Started With FubuMVC Again

Over the last several months FubuMVC has gone through a lot of changes in preparation for 1.0. The good news is that all of the major reorganization and repository breakout is done. If you’ve been hesitant to work with FubuMVC due to the large amount of churn that should begin to settle down now and it might be a good time to start getting familiar with the latest changes. I’ll let Jeremy explain what’s been going on, but many of the changes could be categorized into the following reasons.

  1. Heavily leveraging bottles and breaking things out allowing many features to evolve on their own rather than all getting bundled into FubuMVC itself. The diagnostics is one example of this.
  2. Simplifying what it takes to get a FubuMVC application up and running and trying to remove ceremonial configuration of your conventions (yes you read that right).
  3. General improvements to stabilization and reducing the possibilities of bottles stepping on another bottles toes.
  4. Adding additional diagnostics information.

Okay already, on to the code!

As of today you’ll need to add a reference to FubuMVC’s private nuget feed in your Visual Studio settings because the code has not been published to the public nuget feed until we update some documentation to reflect the latest changes.

Feed Url:

Start first by creating an ASP.NET Empty Web Application project. Assuming you’ve added the private feed mentioned above install the following nuget packages.

  1. FubuMVC.StructureMap
  2. FubuMVC.Diagnostics

Those two packages will bring in the remaining nuget packages we’ll need to get started.

Add a Global.asax and a FubuRegistry class like below. We’ll later do a little bit more with the registry but for now it’s empty.

Without doing anything else hit F5 and browse to http://localhost:{your port}/_fubu and look around and read what’s available. This is FubuMVC.Diagnostics and will be crucial for you as you begin to learn and use Fubu. Also notice that we didn’t have to setup any view engines? This is because of the recent work to extract out what we’ve been calling drop-in bottles. This removes some of the configuration that was necessary previously.

Update: Some may have issues with assets not loading in the diagnostics when running on IIS. If so, you can add this to your web.config.

Now let’s add our first route. Add a folder called Features at the root of your project. Add another folder inside Features called Home. In the Home folder Add 3 classes HomeInputModel.cs, HomeViewModel.cs, HomeEndpoint.cs and a Home.spark view template. The input model class will be empty. HomeViewModel.cs, HomeEndpoint.cs, and Home.spark should look like below (I know it’s not proper HTML). You can of course change this folder and code organization, but you’ll see that others find it quite useful.

Go back to the diagnostics page and see what has changed. You should see a new route (ugly as it may be). Browse to that url and you should see your page. The reason this works without doing anything in your FubuRegistry class is because there is a default convention for classes suffixed with Endpoint are actions. Now rename your HomeEndpoint class to HomeController. Go back to the diagnostic routes and you’ll see your route no longer exists.

Let’s customize things a bit. Go back to your FubuRegistry class and change it to the following.

Hit F5 again. Now you should see your route as the default route. Go back to diagnostics to see the new constraint as well.

This gives you a brief introduction into getting started with the latest FubuMVC changes. When you’re craving to find out more, the documentation is still a good place to start. Even though some pieces are still missing and some are a little out of date, many aren’t. If you find yourself still struggling with something, post a message to the FubuMVC discussion group. We’re usually pretty quick to help out.

Thoughts on Software Delivery Process

This post may be somewhat of a ramble, but it puts to paper as it were my experience on software process.

I’ve been fortunate enough to be part of a company and team that has started small and seen significant growth. When I began I was one of 3 new hired developers adding to a team of one other person. Today we have around 15 developers, and 15 others in related professions. Along that path of growth I’ve seen many things change. Some for the good and some for the not too bad compromise.

When we were small you can imagine what it was like. Typical startup with cowboy code and process type mentality. I can remember many long nights for releases and numerous points of regression when we released code. As we began to grow we got more serious about testing and added a QA team. We began learning about testing practices like unit tests, integration tests, etc. Around this time we were of the mindset that whatever Microsoft produces is AWESOME. This lead us down a path of using Team Foundation Server and other VS tooling for tests. Honestly, things worked fine. Until… we began to work with less technical people. We began interacting more directly with stakeholders. We hired less technical QA people to help with more manual testing. Our design team also typically worked on Macs. This all began to add a lot of friction to the workflow.

The problem with the workflow we were using is that it was focused on one stakeholder, the developer. We were forcing tools and processes on users that didn’t really want to participate. This is really when we began to explore new ideas.

Our first forray into sans TFS was Agile Zen. The kanban board was the latest rage and Agile Zen had a very user friendly interface and a reasonable pricing model. From our stakeholders point of view it was a huge improvement. We were now on our way down the path of continuous improvement, we just didn’t know it yet.

Kanban for us started out well, but the longer we used it things began to turn into waterfall again. Each column on the board represented the next step in our waterfall process. Later we heard the term “waterboarding” and knew that the term hit too close to home. We brought in a consultant to help us zero in on where we were going wrong. One of the nice things brought up in conversation is that it doesn’t really matter whether you use Kanban or Scrum. You need to look at the whole picture from when an idea occurred to when it was delivered to users. You also need to continuously re-evaluate and improve. You mean continuous improvement isn’t just for code quality? If you’re only analyzing velocity and story points you’re missing a big part of the equation. How did that story end up on the board? How long did it take to get there? Who had to talk to who in order for it to get attention, or approval? In my opinion this is when things began to really improve. We removed many of the unnecessary or wasted steps, and began to focus on getting value into users as quick as possible. Oddly, because it wasn’t the cool kid anymore… ended up switching to Scrum.

Scrum? Don’t you realize that time blocks suck? It messes with the natural flow of things. Sure, but it also helps us keep scope to a minimum. It also gives us a goal of deploying every two weeks, which was a big improvement from where we were. The point here is to do what makes sense for you, not you as a developer, you as an organization. Including all the stakeholders from developers, designers, QA, business stakeholders, product people, etc.

Next post I’ll discuss briefly how we as an agile development team deal with regulations like Sarbanes Oxley, HIPAA, etc.

Introducing FubuMVC.Instrumentation

Now you can have visibility into what your FubuMVC application is doing at runtime. Think performance counters available for every route in your application.

FubuMVC.Instrumentation is a drop in bottle extension for the existing FubuMVC.Diagnostics. You will see a new tab appear just by dropping it in one of your existing application, so long as FubuMVC.Diagnostics is dropped in as well. You’ll see more of this in the months to come, but serves as a pretty decent example of what types of things you can do with Bottles.

Currently the instrumentation provides the following types of information per route.

  • Average execution time
  • Hit count (for as long as the application has been running)
  • Exception count
  • Exception frequency to indicate the percentage of errors vs. success
  • Min execution time
  • Max execution time

When drilling down into each route to see more details for the current chain.

  • Average execution time for each behavior
  • Snapshot of configured X number of requests, with further drill down details
  • Last 10 requests that had exceptions with exception details, again with further drill down on where the error occurred

Here’s a sample preview of what it looks like. You can pull down the code and run the sample yourself from the github repository. The nuget is now available on the private fubumvc nuget feed as well. On a side note, we’ve had some hiccups the last few days with the build server and most issues seem to be resolved, but if you run into problems have patience we’re working on it.

Instrumentation Routes

instrumentation routes

Instrumentation Route Details

instrumentation details

A big thanks to Jordan Zaerr, and Andrew Kharlamov for their hard work on OSS Friday afternoons.

Hopefully you find this as useful as we have. We immediately had visibility that we never had before and within a few days improved the overall performance of our application due to the new found visibility.

In a future post I will describe how we have leveraged this same bottle running inside the FubuMVC.SelfHost in our messaging applications.

Creating a Diversion

It’s one of those common problems that pop up when doing web development. The stakeholders pose the need to redirect to another page if some condition isn’t met. One example might be… When a customer has not accepted our privacy policy and browses to a page that requires authentication, ensure first that they accept the privacy policy.

There are many ways this problem can be solved and one way is to always redirect them to a page for the privacy policy.

I’ll describe how we thought about this solution and how things have changed, finally showing the ideal solution (although not quite baked yet).

Coming from ASP.NET MVC

The common approach would be to introduce an ActionFilter. When we first went down this path this meant you needed to have an attribute on each action / controller that needed this behavior. This got a bit ceremonial, and additionally it required you to remember to register your action filters as you added new routes. I realize since then they have added action filters that can be applied globally and that would have helped.

The additional pain point that likely can crop up with this solution is what happens when the business says that they no longer want to redirect to another page, they want to show a modal dialog to the user?

Now I have to say this post is not a FubuMVC vs. ASP.NET MVC post. I am literally describing the experience we’ve had with this type of requirement from both perspectives. Obviously, I am a bit biased now that we have moved to FubuMVC and we have made the switch for reasons that make sense for us. If you’re not there, great. This isn’t a sales pitch and you can stay happy in your own bubble and I’ll stay happy in mine. I digress…

FubuMVC Solution #1

Early on in our transition to FubuMVC our first thoughts went something like this. “What’s the equivalent of an ActionFilter in FubuMVC? Behaviors, great!” and a solution was created that was very similar to an ActionFilter.

Here is a sample of what that solution might look like.

Now although there’s a lot going on in this class. It does bring with it the advantage of conventional wireup as shown below.

The disadvantages it brings using this solution is testing is a bit involved (although arguably less so than before). Continuations in FubuMVC are also conventional and we have lost this using the IContinuationDirector directly in our code.

FubuMVC Final Solution

Discussing things with Jeremy Miller while I was upgrading one of our projects to the latest version he suggested that I use more than one controller for the same route (or chain in Fubu terms). Huh? Coming from my previous experience this one threw me for a loop. Trusting in his advice I decided to give it a try.

Here is the final solution with some caveats for the not quite baked part. Having an InputModel of a different type on the same chain causes problems with partials, and the fubu diagnostics pages that detail your routes are confused and display these actions rather than the primary controller’s action. These issues will soon be remedied and I will update the post when it does. For now, you can just inject the IFubuRequest again rather than taking an argument for the action.

Here is what this solution might look like.

I think the sample speaks for itself. It’s obviously easier to test, and now we aren’t losing OOTB conventions around FubuContinuation. One scenario this would be useful. Say an AJAX rendered module on a page is the piece requiring authentication. The conventions can leverage a FubuContinuation during an AJAX request and return JSON data to the client indicating a redirect should occur, or possibly render a modal dialog as I mentioned before.

I hope this post has been helpful, with more posts coming soon. If you have questions, feel free to leave a comment, or post to the group. The community is quick to respond.