DEV Community: Daniel Viklund

Array() in Ruby

Daniel Viklund — Sun, 27 Dec 2020 04:16:59 +0000

When it comes to working with a mix of values or variables, and I want to treat them as an array, I am in the habit of using the Array(...) method to make sure I am always working with an array, without having to explicitly check for a nil or non-array values. What this method does is that it tries to call first #to_ary, then #to_a on the passed argument.

This basically means that if the argument is or can act as an array, it will return itself, otherwise, it will be converted to an array. And since nil.to_a => [], that means we will get an empty array if the argument was nil, which is often what I want.

Confusion over this method

I have seen usages of other methods when what they really wanted was the result that Array() offers. Here is a comparison of this and other array methods, that I have seen it being confused with.

Array(...)

?> Array(nil)
=> []

?> Array(3)
=> [3]

?> Array([3])
=> [3]

Array[...]

?> Array[nil]
=> [nil]

?> Array[3]
=> [3]

?> Array[[3]]
=> [[3]]

Array.new(...)

?> Array.new(nil)
TypeError: no implicit conversion from nil to integer

?> Array.new(3)
=> [nil, nil, nil]

?> Array.new([3])
=> [3]

The last example in particular have been a source of confusion, because it looks to give you exactly what you want when passing an existing array. But as soon as nil is passed, it raises an error. Very dangerous when testing is lacking...

How it can be used

A common scenario where I use Array() is when I want to check if one variable is allowed or valid based on a second variable. This might look like this.

BY_CATEGORY = {
  'fruits' => %w(apple banana orange),
  'vegetables' => %w(carrot cucumber tomato)
}

Array(BY_CATEGORY[category]).include?(item)

And the result will be true or false, without having to check for nil values before checking for array inclusion. Very neat and compact in my opinion.

Here are a few alternatives that I have seen being used and sometimes used myself.

BY_CATEGORY[category] && BY_CATEGORY[category]).include?(item)

(arr = BY_CATEGORY[category]) && arr.include?(item)

BY_CATEGORY[category]&.include?(item)

All of these are variants of checking for nil before checking for inclusion. The first variant avoids assigning a new variable, but has the added expense of accessing the hash twice.

The second variant uses a temporary variable to store the hash value before checking for inclusion which is efficient, but looks quite cumbersome and is disliked by certain style guides.

And the third variant uses the Safe Navigation Operator (&.), which requires at least Ruby version 2.3 (released in 2015)

What about performance?

While I believe that performance differences on this level is most likely neglectable in comparison to other improvements that can be made in production level applications out there, I was interested to know how these examples compare. Obviously there is a cost (however minor) to creating an empty array instance, just to check for an inclusion that will always be false. So I ran some numbers.

BY_CATEGORY = {
  'fruits' => %w(apple banana orange),
  'vegetables' => %w(carrot cucumber tomato)
}

cat1 = 'fruits'
cat2 = nil
item = 'pineapple'

Benchmark.bm do |x|
  n = 10_000_000
  x.report("When arg exists: Array(group[cat]).include?        ") {
    n.times { Array(BY_CATEGORY[cat1]).include? item }
  }
  x.report("When arg exists: group[cat] && group[cat].include? ") {
    n.times { BY_CATEGORY[cat1] && BY_CATEGORY[cat1].include?(item) }
  }
  x.report("When arg exists: (res = group[cat]) && res.include?") {
    n.times { (res = BY_CATEGORY[cat1]) && res.include?(item) }
  }
  x.report("When arg exists: group[cat]&.include?              ") {
    n.times { BY_CATEGORY[cat1]&.include?(item) }
  }
  x.report("When arg is nil: Array(group[cat]).include?        ") {
    n.times { Array(BY_CATEGORY[cat2]).include? item }
  }
  x.report("When arg is nil: group[cat] && group[cat].include? ") {
    n.times { BY_CATEGORY[cat2] && BY_CATEGORY[cat2].include?(item) }
  }
  x.report("When arg is nil: (res = group[cat]) && res.include?") {
    n.times { (res = BY_CATEGORY[cat2]) && res.include?(item) }
  }
  x.report("When arg is nil: group[cat]&.include?              ") {
    n.times { BY_CATEGORY[cat2]&.include?(item) }
  }
end

Which resulted in the following

                                                        user     system      total        real
When arg exists: Array(group[cat]).include?          1.456000   0.000000   1.456000 (  1.458288)
When arg exists: group[cat] && group[cat].include?   1.996000   0.004000   2.000000 (  2.002088)
When arg exists: (res = group[cat]) && res.include?  1.384000   0.000000   1.384000 (  1.384498)
When arg exists: group[cat]&.include?                1.312000   0.000000   1.312000 (  1.314109)
When arg is nil: Array(group[cat]).include?          1.824000   0.000000   1.824000 (  1.828075)
When arg is nil: group[cat] && group[cat].include?   0.584000   0.000000   0.584000 (  0.586510)
When arg is nil: (res = group[cat]) && res.include?  0.612000   0.000000   0.612000 (  0.612291)
When arg is nil: group[cat]&.include?                0.576000   0.000000   0.576000 (  0.577248)

As expected, there was a significant difference when the argument was nil and having to create an empty array. That &. was the fastest in both scenarios is no surprise either since it must be taking advantage of runtime optimisations.

Just note that it works in this scenario since we know that we will only ever be working with nil or array values. There might be scenarios when arg could be a String or other type of objects, in which case &. would try to call include? on that arg, while Array() would first convert it to an array.

Conclusion

As I already mentioned, the performance differences are minor, but if you want to account for it, I would suggest using the safe navigation operator as long as you know it could only ever be nil or array values.

But if you are working with a combination of values where some are arrays and some are other objects, then Array() will be better suited. And if nil will be a rare occurrence, then it is only marginally slower (+10%) than &..

Happy Holidays and Happy Coding!

Force HTTPS for AWS EB behind a Load Balancer

Daniel Viklund — Sun, 09 Feb 2020 13:14:17 +0000

Originally posted on my blog

Elastic Beanstalk is great! It is very easy to get a Rails app up and running on AWS quickly. Perfect for an app developer that prefers not to deal directly with sysops but still wants to deploy to and leverage the services on AWS.

Sooner or later though, you will probably run into something that you can't fix through the web console GUI.

HTTP to HTTPS redirect

It is straight forward to set up your listeners and your processes for the Elastic Load Balancer (ELB) to route the requests to your app, both with and without SSL. But there is no configurable option to redirect all HTTP requests to HTTPS, meaning you have to handle it in your app.

In Rails, you could force HTTPS redirect by adding force_ssl in ApplicationController, but it seems a bit unnecessary. Do we really need the request to go that far, just to be redirected? Plus, should this security setting really be up to the application?

EB Extensions to the rescue

A few years ago, I found the article Enable HTTPS redirect for AWS Elastic Beanstalk with a Rails App behind a Load Balancer, where this issue is addressed. I found it to be a good resource, but unfortunately, the link to the sample file is now broken. The Github repository has been updated and restructured since that article was written, but the folder containing the updated sample files can currently be found on https://github.com/awsdocs/elastic-beanstalk-samples. In case they change it again in the future, I have forked the current state so you can also find those files on https://github.com/dannemanne/elastic-beanstalk-samples

In that repo, there are two files. One is an extension file for Elastic Beanstalk, meant to be placed in the .ebextensions folder of your app source code. This extension creates a customized NginX configuration file, which has the following modifications:

set $redirect 0;
location / {
  if ($http_x_forwarded_proto != "https") {
    set $redirect 1;
  }
  if ($http_user_agent ~* "ELB-HealthChecker") {
    set $redirect 0;
  }
  if ($redirect = 1) {
    return 301 https://$host$request_uri;
  }
  passenger_enabled on;
}

And with the repository being updated, the example also contains those same redirect rules for the asset pipeline location.

# Rails asset pipeline support.
location ~ "^/assets/.+-[0-9a-f]{32}\..+" {
  if ($http_x_forwarded_proto != "https") {
    set $redirect 1;
  }
  if ($http_user_agent ~* "ELB-HealthChecker") {
    set $redirect 0;
  }
  if ($redirect = 1) {
    return 301 https://$host$request_uri;
  }

  error_page 490 = @static_asset;
  error_page 491 = @dynamic_request;
  recursive_error_pages on;

  if (-f $request_filename) {
    return 490;
  }
  if (!-f $request_filename) {
    return 491;
  }
}

Looking at the commit history, this seems to be a more recent improvement.

Configure Phusion Passenger

The other file in the example is a JSON file (passenger-config.json). This file is meant to be saved in the root of your app source code. Doing so allows you to pass options to Phusion Passenger as it boots.

Note! The filename passenger-config.json is correct for Passenger Phusion version 4, which is what Elastic Beanstalk is currently using. If/when they switch to version 5, the config filename will be Passengerfile.json, but that is not needed at the time of this article.

The passenger-config file in this example is needed because the extension is not replacing the original NginX configuration file that Elastic Beanstalk uses by default. It creates a new file in another location. The passenger config file can tell Passenger to use this new NginX config file rather than the default, which is exactly what it does in this example.

Alternative approach

If you prefer to keep the configurations to a minimum, you could replace the original NginX config file (which is located in /opt/elasticbeanstalk/support/conf/nginx_config.erb), but I would recommend going with the approach from the example. If not, then just imagine what would happen when it is time to upgrade to another version of the server image. This updated version might contain changes to the configuration, but you would never know because it is immediately overwritten during deployment.

If instead, you wrote to a custom location, you could (and should) compare the files for possible changes. It's just good practice!

Happy coding!

Resources

Enable HTTPS redirect for AWS Elastic Beanstalk with a Rails App behind a Load Balancer

https://github.com/awsdocs/elastic-beanstalk-samples

Advanced environment customization with configuration files (.ebextensions)

Introduction to configuring Passenger Standalone