Real HTTP caching for Ruby web apps.
Using Rack::Cache as an example. Nice!
We pushed out a Sinatra 1.0 pre-release. The FAQ includes some info on what the 1.0 release means and how to prepare for it.
Lots of needed fixes and some new features in this release, including new Config, ETag, Sendfile, and Logger middlewares, Carl and Yehuda’s rackup to Rack::Server conversion, multipart fixes, and a bunch of optimizations by Eric Wong.
Huge props to Josh Peek for putting his head down man'ing the patch queue on this one.
Maintenance release that fixes a bunch of issues under Ruby 1.9, some multipart form problems, and various other minor bugs.
The CodeRack Rack middleware competition has begun. All entries get a $30 credit from Heroku and the top three pieces of middleware get special prizes (to be announced). You should submit something. I want to see it :)
This is how I am using Rack::Cache, Sinatra, and CouchDB … Sweet ascii diagram there. I’ve seen this ETag chaining technique twice just this week. The other one is gemcutter. They store gems in S3 and pass the S3 provided ETag along in their responses, so it’s like the web app is more of an intermediary sometimes. Weird and cool and interesting.
Jacob Kaplan-Moss somehow pulls a bunch of interesting contemporary web development issues into a coherent essay. This bit on what happens when web apps begin to mature is especially well stated:
This is an impossible situation for framework developers: by optimizing for a quick start, by focusing on common needs, we’re essentially guaranteeing future failure. Remember the “Rails doesn’t scale” pseudo-controversy last year? I guarantee it’s only a matter of time until there’s an angry “Django FAIL” moment.
Frameworks ought to gracefully fade away as you replace them, bit by bit, with domain-specific code. (This is what I meant, above, that inter-op is also a scaling issue.) Right now, they don’t.
I wish more people would write about their experiences growing out of the general purpose web framework. It’s a totally natural thing but most people seem hesitant to talk about it because it’s interpreted as an attack on the framework or community.
Unicorn is a newish Rack-based HTTP server that’s kinda sorta like Mongrel but comes packed with some insane process management features. The main link is to the SIGNALS file, which documents the master/worker process model, supported signals, process replacement, failover, etc. See the README for a high level description of features.
This link brought to you by @defunkt, who explained Unicorn’s unique approach (repeatedly) over the course of a week.
Amazing! I put Ben under the table that night. Tucked him into bed and gave him a kiss.
We’ve been getting a decent amount of PR-ish type coverage since the commercial launch but I still say blog posts like these are infinitely more interesting:
Remember when microwaves first hit the scene and people couldn’t believe how fast they could ‘deploy’ a meal? Yah me either, but the microwave changed the game big time.
And, unlike the microwave, Heroku doesn’t make your apps taste like cardboard :)
Coda on why Rack has had so much success within the Ruby community and modeling projects after it in the future. I couldn’t agree more.
Christian Neukirchen’s RailsConf 2009 wrap up. I had a pretty amazing time at the conference but sharing a Hookah with Chris was definitely a highlight.
We made it.
Matthias Georgi’s framework for building DAV servers in Ruby with Rack. Could make building apps that mount into a local filesystem quite simple.
Get it while it’s hot.
Nice. This is very similar to the Sinatra::Test module but with a few additional features (i.e., the session/cookiejar thingy). If this gets traction (and it will), we’ll deprecate Sinatra::Test and recommend people use Rack::Test instead.
I worked on this a bit. Jazzed to see it announced. Actually, they pretty much had everything working when I got there. I wrote some docs and tightened things up a bit is all.
Now go deploy something – it’s free!
Harry Vangberg put together a Twitter relay bot in #sinatra (nick: nancie) so a bunch of the cool cats there are keeping the @sinatra twitter feed lit up with a stream links, tips, and announcements.
I haven’t actually had a chance to watch this yet but I’m sure it’s great if it builds on the talk Gregg gave at acts_as_conference 2009. Also, I love this slide: “Reverse Proxy Caches – WTF?” :)
The RailsEnvy guys presented on a bunch of recent innovations in the Ruby/Rails community in their acts_as_conference 2009 talk. Go to 24:00 where Gregg gives a really tremendous overview of using Rack::Cache, the benefits of HTTP caching in general, and how to use all of this stuff in Rails 2.3.
Huge thanks to christian for getting this up. I’ve been meaning to get something on the Rack::Cache site for some time now.
This has been sitting in the back of my brain for months now. I finally got a chance to throw something together last night:
Shotgun is an automatic reloading version of the rackup command that’s shipped with Rack. It can be used as an alternative to the complex reloading logic provided by web frameworks or in environments that don’t support application reloading.
The shotgun command starts one of Rack’s supported servers (e.g., mongrel, thin, webrick) and listens for requests but does not load any part of the actual application. Each time a request is received, it forks, loads the application in the child process, processes the request, and exits the child process. The result is clean, application-wide reloading of all source files and templates on each request.
Another interesting use of Rack middleware.
Geoffrey Grosenbach interviewed me yesterday for the Ruby on Rails podcast. We had a nice chat about Python/WSGI, Rack, Sinatra, Rack::Cache, Heroku, and other random stuff.
I started full time with Heroku last Wednesday. This is why.
This is one the amazing benefits of having an insanely simple but well defined SPEC (Rack) around the edges of your library. It makes it trivial to hook things up in new and interesting ways.
We gave the Sinatra website a major face lift. Check it out. Don’t leave without subscribing to the feed.
The Prag’s have published two screencasts in a new series on Sinatra.
Magnus Holm disects a couple of implementations for parsing nested form parameters (e.g., “person[name]=Joe&person[zip]=55555”) in Ruby. _why’s is the most interesting (as always). We just added this to Sinatra and I’m fairly confident we’ll see something like it land in Rack before 1.0.
Tanner Burson talks about one of the larger accomplishments of the Sinatra 0.9.0 release. We definitely need more docs on using Sinatra in this fashion.
Quick presentation on Rack by Dan Webb. Covers a lot in eight minutes.
Matt Todd did a nice presentation on Rack to the Atlanta Ruby Group (ATLRUG) and they were nice enough to put video of the slides + audio of Matt’s narration online.
Christoffer Sawicki has started in on a partial implementation of ESI (Edge Side Includes) as a Rack middleware component. Put something like this in front of Rack::Cache and things get real interesting real fast :)
“Built with Rack Middleware ONLY (Rails 4.0)”
Jon Crosby’s RESTful JSON-based data store with OpenID and OAuth support. It does versioning and produces HTTP cache friendly responses all in a Rack middleware component. Jon’s been working on this for some time and it shows in the code and docs. Awesome.
David Heinemeier Hansson: “Rails Edge adopted Rack a while back and we’ve been exploring ways to expose that better. The first thing we did was to make it really easy to hook up any piece of Rack middleware in front of a Rails request. In your config/environment.rb file, you can do: config.middlewares.use(Rack::Cache, :verbose => true)”
Oh hell yes.
Rails riding on Rack is going to be a big deal.
It’s really starting to come together, isn’t it?
Adam Wiggins and Blake Mizerany’s presentation on Sinatra and RestClient.
Pratik continues his series on Rack with a deep dive into Rack::Builder.
Pratik’s first in a series of pieces on Rack: how it came to be, why you need to understand it, along with some simple examples. Future installments will cover Rack::Builder and Middleware.
Sebastien Auvray covers Rack::Cache at InfoQ. Thanks!
Interesting approach to setting cache related headers using a Rack middleware component.
Ryan King nails it.
Pretty good introduction to building pieces of Rack middleware and using Rack::Builder.
Much nicer, IMO. I’m interested to see if someone can get Rails + Rack::Cache working together so that you can maximize the benefits of generating these validators.