Archive for September, 2010

A Portable MooTools Development Environment

September 23rd, 2010 by Aaron N.

The actual process of developing MooTools itself isn’t trivial. It’s not rocket science, but maybe there is a little alchemy involved. For instance, let’s say you want to fix a bug in MooTools More. You fork the library and make the change to fix the bug and now you want to test it. You need MooTools Core for this, but which version? Looking at MooTools Core on Github you see there’s a branch called 1.2x and also a branch called master, not to mention a tag for 1.2.5. MooTools More has several branches, too; there’s master, develop, 1.3wip and others. Which combination of these two libraries work together?

Then you see some test files in the library. Some HTML files that appear to be demos, but they don’t run on their own. You need to install the MooTools Test Runner to view them (you can see an example of it running at review.mootools.net:9876). And then there’s an external specs runner.

If you decide you want to play with MooTools ART you have similar issues, not to mention the widget library – art-widgets – built on top of it.

While it’s true that jsFiddle gives you a sandbox with a lot of these things, it doesn’t give you a working development environment. In an effort to make it easier to share these configurations, I’ve created a portable development environment that makes it relatively easy to get things up and running.

http://github.com/anutron/mootools-development

I’ve made a github repo that has essentially no code and only submodules pointing to all the stuff I use in states that work. In theory, it should make it really easy to reproduce a development environment from scratch. Eventually I’ll configure several different environments. 1.3, 1.2, 1.1, 2.0, whatever.

Right now there are three environments configured. 1.2.5-art-widgets (which includes everything you need to play with art-widgets), 1.3-art-widgets which lets you do the same against MooTools 1.3 (there are some issues that we’re working on so it doesn’t look great at the moment), and 1.2x-tracking-core-more, which includes just mootools-core and mootools-more on their respective 1.2x branches. These are my personal environments and you can use them if you like.

Note that instead of submodules I’m using crepo. One of the reasons is it will allow us to create a version that’s tracking against a branch. For example, the 1.2x-tracking-core-more branch is always tracked against core/master and more/develop. Typing “./go sync” will update to the latest of these two branches.

The result of this means that we can create specific, deployable environments for others and for each other. I could file a lighthouse ticket against -core with a specific state that illustrates a bug in core/1.3 that manifests itself only in art.widgets (which I’ve done – art.sheet is broken in 1.3).

Note that you don’t have to use django to use the environment. My environment includes the test runner that I wrote and depender. But you can just do ./go sync and get all the repos without building the django app.

This doesn’t have to be specific to MooTools, but that’s what I made it for. I don’t see people trying to incorporate this into other tools, though crepo is designed for that purpose (we us it throughout cloudera).

Posted in MooTools, Organizing Code | Comments Off

On Github’s Pull Requests and Other Things

September 20th, 2010 by Aaron N.

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.

Posted in 'Industry' News | 2 Comments »