E’ da un po’ di tempo che cercavo di “sistemare” un’accozzaglia di plugin per creare un bel strumento di sviluppo basato sull’ultima release di Eclipse quando mi imbattei in Jazz
l’ultima diavoleria per sviluppatori concepita dai mostri (in senso buono) di IBM-Rational.
Non ne avevo mai scritto (ed in realtà non avevo nemmeno usato molto questo prodotto) perchè le licenza era un po’ “strana”. Prevedeva infatti una prima fase “open” ed una seconda commerciale, in puro spirito open commercial. Questo ci sta, ma la prima fase era aperta solo ai clienti rational ed IBM e quindi non ero tra i “papabili”. I filmati demo (aperti a tutti) erano però veramente impressionanti!
La svolta un po’ di giorni fa. Come segnalatomi da Simone e come riportato qui ora jazz è aperto a tutti.
Ma andiamo con ordine: cos’è Jazz? E’ molto semplicemente una piattaforma per lo sviluppo in ambienti Java-J2EE. La novità è che è orientata al Team e non al singolo sviluppatore. Si compone quindi di una parte Client e di una parte Server. Il client è un Eclipse con parecchi plugin già configurati e tutto il necessario per connettersi al server. Il server contiene tutto ciò che uno sviluppatore si può aspettare pe la gestione di un progetto ovvero:
- SCM: Si appoggia ai più comuni repository come CVS ed SVN
- Continuous Integration build system: al commit parte in automatico una build di integrazione. I risultati vengono notificati nel sito di progetto, gestito anch’esso da jazz e, se necessario agli sviluppatori.
- Groupware e project management: permette di gestire i task, di assegnarli ai membri dei team e di definire un team. Le comunicazioni sono gestite tramite una chat che utilizza jabber come piattaforma di IM.
- Instant messaging: Si integra con i precedenti sistemi e permette ai membri del team di comunicare tra loro e di ricevere notifiche ad esempio dal sistema di build
- Development process management e wiki integrati con il groupware e gli strumenti di project management
Lo so, tutto questo si può ottenere con poco sforzo anche con eclipse liscio aggiungendo mylin, il WTP ed altri plugin, ma volete mettere la comodità di avere uno strumento integrato?
Vale la pena provarlo, per partire iniziate qui e… buon divertimento!
Rilancio la segnalazione di Virgilio con un altro evento degno di nota: l’italian Agile day. Si terrà a Bologna il prossimo 23 novembre ed io mi sono già iscritto. Per maggiori info date un occhio direttamente al sito: http://www.agileday.it
Accorrete numerosi e fate donazioni!
Un post per creare dubbi e non risolverne nessuno…
Ho bisogno di rendere modulare una parte di una java application. Fin qui è facile: ho un oggetto che rappresenta la parte modulare/intercambiabile e ne definisco l’interfaccia. Per cui ho qualcosa tipo
interface IPlugin
{ ResultObject mainMethod(ParamObject) }
Supponiamo che molta gente dica “che figo! aspetta che implemento un mio plugin”.
A questo punto, quando il programma passerà alla versione 2.0, sarà importantissimo che tutti questi plugin non smettano di funzionare. Non posso dire “hei, ho definito l’interfaccia IAdvancedPlugin, adesso si usa quella, riscrivete il vs codice”.
(continua…)
Continuiamo la carrellata di strumenti open source per lo sviluppo rimanendo nell’ambito del processo di build del progetto. Supponiamo quindi di aver creato il nostro file di build con ant o con maven e di avere quindi un processo di sviluppo così modellato:
- Check out dei sorgenti: lo sviluppatore scarica in locale dal repository di progetto i sorgenti.
- Codifica: lo sviluppatore implementa una funzionalità o corregge un bug
- Test: lo sviluppatore esegue i tutti test automatici presenti nel progetto
- Build: si richiama il file di build per controllare che le modifiche effettuate non provochino dei problemi nella compilazione del progetto
- Check in dei sorgenti: lo sviluppatore persiste nel repository centralizzato le modifiche effettuate in locale
(continua…)
Abbiamo visto, nella prima parte del post come usare uno o più strumenti per assecondare e/o cambiare il processo di sviluppo del software tentando di migliorarlo. Focalizziamoci sul processo e diamo alcune definizioni (scusate l’approssimazione e la sintesi):
- Processo: insieme di attività che portano al compimento dell’obiettivo che ci si è proposti (in questo caso lo sviluppo del software)
- Attività: Insieme di azioni svolte da uno o più attori per produrre artefatti
- Attore: Persone/sistemi software coinvolti nello svolgimento di attività
- Artefatto: tutto ciò che viene prodotto da un attore durante lo svolgimento delle attività che compongono il processo
- Metodologia: Insieme di processi organizzati in maniera strategica allo scopo di raggiungere l’obiettivo della conclusione del progetto
A monte quindi della scelta degli strumenti occorre porre l’enfasi sulla metodologia da impiegare per lo sviluppo. Ce ne sono mille e come già evidenziato dal post di Virgilio quelle che vanno per la maggiore in Italia sono quelle agili. Nessuna di queste metodologie può però vantare uno strumento che permetta di gestire in maniera coerente le varie entità evidenziate sopra e che permetta di modificare, assemblare e pubblicare in un repository coerente e centralizzato sia i processi che gli artefatti (per inciso il software prodotto è un artefatto). L’obiettivo, si badi bene, non è solo quello di formalizzare i processi, ma anche quello di razionalizzare gli sforzi del management che, in ambienti complessi e dinamici come quelli dell’attuale mondo dell’IT può avere a che fare con un alto turnover degli attori coinvolti e quindi con un enorme overhead dovuto al passaggio di consegne.
Tutto questo può essere gestito con strumenti come il già citato Rational Method Composer che ha principalmente (ma non solo) come target la metodologia RUP e permette di gestire processi, best practice, ruoli, artefatti ecc.
Dato che però vogliamo rimanere nel mondo open source, consideriamo l’uso dell’Eclipse Process Framework per gli amici EPF.
(continua…)
Stavo preparando un post che parlava di tutt’altro ma, rispondendo al commento di Simone sul post di Virgilio, mi sono accorto che il mio commento stava diventando troppo lungo.
Quando Simone parla di fallimento del RUP ho avuto un tuffo al cuore…. Il RUP è usatissimo in nord europa in aziende di dimensioni medio-grandi anche non di informatica come ad es. la Volvo (viene usato nelle loro sezioni IT).
Il fallimento del RUP è dovuto al fatto che in Italia molti leggono commenti di consulenti ed altri paper ma nessuno si è preso la briga di studiare la documentazione a corredo della suite di Rational che spiega bene che cos’è il RUP. A me purtroppo è capitato all’università e sinceramente mi ha fatto cambiare la maniera di vedere le cose. Ho visto semplicemente che tutti i problemi legati in qualche modo al software erano se non risolti almeno trattati dal RUP. Anche Simone si fa prendere dal “sentito dire” ed afferma che si deve usare solo per grandi progetti. Allora mi chiedo, perchè la Rational nella documentazione del RUP ha fatto un profilo chiamato “Small Project”?? Io l’avevo seguito per l’esame di ingegneria del software e si tratta di scrivere 14 artefatti di cui 2 opzionali ed alcuni molto brevi (nei 14 c’è anche il glossario per intenderci). Inoltre ci sono diversi articoli che parlano proprio di ciò come ad esempio: questo
(continua…)
Diciamocelo, il post del lunedì è sempre il più facile. Non mi ricordo nulla di cosa ci siamo detti la scorsa settimana e quindi parlo di quello che mi passa per la testa 
Oggi metodologie. Evitando di pestare i piedi a Giorgio che prima o poi ci parlerà concretamente dello sviluppo software.
Oh, dimenticavo, i dettagli si trovano ovunque in rete, qui vi racconto cosa ho (intra)visto per esperienza, per il resto iniziate dai siti di riferimento:
Provo a raccontarvi la mia esperienza personale:
(continua…)
