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

[Carlos Catucci]

2015-10-03 16:33 GMT+02:00 Luca Bacchi :

> Questi concetti, che mi pare siano alla base del moderno web design sono
> spiegati molto meglio di quanto io sia in grado di fare in questo articolo
> che vi condivido:


Muchas gracias Luca, molto interessante

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 Paolini (markopaol...@gmail.com) [151002 19:23]:


si dai tranquillo se scoppi per così poco, immagina se ti dico che in python
questa è si chiama funzione:

def ciao():
  db.save('hey')



si, grazie, lo sapevo, molto cortese comunque

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

What to do in case of an alien attack:

1)   Hide beneath the seat of your plane and look away.
2)   Avoid eye contact.
3) If there are no eyes, avoid all contact.

-- The Firesign Theatre, _Everything you know is Wrong_
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Luca Bacchi]

Ciao Carlos. È più o meno quello che intendevo.

Questi concetti, che mi pare siano alla base del moderno web design sono
spiegati molto meglio di quanto io sia in grado di fare in questo articolo
che vi condivido:

http://rauchg.com/2014/7-principles-of-rich-web-applications/

Ciao
Il 03/ott/2015 04:28 PM, "Carlos Catucci"  ha
scritto:

>
> 2015-10-03 16:22 GMT+02:00 Luca Bacchi :
>
>> Proprio nella prima chiamata può avere senso inviare la pagina completa,
>> e non solo un container vuoto da dover poi riempire con successive chiamate
>> Ajax. Può avere senso proprio per ridurre la minimo la latenza, il
>> caricamento dell'applicazione.
>
>
> E allungando i tempi di caricamento. Io da come le vedo caricherei la
> parte visibile all'avvio completa, e a document ready inizierei a prendere
> via ajax i contenuti delle "scatole" sottostanti. Questo almeno se per SPA
> si intende quelle a scrolling verticael. In caso ocntrario ovvio che carico
> tutto, le ajax calls dovrebbero esserci in risposta a eventi particolari
> (es, pressione di un tasto oppure apertura di un menu).
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Notizie dal PyRoma

[Nemesis]

On 10/03/2015 03:36 PM, Massimiliano Pippi wrote:
>
> 2015-10-03 14:52 GMT+02:00 Nemesis  >:
>
>
> Una delle prime cose che abbiamo fatto dopo aver discusso è stata
> creare una board trello per organizzarci meglio:
> https://trello.com/b/c6VREEBQ/pyroma
> L'idea è quella di fare una lista di possibili talk, votarli e poi
> - in base alla disponibilità dello speaker - assegnare il talk ad
> uno degli eventi (per cui stiamo cercando di decidere i giorni con
> largo anticipo).
>
> io non vedo dov'è la card con la mia fantastica idea di fare uno
> sprint su qualsiasi cosa un qualsiasi sabato che *qualcuno*, forse in
> preda ai fumi dell'alcool accolse con estremo favore!
>
> O forse ero ubriaco io, cmq rinnovo la proposta.

Hai ragione, la aggiungo, io vorrei tanto fare uno sprint su
django-hstore per renderlo compatibile con il campo hstore aggiunto
recentemente in django 1.8.

Federico
___
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-10-02 17:29 GMT+01:00 Marco Paolini :

>
>
> Il giorno 2 ottobre 2015 12:42, enrico franchi 
> ha scritto:
>
>>
>> 2015-10-02 7:43 GMT+01:00 Marco Paolini :
>>
>>> Avere nodejs nel proprio stack tecnlologico è quasi una necessità oggi:
>>> hai gratis isomorfismo e rendering server-side di applicazioni single-page.
>>
>>
>> Non mi sembra affatto una necessita'. E' una scelta. Immagino che sia
>> importante per determinate scelte di carriera, ma di qui a chiamarla una
>> "necessita'" ne passa.
>>
>
> Per curiosità, come fai il rendering lato server di una app single page
> angular/ember/react?
>

1. potrei non avere una spa (ancora una volta, e' una moda, non e' un
obbligo; ci sono casi in cui funziona bene, casi in cui funziona male);
come detto prima, non e' una tecnologia che trovo particolarmente simpatica
e che trovo spesso abusata.
2. potrei non avere particolare interesse a fare rendering lato server
(dipende caso per caso quando vinci e quando perdi: ho parecchi use-case
completamente diversi da tenere d'occhio... non trovo una soluzione che va
bene per tutto)
3. per il mio use-case piu' massiccio sfortunatamente sono sotto una pila
di nda. ma diciamo che a naso non mi sembra una soluzione


>
> Secondo me se sviluppi app web è prorio una necessità, perchè nodejs ti
> offre una serie ti tool interessanti per sviluppare app web.
>

Secondo me se sviluppi applicazioni web *non* e' una necessita' (in fatti
non tutti fanno cosi'); magari se sviluppi spa. E anche li, le spa ci sono
da un po' di anni, ma sta cosa del ssr e' relativamente recente. Vedrai che
la tecnologia evolvera' ancora. Ogni 6 mesi esce ualcosa di radicalmente
nuovo/


>
> Lato client è indispensabile, visto che su nodejs si appoggia *tutta* la
> toolchain moderna di un programmatore frontend: grunt/gulp, bower, karma,
> npm...
>

Anche C e' indispensabile perche' ci si basa tutto... ma questo non vuole
dire che devi lavorare in C sebbene dei componenti che ti servono siano
scritti in C.

E poi... programmatore frontend a chi?


> Lato server è estremamente comodo usarlo a fianco (o davanti) l'
> application tier python per fare appunto rendering server-side e sfruttare
> isomorfismo per condividere codice tra client e server.
>

Come dicevo, non c'e' molta speranza che i tentativi di introdurre node.js
in mia presenza non incontrino strenua resistenza.

Poi quando mi mostreranno che non c'e' alternativa ed effettivamente la
cosa non e' un delirio da gestire ne parleremo.

--
..: -enrico-
___
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-10-03 14:49 GMT+02:00 Marco Beri :

> Ho fatto leggere al mio salumiere e non ha capito una mazza... Meno male...


Cavolo ora tutti sanno che sono il tuo salumiere, e cha cazz. ;)

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-10-03 14:53 GMT+02:00 Giovanni Porcari :

> Se avessi chiuso con 'Bazinga' sarebbe stato perfetto ;)


+1

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

[Marco Beri]

On Oct 3, 2015 1:56 PM, "enrico franchi"  wrote:
>
> Ma poi il tutto e' surreale. In algebra, per dirla al salumiere, un
isomorfismo e' una mappa che mantiene "struttura" fra due enti algebrici
*e* che sia invertibile.

Ho fatto leggere al mio salumiere e non ha capito una mazza... Meno male...

Ciao.
Marco.
P.s. Avrei pure preso 26 all'esame di algebra... Non mi ricordo più una
mazza...
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

Re: [Python] Notizie dal PyRoma

[Massimiliano Pippi]

Aò,

2015-10-03 14:52 GMT+02:00 Nemesis :

>
> Una delle prime cose che abbiamo fatto dopo aver discusso è stata creare
> una board trello per organizzarci meglio:
> https://trello.com/b/c6VREEBQ/pyroma
> L'idea è quella di fare una lista di possibili talk, votarli e poi - in
> base alla disponibilità dello speaker - assegnare il talk ad uno degli
> eventi (per cui stiamo cercando di decidere i giorni con largo anticipo).
>
> io non vedo dov'è la card con la mia fantastica idea di fare uno sprint su
qualsiasi cosa un qualsiasi sabato che *qualcuno*, forse in preda ai fumi
dell'alcool accolse con estremo favore!

O forse ero ubriaco io, cmq rinnovo la proposta.

-- 
M.

@maxpippi :: http://dev.pippi.im/
___
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-10-03 16:22 GMT+02:00 Luca Bacchi :

> Proprio nella prima chiamata può avere senso inviare la pagina completa, e
> non solo un container vuoto da dover poi riempire con successive chiamate
> Ajax. Può avere senso proprio per ridurre la minimo la latenza, il
> caricamento dell'applicazione.


E allungando i tempi di caricamento. Io da come le vedo caricherei la parte
visibile all'avvio completa, e a document ready inizierei a prendere via
ajax i contenuti delle "scatole" sottostanti. Questo almeno se per SPA si
intende quelle a scrolling verticael. In caso ocntrario ovvio che carico
tutto, le ajax calls dovrebbero esserci in risposta a eventi particolari
(es, pressione di un tasto oppure apertura di un menu).

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

[enrico franchi]

2015-10-02 18:10 GMT+01:00 m :

> sono l'unico a cui sta sul cazzo[1] il fatto che la parola 'isomorfismo',
> che ha un significato preciso in matematica, sia stata presa e usata a
> sproposito ?
>

No. Non sei l'unico. Ad essere sinceri anche nella community il termine non
piace a molti e cercano alternative.
Tra l'altro... si, il termine e' mal scelto; ma mi sta facendo divertire un
mondo... tipo ho acchiappato il post di Rauschmeyer sull'argomento, in cui
tenta di spiegare che si, isomorfismo e' un buon termine per affinita' con
"il concetto topologico di ismorfismo". A questo punto spara la definizione
di isomorfismo in topologia... ed e' sbagliata. Di brutto: tipo sembra
ignorare il punto chiave di essere un'isomorfismo in topologia (altrimenti
detto omeomorfismo), che e' un concetto in un certo senso molto piu' forte
-- dal concetto di isomorfismo in algebra.

Ma poi il tutto e' surreale. In algebra, per dirla al salumiere, un
isomorfismo e' una mappa che mantiene "struttura" fra due enti algebrici
*e* che sia invertibile. Ovviamente, parlare di Javascript *isomorfico* e'
strano: di solito dici che *due* (o piu' cose) sono isomorfe o che *un*
ente (che appunto e' una funzione) e' un'isomorfismo. "Isomorphic
Javascript" non ha particolarmente senso: se hai un solo elemento nel
discorso, grazie tante ... A e' isomorfo ad A. Ma comunque... l'altro pezzo
interessante e' che la mappa e' invertibile. Questo lascia pensare ad un
rapporto biunivoco fra le due cose. Ora io non sono un esperto di sto
"ismorphic javascript", ma l'ultima volta che ho controllato e' vero che di
fatto convinci il server ad essere un client... ma non mi risulta che tutto
quello che fai sul server possa essere fatto sul client. Il che vuole dire,
che non c'e' nulla di "isomorfo": la parte chiave del concetto e'
l'invertibilita', che io non vedo.

Ah, solo per completezza, sudetto Rauschmeyer e' piu' specifico:
isomorfismo come isomorfismo topologico. Non gli basta quello algebrico,
apparentemente. Vuole proprio quello topologico. Ora, il problema e' che in
topologia gli isomorfismi sono funzioni topologicamente continue (su spazi
topologici). Ah, sempre invertibili, ovviamente. Il che quando mi dice
isomorphic javascript vorrei capire se intende che javascript e' uno spazio
topologico (il linguaggio [0]) o se intende dire che Javascript dovrebbe
essere una funzione continua fra non so cosa.

Comunque si... e' techno babble: qualcuno ha perso termini altisonanti e li
sta usando a sproposito. E' un po' come quando nei film parlando di
informatica mettono insieme termini a caso per simulare un discorso tecnico.



---
[0] ora studiare spazi topologici di linguaggi (come enti matematici) e'
piuttosto interessante; sfortunatamente un linguaggio che possa essere
gestito da un computer deve essere ricorsivamente enumerabile, il che lo
rende un ente relativamente semplice di cui non e' eccessivamente
interessante fare uno studio dal punto di vista topologico...








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

Re: [Python] [PyRoma] Notizie dal PyRoma

[Simone Federici]

chi propone si impega :-)
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Luca Bacchi]

Le SPA tipicamente ricevono dal server degli oggetti JSON che devono
renderizzare lato client con un motore di templating JavaScript tipo quelli
che avete citato sopra.

Tipicamente la SPA non riceve dal server pagine HTML, tranne nella prima
chiamata, ovviamente.

Proprio nella prima chiamata può avere senso inviare la pagina completa, e
non solo un container vuoto da dover poi riempire con successive chiamate
Ajax. Può avere senso proprio per ridurre la minimo la latenza, il
caricamento dell'applicazione.

È in questo passaggio che probabilmente si può riutilizzare lo stesso
codice di rendering, lato server e lato client.

Non credo che sia una cazzata o una moda. Credo che grossomodo le SPA
vadano più o meno fatte in questo modo.

Il giorno 3 ottobre 2015 15:24, Carlos Catucci 
ha scritto:

>
> 2015-10-03 14:53 GMT+02:00 Giovanni Porcari 
> :
>
>> Se avessi chiuso con 'Bazinga' sarebbe stato perfetto ;)
>
>
> +1
>
> Carlos
> --
> EZLN ... Para Todos Todo ... Nada para nosotros
>
> ___
> Python mailing list
> Python@lists.python.it
> http://lists.python.it/mailman/listinfo/python
>
>
___
Python mailing list
Python@lists.python.it
http://lists.python.it/mailman/listinfo/python

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

[Giovanni Porcari]

> Il giorno 03 ott 2015, alle ore 13:56, enrico franchi 
>  ha scritto:
> 
> 
> 2015-10-02 18:10 GMT+01:00 m :
> sono l'unico a cui sta sul cazzo[1] il fatto che la parola 'isomorfismo',
> che ha un significato preciso in matematica, sia stata presa e usata a
> sproposito ?
> 
> No. Non sei l'unico. Ad essere sinceri anche nella community il termine non 
> piace a molti e cercano alternative.
> Tra l'altro... si, il termine e' mal scelto; ma mi sta facendo divertire un 
> mondo... tipo ho acchiappato il post di Rauschmeyer sull'argomento, in cui 
> tenta di spiegare che si, isomorfismo e' un buon termine per affinita' con 
> "il concetto topologico di ismorfismo". A questo punto spara la definizione 
> di isomorfismo in topologia... ed e' sbagliata. Di brutto: tipo sembra 
> ignorare il punto chiave di essere un'isomorfismo in topologia (altrimenti 
> detto omeomorfismo), che e' un concetto in un certo senso molto piu' forte -- 
> dal concetto di isomorfismo in algebra.
> 
> Ma poi il tutto e' surreale. In algebra, per dirla al salumiere, un 
> isomorfismo e' una mappa che mantiene "struttura" fra due enti algebrici *e* 
> che sia invertibile. Ovviamente, parlare di Javascript *isomorfico* e' 
> strano: di solito dici che *due* (o piu' cose) sono isomorfe o che *un* ente 
> (che appunto e' una funzione) e' un'isomorfismo. "Isomorphic Javascript" non 
> ha particolarmente senso: se hai un solo elemento nel discorso, grazie tante 
> ... A e' isomorfo ad A. Ma comunque... l'altro pezzo interessante e' che la 
> mappa e' invertibile. Questo lascia pensare ad un rapporto biunivoco fra le 
> due cose. Ora io non sono un esperto di sto "ismorphic javascript", ma 
> l'ultima volta che ho controllato e' vero che di fatto convinci il server ad 
> essere un client... ma non mi risulta che tutto quello che fai sul server 
> possa essere fatto sul client. Il che vuole dire, che non c'e' nulla di 
> "isomorfo": la parte chiave del concetto e' l'invertibilita', che io non vedo.
> 
> Ah, solo per completezza, sudetto Rauschmeyer e' piu' specifico: isomorfismo 
> come isomorfismo topologico. Non gli basta quello algebrico, apparentemente. 
> Vuole proprio quello topologico. Ora, il problema e' che in topologia gli 
> isomorfismi sono funzioni topologicamente continue (su spazi topologici). Ah, 
> sempre invertibili, ovviamente. Il che quando mi dice isomorphic javascript 
> vorrei capire se intende che javascript e' uno spazio topologico (il 
> linguaggio [0]) o se intende dire che Javascript dovrebbe essere una funzione 
> continua fra non so cosa.
> 
> Comunque si... e' techno babble: qualcuno ha perso termini altisonanti e li 
> sta usando a sproposito. E' un po' come quando nei film parlando di 
> informatica mettono insieme termini a caso per simulare un discorso tecnico.
> 
> 
> 
> ---
> [0] ora studiare spazi topologici di linguaggi (come enti matematici) e' 
> piuttosto interessante; sfortunatamente un linguaggio che possa essere 
> gestito da un computer deve essere ricorsivamente enumerabile, il che lo 
> rende un ente relativamente semplice di cui non e' eccessivamente 
> interessante fare uno studio dal punto di vista topologico... 
> 
> 
> 
> 


Se avessi chiuso con 'Bazinga' sarebbe stato perfetto ;)

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

[Python] Notizie dal PyRoma

[Nemesis]

Ciao a tutti,

non so se ricordate che da poco più di un anno stiamo portando avanti un
python user group a Roma, non senza difficoltà dato che siamo tutti
sempremolto indaffarati.

La volta scorsa abbiamo fatto una retrospettiva, per capire cosa è
andato bene, cosa no, e come migliorare.
Se vi interessa potete leggere di più al riguardo qui:
http://lists.python.it/pipermail/pyroma/2015-September/000424.html

Una delle prime cose che abbiamo fatto dopo aver discusso è stata creare
una board trello per organizzarci meglio:
https://trello.com/b/c6VREEBQ/pyroma
L'idea è quella di fare una lista di possibili talk, votarli e poi - in
base alla disponibilità dello speaker - assegnare il talk ad uno degli
eventi (per cui stiamo cercando di decidere i giorni con largo anticipo).

Abbiamo anche un account twitter qui:
https://twitter.com/pyroma

Sperando che questa mail sia stata gradita, porgo i miei "migliorissimi"
saluti :-)

Federico

PS: per chi sarà a DjangoUnderTheHood, ci vediamo lì!


___
PyRoma mailing list
pyr...@lists.python.it
http://lists.python.it/mailman/listinfo/pyroma

___
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-10-03 13:49 GMT+01:00 Marco Beri :

> Ho fatto leggere al mio salumiere e non ha capito una mazza... Meno male...
>
Ah... non fanno piu' i salumieri di una volta...


> P.s. Avrei pure preso 26 all'esame di algebra... Non mi ricordo più una
> mazza...
>

E' probabile che voi chiamaste algebra quella che normalmente si chiama
algebra lineare. Che e' una cosa abbastanza diversa (o meglio, quando si fa
*anche* algebra si trova la connessione)


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