Meditations on programming, startups, and technology
New Relic

Losing my blog title (oh no, I’ve said too much…)

Keen observers amongst my readers may have noticed that I’ve subtly renamed my blog. It used to be “Zen and the Art of Ruby Programming” and now it just reads “Zen and the Art of Programming”. Perhaps you also noticed that my Ruby logo has been replaced with a cuter one created for the Snakes and Rubies conference, which was held about two years ago at DePaul University (by the way, I don’t know who the creator of that great logo is, but really hope he/she doesn’t mind me using it. If anyone knows who designed it, please let me know so that I can fully give the right person credit for it).

For several months now I’ve been pondering this decision before finally taking the name change plunge. Don’t worry, I’m not going all good ol’ Zed on you. I like Ruby as much as I ever did, I think that in the past four years we have come a long way and I see a bright future for Ruby. My decision has little to do with Ruby or Rails. No Ruby, it’s not you, it’s me.

There are a few reasons beyond my decision:

  1. I noticed that, consciously or not, having the word Ruby in the title conditioned me. As Walt Whitman put it, “I am large, I contain multitudes” and I don’t like to limit myself to simply talking about Ruby and Rails. I use and experiment with various programming languages and, especially on a blog located at, I want to feel free to talk about any language that I please – even if chances are that this blog will always be mostly about Ruby.
  2. The current title paints a more accurate picture of what this site is all about to my readers. This blog is not only about Ruby, nor is it exclusively about programming languages, so I prefer not to advertise it as such. I’ve seen quite a few comments along the lines of, “oh yeah, Zen and the Art of Ruby Programming”, whenever I blogged about Django, DB2 or anything else that wasn’t strictly Ruby related. Not that I care too much about this type of comment, but if I’m (supposed) to have a title at all, it should at least be somewhat factual.
  3. A strongly Ruby-centric blog title may give new readers the false impression that the author of the posts is a highly biased advocate of Ruby. Those who follow my writing, know I value critical thinking and always try to be reasonable in my arguments. I have no qualms with admitting Ruby’s faults, if the occasion warrants doing so. I don’t have a hidden agenda, strive for intellectual honesty, and would prefer to have my opinions valued on the basis of their merits, rather than on a label that’s been given to my blog – or to me. There will always be mindless critics, but I’ve seen far too many harsh comments based on the fact that people jumped to assumptions because they’re sick of “Rails hype blogs”, rather taking the time to actually read what I had to say. I never set out to make everyone happy, but what I just mentioned is definitely a point that I took into consideration when leaning towards the final blog name decision.
  4. I will confess that lately I’ve been more into Python and Django, so chances are that I’ll start giving them some serious coverage here.

What’s in a name? A lot, I think. While there may be a slight loss of “branding” and some negative effects when it comes to SEO, I don’t really mind, and it’s a risk that I’m willing to take. I want to explore the possibility of “Zen and the Art of Programming”, even if proves to be a mistake.

If you enjoyed this post, then make sure you subscribe to my Newsletter and/or Feed.

receive my posts by email

5 Responses to “Losing my blog title (oh no, I’ve said too much…)”

  1. Jeff Self says:

    I’m glad that you are giving more attention to Django and Python. I know you have released a Python DB2 driver which works with SQLAlchemy but is there any chance you and your team will write one for Django?

  2. Thanks Jeff. The API team (which currently maintains all the dynamic language APIs for DB2) considers the Django adapter a priority. Due to IBM’s strict rules in terms of open source participation though, the developers can’t simply look at the code of the other adapters (not even the dummy one) and adapt it for DB2. Therefore, in their case, the lack of a public spec, that outlines method by method the requirements for any new Django ORM adapters, is the biggest obstacle. If such a document was freely published on the web (without restrictions), the API team could come up with a Django adapter for CPython and for Jython in a short amount of time. Heck, I wouldn’t mind implementing it myself on my own time and then passing the code onto them if this meant having a Django adapter sooner. But even if I’m not in their team, I’m still an IBMer and as such I have to follow the same rules, therefore I can’t create the specs or look at the other adapters myself. IBM will most likely find a lawyer-friendly way to get the API team a spec, without breaking any internal rules. This may take some time and having the community produce an open source document instead, would probably take much less time and would also be quite beneficial for those who will attempt to write further adapters in the future.

  3. Wow, it took you the end of the post, and a paragraph beginning with “I will conffess”, but in the end you managed to spell the Python word. Come on, there’s no guilt in that. ;-P

    Instead, there *is* guilt in suffocating red tape. I worked for a big corporation *once*: today I’m not going near anything that has more than 50 employees.

  4. Masci says:

    My aggregator “shadowed” your changes so I didn’t notice at all! Glad to see you writing point 4), good luck for the project!

  5. JJ says:

    This should post as a new challenge for you. Your changing of name tells us of quite how you want to differentiate and make special your specialization.

Leave a Reply

I sincerely welcome and appreciate your comments, whether in agreement or dissenting with my article. However, trolling will not be tolerated. Comments are automatically closed 15 days after the publication of each article.

Copyright © 2005-2014 Antonio Cangiano. All rights reserved.