A Retrospective on Ruby in 2015

Progress Bar Uninstalling with the text: 2015
This article was peer reviewed by Thom Parkin and Fred Heath. Thanks to all of SitePoint’s peer reviewers for making SitePoint content the best it can be!

We’ve come to the end of 2015, which was a big year in Ruby. I thought it’d be a hoot to go back and look at some of the epics (major themes) of the year and the stories that comprised them. Kind of like a Agile process retrospective where I’m treating 2015 as a set of sprints and seeing how we did.

In order to play out this contrived idea all the way, I will need to define the epics. I’d say that, almost every year, Ruby has the following major areas/epics/whatever where the community needs to be productive in order to consider that sprint/year a success:

Improve the language
Grow the community
Keep up with the rest of the programming world

Those are the epics I’ve defined. In order to measure how the Ruby community did, I am going to revisit the blog posts, articles, and videos that touch on sub-themes of these epics. I am sure I’ll miss some, but that’s what comments are for, right?

Finally, any retrospective worth its weight in gems needs to look at what didn’t work. I’ll do that to round out our time today. My guess is some astute readers will have plenty to add to my list.

Improve the Language

Ruby

Ruby 2.2 was released about a year ago, but I am going to include it in this year’s backlog. 2.2 added many things to the language, as the following stories attest:

The addition of super method metadata made debugging much easier.
Symbol GC gave the Ruby garbage collector a massive performance boost as was probably one of the best additions to the language in ages.
Oh yeah…another GC change was Incremental GC resulting in more consistent performance when garbage collecting.
There were also some smaller changes to the language that shouldn’t go unnoticed.

Ruby released 2.3.0 on Christmas Day, and it includes the following presents:

You can know freeze all your strings with a CLI option, allowing you to see how much work you’re going to have to do to fix how you handle strings in your code.
If you haven’t heard about the Safe Navigation Operator, then you’re living under a rock.
All releases include bug fixes, but this one sounds bad. That post details how that bug was fixed and is a seriously good read.

Sometimes improving a language means saying goodbye to older versions. Ruby did just that when it ended support for 1.9.3. plays taps Goodnight, 1.9.3, you will be remembered.

One of the most anticipated (and large) improvements in any Ruby interpreter was JRuby 9000:

Here is the announcement of the actual release that enumerates some of the major changes.
The JRuby EU Keynote video is worth a watch to get an idea of just how big JRuby 9000 is. Charles Nutter and the team deserve some huge props.

Another way to improve a language is to learn something new and useful. There was plenty of that:

This Reddit asks what is your favorite Ruby trick and gets tons of responses.
How about really learning how to profile with rack-mini-profiler? Yes, please.
Here’s a whole site dedicated to awesome Ruby stuff.
You can never really know enough about regular expressions, can you?

On that note, I think 2015 was the “Year of In Depth, Performance Related Articles” in Ruby:

Richard Scheeman (who has to be one of the Ruby Blogger MVPs this year) did a fantastic two-post series on heap dumps in Ruby. One and Two
Here’s a post on how to debug memory leaks in Ruby.
Have you ever messed with your Ruby garbage collector settings? Me neither, but maybe we should.

Battle of the Year

Lastly, when a language offers choices to its community, it levels up. A major example of this is the battle between RSpec and Minitest:

If your default is RSpec, maybe try Minitest next time. You might be pleasantly surprised.
If you decided to switch for good, this will help.

OK, OK, so maybe “Battle of the Year” is a tad clickbaity, but I did feel like there was plenty of talk about Minitest vs RSpec this year.

Rails

Just like Ruby 2.2, Rails 4.2 was released around the end of December last year. Again, I am going to lump that into the 2015 backlog, as the reverberations of the release weren’t really felt until this year. Here’s what it brought:

Of course, the best place to look at the changes is the release notes, where you’d see things like ActiveJob, Asynchronous Mails, and Adequate Record.
ActiveJob is easy to use and makes using a queuing system a breeze.
The common task of sending asynchronous mails became easier to test and implement.

Rails is changing as the back-end web landscape changes. Here are some posts to ease the transition to what’s coming:

Rails is increasingly used to create APIs, and here’s some tips on doing it right. Oh, and here’s some more.
Is there a collection of awesome Rails gems? You bet your sweet Ruby there is!.

A major source of issues for Rails has always been security. There were improvements there too:

Here’s how to make sure you configure Rails securely.
Understanding the most common attacks, like CSRF and Rails, can go a long way to improving your work.
Obviously, 4.2 had several point releases, which are mostly about security and bug fixes. Check out the releases for details.

Of course, there were loads of performance related Rails posts:

The Collective Idea blog put out a 4-part series on optimizing Rails memory usage.
Before you do that, though, shouldn’t you understand your Rails performance.
Once you do understand performance, you’ll probably end up tweaking ActiveRecord. That’s two posts from Justin Weiss, another MVP candidate.

Rails 4.2.x did not really have the major changes that core Ruby did, but 4.2 lays the foundation for 5.0, which will have significant changes, methinks.

Off the Rails

It goes without saying that offering new Ruby-based, non-Rails frameworks and libraries improves the language. Here’s a collection of some new stuff from 2015:

Lotus had a big year and is definitely worth checking out if you want a solid OO web framework that isn’t Rails.
Perhaps riding on the coattails of Opal, Volt is a web framework that uses Opal to let the developer write Ruby for both front and back end work.
Pakyow is a new web framework that aims to make real time apps a breeze. Worth a look, for sure.

Grow the Community

Any language that wants to flourish needs to be able to grow the people that know that language. Duh. For anyone that is new to Ruby, there were some posts to help you on board:

Our very own Kingsley Silas penned a pathway for new Rubyists.
Also on SitePoint, Nihal Sahu introduced the Ruby community to people new to the langage.

Diversity in tech has become a very hot topic, and with good reason. Things like Rails Girls and RailsBridge are focused directly on encouraging diversity in Ruby. Here are some stories around diversity from this year:

Stephanie Burns describes her experience in a Ruby code camp. Code camps are popping up more and more, and the format seems to appeal to those we need in our community.
Organizations like Makers Academy offer scholarships to women for the classes they teach.
I really love the release of Hello Ruby, a children’s book to get all kids interested in coding. Seriously, buy this book for someone if you haven’t already.

All in all, it was a good (but not great) year for diversity in Ruby. Here’s hoping this subject gets some more positive support in 2016.

Keep Up with the Joneses

Another survival tactic for any language these days is to ensure that it can change with and integrate with technologies outside the language itself. Ruby has this at it’s core, with 2 of the big interpreters (MRI and JRuby) tapping into external runtimes, by default. Here are some of the big tech topics of 2015, and how Ruby fits in to the mix.

Docker

Containerization is all the rage at the end of 2015, so here’s some posts about Ruby and Docker:

Create the smallest Docker image for your Ruby apps with this post from Travis Reeder.
Testing Rails is easy with Docker, just ask Marko Locker.
Nick Gauthier demonstrates how to parallelize those Rails tests using Docker.

Really, you couldn’t swing a dead cat in 2015 without hitting 10 posts about Docker. Learn Docker if you haven’t, it is worthy of the hype.

Slack

Are you using Slack? Of course you are, because EVERYONE is using Slack. It’s great and useful and worth the GDP of most developed countries. Ruby and Slack are great together, just look:

Create a Slack service in Rails because it’s fun.
Or, do it in Sinatra. Slack loves all frameworks.
Here’s a gem that does all the work of posting to Slack from Rails for you.

Other Languages

Rubyists are always looking at other languages to leverage or learn from to make dev life better. Here are some stories about looking around the programming landscape:

Parse moved from Ruby to Go and gained some sanity.
Rust received a ton of press this year, and this post by Robert Qualls shows how to use Rust with Ruby.
The new Darling of Rubyists, though, has to be Elixir. Read this post to see why some folks are betting on Elixir as the next big thing.

Finally, some other things on the nerd landscape that made a fair amount of noise in Ruby:

React is the current javascript framework of choice. Learn how to use it with Rails here.
If you write web apps in Ruby and aren’t DHH, then microservices are shiny and new. This post shows you how to architect your Rails app as a microservice.

What Didn’t Work

All retrospectives should spend a bit of time going over what didn’t work. It’s easy to be negative, so this section could be huge, but I will only mention a couple of items:

The addition of Spring to the Rails development workflow has been lauded and criticized. Many people feel like this author who gave up on Spring entirely.
Adam Hawkins mentions tons of things the community needs to improve and lays out a high level road map.
I mentioned microservices before, and there was a fair amount of backlash against them. Nick Sutterer (author of many, many gems and the Trailblazer framework) penned this piece on using good design before you go all microservice crazy.
Finally, what ever happened to Refinements? Does anyone use them? MVP Candidate Starr Horne does, but I don’t get the feeling many people do. Should we be?
2015 was the year we learned that Timeout is pure evil. I mean, it’s terrifying.

I am sure I am missing some more things that fell flat in Rubyland. Tell me what I missed in the comments.

And….Scene!

2015 is coming to a close in just a few days. It was a big year for Ruby, a language that still has a bright future in my opinion. What should that future be in 2016? Do you have an opinion? Well, put it in the comments or on the forums. Let’s make 2016 even better for Ruby and our community. Happy New Year!