Re: [Python] Tutorial su FUSE

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, p

Re: [Python] Tutorial su FUSE

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

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

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 pic

[Python] Tutorial su FUSE

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 fo

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

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, è

[Python] aggiornamento sullo stato di gopy

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

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

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 (mag

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

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 p

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

> 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% > * C

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

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. ;-) Stronzet

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

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 -- EZ

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

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

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

* 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

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

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

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

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-W

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

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][

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

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

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

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, d

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

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 evo

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

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

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

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 Pyt

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

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

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

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,comp

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

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..

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

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 sc

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

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

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

>> >> 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 è succes

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

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 c

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

>> >> 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

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

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): > > > > "Yo

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

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 inter

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

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 >>

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

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 re

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

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