Re: [OT] Una ferale notizia?
Il 23 agosto 2014 21:50, Gian Uberto Lauri <saint@eng.it> 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)
+1
>
> Oppure in certe situazioni meglio un non SQL.
+1
>
> Comunque ci vuole una persona che conosca il dominio ed una che sappia progettare la base dati.
>
questa è una cosa che mi avevano insegnato durante i corsi
universitari di informatica (non ingegneria del software, tutta
un'altra cosa)...
quando vuoi realizzare una nuova modalità di lavoro informatizzando un
lavoro che già esiste, devi prima di tutto passare alcuni mesi (nota
bene, mesi, non giorni) seduto affianco alle persone che il lavoro già
lo fanno, capire ogni minima parte del loro lavoro, cominciando a
limare e riorganizzare il loro lavoro nel modo standard in cui già lo
fanno...
solo quando arrivi a suddividere in singole azioni atomiche tutto il
workflow, puoi permetterti di cominciare ad informatizzare alcune
parti... le più remote tipicamente... e solo quando queste sono
definitivamente collaudate fai un passo ulteriore...
quindi dire che si deve passare all'open source tutto di un botto...
forse è un tirarsi la zappa sui piedi...
comincia a migrare alcuni server, i meno importanti per iniziare...
magari pure basandoti su sistemi virtualizzati...
poi passi alla gestione delle basi di dati, con una base di dati
offline che venga continuamente sincronizzata con il vecchio sistema,
in modo da permetterti lo sviluppo di un'interfaccia web che ti
permetta di gestire le basi di dati originali trasferite... (e qui sta
la gran parte della sfida)...
insomma... è un percorso lungo, che non può essere fatto dall'oggi al domani...
e non siamo ancora arrivati a toccare i singoli utenti utilizzatori
del sistema... loro sono l'ultimo passo del cambiamento...
> Lasciamo perdere quel catorcione di PHP.
+1
>
>>
>>> 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...
appunto... ci vogliono mesi di analisi... e analisi approffondita..
non superficiale, altrimenti ti trovi con il culo per terra... e non
devi fare un qualcosa che poi non possa essere ampliata...
>
> 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.
>
questo vuol dire anche spese di addestramento di personale che poi
deve accompagnare gli utenti all'uso del nuovo sistema... non è come
dirlo... sono spese non indifferenti.
>>> 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.
>
sei già al programma... troppo rigido...
>> 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.
>
ce ne sono tanti di programmi, se solo si avesse la voglia di
impararli ed esplirarli...
>> 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)
>
appunto... conoscenza degli strumenti prima di tutto... prima ancora
di iniziare...
>>> 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...
ecco l'errore... in poche settimane non si fa nulla... ma proprio nulla...
Byez
Gollum1 - http://www.gollumone.it
Tesssssoro, dov'é il mio tessssoro...
Reply to: