Homework for 7A

Review

Topics Covered: Databases and tables; Rails models; ActiveRecord; working with Rails models in rails console.


Exercises

E1: ActiveReview

Again, we went over a lot of methods! Make sure you understand what each one returns, and whether they are a class or instance method. Look them up if you forgot—thankfully, Rails has really good documentation with APIDock.

What's the difference between .find and .find_by?
What's the difference between .where and .find_by?

E2: ActiveQuiz

  1. What is a database?
  2. What is a database table? How does it relate to a database? What's a good analogy for a database table (i.e. a way to visualize it)?
  3. Draw the tweets database table
  4. Why do we use models/resources at all?
  5. What is ActiveRecord?
  6. What's the difference between a database table, resource and an ActiveRecord model?

E3: Purrgrammatic Creation

Fire up rails console from within your 'meowbook' rails app folder from yesterday. Then do the following things:

Purrin' won't stop

A bit harder now:

E5 (Bonus!): Likey Likey

How would you find all Posts that have the word "awesome" in them? How would you find all Posts that have words like "awesome" in them (like meaning "awesum" or "awesick", not synonyms like "cool" or "great")?


Projects

The Real Deal

Now that you have some features, you want to come up with user stories, or typical workflows for all the types of actions. For our Twitter app, there are several that come to mind: A new user signing up, signing in, someone posting something, someone browsing tweets, following another user, etc.

...continuing from your previous document...

## User Stories

#### Sign up

1. User visits site
2. User clicks "Sign up"
3. User fills in name, email, password
4. User clicks "Submit"
  - If all is ok:
    - User is directed to home page
  - If email is invalid
    - User is shown an error message
  - If password is too short
    - User is shown an error message

#### Sign in

1. User visits site
2. User clicks "Sign in"
3. User fills in email and password
4. User clicks "Submit"
  - If email and password match
    - User is directed to main page
  - Otherwise
    - User is shown error message

#### Create a tweet

...

#### Follow a person

...

#### Search for a person

...

#### Search for tweets

...

It might seem extremely verbose, but this a way of pseudo-coding applications: just like writing small programs, large apps need a lot of planning, too. This allows you to foresee a lot of problems that you may not have thought about. How exactly do I do a search? How do I render the results? And questions like that.

Tomorrow, you'll present your idea, features and stories in front of the whole class, and the class will give you back feedback on problems they see. Put yourself in their shoes and think "If I were a user of my app, what would I improve?". It's much better to decide that your idea should be changed/improved/scrapped now, after only hours of work, instead of after days or even weeks of work. Need some inspiration? Check out the App App.

Mockups

Since you guys have learned relatively more of HTML/CSS, you may want to start mocking up your interface. For each user story, you're going to want a screen for the user to perform those actions. Some designers like to draw on paper—you might go that route. Some like to sketch things in Photoshop or Illustrator, and if you have that software and are comfortable using it, then do that. But most coders are not superb drawers, so they like an online interface. We'd recommend Balsamiq or Mockingbird.