Author Archives: Hätinen Antti

About Hätinen Antti

Managing Director for Pharazon AB

Tunnustus yksikkötesteistä

Coding

Tänään täytyy tunnustaa, että tuli taas kerran tehtyä cowboy-koodausta suoraan masteriin erääseen PHZ Full Stack:n omaan tuotteeseen ilman code review:ta, ja puskettua tuotantoon päivityksiä vaikka CI sanoi, että testit ovat punaisella.

Olin tehnyt “parannuksia” coding convention:iin ja korjannut yhden “ilmiselvän” bugin, “selkeyttänyt” koodia luettavammaksi ja ottanut kielikäännökset käyttöön myös REST API:ssa, viisveisaamalla testeistä.

Ylläripylläri tuotanto ei sitten toiminutkaan enää kriittisissä rajapinnoissa. Lähdin selvittämään mistä virheet johtuvat.

Jälkiviisautena ei siis pitäisi olla yllätys, että vaikka nyt kielikäännökset toimivat, niin kaikki muut kohdat joihin oli muutettu yksikin rivi olivat kaikki hajonneet, ja tämän lisäksi puoli tusinaa muuta ominaisuutta, joita en olisi odottanut menevän rikki tehtyjen muutosten seurauksena. Onneksi aiemmin tehdyt yksikkötestit (jotka nyt siis olivat punaisella ja joita ei oltu ajettu) paljastivat kaikki bugit.

Ensimmäinen automaattitestin paljastama ongelma oli ternary statement:n, jossa “selkeytyksen” seurauksena oli true/false logiikka kääntynyt väärin päin. Ehdotukseni tosin on, että ternary statement:tit kielletään firman Coding Convention:ssa, koska juniori-koodaajat eivät ymmärrä niistä mitään ja senioritkin näemmä ymmärtävät ja kirjoittavat ne väärin. Luettavampaa (tosin pidempää) koodia saa aikaan if/else:llä.


muuttuja = testi ? true : false;

Toinen “parannus” oli muuttujan nimen refaktorointi, tosin rajapinnasta. Tietysti tämä oli typotettu “joyfullId” kun piti olla “joyfulI” siten, että testit eivät vastanneet toteutusta. Onneksi taas testit huomasivat virheen.

Kolmas “ilmiselvän” bugin korjaus taas rikkoi sisäänkirjautumisen.

Refaktorointi taas muutti Depency Injection -containerin toimintaa niin ettei testit toimineet tietokantamock:ien osalta lainkaan.

Tästä taas vaihteeksi oppineena lupaan seuraavan kerran olla laittamatta tuotantoon koodia, jos testit ovat punaisella. Tämän varmistamiseksi viritetään CI loppuun asti, että nykyisen testiympäristön automaattideployment:n lisäksi myös tuotanto päivitetään CI:n kautta, mutta ainoastaan jos kaikki testit ovat vihreällä.

Published by:

PHZ Full Stack Havu Gaming cooperation

We are glad to announce that we have a new main sponsor for the year 2018, PHZ Full Stack Oy.

PHZ.fi is a leading IT consultancy and coding company in Finland. PHZ offers software and UI development services for private and public sector customers.

“We are very happy about this partnership. It gives HAVU possibility to reach new level as a eSports organization. – Lasse “klashy” Salminen, CEO / HAVU Gaming

“We want to support the Finnish eSports scene. We share the common values with HAVU and developers need a similar skillset what top players in eSports need to succeed. – Antti “Pharazon” Hätinen, CEO / PHZ Full Stack Oy

HAVU players will play under the HAVU.phz in-game tag in the future.

Published by:

Package visibility is the best visibility in Java

Coding

I find the best visibility level in Java to be the default visibility i.e. package visibility, because it enables unit test classes to access all the methods, if the test is placed in the same package as the main class.

Also package visibility is shorter to write since you can omit the visibility declaration, so there is less boiler plate.

The second best visibility level is protected, since in some cases you can create your test classes as sub-classes of your main class. However, as stated before, package visibility works better in most cases, if you use packages properly.

Third, typically if you run Sonar and do code review and static analysis on large projects, I have found out that typically 80% of the methods are public, and 20% are private/protected. Thus, the main idea of using private or protected methods is to protect the data/properties from being accessed by bypassing the accessors. Most of the methods will be typically public anyways.

The most useless visibility level (but unfortunately commonly used) is private as it’s impossible to test (without using Reflection and modifying the visibility to something else). Also, private prohibits code re-use in subclasses, which is the main idea of using object oriented paradigm in the first place, and thus should be avoided. For the same reasons keyword final should be avoided in most cases.

Thus, I find your example to be the best practice how to define the visibility levels :). However, you are missing the package declaration and unit tests.

See https://stackoverflow.com/questions/16727414/the-use-of-visibility-modifiers-in-java/47213314#47213314

Published by:

PHZ Full Stack palkkaa 80 koodaajaa seuraavan vuoden aikana

Careers Company

PHZ.fi Full Stack Oy tarkoituksena on seuraavan vuoden aikana palkata yhteensä 80 ohjelmistokehittäjää palvelukseensa. Kestävän kehityksen mukaisen ohjelmistokehityksen kysyntä on jatkunut vahvana, koska myös asiakkaat ovat kokeneet jo olemassaolevien järjestelmien uudelleenkirjoittamisen miljoonien eurojen kustannuksella hukkainvestoinneiksi.

PHZ Full Stack tuo valtavia säästöjä asiakkailleen käyttämmällä testiautomaatiota nykyjärjestelmien elinkaarien jatkamisella vuosikymmenillä. Käytämme kuitenkin uusinta teknologiaa (esim. React, Vue.js, Clojure, Scala, AWS) uusien ominaisuuksien tekemiseen samalla säilyttäen vanhat toimivat osst järjestelmästä, joita ei tarvitse muuttaa.

PHZ Full Stack etsii ohjelmoijia kaikilla ohjelmointikielillä. Vaikka Java ja Node.js/javascript kehityksessä onkin suurin kysyntä, kaipaamme myös Python, C# (etenkin Unity3D), PHP, Go, C++ -koodaajia, sysadmineita, it-tuki -väkeä ja käyttöliittymäsuunnittelijoita.

Lisätietoa löytyy web-sivuiltamme www.phz.fi .

Published by:

PHZ Full Stack Oy osakeanti työntekijöille

Careers Company

PHZ Full Stack Oy keskittyy pimeän puolen käytäntöjen ja koodin manaamiseen pois asiakkaiden järjestelmistä, ja toiminta on rahoitettu ainoastaan tulovirralla eikä yhtiöllä ole muita ulkopuolisia omistajia kuin henkilökunta, Osuuspankin factoring -rahoituksen lisäksi. Tämän takia PHZ Full Stack pääoma on ns. puhdasta vaikka yhtiöllä on jo 60 työntekijää ja vuoden 2017 tämänhetkinen liikevaihtoennuste on 4.2M EUR. Yhtiön orgaaninen kasvuvauhti on kiihtynyt tänä vuonna jo yli 100% per vuosi, mikä tyypillisesti muilla yhtiöillä, kuten Reaktor, Vincit, Gofore, Siili ja Futurice on ainoastaan onnistunut yrityskaupoilla mutta ei orgaanisesti.

Henkilökunnan sitouttamiseksi PHZ Full Stack :llä on osakeanti, jonka avulla henkilökunta voi osallistua yhtiön menestystarinaan. Kiitos OP rahoituksen, pystymme nykyään palkkaamaan yhden uuden koodaajan aina kun saamme n. 5000 EUR omaa pääomaa. Käytännössä siis sijoittamalla 5000 EUR PHZ Full Stack Oy osakenantiin “voi palkata itselleen yhden koodaajan” tekemään töitä itselleen ja nostaa tästä osingot. Lisäksi verrattuna muihin alan yhtiöihin, jos ylipäänsä on mahdollisuutta sijoittaa kilpailevan yhtiön osakkeisiin jonka kasvuvauhti on 20% per vuosi, niin tonnin sijoitus muuttuu vain 1200e:ksi vuodessa, kun taas PHZ Full Stack:lla se on tuplaututunut joka vuosi viimeisen 5 vuoden ajan.

Puhdas pääomamme ja henkilöstöomistus petaa mahdollisuuksia tulevaisuudessa jättää option auki, jos orgaaninen kasvuvauhti alkaisi ehkä n. 150 hengen jälkeen tuottamaan vaikeuksia, kuitenkin erittäin edullisin ehdoin hankkia sijoittajia, jotka voivat rahoittaa yhden tai useamman samankokoisen tai pienemmän yhtiön ostamisen ja sen jälkeen listautumisen esim. pörssiin. Toinen vaihtoehto on turvata eläkepäivät nostamalla osinkoja tehdystä työstä seuraavat 20 vuotta. Verrattuna yleisesti saatavilla oleviin sijoituskohteisiin, PHZ Full Stack on sekä riskitön (toiminta on vakiintunutta ja markkinatilanne vakaa) että paljon paremmin tuottava kuin perinteiset sijoitus vaihtoehdot esim. rahastoissa ja pörssissä. Liity koodin valoisalle puolelle!

Published by:

PHZ:lle 0.5M EUR lisärahoitus

Careers

PHZ.fi sai tänään yhteistyössä OP-ryhmän kanssa 0.5M EUR lisärahoituksen kasvun vauhdittamiseen entisestään!

PHZ Full Stack hakee uusia Java-, frontend-, devops ja muita kehittäjiä periaatteessa kaikilla mahdollisilla ohjelmointikielillä C#:sta Pythoniin ja PHP:sta Clojureen. Liity koodin valoisalle puolelle ja luovu pimeän puolen houkutuksista lähettämällä CV:si rekry@phz.fi 🙂

 

Published by:

Viimeinen projekti pois Pimeältä Puolelta

Company

Saimme siirrettyä viimeisenkin projektin pois Koodin Pimeältä Puolelta, kun suurille asiakkaille toimitettu, edelliseltä toimittajalta PHZ Full Stack:lle siirretty IoT-projekti saatiin yksikkötestikattavuuden piiriin. Nyt k.o. projektin backend-puolella on yksikkötestikattavuus 45%. Laadun parantamista täytyy tosin jatkaa lisäämällä monitorointeja ja client-puolen testeillä.

PHZ Full Stack taistelee sitkeästi jokaisen koodaajan kokemaa koodin muuttamisen pelkoa vastaan. Kuten kaikki tietävät, yhdenkin merkin muuttaminen lähdekoodista tyypillisesti räjäyttää koko järjestelmän, joten muutoksen tekemisen pelko on aiheellinen. Asiakkaat ja projektipäälliköt eivät tunnetusti ole kovin tyytyväisiä kun perjantaina tuotantoon siirretään päivitykset, joiden jälkeen sivusto on alhaalla koko viikonlopun. Kukaan ei halua korjata ongelmia viikonloppuisin ja öisin.

Pelon voittamiseen tyypillinen ohjelmoijien käyttämä Pimeän Puolen käytäntö on kiertää pelottava koodin kohta sen sijaan että se refaktoroitaisiin asianmukaisesti hyvien ohjelmistotuotantokäytäntöjä (Clean Code) noudattaen. Kun koodaaja itse tai joku toinen ohjelmoija näkee seuraavan kerran kyseisen pelottavan kohdan, se on muuttunut entistä pelottavammaksi, ja Pimeän Puolen kierre on alkanut. Jatkuvan Pelon lisääntyminen johtaa spagettikoodiin, joka saa jokaisen projektiin osallistuvan Vihaamaan työtään. Lopulta tämä johtaa asiakkaan näkökulmasta pahimpaan mahdolliseen Kärsimykseen, eli versio 2.0:aan, eli aikaisempien investointien heittämiseen ikkunasta ulos ja järjestelmän kirjoittamiseen uudestaan nollasta. Tyypillisesti kuitenkin Pimeän Puolen käytännöt jatkuvat myös uudessa versiossa, joten mitään parannusta tällä tiellä ei ole saavutettavissa.

Koodin Pimeä Puoli on helppo, nopea ja etenkin juiorikoodaajia houkutteleva tie, mutta se ei ole voimakkaampi. PHZ:lla olemme toistuvasti pystyneet muuttamaan toisten IT-firmojen umpikujiin ajautuneet projektit Valoisalle puolelle testiautomaation avulla, säästäen kymmeniä miljoonia euroja uudelleenkirjoittamiseen kuluvalta hukalta. Kaikki uusi koodi on kuitenkin toteutettu uusimmalla teknologialla, kuten React Native, Redux, Clojure, Terraform yms.

Published by:

PHZ 08/2017 kasvuvauhti +235%

Company

PHZ Full Stack asiakkaat ovat pitäneet kestävän kehityksen ohjelmistoprojekteista siten että myyntimme kasvoi vuodentakaiseen nähden elokuussa +235%. Tämän vuoden kokonaisliikevaihtoennuste on 4.1M EUR. Tämä on miellyttävä uutinen PHZ Full Stack koodaajille, jotka ovat sijoittaneet henkilöstöantiin. Sijoitusten arvo kasvoi saman verran vuoden takaiseen verrattuna.

Published by: