Over the past few weeks I put together this talk for my team at GE to help get everyone on the same page with AMD modules. I figured it’d be cool if I removed any GE specific stuff and open sourced the presentation, so here it is!

The video is around 35 minutes long and there’s a slide deck available on Github that has clickable links and whatnot. Enjoy!

Slidedeck on Github

In yesterday’s post I made the case for Web Components so today let’s dive back in and look at Custom Elements.

Yesterday I did a post on the HTML5 <template> tag which is part of the new Web Components standard. I didn’t go into a ton of explanation as to why I’m so interested with this spec and I think jumping right to the <template> tag was probably pretty confusing for folks who don’t have the same needs as me. I want to back up a bit and present a high level overview of Web Components and then illustrate why this is such an important concept.

If you’ve been following the Google Chrome release announcements you may have noticed some interesting terms popping up as of late. Phrases like “Shadow DOM”, “Custom Elements” and “Template”. These are all part of a new standard referred to as Web Components and the latest versions of Chrome are starting to implement them. Basically a Web Component is an encapsulated bit of markup, styles and script that allow you to reuse widgets across your page without worrying about accidental collisions. For a practical example consider Twitter Bootstrap and its myriad of buttons, dropdowns and badges. Bootstrap comes with a lot of CSS which means, right out of the gate, there are a ton of class names which you probably shouldn’t use for your own elements. Want to define a class of .container? Too bad, Bootstrap already uses that name. Want to upgrade Bootstrap in a few months? OK, but you need to double check that none of their new classes conflict with any of yours. Kind of a pain, right? Wouldn’t it be awesome if you could use all the little widgets from Bootstrap and not worry at all about possible collisions? Well, that’s what Web Components are trying to solve and so today I want to look at one part of the Web Components standard: The Template Tag.

hubot. How on Earth did we exist without you? Really I feel like I can demarcate my life into two phases: the time before hubot, and all the awesomeness after. For those not in the know, hubot is an amazing chatbot created by the team at Github. Out of the box he has a ton of cool features but once you start digging into the hubot scripts catalog things get WAY more interesting.

One of the most exciting projects is play, a combination iTunes remote and streaming music player. Play lets you broadcast music to everyone on your team and allows anyone in the chatroom to dictate what goes into the queue. Personally, I don’t use iTunes all that much, opting instead to use rdio for all my music needs. I figured, wouldn’t it be cool if hubot could do all the same stuff he does for play…but with rdio! So that’s what I set out to build.

If you’ve spent much time with preprocessors like LESS, SASS/SCSS or Stylus you’ve probably discovered their one rather crippling flaw: debugging. With thousands of lines of LESS code suddenly turning into even more thousands of lines of CSS it can become nearly impossible to tell where a particular style comes from. Inspecting CSS used to be the domain of the Chrome Developer Tools and Firebug but now that our CSS is machine generated there’s no longer a link between the style at line 2137 and the LESS file that generated it. Thankfully the Chrome team is addressing this problem but their current focus is on SASS. Today I’ll teach you how to rework your LESS processor so it plays nice with Chrome and reunites you with your old friend, the CSS inspector.

After my last post @stevensacks tweeted at me that he was having issues getting node FileSystem commands to work in grunt. After a bit of poking around I noticed that there was no call to grunt’s async method, which was probably preventing the process from finishing properly. So today’s post is a primer on async grunt processes, and how to make sure your node and grunt syntax is setup correctly.

I’ve been working with require.js a lot lately and found it really improves the way I manage my code. I had previous experience with require in the context of some of my Backbone posts but I’d never used it on a more traditional multi-page site before. The workflow to setup require on a multi-page site can be a little confusing at first so I’ll try to walk you through the specifics.

If you’re using Mountain Lion and have the need to setup a vhost it can be a little tricky to get the ball rolling. I’m going to do my best to detail the process that I use to set everything up. Hopefully you can use these same steps to square aware your system.

Table of Contents

Factories encapsulate and separate object creation from the rest of your code. In situations where the creation of an object can be complex or subject to change a factory can act as a nice buffer to help keep things tidy. Without proper planning Factories can lead to class explosions; as a result the pattern can be both a blessing and a curse depending on how it’s used.