Ruby Facets

Ruby Facets
By Olivier Lacan
About this podcast
Short and sweet news about the Ruby and Rails community.

Podcasts like "Ruby Facets"   · View all

By Leah Ruby
By Ruby and Friends / Anchor
By Ruby Fremon
By Ruby
Latest episodes
July 7, 2017
rescue from blocks in Ruby 2.5 Did you know that you don't need to use the begin/rescue/end pattern within a Ruby method definition body? If you do, you might have tried like me to apply an inline rescue statement with no begin or end inside of a normal Ruby block, say a block passed to Array#each for example. But... it doesn't work. Although it works fine inside method bodies, this is invalid syntax in Ruby 2.4 and prior, which is kind of infuriating because putting a rescue statement at the same nesting level as the do statement makes rescue operation very neatly visible. Thanks to Josh Cheek however, this oddity will disappear from Ruby 2.5 which should arrive this coming Christmas. One caveat is that the new behavior will not apply to blocks created with curly braces instead of do/end keywords. Which honestly makes a lot of sense. Rails ❤️ Yarn & Webpacker For a few years, it felt like the Rails community was at odds with the movements of the front-end web development community. It's likely the crazy pace of change in the JavaScript community had a lot to do with this, along with some vague CoffeeScript-fueled isolationist tendencies on the Ruby side. But since the release of Rails 5.1 in late April, a much smoother bridge now exists — beyond Sprockets — between the Rails world and the front-end world. First, Yarn, which arrived in late 2016 and finally brought the crucial enhancements npm sadly failed to bring for years: lockfile support just like Bundler, and faster dependency resolution and download. Yarn is now a first class citizen in the Rails ecosystem with its own bin/yarn command. Second, webpack which can replace Sprockets in the often complicated task of bundling multiple different assets together into one application package for the production environment. Rails 5.1 brought along the webpacker gem which brings a much appreciated tighter integration of Webpack into Rails, to avoid having to deal with heaps of configuration. So while I still default to Sprockets in most of my Rails applications, if I'm ever going to integrate a front-end stack driven by React, Angular, Vue, or Ember then I'm most likely going to reach for Webpack. System Tests in Rails 5.1 Speaking of Rails 5.1, it's hard to overstate how crucial the work of Eileen Uchitelle has been towards the difficult task of bringing real end-to-end tests to the default Rails stack. We've had requests tests, controller tests, and integration tests in the past but the latter notoriously ignored the gigantic elephant in the room that is JavaScript support in those integration tests. By integrating Capybara natively with a default Selenium Chrome driver, Eileen has not only made it easy to really test your Rails application as a user would in their browser, she's also solved some very problematic issues with the way those integration tests behaved in the past. In the way I've been testing the Rails app for years, our JavaScript driver would always create independent threads to run the JavaScript examples which would use its own database connection separate from the one used inside the tests. The usual database transaction which rolls back after a test runs meant that the headless browser's own connection wouldn't see any of the records created before the browser connection started, and vice versa. This forced us to use database truncation around the JavaScript examples and made it impossible to intermingle JavaScript & non-JavaScript tests. This is something that was solved in Rails 5.1 by Matthew Draper. The system test opens a connection to the database that is then shared with the headless browser so they both see the same temporary database records. This alone is going to simplify user-focused feature testing a lot. Active Storage in Rails 5.2 Just as I was finishing this episode, DHH released a new gem called Active Storage. The goal is to finally address the issue of having to store data on a remote server like Amazon S3 which used to require gems like CarrierWave or Paperclip. On his blog, Mike Gunderloy went over the basic setup and interface which allows you to use the usual file_field form helper after defining sort of a virtual association inside your models. For instance, a User can define has_one_attached :avatar and Active Storage will take care of uploading the data submitted to the form straight to the storage provider. This won't be available inside of Rails until Rails 5.2 but nothing prevents you from testing it with rails master.
March 23, 2017
What makes Rails a framework worth learning in 2017? Back in January, David Heinemeier Hansson answered the question What makes Rails a framework worth learning in 2017? on the Q&A website Quora. After a few years when JavaScript frameworks have been monopolizing the limelight, it seems like there's enough new framework fatigue for Rails to become an exciting proposition once again. And it's interesting to see that DHH answers this question by saying that the same thing that made Rails exciting in 2004, still make it so in 2017. It's a full-stack web framework that does it all. While acknowledging JavaScript frameworks like React and Angular, DHH underlines the fact that despite all the front-end progress and excitement, there's always a need for the back-end for databases, computing, job queueing, mailers, push notifications, and much more. It's an interesting post that sets the tone for the upcoming Rails 5.1 release later this year. Ossert You probably know about Ruby Toolbox and other similar tools to find popular Ruby libraries and tools. While popularity is always somewhat relevant when picking an off-the-shelf solution, because if more people use something the more likely someone is to keep maintaining it, it's definitely not a panacea to determine the maturity and quality of an open source project. Sergey Dolganov from Evil Martians created OSSERT, an open source project classification system that takes a lot more than popularity into account. It breaks projects down into three main components: Maintenance Popularity Maturity Each of these components includes a metric ton of signals in order to deliver a grade from A to E (for experimental). For Maintenance, OSSERT looks at issue and pull request processing times, active issues and pull requests, number of releases, commits, commits since last release, etc. Popularity looks at users, issue reporters, watchers and contributors, questions on StackOverflow and the ranks of people who ask and answer them. Finally Maturity looks at the number of users creating issues, commenting, submitting Pull Requests, existing forks, dependent libraries, and so much more. I don't think I've ever come across a more refined tool to find sustainable open source projects before. It does have some flaws (notably established projects which require low maintenance) but for the majority of dependencies, it's a great idea to look at OSSERT. The Difference Between to_s & to_str In Ruby There's nothing quite like a good blog post looking at core Ruby classes you often take for granted. Marc Gauthier wrote about the subtle differences between Ruby's to_s and to_str methods. While they look very similar, to_s is defined on Object, which means virtually every Ruby object responds to it. to_str however isn't defined on Object and usually means that the object CAN behave like a String even if isn't necessarily an instance of the String class itself. Therefore calling to_str on objects that define it may not actually return a String instance, but merely a String-like object. One more example of something that quacks but isn't necessarily a duck. ROM 3.0 Piotr Solnica announced in late January the release of ROM 0.3.0 which includes the first stable versions of rom-sql and rom-repository. From now on, all relations will have schemas, which means the schema API is now available from all adapters. Speaking of adapters, the Postgres one now supports more types like enum, point, and inet. You can now pass relation objects to join, left_join, and right_join methods; and there's a new assoc method on Relation instances to easily prepare a joined relation. If you want to coerce data from a column that uses a special type like JSONB, you can easily have it cast as a special type automatically when it's being read from the database. If you've only ever been exposed to ActiveRecord, I recommend looking at ROM, which alongside Sequel makes for a very interesting ORM alternative. Ruby Coercion Protocols Speaking of coercion. Luca Guidi — author of the Hanami web framework — wrote a two part series on Ruby Coercion Protocols. In the post, Luca laments the over-reliance on type checking with the is_a? method in gems since it makes it difficult to define Ruby classes that act like core classes but don't necessarily inherit from them. This also leads to cruft from what Luca describes as unneeded inheritance when people do inherit from core classes like Float without thinking about the invisible public API they suddenly expose on their objects, which now implement all of Float's public methods. Instead of relying on type checking, his simple solution is to attempt to coerce inputs by simply calling explicit coercion methods like to_f on them. By doing this we allow any all object that implement to_f to become compatible with our interface instead of denying them entry solely based on their identity. Similarities with the real world are probably not coincidences. Two screencasts, two ways to erradicate Ruby nil values A common struggle for Rubyists is dealing with nil values. We can wrap things in conditional to blanket ourselves against them, litter our code with ampersands, ... or we can use the Object-oriented power of Ruby to embrace them. In a Ruby Tapas joint venture with Upcase, you can discover two ways to eradicate nil values by using the Special Case and Null Object patterns. The basic idea of the Special Case pattern is simple, if you're afraid of the special case, extract an object for this special case. So the next time you check that current_user, think about making a GuestUser class that responds to the same methods your current_user would. The Null Object pattern merely expands on that idea to push it a bit further. Remember that all Ruby Facets listeners can get a 10% off discount on a Ruby Tapas subscription which in turn helps to fund the production of the show. I can't think of a better way to make something out of nil. To get that discount simply use the coupon code "rubyfacets" spelled as one word on the subscription page.
Jan. 24, 2017
Ruby 2.4.0 Since Ruby Facets took a Winter break, we missed the joyful release of Ruby 2.4 on December 25th. Aside from the release blog post which listed the marquee features and improvements of this release, I highly recommend Jonan Scheffler's post on the Heroku blog which goes a LOT more in-depth about some of the changes. One of the most exciting for me is the introduction of the binding.irb command. It's a copycat of the binding.pry command from the Pry gem which allows you to open a breakpoint and stop execution of your Ruby program to inspect the state of code. This is an extremely useful debugging tool that until now required adding a gem to your Gemfile. If you've only ever done debugging with put statements, you really should try this out. Later in the post, Jonan goes full Ruby Under A Microscope on the way Hashes are actually implemented in Ruby. He shows how Vladimir Makarov's patch for Ruby 2.4 improved the performance of Ruby Hashes by more than 40% on modern CPUs. Jonan also goes wayyyyy too deep for my puny little brain on unified integers — meaning Fixnum and Bignum becoming the new Integer class. Finally he covers the thankfully timid new rounding behavior changes which almost caused a few breaking changes in 2.4. TruffleRuby It's truffle season. I don't mean the delicious subterranean fungus. I mean TruffleRuby. That would be the new name of the project once known as JRuby + Truffle. It was quite a mouthful so the new name was probably wise. More importantly, the project's maintainer — Chris Seaton — announced a few days ago that TruffleRuby now passes 100% of the Ruby language specs. This is quite an accomplishment for such a relatively new alternative Ruby implementation. Such implementations — especially the ones that aren't written in C — often struggle with the native C extensions commonly found in Ruby gems like nokogiri. TruffleRuby is supposed to sidestep this issue by using an LLVM bitecode interpreter which essentially can translate the C code into something the Java Virtual Machine can understand. But the most impressive feature of this project is its performance goal. The optcarrot benchmark which is being used as the measuring stick for the Ruby 3x3 project — which aims to make Ruby 3.0 3 times faster than Ruby 2.0, runs 9 times faster on TruffleRuby. Granted, there are still a lot of things left unfinished in the implementation. For example, the boot time for a simple hello world program is about 10 times slower than CRuby right now, but it should be possible to bring it to the same speed. TruffleRuby isn't merely an academic research project either. It now passes 100% of Rails' Active Support and Active Model tests, as well as 98% of Action Pack tests. Active Record, Action View and Railties are nearly there. It looks like there are a lot of interesting performance improvements for Ruby on the horizon. Bundler 1.14 Bundler 1.14 just came out with a loooot of bug fixes from the ever prolific Samuel Giddins. On the performance side, running require "bundler" should be five times faster, and gems can now install in parallel when running on rubygems 2.0 and greater. Feature-wise there are new improvements to the bundle doctor command — which checks the operating system dependencies for the gems listed in the Gemfile to ensure they're present, for example for the pg gem that would be a postgres installation. Now bundle doctor will first run bundle check to ensure that all the gems in the Gemfile have been installed on the local machine. If you're concerned about security, Bundler finally validates gem checksums when installing them to compare them with records which could prevent man-in-the-middle attacks. There are a lot more subtle improvements and new features in this version so I highly recommend scanning thorough changelog for this release and running gem update bundler to get the new shiny. Kaminari 1.0.0 I remember when I was mostly a front-end developer and I knew very little about Ruby. Most of what I was exposed to at the time where these cool HTML-focused gems like formtastic, simple_form, will_paginate, and kaminari. Well, version 1.0 of Kaminari is now out with some major changes. First, no more Ruby 1.9.3 — which is unsupported anyway. JRuby 1.7, Rails 3.2 and 4.0 are also no longer supported. Separate gems for specific platforms and ORMs have been introduced so you can add kaminari-sinatra and or kaminari-mongoid if you don't use it with Rails or Active Record. There's also a new without_count method to avoid triggering a potentially very slow count query on large tables. Instead Kaminari will infer the previous and next pages based on the current one. Sadly, it will therefore be impossible to list the total number of pages. But it's a nice solution when performance is crucial. Finally there's now an option to display query parameters even on the first page so that other query parameter filters can be persisted if the page is refreshed. Castaway Jamis Buck made a new delightful little thing out of Ruby with Castaway, an elegant domain-specific language that lets you write code to generate a well-produced screencast or presentation. Castaway lets you define soundtrack blocks so you can fade music in and out, and even duck the soundtrack when a voice track is present. You can define scenes that enter and leave with a dissolve transition set to a specific timing, or define background mattes in any color with superimposed text or still images. You can also use still images as pointers to highlight specific parts of the screen during the video and all visual elements are defined as percentages of the screen so the output can be resolution independent. Jamis already made a great demonstration of Castaway in a YouTube video so I will put a link to that in the shownotes for you to watch. It's incredibly refreshing to see people like Jamis have fun with Ruby and make something that actually helps others create and share knowledge. So, thank you Jamis. Ruby's Gems: swot This episode is already a bit longer than usual since we had so much to catch up on but I'd like to introduce a small new segment in which I'll talk about something that isn't quite newsworthy but worth your attention nonetheless. I named the segment Ruby's gems because I may talk about not-so-well-known Ruby features or simply really cool Ruby gems that don't necessarily have a new version but that you should check out regardless. Recently the Code School support team mentioned they were receiving a lot of requests from students around the world who were trying to register through a student discount form but couldn't get past the naive validation for a .edu email address. I was about to try to find some sort of repository of academic email domains when I happened upon the swot gem from Lee Reilly. First, it taught me that .edu domains aren't necessarily academic because prior to 2001, anyone could register one. Second, I was happily surprised by its extremely simple interface. You call Swot::is_academic?, pass it an email string and it will tell you whether it thinks that email belongs to a student or an academic. You can also run the check with a domain name with or without a protocol. Cooler even, the gem can function as a reverse search engine from either an email or a domain to return the name of the school associated with them. So after you give them a discount, you could even welcome students from l'Université Sorbonne-Nouvelle (Paris III) like me and dazzle them with your magic computering.
Nov. 23, 2016
Guilds at RubyConf 2016 Koichi Sasada recently presented a brand new talk at RubyConf a few more details about Guilds, his proposal for concurrent AND parallel programming in Ruby 3. He repeated the motivations behind Guilds, which are that Threaded programming is very difficult in Ruby, that there should be an easier way to make correct concurrent programs, and even more interestingly that it should possible to run these concurrent programs in parallel which is currently impossible with Ruby Threads, leaving multiple CPU cores on server underused. It's somewhat revealing that Koichi walked on stage with a black t-shirt adorned with "Kill Threads!" written on it. While that glimpses at his feelings on the matter, he did reiterate that Guilds is still simply a proposal for Ruby 3 whose name could change. So nothing is written in stone, and he's encouraging discussion on the topic. Koichi expanded a bit on the struggles that Guilds will face in order to be implemented: like Ruby global data, object invalidation when they're moved between Guilds. He also talked a bit more about the plans for its implementation. While he wants to start working on Guilds in 2017, there are yet no clear plans about whether Guilds will be introduced in minor Ruby versions like 2.6 or 2.7 or if it will have to wait for Ruby 3. Finally he also explained that not all existing Thread code will be able replaceable with Guilds but he expects most of it to be. The bottom line appears to be that if Guilds is indeed the future of concurrent and parallel programming Ruby, there's still a lot to be discussed since it will inevitably impact a lot of things in Ruby itself. Ruby Tapas — Understanding Ruby Thread-Local Variables If you've listened to the first episode of Ruby Facets, you may know how much I love Avdi Grimm's excellent short-form Ruby Tapas screencast series. This week — and this our first official scoop — there's something new at Ruby Tapas. Remember how a minute ago I just talked about Guilds and Threads? As it happens, Avdi once published a great episode of Ruby Tapas in which he talks about the very pitfalls that Guilds will hopefully soon address. This screencast — titled "Understanding Ruby Thread-Local Variables" — is now free for anyone to watch. Yes, that includes you. So you can cram on good threadsafe code practice before Ruby finally makes it much less of a headache to deal with. But instead of just flipping the switching from paid to free, Avdi turned this episode into a blog post which will help you understand what Threads are about and why they're so damned tricky to deal with. If that wasn't enough, he also extended a kind offer to Ruby Facets listeners. You can receive 10% off of any Ruby Tapas subscription by using the coupon code "rubyfacets". Not only is this good for your brain and wallet, but by supporting Avdi's great work you'll also be helping fund the production of Ruby Facets since we'll receive a small percentage of your first month's bill at Ruby Tapas. So thank you in advance. Ruby 2.2.6, 2.3.2, 2.3.3, 2.4.0-preview3 These past few weeks have been filled with a ton of new Ruby versions. There was 2.2.6 and 2.3.2 which were simple bugfix releases that included new SSL certificates for RubyGems. Closely followed by 2.3.3 which fixed a regression with module Prepend. I'm still not quite satisfied with the [ChangeLog][2-3-3-changelog] provided with these releases but I'm working on a tool to group changelog items by Ruby Core APIs in order to make some sense of them, sort of like Rails changelogs. But that's not all, Ruby 2.4.0-preview3 was also released. And it looks like this upcoming Christmas gift will bring some nice performance boosts. For example, the new Regexp#match? method is about three times faster than any of the existing match methods previously available. The Array class now defines its own #min and #max methods that are almost twice as fast as the Enumerable equivalents. Beyond performance improvements, there are a slew of interesting changes covered in a very thorough blog post published last summer on the Blockscore blog and titled New Features in Ruby 2.4. Hash#compact and Hash#compact! now part of Ruby 2.4 Ok, one more Ruby 2.4 item not covered in that blog post I just mentioned, and instead spotted by the good people at 2.4 will also bring most delicious Hash#compact and Hash#compact! methods. Why would you want to compact hashes, I sincerely imagine you asking? Well, let's say you have a properly parsed JSON response in which several keys have nil values. Poof! A quick call to compact!, and gone are the keys for the nils. Writing a Rails Feature - Blow by Blow In my 7 years writting Ruby applications, I think I've had the urge to add or change something in Rails about 100,000 times. Of these urges, only a handful of tiny, and barely significant ones turned into actual contributions. It's very easy to be discouraged by lack of knowledge, time, or motivation. But then you come across a blog like Writing a Rails Feature - Blow by Blow. This post is a detailed diary of the inception, conception, eventual implementation, and release of a Rails feature by Richard Schneeman. While the eventual feature itself is obviously useful, what's really compelling about this post is that documents something you see far too rarely: the thought process behind an open source contribution. It doesn't always make sense for that thought process to happen in public of course, since it often involves arcane knowledge of a very particular set of problems. What's heartening however, is to witness that the work doesn't magically happen or get willed into existence by wizards and witches. It's sometimes slow, or is forgotten for a while, or it can even stop abruptly when reality kicks in and builds start to break. The blost post is definitely not short, but if you've ever considered pitching in, you owe it to yourself to read it. Why We Chose Turbolinks If you've ever raged at indefinite spinners suddenly cropping up on websites that used to fully render in less than a second, then it's possible than you too have had some doubts about the looming hegemony of front-end frameworks. It's sort of easy to cast these doubts as cranky Ruby developer complaints until you read something like Jerod Santo's Why We Chose Turbolinks. While the back-end of the site is actually built using Phoenix and Elixir, the front-end is powered by Turbolinks. Yes, the turbolinks that everybody else seems to be disabling in Rails instead of giving it fair chance. Jerod encourages developers to increase the burden of proof for the necessity of front-end frameworks. Since there was only one interface element in that needed to persist across pages on their site, the team decided that it made more sense to avoid bifurcating the codebase, increasing the JavaScript payload, and choosing a framework. Surprisingly, the rewritten Turbolinks 5 was basically a drop-in solution, with a few documented gotchas. So it might be time to give Turbolinks another look.
Oct. 24, 2016 cuts response time in half 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 response times around the world was cut in half thanks to the deployment of CDN mirrors. There are a lot more plans to improve 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 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. When To Be Concerned About Concerns 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. Procodile 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. Swift for Rubyists 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.
Oct. 10, 2016
Intro 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. Bundler 1.13 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. Bundler multiple source vulnerability 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 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 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. Adding Elm to a Rails application 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. Let The Asset Pipeline Die 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. Rails Capybara Integration 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. Outro 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 or at for one-time donations. Our music was created by and this episode was edited by Jamison Rabbe. Thank you for listening and I'll be back next week with more Ruby Facets.
Oct. 1, 2016
Intro 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. Concurrency in Ruby 3 with Guilds Earlier this month Koichi Sasada presented his proposal for a new concurrency model in Ruby 3 called Guilds. His goals are to retain compatibility with Ruby 2, allow for parallelism, reconsider global locks that prevent parallel execution, try to allow fast object sharing, and provide special structures to share mutable objects. Since I spent the better part of this week trying to understand how Guilds may work in order to explain them properly, I've actually published a blog post titled Concurrency in Ruby 3 with Guilds just yesterday. I'll give you the cliffs notes and you can catch up with that post if anything sounds confusing. There are already two ways to attempt concurrency in Ruby: Threads and Fibers. Although you create Threads yourself, their execution is scheduled by the operating system, Fibers however can be scheduled manually. Guilds are a new layer of abstraction built on top of both. Each Guild contains at least one Thread, which in turn contains at least one Fiber. Threads from different Guilds can run in parallel while Threads in the same Guild can't. Objects from one Guild can't read or write to objects from another Guild. That is, unless you're using immutable objects. By making the sharing of mutable objects harder, Guilds can operate concurrently without running the risk of both accessing and modifying the same objects, which would cause race conditions and bugs. Now it gets even more interesting. Mutable objects from one guild can be copied to another guild, and even fully transferred, making them inaccessible to its original guild. An attempt read or write to them will then cause an error. Why go through all this trouble? Well one clear reason is performance. With truly parallel execution, Ruby would able to do things it's currently unable to do, giving it powers that are currently making some people reach for other languages. My favorite part of this proposal is that it takes inspiration from other languages like Elixir, and still manages to focus on making things easy on developers. Let's hope we hear more about Guilds very soon. The Next Ruby Speaking of Ruby evolving, Tomasz Wegrzanowski published an interesting piece on the bits of Ruby that could be improved if we didn't care so much about backward-compatibility. Beyond the simple desire to remove "end" statements by adopting Python-like whitespace sensitivity, Tomasz brings some very interesting remarks on the absurdities of module nesting and constant resolution, the still half-baked integration of keyword arguments into the send method, or the silliness caused by to_sym and to_s methods when it comes to dealing with hashes. But I think some of his most interesting suggestions involve new concepts, like the idea that methods on a class could be namespaced using colon-delimited prefixes in order to make convenience methods on core classes like String and Integer more sustainable: for example with the classic Ruby idiom 2.hours + 30.minutes, which could become 2.time:hours + 2.time:minutes. To be sure there not so great ideas in the post, but a very insightful comment by Charles Nutter (of JRuby) gives the post some much needed context. I highly recommend the read. Ruby Tapas 2.0 Last week, Avdi Grimm published the four-hundredth-and-fourty-sixth episode of Ruby Tapas. I remember when Avdi started Ruby Tapas in September 2012 and it feels like it was yesterday. In my mind there is no better successor to Ryan Bates' amazing RailsCasts series than Avdi's short, focus, and always insightful screencasts on Ruby. Last spring, Avdi released a brand new site for Ruby Tapas which surfaces the huge collection of Ruby topics he's managed to cover over the past four years. There's a hefty freebies section where you can get a taste for the chef's style, but if you want to get up close and personal with Ruby I'd highly recommend subscribing to access his premium episodes. It'll cost you 18 bucks a month and Avdi's not even paying me to recommend this. That's how good it is. Programs that rewrite Ruby programs Tom Copeland went over some of the most creative and useful ways in which some Ruby programs write other Ruby programs. Having recently upgraded a large Rails application through multiple versions I definitely support his praise of Yuji Nakayama's transpec which can rewrite RSpec 2 specs to follow RSpec 3 syntax in multiple passes. Tom took a look at how transpec achieves this, and it's just as impressive as the end-result. transpec parses your code and converts it to AST nodes. It has classes specializing in rewriting nodes like the chunks of code using the old ShouldReceive syntax into the new expect syntax, but instead of directly replacing the old syntax with the new, transpec uses a queue which allows it to detect possible collisions between rewrites. Tom also goes over similar gems like rails5-spec-converter, and rubocop. In times when many envy the features of more static languages, it's good to remember that some of Ruby's dynamic magic is also part of its strength as a language. I encourage you to read Tom's entire post, which you can find in the shownotes. Keep Ruby Weird Keep Ruby Weird is happening in Austin on October 28th this year. It's a single-day, single-track conference put on by weird but nice folks like Caleb Thompson, Britt Ballard, Terence Lee, and Richard Schneeman. Speakers this year include the wonderful Katrina Owen, Nick Means, Kylie Stradley, Justin Searls, Craig Kerstiens, Marty Haught, and Thomas Enebo. If you're a new or old Rubyist, there's no better place to get a jam-packed day full of fantastic talks, people, food, and conversations than this weird little corner of the Ruby. As I'm saying this, there are only 24 tickets left, so... ORDER NOW! They're 200 dollars which is considerably cheaper than huge majority of conferences. Outro If you'd like to support this show, please take a few itty bitty seconds to leave a review on iTunes or Google Play. I would also deeply appreciate your donations to help me produce the show in my free time without any sponsors. You can make recurring donations on Patreon or one-time donations on Our dreamy little music was created by and this episode was edited by Jamison Rabbe. Thank you for listening and I'll be back next week with more Ruby Facets.
Sept. 21, 2016
Intro 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. I might talk about new releases from Ruby, Rails, or popular RubyGems; discuss insightful or controversial opinion pieces; or even reflect on trends in the community. You should expect a healthy serving of news with a light sprinkle of opinion on top. And with that, let's begin. Ruby 2.4.0 Preview 2 On September 8th, the Ruby core team released Ruby 2.4.0 Preview 2. Preview 1 was released on June 20th so this new preview should include some fixes to issues reported since then. As a reminder, Ruby 2.4.0 brings a few interesting changes like the merge of the Fixnum and Bignum classes into a single Integer class which requires C extensions to be updated. This could be a breaking change so if you maintain a gem with native C extensions or know someone who does, it might be a good idea to start running some tests on Ruby 2.4.0. 2.4.0 also includes performance improvements to Regexp#match? and the Array#min and Array#max methods. Thread deadlocks should also be easier to debug in this new version thanks to new backtraces and dependent thread information when deadlocks occur. Go read the release blog post on for more details. Sidekiq 4.2 Sidekiq 4.2 from Mike Perham is out with a neat new feature: the ability to live reload code in development mode for Rails 5 apps. This new version also removed the Sinatra dependency by relying directly on Rack instead. It also offers a new option for tuning concurrency with the RAILS_MAX_THREADS environment variable which is also used by Puma. Suture Justin Searls published his Ruby Kaigi talk introducing Suture, a Ruby gem that makes refactoring your Ruby legacy code safer. It's an alternative to existing techniques like characterization testing with test harnesses or A/B-testing with a tool like GitHub's Scientist. Suture tries to define a complete legacy refactoring story by giving you the appropriate tools to record the existing behavior of the code you want to refactor. I highly recommend watching Justin's talk not only to understand the incredible amount of thought he's put into building a serious refactoring tool for Rubyists, but also because Suture is an impressive example of a thoughtfully designed gem. Its feedback mechanisms alone could warrant their own 30 minute presentation. Suture helps you identify target legacy behavior, record its output based on a multitude of inputs, point to a new implementation, and compare the behavior of the legacy and new implementation. If there's any divergence in the output, Suture will let you know. And if the divergence in behavior is due to a false negative, Suture also makes it easy to find out what cause the divergent behavior in the refactored code. You can find a link to Justin's blog post, with slides, a video of the talk and a link to the Suture gem, in the show notes. RubyConf 2016 Tickets are available for RubyConf 2016 in Cincinnati, Ohio. The conference will take place between November 10th and 12th. Ticket prices are either $400 for a normal ticket or $1,000 if you'd like to support RubyConf. I believe the supporter ticket also funds the scholarship program that help people in the community who couldn't otherwise afford to come. If you or your company benefit from Ruby, it's a great way to make our community more welcoming and inclusive. Ruby Together Speaking of making the community better. If you rely on Ruby every day for your work, you should probably consider becoming a member of Ruby Together either yourself or as company member. Ruby Together is a non-profit trade association that funds critical infrastructure projects for the Ruby community like Bundler, RubyGems and So far Ruby Together has managed to raise enough funds to pay a few developers to spend 5 hours per week on maintenance of Bundler and With more members, the association could fund further improvements for Bundler, and RubyGems itself. It could also allow developers to spend more time maintaining these same projects. Memberships for individual developers start at $40 per month and $50 per month for companies. The Ruby Together team also publishes monthly updates about their accomplishments, improvements they've made, and where money was spent. So even if you can't afford to be a member, you should follow their work. Outro If you used to listen to Ruby5, then this first episode of Ruby Facets probably sounded familiar to you. For now you'll only hear from me since I can't really afford to publish more than one show per week with multiple hosts. If you'd like to support Ruby Facets, please take a minute to leave a rating on iTunes or Google Play when the show arrives there later this week. Also I would sincerely appreciate your donations on Patreon to help me produce the show at Thank you so much for joining me on this new adventure and remember to shine on you crazy Ruby.