Hello World

“On öö ja ma ei maga jälle. Oleks vale väita, et und ei tule. Ma ei lase tal tulla. Lammaste lugemisest loobusin aastaid tagasi, kui mõtlesin välja algoritmi iseõppiva pildituvastustarkvara jaoks, mis annab sulle pärast mõningaid katseid murdosasekundiga kätte lammaste koguhulga mis tahes suurusega kujutlusväljas.”

Kui Sul tekkis küsimus, et mis jutt see siis nüüd on, siis selgituseks, et tegemist on lõiguga Sass Henno romaanist Proeksperdi ajaloo ainetel. Paberkandjal saab raamatut õige pea poodidest, aga tasuta e-raamatu saad kohe praegu alla laadida siit:

pdf: http://people.proekspert.ee/blog/HMK.pdf

epub: http://people.proekspert.ee/blog/HMK.epub 

Tarkvara arendamisel ettetulevate korduvate protsesside automatiseerimise väärtuses kahtlevad vist üsna vähesed kogenud arendajad ja projektijuhid. Tegelikus elus aga paraku ei ole automatiseerimine kõige prioriteetsem. Sellest võibolla räägitakse projekti alguses, aga töö käigus jääb see tihti unarusse.

Iga arendaja või testija, kes nüri järjekindlusega ühe ja sama toimingu sooritamise asemel eelistab midagi kasulikku oma projekti jaoks teha, peaks tundma automatiseerimise põhimõtteid. Projektijuht, kes teab meeskonna oskuste ja aja efektiivse kasutamise eeliseid ja ei soovi riskida projekti ebaõnnestumisega, peaks oma meeskonda julgustama leidmaks aega ja võimalusi automatiseerimise rakendamiseks.

Read the rest of this entry »

See postitus on ühest küljest kokkuvõte 23. novembril Londonis toimunud konverentsi Agile Testing and BDD eXchange 2012 keynotest, kus Gojko Adzic ning Dan North rääkisid metoodikast nimega impact mapping, teisalt on tegu ülevaatega raamatust Impact Mapping: Making a Big Impact with Software Products and Projects, illustreerivad joonised on laenatud siit.

Mis on impact mapping?

Impact mapping ehk mõjude kaardistamine on strateegiline planeerimismeetod, mis annab meeskonnale vahendid nõuete selgeks kommunikeerimiseks, aitab neil oma tegevusi ärieesmärkidega ühildada ja teha paremaid otsuseid. Selle meetodi kasutusala ei ole piiratud tarkvaraarendusega, samamoodi saab seda rakendada ka näiteks protsesside jms planeerimisel.

Read the rest of this entry »

Kui sa tuled Robotexile ja plaanid seal robotit progeda, siis loe alljärgnevat erilise tähelepanuga, sest see aitab sul võita 500 eurose auhinna. Asi on selles, et Proekspert annab ka sel aastal Robotexil välja auhinna kõige ilusama koodi eest ja siin on mõned vihjed, mida me hindame.

Mis on ilus lähtekood?

Ilus lähtekood on selgesti mõistetav ja hõlpsasti loetav. Loomulikult võiks hakata rääkima siin igasugustest tekstifaili küljendamise võimalustest: taanetest ja tühikutest kuni tühjade ridadeni ja kommentaaride stiilideni välja. Aga kuna me ei dikteeri Robotexi osalistele mingit konkreetset keelt, arendusvahendit ega platvormi, siis jääb ka koodi stiil nende enda valikuks. Küll aga hindame me stiili ühtsust (taane käib kas tühikutega või tabidega, sa ei saa neid vaheldumisi kasutada — või vähemalt ei peaks seda tegema, kui tahad kirjutada koodi, mis on arusaadav ka homme). Sarnaselt peab ka koodi blokke läbiva stiiliga esitama. Muutajate ja meetodite nimed on ilusas koodis alati arusaadavad ja sisu kirjeldavad. Kindlasti ei tohi need olla eksitavalt nimetatud.

Miks me seda hindame?

Jah tõesti? Miks ME (Proekspert) seda hindame? Tegelikult peaks iga Robotexil osalev tiim seda ise juba hinnata oskama. Teisest küljest mäletan ma oma tudengipõlve ja Robotexi kogemusest, et alati jääb üks öö puudu. See aga omakorda tähendab, et hakatakse _kiiruga_ lisama elutähtsat funktsionaalsust, mis pahatihti tuleb muude aspektide (koodi ilu/loetavuse) arvelt. Meie auhind on siinkohal lisaks vaimsele rahuldusele väikeseks lisamotivaatoriks, et koodi ilu mitte ohvriks tuua.

Kuna robotid, või peene välismaise nimega tööstusautomaatika on üks Proeksperdi peamisi tegevusalasid, siis arvame, et robotiprogemispraktikutena ja koodi ilu pühaks pidava ettevõttena saame oma kogemusi teiega jagada.

Miks keegi üldse peaks tahtma oma koodi meile näidata?

Ideaalses maailmas tahavad kõik tudengid oma koodi teistele näidata. Kas selleks, et saada tunnustatud õigeaegselt ja iseseisvalt sooritatud ülesande eest või selleks, et saada väärtuslikku nõuannet mõne ülesande optimeerimiseks või siis võistlemaks teise tudengiga, et näha, kelle kood käib kiiremini. Aga päriselus, kus on päris tähtaeg ja päriselt saavad (t)öötunnid otsa enne, kui võistlus pihta hakkab, on kood tihtipeale sama korras kui tudengi /homework folder (või kirjutuslaud) keset sessi.

Selleks, et Robotexil osalejaid ikkagi motiveerida meile oma koodi näitama (ning taluma meie žürii Priit P. ja Lauri V. piinlike küsimusi), on Proekspert välja pannud ka 500 eurolise auhinna kauneima koodiga tiimile. Kohtume peagi Robotexil ja seal ronime me juba teie robotite ajudesse!

1. novembril toimus Proeksperdis inspireeriva Gojko Adzic-i poolt läbi viidud seminar Winning big with Specification by Example (SBE). SBE on oma olemuselt kollaboratiivne lähenemine nõuete defineerimisele – fookus on kommunikatsioonil ja reaalsetel näidetel, et kõigil osapooltel tekiks ühine arusaam loodava süsteemi funktsionaalsusest. Positiivse lisana muutuvad SBE “õigel” rakendamisel nõuded ka automaatselt valideeritavateks – teatud tööriistade abil saab kõigile loetavas formaadis kirja pandud nõuded automaat-testideks muuta.

  Read the rest of this entry »

Jahedad ja vihmased sügisilmad lihtsalt on tubaseid tegemisi soodustavad ja kui üks hetk avastasin, et Rails Girls Tallinna septembrikuu workshopile registeerimine on avatud, siis oli asi otsustatud. Olen koolis paar põgusat programmeerimisteemalist kursust küll läbi teinud, kuid oma igapäevases kvaliteediinseneri töös koodi kirjutamisega siiski ei tegele. Ettevõttesiseselt on aga käimas raamatukogu arendus just Ruby on Railsi kasutades ja nii süveneski idee lasta end sel teemal natuke harida.

Igatahes Rails Girlsi näol on tegemist rahvusvahelise mittetulundusliku õpitoaga, mis on kõikidele huvilistele tasuta. Ahjaa, üks väike aga on ainult – osalejateks on vaid naised või kui ikka väga hästi läheb, siis lubatakse ka mõni mees uksest sisse. Muidugi ainult juhul, kui ta eriti ägeda ja tegija naise kaasa toob. Seekord vist keegi selle trikiga hakkama ei saanudki. Nagu tasuta asjade puhul ikka on ka Rails Girlsi workshopile tunglejate hulk alati suur (see aasta koguni 125 naist ning 2 meest) ja silmapaistmiseks tuleb ära täita paarist-kolmest küsimusest koosnev ankeet. See on võimalus demonstreerida oma suurepärasid ilukirjanduslikke võimeid ja korraldajaid võluda. Kusjuures kui “motivatsioonikiri” on atraktiivselt kirja pandud, siis tundub, et mida vähem programmeerimisest teada, seda suurema tõenäosusega ka Rails Girlsi üritusele kutse saab. Paar kevadel toimunud workshopilt välja jäänud neiut soovitasid oma kogemustest õppida ning oma koodi kirjutamise oskuste kohapealt enesekiitusega tagasi hoida. Just sel põhjusel sai oma ankeeti kirja pandud, et ei ole koodi näinud ja ei ole koodi teinud.

Mis see Rails Girls ikkagi on?

Rails Girls on 2010. aasta novembris Helsingist alguse saanud üritus, mida organiseerivad vabatahtlikud Ruby huvilised. Selgitusena olgu öeldud, et Ruby on programmeerimiskeel Jaapanist ning Rails veebiarenduse raamistik, mis siis Rubyt kasutab. Read the rest of this entry »

Levinumad acceptance testide loomise vahendid Behavior-Driven Development metoodikas on RSpec (Ruby jaoks) ja Cucumber (universaalsem). Olles mõlemat mõnevõrra pruukinud, tekkis küsimus, et kumb siis on lõpuks acceptance testimiseks parem. BDD põhitõdesid ei hakkaks ehk siinkohal kordama, vaataks hoopis Cucumberis ja RSpec’is testide kirjutamist hüpoteetilise Rubys kirjutatud veebirakenduse jaoks.

Mõlemad tööriistad kasutavad brauseri käitamiseks Capybara-nimelist veebirakenduste testimise raamistikku. RSpec’i ja Cucumberi erinevus seisneb peamiselt testi loetavuses ning kirjelduse nö. tasemes. Lihtne näide esmalt Cucumberi stsenaariumina:

Feature: Blog articles
  In order to have an awesome blog
  As an author
  I want to create and manage articles

  Scenario: Article index
    Given there are 2 articles
    When I go to the articles page
    Then I should see the following articles:
    | Article title |
    | Article one   |
    | Article two   |

Iga sammu tähenduse Cucumberile arusaadavaks tegemiseks tuleb need defineerida:

Given /there are (.*) articles/ do |number|
  number.times { |n| Article.create! }
end

Nagu näha, kasutab Cucumber testide kirjeldamiseks loomulikku keelt ja seetõttu on sellised testid väga hästi loetavad, samuti aitab kõrgema taseme funktsionaalsusele keskendumine kergemini vastata küsimusele “Mida meie rakendus õigupoolest tegema pidi?“. Teisalt on antud juhul vajalik kirjutada ka sammudefinitsioonid, et Cucumber teaks, mida meie loomulikus keeles kirjeldatud stsenaariumitega peale hakata, seega tekib testidesse üks lisakiht, mis samuti vajab ülalpidamist.

RSpec seevastu tegutseb madalamal, detailsemal, tasemel. Ülaltoodud stsenaarium üks-ühele RSpec’i ümber kirjutatuna võiks välja näha umbes selline: Read the rest of this entry »

Tegelikult ajendas mind kirjutama Valdo postitus SOAPi testide automatiseerimisest. Ma ei tea kuidas teile teistele tundub, aga minule jätab Visual Studio SOAPi testide jaoks küll ebaproportsionaalse mulje. Kõik see GUI ja proxide genereerimise wizardid ja noh peamiselt siiski – Windows only vahend – ei kõla nagu veebi testimiseks mõstlik. Aga eks ole Youtubest nähtud kuidas tankiga seenel ka käiakse või õlle jahutamiseks reaktiivmootor ehitatakse.

Jutt keerukusest kõlas intrigeeriv. Mõtlesin, et prooviks siis ise ka. Ütlen ausalt, ei olnud ka minul varasemat kogemust selles vallas. Aga et mitte igavalt Valdoga samasse auku astuda valisin keeleks Ruby.

Ruby install on kõigis enamkasutatavates keskkondades (mida mina kasutanud olen) sirgejooneline. Installerid on olemas või on Ruby opsüsteemi vaikimisi ära installitud. Pole vaja midagi “internetist otsida” ja mööda foorumeid aurata. Hilisem librade install käib sisse ehitatud package manageriga imelihtsalt.
Read the rest of this entry »

Proeksperdi plaan on testide laialdane automatiseerimine. Esimeseks katsetuseks sai telekommunikatsiooni projekt, kus iseteeninduse veebileht suhtleb teenuste serveriga ja infovahetus toimub vana hea SOAP protokolli abil. Regressiooni käigus tuleb testida, kas teenused käituvad õigesti ja seda saab teha käsitsi iseteeninduse lehte kasutades. Lühidalt öeldes: serverile on vaja saata HTTP päringuid ja veenduda, et tagasi tuleva paketi sees on õige info. Säherdune ülesanne tundub jõukohane just arvutile meie eest ära teha.

SOAP – Simple Object Access Protocol on tuntud asi, aga kohe kuulsin lisaks, et nii “lihtne” see ka ei ole. SOAPiga käib kaasas WSDL (Web Services Description Language) kirjeldus, mis on antud teenuse kirjeldus veebilehel. Sellest saab teada, mis funktsioone teenuselt kutsuda saab, mis argumente tahetakse, milline objekt tagastatakse ja mida objektid sisaldavad. Õnneks on asi nii standardne, et on olemas erinevates keeltes library’d, mis funktsioonide ja klasside genereerimise automaatselt ära teevad, ega ole vaja ise WSDLi dešifreerida. Tulemuseks on PROXY, mis võimaldab funktsioonide näol veebiserverile päringuid saata ja mingeid XMLi ega HTTP päringuid pole üldse vaja näppida.

1. päev – PERL

Automatiseerimise üks eesmärk on asjad võimalikult lihtsana hoida. Kuna olin sellega veidi kokku puutunud, sai esimeseks valikuks PERL. Otsimise peale selgus, et on kaks pakki Read the rest of this entry »