brianstorti

export LESS_TERMCAP_mb=$'\E[01;31m'       
export LESS_TERMCAP_md=$'\E[01;38;5;74m'  
export LESS_TERMCAP_me=$'\E[0m'           
export LESS_TERMCAP_so=$'\E[38;5;246m'    
export LESS_TERMCAP_se=$'\E[0m'           
export LESS_TERMCAP_us=$'\E[04;38;5;146m'
export LESS_TERMCAP_ue=$'\E[0m'          

brianstorti

git branch -r --merged master | ack -v master | sed -e 's/\// :/g' | xargs -n2 git push

brianstorti

instead of
tail -f log/development.log

use
less +F log/development.log

so you can use Ctrl-c to move/search inside de log (vim-like) and then Shift-f to go back to the monitoring state.

brianstorti

No one wants to die. Even people who want to go to heaven don’t want to die to get there.  
And yet death is the destination we all share. No one has ever escaped it. And that is as  
it should be, because Death is very likely the single best invention of Life. It is Life’s  
change agent. It clears out the old to make way for the new. Right now the new is you, but  
someday not too long from now, you will gradually become the old and be cleared away.  
Sorry to be so dramatic, but it is quite true.

Your time is limited, so don’t waste it living someone else’s life. Don’t be trapped by  
dogma — which is living with the results of other people’s thinking. Don’t let the noise  
of others’ opinions drown out your own inner voice. And most important, have the courage  

brianstorti

#Practical Object Oriented Design in Ruby

Design that anticipate specific future requirements almost always end badly.
Practical design does not anticipate what will happen to your application, it merely accepts that something
will and that, in the present, you cannot know what. It does not guess the future; it preserves your options for accommodating the future.
It doesn't choose; it leaves you room to move.
The purpose of design it to allow you to do it later and its primary goal is to reduce the cost of change.

Design is more the art of preserving changeability than it is the act of achieving perfection.

brianstorti

Levels of testing

Acceptance: Does the whole system work?
We use acceptance tests to help us, with the domain experts, understand and agree on what we are going to build next. We also use them do make sure that
we haven't broken any existing features as we continue developing. Our preferred implementation of the "role" of acceptance testing is to write end-to-end
tests which, as we just noted, should be as end-to-end as possible; our bias often leads us to use these terms interchangeably although, in some cases, 
acceptance tests might not be end-to-end.

Integration: Does our code work against code we can't change?
We use the term integration tests to refer to the tests that check how some of our code works with code from outside the team that we can't change. It might

brianstorti

Unit tests run fast. If they don't run fast, they aren't unit tests.

A test is not a unit test if:
- It  talks to a database
- It communicates across a network
- It touches the file system
- You have to do special things to your environment to run it (such as editing config files)

--------------------

brianstorti

my_var = 0

class MyClass
  # we want to print my_var here
  
  def my_method
    # and here
  end
end

brianstorti

class Tree
  include Comparable

  attr_accessor :age

  def initialize(age)
    @age = age
  end

  def <=> another_tree

brianstorti

def print_name(*args)
  first_name, second_name = args.flatten
  puts first_name + second_name
end

print_name  "Brian", "Storti"