Accenturen IT-miniseminaari

Riikka Karhu

Accenture järjesti 15.5.2012 Metropolian tiloissa ammattikorkeakoulujen tietojenkäsittelyn ja tietotekniikan opiskelijoille IT-seminaarin. Seminaari oli jaettu kolmeen osaan: avaus, työpajat ja Accenture Awards -stipendien jako. Seminaarin tarkoitus oli esitellä Accenturea opiskelijoille työpaikkana sekä kertoa pinnalla olevista trendeistä IT-alalla. Opiskelijoilla oli mahdollisuus testata taitojaan sekä oppia uusia taitoja, sekä luoda hieman kontakteja tulevaa varten. Aion nyt tuoda esiin kiinnostavia pointteja, joita seminaarin aikana nousi esiin.

Seminaari alkoi yleiskatsauksella Accentureen. Kyseessä on kansainvälinen yritys, jolla on toimipisteitä yli 50 maassa sekä asiakkaita 120 maassa. Suomessa työntekijöitä on yli 1200 sekä toimintaa on Helsingin lisäksi Tampereella ja Oulussa. Esittelijä muisti tuoda sen tärkeän ominaisuuden esiin, että Accenture on valittu vuosina 2007-2010 parhaaksi työpaikaksi Suomessa neljänä vuotena peräkkäin. Asiakasyrityksinä Accenturella on 18 Suomen 20 suurimmasta yrityksestä. Näille yrityksille Accenture tarjoaa konsultointi- sekä teknologiapalveluita. Tehtäviä saatetaan myös tarvittaessa ulkoistaa ulkomaille.

Ulkoistaminen nosti seminaarilla esiin pienen keskustelun, siitä kuinka ulkoistamisen rooli tulee kehittymään tulevaisuudessa. Esittelijän mukaan ulkomailta löytyy osaamista koodaus- ja ylläpitotehtävissä. Monien ohjelmistojen kehitystyö voidaan tehdä muualla kuin asiakkaan luona; tällöin ulkoistus voi olla järkevämpi vaihtoehto. Vaikka tehtävine ulkoistaminen ei tule välttämättä tulevaisuudessa kasvamaan yhtä radikaalisti, sen rooli on osaamisen takia merkittävä jatkossakin.

Accenturen yleisesittely kesti vähän reilun tunnin verran. Tämän jälkeen siirryimme työpajoihin. Ilmoittautumisvaiheessa piti valita yksi kiinnostava työpaja neljästä vaihtoehdosta. Ensimmäinen vaihtoehto oli tutustuminen Jazz-projektinhallintatyökaluihin. Työpajaan osallistuneet pääsivät kokeilemaan Jazz-työkaluja projektijohtajan, testaajan ja määrittelijän rooleissa. Toinen vaihtoehto oli SAP Hot Topics, jossa keskityttiin SAP-järjestelmän ja sen ekosysteemin uusimpiin suuntauksiin ja innovaatioihin, joista asiakkaamme juuri nyt ovat erityisen kiinnostuneita. Kolmas työpaja olisi ollut avoimen lähdekoodin Java-kirjastoihin tutustumista, mutta sitä vetämään valittu konsultti ei valitettavasti päässyt paikalle. Neljännessä työpajassa tutustuttiin .NET-ympäristöön sekä Windows Phone 7:n kehittämiseen.


Itse koin neljännen työpajan, eli Windows Phonen, kaikista kiinnostavimmaksi, joten osallistuin siihen. Työpaja alkoi lyhyellä luento-osuudella, jossa käytiin Windows Phonen perusperiaatteita läpi. Koodaaminen tapahtui Visual Studiolla ja C#-kielellä Windows Phonen virtuaalisessa kehitysympäristössä. Aikaisempaa kokemusta mobiilikehityksestä ei tarvittu, mutta .NET-perustuntemus oli suositeltavaa. Itselläni ei ollut kumpaakaan, vaan menin mukaan puhtaasti java-osaamisen tukemana.

Yksinkertaisimmillaan Windows Phone koodaaminen etenee siis siten, että Visual Studion toolboxista siirretään haluttu ominaisuus näytölle. Ominaisuus voi olla esimerkiksi textbox, jonne käyttäjä voi itse syöttää tietoa tai painike. Painikkeeseen saa suoraan kirjoitettua siihen tarkoitetun koodin. Alla esimerkki yksinkertaisen karttaohjelmiston koodista:

Karttasoftan koodia, omaa koodia

Mielenkiintoista Windows Phonessa oli se, kuinka lyhyellä määrällä koodia pystyi saamaan monimutkaiselta vaikuttavan ominaisuuden aikaan. Konsultin demossa esitettyjen ominaisuuksien koodit olivat todellakin lyhyitä eivätkä edes kovin monimutkaisen näköisiä. Koodaamista helpotti myös "testipuhelimen", eli emulaattorin käyttö; koodaaja siis näkee koko ajan miltä ominaisuus tulee näyttämään puhelimen näytöllä ja kuinka se tulee toimimaan. Myös testaaminen oli helpompaa kuin esimerkiksi Eclipsellä tehdyn koodin testaaminen.

Emulaattori käynnissä, omaa koodia

Kun kerta kaikkea ei saa aina pelkästään kehua, voin sen verran antaa kehittävää palautetta, että työpajaa varten valitussa luokassa oli äärimmäisen huono ilma. Lämpötilaero luokan ja käytävän välillä oli varmaan valehtelematta ainakin viisi astetta. Tällaiset pienet tekijät vaikuttavat ainakin allekirjoittaneen keskittymiseen ja oppimiseen. Toinen omaa oppimistani haastanut tekijä oli se, että luentoa pitämään valittu konsultti puhui hyvin nopeasti. Kuten sanoin, minulla ei ollut aikaisempaa kokemusta .NET-ympäristöstä eikä C#:sta, joten luentoa oli välillä haastava seurata. Tästä huolimatta voisin osallistua vastaavaan tapahtumaan toisenkin kerran. Aika pintapuoliseksi tuo esittelytilaisuus jäi ja ymmärrän, ettei ajan rajallisuuden takia millään ehditty syventyä sen tarkemmin Windows Phonen ominaisuuksiin.


Seminaarin lopuksi oli Accenture Awards-stipendien jako. Tapahtumassa Accenture palkitsi hyvin opinnoissaan menestyneitä opiskelijoita, joita näiden opettajat olivat ehdottaneet palkittaviksi. Opiskelijan näkökulmasta stipendi on arvokas, sillä se saattaa helpottaa työnhakua Accenturelta. Muutama oma opiskelukaveri vastaanotti kyseisen stipendin, ja mielestäni täysin ansaitusti. Ehkä minullekin sitten jonain vuonna... ;)


Kaikin puolin Accenturen järjestämä IT-miniseminaari oli antoisa tapahtuma. En itse työskentele Accenturella, mutta en sulje pois sitä vaihtoehtoa, että joskus kyseisestä firmasta hakisin töitä. Mielestäni on enemmän kuin tärkeää tietää jotain firmasta, josta aikoo hakea töitä. Tällaiset seminaarit ovat parhaimmillaan loistava tilaisuus IT-alan opiskelijalle päästä tutustumaan yritykseen sekä sen toimintatapoihin lähemmin.

Lisää Accenturesta voi lukea heidän nettisivuiltaan: http://www.accenture.com/fi-en/Pages/index.aspx 
Windows Phonesta kiinnostuneet voivat täällä tutustua lisää kehittämiseen: http://msdn.microsoft.com/en-us/library/ff402535

Scrum

Riikka Karhu

Opiskelen toista vuotta tietojenkäsittelyä ammattikorkeakoulussa. Nyt kevätlukukaudella olemme päässeet tutustumaan Scrum-työskentelyyn. Ainakaan itse en ollut aikaisemmin kuullut scrumista juuri mitään enkä usko, että kovin moni muukaan kurssilla oleva. Sen lisäksi, että meille kurssilla kerrottiin mitä Scrum on, olemme päässeet luomaan omaa webbisovellusta Scrumin käytäntöjen mukaisesti. Sanana Scrum on oikeastaan mahdoton kääntää suomeksi, joten on yksinkertaisempi avata mitä termi oikein tarkoittaa.

Scrum on ohjelmistokehitysmenetelmä, viitekehys, jonka avulla ohjelmistokehityksestä pyritään tekemään mahdollisimman kevyttä ja ketterää. Sitä on hyödynnetty alalla jo 1990-luvun alusta lähtien. Scrum voi pitää sisällään erilaisia prosesseja ja tekniikoita, riippuen kovasti yrityksestä, jossa ohjelmistokehitystä tehdään. Sen on tarkoitus tehdä tuotehallinnon ja -kehityksen menetelmien vaikutuksia näkyviksi, jotta menetelmiä voitaisiin parantaa. Scrum hyödyntää iteratiivis-inkrementaalista eli toistavaa ja lisäävää lähestymistapaa, jotta voidaan optimoida ennustettavuus ja minimoida mahdolliset riskit.

Scrum koostuu scrum-tiimistä, tapahtumista, tuotoksista ja säännöistä. Nämä osat ovat kaikki merkityksellisiä Scrumin onnistumisessa. Sääntöjen tarkoituksena on sitoa yhteen tiimien roolit, tuotokset ja tapahtumat sekä ohjata niiden välistä vuorovaikutusta. Vuorovaikutuksen ja kommunikoinnin merkitystä ei voi Scrumissa korostaa liikaa, sillä niiden avulla pystytään minimoimaan riskit entisestään sekä välttyä mahdollisilta konflikteilta.

Scrum-tiimi
Scrum-tiimit päättävät hyvin pitkälle itse millä tavalla työtä tekevät; ulkopuolelta ei tule ohjausta. Tiimeistä löytyy kaikki tarvittava osaaminen ja ne on suunniteltu joustavuuden, luovuuden ja tuottavuuden optimoimiseksi.

Product Owner eli tuoteomistaja on asiakas, joka tilaa tuotteen. Hän on miettinyt etukäteen, minkälaisen ohjelmiston tarvitsee ja mitä ominaisuuksia siinä tulee olla. Tuoteomistajan vastuulla on maksimoida sekä tuotteen että kehitystiimin työn arvo. Hän myös vastaa kehitysjonon hallinnasta. Käytännössä tämä tarkoittaa sitä, että tuoteomistaja pitää huolen siitä, että vaadittavat työt tehdään siinä järjestyksessä, joka mahdollistaa tavoitteiden saavuttamisen parhaalla tavalla. Tuoteomistaja ei osallistu varsinaiseen ohjelmistokehitykseen, mutta saa tuoda ilmi toiveitaan.

Kehitystiimi koostuu ammattilaisista, joiden tehtävänä on toteuttaa tuotteen kehitysjonon sisältö toimivaksi kokonaisuudeksi. Kehitystiimi valtuutetaan hoitamaan omaa työtään, eli tiimi saa sisäisesti päättää kuinka kehitysjonon sisältö muutetaan toimivaksi lopputuotteeksi. Jäsenillä voi olla erityisosaamisia, mutta koko tiimi on vastuussa työn laadusta. Tiimille annetaan siis paljon valtaa ja vastuuta, mikä liittyy varsinaiseen kehitystyöhön. Tällä tavalla luodaan tiimille sellaiset edellytykset, jotka parantavat suorituskykyä ja tuottavuutta. Tiimin koko ei saa olla liian pieni, jotta osaamista ja aikaa löytyy. Liian iso tiimi aiheuttaa sekavuutta ja vaatii enemmän koordinointia. Tästä syystä ihanteellinen kehitystiimin koko vaihtelee kolmen ja yhdeksän henkilön väliltä, riippuen täysin tilatun tuotteen vaatimuksista.

Kolmas Scrumin keskeinen rooli on scrum-mestari, jonka vastuulla on se, että kaikki ymmärtävät ja käyttävät Scrumia. Scrum-mestari on scrum-tiimin palveleva johtaja ja hän toimii apuna scrum-tiimille. Scrum-mestari pitää huolen, että tiimi ei joudu tekemään turhaa työtä. Hän kommunikoi tuoteomistajan ja tiimin välillä sekä dokumentoi tehtyä työtä.

Sprintti
Scrum-työskentelyssä tuoteomistajalta saatu tehtävä jaetaan osiin, jotka valmistetaan maksimissaan kuukauden kestävissä sprinteissä, kehitysprosessin aikana jokainen sprintti on yhtä pitkä. Sprintin aikana ei ole tarkoitus tehdä muutoksia valmiiseen suunnitelmaan eikä kehitystiimiin, vaan sen tavoitteena on tuoda tuotteen kehitysjono lähemmäksi laajempaa tavoitetta ja kokonaisuutta. Kukin sprintti alkaa suunnittelupalaverilla, johon osallistuu koko scrum-tiimi. Palaverissa käydään läpi se, mitä sprintin aikana on tarkoitus toteuttaa ja miten toteutus tapahtuu. Sprintin aikana kukin päivä käynnistetään lyhyellä, noin 15 minuutin mittaisella palaverilla, Daily Scrumilla. Daily Scrumissa kehitystiimi käy keskenään scrum-mestarin kanssa läpi ne asiat, joita kukin on tehnyt ja mitä tulee tekemään. Palaveri antaa tiimille mahdollisuuden kertoa scrum-masterille mikäli työn aikana on ilmennyt joitakin ongelmia. Jokaisen sprintin lopussa järjestetään sprint-review eli demo, jossa kehitystiimi esittelee valmiin lopputuloksen tuoteomistajalle. Jos jotain osiota ei ole saatu valmiiksi, se siirretään seuraavan sprinttiin.

Tuotokset
Olen jo maininnut kehtysjonon, joka on yksi Scrumin tuotoksista. Kyseessä on lista, jossa määritellään kaikki se, mitä tuotteessa saatetaan tarvita. Lista toimii scrumtiimin lähteenä tuotteen vaatimuksille ja muutoksille. Kehitysjono kehittyy sitä mukaa kun tuote ja ympäristö kehittyvät, joten kyseessä ei ole valmis tuotos.

Kehitysjono pitää sisällään kaikki ne ominaisuudet, toiminnot, vaatimukset, parannukset ja korjaukset, jotka on tarkoitus toteuttaa tuoteversioihin. Näihin kohtiin liitetään monesti hieman tarkempi kuvaus, järjestys ja työmääräarvio. Kohdat järjestetään prioriteetin, riskin ja välttämättömyyden perusteella; ylemmälle listatut kohdat kuvaavat välittömiä kehitystarpeita, eli niitä on ehditty suunnitella eniten.

Kehitysjonon kohdista koostetaan tehtävälista, mikä toimii kehitystiimin ennusteena sille, mitä toiminnallisuuksia seuraavaan tuoteversioon sisällytetään. Tehtävälista tekee näkyväksi sen työn, minkä kehitystiimi kokee tarpeelliseksi saavuttaakseen sprintin tavoitteen. Tehtävälistasta tulee tehdä mahdollisimman yksityiskohtainen, jotta Daily Scrumissa nähdään selvästi työn edistyminen.

Tuoteversio on kehitysjonon kohtien summa, jotka on saatu sprinttien aikana valmiiksi. Kyseessä on "valmis" versio tuotteesta. Tämä tarkoittaa sitä, että tuote on scrumtiimin näkökulmasta "valmis". Kehitysjonon kohdat on käyty läpi ja ohjelman toiminnallisuus on testattu. Tuoteomistaja päättää viime kädessä hyväksyykö hän tuotteen.

Lopuksi
Puolentoista sprintin jälkeen voin todeta, että olen itse pitänyt Scrum-työskentelystä. Ainakin meidän tiimi on toiminut todella hyvin yhteen, olemme kommunikoineet keskenämme ja apua on saanut aina tarvittaessa. Ainakin itse olen oppinut uutta. Voin sanoa, että tämän tapainen tiimityöskentely on paljon mielekkäämpää kuin yhteisen raportin kirjoittaminen tai muu vastaava. En usko, että koulussa saa parempaa kuvaa työelämästä, kuin tehdä pientä projektia työelämän oikeita menetelmiä käyttäen.

Lisää tietoa Scrumista tarjoaa Reaktorin erittäin hyvä Scum-opas: http://reaktor.fi/osaaminen/scrum/

Paljon asiaa ilman kuvia. Pienenä kevennyksenä ja asiaan millään tavalla liittymättä Buddy-Christ:

Ohjelmointikieliä aloittelijoille

N.M. Niskanen

Kuva: Ramotion Blog (http://www.flickr.com/photos/ramotion/)

Huolimatta siitä, että useampikin nörttitytoistämme on joko huvikseen tai ammatikseen ohjelmoija, ei tässä blogissa ole vielä aikaisemmin ollut juurikaan puhetta ohjelmoinnista. Näinpä ajattelin täyttää tämän aukon antamalla pikakurssin ohjelmointikielien ihmeelliseen maailmaan. Muutaman huomion jälkeen on jokaisesta ohjelmointikielestä malli ns Hello Worldistä. Se on (yleensä, ei nyt puhuta APL:stä) yksinkertaisin ohjelmaesimerkki; ohjelma, joka ajaessaan tulostaa ruudulle tekstin "Hello World".

Assembly
Assembly on askel ylöspäin Matrixista tutuista ykkösistä ja nollista. Se näki päivänvalon 50-luvulla ja sitä käytetään pääasiassa esimerkiksi mikroprosessorien ohjelmointiin. Sen tarjoamat toiminnot ovat kohtuullisen yksinkertaisia ja näin ollen se on (ainakin teoreettisesti) helppo oppia. Assemblyllä on kuitenkin äärimmäisen helppoa tehdä suuria ohjelmointivirheitä, kuten loputtomia kiertoja ja monimutkaisemman ohjelman koodin lukeminen on vähintäänkin rasittavaa.

Hello World:

title   Hello World!                             (hello.asm)

dosseg
.model small
.stack 100h

.data
message db 'Hello, World!',0dh,0ah,'$'

.code
main  proc
      mov    ax,@data
      mov    ds,ax

      mov    ah,9
      mov    dx,offset message
      int    21h

      mov    ax,4C00h
      int    21h
main  endp
end   main

COBOL
COBOL on ohjelmointikielien torakka. Se näki alkunsa 1959 ja COBOL-sovellukset luultavasti jatkavat pyörimistään maailmanlopun jälkeenkin niin kauan kuin virtaa vain riittää. Ja kun koneet käynnistyvät uudelleen, ne aloittavat taas pyörimisen. COBOL on tuskallista ylläpitää ja kehittää, alkaen siitä, että kääntäjät ovat edelleen pääasiassa kaupallisia. Sen tekstinkäsittelykyky on surkea. Se on myös äärimmäisen tehokas ja kykeneväinen käsittelemään massiivisia määriä tapahtumia, joka tekee siitä edelleen suositun esimerkiksi pankkimaailmassa.

Hello World (RM/1 kääntäjälle):

000100 IDENTIFICATION DIVISION.
000200 PROGRAM-ID.     HELLOWORLD.
000300
000400*
000500 ENVIRONMENT DIVISION.
000600 CONFIGURATION SECTION.
000700 SOURCE-COMPUTER. RM-COBOL.
000800 OBJECT-COMPUTER. RM-COBOL.
000900
001000 DATA DIVISION.
001100 FILE SECTION.
001200
100000 PROCEDURE DIVISION.
100100
100200 MAIN-LOGIC SECTION.
100300 BEGIN.
100400     DISPLAY " " LINE 1 POSITION 1 ERASE EOS.
100500     DISPLAY "Hello world!" LINE 15 POSITION 10.
100600     STOP RUN.
100700 MAIN-LOGIC-EXIT.
100800     EXIT.

C
C kehitettiin vuosien 1969 ja 1973 välillä. Se suurilta osin korvasi Assemblyn sulautettujen järjestelmien koodauskielenä. Sulautettuja järjestelmiä ovat monet, joita ei helposti tule ajatelleeksi hallinnoitavan ohjelmistolla; autojen mottorin hallinta, jarrut, luistonesto, televisiot ja koodasipa entinen opettajani C:llä joskus työkseen sprinklerijärjestelmiäkin. Oma kokemukseni C:stä on, että se on paljon helpompi oppia kuin Assembly huolimatta sen laajemmasta komentovalikoimasta, mutta se voi johtua siitäkin, että olen sillä tavalla vain vähän outo.

Hello World:

#include <stdio.h>
int main(void)
{
  printf("Hello world!");
  return 0;
}

C++
C++ saapui kuvioihin 1983, käytännössä C:n laajennetuna versiona. C++ tarjosi C-kieleen luokkamallin ja tyypitykset, joka helpotti esimerkiksi tekstin käsittelyä. Se on C:tä korkeamman tason kieli, niin sanottu keskitason kieli , koska se yhdistää sekä korkean tason, että alhaisen tason ominaisuuksia. Käytännössä esimerkiksi C++:lla on mahdollisuus tehdä fyysisen muistin varauksia, mutta se ei ole välttämätöntä. Monet pelit koodataan edelleen C++:llä, kuin myös tietokoneeseen liitettävien laitteiden ajurit ja muut vastaavat.

Hello World (huomattavaa on, että edellinen C:n esimerkki toimii myös C++:na, kunhan .c-tiedostomuodon vaihtaa .cpp-tiedostomuodoksi) :

#include <iostream.h>
int main(void)
{
  cout << "Hello world!" << endl;
  return 0;
}

Java

Kuva: Hillary Hartley (http://www.flickr.com/photos/hillaryandanna/)

Jos COBOL on ohjelmointikielien torakka, on Java ohjelmointikielien aasi. Sen tultua kuvioihin 1995 se on pitkälti vallannut maailman. Tähän on kaksi syytä; ensinnäkin Java on alusta lähtien ollut täysin ilmainen niin kirjastojen kuin kääntäjänkin suhteen ja toisekseen se toi mukanaan JVM:n eli Java Virtual Machinen. Kaikki Javalla tehdyt ohjelmat pyörivät JVM:n päällä, poistaen niiltä tarpeen keskustella alla olevan käyttöjärjestelmän kanssa. Tämä tarkoittaa, että Javalla kerran tehty ohjelma ainakin teoreettisesti (ja yleensä myös käytännössä) pyörii missä tahansa käyttöjärjestelmässä, joka oli tuolloin lähes ennen kuulumatonta. Vuosien varrella tämä aasi on kuitenkin lihonut ja hidastunut ja keksinyt omia erikoisia ja rasittavia oikkujaan. Se on silti erittäin laajasti erilaisissa liiketoimintaohjelmistoissa käytössä ja näin ollen kokeneella Java-ohjelmoijalla riittää työn puolesta kysyntää riesaksi asti.

Hello world:

 class Hello {
   public static void main(String[] args) {
     System.out.println("Hello world!");
   }
 }

C#
Vuonna 2001 julkaistiin .Net alusta ja sen myötä C#-ohjelmointikieli. Sitä juhlittiin monissa piireissä Javan tappajana; kevyempänä, nopeampana, helpompana, puhtaampana olio-ohjelmointikielenä. Toisissa piireissä tätä Microsoftin kehittämää kieltä taas kutsuttiin kalpeaksi kopioksi Javasta. C#:lla graafisten käyttöliittymien tekeminen on suoraan sanottuna mukavaa, varsinkin verrattuna Javaan. Toisin kuin Java, C# mahdollistaa nykyään myös funktionaalisen ohjelmoinnin, joka on yksinkertaistettuna paluuta lähemmäs datan matemaattista käsittelytapaa. Ajan kuluessa myös C# on hidastunut, joskin se on myös kehittynyt Javaa nopeammin ja pidemmälle. Se on oppinut Javalta virtuaalikoneajattelua, joskin oman kokemukseni mukaan (josta on myönnettävästi jo jonkin verran aikaa) se ei suju aivan yhtä saumattomasti.

Hello world:

public class Hello1
{
   public static void Main()
   {
      System.Console.WriteLine("Hello, World!");
   }
}

Ruby
Ruby esiteltiin maailmalle 1995, mutta se pysyi pitkään pelkästään yliopistomaailmassa. Vasta Rails-kehikon saavuttua vuoden 2005 aikoihin räjähti Ruby todella laajan yleisön tietoisuuteen. Toisin kuin tässä aiemmin mainitut kielet, Ruby on dynaamisesti tyypitetty kieli, joka tarkoittaa, että kerran luotuun olioon voidaan laittaa millaista dataa tahansa ilman erillisiä toimenpiteitä. Tämä ei välttämättä kuulosta merkittävältä, mutta takaan, että jokainen Javan ClassCastExceptioneita päivitellyt sai tuikkeen silmiinsä kuultuaan tuon ensimmäisen kerran. Ruby on vahvimmillaan selainsovellusten kehityksessä. Esimerkiksi alkeellisen verkkokaupan pystyttäminen nollasta vie noin kymmenen minuuttia Ruby on Railsillä, kun taas esimerkiksi Javalla siihen saattaa mennä päiväkausia. Nopeasti nähtävien tulosten ja helpon ymmärrettävyyden takia Ruby on saavuttanut alaa ns Ensimmäisenä Ohjelmointikielenä ja esim Future Female on Suomessa järjestänyt kurssitusta kielen alkeisiin niin sanotusti pystymetsästä saapuville.


Hello world:

puts 'Hello world'

Scala
Scala, henkilökohtainen suosikkini (jota pääsen kuitenkin käyttämään työssäni aivan liian harvoin), saapui estradille 2003. Se on alusta alkaen suunniteltu hyödyntämään parhaita puolia sekä olio-ohjelmoinnista, että funktionaalisesta ohjelmoinnista. Sen pääasiallisena alustana toimii niin hyvässä kuin huonossakin JVM ja se toimiikin (lähes) saumattomasti aikaisempien Java-ohjelmien kanssa. Scalasta on tehty myös versio .Net alustalle ja se pyörii nätisti myös Android-puhelimissa. Kuten Ruby, myös Scala on laajasti ja jopa pääasiallisesti käytössä selainten hallitsemassa maailmassa. Monet suositut sivustot on toteutettu joko osittain tai kokonaan Scalalla, hyvinä esimerkkeinä vaikka Twitter, Foursquare ja Guardianin verkkosivusto. Scalalle saatavilla oleva Lift-kehikko tarjoaa samat nopeasti nähtävät tulokset, jotka Ruby saavuttaa, kun taas JVM tai (.Net, jos sattuu olemaan sinne päin kallellaan) tarjoaa jämäkkyyttä ja laajennettavuutta.

Hello world:

  object HelloWorld {
    def main(args: Array[String]) {
      println("Hello, world!")
    }
  }

Useita katkeria taisteluita on väännetty netin keskustelupalstoilla, pubeissa ja kaikkialla missä useampi kuin yksi ohjemoija kerääntyy siitä, mikä ohjelmointikieli onkaan kaikkein paras. Ja jos totta puhutaan, ainakin tämä ohjelmoija on onnistunut väittelemään aiheesta myös ihan yksinäänkin. Tärkein asia, joka ohjelmointikielistä kannattaa kuitenkin muistaa on, että ne ovat loppujen lopuksi työkaluja. Vaikka se olisikin mahdollista, Rubylla ei välttämättä kannata lähteä tekemään pankkien taustajärjestelmiä, eikä Cobolilla verkkokauppaa. Ohjelmointikielien kirjo on laaja ja tuskin kukaan pystyy oppimaan käyttämään kaikkia. Tämä setti on vain esimerkki minulle tutuimmista ohjelmointikielistä ja siitä puuttuu monia tärkeitä ja laajasti käytettyjä ohjelmointikieliä (Lisp, Haskell, APL, Smalltalk, PHP, F# ja monia muita), joista joku muu varmasti mielellään jatkaa juttua.