TIL

This afternoon my pair and I spent quite a while on a subtle bug. The culprit? Variable hoisting. Take this file: class Test def self.hoist require 'pry'; binding.pry; bar = 1 end end Test.hoist When we hit the PRY debugger, what will the value of bar be? I would have thought it would raise NameError, because bar has seemingly not yet been defined. Wrong: $ ruby test.rb From: /test.rb @ line 4 Test.hoist: 2: def self.hoist 3: require 'pry'; binding.pry; => 4: bar = 1 5: end [1] pry(Test)> bar => nil When Ruby parses a file, it ‘hoists’ each variable to the top of its scope, declaring and setting it to nil, even if that variable is never assigned by our code. So variables inside an if false conditional get hoisted and set to nil, as described in this blog post. ...

Today I found a great command in Pathogen.vim, :Helptags. This is a riff off :helptags {dir}, a Vim feature that builds helptags for directory {dir}. :Helptags does the same for all the directories in your runtimepath, which defaults on Unix and Mac OS X to: "$HOME/.vim, $VIM/vimfiles, $VIMRUNTIME, $VIM/vimfiles/after, $HOME/.vim/after" The use case here is when you’ve just loaded a new plugin into your Vim bundle, you open up Vim, and :h {my_new_plugin} isn’t ‘helping’ you out.

Have you ever wondered about those secret keys found in config/secrets.yml of your Rails app? The comments generated in that file describe the keys as ‘used for verifying the integrity of signed cookies.’ Great… but what if they become compromised? Or we need to change them? We can generate new ones. Rails provides rake secret for just this purpose. The source code is here. It’s pretty simple; the code simply requires SecureRandom and spits out a string. If you want to be really clever, you can pipe the string directly into your Vim buffer for the config file, with :.! rake secret. ...

This week Josh Branchaud wrote about show-models in Pry-rails: http://til.hashrocket.com/posts/62f61ee06f-show-rails-models-with-pry This method has two nice variants. show-model User shows you that model, useful in a large database. show-models also accepts --grep for searching: [1] pry(main)> show-models --grep published Post id: integer title: string published_at: datetime # 'published' is highlighted

ActiveRecord provides default_scope, which you can use to control how records are returned. An example: # app/model/chapter.rb class Chapter < ActiveRecord::Base default_scope { order(:title) } end Now, instead of this (ordered by ID): Chapter.all.pluck(:title).take(5) => ["BALINESE CAUSE", "BUILDING RAT", "TAIL", "LILAC MERCURY", "PUMP SQUARE"] We get this: Chapter.all.pluck(:title).take(5) => ["AFGHANISTAN COAT", "ALCOHOL GONG", "ANTARCTICA BULL", "ASPARAGUS", "BALINESE CAUSE"] Beware, this decision can lead to inexplicable behavior down the road. Use with caution. One use case I’ve heard is soft deletes. We might not want soft-deleted records appearing in .all: ...

Vim has excellent commands for changing the contents of parentheses (ci(), brackets (ci[), and squiggly braces (ci{) (as well as single quotes, double quotes, backticks, etc.). But what about tags? Place your cursor anywhere inside the tags, type cit in Visual mode, and this: <div>Begone</div> Becomes: <div></div> d works too, but I prefer c because it puts you in Insert mode at the end of the opening tag, ready to type. ...

Haml’s design makes HTML and Ruby tricky to mix inline. But we have Haml helper methods to make it easier. Here is succeed in action: Developer at = succeed ', ' do = link_to "Hashrocket", "https://hashrocket.com/" This becomes: Developer at <a href="https://hashrocket.com/">Hashrocket</a>, Notice the comma at the end, outside of the a tag? precede and surround work in a similar fashion, and do what we’d expect. http://haml.info/docs/yardoc/file.REFERENCE.html#succeed

Vim has commands built-in to increment and decrement numbers: CTRL-A and CTRL-X, respectively. Combining this with a macro was a technique we tried today to build a large database migration. We ended up finding a more efficient solution, but it’s still a very magical key combination. Check out :help CTRL-A for more info. h/t Josh Branchaud

We had a testing issue this week when a button’s text save changes! was rendering as SAVE CHANGES!, due to the CSS property text-transform: uppercase. How do you test that? One technique is to use RSpec’s match method, and include case insensitivity with i (explored earlier here): > button_text = "foo" => "foo" > expect(button_text).to match("FOO") RSpec::Expectations::ExpectationNotMetError: expected "foo" to match "FOO" # stuff > expect(button_text).to match(/FOO/i) => true We ultimately hard coded the expectation to match("FOO"), because allowing fOo and FoO seemed too permissive. But it remains an option.

Today I found a way to assert that an edit form’s inputs include a record’s saved data. I think it strikes a good balance between broad and narrow scope. # spec/features/user_edits_kit_spec.rb within 'form' do expect(page).to have_selector("input[value='Default copy.']") end This asserts that some content is inside an input field in the form, rather than just anywhere on the page. You can narrow the scope as needed.