Today’s Ruby Tuesday covers Array#delete.

Array#delete removes all items in the array that are equal to the object passed as an argument to the method.

list = [1, 2, 1, 3, 1, 5]
# => [1, 2, 1, 3, 1, 5]
list.delete(1)
# => 1
list
# => [2, 3, 5]
list.delete(3)
# => 3
list
# => [2, 5]

mississippi = "Mississippi".chars
# => ["M", "i", "s", "s", "i", "s", "s", "i", "p", "p", "i"]
mississippi.delete("s")
# => "s"
mississippi
# => ["M", "i", "i", "i", "p", "p", "i"]

Array#delete by default returns nil if the item was not found in the list.

no_fours = [1, 2, 3, 5, 6, 7]
# => [1, 2, 3, 5, 6, 7]
no_fours.delete(4)
# => nil

But if you decide to use Array#delete to remove nils from the array, you may not be able to check that it was removed because nil is returned as the value that was removed.

contains_nil = [1, "a", nil, :foo]
# => [1, "a", nil, :foo]
contains_nil.delete(nil)
# => nil
contains_nil
# => [1, "a", :foo]

If you come across that scenario, Array#delete allows you to specify a block that gets called if the item was not found in the array.

contains_nil2 = [1, "a", nil, :foo]
# => [1, "a", nil, :foo]
contains_nil2.delete(nil) {:bar}
# => nil
contains_nil2
# => [1, "a", :foo]
contains_nil2.delete(nil) {:bar}
# => :bar

As mentioned above, Array#delete removes all items that are equal to the argument passed in. The catch is Ruby has three different equality comparisons: ==, eql?, and equal?. So let’s try a couple of different scenarios to see which equality operator Ruby uses when doing an equality check.

mississippi = "Mississippi".chars
# => ["M", "i", "s", "s", "i", "s", "s", "i", "p", "p", "i"]
mississippi.delete("s")
# => "s"
"s" == "s"
# => true
"s".eql? "s"
# => true
"s".equal? "s"
# => false

So it looks like it is not equal?, but we still have == and eql? left that it could be, so let’s try another scenario.

integers = [1, 2, 3, 4]
# => [1, 2, 3, 4]
integers.delete(1.0)
# => 1
integers
# => [2, 3, 4]
1 == 1.0
# => true
1.eql? 1.0
# => false
1.equal? 1.0
# => false

As we can see here, 1 was removed when 1.0 was passed as an argument, so we see that Array#delete uses the == equality check to determine if the items are equal.

–Proctor

Today’s Ruby Tuesday covers String#to_sym.

String#to_sym operates on a String object, and turns the string into a Symbol.

Why would someone want to have a Symbol instead of a String?

The main reason is that Symbols are created once for the lifetime of a program, and use the same reference. Every reference to the symbol :foo refers to the same instance of :foo, and it doesn’t matter when, or where, in the program lifetime it is.

Strings on the other hand are unique objects, so two strings of the same value are not necessarily the same object, and depends on when, where, and how they were created.

"foo".to_sym
# => :foo
"Foo".to_sym
# => :Foo
"foo".__id__ == "foo".__id__
# => false
:foo.__id__ == :foo.__id__
# => true

One case where this might be useful is where you have to tokenize strings, and are going to want to use them as keys for a map. Think header columns in a CSV file, but please don’t write your own CSV parser, as Ruby has a nice one built in.

"firstName,lastName,preferred name,age".split(",").map(&:to_sym)
# => [:firstName, :lastName, :"preferred name", :age]

The other place where you might want to use String#to_sym is when you are trying to create Symbols that cannot easily be created by just using the normal symbol notation.

":foo".to_sym
# => :":foo"
"peanut butter".to_sym
# => :"peanut butter"

–Proctor

Today’s Ruby Tuesday is on Set#disjoint?.

To start using Sets, we first need to require Set.

require 'set'

Set#disjoint? is useful when you want to make sure a group of items is not in another group of items.

Without using Set#disjoint? you would probably be writing something like the following:

[1, 3, 1, 5, 7].none? { |item| [2, 4, 6, 8].include? item }
# => true

While this works, it does not make the intent of what you are trying to do explicit, which is where Set#disjoint? comes in.

Set#disjoint? operates against a set, and takes another Set as it’s argument, and checks to see if there is no common element between the two sets.

[1, 3, 1, 5, 7].to_set.disjoint? [2, 4, 6, 8].to_set
# => true
[1, 2, 3].to_set.disjoint? [1, 3, 5, 7].to_set
# => false

If a nil is present in both sets, Set#disjoint? treats the nils as equal and returns false.

[2, nil].to_set.disjoint? [1, 3, 5, 7, nil].to_set
=> false

Set#disjoint? works against empty sets as well.

[].to_set.disjoint? [1, 2, 3].to_set
# => true
[1, 2, 3].to_set.disjoint? [].to_set
# => true

If two empty sets are passed to Set#disjoint?, it returns true, as both sets have no elements, and therefore no elements in common.

[].to_set.disjoint? [].to_set
# => true

–Proctor

Today’s Ruby Tuesday is on Enumerable#flat_map.

Enumerable#flat_map became this week’s topic, because yesterday I was doing some exercises in Elixir, and was thinking I could use the flat_map that is defined in Elixir to solve the solution, but it wasn’t working the way I thought it should.

I was getting confused with why it was failing, and I went to check my assumptions of how flatmap works in Erlang, and it behaved the same way. Which, after seeing it, is unsurprising given their common runtime, but I couldn’t figure out where my mental model of flat_map was coming from, other than the name alone.

It was time to pull up a Ruby REPL, and see if Ruby was behaving the way I thought it “should” be behaving.

[1, [[2], 3]].flat_map {|x| x * x}
# TypeError: no implicit conversion of Array into Integer
# from (pry):11:in `*'

No! It failed in Ruby as well.

I had myself convinced that flat_map was the equivalent of doing a Array#flatten, and then calling Enumerable#map on the result.

[1, [[2], 3]].flatten.map {|x| x * x}
# [1, 4, 9]

This is the equivalent of what I was trying to get, and flat_map wasn’t working for me, and obviously, it is not the way Enumerable#flat_map behaves either.

After looking deeper, I realized that somehow, I had the application of the conceptual flatten and map methods swapped.

The way Enumerable#flat_map actually behaves is as if you called map on the Enumerable, and then called flatten on the results.

[[:a, 1], [:b, 2], [:c, 3]].flat_map {|item, count| Array.new(count, item) }
# [:a, :b, :b, :c, :c, :c]

[[:a, 1], [:b, 2], [:c, 3]].map {|item, count| Array.new(count, item) }
# [[:a], [:b, :b], [:c, :c, :c]]
[[:a, 1], [:b, 2], [:c, 3]].map {|item, count| Array.new(count, item) }.flatten
# [:a, :b, :b, :c, :c, :c]

And if an Enumerable is not returned by the map block passed to Enumerable#flat_map, it behaves the same as if you just called Enumerable#map.

[1, 2, 3].flat_map {|x| x * x}
# [1, 4, 9]
[1, 2, 3].map {|x| x * x}
# [1, 4, 9]

Here is hoping that this saves you some confusion as well.
–Proctor

In honor of the time change this weekend, today’s Ruby Tuesday is on Time#utc.

In the past few years I have had to deal with numerous bugs crop up around the changes between Daylight time and Standard time. In honor of all the time conversion issues I have dealt with in the past couple of years, I thought it would be timely, pun absolutely intended, to explore time conversions. As as this deals with local time vs UTC time conversions, let me preface this with a warning:

Here there be dragons.

With that said, let us see if we can channel the spirit of Dirk the Daring, and attempt to face down some of those dragons.

For this upcoming time change we will be moving the clocks forward an hour at 2 AM.

Let’s see what time it is right before the time change.

Time.new(2015,3,8, 1,59,59).utc
# 2015-03-08 07:59:59 UTC

And when 2 AM “arrives”, we move the clock forward and it becomes 3 AM.

Time.new(2015,3,8, 3,00,00).utc
# 2015-03-08 08:00:00 UTC

So far, all that looks good. But what happens at 2 AM?

Time.new(2015,3,8, 2,00,00).utc
# 2015-03-08 08:00:00 UTC

Though 2 AM on March 8th of 2015 never really happens, at least here in the Dallas/Fort Worth area, we do get a valid time returned when we call Time#utc, and the result is the same as when we called the utc method for 3AM.

That was interesting; as far if that is good or bad, that depends on how well your system can handle that behavior.

Now onto what happens later in the year when we set our clocks back an hour.

The first time that 2 AM rolls around we set our clocks back an hour to 1 AM, so let’s see what time 12:59:59 AM is in UTC, since we know that only happens once.

Time.new(2015,11,1, 00,59,59).utc
# 2015-11-01 05:59:59 UTC

And we only hit 2 AM only once as well, since the first time we came to 2 AM we all skipped it and relived the 1 AM hour.

Time.new(2015,11,1, 2,00,00).utc
# 2015-11-01 08:00:00 UTC

So now the question is: “What time is it at 1 AM?”

Time.new(2015,11,1, 1,00,00).utc
# 2015-11-01 07:00:00 UTC

Hrmm…..

It looks like we only get the time for 1 AM for the second time it rolls around, as it returns 7 AM UTC, and we have completely lost the 6 AM UTC hour. Dragons!

Hopefully you can avoid most of these issues and just work in UTC or epoch seconds across your systems. But as our systems continue to interact with more and more outside systems, the likelihood of having to deal with these issues increase, so please be aware.

–Proctor