in web we trust

After a lot of time without having time I decided to update query_memcached plugin with a lot of changes that the github collaborators pushed some weeks ago.

These are the major changes:

• there was a bug that made the plugin don't work in some situations
• the philosophy have changed a bit and now not all is magic, and you have to indicate in each model if it has to use cache or not
• at last I could write down some tests

It is important for you to update, specially if you where using the previous version.

Enjoy!

This days I have been working on a small library for the i-Buddy device, a small gadget for MSN Messenger lovers, that you can connect to your computer through a USB port and has some functionality like light its head with different colours, light a small hearth, move the flaps and turn left or right.

The main attractive is the price (no more than 25 €) and the simplicity.

The library result of my work is rubi-buddy, and works with Ruby and ruby-usb, and its inspired in the one that developed at 11870.

The library is in progress, because I still have to implement the flap movement. Also, I want to add more examples in the project. At this moment there is only one that checks the response code from La Coctelera and turn the head light green or red.

If you are interested, I encourage you to use it and to add more examples.

Today we had to find a small bug in La Coctelera's javascript: the bug was a hash with a colon after the last element. The problem was that, of course, it didn't work on IE 6 and don't have any debugger for Javascript installed on my Vmware.

The only information I had was the generic error (an object was expected), and the line and column where the mistake was. So I decide to understand how to find that line in all the linked javascript files.

My conclusions are that the line could be from the HTML resulted from loading the page, or that line in one of each javascript files. It is, you have to find that line in all your javascripts and in the result page (viewing the source code) and then try to deduce which of all causes the error.

If the number of line is big enough you could reject some files, but not always you'll be so lucky.

And that's what I have learnt today.

Since mongrel and thin appear as the people favorites application server (with all my respects to Passenger), the configuration of webservers changed in order that you have a web server plus a kind of proxy and then a lot of application servers.

The idea is that, given a request, the webserver has to decide if it is an static or a dynamic url and then serve the request itself or pass it to the proxy of application servers..

The problem is that, as thin and mongrel are also web servers, if you don't take care with the configuration your application server can be serving all the static files too and be busy when it has to attend a dynamic request, with all the problems it causes.

That's why for me is very surprising when you search in Google about Apache + Mongrel, for example, and you arrive to virtual hosts configurations that doesn't take this into account.

The rules are very easy:

 RewriteCond %{DOCUMENT_ROOT}/%{REQUEST_FILENAME} !-f
 RewriteCond %{REQUEST_URI} !/stylesheets/.* [NC]
 RewriteCond %{REQUEST_URI} !/images/.* [NC]
 RewriteCond %{REQUEST_URI} !/javascripts/.* [NC]
 RewriteCond %{REQUEST_URI} !.*\.js$ [NC]
 RewriteCond %{REQUEST_URI} !.*\.jpg$ [NC]
 RewriteCond %{REQUEST_URI} !.*\.gif$ [NC]
 RewriteCond %{REQUEST_URI} !.*\.css$ [NC]
 RewriteCond %{REQUEST_URI} !.*\.js$ [NC]
 RewriteCond %{REQUEST_URI} !.*\.png$ [NC]
 RewriteCond %{REQUEST_URI} !.*\.ico$ [NC]
 RewriteCond %{REQUEST_URI} !.*\.bmp$ [NC]
 RewriteRule ^/(.*)$ balancer://mongrel_cluster%{REQUEST_URI} [P,QSA,L]
 

And this is an example: in order to your needs you can tune this configuration including more filet ypes and static directories.

For nginx the rule is also very simple.

So, you know, don't forge to include rewrite rules for serving static files.

This weekend we have been rumbling, and as a result we present Tagueame. In a few words:

Tagueame is a little experiment about socializing online opinions about your friends and family.

Feel free to register and enjoy. It's very funny!

It is very ease make link_to_remote accessible, it is, forcing it has a href value different than #, which is the default value if you only indicate the :url parameter.

But, it is quite possible that both parameters have the same value. If so, you can redefine link_to_remote in this way:

 module ActionView
   module Helpers
     module PrototypeHelper
       def link_to_remote(name, options = {}, html_options = {}) 
         url = if options[:url].is_a?(Hash)
           url_for(options[:url])
         else
           options[:url]
         end
         html_options[:href] = url unless html_options[:href] 
         link_to_function(name, remote_function(options), html_options)
       end
     end
   end
 end
 

Related to my last post about testing cache and some curiosity about Shoulda I made a branch of it to add some helper methods for testing cache generation and expiration:

• should_cache_fragment
• should_cache_action
• should_expire_fragment
• should_not_expire_action
• ...

The good thing was to investigate how shoulda was organized, the test suite it has and that is so easy to hack.

I submited a ticket that I hope the authors approve in next days.

The last month I have been working in Query Memcached, a plugin that replaces the Query Cache that comes with Rails, adding a Memcache layer for persisting the query's cache between requests. That means that the cache does not expire at the end of the request, because it is stored in Memcached.

If you are not familiar with Query Cache, you only have to know that it's a very simple caching system from ActiveRecord that stores in memory all the queries performed during a request. If a query is fired more than one time, it will be in cache, so the database won't be affected.

The adventages of my approach are evident: you only use the database when some table has been modified or when a new query is executed. So you can get a notice an important speed improvement.

It is ideal for pages which have a lot of customization for the user logged in the application: in that cases it is very difficult to cache fragments or pages, because of the expiring of all that cache, and so many things.

Cache expiring

For expiring this cache, each Memcached key contains a sum of all the version numbers of the tables involved in the query. If one of that tables is modified, then the version number for that table is increased.

For example, the query below involves the table items and the table places:

So, the version for the cache of that query will be the sum of the cache version of the table items and the cache version of the table places.

Disclaimer

We are using this plugin in two on-line web projects: unvlog.com and iwannagothere, and everything seems to work fine (and faster than before), but these sites don't have so much traffic (about 30.000 req/day), so, there are stille possibilities that appear bugs and "unexpected behaviours".

In spite of all that, if you still are encouraged to try feel free to ask me anythin.

More information at README.