Feed RSS

VARNISH 3.0 Milan Release Party

Inserito il

Yesterday I was at the Milan VARNISH 3.0 Release Party hosted by ZephirWorks to make a “lightning talk” version of my “Varnish e caching di applicazioni Rails” talk I gave at the last RubyDay.

It was very interesting follow the lightning talks because they gave me new ideas on how to integrate Varnish in the application architecture not only to be the “http accelerator” but to be an active architecture component to separate concerns and responsibilities and have much simpler piece of software.

I had the opportunity to have a deeper understanding on what to watch if varnish is in a good shape or not, good stuffs.

I was impressed by so many people were there for a niche’s software, in italy at least. I think it a good starting point to create a devops community… as discussed yesterday we should start organize some sort of local user-group to start sharing experiences and trying ideas.

I hope to find their slides somewhere to review them :)

Well done!

Upgrading to rails 2.3.11 – A selenium and mongrel odyssey

Inserito il

In the last weeks, as a low priority task, I ported our rails app from 2.3.4 to 2.3.11.
The process went well, I updated all gems, fixed all warnings and all our cucumber, spec, unit, function, integration tests… easy stuffs.
BUT we have also some selenium tests that cover ajax interactions and some critical scenario for our app, so I started to check if everything was fine there also and that was the start of my odyssey.

To make a long story short here are the steps I followed to find the problem:

running the tests I was receiving:

1) Error:
test_already_used_coupon_inserted_before_login(BuoniScontoMonousoSeleniumTest):
Webrat::TimeoutError: Timeout exceeded (after 5 sec)
webrat (0.7.3) lib/webrat/selenium/selenium_session.rb:189:in `wait_for'
webrat (0.7.3) lib/webrat/selenium.rb:62:in `wait_for'
/test/selenium/../selenium_test_base.rb:117:in `assert_contain_waiting'
/test/selenium/../selenium_test_base.rb:81:in `log_in'
/test/selenium/buoni_sconto_monouso_selenium_test.rb:29:in `test_already_used_coupon_inserted_before_login'

basically it cannot verify the user is correctly logged in.
I thought it was a cookie/session problem because I saw it was able to find the given user so I put a "debugger" to be able to use the firefox in the middle of the test and check the response headers. No session cookie was present after log in.

Using script/server everything was fine... so what's the problem, it should be in the way webrat starts mongrel so I looked in the webrat source to find in which way it starts mongrel.
I started mongrel directly from the terminal and as soon as it was up & running visiting the homepage I got these errors in the console:

Fri Jun 16 13:21:12 +0200 2011: Error calling Dispatcher.dispatch #
/Users/silk/.rvm/gems/ruby-1.8.7-p302@epistore.2.3.10/gems/mongrel-1.1.5/bin/../lib/mongrel/cgi.rb:108:in `send_cookies'

Bingo! from here it was easy to ask google for a solution "mongrel_server rails 2.3.11 cookies" and it pointed me to this post that have the solution:

http://rcaguilar.wordpress.com/2011/02/14/broken-mongrels-after-rails-2-3-11-upgrade/

Now it's time to move to rails 3.0.9!!!

Italian RubyDay 2011 – Varnish e caching di applicazioni Rails

Inserito il

Last Friday I presented “Varnish e caching di applicazioni Rails” at the first italian RubyDay here you can find my slides:

Varnish won’t start

Inserito il

This morning I’ve updated our amazon 32bit image with varnish.
After I applied the current configuration used on our 64bit image (on which it works flawlessly) varnish was able to start only the admin interface.

Logging in in the admin interface and asking for the status I was receiving:

200 22      
Child in state stopped

And trying to start it:

child (30152) Started
Pushing vcls failed: CLI communication error (hdr)
Stopping Child
200 0       

Child (30152) died signal=11
Child (-1) said 
Child (-1) said Child starts
Child cleanup complete

the options I was originally using were:

DAEMON_OPTS="-a :80 \
-T 127.0.0.1:6082 \
-smalloc,1GB \
-f /etc/varnish/default.vcl \
-u ubuntu \
-g ubuntu \
-p sess_workspace=262144 \
-p listen_depth=2048 \
-p overflow_max=2000 \
-p ping_interval=2 \
-p log_hashstring=off \
-h classic,5000009 \
-p lru_interval=60 \
-p esi_syntax=0x00000003 \
-p thread_pool_add_delay=2 \
	-p thread_pools=2 \
	-p thread_pool_min=100 \
	-p thread_pool_max=4000 \
-p shm_workspace=32768 \
-p default_grace=3600 \
-p sess_timeout=10 \
-p pipe_timeout=10 \
-p send_timeout=10"

Using the "-d" option I was able to test all the options and at the end the problem was with:

-p sess_workspace=262144

It was too large for a 32bit system as stated on the varnish documentation:

Be aware that on 32 bit systems, certain default values, such as
sess_workspace (=16k) and thread_pool_stack (=64k) are reduced 
relative to the values listed here, in order to conserve VM space.

Mini XP Day 2011

Inserito il

In December me and Matteo Vaccari have presented the The Open-Closed Principle Dojo based on his OCP Kata.

After the good feedback received, our session has been selected as the twelve of the favourite sessions of XP Days 2010 for the Mini XP Day Benelux 2011.

Wow second year in a row (after the birthday greetings kata last year) :) and for the second time I’ll present a session in solo (I’m always a little be scared about this).

Now it’s time to review the feedback, integrate it and improve the session!

Parlando di team, progetti e pair programming

Inserito il

Nelle mie ultime esperienze mi sono trovato a lavorare in teams che dovevano gestire più progetti contemporaneamente ed ho potuto constatare come un team sia in grado di lavorare come singoli all’interno della stessa stanza o come vero team che collabora, si aiuta e consegna maggior valore al cliente.

Tutto sta nel come si gestiscono i progetti.

Quando la gestione prevede l’assegnazione di nomi ad un progetto si instilla la “paura” o la “competizione” negli sviluppatori, a seconda del contenuto tecnologico e/o di business  dello stesso. Ma di fondo si sà che passeranno diversi mesi senza poter vedere qualcosa di nuovo o più interessante.

Io sono fortemente convinto invece che la gestione deve essere fatta assegnando i progetti ad un team.

Vediamo cosa cambia applicando i due approcci.

Se assegnamo i nomi ad un progetto:

  • le persone non ruotano sui progetti per lunghi periodi, perchè il time-in è alto e deve essere ammortizzato su un periodo più lungo di tempo.
  • le coppie che si possono formare sono poche e quindi si lavora molto spesso con le stesse persone.
  • le coppie tendono a ruotare (all’interno del progetto) meno spesso, facendo lavorare per molti giorni di seguito la stessa coppia.
  • gli stand up meeting sono noiosi perchè quando si parla di progetti su cui non si è coinvolti è molto difficile rimanere attenti.

Se assegnamo i progetti ad un team:

  • le persone ruotano giornalmente sui progetti, facendo circolare velocemente idee, nuovi punti di vista, conoscenze.
  • le coppie che si possono formare sono tutte quelle possibili e quindi si lavorerà con persone diverse tutti i giorni
  • tutti partecipano attivamente e con attenzione allo stand up meeting rendendolo più efficace

Ovviamente per far funzionare bene il team e per evitare di creare confusione dal lato del cliente ogni UserStory dovrà essere “firmata” da uno sviluppatore che avrà la responsabilità di portarla a termine.
Questo comporta che tale sviluppatore non ruoterà su altre storie, ma una volta terminata potrà decidere se

  1. firmare una storia dello stesso progetto
  2. firmare una storia di un altro progetto
  3. non firmare alcuna storia in modo da poter cambiare progetto ogni giorno.

Come passare da un’organizzazione all’altra? per passi ovviamente.

All’inizio le persone che erano precedentemente assegnate al tal progetto saranno le uniche in grado di firmare le carte perchè saranno le sole che padroneggiano dominio e design e che permettono di continuare ad essere produttivi, così facendo otteniamo però che metà delle persone precedentemente assegnate al progetto saranno libere di lavorarne altri.

Il secondo passo è ruotare giornalmente le coppie in maniera da iniziare a far fluire le informazioni da una persona all’altra dando insieme il grosso vantaggio di avere un paio d’occhi nuovi e smaliziati sulle questioni correnti (es. P1:”ma perchè continuate a passare questa informazione che è già contenuta nel secondo parametro?”, P2:”oooops… hai ragione! Eliminiamolo!”)

Dopo qualche iterazione (qualche settimana) tutti i non-firmatari avranno preso confidenza con tutti i progetti in corso ed inizieranno a farsi avanti al momento della firma delle nuove storie andando a sostituire coloro che erano finora le sole possibili scelte, permettendogli, a loro volta, di ruotare sugli altri progetti e completare il processo di “osmosi”.

Questo permette di costruire un TEAM che non sia meramente un gruppo di singoli sviluppatori ognuno impegnato a coltivare il proprio orticello.

IL CLIENTE

Se non si ha il “customer on site”, ed in una configurazione multi-progetto è molto probabile, un area da gestire è il contatto con il cliente. Per farlo sentire a proprio agio all’inizio bisogna dare continuità alle persone con cui dialoga, dandogli il tempo di fidarsi dei “nuovi arrivati”.

Pian piano il cliente conoscerà tutti i componenti del team e il problema si andrà affievolendo. Qui la questione per me è ancora aperta nel senso che sto osservando le reazioni a questi cambiamenti da parte del customer.

IL NUMERO DI PROGETTI

Il numero di progetti che si possono seguire contemporaneamente dipende da come si decide di pianificare, il team ha una capacità determinata dal numero di coppie che si possono formare (team di 10 sviluppatori formano 5 coppie) quindi si può andare da un semplice “Un progetto -> una coppia” ad una gestione un pò più complessa fatta così:
data una velocità complessiva di 12 punti ad iterazione si allocano 6 punti al progetto A, 3 punti al progetto B, 3 punti al progetto C, in cui la ripartizione dei punti è decisa da come è stata venduta ai clienti.

A

Pair experience

Inserito il

Da un pò di giorni sto facendo pair con Jacopo su bug (!!!), per farla breve, dopo aver fatto uno spike per validare una teoria/intuizione è iniziata una discussione sulla validità (dal punto di vista della testabilità) della stessa.

Dopo 10 minuti di discussione, in cui lui era il driver ed io lo provocavo con frasi del tipo “Si ma qui come lo testi? e qua?” Jacopo ha detto “Facciamo così, ci mettiamo qui fianco a fianco e ognuno implementa la propria soluzione (ndr. ovviamente in TDD) e poi vediamo qual’è la migliore”.

Detto fatto! Nel giro di 2 pomodori avevamo entrambi le soluzioni con tutte le barre verdi e pronti per integrare e, nel mentre, continuavamo comunque a darci una mano l’un l’altro quando avevamo degli intoppi, facendo pair prima sul mio codice poi sul suo.

Terminato “l’esercizio” abbiamo sottoposto i risultati , argomentandoli, al resto del team ed abbiamo lasciato a loro la scelta finale… o meglio ci abbiamo provato!
Si perchè le due soluzioni, pur essendo differenti, erano tutte e due molto valide, quella di Jacopo era forte nell’applicazione dell’OCP avendo utilizzato un nuovo decorator, la mia d’altro canto era molto forte sulla semplicità; questo ha portato quasi tutti i membri del team ad essere fortemente indecisi quindi alla fine abbiamo raccolto il feedback ed abbiamo preso noi la decisione.

Good job!

A

Iscriviti

Ricevi al tuo indirizzo email tutti i nuovi post del sito.