fixedCitazione:
Originariamente Scritto da Bl@ck
Visualizzazione Stampabile
fixedCitazione:
Originariamente Scritto da Bl@ck
non applicabile in questo caso, per vari motivi:Citazione:
Originariamente Scritto da Haruki
- 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 :fag:
- 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.
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.Citazione:
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? :caffe:
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 :fag: 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.
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.
tl;dr
Io ho fatto sgommate per dieci minuti in un parcheggio completamente sobrio e voi no :fag:Citazione:
Originariamente Scritto da Valfuindor la Maia
http://www.youtube.com/watch?v=Z0RS_we5oy0
In This Video: japanese studio aperto discovering the internet.
Appena visto in Germano.
Voalletto. :ciaociao:
adieu :ciaociao:
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 nasoCitazione:
Originariamente Scritto da wxyz
dovrei leggermi la documentazione, ma già ho poco tempo di mio... :bua:
ohayo :snob:
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.Citazione:
Originariamente Scritto da Haruki
le applicazioni web sono tutt'altro che leggere, e comunque la piattaforma così come è oggi fa cacà :asd: .
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 :asd:
giorno
l'omino delle caldaie è in ritardo di 45' ed io mi sono svegliata alle 6:30 per sistemare casa :fag:
http://images.smh.com.au/ftsmh/ffxim..._470x365,0.jpgCitazione:
Originariamente Scritto da Valfuindor la Maia
?
Fuck. :facepalm:Citazione:
Originariamente Scritto da Haruki
wxyz: hai qualche link che spieghi un attimo sta storia degli standard web bloated, per favore? :uhm:
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 :mad:
...i comitati non hanno quasi mai funzionato....
dio mioooooooo, quanto mi fa il culettoooooooooo!!!!!!!!!!!!!!!!
:eek2:Citazione:
Originariamente Scritto da Bl@ck
http://img692.imageshack.us/img692/8748/down1.jpg
:facepalm: (cit.)
buondì; la tipa non ha accettato il dolce salato? :fag:Citazione:
Originariamente Scritto da Kiruha
uhm magari hanno solo dei problemi tecnici :uhm:
al massimo nyaa~ :snob:
no veramente la vedo stasera... :fag:Citazione:
Originariamente Scritto da wxyz
non so perchè, ma a volte mi prendono attacchi alle chiappette, zona bucio del
:facepalm:
Plugin utili per firefox?
-> docCitazione:
Originariamente Scritto da Kiruha
so già che in questi giorni mi romperò abbastanza, bloccato in casa dalla neve
stanotte previste gelate non trascurabili....
ieri sera quattro ore per percorrere la tratta vimodrone -> seregno -> castellanza
tra l'altro, sotto la neve è tutto ghiaccio :|
qui comincia molto lentamente a sciogliersi..... forza sooooleeeee!!! :|
biribiri 12 :eek2:
onesamaaaaaaaaaaaaaaaaaaaaaah :piange: