Chrome 15 stabile e nella 17 HTTP pipelining

[Redazione di Hardware Upg]

Link alla notizia: http://www.hwfiles.it/news/chrome-15...ing_39176.html

Una nuova versione stabile di Google Chrome è disponibile per il download, mentre nella release 17 è atteso il supporto all'HTTP pipelining

Click sul link per visualizzare la notizia.

[andrea2607]

Ok aver risolto i bug, aggiunto funzionalità e migliorato la sicurezza..ma ormai fra i browser è una "gara" a chi arriva alla versione con il numero più grande.

Una volta usciva una versione che cambiava radicalmente il browser e da li in poi fino ad un altro radicale cambiamento si avevano le sub-versioni mentre ora di così radicale cosa cambia? Secondo me l'unica che rispetta ancora questa cosa è Microsoft con ie, ogni volta che si sente ie7, ie8, ie9 si parla di versioni ,oltre dal lato estetico, strutturate in modo completamente diverse eogni volta migliori, perchè ie9 è davvero un ottimo browser, e non sono assolutamente fan di Microsoft, anzi, sono un super-fedelissimo di firefox che però in questo ultimo anno ha cambiato versione di continuo, secondo me peggiorando!!

Ormai per Mozilla e Google è una gara a dire: "io sono alla versione 7, io invece alla 15" quando invece si dovrebbe guardare allo sviluppo vero, visto che se andiamo avanti di questo passo ie10 sarà ancora meglio di chrome e firefox!

[calabar]

In realtà no, c'è una diversa filosofia di sviluppo dietro.
Si tratta mettere subito a disposizione i miglioramenti anziché aspettare una nuova release, lasciando nel frattempo il browser nell'obsolescenza rispetto ai concorrenti.
Ciò che è successo con FF 3.6 in attesa di FF4 insomma.

Quindi si è deciso di adottare la filosofia di sviluppo "alla chrome", che pareva più adatta ai tempi, e così abbiamo due browser che tirano di continuo fuori numeroni di versione.

Ma del resto sono solo numeri, per cui, dove sta il problema?

[andrea2607]

Originariamente inviato da calabar

In realtà no, c'è una diversa filosofia di sviluppo dietro.
Si tratta mettere subito a disposizione i miglioramenti anziché aspettare una nuova release, lasciando nel frattempo il browser nell'obsolescenza rispetto ai concorrenti.
Ciò che è successo con FF 3.6 in attesa di FF4 insomma.

Quindi si è deciso di adottare la filosofia di sviluppo "alla chrome", che pareva più adatta ai tempi, e così abbiamo due browser che tirano di continuo fuori numeroni di versione.

Ma del resto sono solo numeri, per cui, dove sta il problema?

Il problema non c'è perchè come detto uso firefox da sempre..però volevo solo far notare come ie ad ogni cambio di versione cambia radicalmente..mentre altri sparano numeri tutto l'anno ma poi rimangono quasi sempre li..la mia non è polemica sui numeri, anzi non è proprio polemica..è voler far notare che ie cresce davvero ad ogni versione..tutto qua!

[Cimmo]

Originariamente inviato da andrea2607

Il problema non c'è perchè come detto uso firefox da sempre..però volevo solo far notare come ie ad ogni cambio di versione cambia radicalmente..mentre altri sparano numeri tutto l'anno ma poi rimangono quasi sempre li..la mia non è polemica sui numeri, anzi non è proprio polemica..è voler far notare che ie cresce davvero ad ogni versione..tutto qua!

Si chiama "agile development" o in italiano "metodologia agile" che come ha detto calabar giustamente tende a fare tante piccole release, piu' frequenti, ma con meno feature, in modo da non fare attendere 1 anno l'utente anche per la piu' stupida cosa che e' stata messa a posto solo nella release X, di fatto ha tanti difetti, ma ha anche i suoi vantaggi.
http://it.wikipedia.org/wiki/Metodologia_agile

Ad ogni modo bisogna che la gente si faccia una cultura e smetta di lamentarsi del numero delle versioni, perche' tutte le + grandi software house stanno andando in quella direzione.
Ora ad ogni notizia di Chrome o Firefox o dei driver nvidia (e' successo a suo tempo) c'e' sempre almeno un commento a riguardo.

Poi se Firefox e' diventato piu' instabile questo e' un altro paio di maniche, si vede che non hanno abbastanza QA.

[speyer]

Originariamente inviato da Redazione di Hardware Upgrade

Questa innovazione, già disponibile in Opera

Mi risulta che sia da tempo disponibile anche in Firefox: è pieno di tutorial che spiegano come incrementare la velocità di Firefox agendo anche sui parametri di questa funzione (di default disabilitata)

[II ARROWS]

Cimmo, "Sviluppo Agile" non significa cambiare numero di versione per ogni minima cazzata che fai.

[alibrandicus]

Originariamente inviato da Cimmo

Ad ogni modo bisogna che la gente si faccia una cultura e smetta di lamentarsi del numero delle versioni, perche' tutte le + grandi software house stanno andando in quella direzione.
Ora ad ogni notizia di Chrome o Firefox o dei driver nvidia (e' successo a suo tempo) c'e' sempre almeno un commento a riguardo.

Hai ragione, ma non c'è niente da fare, i commenti "intelligentissimi" riguardo il numero di versione ci saranno sempre...
E' triste perchè se uno nella vita si preoccupa del fatto che chrome si chiami 19 anzichè 10.18.310.250...allora...siam messi bene...

[Mde79]

Originariamente inviato da alibrandicus

Hai ragione, ma non c'è niente da fare, i commenti "intelligentissimi" riguardo il numero di versione ci saranno sempre...
E' triste perchè se uno nella vita si preoccupa del fatto che chrome si chiami 19 anzichè 10.18.310.250...allora...siam messi bene...

I commenti "intelligentissimi" sono i vostri.
Chi ci deve sviluppare le applicazioni deve dare supporto a decine di versioni diverse ed è costretto a non supportare ufficialmente Chrome.
Firefox in parte è tornato sui suoi passi con il long term support.
Con i costi sempre tagliati al minimo si finisce per supportare solo Internet Explorer

[jappilas]

Originariamente inviato da Cimmo

Si chiama "agile development" o in italiano "metodologia agile"

NO, non si chiama "agile development"
nello sviluppo sw le metodologie agili prevedono che il processo di: analisi dei requisiti -> design -> sviluppo -> testing e validazione -> feedback non sia più eseguito in una successione monolitica a livello di intero progetto, ma ripetuto iterativamente in cicli dallo scope ridotto, di modo da permettere al progetto stesso di sostenere variazioni nei requisiti (e di riflesso a livello di feature, interfaccia od anche di design architetturale) in corso d' opera
quindi minimizzare i fattori di rischio del processo di sviluppo - processo che per creare qualcosa che soddisfi sia le specifiche iniziali più quelle emerse nel tempo (soluzione completa da fornire alla clientela/ utenza, aka deliverable), richiederà comunque dei mesi o degli anni...
in questo non c'è molta differenza con le metodologie non agili (che anzi con un' accurata pianificazione iniziale possono a seconda dei casi perfino richiedere meno risorse - scendere nel dettaglio di cicli -> stories -> singoli tasks e gestirli individualmente crea un certo overhead), a parte il fatto che se lo sviluppo dovesse per qualsivoglia motivo interrompersi a metà, esiste comunque "qualcosa" (l' ultimo snapshot della code base) da far uscire...
MA, il prodotto del singolo task o della singola iterazione è sostanzialmente una release interna al team di sviluppo - che sia da equiparare a una deliverable non è scritto da nessuna parte, semmai è un' idea indotta dall' open source (che in questo senso è pericoloso perchè rischia di creare dei falsi preconcetti che poi si pretende di applicare al sw in generale) nella sua veste di modalità di distribuzione e deployment (visto che ogni build è anche una relase pubblica)...

Ad ogni modo bisogna che la gente si faccia una cultura e smetta di lamentarsi del numero delle versioni, perche' tutte le + grandi software house stanno andando in quella direzione.

così come non è scritto da nessuna parte che il sw debba uscire con nuove relase a scadenze regolari (3 mesi piuttosto che 6, 12 o..) piuttosto che "quando è pronto" come si è sempre usato...
o che debba essere numerato secondo criteri diversi da major_version.minor_version, dove un incremento di major_version è per convenzione sinonimo di novità sostanziali a livello architetturale e/o (anche solo) di interfaccia
esempio classico : il sw di animazione e modellazione Real3D già dalle prime versioni implementava le proprietà fisiche degli oggetti e li rappresentava nativamente in forma di nurbs, ma aveva un menu che definire ostico è riduttivo, e parecchie idiosincrasie... la gui venne completamente rifatta, il feature set e i menu non solo ampliati ma ortogonalizzati in ottica objet oriented (quindi chiara per l'utente), lo stesso core venne riprogettato di modo che ogni property potesse influenzare programmaticamente ogni altra, oltre a essere animabile, o che mesh nurbs, sds o poligonali potessero essere composte in modo seamless nello stesso oggetto
la nuova versione fu rilasciata come "realsoft version 4", cosa giustificata da tutto il lavoro che vi confluì - ed anche l' utente sapeva di potersi aspettare praticamente un programma del tutto nuovo (cosa che in effetti era)

ora, per Google Chrome non avviene nulla del genere, tra una relase e l' altra l' interfaccia è sempre la stessa, l' architettura a process separated tabs è sostanzialmente sempre la stessa, le funzionalità sono sempre le stesse, di browser (peraltro la tipologia di applicazione fruitiva più basilare e semplice dal punto di vista dell' utente, nonchè l' applicazione orizzontale per definizione) streamlined, con innovazioni che nella convenzione di cui sopra meriterebbero incrementi del major version number in uno o al più due occasioni ... motivo per cui Google sceglie bellamente di ignorarla, per dare all' utenza un' immagine di maggiore dinamismo (e peraltro convincerla che vada abolita in quanto anacronistica e superata)

quindi sì, occorre che la gente si faccia una cultura, ma non tanto per smettere di lamentarsi del numero delle versioni, ma per capire cosa è versioning e cosa è marketing...

[maumau138]

Originariamente inviato da jappilas

NO, non si chiama "agile development"
nello sviluppo sw le metodologie agili prevedono che il processo di: analisi dei requisiti -> design -> sviluppo -> testing e validazione -> feedback non sia più venga eseguito in una successione monolitica a livello di intero progetto, ma ripetuto iterativamente in cicli dallo scope ridotto, di modo da permettere al progetto stesso di sostenere variazioni nei requisiti (e di riflesso a livello di feature, interfaccia od anche di design architetturale) in corso d' opera
quindi minimizzare i fattori di rischio del processo di sviluppo - processo che per creare qualcosa che soddisfi sia le specifiche iniziali più quelle emerse nel tempo (soluzione completa da fornire alla clientela/ utenza, aka deliverable), richiederà comunque dei mesi o degli anni...
in questo non c'è molta differenza con le metodologie non agili (che anzi con un' accurata pianificazione iniziale possono a seconda dei casi perfino richiedere meno risorse - scendere nel dettaglio di cicli -> stories -> singoli tasks e gestirli individualmente crea un certo overhead), a parte il fatto che se lo sviluppo dovesse per qualsivoglia motivo interrompersi a metà, esiste comunque "qualcosa" (l' ultimo snapshot della code base) da far uscire...
MA, il prodotto del singolo task o della singola iterazione è sostanzialmente una release interna al team di sviluppo - che sia da equiparare a una deliverable non è scritto da nessuna parte, semmai è un' idea indotta dall' open source (che in questo senso è pericoloso perchè rischia di creare dei falsi preconcetti che poi si pretende di applicare al sw in generale) nella sua veste di modalità di distribuzione e deployment (visto che ogni build è anche una relase pubblica)...
così come non è scritto da nessuna parte che il sw debba uscire con nuove relase a scadenze regolari (3 mesi piuttosto che 6, 12 o..) piuttosto che "quando è pronto" come si è sempre usato...
o che debba essere numerato secondo criteri diversi da major_version.minor_version, dove un incremento di major_version è per convenzione sinonimo di novità sostanziali a livello architetturale e/o (anche solo) di interfaccia
esempio classico : il sw di animazione e modellazione Real3D già dalle prime versioni implementava le proprietà fisiche degli oggetti e li rappresentava nativamente in forma di nurbs, ma aveva un menu che definire ostico è riduttivo, e parecchie idiosincrasie... la gui venne completamente rifatta, il feature set e i menu non solo ampliati ma ortogonalizzati in ottica objet oriented (quindi chiara per l'utente), lo stesso core venne riprogettato di modo che ogni property potesse influenzare programmaticamente ogni altra, oltre a essere animabile
la nuova versione fu rilasciata come "realsoft version 4", cosa giustificata da tutto il lavoro che vi confluì - ed anche l' utente sapeva di potersi aspettare praticamente un programma del tutto nuovo (cosa che in effetti era)

ora, per Google Chrome non avviene nulla del genere, tra una relase e l' altra l' interfaccia è sempre la stessa, l' architettura a process separated tabs è sostanzialmente sempre la stessa, le funzionalità sono sempre le stesse, di browser (peraltro la tipologia di applicazione fruitiva più basilare e semplice dal punto di vista dell' utente, nonchè l' applicazione orizzontale per definizione) streamlined, con innovazioni che nella convenzione di cui sopra meriterebbero incrementi del major version number in uno o al più due occasioni ... motivo per cui Google sceglie bellamente di ignorarla, per dare all' utenza un' immagine di maggiore dinamismo (e peraltro convincerla che vada abolita in quanto anacronistica e superata)

quindi sì, occorre che la gente si faccia una cultura, ma non tanto per smettere di lamentarsi del numero delle versioni, ma per capire cosa è versioning e cosa è marketing...

*