Kultainen koodi

.NET-osaajan ajatuksia paremmasta koodailusta

Archive for the category “ohjelmointi”

Keskitä vertikaalisesti kolmella koodirivillä

Työkaveri vihjasi törkeän mainion sivun, jossa kerrotaan miten UI-elementin voi keskittää vertikaalisesti kolmella koodirivillä. Taikasana on CSS.

.element {
  position: relative;
  top: 50%;
  transform: translateY(-50%);
}

Saman voi kirjoittaa myös mixininä.

/* Mixin */
@mixin vertical-align($position: relative) {
  position: $position;
  top: 50%;
  -webkit-transform: translateY(-50%);
  -ms-transform: translateY(-50%);
  transform: translateY(-50%);
}

.element p {
  @include vertical-align();
}

Elementti voi sijoittua pikseleiden väliin, jolloin elementin reunat voivat näyttää sumuisilta tai pehmeiltä. Määrittelemällä keskittämisen parin lisämääreen avulla ongelma ratkeaa.

.parent-element {
  -webkit-transform-style: preserve-3d;
  -moz-transform-style: preserve-3d;
  transform-style: preserve-3d;
}

.element {
  position: relative;
  top: 50%;
  transform: translateY(-50%);
}

Korjauksen voi tehdä myös perspectiven avulla (ratkaisua ehdotti alkuperäisessä postissa roydukkey):

.element {
  position: relative;
  top: 50%;
  transform: perspective(1px) translateY(-50%);
}

Nauti keskittämisestä!

Underscore js – JavaScriptin muistilista

Frontin tekeminen ja JavaScript? Underscorejs ratkaisee huolesi tarjoamalla pikaisia vastauksia tyypillisiin ongelmiin. Tavallisesti ongelmiin liittyvät vastaukset joutuu kaivamaan API:sta tai StackOverflowsta, mutta JavaScriptin puolella ratkaisukokoelma helpottaa elämää.

Näyttökuva 2017-03-26 kello 15.58.37

Underscoren kautta löytää hyviä esimerkkejä tyypillisiin funktiokutsuihin. Positiivisena puolena voi mainita funktiot. Jos osaat funktionaalista ohjelmointia, JavaScriptin opetteleminen tätä kautta käy helposti. Mikäli et vielä ymmärrä funktioita, niin esimerkkien avulla opit lisää.

Osaamistasi saat lisättyä codewarsin kautta, kuten kerroin aiemmin.

Riemullista JavaScriptailua!

Code Wars, mahdollisuus oppia

Tutustuin codewarsiin työkaverini suosituksesta yhtenä syksyisenä päivänä. Hän löysi koodiharjoitussivuston, jossa editoria ja testejä voi ajaa selaimen kautta. Toisin kuin exersim.io tai vastaavissa palveluissa, codewarsilla harjoitteleminen onnistuu ilman kehitysympäristöä.

Harjoitusten tekeminen codewarsissa käy helposti. Harjoitusta kutsutaan nimellä kata.

codewars_kata

Kata eli harjoitus codewars.com:ssa.

 

Harjoituksen tehtävänanto selviää ruudun vasemmalta puolelta. Koodi kirjoitetaan oikeassa yläkulmassa näkyvään koodinäkymään. Kirjoitettu koodi ajetaan ”paikallisia” testejä vastaan Run Examples -painikkeella. Ne löytyvät Example Tests -otsikon alta. Näitä testejä voi myös muokata omien mieltymysten mukaan.

Lopullinen testi ratkaisulle tehdään ajamalla koodi Attempt-painikkeella. Ratkaisun toimivuus testataan yksikkötesteillä, joita ei näytetä käyttäjälle. Vain testien tulos näytetään. Toisinaan testien nimestä voi päätellä mikä testi epäonnistui. Järjestelmä sallii myös satunnaistettujen testien ajamisen, jolloin tehtävän luojan ei tarvitse kirjoittaa kaikkia testitapauksia käsin.

Ratkaistuasi tehtävän, saat vaikeusasteen mukaan tietyn määrän pisteitä. Helpoimmat testit saa ratkaistua muutamassa minuutissa, vaikeampien ratkaiseminen kestää tunteja.

Ratkaistuasi tehtävän, näet muiden vastaukset ja näistä oppii. Vastauksista voi merkata omasta mielestä parhaan ja nokkelan vastauksen. Vastauksista näkee kuinka paljon ohjelmoijien ongelmanratkaisukyky ja API-tuntemus vaihtelee.

codewars_stats

Stats-sivu kertoo mistä olet saanut pisteitä.

 

Olen kerännyt suurimman osan pisteistäni tekemällä harjoituksia. Pisteiden hankkimiseen käytetyt kielet näkyvät oikeasta laidasta ja prosenttiosuus kertoo kuinka paljon pisteitä on kerätty ennen seuraavaa tasoa.

Pisteet päivittyvät muutaman tunnin välein, kun palvelin ajaa ajastetusti pisteiden päivistyskriptit. Itsekin ihmettelin aluksi miksi pisteet päivittyvät viiveellä.

Jos teet vain harjoituksia, pisteillä ei ole merkitystä. Halutessasi voit kirjoittaa harjoituksia muiden ratkaistavaksi tai kääntää niitä kieleltä toiselle. Tällöin korkeampi pistemäärä sallii kevyemmän validointiprosessin ennen kuin kirjoittamasi harjoitus julkaistaan.

Yhteisöllisyyttä yritetään lisätä klaanien avulla. Käyttäjän tiedoissa voi antaa itselleen klaanin. Se on vain merkkijono. Kaikki jotka kirjoittavat saman merkkijonon, tulevat samaan klaaniin.

codewars_klaanit

Klaanit

 

Klaanijärjestelmä ei ehkä ole täydellinen, koska vaihdettuani klaanin, näen edelleen kaikki vanhan klaanini jäsenet.

Codewars on ehdottomasti paras palvelu ohjelmointiharjoitusten tekemiseen. Sen avulla voi ylläpitää kielen osaamista tai opetella uutta kieltä. Toki harjoitusten avulla oppii erityisesti kielen käyttöä, ei niihin liittyvien frameworkkien käyttöä.

Suosittelen kokeilemaan codewarsia, sen avulla voit löytää palon vanhaan rakkaaseen kieleen tai kehittää osaamistasi nykyisen kielen kanssa.

 

 

 

Visual Studio Live Unit Testing

Visual Studio 2017 RC julkisti seuraavan askeleen yksikkötestauksessa, live-tilan. Käytännössä VS ajaa jatkuvasti yksikkötestejä kirjoitettua koodia vastaan ja merkkaa onko koodiriviin osuva testi läpäisty, ei mene läpi tai puuttuuko se.

Silmäilin asiasta kertovan blogin läpi ja katsoin siihen liittyvän videon. Oli mielenkiintoista seurata intialaista kerrontaa. Se selvensi kuinka nopeasti testi heijastui koodiin. Pohdiskelin hetken, vaatiiko tekniikka paljon tehoa tietokoneelta?

Ominaisuus vaatii Enterprise-lisenssin, mikä on sääli. Se maksaa huiman summan, verrattuna tavallisesti käyttämääni pro-versioon.

Mieleeni juolahti vanha kuvio. Microsoft kopioi JetBrainsin ideoita. Tapahtuiko tämä kehitysaskel samoin?

Kyllä!

JetBrainsin dotCover tarjosi continuous testing -konseptin vuonna 2015. Se poikkeaa hieman VS:n natiivista. Se vain ajaa testejä jatkuvasti ja näyttää, menevätkö ne läpi. Tosin dotCoverin muut ominaisuudet näyttävät onko koodille yksikkötestejä.

Vanhaa kauraa siis. Kehittäjälle siis löytyy vaihtoehtoja reaaliaikaiseen testaukseen.

Pari vuotta sitten testasin dotCoveria ja tuolloin kaikilla mausteilla valittuna se hieman hidasti Visual Studiota. Olisi jännä testata onko dotCover ydintä optimoitu tuon jälkeen?

Pitää kokeilla!

Emacs työvälineenä

Kirjoitin clojurea syksyn emacsilla ja se sujui hyvin. Suurin osa ajastani menee siis koodin rakenteen ja toiminnan pohtimiseen. Saan näppärästi avattua haluamani tiedostot suoraan editoriin ja se tukee kohtuullisesti kirjoittamista.

Emacsin lisäksi pidän melko usein avoinna clojuren cheat sheet -sivua tai clojurescriptin vastaavaa.

Käyttö

Tavallisesti jaan ruudun kahteen tai kolmeen osaan. Yhdellä puolella näkyy koodi ja toisella yksikkötestit. Mikäli teen rajapintaan koodia, niin yhdellä puolella on tietenkin esim. palvelimen rajapinnat näkyvissä ja toisella puolella asiakas/web-sovelluksen puoli, joka kutsuu rajapintoja. Usein testaan koodin toimintaa myös REPL-ikkunassa.

Ikkunoiden ja tiedostojen välillä liikkuminen tapahtuu todella sujuvasti. Näppäinoikopolut purevat erittäin hyvin. Koodia saa siistittyä, leikattua ja liimattua vaivattomasti. Siihen emacs on tehty, kirjoittamiseen. Sen lisäksi yksikkötestit saa pyörimään jatkuvasti tai niitä voi pyöritellä komennoilla. Sekin toimii fantastisesti. Yksikkötestien ajaminen on paljon nopeampaa ja kätevämpää kuin Visual Studiolla, jota olen käyttänyt noin 10 vuotta.

Clojurea kirjoittaessani testaan usein koodia REPL-ikkunassa. Koodin namespacen saa ladattua näppärästi käyttöön ja voin ajaa haluamiani funktioita ”livenä”. Se helpottaa debuggausta, yksikkötestien suunnittelua ja funktion toiminnan testaamista.

Nähdäkseni emacsin valtteja ovat nopeus, koko ruudun tehokas käyttäminen ja laajennettavuus.

IDEn edut

IDE voittaa emacsin helposti koodin laadun tarkkailussa. Sekä Visual Studiosta, Eclipsestä ja InteeliJ:stä löytyy paljon lisäominaisuuksia, jotka helpottavat koodaamista.

Käyttömätön koodi nostetaan esiin paljon helpommin. IDEt yleensä ehdottavat (tai ainakin niihin lisätyt plugarit) kuinka koodia voisi parantaa. Koodausta helpottavat täydennystoiminnot ovat älykkäitä, toisin kuin emacsissa. Emacs tunnistaa aiemmin käytetyt funktiot, muttei osaa ehdottaa kirjastosta löytyviä vaihtoehtoja.

Sekä emacs että IDEt osaavat yhtä hyvin etsiä ja korvata tekstiä. Funktioiden tai metodien uudelleen nimeäminen sen sijaan onnistuu kunnolla vain IDEn kautta. Nimien tai nimiavaruuksien refaktorointi on ehdottomasti IDE-juttu.

Ohjelmakoodin rakenteen näkee IDEn olio tai sovellusrakenteesta, jos rakenne on yksinkertainen. Esimerkiksi MVVM tai simppeli Reactin dispatcher, subscriber -rakenne näkyy paremmin IDEstä kuin emacsista. Tosin kumpikaan ei pelasta jos kyseeseen tulee kompleksinen rakenne, kuten Prism tai laajalle levinnyt legacy-järjestelmä.

Kipeimmin emacsissa minua pistivät puuttuvat uudelleennimeämisominaisuudet, hyvän bookmark-järjestelmän puute ja heikko tuki koodin laadun tarkkailuun. Olisin kaivannut vihjeitä miten asiat koodataan. Projektissani asia korjaantui mob-koodauksessa ja pull request -arvioinneissa.

IDEssä käytettävien useiden näppäinten oikopolkujen sijaan emacsissa kirjoitetaan usea näppäinoikopolku peräkkäin. Esimerkiksi yksikkötestit voi ajaa komennolla (ctrl+c, ctrl+t, ctrl+n) IDEssä suositaan usean näppäimen samanaikaista painamista. IDEssä komennon voi siis käynnistää ”heti”.

Huomasin myös joidenkin emacsin lisäosien käytön vaativan järjettömiä näppäinoikopolkuja eli komennot menivät neljän tai useamman komennon syvyyteen. Se ei tuntunut käytettävältä. Niin pitkiä komentosarjoja ei edes pysty helposti muistamaan.

Lopuksi

Tuntui mukavalta kokeilla emacsia, mutta projektin laajentuessa jäin kaipaamaan useamman tiedoston refaktorointiin liittyviä ominaisuuksia. Halusin myös käyttää lyhyempiä näppäinoikopolkuja, mutta olenko valmis uhraamaan nopeuden käyttömukavuuden alttarille?

Clojuren opiskeluun vaihtoehtoja

Clojuren ja ClojureScriptin opiskeluun löytyy useita työkaluja, jotka toimivat hyvin. Alkuun voi ottaa maistiaiset kokeilemalla jotain selaimessa pyörivää REPLiä. Sen avulla voi suorittaa suoraan clojurekoodia.

Koodaajan iloksi clojurelle löytyy useita eri kehitysympäristöjä:

Counterclockwise on ilmainen Eclipsen päälle tehty ympäristö.

JetBrains kehitti IntelliJ:n päälle kokonaan oman tuotteen clojurelle. Sen nimi on Cursive. Se näkyi ClojuTRE:n demoissa suosituimpana työkaluna.

Emacsiin saa clojuren pyörimään mainiosti. Käytän sitä itse töissä, koska kokeneemmat kehittäjät osaavat näyttää sillä miten hommat tehdään.

Visual Studioon löytyy vsClojure-lisäosa, jolla pääsee vauhtiin.

Jos haluat opiskella clojurea, voit joko lukea siitä kirjasta, suosittelen Clojure for the brave and true -opusta. Se on kirjoitettu kieli poskessa ja se sisältää hyviä linkkejä lisäopiskelua varten. Aloitin itse sitä kautta.2016-07-19-11-57-22

Ehkä matalin kynnys tulee kuitenkin pyöräyttämällä läpi yksinkertainen hands-on harjoite. Sellainen löytyy try clojuresta. Sen päristely kestää vain 5 minuuttia. Suosittelen lämpimästi. Siinä kerrotaan suoraan mitä pitää kirjoittaa, joten se onnistuu helposti. Toisaalta siinä ei sukelleta kovinkaan syvälle clojuren mahdollisuuksiin.

Omaa osaamista voi vahvistaa ratkomalla koodisokeriongelmia 4Clojuren sivuilla. Kannattaa luoda käyttäjätunnus, niin edistyminen tallentuu. Ratkaisujen löytäminen vaatii rajapintojen tuntemista, tuskastuttavaa ja lopulta palkitsevaa. Apuna voi tietenkin käyttää Cheatsheet-sivua tai vaikka lueskella aiemmin mainittua kirjaa. Hyviä esimerkkejä löytyy myös clojuredocsista, siellä on rajapinnan lisäksi näppäriä esimerkkejä. Stackoverflowsta ei vielä löydy vastauksia, joten kannattaa panetua muuhun materiaaliin.

Exercism.io & clojure on suosikkini itseopiskelua varten. Se tosin vaatii oman koneen ja ympäristön, jossa ratkaista tehtäviä. Exercism antaa kuitenkin vapaat kädet ongelmien ratkaisuun. Ongelman voi ratkaista kauniilla koodilla tai kirjoittamalla apufunktioita ja karmean pitkän hässäkän, kuten itse teen ensimmäisellä iteraatiolla. Löydettyäni ratkaisun yritän jalostaa mörkömöhkäleestäni kaunista koodia.

Valitse oma polkusi clojureen! Opiskele niin paljon kuin on tarpeen tai syöksy kielen syvyyksiin oivaltamaan. Nauti.

ClojuTRE 2016 aloittelijan silmin

Kävin kuuntelemassa upeita luentoja ClojuTRE:ssa, siellä kerrottiin uusimmista tuulista ja erilaisista kielen sovelluksista.

Huomasin hypänneeni clojuren kelkkaan juuri oikeaan aikaan, koska kielen debuggaukseen, ajonopeuteen ym. liittyvät ongelmat on selätetty aivan hiljattain.

Palataan alkuun.

ClojuTRE tarjosi tietoa kolmella rintamalla: clojuren yhteys muihin kieliin ja clojuren historia, erilaisia sovelluksia miten clojurea voi käyttää oikeissa projekteissa ja kielen kehittymiseen liittyvät projektit tai laajennukset.

Tietämykseni laajeni kerralla aivan uusiin sfääreihin seurattuani esityksiä.

Klipse tarjoaa REPL:n eli reaaliaikaisen ohjelmointiympäristön mille tahansa web-sivulle, joka voi pyörittää komponentteja tai JavaScriptiä. Sen avulla uuden kielen oppiminen muuttuu paljon helpommaksi, kun opiskelijan ei tarvitse erikseen pystyttää kehitysympäristöä. Ideoita voi kokeilla heti.

Native mobile apps ja clojure of things järisyttivät maailmaani. Siis näin voi tehdä alustariippumattomia sovelluksia clojurella tai ohjata IoT-laitetta (RaspberryPi). Aivan fantastista kamaa. Juuri tämän kaltaiset esimerkit elävästä elämästä saavat uskomaan tämän kielen mahdollisuuksiin. Huimaa.

The Story of Owl Lisp avasi lispien maailmaa tavalla, jota en uskonut mahdolliseksi. Kaiken lisäksi Aki Helin sai yleisön nauramaan upealla esityksellään. Kaiken takana on yksinkertainen lambda-matematiikka eli funktiot. Yksinkertaisuudessaan ja yksinkertaisuudesta kasvaessaan monimutkaisuudessaan kaunista.

ClojureScriptin viisi viimeisintä vuotta ja viisi seuraavaa puuhkäisivät pöydän puhtaaksi. David Nolen tiivisti erinomaisesti, yhteistö sai tämän kaiken aikaan. Liity yhteisöön ja anna vähän. Nappaa helppoja juttuja, joilla parannetaan clojure (scriptiä). Oikein voimaannuttava puhe mieheltä, joka on auttanut clojurescriptin syntymisessä. Hän rakastaa LISPiä.

Päähäni jäi paljon innostusta. Sain suuren määrän tietoa, josta osaa pystyn käyttämään edukseni paremmin kuin toista. Löysin paikkoja, joista voi aloittaa, kun tahtoo saada asioita tapahtumaan. Siemeniä, alkuja minulle. Muille projekteja, jotka luovat uskoa clojureen.

Clojureen ihastuminen

Astuin clojure-maailmaan, tehtyäni töitä yli kymmenen vuolla .NET-työkaluilla. Suurimman osan tuosta ajasta kirjoitin C#:lla ja hieman yli vuoden Visual Basicilla. Clojure on LISP-perheeseen kuuluva kieli. Ensin se nyrjäyttää aivot ja sitten sillä koodaaminen tuntuu mahtavalta.2016-07-13-09-53-17

Uusimmassa projektissa kieli- ja tekniikkavalintoina on ClojureScript frontissa muutamien lisäpalikoiden kera, serverillä Clojure ja tietokantana CouchDB. Olen harjoitellut ja koodannut clojurea vasta kuukauden, joten kielen vaihtoon liittyy paljon uutuuden viehätystä.

Miltä clojure näyttää?

(map inc [1 2 3])
;; => [2 3 4]

Oheessa koodi, jossa lisätään inc-funktiolla annetun vektorin alkioiden arvoja yhdellä. Map-funktio kutsuu inc funktiota jokaiselle alkiolle erikseen, jolloin funktion tulos on [2 3 4].

Käytin tovin aikaa todetakseni, ettei tässä ilmaisessa wordpress.com:ssa voi asentaa plugineja, joilla voisi tyylikkäästi näyttää miten clojure toimii. Klipse:n voisi upottaa blogiin, jos saisi ajaa JavaScriptiä tai asentaa plugarin.

Käy klipsen sivuilla testaamassa clojurea, niin saat maistiaisen kielestä.

BuildVision lisäosa

Helppous, selkeys ja käytettävyys. Näiden takia pidän BuildVisionista. Lyhyt esimerkki alkuun.

12>Build succeeded.
12>
12>Time Elapsed 00:00:01.41
========== Build: 12 succeeded, 0 failed, 122 up-to-date, 0 skipped ==========

Verratessani BuildVisionin näkymää vilisevään output-ikkunaan, näen helpommin missä mennään ja pystyn peruuttamaan käännöksen napin painalluksella. No joo (Ctrl + Pause/Break) pysäyttää normaalin buildin, mutta output-ikkunasta ei näe yhtä selvästi milloin yhden solutionin projektin kääntäminen epäonnistuu. BuildVision näyttää myös solutionin käännösajan ja statusbarissa juoksevan ajan, kun build on käynnissä.

BuildVision_build_time

BuildVision selkeyttää solutionin kääntämistä, kun solution sisältää useita projekteja. Sen kautta näkee selvästi mitä projekteja ei tarvitse kääntää, ”UpToDate”, mitkä projektit käännetään ”Building / BuildDone” ja mitkä projektit eivät käänny. Viimeisimmät merkataan punaisella ruksilla.

Selkeä käännösaika sai sukat pyörimään jaloissani. Sen näkee ensimmäisen onnistuneen käännöksen jälkeen, isolla. Kun build kestää pitkään ehdin hakea vaikka kupillisen kuumaa. Pienen solutionin kanssa askarrellessa ymmärtää pitää puolen minuutin tauon.

Suosittelen kokeilemaan, ei maksa mitään.

Koodaajan erilaiset hatut, refaktorointi

Martin Fowler piti hienon puheen ohjelmoijan erilaisista hatuista. Se upposi ajatusmaailmaani saman tien.

Hänen mukaansa koodia tehtäessä ohjelmoija laittaa päähänsä tietynlaisen hatun käydessään työtehtävään. Tyypilliset hatut ovat

  • koodaus, uusien toimintojen lisäämiseen ja
  • refaktorointi, laadun parantamiseen.

Toki näiden lisäksi löytyy optimoijan hattu, protoilu tai POC-hattu.

iPhone 166Hyvä koodaaja siistii koodinsa aina ominaisuuden luomisen jälkeen, joten miksi refaktoroinnille pitää käyttää omaa hattua? Koska koodi haisee.

Haiseva koodi on (jonkun toisen tekemä) vanha tuotos. Se ei toimi niin tehokkaasti kuin voisi toimia ja se kaipaa pientä tuunausta. Tästä karmeudesta pääsee eroon vain refaktoroimalla. Ohjelmoimista oppiessa huomaa myös oman vanhan koodinsa kaipaavan päivitystä. Koodin hajun lisääntymisen yksi keskeinen syy on sovelluksen kasvaminen ja toimintojen lisääntyminen.

Alkuperäiseen tarkoitukseen käytetty yksinkertainen arkkitehtuuri ei enää toimi, vaan uusien ominaisuuksien lisääminen pakottaa purkkakoodin lisäämiseen, ellei refaktoroi rakennetta uudelleen. Yksinkertaisimmillaan metodikutsu sisältää liian monta parametria ja tarvitaan parametriolio.

Jos koodin hajuun ei kiinnitä huomiota, koodin laatu rapistuu ja koodin rakenne katoaa. Se hukkuu kaikkiin pieniin muutoksiin ja jippoihin. Kompleksisesta koodista seuraa koodaamisen tuska, koska sitä on vaikeampi ymmärtää ja uusien ominaisuuksien liittäminen käy hankalaksi. Aikaa menee hukkaan. Sen sijaan hyvin suunnitellussa ja siistinä pidetyssä koodissa työskentely on vaivatonta ja nopeaa.

Johtoportaalle refaktorointia on turha perustella laadulla, kauniilla koodilla, asinatuntijuudella tai oikealla tavalla tehdä. Perustele rahalla. Sotkuiseen koodiin koodaaminen vie enemmän aikaa kuin pitäisi.

Huomaa, että refaktoroinnin voi joskus jättää tekemättä. Jos haiseva koodi sijaitsee jossain harvoin käytetyssä syrjäisessä osassa, siihen ei tarvitse koskea. Jos haisevaan koodiin törmää päivittäin, se pitää siivota pois. Muutoin joudut tekemään ylimääräistä työtä ja laskutat ylimääräistä asiakkailta. Se on varastamista.

Refaktorointitalkoot ja issuet projektin backlogilla kannattaa unohtaa. Ne putoavat priorisoinnissa aina alaspäin. Sen sijaan korjaa ihan vähän koodia tänään. Paranna laatua taas huomenna, kun törmään heikkolaatuiseen koodiin. Viikkojen ja kuukausien kuluessa koodin laatu paranee. Pian pääset koodaamaan mukavan koodipohjan päälle.

Post Navigation