Recommended
More Related Content
What's hot
What's hot (20)
Viewers also liked
Similar to RoR: What is it Good For?: Absolutely Something
Similar to RoR: What is it Good For?: Absolutely Something (20)
Recently uploaded
Recently uploaded (20)
RoR: What is it Good For?: Absolutely Something
- 2. RoR: What is it Good For? Absolutely Something
- 3. Ruby vs. Rails Ruby Rails
- 4. Is it the Only Game in Town?
- 5. Is it the Only Game in Town?
- 6. If Rails is the Creature ▪ David Heinemeier Hansson (DHH) ▪ Drives racecars ▪ Created Rails for speed, self- reliance, and programmer happiness ▪ "If we don't have toys, we're just adults."
- 8. MVC Architecture Architecture (n): the action or process of building; construction
- 9. What Does MVC Stand For Anyway? M V C
- 10. What Does MVC Stand For Anyway? Model V C
- 11. What Does MVC Stand For Anyway? Model View C
- 12. What Does MVC Stand For Anyway? Model View Controller
- 13. View
- 14. View
- 16. View ▪ What a user sees ▪ .ERB (embedded ruby) files as default – Mixes Ruby syntax with HTML syntax in .html.erb files
- 17. But Wait, There’s More ▪ Rails provides a number of helpful additions to your views – Form helpers – URL helpers ▪ Partials – Templates that let you use the same view section multiple places – Especially useful for forms ▪ _form.html.erb
- 20. Controller ▪ Where the action’s at ▪ Receives requests for the application ▪ Determines what information the view should display ▪ Sends commands to the model to change/update any data ▪ Ruby (.rb) file
- 24. Model ▪ Determines how data is stored and structured ▪ Less about the action, more about the inherent nature or state of the information ▪ Ruby (.rb) file
- 26. All About That (Data)base
- 27. Database Migrations ▪ Ruby classes that are designed to make it simple to create and modify database tables ▪ automatically generated when you generate a model – Can be generated separately ▪ create the database tables when run
- 30. Relationships ▪ Declared in the models ▪ One to one – Users and social media profiles ▪ A user only has_one Facebook profile, and that profile only belongs_to that user ▪ One to many – Users and orders ▪ A user has_many orders, and each order only belongs_to that user ▪ Many to many – Writing prompts and categories ▪ Categories can contain many prompts, and those prompts can belong to many categories – Join table prompt_categories – A prompt has_many :prompt_categories has_many :categories, through: :prompt_categories – A prompt category belongs_to prompts AND categories
- 42. Gems ▪ Ruby recap: – Gems are packaged bits of code other people have written ▪ Rails is a gem! ▪ People frequently use gems to: – Handle user authentication – Write tests for their code – Separate data chunks into pages – Create fake data ▪ Gems go in yourGemfile
- 43. Who Uses Rails?
- 47. Is Rails Good for Everything?
- 48. Is Rails Good for Everything?
- 50. Katherine McClintic Web Developer.Teacher. Musician. Fencer. Person who likes to take things apart and usually puts them back together in working order-er. @scarletalphabet Rails Lead forWomenWho Code DC meetup
Editor's Notes
- Welcome. I hope you all have enjoyed what you’ve seen and done so far. This talk will give you a taste of some of the topics you’ll see in the tutorial later. There will be plenty of coaches around to help answer questions, and these slides will go up online somewhere, so don’t worry if it seems a little overwhelming at first. Without further ado, Ruby on Rails, RoR, Rails, Ruby/Rails, whatever you want to call it:
- You’ve now heard a bit about Ruby. So if what I’m talking to you about is Ruby on Rails, what’s the difference? I like to think of Ruby as the raw ingredients. The flour, the sugar, the fat, and so on. You can make a great cake from scratch. But that takes a lot of time and you risk the possibility of not getting the mix exactly right. That’s where Rails comes in. Rails is a framework for Ruby, so in this analogy it’s sort of the boxed cake mix. It’s still got flour and sugar and so on inside it, but it’s packaged up to be quick easy to use. You can customize it for your own needs, but you don’t have to in order to get a great cake out of it.
- With that said, is Rails the only Ruby framework? The only boxed cake mix around?
- No, but, and let’s ignore the second one for a moment, it might as well be. It’s so popular compared to the next most popular one that few major companies use anything else. When trying to think of a well known company or organization that does Ruby on another framework, the only one I could come up with is the NSA, for reasons I can theorize later if you’re curious.
- So if Rails is the creation, if it’s the creature, who is Dr. Frankenstein? Well, it’s this guy. DHH as he’s known. He looks less like a member of a European boyband now, but this is still the picture of him that most places use, including his own website. Obligatory information: he drives racecars. The reason why Rails is so popular with startups is that it was created to enable small teams or individuals to build with speed, and to enjoy it. A lot like Matz’s goal with Ruby.
- We’re going to move to looking at different parts of the Rails skeleton. You don’t need to worry about all or even most of this, this is just to give you an idea of what an app might look like.
- Rails is built using an MVC architecture. That may sound intimidating or ominous, but architecture is the same here as it is with buildings. It’s literally the action or process of building—construction. MVC architecture is how you build a Rails app.
- First we’re going to take a look at the part that might be most familiar to those of you who’ve done any coding before: the view.
- A view is what the user sees in the browser. In Rails you’ll use .erb files by default. This is great because it lets you mix Ruby syntax with your html. Say you have an event app, and you’ve got a Ruby variable set to a collection of upcoming events. In your view you can go through these events and make a list with each event’s name serving as a link to the event.
- Like we saw in the last slide, Rails provides some helpful additions for your views, particularly form helpers and url helpers. The url helpers are what let you let the program handle creating a list of links to events instead of writing out each and every link on your own. It translates it into the appropriate html for the browser. This is especially great for when information changes, like a new event is added, so you don’t have to go in a physically add the link yourself. Partials are also helpful for views. They’re basically templates that let you use the same view section in multiple places. Say you’ve got a form to create a new event, where you add the location, the date, the time, and such information. Well that’s pretty much the same thing as an ‘edit my event information’ form, right? So Rails lets you create a partial where you can refer to this form without copy and pasting the whole form wherever you need it.
- We’re going to move from the views
- To the controllers.
- A controller receives requests for certain application actions. This includes determining what information the view should display (creating a new user? Great, let’s show that user’s name with a welcome message once they’ve submitted the form), as well as interacting with the model to change or update any data. You’ve asked the application to create a new user? Great, it meets all requirements so it goes in the database.
- So this is the user controller for the event app. The new action is what will connect the new user form in the view with the user model. The create action is what posts the information to the database and then, if it’s saved correctly, sends you to a different page.
- So we were on controllers but we still need to talk about one aspect of MVC.
- Models. We’ve mentioned them a bit so far.
- There’s a couple of things to notice here. 1) database relationships (how tables of information relate to each other) are declared in the models. In this case how a user has many events that they’ve created or could potentially create. 2) Aside from validations like those that force you to have a long and complicated password, there’s nothing here that talks about what user information we’re storing in the database. That’s because Rails follows its usual pattern of assuming you’re following conventions and maps model information from the matching migration.
- Which means we need to talk about databases.
- Let’s start with database migrations. In Rails they’re just Ruby classes. You can generate them separately from models, but I believe the tutorial will have you do it all as one. This is part of what can make Rails so quick.
- The migration details the kind of information that will be stored in the table. In this case each event is going to have a name, a location, a date, and a time. Timestamps are fields that mark when an entry was created, as well as when it was updated (if applicable).
- Remember how we saw in the user model that a user has many events? Well the events table is where you store the user id so you know which user created that event.
- Let’s get a bit of a closer look at relationships. One to one is probably not something you’ll use a lot, but useful to see. One to many Many to many: say you have a writing prompt about being out in freshly fallen snow. That could fall under the category of winter, nature, weather, or all of the above. Each of those categories could in turn have several other prompts. In this case, because the number of connections on both sides could be anywhere from 1 to infinity – 1, we’re going to need a join table. People have varying opinions on what you should name this join table, but as long as it’s clear, you’re good.
- In this case our user has a one-to-many relationship with events. A user may create many events, but a particular event only belongs to one user. This is not considering any guests, just users creating events.
- Let’s summarize this all up with some app flow. Say you’ve got a user looking at the awesome web app that you’ve created. What they see in their browser is connected to your view. They think it’s pretty cool, so they want to sign up.
- They click on a ‘create account’ link (or similar), which fires off a request to the app.
- That request says the programmatic equivalent of “hey, trying to create a new account here.” That hits the router, whose job it is to make sure that request goes to the appropriate place.
- The router sends that new user creation request to the controller.
- The controller sends that to the model to verify that everything’s on the up and up.
- The information then gets sent to the database and stored.
- Okay, well how are we getting back to the view?
- The information comes back from the database.
- It gets passed to the controller. The controller might fire off a particular action if something went wrong (like showing an error message), and another action if it goes right.
- In this case we’re going to assume that the new user was successfully created and stored. The controller fires off the success action you wrote and passes the user information to the view, which displays the user’s name at the top of the screen and says, “Welcome, Katherine!”
- Gems. Shiny!
- Rails is popular with startups like these because it allows a small team or individual to create at least a basic version of an app fairly quickly. So why doesn’t everybody use it?
- You may have heard that Twitter was built with Rails. So where Rails falters is in scaling up to handle giant apps where hundreds of thousands of users transmit and save data at any single second.
- So Twitter had to move off of Rails. But as you’ve just seen, Rails does a pretty good job for other companies that are household names.
- I didn’t want to end this presentation on a downer, so one last piece of nerd/tech humor.