Enrico Rubboli

Vi sono alcuni casi in cui effettuare alcune operazioni direttamente da Rails prima della risposta di un controller richiederebbe troppo tempo. Si pensi ad esempio un processo che deve scaricare/caricare una risorsa esterna che potrebbe impiegare un tempo indefinito (ad esempio un feed RSS o un’immagine o l’invio di un’email), o effettuare un’elaborazione complessa, in questi casi l’utilizzo di una coda di processi permette di dare una risposta immediata all’utente e completare il task in background. Se necessario avvertire l’utente quando l’elaborazione è terminata è possibile utilizzare un polling ajax o comet (ad esempio APE) oppure quando disponibili sul client le websocket HTML5.

Vi sono diverse implementazioni di queue manager, da ActiveMQ a RabbitMQ (che è stato usato per forexdesk.com) alle innumerevoli versioni Java. La versione piu semplice che si possa adottare su rails, e sufficiente nella quasi totalità dei casi, è delayed jobs, da notare che questa soluzione è anche quella adottata da Heroku sui suoi workers.

JSON e JSONP sono molto spesso utilizzati da rails per dialogare con terze parti, ad esempio per rispondere a chiamate ajax. In rails vi sono diversi metodi per utilizzare JSON.
L’approccio old-school compatibile con rails 2.3 è quello di utilizzare il metodo respond_to e passare un blocco nel quale specificare i vari formati:

Con rails3 è possibile utilizzare il metodo respond_with:

Di default in rails include_root_in_json è true, in alcuni casi è necessario settarlo a false:

Per utilizzare JSONP è sufficiente specificare il metodo di callback nella render:

Chi si è già aggiornato a rspec2 avrà notato che il vecchio approccio al testing delle routes è deprecato, il vecchio codice non funziona più:

it "should map { :controller => 'comments', :action => 'index' } to /comments" do
  route_for(:controller => "comments", :action => "index").should == "/comments"
end
it "should generate params { :controller => 'comments', action => 'index' } from GET /comments" do
  params_from(:get, "/comments").should == {:controller => "comments", :action => "index"}
end

C’è stato ultimamente un’interessante dibattito su quale sia la migliore via per procedere a questo tipo di test, nell’attesa che nuovo zucchero venga aggiunto (es: l’uso del nuovo formato di indirizzamento delle routes tipo “controller#action“) il nuovo approccio (che fa un check bidirezionale) è il seguente:

it "routes GET /post/:post_id/comments to comments#index for post_id" do
  {:get => "/post/1/comments"}.should route_to(:controller => "comments", :action => "index", :post_id => "1")
end

che però senza questo commit non funziona. Per procedere quindi è necessario al momento aggiornarsi all’ultima release di rspec-rails, modificando il file Gemfile:

group :test do
   gem 'rspec-rails',  :git=> "git://github.com/rspec/rspec-rails.git"
end

Capita spesso che al variare di un determinato valore tanti elementi distinti debbano aggiornarsi, ad esempio un grafico che si aggiorna al variare dei valori di una tabella, o le celle di un foglio di calcolo. In tutti questi casi torna utile l’Observer pattern. Nell’esempio che segue variando i valori delle valute verrà automaticamente aggiornato il grafico, ovviamente il numero degli observer non è limitato ad uno.

Read more…

Questo è uno script bash che permette di lanciare rails server/console/generate rispettivamente con rs/rc/rg ed è compatibile con rails 2 e 3:

Si tratta di una fusione colossale, molto più di Fiat e Chrysler o di Sun ed Oracle.
Stiamo parlando di Ruby on Rails, uno dei più interessanti framework per web application esistenti e Merb, i pilastri che hanno fatto di Ruby uno dei linguaggi di sviluppo più interessanti in circolazione.

Personalmente sono convinto sarà un successo, se gli sviluppatori riusciranno a prendere il meglio da entrambi i progetti il risultato sarà eccezzionale. Rails soffre di alcuni difettucci (anche sulle performance) che merb son convinto risolverà.

Quel che mi spaventa è il porting di tutti i progetti su cui lavoriamo che “girano” su rails2 e jruby.

Stiamo partorendo una nuova creatura (ForexDesk) che dovrebbe essere rilasciata prima di rails3, valuteremo il porting appena si saranno calmate le acque e sapremo da che parte sbattere la testa :)