HOWTO compile examples from "Essential Math for Games and Interactive Applications" on OS X 10.6

I just spent a hour and a half trying to figure out how you compile the example projects from the book Essential Math for Games and Interactive Applications (second edition) on Mac OS X 10.6. It seems that the new version of GCC included with 10.6 is stricter when it comes to following the C++ standard. For the posterity, here is how you compile them now:

Step 1

On line 204 of /common/IVGraphics/OGL/IvRenderOGL.cpp, change GLvoid to void.

Step 2

When compiling, use the following command instead of the one provided in README_MAXOS.txt:

make CFLAGS_EXT='-fvisibility-inlines-hidden -ffriend-injection' PLATFORM=OSX

Mitä Paul Graham voi kertoa meille web-standardeista

Toisinaan on tullut mietittyä minkä takia web-standardien omaksuminen tuntuu tekevän niin tiukkaa joillekin ihmisille. Pari päivää sitten tuli mieleeni, että tällä voi olla jotain tekemistä Blub-paradoksin kanssa.

Kirjoituksessaan Beating the Averages, entinen ohjelmoija ja nykyinen sovelluskehittäjä Paul Graham perustelee sitä että Lispiä harvemmin käytetään, vaikka se tunnetaan erittäin ilmaisuvoimaisena ohjelmointikielenä. Graham itse on Lisp-guru ja hän pystytti sitä käyttäen Viawebin, maailman ensimmäisen verkkokauppoja palveluna tarjonneen yrityksen.

Grahamin Blub-paradoksin voisi ehkä muotoilla toisin sanoin seuraavasti: Oletetaan ohjelmointikieli nimeltä Blub, joka ei ole maailman tehokkain kieli muttei myöskään maailman tehottominkaan kieli. Blubia osaava ohjelmoija ei voisi kuvitellakaan käyttävän vähemmän tehokasta kieltä, sillä niistä puuttuu ominaisuus X (missä X kuvaa jotain Blubin ominaisuutta jota kyseinen ohjelmoija käyttää päivittäin). Toisaalta vain Blubin hyvin tunteva ohjelmoija ei myöskään liiemmin välitä tehokkaammista kielistä, ne näyttävät hänestä lähinnä siltä kuin Blubiin olisi lisätty jotain turhuuksia. Riippumatta siitä mihin kohtaan ohjelmointikielten tehokkuuden jatkumoa Blub kiinnitetään (ääripäitä lukuunottamatta), ohjelmoija jonka tiedot pääasiassa rajoittuvat Blubiin harvemmin tuntee tarvetta opetella tehokkaampia kieliä.

Tämä tuo minulle mieleen web-standardien tilanteen: CSS-taiton hyötyjä näyttäisi olevan vaikea selittää taulukkotaittoon tottuneille ihmisille erityisesti siksi, että vaikka hyötyjä yritettäisiinkin listata heille, heidän taustatiedoistaan on enemmän apua haittojen kuin hyötyjen ymmärtämiseen ja he pitävät siksi koko juttua jonkinlaisena akateemisena säätämisenä.

Otetaan esimerkiksi selainyhteensopivuusongelmat. Taulukkotaittaja miettii miten jotkut jaksavat puurtaa CSS-tiedoston parissa. CSS-taittaja puolestaan ihmettelee miten jotkut jaksavat sisäkkäisten taulukkojen tuoman tagisekamelskan kanssa, erityisesti jos sivua pitää manipuloida JavaScriptillä.

Tai validointi. Validaattoria harvemmin käyttävä henkilö miettii miksi ihmeessä joistain "virheistä" pitäisi välittää kun sivu kerran toimii selaimessa. Validoinnin suurin hyöty on kuitenkin siinä että se tekee sivun käyttäytymisestä helpommin ennakoitavaa ja karsii omituisia ongelmia.

Oletetaan että Graham on oikeassa Lispin ja Blubin suhteen ja sama tilanne toistuu web-kehityksen yhteydessä. Mitä hyötyä tästä on? Aika vähän sellaisenaan, ilman että tiedetään mitkä puuttuvat taustatiedot ovat (tai millä muulla tavalla tietämysrakenteet eroavat toisistaan).

Ainakin jos mietin omia toimintatapojani, suurin ero "ennen web-standardeja" ja "web-standardien jälkeen" on siirtyminen arvauksista ja säätämisestä suunnitteluun ja säätämiseen. Ilman standardeja ja ilman CSS:ää lähdin liikkeelle kokeilemalla erilaisia erilaisia sopivantuntuisia tageja (elementeistä en tietenkään silloin ollut kuullutkaan) sopivantuntuisiin kohtiin kunnes saavutin halutun tuloksin. Nykyisin sen sijaan suunnittelen rakenteen lähes kokonaan päässäni, kirjoitan sen kerralla ja teen lopuksi korjauksia ainoastaan jos rakenteessa on jonkinlainen virhe tai selainbugeja tulee vastaan.

Onko tämä tavallista? Onko tämä merkitsevin ero? Vai onko kyse vain yksittäisestä tapauksesta? En tiedä.

Nokia E70 -kokemukset

Olen ehtinyt käyttää Nokia E70:ntä melko tarkkaan kuukauden ajan. Tiivistäen, käytettävyys ja ergonomia ovat erinomaisia, mutta rakenteellinen ja ohjelmiston toteutuksen laatu jättävät toivomisen varaa. Tässä hieman pidempi yhteenveto kokemuksistani:

The Good
- Tämän mallin "killer feature" on tietenkin avattava näppäimistö. Voin ilokseni kertoa että näppäimistö on varsin mukava käyttää. Kirjoitin koko tämän tekstin E70:llä eikä tehnyt tiukkaa.
- Näyttö on kirkas ja tarkka. Niin tarkka että pikseleitä ei enää erota.
- WLAN on nopea ja halpa tapa lähettää suuria tiedostoja.
- Sisäänrakennettu sähköpostiohjelma on aivan käyttökelpoinen.
- Videon- ja äänentoisto toimivat enimmäkseen kuten odotettua.
- Käytettävyysperiatteet kuten multimodaalisuus ja näkyvyys on otettu varsin hyvin huomioon.
- Moniajo onnistuu kätevästi niin kauan kun ei yritä ajaa selainta muiden ohjelmien kanssa.

The Bad
- E70 natisee turhan paljon. Ei niin paljon että sen puolesta pelkäisi mutta tarpeeksi paljon että se ärsyttää Apple-tuotteisiin tottunutta henkilöä. Vähemmän osia ja enemmän metallia, kiitos. Kuten eräälle tutulle totesin, tämä puhelin on enemmän Dell kuin Apple.
- Kännykkä kaatuilee tai antaa omituisia virheilmoituksia toisinaan älypuhelinominaisuuksia käytettäessä (videontoisto, web jne.).
- WLAN-yhteys ei ole saumattomasti integroitu: puhelin esimerkiksi tahtoo katkaista yhteyden sovellusta vaihdettaessa. Sopii ehkä perinteiseen datayhteysmaailmaan, mutta ei GPRS:n ja WLAN:in maailmaan.
- Kamera on kohinainen ja hidas oikeisiin kameroihin tottuneen henkilön näkökulmasta.
- Puhelin ei osaa toistaa kaikkia MP3-tiedostoja.
- Tekstin kokoa ei useinkaan voi pienentää. Toisinaan toivoisi voivansa hyödyntää suurta pikselimäärää ahtamalla ruudulle enemmän tavaraa.
- Sähköpostiohjelma ei sisällä automaattista uudelleenrivitystä eikä osaa tavuttaa.

The Inconsequential
- Äänivalinta ja -komennot toimivat 100% täsmällisesti. Niiden hyöty tulee kuitenkin olemaan vähäinen kunnes joku kehittää taskunkestävän Bluetooth-handsfreen.
- E70 ei näytä tietoa suhteellisesta edistymisestä akun latauksen aikana. Ei merkittävä ongelma, mutta Sony-Ericsson T300 näytti.
- Kännykässä on vain yksi kamera, joten videopuhelun soittaminen olisi hankalaa. En kuitenkaan usko soittavani videopuhelua ties kuinka moneen vuoteen.
- Ohjelmien asennus suoraan verkosta epäonnistuu usein. Hyvän Bluetooth-tuen takia tämä ei kuitenkaan ole suuri ongelma. (Content-Type on usein väärä eikä kännykän selaimesta löydy "Lataa muistiin"-toimintoa.)
- Nokia PC Suite ei tue Mac-koneita, eikä myöskään iSync tue E70:ntä. Ilmaisten ohjelmien (mm. Handbrake) ja standardien tiedonsiirtotapojen (Bluetooth 2.0, USB-massamuistitila, WLAN) tästä ei ole ollut minulle kuitenkaan paljoa haittaa. iCal- ja Address Book -synkronointia jää ehkä kaipaamaan.
- Eräät ominaisuudet kuten SIP-puhelut ("Internet-puhelut") eivät kuulemani mukaan toimi lainkaan. En käytä kyseisiä ominaisuuksia mutta ihmetyttää kuitenkin tuollainen toiminta.

The Rest
- Nokia E70 maksaa halvimmillaan 469 euroa, mikä on mielestäni paljon puhelimesta. Toisaalta E70 on Nokian edullisin täysin varusteltu älypuhelin (S60 3rd edition -alusta, WLAN, kamera).
- En tiedä olisiko teknisesti mahdollista lopettaa pelleily yhteysosoitteiden kanssa ja lähteä siitä että verkko kertoo puhelimelle täsmälleen mitä palveluja on käytettävissä. Toivottavasti on.

And now, the conclusion...
Oliko E70 järkevä ostos? Periaatteessa kyllä mutta käytännössä se on jättänyt minut kylmäksi. Seuraavat valintani olisivat olleet N73 (parempi kamera, ei näppäimistöä, ei WLAN:ia) ja N93 (paljon parempi kamera, ei näppäimistöä, paljon kalliimpi). Tuskin kuitenkaan lähiaikoina ryhdyn vaihtamaan mihinkään. Katsotaan sitten kun N83, N95 ja vastaavan sukupolven E-sarjalaiset ilmestyvät.

Voin kuitenkin suositella E70:ntä ilman sen kummempia varauksia sen viestintäominaisuuksia tarvitseville henkilöille. Lähinnä multimediasta kiinnostuneiden kannattaa arvatenkin kääntää katseensa N73:n suuntaan. Epävarmoja suosittelen odottamaan älypuhelinten seuraavaa sukupolvea. S60 3rd edition kärsii nykyisellään turhan pahoista lastentaudeista.

Hienolta kuulostaisi E70:n avautumismekanismi ja näyttö laitteessa joka on rakennettu N93:n materiaaleista ja tarkkuudella. Käyttömuistia tarvitaan lisää kumpaankin nähden, prosessori alkaa jo olla E70:ssä riittävä. Käyttöjärjestelmäksi S60 3rd Edition Feature Pack 1, kiitos.

Miten DVD siirtyy kännykkään

eli Handbrake-reseptejä Nokian uusille älypuhelimille

Satuin viime perjantaina siirtymään Sony-Ericsson T300:sta Nokia E70:een. Muiden ominaisuuksiensa lisäksi E70 sisältää tuen videoiden toistamiselle. Oikeiden ohjelmien ja asetusten löytäminen tämän ominaisuuden hyödyntämiseksi on kuitenkin aika työlästä. No, onneksi minä olen jo tehnyt sen puolestasi.

Tässä oppaassa hyödynnetään ilmaista ohjelmaa nimeltä Handbrake. Kirjoitushetkellä se on saatavissa vain Mac OS X -ympäristöön, mutta Windows-versio on nähtävästi työn alla.

Näillä ohjeilla tuotettujen videoiden pitäisi olla yhteensopivia ainakin seuraavien Nokia-kännyköiden kanssa: E60, E61, E70, N70, N71, N73, N80, N90, N91, N92, N93. (Tosin mainittakoon että N71, N73, N80, N91, N92 ja erityisesti N93 tukevat korkealaatuisempia videoita kuin joiden tekemiseen tämä opas antaa ohjeet.)

Handbraken käyttö on aika itsestäänselvää lukuunottamatta asetuksia. Suosittelen seuraavaa kahta asetussarjaa:

Resepti 1: Hyvä kompromissi

Destination
File format: MP4 file
Codecs: MPEG-4 Video / AAC Audio
File: (valintasi mukaan)

Video
Framerate (fps): Same as source
Encoder: XviD
Average bitrate (kbps): 384

Subtitles
Language: (valintasi mukaan)

Audio
Language 1: (valintasi mukaan)
Language 2: None
Sample rate (Hz): 44100
Bitrate (kbps): 128

Napauta Picture settings ja naputa kohtaa Width alaspäin kunnes se on tasan 320. Napauta Close. Varmista pituuksien perusteella että kohdan Title arvo on oikea ja napauta lopuksi Rip.

Resepti 2: Parempi kuvanlaatu

Muuten sama kuin resepti 1, paitsi:

Framerate (fps): 15
Average bitrate (kbps): 450

Lisäksi mikäli kännykkäsi on E60, E70 tai N80, voit laittaa Picture settingsiin leveydeksi 352. Tämä kuitenkin saattaa aiheuttaa koko näytössä toistettaessa ikävämmän näköisiä skaalausartifakteja kuin leveyden 320 käyttäminen. Makukysymys.

Minuutti videota vie reseptin 1 ohjeiden mukaan tehtynä noin 3,3 megatavua tilaa. Muuntaminen tapahtui 1,33 GHz PowerBookillani suhteella yhdestä kahteen minuuttia muunnosaikaa yhtä toistominuuttia kohden. Uudemmat koneet saattavat olla useita kertoja nopeampia.

Videoiden koon takia suosittelen siis USB-datakaapelin käyttöä. Vihjeenä kerrottakoon että Finder saattaa jumittaa kännykkää selattaessa. Tämän voi kiertää siirtämällä videon terminaalilla. Toinen hyvä tapa on käyttää koneeseen liitettävää kortinlukijaa. Kiireettömät henkilöt voivat tietenkin käyttää Bluetooth-tiedostonsiirtoa. Neljäs mahdollisuus on laittaa tiedosto lähiverkossa sijaitsevalle HTTP-palvelimelle ja kopioida se sieltä kännykän WLAN-yhteyden avulla.

Hyödyllisiä linkkejä:
- Video and streaming capabilities - Forum Nokia
- How to: convert iPod video for S60

Käytettävyysihminen käyttäjänä - junamatka opettavaisena kokemuksena

Ostin torstai-iltana pari lippua VR:n verkkopalvelusta. En ehtinyt käydä lunastamassa niitä samana iltana enkä perjantainakaan vielä aamupäivästä. Arvelin että viisitoista minuuttia olisi tarpeeksi aikaa selvittää mahdolliset ongelmat. Ehkä hiihtolomista johtuen oli asemalla kuitenkin niin suuri ruuhka että pääsin Junamaatille vasta pari minuuttia ennen junan lähtöä, itse asiassa lähtökuulutus tuli heti pari valintaa tehtyäni.

Systeemihän toimii siis siten että Internetistä ostetun lipun voi joko tilata kirjeenä, noutaa Junamaatista tai lipunmyynnistä, tulostaa kotona tai tilata matkapuhelimeensa (joissakin tapauksissa). Koska matkassa oli vaihtoja, ei ollut aikaa odottaa kirjettä eikä minulla ole tulostinta, valitsin noutamisen asemalta. Tällöin järjestelmä antaa koodin jonka syöttämällä automaatti tulostaa lipun.

Mutta takaisin Vaasan rautatieasemalle. Kauhukseni sain huomata että että järjestelmä ei ottanut vastaan kahta viimeistä koodiin kuuluvaa numeroa. Kokeilin paniikissa pari kertaa uudelleen, mutta kun tuloksena oli aina virheilmoitus, jouduin kiirehtimään junaan ja ostamaan uuden lipun konduktööriltä.

Jyväskylän asemalla kokeilin lunastaa liput uudelleen ja kaikki toimi kuten pitikin. Tajusin samalla mikä meni pieleen: valikossa on päällekkäin vaihtoehdot "Internetistä ostettujen lippujen tulostus" ja "puhelimessa ostettujen lippujen tulostus". Vaasassa katseeni oli ylemmässä ja oikeassa valikon kohdassa mutta painoinkin nähtävästi alempaa kohtaa vastaavaa painiketta ruudun viereltä. En huomannut virhettäni sillä valintaa seuraavat ruudut ovat enimmäkseen samannäköisiä. En toipunut virheestä sillä minulla oli kiire eikä mieleeni siksi tullut palata takaisin päävalikkoon.

Mitä käytettävyysongelmia tämä tapaus paljasti? Ensinnäkin, vaikka Internetistä ja puhelimessa ostettujen lippujen koodit ovat erilaiset, on niiden lunastamista varten kuitenkin nähty tarpeelliseksi tehdä kaksi eri ruutua. Toisekseen, eri toimintojen ruuduissa ei ole selkeitä eroja. Kolmanneksi, toisin kuin kosketusnäytössä, jouduin yhdistämään näytön vierellä olevat painikkeet ruudulla näkyvään valikkoon. Vaikka painikkeet ja valikko ovat aika tarkkaan kohdakkain, ovat virheet selvästi mahdollisia.

Tuntuu mahdottomalta että laitteita ja ohjelmistoa ei oltaisi lainkaan testattu, vaikkei varsinaisia käyttäjätestejä oltaisikaan vedetty. Sen sijaan testeissä arvatenkin mitattiin aikaa, sen sijaan että testihenkilölle olisi annettu realistinen aikaraja (tapauksessani alle kaksi minuuttia) jonka sisällä tehtävä pitää suorittaa. HCI-kirjoissa jätetään todella vähälle huomiolle se että käyttötilanteella saattaa olla aikaraja jolla ei ole tekemistä käyttäjän kärsivällisyyden kanssa. Lasken perjantain siis käytännön oppimisen ja inspiraation hankkimisen piikkiin.

(Minullehan tästä aiheutui vain suhteellisen pieni rahallinen vahinko, noin 10 euroa, sekä lievä harmi siitä etten ehtinyt ostaa Jyväskylästä ruokaa vaan jouduin turvautumaan eväisiin ja ravintolavaunuun. Mutta miten on nääntyvän opiskelijan laita, jolla ei välttämättä ole kaksikymppistä uuden lipun ostoa varten?)

Samassa hengessä on ehkä tehty kirjoitus Mobiilipalveluiden luvattu maa.

Eikö tekniikan pitänyt olla mahdollistaja?

Re: Vain oikeusjuttu riittää ja Target sued for poor accessibility.

Lukiessani Sitepointin keskusteluketjua en voi olla ihmettelemättä miten vähässä suhteellisuudentaju voi joskus olla. Täydellinen esteettömyys on usein todella vaikeaa ja kallista saavuttaa, mutta tietoa enimmäkseen tekstin muodossa välittävällä sivuilla kohtuullinen estettömyys saavutetaan mitättömillä kustannuksilla jos asialla ovat ammattilaiset.

Lisäksi vallalla näyttää olevan ajatus siitä että mikä tahansa vammaisuus tarkoittaa täydellistä kyvyttömyyttä minkäänlaiseen normaaliin elämään. Lukijan tehtäväksi jää miettiä kuinka järkevä ja kustannustehokas tuollainen näkemys oikein on.

Käyttörajoitteiden ihanuus

Ostin pari viikkoa sitten kaksi kappaletta iTunes-musiikkikaupasta kokeilumielessä. Aluksi asiat sujuivat hyvin, mutta kun tänä iltana yritin kuunnella toista kappaleista, sainkin seuraavan ilmoituksen:


Tämä huolimatta siitä ettei koneen konfiguraatiolle ole tapahtunut tietääkseni mitään edellisen vuorokauden aikana. Ja iTunesia olen kuullut kehuttavan DRM-teknologiaa eli käyttörajoitteita käyttävistä kaupoista kaikkein sujuvimmaksi.

Lisää tietoa käyttörajoitteista voi lukea hilpeästä sarjakuvasta tai EFFI ry:ltä.

Vääriä johtopäätöksiä

Jos olemassa yksi sääntö jota kaikkien ohjelmien pitäisi pystyä noudattamaan, olisi se että käyttäjää ei saa loukata. Virheilmoitus "sisäinen palvelinvirhe A8" on valitettava mutta anteeksiannettavissa. Sen sijaan "stupid user error" ei ole.

Ikävä kyllä erityisesti tietoturvan osalta näyttää vääriin johtopäätöksiin hyppääminen tavalliselta. Pari päivää sitten satuin erästä lomakettä täyttäessäni painamaan enteriä lähetyspainikkeen napauttamisen sijasta ja sain seuraavan ilmoituksen: "Hacking attempt! Your IP-address has been logged!" Viime vuonna olin päivittämässä vanhempieni käyttämää kirjanpito-ohjelmaa, joka vaatii joka vuosi uuden avainkoodin. Satuin kuitenkin ottamaan pinosta edellisen vuoden avaimet sisältäneen kirjeen. Niiden syöttämisestä oli tuloksena ilmoitus "LUVATON KÄYTTÖYRITYS! OHJELMA SULJETAAN!" ja ohjelma sulki itsensä (ei kovin suuri yllätys).

Ohjelmalla on yleensä käytössään niin pieni määrä tietoa että ihmisten syyttäminen mistään luvattomasta, laittomasta tai edes tyhmästä on riskialtista. Parempi pysyä faktoissa ja kertoa mitä on tapahtunut (sinulle ei ole myönnetty tarvittavia käyttöoikeuksia, syöttämäsi koodi on väärä, kuukauden tulee olla väliltä 1-12).

Metaverse.google.com

Nyt kun Firefoxin canvas-tuki on kunnossa, aikoo Vladimir Vukićević tutkia mahdollisuuksia yhdistää mukaan OpenGL-konteksti. Laitteistokiihdytettyä 3D:tä, JavaScriptillä ohjattuna, selainikkunassa. Arvatenkin mikäli tuloksena on jotain toimivaa, sovitaan yksityiskohdista Safarin ja Operan kehittäjien sekä suuren yleisön kanssa. Ensimmäinen yritys yhdistää Internet ja 3D ei oikein tuottanut tulosta, mutta ehkä tällä kertaa.

Joka tapauksessa, vaikka 3D-canvas olisi valmis jo huomenna, ei siitä olisi minulle liiemmin hyötyä. Kaksiulotteisuus sopii tarkoituusperiini paremmin ja ainoa sen käyttöä häiritsevä asia on IE-tuen puute. Olen useamman kerran miettinyt on, olisiko teknisesti mahdollista toteuttaa ActiveX-komponentti tai IE-selainlaajennos, jonka avulla IE saisi vastaavat ominaisuudet.

Ai mikä metaverse?

Turvallista HTML-syndikaatiota

Re: No, ask what Bloglines can do to you.

Juttu lyhyesti: Phil Ringnalda löysi XSS-haavoittuvuuksia kolmesta web-pohjaisesta uutisvirtalukijasta. Uutisvirran mahdollisesti sisältämä vahingollinen koodi pääsee luikertelemaan läpi lukijaohjelman suodattimista ja osaksi lukijaohjelman käyttöliittymänä toimivaa web-sivua. Kahdessa tapauksessa kolmesta Ringnaldan havaitsemat viat on jo korjattu, kolmas jostain syystä hidastelee.

Taustalla on se ikävä tosiasia, että useimpien HTML-koodia lähteestä tai toisesta vastaanottavien web-sovellusten suodattimissa on virheitä. Nämä virheet taas johtuvat siitä, että kyseiset suodattimet ovat useimmiten ad hoc -periaatteella kasattuja regex-listoja. Puolustukseksi sanottakoon, että tehtävä ei ole helppo: jo pelkästään standardien mukainen HTML 4.01 tarjoaa lukuisia paikkoja JavaScript-koodin piilottamiseen ja mukaan täytyy laskea erilaiset yksipuoliset selainlaajennokset*, on kasassa aikamoinen soppa.

Mikä siis neuvoksi, jos projekti vaatii ulkopuolisesta lähteestä tulevan HTML:än lisäämistä osaksi sivua, eikä turvallisuudesta myöskään saa tinkiä? Yksi vaihtoehto on kylmästi poistaa kaikki tagilta näyttävä ja laittaa loput saman koodausrutiinin läpi kuin kaikki muukin ulkopuolisesta lähteestä tuleva teksti. Toinen vaihtoehto on olla todella tiukka ja sallia vain taatusti harmittomia elementtejä ilman attribuutteja.

Muitakin vaihtoehtoja on ja se mitä suosittelen on jäsentelijän (tuttavallisemmin parseri) ja kirjoittajan yhdistelmä. Käytännössä siis otetaan sopiva jäsentelijä, annetaan sen muodostaa HTML-koodista puu ja käydään tuo puu lävitse, lisäten HTML-kirjoittajan puuhun ainoastaan sallitut elementit ja sallien attribuuteista ainoastaan hyväksytyksi määritellyt arvot. Kun tähän liitetään CSS-jäsentelijä, voidaan sallia myös joidenkin inline-tyylien lisääminen sisältöön. Kokonaisuuden viimeistelee sopiva kuvankäsittelykirjasto, jonka kautta palvelin välittää kaikki viitatut kuvat.

Ainoastaan todella paha tietoturvavirhe selaimessa tai kuvankäsittelykirjastossa voisi enää tehdä tästä hyökkäysvektorista toimivan. Mikäli niin halutaan, voidaan tuloksena olevan koodin taata myös olevan asianmukaisesti muotoiltua tai peräti validia XHTML:ää.

Koska ratkaisu on olemassa, miksi sitä ei sitten käytetä ja miksi Ringnalda löysi samankaltaisia haavoittuvuuksia kolmesta ohjelmasta sen kummemmin aivojaan rasittamatta? Ehkä tärkeimpänä, HTML:n jäsentely ei ole millään lailla hauskaa puuhaa, varsinkin mikäli ohjelman oletetaan pystyvän käsittelemään uskomattomin tavoin rikkinäistä koodia. Joitain avoimen ohjelmiston alaisia kirjastoja on olemassa, mutta näille kirjastoille harvemmin löytyy liittymää web-sovelluksissa suosituista skriptikielistä. Skriptikielellä kirjoitettu jäsentelijä olisi puolestaan uskomattoman hidas. Tämän tyyppinen ratkaisu olisi myös melko pakko toteuttaa kokonaisuutena, toisin kuin mainitut regexit, joiden määrä voi olla aluksi viisi, sitten kymmenen ja piakkoin viisikymmentä, mutta asian kimpussa tarvitse missään vaiheessa kuluttaa aikaa kyllästymiseen asti.

Jos tästä jutusta haluaa etsiä jonkin pointin, voisi se olla että tämä ongelma voidaan ratkaista hyvin pitävällä tavalla. Ikävä kyllä ratkaisu tulee vaatimaan merkittävän määrän C-koodausta, mikäli sillä haluaa olevan laajempaa vaikutusta. En kuitenkaan ihmettelisi lainkaan, jos jokin Mozilla Firefoxin selainlaajennuksina tarjotuista lukijaohjelmista toimisi jo tähän tapaan, kun kaikki tarvittavat kirjastot ovat jo saatavilla.

Jokaisen ohjelmoijan kannattaa puolestaan muistaa, että regexit ovat hyvä renki mutta huono isäntä. Jos joku ohjelman osa alkaa sisältää rivi rivin jälkeen regexejä, kannattaa harkita osan laittamista uusiksi.

* Erityisti voisi mainita Microsoftin dynamic properties-tekniikan, jota kavereiden kesken kutsutaan nimellä CSS expressions.