Re: [Python] Lo so ma e' per un amico

2016-03-19 Per discussione Fundor333 


Stavolta e' vero, io sono allergico a node, se provo a usarlo mi 
vengono tutte bolle verdi ;)
Queste sono le cose che non mi piacciono di js in generale 
https://youtu.be/et8xNAc2ic8


--
Fundor333

___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-19 Per discussione enrico franchi 
2016-03-18 10:28 GMT+00:00 Carlos Catucci :

> Tutto e' relativo, dipende dal contesto.
>

Yep.


> Io per esempio per garantire di poter lavorare anche se la ruspa dei
> lavori in corso trancia i cavi dell'adsl (ci e' successo realmente a
> Modena) un rapsino con un disco in replica che puo' fungere da macchina di
> backup locale lo propongo. Poi dipende da cosa fa il servizio/applicazione.
> Se devo solo consultare ogni tanto non da problemi, ma se ho tutto li sopra
> ecco che il sistema di backup locale diventa vitale.
>

Breaking news... da qualche mese e' disponibile una nuova cosa chiamata
"cloud computing", che vuole dire che in pratica ti scegli il modello di
ridondanza/availability che vuoi e fine della fiera. Vuoi piu' availably
zones? Puoi. Pensi che tutto sommato devi proteggerti da un evento
catastrofico, che so... in us-east-1? bene... prendi qualcosa anche in
us-east-2. Pensi che tutta l'america possa venire invasa dagli alieni (ci
sono le foto! [0]), prendi qualcosa anche che so... in Australia. I canguri
terranno lontani gli alieni. Etc etc etc. ;)

Poi le ruspe continueranno a tranciare i cavi. Pero' smette di essere un
problema tuo...


---
[0]
http://vignette3.wikia.nocookie.net/aliens/images/b/b2/Alien_Independence_Day.png/revision/latest?cb=20110124141918



-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-19 Per discussione Carlos Catucci 
2016-03-18 15:09 GMT+01:00 enrico franchi :

>
> Breaking news... da qualche mese e' disponibile una nuova cosa chiamata
> "cloud computing", che vuole dire che in pratica ti scegli il modello di
> ridondanza/availability che vuoi e fine della fiera. Vuoi piu' availably
> zones? Puoi. Pensi che
>
[...]

> Poi le ruspe continueranno a tranciare i cavi. Pero' smette di essere un
> problema tuo...
>

Enrico se le ruspe tranciano il cavo della connessione dove sono le
postazioni di lavoro (ufficio del cliente) non esiste cloud che mi faccia
andare.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-19 Per discussione Carlos Catucci 
2016-03-18 15:59 GMT+01:00 Giovanni Porcari :

> No. Però un bel modem 4G qualcosa di buono fa…


Concordo, se sei coperto da rete 4G. Cosa che per molte (troppe) zone in
questo paese non corrisponde al vero.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Codemotion: qualcuno è in giro?

2016-03-19 Per discussione Carlos Catucci 
Il giorno 19/mar/2016 13:15, "Roberto Polli"  ha
scritto:
>
> Ciao belli.
>
> C'é qcn in giro?
>

come no, siamo in mezzo a una strada ;)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Codemotion: qualcuno è in giro?

2016-03-19 Per discussione Roberto Polli 
Ciao belli.

C'é qcn in giro?

Pace, R
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Lo so ma e' per un amico

2016-03-19 Per discussione Simone Federici 
Carlos Catucci :

> ma un amico mi chiedeva


ma dai non ti vergognare...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-19 Per discussione enrico franchi 
2016-03-18 10:58 GMT+00:00 Gollum1 :

>
>
> lasciamo perdere va... sono da mesi oramai che chiedo di replicare
> localmente un server di autenticazione, che ora è solo a Roma...
>
> in un paio di occasioni c'é stato un problema sulle linee di
> comunicazione, e ci siamo trovati con la produzione ferma, solo perché
> gli utenti (montatori) non potevano loggarsi sulle macchine di
> montaggio... (una delle due volte, si era spenta tutta la farm in cui
> risiedono i loro server di autenticazione, un disastro).
>
> ma ingegneria non ci sente... stupidi...
>
>
Unipr, l'anno scorso... storia breve, c'era un UPS vecchiotto che stava
schiattando. Dovevano fare lavori elettrici.
Fanno i lavori elettrici. L'UPS era vecchio ed e' schiattato. Doveva essere
ridondato ma non lo era.
Va giu' un po' di roba... nulla di importante, se non, precisamente, il
server di autenticazione. Bene... non ridondato. Meglio. Avevo detto storia
breve? Beh, in pratica *tutto* (email inclusa) ha smesso di funzionare per
10 giorni... fra cui l'iscrizione agli esami.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Lo so ma e' per un amico

2016-03-19 Per discussione Carlos Catucci 
On 18 March 2016 at 16:58, Simone Federici  wrote:

> ma dai non ti vergognare...
>

Stavolta e' vero, io sono allergico a node, se provo a usarlo mi vengono
tutte bolle verdi ;)

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] attributi astratti?

2016-03-19 Per discussione Marco De Paoli 
Il 11/mar/2016 17:13, "Marco Santamaria"  ha
scritto:
>
> Ciao,
>
> sto lavorando ad un piccolo framework nel quale mi sento autorizzato ad
usare il modulo abc per creare delle classi astratte/interfacce per
permetterne l'estensione.

https://pymotw.com/3/abc/

publicato ieri

- Marco
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Test: uovodicolombosilverbulletdeusexmachinaratatouillecaramba!

2016-03-19 Per discussione enrico franchi 
2016-03-15 18:22 GMT+00:00 Carlos Catucci :

> Questione di scala Enrico.


A me verrebbe dire anche questione di business, piuttosto. O se vuoi, del
tipo di business e del modello di deploy che hai.

Per esempio se fai sw "boxed" i rilasci sono costosissimi e vuoi certamente
dell'infrastruttura massiccia di QA. D'altra parte per la maggior parte dei
sw l'utente si aspetta che ci siano dei bachi. Insomma, Word (o chi per
lui) ogni tanto crasha. Lo sappiamo tutti e continuiamo ad usarlo (magari
usiamo il "chi per lui", che a sua volta ogni tanto va giu'). Pero' grosso
modo e' su... il motivo e' che di fatto l'infrastruttura e' interamente in
mano all'utente. Che d'altra parte vuole dire che determinati tipi di
testing diventano molto piu' complicati. Il caso "pessimo" e' quello dei
giochi che magari hanno bachi nei motori grafici che sono triggerati solo
da certe combinazioni di un certo modello di scheda video con una certa
versione dei driver su una certa versione di un certo sistema operativo.

Se c'e' un baco, si considera ok aspettare qualche mese per avere una minor
version che lo aggiusta. Inoltre, se si introduce un baco, basta dare un
buon modo all'utente di usare la vecchia versione e probabilmente gli si da
solo un fastidio marginale. Non solo... certi utenti si aspettano che la
nuova versione abbia bachi e prima di "adottarla" la testano. Pochi, eh...
ma spesso quelli per cui e' veramente critico lo fanno.

Il modello dei servizi web e' opposto. Ci si aspettano rilasci brevi. Ci si
aspetta che il software sia sempre su. I bachi sono una cosa statistica:
ovvero sappiamo che per qualche utente ci saranno dei problemi, ma fintanto
che il singolo utente non ha problemi troppo spesso si puo' tollerare. Poi
ci sono un mucchio di cose che sappiamo che andranno storte... quindi via
di retry. Che so... se faccio una chiamata ad un servizio, puo' andare male
anche solo per questioni di rete o del momento in cui succede. Ma magari il
servizio di per se e' su e non c'e' davvero un "baco" nel codice. Riprovo
tutto e vado. Magari l'utente stesso e' disposto di tanto in tanto a
ricaricare la pagina per aggiustare una situazione.

E anche qui... e' diverso fare un servizio che "vendi" ad un'azienda il cui
business ne dipende. Se "vendo" un servizio di billing per ecommerce e io
sono giu', i miei clienti non possono fatturare. Non saranno tolleranti. Se
fallisco una transazione su 100, non saranno contenti. Se a mia volta il
mio servizio e' un ecommerce, gli stessi problemi sopra descritti possono
volere dire meno vendite e meno soldi. Downtime vuole dire perdite
monetarie quantificabili immediatamente. Non solo... non posso nemmeno
facilmente testare il mio codice in produzione (ovvero, iniziare a
deployare timidamente e sperare che funzioni tutto). Viceversa se sto
facendo un servizio per condividere una bacheca di puttanate con i miei
amici, posso: 1) fallire di tanto in tanto, inoltre, siccome molti fanno
sta roba dal cellulare, potrebbero addirittura pensare che non sono io a
fallire, ma che e' la connessione che e' singhiozzante; 2) testare feature
su pochi clienti alla volta... posso anche convincerli di essere fortunati
a starmi facendo da beta tester a gratis. Un celebre servizio di
microblogging aveva problemi immensi di availability eppure si e' comunque
espanso.

Comunque a prescindere da quale situazione sia, in generale "non so chi
sono i miei clienti". Ovvero sono tanti, continuano ad entrare e,
potenzialmente, ad uscire. Mi possono abbandonare probabilmente con un
costo limitato. La mia reputazione e' una cosa globale, invece: qualche
post su twitter di persone chiave puo' crearmi grossissimi problemi. Tutti
sanno chi sono (o per lo meno, tutti quelli che sono interessati al tipo di
servizio che sto vendendo/proponendo).

Se quello che fai e' invece offrire soluzioni "individuali" per clienti, e'
un mercato ancora diverso. C'e' un rapporto piu' stretto. I tempi in
qualche modo li da il cliente (mentre se faccio servizi web i tempi li da
"il mercato" -- se siamo i secondi a rilasciare questa feature abbiamo
perso la battaglia -- oppure essere quasi interno -- rilascio questa
feature quando e' pronta, o ancora, rilascio tutte le settimane, ma includo
nel rilascio solo quello che e' pronto). E poi dipendera' di volta in volta
come vengono fatti deployment, aggiornamenti, new release; se le macchine
sono mie o del cliente, quanta gestione ho sulle macchine, etc etc etc.


Questo solo per dire che siccome i modelli di business sono davvero
diversi, non e' affatto detto che una strategia completamente accettabile
in una situazione sia completamente suicida in un'altra.


-- 
.
..: -enrico-
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

[Python] Lo so ma e' per un amico

2016-03-19 Per discussione Carlos Catucci 
Lo so che parlare qui dentro di nodejs e' peggio che bestemmiare in pieno
vaticano,
ma un amico mi chiedeva un parere su come fare una cosa.
Piu' che per nodejs mi piacerebbe sentire come approccereste anche in
generale questa problematica.

Utilizzano socket.io  e JWT.

"come facciamo a determinare in nodejs se un utente ha una o piu' sessioni
dove in qualche modo non sia consentito effettuare connessioni con i
websocket?"

In pratica se uno user ha piu' sessions, devono controlalre se siano vive
(unblocked) e se si come killare solo quelle non attive.

Carlos
-- 
EZLN ... Para Todos Todo ... Nada para nosotros
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python