-
Notifications
You must be signed in to change notification settings - Fork 235
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Joe M - Chitter #234
base: main
Are you sure you want to change the base?
Joe M - Chitter #234
Conversation
… still 1 failing test
…rted into table. Format needs work. Not pretty
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I wasn't able to test the code locally, so haven't been able to look at everything outlined here: https://github.com/makersacademy/course/blob/main/pills/code_review_checklist.md
The code is really clear, easy to follow, and uses the MVC paradigm well.
``` | ||
As a Maker | ||
So that I can see what people are doing | ||
I want to see all the messages (peeps) | ||
in a browser | ||
``` | ||
|
||
|
||
![alt text](story1diagram.png "See all messages diagram") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I really like the diagrams, they're super helpful for visualising the data flow in your program
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree! It's always a good idea to diagram things out.
One thing I would note is that in these diagrams you've included both app.rb
and peeps.rb
under the Controller and under model you have the database itself.
That's not quite how the MVC model is meant to be understood. The database isn't really a part of the MVC model, the MVC model only covers the code you write:
- The Model part refers to the code you write that interacts with the database (peeps.rb) and that provides a way to represent the data once you've retrieved it from the database (one instance of the
Peep
class represents a single row of the DB) - As your diagram already suggests, the Controller part refers to the code you write that sets up routes and is the link between your View and your Model. It's just that in your codebase, this means that the Controller is really only the code in the
app.rb
file (in more complex codebases it could cover more files, but there's no need to worry about that at this point in the course!)
message = params['message'] | ||
p params['message'] | ||
time = Time.now.httpdate | ||
connection = PG.connect(dbname: 'chitter') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One next step here would be to refactor this code into your Peeps class, similar to this step from the Bookmark Manager challenge: https://github.com/makersacademy/course/blob/main/apprenticeships_bookmark_manager/walkthroughs/10.md#refactoring
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be a good next step. It would allow you to test this code in a unit test just like you tested the Peep.all
method in peeps_spec.rb
.
It would also make the separation between Controller and Model that I talked about above clearer.
|
||
result = connection.exec('SELECT message, posted FROM peeps') | ||
# binding.irb | ||
result.map { |peep| peep } |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part of the Bookmark Manager walkthrough outlines wrapping the database data in an instance of the class: https://github.com/makersacademy/course/blob/main/apprenticeships_bookmark_manager/walkthroughs/11.md#wrapping-returned-data
<% end %> | ||
</ul> | ||
|
||
<img src='/chitter.png' /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The logo is a really nice addition!
@@ -34,18 +34,25 @@ You should see 1 passing test. | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I found this framework really helpful when writing my README: https://github.com/makersacademy/course/blob/main/pills/readmes.md
@@ -1 +1 @@ | |||
CREATE TABLE peeps(id SERIAL PRIMARY KEY, message VARCHAR(60)); | |||
CREATE TABLE peeps(id SERIAL PRIMARY KEY, message VARCHAR(60), posted VARCHAR(60)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm not sure I 100% follow their reasoning, but Makers advise adding updates to the database table as a separate migration file: https://github.com/makersacademy/course/blob/main/apprenticeships_bookmark_manager/walkthroughs/11.md#updating-the-bookmarks-table
Also, depending on how you record the date / time, you could use a different SQL data type for the posted column: https://www.w3schools.com/sql/sql_datatypes.asp
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some good links there @olliefreeman94
The reason for a separate migration file is that in a real system, you would want to be able to run the migration separately from the initial creation of the table, as a DB will typically throw an error if you try to create a table that doesn't exist. If all the migrations are in the same file, they will never run because the error will happen before we even get to them.
@@ -0,0 +1,7 @@ | |||
<ul> | |||
<% @peeps.each do |peep| peep['message'] %> | |||
<li><%= peep %></li> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This part of the Bookmark Manager walkthrough outlines updating the view to show different properties of the Peeps object: https://github.com/makersacademy/course/blob/main/apprenticeships_bookmark_manager/walkthroughs/11.md#showing-title-in-the-bookmarks-view
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hey Joe,
Well done on completing the first two user stories. The diagrams were a great addition. I left a few more detailed comments below. I would suggest using this week where you'e building another database app to revisit some of the ideas of Database week, namely:
- the difference between Model and Controller
- how we can update existing tables in a database using migrations
Using Makersbnb as a way to revisit these topics would be a great use of this week. Makersbnb is intentionally an app quite similar to the one's you've built so far so that you can consolidate your learning from the previous weeks. The only new thing is the teamwork aspect.
If you have questions about anything I commented on, feel free to ask me here in the comments or on Slack!
Simo
``` | ||
As a Maker | ||
So that I can see what people are doing | ||
I want to see all the messages (peeps) | ||
in a browser | ||
``` | ||
|
||
|
||
![alt text](story1diagram.png "See all messages diagram") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I agree! It's always a good idea to diagram things out.
One thing I would note is that in these diagrams you've included both app.rb
and peeps.rb
under the Controller and under model you have the database itself.
That's not quite how the MVC model is meant to be understood. The database isn't really a part of the MVC model, the MVC model only covers the code you write:
- The Model part refers to the code you write that interacts with the database (peeps.rb) and that provides a way to represent the data once you've retrieved it from the database (one instance of the
Peep
class represents a single row of the DB) - As your diagram already suggests, the Controller part refers to the code you write that sets up routes and is the link between your View and your Model. It's just that in your codebase, this means that the Controller is really only the code in the
app.rb
file (in more complex codebases it could cover more files, but there's no need to worry about that at this point in the course!)
get '/test' do | ||
'Test page' | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's always a good idea to remove test code from code you submit for code review (anywhere, not just at Makers). It keeps everything nice and clean :)
message = params['message'] | ||
p params['message'] | ||
time = Time.now.httpdate | ||
connection = PG.connect(dbname: 'chitter') |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, that would be a good next step. It would allow you to test this code in a unit test just like you tested the Peep.all
method in peeps_spec.rb
.
It would also make the separation between Controller and Model that I talked about above clearer.
click_button('post your peep') | ||
|
||
expect(page).to have_content 'hey peeps. just a peep to say I am posting a new peep. so peep this!' | ||
end |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good feature test!
connection.exec("INSERT INTO peeps VALUES(3, 'testing chitter.');") | ||
|
||
visit('/') | ||
expect(page).to have_content "Just completed SQL Zoo. It was fun to do!" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
💥
@@ -1 +1 @@ | |||
CREATE TABLE peeps(id SERIAL PRIMARY KEY, message VARCHAR(60)); | |||
CREATE TABLE peeps(id SERIAL PRIMARY KEY, message VARCHAR(60), posted VARCHAR(60)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some good links there @olliefreeman94
The reason for a separate migration file is that in a real system, you would want to be able to run the migration separately from the initial creation of the table, as a DB will typically throw an error if you try to create a table that doesn't exist. If all the migrations are in the same file, they will never run because the error will happen before we even get to them.
@@ -1 +1 @@ | |||
CREATE TABLE peeps(id SERIAL PRIMARY KEY, message VARCHAR(60)); | |||
CREATE TABLE peeps(id SERIAL PRIMARY KEY, message VARCHAR(60), posted VARCHAR(60)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
When we want to add a field to a new table, we typically want to use an ALTER TABLE
statement rather than create a brand new table. Think about what would happen -- all of the existing peeps would no longer be visible on the site because the new table doesn't contain them. The link @olliefreeman94 sent above has a good example of that.
|
||
expect(peeps).to include "Just completed SQL Zoo. It was fun to do!" | ||
expect(peeps).to include "Testing adding chitter messages" | ||
expect(peeps).to include "testing chitter." |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nice and thorough!
Even more thorough: checking that peeps
has the right length -- what if some duplicate messages had crept in somehow?
Joe Musarurwa
User stories
Please list which user stories you've implemented (delete the ones that don't apply).
README checklist
Does your README contains instructions for
Here is a pill that can help you write a great README!