[Python] Codemotion a Venezia

Marco De Paoli depaolim a gmail.com
Mer 5 Set 2012 14:07:11 CEST


Il giorno 04 settembre 2012 11:53, Simone Federici
<s.federici a gmail.com>ha scritto:

> direi che se vuoi parlare di django, la cosa sarà molto gradita
> fammi sapere se vuoi una mano per l'abstract
>

verifico in azienda se si può parlare di argomenti che sono legati a
business interno

mi piacerebbe fare non tanto una presentazione super tecnica quanto
piuttosto un caso d'uso in cui django (e python) hanno decisamente
semplificato la vita ad un intero gruppo di persone con conseguente
tempestività con il cliente finale, etc etc.
... con gran gioia di lean-manager e compagnia cantante

Chiarisco che il mio ruolo in azienda non è quello di fare sw per il
cliente finale bensì per db aziendali e/o a supporto dei workflow interni
di r&d e produzione

In un progetto recente in particolare, visto la rapidità di sviluppo con
django, si è potuto fare un prototipo funzionante in giorni

Il bello è che poi il prototipo è stato usato per generare i primi dati da
condividere con il cliente. Quindi è stato usato, praticamente, in
produzione.

Il bello è che rispetto ad altri prodotti da ufficio (Access!) c'è comunque
l'enorme vantaggio che gli utenti non si trovano a scambiare file (orrendi
mdb!) ma si può partire da subito a lavorare su un db condiviso via http
(Visto che poi con l'admin di django si riesce a dargli un editing decente
con poche righe di codice, grande!)

Allo stato attuale ci mi trovo che il prototipo andrà completato in modo da
centralizzare una serie di procedure semi-automatiche con micro-tool vari

Il problema è che il prototipo andrà buttato via

E' risultato che il workflow usato in questa fase iniziale non è adeguato
al ciclo di lavoro "vero" che si dovrà adottare a regime.

Come dire che un po' per l'emergenza e un po' per recuperare lo storico si
è seguito un modo di lavorare che ha solo in piccola parte a che fare con
il flusso di lavoro che si seguirà a regime per la produzione futura.

Niente paura! Butto via il prototipo e rifaccio il sistema da zero usando
tutto il know-how accumulato ed eventuali procedurine critiche che sono
state messe a punto in questa prima fase

... ma non si sarebbe potuto fare bene le cose da subito e definire
correttament eil workflow già dall'inizio?!?
No!! Sappiamo benissimo che quando si comincia a lavorare sul prototipo
1) non sono ancora chiusi gli accordi commerciali con il cliente finale
2) in azienda non è ancora chiaro nei dettagli cosa e come bisognerà prdurre
3) agli utenti se parli di un ciclo futuro senza avere davanti dati
concreti, si perdono. O meglio li perdi dopo 5 minuti perché non riescono
ancora a concepire un sistema che in effetti dovrebbe essere a supporto di
un modo di lavorare che ancora non è chiaro neppure a loro

Per tutti questi motivi quello che abbiamo fatto è stato iniziare a buttare
su tabelle recuperando dati da vari excel, xml, mdb, etc. e dargli un posto
centralizzato in cui tutti potessero editare (grande django-admin! con 3
righe gli dai un editing più che decente)

In questa fase è necessario un po' turarsi il naso perché si ha a che fare
con tabelle de-normalizzate e inconsistenze varie
Però:
1) si ha un prototipo funzionante che serve per la pre-produzione che
dicevo prima
2) gli utenti hanno capito cosa gli serve e come lo devono fare
3) io ho capito che dati vanno salvati e quali sono le funzioni base del
sistema

a quel punto si inizia a sviluppare il sistema vero con le tabelle fatte
come si deve e e con tutte le regole di consistenza corrette sui dati

Ok, mi sono dilungato un po'... spero di non essere troppo OT

Vi dico l'ultima, che fa un po' sorridere: ho fatto il "prototipo del
prototipo".
In pratica mentre lavoravo al prototipo "ufficiale" ossia quello che usano
i miei utenti, mi sono creato un altra app django con l'abbozzo di quello
che capivo essere il funzionamento reale futuro ("a regime" come dicevo
prima).
La nuova app è dentro lo stesso progetto per cui posso portare avanti gli
sviluppi dell'uno o dell'altro facendo convivere il tutto nello stesso repo
mercurial/svn/trac [1] e sulle stesse directory/host (di sviluppo e di test)

Scusare la lunghezza, ciao
Marco

[1] ...il motivo per cui ci sono sia mercurial che svn potrebbe essere
oggetto di un altra storia :)
-------------- parte successiva --------------
Un allegato HTML è stato rimosso...
URL: <http://lists.python.it/pipermail/python/attachments/20120905/d53b4db9/attachment.html>


Maggiori informazioni sulla lista Python