Prėjusį penktadienį Brighton’e vyko FullFrontal 2009 JavaScript konferencija, kurioje turėjau progą apsilankyti. Tikrai nenusivyliau!

Šiame blogo įraše susidėjau tai, ką pasižymėjau pats sau beklausydamas kalbėtojų. Pačių kalbų tikrai neketinu aprašinėti – tai puikiai padarė Ajaxian (nuorodas pateikiu), o skaidrės taipogi prieinamos viešai.

Jeigu kažkuris punktas sudomino – palikit komentarą – išplėsiu!

Christian Heilmann – Frontloaded and zipped up – do loose types sink ships

Ajaxian santrauka; skaidrės; garso įrašas.

• Apie “AJAX” programuotojus kalbama žymiai pagarbiau negu apie “JavaScript” programuotojus. Abydna, vienok.
• JS nėra programavimo kalba skirta kiekvienam – ir ne kiekvienas save vadinantis “tinklo kūrėju” turėtu ja užsiimti.
• JS egzistavo gerokai prieš jQuery.
• Naudojant JS kalbą, reikėtų ją naudoti taip, kaip ji buvo suplanuota – gana kurti įvairias abstrakcijas pagal tradicinius OO modelius. JS turi savo stilių – privalu jį išnaudoti ir įsisavinti.
• Saugumo skylės (XSS, XSRF ir t.t.) yra server-side problema – JS dažniausiai yra nekaltas (nors ir išnaudojamas)
• Nepamiršti: http-only sausainiukai sesijoms
• Bet kuris API yra iš esmės saugumo skylė – Firefox greičiausiai yra pati nesaugiausia naršyklė būtent dėl savo plėtinių architektūros. Priminė kažkieno sakinį, kad mash-up’ai yra XSS atakos prieš save patį.
• Išbandyti: dažnos ir paprastos apklausėlės kaip mokymosi metodas komandoje
• Pasidomėti: adsafe.org saugumo rekomendacijos
• Pasidomėti: Google Caja (yra informacijos ir YDN)
  • Kas per saugumo skylė IE su radio mygtukais?
  • Kodėl clearfix nevartotinas pagal Caja?
  • Kodėl tiek daug CSS apribojimų?
• javascript:void(0) turi mirti (žiauria ir negarbina mirtimi)!
• John Resig yra, lyg ir, pažadėjęs, kad jeigu pakankamai žmonių to reikalaus – jQuery pritaikys Caja rekomendacijas
• Pasidomėti: ar įmanoma padaryti YQL injection?
• Pasidomėti: jau egzistuoja OAuth implementacija vien su JS

Robert Nyman – JavaScript: from birth to closure

Ajaxian santrauka; skaidrės.

• Kas čia per įprotis, tikrinti ar dižiąjame ekrane bėgantis Twitter srautas yra cenzūruojamas? Įdomus kultūrinis pokrypis, besivystant technologijoms…
• Nepamiršt: skaityti Dmitry Baranovskiy’o blogą
• Pasikartot: typeof kint == 'undefined' naudojimas
• Pasidomėt: Koks yra globalus this Rhino variklyje (t.y. window atitikmuo naršyklėse)?
• Pasidomėt: YAHOO Module Pattern

Peter-Paul Koch – W3C Widgets

Ajaxian santrauka; skaidrės.

• Pasidomėt: Ar Nokia N900 naršyklė yra fennec? (Atsakymas: taip)
• Mobilaus telefono naudojimas interneto naršymui yra puikus būdas pasimokyti – visos vartojiškumo pamokos gali būti pritaikytos eilinėms naršyklėms
• Ar @media kartu su iPhone’o <meta name="viewport" /> galėtų išspręsti problemą, kad user-agentai savaip interpretuoja pločius kai svetainė yra išzoominta? (Prie alaus PPK patvirtino, kad ketina tą patikrinti artimiausiu metu)
• Kai kuriuose aukšto DPI telefonuose kartais būna sunku paspausti tą vietą kurią nori – ar gali spaudimo jautrumo DPI ir ekrano DPI gali būti skirtingi?
• Nejaugi mobilūs telefonai neturi “ilgai trunkančio skripto” perspėjimų?
• Dėl greičio problemų, rekomenduojama nenaudoti iframe mobiliems telefonams skirtose svetainėse – kaip įgyventi AJAX-išką naršyklės istoriją (back/forward)?
• Dingstantis ryšys yra problema – ir online/offline įvykiai jos visiškai nepadeda spręsti
• Mobilių telefonų kešas yra ~200kb – būtina dar protingiau optimizuoti kodą
• W3C specifikacijos widgetai leidžia tik vieną HTML puslapį – potenciali problema?
• Dalintis widgetais per Bluetooth yra pavojinga
• Animacijos efektai mobiliuose telefonuose veikia lėtai. Iš patirties – ne viskas taip jau blogai, bet optimizuoti ir apskritai elgtis protingai privalu

Stuart Langridge – New things that HTML5 provides to JavaScript hackers

Ajaxian santrauka

• Pasidomėti: underscore.js
• Internetas jau nebėra “programų rašymo platforma”. Tavo svetainė gali būti ta platforma, jeigu atidarysi savo API. Ir net jeigu neatidarysi – yra GreaseMonkey. Reikia tam būti pasiruošus!
• Idėja: naršyklių gamintojai, galėtų turėti standartinį būdą palaikymo tikrinimui, t.y. jeigu tu rašai savo kodą laikydamasis progressive enhancement principo, kartais turi paprastus būdus patikrinti, ar kažkas veiks – o kartais ne (pvz. Operos <event-source/>). O galėtų būti kas nors paprasto, pvz. window.navigator.supports("event-source");

Todd Kloots – More accessible user interfaces with ARIA

Ajaxian santrauka, video įrašas ta pačia tema iš YUI konferencijos

• Idėja: YUI3 šiuo moment palaiko ARIA pridėdami roles ir atributus elementams, su kuriais dirba, pvz. sukuriant YUI meniu JS, susiiję elementai yra teisingai pažymimi. Ar neturėtų viskas būti atvirkščiai? T.y. rolės ir atributai nustatomi tiesiai HTML dar serveryje, o YUI (ar kita biblioteka) inicializuojasi jau naudodami tas roles.
• Toddas kalbėjo apie tai, kaip galima “uždėti ARIA sluoksnį savo sistemoje”. Bet argi nebūtų paprasčiau laikytis “ARIA palaikymo” kaip pagrindinio principo, t.y. tai yra kažkas tokio, ką tiesiog darai natūraliai, negu tai, ką darai pabaigoje, ant viršaus? Lygiai taip, kaip kažkada reikėjo pakeisti mastymą rašant HTML ir CSS, bei išmokti naudoti progressive enhancement, o ne graceful degradation.
• YUI2 palaiko “event delegation“? Čia nuo kada? (Atsakymas: pasirodo, nuo YUI 2.8 – pamiršęs buvau… “event delegation” valdo!)
• Žmonės su normaliu regėjimu, turbūt savo protiniuose modeliuose (kaip išversti mental model?) turbūt be problemų priima, kad meniu dažnai eina iš kairės į dešinę. Kaip tai suvokia aklieji? T.y. kaip jų modeliai susitvarko su tuo, kad meniu navigacija vykdoma “kairė/dešinė” mygtukais, o ne “viršus/apačia”, kai naudojamos ekrano skaityklės?
• Pasidomėti: ar ARIA turi kokį nors “fokusuotos grupės” apibrėžimą, o ne vien tik “fokusuoto elemento”?
• Pasidomėti: accessibility šiuo metu dažniausiai siejasi su pele ir klaviatūra, kaip įvesties įrenginiais – kokie modeliai naudojami kitiems įrenginiams?
• Pasidomėti: ką HTML5 specifikacija sako apie <section/> web application kontekste?
• Pasidomėti: klaviatūros greitųjų klavišų atrandamumas lankytojams su normalia rega

Jake Archibald – Optimising where it hurts

Ajaxian santrauka; tyrimas ir skaidrės

• Ar jis čia skaidres varto su savo WII kontroleriu? Geras!
• Niekada nenaudoti eval(), ypač closure viduje – tai iš esmės nužudo visas JS variklių (V8, TraceMonkey ir t.t.) optimizacijas, nes eval() gali nesunkiai pakeisti kintamųjų aprėptį (kaip išversti scope?)
• Nenaudoti closure per dideliam gyliui, jeigu galima to išvengti
• Niekada nenaudoti eilučių sujungimo, kai jos rašomos į innerHTML, t.y. ne el.innerHTML="<div>"+kint+"</div>", o var s="<div>"+kint+"</div>"; el.innerHTML=s;
• Vengti window.onunload naudojimo, nes nužudomas kešinimas (jQuery jau turi šią problemą – bet ketina išspręsti)
• Švarus ir paprastas HTML, neturintis bereikalingų tagų, pats savaime paspartina selektorių darbą (nes reikia perfiltruoti mažesnį kiekį elementų). Žodžiu, rašyti didelį kiekį nesemantinio HTML (ar tai būtų nereikalingi div, ar table) yra blogai!
• Kiekvienas turėtų pasimokyti pats rašyti vykdymo greičio testus (tik reikia nepamiršti apie “16ms problemą JS”)
• “Optimizuok ten kur skauda” iš tikro tereiškia “nebūk durnas” – visos diskusijos, apie tai kuris ciklas optimalesnis (for prieš while) yra bevertės (nes sutaupo 0.002 milisekundės). Iš tikro reikia izoliuoti tą dalį, kuri veikia lėčiausiai, ir tvarkyti būtent ją. Vargti stengiantis rašyti “teisingą kodą” iš anksto yra beprasmiška – žinot istoriją su “priešlaikine optimizacija”, ar ne?

Simon Willison – Beating server side engineers in their own game

Ajaxian santrauka; autoriaus santrauka

• Pasidomėti plačiau apie E4X
• Mac’ų vartotojai elgiasi… kitaip. Tiesiog kitaip ir tiek.
• Ar eitų NodeJS panaudoti kaip unit testų konsolę? Integruoti į continuous build’us?
• JS nėra “strongly typed” kalba – tai natūraliai yra sunkiau dirbant komandoje. Pasidomėti: kaip tai galima spręsti
• NodeJS ir CouchDB yra labai labai seksi! Kiekvienas turėtų pasidomėti kaip jie veikia, kaip optimizuoja procesus ir kokiais principais yra paremti!