Simpltry

All my classes based on prototypejs use an options hash to change the way the widget renders or executes. It is a pretty typical approach to writing classes based on prototype. I used to do this a lot.

var Foo = Class.create({
initialize: function(options) {
this.options = Object.extend({
default1: 1,
default2: 2
}, options || {});
}
});

But that is kinda ugly, It would be nice to get those default options out of the main initialize method. Now I do this:

var Foo = Class.create({
DefaultOptions: {
default1: 1,
default2: 2
},
initialize: function(options) {
this.options = Object.extend(Object.clone(this.DefaultOptions), options || {});
}
});

I don’t know if this code is much more readable, but it does clean the cruft out of the **initialize** method. It also has two more legitimate benefits.

* Default Options are now clearly labeled as **DefaultOptions**
* If you decided to subclass **Foo** you could just over ride **DefaultOptions** to make them more semantical for your class

While this isn’t earth shattering, it should help clean up your code. The code above is based on prototype 1.6, but could easily be modified to work with 1.5.

I use migrations, it is only marginally better than solving the problem myself. On my personal projects, migrations work beautifully. At my work, um, not so much.

Here are some of the issues we run into with our smallish dev team, 4 full time rails developers:

We do some sort of agile development, and during the course of each iteration we end up with about 10 migrations. That’s like 1 a day! Seems like too many to me, at least. This would likely be 30 per iteration, except that we allow our team to modify migrations, until they are released to production. This is not really a problem with migrations more of a problem with fast/frequent refactoring (which is a good thing). The only way to solve this is to do better upfront design, which is kinda counter to the way we develop.

When you test your migrations it is important to do so with **cache\_classes** set to **true**. Why is this important you might ask? Well basically if you add a column to your schema, then try to assign data to that column, issues will arise. It will work in development mode, but when you try to go to production, it will run, it will complete, but the data you tried to set won’t be there. This seems weird. I think there should be a config parameter that would disable Class caching in migrations. Honestly, I don’t care how fast my migrations run (within reason) as long as they do what they claim they are doing.

Loading lots of lookup data into production is not that easy to do. It would be nice to say here is a csv, rails generate that data. You can do it, but if you use their built in stuff you can only populate 1 table per csv file. Not a problem unless you have foreign keys that need to reference stuff in a different table. Blah, it sucks. Alternatively you could define and parse your own file that spanned tables, but that *is* work, and if it takes over 20 minutes to do in rails it’s not worth doing.

Sometimes we end up needing to add a migration on a branch. Since migrations are sequential, this poses a problem. I don’t think this is surprising, or unsolvable, I even think the [other people](http://revolutiononrails.blogspot.com/2007/02/plugin-release-enhanced-rails.html “Revolution On Rails: [PLUGIN RELEASE] Enhanced Rails Migrations v1.1.0″) have taken a crack at it. Just a minor annoyance from time to time.

Like I said at the top of the post, I use migrations. I don’t want to solve the problem again, but I think there are a lot of change that could be made.

I should also note that the company I work at, a super fun startup, is looking to hire one developer. There are a few requirements, must be willing to live in the DC area, and must be willing to learn Ruby. The people are cool, the environment is casual and your input into building a product is valued. Anyway if you want more info drop me a line, schlueter at gmail [dot] com.

As many of you are most likely aware, [prototype](http://prototypejs.org/2007/10/16/prototype-1-6-0-rc1-changes-to-the-class-and-event-apis-hash-rewrite-and-bug-fixes “Prototype JavaScript framework: Prototype 1.6.0 RC1: Changes to the Class and Event APIs, Hash rewrite, and bug fixes”) has recently be revved to 1.6.0_rc1. That release has brought a flury of changes. Most notably the new custom DOM events and the **Class.create** rewrite. As of today, I am happy to announce [widgets.simpltry](http://widgets.simpltry.com/ “Simpltry Javascript Widgets”) now runs on prototype 1.6.

This upgrade may not be backwards compatible in some instances. Especially the window_properties stuff, I yanked most of it because it was added (more or less) to prototype core. See **document.viewport** for more info.

Right now the version I have published is 0.7_pre1. I will make it officially 0.7 after a few things happen, which might take a while. They are:

* Prototype 1.6 gets released
* script.aculo.us 1.8 is moved to a release candidate
* I have a chance to look deeper into the new event system and fire custom events, in addition to callbacks in the code.

One more thing! I know a lot of people are not using [widgets.simpltry](http://widgets.simpltry.com/ “Simpltry Javascript Widgets”), but I would like to publish a list of sites that are using it. So, if you are using widgets.simptltry for a personal or professional project and would like to have it featured on the soon to be added page, widgets.simpltry.users, drop me a [line](http://widgets.simpltry.com/contact/index.html “Simpltry Javascript Widgets”). It would be great to hear how you are using it. The reason I want to publish this page is to draw attention to this project, get more people involved, take it to the next level, add your own cliche here.

method\_missing rules! You probably have a good idea what it does, if you call a method on an object that doesn’t exist, before giving up and stacking, it will call method\_missing. Then you can grab the method names and parameters, jack around with them, and call a different method (or not).

I recently used method\_missing to add some syntactic sugar to a project at work, it was simple. My task was to queue method calls the user doesn’t care about. I quickly wrote a queuing daemon to asynchronously run additional code outside the context of mongrel. The syntax for creating QueueItems was ugly:

QueueItem.push(AuditWebService, :send_audit, audit_instance).save

I cleaned this up by implementing a quick mixin, that you include in any module or class:

module Queuable
def self.included(base)
base.extend(ClassMethods)
end

module ClassMethods
def method_missing(method, *args)
my_method = method.to_s
test_for_queue = my_method.match(/\Aqueue_(.+)\Z/)

if test_for_queue && self.respond_to?(test_for_queue[1])
QueueItem.push(self, test_for_queue[1], args[0])
elsif self.is_a?(Class)
super
else
raise NoMethodError.new(”no method error #{method}”, self)
end
end
end
end

I am not going to explain the ruby voodoo in the about module, it is beyond the scope of this post, but with the method_missing trick you get:

AuditWebService.queue_send_audit(audit_instance).save

While I haven’t saved a lot of code it reads much more naturally.

There are a few caveats, if you don’t can’t handle the **method\_missing**, you should always call super, to try another implementation of **method\_missing**. It is important that you don’t change the **method** parameter. When I converted it from a symbol to a string to do regex on it, I started to get all sorts of crazy errors like:

ArgumentError: no id given

That was a little difficult to track down, I hope this helps someone else.

At my day job, I have become super reliant on our test suite. We write and refactor code pretty furiously. In order to do that we need a decent set of unit/functional tests. Ruby runs tests serially, which means that as you get more and more it starts to slow down. As they start to slow down you have 3 options: run tests less (really bad), get less done (bad), make tests run faster (good). And that brings me to my good news.

I found a really cool gem called [deep_test](http://www.somethingnimble.com/bliki/deep-test “Something Nimble”). In short it runs your tests in parallel. It accomplishes this by starting multiple background processes that each run different tests.

There is a requirement, you have to dump fixtures. This requirement is good. If you need your tests to run faster dumping fixtures is a great place to start. We actually already got rid of fixtures so there was no work for us.

I experimented with how many processes to use, and on my iMac 2.16, I found the sweet spot to be about 4 processes. It will vary based on how fast your machines are, and how your tests are written.

Then instead of running **rake test** you run **rake test:deep**. Which you previously installed following the installation instructions.

The improvement for me was dramatic. Our tests went from **150** seconds to **65** seconds. Which is very dramatic, when you are running the test suite 20 times a day.