@sikac.hu

A faster way to exit a Pry session

2018-06-01T14:01:01+00:00

If you are using Pry in your project, you might run into a situation where you are in a loop or have multiple binding.pry calls so you have to use exit multiple times to get out of it.

So, instead of using exit multiple times, you can use exit-program to continue the execution without breaking into Pry again.

There is also a handy shortcut for this, which is !!!.

You can read more about exit-program and other ways to navigate around in your Pry session in Pry’s wiki page.

Poison Object: An Antidote for Your Nil

2015-11-10T14:09:15+00:00

I recently submitted a pull request to Ruby on Rails to make force reloading an association more explicit. I then came across this suggestion from Sage Griffin:

Rather than using nil here, can we be a little bit more explicit? A user could have theoretically been passing nil here, since we were just relying on truthy/falsy.

The code that they commented on looked like this (notice the force_reload = nil default):

def reader(force_reload = nil, reload: false)
  # Override `reload` if user passed in `force_reload`
  unless force_reload.nil?
    reload = force_reload
  end

  if reload
    # Executing code to reload the association
  end
end

They proposed that instead of using nil as a default value, I should create a poison object instead. My code now looked like this:

NO_FORCE_RELOAD_ARGUMENT = Object.new

def reader(force_reload = NO_FORCE_RELOAD_ARGUMENT, reload: false)
  if force_reload != NO_FORCE_RELOAD_ARGUMENT
    reload = force_reload
  end

  if reload
    # Executing code to reload the association
  end
end

This way, if a user passes in nil as an argument, the code will properly set the reload argument to nil instead of leaving it at the keyword argument’s value.

Next time you use nil as a default argument, don’t forget to ask yourself a question:

“Do I actually want to check whether the user passed in an argument?”

If you do, consider using a poison object like the example above. It will make your code much clearer.

How to keep sensitive commands out of .zsh_history

2015-11-09T01:49:01+00:00

By default, if you enable command history in Zsh, all commands including those that contain sensitive information such as an access token or a password will be saved into your command history file after you run them.

It’s definitely a bad idea to have that information wound up in your .zsh_history file.

However, there is a way you can tell Zsh to not putting a command in your history file by setting this option in your .zshrc:

setopt HIST_IGNORE_SPACE

After that, Zsh will not store any command that starts with a space in a history file.

So, instead of running this:

$ curl -u "LOLNOPE:x-oauth-basic" -i https://api.github.com/...

add an empty space before your command like this:

$  curl -u "LOLNOPE:x-oauth-basic" -i https://api.github.com/...
  ^--------- notice an empty space here

Note that this most recent command will temporarily stay in the command history in your current session so you can go back to reuse or edit it by using the UP arrow, and it will automatically disappear after you run another command in the same session.

You can read more about this in Zsh documentation