What else besides sailing?

Käyttöönottoon tuntuu aina liittyvän kaksi asiaa, mahdollisimman hiljainen ajankohta ja odottamattomat yllätykset. Mahdollisimman hiljainen ajankohta tarkoittaa yleensä Suomessa sunnuntai iltaa, etenkin viimeinen riipaisulle eli dns:ien päivitykselle hyvä hetkin tuntuu olevan sunnuntaina kello 19:00 jälkeen. Silloin tapahtuu harvoin mitään tuottavaa. Odottamattomat yllätykset taas voivat olla positiivisia tai negatiivisia. Negatiiviset liittyvät yleensä siihen että jokin ei toimikkaan odotetulla tavalla ja koska on viikonloppu niin ketään ei saa kiinni, eikä näin ollen asiaan eteenpäin tai korjattua. Yleensä tätä negatiivista kokemusta seuraa positiivinen kun plaan B toimii mukavasti. Niin se taisi mennä tälläkin kertaa. Tuntemukset oton jälkeen ovat odottavat, sitä jää jotenkin aina henkisesti odottamaaan ensimmäistä “tässä on virhe” ilmoitus. Niin nyt kannattaa vierailla http://www.tkrekry.fi ja löytää se ensimmäinen “tässä on virhe” ilmoituksen aihe.

Viikonlopun kokemukset

• Heroku – näytti jälleen hampaansa
• Ruby gems + shared hosting – aiheuttaa aina odottamattomia ongelmia
• Iso kiitos P.Rannikolle

Perusasetelma on että asiakkaalle haluttiin samanlainen haku toiminto kuin esim. http://areena-beta.yle.fi/haku Jolloin urlit pysyvät siisteinä ja hakukone ystävällisinä. Siitä että onko tämä paraskäytäntö tai tapa ei ole tässä yhteydessä oleellista. (tietenkin jos on vahvoja näkemyksiä niin ihmessä komentteihin )

Eli perus asetelma on:

Form  + http post -> parse params to url -> Header 303 -> http get: /haku/kissa (cache)  -> sivu palautetaan. Jolloin voidaan samaa hakutoimitoa ajaa myös suoraa http get: /haku/kissa . Kakku toimii ja kaikilla on hauskaa.

Radiant CMS käyttää versiosta 0.8 eteenpäin implemetaatiota Rack::Cache:sta joka on muuten vallanmainio laitos, mutta siitä ehkä myöhemmin.

Normaalista kaikki sujuu ihan hyvin, http get -> cache: etag/max-age= mukaan pyyntö eteenpäin tai palautetaan 304

Mutta http post -> cache: invalidate joka kutsuu  restore_response metodia metastore.rb:96 tässä kohtaa saadaa aikaa poikkeus joka johtuu siitä että hakua varten tehdyssä radiant sivutyypissä on muokattu tämä header hyppy ennen kuin pyynnölle luodaa mitää sisätöä (tämä on siis minun tapaukseni, muta samankaltaiseen ongelmaan voi törmätä myös muissa tapauksissa). Tämä ihan vain siitä syystä että on turhaa jauhaa turhia sisältöjä

Ongelman voi ratkaista päivittämällä Radint::MetaStore :n metodia restore_response (radiant/lib/radiat/cache.rb)
Patch:lla

 - def restore_response(hash, body)
 + def restore_response(hash, body = nil)

Oletettava virhe joka syntyy ja että sitten googlella löydät:

  SQL (0.3ms)   SELECT DISTINCT class_name FROM pages WHERE class_name <> '' AND class_name IS NOT NULL
/!\ FAILSAFE /!\  Thu Aug 13 18:21:48 +0300 2009
  Status: 500 Internal Server Error
  wrong number of arguments (1 for 2)
    /radiant-project/vendor/radiant/vendor/rack-cache/lib/rack/cache/metastore.rb:96:in `restore_response'
    /radiant-project/vendor/radiant/vendor/rack-cache/lib/rack/cache/metastore.rb:96:in `invalidate'
    /radiant-project/vendor/radiant/vendor/rack-cache/lib/rack/cache/metastore.rb:94:in `map'
    /radiant-project/vendor/radiant/vendor/rack-cache/lib/rack/cache/metastore.rb:94:in `invalidate'
    /radiant-project/vendor/radiant/vendor/rack-cache/lib/rack/cache/context.rb:137:in `invalidate'
    /radiant-project/vendor/radiant/vendor/rack-cache/lib/rack/cache/context.rb:68:in `call!'
    /radiant-project/vendor/radiant/vendor/rack-cache/lib/rack/cache/context.rb:50:in `call'
    /opt/local/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/head.rb:9:in `call'
    /opt/local/lib/ruby/gems/1.8/gems/rack-1.0.0/lib/rack/methodoverride.rb:24:in `call'

Huom! Esimerkki toimii vain *nix alustoilla koska Capistrano ei tue virallisesti muita.

Capistranon asennus:
Riippuen *nix:stä ja Ruby:n asennuksesta riippuen tarvitset sudo/su oikeuksia.

[sudo] gem install capistrano

Rails projektin alustus:
Capistrano luo config/deploy.rb tiedoston.

cd /rails/projektin/juuri/
capify .
[add] writing `./Capfile'
[add] writing `./config/deploy.rb'
[done] capified!

./config/deploy.rb

# Minimaalinen esimerkki
# Sovelluksen nimi
set :application, "sample-app"
# Osoite jossa lähdekoodi majailee
set :repository,  "git@github.com:sample-app.git"
# Versionhallinta sovellus - tässä esimerkikssä git
set :scm, :git
# Palvelimen asennuskansio
set :deploy_to, "/home/example/public_html/#{application}"

# Asetetaan oletus moodi
set(:env, 'staging') unless exists?(:env)

if env == 'production'
  # Otetaan oikea branch
  set :branch,      "production"
  # Virallinen tuotantoympäristö
  puts "********* DEPLOYING TO PRODUTION *********"
  # Web-palvelin
  role  :web,         "domain.fi"
  # Sovelluspalvelin
  role  :app,         "domain.fi"
  # Tietokantapalvelin
  role  :db,          "domain.fi", :primary => true
  # Juuri kansio
  set   :base_folder, "/var/www/production/www"
  set   :user,        "production_user"
  # Kansio johon asennus tehdään
  set   :deploy_to,   "#{base_folder}/#{application}"
  set   :use_sudo,    false
  set   :spinner,     false
  set   :reaper,      false

  # Tehdää asennus kopioimalla ensin omalle koneelle ja siitä siirretään palvelimelle
  # näin vältytään usein ssh avaimien haalimisesta git:ä käytettäessä
  # voisi käyttää myös ssh_forward:ia, mutta näin aloittavalle helpompi
  set   :deploy_via,  :copy
  set   :compression, :zip
  set   :rails_env,   "production"

  elsif env == 'staging'
  # Otetaan oikea branch
  set :branch,      "staging"
  puts "********* DEPLOYING TO STAGING *********"
  # Web-palvelin
  role  :web,         "staging.domain.fi"
  # Sovelluspalvelin
  role  :app,         "staging.domain.fi"
  # Tietokantapalvelin
  role  :db,          "staging.domain.fi", :primary => true
  # Juuri kansio
  set   :base_folder, "/home/developer/www"
  set   :user,        "developer"
  # Kansio johon asennus tehdään
  set   :deploy_to,   "#{base_folder}/#{application}"
  set   :use_sudo,    false
  set   :spinner,     false
  set   :reaper,      false

  # Tehdää asennus kopioimalla ensin omalle koneelle ja siitä siirretään palvelimelle
  # näin vältytään usein ssh avaimien haalimisesta git:ä käytettäessä
  # voisi käyttää myös ssh_forward:ia, mutta näin aloittavalle helpompi
  set   :deploy_via,  :copy
  set   :compression, :zip
  set   :rails_env,   "production"
  end

Staging eli esittelyn vaiheen käyttöönotto:

# Valmistellaan ympäristö eli luodaan tarvittavia kansioita yms.
cap deploy:setup -S env=staging

# Tehdään ensimmäinen käyttöönotto
cap deploy:cold -S env=staging

# Ajetaan migraatiot
cap deploy:migrate -S env=staging

# Uuden releasen vieminen
cap deploy -S env=staging

# Lisää komentoja saat esille
cap -T

Lisää reseptejä löytyy  http://github.com/jaakkos/my-deploy-stuff/tree/master

Mitä termillä RIA sitten tarkoitetaan? Tästä voidaan olla yhtämontaa mieltä kuin on käyttäjiäkin. Esitänkin listan RIA-sovelluksen tunnistamiseen. Lista ei ole missään nimessä kattava vaan enemmänkin suuntaa antavat. Joskus on vaikea erottaa tavallinen web-sovellus RIA:sta, koska niiden väli on häilyvä.

1. Tarvitseeko sovellus asentaa ennen käyttöönottoa?
2. Kuinka käynnistit sovelluksen? Käynnistysvalikon kautta? Selaimella?
3. Onko sovellus käytössä kun ei ole verkkoyhteyttä käytössä?
4. Mikäli käynnistät sovelluksen toiselta koneelta, onko tallentamasi tieto saatavissa?

Muutama miete:

On hyvä erottaa itse sovelluksen asennus ja sovelluksen vaatiman ajoympäristön tai selaimen lisäosan asennus. Esimerkiksi Adobe Air tai Google Gears ovat alustoja joita voidaan hyödyntää RIA sovelluksia kehitettäessä. Adobe Air on RIA sovelluksien luomiseen tehty ajoympäristö, joka löytyy useimmille käyttöjärjestelmille. Google Gears on taas laajennus selaimeen, jonka avulla voidaan luoda offline toiminnallisuutta. RIA sovellus siis saattaa vaatia jonkin sovelluksen asennuksen ennen kuin toimii täydellisesti tai lainkaan, mutta tämä riippuu RIA:n toteutuksesta. Myös RIA sovelluksen käynnistys riippuu käytetystä tekniikasta. Esimerkiksi Adobe Air RIA sovellus vaatii ensimmäisellä kerralla asennuksen, jonka jälkeen se käyttäytyy kuin perinteinen sovellus.

RIA -sovellus voi käsittää useamman käyttöliitymän. Perussovellusta voidaan käyttää suoraa web-selaimella, kun taas edistyneempien ominaisuuksien käyttö vaatii esimerkiksi Google Gears lisäosan asennuksen. Näin sovelluksen saavutettuus on paras mahdollinen.

Mitä tapahtuu kun ei ole yhteyttä internettiin? Tämä on mielestäni todellinen erottaja RIA sovelluksen ja kuorutetun web-sovelluksen välissä. Todellinen RIA kykenee tarjoamaan myös toiminallisuuden offline tilassa, joskin usein rajatun. Kun yhteys taas saavutetaa, tieto synkronoidaan palvelimen ja sovelluksen välillä. Riippumatta paikasta tai koneesta tulee luotu ja synkronoitu tieto olla käytettävissä.

RIA -sovellus on käyttöliittymä tietoon, joka on tallennettu keskitetysti.

Lisää tietoa:

• Wikipedia: Rich Internet Application
• Wikipedia: Web Application
• Google Gears
• Adobe Air
• SilverLight 2 ( ensimmäinen versiota ei voida katsoa RIA alustaksi )

Kysymyksiä lukioille:

1. Mikä sinusta erottaa RIA -sovelluksen perinteisestä web-sovelluksesta?
2. Oletko käyttänyt jotain RIA -sovellus?