Releasing code is a pain. It takes for ever to get it ready. You have to write tests (and run them in all the browsers), docs, tutorials, blog posts, yada yada yada. Something that might take me 20 minutes to write will take me an hour or more to release.

Previously when I’d write a new class for my own work, I’d throw it on the pile of things to release and then, once every few weeks, go through the trouble to put together all the assets and release it.

Starting today I’m going to start releasing my work as I write it. This is still somewhat infrequent – the majority of the code I write are classes for my own projects that would be of little use to anyone else. But instead of letting them pile up, I’m going to just drop them all in a “Beta” directory in my repository and get them onto the download page. I probably won’t blog about them so if you want to keep track I suggest you subscribe to the svn rss.

Don’t expect these beta scripts to stay as they are. They’ll likely get rewritten and tweaked as I go along. So why release them if they’re so brittle? Partly because they might actually be useful to others out there and hey, if you try it out and find a bug or wish it did something differently, that’s good feedback for me. Plus it exposes my work more quickly and easily for others, even if the work might change.

Today I released 9 scripts:

• DollarE – Brings back $E from MooTools 1.11. Returns a single Element for a selector.
• DollarG – Returns a collection when given an element, a collection of elements, an element id, or a selector.
• Hash.Run – Executes every method in a hash. Used for page init function groups.
• HoverGroup – Manages mousing in and out of multiple objects (think drop-down menus).
• InputFocus – Adds a ‘focused’ class to inputs when they have focus.
• MenuSlider – A simple dropdown class; see the menu at the top of Clientcide.com.
• Occlude – Mixin class for preventing a class from applying itself to the same element twice.
• String.FindAllEmails – Finds all the email addresses in a string.
• ToElement – Mixin class that returns *this.element*. Allows you to do $(myInstance).

There aren’t any docs for these either, though the source files often have a quick example of how you might use it.

As always, feedback is most appreciated.

MooTools ships with a copy of JSSpec and a suite of tests that validate much of the core functionality of the MooTools framework. The Clientcide libraries include tests for this suite that we use to validate our work (you can see those here).

These tests are great at determining tests that can be validated instantly by a computer. Does 2 + 2 = 4? If not, something is wrong. But they don’t do such a good job when the result is asynchronous (like with Ajax) or when the test requires user interaction (like dragging). Did the item fade in? Can you drag this? If you submit this form does the result load below? These kinds of tests don’t work in a test suite like JSSpec.

So I’m releasing the Clientcide Test Framework that does just this. It allows you to quickly author a test and any accompanying html that goes with it and then pose questions to the tester that they must answer yes or no to.

For example, let’s say we wanted to test our FormValidator class. The test file for it would look like this:

{
	tests: [
		{
			title: "Form.Validator",
			description: "Validates that a form's inputs are correct.",
			verify: "Fill out the form as described and submit it. Were errors reported correctly?",
			before: function(){
				new FormValidator('foo', {
					serial: false,
					onFormValidate: function(passed, form, event){
						event.stop();
						if (passed) alert('form validated');
						else alert('form did NOT validate');
					}
				});
			}
		}
	]
}

Then we’d have an accompanying html file with a form it that would validate (I won’t paste it here).

This allows developers to write a quick test and develop code against it in a “clean” environment. The test framework has a “vanilla” iframe with almost no javascript in it by default (basically only a few methods used by the test framework). When the user loads a set of tests, the iframe loads the dependent scripts and then displays the tests for the user to run.

The other bit of useful integration is the script.json convention used in MooTools. Basically, in MooTools, there’s a file called scripts.json that lists each file in the library and it’s dependencies. This enables things like our downloads builder. The test framework uses this file to load the dependencies for a given test, and, in turn, the test allows you to verify that the scripts.json file is accurate and that the correct dependencies are being loaded.

Thought the test framework is written in MooTools (1.2.1), the test environment itself is completely vanilla. Other than the scripts.json convention, which anyone can use, it is not specific to MooTools in any way.

The suite is entirely authored in JavaScript, which means that it can be deployed anywhere, allowing you to write tests that interact with back-end server-side code. It can also be run from the deskt

The framework comes with an example set of scripts and tests for those scripts. These don’t use MooTools at all. You can read more about how to use the framework on it’s readme page and see the tests in action on the tests pages.

You can see Clientcide’s tests as well, which are a better indication of how the framework might be used.

The framework is available for download via Googl’es svn services:

http://code.google.com/p/clientside-test-framework

As many of you know, I left CNET back in November of 2007 to pursue my own startup (www.iminta.com). While getting that off the ground CNET continued to contract me to maintain the Clientside public libraries and to continue blogging here. I also worked on a few internal projects as I was needed. This was a tremendous help as it afforded me the time to do things like launch Iminta.com and finish the MooTools book. Considering that CNET was the principal investor in my first startup (way back in 1999), in one way or another, CNET employed me for nearly a decade, and I can’t thank them enough.

But all good things must come to an end, and my contracting work for them is now officially over. Consequently, Clientside.CNET.com is no more. I started thinking about domain names a week or three ago and eventually settled on Clientcide – as in death to the browsers! This was really a reflection of what I and other developers of JavaScript frameworks have been saying for a while: the frameworks aren’t competing with each other – it’s the browsers we’re at war with.

Now that I’m not speaking for a large public company here, I felt free to play around with the look-and-feel and my early designs were all things like browser icons with blood splattered across them, Kill Bill style. But these ultimately felt too derivative and then I stumbled upon the idea of just making the header stupid fun. I must say, I’m enamoured with the new look. We’ll see if I feel that way after a few months of it. What do you think?

To quote the MooTools blog:

In keeping with our new pledge to release more often, we’ve been working hard lately to get 1.2.1 ready for release, and we’re finally happy with it. This release brings a ton of bug fixes, and is a drop in replacement for 1.2.0. (That’s right, no breaking changes!)

What’s new?

Element.Properties.html (element.set('html', html);) now works even with select and table element’s in Internet Explorer. Element:clone is also now faster than ever, and retains the values of form elements being cloned. A lot of work has also been done to fix some bugs in Class.js, and Safari 2 support is now back. With the help of Daniel Steigerwald, we’ve also cleaned up quite a few memory leaks in IE related to events and Element storage, and destroyed elements are now more effectively destroyed.

For a complete list of changes, see the changelog on GitHub…

Links:

• Changelog
• MooTools 1.2.1 Download
• MooTools 1.2.1 Builder

I’ll be regressing all the Clientside code to verify that everything still works and will release 1.2.1 into our svn soon. Hopefully I can knock this out today.

MooTools 1.11 used to have a doc viewer in the svn repository that isn’t there for MooTools 1.2 (I’ve still got it in our repository if you want it). Well, some industrious soul created a chmox file for the 1.2 docs.

There’s also a PDF cheat sheet for both the MooTools core and the plugins.