rr mocking framework

How to mock something and raise exception? In your model if you need to test something that's raises ActiveRecordNotFound, you can do :

stub(some_object).walk { raise }

Bundler::GemNotFound: Could not find rake-10.3.2 in any of the sources

bundle install --path vendor/cache

30-inch Apple Cinema HD Display vs 34" Class 21:9 UltraWide™ WQHD IPS Curved LED Monitor Dimensions

30-inch Apple Cinema HD Display

• Height: 21.3 inches (54.3 cm)
• Width: 27.2 inches (68.8 cm)

34-inch Class 21:9 UltraWide™ WQHD IPS Curved LED Monitor (34.0" Diagonal

Height: 33.7' inches

Width: 14.6 inches

Doing exact text search using ack

ack -w bugs

The -w flag will search only bugs and not bugs-bunny or anything other than exact match.

raise in Ruby

raise in Ruby will raise whatever exception you rescue in your code. So instead of doing :

raise MyException

you can just do:

raise

Here is a demo:

class MyException < Exception
end

class Foo
  def hi
    raise MyException.new('hello')
  end
end

def tester
  begin
    f = Foo.new
    f.hi
  rescue
    raise
  end
end

tester

Count the number of tables in a database

show tables; select found_rows();

FactoryGirl::DuplicateDefinitionError: Factory already registered: author

I was getting this error in the rails console, when I did:

> FactoryGirl.find_definitions

Fix:

FactoryGirl.factories.clear
FactoryGirl.find_definitions

Using Textmate to Browse Source Code using Bundler

Run:

export BUNDLER_EDITOR=mate

in the terminal. Now you can do:

bundle open gem-name

to view the source. You can also add the BUNDLER_EDITOR variable to the bash_profile.

Railways of London Maps

Notes from the book Team Geek

• Software development is a team sport.
• You need to work with other people. 
• Share you vision.
• Divide the labor.
• Learn from others.
• Create a brilliant team.

Humility

•  You are not the center of the universe.
•  You don't know everything
•  You are not incapable of making mistakes or being wrong
•  It does not mean never failing

Respect

• Genuinely care about others you work with.
• You treat them as human beings
• You appreciate their abilities and accomplishments

Trust

• You believe others are competent and will do the right thing
• You're ok with letting them drive when appropriate

Almost every social conflict can be traced back to a lack of humility, respect or trust.

Lose the Ego

• Don't come off like a know-it-all
• Build a sense of team accomplishment and group pride

Learn to both deal out and handle criticism

•  Learn to respect your peers and give constructive criticism politely
•  Your self-worth shouldn't be connected to the code you write

Fail Fast, learn, iterate

•   Failure is viewed as a golden opportunity to learn and improve
•   Don't hide in the cave until it's perfect
•   It's ok to show imperfect software to users and some trust that your users really do appreciate     your efforts and are eager to see rapid improvements.
•   Document your failures  

What was learned and what is going to change as a result of the learning experience. Follow through on the proposed changes. Don't erase your tracks - light them up like a runway for those who follow you.

Postmortem should include:

• A brief summary
• A timeline of the event, from discovery through investigation to resolution
• The primary cause of the event
• Impact and damage assessment
• A set of action items to fix the problem immediately
• A set of action items to prevent the event from happening again
• Lessons learned

Leave Time for Learning

It's about increasing humility and being willing to learn as much as teach. Put yourself outside your comfort zone now and then.

Learn patience

Be open to influence

•   It's ok for someone else to change your mind.
•   Choose your battles carefully
•   In order to be heard properly, you first need to listen to others
•   Listening should take place before you've decided on something

Team Culture

Code reviews, TDD and the value you place on having good design docs before starting to crank out reams of code.

Mission Statement is a way to describe the product goals and non goals.
Comments should be focused on why the code is doing what it's doing, not what the code is doing.
Require code reviews for every commit. Check for style, quality and mistakes.
Have real test and release processes. Testing should be part of the coding and review process.
Communication and process reduces the barrier to entry for newcomers.
Code is ultimately about communications with people.
An engineer needs nurturing, time and space to think and create.

Bad Manager

•  Micromanagement
•  Ignoring low performers
•  Hiring pushovers : Your team won't be able to make a move without you. You can't take a vacation. You may feel secure in job. 

Strive to hire people who are smarter than you and can replace you.
See failure as an opportunity to learn and not to point fingers or assign blame.

Do a postmortem of production failures. Document the events that led to the actual failure and develop a series of steps that will prevent it from happening in the future. Focus on the code of the problem and fix it once and for all.

Be a teacher and a mentor

•  Experience with your team's processes and systems
•  The ability to explain things to someone else 
•  The ability to gauge how much help your mentee needs
•  Don't overexplain things 

Set Clear Goals

  Is there anything you need?
  You can increase intrinsic motivation by giving people three things: autonomy, mastery and purpose
  Autonomy means no micromanagement. Mastery means giving the opportunity to learn new skills and improve existing skills
Code culture should include : Consensus based development, high-quality code, code reviews and an environment where people feel comfortable to try new things and to fail fast.

Protect your team's attention and focus. Don't let someone waste team's time.
Beware of those who are incapable of accepting a consensus decision, incapable of listening to or respecting other points of view and incapable of reaching compromises.
 
Redirect the energy of perfectionists
Keep track of your accomplishments and use them in your self-assessment

Three bullets and a call to action

Don't be all things. Define the problem narrowly and solve it well. Solve common problems for most users and do it really well. Focus on the user, not what's convenient for you to code. Complex things should feel seamless and easy.

Ruby 2.2.3 Complex Basics

Ruby 2.2.3 Complex methods such as to_c, rationalize, rectangular, polar, +, -, /, *, real, imaginary and more. Click on the image below to watch the video.

Ruby 2.2.3 Bignum Basics

Ruby 2.2.3 Bignum methods such as remainder, fdiv, conversion to differnt base using to_s and bit_length. Click on the image below to watch the video.

Ruby 2.2.3 Comparable Basics

Ruby 2.2.3 Comparable methods such as <=> and between is covered in this video. Click on the image below to watch it.

Ruby 2.2.3 Binding Basics

Ruby 2.2.3 Binding basics such as binding, using binding with eval, local_variables, local_variable_set and local_variable_get. Click on the image below to watch the video.

Ruby 2.2.3 Lazy Enumerator Basics

Ruby 2.2.3 Lazy Enumerator basics. Click the image below to watch the video.

Ruby 2.2.3 Enumerator Basics : Part 4

Ruby 2.2.3 Enumerator methods such as yield, feed, next_values, peek and peek_values. Click on the image below to watch the video.

Ruby 2.2.3 Enumerator Basics : Part 3

Ruby 2.2.3 Enumerator methods such as with_object and feed. Click on the image below to watch the video.

Ruby 2.2.3 Enumerator Basics : Part 2

Ruby 2.2.3 Enumerator methods such as enum_for, to_enum and implementing Fibonacci sequence using Enumerator. Click on the image below to watch the video.

Ruby 2.2.3 Enumerator Basics : Part 1

Ruby 2.2.3 Enumerator methods such as each_with_object, next, next_values and feed. Click on the image below to watch the video.

Ruby 2.2.3 Module Basics : Part 9

Ruby 2.2.3 Module methods such as module_function, prepended, private_instance_methods, remove_method and undef_method. Click on the image below to watch the video.