Tagantjärgi tarkusena võib nentida, et hoolimata teatavast kohmakusest meetod siiski töötas. Mul on siiani selge ülevaade enda CV-Online’s töötatud aastate arengutest, eesmärkidest ja väljakutsetest. Nüüd, kümme aasta hiljem, oskan öelda ka seda, miks arenguvestlus hästi läbi viiduna toimib.

Arenguks on vaja peeglit

Oma töises rütmis toimetades tajuvad inimesed enamasti mõningaid aspekte positiivsena, mõningaid negatiivsena, mõnede osas ollakse neutraalsed. Näiteks pakub neile huvi töö sisu, kuid juhiga pole suhted juba pikemat aega selged ega inspireerivad. Või siis ei ole nad rahul teatud tööülesannete ja -korraldusega. Kui sobivat kujundit otsida, siis võiks võrdluse tuua seenelistega, kes vaatavad vaid oma nina ette, korjates neid seeni, mis söögiks kõlbavad ja visates tagasi neid, mis ussitanud on. Kui ussitanud seeni saab liiga palju, muutub seenelise meel mõruks, sest unistus hõrgust seeneroast muutub üha kättesaamatumaks. Kui sel seenelisel oleks nüüd võtta kaasteeliseks mõni mükoloog või sellesinase metsa ekspert, suunaks too teda pilku tõstma, näitama lagendikke, kus rohkem seeni kasvab, võib-olla andma vajadusel nõu varustuse ja seni tundmatute söögikõlbulike seeneliikide osas. See kohtumine võiks olla seenelisele valgustav ja selle peale tulemine poleks üksi olnud mitte ilmtingimata võimatu, kuid igal juhul aeganõudev.

Arenguvestluse kontekstis on juhil kaasteelise roll. Seejuures ei pea ta tingimata olema seeneekspert: võib olla ka metsatark või lihtsalt inimlik inimene, kes õigeid küsimusi küsida oskab. Küsimustele vastamine ongi inimese jaoks mõtete korrastamine, mis omakorda uutele sihtidele suunab.

Olen rahul, ei ole rahul

Karjäärinõustamisse tulevad sageli inimesed, kelle mureks on töö kaotuse asemel läbipõlemise hirm. Välisel vaatlusel paistab kõik kena – töö on olemas, valdkond tore, tegemist jagub. Ainus, mida pole, on tahe silmade särades seda tööd teha. Lähemal uurimisel selgub, et inimesed on turvalisuse vajadusest tulenevalt end pikalt rahulolematus töösuhtes kinni hoidnud – enne kui julgevad tõele otsa vaadata ja muutusi kaaluda. Üks peamisi põhjuseid, mis alati välja koorub, on see, et ei tööandja ega inimene ise pole endalt küsinud: mida sa tegelikult vajad? Seepärast on töösuhe ajapikku kraavi saanud veereda. Individuaalsed eneseanalüüsi praktikad on Eestis alles viimase kümnendi kasvav trend ja karjäärinõustamist pole ülearu. Samas , juhtimisparadigmade arenguid vaadates, on tööandjatel  karjäärivestluste pidamise teadlikkust ja võimalusi olnud palju varem. Sellegi poolest on eelistatud püsida formaalsete töökesksete arenguvestluste praktikates või vastukaaluks viljeleda täiesti vabas vormis jutupuhumist. Ja tulemuseks on mõlemapoolne pettumus –vestlus ei tööta, see toimub vaid linnukese pärast. Formaalsel juhul ei teki inimesel selle vestlusega emotsionaalset seost – see on see, mida tööandja tahab ega arvesta inimese isiklikke plaane või soove siin elus. Vaba vestluse puhul tekib küsimus: mida nad selle infoga peale hakkavad – kuidas mu koer elab ja kas abikaasa ikka õnnelik on. Väikesest Printsist tuntud metafoor kehtib ka siin: kui oled kellegi taltsutanud, pead tema eest ka vastutama. Neid asju, mida küsitakse, peab reaalselt olukorra parendamiseks ära kasutama. Kogu saadud infoga tuleb süsteemselt ja läbimõeldult tegutseda, sõlmitud kokkulepped peavad vett pidama.

Vestluse võti on väärtused

Kuna väärtused on inimese hingele kõige lähemal olevad, siis tasubki vestlus nende peale üles ehitada. Nõustamispraktika on näidanud, et kui inimese jaoks kolmest olulisest väärtusest kaks ei ole tööandja juures tema jaoks kaetud, siis kannatab nii töörahulolu kui ka pühendumus. Näiteks kui töötaja jaoks on üks olulisi väärtusi paindlikkus, kuid ta tajub, et usaldust pole piisavalt, teda kontrollitakse, nõutakse kohalolekut ka siis, kui töö sisu seda tegelikult ei eelda – siis läheb töösuhe varem või hiljem kreeni. Kui aga arenguvestluse kontekstis seda teemat puudutada, teadvustada ja otsida viise, kuidas organisatsioon ja inimene ise saaksid seda väärtust rohkem tagada inimese jaoks, lähevad asjad paremuse suunas. Tõsi, vahel ei ole võimalik mõnes töörollis mõnd väärtust tagada ja siis tulebki kaaluda rolli muutust, vahel harva ka organisatsiooni vahetust. Teine oluline teema, mida koos analüüsida, on töö sisu. Kui jagada tööroll kolmeks: halvad, head ja suurepärased tööülesanded, siis tasuks jälgida, et nn halbade ja mõttetute tööülesannete osakaal ei oleks suurem kui heade ja suurepäraste. Siin peaks olema juht mentoriks ja suunajaks. Vajadusel on tema see, kes halvad tööülesanded töötajalt ära võtab, nende mõttekust selgitab või aitab neid headeks ülesanneteks muuta. Ning proovib suurepäraseid tööülesandeid juurde leida. Just suurepärased ülesanded on need, mis tekitavad hea tunde ja täidavad seda rolli, mida iga töötaja alateadlikult soovib: et antud töökoht tema konkurentsivõimet suurendaks ja aitaks tagada hüpet üha õnnelikumasse tulevikku.

Juhi tööriist on tema isiksus

Põhilised tarkused, mida lisaks heale meetodile enne vestlust taskusse torgata, on kuulamisvõime ja empaatia. Arenguvestlusel ei ole kohta vastuväidetele: miks sa nii mõtled, oled asjadest valesti aru saanud. Nii nagu inimene ütleb, nii on. Mis öeldud, see kuuldud. Kuulamine ei ole siinkohal oma kõnejärje ootamine ja vastuse mõtlemine, vaid vajadusel vestleja mõtte ümbersõnastamine ja püüd seda paremini mõista. Selleks, et arenguvestlusel tekiks vajalik sünergia, peab juht ise seda nautima, tundma inimese vastu siirast huvi ja hoolima. Tähendab, olema hingega asja juures. Sellepärast on paber ja pliiats innovaatiline meetod, mitte arvutiekraan, kust küsimusi lugeda ja kuhu sissekandeid toksida. Südamega läbi viidud vestluse tunneb ära sellest, et peale vestlust suureneb selgus, tulevad uued ideed ja tekib hea koostööenergia.

Tiina Saar

Kõik sai alguse sellest, kui ühel ilusal päeval rändasin Suurbritanniasse ja sattusin poolkogemata tööle pisikesse startupi nimega Picklive. Seal kasutati minu jaoks tol hetkel (ja tänaseni) väga uudseid ja põnevaid vahendeid lisaks juba tuntud asjadele – Ruby on Rails, XMPP, JavaScript, agiilne metoodika jne. Alustasin ka seal tegelikult testimisest, aga üsna pea selgus, et sellest jääb väheks. Seega asusin tasapisi ka parandama vigu, mis leidsin. Märkamatult kirjutasin juba lisaks päris uut funktsionaalsust.

Mis tegelikult mu mõtteviisi tarkvara arendamise ja testimise kohta muutis, oli hetk, kui otsustasime võtta kasutusele Behavior-Driven Development (BDD) metoodika ning selle elluviimise vahendiks sai valitud Cucumber. Kuigi BDD’d saab defineerida mitmeti, on minu arust pädevaim Dan North’i antud kirjeldus:

BDD is a second-generation, outside–in, pull-based, multiple-stakeholder, multiple-scale, high-automation, agile methodology. It describes a cycle of interactions with well-defined outputs, resulting in the delivery of working, tested software that matters.

BDD definitsiooni järgi tekib tarkvara väljast sisse – esmalt defineeritakse tulemus, mida soovime saavutada, seejärel kirjeldatakse käitumine, mis meid soovitud tulemuseni viib ja alles siis kirjutatakse tegelik programmikood, mis teeb seda, mida me tahame, et ta teeks. Tulemuse definitsioon ja käitumise kirjeldused on esitatud inimloetava tekstina.

BDD ei ole vaid metoodika, see on käsitletav ka mõtteviisina. Meie töö eesmärgiks on luua tarkvara, millest tekib tulu kõigile. Iga planeeritava funktsionaalsuse juures tuleks mõelda, kas see aitab meil (ettevõttel) saada rohkem tulu? Kas see aitab meid kui ettevõtet kuidagi esile tõusta? Kas meie tarkvara kasutajad saavad sellest kuidagi kasu? Kui ei, siis üsna tõenäoliselt ei ole tegu väga vajaliku või kasuliku funktsiooniga. Selle võib seega kas hetkel kõrvale lükata või siis üldse välja jätta.

Samuti lubab BDD metoodika arendajal keskenduda küsimusele, miks üht või teist funktsionaalsust vaja on, mitte vaid sellele, kuidas seda teostada või kuidas üht või teist tehnilist probleemi lahendada.

Nagu enamus agiilseid metoodikaid, on BDD puhul kasutatud lähenemised, mis lihtsustavad arendaja elu ja parandavad koodi kvaliteeti:

• YAGNI (You Ain’t Gonna Need It) – kood kirjutatakse alles siis, kui seda reaalselt vaja on, mitte kunagi „igaks juhuks“. Sellega välditakse koodis liiasusi (code bloat) ning hoitakse kood puhas ja kergesti hooldatav.
• DRY (Don’t Repeat Yourself) – kui sama koodilõiku kasutatakse rohkem kui ühes-kahes kohas, on mõistlik see koodilõik eraldi funktsioonina esitada (Single Source of Truth).
• Red-Green-Refactor – koosta testid, mis feilivad, kirjuta koodi, kuni testid passivad, refaktoori ning korda kogu tsüklit algusest. Tulemuseks on loodetavasti parem ja kvaliteetsem kood, mis endiselt teeb seda, mis vaja.

Cucumber ja Gherkin ehk miks aedviljad nii olulised on

Olles rääkinud sellest, mis on BDD ja korraks maininud ka Cucumberi nimelist vahendit, olekski siinkohal õige hetk lühidalt rääkida sellest, mis see Cucumber selline on.

Cucumber on raamistik, mis võimaldab inimloetava tekstina esitada tarkvara käitumise kirjelduse. See moodustab üheaegselt nii dokumentatsiooni, spetsifikatsiooni kui ka automaattestid. Seepärast nimetatakse selliseid kirjeldusi käivitatavaks spetsifikatsiooniks (executable specification).

Cucumber on kirjutatud Ruby’s ja sobib kõige paremini Ruby koodi testimiseks, kuid on üsna kergesti kasutatav muudes keeltes loodud või loodava tarkvara juures, sealhulgas Java, C#, Python jpt. On olemas mitmeid Cucumberi porte, neist olulisemad ehk:

• Cucumber-JVM – puhtalt Javas kirjutatud port, mis toetab selliseid programmeerimiskeeli nagu Java, Groovy, Scala, Clojure, JavaScript (Rhino interpretaatori abil), Python (Jython interpretaator) ning Ruby (JRuby interpretaator).
• Cucumber.js – Javascripti implementatsioon, mis suudab teste jooksutada otse brauseris.
• SpecFlow – implementatsioon .NET jaoks.

Mingil põhjusel on aedviljad agiilsete vahendite loojatele südamelähedased, seega kannab Cucumberi kasutatav keel nime Gherkin ehk väike marineeritud kurk. Gherkin on äriloetav valdkonnaspetsiifiline keel (business-readable domain specific language), mis võimaldab kirjeldada tarkvara käitumist ilma laskumata detailidesse (kuidas käitumine saavutatud on). Kirjeldused on üles ehitatud lugudena, kõige kõrgem ning üldisem tase on feature ehk funktsionaalsus, mida me luua soovime. Iga feature on omakorda kirjeldatud täpsemalt ühe või enama stsenaariumi (scenario) abil. Näide, kuidas Gherkinis kirjeldada väga lihtsa programmi – kalkulaatori, mis oskab vaid kahte arvu liita – käitumist, võiks olla järgmine:

Feature: Addition
   In order to avoid silly mistakes
   As a math idiot
   I want to be told the sum of two numbers

   Scenario: Add two numbers
     Given I have entered 50 into the calculator
     And I have entered 70 into the calculator
     When I press add
     Then the result should be 120 on the screen

Nagu näeme, on see kirjeldus üheselt mõistetav ning kergesti loetav nii programmeerijale, testijale, analüütikule, turundusinimesele, kliendile kui firmajuhile. Samuti on Gherkin kasutatav enam kui neljakümnes erinevas keeles (kaasa arvatud eesti keeles).

Kuid ainult kirjeldusest, kuidas meie loodav rakendus peaks käituma, ei piisa – rakendus tuleb ka valmis kirjutada nii, et ta meie ootusi täidaks. Ka siin tuleb meile appi Cucumber, mis võimaldab eeltoodud kujul kirjeldusi käivitada kui automaatteste ning annab meile vihjeid, mida peaks edasi tegema.

Luues päris uut funktsionaalsust, on suure tõenäosusega meie stsenaariumide sammud defineerimata – me küll kirjeldame käitumist sammhaaval, aga Cucumber ei tea, mida me nende sammudega silmas peame. Et Cucumber meie stsenaariumidega midagi teha oskaks, peame sammud defineerima – kirjutama koodi, mis vastava sammu kohtamisel käivitatakse. Peale sammude defineerimist uuesti Cucumberit käivitades saame juba tõenäoliselt veateate – meie samm on küll defineeritud, aga reaalset rakenduse koodi, mida definitsioonikood välja kutsub, ei ole veel olemas.

Seega järgmise sammuna kirjutamegi juba rakenduse koodi, kuni meie sammudefinitsioon annab positiivse tulemuse, ning liigume edasi järgmise sammu juurde. Nii tekibki rakendus väljast sisse – alustame kõige üldisemast kirjeldusest ja lõpetame detailidega rakenduse koodis.

Lisaks kirjeldatud “väljast-sisse” metoodikale rakenduse loomisel kasutatakse sarnast, “alt-üles” põhimõtet ka väiksemas mõõtkavas – Cucumberi stsenaariumide kirjutamisel:

• Kuna tulemus on meile kõige olulisem, seega esmalt kirjeldame, mida me saada tahame – koostame Then sammud.
• Oodatud tulemuseni jõudmiseks peame sooritama mingeid tegevusi, seega järgmisena kirjeldamegi need – koostame When sammud.
• Lõpuks, kui me teame, mida me tahame ja oleme välja mõelnud, kuidas me selle tulemuseni võiksime jõuda, saame koostada piisavad eeldused meie stsenaariumi mõtestamiseks – koostame Given sammud.

QA roll BDD tiimis

Kuigi siiani olen rääkinud BDD metoodikast rohkem arendajate poolelt ja testimist vaid möödaminnes maininud, siis ei tähenda see, et testijatel sellises stiilis töötavates tiimides kohta ei ole. Kuigi by definition on BDD metoodikat järgides loodud kood alati 100% ulatuses testidega kaetud (eeldusel, et arendajad järgivad BDD metoodikat rangelt), ei tähenda 100% kaetus veel 100% testitust. Meie käitumise kirjeldused ei pruugi katta äärejuhtumeid, rääkimata erijuhtumitest kategoorias “selle peale me ei osanud mõeldagi”. Iga lisapaar silmi, kes koodi ja toodet üle vaatab, on lisakindlustuseks toote kvaliteedile ning testija kaasamine aitab vältida olukordi, kus meie 100% testidega katvust pakkuva moodsa arendusmetoodika põhjal kirjutatud rakendus võib piinlikult triviaalsetes olukordades katkiseks osutuda.

Samas testija BDD tiimis ei peaks olema ainult testija, vähemasti mitte klassikalises mõttes. Täiesti vabalt võib (ja tegelikult isegi peaks) sellises keskkonnas töötav testija olema piisavalt pädev kirjutama rakenduse uute funktsioonide kirjeldusi nii feature kui scenario tasemel, koostama stsenaariume erijuhtude katteks ning neid sammudefinitsioonidega varustama, ideaaljuhul suutma ka rakenduse koodi sisse viia lihtsamaid parandusi ja täiendusi.

CukeUp! 2012

Kuna tegelikult ajendas seda postitust kirjutama hoopis aprilli alguses külastatud konverents CukeUp! 2012 Londonis, siis mõne sõnaga ka seal kuuldust. Põhilised teemad keerlesid Cucumberi ümber, räägiti selle erinevatest portidest (Cucumber-JVM, Cucumber.js), sellest, kuidas Cucumberi variatsioon Calabash võimaldab testida mobiilseid rakendusi otse seadmel ja kuidas rakendada BDD mõtteviisi embedded riistvara disainimisel jpm.

Isiklikult jäi rohkem meelde Colin Humphreys’i loeng teemal, kuidas testida mitte ainult stsenaariumidega kirjeldatud tarkvara käitumist, vaid ka seda, kas meie stsenaariumid ja featuurid täidavad nende kirjelduses püstitatud ärieesmärke. Samuti jäi kõrva Chris Roff’i loeng Cucumberi kirjelduste kogumi kui elava dokumentatsiooni teemal. Lisaks rääkis Elizabeth Keogh väga köitvalt teemal: mida teha siis, kui meie oodatavad tulemused ei olegi väga täpselt määratletud, ja kas häguste eesmärkide puhul on endiselt võimalik testimist automatiseerida.

Natuke teistlaadi teemana oli väga põnev kuulata Karl Krukow’i loengut Calabashist – Cucumberi variandist, mis on mõeldud mobiilirakenduste testimiseks otse füüsilisel seadmel või emulaatoris. Calabash on kasutatav nii iOS kui Android seadmetel, lisaks pakutakse ka pilves elavat testimise teenust nimega LessPainful, mis võimaldab arendajatel oma koodi testida erinevatel seadmetel, mis on kõik füüsiliselt olemas, mitte emuleeritud. Seejuures testida saab mitte ainult ekraanil toimuvat, vaid on võimalik kasutada ka näiteks kaamerat, GPS’i, füüsiliselt seadet keerata (seadmed on paigutatud paneelile, kus servomootorid neid füüsiliselt keeravad, videodemonstratsioon antud võimalusest tekitas kuulajates korralikku elevust) jne.

Päeva lõpetas diskussioon teemal, kuhu Cucumber edasi liikuda võiks, millised võimalused peaks kaotama, millised lisama. Diskussioonis osalesid Matt Wynne, Aslak Hellesoy, Oriol Gual, Julien Biezemans ning Jonas Nicklas, kes kõik on püüdnud Cucumberit viia uutesse suundadesse (Cucumber-JVM, Spinach, Turnip, TextMapper) ja püüdsid üheskoos tuua igaühe head kokku Cucumberisse ning anda ülevaade tehtud vigadest ja neist õpitust.

Kuna räägiti palju ja erinevatel teemadel, ning kõiki loenguid nende paralleelselt toimumise tõttu ei jõudnud isiklikult külastada, siis kogu asjast lõpliku ülevaate saamiseks kulub ka minul veel natuke aega. Huvilistel on võimalik kõiki loenguid koos slaididega videos jälgida siin.

Ükskõik mida scrumipuristid väidavad, reaalsuses on meeskonnal sageli samaaegselt käimas mitu projekti. Need on reeglina erinevad tooted, mida arendatakse paralleelselt ja mille kõigiga on seotud sama grupp inimesi. Nende prioriteete seatakse ühiselt ning sageli peavad need tooted koos toimima ning kasutama samu reliisitsükkleid. Senini polnud Jiras/Greenhopperis niisuguste projektide taskide ühiseks planeerimiseks ja vaatlemiseks mugavat võimalust. Selle tulemusena kippus sprintide skoop minu kogemusel ähmastuma ja pidev projektide vahetamine planeerimisel tekitas osalejais segadust. Sprindi käigus proovisime seda probleemi lahendada eraldi projektideülese füüsilise scrumboardiga, aga selle haldamine oli üsna ebamugav (kuigi hi-level füüsilist scrumboardi kasutame siiani).

Now ladies and gentlemen, put your hands together for – Rapidboard. See on võimalus mitut vabalt valitud projekti mugavalt ühiselt planeerida ja prioritiseerida, kasutada nende arendamisel ühist sprinti ning kuvada kõigi projektide taske samal tahvlil.

Planeerimine
Rapidboard pakub sprindi planeerimisel head tuge. Nimelt kuvab ta kõikide projektide taskid samas prioritiseeritavas nimekirjas ning võimaldab seega määratleda ülesannete olulisust palju selgemini. Senine alternatiiv oli planeerida prioriteete projektipõhiselt. Kasutajaliides töötab analoogiliselt Greenhopperi kasutajale tuttava “Planning boardi” omaga. Lisaks prioriteetidele saab päris mugavalt sisestada ka taskide storypointe.

Ühised sprindid
Projektide koondamine rapidboardile võimaldab nendes projektides mugavalt kasutada ka ühist sprinti. Või tegelikult tuleb öelda, et rapidboardi projektid kasutavad ühist sprinti. Senini oli erinevates projektides ühise sprindi kasutamine üsna tülikas (üheks võimaluseks oli näiteks samanimelise ning sama alguse ning kestvusega sprindi loomine kõikidesse projektidesse eraldi). Lisaks jätab Rapidboardi sprintide kasutamine võimaluse määratleda projektipõhiselt ainult reliise ja jätta sprindid puhtalt rapidboardile. See omakorda aitab puhtamana hoida toodete changelogi.

Kui taskid on olulisuse järjekorda tõstetud saab sprindi skoobi tähist tirides määrata millised ülesanded sprindis tehakse ja millised jäävad skoobist välja. Hiljem on samal moel võimalik vajadusel sprinti ka uusi ülesandeid juurde võtta. Kui skoobitähis on paigas jääb vaid üle teha üks nupuvajutus ning sprint algaski.

Ühine tahvel
Käimasoleva sprindi põhiliseks töövahendiks on tahvel. Nagu juba öeldud näitab RapidBoard kõikide projektide taskide kaarte ühisel tahvlil. Praegu puudub veel võimalus taski-kaartide väljanägemise muutmiseks aga hetkel tundub mulle, et selle omaduse puudumine oluliselt ei sega. Taski olekute muutmine käib sarnaselt Greenhopperi “Task boardiga” ühest olekutulbast teise tirimise teel.
Hea omadus on võimalus tahvlil olevaid taske grupeerida (swimlanes). Näiteks on võimalik grupeerida blockerid või impedimendid eraldi, või näiteks asignee kaupa – gruppe saab määrata JQLi päringutega. Meie kasutame oma projektides toote- ja komponendipõhist grupeeringut – toode ja komponent annavad parema konteksti kaardil oleva taski pealkirja lahtimõtestamiseks.

Nii planeerimisvaates kui tahvlil on võimalik kasutada eelmääratud taskifiltreid millega näiteks iga osaline saab vaadata ainult omi ülesandeid või kõige olulisemaid taske. Ka taskifiltrid on määratavad JQLi päringutega.

Rapidboard sisaldab olulisemaid raporteid nagu näiteks burndown charti ja taskide kumulatiivset diagrammi.

Minu arvates on Rapidboard vajalik täiendus Greenhopperi agile töövahendite hulgas, mille pärast võiks isegi Jira versiooni uuendada. Täpsemalt lugege Rapidboardi kasutamise kohta näiteks Atlassiani wikist. Ah jaa, et hiljem poleks ütlemist, Proekspert tõesti müüb Jirat ja Greenhopperit. Seda, kas tegemist oli reklaamiga otsustage ise. Side lõpp.

Kasutajajuhendid on pelgalt jäämäe tipp. Tõeline dokumentatsioon, nõuded, analüüs, testiplaanid, koosolekute märkmed ja arendajate kommentaarid algkoodis – kõik see, mis eelneb kasutajajuhendi koostamisele – omab kordades suuremat väärtust ja kaalu ning selle ajakohane loomine ühes otstarbelise kasutamisega on suuteline andma toote tegelikule arendusele vääramatu suuna ja põhimõttelise tugevuse. Kahjuks on aeganõudev ja närve kulutav kirjatöö vaid väheste jaoks meelt mööda. Kuid panus, mille kvaliteetne dokumentatsioon võib anda kvaliteetse toote tekkesse, on möödapääsmatu tähtsusega.

Suhtumise küsimus

Suhtumine dokumentatsiooni ja selle tekitamisse arenduskeskkonnas on alati olnud valuline. Ühelt poolt tundub dokumenteerimine triviaalse tegevusena. Triviaalsus selles kontekstis tähendab, et kirja pandust ei ole mitte midagi uut õppida. Arendajad ja analüütikud tunnetavad seda ennekõike teravalt, sest omaenda projektis, kus nagunii iga koma ja punkt teada on, ei ole alati kannatlikkust või siis isegi hoolimist kõiki nüansse kirja panna. See siin ongi projektisisese dokumenteerimise Achilleuse kand: nende jaoks, kes on teemas sügavalt sees, tundub kõik vahetu ja arusaadav. Teistele, kes vaatavad asjade kulgu kõrvalt, paistab lugu pooleldi musta maagiana. Mõned osapooled tunnevad endid kahtlemata kõrvale jäetuna ja lõpeks kannatab terve projekti kulg. Triviaalsus on seega ohtlik konnotatsioon, mille ära tundmine tekitab sama palju vastumeelsust kui selle teadlik esile kutsumine. Teadaoleva informatsiooni edasi andmine kolmandale osapoolele, näiteks professionaalsele dokumenteerijale, tundub seega aja raiskamisena, sest mistahes infovahetus puhtalt infovahetuse väärtusega omandab koheselt negatiivse väärtuse, mille eest keegi justkui maksta ei soovi.

Proeksperdi tuumikväärtustega käsikäes

Kvaliteetne dokumentatsioon peab alati vastama loogilistele nõuetele: see peab olema kergesti leitav, kergesti identifitseeritav, täpne ja arusaadav. Sellele loetelule lisan mina omalt poolt veel ühe omaduse: lihtsuse. Lihtsus läheb kokku ka tõeks tunnistatud Proeksperdi põhiväärtustega. Ning lihtsuse saavutamine on sedavõrd loomulik, sedavõrd iseenesest mõistetav, et sellele võiks sageli enam rõhku pöörata. Miks kasutada viite sõna, kui saab mõtte edasi anda kolmega? Miks tekitada polüsüllaabilisi monstrumeid, kui sõnavara võimaldab viidata kontseptidele palju lihtsamate, koduste terminite abil. Taas kord tuleb võidelda uhkeldava, kirju keelekasutuse vastu maailmas, kus sellele tegelikku kohta sootuks ei leia. Lihtsus teksti puhul annab lugejale hindamatu eelise aja ees: energia ja tempo, millega tekstimassiivis sisalduvat informatsiooni hoomata, väheneb eksponentsiaalselt. Kahtlemata ei saa lihtsuse ees ohverdada keerukamat informatsiooni, kui see on vajalik, aga kogemus dikteerib, et kolmel juhul viiest saab sellestki lihtsate sõnadega ümber.

Lihtsuse tegelik väärtus on ülim, mida tarkvaraarenduses edasi on võimalik anda: lihtsa, ent täpse teksti tulemusena on igal osapoolel võimalik üheselt mõista, mis on antud sõnumi sisuks. Lihtsus ja konkreetsus elimineerivad tehtest tõlgendamise tüütu tegevuse – kui miski on pandud kirja, must valgel, ja sellest aru saamine ei kujuta endast hiina mõistatust, siis on juba astutud esimene samm absoluutse tootekvaliteedi poole.

Tehnilise dokumentatsiooni ettekirjutusi on veel, rohkem, kui blogisein neid kvaliteetselt edasi on suuteline andma. Kuid nende edasi andmiseks ei ole põgus artikkel just parim vorm.

Kvaliteetne dokumentatsioon tagab eeldused kvaliteetse toote arenduse jaoks. Peale arendajate on korrektsest dokumentatsioonist hindamatu abiline testimise ja kasutajatoe juures: iga peenemgi nüanss, kui see on kunagi kirja saanud ja vastab tegelikkusele, on kohe varnast võtta. Kuigi avalõigus nimetatud kasutajajuhendita maailm on veel verisulis, siis kaugel see enam ei ole. Areng ja uudsus ei ole fenomenid, mida miski saaks peatada. Ning kuigi täna veel peab näiteks ühe Danfossi draivi konfiguratsiooni tekitamise jaoks läbi töötama pühakirja mõõtu torni manuaale, siis ühel kaunil päeval oleme kord ka toote ees, mis teeb seda kõike sama hästi ja mille kasutamisega saab kasvõi koolieelik hakkama. Banaalsena kõlab mõte, et põhjalik ettevalmistustöö projekti algset dokumentatsiooni luues teeb kogu hilisema elu kergemaks, aga selle väite tõesuses ei tohi kahelda.

Miks me nii tegime?

Põhjused on lihtsad – kommunikatsioon ning kogemuste vahetamine. Proeksperdi Kvaliteediarenduse meeskonnas (Quality Engineering Team, edaspidi QE tiim) töötab kirjutamise hetkel 20 inimest. Üks tiimi juht, teine tehniline kirjutaja ja kõik ülejäänud kvaliteediinsenerid (QA Engineer), igapäevatöises kõnepruugis tuntud ka kui testijad. Pea kõik kvaliteediinsenerid töötavad omaette tarkvaraarenduse projektimeeskondade juures ehk siis kõik QE tiimi liikmed on hajutatud laiali üle terve Proeksperdi. Mõned neist suisa teistes majades kliendikeskkonnas.

QE tiim ja common sense

Testijate üle ettevõtte hajutamisel on kindlad eelised, kuid sellega kaasnevad samuti mõned miinused. Hea, et Proeksperdi QE tiim keskendub ühtlaselt reaalsetele tarkvaraprojekte läbi viivatele meeskondadele, mitte ei ürita olla musta kasti laadne „testijate osakond”. Üks kvaliteediinsener saab suunata terve projekti jooksul tähelepanu oma projektimeeskonnale, korraldada seal testimist ja jälgida, et kogu projekti korraldamine toimiks mõistlikul ja üle ettevõtte kokku lepitud viisil, järgides seejuures common sense ehk ühise kaine mõistuse põhimõtteid.

Millised on miinused? Eks miinused tulenevadki eeliste varjukülgedest. Hajutatus annab meile suurepärase projektimeeskonna sisese kommunikatsiooni, kuid ahendab suhtlust QE tiimi liikmete vahel. Olemas on küll mõnusalt loitev tiimitunne ja ühised õlled saunaõhtul, kuid organiseeritult, homogeenset erialase teabe vahetust puhkenurgas päris niisama lihtsalt ei teki. Inimesi on tiimis päris palju. Järeldus on lihtne. Pole stabiilset infovahetust, seega ei saa olla ka seda, mida me nii väga common sense’ks nimetada tahaksime. Ehk siis oma hajutatusega oleksime justkui olukorras, kus kogenumad saavad kogenumaks ja vähema staažiga meeskonnaliikmetele jääb üle kogemuse omandamise pikavõitu raja läbikäimine – tihti ennekõike omaenese valusatest vigadest õppides.

Jagamine rokib

Kuigi vahest võib näida, et neil, kes teavad palju, pole mahti oma teadmisi jagada, pole asi tegelikult nii hull. Pigem on probleem töökorralduse iseärasustes. Tegelikult meeldiks meile kõigile, kui kaasvõitlejad teaksid, mida ise elementaarseks peame. Toimub ju ühine töö ägedas ettevõttes, kus iga inseneri kogemuste tase on tiimi ja lõppkokkuvõttes terve Proeksperdi tase.

Kuidas siis võimalikult ühtlast teadmiste jagamist korraldada? Tiim peab kokku saama. Ning kokku me saamegi. Lisaks muhedatele tiimiõhtutele korraldame paar korda kuus poolteist tundi kestvaid kogemuste jagamise ettekandeid. Mis on küll hea, aga mitte ideaalne lahendus. Üks räägib, teised kuulavad ja küsivad. Oleks vaja midagi intensiivsemat, mis paneks kõik võrdsesse olukorda. Vastuseks on treeninglaager!

Kes minevikku ei mäleta, selle jaoks on projekt uus

Testijate treeninglaager tundus hea mõte. Algselt küll tiimi väliüritus egiidi all „pikk päev väljas”, aga kava kokku pannes tekkis arusaamine, et ühes päevas polegi nii palju tunde. Esimese treeningpäeva tingimuseks oli, et teeme kõik ise. Ise selle pärast, et oleme küllalt tark ja elukogenud tiim ning meil on tegelikult teineteisele palju öelda. Vähemalt enne, kui mõne välise guru kõnelema kutsume.

Alguses oli ideid teemadeks ohtralt: usability’st automatiseerimiseni, kuid esmapilgul lõpmatusena tundunud kaheksast tunnist jäi peagi alles vaid kuus ja pool. Organiseerimine nõuab oma osa. Keskenduda tuli olulisele – mis meil olemas on ja milline on meie teadmiste ühisosa.

Meil on olemas fantastiline Proeksperdis arendatud, enam kui kümne aastase ajalooga tarkvaralahendus BioXpert. Tähendusrikas projekt, millest Proekspert õigupoolest alguse saigi ja mida on testinud ka selle kirjatüki autor. Viimane pole üldse vähetähtis, sest tarkvara toimimise põhimõte on tausta teadmisteta esmapilgul hoomamatu ja ülejäänud QE tiimi liikmetel oli senine kogemus BioXperdiga pea olematu. Kõlab just kui päris tarkvaraarenduse projekt.

Nimetatud tarkvara erilisteks plussideks on väga selgepiiriline modulaarsus ja keerukad seadistusliidesed ehk wizard’id. Noid on rakenduses vähemalt viis toekamat ja seega viieks kolme liikmega grupiks treeningul osaleda saanud QE tiimi liikmed väga hästi jagunesidki.

Gruppidesse jaotamise põhimõte oli lihtne. Et mitte aega raisata vaidlustele ja loosidele, lõid korraldajad kõik segamini: erinevad kogemused, erinevad näod. Grupi juhiks sai selle kõige tagasihoidlikum persoon, kes pidi korraldama rollid ja tööülesanded nii, nagu parasjagu oskas.

Täpsustuseks märgin, et kuna BioXpert on isegi seda kunagi kuude kaupa testinule installeerimiseks küllaltki tülikas ja komplitseeritud tarkvara, siis otsustasime loobuda mahlakast installatsiooniprotsessi kogemuse jagamisest ning valmistasime testikeskkonna eelnevalt ette. Kõigile gruppidele oli määratud arvuti virtuaalmasina ja juhistega – juhuks, kui tarkvara tavatult käituma hakkab. Sellele lisaks loomulikult ka tarkvara disaini ja kasutuse dokumentatsioon as is kujul.

Iga paat valib oma kalda ise

Grupid teada, vastutajad samuti. Iga seltskonna juht teadis üritusele eelneval õhtul oma tulevast projekti ehk lahendatavat wizard’it. Teadis ka päevakava, mille jagasime kolmeks osaks:

1. Esimene osa (2,5 tundi)
   • UML-diagrammide joonistamine
   • Ettekanne ühe tiimi poolt
2. Teine osa (2 tundi)
   • Testimise plaani koostamine
3. Kolmas osa (2 tundi)
   • Testimise plaani kaitsmine tiimide kaupa
   • Päeva kokkuvõte

Ühesõnaga, joonista oma wizard’i peale skeemid ja ole valmis neid selgitama. Siis koosta plaan, kuidas viid läbi oma wizard’i testimise ja lõpuks selgita oma valikuid nii, et teised kah usuksid sinu väikese tiimi edusse. Käed vabad, lased vaimul lennata ja vali ise oma tee lahenduseni.

Kui pilk ei hooma, joonista – kui hoomab, joonista ikka

Võib-olla kõlab lihtsalt, aga mis UML? Loomupäraselt puutub iga projektimeeskond kokku tarkvaraga, mis vajab uuendamist. Ehk siis midagi on olemas, aga klient tahab, et Proeksperdis tehtaks igasugu ägedaid asju juurde. Sellise tarkvara dokumentatsioon on just nimelt selline, nagu ta parasjagu on: kindlasti mitte täiuslik. Kui nüüd veel midagi juurde arendada, on ootamatused kiired tekkima. Suure tõenäosusega olemasolevast ja juurde tekitatud dokumentatsioonist ei piisa, et igasugu nurgataguseid main use case väliseid vigu ja anomaaliaid tuvastada. Mis aga aitab, on funktsionaalsuse skeemidel lahti joonistamine.

Tüüpilise algaja testija käitumine tundmatule tarkvarale teste luues on testisammude kirjutama asumine. Seda viga olen korduvalt teinud isegi, uppudes hiljem kombinatsioonide rägastikku ja üsna kindlalt paljud kordavad. Õppisin targematelt, nüüd õpetan teistelegi. UML kirjeldusviis pole loodud niisama ja see ei pea olema vaid analüütikute tööriist. Eriti, kui üks testija on tihti omaette analüütik.

Analüüsida on testijal palju. Kuigi Scrum ja agiilne lähenemisviis üritavad testija rolli arendusmeeskonna ühiseks tegevusosaks sulandada, ei pääse üle eespool mainitud olukordadest. Meil on olemas vana funktsionaalsus, millest me ei tea suurt midagi. Meil on juba kuidagi loodud uus funktsionaalsus, millest me samuti suurt midagi ei tea. Ja kõigele lisaks tahab klient funktsionaalsust, mis ei tarvitse kõigi osapoolte parimatest soovidest hoolimata olla see, mida ta tegelikult väljendas. Kõlab karmilt, aga tootmismaailmas igiammune probleem. „Ütlesin ju, et tahan asja, millega põrgatada, miks te mulle kurika asemel palli tegite?!”

Testija missioon on võimalikult vara mõista, et tema peaks kurikat testima, mitte lootma eksikombel nõuetesse sattunud palli kirjeldusele. Seegi tuleb joonistades ehk suure pildi selgelt esile toomisel kiirelt välja, sest tarkvara funktsionaalsuse toimimise skeeme koostades satume alati küsimuste otsa. Neid küsides leiab ka vastused, mis võivad sillutada teed tegelike ootuste avastamiseni.

Testija kui analüütiku rollis on veel oluline mõista, et peamine kasutusjuht on enamasti kõigile arusaadav, vähemalt selle arendanule endale. Mõistlik ja enesest lugupidav arendaja hoolitseb, et tema realiseeritud use case töötaks. Tihti töötabki, aga ikka tuleb tarkvaras vigu esile. Teada on, et mida hiljem leitud viga, seda kallim selle parandamine on. Varakult olemasolevate, loomisel või äsja loodud kasutusjuhtude lahti joonistamine on see, mis aitab ja juhib meid kiirelt kohtadeni, mida arendaja või algse idee analüütik ette ei näinud. Need on nurgatagused juhud, millele kogenud arendajad viitavad rääkides, et õige testija peab tarkvara kangutama, lõhkuma ja vigu otsima. Vigu saab otsida kogemuste põhjal, tarkvara üdini tundes, kuid ka siis võib kahe silma vahele jäänud haru meid ootamatu exception’i juurde juhatada.

Tagasi treeningpäeva juurde

Tarkvara funktsionaalsuse käitumisskeemide joonistamine pole Proeksperdis midagi revolutsiooniliselt uut. Kogenud testijal on see selliselt käes, et keegi ei märkagi, kuidas tahvlile või paberile harud tekivad. Lisaks on ettevõtte wikis soovitused ja juhised ammuilma kirjas. Oluline on hoopis, kuidas tekib soovitud common sense. Seda skeemide teemat võib igaüks mõista erinevalt, vastavalt kogemusele, kuuldule või loetule. Ent on äge, kui erinevad inimesed joonistavad enda analüüsi skeemiks nii, nagu parasjagu parimal viisil oskavad ja siis neid võrdlevad. Kohtab avastamist ja „ahhaa, nii saab ka” efekti, mis on tunduvalt mõjusamad kui igapäevatöös katsetamine.

Treeningpäeva esimese poole tulemused olid erinevad. Iga tiim tegi põhimõtteliselt sama asja, joonistas diagramme, kuid lähenes lahenduse kujutamisele üsnagi erinevalt. See erinevus avaldus just teise osa töö esitlemisel, mille käigus pidi teiste ees oma grupi testimise plaani kaitsema. Sõnastasime „testimise plaani” nime taotluslikult „testiplaanist” erineva, et ei tekiks ISTQB ainetel krampi testiplaani koostamiseks. Eesmärk oli piiratud aja jooksul tõestada ja demonstreerida, et väike tiim testib ära kogu funktsionaalsuse, mitte rõhuda vormistamisele.

Nõnda näidatigi. Mõned tegid täiusliku joonise sõrmega järje ajamiseks ja kattuvuses veendumiseks. Mõned koostasid joonise järgi klassikalised test case’d. Üks grupp läks aga FitNesse automaattestide kirjeldamise teed.

Mida me sellest kõigest õppisime?

Kaine aja planeerimine ja time boxing töötab! Päeva ettenägelik planeerimine aitas ürituse õnnestumisele väga palju kaasa. Midagi sellist organiseerides tuleb arvestada, et kujuteldav tund kahaneb reaalsuses 10 minutiks. Arvestasime. Ja päev töötas praktiliselt minuti pealt. Kõik said sõna, kõik tööd ja teemad olid lõpuks kaetud. Treeningpäeva lõpus toimuva kokkuvõtte osa hakkis kahjuks ära planeerimata elektrikatkestus, aga sellestki saime üle. Projektorist olulisem on alati enese arusaadav väljendamise oskus.

Arvame, et kõik teavad juba seda, mida mina tean, aga tegelikult ju ei tea! Üllatuslikku informatsiooni jagamist tuli päeval piisavalt ette. Säherdune treeningpäev on suurepärane viis kogemuste jagamiseks ja uute asjade teada saamiseks. Asusime pealtnäha lihtsate ülesannete juurde, kuid lahenduskäigud näitasid, et me kõik mõtleme ja mõistame asju erinevalt. Järelikult on teineteiselt veel palju õppida.

Meeskonnavaim loeb (ja mitte vähe)! Külmas on küll sant istuvat tööd teha, aga kui on huvi, saab kõigest üle. Kuradi külm oli, ausalt! Jope, sall ja müts olid vajalik kostüümi osa. Kes sai, see kasutas kindaid ka. Jagunesime Laitse konverentsiruumides kahte saali ja see, mis vähem külm oli, lõhnas rallipargist sisseimbuva tärpentiini järele. Aga mehed ja naised ei kaebanud vaid rebisid keskendunult tööd murda. Meil on väga äge tiim! Ilma sellise meeskonnata poleks midagi taolist korraldada saanud. Aitäh!

Mõned omapoolsed kommentaarid. Kuna antud juhul pole mul vahet, kas teemas käsitletakse Scrumi või mõne muu õpetuse väärekspluateerimist, siis keskendun sellele, mida nende õpetuste raames müüakse ja ostetakse ehk siis sertifikaadile.

Sertifikaat

Igasugune sertifikaat, diplom ja kraad näitab, et sa oled ära õppinud, kuidas vastav verstapost saavutada. Selle mitteomamine nätab, et sa pole pidanud vajalikuks teemat omandada või asja lõpule viia.

Miks sertifikaat või kraad hea on? See näitab meile, mida inimene oma pädevuse omandamiseks või tõestamiseks konkreetselt ära teinud on. Otseselt halba pole aga ühe tunnistuse omamises midagi. Kogu halb tuleneb pigem hindajatest või süsteemi poolt paika pandud kriteeriumitest.

Kellel on sertifikaadi või kraadi omamise või mitteomamise suhtes eelarvamus (nagu ka artikli autoril), peaks natuke mediteerima, millest see hoiak tegelikult pärineb. Kõik on ju Pavlovi koera kombel õpitav. Kui oled harjunud nägema, et kõik kraadita inimesed on tölplased, siis võtad automaatselt oma joonlauaks kraadi olemasolu tingimuse. Kui oled kogenud, et kõik, kelle CV’s on 20 rida MS’i sertifikaati, on piiratud mõttemaailmaga jobud, siis just nii mõtled järgmise sarnase koolituskogemusega inimese puhul.

Muidugi päris ilma eelarvamuseta ja väljakujunenud vaadeteta ei saa. Küll aga saame mõelda paindlikult, kuidas me ühte sertifikaati suhtume ja kuidas me seda töös ära kasutame.

Minul näiteks on nõue, et kõik minu meeskonna (Quality Engineering Team) inimesed peavad omandama minimaalse kvaliteedi ja testimise alase sertifikaadi, milledest Eestis on kõige lihtsam saada ISTQB Foundation Level tase. Temaatilist kursust õpetatakse ülikoolis, eksam pole päris “lumme lasta”, on mõistliku hinnaga ja ei aegu.

Mida ma sellest sertifikaadist saan

1. Minimaalse huvi indikaator. Ma näen, kas inimest üldse huvitab testimise valdkonnas arenemine. Kui sa sedagi ei viitsi, siis ilmselt ei viitsi sa midagi.

2. Tööturu joonlaud nõuab. Potentsiaalsed kliendid on omandanud eelarvamuse, et sertifikaat (ja vahest ka erialane kõrgharidus) on miinimumnõue soovitud partnertöötajate CV’s. See on nüüd see koht, kus väga midagi parata ei ole. Tahad võistelda hankes, peavad õiged märgid rinnas olema. Ainuke, mida teha saame, on ettevõtte siseselt kaineks jääda ja mitte võtta ainueesmärgiks luua oma tööfassaad sertifikaatidest.

3. Ühine keel. Päris tavapärane on, et niivõrd laiahaardelises maailmas, nagu kvaliteet ja testimine, on erinevate inimeste jaoks samadel sõnadel erinev tähendus. Väidetavalt selliste ISTQB ja muude komiteede eesmärgiks ongi rahvusvahelisel tasandil sõnastiku ühildamine, mis on tegelikult päris üllas, kogu selle sertifitseerimise läbi rahateenimise kõrval. Kui inimesed töötavad aastaid ühes tiimis samale kliendile, siis pole väga vahet, millist sõnastikku nad kasutavad, peaasi, et kõik saavad ühte moodi aru. Meil aga päris nii ei saa. Tiimid muutuvad ja kliendid muutuvad. Kuigi suurema grupi inimeste hulgas enam-vähem ühtse sõnastiku kasutamine ei ole mingi imelabidas, teeb see vähemalt meie sisemise töö kiiremaks ja ühtsete mõistete valimisel on millelegi toetuda. Ka segaduses kliendile saab näidata, et me mõtleme konkreetse mõiste all kindlat asja. Professionaalne nägu kliendi suunal.

Palju ma seda sertifikaati siis tegelikult kasutan

1. Isiklikult veendusin, et mu roostes juhiaju sobib küll teadmata arvu Euroopase tööle tungivate India sertifikaadiomandajatega võistlema (järeldus ISTQB teemaliste foorumite ja blogide kommentaaridest). Mul on hea meel, kui ka minu vestluskaaslasel see kirje CV’s kirjas on. Meil on tööl ja õlleklaasi taga testimise teemal nüüd palju lihtsam rääkida. Kui sa aga ütled, et oled juba ISTQB FL tasemest üle kasvanud, tore, näita, mis värvi vöö sul siis tegelikult peal on.

2. Kui kliendi tingimused nii ütlevad, panen sertifikaati ja kraadi nõudvatesse pakkumistesse just nende inimeste CV’d, kes vastavad tingimused täitnud on.

3. Ühine keel üldiselt toimib. Meil on nüüd ühine sõnastik jah. Väga tore, nüüd saab küsida, kas see sõnastik sobib ka meie päris tööks. Ilmselt 100% mitte, võib olla isegi mitte kolmandiku ulatuses. Ja mis siis. Vähemalt on meil olemas selgeks räägitud alus-sõnastik oma, meie elust möödarääkivate definitsioonidega. Ja selle peale saame ehitada juba meile sobivama kustomiseeritud sõnastiku (oma wikisse).

Sertifikaaditeema kokkuvõtteks

Isiklikult ei viitsi väga vaielda, kas mingi ISTQB FL, Scrum Master jne sertifikaat on meile või maailmale vajalik või mitte. Nagu arvamusartiklis kirjutatud ja ise kogetud, on igasuguse õpetuse pime järgimine, sertifikaadi ülistamine ja silmaklappidega evangelism nõmedused.

Kui me just segi ei lähe ja ettevõtte ette suurt ning uhket ISTQB FL lippu ei tõmba või konverentsidele sellega laiutama ei lähe (ehk need kipuvad minema, kes oma fassaadi sertifikaatidele on ehitanud), vaid kasutame seda just selleks, milleks vaja, siis on ju kõik mõistlik. Midagi otseselt üks sertifikaat või raamistik ära ei lahenda, küll aga on igas õpetuses häid ideid või juhiseid, mida ära kasutada ja millele paremate mõtete puudumisel toetuda.

Aga otsustamine on jah kestnud kaua. Raamatu lugemine kusagilt mujalt kui raamatust tundus kahtlane. Ajalehe lugemisest ma saan aru, mida aeg edasi, seda vähem on tahtmist lugeda pikki artikleid ja pealkiri või kokkuvõte on piisav, et kogu meedia sisukusega või sisu puudumisega hakkama saada. Aga päris raamatu lugemine mingi gadgeti ekraanilt… no see läheb kuidagi üle piiri. Või kas ikka läheb?

Sest tagasi mõeldes olen ma pidevalt ikkagi midagi lugenud, mis pole paberil. Esimene elektrooniliselt omandatud raamat oli Kikerikii. Puhas kuld ja tänaseks klassika. Teine pikem loetud teos oli “The Hitchhiker’s Guide to the Galaxy”. Mõlemad loetud linux terminali ekraanilt. Valge tekst mustal taustal.

Siis tekkis mulle Palm Vx. See on endiselt läbi gadgetite ajaloo üks stiilsemaid ja paremini disainitud tehnikaimesid, ma arvan. Keegi ehk nõustub ka. Palmi fenomen oli see, et talle oli omal ajal sama palju rakendusi kui tänapäeval poppidele telefonidele (suhtarvuna kasutajatesse äkki? no igatahes kümneid tuhandeid). Palmiga sai teha erinevaid asju. Palm sai näiteks internetti. Palm -> IR ühendus telefoni -> GPRS data -> Internet. Profit. Väga uudne tehnoloogia aastal 2001. Aga seda kõike kokku ühendada oli päris tore häkk. Ja muidugi siis ka raamatute lugemine Palmist. Ekraan oli küll udupisike, aga lugemiseks kuidagi hea. Pealegi oli sellel väga ilus roheline taustavalgus, mis ka öösel või pimedas bussis lugemise võimalikuks tegi. Ma lugesin igasugu asju, offline veebilehti ka, Plucker-i abil (ma olen suht üllatunud, et see on endiselt olemas). Pluckeril tuli üldiselt konfida aadress ja järgmise Sync nupu vajutamisega oli sisu su Palmis olemas. Wired ja Slashdot ja muud nö isetehtud raamatud. Omaaegne RSS lugeja. Tuleb juba kellelgi Kindle analoogia ka?

Aga raamatutest ikka ka. Üks oli kindlasti Pythoni Tutorial, mille ma Palmi ise konvertisin. Ilukirjandust väga ei lugenud, mäletan viiendat Potteri raamatut ainult. Sellepärast mäletan, et võrreldes eelmiste osadega oli see päris veniv. Ka Palmist. Loomulikult pole mul aimugi, kust see Potteri tekstifail mu kätte sattus.

Vahepeal oli paus. Pikk. Raamatud olid ainult paberist ja riiulis ja üsna harva tehnoloogia teemadel. Aga nüüd äkki, kui järjekordne uus Kindle müügile tuli, käis krõks ära. Fire polnud kunagi variant, võibolla kõik need “eestis ei tööta” teemad alateadlikult mõjutasid ka. Ehk kõik, mida te Fire kohta juba lugesite.

Aga neitsi Kindle siis. Hetkel kõige uuem, Kindle 4, WiFi, ilma puutetundliku ekraanita. Valida oli kas odavam reklaame näitav või veidi kallim ilma reklaamideta – võtsin viimase. Säästukas ikkagi.

Peale paari nädalat ei teadnud ma ikka, mida lugeda või miks sellest lugeda. Riiulis on kümneid lugemata päris raamatuid. Mingil põhjusel oli mulle ette jäänud Jargon File, vahel tuntud ka kui The Original Hacker’s Dictionary. Esimese hooga ei leidnud Kindle versiooni kuskilt ja mõtlesin, et noh, kui vanasti töötas isetegemine, teeks siis nüüd ka. Selgus, et on olemas Calibre, millega saab peaaegu ükskõik millest ükskõik mida e-raamatute vallas teha. Väga nobedalt see ei läinud ja tulemus sisaldas palju tühje lehti, aga vähemalt lingid töötasid. Ilma linkideta sõnaraamat tundus ka kuidagi totter mõte. Niisiis võib öelda, et esimene raamat, mida ma lugesin Kindlest oli sõnaraamat ja selle sinna saamine oli häkk. Elu on imelik ja korduv.

Faile saab saata Kindlesse kas e-mailiga või üle USB. E-mail on lihtsam ja selle abil saab ka oma faile konvertida Kindle formaati. PDF välja arvatud, selle lugemine on tõsine vaev. Eks need on ka põhimõtteliselt erinevad esitlusviisid, erineva eesmärgiga. Üle Amazoni Whisperneti on oma asjade saatmine toimib väikese tasu eest, üle WiFi paistab, et tasuta. USB puhul leidsin netist huvitava asja, et kui html fail ümber nimetada txt failiks, siis oskab Kindle seda ilusti näidata, linke sealhulgas. Miks mõlemad laiendid ei tööta jääb mõistatuseks. Ma ei suuda mingit conspiracy’t ka välja mõelda.

Ekraan. E-ink tehnoloogia on see, mis teeb Kindlest Kindle. Taustavalgustust pole ja väga ei tunne puudust ka. Lugeda on hea, üsna raamatu lähedane, võib-olla raamatut saab veidi pimedamas toas lugeda. Natuke tundub, et tekst justkui põleks sisse, mis seletab nn ekraanisäästjaid ja ilmselt seletaks ka reklaame, mis nende asemel oleks. Ekraan on muidugi kõigest hoolimata täielik ufo tehnoloogia. Alates karbist võtmisest, kui instruktsioon edasi käitumiseks on ekraanil. Mitte kleepekal. Ekraanil. Üldse on seda raske päris välja lülitada. Pilt on alati ees ja see tekitab segaseid tundeid, tahaks nagu kokku hoida midagi. Põhimõtteliselt on võimalik ta muidugi välja-välja-välja ka lülitada, aga seda pole vaja, sest … järgmine teema – patarei ei kulu.

Patareid on sellel asjal tõesti head. Väidetavalt kestab aku antud mudelil kuu aega. Mis tuletab jälle meelde Palmi, mille aku kestis ka nii kaua, et unustasid laadida. Senise kasutuse ja paari nädala lugemise juures pole aku näitaja peaaegu üldse vähenenud.

WiFi. Tegelikult pole märkimisväärne muidugi mitte WiFi vaid Whispernet. Ehk siis ülemaailmne 3G. Poisid pole just lahjalt ette võtnud. Selle koha peal, kus vanasti tehti IR või Bluetooth või USB tegid mehed internetiühenduse. Ja vaatasid, et internetist on vähe, tegid siis ülemaailmse 3G võrgu koostöös väga paljude operaatoritega. Ilma sind detailidega koormamata. Ja kui see tundub “noh mis see siis ikka ära pole”, siis vaata, kui palju läheb aega, et eesti 3 mobiilioperaatorit suudaks milleski kokku leppida. Rääkides sellest, ma vaatasin igaks juhuks üle väidetava Kindle 3G leviala ja Balti riigid koos Valgevenega on katmata, wtf? Keegi rääkis, et see töötas, kommentaare palun?

Muu nägu ja tegu. Väga kerge on. Väga väga kerge. Ostsin mingi ümbrise ka, see kaalub sama palju kui Kindle ise. Ei ole loogiline. Seda tunnet pole, et kukub kildudeks, aga kuidagi liiga kerge on. Nupud on selge klõpsuga, lehekülgede vahetamisel tunduvad isegi liiga tugeva klõpsuga olevat. Amazoni reklaamlause on, et sa unustad ära, et sa seda üldse käes hoiad. No unustaks küll, kui see klõpsumine üles ei ärataks. Käest ei libise, midagi nagu puudu pole.

Tarkvara on nagu ta on. Ma ei oodanud midagi erilist ja midagi erilist ta pole ka. Teksti näitamise või raamatu vaate osas pole midagi ette heita. Raamatute korraldamise osas tahaks nagu midagi enamat. Riiulit või kaanepilte näiteks, asi mis Fire-s vägagi olemas on. Poolelioleva raamatu leiab kiirelt üles, ka siis kui ta lahti pole. Kõik asjad on jagatud lehekülgedeks (sh. Settings), mille juures lehekülgede vahetamise nupud tunduvad väga mõistlikud ja cool lahendus. Klaviatuur ilmub ekraanile ja sellega saab trükkida umbes sama mugavalt kui telekapuldiga. Ehk siis mitte väga. Aga samas lugemise ajal pidevalt pisikesi klahve vaadata oleks ka häiriv, ma arvan.

Ma olen nüüd rääkinud ühest ja teisest, aga mul on pointe ka.

• Viimane Kindle paistab olevat umbes sama meeldejääv seade, kui seda oli Palm Vx. Isegi kui ta ühel päeval enam ei tööta ja Amazon ei toeta seda ja sa ei saa pilvest oma raamatuid enam kunagi kätte, on see ikkagi väga ajalooline ese su kodus. Isegi kui ta aegunud on.
• Isegi, kui miski on omal ajal päris okeilt töötanud (Palm Vx, sünkimine) tasub seda hiljem uuesti ja paremini teha. Kombineerides kokku häkke ja peites nende lipp-lipi peal oleku kasutaja eest, on võimalik tekitada uut kvaliteeti, mille kasutajad tõepoolest on rahul. Kombineerimine on järjest enam ja enam asi, mida tuleb osata. Kindlasti öeldi seda juba ka 30 aastat tagasi.
• Häkkimine on kasulik ja hea, igati entusiasmi täis tegevus. Huvi üles näitamine, mitte kartmine katsetada ja leida viise asju oma äranägemise järgi kasutada. Häkkimine kui teadmiste kombineerimine. Kindle on üks pagana hea häkk.
• Hitchhiker’s Guide ja Kindle ei ole üksteisest sugugi kaugel – http://xkcd.com/548/

Riistvara

Kõik muidugi teavad, et mis tahvelarvuteisse puutub, siis iPad on kõige kiirem, kvaliteetsem, parem, lihtsam ja mugavam. Ega see mind tema juures häirinudki. Häiris rahanumber, mida saada tahetakse. Mõeldes kui halvasti ma lastele nende asjade eest hoolimist olen õpetanud ei tundunud sellise väljamineku tegemine sugugi otstarbekas. Laiade valikuvõimaluste tõttu on Androidi tableti ostmine muidugi ka omaette katsumus. Iseenesest mõistetavalt blokkisin ajus ratsionaalsuse, ignoreerisin “kvaliteetne androidi riistvara maksab palju” reeglit ning ostsin Viewsonic Viewpad 10s-i.
Viewpad 10s on praeguseks juba tootmisest maha võetud aga hea otsimise peale õnnestus see siiski veel Eestist poest leida. Küll palju kallimalt kui ma veebipoodides olnud hindade põhjal maksta oleks tahtnud aga psüholoogiliselt raskeim etapp – valik – oli juba tehtud. Etteaimatavalt olin ümberotsustamise vältimiseks nõus ka rohkem maksma. Täpsemaid parameetreid saavad huvilised Viewsonicu tootelehelt ise ka vaadata aga minu jaoks tähtsamad olid, et seal on korralik NVidia Tegra protsessor, 10 tolline capacitive-multitouch ekraan, wifi ja kuni 32GB MicroSD mälukaardi pesa. 16GB mälukaart tuleb boonusena komplektis veel kaasa kah.

Ametlikult jookseb selle tahvli peal Android 2.2. Aga mitte klassikaline Android (kui mõnda neist saab üldse klassikaliseks nimetada), vaid Viewsonicu spetsiaalne, ilma Gmaili, Android Marketi ja seega ka tuhandete teiste rakendusteta Android. Lisaks sellele ei toeta 2.2 väiksemate ekraanide jaoks disainitud rakenduste automaatset skaleerimist, mis teeb ta tahvelarvutite jaoks küllaltki ebasobivaks (mitteoptimeerituks nagu Google ise ametlikult ütleb). Uuendust Androidi esimesele tahvlitele mõeldud Androidile – Honeycombile Viewsonic ei paku. Nagu ma blogidest aru sain siis seepärast, et riistvara ei vasta Honeycombi nõuetele – tahvlil puudub teine – tagumise külje kaamera. Vist oli veel ka ekraaniresolutsiooni küsimus. Honeycombi riistvara nõuete olemasolu või nende puudumise üle käis aasta esimesel poolel kõva spekuleerimine – ma ei olegi lõplikult aru saanud kas need siis olid ametlikult olemas või mitte. Aga noh, see polegi ehk nii tähtis igaljuhul ametlikku Honeycombi Viewpadile olemas ei ole.

Originaal

Pakkisin tableti lahti, ühendasin laadijaga, lülitasin sisse ja vaatasin kuidas ilus värviline lindudega Viewsonicu logo ekraanile ilmub. See vist oli ka kõige ilusam pilt mida ma originaal Viewpadis nägin. Kui detailidest rääkida siis eriliselt riivas silma kohutav back nupp ekraani paremas ülaservas. Rakendustest proovisin ainult kaasa pandud marketit. Selles pakutav oli pehmelt öeldes kasin ja ega ei tekkinud erilist soovi ka midagi otsida. AngryBirdsi oleksin võinud väidetavalt leida, Youtube player oli ka olemas, ka meiliapp ja brauser.

Õnneks on maailmas inimesed keda ametlike uuenduste puudumine ei piira ning kes on ise kokku pannud Viewpadile sobiva moodsama Androidi. See sisaldab muuhulgas kõiki klassikalisi Google rakendusi ja mis kõige tähtsam ka Android Marketit. Leidsin isegi 2 distrot – ViewComb ja VegaComb. Mõlema installi juhendid on Internetist kergesti leitavad ja jõukohased ka arvutikaugetele

Custom

Distro uuendamiseks on vaja Windowsiga arvutit ja USB A male to USB A male kaablit (huvitav, kas eesti keeles oleks korralik öelda isane USB A? ah ma parem ei hakka siia poliitiliselt ebakorrektseid nalju kirjutama). Viimast (kaablit siis, mitte nalja) Viewpadiga kaasa ei tule ja ilmselt pole teil seda kodus riiulist võtta ka. Minul igaljuhul ei olnud ning polnud ka aega ega kannatlikkust poest ostma minna. Küll oli mul üks katkine hiir ja üks üleliigne USB-A USB-B kaabel. Mõeldud-mõeldud, lõikasin hiirel saba ja juhtmel USB A poole küljest ära, keerasin samavärvilised traadiotsad kokku ja lootsin, et internetis juhendi kirjutanu ei ole olnud veidra huumorimeelega tüüp.

Esmalt proovisin end “parimaks” tituleerivat ViewCombi. Esimene mulje minu jaoks oli veidi liiga papagoivärviline ja inetu kellaga. Samuti tundus, et natuke uimane – ekraanivajutustele reageeris nagu väikse viitega ja homescreenide vahetamine polnud kuigi sujuv. Market ja Gmail olid olemas. Aga ma tahtsin enamat. Kuna juhe oli käepärast (sai küll veidi lühikesevõitu) ja install lihtne otsustasin proovida ka teist distrot.

VegaCombi installi järel lisandus uimasusele veel ka touchscreeni ebatäpsus. Juba screen locki avamine oli üsna vaevanõudev tegevus – rõngakese lukule tirimisega oli tükk tööd. Wifi parooli ei õnnestunudki sisestada, sest vajutades ekraaniklaviatuuril backspace-i tekkis paroolikasti järgemööda number 5-sid. Praktiliselt oli tahvel täiesti kasutuskõlbmatu. Olin veidi mures. Otsustasin, et panen originaaldistro tagasi. Ikka parem kui täiesti mittekasutatav aga GMaili ja marketiga tahvel.

Peale originaaldistro taastamist oli ekraani olukord niivõrd halb, et häälestust ei õnnestunud lõpetadagi. “Next” nuppu ei tabanud mitte ükski ekraanil tehtud vajutus ja ütleme nii, et ekraan sai ikka päris rasvaseks näpitud. Aga tekkis ka sportlik hasart – umbes nagu vanamehel klassikalises loos, kes oli otsustanud visa marliini vastupanu ükskõik mis hinnaga murda.

Tagasi internetti. Segus, et touchscreeni dekalibreerumine oli nii mõnelegi probleemiks olnud. Jättes kõrvale minu jaoks selgelt ebaadekvaatsed arvamused, et “see vist on akuprobleem” jõudsin foorumini, mis soovitas Viewpadi käivitada USB-host režiimis, ühendada hiir, ning selle abil kalibreerimisproge käivitada. See tegi imet – touchscreeni täpsus taastus ning säilis ka peale VegaCombi reinstalli. Samuti kadus ka ilmselt just touchscreeni halvast responsest tulenenud uimasus. VegaCombil on ka endal kalibreerimisproge olemas. Igaks juhuks kalibreerisin veelkord.

Nüüd on tulemus korralik. Touchscreen on täpne, Honeycomb tundub töötvat sama sujuvalt nagu 2 korda kallimal Motorola Xoomil, Youtube videod mängivad. Ka fullscreeenis. Dragon, Fly ühest maailmast teise lendamine käib ilma jõnksatuseta (mis näiteks Xoomil on märgatav).

Eks aeg näitab, kas Xoomist oluliselt halvem koostekvaliteet, 3G, GPSi ning teise kaamera puudumine ka millalgi häirima hakkavad. Seniks võib vist öelda: so far so good.

Valitud, aga tegelt ei olnud ju ka! Ei valinud Kindle Fire’t lugeriks, vaid tavalise Kindle, mis näitab halli ilusat pilti ning ongi just mõeldud ainult selleks. Ühesõnaga tahtsin parimat, aga välja tuli Kindle Fire, sest viimast klikki tehes oli sellel nii soodne hind, et jah pani mõtlema… 199$ tundus täitsa mõistlik juba korraliku tableti eest, teades et IPad on miljon korda kallim ning minu nõudmisi viimane täita ei suutnud. Ehk see siis on parem… Seega tellimus sisse ning head inimesed (Tänud neile!) tõid selle kaugest Ameerika riigist siia. Teadmiseks, et otse Eestisse tellides läbi netikulleri on hind üle 260€. Vot nii!

Mis mulje see Fire siis jätab?

Riistvara

… on üldiselt on ilus ja armas. Korpus on viisakas, ilma ühegi üleliigse vidinata (üks füüsiline nupp ainult) ning aku peab ka täitsa kaua vastu. Vist. Pole veel laadima pidanud peale paari kasutuspäeva, seega selle efektiivsust me alles hakkame veel nägema :) Ekraan on samuti päris terav ning võrreldes Motorola XOOM tabletiga tundub isegi veidi parem. Ühtegi SIM kaarti ega mälukaarti sellele lisada ei saa, seega selline väga teadlikult lihtsaks tehtud gadget. Võrguühendus on tal ainult wifi kaudu ja ka see on täiesti piisav, sest iga mõistlikum telefon tänapäeval suudab tekitada wifi hotspoti, mis tagab ka Kindlega liikudes igal pool leviala. Kokkuvõtvalt ei ole tänapäeval enam mõtet väga riistvarast rääkida, sest kõik vähegi tegijad suudavad mõistliku riistvara kokku panna ning arvamus uutest vidinatest tuleb ikkagi funktsionaalsuse ehk tarkvara pealt!

Tarkvara …

… puhul alustame ikka UI-st. See Amazoni UI skin Android 2.3 peale on täitsa sõbralik ning intuitiivne. Mõnes üksikus kohas ei leia veel küll õiget nuppu, tagasiliikumiseks või kuhu iganes liikumiseks, kuid ilmselt sellistest kasutatavuse mugavustest saadakse peagi üle ning järgmised versioonid on juba täisfunktsionaalsed ja igati nauditavad. Peamised funktsioonid ehk main usecase’d on igatahes väga mõnusaks ja kasutajasõbralikuks tehtud. Iseasi, milliseid peamisi funktsioone sa mitte US&A asunikuna kasutada saad. Sellest ka tahtsin tegelikult kirjutada, aga enne muud kohustuslikud teemad.

Seaded on väga lihtsaks tehtud ning põhimõtteliselt suutis seade end juba kuidagi ise automaatselt ära registreerida, mis on ka äge. Ükshetk peale wifi-sse lubamist ta juba teadis, et tegemist on Marguse kindlega, kuigi ma panin Amazoni konto aktiveerimise peale alguses CANCEL või Later või midagi säärast, asjad toimivad ning kõik minu Amazoni seaded olid juba kasutusel – makseviisid, aadressid jms. Ehk siis nagu midagi erilist konfima ei pea, kuid asi lihtsalt töötab. Muidugi konfijana käisin ikka igaks juhuks kõik seaded ja menüüd üle. Ja mis jääb hinge kriipima, et neid on liiga vähe, aga see on ilmselt minu probleem juba :)

Main-Use cases …

.. on seadmel siiski ajakirjade ja raamatute lugemine ning muusika ja videode tarbimine. Põhimõtteliselt võib raamatute ja ajakirjade juurde lisada ka veel enda dokumentide lugemise ja kommenteerimise ning see on ka põhiline. Veebis surfamine ning emailide lugemine on ka kõik võimalik, kuid see ei paista nii rõhutatult silma ja samas tundub riiulite vahel liikudes kuidagi võõras. Nimelt on UI selline ilus raamaturiiul, millel on väga mugav leida endale vajalik. Ja erinevaid riiuleid, nagu erinevaid desktoppe, on 7: ajakirjadele, raamatutele, muusikale, videodele, dokumentidele ning veebile ja rakendustele. Viimased kaks justkui ei sobi sinna nimistusse ning nad tunduvad ka pigem olulised lisavidinad, milleta ei saa, kuid samas võibolla isegi saaks.

Probleem main-use case’de puhul on aga see, et kõiki ei saa euroopas tarbida. Videosid saaksin Kindle tellijana kuu aega tasuta tellida, aga samas ju ei saa ka! Sest intellektuaalomandi õigused seda siinpool lompi ei luba. Videod pean ikka ise kaabliga peale laadima ning siis vaatama – mis sellest et ma oleks võibolla isegi nõus maksma neid hindasid selle sisu eest, mis seal on kuvatud – need on ühe filmi kohta umbes samad, mis meil kinopilet. Seega miks mitte! Muidugi peab ise laadides alati vaatama formaati, et kõik oleks sobiv mp4. Kui saaks mõne uue playeri peale rakenduste näol, siis ilmselt pole enam seda muret ka, aga rakendustest ma ikka veel ei räägi.

Muusikat saad ka osta ilusti ühe nupuvajutusega ning see oma 5G suurusesse pilve hoidlasse mahutada. Ja õnneks saan kõiki rahustada, et ka selle koha pealt peate te nüüd kokku hoidma hakkama, sest jällegi lubatud ainult US&A-s. Mis on aga positiivne on see, et seda 5G saab ikka kasutada ning oma muusika saab ikka pilve panna ka väljaspool USA-t. Ei teagi, mis selle põhjuseks oli, et mul lubati see CloudStorage lõpuks aktiveerida, kuid ma arvan, et tegemist oli väikese proxy poolt osutatud teenega ;) Õnnestuks Amazonist midagi ostes ka selle süsteemi ära petta, oleks hea, aga vähemalt üks väike võitki olemas suure hiiu vastu.

Õnneks muusikat saab muidugi tarbida samuti nagu videosidki, laed kaabli vahendusel lood Kindle peale ning siis Play! Kindlel on muidu täitsa kuulatavad stereo kõlarid ka, mis vabalt asendavad köögikapil oleva raadio. Nagu arvata, ega nad veel autole, rääkimata muudest kodustest süsteemidest, vastu saa, aga parem kui telefon ja vana duubelmakk igatahes.

Ja nüüd teemast, mis toob naeratuse näole – Raamatud ja ajakirjad. Lihtsalt lähed ja valid poest sobiva välja, maksad mõne raha ning ongi olemas. Ja töötab. Seega see on asi, mis paneb mõtlema, kas on vaja see asi jailbrake’da või mitte. Sest kõik ju justkui töötab ning sisu on ka palju. Ohtlik on muidugi, sest ostmine on lihtsaks tehtud ning kohe parematel riiulitel on selline kraam, mis kutsub ostma… Jah ma ostsin ka Steve Jobsi raamatu kohe… mis teha olen süüdi :)

One-Click buy…

… on jube mugav ja samas jube ohtlik teema. Super mugav on osta ajakirju ja raamatuid ning neid kohe lugema hakata, kuid samas valedesse kätesse juhtudes on jama kaelas. One-click tähendabki ühte klikki, st ei küsita üle kas oled kindel ikka? Samas on võimalus cancel panna seni kuni laeb raamatut alla, mis võibolla vahest ei pruugi väga pikk aeg olla. Seega you decide, kas annate seadme lapsele Angry Birds’i mängimiseks või siis mitte :)

Amazon App Store…

Ei tööta Eestis!!!!! Ja see on ka selline peamine põhjus, miks tunnen, et natukene on puudu veel. Mõned rakendused – failide haldamine, märkmete tegemine ja võibolla veel ühtteist, mida vahel tahaks kasutada. Saan kõige selleta hakkama, aga mõte liigub selles suunas, et vist tuleb jailbrake teha. Tegelikkuses ei ole asi muidugi üldse halb, sest sinna saab panna päris lihtsalt peale omi rakendusi, kuid selleks peaks olema enne olemas mingi file explorer seal. (Kes tunneb huvi otsige kuidas sideloadida rakendusi Kindlesse) Kuna mina sain ta täitsa puhta lehena, siis ei ole veel õnnestunud midagi sinna peale panna. Praegu vist peaks korra saatma Kindle uuesti välismaa reisile, et seal vajalikud asjad peale saaks laetud ning seejärel siis oleks nagu kõik vajalik olemas juba. Seega tuleb veel natukene uurida, kas Amazoni konfi rikkumiseks on põhjust või mitte – palju mugavaid teenuseid ju seal juba olemas :)

Pilv …

Kogu töö peaks põhimõtteliselt käima pilves, sest sisemine ketas on ainult 6,5GB. Kui ostad midagi pannakse see sulle pilve. Vajadusel saad ka alla laadida, aga seda teenust kasutad juhul kui tead, et oled peagi offline. Seega põhimõtteliselt pilv on hea ja valiku vabadus alati on olemas. Seega elu näitab, et järjest rohkem elu liigub pilve suunas.

Web ja email…

Veeb töötab nagu ikka. Harjud selle Amazoni brauseriga ära ja pole nagu suurt vahet, mis brauser on. FB toimib, YouTube toimib, muud portaalid ka nagu, seega see asi OK. Mail toimib ka – AGA. Jah üks väike, või siis suur, aga. Lugeda on tore. Konfid kõik kontod ära ja toimib, aga kirjutada on keerulisem :) Nimelt segab auto-correct feature ikka sajaga. No ei saa kohe kirjutada üldse ja maha võtta seda seadetest ei saa! Õigemini saad, aga see lihtsalt ei toimi. Mõtlesin, et olen kaval ning kirjutan brauseris. Nemad olid kavalamad ja võitsid! Brauseris sama asi peal ning Google on appikarjeid samal teemal täis. Seega mis teha peab jälle tõsisemalt häkkimise peale mõtlema. Või kui vähemalt saaks mõne teise maili kliendi sinna peale oleks ilmselt ka juba võit.

Kokkuvõtvalt on tablet nagu tablet ikka, kuid Amazoni sisu tarbimine on tehtud mega lihtsaks ning tarbimisühiskonna liikmena tahaks ikka tarbida küll. Nii et kas on ikka vaja ikka jailbrake’da jääb küsimusena õhku. Samas ei saa välistada, et järgmine lugu tuleb juba jailbrake’imisest.