Got an email from Xavier Lecomte this morning that his MooTools book is now available. In French. As my French is terrible I’m a poor judge of it’s quality, but Xavier has been emailing me questions and details over the past several months and seems like a bright guy. If French is your native tongue and you’ve been waiting for some MooTools knowledge, I’d say this is worth checking out. Here’s an excerpt if you care to peruse it.
Archive for the ‘MooTools’ Category
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.
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.
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).
I’ve written a lot about MooTools over the last several years, the mootorial, my own book, not to mention all the posts here and loads of documentation. So you might think that I’d look at another MooTools book on the market as competition but you’d be wrong. I love that there are other people out there who want to help others learn MooTools. Writing tutorials and books is just as valuable to the framework’s growth as writing code. In the last year there have been a lot of new materials on that front now that I think about it. Ryan Florence has dedicated his blog to the topic. Mark Obcena has written a whole series called “Up the Moo Herd” that covers a lot of tips and tricks and best practices. Not to mention all the great work David Walsh continues to do (for instance, his recent post on NetTuts – “Make your MooTools Code Shorter, Faster, and Stronger” - was terrific).
So yeah, another MooTools Book? AWESOME. Read the rest of this entry »
Several weeks ago I had the pleasure of addressing a large crowd of Joomla developers at their conference in New York. The Joomla community is a fantastic bunch and the time I spent there talking about MooTools was perhaps some of the best I’ve had. The people present were very interested in MooTools and as well they should be. Joomla ships with MooTools built in and there is a large community of Joomla plugin developers who end up using MooTools because of it. Unfortunately, it still ships with 1.1.
A few months ago we, the MooTools team, decided to start focusing more on helping the Joomla community with their upgrade woes and began to re-address the compatibility code for 1.1 to 1.2 in earnest. When I spoke in New York to the Joomla team there and said that our goal was to have something to help them upgrade available by the end of the year, there was, dare I say, rawkus applause.
Well, here it is, Dec 31, and I’ve kept my promise. With the help of many of the MooTools Dev team (Chris Pojer, Darren Waddell, Nathan White, and others) we’ve finally got a compatibility layer that actually works and, more importantly, helpes you upgrade.
First, it logs warnings to the console (such as Firebug) and helps you find the places in your code that need updating. The script is not a compatibility layer as much as it is an upgrade helper. Hopefully this will help us retire 1.1 for good.
Secondly, easily half of the work, if not more, was spent creating a test environment for it. When MooTools 1.1 came out, we didn’t have a test framework to run against the code. When we released MooTools 1.2, we did, and it shipped with tests for most of the functionality included. So to make this compatibility layer, we had to go write tests for all of 1.1 (about 400 individual tests), then write the upgrade helper, compatibility code, and then run the tests from 1.1 against the 1.2 code base with the upgrade helper loaded. Creating the tests for a deprecated code base is no fun but I’m glad we did, otherwise the compatibility code would be in far worse shape.
But as a result of all that work by the MooTools Dev team, I can say that the helper script we released today is likely to cover about 95% of all the changes between 1.1 and 1.2; the other 5% being essentially un-hackable. Still, for most developers, it should cover all their work.
Seeing 2010 roll in with people dropping 1.1 is a great way to start it. If you’re still running 1.1, now is the time to move on.
First, this is just awesome news, and a big tip-o-the-hat to Guillermo Rauch, who wrote the app. For those of you who have been around our community for the last three years, the forge was always something we were “working on”. There have been many versions created over the last few years, and many other community created initiatives, that didn’t quite do what we wanted. Guillermo jumped in and built a great system, closely integrated with git, that, well, it kicks ass.
The Clientcide Libs
I’ve uploaded four plugins to the forge as part of the launch (Tabswapper, MenuSlider, HoverGroup, and dbug). I chose these because they were just the simplest plugins that I could release; they just don’t depend on much and they do one thing. Releasing Stickywin, for example, represents a much greater challenge.
One of the things the forge requires is individual git repositories for each plugin. This means that I have to split up my one big repo into lots of little ones, rewriting my download builder, docs engine, and other tools to make these things easy to manage. Consequently, moving things into the forge is likely to be a long and laborious task. For the moment, the four plugins I’ve released are just duplicate files of what’s in the single Clientcide repo, but eventually, once I’ve split them all up, I’ll remove all the files from the Clientcide repo and then include them all as submodules. For the time being, they will be duplicates, and releasing them will happen as I have time (which is not very much these days).
I’m really excited about MooTools here at the end of 2009. I hope to make a longer post here looking back at all we’ve done this year, but certainly the Forge release will be a big highlight. 2010 has a lot of interesting things coming, I’m sure, but perhaps the thing I’m excited most to see is all the good things that the MooTools community creates and uploads to the Forge.
I know what you’re thinking. It’s been 3 months since I last posted. My last post was all about how you can pay it back to MooTools, and since then I’ve been taking my own medicine.
MooTools 1.2.4 released today along with MooTools More 188.8.131.52. In this release, I’ve pushed 274 commits into the codebase (out of 398). There’s a LOT of new features in it, but some should look familiar.
And then there’s MooTools ART, which is awesome. It’s the beginning of a UI system for MooTools plugins.
Rather than go over all this stuff in detail though, I’ll just point you to the blog post I wrote over on the Cloudera Blog, which outlines all the cool stuff we’ve been building with all these new toys. There’s even a fancy screencast.
The Clientcide Libs and MooTools 1.2.4
But you’re probably asking yourself, what about the Clientcide plugins? Well, obviously I haven’t forgotten about them. First and foremost, it should be rather obvious by now that much of my work is now being pushed into MooTools instead of released here. It makes sense mostly, as the plugins get reviewed by the other MooTools dev team members and the result is always better. There are still a few plugins here that don’t belong in MooTools More and to that end I’ve been maintaining them, occasionally adding features.
The current version of Clientcide – 2.1.0 – should work fine with 1.2.4. The catch is that the upgrade path to switch to the new instances of the things that moved (for instance, Waiter moving to MooTools More and now being called Spinner), isn’t super duper easy. I do plan on authoring compat layers for some of these scripts, but not all of them.
What does this mean if you’re using these libraries? Well, you can keep using them. But I’m not going to maintain Waiter, for instance. I’ll focus on Spinner. Converting from one to the other should be relatively straight forward, but since they both work in the same space (because they have different names), you should be able to use either one or both.
Look for a release in a week or so of the next version of Clientcide for MooTools 1.2.4. There are several bug fixes and I will have some compatibility layers for some of the plugins. In the mean time, you should be able to update to 1.2.4 without any issues.
The only exception here is that MooToosl More 1.2.4 includes a few plugins that are almost direct copies of what I have in 2.1.0, namely HtmlTable and Element.Delegation. If you’re using either of these scripts, you can just ditch the copy you get from me and use the ones in 1.2.4.
I used to make a habbit of posting links to all the fun and interesting MooTools news and whatnot here. I’ve recently been focused on the second edition of the MooTools book, MooTools More, bugs, and a new job and have had less time to post here than usual.
To make up for this, I and other MooTools developers have been posting things on Twitter on @mootools. If you want to know what’s happening in the MooTools world, this is the place to follow. If you don’t use Twitter, you can still get the RSS of the feed.
You can also follow MooTools developers who often post useful things about MooTools that don’t make it on to @mootools (in no particular order):
- Valerio Proietti – @kamicane
- Aaron Newton (that’s me) – @anutron
- Thomas Aylott – @subtleGradient
- Guillermo Rauch – @rauchg
- Christoph Pojer – @cpojer
- Jan Kassens – @kassens
- David Walsh – @davidwalshblog
- Michelle Steigerwalt – @Yuffster
You can find more links for these developers (home pages, github profiles, etc) on the MooTools developer page.
As a side note, you can follow Clientcide on Twitter as @clientcide. I’ll note that the only thing posted there are posts to this blog, so if you’re already following Clientcide via email or rss, you won’t see anything new on twitter.
Despite the delay, the completely rewritten version ofFancyUpload, version 3.0, got pushed to github today. This new version is more stable, has betterdocumentation and more showcases than ever. I even added two download packages with runnable installations, like many developers requested. This article introduces the new features and showcases, impatient readers can jump directly to the comprehensive project page or fork on github.
There are a lot of new features and fixed bugs in this new release, so let me distill the most important ones for you:
- The API with, separated uploader and file classes, allows an easy implementation in all kind of interfaces
- Events are dispatched for every step of the uploading process, to keep the interface as responsive as possible
- Progress tracks the loaded size, upload-rate, estimated time and other values for every file and for the batch as a whole
- File uploads can be stopped, restarted or removed anytime
- New Iframe-based class for multiple, asynchronous uploads without dependency on Flash
- Compatible with Flash 9 and 10 with the browse button as a transparent overlay or as an interactive image sprite
- Ability to change the upload URL and add POST/GET data on runtime, customized for every file or the whole process
- Browse through Files and Folders on your Server
- Rename, Delete, Move (Drag&Drop), Copy (Drag + hold CTRL) and Download Files
- View detailed Previews of Images, Text-Files, Compressed-Files or Audio Content
- Nice User Interface
- Upload Files via FancyUpload (integrated Feature)
- Option to automatically resize big Images when uploading
- Use it to select a File anywhere you need to specify one inside your Application’s Backend
- Use as a FileManager in TinyMCE
- Provides your Client with the most possible convenience
Be sure to check out the demos:
In case you didn’t notice, MooTools 1.2.2 just launched along with MooTools More (184.108.40.206; were the last digit is the version of -more).
I’m working on a big update to Clientcide which I might get out tonight but it might take me a day or two to get it all together, so stay tuned.