Chad Myers' Blog

“Productization”

chadmyers — Fri, 30 Oct 2009 16:37:08 GMT

I need some ‘wisdom of the crowd’ here.

I’m guessing just about ever single one of you (at least the software developer types) reading this have deployed software to a production environment at least once in your career. One of the products we’re working on is getting near to a major milestone and will start seeing wider deployments than the beta and preview deployments we’ve seen so far. I’m in charge of developing a list of different things we’ll need to do to the product to start wrapping it in a bow for wider distribution and deployment.

What sorts of things, in your opinion and experience, should I be most concerned about? Some of things I have on my list are: Good logging and error reporting, well-defined and practiced strategy for handling updates and patches going forward (including incremental DB schema migration), etc.

I’m also looking for any “Whatever you do, DO NOT do *this*” where *this* is some thing you tried and ended up being a terrible idea or blew up in your face.

If you comment, please keep your advice short and to the point. Though I would encourage you, if you have a funny and/or insightful story to share, to blog and link it back to this post for me and others to read!

Dovetail is Hiring a Junior-to-Mid-level .NET Developer

chadmyers — Fri, 18 Sep 2009 16:26:43 GMT

Come work for one of the most progressive development shops in the US. This is an opportunity to work with some of the leaders in the .NET/C# space including Jeremy Miller and Joshua Flanagan – both senior developers, designers, architects, authors, and open source project leaders -- with tons of experience. We use cutting edge project practices and our testers and information developers are integrated with the development team.

We’re building a new software product line using pioneering practices and technologies, such as:

Test-driven development
Continuous integration
Behavior-driven design
Domain-driven design
HTML, CSS, Javascript (jQuery)
ASP .NET MVC
C# 3.0, .NET 3.5, Visual Studio 2008
SQL 2008
NHibernate 2.x
LINQ2NHibernate
StructureMap
Selenium Core and Selenium RC
StoryTeller for automated acceptance testing

Who we’re looking for || Dovetail Software is staffing a team for an innovative software project. We’re looking for junior- to mid-level software developers with demonstrable C# (preferably .NET 2.0 or later) and HTML/CSS experience (not necessarily ASP.NET, just web development in general). Any experience with test-driven development or automated unit testing in general is a huge plus. Also, participation in the community (attendance of events, avid blog reader + commenter, or maybe you even have a blog yourself) will put you firmly in the running for this position. We’re looking for people that believe learning and continuous improvement are primary responsibilities of a software developer. We’re hiring motivated people for a terrific opportunity with a team of recognized .NET and agile community leaders. If you’re not looking to rocket your knowledge and experience fast, please do not apply!

Our development methodology || We are an Agile shop (Scrum/XP, Kanban for tracking). We work without iterations in a continuous stream of development with frequent releases -- not long crushing release cycles. We have a collaborative relationship with our customers. We write tests before we write functional code to clarify our design intentions. We keep the build clean. We work in an environment that maximizes communication to minimize the volume of spec documents. We build software that can effectively respond to change. We use open source tools where appropriate, and Microsoft tools where they make sense. We have executive support and visibility all the way up to the owner of the company.

About Dovetail Software || Serving companies since 1995, Dovetail Software develops CRM products for global 1000 enterprises. Our product, Dovetail CRM, is a comprehensive customer service and support, logistics management, customer self service, and knowledge management suite. Dovetail is a small company with big customers and great benefits for its employees. Our outstanding compensation package includes company-assisted health, dental, and life insurance, matching 401k, and more.

About Texas || Texas has outpaced every other state in the Union during the recent economic downturn. Texas added more jobs in 2008 than all the other 49 states combined. Texas’ economy continues to grow and lead the country in technology jobs. Seven of the top 25 fastest-growing cities in the U.S. are in Texas (according to the U.S. Census Bureau). The second-fastest growing city in the U.S. is Round Rock, a city in the same metro/commuter area of Austin.

About Austin || Placing second in the Large Cities Creativity Ranking, Austin is recognized as a city with a thriving music scene, ethnic and cultural diversity, endless outdoor recreations, and a great nightlife. It’s a nationally recognized center for technology innovation—home to 3,200 tech companies with 98,000 employees. In 2008, Forbes Magazine rated Austin the #1 fastest-growing large metro area in the US. Austin is a great place to live and work!

Email us and tell us why you’d make a great addition to our team: tech-jobs@dovetailsoftware.com

Chad’s Comment-worthiness Ranking Scale

chadmyers — Tue, 01 Sep 2009 02:15:22 GMT

I try to be fair to commenters and give them a say, even if they’re belligerent and obnoxious as long as their making good points or otherwise contributing to the thread (even if they’re disagreeing with me).

However, every now and then a comment comes along that just screams out DELETE ME. In the past, my criteria was somewhat arbitrary or loosely self-consistent.

What prompted me to write this was the supreme idiocy of the anonymous/pseudonymous poster ‘Philip’ over on Jeremy’s lighthearted “I thought this was funny” post.

This post is for other bloggers who struggle, like I do, in determining when to cut someone off.

I’m going to start with the Celsius model of measuring comment-worthiness. That is, 0 is minimal acceptance of a comment. Anything below 0 is delete-worthy. As things approach –500, that might constitute a permanent IP-ban site-wide. As things approach –1000, it might be prudent to notify other sites to block this IP address and ones like it. As things approach positive 500, they definitely call for a thoughtful reply, or even another post. As things approach positive 1,000, it might be prudent to write a series of posts or to elicit the response from higher authorities and the larger community of bloggers.

NOTE: This list will probably be changing as the days and weeks go on. I may update it again in the future as people suggest things. If you have a noteworthy suggestion, leave a comment or send me an email and I’ll add it with credits to you (and a link if you give me a URL)

So here’s the start of my grading scale:

Positive Effects

+100 Full, real life name used (not just last or first name)

+100 Public contact information left (the commenter’s web site, maybe an obfuscated email address, etc

+50 Private email left (for the blog author and site admins to be able to contact this person if necessary)

+50 for being a registered user on the site, possibly with a real avatar (showing that this person is interested in being a real part of the community)

+50 More than 50 meaningful words

+25 for good humor that is relevant to the post or other commenters

+25 for replying to another commenter in a polite way that contributes (answering a question, furthering the discussion, etc)

+25 per legitimate point made

+25 per significant, legitimate correction made to the original blog post (more than just spelling/grammar mistakes)

+25 for having the gumption to comment in the first place

+10 per legitimate minor correction made

+5 per incorrect correction made, but made politely with good intent

Negative Effects

-1000 (instant ban + warning to other sites) posting links to or direct embeds of pornography, shock links, images, or videos, etc especially extra vulgar ones

-500 (instant ban) for extreme profanity (gratuitous use greater profanity, excessive vulgarity, racism, sexism, or other extremely offensive bile)

-250 per use of greater profanity (the 7 deadly words, vulgar descriptions, or gratuitous use of the lesser profanities)

-250 for personal attacks on the blog author or other legitimate commenters

-150 for personal attacks on a bogus commenter (one who’s significantly in the negative range, but hasn’t yet been deleted)

-100 for use of lesser profanity (not one of the ‘7 deadly words’ except for maybe ''b.s.’ or just the ‘s’ word used without extra flare)

-50 No last name left

-50 No first name left (or a bogus name)

-25 general rudeness and uncharitably interacting with the blog author or other commenters

-25 per incorrect correction, or a correct suggestion made rudely

-10 per bogus or nit-picky correction made, made rudely, or with snark/sarcasm

Is Blogging Dead?

chadmyers — Tue, 01 Sep 2009 01:54:49 GMT

The other day I was at lunch with some folks (I won’t name drop except to give credit for the person who originally brought it up: Jeremy), and he commented that, while is number of RSS subscriptions has actually increased, the volume of daily unread posts has dramatically decreased.

I’ve heard others attribute this to twitter. Also, perhaps the ~~dragging economy~~ rampaging economic recovery could be keeping people extra busy ~~trying to make ends meet~~ dealing with the flood of new shovel-ready business.

For me, it’s been a combination of both. I sort of burnt out, got super busy dealing with family life, found twitter useful for ~~waging all-out argument wars~~ blurting out a few things off the top of my head, ran out of topic ideas that fire me up enough to pump out blog posts I thought were worthy of sharing.

Los Techies is still cranking out a huge volume of content including Sean Chambers’ epic 31-part ‘31 Days of Refactoring’ series. So I’d say that Blogging is not quite dead, but it’s certainly not operating at the same volume and frequency as we say even just 2 years ago.

Did Twitter kill blogging? What are your thoughts?

The usual result of Poor Man’s Dependency Injection

chadmyers — Tue, 14 Jul 2009 18:41:28 GMT

Alternate Title: An IoC Container is a Rich Man’s Factory Pattern Implementation

I ruffled some feathers with my last post on Poor Man’s Dependency Injection (PDMI), so please allow me to clarify further.

The natural progression of using PMDI is this:

You start out using PMDI, everything is fine. It goes really smooth and easy. “What’s the big deal?” you think.
Later, you need to add some functionality. DI makes it easy, but then you have all these “new()” calls lying around. Well, that “new FooRepository()” call that’s being made in 17 places in your code now suddenly changes to “new FooRepository(new ConfiguredSessionSource())”, for example. 17 changes. Not terrible, but not good either.
Later, ConfiguredSessionSource needs to take in some configuration. This is getting out of hand. Making all these changes gets difficult. I know! I’ll write a small factory that will manage the creation of all these objects.
Eventually even the factory gets too convoluted with all the different forms your dependency object graph can take. It’s out of hand now.
You now have to make a choice: Improve your factory implementation and eventually implement a half-baked IoC container, or just use an IoC Container.

Every time I’ve used PDMI (which was a significant number of attempts a few years ago), I ended up at this point. I wrote a few half-baked IoC containers that ended up being more complex than the application itself. The rest of the time, I ended up going the IoC route, even for small apps with less than, say, 10 classes.

It’s my recommendation that you save yourself some headache and go right for the IoC container. Yes, I know it’s new and a little scary, but trust me, once you get the hang of it, you’ll never look back and laugh at all the fuss that’s being made over this. It’s like wearing seat belts: Sure, it’s a hassle the first few times and the perceived benefit is little, but once you start doing it it’s not a big deal and the alternative is not pleasant to think about any more.

One more thing: How small is too small for IoC?

If you have less than “a few” classes and have no expectation this project will grow further. In my experience, every project usually grows and the ones that don’t are the very rare exception.

Once you have more than “a few” classes, the complexity of maintaining the coupling and dependency graph starts growing rapidly and you’ll wish you had an IoC container later. You’ll then spend more time retrofitting in a container than if you had just started out that way. So save yourself some effort and just do it.

Also, since the effort, once familiar with a container, is so low that even if you don’t end up reaping the benefits, the sunk cost of using a container unnecessarily is negligible.

Just say no to 'Poor Man’s Dependency Injection’.

chadmyers — Tue, 14 Jul 2009 14:53:48 GMT

For background, Jimmy Bogard originally posted about the ‘poor man’s dependency injection’ style used in NerdDinner. Not to single out NerdDinner, because there are lots of apps out there doing this. NerdDinner just happened to be the most recent and visible so it serves as a good whipping boy.

Tim Barcz respectfully countered with his post "Why There’s Nothing Wrong With Dependency Injection in NerdDinner.”

I promised Tim a respectful rebuttal to explain why there *IS* indeed something wrong with ‘poor man’s DI.’ That will be forthcoming. For now, though, it reminded me of a post I did on the altdotnet yahoo mailing list awhile back.

Here’s an excerpt from it for your convenience:

Been thinking a lot lately about how to teach about IoC and how to use containers such as StructureMap to someone who either is coming in cold to DI/IoC or has a vague awareness of what it is.
Personally, the stages I went through (and have seen few other people go through similarly) are:

Replace all (most?) new()'s with ObjectFactory.GetInstance<T>. You get some immediate benefit out of this and it opens up some new opportunities for your code, but doesn't even scratch the surface

Move to ctor injection with very explicitly defined instances/pluginfamilies/etc and not using auto-wiring. Maybe you still even have an old-fashioned C'tor that still satisfies its own dependencies for those times when 'you might not be using an IoC container'

Embrace auto-wiring, remove non-IoC/DI c'tors and trust fully the container

Start using more advanced techniques like lifecycle management, profiles, convention-based dependency satisfaction, etc

Auto-registration, full trust of the IoC. Thoughts start to pop up like, 'I wonder if I could get the Container to write my app for me??'

Since I wrote that post, I can now add the following point:

6. Conventional and custom registration. Rather than explicitly registering everything, and more than automatic registration of some things, you develop more complex and conventional ways of registering your objects/services/controllers/etc into the container. You know you’re in this stage when you’re building your own DSL/FI on top of your container’s configuration model to fit your application’s needs better.

Do you have a 7 or 8 you can add?

VAN is a friend of Pablo’s!

chadmyers — Mon, 13 Jul 2009 16:12:56 GMT

In case you haven’t noticed, the VAN logo now appears in our “Friends of Pablo” section. VAN is really taking off!

If you have checked out VAN (Virtual ALT.NET) before, I suggest you run, not walk, to check it out now.

They’ve got a web site, a logo, and official INETA membership. The E-VAN (European VAN) is taking off as well.

There are lots of great people working very hard on making this happen, so you should definitely give it a look!

The home page, which has everything you need to know is here:

http://virtualaltnet.com/

Also, they have a blog: http://virualaltnet.blogspot.com/

The next speaker is Jean-Paul Sylvain Boodhoo (on Weds the 15th). Be sure to check this out. JP always gives a good presentation. If you haven’t seen or heard him speak, you seriously owe it to yourself to try it this time. He’s inspirational, motivational, and just a great guy in general.

The Perfect Web Framework

chadmyers — Tue, 23 Jun 2009 05:32:26 GMT

I’ve been paid professionally to work with or have messed around with many web frameworks. To name most of them:

Perl/CGI
RoR
a tiny bit of Django
ASP.NET WebForms
ASP.NET MVC
FubuMVC
MonoRail
a tiny bit of OpenRasta (sorry Sebastian, I keep failing to find time to dig into this more. I really mean to, I promise!)
Apache Struts
Java JSP
Java Servlets
Java Server Faces
A bunch of other of the myriad of Java web frameworks
PHP
ASP
A bunch more that I can’t remember or aren’t worth mentioning

Each of them offers a little, but at the huge expense of getting in your way a lot of time.

The more and more I use more of them, the more I come to the conclusion that the perfect web framework looks like this:

public string Get(IDictionary<string, string> request)
{
  //TODO: Stuff here
}

How to Write Unmaintainable Code

chadmyers — Fri, 19 Jun 2009 22:05:46 GMT

A friend showed this one to me a long time ago, and I still chuckle every time I remember a snippet or two from it.

How to Write Unmaintainable Code by Roedy Green

Perhaps my most favorite section is the ‘Naming’ section:

http://mindprod.com/jgloss/unmainnaming.html

And within that, lies the pièce de résistance of that entire body of work (in my opinion):

(NOTE: Make sure you check out the 5th bullet point, it’s a real gem)

Hungarian Notation
Hungarian Notation is the tactical nuclear weapon of source code obfuscation techniques; use it! Due to the sheer volume of source code contaminated by this idiom nothing can kill a maintenance engineer faster than a well planned Hungarian Notation attack. The following tips will help you corrupt the original intent of Hungarian Notation:

Insist on using "c" for const in C++ and other languages that directly enforce the const-ness of a variable.

Seek out and use Hungarian warts that have meaning in languages other than your current language. For example insist on the PowerBuilder "l_" and "a_ " {local and argument} scoping prefixes and always use the VB-esque style of having a Hungarian wart for every control type when coding to C++. Try to stay ignorant of the fact that megs of plainly visible MFC source code does not use Hungarian warts for control types.

Always violate the Hungarian principle that the most commonly used variables should carry the least extra information around with them. Achieve this end through the techniques outlined above and by insisting that each class type have a custom wart prefix. Never allow anyone to remind you that no wart tells you that something is a class. The importance of this rule cannot be overstated: if you fail to adhere to its principles the source code may become flooded with shorter variable names that have a higher vowel/consonant ratio. In the worst case scenario this can lead to a full collapse of obfuscation and the spontaneous reappearance of English Notation in code!

Flagrantly violate the Hungarian-esque concept that function parameters and other high visibility symbols must be given meaningful names, but that Hungarian type warts all by themselves make excellent temporary variable names.

Insist on carrying outright orthogonal information in your Hungarian warts. Consider this real world example: "a_crszkvc30LastNameCol". It took a team of maintenance engineers nearly 3 days to figure out that this whopper variable name described a const, reference, function argument that was holding information from a database column of type Varchar[30] named "LastName" which was part of the table’s primary key. When properly combined with the principle that "all variables should be public" this technique has the power to render thousands of lines of source code obsolete instantly!

Use to your advantage the principle that the human brain can only hold 7 pieces of information concurrently. For example code written to the above standard has the following properties:

a single assignment statement carries 14 pieces of type and name information.

a single function call that passes three parameters and assigns a result carries 29 pieces of type and name information.

Seek to improve this excellent, but far too concise, standard. Impress management and coworkers by recommending a 5 letter day of the week prefix to help isolate code written on 'Monam' and 'FriPM'.

It is easy to overwhelm the short term memory with even a moderately complex nesting structure, especially when the maintenance programmer can’t see the start and end of each block on screen simultaneously.

Going Controller-less in MVC: The Way Fowler Meant It To Be

chadmyers — Thu, 18 Jun 2009 07:06:09 GMT

This is sort of a stream-of-consciousness post. Several folks have been asking me what I mean by ‘Controllerless actions’ and what I’m thinking about doing in FubuMVC. The conversation has already started publically on twitter, so I thought I’d try to capture a brain-dump of my thoughts in a blog post so the conversation can continue. This post likely won’t be up to my normally high (read: barely legible) standards. Please forgive.

Before we go further, read this:

http://www.martinfowler.com/eaaCatalog/frontController.html

And then view this:

public class ProductController : Controller
{
    private IProductRepository _repository;

    public ProductController()
    {
        /// That is the only point you need to replace
        /// if the data source changes.
         _repository = new EntityProductRepository();
    }

    public ProductController(IProductRepository repository)
    {
        this._repository = repository;
    }

    public ActionResult Index()
    {
        return View(_repository.GetAll());
    }

    public ActionResult Create()
    {
        return View();
    }

    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult Create([Bind(Exclude = "Id")] Product productToCreate)
    {
        if (_repository.Create(productToCreate))
            return RedirectToAction(“Index”);

        return View();
    }

    public ActionResult Edit(int id)
    {
        return View(_repository.Get(id));
    }

    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult Edit(Product productToEdit)
    {
        if (_repository.Update(productToEdit))
            return RedirectToAction(“Index”);

        return View();
    }

    public ActionResult Delete(int id)
    {
        return View(_repository.Get(id));
    }

    [AcceptVerbs(HttpVerbs.Post)]
    public ActionResult Delete(Product productToDelete)
    {
        if (_repository.Delete(productToDelete.ID))
            return RedirectToAction(“Index”);

        return View();
    }
}

I’m pretty sure this ProductController is not exactly what Martin Fowler had in mind. Yet, it’s probably an actually cleaner example of what most controllers that are currently being written “in the wild” for ASP.NET MVC and MonoRail (the two most popular MVC frameworks for .NET) look like.

ProductController is a somewhat monolithic controller in that it has many actions. It’s structured this way for several different reasons, a few of which I’ll list here:

The limitations of the framework upon which it’s built. ASP.NET MVC, MonoRail, FubuMVC, and others are structured around controllers and actions (yes, even the venerable, estimable Ruby on Rails [peace be upon it] has this mindset to one extent or another).
The limitations of our imaginations: That’s how we’ve always done MVC!
The habit of doing Model2 style MVC (from which the Heavy Controller/Action paradigm comes)

Reading Fowler’s ideas on Front Controller, and looking at these Model2-esque controllers and actions, I scratched my head and said, ‘Huh. That isn’t right!’

Model 2

Model2-style MVC is concerned primarily with whole request handling and/or whole page rendering. This was OK in the days of non-AJAX whole page post-backs (uphill, both ways, in the snow, with bare feet). But in the modern day of heavily templated, composite UIs (think ASP.NET WebForms MasterPages, Spark Layouts, Partials, etc), and with heavy AJAX use for browser-initiated partial updates, the whole-page rendering concept doesn’t really hold up.

We usually end up contorting and bending the framework to do things that don’t really hold up that well under the Model2 way of thinking.

Front Controller

In the Front Controller pattern, the only “Controller” present is the dumb front controller that has two methods on it: Get() and Post() and you could probably just boil those down to HandleRequest(). If this sounds oddly reminiscent of IHttpHandler, you’re thinking correctly. An IHttpHandler is, in one manner of speaking, a Front Controller. Properly implemented, the Front Controller would load a series of commands for that particular URL/request context and then execute them either via round robin or via chain-of-responsibility (in serial).

In ASP.NET MVC, MonoRail, FubuMVC, and several other MVC frameworks for .NET, the Controller Action is essentially one BIG command that handles almost all aspects of the request. Action Filters and FubuMVC’s Behaviors serve as a way of achieving the more compositional benefits of Commands, but they both have some limitations.

If you’ve been doing any serious MVC work with any of the popular frameworks recently, you will have certainly felt the pain of controller actions getting too large, or having too many concerns. You may also have noticed that your views require data that’s otherwise totally unrelated to the current request (i.e. the user’s current login status for a request to retrieve a list of all products in the persistence store). So you might use Action Filters or FubuMVC Behaviors to compose all the data the view will eventually need. Action Filters, being attributes on the Action and thus explicitly declared, present a strong challenge to proper compositional assembly of the data needed by the view for that request. FubuMVC behaviors certainly handle this better, but the configuration can get a little messy and verbose wiring them up explicitly or even conventionally to your actions. So they are not without their drawbacks also.

This all leads inexorably to the questions: Why even have a controller at all? Aren’t actions really just things-to-do in their own right? And aren’t Actions only a part of the responsibility of fulfilling the request (the rest being satisfied by Action Filters/Behaviors)?

What if we promoted that idea of action filters/behaviors, and the stuff-to-do-for-this-request to equal footing – each simply being a command that gets executed for a particular request?

There’s one little tiny problem in that, when in your Master Page, for example, you may need one tiny nugget of information that’s completely unrelated to the current request, but otherwise needs to be satisfied. Rendering the view, then, becomes yet another command that can actually trigger more commands to be executed.

Explicitly Configured combined with View-Driven Command Resolution and Execution

After several talks with folks like Mark Nijhof, Jeremy Miller, Jimmy Bogard, and others, it soon became clear that we needed to rethink how we were approaching our MVC-based designs and to try to get more in touch with our “Inner Fowler” so to speak (but not too much).

I have observed that there are, in any MVC request, explicit things that need to happen (NHibernate Session-per-Request, load the current IPrincipal for ASP.NET Authorization, load the current user’s culture and timezone information, etc). There are also things that MAY need to happen based on whether the View needs some particular type of information. The view generally shouldn’t be making decisions other than to simply declare that it needs a partial rendered (or a MasterPage, etc). Theoretically with WebForms or Spark views, we could, at config-time, figure out just exactly what information the view and its various partials are going to require. This way you could resolve everything at config-time and avoid any nasty runtime problems with missing information and such. I’m somewhat down on this theory and I’m anticipating this won’t work out like I hope and that there will always be runtime gotchas here.

At any rate, if we have to live with runtime surprises while we flush out this idea, that’s OK for right now. But I really feel that the general idea (that is, demand-based command execution) is going on the right track.

Explicitly Configured Command Resolution and Execution

This one is easy: Just configure it! We’ll have a fluent API or some sort of conventional way (or both) of automatically determining which commands need to be executed for a given request/URL. FubuMVC currently has this with behaviors so this is achievable today, but I think we can do better and I intend to.

View-Driven Command Resolution and Execution

This one is a little tricky since the View will be requesting this at render time, on-the-fly and may result in YSOD’s if something it depends upon isn’t available.

I’m thinking that the View would have access to the IoC Container (or Common Service Locator as the case may be) and will request something like IFubuCommand<TModel> where TModel is the particular type of model that partial requires. So you might see something like this:

<%= this.RenderPartialFor<LoginStatusModel>().Using<LoginStatusPartial>() %>

The RenderPartialForExpression would then access the IoC container and retrieve an implementation of IFubuCommand<LoginStatusModel> and then pass that to the LoginStatusPartial (which may turn around and request other IFubuCommand<XYZ>’s.

Command Registration

Commands would be registered at config-time via the normal IoC container configuration. Using StructureMap, for example, you would simply scan all or certain assemblies for any class implementing ICommand<TModel> and load them automatically into the container as handlers.

Diagnostics

This is also somewhat complicated since the views may request different things at runtime (they may request an IFubuCommand<MODEL> where MODEL may not be known until runtime in which case things may go awry.

You could probe the Container for all IFubuCommand<TModels>’s and then simply observe Views as they execute and deliver a report after-the-fact to show what was used, by whom, and how much. While this won’t necessarily be exhaustive, it would likely help a developer who’s troubleshooting a particular issue (or perhaps a transient, occasional error).

URL Resolution

This is perhaps the biggest change. Since there are no controllers or actions, the URL becomes the only distinguishing characteristic between two “actions” (or chains of commands) to be performed server-side. That means the URL (or URL stub like /blah/baz/{Id}) becomes a first-class citizen – probably even its own class/type.

One thought I’ve been kicking around about this is that you would have a class per URL Stub which has c’tor parameters or properties representing the various options of the URL. For example, consider this “URL object” or “Action object”:

public class EditProduct
{
  // /products/edit
  public EditProduct()
  {
  }
  
  // /products/edit/9
  public EditProduct(int id)
  {
    Id = id;
  }
  
  public Id{ get; set;}
}

And to render a hyperlink to this action, for example, you might: <%= this.LinkTo<EditProduct>(Model.ProductId) %>

or even: <%= new EditProduct(Model.ProductId) %>

Which is a lot cleaner than: <%= this.HyperLinkTo<ProductController>((p,i)=>p.EditProduct(i)) %>

Wrapping Up

So this is my brain dump and currently the rough plan I’m using to spike out some of these things in FubuMVC. Some of it is working out, other things I’m still skeptical.

I’d love to hear what you’re thinking with your MVC-based designs. How are YOU handling the composition problems?

On the performance of “Opinionated Builders”

chadmyers — Sun, 14 Jun 2009 05:35:36 GMT

I was reading Eric Hexter’s post titled “Opinionated Input Builders Part 6: Performance of the Builders” and I was going to leave a lengthy comment, but decided it would be better as its own blog post:

I’m going to assume that the data is all correct (or representative of reality). As another reader pointed out, this [poor performance] could simply be because debug=true is set in the web.config or some other non-obvious, but simple explanation. For this exercise, let’s assume that this performance is the correct reality.

Since [Eric’s] approach is very opinionated and conventional, I would expect it to result in very consistent and expected results (code written in the same way, files in the same place, etc).

This consistency is key because you could write some sort of pre-compiler that could inline the partials or something before pushing to production.If there isn't already a tool to do this, I would imagine it wouldn't be that hard to write.

"But now I have to write a tool to do what ASP.NET could do for me already! This input builder stuff just ain't worth it!" a skeptic might say.

But consider this: Doing it WITHOUT input builders may slow you down 20% vs. doing it WITH them (I’m just making numbers up here, but you get the point). Over an 8 week project with 4 people (1280 man-hours), that's a savings of 256 man-hours. I'm pretty sure that you could easily write some sort of in-liner or pre-compiler in 256 man-hours (6.4 man-weeks) and you'd end up with either a net-zero or a net-gain on the project.

I'm of the firm belief that you do what's expedient for the project (YAGNI unless you're absolutely certain you WILL NEED it), and deal with performance issues later in a systematic way. Performance problems are always easier to deal with later and with more data from which to make a better decision and especially so if you're consistent and conventional in your development (which Opinionated Input Builders certainly are).

So for those who might immediately turn their noses up at Eric’s posts due to suspected performance issues, I suggest you at least give it a second look or give it a little time as an optimizer might show up later, negating most if not all performance issues.

Some quick updates

chadmyers — Wed, 10 Jun 2009 03:41:26 GMT

I know I’ve been remiss in my blog posting duties. Please trust me when I say it’s for good reason and that you’d understand.

I appreciate you sticking with me. In the meantime, here are a few tidbits that you might find worth noting:

Announcing: Zen

Nate Kohari (whom I’d like to call a friend, though I’m not sure he feels the same way, lol) has just announced the coming-out party of a skunk-works project he and his wife Nicole have been cooking up for quite some time now. It’s a lightweight (but powerful) lean project management system using Kanban. Nate can describe it better, so I’ll let you hear it straight from him:

Zen Home Page: http://agilezen.com

Nate’s Blog post: http://kohari.org/2009/06/09/zen-and-the-art-of-project-management/

Side note: I’m taking votes for who has more attractive eyewear Nate or Nicole.

Steven Bohlen speaking for VAN on DDD

Zachariah Young wanted me to let ya’ll know that Steven Bohlen (of “Summer of NHibernate” and “Streaking through campus naked” fame) will be presenting about Domain-driven Design at the next VAN (June 10).

The details for attending are here (I suggest you check it out!):

http://zachariahyoung.com/zy/post/2009/06/08/Introduction-to-DDD-with-Steve-Bohlen-on-June-10.aspx

Site note: His “streaking on campus” days are over, to be clear, there will be no streaking at the VAN)

.NET Slackers Article on StructureMap 101

After many broken promises and terrible delays, I finally delivered my first article to the ever patient, polite, and positive Sonu Kapor (one of the organizers of www.dotnetslackers.com).

You can check it out here:

http://dotnetslackers.com/articles/designpatterns/IntroductionToStructureMap.aspx

Lifecycle of an open source project

chadmyers — Thu, 28 May 2009 16:58:05 GMT

I’ve had several people ask me about the state of various open source projects that I’m involved with or advocate. They ask questions such as “Is it alpha or beta?”, “Should we start using it?”, and “Where can I get started learning more?”.

I find these questions difficult to answer since they’re very relative and subjective depending on your environment, tolerance for change, tolerance for bugs, issues with “bleeding edge” technology, etc.

In an effort to try to come up with a more objective framework for answering these types of questions, I decided to take a stab at putting into words my experience with various frameworks and how they have progressed in their lifecycle.

Phase 1: Concept

Some ideas have been kicked around by a few people. Some spike code has been written. A project site is up (Google Code, CodePlex, etc) and there is maybe a working prototype to show off and talk about. Definitely no documentation, wiki, or anything like that. There may be a blog post or two about the concepts.

Phase 2: Bootstrap

There are one or two serious authors/committers. There might already be one or two actual users experimenting with the framework. The build is continually in a “works on my machine!" state. Some more blog posts have been done and maybe a wiki with a few articles, but otherwise no docs to speak of.

Phase 3: Early Development

A few more committers have signed on, but still there is only one or two primary contributors. A few more users have started playing with it now and are providing feedback. A mailing list has certainly been set up by now, if not earlier. The build is more stable and works in many environments. More blog posts and wiki articles have emerged, but still no serious documentation effort yet.

Phase 4: Early Adoption

More committers are signing on now and contributing more and more. The project is at a state with many of the baseline features are done and the product is quite usable now. There are a few dozen users experimenting with it and even building some interesting applications upon it. Multiple people are blogging about it. The wiki is starting to materialize into categories and sub-topics. Some sparse documentation has started to emerge in the form of some limited API docs and some FAQ’s and getting started guides.

Phase 5: Development

There are several devoted committers now, cranking out serious features and functionality. There are dozens of users – approaching 100 or more. There is an automated (nightly?) build. Binaries are available for download regularly. Many people are blogging about it and buzz is growing. The wiki is really taking shape and being fleshed out. At this point documentation is “moderate” and is growing into more scenarios and topics.

Phase 6: Adoption

Many people are submitting patches and other forms of contributions. The inner circle of committers is growing. There are more than 100 users, perhaps several hundred. There are frequent “point” releases available for download. There’s now likely a basic installer which helps configure your environment for the framework. Frequent, in-depth blog posts by noted authors. The Wiki is now very rich and there are frequent contributions. Documentation at this point is “adequate”. You would likely start seeing “contrib” projects sprouting up here and there and coalescing .

Phase 7: Maturity

There are so many patches and contributors that a hierarchy has been set up to evaluate and approve changes. Multiple releases creates management issues with patches and defects requiring more organization. There over a thousan users by now and like thousands. There are releases and installers for various scenarios (maybe x86/x64, or a Mono compatible release, etc). There is lots of documentation activity and many contrib projects have emerged.

Phase 8: Mainstream

By now, many of the original contributors have moved on or are less involved. A new generation of contributors have taken over and are taking the project into different directions and expanding it greatly. There are hundreds of thousands of users. Perhaps there are even consulting companies forming business services around the project and offering commercial support. There are now multiple “dot-oh” releases. There is no doubt this project is here to stay and provides real value to people. The project has its own active web site with lots of content, guides, add-ons, forums, blogs, etc.

Austin CodeCamp ‘09: Quite Possibly Better than Bacon

chadmyers — Sun, 17 May 2009 21:13:11 GMT

You should go to Austin CodeCamp ‘09.

That’s a pretty sensationalistic title, I’ll give you that. I’m very serious though, Austin CodeCamp ‘09 may actually prove to be better than bacon and even -- yes, I’m going all the way here – cookie dough ice cream! LosTechies’ very own Eric Hexter and John Teague have put in some late nights getting this shindig together (and possibly other people – leave a comment please if you were involved, don’t be shy!) and they’ve done a bang-up job.

LosTechies will be there in force

The Fraternity of the Donkey (or, in the future, the Universal Order of the Donkey should we ever manage to convince a blogger of the female variety to post here) had the idea that many of us would pitch in and do a bunch of CodeCamp sessions.

Many of us love the Central Texas region (specifically Austin and San Antonio) and we love ADNUG and Austin CodeCamp. We wish to see these things continue in the future, so we’re going to present as much as we can.

You can see here that there is quite an illustrious list of available sessions. Eric Hexter has posted the results of the voting and it looks like we’re going to have really good turnout.

Check out what the Los Techies crew has in store for you at the end of May:

Sneak peek at C# 4.0 – Jimmy Bogard (1 hour)
Git for people – Joe Ocampo (1 hour)
Project Automation – Learn about Build and Deployment Automation – Eric Hexter (2 hours)
S.O.L.I.D. Software Development: Achieving Object Oriented Principles, One Step At A Time – Derick Bailey (2 hours)
Designing Views in ASP.NET MVC – Jimmy Bogard (1 hour)
Put your MVC Views in Hyperdrive with T4 Templates – Eric Hexter (1 hour)
Search Enabling Applications with Lucene.NET - Ray Houston (2 hours)
Test Driven JavaScript – John Teague (2 hours)
Introduction to FubuMVC – Chad Myers (2 hours)
Introduction to Scrumban – Joe Ocampo (2 hours)
Enterprise Architecture Patterns: Presentation, Business Logic, and Persistence – John Teague and Chad Myers (2 hours)
Decoupling Workflow From Forms With An Application Controller And IoC Container – Derick Bailey (2 hours)

Twenty Hours!

I dunno about you, but all of these presentations look like awesome presentations in their own right, but coupled together, they present a mighty, unstoppable force of knowledge enhancement! No? Too much? Ok, how ‘bout this: Unless my math is wrong, that’s TWENTY (20, ONE SCORE) information-packed hours presented by experienced, leaders in the industry.

I need some peer review on this

chadmyers — Tue, 05 May 2009 04:21:00 GMT

So I have a problem where I have an open type:

public class ThunderdomeActionInvoker<TController, TInput, TOutput> 
    : IControllerActionInvoker
    where TController : class
    where TInput : class, new()
    where TOutput : class
{
    /*...*/
}

And I need to make a generic one of these bad-boys and then “new” it up. The only problem is, I don’t know whether my candidate/proposed type for TInput meets the “class” and/or “new()” constraints. There doesn’t appear to be a Type.TryMakeGenericType() method and calling MakeGenericType() blindly will toss you up a nice fat ArgumentException to catch.

I did some cursory searching, but my Google-fu has failed me this day. Is there nothing to do this? If not, then I scrapped something together and I wanted to see what you all thought of this just in case I’m really the first person to have needed this. I haven’t fully unit tested this (this was a spike, so I didn’t test-drive this… I know… SHAME), so don’t just COPY AND PASTE this or bad things will happen including 7 years bad luck and maybe some rain coming in through your windows.

public static bool MeetsSpecialGenericConstraints(Type genericArgType, Type proposedSpecificType)
{
    var gpa = genericArgType.GenericParameterAttributes;
    var constraints = gpa & GenericParameterAttributes.SpecialConstraintMask;

    // No constraints, away we go!
    if (constraints == GenericParameterAttributes.None)
        return true;

    // "class" constraint and this is a value type
    if ((constraints & GenericParameterAttributes.ReferenceTypeConstraint) != 0
        && proposedSpecificType.IsValueType )
    {
        return false;
    }
           
    // "struct" constraint and this is a value type
    if ((constraints & GenericParameterAttributes.NotNullableValueTypeConstraint) != 0
        && ! proposedSpecificType.IsValueType)
    {
        return false;
    }

    // "new()" constraint and this type has no default constructor
    if ((constraints & GenericParameterAttributes.DefaultConstructorConstraint) != 0
        && proposedSpecificType.GetConstructor(Type.EmptyTypes) == null )
    {
        return false;
    }

    return true;
}

Thoughts? Obvious bugs?