Ruby on Rails
from the other side
of the tracks

            Tom Armitage
         LRUG, August 8th
aka
“working with your
design team”


           Tom Armitage
        LRUG, August 8th
Who here makes
stuff on the web? In
   Rails, maybe?
Who would say they
   were roughly
 between “good”
 and “expert” at
  either Ruby or
      Rails?
You may be used to
   the following
screens. But. This is
    not the web:
nor is this:
nor is this:
(thank god)
the Web is
HTML
HTML
XHTML
CSS
Who here would say
 they had expert-
  level XHTML?
Why the hell don’t
      you?
It’s OK, we have
people to do this for
         us:
Designers!
They will save us
with their rounded
corners and stock
      photos!
More to the point,
some of them might
  be good at that
   XHTML lark!
Sometimes
dedicated people
(not “designers”)
write markup - so
   also talk to:
Client-side
  developers

Markup monkeys
Anyway...
What to do with front-enders
 Don’t assume you know better
 Don’t outsource
 Get them on board
 Get them templating
Why?
Close the loop
 Give them ownership
 Let them do their job
Avoid mistakes
Mistakes, you say?
<ul class=’someclass’>
       <li>An item</li>
       <li>Another item</li>
       <li>The third item</li>
     </ul>




...
<ul class=’someclass’>
      for item in @items
      <li><%= item.name=></li>
      end
    </ul>




The developer immed...
<ul class=’someclass’>
    </ul>



                   Text
                   This is valid XHTML 1.0
                str...
<ul class=’someclass’>
       for item in @items
       <li><%= item.name=></li>
       end
     </ul>




Let’s improve t...
if @items.size > 0
     <ul class=’someclass’>
       for item in @items
       <li><%= item.name=></li>
       end
     <...
if @items.size > 0
     <ul class=’someclass’>
          for item in @items
          <li><%= item.name=></li>
          e...
How?
Get them into source control
 If you explain it well enough,
 everyone loves version control
Collaborate on working w...
Some notes
Javascript & AJAX
AJAX is cool!
Javascript is
coming back into
    fashion.
(Who here would
say they had expert
 level Javascript?)
(Work on it - it’s
going to come in
     handy)
Libraries make
Javascript much
 less of a PITA.
Libraries are heavy
Library weigh-in:
 prototype.js - 56kb
 effects.js - 34kb
 controls.js - 29kb
 dragdrop.js - 30kb
The problems with Prototype
 Scaffolding gives you bad habits:
 <%= javascript_include_tag :defaults %>

 That’s 146kb on ...
Helpers and
accessiblity
Rails’ HTML helpers
  are pretty great
Rails’ HTML helper are:
 Accessible!
 Valid!
 Powerful!
Rails’ Javascript
 helpers, on the
  other hand...
They work...
...but not like they
      should.
eg
<a href=”#”
onclick=”...”>
    foo</a>
<a href=”/
 toggle-user”
class=”toggle-
     user”>
    foo</a>
Seriously, though:
 Javascript has thorny
 accessibility issues.
 AJAX can be really inaccessible:
  Screenreaders
  Not j...
“Hijax”
 Write without Javascript
 Then progressively add it, focusing
 on ids and classnames to act as
 hooks
 Best of bo...
What’s Rails doing
  about this?
I asked DHH...
“Fuck off”
For everyone
reading these slides
 who wasn’t at the
talk: DHH didn’t say
   this. It’s a joke.
however...
Luke Redpath and
 Dan Webb rule!
Accessible
Javascript Plugin:
http://tinyurl.com/znzmc
It’s awesome
Accessible Javascript Plugin
 Minimal changes to your code
 No inline reference to Javascript!
 Dynamically generated .js
...
Testing
Everybody loves
    test-driven
development, right?
Testing XHTML
Easy: W3C validator
Valid code is easier to debug
 if it breaks, it’ll break in a
 consistent manner
 no poi...
def assert_valid_markup(markup=@response.body)
      require 'net/http'
      response = Net::HTTP.start('validator.w3.org...
No excuse for
developers breaking
 front-end code any
        more!
Going further
 Test components of your page
 with something like Hpricot
  Counting elements: boring
  Checking <title> is...
To summarise
XHTML/CSS/JS
     are core
components of your
 app, like it or not
Designers and
   client-side
   developers
know their stuff, so
    use them!
Take accessibility
    seriously
Take validation
   seriously
Treat your front-end
   folks, and their
code, as first-class
citizens. The web is,
     after all, only
        XHTML.
Thanks!
Recommended reading:
Designing With Web Standards -
Jeffrey Zeldman
Web Standards Solutions -
Dan Cederholm
CSS Ma...
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Ruby on Rails from the other side of the tracks
Upcoming SlideShare
Loading in...5
×

Ruby on Rails from the other side of the tracks

3,965

Published 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 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).

Published in: Technology
1 Comment
9 Likes
Statistics
Notes
No Downloads
Views
Total Views
3,965
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
134
Comments
1
Likes
9
Embeds 0
No embeds

No notes for slide

Ruby on Rails from the other side of the tracks

  1. 1. Ruby on Rails from the other side of the tracks Tom Armitage LRUG, August 8th
  2. 2. aka
  3. 3. “working with your design team” Tom Armitage LRUG, August 8th
  4. 4. Who here makes stuff on the web? In Rails, maybe?
  5. 5. Who would say they were roughly between “good” and “expert” at either Ruby or Rails?
  6. 6. You may be used to the following screens. But. This is not the web:
  7. 7. nor is this:
  8. 8. nor is this:
  9. 9. (thank god)
  10. 10. the Web is
  11. 11. HTML
  12. 12. HTML
  13. 13. XHTML
  14. 14. CSS
  15. 15. Who here would say they had expert- level XHTML?
  16. 16. Why the hell don’t you?
  17. 17. It’s OK, we have people to do this for us:
  18. 18. Designers!
  19. 19. They will save us with their rounded corners and stock photos!
  20. 20. More to the point, some of them might be good at that XHTML lark!
  21. 21. Sometimes dedicated people (not “designers”) write markup - so also talk to:
  22. 22. Client-side developers Markup monkeys
  23. 23. Anyway...
  24. 24. What to do with front-enders Don’t assume you know better Don’t outsource Get them on board Get them templating
  25. 25. Why? Close the loop Give them ownership Let them do their job Avoid mistakes
  26. 26. Mistakes, you say?
  27. 27. <ul class=’someclass’> <li>An item</li> <li>Another item</li> <li>The third item</li> </ul> A list of items.
  28. 28. <ul class=’someclass’> for item in @items <li><%= item.name=></li> end </ul> The developer immediate approach.
  29. 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. 30. <ul class=’someclass’> for item in @items <li><%= item.name=></li> end </ul> Let’s improve this...
  31. 31. if @items.size > 0 <ul class=’someclass’> for item in @items <li><%= item.name=></li> end </ul> end That’s better.
  32. 32. if @items.size > 0 <ul class=’someclass’> for item in @items <li><%= item.name=></li> end </ul> else <p>You have no items</p> end (Best).
  33. 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. 34. Some notes
  35. 35. Javascript & AJAX
  36. 36. AJAX is cool!
  37. 37. Javascript is coming back into fashion.
  38. 38. (Who here would say they had expert level Javascript?)
  39. 39. (Work on it - it’s going to come in handy)
  40. 40. Libraries make Javascript much less of a PITA.
  41. 41. Libraries are heavy
  42. 42. Library weigh-in: prototype.js - 56kb effects.js - 34kb controls.js - 29kb dragdrop.js - 30kb
  43. 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. 44. Helpers and accessiblity
  45. 45. Rails’ HTML helpers are pretty great
  46. 46. Rails’ HTML helper are: Accessible! Valid! Powerful!
  47. 47. Rails’ Javascript helpers, on the other hand...
  48. 48. They work...
  49. 49. ...but not like they should.
  50. 50. eg
  51. 51. <a href=”#” onclick=”...”> foo</a>
  52. 52. <a href=”/ toggle-user” class=”toggle- user”> foo</a>
  53. 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. 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. 55. What’s Rails doing about this?
  56. 56. I asked DHH...
  57. 57. “Fuck off”
  58. 58. For everyone reading these slides who wasn’t at the talk: DHH didn’t say this. It’s a joke.
  59. 59. however...
  60. 60. Luke Redpath and Dan Webb rule!
  61. 61. Accessible Javascript Plugin: http://tinyurl.com/znzmc
  62. 62. It’s awesome
  63. 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. 64. Testing
  65. 65. Everybody loves test-driven development, right?
  66. 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. 67. def assert_valid_markup(markup=@response.body) require 'net/http' response = Net::HTTP.start('validator.w3.org') 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. 68. No excuse for developers breaking front-end code any more!
  69. 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. 70. To summarise
  71. 71. XHTML/CSS/JS are core components of your app, like it or not
  72. 72. Designers and client-side developers know their stuff, so use them!
  73. 73. Take accessibility seriously
  74. 74. Take validation seriously
  75. 75. Treat your front-end folks, and their code, as first-class citizens. The web is, after all, only XHTML.
  76. 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)
  1. A particular slide catching your eye?

    Clipping is a handy way to collect important slides you want to go back to later.

×