On 01/22/2010 01:37 AM, Enrico 'Henryx' Bianchi wrote:
Sul non usare SqlLite ti diro', visto che lavoro preferenzialmente con
SqqlAlchemy, mi va benissimo di usarlo per lo sviluppo, tanto poi in
produzione si cambia una riga (in un file di definizione) e ci pensa l'ORM
a fare il lavoro.
A volte comunque mi capita di far girare i test su
postgresql e fare il deployment su SQL Server. Anche lì l'applicazione
va testata funzionalmente su SQL Server prima di metterla in staging
ovviamente, ma il compromesso funziona, soprattutto mentre stai
scrivendo codice.
Ma gli ORM non
2010/1/22 Giorgio Zoppi giorgio.zo...@gmail.com:
Ma gli ORM non garantiscono uno strato di indipendenza dal software
sottostante a patto di usare
un certo set di feature?
Si, ma puoi comunque customizzare se hai bisogno. Certo e` che se hai
una architettura che usa
tutte le feature piu`
On 01/22/2010 10:44 AM, Giorgio Zoppi wrote:
Ma gli ORM non garantiscono uno strato di indipendenza dal software
sottostante a patto di usare
un certo set di feature?
Oh, si', garantiscono un sacco di cose.
http://blogs.tedneward.com/2006/06/26/The+Vietnam+Of+Computer+Science.aspx
A dir
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Lawrence Oluyede ha scritto:
2010/1/22 Enrico 'Henryx' Bianchi henry...@yahoo.it:
Di conseguenza, lo sviluppo di una base di dati,
indipendentemente dagli strumenti intermediari (e.g. sqlalchemy) va
implementata direttamente sul motore di database
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marco Mariani ha scritto:
On 01/22/2010 10:44 AM, Giorgio Zoppi wrote:
Ma gli ORM non garantiscono uno strato di indipendenza dal software
sottostante a patto di usare
un certo set di feature?
Oh, si', garantiscono un sacco di cose.
On 01/22/2010 12:21 PM, Manlio Perillo wrote:
In un progetto, anni fa (si era alla versione 0.3.x) ho usato l'ORM di
SQLAlchemy in una applicazione web, ed è stato un bagno di sangue.
L'ORM in compenso, ti salva la vita per quei report che si lanciano una
volta ogni 2 settimane e raccolgono
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Marco Mariani ha scritto:
On 01/22/2010 12:21 PM, Manlio Perillo wrote:
In un progetto, anni fa (si era alla versione 0.3.x) ho usato l'ORM di
SQLAlchemy in una applicazione web, ed è stato un bagno di sangue.
L'ORM in compenso, ti salva la
On 01/20/2010 09:41 PM, Massimo Di Stefano wrote:
se la velocità / performance non sono un'aspetto limititante,
io vedrei di buon occhio l'adozione di sqlite.
Vero che MySql è più veloce di sqlite (... a mysql preferirei postgresql),
preferirei postgres e' un understatement, immagino.
Mysql
On 01/21/2010 10:27 AM, Marco Mariani wrote:
E la prossima volta che saltano fuori dei casini con il contenuto di un
database _solo nel momento in cui si migra da mysql a postgres_ provate
a chiedervi perche'.
Mariani's First Law Of Shit:
If a database can contain shit, it will.
--
This
On Thu, Jan 21, 2010 at 10:27 AM, Marco Mariani
marco.mari...@prometeia.itwrote:
On 01/20/2010 09:41 PM, Massimo Di Stefano wrote:
se la velocità / performance non sono un'aspetto limititante,
io vedrei di buon occhio l'adozione di sqlite.
Vero che MySql è più veloce di sqlite (... a
On Jan 21, 2010, at 11:23 AM, Marco Beri wrote:
Ma Postgresql vs MySql non è una guerra di religione: è una guerra di
liberazione.
LOL! +1___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
* giovedì 21 gennaio 2010, alle 11:32, Enrico Franchi scrive:
Ma Postgresql vs MySql non è una guerra di religione: è una guerra di
liberazione.
LOL! +1
+1
PostgreSQL tutta la vita :)
--
| Francesco Benincasa - http://ciccio2000.altervista.org/
| EcoSCIENZE Societa' Cooperativa -
On Wednesday 20 January 2010 09:51:36 Giorgio Zoppi wrote:
Ci sei. Nel progetto posso aggiungere solo account gmail.com
Non metto in dubbio le tue parole, pero` visualizzando la pagina
http://code.google.com/p/medica2/people/list non vedo alcun utente a mio nome
(senza considerare il fatto
On Wednesday 20 January 2010 21:41:00 Massimo Di Stefano wrote:
Vero che MySql è più veloce di sqlite (... a mysql preferirei postgresql),
Da test che ho effettuato, MySQL e` piu` *lento* di SQLite (che, a sua volta,
e` piu` lento di PostgreSQL e di Firebird). Verificando il plan table di una
dammi il tuo account gmail.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
On Wednesday 20 January 2010 21:48:16 Carlos Catucci wrote:
Sul non usare SqlLite ti diro', visto che lavoro preferenzialmente con
SqqlAlchemy, mi va benissimo di usarlo per lo sviluppo, tanto poi in
produzione si cambia una riga (in un file di definizione) e ci pensa l'ORM
a fare il
2010/1/22 Enrico 'Henryx' Bianchi henry...@yahoo.it:
Di conseguenza, lo sviluppo di una base di dati,
indipendentemente dagli strumenti intermediari (e.g. sqlalchemy) va
implementata direttamente sul motore di database che si sta prendendo in
considerazione
Su questo sono d'accordo anche io.
Argomentazioni tecniche:
Personalmente, nonostante li eviti per mia natura, sono d'accordo
nell'usare
un ORM per la gestione delle query su database, in quanto permette di
astrarre
[snip]
nell'esecuzione di query di aggregazione dati SQLite risulta piu` lento di
Firebird in modalita`
2010/1/20 Carlos Catucci carlos.catu...@gmail.com:
Di mio uso Bazaar che trovo migliore anche di Mercurial, ma poi si sa il
sistema di versioning e' come la pizza, a ognuno il suo gusto
Curiosita`, com'e` a velocita` ora? Uno dei motivi per cui non ho mai
considerato Bzr e` che era lento come
Curiosita`, com'e` a velocita` ora? Uno dei motivi per cui non ho mai
considerato Bzr e` che era lento come la morte.
Io sto diventando un fan di Git ma credo che in ufficio forse
passeremo a Mercurial, prima o poi :-)
Io problemi non ne ho. Il fatto poi di avere i repo locali
2010/1/20 Carlos Catucci carlos.catu...@gmail.com:
Io problemi non ne ho. Il fatto poi di avere i repo locali (sincronizzabili)
e' per me il must. Git lo trovo troppo complesso e mancante dei repo locali.
Mercurial piu' complesso di Bazaar. Pero' ripeto, sono gusti. Tanto tra loro
(e con
* mercoledì 20 gennaio 2010, alle 14:27, Lawrence Oluyede scrive:
Per la questione feature: http://whygitisbetterthanx.com/
Io a suo tempo vidi questa:
http://versioncontrolblog.com/comparison/Bazaar/CVS/Git/Mercurial/Subversion/index.html
La discussione mi interessa molto perche' vorrei
Senza voler scatenare guerre di religione, ed anche essendo un pelo OT :-)
Nessuna guerra di religione. Io ho solo espresso il mio parere, asu o tempo
ho fatto uno studio sui tre prodotti ed ho scelto quello piu' idoneo alle
mie esigenze ( lavori di gruppo, spesso un membro del gruppo si puo'
Il giorno mer, 20/01/2010 alle 15.13 +0100, Carlos Catucci ha scritto:
Senza voler scatenare guerre di religione, ed anche essendo un
pelo OT :-)
Nessuna guerra di religione. Io ho solo espresso il mio parere, asu o
tempo ho fatto uno studio sui tre prodotti ed ho
Comunque, a parte la velocità, la cosa che mi ha fatto lasciare bazaar -
e mi incuriosisce sapere se è ancora così - è stata l'impossibilità di
tenere più branch in uno stesso repository, cosa che io trovo
estremamente comoda (se poi uno ci aggiunge la possibilità di avere un
colpo d'occhio
On 1/20/10 2:16 PM, Carlos Catucci carlos.catu...@gmail.com wrote:
MySql mi sembra una scelta altrettanto (se non di piu') valida.
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
___
Python mailing list
MySql mi sembra una scelta altrettanto (se non di piu') valida.
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Ecco il problema di noi informatici. Ognuno ha il suo punto di vista. Quindi
o un progetto nasce con un owner (che so un benevolo
se la velocità / performance non sono un'aspetto limititante,
io vedrei di buon occhio l'adozione di sqlite.
Vero che MySql è più veloce di sqlite (... a mysql preferirei postgresql),
ma è anche vero che sqlite è molto più portabile di un vero e proprio db
relazionale.
con sqlite non c'è
Enrico Franchi wrote:
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Ne ho visti che scambiano sinistra e destra, ma prima e dopo mai.
--
Nicola Larosa - http://www.tekNico.net/
The individual is not like his government. He cannot, for example,
On 1/20/10 9:56 PM, Nicola Larosa n...@teknico.net wrote:
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Ne ho visti che scambiano sinistra e destra, ma prima e dopo mai.
Nel senso che implementarsi il db a mano viene prima di usare MySQL?
Enrico Franchi wrote:
Dal mio punto di vista MySQL è l'ultima scelta.
Appena prima di implementare tutto a mano.
Nicola Larosa wrote:
Ne ho visti che scambiano sinistra e destra, ma prima e dopo mai.
Enrico Franchi wrote:
Nel senso che implementarsi il db a mano viene prima di usare MySQL?
On Thursday 14 January 2010 23:28:26 Giorgio Zoppi wrote:
Io il mio sassolino l'ho buttato...
Rispondo qua in quanto non vedo ancora il mio account tra quelli aggiunti al
progetto...
Argomentazioni tecniche:
Personalmente, nonostante li eviti per mia natura, sono d'accordo nell'usare
un ORM
On 1/20/10 2:11 AM, Enrico 'Henryx' Bianchi henry...@yahoo.it wrote:
Infine, sarebbe piu` interessante
evitare la GPL rispetto ad un'altra licenza, ma considerando che si vuole
usare Qt per la GUI, e` inutile discuterne (PyQT e` sotto GPL mentre Pyside e`
ancora in alto mare)
Io credo che
Allora per chi si volesse aggiungere al progetto mi contatti in
privato. La mia idea era di non
usare un ERP, gia fatto
Concordo
e possibilmente di usare PyQt, perche cosi si
fa prima. Il Designer di Qt migliora di
versione in versione avvicinandosi sempre piu al designer ottimo di
Ciao a tutti,
mi reintrometto un attimo perche' anche io sono interessato a partecipare.
Siccome la fase di analisi e design e' la piu' importante, la cosa migliore e'
cercare delle soluzioni condivise dai partecipanti e soffermarsi sulle
discussioni riguardanti le scelte architetturali e
Siccome la fase di analisi e design e' la piu' importante, la cosa migliore
e'
cercare delle soluzioni condivise dai partecipanti e soffermarsi sulle
discussioni riguardanti le scelte architetturali e tecnologiche anche
settimane
prima di mettersi a sviluppare.
Concordo, una analisi
Il giorno 18/gen/2010, alle ore 10.52, Francesco Benincasa ha scritto:
Ciao a tutti,
mi reintrometto un attimo perche' anche io sono interessato a partecipare.
Siccome la fase di analisi e design e' la piu' importante, la cosa migliore e'
cercare delle soluzioni condivise dai partecipanti
Non voglio dire che ciò sia un male in assoluto ma non so quanto sia
utile e se è di interesse per la maggioranza degli iscritti alla lista.
Magari un forum? IRC mi sembra limitante dato che richiede la presenza
contemporanea di tutti
Carlos
___
Carlos Catucci wrote:
Le filosofie come quella da te proposta somigliano molto a OpenERP.
Solo che richiederebbe un server (non web) e due client. Ovvero doppio
lavoro per avere lo stesso prodotto.
No, questo è fattualmente errato, nel caso di OpenERP.
Come dicevo, il client è stupido: non
Questo comporta che i client sono *già fatti*, sia quello desktop che
quello web, pronti e uguali per tutte le applicazioni.
Si scrivono solo file Python per la business logic, e file XML per
l'interfaccia utente. Tutti questi file risiedono sul server, e vengono
riusati allo stesso modo da
Carlos Catucci spiffera, alle Monday 18 January 2010 circa:
Ok ho poccato di poco dettaglio. Quello che volevo dire era che la
filosofia avere un server per il C/S e uno per il web server, due
diversi client che fanno le stesse cose. Ridondanza. Ah OE usa
TurboGears per la parte web (non
Il giorno lun, 18/01/2010 alle 11.26 +0100, Carlos Catucci ha scritto:
Ok ho poccato di poco dettaglio. Quello che volevo dire era che la
filosofia avere un server per il C/S e uno per il web server, due
diversi client che fanno le stesse cose. Ridondanza. Ah OE usa
TurboGears per la parte
In realtà no, è stato soppresso.
Il client web ora è stato enormemente semplificato. si tratta di un
pugno di template Mako che girano sotto Cherrypy e che non fanno altro
che disegnare le videate web in base all'XML ritornato dal server
OpenObject.
Questo passaggio mi e' mancato; non che
On 1/18/10 12:12 PM, Carlos Catucci carlos.catu...@gmail.com wrote:
Questo passaggio mi e' mancato; non che la cosa rivesta piu' interesse (se non
ho degli analisti funzionali io a lavorare sui gestionali ERP o simili non mi
ci metto. I verticalizzati come il progetto in esame, con un
Enrico Franchi wrote:
Ora io dico chiaramente che non credo avrei il tempo di lavorarci (e
sicuramente non la voglia).
Un po' di voglia l'avrei, ma il tempo neanch'io. Devo... resistere...
argh! :-)
Avete il sogno di qualunque team agile: avete un membro del team che
e' praticamente anche
OpenERP e' una soluzione di altissima qualita' e maturita'. IMHO fate
fatica
in breve tempo a mettere in piedi una struttura analogamente ben fatta.
Quanti conoscono OpenERP? Nel team intendo. Io ci ho dato uno sguardo
superficiale ma non lo conosco. Nel tempo che mi serve ad apprenderlo da
Il giorno lun, 18/01/2010 alle 13.11 +0100, Carlos Catucci ha scritto:
Quanti conoscono OpenERP? Nel team intendo. Io ci ho dato uno sguardo
superficiale ma non lo conosco. Nel tempo che mi serve ad apprenderlo
da zero scrivo tre volte l'applicazione verticalizzata con un
framework MVC.
Io lo conosco direi abbastanza bene.
Uso OpenObject ed OpenERP da più di un anno ed ho già implementato
diversi progetti, anche non correlati al mondo ERP in senso stretto.
Ovviamente tutta la nostra disponibilità se decidete di utilizzare
OpenObject/OpenERP come base di sviluppo.
In tal
Nicola Larosa wrote:
Un po' di voglia l'avrei, ma il tempo neanch'io. Devo... resistere...
argh! :-)
Enrico Franchi wrote:
Dai che hai un sacco di tastiera da suonare ;)
Nah, faccio (finta di fare) il chitarrista, ora. ;-)
--
Nicola Larosa - http://www.tekNico.net/
Restricted academic
Il giorno dom, 17/01/2010 alle 23.42 +0100, Enrico Franchi ha scritto:
On 1/17/10 10:30 PM, Pietro Battiston too...@email.it wrote:
No, dai, mobileme è carino (non lo conoscevo, ma UbuntuOne punta
sostanzialmente a proporre - quando ci arriverà - lo stesso modello)...
ma mi sembra chiaro
Vi seguo attivamente, e grazie per la vostra carica! :-)
Caro Mauro, sei tu che ci dai uno spunto interessante.
Possiamo lavorare ad un progetto open source utile alla collettivita',
fornendo ai medici uno strumento importante. Come nel Pyhton, che sposta
l'attenzione dello sviluppatore dal
Il giorno lun, 18/01/2010 alle 15.36 +0100, Carlos Catucci ha scritto:
Tra parentesi non ho capito bene se il tuo prodotto prevedesse
collegamenti tra diversi client (per scambiare come dicevo cartelle
cliniche prive di dati identificativi del paziente) ne se, qualora non
lo faccia gia', se
Il giorno lun, 18/01/2010 alle 23.49 +0100, mauro ha scritto:
..purtroppo non ho in mente un esempio di applicativo web, o forse ce
l'ho sotto il naso tutti i giorni quando navigo con Firefox, e non me ne
rendo conto.
Di fatto un'applicazione web è un programma che invece di comparire in
una
Il giorno dom, 17/01/2010 alle 00.57 +0100, Enrico Franchi ha scritto:
On 1/16/10 8:11 PM, Pietro Battiston too...@email.it wrote:
_Anche_. E sono ovviamente studi più _limitati_, anche se verosimilmente
molto _approfonditi_. Non sono gli studi a cui chiederei se il web è una
buona
On 1/17/10 10:37 AM, Pietro Battiston too...@email.it wrote:
No, l'hai detto tu che sono più limitati, dato che sono solo sul web.
Io veramente parlavo di *contesto*.
bisogno, essenziale ecc... sono parole che non ho mai utilizzato.
Volevo arrivare esattamente dove sono arrivato.
Cioe' da
La mia personalissima impressione è che Microsoft sia il migliore
esempio di azienda che spesso e volentieri non fa quello che gli utenti
vogliono, ma sopravvive grazie alla conformazione molto particolare del
mercato, e spesso riesce anzi a convincere a posteriori gli utenti che
volevano
Il giorno dom, 17/01/2010 alle 11.00 +0100, Enrico Franchi ha scritto:
On 1/17/10 10:37 AM, Pietro Battiston too...@email.it wrote:
Ovvero un ostacolo causato dall'uso del web viene quasi a scomparire...
In realtà qualche esempio migliore esiste - tipo il drag-n-drop di
immagini in
On 1/17/10 11:35 AM, Pietro Battiston too...@email.it wrote:
Mi sembra che stessimo parlando in modo abbastanza generale. Perlomeno,
era generale la mia osservazione iniziale a Lawrence, ed era generale
parte della risposta di Giovanni. Ed il problema, ammesso che sia un
problema ovviamente,
Il giorno dom, 17/01/2010 alle 12.16 +0100, Enrico Franchi ha scritto:
On 1/17/10 11:35 AM, Pietro Battiston too...@email.it wrote:
Mi sembra che stessimo parlando in modo abbastanza generale. Perlomeno,
era generale la mia osservazione iniziale a Lawrence, ed era generale
parte della
On Saturday 16 January 2010 11:04:39 Enrico Franchi wrote:
Per il resto, e' una chiavica galattica (mail intendo). Gmail
e' molto piu' comodo sotto tutti i punti di vista
Curiosita`: in cosa fa cagare Mail mentre Gmail e` piu` comodo? Personalmente
ho avuto la percezione differente, ovvero
On 1/17/10 12:43 PM, Pietro Battiston too...@email.it wrote:
La migrazione almeno parziale dalla macchina ad internet avverrà, non lo
discuto minimamente. Io auspico caldamente che non avvenga tramite un
medium che Berners-Lee ha inventato per la condivisione di informazioni,
*in
On 1/17/10 4:01 PM, Enrico 'Henryx' Bianchi henry...@yahoo.it wrote:
Curiosita`: in cosa fa cagare Mail mentre Gmail e` piu` comodo? Personalmente
ho avuto la percezione differente, ovvero preferisco un client email
(Icedove/Thunderbird o KMail nel mio caso) piuttosto che Gmail, in quanto
Il giorno dom, 17/01/2010 alle 16.23 +0100, Enrico Franchi ha scritto:
On 1/17/10 12:43 PM, Pietro Battiston too...@email.it wrote:
Io vorrei loggarmi tra dieci anni nel computer del albergo, mettere una
password (sostituire con forma di autenticazione arbitrariamente
futuristica) e
Davide Corio wrote:
Mi aggancio al thread da qui, siccome è già troppo lungo per leggerlo
proprio tutto :)
Faccio parte del team di sviluppo di OpenObject
(http://www.openobject.com)
Ciao Davide, magari dai solo un occhio a
http://lists.python.it/pipermail/python/2010-January/007758.html
Il giorno sab, 16/01/2010 alle 08.16 +0100, Pietro Battiston ha scritto:
Il giorno sab, 16/01/2010 alle 04.03 +0100, Lawrence Oluyede ha scritto:
2010/1/15 Pietro Battiston too...@email.it:
Mi può convincere che il mio prossimo
servizio web potrà assomigliare ad una applicazione vera,
Il giorno sab, 16/01/2010 alle 09.39 +0100, Nicola Larosa ha scritto:
Ciao Davide, magari dai solo un occhio a
http://lists.python.it/pipermail/python/2010-January/007758.html
http://lists.python.it/pipermail/python/2010-January/007774.html
;-)
Ciao Nicola!
Eh beh, con un cicerone del
On 1/16/10 4:03 AM, Lawrence Oluyede l.oluy...@gmail.com wrote:
Pensavo che la contrapposizione vera applicazione - servizio web
fosse morta negli anni 90 :-)
I veri programmatori programmano tutt'ora direttamente in esadecimale,
Mica come quei fighetti del C.
2010/1/16 Pietro Battiston too...@email.it:
Vabbé, chiedo scusa se il mio utilizzo della parola applicazione è
impreciso, ma mi sembra chiaro il concetto: ci sono servizi che sono
intrinsecamente fatti per stare sul web, ed altri no: penso che i
secondi di solito ci perdano ad essere
Cerco di limitare le risposte alle parti dove vedo un barlume di
costruttività.
Il giorno sab, 16/01/2010 alle 11.04 +0100, Enrico Franchi ha scritto:
On 1/16/10 7:35 AM, Pietro Battiston too...@email.it wrote:
A occhio, il caso tipico è di utenti che _sanno_ cliccare su un
installer e poi
Il giorno sab, 16/01/2010 alle 11.15 +0100, Lawrence Oluyede ha scritto:
2010/1/16 Pietro Battiston too...@email.it:
Vabbé, chiedo scusa se il mio utilizzo della parola applicazione è
impreciso, ma mi sembra chiaro il concetto: ci sono servizi che sono
intrinsecamente fatti per stare sul
2010/1/16 Pietro Battiston too...@email.it:
A me sembra che i nuovi paradigmi abbiano semmai al centro lo
sviluppatore, quando va bene, e quando va male solo un modello
commerciale su misura per pochi grandi attori del panorama informatico.
Ne sei davvero sicuro? Ci sono fior fior di tomi
Il giorno sab, 16/01/2010 alle 13.13 +0100, Lawrence Oluyede ha scritto:
2010/1/16 Pietro Battiston too...@email.it:
A me sembra che i nuovi paradigmi abbiano semmai al centro lo
sviluppatore, quando va bene, e quando va male solo un modello
commerciale su misura per pochi grandi attori del
2010/1/16 Pietro Battiston too...@email.it:
Ma ho capito che abbiamo fondamentalmente gusti molto diversi, e forse
non molti elementi certi su quali gusti siano più diffusi tra i medici e
non informatici in generale.
Direi che è la chiave di volta, possiamo discutere quanto ci pare ma
senza
Il giorno 16/gen/2010, alle ore 11.04, Enrico Franchi ha scritto:
Se poi provassi mobile me, vedresti un'interfaccia web ricca tanto quanto
quella dell'OS. E a volte trovo un'esagerazione questo scimmiottamento, ma
tant'e.
Eh beh c'è anche roba come:
http://280slides.com/Editor/
On 1/16/10 12:17 PM, Pietro Battiston too...@email.it wrote:
Cerco di limitare le risposte alle parti dove vedo un barlume di
costruttività.
Mi chiedo chi tu ti creda di essere per andare cianciando di barlumi di
costruttivita' qua e la. Comunque, sorvoliamo pure sui tuoi modi arroganti.
Il giorno sab, 16/01/2010 alle 18.57 +0100, Enrico Franchi ha scritto:
On 1/16/10 12:17 PM, Pietro Battiston too...@email.it wrote:
Gente ben più esperta di me (e forse di te, non so) si è sbattuta per
anni sullo studio di interfacce, non sono io la persona, né questo è il
luogo giusto, per
Il giorno 16/gen/2010, alle ore 20.11, Pietro Battiston ha scritto:
Le sollevazioni popolari contro le applicazioni web non si sono viste. Non
mi sembra che i clienti di Giovanni, per esempio, siano particolarmente
scontenti. Mi auguro per lui che siano anzi particolarmente contenti e non
ho
Dubito che il mio dottore abbia internet in ufficio.
Un framework come TurboGears2 (non a caso Python) ha il suo WbeServer da
avviare come servizio. Ergo possiamo dare l'applicazione che si installa e
gira senza richiedere Internet, dato che il web server sarebbe sullo stesso
portatile.
Vorrei arricchire il discorso con delle considerazioni di carattere
economico. Quando si parla di realizzare gestionali da 'vendere'
[Snip]
Scrivere buoni gestionali non è saper programmare e basta.
Scrivere gestionali significa capire le necessità di chi
hai davanti, prospettare le
On 1/16/10 8:11 PM, Pietro Battiston too...@email.it wrote:
_Anche_. E sono ovviamente studi più _limitati_, anche se verosimilmente
molto _approfonditi_. Non sono gli studi a cui chiederei se il web è una
buona tecnologia per le interfacce _rispetto alle altre_.
Hai piu' volte detto di non
sqlkit funziona bene anche su Win?
Il 14 gennaio 2010 23.55, Alessandro Dentella san...@e-den.it ha scritto:
On Thu, Jan 14, 2010 at 11:28:26PM +0100, Giorgio Zoppi wrote:
Ripeto se siamo in 4 o 5 e ci organizziamo in un paio di mesi si tira
su qualcosa di decente da presentare a colleghi di
Giorgio Zoppi wrote:
Io il mio sassolino l'ho buttato...
Alessandro Dentella wrote:
Posso suggerire a chi se ne vuole occupare di dare una occhiata alla
libreria sqlkit [1] potreste rendervi conto che l'80% del lavoro è già
fatto...
E` sicuramente una buona idea usare strumenti più
On Fri, Jan 15, 2010 at 11:28:43AM +0100, Massimo Capanni wrote:
sqlkit funziona bene anche su Win?
Si. Io programmo in Linux ma i miei clienti lo usano con Windows e Mac.
sandro
*:-)
--
Sandro Dentella *:-)
http://sqlkit.argolinux.orgSQLkit home page - PyGTK/python/sqlalchemy
On Jan 15, 2010, at 12:40 PM, Alessandro Dentella wrote:
Si. Io programmo in Linux ma i miei clienti lo usano con Windows e Mac.
Hai clienti che tollerano GTK su mac?
___
Python mailing list
Python@lists.python.it
On Fri, Jan 15, 2010 at 03:34:03PM +0100, Enrico Franchi wrote:
On Jan 15, 2010, at 12:40 PM, Alessandro Dentella wrote:
Si. Io programmo in Linux ma i miei clienti lo usano con Windows e Mac.
Hai clienti che tollerano GTK su mac?
Si. Immagino che tu ti riferisca al fatto che i menu
gtk su mac è per me una dannazione :-(
da utente di osx 10.6 :
uso felicemente pyqt,
ma gtk su mac è di difficile installazione
almeno chè non si ricorre a darwinports o fink
... e nemmeno in quel caso è assicurata stabilità
io eviterei gtk se si vuole far girare l'applicazione senza
On Fri, Jan 15, 2010 at 04:16:07PM +0100, Massimo Di Stefano wrote:
gtk su mac è per me una dannazione :-(
da utente di osx 10.6 :
uso felicemente pyqt,
ma gtk su mac è di difficile installazione
mi dicono lunga più che difficile. Non ho curato personalmente
l'installazione.
Beh,
Il giorno 15/gen/2010, alle ore 16.39, Alessandro Dentella ha scritto:
On Fri, Jan 15, 2010 at 04:16:07PM +0100, Massimo Di Stefano wrote:
gtk su mac è per me una dannazione :-(
da utente di osx 10.6 :
uso felicemente pyqt,
ma gtk su mac è di difficile installazione
mi dicono
2010/1/15 Massimo Di Stefano massimodisa...@yahoo.it:
dal punto di vista dell'utente la scelta di macports non dovrebbe essere un
dramma, anzi facilita la vita
ma se si sviluppa e si utilizzano già tutte le librerie di sistema + moduli
python (installati nel python di sistema)
potrebbe
Il giorno ven, 15/01/2010 alle 17.40 +0100, Lawrence Oluyede ha scritto:
Se volete un toolkit che sembri nativo su tutte le piattaforme direi
che c'e` una sola risposta: PyQt
[...]
Non ho capito se avete cassato la possibilita` di farle Web.
Il raffronto tra le due affermazioni qui
2010/1/15 Pietro Battiston too...@email.it:
Il raffronto tra le due affermazioni qui sopra (considerato anche che la
prima viene utilizzata come motivazione per non utilizzare il toolkit
grafico più utilizzato dagli sviluppatori di software libero*) mi fa un
pochettino sorridere.
Non so come
Dubito che il mio dottore abbia internet in ufficio.
Non so, forse a me sfugge lo use case ma vedo pochi casi specifici che
giustificano a tutti i costi una applicazione desktop oggi giorno,
toolkit mobile a parte.
Se volete posso linkarvi un po' di applicazioni simil-gestionali che
sono
Il giorno 15/gen/2010, alle ore 18.48, Pietro Battiston ha scritto:
Il giorno ven, 15/01/2010 alle 17.40 +0100, Lawrence Oluyede ha scritto:
Se volete un toolkit che sembri nativo su tutte le piattaforme direi
che c'e` una sola risposta: PyQt
[...]
Non ho capito se avete cassato la
2010/1/15 Massimo Di Stefano massimodisa...@yahoo.it:
Concordo sul fatto che GTK è IL toolkit grafico libero ...
pyqt non è ugualmente libero (essendo lgpl .. e di proprietà di nokia)
... essendo un utente di entrambi (linux osx)
ho optato per pyqt (che mi piace davvero un sacco)
Qt e` anche
Lawrence Oluyede wrote:
Se poi il problema e` che queste app devono funzionare senza
connessione di rete allora ritiro tutto :D
C'è poco da ritirare.
Prendiamo il summenzionato OpenERP/OpenProject: è basato su un modello
client-server. Il client è stupido: non solo il database e la logica,
ma
2010/1/15 Nicola Larosa n...@teknico.net:
Per una postazione singola, magari quest'architettura è overkill. Ma
dovendo sviluppare un'applicazione, tanto vale farlo in modo scalabile
fin dall'inizio, tanto più quando lo strumento consente allo stesso tempo
di velocizzare molto il lavoro.
Il giorno ven, 15/01/2010 alle 18.54 +0100, Lawrence Oluyede ha scritto:
2010/1/15 Pietro Battiston too...@email.it:
Il raffronto tra le due affermazioni qui sopra (considerato anche che la
prima viene utilizzata come motivazione per non utilizzare il toolkit
grafico più utilizzato dagli
2010/1/15 Pietro Battiston too...@email.it:
Quello che dicevo è: suggerisci un toolkit invece di un altro perché è
più nativo e poi suggerisci il web?!
(a prescindere dal problema della rete a cui non avevo nemmeno pensato)
suggerivo il web per la facilita` di deployment ecc ecc. Non era un
Il giorno ven, 15/01/2010 alle 19.32 +0100, Lawrence Oluyede ha scritto:
2010/1/15 Pietro Battiston too...@email.it:
Quello che dicevo è: suggerisci un toolkit invece di un altro perché è
più nativo e poi suggerisci il web?!
(a prescindere dal problema della rete a cui non avevo nemmeno
1 - 100 di 112 matches
Mail list logo
