Koodihommia

Eräässä projektissa pääasiallinen asiakkaalle näkyvä käyttöliittymä on tehty Liferayn päälle. Käyttöliittymän lisäksi pidämme käyttäjät ja näiden oikeudet liferayn hallinnassa. Asiakkaille on olemassa omat Liferay instanssinsa eri teemoituksineen. Testiympäristöissä on tuotannon tilaa vastaavia referenssiinstansseja. Uudet sivut ja näiden oikeudet siirretään LAR tiedostoissa tuotantoon. Olemme myös käyttäneet Liferaytä piilottamaan tai näyttämään jotain ominaisuuksia vain tietyille käyttäjille. Ongelmana on että emme ole testanneet ikinä automaattisesti LAR-tiedostoja. Tästä on seurannut useita huolimattomuusvirheitä. Haluamme että esimerkiksi vain tietyt käyttäjät näkevät jonkun portletin, mutta se onkin näkynyt kaikille Olemme nykyään varautuneet deploymentteihin sekä testaamalla itse LAR-tiedostot, että ajamalla muutamia SQL-skriptejä tuotannon tietokantaa vasten. LAR-tiedostot ovat pakattuja XML-tiedostoja, joissa on mm. sivujen urlit ja hierarkiat pääsyoikeuksineen. Kun nämä l

Ohjelmisto on jaettu useaan OSGi bundleen. Bundlet ovat karkeasti jaettavissa viiteen kategoriaan. Näkymätyyppiset bundlet ovat itsenäisiä osia käyttöliittymää. Taustajärjestelmäbundlet toimivat fasadina taustajärjestelmille, joihin otetaan yhteyttä esimerkiksi  SOAPilla. Jaetut bundlet tarjoavat yhteistä koodia jota käytetään useissa eri bundleissa. Core-bundlet sisältävät perustoiminnallisuutta kuten Vaadin UI:n, aktorisysteemin ja navigoinnin. Domain-bundlet sisältävät sen bisneslogiikan jota käyttöliittymä tarvitsee. Presenterit lähettävät viestejä muille OSGi bundleille, jotka ottavat yhteyttä mm. SOAPilla taustajärjestelmiin. Tämä fasadina toimiva middle-layer voi pyöriä sekä samassa että eri OSGi containerissa. Ajatuksena on että näkymät lähettävät pelkästään Akka-viestejä tietämättä, mikä bundle hoitaa nämä eteenpäin. SOAP taustapalveluihin otetaan yhteyttä Akka-Camelilla. Käytössä on pieni klusteri Producereita ja Consumereita. Akka-viestit saapuvat klusteriin, josta

Sain tehtäväksi tehdä käyttöliittymän tabletille. Valitsimme toteutukseksi AngularJS kirjaston. Se on saanut ristiriitaisen arvion, ainakin mikäli lukee keskustelupalstoja.[1] Tilastojen mukaan sen käyttö on kuitenkin lisääntynyt tasaisesti. [2] Vaikka olin tehnyt pienempiä kokeiluja Angularilla jo ennenkin, ensimmäisenä lähdin etsimään hyvää guideline miten Angularilla tehdään hyvää koodia. Yksi suositumpia guidelineja on John Papan, josta löytyy jopa oma kurssi Pluralsightista. Päätin ottaa sen käyttöön. Huomioitavaa siinä on mm. controllerAs tyylin käyttäminen sekä kaiken ylimääräisen (mm. taustapalvelukutsujen) siirtäminen pois controllereista. Käytin myös jonkin verran directivejä. Directiveillä voi tehdä DOM puusta helpommin luettavaa semanttisessa mielessä. Huomioita piti kiinnittää siihen, että nämä toimivat kontekstista riippumatta jos käyttää useita templateja. AngularJS sanotaan myös verrattain hitaaksi johtuen clienttipuolen HTML templatejen parsimisesta ja digest s

Viestin välitykseen perustuva design patternia voi hyödyntää mutkikkaissa ohjelmistoissa erottamaan tiukkoja riippuvuuksia ohjelman eri osien välillä. Oma kokemukseni tästä on Vaadin käyttöliittymä, jonka bisneslogiikast vastaa Akka. Akka hoitaa yhteydet taustajärjestelmän palveluihin, navigoinnin sekä käyttäjäsession. Käyttöliittymässä noudatetaan MVP patternia. Presenterit ovat Akka-aktoreita. Presenterit voivat lähettää viestejä taustajärjestelmäyhteyksiä hoitaville aktoreille, toisille presentereille sekä luonnollisesti vastaanottaa notifikaatioita jotka voivat olla broadcastattuja. Presenterit siis ajetaan eri säikeessä missä "käyttöliittymäsäie" pyörii. Koodaajan ei tarvitse välittää rinnakkaisuudesta muutoin kuin interaktoissa käyttöliittymän kanssa. Presenteriaktorit ovat nimettyjä tietyn säännön mukaan, jotta nämä voivat lähettää helposti viestejä muille presentereille. Tämä mahdollistaa verrattain helpon kommunikoinnin eri käyttöliittymän käyttäjien välillä. Mi

Hienoa uutta opittua JavaScriptin perusteet, erityisesti AngularJS. Mukana kahdessa pienessä projektissa, joissa käytettiin AngularJS:ää. Kimono API, jopa niin paljon että pidin esityksen työpaikallani! OSGI, oppiminen jatkuu. Toimii hienosti Vaadinin ja Pushin (http) kanssa. SCSS. SCSS:llä on ytimekkäämpi ja monipuolisempi syntaksi. Laaja projekti voidaan jakaa semanttisesti useampaan eri tiedostoon. Clean code, 5 riviä per metodi. Vältä kommentteja! Metodin nimen pitää olla sellainen että kommentteja ei tarvita.  Design patternien tärkeys, kun koodin määrä kasvaa. Tärkeää että kaikki koodaajat hyväksyvät valitut patternit ja käyttävät niitä yhdenmukaisesti. Myös uudet kehittäjät täytyy perehdyttää miten patternia käytetään. Töiden tekeminen käyttöliittymäsuunnitelijan kanssa. Käyttöliittymäsuunnittelussakin pätee sääntö "älä keksi pyörää uudelleen". Käyttöliittymässä pitää olla tuttuja elementtejä. Tämä ei kuitenkaan tarkoita, että kaikki pitää uudelleen kie