My Resume

  • My Resume (MS Word) My Resume (PDF)


  • Microsoft Most Valuable Professional
  • INETA Community Champion
  • Leader, NJDOTNET: Central New Jersey .NET User Group

Wednesday, June 25, 2008

Where the heck can I download Firefox 2.0!?

Now that Firefox 3.0 is finally released, Mozilla has done a real good job of clearing out any mention of it from their website.  Thing is, we web developers still need to test on it!

Well, after a bit of querystring hacking (simply replacing "product=firefox-3.0" with "product=firefox-"), I came up with this link, which should get you what you need:

Download Firefox

Thursday, June 19, 2008

Inaugural NJDOTNET Agile Meeting **Tonight**

As I announced at the last few weeks' NJDOTNET Study & User Group meetings, we'll be having our very first NJDOTNET Agile meeting tonight, Thursday, June 16th starting at 6:30 PM in the Infragistics auditorium in East Windsor (the same location as the regular NJDOTNET user group meetings). Here's a little bit about the group:

Taking a cue from both the growing ALT.NET movement and quite a few members of the main NJDOTNET user group, I've decided to augment the monthly meetings of our established user group to create a more interactive, discussion-based meeting. These Open Spaces meetings will occur once a month, on the weeks following the regular User Group (the third Thursday of the month). Hopefully the addition of these meetings will allow everyone to get the benefit of a different style of interaction and learning that the “Lecture-Learn” style of the main user group cannot provide.

I'll see everyone there!

Tuesday, June 10, 2008

ASP.NET MVC: Using Custom View Engines and Filters for AJAX

Way back in the time of ASP.NET MVC Preview 2 (last month), I was preparing for a presentation and decided that it would be nice to show just how simple it is to make your own View Engine.  Having found David Higgins' JsonViewEngine a few days earlier, I decided to expand a little upon it and add the option to emit either XML or JSON using the same engine.  After a little while, I had something looking like this that supported both:


public class SerializableViewEngine : IViewEngine
    public void RenderView(ViewContext viewContext)
        string method = viewContext.RouteData.Values["responseType"] as string;

        string serializedData = string.Empty;
        switch (method.ToLowerInvariant())
            case "json":
                serializedData = new JavaScriptSerializer().Serialize(viewContext.ViewData);
            case "xml":
                serializedData = SerializeToXml(viewContext.ViewData);


    protected static string SerializeToXml(object o)
        StringBuilder sb = new StringBuilder();
        using (TextWriter writer = new StringWriter(sb))
            new XmlSerializer(o.GetType()).Serialize(writer, o);
        return sb.ToString();

As far as building a custom ViewEngine goes, I figure this is a great example - other than the fact that I extracted my "SerializeToXml" logic out, this is a one-method override!  At first glance this (and David's) implementation may seem a little "underpowered" because of how few lines it took, but if you disassemble the System.Web.Mvc assembly or look at the MVCContrib code, you'll see that even real-world ViewEngine implementations can be this simple!  I guess that's one of the nice side-effects of separation of concerns - when big things are broken up into a bunch of pieces, those pieces are usually pretty small!

As for the details of this particular example, you'll notice that it checks the RouteData dictionary (populated from the routing tables you specified elsewhere) to see if it contains "responseType" (e.g. if one of your routes was "{responseType}/{controller}/{action}" and the url that was called looked something like "/json/products/categories") and try to honor it by serializing the ViewData that was passed from the controller into the requested result.  Once it has serialized the data, it just writes it directly to the Response and you're done!  You could then use this View Engine to render out all the async calls all day and night, just by setting the ViewEngine property on the controller instance like so:

Setting the ViewEngine

public void AsyncCategories()
    var categories = repository.GetCategories();
    this.ViewEngine = new SerializableViewEngine();
    return RenderView("Category", categories);

Simple as that, right?  Well, sure... but what happens when you end up making duplicate Actions for your "normal" browser and AJAX requests that have all the same logic with the exception of that one line?  The line that sets the ViewEngine is hard-coded in there, so you have to have separate Actions, right? 

Enter the ActionFilter!

Wrong!  After thinking about it for a minute I realized that this is the perfect place to use an ActionFilter (which was a good thing, because I just so happened to need a code example for that, too)!  And so, I got to coding and came up with this guy:


public class SerializableViewDataAttribute : ActionFilterAttribute
    public override void OnActionExecuting(FilterExecutingContext filterContext)
        var controller = ((Controller)filterContext.Controller);

        if (filterContext.RouteData.Values.ContainsKey("responseType"))
            controller.ViewEngine = new SerializableViewEngine();


As you can read about here (if you haven't already), ActionFilters are the perfect way to "inject" behaviors into your controllers.  I like to compare them to the ol' Web Forms ASP.NET Page Lifecycle events such as PreInit, Init, PreRender, Render, etc. that let you plug in to the various stages of processing a request and allow you to manipulate it accordingly.  For example, by overriding the OnActionExecuting method on the ActionFilterAttribute as shown above, you can plug into the request after it's reached the controller, but before any action has actually been taken on it.  I believe I could have also used OnActionExecuted to accomplish the same thing since I'm only setting the ViewEngine, but that just didn't "feel" right.

Using this new custom ActionFilter, I could apply it at the Action level - or the Controller level if I wanted to apply it to all of the controller's actions - and get rid of those silly duplicate Actions.  Now, instead of having the AsyncCategories Action shown above (which is assumedly just a duplicate of some other Action, perhaps called Categories) that explicitly overrides the ViewEngine with every request, I can now drop the line that sets the View Engine and let my new ActionFilter take care of setting it for me when it is appropriate!  In other words, the code above now turns into the code below, which handles both "regular" and AJAX calls with the same code!

Removing the ViewEngine code from the AsyncCategories Action

public void Categories()
    var categories = repository.GetCategories();
    return RenderView("Category", categories);

The first time I successfully saw the result of running this demo was the first time the power of ASP.NET MVC really hit me.  This whole example was just a bunch of really small and straight-forward (dare I say 'simple'?) pieces that, when put together, create some really amazing and powerful results.

Grab the Code and See For Yourself!

You can see all of this stuff in action by downloading the code from my website:


I welcome any and all feedback y'all can throw my way.  Enjoy!

UPDATE:  As the beginning of the post says, these are what you can do with the Preview 2 bits.  With the addition of the ActionResult in Preview 3 and the related methods on ActionFilter, you can actually ditch the custom ViewEngine altogether and just use the ActionFilter!  Not the ActionFilter I show here, mind you, but an updated version I will show in an up-coming blog.  :)

Thursday, June 5, 2008

Douglas Crockford JavaScript Videos Online!

I was doing some JavaScript development earlier tonight, Googled an issue I was having and at the bottom of a blog post the author linked to a bunch of videos on Y! Video of a Douglas Crockford presentation, "The JavaScript Programming Language".  These videos are - hands down - the best use of my time spent learning JavaScript ever.

Here they are:

There is also an "Advanced" series, too!

Monday, June 2, 2008

ASP.NET MVC Firestarter - June 7th!

Are you interested in diving deep into the new ASP.NET MVC framework?  If so, come check out the NYC ASP.NET MVC Firestarter!

I'm not going to duplicate too many details here, but it's Saturday, June 7th, 2008 at the Microsoft offices in NYC (1250 Ave. of Americas). 

Check out this link for more information and to register!

Oh yeah - there's gonna be free food, too! :)

The Search for a Proper VM Host

The task that's been consuming my past few weekends (and a good deal of my weeknights) has been exploring various options for running various virtual machines on my desktop PCs (as opposed to my "server", which runs Gentoo Linux without debate or question).  "Why?" you might ask, and for good reason, since I am continually asking myself the same thing...  Even I am not sure that this is really the best route to go, but I'll try to enumerate my goals below which may shed some light on my rationale.

My Goals

  • Avoid the pain of dealing with pre-release software and frameworks.  I've always been incredibly interested in bleeding-edge technologies and releases and being an early adopter often has its painful side-effects.
  • Avoid bloat.  Keep it "clean and simple." I'm a minimalist and I don't like bloat.  Visual Studio may be the best .NET IDE around, but it's friggin' huge!  I may use it (and my other development tools) a lot, but I don't consider them part of my "core OS/tools".  When I boot up, I want to be up and running as quickly as possible; and when I'm running, I don't want anything other than what I currently need (and that includes stupid OS "features") to be hogging my resources, be it CPU, RAM, or even disk space.  I want to load those those in their own VM and turn them off/on when I need them; having them in their own VM also gives me the freedom to store them wherever I want and even transport them other places (like work)!
  • Be "Agile".  The key to agility is being able to do things quickly.  I also think a key part of Agile development practices is being able to not only try something just to see how it turns out, but the implied converse of easily being able to roll back to a clean environment before you tried that thing out.  Applying this principle at the OS level is a very powerful concept.  (This is very closely related to the first bullet-point above)
  • Run Linux as much and where ever possible.  This one has no real logic to it - it's completely emotionally-driven.  I love the idea of the power I get running Linux and I'd like to harness that power wherever possible.  The downside to this (as I found out in this process) is that the UI in Linux really sucks;  it's ugly to the point of un-usability.  (Yes, I know function, experience, and style are very different things, but in this case style overrules them all.)

My Stabs at Success

  1. VMWare ESX Server.  This looked like the ultimate answer, since it appeared to serve all of my goals above.  Unfortunately, the install for ESX didn't really go very smoothly (not to mention the fact that it was slightly, ah, "questionable" - legally speaking - to begin with...) so I gave up on it quite easily.
  2. VMware Server on Ubuntu JeOS.  I downloaded and burned a copy of this at 3 AM Saturday morning, but never installed it.  Why?  'Cause I re-read its overview and saw that it is meant to run ON a VM host, not act as one!  Stupid (actually, time for bed...)!  Luckily I only wasted about 20 minutes and a CD downloading and burning it.
  3. VMware Server on Ubuntu Server Edition.  Well, I got everything up and running with minimal overview...  Then I realized I didn't just need to host VMs...  I needed to be able to "consume" them on the same machine!  DOH!  In retrospect, this was an incredibly blatant oversight.
  4. VMware Server on Xubuntu.  Now we're on to something!  Linux host with very minimal overhead - I had the whole system up and running, hosting VMs, and running the client with only 600 Mb RAM.  This was awesome, and it met all of my goals.  Problem was - it met them a little too well.  Sure, I wanted a minimal system to host VMs with no bloat, but the fact is, I kinda wanted some of that bloat.  IM, Twitter, and even Microsoft Office are the types of things that I want available all the time and not things I want or need to virtualize.  Sure, there are OSS replacements or workarounds that can handle pretty much all of my needs, but I came to the sad, sad realization that Linux as a desktop just plain sucks.  It's powerful, sure - but it looks like crap, and that makes it just plain dreadful to spend most of your time in... especially in a "minimal" environment like the one I was shooting for.
  5. VMWare Player on a trimmed-down Vista.  Luckily, I was trying out all of the previous attempts on an extra HD, not actually overwriting my existing Vista install; an install which, quite honestly, I never intended to completely replace as I do play games on it occasionally.  This is the solution I eventually settled for (at least for now), since it seemed the best compromise of all my goals, including those hidden ones I discovered along my journey.  I'm wondering, though, if this really is the best solution...  For starters - you'll notice the other solutions involve VMWare Server whilst this one uses Player.  That's right - since I'm on a 64-bit machine and stupid Vista doesn't allow non-signed drivers (and for some strange reason stupid VMWare doesn't provide signed drivers for Server), I'm left with the crappy, non-feature-ridden VMWare Player.  Which sucks.  Oh yeah, and did I mention Vista is bloaty!?

The Bloat that is Vista

Even after I spent quite a while picking and choosing which services to kill (practically all of them - including Themes - except the bare system ones) in order to make my Vista install as lean as possible, it still took up 15% of my total 6 GB of RAM!  Here's a few screenshots of my system after it's booted up before I've run anything (except SnagIt and FolderShare):

Vista - Memory Hog Vista Task Manager - Full

That is not my idea of "minimal", especially compared to my Xubuntu install!  I don't have a screenshot of the latter, so you'll just have to trust me when I tell you - 617Mb.  A fully-running system (including X & XFCE Window Manager) took 617Mb of RAM... and that was without any real attempts at minifying it any more than the default install!  Now I'm left wondering what a stripped-down install of XP would look like....

So, I'm back to square one - facing the dilemma that I've been tortured with for the past 6 years since I began using Linux: suffer with the unsavory UI and awkward UX that is the Linux Desktop, or deal with the bloat that is Windows.

It really is a no-win situation.