Ruby on Rails' Strengths

• Easy to get started with, easy to get something done enough to launch
• Easy to re-factor and replace weak code with stronger
• Development speed and philosophy lend themselves to agile development methodologies

Weaknesses

• Some confusion about scale and the "right" architecture for Rails apps
  • Lots of people using Rails for the "wrong" thing.
• Can be hard to debug memory and performance issues
• Speed of new features/fixes/best practices can make it hard to keep up, especially in a behemoth like AOL.
• Lots of FUD in other communities about Rails' weaknesses, can be hard to separate myth from reality and past from present.

When (and not) to Use Rails

• When:
  • You need the power of MVC, but want to Get Things Done™ quickly
  • You want unit tests, a sane and flexible environment and help to do the Right Thing™
  • You like being a part of a very active and passionate development community
  • You can start with a clean slate database-wise
• But Not When:
  • You don't need an MVC or framework, especially if you don't need a database
  • You need to get lots of data from lots of different sources for each request
  • You're constrained by a legacy database and can't change anything

Some Companies Running Rails

• Hulu
• Vimeo
• Basecamp (by 37signals - they created Rails)
• YellowPages.com
• Twitter
• Rails also runs some of the most popular Facebook apps, including Packrat and another one I can't tell you about (I was sworn to secrecy)

The Ruby in Rails

• Everything is an object
  • You can do things like: 15.times do
• Or: "Bob Denver".downcase
• Real support for mix-ins, which makes patching and plugging in new features a snap
• It makes for very compact, expressive and human-readable code.

Demo Time!

• If you have OS X Leopard, you already have Rails (surprise!)
  • Before doing anything, you'll need to run: sudo gem update
• On Windows, check out InstantRails
• Lots of tutorials for the different flavors of *nix.

Creating a Rails App

• rails name_of_your_rails_app
• cd name_of_your_rails_app
• Run script/server and then go to http://localhost:3000
• Ooh and Ahh.

Creating a Model

• script/generate model Entry
• Open up db/migrate/001_create_entries.rb
• Add some columns (see mine)
• Run rake db:migrate
• Hey look, we have a table!

Playing With Your Model

• script/console
• entry = Entry.new
• entry.title = "My First Blog Entry"
• entry.body = "Hey, look, it's a blog entry!"
• entry.save!

The Faster Way to Create

entry = Entry.create(
	:title => "My Second Blog Entry",
	:body => "Wow, that's pretty awesome!"
)

Let's Make It Look Like Something!

• Create a new HTML document and save it to app/views/layouts/blog.html.erb
  • see mine
• script/generate controller entries index show
• Open app/controllers/entries_controller.rb
• Create a new line above "def index" and add:
  • layout "blog"
• On a new line under def index, add:
  • @entries = Entry.find(:all,:order => "created_at DESC",:limit => 10)

Looking Good!

• Now, open app/views/entries/index.html.erb
  • Grab mine
• run script/server
• visit http://localhost:3000/entries
• Ta-da!

Not Interesting Enough? Let's Add Comments!

• script/generate model Comment
• open db/migrate/002_create_comments.rb
• Let's add some columns
  • Grab mine
• rake db:migrate

Associations

• Open app/models/entry.rb
• Create a new line under line 1 and add:
  • has_many :comments
• Open app/models/comment.rb and under line 1, add:
  • belongs_to :entry

Let's Test It Out!

• Run script/console
• entry = Entry.find(1)
• entry.comments
• I guess we don't have any... so, let's create one!
• entry.comments.create(:email => "someone@somewhere.com",:url => "http://somewhere.com",:body => "Awesome blog post!")
• Now, let's see what entry.comments is...

Let's Display Them

• Open app/controllers/entries_controller.rb
  • Or grab mine
• Inside "def show", add:
  • @entry = Entry.find(params['id'],:include => 'comments')
  • @page_title = @entry.title
• Open app/views/entries/show.html.erb
  • Grab mine
• Oops! We forgot to get commenters' names!

Database Versioning!

• script/generate migration add_name_to_comments
• Open db/migrate/003_add_name_to_comments.rb
• Inside self.up, add: add_column :comments, :name, :string
• Run rake db:migrate
• Now we can go display things!

Back to views

• Make sure script/server is running
• Go to http://localhost:3000/entries/show/1
• Ta-da!

That's it!

• There are more associations, unit tests, validations and others, but that's enough for one brown bag.
• I left out almost all data validations and we didn't do any tests.

Things I've Learned

• The console is your friend.
• Fat models and skinny controllers are the best.
• Get someone "honest" to write your tests.
• Think about result set size.
• Speed makes up for a myriad of sins

The Scale Myth

...languages don't scale, architectures do

Scale is Inside

• Rails will scale if you do it right, just like anything else
  • Time to market is more important than scale to begin with anyway, so just get it out there and scale when you have to.
• Cache everything you can to protect the hard-to-scale bits of your app (database, disk, etc)
• Don't return unbounded associations!
• For example, back in our controller...

Unbounded Associations

• In app/controllers/entries_controller.rb, show method:
  • Entry.find(params['id'],:include => "comments")
• What if that entry has 10,000 comments?
• Create model methods with count limits, and page through.
• Let's fix it...

Model Methods

• Open app/models/entry.rb
• After has_many :comments, add a new method:

def limited_comments(count=10,offset=0)
	self.comments.find(
		:all,
		:limit => count,
		:offset => offset
	)
end

Let's Try It!

• First, we need to create at least 15 comments (this'll take some time)... or not!
  • In script/console
  • entry = Entry.find(1)
  • 15.times {|i| entry.comments.create(:name => "Me!",:body => "I am comment #{i}!")}

Ch-ch-changes

• In app/controllers/entries_controller.rb, show becomes:

def show
	@entry = Entry.find(params['id'])
	@page_title = @entry.title
	offset = params[:offset] || 0
	@comments = @entry.limited_comments(10,offset)
end

Changing the Show

• Which means we need to change app/views/entries/show.html.erb
• Anywhere we see @entry.comments, we change it to @comments

Cache It!

• Protect your database by caching everything you can!
  • Don't use disk-based caching in large deployments - because you'll have lots of instances and lots of disks.
  • Cache items as atomically as possible.
  • Separate cache deletion methods between object and partials (just remember this, it will make sense later)
• Check out the cache_fu plugin
• Memcached is the coolest thing ever.

Be Careful Who You Trust

• There are literally hundreds of Rails plugins out there. Be sure to check the code, and ask around before choosing a plugin for "serious" stuff (like database replication).
• Make sure any tutorials you follow are up to date.

Be Flexible

• The fix-rate in Rails-land is fast and furious. I don't recommend living on Edge Rails, but stay open to rewrites.
  • If you decide you have to monkey-patch Rails, keep it small and remember that it's there so future versions don't bite you.
• It should never take you so long to write a single feature that you feel bad about discarding it and starting over!
• Rails feels a lot more like art than code - sketch, form, re-form, tweak and mold.
  • And that's Ruby... learn and follow The Ruby Way. Don't write Ruby like you'd write PHP - it will suck.

Keep 'em Separated

• If you have a problematic part of your app, keep it separate! You can run it on separate mongrels, which will give you time to troubleshoot and isolate the problem.
• Mongrel behind Apache with mod_proxy_balancer gives you a lot of flexibility. Use it.

Speed Makes Up For Everything

• On AIM Photos, we were able to completely rewrite how we did things in an afternoon, test it, and repeat until we got it right.
• Developer time is expensive. The faster they can get things done, the better.
• Developer morale is more expensive. If they're not having fun and feeling productive, they'll work much slower.
• At its core, Rails is fun to work with.

An 'Incredible' Quote

In my experience, the thing that has the most significant impact on a movie's budget __ but never shows up in a budget __ is morale. If you have low morale, for every $1 you spend, you get about 25 cents of value. If you have high morale, for every $1 you spend, you get about $3 of value. Companies should pay much more attention to morale.

Brad Bird

The Future

• JRuby looks promising
• Life after Mongrel
  • Thin
  • Passenger
• Rails' little brothers
  • Merb
  • Nitro

Recommended Reading

• Agile Development With Rails (wait until the 3rd edition comes out)
  • O'Reilly's Ruby in a Nutshell is a good desk reference
• Riding Rails
• buckblog
• has_many :through
• Err the Blog
• Hungry Machine

AOL's Rails Apps

• Ficlets
• circaVie
• AIM Photos
• Pixnay

Questions?

• Download the app
• E-mail: kevin.lawver@corp.aol.com
• AIM: kplawver
• Blog: Ultranormal

The Team

• Product: Ian Costello (left AOL), Will Kern (ditto), Jeremy Rephlo (as far as we know, he's staying)
• Initial Developers: Venkat Balasubramanian, Jason Garber (left early on), David McVicar, Kevin Lawver
• QA: Laura Haft and Dia Johnson
• Project Management: Sabrina Doepringhaus
• Operations: Dan Bradley

AIM Photos Challenges

1. We have photos products already, do we need another one?
2. How/where do we store all the photos?
3. How do we convert them and retain quality?
4. We have little time and lots to do
5. And none of us have built a photo application before!

Choices

• None of the existing photo products we have fit the product requirements
  • XDrive has an API and storage and it made long-term sense, but they couldn't support all of the product requirements for launch.
  • AOL Pictures couldn't meet the date and had their own priorities
• So, we went with WSS for storage - lots of space and an easy HTTP-based API
  • With the understanding that we'd work with the XDrive folks to get their APIs in a state we could use and we'd talk about moving in the future.

The Big Choice: Ruby on Rails

• I'd just built ficlets, and we didn't have much time.
• Ficlets and circaVie both proved you could built quality products quickly with limited resources - which was exactly our condition
• AIM Photos seemed like a good candidate to see if Rails could scale

Results

• With a rotating crew of three developers (only one was on the project the whole time) and two QA engineers (one full-time), we built and launched AIM Photos in four months.
• Over 6.5 million photos (about half came from migration) in less than three months.
• Some load issues related to memory use and way underestimating growth, which we'll get to in a bit.

The Graph

Process

• We used Scrum
• It worked a treat:
  • We hit every sprint on time, and were 80% utilized
  • Even though we had a ton to do and very little time, we still beat Profiles out the door

Embracing Scrumminess

• Scrum works really well only if:
  • Everyone on the team embraces it. Product has to buy in and be a part of the process or you're just doing little waterfalls
  • Everyone believes in constant course correction and works to product better estimates, give better status reports and work smarter

Architecture

Rails Helpers

• We use a handful of great Rails plugins, which shows how reactive the community is to scaling needs:
  • cache_fu: Great memcached integration with ActiveRecord models.
  • Gibberish: Localization
  • acts_as_readonlyable: Easy-as-pie plugin to handle writer/reader databases.

Issue: Database Handles

• We started out using acts_as_partitionable, which, unfortunately, created a database connection for every model/database combination, which meant that across 60 mongrels, we were keeping up over five hundred open connections to the writer database
• Solved by finding and switching to acts_as_readonlyable.
• Lesson Learned: Choose your plugins carefully!

Issue: Memory and Image Manipulation

• Image manipulation is memory intensive and leaky.
  • We got hit by a memory leak in RMagick, which causes very bad things to happen to Mongrel
  • We found a way around it for now, but it took too long to figure out and fix
  • Exposes the immaturity of Rails profiling tools and understanding of how it uses and frees memory
  • But, it was possible, and the community is making huge strides in building those tools
• Lesson Learned: We should have spent more time looking at memory usage during development.

The Whole Graph

A Happy Disaster

• AIM Photos is getting about 3x more traffic than estimated
• When it was only 2x more, we were doing OK.
• Then, something happened, and... we weren't.
• Dan will talk about this a little, but thanks to him and being on the Matrix, we doubled our capacity in three days. Hooray for Operations!

Diary: The Java Developer (Venkat)

• Venkat asked me to give his slides... so pretend I'm him.

The Choice Thing

• Rails makes some choices for you and has strong opinions about how things should be done. For the most part this, is a good thing.
• On a lot of java projects, you just get it out the door™ and then cram it into an MVC later. Rails takes care of that for you and makes it easy to do the right thing.
  • The same can be said for unit testing, but Dave will cover that.

Configuration

• Configuration is so much easier than having to deal with dozens of XML files like in Javaland.
• Convention over configuration makes it really easy to get things working with little config.

The Console

• The Rails console is invaluable for debugging and rapidly developing models and plugins

Community

• The community is extremely active and helpful
• It's really easy to find plugins and recommendations.
• There's a lot of interest and things move quickly

The Right Choice for Some Things

• Rails is the right choice for some apps, not all:
  • Iterative developed and quickly deployed
  • Small/medium sized web applications
  • Lets you get up and running quickly and saves a lot of time with quality built-in solutions
• See also: Ten Things a Java Programmer Should Know About Ruby

Diary: The Value of Unit Tests (Dave)

Why Automated Unit Tests?

• Code can break more easily when multiple developers update a repository
• Functional breakdowns/Regression can be detected more easily
• Validates your Model and Controller Interfaces
• They're built-in with Rails!

Types of Tests in Rails

• Unit Tests
  • Tests Rails Model
  • YAML programmatically builds test data
• Functional Tests
  • Test Rails Controllers
  • Simulates HTTP requests + query params from a client

Further Investigation

• Google "TDD Rails" Test Driven Development
• BDD with rSpec

Diary: The Testers Perspective (Laura)

Challenges

• Environment set-up
• What is the best way to overlap development and QA?
• How can we test effectively and efficiently?
• How do we make sure that new bugs get addressed in a timely manner?

What Worked Well

• Pre-QAR testing
• Daily builds
• Combinations of TCM and exploratory testing
• Including tasks such as build installs and bug re-testing in the sprint planning
• Daily bug scrubs

Diary: Operational Considerations (Dan)

Rapid Application Delivery with the Matrix

• To share hardware or not to share hardware, that is the question.
• Pro: Shared hardware cuts down on time to deployment, and greatly
  increases expandability in times of crisis.
• Con: shared hardware makes you ruin other applications when you have
  memory leaks or performance issues.
• Con: versions of dependancies have to be the same. So if a different
  app comes along and wants to use Rails 2.0, we will have a hard time
  installing both onto the same host.
• We use the Matrix, which is a shared infrastructure, which means our
  development team will have to work extra hard to get the performance up
  to par.
• Given that we have had to rapidly scale to double our cacpacity, which
  took 1 business day, I think we made the right decision. If we didn't
  have to go through hoops for dependancies, we could probably reduce this
  time.

How to deploy rails in production

• We created the basic rails application in BCS.
• We also put all of our gems in BCS. The advantages are thet we can
  install from any AOL datacenter, we always have the same code, and we
  are able to track and query whats installed through standard rpm
  commands.
• Use apache to front end rails. We need to for VL, plus we can use
  mod_proxy_balancer to offload requests for WSS.

Tracking down performance issues

• Initially, we had performance problems with photos in production, that
  didn't happen in dev. It turns out the BCS version of the mysql plugin
  wasn't working because we had a mismatch of the gem and the mysql client
  library on the hosts we installed to. This made the application hang
  after a period of time, and prevented us from putting any real traffic
  on it at launch.
• Rails has had the previously mentioned memory leak. Tracking it down
  in production has been nearly impossible. The runtime tools for rails
  leave a lot to be desired.

Diary: Project Management Nightmares (Sabrina)

What Worked Well

• Scrum worked really well here
• Prep on tasks breakdown and estimates make sprint planning a breeze
• Winner: individual's accountability and team collaboration to meet the sprint's goal
  • (resources to volunteer in helping with tasks behind schedule)

Challenges

• Ruby QA environment setup (AIM Photos is the pioneer!)
• UI design happening in parallel with development in the same sprint
  • our tech lead helped out quite a bit here
• Discovery of new tasks and under-estimation of efforts in the beginning
• And then the usual: integrating party not in sync to integrate at the same time.

Conclusion

• Other than some growing pains, and on-the-run learning, the experience with Rails has been great.
  • There have been some operational issues, but they've been fairly easy to remedy or work around.
  • The speed of development, testing and developer happiness is worth some pain in being an early adopter
  • We need to experiment with new technologies to find the ones we should jump on and adopt.
• Scrum is great if you embrace it fully. The entire team has to buy in or it won't work.

The Best Practices

• Use the vocabulary to provide meaning around the data
• Write as little markup as possible to convey meaning and give you enough hooks to write CSS for

Kevin's Theory of Heterogenous Markup

• It's easier to style documents when you know what markup to expect.
• It's easier to style documents when there are different types of elements to build selectors around.
• It's a lot easier to read type selectors than class selectors.
• You will build smaller, faster, better web applications if you use fewer divs and open yourself to the wide array of semantic elements the XHTML 1.0 spec has to offer you.

Think Outside the <div>

• Divs are for large divisions of the page, or pieces that don't have other applicable semantics
• Use id's and classes to add semantics
  • microformats are a good start

Spans are Useless

• It takes at least 13 characters to put a span around content.
• Spans are meaningless.
• It's better to use another, shorter, meaningless element instead.
• b or i save you 6 characters per instance, which, over a large document, can significantly reduce page size.

Semantics Are What You Make of Them

• HTML was originally meant to mark up scientific documents
• It misses a lot of semantics needed in today's web
• It's OK to bend the original semantics of the element to serve your purpose and to get to heterogenous markup

Questions Before We Travel to the Future?

• One? Two? Three?
• Are they well-formed and valid?
• Now, what's coming next?

XHTML 2 vs. HTML5

• XHTML 2 has been in the works in the W3C for years...
  • But, web developers don't want it and neither do browser vendors
• Ian Hickson started the WHAT Working Group as a response to XHTML 2 "abandoning" the "real" web
• AOL and others led the charge to get a new "real web" HTML group started within the W3C.
• Now, we have a new HTML Working Group working on HTML5 (basically, the WHATWG's spec brought under the W3C umbrella)

What's New in HTML5?

• better document semantics
• new form elements
• video and audio get their own elements
• offline storage API

Better Document Semantics

• section: Denotes generic section of a document or application
• article and aside: Independent pieces of content part of the larger document
• header, footer and nav: Finally!

Video and Audio Get Their Own Playground

• There are video and audio elements now!
• There are huge issues about the default codec, how to handle other things, etc.

New Form Elements

• There are a lot of them!
  • lots of fields around dates and times
  • number
  • range (sliders, finally!)
  • specific for e-mail addresses and URLs

Offline Storage

• Like Google Gears and Firefox 3's APIs
• SQL and/or key-value pairs storage

When to Jump In?

• Not yet! Nothing in HTML5 is interoperably implemented yet!
• You can play around with some the new form elements in Safari 3.
• Apple, Mozilla and Opera have all committed to supporting HTML5 - it's just a matter of waiting for implementations.
  • No word from Microsoft yet...

Questions Before We Move On?

• Are the experimental?
• Are they implemented yet?

Introducing: The URI

http://something.something#fragIdentifier

Subject Predicate Object

http://dev.aol.com/node/230 has the value of creator as "Arun Ranganathan"

Now Use URIs

http://dev.aol.com/node/230
dc:creator
http://www.arunranga.com
TimBL's Tabulator (Demo)

A Challenging Proposition

<address class="vcard">
<a class="fn url" href="http://tantek.com/">Tantek &Ccedil;elik</a>
</address>

Semantics on the GRDDL

• Extract data from XHTML using XSLT Transformations
• link rel="transformation"
  *Use Namespaces Inside XHTML Documents
  *Let the XSLT Do the Trick, or else Use RDFa

RDFa By Example

• Uses XMLNS to Embed Attributes via rel="ns:prop" or

<meta
<html xmlns:cal="http://www.w3.org/2002/12/cal/ical#" xmlns:contact="http://www.w3.org/2001/vcard-rdf/3.0#">

• Creative Commons

<a rel="license" href="http://creativecommons.org/licenses/by/3.0/">cc</a>

Getting It

• Download it
• Untar is and drop it in app/vendor/plugins
• Then check out the wiki
  • It may be a little out of date - I've been busy - most things should be the same.

Configuring it in Development

$TRRICONFIG = {
 :host => "reddev-l26.tred.aol.com:8080",
 :url => "/TRRI/REST/",
 :appid => "yourappid", ## Change your your TRRI appid
 :appkey => "",
 :default_type => "text",
 :default_category => "story",
 :timeout => 3,
 :ratings_scale => 10
}

Configuring it in Production

$TRRICONFIG = {
 :host => "trri.search.aol.com:80",
 :url => "/TRRI/REST/",
 :appid => "yourappid", ## Change your your TRRI appid
 :appkey => "", ## Your AKES key
 :default_type => "text",
 :default_category => "story",
 :timeout => 1,
 :ratings_scale => 10
}

Adding it to a Model

acts_as_trri {
  :category => "photo",
  :type => "image"
}

Adding Tags

photo = Photo.find(1)
photo.set_tags(["horse","bucket","silly"],"kplawver@aol.com")
# or
photo.add_tags(["foo","bar"],"kplawver@aol.com")

Getting Tags

photo = Photo.find(1)
tags = photo.get_tags

Removing Tags

photo = Photo.find(1)
photo.remove_tags(["foo","bar"],'kplawver@aol.com')

Adding a Review

photo = Photo.find(1)
photo.add_review({
  :author => "kplawver@aol.com",
  :title => "My Review of Stuff",
  :text => "That's friggin' awesome!",
  :ratings => [
	{
      :subject => "Quality",
      :scale => 10,
      :score => 7
     }
  ]
})

Getting Reviews

photo = Photo.find(1)
reviews = photo.get_reviews(20,1)
reviews[:reviews].each do |review|
  # Do stuff here
end

What Review Objects Look Like

• review
  • review_id
  • posted: Time object gives you date posted in UTC
  • author
  • appid
  • type
  • category
  • title
  • text
  • ratings: array of
    • subject, scale and score

Incrementing Counters

photo = Photo.find(1)
photo.increment_counter

• Defaults to "View" for the type.
• Other supported types are:
  • Collect, Subscribe, Recommend, Forward

Getting Counters

photo = Photo.find(1)
counter = photo.get_counter
count = counter[:count]

• Default is, again, "View"

Get Top

top = Photo.get_top
results = top[:results]

• Defaults to "Popular", "30day" and "All"

Objects in Results Array

• result
  • status: "ok" or "notfound"
  • id: the id of the object
  • object: the actual ActiveRecord object - can be nil if it's not found!

Caveats

• Not every part of it's been exercised yet, and I keep finding little bugs here and there.
• It works and is in production in AIM Photos
  • an early version is working on ficlets
• It's easiest to play with it in the Rails console.

Questions?

• You've got to have at least one

Issues

1. The markup's not valid. The validator reports 120 errors.
2. HTTP-EQUIV Meta tags are old school. Your webserver should be returning those headers.
   • Either way, all attributes must be lower case.
   • All elements must be lower case.
   • All elements must be closed.
   • Alt attributes only exist for images. Use title for everything else.

... let's start there and we'll pick up the rest in a bit.

Markup Decides Your Fate

• Your markup is the foundation for everything else.
• If it's bad, your CSS will be worse
• If it's good, you'll write less CSS and it'll be easier to redesign later.
• Because...

CSS is Parasitic

• We'll talk about this later, but CSS can only find and style elements it can find.
• The harder you make it to find the element you want to style, the more complex and inflexible your CSS will be.
• Which means...

Use the Right Element for the Job!

• If you're using the same class over and over again, you're probably not using the right element for the job.
• Semantic meaning is not written in stone.
• Unordered lists are your friends.
• Use appropriate headings for your content. It helps with accessibility, and even with CSS.

Use an XML Editor

• Provides quick validation checks
• Should provide you available options for all elements so you don't have to guess.

Writing Good Markup

Here's how I write HTML. Your mileage may vary:

1. I think about the content first. What's most important? What order should everything be in?
2. I mark up the bare minimum to provide meaning and give me logical hooks to write CSS around (divs around major sections, everything else as semantic as possible).
3. Validate often!
4. Only when I'm happy with the markup do I start writing CSS.

And Now CSS

• Let's start with vocabulary (hopefully, there's a whiteboard)
  • selector
  • declaration
  • property
  • descendent selector
  • child selector
  • wildcards (boo, hiss!)

Specificity

• The least understood, but most important part of CSS.
• Specificity determines which properties actually apply to an element.
• Let's draw some pictures...

Keep It Isolated

• Avoid wildcards!!
• Use enough specificity to make sure you're not going to accidentally affect elements you don't mean to.
• But, don't over-specify because you may need to override later.

A Sense of Order

• Keep one stylesheet for your product.
• Avoid inline styles, both style elements and especially style attributes
• Write your CSS in document order!

Things You Don't Need

• Separate browser-specific CSS files
• Lots of server-side code to check for browsers and serve different markup.
• Honest

CSS Hacks

• All CSS hacks should be done in the same stylesheet so you can keep track of them!
• CSS hacks should be as minimal and affect as atomic a property as possible.
• CSS hacks should all be valid CSS.
• The big browser you have to watch out for is IE 6. IE 7 needs a little help, but not much.
• Should be kept as close as possible to the block or property they're overriding!!

Acceptable Hacks

• The underscore hack:
  • Put an underscore in front of a property to make it apply only to IE6.
• The IE7 * html child selector hack:
  • Hides the declaration from everyone but IE7.
• Child Selector:
  • Hides from IE6, shows to all the "good" browsers.

Performance

• One CSS file, and one only!
• If you need to have multiples for localization, put it right underneath the original.
• The fewer files you make your users download, the better.
• Inline CSS blocks aren't cached, and shouldn't be there!
• Style attributes are the worst because you can't override them!

CSS Reality Check

• You have three linked CSS files, and two style elements. Why?
• You should validate your CSS too:
  • snslanding_css.css: 14 errors
  • snslanding_dyk2.css: 1 error (and it's not a "real" error)
  • snsMiniStyles.css: 35 errors (WTF?)

Things to Think About

• zero is zero and doesn't need a unit
• for padding and margin, 0 is the same as 0 0 0 0.
• don't set font sizes in pixels! IE6 can't resize them, which creates accessibility problems.
• set the font properties on the body element and don't change them. You rarely need to change the font face.

Conclusion

• Markup is extremely important. Take the time to get it right.
• Keep your CSS as simple as possible. The better your markup is, the easier that is to accomplish.
• Keep your CSS maintainable by keeping it in document order, and with adequate specificity so you can read it later on.

Questions?

• kevin.lawver@corp.aol.com

The Pieces

• Ruby on Rails - Open Source MVC Framework written in Ruby
• Memcached - In-memory cache for storying objects, fragments and sessions
  • cache_fu - Plugin for Rails that does 90% of the memcached work for you.
• MySQL
• TRRI - Taggings, Ratings and Reviews infrastructure. Used for comments and tags.
• Web Storage Services - Storage for photos. Provides us practically unlimited storage per user.
• The Matrix: Virtualized shared hosting. Will allow us to roll out new instances quickly when we need them.

Where We Are

• Just finishing up our third sprint.
• 90% of user-facing functionality is in place (may not be working perfectly, but it's mostly in there)
• Still working on:
  • Caching and Performance
  • CAT Tools
  • Profile Integration (waiting on a lot of pieces to be finished)
  • Bugs and cleanup
  • Visual Design

Enough Talking, Let's Do The Demo!

• This is running on my laptop, and I'm "cheating" and using OpenAuth.

Ingredients

1. Ruby on Rails
2. The following gems:
   • ruby-openid
   • mofo
3. MySQL
4. jquery
5. A page with an OpenID delegate, an hcard and a blogroll with XFN
   • I mean, who doesn't have that?

Getting Started

1. Create a rails app: rails mashup_u
   • Or download this thing
2. Make the changes in the README
3. Configure the database in config/database.yml
4. run script/server to make sure things work.

The Routine Stuff

1. delete public/index.html
2. put jquery.js in public/javascript
3. create a layout
4. add that layout to application.rb

Create Your Model

script/generate model User

Create Your Controllers

script/generate controller users
script/generate controller signin

Now, It's Time To Create a Signin Page!

1. open up controllers/signin_controller.rb
2. We need a few methods: index, aol_signin, aol_signedin, openid_signin, openid_signedin
3. We'll start with OpenID...

Configuring

• We need to tell Rails where to store OpenID stuff
• In environment.rb (at the bottom):

require "openid"
$OPENID_STORE = OpenID::FilesystemStore.new("#{RAILS_ROOT}/tmp/cache")
$OPENID_RETURN = "http://HOST:PORT/signin/openid_signedin"

Handling OpenID

• We need to create the form in app/views/signin/index.rhtml
• Then we need to create the action!

Logging In With OpenID

• We need to create the openid_signin method in app/controllers/signin_controller.rb

Let's Log In!

• Woo-hoo! (I'm being hopeful)

Let's Add OpenAuth!

• Go get a key
• Add some config to environment.rb
• And then add some code to signin_controller.rb!

Let's Log In!

• Woo-hoo! (again with the hope)

Time to make a User

• We've logged in, now what?
• We need to define what's in our users table.
• Open up db/migrate/001_create_users.rb and add some columns

Create Some Relationships

• Yet another model: script/generate model Relationship

Now, We Need Some Users!

• We need some to play with, so let's fake some.
• Run script/generate migration create_dummy_users
• And let's make some friends!
  • When you do this, you should use folks from your buddy list or who are on your blog roll.

Time To Make The Tables!

• Run rake db:migrate

We Need to do Something About the Login Process

• Let's make it do something special if you're a new user...

Now, we're ready to do something cool!

• I know, finally!
• Now, we have two different user types, and need to do slightly different things with them.
• We can also assume slightly different things from the data we have about them.

For OpenID Users

• We have an URL.
  • What's there?
  • What can we infer about the user from the data we find there?

Enter Microformats!

• Let's look for an hcard
• Let's look for some XFN links
• Yes, mofo is that cool.

For AOL Users

• We have a screenname and a display name
• We have a buddy list, so we know who their friends are.
  • This version uses javascript to pull in the buddy list that I stole from another project. There is a way to do it server-side.

Back to the Code!

• We need to handle those new users, so into users_controller.rb we go!
• We need to define a new method.
• And then do something different based on their identity_type.

Creating a Form

• Now we need a form so they an tell us stuff we either don't know, or change the stuff we do.
• Then we need to do something smart when they hit Save.

Finding the Network

• Let's show OpenID first.
• We go grab the identity url
• crawl for XFN links
• then do a lookup and see if they're in our network
• display them to the user and let them choose who to keep and who to ignore.

Find the AOL Network

• It's all built into the buddy list, so we have to do some extra stuff to get to it.
• Sprinkle in some javascript
• A little JSON web service
• And voila, the people in your buddy list who are here already!

Creating Your User

• In users_controller.rb, we need a create method!
• It creates the user, then adds the relationships they checked off from the form.

Possibilities

• It would be trivial to turn these two things into widgets so you could put in your blog URL and have it pre-fill the contacts, even if that's not your identity URL. Same thing with the buddy list stuff.
• What other places are there on the web that aggregate this data in:
  • Predictable formats
  • With enough "reputation" to make it reliable and accurate
  • That don't require Yet Another Network to maintain?

Questions

• Gimme a minute, I need to catch my breath...

Set of developer tools

• Extend functionality beyond the AIM client
  • Tap into existing community of 68 million users

Web AIM (Beta)

• Add AIM to your web page
  • Ability to send and receive messages, set presence, access users' Buddy lists, etc

AIM CC

• SDK to build your own custom client
  • Add AIM functionality to your current application

AIM Bots

• Create interactive Bots for any purpose
  • Bot is able to interact with your community in real-time, on-demand

AIM Plugins

• Add your specific features to AIM
  • Access built-in location based services (Skyhook)

Open Success Stories

AIM Pro

• Built using AIM Custom Client
  • Enterprise level AIM client
  • More info

Lite AIM

• Built using AIMCC
  • Small memory footprint client without all the bells and whistles
  • More info

SCI's PlayLinc

• Gives gamers many tools including AIM/ICQ integration
  • AIM integration allows gamers to communicate with their friends and set-up matches
  • More info

The Lounge

• Virtual world where music fans can hang out, talk about music and interact
  • Uses AIMCC
  • More info

Chumby

• Will launch with an AIM widget built on the Web AIM beta platform.
  • Custom Flash class will be added later this year (Time Frame TBD)
  • More info

What does this give you

• Ability to tap into the existing AIM network
• Create communities around existing screennames (OpenAuth)
• Promotion from AIM site for applications built on AIM platform
• Limitless mashup possibilities

So what does this give us

• Further growth of AIM network beyond AIM client
• Tested, stable environment that is easily extended
• Less development time and energy to integrate with other applications

Aim Developer User License

Currently license restricts development to:

...and your Application shall be for use with the U.S. based version of the AOL Service exclusively.

• Legal and product management are working to revise this ASAP

Kevin's turn

Open Building Blocks

• We're going to talk about two:
  • Open Identity
  • Open Interaction and Social Data

Case Study: User Authentication

Ficlets

• A site for folks without a lot of time who want to write stories
• An "innovation" project built by a very small team in a very short period of time using Ruby on Rails

Enter OpenID and OpenAuth

OpenID

• Distributed identity:

OpenID starts with the concept that anyone can identify themselves on the Internet the same way websites do-with a URI (also called a URL or web address). Since URIs are at the very core of Web architecture, they provide a solid foundation for user-centric identity.

OpenAuth

• Allows third-party sites to authenticate AOL/AIM users in their web apps
• more info

What It Buys Ficlets

• No more passwords! Users don't have to remember yet another one, and I don't have to store them.
• I don't have to create the "oops I forgot my password" UI!

Integration

• OpenID: Ficlets used the OpenID Enabled Ruby Library
• OpenAuth: Three methods in the signin controller... took about 20 minutes.

Demo

• Go sign in!

Case Study: No More Blank Slates

Web AIM

• Allows third party sites to access AOL/AIM users' buddy lists, send IMs and create mashups around and through the AIM network.
• more info

Well, How Can That Help Me?

• Make use of a user's existing social network!
• Interact in real time with your users, allow them to share your content with their friends
• Add IM and Buddy List to your existing application, widget platform, blog, etc.

Example: Widget

• Using Netvibes' UWA, I created a simple Buddy List widget.
• Try it out
• Works great in standalone mode, but there's currently an open question about module servers that keeps it from working in the "real" NetVibes.

How it Works

• Almost a drop in of the Whimsicals code, with a little bootstrapping to make it work in UWA and to fix some CSS stuff.
• Whimsicals are just a reference implementation. JSON and XML APIs are available for you to build apps around.

Example: The Social Blank Slate

• I can't get my friends or family to set up a feed reader to keep up with my blog, photos, etc
• But, they'll actively prune and keep their buddy list in AIM.
• Why not use that to make it easy to set up a feed reader?

Enter: Buddy Reader

• Removes the "blank slate" problem by pre-populating your feed list with your buddies' feeds
• Allows your friends to alert you to new sources of their content

Demo: Buddy Reader

• Currently running on my laptop
• Signin
• Choose my buddies
• Update my feeds
• Browse

Possibilities

• What else could you do?
• How else could a user's existing buddy list remove barriers or give your product a head start?
• What else do you want?

Conclusion

• There's no need to start a "green field" social network.
• Leverage your users' existing connections.
• Have fun, and be open.

Beginnings

• Modern IDEs embrace markup, javascript (or javascript-like) interfaces
• Modern desktop apps are providing more and more data through web services
  • and digesting, or built on top of, web services (feed readers, etc)

Today

• Open APIs
• Desktop apps are essentially windowless browsers
• Many more apps include renderers in them somewhere
• Byte-less applications allow for rapid deployment
  • Web: Yahoo Pipes, Ning
  • Desktop: Apple's Cocoa Framework
• Did you configure your wireless router with a client or web app?
• Even Office tools are moving online...
  • Google Docs and Spreadsheets
  • Zoho
  • Thinkfree
  • and many many more

The Web Won

• Forgiving programming model
  • Fairly easy to get started with
• Flexibility
• Upgrade path between versions smoother
  • Ever thought about "sunsetting" a website?
  • Client APIs find themselves relegated to the backend

Demo Time...

• Web APIs doing traditional client work make for easy consumption
• Focus on the UI rather than the brute forcing a protocol

Demo Time...

• Open AIM Web APIs talk directly to the AIM Cloud via JSON calls
• Custom Session type allows for game data to be sent in a back channel between web pages

Is there any hope for clients?

• Flex and Apollo do not provide high quality P2P solutions
• Development tools are still better for clients
• Clients are more sticky then web apps (push vs. pull)

Demo Time part II...

• COM/ATL APIs acknowledge javascript so web APIs can play nicely
• User interface tools on the client side are becoming more like web pages
  • XML-like Windows Presentation Foundation and Boxely, AOLs toolkit for internal and external consumption

Demo Time part II...

• Open AIM API that AIM Lite uses allows for javascript plugins to be injected
• Javascript hooks both Open AIM as well as Flickr's REST API
• Results are displayed is a simple Boxely UI control

The "semantic web"

• Apps are already more aware of semantic data in web pages.
• Upcoming versions of modern browsers will be microformat-aware and allow you to do useful things with semantic data embedded in today's web.

Demo Time part III...

• Install Firefox and the Operator extension.
• Go to a story on ficlets
• Export my hcard to your address book
• Or, browse that story's tags on other sites.

Tomorrow's Browsers

• This kind of thing will be seamless
• Provide true web-to-desktop integration

Tomorrow

• Better browsers
• Offline DOM storage in Firefox 3.0
• Better scripting standards and tools
• Better markup standards (Web Formats, XHTML+)
• Easier to use IDEs
• Straight-from-the-web compilers (see Amnesty Singles)

And Now for a Couple Announcements...

• No really, these are good.

Contact Info

• Main AIM Developer Web Page
• AOL Developer Network
• Greg's Blog
• Kevin's Blog

What's Next?

• What do you want to see?
• What can we do to help?
• How does the relatively slow rollout cycle of desktop apps keep up with the ever-amorphous web?

How did Ficlets Happen?

• Proposed at Kerry Parkins' Community in a Box offsite in early December
• It was one of the "winners" and I got approval to build a prototype as an experiment
• I got a very small team (4-5 total for design and dev): no project manager, no product lead, no QA
• Designed in three weeks while I was on vacation, built in two months after I got back.

What Were You Trying to Prove?

• We could use Rails to build high quality viral products quickly and with minimal QA involvement
• I could lead a very small team and crank out a full-fledged product very quickly
• That AOL could embrace the startup model - fuzzy roles, not a lot of process - and do it successfully
• That we could launch a site that accepts OpenID and AOL screen names.
• That we could launch a site that uses Creative Commons

Who Did It?

• Jason Garber - Front end wizard. He did all the microformats, CSS and a lot of javascript, so I didn't have to
• Ari Kushimoto - Did a lot of the UI and her initial take on the logo led us to the final treatment
• Me - Idea, product owner, project manager, architect, designed the database, wrote all the models, controllers, routes, and did a good bit of the install.
• Cindy Li - Lots of UI, initial brainstorming and direction and tons of marketing at SxSW
• Jenna Marino - The awesome visual look of the site and the logo.

What Happens to Ficlets Now?

• We're fixing bugs, rolling them out several times a week
• Waiting to see how ficlets does so we can justify phase two

Why We Used Rails

• I'd been playing with it for months and looking for a "class project"
• It felt like the right choice for rapid development
• Very active community, good documentation, lots of deployment options
• It's fun.

What's Rails?

• Web development framework written in Ruby
• A full-featured MVC, complete with development environment
• As much a philosophy for web development as it is a framework

Why is it Cool?

• It's easy to use
• Super quick to install and get something working
• Lots of plugins, gems and other fantastic tools to speed up development
• Solid development philosophy that enforces best practice, but allows you to get around it if you absolutely have to.

Getting Started With Rails

• Lots of full apps you can download:
  • OS X - Locomotive
  • Windows - InstantRails
• But, you should probably just install it by hand.
  • OS X
  • Windows XP

Creating a Project

• rails project_you_want_to_create
• cd project_you_want_to_create
• script/server
• http://localhost:3000

Getting Something Working

• Create your database
• Configure in config/database.yml
• Create a table in your database
• run script/generate scaffold table_name

The Scale Myth

• With the release of mongrel, scaling Rails is no longer a real problem (or no bigger a problem than any other product).
• Ficlets is currently running on two machines with:
  • 1 apache each
  • 4 mongrels each
• We've handled being boingboing'ed, dugg, ma.gnolia'ed, etc. with no real problems.

OpenID

• Allows for distributed identity - you keep your identity and "share" it with requesting sites
• Identity Providers (like AOL) and Relying Parties (like Ficlets)
• See OpenID

OpenID and Rails

• We decided to use the library at OpenID Enabled
• Provides easy hooks for being both an identity provider and relying party - used on several public sites, and actively developed and supported.

The OpenID Login Process

1. User entered OpenID
2. Relying party requests OpenID, looks for delegate URLs
3. Redirects User to URL found in the openid.server link.
4. User authenticates and grants or denies permission
5. User is redirected by Identity Provider back to Relying Party

The Code: Signin

1. Checks to see if you're already signed in
2. Checks for return URL and sets that in the session
3. If it's a POST
   1. Begins the OpenID login process
   2. Redirects to Identity Provider or returns error

The Code: Signedin

1. Check for success criteria
2. Checks to see if User exists
   1. If User exists
      1. Set session[:user] to User.id
   2. else
      1. Create new User
3. Redirects to intended URL or the homepage

Handling Multiple Userspaces in One App

• Database has not just a login, but a logintype to tell me where the user came from
• Currently support OpenAuth and OpenID, but could support others (intended to support Yahoo's BBAuth but ran out of time)
• We create "pen names" so users "real" identity is kept private.

Lessons Learned

• Rails is fantastic, and makes development "fun"
• Rails provides a great platform for pair programming
• The myth that Rails can't scale is just that - a myth
• I wouldn't skip QA the next time, but it can be done - and I'd spend a lot of time creating test cases
• The design process is a lot more fun when it's collaborative and design and development feels like one team

Conclusion

• It is possible to do things both quickly and well
• We're too entrenched in roles and process to truly innovate
• We have insanely creative and smart people within the company - it's time to unshackle them and let them be both creative and smart.
• OpenID is great, and will bring a lot of people in to our products who don't want AIM screennames.

Questions?

My questions for you:

• How can we do more stuff like this?
• What's standing in the way of innovation?
• What new technologies or methodologies should we be trying out?

Where are They Used Today?

• By companies like:
  • AOL
  • Yahoo
  • Technorati
  • LinkedIn
  • Ma.gnolia and others
  • Eventful
  • Edgeio
  • Many more!
• By individual developers and bloggers all over the world
• See all the implementations

Existing Web Services

• Technorati
  • hcard to vcf service
  • hcal to ical service
• AIM Pages
  • Service to pull individual modulet modules from AIM Pages
  • Example
• See the implementations page for more

Existing Parsers

• Ruby: mofo
• PHP: hKit
• Javascript: Sumo
• Python: Python Microformat Parser

Use Case: Widgets

• AIM Pages provides a web service around modules
• Any page on AIM Page is a web service.
• Example

Demo: Incestuous Widgets

• My Page has a list of conferences I'm attending.
• Me Evil Twin's Page has one too!
• If I sign in as me and to go my evil twin's page, it shows the events we're both going to!

Incestuous Widgets: How It Works

• Grabs the visitor's my-events module if it's there.
• Looks for URLs that are in the current page's my-events module.
• Builds and then displays list of shared events.
• the code

Use Case: Mashups and Portable Content

• When your page is the API, people don't need fancy REST or SOAP APIs.
• You only have to build it once, and then see how people use it.

Demo: Mashups and Portable Content

• Ficlets has lots of different feeds
• But, it's missing feeds for prequels and sequels.
• Les Orchard created his own prequel/sequel feed from our microformatted content

Use Case: OpenID

• OpenID provides distributed identity - all based on URLs.
• What if those URLs contained hcards?

Profile Demo

• Built on Ruby on Rails
• Uses OpenID for authentication
• When it returns, it grabs the identity URL and looks for HCards using mofo
• Populates your profile with the data if it finds an hcard.
• Download it (coming soon)

Use Case: Feeds Without Feeds

• What if you didn't need a feed? What if your content was so well described on the page you could use that as the feed?

Demo: AIM Pages (if the network works)

• I build a "cheap" blog module for AIM Pages
• I wanted a feed, but didn't want to have to figure out how to write out another file to the user's directory.
• Microformats to the rescue!

Demo: AIM Pages: Building the Feed

1. Using PHP, I grabbed that module of the page
2. Parsed out the hatom feed using DOM methods
3. Return it as ATOM

Demo: Rails + hpricot (if the network doesn't work)

• Using Rails and hpricot, I built an hatom to ATOM conversion.
• Demo

Conclusion

• Produce content once, then repurpose
• Don't want XHTML anymore? Transform it!
• Use data from everywhere without dealing with APIs
• Get the "semantic web" today.

Q&A

What Came Before

• Convincing your company to embrace web standards

What's Next?

• Once you've embraced open standards, the next step... open APIs!

What's Mashup Culture?

• Open
• Agile
• Data wants to be free
• Nothing is sacred, and everything can be squished, mangled or munged to make something new and interesting.

Why Mashup Culture?

• Entrenched processes engender entrenched thinking
• Get out of the ditch of the same old thing
• Innovate more quickly
• Allows for a sense of play, which can only help morale and boost productivity
  • (That one's for the managers)

Alla

• Slides

Arun

So, The Saga Continues

• Last Year's Story: Web Standards
  • Efficiency, Reuse, Elegance, Accessibility
• This Year's Story: Guerilla Standards
  • Community Openness.

Guerilla Standards: Case Study

• AOL and OpenID
  • Lots of Internal Debate, Discussions at Mashup Camp, and Blogosphere Stuff
  • And then: 63 Million Screennames can be used as OpenIDs
  • http://openid.aol.com/screenname
  • http://journals.aol.com/screenname or journals.aol.com/screenname/blogname
  • Ficlets accepts OpenID
• Liberty Alliance's Notions of ID
• Proprietary ID

Viva La Revolution

Greg

• Slides

Steve

• Slides

Wrapping Up

Don't Forget to Ask

• Nothing changes if you don't ask.
• Ask
• If you don't like the answer, come up with a better question

Embrace the Agile

• Show that things can be done quickly - embrace new technology
• Embrace small teams moving quickly

Example: Ficlets

• I asked if I could build a prototype as an experiment
• 2 copies of Agile Development With Rails
• 2 developers
• 3 designers on the main project
• 3 months from concept to launch
• Creative Commons and Flickr API
• Launched Wednesday, cuz why not?

Conclusion

• If we can move a large mature company with entrenched processes like AOL, you can move yours.
• Start small. Don't be afraid of prototypes and mockups
• Have fun. Mashups are about fun and exploration - so go explore!
• And get great people to help evangelize.

What are Web Standards?

• Definitions for Authors and Implementors to allow for interoperability, and consistent implementation of functionality.
• When used by geeks and nerds, they frequently mean XHTML and CSS.

What Kinds Are There?

• Dejure
• Defacto
• "Guerilla"

Dejure Standards

• Ratified by a Standards Body
• Well documented (although often not in language normal humans understand), usually with very good test cases and at least a reference implementation.
• Examples:
  • XML, SOAP, ATOM
  • HTML, CSS, ECMAScript

Defacto Standards

• Become standards through large install base. Examples:
  • Microsoft Office
  • Flash
  • RSS

Where Do They Come From?

• W3C: XML, HTML, CSS, SOAP, etc
• Liberty: Identity and authentication
• OASIS: Lots of XML schemas
• Lots of others...

Guerilla Standards

• We'll talk about that later...

Why Should I Use Them?

• Quality is easily tested through validation
• Consistency
• Documentation
• Consistent and interoperable implementations

Don't Invent New XML Languages!!

• Tim Bray wrote an excellent article
• Key points:
  • Inventing new XML languages is hard, and more importantly, expensive
  • To do it right, you have to create schemas, validators and all new tools
  • Why do that when there is probably already an XML language that will express what you need?
• Use the standards-based development method instead!
  
  

The Standards-Based Development Method

• State your problem
• Research applicable standards
• Look for implementations
• Extend only if absolutely necessary

Step One: State Your Problem

• What are you trying to accomplish?
• What data do you need to represent?
• What are the endpoints and delivery methods?

Step Two: Research

• Are there any existing standards that represent similar data?
• Are there data structures in other fields that could be mapped to your data?

Step Three: Look for Implementations

• Is there already an open source toolkit in the language of your choosing?
• How mature is it?
• Is it something we should use and contribute back to?

Step Four: Extend Only if Absolutely Necessary

• Extend through namespaces
• Don't break existing tools!
• Don't change the meaning of existing elements

Case Study: XHTML

• XHTML is the XML-ization of HTML.
• Currently four flavors:
  • XHTML Transitional 1.0
  • XHTML Strict 1.0
  • XHTML 1.1
  • XHTML 2.0

Benefits: Consistency

• XHTML requires you to close tags, quote attributes and use all lowercase elements and attributes.
• That means you can enforce consistency across developers.

Benefits: Validation

• Validation becomes easier as a preliminary test of quality.
• Most decent text editors provide in-place validation.

Benefits: Broad Implementation

• There are parsers for XHTML in almost every programming language
• Because it's just XML, you can use XML parsers.
• Fairly consistent implementation across modern web browsers

Benefits: Well Documented and Understood

• Lots and lots of books and web resources.
• Well-established best practices
• Many subject matter experts within and outside of the company.

Guerilla Standards

• Small groups, forming "rebel" working groups
• Created to address perceived shortcomings of existing standards
• Sometimes end up in larger established standards bodies

Examples

• Microformats
  • Uses existing standards' (HTML and XHTML) attributes to add meaning to ambiguous elements
• ATOM
  • Alternative to RSS. More consistent and well-designed than RSS.
  • Also provides a syndication API.
• WhatWG
  • Formed in response to the W3C's direction with XHTML 2.
• OpenID
  • Allows for truly portable internet identity

Example: Microformats

• All work is done on e-mail lists and the wiki
• Rigorous community review makes for better standards.
• Has been accused of being "cultish" and led by a small group
  
  

Why Microformats?

• You have to use classes in your HTML, why not use classes with meaning?
• They're the semantic web today. We don't need no stinkin' RDF!
  
  

Microformats vs. W3C

• Microformats try to "pave the cowpath" instead of "boil the ocean"
• The process of creating a microformat and getting it approved by the community can be done in weeks instead of years (::cough:: W3C).
  
  

Example: WhatWG

• Produced the HTML5 and WebForms 1.0 specs.
• Along with group of W3C member companies (including AOL!), led the W3C to reconsider the direction of XHTML and the reformation of the HTML Working Group.
• Extremely informal, but doggedly led by Ian Hickson.
  
  

How Is AOL Involved? W3C

• AOL is a member of the W3C, and currently has representation on the following working groups:
• CSS WG: Cindy Li, Kevin Lawver
• Protocols and Formats WG -- A WAI activity/WCAG: Donald Evans
• Mobile Web Best Practices WG: Arun Ranganathan
• Web Security Context WG: Praveen Allavilli, Shawn Duffy, Zhihong Zhang
• Future HTML WG: Geoff Bishop, Arun Ranganathan
• Web API WG: Arun Ranganathan, Kevin Lawver
• Web Application Formats WG: Arun Ranganathan, Kevin Lawver, John Robinson
• Web Content Labeling XG (Incubator Group): Diana Pentecost
• We observe: Semantic Web, Web Services XML Protocol, Patent Policy, P3P

Other Standards Bodies AOL is a Member of

• Liberty Alliance: federated identity standards
• OMA: Open Mobile Alliance
• IETF: Internet Engineering Task Force: Edwin Aoki and Richard Collela
• INCITS: Accessibility
• OASIS: Monitor, but don't actively participate in the Security and Open Document Format: Roger Martin
• JCP: Java Community Process: Carlos O'Kieffe
• OMTP: Open Mobile Terminal Platform: Pim van Meurs, Mary Lou Hardy
• DDEX: Digital Date Exchange: Metadata for media: Nick Sincaglia

AOL is a Guerilla

• Several employees are active in:
  • the Microformats community - ModuleT, hAtom, hReview and hResume
  • OpenID - Trying to get agreement between all the identity specs on a direction
  • Atom - John Panzer has been very involved in the Atom community
    
    

How Can I Get Involved?

• We need more representation in the W3C! If you're a domain expert, talk to your manager and get approval.
• Adopt standards-based development practices!
• Don't create any more XML languages
• Reach out. There are domain experts in the company who can help point you in the right direction.

Conclusion

• Follow the steps
• Ask, don't invent

Questions?

Today

• Open APIs
• Desktop apps are essentially windowless browsers
• Many more apps include renderers in them somewhere

The Web Won

• Forgiving programming model
  • Fairly easy to get started with
• Flexibility
• Upgrade path between versions smoother
  • Ever thought about "sunsetting" a website?

Beginnings

• Modern IDEs embrace markup, javascript (or javascript-like) interfaces
• Modern apps are providing more and more data through web services
  • and digesting, or built on top of, web services (feed readers, etc)

Demo

• Greg? (I sure hope this works)

Tomorrow

• Better browsers
• Better scripting standards and tools (DOM3, WebAPI)
• Better markup standards (Web Formats, XHTML+)
• Easier to use IDEs
• Straight-from-the-web compilers (see Amnesty Singles)

What's Next?

• What do you want to see?
• What can we do to help?
• How does the relatively slow rollout cycle of desktop apps keep up with the ever-amorphous web?

Agenda

• Microformats Introduction
• Development Case Study
• Cool Examples
  • Generation
  • Discovery
  • Transformation
• Stuff You Can Use Today
• Questions! (you can ask them any time, honest)

What are Microformats?

Microformats are a set of simple, open data formats built upon existing and widely adopted standards.

No, Really...

• Conceptually:
  • A way of thinking about data formats that's highly correlated with semantic XHTML, AKA the real world semantics, AKA lowercase semantic web, AKA lossless XHTML
  • a set of simple open data format standards that many (including Technorati) are actively developing and implementing for more/better structured blogging and web microcontent publishing in general.
• Practically:
  • Add a little bit of extra stuff to your existing markup and you've joined the party.
  • Small changes to how you already create XHTML.
  • Makes your good markup better without a lot of extra work.

Sounds Hard...

• Nope! Take this from the conference homepage:

<address>
    Westin Boston Waterfront<br />
    425 Summer Street<br />  
    Boston, MA  02210<br />
    <a href="http://maps.google.com/maps?q=425+Summer+Street,+Boston,+MA+02210&hl=en" target="_map">View Map</a>
</address>

That Same Code With Microformats!

<address class="vcard">
    <p class="org">Westin Boston Waterfront</p>
    <p class="street-address">425 Summer Street</p>
    <p><b class="locality">Boston</b>, <b class="region">MA</b>  <b class="postal-code">02210</b></p>
    <a href="http://maps.google.com/maps?q=425+Summer+Street,+Boston,+MA+02210&hl=en" target="_map">View Map</a>
</address>

That Wasn't So Hard, Was It?

• We can use a little CSS (two or three lines at the most) to make that look like we want.
• We'll talk about why you'd want to do all that a little later.
• But first... how we create microformats!

Paving the Cowpath

• solve for existing applications
• solve a specific problem
• start as simple as possible
• design for humans first, machines second
• reuse building blocks from widely adopted standards
• modularity / embeddability
• enable and encourage decentralized and distributed development, content, services

Reuse, Reuse, Reuse!

• reuse building blocks from widely adopted standards
  • Before you go inventing a new language, learn the current ones
  • Document them, find strengths, weaknesses and reasons behind decisions
  • Pick the best from each one, or just go with what exists

Current Microformats

• Several are "finished", lots are very close
• Several are in the brainstorming and example phases.

XFN, rel-license and rel-tag

• All use the rel attribute of links.
• XFN: XHTML Friends Network - Tell the world what your relationship is with the folks on your blogroll.
  • Example: <a href="http://lawver.net/jen" rel="spouse"></a>
• rel-license: Define the license for your content. Becoming more and more important
  • Example: <link rel="license" href="http://creativecommons.org/licenses/by/2.0/"/>
  • Example 2: Licensed under <a href="http://creativecommons.org/licenses/by/2.0/" rel="license">Creative Commons 2.0</a>
• rel-tag: Tag the current page with links
  • Example: <a href="http://lawver.net/politics" rel="tag">politics</a>

XOXO

• Mark up lists like outlines or blogrolls (comparable to OPML)
• v1.0 is final
• Homepage

XOXO Example

<ul class="xoxo">
    <li>An item
        <ul>
            <li>A sub-item</li>
        </ul>
    </li>
    <li>Another item</li>
</ul>

hCalendar

• Pretty much everything in the iCalendar spec (you know, an iCal or Outlook entry) in HTML.
• baked, set in stone, etc
• Homepage

hCal Example

<ul><li class="vevent">
    <h4 class="summary">
        <a class="url" href="http://theajaxexperience.com/" target="_new">The AJAX Experience</a>
    </h4>
    <div class="description">I'll be speaking about microformats, and their uses
        in DOM scripting, web services and AJAX-y goodness
    </div>
    <p class="location">Boston, MA</p>
    <p>
        <abbr class="dtstart" title="2006-10-23">10/23/2006</abbr> - 
        <abbr class="dtend" title="2006-10-25">10/25/2006</abbr>
    </p>
</li></ul>

hCard

• Everything in an address book card, only in HTML.
• Done!
• Homepage

hCard Example

<div class="vcard">
    <a class="url fn" href="http://lawver.net/">Kevin Lawver</a> - 
    <a href="http://aol.com" class="org">AOL</a>
</div>

hAtom

• The ATOM feed format turned into HTML.
• Draft, but a solid one.
• Homepage
• We'll look at an example in a little bit.

hAtom Example

<div class="hentry">
   <h3 class="entry-title">
       <a href="http://someurl.com/blog/permalink" class="bookmark">My Blog Post</a>
    </h3>
   <div class="entry-content">I'm going to AJAX Experience!</div>
   <p>
       Published <abbr title="2006-10-24T09:30:30">10/24/2006</abbr> 
       by <b class="author">Kevin Lawver</b>.
   </p>
</div>

hReview

• A way to mark up reviews.
• Drafty, but closey to doney
• Homepage
• If we have time, we'll look at an example of this too.

hReview Example

<div class="hreview">
 <span class="reviewer vcard">
  <span class="fn">anonymous</span>, 
  <abbr class="dtreviewed" title="20050418">April 18th, 2005</abbr>
 </span>
 <div class="item">
  <a lang="zh" class="url fn" href="http://www.imdb.com/title/tt0299977/">
  Ying Xiong (<span lang="en">HERO</span>)
  </a>
 </div>
 <div>Rating: <span class="rating">4</span> out of 5</div>
 <div class="description"><p>
  This movie has great music and visuals.
 </p></div>
</div>

hResume

• Mark up your resume
• A little draftier than the others.
• Homepage

hResume Example

• Keri Henare has a nice one.

Development Example: ModuleT

• Needed to create modules, but couldn't use other existing formats
• Wanted it to be easy for developers to create, test and deploy them.
• Wanted to be able to embed them in any other format or HTML page.
• So, we created a microformat!

Document Existing Formats

• Created a wiki page for examples
• Looked at everything, tried to talk to everyone.

Draft, Publish, Revise, Repeat

• Our profile went through several drafts.
• Each one got better.
• We eventually had to stop and actually get to work...

ModuleT in Action

• Currently in use on AIM Pages
• Coming soon to other AOL products
• Released under a royalty-free license, so anyone can use it for pretty much anything.

Generating Microformats

• I created a module (javascript)
• Allows users to create a simple list of events
• Not terribly exciting, except they're marked up as hcal events!
• See it in use (left hand side)

Parsing Microformats

• I have the Operator plugin, which will light up icons when it sees microformats on the page.
• Click the one that lit up, and it should show you the info it found on the page.
• We'll talk about this a little later.

Discoverability

• Ok, big deal, you can put some dates on your page.
• But, what if everyone else did too?

Shared Events

• Now, when I go to my other page, it should tell me what events "we" have in common.

How Sharing Works

• Module javascript
• Using AIM Page's super cool pageQuery API, I can get just a piece of a page
• I take the URLs out of that chunk, and compare it to the URLs in the my-events module on the current page.
• If any are the same, they get added to the list, and you get a friendly "Hey, you've got events in common" message.
• Check out the module above that one. If I go to my other page, we'll see what events the two pages share.
  

Possibilities

• SEO is a dirty word, but this could turn out to be SEO on crack.
• Lots and lots of well-marked up data just laying around the web... and spiders crawling all of it.
• I smell smarter spiders in our future.

Your Document Becomes the API

• Using ModuleT, we built a web service to pull individual modules out of a page
• Example
• Lots of other examples of transforming microformats into other things (more on that in a second)

What if...

• You wrote XHTML expecting it to be transformed?
• Your web page was the API, what would happen?
• You could embed pieces your web page in other pages, what would that look like?
• Which leads to...

Transformation

• Ok, let's start with a new module: Cheap Blog
  • Example (first module in the middle column)
  • The interesting bit of code
• It's a cheap blog! It stores everything in the page!
  • In hAtom to boot
• Now that we have a blog in the page, what can we do with it?

Transform it!!

• Using Robert Bachman's XSLT, we get just the piece of the page we need, then transform it!
• Originally using Robert's stylesheet, now using PHP DOM stuff because my foo is not strong enough (or I didn't have enough time to troubleshoot some encoding issues).
• Example
• It's not perfect, but this is a demo, right?

Other Tools for Transformation

• There are several existing stylesheets and services for microformats (converting to and from):
  • hAtom2Atom: XSL and a proxy
  • X2V - Converts hCard and hCal to vcard and iCal.
  • hCal to iCal - Give an URL, get back a .ics file!
  • hCard to vcard - Give an URL, get back vcards!

Mashups and Microformats

• Microformats make getting meaningful data out of HTML documents easier
• Consistent class names and formatting mean repeatable parsing across documents
• Allows for a whole new set of web services

Beginnings of the Revolution

• Browser plugins/extensions
• Web services
• Bookmarklets
• Others?

Some Browser Examples

• Operator
• Tails
• Tails in Action
• User Generated Microformats

Other Microformat Web Services and Extensions

• Pingerati - Sends pings to appropriate microformat-aware services based on what's in your page.
• Greasemonkey - Screaming for more microformat mashups. Already treats web pages as a canvas.

Things That Would Make Me Happy

• Microformat to JSON conversion tools
• A "global" widget/module spec
• Consistent licensing of web pages, feeds and services so I know what I can use/embed
• More smart people thinking about web services around microformats.

The Future is Bright

• The Semantic Web is taking forever, and depends on people creating new ontologies, and users fundamentally changing how they use the web.
• Microformats can be the semantic web today, with existing user behavior and using existing browsers and tools.
• There are now millions of web pages with microformats embedded in them.
• The services around them are getting better and better as more people start paying attention.
• What can you do with them?

Return on Investment

• Because someone asked that I cover it... if you use microformats, you'll get:
  • more SEO juice in the future
  • cool Web 2.0 buzz from the geek-o-sphere
  • automatic functionality as more tools become available
  • instant web services because your page becomes your API

Questions?

• One, two, three... four?
• More? Is it still too early for questions?