Jeff's Junk

Silverlight 3 and Twitter

Jeff — Thu, 09 Jul 2009 23:08:00 GMT

The Twitterworld or (Twittersphere or whatever silly shit someone made up today) was all abuzz about the release of Silverlight 3 today, and I was shocked at how quickly it made the trends and how overwhelmingly it was positive.

I kind of knew it was coming already for various reasons (spelled NDA), but it makes me happy to see how excited most people are. I think that individually, the new features have been of average importance, but together, this is a really big deal release. My own pet excitement is attached to the out-of-browser feature, and to a lesser degree the H.264 support, but again, it's an overwhelmingly positive reaction.

But of course the haters are, well, haters. There's a lot of noise and hate on Twitter in general, which is why I fire up Tweetdeck once a week and then let it go for a week after that. The militant Adobe and anti-Microsoft camps started their douchebaggery before anyone ever installed the plugin (let alone the dev tools).

What bothers me the most is that it's a sad reflection on our profession. Platform/language zealotry is like a toxic substance that trivializes what we do. I've had a number of gigs where I happily let go of other projects based on Orcale, Java or whatever because they made sense for the situation. My job was to integrate and connect and ultimately make someone more money, and that's what mattered. If the platform met the requirements, I had to roll with it regardless of what I thought of the vendor or people doing the work. Why is that so hard for some people to deal with?

For the record, I'm pretty excited about Silverlight 3, and its new capabilities immediately bring some uses to mind. I recently deployed a small app to one of my sites for limited use, and install stats went from 25% to 35% in a few days. That's encouraging.

304 Your images from a database

Jeff — Wed, 01 Jul 2009 04:58:00 GMT

I was reading somewhere about some anecdotal evidence that Google doesn't like to index images that don't have some kind of modification time on them. When I relaunched CoasterBuzz last year, I moved all of my coaster pr0n to the database, and I've since noticed that none of the images are in fact indexed. Bummer.

This also pointed out to me that I was doing something annoying. I was reading the data out every time for every image request. Not exactly the most efficient use of resources. Static files come down with information in the headers indicating when they were last modified (IIS, and presumably any other Web server does this), so the next time the browser makes the request, it the server compares the time in the request header with that of the file, and returns a 304 "not modified" response, and no file.

That seemed like an obvious thing to do, even if it has no impact on Google indexing. Fortunately, it just required some refactoring of the IHttpHandler I had doing the work.

Sidebar: This is probably the point at which some people will make a big stink about serving images out of a database, and how it's bad for performance or scalability. That's a fine argument to make, but outside of doing obviously stupid things, this is not an issue here. I'd prefer to address performance and scalability problems if I have them, not when I might have them, or never have them. Seriously, this is a site that does somewhere between a half-million and a million page views a month depending on the season. There are no performance issues here.

So anyway, assuming for a moment that "photo" is a business object in this code, and it was determined by a query value to the handler, this is the meaty part of the ProcessRequest() method of the handler:

if (!String.IsNullOrEmpty(context.Request.Headers["If-Modified-Since"]))
{
    CultureInfo provider = CultureInfo.InvariantCulture;
    var lastMod = DateTime.ParseExact(context.Request.Headers["If-Modified-Since"], "r", provider);
    if (lastMod == photo.SubmitDate.AddMilliseconds(-photo.SubmitDate.Millisecond))
    {
        context.Response.StatusCode = 304;
        context.Response.StatusDescription = "Not Modified";
        return;
    }
}
byte[] imageData = GetImageData(photo);
context.Response.OutputStream.Write(imageData, 0, imageData.Length);
context.Response.Cache.SetCacheability(HttpCacheability.Public);
var adjustedTime = DateTime.SpecifyKind(photo.SubmitDate, DateTimeKind.Utc);
context.Response.Cache.SetLastModified(adjustedTime);

Yes, it probably needs to be refactored, and yes, it should probably be used in an IHttpAsyncHandler. But let's go through what's happening, starting at the bottom.

The last few lines write out the actual bytes of the image (MIME type was set in previous code), then set the cacheability and the modification time of the image, which in my case is stored with the bits. The goofy part is where we create a new DateTime to make its kind known. If you don't explicitly state that it's a UTC time, the SetLastModified() method apparently adjusts it. I happen to store most times as UTC, so that was one less thing to worry about. This adds a header in the response called Last-Modified, and gives it a value that looks something like "Sun, 22 Jun 2003 16:27:19 GMT" (note that it truncates milliseconds and ticks, as you may expect).

Now, on subsequent requests for the same image, the browser adds an If-Modified-Since header to the request, with the same date and time as the value. Here we're checking to see if the value is present on the request, and if so, let's see if we should do a 304. If it's there, we parse it into a DateTime and compare the time with the one stored in the business object. We're stripping off the milliseconds because the database will fill them in on our DateTime, and the incoming request doesn't have the same high resolution. If we have a match, we send out the 304 and return, not sending any more data or reading the bytes from the database.

You can do this pretty easily in ASP.NET MVC as well.

public ActionResult Image(int id)
{
    var image = _imageRepository.Get(id);
    if (image == null)
        throw new HttpException(404, "Image not found");
    if (!String.IsNullOrEmpty(Request.Headers["If-Modified-Since"]))
    {
        CultureInfo provider = CultureInfo.InvariantCulture;
        var lastMod = DateTime.ParseExact(Request.Headers["If-Modified-Since"], "r", provider).ToLocalTime();
        if (lastMod == image.TimeStamp.AddMilliseconds(-image.TimeStamp.Millisecond))
        {
            Response.StatusCode = 304;
            Response.StatusDescription = "Not Modified";
            return Content(String.Empty);
        }
    }
    var stream = new MemoryStream(image.GetImage());
    Response.Cache.SetCacheability(HttpCacheability.Public);
    Response.Cache.SetLastModified(image.TimeStamp);
    return File(stream, image.MimeType);
}

Let me start by saying that this was something I just prototyped. It's in dire need of refactoring, as much of the logic isn't stuff you'd normally put in a controller action. I think there's a method for returning nothing on the Controller base, but I don't remember off the top of my head. If there is, you'd use that instead of Content() in the 304 case.

I hope this helps someone out!

Caught in a flesh storm, with a 90% chance of satisfaction

Jeff — Tue, 30 Jun 2009 19:05:00 GMT

This makes me laugh, in light of tech pundits who overstate the importance of Twitter.

The Colbert Report

Mon - Thurs 11:30pm / 10:30c

Jeff Goldblum Will Be Missed

www.colbertnation.com

Colbert Report Full Episodes

Political Humor

Jeff Goldblum

The Colbert Report

Mon - Thurs 11:30pm / 10:30c

Biz Stone

www.colbertnation.com

Colbert Report Full Episodes

Political Humor

Jeff Goldblum

Webforms vs. MVC, the desire to rewrite everything, an unexpected benefit

Jeff — Wed, 24 Jun 2009 02:16:00 GMT

I read a good post today about the silly wars that go on in versus debates, in this case the arguments about whether to use Webforms or MVC for ASP.NET. I kind of saw this storm coming when people started describing themselves as part of the alternative "movement" in the ASP.NET community.

The truth is that MVC gets me really excited, for a thousand different reasons. My win comes from the fact that I feel like I'm no longer fighting the statelessness of the Web by conforming to a framework that simulates statefullness. Maybe I never really realized I was doing that. But the nice thing about MVC is that it has forced me to break down what I'm doing into simple actions. There are two benefits developing that I had not previously considered.

The first is that the stripped down nature of the MVC pattern causes you to back off if you're someone who does UI development. It can be argued that many of the apps out there now that get all of the press and attention are ridiculously simple and easy to use because they don't try to do a lot, and, by no coincidence, happen to be developed on another MVC framework, Rails. Whether it be Twitter or my wife's favorite site, Ravelry, there is a simple style that seems representative of sites developed using this design pattern.

The second benefit is that adhering to a strict seperation of concerns, whether it be for reasons of testability or the desire to decouple your pieces parts as much as possible (or because "they" said so), makes your code infinitely easier to maintain.

That said, when bouncing back to a Webforms project, I'm amazed at just how much cleaner everything I write is in terms of keeping the moving parts minimally coupled to each other. It's not that I had 10,000-line code-behind files before, but my mindset has changed enough since spending time in MVC that I'm a better developer now when using Webforms.

And when all of the crazy zealots go on and on about how awesome MVC is, I'm not writing that image gallery control for the hundredth time, because I did it once years ago. The simple content management apps, handlers and diagnostic pieces are all there still for me to use, and now I'm wiring it all together in a much cleaner way.

I love MVC. I mean I really dig it. I can't wait to get some of my projects based on it out into the open (other than my personal blog, anyway). But the truth is that the value already built into years of ASP.NET Webforms is not trivialized or bested by the new framework. Instead, there's a great compliment in place now where I can use which ever gets me to market the fastest. At the end of the day, rewriting things for the sake of science doesn't get me paid. Shipping stuff is what puts food on the table. Now my toolbox is a lot bigger.

Silverlight request: Make it work for iPhone apps

Jeff — Sun, 21 Jun 2009 21:38:00 GMT

Obviously Silverlight runs on OS X. That much we know, since developers like me use it for non-development tasks instead of Windows. How difficult would it be to adapt it to stand-alone apps on the iPhone? Even if it had to include the runtime and base library (at a few megabytes), it would still be pretty cool, and we wouldn't have to use Xcode (which I'm not impressed with).

The joy of learning and surprise

Jeff — Wed, 10 Jun 2009 19:44:00 GMT

I just read the JJ Abrams essay in the previous issue of Wired. This essay really struck home about where we get joy out of life, and how we seem so eager to overlook it. This quote sums it up for me:

"True understanding (or skill or effort) has become bothersome—an unnecessary headache that impedes our ability to get on with our lives (and most likely skip to something else). Earning the endgame seems so yesterday, especially when we can know whatever we need to know whenever we need to know it."

That is true on more levels than I can describe. While the Internet has done so much to facilitate communication and bring people together, it has also managed to trivilaize knowledge and the process of acquiring it.

I liken this to a suggestion that a friend made to me last year when I was in the midst of writing code for one of my sites. He asked, "Why don't you just use all of the free stuff out there and stictch it together to make a site?" Aside from issues of integration, I asked what I would get out of that as a developer. The "skill and effort" is important to me. Deeper understanding is important to me. It's the same reason someone may build a table instead of buying one from Ikea. Indeed, sometimes the end product is less interesting than the journey required to get there.

ASP.NET MVC book: Not going to happen (for now)

Jeff — Wed, 10 Jun 2009 02:51:00 GMT

After a great deal of soul searching (and a PDF draft of chapter 1 posted), I've decided that I'm not going to follow through on this book. I've got a total of four chapters, two of which are at 75%, but there are a number of reasons that I've decided to focus my attention elsewhere.

The biggest issue I have right now is that I don't see an obvious personal benefit to following through at this time, especially when I compare it to other projects. Since I'm essentially "self-employed," and foresee that as a lasting condition for some time given the sad job market, I really want to pour more energy into things that look and smell like income. Self-publishing, for all of the benefits, doesn't pay up front the way an advance does through a mainstream publisher and, you know, I like to eat and do summer stuff.

I've also had a lot of fun in the last two months tweaking and analyzing my existing Web sites. CoasterBuzz is doing very well, with page views up 20%. I've been shooting video and photographing rides for the site too, something I love to do but kind of let go of over the years. I'm really getting back in touch with the stuff that motivated me to get into software in the first place.

Perhaps most important, I'm getting back into some basic level of fitness. I'm married again, and I have to look after myself for someone else's benefit as well. The nasty high stress crappy job I lost really had me pushing aside just common sense eating and exercise, and I want to make sure I'm balancing all of that out.

The content I've written so far will not go away, and it will see the light of day one way or another. Perhaps it'll appear as a finished book for a future release, or as a series of long Web pieces. I haven't decided. The simple blogging app used as the example code will be released as well, probably sooner than later (in part because I'm hell bent on proving that 95% of what you want to do can be achieved by 10% of the average "best practice" or "sample" app).

This wasn't an easy decision, especially given all of the wonderful feedback I've received so far (and even some outright hate mail). At the end of the day, I need to chase what gets me out of bed, and unfortunately, this just wasn't it.

Personal blog moved, powered by ASP.NET MVC

Jeff — Fri, 05 Jun 2009 00:08:00 GMT

I moved my personal blog to a more appropriate domain name, JeffPutz.com. Hooray for vanity names! I'll continue to keep technical and programming junk here. It seemed appropriate though to have a central location for me stuff, including my resume and various media samples, so this is it.

This is the first MVC app that I've put into production, oddly enough. Well, technically it is, though I've supervised the development of MVC apps elsewhere. This little app is what I've been writing my next book around, and it is purposefully as simple as possible. Most of the sample apps I've tried to disect are entirely too complex, and I think that's a barrier for a lot of people. I'll post the code after I've put it through the paces a bit.

Can you afford to blow off a part of your audience?

Jeff — Tue, 02 Jun 2009 02:46:00 GMT

The other day, me and Diana were talking about the concept of "supported" browsers, and how big corporations often restrict their online applications for use only with certain browsers. This is a throwback to the days when you needed ActiveX or certain IE-only features, and is rooted in old school corporate IT nonsense.

But there are still a lot of financial institutions in particular that keep telling you what browser to use, and that's just stupid. I was looking at the stats for my sites today, and it shows that 15% of visitors are Mac users, and only about 55% are IE users. Even the iPhone is closing in on 1%, which is crazy.

That's the world we live in. If you blow off 15% of your audience, can you afford that? Imagine if Amazon did this. Their holiday quarter did $225 million in profit. Do you think they'd be OK with leaving $33 million on the table?

I ran into another support issue today, when trying to view the video clips for the Halo prequel and the body control stuff for Xbox. I'd love to watch them, but they use some goofy stream that's presumably Windows Media based and I can't watch them on the Mac. Technologist apologists seem hell bent on declaring that this kind of thing is OK, but especially for marketing intent, why would you exclude any percentage of your audience?

I'm not suggesting we all need to test for IE6 at this point, but come on man... with the standards and frameworks we have, it isn't that hard to reach 99% of your audience.

Twitter FAIL

Jeff — Wed, 27 May 2009 19:14:00 GMT

And productivity of nerds everywhere skyrocketed! :)

Google Ad Manager: FTW!

Jeff — Wed, 20 May 2009 02:07:00 GMT

It doesn't seem like there are a lot of .NET developers out there who build their own stuff for their own sites, and if there are, they don't blog. But I know they're out there!

So if you have your own sites, and they're primarily a content endeavor, then you know that managing advertising is kind of a pain. There's the ad network chaining, and then things get crazy when all of a sudden you sell some campaigns on your own. Suddenly you need some way to deliver those ads, and the options have been to either roll your own solution, rent some service or buy software.

All of those solutions have a down side, especially in terms of cost. I first built my own solution circa 2005, and even put out a very rough beta of it. That's as far as it went. It didn't have any significant reporting, but it did deliver ads pretty well with frequency capping and what not. It wasn't a retail-ready product, but it was serving me well enough.

But it couldn't geo-target, do really sweet reporting and it was never tested beyond a handful of campaigns at a time. I looked into buying a third-party product, or using services, but they were all way too expensive for the volume I was doing. So my solution has been serving since then, mostly mixing remnant ads from various networks.

Along comes Google and they start offering Google Ad Manager. I've used some of the online services before, which vary from usable (the old old pre-Google DoubleClick) to downright horrible (Atlas), as well as some of the purchased products (most expensive of which was Open AdStream, also purchased back in the day). I've also used the publisher default management of everyone from Federated Media (awesome) to Burst and Casale (decent) to Tribal Fusion and ValueClick (sub-optimal). I've seen more ad platforms than any one person should, and the only one that did what I really wanted was my own, if you don't count the lack of reporting.

"GAM," as they call it in the video and WebEx, makes sense. From the set up perspective, it has "slots" that are the physical postion of ads, and placements, which in turn can be any combination of slots. It's a many-to-many relationship. So you can group various slots together to form units that correspond to sites, sections or whatever. These can be further combined into products, which are optional, but an easy way to package a frequent or common buy. The UI around these might be a little confusing at first, but once watch their video clips, it makes sense.

To put ads into these slots, you create an order. An order basically is just a name and flight dates. Order have line items, which indicate a delivery priority (more on that in a moment), the cost type (CPM, CPC, CPD), targeting, frequency caps, and most importantly, the placements where the ads will go. At that point, you can upload Flash or image creative, third-party HTML/script, etc. It will match creative sizes to the available placement sizes.

Once you get that cascade of entities, it's actually really smooth sailing. The big strength comes in the fact that the delivery priorities are so flexible. At the top is exclusive delivery, which takes precedent regardless of cost unit. Premium and standard are the regular serving of campaigns, smoothed out in delivery frequency based on quantity, caps, targeting, etc., only premium trumps standard in priority. Remnant and house priority are, as the name implies, delivered when the others have no ad to serve, and your ad networks fall into the remnant category.

So what does Google get out of this? Well obviously they want it to be easy for you to run AdSense ads, whenever it makes sense. If you've ever just plugged AdSense tags into a site template and let it serve, you know the payout can be miserable, depending on your content. However, there is some optimized magic here. You can enable AdSense by slot. Then you give your remnant ads a "value CPM," which is like a virtual CPM for AdSense to compete with. For example, say I set up a Tribal Fusion order as remnant ads, and I set the line item for my 300x250 placements at $1.00. Now when it comes time for an ad to be served, Google determines if it can serve AdSense ads that, over time, would yield a higher CPM than $1.00. If it can, then it serves an AdSense ad, otherwise, it goes with the remnant campaign, in this case the Tribal Fusion ad. The result is that it only shows AdSense on a particular page if it knows that it can score more cash than the virtual CPM you specified.

I did a week-long test of this on one ad position, and once it had some time to serve tens of thousands of ads, it turned out that the AdSense CPM was in fact higher. But there is less waste because on the pages that wouldn't generate very good AdSense ads, it allows the remnant (ad network) stuff to show through, which for me is generally CPM and not CPC like AdWords. It surprisingly works really well!

The only issue I've encountered, and really it's not a deal breaker, is that I can't set weights for different remnant orders or line items. You can only set manual weighting among creatives in a specific line item, which is something you'd probably not do in a regular campaign since it optimizes to show more of the creative that has a stronger click-through. For an independent publisher, this is not likely a big deal, since you probably have a chain of ad providers that show as default to one another, based on their ability to pay out.

Overall it's a well thought out product, and it makes me want to sell more of my own ads! Again, I understand that Google's intention is to get you running more AdSense, and they win the business because it removes the biggest objection I always had: Too much waste that diluted the overall CPM of any given page on my site.

ASP.NET MVC book: Chapter 1: Plumbing

Jeff — Fri, 08 May 2009 18:27:00 GMT

ASP.NET MVC: From Webforms to MVC
by Jeff Putz

The following is a barely-edited draft from the forthcoming book
that will explore Microsoft’s ASP.NET MVC framework from the
view of a traditional Webforms developer. This chapter goes over
the basic plumbing of the framework, while subsequent chapters
will be more focused on the typical use cases that every developer
encounters, and how they relate to their Webforms analogs.

Again, this is a draft, so read with caution. You can find updates on
the status of the book, which will likely be published early summer,
2009, at the following locations:

http://weblogs.asp.net/Jeff/

http://twitter.com/jeffputz

Download a more formatted version in PDF form... it's much easier to read!

Feedback is welcome, especially if you find something that is outright incorrect. Thanks for reading! Did I mention the PDF version is easier to read?

EDIT, Previously:
Introduction

The M, The V, The C and Other Plumbing

We explained in the introduction what MVC is, the model-view-controller
pattern. Let’s get to a quick and dirty example to see it in action.

Hello kittehs

As a tribute to those illiterate captioning cats on the Internet, why don’t we
quickly build an application that gets the names of cats and displays them. We’ll
fire up Visual Studio, choose a new ASP.NET MVC Web Application from the
File -> New Project menu, and get to work immediately. For now, we’ll skip
creating a test project.

If we take a peak in the
solution explorer, we’ll see
all kinds of goodies created
for us. You’ll immediately
notice that there are several
folders that correspond with
the three facets of our
pattern, Models, Views and
Controllers. This is
where the app expects to
find the pieces by
convention, much in the
same way that it expects to
find compiled assemblies in
the /bin folder or themes in
/App_Themes.

You’ll also notice some
other folders for content and
scripts. The former is for
things like images and style
sheets, the latter is intended
for scripts. This project
template is good enough to
add both the jQuery library
and the ASP.NET AJAX
files for you.

Figure 1.1: The new MVC project generated
by Visual Studio.

--sidebar

You might be wondering if you’re stuck putting all of your code in
this structure, but rest assured, it’s not required. Most of the teams
that I’ve worked with break out all of their code into one or more
library projects, compiled into their own assemblies. All of your
model and controller code can go in separate projects, just make sure
that the MVC project references the other projects. You do lose the
convention-based association between controllers and views (we’ll
go over that momentarily), but that’s far from being a deal breaker.

--/sidebar

If you look a little closer, you’ll also notice that the Views folder has subfolders
that correspond to the names of the C# files found in Controllers. This allows
you to return views without having to explicitly choose them. That will be
obvious once we flesh out our simple example.

The Views folder contains .aspx files that make the views. They also may contain
.ascx files, which are known as partial views. They act somewhat like the user
controls you’re used to in Webforms, but they’re used in a different way.
Furthermore, it’s critical to understand that these views are not a one-to-one
mapping with URL’s in your app. There is no /views/home/index.aspx to view. If
you look at the web.config file found in the Views folder, you’ll notice an
HttpHandler is set up to block the direct viewing of these files entirely.

Before you start scratching your head, think back to our first description of how
MVC works. Incoming requests are routed to controllers, which based on some
logic, return a particular view. The missing link is the routing table, which takes
the URL of the request and hands it off to a controller. The routing table is
established in global.asax, so let’s take a peek at what the project template has
put there. The default is shown in Listing 1.1.

In the world of MVC, global.asax is used as the location for establishing the
route table, a special collection object used to map requests to controllers. The
RouteTable class has a single static property, Routes, of type
RouteCollection, used to store these mappings. It has the typical methods for
manipulating a collection, and a class of extension methods
(RouteCollectionExtensions) adds two other important methods,
IgnoreRoute() and MapRoute(). These do exactly what you expect, forcing
the MVC routing engine to ignore certain URL’s and send others to certain
controllers.

--sidebar

This is a very quick overview on routing. ASP.NET MVC is
extremely extensible, and you can do a lot with custom routes,
constraints, custom view engines, etc.

--/sidebar

Listing 1.1: The default global.asax file

using System.Web.Mvc;
using System.Web.Routing;

namespace HelloKittehs
{
public class MvcApplication : System.Web.HttpApplication
{
    public static void RegisterRoutes(RouteCollection
routes)
    {
      routes.IgnoreRoute("{resource}.axd/{*pathInfo}");

      routes.MapRoute(
        "Default",        // Route name
        "{controller}/{action}/{id}", // URL with parameters
        new {controller = "Home", action = "Index", id = ""}
          // Parameter defaults
      );

    }

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

The first line of our RegisterRoutes() method tells the engine to ignore the
.axd pieces typically found in an ASP.NET application, like script handlers and
the trace page. The second one sets up the default route, using one of several
overloads. The comments generated explain what each parameter does. The first
is a name for the route, in this case, “Default.” The second parameter outlines the
URL structure by naming parameters that will establish the route, including the
controller name, the action to call on the controller and an ID to pass along. The
final parameter creates an anonymous type with the default values for the route
parameters. Following this convention, a request for “/home/getcat/3” will route
the request to the HomeController class, call its GetCat action method and
pass in “3” as a parameter.

--sidebar

Not familiar with anonymous types? They’re a key feature of C# 3.0
and essential to using LINQ, and to serialize JSON for AJAX calls.
An anonymous type creates a class with the properties you declare,
without the formal declaration of a named class. The anonymous
type in Listing 1.1 creates a class with controller, action and id
properties.

--/sidebar

One final thing to note in the default generated code, is the presence of a
Default.aspx page. Its code behind class creates and executes an instance of
the MvcHttpHandler class, which according to the routes just established will
execute the HomeController and call its Home method, since those are the
default values we established. That code is there so Internet Information Services
(IIS) knows what to do with a request that has no path.

Let’s get to our simple app. Delete the three folders under Views, but leave the
web.config in place. Delete the AccountController.cs file under
Controllers. Now that we have a clean start, right-click the Models folder and
add a new class file called KittehNames.cs. We’re going to write a
ridiculously simple method to return names, and you can see it Listing 1.2.

Listing 1.2: KittehNames.cs

namespace HelloKittehs.Models
{
public class KittehNames
{
    public static string[] Get()
    {
      string[] names = new [] {"Cosmo", "Emma", "Gideon",
"Oliver"};
      return names;
    }
}
}

There isn’t anything remarkable about this method at all. It exists solely to return
an array of strings. Naturally you could also return an array or List<T> of
objects that offered more detail, like the cat’s gender or age, but we’ll keep it
simple with strings.

Let’s move on to the controller. So as not to change that which has been
generated for us, we’ll use the HomeController class, but remove the About()
method. We’ll replace the contents of the Index() method and the result will
look like Listing 1.3.

Requests routed to the HomeController class, taking the Index action, will
execute the Index() method. Controller actions return ActionResult objects,
which come in many derived forms, but for now we’ll stick to the ViewResult.
The System.Web.Mvc.Controller base class includes helper methods to
return results, including the View() method, which we have in our action here.

The only line we have added is one to retrieve the cat names, and add them to
ViewData property, a dictionary objet and member of the Controller base class.
Returning a call to the View() method, with no parameter, tells the controller to
look for a view in the Views folder, under a subfolder that matches the name of
the controller, Home, and an actual view file that matches the name of the action,
in this case Index.aspx. If it can’t find the view in the path
“/Views/Home/Index.aspx,” it will look in “/Views/Shared/Index.aspx.” These
naming conventions are built in to the MVC framework.

Listing 1.2: KittehNames.cs

using System.Web.Mvc;
using HelloKittehs.Models;

namespace HelloKittehs.Controllers
{
   public class HomeController : Controller
   {
      public ActionResult Index()
      {
         ViewData["AllKittehNames"] = KittehNames.Get();
         return View();
      }
   }
}

We deleted all of the views, so let’s create one now. To create one that follows
the naming conventions, right-click on our call to the View() method, as shown
in Figure 1.2. Uncheck the boxes and click OK.

Figure 1.2: Adding a view from a controller action.

The view is created with the path “/Views/Home/Index.aspx,” because it’s being
called by the HomeController class from the Index() action. Let’s fill it out
with Listing 1.3. The bold piece is new.

Listing 1.3: /Views/Home/Index.aspx

<%@ Page Language="C#" Inherits="System.Web.Mvc.ViewPage" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Index</title>
</head>
<body>
<div>
    <p>
      <% foreach (var name in ViewData["AllKittehNames"] as
string[]) { %>
        <%= name %><br />
      <% } %>
    </p>
</div>
</body>
</html>

This view is about as simple as it gets. We’ve added a loop to cycle through all of
the values from the ViewData entry we added in the controller. Note that we use
the as keyword to indicate the type of the dictionary entry we’re calling. If the
object can’t be cast to the type indicated, it’s treated as a null. This is different
from a straight cast, which will throw an exception when the cast fails. That’s an
important consideration when choosing how you perform the cast.

Note the subtle, yet different syntax for executing code and for resolving a value.
Code execution happens inside of the <% %> block, while values are resolved and
output from the <%= %> block.

Figure 1.3: The default view, rendered.

If you run the site, you’ll get the results in your browser shown in Figure 1.3.
Because of the routing set up in global.asax, you can point the browser to
“/home/index” as well.

To recap, here’s what happens when the request is made to the server:

• The routing to a controller and action is determined. In the case of
“/home/index,” or the root of the site (which is handled by
Default.aspx), the routing table determines that MVC should
instantiate the HomeController class and call its Index() method.
The naming convention take the “home” and adds “Controller” to
determine the class name of the controller.

• The framework makes an instance of the HomeController, calling its
default constructor. We did not explicitly write one, but the compiler
makes it for us.

• The correct action method is called. The method must return a derivative
of ActionResult. In our example, the Index() method is called.

• Logic is performed as needed in the action method, but it should be
limited to handling input or, in this case, preparing data for output in the
view.

• The action method returns a view for rendering to the browser. Without
any parameters, we’re creating an instance of a view by naming
convention.

• The view executes its display logic, and uses data sent to it by the
controller.

The great thing about this arrangement is the separation of concerns we’ve been
talking about from the start. The model, view and controller can all execute
without having to know anything about the internal processes of each other. This
is especially helpful for testing purposes, and we’ll get deeper into that later.

Models

The model part of MVC in the strictest sense refers to the data infrastructure for
your application. It’s the stateful part of your app, where real things are stored. In
the broader sense, the Models folder of your MVC app ends up acting much like
/App_Code, because your application logic goes here. It can also live in external
libraries, compiled projects that have no dependency on your application.

The most common set of tutorials you’ll see on models for MVC involve the
creation of data entities that map to a database technology, usually SQL Server.
We’ll go deeper into that in the next chapter.

However, it’s important to note that one of the key benefits to using ASP.NET
MVC is the ability to test the snot out of as much of your application as possible.
In that sense, solid designs that code against interfaces, combined with mocking
frameworks, make it easier to test your model code. Stay tuned for more on that.

Controllers

The System.Web.Mvc.Controller class is the basis for the magic glue that
bridges application logic and data (models) with the presentation of a user
interface (view). You’ve already seen how a request is mapped to a specific
controller. It should also be obvious that the controller must inherit from the
Controller base class.

By convention, these controllers must be named with the “Controller” suffix. So
or example, requests routed to the “Admin” controller require that the controller
class be named AdminController.

The second part of the routing equation calls a specific action method on the
controller class. These methods must have a return type of ActionResult. This
abstract class has ten derivatives (if you count the PartialViewResult). You
don’t need to create specific instances of these result classes, but can use the
helper methods that come free with the Controller class:

• View() – This is the most common helper you’ll use, as it returns
instances of the views that you create. It has several overloads, the
simplest being one that takes no parameters. It will look for a view that
matches the name of the action. So if your action is named Cat and your
controller class is AdminController, it will look for a view called
Cat.aspx in /Views/Admin. If it can’t find it there, it will look in
/Views/Shared. There are additional overloads that allow you to
return a specific view and even specify a certain master page. By
passing an object in to View(), you can bind data to a strongly typed
view, as we’ll see in the next section.

• Redirect(), RedirectToAction() and RedirectToRoute() –
This set of methods and their various overloads do exactly what the
names imply. There are times when you don’t want to return a view, but
send the user to some other location. The regular Redirect() is about
the same as Response.Redirect() in Webforms. The other two take
a variety of parameters to send the user to a specific destination based
on the controller, action and route you specify. The helpful angle is that
you don’t need to know what the actual URL is, and if you change the
routing, you won’t have a hard-coded (and broken) URL in your code.

• Json() – The secret sauce to quick AJAX enriched Web apps is
JavaScript Object Notation, or JSON. This light-weight data format is
deal for sending short messages back to the client, and requires no
special parsing or processing in the browser. You can pass in any
serializable object to this method. We’ll be talking about it extensively
in a later chapter.

• JavaScript() – Returns, believe it or not, some JavaScript.

• File() – This one has some of the goodness you would expect from a
straight IHttpHandler in the Webforms world. You can pass it
Stream objects and byte arrays and specify the MIME type of the
response. This is ideal for returning images or documents.

• Content() – This is the best choice for returning string content. It too
allows you to specify the MIME type.

We can limit the kinds of requests that come in to controller actions with special
attributes, but we’ll cover those along with the use cases that match their use.

The Controller class also has several properties to get at the objects you would
typically find as part of System.Web.UI.Page, like Request, Response,
HttpContext and User.

--sidebar

As is the case with a lot of classes in the framework, there are many
members to explore, and we’re not going to mention them all.
Fortunately, they’re easy to Google by simply searching for the
class, like “system.web.mvc.controller class.” It’s even faster if you
have http://msdn.microsoft.com/ bookmarked.

--/sidebar

Views

The views you create with .aspx file names are not pages, in the strict sense of
the word. You should think of them as, well, views on data! Several different
URL’s can eventually route to controllers and actions that serve up the same
views, so there is not a one-to-one relationship between the URL and the view.

At the very least, a view is any HTML that you choose. Using a series of helpers,
we can cause additional markup to be rendered around data that we pass through
to a view from a controller action. This results in what appears at first to look like
classic ASP, but it’s not. As a rule, there should be absolutely no logic in the
page unless it has something to do with the display (or validation) of data. You
would never calculate tax or make a database call from a view. On the other
hand, it’s OK to decide whether or not to display a block of HTML based on
whether or not the user is logged in.

--sidebar

Hardcore computer science people may engage in some level of
debate about what data is OK to act on. For example, checking
Request.IsAuthenticated definitely isn’t rooted in the data populated
by the controller, but it’s a common sense way to do things. My
advice: It’s a not a religion, so if it doesn’t violate the separation of
concerns by creating a difficult dependency, don’t lose sleep over it.

--/sidebar

HTML helpers create form tags, user interface elements, links and other useful
stuff for rendering in your views. The class used for this is
System.Web.Mvc.HtmlHelper, augmented by several classes full of extension
methods. Because all view pages inherit from the ViewPage class, you can use
its Html property to access these helpers. In the next chapter, we’ll demonstrate
how many of these helpers are used.

There are also a great many methods for use in the AjaxHelper class and its
extension methods.

While ViewPage does inherit from the traditional Page class, most of what you
find there is not relevant to an MVC view. The HTML helpers and straight forms
do not participate in the event or postback model, so avoid getting into the events
you’re used to using in Webforms.

There are several new properties that you will want to take note of.

• Html – As mentioned previously, this property accesses the wealth of
the HtmlHelper class and its various extensions.

• ViewData – Remember our simple example that rendered cat names?
This property is your one-stop access to the data assigned in the
controller.

• ViewContext – This property give you access to ViewContext, which
is a derivative of ControllerContext. It gives you access to the
Controller, HttpContext, RequestContext, RouteData and
TempData. Be careful when accessing these objects so as not to create
any dependencies on specific controllers.

• Ajax – Provides access to the AjaxHelper class and its extensions.

Views can also be strongly typed. ViewPage and ViewUserConrol (the class
used for partial views, later in this chapter) have a generic descendent that tie the
view to a specific model. Visual Studio will automatically set this up for you in
the create view dialog, which we’ll use later. We can rewrite our original view
and controller action method from HelloKitteh as shown in Listing 1.4

Listing 1.4: Strongly typing the view, and passing a model to it

HomeController.cs
namespace HelloKittehs.Controllers
{
   public class HomeController : Controller
   {
      public ActionResult Index()
      {
         var names = KittehNames.Get();
         return View(names);
      }
   }
}

/Views/Home/Index.aspx
<%@ Page Language="C#"
Inherits="System.Web.Mvc.ViewPage<String[]>" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
   <title>Index</title>
</head>
<body>
   <div>
      <p>
         <% foreach (var name in Model) { %>
            <%= name %><br />
         <% } %>
      </p>
   </div>
</body>
</html>

The changes we made are in bold, as compared to Listings 1.2 and 1.3. We’re
passing an object to the controller’s View() method, which is designated as the
model for the view. The view itself inherits from a generic version of ViewPage,
in this case, ViewPage<String[]>. You can use any type you like here,
including complex types that encapsulate any number of different data items. If
our view were more complex, the Intellisense in the page would generate
whatever properties and methods are found on the model when we type a period
after it, because the Model property is an alias to the type you’ve designated in
the @Page declaration.

--sidebar

The cool thing going on here is that instead of a dictionary object
like ViewData, we’re enforcing some very specific contracts
between the controller and the view. Pulling stuff from the
dictionary isn’t as safe and there’s no warning at compile time about
whether or not the data will be there. It makes testing a lot easier too,
because your controller methods return strongly typed data. That
said, it may not be appropriate for every case, and you can still use a
combination of a strongly typed view and ViewData.

--/sidebar

Under the hood of ASP.NET MVC

Let’s step back for a moment to talk about what’s going on under the hood,
especially since we glossed over the notion that there is no one-to-one
relationship between URL’s and views.

In a traditional Webforms application, a request comes into the Web server,
Internet Information Server (IIS), and does one of two things, depending on the
version of IIS. If it’s IIS 6, the server determines that the incoming request
should be handled by ASP.NET, usually because of the file extension, like
.aspx. If it’s IIS 7, ASP.NET already has access to everything coming in.

Next, ASP.NET checks web.config’s HttpHandlers section to see what class
should handle the request. If no entry is found, it checks at the machine level,
which says that .aspx requests will be handed off to
System.Web.UI.PageHandlerFactory, a class that implements the
IHttpHandlerFactory interface. This class looks at the URL of the request,
and serves up the appropriate instance of a class that implements
IHttpHandler. As you may guess, this will be your page, which inherits from
the Page class (which implements IHttpHandler). From there, all of the
familiar things happen inside your page.

If you’ve never implemented an IHttpHandler class yourself, the premise is
pretty simple: Make something to send back to the browser. At its most basic
level, it provides access to the stream that is sent out by the server to the client.
One of the most common uses that I’ve encountered is to send the bytes that
together make an image that is stored in a database. You set the MIME type, put
the bytes in the output stream, and enjoy.

--sidebar

It’s true, you can do the same thing in the Load event of a page, but
you’re creating all of that overhead and baggage that comes with
creating a page. Remember, a page is just a really robust
HttpHandler. It’s easier and more efficient to strip it down and
implement your own for something like serving an image.

--/sidebar

Understanding how a request is handled, you’re empowered even in Webforms to
break the notion that a request must map to an actual file. You might build an
application with a handler that intercepts URL’s like “/news/371.aspx” and
creates an instance of the page of your choosing using
System.Web.UI.PageParser.GetCompiledPageInsance(). At that point,
there’s no going back to thinking of your app as a series of pages, but rather an
application!

It’s not hard to figure out what’s going on with MVC once you have this
knowledge either. The differences are, however, noticeable between the two
versions of IIS. In IIS 6, an .mvc file extension is mapped to ASP.NET, and
handled by an HttpHandler specified in web.config. The reason for this is that
IIS 6 by default treats ASP.NET as a subsystem that runs as an ISAPI module
(Internet Server Application Programming Interface). We’re not going to get into
it here, but as the name slightly implies, it’s a way to plug in pretty much
anything into the server’s request/response pipeline. So now a request ending in
.mvc is routed to ASP.NET, and new entries in web.config in turn map it to the
right handler. If you want to work without these nasty file extensions, you can
simply set the wildcard map in IIS 6 to send all requests to ASP.NET.

IIS 7 integrates ASP.NET much closer to the Ethernet port on the server, so to
speak. That means that configuration files are considered immediately. The
system.webServer section of web.config allows you to adjust the plumbing
without having to set configuration properties in the IIS control panel.

This probably has you wondering how ASP.NET MVC knows how to handle a
request with no particular file extension. Enter the HttpModule! These classes
implement IHttpModule, and have access to many events in the
request/response lifecycle, set at the application level. Back in the early days of
ASP.NET this interface is what you used to implement your own logic to assign
roles to user on each request. You might use it today to implement logic that
indicates a user’s subscription status. And because it has access to the Error
event, you can build an error logging module here too.

ASP.NET MVC uses System.Web.Routing.UrlRoutingModule to look at
the request, compare it to the routing table, and find the right IRouteHandler
object for the route, the default being the MvcRouteHandler. IRouteHandlers
are intended to return an IHttpHandler (which is not specific to MVC, thus the
inclusion in the System.Web.Routing namespace), and MvcRouteHandler
returns an instance of MvcHandler. That class loads an instance of the
appropriate Controller derivative, which fires off an action. Got all that? One
of the important points here is that the whole system is extensible, and starting at
the top, with the routing table, you can specify alternate route handlers.

More on routing

You’ll recall in our trivial example that global.asax declares a default route to
follow:

routes.MapRoute(
   "Default",         // Route name
   "{controller}/{action}/{id}", // URL with parameters
   new {controller = "Home", action = "Index", id = ""}
          // Parameter defaults
      );

This route says the first component in the path of the URL will name the
controller, the second will name the action to take, and the third will name an ID
of some kind. When any of them are missing, from right to left, the defaults
specified in the third parameter are used. Thus, no path in the URL would call the
Index method on the HomeController, a URL of “/Admin” will call the
Index method of the AdminController, and if no ID is specified, it will try
first to call an action method with no parameters.

Chances are good that you don’t want to be constrained to this one routing
situation. You could have a blogging app (oh, wait, we have one of those!),
where the path should be “/post/some-post-name,” but using the default route,
this maps to the PostController class calling an action method of some-
post-name, which obviously would not exits. This is a case for a custom route,
which we’ve typed out in Listing 1.5.

Listing 1.5: Adding a custom route to global.asax

routes.MapRoute("PostRoute", "blog/{id}",
   new {controller = "Post", action = "Detail"});

routes.MapRoute("Default", "{controller}/{action}/{id}",
   new {controller = "Home", action = "Index", id = ""});

The first thing you’ll notice is that we explicitly spell out the first part of the
URL, with “blog” followed by the slash and the “id” in brackets. Because we’re
not getting a controller name or action from the URL, we specify the one to use
in the default object parameter, in this case the Detail action method of the
PostController.

As we’ll find later in more detailed examples, the kind of data you want to pass
to an action varies. In some cases, passing a string where the method wants an
integer will simply throw an exception (like “/Admin/Edit/foo” when the method
is Edit(int id), for example). That may or may not be adequate for your
exception handling skills. But there are also cases where you may actually
require one or the other. Fortunately, you can pass a fourth parameter into the
MapRoute() method that indicates a regular expression that the request must
conform to. If you only wanted to match blog entries by an integer ID, you would
map the route as indicated in Listing 1.6.

Listing 1.6: Adding a custom route with a constraint

routes.MapRoute("PostRoute", "blog/{id}",
   new {controller = "Post", action = "Detail"},
   new {id = @"\d+"});

The regular expression forces a match for requests like “/blog/509” but not
“/blog/foo.” I know, a lot of developers hate regular expressions, but the power in
front of you is nearly limitless. You can require that the path match any arbitrary
thing you can come up with!

As with everything else in ASP.NET MVC, constraints are also extensible. The
framework provides a simple interface called IRouteConstraint, and with it,
you can implement almost any kind of logic you can think of to accept or decline
the matching of a request. The basic scaffolding of a custom route constraint
class is shown in Listing 1.7.

Listing 1.7: A bare bones custom route constraint class

public class SampleRouteConstraint : IRouteConstraint
{
   public bool Match(HttpContextBase httpContext,
      Route route,
      string parameterName,
      RouteValueDictionary values,
      RouteDirection routeDirection)
   {
      // do some logic
      return true;
   }
}

There isn’t much to the interface, only a single method called Match(), which
returns a Boolean value indicating whether or not the request meets the constraint
(this one isn’t useful since it always returns true). You’ve got all of the relevant
data here to act on and make a decision on, including the HttpContext, so you
could make the matching criteria consider the identity or role of a user. You also
may consider some deeper format for the path that you can’t express (or would
rather not express) with a regular expression.

The order in which you create routes is the order in which MVC tries to find a
match, so the default route is placed last, unless you have some clever reason to
do otherwise.

Master pages and partial views

By now you probably have a pretty good feel about how ASP.NET MVC works
compared to Webforms, but can’t imagine life without the beloved master page,
and probably user controls. Let’s review how those work.

A master page, or more to the point, a System.Web.UI.MasterPage, is a page
template from which other pages are derived from. In the Webforms world, it has
its own code behind and can conduct its own logic. It has most of the “outside”
HTML for the page, including the <head> and <html> tags, leaving
placeholders that will fill in the “inside” content from pages that use the master
page. These pages end with a .master extension.

User controls, typically files ending with .ascx, are a bit of an opposite from
master pages, as they’re fragments of markup and code that can dropped into a
page. Really old school developers might call them a robust version of server-
side includes, although these are much better since they can have awareness of
the page and can be loaded dynamically.

Master pages are still used in MVC, but in keeping with the separation of
concerns, they don’t do anything beyond simple display logic. If they need to
display data, the data should come from a controller. Let’s go back to our cat
names. Imagine that we intend to show those cat names on every page using our
master. Let’s work our way from the view backward, starting with the master
page itself in Listing 1.8.

Listing 1.8: /Views/Shared/Site.master

<%@ Master Language="C#"
Inherits="System.Web.Mvc.ViewMasterPage" %>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0
Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-
transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" >
<head runat="server">
<title>Kittehs</title>
</head>
<body>
<div>
    <p>
      <% foreach (var name in ViewData["AllKittehNames"] as
string[]) { %>
        <%= name %><br />
      <% } %>
    </p>
</div>
<asp:ContentPlaceHolder ID="MainContent" runat="server" />
</body>
</html>

If this reminds you of Listing 1.3, it should! The new and changed parts are in
bold. First, the directive was changed from Page to Master, and the Inherits
attribute changed to ViewMasterPage. Second, we’ve added a
ContentPlaceHolder, which is where pages using the master will put their
goodies. This part works just as it does in Webforms.

Next, let’s build a sample page that uses the master, as in Listing 1.9. Again, this
is fairly straight forward, and works similar to the way Webforms masters work.

Listing 1.9: Some random page using our master page

<%@ Page Title="" Language="C#"
MasterPageFile="~/Views/Shared/Site.Master"
Inherits="System.Web.Mvc.ViewPage" %>

<asp:Content ID="Content1"
ContentPlaceHolderID="MainContent" runat="server">

   <p>Nothing exciting ever happens here.</p>

</asp:Content>

If this page were our home page using the default routing (“/home/index”), the
view would be in “/Views/Home/Index.aspx” as expected. Countless other views
would also use this master, and those views would likely be called by any
number of controllers and their actions. The trick is that we need a centralized
place to populate view data the master can use, regardless of the view called
upon. Setting up this data in every controller action would suck, and be a waste
of time.

Fortunately, your object-oriented skills force you to write better code, and do it
once. You know that all controllers inherit from the Controller class, so it only
makes sense that you extend Controller yourself, and have all of your
controllers derive from that class instead. Listing 1.10 shows us our new
improved controller base and a skeleton of a home controller.

Listing 1.10: A controller base class and a controller that inherits from it

namespace HelloKittehs.Controllers
{
   public abstract class ControllerBase : Controller
   {
      public ControllerBase()
      {
         ViewData["AllKittehNames"] = KittehNames.Get();
      }
   }

   public class HomeController : ControllerBase
   {
      public ActionResult Index()
      {
         return View();
      }
   }
}

Now any controller that inherits from the ControllerBase will get the names
of the cats and place them in the ViewData collection, for use by the master
page. Note that we’ve marked the base class as abstract so it’s not accidentally
used as a controller directly.

The approximate analog to user controls are called partial views. They live in
.ascx files, and like master pages, they should not contain any real logic beyond
display tactics. Instead of registering them, as you would in Webforms, you drop
them in the page using a simple code block like this:

<% Html.RenderPartial("UserPartial"); %>

This is from a case we’ll show you later, where we reuse components of a form
because they appear exactly the same in more than one view. For example, the
form fields used to add a user and edit a user are identical, so it’s easier to create
them once, and keep maintenance down to one place. The line of code above
follows the same conventions as the View() method of controllers, looking first
in the controller’s cousin folder (like “/Views/Admin”), and if it can’t find it
there, it’ll check the “/Views/Shared” folder. Since it’s a partial view, it’s looking
for UserPartial.ascx instead of an .aspx file.

Getting data to these partial views works the same way as it does for full views.
The data must be added to the ViewData in the controller action. You won’t
likely need to do it in some abstract base class, as you should know in most cases
that the partial view will be a part of the view you’re instantiating. As such, make
sure you get the partial view’s data set in the action method.

ASP.NET MVC, front-to-back advantage revisited

Jeff — Tue, 05 May 2009 18:32:00 GMT

A couple of month ago, I wrote a post about the surprising advantage of MVC as an enabling technology for front end folks. The more I work with it, the more I feel that it's the key advantage to using MVC. Given my rants on why I think the user experience is so important, you can understand why I'm so excited by this.

The shift in thinking to making more UX magic on the client end does throw us back into the world of Javascript, which is at least a little unfortunate since the debugging tools aren't nearly as good as the back end, but with jQuery and countless plugins easing the pain, I continue to be amazed at how quickly you can turn out really nice experiences. And even more surprising is that it doesn't require all kinds of drag-and-drop tools. You really get into the weeds with actual code, but without a ton of complexity.

What am I rambling about exactly? Your client code is often a couple of lines of code to make a JSON call or activate graphical notifiers, while your server code is often little more than a simple controller action. Even in the best encapsulation of script and rendering code in standard Web controls for Webforms, it's never that clean.

The question in my mind now is, what happens when ASP.NET v4 is out? With a much higher degree of rendering control, the "cleanliness" issues may be largely addressed when it comes to writing the client code. Will it still be as compelling?

I'm curious to hear stories from developers on how MVC is making their lives easier (or harder).

Job recruiting turned to spamming, staffing firms marginalizing themselves

Jeff — Mon, 04 May 2009 21:13:00 GMT

The poor economy has had an interesting (and unfortunate for people in my position) side effect for the business of matching employers and people. The staffing agencies themselves have become so desperate to fill so few jobs that they've gone to the point of spamming prospects with irrelevant "leads." It's literally the same approach that spammers take, feeling that e-mail is cheap, and send out enough and something will stick.

Some of it goes as far as to insult you. Next to the unsubscribe message, one that I got today said, "You opted to receive this e-mail because you posted your resume on a job board." Seriously? So I could be spammed by someone plugging a job in Portland that I'm not qualified for?

Even worse, when someone posts a job on Monster, all of the recruiters call you that morning pitching the same thing, which by then if it was a fit I already applied for. I keep wondering what value these staffing firms add for anyone. In the Internet age they strike me as unnecessary.

The big difference in looking for a job now compared to a year ago is that you the candidate have to do things the old fashioned way, by looking for positions yourself and firing up the network. The network of course says, "Ain't got nothin' fo' ya man."

It's a bad scene out there, especially in the Cleveland/Akron market. The recruiters I trust say they see a slight up tick in other markets they work in, but not here. I'm perfectly willing to move, but not for contract work, and not without some measure of relocation assistance. We just got married and have two mortgages, so moves initiated by us... not likely for about the next year.

It's a good time to reinvest in yourself, volunteer and write something on your own.

Empower for ISV's: FAIL

Jeff — Mon, 04 May 2009 15:45:00 GMT

I was just thinking back to Mix when I remembered some mention of the ISV program, where a couple hundred bucks a year gets you MSDN and such. The catch is that you have to release some kind "packageable" software. Seriously? Does this make sense from the company moving all of its stuff to Web-based solutions and driving the developer community in the same direction.

Not very well thought out, actually.