A volte ritornano... Re: [PLUTO-Journal] XPJ

[Marcello.seri]

> nicolafragale a libero.it wrote:
> > Ciao
> 
> Ciao Nicola, speravo che entrassi in gioco anche tu :-)
> 
> > io suggerisco di seguire un approccio a la Ingegneria del Software.
Cioè
> > stabiliamo prima, e nel modo più preciso possibile le nostre
necessità, passiamo
> > poi alla progettazione del sistema e infine iniziamo a scrivere il
codice.
> 
> Uhm...
> 
> > Una volta definite e formalizzate le nostre esigenze in un documanto
di
> > specifica dei requisiti (scopo del progetto, tipo di tag da
supportare, formati
> > in cui esportare, editor visuali o meno, tutto quello che dalla
discussione
> > risulta essere utile, ecc), passiamo alla progettazione
> 
> La definizione delle esigenze era gia` stata fatta, e in base a quella 
> io avevo prodotto il DTD; questa parte va, al massimo, formalizzata o 
> appena rivista, se qualche esigenza e` cambiata nel corso di questi 
> ultimi anni, ma rifarla da capo mi sembra che prenderebbe troppo tempo e 
> ci rimetterebbe al palo. Stavolta, pero`, definitivamente.

Qui sono daccordo, c'è da correggere il DTD che abbiamo (quello che si
ritiene migliore tra i due) e partire da quello. Sono daccordo anche sul
fatto che vanno solo ricontrollate le esigenze che erano uscite all'epoca
della proposta. Sinceramente non ricordo se mi ero inserito tra i
partecipanti o no, comunque dal 24, finiti gli esami, ho parecchio tempo
utile e un discreto allenamento con XSLT ed XSL, per cui credo di potervi
dare una mano se serve.

> > Apriamo su Pluto Devel una pagina ufficiale del progetto,
pubblichiamo
> > questi documenti (che saranno la nostra guida) e iniziamo a scrivere
il core del
> > codice.
> 
> Non lo vedo strettamente necessario. Anzi, considerato il tempo che 
> avremo per lavorare al progetto e il tempo che abbiamo gia` perso, 
> mettere su una pagina per pluto-devel mi sembra addirittura _dannoso_.

Concordo pienamente.

> Il tuo approccio e` estremamente pulito, logico, ordinato... ma contiene 
> anche una serie di passi che per necessita` dobbiamo saltare. Non 
> possiamo ne' impiegare tempo a fare cose che abbiamo gia` fatto in 
> passato (vedi le valutazioni sulle esigenze: riprendiamo i vecchi thread 
> e vediamo se bisogna aggiungere/togliere/cambiare qualcosa, stop), ne' 
> sulle formalita` (la pagina ufficiale del progetto su pluto-devel: ci fa 
> perdere tempo e basta; troviamo piuttosto un punto comune dove 
> condividere i documenti -io credo di poter mettere a disposizione una 
> istanza di OpenGroupware, ad esempio).

mmh... dalla rete dietro cui mi trovo posso usare solo ftp passivo, http ed
https, come funziona OpenGroupware?

[cut]
> > Questa a grandi linee è la via che attualmente l'ingegneria del
software
> > prescrive per la realizzazione di sistemi software di dimensioni non
banali, e
> > il nostro ad occhio e croce lo è.
> 
> Non e` piccolissimo, ma neanche grande.
> 
> Se nel progetto comprendi anche la realizzazione di un editor per il 
> formato XPJ, probabilmente ne usciamo malissimo... 

Non credo sia il caso di fare un editor per ora, al più *a progetto finito*
si possono creare i filtri xsl per far trasformare ad OpenOffice i suoi
documenti in pagine xml conformi al formato che è stato creato.

> ma se per ora il 
> focus del progetto rimane:
> 
> * definire un formato per gli articoli,
> * definire un formato per il journal
E questo si può fare coi DTD o con XMLSchema se non sbaglio

> * definire il formato delle pagine web e del PDF da generare,
Questo con XSL, XSLT e varie altre cose che non so usare (soprattutto per
quanto riguarda il PDF)... [non sono sicuro di aver ben compreso questo
punto]

> * scrivere dei fogli di stile in qualche linguaggio,
Qui di sicuro vanno bene XSL, XSLT e CSS, ma forse si può utilizzare
qualcos'altro

> * scrivere degli automatismi per generare HTML e PDF dai sorgenti
Anche qui vanno bene i fogli XSL e varie altre cose.

Ditemi se sbaglio, soprattutto nell'interpretazione di questi punti.

> la dimensione del progetto diventa immediatamente abbordabile, anche per 
> un gruppo ristretto di persone quale siamo attualmente.
> 
> > I vantaggi principali di questo approccio sono
> > relativi ad una più semplice espandibilità e manutenzione, ad un
codice più
> > pulito e coerente, meno bug dovuti ad incongruenze nel progetto (non
si inizia 
> > a scrivere codice da modificare più e più volte a causa di
valutazioni scorrette) ecc.
> 
> Nicola, sono *assolutamente* d'accordo su questo punto, ma 
> l'organizzazione non viene gratis: richiede risorse; e vorrei evitare 
> che sprechiamo risorse ad progettare cose gia` progettate, o a creare 
> strutture che basterebbero a 50 persone per lavorare in parallelo 
> quando, alla fine, quelle persone saranno a malappena 5! Insomma, 
> troviamo una via di mezzo!!!

Io credo che ci sia da mediare tra i due metodi di procedere che avete
proposto. Bisogna decidere bene cosa c'è da fare per evitare di perdere
tempo inutilmente.
 
> > Tutto il lavoro da fare, che a prima vista sembrerebbe inutile,
diventa invece
> > prezioso per l'effettiva creazione del software.
> 
> Ne sono cosciente, ma... calibriamo bene gli sforzi: abbiamo tempo e 
> forze limitati, tutti quanti. Lo sappiamo bene, no?

E' più o meno quello che volevo dire sopra.. ;P 
 --
 Email.it, the professional e-mail, gratis per te: http://www.email.it/f
 
 Sponsor:
 Stanco del tappetino mouse che hai??
Stampaci l'immagine che vuoi tu!

 Clicca qui: http://adv.email.it/cgi-bin/foclick.cgi?mid=2117&d=20050114