So I undertook to get our test coverage up to scratch, I got ZenTest to ensure that the tests get run for every saved modification, which is a great help during development. But this exposed me to something which I had already started to notice but which hadn’t become a real issue yet, Ruby on Windows is slower than a 1-legged dog down the dog track. ZenTest was taking 20 seconds or more to even notice a file had changed and then took even longer to begin the test. Combined with Ruby using 100% CPU most of the time this really dented my productivity and I had to do something. Luckily all that spare time I had while I was waiting for the tests to run every time I pressed save meant I could look into resolving the problem.

After investigating the problem further it seemed like there was some issue with the startup phase of Ruby, as it took ages to get things like Webrick, mongrel, IRB, Rake tasks etc. started but once they were running everything was fine and dandy.

I came across a few solutions but I opted for this solution using andLinux — which is a install of Ubuntu Linux for running within Windows, think VM but without the hassle of setting up a VM, or think Cygwin but more powerful (you can do apt-get to get any Ubuntu package quickly etc.). That tutorial helped me to setup andLinux and my Ruby & Rails environment in under an hour.

Suddenly it was all blazingly fast and I was happy developing again.

I then looked to my IDE, I had been using RadRails for eclipse but no longer needed many of it’s features I was using and I had noticed that while editing Rails stuff it would start off Ruby (apparently randomly — well I couldn’t figure out the connection between what I was doing and when Ruby would start) which as I say uses 100% of my CPU in Windows.

I wanted something lighter, I wanted something cleaner and I wanted all the cool snippets that TextMate gives you when developing Ruby/Rails (or pretty much anything) on OS X. Luckily I found exactly what I (and lots of other people) want in TextMate for Windows – in the guise of "e", which is a fantastic name for launching it via Launchy.

A quick install of e and a play around with the themes to make it easier on the eye and I was in editor heaven (or as close as I’ve got so far on Windows).

Finally I then found that I had lots of PuTTY windows open to my andLinux install (one for mongrel, one for Zentest, one for log tailing & another for bash), finding which window was which became annoying — within about 2 minutes. So looking for a tabbed UI for PuTTY I came across two, PuTTY Tabs and PuTTY Connection Manager. I tried them both out but it instantly became clear that PuTTY Connection Manager was the better of the two for my needs (the fact that it wraps all your PuTTY windows into one with tabs was the main winner). Now I have (at least) four tabs open in PuTTY Connection Manager and rename them all to suit (e.g. [mongrel],[zentest] etc.) making it much, much easier for me to manage.

So the short-list of things that increased my Ruby on Rails productivity in Windows is as follows:

• A Linux install :) to run Ruby on
• ZenTest autotest, I couldn’t live without it anymore
• e
• PuTTY Connection Manager
• TopDesk which I’ve also had for quite a while, but still very useful.

I guess the moral of this story is if you want to develop with Ruby on Windows use Linux. I am planning on a move to Ubuntu at some point, but really don’t have the time to start from scratch with my system right now.

• Component Class – Part One
• Component Class – Part Two
• Component Class – Part Three
• Component Class – Part Four
• Component Class – Part Five(Skins vs Styles)

This series takes you through creating a custom component in Flex with actionscript and he takes you through all the possible options (from extending an existing component from the Flex framework to starting with a clean slate by extending the UIComponent.)

As I’m still fairly new to Flex reading this exposed some new areas of Flex components to me, such as the commitProperties() and invalidateProperties() methods and also gave me more insight into the updateDisplayList() method.

This weekend I have been getting dirty at a low level with Flex creating some really customised components (and my first programmatic skins – which are really great to use once you get one under your belt) for a personal project and if I hadn’t have read this series it wouldn’t have half as easy as it has been.

I’ve seen a few thoughts about how to best work around this, such as the above post on Java vs CFC instantiation by Mark Drew and the ideas presented by Peter Bell with regards to iterating business objects which I’ve mentioned before.

But to be honest I’ve not explored either of these in any great detail, although I really wish I could devote some time to looking at them.

Another, and easier and more instant, solution appears to have been suggested by Brandon over at devnulled in his post on how the Coldfusion compiler works in the following aside:

A related thing to note that he doesn’t cover is how much faster it is to instantiate objects in cfscript rather than CFML on a percentage basis. Just some food for thought. I can do a follow-up post on this in particular topic if anyone is interested.

Of course we’re interested in a follow up post. After reading this I spent a few minutes testing this out with a few different CFCs from our model; beans, gateways etc.

I was only looking at the average time of instantiation in either 100 and 1000 iterations and although I did see a tiny improvement in the average time in cfscript I won’t be going out and rewriting all the code that uses cfset to instantiate CFCs just yet.

I’m hoping that Brandon has some hidden trick or information up his sleeve and I’m dying to read a post on it (and I’d say as much in the comments on this post if it would let me, every time I try it doesn’t get added to the post) and find out there really is a marked difference between the two.

Personally I find it easier to read ECMAScript syntax rather than the tags in Coldfusion, so I use it wherever I can already. But if there is a speed benefit for using cfscript when instantiating CFCs then I can use that as leverage to get the rest of the team at work to start to use cfscript wherever possible. Which would be nice.

Update: I’ve just found a post on the Coldfusion compiler over at Absolutely No Machete Juggling that goes into detail about exploring the differences between the resultant compiled Coldfusion code in a simple test (not related to CFC instantiation). The important notes that may apply to CFC instantiation appear towards the bottom of the post:

So there you have it, the SetVariable implementation is slow…

CFScript [when compiled] doesn’t use SetVariable, so if you’re doing heavy loop code like this, I’d recommend writing it using CFScript rather than CFML.

I've not had the time to play around with MooTools yet, but simply looking at the help page you can't deny that it looks sweet.

"OK" you may say to yourself, "it doesn't look like there is anything too new in there". Well even if it were just the really nice syntax changes, such as when extending classes:

Which is a lot more intuitive and concise than the current method offered in Prototype:

I'd be happy to recommend MooTools on those improvements alone, intuitive and concise is always the best combination when it comes to programming languages as far as I'm concerned, but there is much more:

• OO inheritance, allowing you to call methods on the parent object when extending objects.
• Using the $ function to extend elements with the Element methods.
• Defining custom methods on elements.
• Powerful yet simple effects.
• The full release (when the compressed option is chosen) is around 20kb, consider that the latest version of Prototype alone is 53kb and when compressed (with the fabulous Dojo Rhino compressor) is still 36kb. To work around the large size of Prorotype & script.aculo.us combined I've had to break Prototype up into its component parts and then use a custom manager for managing script requirements (I plan to post about this in future once I've worked up a couple of examples); I mean who uses all the functionality Prototype offers at the same time?

Another of the potentially great things about the MooTools library is the FX themselves, I'm aware that Moo.fx has been around for a while, but the really great thing about Moo and is that it doesn't seem to try and do all the work for you. If you've ever taken a look at using the script.aculo.us dragables or sortables for anything that slightly differs from the test cases or examples you'll soon come a bit of a cropper, Johnathan Snook gives a good example of the simplicity and flexibility of the MooTools way of doing things in his post exploring drag and drop with MooTools.

I'm sure I'll have more to post about MooTools in the near future as I'm planning to use it as my primary JavaScript framework for my next large project, so we'll see if it lives up to expectations. For now I'll just share a few links that I've found informative so far:

• The MooTools help page
• Useful Utility Functions in mootools
• Extending Objects and Classes with mootools
• drag and drop with MooTools