Three.new

Welcome to Ruby Facets. I'm Olivier Lacan and every week on this show I'll talk to you about a few interesting things going on in the Ruby community.

Just a month ago you might have missed the release of Bundler 1.13. I know I did, and I feel bad so let's talk about.

If you're a fan of the brew doctor command from Homebrew which allows you to detect any issues with your installed packages or even your environment, you'll be happy to know that Bundler now has its own doctor. This will be especially useful for those times when you upgrade your operating or your system dependencies like Postgres and and you forget to rebuild gems that depend on these dependencies.

It's also now possible to add or remove support for a specific platforms — like java or mswin — in your Gemfile.lock with the --add-platform and --remove-platform flags to the lock command.

Along with these new features, there are also a few performance improvements to bundle exec, the dependency resolver, and the gem index which should make Bundler snappier. Read the full release blog post to see what cool other feature or improvement this new version brings.

Speaking of Bundler. This past week, Steve Richert published a post highlighting some potential security issues with Bundler's handling of multiple gem sources.

While the Bundler team seems bummed by the way Steve handled this vulnerability disclosure, I feel like it's relatively important for Rubyists to be aware of this issue and potentially update their Gemfiles to account for it.

So let's say you have a private gem server to serve gems that your company created but you don't want published on RubyGems.org. You probably have RubyGems listed as the first source in your Gemfile and your private gem server as the second source. In recent versions of Bundler, you started seeing ambiguous source warnings that hopefully prompted you to explictely specify a source argument for gems that you wanted to fetch from your private server.

As such, it's likely that you expect only these specific gems to be resolved from the private gem servers. Steve's proof of concept however, shows that when a secondary gem server is used for the source argument of a single gem, this last gem server is the one used to resolve other gems which do not have a source argument. This means that even if you didn't tell Bundler to download the rails gem from your private gem server, it will do so if it finds a gem matching that name on the private server.

In other words, despite seeming more specific than a global secondary gem source, these source argument basically act the same way. And after asking André Arko from Bundler team I now understand why: it's an essential shortcoming of the current Gemfile.lock format. Thankfully this will be solved in Bundler 2.0, but there's still a lot of work to be done on that, and this upcoming version will be backward incompatible.

So the issue that Steve describes could occur if your private gem server is compromised. In this hopefully rare situation, there would be no way for you to prevent Bundler from accidentally loading compromised gems from the private gem server instead of rubygems.org... Unless you refrain from using global source declarations and instead stick to source blocks.

In case this wasn't clear enough, you can find links to Steve's post and André's response, in the show notes.

If you're interested in front-end development, you might want to take a second to read Giles Bowkett's blog post titled Elm is the Rails. I've heard a lot of Rails & Ruby folks talk about Elm recently, and I'll admit to being seduced the philosophy behind this new front-end-focused language.

Earlier this month, Abe Voelker wrote a short blog post in which he explains how to add Elm to a Rails application using webpack. Just like [React][react], Elm is something you can drop for a specific section of a Rails application without having to commit to it for your entire app.

This might be a good excuse to give Elm a chance.

Speaking of Giles, he recently published a huge post during which he uses the asset pipeline to spark an exploration of the Ruby community's values.

What's interesting about Giles's post is that he's not just piling on about the asset pipeline, since he acknowledes Richard Schneeman's excellent work to improve it. Instead he uses it as an excuse to address deeper issues within the Ruby community.

The first being the cognitive dissonance between the unofficial motto of the Ruby community: Matz Is Nice So We Are Nice also known as MINASWAN, and the brash personality of someone like David Heinemeier Hansson. I'll let you read Giles' post for yourselves since it's difficult to summarize his points, but I was especially interested by one of his second points: about webpack.

To bastardize it, webpack is essentially a JavaScript asset pipeline. There are however several obvious differences. First would be webpack's performance compared to Sprockets which is essentially calling out to Node within Ruby. Second would that webpack is native to the JavaScript community and has its own flourishing ecosystem.

I'm ashamed to say I has brushed off webpack as yet another redundant JavaScript project, but Giles made me want to give a second chance.

Chris Arcand mentioned on Twitter that Eileen Uchitelle from the Rails core team is currently working on integrating Capybara with Rails to enable easier systems tests.

It's good to see the Rails team taking the time to make more end-user focused tests easier to create. This Pull Request from Eileen hasn't been merged yet so I'll try to keep you posted if it makes it into Rails 5.1.

If you'd like to support Ruby Facets, please take a few seconds to leave a review on iTunes. You can also donate to support the production of the show at patreon.com/rubyfacets or at rubyfacets.com for one-time donations.

Our music was created by bensound.com and this episode was edited by Jamison Rabbe.

Thank you for listening and I'll be back next week with more Ruby Facets.