norton-design / flash_forward Goto Github PK

Before tomorrow, I highly recommend that you take a few minutes to set up an empty Rails app skeleton for your clone. This way, I can double check your work tomorrow morning and you'll be able to hit the ground running with developing your app after the assessment.

Below are some instructions for doing this. The setup requires some specific configuration (using Rails version 5, using Postgres as the databse, and disabling turbolinks), so read through the entire instructions first to make sure you understand everything before running the setup commands.

Let me know if you run into issues or have questions.

Setting up an empty Rails app skeleton and pushing to Github:

1. Create new Rails project (remember this cannot be nested inside of a directory that is a git repo):
   • rails _5.2.3_ new <placeholderForYourAppName> --database=postgresql --skip-turbolinks
     • remember to replace the <placeholderForYourAppName> with your actual clone's name (don't include the angle brackets!)
   • The above command ensures the following things, which are very important:
     • your Rails project will use version 5.2.3 (we definitely don't want a Rails 6 app)
     • Postgres will be used as the database (the default is sqlite3, which is too lightweight for your production app)
     • Turbolinks will be disabled for your project (Turbolinks won't play nice with your JS code and may cause weird bugs)
2. cd into the newly created Rails project directory
3. Run commands to follow the usual workflow for adding and commiting to your local repo.
   • Make sure to do this from the top level of your Rails project directory!
4. Add your remote repo.
   • Also do this from the the top level of your Rails project directory
   • Your github repo should have setup instructions for "pushing an existing repository from the command line". You can copy the first command in that section, paste it into your terminal, and run it.
   • The command should look like this: git remote add origin <placeholderForYourAppRemoteRepoGitUrl>
     • if you don't see the setup instructions, you can type this command manually, making sure to replace the <placeholderForYourAppRemoteRepoUrl> with your actual remote repo's git url.
     • remember that you can copy your remote repo's git url by navigating to your project repositiory page on github, clicking on the green "Clone or download" button (which is just above the listing of your projet directories), and clicking on the clipboard icon to the right of the url that appears in the dropdown menu.
5. Push to your remote repo: git push -u origin master

Hey Michael, thanks for the hard work you put into your docs - I'm excited to see this project take shape! I have some initial feedback below, which we can discuss in person today.

MVP list:

• Move production README to the end (lay out your MVPs in the order you intend to tackle them)
• Flesh out the user authentication (signup, login, demo) MVP with specific bullet points. Which parts of the site (if any) will users be allowed to see w/o being logged in?
• Climbing Directory MVP: I would frame this MVP in terms of the resource that it deals with (a Route) and the CRUD operations (create, read, update, destroy) that can be performed on it. It seems the Climbing Directory refers specifically to the functionality of Reading a Route (an index of routes).
• You should plan to spend 10 days for this initial sprint of your fullstack project. That leaves you 1 additional day to work with, which I recommend allocating to Photos (giving you time to work out any kinks with AWS S3)

Database Schema:

1. Users
   • Separate name into first_name and last_name columns (these fields are part of the signup process)
   • Set up a default value for your boolean mod column. Example: default: false
     • For more explanation, check out this resource on avoiding the three state boolean problem
2. Routes
   • Am I right in understanding that a route could have multiple moderators? If so, we shouldn't have a mod_id column and instead should use a joins table (route_moderators)
   • It does seem like a route has a "shared_by" attribute, so some sort of shared_by_id or author_id would be useful
   • On Mountain Project, it looks like there isn't really a separation between state and region. They're really just two types of areas. And it seems like areas can be nested under other areas. We should model areas as a separate resource, so it needs its own table. Then you can reference a route's area through an area_id.
   • I recommend changing type to something more descriptive (like route_type). “Type” is a keyword in SQL (albeit a non-reserved one), and it’s best to avoid any confusion with that keyword.
3. Photos
   • Remove the user_id column. We can know a photo's user through its route.
   • Actually, now that I think about it, a photo can belong to a user or a route, right? If that's so, we should make photos :polymorphic, similar to what you propose for comments. Another option is to just focus on photos for Routes for this feature.
   • Note: you’ll be store your photos in a cloud service (AWS S3) and managing references to those files via Active Storage, so you don't need to migrate the table in the usual manner. (I'll send a resource this weekend)
4. Ratings
   • Should this be polymorphic too? Users can rate Routes and they can rate individual Photos. But I'm ok with simplifying to just Routes if you don't plan to make photos rateable
5. Areas (or Locations)
   • Add this table with the columns you think you'll need. Areas seem to be nested in a hierarchy, so how can we model that with this table?

Sample State:

1. General
   • Remember to make the keys camelCase! (You'll be interfacing with the frontend state through your JS code, so use JS naming conventions.)
   • Update sample state to reflect any modifications to the schema (based on feedback)
2. Routes
   • Each route should have a key of commentIds pointing to an array of ids
   • What are some other pieces of route information that you'll need on the frontend but that aren't in the routes table itself?
     • One that comes to mind is the rating info.
       • You could add a key of ratingIds pointing to an array of ratingIds. (So you can calculate the avg rating on the frontend and also display the ratings breakdown, if that's what you're aiming to do.)
       • Alternatively, you could calculate the average in the backend (with your Route model) and send just the avg up in your jbuilder template.

Great job, Michael! A few points of feedback to address after you get to a good place with your areas/routes feature (no need to drop what you're currently working on):

Rendering & clearing errors

• Need an "x" button to close the red banner at the top (clearErrors). Also add an error icon (like a triangle w/ exclamation point in it) - could use Font Awesome. Finally, the text should be left-aligned instead of centered.
• Errors still persist on the page when switching from one form to the other (both through the nav links and through the browser's back button). To fix this, dispatch a clearSessionErrors action in componentWillUnmount.
• Make the email inputs type=email instead of type=text. This will provide built-in email validations in the way that Mountain Project has them (a tooltip that tells you what's wrong).

Styling

• Add cursor: pointer to all buttons (login, signup, demo, close modal buttons)
• The images aren't visible on Heroku, which suggests an issue with asset pipeline. To fix this, check out part 4 of the Setup instructions in the "Deploying to Heroku" guide. The relevant section is called "Migrate static assets to the Asset Pipeline" and has info about how to add the image to the window in your application.html.erb, how to source it in your React components, and how to style it as a background image in your .scss files.