Studs in motion

Imagine a carpenter who took the blueprints for a house, read them once and then never checked back to make sure that all the details were right.  That carpenter built the whole house and upon completion the inspector showed up to review the first phase of the work.  The inspector would require that all the drywall would need to be ripped out so that the plumbing and electrical and structural work was done properly.   In fact if the foundation wasn’t properly inspected they may make you tear the whole house down to the foundation.  The mechanisms in place to make sure that the house can be moved into are strict to make sure that people who move into a house are safe and to confirm that the home will meet the minimum requirements of building code.

Final inspection processes are the worst gating mechanisms as far as efficiency is concerned.  Gating mechanisms are used to control bad output/content/products from hitting the public or releasing into production.  This is part of quality control work, which is important.  However, often decisions are made that trump the processes and I’d like to address that idea here.

Principles are basic assumptions that lead to actions for the individual.  If a company has hired an employee who has either under-developed, compromised, or incorrect principles then the outcome will be under-developed, compromised or incorrect.  This applies to me as much as anyone else as an employee.  I’ve had bugs in software because I compromised on my principles for the sake of time or in response to perceived pressure and the outcome was compromised [read: bugs in the code].  Instead I needed to work with the discipline and conviction that were the principles I knew.  This would involve test driven development, careful use of the tools that I had, and doing things the ‘right’ way.  Software Craftsmanship principles that lead to a quality outcome over and over.

Principles lead to practices – they’re things that I do and tell other people about so that when they’re doing what they do they might consider changing their practices based on the principles I’ve informed them of.  Maybe they add test driven development to their repertoire.  Maybe they break changes down into better modules of code so as to make it more  testable.  Maybe they teach me a principle so that I can do a better job because my personal craftsmanship toolbox is added to.  In the end the principles lead to best practices that are applied and expected between myself and the community of developers (or team) that I work with.

Processes – being required/enforced by an outside party (management, C?O’s, clients) – should almost appear as an afterthought.  They should be affirmed, but they should never trigger a gating situation.  Internal processes should exist, but should not come up as tests or mechanisms that lead to surprises.  Instead the value of  the process is to confirm that the right principles and the right practices were in place.  You see if the wrong principles and practices are in place then the technicians employing their trade can either figure out a way to bypass them, or they’ll slow down the whole race to completion of work because they ignored them and the problems weren’t discovered until the end.  If processes are finding issues then the principles and practices should be addressed first because they are the location of the problem.  You don’t need more processes, you need quality in the principles and practices of your team.

I’m learning this about myself the hard way – so this isn’t something that I’ve known all along, it is what I’ve seen in myself.  More processes will just slow down the final work of your team as they reach a release.  However, if the team is not responsive to education and learning proper craftsmanship principles and embracing practices of maturing craftsmen (and craftswomen) then they’re not going to be helped by more processes.  They may be a bad fit for your company or project.

Make sure you know the blue prints.  Make sure you know the best way to do things.  And for heavens sake, don’t let the inspector find your mistakes and make you do the work again – do it right the first time.

** ignoring that a majority of my readers are family who could probably care less

1. Lots of branches in their code to handle every possible variation of event detection
2. Send users away
3. Attempt to use some open source or home rolled equalization library that tries to mask the differences (this way could lie madness)
4. Give the users a lesser experience
5. Create multiple versions of the same thing, each with their own special ‘per device’ sauce (this way also lies madness).

Maybe there’s another option, but I just don’t get why Microsoft has done this to devs.

Today BDConf wrapped up.  It’s targeted primarily towards mobile development and I had a chance to go to their first event in Grapevine, TX in March.  One of the things that they talked about was writing for an ever changing web audience that accesses your site/web application through any number of devices.  However, this sort of added complexity from a major player in the OS department means that one of two or three things is going to happen, and one of them isn’t going to be developer buy in.  I’m convinced that Microsoft is going to have to either adopt some method for giving developers a smaller amount of effort to reach their audience on a Windows 8 tablet, or they’re going to really hurt their end user experience.

I want to create interactive, 3D-space enabled applications with rich interactions that happen to live in a browser, but Microsoft is definitely not reaching out to developers to create a “bold”* new experience in IE10.  They’re not making it easy for end users to have a great, familiar experience.  If you’re switching from an iPad 1 or 2 to a Windows 8 tablet you’re going to get fed up, and move back to the iPad.  If you were to switch from the iPad to the PlayBook you’d be comfortable.  Microsoft has created a barrier to entry, and this is not a good move.  They’re distancing themselves from developers, and they’re distancing their users from rich content.

(update:) Don’t misunderstand me to think that all of what they’ve added to IE10 is a move in the wrong direction, but it’s just not cool that they added a bunch of new HTML5 standards support, and ripped the mobile/tablet market a new hole to support.

* Microsoft employees used the term “bold” numerous times during their announcement presentations today and many people in the media and on twitter noted this.

Worse, in HTML5 web workers you can set up a loop that will take a machine to its knees even if it doesn’t do anything.  I’d make a demo page, but someone will undoubtedly use it for evil, so just trust me that a bad coder doing bad things can use non-flash things to take down your computer.  I can do it without HTML5, too.  I can probably write bad code in every programming language and probably take down every machine – because it’s bad code.  Don’t blame the messenger [AKA Flash]!  Blame bad coders and people who are using it irresponsibly.   There are bugs, there have been security problems, but Flash is just as vulnerable as the browsers, and even your word processing software (ahem, Office + Macros).

I should also point out: I don’t code/program in Flash.  I have nothing to gain from Flash being anywhere (except of course when I play Scrabble on Facebook, which I quite enjoy). I just don’t like it when people point their fingers at one technology or another like has  happened to Flash pointing to the middle of the problem instead of the root.

The idea is not that we should try to implement every fringe, unverified hack and standard, but we’ve been working with bleeding edge HTML4.1/ECMAscript and de facto browser standards for over a decade.  If that’s not clear to the W3C then I’m pretty sure they’re not prepared for 2011 when every major browser vendor will announce that they’re HTML5 ready.  Will there be interoperability issues?  Certainly.  Will there be hacks to get around them?  There already are!

HTML5 is a great concept and I think it will be the de facto standard moving forward from 2011 further.  I’m going to be updating all of my blogs to use HTML5 as time allows.  HTML5 will save money (working on a blog post for that) for companies that deplay the markup, ISPs who have to have provide bandwidth, and save time for end users who do almost nothing but upgrade their browsers to HTML5 ready versions and get the benefit.

One of the problems that made the HTML4/Netscape 4/IE4 wars so difficult was that bandwidth was scarce and unless AOL shipped yet another CD to your house with IE (5 or 6) on it, upgrading could take so long that your grandma’s call on the dial-up connection could be blocked.  However, with DSL and various other broadband mechanisms in place on top of auto-updating browsers the cost of the upgrade is minimal at best.  HTML5 is not the future, it’s the present.  Google pushed Google Wave as HTML5 goodness May 27th 2009 as a presently capable, functional application.  That means that very large corporations reaching millions of users have been using HTML5, even if it required a sub-set of browsers, for a hear and a half.  That means that my iPhone, my BlackBerry, my Droid and an array of other devices running Webkit and my desktop browser are all generally HTML5 capable.

I believe we can use HTML5, even if we don’t get to use it every single day for every possible feature it could provide if cross-browser perfection were achieved.  It’s ready.

JS Patterns

JS Patterns is a site dedicated to the design and development patterns that are not only industry standards, but also patterns that are native to JavaScript (which C++ or Java cannot do natively). This is definitely worth adding to your RSS feed reader.

Dustin Diaz

Dustin happens to work at Twitter, but his site is loaded with good JavaScript tips. If you’re not following his writing I’d suggest you consider doing so.

BlackBerry WebWorks

The WebWorks development/widget framework for BlackBerry devices looks interesting [disclosure: I work for a RIM subsidiary and have nothing to do with this project]. Download the toolkit from github or from RIM’s site and check it out. It’s focused on giving web developers a web-focused interface to develop for the webkit based smartphones.

What they call themselves: jQuery = Library YUI = Library ExtJS = Library MooTools = Framework Prototype = Framework Dojo = Toolkit [cite]

I just got some crap for “not knowing the difference” – which I don’t. It’s just semantics (literally) as far as I know. [cite]

While I think it’s absolutely bad form for people to attack him on his use of those terms synonymously, it connected two apparently opposite ideas in my mind.  It resonated with some ideas I had about a debate that’s been going on in the last few months since Rebecca Murphey suggested that jQuery was not up to the task of being used as a framework in a browser based web application [cite].  Then there’s the jQuery forum discussion of adding JavaScriptMVC as an enterprise branch of the jQuery project [cite].  But here’s the big “revolutionary” idea: jQuery is just a library.  It is not a framework.  It goes well beyond a simple toolkit, but it is an excellent library.

Now, let’s get down to brass tacks.  In the first 10 years of web development there was a lack of craftsmanship and instead a lot of do it yourself or self-directed education by the community as we all learned the emerging web technologies.  I learned my first bits of HTML from HTML Goodies.  I then spent time on other sites and read a few JavaScript for Dummies type books when I got started over a decade ago.  Terms like Library, Toolkit and Framework were never discussed.  However, from an academic level these terms imply things about the code’s purpose and therefore are a critical part of the discussion.

Toolkit

A toolkit is a combination of classes or functions that do not define or limit the design of an application.  A toolkit may have a small handful of functions that allow you to do rollover events (see also: Dreamweaver’s JavaScript tricks).

Library

A library is a collection of classes or functions designed specifically to interface with one particular complex task.  Examples of a library might be an image manipulation library or a canvas manipulation library.  jQuery is a library because it was fundamentally a DOM manipulation library.

Framework

A framework is a collection of classes or functions designed to implement a certain pattern for a specific class of software.  A framework is for specific domains or types of applications such as web applications.  JavaScriptMVC is a framework for developing Model-View-Controller based web interfaces.

Did you see what I did there?  I just diffused a bomb.  OK, not really.  Rebecca Murphey’s direct problem with jQuery (and she has stated this) is not that it is a bad library, it is that it is not a complete framework.  That’s OK, because John and the rest of the jQuery developers have not been trying to make a framework.  John Resig doesn’t want an MVC framework as a direct branch of the jQuery library because JavaScriptMVC goes well beyond the purpose of the jQuery library.  However, the work done to build JavaScriptMVC as a framework that uses the jQuery library is really, really cool and powerful.

Across the spread of the web horizon lies the Dojo toolkit, which has expanded beyond just being a toolkit and really has taken on a multi-tiered approach: it has a toolkit presentation due to its name, but it really is a library (for the DOM like jQuery), but it also has a framework for creating MVC styled applications and taking on the details of a larger built application (See the Dojo Builder for Eclipse or the dojo toolbox).  The purpose of the build tools is to allow you to compile the appropriate libraries from within the larger Dojo framework into a final, smaller file (or files) for inclusion in your project.

So fundamentally you need to ask yourself what your project needs: does it need a toolkit?  I would suggest it just might given that there may only be a handful of tasks that you really need to accomplish.  Does it need a library?  If there is very much DOM manipulation you should evaluate the various libraries and confirm that one of them meets your needs (or has the smallest learning curve, or whatever specifications you have) .  Does it need a framework?  Are you making a website or a web application?  If you’re making a web application you probably need a server side framework such as CakePHP or Ruby on Rails.  You probably want to consider what client side framework you’ll need.  Having rolled my own I can confidently say that rolling your own won’t kill you, but you should absolutely consider the frameworks that do exist because it could save you time and be very extensible in the future when your project goes for another iteration that needs more meat.

This hasn’t been a journey down the yellow brick road to the emerald city, but whether you see lions, toolkits, or bears be aware that the terms do have a technical implication and your use of them may help clear up confusion.  And it could help you in that next interview when the project lead asks you if you prefer to use one religious war starting technology over another more holy religious war starting technology  I’m going to stick with using my new favorite library: vapor.js.

So when you click on this link you want it to be able to refer to your object so that you can work nicely with other libraries or have multiple instances of the object on the page.  The hacky ways to do this might have included adding attributes to the HTML object, doing some sort of global object lookup, or any number of other things I did when I didn’t understand closures.  But here’s what you’re going to do:

<html>
<head>
<title>Never Gonna Give You Up, Closures!</title>
<script src="http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js"></script>
<script>
function MakeItCloserWithClosures()
{
/**
Assigning a variable 'that' to have the value of 'this' creates a reference that maintains scope through closure, so sub-functions/lambdas, can reference that as a variable that is in scope to call functions withint this object
*/
var that = this;
$('.makeMeClosureFriendly').click(function(){that.rickRollTheUser();return false;});
}
MakeItCloserWithClosures.prototype.rickRollTheUser = function(){
document.location.href = 'http://www.youtube.com/watch?v=3HrSN7176XI';
};
/* use jQuery's ready function to initialize the object, which should attach it to the HTML objects. */
$(document).ready(function(){ new MakeItCloserWithClosures(); });
</script>
</head>
<body>
<a class="makeMeClosureFriendly" href="http://www.digg.com/closures-are-easy">
Closures are easy!
</a>
<body>
<html>

There are a number of possible issues with the above code as far as scope is concerned: 1) the new object is not assigned to a variable for future reference (which we’ll pretend is awesome and the best idea ever), and 2) since it isn’t assigned there’s no global variable that we could attach to inside of the click event handler (function).  Except that with closures we can use the code’s reference to ‘that’ and it will refer back to the originating object and Rick Roll the user.  Closures are the best for handling references back to an object that needs to touch code, but not be global in scope or concern itself with as much interaction with other libraries.

I like to think of closures as ‘scope tunnels’ that can linger on for some time as long as the objects that reference them still exist.  In complex web applications being able to reference back to a parent object can save lines of code, confusion and can help call functions that are aware of other variables, details, and settings that exist within a JavaScript/ECMAScript object.  Fewer lines of code to debug is a big win, and fewer lines of code to maintain is even better.  I hope this helps!

Where will you use closures today?  See the demo to get Rick Rolled.  Please leave questions in the comments.

JQuery may get a new implementation or a sub-library that can handle being in a thread, but for now, don’t count on it inside web workers.

• The YUI compressor doesn’t require you to pre-validate your code with tools like JSlint, which are nice, but not very friendly for beginner or pressed-for-time developers.  The JSlint site puts it well: JSLint will hurt your feelings.  I can deal with some hurt feelings myself, but managing browser quirks like IE’s inconsistent handling of ‘==’ verses ‘===’ means JSLint isn’t as handy as it could be for large files with lots of comparison operations.  I like well written code.  No.  I love well written code.  Not all code shoppes have time for syntax evaluation – if it works they’ll ship it – and YUI Compressor works great for this situation.  You can use the ‘-v’ parameter when executing the compressor at the command prompt to have it output any hints or suggestions for better syntax or potential errors.
• The compressor optimizes functions and classes by managing variable instantiation and reducing the number of places in the code where this sort of memory allocation has to happen so that the beginning of the function contains all variable instantiations and your code can then execute without extra overhead for inline instantiations (especially if someone made the bonehead move of instantiating a variable in a loop!).
• The compressor creates files that have no comments in them so JavaScript parsers  can parse a file that has been parsed and then output by a parser in parser optimized form.  The output code has a whole lot less fluff and generally looks like what a parser would hope a file would look like.  To make a comparison that would be like me taking my thoughts, putting them into a brain just like yours, having that brain output the words perfectly so that you could read them and understand them without any questions and the fewest number of possible words.  Its a JavaScript communications breakthrough.
• The YUI Compressor can also be integrated with a build script so that your build engine (such as Ant or Nant) could automate the creation of the compressed or optimized files.

I have personally found the YUI Compressor to be invaluable and it has helped improve the loading time of the web applications that I work on substantially.  Being able to tell users (and the sales channel) that the slower loading web application has been improved to load 27% less data (while adding features) almost two years ago was a major win.  Watching their faces as I demonstrated how much faster the code was was icing on the cake.

Does everyone need to use the YUI compressor for every project?  Maybe not.  But I believe that it is probably the best tool available at this time to help professional web application developers to squeeze out that extra bit of performance without hand-tweaking code that could otherwise be thousands of lines of code to evaluate.  I have more performance optimizations I will find, I’m sure, but using YUI Compressor is a no-brainer and I hope you’ll find it gives you peace of mind and mind blowing performance improvements when it comes to file download sizes and speeds.

My buddy Dave O’Hara sent me this link: 7 Rules of Unobtusive JavaScript. A good overview of why you should be coding unobtrusively (which I do in as many cases as possible) and also explains some good things about namespacing and object access.

I’m trying to learn about TDD and JavaScript which has been a bit harder than I expected: we need more of this in the JavaScript community!  Here’s a bit over at the Ajaxian on doing TDD with JsMock.