Scalalla helposti Googlen App Engine -pilveen

Scala on fiksu ohjelmointikieli ja Google App Engine on helppo tapa pyörittää web-sovelluksia pilvessä. Siitä hyvästä että Scala on Javan virtuaalikoneelle kääntyvä ohjelmointikieli se toimii mainiosti myös Google App Enginen Java-ympäristössä.

Miten Scalasta utelias pääsee nopeimmin kokeilemaan koodiaansa Googlen App Engine -pilvessä? Alla on minimaalinen projekti jonka avulla saa Scalassa toteutetun Hello World -tyylisen web-sovelluksen nopeasti pilveen. Ainoa käsin asennettava riippuvuus on Apache Maven – muut riippuvuudet kuin Scala ja Google App Enginen tarvittavat kirjastot haetaan automaattisesti verkosta Mavenin avulla. Toimi seuraavasti, esimerkeissä olettaen Ubuntu-ympäristöä:

$ sudo aptitude install maven2 # Asenna Apache Maven
$ tar xzf example.tar.gz       # Pura esimerkkikoodi
$ cd example
$ mvn gae:unpack               # Pura App Engine SDK

Jatkossa sovellusta kehitetään ja julkaistaan seuraavasti:

$ vi src/main/scala/ExampleServlet.scala
$ mvn gae:deploy               # Vie sovellus App Engineen

Yllä mainitut komennot kääntävät ja vievät siis sovelluksen App Engineen asti jokaisen muutoksen jälkeen. Julkaiseminen App Engineen vaatii App Engine -tilin, jonka kuitenkin saa hankittua ilmaiseksi.

Jos haluaa vain kokeilla sovellusta paikallisessa koneessa App Engine -simulaattorissa ilman App Engine -tilin hankkimista se onnistuu seuraavalla komennolla:

$ mvn gae:run                  # http://localhost:8080/

Siitä vaan kokeilemaan!

Ja mitä tiedostoja tämä minimaalinen App Engine -projekti sitten sisältää?

  • pom.xml – Yksinkertaisen Maven-projektin määrittely jossa on riippuvuudet App Engine -kirjastoihin sekä Scala-kääntäjään.
  • src/main/scala/ExampleServlet.scala – Hello World -tyylinen yksinkertainen Java Servlet toteutettu Scala-ohjelmointikielessä.
    import javax.servlet.http._
    
    class ExampleServlet extends HttpServlet {
      override def doGet(request: HttpServletRequest,
                         response: HttpServletResponse) =
        response.getWriter().println(<html>Hello World!</html>)
    }
  • src/main/webapp/WEB-INF/web.xml – Yksinkertaisen web-sovelluksen määrittely jossa yllä mainittu esimerkkiservlet vastaa pyyntöihin kaikeissa URL:eissa.
    <?xml version="1.0" encoding="utf-8"?>
    <web-app xmlns="http://java.sun.com/xml/ns/javaee" version="2.5">
      <servlet>
        <servlet-name>ExampleServlet</servlet-name>
        <servlet-class>ExampleServlet</servlet-class>
      </servlet>
      <servlet-mapping>
        <servlet-name>ExampleServlet</servlet-name>
        <url-pattern>/</url-pattern>
      </servlet-mapping>
    </web-app>
  • src/main/webapp/WEB-INF/appengine-web.xml – Määrittelee App Engine -sovelluksen ominaisuudet, kuin sovelluksen nimi ja versio.
    <?xml version="1.0" encoding="utf-8"?>
    <appengine-web-app xmlns="http://appengine.google.com/ns/1.0">
      <application>example</application>
      <version>1</version>
    </appengine-web-app>

Siinä kaikki, enempää ei tarvita.

Tämän artikkelin on kirjoittanut Markus Holmberg  ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Uuden työntekijän aatteita

Hei vaan! Olen Antti ja Codenton uusi bloginikkari. Olen myös Codenton uusin työntekijä. Ensimmäisenä työpäivänäni Tommi ehdotti, että voisin kirjoittaa ensimmäisistä työpäivistäni blogiartikkelin. Jätän rekursiolla hassuttelun väliin ja totean näin:

Codentossa on kiva olla töissä ja työkaverit ovat mukavia.

Molemmat asiat liittyvät yhteen kuin paita ja gluteus maximus. Honeymoon-vaiheessa minä – kuten uudet työntekijät yleensä – keskityn ensin jokapäiväisiin asioihin: työnantajan käytännöt, työkaverien jutut, tarjottavan kahvin merkki. Tämän vaiheen kesto riippuu valtavasti ihmisestä ja sen tietäminen nopeuttaa uusiin töihin sujahtamista. Jos et jo tiedä oman kuherruskautesi pituutta, pidä siitä kirjaa seuraavan kerran työpaikkaa vaihtaessasi. Samaa voi toki kokeilla myös ylennyksen tai jopa uuden projektin yhteydessä.

Itse pidän tärkeimpänä asiana uusia työkavereitani. Codentolaiset ovat… persoonallisuuksia. Lounaskeskustelut kattavat pökerryttävän laajan alan: Javan getterit ja setterit, normannien kuningaskunnat Italiassa 1100-luvulla, derivaatan olemus ja paljon muuta. Jos työpaikka pitäisi valita lounasseuran perusteella, Codento olisi listan kärjessä. Lisäksi työntekijöiltä löytyy yhdistäviä asenteita työstä ja sen merkityksestä.

Pidän myös yrityksessä vallitsevasta selkeydestä. Pelisääntöjä on mietitty ja ne ovat kaikkien tiedossa. Ensimmäisten viikkojen aikana kuulin usein lauseen “Katso intrasta.” Tavallisuudesta poiketen tässä RTFM-kehoituksessa F todellakin tarkoittaa sanaa “fine”. (Siis “hieno”, ei “sakko”.) Kolleegani ovat laittaneet valtavan määrän määrän työtä yrityksen toimintatapojen määrittelyyn. Tästä syntyy odottamattomia lisäetuja. Epävarmuus on tuottavuuden kannalta kryptoniittia. Kun minimoimme sen määrän kotikentällä, voimme paremmin keskittyä asiakasprojektien kuvioihin.

Vaikka yllämainitut asiat ovat tärkeitä myös pidemmällä tähtäimellä, tulevaisuudessa täytyy myös arjen luistaa. Pinnalle nousevat jaetut motivaatiot, arvot ja tavoitteet. Jätän tältä erää yrityskulttuurien pidemmän pureskelun suosiolla tuleviin blogiartikkeleihin. Siitä on kuulemma useampikin viisas mies kirjoittanut vielä useamman kirjan. (Kirjavinkki: David Maisterin True Professionalism.)

PS. Jos ylläoleva ei vielä vaikuttanut sinusta liian ruusunpunaiselta, niin vielä vinkki uusimmasta Niksi-Codentosta. Muista kodin ja työn tasapaino: osta muutama (tai vaikka vain yksi) ruusu tänään kotiisi.

Tämän artikkelin on kirjoittanut Antti Rasinen ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.

Myynnin tuki

Jos myyntimiehiltä menee kysymään, yrityksessä on kaksi toimintoa: myynti ja myynnin tuki. Myynti tuo rahat taloon, ja myynnin tuki tekee kaiken sen välttämättömän muun työn, mitä toimiva myynti edellyttää. Kuten esimerkiksi toimittaa asiakkaille jotain jotta nämä maksaisivat laskunsa.

Vähän ahtaammin ajatellen myynnin tuki on myynnin teknistä tukea. Meillä ainakin usien myyntikeikoille lähtee myyjä ja yksi “presales engineer”, eli teknisempi hattu päässä istuva kaveri. Kun nyt “default presales engineerin” hattu siirtyy minulta eteenpäin, ajattelin kirjoittaa seuraajani Antin sekä muidenkin iloksi vähän huomioita aiheesta.

Myynnin teknisen tuen tehtävänä asiakaskontaktissa on selvittää kolme asiaa, ja ymmärtää niiden yhteydet. Ne ovat

  • Mitä asiakas haluaa
  • Mitä asiakas tarvitsee
  • Mitä voimme asiakkaalle toimittaa

Ensin pitää ymmärtää, että nämä kolme aluetta ovat erilliset, eivätkä välttämättä edes leikkaa.

Asiakkaan halut selviävät melko suoraan puheista, tai ainakin kysymällä. Joskus tietysti asiakas on niin epävarma haluistaan, että sininen pallo on lähes tyhjä.

Asiakkaan tarpeet ovatkin sitten vaikeampia. Niistä voi etsiä vihjeitä, kun asiakas kuvaa omia toimintatapojaan ja bisnestään, tai sitten voi edetä ihan yleisellä elämänkokemuksella. Samantyyppisillä firmoilla kun usien on samantyyppisiä tarpeita.

Oma tarjooma taas ei ole niinkään asiakasriippuvainen, joten se on syytä ymmärtää jo pohjatietoina. On syytä huomata, että oranssinpunainen pallura rajaa ulos myös asiat, joita ehkä osaisimme toimittaa, mutta emme halua. Konsulttiputkassa seinät ovat etäällä ja katto korkealla, kun rajoina on lähinnä firman moraali ja ehkä positiointi, mutta tuotefirmalla pallo onkin jo paljon pienempi. Itse asiassa todella pieni.

Tämä rajanveto on ennen kaikkea myynnin tuen tehtävä, ei myynnin. Meillä myyjät on koulutettu melko sisäsiisteiksi, mutta noin yleisesti koskaan ei pidä laskea myyntimiehen moraalin tai kaukonäköisyyden varaan, koska hänen työnsähän on myydä. Jos asiakas ostaa, ja tästä seuraa sittemmin ongelmia, se on jonkun muun vastuulla ratkaista ne. Tätä varten myynnin tuki on olemassa: ratkomassa ongelmat etu- tai jälkikäteen.

Ja kuten venn-diagrammeissa yleensäkin, homman juju on leikkauspinnoissa.

Halut ja tarjooma: älä päästä myyjää tänne

Vasemmalla alhaalla on violetti alue, jonka sekä voimme toimittaa, että asiakas haluaa ostaa. Huono myyjä myy koko sinisen pallon (halut) alueelta, ja sitten yritys on vaikeuksissa, kun toimitus takkuaa. Hyvä myyjä pysyy punaisella pallolla (tarjooma), mutta violettia suikaletta hänkään tuskin voi vastustaa (ks. pohdinta myyjän toimenkuvasta yllä). Kuitenkin pitkän päälle ei koskaan kannata myydä asioita, joita asiakas ei oikeasti tarvitse, vaikka haluaisikin. Hän kyllä huomaa sen aikanaan ja luottaa enemmän toimittajaan, joka ei ole rahastanut hänen väärillä käsityksillään. “Eihän se oikeastaan ollut niiden vika, että projekti ei vastannut meidän tarpeita” on lause, jolla emme halua asiakkaidemme kuvaavan meitä.

Viereen eksyneen Laren huomautus tähän: joskus voi olla perusteltua myydä pieni projekti lilalta alueelta (vastaa haluja, muttei tarpeita), jotta saadaan asiakas ymmärtämään tarpeensa paremmin, ja päästään myymään tarpeita vastaavaa jatkossa. Sen mitä tarvitsee kun usein ymmärtää vasta saatuaan mitä haluaa.

Tarpeet ja tarjooma: yritä perustella nämä

Oikealla alhaalla on vaaleanruskea alue, jota asiakas tarvitsee, ja me voimme toimittaa. Näitä olisi kiva päästä tekemään, mutta niin kauan kun asiakas ei ymmärrä niitä tarvitsevansa, ei hän niitä tilaa. Siksi ne on syytä pyrkiä perustelmaan, milloin mahdollista. Käytännössä asiakkaan omaa kuvaa liiketoiminnastaan on vaikea muuttaa yhdessä myyntitapaamisessa, eikä tänne vaaleanruskealle vyöhykkeelle siksi yleensä päästä. Mutta jos pienempi konsulttiprojekti on jo saatu myytyä tavoitteena pohjustaa isompaa keikkaa, tätä aluetta on syytä käydä läpi tiheällä kammalla.

Halut ja tarpeet: kilauta kaverille

Ylhäällä kesellä on turkoosi alue, jota asiakas sekä haluaa, että tarvitsee, mutta me emme voi toimittaa. Näissä tapauksissa asiakas pitää ohjata keskustelmaan jonkun hyväksi tuntemamme yrityksen kanssa, joka voi sen toimittaa. Tämä on yleensä myyjän työnä, tai kuka firmassa sitten vastaakaan yritysten välisestä ystävyydestä. Tälläisessä paritustoiminnassa ei kannata itse tunkea väliin kolmanneksi pyöräksi, vaan tyytyä vastaanottamaan kiitollisuudenvelka sekä ostajalta että etenkin myyjältä. Se voi osoittautua paljon välirahastuksesta saatavia pikkuropoja arvokkaammaksi, ja vaatii vähemmän (turhaa) työtä.

Maalialue: kaikki kolme kohtaavat

Keskimmäisenä onkin sitten pieni alue, jossa asiakkaan halut ja tarpeet, sekä toimituskykymme kohtaavat. Tähän maaliin tulee myyntitapaamisssa pyrkiä. Joskus se on tyhjä joukko. Ei voittoa.

Kirjoittaja on tehnyt myynnin tukityötä vuosikausia pienehköissä it-taloissa.

Tämän artikkelin on kirjoittanut Otso Kivekäs ja sitä ovat sittemmin muokanneet muut Codenton työntekijät.