Rails on the Run - All Comments

Comment on 'Ajax Pagination in less than 5 minutes' by Roberto

2008-05-13T21:06:27Z

Hi Matt, i really appreciate your hack to will_paginate, it was excactly what o was looking for. I have Prototype 1.6.0.2 and Low Pro 0.5. Everything seems to work fine and it did, but with firebug i get this annoying javascript error and googling didn't help:

Event.addBehavior has no properties application.js?1210710865()application.js?12... (line 5) Event.addBehavior.reassignAfterAjax = true;

where my application.js is exactly like your and in my view i included the javascripts like this:

<%= javascript_include_tag 'prototype' %>
<%= javascript_include_tag 'lowpro' %>
<%= javascript_include_tag 'remote' %>
<%= javascript_include_tag 'application' %>
<%= javascript_include_tag 'effects' %>
<%= javascript_include_tag 'controls' %>

I even tried to substitute "Event.addBehavior.reassignAfterAjax = true;" with this "Event.addBehavior.reload();" but with the same result.

Any ideas?

Thanks in advance.

Comment on 'Rails or Merb, what's best for you?' by R. Elliott Mason

2008-05-10T19:16:33Z

I know that Rails is killing my 256 Slice and I am currently in the process of porting my Rails app to Merb. Since Merb can use AR it has been a pretty decent experience. Most people warned me that switching frameworks is suicide but since my models are fat and my controllers are skinny it has been fairly straightforward. I did have to adjust my Upload model since Merb handles uploads differently than Rails, but other than that it's been a breeze.

The only thing I feel like I'm missing out on is Rails' abundance of view helpers. It is not incredibly fun to have to code my own link_to_if, but it's not time consuming either.

And I love raising NotFound (as strange as that sounds), because a 404 isn't always because there isn't a route to match the request, it could also be because a record doesn't exist. Why Rails don't got that?

Comment on 'Sexy charts in less than 5 minutes' by Alain

2008-05-07T08:35:38Z

The problem was coming from the compile error in the xml.builder as reported by jamiew. Can you update your code as I do not guess whit what to replace label. By the way I am a duplo addict ;-)

Comment on 'Avoid using metaprogramming (seriously!)' by Rob Kaufman

2008-05-06T20:24:48Z

It is worth noting that Tim Harpers method only gets called when the class instantiates (which is why it is equally as fast) as Matt's cleaned up version. The most important thing about meta-programming is knowing when to use it and when not to and to only do as little as possible. The reasons are speed, readability and maintainability. And remember there is nothing wrong with writing code that writes code (generators)

Comment on 'Avoid using metaprogramming (seriously!)' by Tim Harper

2008-05-05T18:16:34Z

The following code is just as fast, and I would write it this way over the long way :) It's pretty clear to me.

module MetaTimeDSL
  SECOND  = 1
  MINUTE  = SECOND * 60
  HOUR    = MINUTE * 60
  DAY     = HOUR * 24
  WEEK    = DAY * 7
  MONTH   = DAY * 30
  YEAR    = DAY * 364.25

  %w[SECOND MINUTE HOUR DAY WEEK MONTH YEAR].each do |const_name|
    meth = const_name.downcase
    class_eval <<-eof>

Comment on 'Avoid using metaprogramming (seriously!)' by Tim Harper

2008-05-05T18:16:01Z

The following code is just as fast, and I would write it this way over the long way :) It's pretty clear to me.

module MetaTimeDSL SECOND = 1 MINUTE = SECOND * 60 HOUR = MINUTE * 60 DAY = HOUR * 24 WEEK = DAY * 7 MONTH = DAY * 30 YEAR = DAY * 364.25

%w[SECOND MINUTE HOUR DAY WEEK MONTH YEAR].each do |const_name| meth = const_name.downcase class_eval <<-EOF def m_#{meth} self * #{constget(constname)} end alias m#{meth}s m#{meth} EOF end end

Comment on 'Avoid using metaprogramming (seriously!)' by Ken Miller

2008-05-05T15:27:39Z

Amendment to above: in this case, it's also that you're doing the array work every time. That could easily be moved into the generator code and out of the instance method, leaving the instance methods defined identically to the hand-coded methods.

But this really supports the overall point -- metaprogramming is harder to write and understand, and contains more opportunities for bugs and sneaky performance pitfalls. But if you really need it, it IS possible to make it perform just as well as hand-coded ruby.

Comment on 'Avoid using metaprogramming (seriously!)' by Ken Miller

2008-05-05T15:21:43Z

It's not metaprogramming per se that makes this slow, it's the use of definemethod. methods so defined are always slower to call than methods defined the usual way. If you just use classeval and a string containing a standard method definition, you'll get results more in line with the written out version.

Of course, then it's even harder to read. Metaprogramming should really only be used if it's the only way to solve a problem, as you say, but performance is not really a reason not to.

Comment on 'Avoid using metaprogramming (seriously!)' by DaveS

2008-05-05T15:06:49Z

You might as well go back to assembly programming...

Comment on 'Avoid using metaprogramming (seriously!)' by allen

2008-05-05T14:43:48Z

Metaprogramming is used to add methods and features to classes at load time, not on each instantiation. Of course, doing this will require more work to dynamically create and install these methods on your Ruby classes.

While the metaprogramming can be slower on load time, it it not significant considering it is only loaded once (in the production environment, though after every change to those classes in development).

This should be the same in merb as rails. In a script/runner invocation or an application off the rails (CGI, command line, etc.) will have a slower load time as the class will be loaded each time your app starts up.

In the end, it does provide more readable/maintainable and DRY code, if written well. Are you optimizing prematurely?

Comment on 'Avoid using metaprogramming (seriously!)' by Matt Aimonetti

2008-05-05T08:35:10Z

Good point! At least if you care about performances.

Now, if the benchmarks were close and that the slightly slower version was easier to read/understand, I would probably go for readability over performance.

Comment on 'Avoid using metaprogramming (seriously!)' by Ben

2008-05-05T08:00:57Z

I seem to remember a cartoon from the 80s - GI Joe, maybe? - that always had a moral at the end; like the one in this post, however, the moral presented then often seemed to be the wrong one given the experiences the Joe team had in the preceding half-hour.

Isn't the correct moral here that you should benchmark your code, metaprogrammed or otherwise?

Comment on 'Avoid using metaprogramming (seriously!)' by Matt Aimonetti

2008-05-05T03:38:08Z

Matt Jones had a really good post, but my blog indicated that textile was enabled while only Markdown is enabled.

Here is Matt's post:

dohzya's comment is on target - the overhead here is in restoring the context (stack frame) that was captured by definemethod, and handling the amount.isa?(Array) case.

Just lifting the Array case above definemethod fails pretty badly, as the methods don't get defined on Numeric until the end. (Also note: the meta-programming code relies on the TimeDsl code in this example - mdays calls TimeDsl's version of hours)

What's really needed (if you want to go meta) is something closer to ActiveRecord's method:

see pastie

Please look at the above pastie to see how Matt got really good perf using metaprogramming. Really interesting stuff!

Comment on 'Avoid using metaprogramming (seriously!)' by dohzya

2008-05-04T10:19:34Z

try to put @amount = amount.isa?(Array) ? amount[0].send(amount[1]) : amount@ out of the definemethod. It must be compute one time only, not at each call of method... Your can try to replace your @define_method@ by an @eval( "", binding )@ too (more slow one time only)

Comment on 'Avoid using metaprogramming (seriously!)' by Henrik N

2008-05-04T09:43:47Z

Oh, and the 364.25 (as opposed to 365.25) in the very first code snippet is a bug and/or typo.