2012-01-11

Favorite childhood poems

   Auguurit

   Haukkani, haukkani,
   Elämä on vain leikki ja oikku,
   mullassa on kyllä aikaa maata.
   Älä pelkää pimeää jokea,
   älä pelkää kummallista lauttaa,
   sekin on vain leikki ja oikku.
   Älä hätäile,
   anna sydämesi kovettua,
   kunnes mikään ei merkitse mitään.
   Kenties sillon auguurit tervehtivät sinua,
   kuten itse tervehdit haukkaasi
   syysaamuna.


   Mika Waltari
   1953

2012-01-03

Lomaopinnot: JSF 2.0 + PrimeFaces 3.0

(Kopio eri taustaisille kollegoille lähetetystä sähköpostista.)

Hei, katselin loman aikana erilaisia teknologioita, joista yksi oli JSF 2.0 + PrimeFaces 3.0 RC2.

Java Server Faces on selainteknologiastandardi, joka tuo yhteen web-käyttöliittymäsuunnittelijat, backend-kehittäjät sekä kolmannen osapuolen komponenttikirjastojen toimittajat. Se standardoi eri toimijoiden väliset rajapinnat, sekä web-sovelluksen teknisten toimijoiden osuudet sovelluksien käytön elinkaaren aikana. Siitä on useita implementaatioita.

PrimeFaces on komponenttikirjasto, joka sisältää kaiken mitä B2B web-sovellukset yleensä tarvitsevat, helppokäyttöiseksi paketoituna.

Nämä teknologiat kilpailevat perinteisen HTML/JavaScript käsin kehityksen kanssa, sekä sovelluskehittimistä MS:n webbikehittimen, sekä esimerkiksi Google Web Toolkitin, Vaatimen, ExtJS:n, SmartClientin, SmartGWT:n ja ExtGWT:n kanssa. (Uutena mutta varteenotettavana kilpailijana kentällä on 2012 dust.js:n tyyppiset teknologiat, joita mm. LinkedIn on siirtymässä käyttämään, REST JSON-palveluiden kanssa.)

JSF-sovellukset koostuvat näkymätemplateista (Facelets) joissa HTML-koodin seassa määritellyt näkymäkomponenttien instanssit osoittavat sovelluksen taustaosioon, eli beaneihin (tiettyä sopimusta noudattava Java-luokka) jotka on annotoitu JSF:n kontekstitiedolla. Tyypillisessä sovelluksessa on joitakin taustaluokkia joiden elikaari kuuluu sessiokontekstiin, joitakin taustaluokkia jotka elävät spesifisessä keskustelukontekstissa (esim. jos sovelluksessa on osioita joiden halutaan toimivan samaan aikaan saman selaimen eri tabeissa) tai jopa yhden requestin eli HTTP-pyynnön pituisessa kontekstissa.

(JSF 2.0:n sisäänrakennettu keskustelukonteksti toimii hyvin epäintuitiivisesti, ja sitä varten Apache MyFaces CODI projekti on luonut standardia noudattavan custom scopen, joka toimii fiksummin. CODI:n käyttöönotto vaatii vain sen, että otat sen kirjastot mukaan projektiin, ja merkkaat taustapavun sen keskustelukonteksti-annotaatiolla.)

Hyvä esimerkki JSF 2.0 toimintaperiaatteesta löytyy PrimeFaces ajax multiupload demosta, http://www.primefaces.org/showcase-labs/ui/fileUploadMultiple.jsf

<h:form enctype="multipart/form-data">  
    <p:fileUpload fileUploadListener="#{fileUploadController.handleFileUpload}"
            mode="advanced" update="messages" multiple="true" sizeLimit="100000"
            allowTypes="/(\.|\/)(gif|jpe?g|png)$/"/>  
    <p:growl id="messages" showDetail="true"/>  
</h:form> 

Taustapapu:
 
public class FileUploadController {  
    public void handleFileUpload(FileUploadEvent event) {
        FacesMessage msg = new FacesMessage("Succesful", event.getFile().getFileName() + " is uploaded.");
        FacesContext.getCurrentInstance().addMessage(null, msg);
    }
}

Tässä esimerkissä ajax-komponentti uploadaa tiedostot, ja sen jälkeen päivittää dynaamisesti "messages" komponentin, jonka tehtävä on näyttää pienessä viestilaatikossa eventtinotifikaatioita. Jos metodissa tiedostot laitettaisiinkin talteen keskusteluskooppiseen papuun, johon vaikkapa esikatselukomponentti puolestaan osoittaisi, senkin voisi laittaa automaattisesti päivittymään, ja kokonaisuus toimisi edelleen odotetulla tavalla, vaikka komponenttien ja taustadatan vuorovaikutus ei ole mitenkään yksinkertaista.

Tässä mallissa kontrolli säilyy palvelinpäässä, kun taas kilpailevassa GWT-mallissa sovellus pyörii itsenäisesti selaimessa, ja tekee vain spesifisiä pyyntöjä taustapalveluihin. Siinä missä käsin koodattavissa järjestelmissä rajapinnat rakennetaan joko REST JSON tai XML päälle, tai enterprise architectien toiveesta SOAP:illa, JSF komponenttikirjastojen rakentajat voivat määrittää käyttäjälle näkymättömästi komponenttien toimintatavat, kunhan ne noudattavat JSF-standardin rajauksia.

Olin viimeksi kokeillut JSF:aa 1.0-versiossa, jossa se oli varsin kankea eikä vastannut tarkoitustaan, mutta nykyinen 2.0-versio vakuutti. Sillä voi rakentaa B2B sovelluksia valmiista komponenteista merkittävästi vaivattomammin kuin käsin HTML:aa ja JS:aa jyystämällä. Hintana on tosiaan se, että täysin uusia komponentteja on vaikeampi rakentaa, mutta 99%:ssa projekteista valmiissa komponenteissa pitäytyminen on vain positiivinen juttu projektin liiketoimintatavoitteissa onnistumisen kannalta. Jälleen uuden sliderikomponentin keksiminen ei oikeasti hyödytä ketään, mutta saman ajan käyttäminen tuotteen iteroimiseen asiakkaiden kanssa taas hyödyttää.

Lomaopinnot: Google Dart ohjelmointikieli

(Kopio eri taustaisille kollegoille lähetetystä sähköpostista.)

Hei, katselin loman aikana moniaita teknologioita, joista yksi oli Google Dart ohjelmointikieli.

Googlen strategia webbityökalujen suhteen on investoida siihen, että webissä pystytään tekemään mahdollisimman hyviä ja monipuolisia sovelluksia, koska he näkevät mainosbisneksensä markkinaosuuden, -position ja kannattavuuden olevan tämän globaalin capabilityn funktio.

Heillä on useita työkaluja tällä alalla, joista tunnetuin on Google Chrome verkkoselain, ja heille on kertynyt infrastruktuurikokemusta myös webin tämän hetken laajimman sovellusten toimitustavan, JavaScriptin osalta, V8 virtuaalikoneen ja Google Web Toolkit käännösympäristön mukana.

Googlen positio webin perusteknologioiden suhteen on 2012 se, ettei JavaScript itsessään vastaa riittävän hyvin huutoon, eikä sitä pysty inkrementaalisesti parantamaan riittävällä tavalla. Google Dart on heidän vastauksensa tähän ongelmaan. Se on mennyt konseptina hyvin läpi selainmarkkinoilla, ainoa vastustaja on Microsoft, jonka markkinaosuus on pudonnut jo alle 50%:n, ja jonka selainstrategian motivaationa on ollut heidän käyttöjärjestelmäbisneksensä, jonka nykymallista he ovat nyt aktiivisesti pyrkimässä ulos.

Dart vastaa kahteen ongelmaan: JavaScript ei ad-hoc kielenä tue edes keskisuurten projektien vaatimaa kehittäjien välistä viestintää, eikä sen ajamista ole sen ad-hoc ominaisuuksien vuoksi mahdollista optimoida tiettyä pistettä pitemmälle.

Dart-kieliset ohjelmat käännetään tällä hetkellä legacya varten mahdollisimman optimoitavaksi JavaScript-subsetiksi, sekä potentiaalisesti selaimiin kuten Chrome ja Firefox voi jatkossa tulla dedikoidut Dart-virtuaalikoneet.

Kieli tukee eri ominaisuuksin primääristi kahta eri käyttötapausta: normaaleja web-sovelluksia, sekä kirjastoja tai laajoja sovelluksia.

Pienet sovellukset kirjoitetaan hyvin pitkälle samaan tyyliin kuin tällä hetkellä JavaScript-sovellukset. Tyypitys on vapaaehtoista, ja skoopitus ja paketointi on huomattavasti intuitiivisempaa kuin JS:sa. Kielen peruskirjasto sisältää paljon juttuja, joiden puuttumista JS-väki usein kiroaa.

Kirjastot ja laajat sovellukset on tarkoitettu kirjoitettavaksi tyypitystiedon kanssa. Tällöin esim. muuttujat deklaroidaan tyyppitiedon kanssa, eli se mikä pienessä sovelluksessa kirjoitettaisiin val foo = "bar"; sanotaankin String foo = "bar";. Tällöin IDE osaa varoittaa, jos sovelluksesta yritetään käyttää kirjastoa väärin, ja työkalut osaavat mm. näyttää dokumentaation ja vaihtoehdot kuten C# ja Java-IDE:t tällä hetkellä.

Tyyppitieto on kuitenkin vain koristeinformaatiota, eli vaikka sanot Integer foo = "bar";, sovellus toimii edelleen odotetulla tavalla, vaikka IDE ja kääntäjä antavat varoituksia.

Mielenkiintoisia konsepteja, joilla on potentiaali tuoda merkittävästi enemmän ennustettavuutta selainsovelluksiin, jotka ovat toistaiseksi paras tapa toimittaa tuotteita mahdollisimman laajalle yleisölle.

Kannattaa tutustua. http://www.dartlang.org/ voi ladata Eclipse-pohjaisen IDE:n, joka sisältää kaiken tarvittavan.

2011-12-07

IntelliJ IDEA 11 rocks!

IntelliJ IDEA 11 came out yesterday, and I've been evaluating it by adding some unit tests to a hobby project.

The user interface (on Linux) has improved tremendously from the previous major version. It's now better more eye-friendly than either Eclipse or NetBeans, for a user who'll be staring at it for hours on end.

Its Git integration is leaps and bounds past what either Eclipse offers, and you can't even mention NetBeans (7.1 RC1) Git "support" in the same sentence. It prompts you to "git add" files as you add them to the project, and has only very relevant stuff in the commit and push workflows. Its quick diff is far superior to Eclipse's, as is its review functionality. Finally, neither of its competitors offers anything close to what its git push interface does.

When writing unit tests, IDEA makes the smartest assumptions of contextual test running. Control-Shift-F10 not only works by default on Linux, unlike NetBeans' and Eclipse's defaults, it detects your context from your cursor position, running only your current test if your cursor is in a method, or the entire class, if the cursor is between methods. Eclipse can do the same, but it also has to pop up a dialog asking whether I want to run the unit test on a server (?), and its keybindings need a lot of tweaking to work on Linux. NetBeans just leaves the entire job of determining context to the user.

Where NetBeans and Eclipse still win, however, is suggesting different class constructors, by their parameters and JavaDoc.

NetBeans 7.1:

IntelliJ IDEA 11:

2011-11-26

Testing Spring Data JPA

What I like about Spring libraries is that they just work, and they don't suddenly stop working. The APIs are usually well thought-out.

Spring Data JPA continues on the same track.

I've been going through recent developments in ORM / data access technology, and porting my tiny skeleton application to each. Today it's Spring Data JPA's turn.

You provide an interface like this:

And configuration like that:

After which Spring automatically builds, generates and injects a concrete implementation of that interface to your application, where you can use it like so:

Calling the findByNameLike method results in this SQL query being run:

Compared to many other ways of building simple database access I've tried and used, Spring Data JPA takes the cake.

The only complaint I have with it is that when integrating JPA entities with Scaml, you have to refer to their property getters like so example.getName instead of Scaml autodetecting bean properties by simply example.name, but that's more of an issue with Scaml than Spring.

2011-11-24

Tools that make a difference

When I first started out in the software product development business, new and shiny tools frequently captivated my imagination.

Over the years, I've come to see that very few new tools truly let you do new things, or offer improvements more significant than the costs of their adoption.

First, let's go over two disappointments:

Ruby on Rails is marketed as a way to reduce time to market. It delivers, when your product is trivial microsites. Otherwise, the investment it requires, and the restrictions it imposes, more than offset its merits.

Likewise with Scala. It's sold as an improvement in language expressivity, but confuses "more" with "better". It's not better for the vast majority of business missions to be able and encouraged to perform the same primitive operations in six different, largely unlegible ways. It's perfectly OK if your mission is to produce academic papers, or sell a maximum amount of consultancy hours, but for a customer of product development, a loss both in the short and long terms. And that's even without going in the whole matter of upwards compatibility.

From the bitter comes the sweet, however, and a few tools which truly make difference have come out of the innovation around these things:

HAML is the best way to describe XML/HTML templates I've yet to come across. It introduces conceptual and communicative symmetry without taking away anything important. On the JVM side, Scaml is an implementation of the same ideas.

GitHub (and Git) changed small software project management. Its predecessors (SourceForge, other forges, java.net, Kenai et al.) were stuck in a rut with the concept of how people can fix bugs and customize existing software projects, and get those changes included in the upstream. The concept of person/team specific repository namespaces, pull requests, and the fork and merge big red buttons have let me do things that I'd otherwise not done, as well as easily include others' work.

JRebel has helped me to rapidly deal with a project in which I had to make changes to an extremely slow-starting undocumented buggy component, that hadn't originally been built to be testable. Most of the time, JRebel just works, especially with a Spring stack. When I've had problems with it with less-reliable just-released JEE6 stack components, Anton has responded to support mails in hours.

2011-11-18

Testing ORMLite

While various JPA implementations are the standard for good reasons, I took the time to shop around for some of the lighter ORM tools, especially one with a reasonable SQL query builder DSL.

ORMLite won this round, and I integrated it into my skeleton application, where it replaced Spring JDBC.

The @DatabaseTable and @DatabaseField annotations come with far fewer rules than JPA beans. The _ID and _NAME constants are used with the query builder.



Unfortunately Spring doesn't automagically translate the SQLException to DataAccessException, so I have to use the translator manually.



Configuring ORMLite with Spring is painless. Had to switch HSQLdb to H2, since HSQLdb threw some permission exceptions when used with ORMLite.



Exciting stuff of November 2011

http://www.infoq.com/presentations/The-Kotlin-Programming-Language

http://www.dartlang.org/

http://blogs.oracle.com/briangoetz/resource/devoxx-lang-lib-vm-co-evol.pdf

http://ormlite.com/

http://cloudfoundry.org/ https://github.com/cloudfoundry

2011-11-14

Spring 3.1 MVC skeleton project upgrade

Over the weekend I upgraded my Spring project skeleton to include Spring 3.1 MVC support.

The skeleton app uses Scaml, a HAML-variant, as its view layer. The index page merely lists all the examples we have available.

It also contains the standard dependencies I usually recommend: Spring Framework 3.1, Joda-Time 2.0, Guava 10, LogBack/SLF4j, JUnit, Mockito and PostgreSQL.

The skeleton application is available as a Maven project at my BitBucket page at http://dev.gueck.com/project-skeletons/src/tip/spring3-web. It can be executed with the command mvn -Dspring.profiles.active=dev jetty:run.




The embedded development database gets re-initialized with a schema and test data at every application restart.





The Spring MVC controller, service and DAO classes don't need much introduction.




The service makes the business decisions, such as whom to exclude, and also demonstrates Guava's usefulness in collection handling.




The easiest way to do a simple CRUD DAO is with Spring JDBC, but it gets progressively more complex as your domain tables/classes get more complex, and pretty soon you're better off with just going with JPA.




The skeleton domain class uses Guava's ToStringHelper, and contains a static instance of Spring JDBC's RowMapper.

I like to situate some or many of the Spring JDBC helpers in the actual domain class, but the location varies depending on the various architectural visions you might embrace.




The Spring XML configuration file now demonstrates the new mvc:resources-tag, as well as profiles, and how to create a embedded development database with them.




2011-10-15

Email MIME container handling inside PostgreSQL with PL/Python

Some examples from a discussion with some colleagues of how to best handle complex LOB parsing for rare ad-hoc analytical business database queries.

2011-10-10

Google Dart + JetBrains Kotlin = ethical hotness

I've written software for pay in many various languages, and lately mostly in Java, since professional ethics require me to recommend and use the language with the most balanced match of individual, group and business features to my employer's business objectives and mission.

What excites me about a couple new tools coming out in the 4Q2011-1H2012 timeframe, is that they seem credible competitors for tool choices compatible with professional ethics.

Google Dart came out today, and offers the promise of a strong player bringing significant change to the best way of delivering applications to both consumers and business users today.

JetBrains Kotlin is yet to be published, but is proposed by one of the strongest niche players in the software tools landscape, and offers to actually reduce complexity of backend programming, without sacrificing the supporting tooling which gives participants to the Java ecosystem a lot of good value. It's different enough from Java to be worth an investment, but evades the trap many of its purported competitors fell into - optimizing the language for academic papers, and pushing out duplicate half-baked features after another.

2011-08-14

X79 Siler + i7-3930K: Java-sovellusten palvelinraudan sweet spot 4Q2011-1Q2012

Tyypilliset Java-palvelinsovellukset, business-tietokannat ja business-virtuaalikoneet eivät käytä CPU:ta tapissa, vaan niiden kustannustehokkuuden portinvartijana on keskusmuisti, ja muutaman kymmenen gigan datasettiin kohdistuvat IOPS:it.

X79 Siler-emolevyt tarjoavat mahdollisuuden kahdeksaan DDR3 slottiin per prosessori, eli 64 GB (latenssiltaan symmetriseen, NUMA:n tarpeettomuuden vuoksi) keskusmuistiin, yhdistettynä LGA2011 kantaiseen prosessoriin, kuten Sandy Bridge-E i7-3930K.

Intelin 320-sarjan SSD-levyt eivät (PostgreSQL-kehittäjien kokeiden mukaan) tarvitse superkapasitaattoria virtakatkoista selvitäkseen, ja niiden hinnat liikkuvat parissa eurossa per gigatavu, melko tyylikkäillä IOPS-luvuilla.

Tälläinen prosumer-vallankumous tarjoaa uskaltavalle ja yrittävälle firmalle mahdollisuuden rakentaa Suomen (ja lähialueiden, jos vähän näkee vaivaa) mittakaavaisiin tuotteisiin hyvin edullisesti ominaisuuksia, joiden kustannukset olisivat olleet satakertaisia vielä vuosi tai pari sitten.

Jotta voi ottaa ilon irti rautapuolen kehityksestä, pitää vaan pysytellä kauempana harrastajaporukan ohjelmistokehityksen työkaluista, kuten skriptikielistä jotka eivät vaan käytännössä pysty käyttämään samanaikaisesti kahtatoista säiekontekstia, ja käyttämään keskusmuistia säieturvallisesti datasetin käsittelyyn.

8GB registered DDR3 hinnat saisivat vielä pudota...

2011-07-16

Charliella on asiaa

Etenkin relevantti Norjan tapahtumien jälkeen...

2011-04-28

Running Java .WARs on port 80 as an ordinary non-root user with Ubuntu Linux 11.04, Jetty, upstart, authbind and OpenJDK

First, let's install the various dependencies:

sudo apt-get install openjdk-6-jdk ivy authbind curl nano

We need to create a Hello, World! application to test with:

sudo mkdir /var/tmp/helloworld
sudo chown 1000 /var/tmp/helloworld
echo '<%= "Hello, World! " + new java.util.Date() %>' > /var/tmp/helloworld/index.jsp

Let's test that ivy can fetch us the requirements for running Jetty.

/usr/lib/jvm/java-6-openjdk/bin/java -jar /usr/share/java/ivy.jar -dependency org.mortbay.jetty jetty-runner 7.3.1.v20110307

Use the same mechanism to start up Jetty on port 8080 for /var/tmp/helloworld. Since the previous run cached the dependencies to ~/.ivy2/cache/, this time Jetty will start up much faster. Notice, that whichever user you end up running the service as must have an existing home directory which they also own.

/usr/lib/jvm/java-6-openjdk/bin/java -jar /usr/share/java/ivy.jar -dependency org.mortbay.jetty jetty-runner 7.3.1.v20110307 -main org.mortbay.jetty.runner.Runner -- --port 8080 /var/tmp/helloworld
curl http://localhost:8080/

Next we need to configure authbind to let you bind to port 80 as a regular user. Unfortunately, Authbind has a bug in that it doesn't let you just configure permissions for 0.0.0.0/0, and you have to define one row for all addresses which start with bit 0 and one row for bit 1. A bit funny, but it works.

echo '0.0.0.0/1:1,32000' > authbind.conf
echo '127.0.0.0/1:1,32000' >> authbind.conf
sudo mv authbind.conf /etc/authbind/byuid/1000 # assuming that your uid is 1000
sudo chown 1000 /etc/authbind/byuid/1000

Let's test your helloworld with Jetty and Authbind together, notice that we must tell Java to use the IPv4 stack for authbind to do its jobs properly:

/usr/bin/authbind --deep /usr/lib/jvm/java-6-openjdk/bin/java -Djava.net.preferIPv4Stack=true -jar /usr/share/java/ivy.jar -dependency org.mortbay.jetty jetty-runner 7.3.1.v20110307 -main org.mortbay.jetty.runner.Runner -- --port 80 /var/tmp/helloworld
curl http://localhost/

Since everything went swimmingly so far, we'll go ahead and create an Upstart script to automatically start the service when the server comes up:

sudo nano -w /etc/init/helloworld.conf
# Create a file with the following contents:
start on runlevel [2345]
stop on runlevel [!2345]

exec /usr/bin/sudo -u '#1000' \
  /usr/bin/authbind --deep \
  /usr/bin/java -Djava.net.preferIPv4Stack=true -jar /usr/share/java/ivy.jar \
     -dependency org.mortbay.jetty jetty-runner 7.3.1.v20110307 \
     -main org.mortbay.jetty.runner.Runner -- \
         --port 80 /var/tmp/helloworld \
  > /dev/null 2> /dev/null

Now we're ready to test and see that our Upstart script pulls everything together correctly:

sudo start helloworld
curl http://localhost/

If upstart complains that it can't find the service, or something or other, make sure that the exec statement in helloworld.conf is perfect in that it doesn't contain any suprise spaces after the backslashes.

To further customize your environment, take a look at the additional parameters Jetty and Ivy accept:

/usr/lib/jvm/java-6-openjdk/bin/java -jar /usr/share/java/ivy.jar -help
/usr/lib/jvm/java-6-openjdk/bin/java -jar /usr/share/java/ivy.jar -dependency org.mortbay.jetty jetty-runner 7.3.1.v20110307 -main org.mortbay.jetty.runner.Runner -- --help

Have fun!


2011-04-20

Impressed with VMWare Cloud Foundry

Just got my VMWare Cloud Foundry login, and tried my first application there.

I've previously used Google App Engine and Amazon EC2 for production apps, and Cloud Foundry blows them out of water by its ease of use.

The feature I'm most interested to measure is IOPS and disk throughput, though.

I'll have to block out some time to test that, some time this week.

$ vmc runtimes

+--------+-------------+-----------+
| Name   | Description | Version   |
+--------+-------------+-----------+
| node   | Node.js     | 0.4.5     |
| java   | Java 6      | 1.6       |
| ruby18 | Ruby 1.8    | 1.8.7     |
| ruby19 | Ruby 1.9    | 1.9.2p180 |
+--------+-------------+-----------+

$ vmc frameworks

+---------+
| Name    |
+---------+
| grails  |
| node    |
| spring  |
| sinatra |
| rails3  |
+---------+

$ vmc services

============== System Services ==============

+---------+---------+-------------------------------+
| Service | Version | Description                   |
+---------+---------+-------------------------------+
| mysql   | 5.1     | MySQL database service        |
| mongodb | 1.8     | MongoDB NoSQL store           |
| redis   | 2.2     | Redis key-value store service |
+---------+---------+-------------------------------+

=========== Provisioned Services ============


No PostgreSQL 9.0 yet... :(