Viktar Basharymau

10 Excellent Ruby and Rails Interview Questions¹

Wed, 12 Apr 2017 21:30:00 +0000

Here is a collection of 10 interview questions one can use to prove that the interviewee knows nothing about Ruby.

Before opening a link with the correct answer, please spend at least 5 minutes and try to come up with an answer by yourself.

1. Supersonic Future

$ ruby -r./magic.rb -e 'maybe_yes_maybe_no = magic; if maybe_yes_maybe_no then puts "YES" else puts "NO" end'
YES
NO

As you see, both branches of the if are executed. In this question and in any other question in this post, standard Ruby distribution is used.

The task is to implement magic.rb.

Hint.

Now, think again.

Giving up? Here’s the answer.

2. Point-free

duplicate = ...
duplicate.(20) # => [20, 20]
duplicate.(:x) # => [:x, :x]

Implement duplicate. There is a limitation: using arbitrary local variables (including proc/lambda/block/method params) is not allowed. For example, the following solutions are not acceptable:

duplicate = proc { |x| [x, x] }
duplicate = method(def f(x) [x, x]; end)

Answer.

3. Forty Two

h = {}
h.inspect.size # => 2
v = ...
h[v] = v
h.inspect.size # => 14
h[v] = v
h.inspect.size # => 28
h[v] = v
h.inspect.size # => 42

What is v equal to?

Answer.

4. Binary Blindness

"1011".b is equal to

11
"1111110011"
"11"
1011
"1011"
String doesn’t have a method named b
undefined

Answer.

5. ActiveRails

Let’s assume u is a newly created instance of a usual AR model User < ActiveRecord::Base with timestamp columns.

What is u.updated_at -u.created_at equal to?

0.0
0
Non-negative integer number
Non-negative floating point number
undefined
___ your answer

If you think you know the answer, write it down first and then compare with the correct answer.

Answer.

6. Quantum Computing

[0,1].first(&:nonzero?) evaluates to

0
1
Runtime error
undefined

Answer.

7. Referential Transparency

Implement MyClass such that

case 5 when MyClass then true else false end
# => true
case 5 when MyClass then true else false end
# => false
case 5 when MyClass then true else false end
# => true

Answer.

8. Go Meta

class A
end

A.class_eval do
  extend Module.new do
    def foo
      :bar
    end
  end
end

A.foo returns…

:bar
nil
undefined
__ your answer.

Answer.

9. Matrix Multiplication

[ 10 ] [ 0 ] [ 01 ] returns…

0
1
2
10
-1
10001
Syntax error
Runtime error
undefined

Answer.

10. Action Unpack

Construct an object liar using only standard Rails classes and not using metaprogramming (not even (re)defining classes and methods), for which the following is true:

liar = ...
liar.nil? # => true
!liar     # => false

Answer.

Bonus: C++

def f(xs, ys)
  xs.reject! do |x|
    ys.any? { |y| y[:cnt] += x[:cnt] if x != y }
  end
end

a = [{cnt: 4}, {cnt: 2}]
f(a, a)
a # => ???

What a will be equal to as a result?

[{cnt: 4}, {cnt: 2}]
[{cnt: 4}]
[{cnt: 2}]
[{cnt: 6}]
[]
Runtime error
undefined

Answer.

Final word

If your interviewee knows more than a half of these questions - they are a perfect candidate for ~~a Ruby position~~ solving stupid riddles.

¹ Never ever ask these questions during an actual interview.

4 Languages Experiment

Fri, 20 Jan 2017 11:30:00 +0000

I need to implement a small command line tool to convert a CSV in one format to a CSV in another format. The task itself is rather simple, but there are a few issues with the input CSV format which make it a bit more interesting.

As an experiment, I want to write the tool in several different languages and compare my experience. Somewhat randomly, I chose Ruby, Haskell, Java and Elixir.

Read on to see what happened.

Problem Definition

The input file is a bank statement from my bank’s online banking system. The output is a file in a format understandable by my personal finance management system.

Example input:

<U+FEFF>"ЗАО «МТБанк»"
"улица Толстого, 10, 220007, г.Минск."
"http://www.mtbank.by"
"тел.: +375 17 229-98-89"
"Выписка по счету  12322332233"
"Клиент:","Цой Виктор Робертович","15.01.2017 г. 19:58:04"
"Название:","VC USD 2Y (Сберегательная карта)"
"Номер счета:","12322332233"
"Номер и дата договора:","38555568 от 23.06.2015"
"Период выписки:","с 14.01.2017 г. по 16.01.2017 г."
"Входящий остаток:","1,000.00","USD"
"поступило:","0.00","USD"
"списано:","17.65","USD"
"Исходящий остаток:","1,000.81","USD"
Транзакции по счету с 14.01.2017 г. по 16.01.2017 г.
"Тип","Дата операции","Дата обработки","Место операции","Oписание операции","Карта","Валюта","Сумма в валюте операции","Сумма в валюте счета","Остаток счета"
"A","15.01.2017 12:19:46","..","SHOP "BRIOCHE PARIS" / MINSK / BY","Оплата товаров и услуг","123123******2222","BYN","-25.10","-12.88",""
"A","14.01.2017 17:10:38","..","0253379 / MINSK / BY","Выдача наличных","123123******2222","BYN","-100.00","-51.31",""
"T","12.01.2017 16:52:34","16.01.2017","SHOP"KALI LASKA" BPSB / MINSK / BY","Оплата товаров и услуг","123123******2222","BYN","-34.39","-17.65","1,000.81"
"  Типы операций"
"T - сумма обработана"
"A - сумма блокирована (ожидает обработки)"
"E - ошибка выполнения операции"
"Исходящий остаток:","1,000.81","USD"

Example output:

15.01.2017;ХЗ;Без категории;-12.88;ХЗ;"Место: SHOP ""BRIOCHE PARIS"" / MINSK / BY, Описание: Оплата товаров и услуг, Сумма: -25.10 BYN";
14.01.2017;ХЗ;Без категории;-51.31;ХЗ;Место: 0253379 / MINSK / BY, Описание: Выдача наличных, Сумма: -100.00 BYN;
12.01.2017;ХЗ;Без категории;-17.65;ХЗ;"Место: SHOP""KALI LASKA"" BPSB / MINSK / BY, Описание: Оплата товаров и услуг, Сумма: -34.39 BYN";

A few notable things:

Input data is encoded in UTF-8 and has Cyrillic characters.
Several first and last lines need to be removed from the output.
The input CSV is not valid: double quotes in the middle of fields are not escaped.
Some fields require additional transformations besides renaming: e.g. "12.01.2017 16:52:34" -> "12.01.2017".
The input is always small and can fit into memory. Performance is not a concern.

The experiment

In order not to waste much time, I decided to make something working really fast. No autotests, no code refactoring after the tool works, nothing like that. As soon as it works - ship it and move on to the next language.

Here is a pretty arbitrary scoring system I used to estimate the development process.

Correctness - max 3 points. If the script doesn’t work, it’s pointless.
Speed of development - 2 points.
Ease of packaging up the tool into a standalone binary or script - 1 point.
Number of external dependencies - 1 point.
Lines of code - 1 point.
Code readability - 1 point. I’m not going to change this script very often, and it’s also small, so it’s not as important for me in this case.

Results

Ruby

Ruby was my first choice since it’s the language I’m most comfortable with at the moment. This is typical throwaway code. It’s about 100 lines. It doesn’t have external dependencies except Ruby itself (CSV parser library is built in to Ruby). It took me a couple of hours to build and debug it. One painful moment was connected with “fixing” badly escaped double quotes in the middle of the fields.

Verdict:

Correctness - 2 points. There are a few bugs that I discovered later, but they are very easy to fix.
Speed of development - 2 points. It took very roughly 2-3 hours to build the script. The experience was smooth, more or less. There were a few hiccups when I realized that the input CSV is invalid.
Packaging standalone script - 1 point. It’s just one file which just works anywhere where Ruby 2 is installed.
Number of external dependencies - 0.5 points. No external libraries are required, but Ruby is still needed to run the script.
Lines of code - 1 point. ~100 LOC. Not that bad.
Code readability - 1 point.

Total - 7.5.

Haskell

Having solved the problem in Ruby, I decided to give Haskell a shot. Luckily, Stack solves most of the pain with external dependencies. The development experience was not that good, however. There are like 5 different types for String(-ish) data: String, Data.Text.Strict, Data.Text.Lazy, Data.ByteString.Lazy, and so on and so forth. Some of these types come as external packages. There are also a bunch of packages for regular expressions. I ended up using the package that also requires installing external library (icu4c). There are also a few packages to parse CSV which I used with different level of success. I ended up using cassava.

So, I spent a couple of evenings using different combinations of packages. In the end, I had 7 (seven) dependencies in my cabal file: temporary, text-regex-replace, bytestring, cassava, text, text-icu, vector. My 100-line app even compiled successfully! But it didn’t do any job yet, because I made it parse only one column of a CSV.

But even that was enough to show that the app can’t work with Cyrillic characters in CSV data. I gave up.

Verdict:

Correctness - 0 points.
Speed of development - 0 points.
Ease of packaging standalone script or executable - 0.5 points. It would be 1 point if I didn’t have to install or upgrade icu4c. Other than that, Stack does incredible job managing dependencies for me.
Number of external dependencies - 0 points. Too much stuff I need to pull in in order to get anything working.
Lines of code - 1 point. It’s less than a hundred lines of code (OTOH, the app doesn’t work at all, lol).
Code readability - 1 point. The code is concise and clear (to me). Type annotations serve as very good documentation generally.

Total - 2.5.

Java

After failing the Haskell experiment, I decided to switch to something simple. Something, where IDE does most of the job for me. Java!

I have to say that I’m not really aware of the most modern ways of working with Java collections. Every time I needed a map, I wrote it myself using for-loop. Sad story.

I also failed to build standalone executable uberjar. I pasted various snippets for my pom.xml, but then got bored and gave up.

Verdict:

Correctness - 2 points. I made a few bugs which I found later.
Speed of development - 2 points. I spend 2-3 hours, just like with Ruby version.
Ease of packaging standalone uberjar - 0 points. I failed.
Number of external deps - 0.5 points. Java is needed to run the jar.
Lines of code - 0.5 points. 200+ LoC - a bit too much. And if we add pom.xml then it’s gonna be almost 300 lines.
Code readability - 0.5 points. On the one hand, the code is really stupid simple, but on the hand, in some cases stupidness of the code leads to its bloatedness. Manual for loops, jiggling with boolean flags, all this jazz from the world of Golang and similar languages. Not my thing.

Total - 5.5.

Elixir

With 3 implementations behind my back, implementing the script in Elixir was really a breeze. The pipeline operator is great. Everything worked just fine almost from the first attempt. The source code is really simple and elegant. Albeit this was not a goal, the code works in a “streaming” manner - it uses constant memory no matter how big the input is. I enjoyed it so much.

Verdict:

Correctness - 3 points. Not a surprise, taking into account that it’s not the first attempt to write this script.
Speed of development - 2 points. Same 2-3 hours as with Ruby and Java.
Ease of packaging standalone script - 1 point. Just one simple command.
Number of external deps - 0.5 points. Erlang runtime is needed to run the script.
Lines of code - 1 point. ~100 LoC, same size as Ruby and (non-working) Haskell.
Code readability - 1 point.

Total - 8.5.

Conclusion

I wish I could give Haskell more points, but my experience with it was too painful, unfortunately. Sad, but true.

With other 3 languages my productivity was about the same, but Elixir (and Ruby, to some extent) are more fun to work with, as for me.

The source code is available here. Bear with me, it can be really shitty in some places. I spent 0 time polishing it.

Quickchecking ActiveSupport::Duration

Sat, 24 Dec 2016 11:30:00 +0000

QuickCheck is an awesome library, so I decided to play with it a bit and also refresh my memory of Haskell.

Intro

To, warm up, let’s remind ourselves how insane floating point arithmetic is. Let’s test if addition of floating point numbers is commutative (x + y = y + x).

$ stack ghci
Prelude> import Test.QuickCheck
Prelude Test.QuickCheck> :{
Prelude Test.QuickCheck| prop_additionIsCommutative :: Double -> Double -> Bool
Prelude Test.QuickCheck| prop_additionIsCommutative x y = x + y == y + x
Prelude Test.QuickCheck| :}

Prelude Test.QuickCheck> quickCheck prop_additionIsCommutative
+++ OK, passed 100 tests.

Ok, so far so good. What about associativity ((x + y) + z == x + (y + z))?

Prelude Test.QuickCheck> :{
Prelude Test.QuickCheck| prop_additionIsAssociative :: Double -> Double -> Double -> Bool
Prelude Test.QuickCheck| prop_additionIsAssociative x y z = (x + y) + z == x + (y + z)
Prelude Test.QuickCheck| :}

Prelude Test.QuickCheck> quickCheck prop_additionIsAssociative
*** Failed! Falsifiable (after 2 tests and 117 shrinks):
2.2204498059835824e-16
3.144251466391179e-2
0.9693770503702299

Nice! Let’s try a few more.

Prelude Test.QuickCheck> quickCheck ((\x y z -> x * y * z == x * (y * z)) :: Double -> Double -> Double -> Bool)
*** Failed! Falsifiable (after 2 tests and 1148 shrinks):
5.0e-324
2.267914075073144
1.1023346291857508

Prelude Test.QuickCheck> quickCheck ((\x y -> x + y - y == x) :: Double -> Double -> Bool)
*** Failed! Falsifiable (after 4 tests and 2097 shrinks):
5.0e-324
4.450147717014403e-308

This is one more reminder not to use double and float types to represent money. If you have X dollars and then someone gives you Y dollars and then changes their mind and takes these Y dollars back, you can end up with 0 dollars in your pocket, even though X was greater than zero. Before taking money from someone, make sure they don’t use doubles for money.

x, y = 5.0e-324, 4.450147717014403e-308;
x > 0           # => true
x + y - y == 0  # => true

Testing Date and Time

Not only floating-pointer numbers are insane. Date and time are extremely weird as well. All these time zones, daylight saving time, leap years, leap seconds. Pure madness. Many of our assumptions about time are wrong.

In order to make my life more complicated, I decided to check whether ActiveSupport::Duration from Rails is associative, but I want to use Haskell’s QuickCheck to do that.

Here are a few instances of the ActiveSupport::Duration class:

1.month    # => 1 month
10.years   # => 10 years
-5.seconds # => -5 seconds

t = Time.zone.now # => Sat, 24 Dec 2016 14:24:41 EST -05:00
5.weeks.since(t)  # => Sat, 28 Jan 2017 14:24:41 EST -05:00

In which case the time to wait is longer: when you first wait D1 and then D2, or when you first wait D2 and then D1? Common sense suggests that it’s the same, but let’s check it.

Let’s get started.

stack new ActiveSupportDates quickcheck-test-framework
cd ActiveSupportDates

There are a few predefined tests in test/Spec.hs, let’s remove them all. Now, testing pure properties is easy. This time, however, we need to communicate with Ruby, thus we need quickcheck with IO. After 15 seconds of searching, we can find this. Looks like this is exactly what we need. Let’s adapt it to our needs.

import Test.Framework (defaultMain, testGroup)
import Test.Framework.Providers.QuickCheck2 (testProperty)

import Test.QuickCheck
import Test.QuickCheck.Monadic

import Data.Char (toLower)
import System.Process (readProcess)

data Duration = Duration TimeUnit Int deriving (Eq, Show)

data TimeUnit
  = Seconds
  | Minutes
  | Hours
  | Days
  | Weeks
  | Months
  | Years deriving (Eq, Show)

instance Arbitrary Duration where
  arbitrary = Duration <$> arbitrary <*> arbitrary

instance Arbitrary TimeUnit where
  arbitrary = oneof
    [ pure Seconds
    , pure Minutes
    , pure Hours
    , pure Days
    , pure Weeks
    , pure Months
    , pure Years
    ]

main :: IO ()
main = quickCheck prop_commutative

prop_commutative :: Duration -> Duration -> Property
prop_commutative op1 op2 = monadicIO $
  run (commutative op1 op2) >>= assert

{-
Builds a Ruby program which applies two given durations to a fixed date
in different order and check whether the output is the same. The program
then is fed to Ruby interpreter. The program prints "true" when the dates
made by applying durations in different order are equal. The output of the
program is converted to Haskell's Bool
-}
commutative :: Duration -> Duration -> IO Bool
commutative op1 op2 = do
  let flags = ["-ractive_support/core_ext/integer/time", "-e", rubyProgram op1 op2]
  output <- readProcess "ruby" flags ""
  return (output == "true")

{-
Example:
`rubyProgram (Duration Seconds 3) (Duration Years 5)` returns a string
equivalent to the following Ruby code:

    tz = ActiveSupport::TimeZone.zones_map.fetch('Eastern Time (US & Canada)')
    t = tz.parse('Fri, 23 Dec 2016 18:30:02 EST -05:00')
    x = 3.seconds.since(5.years.since(t))
    y = 5.years.since(3.seconds.since(t))
    print(x == y)
-}
rubyProgram :: Duration -> Duration -> String
rubyProgram op1 op2 =
    "tz = ActiveSupport::TimeZone.zones_map.fetch('Eastern Time (US & Canada)'); " ++
    "t = tz.parse('Fri, 23 Dec 2016 18:30:02 EST -05:00'); " ++
    "x = " ++ applyDurations op1 op2 ++ "; " ++
    "y = " ++ applyDurations op2 op1 ++ "; " ++
    "print(x == y)"
  where applyDurations x y = toRuby x ++ ".since(" ++ toRuby y ++ ".since(t))"

{-
Examples:
toRuby (Duration Hours 5)
  -- "5.hours"

toRuby (Duration Minutes (-1))
  -- "-1.minutes"
-}
toRuby :: Duration -> String
toRuby (Duration unit amount) = show amount ++ "." ++ map toLower (show unit)

Simpru, right?

Let’s run it:

$ stack test
*** Failed! Assertion failed (after 13 tests):
Duration Days 10
Duration Months 2

And check it in Ruby:

tz = ActiveSupport::TimeZone.zones_map.fetch('Eastern Time (US & Canada)')
t = tz.parse('Fri, 23 Dec 2016 18:30:02 EST -05:00')
# => Fri, 23 Dec 2016 18:30:02 EST -05:00
x = 10.days.since(2.months.since(t))
# => Sun, 05 Mar 2017 18:30:02 EST -05:00
y = 2.months.since(10.days.since(t))
# => Thu, 02 Mar 2017 18:30:02 EST -05:00

Wow, 3 days difference! Not bad. This is because adding the actual duration of adding months depends on the timestamp we are adding these months to.

(t + 2.seconds) - (t + 1.second) == 1.second
# => true
(t + 2.months) - (t + 1.month) == 1.month
# => false

Now, what if we remove months out of the equation? Let’s comment out pure Months from Arbitrary instance definition for Duration and rerun the test.

Failed! Assertion failed (after 50 tests):
Duration Years 17
Duration Weeks (-49)

Let’s have a look.

# => Fri, 23 Dec 2016 18:30:02 EST -05:00
x = 17.years.since(-49.weeks.since(t))
# => Sat, 15 Jan 2033 18:30:02 EST -05:00
y = -49.weeks.since(17.years.since(t))
# => Fri, 14 Jan 2033 18:30:02 EST -05:00

1 day difference. This time, it’s a leap year problem: if we travel from 23 December 2016 to 49 weeks in past, we will get to 15 January (because 2016 is a leap year and 29 February is a thing). Then 17 years to the future - it’s 15 Jan 2033.

On the other hand, if we first go to the future (23 December 2033), and then 49 weeks back, then we’ll get to 14 January (because the 2033 year is not leap and Feb 29 doesn’t exit).

So the problem now is very similar to the previous problem we had with month durations. year durations depend on the year of the date they are applied to. Let’s comment out pure Years and rerun tests.

$ stack test
+++ OK, passed 100 tests.

Hmm, looks promising. But maybe I overlooked something? Let’s increase the number of tests and run it again.

main :: IO ()
main = quickCheckWith stdArgs{maxSuccess = 1000, maxSize=100500} prop_commutative

$ stack test
Failed! Assertion failed (after 10 tests):
Duration Hours 684
Duration Days (-433)

What is this?

x = 684.hours.since(-433.days.since(t))
# => Mon, 16 Nov 2015 01:24:41 EST -05:00
y = -433.days.since(684.hours.since(t))
# => Mon, 16 Nov 2015 02:24:41 EST -05:00

1 hour difference. DST? Most likely. If you run stack test a few times, you’ll see that x and y will be around mid March or mid November. This confirms our suspicion. Well, the problem is the same: 1.day doesn’t actually have a constant length. It can be 23 or 25 hours long, if we jump over DST point.

Let’s exclude days and weeks and rerun tests.

I ran stack test with the new settings multiple times and didn’t get any new failures. It doesn’t mean that the commutative property holds for second/minute/hour durations. It just means that QuickCheck didn’t find any counterexamples.

Conclusion

Current implementation of the test is very inefficient: it starts a process for each single check. My initial implementation was more ugly and a lot faster. Its source code is there. I checked a few more properties there. In that implementation, the Ruby process is started once and it communicates with Haskell via pipe.

[] must be renamed

Wed, 14 Dec 2016 21:30:00 +0000

Here is the proposal for Ruby 4.

Hash#[] and Array#[] have to be renamed to something that is less convenient to use. For example, to Hash#get and Array#get. These methods should either accept 2 parameters (a key/index and a default value), or one parameter (key/index) and a block which evaluates the default value.

Hash#fetch and Array#fetch have to be renamed to Hash#[] and Array#[].

In other words, {Hash,Array}#[] should fail when an element is missing.

Returning nil by default is an anti-pattern and should be avoided.

But until Ruby 4 is there, we have to be deal with what we have. The simplicity of calling #[] leads to code that is harder to debug in case of errors.

Consider this.

@table[f][i] = i

What if, due to some bug, @table[f] returns nil because of a missing key? Perhaps, f got some unexpected value or something like this? What we will get with this code is NoMethodError.

@table = {a: [1]}

@table['a'][0] = 2
# => NoMethodError: undefined method `[]=' for nil:NilClass

Now, what if we use fetch instead of the first []? It reveals our intent more clearly, and if something goes wrong fails with a better error:

@table = {a: [1]}

@table.fetch('a')[0] = 2
# => KeyError: key not found: "a"

This is for sure a much more descriptive error than the previous one.

I know the code looks ugly. That’s why I proposed changes to the semantics of [] in the beginning of this post.

Try is useless

Fri, 09 Dec 2016 21:30:00 +0000

Object#try from ActiveSupport is a code smell. What developers need in the vast majority of cases is &. or Object#try!.

What is the difference between those? x.try(:method) returns nil when x is a non-nil object that does not respond to :method. On the other hand, x&.method fails with NoMethodError in such cases.

Why is this difference important? It is important because of the reasons is outlined in the previous post about flatten. try is very vague. It declares that you don’t know what kind of object is the receiver. If you pass the wrong kind of object, for example something that does not respond to the passed message, try will just silently hide this from you. This is bad because it just postpones the error until later. It is always better to fail ASAP (at compile time, if you wish), than to delay the error and pretend that everything is fine.

Here is an example.

options[:namespace].try(:gsub, /\//, "_")

What happens there if someone passes {namespace: :core} instead of {namespace: 'core'}, perhaps because of a bug? The poor user will just get confused why :namespace param is ignored, and she will need to investigate the source code to understand what happens there.

On the other hand, if we use try! there, the code will rightfully blow up with a nice message:

def f(options = {})
  options[:namespace].try(:gsub, /\//, "_")
end

f()                  # => nil
f(namespace: 'core') # => 'core'
f(namespace: :core)  # => nil # what? why?

def g(options = {})
  options[:namespace].try!(:gsub, /\//, "_")
end

g()                  # => nil
g(namespace: 'core') # => 'core'
g(namespace: :core)  # => NoMethodError: undefined method `gsub' for :core:Symbol
                     # Immediately clear what went wrong.

There are many more examples like this:

# Are you claiming here that `User` instances may or may not respond
# to `:autnenticate`? Doesn't sound realistically. Maybe you are
# claiming that `find_by` can return something that is not `nil` or
# an instance of `User`? Also doesn't sound like truth. So why not
# use `try!` then? It's like documentation: you are essentially
# asserting that `find_by` returns either something that responds to
# `:authenticate` or `nil`.
User.find_by(name: 'david').try(:authenticate, 'mUc3m00RsqyRe')

# What? Are there weird kind of exceptions that do not respond to
# `:message`? Unlikely so. Then don't use `try`. Use `&.` or `try!`.
$!.try(:message)

Again, the difference between try! and try is the difference between confident code and sloppy code.

And by the way, try! is more performant than try on average.

There are cases when try is really needed, but they are rare.

Flatten must be banned

Thu, 08 Dec 2016 21:30:00 +0000

I have strong opinion about some patterns in Ruby. Certain things are frequently used in a terribly wrong way (what a surprise). In this post I will explain what is wrong with how Array#flatten is used sometimes.

Array#flatten

Argument-less flatten should not exist. In my experience, only in very rare cases do we need to call it. Most often, flat_map should be used instead. In most of the remaining cases, flatten(1) is an option.

flatten without arguments means that you have no idea what kind of input to expect. This is a violation of YAGNI principle and just sloppy coding.

There are literally hundreds of examples of abusing flatten on GitHub. Let’s review some of them.

Case One

  # bad
  reloadable_paths.map(&:existent).flatten

  # good
  reloadable_paths.flat_map(&:existent)

a.map{}.flatten is not always equivalent to a.flat_map{}, but in this particular case it is, as well as in many similar cases.

Case Two

  # bad
  html.scan(/.../).flatten.each do |anchor|
    ...

  # good
  html.scan(/.../) do |(anchor)|
    ...

Way simpler, right?

Case Three

  # bad
  def helper_attr(*attrs)
    attrs.flatten.each#...
  end

  # good
  def helper_attr(*attrs)
    attrs.each#...
  end

This pattern is especially popular among Ruby developers. With this pattern, the caller is allowed to call helper_attr in many different ways:

  HELPERS = %i[current_account current_user current_role]

  helper_attr :current_user
  helper_attr HELPERS
  helper_attr [[:bullshit]], [[[[[:look_what_i_can_do]], [:lol]]]], :ok

Some people call it “convenient”. I respectfully disagree. I consider this code unconfident, vague and sloppy. Interface of helper_attr is overly broad. Without losing much readability, flatten can be dropped and the method will become more strict, it will obtain a well-defined type, if you wish:

  HELPERS = %i[current_account current_user current_role]

  helper_attr :current_user
  helper_attr(*HELPERS)
  # the following is not considered a valid input
  helper_attr [[:bullshit]], [[[[[:look_what_i_can_do]], [:lol]]]], :ok

If the splat in helper_attr(*HELPERS) really, really, really bugs you, then there still exists an option way better than argument-less flatten: flatten(1).

  def helper_attr(*attrs)
    attrs.flatten(1).each#...
  end

  helper_attr :current_user
  helper_attr HELPERS
  # the following is not considered a valid input
  helper_attr [[:bullshit]], [[[[[:look_what_i_can_do]], [:lol]]]], :ok

Case Four

  # bad
  [forwarded_ips, client_ips, remote_addr].flatten.compact

  # good
  [*forwarded_ips, *client_ips, remote_addr].compact

If we know the shape of the input, why on Earth do we need to use the overly generic and slow method that hides our intent instead of making it as clear as possible?

Case Five

  # bad
  [token].flatten.first

  # still bad, but better
  Array(token).first
  # or
  Array.wrap(token).first

Surprisingly often I see this [something].flatten code. In most cases, what people want is: if it’s a collection, keep it as is, otherwise wrap it in array. This is exactly what Kernel#Array does.

Conclusion

Do I need to say that flatten-less code is generally faster than equivalent code full of argumentless flattens?

But mind you, performance is not my main concern. My main concern is maintainability. I consider naked flatten a code smell. In many cases code with flatten is the opposite of what I would call Confident Ruby.

Data.Maybe.rb

Thu, 19 Nov 2015 10:15:00 +0000

Вот, допустим, есть такой код:

  def authenticate_user_from_token!
    return unauthorized! unless request.headers['Authorization'].present?

    token = request.headers['Authorization'].split(' ').last
    payload = JsonWebToken.decode(token)
    return unauthorized! unless payload.present?

    user_id = payload['user_id']
    return unauthorized! unless user_id.present?

    user = User.find_by(id: user_id)
    return unauthorized! unless user.present?

    @current_user = user
  end

Очень плохо, отвратительно. Нужно срочно расчехлить Maybe/Some/Option:

  def authenticate_user_from_token!
    @current_user =
      Maybe(request)
        .fmap { |request    | request.headers['Authorization'] }
        .fmap { |auth_header| auth_header.split(' ').last      }
        .fmap { |token      | JsonWebToken.decode(token)       }
        .fmap { |payload    | payload['user_id']               }
        .fmap { |user_id    | User.find_by(id: user_id)        }
        .from_just { unauthorized!; nil }
  end

Мммм, монады.

В интернете 100500 реализаций Maybe, но мы пойдём иным путём, в силу того, что критерий для Nothing у нас в этом конкретном случае специфичен для Rails (.present? я имею в виду). Вместо того, чтобы манкипатчить чужие гемы, лучше написать немного своего ненужного кода.

  Maybe = Struct.new(:value) do
    def fmap(&f)
      if value.present?
        Maybe.new(f.(value))
      else
        self
      end
    end

    def from_just(&when_nothing)
      if value.present?
        value
      else
        when_nothing.()
      end
    end
  end

  def Maybe(value)
    Maybe.new(value)
  end

Окей, тесты проходят. Но как-то не оопешно. Ифы повторяются, сплошной грех. Второй подход:

  def Maybe(value)
    if value.present?
      Just.new(value)
    else
      Nothing
    end
  end

  Just = Struct.new(:value) do
    def fmap
      Maybe(yield value)
    end

    def from_just
      value
    end
  end

  module Nothing
    def self.fmap
      self
    end

    def self.from_just
      yield
    end
  end

ООПе-духи одобряют!

Единственный печальный момент - это наличие унылого .present?. Заэкстрактим:

  def Maybe(value, &is_just)
    is_just ||= :itself.to_proc
    if is_just.(value)
      Just.new(value, is_just)
    else
      Nothing
    end
  end

  Just = Struct.new(:value, :is_just) do
    def fmap
      Maybe(yield(value), &is_just)
    end

    def from_just
      value
    end
  end

  module Nothing
    def self.fmap
      self
    end

    def self.from_just
      yield
    end
  end

Интерфейс несколько поменялся, но зато теперь эта штука не зависит от рельсов, абстракция не протекает и тесты будут работать супербыстро.

Maybe({user: {address: {street: '213'}}})
    .fmap{|x| x[:user]}
    .fmap{|x| x[:address]}
    .fmap{|x| x[:street]}
    .from_just { 'No such number, address unknown' }
# => "213"

Maybe({user: {address: ''}})
    .fmap{|x| x[:user]}
    .fmap{|x| x[:address]}
    .fmap{|x| x[:street]}
    .from_just { 'No such number, address unknown' }
# TypeError: no implicit conversion of Symbol into Integer

#OKAY, WHAT ABOUT THIS?#

Maybe({user: {address: ''}}, &:present?)
    .fmap{|x| x[:user]}
    .fmap{|x| x[:address]}
    .fmap{|x| x[:street]}
    .from_just { 'No such number, address unknown' }
# => "No such number, address unknown"

Победа!

UPD: таки запилил гем.

power_assert

Tue, 10 Nov 2015 21:00:00 +0000

`
                                  _.---"'"""""'`--.._
                             _,.-'                   `-._
                         _,."                            -.
                     .-""   ___...---------.._             `.
                     `---'""                  `-.            `.
                                                 `.            \
                                                   `.           \
                                                     \           \
                                                      .           \
                                                      |            .
                                                      |            |
                                _________             |            |
                          _,.-'"         `"'-.._      :            |
                      _,-'                      `-._.'             |
                   _.'                              `.             '
        _.-.    _,+......__                           `.          .
      .'    `-"'           `"-.,-""--._                 \        /
     /    ,'                  |    __  \                 \      /
    `   ..                       +"  )  \                 \    /
     `.'  \          ,-"`-..    |       |                  \  /
      / " |        .'       \   '.    _.'                   .'
     |,.."--"""--..|    "    |    `""`.                     |
   ,"               `-._     |        |                     |
 .'                     `-._+         |                     |
/                           `.                        /     |
|    `     '                  |                      /      |
`-.....--.__                  |              |      /       |
   `./ "| / `-.........--.-   '              |    ,'        '
     /| ||        `.'  ,'   .'               |_,-+         /
    / ' '.`.        _,'   ,'     `.          |   '   _,.. /
   /   `.  `"'"'""'"   _,^--------"`.        |    `.'_  _/
  /... _.`:.________,.'              `._,.-..|        "'
 `.__.'                                 `._  /
                                           "' mh

Срочно в номер: не исключено, что с рубями из коробки будет поставляться мега-гем power_assert. Тем временем, его можно использовать и установив самостоятельно:

$ gem install minitest-power_assert

# test.rb
require 'minitest-power_assert'
require 'minitest/autorun'

class TestPowerAssert < Minitest::Test
  def test_power_assert_failed
    assert { "0".class == "3".to_i.times.map {|i| i + 1 }.class }
  end
end

$ ruby test.rb
Run options: --seed 36110

# Running:

F

Finished in 0.004967s, 201.3478 runs/s, 201.3478 assertions/s.

  1) Failure:
TestPowerAssert#test_power_assert_failed [tst.rb:6]:
    assert { "0".class == "3".to_i.times.map {|i| i + 1 }.class }
                 |     |      |    |     |                |
                 |     |      |    |     |                Array
                 |     |      |    |     [1, 2, 3]
                 |     |      |    #<Enumerator: 3:times>
                 |     |      3
                 |     false
                 String

1 runs, 1 assertions, 1 failures, 0 errors, 0 skips

Не знаю, как оно по производительности, но для мелких проектов штука бесценная, я считаю.

clj.hs

Sun, 08 Nov 2015 01:15:00 +0000

Х-ь клёвый язык, скобки тоже. Почему бы не скрестить их между собой?

(take 7 (mySeq "1"))
-- ["1","11","21","1211","111221","312211","13112221"]

-- Implementation
import Control.Concatenative
import Data.List

mySeq = (iterate (concatMap (bi (show . length) (take 1) (++)) . group))

Более другой язык

Sun, 08 Nov 2015 01:15:00 +0000

Продолжаем играть в гольф.

-- Interface

head (mySeq "1")
-- "1"
take 7 (mySeq "1")
-- ["1","11","21","1211","111221","312211","13112221"]
find ((> 15) . length) (mySeq "1")
-- Just "13211311123113112211"

-- Implementation
mySeq :: String -> [String]
mySeq = iterate $ concatMap (\chs -> show (length chs) ++ take 1 chs) . group