Blogi

Vuoden 2023 loppupuolella teetimme henkilöstöllemme vuosittaisen työtyytyväisyyskyselyn. Kyselyn tulokset ovat erinomaiset ja työntekijämme vahvasti suosittelevat Webscalea työnantajana. Tutustu blogitekstissä Talent Acquisition Specialistimme Juho Sopasen johdolla tulokseen ja sen taustoihin.

Kolme Webscalen konsulttia matkusti marras-joulukuun vaihteessa Las Vegasiin AWS re:invent konferenssiin. Lue blogista matkalla olleiden Heikin, Jussin ja Villen ajatuksia matkasta sekä heidän vinkkinsä kyseiseen tapahtumaan tulevaisuudessa osallistuville.

Yhteisöllisyyden merkitys työpaikoilla on korostunut erityisesti koronavuosien jälkeen. Mitä yhteisöllisyys tarkoittaa meidän työyhteisössämme ja mitä asioita teemme sen ylläpitämiseksi? Lue toimistopäällikkömme ajatuksia aiheeseen liittyen.

AWS-konsulttimme Johan kertoo blogitekstissä vierailusta Nordic Software Summittiin, joka järjestettiin Tukholmassa 29.8.2023. Tapahtuman aiheina olivat tekoälyn tuleminen IT-alalle sekä SaaS -yrittämiseen liittyvä tietotaito.

Mitä saavutettavuus on? Termi ei välttämättä ole kaikille tuttu, joten tässä nopea määritelmä sovelluskehityksen näkökulmasta: saavutettava sovellus on sellainen, jota pystyy käyttämään mahdollisimman kirjava joukko eri kykyisiä ihmisiä. Jokaisella tulisi olla yhtäläiset mahdollisuudet käyttää palveluita riippumatta siitä, mitä aisteja tai vuorovaikutuskeinoja hänellä on käytössään. IAAP-järjestön CPACC-sertifiointi tarjosi kattavan kokonaisuuden vammaisuudesta, toimintarajoitteista ja ihmisten arjessaan kohtaamista esteistä.

Webscale Tech Days -konferenssi järjestettiin yhteistyössä AWS:n kanssa perjantaina 26.5.2023 Tuusulan Krapissa. Tapahtuman teemana oli liiketoiminnan jatkuvuuden varmistaminen teknisestä näkökulmasta.

Parhaita työpäiviä ovat sellaiset, jossa päivän lopuksi voi todeta tuhonneensa pari tuhatta riviä ohjelmakoodia.  – H-P, Webscale Monelle IT-järjestelmien kanssa tekemisissä oleville ei-kehittäjille saattaa tulla yllätyksenä se, että kypsän järjestelmän kehittämisessä vaikein asia on monesti vanhentuneiden osien tuhoaminen. Johtuen juuri siitä vaikeudesta se on itselleni monesti suurinta työn iloa tuottava hetki, kun vihdoin saa teilattua lopullisesti pois vanhentuneita komponentteja. Laadukasta ylläpitoa vai toteutuksen täysi uusiminen? Tyhjästä rakennettavien järjestelmien alkukuukausina tuotetaan merkittävä määrä koodirivejä päivittäin, mutta saavutettaessa kypsä vaihe vuoden-kahden vaiheilla olennaisesti enemmän työtä vaatii järjestelmän laadukkaana ylläpitäminen ja olemassa olevien käyttötapausten tukeminen. Tästä pari vuotta eteenpäin ja väistämättömät muutostarpeet ovat jo lisänneet koodikannan kokoa, mutta vanhasta ei ole voitu vielä luopua, koska vuosien aikana niiden järjestelmien ympärille on ehditty jo rakentaa uusia integraatiopisteitä ja käyttötarpeita. Kehitystiimien työ ei ole aivan halpa resurssi, jolloin kehitysjohtajilta tarvitaan valistuneisuutta sijoittaa riittävä osuus tästä resurssista vanhojen järjestelmien tarkasteluun, perkaukseen ja hyvälaatuisena pitämiseen. Ohjelmistokehityksessä työkalujen, ohjelmointikielien ja kirjastojen luonteeseen liittyy se, että näitä kehitetään jatkuvasti ja vanhoista kirjastoista löydetään toinen toistaan luovempia tapoja väärinkäyttää niiden tietoturvahaavoittuvuuksia. Mikäli komponentteja ei kehitetä, loppuu niiltä usein myös tuki ja se tarkoittaa samalla haavoittuvuuksien jäämistä pysyväksi. Tällöin ainoat vaihtoehdot ovat lähteä tukemaan komponenttia itse tai luopua komponentin käytöstä ja kirjoittaa oma toteutus uusiksi. Monesti tällaisessa tilanteessa, jossa on pakko uusia oma toteutus on paras tilaisuus arvioida kyseisen toteutuksen tarpeellisuutta nykyhetkessä ennen työn käyttämistä sen päivittämiseen. Tarpeeksi aikaa vanhojen koodirivien läpikäyntiin Usein huomaan itse, että jo muutenkin vanhentuneet komponentit ylläpitävät vanhentunutta toimintatapaa, josta haluttaisiin eroon ylläpidettävyyden vuoksi: Jos sama toiminnallisuus voidaan muuttaa noudattamaan nykyistä toteutustapaa, voi hyvinkin olla kannattavaa tuhota vanha toteutus kokonaan ja päivittää riippuvuudet uudelle mallille. Tämä voi näyttäytyä uuden kehityksen kannalta tyhjäkäyntinä, josta ei saada uusia ominaisuuksia esiteltäväksi. Se on kuitenkin mielekkäämpää tyhjäkäyntiä kehitystiimin kannalta kuin vanhojen ongelmakomponenttien ylläpitämiseen kuluva aika. Varsinkin kun tiimeissä on väistämättä vaihtuvuutta tekijöissä, niin vanhentuneiden komponenttien ylläpitoon voi olla yllättävänkin vaikea löytää kunnon osaamista ja ymmärrystä niiden sielunelämästä. Kehittäjänä arvostan sitä, että on säännöllisesti käytettävissä aikaa vanhojen palikoiden perkaamiseen, päivittämiseen ja erityisesti sen liputtamiseen, että järjestelmä pitää tuhota ja päivittää uuteen. Suurelle suomalaiselle laitevalmistajalle tehdyssä muutaman vuoden pituisessa projektissa laskimme loppuvaiheessa keskimääräisen päivittäisten koodirivien määrän muutoksen per kehittäjä. Lopputulema oli noin +5 riviä koodia per päivä. Vanhat toteutukset oli hyvissä ajoin ajettu alas ja sillä saatu pidettyä kehitystyö mielekkäänä.

Viikon konsulttikysymys-blogisarjassa konsulttimme tekevät selkoa alan termeistä ja ilmiöistä. Vastaukset on mitoitettu sopimaan pieneenkin tiedonnälkään. Tällä kertaa pureudumme ytimekkäästi DevOpsin ja ohjelmistokehityksen maailmaan.

Vuosi 2020 alkaa olla paketissa - ja millainen vuosi se onkaan ollut! Nyt on hyvä hetki katsoa hieman taaksepäin ja summata viisi asiaa, jotka tänä vuonna ovat korostuneet.