JRuby , Ruby and a world of Pain (Corporations)

At work, we use Ruby and JRuby in various data feeds. Moving important market data about indices and stock prices from one system to another, whilst massaging the data to meet the front-office requirement. It is certainly an amazing work environment and multi-talented team and leadership. Sadly , as with many people out there, we do face certain limitation and this message intent to display such limitation and how corporate and companies can benefit from our example.

Why JRuby?

Funny thing you ask! I wasn't around when the choice was made, however, my brilliant predecessor - and I genuinely mean brilliant - back in 2007 started working with JRuby to connect to our variety of databases. DB adapters were easy to locate for Java, and we use a good amount of Java at work that it seemed perfect to carry on the tradition. It was harder - at least at that time - to connect Ruby simultaneously to more than one database. Therefore, it was easier to wrap the Java Adaptors with ruby classes and use such wrappers to access databases. There could be other reasons for why JRuby, but let's face it, Ruby all together is awesome. (Even though I am a massive #laravel fan)

== I am certain ruby is more capable of handling databases at this stage ==

Ruby is Love, Ruby is Life

Yes, I agree; Ruby is an amazing language, and indeed it is young and I am a relatively Jr. user of the language but there is always a place for improvements.Due to, let's say, strictly regulated environment our choice of technologies often enforced upon us. Even the use of public Gems can be followed with a holy-war of bureaucracy, nevermind the use of windows package managers such as Chocolatey or the use of technologies such as Vagrant.

& So The Pain Begins: Migration to JRuby From JRuby 1.7.16
  • Since I am using the language under windows and with no package managers, and our production and test environments are not connected to the internet, I had to bundle the new JRuby and Gems on my machine, zip it and promote for production.

  • How do we keep track of gems? WE didn't!!! At least not before my latest promotion. At an early stage, we worked on the code, we manually installed gems gem install RubyXL and zipped the package and promoted. However, now we do things more cleanly. Since the introduction of JRuby and Ruby we have had the pleasure of implementing small projects here and there, losing track of any gems. Until I introduced what ancient history - the outside world - have been using for generations, Gemfile.

  • Why not follow SCRUM or any other development strategies? We can't always do that. Because we are not a software-house it's harder to get things done the right way, they have to be done the fast way!! (Trade Mark). For example, Gemfiles were not the problem, or gems to begin with, or even ruby, the problem was getting the authority to use such awesome technologies. The introduction of JRuby was hard enough to achieve nevermind the introduction of more useful Tools.

  • The final issue was not the actual upgrade, nor the refactoring it needed [which wasn't much] but the fact that everyone who's anyone in the project or not even related had to have an input on the matter. And no one treated it as a natural cycle of any software development except my manager and the team who really appreciate such technologies but not always possible to convince others of our beliefs.

Lessons learnt Or Not!!

In any future development using this language or any other, the input of non-techy personals who's worries are never the long term, but the current bank balance will cripple real talent within the team and the organisation. In conclusion, I believe the technology is amazing, and I honestly believe that the company can benefit a great deal from this but with such constraint and an extremely precarious view we won't be able to use the language, nevertheless any public libraries published by the Champions of Open Source World.

To take from this, I urge senior managers to hear what developers have to say. Yes sometimes we love playing with cool tools like Laravel, or Ruby on Rails, but we always have the business at heart and we want to successed within a flourishing business model.