Revisione 0.06

La creazione di gestioni e gestionali è un’attività difficile e con forti vincoli, per esempio dover utilizzare l’ambiente Microsoft per le App Desktop e la necessità di App Mobile e Web.

Non esiste un unico ambiente e framework per lo sviluppo di software che permetta di rendere al meglio ogni aspetto, ma si può introdurre il concetto di framework ibrido, ovvero un mosaico con ogni tassello realizzato medianteil framework più adatto.

Infatti la parte blog conviene sia realizzata, per esempio, in WordPress, l’area di accesso web riservata ai clienti, per esempio, in Yii2, le App Desktop MSWindows in Visual Studio od Embarcadero Dx Delphi.

Il Framework Ibrido si appoggia sui pilastri:

1. Sistemi Operativo Server
2. RDBMS di appoggio
3. Framework per Microsoft App Desktop
4. Framework Mobile e Web
5. Servizi lato Server
6. Framework Reports, Business Intelligence  o Business Object
7. Integrazione Contabilità / ERP / CRM / Groupware commerciali
8. Storage locale od accessibile da internet con servizi gestione file

L’esperienza porta ad utilizzare UNIX Linux Ubuntu Server LTS come Sistema Operativo  di appoggio per ogni servizio.

L’estrema robustezza, l’assenza di costo di acquisto, la possibilità di allineamento di versioni, l’assenza dei malware che sono praticamente solo per gli ambienti MS Windows, rende questo sistema operativo l’appoggio ideale per qualsiasi realizzazione.

Sul RDBMS la scelta più ovvia sarebbe Microsoft SQL Server. Ma si aprono questione di costi, di allineamento versioni, di difficoltà con i linguaggi embedded, di problemi di licenza, di difficoltà nel realizzare veri cluster RDBMS, di vincoli di dover soggiacere su Sistemi Operativi MS Windows Server, ed altro.

Il nodo centrale è costituito dal connettore al RDBMS, ovvero Microsoft ODBC.

Mysql, con la sua dominanza nel web, crea difficoltà proprio con il connettore MS ODBC.

PostgreSQL risulta imbattibile anche per l’ottimo connettore MS ODBC  PostgreSQL.

1. permette l’utilizzo in ampia scala di RDBMS e la normalizzazione alla stessa versione non avendo vincoli di licenza
2. abbatte i costi vivi
3. si appoggia in modo perfetto in ambiente UNIX Linux Ubuntu Server 64 LTS
4. ha una robustezza, anche network, impressionante
5. permette una vera clusterizzazione
6. ha opzioni di sicurezza estreme
7. è usabile in ambiti extranet in SSL puro
8. ha una velocità vistosa
9. ottimizza i backup nel rapporto costi benefici
10. la versione 10 introduce vistose novità

Ma ha delle ulteriori caratteristiche ineguagliabili:

1. ha vari linguaggi embedded, anche untrusted, che sono proprio esattamente quei linguaggi di fascia alta,  usati in genere per creare programmi ad uso amministrativo in ambito server
2. ha connettori MS ODBC 32 e 64 incredibilmente stabili e ben curati
3. ha opzioni di sicurezza ed utilizzo dal network confrontabili con Apache
4. permette il reale allestimento in server dedicato in internet
5. permette la realizzazione del miglior middleware, anche basato sulla tabella commands,  per accesso anche da internet
6. permette una scalabilità incredibile
7. regge a poll pesanti
8. indici full text search incredibili in termini di velocità e precisione
9. ottimi e realmente amichevoli programmi di amministrazione
10. è usato da i maggiori framework web ed altri servizi (Owncloud, Jaspereport, …)
11. e molto altro

Quindi è naturale scegliere PL Python 3 Untrusted come ambiente sviluppo embedded. In sostanza è la completa versione Linux Python 3, ovvero tra i migliori ambienti per lo sviluppo di servizi lato server, integrata nel server RDBMS.

Nello stile ERP Odoo, molto codice viene delegato, e quindi uniformato, a funzioni PL/PY3u.

Come esempio si può pensare alla costruzione di eventi realizzati mediante procedure su TRIGGER, per esempio, al SQL INSERT.

Sul Framework per la realizzazione di App Microsoft Desktop, non è stato scelto l’ottimo Embarcadero, ma il classico Microsoft Visual Studio, l’utlime versioni non .net, integrato dal framework C C++ Qt con MINGW.

DLL in C++ Qt permettono di eludere le restrizioni che Microsoft impone nell’uso dei processi e del winsock.

Così la gestione di processi esterni, anche detached, diventa precisa in un ambiente client difficile quale OS MS Windows.

Inoltre sono integrabili e direttamente utilizzabili librerie in C e C++ eccellenti, per esempio per gestire il winsock o XML o RE e molto altro.

E’ in corso il port di codice MS Windows 32 e 64 in ambito simulatore MS Windows per UNIX Linux e Virtual Machine Open Source e MSwin32 compatibile.

Il tutto ha portato alla costruzione di librerie per lo sviluppo di gestionali, con caratteristiche del codice che genera codice, di rapidissimo sviluppo MS App Desktop a partire dal database nel RDBMS.

Quindi se le tabelle dell’applicazione che si intende sviluppare sono dell’ordine del centinaio, le pagine della GUI da creare siano della decina e le griglie a centinaia, nel classico stile visuale di Visual Studio e con il Framework SQL, si produce la App Desktop, a partire dalle tabelle nel RDBMS e con le specifiche pronte, in pochi giorni.

Gli stili ampiamente utilizzati sono visuale e codice chje genera codice.

E’ corso la riscrittura della libreria realizzata in Visual Studio per il framework Qt, in un certo senso indipendente dal OS,  con le su form native descritte nel formato XML.

Le tabelle di appoggio locali, sqlite o dbf, sono conformi alle tabelle in RDBMS. Le funzioni nella libreria di base realizzano la bijezione tra dati e tipi locali e lato RDBMS. Le tabelle sqlite sono ampiamente diffuse e la libertà dai tipi può essere origine di qualche ambiguità. Il vecchio standard DBF brilla in robustezza, ma risente per una generale rigidità. Comunque la conversione in linea, dinamica, e la popolazione di centinaia di migliaia di righe dal server nelle tabelle locali è di una strabiliante velocità. L’idea utilizzata in ambito Visual Studio è di mappare il record in matrice sul quale agire con la trasformazione necessaria. Quindi aggiungerlo nel cursore locale oppure nel remoto.

Una caratteristica è data dalla personalizzazione estrema dei flussi di informazioni, anche per contesti massivi, ovvero importazioni ed esportazioni mediante fogli elettronici, prima nota verso Gamma, creazione di file PDF e collocazione in OwnCloud, ampia integrazione IoT,…

L’integrazione con documenti nel formato Microsoft Office o OpenDocument avviene mediante le API UNO Libreoffice.

Sono stati creati servizi in produzione, non interrotta, di conversione file DOC e DOCX in PDF o Text per la full text index. Oppure servizi da XLS o XLSX che producono per ogni riga un record nel RDBMS con relativa full text index.

La parte Mobile e Web UI viene delegata al framework web Yii2 con il framework CSS.

La reportistica e Business Intelligence all’ambiente JasperReport.

Storage locale in RDBMS è Samba.

Storage con Web UI è Owncloud.

La creazione e gestione di file Office a servizi che utilizzano API UNO di LibreOffice su UNIX.

L’integrazione IoT avviene mediante board Arm, quali Rpi, ed AVR, quali Arduino, in particolare:

1. gestioni seriali RS 232, RS 422, RS 485, MODBUS
2. gestione completa bus USB, in particolare con servizi di aggiornamento stato dispositivi verso RDBMS
3. intregrazioni mediante telnetd anche in tunnel SSH
4. LCD ed interruttori / pulsanti
5. attuatori
6. sensori
7. AVR firmware nello stile Arduino per servizio wrapper in Qt verso RDBMS

Enterprise Resource Planning (letteralmente “pianificazione delle risorse d’impresa”, spesso abbreviato in ERP) è un sistema di gestione, chiamato in informatica sistema informativo, che integra tutti i processi di business rilevanti di un’azienda (vendite, acquisti, gestione magazzino, contabilità etc.)

Con l’aumento della popolarità dell’ERP e la riduzione dei costi per l’ICT (Information and Communication Technology), si sono sviluppate applicazioni che aiutano i business manager ad implementare questa metodologia nelle attività di business come: controllo di inventari, tracciamento degli ordini, servizi per i clienti, finanza e risorse umane.

• Sviluppo di gestionali
• Ambiente Sviluppo Software per Gestionali

Revisione 0.6

Lo sviluppo di gestionali personali e non legati a mainframe, nasce negli anni ’80 e ci riportano al Cobol,  Basic e, poi, dBase.

Alla fine degli anni ottanta,  dBase e Clipper primeggiarono soprattutto in relazione all’enorme e meritato successo del sistema operativo Microsoft DOS ed alle tabelle DBF con l’eccellente meccanismo di indicizzazione.

All’inizio degli anni novanta ci fu l’enorme rivoluzione visuale sostanzialmente introdotta da Microsoft.

Microsoft e Borland forse furono i due veri e grandi giganti nell’innovazione visuale per lo sviluppo di software gestionale: finalmente chi si prendeva questi pesanti oneri aveva un debugger amichevole, dei widgets decorosi e la possibilità di avere una formidabile vista personale  d’insieme. I due prodotti che segnarono i tempi furono Microsft Visual Studio e Borland Delphi.

Ogni altro approccio, dagli oggetti all’ultima moda HTML5, crea enormi problemi per sviluppare gestionali legati al non rapido sviluppo, alla dispersione delle sorgenti, alla molto più difficile lettura, ai metodi di  debug complicati, alla difficoltà di personalizzare parti senza perdere il controllo dell’insieme.

Ancora oggi, a livello nazionale, la gran parte dei programmi di contabilità è prodotta con strumenti Microsoft Visual Studio, in particolare Visual Basic e Visual Fox Pro. Alcune aziende riescono a creare gestionali formidabili con l’erede del Borland Pascal ovvero  Delphi appartenente alla suite Embarcadero RAD Studio.

 

Con il nuovo millennio lo sviluppo in Java ha preso sempre più spazio, ma per grandi realtà, con collocazioni in diverse località e capaci ad investimenti economici di rilievo. Java è alla base delle produzioni di aziende quali IBM ed Oracle. Gli applicativi si caratterizzano per l’interfaccia utente piuttosto rigida e l’utilizzo in prevalenza del RDBMS Oracle.    Lo sviluppo comunque non è in generale personale e coinvolge un gruppo di lavoro che impone delle pratiche burocratiche talvolta onerose.

Lo sviluppo ad oggetti è obbligatorio per una libreria destinata ad ampia diffusione, ma non per lo sviluppo di gestionali che meglio beneficia del formidabile approccio visuale.

La tecnologia web è evoluta in modo formidabile, da essere alla base anche della generazione attuale delle app mobile, ma soffre, nell’ambito dei gestionali, delle forti restrizioni imposte dal browser web.

Il futuro dei gestionali si baserà molto su app mobile, ma le scelte attuali, alla base degli SDK più diffusi per app mobile, permettono solo utilizzi marginali.

Le app mobile comunque sono attualmente sbilanciate tra sviluppo C++, Java ed HTML5, un cocktail semplicemente sfavorevole allo sviluppo di gestionali.

Si consideri la possibilità di sviluppare in Java per Android. Il solo SDK  Java occupa oltre i 70 GB di spazio disco, la realizzazione di una app con qualche bottone a volte offre la percezione analoga al varo del Titanic. Situazione ben distante da poter sviluppare una gestione minimale che in genere facilmente coinvolge un centinaio di tabelle ed altrettante pagine con innumerevoli widgets di base e, soprattutto, la diretta interazione con il personale aziendale che considera solo i problemi legati alla loro attività e non all’informatica.

Mescolare script con sintassi e semantiche diverse, spingendosi fino a toccare l’impossibilità di eseguire il debug,  è necessario per fare  funzionare i browser web, che condensano un formidabile miscuglio di interpreti a volte forse neppure compatibili.

Per creare gestionali, soprattutto su misura, servono:

•  un ambiente semplice, con fortissima integrazione verso le tabelle sia locali che remote
• un approccio decisamente Visuale integrato ad
• un debugger ben oliato
• con una libreria di widget adeguata, per esempio con widget grid evoluto
• utilizzare un’ unica sintassi ed un’ unica semantica, escludendo banali eccezioni quali utilizzare l’utilizzo di SQL
• seguire uno stile di scrittura delle sorgenti quasi esclusivamente rivolto alla comprensione umana, meglio scrivere cento righe intellegibili umanamente che una riga Perl one-liners
• scrivere una procedura in una procedura e non disseminata in diversi file
• evitare trucchi ed espedienti, discendenti dei memorabili peek&poke, che poi portano a vere e proprie trappole, meglio scrivere codice vanilla
• il codice sorgente deve contenere commenti certosini, ma intellegibili,  da permettere di riprenderne la lettura senza esitazioni anche in tempi, modalità e situazioni diverse: contano la comprensione umana, il poter concentrarsi sul mondo reale e non su contorsioni di programmazione
• i commenti devono seguire sempre lo stesso stile
• deve esistere un file documento unico di riferimento al programma

Un raro modello di ambiente ottimale per lo sviluppo di gestionali da citare è Lazarus con freePascal, veramente ha tutto di quanto è stato succintamente elencato. Inoltre è opensource. Ma non ha consenso tra i programmatori e, forse, non ha raggiunto livelli di maturità tali da permettere lo sviluppo di applicazioni in ambito critico. Delphi, la versione commerciale, è senza ombra di dubbio forse il miglior strumento per lo sviluppo di gestionali, ma non ha propulsione. Anche in questo contesto valgono gli usuali elementi di propaganda.

Forse diventa ancora più ardito provare a sviluppare tale semplice gestione in Objective-C ed HTML5, scelte caratteristiche di Apple.

Lo sviluppo di gestionali in C++ in genere si sbilancia pesantemente verso gli oggetti,  affondando l’approccio visuale. Situazione che porta a perdere il controllo del codice sorgente sganciandolo dalle problematiche legate all’utilizzo concreto.

SAP, Systeme, Anwendungen, Produkte in der Datenverarbeitung, è forse il più mirabile esempio di  sviluppo in C++. Valgono le considerazioni fatte per lo sviluppo in Java, ma aggiungendo che comunque le asprezze sono smorzate dall’attingere ampiamente in materiali e metodi  Microsoft Visual Studio.

Qt forse apre uno spiraglio promettente, ma l’evoluzione è molto lenta: il debugger funziona ed è pratico; l’integrazione in un sistema operativo Ubuntu Linux con Ubuntu SDK è ancora fragile per lo sviluppo di gestionali; le librerie talvolta assorbono l’intera attenzione compromettendo quella visione d’insieme che garantisce il felice connubio tra codice prodotto e questioni concrete ben risolte. Il programmatore deve poter essere quasi completamente assorbito dall’astrazione dei problemi concreti e non da quelli dell’ambiente di sviluppo.

QML forse sarà lo strumento che permetterà di realizzare gestionali nella veste di app mobile.

La realizzazione di gestionali è strettamente legata ad un RDBMS, in particolare i due più diffusi sono Oracle e Microsoft SQL. In ambito web primeggia Mysql.

Postgresql è il riferimento assoluto in ambito Open Source per applicazioni enterprise.

Introduciamo un progetto molto ambizioso.

Premettiamo alcune ovvie considerazioni: le aziende italiane sono in sofferenza, hanno problemi di tutti i tipi, ma in particolare la loro gestione interna e l’integrazione con la burocrazia è praticamente drammatica, per esempio la fattura elettronica, formidabile semplificazione, rimane un miraggio.

Conoscenze e competenze nella gestione automatica dell’azienda rimangono dei tabù riservata a pochi specialisti che spesso sembrano esercitare riti magici.

La pratica della contabilità industriale è qualche cosa di magico.

Ritengo che lo Stato mediante le sue Università dovrebbero aiutare per esempio creando degli strumenti concreti per semplificare. Un processo virtuso in questo senso aprirebbe formidabili spiragli a giovani con talento e studio, creando una catena di bisogni costruttivi.

Questo sogno, come molti altri, è possibile, ricorrendo a sistemi operativi come Linux, RDBMS come PostgreSQL, ambienti di sviluppo innovativi ed anche opensource come Qt QML, competenze disseminate nel pianeta universitario che non sono mai finalizzare a produrre qualche cosa di vero, grande ed utile per il mondo di tutti le aziende italiane.

L’informazione automatica secondo la burocrazia istituzionale non è qualche cosa di pratico ed utile, ma contorto e non comprensibile. Invece di far buon software si costruiscono inutili grovigli di regole e condizioni.

Il progetto ERP Italia potrbbe avere come confronti ambienti come il tedesco SAP, oppure gli statunitensi NAV o JD Edwards.

Si potrà obiettare che è un sogno non realizzabile, si risponda di non sottovalutare l’ingegno italiano.