Suhtaudu varauksella

En yleensä omista postausta vain yhdelle linkille ilman mitään aiheeseen liittyvää kommenttia. Seuraava tuloillaan olevia konsoleita käsittelevä artikkeli on kyllä sen arvoinen:

Smoke, mirrors and the next generation

Lyhyesti siis, suuri osa kaikesta Xbox 360:sta, PlayStation 3:sta ja mahdollisesti myös Nintendo Revolutionista kuulemastasi ei tule toteutumaan. Historialla kun on taipumus toistaa itseään.

Joitain muistiinpanoja ajastani Mac-käyttäjänä

PowerBook palasi huollosta pari viikkoa sitten. Kävin tänään noutamassa Kuopiosta Mac OS X 10.4 "Tiger" -päivityksen ja otan lähipäivinä koneen uudelleen päivittäiseen käyttöön. En kommentoi nyt vielä päivitystä, sillä en ole ehtinyt testaamaan sitä paljoa. Sen sijaan listaan muutaman viime vuoden aikana oppimani asian.

Kohta 1. Vaikka kaikki nykyiset Mac-mallit ovat erinomaisia tietokoneita, ovat jotkin niistä erinomaisempia kuin toiset. Elleivät tarpeet muuta sanele, suosittelisin valitsemaan kannettavan tästä joukosta: PowerBook 15", iBook 14" ja iBook 12". Omien kokemusteni ja kuulemani perusteella PowerBook 12" ja 17" eivät ole samalle asteelle viimeisteltyjä. Pöytäkoneisiin en ole perehtynyt tarkemmin.

Kohta 2. Mikäli vaihtoehtoina ovat nopeampi prosessori ja enemmän muistia, kannattaa valita muisti. Muisti kannattaa todennäköisesti tilata jostain muualta kuin Apple Storesta ja asentaa itse.

Kohta 3. Opiskelijoiden kannattaa hyödyntää opiskelija-alennukset. Vastoin yleistä luuloa, myös muillekin kuin Apple Developer Connectionin opiskelijajäsenille löytyy tuntuvia alennuksia niin laitteista ja ohjelmistoista. Saatavilla esimerkiksi 10.4-päivitys hintaan 89 euroa ja Final Cut Studio hintaan 629 euroa. Kun vain Adobe antaisi samanlaisia alennuksia...

Mitähän muuta... Optimaalinen hiiri sisältää yhden painikkeen ja vieritysrullan. Muu on lopulta turhaa. Vastoin yleistä luuloa, Macin käyttäminen ei välttämättä johda iPodin ostamiseen. Kokonaisuutena voisin sanoa, että olen varsin tyytyväinen asiakas. Kannatti vaihtaa.

Otsakkeiden lyhyt oppimäärä

Jokainen meistä on varmasti kuullut peruspiirteet siitä, miten HTTP-yhteys toimii. Selain tekee palvelimelle kyselyn (request), jonka perusteella palvelin tuottaa vastauksen (response). Kysely on esimerkiksi "anna minulle polussa /tuotteet/index.html sijaitseva resurssi" ja vastaus useimmiten "tässäpä tämä". Eli teknisemmin, GET /tuotteet/index.html HTTP/1.1 ja HTTP/1.1 200 OK .

Vähemmän tunnettua on, että niin kyselyn kuin vastauksen mukana seuraa koko joukko otsakkeita (header). Kyselyn otsakkeet kertovat erityisesti selaimesta ja sen tukemista tiedostomuodoista. Vastauksen otsakkeet puolestaan kertovan minkä muotoinen tiedosto lopulta palautettiin ja miten sitä tulisi käsitellä.

Ennen jatkamista on hyvä hankkia sopivat työkalut. Helpoimmalla pääsee käyttämällä Webissä sijaitsevaa kyselyntekijää, esimerkiksi tätä Rex Swainin tarjoamaa. Mozilla-pohjaisten selainten käyttäjät voivat myös ladata erittäin hyödyllisen LiveHTTPHeaders-laajennoksen, joka näyttää otsakkeet miltä tahansa sivulta, myös jälkikäteen. Melkein pakollinen väline Web-sovellusten kehittäjille, sanoisin.

Tämä juttu keskittyy enemmän vastauksen otsakkeisiin. Esimerkiksi Tampereen yliopiston etusivun eli http://www.uta.fi/ mukana seuraa tällainen rimpsu:

HTTP/1.1 200 OK
Date: Sat, 21 May 2005 18:38:17 GMT
Server: Apache/1.3.33 (Unix)
Last-Modified: Fri, 20 May 2005 11:51:10 GMT
ETag: "479a0-1578-428dcf2e"
Accept-Ranges: bytes
Content-Length: 5496
Connection: close
Content-Type: text/html; charset=iso-8859-1

Ensimmäinen rivi ei oikeastaan ole otsake, vaan tilarivi (status line) ja se jätetään myös tässä tarkastelun ulkopuolelle. Seuraavat merkitykseltään selvät otsakkeet käydään myös läpi nopeasti:

Date (palvelimen kellon aika lähetyshetkellä)
Server (palvelinohjelmistoa kuvaava määrämuotoinen rivi)
Accept-Ranges (ilmoitus siitä, että palvelin osaa pyydettäessä toimittaa tietyn osan resurssista)
Content-Length (vastauksen sisältöosan pituus tavuina)
Connection (close kertoo, että palvelin aikoo sulkea yhteyden vastauksen jälkeen, keep-alive tarkoittaisi palvelimen olevan valmis vastaanottamaan toisen kyselyn samalla yhteyskerralla)

Ensimmäinen erityisen mielenkiintoinen otsake on Content-Type. Otsakkeessa kerrotaan, minkä tyyppinen vastauksen sisältöosa on. Tässä tapauksessa palvelin kertoo palautetun tiedoston olevan tyypiltään text/html eli HTML-tiedosto. Se olisi voinut myös olla vaikkapa image/png eli PNG-muotoinen kuva. Esimerkkivastauksessa palvelin tarkensi vielä tyyppiä ja kertoi tiedoston merkkikoodauksen olevan ISO Latin 1.

Selaimen tulisi tunnistaa vastauksen tiedostotyyppi kokonaan Content-Type -otsakkeen perusteella, eikä esimerkiksi yrittää arvailla tiedostopäätettä kyselystä. HTTP:n näkökulmasta index.html on ainoastaan osa resurssin sijaintia (index piste html) eikä kerro mitään sen tyypistä. Luonnollisesti Internet Explorer toimi kauan väärin tässä asiassa, kunnes jokin Service Pack muutti tilanteen ja aiheutti harmia asiasta tietämättömille ylläpitäjille. Olisi ehkä kannattanut korjata palvelimen säädöt siinä vaiheessa kun Mozilla-käyttäjät valittivat asiasta.

Toisia tärkeitä tapauksia ovat Last-Modified, ETag ja esimerkistä puuttuva Cache-Control. Näiden käytännön vaikutus on välimuistien ja välityspalvelinten toiminnan sääteleminen.

Last-Modified kertoo, milloin resurssia muutettiin edellisen kerran. Kun selain tietää tämän, se voi seuraavan kerran tehdä ehdollisen kyselyn (conditional request), esimerkiksi "anna minulle resurssi jos se on muuttunut edellisen kyselyn jälkeen". Jos resurssi ei ole muuttunut, tulee paluupostissa tieto asiasta ja selain pystyy käyttämään välimuistista löytyvää kappaletta resurssista.

ETag sisältää entity tagin eli vastauksen sisältämää resurssia kuvaavan tunnisteen. Kun resurssi muuttuu, tulee myös sen entity tagin muuttua samalla. Selain pystyy tekemään ehdollisen kyselyn myös entity tagin pohjalta. Syvästi kiinnostuneiden kannattanee vilkaista liittyvää kohtaa RFC:stä, muiden kannattaa puolestaan unohtaa, että mainitsin koko entity tagit.

Cache-Control sisältää erityisohjeita siitä, saako vastauksen mukana saapuneen resurssin tallentaa välimuistiin, ja jos saa, niin millä ehdoilla. Jos otsaketta ei palauteta, käytetään oletuksia. Otsakkeen arvoista esimerkiksi public kertoisi, että resurssin voi tallentaa oletuksia laajemmin, private estää tallentamiseen jaettuihin välimuisteihin. Tiukin määritys on no-store, joka kieltää kaiken tallentamisen.

Palvelin pystyisi kertomaan myös esimerkiksi palautetun resurssin kielen (Content-Language), vanhenemishetken (Expires) ja minkä kyselyn otsakkeiden muuttuminen muuttaa palautettua resurssia (Vary). Muut otsakkeet ja linkit liittyviin HTTP/1.1-määrityksen kohtiin löytyvät helposti Jukka Korpelan kokoamasta listasta.

Mutta mitä hyötyä tästä tiedosta sitten on? Miksi sovelluksen kehittäjän tulisi välittää asiasta? No, oikeiden otsakkeiden palautaminen voi parantaa Web-sovelluksen käytettävyyttä, turvallisuutta ja nopeutta. Kuvien ja JavaScript-tiedostojen mukana kannattaa palauttaa tieto siitä, että ne saa tallentaa välimuistiin ja pitkäksi aikaa vieläpä. Tietylle käyttäjälle henkilökohtaisten sivujen mukaan voi liittää tietojen yksityisyysasteesta riippuen sopivat otsakkeet, esimerkiksi sähköpostia tuskin kannattaa koskaan jättää välimuistiin lojumaan. Merkkikoodaus kannattaa kertoa otsakkeissa, eikä vasta meta-elementissä, ettei selaimen tarvitse arvailla mitään. Content-Disposition -otsakkeella pystyy ilmoittamaan selaimelle, että resurssi tulisi tallentaa eikä näyttää.

(Kyselyn otsakkeiden perusteella voi myös esimerkiksi valita palautettavan resurssin kielen käyttäjän selaimen asetusten perusteella ja resurssin tyypin selaimen tukemien tyyppien perusteella. Tämä on kuitenkin laajempi aihe, jossa on omat sudenkuoppansa, ja se saa siis jäädä tältä kertaa väliin.)

PHP-kehittäjät voivat käyttää header-funktiota sivun mukana lähetettävien otsakkeiden säätämiseen. Otsakkeet tulee määrätä ennen kuin mitään sivun sisältöä tulostetaan.

RIA Toolkit, VB ja IWAS: hyviä ideoita, mutta eivät ehkä tarpeeksi hyviä

Re: Helmi jouduttaa surffausta.

Vaikka en olekaan erityisen innostunut Ajax-teknologiasta, tai tarkemmin sanoen en usko sen olevan sellainen mullistava ja käänteentekevä voima kuin luvattua, on sillä kuitenkin paikkansa. Ja näissä paikoissa ei välttämättä kannata lähteä liikkeelle puhtaalta pöydältä, vaan ottaa pohjalle jokin kirjasto. Yksi uusi tulokas on on Helmi Technologies -yrityksen Rich Internet Application Toolkit eli RIA Toolkit.

Mikäli ymmärrän oikein, kirjaston pohjana oleva Virtual Browser eli VB on "selain selaimen sisällä", JavaScriptillä luotu standardien mukainen pseudoselain. Tämä selain suorittaa ohjelmoijan kirjoittaman koodin, ohittaen selainyhteensopivuusongelmat. Päälle rakentuu Intelligent Web Application Structure eli IWAS, joka vastaa liikenteestä selaimen ja palvelimen välillä.

Mielestäni Virtual Browser on varsin hieno idea. Näin selainten erilaisuudet tulevat paremmin hallintaan, mutta toisin kuin aiemmissa tätä yrittäneissä kirjastoissa, ei uutta kolmannen osapuolen rajapintaa tarvitse opetella. Virtual Browserin rajapinta kun on ainakin yrityksen väitteiden mukaan täysin W3C:n standardien mukainen.

Ongelmana näkisin avoimuuden puutteen. Koska RIA Toolbox on puhtaasti kaupallinen tuote eikä ehtinyt pelinavaajaksi, on avoimen lähdekoodin tuotteilla jonkinasteinen etulyöntiasema osaajien, näyttöjen ja esimerkkikoodin suhteen. Helmi Technologiesin näkyvin demonstraatio on tällä hetkellä heidän omansa ja Visualway Designin sivustot. Mikä sopii Web-sovelluksiin ei välttämättä sovi Web-sivuille, eikä esimerkiksi Helmi Technologiesin sivuston Technology-sivulle voi linkittää suoraan. Jos lataa 4,9 megatavun PDF-esityksen, löytää yhden näkyvillä olevan demon sovelluksesta, eli PSOAS:in kohdekartan, joka on turhan jähmeä vaikkapa tähän verrattuna.

Avointa samantyyppistä ratkaisua etsivien kannattaa tutustua erityisesti Dojo Toolkit -projektiin ja SAJAX:iin (Simple Ajax Toolkit). Kaupallisena kilpailijana löytyy esimerkiksi Backbase.

Muokkaus 21.5.: Alkuperäisestä otsikosta tuli mielestäni hieman asiastani ohi menevä, eli RIA Toolkit, VB ja IWAS: hyviä ideoita, mutta ehkä jo myöhässä? ja vaihdoin sitä.

Ehkä selaimella kuitenkin on etuja

Re: Completely Rethinking the Web, erityisesti osio Desktop applications must replace Web applications.

Väite on seuraava: Web-sovelluksilla on puolellaan vain yksi etu, eli mahdollisuus käyttää niitä lähes miltä tahansa Internetiin liitetyltä koneelta, ilman minkäänlaista asennusta. Sen sijaan työpöytäohjelmilla on paljon etuja, kuten mahdollisuudet näyttää tietoa tehokkaammin, nopeammin ja tiheämmin, tehokkaammat vuorovaikutusmallit ja hienompi ulkoasu.

Tästä syystä Webin seuraaja tulee perustumaan tiedon ja vuorovaikutuksen erottamiseen. Esimerkiksi verkkokauppa toimii siten, että kauppias julkaisee tiedot saatavilla olevista tuotteista standardilla tavalla. Asiakas tutkii tuotteita ja tekee tilauksen hänelle parhaiten sopivalla verkkokauppaohjelmalla.

So far so good. Seuraava askel ketjussa herättää epäilyksiä. Syy vuorovaikutuksen erottamiseen on kokemuksen parantaminen ympäristöä kontrolloimalla. Eli verkkokauppaohjelma voi tarjota täydellisen kokemuksen, koska kaikki kokemuksen osat ovat ennalta määrättyjä, eikä selainta ole asioita sotkemassa. "That is the critical point: we need to begin controlling the environments that our work is being experienced in." (Lainaus artikkelin kirjoittajan kommentista.)

Hetkinen. Ymmärrän kyllä, että käyttöliittymien suunnitteluun kuuluu paljon luovuutta. Mutta jotenkin ajatus siistä, että käyttöliittymäsuunnittelijan työ pitäisi kokea tietyssä ympäristössä? Minun ajatusmaailmassani käyttöliittymällä ei ole vähääkään itseisarvoa. Käyttöliittymän tarkoituksena on olla hyödyllinen ihmisille tai organisaatioille. Se on käyttöesine, ei taidetta. Kokemus syntyy hyödyllisyyden sivutuotteena. Epäoptimaalinen kokemus on parempi, kuin ei kokemusta ollenkaan. EOR, End of Rant.

Artikkeli myös unohtaa, että Web-sovelluksen heikot mahdollisuudet "irtautua" selaimesta ovat samalla myös siunaus. Web-sovellus voi pakottaa hyvin vähän asioita, hallita käyttöympäristöä vain heikosti. Siispä sovelluksen käyttäminen ei edellytä erityisempää luottamusta sovelluksen julkaisijaa kohtaan. Jos sovellus alkaa kukkoilemaan, riittää selainikkunan sulkeminen ja pysyminen poissa sivustolta.

Samoin Webissä eri sovellusten ja sivustojen välillä liikkuminen tapahtuu yhtenäisen mallin kautta. Selain tarjoaa palveluja, joita sovelluksen kehittäjä ei välttämättä ole tullut ajatelleeksikaan. Milloin oikein saan välilehdet iTunesiin? Niinä harvoina kertoina kun olen iTunes Music Storea (iTMS) selannut, olen toivonut että voisin avata kappaleiden "sivuja" taustalle samoin kuin verkkokaupassa tuotesivuja. Olisiko välilehdillä tai vastaavalla ratkaisulla varustetulla musiikkikauppasovelluksella tarpeeksi kysyntää?

Web-selain on user agent eli käyttäjän edustaja, eikä tätä voi Web-sovelluksen kehittäjä muuttaa. Onneksi.

On myös kyseenalaista, voidaanko lopulta yhtä oikeaa sovellusta verkkokauppojen koluamiseen. Kun kaikki verkkokaupat tarjoavat sovellusliittymän, miten yksittäinen verkkokauppa voi erottua joukosta? Tarjoamalla oman sovelluksensa, tietenkin! Ja näin koneellani tulee olemaan asiakasohjelmat niin Amazon.co.uk:hon, Bookplus.fi:hin kuin Suomalaiseen kirjakauppaan, sillä jokainen tarjoaa hieman erilaisia extroja kuin toiset. Ja sinne se yhtenäisyys ja paras mahdollinen kokemus sitten hävisikin.

Ei siten, että Web varsinkin nykyisessä muodossaan olisi mielestäni ideaali tapa tehdä ostoksia verkossa. Ei siten, että näkemykseni tietokoneista olisi kylmä utilitarismi, kokemuksen kautta ajattelu on minulle tuttua. Mielestäni kuitenkin kuulostaa aikamoiselta non sequiturilta, että koska tietokoneen työpöytä on tiukemmin sovelluskehittäjän ohjaksissa, on se Webiä parempi ympäristö ottamaan ihmisyksilö huomioon.

Omituinen ongelma

Jostain syystä en pysty enää täydentämään edellistä postausta, joten laitetaan uudet linkit sitten tänne:

Poor Web Applications and Pre-fetch Security Issues, I'm sorry, I can't kiss it and make it better ja Only the paranoid survive.

Lisäys 7.5.: Vielä yksi, URIs, Addressability, and the use of HTTP GET and POST.

Googlen turbovaihteen ongelmat

Re: Google Web Accelerator: Hey, not so fast - an alert for web app designers.

Näyttää siltä, että Google Web Accelerator (lyhyesti GWA) aiheuttaa paljonkin harmaita hiuksia. Kyseessähän on ohjelma, joka yhtenä ominaisuutenaan lataa sivuja palvelimelta ennakkoon (engl. prefetch), valmiiksi välimuistiin napautusta odottamaan.

Hieman vastaava ominaisuus on löytyvät Mozilla-selaimista jo jonkin aikaa, mutta Mozillan ja Googlen toteutuksilla on yksi huomattava ero. Siinä missä Mozillat noutavat ennakkoon ainoastaan link-elementeillä erikseen osoitetut sivut, hakee GWA myös a-elementeillä viitattuja sivuja.

Tämä tietää pahaa erityisesti, mikäli sivustolla toteutetaan toimintoja GET-metodia käyttävien kyselyiden yhteydessä. Esimerkiksi jos jotain poistetaan napauttamalla linkkiä, ilman erillistä POST-metodia käyttävää lomaketta sisältävää vahvistussivua, saattaa GWA poistaa sen vahingossa. Tällainen käytänne ei ole HTTP/1.1 -standardin hengen mukainen, mutta varsin tavallinen nykyisinkin. Vähemmän tuhoisia vaikutuksia esiintyy esimerkiksi foorumeilla, joissa ennakkoon lataaminen saattaa merkata viestejä luetuksi vaikka kävijä ei olekaan niitä nähnyt.

Kaikki TLS- tai SSL-yhteyttä käyttävät sivut ovat ulkona niin GWA:sta kuin Mozillan ennakkoon lataamisesta. Palvelimen ylläpitäjä voi kieltää ennakkoon lataamisen palauttamalla koodin 403 mikäli kysely sisältää otsakkeen X-moz: prefetch . Mikäli tämän tekee koko sivustolleen, estyy tosin samalla myös tarkoituksella merkittyjen ennakkoon latausten toiminta. On kai myös mahdollista estää kyselyt IP-osoitteiden perusteella, sillä GWA hakee sivut Googlen palvelinten kautta. Linkit voi laittaa viemään vahvistussivulle oletuksena ja ohittamaan sivun, mikäli onclick-käsittelijä suoritetaan.

Ei ole vielä selvinnyt, miten Cache-Control -otsakkeet vaikuttavat GWA:n toimintaan. Luulisi, että mikäli sivu on private ja no-store, ei sillä olevia linkkejä kannata lähteä lataamaan. On myös epäselvää, annetaanko GWA-betan olla saatavilla nykyisessä versiossaan sen aiheuttamien ongelmien takia. Saattaa olla, että beta vedetään pois saatavilta ja tuodaan takaisin pienen virittelyn jälkeen.

Lisäys 7.5.: Nähtävästi GWA aiheuttaa tietoturvaongelmia, mikäli istunnot on sidottu IP-osoitteisiin eikä evästeisiin. Mielestäni tässä asiassa kuitenkin saavat sivustojen ja sovellusten kehittäjät syyttää itseään. Julkisessa Internetissä IP-osoitteisiin perustuvat istunnot eivät ole olleet järkeviä kymmeneen vuoteen. Erilaiset näkymättömät välityspalvelimet ovat aiheuttaneet vastaavia ongelmia jo kauan, tosin pienemmässä mittakaavassa. Intranetit ovat sitten eri asia, mutta niihin ei toisaalta GWA:llakaan ole pääsyä.

Hyvää vappua

Äh. Vielä on paljon opittavaa. Lasista katoaa pyöreys ja tausta näyttää jotenkin ikävältä. Lasista puuttuu myös täyte, sillä mitä sitä nyt hyvää simaa seisottamaan.