JFokus 1/4 – hyvää syntymäpäivää Vaadin!

No niin, keskellä talvilomaa on aikaa käydä seminaareissakin vaihteeksi. Kohteena on Tukholmassa järjestettävä Java-kehittäjien seminaari JFokus, ja päätin lähteä matkaan Vaadin porukan sponsoroimalla laivaristeilyllä, joka sisältää mm. luentoja ja verkostoitumista.

Silja Europa risteily sujui mukavasti, ja päädyin lumiseen Tukholmaan jossa pakkasasteita on n. puolet siitä mitä Helsingissä tällä hetkellä – käytännössä siis melkein lämmin rantaloma. Osallistuin eilen tilaisuuteen jossa kävi ilmi että suosittu Vaadin framework on melkeinpä päivälleen 10 vuotta vanha – kun huomioidaan sen juuret. Nykyisessä GWT vetoisessa muodossahan se ei ole montaa vuotta ollut, mutta serveripään koodi on ollut lähes saumattoman yhteensopivaa alkuajoista alkaen. 10 vuotta vanha vaadin taitaa olla jo aika poro. 😉 Edelleen pidän Vaadin frameworkissä siitä miten komponentisointia ja uudelleenkäyttöä on viety äärimmilleen GWT:n avulla – mutta serveripään tilanhallinnalla on saatu kevennettyä kovasti paljon AJAX tietoturvapulmia – lukuisat AJAX sovellusten tietoturvareiät ovat muuten asia josta muuten tulevina vuosina tullaan vielä seminaareissa jauhamaan.  Tällä hetkellä niitä lähinnä hyödynnetään 😉

Illan luennoissa Arun Gupta Oraclelta kävi kertomassa miten OSGI, Glassfish ja Java EE 6 pelaavat yhteen, ja jälleen kerran syntyi uusia ideoita ja ymmärrystä. OSGI vetoisuus on varmasti sovelluspalvelimille hyvä asia, koska käytännössä niitä monet haluavat kustomoida, ja OSGI mahdollistaa mahdollisimman sulavan modulaarisen rakenteen, jonka avulla saadaan mm. nopeampi kännistyminen kun turhia palveluita ei ladata, ja sujuvampi päivitys kun uusia palveluita tarvitaan lisää.

David Chandler Googlelta kävi kertomassa GWT:n uusista kujeista ja antoi nipun tehovinkkejä siihen, miten GWT:stä saa kaiken irti, mm. miten JavaScript kääntämisvaihetta voi rutkasti nopeuttaa kehityksen aikana. Mieleen jäi myös uusi HTML 5 Canvas widget. Hupaisaa muuten miten W3C:n roadmap HTML 5 suhten on julkaista finaaliversio 2014… 😉 Kovasti sitä käytetään jo nyt.

Tässä vaiheessa uupumus voitti ja jouduin vetäytymään hyttiin herkkää aamuviiden herätystä varten. Kuulematta jäi Vaadin frameworkin tulevista piirteistä, mutta yritän paikata aukon sivistyksessä myöhemmin. Joka tapauksessa, Tukholmassa ollaan, ja nyt on aika poimia materiaalit ja aloittaa seminaarin päivä 1. Luvassa itselleni mm. Scalaa ja Androidia. Ja jos haluaa etäältä seurata tapahtumia reaaliajassa, twitter avainsanat #Jfokus ja #vaadin toimivat, samoin kanavat @Jfokus ja @Vaadin

 

Vuosi lähestyy loppuaan – Scalaa ja App Engineä ;)

Jep, joululomailut ovat vähentäneet blogikirjailua mutta vielä ehtii yhden artikkelin luikkaamaan sisään ennen kuin vuosi ja kujeet vaihtuvat. Olkoonkin sisällöltään vähän kevyempää tällä kertaa – ei esim. koodi tai konfiguraatiopätkiä tarjolla 😉 Vuoden vaihtumisen kunniaksi uusi ulkoasu kehiin.

Jouduin valitettavasti luopumaan suunnitelmastani toteuttaa google app engine sovellukseen käyttöliittymä Vaadin frameworkillä. Tähän päätökseen vaikutti useampikin asia, mutta se mitä en pystynyt kiertämään oli se että joka vaiheessa oli vastaan tapeltavaa ja säädettävää, ja työaika meni virittelyyn sensijaan että se olisi mennyt ratkaisun tekemiseen. Tämä on aina omassa mielessäni se killswitch jolloin on aika vaihtaa tekniikkaa. Vaadin on itsessään loistava framework, mutta se abstraktoi liiankin korkealle tasolle, jolloin gae:n asettamien vasteaika ja kirjastorajoitusten kanssa tulee vastaan paljon haasteita. Lisäksi tietysti mehukkaimmat komponentit ovat AGPL lisenssin takana josta en järin itse pidä – se kun pakottaa julkaisemaan KOKO oma sovellus lähdekoodina, ei pelkästään muutoksia komponentin koodiin. Tästä pääsee tietysti eroon lisensoimalla komponentin mutta se vaatii tiettyä sitoutumista ratkaisuun. Lopulta ongelmana on myös debuggaus; Testaus pilvessä ei anna aina kovin hyviä virhetietoja ja statistiikkaa – testaus omassa koneessa ei taas toimi samoin kuin pilvessä. Tämä on tietysti vastassa joka frameworkillä mutta kun puolet asioista tapahtuu javascriptin puolella on asiassa vielä lisähaasteita.

Sinnikkäämmät sielut ovat saaneet homman toimimaan, eli tässä pari viitettä gae + vaadin asioihin:

http://vaadin.com/wiki/-/wiki/Main/Google%20AppEngine%20HOWTO

http://www.streamhead.com/maven-spring-vaadin-appengine/

http://devrimyasar.com/blog/2009/11/22/finally-there-vaadin-godsend-on-gwt-google-app-engine/

Eli vielä kerran, Vaadin on hieno ellei peräti loistava framework, ja paljon käytetty, mutta pilvi + vaadin on toistaiseksi early adopter aikaa, jossa joutuu maksamaan aika kovan hinnan etenemisestään. Se on huimasti parempi vaihtoehto kuin paljas Google Web Toolkit, koska suurin osa prosessoinnista ja tilanhallinnasta tapahtuu palvelinpäässä (tästä on myös tietoturvahyötyä GWT:hen verrattuna). Kokonaisuus tulee varmasti tulevaisuudessa paranemaan vielä ennestään, mutta itselleni valikoitui käyttöliittymään RichFaces toistaiseksi, se kun on pilvivalmis uusimmassa 4.0 releasessaan. Näin pääsen hyödyntämään rikkaita JSF kontrolleja ja voin hallita miten paljon AJAX:ia haluan upotella mukaan. So far so good..

Ja sitten, sain valmiiksi koulutusmateriaalin Scala ohjelmoinnista, ja tutustuessa tähän kieleen täytyy sanoa että se on kuin kevättuulen virkistävä hengähdys. Javan vanhuus ja muuttumattomuus näkyy ja useat parannukset ovat kuin laastarilappuja alustan päällä. Se on edelleen kova alusta jolla voi tehdä melkein mitä vain, mutta aika ajoin koodaajalle tekee hyvää tuulettaa vähän ajatuksiaan ja oppia jotain uutta, ja Scala on kyllä miellyttävää. Monet asiat jotka vaativat paljon työtä Javassa ovat salamannopeita Scalassa, ja jokainen koodaaja voi itse päättää haluaako kirjoittaa Scalaa oliomaisesti, vai funktionaalisesti, ja missä suhteissa.

On toki vielä useita alueita joissa Scalassa on keskeneräisiä ratkaisuja ja turhankin monta vaihtoehtoa, mutta suuri rikkaus on myös hypätä saumattomasti Java kirjastoihin aina kun sille on tarve – ja enemmän ja enemmän asioita voi jo nykyisin tehdä scalamaisesti, kuten esim. tiedostojen ja url resurssien käsittelyn, tietokannankäsittelyn, ja web kerrokset. Ja mikä mukavinta, scalaa voi ajaa missä vain java alustalla – esim. pilvessä 😉

Joka tapauksessa, kurssi on näkyvillä http://www.tieturi.fi/avoimet-kurssit/kurssi.html?cat_id=117445444&course_id=83926464 – ja palautetta kuulen mieluusti. Jos homma kiinnostaa niin jatko-osia tulee perässä!

Joka tapauksessa, tämä on viimeinen blogi tälle vuodelle. Parhaimmat uudenvuoden toivotukset kaikille tälle sivuille osuville!

Google App Engine pilvipalvelu ja Java EE 6, osa 4

Silmäilin mielenkiinnolla miten Java EE 7 tulee koskemaan pääteemana pilvipalveluita; Tekisi hyvää saada yhteistä rajapintaa myös tämän osalta, jolloin ainakin teoriassa pilvipalveluista tulisi vapaammin siirettäviä ja kilpailutettavia, ja vältettäisiin nykyinen vahva vendor lock-in.. Aika näyttää miten tässä käy.

Itse päädyin tekemään muutoksen oman pilvipalveluni arkkitehtuuriin. Siinä missä homma alkoi Solakka Java-periaatteella, totesin että vaikka JSF 2 on paljon parannettu versio aiemmasta, tekniikkademosta saa paljon mielenkiintoisemman jos korvaan sen RESTful web service tekniikalla ja suomalaisella Vaadin AJAX frameworkillä.

Valitsin toteutusalustaksi referenssitoteutuksen eli Jersey JAX-RS alustan. Sain sen käyttöön Mavenin  pom.xml:ssä näin:

<!-- Turn on Jersey JAX-RS -->
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-server</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-client</artifactId>
<version>1.4</version>
</dependency>
 
<dependency>
<groupId>com.sun.jersey</groupId>
<artifactId>jersey-json</artifactId>
<version>1.4</version>
</dependency>
<dependency>
<groupId>com.sun.jersey.contribs</groupId>
<artifactId>jersey-multipart</artifactId>
<version>1.4</version>
</dependency>

Eli muutama dependency lisää. Lisäksi web.xml:ssä piti ottaa Jersey servlet käyttöön ja kertoa mitä pakettia skannata resurssien osalta, tähän tapaan:

<!-- JERSEY support -->
<servlet>
<servlet-name>Jersey Web Application</servlet-name>
<servlet-class>com.sun.jersey.spi.container.servlet.ServletContainer</servlet-class>
<init-param>
<param-name>com.sun.jersey.config.property.packages</param-name>
<param-value>fi.tieturi.pilvenveikko.services</param-value>
</init-param>
<load-on-startup>1</load-on-startup>
</servlet>
<servlet-mapping>
<servlet-name>Jersey Web Application</servlet-name>
<url-pattern>/resources/*</url-pattern>
</servlet-mapping>

Ja siitä se sitten lähti. REST filosofian mukaan muokkaan palveluita CRUD tyyliin joten jatkossa voi luoda tätä kautta WorkUnit, Person, ja Goal yksiköitä, hakea ja päivittää ja poistaakin niitä, http url osoitteilla.

Pari pikku knoppiakin tuli vastaan. Google App Enginen JPA toteutus ei haekaan tietoja aina heti vaan käyttää lazy load periaatetta. Näin on tarpeen varmistaa että kaikki tiedot on kannasta saatu ennen kuin niitä xml:ksi marshalloidaan . Tämän voi hoitaa vaikkapa size-metodia kutsumalla. Tässä maistiainen Resource luokastani:

package fi.tieturi.pilvenveikko.services;
import fi.tieturi.pilvenveikko.domain.WorkUnit;
import fi.tieturi.pilvenveikko.util.EMF;
import java.util.List;
import javax.persistence.EntityManager;
import javax.persistence.Query;
import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
@Path("/workUnit")
public class WorkUnitResources {
  @GET
@Path("/findAll")
@Produces("text/xml")
public List<WorkUnit> getWorkUnits() {
EntityManager em = null;
try {
em = EMF.get().createEntityManager();
Query q = em.createQuery("SELECT wu FROM WorkUnit wu ORDER BY wu.workDate");
q.setMaxResults(200); // limit to max 200 results
List<WorkUnit> results = q.getResultList();
results.size(); // this is a hack to wait until results are all there
return results;
} finally {
if (em != null) {
em.close();
}
}
 }

@GET
@Path("/read/{workUnitId}")
@Produces("text/xml")
public WorkUnit getWorkUnitById(@javax.ws.rs.PathParam(value="workUnitId") long workUnitId) {
EntityManager em = null;
try {
em = EMF.get().createEntityManager();
WorkUnit result = em.find(WorkUnit.class, workUnitId);
return result;
} finally {
if (em != null) {
em.close();
}
}
}
}

Ja siinä se. Ensi kerralla voisin jutella vaikkapa Vaadin frameworkin käyttöönotosta ja piirteistä ja pilvivirityksistä.