Eric Hexter

Updated TDD Productivity Plug-in for Resharper

erichexter — Wed, 01 Jul 2009 03:41:03 GMT

I first want to thank JetBrains for being pretty awesome. I have complained a lot about how they are constantly chaining their APIs to Resharper and as a result it makes keeping plugins very hard to maintain but they went way out of their way to help. I received and email from one of their developers offering to help on my plugin. Their was a change made in the latest version of resharp which made my plugin incompatible and their telemetry showed them a pattern with this problem. Just this week they made a commit to the source code and updated the project. I did not have the time to get into the internals of this change and I was really motivated by their help.

As a result, if you were using the plugin I recommend you download the latest version and install it!

Download it Here

For those of you who do not use it yet I will run down the features that are available.

1. Code forward, create a class in a referenced project.

When prompted with Quick Fixes for a non-existent class You get the following menu. This adds menu items to create the class in all referenced projects.( If this menu does not show up… you may need to add the project references to you unit test project).

After selecting a menu item. The class is created in the project you selected but the IDE stays in your test class. And you are prompted with the quick fix for adding the using for your classes namespace.

The class file is created in the corresponding project under the correct folder and namespace. It is that easy!

2. Move Class/Interface to referenced project

If you prefer working with your Class or Interface under test in the same file as your test class and move the class to your referenced project after you get your tests passing this feature will reduce the number of steps it takes to move the class to the referenced project. This eliminates the need to fumble around in the Solution Explorer window.

Opinionated Input Builders – Part 9 override the default Date Time picker

erichexter — Tue, 30 Jun 2009 13:07:23 GMT

Part 1 – Overview
Part 2 – the Label
Part 3 – the Source Code
Part 4 – the Partial View
Part 5 – the Required Field Indicator
Part 6 – the Performance
Part 7 – the Performance Take 2
Part 8 – the AutoForm
Part 9 – override the default Date Time Picker

I received a comment from Scott Hanselman about how would a better date time picker look using the opinionated input builders. I knew that this would be a complex problem just for the fact that there are currently very few good solutions to this problem now. While JQuery provides a great Date picker I am not very happy with the time picker. So here is a version of what this could look like. What I like about this approach is that it takes all the complexity including the multiple form elements and javascript and pushes it to a small partial that can be easily reused as well as it could be easily tested using QUnit.

The user interface I came up with is a combination of the Jquery UI datepicker and a set of dropdowns to select the time. I trimmed down the minute select box so that it only contains fifteen minute increments for this example.

In order to implement this I added a call to the Partial( ) method and passed in the name of my opinion for how a datetime should be rendered.

The next step was to add a partial control with the same name to my Shared view folder. This could have been placed in the Home folder if I only wanted to have this input available for that controller.

The code for the Partial view looks like the following. The view page is strongly typed to a DateTime model property. Than comes some jquery to pull it all together.

I rendered a hidden field, this field will be used to databind when being posted back to my Save Action. The other elements I appended some fixed names so that I can wire up an event that updates the hidden field when any of the values of the dropdowns or the date pickker text box changes. I also write a dynamice method named after the input field in order to reduce the client side code.

This is one approach to solve this problem, if you did not want to include this javascript and do the client side wire up of updating the hidden field this same work could be done in a Custom Model Binder that is wired up for DateTime objects that could look for fields with these names and than it could do the formatting. So there you go a few ways to tackle this problem.

Performance differences in the ASP.Net MVC View Engine when using two View Engines versus a single Composite View Engine.

erichexter — Fri, 19 Jun 2009 02:01:49 GMT

While I was testing out my VirtualPathProvider implementation in the Opinionated Input Builders series I ran across an interesting performance difference which was quite surprising. In fact even after looking at the source code to the MVC ViewEngineCollection it still seemed like this difference should not occur. But it does and I am sure that we will get to the bottom of this.

Don’t go jumping to any conclusions just yet about how this performs because the one common piece of functionality that these engines still rely on is a VirtualPathProvider that I implemented and I can honestly say I understand very little about how the VPP is used and how to ensure that it was implemented correctly to ensure maximum performance.

The first part of this graph (the green line) shows the requests / second that I can get through my MVC view when using two ViewEngines, the default view engine to handle all requests to the /Views/{controller} and /Views{Shared} . The second view engine Handles all requests to my virtual path /Views/InputBuilders/ . At the 7:50 mark I changed the flag and recompiled the application. You see a small dip while the application restarts with the new code in place. Now the application uses a single view engine that handles all the views for the default locations and my extra virtual path.

Here is the part of my codebase that shows the difference between adding my ViewEngine to the collection and Clearing the Collection and adding the view engine with parameters to handle the additional view locations.

The source code for the project I am testing is located here: http://code.google.com/p/erichexter/downloads/detail?name=InputBuildersV4.zip&can=2&q=#makechanges incase you wish to try this out yourself. The assumptions and environment settings are the same as they were in my previous post ( http://www.lostechies.com/blogs/hex/archive/2009/06/13/opinionated-input-builders-part-6-performance-of-the-builders.aspx ).

I would love to hear from someone who has an eye for performance tuning!

Making a Unit Test Framework agnostic Assertion in C#

erichexter — Thu, 18 Jun 2009 17:49:48 GMT

At the beginning of the year I got some feedback that the assertions in the MvcContrib.TestHelper library were great and very useful but the problem with them is that we relyed on the NUnit assertions. This was a problem for some users as they did not use nunit and did not want to include that dll in their codebase. I also have been frustrated because NUnit is strongly named and since I am using other framework that add a little extra on top of nunit I have found that I know need to add all sorts of Assembly Redirect configuration in my app.config files in order to trick all of the assemblies I am using to think they have the right version of NUnit. It is quite a big mess when you really think about it.

So at the Alt.Net conference in Seattle I proposed a session to talk about Unit Test Framework agnostic assertions and helpers. I was quite lucky to have some very smart people in the room and on the kyte.tv feeds. The end result that came out of the was this. Just throw a custom exception and the test frameworks will pick it up. I was told that this is how Rhino Mocks handles it’s assertions and that the test frameworks would eventually add my namespace to there code base so that the Call stack reported to the developer running his tests would not see the frames that were used internally by my assertions. Let me give you a visual so that it is a little easier to understand exactly what the problem is….

The first line in this example shows a line that is from my special assertion code. I do not want that to show up when a user runs a unit test with my assertion.

Here is my little assertion helper example. Since I just created a standard exception I got the default behavior.

The way to fix this is to throw a special exception which knows how to remove specific frames out of the call stack. This code was adapted from the xUnit source code and is working quite well in the MvcContrib Test Helper Library

With some simple string manipulation of removing lines that contain the namespace of my exception it is really easy to reuse this exception in an Unit Test framework Agnostic helper library.

Here is the result of an assertion that failed using this assertion. As you can see the test runner does not show lines that my assertion framework contain the call stack stops at the last line in my unit test code. Which is exactly what we want. That way there is no question as to where the developer using this needs to look to get information about the test failure.

This code is located in the MvcContrib TestHelper library located at http://MvcContrib.org in case you want to dig deeper into the code. I hope this helps others as it really took some time to get to this approach.. It seemed totally obvious to the developers of the unit test frameworks but for us mere mortals it took a little extra digging to really understand how the Unit Test runners work.

Comments .. Questions ???

Opinionated Input Builders – Part 8 the Auto Form

erichexter — Wed, 17 Jun 2009 17:38:20 GMT

Once I defined what my the opinions for rendering each data type of my model as a form element it was a pretty trivial exercise to take this to the next level and render a default form for the model. Just a single like in the view that walks over each property of the model and decides how it should render each property. Although this was not my goal of the builders it was a logical step to go from a pattern for each property to just enumerating all the properties. I think this really shows the power of having the strongly typed view models.

While I like this approach I would not stick to this as the only way to develop forms. I would use an approach like this to take care of my initial CRUD type screens and allow this to quickly get my views hooked up to my controllers. The next step is to have a clear and simple path for dealing with the case where the AutoForm does not work for a scenario. Using some of the View Templates it is pretty trivial to generate a view or a partial that displays the view code to define each input individually so that they can be re ordered or have properties overridden.

Here is the form that is generated as well as the single line of view code that is used to create it.

Just to show how trivial it was to implement this functionality here is the section of code that is called to loop over each property of the model. It would be pretty easy to modify this for your conventions to say add a Validation Summary to the top of the form. This code simply loops of the properties of the Model Type and then renders the partial needed for each of the properties type. Than a Submit Button is added and the form tag is closed. Pretty simple.

Opinionated Input Builders - Part 7 More on Performance / Take 2.

erichexter — Sun, 14 Jun 2009 19:15:02 GMT

Part 1 – Overview

Part 2 – the Label

Part 3 – the Source Code

Part 4 – the Partial View

Part 5 – the Required Field Indicator

Part 6 – the Performance

Part 7 – the Performance Take 2

After doing what all good developers should do on the weekend… which is enjoy life and spend some time with my family, I thought I would take another stab at the Input Builder performance and see what else I could learn about the implementation. That being said this is what I came up with.

Want to get a 2X increase in 5 seconds of development time?

One of the features of the Builders that I like is the ability to deliver all of the partial views from a separate assembly that would make this library and approach feel more like a component with a single package for all of its files than a Hodge-podge of files you need to copy into your project. That approach came at a cost. My own implementation of the VirtualPathProvider proved to be disastrous on performance. Below is the same performance test running against my sample page with the partial views and master pages copied into the local project and removing my implementation of the VirtualPathProvider.

With this small 5 second change the Maximum Requests/Second went from 442 to 1,027 . The Average Requests/Second went from 351 to 908. Not bad huh? So after a single change to the code base and removing my custom code for pulling partial views from the embedded resources, I was able to get a huge performance increase.

What are the next steps?

Since I still like the approach of having the virtual path provider I will spend a little time looking into how I can change the implementation so that it renders better performance. Now that I have better performance out of the builders it will be good for me to take a 2nd pass with the profiler and see where the hot spots are. My hunch is the bottle neck in this code is something that I wrote versus something that comes out of the box with the framework. So there will be more work to do on this front but at this point I am positive that I can overcome the performance aspects of this approach and I will concentrate on a few more posts which discuss more of the opinions as well as more of the implementation.

Opinionated Input Builders Part 6 – Performance of the builders

erichexter — Sat, 13 Jun 2009 17:15:00 GMT

Update - 6/14/2009 Chad Myers blogged about the trade offs and the importance of productivity over premature optimizations.

Update 6 /14/2009 – Please see the second set of tests I ran for a large performance increase.

Multiple people asked about the performance implications of using this style of input builders. First let me say that as far as performance, using the partial views is probably the least efficient way to render html. But with every approach there are tradeoffs. In this case we are trading run time performance for developer productivity and codebase and user interface consistency. That being said I cannot answer what the best approach is for you. That depends on the size of your team , the size of your project, the skill set of your team and a number of other aspects which determine what the best approach is. For instance I would not use input builders or a MVC view if I was building a form to collect votes for American Idol. I would actually create the forms in static html pages. The scalability would require the best performing solution.

The Control Test

With any good test you have to have a control case. In this case I ran a load test against an empty MVC view that was using the same Master Page as my form page. I ran a constant load against that page in IIS 7, on a x64 Vista OS for 10 minutes. The results is that I have a maximum Request / Second of 1,622 and an Average Requests / Second of 1,275. You can see the chart below of the Requests/Second.

The Load Test

Next I ran the same test against the page I have used for all of the samples in this series. With the same load , machine configuration, and duration as the control test. In this case my Maximum Requests/Second was 442 and the Average Requests/Second were 351. What does that mean? I lost 75% of my page request through put by using the Input Builders. Does this mean we should not use the input builders? The answer is … it depends. What through put do you need? From my experience I have found that most forms backed by a data store cannot scale to 400 Requets / Sec without some significant architectural principles in play. Such as asynchronous messaging and other methods to scale.

What are the next steps for performance?

The next step for me is running the load test with a Profiler attached to the process. I used the JetBrains Dot Trace application. It is nice because after I run the profile session and analyze the data it has a quick and dirty Hot Spot report. This show the single biggest offender of my codebase. This means that if I optimize the code below that will have the biggest improvement for performance. It is a combination of the time it takes to execute this code combined with the number of times this code path is executed. That being said, lets dig into it.

The 3rd call in this stack is part of the RenderPartial call I do not totally understand the internals of the MVC view engine and I will not pretend to. If I really wanted to see more it would make sense to pull down the MVC source code and build it with is symbol files, than the profiler could give me more information. So what I am surprised by is that my hunch when first thinking about performance would have taken me to the reflection and Lamda Expression code, but this test shows that the biggest bottle neck is in the control / partial rendering. So by using this tool I have saved myself a huge headache by preventing myself from optimizing the wrong code. At this point I am going to put this information together and get it in front of those in the .Net Community who are way smarter than I am and of course, get it to the brainiacs at Microsoft who wrote this stuff to suggest some approaches for better performance . They know their internal benchmarks as well as what they are planning for the future.

The biggest lesson I can demonstrate here is do not pre optimize. I already wasted 20 minutes of my time and Jimmy Bogard’s time talking about different ways to optimize Lambda Expressions. It is clear that implementing those optimizations would not make a single difference in effecting the output of this performance test.

Should you use the builders?

Well that decision is really up to you, but I hoped that I demonstrated a scientific approach to answering that question. For me the componentization of the HTML and the productivity increases of using the builders far outweigh the runtime performance issues. Again, I would take this on a case by case basis and when I need more throughput than what I can provide with this approach I would consider a different method of mark up generation.

Free ASP.Net MVC Workshop in Austin on Tuesday June 16th

erichexter — Thu, 11 Jun 2009 13:32:07 GMT

I am doing a half day workshop at the Microsoft Office in Austin around ASP.Net MVC. I did this in February with Jimmy Bogard and we had about 90 people show up, it was a pretty good event. We will cover a lot of what we have learned using the framework on a number of large enterprise project at Headspring Systems. This time I am doing the workshop with Jeffrey Palermo and we will cover a portion of the presentation he gave to the Austin Code Camp. After that I think I will dive into some features around getting things done with the framework. See Jeffrey’s post for some more details.

To Register go here: http://www.headspringsystems.com/services/agile-training/mvc-training/

Opinionated Input Builders for ASP.Net MVC – Part 5 the Required input

erichexter — Thu, 11 Jun 2009 02:58:00 GMT

The Required Field Indicator

The Required Field Indicator is a property which allows the UI to indicate that a field is required. The example below shows that an asterisk could be used to indicated the field is required. This could be used to apply a css class to the Label which could change the color or bold the label. The possibilities for how you turn this property into a compelling user interface is endless. The important point to know is that there are different approaches to decide how this could be set.

Model Approach

Here is an example of using a DataAnnotations Required attribute as a way to indicate the field is required. I like this approach since this attribute can be used with a Model Binder to perform Model Validation using model state. This model binder will be provided in the ASP.Net MVC 2.0 release so I included this as a way to get synergy with existing features of the MVC framework.

I have received a lot of feed back that people feel marking your model with attributes pollutes the model. I disagree with this because the models that I use are View Models not my Domain entities which represent my business object which will be stored into my database. The Models that I would decorate with validation attributes would be used for one specific MVC View. The model would represent the fields needed to create the User Interface view.

Fluent Approach

An alternative approach to using attributes would be to use a Fluent method as shown below. I dislike this approach as it does not work with my preferred way of performing data type validation using the MVC Model Binder. in the framework. I would be more likely to use the fluent methods for the Label or PartialView selection, but I would not use it for the Required indicator because it would mean I am duplicating how I identify a required property on my Model.

The View markup

Here is an example of how the Required property is used in the Field.Master master page. As I wrote earlier, this could be used to add a css class to the html markup.

Your own convention

The framework uses a convention to determine if a Model property is required. By implementing your own PropertyIsRequiredConvention you could make all Properties with the name Name & Description required or whatever makes sense for the type of application that you are creating. It could be Username or email if you are creating a consumer facing website the possibilities are endless. But at the end of the day you can have your own convention.

Here is the implementation of my Default Convention for Property Is Required, it is simple and to the point. I could see implementing some sort of Chain of Responsibility pattern here and in the other conventions to have some consistency to your User Interface.

Thoughts… opinions..?

Opinionated Input Builders for ASP.Net MVC – Part 4 the Partial View Inputs

erichexter — Wed, 10 Jun 2009 15:00:00 GMT

This is the forth part of the series.

Given this form that is generated by the input builders the partials for each data type of the Model are selected by the builder based on a simple convention.

Each partial control is selected using the following convention:

The type of the property is used to find a Partial View by the same name.
If the partial does not exist in the /Views/Shared/ directory it is pulled from an embedded resource from the Input Builder assembly. This allows you to override the conventions of the framework with your own.
If a PartialView Attribute is applied to a property it is used to override the previous conventions.
Display a partial using a Chained Method on the Input() method UsingPartial( partialName )

Looking at the types of the model you can see that the Enum partial will render a Select element by default. The PartialView(“RadioButtons”) attribute was applied to override the default and have the build render the RadioButtons.aspx partial view.

This is an example of using the Chained Method override instead of using an attribute based approach.

This convention of utilizing the partial views allows the separation of concerns (SoC) of the markup from the conventions which determine which partial to render.

What if you do not like the convention ????? Each part of the UI model is extensible. There are two conventions that are at play here. The selection of the partial view and the selection of the data that is used by the controls to display the possible selections. This is shown for the enum data types which allows the select and radio button inputs to display a list of possible values.

The ModelPropertyFactory class calls two methods to execute the conventions. The ParialNameConvention and ModelPropertyBuilder by using the static Func fields this will allow your project to define your own conventions if you do not like mine. This is an important extensibility point that gives the great flexibility to this approach. There are conventions like this for each of the elements used within the partials.

Opinionated Input Builders for ASP.Net MVC – Part 3 the source code.

erichexter — Wed, 10 Jun 2009 13:36:50 GMT

There have been a number of requests for me to provide the source for the input builders. I consider this code to be a prototype because, I expect to change the API as this post series helps me work out what should be supported. I have full intention to add this code to the MvcContrib project once I get the appropriate feedback and documentation as a result of fleshing out this post series.

With that being said the source code is located here: There is only V1 up there now but I expect to have some iterations pretty quickly.

http://code.google.com/p/erichexter/downloads/list?q=label:Inputbuilder

Requirements:

ASP.Net MVC 1.0
Visual Studio 2008

Solution Structure:

The solution is structured into two projects. The InputBuilder project is what I would see providing as a dll in the future. The web project is a MVC web application that shows how to use the InputBuilders as well as override markup for the builders.

Opinionated Input Builders for ASP.Net MVC - Part 2 Html Layout for the Label

erichexter — Wed, 10 Jun 2009 01:26:02 GMT

In part two of this series I will cover the different components of the Input as it is rendered to HTML and explain how each of those are created by the Input Builder.

Given the following form layout I will explain each feature of the input builder framework.

the Label

The text highlighted in red are labels that come from the Model type. The label is created from the PropertyInfo object that represents the respective properties of the mode.

The label is Property Name.
The label is the Property Name that is split on the pascal case property name.
The label is specified by using the Label Attribute applied to the property.

The html for the label is created in a Content control of the Field.Master Master Page. That control is highlighted in red.

That explains how the labels are rendered to the html for the builder. There will be more posts in this series to explain the other conventions followed by the Input Builders.

This is part 2 in the series.

Part 1 – Introduction to the Input Builder

Opinionated Input Builders for ASP.Net MVC using partials – Part 1

erichexter — Tue, 09 Jun 2009 16:21:00 GMT

It has taken a while to really understand how different pieces and ideas can fit together to give a concise and productive form input helpers for the asp.net mvc framework. I have pulled together this idea from the following sources:

“opinionated input builders” that Jeremy Miller and Chad Myers presented at the Kaizen Conference in Austin last year,
The work that Headspring Systems (Jimmy Bogard and Matt Hinze) has done with that concept on some of our big projects.
Brad Wilson’s sample of how Dynamic Data Could work on Asp.Net MVC
Convention Over Configuration – Ruby on Rails and Jeremy Miller
Creating partial views as aspx pages with their own nested master pages via Jeffrey Palermo
The strongly typed helpers from MVC Contrib and the MVC Futures work that the MVC Team has put together.

Now that I have given credit to everyone who has helped me get to the point of understanding how to pull of these pieces together.

The Model comes first.

The goal of these control helpers is to reward you for developing MVC with the Model first. Yeah there is a reason that Model View Controller starts with the Model. Using the strongly typed views in the aspx view engine we can carry the type down to the control helpers with intellisense and then build html input control based on conventions for rendering specific CLR types to specific HTML output. Now my biggest problem with the ways that this has been attempted to date is that once helpers started to take on more mark up beyond the < input > tag it was hard to modify as that markup ended up being written in code rather than in a view file. This is where I abstracted the mark up and the logic to decide which markup to render so that there is a solution that is easy to maintain the markup and it is easy to add new conventions or change the conventions for how a particular type or model property is rendered to a control.

First here is an example of a model rendered in a strongly typed view and the markup used to create this. There are attributes applied to the model to add some specific control over how the UI is rendered. It is important to call out that in this case I have built a (view) Model specifically to represent a single view. I do not intend to reuse this model in another views. I think trying to get reuse out of models is a mistake in most circumstances, it is better to keep your model clean so that it represents exactly what you want for the View. Each of these attributes are used by my conventions to decide which Partial View to render.

This is the example of the view page which is rendering the view and the markup used to create this. The Html.Input uses the LamdaExpression syntax to declare which property needs and input.

It is important to call out that the Guid property is rendered as a Hidden input tag and that is why it does not show up in the UI. This is a model element that is used to carry state in the form between posts.

Walkthrough of the Html.Input( ) method

The syntax for calling into the input method uses a lamda expression like so….. This has full intelisense support.

The helper determines that since the Name is a string data type it decides by convention to render this property using the String.aspx partial view.

Here is the markup of the String.aspx partial view. As you can see it uses a Master Page to control how its label and input is rendered.

Here is the Field.Master Master Page this controls the layout of the input, label, example text, and validation message.

More to come soon.. What do you like… what do you dislike?

The Flat Tire Principle for Source Control

erichexter — Tue, 19 May 2009 03:24:00 GMT

There is a strange correlation between automobiles and line of business software applications when it comes to performing some standard repairs.

Consider the following scenario, you are happily working away at your job or out dining with your friends or family and when you come out to your vehicle, it has a flat tire. While this does not happen that often, it is a pretty common occurrence.

This common occurrence can look like this in an ASP.Net application….

In fact it is so likely to happen that most (if not all) automobile manufactures include the necessary equipment to keep you moving along when this happens. So where in your trunk or hidden under your seats are usually a spare tire. a jack, a wrench, and in some cases a special adaptor to loosen on special lock lug nut. The lock lug nut is a lug nut that is specific to each manufacturer and is meant to deter criminals from stealing your tires.

After a little work you can get your tire replaced or if you do not feel handy enough you can call for some help to get your spare tire put on and your flat tire put into your trunk so that you can get to a repair station. Once you get to a repair station they will ask for your lock nut. The repair stations do not want spend the time working with the wrong tools to get your new tire on.

This is where I can relate this analogy back to software. I consider all of those 3rd part controls, open source libraries and tools the lock nuts of software. We call these lock nuts system dependencies. You must handle all of your dependencies with extreme care. All of these tools can prevent your ability to maintain a software system in the future.

Why? If you do not keep your dependencies in your source control tree than when it comes time to build your software after you rebuild your machine or when it comes time to fix a bug brought on by environmental changes this simple thing can turn an easy fix into an impossible task.

The fix to this problem is pretty simple.. Grab all of those evil 3rd party assemblies and specific versions of libraries and include them in your source control tree. Here is the /lib folder of the CodeCampServer project. This seems like such a simple little thing yet so many developers make the mistake of ignoring their dependencies and instead keep relying on remembering where they put the installer for the specific version of a control their project needs which is sitting on the company file server. I cringe thinking about all the developers who will stumble on this code years down the road.

Big Props to the Codeplex team!

erichexter — Sun, 17 May 2009 03:09:58 GMT

A month back I was on a mission to get a feature included in Codeplex that would allow my projects to better support the companies which fund my projects. I reached out to the community to help vote this feature up from somewhere in the lower 400s to the number one (1) position. The Codeplex team implemented the feature and pushed it live in the matter of weeks. I talked with one of the team members at Teched and they told me the feature would have made it up a week earlier but there was an across the board focus from the company to test out their latest product.

I was so glad to have such an awesome response from the team.. I have hosted Open Source projects on Codeplex , Google Code and Source Forge and I must say I have never had this type of interaction with Google Code or Source Forge. While I dislike the source control system with Codeplex, I have to say that to have a team that is that focused and transparent is just awesome. So… huge props to Codeplex. Having a team that is willing actually listen to the users is a huge reason to consider codeplex for your open source projects.