Posts for: #Ruby on Rails

Rails caching and Javascript pt. 2

map[bio:Developer, music connisseur and avid tea lover. image:lg.png name:Luca Guidi twitter:jodosha]
#ruby on rails  #rails  #caching  #javascript  #jquery  #caching  #page caching 

In the previous article I showed how to take the advantage of Javascript for page caching.

This cache strategy allows to generate static HTML and allow the web server to serve it, without waste a useless Rails request/response cycle. But, since the cached page is stateless we ask help to Javascript for make it a little bit dynamic.

Flash

All of you has probably noticed that flash object is an enemy of page caching. Let me show you why.
class SessionController Now suppose the application is in a blank state, when the user hits the dashboard_url, ActionPack will cache the page, including the flash status. This means it will be always rendered, even if the flash will be expired.

[]

Rails caching and Javascript pt. 1

map[bio:Developer, music connisseur and avid tea lover. image:lg.png name:Luca Guidi twitter:jodosha]
#ruby on rails  #rails  #javascript  #jquery  #caching  #page caching 

Rails offer a multi-level view caching based on: page, action and fragment.

Page Caching

For Rails cache a page means to generate the HTML code on the first visit, then allow front-end web server to send it statically.
This is the fastest way to serve pages, because Rails puts the cached page in the public folder, the web server intercept the request and doesn’t forward it to the application server, avoiding an useless Rails request cycle.
class HomeController

[]

Skip Mocha

map[bio:Developer, music connisseur and avid tea lover. image:lg.png name:Luca Guidi twitter:jodosha]
#ruby  #ruby on rails  #tdd 

Yesterday I confessed how messed up was CachedModels 0.0.2. The problem was pretty simple: I made some mistakes mocking up Memcached behaviors.

The Dilemma

I massively use Mocha for track how many calls CachedModels performs against the cache, and (ideally) for run test suite without any server active. But, this approach led me to broken results. Should I keep out Mocha from my tests?

The Solution

Why don’t mock the mock? We know, Ruby allows to add behaviors to classes at runtime, Mocha itself take this advantage. I added to my test_helper.rb the following code:
if ENV['SKIP_MOCHA'] == 'true' class Object def expects(*args) self end 

def method_missing(method_name, *args, &block)
end

end

[]

Cached Models 0.0.3

map[bio:Developer, music connisseur and avid tea lover. image:lg.png name:Luca Guidi twitter:jodosha]
#ruby on rails  #rails  #plugins  #cached models  #nosql  #memcached 

Since I began to work as professional developer I learned a lot of stuff, but, first of all I learned to be honest with customers and with the Community. I have to admit: CachedModels 0.0.2 was a huge mess.

It was a broken version, due to wrong mocks in test. I apologize for all the problems you could encountered using it. Since I discovered all the errors, I worked hard to restore all the lost functionalities. But it wasn’t enough for me, so I focused my attention on performances, reducing cache accesses: now benchmark test tooks 36.015132 fewer seconds than plain ActiveRecord!

[]