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.

You May Also Like

Thought static method can’t be easy to mock, stub nor track? Wrong!

No matter why, no matter is it a good idea. Sometimes one just wants to check or it's necessary to be done. Mock a static method, woot? Impossibru!

In pure Java world it is still a struggle. But Groovy allows you to do that really simple. Well, not groovy alone, but with a great support of Spock.

Lets move on straight to the example. To catch some context we have an abstract for the example needs. A marketing project with a set of offers. One to many.

import spock.lang.Specification

class OfferFacadeSpec extends Specification {

    OfferFacade facade = new OfferFacade()

    def setup() {
        GroovyMock(Project, global: true)
    }

    def 'delegates an add offer call to the domain with proper params'() {
        given:
            Map params = [projId: projectId, name: offerName]

        when:
            Offer returnedOffer = facade.add(params)

        then:
            1 * Project.addOffer(projectId, _) >> { projId, offer -> offer }
            returnedOffer.name == params.name

        where:
            projectId | offerName
            1         | 'an Offer'
            15        | 'whasup!?'
            123       | 'doskonała oferta - kup teraz!'
    }
}
So we test a facade responsible for handling "add offer to the project" call triggered  somewhere in a GUI.
We want to ensure that static method Project.addOffer(long, Offer) will receive correct params when java.util.Map with user form input comes to the facade.add(params).
This is unit test, so how Project.addOffer() works is out of scope. Thus we want to stub it.

The most important is a GroovyMock(Project, global: true) statement.
What it does is modifing Project class to behave like a Spock's mock. 
GroovyMock() itself is a method inherited from SpecificationThe global flag is necessary to enable mocking static methods.
However when one comes to the need of mocking static method, author of Spock Framework advice to consider redesigning of implementation. It's not a bad advice, I must say.

Another important thing are assertions at then: block. First one checks an interaction, if the Project.addOffer() method was called exactly once, with a 1st argument equal to the projectId and some other param (we don't have an object instance yet to assert anything about it).
Right shit operator leads us to the stub which replaces original method implementation by such statement.
As a good stub it does nothing. The original method definition has return type Offer. The stub needs to do the same. So an offer passed as the 2nd argument is just returned.
Thanks to this we can assert about name property if it's equal with the value from params. If no return was designed the name could be checked inside the stub Closure, prefixed with an assert keyword.

Worth of  mentioning is that if you want to track interactions of original static method implementation without replacing it, then you should try using GroovySpy instead of GroovyMock.

Unfortunately static methods declared at Java object can't be treated in such ways. Though regular mocks and whole goodness of Spock can be used to test pure Java code, which is awesome anyway :)No matter why, no matter is it a good idea. Sometimes one just wants to check or it's necessary to be done. Mock a static method, woot? Impossibru!

In pure Java world it is still a struggle. But Groovy allows you to do that really simple. Well, not groovy alone, but with a great support of Spock.

Lets move on straight to the example. To catch some context we have an abstract for the example needs. A marketing project with a set of offers. One to many.

import spock.lang.Specification

class OfferFacadeSpec extends Specification {

    OfferFacade facade = new OfferFacade()

    def setup() {
        GroovyMock(Project, global: true)
    }

    def 'delegates an add offer call to the domain with proper params'() {
        given:
            Map params = [projId: projectId, name: offerName]

        when:
            Offer returnedOffer = facade.add(params)

        then:
            1 * Project.addOffer(projectId, _) >> { projId, offer -> offer }
            returnedOffer.name == params.name

        where:
            projectId | offerName
            1         | 'an Offer'
            15        | 'whasup!?'
            123       | 'doskonała oferta - kup teraz!'
    }
}
So we test a facade responsible for handling "add offer to the project" call triggered  somewhere in a GUI.
We want to ensure that static method Project.addOffer(long, Offer) will receive correct params when java.util.Map with user form input comes to the facade.add(params).
This is unit test, so how Project.addOffer() works is out of scope. Thus we want to stub it.

The most important is a GroovyMock(Project, global: true) statement.
What it does is modifing Project class to behave like a Spock's mock. 
GroovyMock() itself is a method inherited from SpecificationThe global flag is necessary to enable mocking static methods.
However when one comes to the need of mocking static method, author of Spock Framework advice to consider redesigning of implementation. It's not a bad advice, I must say.

Another important thing are assertions at then: block. First one checks an interaction, if the Project.addOffer() method was called exactly once, with a 1st argument equal to the projectId and some other param (we don't have an object instance yet to assert anything about it).
Right shit operator leads us to the stub which replaces original method implementation by such statement.
As a good stub it does nothing. The original method definition has return type Offer. The stub needs to do the same. So an offer passed as the 2nd argument is just returned.
Thanks to this we can assert about name property if it's equal with the value from params. If no return was designed the name could be checked inside the stub Closure, prefixed with an assert keyword.

Worth of  mentioning is that if you want to track interactions of original static method implementation without replacing it, then you should try using GroovySpy instead of GroovyMock.

Unfortunately static methods declared at Java object can't be treated in such ways. Though regular mocks and whole goodness of Spock can be used to test pure Java code, which is awesome anyway :)