Dar kalbėsiu apie tai, kaip paskutiniu metu internetai yra gadinami, kaip jūs visi esate neteisūs ir kaip tik aš vienas išmanau, kaip Teisingai gaminti svetaines. Apžvelgsiu dalykus nuo <a> iki SEO*, nuo CSS iki usability, nuo W3C standartų iki programuotojų etikos. Prisiliesiu prie nesenų “skandalų” apie vendor prefixes, mobilias prieš “normalias” svetaines, kabliataškius Javascript ir pareikšiu savo Ypatingai Svarbią ir Autoritetingą Nuomonę tais klausimais.

Veiksmas KTU Elektronikos fak.** 101 auditorijoje, registracija gūgluose, aprašymas Veidaknygėje, programa:

• 11:00 Sergej Kurakin – Projekto su 1M lankytojų per dieną apkrovimo paskirstymo istorija;
• 12:00 Sergejus Barinovas – Introduction to Big Data and Hadoop;
• 13:00 Edvinas Aleksejonokas – Python/Django;
• 14:00 Pietūs
• 15:00 Rokas Paškevičius – SEO friendly žiniatinklio aplikacijų kūrimas;
• 15:45 Dominykas Blyžė (taigi čia aš!) – Priekinio galo Kliento pusės kūrimo ypatumai;
• 16:45 Mažvydas Skuodas – Kodo derinimo metodai: Zend, Xdebug, Firebug;
• 17:45 Paulius Paškevičius – KTU LSS projektas
• 19:00 After Party @ Kavinė Kultūra

Renginys nemokamas.

* iš tikro tai apie SEO nieko nesakysiu, nes apie tai kalbės Rokas.

** ne keiksmažodis.

Diskleimeris

Aš esu nusistatęs prieš elektroninį balsavimą (internetu ar ne internetu). Šios diskusijos tikslas buvo įvertinti iššūkius – nepaisant to, kad priėmiau tai kaip “projektą”, kurį reikia įgyvendinti (“niekada negali žinoti, kada seimūnams užplauks ir pasakys – darykit”), nepaisant to, kad po diskusijos šiek tiek galbūt mano pozicija ir sušvelnėjo, aš esu įsitikinęs, kad elektroninis balsavimas yra laiko ir pinigų švaistymas, kuris nesprendžia jokios problemos.

Tokios sistemos šalininkai teigia, kad atidžiau pažiūrėjus į tradicinį balsavimą, turbūt surastume analogišką kiekį rizikų ir peno nepasitikėjimui. Vadovaujantis tokiais argumentais, kodėl mums neperkėlus balsavimo į prekybos centrus? Ten daug kamerų – visi galėtų stebėti internetu, o žmonėms nereiktų eiti toli nuo namų – balsuotojų aktyvumas padidėtų. Arba va, dar geriau – turim kalną nenaudojamų snoriukų – įrenkime balsavimo punktus juose!

Valdžios pasisakymai

Iš apie 30 žmonių, dalyvavusių diskusijoje, keletas buvo iš valstybinių įstaigų, norėčiau išskirti tris iš jų:

• Z. Vaigauskas (VRK pirmininkas) – man trūksta žodžių apsakyti kiek papildomų pagarbos taškų jis gavo tąvakar iš manęs. Man niekad nebuvo nuobodu stebėti jį skaitantį rezultatus per televizorių, tačiau tai kaip jis išaiškino balsavimo organizavimo teoriją ir apibrėžė internetinio balsavimo problemą mane sužavėjo. Profesionalas! Ačiū.
• K. Andrijauskas (IVPK direktoriaus pavaduotojas) – susidariau šiek tiek negatyvią nuomonę. Tikiuosi ateityje ryšys tarp valdžios ir visuomenės bus paprastesnis, o bendravimas atviresnis su požiūriu, kad visi esame viename katile ir vieni kitus palaikome, suprantame ir padedame. Jeigu konkrečiai – man labai nepatiko jo mintis (perfrazuota), kad valdžiai reikia, kad IT specialistai paaiškintų tautai, kad internetinis balsavimas yra saugus. Aš nežinau, ar jis atkreipė dėmesį, kad beveik visi susirinkę IT specialistai buvo skeptikai, t.y. jie patys nėra užtikrinti tuo saugumu. Aš niekada negalėčiau pasisakyti “už”, kai akivaizdžiai matau skyles. IT specialistų darbas yra ne meluoti (ar pagražinti situaciją) visuomenei, o spręsti problemas. Smegenų plovimas yra marketingistų ir piarščikų darbas. Tačiau internetinio balsavimo atveju pagrindinis reikalavimas yra ne “tautos pasitikėjimas”, o “pagrįstas tautos pasitikėjimas”. Bet galbūt aš neteisingai jį supratau?
• R. Rainys (RRT tinklų ir informacijos saugumo skyriaus vedėjas) – per daug nesiplėsiu – šis pasisakymas buvo daugiau reakcija į netiesiogiai susiijusius dalykus diskusijoje, tačiau privalau pastebėti, kad buvo užimta labai gynybinė pozicija. Kita vertus, įgavau šiek tiek pasitikėjimo, kad RRT užsiima naudingais dalykais, ypač saugumo srityje. Galėtų jie tuos darbus geriau komunikuoti – dažnesni pranešimai spaudai tikrai nepakenktų. Jeigu esminiai įvykiai tokie kaip “3 valandas visas Lietuvos srautas keliavo per Rusiją” būtų pateikiami kaip suvaldyti, nereiktų užimti tos gynybinės pozicijos.

Neminint kitų pavardžių (nes nepažįstu), teko nugirsti ir pašalinių pokalbių tarp žmonių, kurie sėdėjo netoliese. Vienas iš tų pokalbių skambėjo labai grėsmingai (gal išgirdau neteisingai?) – “čia viską galima išspręsti techniškai… galimybės yra… viskas bus gerai”. Laikytis tokios nuomonės yra pavojinga. Balsavimas yra nacionalinio saugumo klausimas. Už aplaidų žiūrėjimą į internetinį balsavimą reikėtų bausti kalėjimu ar bent jau draudimu dirbti valstybės tarnyboje.

Problema nr. 0: terminologija ir problemos apibrėžimas

Šiemet teko matyti projektą, kurio dalyviai dar po šiai dienai nesusitarė kaip vadinti tam tikrus veikėjus sistemoje. Spėkit, ar projektas buvo įgyvendintas laiku? Kai nėra suderinti kertiniai terminai, komunikacijos problemos tampa pagrindiniu projekto stabdžiu. Todėl diskusijos įžangoje man pasirodė keista, kad nepaisant išdalintų schemų (žr. pirmą diagramą), nuskambėjo pasiūlymas vadinti tai ką aptarinėjome “e-balsavimu”. Mano nuomone, daiktus reikia vadinti tikraisiais vardais, t.y. mano supratimu visus techninius klausimus aptarinėjome tik “nuotolinio balsavimo, duomenis perduodant Interneto tinklais” aspektu. Todėl ir derėtų tai vadinti tiesiog “balsavimu internetu” – ir nevartoti jokio kito termino.

Problema: autentifikacija

Prieš diskusiją teko perversti Elektroninio balsavimo galimybių studiją, bei šiek tiek nugirsti kitų užuominų apie tai, kad autentifikacija turėtų būtų vykdoma el. bankininkystės sistemose. Pačiame susitikime kalba praktiškai vien apie ID kortelės naudojimą. Manau, kad neverta net analizuoti pirmojo varianto – jis nėra saugus vien todėl, kad kalbame apie finansus, o į pinigus yra nusitaikę begalės sukčių. Internetinė mafija prekiauja kreditinių kortelių numeriais urmu, telefoniniai sukčiai vis bando išvilioti bankų prisijungimo duomenis – tam tikros struktūroms būtų naudinga pasinaudoti jau egzistuojančia vogimo infrastruktūra tam, kad daryti įtaką rinkimų rezultatams.

Jeigu kalbėti apie ID kortelės kodavimo lusto naudojimą, tai didžiausias stabdis turbūt būtų reikalavimas pirkti specialų įrenginį bei jį palaikyti ir įdiegti įvairiose OS. Manau, kad tai yra dar viena saugumo spraga, nes paslaugus “kaimynas” mielai gali “pakonfigūruoti” jūsų tėvų kompiuterius taip, kad jie balsuotų tinkamai. Todėl norėčiau matyti įrenginį, panašų į tuos, kurie naudojami prisijungimui prie bankų, t.y. pats įrenginys yra atskiras nuo kompiuterio, į jį dedama kortelė, įvedamas PIN (2 faktorių autentifikacija yra privaloma) ir iš balsavimo sistemos į įrenginį vedami kodai, o iš įrenginio – atgal į sistemą. Idealiu atveju, įrenginys sugebėtų generuoti (skirtingus) kodus bet kuriai kortelei. Neturiu pakankamai kriptografijos ir matematikos žinių, kad teigti, jog toks įrenginys yra pakankamai saugus, tačiau tikiu, kad teoriškai tai įmanoma ir kas nors turėtų tuo pasidomėti – hell – čia juk iš to verslą galima padaryti.

Dar viena trumpa mintis dėl ID kortelių – jos galioja 10 metų. Ar per 10 metų jose įrašyti pasirašinėjimo raktai netaps nebesaugūs? Kai aš pradėjau krapštyti interneto svetaines prieš daugiau nei 10 metų, MD5 buvo rekomendacija. Bent prieš 5 metus prasidėjo bruzdesiai, kad reikėtų naudoti SHA1 – o dabar jau ir SHA1 yra nebe pakankamas. Lygiai tokiu pačiu greičiu keičiasi rekomendacijos ir raktų ilgiui bei kodavimo algoritmams.

Problema: kriptografija

Nepaisant to, kad toli gražu neesu kodavimo ekspertas, matau keletą klausimų ir spąstų:

• “Balsas” yra labai mažas kiekis duomenų – kodavimo algoritmai yra efektyvūs, kai duomenų kiekis yra didesnis už rakto ilgį. Priešingu atveju tenka generuoti papildomų duomenų, o jie turi būti unikalūs – tačiau tokiu atveju balsas gali nebebūti anonimišku. Būčiau dėkingas jeigu kas nors pataisytų mane komentaruose, jeigu klystu.
• Tam, kad balso anonimiškumas būtų išsaugotas, kiekvienas rinkėjas turi gauti unikalų viešąjį raktą, nes kitu atveju visi balsuojantys už kandidatą A išsiųs tą patį užkoduotą f(A), net jei tai ir su skirtingu parašu g(f(A)). Galima būtų prieš siuntimą užkoduoti dar kartą – h( f(A) + g(f(A)) ), tačiau neesu įsitikinęs, kad tai yra pakankamai saugu, o be to toks variantas apsunkintų realų rinkimų stebėjimą (žr. toliau).

Problema: autorizacija ir “du vokai”

Balsuojant paštu, naudojama dviejų vokų sistema – išoriniame voke yra rinkėjo pažymėjimas, vidiniame – biuletenis. Skaičiuojant balsus biuletenis nuo pažymėjimo atskiriamas, taip užtikrinant balso slaptumą. Tradiciškai, perkeliant įvairias sistemas iš popieriaus į kompiuterį yra gaminamas realybės atspindys. Tačiau taikant tokį principą kartais nukenčia patogumas, o tuo pačiu neišnaudojamos visos elektroninės galimybės. Kompiuteriai ir internetas yra sistemos, kurios turi savo principus, kurie dažnai yra iš esmės kitokie negu realybė. Todėl ir kuriant balsavimo internetu sistemą reikia tai įvertinti ir netgi, sakyčiau, atsikratyti “realybės”, o kurti naują sistemą.

Galbūt ir galima būtų kompiuterinį variantą vadinti “dviem vokais” – autorizacija ir balsas privalo būti dvi visiškai autononimės sistemos. Tačiau esminis skirtumas virtualioje sistemoje yra tas, kad neįmanoma garantuoti voko neatplėšimo – žvilgtelti į voko vidų galima visiškai jo nepažeidžiant. Kalbantis su įvairiais žmonėms, man susidarė įspūdis, kad esminis mąstymo principas yra toks, kad “du vokai” yra kartu iki tol kol “atidaromos balsadėžės”. Aš manau, kad turint omenyje dvilypišką kompiuterių prigimtį – t.y. informacijos gyvenimo laikas yra atomiškai trumpas, bet tuo pačiu ir amžinas, vokai negali gyventi kartu ilgiau negu tai yra absoliučiai reikalinga (t.y. tik “transportavimo” metu) – jie turi būti atskirti iš karto.

Tam, kad užtikrinti sąžiningą balsavimą, yra rekomenduojama, kad rinkėjai galėtų pakeisti savo balsą iki paskutinės minutės. Kad tai įgyvendinti, sudėdamas idėjas, kurias jau minėjau, siūlyčiau patyrinėti tokios sistemos įgyvendinimo galimybę:

1. Rinkėjas VRK programoje ar svetainėje – autentifikatoriuje – įveda savo asmens kodą
2. Autentifikatorius pateikia vieną ar kelis kodus-užklausimus
3. Rinkėjas įdeda savo ID kortelę į kodų generatorių, autorizuojasi PIN kodu ir suveda kodus-užklausimus
4. Gautus kodus-atsakymus iš generatoriaus rinkėjas suveda atgal į autentifikatorių
5. Autentifikatorius sugeneruoja unikalų balso ID ir jam priskiria viešąjį raktą – prireikus, su šiuo ID autentifikatorius gali anuliuoti balsą skaičiavimo sistemoje, jeigu rinkėjas pageidauja balsuoti iš naujo
6. Autentifikatorius išsiunčia privatų raktą, susietą su balso ID, į atskirą raktų saugojimo sistemą
7. Rinkėjas pasirenka kandidatą ir užkoduoja viešuoju raktu
8. Rinkėjas išsiunčia savo užkoduotą balsą su ID į balsų skaičiavimo sistemą
9. Rinkėjas gauna pasirašytą balso patvirtinimą – su šiuo patvirtinimu jis bet kada gali pasitikrinti balsų rinkimų sistemoje, kad jo balsas yra įskaičiuotas
10. Pasibaigus balsavimo laikotarpiui, sunaikinami autentifikatoriuje esantys balsų ID – sunaikinamas bet koks ryšys tarp balso ir rinkėjo. Norėčiau atkreipti dėmesį, kad plačiau žvelgiant, balsas ir “rinkėjo pažymėjimas” niekada nebuvo viename išoriniame voke kartu.
11. Apjungiamos raktų saugojimo ir balsų skaičiavimo sistemos – balsai atkoduojami
12. Rinkėjas, pasinaudodamas savo balso ID, vis dar gali pasitikrinti, kad jo balsas įskaičiuotas, bet tuo pačiu – ir kad jo balsas įskaičiuotas už tą kandidatą, kurį jis pasirinko. Rinkėjas negali meluoti, kad balsas įskaičiuotas neteisingai, nes įmanoma patikrinti ar jo balsas, užkoduotas su tuo pačiu raktu yra identiškas tam, kuris išsaugotas.

Be abejo, teorinės galimybės tiek klastoti balsus, tiek atsekti už ką balsavo konkretus rinkėjas išlieka, tačiau jeigu trys pagrindinės sistemos (autentifikatorius, raktų kaupimas ir balsų saugojimas) yra visiškai nepriklausomos, tos galimybės gerokai pasunkėja. Tuo pačiu, šis variantas išspręstų (bent dalinai – kompiuteriai visada gali meluoti ir rodyti vieną dalyką rinkėjui, o kitą – komisijos nariams…) pasitikėjimo klausimą – kiekvienas rinkėjas galėtų bet kada pasitikrinti savo paties balsą.

Problema: stebėtojai

Aukščiau pasiūlyta sistema taipogi suteikia puikias galimybes stebėti rinkimus partijų atstovams ir nepriklausomoms organizacijoms. Kadangi balso įslaptinimas yra įvykdomas gana anksti viso proceso metu (paliekant tik galimybę jį atšaukti), tai užkoduotus balsus galima skelbti viešai – t.y. duomenys, kurie įeina į balsų kaupimo sistemą nėra identifikuojantys, todėl gali būti išslaptinti ir paskleisti į P2P ar kt. tinklus. Tokiu būdu, pagal tik rinkėjui žinomą ID, pats rinkėjas gali pasitikrinti savo balsą ne tik pagrindinėje sistemoje, tačiau ir pas nepriklausomus tiekėjus. Lygiai taip pat galima būtų viešai skelbti ir atkoduotus balsus.

Toks visiškas atvirumas yra tai, dėl ko internetas apskritai gali egzistuoti ir dabar jau yra įsišaknyjęs. Mano nuomone, užtikrinti sąžiningą balsavimą gali tik panoptikonas. Didysis tokio atvirumo trūkumas – kenksmingų interesų turintys asmenys galėtų “išmušti” balso ID iš (papirkto?) rinkėjo ir patys pasižiūrėti, kad balsas nebuvo pvz. pakeistas ir tokiu būdu keršyti ar šiaip “atsiskaityti” su rinkėju jau pasibaigus visam procesui. Kas yra didesnė blogybė – gili filosofinė diskusija…

Problema: infrastruktūra

Praėjusios savaitės “pasitarime” diskusijos buvo tik įžanginės – paminėti buvo tik principai ir iššūkiai. Pagrindinė tema vis dar išliko kodavimo, tinklų ir žmonių saugumas, bet man šiek tiek apmaudu, kad visiškai nebuvo paliestas serverių klausimas. Iš vienos pusės, atrodo, kas čia tokio – prijungei galingą kompiuterį prie interneto ir turi balsavimo serverį. Tačiau iš kitos pusės, reikia įvertinti stebėjimo galimybes, taipogi ir patikimumo bei gedimų scenarijus.

Jeigu kalbame apie stebėjimą – įgyvendinus viešą balsų duomenų skelbimą, belieka užtikrinti, kad serveriuose sukasi “teisingas” kodas. Manau, kad geriausias būdas tai pasiekti – visas su rinkimais susiijusias sistemas įrašyti į ROM’us, kuriuos galima pakeisti tik fiziniu priėjimu. Sistemų kompiliavimas ir įrašymas į lustus turėtų būti griežtai stebima ir tikrinama procedūra. Iš to turbūt netgi gautųsi visai graži parodomoji ceremonija – skirtingų spalvų čipukai įrašomi, transportuojami į keliose skirtingose vietose esančias serverių fermas, įdedami į tam paruoštas plokštes ir užplombuojami.

Įdomu pastebėti, kad ESBO atsiliepimuose apie internetinį balsavimą Estijoje, yra rekomendacija, kad kol vyksta balsavimas, prie serverių niekas neturi kišti nagų. Aš turbūt rekomenduočiau žengti dar toliau – ne tik kad fizinio įsikišimo neturi būti, bet netgi turėtų būti nedaromos atsarginės duomenų kopijos. Jeigu visa sistema yra pakankamai išskaidyta ir kiekvienas modulis veikia dvejomis pastoviai tas pačias operacijas atliekančiomis kopijomis (kiekviename duomenų centre) – turime pakankamą gedimo valdymo scenarijų (t.y. sulūžo vienas serveris – persijungiam į visais požiūriais identišką kitą serverį, įskaitant pilną RAM kopiją, tame pačiame ar kitame duomenų centre).

Beje, kalbant apie RAM kopijas – įdomus faktas – net jeigu vienas rinkėjas sugeneruoja, sakykime, 20kb duomenų, tai visi rinkimai sutelpa į apie 40Gb, t.y. pastovaus saugojimo įrenginiai yra nereikalingi. “Kietos kopijos” nebuvimas netgi galėtų būti savotiškas pliusas, nes visą sistemą sudarytų tik neliečiamas ROM vykdomasis kodas ir duomenys RAM, t.y. kenkėjiškas kodas patekti į sistemą galėtų tik labai įmantriais būdais.

Problema: silpniausia grandis

Banalu, tačiau bet kuri sistema yra tik tiek saugi, kiek saugi yra silpniausia jos grandis. Internetinio balsavimo atveju silpniausia grandis yra būtent rinkėjų kompiuteriai. Tai yra pagrindinė priežastis kodėl aš kovosiu prieš internetinio balsavimo įgyvendinimą tol kol galėsiu. Jeigu mes sąlyginai galime užtikrinti serverių ir VRK priklausančios programinės įrangos saugumą, jeigu mes galime įgyvendinti papildomas tinklo (transporto) saugumo priemones todėl, kad Lietuvos IPT yra labai neblogai susijungę tarpusavyje (t.y. rinkimų duomenys per užsienį keliautų tik iš emigrantų – pasak ESBO ataskaitos, estai apribojo priėjimą iš užsienio tik ambasadų kompiuteriams), tačiau mes vistiek nežinome pagrindinio sistemos komponento – rinkimų serviso kliento (service client/consumer) būklės.

Aš, kaip atviro tinklo entuziastas, turbūt norėčiau matyti visą sistemą naršyklėje. Tačiau ką daryti su naršyklių įskiepiais? Pasak RRT, Lietuvoje pastoviai stebima apie 17 tūkst. kompiuterių-zombių – visi jie jau yra pažeisti. Jeigu balsavimas vyksta naršyklėje – nėra jokios problemos “pakoreguoti”, kad naršyklė rodytų atitinkamą SSL sertifikatą net jeigu jis nenaudojamas. Sukurti Google Chrome ar Firefox įskiepį, kuris “panaikintų” “nereikalingus” kandidatus balsavimo biuleteniuose aš pats užtrukčiau turbūt mažiau nei valandą.

Atrodytų, kad sprendimas būtų padaryti tai ką padarė estai paskutiniuose rinkimuose – reikalauti, kad vartotojas parsisiųstų konkrečią programą. Tačiau šiuo atveju labai kenčia usability, o taipogi programa turi veikti visose OS ir būti įdiegiama be administratoriaus teisių. Kas blogiausia – nėra jokio būdo patikrinti ką ta programa išvis daro. Jeigu naršyklėje rodomus sertifikatus pasitikrinti žmones galima išmokinti (pvz. atspausdinti lankstinukus su sertifikatų “pirštų atspaudais”), tai pasitikrinti ar apskritai parsiųsta programa yra ta, kurios reikia yra per daug sudėtinga.

Kaip spręsti šią problemą aš nežinau ir, deja, neturiu jokių rekomendacijų ar netgi idėjų. Gal reikia dalinti USB ROM’us su Rinkimų OS?

Ir dar keletas minčių…

Šiame įraše net neprisiliečiau prie rizikos valdymo – apie tai diskusijoje labai neblogą apžvalgą pateikė T. Beinaravičius. Šioje vietoje tik norėčiau pabrėžti, kad nepaisant to, kad esame išdidi ir moderni tauta, Rusijoje ir Kinijoje kompiuterių ir hakerių kiekis, net jeigu mes būtume šimtą kartų už juos gudresni, visada bus daug didesnis negu trys milijonai.

Taipogi nepaminėjau nieko apie įstatyminę bazę – o būtent apie ją estams labai daug rekomendacijų pateikė ESBO savo apžvalgoje. Vienintelis komentaras, kurį turiu šioje srityje, tai pageidaučiau, kad įstatymų leidėjai įtvirtintų Konstitucijos nuostatą, kad referendumai dėl Konstitucijos ar Konstitucinių Įstatymų galėtų būti vykdomi tik tradiciniu, fiziniu, popieriniu būdu.

Tikiuosi, kad bent dalis mano idėjų nėra akiplėšiškai naivios ir kvailos ir tikiuosi, kad atsakingi asmenys, įskaitant LIKS, jas apsvarstys. Norėtųsi, kad tiek mano, tiek kitų žmonių mintys būtų katalogizuotos ir sudėtos mažų mažiausiai į kokį nors diskusijų forumą. Laukiu kitų diskusijų, ir tikiuosi, būsiu Lietuvoje kai jos vyks, arba, kad bus galimybė dalyvauti nuotoliniu būdu!

Bendrai paėmus, kadangi investavau tik pusantros dienos darbo, rezultatas visai patenkinamas – “mobili” Login 2011 programa. Informaciją nukopijavau iš oficialios svetainės – tikiuosi savininkai nesupyks.

Žvaigždutės veikia ir turėtų atsiminti nustatymus iš localStorage, taipogi turėtų veikti ir offline, jeigu išsisaugoti “darbastalyje” (bent jau su Android 2.2). Back mygtukui sutvarkyti laiko pritrūkau, taipogi vietomis matosi animacijos šokčiojimai ir trūkčiojimai.

Pirmojoje versijoje, kurią išmečiau, bandžiau viską pasiekti apskritai be Javascript, :target pseudo-selektoriaus pagalba, tačiau rezultatas gavosi gerokai prastesnis negu galutinis variantas.

Taipogi peržvelgiau akimis Phonegap rekomenduojamus įrankius, tačiau panašu, kad visi jie kenčia nuo tų pačių problemų – mobilios naršyklės labai jautriai reaguoja į ekrano pločio/aukščio pasikeitimus kai tenka animuoti perėjimus iš vieno ekrano į kitą, o išsprendus šią problemą kiek griežtesniais išdėstymo apribojimais, vistiek lieka scrollinimo problema – sugrąžinti vartotoją į tą pačią ekrano vietą be ekrano mirksėjimo ir šokinėjimo yra neįmanoma.

Taigi, tam, kad sukurti pakankamai patogų interfeisą, reikia rašyti daug kodo eilučių. Tai natūraliai turi įtakos veikimo greičiui. Tam, kad sistema veiktų greitai, kartais tenka aukoti funkcionalumą, o kartais tenka rašyti visiškai nesuprantamą galvosūkį keistų simbolių, kurių net patyrę programuotojai nesupranta. Tam, kad kodas būtų lengvai skaitomas ir nekeltų daug problemų, kai reikia jį tvarkyti, tenka aukoti kitus dalykus, pvz. tą patį accessibility. Kad padaryti kažką arčiau tobulumo, tenka sugaišti begalybę laiko ir pinigų, ir tada atsiranda problema su tais, kas užsakinėja muziką.

Žiūrint prezentacijas, įvairūs specialistai vis kartoja savo srities mantras – “daryk taip ar anaip, ir sutaupyk trečdalį sekundės siuntimo laiko”, “agile procesas sako, kad nereikia per daug laiko skirti planavimui”, “user centered procesas sako, kad reikia skirti pakankamai laiko vartotojų tyrimams ir pasiruošimui”. Dar anądien ir pats norėjau parašyti blog’ą apie tai, kaip paprasta naudojant naujus HTML5 atributus ir elementarias “geriausias praktikas” suprogramuoti patvirtinimo dialogą, kuris veikia visose situacijose, įdedant “vos keletą eilučių daugiau” kodo (gal ir parašysiu kada kai bus gera nuotaika).

Atmetus seną gerą taisyklę, kad iš “gerai”, “pigiai” ir “greitai” galima pasirinkti tik du, aš savo kasdieniame darbe, kodą rašau remdamasis maždaug tokiais principais:

0. Kodo grožis – žr. paskutinį punktą šiame sąraše.
1. Produkto patogumas – aš linkęs paaukoti labai daug kitų dalykų tam, kad galutinis rezultatas patenkintų galutinį vartotoją – ar tai būtų klientas, ar kitas programuotojas naudojantis mano API.
2. Minimalizmas – jeigu kažko galima nedaryti – aš padarysiu viską, kad to nedaryti. Šitas principas iš esmės paaiškina du žemiau esančius punktus. Papildoma taisyklė – blogas programuotojas tas, kuris nėra tinginys.
3. Palaikymo kaina – iš esmės susiveda į tai, kad reikia rašyti mažiau kodo ir reikia jį organizuoti kuo mažesniais, suprantamais gabaliukais. Visa tai galutiniam rezultate reiškia a) mažiau šansų vabaliukams b) lengviau suvokti. Be abejo, sutrauktas ir minimalizuotas kodas nereiškia, kad jis yra lengviau suprantamas ar palaikomas (čia ypač tinka kalbant apie tokius dalykus kaip visa Perl kalba, regex arba LINQ) – šis principas yra iš esmės narciziškas ir remiasi į tai, kad atėjęs kitas žmogus nesugadins veikiančio dalyko.
4. Sukūrimo kaina / produktyvumas – šis punktas yra skiriamoji linija – dėl visko, kas yra aukščiau jo, aš linkęs aukotis ir sėdėti viršvalandžius. O kalbant apie tai, kas yra žemiau jo, tai tikėtinas variantas yra, kad aš paliksiu @todo žymeles.
5. Standartai, best practices ir “teisingumas” – šis principas anksčiau būdavo gerokai aukščiau šiame sąraše – turbūt dėl to dabar dėl tokių dalykų nebereikia jaudintis, nes jie ateina natūraliai. Tiesiog, įvertindamas kitus faktorius mieliau pasirinksiu paprastumą vietoj devynaukščio objektinio dizaino pattern‘o. “Teisingumas” šiuo požiūriu reiškia puritoniškumą ir naivų idealo siekimą, o ne tiesiog “veikiantį kodą”.
6. Accessibility – iš dalies čia truputį gėda. Iš kitos pusės, lygiai kaip ir su standartais ir “teisingumu” – tiesiog esu įpratęs padaryti tam tikrą kiekį šito darbo automatiškai ir nesistengdamas, o daugiau papildomų pastangų tam nededu, nes jos daugiau kainuoja, negu duoda naudos.
7. Plečiamumas – praktiškai niekada nededu papildomų pastangų vien tam, kad patenkinti vidinį spirgėjimą “o jeigu netyčia prireiktų padaryti XYZ” – net jeigu ateityje nepavyksta padaryti chirurgiškai tikslaus, vienos kodo eilutės dydžio, įpjovimo tam, kad sukurti papildomų funkcijų, susumavus vistiek išeina tiesiog pigiau refactorinti ar net perrašyti.
8. Veikimo greitis – čia nekalbu apie varotojo suvokimą/įsivaizdavimą apie interfeisą – daugiau apie realius CPU/atminties resursus. Manau, kad geriausia yra žinoti tobulintinus dalykus, tačiau pasitenkinti tiesiog “gerais programavimo įpročiais” tol, kol nereikia to tvarkyti. O kai prisireikia tvarkyti – visų pirma gerai pamatuoti!
9. Kodo grožis – paminėjau šitą dalyką pirmu numeriu, tačiau labai retai darau taip, kad kodas atrodytų “gražus”. Grožis yra subjektyvus, o patenkinus visus aukščiau esančius reikalavimus, kodas pats savaime atrodo gražus.

Dabar kai jau surašiau juodu ant balto klaviatūra į ekraną, viskas atrodo taip akivaizdu… Ką praleidau? Kokia jūsų prioritetų tvarka?

Moralas toks – jeigu įtrauki į savo kodą failus tiesiogiai iš kitų žmonių serverių, ypač jeigu jų nepažįsti ir nepaklausi jų sutikimo, viskas gali baigtis blogai. Štai pvz. mano blog’as naudoja html5.js – aš galėčiai ramiai pakeisti jį taip, kad jis vogtų jūsų svetainės lankytojų slaptažodžius ir siųstų man. Bet aš neesu blogietis ir to nedarysiu.

Jeigu kam nors reikia įsijungti HTML5 Internet Exploreryje – galima gi paimti ir parsisiųsti tą JS ir pasidėti savo svetainėje. Bet jeigu jau taip gaila srauto – Remy Sharp leidžia tiesiogiai naudoti jo sukurtą versiją iš Google Code SVN.

Man iš tikro negaila, bet pagunda bent pajuokauti yra… Tu žinai kas tu esi. Ar ne?

Pirmas argumentas, kurį gavau uždavęs šį klausimą, buvo tai, kad ranka rašyti, atseit, yra greičiau. Kodėl tuomet teismo stenografuotojai – žmonės, kurių darbas yra rašyti pačiu greičiausiu įmanomu būdu, naudoja (tegul ir specializuotą) aparatūrą? Turint omeny, kaip veikia žmogaus smegenys, kai jis atlieka darbą, kuris jam įaugęs į kraują, aparatūra teikia garantuotą privalumą.

Patogumo požiūriu, tam tikrose situacijose aš pats vis dar teikiu pirmenybę popieriui. Jeigu mokykloje būčiau mokytas kitaip – tokio įpročio neturėčiau. Ir nuo to visai nenukentėčiau – esu įsitikinęs, kad būčiau tik dar efektyvesnis. Turint omeny Twitter paplitimą ir kiek žmonių savo užrašus konferencijose atlieka tiesiai į kompiuterį ir į internetą, akivaizdu, kad patogumas tėra tik įprotis.

Nepaisant to, kad galbūt nukenčia rašymo greitis, aš naudoju spausdintines raides savo užrašuose. Ir nuo to taipogi nieko neprarandu – netgi laimiu, nes mano užrašus kiti žmonės gali įskaityti lengviau. Tiesą pasakius, turbūt rašytinėmis raidėm ir nebemokėčiau rašyt – reiškias lieka galvoj daugiau vietos dalykams, kurie yra naudingesni.

Be abejo, šiame reikale yra ir emocinis aspektas – ranka rašyti laiškai, atseit, yra kažkokiu būdu “žmogiškesni”. Aš nestudijavau psichologijos – nežinau ar tikrai pagrįstas yra šis argumentas, tačiau aš manau, kad mano būsimi vaikai pradės su manim bendrauti “mašininiu būdu” anksčiau, negu pradės eiti į mokyklą – SMS, Skype ir pan. Lygiai taip pat bus ir su jų bendraamžiais. Emocinis aspektas išliks tik siekiant parodyti, kad tai yra mano “rankų darbas” – lygiai kaip ir ranka pieštas, o ne pirktas, gimtadienio atvirukas. Tačiau juk piešti atvirukų žmonės privalomai mokykloje nemokomi. Na, bent jau ne visus metus ir ne kiekvieną dieną. Lygiai taip pat ir su bet kuriais kitais rankdarbiais.

Nesupraskit manęs neteisingai. Aš neteigiu, kad rašyti ranka yra apskritai nereikalingas įgūdis – sugebėti perduoti informaciją primityviais įrankiais yra labai svarbu. Maždaug taip, kaip svarbu mokėti sukurti laužą ir sužvejoti žuvį – elementarus išlikimas. Ir turint omeny, kad visiškai popieriaus atsikratyti artimu metu tikrai nepavyks, treniruotis greitai užpildyti formas derėtų, tačiau mes juk kalbame apie ateinančią kartą – tą, kuri turės gyventi gerokai po to, kai baigsis mūsų pačių galiojimo laikas.

Šiuo metu, nėra nei vieno žmogaus, kuris turi nusipirkęs iPad. Tačiau prieš šimtą metų nebuvo nei vieno žmogaus, kuris turėjo nusipirkęs radiją. Po šimto metų, būsim visi prijungti prie matricos, ir nei rašymas, nei spausdinimas, nei išvis diktavimas nebebus aktualūs. Tačiau šiuo pereinamuoju laikotarpiu, septynmetis, kuris sugeba kompiuteriu atlikti namų darbus yra ateities žmogus, kuris savo laiku galės konkuruoti su milijonais kitų dėl darbo ir mokės jūsų pensijas.

Diskleimeris

Man rūpi klimato kaita. Aš tikiu, kad žmonija yra kalta dėl to. Aš mėgstu gamtą ir noriu, kad mano vaikai ir vaikaičiai gyventų švariame pasaulyje. Todėl nuo rugpjūčio mėnesio šiek tiek savanoriauju Oxfam Ireland ir (tikiuosi) šiek tiek padėjau jiems internetinėje kampanijoje dėl klimato kaitos.

Mano požiūris šiuo klausimu nėra visiškai neutralus, tačiau faktus aš stengiuosi vertinti objektyviai. Mažų mažiausiai, aš stengiuosi patikrinti juos skirtinguose šaltiniuose ir išklausyti abi puses – kartais “vienos tiesos” paprasčiausiai nėra.

Būtent dėl to, per paskutinius kelis mėnesius perskaičiau begalę informacijos apie tai kokiais argumentais apie klimatą “kovoja” skirtingos šio reikalo pusės. Tiesą pasakius, man nelabai patinka kai kurių žaliųjų metodika, nes jie iš tikrųjų atrodo kaip viską pervertinantys verksniai. Kita vertus, jei nuoširdžiai, tai vadinamieji “klimato skeptikai” yra ne skeptikai, o nusišnekantys idiotai.

Mokslas ir faktai

• Kad CO₂ yra “šiltnamio efektą” sukeliančios dujos žinome jau daugiau nei šimtą metų
• Per tą šimtmetį žmonių išmetamų CO₂ ir kitų šiltnamio dujų kiekis išaugo daugybę kartų
• Per tą šimtmetį pačių žmonių kiekis išaugo beveik penkis kartus

Kiek suvokiu aš, paprasčiausiai nelogiška, kad žmonijos veikla pasauliui neturi įtakos. Nes, na, būkim atviri – tai, kas matosi šituose paveiksliukuose yra mūsų kaltė. Lygiai taip, kaip ir daugybė kitų dalykų. Ir skaičiavimai kiek CO₂ dalelių yra ore, bei kokį tai turi efektą klimatui, taipogi atrodo realesni, negu aklas pasakymas “viskas bus gerai”. Nebus gerai – ir geriausiai tai iliustruoja šis simuliatorius.

O dabar grįžtam prie žurnalistų pezalų…

Aš neįsivaizduoju, kaip žmogus parašęs tokį straipsnį gali save vadinti žurnalistu… Elementari paieška suranda kiekvieno pateikto pseudo-fakto paneigimą… Iš eilės:

… aštuntojo dešimtmečio pradžioje buvo skleidžiamas visiškai priešingas aiškinimas: JAV spauda mirgėjo straipsniais apie ledynmetį, kuris tuoj tuoj sustingdys visą pasaulį.

Melas. Faktas: buvo keletas mokslinių straipsnių, buvo spekuliacijų, bet nebuvo pasaulinio sutarimo, kad tai vyksta ir spauda tikrai nemirgėjo antraštėmis. Jeigu iš tiesų tai buvo kelis kartus daugiau straipsnių, kalbančių apie artėjantį atšilimą, negu apie atšalimą.

Kodėl tada taip išplito žmogaus sukelto pasaulinio atšilimo teorija? Yra nemažai manančiųjų – ir ne be pagrindo, – kad ši teorija kur kas labiau tinka spaudai, televizijai ir Holivudui.

Juokingesnio argumento nesu girdėjęs. Nors, turiu pripažinti, Kopenhagoje dabar vykstančio susitikimo įžanginis video tikrai atrodo baugiau negu Ice Age.

Kada gi žiniasklaidai nepatiko skleisti panikos?

Iš žurnalisto lūpų… Ypač, kai už poros pastraipų yra parašoma “O tai įdomu, nes kitas jų politinės evoliucijos etapas turėtų būti terorizmas.” Reductio ad Hitlerum yra geriausias argumentas bet kuriame ginče.

Daugiau kaip 30 tūkst. mokslininkų viešai pareiškė, kad A.Gore’o paskaita – nesąmonė, ir pagrasino jam teismu.

Melas. Faktas: Al’as Gore’as renginyje dalino autografus. Į renginį prisirinko protestuotojų. Vienas iš protestuotojų suriko: “30000 žmonių ketina paduoti jį į teismą”. Jokios naujienos apie tai Reuters. Jokios naujienos apie tai Associated Press.

Iš kur šitas mitas? Prieš dešimt metų kažkas, kas buvo suinteresuotas, sugalvojo peticiją, kad paneigtų, kad klimato kaita egzistuoja. Ją pasirašė 30 tūkst. žmonių. Dalis iš jų (mažiau nei penkiasdešimt…) buvo meteorologai ir klimatologai. Tačiau didžioji dalis – mokslininkai, kurie neužsiima tyrimais toje srityje. Dalis tų mokslininkų išvis neegzistuoja, dalis vardų ant peticijos buvo be pavardžių. Sluoksniai, kuriems tokia peticija buvo naudinga, išpūtė iš to burbulą, ir nepaisant to, kad ši informacija buvo paneigta šimtus kartų, jis vis grįžta ir grįžta…

Įdomus faktas: tabako industrija naudojo lygiai tokią pačią metodiką, bandydami paneigti, kad rūkymas nesukelia vėžio.

Kova su pasauliniu atšilimu, galima sakyti, virto pramone, kurioje pluša ne viena dešimtis tūkstančių žmonių. Juk nė vienas jų nenori prarasti darbo.

Geras argumentas, mat mosklininkai praras pinigų truputį. O kiek pinigų sukasi naftos pramonėje ir kiek yra suinteresuotų pusių, kad problema būtų ignoruojama trumpalaikiam pelnui užtikrinti?

Jeigu dėl klimato kaitos pakils vandens lygis, savo būstą praras apie 20 milijonų Bangladešo gyventojų, o Maldyvų salų išvis neliks.

Tačiau šie mokslininkai taip pat primena, jog mūsų planetos klimatas keitėsi per visą jos egzistavimo laiką, ir ne vieną kartą taip radikaliai, kad beveik lėmė gyvybės išnykimą.

Po šios pastraipos “žurnalistas” kalba apie tai, kad ginčas yra labiau apie tai, “kodėl” keičiasi klimatas. Per paskutinius kelis mėnesius perskaičiau kalną argumentų, kurie skamba maždaug taip:

• Viduramžiais buvo šilčiau – taip, bet tik Europoje ir kai kur Azijoje.
• Marse temperatūra irgi kyla – taip, bet tik Marse. Kituose Saulės sistemos kūnuose – ne.
• Grenlandija prieš 1000 metų buvo iš tikro žalia – absurdas – negana to, kad Grenlandija toli gražu nėra “pasaulis”, bet tokio ledo kiekio susiformavimui reikia tūkstantmečių.
• Tai natūralus ciklinis fenomenas – ir tie ciklai atsispindi temperatūros augime.
• CO₂ kiekis kyla dėl ugnikalnių – taip, bet ugnikalniai taip pat išmeta pelenus, kurie užstoja Saulę ir dėl to pasaulis šąla, o ne šyla. Tikėkimės, kad Vezuvijus vėl užsidegs, ir būsim išgelbėti nuo atšilimo!

Galų gale, o koks skirtumas kodėl? Prisitaikyti prie naujų sąlygų reikia šiandien. Taip – prieš tūkstančius metų buvo ledynmečiai. Prieš milijonus metų išnyko dinozaurai. Ar dėl to verta ignoruoti tai, ką patys prišikome (atleiskit už mano netobulą prancūzų kalbą)? Ar dėl to turime išnykti kaip eilinė gyvūnijos rūšis?

Ir dar truputis…

Mes išrausėme žemę. Išdeginome miškus. Priteršėme vandenynus. Gal jau laikas bent truputį susiimti ir apsikuopti? Aš neabejoju, kad mūsų išmetamosios dujos skatina šiltnamio efektą. Kas bus, jeigu iš tiesų prie to dar prisidės saulės aktyvumas? Natūralūs pokyčiai? Kiek žmonių turi pradėti auginti bananus maistui arba mirti iš bado, kad pagaliau atsibustume ir pažvelgtume į savo godumą? Ir kada žurnalistai pradės tikrinti faktus?

Š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!

Vieną dieną sužinojo, kad kai kurie butai būna neužrakinti. Gal dėl savininkų žioplumo, gal dėl to, kad pametė raktus – nesvarbu kodėl.

Nuėjo bomžas į laiptinę ir pradėjo tikrinti duris. Na ir rado atrakintas. Įėjo į vidų ir šiltai sau miega.

Juk tai nėra įsibrovimas į svetimą valdą, nes nu juk bomžui šalta. Ir tai nėra neteisėta, nes nu juk žalos tai jis nepadarė – išsimiegojo, neprišiko, išėjo. Butas vietoje, visi daiktai vietoje. Vagystės nėra. Žalos lyg irgi nėra.

Anglijoje, gi, žmonės, sakoma, daug uždirba. Todėl pas juos bomžai geriau gyvena. Prisirenka daugiau išmaldos, todėl gali miegoti nakvynės namuose. Todėl Lietuvoje bomžai tiesiog turi teisę eiti į svetimus namus ir ten miegoti.

Ir apskritai, bomžai turėtų įsteigti bomžų partiją, ir kovoti už teisę, kad visi žmonės paliktų duris atrakintas, kad jie galėtų ateiti ir miegoti kada nori. Nes na juk ne įsibrovimas į svetimą valdą ir visi turėtų turėt teisę miegoti svetimuose butuose.