Should you be actually building all your IBM i apps directly on IBM i? Maybe not.
Not so long ago, I was an RPG developer working on IBM i. I’d been doing it for about 15 years when I came across an article about compiling your own PHP to run in the Portable Application Solutions Environment (PASE). Wow, I thought to myself, imagine being able to easily create web applications on an IBM i. It was revolutionary. Sure, there were ways to serve web pages from the IBM i before then (starting back around 2003) but none that were so easy. I decided this must be the future of the IBM i developer. I knew I had to learn how to write PHP code and run it on the i. So I did; in fact, I Iearned it really well. A few years later, after Zend Core was released, my friend Kevin Schroeder and I wrote a book on the subject.
I later jumped ship and became a Ruby on Rails developer—or more specifically, a full-stack developer since my bag of tricks includes other tools. I traded my IBM i for a MacBook Pro and AWS cloud servers. Well, not literally; old IBM hardware isn’t worth that much. I tell you all this so that, when I start explaining my views on developing Ruby on Rails applications on your IBM i, you know that I am not just some schlep who never touched an IBM i and is biased against it. On the contrary, I loved my IBM i and believe it’s still very powerful and relevant today. However, I also believe that the vast majority of IBM i developers are slowly killing the IBM i. But that’s another story for another time.
The route that I hear most people talking about when developing Ruby on Rails apps for the IBM i is one of actually building those apps on their IBM i. To ensure there’s no room for confusion, what I mean by that is loading Ruby on Rails in PASE, developing apps there, and running them there. I usually try to be somewhat politically correct in my writing, so I’ll make this as delicate as I can: Using the IBM i as your development environment for Ruby on Rails (or similar pairings like Python/Django) is the silliest thing I’ve ever heard of.
What possible good comes of building your apps on your IBM i? OK, maybe you get away without having to hire a Linux administrator (unlikely, but I’ll give you the benefit of the doubt). None of your aging and whining staff has to learn Linux? No, that’s nonsense. In the interest of full disclosure, my editor would not let me swear in this article, so the previous statement was censored. I leave it to your imagination as to what the original draft said. Even using PASE effectively requires enough Linux that you might as well be in a real Linux environment. It’s safer there (in PASE)? Possibly, but unlikely. You didn’t know there was another option? OK, now we’re getting somewhere.
I think we’ve established that there isn’t really any upside of developing/running your Ruby on Rails apps on your IBM i. The few items that might have been considered of benefit are marginal at best, so let’s look at the downside, shall we? Right out of the gate, you’re going to eliminate 99 percent of the development workforce from being willing to build apps for you. Let’s be honest; there are lots of Ruby developers out there, and more are getting trained every day. So why would you force them to learn all the specialized knowledge a programmer needs to develop Ruby on IBM i? Well, the honest answer is you wouldn’t because none of them will apply for that job. On top of that, you’re losing one of the big reasons for using Ruby to begin with: the Ruby community. To put this in perspective, let me tell you a story. When I went to a four-month “bootcamp” to learn Ruby on Rails, one of the first things they taught us was to search for answers to our problems online. In the years since I started developing with Ruby, I can’t think of a single problem that I have run into where I couldn’t find the solution on stackoverflow.com. I’m sure there were one or two, but I don’t recall at the moment what they might have been. The point here is that the solutions are there because I am on a MacBook Pro and using a recent version of Ruby on Rails (just like a billion other Ruby developers), so whatever solution worked for them will work for me 99 times out of 100. That’s a huge benefit; it can save enormous amounts of time and wasted effort. To be honest, this will help you to some degree even if you’re developing in PASE on the IBM i. But it’s going to be limited and hindered by the fact that there are little differences in your environment, configuration, and deployment that will make some of the answers incorrect for you specifically. Don’t feel too bad or singled out about that; Windows has the same problem (if someone tells you they develop Ruby on Rails apps on their Windows system, they’re lying to you).
Enough of the negative. Let’s talk about positives. If you’re using an IBM i, then you know that you’re using an extremely secure and extremely versatile database engine known as DB2. That, ladies and gentlemen, is the reason to develop Ruby on Rails apps for your IBM i: to marry Ruby to DB2 data and to your existing applications. So what do you do? You use the database-agnostic nature of Ruby on Rails to build your application on a MacBook using Postgres or MySQL. What the hell, if you miss DB2 that much, then you can even download DB2 for your Mac/. Then, with a few simple changes to your database.yml file, you can even test your app using real IBM i database tables, all while still running in your local environment on your Mac. Excellent work! You are now a true full-stack developer.
Now let’s talk about deploying your newly written and tested application to your IBM i.
For the sake of argument, let’s assume I’ve convinced you that you should develop your apps elsewhere. If I haven’t, well then…good luck with the shrimpin’, Forrest. But even from those who have been convinced, I can already hear the whining starting, “But, Jeff, won’t we run into difficulties deploying to the IBM i environment if we don’t develop there?” Damn straight you will. But the solution is staring you right in your fluorescent-light-tanned face: Create a Linux partition on your IBM i and run your Ruby application there. After all, that’s where Ruby was built and where it’s designed to run. It’s still secure because the partition is literally in the same machine as your IBM i. The advantages are huge. Once again, you have the advantage of a billion other Linux administrators’ experiences on stackoverflow.com. You’ve got access to all the nifty tools that Linux has available: nginx, unicorn, and bash, just to name a few. Also, in one simple step, you have freed yourself from the need to use PowerRuby.
Don’t get me started on PowerRuby. Oh, OK, get me started.
If you use PowerRuby, you’re tying yourself to whatever upgrade schedule they manage. As of this writing, PowerRuby is using 2.1.6 and Rails 4.0. For the record, the most recent stable release of Ruby is 2.5.1 (released March 28, 2018) and the most recent Rails version is Rails 5.2 (released April 9, 2018). As of March of 2017, Ruby 2.1.x is no longer supported or maintained, which means security patches and bugs are no longer patched back to versions prior to Ruby 2.2.0. In September of 2017, rubyonrails.org issued a press release that stated: “Rails 4.2 is no longer supported except for severe security patches, but the last release introduced a couple regressions that warranted a release. Unless more regressions are found this will likely be the last bug fix release for Rails 4.2.” I’m just sayin’ you may want to look closer at it before using PowerRuby in PASE.
Let’s review. First, develop your Ruby on Rails apps on your MacBook or Linux-based machine. Next, set up a Linux partition on your IBM i to host your Ruby apps. Last, pat yourself on the back; you have just saved yourself from some huge headaches and gained access to a giant talent pool.