I love github. At the risk of sounding trite, I’ll say that they are the “2.0″ of open source project hosting. Sourceforge, Google Code, etc, have played a big role in open source development, but their tools pale in comparison to Git itself much less the beauty that is Github. Github is fun to use, nice to look at, and has served the MooTools well since we moved it there.

One of the thing that’s so encouraging about it is the pace of the development. New features seem to crop up every couple of weeks and while they may not be perfect, they’re almost always a good start. Take Github Issues for instance. It leaves a lot to be desired, but if you have a small project, it gets the job done. MooTool uses Lighthouse and Apache uses JIRA and Github’s Issues can’t yet compete with these tools. It works fine until you have > 100 bugs and > 30 people working on the project. But I thoroughly believe it’ll catch up eventually because the people at Github have proven that they’re talented and dedicated to quality. A lot of their features are in the beta-ish phase, it seems, and given the quality of those features at this early stage, I’m mostly content.

So when they recently released their new “Pull Requests 2.0” I was a bit excited and a bit wary. I’ve been trying to get the MooTools dev team to use Reviewboard for a couple of months now and not getting any traction for various reasons. One is that we’ve been trying to consolidate our community around Github (our Lighthouse account pre-dates Github’s Issues feature). With the revamped Pull Request feature I felt like I could finally drop that argument because it looked like everything we needed.

Like their other features, it works pretty damn well, but is missing a few key ingredients that I find myself yearning for from other tools that its meant to replace. I still have faith that the Github team will eventually get it polished, but of all the features they’ve rolled out, this one – code review – is the one I think they need to get all the way right. Code review, and easy contributions, are the key to open source. If it’s hard to review someone’s pull request, you’re either not going to pull it, or pull it without doing a good review. So I give this feedback with as much love as I can; this is literally meant as constructive criticism. Here’s what I think they need to do to make it perfect:

• Inline Comments: When you get a pull request you can comment in the “review” view, but not on a specific line. To comment on a line, you must find the commit that has that line change and comment there. For individuals who send a pull request with 10 or 20 commits, this is impossible. You *must* be able to make a comment on a specific line of code in the pull request’s review view.
• Pagination and Deep Linking: Currently, Github loads request views all at once and switch between them w/ JavaScript. This makes very large reviews impossible (it actually limits the view to a finite number of commits – 200 I think?) and very slow to load. Further, there’s no pagination so you have to scroll and scroll and scroll. This isn’t so bad, but it also makes linking to a specific line in the review hard, because the code view is hidden when you load the page, making any #anchor in that view unavailable to the browser. This ties into the comments issue, because I need to be able to link to a page and have it jump to the comment in question (as Github does when you comment on a commit) to allow people to reply to it.

Thats it. Those two things. They aren’t small things, but they aren’t big things. I’ve been leaving comments on their various blog posts around code review for a while now, and they always reply that they are aware of these things and will get to it. I have complete faith that they will. Their work to date has inspired great confidence. Of all the things on their long laundry list, I hope that these two changes are very near the top.

Many of you may have noticed looking at the schedule of speakers and events at the Ajax Experience (this September in Boston) that many of the speakers from previous years are not present. I will not be attending, and the same is true for the Prototype team, the Dojo team, the jQuery team, as well as speakers like PPK and others. There’s a reason for this that I won’t go into, but I think it will suffice to say that the conference is shaping up to be a little less… complete this year.

Instead I’ll be speaking at the Rich Web Experience in Orlando, FL, Dec 1-4. I’ll be giving a few talks there (3 or 4) and it’s looking to be like a much more interesting conference. If you’re into MooTools I hope to see you there and if you’re into JavaScript and rich web apps in general, then I think the conference should be worth the trip. There’s not a lot of detail on the RWE site yet, but I hope to see some stuff up soon. You can actually get past the “coming soon” page and into the bios of speakers from the last conference and get an idea of the kinds of topics covered.

If you end up going to the Ajax Experience this year, please let me know how it goes. I’m curious to see how it fairs without any representation from all the frameworks…

I’ve been rather quiet here for the last few weeks. Aside from the fact that I started a new job as I mentioned previously, I’ve been working probably 2/3s of my evenings for the last few weeks on MooTools More, which at this point is essentially code complete. I feel bad about not posting here – there certainly have been plenty of things I wanted to write about, but all I can manage to do is tweet them on @mootools.

So since I haven’t been here posting like I usually do, I thought I’d give you a glimpse into my MooTools to-do list which doesn’t include my day job (where I’ve been writing gobs of cool JavaScript, some of which I’ll release, I promise). This list is feeling quite oppressive right now – I feel very behind – so hopefully sharing it will be both cathartic for me and also will explain my lack of posting to those of you who have missed my super awesome posts lately.

MooTools More: Download Page

The new MooTools More has a lot of functionality. I want a download builder similar to the one here on Clientcide. This will become especially important as the official plugins are broken up into separate libraries. For instance, all the language translations are in their own repository. So I have to rewrite the More Builder for mootools.net, which isn’t a small task.

MooTools More: Review Lighthouse Bugs

Before we release the new MooTools More I want to review the 60+ bugs in Lighthouse thoroughly and identify any that are especially ugly, any that are invalid or duplicates, and then the others that are perhaps just annoying. My objective is once the new -more is out there to have a weekly or bi-weekly release with a bug fix or two and a new feature or two. Constant, iterative development.

MooTools More: Hand Off MooTools Lang

I launched the MooTools Lang Google Group where people who want to help translate things in -more can contribute and discuss that aspect of the work in detail. I don’t want to manage this stuff. I split all the language files off into mootools-lang on github and now I just need to find a poor sucker enterprising soul to own it.

MooTools More: Testing!

We now have tests for every plugin in the library (over 40 now and that will grow quickly). Now we just have to churn through them all in every browser we want to support and fix any issues that crop up. I can see IE6 out of the corner of my eye like it’s stalking me.

MooTools More: RC1

Actually pushing out a release candidate is a big milestone and we’re basically ready for it. This just means things like the docs pages, download page, and a nice long blog post are prerequisites.

MooTools More: Wikitorials

After RC1 is out, I need to go through all the wikitorials here on Clientcide and move the pages for the plugins that are moving to -more over to the MooTorial.

MooTools More: Compatibility

There are only one or two changes to existing MooTools More plugins that will require compatibility files, but there are numerous changes to the scripts coming from Clientcide (one or two are minor breaking changes that can be fixed with a simple search and replace). I need to author all these and then test them so that people using the versions here on Clientcide can migrate easily.

MooTools More: Demos

We’ll need to author demos for MooTools.net that show off all this great new stuff.

MooTools Book

Did I mention I’m working on the second edition of the MooTools book? This version will cover MooTools 1.3 as well as a lot more detail of how to use MooTools. All the inner workings of the library and how you can use them most effectively – a best practices for MooTools kind of thing. This is all the stuff I didn’t have time for in the first book (the last three chapters were all I could get in there before the deadline). It’s shaping up to be about twice the size of the original (you’ll be relieved to know that the font size will not be ginormous like the first book – I still don’t know why Apress did that). Given that the book has been out since August and I still have no clue how it sold and have not received any payment for it, it seems like thankless work. Not to mention the fact that I’m trying to rewrite the book to be about MooTools 1.3 which is still very much in development. Every day I turn around and Valerio has something completely different checked in. Every time he makes a change I think to myself, well, I’m gonna have to rewrite the mootorial pages about that, these two chapters of the book, these plugins in MooTools More, and these plugins on Clientcide. Yay!

As it is I’m on the hook to deliver a chapter every four days (!!!) in order to stay on schedule, and that’s assuming 1.3 doesn’t change much as I go and that it’s on schedule, which I have no control over. In case I’ve never given you this advice, I’ll give it to you now, for free: never write a technical book. If only I had taken my own advice and left it at the first edition, but alas, I was never satisfied with the first edition which I felt was left unfinished.

Clientcide Bugs

Previously I tried to stay on top of bugs that crop up in the Clientcide code. A few bugs were either too esoteric for me to fix (I’m sorry, but I simply refuse to support Chrome or Safari 4 beta yet), but for the most part, if someone filed a bug because something wrong in my work was blocking them, I’d stop what I was doing and try and fix it. Because of my focus on MooTools More lately, I haven’t been able to do this. I’ve fixed a few bugs – the easy ones and the bad ones – but still, I have eighteen bugs open, some of which I can tell are going to be painful to fix. Every time a new one comes in I cringe because I simply cannot focus on this stuff yet. For those of you out there who are stuck because of these bugs, I am truly sorry.

As you can see, my cup runeth over. I know what you’re thinking. You’re thinking I am insane.

Increasingly, I think you may have a point there.

2009 is shaping up to be very interesting for me. As noted today on the MooTools blog, I’m taking on the mantle of the mootools-more principal developer. I’ve spent the last week or two porting a healthy chunk of the Clientcide libraries over to MooTools (which mostly just means going over them and refining and cleaning them up and renaming a few things so they fit in better).

The first infusion of my plugins should be ready for -more in the next week for testing and I’m excited to see them make their way into the framework. For starters we’re going to bring items into -more that do not require non-js assets to work well (so Waiter is out for now, for instance). There will be a roadmap coming soon that should give you an idea of where -more is going. We hope to see a lot of contributors involved.

Wait, I said Job*s*

But wait! That’s not all! Today is my first day at my new shiny job. I’m quite happy and excited to say that I am now amongst the employed again. Over the past 15 months since I left CNET to pursue my own idea of fun I’ve been approached by numerous companies to join their ranks. The latest company to put the full court press on me and convinced me that they were the right next step for me to take: Cloudera.

Allow me to elaborate. Aside from the fact that the team here is beyond killer and that the people backing this small upstart are impressive, the place has two things that are really enticing to me. But first, you must be asking yourself, what does this company do?

Cloudera is to Hadoop what RedHat is to Linux. We are a service oriented company around an open source product – Hadoop. Hadoop is an open source implementation of MapReduce/GFS, which is basically what Google uses to crunch the whole internet into a format that allows it to return blazing fast search results to you when you type in your search for “JavaScript rockstar” (which I see is the term that brought you to this page).

Now, I know what you’re thinking. For a guy who has founded a music startup, launched a music site for CNET, and then launched a social aggregator startup, why is this the right place for him to be? Well, I alluded to two big reasons earlier. They are:

1. I believe that Hadoop (and Cloudera specifically) are going to have a big impact on technology and, specifically the web. Start-ups like Iminta.com aggregate a mountain of data and the interesting products of tomorrow are going to do interesting things with mountains of data. Simply put, what Amazon’s hosted services have done for startups who need a host, I think Cloudera will do for startups that need to crunch all that web 2.0 data that we are all creating with every comment, tag, and upload.
2. The second big thing is that the Cloudera team is small, smart and motivated. More importantly (for me) they recognize the value of a solid user experience and they needed someone who had my exact skill set. It’s rare that an opportunity comes along that lets me be a product manager, UI designer, and UI developer all at the same time. I like doing these things and, most importantly, am most happy when I get to do all of them together. The job is just a great fit for me.

But What About You and Moo?

One of the cool things about this gig is that I’m going to have time to continue doing what I’ve been doing. I’m still working on the next version of the MooTools book. I’m now the principal developer for mootools-more and that’ll take up some time, too. I’ll keep blogging about MooTools and JavaScript. If anything, the demands of this new roll will likely mean I’ll have more and more code to release.

I’m really excited about my new jobs and I’m really excited about MooTools. This year is gonna rock.

Over on the MooTools google group, Lori (who works for Aptana) posts:

Hi gang

Last week I finally added support for MooTools 1.2.1 to Aptana Studio — apologies for the delay. To get the updated plugin, do the following:

1. First, if you do not have it already, get Aptana Studio (http://www.aptana.com/studio). It’s free.
2. In Aptana Studio, open the Plugins Manager by choosing Window > Show View > Other… > Aptana Standard Views > Plugins Manager.
3. In the Plugins Manager, select MooTools 1.2.1 and click the green + icon at the top right of the panel to install.
4. In the Updates dialog box, expand the tree until you see the available “Aptana Support for MooTools” plugins. Select Aptana Support for MooTools 1.2.1.00001 and click Next.
5. In the Install dialog box, accept the terms of the license agreement and then click Next.
6. In the Verification dialog box, click Install.
7. In the next Install dialog box, click Finish.
8. Aptana Studio will begin downloading the MooTools 1.2.1 plugin.
9. Click Yes when you’re prompted to restart.

I’ve tested plugin installation with Aptana Studio 1.2 and 1.2.1; let me know if you have any problems. If you’re using an earlier version of Studio, you may need to upgrade (again, it’s free!) in order to
install the MooTools 1.2.1 plugin.

If you need to post questions for her you should probably do so on the thread.