Los Techies

Refactoring challenge Part 2 – Preparation

bogardj — Thu, 09 Jul 2009 02:22:00 GMT

Refactoring challenge Part 1 - Examination

bogardj — Wed, 08 Jul 2009 02:51:45 GMT

Most of the time I post code on my blog, it’s something I’m proud of. Other times, it’s code I didn’t write, which I promptly lambaste. In my last post, I threw up code I did write, but couldn’t see the design coming out. From the responses, I think I have some direction. But first, let’s take a closer look at the design issues with the original code, and try to catalog the code smells. This should give us direction on how we need to refactor it. Here’s the original code:

public object Map(ResolutionContext context, IMappingEngineRunner mapper)
{
    object mappedObject = null;
    var profileConfiguration = mapper.ConfigurationProvider.GetProfileConfiguration(context.TypeMap.Profile);

    if (context.TypeMap.CustomMapper != null)
    {
        context.TypeMap.BeforeMap(context.SourceValue, mappedObject);
        mappedObject = context.TypeMap.CustomMapper(context);
    }
    else if (context.SourceValue != null || !profileConfiguration.MapNullSourceValuesAsNull)
    {
        if (context.DestinationValue == null && context.InstanceCache.ContainsKey(context))
        {
            mappedObject = context.InstanceCache[context];
        }
        else
        {
            if (context.DestinationValue == null)
            {
                mappedObject = mapper.CreateObject(context.DestinationType);
                if (context.SourceValue != null)
                    context.InstanceCache.Add(context, mappedObject);
            }
            else
            {
                mappedObject = context.DestinationValue;
            }

            context.TypeMap.BeforeMap(context.SourceValue, mappedObject);
            foreach (PropertyMap propertyMap in context.TypeMap.GetPropertyMaps())
            {
                MapPropertyValue(context, mapper, mappedObject, propertyMap);
            }
        }

    }

    context.TypeMap.AfterMap(context.SourceValue, mappedObject);
    return mappedObject;
}

So let’s list out the code smells, there are quite a few.

No tests

I forgot to post the tests, but even more telling, I only really have large-grained, scenario based tests that cover this class. No unit tests, and that problem starts to show here, as tests would have surfaced the code smells earlier.

Feature Envy

There’s lots of poking around the ResolutionContext object (which is responsible for holding all information pertaining to a mapping operation). For example, the first nested “if” asks the ResolutionContext a lot of things that don’t seem to make any sense by themselves. Additionally, it’s not clear at all what each conditional has to do with the work being done.

Long Method

This should be quite obvious. For me, the ideal maximum method length is about 10 lines. That’s pretty much the limit of my understanding of what’s going on. Any more than that, and I have to put too much context into my head.

Conditional Complexity

Way too much branching going on here, and even worse, it looks like arrowhead programming. Flip it sideways, it looks like a mountain range with all the indention. The cyclomatic complexity is off the charts here, and a tool like NDepend would let me know right away where my maintenance problems will be.

Those are a lot of code smells, but each one has their corresponding refactoring to take care of it. In retrospect, I’m not sure why I just didn’t look for code smells in the first place. In the next few posts, I’ll apply refactorings one by one to get to my destination – clean code.

VAN: Castle Monorail, Active Record and Brail talk at Wednesday 8PM CST (-5 GMT), by yours truly.

Ryan Svihla — Tue, 07 Jul 2009 12:00:00 GMT

Last week I did a talk on Windsor and it went..ok. I’m not used to online presentations and am more experienced in front of crowds that I can interact with.

So between last week’s experience and some advice from Agile Joe this talk I’ll be aiming for more of a screen cast feel. The talk should go for close to an hour and will be open for questions afterword.

Outline is as follows (subject to change):

Monorail

Controllers
Windsor integration
Grouping controllers (“Area’s”)
Aspect Oriented Programming through Filters

Brail View Engine

Conditionals and Iterators
Parent/Child Views
Sub Views
Rescues

Active Record

Architecture overview
Using multiple databases
Using Active Record in a more DDD friendly way
Introduction to writing queries in HQL
Working with the underlying ISession.

If any of you have the time drop by for some/all of this and give me some feedback please do so.

Refactoring challenge

bogardj — Tue, 07 Jul 2009 02:42:47 GMT

I don’t like messy, obfuscated code. But ~~occasionally~~ often, I write it anyway as I can’t quite see the right way to go. Today is one of those days where I can’t seem to get past some ugly code, none of my normal tricks seem to work. Instead of me doing any more work on it, I’m curious if anyone else has any ideas. Here’s the offending function, in the TypeMapMapper class from the trunk (R97) of the AutoMapper codebase:

public object Map(ResolutionContext context, IMappingEngineRunner mapper)
{
    object mappedObject = null;
    var profileConfiguration = mapper.ConfigurationProvider.GetProfileConfiguration(context.TypeMap.Profile);

    if (context.TypeMap.CustomMapper != null)
    {
        context.TypeMap.BeforeMap(context.SourceValue, mappedObject);
        mappedObject = context.TypeMap.CustomMapper(context);
    }
    else if (context.SourceValue != null || !profileConfiguration.MapNullSourceValuesAsNull)
    {
        if (context.DestinationValue == null && context.InstanceCache.ContainsKey(context))
        {
            mappedObject = context.InstanceCache[context];
        }
        else
        {
            if (context.DestinationValue == null)
            {
                mappedObject = mapper.CreateObject(context.DestinationType);
                if (context.SourceValue != null)
                    context.InstanceCache.Add(context, mappedObject);
            }
            else
            {
                mappedObject = context.DestinationValue;
            }

            context.TypeMap.BeforeMap(context.SourceValue, mappedObject);
            foreach (PropertyMap propertyMap in context.TypeMap.GetPropertyMaps())
            {
                MapPropertyValue(context, mapper, mappedObject, propertyMap);
            }
        }

    }

    context.TypeMap.AfterMap(context.SourceValue, mappedObject);
    return mappedObject;
}

Yes, it’s very, very long. Originally, there were four different exit points all over the place, but that made it difficult to do other things I needed (the BeforeMap and AfterMap calls). There’s just way too much going on here, so I’m curious if anyone out there in the æther has any other ideas. Feel free to post ideas here, or for those adventurous folks, submit a patch on the AutoMapper group. Frankly, it’s making me cross-eyed, so I’ll just turn away in shame.

Python Web Framework Series – Pylons Part 7: Refactoring, Deployment And Wrap-Up

Ryan Svihla — Sat, 04 Jul 2009 12:00:00 GMT

Lets take a look at our existing site and what we can do to clean it up and add some badly needed functionality, however that is beyond the scope of my series. So I’m going to leave some hints for the remaining functionality to get you started.

Refactoring Ideas

Replace default authkit login with custom login. HINT: make a sign-in link on your public page. then redirect to a custom login page that uses authkit. Trying it any other way will make you lose hair.
Refactor database access into a class or two. This will make the db access more testable and allow you to monkey patch in different behavior later. HINT: If your controllers can avoid having to know anything about SQLAlchemy you’ve done your job.
Replace return “rsvihla” in the users.py module with actual authkit user. HINT: just access pylons request object: “request.environ.get("REMOTE_USER")”
Create admin ui for users, with roles. HINT: look at Pylons Book for Authkit ideas here.
Split threads into categories and then give the ability to respond to posts. HINT: just more controllers and views.
Makes parts of your view visible depending on if a user has certain rights or not. HINT: while this is not what you’ll find in the Pylons Book I highly suggest not have gobs of if/else checks in your views. Make small functions that you can unit test easily which will change what is visible depending on role, then have your views call these. See what I did with my user.py module for a concept.

Deployment

This almost completely depends on your situation with hosting. If you are using something like WebFaction you just have to upload files and follow their directions. I found it trivial to have a production site up and running with them.

Now if you are using your own dedicated server or want to shrink wrap the project I suggest using Python Eggs, this is not pylons specific at all and I’ve built them for a number of other projects. There are some snags you can run into depend on your platform and how portable you want to make this but as long as your dev platform and production platform are the same all you need is “python setup.py bdist_egg” and you should have a egg file in the dist directory which can be installed with easy_install.

Finally, you’ll want to build a production.ini . By and large you can copy your development.ini but you must must make your debug = false or you’ll give people access to your application in all sorts of bad ways. Also, don’t forget to make your secret strings actually secret strings.

Overall Impressions

Things I like:

Pretty easy to get up and running quickly.
paster and nose integration is pretty slick.
being able to functional test response including view is actually nice. Really wish I had this in Monorail as easily.
Component based to the hilt. If you really don’t like something you can switch it out.

Things I don't like:

AuthKit is like all auth frameworks I’ve used, just a lot to make work the way I want.
Too much violation of dry in the config. AuthKit being the main culprit here, while I may want to change which datasource I use, I’m not sure how helpful it is to have to select “form, cookie” for each ini file I make.
Explicitly calling the view in my actions. Should have some convention over configuration here.

So I could certainly see using Pylons more once I get my own auth solution worked out, and get my own code flow working I could actually probably get work done more quickly in it than most web frameworks I’ve learned. The majority of the time I wasted learning was dealing with authkit, in fact that took more time than everything else I studied combined.

Thank you for taking the time to get this far with my posts. If you have any specifics parts you want me to dive into more depth and/or suggestions for me on the next series (which will be Pyxer with Google App Engine) let me know.

Theory Of Constraints: Productivity Metrics in Software Development

derick.bailey — Fri, 03 Jul 2009 17:38:16 GMT

In the past, I’ve been a true believer that software development is not really possible to measure from a productivity perspective. I was ignorant, basically. I’m now a bit wiser and I understand that software development is no different than any other product development process. We can and should measure productivity of software developers by understanding that we are building business value via functionality that the end-user wants. So, we should essentially be measuring our progress toward the end user facing functionality (as an over-simplification).

A Paper On The Theory Of Constraints

Several months ago, I wrote up a paper for an internal company effort to help define productivity metrics for software developers. This paper is largely based on the work of David J. Anderson, in “Agile Management For Software Engineering”. It also includes some of my own interpretations and understandings of the Theory of Constraints.

The original intent of this paper was to facilitate the discussion of productivity and metrics in the Development Department at McLane Advanced Technologies, LLC., where I work. I decided to release it to the world, to hopefully help others understand how we can measure productivity as software developers. I did not intend this to be a comprehensive or exhaustive discussion of the points within, but am trying to spur additional research and conversations. I hope you enjoy reading it as much as I enjoyed writing it.

Download The Paper

You can download the PDF here:

The Theory of Constraints: Productivity Metrics In Software Development

How not to do Dependency Injection, in NerdDinner

bogardj — Fri, 03 Jul 2009 16:19:29 GMT

Checking out the NerdDinner code the other day, I found a common Dependency Injection anti-pattern. One of the core concepts of DI is that components are not responsible for locating their own dependencies. The code went part of the way to full-on DI, but not quite far enough. Here’s the offending code:

public class SearchController : Controller {

IDinnerRepository dinnerRepository;

//
// Dependency Injection enabled constructors

public SearchController()
    : this(new DinnerRepository()) {
}

public SearchController(IDinnerRepository repository) {
    dinnerRepository = repository;
}

The second constructor is correct – the SearchController’s dependencies are passed in through the constructor. This is because the IDinnerRepository is a required, or primal dependency. SearchController depends on IDinnerRepository to function properly, and won’t work without it. But on the first constructor, we violate DI by having the SearchController create a concrete DinnerRepository! We’re now back to concrete, opaque dependencies. We have a small benefit of easier testability, but we still force our controller to locate its own dependencies.

So why is this a Bad Thing?

For one, it’s confusing to have two constructors. Why go through all the trouble of creating the IDinnerRepository interface if I’m just going to depend directly on an implementer? Now what if DinnerRepository now needs some dependency? What if it now needs some ILogger, security or policy dependency? Do I now need to go fix all of my calls to “new”?

And that’s the whole point of Dependency Injection, and the Dependency Inversion Principle. I only know about my first level dependencies, and abstractions on top of that. If we check out DinnerRepository, we see another issue:

public class DinnerRepository : NerdDinner.Models.IDinnerRepository {

    NerdDinnerDataContext db = new NerdDinnerDataContext();

A private, opaque dependency to NerdDinnerDataContext. If we wanted to make that opaque dependency explicit, we’d have to fix our SearchController (and all the other controllers as well). It’s these kinds of ripple effects that prevent refactoring and improvement.

Fixing it

But we can fix this, quite easily. From MvcContrib, we can grab any one of the ControllerFactory implementations for the IoC container of our choice. For me, that’s StructureMap. First, we’ll need to configure StructureMap to wire up all of our dependencies. The preferred way to do so is to create a Registry:

public class NerdDinnerRegistry : Registry
{
    public NerdDinnerRegistry()
    {
        Scan(scanner =>
        {
            scanner.TheCallingAssembly();
            scanner.WithDefaultConventions();
        });

        ForRequestedType<NerdDinnerDataContext>()
            .CacheBy(InstanceScope.HttpContext)
            .TheDefault.Is.ConstructedBy(() => new NerdDinnerDataContext());
    }
}

In the first part, we just tell StructureMap to scan the calling assembly with default conventions. This will wire up IDinnerRepository to DinnerRepository. Probably 99% of our dependencies will be taken care of in that one call. Next, we need to wire up the NerdDinnerDataContext (for reasons we’ll see soon). Since that class has multiple constructors, StructureMap likes to use the greediest dependency, with the most arguments. I don’t want that, so I override it to use the no-arg constructor. Finally, I cache it by HttpContext, though I could probably go Singleton if it’s expensive to instantiate.

Next, I need a wrapper class to initialize StructureMap:

public static class IoCContainer
{
    public static void Configure()
    {
        ObjectFactory.Initialize(init =>
        {
            init.AddRegistry<NerdDinnerRegistry>();
        });
    }
}

Initialize only needs to get called once per AppDomain, and all I need to do is add the NerdDinnerRegistry I created earlier. I could wire up everything here, but again, the preferred configuration method is through registries. The next piece is to wire up ASP.NET MVC to both call our configuration method and use the StructureMapControllerFactory:

void Application_Start()
{
    RegisterRoutes(RouteTable.Routes);

    IoCContainer.Configure();
    ControllerBuilder.Current.SetControllerFactory(new StructureMapControllerFactory());

    ViewEngines.Engines.Clear();
    ViewEngines.Engines.Add(new MobileCapableWebFormViewEngine());
}

I put all this in with the other MVC configuration in the Global.asax Application_Start method. One final piece is to remove the extra constructors on our controller:

public class DinnersController : Controller {

    IDinnerRepository dinnerRepository;

    //
    // Dependency Injection enabled constructors

    public DinnersController(IDinnerRepository repository) {
        dinnerRepository = repository;
    }

And make our DinnerRepository expose its dependencies explicitly:

public class DinnerRepository : NerdDinner.Models.IDinnerRepository {
    
    private readonly NerdDinnerDataContext db;

    public DinnerRepository(NerdDinnerDataContext db)
    {
        this.db = db;
    }

Note that there are no no-arg constructors to be found! When StructureMap creates a DinnersController, it will look to resolve the IDinnerRepository dependency. That’s a DinnerRepository, which in turn needs the NerdDinnerDataContext. But that’s all hidden from us, we never need to wire up an entire graph, as we would if we stuck to the “new” operator. Just to make sure everything works, I can navigate to view upcoming dinners:

Wrapping it up

In the original NerdDinner code, dependency inversion was only partially implemented as the original controllers still contained a constructor that called a constructor of a concrete class. To fix this, we added StructureMap to the mix, configuring ASP.NET MVC to use StructureMap to create controllers instead of the default controller factory. Finally, we pushed the dependency inversion principle all the way down to our repository, removing the opaque dependencies where we found them. When we finished, all of our classes exposed their dependencies explicitly through their constructor. No one class knew more than one level of depth, and our controllers now properly depended exclusively on the IDinnerRepository abstraction.

In the future, we can add things like logging, policies and the like to custom IDinnerRepository implementations, without needing to change any of our controllers. Once we introduce inversion of control to our application, we open a lot of doors for functionality and simplicity, but only going halfway won’t give us the full benefit.

Python Web Framework Series – Pylons: Part 6 Basic Authorization With AuthKit

Ryan Svihla — Fri, 03 Jul 2009 12:00:00 GMT

Last post we left off with very basic database access, and testing story completed. Now we're going to look at basic Authorization and Authentication with AuthKit. NOTE: most of this post is just an aggregation of a couple of chapters in the Pylons Book since this setup is a good base starting point. Read the previous link to the Pylons Book for more in depth coverage of this topic.

Setting Up AuthKit

First lets make sure we have AuthKit installed: easy_install AuthKit. For this post we're working with AuthKit 0.4.3, your mileage may vary if you read this post in the future and are using a different version. Now that we have Authkit installed open up pylonsforum\config\middleware.py add the following imports:

import authkit.authenticate

from authkit.permissions import ValidAuthKitUser

and then add somewhere inside the if asbool(full_stack): code block.

permission = ValidAuthKitUser()

app = authkit.authorize.middleware(app, permission)

app = authkit.authenticate.middleware(app,app_conf)

in development.ini add this to the end of your [app:main] section

authkit.setup.enable = true

authkit.setup.method = form, cookie

authkit.form.authenticate.user.type = authkit.users.sqlalchemy_driver:UsersFromDatabase

authkit.form.authenticate.user.data = pylonsforum.model

authkit.cookie.secret = secret string

authkit.cookie.signoutpath = /home/signout

Open your home.py controller and for now add a “signout” action:

def signout(self):

    return "You've been signed out"

Now in your websetup.py we have a ton to add to get the basic setup working. Start right after imports and add these line.

from authkit.users.sqlalchemy_driver import UsersFromDatabase

next add the following in your “setup_app” method after load_environment

    from pylonsforum.model import meta

    meta.metadata.bind = meta.engine

    filename = os.path.split(conf.filename)[-1]

    log.info("Adding the AuthKit model...")

    users = UsersFromDatabase(model)

    meta.metadata.create_all(checkfirst=True)

    log.info("Adding roles and uses...")

    users.user_create("admin", password="admin")

For the final piece delete your development.db file and run paster setup.app development.ini to recreate it with the AuthKit user model. Now you have very basic authentication working in your site

http://localhost:5000 reveals:

type in “admin” for the username and password and it should let you pass. Note going back to the site will not bring up a password box again.

http://localhost:5000/home/signout

will remove your cookie and you’ll see the sign in form once more if you go to http://localhost:5000 . Stayed tuned for more posts as I go more in depth with the different features and customizations of AuthKit.

Python Web Framework Series – Pylons: Part 5 Testing Models

Ryan Svihla — Thu, 02 Jul 2009 20:09:00 GMT

UPDATE: was an error caught by Govind (who is turning out to be my unofficial proofreader). I've made a correction in the thread mapping for "dateadded" property in the previous article. If this you are caught up with and error indicating there is no dateadded property on thread make sure to edit your model\__init__.py file to match the previous article and rebuild your db so that everything is happy. Please bear with me as I hone my tutorial writing skill set.

When we last left of with our Pylons forum we had a had just successfully created a post, and then could immediately retrieve that same post. However, we kind of skimped on the testing story so lets fill in the gaps and do some refactoring as a bonus.

Functional Testing Models

Open your functional controller test located at pylonsforum\tests\functional\test_home.py and add the following import line

from pylonsforum.model import Thread, Post, meta

and the following methods

def setUp(self):

    meta.Session.remove()

    meta.metadata.create_all(meta.engine)

    self._createpost(5)

def _createpost(self,times):

        i = 0

        while i < times:

            i = i +1

            thread = Thread()

            thread.subject = "subject " + str(i)

            post = Post()

            post.author = "posting away"

            post.content= ""

            post.isparent = True

            thread.posts.append(post)

            meta.Session.add(thread)

        meta.Session.commit()

and change the test_recent_posts method to

   def test_five_most_recent_threads_show_in_homepage(self):

        response = self.app.post(url(controller="home", action="index"))

        assert "subject 1" in response

        assert "subject 2" in response

        assert "subject 3" in response

        assert "subject 4" in response

        assert "subject 5" in response

In summary here we’re adding a _createpost factory method that generates some basic test threads and parent posts. running nosetests –-with-pylons=test.ini should result in failed tests.

Changing The View and Controller

Now adjust your index.mako view to the following:

<%def name="title()">Pylons Forum</%def>

<%def name="head_tags()"></%def>

<div id="recentposts">

<table>

<thead><tr><th>subject</th><th>author</th><th>date submitted</th></tr></thead>

<tbody>

%for t in c.threads:

    <tr><td>${t.subject}</td><td>${t.parentpost.author}</td><td>${t.dateadded}</td></tr>  <!-- changed posts properties to thread properties and added parentpost -->

%endfor

</tbody>

</table>

</div>

So once you’ve changed the to using a “threads” object, added parentpost (where did that come from? I’ll get to that in minute) and changed our properties around we need to change the our home.py controller index action for our cosmetic changes and to work with our new tests:

 def index(self):

        c.username = "rsvihla"

   # removing this line    c.posts = [Post("jkruse", "New Kindle", "06/24/2009")]

        thread_query = meta.Session.query(model.Thread)

        c.threads = thread_query.order_by(model.Thread.dateadded.desc()).limit(5).all()

        return render('index.mako')

So our index action now is querying for the 5 most recent threads and storing in our new c.threads context variable. Lets strip the query down into pieces.

thread_query = meta.Session.query(model.Thread)

we’re working with SQLAlchemy Session object. We call a Thread Model and then store a Thread query object inside the thread_query variable. Now through the thread_query variable we can get access to the Thread objects stored in the database.

c.threads = thread_query.order_by(model.Thread.dateadded.desc()).limit(5).all()

Here we call “order_by” on our query object and then pass in the Thread model specifying a descending order of the dateadded property. Next we limit it to 5 rows and then call “all()” which returns our results in a nice python “list” object.

Custom Properties on the Model

Ok so back a few paragraphs ago in the index.mako view I stuck in a “parentpost” property on the thread, and I’m quite certain you’re wondering how I did that. So I’ve created the following class tests\test_model.py

from pylonsforum.model import Thread, Post, meta

from pylonsforum.tests import *

class TestThreadParent(TestController):

    def _makethread(self, hasparent):

        thread = Thread()

        thread.subject = "test"

        parentpost = Post()

        parentpost.content = ""

        parentpost.author = "first post"

        parentpost.isparent = hasparent

        childpost = Post()

        childpost.content = ""

        childpost.author = ""

        childpost.isparent = False

        thread.posts.append(childpost)

        thread.posts.append(parentpost)

        return thread

    def test_should_find_parent_post(self):

        thread = self._makethread(True)

        assert thread.parentpost.author == "first post"

    def test_should_not_find_parent_when_none_set(self):

        thread = self._makethread(False)

        assert thread.parentpost is None

Our test has a _makethread factory method (another one of those maybe time for a factory class soon!) which can make a parent post or not depending on its parameter, then two tests documenting its behavior in each situation.

So I’ve gone back to our models\__init__.py class and changed the Thread class to look like this:

class Thread(object):

    @property

    def parentpost(self):

        for p in self.posts:

            if p.isparent == True:

                return p

Not the best method however its VERY interesting for static language veterans. We are searching an instance variable that we have not even defined! Remember only our SQLAlchemy mapper even makes mention of a “posts” variable through our relationship mapping, yet our “parentpost” property is searching through self.posts. Once it finds a parent post it returns true, this is not perfect and again not the ideal way to enforce a database constraint but for a demo it works fine.

Calling nosetests –-with-pylons=test.ini should now give you all passing tests. Running paster serve –-reload development.ini and opening http://localhost:5000 , adding a couple of threads and you should have something that looks like this:

Summary

We’ve completed a home page now that has some dynamic data, added a custom property on our database class, and addressed functional testing with models.

Congrats to the Los Techies MVPs!

bogardj — Thu, 02 Jul 2009 01:03:38 GMT

This morning, I and fellow Los Techies alumni Eric Hexter and Chris Patterson learned that we are MVPs! Well, technically I learned last night through an IM of a re-tweet of my MVP lead, but hey, close enough, right? I know it’s cheesy, but I think these awards are a testament to the great community Los Techies has built over the years, so for me, this is really an award for Los Techies. The roundup includes:

Jimmy Bogard, MVP ASP.NET
Eric Hexter, MVP ASP.NET
Chris Patterson, MVP C#

Personally, I’ve viewed my community involvement as simply a desire to share my journey with others, and in turn learn where others have been and are going. My favorite experiences thus far have been the open space conferences, book clubs, dojos and code camps, as it gives me a great chance to meet and talk with a lot of smart people. Thanks again everyone!

I'm a Microsoft C# MVP!

Chris Patterson — Thu, 02 Jul 2009 00:14:35 GMT

Opening my Inbox this morning resulted in a pleasant surprise from Microsoft. I have been presented with the 2009 Microsoft® MVP Award as a recognition for sharing my expertise in Visual C# with others. It is an honor to be recognized by Microsoft for doing something that I truly enjoy - building really cool software.

Microsoft Most Valuable Professionals (MVPs) are exceptional technical community leaders from around the world who are awarded for voluntarily sharing their high quality, real world expertise in offline and online technical communities. Microsoft MVPs are a highly select group of experts that represents the technical community's best and brightest, and they share a deep commitment to community and a willingness to help others.

A community-based award like this would not be possible without the support of my peers, and I look forward to meeting up with some of those very peers at the next MVP Summit! In the meantime, congratulations to all the new and renewed MVPs!

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.

How we do MVC – View models

bogardj — Tue, 30 Jun 2009 03:06:36 GMT

A while back, I went over a few of the patterns and opinions we’ve gravitated towards on our current large-ish ASP.NET MVC project, or, how we do MVC. Many of these opinions were forged the hard way, by doing the wrong thing many times until we found the “right” opinion. Of course, many of these opinions are only really valid in the constraints of our project. While the domain of this project isn’t important, here are some key aspects to consider:

AJAX is used very, very sparingly. Section 508 compliance is required
XHTML compliance is also required
XHTML DTD validation is also required
All (well, 99%) operations revolve a single uber-entity. Think customer relationship management, where everything you do deals with exactly one customer
Snippets of information repeated across many screens
Screens are either edit, or view, but never both. (99% never)

Given these constraints, these opinions may or may not apply to the project you work on. Again, patterns are all about tradeoffs, benefits and liabilities. But, opinionated software is like building a bullet train. It goes extremely fast, but only in the direction you build it.

That said, I’m going to go over some of the main aspects of our MVC usage in a series of posts – starting with ViewModels.

ViewModel design

For our application, the ViewModel is a central aspect of our MVC architecture. One of the first dilemmas facing MVC developers is to decide what the “M” in MVC means in ASP.NET MVC. In Rails, this is fairly clear, the M is ActiveRecord (by default). But in ASP.NET MVC, the “M” is silent! Its out-of-the-box architecture offers no guidelines nor advice on what the M should be. Should it be an entity? Data access object? DTO? Something else?

Sidenote – the term DTO is far overused. DTO is a Data Transfer Object. The pattern describes the usage, not the shape of a type. Just because an object is all properties and no methods does NOT mean it’s a DTO.

For us, the ViewModel is inextricably linked to Views, which leads us to our first rule:

Rule #1 – All Views are strongly-typed

I think I’ve gone over this one enough, as I really can’t stand magic strings and loose contracts. A dictionary as ViewModel is a very loose contract between the Controller and View. While on rare occasions we still need to pass information in the dictionary part, we’ve limited this to supporting information to help render some of the lower-level pieces of the View, and are used for some “plumbing” pieces, these pieces do not show up in our Controller action nor are they visible when you design the view.

Rule #2 – For each ViewModel type, there is defined exactly one strongly typed View

We’ll get into how we do this soon, but this rule has a lot of implications:

ViewModel types are distinct from our Domain Model types
The choice of what View to show can be decided strictly on the shape of your ViewModel
Re-used pieces in a View (through Partials) can be decided through re-using ViewModel types

On the first point, we never pass an Domain Model entity straight into the view. Most of the time, we only show a slice of information from a single entity. And many other times, the same snippet is shown in many places.

Rule #3 – The View dictates the design of the ViewModel. Only what is required to render a View is passed in with the ViewModel.

If a Customer object has fifty properties, but one component only shows their name, then we create a custom ViewModel type with only those two properties. Because we only have one ViewModel type per View, we shape our ViewModel around only what is displayed (or used) in that View. Why is this a Good Thing?

For one, just having a ViewModel points us to the right View. We need any other information other than your ViewModel type to pick the correct View. This also means we no longer need to concern ourselves with locating views by some arbitrary name, as the ViewModel is the View. Things like RenderPartial, which I have to select a name, become rather pointless at that point.

Rule #4 – The ViewModel contains only data and behavior related to the View

For the most part, our ViewModel contains only data. Most, if not all aggregations/calculations or shaping is done through our Domain Model. But occasionally, we have View-specific behavior or information, and that rightly belongs on our ViewModel.

We’ve looked at how we design our ViewModel and what it looks like, but how does it get there? If we create all these distinct ViewModel types separate from our Domain Model, didn’t we just create a bunch of work for ourselves? We thought so too, which is why we developed AutoMapper on this project.

Building the ViewModel

When we introduced AutoMapper into our MVC pipeline, we had a real problem. Do Controllers need to do the mapping between Domain Model and ViewModel in each action method? That becomes rather annoying for unit testing, as the mapping operation could warp things to a state that it becomes difficult to pull things back out. For example, or EditModels (ViewModels for forms) are very string-y, where DateTimes, Ints, Decimals etc are represented as strings. This comes from us using Castle Validators (future post, I promise) for validation.

So more moving parts, a dependency across all controllers? No, mapping in our Controller action just won’t do. Instead, we’ll use an Action Filter to do the work for us:

A request comes in, handled by an Action. The Action does its thing, ultimately deciding how to respond to the request. In many cases, this means rendering a view (ViewResult). From there, our Action Filter comes into play. On our Action method, we decorate it with an AutoMap attribute to configure the source/destination type pair to be mapped:

[AutoMap(typeof(Product), typeof(ShowProduct))]
public ActionResult Details(int id)
{
    var product = _productRepository.GetById(id);

    return View(product);
}

Very trivial, yes, but here we see that we still use the strongly-typed version of the View method, so that means that our model on the Action side, which I call the Presentation Model (feel free to pick a better name), is the strongly-typed ViewModel for the moment. The Presentation Model, which the Action creates, can be an entity, an aggregate root, or some other custom aggregate component that we build up.

From there, we decorated our action with a filter that specified we need to map from Product to ShowProduct. Why do we have to specify the source type? Well, many ORMs, including NHibernate, rely on proxy types for things like lazy loading. Instead of relying on the runtime type, we’ll explicitly specify our source type directly. This also helps us later in testing, as we can whip through all of our controller actions using reflection, and test to make sure the source/destination type specified is actually configured.

The filter attribute is very simple:

[AttributeUsage(AttributeTargets.Method, AllowMultiple = false)]
public class AutoMapAttribute : ActionFilterAttribute
{
    private readonly Type _sourceType;
    private readonly Type _destType;

    public AutoMapAttribute(Type sourceType, Type destType)
    {
        _sourceType = sourceType;
        _destType = destType;
    }

    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        var filter = new AutoMapFilter(SourceType, DestType);

        filter.OnActionExecuted(filterContext);
    }

    public Type SourceType
    {
        get { return _sourceType; }
    }

    public Type DestType
    {
        get { return _destType; }
    }
}

We simply capture the types and delegate to the real action filter for the work. This is again because I believe in separating metadata in attributes from the behavior they perform. Attributes just don’t work well for behavior. Instead, I’ll create a separate action filter:

public class AutoMapFilter : BaseActionFilter
{
    private readonly Type _sourceType;
    private readonly Type _destType;

    public AutoMapFilter(Type sourceType, Type destType)
    {
        _sourceType = sourceType;
        _destType = destType;
    }

    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        var model = filterContext.Controller.ViewData.Model;

        object viewModel = Mapper.Map(model, _sourceType, _destType);

        filterContext.Controller.ViewData.Model = viewModel;
    }
}

The BaseActionFilter is just a class that implements the various filter methods as virtual members, so I can override just the ones I need to use. The AutoMapFilter pulls the original PresentationModel out of ViewData, performs the mapping operation, and puts the mapped ViewModel into the ViewData.Model property. From there, the strongly-typed view for our specified ViewModel type is rendered.

Because AutoMapper can flatten source types, we often find our ViewModel to simply follow a property chain for various pieces of information. Again, we let our View shape that piece. If we decide not to flatten, it’s usually because we’re creating a partial that re-uses a ViewModel type across other parent ViewModel types.

Wrapping it up

Designing ViewModels is quite ambiguous with MVC, as the shipped platform doesn’t offer any guidance or opinions in that area. But by forming rules around our ViewModel, we can create a path and direction for our innovation. Our rules are designed to strengthen the relationship between the View and the Model, with a concept of ViewModel – a Model designed exclusively for exactly one View.

In the next post, we’ll look at designing our views – for both viewing and editing data, and how we’ve crafted opinionated HTML builders to eliminate a lot of duplication and enforce standardization.

Python Web Framework Series – Pylons: Part 4 Introduction For Database Support With SQL Alchemy.

Ryan Svihla — Mon, 29 Jun 2009 02:54:00 GMT

We last left off with Views with Mako, now Pylons does not enforce on you an ORM at all, so you can use hand crafted SQL if you prefer. However, since I’ve done enough of that for a career or two we’re going to use my Python ORM of choice and the preferred one for Pylons SQLAlchemy.

Where does SQLAlchemy fit in as an ORM?

If you used NHibernate, you should feel pretty close to right at home with SQLAlchemy. If you come from an ActiveRecord, Entity Framework, Subsonic, or even Linq2Sql background this will be a bit more hand management than you are used to. If that is the case, I suggest Elixir (which I’ve heard great things about) or SQLObject (which I’ve used as well and works fine).

Mapping and Setup

There are three different ways to map tables to classes with SQLAlchemy, I will pick the most commonly used one, but will show the other two in a later post. In our PylonsForum project open model\__init__.py and change the file to look like so:

"""The application's model objects"""

from sqlalchemy import orm

import sqlalchemy as sa

import datetime

from pylonsforum.model import meta

def now():

    return datetime.datetime.now()

def init_model(engine):

    """Call me before using any of the tables or classes in the model"""

    meta.Session.configure(bind=engine)

    meta.engine = engine

class Post(object):

    pass

class Thread(object):

    pass

posts_table = sa.Table("posts", meta.metadata, 

		sa.Column("id", sa.types.Integer, primary_key=True),

		sa.Column("threadid", sa.types.Integer,sa.ForeignKey('threads.id')),

		sa.Column("content", sa.types.String(4000), nullable=False),

		sa.Column("author", sa.types.String(255), nullable=False),

		sa.Column("created", sa.types.TIMESTAMP(), default=now()),

		sa.Column("isparent" , sa.types.Boolean, nullable=True)

		)

threads_table = sa.Table("threads", meta.metadata,

		sa.Column("id", sa.types.Integer, primary_key = True),

		sa.Column("subject", sa.types.String(255)),

sa.Column("dateadded", sa.types.TIMESTAMP(), default=now())

		)

orm.mapper(Post, posts_table)

orm.mapper(Thread, threads_table,properties={'posts':orm.relation(Post, backref='thread')})

Not the best table structure and you’re welcome to improve this on your own but I wanted to create a default setup that was easy to read. Lets take a bit to recap the pieces:

def init_model(engine):

    """Call me before using any of the tables or classes in the model"""

    meta.Session.configure(bind=engine)

    meta.engine = engine

Straightforward method here sets up a Session object with the database engine passed into the method. Pylons will call init_model itself when the site is accessed.

class Post(object):

    pass

class Thread(object):

    pass

So a couple of empty classes? Python being a dynamic language can get away with this and just add the properties at runtime. These are the objects we’ll be interacting with when we want to store data.

posts_table = sa.Table("posts", meta.metadata, 

		sa.Column("id", sa.types.Integer, primary_key=True),

		sa.Column("threadid", sa.types.Integer,sa.ForeignKey('threads.id')),

		sa.Column("content", sa.types.String(4000), nullable=False),

		sa.Column("author", sa.types.String(255), nullable=False),

		sa.Column("dateadded", sa.types.TIMESTAMP(), default=now()),

		sa.Column("isparent" , sa.types.Boolean, nullable=True)

		)

threads_table = sa.Table("threads", meta.metadata,

		sa.Column("id", sa.types.Integer, primary_key = True),

		sa.Column("subject", sa.types.String(255))

		)

Ok these table declarations are providing the data definition logic, including some basic relationship, nothing too interesting here post in comments if you have specific questions.

orm.mapper(Post, posts_table)

orm.mapper(Thread, threads_table,properties={'posts':orm.relation(Post, backref='thread')})

Here the orm.mapper calls take the Page and Thread classes and map them with the table data definitions typed in earlier. You can also specify relationships here as we have done in the thread mapping, the properties argument is referencing the Post class and mapping it to a property called posts on the Thread class, while also mapping the other direction and putting thread on the Post class.

Finally run paster setup-app development.ini from the root pylonsforum directory and you should see a bunch of SQL flying by which indicates it has build the database schema for us:

Making Our New Thread Store In The Database

In the interest of space and time I’ll skip the testing story for another post.

Open up controllers\home.py .

Remove the Post class we created several posts ago
under the imports add import pylonsforum.model as model
under the imports add import pylonsforum.model.meta as meta
change the submitnewthread method to the following

Finally run the newthread action

http://localhost:5000/home/newthread

then create a thread

http://localhost:5000/home/submitnewthread

Should be no change in the actual outward appearance of from what we were doing before.

Summary and Recap

This was a very quick and basic introduction to SQLAlchemy and I will do more with it over the next couple of posts, but please add any comments to things I did not make clear. SQLAlchemy and ORM’s in general are a very large subjects and those of us that have used them for a long time tend to forget not all of this was so obvious when we started.