Heroku means Java - It’s not a weird non standard thing

Build your system with JAVA using the PLAY! Framework installed on Salesforce’s Heroku platform.

One of our observations from talking to would-be customers for Salesforce’s Heroku platform is the misconception that it is something weird and non-standard, and should perhaps be avoided because of this. One prospect spent some time between our first meeting and our second meeting testing out the job boards looking for developers with Heroku skills. He understandably wanted to make sure that if he did go forward with ProQuest on a Heroku project, he wasn’t backing himself into a cul-de-sac by inadvertently adopting a weird and esoteric development language.

We would argue that this is not what he should be looking for! Just to be clear – Heroku is a PAAS, a Platform as a Service (which, by the way, uses Amazon Web Services as its underlying IAAS – Infrastructure as a Service). We use Heroku as an abstraction layer to remove complexity and drudgery from your system development challenge.

What you need to find are clever, modern-thinking, pragmatic JAVA specialists (or perhaps Ruby on Rails) that are not set in their ways, and can see how Heroku supercharges their development. Heroku remains one of Salesforce’s best-kept secrets and they seem to be still working out exactly how to effectively move it into the mainstream marketplace.

Fergus Kelledy expands here upon why enterprises should adopt the awesome PLAY! framework on top of the Heroku platform, in order to get maximum bang for buck. It makes JAVA developers happier than you’ve ever seen them before.

If you need to build a custom system – then Heroku plus JAVA makes for fantastic possibilities. Your “time to value” will never have looked like this before. We guarantee it

Heroku moves your developers to best practice

For many, particularly the sceptical, it would be a frustrating experience, but Fergus drove through and came to the conclusion that within a few days his code was stronger and the application better designed because of the way Heroku pushed him to do things in a certain way. Like most of the fine things in life, there’s an investment in time (a day or two) to be made up front as you get to grips with new paradigms. But our position at ProQuest is that if you have a serious application you should be looking toward the long term flexibility that Heroku provides.

Message to business people:

If you are building an application, Salesforce.com’s Heroku provides a fantastic platform, loved by expert programmers for the rapid development of clean code without need to purchase infrastructure. This means low cost, business agility and flexibility. If you have developers embarking on their journey and bringing you budgets, you really should be getting a proper comparison of cloud based development using Heroku.

Message to Technical people:

Here’s Fergus to deliver it. ………

‘As I’ve mentioned I am deploying the Play! framework. Play! is pretty flexible when it comes to its build process, the preferred approach is to use the dependencies.yml file to configure the applications dependencies, however you can also manage a Play! application’s dependencies through maven by deploying the maven plugin within your application. This creates a maven pom.xml file which you can then edit, building the project then adds the libraries configured in the pom.xml file to you application. Great! Well not so great when it came to deploying the Play! application to Heroku. When I first attempted to deploy the application to Heroku, Heroku detected the pom.xml file and thought that the application being deployed was a Java application and not a Play! application. This caused compilation errors during the deployment process.

In order to fix this I had to remove the maven plugin from the Play! application’s configuration and then remove the pom.xml, migrating any dependencies it contained to the conf/dependencies.yml file.

Redeploying my application after removing maven from the equation I then got a different compilation error during the deployment process, complaining about the fact that a required class did not exist. This is despite the application running perfectly locally and also in the Amazon EC2 cloud.

After some digging the problem boiled down to the following:

My Application depended on a 3rd party Play! module called fbgraph-0.3. This is turn depended on a another 3rd party library restfb-1.6.2.jar. However during the course of development I needed to use an updated version of the restdb library to take advantage of the latest functionality offered through the Facebook Graph API. This required me to crack open the fbgraph-0.3. plugins and replace the restfb-1.6.2.jar with the latest restfb-1.6.9.jar. I could then package up the build locally and deploy to Amazon EC2 and all worked as expected.

However with Heroku, you deploy your application’s code only along with its build script, in the case of a Play! application the build script and dependencies are defined in a file called dependencies.yml, this file stilll refers to fbgraph-0.3. Heroku then goes and downloads its copy of fbgrsph-0.3, which of course has the older (1.6.2) version of the restdb library. This then causes the compile to break during deployment.

Luckily Play gives you the opportunity to deploy 3rd party libraries to the /lib directory within your application. By deploying restfb-1.6.9.jar directly to this directory and also editing the .gitignore file to remove the /lib directory and pushing this version of the code to heroku solves the problem.

Other ways to solve this problem would be to raise an issue with the developers of the fbgraph-0.3 Play! module and get them to release a fbgraph-0.4 containing the updated restfb-1.6.9.jar. Alternatively you could host a public repository and publish an updated version of the fbgraph-0.3 and then configure your application dependencies.yml file to point to this custom repository (probably a LOT of work to get this working)

This allowed me to get a clean compile and deployment of the application, at this point we were live in the Heroku cloud!

But that was not the end of the story…