One thing RideCharge has used, but which I’ve only recently expressed interest in, is Watir. Watir is a cool testing toolkit that allows you to control and get feedback from various Web browsers using Ruby. You can use it, or variations of it, with IE (the original Watir was IE-only) Firefox, Safari, or even Flash using the various variations. I’ve only spent enough time with it to get it installed and tinker a bit, so this post only deals with real in-the-field experience. As such, I’ve only played with the FireWatir and SafariWatir variations.

One thing I’ve noticed already are some nuisances in SafariWatir and FireWatir, and perhaps Watir in general in some cases:

• SafariWatir’s goto method requires the protocol as part of the URL whereas FireWatir does not. This is a minor complaint.
• Links in SafariWatir appear to have no href or url property (among others), despite this table showing that they should.
• SafariWatir has no url to determine the current page.
• No support for CSS selectors that I’m aware. This could be brought in from one of at least two Ruby projects (Hpricot or Nokogiri). XPath is a bore.
• Confusingly it only selects the first matching element if multiple elements match. There’s no way to verify the # of elements, etc. Selecting a different matching element is accomplished through the :index parameter.
• Having a different “selector” method for almost every element type seems strange, but perhaps this is just bias from having used JavaScript selector engines so much.
• Having the browser “click” a link where JavaScript is supposed to intercept the click fails to trigger the JavaScript, or may simply have no effect (in one case in SafariWatir).
• No convenient “click the back button” method. This would be useful for testing state-saving in Ajax-focused applications where browser history is an issue.

Control Diagram for ThyncRecord

This is a reposting of an email I sent Frank Lee, who I’ve tapped to help out in building optimized queries for ThyncRecord. Just figured I’d share.

“Because of [JavaScript's prototype-based inheritance vs normal OOP], there is no proper concept of class methods and instance methods. (I don’t believe moo has implemented such a feature yet, though it may in the future…) So, whereas in ActiveRecord’s Ruby implementation we have a model class which returns instances of itself when queried using class methods, I’ve had to invoke a second class called Record, which is a mostly dumb object with a few key methods (save, destroy, reload) and access to associated records within the database. To accomplish this, we need to preload data as deep as seems reasonable to obtain quickly and map it out to dynamically-generated objects which are then assigned to the associated properties.

To generate the SQL for a query, it is necessary to examine a particular model’s associations and the associated models’ associations, recursively until we reach the appropriately-defined depth. It is of course also necessary to know the data type for each column of the currently-being-built object, It is most important to know upon save, preventing improper types being stored in the db, formatting the query strings appropriately with quotes or without, outputting error messaging, etc. Likewise validation rules may output similar error messaging, as defined by the user of the library via regex. (may implement add’l validation in the future)

Associations which can be defined should include at a minimum: belongsto and hasone, which are essentially the same thing but seen from different perspectives; hasmany, which maps an array of the associated model’s Records to a plural property name on the root Record object; and hasandbelongsto_many, which will map an array of associated Records from either end. Determining where to cutoff preloading of these properties is a significant decision to make still. Preventing circular references, etc may be important.

Data types need further fleshing out as well, I currently have only been dealing with number and text, since SQLite does little to prevent storing improper types in the db. (it does, however, provide some base functions which may be used to provide some additional validation beyond application-level if we thought it was necessary) Likewise, JavaScript makes type checking harder than it is in most languages. We certainly should at a minimum include a date type of some kind, I believe SQLite has another built-in function for current timestamp, etc…

An example of ThyncRecord usage would be storing various users’ payment info. We might define a User model and a PaymentMethod model, where the User hasmany PaymentMethods, and a PaymentMethod belongsto a User. All of this is accomplished declaratively (along with defining all columns and add’l validation). Schema is created by means of migrations or model declarations alone. (I may also implement the Rails concept of fixtures which will load data directly into the db from formatted text, in this case JSON) A call to return the second payment type for user 3 might be:

var paymentmeth = User.find(3).paymentmethods[1];

payment

"UPDATE paymentmethods SET billingaddress='123 Some Place, Sometown, ZZ 90876' WHERE id=543";

Anybody w/ questions or who feels like contributing, feel free to email me (thynctank@thynctank.com).

[EDIT: ThyncRecord is now JazzRecord and will be available for download from www.jazzrecord.org starting 10/21/08]

Those choices are basically regarding ID3 handling and file uploads. Aside from picking from the numerous .swf-based JavaScript uploader widgets (see here, and here) we’ve got to determine the back-end stuff. So I’m currently planning on using id3.rb (download here), which is apparently alternately known as “ID3 Library for Ruby”, “id3tag”, and who knows what else. While documentation seems sparse, the functionality is promising. I’m going to add to it/wrap it a li’l bit just so I don’t have to jump through so many hoops and can handle all mp3s the same regardless of tag version. For some reason development stopped back in 2004, according to what I can find online. This lib was simply more accessible and easier to install than the alternatives. (which I could only find references to here)

I’ve also made the decision to store our users’ mp3s in the db vs. in flat files, primarily as a matter of convenience. I can’t imagine having to manage thousands of files in hundreds (or thousands) of directories, and all of the maintenance nightmares if we decided to change the file structure. Storing in the db just makes sense. Now I just have to remember to make use of persistent connections!

Dropping Hobo and DRYML (at least for the time being)

Hobo is a great-looking toolkit and  I’m sure I’ll make use of it in the future. However, it’s got a steep learning curve and has a lot of bells and whistles I just don’t think I need for Hooyip. It’s also not been the fastest kid on the block in terms of parsing over my DRYML files, and I’ve only got a few. Instead of Hobo, I’m turning to Haml, another plugin I may have mentioned in the past. This plug uses a simplified markup syntax that borrows from CSS and still allows for dynamic content (and Rails helpers) quite easily. A companion language, Sass, minimizes complexity of CSS and enforces bundling together of parent-child selector groups.  Haml has performed excellently in my brief trials, and is quite simple to install. There are also great Haml/Sass editors popping up all over for Eclipse (point your Eclipse updater here) and TextMate bundles, etc.

Akai is back! More dog pictures for all the fiends out there in a minute. He was away while my great aunt Mar was in town, as she’s fantastically allergic to anything and everything. But no food allergies, go figure. Now on to the reason for Akai’s departure and Mar’s arrival…

Sad news I figure comes best last, and I have to report that my grandfather, Theodore Patrick McFadden, also known as Poppy, has passed away at 88. I don’t really have much to say about the topic in the blog, just wanted to actually write it somewhere and let it be known that we all miss him. I was one of his pallbearers. Thanks to all of the friends who came to the funeral and/or mass, (regardless of how religious you may be… I sure am not) that was real classy and very much appreciated by all.

Other stuff and nonsense after the jump…

So when writing migrations gets you down, know that just around the corner is a whole new sexy migration tool from Tom at Hobo Central. Tom is responsible for the current “sexy migrations” trend in Rails and has some amazing ideas. The new tool allows you to define all columns and relationships within the models themselves, and based upon the comparison between current models and previous schema, the migration generator migration files to do all the work of both up and down methods! That’s right, no more typing redundant code which is just a mirror of the previous method def! I’d love to see this implemented in core Rails. Let us pray…

There are no books specifically on CakePHP. Not a single one. So whoever writes the first few books will probably make out pretty well in royalties for a while! Hint, Hint! I may write one myself if I ever get round to learning it that well before it takes off!

On the PHP front, Aptana has now added PHP support to the nightly build! Yeehaw! Abandon all PDT and PHP Eclipse, ye who enjoy the Aptana Experience!

Another recent IDE/editor interest of mine (other than TextMate… drool) is jEdit. With the Ruby plugin, SuperAbbrevs, TextAutocomplete and a few other choice plugins (all freely available and without any additional Web browsing to retrieve) jEdit can pose as a fairly capable TextMate replacement. I’d mentioned this in a previous blog entry or two, but I’m really coming to love this editor. The fact that it has Ruby/Rails documentation as you type (as well as dictionary-based code completion) has had me using it over TextMate for Rails for the time being. (I’m not as used to Rails code as I’d like to be, yet) Now that I’ve added the other two plugs (SuperAbbrevs and TextAutocomplete) I have most of what was missing coming from a TextMate background. (snippet templates and completion of previously-typed words) Very much looking forward to going ever deeper with this tool.

I’ve got a new job! Hanley Wood publish a few dozen magazines for the construction marketplace, and I’ll be part of their dev team working on a massive CMS to manage all of these sites. Very exciting.