Dietro le quinte del sito di Altura Labs

Dalla scorsa settimana è disponibile online il nuovo sito di Altura Labs. Come Claudia ha avuto modo di sottolineare nel post di presentazione, il nuovo sito dà ampio spazio ai progetti made in Altura Labs così come alle tecnologie utilizzate. E proprio di tecnologie vorrei parlare in questo mio primo post, rivelando qualche curiosità tecnica sul dietro le quinte del nostro sito e del nostro blog.

Two is meglio che One

Così come il Maxibon, anche il progetto Alturalabs è composto da due anime: il sito ed il blog. A voi la scelta su quale corrisponda alla granella e quale al biscotto.

Il sito di Altura Labs è completamente scritto in Ruby, basato sul framework Ruby on Rails. Al contrario, il blog gira su piattaforma WordPress e PHP 5. Ebbene sì, se non lo sapevate, è possibile far convivere in modo del tutto trasparente anche su uno stesso server.

Ma vediamo qualche dettaglio in più.

Sito di Altura Labs

Linguaggio

Come anticipato, il sito di Altura Labs si basa si basa sul framework Ruby on Rails, versione 2.3.2. L’ambiente di production utilizza una versione speciale di Ruby, Ruby Enterprise Edition, per sfruttare a pieno le potenzialità del linguaggio in combinazione con mod_rails.

Personalmente sono molto curioso di provare Ruby 1.9.1. Le performance sono eccellenti e la nuova versione si sta comportando decisamente molto bene. Purtroppo, il processo di integrazione di una versione di un linguaggio così profondamente modificata in uno stack di produzione non è attività immediata.

Alturalabs utilizza alcune GEM liberamente disponibili. Il nostro environment.rb contiene più o meno le seguenti istruzioni

config.gem "chrislloyd-gravtastic", :lib => "gravtastic", :source => 'http://gems.github.com'
config.gem "lukeredpath-simpleconfig", :lib => "simple_config", :source => 'http://gems.github.com'
config.gem "mislav-will_paginate", :lib => "will_paginate", :source => 'http://gems.github.com', :version => '>= 2.3.0'
config.gem "RedCloth", :lib => 'redcloth', :version => '>= 4.0'
config.gem "thoughtbot-paperclip", :lib => "paperclip", :source => 'http://gems.github.com', :version => '>= 2.2'
config.gem "thoughtbot-shoulda", :lib => "shoulda", :source => 'http://gems.github.com'
config.gem "weppos-helperful", :lib => "helperful", :source => 'http://gems.github.com', :version => '~> 0.3.1'
config.gem "weppos-tabs_on_rails", :lib => "tabs_on_rails", :source => 'http://gems.github.com', :version => '~> 0.3'

Per i meno tecnici, ecco una breve panoramica.

• chrislloyd-gravtastic è una delle GEM ufficiali l’integrazione su Rails di Gravatar, il servizio che usiamo per mostrarvi le nostre (belle?) facce sia sul blog sia sul sito
• lukeredpath-simpleconfig è oramai uno standard de-facto di ogni nostro progetto. Consente la gestione di un sistema di configurazioni globali in modo flessibile, elegante, per environment e con una speciale DSL per la definizione delle variabili.
• mislav-will_paginate non ha bisogno di presentazioni dato che è lo standard de-facto per la paginazione dei record per ActiveRecord.
• RedCloth è un parser Textile per Ruby.
• thoughtbot-paperclip è un plugin per l’upload in Rails. Normalmente la preferiamo ad altre alternative altrettanto note come attachment_fu.
• thoughtbot-shoulda è un plugin per semplificare la creazione di unit, functional ed integrational test in Ruby e Rails.
• weppos-helperful è un plugin Rails che contiene una lista di helper più o meno utili che utilizziamo in molti progetti Rails.
• weppos-tabs_on_rails è un plugin Rails per la creazione gestione di tab e menu di navigazione in Rails.

Come avrete senz’altro notato, diverse di queste GEM sono in realtà plugin per Ruby on Rails. Infatti, normalmente preferiamo utilizzare le GEM quando disponibili. La cartella plugin contiene ugualmente un paio di prodotti interessanti:

• jrails per integrare jQuery in Rails come alternativa a Prototype.
• Google AJAX Libraries API per sfruttare la versione di jQuery ospitata da Google, traendo così vantaggio dal loro sistema di Content Delivery Network.

Database

Il database di riferimento per questo e per la maggior parte dei nostri progetti è PostgreSQL. Tutte le nostre applicazioni Rails utilizzano PostgreSQL in production ed in staging, mentre normalmente preferiamo SQLite 3 in fase di test e sviluppo.

PostgreSQL è uno degli ingredienti base delle nostre ricette. Da quest’anno, Altura Labs è anche sponsor ufficiale del PGDay. Credo che ci sarà senz’altro occasione di approfondire l’argomento in futuro su questo blog.

Blog di Altura Labs

Quanto si è trattato di scegliere quale piattaforma adottare per il blog di Altura Labs non l’abbiamo tirata troppo per le lunghe. Il blog precedente era ospitato su piattaforma WordPress così la scelta è stata abbastanza naturale.

Altra piattaforma altro database. Purtroppo WordPress supporta solo MySQL dunque anche in questo caso la scelta è stata obbligata.

Frontend e Backend Server

La struttura di frontend e backend dei nostri progetti è mediamente complessa e, da sola, merita un post dedicato.

Senza entrare troppo nei dettagli, sia il sito di Altura sia il blog utilizzano Apache come web server. Nel primo caso si tratta di un’installazione multi-thread con mod_rails, nel secondo di un’installazione classica per PHP 5. Come avrete capito, le due applicazioni girano su due server differenti.

A gestire le danze ed il traffico ci pensa un frontend server che si occupa delle operazioni di proxy. In questo caso il compito è egregiamente assolto dal russo Nginx.

E i test?

Non potevo concludere l’articolo senza un accenno all’argomento test. Credo che il team di sviluppo non me l’avrebbe mai perdonato, considerato quanto io sia particolarmente stressante sull’argomento (ebbene sì, lo ammetto!).

Il sito di Altura è un progetto relativamente semplice ma, nella sua semplicità, comporta comunque un certo grado di complessità. Così come ogni nostro progetto, anche questo comprende unit, functional ed integrational test.

Il code coverage di questo progetto è del 73.4%. Tipicamente ad abbassare la media sono le funzionalità di caching che, in Rails, sono particolarmente complesse e macchinose da verificare in modo automatico.

Numeri a parte, i test sono un aspetto fondamentale del nostro processo di sviluppo, supporto fondamentale alle periodiche attività di refactoring e manutenzione del codice.