Sorrento – quarta puntata (postuma)

8 04 2007

eccoci qui, ormai a cose fatte, tornati alle questioni quotidiane, a
cercare di appuntare le ultime note interessanti dello sprint appena trascorso..

difficile a farsi l’opera di selezione in mezzo ai mille spunti che sono emersi nel giro di cosi’ pochi ma intensi giorni.

abbiamo parlato di remember, di plone 3, delle meraviglie di KSS, non abbiamo ancora parlato dei nuovi meccanismi adottati per la gestione del proprio ambiente di lavoro.. si, perche’ preparare un ambiente di lavoro coerente per poter mettere mano al miglioramento di plone 3 o anche 2.5 potrebbe essere cosa non banale, dato che sbagliare la versione puo’ comportare fix non accurato/adeguato (solo per pensare in positivo).

ebbene, sarete contenti di sapere che, con un paio di comandi o tre da shell e al limite qualche minuto di pazienza, chiunque puo’ avere a disposizione sulla sua macchina l’ambiente perfetto per operare tale attivita’.

la meraviglia viene compiuta da uno script chiamato “buildout“:

http://dev.plone.org/collective/browser/buildout

qui trovate varie possibilita’ a disposizione..

quella da usare nel caso vogliate contribuire a plone 3 invece la
trovate qui.. https://svn.plone.org/svn/plone/ploneout/trunk

per “azionarla”, dopo averne fatto un checkout sulla vostra macchina:

$ cd plone3
$ python2.4 bootstrap.py
$ ./bin/buildout

e fate attenzione ad eseguire *esattamente* questi comandi, se qualcosa va storto, invece, chiedete ad antonio!! :p

bene, se avete fatto quel che la ricetta dice, vi trovate sulla vostra macchina un bell’ambiente aggiornato all’ultima linea di codice di plone 3.0, che potrete far partire con ./bin/instance start

attenzione che per accedere allo zope dovete usare admin, admin (ma se avete letto, come dovreste, i readme a corredo, questo lo sapete gia’!!!).

bello plone 3, non e’ vero!? :)

si.. ci sono un sacco di cose nuove; prima fra tutte con cui fare amicizia il fatto che il buildout vi ha messo le cose a voi gia’ note nella cartella products (badate bene, con la “p” minuscola), ma poi ha usato altre cartelle per ulteriori moduli! “src” contiene le nuove librerie in perfetto stile Z3 usate da plone, “parts” contiene il server zope appositamente scaricato e compilato per voi, etc. etc.

detto cio’, diciamo che e’ ora di partire all’avventura, concentrandoci su uno qualsiasi dei ticket aperti, per interagire con i quali utile sara’ disporre di un login su plone.org, che automaticamente vi permettera’ di accedere anche al tracker ufficiale.

ogni modifica che vorrete apportare potra’ essere fatta quasi senza paura, in quanto plone dispone di un corredo di test molto molto ricco!
e chiaramente, se trovate che qualche test e’ mancante, siete calorosamente invitati ad aggiungerlo! anzi, ogni nuova feature o baco scoperto, non viene ammessa a soluzione senza il relativo corredo di test!

e mi dite quali altri pacchetti open source con cui siete abituati a lavorare vengono gestiti con tale cura?

ma bando alle polemiche.. il test e’ molto utile da molti punti di vista:

  • garantisce che le proprie modifiche non “rovinino” il lavoro di altri
  • documentano il modo “corretto” di usare le interfacce dei moduli sviluppati
  • permettono di rifattorizzare l’esistente senza paure e perdite di tempo eccessive
  • garantiscono la qualità del software prodotto in modo attivo e diretto (non solo a chiacchiere)

certo, costruire il software per effettuare i test non e’ compito semplice ne economico, ne tantomeno sempre applicabile, ma cio’ non significa che sia da implementare in ogni occasione in cui cio’ sia possibile o consigliato! chiunque abbia intrapreso tale strada ne e’ rimasto entusiasta.. e al solito ha sviluppato la giusta sensibilita’ per comprendere di volta in volta cosa vada testato e cosa no.. parola di balasz.

NB: se siete curiosi e volete provare a capire come sviluppare test per le vostre applicazioni plone e non, su plone.org ci sono vari documenti utili ai primi passi e anche all’uso avanzato.. di fatto anche i tool per costruire i test sono open source.. nessun problema a capire cosa fanno!

uno su tutti:
http://plone.org/documentation/tutorial/testing/running-unit-tests

altra nota a margine che viaggia parallela allo script buildout, ma non lo esclude a priori: ploneenv.

Python dispone da un po’ di tempo di un meccanismo di gestione dei propri moduli/pacchetti python chiamato workingenv. ploneenv ne e’ l’adattamente per plone, e caricare l’ennesimo pacchetto e’ semplice come operare un apt-get install!!

ma questo lo vedremo in una prossima puntata (ancora un paio di cosette ve le vorrei dire prima del post finale :) ), e per chi non puo’ aspettare google fa al caso vostro!


Azioni

Informazione

Lascia un commento