DDevelopment & Design

Friends with benefits

Back when I was at my first university, working on my B.Sc., it was obvious for us, students, to always try to get into any possible, open IT event in the town. We were hungry for knowledge, for experience, anxious looking at the future. One of the really bad professors out there, told us on the first lecture, that whatever we learn is going to be outdated the moment we learn it. He said that we won’t be able to keep up the pace, that we will burn out, we will be replaced by some newfags before we even learn to do the job. And there is no hope for us.

It wasn’t a good university, it was a young one. A young university in a small town, with very old professors. Some of those guys were there, because no one else would take them. So yeah, we were anxious. Anxious that we are not getting any good education, anxious we will not find a good job afterwards, anxious we will become burned out before we know it.

But we were also very young, young enough to believe, we won’t be giving it up without a fight. And thus we were learning on our own, reading books, coding, getting together and sharing what little knowledge we had. And we applied for every interesting position around, to get as much experience as we could.

Not that we had many options. As I said, it was a small town.

After B.Sc., I moved to Warsaw. Started my M.Sc. at another university, which turned out to be no better, but it didn’t matter anymore. I had a good job as a programmer, with fantastic, smart people. In half a year, I learned more, than in five years at all the universities.

Then I moved to another company. Changed the technology stack completely. Started anew, and had great time learning from all those smart people around me, and teaching them whatever I could.

And there was not a single event I would attend to, or hear anybody do it. It seemed like a thing of the past. We had so much knowledge to learn inside the company, why move, why go anywhere at all?

And then I switched my technology stack again. I joined TouK. This time, however, it seemed like I could spread a lot more knowledge about TDD, OOP and good practices, than before. But to do that, I had to fill the holes in my knowledge really fast. So I got myself some books, some RSS’es, some tutorials. One day, my boss sent us an invitation for a Warsaw Java User Group meeting. Some guys were coming. I signed up to the mailing group, and off I went.

There I was, back at the University, getting to know other hairy guys at WJUG meetings, learning about their craft, their interests, and their passions. Encouraged by someone, I went to a conference. Then another. I started attending conferences on regular basis. Actually, I started attending all the Java conferences in Poland. And there are quite a few, I tell you.

Something strange happened. Apart from the technologies, personal experiences, tricks and traps, I learned something completely different. I knew I was getting tired by everyday work, that my energy was much higher after right after holidays, and I’d be much less efficient just before one. I knew I could find myself burned out, one day. I heard a story here and there, in the kitchen, over the coffee table. Someone with a sad look would mention, he has no fun anymore. The job became tiresome. Someone would talk about buying a farm. Or a workshop. Getting out of this line of work.

But at those WJUG meetings, at those conferences, my energy was replenished. The enthusiasm and passion for cool technology, hanging right out in the air, would be contagious. The people, with eyes burning bright for great things they could learn and bring back home… I could feel their hunger for knowledge. And I was back, to my student years again, feeling everything is possible. Not anxious about my future this time.

That was great.

I wanted to help those, who make it happen. To somehow thank them. And I could do that in two ways: either by helping organize, or by sharing what I knew. I prepared a small presentation about Craftsmanship for WJUG, and got a positive feedback. Then I had another, about Spring Security, and another, and so on. Then I answered a call for papers, and got myself speaking at conferences. And it was great too. I joined another great group, Agile Warsaw. I even organized a weekly workshop, here at TouK, to get all the shy people to share, and learn how good it feels.

I have to confess, though. Speaking at conferences is a terrible strain for an anti-social, hairy guy like me. There is so much stress involved. If I wanted to be in spotlights, I wouldn’t become a programmer in the first place. No one digs inside computers, because of love for humanity, I suppose.

Local group meetings, like WJUG, are a completely different story, however. Those are semi-formal, with 50-150 people in an old University assembly hall, with half of them hairy sociopaths in Amiga Forever T-shirts or alike, with beards that would make Richards Stallman proud, swearing like Linus Torvalds when he was thanking Nvidia, and making jokes that would fit right into bash.org, xkcd or the Jargon File. It feels good to be around them. It feels at home.

This is as close to demoscene-kind-of-feeling, as my old ass gets. Preparing a talk for them, apart from motivating me to dig the subject thoroughly, is even better.

One of the unforeseen consequences of getting out to conferences and meetings, is that you get a lot of cool gadgets. A hat from oracle, a ninja coder from Amazon, an energy drink from Microsoft with Linux/PHP/Ruby all over it, a nerd pistol, tons of T-shirts. I didn’t have to buy a T-shirt for years. Sometimes, you even get a licence or a ticket.

Thanks to WJUG, I have the IntelliJ Idea and JProfiler, both of which are extremely good and handy pieces of software.

And yesterday… well yesterday, I got a ticket for Devoxx in Belgium, saving me a few hundred Euros.

So in case you didn’t already, get your lazy ass out, and join a local technology group, go to conferences, write a blog, share with people. You’ll be surprised by the unforeseen benefits.

Even if you are a hairy sociopath, like me.

Solution Architect @ TouK

— Previous article

Scrum w Polsce - TouK

Next article —

Inconsistent Dependency Injection to domains with Grails

You May Also Like
DDevelopment & Design

Spock, Java and Maven

Few months ago I've came across Groovy - powerful language for JVM platform which combines the power of Java with abilities typical for scripting languages (dynamic typing, metaprogramming).

Together with Groovy I've discovered spock framework (https://code.google.com/p/spock/) - specification framework for Groovy (of course you can test Java classes too!). But spock is not only test/specification framework - it also contains powerful mocking tools.

Even though spock is dedicated for Groovy there is no problem with using it for Java classes tests. In this post I'm going to describe how to configure Maven project to build and run spock specifications together with traditional JUnit tests.


Firstly, we need to prepare pom.xml and add necessary dependencies and plugins.

Two obligatory libraries are:
<dependency>
    <groupid>org.spockframework</groupId>
    <artifactid>spock-core</artifactId>
    <version>0.7-groovy-2.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupid>org.codehaus.groovy</groupId>
    <artifactid>groovy-all</artifactId>
    <version>${groovy.version}</version>
    <scope>test</scope>
</dependency>
Where groovy.version is property defined in pom.xml for more convenient use and easy version change, just like this: 
<properties>
    <gmaven-plugin.version>1.4</gmaven-plugin.version>
    <groovy.version>2.1.5</groovy.version>
</properties>

I've added property for gmaven-plugin version for the same reason ;)

Besides these two dependencies, we can use few additional ones providing extra functionality:
  • cglib - for class mocking
  • objenesis - enables mocking classes without default constructor
To add them to the project put these lines in <dependencies> section of pom.xml:
<dependency>
    <groupid>cglib</groupId>
    <artifactid>cglib-nodep</artifactId>
    <version>3.0</version>
    <scope>test</scope>
</dependency>
<dependency>
    <groupid>org.objenesis</groupId>
    <artifactid>objenesis</artifactId>
    <version>1.3</version>
    <scope>test</scope>
</dependency>

And that's all for dependencies section. Now we will focus on plugins necessary to compile Groovy classes. We need to add gmaven-plugin with gmaven-runtime-2.0 dependency in plugins section:
<plugin>
    <groupid>org.codehaus.gmaven</groupId>
    <artifactid>gmaven-plugin</artifactId>
    <version>${gmaven-plugin.version}</version>
    <configuration>
        <providerselection>2.0</providerSelection>
    </configuration>
    <executions>
        <execution>
            <goals>
                <goal>compile</goal>
                <goal>testCompile</goal>
            </goals>
        </execution>
    </executions>
    <dependencies>
        <dependency>
            <groupid>org.codehaus.gmaven.runtime</groupId>
            <artifactid>gmaven-runtime-2.0</artifactId>
            <version>${gmaven-plugin.version}</version>
            <exclusions>
                <exclusion>
                    <groupid>org.codehaus.groovy</groupId>
                    <artifactid>groovy-all</artifactId>
                </exclusion>
            </exclusions>
        </dependency>
        <dependency>
            <groupid>org.codehaus.groovy</groupId>
            <artifactid>groovy-all</artifactId>
            <version>${groovy.version}</version>
        </dependency>
    </dependencies>
</plugin>

With these configuration we can use spock and write our first specifications. But there is one issue: default settings for maven-surefire plugin demand that test classes must end with "..Test" postfix, which is ok when we want to use such naming scheme for our spock tests. But if we want to name them like CommentSpec.groovy or whatever with "..Spec" ending (what in my opinion is much more readable) we need to make little change in surefire plugin configuration:
<plugin>
    <groupid>org.apache.maven.plugins</groupId>
    <artifactid>maven-surefire-plugin</artifactId>
    <version>2.15</version>
    <configuration>
        <includes>
            <include>**/*Test.java</include>
            <include>**/*Spec.java</include>
        </includes>
    </configuration>
</plugin>

As you can see there is a little trick ;) We add include directive for standard Java JUnit test ending with "..Test" postfix, but there is also an entry for spock test ending with "..Spec". And there is a trick: we must write "**/*Spec.java", not "**/*Spec.groovy", otherwise Maven will not run spock tests (which is strange and I've spent some time to figure out why Maven can't run my specs).

Little update: instead of "*.java" postfix for both types of tests we can write "*.class" what is in my opinion more readable and clean:
<include>**/*Test.class</include>
<include>**/*Spec.class</include>
(thanks to Tomek Pęksa for pointing this out!)

With such configuration, we can write either traditional JUnit test and put them in src/test/java directory or groovy spock specifications and place them in src/test/groovy. And both will work together just fine :) In one of my next posts I'll write something about using spock and its mocking abilities in practice, so stay in tune.