Ruby Facets

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

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

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

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 in

RubyGems.org 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 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 commu

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 sho

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 s

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 i