Pysähdyin hetkeksi sivustolle, jolla on missionaan pyyhkäistä Internet Explorer 6 maan kamaralta.
Linkki Deliciousiin ja sillä selvä? Miksipä ei mutta kun tuolla sijaitseva artikkeli herätti ajatuksia ja asia vaikuttaa meistä jokaiseen niin annetaan pulputa.
Upotusten ominaisuudet uudessa sisältöeditorissa. Monille tuo ei sano yhtään mitään mutta harmin lähteenä se on kuukausien mittaan muodostunut jo jonkin sortin käsitteeksi. Tänään aiheeseen liittyvä ongelma taisi viimein ratketa mutta voittajaoloa se ei tuonut mukanaan. Tällä kertaa tarina epäonnistumisesta ja miten siitä ei välttämättä opi mitään.
Tänään väänsin graafisen käyttöliittymäehdotuksen gliffyllä. Gliffy on parhaimmillaan loistoväline käyttöliittymäsuunnittelussa, sillä se mahdollistaa “prosessisuunnittelun” ( vrt. prosessikirjoitus.).
Linkki: http://www.gliffy.com/
Tällä viikolla nousi esille kysymys, kuinka saada oma avatar kuva näkymään blogeissa. Koitan tässä artikkelissa parhaani mukaan opastaa tarvittavien toimien läpi.
Tänäänkin avautui mahdollisuus oppia uutta sekä itsestään että kanssaihmisistään, sponsorina Otavan opiston Muikku-oppimisympäristö, joka potentiaalisesti näköjään kouluttaa myös muita kuin verkko-opiskelijoita.
Pieni takavasemmalta kimppuun hyökkäävä avunpyyntö voi johtaa mihin tahansa. Tällä kertaa mielenkiintoiseen oppimiskokemukseen.
Nykyään netti on pulloillaan erilaisia tiedon tuottamiseen tarkoitettuja välineitä ja avoimen lähdekoodin palikoita joita voi ymppäillä omiin projekteihin aika vapaasti. Kuten esim tämä Wordpress. Tämä tietysti alentaa kynnystä ratkoa ongelmia tämänkaltaisilla välineillä. Vaarana moisessa ajattelussa on se, että se tehdään käyttäjien kustannuksella ja väkisin.
Kuten aina, tekniikallakin on rajoituksensa ja ympäristöjä tuotettaessa oppimisen paikka myös käyttäjillä. Sosiaaliset ratkaisut ovat usein parhaita ratkaisuja. Ympäristöjähän on laidasta laitaan, mutta oma näkemys verkkoympäristöstä on työkalu: Olen osana rakentamassa työkaluja, välineitä ihmisille jotta he voivat oppia, opettaa. Tehtäväni on tehdä siitä mahdollisimman helppoa.
Olen oppinut, että eräänlainen epätarkkuusperiaate on olemassa näitä työkaluja suunniteltaessa ja rakenneltaessa, ääripäät ovat suurinpiirtein seuraavat:
Tunkki
Ympäristön voi rakentaa loppukäyttäjää holhoten. Narut käsissä, ohjaten pilkuntarkasti hänen jokaista toimeaan, ja pohtia etukäteen tarkasti mitä hän saa ja ei saa työkalulla tehdä. Luoda selvät rajat toiminnolle. Tämä lähestymistapa tuottaa helppokäyttöisiä ympäristöjä, joilla voi tehdä jotain asiaa helposti. Tällä lähestymistavalla myös helposti tuhotaan luovuus, ja ympäristöt ovat usein raskaita ja pilkuntarkasti räätälöityjä. Ratkaisumallien uudelleenkäyttöaste on huono. Tunkin perusluonne on staattinen, se näyttää käyttäjälle yksinkertaiselta, se on pitkälle erikoistunut toimittamaan yhtä asiaa. Sen erityispiirre on, että se tekee juuri sen mihin se on suunniteltu, ei yhtään enempää.
Hilavitkutin
Ympäristön voi rakentaa ratkomaan geneerisiä ongelmia, heittää pallon loppukäyttäjälle. Tämä vaatii käyttäjältä opettelua. Hän ei osaa heti ensihetkestä lähtien tehdä kaikkea tällaisella ympäristöllä, vaikka tietääkin mitä ongelmia sillä periaatteessa ratkotaan. Hän joutuu käyttämään ympäristöä, kokeilemaan, opettelemaan – hankkimaan jopa koulutusta. Hänellä on ratkaisujen suhteen vapaat kädet; Voi olla että saman asian voi tehdä monellakin tapaa ja on mahdollista kehittää omia, uniikkeja käytäntöjä, ja löytää ympäristöstä uusia puolia. Hilavitkuttimen perusluonne on dynaaminen, se mahdollistaa monia erilaisia ratkaisumalleja samaan ongelmaan. Hilavitkuttimen erityispiirre on, että siitä saa rakennettua tunkin jos niin haluaa, siinä missä tunkista ei ehkä niin helposti saa hilavitkutinta.
Ympäristöt voivat nykyään itse koostua tunkeista ja hilavitkuttimista, pienemmistä osista, esimerkiksi tekstin tuottamiseen yms. on monenlaisia. Ne samat tunkkimaiset/hilavitkutinmaiset osaset toimivat ympäristössä eri tilanteissa, eri rooleissa, hoitaen kuitenkin sitä ennaltamäärättyä virkaa.
Mutta asiaan. Kuten jo alussa totesin, huolenaiheena ja mahdollisuutena ovat tällaiset valmiit julkaisualusta. On Drupalia, wikiä, wordpressiä ja muuta. Niissä piilee suuri mahdollisuus, sillä asiakas tulee palveltua helposti ja nopeasti, aikaa jää tunata yksityiskohtia jne. Sitä ei käy kieltäminen.
Suurin huolenaiheeni on se, että niitä ja niiden valmiiksipureskeltuja, varsinkin tunkkimaisia ominaisuuksia tarjotaan käyttäjille, että päästetään tekniikka sanelemaan mikä on hyväksi loppukäyttäjälle. On olemassa vaara, että ei kartoiteta tarkasti kykeneekö työkalu vastaamaan käyttäjän tarpeisiin käyttäjän vaatimalla tavalla. Käyttäjän tarpeet ovat selvillä, työkalun ominaisuudet ja mahdollisuudet ovat selvillä, mutta tarpeiden ja ominaisuuksien suhdetta ei koskaan pohdita. Nämä välineet tuottaa sisältöä ovat uusia, joten niiden ongelmat ja rajoituksetkin eri käyttömuodoissaan ovat myös uusia ja varmasti alkupään selvitystyö ja kommunikointi pelastavat monelta lapsukselta.
Päätös käyttää jotakin julkaisujärjestelmää jonkin ympäristön tarkoituksiin ei voi olla lähtökohta, sen täytyy olla tarkastelun, selvityksen ja siitä seuraavan ymmärryksen seuraus.
En minä ainakaan halua kalastaa tunkilla. En, vaikka siinä olisikin ledivalo ja riittävästi siimaa.
Asialista:
SVN:än uudelleen asentaminen
Ensi perjantain virtualisointi ei vielä auta tähän, joten homma myöhempään aikaan.
Ulkoverkko SVN
Ensi perjantain virtualisointi ei vielä auta tähän, joten homma myöhempään aikaan.
Ratkaisuiden oma Nexus
Ensi perjantain virtualisointi ei vielä auta tähän, joten homma myöhempään aikaan.
Palomuuri ongelma: Revisited
Homma ok, viime viikkoiset muutokset auttoivat.
BugZillan uudelleen asentaminen
ATK-Tuki hoitaa.
BugZillan käyttöönotto
Ratkaisutiimi etsii työkaluja, joilla sitä voitasiin ihmimillisemmin käyttää.
Muut
Ei muita asioita
Tästä lähtee. Teknoblogiin kirjoittamiseni varmastikin tulee muotoutumaan aika paljon työnkuvan ja realiteettien pohdinnan ja ideoiden pyörittelyn ympärille, ja mahdollisesti myös ajankohtaisiin aiheisiin ja ongelmiin aion pureutua jos näen tarvetta. Kukkonen näyttäisi niissä tosin tekevän enemmän kuin hyvää jälkeä, joten aika vähissä voi olla se puoli.
Eli: Nimi on Antti Ukkonen, olen ratkaisutiimissä ympäristöihin, toiminnallisuuksiin ja käyttöliittymien kasaamiseen keskittyvä lihava ja karvainen webbisuunnittelija. Jos sitä nyt ei joku potentiaalisista lukijoista ( ne 3 kpl – Terveisiä vaan Leppä, Laitila ja Kukkonen!) jo tiennyt.
Kommenteissa voi myös kysellä ja ehdotella jos haluaa tietää jostakin tarkemmin tai muuten vaan kuulla miten päin se divi lepää.
Ratkaisutiimi vietti 13. perjantain Heimarissa kehittämässä omaa toimintaansa.
Päivän aiheita olivat edellisen vuoden projektit, oman osaamisen arviointi ja kehittäminen, uudet toimintatavat sekä Pyramus 2009:n käynnistys.
Päivä aloitettiin Villen johdolla uuden projektin Pyramus 2009:n esittelyllä.
Noin pähkinänkuoressa Pyramus on toiminnanohjaus, -suunnittelu ja seurantaväline, jolla voidaan harrastaa kannattavuuslaskentaa, kustannusseurantaa, tilastointia sekä raportointia.
Ohjaavina ideoina projektissa ovat:
Projekti käsiteltiin suhteellisen nopeasti. Varsinainen suunnittelun aloittaminen sekä projektiryhmän kasaaminen päätettiin jättää lähitulevaisuuden ongelmaksi.
Kun Pyramus -projekti oli saatu käsiteltyä loppuun asti aloitettiin keskustelmaan edellisestä vuodesta. Edellisenä vuotena oli ehtinyt menemään läpi niin paljon pieniä projekteja, että emme mitenkään voineet käsitellä niitä kaikkia. Sen sijaan käsittelimme kaksi suurinta projektia: Muikku 2:n ja eDelfoi 2:n ja niputimme pienet projektit kahden otsikon alle: Pienet projektit sekä open source -projektit. Keskusteltavaa suurista projekteista tuntui piisaavan, mutta pääasiallinen viesti oli selkeä: eteenpäin on menty ja reilusti, niin laadussa kuin käytettävyydessäkin. Silti parannettavaa on vielä kummallakin saralla paljon.
Pienissä projekteissa muutos on ollut viime vuonna erityisen suuri, sillä niiden tekemisessä ole enää lähdetty rakentelemaan Nexus -ympäristöjä vaan ollaan useimmiten päädytty open source -ratkaisuihin kuten Wordpress tai Wiki. Ensimmäisen Wordpress-installaation jälkeen (Nettilukion blogi) on erilaisia pikkusaitteja ehditty tekemään Wordpressin avulla jo 10 kappaletta. Wordpressi lisäksi Wiki-pohjaisia ympäristöjä on matkan varrella siunaantunut jo kuusi kappaletta ja useita muita ratkaisuja on ehditty protoilemaan ja tutkimaan. Kelkka on siis vihdoin alkanut kääntymään Nexuksesta open sourceen! Rock Rock!
Menneisyyteen tuijottelun jälkeen siirryimme kaikkien niin kovin rakastamaan osuuteen: omien ja tiimitovereiden vahvuuksien kartoittamiseen. Käytännössä kirjailimme kukin paperille omia, tiimin ja tiimitovereiden vahvuuksia ja heikkouksia. Lopuksi tulokset vedettiin kootusti yhteen (tuloksia voi käydä kyselemässä oikeuden määräyksen kanssa minulta). Kaikki tämä piina tähtäisi seuravaan tehtävään: miten meidän pitäisi yksilöinä ja tiiminä kehittyä, että pysyisimme paremmin tekemään työtämme. Keskustelussa ilmeni, että varsinaista koulumuotoista koulutusta pidettiin epätoivottavana tapana mutta kirjallisuutta kaivattiin kyllä. Kirjoja olisi hyvä olla ainakin väreistä, Ajaxista, JavaScriptistä, Prototypestä sekä Scriptaculouksesta.
Keskustelussa tuli esille myös se, että joidenkin kohdalla kehittymiselle nähtiin esteenä pelko siitä, että kun tässä talossa kehittyy jossakin hyväksi vedetään kehittynyt yksilö kouluttamaan pajoihin sun muihin virvellyksiin osaamaansa asiaa, eli käytännössä tietynlaisella persoonalla varustettuja ihmisiä siis rangaistaan kehittymisestä. Tähän ongelmaan ehdoteltiin ratkaisuksi sitä, että nörtit yrittäisivät viestiä osaamistaan, olemistaan heille luonnollisella tavalla, eli blogeissa, ningeissä, tubeissa sun muissa hassun nimisissä palveluissa. Lisäksi keskusteltiin mahdollisuudesta jakaa tietoa MMM:lle, josta sitä voitaisiin näppärästi jakaa eteenpäin.
Muonitustauon jälkeen lähdettiin kohti iltapäivää ja konkretiaa. Aiheena oli tiimin uudet toimintatavat. Uusiin ehdotettuihin ja keskusteltaviin toimintatapoihin kuuluivat extreme programming, koodikatselmoinnit sekä bugien hallinnan kehittäminen.
Extreme programmingilla tarkoitetaan satsia ketterän ohjelmistokehityksen menetelmiä, joihin kuuluu mm. pariohjelmointi, testivetoinen kehitys, jatkuva iteraatio jne. XP-menetelmiä olemme kyllä käyttäneet ennenkin palvelinpuolen kehityksessä mutta tällä kertaa keskustelimme ideoiden käyttöönotosta myös websuunnittelutyössä. Lisäksi käsittelimme yksikkötestauspohjaista suunnittelua.
XP-keskustelu aloitettiin pariohjelmoinnista (kaksi koodaria koodaa samaa projektia samalla koneella). Pariohjelmointi (ns. XP-koodaus) on todettu varsin hyväksi metodiksi, jakaa tietoa sekä ratkaista vaikeita ongelmia mutta sitä ei vain meillä ole vielä kokeiltu webohjelmointipuolella. Ideaa kokeilla XP-koodausta webkoodauksessa ei sinänsä tyrmätty mutta todettiin kuitenkin, että esimerkiksi JavaScriptin vääntämiseen se ei vielä ole paras mahdollinen opiskelukeino, sillä websuunnittelijoiden pohjatieto JavaScriptissä ei ole vielä riittävä. Eli ensin kirjoista pohjatieto kuntoon ja sitten XP:nä kehittymään.
Yksikkötestauksen käyttöönotosta syntynyt keskustelu oli lyhyt mutta hedelmällinen. Lopputuloksena oli päätös kokeilla suunnittelutapaa uudessa Pyramus-projektissa ja jatkaa käytäntöä sitä seuraavissa projekteissa, jos se todetaan hyväksi ja toimivaksi toimintatavaksi. Vanhojen kokemusten perusteella tiedettiin jo, että vanhoihin jo olemassa oleviin projekteihin yksikkötestaus ei sovellu.
Seuraavaksi keskustelu jatkui koodikatselmointeihin. Käytännössä koodikatselmointi tarkoittaa sitä, että kun ohjelmaan / sivustoon ollaan tekemässä päivitystä, luetaan kaikki muuttunut koodi läpi vähintäänkin kahden mutta mielellään useamman koodarin voimin. Käytännöllä pyritään vähentämään virheiden määrää, sekä parantamaan koodin laatua. Koodikatselmoinnit ovat koodareiden puolella jo arkea, mutta websuunnittelija puolella käytäntöä ei kuitenkaan käytännön syistä ole koskaan edes harkittu. Palvelimien virtualisoinnin myötä on kuitenkin mahdollistunut tilanne, jossa ratkaisuilla on oma palvelin jota vasten websivustoa kehitetään ja kun koodi on valmis ja testattu, voidaan se koodikatselmoinnin kautta viedä varsinaiselle tuotantopalvelimelle.
Hommaa helpottamaan päätettiin samalla uudelleenorganisoida versiohallinta käyttämään trunk/stable-haaroja. Nykyinen versionhallinta siis jaetaan kahteen haaraan, joista toinen edustaa testipalvelimen ja toinen tuotantopalvelimen tilannetta.
Lopuksi keskusteltiin bugien hallinnasta. Ehdotuksena oli, että otamme Bugzillan kunnolla käyttöön keskitetyillä ilmoittajilla, hautaamme bugilistan, alamme viikkotasolla seuraamaan bugien määrää ja niiden ratkaisujen vasteaikaa sekä uudelleenohjaamme Muikun bugit takaisin helpdeskiin.
Ehdotuksista tuli käden käänteessä päätöksiä, sillä päätimme ottaa Bugzillan käyttöön ainoana bugien hallintavälineenä. Bugzilla on tosin asennettava uudestaan sillä tämän hetkinen asennus ei toimi. Keskitetyn ilmoittamisen kannalla oltiin yksimielisesti, koska tuolla ratkaisulla säätyttäisiin kaaokselta, jonka bugien ilmoitusmuutos muutoin aiheuttaisi sekä saataisiin ongelmien ohjautuminen oikeille urilleen, eli ensisijaisesti helpdeskiin, josta ihan oikeat bugit ohjautuisivat Bugzillaan ja sitä kautta korjaajien tietoon.
Sitten eikun ideoita toteuttamaan…