From 5cb3c17cc2c0f948f60e980016a08d6f6ae4c31a Mon Sep 17 00:00:00 2001 From: Dave Junta Date: Tue, 11 Oct 2016 15:14:55 -0600 Subject: [PATCH 1/5] Update rush_hour.md --- source/projects/rush_hour.md | 6 +++--- 1 file changed, 3 insertions(+), 3 deletions(-) diff --git a/source/projects/rush_hour.md b/source/projects/rush_hour.md index a6df1b76d..7d6502bf3 100644 --- a/source/projects/rush_hour.md +++ b/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 From e6834b45f24b8f6c87540270eff9f49d16f37d00 Mon Sep 17 00:00:00 2001 From: Michael Dao Date: Fri, 14 Oct 2016 09:31:42 -0600 Subject: [PATCH 2/5] Update complete_me.markdown --- source/projects/complete_me.markdown | 52 ++++++++++++++++------------ 1 file changed, 29 insertions(+), 23 deletions(-) diff --git a/source/projects/complete_me.markdown b/source/projects/complete_me.markdown index 55f14e05b..31158a9e6 100644 --- a/source/projects/complete_me.markdown +++ b/source/projects/complete_me.markdown @@ -258,37 +258,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 From 435474ffc4cafb3a880ae68bb0e8d445171ae597 Mon Sep 17 00:00:00 2001 From: Michael Dao Date: Fri, 14 Oct 2016 09:36:09 -0600 Subject: [PATCH 3/5] Update night_writer.markdown --- source/projects/night_writer.markdown | 40 +++++++++++++-------------- 1 file changed, 20 insertions(+), 20 deletions(-) diff --git a/source/projects/night_writer.markdown b/source/projects/night_writer.markdown index 4213c8c78..e6c6afc2d 100644 --- a/source/projects/night_writer.markdown +++ b/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 From 116f89ba0ea6bddf2a436bf9d54506e4fd834bf5 Mon Sep 17 00:00:00 2001 From: Beth Sebian Date: Wed, 19 Oct 2016 00:10:50 -0500 Subject: [PATCH 4/5] Update complete_me.markdown --- source/projects/complete_me.markdown | 8 +++++--- 1 file changed, 5 insertions(+), 3 deletions(-) diff --git a/source/projects/complete_me.markdown b/source/projects/complete_me.markdown index 31158a9e6..a6c974060 100644 --- a/source/projects/complete_me.markdown +++ b/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 From 6478b84d40b898b21865ed080ae3c69d47fcd5ce Mon Sep 17 00:00:00 2001 From: LucasMarquesdaSilva Date: Sun, 23 Oct 2016 17:18:28 -0200 Subject: [PATCH 5/5] update blogger.markdown --- source/projects/blogger.markdown | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/source/projects/blogger.markdown b/source/projects/blogger.markdown index f21d2539f..e58ffe616 100644 --- a/source/projects/blogger.markdown +++ b/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>" }