<![CDATA[Jerome's Adventures in Software]]> 2021-03-21T16:32:05-07:00 http://jeromedalbert.com/ Octopress <![CDATA[JSONB + Rails to store glorified strings in your DB]]> 2016-06-27T08:48:00-07:00 http://jeromedalbert.com/jsonb-plus-rails-to-store-glorified-strings-in-your-db

Everyone likes a good old quick and dirty hack every once in a while. For example, who hasn’t stored — or at least hasn’t been tempted by storing — a list of values as a simple string in the database?

Let’s see when this could be a good choice, and how to use Postgres JSONB to make our lazy decision nicer to implement!

The case for storing strings in DB

Say we are working on a simplified app where products have predefined available sizes. When buying a product, users can choose between these available sizes. For example a T-shirt could come in S, M, L and XL sizes. A pack of cookies could have “tiny”, “reasonable” and “super-size-me” editions. Etc. When trying to implement this, we are faced with a choice.

  1. We could “just wing it™” and store a comma-separated string. Our T-shirt would have the "S,M,L,XL" string in an available_sizes field. When editing this product, the front-end would send this string and the back-end would store it as is. When displaying these sizes to our users in a select box, our code would split(',') to be able to iterate on them.

  2. Another possibly cleaner solution would be to have a separate sizes table. A product has many sizes and a size can belong to many products. This is what they usually teach you in traditional Computer Science classes.

Which solution is best? As usual it’s all about trade-off and it depends on your context. Solution 2 has no data duplication and is possibly easier to query for stats and whatnot, but it involves two additional tables: sizes + a table to store our many-to-many relationship. For a simple feature like this, especially if the future is uncertain, I would argue that solution 1 is often good enough. It is the quickest to implement with minimal effort, and easily modifiable in the future if needed. If one day people need to do aggregate queries for stats purposes (inefficient/cumbersome and sometimes impossible with strings), one can always improve later with a migration. Either by implementing the second solution with additional tables, or by using some form of noSQL storage, depending on the needs.

A nicer way with JSONB

So you’ve decided to store good ol’ comma-separated strings in your app. You probably didn’t need to read a blog post for that! But some of you may not know that the Postgres JSONB format could fit the bill quite nicely as a glorified string.

JSONB allows you to store JSON as is, and Rails has very good support for it. How good? Well, it means that your back-end can literally store the ["S", "M", "L", "XL"] array, which is valid JSON. When retrieving the value from the database, Rails presents it to you as a Ruby array, so you can directly iterate on it without doing any split! It’s arrays all the way down, no strings attached (bad pun intended).

All you need is Postgres 9.4+ and a migration like this:

1
2
3
4
5

class AddSizesToProducts < ActiveRecord::Migration
  def change
    add_column :products, :sizes, :jsonb, default: []
  end
end

And you’re good to go.

EDIT: As Hauleth has pointed out in the comments, Postgres has an array data type exactly for this use case. The corresponding migration would then be:

1
2
3
4
5

class AddSizesToProducts < ActiveRecord::Migration
  def change
    add_column :products, :sizes, :text, array: true, default: []
  end
end

Conclusion

With this technique you get the advantages of a quick and easy implementation without the uneasy feeling of handling dirty strings. If you want to drink more of this JSONB kool-aid, I recommend reading this post from the Codeship blog, especially if you are planning to store javascript objects (pro-tip: you can use default: {} in your migrations if needed). In the meantime, happy hacking!

]]> <![CDATA[How DHH organizes his Rails controllers]]> 2016-02-28T00:42:00-08:00 http://jeromedalbert.com/how-dhh-organizes-his-rails-controllers

EDIT: This article is also available in Japanese. すごい!

In a recent interview with Full Stack Radio our Lord and Savior DHH™ explains how he organizes Rails controllers in the latest version of Basecamp. Here is an enhanced transcript of his holy words:

What I’ve come to embrace is that being almost fundamentalistic about when I create a new controller to stay adherent to REST has served me better every single time.

What I’ve come to embrace is that being almost fundamentalistic about when I create a new controller to stay adherent to REST has served me better every single time. Every single time I’ve regretted the state of my controllers, it’s been because I’ve had too few of them. I’ve been trying to overload things too heavily.

So, in Basecamp 3 we spin off controllers every single time there’s even sort of a subresource that makes sense. Which can be things like filters. Like, say, you have this screen and it looks in a certain state. Well, if you apply a couple of filters and dropdowns to it, it’s in a different state. Sometimes we just take those states and we make a brand new controller for it.

The heuristics I use to drive that is: whenever I have the inclination that I want to add a method on a controller that’s not part of the default five or whatever REST actions that we have by default, make a new controller! And just call it that.

So let’s say you have an InboxController and you have an index that shows everything that’s in the inbox; and you might have another action where you go like “Oh I wanna see like the pending. Just show me the pending emails in that or something like that”. So you add an action called pendings:

1
2
3
4
5
6
7

class InboxesController < ApplicationController
  def index
  end

  def pendings
  end
end

That’s a very common pattern right? And a pattern that I used to follow more.

Now I just go like “no no no”. Have a new controller that’s called Inboxes::PendingsController that just has a single method called index:

1
2
3
4

class InboxesController < ApplicationController
  def index
  end
end

1
2
3
4

class Inboxes::PendingsController < ApplicationController
  def index
  end
end

And what I found is that the freedom that gives you is that each controller now has its own scope with its own sets of filters that apply […].

So we’ve had great controller proliferation and especially controller proliferation within namespaces. So let’s say we have a MessagesController and below that controller we might have a Messages::DraftsController and we might have a Messages::TrashesController and we might have all these other subcontrollers or subresources within the same thing. That’s been a huge success.

Amen.

So basically he says that controllers should only use the default CRUD actions index, show, new, edit, create, update, destroy. Any other action would lead to the creation of a dedicated controller (which itself only has default CRUD actions).

What I think about it

From now on the following opinions are my own. Different opinions are totally OK. Just saying, before you call me a pontificating zealot. Calm down guys!

Anyways, I was happy to learn that I have been using “the DHH way” to organize controllers for more than a year now #DHHFanboy. The examples he mentions are only about filtering though, and are probably overkill for simple controller logic. A common way to filter in REST is by using query parameters (e.g. GET /inboxes?state=pending), so I would stick to that when the code is short and simple (once it gets long or complicated or there are too many mixed actions/concerns, I would do the same as him).

But I totally agree with the general idea of splitting controllers. I like it for several reasons.

It encourages you to produce simpler code

With this technique you can create as many controllers as you want.
Use your judgment though: If the controller only has default CRUD actions and is relatively short/simple (like the ones scaffolded by Rails), there is probably no need to prematurely extract each index/show/etc into their own controller.

Where the controller splitting technique becomes very cool is when the controller is getting heavier, even when it has only default CRUD actions. What to do then? Well, just put the heavy code in its own dedicated controller!

For example, here is what our most complicated controller looks like at my current company (we are using “relatively skinny models and fat controllers” so YMMV). It allows you to purchase a product in the API part of our app:

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

class Api::V1::PurchasesController < Api::V1::ApplicationController

  rescue_from Stripe::StripeError, with: :log_payment_error

  def create
    load_product
    load_device
    load_or_create_user

    create_order
    create_payment
    authorize_payment
    confirm_address

    render json: @order, status: :created
  end

  private

  def load_product
    @product = Product.find_by!(uuid: params[:product_id])
  end

  # …

end

There is only one public method (the default CRUD create action). No premature abstractions into fat models, no “service classes”, no observers, no nothing, no bullshit. Everything is here, nicely contained in the controller. No need to jump between a dozen files to understand what is going on; you just need to open this one file in your code editor. And since controllers are the entry point for any web application code, you would open that file anyway when coding. #ObviousCode

But you may ask “Jeez, how long is that class since you dump everything in it? Surely it is very long, like a gazillion lines, right?” Nope. 144 lines.

And that’s our most complicated controller. Like, the worst of the worst. We could arguably split its code into smaller chunks but it looks good enough to us (YMMV). The rest of our other “fat” controllers are much simpler: between 6 and 103 lines long, with an average of 15 lines of code per controller (we have about 150 controllers for now).

Remember the projects you worked on where controllers were 200+ lines long AND this was only a small portion of the code related to the request — the rest of it being scattered between a gazillion of service objects, observers, and models? This kind of shit doesn’t happen here, mostly thanks to this controller splitting technique, among other easy things like the rule of 3. Indeed, duplication is far cheaper than the wrong abstraction, and it’s one of the reasons why I think (like DHH) that DRY and SRP are crap and they are overrated and they shouldn’t be an end in themselves and they suck balls and and and… Anywaaays, back to our topic!

It makes your code more uniform

Knowing that there can only be so many CRUD actions in a controller is quite cool. No more guessing/spelunking/endlessly scrolling in long controllers to find that one weird action. No more wondering how/if a custom controller method maps to a route.

I don’t like to be surprised when doing mundane organization. I like uniform code, and heavy convention over configuration is one of the many reasons why I still prefer Rails compared to other Ruby frameworks. Everything is organized the same, so you spend less time making mundane decisions, and make faster progress in areas that really matter for the business.

In theory, it also means that you can move from one codebase to another and be 100% productive in a very short time. In practice people seem to encounter many “horrible Rails apps” in the wild. One company may use architectural patterns such as observers (not my cup of tea), another might use a whole additional architecture layer such as Trailblazer (not my cup of tea either but it has some interesting ideas), another company will use yet another tool, another one will use its own custom sauce, etc.

All of this because people seem uneasy and unhappy with the so-called “lack of structure” in vanilla Rails apps. So they look for additional structure elsewhere. Guys! The solution is right under your nose! Split your controllers, and only use the default CRUD actions. Simple as pie, and junior developer friendly.

Rails could possibly do a better job of promoting this controller splitting heuristics. Their doc only briefly says “[…] you should usually use resourceful routing […]”. But the idea of CRUD actions and RESTful routes has prominently been featured in their doc for ages. If you RTFM’ed, it has probably crossed your mind at least once that adding custom actions (apart from the CRUD ones) is not very “Rails way”. Splitting controllers is a good answer to that uneasy feeling.

It makes you think in terms of REST

A lot of people like REST because it is uniform and simple. Once you understand a (truly) RESTful API, it is easier to understand another one. In theory at least: authentication anyone? ;-). The business logic obviously differs between applications so you have to understand it, but how you consume that logic is the same: you create a charge in Stripe (i.e. you take someone’s money), you create an SMS in Twilio (i.e. you send it), you get a repository in Github, etc.

You have to bend your mind a little at first to use REST nouns instead of actions: you don’t “pay”, you “create a payment”. You don’t “add funds to your balance”, you “create a fund in a balance”. Et cetera. Maybe a bit weird at first, but I would pay this small price any day of the week rather than going back to SOAP, WSDL and all that jazz (ex-Java/JEE developers will know what I’m talking about).

As a bonus, I think that having your whole business logic interface (not necessarily implementation) dictated by REST makes for a cleaner and simpler business logic. You can only have objects with so many actions: no more, no less. Yet you know you can express anything with REST, and it will be sound and dependable. It is a liberating constraint.

Here are some example RESTful Rails routes that map to splitted controllers that only use CRUD actions.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

resources :purchases, only: :create

resources :costs_calculations, only: :create

namespace :company do
  resource :account_details, only: :update
  resource :website_details, only: :update
  resource :contact_details, only: :update
end

namespace :balance do
  resources :funds, only: :create
end

resource :bank_account, only: :update

For best REST design (especially when subresources are involved), I usually write down the REST action+resource first on a temporary note (example: POST /balance/funds) without worrying about the implementation. Then when I am happy with the naming, I translate it to a Rails route, which is trivial since Rails has very good REST support.

Wrapping up

Splitting your Rails controllers when they have a very specific scope, too much logic, or too many mixed concerns can have a lot of good side effects in your code.

It doesn’t mean that you never abstract. It just comes later down the road. At some point some logic needs to be shared by several controllers. Sometimes even a splitted controller with only one public method gets too big. Et cetera. This is where concerns, model methods, possibly background jobs, and even sometimes service objects (hopefully not too many) come into play.

The more your app grows, the more time you will need to spend to understand it, no matter how clean the code is. But splitting your controllers makes things easier.

]]> <![CDATA[Leveraging Rails' custom configuration]]> 2015-10-17T16:52:00-07:00 http://jeromedalbert.com/leveraging-rails-custom-configuration

These days, I use environment variables for credentials and other sensitive data (secrets.yml could do the job but is too boilerplate-y for my taste). Dummy environment values are stored in my project dotenv file and production values are deployed to the PaaS server of my choice with a simple heroku config:set / eb setenv / etc.

But what about non-sensitive configuration values such as emails or your company address?

Storing them in environment variables both in your project and in your server is overkill and not really compliant with 12 factor apps. Those values are best stored in your project source code, in some sort of configuration file.

Rails 4.2 introduced a custom configuration object that can be accessed with Rails.configuration.x, and Rails.application.config_for loads YAML file values depending on the environment. By combining those two features, you can have all your custom configuration in a handy all-in-one YAML file!

Say your project is called MyApp:

  • Create a my_app.yml file in the config directory. It would look something like this:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

# MyApp custom configuration.
# Do not put sensitive data in this file (use environment variables instead).

default: &default
  emails:
    support: support@my-app.com
    marketing: marketing@my-app.com
  company_address: 221B Baker Street

production:
  <<: *default

development:
  <<: *default
  emails:
    support: support+dev@my-app.com

test:
  <<: *default
  • Add this line in your config/application.rb file:
1
2
3
4
5
6
7
8
9
10

# ...

module MyApp
  class Application < Rails::Application
    # ...

    # Custom configuration
    config.x = Hashie::Mash.new(Rails.application.config_for(:my_app))
  end
end

You can see that I wrap the loaded configuration hash in a hashie Mash object. I just use it for convenience so that I can access configuration variables with dots rather than brackets (it’s like OpenStruct with nested hash support). To use it, add gem 'hashie' to your Gemfile.

  • You can now access your configuration variables anywhere in your app like so:
1

Rails.configuration.x.emails.support

I hope that in future releases, Rails will improve its secret and configuration handling so that they can be even easier to use out of the box. But for now, this will do!

]]> <![CDATA[Migrate from Oh-my-zsh to Prezto]]> 2014-05-06T22:44:00-07:00 http://jeromedalbert.com/migrate-from-oh-my-zsh-to-prezto

EDIT: This article is outdated. I have moved away from Prezto and now use my own minimal ZSH settings.

Zsh is an amazing shell, and Oh-my-zsh is very good at showcasing its power without having to dive into too much configuration. I recommend it to Zsh first-timers: within minutes they can enjoy autocompletion on steroids, crazy prompt tweaking, git integration as well as many other plugins.

BUT. It’s God. Damn. Slow!

Wanna spend the night happily coding and hacking in the “zone”? Here, wait for 1 long second (or more) whenever you open up a new terminal window/tab. Are you triggering tab autocompletion? Oh boy. Come back tomorrow.

Enter Prezto, a.k.a the “Instantly Awesome Zsh”. It began as a fork of Oh-my-zsh, but was later completely rewritten with optimization in mind, and moved to its own repo.

Here’s how I migrated in order to have the exact same behavior as before, while still having a fast shell. Yes, I like to have my cake and eat it too.

Installation

Very straightforward:

  • Backup your existing configuration: ~/.oh-my-zsh, ~/.zshrc and your possible other dotfiles
  • Uninstall Oh-my-zsh by running uninstall_oh_my_zsh
  • Install Prezto by following the quick instructions on the github repo

Done. You now have a bunch of symlinked .z<something> dotfiles in your home folder.

Fiddling with the dotfiles

  • If it annoys you, remove the possible example instructions in ~/.zlogin and ~/.zlogout (such as displaying a fortune every time you login)
  • Put back all your aliases and other customizations into ~/.zshrc:
1
2
3
4
5
6
7
8
9
10
11
12

source ~/.zprezto/init.zsh

export SUBLIME=subl
export EDITOR="$SUBLIME --wait"
export VISUAL=$EDITOR
export LSCOLORS="exfxcxdxbxegedabagacad"
...

alias ll="ls -lh"
alias la="ls -A"
alias gl="git pull --rebase"
...
  • If you like to organize your exports/aliases/etc into separate files, have a look at the other dotfiles. I personally don’t do that and just have one massive ~/.zshrc.

Customizing the prompt

Now to the fun part!
Prezto contains half a dozen example themes compared to the 140 (!) ones of Oh-my-zsh. If you have a custom prompt like me, you will need to tinker a bit.

My theme is quite minimalist: just display the current path followed by $ and a space. When in a Git repo, I like to display the branch name followed by a dirty/clean indicator like so:

At the time of writing, most Prezto themes use vcs_info which can detect staged and unstaged changes (i.e. a dirty state). But there’s no hook for a clean state, so when there are no changes, the prompt will just display nothing. I would much rather have a satisfying green little tick that means “Nothing else to do! Well done mate, you can have a beer* now”.

For this, we need to use git-info from the Prezto git plugin. I ended up with this:

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
29
30

function prompt_jerome_precmd {
  git-info
}

function prompt_jerome_setup {
  setopt LOCAL_OPTIONS
  unsetopt XTRACE KSH_ARRAYS
  prompt_opts=(cr percent subst)

  # Load required functions.
  autoload -Uz add-zsh-hook

  # Add hook for calling git-info before each command.
  add-zsh-hook precmd prompt_jerome_precmd

  # Set git-info parameters.
  zstyle ':prezto:module:git:info' verbose 'yes'
  zstyle ':prezto:module:git:info:branch' format '%F{green}%b%f'
  zstyle ':prezto:module:git:info:clean' format ' %F{green}✔%f'
  zstyle ':prezto:module:git:info:dirty' format ' %F{red}✗%f'
  zstyle ':prezto:module:git:info:keys' format \
    'prompt' ' %F{green}(%f$(coalesce "%b" "%p" "%c")${git_info[rprompt]}%s%F{green})%f' \
    'rprompt' '%C%D'

  # Define prompts.
  PROMPT='%~${(e)git_info[prompt]}$ '
  RPROMPT=''
}

prompt_jerome_setup "$@"

I then saved the theme in ~/.zprezto/modules/prompt/functions/prompt_jerome_setup and made Prezto use it by having this line in ~/.zpreztorc:

1

zstyle ':prezto:module:prompt' theme 'jerome'

Done.

Last bits and pieces

  • I added history-substring-search and git to the ~/.zpreztorc plugin list:
1
2
3
4
5
6
7
8
9
10
11
12
13
14

...
zstyle ':prezto:load' pmodule \
  'environment' \
  'terminal' \
  'editor' \
  'history' \
  'directory' \
  'spectrum' \
  'utility' \
  'completion' \
  'prompt' \
  'history-substring-search' \
  'git'
...

history-substring-search: when pressing up/down arrows, completes the beginning of a command by searching in the history.
git: adds useful aliases and functions like the git-info one that we discussed above.

  • When pressing tab to complete a command, I didn’t like the category menus, so I commented these lines out in ~/.zprezto/modules/completion/init.zsh:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15

...
# Group matches and describe.
zstyle ':completion:*:*:*:*:*' menu select
# zstyle ':completion:*:matches' group 'yes'
# zstyle ':completion:*:options' description 'yes'
# zstyle ':completion:*:options' auto-description '%d'
# zstyle ':completion:*:corrections' format ' %F{green}-- %d (errors: %e) --%f'
# zstyle ':completion:*:descriptions' format ' %F{yellow}-- %d --%f'
# zstyle ':completion:*:messages' format ' %F{purple} -- %d --%f'
# zstyle ':completion:*:warnings' format ' %F{red}-- no matches found --%f'
# zstyle ':completion:*:default' list-prompt '%S%M matches%s'
# zstyle ':completion:*' format ' %F{yellow}-- %d --%f'
# zstyle ':completion:*' group-name ''
# zstyle ':completion:*' verbose yes
...

I also modified this line in order to have red diretories when autocompleting the cd command:

1
2

# Directories
zstyle ':completion:*:default' list-colors ''
  • In my ~/.zshrc, I added these zsh options:
1
2
3
4
5
6
7
8
9
10

unsetopt CORRECT                      # Disable autocorrect guesses. Happens when typing a wrong
                                      # command that may look like an existing one.

expand-or-complete-with-dots() {      # This bunch of code displays red dots when autocompleting
  echo -n "\e[31m......\e[0m"         # a command with the tab key, "Oh-my-zsh"-style.
  zle expand-or-complete
  zle redisplay
}
zle -N expand-or-complete-with-dots
bindkey "^I" expand-or-complete-with-dots

Wrapping up

That’s it, you now have a fast zsh that behaves like before!

I skipped some very minor configurations in this article, so if you want to review exactly what I’ve done (or if you want to know what kind of crazy stuff I put in my ~/.zshrc), have a look at the commits in my Prezto fork.

Enjoy!

EDIT: Hacker News thread

*I prefer cider.
]]> <![CDATA[Ruby: How to iterate "the right way"]]> 2014-01-05T14:12:00-08:00 http://jeromedalbert.com/ruby-how-to-iterate-the-right-way

If any of you have written code in the last year that had an explicit loop […], you don’t understand collections.

You may be baffled by this quote if you come from a C-flavored language such as C++ and Java, where explicit loops like for and foreach are part of your everyday life.

Luckily, collection methods come built-in with Ruby. Once you realize how powerful they are compared to explicit loops, there is no going back!

each

Let’s begin with the collection method that has the least added value.
each is the equivalent of a for loop. Use it when you need to iterate on a collection with side effects.

1
2
3

['a', 'b', 'c'].each do |e|
  # do side effects, such as printing to the console, writing to a file, persisting in database, etc.
end

For your information, Ruby also has a for statement (nobody uses it though).

map

(alias to avoid: collect)
Whenever you need to transform some values into some other values, map is your friend.

1
2
3
4
5

[1, 2, 3].map { |e| e * 2 } # returns [2, 4, 6]

['a', 'b', 'c'].map { |e| e.upcase } # returns ['A', 'B', 'C']

['a', 'b', 'c'].map(&:upcase) # same result as before, for experienced lazy Ruby programmers

map is your bread and butter. I probably use it more than each.

select

(alias to avoid: find_all)
Very useful when you need to filter (i.e. “select”) multiple values.

1

[1, 2, 3, 4].select { |e| e % 2 == 0 } # returns [2, 4]

reject

The contrary of select

1

[1, 2, 3, 4].reject { |e| e % 2 == 0 } # returns [1, 3]

partition

select + reject

1

[2, 3, 4, 5].partition { |e| e.even? } # returns [[2, 4], [3, 5]]

find

(alias to avoid: detect)
Very useful when you need to find a single value.

1

[4, 6, 8, 13].find { |e| e > 7 } # Returns 8 (the first found element)

reduce

(alias to avoid: inject)
reduce is very important in functionnal programming, where it is also known as fold. Indeed, it can be used to build everything else: map, select, find, min, max, sums, etc.
The idea is to use an accumulator that will contain the final result. This accumulator can be anything: a number, an array, a hash, etc.

1
2
3
4
5
6
7
8
9
10
11
12
13
14

[1, 2, 3].reduce(0) { |acc, e| acc + e } # returns 6 (0 + 1 + 2 + 3).
                                         # 0 is the initial value of the accumulator.

[1, 2, 3].reduce { |acc, e| acc + e } # same result as before. When we omit the accumulator initial
                                      # value, the first element of the array is chosen.
                                      # So in our case, 1 is the initial value of the accumulator.
                                      # What is computed is 1 + 2 + 3.

[1, 2, 3].reduce(:+) # same result as before, for experienced lazy Ruby programmers.
                     # Reduce accepts :+, but you can also use &:+

[2, 3, 4].reduce { |acc, e| acc * e } # returns 24 (2 * 3 * 4)

[0, 2, 3, 4].reduce { |acc, e| acc * e } # returns 0 (0 * 2 * 3 * 4)

I rarely use reduce in practice, but it is fun and good to know for your computer science culture.

all?

1

[2, 4, 6].all? { |e| e.even? } # returns true

Self-explanatory.

any?

1

[3, 8, 42].any? { |e| e > 10 } # returns true

Self-explanatory.

By the way, I like using the “no block” form of any? to ask if something “has any” significant element:

1
2
3
4

[3, 4].any? # returns true
[].any? # returns false
[nil].any? # returns false
[false].any? # returns false

I find it more expressive than !some_array.empty?.

times

This is a funny one!

1
2
3

3.times { puts 'Hello world!' } # prints 'Hello world!' 3 times

3.times { |i| puts i } # prints '0', '1' and '2'

In practice I don’t use it very often though.

Sorting methods

1
2
3
4

[7, 2, 5].sort # returns [2, 5, 7]
['c', 'b', 'a'].sort # returns ['a', 'b', 'c']

employees.sort_by {|e| e.last_name} # sort your employees by last name

But… I want indexes!

On top of the current element, you also need the current index? Worry not, fellow citizen. Ruby has it all.

1
2
3
4
5
6
7

['a', 'b', 'c'].each_with_index do |e, i|
  # do stuff
end

['a', 'b', 'c'].map.with_index do |e, i|
  # do stuff
end

In practice I don’t use each_with_index very often. I never had to use map.with_index, but I put it for the sake of being comprehensive.

Explicit loops

Collection methods will probably cover 90% of your needs. What is certain is that you won’t need to use a for loop ever again.

However, there are cases when the number of iterations in not known in advance: if you work on an algorithm or low-level code, for example. This is a typical job for while and until. In this case, these explicit loops are ok to use.

1
2
3
4
5
6
7
8
9

finished = false
until finished
  # do stuff
end

x = 100
while x > 0
  # do stuff
end

You may want to use an infinite loop: for example the main infinite loop of a video game. Here is the syntax:

1
2
3
4

loop do
 # do stuff.
 # You can still exit the loop with break.
end

Same as while true, but terser.

Going further

Ruby collection methods become even more powerful if you combine them:

1
2
3
4
5

['coconut', 'lemon', 'banana', 'apple'].select { |e| e.size > 5 }
                                       .map    { |e| e.upcase }
                                       .sort

# returns ['BANANA', 'COCONUT']

Don’t do this to excess though!

This article covers the main collection methods: feel free to dive into the Ruby Core documentation for more.
Finally, if you are wondering why I avoid aliases such as collect and inject, you can read this community-driven Ruby style guide.

]]> <![CDATA[Dead simple file handling in Ruby]]> 2013-11-10T18:52:00-08:00 http://jeromedalbert.com/dead-simple-file-handling-in-ruby

Common scenario
You are writing a basic Ruby script that needs to read or write in some text files.
So you search “ruby write file” and “ruby read file” on Google.
You end up on the usual tutorials and Stack Overflow answers that tell you to open files with r or w mode, “1970 C style”.

It’s OK, it works. But you may think:
“I’m in the 21st century goddammit. I just want to read/write in a file, spare me the details!”

Worry not, fellow citizen. Have a look at the code below.
In all of these examples, Ruby automatically opens and closes the file. No need to think about it.

Read a whole file

1

content = File.read('input.txt')

Done.

Write to a file

1

File.write('output.txt', 'Hello world')

‘Nuff said.

What if I want to …?

The above code covers 80%* of the needs for quick Ruby scripts. Feel free to skip the rest of this post.
Just for the sake of being comprehensive, here are the other 20%*, slightly more complex because used less often.

Read a file line by line (useful if you don’t want to load a big file entirely in memory):

1

File.open('input.txt', 'r').each_line { |line| puts line }

Another way to do it is File.foreach('input.txt') { |line| puts line }, though I don’t find foreach very Ruby idiomatic.

Put the lines of a file in an array of lines (I’ve never needed to do it, but this is for reference):

1

lines = File.readlines('input.txt')

Append some text at the end of a file:

1

File.open('file.txt', 'a') { |file| file.write('some text') }

You can also do file << 'some text'. Or file.puts('some text') if you want to insert the text with a \n in the end.

*These numbers are completely made up. Do not trust the Internet.
]]> <![CDATA[What traffic do you get when mentioned by several Ruby authorities?]]> 2013-11-10T16:50:00-08:00 http://jeromedalbert.com/what-traffic-do-you-get-when-mentioned-by-several-ruby-authorities

EDIT: Some of my latest articles have had traffic orders of magnitude larger than the one mentioned below, making the figures completely obsolete.

It looks like my latest blog post, A Diagram of the Ruby Core Object Model, has had quite a bit of a success in the Ruby community. Mostly in the educational sphere, that is, Ruby beginners (the targeted audience) but also… trainers!
Well, as long as you guys cite your sources, it’s fine by me!

It casually begins with a decent score on Reddit:

Then, the unexpected happens: I get retweeted by Matz, the creator of Ruby! I can die in peace now. Minaswan.

Finally, two weeks later, my post gets mentioned in the famous Ruby Weekly newsletter! Definitely a lot of traffic coming from there.

In terms of metrics, in two weeks, I had 5000 hits, 70 related tweets, and a couple of new followers and e-mail messages.

Overall, I am surprised and humbled by the attention this post had. It looks like people want more of this kind of visual explanations: I admit it lacks a bit on the Internet.

]]> <![CDATA[A diagram of the Ruby Core object model]]> 2013-10-05T20:26:00-07:00 http://jeromedalbert.com/a-diagram-of-the-ruby-core-object-model

I am a visual learner. A picture is worth a thousand words.

When I started learning Ruby, I could not find a decent diagram that would just sum up the Ruby classes, modules, and their hierarchy.

So I made mine.
By hand.
On an A4 sheet.

Here is the result (click for a full size view):

Most of Ruby’s guts at one glance: pretty neat, huh ?

  • Modules are on the top left.
  • The usual types are here: strings, arrays, hashes, numbers, “booleans” (actually TrueClass and FalseClass).
  • The error hierarchy is on the right.
  • Other classes are in the middle.

Note: To have a decent layout, I only drew 70% of the Ruby 2 Core classes. All of the important ones are there, except Random, Time, GC and ObjectSpace: when I noticed, it was too late. :-)

What can we “draw” from this ?

Well, this model is pretty much what we would have expected:

  • Arrays are enumerable, numbers are comparable.
  • “Everything is an object”, or more precisely, every box is this diagram is a BasicObject.
  • Object includes the Kernel module, so Object has all the instance methods of Kernel, like puts, gets, exit. When you write Ruby code, you are inside a main object, that’s why you can just write puts 'Hello world' instead of Kernel.puts 'Hello world'.

So, everything makes sense and is quite simple actually! Except maybe the fact that a module is a class, and class inherits from module. Don’t worry, you will eventually wrap your head around it.

Going further

In addition to Ruby Core, the Ruby Standard Library contains many other very useful classes and modules, such as Date, Forwardable, SimpleDelegator, Net::HTTP, OpenStruct, etc.

This diagram does not explain the Ruby method lookup path, which takes eigenclasses, included modules and superclasses into account. I recommend reading this enlightening article from Practicing Ruby.

]]> <![CDATA[First post]]> 2013-10-02T20:53:00-07:00 http://jeromedalbert.com/first-post

Hi everyone, welcome to my blog!

Let me tell you an inspiring story of honor and glory.

June: the idea of creating a blog springs in my little head.
Early July: I start talking about it to a couple of people.

July, August, September: ???

End of September: a fellow coworker asks me how far I am into this blog project.
I realize I was vegetating the whole time, watching all of the Doctor Who series.

One day later: I frenetically spend my whole Saturday + half of the night creating and customizing this blog…
Motivation comes in mysterious ways !

So, what is this blog going to talk about ?

Contrary to what it may seem, this is not a Ruby only blog: I just found the logo cool. This is a tech blog at the moment. I will post some day-to-day discoveries and tips and tricks, share my thoughts about software craftsmanship (or whatever this pontificating word means) and maybe talk about life as an IT professional in general.

What can I do to help ?

How thoughtful of you to ask this question. I doubt having any reader at all, but if so, do not hesitate to contribute with a comment.

]]>