Four.new

In the first episode of Ruby Facets, I talked about Ruby Together; a membership-based trade association that supports the ongoing development and maintenance of essential Ruby infrastructure.

Recently, the long-term support of Ruby Together yielded a clear benefit for Rubyists around the world: the RubyGems.org response times around the world was cut in half thanks to the deployment of CDN mirrors.

There are a lot more plans to improve RubyGems.org including elasticsearch, metrics for gems, and an ambitious merge between RubyGems and Bundler. André Arko who founded Ruby Together in March 2015 gave a talk a EuRuKo 2016 in Sofia, Bulgaria about the great work accomplished thanks to the support of Ruby Together in the past year. If you don't know the incredible work that goes into maintaining RubyGems.org and Bundler, and how sad it is that so few companies that benefit from Ruby are willing to support it financially.

One of the great benefits of Ruby's maturity as a community is that we get to rely on tools being maintained even during a crisis when it would otherwise have been very difficult for volunteers to help. Keep that in mind if you or your business depend on Ruby every day.

Supporting Ruby Together starts at $10 and $50 per month for individual developers and companies.

My alternative title for Richard Schneeman's new blog post When To Be Concerned About Concerns is The Code That Isn't There.

As a follow-up to his previous blog post on Modules, Richard presents scenarios in which there are betters ways to extract behavior than using modules and concerns.

The most striking example he gives involves loose contracts between the concern and the model. Especially when the code within the concern relies on one of the model's associations for its behavior. If at any point, someone slightly changes the behavior of that same association (by sorting it, or filtering it in anyway), the behavior in the concern will break in very subtle ways that even specs might struggle to warn you about.

Richard's suggestion is to instead inject a class instance within a method on the model itself, and pass to that class's initializer just the data it needs for the behavior it provides. So instead of giving the concern module access to the entire model's methods and associations, you're defining a clear contract. The third-party class receives this array of things, does something with it, and sends back a result or a side-effect.

While injection like this is similar to a Concern module, it caries far lesser coupling. Richard goes on to show a real example within ActiveRecord where concern-like modules make it very difficult to understand what code has access to what. I especially recommend the read if you have refactoring work on your plate right now.

Aside from being one of the best new gem names of the year, Procodile from Adam Cooke is a new tool to manage your application processes in Production and Development.

While it's common to only worry about the Rails server in development, production environments often involve things like running one or several task for a job queue, and maybe a CRON task for periodic but less regular execution of slow running tasks.

In recent years, the use of Procfiles and the foreman gem has spread thanks in part to their support on Heroku. The issues Adam ran into involve Foreman's behavior in production, as a background daemon, and especially when trying to handle seamless restarts without root access to the server.

In the end, Adam came up with Procodile. It's compatible with Heroku & Foreman Procfiles which contain a list of process name and associated commands to start them. Procodile can run multiple instances of each process; handle restarting those processes in different ways; report their status; capture grouped or individual log output; automatically restart any failed process; and even more interestingly it can dynamically manage the quantity of one type of process (for example workers) without affecting others.

Finally, Procodile mimics the behavior of Foreman in development by remaining in the foreground, it works on Linux and macOS, and it's compatible with deployment tools like Capistrano.

If you're impressed by such a well-rounded feature list for a 1.0 version, you're not the only one.

Danny Garcia recently released the second part of his Swift for Ruby Devs: The Basics blog post series.

After spending part one going over syntax differences between Swift and Ruby, and basic data types, this new post goes over control structures like loops, iterators, conditionals, functions, structs, and classes.

I was surprised to discover that dictionnaries in Swift, known as hashes in Ruby, are iterated in reverse order. So the last item added to a Swift dictionnary would be printed first if you looped over it.

Danny's posts are a really nice high level overview that should allow you to get past the first hurdles if you decide to play around with Swift. As a Rubyist I find that Swift finally solves the gag reflex issue I had for years when looking at Objective-C code, despite the somewhat irresistible attraction of the iOS ecosystem.

You can find links to [part 1] and [part 2] of Danny's blog post series in the show notes.