Mary Poppins going Corporate

We at The Product Works always aspire to use relevant tools for our clients. Let it be a 2-person startup or a big company with 100+ tech people at their disposal. We listen to their requirements, ask lots of questions about their needs, then spend days going back with more questions. This is all happening so we can assure we pick the right technology to fit their needs now as well as in the foreseeable future, that fits in what the team at hand can handle. The latter is especially important when you propose to add a new language to learn for a team that is super confident in their own abilities. We took on a contract recently where we took exactly this approach to the test.

The Challenge

Recently we’ve been asked by an established business to talk to them. It all started with a discussion whether we can help them. They had an upcoming project, with a relatively long deadline. They are quite confident with their abilities using the technologies they have been using for a decade or so. But this project provided them with an opportunity to challenge themselves to learn something new, something current that could be used not only internally to them later on, but on their individual careers as well. So after talking a few times, we actually saw a challenge ourselves in this too.

Blown in by the East Wind

We proposed Ruby, the Mary Poppins of programming languages to be used for this. Not only because it would fit well with their current stack, but it is a language and skill that is looked for on the job market right now. Using Ruby would prove that it is a versatile language, that can be used under extremely restrictive circumstances, and it’s easy to learn under 2 week window. 

After the second meeting we realised that there will be lots of constraints with this job. It’s the exact opposite of a startup scenario, where you have all the freedom. Here we had all the boundaries nevertheless we embarked on this journey. Just to list some of the things we had to comply with:

  • Code must be written on site
  • Strict network security
  • Must be written on Windows 7
  • Datastore is Oracle
  • Deploy to WebLogic server
  • 5 days to deliver a working proof of concept application

Now that all was set, we started the work and solve the issues one-by-one.


Workstation Setup

We started the project with selecting a version and build of Ruby that fits the needs of the company and team. We selected JRuby, something that could be easily deployed to their internal servers (no cloud allowed for security and data protection reasons), with minimum version With that build version we got a serious speed improvement along with lot more stability compared to JRuby 1.7.X. After spending good few hours coming up with the list of software needed - this includes IDE, binaries, SQL client - and the list of sites we need access to, we started the work on site.

Osmosis through the firewalls

Soon we realised that this restriction will be the tricky one. Getting JRuby running on the workstation was straightforward, but the minute we attempted to install Gems, we realised we didn’t think of one thing, CDNs. We put on the list but soon realised all gems are served from a CDN ( This road block cost us circa half a day, working with IT support in-house on a Friday afternoon, trying to get a firewall change into place so we can install gems - a must have for Ruby based development. Once we overcame that we had a smooth sailing.

Windows 7 & Oracle

We got comfortable with the workstation, OS and version control, all preselected for us. Ruby proved to be perfect in a confined environment as this, enjoyable to write as always. After 3 days we had a working solution that was running on another person’s workstation, talking to the DB, performing most of the actions it was set out to do. A major win for Ruby and its ecosystem!

Another one was talking to Oracle. Luckily there are lots of help & pointers online. The active record adapters are great help. The only thing we had to add was a .jar file and the plsql gem to handle package and function calls.

Hit the big red button

The next big block was with the deployment. We wanted to package up the application as a .war file, using warbler. We bumped into another issue with access control here. We were blocked from downloading and installing Maven, an apache build tool that warbler uses to generate the .war package. Another round of email ping-pong with IT support on a Friday afternoon, but once resolved, we had a way to package the application! Then the deployment was the first for everyone. The server setup was a custom one, with plenty of help online though. From creating the first package to get the application running on the server, we spent about a day, but learned a lot in the process. And all issues that popped up were related to configuration (memory limits, network access), not the code.

Practically perfect in every way

What was great to see is some of the people in the company got involved. Provided lots of help, showed interest in the code. They even started to make changes to the code, a remarkable act for us, if you consider this was all new to them, the toolset, the language, syntax, etc.

And this shows us the maturity that Ruby and its ecosystem has. Something that is often forgotten, as Ruby is still categorised as a ‘fun tool to use’, not fit for serious work. We beg to differ, dare to say that Ruby is a viable solution for the corporate world. It has a world class community around the globe, it’s durable and portable - we ran the same code on Mac OS and Ubuntu without any issues! And its age should not be a problem, after all Ruby can legally buy its booze in the US as of this year.


TL;DR we built a proof of concept under 5 working days, on an alien environment, with plenty of restrictions. Ruby proven to be a valid choice for an established corporation, excelled in every level throughout the project.