Web-palveluissa sijaitseva tieto ei ole ikuisia

Nykyään yhä enemmän ihmisten datasta, oli se sähköpostia, kirjanmerkkejä tai muistiinpanoja, on sähköisessä muodossa jossain Internetin lukuisista Web-palveluista, eli poissa käyttäjän ”omistuksesta”. Käyttäjä on ulkoistanut tiedon säilyttämisen palveluntarjoajalle, mutta ei usein tule ollenkaan ajatelleeksi, että etenkin ilmaispalveluiden osalta tiedon säilyvyys ei välttämättä ole niinkään varmaa.

Kävin jokin aika sitten läpi eri Web-palveluihin tekemiäni tunnuksia ja muutaman vuoden takaisista palveluista oli osa jo ehtinyt lopettaa toimintansa. Tällaisia olivat muun muassa Pownce, Widsets ja Ma.gnolia. Kahden ensimmäisen palvelun lopettamisesta tuli aikoinaan sähköpostiin tiedotteita, mutta sosiaalinen kirjanmerkkipalvelu Ma.gnolia päättyi tarinan mukaan yllättäen tietokannan hiljaiseen hajoamiseen. Onneksi en aikanaan vaihtanut Delicious -kirjanmerkkipalvelusta pois, vaikka Ma.gnolia tarjosikin muutamia käteviä ominaisuuksia. Siinä olisi samalla hävinnyt kasa kirjanmerkkejä, ellei niistä olisi ollut varmuuskopioita omassa tallessa, jotka palvelusta halutessaan sai.

Useissa Web-palveluissa ei ole välttämättä edes tarjolla mahdollisuutta itse tuottamansa sisällön tuomiseen omaan talteen, joten pahimmassa tapauksessa esimerkiksi urheilupäiväkirjan tai blogipalvelun kaatuessa rahoitusvaikeuksiin tai laiterikkoon, häviää käyttäjän ”kallisarvoinen” tieto. Esimerkiksi GMailista omien sähköpostien tallettaminen on hankalaa ja Tumblr -blogipalvelusta, Flickr -kuvapalvelusta, Snipplr -koodiotteista, Moozement-urheilupäiväkirjasta tai Sports Tracker -urheiluseurannasta on turha varmuuskopiointimahdollisuutta etsiä. Vastaavasti muun muassa WordPress -blogipalvelusta ja Delicious-kirjainmerkkipalvelusta voi oman sisältönsä ottaa kätevästi talteen.

Tietenkin Webissä on lukuisia palveluita, joiden sisällöllä ei ole juurikaan arvoa myöhemmin, joten menetyksen arvo ei ole kovin suuri. Tällaisia ovat muun muassa tiettyyn ajan hetkeen sidottut palvelut, kuten Facebook-yhteistösivusto ja Twitter -lyhytviestin tai ”portfolio-sivustot” kuten LinkedIn -verkostoitumissivusto. Monien foorumeiden keskusteluiden tai Wiki-tyyppisten sivustojen osalta sisällöllä on merkitystä myöhemminkin, mutta yhteisöllisestä luonteesta johtuen se on kollektiivista omaisuutta.

Tiedon turvaamisen näkökannalta Web-palvelut eivät paljoa eroa perinteisistä työpöytäsovelluksista ja vastuu on aina käyttäjällä. Muista siis ottaa varmuuskopiot, jos tieto on sinulle arvokasta.

Joustavat sisennykset selkeyttävät koodin lukemista

Ohjelmoijat ovat usein erittäin pikkutarkkoja siitä, miten he kirjoittamansa koodin jäsentelevät: käytetäänkö sisennyksessä tabulaattoria vai välilyöntejä, miten asiat rivitetään, tuleeko sulkeiden jälkeen väli vai ei ja niin edelleen. Teoreettisesti koodi on samaa, jäsenteli sen miten halusi, mutta käytännössä koodin lukeminen on huomattavasti helpompaa, jos se on rakenteeltaan selkeää ja yhdenmukaista.

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.

Tab Stops

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

Tab Stops

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.

Rätinää ja räimettä elokuvateatterissa

Elokuvissa käyminen on jotenkin aina yhtä hankalaa, kun ensin pitää valita kiinnostava elokuva, sopiva esitysaika ja varata liput ennakkoon tai toivoa, että salissa on vielä kelvollisia penkkejä jäljellä. Vastineeksi tosin saa ison ruudun, isosti tehosteääniä, mukavan penkin ja enemmän tai vähemmän kanssakatsojia. Onneksi elokuviin lähtemistä oli pakottamassa joululahjaksi saamani elokuvaliput, joiden kelpoisuusaika oli uhkaavasti hupenemassa käsiin.

Leffavalintani osuivat alkuvuoden toimintapläjäyksiin eli Terminator Salvation, Star Trek ja Transformers: Revenge of the Fallen -elokuviin, jotka pohjasivat aikaisempiin elokuviin ja tarjosivat siis tuttua tarinaa. Valinnat eivät pettäneet, mutta eivät juuri yllättäneetkään, sillä ruudulta sinkoili runsaasti tehosteita ja köykäisesti rakennettua tarinaa. Toisaalta, kyseisiltä elokuvasarjoilta on muuta hieman vaikea odottaakaan, joten elokuvat tarjosivat mitä lupasivatkin.

Star Trek oli ihan mielenkiintoinen, kun tarina kertoi U.S.S. Enterprisen miehistön syntytarinan, vaikkakin Kirkin nuoruus oikaistiin hieman kömpelösti. Terminator Salvation vastaavasti ei visuaalisia efektejä ja toimintaa lukuun ottamatta juuri kelvollista juonta tarjonnut, mutta oli sentään kolmatta Terminatoria hieman parempi. Transformers: Revenge of the Fallen oli tiukkaa visuaalisesti näyttävää toimintaa ja tarinaan oli saatu myös hieman huumoria, jonka mielekkyydestä voi olla montaa mieltä. Ihan viihdyttävää katsottavaa kaikki tyynni ja pari tuntia per elokuva kului nopeasti.

Alkuvuodesta kirjoittelin vuoden 2009 leffatarjonnasta ja listalla olisi vielä paljon katsottavaa ja odoteltavaa. Saa nähdä mitä elokuvia sitä elokuvateatteriin viitsii vielä lähteä katsomaan.

Ikäviä totuuksia projekteista

Tony Collins IT Projects -blogista on listannut parikymmentä totuutta IT-projekteihin liittyen ja ikävän todelta useat listan kohdista ovat parin vuoden aikana osoittautuneet olevan. Listassa on kyllä useita kohtia, jotka ovat hieman yliampuvia. Tässä muutama oma poiminta listalta.

  1. Projekti myöhästyvät aina alkuperäisestä suunnitelmasta
    • Useat projektit ovat jo lähtökohdiltaan suunniteltu liian tiukalle aikataululle, mutta edellisistä projekteista harvoin opitaan ja aina yritetään puskea eteenpäin mahdottomilla aikatauluilla.
  2. Alkuvaiheessa pitäisi keskittyä löytämään oikeat kysymykset
    • On parempi aloittaa sovelluskehitys selvittämällä, mitä oikeasti ollaan tekemässä ja mitä asiasta pitäisi kaikkiaan tietää. Heikoilla alkutiedoilla aloitetaan tekemään turhaa työtä ja myöhemmin asioiden muuttaminen on aina hankalampaa.
  3. Käyttäjä on henkilö, joka hylkää järjestelmän, koska se on mitä haluttiin
    • Välillä projekteissa tuntuu, että ollaan kehittämässä järjestelmää, joka tekee kaiken mahdollisen, mutta ei kokonaisuutena ole kuitenkaan sellainen, jota asiakas halusi. Tietenkin asiakkaan toiveita ja vaatimuksia toiminnallisuuksien suhteen on kuunneltava, mutta kaiken mahdollisen toteuttamisessa ei välttämättä ole järkeä.
  4. Onnistuneen ja epäonnistuneen projektin ero on hyvässä tiedottamisessa
    • Kommunikaatio ja tiedottaminen projektin eri osapuolien välillä on tärkeää ja sen merkitys korostuu, kun projekti alkaa menemään sivuraiteille ja aikataulut venyvät.
  5. Mikään ei ole mahdotonta henkilölle, joka ei joudu sitä tekemään
    • Kaikki on mahdollista ja usein helppoa, ainakin sellaisen henkilön mielestä, joka asiaa ei joudu käytännössä toteuttamaan. Kaikkia ominaisuuksia ei vain voi, eikä kannata sovellukseen toteuttaa.
  6. Alkuperäiset suunnitelmat muuttuvat aina
    • Projektin edetessä sovellukselta vaadittavat ominaisuudet tarkentuvat ja ne usein tarkoittavat alkuperäisten määrittelyiden ja suunnitelmien muuttamista. Mitä aikaisemmin muutostarpeet havaitaan, sitä helpompi on on sovellukseen viedä.
  7. Koskaan ei ole riittävästi aikaa, joten tee se kerralla oikein
    • Kun asiat tehdään kerralla oikein, ei niihin tarvitse myöhemmin palata ja muuttaa toimintoa, joka mahdollisesti vaikuttaisi moneen muuhun sovelluksen osaan ja dominoefekti olisi taattu.
  8. Koskaan ei ole riittävästi aikaa tehdä se ensimmäisellä kerralla kunnolla oikein
    • Jos asiat tehtäisiin kerralla kunnolla, ei niitä tarvitsisi myöhemmin ”korjata”, mutta koska projektin aikataulut ovat tiukkoja, tehdään asiat ”kunhan toimii” ja ”viimeistellään kun on aikaa”. Etenkin dokumentointi on usein tällainen asia.
  9. Ymmärsit mitä sanoin, et mitä tarkoitin
    • Kommunikoinnin merkitystä projekteissa ei voi yliarvioida, sillä sitä on aina liian vähän.
  10. Jokainen haluaa vahvan projektipäällikön, kunnes saavat sellaisen
    • Projektipäällikkö on projektin johtohahmo ja suuri osa projektin toimivuutta. Heikko projektipäällikkö ei vedä projektia eteenpäin riittävällä voimalla ja useat asiat jäävät ilmaan. En ole vielä vahvaa projektipäällikköä tavannut, joka sanoisi asiakkaallekin vahvasti takaisin, joten jään innolla odottamaan.
  11. Projektit eivät epäonnistu lopussa, ne epäonnistuvat määrittelyssä
    • Projektin alkuvaiheet ovat projektin tärkeimmät vaiheet, ja jos projektin määrittelyä ei hoideta kunnolla, voi sovelluskehitystä verrata kerrostalon rakentamiseen suomaalle. Paalutetaan perusta, kun rakennus on jo kallistumassa.
  12. Vaikein tie on usein helpoin
    • Tekemällä kaikki asiat aina helpolla ja totutulla tavalla, ei hyödynnetä kaikkia mahdollisuuksia. Joskus kannattaa käyttää aikaa vaikean asian tekemiseen, sillä se voi myöhemmin palkita.
  13. Realisti on henkilö, joka on kaukonäköisesti pettynyt tulevaisuudessa
    • Etenkin projektien suhteen, kannattaa jo ennakkoon olla skeptinen projektin sujuvuudesta ja kaikkien osa-alueiden toimivuudesta. Projekti menee kuitenkin pitkin mäntyjä, ainakin joltain osin.

Mozvoikko-lisäosa PowerPC Mac OS X:lle

Sain viimeinkin iBookkini käyttöön hieman pidemmäksi aikaa ja ehdin kokeilla Firefoxin suomen kielen oikoluku -lisäosan eli mozvoikon kasaamista myös PowerPC-alustalle. Hyvinhän se onnistui ja tuntui toimivan Mac OS X 10.4 Tigerissa.

Muutamia muutoksia piti mozvoikkoon tehdä uuden alustan lisäämisen suhteen ja hieman konfiguraation jälkeen viritellä käsin libvoikon config.h-tiedostoa, mutta yleisesti ottaen aika sulavasti käännös sujui. Muutoksista löytyy kaksi vaihtoehtoista muutostiedostoa, mozvoikko-r2711_osx-ppc.diff_a.txt ja mozvoikko-r2711_osx-ppc_b.diff.txt, jotka molemmat tekevät käytännössä saman asian.

Yhdistelin samalla hieman mozvoikon kasaamiseen liittyviä muistiinpanojani sisältämään sekä Intel-alustalle että PowerPC-alustalle tapahtuvan käännöksen. Varsinaisen käännöksen eli Firefoxin ja lisäosan kääntämisen tein Intel-alustalla.

Lopputuloksena oli siis Suomen kielen oikoluvun sisältävä mozvoikko-1.0-Darwin_ppc-gcc3.xpi -laajennus, joka asentui sopuisasti Firefoxiin ja näyttäisi toimivan iBookissani Mac OS X 10.4 Tigerin kanssa. Lisäosaa voi kokeilla omalla vastuulla.

Asiasta lisää mozvoikko-alasivulla.

Muutamia LaTeX-vinkkejä

LaTeXilla kirjoittaminen ei ole kovinkaan yksinkertaista, jos tekstin lisäksi haluaa myös hieman erikoisempia rakenteita tai kuvia. Onneksi Internetistä löytyy paljon ohjeita ja yksi hyvä lähde on ”Pitkänpuoleinen johdanto LaTeXinkäyttöön: Eli opi LATEX 2ε 133 minuutissa” (pdf).

Helpointa LaTeXin lähestyminen on käyttämällä jotain valmista dokumenttipohjaa kuten Tapio Leppälammen Thesis-pohjaa (zip, 23KB) tai Mikko Hämäläisen Thesis -pohjaa. Mallipohjista voi katsella eri menetelmiä toteuttaa asioita ja soveltaa omiin tarpeisiinsa. Etenkin Leppälammen mallipohjassa on hyvin käsitelty eri asioiden toimivuutta LaTeXissa, vaikkakin lähtökohta on matemaattispainotteiseen dokumenttiin.

Tässä muutamia vinkkejä, jotka ovat itsellä tulleet eteen. Lista täydentynee, kun ongelmakohtia ilmenee.

Kuvien liittäminen dokumenttiin
Kuvien liittäminen LaTeX-dokumenttiin ei ole niin yksinkertaista kuin mitä sen haluaisi olla. LaTeX osaa helposti käsitellä eps-formaatissa olevia kuvia, mutta kaikkia kuvia ei ole järkevää muuntaa eps-muotoon.

Kuvia voidaan liittää onneksi myös muissa formaateissa, kun dokumentti käännetään PDFLatexilla, joka syö tutumpia PNG, JPG ja PDF -tiedostoja. Tämä onnistuu määrittelemällä grafiikat \usepackage[pdftex]{graphicx} -pakettikomennolla. Tämän jälkeen ei tosin Latexilla kääntö enää onnistu, eli DVI ja PS -muotoiset dokumentit jäävät saamatta, mutta koska PDFLatex tuottaa lopputuloksena PDF:iä, ei muita formaatteja tarvitakaan.

Lyhyesti sanottuna, kuvan liittäminen dokumenttiin onnistuu \includegraphics[scale=0.8]{kuvahakemisto/kuva} -komennolla, jossa voi lisäksi määritellä esimerkiksi skaalauksen scale-parametrillä. Skaalausta voi myös tehdä sisällyttämällä kuvan \scalebox{0.8}{} -laatikkoon.

Kuvien sijoittuminen dokumentissa onkin sitten aivan toinen asia. Hyvänä sääntönä voi kuitenkin pitää, että kuva ei ainakaan tule siihen kohtaan, johon sen haluaisit. Asiaan on opastettu hyvin ”Pitkänpuoleinen johdanto LaTeXin käyttöön” -oppaassa.

Taulukot
Taulukoidenkin kanssa joutuu hieman askartelemaan ja taiteilemaan, joten kannattaa lukaista ohje Wikibooksin LaTeX-kirjasta.

Kaavioiden otsikot ja viittaukset
Taulukoiden, kaavioiden ja kuvien yhteydessä, on dokumentteihin hyvä lisätä myös otsikkoteksti ja viittauskenttä. Kaavio merkitään \begin{figure} -alueen sisälle ja lisätään otsikkoa varten \caption{} -merkintä ja viittaukseen \label{} -merkintä. Nyt haluttuun kaavioon voi viitata tekstissä \ref{fig:kaavio} -merkinnällä, joka lisää tekstiin kaavion numeron. (LaTeX/Floats, Figures and Captions)

\begin{figure}[!h]
	\includegraphics{kuvahakemisto/kuva}
\caption{Kaavion otsikkoteksti}
\label{fig:kaavio}
\end{figure}

Usean rivin kommentti:
Tekstin jättäminen kommentiksi dokumenttiin onnistuu lisäämällä rivin eteen % -merkki tai merkitsemällä teksti comment-alueeksi. Komento löytyy \usepackage{verbatim} -paketista.

\begin{comment}
Lorem ipsum
Dolor sit
\end{comment}

Viitteet
Viittausten hallinta on LaTeXissa hoidettu kätevästi ja siitä kannattaa lukea Wikibooksin LaTeX-teoksen viite-osiosta. Kaikki viitteet saa tulostumaan käyttämällä \nocite{*} -merkintää.

UTF-8 -merkistöllä kirjoittamista varten määritellään tekstin enkoodaus seuraavasti:

\usepackage[utf8]{inputenc}
\usepackage[T1]{fontenc}

Kuitenkin, jos aikoo kirjoittaa dokumenttia eri alustoilla, etenkin myös Windowsilla, kannattaa tyytyä suosiolla perinteiseen Latin1 (ISO 8859-1) -merkistöön.

Futurama palaa ruutuun vuonna 2010

Matt Groeningin ja David X. Cohenin huumorin ystävät saavat ensi vuonna iloita, sillä Comedy Central on julkaissut tiedotteen, jossa kerrotaan Futuraman palaavan ruutuun 26:lla uudella jaksolla vuoden 2010 puolessa välissä, yli kuuden vuoden tauon jälkeen.

TV-sarjan loputtua DVD:lle julkaistut noin puolitoista tuntiset ”Bender’s Big Score,” ”The Beast with a Billion Backs,” ”Bender’s Game” ja ”Into the Wild Green Yonder” eivät oikein yltäneet TV-sarjan tasolle, sillä Futuraman huumori sopii paremmin TV-sarjan mittaisiin annoksiin. Saa nähdä, riittääkö tarinassa vielä samanlaista intoa, kuin aikaisemmin, vai jääkö lopputulos laimeaksi. Hieman toiveikas pitää olla, vaikka samojen tekijöiden Simpsonien huumori ei enää jaksa oikein innostaa.