The Grubbsian

Wi-Fi Mile High

So, I'm on a plane right now and there are at least five people in my immediate vicinity working on laptops. Every single one of these people is reading email in Outlook. The obvious disgust at Outlook aside, this leads me to the question, "Why don't we have Wi-Fi on every commercial flight yet?".

I myself would be incredibly attracted to any airline that offered this service. It wouldn't even have to be free. I'd happily pay an extra $10 for my ticket if it came with even modestly quick Internet access.

I doubt if any airline execs read this particular blog, but if you are...Wi-Fi...all I have to say...Wi-Fi.

jQuery Plugin: wrapList

Ok, so now I'm on a roll with the jQuery plugins.  This time it's a simple plugin that takes a single unordered list and segments it at predefined intervals into additional lists.  Each list is then floated to the left making it appear to wrap content to the next "column".  The plugin is extremely simple to use but works really well on all sorts of content.

Download: jQuery.wrapList.zip

jQuery Plugin: AnchorCheck

I recently needed a jQuery plugin to do checkbox replacement for a client.  Unfortunately, the plugins that were available really didn't fit our needs.  In this particular instance we were not concerned with being unobtrsive so we didn't need to render out an actual checkbox and the replace it with another tag.  Instead, we decided to go with plain old anchor tags. 

So I whipped up my very first jQuery plugin to solve the problem.  And with the recent announcement that Microsoft will be shipping jQuery with ASP.NET it seemed all the more appropriate.  In another post I'm going to go through the steps needed to create a jQuery plugin but for now, here it is.

Download: jQuery.anchorCheck1.3.zip

Should We Hold a Funeral for IE6?

Folks, I think the time is nearing...may it come quickly.  I just loaded up IE8 beta 2 in a VM and I just realized that by the time IE8 is released, IE6 will be 8 years old and two whole versions behind.  The thought of trying to write rich-Internet applications for a browser that was released in mid-2001 is becoming more and more frightening.  

In my line of work the most compelling reason to continue support for IE6 is that most large companies still deploy it to the desktops.  A surprising number even block the upgrade to IE7 forcing thier users to suffer with a slow and broken browser.  That aside, is it time to start turning away work (or at least seriously discouraging work) if the client insists on supporting IE6?  In my opinion, we're almost there.  

In fact I think it's the only way that change is going to happen.  Companies usually don't make major shifts like this without it hitting them in the pocketbooks.  If suddenly a larger and larger portion of vendors and line-of-business apps stop supporting IE6 they will feel the pain and suddenly see the light.  So don't be afraid to question your next client or project when the subject of IE6 support comes up...and don't be afraid to say no...say no to IE6.

Join the Movement: http://www.savethedevelopers.org/

Urgent!

An interesting experiment going on over at 37 Signals: http://www.37signals.com/svn/posts/966-urgency-is-poisonous.  I think they might be on to something.  I know that my current project would have benefited greatly from this kind of freedom from urgency.  I can attest first hand that extreme urgency does not elicit the best code or the best mental attitudes from a team.

Access Modifiers and Programmer (mis)Trust

So I've been looking at some new languages recently, particularly dynamic languages like Ruby and Python.  One of the first things I noticed about their syntax was the lack of access modifiers.  I suppose the assumption could be made that since C# is type-enforced that it lends itself to access modifiers but I also wonder if maybe it's just a case of programmer mistrust.

If I'm writing an API that's going to be consumed by other developers, am I really so paranoid that I need to lock things away into isolated boxes to prevent misuse?  No, I think I fairly well trust consumers of my code to understand my code prior to using it or do so at thier own peril.

I can see the argument being made that it makes the API cleaner if implementation code is hidden from the consumer.  I don't disagree, but I think that problem is better solved by encapsulating implementation logic into a lower level class.  This has the added benefit of making the implementation available for anyone that wants to take a look under the covers, but still providing a clean API layer.

So what am I really proposing here?  Should we just mark everything public everywhere?  No, I don't think that's really what I'm saying.  What I am saying, is that it's interesting that a number of dynamic languages have decided to trust thier developers more than C# and I just think that's interesting.

Improving Performance of Windows Vista in VMware Fusion

I recently moved over to a MacBook Pro as my primary laptop and development machine.  With the recent advances in virtualization on that platform (namely VMware Fusion) it's become possible to run both Mac OS X and Windows (XP/Vista/Server) in a VM quite happily.  So when my new laptop arrived the first thing I did after watching the cool intro video, was install VMware Fusion Beta 2. 

This newest version adds some exciting features and improved stability so its a good choice if you're moving to Mac.  Despite how good Fusion is, there are some things you can do to tweak Windows to play a little nicer in a virtual environment.  I'm using Windows Vista but these tips will apply to Windows XP as well.

5 Ways to Improve Windows Performance in VMWare Fusion

1. Turn off all non-essential services.  There are a lot of services that Windows enables by default a number of which are totally unnecessary for day-to-day use.  By going through your running services list (run: services.msc) you can trim quite a bit of memory use.
2. Ditch the screen saver.  Because you're running in a VM in an OS that already has a screen saver, you can turn the Windows one off.  If it kicks in while your not paying attention it will start to eat up additional resources while you're trying to do other Mac OS work.
3. Do you really need 3D acceleration?  Chances are you're not going to be playing games in the VM so you can safely turn off the 3D acceleration option in VMware preferences.  This may not actually eat up resources in the VM but it will add some overhead to the VMware container.
4. Areo is pretty but slow.  Just resort to the Windows Classic or Windows Vista Basic theme and just deal with it.  You should get your "Ooh that's pretty" vibe from Mac OS X anyway.
5. Turn off system protection.  Since you'll be backing up your Mac OS X machine (and you will be backing up right?) you don't need the added protection of using system restore on the guest machine and it just eats up virtual hard-disk cycles.

So there you have it, a few quick ways to speed up the performance of Windows on Mac...friends at last.

Google Chrome: Friend or Foe

The jury is still out on Google Chrome...most likely since no one has really been able to get their hands on it yet.  The browser is set to ship in beta sometime today.  But even before its release the very idea of a new browser begs the question... "Do we need another browser?"

Like most philosophical questions of this depth (mind you not very deep at all) the answer is varied.  Some say, "Yes, more browsers equals more choice equals more competition equals better features, blah blah balh."  Others say, "Are you crazy?  I just got over IE6!"  In my opinion, it's not really about the browser it's about the engines. 

I don't care if the title bar of my browser says Microsoft, is a drab 1940's post-ware gray (ala Safari), or has a little curled up fox gently engulfing the globe.  What I do care about is how the thing works.  As a developer, I crave consistency.  When I write a piece of code I want it to function precisely as I expect it to, and I want it to do that in every environment that calls it.  In this vein the nice thing about Google Chrome is that it's built with open source pieces...it's the Frankenstein of browsers really.  It has WebKit's rendering engine, parts of the plug-in architecture are ripped off from FireFox, and I suspect that a its new JavaScript engine is built on concepts from a whole realm of different open source projects.

So, we'll have to wait and see what comes of it.  If it runs Firebug, and is really as fast as they say, then it'll probably be a good browser for developers, if not it will just be another "Oh that's kinda cool", and then we'll all go back to FireFox.

Dance Pentium4... Dance Like it's 1999

So, I've been working at a client location now for the past several months and up until about three weeks ago I was able to use my own laptop for most of my development.  Unfortunately, due to the security policy on one of our more recent projects I have been forced to use the machine provided (because it's joined to the domain).

Now, this machine is very typical for this company, most of the developers have this exact setup.  Let me just give you the run down:

1. Lenovo ThinkCentre - Pentium 4 (2.xGHz), 1GB Memory, 40GB Hard Disk.
2. Acer 17" LCD Monitor (just one mind you)
3. Standard Lenovo keyboard (wired)
4. Standard Lenovo mouse (wired)

So there you have it.  The most basic business machine...ever.  If I was sitting in accounts payable, or in marketing, or even an IT manager this machine would be exactly what I need.  It would handle my spreadsheets, word documents, and emails with ease.  As a developer however, it leaves much to be desired.

So this got me thinking about the cost/benefit surrounding the choice of hardware for your development team...and the choice to plant this doorstop on my desk.  Developers are not typical users, they're not really even power users, they are their own class.  Constantly restarting, installing, uninstalling, resetting, formatting, deleting, pegging the processor, running out of memory, etc, etc.  Basically anything bad that you can do to a computer, a developer will inevitably do.  So the first compelling reason to get good hardware is for the hardware's sake...it will simply last longer and perform better for a longer period.

The second thing that distinguishes developers from other users is that their primary output is code...a medium wholly dependent on a computer.  Other positions within a company, while extremely reliant on computers and software, are not completely crippled when a computer is slow or temporarily unavailable.  So the second argument for quality machines is maintaining developer output.

The third reason I'll highlight is developer happiness ;)  Again, developers are not normal.  We are fickle but easily amused and really good hardware running well tweaked operating systems just make us smile.  Smiling developers write better code...it's a fact.

So please, if you manage a development team or are responsible for provision hardware for one...think about the day-in-day out developer who'll be sitting behind that tiny screen, and get him/her a bigger one.

.NET Developers Journal Article

The September issue of .NET Developers Journal will include an article authored by yours truly entitled, "Design for Developers".  It's basically a primer for developers on the art of design.  I don't consider myself a designer by any means but I've picked up a few tricks along the way and am fortunate enough to be given the opportunity to share my learning with the community at large.  I'll post again when the issue is out with a link to the online version.

Inline Scripting

This is an interesting article from Rob Conery on the virtues of inline scripting; which, of course, has received a bad rap in recent years but still has a place in the pantheon of development technique.

http://blog.wekeroad.com/2007/10/15/crazy-talk-inline-scripting-and-code-behind/

Perfect Christmas Gift

Anyone who gets me any of these for Christmas is tops in my book:

http://www.thinkgeek.com/geektoys/plush/6708/images/

jQuery Event Binding vs. ASP.NET AJAX UpdatePanel

UPDATE (12/5/2008): An alternative solution to this issue is found in a more recent post here:
http://www.thegrubbsian.com/2008/12/jquery-vs-the-aspnet-update-panel-revisited.html

While this is a simple topic, it is one that tripped me up and since the documentation for ASP.NET AJAX is pretty poor, I thought I'd share how I worked it out.

One of the great advantages of using a JavaScript library like jQuery is easy event binding.  In jQuery you can bind an event in a cross-browser compliant manner with very little code:

$("someElement").click(function() { alert('I'm Clicked!');});

Another convenience of modern JS libraries is a loaded event, basically detecting when the browser has finished receiving and parsing the DOM from the server.  For example, in jQuery we can test for DOM completion thusly:

$(window).ready(function() { ... });

Anything within the function here will be executed only after the entire DOM has been downloaded and parsed by the rendering engine.

Now, when you wrap parts of markup with an ASP.NET AJAX UpdatePanel you create a scenario in which a certain portion of the DOM will be reloaded asynchronously while other parts are not.  Even though you will often be merely updating nodes within this area of the DOM, the UpdatePanel is heavy handed...it basically just wipes out whatever was in there and replaces it fresh from the server.  When this happens all your fancy events bound to those elements are blown away.  Thanks UpdatePanel!

Happily, there is a solution that works with any library, not just jQuery.  You will need to abstract your jQuery event bindings away from their handlers into new JS functions.  For example:

$(window).ready(function() {
    $("#someElement").click(function() {
        alert('I've been clicked!');
    });
});

would become:

$(window).ready(function() {
    $("#someElement").click(function() { SomeElementClicked() });
});

function SomeElementClicked() {
    alert('I've been clicked!');
}

Next, we need to replace the jQuery "ready" block with a function that automatically gets called by the ASP.NET AJAX client framework whenever a postback occurs (sync or async).  So our script would now be:

Sys.Application.add_load(WireEvents);

function WireEvents() {
    $("#someElement").click(function() { SomeElementClicked() });
}



function SomeElementClicked() {
    alert('I've been clicked!');
}

Now you can continue to use jQuery to bind events (and skip using the convoluted ASP.NET AJAX way) and use the UpdatePanel to surround jQuery bound DOM elements.

My Page Just Had Deja Vu

One function whose absence I find annoying in ASP.NET is the ability to easily return to a previous page and reload its state.  I recently needed this functionality in a project for a course registration application I was building at work.

The basic scenario is this:

1. User enters some search criteria on the Course Search page and a list of matching courses is returned.
2. The user selects a course and is directed to the Student Roster page for that course.
3. The user then selects a particular student and is directed to the Student Maintenance page.

Now, the user will almost always need to get back to the Student Roster page, and maybe even the Course Search page after making changes on the Student Maintenance page.  However, they don’t want to start the whole process over back at Course Search each time.

So, I tried a number of ways to accomplish this in a generic fashion, the first being a convoluted method using the PageStatePersister class to pop the page’s ViewState into Session and bring it back when the user returns.  However, this can be problematic because the page is unaware of what’s going on in the application outside of itself.  In other words, data may have changed or the user may have returned to this page through a non-linear route and now needs a different set of criteria; they don’t want the same options they chose before.

So what I came up with was a simple solution using the query string and a ReturnUrl parameter.  I’m sure we’ve all seen these things gumming up query strings around the web.  While it does tend to make your URL rather intense, it is an effective method and it’s easy to see what’s going on.  So here are the requirements I set up for whatever method would implement this functionality:

1. The method must be able to pass forward a ReturnUrl parameter which can hold both control values on the original page as well as any query string variables which were passed to it.
2. The method must be able to handle n forward progressions and likewise be able to link backwards n times without losing anything along the way.
3. When a page reloads from a ReturnUrl the method must be able to set values on ASP.NET  WebControls on Page_Load.

So, I wrote a class which inherits from System.Web.UI.Page called DejaVuPage (an apt name I thought) which encapsulates this functionality.  The code for this class can be found in the App_Code folder in the zip file which accompanies this post as DejaVuPage.cs.  Essentially, there are four things any page inheriting from DejaVuPage can now do:

1. Set a list of controls to be included in potential ReturnUrl params.  This is done by adding control IDs to the DejaVuPage.ReloadableControls (ArrayList) property.
2. At any time get what the current ReturnUrl parameter would be.  This is done by getting the DejaVuPage.ReturnUrl property.
3. Redirect to the previous page by calling this.RedirectToReturnUrl().
4. Reload a page's controls from a ReturnUrl by calling this.LoadFromReturnUrl().

The ASP.NET sample project included in the post has a good example; run the app, enter some criteria on each page, then when you get to the end use the ‘Go Back’ links each previous page will reload it’s controls as you left them before.

I’m sure someone can improve my code, so if you see somewhere where this concept could be refined, please let me know.  I hope some of you find this useful.

Download DejaVuSample.zip