2015-06-24 15:07 GMT+02:00 Enrico Bianchi :
> In questi casi la fuga e` un'opzione. L'altra e` il machete
Posto che non intendo ammazzare nessuno, per l'altra alternativa si deve
avere un posto dive fuggire. Accetto consigli.
Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
__
On 06/24/2015 12:37 PM, Carlos Catucci wrote:
No, producono ansia e stress (a me).
In questi casi la fuga e` un'opzione. L'altra e` il machete
Enrico
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
2015-06-24 14:50 GMT+02:00 Simone Federici :
> Marco Beri:
>
>> In che senso +1? Per arrivare a IBM?
>
>
> HAL viene da 2001 Odissea nello spazio. Un cult che supera Start Trek
> IMHO. Presa per i fondelli di IBM, come hai già capito.
>
Era HAL 9000 comunque :-)
Ho letto penso tutti i libri di C
Marco Beri:
> In che senso +1? Per arrivare a IBM?
HAL viene da 2001 Odissea nello spazio. Un cult che supera Start Trek IMHO.
Presa per i fondelli di IBM, come hai già capito.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailm
On 24/06/2015 13:19, Carlos Catucci wrote:
Dico al computer "fai questo" e lui
lo fa, ci ha rovinati star trek a noi. ;)
https://youtu.be/QpWhugUmV5U :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
On Wed, Jun 24, 2015 at 1:26 PM, Simone Federici
wrote:
> Carlos Catucci:
>
>> Dico al computer "fai questo" e lui lo fa, ci ha rovinati star trek a
>> noi. ;)
>>
> più probabile ci abbia rovinato HAL+1
>
In che senso +1? Per arrivare a IBM?
--
http://beri.it/ - Un blog
http://beri.it/i-miei
Carlos Catucci:
> Dico al computer "fai questo" e lui lo fa, ci ha rovinati star trek a noi.
> ;)
>
più probabile ci abbia rovinato HAL+1
--
Simone Federici
Software Craftsman
XP, Agile, Scrum, Kanban
Quality, performance & security
Explicit is better than implicit.
_
Il 24/Giu/2015 13:15, "Gianluca Sforna" ha scritto:
> Non credo usi quella metafora, altrimenti non potrebbe pretendere che
> il blocco motore che il fornitore non ha deliverato in 4 mesi venga
> forgiato in una settimana da te :)
Ma lui è convinto che progrsmmare sia comd inserire dati su un fo
2015-06-24 12:44 GMT+02:00 Carlos Catucci :
> Che poi uno dei due e' pure un capoprogetto (ingegnere meccanico).
> Solo che di ciclo i sviluppo SW non capisce nulla. Lui pensa sia come per i
> motori.
Non credo usi quella metafora, altrimenti non potrebbe pretendere che
il blocco motore che il for
2015-06-24 12:42 GMT+02:00 Simone Federici :
> ma per caso il tuo capo è tua me?
> no perché succede...
>
No fortunatamento no. a potrebbe essere la mia morte ;)
Che poi uno dei due e' pure un capoprogetto (ingegnere meccanico).
Solo che di ciclo i sviluppo SW non capisce nulla. Lui pensa sia
Carlos Catucci:
> No, producono ansia e stress (a me).
ma per caso il tuo capo è tua me?
no perché succede...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
2015-06-24 12:36 GMT+02:00 Simone Federici :
> => "vivono solo alla giornata"
>
No, producono ansia e stress (a me).
Mista bene il continuous integration e il refactoring, ma considerato che
sono pure da solo a fare le cose ...
Carlos
--
EZLN ... Para Todos Todo ... Nada para nosotros
_
Carlos Catucci:
> I miei capi cambiano idea su tutto mediamente 30 volte al giorno.
=> "vivono solo alla giornata"
Sallo.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python
2015-06-24 12:19 GMT+02:00 Simone Federici :
> Se questo discorso i tuoi capi non lo fanno vuol dire che devi cambiare
> azienda, perché non è meritocratica, ma vive solo alla giornata.
I miei capi cambiano idea su tutto mediamente 30 volte al giorno. Ultima
modifica delle idee 10 minuti fa. Da
Carlos Catucci:
> ma far capire ai capi che il tempo spesso nel TDD
Ai capi non frega nulla perché non sono tecnici.
il TDD serve a te, non a loro. E se lo usi il vantaggio è tuo e non loro.
Spendi più tempo ma sii più preciso, questo è l'unica cosa che i capi
percepiscono.
discorso tipo: certo
2015-06-24 0:01 GMT+02:00 Roberto Polli :
> Anche qui un po' di TDD non è che guasta eh :P
In effetti io cerco di usarlo, ma far capire ai capi che il tempo spesso
nel TDD si recupera abbondamentemente quando troverai il baco su cui sbatti
il capoccione per giorni non e' cosi' realizzabile.
Car
2015-06-24 0:01 GMT+02:00 Roberto Polli :
> Il 23 giugno 2015 21:10, Carlos Catucci ha scritto:
>> ma l'errore si origina (chissa' dove) nel mio codice
>
> Anche qui un po' di TDD non è che guasta eh :P
Mi pare che lo stia già facendo. Il TDD di Rik0, intendo :P
©
--
|:**THE BEER-WARE LICENSE
2015-06-23 20:51 GMT+01:00 Simone Federici :
> Enrico franchi:
>
>> logger.debug('dump: %s', JSONDumper(something))
>
>
> yep, vuol dire scrivere però struttura OOP per il logging, non che ci sia
> nulla di male.
>
Eh... si, vero. D'altra parte o cosi' o cosi'.
>
> non sarebbe male se invece si
2015-06-23 19:57 GMT+01:00 Enrico Bianchi :
> On 06/23/2015 06:58 PM, enrico franchi wrote:
>
>> Poi detto fra di noi: logging sembra essere stato pensato da Javisti. Io
>> temo che semplicemente a suo tempo sia stata presa pesante ispirazione da
>> logging di Java
>>
> Da quello che ho notato, da
Roberto Polli:
>
> Per ogni chiamata che necessita la lambda-join-proxy ce ne sono almeno
> 100 semplici...ad ogni modo se vogliamo
> sviluppare una nuova libreria io sono d'accordo eh :DDD
c'è spazio per le proposte, buttati :-)
--
Simone Federici
Software Craftsman
Il 23 giugno 2015 21:51, Simone Federici ha scritto:
> non sarebbe male se invece si andasse in qualcosa tipo
>
> logger.debug('dump: %s', (json.dumps, (self.obj),))
> [non funziona]
> logger.debug('dump: %s', (lambda x: "\t".join("%s=%s" % (k, v) for k, v in
> x.items(), (data,)))
> [non funzion
Il 23 giugno 2015 21:10, Carlos Catucci ha scritto:
> ma l'errore si origina (chissa' dove) nel mio codice
Anche qui un po' di TDD non è che guasta eh :P
Pace,
R
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/pyt
Enrico franchi:
> logger.debug('dump: %s', JSONDumper(something))
yep, vuol dire scrivere però struttura OOP per il logging, non che ci sia
nulla di male.
non sarebbe male se invece si andasse in qualcosa tipo
logger.debug('dump: %s', (json.dumps, (self.obj),))
[non funziona]
dove cioè il mod
2015-06-23 21:00 GMT+02:00 Giovanni Porcari :
> Scusa ma in debug non puoi servire la versione non compressa ?
Sarebbe la stessa cosa. Mi darebbe lo stesso un errore su una riga di
jQuery.js, ma l'errore si origina (chissa' dove) nel mio codice (sarei un
idiota anche solo a pensare che sia un bu
> Il giorno 23/giu/2015, alle ore 20:53, Carlos Catucci
> ha scritto:
>
> Grazie, sono davvero ottime metodologie. Il debug e' sempre la parte rognosa.
> E fortuna che python da lo stacktrace. Quando uso hjQuery e mi da errore
> sulla riga 4 di jquery-min.js (ovvio che non e' li l'errrore ma
On 06/23/2015 06:58 PM, enrico franchi wrote:
Poi detto fra di noi: logging sembra essere stato pensato da Javisti.
Io temo che semplicemente a suo tempo sia stata presa pesante
ispirazione da logging di Java
Da quello che ho notato, dalla comparsa di log4j, tutte le librerie per
il logging ten
2015-06-23 8:41 GMT+02:00 Simone Federici :
> altro suggerento per loggare elementi costosi a livello computazionale
> tipo json.dumps() è wrapparli con isEnabledFor
>
> if logger.isEnabledFor(logging.DEBUG):
> logger.debug('dump: %s', json.dumps())
>
Grazie, sono davvero ottime metodologie.
2015-06-23 19:02 GMT+02:00 enrico franchi :
>
> 2015-06-23 7:41 GMT+01:00 Simone Federici :
>
>> altro suggerento per loggare elementi costosi a livello computazionale
>> tipo json.dumps() è wrapparli con isEnabledFor
>>
>
> Ah, dimenticavo una cosa... Io *odio* JSON nei logs. E *odio* gli stack
>
2015-06-23 7:41 GMT+01:00 Simone Federici :
> altro suggerento per loggare elementi costosi a livello computazionale
> tipo json.dumps() è wrapparli con isEnabledFor
>
Ah, dimenticavo una cosa... Io *odio* JSON nei logs. E *odio* gli stack
trace nei log. In primo luogo tendono a spaccare qualunqu
2015-06-22 23:28 GMT+01:00 Enrico Bianchi :
> Giusto perche` si e` detto pochi minuti fa' di aprire qualche discussione,
> che ne pensate di questa? Ovvero, che ne pensate dell'usare logging al
> posto di print per debuggare (parte) del codice?
>
> http://inventwithpython.com/blog/2012/04/06/stop-
2015-06-23 7:41 GMT+01:00 Simone Federici :
> altro suggerento per loggare elementi costosi a livello computazionale
> tipo json.dumps() è wrapparli con isEnabledFor
>
> if logger.isEnabledFor(logging.DEBUG):
> logger.debug('dump: %s', json.dumps())
>
Un'altra possibilita' in questi casi (che
Simone Federici:
> se imposti DEBUG in produzione rischia di andare tutto a 1/10 della
> velocità.
>
altro suggerento per loggare elementi costosi a livello computazionale tipo
json.dumps() è wrapparli con isEnabledFor
if logger.isEnabledFor(logging.DEBUG):
logger.debug('dump: %s', json.dump
Enrico Bianchi:
> Ovvero, che ne pensate dell'usare logging al posto di print per debuggare
> (parte) del codice?
non ho letto il suddetto articolo, comunque, secondo me il print() va bene
per scripts per l'interazione con l'utente a linea di comando.
Per il debug, è meglio usare pdb.
Per il l
Giusto perche` si e` detto pochi minuti fa' di aprire qualche
discussione, che ne pensate di questa? Ovvero, che ne pensate dell'usare
logging al posto di print per debuggare (parte) del codice?
http://inventwithpython.com/blog/2012/04/06/stop-using-print-for-debugging-a-5-minute-quickstart-guid
34 matches
Mail list logo
