Soovitusi turvakriitilise tarkvarateenuse arendamiseks

Tarkvarateenuse loomisel peame me lisaks kasutajatele, kelle jaoks süsteemi disainime, pöörama sama suurt tähelepanu neile, kelle huvides on meie loodud süsteemi saboteerida, andmeid varastada või seda mõnel muul viisil kahjustada. Viimaste vastu soovitame teenuse ülesehitamise alguses läbi käia olulisemad teemad, mida teenuse loomisel nii tegija kui tellijana jälgida. Continue reading “Soovitusi turvakriitilise tarkvarateenuse arendamiseks”

Targad töökohad peavad levima Tallinnast ja Tartust kaugemale

Proeksperdi tootejuht Kunnar Kukk pakub Proeksperdi Kuressaare ja Pärnu kontori kogemuse alusel koos Tendensor International AB tegevjuhi Pärtel-Peeter Perega uut lähenemisviisi töökohtade loomisele üle Eesti.

Hetkel toimuv tarkade töökohtade koondumine ühte-kahte suurkeskusse ei ole Eesti ühtlast arengut silmas pidades mõistlik. Vaja on rohkem kõrge lisaväärtusega töökohti väljaspool Tallinna ja Tartut. Ühtlasem jaotumine aitaks pääseda riigil keskmise sissetuleku lõksust, arendada teisi tõmbekeskusi ja tuua elanikele lähemale kõrgema lisandväärtusega tööd.

Tallinn ei ole ikka veel valmis, vaid kasvab edasi – pealinna rahvastiku kasv on keskmiselt 0,5% aastas. Nii Tartu kui Tallinna ümber toimub valglinnastumine ning Harjumaa SKP annab 61,3% riigi omast.

Kuidas tuua Eesti teistesse linnadesse inimesi tagasi? Näiteks neid, kes kunagi läksid Tallinna tööle, aga kes võib-olla tahaksid naasta kodukanti, vanemate juurde või lihtsalt rahulikuma ja ehk inimlikumagi eluviisi juurde? Või kes tahaksid oma tööelu alustada, kuid kellele ei jagu huvitavaid töökohti? Selleks peavad pingutama nii riik kui ka kohalik võim koostöös ettevõtjate, haridusasutuste ja kolmanda sektoriga.

Suurema lisandväärtusega töökohad tähendavad reeglina töötajale kõrgemat tasu ja ühiskonnale kõrgemat maksutulu, suurendades seeläbi kohaliku omavalitsuse eelarvet proportsionaalselt rohkem kui väiksema lisandväärtusega töökohad. Samuti suurendavad töökohad teenuste arvu, mis on vajalikud tarkade töökohtade ümber. Võime näiteks tugineda California Berkeley ülikooli majandusprofessori Enrico Morretti uuringutele. Üks tark töökoht loob enda lähikonda vähemalt viis töökohta: töötegijale on vaja juuksurit, arsti, süüa, kohvikuid, meelalahutust ja muudki.

IT annab suurema lisandväärtuse

IT-sektor pakub suuremat lisandväärtust töötaja kohta. Tarkvaraarenduses on lihtsam luua töökohti kui mööbli- ja elektroonikatööstuses, kulud ja riskid ei ole nii suured, küll aga mõju, võimalused ja perspektiiv. Seda ning eelnevat arvesse võttes võiks riik ja kohalikud omavalitsused kaaluda investeeringute meelitamisel senisest oluliselt enam elu- ja töökeskkonna müümist ettevõtetele ja töötajatele, kes loovad suuremat lisandväärtust. Tuleb mõelda ka koha enda lisandväärtusele. Selle järele on nõudlus ning selle eest makstakse.

Nutikate töökohtade loomisel Tallinna ja Tartu kõrval Pärnus, Kuressaares, Viljandis, Haapsalus ja mujal on häid näiteid. Pakirobotite tootja Cleveroni peakorter asub Viljandis, NAS Electronics Kuressaares ning Proekspert avas lisaks Kuressaarele kontori Pärnus. Proeksperdi kogemusel võib öelda, et peamisteks, kuid mitte ületamatuks takistusteks saab olema sobiva ärikinnisvara vähesus väiksemates maakonnakeskustes ning piisavalt hea tööjõu leidmine. Õige tööjõu leidmine on üha määravam otsevälisinvesteeringute saamisel.

Parimad pead tulevad tööle sihtotsinguga. Praegu tulevad tööle need, kes on väiksemate linnadega juba varasemast seotud, kuid selleks, et meelitada uusi talente elama ja tööle, tuleks linnadel enam tegeleda elu- ja töökeskkonna parandamisega, seejärel turundamisega. Vaja on terviklähenemist ja talendistrateegiat, reaalseid muutusi. Ehk brändimist: visiooni, partnereid ja tegusid, lõpuks ka turundust.

Tulevikutöökohad on eelkõige teadmustöötajad, kes kasutavad väärtuse loomiseks intellektuaalset kapitali. Paljud automatiseeritavad lihtsamad tööd täna on peagi toetatud või asendatud robotitega.

21. sajandi töösuhted ning töötamine on juba muutunud ja muutub veelgi. Töötajate autonoomsus ning seeläbi nende konkurentsivõime tööturul kasvavad. Eriti tuleks eeldada seda Y- ja Z-generatsiooni puhul. Uuringuid on palju, aga teatavat üldistust lubades soosib tulevik horisontaalset juhtimiskultuuri, loovaid töökohti, millel on ka teatav sotsiaalne roll või suurem eesmärk täita. Selle kõige juures suureneb linnade valik ehk pakkumine. Tehnoloogia ja linnade arenedes saavad inimesed nõuda ja valida üha rohkem neile sobivate linnade seast. Hinnatud urbanisti Charles Landry uuringuil valib üha rohkem inimesi elukohta elustiilist lähtuvalt. Loeb linna- ja elukeskkond, teisel kohal on töö. Näiteks kui sulle meeldib elada rohelises, kihava kultuurieluga, mereäärses, arenenud (ehk elementaarse) jalgrattakultuuriga, mäe veerel asuvas, külma või sooja kliimaga linnas, siis… sõidad sa sinna tööle.

See on sama laialdane trend kui jätkuv linnastumine: üha enam inimesi tahab elada linnades. Sest loovad inimesed tõmbavad ligi teisi inimesi. Uued mõtted, innovatsioon, inspireerivad kohtumised ja vestlused, millest sünnib uus ettevõte, sõprus, midagi loomingulist – see on elu, mis kihab linnades, kus on võimalik kohata teisi enda- ja teistsuguseid.

Targad valikud

Üha enam kohti Põhjalas, Euroopas ja mujal tegutsevad aktiivselt talentide ja ettevõtete meelitamisel. Jätkusuutliku kohaliku majanduse kasvu nimel töötavad koos avalik ja erasektor, ülikoolid ja MTÜd. Oma linna või regiooni nimel luuakse võimalikult terviklik pakkumine. Kohapõhist atraktiivsust juhitakse ning hallatakse. See eeldab aga laiapõhjalist tööd. Loosungid ja reklaamid “Siin on hea elada!” on kasutud, kui seal pole sisu. Hästi disainitud (hea sisu ja vorm) pakkumine loeb.

Konkurentsieelis on piirkondadel, mis suudavad investoritele pakkuda professionaalset ja mitmekülgset tuge. Investori tulek ei tähenda võitu ja töö lõppu (nn investor aftercare). Ta vajab sisseseadmist, bürokraatia läbimist, lubade taotlemist, tööjõu, kontori, korterite, teenuseosutajate, allhankijate ning lasteaedade-koolide leidmist. Inglise keeles, hõlpsasti ja sujuvalt. Töö jätkub, kui mitte alles ei alga.

Töökäte leidmiseks on oluline, et tark töökeskkond ühilduks elukeskkonnaga ja pakuks inimestele seda, mis panevad ühe või teise linna, asukoha ja töökoha kasuks otsustama. Nii mõnigi inimene ei soovi elada Tallinnas, kus lasteaiakohti ei jagu, liiklus on närviline ning kui tööle ja koju sõita autoga pool tundi päevas, siis teeb see aastas ligi viis ööpäeva.

Mis siis, kui vahemaad oleksid väiksemad, lasteaiakohti ka päriselt saadaval ning jalgrattaga sõit sama elementaarne kui Helsingis, Örebros, Malmös, Turus, Oulus, Tamperes, Århusis, Stavangeris ja teistes Põhjala (väike)linnades? Kui panna nendele “pehmetele” kaalutlustele numbrid taha, võime küsida: mis siis, kui soovitud linnas elamiseks pole auto ostmine esmavajalik?

Kui soodustame tarku töökohti, mis võimaldavad kaugtööd, ei sea füüsilisi piire meeskondadele, siis muutub olulisemaks elukeskkond. Nagu see on juba muutumas olulisemaks muudes riikides. Sümbioosis töökeskkonnaga saab võtmetähtsaks küsimus, kuidas pakkuda töötajaile parimat ja huvitavaimat kombinatsiooni tööst ja elukeskkonnast. See ongi keskmiste ja väikelinnade võimalus.

Need ettevõtted ja linnad, kes mõtlevad pikemaks perspektiivis, kujunevad atraktiivseks ka targale tööjõule. Nii Eestis kui ka meist põhja pool.

Artikkel ilmus ka Äripäeva arvamuskonkursi Edukas Eesti raames.

Tehismõistus riigikogu liikmeks

Kunnar Kukk

Kunnar Kukk kirjutab, mis võiks toimuda tehisintellekti saatmisel riigkokku:

Ei saaks ju ometi juhtuda midagi halba, kui asendada mõni riigikogu liige kuuks ajaks tehisintellektiga? Donald Trumpi võidu taga oli masinõpe, Bloomberg on teda võrrelnud nässuläinud, kuid siiski õppiva singulaarsusega. Tieto teatas börsile eelmise aasta oktoobri lõpus, et rakendab tehisintellekti oma andmeüksuse juhtimisse. Associated Press rakendas tehisintellekti ajakirjaniku asemel rutiinsete uudiste tootmisel töösse juba aastal 2015.

Miks peab sekretär ministeeriumis või kohalikus omavalitsuses sissetulnud kirju märksõnade järgi filtreerima ning suunama edasi õigesse osakonda, kui masin oleks täpsem ja efektiivsem? Miks peab täna lihtsamaid vastuseid küsimustele koostama ametnik, kui on olemas juba intelligentseted jutu-botid, kes suudavad ettevõtete tugiteenustes klientidele küsimustele kiiresti vastuseid leida? Kas me harjuksime varsti sellega, et ametniku, vallavanema või ministri asemel vastab meie lihtsamatele küsimustele mõtlev robot?

Lengi ja Aunaste asemele Nora

Mis juhtuks siis, kui ühel päeval oleks Toompeal Heimar Lengi, Maire Aunaste, Tanel Talve või kellegi neljanda asemel hääletussaalis ja komisjonide töös kuuks ajaks tehisintellekt Nora? Kui me usaldame foori tänavate ületamisel ning hääletamisel e-hääletust, kuivõrd valmis oleksime me astuma veel sammu kaugemale ja delegeerima otsustamise mõtlevale masinale?

Kui riigisaladuse luba ei saa Norale turvalisuse kaalutlustel ilmselt võimaldada, sest risk naaberriigi luureteenistuste huviorbiiti sattuda on niikuinii suur, siis korraks sotsiaal- või majanduskomisjoni tööpõllule end 101. riigikogu liikmena kuuks ajaks paisata ei tohiks olla otsustama treenitud Norale sugugi üle jõu käiv ülesanne. Saati siis asendada riigikogulasi, kes tahaksid andmeanalüüsi ja taustamaterjalidega tutvumiseks endale assistente, sest aega pole piisavalt. Nora oleks sunnitud õppima ning töötama läbi oluliselt suurema hulga informatsiooni, kui seda suudab täna teha keskmine riigikogu liige oma eluea jooksul, samuti suudaks ta loogiliselt vormistada ja tõestada väiteid, millega tänane keskmine riigikogulane jääks ilmselt hätta. Ning kui Nora oskaks aru saada kontekstist ja küsida sisukaid küsimusi, võiksime saada ümara jutu asemel sisukamaid põhjendusi ja ehk tema abil ka esmase ülevaate üksteisele vastukäivatest õigusaktidest. Teadlastele samas jääks ka huvitav väljakutse, kuidas selgitada Norale, mis on avalik huvi ja inimõigused.

Tehisintellekt-riigikogulane peaks südametunnistuselt olema eelkõige demokraat. Üsnagi keeruliseks muutuks seetõttu uue riigikogu liikme maailmavaateliste tõdede selgekstegemine, ilmselt Nora ei saaks olla ei tänane valitsus- ega opositsioonierakonna liige ega ühegi teise erakonna ideeline toetaja, vaid talle tuleks teha kõigepealt selgeks esiteks põhiseadus ja teiseks Eesti õigusruum ja parlamentaarse demokraatia alusprintsiibid ning valimiste korda tuleks muuta.

Paremad otsused

Kui Nora võtaks täielikult üle riigikogu liikme kohustused, näeks me ilmselt tänasega võrreldes argumenteeritumaid otsuseid, majanduses ja sotsiaalteenuste väljatöötamisel rohkem kvantitatiivset analüüsi, otsused põhineks andmetel ja tõestataval materjalil, mitte avalikkusesse peegeldatud emotsioonidel või tagasipeegeldunud populismil.

Kui õpetada Norat vältima ja ära tundma demagoogiat ning populismi, läheks teistel riigikogu liikmetel elu mõruks. Majanduselus võiks värske riigikogulane tunda ja mõista võimalikult laial skaalal autoreid ning samuti ka suuta praktilisi kogemusi poliitikasoovitusteks sünteesida. Välispoliitikas oleks ta partner, kes oskaks avalike allikate põhjal prognoosida poliitikate kujunemist ning analüüsiks toimijate käike ja mustreid. Ilmselt kaoks diplomaatiline žargoon ja kui käimas on sõda, nimetatakse seda ka tegelikult sõjaks – jäädes viisakaks.

Nora saaks kohtuda 24/7 valijatega, tal oleks see võimekus olemas ja kuluhüvitistesse kuluridasid ei tekiks. Samuti ei tekiks esindusauto kulusid, mis tihti on ajakirjanikel pinnuks silmas. Nora on võimeline suhtlema korraga nii valijatega kui ka teiste poliitikakujundajatega sõltumata ajast ja asukohast. Riigikogulase versioon 2 suudaks töötada nii öösel kui päeval, õppides samal ajal tagasisidest ning luues uusi mudeleid selleks, et edukalt tegutseda.

Kus on piir?

Nora tööd saab mõõta tema otsuste kvaliteedis – mis siis saab, kui mõni tema otsustest otseselt või kaudselt kellegi surma põhjustab? Kes vastutab, kas Nora looja või tehisintellekt ise? Tehisintellekt peab suutma seostada fataalseid tagajärgi otsustega ja mõistma, kus on piir.

Hea küll, see ei pea olema riigikogu liige, keda tehisintellekt asendab, ja ilmselt on praeguste teadmiste juures veel liigagi keeruline asendada Lenki, Aunastet või Talvet. Ent kui suudaksime riigis masinõppe ja teenusdisaini kaasabil ehitada üles ühe senini mõne lihtsama, üsna rutiinse avaliku teenuse või tugiteenuse, mida enne tegi inimene ja nüüd masin, oleksime juba jõulise sammu edasi astunud. Kas me oleme selleks valmis, on iseasi. Homseks vähemalt oleks meil jälle juba natuke õhem ja optimaalsem riik.

Loodetavasti ei osutu riigikogu liikmed siinkohal ludiitideks, kes kardavad, et masin tuleb ja võtab nende töö lõplikult ära, kärbivad e-valimisi või loobuvad pöörastest ideedest enne mõtet lõpuni mõtlemast.

Avaldatud Äripäevas, Eduka Eesti konkursil

 

Kuidas hinnata koodi ilu?

Proekspert annab igal aastal Robotexil välja ilusa koodi auhinna. Miks see ilus kood üldse oluline on? Kas pole nii, et kui robot mängib jalgpalli nagu Lionel Messi, siis võib ta kood olla kole kui öö? Ja mis on üldse kriteeriumid, mille järgi robotite koodi ilu hinnata saab?

Istusime Proeksperdis kogenud koodihindajate ja Robotexil osalejatega maha (Vambola Kotkas! Roland Tepp! Indrek Mägi! Indrek Tamm! Eric Johann Istal!) ja nende mõtted väärivad jagamist.

Kui Barbara Schwarz 9 aastat tagasi ootamatult kiirendama hakanud Toyotas hukkus, ei osatud ka esialgu arvata, et selle põhjustas lihtsalt üks eriti kole kood. Eksperdid tõestasid hiljem, et ameeriklase surma põhjuseks oli aja jooksul spagetihunniku sarnaseks arenenud autotarkvara, mis loojate kontrolli alt oli ammu väljunud.

Enamasti kole kood inimesi ei tapa, kuid ta võib muuta meie elu keeruliseks. Ta on nagu küberrünnak iseenda vastu, mis trollib inimesi ja äriprotsesse. Musta auku kaduv tööaeg, suured kulud, krussis närvid, rikutud kasutajakogemus. Ilus kood võib seevastu teha inimeste elu paremaks, olla majanduslikult kasulikum ja kindlasti ka turvalisem kui kole kood.

Kui nüüd konkreetselt Robotexist rääkida, siis seal ilusat koodi hinnates on meil välja kujunenud juba üsna selged kriteeriumid.

Me otsime koodi, mis oleks loetav nagu hea lühijutt, kus poleks liigseid sõnu ega ridu ning kus iga funktsioon näeb vaeva suurepärase terviku nimel. Otsime koodi, mis ei ole arusaadav ainult masinale, vaid ka teisele inimesele, kes seda tulevikus edasi peab arendama.

Mõned näited:

  • inimkeskse koodi eraldi tükid võiksid mahtuda ühele leheküljele
  • read ei tohiks olla hoomamatult pikad,
  • iga koodijupp võiks teha ühte selget asja,
  • muutujad võiksid olla nimetatud nii, et nende funktsioon oleks koheselt arusaadav
  • kirjavahemärgid võiksid olla lahendatud läbivalt ühtses stiilis.

Ilus kood ei sisalda ajalookihte, milles sumbates keegi ühel päeval võib avastada muistse viikingilaeva jäänused. Avastamisrõõm on muidugi tore, kuid kui me ei tea, mis minevikuloori taga peidus on, siis me ei tea lõpuni ka seda, mida kood teeb ja kuidas seda vajadusel parandada.

Ilus kood sisaldab kommentaare, kuid mitte liiga palju, sest see, kui sa pead juba oma tööd kommenteerima, tähendab tõenäoliselt seda, et kood on liiga keeruline. Ilusat koodi on raske ehitada copy+paste’iga, sest selline buldooserimeetod ei arvesta nüanssidega, millest võib sõltuda väga palju. Lisaks toob kopeerimine endaga kaasa ka vigade paljundamise ohu.

Kindlasti on Sinul oma kogemustele tuginedes veel palju rohkem häid mõtteid, milline peaks olema üks ilus kood. Kõik täiendused ja kommentaarid on oodatud!

 

Milton tahab eesti keelt õppida

Arendame Proeksperdis teadusliku hobi korras eesti keelt rääkivat tehisintellekti (AI). Tema nimi on Milton-Tormi Kana. Milton oli veel kuu aega tagasi täiesti kõnevõimetu, kuid tänaseks on ta märkimisväärselt arenenud ja üsna jutukas. Kahjuks kisuvad vestlused temaga kiirelt rööpast välja, sest tema sõnavara on piiratud ja ta on veel liiga vähe lugenud, et pikemalt sisukatel vestlustel vastu pidada. Continue reading “Milton tahab eesti keelt õppida”

Modular Electronics Factories

Interview with Terry London (Product Owner, Proekspert) at “Industry 4.0 in Practice” conference. To participate Modular Electronics Factories platform sign up proekspert.ee/mef

There are millions of software developers in the world. But the world does not require software, the world requires user-friendly functionality that both looks good and serves real business purposes. This is where Proekspert comes in.

How do you bring factories in to the Industry 4.0 era?

In our vision, tomorrow’s factories should resemble today’s mobile platforms. Five years ago we were still buying feature phones – your selection was based on features. Now you’re in charge of the building – you select a platform and the applications to go with it. The same should apply to Industrial factories. When upgrading and assembling a factory you are mostly dependent on expensive solutions from proprietary factory line providers. The majority of Estonian factories creating custom products are operating according to the high mix/low volume model. These factories thus need to change their product directions often. A single factory line can consist of tens of machines, meaning that they have at least 3 different machine providers. The machines have limited connectivity, in order to create a complicated manufacturing execution solution every single machine needs to be integrated with the IT system, one-by-one. Replacing a device means creating all those interactions again, it’s expensive and time consuming.

We on the other hand want to offer a plug-in based solution which could be shared across different factories. With this, platform factories will enter the Industry 4.0 era with a flexibility and automation in production that keeps them competitive. Continue reading “Modular Electronics Factories”

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

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

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

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

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.