Urmas Kobin: Tulles Indiast tagasi koju Põhjamaadesse, jääb ukse ette Eesti

December 4th, 2015

Globaliseerunud maailm toimib suures osas trendidel ja edukatel mustritel. Neid kopeeritakse ja kohendatakse, proovides olla oma tegevuses edukam ja vältida varasemaid vigu. Võtame näiteks arvutimängude maailma. Kui tekib mingi uuenduslik mäng, leidub alati suur hulk jäljendajaid. Sageli on need edukamad kui esialgne lahendus. Sageli mitte. Kes ei teaks sellist kurioosumit nagu Flappy Bird? Kui selle edu avalikuks sai, hakkasid nagu seened peale vihma ilmuma kõiksugu laperdavate elukate mängud. Sama võib öelda Clash of Clansi, Bejeweldi ning paljude teiste kohta kui rääkida ainult viimase paari aasta mängudest.

Aga räägime trendidest korporatiivses tarkvaraarenduses. Üheks selliseks tundub olevat outsourcemine Indiasse, mis algas eelmise sajandi üheksakümnendatel. Otsa tegid lahti lennufirmad ja IT järgnes peatselt. Kui korporatiivne strateegia nägi ette, et arendused tuleb outsourceda, siis loomulikult läksid sa Indiasse. See tekitas Indias suure programmeerijate nõudluse, mis omakorda viis lõpuks selleni, et sinna on tekkinud softimajad, kus töötab sadu tuhandeid inimesi. Ühes India ettevõttes, millega olen kokku puutunud, töötas sel kevadel umbes 320 000 inimest. Töölesoovijaid on aastas umbes 10 000 000 (ei, ma ei eksinud nullidega).

Aga selline üles skaleerumine ei tulnud probleemideta. Kuna progemisest (mõningate mööndustega – tarkvaraarendusest) sai masstootmine, muutus see tegevus reeglina anonüümseks ja pealiskaudseks. Tellija poolt vaadates muutusid ka arendajad anonüümseks, neist said parimal juhul põhja-eurooplase jaoks raskelt mõistetava aktsendiga hääled telefonis, halvimal juhul veidrate nimedega e-maili aadressid. Muidugi esindasid neid paar projektijuhti, kellel oli ka füüsiline kuju. See, mida vaja teha, kirjutati mahukatesse spetsifikatsioonidesse. Need versioneeriti, hinnati, kinnitati ja allkirjastati. Pandi dokumendihaldusse. Nende põhjal loodi arhitektuuri- ja disainipiiblid, millega toimiti samamoodi. Ja progejad kirjutasid koodi. Nii nagu piiblis kirjas. Kõik edenes by the process ja by the book. Aga kui arendaja ülesandeks on ainult kirjutada koodi spetsifikatsiooni järgi, siis ei mõtle ta sageli selle peale, milleks ning kellele see üleüldse kasulik on? Nii tekkisid paljud teenused, mille suurim väärtus seisnes selles, et need olid arendatud CMMI level 5 firmade poolt täpselt nii nagu tellija kunagi kuid või aastaid tagasi öelda oli osanud. Mitte nii, nagu tegelikult vaja oli. „Bang for buck“ hakkas tellija jaoks kokku kuivama.

Tänaseks on paljud Põhjamaade korporatsioonid hakanud Indiast tagasi koju tulema.

Väga formaalsele arendusprotsessile vastanduvalt tekkinud agile kinnitab viimasel ajal aina enam kanda ka suurfirmades. Selle mantra – klient ja tarkvarameeskond töötavad koos – suunab softi arendust teistpidi majasisestele arendustiimidele, kuhu kohalikult turult lisatakse ettevõttes puuduv kompetents. Tiim töötab reeglina koos samas ruumis, seisab hommikuti 15 minutit ringis kohvitass käes ja ja suhtleb otse äri-inimestega. Hommikul pühib koristaja seinal oleva scrumboardi alt jälle paar maha langenud sticky-t kokku ja ei juhtu ka midagi hullu. Tavaliselt. Agile by the book. Enda tehtud vead koodis on kuidagi armsamad ka. Või vähemalt ei pea nende parandamiseks täitma mitmeleheküljelist Wordi dokumenti veakirjeldusega ja ootama paari nädalat, et viga andmebaasiprotseduuris dokumenteeritaks, analüüsitaks, prioritiseeritaks, parandataks, testitaks ja lõpuks parandus kõigisse süsteemidesse saaks viidud. Pendel on teise äärmusesse jõudmas.

Aga kas see, kui Indias said käpad kõrvetatud, on piisav põhjus pugeda peitu omaenda koopasse ja üritada kõike ise teha? Kui firmajuhid vaatavad marginaalset majanduskasvu ja punaseid börse on surve kulude kokkuhoiuks väga suur. Skandinaavialik sotsiaalkaitsesüsteem ei võimalda ka majasiseseid tiime väga mugavalt “skaleerida”.

Tänapäeva maailmas rääkida sellest, et arendustiim peab istuma ühes toas, et olla efektiivne, on minu arvates veider. Kui ma satun ükskõik, millise Proeksperdi tiimi tuppa, siis enamasti valitseb seal vaikus. Milleks siis nohiseda samas ruumis? Meil on insenerid, kes töötavad Tartust (200km), Kuressaarest (x km+praam), Brüsselist (miskit lennukit on vist vaja). Sel suvel töötas hulk inimesi Keri saarelt. Teekond sinna või tagasi võttis sõltuvalt ilmast kuni 2 tundi. Täna astusin ühe tiimi tuppa ja nägin, et Kadri istub üksinda. Tegin imestunud näo: “Kus kõik on?” Kadri näitas pöidlaga teleka poole, mille külge on ühendatud arvuti, milles on lahti Google Hangouts. Telekas olid Risto ja Tanel. Kusjuures, varem istus Tanel samas kontoris, aga paar tuba edasi. Kui Kadril oli talle (suuline) küsimus, pidi ta püsti tõusma ja minema paar tuba edasi, et seda küsida. Nüüd, kui Tanel on „telekas“, ei ole vaja isegi püsti tõusta.

Loomulikult jäävad alles erinevad sotsiaalsed aspektid, näiteks on vahel pisut veider suhelda inimesega, kelle kohta sa ei tea, kuidas ta välja näeb. Mina näiteks nägin Tanelit esimest korda võib-olla aasta pärast seda, kui ma ta häält olin telekas kuulnud (Tanel väga ei armastanud veebikaamerat või miskit). Ta intonatsioon ja kõneviis meenutas mulle ühte paksu ja laiska osakonnajuhti eelmisest töökohast. Nagu ma nüüd tean, ei ole Tanel ei paks ega laisk. Inimesed peavad aegajalt kohtuma, ka mittetöises õhkkonnas. Aga see on juba puhtalt operatiivküsimus. Oluline on see, et igapäevatöö tegemiseks ei ole alati vaja olla samas ruumis ja hingata samast konditsioneerist läbi käinud õhku.

Ja tegelikult on peamine küsimus hoopis selles, kas ja mida me oleme ise teinud, et oma klientidele selgitada, et outsourcemine ei ole paha. Lihtsalt, seda on mõistlik teha lähemalt kui kolme ja poole ajavööndi kauguselt. Sealt, kus on sarnane suhtumine töösse, sarnased väärtused ja ärkvelolekuajad. Seal on inimesed, kes tahavad saada aru, mis äri sa ajad ja kuhu voolumõõtja oleks kõige sobilikum paigaldada, kui meenutada liikvelolevat juttu Tesla universaalse elektriülekande teooria realiseerimisele saatuslikuks saanud voolumõõtja paiknemise küsimusest.

Meil on olemas nüüdseks juba üle 15 aastane kogemus, kuidas nearshoring toimib. Füüsiline samas ruumis paiknemine võib aidata, aga ei ole määrav faktor. Oluline on suhtlemine. See, et tekib tiimitunne ja arusaam, et me kõik teeme sama projekti ja oleme ühiselt vastutavad. Ja sarnane kultuuri- ja väärtusruum aitab sellele kõigele oluliselt kaasa. Ka see, et koosolekud saab kokku leppida mitte kasutades ajavööndiinfot või teadmist, et vastus “Yes-yes,” ei tähenda ilmtingimata seda, et millegagi nõustutakse või sellest aru saadakse. Lõpetuseks meenub juhtum, kui ma põhjanaabritest klientidega ühiselt lõunalauas istudes naljaga pooleks küsisin, et misasi on “pilaat”? See, et “melilosvo” vastati üllatas tegelikult mind ennastki.

Loo autor Urmas Kobin on Proeksperdi kliendihaldur.

Trendid Java-maailmas 2016 – vaade Devoxxilt

November 28th, 2015

Mattias Tiitson, Proeksperdi tarkvaraarendaja

11 – 13. novembrini toimus Belgias, Antwerpenis 3500 osalejaga Java konverents Devoxx, kus sain osa esitusest kaheksal paralleelsel rajal. Millised trendid valitsevad Java maailmas? Ilmselgelt on mu nägemus pisut kallutatud ja suuresti mõjutatud ettekannete valikust, kuid mõned mustrid joonistusid välja üsna selgesti.

Selle, 2015. aasta kindel hitt on Docker. Docker on vidin, mis võimaldab rakenduse koos igasuguste sõltuvustega pakkida konteinerisse. Miks see hea on? Sest rakendus töötab nüüd, kus iganes Dockeri põhi all on. Mingisugust keerukamat seadistust polegi vaja. Konteinereid on lihtne luua, hävitada ja taasluua. Järele proovides selgub üsna kiiresti, millest selline vaimustus.

Loomulikult on endiselt äärmiselt populaarsed pilvetehnoloogiad. Teenused nagu AWS pakuvad lihtsalt skaleeritavat infrastruktuuri. Huvitava kõrvalmõjuna võimaldavad nad mõelda infrastruktuurist kui commodityst. Sellega kaasnevad omakorda uued võimalused tarkvara tarnimiseks ja sellele eelnevaks ettevalmistuseks.

Continuous Delivery on teema, mis mind isiklikult on viimasel ajal väga huvitanud. Selle peamiseks eesmärgiks on hoida rakendust pidevalt reliisitavas seisundis, mis on järgmine loogiline samm pärast Continuous Integrationit. Üsna üllatav oli näha, et tegelikult juba aastaid vana idee paistab just praegu väga tugevalt esile kerkivat printsiibina, mille kogukond on vastu võtnud kui hea tava – midagi, mille poole vähemalt pürgida. Võib-olla on teema aktuaalne just varem mainitud tehnoloogiate võidukäiguga seoses. Nii Docker kui ka erinevad platvormiteenused, millele viidatakse lühendiga PaaS võimaldavad tunduvalt hõlbustada automatiseeritud deployd.

Metoodikate valdkonnas kerkivad esile kaks tegijat: Lean ja DevOps. Lean on üldisem metoodika, mille eesmärk on vähendada väärtust mitteloovate tegevuste hulka. Eriti omab see mõtet startupide kontekstis, kus välditakse näiteks põhjalike turu-uuringute ja äriplaanide koostamist traditsioonilisel aeganõudval viisil. DevOps on spetsiifilisem metoodika, mida kasutatakse just tarkvaraarenduse kontekstis. Selle ülesanne on edendada koostööd tarkvaraarendajate ja operatsioonide üksuste vahel, millega avanevad uued võimalused, sealjuures ka eelpool mainitud tehnoloogiad. Kumbki neist meetoditest ei ole konkurendiks meile hästi tuttavale agiilsele lähenemisele, kuid pigem täiendavad seda.

Devoxxil räägiti ka Java järgmisest versioonist, mis toob meile kauaoodatud moodulihalduse. Endiselt olid teemaks ka käesoleva Java versiooni 8 pakutavad lisavõimalused, kus klassikalise objektorienteeritud programmeerimise kõrval otsitakse lahendusi teiste paradigmade kaudu, muuhulgas funktsionaalse programmeerimise võtete kasutamisega. Palju räägitakse ka Reactive programmeerimisest vahendite nagu näiteks RxJava, Akka, Vert.x ja NodeJS abil. Viimane on abstraktsioon, mis võimaldab andmetest mõelda kui striimidest, mida on võimalik transformeerida ja kombineerida.

Mitmeid neid tehnoloogiaid ja metoodikaid reklaamitakse kui võluvitsa, mis pühivad kõik mured. Kuid on ka neid, kes hoiatavad tormakaid otsuseid tegemast. “Shit happens when you put network between your classes,” ütles üks esineja tabavalt microservicete kohta, viidates sellega kaasnevale paratamatule lisakeerukusele.

Microservices

Microservice on mõiste, mida ei saa enam väga uudseks nimetada. Sisuliselt on see moodus rakenduse modulariseerimiseks, millega jagatakse rakendus väikesteks autonoomseteks teenusteks, mis omakorda suhtlevad omavahel üle võrgu. Tavaliselt paljastavad need REST-liidese, mille abil teenused üle võrgu üksteisega suhtlevad. Sellega võimaldame süsteemi erinevatel osadel areneda erineva kiirusega. Muudatus ühes teenuses ei mõjuta tingimata teiste teenuste tööd. Microservicite kontekstis pakub palju kõneainet ka süsteemide resilience ja rikete käsitlemine.

Et viia teenuste piire ületavate muudatuste hulga miinimumini, jagatakse süsteem teenusteks vertikaalset. Jagades süsteemi äridomeenide alusel saame stabiilsemad teenuste liidesed. Süsteemi kasvades võib tekkida vajadus töö jagamiseks erinevate meeskondade vahel. Vertikaalne jaotus võimaldab tiimidel saada spetsialistiks ka oma hallatavas äridomeenis. Mõnes mõttes erandina võib vaadata front-endi, mis moodustab õhukese horisontaalse kihi teiste teenuste peale.

Hea mustrina ei jaga teenused andmebaase. Jagatavad andmed peaksid teenused paljastama liideste kaudu. See on vajalik teenuste implementatsiooni detailide peitmiseks avalikkuse eest, mis omakorda hõlbustab muudatuste tegemist teenuste sees ilma seotud teenuseid mõjutamata. Kui andmebaas on jagatud mitme teenuse vahel, võib ka pisem muudatus selles nõuda mitme erineva teenuse üheaegset muudatust. Need teenused võivad aga olla erinevate tiimide arendada ja nõuda keerukat koordineerimist. Seepärast tuleks vältida tsentraalsete punktide tekkimist.

Kuid ka uuendused teenuste liidestes võivad tekitada vajaduse mitme teenuse üheaegse muutmise järgi. Selliseid olukordi saame vältida liideste versioniseerimisega. Oluline on meeles pidada, et meie eesmärk on võimaldada teenuste iseseisvat arengut.

Mitte alati ei toimi kõik teenused õlitatult. Microservicite kontekstis muutub äärmiselt oluliseks rikete leviku piiramine. Ka ebatavaliselt aeglaselt vastav teenus võib temast sõltuvate teenuste töö täielikult halvata. Vastust ootavate päringute kuhjudes ammenduvad rakendusele saadaval olevad threadid ja teenus võib hanguda. Kogu lisakoormus jaotub ülejäänud klastrile ja võib ka teised noded üle koormata. Selline stsenaarium illustreerib hästi vajadust rikete läbimõeldud käsitlemise järgi. Hystrix on teek, mis võimaldab just selliseid olukordi vältida. Nö circuit breakerite implementeerimine aitab rikkis funktsionaalsust välja lülitada ja minimeerida negatiivseid mõjusid. Teenuse arendudes tuleb alati lähtuda eeldusest, et kõik taustasüsteemid võivad maha kukkuda. Kõiki halbu stsenaariume saab muuseas simuleerida ja testida vahenditega nagu Mockwire.

Teenuste arvu kasvades muutub kiiresti oluliseks automatiseerimine. Skaleerumiseks on hädavajalik automaatne testimine ja hõlbus muudatuste deploymine. See nõuab aga investeeringut infrastruktuuri ja protsessidesse nagu Continuous Delivery. Samuti muutub keeruliseks logide haldamine. Tööriistad nagu Kibana või Splunk võimaldavad logid agregeerida ühte kohta. Huvitava trikina võib juurutuda praktika, kus igale äriloogilisele tegevusele genereeritakse oma korrelatsiooni identifikaator. See identifikaator märgitakse maha iga seotud logikande juures. Nii on lihtsalt leitavad kõik omavahel seotud, kuid erinevatest süsteemidest pärinevad logikanded.

Paljud neist printsiipidest kehtivad ka monoliitse rakenduse juures. Kuid tõeliselt kriitiliseks saavad need just microservice arhitektuuri puhul. Kui suur on sellise arhitektuuri valimise hind? Kindlasti sõltub see ümbritsevast ökosüsteemist. Hästi juurdunud DevOps metoodika võimaldab lihtsamini taolist arhitektuuri üles seada. Korporatiivses maailmas, kus asjad liiguvad suurema inertsiga, võib see aga päris raskeks ülesandeks osutuda. Nii ei pruugi potentsiaalne tulu üldsegi üle kaaluda muudatusega kaasnevat vaeva ja lisakeerukust ja seetõttu on ilmselt hea strateegia hoida valikuid avatuna võimalikult kaua viljeledes modulaarset disaini monoliitse rakenduse sees. Hüpe microservicitele on mõistlik teha alles tungiva vajaduse tekkides. Pühendumise edasilükkamine on muuseas ka üks Lean metoodika printsiipidest.

Principles Of Microservices

Six principles for building fault tolerant microservices on the JVM

Microservices and Modularity or the difference between treatment and cure!

Code Review

Code Review on praktika, kus enne koodi mainline commitimist vaatab selle üle mõni tiimikaaslane. Eesmärgiks on koodi kvaliteedi parandamine, koodibaasi tutvustamine tervele meeskonnale ja õppimine arutelude kaudu. Praktika juurutamiseks tasub aga silmas pidada mõndasid põhitõdesid. Code Review ei tohi omandada negatiivset alatooni. See ei ole meetod töötulemuste hindamiseks ega tohiks panna hinnatava koodi autorit liiga suure pinge alla. Samuti ei tohiks see panna liigset koormust hindaja õlule. Eesmärk ei ole koodile vaadates kõik vead leida, kogu hindamine ei pea kestma üle 10 minuti. Küll aga võiks hindamine toimuda aegsasti, muudatused ei tohiks selle taha takerduda. Põgus ülevaatus tekitab loodetavasti arutelusid ja ideede jagamisi, mis lõpptulemusena parandavad koodi kvaliteeti ja aitavad kaasa ka osaliste isiklikule arenemisele. Code Review aitab meeskonna liikmeid kursis hoida teiste tegemistega koodibaasis ning rakenduse erinevate osade arenguga. Tagasiside jagamise juures on äärmiselt oluline emotsionaalne intelligentsus. Arendaja suhtub alati oma koodi teatava isiklikkusega. Kriitika peab seepärast olema konstruktiivne ja mõistvalt serveeritud. Vastasel juhul ei saavuta me loodetud hüvesid vaid tekitame vaid lisatüli.

How to stop wasting your time and start performing useful code reviews

“Make jar not war” – Twelve-Factor App

Rakenduse war arhiivi pakendamine on muutumas mõnes mõttes antipatterniks. Traditsiooniliselt pakitakse veebirakendus war faili, millele tuleb seejärel leida koht mõnes aplikatsiooniserveris. Tihti sisaldab selline aplikatsiooniserver veel teisi ware. Wari uuendamine serveris aga ei pruugi olla triviaalne. Halvimal juhul tuleb server taaskäivitada häirides sellega kõigi sisalduvate rakenduste tööd. Samuti ei ole rakendusserveri automatiseeritud üles seadmine lihtne. Seepärast on populaarseks muutunud jar arhiivi pakendatud rakendused, mis sisaldavad oma enda embedded serverit. Populaarseim näide sellisest lahendusest on ilmselt Spring Boot.

Serverit sisaldava ja .jar-i pakendatud rakenduse käivitamiseks on vaja vaid Javat. Lahendus sobib eriti hästi pilvetehnoloogia konteksti, kuid on oluline ka traditsioonilisel platvormil Continuous Delivery praktika juures. Idee poolest võiks infrastruktuur olla ühekordselt kasutatav. Rakenduse keskkonna võib ära visata ja taasluua. Kuna .jar arhiiv on käivitatav kus iganes on olemas Java virtuaalmasin, teeb see keskkonna loomise tunduvalt lihtsamaks. Jar eemaldab ühe muutuja mängust – rakendusserveri. See suurendab paarsust production ja arenduskeskkondade vahel. Kaovad serverist tulenevad erinevused ja suureneb kindlus, et rakendus töötab erinevates keskkondades samamoodi.

Need põhimõtted ja mitmed teised on koondatud metoodikasse, mida nimetatakse Twelve-Factor Appiks. Pean tunnistama, et polnud sellist mõistest varem kuulnud. Midagi täiesti revolutsioonilist ei paista see mängulauale toovat. Ometi pakub see üsna head kokkuvõtet headest praktikatest, mida arhitektuuri valimisel järgida. Täpsema kirjelduse leiab 12factor.net. Saab näha, kui palju kõlapinda metoodika tulevikus saavutab.

The Twelve Factor app: Best Practices for Java Deployment

Kõigi muudatustega kaasneb teatav hind, vahel ei pruugi see hind üle kaaluda mõne uuendusliku vahendi kasutuselevõtust loodetud tulu. Vahel võib ka juhtuda, et uus asi lahendab suuresti meie tänased mured, kuid tekitab hoopis uusi muresid. Oma üsna lühiajalisele kogemusele tuginedes tundub mulle siiski, et tarkvaraarenduse maailmas on toimumas üsnagi suured muutused, millel tasub vähemalt silma peal hoida.

Miks õppida programmeerimiskeeli

November 9th, 2015

Roland Tepp, tarkvaraarhitekt

Olen mitmel puhul (ka Proeksperdi siseselt) kuulnud arvamusavaldusi nagu professionaalsel tarkvara inseneril ei oleks vaja õppida enam kui kahte programmeerimiskeelt. Üks neist keeltest peaks olema tõsisem töö tegemise keel nagu C++, Java või C#; ning teine keel võiks olla mõni dünaamiliste tüüpidega skriptide kirjutamise keel nagu Ruby või Python.

Samuti olen kohanud suhtumist et programmeerimiskeele õppimine oleks just nagu väärtusliku aja ja ressursi raiskamine – miks õppida uusi või vähetuntud programmeerimiskeeli, kui nende osas puudub kliendi tellimus, kui neil puudub kogukonna tugi ja jääb vajaka oskusteabega töökäsi.

Ütlen otsekohe välja, et ma ei jaga neid seisukohti. Miks?

Sest programmeerimiskeeled on minu ameti tööriistad. Ma tahan käia ajaga kaasas ja lubada endale valida ainult parimaid tööriistu. Iga uus tööriist õpetab mulle uusi töövõtteid, laiendab minu silmaringi ja parandab minu konkurentisvõimet.

Pidevalt kasvav tööriistakast

Usun, et ei ole suur üllatav, kui ütlen et mulle meeldivad programmeerimiskeeled. Paljud, kellega suhelnud olen, on ilmselt kuulnud minu huvist Ceylon keele vastu — olen seda huvi kahel korral ka kolleegidega jagada püüdnud ning ka ise oma käe projektile külge pannud.

Samas minu programmeerimiskeelte huvi ei piirdu vaid ühe keelega. Läbi oma karjääri olen enamal või vähemal määral kokku puutunud paljude erinevate programmeerimis- ja dokumendikeeltega:Basic, Pascal, Perl, C, C++, VisualBasic, Python, JavaScript, Java, C#, Bash, PowerShell, SQL, Octave, Standard ML, Racket, Ruby, Erlang, Ceylon, Smalltalk, jne… Ja need on ainult programmeerimiskeeled — lisaks võib siia hulka lisada ka HTML, XML, CSS, LaTeX ja mitmed teised dokumendi- ja domeenispetsiifilised keeled.

Niiviisi ühes reas üles loetletuna tundub nimekiri kohutavalt pikk — tagantjärgi sellele pilku peale visates üllatab nimekirja pikkus mind ennastki — aga kui mõelda sellele, mis moel või millistel põhjustel ma neid keeli olen kasutama pidanud, siis pole tegelikult midagi imestada, suuremat osa neist keeltest on mul läinud vaja ühe või teise töö tegemiseks.

Väga vähesed keeled selles nimekirjas on õpitud ainult uue programmeerimiskeele õppimise rõõmu pärast. Enamasti on õppimise ajendiks olnud reaalne vajadus midagi ära teha.

Programmeerimiskeeled on enne kõike ikkagi peamised tööriistad. Uue programmeerimiskeele õppimine on nagu uue tööriista hankimine — sa ostad omale uue tööriista sellepärast, et sul on seda mingil hetkel vaja. Ikka üks tööriist korraga. Ja enne, kui sa märgatagi oskad, on sul neid kogunenud juba nii palju, et sellega täidab ära juba päris aukartustäratava tööriistakasti.

Ma ei pruugi kõiki tööriistu meistriosavusega käsitleda. Enamik programmeerimiskeeli minu “tööriistakastis” on näinud viimast kasutust aastaid tagasi ja tõenäoliselt võtaks mul täna paljude nendega mingi arvestatava produktiivsuseni jõudmine pea samapalju aega kui kunagi selle keele õppimine, aga mingil hetkel oli mulle neid vaja ja ma omandasin vajaliku teadmise piisaval tasemel, et “ohtlik olla”.

Käia ajaga kaasas

Isegi kui on õnn (või õnnetus) pikema aja vältel püsida sama programmeerimiskeele ja -keskkonna juures (C++ Windows development või Java EE või LAMP stack), siis ka need keskkonnad ei seisa kunagi paigal.

Nii C++, Java kui C# on läbi viimase paari aastakümne läbi elanud tohutuid muutusi. Pikad suhteliselt stabiilse platvormi perioodid on vaheldunud ajuti päris radikaalsete muudatustega nii keele kui arenduskeskkonna osas.

Java suureks murranguks oli 2004, kui saabus Java 5, koos generic’ute ja annotatsioonidega, mis muutsid tundmatuseni seda, kuidas kirjutada ja kasutada teeke ja raamistikke – Java EE pärast Java 5 erineb radikaalselt J2EEst mei oli enne seda.

Pärast kümneaastast pausi, kahte vahepealset Java versiooni, tuli eelmisel aastal välja Java 8, tuues keelde sisse funktsionaalse programmeerimise elemendid — lambdaavaldised. Nende mõju sellele, milline näeb välja uus Java kood, võib märgata juba praegu…

Samas ei saa jääda puhkama oma loorberitele ja loota, et sellega kõik piirdubki — Java 9 koos keelde sisse ehitatud moodulite toega ei ole kaugel silmapiiri taga ning selle muutuse mõjusid arendusele on väga lihtne alahinnata, kui puudub varasem kokkupuude modulaarse runtime’ga.

Kuigi ma ei ole enam aastaid aktiivselt C või C++ arendusega tegelenud, on siiski silma hakanud viimase aja C++ standardi kiirem areng. Ka JavaScript (või ECMAScript) on viimasel ajal hakanud näitama oluliselt kiiremat arengutempot tuues sisse suuremaid muudatusi keele süntaksi ja semantika osas.

Kiired ja ajuti ka üsna radikaalsed muutused muidu nii stabiilsete keelte juures ei ole juhuslikud. Need muutused on ajendatud peamiselt uute ja elujõuliste programmeerimiskeelte pealetungist — Java liidripositsiooni enterprise süsteemide arenduses on juba pikka aega noolinud C#, kuid ei saa alahinnata ka mõnevõrra uuemate tulijate nagu Scala, Groovy, Kotlini, Dart’i, Clojure, Ceylon ja Go keelte kuuma hingeõhku Java kuklas.

C++ käest püüavad vahelduva eduga püüda väänata turuosa D, Rust, Go, Nim, C#, Julia.

JavaScripti mitmeid veidrusi on siluda püüdnud nii CoffeScript, Dart, ClojureScript, Ceylon, ActionScript, Scala.js, ja paljud muud keeled.

Lisaks on hakanud akadeemikute tolmustelt riiulitelt pead tõstma ka mitmed funktsionaalsed keeled nagu Haskell, F#, OCaml, Erlang, Elixir, Racket.

Põhjalikuma suurpuhastuse on läbi teinud ka Perl, Python, PHP ja teised…

Kõik need keeled täidavad mingi lünga meie võimalikus tööriistakastis — igaühel neil on oma nišš, milles just see keel eriliselt särama lööb, võimaldades saavutada meie eesmärke kiiremini, kergema vaevaga, tehes koodi kompaktsemaks, paremini loetavaks ja/või pakkudes paremat turvavõrku tüüpiliste veaolukordade vältimiseks või olulisemat valupunktide leevendamiseks.

Püsida laineharjal

Parafraseerides tuntud vanasõna: “Kui su tööriistakastis on ainult haamer, siis valid sa oma tööpinna ja -materjali alati selliselt, et töö saaks ainult naelte ja haamriga tehtud.” Ka siis kui mõnikord piisaks liimist või akutrelli ja kruvidega saaks paremini, kiiremini ja kindlamalt.

Sa võid oma ainsat tööriista kasutada erakordse meiserlikkusega, teada täpselt, kui kõvasti millist naela millise pinna sisse lüüa, mis naelad sobivad millistesse materjalidesse ning osata 42 erinevat haamrilööki, kuid suvaline noor nolk, kes tuleb objektile oma naelapüssi ja akutrelliga, võtab sult töö käest, sest tema tööriistakast on rikkalikum ning võimaldab sama tulemuse saavutada kordades kiiremini ja kui mitte alati kvaliteetsemalt, siis vähemalt ühtlase ja piisavalt hea kvaliteediga.

Sama lugu on ka programmeerimiskeeltega. Jäädes pidama vaid ühe kindla (ja kahtlemata mugava) töövahendi juurde, piirame me oma konkurentisvõimet ja jääme mingil hetkel paratamatult ka ajale jalgu.

Mina eelistan hoida ennast kursis uute töövahendite ja töövõtetega. See tähendab lisaks teemakohaste artiklite ja raamatute lugemisele, podcastide kuulamisele (ja võimalusel konverentsidel käimisele) ka silma peal hoidmist uutel programmeerimiskeeltel.

Aegajalt kerkib teemakohasest meediast üles mingi uus teek, raamistik või programmeerimiskeel, mis lubab me elu koheselt teha kümme korda ilusamaks, lahendada maailma näljahädad ja teha lõpp sõdadega. Ei maksa palju kulutada, tund või paar selle uue asjapulgaga tutvumisele — lugeda dokumentatsiooni, uurida koodinäiteid ja vaadelda arhitektuurijooniseid. Mitte kõik ei ole kuld, mis sädeleb, aga esmase tutvuse tegemine annab piisavalt infot, et uuele tehnoloogiale mingi mõtteline koht oma tööriistakastis reserveerida.

Varem või hiljem saabub olukord, kus teadmise kogumisele investeeritud aeg kuhjaga tagasi võidetakse. Siis, kui vaja, meenub sulle töövahend või töövõte või programmeerimiskeel, mis lubab esimesed 80% lahendusest saavutada 20% vaevaga võrreldes tööga, mis oleks kulunud, et kõik algusest lõpuni ise teha, samas koodi loetavust kümnekordselt parandades.

Kui ma ei ole isegi teadlik parema töövahendi olemasolust, ei ole vähimatki võimalust seda ka rakendada.

Samuti ei tohiks unustada et ka tänased näiliselt kõigutamatu positsiooniga C++ ja Java olid millalgi uued ja tundmatud, eksootilised programmeerimiskeeled. Nende asemel laiutasid C, COBOL, Smalltalk ja Pascal.

Miks sörkida ammuste trendide sisse tallatud jalajälgedes, kui saame võtta liidripositsiooni ning aidata neid trende ise kujundada.

Õppida midagi uut

Nii nagu iga uue tööriista kasutusele võtmine paneb omandama uusi töövõtteid, nii õpetab ka iga uus programmeerimiskeel midagi uut.

Basic ja VisualBasic andsid ilmselt tugeva aluspõhja ja õpetasid, kuidas midagi lihtsalt “ära teha”. Pascal andis esmase arusaama sellest, mis vahe on interface’il ja implementatsioonil. C ja vähesel määral ka kunagine ammune ASM’i kogemus andsid mulle arusaamise sellest, kuidas kasutab mu programm arvuti ressurssi, kuhu kaob mälu ja kust tekib soojus. Java õpetas objektorienteeritud mõtlemist ja OO disaini põhitõdesid. Perl õpetas hindama loetava koodi väärtust. Python andis esmase kogemuse funktsionaalse programmeerimise elementidega ja õpetas usaldust koodi vastu ning näitas kuidas dünaamiliste keeltega saab lihtsate vahenditega ja vähese tseremooniaga saavutada suuri tulemusi.

Erlang andis esimese õppetunni sellest misasi on pattern matching ning kuidas kasutada rekursiooni. Scala ja Standard ML õpetasid mis asjad on kõrgemat järku funktsioonid ja kuidas nende abil lihtsaid ja kergesti hallatavaid funktioone kombineerides jõuda võrdlemisi keeruka funktsionaalsuseni.

Tänu Scalale tegin endale selgeks (mingil määral), mis on monaadid ja kuidas neid kasutada (ning sain ka selgeks, miks Java keeles need seni nii vähest kasutust on leidnud).

Ceylon ja Scala õpetasid kasutama staatiliste tüübi infot enamaks kui vaid tühipaljaks andmete konteineriks või sarnaste funktsioonide grupeerimiseks – staatiliste keelte tüübisüsteem võib olla sihipärase ja teadliku kasutaja käes väga terav tööriist veavabama ja kergesti loetava koodi kirjutamisel.

Erlang, Scala ja Clojure näitasid, kuidas immutable andmestruktuurid võimaldavad muuta triviaalseks paralleeltöötluse ja asünkroonsete protsesside haldamise. Ja läbi selle andsid aimu hoopis uuest arhitektuursest lähenemisest skaleeruvate süsteemide ehitamisel.

Iga keel, millega mul on olnud au kokku puutuda, on mõjutanud seda, kuidas ma pärast oma koodi kirjutan, kuidas ma oma esialgse ülesandepüstituse tükkideks lammutan ja mis moel ma lahenduse kokku kombineerin.

Usun et iga üks neist on teinud minust parema inseneri.

Elu välikontoris Keri saarel

September 22nd, 2015

Meie veel värske ja põnev sopiline kontor on hirmus äge, aga veel ägedam on, kui saad vahelduseks totaalselt äraspidises keskkonnas enda tööd teha. Selline võimalus avanes seiklushimulisematele Proeksperdi töötajatele eelmisel nädalal – meil oli ajutine harukontor tillukesel Keri saarel.

Emotsioone, kuidas sinna “kontorisse” tööle sõita oli ning mida tähendab elu 12-voldiste akude peal, kirjeldab elavalt enda blogis kvaliteediinsener Kunnar.

 

TechEd Europe 2014

November 14th, 2014

Külastasime Kaupoga paari nädala eest Barcelonas Microsofti suursündmust TechEd 2014. Kokkuvõtvalt kirjeldades on tegemist Microsofti uusimate tehnoloogiate väljanäituse ning arengusuundasid tutvustava ettekannete formaadis korraldatud üritusega.  Meied huvitas peamiselt arendajatele suunatud ettekanded, mis keskendusid Microsofti arendusvahenditele, tehnoloogiatele ning nende rakendamisele – ehk kuidas teha vähema pingutusi suuri asju.  Kui meenutades 6 aasta eest samas paigas toimunud TechEdi, siis väga paljud tol ajal välja hõigatud arengusuunad on saanud meie igapäevaeluks. Vaatame, kuidas seekord läheb. Mõtteid järeleproovimiseks, -vaatamiseks ja seedimiseks tekkis igatahes hulgim.

Juba avakõnes rõhutati, et Microsofti fookus on praegusel hetkel pilv ja mobiilsus. Sellest tulenevalt oli väga suur osakaal terve nädal kestnud ettekannetel just nendel teemadel. Mobiilsus ja nutitelefon ei tähenda MS jaoks ainult Windows Phone’i, vaid ka kõiki teisi laiemalt levinud Google’i ja Apple’i nutiseadmeid. Lähtudes mobiilseadmete turusituatsioonist, on see igati mõistetav. Teiseltpoolt on võimalik oma pilveteenustega kasu lõigata sõltumata sellest, mis marki ja tüüpi seadmega lõppkasutaja neid teenuseid tarbib. Sellest tulenevalt Microsoft lihtsalt peab armastama ka konkurentide loodud telefone ja tahvelarvuteid. Pakkudes parimaid arendusvahendeid, et luua oma rakendusi mistahes laiatarbe nutiseadmele, on üks meeldejäävamaid märksõnu sellel teel. Oleme viimasel ajal tihedamalt kokku puutunud Microsofti Azure platvormile pilverakenduste arendustega. Väga paljud ettekanded neist võimalustest ja arenduse parimatest praktikatest leidsid äratundmist. Järelikult oleme õigel teel.

Pilv, pilv ja veelkord pilv. Tulevik on pilves. Arendajad on ka pilves. On ju oluline tegeleda ainult enda põhiäriga ning arendada enda toodet ja pakkuda enda teenuseid. Kõik muu nagu süsteemsed turvauuendused, riistvara, varundus ja muu säärane usaldada teenusepakkujale. Usalda, et sinu asjad on turvaliseimas paigas ning teenindavad sind ja sinu kliente skaleeruvalt ning laitmatult 24/7. Globaalse turu jaoks suunatud rakenduste jaoks on see juba möödapääsmatu.

Kuulasin ka paari ettekannet, mis oli fokuseeritud äriotsuseid tegevatele IT spetsialistidele.  Ühes sellises võrreldi Microsofti positsiooni konkurentidega. Tõsiasi on, et Microsoft pole Gartneri raportite järgi ühegi spetsiifilise valdkonna liider, kuid ta on igas valdkonnas innovatsiooni ja turuosa liidrite hulgas väga silmapaistev. Ning aastate lõikes oma positsiooni aina tugevdav. Huvitava märkusena jäi meelde, et Moore’i seadus kehtib ka pilveteenuste kohta. Analoogiliselt algupärase tähendusega saab sama raha eest iga kahe aasta tagant kaks korda rohkem pilveteenust. Et maailma suurimate jaoks on pilv ja pilveteenused suur arendussiht, siis pole oluline, kes on hetkel hinnaliider. Endiselt on kõige olulisem, kuidas kiirelt turule tulla ning oma toodet kiirelt arendada. Google, Amazon ja Microsoft on teinud mõõtmatuid investeeringuid arvutuskeskustesse ning sellest tulenevalt hakkavad massiefekti tulemusena hinnad langema. Kaugeleulatuvalt prognoositakse, et teised majutusteenuseid pakkuvad ettevõtted peavad leidma endale niššiturge. Kokkuvõtvalt äriotsuste tegijatele – ole innovaator või tehnoloogia jälgija ja varajane kasutuselvõtja, et mitte maha magada võiduvõimalust. Sa oled aga kindel kaotaja, kui muutused tabavad sind üllatusena. Vaid esimesed jaololijad jagavad piruka. Teised võitlevad purude pärast.

Eks neid mõtteid tekkis veelgi. Peab veel seedima. Head koodi ja töötavat tarkvara on ka vaja teha.

 

Atlassian Summit 2014

October 20th, 2014

Osalesime koos Taneliga taas kord iga-aastasel Atlassian Summitil, mis sedapuhku leidis aset San Joses, Californias. Seekordne üritus hakkas juba suurkonverentsi mõõtmeid võtma – peasaal oli nii hiiglaslik, et vaevalt nägi selle teise otsa ja vendor‘ite bokside vahele võis tõsimeeli ära eksida. See pole ka ime, sest Atlassiani klientide arv on aastaga suurenenud 30% ning töötajate arv pea kahekordistunud – sarnase kasvu pidi järelikult Summitist osavõtjate hulkki tegema. Samas, suurem ei pruugi alati parem olla. Minu arust jäi sel korral juba kõvasti vajaka “intiimsusest”, mida eelmisel aastal veel kergelt õhus tunda oli. Inimesi, ruumi, vendor’eid, paralleelseid track‘e ja kõike muud oli hoomamiseks lihtsalt liiga palju. See aga ei tähenda, et me poleks palju kasulikku infot või kontakte saanud.

Üks Atlassiani asutajatest pealaval tuhandete peade ees kõnelemas.

Üks Atlassiani asutajatest pealaval tuhandete peade ees kõnelemas.

Lisaks silmapiiri avardamise soovile läksime Taneliga Summitile kindla eesmärgiga leida inimesed, kes aitaksid lahendada müstilise häda, millega oleme ühe kliendi juures pikemat aega maadelnud. See tähendas, et tuli ohtralt tegeleda networkimise ja tehniliste vestlustega ehk loobuda paljudest ettekannetest. Viimane ei pannud õnneks just nutma, kuna paljud lubava pealkirjaga ettekanded osutusid igavamaks kui loodetud: nii mõnigi esineja oli kas kogenematu/kiretu või polnud ettekande sisu loodetud tasemel. Lisaks teadsime, et kõiki esinemisi saab kunagi järelvaadata (kuigi paljud meist seda päriselt teevad?), seega võis rahulikult inimestega suhelda. Paar aastat tagasi kohtusin Summitil ühe mehega, kes väitis, et ta ei käi mitte ühelgi konverentsil mitte ühtegi ettekannet vaatamas – asja mõte on ainult networking! Kas peab just nii radikaalne olema, aga ta jutus on iva, sest tõepoolest on võimalik kõiki esinemisi juba praegu veebist vaadata, kuid nende inimestega näost näkku rääkida enam ei saa.

Networkimine kurikuulsal Summit Bash peol.

Networkimine kurikuulsal Summit Bash peol.

Kes ei viitsi pea ees videomaterjali sukelduda, neile nimetan mõned tooteuudised ning poetan ka paar kogutud tarkusetera kuuldud heietustest tarkvaraarenduse teemadel. Peamine “päris uue toote” esitlus Atlassianilt oli JIRA Portfolio ehk kaua-oodatud product management kiht olemasoleva projekti- ja taskihalduse peal. Viimaks on võimalik mõistlikult hallata projektideüleseid initsiatiive, neid theme’deks kategoriseerida ja siduda juba konkreetsemate epic’ute ning story’dega. Ühtlasi saab harrastada Gantt chart’i laadset aja/ressursside planeerimist visuaalsel kujul Atlassianile omaselt paari huvitava kiiksuga. Kel rohkem huvi, lugege lähemalt veebist.

Konverentsi-melu

Konverentsi-melu

Confluence poolt oli suurimaks väljakuulutatud hitiks Google Docsist tuttav reaalajas mitme inimese kollaboratsiooni võimalus samal dokumendil. Veel hakkab olema võimalik kommenteerida nii lehtede kui failide sisus konkreetseid kohti (nt mõnda konkreetset lauset, PowerPointi slaidil ainult pealkirja vms). Mõlemad võimalused on “varsti poelettidel”.

JIRA Service Deski kasutajatele teeb kindlasti heameelt hinnastamise muudatus – nüüd käib maksmine tuge pakkuvate agentide töökohtade baasil, mitte tuge saavate inimeste arvu pealt. Lisaks muutus ka do-it-yourself tutorial’e sisaldav Atlassian University tasuta ligipääsetavaks. Tarbijale hea uudis, tootjale ilmselt mitte nii väga :) Vahetuma kogemuse saamiseks vaata näiteks kompaktset 7-minutilist kokkuvõtet keynote’i parimatest paladest.

Tootest sõltumatul teemal oli päris huvitav ettekanne spike’misest ehk teatud kindlal viisil läbi viidud uurimisülesannetest (video). Hästi tehtud spike’i abil on võimalik ülesandeid paremini (täpsemini) hinnata, lihvida nõudeid, vähendada teadmatust, valideerida tehnilist lähenemist ning paremini eesseisvat tööd organiseerida. Kindlasti peab ühel korralikul spike’il olema eesmärk, kindlaks määratud maksimaalne aeg, mis sellele pühendatakse ning see tuleb ka sprindi tööde hulka planeerida ja sarnaselt teiste töödega tulemust demoda! Ahjaa – sealt tulnud kood viska minema, sest häki otsa ei maksa uut toodet/funktsionaalsust ehitada. Oleme oma tiimis seda metoodikat täitsa edukalt rakendanud ning see on heaks sissejuhatuseks just ülesannete juures, mida ümbritseb suur teadmatus või puuduv üksmeel lahenduse osas.

Teine väga paeluv ettekanne oli Penny Wyatt’i poolt esitatud “Quality at Speed“. Penny rääkis oma teekonnast JIRA meeskonna QA eestvedajana. Kõik algas aastal 2009, kui selle tiimiga liitudes oli story’de rejection rate 100%. Viie aastaga on see kukkunud 4% peale ning võtmeks ei ole olnud tohutu QA inseneride armee usin tegevus, vaid hoopis vastupidi – QA inimesed on võtnud üksnes nõustaja rolli ning puutuvad meeskonnaga kokku kahes punktis kogu arendustsükli jooksul. Esiteks, nad vaatavad üle testimise märkmed, mida arendajad ise enda koodi kohta on kirjutanud – justnimelt, arendajad testivad ise enda koodi! Teiseks, nad osalevad story demol. Kuna kogu vastutus lasub nüüd arendaja enda õlul, on ta palju hoolsam, sest ta ei saa lootma jääda “turvavõrgule”,  mida pakkusid minevikus kas QA või teised arendajad. Samas, QA poolne tugi on siiski olemas ning nende tähelepanekute põhjal harivad pidevalt end ka arendajad. Kokkuvõttes tõdes Penny, et kvaliteet ei tulene koodist, vaid inimestest ning mis töötab ühes meeskonnas, ei pruugi töötada teises – eksperimenteeri pidevalt! Universaalne tõde, mis kehtib pea igas elu valdkonnas :)

Farewell-pidu partneritele viimasel õhtul

Farewell-pidu partneritele viimasel õhtul

Nn ametliku osa kõrval ei saa ära mainimata jätta ka kuulsat pidu Summit Bash, mis sel aastal toimus väga ebatavalises miljöös: paari tuhande inimese käsutada oli terve San Jose Tehnikamuuseum (vt pilti artikli alguses). Ei uskunud, et ma kunagi muuseumi põrandal tantsu vihun või kokteil käes kõiksugu huvitavate gadget’itega eksperimente läbi viin (sageli saatjaks jooke keelavad märgid)!

Meelelahutus peol - termoselfie

Meelelahutus peol – termoselfie

Sotsialiseerumiseks olid igatahes ideaalsed tingimused loodud ning neid sai ka korralikult ära kasutatud. Kuigi taolised üritused võivad maksale liigagi intensiivset treeningut pakkuda, siis elu on näidanud, et isiklik kokkupuude Atlassiani töötajate ning partneritega aitab hilisema suhtluse viia täiesti uuele tasemele. Tasub tulevatelgi aastatel osa võtta!

Veebirakenduste automaatne testimine vol 2 – jõudlus ja stabiilsus

May 24th, 2014

Jätkamaks postituses Veebirakenduste automaatne testimine – capybara-webkit vs poltergeist alustatud headless-draiverite võrdlust, püüan järgnevalt anda lühikese ülevaate sellest, milline on nende kahe jõudlus lihtsas võrdlustestis ning arutleda ka selle üle, kui stabiilne on suure hulga kasutajaliidese testide regulaarne jooksutamine pikemas plaanis.

Nagu juba viidatud postituses mainitud, on poltergeist’il päris mitu eelist, kuid kuidas on lood testide jooksutamise kiirusega? Võrdlemaks kahte draiverit, jooksutasin ühte ja sama testide kogumit mõlema draiveriga kolm korda ning kasutasin võrdlemiseks kolme korra keskmist tulemust. Valitud kogum oli koostatud selliselt, et testid läbiksid võimalikult palju erinevaid olukordi, nii keerukamaid kui ka lihtsamaid lehekülgi.

Tulemusi analüüsides selgus, et vähemalt antud rakenduse ja valitud testide korral ei olnud kahel draiveril olulist jõudluse erinevust. Lihtsamate lehekülgedega sai poltergeist hakkama kiiremini, kuid keerukatel, rohket Javascripti sisaldavatel lehekülgedel olid mõlemad draiverid keskmiselt üsna võrdväärsed. Kokkuvõttes oli valitud testide puhul poltergeist keskmiselt umbes 10% kiirem, kuid üle kõigi testide oli ajavõit suhteliselt marginaalne 5-6%. Loomulikult võib see number sõltuvalt testitavast rakendusest ja testide iseloomust kõikuda mõlemale poole, nii et kokkuvõtvalt võib öelda, et jõudluse poolest on mõlemad draiverid suhteliselt võrdväärsed.

Read the rest of this entry »

Noorteakadeemia vol. 1 ehk kuidas seadmetele hing sisse puhuda

April 15th, 2014

Noorteakadeemia on kutsutud ellu ideega ärgitada leiutamishuvi meie kõige nooremates. Esiotsa otsustasime kokku kutsuda Proeksperdi töötajate lapsed. Kohtumine sai korraldatud innovatsiooni- ja ettevõtluskeskuses Mektory, mille üheks eesmärgiks on tegeleda järelkasvuga ja näidata kooliõpilastele, et inseneri roll on huvitav, jõukohane ja elulähedane! Mektory majas on loodud palju võimalusi ka lastele.

Enne leiutama hakkamist tegime kiire ringkäigu Mektory põnevates ruumides. Kõigepealt ajas lapsed elevile rääkiv puu, mida sai ägedalt sakutada ja mis selle peale siiski inimkeeles (ehkki välismaises) palus end mitte nii tugevalt raputada. Kõigele lisaks teatas ta, et pole slot machine. Muuhulgas piilusime ka robotooriumisse, kus ka meie kõige suuremal lapsel Lauril silmad põlema läksid.

Read the rest of this entry »

Veebirakenduste automaatne testimine – capybara-webkit vs poltergeist

April 1st, 2014

Veebirakenduste automaatseks testimiseks on mitmeid võimalusi, üks neist on testida rakendust läbi kasutajaliidese – kasutades selleks siis kas päris- või headless-brauserit.

Kasutajaliidese kaudu testimisega kaasneb paratamatult hulk probleeme, alates sellest, et testid on suhteliselt aeglased võrreldes rakenduse backend‘i service‘i tasemel testimisega. Jah, palju asju saab veebirakenduste puhul testida kasutajaliidest absoluutselt puudutamata, kuid on ka olukordi, kus tuleb seda teha.

Näiteks on kasutajaliidese kaudu testimine praktiliselt ainus võimalus testida rakendust tegeliku kasutaja vaatepunktist, samuti võimaldab see teostada end-to-end testimist ning mis kõige tähtsam – veenduda, kas meie veebirakenduse frontend üldse töötab.

Read the rest of this entry »

Kas meil on midagi õppida PowerPointi koolitusest

March 31st, 2014

Kämblatäis vabatahtlikke Pro ridadest registreerisid endid sisekoolitajate koolitussarjale. 21. veebruaril jõudiski kätte esimene koolitus. Siin artiklis katsun anda ülevaate sellest, mis mõtteid see koolitus minus indutseeris ja mida muud me kõik võiksime sealt kõrva taha panna.

Esmalt kirjeldan koolituspäeva. See oli jagatud järgmiselt: kolmandik andragoogikat (täiskasvanute harimise teooriat) ja kaks kolmandikku PowerPointi. Nagu pealkiri reedab, keskendun ma siin sellele tagumisele kahele kolmandikule. Andragoogika oli küll huvitav ja mõtteid sütitav, kuid selles ei olnud ma enne nii kodus kui mulle meeldiks. Hiljem sain aru, kui palju rohkem ma sellest teemast teada tahaks. Seevastu PowerPoint on arvutiinimestel veres juba sellest ajast kui arvutid ja Windowsid tubadesse sisse murdsid. Seepärast tekkis koolitusel viibivatel Pro inimestel küsimus, et kas me oleme ikka õiges kohas.

Tegin südame kõvaks, ei andnud tärkava kevade kutsele järgi ja istusin oma kohustuslikud kolm tundi ära. Esineja oli iseenesest huvitav ja tegelikult laialdase kogemusega kõiksugustel Office’i teemadel. Õnneks näitas vahepeal ka naljakaid videoid Peeter Ojast – kui märkas, et inimesed hakkavad liiga laiali valguma. Read the rest of this entry »