Yhteensopivuutta

Edellisessä jutussa valittelin ongelmia PHP:n asentamisessa MacBook Prohon. Nyt sain sen lopultakin onnistumaan.

En tiedä ovatko kaikki vaiheet pakollisia ja onko listalta mahdollisesti unohtunut jotain mitä yrityksen ja erehdyksen kautta tein, mutta tässä muutamia muistiinpanoja.

Käytin pohjana NetMusician Wikin hienoja ohjeita. Noudatin ohjeita muuten täysin, mutta olin jo asentanut MySQL 5:n virallisen binäärilevityksen, mikä aiheutti omat ongelmansa. NetMusicianin ohjeet on tehty PHP:n ja MySQL:n nelosversioita varten, mutta sen osalta ainoa tarvittava muutos oli vaihtaa neloset vitoseksi (esim. sudo port -v install php5 +apache +mysql5).

Asensin siis ensin ohjeiden mukaisesti duplikaatit Apachesta ja MySQL 5:stä. Sen jälkeen asensin PHP:n, mutta se ei toiminut, koska se yritti käyttää DarwinPortsin asentamaa MySQL:ää eikä sitä, joka minulla oli jo toiminnassa. Ratkaisuna oli ennen asennusta muokata Portfile-tiedostoa (/opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/www/php5/Portfile) riviltä 150 alkaen:

variant mysql5 conflicts mysql3 mysql4 {
	depends_lib-append	port:mysql5
	configure.args-delete	--without-mysql
	configure.args-append	--with-mysql=/usr/local/mysql \
							--with-mysql-sock=/tmp/mysql.sock \
							--with-mysqli=/usr/local/mysql/bin/mysql_config
	post-extract {
		file mkdir "${workpath}/mysql5"
		file link -symbolic "${workpath}/mysql5/lib" "/usr/local/mysql/lib"
		file link -symbolic "${workpath}/mysql5/include" "/usr/local/mysql/include"
	}
}

Jos muuten PHP:n asennus epäonnistuu libmcryptin tarkistussumman laskemiseen (kuten minulla tapahtui), ratkaisuna on muuttaa kyseisen kirjaston Portfile-tiedostoa (/opt/local/var/db/dports/sources/rsync.rsync.darwinports.org_dpupdate_dports/devel/libmcrypt/Portfile) ja poistaa master_sites-listasta ”sourceforge:”.

Tämän jälkeen PHP asentui kiltisti. Asennuksen jälkeen poistin juuri asennetun Apachen (sudo port uninstall apache) ja deaktivoin MySQL:n (sudo port deactivate mysql5). Nyt käytössä olivat käyttiksen oma Apache ja virallinen MySQL.

Sitten saa vielä nähdä, toimiiko kaikki vielä kun ensimmäisen kerran buuttaan tämän koneen…

Teknologiauutisia: Ruby on Rails, Alexa Web Search Platform, Google Homepage API

Symfony

Aloitin tänään Symfonyyn tutustumisen. Symfony on PHP5-kielellä tehty ohjelmistokehys (framework) web-sovellusten kehittämiseen. Ensivaikutelma on, että se muistuttaa kovasti suosittua Ruby on Rails -ohjelmistokehystä, tosin ohjelmointikieli on eri. Molemmissa pyritään toteuttamaan MVC-mallia mahdollisimman pitkälle. Sekä Symfonyssä että Railsissa apuna ovat komentoriviskriptit, joiden avulla koodia saa generoitua MVC-mallin mukaisesti, ja jotka vähentävät käsin tehtävän koodauksen määrää.

Symfony käyttää hyväkseen PHP:n PEAR-kirjastoa ja koko ohjelmistokehyksen asennuskin tapahtuu PEAR:n kautta. Railsin asennukseen käytetään vastaavaa menetelmää eli RubyGemsiä.

Nyt joulun alla Symfonyn saitilla julkaistaan joulukalenteria, jossa toteutetaan moderni web 2.0 -sovellus Symfony-kehyksen päälle. Se vaikuttaa hyvältä lähtökohdalta Symfonyyn tutustumiseen.

Yritin löytää netistä benchmarkeja Symfonyn ja Ruby on Railsin tehokkuudesta, mutta en löytänyt oikein mitään. Varmaankaan Symfony ei ole vielä lyönyt itseään läpi tarpeeksi. Olen ymmärtänyt, ettei Ruby on Rails ole varsinaisesti loistanut skaalautuvuustesteissä, joten olisi kiva tietää, millaisen vastuksen PHP-pohjainen ohjelmistokehys sille antaa.

Google Analytics ja Bad Behavior

Ihmettelin, kun Google Analytics edelleenkin näyttää visakopu.netin kohdalla ”Waiting for Data”, vaikka rekisteröitymisestä on jo useampi viikko. Tähän asti olen syyttänyt ongelmista vain Google Analyticsiä, mutta hetki sitten minulle valkeni, että syyllinen voikin olla Bad Behavior -laajennus, jonka olen tähän WordPressiin asentanut.

Bad Behavior pitää kommenttispämmääjät loitolla tarjoamalla niille eioota. Koska Google Analytics käy rekisteröitymisen jälkeen tarkkailemassa, milloin tarvittava JavaScript-koodi on syötetty sivun html:ään, saattaa Bad Behavior estää Analyticsiä huomaamasta koodia. Näin ollen käyttäjäseuranta ei ikinä edes pääse alkuun.

Kun Google Analytics on saanut selville että koodi on paikallaan, se ei ymmärtääkseni enää käy tutkimassa sivujen sisältöä, vaan kävijäseuranta tapahtuu käyttäjien ladatessa kyseisen JavaScript-koodin.

Google Analyticsin tukisivut eivät (tietenkään) kerro, mikä koodia tarkkaileva järjestelmä ilmoittaa serverille olevansa, mutta onneksi Bad Behavior pitää logia estetyistä yrityksistä. Logista löytyi merkintä ”selaimesta” Urchin/6.3.05, joka lienee Google Analytics. Palvelu on entiseltä nimeltään Urchin ja joiltain japaninkielisiltä sivuilta löytyi viittauksia siitä, että Google Analytics ja Urchin/6.3.05 ovat kytköksissä toisiinsa.

Lisäsin Urchin/6.3.05:n nyt Bad Behaviorin sallittujen listalle. Saa nähdä auttaako.

Samalla lisäsin listalle myös agentit FeedFetcher-Google; (+http://www.google.com/feedfetcher.html) ja Mediapartners-Google/2.1. Ensiksi mainittu liittyy Googlen RSS-lukijaan ja toinen AdSense-mainosjärjestelmään.

Päivitys 7.12.2005: Google Analytics valitti edelleen samaa asiaa. Nyt sinne oli ilmestynyt kellonaika, jolloin se on viimeksi käynyt tarkistamassa, ettei koodi muka ole paikoillaan. Otin koko hiton Bad Behaviorin pois päältä ja vaihdoin spämmisuojaksi Akismetin.

Mac OS X 10.4.3 ja Acid2

Apple julkaisi tänään Mac OS X 10.4.3 -päivityksen. En ole vielä sitä asentanut, mutta nörttejä kiinnostanee, että päivityksen jälkeen Safari läpäisee Acid2-testin. Testi mittaa, kuinka hyvin selain tukee uusimpia standardeja ja kuinka selain suoriutuu virheellisestä css-koodista.

Itse en ole Acid2:n hyödyllisyydestä kovin varma. Ainakaan se ei ole mittari siitä, kuinka hyvin normaalit www-sivut latautuvat, sillä testi sisältää hyvin erikoista css- ja xhtml-koodia. Varsinkaan se ei ole kunnollinen mittari silloin, jos selaimen koodi ainoastaan optimoidaan suoriutumaan Acid2-testistä, mutta unohdetaan kaikki ”tavallisten” sivujen ongelmat, joista selaimen pitäisi myös selvitä.

Acid2-tuki tehtiin Safarin lähdekoodiin jo huhtikuussa, joten tämän perusteella Applella kestää noin puoli vuotta saada koodiin tehty muutos läpi versionhallinnasta ja laaduntarkkailusta. Kriittisten bugien korjauksessa aikataulu on toki nopeampi.

Uudet sivut Googlen indeksiin nopeammin

Google Sitemaps on uusi tapa kertoa Googlelle saitille lisätyistä sivuista. Tähän asti on pitänyt odottaa, että Googlen hakurobotti käy tutkimassa sivuston ja huomaa uudet sivut. Google Sitemaps on tekniikka, jossa sivuston sisällöstä julkaistaan xml-tiedosto, jolloin hakurobotti helposti näkee muuttuneen sisällön. Hienointa on kuitenkin se, että kun sisältö muuttuu, Googlea voi pingata eli sille voi kertoa, että nyt kannattaa tulla indeksoimaan sivut uudestaan.

Käsin tuollaista xml-tiedostoa kukaan tuskin jaksaa ylläpitää, mutta onneksi ainakin WordPressin käyttäjille on olemassa helppo ratkaisu: Google Sitemaps Generator -niminen laajennus.

Laajennus luo automaattisesti sitemap.xml-tiedoston ja sen lisäksi siitä vielä gzipatun version kaistan säästämiseksi. Tiedostoon listataan automaattisesti kaikki blogikirjoitukset ja WordPressillä luodut sivut. Kun blogikirjoituksia tai sivuja lisätään, muokataan tai poistetaan, laajennus rakentaa xml-tiedoston uudestaan ja kertoo muutoksesta Googlelle. Jos saitilla on muitakin kuin WordPressillä luotuja sivuja, ne voi kertoa laajennukselle, jolloin nekin tulevat mukaan xml-tiedostoon.

Kirjanmerkkejä

Laitetaanpa tähän muutamia linkkejä ihan vaan muistiin itselle: