Blog

Search by tag: ruby on rails

February 13, 2011 02:21 - No comments yet

Ruby on RailsAlla fine di Agosto 2010 è stata rilasciata la nuova major revision del framework Ruby on Rails, la 3.0.0, che introduce

  • un nuovo motore di query per ActiveRecord;
  • un nuovo sistema di routing;
  • la gestione delle dipendenze con Bundler (ndr: spettacolare!!);
  • una efficacissima protezione contro gli attacchi XSS, attiva di default;
  • impostazione dell’encoding del testo a livello generale;
  • altri piccoli miglioramenti… qui i dettagli

E siccome questo sito non è altro che il mio laboratorio degli esperimenti, mi sembrava giusto tenerlo aggiornato, visto che ero ancora fermo alla versione 2.3.2 di Rails, che comunque funzionava alla grande. Potete immaginare quanto sia stato tentato di lasciare tutto come stava, ma la tentazione è stata troppo forte… la scarica di adrenalina che precede una decisione del genere, proprio prima di premere il tasto che può rompere tutto, è una sensazione indescrivibile :)

Per l’aggiornamento ho seguito questa guida in quattro parti: Rails 3 upgrade… davvero completissima, tanto che non ho proprio niente da aggiungere :)

La comodità (da sempre il vanto di Rails) è stata nel fatto che è stato messo a punto un opportuno plugin, per aiutare gli sviluppatori nel lavoro di upgrade: questo plugin evidenzia, file per file, tutte le modifiche da apportare per rendere l’applicazione Rails 3-compliant. E’ tutto descritto nella guida che ho linkato.

Ne è risultato che buona parte del codice risultava deprecated, cioè da aggiornare, ma soprattutto tantissimi plugin erano segnalati come non più compatibili! E quindi sono servite ore per cercare l’opportuna sostituzione di ogni plugin con un apposito fork per Rails 3, oppure con uno completamente diverso, per poi adattare il mio codice e correggere anche il codice degli altri, piccoli bug ancora irrisolti nelle versioni preliminari di questi plugin. Insomma, è stata un’impresa!

Mi ha ricordato un po’ quando mi ostinavo a tenere Slackware Linux sul mio computer di casa, quando tutto il mondo cominciava ad usare Ubuntu :P


Ruby On RailsEra da un po’ che ci lavoravo, ma gli impegni lavorativi fino ad oggi avevano sempre prevalso: ho fatto il porting del sito alla nuova versione 2.3.2 di Rails!
(era fermo alla 1.2.6)

I miglioramenti sono tanti, ma (tanto per cambiare) per la maggior parte invisibili. Beh, rimane la soddisfazione di aver fatto una cosa per benino!

Il risultato più evidente si può osservare nel nuovo modulo Social Networks, che integra le ultime condivisioni dai siti “2.0” che utilizzo di più… ne sono molto soddisfatto!

La notizia veramente positiva è che adesso c’è tanta carne al fuoco, perchè non ho intenzione di lasciar morire dentro la mia memoria, al momento moooolto volatile, quelle quattro cose che ho imparato: ho utilizzato la API di Facebook, YouTube e Flickr; ho sperimentato il fragment caching di Rails; mi sono deliziato con le nuove API i18n di Rails, per l’internazionalizzazione e la localizzazione delle pagine.
Insomma, ne avrò ancora per qualche altro post! :)

Concludo lodando ancora l’eleganza estrema di Ruby on Rails, è una goduria programmarlo! Certo non è a livelli “enterprise”… ma è VERAMENTE DIVERTENTE!! XD

PS: è in programma un ritoccone alla grafica… ma il lavoro è lungo!


Qualche giorno fa mi è arrivata una mail automatica dal mio provider di hosting, che mi segnalava la prossimità dell’esaurimento dello spazio su disco riservato al mio account…
3 GB di disco quasi pieni?!? La cosa mi è sembrata subito assurda, perchè un sito web con blog e alcune pagine non può occupare tutto questo spazio!! Ho pensato che probabilmente mi sfuggiva qualche particolare del comportamento di Rails…

ebbene, ho scoperto che 2 GB di spazio erano occupati dai file temporanei che Rails utilizza per memorizzare le sessioni di ogni utente che accede al sito!

Questi file dal nome ruby_sess.QUALCOSA sono contenuti nella directory tmp/sessions all’interno della root dell’applicazione Rails.
File temporanei, che nella maggior parte delle volte sono utili solo per pochi secondi, il tempo di caricare una pagina, dopo di che andrebbero eliminati. Certo, con cautela, perchè alcuni possono essere realmente importanti (come le sessioni degli utenti attualmente connessi al sito).

La soluzione che ho adottato è stata quella di cancellare giornalmente, nottetempo, tutte le sessioni più vecchie di 2 giorni, giusto per essere sicuro di non togliere il pavimento da sotto i piedi di nessuno :)

Ho schedulato su cron questa operazione di pulizia, con un semplice comando:

$ crontab -e

per entrare nel crontab in modalità modifica, e poi ho aggiunto la riga

0 4 * * * find ~/rails-app/tmp/sessions -type f -name 'ruby_sess*'
-ctime +2 -exec rm -f {} \;

(tutto su una riga): in questo modo ogni notte alle 4:00 viene avviata una ricerca su tutti i file (-type f) nella directory ~/rails-app/tmp/sessions il cui nome inizia con il prefisso ‘ruby_sess’, che siano più vecchi di 2 giorni (-ctime +2). Ogni risultato di questa ricerca viene finalmente eliminato (-exec rm -f {} \;)

Sospiro di sollievo! =)


WARNING! Violento attacco di programmazione!

In questo periodo pieno di lavoro mi riesce particolarmente facile avere qualcosa da dire riguardo alla programmazione: parliamo sempre di lui, il mio amico Ruby on Rails!

A volte capita di avere a che fare con modelli complessi, collegati con associazioni has_many, per i quali la creazione di una nuova istanza deve prevedere un form dinamico.

Ad esempio: una rubrica in cui ogni nominativo può avere più di un numero di telefono.
Significa che all’interno del modello Person sarà specificata l’istruzione

has_many :phone_numbers

Si dovrà quindi implementare un form dinamico che consenta l’aggiunzione di uno o più campi riguardanti i numeri di telefono, che poi andranno salvati nella relativa tabella con l’associazione al nominativo (dopo essere stati validati).

(… e se non credete ci sia complicato, provate a farlo senza leggere questo post! ihihi!)

Ovviamente un buon programmatore RoR sa che, soprattutto in queste occasioni, bisogna applicare la filosofia DRY (don’t repeat yourself), perciò la soluzione da ricercare non sarà una soluzione elegante… bensì la più elegante =)

Non starò qui a descrivere tutta la procedura, ma vi rimando a tre screencast che chiariscono ogni dubbio:

Se non andate d’accordo con il video-learning, nelle pagine linkate trovate anche la trascrizione di tutte le operazione effettuate… veramente semplici e da applicare il più possibile, per rendere più cool le nostre web application :)


In ogni grande azienda, quando si tratta di adottare una nuova tecnologia, ci si trova sempre frenati da qualcuno che pone la domanda “e con tutto il software sviluppato finora che facciamo?”.
In effetti è vero che non si può pretendere di fare il porting di tutto il codice già scritto ogni volta che viene scoperto un nuovo framework di programmazione.

interoperabilityLa soluzione sono i Web Services, “un sistema software progettato per supportare l’interoperabilità tra diversi elaboratori su di una medesima rete” (fonte: Wikipedia).

Il Web Services Description Language (WSDL) è uno standard internazionale, promosso dal World Wide Web Consortium (W3C), che permette la descrizione delle caratteristiche di un Web Service attraverso uno schema XML/SOAP, il quale viene utilizzato come “strumento di sincronizzazione” tra il framework fornitore del servizio e quello che sarà l’utilizzatore (che, grazie a questa forma di comunicazione standard, potranno anche essere basati su linguaggi di programmazione eterogenei).
Grazie al WSDL è possibile, per esempio, utilizzare un’infrastruttura software progettata e sviluppata su un server Java (es. Tomcat), richiamandone i metodi da un server basato su Ruby on Rails (es. Mongrel).
In particolare, per quanto riguarda Ruby, si dovrebbe utilizzare la gemma SOAP4R, che però nelle ultime versioni è inclusa direttamente nel pacchetto ufficiale.

Un piccolo esempio di tutto ciò si può realizzare in pochi semplici passi, non c’è neanche bisogno di scrivere un vero tutorial.

  • Creare una Web Application con un Web Service in Java e deployarla su Tomcat:
@WebService()
public class MyWebService {
    @WebMethod(operationName = "sayHello")
    public String sayHello(@WebParam(name = "firstName")
    String firstName) {
        return "Hello, " + firstName + "!";
    }
}
  • Creare un progetto in Rails e richiamare il Web Service remoto:
class MyController < ApplicationController
  require 'soap/wsdlDriver'
  
  def index
    XSD::Charset.encoding = 'UTF8'
    wsdl = "http://TOMCAT_SERVER:8080/MyWebApp/MyWebService?wsdl"
    service = SOAP::WSDLDriverFactory.new(wsdl).create_rpc_driver

    result = service.sayHello :firstName => 'Bruno'

    render :text => result.return
  end
end

Ovviamente i due componenti precedentemente descritti potranno anche stare sulla stessa macchina, comunicando tramite l’interfaccia di loopback.

C’è da ricordare che lo standard XML dei Web Services permette di ritornare come output soltanto i seguenti tipi di dato:

  • Boolean
  • Byte
  • Double
  • Datatype
  • Decimal
  • Enumeration
  • Float
  • Int
  • Long
  • Qname
  • Short
  • String
  • TimeInstant
  • UnsignedByte
  • UnsignedInt
  • UnsignedLong
  • UnsignedShort
  • Array dei suddetti tipi

quindi per passare tipi di dati complessi da un’applicazione all’altra sarà necessario implementare dei metodi di serializzazione/deserializzazione sugli oggetti.

PS: un motivo in più per utilizzare NetBeans, che dalla versione 6 supporta anche Ruby on Rails e PHP! :)