soledad penadés

repeat 4[fd 100 rt 90]

What did you expect after this?

He is opinionated too, and what's wrong with that?

My first ajax-y attempts were done with prototype. It all seemed so natural and seamless: prototype came with rails and there were those nice javascript helpers like link_to_remote which generated the javascript code for calling prototype functions. Until you looked at the code! (and the weight of it). I'm not talking about the ruby code but the output HTML, which is heavy and plagued with very obtrusive javascript.

Since I'm a concerned person, I decided to ditch Prototype and its Scriptaculousy effects and use jQuery instead. And I thought: since jQuery is so cool, I'm pretty sure that somebody will have done a replacement for the default javascript helpers (based in Prototype). But I was wrong. Not completely wrong, but quite a bit.

There's some work done in this area; a guy whose page is titled Katz got your tongue? is working hard in getting a jQuery On Rails plug-in up and running. Incidentally it seems he's also a jQuery developer so that's very good too. But since the plug-in is not finished yet, I kept looking for less obstrusive alternatives. I remembered about the unobtrusive plug-in that Luke Redpath & Dan Webb talked about in a LRUG meeting, UJS, and although it looked really cool, I realized am not sure if that's what I want.

Right now, it looks easier to simply write the HTML and add some JS (not in the html itself) which behaviourizes the elements, using jQuery for this, rather than using UJS's apply_behaviour. Specially because at the end, UJS is still using Prototype, and it is very slow compared with jQuery.

In my tests, which are so unscientific that I don't have any result indicator more than my own subjective speed perception, effects made with Prototype+Scriptaculous ended with what I call the 1fps syndrome: the screen gets updated only 1 time per second, so you forget about concepts like smoothness, transitions, easing and all that quite quickly. Way more quickly than it takes the effect to execute, actually; when it finishes you have almost forgotten what you wanted to do. Meanwhile, jQuery kept always a decent framerate and didn't feel like overloading the processor. And this happens in all types of machines.

So I think I'm going for jQuery, doing things in the style of this guy over here, and will keep an eye in jQuery for Rails development.

I have been doing some RubyOnRails stuff lately, for fun basically. I decided to build my new site (supersole.net) with Rails, and I also decided to use the shiny REST stuff which comes built in with the latest versions of Rails.

But I don't know if it's just me and my (mis)understanding of how this is supposed to work, but I'm fighting with the framework more than desired. The main problem is not with REST, and is not with caching either, but with both at the same time.

I have a controller (PostsController), whose index action takes care of showing the latest posts if an html response was required, and the RSS feed if the rss format was required. Until here, it's all fine, I set :cache_action to :index and it was generating beatiful posts.cache and posts.rss.cache versions. The problem came when I decided to add an "archive" view of the index page: it would allow me to show a list with all the posts in the site, using a url like /posts?type=archive. In the code, if type==archive, it would retrieve every post and show only the titles plus a link; in any other cases it would have the normal behaviour.

Ahh but how to discern what to cache this time? If I visited first the archived version and then went to the non-archived view, I found the cache was showing the same contents for both /posts and /posts?type=archive. The feed was correctly cached, though.

Then I switched to manually cache the fragments, specifying the type (archive/index) and the request format (html or rss) as params for the cache, but with no luck, since I couldn't find a way of caching the rxml output, although the different html versions were working well in this case, with two different versions being generated.

It could be a bad approach on my side, also. Maybe I'm putting just too much logic into what should be a neater function. The only idea that comes to mind is a PostsArchive resource which would show all the posts and could then be easily cached (would be just a single page!), but it looks a bit exaggerated to create a new Controller just for showing a listing of posts, since in fact it is simply another view of the same resource.

Again, I understood that the philosophy of REST in Rails was to have many simple controllers rather than a handful of complex controllers, and while I am all in favour of that concept, it is still a bit complicated to put those little controllers in place in a meaningful way.

After three failed attempts, I managed to go to yesterday's lrug meeting. It was intended to be a kind of experimental collective code review, so people would contribute with pieces of code and get it dissected and improved collectively. There was an special obsession with Hashes, most of the code submissions were improvements and/or workarounds for the Hash class. I understand it. Hashes are cool! The other topic was using continuations for (I believe) solving sudokus. Backtracing and fibonacci were also mentioned in the session, and Rob McKinnon made one of his quick presentations, this time proposing a way of getting data from different sources into a generic shareable format (and using upcoming as an specific example, and hpricot and hashes, of course!).

I must say it was pretty interesting, even if I got lost at some points (my ruby knowledge is still too poor). I specially got lost with the continuations stuff, which at the same time brought me back uni memories, of those times in which I skipped some lessons and then went back to the classroom with lots of knowledge gaps and tried to follow the teacher (with no luck, usually). Hehe! But fortunately, this time the teacher was interesting and deserved to be listened to.

This reminded me as well of the beauty of programming and talking about pure concepts and abstractions. It was ages since I felt that, so thanks to all who did it possible. I think we all need a good dose of abstraction from time to time. Keeps the brain working.

One of the books which was strongly and fervourously recommended is Structure and Interpretation of Computer Programs, which I believe I read some years ago (again, in the uni :-)). So you can see, ruby is not about rails only!

I know the title is harsh but it's so true. At least it is according to nowadays php's implementation of classes and objects, which do not permit to "reopen" and add or redefine new methods to an existing class definition, which is the basis upon Rails (and I presume lots more of applications and frameworks) is built.

This ruby feature managed to freak me out when I first read about it. Redefining an existing class? Who would think of it as a good idea? Where is the maintainability and the good practices of object oriented programming? How can we rely on some class behaving as expected if some piece of code is changing its internal behaviour?

But then I got the answer - when used within reason, this allows you to extend existing classes. Extend. Morph. Adapt. Improve. Refine. Lots of concepts which started jumping around me and made me understand all in a sudden how Rails plugins worked so seamlessly, without having to do any extra include, or without having to touch Rails very core files, or defining hooks at certain places. If you don't like some aspect of Active Record, you could write a plugin which overwrites that behaviour - only that one. The rest remains the same.

The aesthetics is somehow shocking for php-only programmers. It's something like this:

class A
function hello_world
puts "I'm hello_world"
end

Any instance of A running hello_world will output "I'm hello_world"

But if you add this anywhere after the definition of A

class A
function hello_world
puts "I'm hello_world v2"
end

and run hello_world again, you will get "I'm hello_world v2". Which definitely is impossible to do in PHP - you would get a Fatal error: Cannot redeclare class error as soon as you tried to "reopen" a class and add or redefine some methods.

While this is not a problem for the average use of php, it turns to be the opposite when you want to do something smart with php5's new and shiny objects model. Something like, for example, building a cool framework like Rails.

There have been some attempts already, like for example CakePHP or Symfony. I just have experience with CakePHP and while it is magnifically built (given that it maintains compatibility with php4 and php5) it will never reach the whole expressivity and power that Rails has.

A quick example is the AppModel class. AppModel is the CakePHP's equivalent of ActiveRecord::base. In Rails, when you declare a model you just extend ActiveRecord. Simple as that; you don't need extra stuff in the middle. In CakePHP you need to extend AppModel, and if you want to modify AppModel in your application, you have to write a new AppModel.php - which cake will load instead of the default, empty one. Yes, AppModel is an empty class whose sole purpose is extending Model (which has the real ActiveRecord-like methods). That doesn't sound very flexible.

So at the end, AppModel is not more than a simple intermediate step for overcoming the limitation of php's inability to redefine the underlying class, that is, Model. We need to add an extra class in the middle for each level that you anticipate the user of your classes will want to redefine or extend.

Meanwhile, in Rails you would just add some code in the plugins directory with the new functions for ActiveRecord, and your models would still extend ActiveRecord::base. No extra levels of hierarchy whatsoever.

Another interesting example is the famous acts_as_taggable plugin, which allows programmers to add the ability to tag items (i.e. ActiveRecord models) just by adding a single line of code to the model (acts_as_taggable), using ruby's ability to reopen classes and add a series of new methods to existing models.

Even more, there are some Ruby core classes, like Date, to which Rails adds new methods, while they still belong to the Date object, not an artificial AppDate intermediate object in the middle, and without modifying Ruby's core files. Isn't it beatiful?

And before you discard my arguments as biased towards Rails, there are more languages which allow for classes to be reopened, like Javascript (and I believe ActionScript was like that before, don't know about ActionScript 3). These flexible languages have allowed people to write such amazing stuff as Prototype or Script.aculo.us, by making use of the redefinition and extension of existing classes.

So that's why I say that PHP is not flexible and will never have a real Rails-like framework :-)

Hope it's clearer now…