done

ruby-lecture-reading-error-messages-001/.learn

@@ -0,0 +1,9 @@
+tags:
+  - introduction
+  - error messages
+  - lecture
+languages:
+  - ruby
+type:
+  - video
+  - lab

ruby-lecture-reading-error-messages-001/.rspec

@@ -0,0 +1,3 @@
+--color
+--require spec_helper
+--format documentation

ruby-lecture-reading-error-messages-001/CONTRIBUTING.md

@@ -0,0 +1,37 @@
+# Contributing to Learn.co Curriculum
+
+We're really exited that you're about to contribute to the [open curriculum](https://learn.co/content-license) on [Learn.co](https://learn.co). If this is your first time contributing, please continue reading to learn how to make the most meaningful and useful impact possible.
+
+## Raising an Issue to Encourage a Contribution
+
+If you notice a problem with the curriculum that you believe needs improvement
+but you're unable to make the change yourself, you should raise a Github issue
+containing a clear description of the problem. Include relevant snippets of
+the content and/or screenshots if applicable. Curriculum owners regularly review
+issue lists and your issue will be prioritized and addressed as appropriate.
+
+## Submitting a Pull Request to Suggest an Improvement
+
+If you see an opportunity for improvement and can make the change yourself go
+ahead and use a typical git workflow to make it happen:
+
+* Fork this curriculum repository
+* Make the change on your fork, with descriptive commits in the standard format
+* Open a Pull Request against this repo
+
+A curriculum owner will review your change and approve or comment on it in due
+course.
+
+# Why Contribute?
+
+Curriculum on Learn is publicly and freely available under Learn's
+[Educational Content License](https://learn.co/content-license). By
+embracing an open-source contribution model, our goal is for the curriculum
+on Learn to become, in time, the best educational content the world has
+ever seen.
+
+We need help from the community of Learners to maintain and improve the
+educational content. Everything from fixing typos, to correcting
+out-dated information, to improving exposition, to adding better examples,
+to fixing tests—all contributions to making the curriculum more effective are
+welcome.

ruby-lecture-reading-error-messages-001/LICENSE.md

@@ -0,0 +1,7 @@
+#Learn.co Educational Content License
+
+Copyright (c) 2015 Flatiron School, Inc
+
+The Flatiron School, Inc. owns this Educational Content. However, the Flatiron School supports the development and availability of educational materials in the public domain. Therefore, the Flatiron School grants Users of the Flatiron Educational Content set forth in this repository certain rights to reuse, build upon and share such Educational Content subject to the terms of the Educational Content License set forth [here](http://learn.co/content-license) (http://learn.co/content-license). You must read carefully the terms and conditions contained in the Educational Content License as such terms govern access to and use of the Educational Content.  
+
+Flatiron School is willing to allow you access to and use of the Educational Content only on the condition that you accept all of the terms and conditions contained in the Educational Content License set forth [here](http://learn.co/content-license) (http://learn.co/content-license).  By accessing and/or using the Educational Content, you are agreeing to all of the terms and conditions contained in the Educational Content License.  If you do not agree to any or all of the terms of the Educational Content License, you are prohibited from accessing, reviewing or using in any way the Educational Content.

ruby-lecture-reading-error-messages-001/README.md

@@ -0,0 +1,125 @@
+# Intro to Reading Ruby Error Messages
+
+## Overview
+
+In this lab, you'll be reading error messages from tests. This lab is designed so that both running the files *and* running the test suite via the `learn` command will show the error messages for you to decode. Moving forward though, you'll be reading error messages mainly through running the test suite. 
+
+## Objectives
+
+1. Read the three different parts of an errors message.
+2. Identify four error types- name errors, syntax errors, types errors, and division errors- and fix them
+3. Describe a test suite, where it's found in a lab, and its purpose
+3. Use the `learn` command in terminal to run the tests for a lab.
+
+## Video 
+
+[MP4](http://flatiron-videos.s3.amazonaws.com/ironboard/ruby/ruby-lecture-reading-error-messages/ruby-lecture-reading-error-messages.mp4)
+
+<video controls width="100%">
+  <source src="http://flatiron-videos.s3.amazonaws.com/ironboard/ruby/ruby-lecture-reading-error-messages/ruby-lecture-reading-error-messages.mp4" type="video/mp4" >
+    This video is best enjoyed on Learn.co.
+</video>
+
+## Reading Error Messages 
+
+Error messages have 3 parts:
+
+```
+lib/a_name_error.rb:3:in `<main>': undefined local variable or method `hello_world' for main:Object (NameError)
+```
+
+1) The location of the error, the "where".
+
+```
+lib/a_name_error.rb:3:in `<main>':
+```
+
+* `lib/a_name_error.rb` is the file the error occurred in.
+* `3` is the line of code the error.
+* `<main>` is the scope of the error.
+
+2) The description, the "why".
+
+```
+undefined local variable or method `hello_world' for main:Object
+```
+
+The interpreter does the best job it can to tell you what it thinks went wrong.
+
+3) The type of error, the "who".
+
+```
+(NameError)
+```
+
+This is a [Ruby Error Type](http://www.ruby-doc.org/core-2.2.0/Exception.html)
+
+You've solved games of *Clue* with less information. This is my favorite part of programming, debugging, fixing errors. It's like you're a detective solving a crime. The only bad thing is that more often than not, you're also the criminal that caused the error in the first place.
+
+Errors are clues, reading them is the interpreter telling you what to do to fix the program and move on.
+
+## Four Common Error Types
+
+### Name Errors
+NameErrors are caused when a given name is invalid or undefined. Whenever the Ruby interpreter encounters a word it doesn't recognize, it assumes that word is the name of a variable or a method. If that word was never defined as either a variable or a method, it will result in a name error.
+
+### Syntax Errors
+Syntax errors are pretty self explanatory: they're the result of incorrect syntax. Thankfully, they're usually followed by a guess about the location of the error. For instance:
+
+```ruby
+2.times do
+  puts "hi"
+```
+
+Will result in:
+```text
+2: syntax error, unexpected end-of-input, expecting keyword_end
+```
+Here, Ruby is saying that on line 2, there is a missing `end` (every `do` keyword must be followed by some code and then an `end` keyword). Always read the full details of syntax errors and look for line numbers, which usually appear at the beginning of the error message.
+
+### TypeErrors
+
+When you try and do a mathematical operation on two objects of a different type, you will receive a TypeError.  For example if you try and add a string to an integer, Ruby will complain.
+
+```ruby
+1 + "1"
+```
+Will produce the following error:
+
+```
+TypeError: String can't be coerced into Fixnum
+```
+
+### DivisionErrors
+DivisionErrors are caused when a given number is divided by 0.
+
+## What is a Test Suite?
+
+The tests for each lab will be found inside the `spec` directory of that lab. Tests are programs, written using the Rspec testing library, that are written to make sure your program is running properly. Generally, tests will call on the methods you define in your programs and check to see if they are working the way they are expected to. 
+
+In the future, you will learn how to read tests more thoroughly and even how to write your own tests. For now, all you need to understand is that the code in the `spec` directory is there to test the code in your program. When you run the `learn` or the `rspec` command in your terminal in the directory of the lab you are working on, the runs the code in your `spec` file and tests your program. The output that appears in your terminal is the result of running those tests. If you pass a test, the output will generally appear green, otherwise, it will appear red and be accompanied by the types of error messages that we're discussing in this Readme. Paying attention to those error messages will help you to pass the test. 
+
+
+## Instructions
+
+STOP. If you haven't watched the above video, you are making life much harder for yourself! Watch the video lecture above before attempting this lab : ) 
+
+Did you watch it? Okay, great. Let's proceed.  
+
+1. Fork and clone this lab down onto your computer. 
+
+2. Run each of the files in the `lib` directory using the `ruby` command.
+
+  * From the directory you cloned this lab, try: `ruby lib/a_division_by_zero_error.rb` to run that program. You should get output about an error in the program. Read the error message and open that file in Sublime and see if you can fix the error. When the error is fixed and you run the file via `ruby`, you'll simply see no output at all, no errors or anything. Confirm this by running the `learn` command and seeing that you have a passing test and 3 remaining failures.
+
+  * Run each file via `ruby lib/<file name>`, fix the errors, and confirm with `learn` until you're done and all the tests pass. Pay attention to the filenames in `lib` if you need hints for what kind of error to look for.
+
+3. Once your code is passing with the `learn` command, in your command line run:
+
+  * `git status`, to see all of the files you changed
+  * `git add .`, to stage your changes
+  * `git commit`
+  * `git push` to push your changes up to your fork of this lab
+  * Open a pull request, across forks, between your master branch and the master branch of the repo from which you forked it. 
+
+Feel proud, being able to read an error message and fix it, no matter how basic, is a huge step in being a programmer. Get comfortable with broken code, it's totally normal in programming.

ruby-lecture-reading-error-messages-001/lib/a_division_by_zero_error.rb

@@ -0,0 +1,3 @@
+42 / 6
+
+42 / 2

ruby-lecture-reading-error-messages-001/lib/a_name_error.rb

@@ -0,0 +1,3 @@
+"hello world"
+
+hello_world

ruby-lecture-reading-error-messages-001/lib/a_syntax_error.rb

@@ -0,0 +1,3 @@
+x = 1
+
+x = 

ruby-lecture-reading-error-messages-001/lib/a_type_error.rb

@@ -0,0 +1,3 @@
+1 + 1
+
+1 + "is the loneliest number"

ruby-lecture-reading-error-messages-001/spec/no_ruby_errors_spec.rb

@@ -0,0 +1,34 @@
+describe "Not having any errors and being all green" do
+
+  context 'NameError' do
+    it 'raises a NameError when encountering undefined barewords' do
+      expect{
+        load './lib/a_name_error.rb'
+      }.to_not raise_error
+    end
+  end
+
+  context 'SyntaxError' do
+    it 'raises a SyntaxError for nonsensical code' do
+      expect{
+        load './lib/a_syntax_error.rb'
+      }.to_not raise_error
+    end
+  end
+
+  context 'TypeError' do
+    it 'raises a TypeError for objects of the wrong type' do
+      expect{
+        load './lib/a_type_error.rb'
+      }.to_not raise_error
+    end
+  end
+
+  context 'ZeroDivisionError' do
+    it 'raises a ZeroDivisionError for dividing by zero' do
+      expect{
+        load './lib/a_division_by_zero_error.rb'
+      }.to_not raise_error
+    end
+  end
+end

ruby-lecture-reading-error-messages-001/spec/spec_helper.rb

@@ -0,0 +1,89 @@
+# This file was generated by the `rspec --init` command. Conventionally, all
+# specs live under a `spec` directory, which RSpec adds to the `$LOAD_PATH`.
+# The generated `.rspec` file contains `--require spec_helper` which will cause this
+# file to always be loaded, without a need to explicitly require it in any files.
+#
+# Given that it is always loaded, you are encouraged to keep this file as
+# light-weight as possible. Requiring heavyweight dependencies from this file
+# will add to the boot time of your test suite on EVERY test run, even for an
+# individual file that may not need all of that loaded. Instead, consider making
+# a separate helper file that requires the additional dependencies and performs
+# the additional setup, and require it from the spec files that actually need it.
+#
+# The `.rspec` file also contains a few flags that are not defaults but that
+# users commonly want.
+#
+# See http://rubydoc.info/gems/rspec-core/RSpec/Core/Configuration
+RSpec.configure do |config|
+  # rspec-expectations config goes here. You can use an alternate
+  # assertion/expectation library such as wrong or the stdlib/minitest
+  # assertions if you prefer.
+  config.expect_with :rspec do |expectations|
+    # This option will default to `true` in RSpec 4. It makes the `description`
+    # and `failure_message` of custom matchers include text for helper methods
+    # defined using `chain`, e.g.:
+    # be_bigger_than(2).and_smaller_than(4).description
+    #   # => "be bigger than 2 and smaller than 4"
+    # ...rather than:
+    #   # => "be bigger than 2"
+    expectations.include_chain_clauses_in_custom_matcher_descriptions = true
+  end
+
+  # rspec-mocks config goes here. You can use an alternate test double
+  # library (such as bogus or mocha) by changing the `mock_with` option here.
+  config.mock_with :rspec do |mocks|
+    # Prevents you from mocking or stubbing a method that does not exist on
+    # a real object. This is generally recommended, and will default to
+    # `true` in RSpec 4.
+    mocks.verify_partial_doubles = true
+  end
+
+# The settings below are suggested to provide a good initial experience
+# with RSpec, but feel free to customize to your heart's content.
+=begin
+  # These two settings work together to allow you to limit a spec run
+  # to individual examples or groups you care about by tagging them with
+  # `:focus` metadata. When nothing is tagged with `:focus`, all examples
+  # get run.
+  config.filter_run :focus
+  config.run_all_when_everything_filtered = true
+
+  # Limits the available syntax to the non-monkey patched syntax that is recommended.
+  # For more details, see:
+  #   - http://myronmars.to/n/dev-blog/2012/06/rspecs-new-expectation-syntax
+  #   - http://teaisaweso.me/blog/2013/05/27/rspecs-new-message-expectation-syntax/
+  #   - http://myronmars.to/n/dev-blog/2014/05/notable-changes-in-rspec-3#new__config_option_to_disable_rspeccore_monkey_patching
+  config.disable_monkey_patching!
+
+  # This setting enables warnings. It's recommended, but in some cases may
+  # be too noisy due to issues in dependencies.
+  config.warnings = true
+
+  # Many RSpec users commonly either run the entire suite or an individual
+  # file, and it's useful to allow more verbose output when running an
+  # individual spec file.
+  if config.files_to_run.one?
+    # Use the documentation formatter for detailed output,
+    # unless a formatter has already been configured
+    # (e.g. via a command-line flag).
+    config.default_formatter = 'doc'
+  end
+
+  # Print the 10 slowest examples and example groups at the
+  # end of the spec run, to help surface which specs are running
+  # particularly slow.
+  config.profile_examples = 10
+
+  # Run specs in random order to surface order dependencies. If you find an
+  # order dependency and want to debug it, you can fix the order by providing
+  # the seed, which is printed after each run.
+  #     --seed 1234
+  config.order = :random
+
+  # Seed global randomization in this process using the `--seed` CLI option.
+  # Setting this allows you to use `--seed` to deterministically reproduce
+  # test failures related to randomization by passing the same `--seed` value
+  # as the one that triggered the failure.
+  Kernel.srand config.seed
+=end
+end