I just happened across the Passenger website. Passenger claims to provide “Easy and robust deployment of Ruby on Rails applications on Apache webservers.” The metric graphs show it performing as well as Mongrel and Thin. It will be interesting to see how this plays out in community and the hosting companies. In true Ruby on Rails fashion there’s screencasts, lots of pretty colors, big fonts, and rounded corners everywhere. Hopefully there’s some there there.
A few weeks ago I stumbled across Heroku, an online IDE for instant Rails development. It provides editing, sharing, and collaborating of projects, as well as the ability to import and export projects.
Heroku is an amazing implementation of technology and innovative in so many ways. Even if you’re not a Rails developer you will appreciate the beauty of Heroku.
Hmm, what would it take to get something like this for Django?
After reading Zed A. Shaw’s rant, Rails Is A Ghetto, I was a bit surprised. I’ve met Zed on a couple of occasions and each time he was always pleasant and kind.
As a result I decided I would dig further into Mr. Shaw’s background and surprisingly I discovered this letter.
It’s amazing how much things have stayed the same. :)
Fabio Akita (not the Fabio) has an excellent interview with Adrian Holovaty, creator of the Django Framework.
I’ve been following Akita’s work for some time and I’ve enjoyed it immensely. Recently he reproduced the original Rails screencast, to update it. I also enjoyed his two-part interview with Avi Bryant.
Even if you’re not doing Rails stuff, Akita’s feed is a Must Subscribe.
Mike Clark just announced the release of his new Beta book Advanced Rails Recipes. Although it is a beta book, it already contains 42 recipes, and by the time the book is complete there should be 70+ available.
Unlike the first Rails Recipes book, written primarily by Chad Fowler, this books is collection of the best tips and tricks from the Rails community at large. Mike Clark contributed, reviewed, edited, and consolidated them into a great collection of the most up-to-date Rails information available.
For those of you that do not know him, Mike Clark is an independent consultant, author, trainer, and programmer. I got to know Mike and his lovely wife Nicole through their excellent training program at The Pragmatic Studio.
I just received my PDF copy and plan to make my way through it over the next week or two. So many new books, so little time…
Bob Follek wrote an interesting post asking the question Why The h Can’t Rails Escape HTML Automatically?.
As many of you know, Django recently introduced an enhancement that automatically auto-escapes all template variables. It’s a very elegant solution and something that I’m really excited about. (Although I could do without the plethora of questions on IRC that begin with “Why suddenly are all my HTML attributes appearing as > and <.) The really cool thing is the amount of flexibility built into the auto-escaping architecture. Auto-escaping can be turned off per-site, per-template level or per-variable level. This gives the developer total control, while still maintaining a safety by design stance.
What’s even more interesting is the comments in Simon Willison’s reference to the aforementioned post. To be more precise the interesting part is the actual comment banter that takes place between koz, Michael Koziarski, a Rails core developer and Simon. Read the comments to get all the details, but essentially koz explains that the difficulty is in the fact that all of the Rails helpers, such as link_to would need to be able to not be escaped. It is a difficult problem but the same problem existed for Django with some of the tags and template filters, and they handled it with a flag that let the render engine know how things should be handled.
I got involved with Rails in early 2005 and I remain involved somewhat with the Rails community, although not as engrossed as I once was. The Rails developer community has been asking for this feature for as long as I can remember. Some will argue that a framework can’t solve lack of developer competence, but the reality is that our frameworks and tools should be safe by design. Security must be something that is designed into the product and not as an afterthought.
Along the same vein as this thinking, it has bugged me for a while now that the database vendors do not make any effort to stop sql injection attacks. They could be seriously thwarted by setting a default database option that does not allow more than a single transaction to be executed at a time. Of course they would need an option to turn this off as needed, but this would certainly help correct the problem in a big way.
Regarding the Rails issue, I agree with koz that it’s not an easy problem to solve, especially with a framework like Rails that is so far along in development. But it’s also not an impossible thing to address either. The auto-escaping Rails plugin looks interesting and I hope that as the Rails framework moves forward they will adopt a solution such as that to deal with this problem effectively. My guess is that it probably took no more than about 40 – 60 hours of development time to get it implemented in Django, although that’s just an assumption on my part.
As an aside one thing that has always impressed me with Michael Koziarski is that although he is quick to defend Rails or set the record straight, he always does so with grace. This is certainly something that a lot of individuals involved in open-source projects could learn from.
The Beast is getting green eggs and spam
There’s been some buzz lately about Hobo, a plugin extension to the Rails framework that makes it easy to do rapid prototyping of web applications. You can find out about all of the features at the HoboCentral website. One exciting feature is the implementation of DRYML, a way of drying up your views and providing extendable tag libraries.
Check out the screencasts. They’re very well done. I haven’t been this stunned by a screencast since I saw the original DHH Rails screencast. It’s exciting times.
I was trying to spec out a few of my controllers that had actions on them requiring authentication. After jumping through many mind hoops to figure out how to stub them out properly I asked the RSpec-Users list and received this solution from Graeme Nelson:
def mock_user_authentication(allow_user_to_pass=true)
controller.stub!(:login_required).and_return(allow_user_to_pass)
endIt’s elegantly simple and works well. I’m still fumbling around with this RSpec stuff and did not realize I could stub out a method directly on the controller. This has cleared up a big missing piece in my thinking.
Ryan Bates provides an excellent collection of Ruby on Rails screencasts for free. If you have a couple of minutes, literally, please check out what he’s put together.
Some time ago I had envisioned producing something similar, but in no way could I have even come close to this. Ryan really nails it, with high production quality and keeping it concise. Show him some love.