Re: [OT] Una ferale notizia?
> On 23/ago/2014, at 15:17, Alessandro Pellizzari <alex@amiran.it> wrote:
>
> 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.
Oppure usare Postgres. Fatto meglio e non è di Oracle. Mysql è un trappolone con cagate progettuali favolose (esempio: fate un'applicazione su un file System non case sensitive e poi usatela su uno case sensitive)
Oppure in certe situazioni meglio un non SQL.
Comunque ci vuole una persona che conosca il dominio ed una che sappia progettare la base dati.
>> 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.
Lasciamo perdere quel catorcione di PHP.
>
>> 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.
Eh, cipolle. Prima di arrivare al codice si deve capire cosa la programmazione
dovrà fare ed in che modo, qui ci vuole l'esperto di dominio con l'analista...
Non sarebbe male avere qualcuno che sappia quali sono i i limiti della tecnologia ed
anche quale interfaccia è in grado di accompagnare l'utente e non di ostacolarlo o
punirlo quando fa un errore.
>> 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.
Fare un programma con curses non è più facile che farlo con un toolkit grafico.
> 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.
Occhio al gestisce. La vera forza di un gestionale è quanto riesce a rendere i
dati utili all'azienda.
Ah, per la business intelligence di libero c'è Spago BI.
> Le eccezioni sono quegli ambienti che cercano di astrarre tutto (Java, Mono, Gambas per dirne tre) che vorrebbero essere multipiattaforma. Basta
> ignorarli. :)
O basta non essere pirlotti dietro ad una delle tante e usare i tool con intelligenza conoscendoli (veramente)
>> 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)
Ti voglio vedere a manutenerlo quando cambiano le regole...
--
Gian Uberto Lauri
Messaggio inviato da un tablet
Reply to: