Update blogger

source/projects/blogger.markdown

@@ -1949,7 +1949,7 @@ Now our articles can have an image and all the hard work was handled by papercli
 
 Yes, a model (in our case an article) could have many attachments instead of just one. To accomplish this you'd create a new model, let's call it "Attachment", where each instance of the model can have one file using the same fields we put into Article above as well as an `article_id` field. The Attachment would then `belong_to` an article, and an article would `have_many` attachments.
 
-Paperclip supports automatic image resizing and it's easy. In your model, you'd add an option like this:
+Paperclip supports automatic image resizing and it's easy. In your model, you'd add an option in `app/models/article.rb` like this:
 
 ```ruby
 has_attached_file :image, styles: { medium: "300x300>", thumb: "100x100>" }

source/projects/complete_me.markdown

@@ -136,7 +136,7 @@ completion.suggest("piz")
 completion.select("piz", "pizzeria")
 
 completion.suggest("piz")
-=> ["pizzeria", "pizza", "pizzicato"]
+=> ["pizzeria", "pizza", "pizzicato", "pizzle", "pize"]
 ```
 
 ## Spec Harness
@@ -152,6 +152,8 @@ You can structure the internals of your program however you like,
 but if the top level interface does not match, the
 spec harness will be unable to evaluate your work.
 
+Spec harness available [here](https://github.com/turingschool-examples/complete_me_spec_harness/blob/master/test/complete_me_test.rb). 
+
 ## Support Tooling
 
 Please make sure that, before your evaluation, your project has each of the following:
@@ -191,10 +193,10 @@ completion.select("pi", "pizza")
 completion.select("pi", "pizzicato")
 
 completion.suggest("piz")
-=> ["pizzeria", "pizza", "pizzicato"]
+=> ["pizzeria", "pizza", "pizzicato", "pizzle", "pize"]
 
 completion.suggest("pi")
-=> ["pizza", "pizzicato","pizzeria"]
+=> ["pizza", "pizzicato","pizzeria", "pizzle", "pize"]
 ```
 
 In this example, against the substring "piz" we choose
@@ -258,37 +260,43 @@ Can you create a graphical user interface for your code? Something that a "norma
 
 The project will be assessed with the following rubric:
 
-### 1. Functional Expectations
 
-* 4: Application fulfills all base expectations and one extension
-* 3: Application fulfills all base expectations
-* 2: Application is missing one base expectation
-* 1: Application is missing more than one base expectation
+### 1. Test-Driven Development
 
-### 2. Test-Driven Development
-
-* 4: Application is broken into components which are well tested in both isolation and integration using appropriate data
+* 4: Application is broken into components which are well tested in both isolation and integration using appropriate data, including edge cases
 * 3: Application is well tested but does not balance isolation and integration tests, using only the data necessary to test the functionality
 * 2: Application makes some use of tests, but the coverage is insufficient
-* 1: Application does not demonstrate strong use of TDD
+* 1: Application does not have significant testing.
+
+### 2. Encapsulation / Breaking Logic into Components
 
-### 3. Encapsulation / Breaking Logic into Components
+* 4: Application always breaks concepts into classes and methods which encapsulate functionality.
+* 3: Application consistently breaks concepts into classes and methods which have appropriate scope and responsibilities (SRP).
+* 2: Application makes use of some classes, but the divisions or encapsulation are unclear.
+* 1: Application makes use of just a few huge methods to control the bulk of the functionality.
 
-* 4: Application is expertly divided into logical components each with a clear, single responsibility
-* 3: Application effectively breaks logical components apart but breaks the principle of SRP
-* 2: Application shows some effort to break logic into components, but the divisions are inconsistent or unclear
-* 1: Application logic shows poor decomposition with too much logic mashed together
 
-### 4. Fundamental Ruby & Style
+### 3. Fundamental Ruby & Style
 
-* 4:  Application demonstrates excellent knowledge of Ruby syntax, style, and refactoring
-* 3:  Application shows strong effort towards organization, content, and refactoring
-* 2:  Application runs but the code has long methods, unnecessary or poorly named variables, and needs significant refactoring
+* 4:  Application demonstrates excellent knowledge of Ruby syntax, style, refactoring, and extensively uses idiomatic code.
+* 3:  Application shows some effort toward organization but still has 6 or fewer long methods (> 8 lines)  needs some refactoring, and is mostly idiomatic.
+* 2:  Application runs but the code has many long methods (>8 lines), has poorly named variables, needs significant refactoring, and is somewhat idiomatic.
 * 1:  Application generates syntax error or crashes during execution
 
-### 5. Enumerable & Collections
+### 4. Enumerable & Collections
+
+* 4: Application consistently makes use of the best-choice Enumerable methods and collections
+* 3: Application makes use of appropriate Enumerable methods and collections
+* 2: Application only uses the most basic Enumerable techniques.
+* 1: Application does not use enumerables.
+
+### 5. Functional Expectations
+
+* 4: Application fulfills all base expectations and one extension
+* 3: Application fulfills all base expectations
+* 2: Application is missing one base expectation
+* 1: Application is missing more than one base expectation
+
+
+
 
-* 4: Application consistently makes use of the best-choice Enumerable methods
-* 3: Application demonstrates comfortable use of appropriate Enumerable methods
-* 2: Application demonstrates functional knowledge of Enumerable but only uses the most basic techniques
-* 1: Application demonstrates deficiencies with Enumerable and struggles with collections

source/projects/night_writer.markdown

@@ -200,30 +200,30 @@ to submit additional examples, especially for the extensions, as pull requests.
 
 The project will be assessed with the following rubric:
 
-### 1. Overall Functionality
+### 1. Test-Driven Development
 
-* 4: Application follows the complete spec and two extensions
-* 3: Application follows the complete spec and one extension
-* 2: Application converts to Braille and back successfully
-* 1: Application only converts to Braille or from Braille
+* 4: Application is broken into components which are well tested in both isolation and integration using appropriate data, including edge cases
+* 3: Application is well tested but does not balance isolation and integration tests, using only the data necessary to test the functionality
+* 2: Application makes some use of tests, but the coverage is insufficient
+* 1: Application does not have significant testing.
 
-### 2. Fundamental Ruby & Style
+### 2. Breaking Logic into Components
 
-* 4:  Application demonstrates excellent knowledge of Ruby syntax, style, and refactoring
-* 3:  Application shows some effort toward organization but still has 6 or fewer long methods (> 8 lines) and needs some refactoring.
-* 2:  Application runs but the code has many long methods (>8 lines) and needs significant refactoring
-* 1:  Application generates syntax error or crashes during execution
+* 4: Application always breaks concepts into classes and methods which encapsulate functionality.
+* 3: Application consistently breaks concepts into classes and methods which have appropriate scope and responsibilities (SRP).
+* 2: Application makes use of some classes, but the divisions or encapsulation are unclear.
+* 1: Application makes use of just a few huge methods to control the bulk of the functionality.
 
-### 3. Test-Driven Development
+### 3. Fundamental Ruby & Style
 
-* 4: Application is broken into components which are well tested in both isolation and integration
-* 3: Application uses tests to exercise core functionality but leaves many common edge cases untested.
-* 2: Minor mutations to the implementation code, such as swaping characters, changing `<` to `<=`, placing `true` into a conditional, or deleting a line of code which break the functionality do not cause any tests to fail.
-* 1: Application does not demonstrate strong use of TDD
+* 4:  Application demonstrates excellent knowledge of Ruby syntax, style, refactoring, and extensively uses idiomatic code.
+* 3:  Application shows some effort toward organization but still has 6 or fewer long methods (> 8 lines)  needs some refactoring, and is mostly idiomatic.
+* 2:  Application runs but the code has many long methods (>8 lines), has poorly named variables, needs significant refactoring, and is somewhat idiomatic.
+* 1:  Application generates syntax error or crashes during execution
 
-### 4. Breaking Logic into Components
+### 4. Overall Functionality
 
-* 4: Application effectively breaks logical components apart with clear intent and usage
-* 3: Application has multiple components with defined responsibilities but there is some leaking of responsibilities
-* 2: Application has some logical components but divisions of responsibility are inconsistent or unclear and/or there is a "God" object taking too much responsibility
-* 1: Application logic shows poor decomposition with too much logic mashed together
+* 4: Application follows the complete spec and two extensions
+* 3: Application follows the complete spec and one extension
+* 2: Application converts to Braille and back successfully
+* 1: Application only converts to Braille or from Braille

source/projects/rush_hour.md

@@ -53,7 +53,7 @@ RushHour will simulate sending these requests using a cURL command. This is a co
 
 ### Define the Relationship with your group
 
-DTR with your group [here](https://gist.github.com/case-eee/38e212c799c563f58766128b5057858a). One group member should send link to forked gist to your anchor as soon as it's complete.
+DTR with your group [here](https://gist.github.com/case-eee/38e212c799c563f58766128b5057858a). One group member should send a link of the forked gist to your anchor as soon as it's complete.
 
 ### Clone the Project
 
@@ -349,7 +349,7 @@ Now that you have everything set up and ready to go for accepting data submitted
 
 ### Iteration 7
 
-We also have stats we generated that are specific to a Clients URLs. Let's create a view that will show our URL specific stats.
+We also have stats we generated that are specific to a Client's URLs. Let's create a view that will show our URL specific stats.
 
 The URL we will create for this will be:
 
@@ -380,7 +380,7 @@ If the url for the identifier __DOES__ exist let's display the url specific stat
 * Min Response time
 * A list of response times across all payloads listed from longest response time to shortest response time.
 * Average Response time for this URL
-* HTTP Verb(s) associated used to it this URL
+* HTTP Verb(s) associated with this URL
 * Three most popular referrers
 * Three most popular user agents