/purupuru/ Kore wa Inbou da! #nipponerds

[Haruki]

kenpufa- 12

the whole thing was so fk'd up

fixed

[wxyz]

>poche risorse
>multipiattaforma

applicativi via web is the way alla maniera di Google, per intenderci.

non applicabile in questo caso, per vari motivi:

- le webapp sono lente (nel senso della latenza) e pesanti rispetto ad un'implementazione non web, sopratutto se devi gestire uno stato applicativo complesso e non hai reale necessità di usare quella caterva di standard

- anche la piattaforma è "sbagliata", stanno cercando di porci rimedio (websockets ecc) ma ora come ora il modello rpc asincrono è troppo limitante ed i browser non hanno un comportamento realmente utile (solo ora justcompilano js, ancora male il threading, integrazione con il desktop inesistente o quasi); hai poco controllo delle condizioni di esecuzione (non funziona più! ah, adobe ha cambiato quel dettaglio dell'implementazione del player..., ah, ma cià greasemonkey.... ecc)

- gli standard del w3c sono interessanti ma bloated, anche se pochi se ne vogliono rendere conto; la stessa google a più riprese ha tentato di metterci pezze (es internamente col cavolo che usano webservices, usano da anni i loro protocol buffers), ma non c'è gente che li ascolti davvero.

- in termini di prestazioni c'è anche una cospicua differenza fra applicazione networked e non networked, non sempre è necessario passare su rete, sopratutto se non vuoi sviluppare un'applicazione client server tipo anni 70, ed io non voglio

- i web server controllano loro la situazione e la webapp subisce, io voglio fare al limite il contrario, quindi o embeddo il web server nell'applicativo o ciccia, quindi dovrei comuqnuei sviluppare un bel pò al solo scopo di. nah.

- un browser in esecuzione occupa anche 256 mega e rotti (appena controllato). nah.

E poi caro mio, le risorse deve saperle gestire meglio il programmatore che il sistemista. Se il programmatore non sa gestire bene le risorse è semplicemente un niubbo. Altrimenti perché favorire programmatori bravi con gli algoritmi?

su questo non ci piove (al limite ci nevica), ma le misurazioni del caso tradizionalmente non le fanno i programmatori ma congiuntamente il team di sviluppo (che non coincide con i programmatori), il team di testing ed i sistemisti, e non è un caso.

java (in genere i runtime con garbage collector mark & sweep) di fatto tendono a toglierti il controllo sul reclaim delle risorse, per questo il c++ ha un vantaggio netto su questi aspetti, ma al prezzo di saperlo usare (come dicevi) E di scegliere bene il toolkit e le librerie. le qt sono definite ottime da più parti, così come anche boost, il punto è che a me non interessa il parere comune voglio sapere cosa possono fare per me. ed io programmatore non so dirlo finchè non misuro.

ribadisco, ti assicuro che di fatto i programmatori non sono più in condizioni di sapere come vanno i loro programmi per questioni di risorse.

ho programmato sistemi anche "bare metal" (senza sistema operativo e senza librerie) - e ti assicuro che quella è l'unica situazione in cui *a volte* puoi disegnare la gestione delle risorse senza effettuare misurazioni a priori. a volte.

[Haruki]

wxyz se ti aspetti che io legga tutto quel wall of text stai fresco, fammi un riassunto

@purupuru #tokyotosho La libreria ha chiuso i battenti.

[Bl@ck]

tl;dr

[Stanislao]

però io ho giocato a palle di neve completamente ubriaca e voi no

Io ho fatto sgommate per dieci minuti in un parcheggio completamente sobrio e voi no

[Haruki]

http://www.youtube.com/watch?v=Z0RS_we5oy0

In This Video: japanese studio aperto discovering the internet.

[DT84]

Appena visto in Germano.

Voalletto.

[Haruki]

adieu

[Valfuindor la Maia]

attenzione però (vale per entrambi ), la domanda non era su questioni di programmazione ma piuttosto di impiego di risorse.

in questo caso la gara era fra le strutture dati di libreria qt (e la loro gestione interna) ed il gc di java, sul lungo periodo. è più facile che il comportamento tipico l'abbia notato un sistemista (anche per i cavoli suoi) che un programmatore. [cut]

il problema è avere avuto a che fare, in qualsiasi modo, con ambienti di sviluppo. non avendo mai programmato in prima persona, diventa un po' difficile dare una risposta così a naso
dovrei leggermi la documentazione, ma già ho poco tempo di mio...

ohayo

[wxyz]

wxyz se ti aspetti che io legga tutto quel wall of text stai fresco, fammi un riassunto

la domanda era diretta non alla programmazione o di design ma alle risorse così come consumate realmente a runtime, ed è una cosa molto diversa; chi programma oggi - se non in condizioni estreme e particolari - non può più essere sicuro di controllare le risorse che usa, ad esempio per librerie e componenti deve trovare riscontri osservando il comportamento reale, ed in genere non ha occasione di farlo per vari motivi.

le applicazioni web sono tutt'altro che leggere, e comunque la piattaforma così come è oggi fa cacà .

uhhhuuu un ... bah penso una merla ha appena trovato riparo dalla neve sul mio terrazzo :puchuuuu:

certo che pensare che una settimana fa stavo passeggiando sulla spiaggia

giorno

[Valfuindor la Maia]

l'omino delle caldaie è in ritardo di 45' ed io mi sono svegliata alle 6:30 per sistemare casa

[wxyz]

l'omino delle caldaie è in ritardo di 45' ed io mi sono svegliata alle 6:30 per sistemare casa

?

[Zakaria]

@purupuru #tokyotosho La libreria ha chiuso i battenti.

Fuck.

wxyz: hai qualche link che spieghi un attimo sta storia degli standard web bloated, per favore?

[wxyz]

li avevo, ma non più; in ogni caso mi imbatto in questo tipo di considerazioni anche girellando su stackoverflow.com (è molto ben navigabile anche per tag) o wikipedia.

il sunto è: sono text-based e quindi cross platform; sono estesi e storicizzati quindi hanno un sacco di meccanismi che funzionano e sei sicuro che vadano; sono estendibili e quindi sono belli; sopratutto sono standard aperti e quindi bellissimi.

peccato che: per la parte di networking nascono come estensione di un protocollo che fra tutte le rfc esistenti è il meno adatto ad applicazioni complesse o che hanno restrizioni di tempo (http); che ci sono un sacco di sovrastrutture, talmente tante che a rigore fatichi a leggere la documentazione quanto ad usarle. che gli standard text based non sono una risposta a tutte le domande del mondo. che l'xml è mortalmente verboso (non a caso si è tornati "indietro" al json; e persino il w3c ha sintassi alternative per certi scopi, vedi le ontologie) che le rfc pre-w3c erano notevolmente più snelle e coprivano una casistica di esigenze più ampia.

se giri un pò su wikipedia vedrai che ci sono diversi tentativi - ad esempio - di avere un corrispondente binario di xml; i proposal guidati dal w3c od aderenti ad xml tendono ad arrancare, alla fine quel poco che funziona sono implementazioni custom e quindi "non benedette" da w3c, vedi protocol buffers, bson, e ... link collegati.


più che altro a me interesserebbe trovare un link che fosse uno che mi spiega perchè è "informaticamente corretto e pulito e più standard" cercare di fare tutto su un protocollo che è l'ennesima riproposizione di una remote procedure call ed è nato per gli ipertesti. perchè io una ragione valida non la trovo

...i comitati non hanno quasi mai funzionato....

[Kiruha]

dio mioooooooo, quanto mi fa il culettoooooooooo!!!!!!!!!!!!!!!!

[Ero-Senin]

non le conosco nemmeno io.

[Ero-Senin]

(cit.)

[wxyz]

dio mioooooooo, quanto mi fa il culettoooooooooo!!!!!!!!!!!!!!!!

buondì; la tipa non ha accettato il dolce salato?

[Valfuindor la Maia]

uhm magari hanno solo dei problemi tecnici
al massimo nyaa~

[Kiruha]

buondì; la tipa non ha accettato il dolce salato?

no veramente la vedo stasera...







non so perchè, ma a volte mi prendono attacchi alle chiappette, zona bucio del

[Svartborg]

Plugin utili per firefox?

[wxyz]

no veramente la vedo stasera...

non so perchè, ma a volte mi prendono attacchi alle chiappette, zona bucio del

-> doc

so già che in questi giorni mi romperò abbastanza, bloccato in casa dalla neve

stanotte previste gelate non trascurabili....

[Valfuindor la Maia]

ieri sera quattro ore per percorrere la tratta vimodrone -> seregno -> castellanza
tra l'altro, sotto la neve è tutto ghiaccio

[wxyz]

qui comincia molto lentamente a sciogliersi..... forza sooooleeeee!!!

[Ero-Senin]

biribiri 12

onesamaaaaaaaaaaaaaaaaaaaaaah