This blog is the product

Google Street View -julkkis

Googlen karttapalveluun päivitettiin vihdoin katunäkymä myös Suomeen. Kun kamera-autot pyörivät kotinurkillani, oli talon maalaus juuri kesken, ja onnistuinkin pääsemään kuvaan.

Jaa kirjoitus: Share on Facebook Tweet this Digg this! Save on Delicious

Googlen karttapalveluun päivitettiin vihdoin katunäkymä myös Suomeen. Kun kamera-autot pyörivät kotinurkillani, oli talon maalaus juuri kesken, ja onnistuinkin pääsemään kuvaan.

Kuka toimii puolestasi verkossa?

Twitter-viestit sovellusten luotettavuudesta aloittivat mielenkiintoisen ja tärkeän keskustelun siitä, mihin kaikkeen annamme lupaa erilaisille sovelluksille. Ehkä tärkeämpänä esimerkkinä tästä luotettavuudesta on viimeaikoinakin uutisissa palstatilaa saanut Balancion, verkkopalvelu joka hakee pankkitililtäsi tilitapahtumia ja analysoi näiden perusteella rahankäyttöäsi.

Balancionin tyylisten uusien sovellusten myötä on herännyt tarvet luottaa käyttämäänsä sovellukseen. Aikaisemmin riitti että sovellus toimi, sillä sai tehtävän tehtyä ja se ei mielellään kaatunut liian usein. Nyt otamme käyttöön erilaisia kolmannen osapuolen ohjelmistoja ja annamme niille luvan tehdä asioita puolestamme ja käsitellä yksityisiä tietojamme. Ei enää riitäkään että ohjelma ei kaadu, vaan meillä tulee olla riittävä luottamus siihen että sovellus tekee kertomansa asian, ja vain ja ainoastaan sen.

Useimmiten ongelmaksi nousee se, että sovellukset ovat suljettuja - emme voi nähdä niiden kokonaista toiminnallisuutta ja vaikka joissain tapauksissa voisimme (esim. open source -ratkaisut), on vain harvalle lähdekoodin julkaisemisesta konkreettista lisäarvoa tietämyksen kasvattamiseksi.

Toki Balancion on ääriesimerkki luottamuksesta, sovelllus päästetään kuitenkin pankkitiliin käsiksi. Kuitenkin jo monella suomalaisella internet-käyttäjällä luottamuksen antaminen on jokapäiväistynyt kiitos Facebookin. Facebookin sovellukset ovatkin loistava esimerkki siitä kuinka jatkuvasti annamme kolmannen osapuolen tekemälle sovellukselle luvan käsitellä tietojamme ja tehdä puolestamme asioita. Ongelma Facebookin kanssa on siinä että se on tehnyt luvan antamisesta jokapäivästä - suurin osa käyttäjistä ei varmaan edes mieti asiaa sen tarkemmin kun antaa luvan jollekin sovellukselle käsitellä tietojansa Facebookissa.

Kuitenkin Facebookin kehittäjä API on tehokas työkalu joka antaa paljon mahdollisuuksia kehittäjälle käsitellä käyttäjän tietoja, ja tehdä asioita käyttäjän puolesta. Kun sovellukselle on annettu lupa Facebookissa, voi se kerätä käyttäjästään valtavan määrän tietoa (josta tutkimalla meeting_for ja sex -kenttiä, voidaan periaatteessa päätellä jopa käyttäjän sukupuolinen suuntautuminen) ja pyytämällä hieman lisää oikeuksia sovellus taitaa voida lähetellä nimissäsi viestejä kaikille kontakteillesikin.

Ongelmallista Facebookin (ja muidenkin vastaavien) lähestymistavassa kolmannen osapuolen sovelluksiin on tapa esittää ensimmäisenä dialogi jossa pyydetään lupaa ja sen jälkeen viedä käyttäjä suoraan käyttämään sovellusta. Tämä ei missään vaiheessa anna käyttäjälle mahdollisuutta tutkia sitä, mitä sovellus oikeasti haluaisi tehdä. Toki tämän tekeminen eri tavalla (esim. sallimalla jokainen API-kutsu erikseen) olisi hieman hankalaa ja epäkäytännöllistä, mutta itse toivoisin hieman erilaista ratkaisua. Monesti jätän Facebook-sovelluksen auktorisoimatta vain siksi että en tiedä mitä se haluaa tehdä.

Toki Facebook on suurimmaksi osaksi vain leikkikenttä jossa emme pidäkään mitään tärkeää tietoa, mutta varmasti monella on sielläkin tietoa jota ei haluaisi joutuvan muiden käsiin. Facebook tekee myös pelottavaa pohjatyötä opettamalla käyttäjille toimintatapaa jossa sovelluksen annetaan käsitellä omia tietoja ilman tarkemmin asiaa miettimättä. Tarkista vaikka huviksesi että monta Facebook -sovellusta sinun profiilissasi on käytössä?

Ja kun olemme tähän tottunut, mitä sitten kun sovellukset jotka haluavat käsiksi pankkitiliimme tai muihin yleleistyvät? Kuinka moni antaa luvan sitten tähän tarkemmin miettimättä?

Jaa kirjoitus: Share on Facebook Tweet this Digg this! Save on Delicious

Twitter-viestit sovellusten luotettavuudesta aloittivat mielenkiintoisen ja tärkeän keskustelun siitä, mihin kaikkeen annamme lupaa erilaisille sovelluksille. Ehkä tärkeämpänä esimerkkinä tästä luotettavuudesta on viimeaikoinakin uutisissa palstatilaa saanut Balancion, verkkopalvelu joka hakee pankkitililtäsi tilitapahtumia ja analysoi näiden perusteella rahankäyttöäsi.

Balancionin tyylisten uusien sovellusten myötä on herännyt tarvet luottaa käyttämäänsä sovellukseen. Aikaisemmin riitti että sovellus toimi, sillä sai tehtävän tehtyä ja se ei mielellään kaatunut liian usein. Nyt otamme käyttöön erilaisia kolmannen osapuolen ohjelmistoja ja annamme niille luvan tehdä asioita puolestamme ja käsitellä yksityisiä tietojamme. Ei enää riitäkään että ohjelma ei kaadu, vaan meillä tulee olla riittävä luottamus siihen että sovellus tekee kertomansa asian, ja vain ja ainoastaan sen.

Useimmiten ongelmaksi nousee se, että sovellukset ovat suljettuja - emme voi nähdä niiden kokonaista toiminnallisuutta ja vaikka joissain tapauksissa voisimme (esim. open source -ratkaisut), on vain harvalle lähdekoodin julkaisemisesta konkreettista lisäarvoa tietämyksen kasvattamiseksi.

Toki Balancion on ääriesimerkki luottamuksesta, sovelllus päästetään kuitenkin pankkitiliin käsiksi. Kuitenkin jo monella suomalaisella internet-käyttäjällä luottamuksen antaminen on jokapäiväistynyt kiitos Facebookin. Facebookin sovellukset ovatkin loistava esimerkki siitä kuinka jatkuvasti annamme kolmannen osapuolen tekemälle sovellukselle luvan käsitellä tietojamme ja tehdä puolestamme asioita. Ongelma Facebookin kanssa on siinä että se on tehnyt luvan antamisesta jokapäivästä - suurin osa käyttäjistä ei varmaan edes mieti asiaa sen tarkemmin kun antaa luvan jollekin sovellukselle käsitellä tietojansa Facebookissa.

Kuitenkin Facebookin kehittäjä API on tehokas työkalu joka antaa paljon mahdollisuuksia kehittäjälle käsitellä käyttäjän tietoja, ja tehdä asioita käyttäjän puolesta. Kun sovellukselle on annettu lupa Facebookissa, voi se kerätä käyttäjästään valtavan määrän tietoa (josta tutkimalla meeting_for ja sex -kenttiä, voidaan periaatteessa päätellä jopa käyttäjän sukupuolinen suuntautuminen) ja pyytämällä hieman lisää oikeuksia sovellus taitaa voida lähetellä nimissäsi viestejä kaikille kontakteillesikin.

Ongelmallista Facebookin (ja muidenkin vastaavien) lähestymistavassa kolmannen osapuolen sovelluksiin on tapa esittää ensimmäisenä dialogi jossa pyydetään lupaa ja sen jälkeen viedä käyttäjä suoraan käyttämään sovellusta. Tämä ei missään vaiheessa anna käyttäjälle mahdollisuutta tutkia sitä, mitä sovellus oikeasti haluaisi tehdä. Toki tämän tekeminen eri tavalla (esim. sallimalla jokainen API-kutsu erikseen) olisi hieman hankalaa ja epäkäytännöllistä, mutta itse toivoisin hieman erilaista ratkaisua. Monesti jätän Facebook-sovelluksen auktorisoimatta vain siksi että en tiedä mitä se haluaa tehdä.

Toki Facebook on suurimmaksi osaksi vain leikkikenttä jossa emme pidäkään mitään tärkeää tietoa, mutta varmasti monella on sielläkin tietoa jota ei haluaisi joutuvan muiden käsiin. Facebook tekee myös pelottavaa pohjatyötä opettamalla käyttäjille toimintatapaa jossa sovelluksen annetaan käsitellä omia tietoja ilman tarkemmin asiaa miettimättä. Tarkista vaikka huviksesi että monta Facebook -sovellusta sinun profiilissasi on käytössä?

Ja kun olemme tähän tottunut, mitä sitten kun sovellukset jotka haluavat käsiksi pankkitiliimme tai muihin yleleistyvät? Kuinka moni antaa luvan sitten tähän tarkemmin miettimättä?

SQL-kyselyjen suorituskyvyn testaaminen kannattaa!

Tällä viikolla ohjelmassa on ollut pientä pellin alla -korjausta ja taustajärjestelmien hienosäätöä. Tähän on kuulunut mm. MVC-frameworkin M-osion hienosäätöä ja samalla kun kirjoitin uudelleen SQL-kyselyjä, pysähdyin hetkeksi miettimään miten asiat kannattaa tehdä MySQL:n kanssa. Tarkoitus oli tehdä kyselyä joka hakee tietokannasta tietyn mallin rivit, ja näihin kuuluvat muiden taulujen rivit (1...N -suhde). Aloin tekemään ratkaisua käyttäen LEFT JOIN:ia, kunnes ihmettelin kun kysely kestää ja kestää ja kestää....

Teinkin pienen testin, ja kokeilin kumpi on nopeampaa, käyttää LEFT JOIN -kyselymuotoa vai tehdä useampi kysely. Tein tietokantaan kaksi taulua, taulu1 ja taulu2.

Vaihtoehto 1: LEFT JOIN

Datasource::query("select * from taulu1 left join taulu2 on taulu1.id=taulu2.taulu1_id");

Vaihtoehto 2: Ilman LEFT JOIN:ia

$rows = Datasource::query("select * from taulu1");
foreach($rows as $row) {
    Datasource::query("select * from taulu2 where " .
          "taulu1_id=" . $row["id"]);
}

Taulu1 -tauluun syötetään 1000 riviä, ja taulu2 -tauluun syötetään 100 riviä jokaista taulu1:n riviä kohden, eli yhteensä 100 000 riviä.

Lopputulos: LEFT JOIN on merkittävästi hitaampi. Kysellessä kaikki rivit, ero on jopa n. 30-kertainen. Rajatessa kyselyn kokoa esim. 10:een taulu1:n riviin (jolloin tulosjoukko on 1000 riviä), vaihtoehto 1 vie 7 sekuntia koneellani kun vaihtoehto 2 vie alle sekunnin.

Jaa kirjoitus: Share on Facebook Tweet this Digg this! Save on Delicious

Tällä viikolla ohjelmassa on ollut pientä pellin alla -korjausta ja taustajärjestelmien hienosäätöä. Tähän on kuulunut mm. MVC-frameworkin M-osion hienosäätöä ja samalla kun kirjoitin uudelleen SQL-kyselyjä, pysähdyin hetkeksi miettimään miten asiat kannattaa tehdä MySQL:n kanssa. Tarkoitus oli tehdä kyselyä joka hakee tietokannasta tietyn mallin rivit, ja näihin kuuluvat muiden taulujen rivit (1...N -suhde). Aloin tekemään ratkaisua käyttäen LEFT JOIN:ia, kunnes ihmettelin kun kysely kestää ja kestää ja kestää....

Teinkin pienen testin, ja kokeilin kumpi on nopeampaa, käyttää LEFT JOIN -kyselymuotoa vai tehdä useampi kysely. Tein tietokantaan kaksi taulua, taulu1 ja taulu2.

Vaihtoehto 1: LEFT JOIN

Datasource::query("select * from taulu1 left join taulu2 on taulu1.id=taulu2.taulu1_id");

Vaihtoehto 2: Ilman LEFT JOIN:ia

$rows = Datasource::query("select * from taulu1");
foreach($rows as $row) {
    Datasource::query("select * from taulu2 where " .
          "taulu1_id=" . $row["id"]);
}

Taulu1 -tauluun syötetään 1000 riviä, ja taulu2 -tauluun syötetään 100 riviä jokaista taulu1:n riviä kohden, eli yhteensä 100 000 riviä.

Lopputulos: LEFT JOIN on merkittävästi hitaampi. Kysellessä kaikki rivit, ero on jopa n. 30-kertainen. Rajatessa kyselyn kokoa esim. 10:een taulu1:n riviin (jolloin tulosjoukko on 1000 riviä), vaihtoehto 1 vie 7 sekuntia koneellani kun vaihtoehto 2 vie alle sekunnin.

Mental note

Mental note: Debianin apt-get udpate voi pilata päiväsi. apt-get install ntp poisti 20 pakettia ja sen jälkeen totesi että "eihän tätä voi tehdä". Onneksi pakettien joukossa oli mm. libc6...

Jaa kirjoitus: Share on Facebook Tweet this Digg this! Save on Delicious

Mental note: Debianin apt-get udpate voi pilata päiväsi. apt-get install ntp poisti 20 pakettia ja sen jälkeen totesi että "eihän tätä voi tehdä". Onneksi pakettien joukossa oli mm. libc6...

Digitoday

Digitodayn kommenttipalstalla syvällinen argumentaatio on taas arvostettuna.

Miksi en osaa olla lukematta noita IT-medioiden kommenttipaltsoja? Huoh.

Jaa kirjoitus: Share on Facebook Tweet this Digg this! Save on Delicious

Digitodayn kommenttipalstalla syvällinen argumentaatio on taas arvostettuna.

Miksi en osaa olla lukematta noita IT-medioiden kommenttipaltsoja? Huoh.

Mainos