Note: If you're using old Errbit version (0.2.0, 0.4.0) and an old Airbrake version (v4) please refer to this manual to make it work with self-signed certificates.
Having an error catcher like Errbit behind SSL is generally a good idea. Especially when Errbit is hosted on a different server than you application (for example when you manage multiple apps with one Errbit instance). In many cases you will have a self-signed certificate (why would you pay for a cert for internal tool). If you try to use it with Airbrake, you will see following error:
Unfortunately, global SSL certificates verification disabling hack (solution that used to work with Airbrake notifier v4) won't work:
# No longer working!
OpenSSL::SSL::VERIFY_PEER = OpenSSL::SSL::VERIFY_NONE
Luckily, Airbrake notifier is written pretty well, so hacking it (and disabling per request SSL certificate verification) is not hard at all. Here's a full code you need to place in config/initializers/errbit.rb to make it work:
module Patches
module Airbrake
module SyncSender
def build_https(uri)
super.tap do |req|
req.verify_mode = OpenSSL::SSL::VERIFY_NONE
end
end
end
end
end
Airbrake::SyncSender.prepend(::Patches::Airbrake::SyncSender)
After that (and configuring Airbrake notifier), you can test it out like this:
If you like reviewing gems, you could often find something like that:
module MyGem
VERSION = '1.0.2'.freeze
end
Did you ever wonder why people tend to freeze their strings? There are 2 benefits of doing so:
First of all, you tell other programmers that this string should not change - never. It should remain as it is and it is intended (in general this is why freeze exists)
Performance is a factor as well. Frozen strings won't be changed in the whole application, so Ruby can take advantage of it and reduce object allocation and memory usage
It's worth pointing out, that Ruby 3.0 might consider all strings immutable by default (1, 2). That means that you can use current version of this feature as a first step to prepare yourself for that.
How can you start using "frozen by default" strings without having to mark all of them with #freeze? For now, you will have to add following magic comment at the beginning of each Ruby file:
# frozen_string_literal: true
# The comment above will make all strings in a current file frozen
Luckily, as expected from Ruby community, there's already a gem that will add the magic comment to all the files from your Ruby projects: magic_frozen_string_literal.
Ok, so we will lose possibility to change strings (if we won't explicitly allow that), what we will get in return? Performance. Here are the performance results of creating 10 000 000 strings all over again (with GC disabled). In my opinion results are astonishing (you can find the benchmark here). With frozen strings a simple "string based" script runs 44% faster then the version without freezing.
If you wonder what will happen, if you try to modify frozen string, here's a simple example you can run:
This description is pretty straightforward for smaller applications, but if you deal with many strings, from many places, you might have a bit of trouble finding an exact place where this particular string was created. That's when --enable-frozen-string-literal-debug flag for Ruby becomes handy:
# frozen_string_literal: true
'string' << 'new part'
# Execute with --enable-frozen-string-literal-debug flag
# ruby --enable-frozen-string-literal-debug script.rb
# output:
frozen.rb:3:in `<main>': can't modify frozen String, created at frozen.rb:3 (RuntimeError)
it will tell you not only the place where you tried to modify a frozen string, but also a place where this string has been created.
Immutable strings make us also one step closer to understanding, introducing and using the concept of immutable objects in Ruby.
Safe navigation operator
Easy nil saving FTW! Finally a ready to go replacement for many #try use cases (however not for all of them). Small yet really sufficient feature, especially for non-Rails people. So what exactly Object#try was doing?
Object#try - Invokes the public method whose name goes as first argument just like public_send does, except that if the receiver does not respond to it the call returns nil rather than raising an exception.
This is how you can use it:
# Ruby 2.2.3
user = User.first
if user && user.profile
puts "User: #{user.profile.nick}"
end
# Ruby 2.3.0
user = User.first
if user&.profile
puts "User: #{user.profile.nick}"
end
At first that might not look too helpful but image a chain of checks similar to this one:
if user&.profile&.settings&.deliver?
# and so on...
Warning: It is worth pointing out that the Object#try from ActiveSupport and the safe navigator operation differs a bit in their behaviour so you need to closely consider each case in which you want to replace one with another (both ways). When we have a nil object on which we want to invoke the method (both via try or safe navigator), they behave the same:
user = User.first # no users - user contain nil
user.nil? #=> true
user.try(:name) #=> nil
user&.name #=> nil
However, their behaviour strongly differs when we have non-nil objects that may (or may not) respond to a given method:
class User
def name
'Foo'
end
end
class Student < User
def surname
'Bar'
end
end
user = User.new
# This wont fail - even when user exists but does not respond to a #surname method
if user.try(:surname)
puts user.surname
end
user = Student.new
if user.try(:surname)
puts user.surname
end
# With an object that has a #surname method the safe
# navigation operation will work exactly the same as try
if user&.surname
puts user.surname
end
# However it will fail if object exists but does not have a #surname method
user = User.new
if user&.surname
puts user.surname
end
NoMethodError: undefined method `surname' for #<User:0x000000053691d8>
Does this difference really matter? I strongly believe so! #try gives you way more freedom in terms of what you can do with it. You can have multiple objects of different types and you can just try if they are not nil and if they respond to a given method and based on that react. However it is not the case with the nil safe operator - it requires an object (except nil) to respond to a given method - otherwise it will raise an NoMethodError. This is how they look (more or less) when implemented in Ruby:
# try method simplified
# We skip arguments for simplicity
def try(method_name)
return nil if nil?
return nil unless respond_to?(method_name)
send(method_name)
end
def safe_navigator(method_name)
return nil if nil?
# Does not care if an object does not respond to a given method
send(method_name)
end
And that's why, when replacing #try with the safe navigation operator (or the other way around), you need to be extra cautious!
Did you mean
A small helper for debugging process directly built in into Ruby. In general it will help you detect any typos and misspellings that cause your code to fail. Will it become handy? Well I tell you once I'll use it for a while.
class User
def name
end
end
user = User.new
use.name
# Error you will receive:
user.rb:7:in `<main>': undefined local variable or method `use' for main:Object (NameError)
Did you mean? user
Hash Comparison
This is a really nice feature. Comparing hashes like numbers. Up until now we had the #include? method on a Hash, however it could only check if a given key is included (we could not check if one hash contains a different one):
Ruby was always about doing things in a short and easy way. Now this can be also said about retrieving deeply nested data from hashes and arrays thanks to #dig. No more || {} tricks or anything like that!
# Nested arrays
nested_data = [
[
%w( a b c )
],
[]
]
nested_data.dig(0, 0, 0) # => 'a'
nested_data.dig(0, 1, 0) # => nil
# Way better than this:
((nested_data[0] || [])[0] || [])[0]
Hash#to_proc
This feature allows to use hashes to iterate over enumerables
h = { a: 1, b: 2, c: 3 }
k = %i{ a b c d }
k.map(&h)
Hash#fetch_values
More strict version of Hash#values_at:
settings = {
name: 'app_name',
version: '1.0'
}
settings.values_at(:name, :key) #=> ['app_name', nil]
settings.fetch_values(:name, :key) #=> exception will be raised
KeyError: key not found: :key
Enumerable#grep_v
I could use this one few times. Instead of negating a regexp itself, we can now just specify that we want all the elements that does not match a given regexp. It also works for filtering by types.
# Regexp example
data = %w(
maciej@mensfeld.pl
notanemail
thisisnotanemailaswell@
)
regexp = /.+\@.+\..+/
data.grep(regexp) #=> ['maciej@mensfeld.pl']
data.grep_v(regexp) #=> ['notanemail', 'thisisnotanemailaswell@']
# Type matching example
data = [nil, [], {}]
data.grep(Array) #=> [[]]
data.grep_v(Array) #=> [nil, {}]
Conclusions
It's been a while since we had a new Ruby version with some additional features. It's not a big step but it definitely brings something to the table. Nothing that we would not be able to do with an old plain Ruby, but now many things will require much less work. If we consider this release as a transitional one, it feels that things are heading in a good direction (towards 3.0).
