Re: [Python] Tutorial su FUSE

[Alessandro Re]

2015-09-30 22:11 GMT+01:00 Marco Paolini :
> Voglio dire il config file di nginx lo metto su un mount fuse e non appena
> nginx tenta di aprirlo, io creo al volo il config file da python prendendo
> per esempio delle informazioni da variabili di ambiente...
>
> è troppo un accrocchio?

Ah guarda, per me non è un accrocchio, ma una soluzione piuttosto
divertente :D E dipende abbastanza per cosa ti serve...

Ma mi chiedo: quali sono le alternative? Quanto stabili sono? Quanto
sono manutenibili? Quali requisiti hanno? È necessario passare per
fuse?

Perché se devi far partire nginx (che non conosco) in un container
usando ogni volta un file di configurazione diverso, allora forse è
più lineare se fai uno script che genera il file e lancia il server
ogni volta: mi sembra più semplice e meno prone ad errori.

Se invece il server deve sempre restare attivo e ogni tanto per
qualche motivo deve cambiare configurazione e l'unico modo è leggere
lo stesso file, allora passare per fuse potrebbe anche aver senso.

E grazie per il consiglio sul try, in effetti non avevo pensato al finally!
Ciauz!
~Ale
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Tutorial su FUSE

[Marco Paolini]

Il giorno 30 settembre 2015 21:52, Alessandro Re  ha
scritto:

> Ciao lista,
>
> mi faccio della pubblicità (cosa che non mi piace mai fare, perché
> temo le conseguenze dei miei errori :D), e vi condivido un tutorial
> che ho scritto su llfuse.
>
> llfuse è una libreria per python che permette di creare filesystem con
> fuse, usando le API di basso livello.
>
> Se qualcuno fosse esperto con queste belle cose, qualunque feedback
> (incluso "fa cagare" + giustificazione) mi farebbe piacere.
>
> Se invece non siete esperti con fuse, per me vale la pena di dargli
> un'occhiata perché è un concetto molto carino :)
>
> https://gist.github.com/akiross/3d7952b186d523c61cbc


io farei:

try:
 llfuse.main()
finally:
  llfuse.close()

secondo te sarebbe applicabile tipo per configurare dinamicamente nginx
dentro un container?

Voglio dire il config file di nginx lo metto su un mount fuse e non appena
nginx tenta di aprirlo, io creo al volo il config file da python prendendo
per esempio delle informazioni da variabili di ambiente...

è troppo un accrocchio?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Paolini]

2015-09-30 10:01 GMT+02:00 Marco Beri :

> 2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti <
> riccardo.magliocche...@gmail.com>:
>
>> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>>>
>>> Uso python. Ultimamente stiamo mettendo su una architettura microservice
>>> che
>>> prevede API gateway piccolissimo in node che fa il dispatch, dietro ci
>>> sono i
>>> microservice python. Abbiamo copiato un po' da qua
>>> https://www.nginx.com/blog/introduction-to-microservices/
>>>
>>
>> link interessante grazie
>
>
> Uno dei rovesci dell'architettura a microservices che trovo davvero duro
> da digerire è questo:
>
> *"Business transactions that update multiple business entities are fairly
> common. These kinds of transactions are trivial to implement in a
> monolithic application because there is a single database. In a
> microservices-based application, however, you need to update multiple
> databases owned by different services. Using distributed transactions is
> usually not an option, and not only because of the CAP theorem. They simply
> are not supported by many of today’s highly scalable NoSQL databases and
> messaging brokers."*
>
> La soluzione non la trovo utilizzabile in ambito, per esempio, finanziario
> (ma ammetto di essere ignorante in questo approccio, per questo chiedo un
> parere qui):
>
> *"You end up having to use an eventual consistency based approach, which
> is more challenging for developers."*
>

Marco, hai centrato perfettamente il nodo della questione.

In una app monolitica puoi fare:

def purchase_product(product_id, payment_id):
  with transaction.atomic():
product = Product.objects.select_for_update().get(pk=prod_id)
if product.status != 'available':
  raise ProductNotAvaliable()
product.status = 'purchased'
product.save()
Payment.objects.create(product=product, payment_id=payment_id)

sfruttando alla grande le funzionalità del db relazionale per sincronizzare
l'accesso ai dati e per garantire l'integrità e la consistenza.

Se product e Payment fossero in due microservice differenti, dovremmo
creare una transazione distrubita (XA) e gestire il fallimento a livello
applicativo. Molto + codice, molto + difficile da testare.

L'approccio che propongo, e sul quale sto sperimentando da un po', si basa
su un core monolitico django e *alcuni* microservice periferici che stanno
dietro ad un "frontend application tier" (scusate il nome) in nodejs che
permette l'isomorfismo di parte della app e con API graphql. Tutti questi
componenti girano in container docker. Ultimamente stiamo usando trhift per
la comunicazione interna tra questi "microservice". Stiamo scopiazzando un
po' da facebook ;)

In generale nella maggior parte dei progetti in cui lavoro alla fine non ci
saranno mai sopra più di una decina di sviluppatori, quindi l'architettura
monolitica se ben incapsulata va benissimo. I microservice a noi servono
per gestire un po' meglio la scalabilità e il ciclo di vita dei singoli
componenti e poer poterli scrivere in linguaggi diversi in alcuni casi.

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

[Python] Tutorial su FUSE

[Alessandro Re]

Ciao lista,

mi faccio della pubblicità (cosa che non mi piace mai fare, perché
temo le conseguenze dei miei errori :D), e vi condivido un tutorial
che ho scritto su llfuse.

llfuse è una libreria per python che permette di creare filesystem con
fuse, usando le API di basso livello.

Se qualcuno fosse esperto con queste belle cose, qualunque feedback
(incluso "fa cagare" + giustificazione) mi farebbe piacere.

Se invece non siete esperti con fuse, per me vale la pena di dargli
un'occhiata perché è un concetto molto carino :)

https://gist.github.com/akiross/3d7952b186d523c61cbc

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Nicola Larosa]

Manlio Perillo wrote:
> usando Go per il backend e gopherjs per il frontend.

Una web framework interessante scritto in Go che usa GopherJS è Seven5
. L'ho usato per una semplice admin UI, non è
male. Ho incontrato l'autore, Ian Smith, a luglio alla GopherCon di
Denver, è simpatico e disponibile.

Tieni conto che la community in pratica sono io (o lo ero). Se lo usi
anche tu, saremo in due. :-)

-- 
Nicola 'tekNico' Larosa 

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

[Python] aggiornamento sullo stato di gopy

[Carlo Miron]

http://talks.godoc.org/github.com/sbinet/talks/2015/20150929-gopy-lyon/gopy-lyon.slide

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Manlio Perillo]

2015-09-30 2:10 GMT+02:00 enrico franchi :

>
> 2015-09-29 18:43 GMT+01:00 Manlio Perillo :
>
>> La portabilità?
>>
>
> Cosa intendi con "portabilita'"? Il senso "tradizionale" chiaramente non
> si applica...
>
>
Diciamo che vorrei essere in grado di sviluppare una GUI per una mia
applicazione (magari in Go) senza
complicarmi la vita.
Dopo averci riflettuto, stavo pensando di usare questo per disperazione:
https://developer.chrome.com/extensions/nativeMessaging
usando Go per il backend e gopherjs per il frontend.

L'alternativa è usare Qt,  che si appoggia ad ANGLE (come chrome), ma che
comporta un minimo di sbattimento per
installare le librerie necessarie se non addirittura compilarsi tutto.

Da notare però che go-qml sono mesi che non viene aggiornato.
Secondo questa pagina:
https://en.wikipedia.org/wiki/List_of_language_bindings_for_GTK+
i bindings per le GTK sono messi peggio.

Il fatto stesso che per potermi interfacciare ad una libreria "completa"
per la GUI sia così "incasinato", a meno di non
utilizzare lo stesso linguaggio in cui la libreria/framework è stato
sviluppato, significa che c'è qualcosa di profondamente
sbagliato.
Le GUI moderne usano un linguaggio ad oggetti come C++ o Java, e richiedono
il subclassing per poterle utilizzare.
Come fai in Go? Per fortuna le Qt hanno QML e le GTK sono scritte in C...

Usando tecnologie web sono costretto ad usare Javascript, ma:
1) Il linguaggio non è object-oriented alla C++/Java (anche se sembra lo
vogliano fare diventare)
2) La UI è dichiarativa di default, essendo in HTML
3) Dato che Javascript lo usano tutti, ci sono tool come gopherjs


Ciao  Manlio

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlo Miron]

2015-09-30 14:32 GMT+02:00 Nicola Larosa :

>> Nicola Larosa wrote:
>>> peccato non sia scritto in Go. ;-)
>
> Carlo Miron wrote:
>> Stronzetto, è praticamente scritto in python...
>>
>> * C++ 55.8%
>> * Python 29.3%
>
> Magra consolazione non avere la sindrome di Stoccolma più grossa da
> queste parti...

Chi/cosa mi avrebbe maltrattato, scusa?

> Dove l'hai presi 'sti numeri? Me ne risultano altri:
> 



㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Nicola Larosa]

> Nicola Larosa wrote:
>> peccato non sia scritto in Go. ;-)

Carlo Miron wrote:
> Stronzetto, è praticamente scritto in python...
> 
> * C++ 55.8%
> * Python 29.3%

Magra consolazione non avere la sindrome di Stoccolma più grossa da
queste parti...


> * JavaScript 5.0%
> * CoffeeScript 3.7%
> * CSS 2.9%
> * Ruby 0.9%
> * Other 2.4%

Dove l'hai presi 'sti numeri? Me ne risultano altri:



C++ 82.6%
Python 8.4%
Javascript 7.2%

e spiccioli di altro.

(Non potevano continuare a chiamarsi Ohloh, o perlomeno trovare un nome
meno generico? Continuo a dimenticarlo...)

-- 
Nicola 'tekNico' Larosa 

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlo Miron]

2015-09-30 11:21 GMT+02:00 Nicola Larosa :

> RethinkDB sembra un NoSQL fatto bene:
> 
>
> Un query language decente, garanzie sulle scritture, MVCC come l'amato
> elefante, client Python ufficiale... peccato non sia scritto in Go. ;-)

Stronzetto, è praticamente scritto in python...

* C++ 55.8%
* Python 29.3%
* JavaScript 5.0%
* CoffeeScript 3.7%
* CSS 2.9%
* Ruby 0.9%
* Other 2.4%

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlos Catucci]

2015-09-30 11:39 GMT+02:00 enrico franchi :

>
> Tra l'altro non sono molto convinto che node faccia "bene" cose che Python
> fa "male". Anzi, direi che essenzialmente le cose che Python fa davvero
> male sono quelle che anche Node fa male.


Il che non e' una grande consolazione. ;)

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlos Catucci]

2015-09-30 11:33 GMT+02:00 enrico franchi :

>
> Mah, guarda... bisogna vedere numeri (e caso per caso). Quando si parla di
> "efficienza" si rischiano sempre di prendere delle cantonate.
>

Concordo ma in generale a me piace come logica. Sara' che vengo dai tempi
in cui si cercava di risparmiare i bytes, in tutto (spazio disco, memoria
gestita, traffico su porte seriali)


> Non parlo di quello. E non sono completamente certo che il paginone
> funzioni bene sul mobile; concordo che lo trovo in generale scomodo sul
> desktop. Ma lo trovo scomodo anche sul mobile.
>

In effetti puo' esserlo dipende anche dalle dimensioni del device. Sul mi
Galaxy Ace devo dire che trovo scomodo tutto ;)

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[m]

* Marco De Paoli (depao...@gmail.com) [150930 12:02]:


segnalo questa intervista all'inventore del "CAP theorem", Eric Brewer



Brewer fece la congettura, il teorema è di Gilbert e Lynch (quindi IMHO,
la parte faticosa l'hanno fatta loro, non Brewer)

--
 .*.finelli
 /V\
(/ \) --
(   )   Linux: Friends dont let friends use Piccolosoffice
^^-^^ --

Politicians speak for their parties, and parties never are, never have
been, and never will be wrong.
-- Walter Dwight
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlos Catucci]

On 30 September 2015 at 12:10, Carlo Miron  wrote:

> Beh, è noto che gli ingegneri Amazon sono tutti incapaci. Senza eccezioni.


E' una mia impressione o abbiamo qualcuno in llista che e' parte di cotanta
schiera? ;)

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlo Miron]

2015-09-30 12:02 GMT+02:00 Marco De Paoli :

> sono spesso citati i casi di un ATM mi permette di prelevare soldi che non
> mi appartengono o Amazon che mi lascia ordinare beni che non esistono più...

Beh, è noto che gli ingegneri Amazon sono tutti incapaci. Senza eccezioni.

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco De Paoli]

Il giorno 30 settembre 2015 11:27, Carlo Miron  ha scritto:

> 2015-09-30 10:34 GMT+02:00 Marco Beri :
>
> > On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron  wrote:
> >> Già, è un bel casino. Dato che non sempre la consistenza eventuale è
> >> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
> >> le complicazioni del caso.
> >
> > "The main disadvantage to this algorithm is that it cannot recover in the
> > event the network is segmented in any manner. The original 3PC algorithm
> > assumes a fail-stop model,
> > where processes fail by crashing and crashes can be accurately detected,
> and
> > does not work with network partitions or asynchronous communication:
> >
> > Brrr...
>
> Riporto un dialogo immaginario tra me e un personaggio fittizio che
> chiamerò Pelatone™ per proteggerne l'identità.
>
> me
> non c'è soluzione, al problema del partitioning
> ma nemmeno con nessuna replica master-master relazionale
> quindi è un problema comune
>
> Pelatone
> certo
> ma tu useresti un db replicato in una applicazione finanziaria per esempio?
>
> me
> se lo devo scalare sui c100k non vedo grosse alternative
>
> Pelatone
> ok
> 100.000 connessioni al secondo in una app finanziaria... uhm...
> solo la borsa mi sa
> però in quel caso lì io devo essere sicuro delle transazioni...
> come faranno?
>
> me
> evitano accuratamente che il sistema si partizioni :D
>
> Pelatone
> :D :D
> bella roba... allora è come dicevo io... non si usano
> i microservizi
> in una app finanziaria
>
> me
> ripeto, il problema del partitioning non è insito nei microservizi
> ce l'hai anche nello sharding
> solo la replica master/slave ne è immune
> ma presenta forti limiti di scalabilità, infatti
> poi non è vero che il fail-stop model è sempre la soluzione migliore
> per esempio la borsa. se la cina si isola, il sistema borsa crolla?
> no, si formano due isole indipendenti; il mercato va avanti da una
> parte senza la cina, dall'altra solo con la cina
> e poi qualche povero deficente riconcilia il casino ammano :-/
> hai indubbiamente perso consistenza. ma è la migliore quantità di
> consistenza che puoi ottenere in un sistema distribuito peer
> e non c'è nessun "non me lo posso permettere" che tenga, punto.
>

segnalo questa intervista all'inventore del "CAP theorem", Eric Brewer
https://medium.com/s-c-a-l-e/google-systems-guru-explains-why-containers-are-the-future-of-computing-87922af2cf95

parla di container, di orchestration e di "compromises on consistency"

un estratto:

That bothered me for a little while until I eventually realized that was a
fundamental tradeoff and that anyone that wants to be highly available in a
distributed system has to make some compromises on consistency. It was not
at first well received, because it implies that people who build databases
can’t promise to be up all the time, even though they do make that promise.
And it means if you want to have both you actually have to work pretty hard
to even get good compromises.

certo ci sono varie strategie di eventually consistency ...

sono spesso citati i casi di un ATM mi permette di prelevare soldi che non
mi appartengono o Amazon che mi lascia ordinare beni che non esistono
più...
è qualcosa che va gestito a vari livelli: dal livello del codice
applicativo (logica supplementare per gestire queste situazioni) su su fino
ai livelli dirigenziali dell'azienda per capire cosa è accettabile e cosa no

il caso citato da Carlo è però emblematicamente divertente nella sua
enormità: vorrei proprio vedere chi sarebbe l'autorità delegata a
ri-raccordare le quotazioni delle borse occidentali con le borse asiatiche
in caso di partitioning continentale...

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-30 8:05 GMT+01:00 Carlos Catucci :

> Infatti il motivo per cui ancora non ho approcciato node e' questo. la
> tentazione di usarlo per fare del multi-process diciamo, cioe' per quelle
> cose che Python non fa o fa con fatica, la vrei avuta. Lo so posso usare
> Go, o altri linguaggi che lo fanno bene, ma JS e' un linguggio (un male?)
> conosciuto, ho meno rischi di scrivere cazzate per poca conoscenza del
> linguaggio (quella di scriverle per miei fault e' una cosa differente).
> Eppure non riesco a decidermi a mettere js sul server (tranne che come
> dipnedenza di qualcosa appunto, come dice Riko).


Tra l'altro non sono molto convinto che node faccia "bene" cose che Python
fa "male". Anzi, direi che essenzialmente le cose che Python fa davvero
male sono quelle che anche Node fa male.


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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-30 8:02 GMT+01:00 Carlos Catucci :

>
> 2015-09-30 2:40 GMT+02:00 enrico franchi :
>
>> E, sfortunatamente, sara' colpa di troppe fatte male, ma tendo ad odiare
>> le single page apps.
>>
>
> Potresti illustrare le cose fatte male nelle Single Page Apps?
>

Puoi trovare parecchio in rete, da parte di gente piu' competente sul
front-end del sottoscritto.

E si, ci sono alcuni use-case in cui la faccenda non e' particolarmente
rilevante. Ci sono use case in cui e' comodo (per l'utente).

In generale il problema che trovo e' che alla fine dei conti devi fare "a
mano" un sacco di roba che il browser farebbe per te (e si, i framework
aiutano). Poi ci sono varie questioni di SEO, accessibilita', etc etc etc.

Ma in generale il fatto che la cosa bella del web era la sua semplicita' e
la sua componibilita'. Spezzare la parte servizio dalla parte UI ha senso
(ma anche li, ci sono costi sia a farlo che a non farlo) ed e' un
vantaggio. Ma non e' necessario essere una SPA per farlo.

Io le trovo comode, almeno intendo quelle dove la parte dinamica della
> pagna cambia tramite callback REST ajax, senza dover ricaricaricare
> (inutilmente?) anche parti gia' caricate nella pagina precedente.
> Sopratutto se hai una connessione non brillantissima (problema che ha
> ancora una parte davvero grande della popolazione mondiale sebbene chi
> lavori nel settore sia abituato a velocita' almeno decenti).
>

Mah, guarda... bisogna vedere numeri (e caso per caso). Quando si parla di
"efficienza" si rischiano sempre di prendere delle cantonate.


>
> Se invece intendi la moda di avere la pagina enorme che scrolla in
> verticale devo dire che la trovo poco fruibile su computer. Capisco che su
> device mobile/touch possano avere il loro perche', ma su PC no. E visto che
> si puo' sapere con cosa fai la richiesta (OS, browser e relative versioni)
> fare dei CSS adattativi non mi sembra impossibile.
>
>
Non parlo di quello. E non sono completamente certo che il paginone
funzioni bene sul mobile; concordo che lo trovo in generale scomodo sul
desktop. Ma lo trovo scomodo anche sul mobile.

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Beri]

2015-09-30 11:27 GMT+02:00 Carlo Miron :

> 2015-09-30 10:34 GMT+02:00 Pelatone immaginario:
>
> > Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura
> che
> > hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)
>
> non è sempre vero. se hai solo problemi evolutivi, succederà che il
> costo evolutivo diventerà insopportabile ed il sistema stagnerà finché
> qualcuno non propone una alternativa più economica. se invece devi
> anche scalare (per esempio, per adattare il tuo sistema nazionale ad
> un nuovo mercato), allora se il costo complessivo di riscrittura è
> inferiore a quello evolutivo, riscrivere conviene
> (ipotizzando che la riscrittura abbassi la complessità/migliori le
> prestazioni/etc di ordini di grandezza)
>

Yep. Intendevo dire che ti dicono spesso di no (cliente or manager).

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlo Miron]

2015-09-30 10:34 GMT+02:00 Marco Beri :

> On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron  wrote:
>> Già, è un bel casino. Dato che non sempre la consistenza eventuale è
>> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
>> le complicazioni del caso.
>
> "The main disadvantage to this algorithm is that it cannot recover in the
> event the network is segmented in any manner. The original 3PC algorithm
> assumes a fail-stop model,
> where processes fail by crashing and crashes can be accurately detected, and
> does not work with network partitions or asynchronous communication:
>
> Brrr...

Riporto un dialogo immaginario tra me e un personaggio fittizio che
chiamerò Pelatone™ per proteggerne l'identità.

me
non c'è soluzione, al problema del partitioning
ma nemmeno con nessuna replica master-master relazionale
quindi è un problema comune

Pelatone
certo
ma tu useresti un db replicato in una applicazione finanziaria per esempio?

me
se lo devo scalare sui c100k non vedo grosse alternative

Pelatone
ok
100.000 connessioni al secondo in una app finanziaria... uhm...
solo la borsa mi sa
però in quel caso lì io devo essere sicuro delle transazioni...
come faranno?

me
evitano accuratamente che il sistema si partizioni :D

Pelatone
:D :D
bella roba... allora è come dicevo io... non si usano
i microservizi
in una app finanziaria

me
ripeto, il problema del partitioning non è insito nei microservizi
ce l'hai anche nello sharding
solo la replica master/slave ne è immune
ma presenta forti limiti di scalabilità, infatti
poi non è vero che il fail-stop model è sempre la soluzione migliore
per esempio la borsa. se la cina si isola, il sistema borsa crolla?
no, si formano due isole indipendenti; il mercato va avanti da una
parte senza la cina, dall'altra solo con la cina
e poi qualche povero deficente riconcilia il casino ammano :-/
hai indubbiamente perso consistenza. ma è la migliore quantità di
consistenza che puoi ottenere in un sistema distribuito peer
e non c'è nessun "non me lo posso permettere" che tenga, punto.

>> Probabilmente è vero che l'architettura a
>> microservizi è da adottare quando ulteriori evoluzioni o scale up di
>> software monolitico diventano troppo
>> complesse/costose/rischiose/wathever.
>
> Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura che
> hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)

non è sempre vero. se hai solo problemi evolutivi, succederà che il
costo evolutivo diventerà insopportabile ed il sistema stagnerà finché
qualcuno non propone una alternativa più economica. se invece devi
anche scalare (per esempio, per adattare il tuo sistema nazionale ad
un nuovo mercato), allora se il costo complessivo di riscrittura è
inferiore a quello evolutivo, riscrivere conviene
(ipotizzando che la riscrittura abbassi la complessità/migliori le
prestazioni/etc di ordini di grandezza)

㎝

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Ippolito]

Il 30 settembre 2015 11:22, Riccardo Magliocchetti
 ha scritto:


> http://martinfowler.com/bliki/MonolithFirst.html

Interessante.Grazie. Lo sto leggendo e mi sta dando ulteriori spunti,
ma anche tanti punti interrogativi.
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Beri]

2015-09-30 11:22 GMT+02:00 Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com>:

> Il 30/09/2015 11:15, Marco Ippolito ha scritto:
>
>>
 Quale approccio pratico consigli?

>>>
>>> marcob...@gmail.com tramite lists.python.it
>>
>>> Bella domanda... :-)
>>>
>>> 2a domanda collegata: e se parti "green field"cioè in un progetto
>> nuovo, mettiamo il caso che si rivela essere
>> tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
>> successo)quale approccio pratico consigli?
>> Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
>> con quale/i criterio/i pratico/i?
>>
>
> http://martinfowler.com/bliki/MonolithFirst.html



Apperò... Interessante anche questo.

Grazie.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Beri]

2015-09-30 11:15 GMT+02:00 Marco Ippolito :

> >>
> >> Quale approccio pratico consigli?
> >
> marcob...@gmail.com tramite lists.python.it
> > Bella domanda... :-)
> >
> 2a domanda collegata: e se parti "green field"cioè in un progetto
> nuovo, mettiamo il caso che si rivela essere
> tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
> successo)quale approccio pratico consigli?
> Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
> con quale/i criterio/i pratico/i?
>

2ª bella domanda :-)


-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Riccardo Magliocchetti]

Il 30/09/2015 11:15, Marco Ippolito ha scritto:


Quale approccio pratico consigli?



marcob...@gmail.com tramite lists.python.it

Bella domanda... :-)


2a domanda collegata: e se parti "green field"cioè in un progetto
nuovo, mettiamo il caso che si rivela essere
tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
successo)quale approccio pratico consigli?
Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
con quale/i criterio/i pratico/i?


http://martinfowler.com/bliki/MonolithFirst.html

--
Riccardo Magliocchetti
@rmistaken

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Nicola Larosa]

Marco Ippolito wrote:
> Quindi meglio continuare ad ingro/a-ssare il mammuth?

RethinkDB sembra un NoSQL fatto bene:


Un query language decente, garanzie sulle scritture, MVCC come l'amato
elefante, client Python ufficiale... peccato non sia scritto in Go. ;-)

-- 
Nicola 'tekNico' Larosa 

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[enrico franchi]

2015-09-30 7:56 GMT+01:00 Carlos Catucci :

> Ilpunto e' che anche JS non e' realmente un standard, a volte magari
> qualche side effect tra un browser e l'altro si incontra  (meno di un tempo
> pero')


Lo standard c'e'. Tutto sommato l'effort di seguirlo c'e'. Chi piu'
velocemente chi meno... ma c'e'.

Io non direi che Javascript non e' uno standard. Per dire, magari non e'
ovvio se non ci si ha fatto sopra roba... ma dovremmo dire che anche Unix
(o SuS o POSIX che dir si voglia) non e' uno standard perche' qualche side
effect qui e li si trova (per esempio Linux alcune cose le implementa fuori
standard e immagino anche la maggior parte degli altri OS).

E Python non e' cross platform. Anche li, piu' di qualche glitch anche solo
fra Linux e Windows.


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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Ippolito]

>>
>> Quale approccio pratico consigli?
>
marcob...@gmail.com tramite lists.python.it
> Bella domanda... :-)
>
2a domanda collegata: e se parti "green field"cioè in un progetto
nuovo, mettiamo il caso che si rivela essere
tosto,complesso,articolato.(guarda caso è proprio ciò che mi è
successo)quale approccio pratico consigli?
Mammuth o Microservices? O nessuno dei due?Od entrambi,modulatima
con quale/i criterio/i pratico/i?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Beri]

2015-09-30 11:03 GMT+02:00 Marco Ippolito :

>
> >> Probabilmente è vero che l'architettura a
> >> microservizi è da adottare quando ulteriori evoluzioni o scale up di
> >> software monolitico diventano troppo
> >> complesse/costose/rischiose/wathever.
> >
> > Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura
> che
> > hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)
> >
> > Ciao.
> > Marco.
>
> Quindi meglio continuare ad ingro/a-ssare il mammuth?
>

Intendo dire che, quando vai dal cliente (o dal tuo manager) e gli dici
"dobbiamo rifare tutto da zero con i microservizi" di norma la risposta è
"mai nella vita".


> Quale approccio pratico consigli?
>

Bella domanda... :-)


-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Ippolito]

>>
>> Probabilmente è vero che l'architettura a
>> microservizi è da adottare quando ulteriori evoluzioni o scale up di
>> software monolitico diventano troppo
>> complesse/costose/rischiose/wathever.
>
>
> Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura che
> hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)
>
> Ciao.
> Marco.
>

Quindi meglio continuare ad ingro/a-ssare il mammuth?
Quale approccio pratico consigli?
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Beri]

On Wed, Sep 30, 2015 at 10:14 AM, Carlo Miron  wrote:

> On Wed, Sep 30, 2015 at 10:01 AM, Marco Beri  wrote:
>
> > La soluzione non la trovo utilizzabile in ambito, per esempio,
> finanziario
> > (ma ammetto di essere ignorante in questo approccio, per questo chiedo un
> > parere qui):
> >
> > "You end up having to use an eventual consistency based approach, which
> is
> > more challenging for developers."
>
> Già, è un bel casino. Dato che non sempre la consistenza eventuale è
> un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
> le complicazioni del caso.



*"The main disadvantage to this algorithm is that it cannot recover in the
event the network is segmented in any manner. The original 3PC algorithm
assumes a fail-stop model, *
*where processes fail by crashing and crashes can be accurately detected,
and does not work with network partitions or asynchronous communication:*

Brrr...


> Probabilmente è vero che l'architettura a
> microservizi è da adottare quando ulteriori evoluzioni o scale up di
> software monolitico diventano troppo
> complesse/costose/rischiose/wathever.
>

Già. Però tutti sanno che, una volta che sei arrivato lì, l'architettura
che hai scelto te la tieni e la manutieni col sudore e con le lacrime :-)

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlo Miron]

On Wed, Sep 30, 2015 at 10:01 AM, Marco Beri  wrote:

> 2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti
> :
>> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>>> [...]
>>> microservice python. Abbiamo copiato un po' da qua
>>> https://www.nginx.com/blog/introduction-to-microservices/
>> link interessante grazie
>
> Uno dei rovesci dell'architettura a microservices che trovo davvero duro da
> digerire è questo:
>
> "Business transactions that update multiple business entities are fairly
> common. These kinds of transactions are trivial to implement in a monolithic
> application because there is a single database. In a microservices-based
> application, however, you need to update multiple databases owned by
> different services. Using distributed transactions is usually not an option,
> and not only because of the CAP theorem. They simply are not supported by
> many of today’s highly scalable NoSQL databases and messaging brokers."
>
> La soluzione non la trovo utilizzabile in ambito, per esempio, finanziario
> (ma ammetto di essere ignorante in questo approccio, per questo chiedo un
> parere qui):
>
> "You end up having to use an eventual consistency based approach, which is
> more challenging for developers."

Già, è un bel casino. Dato che non sempre la consistenza eventuale è
un opzione, obbliga ad utilizzare approcci tipo il [3PC][¹], con tutte
le complicazioni del caso. Probabilmente è vero che l'architettura a
microservizi è da adottare quando ulteriori evoluzioni o scale up di
software monolitico diventano troppo
complesse/costose/rischiose/wathever.

㎝

[¹]: 

PS: @MarcoP non mi hai convinto (ma probabilmente è impossibile, temo
di essere assolutamente refrattario ;) che JS lato server sia una
buona idea, sorry :P

-- 
|:**THE BEER-WARE LICENSE** (*Revision 42*):
|  wrote this mail. As long as you retain
| this notice you can do whatever you want with this stuff.
| If we meet some day, and you think this stuff is worth it,
| you can buy me a beer in return.
|--Carlo Miron :
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Marco Beri]

2015-09-29 8:41 GMT+02:00 Riccardo Magliocchetti <
riccardo.magliocche...@gmail.com>:

> Il 28/09/2015 21:43, Marco Paolini ha scritto:
>>
>> Uso python. Ultimamente stiamo mettendo su una architettura microservice
>> che
>> prevede API gateway piccolissimo in node che fa il dispatch, dietro ci
>> sono i
>> microservice python. Abbiamo copiato un po' da qua
>> https://www.nginx.com/blog/introduction-to-microservices/
>>
>
> link interessante grazie


Uno dei rovesci dell'architettura a microservices che trovo davvero duro da
digerire è questo:

*"Business transactions that update multiple business entities are fairly
common. These kinds of transactions are trivial to implement in a
monolithic application because there is a single database. In a
microservices-based application, however, you need to update multiple
databases owned by different services. Using distributed transactions is
usually not an option, and not only because of the CAP theorem. They simply
are not supported by many of today’s highly scalable NoSQL databases and
messaging brokers."*

La soluzione non la trovo utilizzabile in ambito, per esempio, finanziario
(ma ammetto di essere ignorante in questo approccio, per questo chiedo un
parere qui):

*"You end up having to use an eventual consistency based approach, which is
more challenging for developers."*

Ciao.
Marco.

-- 
http://beri.it/ - Un blog
http://beri.it/i-miei-libri/ - Qualche libro
http://beri.it/articoli/ - Qualche articolo
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlos Catucci]

2015-09-30 1:03 GMT+02:00 Giovanni Porcari :

> Abbastanza curioso come procedimento e in questo caso il server si fa
> carico di una parte di lavoro che sarebbe fattibile dal client con il
> vantaggio di distribuire questo lavoro sulle risorse di elaborazione dei
> client invece che affidare la renderizzazione al server.


Infatti il motivo per cui ancora non ho approcciato node e' questo. la
tentazione di usarlo per fare del multi-process diciamo, cioe' per quelle
cose che Python non fa o fa con fatica, la vrei avuta. Lo so posso usare
Go, o altri linguaggi che lo fanno bene, ma JS e' un linguggio (un male?)
conosciuto, ho meno rischi di scrivere cazzate per poca conoscenza del
linguaggio (quella di scriverle per miei fault e' una cosa differente).
Eppure non riesco a decidermi a mettere js sul server (tranne che come
dipnedenza di qualcosa appunto, come dice Riko).

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

Re: [Python] [graphql] interessante alternativa/evoluzione rispetto al REST

[Carlos Catucci]

2015-09-30 2:40 GMT+02:00 enrico franchi :

> E, sfortunatamente, sara' colpa di troppe fatte male, ma tendo ad odiare
> le single page apps.
>

Potresti illustrare le cose fatte male nelle Single Page Apps? Io le trovo
comode, almeno intendo quelle dove la parte dinamica della pagna cambia
tramite callback REST ajax, senza dover ricaricaricare (inutilmente?) anche
parti gia' caricate nella pagina precedente. Sopratutto se hai una
connessione non brillantissima (problema che ha ancora una parte davvero
grande della popolazione mondiale sebbene chi lavori nel settore sia
abituato a velocita' almeno decenti).

Se invece intendi la moda di avere la pagina enorme che scrolla in
verticale devo dire che la trovo poco fruibile su computer. Capisco che su
device mobile/touch possano avere il loro perche', ma su PC no. E visto che
si puo' sapere con cosa fai la richiesta (OS, browser e relative versioni)
fare dei CSS adattativi non mi sembra impossibile.

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