Welcome To Ruby On Rails

Loading...

Flash Player 9 (or above) is needed to view presentations.
We have detected that you do not have it on your computer. To install it, go here.

0 comments

Post a comment

    Post a comment
    Embed Video
    Edit your comment Cancel

    1 Favorite

    Welcome To Ruby On Rails - Presentation Transcript

    1. Welcome to Ruby on Rails Kevin Lawver | June 25, 2009 http://uplaya.com Friday, June 26, 2009
    2. Hi, I’m Kevin Lawver Chief Architect at Music Intelligence Solutions - http://uplaya.com (it’s a Rails app) Worked at AOL for 13 years, launched two public Rails apps. Spent a lot of time on AOLserver using Tcl and Tomcat writing JSP’s. Just launched http://ficly.com with a friend as an “art project” (also on Rails) Friday, June 26, 2009
    3. What is Ruby? Object-oriented Interpreted Expressive “principle of least surprise” Friday, June 26, 2009
    4. “They are focusing on machines. But in fact we need to focus on humans, on how humans care about doing programming or operating the application of the machines. We are the masters. They are the slaves.” -- Matz Friday, June 26, 2009
    5. Everything’s an Object This confuses everyone at the beginning. Everything in Ruby is an object. There are no primitives, they’re all objects! For example, you can do things like 15.times or 24.hours.from_now It makes for compact, human-readable code. Friday, June 26, 2009
    6. What’s Rails? Web framework written by DHH in 2003 at 37signals for Basecamp Takes most of the “grunt work” out of building web apps MVC “Optimized for programmer happiness and sustainable productivity” Friday, June 26, 2009
    7. Who Uses It? 37signals: Basecamp, Backpack, Ta-da Lists, etc Twitter Yellowpages.com iLike (and Jango too) Hulu (and Vimeo) And thousands of other sites... Friday, June 26, 2009
    8. Why Use It? Convention over configuration Quick prototyping - can turn into the “real” project without starting over Convention makes it easy to share code and quick to get started Because it’s Ruby, you can turn it into anything you want Friday, June 26, 2009
    9. Rails’ Components ActiveRecord ActionController ActionView ActiveResource ActiveSupport Friday, June 26, 2009
    10. ActiveRecord The “M” in MVC Rails’ crown jewel - a great database abstraction layer. Makes it really easy to work with databases. In Rails, your models should contain 95% of your business logic. Friday, June 26, 2009
    11. ActionController The “C” in MVC Handles routing requests and processing them. In Rails, your controllers should be light Friday, June 26, 2009
    12. ActionView The “V” in MVC Where you do all your HTML and most of your XML. I’ve used a dozen different template systems over the years and Rails’ is by far my favorite. Friday, June 26, 2009
    13. ActiveResource Rails’ built-in support for RESTful API’s Makes it easy to do REST the right way Provides a lot of the wrappers, error cases and connection code you need to do RESTy stuff. Friday, June 26, 2009
    14. ActiveSupport All the extensions to Ruby’s base classes A lot of “glue” for JSON and other things that don’t belong in the other pieces Friday, June 26, 2009
    15. My Favorite Things About Rails I can go from idea to “real” in hours instead of days. It’s easy to refactor single pieces without affecting the whole app. Plugins solve major problems without requiring rewrites (see cache money) Community is helpful and responsive Friday, June 26, 2009
    16. Getting Started I don’t use Windows, so you’re on your own there. If you use a Mac and have Leopard, you already have Ruby and Rails. Linux? There are dozens of tutorials for your distro, don’t worry. Friday, June 26, 2009
    17. The 20 Minute Blog Sorry if you’re following along online, I’m heading to terminal now. Friday, June 26, 2009
    18. What we’ll be doing Create a new Rails app for our awesome new blog Build a model, controller and view for it Look at some helpful gems and plugins Make a feed for it Talk a little about ActiveRecord callbacks Friday, June 26, 2009
    19. What we won’t be doing Talking about tests (they’re important, but I hate writing them) Spending a lot of time on configuration Friday, June 26, 2009
    20. What we’ll be doing (redux) Create a new Rails app for our awesome new blog Build a model, controller and view for it Look at some helpful gems and plugins Make a feed for it Talk a little about ActiveRecord callbacks Friday, June 26, 2009
    21. Wasn’t that fun? now let’s talk about myths! Friday, June 26, 2009
    22. Some Rails Myths “Rails doesn’t scale” “Ruby (or Rails) is too slow” “Rails locks you into doing it its way” “X is better!” (where X = “Python”, “PHP”, “Java” or whatever) Friday, June 26, 2009
    23. Myth: “Rails Doesn’t Scale” Friday, June 26, 2009
    24. Maybe 3 Years Ago Back then, we had to use FastCGI or Mongrel. Now, though, we can use Phusion Passenger! It’s an Apache plugin that does a great job of managing Rails instances. And Ruby Enterprise Edition makes Rails use less memory and run faster. Brilliant! Friday, June 26, 2009
    25. Live-World Examples uplaya.com handles tens of thousands of requests a day on a couple tiny Amazon EC2 instances (we could do everything on one with room to spare, but I like having backup). ficly.com handles tens of thousands of requests a day on a single quad core server - that’s not even breaking a sweat yet. hundreds of other sites handle a lot more traffic with minimal hardware or fuss. Friday, June 26, 2009
    26. You will probably never need to scale. Friday, June 26, 2009
    27. But if you do... Friday, June 26, 2009
    28. The Data Layer Your database will fall over before your web server does. Optimize your connection, queries and indexes Protect your database by using memcached between your front-end and database Friday, June 26, 2009
    29. Cache, Cache, Cache memcached is your friend Disk-based caches don’t work once you grow beyond one server - same thing for in-memory caches Caching hides a world of programming sins, and saves you from having to do ugly things like sharding. Friday, June 26, 2009
    30. You Don’t Want... to be both read-heavy and write-heavy to have complex queries that can’t be cached to have to do multiple selects on a single request Friday, June 26, 2009
    31. The Most Important Thing is to launch! If you never launch, you’ll never have users. If you never have users, you’ll never have to scale. Rails helps me get from nothing to launch faster than anything else I’ve tried. It helps me get from launch to scale pretty quickly as well. Friday, June 26, 2009
    32. Typical Rails Stack Apache w/ Passenger *x MySQL Master memcached * y Slave Readers * z Writer Friday, June 26, 2009
    33. Myth: “Ruby is too slow!” Friday, June 26, 2009
    34. But, it’s fast enough for the web. Friday, June 26, 2009
    35. For all of my sites... No request takes longer than 1 second On uPlaya, the average time per request is 217 milliseconds. On Ficly, the average time per request is 165 milliseconds. That’s more than fast enough for the web. Friday, June 26, 2009
    36. The “Slow” in Rails Is the same slow anywhere else: Database The Internet CPU, Disk or RAM Friday, June 26, 2009
    37. Those factors affect everyone, not just Rails Friday, June 26, 2009
    38. Performance Gotchas Database indexes. If you’re selecting or sorting by a column, it should have an index! You won’t know you need them until it’s too late. Compression and Caching. Make sure you set up mod_deflate and set up reasonable expire times for static assets. It helps a LOT with perceived performance! Selects. Tune your cache so you can average zero reads per page view, if possible. Friday, June 26, 2009
    39. Myth: Rails makes you do things its way Friday, June 26, 2009
    40. It doesn’t make you. Friday, June 26, 2009
    41. It encourages you. Friday, June 26, 2009
    42. Plus, Rails’ way probably is the right way. Friday, June 26, 2009
    43. And if not, you can write a plugin to make it do it your way. Friday, June 26, 2009
    44. For example, things I don’t like... Rails’ built-in javascript stuff. I prefer jQuery, and RJS gives me a headache Routes, especially the name convention for generated routes Friday, June 26, 2009
    45. But... I happily use jQuery with Rails. I just don’t use the javascript helpers. And now there’s a plugin that let’s you use the helpers with jQuery. Win! I can live with the the route naming convention. It makes sense, even if I don’t like it. I could easily write a plugin to reverse route names if I strenuously objected. Friday, June 26, 2009
    46. Myth: “X is better!” Friday, June 26, 2009
    47. Your point is? Friday, June 26, 2009
    48. Religious battles over programming languages are stupid. Friday, June 26, 2009
    49. Use what makes you happy and productive. Friday, June 26, 2009
    50. Why You Shouldn’t Use Rails You have a legacy database that you can’t change. You could make it work with Rails, but it probably wouldn’t be much fun. You’re happy with what you’ve got and hate learning. You don’t ever talk to a database. Rails pretty much is ActiveRecord, so if you’re not using it, you might be better off with something else. Friday, June 26, 2009
    51. Ruby-based Alternatives Camping: http://wiki.github.com/why/ camping/ Sinatra: http://sinatra.rubyforge.org/ webby: http://webby.rubyforge.org/ Halcyon: http://halcyon.rubyforge.org Friday, June 26, 2009
    52. Gems! gem sources -a http://gems.github.com Pagination: mislav-will_paginate Faster URLs: pauldix-typhoeus Twitterness: hayesdavis-grackle Faster XML or HTML parsing: nokogiri or hpricot Friday, June 26, 2009
    53. Rails Plugins FTW! cache-money: a write-through cache for ActiveRecord. attachment_fu: great for handling uploads and storing them on s3 smurf: automatic minification of javascript and css openid_enabled: just what it says, painless OpenId. Friday, June 26, 2009
    54. To Wrap Up Rails is fun to work with. I’m way more productive now than I was before, happier too. Rails is more flexible than it gets credit for. It’s great for teams because it encourages good behavior Friday, June 26, 2009
    55. And now, a word from our sponsor: We’re looking for interns! Development, design or office management, we want ‘em! So if you know any, please have them e-mail jobs@uplaya.com! We’re also looking for a front-end developer and a Flash AS3 developer. If you know any of those, please have them send their resume to jobs@uplaya.com too! Friday, June 26, 2009
    56. And if you know anyone in a band Friday, June 26, 2009
    57. Please send them to... Friday, June 26, 2009
    58. uplaya.com! Friday, June 26, 2009
    59. Questions? Friday, June 26, 2009
    60. Thank you! Friday, June 26, 2009
    61. Contact Info kevin@uplaya.com @kplawver on twitter http://uplaya.com http://lawver.net Friday, June 26, 2009

    + Kevin LawverKevin Lawver, 5 months ago

    custom

    645 views, 1 favs, 3 embeds more stats

    I'm giving a presentation to the DWEEBS group at th more

    More info about this document

    © All Rights Reserved

    Go to text version

    • Total Views 645
      • 588 on SlideShare
      • 57 from embeds
    • Comments 0
    • Favorites 1
    • Downloads 9
    Most viewed embeds
    • 28 views on http://lawver.net
    • 28 views on http://refreshsavannah.com
    • 1 views on http://lwvr.net

    more

    All embeds
    • 28 views on http://lawver.net
    • 28 views on http://refreshsavannah.com
    • 1 views on http://lwvr.net

    less

    Flagged as inappropriate Flag as inappropriate
    Flag as inappropriate

    Select your reason for flagging this presentation as inappropriate. If needed, use the feedback form to let us know more details.

    Cancel
    File a copyright complaint
    Having problems? Go to our helpdesk?

    Categories

    Tags