Configurare eclipse per JPlanets

Con questo post voglio illustrare come si configura l'IDE Eclipse per compilare, modificare, debuggare ed eseguire il progetto JPlanets.
Le indicazioni sono valide per qualsiasi piattaforma: GNU/Linux, Windows, MacOsX; le immagini si riferiscono ad Eclipse 3.2 su MacOsX 10.4 (Tiger).

0) avviamo Eclipse;
1) dal menù File, scegliamo New / Project;
2) apparirà una finestra simile a quella mostrata, apriamo la cartella CVS e scegliamo la voce Project from CVS quindi premiamo il pulsante Next;
3) Nella finestra che ci viene presentata, selezioniamo la voce Create a new repository location e premiamo il pulsante Next;

4) Nella finestra di configurazione, riempiamo i campi con questi valori:

• Host: jplanets.cvs.sourceforge.net
• Repository path: /cvsroot/jplanets
• User: anonymous
• Connection type: pserver

...lasciamo vuoto il campo password e premiamo il pulsante Next;
5) come nome del modulo mettiamo jplanets;


6) abbiamo finito!

---

Note:
con questi semplici passi abbiamo ottenuto una working copy del progetto JPlanets come utenti anonimi; per contribuire al progetto occorre accedere come sviluppatori, che operativamente si traduce in:
0) essere registrati come sviluppatori del progetto jplanets
1) modificare il punto 4 inserendo le proprie credenziali (user/password) e selezionando come Connection type la voce extssh. Suggerisco inoltre di biffare la casella Save password.

Riuso e OOP

Oggi sono in vena di ribadire un'ovvietà.
Certamente vi sarà capitato (o vi capiterà) di vivere la seguente esperienza:
il vostro capo/responsabile vi dice che dovete svolgere un dato compito, portare a termine un progetto, ecc. e che sarebbe meglio ricorrere al riuso di parti di questo o quest'altro progetto esistente.
Occhio, adesso arriva l'ovvietà: l'operazione è conveniente se e solo se il progetto di partenza è stato pensato, disegnato e scritto strettamente O.O., altrimenti ecco quello che capita:

- vi ritrovate a copiare/incollare procedure o pezzi di procedure

- sporcate la vostra applicazione con codice fuori contesto

- costruite il vostro codice sulle macerie di un altro progetto, ottenendo un design pasticciato, precludendovi la possibilità di trovare una soluzione migliore.

Questa sorta di riuso all'italiana fa parte del triste retaggio anche noto come "arte di arrangiarsi", applicato al processo di sviluppo del software:

- FASE UNO: scrivi un programmino in fretta, non documentarlo, non pensare nemmeno a un design. Ah, ancora una cosa: indipendentemente dal linguaggio scelto, se proprio devi usarli, usa gli oggetti solo pro-forma, cerca di fare tutto in modo procedurale (So che puoi farlo, non essere modesto).

- FASE DUE: quando servirà un'applicazione per risolvere un problema in qualche modo similare, il tuo successore (perché nel frattempo tu sarai andato a fare il technical manager dalla concorrenza) prenderà i vecchi sorgenti, e nel tentativo di tirar su qualcosa di decente nei tempi imposti farà una minestra di:

- reverse engineering sul tuo codice

- bug fixing del tuo codice

- cross-design tra la vecchia applicazione e quella che si vorrebbe

- codifica modificando le procedure (cioè il core del tuo programma)

tutto questo naturalmente senza accorgersene, senza un planning che dia un nome alle varie fasi di sviluppo, e chiamando infine la suddetta minestra: programmazione.

Questa è la ragione per cui è una buona idea usare librerie di classi pronte (ed esistono aziende il cui business è proprio quello di vendere componenti), mentre generalmente è una cattiva idea cercare di riusare codice scritto per risolvere in fretta un problema.

Metodologie agili??

La situazione dello sviluppo software in Italia è scoraggiante.
Manca una cultura dello sviluppo, la stragrande maggioranza delle piccole aziende che facciano software, o che abbiano un dipartimento di sviluppo, di fatto non utilizza nessuna metodologia, approcciando il processo di produzione del software come fossero piccoli artigiani.

DISCLAIMER: non c'è nulla di sbagliato nell'approccio artigianale, il fatto è che gli artigiani bravi sono pochi: i falegnami che sanno costruire uno splendido comò partendo da semplici assi di rovere sono pochi, e quei pochi impiegano tanto tempo, e si fanno pagare molto.

I programmatori assunti dalla piccola impresa italiana non assomigliano a questi pochi eletti artigiani del legno. Generalmente hanno vincoli di tempo ristretti, sono sottopagati e spesso il loro lavoro non viene apprezzato dai responsabili non-tecnici (quando invece quasi tutti sanno giudicare un comodino ben costruito).

L'artigianato del software assomiglia più alla totale deresponsabilizzazione dei project-manager, project-leader e generici project-something: assumi dei neolaureati, pagali un po' meno della media di mercato, dai loro un compito definito fumosamente, dai dei tempi basati sulle tue impressioni e al termine verifica che lo staff non ha capito cosa doveva fare, i tempi si sono decuplicati, i programmatori si odiano tra loro e odiano i project-something.

Bene, se questa è la situazione nella vostra azienda è meglio chiarire subito e brutalmente una cosa: non siete in grado di mettere su neanche una cassetta per la frutta, altro che comodino in rovere.
Dovete ricorrere a delle metodologie.

I project-something a questo punto ripescheranno nella memoria le paroline magiche che illustrano la strada vincente: metodologie agili, che negli cervelli dei diversi attori si traducono in:

[manager capo]: azienda all'avanguardia, siamo forti!

[project-something]: lavoro fatto bene, meno lavoro per me, più lavoro per lo staff.

[programmatore]: nessun vincolo, nessuna metodologia.

Le metodologie agili funzionano se il team di sviluppo conosce e usa già una metodologia (non agile), altrimenti è molto probabile che un processo agile venga preso come "nessun processo" e si consegni l'intero sviluppo all'anarchia.