DDevelopment & Design

4Developers 2010 Review

I’ve been to 4Developers in 2009 in Cracow, together with Tomasz Przybysz and we had very nice impressions, no wonder then I wanted to signed up for 2010 edition in Poznań as well. Tomasz was sick, but Jakub Kurlenda decided to come with me. This time…I’ve been to 4Developers in 2009 in Cracow, together with Tomasz Przybysz and we had very nice impressions, no wonder then I wanted to signed up for 2010 edition in Poznań as well. Tomasz was sick, but Jakub Kurlenda decided to come with me. This time…

I’ve been to 4Developers in 2009 in Cracow, together with Tomasz Przybysz and we had very nice impressions, no wonder then I wanted to signed up for 2010 edition in Poznań as well. Tomasz was sick, but Jakub Kurlenda decided to come with me. This time our company was sponsoring the conference so I had a stand-up banner to carry.

Getting up at 4am is annoying, and you need to get up so early to get to Poznań by car. Thanks god it was  Friday, I could be dangerous if woken up at this hour on Saturday.

After arrival we were invited by high-heels hostesses. Now I’ll be a bit stereotypical programmer for a while: what on earth are so lovely hostesses doing on an IT conference? Yeah, sure they look nice, but hey, I thought I’m paying my money for the knowledge. If I wanted to go for good looking girls, I’d visit a local Salsa club. The best high-heels can do is distract me. And I’d rather you spend my bucks on better food, more speakers or just lower the price instead of this.

Unless, of course, these were local IT students helping for free. I strongly doubt if Poznań has so many female IT students all together in all its higher education facilities, but if that is the case, I’m starting to regret I’ve not moved to Poznań.

While I am at the organizational part, lets say that the rest was quite flawless, with tasty sandwiches, drinks, cookies and console games in between lectures. Two exceptions were: a bad lunch, served at Orbis Polonez hotel (and a total rip-off at 50zł) and no place to sit down while outside of conference rooms.

Not that we had any time, mind you. All the presentations had a tendency to take more than scheduled, and while it’s quite fine with me (it actually means there are people who’d rather listen than go for a cookie and coffee), the host didn’t seem to like it much. I think there should be more buffer time for breaks or maybe even an open space in between, to make everyone happy.

Fighting for live

Let’s get back to the lectures. The conference had four tracks, and I’ve started with ‘Fighting for live – derivatives and successors of Java are taking over the world’ by Michael Hunger. That was a big disappointment. Michael was way too theoretical. I’m afraid nothing from his speech would be useful to anyone in the room. And he didn’t give us much more than what we can actually find on wikipedia: just a brief list of some from 400+ languages running on JVM. The only interesting parts were actually played from youtube. I’ve not been waking up at 4am to watch youtube in Poznań. I can do it back home, you know.  As I said, a total disappointment.

Microsoft Cloud: Windows Azure

Angry and sad at the same time, I’ve decided to switch rooms to see Maarten Balliauw talking about Windows Azure. I’ve been thinking about using Google App Engine for my next project, so I wanted to know what Microsoft has to offer in terms of cloud computing. And boy, they do have stuff in there.

Maarten gave us a quick overview of a few projects surrounding the M$ cloud, and after that showed us how to move a simple ASP.NET application to Azure. Jakub Kurlenda, who I believe never had a chance to work with .NET, was amazed. It can't be that simple – he said – There's got to be a lot of problems with complex solutions. Well my friend, remember that M$ has inherited all the good stuff from Borland togethere with Anders Hejlsberg. Sure it sometimes doesn’t work perfectly, but still their tools are quite sexy. And way easier than anything you can find in Java world.

The Microsoft Azure does look very interesting. You get an MS SQL, Storage Service for unstructured data, front end web servers, back end servers and a AppFabric Service Bus to connect different services in a via-VPN-like manner. You even get an information marketplace Codename “Dallas”, to sell and buy services and data. Now this sound like an App Store of cloud computing, doesn’t it?

I think the war between cloud computing providers is going to be quite a show soon. And no matter whoever wins, I think that Microsoft won’t lose.

Not so Funky It Management

For the third lecture I’ve visited the IT Management track, where Peter Horsten, a guy who moved from Netherlands to Poland to create his company (Goyello) in Gdańsk, gave a speech about Funky It Management, but after half an hour I’ve returned to Java track uninspired. Peter is a great speaker, but for the first thirty minutes I heard nothing I could actually use or didn’t know already, so I wasn’t going to risk the rest of the time.

TopLink Grid and Oracle Coherence

That made me see only half of presentation from Waldemar Kot about TopLink Grid and Oracle Coherence, and I really regret that. Waldi, as he is sometimes called by friends (and notoriously by Jacek Laskowski) works for BEA… errr… Oracle, and while I do not know whether he is only consulting or also building systems for his clients, he is sharp as a Gillette, precise as a laser and full of knowledge. I really enjoyed his talk, there was a nice mix of theory and practice, and finally, some stuff I could actually use at work. Thanks Waldi.

Flex 4 and iPhone news

After a horrible lunch, Piotr Walczyszyn gave us a tutorial in using Flex 4. Years ago, I had a chance to use AMF to communicate between a heavy Flash frontend and a PHP backend, and it worked quite well. I have to note that especially debugging was nice, something I wouldn’t expect from a binary and proprietary format. For the last two years, I’ve been hearing about how easy it is to have a Java backend and Flex rich frontend. A lot of people I’ve met at the last year’s GeeCON conference actually worked that way. I was very interested in the topic and after the show I can tell you this, Flex is a way to go if you want to have a rich (heavy?) Intranet client. I think though, that its use for public/Internet services should be considered carefully. Too much bells and whistles and you are going down on frontend complexity and throughput. But you already know that, don’t you?

If using Java, I’d go for Flex 4 if Wicket is not rich enough for the solution. If Wicket is fine, I’d stay away from anything more complex (and difficult to test). I don’t have a lot of love for GWT, after what I’ve seen at work. But that could be a GXT fault, not a Google failure.

One of the most interesting news Piotr spread, was that Flex is being implemented on Android and… wait for it… iPhone! How’s that possible, you ask? We all know Apple doesn’t want to loose its AppStore market to on-line flash applications. Well, they are building a native Flex to Objective-C compiler, that’s how. If they manage to implement a runtime on Symbian and Windows Mobile, it may be the only truly portable technology. Unless you call HTML 5 a programming language, of course.

Java SE 7

After that Marcin Katas was talking about Java SE 7, which is scheduled for the end of this year. There was a lot about new Garbage Collector, that I don’t really care about, a few thing about OSGi-like solutions to dependency hell,  support for dynamic languages, new concurrency classes, closures and  Project Coin (small changes/additions to the language).

The only thing I can say is: why so late? And why so little?

Especially for Project Coin.  This is actually quite sad. Java as a language is being left behind its competitors. Really, Automatic Resource Management is a concept implemented YEARS ago with using in C#. Come on people, I’d at least expect stuff like .NET LINQ in new version of JDK, not even mentioning some long needed fixes for stuff like collections and generics. It’s been four long years since Java SE 6, there should be a Java SE 8 already.

I really think they should release a new version in a fixed interval of time, like Ubuntu is doing, like it was before Java SE 6. And forget about the hardcore backward compatibility, like with fu…-up generics. Banks that are still using J2SE 1.4 are not updating anyway.

Sobótka on Craftsmanship

And finally, I’ve been waiting for this one, Sławomir Sobótka, owner of Bottega, guy whose blog I’m actively reading, shared his thoughts about software craftsmanship.

That was by far the best presentation at the conference. Absolutely brilliant. I would not be able to put more meaningful information in such a short time and accessible way even had I tried for months. And to be honest, that was also the most important subject, useful to everyone, touching the work of every software developer in the room (and in the other .NET room as well). Kudos to you Sławek.

Too bad, there wasn’t anything new to me then. But maybe I should be actually glad, maybe it means I’m keeping up with the front line. Maybe, or maybe we are just reading the same books, groups and feeds (or I’m reading his blog actually). Anyway, I’m very happy about this lecture. What a beautiful world would it be if everyone was as passionate for craftsmanship and quality as  Sławek is.

I didn’t make it for OSGi speech from Jacek Laskowski. Sorry Jacek, but waking up at 4am doesn’t leave you a lot of strength for the last lecture. I’ve seen Jacek in action a few times, and it’s always a pleasure as he is a great showman (in a positive sense). I hope I’ll see you again at Warsaw’s JUG meetings, but now I’d rather get back to bed before midnight than get sick after the conference like all my friends did. Yeah, I’ve heard that Jakub Kurlenda got down just like Tomasz Przybysz a week ago, after the Winter Agile Tunning.

The price of knowledge has always been high, I guess.

Alltogether it was a very interesting conference and definitely worth the money.

Reviews (in Polish) from others can be seen here and here and here and here.

Solution Architect @ TouK

— Previous article

Winter Agile Tuning Review

Next article —

Tomek's tray notes on Scrum

You May Also Like
NNews & Events

Scalar – będziemy tam z ofertą pracy dla Was

Już w najbliższą sobotę – Scalar – bezpłatna konferencja dla wszystkich zainteresowanych Scalą. TouK ma przyjemność być jednym ze sponsorów wydarzenia. Podczas przerw będziemy rozglądać się za młodszym developerem Scali, więc jeśli jesteś zainteresowany pracą, wypatruj ludzi z TouK. This Saturday – Scalar – a free conference for funs and enthusiast of Scala. TouK has a pleasure to co-sponsor the event. During breaks we'll also look out for a junior Scala developers, so if you're interested, look out for TouK people.
DDevelopment & Design

Multi module Gradle project with IDE support

This article is a short how-to about multi-module project setup with usage of the Gradle automation build tool.

Here's how Rich Seller, a StackOverflow user, describes Gradle:
Gradle promises to hit the sweet spot between Ant and Maven. It uses Ivy's approach for dependency resolution. It allows for convention over configuration but also includes Ant tasks as first class citizens. It also wisely allows you to use existing Maven/Ivy repositories.
So why would one use yet another JVM build tool such as Gradle? The answer is simple: to avoid frustration involved by Ant or Maven.

Short story

I was fooling around with some fresh proof of concept and needed a build tool. I'm pretty familiar with Maven so created project from an artifact, and opened the build file, pom.xml for further tuning.
I had been using Grails with its own build system (similar to Gradle, btw) already for some time up then, so after quite a time without Maven, I looked on the pom.xml and found it to be really repulsive.

Once again I felt clearly: XML is not for humans.

After quick googling I found Gradle. It was still in beta (0.8 version) back then, but it's configured with Groovy DSL and that's what a human likes :)

Where are we

In the time Ant can be met but among IT guerrillas, Maven is still on top and couple of others like for example Ivy conquer for the best position, Gradle smoothly went into its mature age. It's now available in 1.3 version, released at 20th of November 2012. I'm glad to recommend it to anyone looking for relief from XML configured tools, or for anyone just looking for simple, elastic and powerful build tool.

Lets build

I have already written about basic project structure so I skip this one, reminding only the basic project structure:
<project root>

│

├── build.gradle

└── src

    ├── main

    │   ├── java

    │   └── groovy

    │

    └── test

        ├── java

        └── groovy
Have I just referred myself for the 1st time? Achievement unlocked! ;)

Gradle as most build tools is run from a command line with parameters. The main parameter for Gradle is a 'task name', for example we can run a command: gradle build.
There is no 'create project' task, so the directory structure has to be created by hand. This isn't a hassle though.
Java and groovy sub-folders aren't always mandatory. They depend on what compile plugin is used.

Parent project

Consider an example project 'the-app' of three modules, let say:
  1. database communication layer
  2. domain model and services layer
  3. web presentation layer
Our project directory tree will look like:
the-app

│

├── dao-layer

│   └── src

│

├── domain-model

│   └── src

│

├── web-frontend

│   └── src

│

├── build.gradle

└── settings.gradle
the-app itself has no src sub-folder as its purpose is only to contain sub-projects and build configuration. If needed it could've been provided with own src though.

To glue modules we need to fill settings.gradle file under the-app directory with a single line of content specifying module names:
include 'dao-layer', 'domain-model', 'web-frontend'
Now the gradle projects command can be executed to obtain such a result:
:projects


------------------------------------------------------------

Root project

------------------------------------------------------------


Root project 'the-app'

+--- Project ':dao-layer'

+--- Project ':domain-model'

\--- Project ':web-frontend'
...so we know that Gradle noticed the modules. However gradle build command won't run successful yet because build.gradle file is still empty.

Sub project

As in Maven we can create separate build config file per each module. Let say we starting from DAO layer.
Thus we create a new file the-app/dao-layer/build.gradle with a line of basic build info (notice the new build.gradle was created under sub-project directory):
apply plugin: 'java'
This single line of config for any of modules is enough to execute gradle build command under the-app directory with following result:
:dao-layer:compileJava

:dao-layer:processResources UP-TO-DATE

:dao-layer:classes

:dao-layer:jar

:dao-layer:assemble

:dao-layer:compileTestJava UP-TO-DATE

:dao-layer:processTestResources UP-TO-DATE

:dao-layer:testClasses UP-TO-DATE

:dao-layer:test

:dao-layer:check

:dao-layer:build


BUILD SUCCESSFUL


Total time: 3.256 secs
To use Groovy plugin slightly more configuration is needed:
apply plugin: 'groovy'


repositories {

    mavenLocal()

    mavenCentral()

}


dependencies {

    groovy 'org.codehaus.groovy:groovy-all:2.0.5'

}
At lines 3 to 6 Maven repositories are set. At line 9 dependency with groovy library version is specified. Of course plugin as 'java', 'groovy' and many more can be mixed each other.

If we have settings.gradle file and a build.gradle file for each module, there is no need for parent the-app/build.gradle file at all. Sure that's true but we can go another, better way.

One file to rule them all

Instead of creating many build.gradle config files, one per each module, we can use only the parent's one and make it a bit more juicy. So let us move the the-app/dao-layer/build.gradle a level up to the-app/build-gradle and fill it with new statements to achieve full project configuration:
def langLevel = 1.7


allprojects {


    apply plugin: 'idea'


    group = 'com.tamashumi'

    version = '0.1'

}


subprojects {


    apply plugin: 'groovy'


    sourceCompatibility = langLevel

    targetCompatibility = langLevel


    repositories {

        mavenLocal()

        mavenCentral()

    }


    dependencies {

        groovy 'org.codehaus.groovy:groovy-all:2.0.5'

        testCompile 'org.spockframework:spock-core:0.7-groovy-2.0'

    }

}


project(':dao-layer') {


    dependencies {

        compile 'org.hibernate:hibernate-core:4.1.7.Final'

    }

}


project(':domain-model') {


    dependencies {

        compile project(':dao-layer')

    }

}


project(':web-frontend') {


    apply plugin: 'war'


    dependencies {

        compile project(':domain-model')

        compile 'org.springframework:spring-webmvc:3.1.2.RELEASE'

    }

}


idea {

    project {

        jdkName = langLevel

        languageLevel = langLevel

    }

}
At the beginning simple variable langLevel is declared. It's worth knowing that we can use almost any Groovy code inside build.gradle file, statements like for example if conditions, for/while loops, closures, switch-case, etc... Quite an advantage over inflexible XML, isn't it?

Next the allProjects block. Any configuration placed in it will influence - what a surprise - all projects, so the parent itself and sub-projects (modules). Inside of the block we have the IDE (Intellij Idea) plugin applied which I wrote more about in previous article (look under "IDE Integration" heading). Enough to say that with this plugin applied here, command gradle idea will generate Idea's project files with modules structure and dependencies. This works really well and plugins for other IDEs are available too.
Remaining two lines at this block define group and version for the project, similar as this is done by Maven.

After that subProjects block appears. It's related to all modules but not the parent project. So here the Groovy language plugin is applied, as all modules are assumed to be written in Groovy.
Below source and target language level are set.
After that come references to standard Maven repositories.
At the end of the block dependencies to groovy version and test library - Spock framework.

Following blocks, project(':module-name'), are responsible for each module configuration. They may be omitted unless allProjects or subProjects configure what's necessary for a specific module. In the example per module configuration goes as follow:
  • Dao-layer module has dependency to an ORM library - Hibernate
  • Domain-model module relies on dao-layer as a dependency. Keyword project is used here again for a reference to other module.
  • Web-frontend applies 'war' plugin which build this module into java web archive. Besides it referes to domain-model module and also use Spring MVC framework dependency.

At the end in idea block is basic info for IDE plugin. Those are parameters corresponding to the Idea's project general settings visible on the following screen shot.


jdkName should match the IDE's SDK name otherwise it has to be set manually under IDE on each Idea's project files (re)generation with gradle idea command.

Is that it?

In the matter of simplicity - yes. That's enough to automate modular application build with custom configuration per module. Not a rocket science, huh? Think about Maven's XML. It would take more effort to setup the same and still achieve less expressible configuration quite far from user-friendly.

Check the online user guide for a lot of configuration possibilities or better download Gradle and see the sample projects.
As a tasty bait take a look for this short choice of available plugins:
  • java
  • groovy
  • scala
  • cpp
  • eclipse
  • netbeans
  • ida
  • maven
  • osgi
  • war
  • ear
  • sonar
  • project-report
  • signing
and more, 3rd party plugins...