Työpaikkablogi

UUSI MAAILMA

Aloittaessa työt 40-vuotiaassa ohjelmistotalossa vain kahden ohjelmointikurssin pohjalta, on koodaamisen parissa aukeava maailma uusi ja jännittävä.

Ennen Vertexillä aloittamista olin tottunut siihen, että ohjelmat olivat suhteellisen pieniä ja yleensä lähes kokonaan itse toteutettuja. Ohjelmat kääntyivät hetkessä ja koodia lukemalla oli helppo löytää mikä oli pielessä, jos ohjelma ei toiminutkaan halutulla tavalla. Kuitenkin heti ensimmäisenä kesätyöpäivänä oli selvää, että isommat ohjelmat toimisivat hieman eri tavalla. Useat syvälle menevät sisäkkäiset rakenteet tuntuivat aluksi pelottavilta ja niihin tutustuminen vei oman aikansa. Tämän lisäksi vikatilanteissa ongelmakohta ei välttämättä löytynytkään aivan yhtä helposti. Ja kun koodin laittoi aamulla kääntymään, ehti sitä odotellessa helposti käydä hakemassa (ja juomassa) kupin teetä tai kahvia.

Jostain syystä ennakkokäsitykseni työn aloituksesta ohjelmistofirmassa oli se, että kesän aikana ei välttämättä pääsisi ollenkaan koodaamaan. Tämä ei kuitenkaan pitänyt paikkaansa, koska heti ensimmäisten päivien koulutuksien jälkeen pääsin tutustumaan koodipohjaan ja sain ensimmäiset issuet tehtäväksi. Meitä aloitti mekaniikkatiimissä kaksi kesätyöläistä ja työnjako oli toteutettu siten, että molemmille tuli spesifiin aihealueeseen keskittyneitä tehtäviä, mikä auttoi siinä, että luettavan koodin alue pysyi hallittavan kokoisena.

Oma aihealueeni keskittyi erityisesti luonnospuolen kehittämiseen ja asiakkaiden toivomien uusien ominaisuuksien toteuttamiseen. Mieleenpainuvimpana ominaisuutena pidän uudistettua monikulmion piirtotyökalua. Vanhan toteutuksen hyödyntämisen sijaan toteutin koko toiminnon uudestaan, jolloin sain vapaasti suunnitella, miten halusin toteuttaa tarvittavan ominaisuuden.

Oli yllättävää, miten erilaiset koulussa opitut aihealueet kulkivat käsi kädessä uusia ominaisuuksia tehdessäni. En esimerkiksi olettanut kaipaavani matriisilaskentaa, mutta yllätyksekseni erilaisten transformaatiomatriisien pyörittely liittyi jollain tavalla lähes jokaiseen työstämääni aiheeseen aina viivan piirrosta tekstin paikoitukseen.

Kesän jälkeen voin todeta, että erityisesti taito lukea muiden kirjoittamaa koodia on parantunut huomattavasti. Isojen ohjelmien ja syvien tietorakenteiden käsittely on nyt paljon varmempaa kuin aiemmin – eikä ollenkaan pelottavaa. Yleisestikin kesällä opituista asioista on ollut paljon hyötyä, kun samoja asioita on käsitelty lisää nyt viimeisimmillä ohjelmistotekniikan kursseillani.

 

Voiko saaressa koodata?

#lukkolahtihackathon kesäkuu 2018

Meillä tuotekehitys pohjautuu paljolti olemassa olevien tuotteiden inkrementaaliseen kehittämiseen. Vuoden mittaan 3–4 viikon mittaisia kehityssprinttejä työstetään läpi kaikkiaan noin 15 ja niissä kooditehtaan voimin syntyy tuotteisiin satoja uusia ominaisuuksia ja parannuksia. Tehdyt teknologiavalinnat luovat tiukan viitekehyksen kehitykselle ja ohjelmistokehittäjien satunnaiset irtiotot saavat tuotepäälliköiden verenpaineen nousemaan.

Product backlogissa majailevien tuoteideoiden määrä on loputon ja mistään ei tunnu löytyvän aikaa kokonaan uusien näkökulmien, teknologioiden, menetelmien tai palvelujen tuottamiseksi. Juuri näissä uusissa hajatelmissa voisi kuitenkin piillä tulevaisuuden sankariominaisuudet, jotka helpottaisivat kaikkien arkea.
Näistä lähtökohdista ja omassa Angular-workshopissa Markon puolihuolimattomasti heittämästä läpästä syntyi ajatus hackathonista, jonka tarkoituksena olisi unohtaa kaikki entinen ja astua kokonaisvaltaisesti pois mukavuusalueelta kenties vielä mukavammalle alueelle. Ajatusta puolsi myös kiky-sopimuksen velvoittama 24 tunnin työajan pidennys, joka meillä Vertexillä toteutetaan lähes minä tahansa työyhteisöä palvelevana "projektina", jonka voi tehdä yksikseen tai yhdessä toisten kanssa.


Antti:
Lukkolahteen päästyämme ja tavaroiden purkamisen jälkeen, kaivoimme läppärit repusta pöydän ääreen ja rupesimme hommiin. Ennen hackathonin varsinaista alkua kaikki meistä oli jo ottanut selvää ja testaillut käytettäviä teknologioita, myös varsinainen projekti oli sovittu ja aloillaan. Paikan päällä projekti jaettiin yhdessä edelleen osiin, jotka jaettiin eri henkilöille. Valmistautumisen myötä alkukankeus oli vähäistä ja jo nopeasti aloittamisen jälkeen saimme aikaan tuloksia. Varsinaisena tavoitteenahan ei ollut itse projektin loppuun asti vienti, vaan uusien ennestään tuntemattomien teknologioiden kanssa toiminen ja uuden oppiminen.
Varsinkin oppimismielessä ryhmässä tekeminen oli erinomaista. Kysymyksiä voitiin heittää ilmaan ja pohdittiin ja tutkittiin yhdessä, tai jollain oli jo vastaus ongelmaan. Kaiken kaikkeaan ilmassa oli siis vahvaa tekemisen ja oppimisen meininkiä. Eikä varmasti miljöö, saunominen, järvessä pulahdus ja grillaus haitanut koodailua, joka jatkui vielä myöhään yöhön puhdistumisen ja maukkaan grilliruuan jälkeen.

Jari:
Kokemamme jälkeen voimme todeta, että ainakin tämän kaltainen web-sovelluksen kehitys onnistuu nykypäivänä helposti kaikkialla, missä on vähintään 4G-mobiililaajakaista käytettävissä. Työn suoritus ei ole aikaan eikä paikkaan sidoksissa. Myös tiiviissä vuorovaikutuksessa työskentely oli ehdottomasti kokemisen arvoista ja sai positiivisen vastaanoton. Oli helppo vaihtaa ajatuksia ja saada apua, kun kaveri oli vieressä. Tunnelma antoi myös uudenlaista potkua, eikä hommaa olisi millään malttanut keskeyttää. Tällaista työskentelytapaa voisi jatkossa ehdottomasti soveltaa myös varsinaiseen työhön.

Marko L:
Itseorganisoitunut poikkitieteellinen ryhmämme oli valmistautunut hyvin ja "töihin" päästiin heti saareen saavuttuamme. Vuorovaikutus ja ideoiden lentely oli aivan toisenlaista kuin tylsässä neukkarissa, jossa ajatukset helposti kiertävät samaa vanhaa kehää. Tavoitteet saavutettiin hyvin, eli opimme uusia tekniikoita ja työkaluja sekä saimme valmiudet tehdä niillä jotain ihan oikeaakin. Harjoitustyönä tehty monen käyttäjän ja alustan reaktiivinen sovellus saatiin lähes tuotantokelpoiseen kuntoon, vaikka se ei ollutkaan tärkeintä. Ehkäpä epätodennäköisen kesäsadepäivän sattuessa kohdalle tähän tulee vielä palattua...
Innostuksen määrästä voi päätellä jotakin siitä, että perjantai venyi lopulta ~18 tuntiseksi (kahdelta yöllä jouduttiin lopettamaan, kun silmät eivät enää pysyneet kunnolla auki). Lauantaina tehtiin hieman lyhyempi päivä, mutta ei se siihen jäänyt: illalla kotona oli vielä pakko vähän jatkaa! Saaressa ei vain voi, vaan myös pitää koodata. Viimeistään keväällä uudelleen, seuraava puolihuolimaton läppä mietinnässä =D.

Marko M:
Kuten niin usein näinä aikoina voi todeta, että ”ei se ole enää tekniikasta kiinni”. Teknisesti toteutus onnistuu kyllä, mutta uuden asian oppimisessa on tietty oppimiskaari, mikä ottaa aikansa. Asynkronisen toiminnan ymmärtäminen käytetyssä alustassa vaati vanhojen ajatusten kääntämistä uuteen asentoon. Tässä auttoi rento ympäristö ja ilmapiiri sekä selvä irtaantuminen vanhasta kaavasta. Ryhmädynamiikka ainakin tällä ryhmällä toimi erinomaisesti ja kaikille löytyi mielekästä tekemistä itseohjautuvasti. Koin oppineeni jotain aivan uutta lyhyessä ajassa tehokkaasti, ja viikonlopusta jäi vielä versionhallintaan hyvä demopohja itseopiskelun jatkoksi.

Anssi:
Saaressa voi todellakin koodata, ja eikä vain koodata vaan samalla kertaa tutustua, kokeilla ja ottaa lähes tuotannolliseen käyttöön uusia teknologioita ja pilvipalveluina tarjottavia kehitystyökaluja tai -alustoja. Ja tässä vaiheessa koodaaminen muuttuukin kokonaisvaltaisemmaksi case-sovelluksemme asiakastarpeiden hahmottamiseksi tai jopa palvelujen muotoiluksi. Normaalissa tuotekehityssyklissä ja konttorirutiineilla vastaavan annostukseen uutta menisi useita päiviä, ellei viikkoja. Kun Markon seuraava läppä lentää, olen mukana!

34-tunnin aikana koettua


Softat, palvelut jne...
•    Git & Github  -versionhallintajärjestelmä
•    Visual Studio Code -editori (Microsoft)
•    Angular/typescript - web-sovellusten kehitysalusta/-kieli (Google)
•    Firebase - web-sovellusten kehitysalusta (Google)
•    AWS S3 - laskenta- ja pilvitallennuspalvelut (Amazon)
•    Kettukeksit (Jaffa Pihlaja)

Käytetty laitteisto
•    Windows ja Linux läppäreitä
•    Android-puhelimia ja iPhone
•    4G-yhteydet puhelinten kautta
•    Yhteysvene Linder ja perämoottori Yamaha 4.0 hv
•    Vararengas, tunkki ja rengasavain
•    Pekonia ja munia
•    Firman mökki ja sauna saaressa
 

Fixing the Water Leak – what do you do?

I saw an interesting event DevOps Tooling Day at Pasila Helsinki somewhere around two years ago. The keynote was about how to boost your Software Development with DevOps. Having our current situation in mind with 40 years of expertise and 5–6 million lines of code, I decided to give it a shot and popped up at the venue. With our in-house CI-environment up and running full steam and some personal expertise about Atlassian CI/CD Tools (Jira, Bamboo and Bitbucket) I was eager to find out ideas how to boost Vertex Systems development process.

During the day, I was privileged to hear stories about Volvo and Accenture how they emerged from traditional software process towards Agile and DevOps. At lunch break some networking discussions really hit the break. A small detail at subordinate clause took my attention: Continuous Code Quality and Coverage after each commit as a part of automatic regression tests with SonarQube. An excellent day.

Long ride back to Tampere with a lot of thoughts in mind I decided to try it on my hobbyist CI/CD environment. After couple of long nights, I was able get it running on my personal server with Bamboo and Bitbucket checking the Code Quality of a Java EE / JSF based application. After a first glance, I was not so convinced. A lot of bugs and security vulnerabilities. What? Doesn’t this system really know how to write good code? There must be a lot of false positive errors. I decided to leave it alone, for a while.

At Vertex, I started thinking how to spend my three "out of the box" days helping myself and my company? That’s a good question. Should we give the SonarQube a chance in our development process? After selling the idea to our Build Manager Panu Outinen, we decided to try it together. And raised the bar to include the Code Coverage after unit, integration and ui tests are ran after each commit.

To go back to heading, water leaks and creating bad code have much in common. When you see a water leak, do you fix the problem immediately or let it leak for days before mopping the puddle?

Similarly, should we let bad code escalate and wait for periodic reviews or should we notice and fix the problems earlier?  Fixing the leak means putting the effort to “new” code and running quality checks every day or even on every commit if possible time-wise.

Code Quality with SonarQube is now part of our Vertex Flow development process checking the quality and coverage on every commit. We are also using SonarLint with IntelliJIdea of trying to check quality problems as typing new code on IDE. The Code Coverage reports are created after running automated regression to see the parts of the code fully covered of the tests. The report helps to design and implement new unit and ui tests to increase the code coverage systematically.

I want to thank Panu Outinen about the times we spent over night knitting together existing ant-based building scripts with maven. And helping to get the system up and running with me. Special thanks to Henri Helevä, Anssi Männistö, Jari Avikainen, Petri Molkkari and Juho Kärnä for taking the code quality seriously and for putting an effort to a “new” bug free quality code.

Timo Tulisalmi
CTO, Vertex Systems Oy
Leader and Passionate Developer at Night