Taannoin Serverfaultin puolella törmäsin suorituskykyhuolestuneisessa kommentissa neuvoon '"Make it work first, make it fast later", as my professor told me'.

Köh.

Alkuperäinen kysyjä oli huolissaan siitä, onko normaalia että Symfony-frameworkin avulla tehdyssä yksinkertaisessa Hello World -sivussa kestää puoli sekuntia ennen kuin sivu parsiutuu -- tavallinen PHP:n läpi parsittu hello world suoriutuu satoja, jopa tuhansia kertoja sekunnissa melko köykäiselläkin nykypalvelimella. Kysyjä pohti sitä, onko Symfonysta mahdollisesti suurempaan webbipalveluun laisinkaan ja sai tuollaisen vastauksen.

Mitenköhän vastaaja ajatteli optimoida myöhemmin? Kajoamalla Symfonyn koodiin? Heh. Hyvä jos sen saa noin paljon nopeutettua jollain mustalla magialla, karu totuus vain on että aivan liian monet peruspilarit rakennetaan nykyään puolihuolimattomasti ja järkyttävän monimutkaisiksi.

* * *

KAIKKI NÄMÄ VUODET shellin parissa, enkä ollut ennen huomannut moista pientä yksityiskohtaa: painamalla ctrl+x+e avautuu parhaillaan shellissä muokattavana oleva rivi tekstieditorin puolelle. Avautuva tekstieditori on se, mikä on määritelty $EDITOR-ympäristömuuttujaan.

Että tällainen pikavinkki vaan. Toivottavasti tästä on hyötyä sinullekin. :)

Olen viime aikoina huomannut käyttäväni Googlen Chrome-selainta perussurffaukseen huomattavasti useammin kuin Firefoxia. Firefoxia iät ja ajat käyttäneenä olen samalla pohtinut, mistä tämä ilmiö johtuu. Ei Firefox minusta huono missään nimessä ole, mutta joku Chromessa on käännyttänyt minut sen käyttäjäksi.

Olisiko kyse sivujen taittonopeudesta? IT-uutisissa nykyään vouhotetaan koko ajan siitä, miten nopeasti mikäkin selain suoriutuu erinäisistä JavaScript-testeistä. "Selain x selvitti testin 300 millisekuntia edeltäjäänsä vikkelämmin!".

Suorituskyvyn lisääntyminen on iloinen asia, mutta ei tästä voi käännytyksessä olla kyse. Jokapäiväisessä surffaamisessa en ole eroa yleensä käyttämilläni sivuilla huomannut - yhtä hyvin YouTube-videot, uutissaitit, Facebook, bugzillat ynnä muut toimivat näillä yleisimmillä perusselaimilla, yleensä rajoittava tekijä on kaistannopeus.

Sitten tajusin sen.

Jos työnkuvasi on kuten minulla:

• Pääasiallinen työkalusi on ssh
• Ylläpidät isohkoa määrää palvelimia
• Työpäivän kuluessa olet tekemisissä niin kehityspalvelinten, testipalvelinten kuin tuotantopalvelintenkin parissa
• Vaihdos ylläolevien parissa saattaa tapahtua nopeastikin; esimerkiksi joku tulee selkäsi taakse pyytämään, että teetkö pienen muutoksen testiympäristön puolelle

Webbiselainten access-lokeja pähkiessä väkisinkin tulee mieleen, että paljonkohan botnetit oikeastaan vääristävät webbiselaintilastoja? Eivät välttämättä kovinkaan paljon isommilla sivuilla, mutta pienillä ja keskikokoisilla sivuilla tilanne voi hyvinkin olla toinen.

Ainakin jaba.mbnet.fi:n puolella on viime aikoina ahkerasti vieraillut usein jotain botnettejä(?), joiden user-agentiksi kerrotaan ulospäin tällaista:

Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1)

Joitain muitakin variantteja on. Joka tapauksessa oikeita selaimia/käyttäjiä nuo tuskin ovat; ip-osoite viittaa usein jonnekin todella eksoottiseen maahan, noista käsin yritetään postata kaikkea kuraa ja sivuja käydään läpi todella umpimähkäisen tuntuisesti ja linkkejä nopeaan tahtiin edeten.

Osuipa KDE:n kehittäjälistalla eteen mielenkiintoinen idea, joka ainakin osittain on menossa eteenpäin erään Google Summer of Code -projektin voimin.

Se nyt on ihan tavallista lähes käyttöjärjestelmästä/käyttöliittymästä riippumatta, että jonkun ohjelman kaatuessa on mahdollista lähettää bugiraportti eteenpäin. Bugiraportti sisältää kehittäjille tarpeelliset tiedot siitä, mikä käyttis on kyseessä, mitä tapahtui juuri ennen kaatumista ja miltä ohjelma kaatumisen aikaan näytti.

"Mitä ihmeen Amiga-vinkkejä tänne ilmestyi?", pohtii rss-lukijaansa tämän sivun syötteet itselleen tilannut lukija.

Ei hätää, kyseessä ei ole pysyvä ilmiö. Löysin vain sattumalta 90-luvun kotisivujeni Amiga-vinkit ja ajattelin pasteta ne tännekin jälkipolvien muistoksi. Ties, vaikka UAE:n käyttäjille, käytetyn Amigan ostajille tms. olisi noista jotain iloa.

A1200, Blizzardin 68060-kortti ja Squirrelin PCMCIA-väylään liitettävä SCSI-ohjain saattavat tuntua epävakautensa takia varsin hermoja katkovalta kokemukselta. Onneksi kaatuilu saadaan kuriin parilla pienellä niksillä.
Kopioi SquirrelSCSI.devicen 68060-päivitys HiSoftin kotisivujen takaa (www.hisoft.co.uk) ja hae Phase5:sen FTP-osoitteesta (ftp.phase5.de) beta/060-hakemistosta 68060.libraryn uusin versio. Näiden asentamisen jälkeen käynnistä SquirrelHDToolBox.

Valitse Partition Drive ja klikkaa namiskaa nimeltä Advanced Options.

Paina Change-nappulaa. Eteesi pitäisi ilmestyä uusi valikko.

Uudempien Amigoiden ROM-piireillä oleva FastFileSystem (FFS) ei tue vakiona kuin maksimissaan neljän gigan levyjä. Tämän vuoksi isompien levyjen asentaminen Amigaan vaatii pientä guruilua. Jos et ole onnistunut levyn installoimisessa, jatka lukemista.

Aivan alkuun urhea amigisti tarvitsee päivityksen sekä scsi.devicelle että FFS:lle. Käy noutamassa ne täältä.

Pura paketit ja kopioi FFS-päivityksen mukana tuleva FastFileSystem-tiedosto käynnistyslevysi L-hakemistoon. Kopioi SCSI-päivityksen mukana tulevat tiedostot vaikkapa C-hakemistoon ja lisää Startup-Sequenceen seuraava rivi:

LoadV43Module c:a300.ld.strip REBOOT

a300.ld.strip-tiedoston sijasta käytät luonnollisesti omalle koneellesi sopivaa patchia. Seuraavassa jokaiselle eri koneelle sopivat päivitykset:
a300.ld.strip ---> A1200 IDE
a600.ld.strip ---> A600 IDE
a1000.ld.strip ---> A4000[T] IDE
a4000t.ld.strip ---> A4000T SCSI
scsidisk.ld.strip ---> A3000[T]