Continuous Delivery Windows alustalla

Tuli taannoin paneuduttua syvemmälle Windows maailman varusteisiin ja lähtökohtiin koskien automatisoitua testausta, buildejä, test driven development käyttöä ja sensellaista. Suurena pettymyksenä tuli miten lastenkengissä siellä mennään, verrattuna esim. Java alustaan. Oli kaikenlaista härveliä joista suurin osa hyvin epävirallisia ja herkästi särkyviä jos visual studio versio vaihtui. Olen siitä asti ollut vähän haku päällä parempien varusteiden suhteen, jotka antaisivat keskittyä olennaiseen.

Ja niin törmäsin artikkeliin jossa tiimi tekee ihan perinteistä continuous deliveryä – windows alustalla.

http://java.dzone.com/articles/continuous-delivery-difference?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29

Muutama kohta jotka herättivät mielenkiintoa.. Ikuisuuskysymys on miten testaajat ja ylläpitäjät suhtautuvat ketterään tiimiin. Tässä on sulautettu ammattitestaajat osaksi tiimiä. Ja ylläpito hoituu omaa sydäntä lähellä olevalla DevOps tyylillä. Periaatteet kuten DevOps, TDD, ketteryys ovat arvostettuja ja hyviä, mutta vaativat toimiakseen myös välineet jotka hoitavat hommansa eivätkä tule tielle.

Eli tässä kombinaatiota: msbuild, TeamCity, NUnit, SpecFlow, PowerShell. Ja msi-pakettien sijaan zip-paketteja (Java maailmassahan ei juuri .exejä tuoteta muutenkaan).

Mainokset

Android sovellusten käyttäliittymädesign

Törmäsin kiintoisaan artikkeliin Android sovellusten tuunauksesta.

http://java.dzone.com/articles/android-apps-redesigned?utm_source=feedburner&utm_medium=feed&utm_campaign=Feed%3A+javalobby%2Ffrontpage+%28Javalobby+%2F+Java+Zone%29

Tuossa on aika hyviä kuvaruutukaappauksia ennen-jälkeen tilanteesta. Itsellä on ollut aina peukalo keskellä kämmentä mitä tulee kauniiseen käyttöliittymiin, värejäkin taidan tunnustaa löytyvän kolme – ja niistäkin kaksi on mustaa. Paras mihin itse pystyn on tähdätä yksinkertaisuuteen ja intuitiivisuuteen. Silti Android sovellukset laajaltikin kärsivät rumista, kömpelöistä ja monimutkaisista käyttöliittymistä.

Tuossa artikkelissa oli aika reippaastikin upeita käyttöliittymiä jotka hyödyntävät Jelly Beans/Ice Cream Sandwich androidien uusia piirteitä. Esim. ComingSoon ja Runtastic Altimeter

P.S. Sain muuten vanhan Galaxy Nexukseni henkiin kun siitä kärähti usb portti vesisateen vuoksi – kolmen taalan varaosalla. Nyt tuli kurkattua myös laitteen sisuksiin ihan emolevyä myöten 😉 Photo Sphere panoraamat ovat aika hupaisia.

Tuli sitten tuhlattua miljardi

Jep, tämä on jo vanha uutinen, mutta ehdin ajoittain lukemaan sähköposti-backlogiani ja yleensä muutaman viikon viiveellä kun aikaa löytyy, joten asia ehti käsittelyyn vasta nyt. Minä en siis tuhlannut miljardia, mutta jenkit tuhlasivat. Jälleen kerran on tehty massiivinen vanhanaikainen projekti jossa tehdään raskas esimäärittely, työmäärä-arvaus, asetetaan tiukka deadline ja budjetti, ja pistetään tuhlausjuna käyntiin. Puolessavälissä matkaa havaitaan että hups, ei tämä toimikaan. Business vaatimukset ovat muuttuneet, softa ei etene haluttuun suuntaan, softanteossa on ratkaisemattomia ongelmia. Hups, siinä meni miljardi veronmaksajien rahoja.

http://www.computerworld.com.au/article/442099/air_force_scraps_massive_erp_project_after_racking_up_1_billion_costs/

No, liiketoimintaahan tuokin on. Miljardi taalaa on ruokkinut monia suita matkan varrella mutta olisi toki mukavaa kun jotain tulisi tuutista uloskin vastineeksi, muuten kyse on vain verorahojen kierrätyksestä (joka sinällään on lähestulkoon ikiliikkuja, vain huonolla hyötysuhteella).

Tässäpä villi ajatus, mutta miten olisi, jos projektia olisikin vedetty etappeina ja välitavotteina? Priorisoitu se, että saadaan demonstroitavaa toiminnallisuutta toimitettua josta saadaan takaisin palautetta, ja saadaan tilaajakin ymmärtämään mitä tehdään ja meneekö se oikeaan suuntaan? Jos olisi menty peräti testit edellä varmentamaan että pienikin toimitettu osa toimii ja kestää kuormaa. No niin, eihän integraatio ja ERP hankintaprojekteja vain niin tehdä. Ei se ole realistista, ne on vain pakko vetää vanhan kaavan mukaan.

Vai onko? Pitäisiko kuitenkin tehdä jotain?`

http://www.cio.com/article/486284/10_Famous_ERP_Disasters_Dustups_and_Disappointments

http://www.quickstonesoftware.com/blog/2011/06/22/erp-and-agile-a-good-match-for-success

https://community.dynamics.com/product/nav/navnontechnical/b/erpsoftwareblog/archive/2012/11/08/why-is-agile-project-management-better-for-erp-projects.aspx

Olisiko kuitenkin arvokasta saada palautetta tilaajalta, linjata tekeminen siihen mitä halutaan ja etenkin tarvitaan? Olisiko mukavaa varmistaa että valitut teknologiat sopivat tehtäväänsä? Ei ole helppoa soveltaa ketteryyttä massiivisiin järjestelmämuutoksiin tai hankintoihin, joissa yhden asian muuttaminen vaikuttaa potentiaalisesti moneen muuhunkin asiaan, ja jossa testausympäristön aikaansaaminen voi tuntua valtavalta/mahdottomalta tehtävältä. Kuitenkin, perinteisetkään lähestymistavat eivät sanottavammin toimi. Olisiko aika ottaa inspiraatiota ketteryydestä?

Toki muistaen että ketteryyskin voi epäonnistua yhtälailla, ja siinä on omat riskinsä. If it was easy we wouldn’t be getting paid to do it 😉

Mietin hetken pistänkö tätä mietiskelyä liikkeelle, koska projektin läpivientimalli on niin herkkä aihe meille monelle, ja koska epäonnistumisen syyt ovat aina moniselitteiset, ei niitä yksistään projektimalli useinkaan selitä. Ja usein voi tuntua että suurikokoisia hankkeita on vaikea, suorastaan mahdoton mitenkään tehdä ketterämmin. Mutta kuitenkin, tuntuu käsittämättömältä että taas on uhrattu miljardin verran rahoja suorastaan kankkulan kaivoon, kun järki sanoo että jotain tulosta pitäisi saada aikaan kausittain. Ellei kuukauden välein, edes kerran kvartaalissa uudelleensuuntaus etappia. Tuossa jenkkihankkeessakin niitä oli muutama mutta selkeästi liian vähän tai vääränlaisia.

Kerran neljässä tai kahdeksassa viikossa tilaajalle tai asiakkaan edustajalle demonstroitavaa toimintaa parantavaa toiminnallisuutta. Liikaa vaadittu?

Scala of the day – RSS reader

Pidin juuri Scala kurssia ja taas tuli hurmaannuttua kielen yksinkertaisesta eleganssista tietyissä operaatioissa. Ensi vuonna jää nähtäväksi miten Java 8 Lambda Expressions vastaa tähän.

Mutta tässä yhden harjoitustehtävän hedelmä; koodi joka lukee Tieturin blogista kaikki otsikot ja listaa ne ruudulle:

  for ( line
       <- Source.fromURL("http://feeds.feedburner.com/tieturi").getLines
        if line contains("<title>") )
          println (line)

Ja tässä tämänhetkinen tulostus:

 <title>Tieturi</title>
  <title>Tieturi</title>
  <title>Työympäristö muuttuu yhä vaativammaksi, pysyykö työntekijä tahdissa mukana?</title>
  <title>Arvoista hyveisiin – päämääristä tuloksiin!</title>
  <title>Lean IT – onko palveluprosessissa läskiä?</title>
  <title>Maailmaa muuttamassa yhdessä Jurgen Appelon kanssa</title>
  <title>Kokonaisarkkitehtuuri on kaikkien asia – ei vain tietohallinnon!</title>
  <title>Tieturilaisten etäpäivästä ekopäivä</title>
  <title>HTML5 ja JavaScript – kahvipöydässä kuhisee</title>
  <title>Windows Phone 8 tähtää varteenotettavaksi yrityspuhelimeksi</title>
  <title>Pienennä hiirijalanjälkeäsi</title>
  <title>Tervetuloa IPv6!</title>

I likes it! 😉

Otetaanpas tuolta kommenttiosiosta vielä tiiviimpi ja scalamaisempi tapa tehdä sama:

Source.fromURL(“http://feeds.feedburner.com/tieturi”).getLines.filter(_.contains(“<title>”)).mkString(“\n”)

Lakkasiko JCONSOLE toimimasta Windows 8 koneessa? Siihen löytyy korjaus.

Asentelin taannoin uuden Windows 8 koneen, 64-bit versiona lisähankaluuksia kaivellakseni. Siirtymä siihen sujui yllättävänkin kivuttomasti, mm. kehitysvälineet, demot, vanhat koodit siirtyivät helposti. Yksi juttu tuli kuitenkin kursseja pitäessä esille: Javan JMX työkalu, JConsole ei listannut paikallisia prosesseja ollenkaan, ja näin sillä ei voinut monitoroida paikallisesti mitään.

Tänään oli hetkonen aikaa penkoa, ja syy löytyi. JConsole voi toki olla monestakin syystä pois toiminnasta, mm. jos koneessa on ristiin rastiin 32-bit ja 64-bit versioita Javasta, tai jos prosessia ei ole jostain syystä käynnistetty jmx agentti enabloituna (viimeisimmillä Java-versioilla pitäisi tapahtua automaattisesti). Mutta omassa tapauksessani syy oli seuraava:

JMX tekee käyttäjän TMP hakemistoon (Windowsissa %TMP%) hsperfdata_username nimisen kansion, tässä siis username millä ikinä oletkaan sisässä. Kokeilin avata tuon TMP kansion, itselläni se oli muotoa c:\users\username\AppData\Local\Temp – ja kyllähän se aukesi. Mutta sen sisään ei voinut luoda mitään tiedostoja, ja kansionkin luonti olisi vaatinut adminiksi ylentämisen. Tämä on siis se ongelma. Javan tulee päästä tähän kansioon kirjoittelemaan tiedostoja, tai prosessien seuranta ei toimi. Jos se ei toimi, esim. Javan jps työkalu ei näytä mitään käynnissä olevia prosesseja.

Korjaus

Eli mikä korjaukseksi? No itse poistin kansion, jonka jälkeen se osattiin luoda oikein. Toinen vaihtoehto olisi muuttaa oikeuksia kansiossa, siten että Java (sinä itse) saa kirjoitella sinne. Kolmas olisi muuttaa TMP ympäristömuuttuja osoittamaan paikkaan jossa on vapaammat oikeudet. Kuten tavallista, ongelma on oikeuksissa, eli tapoja on monia.

Mutta tässä siis yksinkertainen fiksi. JConsole ei näytä lokaaliprosesseja? Aja jps ja katso näyttääkö sekään prosesseja. Jos ei, poista kansio c:\users\username\AppData\Local\Temp\hsperfdata_username, ja tarkista että kun se luodaan uudestaan, sinne voi tunnuksillasi luoda uusia tiedostoja.

P.S. Windows 8 on hauska, muttei erityisen maatamullistava. Se on luontaista evoluutiota, toimisi varmasti paremmin kosketusnäytöllä. Mutta asiat toimivat siellä, se on jotakuinkin samalla tasolla kuin 7 (ellei muutamaa hang-at-boot-time pulmaa lasketa mukaan). Plussaa SoMe-integraatiokyvykkyydestä (joka on kieltämättä vähän pelottava… 😉