[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: [OT] Una ferale notizia?



Il Sat, 23 Aug 2014 14:02:14 +0200, MaX ha scritto:

> Del tipo... quante tabelle deve avere il db?
> quali nomi gli diamo ad ogniuna?
> quandi campi e caratteristiche avrá ogniuna?

Questo lo puoi fare com mysql-workbench, per esempio. Puoi anche creare 
lo schema UML del DB e definire le constraint e le foreign keys.

> Quante intefacce (schermate) deve avere il programma?

Questo lo fai con Glade o QtDesigner. Il secondo non lo conosco molto, ma 
in Glade puoi definire le callback per ogni area attiva, e ti genera un 
XML. Tramite libglade lo puoi usare da Python, C/C++, e probabilmente 
anche PHP e Ruby.

> ad ogni schermata quali campi di quali tabelle mettiamo?

Questo non ha molto senso. Molto raramente hai una corrispondenza 1:1 tra 
quello che devi mostrare a schermo e come lo salvi in DB. Qui è compito 
del programmatore definire i model che interfacciano appunto lo storage 
con le view.

> a quel punto la tool crea tutto il codice per interfaccia a caratteri
> tipo ncurses per intenderci, in un linguaggio da stabilire, aggiungendo
> delle opzioni standard, tipo stampa, esportazione dati, menu, ecc.

Il punto è che non esistono "opzioni standard". :)
A meno che non fai una banale rubrica, un gestionale avrà la sua forza 
nel modo in cui salva e gestisce i dati.

> Praticamente Unix è come un Lego... offre un sacco di mattonici da
> abbinare a propria scelta. Usiamoli al posto delle stermiante librerie
> che quasi tutti i linguaggi di programmazioni offrono, cosí non dobbiamo
> reinventare la ruota ogni volta.

Praticamente tutte le librerie dei linguaggi sotto Linux sono wrapper 
attorno alle librerie standard.

Le eccezioni sono quegli ambienti che cercano di astrarre tutto (Java, 
Mono, Gambas per dirne tre) che vorrebbero essere multipiattaforma. Basta 
ignorarli. :)

> Se devo creare un report di stampa alivello professionale, è melgio
> partire da zero con le librerie, o creare un file di testo per latex e
> farglielo processare?

Per alcune cose è meglio usare reportlab da python, per esempio.
Per altre magari generare HTML e trasformarlo in pdf con wkhtml2pdf, o 
generare markdown e trasformarlo in epub, pdf e html in modo da averlo 
leggibile ovunque.
Insomma, dipende. :)

> Alla fine avremmo ottenuto in poche settimane di lavoro, un gestionale
> con interfaccia a caratteri perfettamente funzionale.

Dipende dal gestionale, ma in poche settimane, volendo, puoi farlo anche 
in PHP. Prendi Bootstrap+Backbone o AngularJs per il frontend, Symfony o 
un altro framework per il backend, ecc.

E sarebbe anche multipiattaforma (magari con IE>9 :P)

> bho... per il momento non mi viene in mente altro.

Io credo che tu stia cercando di sostituire un buon programmatore con un 
pessimo tool. :)

Non offenderti. Capisco che non sei un programmatore, ma un tool come 
quello che proponi avrebbe limitazioni troppo strette per andare oltre la 
classica agenda telefonica o il programmino per prendere note o fare un 
todo.

O comunque "attirerebbe" schiere di script kiddies e verrebbe ignorato 
dai 
senior.

Gli strumenti ci sono, e sono anche abbastanza potenti. Il problema è la 
"spinta" di cui un team avrebbe bisogno per mettersi a sviluppare una 
cosa del genere. E soprattutto un team di senior che sappiano quello che 
fanno.

Se nessuno paga per avere un gestionale che giri su Linux, nessuno si 
metterà a farlo. Quando fai un gestionale, per quanto scrivi nella 
licenza 
"senza nessuna garanzia", se uno te lo paga o comunque lo usa per 
metterci 
la contabilità, si aspetta che le garanzie ci siano, e se succede 
qualcosa 
ti trovi in tribunale, alla faccia della GPL.

Scusami, confesso che la mia era una domanda trabocchetto. ;)

Bye.



Reply to: