Empty Thoughts

There’s been a lot of commotion over the recent fork of the Pidgin IM client by the folks behind FunPidgin. The community at large has grown accustomed to the idea that forking is a “bad thing.” On the other hand the use of distributed version control systems (DVCS), like Git, Mercurial, and Bazaar, have made the idea of forking a project something that is part of the standard process. The fact that there is an “official” repository is one of community agreement and not anything dictated by the software. Large open source projects are investigating how to gain the benefits of a DVCS while still maintaining control of their code base. Some, like the Ruby on Rails project, have decided recently to make the jump. I am encouraged by this, and I’ve been watching the IRC discussions in #github pretty closely as they attempt to figure out the logistics of working in a distributed yet overall centralized fashion.

So the real question in my mind is why do we, as a community, have a general distaste for forking? A lot of people will say because it divides the resources and the end result is two half-assed projects instead of something that could adequately compete against closed source solutions. Although, that may be the case in some situations, it certainly doesn’t have to be the case. The drive for providing a permissive license is so that we can all benefit off the work that came before us and help propel it to that next level. In a lot of ways that is what forking is all about. If we look at an analogous situation in the research world, it is dependent on the idea of forking research. Each project takes prior research and throws something new into the mix, and moves it along to the next level, for the benefit of all. Why do we not see it the same way in the software world?

What is interesting to me is that we seem to have no problem of forking ideas if it is to put them on another platform. Consider blogging software. Every time a new framework / language comes out there are multiple development efforts to do a WordPress clone, or a Typo clone, etc… on the new platform. The same holds true for Content Management Systems, and a host of other types of applications. We could argue that those efforts do not work to help strengthen the open source offering. But I feel differently. I think competition and choice are beneficial to the community at large. If WordPress provides integrated Flickr support, then Mephisto feels compelled to add Flickr and Magnolia support. We also can not discount the learning opportunities that these types of forks provide. In the end we all win.

I think one of the real reasons that many are uncomfortable with forking is because because the most successful open source examples we have to look at, projects like Linux, Gnome, or Rails have all been these monolithic efforts driven by a single individual (Linus Torvalds, Miguel de Icaza, or David Heinemeier Hansson). The success of those projects in large part are a result of the charisma, intelligence, and management of those individuals. This has left us with the impression that this is how it should be done. While it has been clearly a successful approach it is not the only approach. There have been truly community driven projects like PostgreSQL that have been hugely successful, with no one individual clearly at the helm.

Clearly a lot of open source dictators of the day have no interest in seeing their projects forked. That has direct impact on their ability to render influence in the community, and works to dilute their personal brand. Quite honestly this is a real issue because this influential capital translates into real dollars for these individuals. That said, where I have seen forking or competitive offerings the end result is that both projects benefit. Most recently I feel that the Merb project has forced Ruby on Rails to get after it and address some of the performance issues. Even if Merb has no impact at all on Ruby on Rails, for a lot of people it will be exactly what they are looking for in a framework. That does not make the Merb approach correct and the Ruby on Rails approach incorrect, just different.

I am actually quite excited that this issue is being brought to the forefront by the DVCS systems. I am also eager to see the forking of more projects. There is no requirement that says the things I’m interested in seeing in a blog platform needs to be the same things that you are interested in seeing. There is room for both of our ideas, whether we work together or separately. Some people will be compelled by my offerings and some by others. In my opinion the community benefits from this plethora of ideas and options. This is a “good thing.”

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.

For some time I’ve had problems with the blog. Sure I could make lots of jokes about it being on Rails and unable to scale, but I leave all that as an exercise for the reader. The real issue has been a problem with fcgid crapping out about every four minutes. Well truthfully, almost every time I post an update and cache needs to be invalidated. At any rate I’ve been wanting to give nginx a try and so I finally found the time to test things out and get it running. I’m now running on nginx proxying to a pack of Mongrels. It’s not crashing anymore—so far so good. Let me know if you experience problems.

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.

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)
end

It’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.