# Wednesday, 25 November 2009

I believe strongly in teams being families.  We spend eight hours a day, five days a week with each other.  A great team is able to take everyone’s ups and downs, pluses and minuses, strengths and weaknesses with dignity, respect and healthy doses of humor.  A great team is a team that isn’t all alike and embraces and remains open to diversity of ideas, backgrounds and ways of thinking even when it’s hard for them to do so.

Lindy White was one of the most unique team members I have had the pleasure to work with and go on to lead.  His candor was unmatched and so was his personality.  His tenacity and intensity for development was infectious.  He was an extremely valuable team member.  He made us all better.

Many years back we moved our website to a CMS system.  Over the years, the site grew to have around eighty content liaisons (users who could write content).  Unfortunately, strewn throughout the website were email addresses.  Our website was responsible for a large amount of email cherry picking by bots.  The team discussed how we could handle this and Lindy was given the lead to develop the solution.

As time went on, Lindy being Lindy was unsatisfied with the solution being developed and struck out to find a better way.  What he came up with was pure gold.  He wrote an HTTP Module that intercepted the outgoing HTML and converted all email addresses to a format bots could not use/read. With zero changes to our end users and next to zero maintenance on our part the web bots can no longer steal email addresses from the website.  I nominated him for an IT Pro Hero award through Windows IT Pro magazine.  Here’s the article:


Lindy knew of the award but sadly he passed away before he could see the article with his own eyes. 

It’s been a little over a year since he left us and I still think about him all the time.  Lindy, I miss you and you will always have a special place in my heart.  Thanks for the memories!

Posted 11.25.2009  #    Comments [0]  | 

I have been developing with ASP.Net since it debuted.  Before that I was doing windows form development with VB and classic ASP web development.  The advent of ASP.Net was phenomenal for me and my team.  The web forms model allowed our team to continue using the Windows event driven model over the web and allowed us to take our web development to a new level than classic ASP.  We quickly dispatched of our windows development in favor of the simple deploy / update model and gladly left the dreaded PC install / update nightmare.

Fast forward many years and ASP.Net matured quite a bit, Windows Forms had click once and all sorts of other goodies in the framework.  Now MVC.  My experience with MVC up until this point had only been my reading in the Gang of Four book and the occasional blog entry.  While all this was going on I had (and still am) been on a mission to improve my programming skills.  The majority of this was and has been reading, reading, and more reading.  I started trying out test driven development with a side project of mine.  The project was web forms based.  I was greatly encouraged with TDD but had read all the difficulties with TDD and web forms.  I had just begun this side project and decided why not make the switch to MVC?  So I did.

Along the way, I have had a lot of  "aha" moments.  Here’s some of them:

Web forms code behind faked me out. I thought I had good separation of concerns. Or I really abused the code behind file but I thought I was doing right.

For quite a while I knew large code behind files were not healthy.  I had been working as best as possible to decrease the code in them.  However, with my MVC journey I think I have come to see just how unhealthy large code behind files are and just because the code was not in the same file as my html did not mean I had a strong separation.  MVC by it’s nature encourages good separation and all the books and blog entries I have read show this by default.  In the web forms world I had to seek this out (not so much today but definitely in the early days and habits can be hard to change).

I’m having data source withdrawals and View State withdrawals.

I’m nearly over it now but this was a big hurdle for me.  It’s amazing how reliant I became on this but it shouldn’t be too much of a surprise since this is the magic of Web Forms. 

I'm loving having control back of the HTML and the HTML is actually readable now.

This is definitely has been a pleasant return to HTML for me.  With web forms I went on autopilot for much of the HTML / JavaScript that my apps produced.  I just lived with it even when I saw disgusting and bloated source.  Many took great pains to make web forms bend to their HTML will and I certainly understand why.  For me though, this is one of the reasons I like web forms so it didn’t bother me much.

So why would I want the control back.  Simple, because I can easily have it back now and the trade off to me doesn’t really feel like a trade off.  MVC is far more bare bones by design but I still don’t feel like I am back at the classic ASP spaghetti code.  It’s this bare bones nature that I am really digging.  I have a lot more control over everything and even though I may not want to control a lot I know I have the option to.  I do miss at times the "drag and drop a control unto the canvas and go" mentality but with jQuery and HTML helpers I am missing it less and less as I become more proficient.

Hello, JavaScript. It's been a while since we last worked together.

With web forms, I enjoyed the luxury of not having to really getting down and dirty with JavaScript.  I used everything at my disposal to use a control and/or post backs to handle what was needed and only used JavaScript when I needed to.  Mind you, I realized this came with a price of some nice user interactions but I was willing to pay that price.  JavaScript and the DOM specifically were always giving me fits. 

Unfortunately, this experience in the long ago past blinded me to the wonderful things going on with JavaScript over the years.  With JavaScript libraries like jQuery the capabilities that once required a JavaScript and DOM wizard are now at your fingertips.  I have fallen for JavaScript and am ashamed I had closed my mind off to it for so long. 

MVC by it’s nature encourages JavaScript for rich UI interaction much like controls did for Web Forms but so much more.

Testing? Ya, I did that. It's F5 right?

MVC was not my start on considering better ways to test but everything I read and worked with on MVC had testing involved all the way.  Every book I have read, every beginning MVC blog entry has testing intertwined.  My first attempts at unit testing was with a web forms project and I was absolutely convinced it would make me a better developer, faster developer and create more maintainable code.  However, with web forms, testing for me and many I suspect was changing some code and hitting F5 to run the application and manually test.  With a little unit testing / TDD under my belt I have come to see how much more efficient it is to "F5 testing". 

MVC permeates with the idea of unit testing and that’s by design.  I have much to learn on my testing journey but it has already paid dividends for me that has me convinced it’s an important tool in my toolset.

I am working in harmony with the HTTP protocol now.

I mentioned one of the reasons I liked web forms is that it allowed me a very easy transition from windows forms development.  As much as I would like to say I understood how the web really worked underneath the hood I know now that I didn’t.  Yes, I knew it was stateless and all that jazz but with web forms I was abstracted away from the way the web worked. 

When I started learning MVC it became painfully obvious how much I had forgotten and/or didn’t really understand about how the web works.  I am still tripping over this while I continue my MVC journey but I am happy to say that the knowledge gained in understanding more deeply how the HTTP protocol really works is making me a better web developer.  “Working in harmony” is a paraphrased quote from "Pro ASP.NET MVC Framework" by Steven Sanderson.

I am enjoying my MVC journey and look forward to becoming extremely proficient with it.  I will also admit that much of my 'aha' moments are not because of Web Forms, rather they were mainly a result of my own lack of exploration into what was possible and what was out there.  I was too busy keeping my head down and firing out widgets instead of really trying to hone my craft at all times while spitting out widgets. :-) This has changed for me now.  I have an extremely strong desire to be a real craftsman and not just someone who can bang on a keyboard.

Web Forms is a great tool and I imagine I will continue to have it as a tool in my toolset for a long time to come along with MVC.

Posted 11.25.2009  #    Comments [0]  | 
# Sunday, 15 November 2009

I live in Flagstaff, Arizona and since it’s a small town not many happenings occur for coder geeks.  I wanted to come out of my shell a bit and head down to the Valley (Phoenix).  It’s only a couple hour drive, not too bad.  I decided to attend Desert Code Camp this year for the first time and all the sessions I attended were great.  They even fed us which I was not expecting.  What a great camp!

The camp heavily favored web development but that’s the majority of my work.  I attended several sessions and want to give a small run down and thanks to the presenters and to the organizer.

First and foremost, to the organizer, Joseph Guadagno, thank you!  I can’t imagine the work it took to put it together and all the volunteers by your side.

To all the presenters, thanks.  Giving your time to teach others is always appreciated.

I wanted to give a special thanks to Michael Collins, Saul Mora, Rex Miller, Steve Andrews and Remi Taylor.  You guys did a great job on your presentations!  I mean it.

Michael – I wasn’t sure what I would find sitting in on Advanced Debugging with Visual Studio.  Well, I was more than surprised.  You gave me some good ideas and I just might write a visualizer now!

Saul – If there was an award for most animated and informational,  you’d get it!  I attended your sessions on CSS3 & JavaScript.

Rex – You deserve the award for doing as much as you could in 30 minutes!  Unfortunately, the schedule dealt you a short session.  However, you did a great job of going over the basics of ASP.Net MVC.  If you had an hour I imagine you would have been able to dive into more challenging stuff.

Steve – What can you expect when hardware just doesn’t want to go your way!  Joe to rescue!  Your session on tips & tricks in VS.Net was great.  I already have Sara Ford’s book that you mentioned and read it a while back but there’s just so many tips & tricks.  You gave me a few new ones!

Remi – What can I say?  You are a jQuery wizard and your presentation on it had me salivating.  As luck would have it, I was able to put some of it to good use fairly quickly back at the office.

I’m looking forward to next year's Desert Code Camp!

Posted 11.15.2009  #    Comments [1]  | 
# Saturday, 14 November 2009

I’m using SyntaxHighlighter and it’s awesome!  It’s completely JavaScript based and can be put into dare I say any blog engine.  If your engine can take JavaScript that is.  I use dasBlog and found two posts on it that guided me nicely.  Give it a shot.  Spruce up your code snippets in your blog.  Everyone will thank you for it.

Scott Hanselman’s blog got me started and Justin Thirkell finished it off.

Anybody writing code on their blog should take a look at SyntaxHighlighter. 

Posted 11.14.2009  #    Comments [0]  | 

Recently, one of our ASP.Net WebForm app’s had a new requirement for formatted text entry. No problem, the HTML Editor control from the AJAX control toolkit would fit the bill nicely.

In this new version, we were asked to show the count of characters used as a user types and enforce a maximum character count allowed.  Unfortunately, the HTML Editor doesn't have anything built in to give this information and it's a conglomerate of many controls such as iframes and hidden text area's that make this a slightly less than trivial task (at least it felt that way initially).

After some thought on this and seeing a lot of great stuff from jQuery I figured it was up to the task. It didn't disappoint.  Here's what I came up with.

var Editor1 = '#Editor1';
var Editor1CountLimit = 50
var Editor1InfoArea = '#Info';

$(document).ready(function() {
  TrackCharacterCount(Editor1, Editor1CountLimit, Editor1InfoArea);

function TrackCharacterCount(ctl, limit, info) {
  var editor = $(ctl)contents().find('iframe').eq(1);
  $(editor).load(function() {
      var txt = $(this).contents().find('body').text();
      $(info).html(txt.length); //set initial value 
    $(this).contents().keyup(function() {
      var txt = $(this).contents().find('body').text();
      if (txt.length > limit)
        $(info).html(txt.length).css("color", "red");
        $(info).html(txt.length).css("color", "");

My HTML looks like this:


When the document is ready we call the TrackCharacterCount function that takes the ID of the HTML Editor control, then the character limit, and last the element you want to have the character count displayed in.   Be sure to replace these parameters with your values.  

The second iframe contains the contents of the text typed.  The iframe contains a document and the text we are after is in the body tag.  I did some jQuery spelunking in firebug’s console to figure this out.  I added a little touch to have the div element turn red if the user goes over the limit passed into the function. 

In order to enforce the maximum length allowed, I set a custom validator to call the below function.

function ValidateEditor1Length(source, args) {
  var editor = $(Editor1).contents().find('iframe').eq(1);
  var txt = editor.contents().find('body').text();
  var isValid = txt.length > 0 && txt.length <= Editor1CountLimit;
    args.IsValid = isValid;

Some jQuery goodness I found along the way.  My first attempt at counting the characters retrieved the entire HTML (used .html()) and then removed the HTML with a regular expression.  It was a little later that I found .text() which simply returns all of the text without markup.  Thank you jQuery!!!!

Here’s a shot of what it looks like before they go over the limit:


And after the go over the limit…


Now, I’m not a jQuery wizard.  In fact, this is my first jQuery foray and I am extremely impressed with jQuery so far.

AjaxHtmlEditor.zip (1.28 MB)

Read my second post where I add functionality to capture the context menu’s cut and paste.

Posted 11.14.2009  #    Comments [0]  |