The first thing you need to know about my “computing background” is that I went to college for Jazz Guitar. At roughly the same time the web was being born. I was always into computers; building them and playing games and making art with them. When the web first showed up I started fiddling with HTML and making galleries of my photography (which I also studied in high school and college). I took some graphic design courses and helped design, build, and maintain the web site for my school. In 1997 I got a call from a friend to come to California and work on a startup as an interface designer which pretty much killed my music career.

I started my own company in 1999, a music site called Epitonic. It kinda died when the rest of the web did. I joined CNET as a product manager and built more music oriented sites there but slowly moved into technical product management focused on internal projects. At some point I hacked together some prototypes for the network and was annoyed at the lack of JavaScript infrastructure.

I took it on myself to research all the budding frameworks, pick one, and standardize the whole company around it. I started w/ Prototype and Moo.fx but when MooTools came out I quickly latched onto it. I started blogging all this, originally as an internal blog for CNET developers but later as a public blog where we started releasing all the things I was putting together. If you feel like it, you can read my initial impressions of MooTools in this post and a followup that I posted shortly after that.

Since then I’ve been active in the MooTools developer community non-stop. I left CNET and did another startup on my own (www.iminta.com) and then in 2009 I joined Cloudera as employee number 10. Cloudera now has six front-end developers (including Thomas Aylott ed: “SubtleGradient” of mootools-core and Slick teams), all cranking out MooTools code.

Well, lately, I don’t. I haven’t posted much to Clientcide in roughly two years. I have a lot of code on my github account that I want to release but I don’t have time to write docs and promote it. Some of my latest work is perhaps the most interesting I’ve ever done. The Clientcide libraries still haven’t seen a release against MooTools 1.3, though the work is done in github. MooTools More now has 4 other developers on the team and they are responsible for most of the new features and work you see there. So, in short, though I remain active on the mailing lists and I do author a large amount of JS, my contributions this last year or so have been rather thin as Cloudera continues to require nearly all my attention.

But, that said, in general over the years I’ve made it a priority to make the framework easier to learn, adopt, and use out of self-interest. I genuinely enjoy teaching and helping others, but I do these things for MooTools because I want to see the framework succeed. Where others on the team focus on code quality and features, I’ve focused on stability, documentation, tutorials, message boards, etc. because I want to write MooTools code where I work and if no one is adopting it then there’s no market for it. Already you can see that jQuery, which is a fine library for it’s scope, is the defacto standard in much of the market. This makes it harder for people who see the value of MooTools to find work using the framework. Much of my time is dedicated towards adoption to ensure that the project is healthy and can not only survive, say, Valerio getting hit by a bus, but also allow me and you and others to continue working on MooTools in our day jobs.

I mentioned some of this already, but my somewhat self-appointed task at CNET was to create a common JS story for the network. I was a product manager there and every time I’d ask for some aspect of my product to be interactive I’d get blank stares from all the Java guys on my development team. I’d often end up writing the JS for my product myself. After a while I could see that the problem was only going to get worse as the web got more sophisticated; if CNET didn’t adapt our customers would find a site that just felt out of date.

Initially I chose Prototype. I researched a bunch of frameworks and I liked Prototype’s model a lot. But the library was really verbose (it was like, 70K in those days) and it didn’t have element enhancements nor effects; for those you needed Scriptaculous – another 70K or so. Moo.fx came out and it was 3K (!). I started building on top of that and then MooTools itself followed. I loved the framework from the start, but it was not even a 1.0 release yet (r87); there weren’t even docs for it. I knew I couldn’t get the CNET engineers to even consider it without those things, so my first contribution was the documentation. I authored these by reading through the entire source and documenting each method. That single week’s worth taught me more about JavaScript than anything before or since.

While working at CNET I decided to release everything I could. At the same time, I continued to contribute to MooTools Core. Most of my contributions to Core were added because I needed stuff in my actual work. $merge for example didn’t exist in r82. I wrote the first implementation of it (which Valerio immediately rewrote). This was the pattern for a long time; I’d work on my stuff for my job while Valerio and others worked on Core. When I found
something wanting, I’d push it up into Core when I could. As I released more and more stuff on Clientcide it became harder to maintain that code and still contribute to Core in any meaningful way.

About two years ago the MooTools development community decided, at my urging, to focus on growth. Specifically to work to increase the number of people contributing to the framework. The dev mailing list went from something like 12 to maybe around 70 today. About that time we decided to pull over a lot of the Clientcide plugins and make them an official MooTools release. If you look at the MooTools More library today there are about 65 plugins (if you exclude all the localization files). About 40 of those came from Clientcide. Nearly all of them have been rewritten by the team (and are much better for it); they certainly aren’t my contributions any more. Clientcide still has about 50 plugins in it (the next version deprecates about 20 of them). All that code is already too much to maintain, so any notion that I might have about contributing to Core goes right out the window. My todo list is already too long.

As for what I would do if I could do anything; if I could just take a week of vacation and work… well, I always have a long laundry list of things that I’m trying to accomplish. I want to improve the test coverage in MooTools More (which is already in pretty good shape thanks to the rest of the More team). I want to implement some automated UI testing with Windmill or Dohbot or something. I have several repos on github that I want to release; the Behavior library in particular. I need to update the Mootorial. Blah blah blah. It’s a long list.

I would say I was an average developer with an average understanding of JavaScript. I wrote a lot of functions but never used inheritance. My work in JS wasn’t very object oriented. I had a cursory understanding of prototypes but not why they were useful. As I stated earlier, reading through the MooTools source code taught me more in one week than anything I’ve ever done. Valerio is a brilliant developer; his work borders on art if you ask me.

What I’ve learned since then is less about being a better coder and more about working with people. I’ve pushed on the MooTools community pretty hard to adopt a lot of the process and principals that I find in my day jobs. Many of the MooTools developers don’t have jobs as full time developers in a community of developers. They are freelancers or are in school. Valerio spends nearly all his time working on MooTools itself. I’ve had a very different experience working in organizations with dozens or even hundreds of developers. There’s a different priority at work there. At Cloudera I’m surrounded by hardcore developers – some of the smartest guys I’ve ever met. We contribute to a lot of other open source projects (mostly Apache projects) and I see the merit in the structure that those projects have. Doug Cutting, creator of Hadoop, Lucene, Nutch and others, works at Cloudera. He’s the chairman of Apache! I’ve picked his brain a lot about what makes Apache projects succeed or fail. I try and bring a lot of that knowledge to the MooTools developer community. I’m not always successful at it, but there are numerous things that we do now that came from my talks with Doug and others.

I’m not a perfectionist. Look at my code on github and compare it to Valerio’s. Valerio and the other MooTools developers will often choose beautiful code over just about anything; usually that’s a good thing. Their dedication to releasing the best code they can possibly produce is what makes MooTools so wonderful to work with. I am not the kind of person that could produce a MooTools even if I had the technical talent.

I’m a pragmatist. I make things that work and that are extensible, reusable, etc. I often find myself redoing what I’ve done before or extending something I’ve done before usually because I had a lack of foresight in my initial API design. It’s what makes me look so productive. I produce a lot of things that work but they certainly aren’t perfect. I don’t even strive for perfection; I strive for flexibility and functional completeness. I’m not afraid to rewrite something a few times.

That programming to patterns talk that I give is based entirely on my own revelations as a developer. I spent many years doing things the hard way. The stuff I do now is taking that pattern thinking even further (for example, the Behavior stuff I’ve mentioned already). But I can point to several things I’ve authored here at Cloudera that are on their 3rd rewrite.

As for MooTools, I can’t imagine being able to author JavaScript this way without it or something very similar. If I didn’t have MooTools, I’d probably write it myself (only worse) just to keep from going back to the way I used to author code.

Credit where it’s due: Valerio authored many of those demos. We actually use ART in our product at Cloudera. We may at some point remove it or at least portions of it; at the scale we are using it it’s a little slow (not MooTools fault but rather that of SVG/VML). We’re pushing the edge a little I guess.

As for release, there are two things here; ART, and the widget framework that happens to use it. ART continues to slowly march towards release, but that’s something you’ll have to ask Valerio about. It’s unofficially a MooTools project; as soon as it’s ready for 1.0 you’ll probably see it on MooTools.net, but certainly not Clientcide.

As for the widget framework, that falls directly into the “on my long list of things to do” category. Will I release it? It’s on github now with demos and stuff. The real question is will I find the time. The more code I release, the more stuff I have to maintain. The value of open source software is that if it’s useful you find others to help you maintain and grow it, but even that takes a time investment. I’d like to think that as Cloudera matures a bit we’ll be able to focus a little more on packaging this stuff up and pushing for others to adopt it…

I have learned not to make predictions about future releases of MooTools the hard way. I wrote a second edition of my book against the 2.0 branch of MooTools. That was about two years ago. Since then we decided to focus on a more iterative approach to releases so much of the 2.0 branch got back-ported to become MooTools 1.3. The work on my book is essentially worthless.

These days I focus on the current release. When Core goes into testing and its API is locked down, that’s when the work on MooTools More gets safe to start. I’ll point out that the rest of the MooTools More team, in particular
Tim Wienk, Arian Stolwijk, and Christoph Pojer, were instrumental in updating More for 1.3. I contributed very little to that effort I’m sad to say. Cloudera has yet to upgrade to 1.3, though I hope to do that soon.

Most of the things I want to change aren’t about the features or organization of the code but rather priorities and the social structure of the project. Writing software is a social challenge as much as anything. I’d like to see the number of committers on the project quadruple. It would make it harder to introduce change in some ways, but it would make the project more resilient. MooTools More went from essentially one full-time committer to five and there are some awesome things in there now that I personally would never have had time to author. If there were 100 people with committer status it would require each of us individually to give up influence but it would be for the best.

As for the web site, I’d like to see it more focused on adoption. The new Demo environment is a good start in that direction. I’d like to see more tutorials and more community engagement. The guys working on the site are awesome, but like me they have other responsibilities to their jobs and families. We can only go as fast as we can donate time.

Sooner or later I want to go back to managing products. I am involved with MooTools because I care about building good products. I want the web projects I work on to be interactive and fun to use. In some ways, I don’t care if I write the code itself. I like doing it, but if I were to do another startup of my own, I’d eventually hire someone else to take over that work and I’d focus on the product design.

Read the source. If it takes you a week or a month, if you can get to a point where you understand how and why MooTools does what it does – every single line and function – your skills will improve. The second thing I’d recommend is getting involved. Write about what you do on your blog. Release some code! Go into Lighthouse and find a bug to fix. Improve the docs. Makes some demos for us!

Oh jeez. Instead of top 5, I’m just going to list some stuff I use a lot.

• jsFiddle obviously; no surprise
• JSLint – I use TextMate and have this integrated to show me errors and warnings when I save a file. It’s a life-saver.
• Git and gitub have both changed my life.
• I love ReCSS (http://david.dojotoolkit.org/recss.html); WTFramework (http://nouincolor.com/wtframework/2.0/) is also pretty cool
• j for command line work is another huge time saver (https://github.com/rupa/j)
• I love visor for the mac (http://visor.binaryage.com/) – my command line is never more than a single keystroke a way
• I regularly visit the Mozilla Developer Center for docs on JS, HTML, CSS (https://developer.mozilla.org/en-US/)