Adventures in JavaScript Development

On Choosing a Syntax Highlighting Scheme for Your Next Presentation

| Comments

This is a projector screen:

You will notice that it is white, or some reasonable approximation thereof. It is probably made of a reflective material that sparkles a bit when light shines on it. Still: white.

Do you know what color this screen is when you use a projector to display this image onto it?

It is still white. Crazy, I know! The thing is, projectors cannot project black; they can only not project any light on a region that you intend to be black.

Chances are you are reading this on an LCD screen of some sort, where the rules are completely different: they usually start out essentially black, not white, and pixels are brightened as required. The pixels that start out dark can generally stay pretty dark.

On a projection screen, on the other hand, the appearance of black is nothing more than an optical illusion, made possible by the projector projecting brightness everywhere else.

What does this mean? Lots of things, but in particular, it means that you should never, ever, ever use a color scheme with a dark background – no matter how high-contrast and good it looks on your monitor – if you will be presenting using a projector that is projecting onto a white screen. At least, assuming that you intend for your audience to be able to actually read the code.

Presentation Color Schemes That I Have Loved

  • Ben Alman’s TextMate Theme: Ben has tailored this to be incredible for presenting about JS code.
  • Tomorrow Theme: The light-background flavor is decent, but could probably stand to be higher-contrast, at least for some languages.

Show & Tell

| Comments

I spoke at the Times Open Source Science Fair a couple of weeks ago. I’ll admit that I was pretty skeptical of the concept when I was first asked, but as someone who used to work as an editor at a tiny newspaper in upstate New York, I wasn’t about to say no when the Times asked me to come say hi.

A few days before the event, I got an email asking me for information about what I’d be showing off at my booth. Booth? Wat? They weren’t kidding about the science fair thing, but what the heck was I going to show at a booth?

It turns out this is basically the best idea ever. I recruited my Bocoup colleague Rick Waldron to join me, and together we spent a whirlwind hour showing off robots powered by JavaScript to an endless stream of people walking up to our booth. Rick did a great job of setting up a demo that people could play with, and they took turns moving sliding potentiometers that controlled servos that moved an arm with a gripper at the end, trying to pick up Bocoup stickers. Ours was one of about a dozen booths showing off open-source projects, and the room was a wonderful madhouse.

After a break for dinner, I, Jeremy Ashkenas, and Zach Holman each gave 20-minute talks, but the talks were really just icing on the evening. The “science fair” format promoted such intentional interaction, in a way that traditional conferences just can’t, no matter how great the hall track or the parties may be. The format invited and encouraged attendees to talk to the presenters – indeed, if they didn’t talk to the presenters, there wasn’t much else for them to do. By the time the official talks came around, a super-casual, super-conversational atmosphere had already been established, and the energy that created was tangibly different from any event I’ve been to before.

I love conferences, and the sharing of knowledge that happens there, and there’s a whole lot to be said for their speaker-audience format – don’t get me wrong. But I’d also love to see more events figure out how to integrate this show and tell format. “Booths” don’t need to mean “vendors trying to sell things” – they can actually be a great opportunity to facilitate conversation, and to let open source contributors show off their hard work.

Recent Talks

| Comments

A post from Alex Russell reminded me that I’ve given a number of talks in the last few months, and some of them even have video on the internet.

I’ve been ridiculously spoiled to get to travel all over the place these last few months – San Francisco, New York, Amsterdam, Berlin, Brighton – and speak at some truly first-class conferences, sharing the stage, sharing meals, and sharing beers with some seriously amazing folks. My recent news means I’ll be doing a lot less travel for the next little bit, but I’m ever-so-grateful for the opportunities I’ve had and the people I’ve gotten to see and meet these last few months.

Writing Testable JavaScript

This is the first talk I’ve developed that I’ve managed to give several times in rapid succession: three times in six days, including at Full Frontal, the online JS Summit, and to a group of developers at the New York Times. There’s no video yet, but the slides are here, and there should be video soon, I think.

JS Minty Fresh

A fun talk at Fronteers about eliminating code smells from your JavaScript. The best feedback I got afterwards was from an attendee who said they felt at the beginning of the talk like the material was going to be too basic for them, and by the end of the talk, the material was nearly over their head. “I guess that makes you a good teacher,” he said. Aw!

Rebecca Murphey | JS Minty Fresh: Identifying and Eliminating Smells in Your Code Base | Fronteers 2012 from Fronteers on Vimeo.


If you like this, you should also check out the screencasts we released at Bocoup earlier this week.

Beyond the DOM: Sane Structure for JS Apps

An update of my code organization talk, delivered at the jQuery Conference in San Francisco. It’s fun for me to see how my thinking around code organization has evolved and improved since my first, now-almost-embarassing talk at the 2009 jQuery Conference in Boston.


Johnny Five: Bringing the JavaScript Culture to Hardware

This one was from the New York Times Open Source Science Fair, a fun night of about a dozen folks presenting open-source projects at “booths,” followed by short talks about open source by Jeremy Ashkenas, me, and Zach Holman. The slides don’t necessarily stand on their own very well, but the short version is: use JavaScript to make things in the real world, because it’s ridiculously easy and ridiculously fun.

Getting Better at JavaScript

I put this together as a quickie for the Berlin UpFront user group – it was the first talk I gave with my broken foot, and the last talk I’d give for weeks because I lost my voice a couple of hours later. There’s not a whole lot here, but it was a fun talk and a fun group, and a topic that I get plenty of questions about. Again, no video, but here are the slides:

This Is the Cup of Coffee

| Comments

This is the cup of coffee I was making earlier this week when Melissa gave me a thumbs-up while she talked on the phone to a woman in Pennsylvania who had just finished telling Melissa that yes, indeed, after 10 weeks or three years of waiting depending on how you count, a 29-year-old woman who’s due to give birth in Iowa at the beginning of February has decided that Melissa and I should be so lucky as to get to be her baby girl’s forever family.

Most people get to post ultrasound pictures on Twitter at moments like these, but for now this will suffice to remind me of the moment I found out I would get to be a mom. My head is spinning, and while on the one hand it’s a little difficult to fathom that this is all just 10 weeks away, on the other hand I’m counting down the days.

Our adoption will be an open one; the meaning of “open” varies widely, but in our case it means we talked to the birth mother before she chose us, we’ll be meeting her in a few weeks, we’ll do our very best to be in Iowa for the delivery, and we’ll stay in touch with letters and pictures afterwards. Melissa and I are grateful that we’ll be able to adopt as a couple, though we are saddened that we have to adopt outside of our home state of North Carolina in order to do so. It’s important to us that our child have both of us as her legal parents, and I don’t hesitate to say that it’s downright shitty that we have to jump through significant legal and financial hoops – and stay in a hotel in Iowa with a newborn for an unknown number of days – to make it so. It is what it is, and good people are working and voting to make it better, and it can’t happen fast enough.

I’ve learned a lot about adoption these past few months, and I know a lot of people have a lot of questions, some of which they’re reluctant to ask. If you’re interested in learning more, I highly recommend In On It: What Adoptive Parents Would Like You to Know About Adoption. You’re also welcome to ask me questions if you see me in real life or on the internets – I can’t promise I’ll know the answers, but I promise to do my best.

In the meantime, wish us luck :)

A Baseline for Front-End Developers

| Comments

I wrote a README the other day for a project that I’m hoping other developers will look at and learn from, and as I was writing it, I realized that it was the sort of thing that might have intimidated the hell out of me a couple of years ago, what with its casual mentions of Node, npm, Homebrew, git, tests, and development and production builds.

Once upon a time, editing files, testing them locally (as best as we could, anyway), and then FTPing them to the server was the essential workflow of a front-end dev. We measured our mettle based on our ability to wrangle IE6 into submission or achieve pixel perfection across browsers. Many members of the community – myself included – lacked traditional programming experience. HTML, CSS, and JavaScript – usually in the form of jQuery – were self-taught skills.

Something has changed in the last couple of years. Maybe it’s the result of people starting to take front-end dev seriously, maybe it’s browser vendors mostly getting their shit together, or maybe it’s front-end devs – again, myself included – coming to see some well-established light about the process of software development.

Whatever it is, I think we’re seeing the emphasis shift from valuing trivia to valuing tools. There’s a new set of baseline skills required in order to be successful as a front-end developer, and developers who don’t meet this baseline are going to start feeling more and more left behind as those who are sharing their knowledge start to assume that certain things go without saying.

Here are a few things that I want to start expecting people to be familiar with, along with some resources you can use if you feel like you need to get up to speed. (Thanks to Paul Irish, Mike Taylor, Angus Croll, and Vlad Filippov for their contributions.)


This might go without saying, but simply knowing a JavaScript library isn’t sufficient any more. I’m not saying you need to know how to implement all the features of a library in plain JavaScript, but you should know when a library is actually required, and be capable of working with plain old JavaScript when it’s not.

That means that you’ve read JavaScript: The Good Parts – hopefully more than once. You understand data structures like objects and arrays; functions, including how and why you would call and apply them; working with prototypal inheritance; and managing the asynchronicity of it all.

If your plain JS fu is weak, here are some resources to help you out:

Git (and a Github account)

If you’re not on Github, you’re essentially unable to participate in the rich open-source community that has arisen around front-end development technologies. Cloning a repo to try it out should be second-nature to you, and you should understand how to use branches on collaborative projects.

Need to boost your git skills?

Modularity, dependency management, and production builds

The days of managing dependencies by throwing one more script or style tag on the page are long gone. Even if you haven’t been able to incorporate great tools like RequireJS into your workflow at work, you should find time to investigate them in a personal project or in a project like Backbone Boilerplate, because the benefits they convey are huge. RequireJS in particular lets you develop with small, modular JS and CSS files, and then concatenates and minifies them via its optimization tool for production use.

Skeptical of AMD? That’s no excuse to be doing nothing. At the very least, you should be aware of tools like UglifyJS or Closure Compiler that will intelligently minify your code, and then concatenate those minified files prior to production.

If you’re writing plain CSS – that is, if you’re not using a preprocessor like Sass or Stylus – RequireJS can help you keep your CSS files modular, too. Use @import statements in a base file to load dependencies for development, and then run the RequireJS optimizer on the base file to create a file built for production.

In-Browser Developer Tools

Browser-based development tools have improved tremendously over the last couple of years, and they can dramatically improve your development experience if you know how to use them. (Hint: if you’re still using alert to debug your code, you’re wasting a lot of time.)

You should probably find one browser whose developer tools you primarily use – I’m partial to Google Chrome’s Developer Tools these days – but don’t dismiss the tools in other browsers out of hand, because they are constantly adding useful features based on developer feedback. Opera’s Dragonfly in particular has some features that make its developer tools stand out, such as an (experimental) CSS profiler, customizable keyboard shortcuts, remote debugging without requiring a USB connection, and the ability to save and use custom color palettes.

If your understanding of browser dev tools is limited, Fixing these jQuery is a great (and not particularly jQuery-centric) overview of debugging, including how to do step debugging – a life-altering thing to learn if you don’t already know it.

The command line

Speaking of the command line, being comfortable with it is no longer optional – you’re missing out on way too much if you’re not ready to head over to a terminal window and get your hands dirty. I’m not saying you have to do everything in the terminal – I won’t take your git GUI away from you even though I think you’ll be better off without it eventually – but you should absolutely have a terminal window open for whatever project you’re working on. There are a few command line tasks you should be able to do without thinking:

  • ssh to log in to another machine or server
  • scp to copy files to another machine or server
  • ack or grep to find files in a project that contain a string or pattern
  • find to locate files whose names match a given pattern
  • git to do at least basic things like add, commit, status, and pull
  • brew to use Homebrew to install packages
  • npm to install Node packages
  • gem to install Ruby packages

If there are commands you use frequently, edit your .bashrc or .profile or .zshrc or whatever, and create an alias so you don’t have to type as much. You can also add aliases to your ~/.gitconfig file. Gianni Chiappetta’s dotfiles are an excellent inspiration for what’s possible.

Note: If you’re on Windows, I don’t begin to know how to help you, aside from suggesting Cygwin. Right or wrong, participating in the open-source front-end developer community is materially more difficult on a Windows machine. On the bright side, MacBook Airs are cheap, powerful, and ridiculously portable, and there’s always Ubuntu or another *nix.

Client-side templating

It wasn’t so long ago that it was entirely typical for servers to respond to XHRs with a snippet of HTML, but sometime in the last 12 to 18 months, the front-end dev community saw the light and started demanding pure data from the server instead. Turning that data into HTML ready to be inserted in the DOM can be a messy and unmaintainable process if it’s done directly in your code. That’s where client-side templating libraries come in: they let you maintain templates that, when mixed with some data, turn into a string of HTML. Need help picking a templating tool? Garann Means’ template chooser can point you in the right direction.

CSS preprocessors

Paul Irish noted the other day that we’re starting to see front-end devs write code that’s very different from what ends up in production, and code written with CSS preprocessors is a shining example of this. There’s still a vocal crowd that feels that pure CSS is the only way to go, but they’re starting to come around. These tools give you features that arguably should be in CSS proper by now – variables, math, logic, mixins – and they can also help smooth over the CSS property prefix mess.


One of the joys of writing modular, loosely coupled code is that your code becomes vastly easier to test, and with tools like Grunt, setting up a project to include tests has never been easier. Grunt comes with QUnit integration, but there are a host of testing frameworks that you can choose from – Jasmine and Mocha are a couple of my current favorites – depending on your preferred style and the makeup of the rest of your stack.

While testing is a joy when your code is modular and loosely coupled, testing code that’s not well organized can be somewhere between difficult and impossible. On the other hand, forcing yourself to write tests – perhaps before you even write the code – will help you organize your thinking and your code. It will also let you refactor your code with greater confidence down the line.

  • A short screencast I recorded about testing your jQuery with Jasmine.
  • An example of unit tests on the jquery-bbq plugin.

Process automation (rake/make/grunt/etc.)

Grunt’s ability to set up a project with built-in support for unit tests is one example of process automation. The reality of front-end development is that there’s a whole lot of repetitive stuff we have to do, but as a friend once told me, a good developer is a lazy developer: as a rule of thumb, if you find yourself doing the same thing three times, it’s time to automate it.

Tools like make have been around for a long time to help us with this, but there’s also rake, grunt, and others. Learning a language other than JavaScript can be extremely helpful if you want to automate tasks that deal with the filesystem, as Node’s async nature can become a real burden when you’re just manipulating files. There are lots of task-specific automation tools, too – tools for deployment, build generation, code quality assurance, and more.

Code quality

If you’ve ever been bitten by a missing semicolon or an extra comma, you know how much time can be lost to subtle flaws in your code. That’s why you’re running your code through a tool like JSHint, right? It’s configurable and has lots of ways to integrate it into your editor or build process.

The fine manual

Alas, there is no manual for front-end development, but MDN comes pretty close. Good front-end devs know to prefix any search engine query with mdn – for example, mdn javascript arrays – in order to avoid the for-profit plague that is w3schools.

The End

As with anything, reading about these things won’t make you an expert, or even moderately skilled – the only surefire way to get better at a thing is to do that thing. Good luck.


I’m officially one-third of the way through my self-imposed month of unemployment before I join Bocoup at the beginning of May, and I’ve been spending most of what would normally be my working hours on a small demo to support talks at conferences I will be speaking at this summer. It’s just a little app that searches various services, and displays the results – so simple that, when I showed it to Melissa, she helpfully asked why I wouldn’t just use Google.

It’s been about 18 months since I last got to start a project from scratch – in that case, the codebase that became Mulberry – but even then, I didn’t have control over the full stack of technologies, just the JavaScript side of things. Over the course of my time on that project, I came to be extremely familiar with Dojo, fairly competent with Jasmine, decently comfortable with Ruby and its go-to simple server Sinatra, and somewhat conversational in Sass.

I spent most of my time on that project working with technologies with which I was already pretty comfortable. Interactions with new technologies came in dribs and drabs (except for that one time I decided to test my Ruby skills by rewriting our entire build process), and all of my learning was backed up by a whole lot of institutional knowledge.

The consulting world, of course, is a wee bit different: you interact frequently with new technologies, and you never know what a client might ask you to do. Learning comes in bursts, and the ability to quickly come up to speed with a technology is imperative. On a six-week project, you can’t spend the first 40 hours getting your bearings.

Even though I spent three years as a consultant, returning to that world of constant learning was feeling a tad intimidating. And so for this project, I decided to make a point of leaving that comfort zone, and intentionally chose technologies – Node, Bootstrap, Backbone, Mocha, RequireJS – that I hadn’t really had a chance to work with in depth (or at all).

On Learning

Greenfield projects are few and far between, and it’s easy to get in a rut by sticking with the tools you already know. Some of my most exciting times at Toura weren’t when I was writing JavaScript, but rather when I was learning how to talk to the computer in a whole new language. Greenfielding a personal project is a special treat – it never really has to be “finished,” and no one’s going to be mad at you if it turns out you made a shitty choice, so you’re free to try things that are less of a sure thing than they would need to be if you were getting paid.

Speaking personally, it can also be a little intimidating to learn a new thing because learning often involves asking for help, and asking for help requires admitting that I don’t already know how to do the thing that people might expect I already know how to do.

Sometimes the thing that gets in the way of starting a new learning project is actually the fear that I will get stuck. What does it mean if the person who talks at conferences about principles code organization can’t figure out how best to structure a particular app with Backbone? What does it mean if the person who’s been encouraging people to build their JavaScript can’t get RequireJS to generate a proper build? What will I say to Isaac, now that he is standing in front of me and introducing himself, when I have not in fact spent any quality time with Node prior to this past weekend?

Lucky for me, it turns out that all of this is mostly in my head. While I often preface my questions with a small dose of humility and embarrassment, it turns out that well articulated questions are usually greeted with thoughtful and helpful answers. If anything, I’m trying to be more communicative about the learning that I do, because I think it’s important that people feel comfortable acknowledging that they used to not know a certain thing, and now they do. I also try to gently remind people that just because they have known something for months or years doesn’t mean they should look down upon the person enthusiastically blogging about it today.

On that note … here’s what’s new to me these past couple of weeks :)

Twitter Bootstrap

I’ve written a lot of demo apps, and while my coding style has changed over the years, one thing has remained constant: they all look fairly terrible. In theory, we’re all smart enough to know that what a demo looks like doesn’t have any bearing on what it explains, but in reality a good-looking demo is simply more compelling, if only because the viewer isn’t distracted by the bad design.

With this in mind, I decided to give Twitter Bootstrap a try. When I first arrived at the site, I started looking for docs about how to set it up, but it turns out that I vastly overestimated Bootstrap’s complexity. Drop a style tag into your page (and, optionally, another style tag for the responsive CSS), look at the examples, and start writing your markup.

What I really loved is that there were patterns for everything I needed, and those patterns were easy to follow and implement. Within an hour or so I had a respectable-looking HTML page with markup that didn’t seem to suck – that is, it looked good and it was a decent starting point if I ever wanted to apply a custom design.


If you’ve ever talked to me about Node, you know that I have pretty mixed feelings about it – some days I feel like the people writing JavaScript in the browser really would have benefited if the people who have gravitated to Node had stuck around to invest their collective smarts in the world where 99% of JavaScript is still written. But that doesn’t really have anything to do with Node the technology, so much as Node the new shiny thing unburdened by browser differences.

I’ve actually visited Node a couple of times previously – if you haven’t at least installed it, you might be living under a rock – and I was flattered that Garann asked me to review her book Node for Front-End Developers, but past experiences had left me frustrated.

This time, something was different. I don’t rule out that it might be me, or even that learning some of the ins and outs of Ruby might have prepared me to understand Node – and packages and dependency management and writing for the server instead of the browser – better this time around. It could also be that the Node ecosystem has reached a point of maturity that it just hadn’t reached the last time I poked around.

Regardless, I found that everything made a whole lot more sense this time, and my struggles this time were about forgetting to stringify an object before sending it as a response to a request, not about getting the server to start in the first place. I used the q module to give me my beloved promises for managing all the asynchronicity, and generally found it ridiculously pleasant to leave behind all the context switching I’d grown accustomed to while using JavaScript and Ruby side by side. I’ll probably still turn to Ruby for automating things on the command line (though I continue to be intrigued by grunt), but I’m ready to admit that it’s time for me to add Node to my toolbox.


To be honest, I’d just planned on using Jasmine for writing tests for this project, mostly because I’d never set up Jasmine myself, and I was interested in maybe getting it working with grunt for headless testing. I ended up bailing on that plan when, in the course of some Googling for answers about Jasmine, I came across Mocha.

Mocha is a super-flexible testing framework that runs on Node and in the browser. You can choose your assertion library – that is, you can choose to write your tests like assert(1, 1).ok() or expect(1) depending on your preference. I decided to use the latter style, with the help of expect.js. You can also choose your reporting style, including the ability to generate docs from your tests.

I had to do a bit of finagling to get the browser-based tests working with my RequireJS setup, and ultimately I ended up just using my app’s server, running in dev mode, to serve the tests in the browser. I’m still working out how best to run just one test at a time in the browser, but all in all, discovering Mocha has probably been the best part of working on this project.


RequireJS is another tool that I’ve dabbled with in the past, but for the last 18 months I’ve been spending most of my time with Dojo’s pre-AMD build system, so I had some catching up to do. I don’t have a ton to say about RequireJS except:

  • It’s gotten even easier to use since I last visited it.
  • The docs are great and also gorgeous.
  • While I haven’t had to bother him lately, James Burke, the author and maintainer of RequireJS, is a kind and incredibly helpful soul.
  • The text! plugin makes working with client-side templates incredibly simple, without cluttering up your HTML with templates in script tags or hard-coding your templates into your JavaScript.
  • The use! plugin makes it painless to treat libraries that don’t include AMD support just like libraries that do. I hear it might become an official plugin soon; I hope it will.


This part was a tough choice, and I actually set out to use a different framework but ended up getting cold feet – even though this was just a personal project, it did need to reach some semblance of done-ness in some reasonable period of time. After a little bit of poking around at other options, I decided that, barring completely copping out and using Dojo, Backbone was going to be the best tool for this particular job on this particular schedule.

I’m pretty torn about this, because I decided to use a framework that I know has shortcomings and limited magic, and I know that other options would serve me better in the long term. But I also know that the long term doesn’t exactly matter for this particular project. The thing that swayed me, really, was that with Backbone, I didn’t feel like I needed to grasp a whole slew of concepts before I could write my first line of code.

I looked up plenty of things along the way, and rewrote my fair share of code when I discovered that I’d been Doing It Wrong, but I was able to maintain a constant forward momentum. With the other options I considered, I felt like I was going to have to climb a ladder of unknown height before making any forward progress.

I feel like I made the right choice for this project, but it’s a choice I’d spend a lot more time on for a “real” project, and I’d be much more inclined to invest the initial energy in getting up to speed if the payoff was clearer. This, though, is a choice that people seem to be consistently terrible at, and so I feel like I should beat myself up about it just a little. It’s all too common to dig a ginormous hole for ourselves by choosing the technology that lets us start writing code the soonest; on the flip side, it’s all too common to choose a technology that’s complete overkill for the task at hand.

The End

The master branch of the repo for the project should be mostly stable (if incomplete) if you want to check it out. I’m going to close comments on this post in the hopes that you’ll write your own post about what you’ve been learning instead :)

JavaScript: It’s a Language, Not a Religion

I have six things to say:

  1. I am in a committed relationship with my partner Melissa. We will celebrate six years together on Sunday. We contribute frequently to political causes.

  2. I was deeply saddened yesterday to learn that Brendan Eich contributed money in support of a political initiative that sought to rescind the court-established right for same-sex couples to marry in the state of California. It has changed my view of him as a person, despite the fact that we have had a positive and professional relationship and he has been a great supporter of my JavaScript career. I think he is on the wrong side of history, and I hope that courts will continue to agree with me.

  3. I had a frank, private, and face-to-face conversation with Brendan about the issue during JSConf. I shared my disappointment, sadness, and disagreement.

  4. I have been dismayed to see this incident interpreted as a statement about the JavaScript community as a whole. This community is made up of so many people who believe so many different things, and yesterday I was reminded that they are all just people, and JavaScript is just a language, not a religion. I shudder to think of a world where there is a political litmus test for entry into the community. Indeed, I am extremely torn about introducing personal politics into my professional life*, as I fear it will encourage professional colleagues to opine about personal beliefs that are frankly none of their business. One of the great joys of working with computers is that they do not care who I am or what I believe; I realize that to ask the same of people is unreasonable, but inviting politics into the workplace is a treacherously slippery slope. Unless my personal belief system presents an imminent danger to my colleagues, I am loath to welcome discussion of it by people who otherwise have no substantial or personal relationship with me.

  5. I believe individual companies must determine how best to address these issues, as their attitude toward them can have a significant impact on their ability to hire and retain talented people. I support constructive pressure on companies to align themselves with or distance themselves from political causes, but I would not support a company that prohibited its employees from participating in the political process. I urge anyone who is hurt or offended by this incident to engage with Brendan and Mozilla personally and professionally. Brendan is wrong on this issue, but he is a thoughtful and intelligent person, and he is also a human being.

  6. Finally: If this incident has made you angry or sad or disappointed, the most effective thing you can do is follow in Brendan’s footsteps by putting your money where your mouth is. Money speaks volumes in the American political system, and there are campaigns in progress right now that will impact the rights of gays and lesbians. Your contribution of $50, $100, or $1,000 – or, in lieu of money, your time – will have far more impact than yet another angry tweet.

And now I shall turn off the internet for a bit. Comments are disabled. Shocker, I know.

* It bears mentioning that, in certain cases, people making political contributions are required to include information about their employer. The inclusion of this information does not indicate that the employer supports – or is even aware of – the contribution.


| Comments


It wasn’t so long ago that I was giving my first talk about JavaScript at the 2009 jQuery Conference, and it was there that Bocoup’s Boaz Sender and Rick Waldron created the (now-defunct), a celebration of an unfortunate typo in the conference program’s listing of my talk.

A bond was forged, and ever since I’ve watched as Bocoup has grown and prospered. I’ve watched them do mind-boggling work for the likes of Mozilla, The Guardian, Google, and others, all while staying true to their mission of embracing, contributing to, and evangelizing open-web technologies.

Today, I’m beyond excited – and also a wee bit humbled – to announce that I’m joining their consulting team. As part of that role, I look forward to spending even more time working on and talking about patterns and best practices for developing client-side JavaScript applications. I also hope to work on new training offerings aimed at helping people make great client-side applications with web technology.

New beginnings have a terrible tendency to be accompanied by endings, and while the Bocoup opportunity is one I couldn’t refuse, it’s with a heavy heart that I bid farewell to the team at Toura. I’m proud of what we’ve built together, and that we’ve shared so much of it with the developer community in the form of Mulberry. The beauty of open source means that I fully expect to continue working on and with Mulberry once I leave Toura, but I know it won’t be the same.

I’ll be spending the next few days tying up loose ends at Toura, and then I’m taking a break in April to hit JSConf, spend some time in Berlin, and head to Warsaw to speak at FrontTrends. I’ll make my way back home in time to start with Bocoup on May 1.

And so. To my teammates at Toura: I wish you nothing but the best, and look forward to hearing news of your continued success. To Bocoup: Thanks for welcoming me to the family. It’s been a long time coming, and I’m glad the day is finally here.

Girls and Computers

| Comments

After a week that seemed just chock full of people being stupid about women in technology, I just found myself thinking back on how it was that I ended up doing this whole computer thing in the first place. I recorded a video a while back for the High Visibility Project, but that really just told the story of how I ended up doing web development. The story of how I got into computers begain when I was unequivocally a girl. It was 1982.

Back then, my dad made eyeglasses. My mom stayed at home with me and my year-old sister – which she’d continue to do til I was a teenager, when my brother finally entered kindergarten eight years later. Their mortgage was $79 – about $190 in today’s dollars – which is a good thing because my dad made about $13,000 a year. We lived in Weedsport, New York, a small town just outside of Syracuse. We walked to the post office to get our mail. The farmers who lived just outside town were the rich people. In the winters the fire department filled a small depression behind the elementary school with water for a tiny skating rink. There were dish-to-pass suppers in the gym at church.

In 1982, Timex came out with the Timex Sinclair TS-1000, selling 500,000 of them in just six months. The computer, a few times thicker than the original iPad but with about the same footprint, cost $99.95 – more than that mortgage payment. When everyone else in town was getting cable, my parents decided that three channels were good enough for them – it’s possible they still had a black-and-white TV – and bought a computer instead.

Timex Sinclair TS-1000

I remember tiny snippets of that time – playing kickball in my best friend Beth’s yard, getting in trouble for tricking my mother into giving us milk that we used to make mud pies, throwing sand in the face of my friend Nathan because I didn’t yet appreciate that it really sucks to get sand thrown in your face – but I vividly remember sitting in the living room of our house on Horton Street with my father, playing with the computer.

A cassette player was our disk drive, and we had to set the volume just right in order to read anything off a tape – there was actually some semblance of a flight simulator program that we’d play, after listening to the tape player screech for minutes on end. Eventually we upgraded the computer with a fist-sized brick of RAM that we plugged into the back of the computer, bumping our total capacity from 2K to 34K. I wrote programs in BASIC, though for the life of me I can’t remember what any of them did. The programs that were the most fun, though, were the ones whose assembly I painstakingly transcribed, with my five-year-old fingers, from the back of magazines – pages and pages of letters and numbers I didn’t understand on any level, and yet they made magic happen if I got every single one right.

A string of computers followed. My parents bought a Coleco Adam when we moved to Horseheads, New York – apparently the computer came with a certificate redeemable for $500 upon my graduation from high school, but Coleco folded long before they could cash it in. I made my first real money by typing a crazy lady’s crazy manuscript about crazy food into an Apple IIe that we had plugged into our TV, and my uncle and I spent almost the entirety of his visit from Oklahoma writing a game of Yahtzee! on that computer, again in BASIC.

Me at a computer fair at the mall with my sister, my mother, and my friend

Above: Me at a computer fair at the mall with my sister, my mother, and my friend Michael. “You were giving us all a tutorial, I can tell,” says my mom. Note the 5-1/4” external floppy drive.

In middle school, I started a school newspaper, and I think we used some prehistoric version of PageMaker to lay it out. When high school rolled around, I toiled through hand-crafting the perfect letters and lines and arrows in Technical Drawing so I could take CAD and CAM classes and make the computer draw letters and lines and arrows for me, and quickly proceeded to school just about every boy in the class. In my senior year of high school, I oversaw the school yearbook’s transition from laying out pages on paper to laying out pages with computers, this time the vaguely portable (it had a handle on the back!) Mac Classic. We used PageMaker again; the screen was black and white and 9”, diagonally.

Macintosh Classic

It was around then that a friend gave me a modem and – to his eventual chagrin, when he got the bill – access to his Delphi account, giving me my first taste of the whole Internet thing in the form of telnet, gopher, and IRC. When I went to college the following year, I took with me a computer with perhaps a 10MB hard drive, and no mouse.

Once again I found myself poring over magazines to discover URIs and, eventually, URLs that I could type to discover a whole new world of information. In 1995, I spent the summer making my college newspaper’s web site, previewing it in Lynx – it felt like there wasn’t much to learn when there was so little difference between the markup and what I saw on the screen. I would go to the computer lab to use NCSA’s Mosaic on the powerful RISC 6000 workstations, because they had a mouse. Yahoo! was about one year old. My friend Dave, who lived down the street, installed Windows 95 that summer and invited me over to show me. It was amazing. We were living in the future.

My early years with computers seem pretty tame – I wasn’t tearing them apart or building my own or doing anything particularly interesting with them, but I was using them, I was telling them what to do and they were mostly listening, and it never made me feel like I was weird. To the contrary, it made me feel powerful and empowered. I felt like a part of this ever-growing community of people who understood, eventually, that computers were going to change the world. It was the people who didn’t understand this who were weird and beneath us. It was the people who understood computers better than me of whom I stood in awe.

I can barely remember a time when computers weren’t a part of my life, and yet when they first entered my life, their presence was incredibly exceptional. These days, of course, computers are ubiquitous, but interaction with them at the copy-assembly-from-the-back-of-a-magazine level is almost nonexistent. Parents who can approach a computer with the same awe and wonder and determination as a child – as I must imagine that my dad did in 1982 – are likely equally rare.

In some ways, it is like the very ubiquity of technology has led us back to a world where socially normative gender roles take hold all over again, and the effort we’re going to need to put into overcoming that feels overwhelming sometimes. Words can’t express my gratitude for the parents I have, for that $99.95 investment they made in me, and for fact that I was lucky enough to be 5 and full of wonder in 1982.

Thoughts on a (Very) Small Project With Backbone and Backbone Boilerplate

| Comments

I worked with Backbone and the Backbone Boilerplate for the first time last weekend, putting together a small demo app for a presentation I gave last week at BazaarVoice. I realize I’m about 18 months late to the Backbone party, here, but I wanted to write down my thoughts, mostly because I’m pretty sure they’ll change as I get a chance to work with both tools more.


Backbone describes itself as a tool that “gives structure to web applications,” but, at the risk of sounding pedantic, I think it would be more accurate to say that it gives you tools that can help you structure your applications. There’s incredibly little prescription about how to use the tools that Backbone provides, and I have a feeling that the code I wrote to build my simple app looks a lot different than what someone else might come up with.

This lack of prescription feels good and bad – good, because I was able to use Backbone to pretty quickly set up an infrastructure that mirrored ones I’ve built in the past; bad, because it leaves open the possibility of lots of people inventing lots of wheels. To its credit, it packs a lot of power in a very small package – 5.3k in production – but a real app is going to require layering a lot more functionality on top of it. Ultimately, the best way to think of Backbone is as the client-side app boilerplate you’d otherwise have to write yourself.

My biggest complaint about Backbone is probably how unopinionated it is about the view layer. Its focus seems to be entirely on the data layer, but the view is still where we spend the vast majority of our time. Specifically, I think Backbone could take a page from Dojo, and embrace the concept of “templated widgets”, because that’s what people seem to be doing with Backbone views anyway: mixing data with a template to create a DOM fragment, placing that fragment on the page, listening for user interaction with the fragment, and updating it as required. Backbone provides for some of this, specifically the event stuff, but it leaves you to write your own functionality when it comes to templating, placing, and updating. I think this is a solveable problem without a whole lot of code, and want to spend some time trying to prove it, but I know I need to look into the Backbone Layout Manager before I get too carried away.

Backbone Boilerplate

This project from Tim Branyen was a life-saver – it gave me an absolutely enormous head start when it came to incorporating RequireJS, setting up my application directories, and setting up a development server. It also included some great inline docs that helped me get my bearings with Backbone.

There are a couple of ways I think the boilerplate could be improved, and I’d be curious for others’ opinions:

  • The sample app includes the concept of “modules,” which seem to be a single file that include the models, collections, views, and routes for a … module. I don’t love the idea of combining all of this into a single file, because it seems to discourage smart reuse and unit testing of each piece of functionality. In the app I created, I abandoned the concept of modules, and instead broke my app into “components”, “controllers”, and “services”. I explain this breakdown in a bit more depth in the presentation I gave at BazaarVoice. I’m not sure this is the right answer for all apps, but I think modules oversimplify things.
  • The boilerplate includes a namespace.js file. It defines a namespace object, and that object includes a fetchTemplate method. It seems this method should only be used by views, and so I’d rather see something along the lines of an enhanced View that provides this functionality. That’s what I did with the base component module in my sample app.
  • I’m super-glad to see Jasmine included in the test directory, but unfortunately the examples show how to write Jasmine tests, not Jasmine tests for a Backbone app. As a community, we definitely need to be showing more examples of how to test things, and this seems like a good opportunity to distribute that knowledge.


I feel a little silly that I’m just now getting around to spending any time with Backbone, and I know that I only scratched the surface, but I like what I saw. I think it’s important to take it for what it is: an uber-tiny library that gets you pointed in the right direction. What I really want to see are fuller-fledged frameworks that build on top of Backbone, because I think there’s a lot more that can be standardized beyond what Backbone offers. I’m hoping to have a bit more time in April to dig in, and hopefully I can flesh out some of these ideas into something useful.