Wednesday, February 8, 2017

Naming conventions are important even in Fizz Buzz

I was playing around with Fizz Buzz today.

I started thinking about the dividing part of Fizz Buzz.

I originally was creating 3 methods which I then called in the print_fizzbuzz method.

def divide_by_fifteen(num)
  num % 15

def divide_by_three(num)
  num % 3

def divide_by_five(num)
  num % 5

I realized that I could condense these into one method.

So I went back to math to figure out the best wording for the arguments.

dividend  / divisor == quotient

And thus the final method that is very clear as long as you remember your math.
I added this: ( dividend  / divisor == quotient ) as a comment to be crystal clear.

def divide_by(dividend, divisor)
  dividend % divisor == 0


Then to print the fizz buzz I was looping through a range, for the argument I was using the placeholder num.

I started to think about what I was actually trying to say there.
Instead of just saying num what was it that I really meant?

It took me a while to distill down the words in my head.

First I thought about the problem.
What is "num"? It is the number that I want the Fizz Buzz to stop at.
So I thought end_num, end_number, limit.

When trying to narrow down a word I find it useful to use a Thesaurus
Here are the synonyms for the word limit:

These are the words that I thought might be good for my argument after viewing that list:
terminates at
end of range

Then I noticed that I was calling a range.
What could the beginning and the end of a rangebe called?
Answer: lower bound and upper bound

  def print_fizz_buzz(upper_bound)
    fizzbuzz = []
    (1..upper_bound).each do | dividend |
      if divide_by(dividend, 15)
        fizzbuzz << "fizz buzz"
      elsif divide_by(dividend,3)
        fizzbuzz << "fizz"
      elsif divide_by(dividend,5)
        fizzbuzz << "buzz"
        fizzbuzz << dividend

Tuesday, November 29, 2016

Thursday, September 1, 2016

View your Gems and its methods locally with no internet

In this example I am viewing my Devise Gem.
(Your paths will be different than mine.)

$ gem which devise
==> /home/vagrant/.rvm/gems/ruby-2.3.0/gems/devise-4.2.0/lib/devise.rb

$ gem open devise

$ cd /home/vagrant/.rvm/gems/ruby-2.3.0/gems/devise-4.2.0/lib

$  ls
==> devise  devise.rb  generators

$ cd devise/

$ ls
==> controllers     hooks       models.rb    orm                     rails.rb         time_inflector.rb
delegator.rb    mailers     modules.rb   parameter_filter.rb     strategies       token_generator.rb
encryptor.rb    mapping.rb  omniauth     parameter_sanitizer.rb  test             version.rb
failure_app.rb  models      omniauth.rb  rails                   test_helpers.rb

$ cd controllers/

$ ls
==> helpers.rb  rememberable.rb  scoped_views.rb  sign_in_out.rb  store_location.rb  url_helpers.rb

$ cd ..

Here I am looking for the RegistrationsController in all the files with Grep. This is like when you are in Sublime and search all the files.

$ grep -r RegistrationsC .
==> ./rails/routes.rb:    #    class RegistrationsController < Devise::RegistrationsController
./parameter_sanitizer.rb:  # +password_confirmation+ for the `RegistrationsController`), and you can
./parameter_sanitizer.rb:    #    # Inside the `RegistrationsController#create` action.

$ cd rails/

$ ls
==> routes.rb  warden_compat.rb

This is where it is. I open it in vim and look around.
$ vim routes.rb 

Thursday, August 25, 2016

git add with sophictication

I found this git command that I have been looking for forever.
I used to use it then I forgot it and have been googling for it ever since/.

The perfect pairing to git add -p, drum roll please...

git add . -N && git add -p

Wednesday, April 13, 2016

Notes on Redis

Thursday, April 7, 2016

Squashing a commit

  • You just sent a pull request to GitHub.
  • Someone commented on it.
  • You fixed the errors. You added them, commited them and pushed them again. 

This actually adds another commit to that pull request and makes it really hard to read for the person who is trying to accept that commit.

What you can do to combine these commits into one, easy to read commit is to squash them together.

This is officially called squashing a commit.

Squash a commit:
$ git rebase -i HEAD~3

You'll see your commits all mashed together

pick Add to README
pick Add .gitignore
pick Edit README

and a list of options

what you want to do is Put the commit you want at the top and squash the other ones into it by removing the work pick in front of it and replacing that with the letter 's' for squash.

So it looks like this

pick Add to README
s Add .gitignore

save it and force push it to GitHub like this:

$ git push origin branch-name --force

Then instead of doing the whole thing again if you make another change just
git add  
git commit --amend
git push origin branch-name --force

and you can add to you former commit

Monday, March 28, 2016

Group Asset deprecated in Rails 4

There is no longer any reason to declare group :asset endin your Gemfile because it was deprecated in Rails 4.

Do not use this:

group :asset do
  gem 'whatever'
Previously the assets group existed to avoid unintended compilation-on-demand in production. As Rails 4 doesn't behave like that anymore, it made sense to remove the asset group.
This is explained in more detail in the commit that changed that. I extracted some quotes with the actual answer.
Some gems can be needed (in production) like coffee-rails if you are using coffee templates and the fact that now assets are not precompiled on demand in production anymore.
(not precompiled on demand in production) Means that if you have that gems in production environment in 3.2.x and forget to precompile, Rails will do exactly what it does in development, precompile the assets that was requested. This is not true anymore in Rails 4, so if you don't precompile the assets using the tasks you will get a 404 when the assets are requests.