Ylan Segal

StringInquirer: Nicer Syntax for Testing Equality

There is a well-known idiom in Rails, to tell wheather one is runnign in a specifc environment or not:

1
2
Rails.env.production? # => false
Rails.env.development? # => true

At first, it looks like Rails.env is a special kind of object that has methods defined on it to check for the environment properties. However, upon closer inspection, it looks like it is really just a String, but not quite:

1
2
3
4
>> Rails.env
=> "development"
>> Rails.env.class
=> ActiveSupport::StringInquirer

As the documentation says, StringInquirer is just a pretty way to test for equality. It can be used outside of Rails, say for example to be a bit lenient when reading environment variables:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
require 'active_support/core_ext/string'

class Logger
  def log(message)
    message if verbose?
  end

  private

  def verbose?
    env_verbose.true? || env_verbose.yes?
  end

  def env_verbose
    @env_verbose ||= (ENV['VERBOSE'] ||= '').downcase.inquiry
  end
end

Logger.new.log("Hello, World") # => nil

ENV['VERBOSE'] = 'yes'
Logger.new.log("Hello, World") # => "Hello, World"

ENV['VERBOSE'] = 'YES'
Logger.new.log("Hello, World") # => "Hello, World"

ENV['VERBOSE'] = 'True'
Logger.new.log("Hello, World") # => "Hello, World"

Book Review: The Rails 4 Way - Fernandez & Faustino

“The Rails 4 Way”, by Obie Fernandez and Kevin Faustino is a great reference book that covers most of what a Rails developer is likely to need on a daily basis. It covers the various DSLs and idioms (i.e. route definition, controller filter declaration, ActiveModel association and validations, etc) without getting into the details of Rails internals and how those features are implemented. The explanations are clear and the code examples relevant.

Just like Rails itself, “The Rails 4 Way” is opinionated and occasionally differs from the omakase 1 way; Most notoriously, but hardly controversial, using Haml as a template engine and Rspec for testing.

Most of the book can be read cover-to-cover or used as a reference on particular topics. The exception is section about rails helpers (Chapter 11) which, as the author themselves point out, is really just an alphabetical listing of the methods available, like the one usually found on appendices or online documentation.

I recommend this book to new Rails developers (maybe after trying out an online tutorial) and for experienced Rails developers who are still working on Rails 3 (or 2!) and are expecting to make the jump to Rails 4 in the near future.


  1. Want a laugh? See the dramatic reading of DHH’s post

Talk: Practical Unix for Ruby and Rails

Last night I had the pleasure of giving a talk at the SDRuby monthly meeting on practical uses of UNIX command line programs for Ruby and Rails developers. Check out the slides! and thanks everyone for the words of encouragment.

We Are All Atom Now

Back in February I wrote about Atom. At the time, I felt Atom showed promise, but was still a bit lacking. After Github announced that Atom is now completely open source in May, I decided to take another look. Most of what I use every day for development is open source, especially the tools with which I make my living: Linux, zsh, Ruby, Rails, etc that I find the idea of my editor being open source very appealing.

Code Navigation

Atom uses ctags, as does other Unix-y editors. Support for jumping back from declarations has now been added, wich was crucial for my workflow. Another issue I had was the lack of context when multiple symbols were listed when navigating, but I managed to wrestle my way through coffeescript to fix that. Now, it works just like I expect it to.

Speed

Atom has much better performance now and it is clear that the development team consider this a priority. Overall, I find that the speed while working in the editor (opening files, editing files, jumping between files, searching) is acceptable and I do not notice and lag. Opening the editor, however is another matter. It is very sluggish, even when opening directories that are not deep and with a small number of files. For example, I enjoy using Atom for my git commit messages since I am already familiar with the navigation and it has a nice syntax formatting. However, some times it takes several seconds to open and makes me want to tear my hair out.

Contributing

Being open source means any one can download the source and hack, but Atom makes it much easier than that. The guide explains how to create new packages for atom and it includes a testing framework out-of-the-box. I had never written a line of coffescript (or much javascript for that matter) and was able to use apm to download a package, make a few fixes and submit a pull request: I can see why there is so much excitement about Atom.

Conclusions

I have been using Atom as my main editor for the last 3 months. For being a beta version, I find the editor more than usable. Sublime Text 2 is a great editor and a lot of Atom is modeled after it (just as Sublime is modeled after TextMate). However, I believe Atom is here to stay and is my main editor for the foreseeable future.

World Cup Player Age, Unix Style

I love watching the World Cup: It’s more soccer than you could hope for, mixed with national rivalries. What could be better. Now that I am older than most of the players, it dawned on me the intense pressure that they are under, to perform for their country and a question came to me: Just how old are this kids? Let’s find out.

Source Data

With a quick google search, I came up with what seemed like a good source of data for the task at hand. I simply copy and pasted the data from my browser into a text editor to get a file that looks like this:

1
2
3
4
5
6
7
8
9
10
11
Alan PULIDO  Mexico  08/03/1991  5   4
Adam TAGGART  Australia   02/06/1993  4   3
Reza GHOOCHANNEJAD    Iran    20/09/1987  13  9
NEYMAR    Brazil  05/02/1992  48  31
Didier DROGBA Ivory Coast 11/03/1978  100 61
David VILLA   Spain   03/12/1981  95  56
Abel HERNANDEZ    Uruguay 08/08/1990  12  7
Javier HERNANDEZ  Mexico  01/06/1988  61  35
Islam SLIMANI Algeria 18/06/1988  19  10
Shinji OKAZAKI    Japan   16/04/1986  75  38
...

Cutting and Slicing

Using the power of unix pipes, we can easily extract the data we want from the data. Let’s start by getting all birthdates:

1
2
3
4
5
6
7
8
9
10
11
12
$ cat players.txt | cut -f3
08/03/1991
02/06/1993
20/09/1987
05/02/1992
11/03/1978
03/12/1981
08/08/1990
01/06/1988
18/06/1988
16/04/1986
...

As the man pages say: cut cut out selected portions of each line of a file. In our case, we want the 3rd field in the database.

Now, we can cut again to get the birth year of each player:

1
2
3
4
5
6
7
8
9
10
11
12
$ cat players.txt | cut -f3 | cut -d '/' -f3
1991
1993
1987
1992
1978
1981
1990
1988
1988
1986
...

In this case, we are cutting again, this time using / as a delimiter. Now we have a list of all the players' birth years.

Histogram

I searched around for some quick utilities that would generate a histogram and the most promising seemed a python utility called data hacks. Unfortunetly, I did not install for me and I didn’t have the inclination to mess with my python installation. I did however, find something similar to what I needed in a blog post about visualizing your shell history. After adapting it a bit to my purposes, I created a small bash function that now lives in my profile:

1
2
3
function histogram() {
  sort | uniq -c| sort -rn | awk '!max{max=$1;}{r="";i=s=60*$1/max;while(i-->0)r=r"#";printf "%15s %5d %s %s",$2,$1,r,"\n";}'
}

This function leverages awk very heavily. awk is a pattern-directed scanning and processing language. I am not very familiar with it, but after seeing how powerful it is, I am definitely want to get acquainted with it.

With this function, we can now get a full histogram:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
$ cat players.txt | cut -f3 | cut -d '/' -f3 | histogram | sort
   1971     1 #
   1976     1 #
   1977     2 ##
   1978     5 ####
   1979    15 ############
   1980    19 ###############
   1981    32 #########################
   1982    33 ##########################
   1983    46 ####################################
   1984    58 ##############################################
   1985    66 ####################################################
   1986    77 ############################################################
   1987    70 #######################################################
   1988    65 ###################################################
   1989    62 #################################################
   1990    63 ##################################################
   1991    38 ##############################
   1992    47 #####################################
   1993    22 ##################
   1994     7 ######
   1995     6 #####
   1996     1 #

Notice that the final sort is needed, because histogram returns the values ordered by the number of times it appeared in the data, but since we are talking about birth years, I believe the graph is more telling if it is in ascending order.

Other Findings

With all that in place, it is relatively easy to make a histogram of other data. I remember Malcom Gladwell’s theory in his book Outliers about how most professional hockey players are born in the first part of the year, because of how the developmental leagues work in Canada. With a database of 735 professional soccer players, chosen to be then best 23 of each country, I would expect 61.25 players to be born on each month. Let’s find out how many really are:

1
2
3
4
5
6
7
8
9
10
11
12
13
$ cat players.txt | cut -f3 | cut -d '/' -f2 | histogram | sort
   01    73 #########################################################
   02    77 ############################################################
   03    66 ####################################################
   04    63 ##################################################
   05    73 #########################################################
   06    59 ##############################################
   07    57 #############################################
   08    57 #############################################
   09    66 ####################################################
   10    46 ####################################
   11    48 ######################################
   12    51 ########################################

Notice that to arrive at this graph, the only thing we changed was the field we extracted from the data, in this case the month of the birthday. Is there a trend here? It does suggest that players born in the first part of the year are favored, but I do not know if it’s statistically significant.

Conclusion

Quick and dirty data analysis on the command line is pretty easy if you know a bit of unix and some awk!