Chad Myers' Blog

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?

To MVC or to WebForms?

chadmyers — Mon, 27 Apr 2009 22:23:26 GMT

In case you haven’t been following it, there’s a sort of blog storm happening around whether or not you should learn ASP.NET MVC (or indeed MVC in general) or stick with Web Forms.

You can follow the storm here:

Rob Connery’s Post (which also has links to some of the progenitor posts)
Joe Brinkman’s Post (which is sort of a response to Rob, plus some extra commentary)

Ok, so now that you’re caught up, I’d like to try to sum up this whole argument with this piece of advice:

Productive Bliss: If you’re happy with WebForms, and feel that it’s delivering you good value and you’re not sure what this “pain” or “friction” is that everyone keeps talking about, then you definitely should stay on Web Forms.

Disappointed Disillusionment: If you generally like WebForms, but you keep bumping into problems (long postbacks, viewstate continually causing issues for you, hard to test, etc, etc), then you should start looking into the MVC pattern in general, and maybe start dipping your toe in some of the content over at www.asp.net/mvc.

Disenfranchised Frustration: Let’s say you came to ASP.NET from PHP, Java, ColdFusion, or some other framework and you like ASP.NET, but you can’t believe how ridiculously hard some tasks are compared to PHP, CF, or some other framework you used. You like .NET and don’t want to go back, but insist there must be a better way, definitely go check out ASP.NET MVC right now.

Diabolical Disgust: If you’re appalled at how tightly coupled, SOLID-violating, and horribly mis-abstracted ASP.NET WebForms is, not to mention how completely impossible it is to write testable code, then you might think about skipping both ASP.NET Web Forms and ASP.NET MVC, going straight to something further like OpenRASTA or even FubuMVC (if you dare).

Virtual ALT.NET Meeting about S#harp Architecture

chadmyers — Mon, 20 Apr 2009 05:24:01 GMT

The VAN is still going strong, thanks to Zachariah Young for all his dedication and hard work! We’re looking for feedback on the format and topics. Please opine on the Virtual ALT.NET Mailing List (they’re up to 286 members now!).

This week there’ll be a speaker: Billy McCafferty on S#harp Architecture. Zach asked if I could post a little something about the upcoming meeting and I’m happy to oblige:

Speaker Bio for this week. Who is and what makes this Billy McCafferty guy tick?
Well he is a long time developer and a hopeless romantic when it comes
to writing beautiful software. Billy currently leads a double life
between helping to run a small training and consulting company known
as Codai (which will be getting a new website very very soon) and
filling the role of lead developer and architect with Parsons
Brinckerhoff. After Billy gets his life back – which should be after
the release of S#arp Architecture 1.0 – expect to see him soon at
ALT.NET and other development conferences.

He will be demonstrating the latest cut of S#harp Architecture 1.0
with a 45-50 minute non-PPT presentation.

Bring your opinions and attention. Questions and Answer will be served
also. The drinks as usual are up to the participants.

Should be a fun evening. See you all there.

Meeting details.

Where and When
Start Time: Wednesday, April 22, 2009 9:00 PM GMT/UTC - 5:00 (CDT)
End Time: Wednesday, April 22, 2009 12:00 PM GMT/UTC - 5:00 (CDT)
Attendee URL:http://snipr.com/virtualaltnet (Live Meeting)

Excelling in a job interview

chadmyers — Fri, 17 Apr 2009 04:12:41 GMT

My friend and co-worker Gary Sherman recently tweeted this and I thought I would share it with you:

How to Nail an Interview:

http://www.howtonailaninterview.com/

(for my English-as-a-second-language friends, ‘nail’ here means ‘to achieve great success’ – the text of the link is sincere, but the videos are most definitely sarcastic)

Oh yeah, one other thing I’d like to mention while we’re on the subject of job interviews: If you’re applying for a professional job, be a professional. Professionals are good at what they do, but above all, they take everything in stride and seek solutions not add to problems. “It takes a gentleman to suffer ignorance and smile”, the saying goes. And so it takes a professional to suffer indignity with patience. No matter how bad that interview went, no matter how idiotic or asinine the interviewer may have been, do not, under any circumstances, send an email to the interviewer like this (sic. exactly preserved):

Sorry that was not an interview. That was big joke, interview are not performed Like that. Interviews are two ways, in the end there is an opportunity given to Candidate to ask question. Any one can write a Blog, it may be something new for you but they are out there for more than fifty years, unfortunately you just learn about them. Keep riding the clock and wasting people's time, after all you don't need to hire anyone. I have been doing this successfully for twenty years and Have plenty of Ave.

- [Applicant for software tester position]

I’m going to need a mop and 3 buckets to clean up the irony dripping from this one.

Virtual ALT.NET Meeting Tonight

chadmyers — Wed, 01 Apr 2009 14:18:32 GMT

Zachariah Young has been rockin’ the Virtual ALT.NET (VAN) meetings for the past several months. There’s been good turnout and good discussions. He’s kicking it up a notch and asking members of the community to present something interesting at each meeting.

This week, Zachariah has asked Yegor Yarko to speak. He joined us in last week's call and was very helpful in answering questions. He will be doing a demo of Team City and also showing us other scenarios using Team City.

Also if you have any other topics or questions about Team City, Yegor has asked that you submit them to the VAN Google group: http://groups.google.com/group/virtualaltnet

VAN’s are Microsoft LiveMeeting events. The details are below:

Start Time: Wednesday, April 1, 2009 9:00 PM GMT -5 (CDT)
End Time: Wednesday, April 1, 2009 12:00 PM GMT -5 (CdT)
Attendee URL: http://snipr.com/virtualaltnet (Live Meeting)

How to apply for a professional job

chadmyers — Tue, 24 Mar 2009 02:34:55 GMT

Think for a good solid 10 seconds before answering these two questions: “What does the word ‘professional’ mean to you?” and “Do you consider yourself a professional?” I’ll wait while you think.

If you answered “Yes” to the second question, then please proceed with this blog post. Otherwise, you’re welcome to continue reading, but the following admonishments do not apply to you. So no hard feelings, OK?

First rule of applying for a professional job

You’re either a professional or not. If you are, act and think like one. Your future job is on the line.

Since you consider yourself a professional, I would expect at least some portion of a high school education (or GED). College is great, but I’m talking remedial stuff: Basic spelling and grammar skills. I would hope these would have entered your realm of knowledge. Now, I know, I make mistakes and misspell things quite frequently on this blog. I should do better. You read my blog because you were likely referred to me by someone else. You have a small reason to give me the benefit of the doubt and assume that I’m capable of spelling and grammar, but I was just too lazy or in a fit of writing to stop and take the time to correct.

If I were applying for a job, however, I would not expect you to give me the benefit of the doubt. You have no reason to trust me or even assume I’m capable of saying my “ABCs,” let alone skillfully accomplishing the professional tasks you set before me as my potential employer. Thus, the only way people will even consider you for a professional position is if you give them every reason to believe you’re a professional. Spelling and grammar mistakes on your cover letter and/or Resume/CV are simply unacceptable. Do not make this mistake. If you can’t handle even this simple task, you might as well go home.

Tips:

Have a peer or two review your letters, resume/CV, and any other artifacts you plan on submitting to potential employers. If you have a mother or father or sibling around, have them look at it, too. Sometimes having a non-technical person review things helps a lot as they don’t gloss over things as easily as someone used to seeing all the key words and acronyms.
If you refer your potential employer to online materials, make sure those are of the highest quality.
If you refer your potential employer to your blog or other personal/semi-professional works, and you know your they have lower quality than your normal, professional works (as is the case with my blog), point this out to your employer and let them know that what your own intentions and expectations of your blog are.

Second rule of applying for a professional job

Find out as much about the job as you can in a reasonable period of time

For crying out loud, take 2 minutes to look up the company and a little bit about them so you can talk intelligently in your cover letter. Who is the CEO? Who is your primary contact there and what role do they play (supervisor, HR manager, etc)? Sometimes that information isn’t available. Try to pry it out of a recruiter or see if you can find other job posting for the same position on other sites and see if any more info is available there. Don’t spend 2 weeks researching – that’s just creepy. But don’t spend 0 seconds either.

If you’re a professional like you say you are, you’re likely going to be at this company for at least a year, hopefully 5 or more. It behooves you to at least have SOME idea what they do so you don’t get halfway through the hiring process only to find out that they are preparing the Earth for an alien invasion or something.

Third rule of applying for a professional job

Take some time to hand-craft a cover letter specifically for that employer and that position

If you don’t care enough to write up a letter for this position and you’re going to use a form-letter or, worse yet, no letter (or just a simple email), then I don’t care enough to hire you. Sorry, go sell “lazy and uncaring” somewhere else, we’re all stocked up here.

Third Rule Clarified #1:

Spell check. Check your spelling. They actually make computers that can check basic spelling mistakes, you know? Oh yeah, and maybe, just once, read through what you wrote before sending it off.

It takes 1 minute to read back through the letter you just wrote. Odds are, you’ll find that you sound like an idiot and you’ll revise it. You’ll sound much better the second time. A third time might do good, but after that you’ll start obsessing over every word and syllable. By the time you’re done you’ll probably end up with a Sonnet and your potential employer’s email server will flag it as spam anyhow. Trust me, spelling and grammar are all that’s necessary. No one will check for your adherence to iambic pentameter (and if they did, you probably wouldn’t want to work there anyhow).

Third Rule Clarified #2:

I have a name. Use it. If you know it, that is. If you don’t know, it use as courteous language as you can.

“Dear Mr. Myers”, “Dear Ms. Smothers”, or even “Dear Sir or Madam” will go far in encouraging your potential employer about your professional abilities. Professionals respect and address other professionals properly. If you are the professional you claim to be, you should know this. Prove it to them through your writing.

Also, I expect some professional courtesy. Simply ending your cover letter with “-Bob” or “-THX1138” is not cool. I’m not your buddy or pal (yet?), so don’t get too familiar with me. Address me properly. End your letter with two blank lines followed by words like “Sincerely,” or “Cordially,” and so forth. Likewise, expect to be addressed properly in return. It works both ways. If they do not treat you professionally in return, then you don’t want to work there anyhow.

Third Rule Clarified #3:

Learn how to write a basic business letter. Most popular word processors have built-in templates!

I’m sorry, but if you don’t even know about some of the basic features of Word or (your favorite word processor), then you’re probably not going to be able to deal with the complexities of SQL Server or the .NET Framework either.

Your letter should look something like the image to the right. Tell me who you are, where you’re from, and what day you wrote this letter. Tell me who you think you’re writing it to. Tell me you’re talking to me (Dear so and so). Tell me what you want to say. Summarize what you just told me. Tell me your feelings in this letter (sincerely, cordially, hostile, livid, etc), and then sign your name or print it again electronically. Finally, if you have any attachments or anything else I should be aware of (resumes, list of references, associated review materials, etc) let me know that they are included or enclosed.

For a cover letter, I’d limit it to maybe two or three paragraphs followed by a small summary paragraph. In these two to three paragraphs, tell me what position you’re applying for, why you want it, and finally why you think you can do it better than anyone else. Let’s be honest with ourselves, if you can’t do that, do you really want or deserve this job in the first place?

Fourth rule of applying for a professional job

Prepare a resume/CV specifically for that job

This rule might also adequately be stated “Don’t waste the hiring manager’s time.” The manager to whom you’re submitting your application has taken the time to list out the things they’re interested in when looking at a candidate. They’ve given you a huge advantage in the hiring process in that you now know what they’re thinking and what they’re looking for. Seize this advantage and tailor your resume to accentuate your skills and experience in those areas where they have indicated interest. Put those skills first, discuss how your experience with those skills is important, list related work experience. When I review a resume, I’m not looking for continuity of work, I’m looking for related work experience. I find myself asking the resume questions such as “Have you worked with skill XYZ in the past 2 years?” or “How much experience do you have with skill ABC?” Later in the hiring process, I may inquire with a candidate about work continuity (to make sure there wasn’t a 3 year stint in federal prison, for example).

The Big List o’ Skills

Also, I’d like to discuss the “big list o’ skills” block anti-pattern at the top of every technical resume. Please don’t list me 50 skills because after 10 I’m likely to think you’re lying or that you don’t take these skills seriously. Show me a few skills that you are *REALLY* proficient at. Do you have some skills at which you consider yourself an “expert” (better than almost everyone else at it)? Show me those. After that, maybe show me a few other skills you have knowledge of but don’t consider yourself an expert. Then stop. Don’t show me a list of things you’ve seen sitting on the shelf before or maybe typed a few keystrokes into. Also, don’t show me your DEC VAX/VMS experience from 1993 or your Lotus 1-2-3 scripting skills from 1992. I don’t care about these and, likely, neither does anyone else.

Work experience

When listing your work experience, keep it short, concise, and to the point. Tell me what your role was (not just your job title, tell me what your responsibility was), how you met or exceeded the expectations of that role, and how you grew as a result. I don’t want your life story, give it to me quick and neat. Next, give me a few bullet points about how you accomplished that. Keep it short! Really, I’m serious. I don’t want your life story, I just want to know how you approached your role and how you knocked problems out of the park. Finally, if there was anything particularly interesting about that job, your role in that job, or some special accomplishment, let me know. It better be interesting and really special or don’t bother mentioning. “Leveraged strategic partnerships to forge a more cohesive success strategy” won’t do. “Doubled efficiency allowing field agents to process twice as many requests in the same time resulting in a four-fold increase in revenue” will do, however. Oh yeah, things like “426 children now have full smiles” or “More than 7,000 puppies were rescued thanks to the technology we developed” will do wonders. Not all of our work has that kind of social impact. If yours doesn’t, then don’t mention banal details. Tell me about how you *really* changed something (revenue and profits, improved people’s lives, helped the planet, etc). If you can’t, that’s OK, but don’t waste my time with boring stuff.

Next you’ll have to deal with the question about how many pages your resume should be. My current thinking goes like this: If you’ve hand-crafted a resume specifically for this job, it’s hard to imagine how you could go over 1 page. Two pages is probably OK, 3 or more is definitely too many. Odds are, your work experience isn’t that interesting that you’d need 3 pages to describe it. If it is, then you’re probably applying for the wrong job and you belong negotiating Israeli/Palestinian Peace or solving world hunger or something. More than likely you’re tempted to write a small novel about each job you were at. Resist this temptation. It sounds harsh, but really few people care about your specific experiences at your former jobs. After they hire you and get to know you, they will hear all your war stories. The resume is not the place for telling your life story. Give it to me short, sweet, and relevant. It doesn’t mean I don’t care about you, but I’m trying to find a new hire now, not a friend. We can become friends later in the process.

Proofing – you are a “professional”, right?

Make sure that you’ve read and re-read your resume. Spell check it and grammar check it. Three times. Then, have someone outside of your expertise area read your resume (your mother, father, friend, niece, anyone). You should have a colleague read it, but keep in mind that they will likely miss the same things you did because they are like-minded. Having someone outside your normal sphere of thought will help you to catch things that your particular perspectives blind you from seeing. Let me summarize this paragraph: If your resume gets to me with a spelling or grammar mistake, that’s *almost* grounds for immediate disqualification. This is especially true if you’re applying for a detail-oriented position like programmer or tester. If you’re applying for a tester position and you can’t even find spelling mistakes in your own resume, there’s no way I’m going to trust you to ensure that the software I write leaves my office defect-free.

Submitting your resume

Finally, when submitting the resume, use the Word document format or RTF. PDF is OK. TXT is so-so, but acceptable. If text, please make sure it’s formatted to be easily printable on a standard A4 or 8.5x11 sheet of paper. That means something like 74 columns and 100-ish rows (I’m not sure on those sizes, please look it up for yourself). It can also be acceptable to send a link to an online resume. If you go the link route, it better be impressive and justify the fact that you didn’t send me an attachment. Let me put it this way: You have inconvenienced me by requiring me to click a link and open my browser to view your resume. It better be worth my extra time. Whatever you do, do NOT send me a link to a Word doc or PDF that I have to download to view. Attach it or host it online. Anything else is bad form. Oh yeah, one more thing on this: If you’re going to attach the resume, make sure you actually attach it! I can’t tell you how many applications I get with no file attached! If you instantly correct it, I’ll give you the benefit of the doubt, but if you don’t realize you screwed up, that’s instant grounds for my surreptitiously dismissing your application. C’mon, if you can’t even figure out email, how are you going to develop or test complex systems for me?

Dovetail Hiring Software Tester/Test Engineer

chadmyers — Thu, 19 Mar 2009 22:12:59 GMT

http://www.dovetailsoftware.com/about/careers.aspx

Dovetail Hiring Senior Software Tester or Test Engineer

Work for one of the most progressive software development shops in the US. We’re building a new software product line using pioneering practices and technologies, such as:

WatiN
Selenium
StoryTeller (acceptance testing framework)
Test-driven development
Continuous integration

Who we’re looking for Dovetail Software is staffing a new team for an innovative software project. We’re looking for someone who can help us achieve the most usable, highest quality software product. We're looking for people who can empathize with the user, question whether functionality actually makes sense. We're looking for people who can flush out defects, inconsistencies, and mistakes in the software. This person should also be thinking about how to automate as much as possible to constantly increase test coverage and enforce quality throughout the development process.

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 tester. We’re hiring motivated people for a terrific opportunity with a team of recognized software development and agile community leaders.

Our development methodology We are an Agile/XP shop. We work in a continuously-improving pipeline mode, not iterations or long crushing release cycles. We have a collaborative relationship with our customers. We place an emphasis on usability and how people interact with our software. We write tests before we write functional code to clarify our design intentions. We automate whatever we can. 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.

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

ALT.NET “Mean” – How do we fix it?

chadmyers — Sun, 01 Mar 2009 19:21:53 GMT

I’m watching the video that Scott Hanselman graciously recorded of the “ALT.NET: Why so mean?” session at ALT.NET Seattle.

I’m rolling my eyes a lot at the discussion because it seems to miss a lot of the basic points and the severity of the minor crisis our industry has been facing for some time (lack of significant engineering discipline, serious academic pursuits, and scientific analysis of success and failure, etc).

If we are mean, or I am mean (which no one has accused me/us of, but I’ll put it on myself), then I ask: What else should we be doing?

The Analogy

Consider this analogy which may best explain how I feel about the situation:

You come home from work some evening and sit down with your daughter who’s writing a story on paper. To your abject horror, all her letters are upside down! Her handwriting is decent, but the letters are all inverted. You decide to pull her out of school and send her to a private school.

Upon interviewing the teachers at the new school, you realize they, too, teach inverted writing. You find out that it’s a new wave of teaching that has caught the education community by storm and most every school is teaching it. The teachers are delighted by this and believe that it’s what the children and parents really want. They’re proud of themselves for having solved so many problems for parents and children. They honestly believe they’re doing the right thing for the kids.

Obviously your first priority is to fix the damage done to your daughter and teach her correctly or send her to a school that does not adhere to this new, objectively wrong philosophy. But what about all the other students now coming up through the school systems being damaged by this harmful teaching?

Sure, all these kids will be able to read and write to each other, but they will be completely functionless in the real world for at least a generation or two. What a travesty! What a crime against an entire generation of children!

The Breakdown

Ok, that’s overly dramatic, I realize and the analogy is a little overboard, but hopefully you get the basic point of everything. Sure you could start trying to rally parents and start teaching children both methods of reading/writing, but you still have your full time job in order to feed your children. How, then, could you ever compete an army of full-time teachers teaching the other method?

Remember, this is an analogy, so we shouldn’t argue the analogy. Yes, there are problems with it, yes it’s overly dramatic, yes it’s only illustrative not completely accurate, etc. I’m not trying to demonize Microsoft, and not everything they’re doing is setting things back, but some things are. Microsoft is not perfect and some of the things they do do not help and, in fact, set things back. Can we at least agree on that?

And what then are people who see the “wrong” things supposed to do with the people who are being ill-affected by the “wrong” things? Let them flounder and suffer? Try to educate them all? Try to stop Microsoft from doing wrong things?

The Result: What to do?

What if Microsoft is doing more wrong things than we can possibly ever hope to keep up with (—NOTE: They’re also doing a lot of RIGHT and GREAT things… don’t get me wrong)? We have full time jobs. Should we quit our jobs to fight against incorrectness?

What if we do try to stop Microsoft from doing these wrong things and, instead, offer feedback and try to correct them before the damage is done? Sounds good. Now, what if some of the folks that are doing wrong things within Microsoft won’t listen, or dismiss the advice and proceed to damage the community?

If we raise awareness of the problem, we’re “mean”. What then?

Worse yet, what if there are others in the community who have some profit-interest (book deals, speaking engagements, lucrative contracts) in seeing the “wrong” technology being released so they can help customers who are unable to use the technology effectively (… because it’s “wrong”!)? What if these people who have conflicts of interest malign us and call us “mean” and tell us to stop being “a**holes” and, basically, to shut up?

The Crux

Should we just sit down, be quite, and allow such horrific waste and loss of productivity persist in our profession?

If not, how should we combat this problem (keeping in mind we have full time jobs as well and have limited personal time to dedicate to this)?