Collaborate allo sviluppo FidoCadJ!

[miklos]

Ciao,

io sono un programmatore Java, quindi lavorare col sorgente di FidoCadJ non dovrebbe essere un problema, anche se prima dovrei imparare ad usarlo
Inoltre sono un membro attivo di slacky.eu, una comunità italiana di Slackware Linux dove gestiamo uno dei pochi repository di pacchetti binari, percio' posso creare un pacchetto di FidoCadJ.
Ti chiedo inoltre se hai mai pensato di creare un mirror anche solo del codice sorgente su github dato che la natura social di quest'ultimo rende piu' agevole il controllo e la gestione di patch provenienti dai volontari.

Ciao

[DarwinNE]

Ciao miklos, grazie per esserti manifestato.
Quanto dici è molto interessante!!!

Per quanto riguarda gli aspetti più tecnici, ti proporrei di manifestarti in questa discussione su SF:

http://sourceforge.net/p/fidocadj/discussion/997486/

Sarebbe quanto mai utile avere FidoCadJ disponibile come pacchetto in una distribuzione come Slackware!
Hai esperienza di unit testing, per caso?

Per quanto riguarda GitHub, penso molto spesso alla possibilità di fare una transizione. Quello che mi frena è:
- gli aspetti tecnici legati alla transizione (perdita delle discussioni nel forum, transizione fra Git e SVN, etc.), il fatto che non so usare Git
- la necessità di cambiare tutti gli indirizzi internet associati al progetto, con la conseguenza di dover attendere mesi o anni prima di avere gli indirizzi corretti nei motori di ricerca, etc.

Dato che il mio tempo a disposizione è pochissimo, per il momento ho preferito concentrarmi sui problemi tecnici legati direttamente a FidoCadJ. Oggi GitHub è un sito molto migliore di SourceForge sotto praticamente qualunque punto di vista, però se devo occuparmi della transizione da solo, mi sento male

[miklos]

In realtà, e vado sicuramente offtopic già al 3zo messaggio, potrei creare gli script di creazione dei pacchetti per qualsiasi distribuzione dato che slackware è la piu' antica distribuzione ancora attiva ma non gode della stessa diffusione delle altre quindi con i pacchetti ci si arrangia :)
Sarebbe carino inserirli direttamente nel sorgente in modo che si possano generare i pacchetti a seconda della distribuzione oltre al semplice jar.
Ma di questo ne parlero' sicuramente su sourceforge.

Come unit testing intendi del codice!? perché in quel caso la risposta è affermativa.

Relativamente a github non devi necessariamente traslare tutto quanto, o meglio non sei obbligato se non vuoi. Puoi anche solo avere un mirror del codice disabilitando tutte le altre funzionalità di github(wiki, bug tracker, etc etc etc)
Il consiglio era rivolto alla natura del sistema di versionamento (non tanto al portale in se) perché git è un sistema decentralizzato, quindi io posso prendermi una copia del software lavorare in locale e postare le modifiche alla tua attenzione e tu poi, decidi se inserirle o meno.
Questo senza dover dare privilegi di nessun tipo a nessuno.. con subversion invece se ti volessi mandare del codice dovrei avere accesso diretto in scrittura al repository, oppure inviarti le patch via email.

Comunque concludo dicendo che ho preso ad esempio l'export in formato gerber e devo dire che il codice è molto leggibile, ma forse lo è per me che con java ci lavoro da un bel po'

A presto

[DarwinNE]

... potrei creare gli script di creazione dei pacchetti per qualsiasi distribuzione dato che slackware è la piu' antica distribuzione ancora attiva ma non gode della stessa diffusione delle altre quindi con i pacchetti ci si arrangia :)

Ottima idea. Discutiamone su SF.

Come unit testing intendi del codice!? perché in quel caso la risposta è affermativa.

Esatto. Vorrei avere l'opinione di un esperto per vedere se è indispensabile implementare qualcosa del genere nel codice di FidoCadJ. Per adesso ci sono dei test automatici sotto forma di alcuni script (vedi il README), ma quello che viene testato è poco.

Relativamente a github non devi necessariamente traslare tutto quanto, o meglio non sei obbligato se non vuoi. Puoi anche solo avere un mirror del codice disabilitando tutte le altre funzionalità di github(wiki, bug tracker, etc etc etc)

Molto interessante. Ci rifletterò di sicuro.

Il consiglio era rivolto alla natura del sistema di versionamento (non tanto al portale in se) perché git è un sistema decentralizzato, quindi io posso prendermi una copia del software lavorare in locale e postare le modifiche alla tua attenzione e tu poi, decidi se inserirle o meno.

Io non so usare Git. Potrei imparare se ci fosse una necessità, quanto dici è molto interessante. Ora la domanda è: imparo a usare Git e faccio la migrazione, oppure continuo ad usare SVN e lavoro su FidoCadJ? Per il momento ho sempre optato per la seconda possibilità, ma niente impedisce di passare alla prima qualora ci fossero dei benefici a lungo termine. Già quanto dici mi fa riflettere.

Comunque concludo dicendo che ho preso ad esempio l'export in formato gerber e devo dire che il codice è molto leggibile, ma forse lo è per me che con java ci lavoro da un bel po'

Grazie, ma non è che ho scritto tutto io. Certe convenzioni tradiscono alcune mie vecchie abitudini, vedi per esempio la posizione delle graffe che arriva diritta diritta dal K&R e del primo libro che ho letto su Java negli anni 90 e non sembra affatto quella che va di moda attualmente. Qualche parte del codice è vecchiotta e ben testata, c'è qualcosa che è ben strutturato, altro un po' meno. Occhio che sto cercando di cambiare la posizione di alcuni package un po' alla volta, spostandoli sotto net/sourceforge/fidocadj/

Per quanto riguarda la qualità generale del codice, non ho pretese di fare nulla di trascendente, però FidoCadJ è stato ben valutato in uno studio di un'università canadese:

http://www.cs.usask.ca/documents/techre ... 013-01.pdf

Mi farebbe piacere continuare a migliorare la leggibilità, la modularità e la qualità generale del codice quando possibile, da cui il mio interesse verso i sistemi di verifica statica del codice, il testing, etc. Negli ultimi tempi ci sono stati dei refactoring abbastanza impressionanti portati avanti da un ragazzo giapponese ed anch'io ho lavorato molto sull'organizzazione generale del tutto. Ciò ha permesso di far uscire una versione per Android che condivide molto codice con quella per calcolatori.

Per gli aspetti tecnici, se vuoi contribuire sei il benvenuto, discutiamone su SF. L'esportazione in file Gerber potrebbe essere in effetti un'ottima cosa. C'è anche del lavoro da portare avanti su Android. Ci sono dei discorsi sulla libreria standard (vedi per esempio qui: viewtopic.php?f=4&t=54536 ) in corso e molto altro

Se non rispondo subito, mi scuserai, in questi giorni ho delle prove e dei concerti che si sovrappongono al mio lavoro quotidiano, il tempo libero è davvero poco...

[miklos]

non posso dire di averla sviscerata tutta, ma da quel poco che ho visto buona parte del codice è relativo all'interfaccia grafica e per quell'aspetto non ci sono test unitari fattibili scrivendo codice java perché è difficile simulare l'input (le azioni compiute col mouse etc etc etc).
i test unitari li puoi prevedere per le componenti che prevedono input facilmente programmabili, al momento in fidocadj vedo testabili in questo modo solamente i componenti che esportano in vari formati,ma mi sembra di aver visto che questi test li fai con gli script che hai citato.

ad ogni modo voglio provare a fare la mia parte.. come 'dichiarato' ho creato i pacchetti binari per slackware partendo dai sorgenti e non appena verranno pubblicati sul repository della mia comunità mi faro' l'account su SF e iniziero a postare le mie considerazioni sulle cose migliorabili da questo punto di vista, e non solo

ciao

[DarwinNE]

Il codice che sta dietro al disegno in FidoCadJ è composto da una parte di basso livello (condivisa fra le versioni per Android e Swing) che è più o meno organizzata in model/controller/view, poi c'è del codice più ad alto livello che implementa i vari componenti Android e Swing a seconda delle versioni.

Potrebbe essere eventualmente possibile fare unit testing della parte di basso livello, anche se ho anch'io dei dubbi sull'interesse dell'operazione, perché forse è più semplice vedere se ci sono problemi giocando un po' con il programma. E' anche per quello che facciamo uscire delle versioni preliminari, vedi per esempio le ultime pagine di questa discussione:

viewtopic.php?f=4&t=18347&start=870#p496038

Sentiamoci quindi su SF per quanto riguarda gli script

[DarwinNE]

Come ti ho detto su SF, miklos, hai accesso in scrittura al repository di FidoCadJ

Fanne buon uso. Ti ho proposto qualche lavoretto, non sentirti obbligato ad accettare. Se hai idee, la cosa migliore è discuterne prima di mettersi al lavoro, per vedere come integrarle con la filosofia del progetto e non lavorare inutilmente.

[miklos]

Grazie mille, sono onorato :)
Per quanto riguarda le attività per partire vado con le cose che ci siamo detti su SF + mi spulcio il report dei bugs.
Avevo iniziato una bozza dell'export in gerber, ma sinceramente non ho ancora visto fidocadj lato utilizzatore, quindi non avrei materiale per testarlo.

Grazie ancora :)

[DarwinNE]

richiurci, non ho capito bene cosa sia successo. Il disegno che mostri è normale.
Comunque, sarebbe meglio parlare qui unicamente dei problemi legati allo sviluppo del programma. Puoi provare ad aprire una nuova discussione?

miklos, come ti ho detto su SF, quello che fai è ottimo e ci voleva proprio una mano per quegli script.
La cosa migliore è continuare così: descrivi ciò che pensi di fare sul forum su SF (non esitare ad aprire nuove discussioni), ne discutiamo, e poi lavori sul codice. Come vedi, riesco a riguardarmi uno o due commit al giorno se non sono troppo grossi.

[miklos]

Grazie DarwinNE, mi fa piacere darti una mano, e di riflesso a tutti gli utilizzatori del tuo lavoro .
Per il momento, anche per prendere un po' di confidenza col progetto e non gettare troppa carne al fuoco, penso che ti aiutero' a portare a termine la migrazione dei package.
Comunque ci sentiamo su SF

Ciau