Enrico Rubboli

Ieri

Beppe Grillo era un comico divertente, sapeva far ridere nonostante ponesse questioni serie. Questa battuta sullo spazzolino è eccezionale e dimostra che 20 anni fa persino un comico poteva sapere quel che ci aspettava. Oggi infatti abbiamo Napoli sommersa dai rifiuti, con le falde inquinate e discariche tossiche abusive, ed una raccolta differenziata fatta solo per separare l’umido dai combustibili per gli inceneritori.

Beppe Grillo riusciva a far ridere anche spiegando come il significato delle parole viene alterato, o come si cambiano le parole stesse. Allora la candeggina diventa gentile, e l’inceneritore diventa termovalorizzatore. Nonostante la prima uccida chiunque la ingerisca ed il secondo distrugga  definitivamente (non valorizza un bel niente) plastica e carta che potrebbero essere riutilizzate e come se non bastasse aumenti la mortalità per tumori e tante altre patologie di chi ci vive intorno (nonostante molti politici ed affaristi – evidentemente molto più esperti degli esperti – sostengano il contrario).

Read more…

Innanzitutto è la settima edizione della conferenza, significa che sono già 7 anni che qualcuno in Italia parla di queste cose (non so se il fatto che molti speaker siano italiani che lavorano all’estero sia significativo), e questo mi fa molto piacere, ho sempre visto l’Italia come la patria dei programmatori che “fanno FTP per incollare il codice sui file PHP in produzione“, oppure quelli della burocrazia sfrenata, dove una variazione all’analisi significa poi richiedere una nuova approvazione della stessa e nel caso ci sia un bando di mezzo non ne parliamo. Tuttavia eravamo circa 400 presenti, per la maggior parte giovani. Ecco un piccolo riassunto dei talk che ho seguito:

Keynote

L’introduzione all’evento è stata di Paolo Perrotta,  che è senza ombra di dubbio un oratore straordinario. Negli ultimi 30 anni in molti hanno cercato di paragonare l’ingegneria del software alle altre discipline (edile, meccanica ecc.) per risolvere quello che è un problema fondamentale, il suo elevato numero di insuccessi: il 24% dei progetti non viene alla luce, oltre il 70% subisce ritardi e variazioni di budget. Da molti anni qualcuno salta fuori dichiarando “la fine dei programmatori”, la tecnologia XY permetterà di realizzare software senza bisogno di programmatori, purtroppo (o per fortuna?) si tratta di tecnologie che puntualmente falliscono.

Read more…

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.

A volte mi chiedo quanto sarebbe bella l’Italia se fosse un paese normale. Un paese dove i politici fanno il loro mestiere e discutono pacificamente dei problemi cercando insieme la soluzione migliore. Dove il presidente del consiglio non è stato un membro di una loggia massonica sovversiva. Dove i mandanti delle stragi di via d’amelio e capaci sono stati trovati e consegnati alla giustizia. Dove non si sacrifica la scuola e la ricerca (ovvero il futuro) da una parte e si spende e spande per progetti di interesse mafioso dall’altra. Un paese il cui premier non ha ospitato in casa per anni un criminale pluriomicida mafioso che gestiva il traffico di droga e le estorsioni nel nord, definendolo poi un’eroe. Un paese laico che non sperpera il proprio denaro pubblico per la chiesa cattolica. Un bel paese dove Marco Travaglio sarebbe disoccupato oppure costretto anche lui a parlare solo di maltempo. Un paese dove si discute su come risolvere problemi come quello dello smaltimento dei rifiuti e dell’energia e non si impongono soluzioni ai cittadini, mentre il mondo intero ride dell’immondizia lasciata per le strade. Un paese normale, del quale essere fiero.

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:

Tra le novità di ruby1.9 ci sono alcune migliorie sulle espressioni regolari, oltre ad un significativo miglioramento nelle prestazioni, sono state introdotte due nuove funzionalità: look-behind e named captures.

Look Behind

look-ahead e look-behind sono asserzioni che non catturano l’elemento, ma controllano che intorno, rispettivamente davanti e dietro, sia presente o assente. Mentre look-ahead era già presente in ruby 1.8 la look-behind è stata introdotta con la 1.9. Per la look-behind positiva si utilizza la formula (?<=regex), la look-behind negativa invece (?<!regex). Di seguito due esempi, positivo e negativo, di look behind:

Named Capturing Groups

Named capture è una funzionalità a mio avviso molto rubish ed elegante, permette semplicemente di dare un nome alla capture, il nome sarà poi ovviamente la key nel MatchData. Per utilizzare la Named Capture si usa la sintassi (?<name>group). Di seguito un’esempio:

Se necessario utilizzare ruby 1.8 c’è a disposizione la gem di Oniguruma .

Prendendo spunto dal post di Alessandra Farabegoli sulla presunta inutilità dei creativi, ho voluto scrivere questo post ironico cercando di descrivere perché secondo me è di chi si occupa di marketing, che il mondo potrebbe fare a meno. I 10 punti che seguono sono la versione creativa della slide presentata da Alessandra e Gianluca Diegoli:

1. Il markettaro vuole vendere, è sempre solo una questione di soldi
2. Il markettaro dà sempre ragione al cliente, ad ogni costo, pur di vendere
3. Il markettaro non crea nulla, e non gli interessa nemmeno sapere come si fa
4. Se c’è una soluzione più elegante ma più costosa al markettaro non importa, quella vecchia ma “che comunque va” si vende benissimo ugualmente
5. Ogni nuovo canale di vendita è una gioia infinita per il markettaro, soprattutto se gratis
6. Il markettaro non ha bisogno di chiedere a nessuno cosa sia meglio, il markettaro laverebbe i piatti col martello se si vendesse allo stesso prezzo
7. Il markettaro non si fa scrupoli ad alterare la realtà per poter vendere, il fumo è un’effetto speciale
8. Il markettaro tappezza la città di cartelloni pubblicitari, e poi magari chiama i murales sporcizia
9. Il markettaro ha un sito in con un’animazione di 10 minuti for dummies che ti spiega perchè lui è molto più bravo della concorrenza a vendere, in questo caso il markettaro chiama sè stesso meta-prodotto
10. Il markettaro piu stimato tra i markettari è quello che riesce a semplificare le cose al punto da fare soldi senza nemmeno vendere nulla

Tuttavia, i markettari che se la prendono con i creativi, dovrebbero capire che il mondo senza creativi sarebbe all’età della pietra, se nessuno crea niente, c’è ben poco da vendere. D’altra parte in un mondo senza markettari, forse i bisogni della gente non sarebbero manipolati fino a questo punto ed i prodotti sarebbero valutati effettivamente per quel che sono e non per quel che appaiono.

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