Newsgroup: it.lavoro.informatica
Titolo: Udita poco fa'

Manager IT a Programmatore PHP che gestisce il cms del sito web:
MIT: la pagina x del sito non si vede bene
PPHP: quale? non capisco...io visualizzo tutto correttamente..
MIT: cchestai a di' i testi vanno tutti fori dai margini...
PPHP: Dottor MIT, mi scusi ma lei quale browser utilizza? Noi abbiamo
ottimizzato il sito per Mozilla...
MIT: A MORO A ME DE GODZILLA NUN ME NE PO' FREGA' DE MENO, ER SITO SE DEVE VEDE'
BENE CO' L'EXPLORER


Lavori a Roma? :)

 
 
 
A parte la nota di colore dell'aneddoto, nel 2013 (ma anche prima) è
semplicemente fuori da ogni graziaddiddio pensare ancora di ottimizzare
un sito "per questo o per quello". Il sito deva da funzionà co' TUTTI.
 
M.

 un sito "per questo o per quello". Il sito deva da funzionà co' TUTTI.
 
Mi hai levato le parole dai ditini. Aggiungo un paio di cose: visti i casini legati ai vari browsers, che pure Ext-JS NON risolve (conosco solo questo, chiedo scusa, anzi, se qualcuno più esperto di me ha qualche suggerimento alternativo, lo ringrazio in anticipo), purtroppo bisogna provare le cose maniacalmente almeno su Explorer, Firefox e Chrome (con Chrome che, va detto, è quello più disposto a mangiardi qualsiasi cosa). L'attenzione a Explorer in particolare è necessaria, vsto che ancora oggi, piaccia o non piaccia, ha ancora una enorme fetta di utilizzo.
 
-- 
Ciao!
Luca

 
 
 
 
mi sembra piuttosto contestabile: io nel 2009 ho lavorato in
ambito finanziario (il mio anno a progetto...), e l'applicativo
andava solo su IE (non ricordo la versione, probabilmente la 6).
 
Ora invece lavoro su applicativi che vanno su chrome e firefox,
e non su IE.
Dipende molto dal contesto e dal tipo di applicazione, direi.
 


Infatti è facilissimo, ci vuole proprio nulla: un clientino che gira nel 
browser che ti da accesso ad un terminal server.
E si vive felici....
Ma non si può perché c'è un giro di magna magna a livello tecnologico e 
formativo che fa paura per di continuare a tenere in piedi l'acrocchio 
nativo delle web applications, che in teoria funzionano, in pratica poco e 
con continui investimenti in manutenzione per farle rimanere abbastanza 
funzionanti correndo dietro ai vari rilasci dei browser che si incrociano 
con i vari rilasci dei componenti di terze parti a cui uno si è felicemente 
legato per avere la UI figa.
Che poi, ora che il cloud va di moda e si parla tanto di infrastruttura come 
servizio, e quindi possibilità di avere più o meno risorse lato 
"back-clound" in base al carico reale, che cavolo di idea assurda può essere 
tornare a lavorare felicemente in modalità terminal server?
 

beh non vedo la stranezza.


 Dipende molto dal contesto e dal tipo di applicazione, direi.
 
Ripeto.
Se non ci sono vincoli particolari, e il target usa un po' di tutto, �
buona norma per lo sviluppatore fare una cosa che funzioni con tutti i
browser. Sono finiti i tempi dei banner e delle scritte "Sito
ottimizzato per ... versione xyz".
 
Altrimenti, come si fa spesso in casi particolari, si realizza quello
che chiede il cliente; posso portare come aneddoto le richieste di un
cliente: con tutto il mondo oramai diretto verso Firefox (che nelle
ultime versioni � diventato una mezza monnezza), IE 8 / 9 / 10 e Chrome,
abbiamo sentito dire "l'applicazione DEVE funzionare con la 7 perch� NOI
abbiamo installato QUESTA versione. Non ci frega niente del mondo esterno".
 
M.

 
 
 
 
guarda che non è che stiamo dicendo cose diverse.
Come ho detto dipende dal contesto: se ad esempio stai facendo un
portale per il turismo (come mi è capitato), allora come dici
tu non ci sono vincoli particolari, e l'applicativo si testa
su più browsers (io testavo con ie, chrome, firefox e anche 
opera).
Ma vi sono contesti in cui magari si usa solo ie, o si usano
chrome e firefox e non ie, come dove sono ora, e in tal caso
non mi metto a testare sui browser non utilizzati.
Ad esempio, il progetto (anzi, i progetti) che sto sviluppando ora
con ie sono inguardabili, oltre che inutilizzabili, ma per
dove sto lavorando va bene così, stop.
In altre situazioni invece è diverso.
 
 
Tu prima ti sei espresso in un modo che sembrava che fosse
impensabile che un applicativo non andasse con tutti i
browser, e io ho solo detto che non è sempre così.
 

 opera).
 
Meglio sempre specificare in sede contrattuale per quali versioni e 
quali browser si assicura il funzionamento corretto.
 

 dove sto lavorando va bene così, stop.
 
Cosa intendi per "inguardabili/inutilizzabili"?
stai usando che tipo di impostazioni da rendere addirittura non usabile 
su IE7 ?
Premetto che personalmente sono piuttosto talebano e cerco di non 
perdere tempo per IE, ma mi chiedo in cosa consista la tua affermazione.
 
ciao
Gabriele
 

 
 
 
 
allora: quello che sto facendo ora consiste in sostanza nel
replicare alcuni applicativi che sono già stati sviluppati,
e di rifarli modificando template grafico e tecnologia,
mantenenendo però tutte le funzionalità originali.
In pratica stiamo prendendo dei progetti sviluppati con
normali pagine jsp senza framework particolari e li stiamo
rifacendo usando il framework jsf e primefaces, e usando
un template grafico che sta facendo un nostro collega
grafico appositamente.
 
 
Ora, non voglio entrare nel merito dei problemi che sono
sorti e sorgono continuamente nel replicare le
funzionalità, che è un casino che non finisce più:
i nuovi siti che sto facendo funzionano con chrome e ff,
ma non con ie: io inizialmente ho fatto un po' di prove
con ie, e mi sono subito accorto che l'applicazione era
inutilizzabile: graficamente faceva schifo, le liste di
dati apparivano in un modo osceno, e non si riusciva
a navigare nel sito. Ho segnalato la cosa, e mi hanno detto
chiaramente che di ie non gliene frega nulla a nessuno.
 
Da allora io ie non lo uso più [per questi progetti], e
mi preoccupo solo che su chrome e ff le cose funzionino
e la grafica sia come dev'essere.
Insomma: con ie il lavoro che sto facendo è un vero
schifo, non funziona ed è brutto esteticamente, ma ie è stato 
bannato, quello che conta è che funzioni bene con gli
altri due browser.
 
 
Ecco in che senso con ie i progetti che sto sviluppando
sono inutilizzabili, ed ecco un esempio concreto di
quando dicevo che non sempre tutto deve funzionare con
tutti i browser.
 

 (cut)
 
E quello che volevi dirci � che entrambi erano inompetenti, incapaci e
cazzoni, giusto?
 
 


Sull'inutilizzabile ti posso dire che visto l'engine js che fa pietà, ti 
puoi trovare delle web app che funzionano bene (come responsività lato 
client, lasciamo un attimo perdere l'usabilità in senso stretto) con ff e 
chrome che su ie sono *almeno* il doppio più lente. Fa conto che esiste un 
plugin per ie, google chrome frame, che si usa proprio per far girare 
decentemente il js che sta dietro alle pagine.
 


 
 
Il mio dubbio verteva sulla differenza tra "si vede brutto" e "non si 
può usare" :)
Non è che potresti fornire un esempio reale?
Perché sono d'accordo che ci possano essere difficoltà di allineamento 
(specie in IE7) e non visualizzare alcune caratteristiche (a me piace 
usare solo CSS per quanto possibile per le "frocerie"), ma che proprio 
non funzioni... la mia è curiosità tecnica :)
 
ciao
Gabriele
 


Premesso che della scomparsa completa di IE sarò (sono) molto felice e 
che conosco perfettamente la frustrazione che sale quando cisi deve 
combattere, dai un'occhiata al tuo codice:
Per la mia esperienza con IE i problemi sono principalmente di box-model 
che fa qualche pixel in più, in meno, trasparenze e cose varie.
Se sbarella del tutto di solito è qualche regola css mal applicata o 
qualche problema di scoping delle variabili js dichiarate come capita.
Gli altri browser ci mettono una pezza mentre IE no
Verificare non guasta.
 
 
Ad ogni modo quelle ormai rare volte che mi tocca fare un sito dico ai 
clienti che sarà pixel-perfect su chrome e firefox.
Sugli altri browser dico espressamente che non me ne curo e casomai si 
paga di più
M
 
-- 
I fatti mi cosano

 
 
 
 
l'esempio te l'ho già fatto, mi pare: sto sviluppando dei
progetti con un'impostazione grafica tale che con chrome e ff
funziona bene, con ie è una merda.
Ovviamente non decido io la grafica, sono direttive che vengono
dall'alto, e noi a quelle ci atteniamo.
 
 
Poi è ovvio che le differenze da browser a browser riguardano
solo la parte client e non quella server: quando dico che
il progetto non funziona non vuol dire che la business logic
ha dei funzionamenti diversi a seconda di quale browser
uso, è ovvio che questo non accade; intendo dire che l'utente
dell'applicativo usa ff o chrome, ma non ie, poiché su ie è
impossibile navigare.
Se la parte grafica fa cilecca mi sembra chiaro che è come
dire che il progetto non funziona: se ho una lista di dati,
con le funzionalità annesse, nel momento in cui con ie
la lista viene male anche le funzionalità del sito ne restano
compromesse, mi sembra chiaro, indipendentemente dal fatto
che l'implementazione della business logic in se funzioni.
E' questo che sto dicendo.
Cos'è che non ti torna? 
 

 clienti che sarà pixel-perfect su chrome e firefox.
 
Come ho premesso, impiego un framework in Javascript. Io non so come sia, fatto sta che non riesco a costruire qualcosa che sia perfetto tra browsers: a volta ok tra IE e Chrome e sbarellato su Firefox, a volte ok su Chrome e basta...
 
Aggiungo. Potrà non piacere, ma alla fine IE è uno dei browsers maggiormente usati, per cui se il tuo target è un'applicazione facilmente distribuibile (leggi, non una roba su commessa) inevitabilmente devi aver a che fare anche con Explorer.
 
Va detto che IMHO con le versioni più recenti le cose son migliorate parecchio: da un punto di vista grafico, io ho più problemi con l'ultima versione di Firefox...
 
-- 
Ciao!
Luca

 
 
 
in effetti sì, però mi pare che negli ultimi anni anche chrome e ff
siano parecchio utilizzati, e personalmente, dopo quasi 5 anni che
faccio questo lavoro, devo dire che con questi due browser mi trovo
meglio che con ie.
Negli ultimi mesi ie lo sto usando pochissimo, e mi riferisco anche
a cose non legate al lavoro (ora ad esempio qui su ili sto usando 
chrome :) ).


La 9 è appena sopra l'indecenza, la 8 che per fortuna sta scomparendo 
abbastanza rapidamente è sotto l'indecenza
Ormai con la 9 si è ragionevolmente sicuri che al 90% il layout e il 
comportamento dovrebbero essere congruenti.
Concordo che Firefox stia perdendo terreno rispetto a chrome
Resta il fatto che io personalmente col cavolo che ci perdo tempo se non 
pagato
Ahhh, che sollievo :)
 
È un sacco che però non provo Opera che fino a qualche tempo fa era 
l'avanguardia, quasi quasi me lo reinstallo


 pagato
 
Credo che Chrome venga installato anche in modo un po' subdolo, sia con 
alcune barre aggiuntive che quando Google ti fa apparire degli avvisi 
"aggiorna il tuo browser con uno più veloce"... e questo IMHO non è 
molto etico.
 
ciao
Gabriele
 
 


 
Non mi torna che, per quanto io odi profondamente IE (oltretutto uso 
solo OSX, quindi le simulazioni le faccio con siti appositi o con una 
VM), mi pare strano che sbarelli tutto in modo così grave come descrivi 
tu :)
 
Sarebbe interessante vedere un po' di codice.
 
ciao
Gabriele
 


Scusa, mi sono espresso male.
Con "sta perdendo terreno" intendevo da un punto di vista tecnico.
Usavo solo firefox, ora che mi sono abituato a come frulla Chrome uso 
firefox solo come browser secondario (ad es quando devo testare cose e 
non ho voglia di segare i cookies)
Sull'eticità non mi pronuncio, ma effettivamente Chrome è più veloce
 
M


 browser a browser.
 
jquery è una libreria non un framework per l'interfaccia grafica. semmai 
si può dire che esistono un gran numero di framework che si basano su 
jquery.

 Per il 15% circa non è che sia da stracciarsi le vesti ...
 
Faccio notare che, ahime, siamo intorno al 26%. IE è diviso tra 7 (irrilevante), 8 e 9, Firefox è definito '5+', e visto che siamo, pur con salti, alla 18...
 
E in ogni caso, con quella cifra, è ancora il terzo browser, con un utilizzo preponderante in molte aree del pianeta (ad es. nord america)
 
 
-- 
Ciao!
Luca

 quali browser si assicura il funzionamento corretto.
 
Yup. Ricordo un progetto per una grossa multinazionale, durante una riunione uno dei mie colleghi disse en passant che avremmo supportato soltanto IE7, non più IE6, il cliente andò nel panico più totale, il motivo: aggiornare quelle workstation da IE6 a IE7 gli sarebbe costato 750 mila Euro!
Ovviamente è finita che abbiamo anche dovuto supportare IE6 per quello specifico cliente ...
 
-- 
ale
http://ale.riolo.co.uk
 

 rispetto alla 8.
 
guarda usando un framework javascript un po' spinto come potrebbe essere 
extjs dei tre non se ne salva uno. noi abbiamo avuto la sventurata idea 
di realizzare per un cliente, che sapevamo usare mandatoriamente ie, un 
prodotto critico con interfaccia sviluppata in ext, non l'avessimo mai 
fatto. sulla 7 notoriamente il javascript non va e già lì ci siamo 
giocati una fettina di credibilità, perché hai voglia di mettere per 
iscritto i requisiti ma quando il cliente vede il programma penosamente 
piantato la prima cosa che pensa è che il programma fa cacare, poi magari 
ci ripensa ma la prima sensazione è quella. l'8 e il 9 da questo punto di 
vista vanno un po meglio, ma solo da questo punto di vista. al di la del 
fatto che ci sono delle cose, tipo la gestione degli iframe, su cui ormai 
abbiamo rinunciato ad ogni velleità. però tuttora saltano fuori dei 
malfunzionamenti *diversi* da macchina a macchina, tipo a uno explorer 
ogni tanto si congela e va ucciso col task manager, un altro ad ogni 
avvio deve pazientemente svuotare la cache perché sennò gli viene pagina 
bianca, un altro ancora alla terza volta che fa una operazione esce un 
errore javascript nella libreria ext. in tutte le altre postazioni 
ovviamente non hanno nessuno di questi problemi. questo perché un altro 
difetto di ie è che non è possibile avere o ripristinare una 
installazione pulita. 

 extjs dei tre non se ne salva uno. 
 
Io penso spesso: maledetta quella volta che mi son fatto convincere a fare applicazioni con interfaccia web. Parecchie volte tocca sputare sangue perché due form siano non dico uguali, ma abbastanza simili, tra Firefox e Chrome / Chromium. Problema di questa settimana, risolto: l'upload delle immagini, che con Chrome funziona, con Firefox non va; soluzione? indicare la risposta, che pure è JSON, come 'text/html' invece che come 'application/json'...
 
Sto davvero rivalutando le applicazioni monolitiche, magari multipiattaforma:sto impiegando in questo periodo Python con wx e Python con Qt, e forse il secondo è meglio del primo, e portare un'applicazione da Linux a Windows è davvero questione di minuti.
 

 
 
 
effettivamente mi sono espresso un po' male. Intendevo dire che
sviluppando col javascript senza uso di framework i problemi
da browser a browser sono abbastanza frequenti, sia per quanto
riguarda questioni grafiche, sia per il fatto che determinate
azioni a seconda del browser si fanno con istruzioni diverse.
 
Chiaramente i framework hanno anche lo scopo di limitare
questi problemi (non solo questo scopo, s'intende), ma secondo
me non li elimini del tutto.
Io ho usato jquery e anche un po' dojo nel corso della mia
esperienza lavorativa (ma il secondo molto poco), e anche se
jquery mi sembra molto buono, qualche volta cambiando browser
qualche problema si è verificato, anche se sul momento non
ricordo nei dettagli il caso specifico.
 
 
In ogni caso ribadisco quanto ho già detto: i framework o le
librerie sono strumenti potenti, ma devi conoscerli molto bene,
altrimenti accade che per fare una cosa semplice ci perdi
delle giornate, e questo discorso vale per tutti i framework,
non solo quelli js.
Basti pensare a struts, hibernate, ma anche jsf, con cui sto
lavorando ora che certe volte fa tirare a me e ai miei colleghi
delle belle sfilze di bestemmie.
Però alla fine devo dire che è abbastanza divertente usare i
framework...

 
 
 
te lo ripeto, bisogna che ti fidi. Ti garantisco che ho provato
a navigare con ie, ma il progetto viene reso molto male.
Poi magari ci si può navigare lo stesso, ma poiché per il
momento di ie non ce ne importa niente non sono stato lì
ad approfondire più di tanto.
E poi, se non è compito mio fare la parte grafica, se dovessero
nascere dei problemi se ne occuperà il grafico, no?
Poi sono perfettamente consapevole che in un modo o in un
altro ci vanno di mezzo tutti gli sviluppatori del progetto,
ma tanto che ci posso fare?

 Io penso spesso: maledetta quella volta che mi son fatto convincere a fare applicazioni con interfaccia web. Parecchie volte tocca sputare sangue perché due form siano non dico uguali, ma abbastanza simili, tra Firefox e Chrome / Chromium. Problema di questa settimana, risolto: l'upload delle immagini, che con Chrome funziona, con Firefox non va; soluzione? indicare la risposta, che pure è JSON, come 'text/html' invece che come 'application/json'...
 
bah questo però mi sembra un problema di come gestisci la risposta: di servizi
rest che consentono upload e rispondono json ce ne sono a quintalate nel
web e nessuno ha ovviamente problemi con firefox.
per il resto sfondi una porta aperta: da anni ormai spingo per sviluppare
tutto rest in modo che non ci siano vincoli di piattaforma per l'interfaccia,
browser, client, ria o mobile che sia. quello che secondo me non è "furbo" è
portare anche la business logic sul client, però è una opinione personale.

 quali browser si assicura il funzionamento corretto.
 
sicuramente è bene farlo ma non cambia granché i termini del problema. 
è vero che se il cliente si lamenta puoi sempre dire "ma io te l'avevo 
scritto", però rimane il fatto che il cliente è scontento. 
buttarla sul legale non è
certo un modo di consolidare i rapporti e, di solito, è l'ultima spiaggia
quando ormai il cliente è andato.
 

 web e nessuno ha ovviamente problemi con firefox.
 
Infatti, io son più portato ad addossare la responsabilità a come viene gestita la cosa da Ext, piuttosto che a Firefox; non fosse altro perché TUTTO il resto dell'applicazione risponde JSON con tipo 'application/json' senza alcun problema.
 
Era più che altro per dire della differenza con Chrome che, viceversa, quella risposta accetta senza nessuna difficoltà (anche se, ho pensato, probabilmente ancora una volta c'entra Ext...).
 
-- 
Ciao!
Luca


E se questa non è una definizione perfetta di debito tecnico ...
Dovrebbero metterla nella campagna Get The Facts :)


 quando ormai il cliente è andato.
 
Il legale e' chiaro che e' l'ultima spiaggia ma intanto specifico poi 
valutero' se nei vari casi e' opportuno cedere commercialmente o no.
Se non lo specifichi ti togli questa possibilità di argomentare a priori.

 portare anche la business logic sul client, per� � una opinione personale.
 
 
Concordo con questo approccio meglio essere piu' indipendenti possibili 
dalle interfacce.

 dalle interfacce.
 
Personalmente penso che non sia nemmeno più una questione di opinione. La business logic non deve MAI essere presso il client. Punto. La strada alternativa, se non attentamente pesata, espone a dei rischi assolutamente non accettabili.
 
-- 
Ciao!
Luca

 lavoro supplettivo non pagato di adeguamento.
 
e infatti per questo motivo ho scritto "sicuramente è bene farlo".
ti facevo solo notare come impugnare il contratto non risolve il problema
del cliente insoddisfatto.

 del cliente insoddisfatto.
 
In quest'ottica c'e' anche da valutare il cliente che e' insodisfatto a 
prescindere perche' vuole ottenere sconti o altro anche se hai eseguito 
correttamente il lavoro.

 installazione pulita.
 
Per aver usato (e usando tutt'ora, purtroppo) ExtJS in un progetto posso 
confermare pienamente e senza ombra di dubbio ogni singola parola di 
quanto hai scritto.
 
In piu' aggiungo che non solo IE e' quello che e', ma anche che ExtJS e' 
un CESSO pazzesco. Dietro lo specchietto per le allodole dell'aspetto 
estetico accattivante si cela un prodotto pieno di bachi, di 
incompatibilita' anche tra minor release successive, con un supporto 
tecnico inesistente. Maledetto il giorno in cui e' stato deciso di 
usarlo (non ho deciso io, ma purtroppo poi gli uccelli paduli si 
concentreranno verso il mio culo).
 
Morale: state il piu' possibile lontano da ExtJS e piu' in generale da 
Javascript. Ma se proprio non potete fare a meno di usare Javascript, 
almeno state alla larga da ExtJS. Ne guadagnerete in serenita'.
 
TheStar

 abbiamo installato QUESTA versione. Non ci frega niente del mondo esterno".
 
 
E, molto probabilmente, al mondo esterno non gli frega niente di loro! LOL! :-D
 

 ha scritto:

probabilmente, quella richiesta per supportare merdIE6 fatta all'epoca,
adesso sarà causa di una perdita economica pari al doppio se non al triplo
della stima iniziale.
 

 correttamente il lavoro.
 
Insomma: non vale la pena sviluppare web app per la clientela standard che ci ritroviamo? :)

 Javascript. 
 
QUOTO, cazzo, quoto.
Gestione di focus all'interno di controlli a griglia, in cui è stato chiesto anche lo spostamento con frecce e tab?
 
*Impossibile*da*debuggare*.
 
...che alternative esistono? :)

 Insomma: non vale la pena sviluppare web app per la clientela standard che ci ritroviamo?:)
 
Ad ognuno la valutazione dei propri clienti.Comunque il discorso sopra 
non e' solo riferibile alle webapp.


Imparare a programmare nel linguaggio che viene richiesto
Il debugger c'è e basta usarlo
Scusa la crudezza


 almeno state alla larga da ExtJS. Ne guadagnerete in serenita'.
 
Javascript è una delle poche tecnologie (insieme all'ambiente di R, ad
esempio) che ha permesso a centinaia di non-informatici provenienti
dai più disparati campi in ambito scientifico-computazionale di essere
*produttivi* in poco tempo e con ottimi risultati (soprattutto in
ambito visualizzazione dei data); in posti come Bloomberg (mi viene in
mente questo perchè conosco all'interno, ma ce ne saranno a dozzine di
altre realtà che ignoro) ci hanno costruito un'intero stack e ci
macinano con profitto quantità di dati spropositate. Personalmente, ho
realizzato un'applicazione che fa principalmente analisi geometriche e
topologiche su certi data sets e OpenGL e con il mio socio-amico
(esperto in JS, tra l'altro) tra Javascript, Protovis e appunto OpenGL
abbiamo tirato fuori una parte di visualizzazione analitica che ha
pienamente soddisfatto chi l'ha commissionata - tutto senza grossi
problemi.
 
Stare lontani da JS? Forse dovete un attimo rivedere il vostro
approccio (tra l'altro è probabile che Ext JS sia l'unica soluzione a
vostra disposizione per il dato ocmpito che vi interessa, perchè
quindi far passare le colpe dal framework al linguaggio...).

 approccio (tra l'altro è probabile che Ext JS sia l'unica soluzione a
 
era: è probabile che Ext JS *non* sia l'unica soluzione a...

 c'è e basta usarlo Scusa la crudezza M
 
ok però extjs ci mette parecchio del suo quanto a incoerenza 
dell'ingegnerizzazione. e secondo me illude la committenza che si possano 
fare facilmente determinate cose di interfaccia quando poi fa scrivere 
una enormità di codice al programmatore.


Ma gira bene anche su IE?
 

 Ma gira bene anche su IE?
 
Si - anche se era prettamente compito del socio-amico (a me gli
algoritmi/modelli e il prototipo realtime su OpenGL della
applicazione), posso dire che con Protovis + alcune libs sue + non
ricordo quali altri packages oss per la portabilità nessun problema e
risultati davvero di alto livello, tra l'altro con mia sorpresa anche
spendendoci relativamente poco tempo su.

 quindi far passare le colpe dal framework al linguaggio...).
 
Che JS abbia permesso a molta gente di essere produttiva in poco tempo e 
che ci siano delle realta' specifiche in cui sia stato usato con 
successo, non lo metto in discussione. Si tratta pero' di casi 
abbastanza isolati, realta' in cui quasi sicuramente si avevano risorse 
e competenze per implementare delle soluzioni ad-hoc molto particolari. 
Leggi: realta' che si facevano tutto in casa.
 
L'esperienza negativa con il framework ha un grosso peso nell'opinione 
che ho espresso: pero' lo sanno *anche i sassi* che Javascript e' una 
delle cose meno standard che esistano a livello di browser. Io vengo 
dalla programmazione da linguaggi tipizzati (C/C++ e soprattutto Java), 
percio' un linguaggio in cui ad una variabile puoi assegnare qualunque 
tipo di valore a runtime mi fa venire l'allergia. Lo stesso ragionamento 
e' applicabile ad altri linguaggi come ad esempio al Visual Basic.
 
Nel mio caso poi c'e' un'aggravante: una decisione di fatto presa da 
altre persone ma per cose di cui sarei poi stato responsabile io. Ai 
tempi della decisione (ma anche adesso) la mia esperienza sulle 
tecnologie web lato client era talmente limitata che non avevo 
argomentazioni sufficienti per oppormi a chi spingeva per JS + ExtJS. 
Tornando indietro avrei usato HTML, CSS e magari ricorrendo a qualche 
framework Java per creare interfacce operatore, come Wicket o Vaadin.
 
Colpa anche mia: avrei dovuto essere categorico. Della serie "se la 
responsabilita' dev'essere mia facciamo come dico io, altrimenti vi 
impiccate". Pazienza, sara' una lezione per il futuro.
 
TheStar

 Scusa la crudezza
 
Al giorno d'oggi quando si ha:
 
1) un programma decentemente implementato
2) scritto in un linguaggio di medio-alto livello (leggi: OO)
3) facendo uso di framework altrettanto decentemente implementati
 
il ricorso al debugger dovrebbe essere solo occasionale. Altrimenti vuol 
dire che una (o anche piu') delle affermazioni di cui sopra non e' vera.
 
TheStar
 
 

 1) un programma decentemente implementato
 
Questa premessa, al contrario delle altre, faccio fatica a capirla.

 e' applicabile ad altri linguaggi come ad esempio al Visual Basic.
 
 
Il motivo non può (e non deve) essere "un linguaggio in cui ad una
variabile puoi assegnare qualunque tipo di valore a runtime mi fa venire
l'allergia". Il motivo è (come hai scritto all'inizio) che in realtà
l'engine JavaScript è scritto a capocchia in ciascun differente browser,
dando a volte comportamenti differenti.
 
M.

 l'allergia".
 
Lo e' invece. Perche' i linguaggi tipizzati ti risolvono molte 
ambiguita' a livello di compilazione, ancora prima di eseguire il 
programma.
 
Questa caratteristica, che secondo me e' *sempre* un vantaggio perche' 
esegue controlli che altrimenti sarebbero a carico dello sviluppatore, 
naturalmente ha un costo, che si esplica in minore flessibilita' e in 
minore compattezza del codice.
 
TheStar

 dando a volte comportamenti differenti.
 
a me non risulta che il problema sia l'engine javascript ad avere 
comportamenti differenti. 
comunque, parlando di allergie, javascript ha tre caratteristiche di base:
 
- non è compilato
- ha una tipizzazione dinamica
- ha lo scope dinamico
 
tre cose bellissime, ma provenendo da linguaggi compilati, a tipizzazione
statica e scope statico fintanto non esci dal retaggio non solo vai fuori
di testa ma scrivi anche programmi con dei bug mostruosi (specialmente 
lo scope dinamico, vengon fuori delle cose mica da ridere).
 
comunque non confonderei i difetti progettuali di alcuni framework come
ext con le caratteristiche di un linguaggio che tutto sommato non è
per niente male.
 

 Questa premessa, al contrario delle altre, faccio fatica a capirla.
 
In estrema sintesi, leggi: "caratterizzato da un buon design e 
implementato seguendo le buone pratiche del (best practice) 
dell'ingegneria del software e della programmazione OO".
 
TheStar
 
 


 
La mia perplessità dipende dal fatto che con una premessa di questo tipo 
si può arrivare a fare a meno di tutto.

 programma.
 
a gusto mio preferisco senz'altro linguaggi con il type inference ma
tipizzazione statica, tipo scala per intendersi. però ammetto che 
linguaggi dinamici permettono "virtuosismi" di notevole eleganza e
espressività. 
il problema come dicevo è tutto nell'approccio.
 

 si può arrivare a fare a meno di tutto.
 
Certo che no. Un buon design e' una condizione necessaria ma certamente 
non sufficiente per sviluppare SW di buona qualita'.
 
Infatti non dico che il debugger non si debba mai usare (ci sono infatti 
dei casi in cui e' indispensabile), ma solo che il suo uso dovrebbe 
essere puntuale e non la norma (leggi: ogni volta che devo fare un test 
lancio il programma col debugger ;-) ).
 
TheStar
 
 

 per niente male.
 
Mi interessa sapere quali sono secondo te i difetti progettuali di Ext. Io 
lo sto usando abbastanza pesantemente e benché ne abbia trovate non vedo 
ancora nessuno showstopper.
 
Ciao,
 
-- 
  Daniele "Vihai" Orlandi
  Bieco Illuminista #184213

 impiccate". Pazienza, sara' una lezione per il futuro.
 
E' un discorso sempre spinoso, in effetti io ho impiegato un bel pò di
tempo e risorse per meglio posizionarmi in questo senso (leggi: per
essere il più possibile nella condizione di avere carta bianca quando
interpellato). Certo non si può sempre fare, ma c'è anche da dire che
in tanti non ci provano proprio a lavorare in questa direzione.


Whoa, frena! L'object-orientation equiparato come necessità ad un buon
design per la riuscita del software? E di eccellenti programmi non
object-oriented non ce ne facciamo nulla quindi? L'OOP non è mai stata
una parte fondamentale del computing come qualcuno ha tanto insistito
per farci credere - molto più spesso di quanto non ci si renda conto
usarla complica il software invece di semplificarlo e applicarla
sempre di default ignorando altre possibilità porta più problemi che
soluzioni.
Sarebbe meglio farsene una ragione una buona volta e per tutte.

 soluzioni.
 
dal punto di vista dello sviluppo algoritmico, *stramegaquoto* :-)
 
Dal punto di vista del mero software engineering, un po' meno, IMHO.
Non che non se ne possa fare a meno, anzi! Pero', ad esempio il
polimorfismo (specialmente in esecuzione) di classi e funzioni e'
molto piu' lineare ragionando ad oggetti. Certo, se stai sperimentando
un nuovo algoritmo, e' -di solito- piu' piacevole martellarti
l'apparato genitale che lavorare con l'OOP puro: decine e decine di
files e classi con k e k di dichiarazioni per fare 2+2 o qualcosa del
genere, e a ogni modifica devi cambiare tutte le dichiarazioni, it's
not fun.
 
Poi insomma il tutto IMHO, scritto da un "tecnofobico" allergico a
qualsiasi editor che non sia "vi", sicuramente accrocchi visuali
bypassano il problema, ma IMHO creandone altri ben peggiori :-)
 
 

 approccio (tra l'altro è probabile che Ext JS sia l'unica soluzione a
 
Condivido abbastanza il ragionamento. In fondo, JS e Ext sono strumenti, e come tali vanno usati. A mio parere, però, JS non è il miglior strumento con cui ho avuto a che fare, e per due motivi che sostanzialmente si compenetrano: da un lato, da eccesso di libertà; dall'altro non è detto che il browser di destinazione, e l'annesso JS engine, supporti tutta quella libertà. La sensazione, insomma, è che ci si dovrebbe sedere attorno a un tavolo e decidere se e come supportare JS.
Quanto a Ext, personalmente lo trovo un bellissimo strumento, con grandi idee MA con delle disorganicità abbastanza pesanti. Qualche bucherello ce l'ha, ma chi ha scritto software senza buchi scagli la prima pietra!
 
-- 
Ciao!
Luca
 

 una enormità di codice al programmatore.
 
Domanda: perché avvisare la committenza che si usa Ext?
Detto questo, noi abbiamo scritto tutto a codice, ma so che c'è il designer (l'ho scaricato, devo ancora trovare il tempo per provarlo...).
 
-- 
Ciao!
Luca

 dire che una (o anche piu') delle affermazioni di cui sopra non e' vera.
 
Mah. Io trovo che, pur implementando unit testing (che non hai citato!), il ricorso al debugger sia abbastanza importante. Primo, perché chi è senza bug scagli la prima pietra (*). Secondo, perché ti consente di seguire il filo logico dell'applicazione e verificare se ciò che avevi pensato è effettivamente quanto è stato realizzato.
Prima che tu lo dica, si, mi è capitato di pensare 'ma che cavolo avevo per la testa?', riguardando il codice scritto magari solo qualche ora prima.
 
(*) E' stato grazie a questo principio che la settimana scorsa ho scoperto un buco in una libreria che impiego, abbastanza fastidioso perché si manifestava in modo erratico.
 
-- 
Ciao!
Luca

 per chi scriveva il compilatore 
 
Già. Il C è sostanzialmente un Assembly ben vestito. Parlavo giusto la settimana scorsa con il mio referente presso un cliente, che mi diceva che praticamente lui per i microcontrollori l'Assembly non lo usa più, è quasi tutto C.
 
Certo che ti dava una libertà (compreso quella di fare danni)... ;-)
 
-- 
Ciao!
Luca

 Domanda: perché avvisare la committenza che si usa Ext?
 
glie lo vorresti nascondere?
parlando della interfaccia grafica non vedo come tenerlo fuori da questa 
scelta. parlo di un committente (cioè uno che *commissiona* un progetto) non
di un cliente di prodotto.

 scelta. 
 
Io ci vedo due cose distinte: 1) come deve essere fatta l'interfaccia, 2) in che modo la realizzo. Mentre per quel che riguarda il primo aspetto sono d'accordo con te, non lo sono tanto per il secondo (sempre a meno del vincolo che ho citato sopra). 
 
-- 
Ciao!
Luca

 Io ci vedo due cose distinte: 1) come deve essere fatta l'interfaccia, 2) in che modo la realizzo. 
 
in teoria.
in pratica, i rich ui framework come extjs hanno un look&feel che di fatto 
li identifica.  

 li identifica.
 
OK. Allora mi viene la domanda.
Normalmente sei tu che presenti una bozza al tuo committente o è il tuo committente che ti indica anche il 'look and feel'? E nel primo caso, presenti una sola bozza o ne presenti più di una, in modo che il committente scelga?
 
-- 
Ciao!
Luca
 
 

 bypassano il problema, ma IMHO creandone altri ben peggiori :-)
 
Oh questa giuro è inaspettata, esempi degli accrocchi ai quali ti
riferisci?

 Certo che ti dava una libertà (compreso quella di fare danni)... ;-)
 
Ne da ancora e non solo se fai embedded, basta cercarsi il lavoro (o
l'hobby, se basta quello) giusto!.

 l'hobby, se basta quello) giusto!.
 
Era una valutazione personale (assieme a una lacrimuccia che mi è scesa).
Oggi faccio danni in altri modi...
 
;-)
 
-- 
Ciao!
Luca
 
 

 committente che ti indica anche il 'look and feel'? 
 
se parliamo di applicativi aziendali e il progetto ha un committente 
normalmente sì, il look&feel lo sceglie lui. anche perché normalmente 
richiedono di adeguarsi a loro standard.

 richiedono di adeguarsi a loro standard.
 
Deduco che hai un committente mediamente più specializzato rispetto al mio. Domanda successiva: tu proponi una bozza o più bozze tra cui scegliere?
 
-- 
Ciao!
Luca


Fratello! Vieni qui che ti abbraccio :D
 
Cmq in realtà non c'è tanta distanza fra le affermazioni di entrambi:
UnitTesting e un po' di mestiere fanno sì che il debugger lo si usi 
principalmente per quei maledetti corner cases dove la logica se ne va a 
quel paese
Spesso sono casi che pur i  test unitari fanno fatica a cogliere, 
appunto perché sono unitari
 
Inoltre ci sono errori a runtime legati all'ambiente, tipo i 
simpaticissimi OutOfMemory su Android quando si gestiscono le foto o la 
deserializzazione di risposte SOAP un pelo enormi
 
 
 
-- 
I fatti mi cosano

 Deduco che hai un committente mediamente più specializzato rispetto al mio. Domanda successiva: tu proponi una bozza o più bozze tra cui scegliere?
 
se il progetto non è grafico non propongo nessuna bozza, o il committente mi
dice come lo vuole oppure lo prende com'è. cioè fare uno studio 
sull'interfaccia grafica è un lavoro a parte. 

 sull'interfaccia grafica è un lavoro a parte.
 
Ho capito.
Premetto, a scanso equivoci (che ultimamente sembra io generi in modo automatico) che la domanda che sto per farti non è per vis polemica ma proprio per conoscere una realtà differente dalla mia.
Come si concorda questo con quanto dicevi più sopra (il cliente sceglie il look & feel, e di conseguenza il framework)? Cioè, ponendo che tu conosca più di un framework per la produzione di UI, gli fai vedere degli esempi generici, magari quelli disponibili sui siti relativi?
 
-- 
Ciao!
Luca


allora: se il committente (sottolineo committente, non cliente) vuole un
look&feel specifico è lui che mi mostra un esempio e io lo riproduco. 
normalmente questo avviene allorché non sono l'unico fornitore e il
committente non vuole avere una casbah di software ciascuno diverso dall'altro.
 
se invece il committente non pone vincoli di interfaccia allora gli faccio
uno studio solo se me lo commissiona (e paga) altrimenti scelgo io 
(solitamente fra gwt/vaadin o jquery ui) a seconda delle necessità. 
 
può capitare che il committente esprima delle riserve quando gli mostro
la prima beta, ma basta pronunciare la parola "pagare" che subito le riserve
perdono d'importanza. studiare un interfaccia e/o formulare delle proposte
*costa* ben più che la realizzazione della stessa, questo è il concetto che
faccio (anzi, facciamo) passare.


 
Con un approccio del genere non mi fai venire un desiderio irrefrenabile 
di diventare tuo cliente.

 di diventare tuo cliente.
 
Però a mio avviso si tratta in modo corretto. 
Meglio che il cliente sappia fin da subito di che morte deve morire; non solo, ma per quanto riguarda una commessa è opportuno che sappia fin da subito che tutti i costi sono a suo carico, e che intervenire a far modifiche in corso di sviluppo - e la modifica al disegno di un'interfaccia è una modifica che può diventare pure piuttosto pesante - ha un costo ed è giustificata solo nel caso in cui abbia una reale utilità.
 
-- 
Ciao!
Luca
 
 

 Meglio che il cliente sappia fin da subito di che morte deve morire;
 > non solo, ma per quanto riguarda una commessa � opportuno che sappia 
fin da subito che tutti i costi sono a suo carico,
 >e che intervenire a far modifiche in corso di sviluppo - e la modifica 
al disegno di un'interfaccia � una modifica che pu� diventare pure 
piuttosto pesante -
 > ha un costo ed � giustificata solo nel caso in cui abbia una reale 
utilit�
 
Se tutti operassero cosi' probabilmente il settore ne avrebbe giovamento.

 per niente male.
 
 
http://www.youtube.com/watch?v=THERgYM8gBM
 
 
 
:-)
 
M.

 M
 
No no, in realtà il commento è appropriato. Le attenuanti del caso sono un controllo di rappresentazione dati fatto esternamente a questo ufficio con specifiche iniziali diverse dall'utilizzo che ne viene fatto adesso, ma in linea di massima sono abbastanza d'accordo.
 
La frustrazione del momento era diretta all'impossibilità di fare test "estensivi" sugli eventi generati dal cambio di focus di tale controllo in quanto i debugger cui ho accesso sono un po' draconici.
 
Ma il commento rimane appropriato.