Multiculturalismo a Bruxelles
Ad
https://www.davidicke.com/article/513643/firemen-flee-attacked-migrant-youths-multicultural-molenbeek
“They call us for small fires and attack us while we want to help.”
Scritto da: altg
> > > Col segnalatore e gli swarowskini, elegante per micette di classe.
> > >
> > > https://scontent-mxp1-1.xx.fbcdn.net/v/t31.0-8/179...
> > >
> > > https://scontent-mxp1-1.xx.fbcdn.net/v/t31.0-8/179...
> > >
> > > https://scontent-mxp1-1.xx.fbcdn.net/v/t31.0-8/179...
> > >
> > > Di sotto c'è una fessura per estrarre e reinserire il segnalatore, e cambiare la batteria, che però non arriverà mai a fine vita perché lo perderà molto prima. Di solito succede così.
> > >
> > > Sto per tirare l'icoso nel mvro.
> > > Devo passare alla tastiera vera.
> >
> > Quanto l'hai pagato quel coso?
>
> 99 sterline per 4 segnalatori e l'handset (cioe` l'aggeggio per ritrovare i segnalatori).
> Si chiama "tabcat". Se lo Googli lo trovi.
>
> > Hai dovuto programmarlo o era già programmato?
>
> Gia` programmato.
>
> > Riusciresti a metterlo nel telaio di una bici? Quanto dura la batteria?
>
> La batteria in standby dura probabilmente intorno a un anno, ma se dovessi mettere qualcosa su una bici per ritrovarla dopo un furto, immagino sarebbe molto meglio uno di quei minuscoli GPS cinesi che ti mandano le coordinate geografiche via SMS sfruttando le reti di telefonia mobile. Quell'aggeggio serve per ritrovare gatti che vagano in paese, ha una portata molto limitata (da qualche decina di metri tra edifici, fino a un massimo di 120 metri in un campo aperto). Improbabile per ritrovare una bici rubata.
Dovresti comprare un cellulare ai gatti, ed insegnare loro a chiamarti ogni tanto per non farti preoccupare.
> > > Col segnalatore e gli swarowskini, elegante per micette di classe.

> > >
> > > https://scontent-mxp1-1.xx.fbcdn.net/v/t31.0-8/179...

> > >
> > > https://scontent-mxp1-1.xx.fbcdn.net/v/t31.0-8/179...

> > >
> > > https://scontent-mxp1-1.xx.fbcdn.net/v/t31.0-8/179...

> > >
> > > Di sotto c'è una fessura per estrarre e reinserire il segnalatore, e cambiare la batteria, che però non arriverà mai a fine vita perché lo perderà molto prima. Di solito succede così.
> > >
> > > Sto per tirare l'icoso nel mvro.
> > > Devo passare alla tastiera vera.
> >
> > Quanto l'hai pagato quel coso?
>
> 99 sterline per 4 segnalatori e l'handset (cioe` l'aggeggio per ritrovare i segnalatori).
> Si chiama "tabcat". Se lo Googli lo trovi.
>
> > Hai dovuto programmarlo o era già programmato?
>
> Gia` programmato.
>
> > Riusciresti a metterlo nel telaio di una bici? Quanto dura la batteria?
>
> La batteria in standby dura probabilmente intorno a un anno, ma se dovessi mettere qualcosa su una bici per ritrovarla dopo un furto, immagino sarebbe molto meglio uno di quei minuscoli GPS cinesi che ti mandano le coordinate geografiche via SMS sfruttando le reti di telefonia mobile. Quell'aggeggio serve per ritrovare gatti che vagano in paese, ha una portata molto limitata (da qualche decina di metri tra edifici, fino a un massimo di 120 metri in un campo aperto). Improbabile per ritrovare una bici rubata.

Dovresti comprare un cellulare ai gatti, ed insegnare loro a chiamarti ogni tanto per non farti preoccupare.
Young professional woman and busy mom.
Scritto da:
> Scritto da:
> > Scritto da: ::1
> > > https://krikienoid.github.io/flagwaver/
> >
> > non funziona se carico due file con url da la bandiera sempre bianca
>
> bello funziona si può salvare l'url specifico? non mi pare
Quando metti una url ti modifica l'indirizzo:
https://krikienoid.github.io/flagwaver/#?src=https...
Puoi anche salvare le impostazioni avanzate di vento.
> Scritto da:
> > Scritto da: ::1
> > > https://krikienoid.github.io/flagwaver/

> >
> > non funziona se carico due file con url da la bandiera sempre bianca
>
> bello funziona si può salvare l'url specifico? non mi pare
Quando metti una url ti modifica l'indirizzo:
https://krikienoid.github.io/flagwaver/#?src=https...

Puoi anche salvare le impostazioni avanzate di vento.
Young professional woman and busy mom.
Scritto da: altg
> Non mi succedeva da anni, e invece stamani mi son svegliato e bella ciao bella ciao bella ciao ciao ciao stamattina mi son svegliato e ho trovato un gran dolor.
>
> Ho preso due bustine di nimesulide.
> Va meglio, il problema e' muscolare, se no avevo gia' pensato alle iniezioni di WD-40 (anche noto come acido ialuronico).
>
> Appropo' per la schiena di avve: provato l'ozonoterapia?
> La mia mamma ci s'e' rimessa a nuovo, con quella.
Nun c'hai più er fisico.
> Non mi succedeva da anni, e invece stamani mi son svegliato e bella ciao bella ciao bella ciao ciao ciao stamattina mi son svegliato e ho trovato un gran dolor.
>
> Ho preso due bustine di nimesulide.
> Va meglio, il problema e' muscolare, se no avevo gia' pensato alle iniezioni di WD-40 (anche noto come acido ialuronico).
>
> Appropo' per la schiena di avve: provato l'ozonoterapia?
> La mia mamma ci s'e' rimessa a nuovo, con quella.
Nun c'hai più er fisico.
Young professional woman and busy mom.
Scritto da:
> Mi sono accorto che l'avviso di connessione non sicura è una cosa del browser (Firefox) perché compare anche con il forum. Se scrivo qualcosa nelle caselle per il login appare il messaggio. Suppongo che l'action punti a un URL https, o no? Non avevi un certificato gratuito?
Il forum è visualizzabile sia in http che in https. Se visiti il sito in http tutti i form vengono passati in http, per questo firefox ti avverte.
> Mi sono accorto che l'avviso di connessione non sicura è una cosa del browser (Firefox) perché compare anche con il forum. Se scrivo qualcosa nelle caselle per il login appare il messaggio. Suppongo che l'action punti a un URL https, o no? Non avevi un certificato gratuito?
Il forum è visualizzabile sia in http che in https. Se visiti il sito in http tutti i form vengono passati in http, per questo firefox ti avverte.
Young professional woman and busy mom.
Proc di Catania
Scritto da:
> Scritto da: SAMURAI
> > Chi è 'sto clone..? E perchè ogni tanto leggo commenti miei non scritti da me? Giambo investiga.....
>
> Perché non ricordi di averli scritti




> Scritto da: SAMURAI
> > Chi è 'sto clone..? E perchè ogni tanto leggo commenti miei non scritti da me? Giambo investiga.....
>
> Perché non ricordi di averli scritti





Young professional woman and busy mom.
Scritto da:
> Scritto da: ::1
> > 7 anni fa abbiamo creato /r/fdt, che è abbandonato praticamente da allora.
> > Tuttavia ha un successone tra gli americani che pensano sia un subreddit "fuck donald trump".
> > È già il secondo che mi scrive in modmail, sono andato a vedere il sub (che senza autorizzazione non è accessibile) ed ha ricevuto oltre 6000 visite negli ultimi 15 minuti.
>
> lol
>
> questo?
https://www.reddit.com/r/fdt 
>
> ma è privato
Avevi anche l'account per entrare, è sempre stato privato.
> Scritto da: ::1
> > 7 anni fa abbiamo creato /r/fdt, che è abbandonato praticamente da allora.
> > Tuttavia ha un successone tra gli americani che pensano sia un subreddit "fuck donald trump".
> > È già il secondo che mi scrive in modmail, sono andato a vedere il sub (che senza autorizzazione non è accessibile) ed ha ricevuto oltre 6000 visite negli ultimi 15 minuti.
>
> lol
>
> questo?

>
> ma è privato

Avevi anche l'account per entrare, è sempre stato privato.
Young professional woman and busy mom.
7 anni fa abbiamo creato /r/fdt, che è abbandonato praticamente da allora.
Tuttavia ha un successone tra gli americani che pensano sia un subreddit "fuck donald trump".
È già il secondo che mi scrive in modmail, sono andato a vedere il sub (che senza autorizzazione non è accessibile) ed ha ricevuto oltre 6000 visite negli ultimi 15 minuti.
Tuttavia ha un successone tra gli americani che pensano sia un subreddit "fuck donald trump".
È già il secondo che mi scrive in modmail, sono andato a vedere il sub (che senza autorizzazione non è accessibile) ed ha ricevuto oltre 6000 visite negli ultimi 15 minuti.
Young professional woman and busy mom.
Scritto da: Wakko Warner
> Scritto da: ::1
> > Scritto da: Wakko Warner
> > > Scritto da: avvelentani
> > > > > Il punto degli async-await è quello di permetterti di scrivere codice più chiaro e comprensibile.
> > > >
> > > > Le chiamate bloccanti erano ancora piu` semplici.
> > >
> > > Nessuno lo mette in dubbio, ma appunto il compito delle async-await è far ritornare il codice leggibile come quando si usavano le chiamate bloccanti senza però rinunciare ai vantaggi delle chiamate non bloccanti.
> > >
> > > Per esempio, su IIS viene riservato un certo pool di thread per gestire le richieste, facciamo finta che siano 2000 giusto per dare un numero.
> > > Questi thread vengono messi in un pool di thread inattivi pronti ad essere assegnati alle varie richieste in ingresso.
> > >
> > > Ora immagina di avere nel tuo codice una chiamata bloccante per, chessò, fare una certa operazione su un grosso numero di righe in un database che impiega 10 secondi per eseguirsi. Questo significa che per 10 secondi interi quel thread è mantenuto occupato inutilmente in attesa di una risposta mentre il database (che è un processo esterno) fa quello che deve fare.
> > >
> > > Immagina ora che questo sito sia un grosso sito, utilizzato da migliaia di persone ogni secondo... e che molti di loro debbano fare operazioni simili sui dati. Arriverai al punto in cui molti di questi thread sono bloccati e il server web, raggiunti i 2000 thread occupati, non potrà fare altro che dare errore all'utente che sta cercando di avviare una nuova richiesta perché non ci sono thread disponibili a servirlo.
> > >
> > > Con le async-await questo problema non succede perché il thread non resta occupato ad aspettare una risposta, quello che stava facendo quel thread viene momentaneamente sospeso in attesa di una risposta dal database e il thread viene rimesso nel pool dei thread disponibili per accettare nuove connessioni. Quindi ora non stai sprecando risorse inutilmente in attesa di qualcosa su cui non hai alcun controllo.
> > >
> > > Ho fatto l'esempio del database ma potrebbe essere qualunque cosa... l'accesso ad un file sul filesystem, la chiamata di una API su un server di terze parti, ecc.
> > >
> > > Il punto è che le chiamate bloccanti sono più semplici, ma in alcuni casi non ce le possiamo permettere. Invece di usare callback incomprensibili si usano gli async-await e noi sviluppatori siamo felici perché capiamo quello che stiamo facendo e pure il cliente è felice perché il software funziona meglio.
> >
> > A me async/await non piace come sintassi, perché nasconde al programmatore il fatto che il metodo viene spezzato.
>
> E perché ti importa? È una cosa di cui si occupa il compilatore, non devi occupartene tu. Ti poni tutti questi problemi anche circa come il compilatore compila il tuo codice in assembly? Non credo... dai per scontato che lo faccia correttamente... non vai certo a verificare se ha azzerato la tua variabile con un assegnamento o uno xor con se stesso.
>
> Metti ora sul piatto i vantaggi che async/await ti danno, in primis la facilità di ragionare sul codice, di capirlo, mantenerlo, ecc.
>
> IMO più è la macchina ad occuparsi dei dettagli e più sono sicuro che il codice faccia esattamente quello che voglio faccia, meno codice scrivo e più sono sicuro di non aver introdotto bug, più facile il codice è da leggere e meno mi fa diventare matto e fa perdere tempo. Al cliente non glie ne frega nulla di come hai raggiunto il risultato, a lui interessa che il risultato sia quello che si aspettava, che abbia meno bug possibili ed ottenerlo nel più breve tempo possibile.
>
> Se io e te facciamo lo stesso software ma tu impieghi 1 mese e 3000 euro in più di me per farglielo, da chi credi lo comprerà? Alla fine a te sviluppatore interessa guadagnare con meno sforzo possibile (che è poi quello che interessa tutti) e il tuo cliente avere quello che ha chiesto il prima possibile pagandolo il meno possibile.
>
> Non so te, ma io do un alto valore al mio tempo e preferisco avere più tempo libero possibile. Impiegare il mio tempo decifrando quello che succede in mille mila callback annidiate non è il modo in cui preferisco passare il mio tempo né tantomeno mi piace stare a spaccarmi la testa su problemi che si possono evitare interamente.
>
> > Il problema degli stacktrace in codice non-blocking si risolve solo parcheggiando il vecchio stack da qualche parte, ma non è una cosa gratuita, e la soluzione microsoftara è l'unica percorribile (mi dici quanti stack frames ti servono e te li tengo).
>
> Non è gratuito, ma non ti importa, è un lavoro che fa il tuo strumento di sviluppo in fase di debug e ti rende più semplice la vita. Perché lamentarsene?
Il codice non devi solo scriverlo, ma anche mantenerlo; significa anche leggere uno stralcio di log tra 5-10 anni e capire cosa fa e seguire il percorso nel codice. Uno stacktrace interrotto o parziale è la cosa peggiore che ti può capitare se non hai modo di ricostruire da dove è partita l'invocazione, ed in release ms lo limita perché ha un costo. Il mio lavoro implica spesso leggere stacktrace di codice scritto da altri e capire cosa fare per fixare.
> > Il codice blocking tuttavia non è così drammatico come lo disegni, un'architettura classica con un webserver con i/o asincrono e backend con i/o sincrono funziona bene anche con grandi carichi, soprattutto se il backend ha threadpool dinamici (vedi java e gli executor service); non è ottimale, ma devi stare ad alti numeri di carico per iniziare a preoccupartene (ed a quel punto il management risolve comprando ibm power series… ma questa è un altra storia).
>
> Hai mai provato a sviluppare qualcosa per android? Magari con phonegap dove ogni 3 righe hai una callback? Lì semplicemente non puoi evitarle perché è l'ambiente stesso che non ti offre alternative sincrone. Io l'ho fatto, ed è un'esperienza che preferirei non ripetere. Con i Future le cose un po'si semplificano, ma sono comunque lontane anni luce dalla semplicità dell'await/async.
Ho scritto parecchia roba su nodejs, e senza usare framework esterni l'unica via efficace che ho riscontrato è quella di evitare callback anonime nel codice, portarle fuori e dare un nome alla funzione ed ai parametri.
> Scritto da: ::1
> > Scritto da: Wakko Warner
> > > Scritto da: avvelentani
> > > > > Il punto degli async-await è quello di permetterti di scrivere codice più chiaro e comprensibile.
> > > >
> > > > Le chiamate bloccanti erano ancora piu` semplici.
> > >
> > > Nessuno lo mette in dubbio, ma appunto il compito delle async-await è far ritornare il codice leggibile come quando si usavano le chiamate bloccanti senza però rinunciare ai vantaggi delle chiamate non bloccanti.
> > >
> > > Per esempio, su IIS viene riservato un certo pool di thread per gestire le richieste, facciamo finta che siano 2000 giusto per dare un numero.
> > > Questi thread vengono messi in un pool di thread inattivi pronti ad essere assegnati alle varie richieste in ingresso.
> > >
> > > Ora immagina di avere nel tuo codice una chiamata bloccante per, chessò, fare una certa operazione su un grosso numero di righe in un database che impiega 10 secondi per eseguirsi. Questo significa che per 10 secondi interi quel thread è mantenuto occupato inutilmente in attesa di una risposta mentre il database (che è un processo esterno) fa quello che deve fare.
> > >
> > > Immagina ora che questo sito sia un grosso sito, utilizzato da migliaia di persone ogni secondo... e che molti di loro debbano fare operazioni simili sui dati. Arriverai al punto in cui molti di questi thread sono bloccati e il server web, raggiunti i 2000 thread occupati, non potrà fare altro che dare errore all'utente che sta cercando di avviare una nuova richiesta perché non ci sono thread disponibili a servirlo.
> > >
> > > Con le async-await questo problema non succede perché il thread non resta occupato ad aspettare una risposta, quello che stava facendo quel thread viene momentaneamente sospeso in attesa di una risposta dal database e il thread viene rimesso nel pool dei thread disponibili per accettare nuove connessioni. Quindi ora non stai sprecando risorse inutilmente in attesa di qualcosa su cui non hai alcun controllo.
> > >
> > > Ho fatto l'esempio del database ma potrebbe essere qualunque cosa... l'accesso ad un file sul filesystem, la chiamata di una API su un server di terze parti, ecc.
> > >
> > > Il punto è che le chiamate bloccanti sono più semplici, ma in alcuni casi non ce le possiamo permettere. Invece di usare callback incomprensibili si usano gli async-await e noi sviluppatori siamo felici perché capiamo quello che stiamo facendo e pure il cliente è felice perché il software funziona meglio.
> >
> > A me async/await non piace come sintassi, perché nasconde al programmatore il fatto che il metodo viene spezzato.
>
> E perché ti importa? È una cosa di cui si occupa il compilatore, non devi occupartene tu. Ti poni tutti questi problemi anche circa come il compilatore compila il tuo codice in assembly? Non credo... dai per scontato che lo faccia correttamente... non vai certo a verificare se ha azzerato la tua variabile con un assegnamento o uno xor con se stesso.
>
> Metti ora sul piatto i vantaggi che async/await ti danno, in primis la facilità di ragionare sul codice, di capirlo, mantenerlo, ecc.
>
> IMO più è la macchina ad occuparsi dei dettagli e più sono sicuro che il codice faccia esattamente quello che voglio faccia, meno codice scrivo e più sono sicuro di non aver introdotto bug, più facile il codice è da leggere e meno mi fa diventare matto e fa perdere tempo. Al cliente non glie ne frega nulla di come hai raggiunto il risultato, a lui interessa che il risultato sia quello che si aspettava, che abbia meno bug possibili ed ottenerlo nel più breve tempo possibile.
>
> Se io e te facciamo lo stesso software ma tu impieghi 1 mese e 3000 euro in più di me per farglielo, da chi credi lo comprerà? Alla fine a te sviluppatore interessa guadagnare con meno sforzo possibile (che è poi quello che interessa tutti) e il tuo cliente avere quello che ha chiesto il prima possibile pagandolo il meno possibile.
>
> Non so te, ma io do un alto valore al mio tempo e preferisco avere più tempo libero possibile. Impiegare il mio tempo decifrando quello che succede in mille mila callback annidiate non è il modo in cui preferisco passare il mio tempo né tantomeno mi piace stare a spaccarmi la testa su problemi che si possono evitare interamente.
>
> > Il problema degli stacktrace in codice non-blocking si risolve solo parcheggiando il vecchio stack da qualche parte, ma non è una cosa gratuita, e la soluzione microsoftara è l'unica percorribile (mi dici quanti stack frames ti servono e te li tengo).
>
> Non è gratuito, ma non ti importa, è un lavoro che fa il tuo strumento di sviluppo in fase di debug e ti rende più semplice la vita. Perché lamentarsene?
Il codice non devi solo scriverlo, ma anche mantenerlo; significa anche leggere uno stralcio di log tra 5-10 anni e capire cosa fa e seguire il percorso nel codice. Uno stacktrace interrotto o parziale è la cosa peggiore che ti può capitare se non hai modo di ricostruire da dove è partita l'invocazione, ed in release ms lo limita perché ha un costo. Il mio lavoro implica spesso leggere stacktrace di codice scritto da altri e capire cosa fare per fixare.
> > Il codice blocking tuttavia non è così drammatico come lo disegni, un'architettura classica con un webserver con i/o asincrono e backend con i/o sincrono funziona bene anche con grandi carichi, soprattutto se il backend ha threadpool dinamici (vedi java e gli executor service); non è ottimale, ma devi stare ad alti numeri di carico per iniziare a preoccupartene (ed a quel punto il management risolve comprando ibm power series… ma questa è un altra storia).
>
> Hai mai provato a sviluppare qualcosa per android? Magari con phonegap dove ogni 3 righe hai una callback? Lì semplicemente non puoi evitarle perché è l'ambiente stesso che non ti offre alternative sincrone. Io l'ho fatto, ed è un'esperienza che preferirei non ripetere. Con i Future le cose un po'si semplificano, ma sono comunque lontane anni luce dalla semplicità dell'await/async.
Ho scritto parecchia roba su nodejs, e senza usare framework esterni l'unica via efficace che ho riscontrato è quella di evitare callback anonime nel codice, portarle fuori e dare un nome alla funzione ed ai parametri.
Young professional woman and busy mom.
Scritto da: Wakko Warner
> Scritto da: avvelentani
> > > Il punto degli async-await è quello di permetterti di scrivere codice più chiaro e comprensibile.
> >
> > Le chiamate bloccanti erano ancora piu` semplici.
>
> Nessuno lo mette in dubbio, ma appunto il compito delle async-await è far ritornare il codice leggibile come quando si usavano le chiamate bloccanti senza però rinunciare ai vantaggi delle chiamate non bloccanti.
>
> Per esempio, su IIS viene riservato un certo pool di thread per gestire le richieste, facciamo finta che siano 2000 giusto per dare un numero.
> Questi thread vengono messi in un pool di thread inattivi pronti ad essere assegnati alle varie richieste in ingresso.
>
> Ora immagina di avere nel tuo codice una chiamata bloccante per, chessò, fare una certa operazione su un grosso numero di righe in un database che impiega 10 secondi per eseguirsi. Questo significa che per 10 secondi interi quel thread è mantenuto occupato inutilmente in attesa di una risposta mentre il database (che è un processo esterno) fa quello che deve fare.
>
> Immagina ora che questo sito sia un grosso sito, utilizzato da migliaia di persone ogni secondo... e che molti di loro debbano fare operazioni simili sui dati. Arriverai al punto in cui molti di questi thread sono bloccati e il server web, raggiunti i 2000 thread occupati, non potrà fare altro che dare errore all'utente che sta cercando di avviare una nuova richiesta perché non ci sono thread disponibili a servirlo.
>
> Con le async-await questo problema non succede perché il thread non resta occupato ad aspettare una risposta, quello che stava facendo quel thread viene momentaneamente sospeso in attesa di una risposta dal database e il thread viene rimesso nel pool dei thread disponibili per accettare nuove connessioni. Quindi ora non stai sprecando risorse inutilmente in attesa di qualcosa su cui non hai alcun controllo.
>
> Ho fatto l'esempio del database ma potrebbe essere qualunque cosa... l'accesso ad un file sul filesystem, la chiamata di una API su un server di terze parti, ecc.
>
> Il punto è che le chiamate bloccanti sono più semplici, ma in alcuni casi non ce le possiamo permettere. Invece di usare callback incomprensibili si usano gli async-await e noi sviluppatori siamo felici perché capiamo quello che stiamo facendo e pure il cliente è felice perché il software funziona meglio.
A me async/await non piace come sintassi, perché nasconde al programmatore il fatto che il metodo viene spezzato.
Il problema degli stacktrace in codice non-blocking si risolve solo parcheggiando il vecchio stack da qualche parte, ma non è una cosa gratuita, e la soluzione microsoftara è l'unica percorribile (mi dici quanti stack frames ti servono e te li tengo).
Il codice blocking tuttavia non è così drammatico come lo disegni, un'architettura classica con un webserver con i/o asincrono e backend con i/o sincrono funziona bene anche con grandi carichi, soprattutto se il backend ha threadpool dinamici (vedi java e gli executor service); non è ottimale, ma devi stare ad alti numeri di carico per iniziare a preoccupartene (ed a quel punto il management risolve comprando ibm power series… ma questa è un altra storia).
> Scritto da: avvelentani
> > > Il punto degli async-await è quello di permetterti di scrivere codice più chiaro e comprensibile.
> >
> > Le chiamate bloccanti erano ancora piu` semplici.
>
> Nessuno lo mette in dubbio, ma appunto il compito delle async-await è far ritornare il codice leggibile come quando si usavano le chiamate bloccanti senza però rinunciare ai vantaggi delle chiamate non bloccanti.
>
> Per esempio, su IIS viene riservato un certo pool di thread per gestire le richieste, facciamo finta che siano 2000 giusto per dare un numero.
> Questi thread vengono messi in un pool di thread inattivi pronti ad essere assegnati alle varie richieste in ingresso.
>
> Ora immagina di avere nel tuo codice una chiamata bloccante per, chessò, fare una certa operazione su un grosso numero di righe in un database che impiega 10 secondi per eseguirsi. Questo significa che per 10 secondi interi quel thread è mantenuto occupato inutilmente in attesa di una risposta mentre il database (che è un processo esterno) fa quello che deve fare.
>
> Immagina ora che questo sito sia un grosso sito, utilizzato da migliaia di persone ogni secondo... e che molti di loro debbano fare operazioni simili sui dati. Arriverai al punto in cui molti di questi thread sono bloccati e il server web, raggiunti i 2000 thread occupati, non potrà fare altro che dare errore all'utente che sta cercando di avviare una nuova richiesta perché non ci sono thread disponibili a servirlo.
>
> Con le async-await questo problema non succede perché il thread non resta occupato ad aspettare una risposta, quello che stava facendo quel thread viene momentaneamente sospeso in attesa di una risposta dal database e il thread viene rimesso nel pool dei thread disponibili per accettare nuove connessioni. Quindi ora non stai sprecando risorse inutilmente in attesa di qualcosa su cui non hai alcun controllo.
>
> Ho fatto l'esempio del database ma potrebbe essere qualunque cosa... l'accesso ad un file sul filesystem, la chiamata di una API su un server di terze parti, ecc.
>
> Il punto è che le chiamate bloccanti sono più semplici, ma in alcuni casi non ce le possiamo permettere. Invece di usare callback incomprensibili si usano gli async-await e noi sviluppatori siamo felici perché capiamo quello che stiamo facendo e pure il cliente è felice perché il software funziona meglio.
A me async/await non piace come sintassi, perché nasconde al programmatore il fatto che il metodo viene spezzato.
Il problema degli stacktrace in codice non-blocking si risolve solo parcheggiando il vecchio stack da qualche parte, ma non è una cosa gratuita, e la soluzione microsoftara è l'unica percorribile (mi dici quanti stack frames ti servono e te li tengo).
Il codice blocking tuttavia non è così drammatico come lo disegni, un'architettura classica con un webserver con i/o asincrono e backend con i/o sincrono funziona bene anche con grandi carichi, soprattutto se il backend ha threadpool dinamici (vedi java e gli executor service); non è ottimale, ma devi stare ad alti numeri di carico per iniziare a preoccupartene (ed a quel punto il management risolve comprando ibm power series… ma questa è un altra storia).
Young professional woman and busy mom.
Scritto da: avvelenato
>
http://m.espresso.repubblica.it/plus/articoli/2017... 
>
> Ripostatelo per wakko.
>

>
> Ripostatelo per wakko.
Young professional woman and busy mom.
Pe: Mattia si infila in una live youtube e difende i pedoni
::1 ha spostato in procura questo thread
Young professional woman and busy mom.
Scritto da: avvelentani
> Scritto da: ::1
> > io"
> >
http://www.repubblica.it/politica/2017/04/16/news/... 
>
> > E chi meglio di lui potrebbe far dialogare i due mondi?
>
> dice il giornalista Angelo Quadro mentre si inginocchia e comincia a fare un pompino a Romano Prodi.
…
E di quello che dice sui porti che ne pensi?
> Scritto da: ::1
> > io"
> >

>
> > E chi meglio di lui potrebbe far dialogare i due mondi?
>
> dice il giornalista Angelo Quadro mentre si inginocchia e comincia a fare un pompino a Romano Prodi.
…
E di quello che dice sui porti che ne pensi?
Young professional woman and busy mom.
Scritto da:
> L'autobus di campagna si ferma, una passeggera con la bambina piccola scende.
> L'autobus riparte.
> La bambina muore, si era aggrappata alla ruota anteriore.
> L'autista paga 1800 dollari per mettersi la coscienza apposto.
> Di chi è la colpa?
Dei genitori della bambina. Per quanto crudo possa apparire, dovevano sorvegliarla.
> L'autobus di campagna si ferma, una passeggera con la bambina piccola scende.
> L'autobus riparte.
> La bambina muore, si era aggrappata alla ruota anteriore.
> L'autista paga 1800 dollari per mettersi la coscienza apposto.
> Di chi è la colpa?
Dei genitori della bambina. Per quanto crudo possa apparire, dovevano sorvegliarla.
Young professional woman and busy mom.
Young professional woman and busy mom.
Re: seghe
Scritto da: avvelenato
>
> Comunque è interessante che il thread verteva sull'argomento seghe e siam finiti a parlare di layout delle tastiere.
Nel forum Sesso siamo off topic. Corro a farmi una sega.
>
> Comunque è interessante che il thread verteva sull'argomento seghe e siam finiti a parlare di layout delle tastiere.

Nel forum Sesso siamo off topic. Corro a farmi una sega.
Young professional woman and busy mom.
Scritto da: altg
> Non ne ho la piu` pallida idea, non sono mai stato fisionomista. Hai presente quella teoria che sostiene che l'area del cervello che distingue i volti e` la stessa che distingue i modelli di automobile? Ecco, la mia e` sempre stata bruciata, infatti per me una Fiat 500 e una Yaris sono la stessa cosa, e i volti hanno due occhi, un naso e una bocca. Se almeno qualcuno avesse tre occhi, la cosa mi aiuterebbe.
>
> p.s.
> questo e` il post 11111 di questo account.
> Non ricordo quanti ne avessi con quelli precedenti, ma complessivamente qualcosa tipo altri 5-6 mila.
> Madonna come mi sento vecchio.
>
> **Modificato dall'autore il 17.04.2017 02:23**
Stats time:
> Non ne ho la piu` pallida idea, non sono mai stato fisionomista. Hai presente quella teoria che sostiene che l'area del cervello che distingue i volti e` la stessa che distingue i modelli di automobile? Ecco, la mia e` sempre stata bruciata, infatti per me una Fiat 500 e una Yaris sono la stessa cosa, e i volti hanno due occhi, un naso e una bocca. Se almeno qualcuno avesse tre occhi, la cosa mi aiuterebbe.
>
> p.s.
> questo e` il post 11111 di questo account.
> Non ricordo quanti ne avessi con quelli precedenti, ma complessivamente qualcosa tipo altri 5-6 mila.
> Madonna come mi sento vecchio.
>
> **Modificato dall'autore il 17.04.2017 02:23**
Stats time:
mysql> select author, count(*) from messages where author is not null group by author having count(*) > 2000 order by count(*) desc; +-----------------+----------+ | author | count(*) | +-----------------+----------+ | Giambo | 42920 | | nathan71 | 27559 | | The Lich | 21351 | | avvelentani | 17847 | | exsinistro | 17613 | | avvelenato | 12993 | | ::1 | 11568 | | altg | 11111 | | gengiva | 9088 | | The Animal | 8661 | | Alessandrox | 8658 | | non autenticato | 8283 | | Daisuke Niwa | 6532 | | Wakko Warner | 6124 | | SAMURAI | 5894 | | dada216 | 5467 | | Rin Kobayashi | 5425 | | gian_d | 5131 | | achille97 | 5005 | | Caccola | 4459 | | dada_216 | 4330 | | Suor Dannata | 4147 | | Celeste65 | 3913 | | alex.tg | 3444 | | Ceiling dog | 3307 | | Lich | 3286 | | Alienazione | 3184 | | dfsxsfd | 3068 | | Larry | 3047 | | Ordine Reich 2 | 2971 | | kryptonized | 2737 | | Troll.Psicazzo | 2730 | | Chitto | 2634 | | Donna | 2620 | | Figàro | 2602 | | Fatalmente2 | 2531 | | Avve DeLarge | 2348 | | malvagia | 2240 | | Seu | 2082 | | suoranciata | 2013 | | pentothal | 2005 | | Renton Thurston | 2001 | +-----------------+----------+ 42 rows in set (0.36 sec) mysql>
Young professional woman and busy mom.