ColdFusion to Ruby on Rails: Part I

This is the beginning of a journey. I have been developing in ColdFusion for almost exactly a decade now. I have begun the transition to developing in Ruby on Rails. This won’t be a comprehensive comparative analysis. This will be a personal (public) diary of the journey in the hopes that it will provide guidance to anyone in the same or a similar situation. Maybe it’ll be a little entertaining to everyone else.

A friend recently started her journey to learning more about server-side development, and I asked that she write about it as she learns. I hope she does, and I hope you check out her art and writing even before she starts. I was fascinated to read in a short Facebook post explaining how she views a journey I took some 15 years ago. So I had to admit that while my own similar journey feels boring enough to make Fight Club a six-minute film about curing insomnia, perhaps others would get a kick out of watching me struggle to bend servers to my will. If nothing else, I know schadenfreude is strong on the Internet because I visited reddit once.

So about the narrator: I make web applications. For business, for personal use, for fun, for profit and non-profit. I am employed as a “Web Developer” but really am a Senior Software Engineer, System Administrator (Linux), and Database Administrator. The projects I work on are small enough that a single person can reasonably perform those duties. I don’t manage a team of people, I manage the multiple facets of a team of applications.

I like ColdFusion. I like its tag-based syntax. The language does what I need to the point that any language can reasonably be expected to. The server installs on Linux and isn’t terribly difficult to set up. But it’s being neglected in my opinion. And where it isn’t being neglected, it’s got a skeleton crew. I know others don’t like the ColdFusion Server. I know others don’t like CFML. I know others disagree with what I’ve stated. It’s cool, guys and gals. I hear ya and often agree, and I like your panache. Looks like our mileage has varied, so whose round is it?

I’m not jumping off the ColdFusion boat because I think it’s sinking. This isn’t alarmist rhetoric. So why switch?

I want to develop faster at the current quality I can produce. I want to produce better quality, too(eventually). I want to adjust my paradigm to a more modern web architecture. And I want to keep coding fun. After examining as many web application frameworks as I could find, Ruby on Rails is my uninitiated favorite of all the frameworks that promise to do all the things I want.

I like the look of Ruby. With Ruby, I learn a way to do something. Then I attempt something parallel. I guess at a syntax and it works. That, for me, is an indication that I have rapport with a language. The same would be true of Python, but for whatever reason I simply like Ruby better.

In many ways, the selection of a programming language is like the selection of a romantic partner. There are practical considerations: are we compatible emotionally, intellectually, socially? But there are also the non-practical or subjective considerations. One might call them the “indefensible” considerations. Are they attractive to me? Do they hate mayonnaise as much as I do? When they laugh at my jokes, do I feel like their laughter means more than anyone else’s?

So I admittedly have some indefensible affection for Ruby. In the end, those are the real reasons I selected it. I think that may be true for many of us. We pretend that we picked Python or Go or Node.js or Angular/React/Ember for reasons that we can objectively lay out so that everyone knows we’re Good At Computer Talking™. I do have objective reasons, but really I just thought Ruby was the prettiest girl in the room at that party to which my friend made me go. And yes, I edited that sentence to avoid the ending preposition.

Here’s how I might be different than most people learning a new web framework: I don’t want to jump in and start coding right away. While I believe that some of the best education in programming is gained by failing to build things and breaking existing things and learning to succeed and fix, I’ve done that all before. I know it will happen no matter how much I prepare. But I still want to prepare.

So I’m reading. A lot. Online tutorials, published material, and videos. That’s where Part II will begin: the resources.

There are 3 comments

  1. Brad Wood

    Hi Sean, thanks for the reply. As far as ColdBox MVC and CommandBox CLI not being core, I don’t see why that would be any cause for concern. Is not Ruby on Rails a 3rd party improvement over the language of Ruby? In fact, I don’t know of any language right off that has MVC built in– that’s always a library. There are some languages that bundle CLI tools or package managers, but that’s certainly not a given and ones that do often times started as community projects (like npm). Now if you packages themselves– that _would_ be nice to be core, but again that’s not a given in many languages. Coldbox modules are very powerful with their conventions and lifecycle methods that trigger on loading/unloading and are closely tied to the MVC routing mechanism to allow for a hierarchical MVC design pattern that I’m not even sure ROR supports.

    I’d love for you to check out those tools and I’d be happy to help you get started as I think it’s a world of difference banging away at old, procedural CFML tags vs writing modular MVC in sexy script with package management, ORM services, and BDD testing, etc. Here’s a couple links to get you started:

    Regarding succinctness– that’s certainly something I think Ruby is very good at. Were you aware of and using the functional programming features of CFML as well as member functions. All CF’s major data types (arrays, structs, queries, lists, and dates) have chainable member functions including higher order functions like map(), reduce(), and each() that accept function references like closures. CFML also supports all the modern constructs like elvis and ternary operators as well as object literals. There’s a good deal of one-liners nowadays that weren’t possible back in the past, and you likely aren’t using if you’re still using the tag-based templating syntax for business logic! I’d say 95% of what I write is script nowadays and here’s a little sample from an ORM-based CMS built on ColdBox:

    You also have me curious about this two-way communication. Do you mean something front-end like websockets/JS or is this part of ROR?

  2. Brad Wood

    Interesting start of a series… You mentioned liking CFML’s tag based syntax but wanting a more modern web framework. I’m curious if you were using ColdBox MVC along with CommandBox CLI and the script syntax that CF has offered for many years now. I think that combination is a very compelling package in favor of modern CF but I’ve found many people looking to move away from CF aren’t actually using the modern tools it provides. It’s cool if you are just wanting to expand horizons and get a bigger community, but I’m also curious if there’s anything specific that you’re seeing in ROR that can’t be found in modern CFML.

    • sean

      I’ve never used ColdBox or CommandBox. The script syntax I have used, but sparingly.

      If I remember what little I’ve heard of both, they’re third-party improvements to the existing ColdFusion functionality? I guess my first concern would be that if someone else can make CF more modern than Adobe can, well… y’know? Not that I’m opposed to plugins and gems and libraries and such, but it seems like that sort of thing should be core.

      I’ll definitely check it out, though. Even as I transition, it would potentially be a huge time-saver and brain-conditioner.

      To answer your last question: succinctness. There are some amazing ways to push to arrays, to combine queries, and one-line fairly complex ideas. I also like that layouts and views have two-way communication (you should see the “solution” I wrote to dynamically assign tags). Of course, ColdBox MVC probably allows something similar, but again core vs. 3P.</p> <p>Honestly, I probably won’t abandon CFML. I still have many projects to maintain, and I still like how it mixes with HTML, and I know it in my bones. I don’t have to “plan” with CFML, I just write. So it’ll stay in the toolbox, even if it’s not right on the top any more.

Post a new comment