This will be my first talk at a major conference.
The following screed was originally published at gist.github.com/54177 but has been copied here for posterity and because people keep asking me on IRC for the original link (it must be hard to find on gist for some reason).
What I’d like to do is run Firefox/Gecko on the server. It would load up the report, render it with the print stylesheet and then output the PDF. The concept is not unlike khtml2png or webkit2png but instead of outputting a raster image, it would output a PDF: gecko2pdf, if you will.
On Dreamhost freaking out because they can’t get Rails deployed reliably.
It’s not Rails’s problem.
Charles Nutter on the possibility of a Rails support announcement in February 2007.
Yehuda lays out some of the history and rationale behind Rubygems’s multi-package-version design and also takes a look at how a few recent tools (Bundler, Rip, rvm, etc.) are using different approaches to develop concepts around multiple “environments”.
I’ve never been a fan of Rubygems multi-versioned, directory-per-package approach to organizing packages. There’s a few different reasons, but mostly it forces a lot of unnecessary complexity into runtime that could (I think) be handled more simply at install time. I do like the convenience of installing a bunch of packages into a single Rubygems environment without having to think about it, but those benefits are outweighed by the subtle differences in runtime behavior, some of which can be extremely annoying (e.g., “already activated” errors). I’d rather be aware of and be forced to deal with those issues at install time. It’s great to see so much experimentation on new tools and alternative approaches.
Interesting use of node.js as a sort of HTTP reverse proxy. It uses redis based queues to communicate with backends instead of establishing a direct socket connection and doing HTTP:
This spike uses node to put messages into a (redis) queue. Ruby background workers read from the queue, process the requests, and respond on a different queue. When node receives the response from the background worker, it sends the response back to the waiting user.
I assume this adds a not insignificant amount of latency to each request but would also make possible a bunch of long-running connection features. For example, the response (or portions of the response) could be delivered from separate worker processes. This style of architecture, where the client connection isn’t tied to backend web process, looks promising. The nginx_http_push_module is another example that gives the same types of benefits.
Looks like Aman and Joe knocked one out of the park with this presentation on Ruby’s GC:

I wish RailsLab or PeepCode or somebody would team up with those guys and do a series of screencasts. You can learn a ton just by watching over their shoulder while they work.
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.
Really excited to see Chris release the shiny new Redis-based work queue that’s been running GitHub for the past couple of months:
It boils down to this: GitHub is a warzone. We are constantly overloaded and rely very, very heavily on our queue. If it’s backed up, we need to know why. We need to know if we can fix it. We need workers to not get stuck and we need to know when they are stuck. We need to see what the queue is doing. We need to see what jobs have failed. We need stats: how long are workers living, how many jobs are they processing, how many jobs have been processed total, how many errors have there been, are errors being repeated, did a deploy introduce a new one?
I’m still getting my feet wet with the jobs system but I can’t wait to get my hands dirty in the guts of this thing.
Nick Quaranto shows why you need to start thinking about bundler.
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.
Kudos to everyone hacking on Rails 3. This is a great demonstration of how far they’ve come in making it possible to pull in only the bits you need, without gem hell and activesupport spewing all over everything. Also, if you have an opportunity to see Yehuda’s “shit that’s happening in Rails 3” presentation, take it.
This is an interesting idea. Publishing gems on rubyforge is complicated but the gem source is everywhere and gems have sane file names. Publishing gems on github is dead simple but the filenames include a username prefix, which is just kind of weird. Publishing gems to gemcutter is simple enough and the gems have sane filenames. This could work.
Nice short list of PostgreSQL features everyone should be thinking about when choosing between MySQL and postgres (and each with a link to more detailed information). Then a wrap up that talks a bit about the licensing situation:
One of the major reasons for trying out PostgreSQL, regardless of it’s feature set, is it’s license and community. This can’t be more true these days, when MySQL AB was consumed by Sun Microsystems, which in turn recently got acquired by Oracle. While I doubt that the product itself may die off, the fact that the copyright to the code, and the direction of the database system itself may and will be dictated by a company like Oracle is a deal breaker for me.
I suppose it’s a bit on the FUD side but those are my feelings exactly.
Koz on Delayed::Job’s lesser-known send_later and handle_asynchronously methods. Sweeet.
Adam takes a look at how long requests and backlog interact. The sleep example runs concurrently under Mongrel but Thin and WEBrick will backlog.
“… learn how to use httperf load testing with sessions, how to automate our httperf testing using autobench, how to graph the results from autobench, and lastly we talk briefly about a few other load testing tools you might want to be aware of.”
This is the second time Gregg has beat me to a great screencast :)
There’s a nice combination of old and new concepts in here.
mnot on how to evaluate different proxy cache options for your needs.
Great talk from this year’s gogaruca conference. Anything that starts with a rail against the belief that tools can have mystical scaling powers is going to end up being a good talk :)
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 :)
Here’s the slides from my RailsConf 2009 presentation on HTTP caching. I doubt the general info will make much sense without me talking over it but the diagrams should be fairly useful.
I’ve been staring at this screen for two sleepless weeks now. Really glad to have it wrapped. James Lindenbaum (CEO/founder/bad-ass) did most of the conceptual design work. seaofclouds did the fucking amazing illustrations and took the design to completion. Pedro Belo did the HTML/JavaScript and server side stuff. Definitely one of the best teams I’ve worked on.
Remi’s kick ass screencast on deploying to Heroku.
Great ideas for tweaking Ruby’s GC after applying Stefan’s Kaes’s GC patch. By the way, that patch has been an option on the ruby port in FreeBSD for years. It works. Apply it.
Get it while it’s hot.
Well said. It appears PHP’s culture of stupidity isn’t limited to technology. What a bunch of assholes.
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!
Things are starting to get interesting around here. James pulled together some (fucking sexy) high level architectural diagrams and annotated them just so. We can start talking about what we’re up to a bit more now that this is out. I’m jazzed.
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.
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.
“Not to mention ‘overrideable’ is not a real word.”
We gave the Sinatra website a major face lift. Check it out. Don’t leave without subscribing to the feed.
True! A lot of cargo-cult types get this wrong.
Finally, a sane looking sanitization lib that doesn’t try to do too much.
A much more sober but constructive take on the plan to merge Rails and Merb.
Mailing list for Rack::Cache users and hackers. Come on in, the water’s warm.
“Built with Rack Middleware ONLY (Rails 4.0)”
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.
Bad-ass ActiveRecord extension that does read-through and write-through caching to memcached in a way that’s fairly transparent. This is one of the strategies the Twitter folks put in place recently to improve their response time and availability.
You’ve got to be kidding me.
So, I got an email yesterday disagreeing with my remark about HTTP caching being wildly under-appreciated in the Ruby web community. I felt bad, a little. Then I read this article (posted the day after my remark), which talks about Scribd moving to a Squid reverse proxy setup to front their Rails deployments:
“But there was a problem – no one uses caching proxies in 2008 :–) So, we’ve got an idea – why can’t we place such a server in front of our application and make it cache content for all users in the world?”
The fact that Scribd had to “have this idea” on their own and had not previously been exposed to a ton of literature/tools on reverse proxy / gateway caching is completely fucking unacceptable. I’m back to agreeing with myself.
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.
Interesting Rails plugin from Viget Labs that adds ActiveRecord attribute helpers for various humane markup languages. The markdown variation supports both rdiscount and rpegmarkdown. Cool. Not sure how I missed it when it was released in August.
So I’ve been skeptical about Merb but I really like the world-view Ezra puts forth here: core framework code should be simple (no/little meta-programming), fast is good, Rack is awesome, etc.
Bill Burcham applies the technique of making form controls inherit style from their container in the Air Budd Form Builder Rails plugin. Cool.
Adam Wiggins on Sinatra’s blasphemous approach to controllers and routing. AKA: the thing that makes Sinatra my web layer of choice (well, that and throw :halt).
Still too much work but it’s nice to see some support for conditional GET making its way into the framework.
“Jim Meyer, manager of LED says that Rails scales like any other web application: ‘That is to say you need to take into account all the components from the moment the request is received at the load balancer all the way down and all the way back again.’”
If you move the slides quickly, it feels a bit like playing Desktop Tower Defense.
Support for HTML4/HTML5 output, more control over whitespace, option for implicit HTML encoding, and now faster than ERB.
“I still haven’t found anyone who knows how you implement Scaling in a language, so I guess that LRM will never have it… Anyone who care to enlighten me, please send me a detailed email with an implementation of Scaling.”
Constantly updates the the process title ($0) with something like: “mongrel_rails [10010/2/358]: handling 127.0.0.1: HEAD /feed/calendar/global/91/6de4”. Let’s you monitor backends with ps and top.
A “Hello World” Rails webapp in fewer LOC than a Java console app that System.out.println(“Hello World”). The routes and controller DSLs look pretty interesting as well.
Nice Ruby assertion library that’s block based. Shows block contents when the assertion fails. Much cleaner than Test::Unit assertions and without the retarded RSpec non-sense. This really ought to be rolled into the stdlib Test::Unit, IMO.
Evan Weaver: “These leaks tend to grow slowly. Your Rails app definitely has this kind of leak, especially if it uses the ActiveRecord session store.”
Peter Cooper scratches the deployment problem itch.
Dion Almaer sits down with Yegge to talk about his JavaScript/Rails port. Nice one-on-one video, candid, and thick in technical detail.
Ian takes a look at some of the attributes of PHP’s deployment model, why they work so well (for PHP), and why other environments have such a hard time duplicating them.
“The constraints, the instability, and the unpredictability of a shared hosting environment are a big part of the reason why the web hosting business is moving towards virtualization everywhere you look. Big kids need their own sandboxes to play in.”
“Ousted ActionWebService from Rails 2.0 ” :)
something to dig into during a 1 hour conference call or whatever …
“… Rails has picked a side in the SOAP vs REST debate. Unless you absolutely have to use SOAP for integration purposes, we strongly discourage you from doing so. As a naturally extension of that, we’ve pulled ActionWebService from the default bundle.”
Checks pre-Rails 2.0 apps for compatibility.
Brings ActiveRecord’s transactions toward sanity and adds savepoints. The methods added to Object must go! — transaction, commit!, and rollback! will clash with existing libraries. e.g., PDF::Writer and Transaction::Simple.
“Every time some Rails fanboy starts peddling their hype, the approved thing to do is to respond with Erlang.” – Brilliant idea! That will bring some real substance to the argument.
“What matters a lot more than choice of programming language is the ability to get the project done, meaning tested and correct and launched. Apparently for Derek, PHP is the way to get that done, and Rails ain’t.” — it really is that simple. Period.
“But at every step, it seemed our needs clashed with Rails’ preferences. (Like trying to turn a train into a boat. It’s do-able with a lot of glue. But it’s damn hard. And certainly makes you ask why you’re really doing this.)”
“Maybe I’ll start to believe when they start promoting Ruby on Rails at JavaOne, as opposed to promoting JRuby on Rails at RailsConf.”
Comprehensive look at common Rails security concerns with links out to in-depth articles.
“I’m not really much into evangelizing Ruby and Rails much nowadays. You know, since we won, I have to admit that it became boring and besides the point.” :)
“‘Why are they doing all this?’, that’s a common concern with most Ruby folks … A Sun that’s heavily involved with Rails on the software side is a Sun that’s much better positioned to sell loads of hardware …”
Slides from the presentation Roy will be giving in about an hour at RailsConf Europe.
“We’re not trying to bend Ruby on Rails to fit the enterprise, we’re encouraging enterprises to bend to Ruby on Rails,” he said. “Come if you like it, stay away if you don’t.”
I must say, I’m a bit bummed that we’re having this conversation at all.
Pppkkkeeeewwwww.. The happy universe explodes. This is turning into one hell of a discussion.
The entire Twitter Scaling Problems conversation in one place.
I’ve been using this technique for some time with great success. Oh, and this site’s design is bordering on perfection.
subscribed
Interesting concept. I’ll have to check this out once it comes out of “pre-pre-pre alpha” (which doesn’t really make sense, btw. There’s nothing more alpha than alpha).
The JRuby guys are real close to 100% passing Rails' unit tests. I think I’m going to sign up for PostgreSQL testing/hacking. What are you doing?
That’s sales growth not sales.
“All you have to do is change the internal processing, add 200 more methods to the HTTP parser, serve Bittorrent over Ethernet, and have it save Korean orphans while eating a Mango in the back seat of an El Camino driven by twenty midget clowns.”
“I would rather take an easily modifiable, open platform that I can make do what I need in a specific environment.”
Wherein the author lists 8 reasons (maybe 3 of which are approaching objective or even valid) and also spells Adrian’s name wrong: “Adrian Zolovaty”. Ruby/Python flame-bait is exactly what we need.
I’m starting to “get it” now… Makes a ton of sense.
I’m going to have to jump all over this.
Animated GIFs designed to indicate your site is doing something…
Perdy..
I’m going to see about moving my weblog to this..