OSCON Wrap-Up.

It's been a week since OSCON ended and I'm just beginning to recover. Very interesting things abound.

The theme/tagline of this year's event was The Future is Open. Rumor is the runner-ups with The David Hennemeier Hanson Show and With Ruby on Rails! More on that in a bit though.

Ben Hammersley and I had quite a good turn out and response to our 45 Syndication Hacks in 45 minutes presentation. While we were in one of the smaller presentation room its was filled to capacity throughout. You dread presenting on the last day, last session because attendance is significantly diminished as everyone is burnt-out or running off to catch their flight. Ironically I seem to draw this dubious honor each time I present. Perhaps there is a secret password I'm forgetting to say. Nevertheless for those who are interested in our flying-by-the-seat-of-our-pants slides they are here.

I attended Brad Fitzpatrick's scalable Perl presentation. Quite an impressive setup they have developed. Some of the tools they've develop and released as open source – memcache and perlbal – look quite intriguing stuff I hope to take a look at soon. The mention of a forthcoming distribution, Data::ObjectDriver, caught my eye. As I suspected it sounds like an open source version of MT's data persistence layer with various high-end scalability functions built in. Six Apart founder Ben Trott discusses the module here. Looking forward to that modules release.

My sleeper pick was Yahoo's Michael Radwin's presentation on HTTP caching and cache busting. Highly useful information to anyone dealing with efficient distribution of content on the Web. Presentation hasn't been posted. My rough notes at the end of this post.

So Ruby on Rails and its creator David Hennemeier Hanson seemed to be everywhere at the conference. The good Mr. Hanson had 1 tutorial, 2 presentations and 1 keynote this year. Several other Ruby presentations were also on the bill and the discussion of many conversations heard through out the conference. There was even a Ruby on Rael sighting. The always insightful and humorous Danny O'Brien put it best when he noted that Ruby moved from being ignored to winning (thereby bypassing being laughed at and fighting) in about three weeks. I always worry when any thing gets hyped up into such a rich foamy lather because misuse and backlash is inevitable. Ruby on Rails does have a lot of nice things worth praise.

The thing I like most about Rails is the thinking and philosophy behind the framework. The idea of joy and aesthetics is a novel one that gets lost or forgotten. I once felt that type of joy from MT and know it really can make a difference.

The following are my rough notes I took from Extracting Rails from Basecamp and Secrets Behind Ruby on Rails.

Less people, more power
Less money, more value
Less resources, better use
Less time, better time

Prove that an application is worth building the big thing (scaling up) for it.

We built half a product instead of a half-ass product.

Develop less software.

Too much enterprise. Too much focus on 99.999% uptime. Too much 100 man shops.

Liberate the good ideas. Change the language. Change the context. Retain the core insights.

Call me shallow. I love beautiful code. Aesthetics. Joy.

On APIs: I'll know when I see it. You have to feel an API to make it fit. Guessing the future is for fortune tellers.

Why Open Source? For entirely selfish reasons. Make others do the work. Bask in the glow of being a giver. What's there to loose?

Fear obscurity. You need a network to reap the effects.

Passion is infectious. The baseline of excitement. A conversation of success.

Scaling a culture. Early influx can bend you out of shape. Release not so early, then often. Set a viral example of kindness.

Getting rid of XML situps. Use conventions.
 class Post < ActiveRecord::Base
 belongs_to :weblog
 has_many :comments
 has_one :author, :class => Person
 end
No compilation. No deployment. No server restarts. No code generation.

Ruby: Introspection, Open classes, Execute code in class definitions.

Complete, integrated, and familiar stack. One language all the time.

The bucks stops here. We handle it all.

Responsible for the whole experience. Taking care of all the little things.

Flexibility is overrated. Its a bad notion. Trade flexibility for constraints are liberating.

Of all the Rails knock-offs being discussed, this last point, that flexibility (in frameworks) is overrated, seems to be the most crucial and most overlooked attribute. (Are you listening Catalyst team? This is what I meant.) Phil Windley rocks out flexibility being overrated here. I didn't get to attend the Rails tutorial, but Phil did.

Notes on Michael Radwin's HTTP Caching presentation:

 Cache Publishing and Busting.

 (Dynamic Content)

 Frequently 
     HTML

 Occasionally
     CSS
     JavaScript

 Rarely/Never
     Images
     Flash
     PDF

 (Static Content)

 Top 5 Techniques.

 Use Cache-Control: private for personal content
     For use with dynamic content. 
     HTTP 1.1 Caching anything by default
     In practice, most caches avoid anything with:
         Cache-Control/Pragma header
         Cookie/Set-Cokkie header
         WWW-authenticate/Authorization
         POST/PUT
         302/307
         SSL content

     Cache-Control: private

     Shared caches bad for shared content
     Private caches perfectly OK
     Avoid personalization leakage.

 Images Never Expire
     Dictate that images once published never change
         Set Expires header 10 years in the future
     Use news names for new versions
     Tradeoffs
         More difficult for designers
         Faster user experience, bandwidth savings

     mod_expires
     ExpiresActive on
     ExpiresByType image/gif A315360000 # 10 years
     ExpiresByType image/jpg A315360000

     mod_headers provides a HTTP 1.1 solution

     mod_images_never_expire - Never even hits the file system 
     when an if-Modified header is sent.

 Cookie-free TLD for static content
     A seperate domain name for your static content (like images) 
       cuts down on the size of the requests coming from a cookie 
       header being inserted in every request.
     Many proxies are more likely to not cache a file to avoid 
       personalized data leaks.

 Use Apache defaults for occasionally changing static content

 Use randon tags in URL for accurate hit metering or 
   very sensitive content.
     Convert public shared proxy caches into private caches
     Without breaking real private (browser) caches
     (Missed last point)

     (Missed more here.)
     Return 302 to highly cacheable images file
     Counts 302s as hits

     Does not require modifying HTTP headers
         No need for Pragma: no-cache or Expires
         Doesn't break the back button
     Browser history & visited-link highlighting
         Javascript timestamps/random numbers
             Easy to implement
             Breaks visited link highlighting
         Session or Persistent ID preserves history
             A little harder to implement

     User expectation: Back button works instantly
         Private caches normally enable this behavior
     Aggressive cache-busting breaks back button
         Server sends Pragma: no-cache or Expires in past
         Browser must re-visit server to re-fetch page
         Hitting network much slower than hitting disk
    (one more)

 Pro-Caching Techniques
 Cache-Control: max-age=<bignum>
 Expires: <10 years into future>
 Generate static content headers
     Content-Length
     Last-modified, ETag
 Avoid cgi-bin, cgi, "? in URLs
     Some proxies (e.g.Squid) won't cache
     Workaround: use PATH_INFO instead.

 Cache-busting Techniques
 Use POST instead of GET
 Use random strings and ? char in URL
 Omit Content-Length and Last-Modified
 Send explicit headers on Response
     Breaks back button
     Only as a last resort
         Cache-Control: max-age=0,no-cache,no-store
         Expires: PAST DATE
         Pragma: no-cache

 Books Web Caching and Replication (Addision Wesley)
 Web Caching (O'Reilly)

It's been a week since <a href="http://conferences.oreillynet.com/os2005/">OSCON</a> ended and I'm just beginning to recover. Very interesting things abound. 
The theme/tagline of this year's event was <q>The Future is Open.</q> Rumor is the runner-ups with <q>The David Hennemeier Hanson Show</q> and <q>With Ruby on Rails!</q> More on that in a bit though.
<a href="http://www.benhammersley.com/">Ben Hammersley</a> and I had quite a good turn out and response to our <a href="http://conferences.oreillynet.com/cs/os2005/view/e_sess/6687">45 Syndication Hacks in 45 minutes</a> presentation. While we were in one of the smaller presentation room its was filled to capacity throughout. You dread presenting on the last day, last session because attendance is significantly diminished as everyone is burnt-out or running off to catch their flight. Ironically I seem to draw this dubious honor each time I present. Perhaps there is a secret password I'm forgetting to say. Nevertheless for those who are interested in our flying-by-the-seat-of-our-pants slides they are <a href="http://conferences.oreillynet.com/presentations/os2005/ben_hammersley.pdf">here</a>.
I attended Brad Fitzpatrick's scalable Perl presentation. Quite an impressive setup they have developed. Some of the tools they've develop and released as open source – <a href="http://www.danga.com/memcached/">memcache</a> and <a href="http://www.danga.com/perlbal/">perlbal</a> – look quite intriguing stuff I hope to take a look at soon. The mention of a forthcoming distribution, Data::ObjectDriver, caught my eye. As I suspected it sounds like an open source version of MT's data persistence layer with various high-end scalability functions built in. Six Apart founder Ben Trott discusses the module <a href="http://btrott.typepad.com/typepad/2005/08/design_patterns.html">here</a>. Looking forward to that modules release. 
My sleeper pick was Yahoo's Michael Radwin's presentation on HTTP caching and cache busting. Highly useful information to anyone dealing with efficient distribution of content on the Web. Presentation hasn't been posted. My rough notes at the end of this post.
So Ruby on Rails and its creator David Hennemeier Hanson seemed to be everywhere at the conference. The good Mr. Hanson had 1 tutorial, 2 presentations and 1 keynote this year. Several other Ruby presentations were also on the bill and the discussion of many conversations heard through out the conference. There was even a <a href="http://flickr.com/photos/41715395@N00/31541062/">Ruby on Rael</a> sighting. The always insightful and humorous Danny O'Brien put it best when he noted that Ruby moved from being ignored to winning (thereby bypassing being laughed at and fighting) in about three weeks. I always worry when any thing gets hyped up into such a rich foamy lather because misuse and backlash is inevitable. Ruby on Rails does have a lot of nice things worth praise. 
The thing I like most about Rails is the thinking and philosophy behind the framework. The idea of joy and aesthetics is a novel one that gets lost or forgotten. I once felt that type of joy from MT and know it really can make a difference.
The following are my rough notes I took from <a href="http://conferences.oreillynet.com/cs/os2005/view/e_sess/6837">Extracting Rails from Basecamp</a> and <a href="http://conferences.oreillynet.com/cs/os2005/view/e_sess/7167">Secrets Behind Ruby on Rails</a>.
<blockquote>
Less people, more power Less money, more value Less resources, better use Less time, better time
Prove that an application is worth building the big thing (scaling up) for it.
We built half a product instead of a half-ass product.
Develop less software.
Too much enterprise. Too much focus on 99.999% uptime. Too much 100 man shops.
Liberate the good ideas. Change the language. Change the context. Retain the core insights.
<q>Call me shallow. I love beautiful code.</q> Aesthetics. Joy.
On APIs: I'll know when I see it. You have to feel an API to make it fit. Guessing the future is for fortune tellers.
Why Open Source? For entirely selfish reasons. Make others do the work. Bask in the glow of being a giver. What's there to loose?
Fear obscurity. You need a network to reap the effects.
Passion is infectious. The baseline of excitement. A conversation of success.
Scaling a culture. Early influx can bend you out of shape. Release not so early, then often. Set a viral example of kindness.
</blockquote>
<blockquote>
Getting rid of XML situps. Use conventions. 
<pre>
class Post < ActiveRecord::Base
belongs_to :weblog
has_many :comments
has_one :author, :class => <q>Person</q>
end
</pre>
No compilation. No deployment. No server restarts. No code generation.
Ruby: Introspection, Open classes, Execute code in class definitions.
Complete, integrated, and familiar stack. One language all the time.
The bucks stops here. We handle it all.
Responsible for the whole experience. Taking care of all the little things.
Flexibility is overrated. Its a bad notion. Trade flexibility for constraints are liberating.
</blockquote>
Of all the Rails knock-offs being discussed, this last point, that flexibility (in frameworks) is overrated, seems to be the most crucial and most overlooked attribute. (Are you listening Catalyst team? This is <a href="http://www.timaoutloud.org/archives/000409.html">what I meant</a>.) Phil Windley rocks out flexibility being overrated <a href="http://www.windley.com/archives/2005/08/flexibility_is.shtml">here</a>. I didn't get to attend the Rails tutorial, but <a href="http://www.windley.com/archives/2005/08/ruby_on_rails_o.shtml">Phil did</a>.
Notes on <a href="http://conferences.oreillynet.com/cs/os2005/view/e_sess/6630">Michael Radwin's HTTP Caching presentation</a>:
<pre>
Cache Publishing and Busting.

 (Dynamic Content)

 Frequently 
     HTML

 Occasionally
     CSS
     JavaScript

 Rarely/Never
     Images
     Flash
     PDF

 (Static Content)

 Top 5 Techniques.

 Use Cache-Control: private for personal content
     For use with dynamic content. 
     HTTP 1.1 Caching anything by default
     In practice, most caches avoid anything with:
         Cache-Control/Pragma header
         Cookie/Set-Cokkie header
         WWW-authenticate/Authorization
         POST/PUT
         302/307
         SSL content

     Cache-Control: private

     Shared caches bad for shared content
     Private caches perfectly OK
     Avoid personalization leakage.

 Images Never Expire
     Dictate that images once published never change
         Set Expires header 10 years in the future
     Use news names for new versions
     Tradeoffs
         More difficult for designers
         Faster user experience, bandwidth savings

     mod_expires
     ExpiresActive on
     ExpiresByType image/gif A315360000 # 10 years
     ExpiresByType image/jpg A315360000

     mod_headers provides a HTTP 1.1 solution

     mod_images_never_expire - Never even hits the file system 
     when an if-Modified header is sent.

 Cookie-free TLD for static content
     A seperate domain name for your static content (like images) 
       cuts down on the size of the requests coming from a cookie 
       header being inserted in every request.
     Many proxies are more likely to not cache a file to avoid 
       personalized data leaks.

 Use Apache defaults for occasionally changing static content

 Use randon tags in URL for accurate hit metering or 
   very sensitive content.
     Convert public shared proxy caches into private caches
     Without breaking real private (browser) caches
     (Missed last point)

     (Missed more here.)
     Return 302 to highly cacheable images file
     Counts 302s as hits

     Does not require modifying HTTP headers
         No need for Pragma: no-cache or Expires
         Doesn&#39;t break the back button
     Browser history &amp; visited-link highlighting
         Javascript timestamps/random numbers
             Easy to implement
             Breaks visited link highlighting
         Session or Persistent ID preserves history
             A little harder to implement

     User expectation: Back button works instantly
         Private caches normally enable this behavior
     Aggressive cache-busting breaks back button
         Server sends Pragma: no-cache or Expires in past
         Browser must re-visit server to re-fetch page
         Hitting network much slower than hitting disk
    (one more)

 Pro-Caching Techniques
 Cache-Control: max-age=&lt;bignum&gt;
 Expires: &lt;10 years into future&gt;
 Generate <q>static content</q> headers
     Content-Length
     Last-modified, ETag
 Avoid cgi-bin, cgi, &quot;? in URLs
     Some proxies (e.g.Squid) won&#39;t cache
     Workaround: use PATH_INFO instead.

 Cache-busting Techniques
 Use POST instead of GET
 Use random strings and ? char in URL
 Omit Content-Length and Last-Modified
 Send explicit headers on Response
     Breaks back button
     Only as a last resort
         Cache-Control: max-age=0,no-cache,no-store
         Expires: PAST DATE
         Pragma: no-cache

 Books Web Caching and Replication (Addision Wesley)
 Web Caching (O&#39;Reilly)
</pre>

Categories:

No TrackBacks

Search

About this Entry

Categories

Monthly Archives

Pages