Developing, Code and Context for Hobbies: Brewing

[Skip this part if you just want to read the article and not why I’m writing it]

The podcast This Developer’s Life is one I’ve enjoyed for some time now.  It’s a great NPR-styled show that looks to investigate various facets of the developer’s interaction with the world.  At the end of the most recent show on Faith (which I would suggest is about courage and not faith in a historical or religious sense) Scott Hanselman mentioned that suggestions for the show were welcome.  On Twitter I suggested the topic of hobbies being impacted by the the developer’s mindset and mentioned that it really impacted my brewing and cooking.  Since Twitter is public, Barry Forrest asked me to articulate my thoughts on this – and so I shall.

[OK, Start Here!]

Software development is very much about order, understanding, and taking complex ideas and breaking them down to their simplest parts.  It’s also about being lazy where you can [See also: Perl].  So ideally you’ll take a complex idea, break it down into its component parts and then write code that executes that complex code in the least amount of lines with zero bugs.  Ideally.  Reality is that it can take a lot of code and there are usually at least a few bugs.

The thing that was so hard for me to begin wrestling with as a software developer was the complex to simple conversion process.  The breaking things down to their bare components, and then breaking those components down to their raw concepts.   This is done so that you can go from a sentence or paragraph describing a feature or idea in written language to a working piece of software that does the very thing that was described (and hopefully more).

I have written or helped write dozens of applications and thousands of features in the 15 years of my career.  All of that was practice in craftsmanship, but as I grew as a developer I noticed that it was changing me.  It was changing my thought processes so that when I looked at any of my hobbies (music, photography, cooking, and more recently brewing) they were a rich set of components that I knew as a collection of steps.  Like classes that were called in order to write a played guitar piece, a coded photograph, a compiled dish, or an abstracted ale. I’m going to simplify this article by hammering out my thoughts on brewing as I think both Barry and Rob (involved in the Twitter discussion) brew.

The following ideas below may be out of order, they may have some assumed nuances, and they might need some clarifications.  Throw me a message in the comments and I’ll do my best to fix or clarify things.

Knowing Your Problem/Goal/Recipe

Brewing beer is not just making a beverage.  You’re not just trying to make something that can be consumed.  You’re trying to craft either a clone recipe, another brewer’s recipe, or your own creation.  You may be trying to improvise to learn ingredients, or you may be trying to hone in on an ideal you’re imagining, but haven’t brewed yet.  As a software developer I aim to have a user story that clearly states the outcome I’m after.  You don’t start coding until you know your goal.

You should not start brewing until you have a recipe (which is equivalent to a user story).  It might be an experimental recipe [this is one of mine], but even still you have a goal.  Your recipe helps set constraints and it helps you begin to set expectations.

Knowing Your Tools

Visual Studio, Eclipse, or Chrome Web Inspector are examples of tools that developers may lean on to help create better code, better programs, and have a good technique for debugging or understanding existing code.  As a brewer you have a brewing setup that involves a kettle, heat and any number of other vessels for getting the sugars from barley (or other grains), hops, and water into a state that the yeast can eat.  There are different techniques to brewing, but no matter what you’re doing – you need to understand the process and the tools involved.

I spent a lot of time investigating the processes available to me as a brewer before I started brewing.  My brother – who taught me how to brew – showed me the brew in a bag, extract kit, and all-grain/sparge methods in 2 days so that I could see how simple it can be, and how complex it can be.  I began reading heavily about what control I could have with the different techniques.  How hard would it be to make mistakes and corrections with each one?  What were the expenses with the different tools?

I started with brew in a bag because the tools required were fewer, the results were more controllable than an extract kit, and I could begin learning and experimenting through experience.  It didn’t take long for me to jump to an all grain/sparge setup, but when I did that I had to re-learn the tools at my disposal.  How did the vessels retain temperature?  How easily could I transfer liquids between the kettle, cooler (mash tun), and the fermentation buckets?

If I knew the keyboard shortcuts to maximize my efficiency in various development tools, I sure as heck worked out the same sorts of efficiencies in my brewing.  What configuration of my brewing equipment gave me faster transfers, better temperature control, and maximum extraction efficiency?  I had to learn my tools.  Consistency in results built trust in my tools.  My tools produced better beers because I knew them.

Knowing Your Process

In building my recipes I take into consideration that I’m going to need to have water at various temperatures at different times.  I’m going to need various grains (or sugars), one or more ounces of hops, and yeast.  I’m going to add them at different times.  I need to know when they are to be added, mixed, resting or whatever the step is.  In programming I’ve found that doing the exact same steps in the exact same order with the exact same tools will give me the exact same results. OK, I’ll admit that isn’t always the case, but it’s within a margin of error.  Home brewing is about honing in on those same results with the same process.

Testing the Outcome of Each Step

When brewing, and in coding, tests are there to inform you as to what’s going on in your code (or your brew).  If you test for starches in the water you’ll know you don’t have the sugars you need for the wort.  If you test for pre-boil gravity you’ll know you don’t have enough (or too much, or just right) sugars in the wort.  If you test everything as you move through your brewing process you’ll be able to learn your equipment better, fix (some) mistakes, and hone in the desired outcome.

Teaching the User

Software usability matters.  It matters in APIs, it matters in user interfaces, and it matters in the steps we present users.  Users have been taught how to access and interact with software for decades now.  Beer has been more accessible for much longer, however, many beer drinkers don’t have exposure to a diversity of beers and don’t understand many of the styles.  Walking users through features of software should not be required, but documentation should exist.  Describing appearance (color, head, carbonation level), flavors (malty, hoppy, bitter), aromas (grassy, piney, fruity, carmely), and textures (mouthfeel/viscosity) can really enhance the experience of the drinker of your beer.  Talking or writing about what makes this beer special by style, history, brewing process or ingredient list gives consumers access to parts of the beer that they may not have previous exposure to.

On more than one occasion I’ve helped talk people through IPAs and they’ve developed a taste for them.  I remember not liking the first 5 or so IPAs I had until I had an O’Dell Myrcenary.  It was like switching from Windows to OS X.  It felt weird until it felt right.  I’m still learning to love lagers and Linux.

Software development taught to me think about the steps, the context, the history, the user’s needs and all (or many) of the ways a problem can be broken down and solved.  It taught me about clean code.  Brewing has become a parallel process that has steps, context, history and user needs. I’ve seen how recipes can be created with complexity and nearly identical beers produced with fewer ingredients or steps [all grain vs. extract, or adding in DME to help get your gravity higher without a bigger mash tun].

There’s a lot I’m still learning about the craft of software development, and there’s a lot I’m still learning about the craft of brewing – but they’re the same.  Next time let’s talk about barbecue!

Opera WebKit

Creative Commons: http://www.flickr.com/photos/cyron/105110722/sizes/s/in/photostream/

Creative Commons: http://www.flickr.com/photos/cyron/105110722/sizes/s/in/photostream/

In the movie Casino Royale James Bond chases a villain up into the scaffolding of a tall crane.  It makes for amazing cinematography, a great fight, and heightens (no pun intended) a scene that would have been a relatively standard bar room brawl. But the chase and fight didn’t start there.  They started somewhere below and they worked their way there.  As it turns out logical arguments, which hopefully have less blood and risk than physical fights, need to be restrained to the lowest possible point of agreement.  Otherwise it’s like having a fight on a crane that is floating in mid-air.  Since that doesn’t exist outside of the Matrix, let’s assume that’s either not possible or a bad idea.

Opera is a business.  Business offer users/customers/beings/entities solutions.  But they do that based on a business model.  In the excellent book “Running Lean” the auther,  Ash Maurya, points out that the business model is what the company is actually selling.  Whatever the solution may be, it is based on the business model.  If the business model is stable, and a workable business, then the solution can be discarded as time requires it and paradigms shift and a new solution can be put in place on top of the business model.  Opera just changed their solution, but not their business model.  The jump to webkit is based on offering a solution that they think is viable based on their business model.  That’s good business sense.

Web developers are assuming that this change is based on some weird desire to kill the Internet, or destroy diversity.  This is a bit presumptuous.  If anything my 13 years in the industry has taught me it is that diversity fails to go away.  For the sake of argument when I went to BD Conf and saw a wide range of qualified speakers deliver presentations on web development they complained consistently that just because someone had Android and Android had a webkit based browser you couldn’t assume anything.  Why is that?

The answer is because every version of Android has its own twist from the handset vendor or the service provider.  And then there are the old devices.  Those don’t seem to go away.  Partially because of two year contracts and hand-me-downs, and partially because some phones work ‘well enough’ for users and they don’t care;  But they DO want your website to work on their mobile devices.  Many, many devices work with Opera Mobile or Opera Mini and those users take for granted that sites will be workable.  Except that over and over again I see developers only testing on iOS or Android and calling it good enough. You can’t gripe about the philosophy of this business change from Opera if you are only paying them lip service.  Use Opera on the desktop, the mobile, and even the Wii and test on it if you’re actually passionate about their solution offerings.

One last detail is this: RIM/BlackBerry [disclosure: they are my former employer] is using Chromium for their browsers and has been for a while.  They are using the same code base, but they are not shipping the same code.  How can their BB10 browser score higher on HTML5 tests if they are?  Opera will not be shipping the identical code.  They will ship variances.  They will update on different cycles.  They will do what their business model defines as a good procedure.

Don’t get angry at Opera and state that they’re ruining diversity – they’re not.  They’re changing their solution based on the details of the business model, which you may not know specifically.  They may have a really great reason to do so that has nothing to do with following Android, iOS or BlackBerry/RIM.  Opera has long known it needs to differentiate itself in the market to stay alive and competitive – that’s a major part of their business model.  We need to argue about more relevant things like which James Bond movie is best because unless we’re part of the leadership of a browser vendor who knows our business model, we really can’t call those shots anyway.

You’ll excuse me, though, I have to get back to writing backwards compatible, future friendly, cross-platform, web standards compliant code.  Code that works in all the variations of WebKit.

Dear Friends and Family: Stay Away from Windows 8

I don’t normally post a lot of tech advice here.  People ask me for it sometimes, and I give it because they ask.  I’m stepping outside of that pattern to say that you should avoid Windows 8.  It is to user interfaces what being kicked in the face is to life experiences.  In case you didn’t major in analogy in school I’ll put it like this: using windows 8 will be painful, unfamiliar, and they have moved all of your cheeses.

Windows 7 was awesome. I upgraded to it the day it was released on all 4 of my family’s computers.  It was that good.  Windows 8 is a major let down with lots of potential confusion.  Windows 8.5 may be better. They may release Windows 8.1 (remembers Windows 3.1?) that fixes some of the major issues Windows 8 has.  But for now, stay away from it.

Reasons for this, you ask? 1) The move to a semi-tablet focused interface means that a lot of things you know about Windows are gone by default.  There is no small, easy to navigate start menu.  2) The start button is gone if you switch to desktop mode.  If you press the Windows key on your keyboard you’ll be faced with the tablet application picker (AKA: Windows Metro).  3) They’re copying Apple and creating a Windows store just like iTunes and the App Store.  This will mean that over time Microsoft will limit what developers can publish and will censor material based on their corporate needs and drive.  This is unacceptable.

If you make change for change’s sake, you’re just annoying users who have become accustomed to a pattern.  If you benefit the user with these changes, then there’s a trade off that hopefully most people will see the value in.  This is not that positive change, this is just making change to pretend you’re innovating to ‘lead the market’.  Bad move, Microsoft, bad move.

<done ranting, sorry>

Loading CKEditor with jQuery Promises

I needed to load up the CKEditor library dynamically as part of a module pattern using jQuery’s promises.  I kept getting issues about broken paths to files like the skin and the language files due to the context not being the root server path.  Because the software I’m working on is installed internationally and on all sorts of servers with different paths I couldn’t use the CKEditor config.baseHref setting.  The fastest way to accomplish this is through a custom load script (instead of $.getScript) like so:

function loadScript(srcURL) {
 var deferred = new $.Deferred();
 var e = document.createElement('script');
 e.onload = function () { deferred.resolve(); };
 e.src = srcURL;
 document.getElementsByTagName("head")[0].appendChild(e);
 return deferred.promise();
 }

Then you can just pass loadScript the URL to CKEditor (or another complex library that will do sub-sequent downloads and path references) and it will execute in the global space.

Principles Inform Practices Which Inform Process

Continuing in my nerdy output of management concepts** I want to highlight an important idea about management processes.

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

Windows 8, Internet Explorer 10 and Web Developers

I just got done reading the specs on Internet Explorer 10’s tablet ‘features’ in Windows 8.  This new set of features is incredible on the surface, but as a developer I’m flabbergasted that Microsoft has decided to ignore the de facto standards and now has created yet another touch/tablet interaction model.  I’m not flabbergasted a company would do that, because Apple did it with the iPhone and iPad to create the de facto standard that RIM (disclosure: I work for a subsidiary of RIM) and others have followed.  What this means for developers who are trying to reach the widest possible audience is that their web applications are going to have to choose between:

  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.

Flash: Not as Evil as Bad Coders

I’m tired of the argument that Flash crashes browsers, consumes CPUs (and thus electricity and your laptop battery), and keeps your fan going.  Guess what?  Bad code outside of flash, and in HTML5, can do the same thing!  Open Google Chrome and launch Twitter, Facebook, and Google Reader and check your resources.  Is Chrome eating up system resources?  You’ll probably not be surprised to discover that it is.  Advertisers are using Flash and they’re using it in intensive ways.  Flash by its nature sits as a plugin for most browsers (Chrome actually being an exception) but those browsers and Flash rely on developers doing certain things.

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.

HTML5 *Is* Ready

In what has to be one of the weirdest declarations of 1990’s Netscape4 vs. IE4 thinking the W3C’s Philippe Le Hegaret has suggested that we not deplay HTML5 yet in web projects.  I’m pretty sure that if we wait until all the web browsers are ready for HTML5 we’ll get the go-ahead in 2036, about the time I’m ready to retire.  Some poor blokes will still be on IE6 with more malware and viruses than Windows ME can deal with and the W3C will be telling us that we should still step into the HTML5 pool with gingerness.  Forget about HTML5 as a stable standard since we have things like HTML5Boilerplate, and JavaScript patches as well as things like Google Chrome Frame.

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.

Design & Development Links

Along the line of software craftsmanship on the web here are some handy sites I’ve seen recently:

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.

Toolkits, Frameworks, and Libraries, Oh My!

On Monday the 4th of October Chris Coyier of CSS Tricks wrote on Twitter:

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.