Ruby on Rails from the other side of the tracks

Uploaded on

A 20-minute chat at the London Ruby User Group (from August 2006) about how to get client-side-developers, and even designers, involved in the process of making applications with Rails - helping them …

A 20-minute chat at the London Ruby User Group (from August 2006) about how to get client-side-developers, and even designers, involved in the process of making applications with Rails - helping them get involved in the templating process. It then diverges into a client-side perspective on Rails, looking in particular at issues around Javascript and Ajax, and XHTML testing. Because of its slide-heavy nature, it’s fairly self explanatory, but obviously you’ll miss out on some of the discussion around the talk (which was excellent).

More in: Technology
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
No Downloads


Total Views
On Slideshare
From Embeds
Number of Embeds



Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

    No notes for slide


  • 1. Ruby on Rails from the other side of the tracks Tom Armitage LRUG, August 8th
  • 2. aka
  • 3. “working with your design team” Tom Armitage LRUG, August 8th
  • 4. Who here makes stuff on the web? In Rails, maybe?
  • 5. Who would say they were roughly between “good” and “expert” at either Ruby or Rails?
  • 6. You may be used to the following screens. But. This is not the web:
  • 7. nor is this:
  • 8. nor is this:
  • 9. (thank god)
  • 10. the Web is
  • 11. HTML
  • 12. HTML
  • 13. XHTML
  • 14. CSS
  • 15. Who here would say they had expert- level XHTML?
  • 16. Why the hell don’t you?
  • 17. It’s OK, we have people to do this for us:
  • 18. Designers!
  • 19. They will save us with their rounded corners and stock photos!
  • 20. More to the point, some of them might be good at that XHTML lark!
  • 21. Sometimes dedicated people (not “designers”) write markup - so also talk to:
  • 22. Client-side developers Markup monkeys
  • 23. Anyway...
  • 24. What to do with front-enders Don’t assume you know better Don’t outsource Get them on board Get them templating
  • 25. Why? Close the loop Give them ownership Let them do their job Avoid mistakes
  • 26. Mistakes, you say?
  • 27. <ul class=’someclass’> <li>An item</li> <li>Another item</li> <li>The third item</li> </ul> A list of items.
  • 28. <ul class=’someclass’> for item in @items <li><%=></li> end </ul> The developer immediate approach.
  • 29. <ul class=’someclass’> </ul> Text This is valid XHTML 1.0 strict, but it may also lead to positional/aesthetic issues. (It’s also bobbins, semantically.) Whoops.
  • 30. <ul class=’someclass’> for item in @items <li><%=></li> end </ul> Let’s improve this...
  • 31. if @items.size > 0 <ul class=’someclass’> for item in @items <li><%=></li> end </ul> end That’s better.
  • 32. if @items.size > 0 <ul class=’someclass’> for item in @items <li><%=></li> end </ul> else <p>You have no items</p> end (Best).
  • 33. How? Get them into source control If you explain it well enough, everyone loves version control Collaborate on working wireframes Answer their questions Ask them questions Intervene (eg with helpers)
  • 34. Some notes
  • 35. Javascript & AJAX
  • 36. AJAX is cool!
  • 37. Javascript is coming back into fashion.
  • 38. (Who here would say they had expert level Javascript?)
  • 39. (Work on it - it’s going to come in handy)
  • 40. Libraries make Javascript much less of a PITA.
  • 41. Libraries are heavy
  • 42. Library weigh-in: prototype.js - 56kb effects.js - 34kb controls.js - 29kb dragdrop.js - 30kb
  • 43. The problems with Prototype Scaffolding gives you bad habits: <%= javascript_include_tag :defaults %> That’s 146kb on your page load And it loads serially Use what you need You don’t even need Prototype for basic JavaScript
  • 44. Helpers and accessiblity
  • 45. Rails’ HTML helpers are pretty great
  • 46. Rails’ HTML helper are: Accessible! Valid! Powerful!
  • 47. Rails’ Javascript helpers, on the other hand...
  • 48. They work...
  • 49. ...but not like they should.
  • 50. eg
  • 51. <a href=”#” onclick=”...”> foo</a>
  • 52. <a href=”/ toggle-user” class=”toggle- user”> foo</a>
  • 53. Seriously, though: Javascript has thorny accessibility issues. AJAX can be really inaccessible: Screenreaders Not just screenreaders Well-written Javascript goes a long way to make things easier
  • 54. “Hijax” Write without Javascript Then progressively add it, focusing on ids and classnames to act as hooks Best of both worlds Yes, this doesn’t work for some apps - but Web 2.0 doesn’t need to mean “inaccessible” all the time.
  • 55. What’s Rails doing about this?
  • 56. I asked DHH...
  • 57. “Fuck off”
  • 58. For everyone reading these slides who wasn’t at the talk: DHH didn’t say this. It’s a joke.
  • 59. however...
  • 60. Luke Redpath and Dan Webb rule!
  • 61. Accessible Javascript Plugin:
  • 62. It’s awesome
  • 63. Accessible Javascript Plugin Minimal changes to your code No inline reference to Javascript! Dynamically generated .js Dynamically generated event handling ...and more seriously impressive.
  • 64. Testing
  • 65. Everybody loves test-driven development, right?
  • 66. Testing XHTML Easy: W3C validator Valid code is easier to debug if it breaks, it’ll break in a consistent manner no point writing invalid XHTML Want to automate that?
  • 67. def assert_valid_markup(markup=@response.body) require 'net/http' response = Net::HTTP.start('') do | w3c| query = 'fragment=' + CGI.escape(markup) + '&output=xml' w3c.post2('/check', query) end assert_equal 'Valid', response['x-w3c-validator- status'] end assert_valid_markup
  • 68. No excuse for developers breaking front-end code any more!
  • 69. Going further Test components of your page with something like Hpricot Counting elements: boring Checking <title> is what it should be: useful Selenium, Watir Beyond my scope, but certainly also useful
  • 70. To summarise
  • 71. XHTML/CSS/JS are core components of your app, like it or not
  • 72. Designers and client-side developers know their stuff, so use them!
  • 73. Take accessibility seriously
  • 74. Take validation seriously
  • 75. Treat your front-end folks, and their code, as first-class citizens. The web is, after all, only XHTML.
  • 76. Thanks! Recommended reading: Designing With Web Standards - Jeffrey Zeldman Web Standards Solutions - Dan Cederholm CSS Mastery - Andy Budd DOM Scripting - Jeremy Keith The Rhino (O’Reilly js book)