Projekti Euler tarjoaa sarjan laskennallisia ja matemaattisia ongelmia tietokoneella ratkaistavaksi ja mahdollisuuden tavoitella erilaisia saavutuksia, kisailla kavereiden kanssa ja keskustella ratkaisuista muiden käyttäjien kanssa. Projekti alkoi Colin Hughesin toimesta vuonna 2001 mathschallenge.net -sivuston alaosiona ja on nimetty uraauurtavan sveitsiläisen matemaatikon ja fyysikon, Leonhard Eulerin, mukaan. Käytännössä projekti pyörii käyttäjien toimesta, jotka ehdottavat uusia pähkinöitä, ja lahjakkaiden matemaatikkojen ja ohjelmoijien tiimi muuntaa ne ratkaistaviksi ongelmiksi. Tällä hetkellä pähkinöitä on 367 ja uusia julkaistaan epäsäännöllisin välein.

Ratkaisemani ongelmat ja niiden koodit löytyvät “theeuler” -repostani GitHubista. Ratkaisuista huomaa, että niissä ei ole tähdätty elegantteihin ratkaisuihin. Ehkä sitten myöhemmin. Ensimmäiset kymmenen tehtävää, jotka tähän mennessä olen suorittanut, ovat kohtuullisen helppoja ja sisältävät peruskäsitteitä alkuluvujen generoinnista suurimpaan yhteiseen jakajaan. Pythonilla pähkinät ratkesivat suhteellisen helposti, samoin Javalla. Seuraavaksi ehkä Scala ja JavaScript.

Pelkällä raa’alla voimalla ei ongelmia luultavasti enää alkupään jälkeen ratkaista, vaan vastauksen saaminen vapaasti asetetussa minuutin aikarajassa vaatii sekä tietoa että taitoa kehittää sopiva algoritmi. Koska ongelmat ovat matemaattisia, auttaa niiden ratkaisemiseen muun muassa matemaattisten teorioiden kuten lukuteorian tunteminen. Tuskin kuitenkaan pyyhin pölyjä hyllyssä olevasta Calculuksesta tai Betasta, sillä hakukone tarjonnee vastauksia teorioiden osalta.

Internetissä on tarjolla myös muita vastaavia projekteja, jotka tarjoavat ohjelmoijille keinon virkistää ja kehittää taitojaan. Code Academy opettaa ohjelmoimaan (JavaScriptiä) kädestä pitäen, CodeKata tarjoaa 21 harjoitusta paremmaksi ohjelmoijaksi tulemiseen koodauksen ja ajattelun kautta, Rubyn opetteluun voi seurata Ruby Koans -polkua, logiikkaongelmia voi ratkoa 99 Prolog ongelman kautta ja Python Challenge tarjoaa kuvavihjeellisiä pähkinöitä. Kaikilla sivustoilla on hieman oma lähestymisensä ohjelmoijien aktivoimiseen.

Indigon suurimpia uudistuksia Java-kehittäjän näkökulmasta ovat muun muassa:

• Egit 1.0: Git-versionhallinnan integroiminen
• WindowBuilder: Graafisten SWT ja Swing -käyttöliittymien rakentamiseen
• Jubula: Java ja HTML -sovellusten funktionaalisen GUI -testausten automatisoimiseen
• m2eclipse: Mavenin integroiminen Eclipsen työtilaan
• Mylyn 3.6 tukee nyt Hudsonin buildien monitorointia
• Eclipse Marketplace tukee laajennusten lisäämistä vetämällä ja pudottamalla
• Tuki WebKitille kaikilla alustoilla
• Cocoa parannuksia OS X:llä

Tarkempaa listausta uudistuksista voi yrittää etsiä Indigon suunnitelma -wikistä.

Suunnitelluista uudistuksista Java 7 -tukea jouduttiin siirtämään, koska siihen liittyvät speksit olivat saatavilla liian myöhään ja virallinen julkistaminen (28.7.2011) on Indigon julkaisun jälkeen. Vastahan tässä Enterprise-sovellusten osalta (lue Oraclen palikat) päästiin Java 6:sta käyttämään, joten eipä sillä niin tarvetta.

Uusista ominaisuuksista WindowBuilder kuulostaa kätevältä, vaikka onneksi ei GUI-palikoita tarvitse rakennella. Nyt käsin tunkkaamisen asemesta elementtejä voi lähestyä kuten Netbeansin työkalujen kanssa on jo kauan voinut: valitse komponentti ja tiputa paikoilleen. WindowBuilderissa on kaksisuuntainen koodigenerointi, joka mahdollistaa yhteentoimivuuden käsinmuokatun koodin kanssa, joten ehkä se ei tuota yhtä sotkuista koodia kuin koodigenerointi yleensä.

Kokonaisuutena Eclipse 3.7 Indigo on jälleen askel parempaan kehitysympäristöön, vaikka mitään suuria, maata järisyttäviä, uudistuksia ei nähty, kuten ei viime vuonna Helioksenkaan osalta (lukuun ottamatta Marketplacea) tai pari vuotta sitten Ganymedessä, enkä edes muista mitä uudistuksia Galileo vuosi sitten toi. Saa nähdä vieläkö Eclipse hajonnee ikävän herkästi ja temppuilee. Rohkeat voivat koittaa vanhan Eclipse asennuksen importoimista Indigoon, joka yrittää asentaa vanhassa olleet laajennukset uuteen.

• Lisäosien asennus Eclipse Marketplacesta: Tarvittavien lisäosien asennus on nyt helpompaa Eclipsen sisältä löytyvän Marketplacen kautta. Hakusana ja pari kliksautusta, entisen update siten syöttelyn asemasta. Harmillisesti kaikki laajennukset eivät uutta tapaa vielä tue.
• Web Tools Project sai tuen Java EE 6 -teknologioille kuten Servlet 3.0, JSF 2.0, JPA 2.0 ja EJB 3.1. (Jos niitä vielä pystyisi oikeasti toteutuksessä käyttämäänkin)
• Formatoinnin kontrollointi: Window > Preferences > Java > Code Style > Formatter > On/Off Tags -kohdasta voi nyt kytkeä päälle annotaation, jolla voi disabloida koodin formatoinnin haluamalleen koodiblokille
• “rawtypes” -merkki @SuppressWarnings annotaatiolle: Kääntäjä tekee eron ilmoitettujen varoitusten osalta raw typen käytön ja geneeristen unchecked -operaatioiden osalta.
• Export All: Formatterin asetuksista voi nyt viedä kaikki käyttäjän määrittelemä asetukset, ja ne voidaan tuoda kerralla. Kätevää, kun Eclipse tulee muutamia kertoja vuodessa asennettua uudestaan.
• Pakettien nimien lyhenteet: Java-näkymissä voi lyhentää kustomoitavilla säännöillä pakettien nimet. esim. org.eclipse.ui={UI}, org.eclipse.ui.texteditor={T} ja org.eclipse.ui.internal.texteditor=[iT]. (Preferences > Java > Appearance > Abbreviate package names)
• Lokaalin historian tyhjennyksen voi disabloida: Lokaalin historian kokoa siivotaan aina Eclipsen sammutuksen yhteydessä, mutta sen voi nyt disabloida. Tällöin historian koko kasvaa rajattomasti. (Preferences > General > Workspace > Local History)

Uusi Eclipse on nyt ollut muutaman viikon käytössä ja ihan toimivalta se edelleen vaikuttaa. Kenties hieman myös nopeampi kuin edellinen, ta sitten vain uusi asennus luo hyvää mielikuvaa. Asennuksessa tosin taas meni aikaa säätäessä kaikki kuten aikaisemmin ja Marketplace auttoi hieman lisäosien suhteen, mutta turhan vähän. Samalla vaihdoin Subclipsen käyttöön, joten Maven2-projekien tuonti versionhallinnasta oli kätevämpää. Laitoinpa samalla myös Atlassian Connectorit, jotka vaikuttavat ihan käteviltä. JBossin työkaluista piti tosin asentaa Nightly Build -versiot.

Usability Post kysyykin, pitäisikö Web-sovelluksilla olla yhtenäinen käyttöliittymä, eli ulkoasu näyttäisi ja toimisi visuaalisesti samoilla periaatteilla, kuten työpöytäsovelluksissakin eri käyttöjärjestelmissä sovellukset ovat usein yhtenäisiä keskenään. Tutut toiminnot näyttäisivät samoilta eri Web-sovellusten välillä, kun nyt painikkeiden ja komponenttien ulkoasut vaihtelevat enemmän tai vähemmän eri sovellusten välillä.

On totta, että sitä toivoisi sovellusten toimivan edes suurin piirtein samoilla periaatteilla, ettei aina tarvitsisi arpoa miten asiat nyt tässä toimivatkaan, mutta yleisesti ottaen on vaikea nähdä, että eri Web-sovellukset näyttäisivät peruspiirteiltään samanlaisilta, toimisivat samalla tavalla tai käyttäisivät samoja komponentteja. Web on visuaalisesti toinen maailma verrattuna työpöytäsovelluksiin, joka myös heijastuu sovellusten toimintoihin. Webin osalta ei oikeastaan odoteta, että eri sovellukset näyttäisivät yhtenäisiltä, vaan ollaan jo totuttu, että jokaisen sovelluksen kohdalla pitää aina oppia uudestaan perustoiminnot ja logiikka. Onneksi suunnittelijat tekevät sovellukset usein helposti opittaviksi ja joissa asiat toimivat kuten niiden olettaa toimivan. Tai ainakin näin haluaisi uskoa, sillä todellisuus on välillä aivan jotain muuta.

Kun asiaa ajatellaan pienemmällä skaalalla, olisi sovelluskehittäjällä hyvä olla karkealla tasolla välineet yhtenäisen käyttöliittymän toteuttamiseksi, ainakin saman asiakkaan sovellusten osalta. Toki usein saman kehittäjän sovelluksissa toistuvat samat ratkaisut ja uudestaan käytettävät palikat, joilla yhtenäisyyttä syntyy kuin itsestään. Miksi keksiä asioita uudestaan, kun ne ovat jo kerran toteutettu, ellei asiaa keksi “paremmin”. Suunnittelun ja ratkaisujen avuksi löytyy myös apuvälineitä, joilla visuaalista ilmettä ja sovellusmaista toimintaa voidaan tukea.

Webissä ei ole yhtä ja oikeaa tapaa toteuttaa asioita, vaan monet ratkaisut ovat yhtä hyviä. Mallia voi ottaa esimerkiksi useilta suunnittelumalli-sivustoilta kuten UI Patterns, YPatterns ja UI Pattern Factory. Lisäksi erilaiset komponenttikehykset kuten JQuery UI ja Java EE -maailmassa RichFaces ja PrimeFaces tarjoavat omia ehdotuksiaan toiminnoille. Vaihtoehtoja on monia ja lopputulos on usein eri ratkaisujen yhdistelemistä, jolloin sovellus koostuu useista erilaisista käyttöliittymäratkaisuista. Harvoin eri valmiiden ratkaisujen mallit toimivat suoraan omiin tarpeisiin nähden ja niitä joudutaan vähintäänkin visuaalisen ilmeen osalta virittelemään.

Koska Web perustuu pohjimmiltaan HTML:ään ja CSS:ään, voidaan valmiita komponentteja yleensä muokata ulkoasultaan tarpeiden mukaan ja soveltaa toisaalla havaittuja hyviä asioita. Esimerkiksi Web-sovelluksen käyttöliittymää varten voidaan soveltaa Cappucino tai Sproutcore -kehysten Creative Commons Attribution Share-alike -lisenssin alaisuudessa olevia Ace- ja Aristo-teemoja, jotka näyttävät siisteiltä ja tarjoavat yhtenäisen ulkoasun eri komponenttien välille.

Molemmat teemat näyttävät nykyaikaisilta ja niillä on enemmän yhteistä kuin eroa, jonka voi todeta lyhyestä vertailusta. Enemmän teemojen toiminnasta saa selville, kun vierailee teemojen demosivuilla. Sproutcoren Ace-teemasta on havaittavissa yhtäläisyyksiä OS X:n Aqua-teemaan ja SproutCoren kehitys onkin Applen sponsoroimaa. Cappucinon Aristo-teema ei ole niin silmiinpistävä kuin Ace, keskittyy näyttämään hyvältä sekä Windowsissa että OS X:ssä ja sopii paremmin vakavampiin sovelluksiin.

Molempien teemojen soveltuvuus omaan käyttötarkoitukseen riippuu toteutettavasta sovelluksesta, mutta niistä voi ainakin ottaa hieman mallia, miltä peruskomponentit voisivat näyttää. Cappucinon Aristo-teema on hieman helpommin otettavissa testiin ja se on saatavissa PSD -kuvina ja kolmannen osapuolen CSS 3 toteutuksena. Sproutcoren Ace-teema löytyy vastaavasti vain sprite-kuvina, joten teemaus pitää hoitaa itse loppuun, mutta se tarjoaa kattavamman valikoiman eri komponentteja ja malleja.

Ikävä tosiasia valitettavasti on, että sovelluksen ulkoasun eteen joudutaan aina askartelemaan enemmän tai vähemmän. Esimerkiksi jos sovelluksessa otetaan käyttöön jokin valmis komponentti, pitää sen ulkoasua joko muokata vastaamaan muuta sovellusta, tai käyttää valittua kirjastoa kaikilta osin jokaisen komponentin kanssa, jolloin eroavaisuuksia on mahdollisimman vähän. Valituista ratkaisuista riippuen tämä on enemmän tai vähemmän helppoa. Esimerkiksi JQuery UI:n komponenteille voi määritellä haluamansa ulkoasun kätevästi Theme Rollerin avulla, mutta vastaavasti samanlainen teemanrakentaja tarvittaisiin myös RichFaces-komponenteille, joiden teemaus on suhteellisen työlästä ja osittain arpapeliä. Muutenkin aina tuntuu, että useat valmiit ratkaisut eivät toimi kuten niiden haluaisi toimivan, eikä niitä usein voi myöskään helposti muokata riittävällä tasolla.

Kaikenkaikkiaan Web-käyttöliittymä voi näyttää upealta, jos siihen viitsii panostaa, mutta Web-sovelluksilla ei mielestäni tarvitse olla yhtenäisiä periaatteita. Web on monimuotoinen ja asiat saavat toimia, kuten ne parhaimmikseen näkee, kunhan ne silti toimivat loogisesti ja ymmärrettävästi. Toki yhtenäiset ratkaisut helpottavat käyttäjän elämää. Toisaalta Webin käyttöliittymät eivät helposti vertaudu perinteisiin työpöytäsovelluksiin, ainakaan nykyisillä teknologioilla ennen HTML5:n ja CSS 3:n yleistymistä, joten sallittakoon niille myös omat tyylinsä, kunhan ne ovat hyvällä maulla toteutettuja.

Pitääkin tässä edistää työlistalle hautautunutta tehtävää jalostaa omaa visuaalisesti yksinkertaista komponettiteemaa eteenpäin ja rakentaa vastaava teemaus myös RichFaces-komponenteille, jolloin asiakkaan sovellus saisi vielä nykyistä yhtenäisemmän ulkoasun.

Kumiankka-metodi debuggauksessa menee seuraavasti:

1. Kerjää, lainaa, varasta, osta, valmista tai muuten hanki kumiankka (amme-tyyppiä)
2. Aseta kumiankka pöydälle ja kerro, että tulet kohta käymään läpi hieman koodia sen kanssa.
3. Selitä ankalle mitä koodisi pitäisi tehdä ja syvenny yksityiskohtiin kertomalla asiat rivi riviltä.
4. Jossain vaiheessa tulet kertomaan ankalle mitä teet seuraavaksi ja sitten tajuat, että todellisuudessa se ei ole sitä, mitä oikeasti teet. Ankka istuu seesteisenä, onnellisena siitä tiedosta, että on auttanut sinua.

Toimii joka kerta, ja jos kumiankkaa ei ole saatavilla, voi korvikkeena käyttää myös toista henkilöä, joka istuu vieressäsi ja kuuntelee. Tosin, jos työskentelet avokonttorissa ja selität asioita kumiankalle, kannattaa se tehdä ääneti ajatuksissa, sillä muuten voit saada osaksesi outoja katseita. Englanniksi asia tunnetaan nimellä Rubber Duck Debugging.

Vaadinta voi lyhyesti kuvata sanomalla sen olevan Swing-koodausta sekä hyvässä että pahassa. Web-sovelluksen toteutus Vaatimella on suhteellisen helppoa, mutta toisaalta se myös Swingin tapaan rajoittaa käyttöliittymäsuunnittelua. Toteutuksessa HTML:n ja komponenttien säätäminen jää pois, jolloin toteuttajat voivat keskittyä varsinaiseen toimintaan kuuntelijoiden ja tapahtumien parissa. Kokonaisuutena kehitys on tavallaan selkeämpää kuin esimerkiksi JSF:llä, jossa toiminnot hajoavat sekä sivuille että Java-luokkiin ja erilaisia säädettäviä XML:iä on useita. Totuus ei tietenkään ole aivan näin yksinkertaista, mutta melkein.

Sovelluskehityksen osalta Eclipselle on saatavilla WYSIWYG-editori ja sovelluksen debuggaus onnistuu normaalisti debug-moodissa ja käyttöliittymän osalta Firefoxin Firebug-lisäosalla, eli sen osalta ei ole mitään ihmeellistä. Käytettävissä on useita erilaisia komponentteja ja hyvä dokumentointi, joilla toimintoja rakentaa. Tutoriaalien avulla pääsee helposti alkuun ja näkee mistä asiassa on kyse. Vaadin on lisensoitu avoimen lähdekoodin Apache License versio 2.0 -lisenssillä, joten tarvittaessa sen laajentaminen ja bugien korjaaminen on mahdollista. Saatavilla on myös maksullista tukea ja palveluita.

Vaadin perustuu Google Web Toolkitin päälle, jota käytetään selaimelle piirtämiseen ja GWT:hen verrattuna Vaadin-sovellukset pyörivät palvelinpuolella, kun GWT on selainpuolen sovellus. Vaadin-sovellus on paljolti sidottu JavaScriptiin ja siinä on mielestäni myös sen heikoin lenkki, sillä suorituskyvyllisesti käytetty lähestymistapa ei ole kovin tehokas. Etenkin monimutkaisilla käyttöliittymäkomponenteilla ja ulkoasuilla selaimen JavaScript-suorituskyky tulee äkkiä vastaan, vaikkakin tällä saralla on etenkin Googlen Chrome ja Safari kunnostautuneet. Muuten komponentit toimivat hyvin riippumatta käytettävästä selaimesta.

Vaikka Vaadin tavallaan yksinkertaistaa rikkaiden Internet sovellusten (RIA) tekemistä, pidän itse enemmän perinteisestä Java Server Facesiin (JSF) pohjautuvasta Web-kehityksestä. JSF:n kanssa käyttöliittymän koodi on erikseen HTML:ssä, johon on lisätty tarvittavat sidokset ja dynaamisuutta. Tietenkin tässäkin tavassa on omat ongelmansa, etenkin kun JSF 1.2 ja käyttöliittymäkomponentit ovat mitä ovat. Ehkä taustani Web-koodaajana vaikuttaa siihen, että pidän enemmän siitä, että pääsen helpommin näkemään ja säätämään käyttöliittymää HTML-tasolta, eli tekemään juuri sitä, mistä “perinteiset” Java-koodarit eivät tykkää. Ainakin saan tarkalleen mitä haluan, jos osaan sen HTML:llä, CSS:llä ja käytössä olevilla komponenteilla toteuttaa.

Vaadin on kuitenkin kätevä tapa toteuttaa Web-sovelluksia ja sillä saa kohtalaisen nopeasti aikaan hyvän näköistä jälkeä helposti. Toisaalta kuten kaikissa sovelluskehyksissä, on myös Vaatimessa asioita, jotka aiheuttavat kehittäjälle harmaita hiuksia. Nimi Vaadin tarkoittaa myös naaraspuolista poroa ja sanaa voidaan käyttää esimerkiksi lauseessa “Vaadin parempia käyttöliittymiä!”.

Näköjään seuraava Vaadin Developer Meetup pidetään 3.12.2009 Pitäjänmäellä Helsingissä Logican tiloissa (ilmoittautuminen 26.11.2009 mennessä).

Esimerkkinä silloin vielä IT Mill Toolkit -nimellä tunnetulla Vaadin-kehyksellä hahmoteltu sähköpostisovellus:

Mac OS X:ssä dynaamiset kirjastot toimivat hieman eri lailla ja haluavat täydellisen polun asennushakemistoonsa. Asiasta löytyy blogikirjoitus ja selventävä ohje, jotka kertovat miten asioiden laita on. Kirjoituksissa neuvotaan toimivien dynaamisten kirjastojen luontiin käyttämällä install_name_toolia ja LDFLAGS-muuttujien käytöllä.

Hieman asian ympärillä iteroiden ei kirjastojen kääntäminen toivotulla lopputuloksella kuitenkaan onnistunut. Vaikka LDFLAGS-muuttujiin laittoi ehdotetun -Wl,-dynamic,-install_name -Wl,@executable_path/kirjasto.dylib -loitsun, eivät lisäosan vaatimat gettext, iconv, glib-2, malaga, suomi-malaga ja voikko -kirjastot suostuneet toimimaan lisäosan sisältä. Gettextin libintl -kirjastoa varten joutui LDFLAGS-muuttujat lisäämään suoraan Makefileen, mutta muuten loitsiminen onnistui configuren parametreina.

En tiedä onko vika kirjoittajassa, vai missä, mutta ei voi sanoa, että asiaa olisi turhan helpoksi tehty. Joku jippo tässä täytyy olla, kun kirjastot kuitenkin /usr/local/lib -hakemistosta toimivat. Ehkä tämäkin asia joskus selkenee.

Koodin jäsentelyyn liittyvien sisennysten toimintaan on Nick Gravgaardin ideoinut niin sanotun joustavan sisennyksen eli “elastic tabstops” -ominaisuuden, jossa rivit sisentyvät selkeiksi ryhmiksi. Ominaisuudessa tabulaattorin pituus voi vaihdella eri riveillä ja teksti on jaoteltu tavallaan kuin taulukon soluihin ja sarakkeisiin.

Esimerkiksi ryhmän rivit sisennetään automaattisesti samalle tasolle.

ja rivin muuttuessa ryhmän rivien sisennystä muutetaan automaattisesti uuteen pituuteen.

Ideasta saa paremman käsityksen, kun vilkaisee enemmän esimerkkejä miten Code Browser -ohjelma asian toteuttaa tai testata ominaisuutta käytännössä. Sisennyksen automaattinen muuttaminen tekstin muuttuessa tuo selkeyttä koodin lukemiseen muun muassa switch-case -rakenteissa, muuttujaryhmissä ja kommenteissa.

Ominaisuus näyttää kätevältä, mutta harmillisesti se ei ole vielä yleistynyt. Toivoa kuitenkin herättää, että ominaisuudesta on tehty kehitysehdoitus Eclipseen ja ominaisuus löytyy kuulemma Swingistä, GTK:sta ja tulevasta Visual Studiosta. Gedit-editoriin tämä mullistava uudistus on saatavissa Nick Gravgaardin tekemän lisäosan avulla.

Muutamia käteväksi todettuja ja omasta mielestäni “parhaita käytäntöjä” koodaajan näkökulmasta ovat muun muassa:

1. Työn kulku
2. Vie koodi versionhallintaan usein ja aikaisin
3. Vie yhtenäisiä kokonaisuuksia
4. Kirjoita järkeviä commit-viestejä
5. Tee koodaustyylin muutokset erillään oikeista muutoksista
6. Älä vie tiedostoja, jotka muuttuvat dynaamisesti
7. Älä vie koodia, joka ei käänny

1. Työn kulku
“Version Control with Subversion” -kirja selvittää normaalin työn kulun, joka on hyvä omaksua versionhallintaa käytettäessä (hieman sovellettuna):

1. Hae koodista tuorein versio versionhallinnasta
2. Toteuta koodiin tehtävät muutokset
3. Hae tuorein versio ennen koodin vientiä versionhallintaan
4. Aja testit uudestaan ja varmista, että tekemäsi muutokset toimivat
5. Vie koodi versionhallintaan yhtenä kokonaisuutena
6. Selvitä konfliktit
7. Tarkista, että versio kääntyy myös build-palvelimella
8. Korjaa virheet tai palauta

2. Vie koodi versionhallintaan usein ja aikaisin
On suositeltavaa toteuttaa Check In Early, Check In Often -periaatetta. Tällöin muut näkevät mitä olet tekemässä ja koodi on muidenkin käytössä.

“If the code isn’t checked into source control,
it doesn’t exist.” – Coding Horror

Lisäksi jos piilottelet koodia omalla koneellasi, etkä synkronoi sitä versionhallintaan pitkään aikaan, voi muutosten yhdistämisestä tulla erittäin työlästä. Pieniä kokonaisuuksia on helpompi verrata ja saadaan aikaan vähemmän konflikteja.

Vaikka idean järkevyys ja käytännöllisyys on helppo ymmärtää, on käytännön toteutus usein jotain muuta. Itse olen ainakin huomannut, että omaa koodia tulee helposti pantattua levyn nurkalla, kunnes kyseinen ominaisuus on “valmis” ja testattu.

“Hiding your code until it’s “done” may feel safer, but it isn’t. Sharing your ongoing code with your coworkers is scary, much less the world — but it also results in feedback and communication that will improve your code and draw you closer to the project you’re working on.” – Coding Horror

3. Vie yhtenäisiä kokonaisuuksia
On suositeltavaa viedä versionhallintaan loogisesti yhtenäisiä kokonaisuuksia. Tämä tekee versiohistorian seuraamisesta huomattavasti hyödyllisempää, etenkin jos muutokset käsittelevät useita eri tiedostoja.

Eli, jos teet useita yhtäaikaisia muutoksia, jaa ne useampaan loogiseen kokonaisuuteen ja vie ne osissa. Näin yksittäisten muutosten historiaa on helpompi seurata ja nopeuttaa mahdollisten bugien metsästystä myöhemmin. Jos siis teet ominaisuutta A, B ja C sekä korjaat bugeja 1, 2 ja 3, pitäisi niistä muodostua vähintään kuusi committia. Vastaavasti, jos teet suuria muutoksia tai toteutat itsenäisiä muutoksia useisiin loogisiin moduleihin, vie muutokset erikseen, vaikka ne olisivatkin osa isompaa kokonaisuutta.

Käytännössä sitä kuitenkin usein huomaa koodaavansa hieman sieltä sun täältä sitä ja tätä, ja lopulta järkevän yhtenäisen kokonaisuuden vieminen versionhallintaan on käytännössä mahdotonta.

Tietenkin tätä periaatetta on helpompi noudattaa sovelluksen ylläpidossa kuin sovelluksen kehittämisessä, jossa puutteellisia ja koodausta kaipaavia asioita on paljon. Teoriassa järkevä “commit”-tapa on helppo omaksua, mutta käytännössä yhtenäisen kokonaisuuden siirtäminen versiohallintaan vaatii itsekuria ja koodauksen suunnittelua.

4. Kirjoita järkeviä commit-viestejä
Kirjoita aina jokin kommentti viedessäsi koodia versionhallintaan. Kommentin tulisi olla lyhyt ja ytimekäs, ja kertoa mitä muutettiin ja miksi. Jos teit useita muutoksia, kirjoita ne omille riveilleen.

On myös kätevää lisätä kommentin eteen jokin tunniste kuten Fix tai Add, viitaten minkä tyyppisiä muutoksia teit. Tämä myös helpottaa sisällön filtteröintiä myöhemmin.

Korjatessa jotain tiettyä bugia tai pyydettyä ominaisuutta, on suositeltavaa lisätä bugin tai issuen numero commit-viestiin.

“If the changes you made are not important enough to comment on, they probably are not worth committing either.” – loop label

5. Tee koodaustyylin muutokset erillään oikeista muutoksista
Koodaustyyli voi kokea muutoksia ja kehitysvälineessä voidaan esimerkiksi ottaa käyttöön automaattiset koodimuotoilut. On erittäin suositeltavaa, että koodin muotoiluun vaikuttavat muutokset tehtäisiin erillään oikeista muutoksista.

Jos koodimuotoilut ja muutokset sekoitetaan keskenään, on muutosten jäljittäminen ja kohdistaminen käytännössä mahdotonta.

6. Älä vie tiedostoja, jotka muuttuvat dynaamisesti
Versionhallinnassa olevien tiedostojen olisi hyvä olla sellaisia, joiden sisällöstä valta on käyttäjillä eikä esimerkiksi kehitysympäristöllä. Esimerkiksi ei kannata viedä Eclipsen asetuksia tai projekti-tiedostoa, jotka muuttuvat riippuen kehittäjän haluamista asetuksista. Kyseiset tiedostot eivät varsinaisesti liity projektin koodiin ja aiheuttavat vaan turhaa synkkaamista. Myös projektin binäärit ja Javadocit voidaan mieltää turhiksi versionhallinnan näkökulmasta.

(via Perforce)

7. Älä vie koodia, joka ei käänny
Ei ole suositeltavaa viedä versionhallintaan koodia, joka ei käänny ja hajottaa projektin myös muille kehittäjille. Toisaalta, ideaalissa tilanteessa, ei pitäisi koskaan lähteä toimistolta viemättä koodia versionhallintaan.

Jos teet muutoksia, jotka vaikuttavat muihin, harkitse koodin branchaamista muutoksen toteuttamiseksi ja yhdistä koodi, kun olet valmis. Toisaalta, toimimaton koodi ei ole syy olla viemättä sitä versionhallintaan.

“It’s better to have a broken build in your working repository than a working build on your broken hard drive.” – loop label

Yhteenveto
Versionhallinnan käyttö on omaksuttu osaksi sovelluskehitystä ja toivottavasti edes osa yllä olevista periaatteista on jo useimpien kehittäjien käytössä. Ellei käytössä olevia työvälineitä hyödynnetä kunnolla, jää paljon etuja saavuttamatta. Edes muutaman yllä olevan käytännön omaksuminen kuten “loogiset kokonaisuudet” ja “commit-viestit”, helpottaa jo kummasti.

Versionhallinta on käsitteenä laaja ja sen käyttöön liittyy paljon muitakin asioita, joista voidaan määritellä niin sanotut parhaat käytännöt. Tälläisiä ovat muun muassa koodin hallintaan liittyvät asiat, versionhallinnan soveltaminen ja toimintojen laajentaminen, mutta ei niistä sen enempää.

Blueprint CSS on norjalaisen opiskelijan, Olav Frihagen Bjørkøy:n luoma CSS-framework, joka käytännössä kokoaa yhteen useita hyväksi havaittuja tekniikoita ja tarjoaa hyvän perustan web-sivun rakentamiselle. Kehyksen kokonaisuus rakentuu ristikkotaiton päälle (Grid Layout) ja tarjoaa järkevät perusarvot typografialle ja eri CSS-elementeille. Vakiona sivuston sisältö on suunniteltu 960px leveäksi eli 1024×768 -resoluutiolle. Blueprint CSS:n tarjoamia ominaisuuksia voi laajentaa muun muassa hienommilla napeilla. Jos Blueprint CSS:n taustat kiinnostavat, kannattaa lukaista Olavin haastattelu.

“Spend your time innovating, not replicating.” – Blueprint CSS

Parhaiten Blueprint CSS:n idea selvenee esimerkeistä:

Blueprint CSS:llä saa aikaan nopeasti sekä näkyvää että siistiä tulosta ja varsinkin hieman vähemmän CSS:n kanssa taistelleille web-koodareille se on hyvä lähtökohta. Vastaavasti hieman kokeneemmille toteuttajille Blueprint CSS:n käyttäminen voi tuntua hieman rajoittavalta ja jäykältä, vaikka monilta osin se tarjoaakin käteviä palikoita nopeaan toteutukseen. Tältäkin osin Blueprint CSS -framework toteuttaa monen muun frameworkin tavoin yhden niiden käytön ongelman: olet “rajoittunut” valitsemasi kehyksen sisään ja sieltä irtautuminen voi olla työlästä.

Kokeilin Blueprint CSS:n kätevyyttä muutaman web-projektin suunnittelussa ja etenkin sen sopivuutta omiin tarpeisiini, mutta vaikka kehys vaikuttikin näppärältä, ei se oikein taipunut haluamiini raameihin. Pala palalta kaipasin jotain hieman erilaista, jota Blueprint CSS ei tarjonnut, ja lopulta totesin helpommaksi vain poimia käyttöön ne osat, jotka havaitsin käytännölliseksi. Eli käytännössä olen osa osalta rakentamassa omaa CSS-kehystä, joka toki hiemankin enemmän web-sivujen suunnittelua tekeviltä jo jossain muodossa löytyy. Työläin vaihehan vain on kaikkien palikoiden kerääminen yhteen ja sen jalostaminen sopivaksi kokonaisuudeksi.

Vaikka Blueprint CSS ei oikein lämmittänyt, sen kanssa leikkiessä tuli kuitenkin todettua, että ristikkotaitto eli Grid Layout on aika kätevä tapa sijoitella komponentit ruudulle. Kehitysvaiheessa ristikkotaiton ja elementtien sijoittelun apuna on lisäksi kätevä käyttää Grid Layout JS -palikkaa, joka JavaScriptin avulla näyttää ja piilottaa sivutaiton sarakkeet.

Kenties seuraavaksi pitää tutkia, mitä tarjottavaa BlueTripillä on ja mitä kaikkia komponentteja Yahoo User Interface Librarysta löytyy. Open Sourcessa on se mainio ominaisuus, että jos jokin asia ei miellytä, lisäyksen saa kohtalaisen helposti toteutettua ja aina voi tietenkin forkata.