Blog

During the season of holidays, even the code-geeks lift their heads from the computer and ask themselves: what is it that I am doing and why am I doing it? At ZeroTurnaround, the answers came quickly when we had a all-hands-aboard team meeting in Estonia last week.

The answers were quick to come (hey, we need to get back to our code, not fool around and do nothing!), such as that ZeroTurnaround has a product that actually gives value and is needed by our customers (have you heard of JRebel?), that our team consists of intelligent people who take responsibility for their work, and on top of that we can still have tequila shots at work parties. There was something else that still is ringing in my head like a Christmas Carol, which is what Oleg from the LiveRebel team said: “When I look at Lauri’s or Rein’s written code, I think to myself that it’s a work of art!” All in all: We make art with passion in our office.

We hope that our passion for making Java fast and fun helps you write gorgeous code, and inspires you to turn your work into an piece of art. Have a wonderful holidays and a great New Year!

President Toomas Hendrik Ilves of Estonia is a tall, impeccably dressed man with a bow tie whose 45-minute visit to our bigger and brighter offices might at first seem intimidating to a group of geeks. Luckily, President Ilves has a bit of inner geek of his own–the visit marked an occasion to celebrate ZeroTurnaround’s contributions and impact on Estonian economy and awareness and reach of Estonian IT in the world. ZeroTurnaround’s innovations are making waves in the global IT world by winning three awards in a single year (the JAX Innovation Award, Duke’s Choice Award and the Estonian Innovator of the Year Award), and growing the team size by 250% in 2011 alone.

So what did we talk about?

Well, President Ilves is not a JRebel user, so we described our first product line with gusto and snacks, then described LiveRebel and how we see the future of continuous deployment (and continuous delivery). More related to his interests, co-founders Jevgeni Kabanov and Toomas Römer discussed ZeroTurnaround’s global markets, spreading the good word and raising awareness about the Estonian IT sector and e-Estonia, our drive to hire the best developers in the Estonian market, and the company’s ambitious plans for 2012 and beyond.

Thank you, Mr. President, and hope to see you soon for a sauna visit! ;-)

Morning coffee between the man who created JRebel, Jevgeni Kabanov and The President of The Republic of Estonia, Mr Toomas Hendrik Ilves

From Tartu to the World: Mr President's visit was a huge honor to ZeroTurnaround's team and their efforts

How can we together bring Estonian innovative IT products and services into focus?

Pictures by Rein Raudjärv

ZeroTurnaround has become approximately 250% more geeky in 2011, according the our latest numbers. We grew from 14 to 35 team members, expanding our offices in Tartu, Tallinn, Prague and Boston. It’s fair to say that these last months have seriously been focused on building Team ZeroTurnaround! Growth like this can only happen when there is something attracting new, talented developers (maybe it’s our Jobs 2.0 page?). Developers at ZeroTurnaround are looking for a challenging, exciting job environment, fueled by innovative product development, rapid growth and, occassionally, beer. We like to think that this is a chance to be part of creating something new, something that makes a world a better place.

ZT team growth over the years

But let’s face it, the people and the working environment also matter. This year, we have been fortunate enough to go on a team vacation to Crete and opened new offices in Tartu and Boston.  On 11.11.11, we had another party to test out the capacities of the Tallinn office, including our brand new sauna and considering the party went on until the wee hours, we were happy to consecrate a new hub for the best Java developers in Estonia. Here are some pictures:

Anton and Kristina, in charge of Tallinn team & office

We like to do things differently :)

The guests of ZT geek-party listening to Jevgeni’s famous cool-speech

We work hard and now we have a chance to relax thoroughly in our sauna as well

It’s all good, when beer is at hand

Today, we are 35 people from three countries (and many more nationalities). What will the year 2012 bring? Ain’t the sky the limit?
If you want to be part of the most innovative company in Estonia, see vacant positions in ZeroTurnaround here.

Go Java Developers!

Pictures by: Liisi Toom, Aleksandr Motsjonov, Rein Raudjärv

Wow – we won again!!

ZeroTurnaround received the honor of being recognized as the Estonian Innovator of the Year award for 2011. It is heart-warming to be recognized in the country the product is developed.

Each year, Enterprise Estonia, the Estonian Chamber of Commerce & Industry and the Estonian Employers’ Confederation give out awards for Entrepreneurship and Innovation. IT is definitely an important industry sector in Estonia, and also very competitive areas in today’s market. We are happy to have competed so well among other innovative Estonian firms, and thrilled to have received the award.

Our thanks goes to the jury for the prize and our best regards to the other nominees! Congratulations to Martin Koppel, on the left of Jevgeni in the photo, and Fortumo for winning the main prize, Entrepreneurship Award 2011!

It’s been quite a year – just a few months again, we received a JAX Innovation Award for JRebel, which was named “Most Innovative Java Technology” or 2011. In 2009, we got a Jolt Productivity Award. What could possibly be coming next?

Innovation is in our blood ;)!

Here you can see the clips of other nominees and the award ceremony (In Estonian).

While planning my trip to San Francisco for JavaOne (catch me there for a beer), I saw that there is a Jenkins User Conference coming up October 2nd, 2011, just prior to JavaOne. As I was signing up for the event, I started thinking that we’ve been using Hudson/Jenkins for years now. Through the years, certain Jenkins features/plugins have really paid off and been life savers for getting higher-quality software out quicker. So I thought, why not share this with you? Here is a list of my own and the team’s top 10 must-have Jenkins features/plugins.

• Easy Installation
• Easy Upgrades
• Scriptability
• View Filters
• Maven
• Amazon EC2
• HTML Publisher
• Throttle Builds
• Join
• Green Balls

(more…)

GeekOut Estonia 2011 is over and it turned out great – we seldom see so many geeks in one place in Estonia! It was an awesome time for everyone – before the day was half-way done we already wanted to try out a dozen new concepts and frameworks! See what other people had to say about it on Twitter.

(more…)

For couple of weeks now, I’ve been looking into Continuous Integration with multiple branches with Jenkins/Hudson. I’ve searched the intertubes, talked to friends, colleagues and other nerds out there.

My greatest discovery was that although CI is about committing, pushing and getting feedback often (i.e. the CI cluster provides you with feedback that your workstation could never give you in the same amount of time), the true purist CI actually has one more requirement — that the team needs to work on the same baseline.

I wish there was some kind of tooling for not-so-purist CI and I’ll try to explain why…

First, the non-technical view of the problem

I work on products that are distributed as downloads. After a person downloads, it is up to them to update to a newer version if they want to. So I can’t push out quick fixes that get deployed to clients automatically — the software will inform the user when a new version is available, but there are no guarantees that they will upgrade.

This means we need to take extra steps in our quality assurance (QA). In contrast, if your product is offered as a service then most of the time you can push out changes and they are visible to all clients out there. No such luck for me. This limitation puts extra attention on QA.

We have created two main branches, DEV and STABLE. DEV is the mainline that we share. The CI cluster provides extra quick feedback on this branch. It runs a test-suite of our software, testing it on a handful of JEE containers out there (e.g. Tomcat, JBoss and Websphere series). If the tests succeed, then the code is pushed to the stable branch. The CI cluster then runs the test-suite on 50 container versions.

This approach would take the pressure to have a machine or OS that supports so many test environments away from devs. They get quick feedback if their push has broken any container that they did not test locally (e.g. “Did my Resin changes break anything on Glassfish?”)

Okay, I seem to have stuff figured out, so what’s the problem then? Well, if developers want to live in their own branch for a while and still get the benefits of automated testing on a large variety of environments, then they won’t be able to do that. They are not CI engineers.

Technical view of the problem

Jenkins/Hudson uses a notion of jobs. A job is something that is usually tied to a VCS URL and then gets built (run) when there is a change in the VCS repository. The build can do anything, from executing shell scripts to sending out tweets of the status of the build.

The build can produce all kinds of results. In our case, we use Maven and Maven artefacts are the results. The artefacts are stored in one repository for the DEV branch, and in another for the STABLE branch. This is because multiple DEV branch jobs can re-use prebuilt snapshots that won’t conflict with STABLE snapshots.

There are two set of jobs. The DEV jobs and the STABLE jobs. There are two because the VCS urls differ and the maven repositories differ and now we have a problem. The two set of jobs needs to stay in sync. So if we change a job in DEV (e.g. add a new step), we’d want to change a job in STABLE and vice versa.

If devs want to live in their own branch, they need to sync any jobs that they duplicate. And now the job management is just getting out of hand:

• They start the duplication of jobs
• They try to keep them in sync
• They start debugging the jobs (e.g. “Why is there a port race between SAP NetWeaver and OC4J9?”)
• The delete the jobs after integration

Instead of developing the feature, the dev is now becoming a CI engineer. Shouldn’t he just get fast feedback from a large variety of environments without any hassle?

Solutions

The many posts that I’ve read through suggest writing the tooling for branch management. Shell scripts and ANT tasks that duplicate jobs on the filesystem level are popular. Scripts using the Jenkins/Hudson API are also a good choice.

But what if I don’t want to write another set of tooling? This is something that should be provided by the CI software I’m using. I’m sure I’m not the only one out there using branching and wanting CI support for it.

The CI purists will say that I’m doing it wrong and that I should either drop the feature branches or live with the problems. But does it have to be that way?

I’d really like to see a Jenkins plugin that will understand multiple branches, multiple Maven repositories and just deal with the problem. If CI necessarily implies a single branch, maybe we can change the name of these servers to Continuous Integration and Build Automation servers and we could throw out the implication?

We’ll have to wait and see…

Materials used

• Multiple Branches Best Practices – post to Jenkins list
• Is it possible to handle multiple branches where some jobs should run on each one without duplicating – post to Jenkins list
• Parallel Development with Branches – post to Jenkins list
• Configure or Create Hudson Job Automatically – stackoverflow.com
• Continuous Integration with Multiple Branch Development – stackoverflow.com
• Handling Multiple Branches in Continuous Integration – stackoverflow.com
• Continuous integration – Martin Fowler
• Continuous integration – Wikipedia

For a year I’ve been working on two projects using the Play! Framework. The JRebel License Server and LiveRebel. I was evaluating different frameworks for these tasks and it boiled down to a choice between Struts and Play! Framework. Play! seemed the risky, cool, rebellious choice, while Struts was something more like the work horse (somewhat old) who delivers for sure. After some debate within the team we took a chance and went with Play!. During this time I’ve grown to love some features of Play! more than others and would like to share the love.

My Top 5 Play! Framework Features

1) Jobs – get stuff done in the background
2) Templating – intuitive and productive
3) URL mappings and redirects – so easy that it is scary
4) Testing – halfway enforced for better adoption
5) Quick turnaround – happier and productive devs
Conclusions

Jobs

Play! framework jobs provide a way of running program logic “in the background”. Play! will take care of the lifecycle and the timings. For example if you need something to run every 5 minutes you will use an annotation @Every(“5min”) and the job will be run every 5 minutes. I’ve included an example called MemoryUsageLogger which logs the memory usage of the application. Its just dead simple.

@OnApplicationStart
@Every("5min")
public class MemoryUsageLogger extends Job {
  private volatile boolean maxPrinted = false;
 
  @Override
  public void doJob() throws Exception {
    Runtime r = Runtime.getRuntime();
 
    long total = r.totalMemory();
    long free = r.freeMemory();
    long used = total - free;
 
    if (!maxPrinted) {
      Logger.debug("Used: %dM Free: %dM Total: %dM Max: %dM", m(used), m(free), m(total), m(r.maxMemory()));
      maxPrinted = true;
    }
    else {
      Logger.debug("Used: %dM Free: %dM Total: %dM", m(used), m(free), m(total));
    }
  }
 
  private static long m(long bytes) {
    return bytes / 1024 / 1024;
  }
}

Templating

So far I’ve used JSPs (old and XML syntax), Jelly (Hudson plugins), XTemplate and Smarty for PHP as templating engines. I’ve never felt productive in these, writing custom tags that choke when changing the container, fighting with bloated XML or even just learning an obscure templating expression language has not been fun.

Play! template engine uses Groovy as an expression language and also a tag system for reusable components. Groovy is a clean, intuitive, powerful language which is really easy for Java devs to pick up. I also like that it is a separate, well established project vs something that is only meant for templating.

#{list items:resources,as:'res'}
  #{if res.directory}
    <tr class="directory collapsed" rel="${res.id}" parent="${res.parent?.id}">
      <td><a href="#">${res.name}</a></td>
      <td></td>
      <td class="right">${res.lastModified == null ? '(unknown)' : res.lastModified.format("yyyy-MM-dd HH:mm")}</td>
    </tr>
  #{/if}
#{/list}

This all comes with great error messages, even for the templating code. You can quickly tell where you’ve made a mistake. I just hope the templating language will be supported by Eclipse to provide content assist and highlighting.

URL mappings and redirects

Your controllers in Play! contain ton of static methods that adhere to the URLs of your application. For example, if you need to show something for a URL /contacts/list you would implement a method list in a controller contacts (this is the default naming convention that can be changed). Or if you want a page to show an actual contact you would have a method showContact and it will get mapped to /contacts/showcontact.

What if I want to redirect from the list page to a show contact page when there is only a single contact to show? In your Java code in the list method just invoke the showContact method, it’s going to be an HTTP redirect. So easy and readable in Java that it is scary.

Testing

Automated app testing is a difficult subject, there are tons of approaches out there and its all about you picking a couple and trying to use them with your app written in framework X. Play! has a different approach and it comes bundled with a slick interface to run unit, functional and selenium tests against your app. As testing is something that is so easy to “forget about” then something halfway enforced is really welcomed. Besides automating this you can use the same interface while developing vs configuring the tests to run from your IDE or ant/maven/shell.

Quick Turnaround

We at ZeroTurnaround are really into developer productivity. Our flagship product JRebel lets you change your application code and just hit refresh in your browser and you’ll see the changes instantly. Play! framework offers something similar. I have not read enough source code but it seems that with custom extra metadata (see your app’s tmp/bytecode/DEV), a stateless model and the custom runner (play run) they will give you the power of changing code on the fly. If they don’t support the change they will restart your app automatically for you. This is actually a really big thing compared to other frameworks out there.

Conclusions

Play! framework is packed with cool features and this is only my top 5. Of course Play! is no silver bullet and it does have its own set of problems, but that is something for another article. So far Play! has proven to be a productive and intuitive environment to develop in. What are your favourite features of Play!?

Automatically building Eclipse plug-ins has been sort of difficult for quite a while.

Running the build manually from PDE works, but it’s pretty much a black box and you can’t always get what you want from that. It can sign plug-ins when choosing Export… -> Deployable plug-ins…, but it can’t do this when building a whole update site. If you are used to Maven, Ant or another command line build tool, then things like this are truly annoying.

There are, of course, some tools provided by the Eclipse Foundation for headless building of plug-ins, but they don’t seem easy to set up or convenient to use. Tycho for Maven 3 aims to change that, making it possible to build OSGi bundles / Eclipse plug-ins in an environment familiar to most developers and with minimal additional configuration.

Background

Tycho still doesn’t have an 1.0 release, but seems pretty stable, if lacking a few features. It doesn’t yet have a lot of updated or detailed documentation, but I found help in blog posts about building with Tycho. Mattias Holmqvist’s posts, for example, are recommended reading.

The information I found was sometimes outdated, though, or didn’t go into the things that we needed to make a headless build for JRebel for Eclipse, which has had over 800 downloads in February alone and continues to climb the charts on the Eclipse Marketplace. I figured that since others may have similar needs to ours at ZeroTurnaround, it would be cool to share this experience with everyone (*note: this post assumes some experience with Maven and PDE).

First, I’ll describe what we needed from Tycho. JRebel for Eclipse consists of 6 Eclipse plug-ins, some of which depend on each other. One plug-in provides general JRebel/Eclipse integration, another embeds JRebel itself, and others provide debugger, WTP and RAD integration. We needed to be able to:

• use existing meta-data (manifest-first model), so that we can still use PDE for development
• build the whole set of plug-ins at once when doing a new JRebel release
• sign all our plug-ins and features
• build single plug-ins separately to release bug fixes quickly

It was actually quite easy to get the first three requirements met by a Tycho build, but it turned out the fourth one was harder to achieve (more on that later).

At first I just added a pom.xml file to each plug-in and feature, specifying the artifact name, version and packaging type for each. Tycho can even generate a basic pom.xml for you. A parent pom.xml was added to define some common Maven plug-in settings. I also created a new update site project, which only has the site.xml that says which versions of what features to add to the site.

Sample project: Achievements for Eclipse

To make things easier to demonstrate, let’s create a sample project that mimics the setup I used. And to make it more fun (or ridiculous, take your pick), the sample project will add a couple of achievements to Eclipse, similar to Steam, Xbox or Playstation achievements. I got the idea for that from this post. The project structure will be like this:

(more…)

Older Entries »