DB2 support for Django 1.2 is here
The latest release of the IBM Adapter for Django now supports Django 1.2. Aside from enabling you to use the most recent version of Django, this release adds a few new goodies into the mix, that I’m sure many will appreciate.
For example, IBM’s adapter (through the underlying DBI wrapper) now uses persistent connections, which are especially helpful when dealing with Django – as it lacks connection pooling. (Of course DB2 also has the Connection Concentrator to aid in reducing the usage of server resources and improving scalability.)
Furthermore, the adapter adds support for the DECIMAL datatype, a necessary feature when dealing with money and currencies. Various enhancements and bug fixes were included too; check them out on Google Groups.
As a reminder, DB2 Express-C is an absolutely free of charge version of DB2 and it’s production ready (not a toy version). You can download it from here. Take it for a spin, experiment – chances are you’ll like it. If you need a guide to getting started, be sure to check out this free e-book by my colleagues Raul, Ian, and Rav.
Enabling support for DB2 and Python/Django/SQLAlchemy on Mac OS X Snow Leopard
This is the Python version of a post I made about Ruby a few days ago.
Now that Mac OS X 10.6 is out, it’s time to leave the world of 32 bit computing behind. The pre-installed Python interpreter will run in 64 bit mode by default, so you may need to pay attention when installing some C-based eggs.
Assuming you have DB2 Express-C installed already, the ibm_db Python egg for DB2 can easily be installed by following these simple steps:
$ sudo -s
$ export IBM_DB_LIB=/Users/<username>/sqllib/lib64
$ export IBM_DB_DIR=/Users/<username>/sqllib
$ export ARCHFLAGS="-arch x86_64"
$ easy_install ibm_db
This will install the ibm_db C driver, and the ibm_db_dbi Python module that complies to the DB-API 2.0 specification.
You can verify that the installation was successful my running the following:
$ python
>>> import ibm_db
>>>
Now, for the Django adapter, install Django first (if you haven’t done so already):
$ sudo easy_install django
The Django adapter can then be installed as follows:
$ sudo easy_install ibm_db_django
Finally, if have installed SQLAlchemy and wish to install the DB2 adapter for it, run:
$ sudo easy_install ibm_db_sa
Please let me know if you encounter any issues, I’d be glad to help you.
Startup for sale on eBay (and it’s a great deal)
One of the best programmers I know is selling a web application on eBay, that he’s been developing and running for the past three years. Given the starting price and considering what one lucky person or company will walk away with, I must say, it’s an amazing deal. I’m writing about his auction here so that I can help it get the proper exposure it deserves and because I think it’s an incredible bargain for anyone who is interested!
BlogBabel, the aforementioned site/web app, is a blog indexing and aggregation service that began in 2006. Amongst its features are the ability to detect and show the most popular blog discussions, weekly posts, books, videos, and even popular blog entries based on their location (through geotagging). It also features leaderboards of the most popular blogs.
Its codebase uses Python and Django, and consists of 27,359 physical lines of code (roughly equivalent to 6.46 person-years, according to sloccount). The R&D alone makes this application worthwhile to an interested party.
At this stage, BlogBabel has an Italian interface (located at it.blogbabel.com) and aggregates almost 15,000 Italian blogs and 5 million posts. Changing the interface to make it an international project that’s available in several languages, or switching to English (solely), would not be challenging in the least (they used to run a Spanish version as well, for example, but decided to discontinue it so as to focus on the Italian one).
BlogBabel has been featured in the mainstream Italian media and has had a noticeable influence on the Italian blogosphere. One could argue that it has been the yellow pages of the Italian blogosphere. Because of this, Ludovico Magnocavallo (the site’s creator) received substantial offers to buy BlogBabel in the past, but he turned them down because he wanted to continue building this site. Now however, due to personal circumstances and lack of time/resources, he’s willing to sell this application for what may amount to far less than its true value. And here’s the real bargain, the starting price, without a reserve, is 4,999 Euros. This is of course, a ridiculously low price for the value being offered. But Ludovico believes in letting the market decide.
If I had the funds lying around, I would buy it myself and gear it towards the English speaking world (in conjunction with the pre-existing Italian version). It’s a prepackaged, virtually ready-made startup with a great deal of potential both in its current state and in terms of what it could grow to become.
To recap, the auction includes:
- The domain name blogbabel.com (it.blogbabel.com has a pagerank of 6);
- The full codebase (almost 30,000 lines of code);
- A database containing 3 years worth of data relating to the Italian blogosphere (more than 30 GB, lots of data-mining opportunities);
- 4 hours of work to help you with setting up the site on your own servers.
BlogBabel has been running smoothly for three years, and is currently under-marketed. Optimizing ads, affiliates, and similar sources of revenue wouldn’t be hard at all, especially if one were to aim this site at the English speaking world.
Also, Ludovico has already implemented most of the code that’s necessary to allow users to have accounts (through OpenID), but since these “social features” are not fully implemented yet, they have not been deployed in production. A buyer could decide to disregard them or finish implementing them and roll out a technorati-like service. The winner of this auction could decide to implement support for Twitter, comments on social networks, sentiment analysis, etc, on their own. The possibilities are really limitless when you start with a solid engine and crawler, and already have a great deal of data at your fingertips.
I know Ludovico and he’s a stand-up guy. If you are interested in this great deal, you can bid here. If you have technical questions about this auction, please feel free to contact him directly through eBay.
UPDATE (September 8, 2009): Ludovico received an undisclosed offer for the site and a few years of maintenance work, so the auction for the site alone was suspended.
The DB2 adapter now supports Django 1.1
I’m glad to announce that the API team has just released version 1.0.2 of the adapter for Django. And on my birthday to boot, what a nice present. This version extends its support to the recently released Django 1.1, as well as incorporating the feedback that was received earlier on. 
(For installation instructions, take a look at the README file.)
IBM confirms its commitment to support Python and Django, and gives Django well deserved credentials in environments where having IBM’s support counts. Django is becoming an increasingly mature web framework with the potential to do well within the Enterprise world. Having support for DB2 will surely help.
The next step will be working with the Django team to bake DB2 support directly into Django’s releases. The code for the adapter is released under a liberal OSI-compliant license that is compatible with Django’s own BSD, and the API team is more than willing to work on the development and support of the adapter should it become part of Django. We love Django and ponies. Let’s make this happen, guys.
Serving Django Static Files through Apache
Django’s development server is capable of serving static (media) files thanks to the view django.views.static.serve. Popular web servers like Apache, Lighttpd or NGINX are much faster though, and as such should be used in production mode. Our goal is to bypass Django and let Apache (or other valid alternatives) directly serve static files like images, videos, CSS, JavaScript files, and so on, for us.
Generally speaking, for performance reasons, it’s advised that you have two different webservers serving your dynamic requests and static files. In practice, for smaller sites, people often opt to simply use one webserver. In this article, I’ll discuss how to serve the static files within your Django project, through Apache.
The first thing we need to do is distinguish between development and production mode. We can do so by simply specifying DEBUG = True (development), or DEBUG = False (production) within our settings.py file.
settings.py may include (among others) the following declarations:
# Absolute path to the project directory
BASE_PATH = os.path.dirname(os.path.abspath(__file__))
# Main URL for the project
BASE_URL = 'http://example.org'
DEBUG = False
# Absolute path to the directory that holds media
MEDIA_ROOT = '%s/media/' % BASE_PATH
# URL that handles the media served from MEDIA_ROOT
MEDIA_URL = '%s/site_media/' % BASE_URL
# URL prefix for admin media -- CSS, JavaScript and images.
ADMIN_MEDIA_PREFIX = "%sadmin/" % MEDIA_URL
*PATH constants indicate paths on your filesystem (e.g., /home/myuser/projects/myproject), while *URL constants indicate the actual URL needed to reach a given page or file.
Notice that it’s not unusual to have a /site_media URL that corresponds to a /media folder. In the example above, I opted to separate regular media files for the project from the standard ones that ship with Django for the admin section. To do this, all we have to do is create a symbolic link as follows:
ln -s /usr/lib/python2.5/site-packages/django/contrib/admin/media /path/to/myproject/media/admin
When you’re in development mode, and DEBUG = True, you want to let Django serve your static files. This can be done by adding the following snippet (or similar) to your urls.py:
if settings.DEBUG:
urlpatterns += patterns('',
(r'^site_media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT}),
)
In production mode, the code contained within the if clause will not be executed as we’ve set DEBUG to False within settings.py.
From the Django side of things, we are good. We now need to instruct Apache. Within your virtual host file, you can specify something along the lines of:
<VirtualHost *:80>
#...
SetHandler python-program
PythonHandler django.core.handlers.modpython
SetEnv DJANGO_SETTINGS_MODULE myproject.settings
PythonDebug On
PythonAutoReload Off
PythonPath "['/usr/lib/python2.5/site-packages/django', '/path/to/myproject'] + sys.path"
#...
Alias /site_media "/path/to/myproject/media"
<Location "/site_media">
SetHandler None
</Location>
</VirtualHost>
The first group of declarations essentially tells Apache to use mod_python to handle any incoming requests. However, we don’t want Django to deal with static files, so the second group of declarations, aliases/maps the /site_media URL with the actual media directory on the server, and tells Apache to threat it as static content (with SetHandler None) bypassing de facto Django.
DB2 Express-C 9.7 and the Django adapter released
This is a great day for those of us who love DB2, as DB2 Express-C 9.7 has just been released. As mentioned before, this is the best DB2 ever, and an extremely important release.
To learn more about what’s new in this release, please check out the recording of our latest webinar:
If you run Linux, Unix or Windows, download it while it’s hot.
DB2 9.7 on the Cloud
Another great aspect of this release is that for the first time ever, DB2 has been released both as a product and as a deployment on the Cloud. If you pop over to RightScale, you can get a trial account for free and should see DB2 Express-C 9.7 on both CentOS and Ubuntu within the partner catalog. RightScale has been an amazing partner and they really do wonders to simplify Cloud Computing. In ten minutes time you can be up and running on the Cloud, thanks to the templates provided.
DB2 support for Django
But the good times don’t stop there, we are also announcing the first official release of the Django adapter for DB2. It sounded crazy when I first proposed the idea within IBM back in 2006, but now it’s a reality.
You can download the .tar.gz archive from the Google Code homepage for the project, or simply by clicking here. This version fully supports the Django 1.0.2 API. For instructions on how to install it, please read the Getting started with the IBM DB Django adapter guide. The current version supports DB2 for Linux, Unix, Windows and MAC OS X, version 8.2 or higher (9.5 FP2 or higher for MAC OS X). In the future, IBM Cloudscape, Apache Derby, Informix (IDS) and both System i & z/OS will be supported.
ibm_db gem updated to 1.1
I’ll conclude this DB2-centric post with a smaller, but still interesting announcement. The ibm_db gem has been updated to version 1.1. This release includes support for ActiveRecord’s QueryCache mechanism, enhanced support for BigInt (and BigSerial), support for rename_column (requires DB2 9.7), parametrization of the timestamp datatype (requires DB2 9.7), and a few fixes and performance enhancements as well. It is recommended that you upgrade to this version.
Of labels and limits
In an attempt to satisfy our need for identity and belonging, we desperately try to wear as many labels as possible, and to a certain extent labels are a necessity. When people ask you what you do for a living, it’s far easier to reply “I’m a computer programmer” than to try and explain the plurality and complexity of the exact criteria of your job.
The problem with labels is that they can place you in a box, at times greatly limiting who and what you are. So while it’s okay to use labels to efficiently communicate with other people, it’s important not to fall into the trap of taking them too seriously, thus letting them become who you are – or are not.
It’s not the label per se, but rather our perception of what our identification with a given role implies. If I identify myself too strongly as a “rubyist” I may not be inclined to recognize the good that is found elsewhere in other programming languages, or worse still, reject such good in an attempt to defend the choice I opted to identify myself with. This inclination is the basis of many of the “religious wars” you see online.
I sometimes find myself in the odd predicament of limiting myself because of some label or assumption of what “a person like me” can and cannot do. In such instances though I’m reminded of a few stories about courageous individuals who went beyond labels, above the layer of conventionality, breaking what common sense would have considered a “difficult to challenge” limit. I’m reminded of blind people who took on photography and managed to be successful at it, or of a black kid of Kenyan origins who managed to become the President of the United States of America. But there is one story in particular that always gets me, it’s the story of Django Reinhardt, after whom the the popular Python framework was named.
Django was a Gypsy jazz guitarist who was severely injured in a fire when he was eighteen. As a result of this accident his right leg was paralyzed and the third and fourth fingers on his left hand were severely burned. Doctors recommended amputating his leg and were pretty darn sure that he would never play guitar again due to the extensive damage to his hand. Django refused the amputation though and left the hospital as soon as he could. Within a year he was able to walk again, albeit with the aid of a cane. Even more surprisingly, despite being “disabled” in his left hand, he persisted through the pain to practice his beloved instrument. He went on to reinvent the conventional approach to guitar playing by performing solos with the use of only two fingers, using his half-paralyzed fingers for chord work. Today Django is considered one of the most influential guitarists of the 20th century.
I’ve learned to consciously fight the urge to limit myself. Whatever labels you feel may be cutting your potential short or holding you back, I encourage you to break free and rise above them. Does doing so mean you’ll reinvent the way a musical instrument is played, reshape the course of history or become a hero in your field? Perhaps, but even if it doesn’t, your own life stands to become richer and freer because you decided not to live within the confines of a label.
DB2 support for Django is coming
A few weeks after DB2 Express-C for Mac OS X was announced, I’m here to let you in on another great scoop. DB2 support for the Django web framework is going to be available soon to the community, under the permissive Apache 2.0 License. We are presently waiting for clearance from our lawyers, but the code has been written and tested, and Django is finally working with DB2. This comes on the heels of a new release of the Python driver for DB2, version 0.6.0, which adds full support for Unicode.
The Django community will soon be able to use the rock solid database management system which is DB2, and enjoy all the advantages that it provides. Would you like to introduce Django into your enterprise environment, where DB2 is already in use? If so, you’ll now have an easier time with this. Want to use DB2 as a competitive advantage for your startup? Now you can, whether you opt to use Django/Python, Rails/Ruby, Zend Framework/PHP or Perl.
I have been pushing for Django’s ORM support since 2006, and I distinctly remember the initial reactions of some people at IBM, they were along the lines of, “Djan… what?”. Unlike Rails, Django was much less known back then, especially among IT managers, and in all fairness, while powerful and very productive, the inherited Python philosophy that “explicit is better than implicit” made it look more complex – or at least less impressive – than Rails during 10 minute demos. But I insisted that it was important for our DB2 strategy and for the Django community, and now it’s finally a reality, thanks to the hard work of the IBM API team. Just like for Rails and Ruby, IBM will be the first and only vendor to officially support a Python driver, SQLAlchemy and Django’s ORM adapters.
I can’t help but think, what’s next? What language and/or framework truly needs some DB2 love? I’m definitely interested in a few languages and frameworks, and have already advocated for some of these as well, but I’d like to hear your opinions on this topic. I have created a poll that asks you which, among the technologies that we don’t currently support, do you think it would be most beneficial to have DB2 support for. Feel free to express your opinions in the comment section, as well as in the poll.
Disclaimer: The opinions expressed in this post are mine and mine alone, and do not necessarily represents the opinions of my employer, IBM. The poll is not an official IBM survey.
Merb, Rails Myths, Language Popularity and other Zenbits
Zenbits are posts which include a variety of interesting subjects that I’d like to talk about briefly, without writing a post for each of them.
Merb: A few days ago Merb 1.0 was released. Congratulations to Ezra Zygmuntowicz on this important milestone, the Merb community and Engine Yard (who finances the project). Merb 1.0 wasn’t even out yet when some people had already started commenting on the fracturing of the Ruby community that this new framework might bring with this, and the impact that this high visibility “competitor” might have on Rails. I believe that having more than one widely adopted web framework will only benefit the Ruby community. Furthermore, it’s important to remember that this is not a zero-sum game. Ruby programmers are perfectly capable of learning two frameworks and using one or the other, depending on the project at hand. This is particularly true if we consider that Merb, for all of its advantages – and disadvantages – when compared to Rails, is not totally different from its forerunner. If you are an expert Rails programmer, you should be able to become proficient in Merb in very little time. To help with this process, the Merb community needs to concentrate on the documentation now, given that the API is finally stable.
Rails Myths: David Heinemeier Hansson began a series of posts about Rails Myths. I like the idea of seeing common myths addressed straight from the horse’s mouth. Over the past two years, Rails has received quite a bit of backslash and old fashion FUD, so it’s important to set the record straight, whether the myths are entirely fabricated or if there is some element of truth to them. Whether you agree with David or not, it’s also nice to hear two sides of the same story. In fact, at the beginning of my book I debunk a few myths, just to set the record straight regarding what some readers may have heard surrounding the framework. It was a fun part to write.
My Book: Speaking of my book, Ruby on Rails for Microsoft Developers, I’m getting closer to the finish line. I’m about to complete Chapter 9 (out of eleven chapters). The initial schedule I was provided with has been extended slightly so that there will be sufficient time to properly review the content and ensure that it’s up to date with the final release of Rails 2.2. Some people wondered what the “Microsoft Developers” part means. Is it for people that work at Microsoft? Is it for .NET programmers? Is it for people who develop on Windows?
The truth is that “Microsoft Developers” is probably just a marketing term that Wrox selected as a catch-all for of the aforementioned categories of programmers. As an author I’m trying to serve all of them well, by providing a guide that sneaks in much of the Rails culture and softens the migration path by using an Operating System, and to a certain extent, tools that they’re already familiar with. In my opinion one of the major obstacles when switching to, or trying, Rails when coming from the Microsoft world, is the culture shock. The documentation and most books assume that you are familiar with *nix systems and tools, and this can be frustrating for those who are forced not only to learn a new language and framework, but also an entirely new set of tools. As it’s targeted at Microsoft developers, the book obviously makes quite a few references and comparisons to the .NET world, where they fit. This is done so that the many .NET programmers amongst the group of so called “Microsoft Developers” will find the book particularly useful. Yet the book remains generic enough so that it can be used by any programmer (particularly Windows users), even those without any knowledge of the Microsoft .NET Framework or ASP.NET.
Python books: While on the subject of books, I wanted to mention that the final version of the Pylons book is available online. Despite the much less fancy UI, the book pretty much does what the Django Book did in the past. And both are available in print as well (The Definitive Guide to Django: Web Development Done Right and The Definitive Guide to Pylons). Pylons is a Python web framework that can be viewed as a Ruby on Rails clone, in a far greater way than Django could ever be considered.
Another thing I want to mention is that I received a copy of Expert Python Programming. I haven’t gotten to far into it yet, but from what I’ve seen so far, things look good. I hope to be able to read it through, over a weekend in the near future and then provide a proper review. Stay tuned.
Language Popularity: If you take a look at the TIOBE Index, you’ll notice a few interesting things: Ruby has dropped two positions since last year, and it’s now the 11th most popular language in the world. This shouldn’t be cause for concern though, as shown by this Ruby graph. Python on the other hand is increasing in popularity and moved from the 7th to the 6th most popular language. Interestingly, according to the index (the results of which are educated guesses only), Python would seem to be more popular than C#. I find this to be true, in terms of online activity within an increasingly vibrant community, but in my opinion, the job market hasn’t caught up yet. In fact, at least in Toronto, when there’s a Python opening it’s pretty much an event that’s worthy of being discussed on the local Python mailing list. C# openings are much more common. This may be different in Silicon Valley, of course. It would also seem that Delphi has experienced a huge come back, moving from the 11th position last year to the 8th one this time around. It’s hard to imagine that Delphi has had a similar level of adoption as C# and thus has become more popular than Perl, JavaScript and Ruby. Delphi is a great solution for Win32 programming, but I don’t quite believe this overly optimistic outlook. And if this is the case, where are all the Delphi jobs and buzz?
DB2: This interview shows a few good reasons why even smaller and medium sized companies are increasingly adopting DB2. And while the video doesn’t mention it, IBM is coming out with an updated version of DB2 Express-C 9.5. This new version, 9.5.2 or 9.5 FixPack 2, is going to introduce exciting new features, including an engine for full text search.
The Great Ruby Shootout These days you hear a lot of talk about parallel programming. Intel promotes it and despite their bias, it’s plausible that parallel programming will become important as the CPU market heads towards an increasingly larger number of cores, as opposed to focusing on the frequency of said CPUs. In the world of Ruby, this translates into multiprocessing, as opposed to multithreading due to the infamous GIL (Global Interpreter Lock). This means that Ruby will most likely approach the problem similarly to how Python 2.6 did with the multiprocessing module, which is a process-based interface. The obvious exceptions are JRuby and IronRuby, which establish a 1 to 1 relationship between green threads and OS threads.
For the shootout, it would be interesting to see some multithreaded code, so as to get a better sense of how well JRuby and IronRuby compare to MRI and 1.9, when more cores are available. In fact, the long-promised shootout will be performed on a quad-core machine with 8GB of RAM. If Charles Nutter, John Lam, or any of their team members would like to contribute some programs that are able to take advantage of “native” multithreading, I’d be very happy to include them in the Ruby Benchmark Suite, to be used for my shootout.
The repository requires some love and refactoring, since it needs to be split in two types of benchmarks. The simpler one will evaluate the execution time minus the startup time, while the more advanced benchmark will also exclude the time required for parsing and loading modules, classes and methods in the AST. It would also be nice to test each program with variable input sizes and report these results accordingly. Right now I’m very busy with the book, but as I become more available, I’ll start working on this.
Finally, I want to point out a very interesting article about performance and UIs. Slow is indeed a very relative concept, and it’s important to understand how to analyze and respond to the user requirements when it comes to the responsiveness of an application as a user interacts with it.
Hardware: I finally bought a Trackball made by Logitech and the Microsoft Ergonomic Keyboard (Microsoft makes great hardware). I don’t have wrist problems, but I’d like to see how these two affect my extensive computer usage. I plan to report my experience as soon as I’ve had a chance to use these input devices for a while, since I know this is a topic that interests lots programmers (many of whom end up being victims of RSI, and some of the IRS 
). I also bought a bad-ass color laser printer which is quite handy when you’re a programmer and you are writing a book. I’ll let you know how it goes. What I didn’t buy, but still think is awesome, is the Flip minoHD. It’s the equivalent of an iPod for the world of camcorders. $235 for a camcorder that’s so perfectly compact, and yet that can record in HD, is a pretty sweet deal. I’m considering it for Christmas, assuming it reaches Canada by then.
Take this survey and win a free ticket for the Professional Ruby Conference
Addison Wesley will hold their first Professional Ruby Conference in Boston, Massachusetts between November 17 and 20, 2008. This conference, for which Obie Fernandez is the Technical Chair, is highly educational and boasts some of the best speakers from the Ruby and Rails communities.
The organizers were kind enough to invite me, offering me a complimentary pass for the Professional Ruby Conference. I won’t be able to attend, so I decided to donate my free admission to one lucky reader. They also provided me with a priority code (like a coupon) for my readers, which entitle you to receive a $200 discount off the regular admission price.
I really value your opinions and I’d appreciate it if you could take this survey, so that I can improve the quality of this blog. At the end of the survey you’ll receive your $200 discount code, and will be entered into my draw for your chance to win one free ticket. I will announce and get in touch with the winner early next week (Monday or Tuesday depending on participation levels).
Django turns 1.0
A couple of weeks ago Django 1.0 was finally released. In the software world version numbers can be rather arbitrary, but this announcement electrified the usually quiet community. Hiding behind the 1.0 label there are thousands of bug fixes, code refactoring of crucial components, compatibility with Jython 2.5, and the addition of impressive features such as GeoDjango which adds GIS capabilities to the framework.
Above all, the release of a 1.0 version implies that we can now rely on a stable API. So far most Django developers adopted the trunk version of the framework in production, because a lot of the desirable new features were not available in 0.96. The introduction of Django 1.0 is a fundamental stepping stone, and one I’m sure will lead to even more developers giving Django a chance. It will also facilitate the adoption of the framework within the enterprise, which is rarely keen on the idea of working with the edge version of a 0.x framework.
Matz is often quoted as saying: “Rails is the killer app for Ruby”. There is no doubt that likewise, Django is the killer app for Python. As Django matures and gains further worldwide acceptance, employing Python for web development will become an increasingly common reality, repeating to a certain extent what Rails did for Ruby.
Admittedly, the parallel doesn’t fit perfectly as Ruby on Rails has an overwhelming market share amongst Ruby frameworks, while in the Python community there are a few big contenders (and Zope was the first widely adopted Python framework). But it’s clear to me that Django will bring the popularity of Python on the web to a whole new level, and together with Rails, they will be the two major frameworks for developing web applications, at least in the open source field.
These two frameworks will continue to benefit from this popularity, and indirectly so will their respective languages and communities. Finding a Ruby or a Python job outside of the realm of Silicon Valley startups will not be seen as having won the job lottery, but instead the norm. And we’ll suddenly realize that the paradigm shift of the first decade of the 21st century in the programming world didn’t come from the adoption of multi-core processors, but rather from a focus on web applications and the consequent rise to fame of MVC frameworks like Rails and Django. Whose existence is only possible thanks to open source, dynamic and highly expressive languages such as Ruby and Python.
Django’s tipping point
Django seems to have reached its tipping point, that critical mass which will enable its momentum to skyrocket. Getting here took a while though; partially because of a lack of hype and partially due to Rails’ very prominent presence in the market. Now this well deserving framework has finally begun to be widely adopted and considered as a valid alternative to Rails, for agile web development. Why do I care about what other people are going to use? I care because I’m deeply passionate about technology that works and that keeps things as simple as possible – as such forms of innovation always should. Independently from their adoption, promotion, and the differences in their approaches, both Django and Rails have at their core, a lot of substance and can greatly simplify and improve the way a web developer’s creative process flows.
Stating that Django has reached its tipping point is a bold claim, but I can present some evidence to back it up. I will use Rails and Ruby as a comparison for Django and Python – but don’t construe this as a race between the two frameworks. Rails is still the most popular and will probably continue to be for a long time. I’m only comparing the numbers to get an idea of where Django stands right now.
Visiting irc.freenode.net, I’ve noticed that the Python (#python) channel is often more populated than the Ruby one (#ruby-lang), and the same goes for Django (#django) and Ruby on Rails (#rubyonrails). For example, right now I see 517 members for Python and 354 for Ruby, 382 for Django and 298 for Rails. Django and Python consistently have more hackers in their chats than Rails and Ruby. This doesn’t say too much, given that the average developer doesn’t hang out on irc, but it’s still somewhat indicative of Django’s growing community.
Moving to newsgroups/Google Groups, things start to change a little. As I write this, there are 12,457 subscribers for comp.lang.python and only 6,935 for comp.lang.ruby (with 1,857 members in ruby-talk-google). “Django users” has 8,178 members versus the 13,355 of “Ruby on Rails: Talk”. So far this month, the Django group has had 1,244 messages versus the 2,890 of the Rails one. By looking at these numbers, without any pretense of being too scientific in our comparative methods, we get the impression that the Rails community is almost twice as big as the Django one, which sounds about right. On the other hand we also get that the Python community is larger than the Ruby one (confirmed also by the irc results above). In looking at these numbers, Rails also has the advantage of being the most used Ruby framework by far. In Python-land, Turbogears (3,303 members), Pylons (1,333 members) and good old Zope split the pie too, even though Django remains the most popular choice. Guido van Rossum’s blessing for Django was just the icing on the cake.
By observing the TIOBE Index, we see that Python is in 7th position versus the 10th position where we find Ruby. Perhaps more interestingly, Python has had a +0.70 delta since last March, while Ruby a -0.11%. Again, this is certainly not an exact science, my friends. TIOBE accuracy is often disputed for good reason, but I think it’s still an indicative factor.
Speaking of less than entirely reliable things, Alexa (django vs rails), Compete, and Google Trends (yes, rails is a very generic term) all confirm the anecdotal evidence that Rails is still far more popular. That said, the values start to be at least somewhat comparable.
In my opinion the strongest indicators of Django’s increasing popularity come from the publishing world. You’ll see many books in print for a given topic, only if their publishers believe that there is a large enough market for them. In 2007 the following two books were published: Professional Python Frameworks: Web 2.0 Programming with Django and Turbogears
5 books on Django announced to date and more lined up to be released this year, I’m sure. There are now many books in print that cover Rails (my recommendations here), but the sudden spur of Django books reminds me of Rails a couple of years ago and will surely help widen Django’s popularity. Watch closely because things will move fast in Django-land.
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:
- 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 firstnamelastname.com, 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.
- 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.
- 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.
- 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.
Rails is the best thing that ever happened to Python
Rails has been a blessing and a curse for the Ruby community. It brought sudden popularity to the language with all the consequences, good and bad, that usually result from exponential growth. On one hand, it gave many developers the chance to appreciate the design of the Ruby language based on its own merit. On the other hand though, it’s been a cash cow that’s changed the community forever by attracting all kinds of attention. Rails has become the poster child for Ruby, blurring the distinction between the Ruby, and Rails, communities. A large number of web programmers got to experience the “ease of use” and beauty of Ruby development, but it also clearly exposed Ruby’s implementation shortcomings. Rails enabled Ruby to go from a relatively unknown programming language to a mainstream one within the frame of just a couple of years. Languages are made to be used, so overall, most would agree that the advantages for Ruby, brought forth by Rails’ success, far outweigh the negative aspects. In the words of Matz, Ruby’s creator:
Rails is the killer app for Ruby.
— Yukihiro Matsumoto
Whatever your take on the subject is, in this article I argue that Ruby on Rails is actually the best thing that ever happened to Python. Rails is a successful Ruby framework, so some may think that it would convince people to switch from Python to Ruby. In other words, naively, one could think of Rails as a Python exterminator, at least as far as web development goes (which is a big deal nowadays). This couldn’t be further from the truth. This year is going to be a great one in terms of the adoption of Python, and I think that Rails has had a positive influence in this regard.
Independently from Rails and Ruby, over the past few years Python has had a good deal of penetration within the market. It wasn’t Java, of course, but as far as dynamic languages go, Python was well represented in many companies and achieved a fairly adopted niche even within the enterprise world. What Rails did was to promote and popularize the usage of MVC web frameworks written in dynamic languages. What could have been considered an unusual choice in the pre-Rails era, is now viewed by most as the right way of developing web applications. The marketing abilities of the Rails community benefited the Python one, in the sense that they made the usage of dynamic languages for serious web projects a very acceptable and even well warranted choice.
Rails got the message out that MVC web frameworks and “scripting” languages could be very productive and much nicer to work with. Django and other web frameworks are indirectly taking advantage of this. A couple of years ago people were asking me whether it was better to adopt Rails or stick with Java for a given project. Nowadays, most emails and requests that I receive are about whether it makes sense to adopt Rails and Ruby or if it would be more sound to use Django and Python.
Initially, even Sun hired Ruby hackers to work on JRuby and have only recently announced that two pythonstas will work on Jython full-time. Yes, they are late to the party and should have done this years ago, but I think that Rails’ popularity and hype led them to consider Ruby first before eventually realizing that they should have done the same thing for Python. Rails has been, at least in part, a catalyst for Python’s success.
Don’t let this confuse you though. Python (and Django) are able to benefit from all the interest geared towards dynamic languages, only because they are technically excellent and make a strong case on their own. Their communities are much less about marketing and more about substance, in my opinion. I understand those who go from Ruby to Python, but there are far fewer motivations in favor of a switch from Python to Ruby. The reason for this is that, in a way, Python is currently an answer to Ruby’s MRI shortcomings. When I speak about Ruby’s shortcomings I always refer to the implementation and not to the design of the language, which is a well balanced and coherent mix of paradigms and features.
Things will change with Rubinius (and perhaps JRuby), but as it stands right now, Ruby’s implementation has critical limitations that affect the development of non-toy projects and its adoption within the enterprise world. Speed, I/O processing, threads, garbage collection and troubling deployment when compared to other languages, are serious issues. It doesn’t mean that you can’t use it, just that the limitations that are in place will make your life more difficult on certain projects.
In a way, Python is the only acceptable implementation of Ruby for certain values of Ruby. The two languages have different approaches and quite a few distinctions which make them both unique. Overall though there are plenty of similarities that make developing in one or the other a somewhat comparable mental process and coding experience. Sure, Python doesn’t promote the functional paradigm as much, and it’s less implicit/magical than Ruby (read import this). This could be a good thing when it comes to large and enterprise projects, but the two are all not that different from each other. They’re Capelli d’angelo and Spaghettini, as my fellow countryman Alex Martelli eloquently put it.
As much as I may like Ruby more as far as language design goes, not only does Python boast a very solid implementation, it has several advantages over Ruby that go beyond the interpreter. I’ve found that Python has an incredible amount of rock solid, high quality libraries that perform very well. Not all of them of course, but most are well coded, maintained and documented. In Rubyland we can’t claim the same levels of good reusable code. I use both and I see a big difference. Lingering for a moment on the subject of documentation, Python has a wealth of tutorials, guides and even entire books available for free online. Learning Python from these, without spending a cent, is a walk in the park. Ruby on the other hand has good books in print, but a long way to go as far as free documentation goes. And this is true for both Ruby and Rails.
The community attitude is much different too. The Python and Django communities generally keep a low profile, following the “shut up and show them the code” mantra. They do have some marketing issues but can’t be blamed for hyping their technology, like at least in part, Rails has done. For example, Django is a very mature framework that’s several years old, and yet it still hasn’t been tagged as a 1.0 version. If Twisted Matrix was implemented in Ruby it would be advertised as the second coming of Christ. Jokes aside, I feel that the Python community has a very good attitude which is in no way altered by the Django one, because it happens to share the same traits. There are no exclusive private clubs or the feeling of experiencing a technological “gold rush”, even though the community is in no way smaller. This may seem like a minor point, but for many the maturity, pragmatism and attitude of the community is a big selling point for Python/Django.
I’ll refrain from indulging in a full length comparison of Rails and Django. But I must briefly mention that Django takes the cake when it comes to creating applications that do web publishing (for obvious background reasons). Despite attempts to put Photoshop online, I feel that most of the web is still about publishing and interacting with published data. This makes Django a good choice in most cases. Of course, should you develop a web application that intends to replace a desktop app, Rails will most likely have the edge there.
So what does this mean for me personally? I’ll use them both, as I’m a firm believer in using the right tool for the right job. I’ll give you an example. Stacktrace.it is a small revolution in the Italian IT publishing world. A few months ago I contacted about 30 people from amongst the best Italian hackers and IT professionals and I proposed that together we create a site in which we’d promote and influence software development and IT in general in Italy (even if I live in Canada myself). The site has been going very well and has attracted a group of highly technical people who follow and contribute regularly with high quality articles. The code was based on Luambo, an open source blog engine yet to be officially packaged and promoted to the world. What was remarkable about it was that most of the new features that were requested in our private mailing list ended up in the code in less than five minutes. An unbelievable level of productivity. Even our designer, who was not familiar with the language or the framework, was easily able to work on the project. Guess what? Despite loving Ruby and Rails, when it came to deciding on the framework and language to be used for that project, I strongly pushed for the adoption of Django and Python, and not Ruby on Rails. It was simply the right tool.
IBM releases DB2 adapter for SQLAlchemy
A while ago I informally announced IBM’s intention to develop an SQLAlchemy adapter for DB2 and Informix IDS. Today, I’m happy to inform you that we have a first working release for DB2 on Linux, Unix and Windows (LUW). Support for Informix IDS is next (almost done), and after that, it will be System i and z/OS’ turn.
This release will surely excite those Pythonistas who can appreciate DB2 for what it is: one of the most powerful data servers in the world. Which, in its Express-C version, also happens to be gratis (“free as in free beer”). But there is more to it than just that.
IBM has in fact created a project on Google Code, for supporting Python development with IBM Data Servers. Aside from downloads and SVN access, this gives the project a nice public bug tracker which was missing up until this point. A Google Group was also created in order to have an easy to follow support mailing list, and I invite you to join it now.
With the switch to Google Code, there was also an update to the Python drivers (now version 0.2.5), which contain a few improvements and a bug fix for the egg that wasn’t working properly on Linux.
The project currently hosts the following components:
- The ibm_db Python Egg for Linux and Windows which contains:
- The ibm_db driver: a C extension module that wraps IBM’s Data Server Driver for ODBC and CLI APIs and provides a Python client interface for the DB2 and Informix IDS databases.
- The ibm_db_dbi: a Python coded module that relies on the ibm_db Python driver, and complies with the DB-API 2.0 specs.
- The ibm_db_sa: a Python coded adapter which implements the SQLAlchemy 0.4 API specification.
Please use the driver and/or the adapter for SQLAlchemy and let us know if you encounter any issues or have any feedback about it.
Installing Django with PostgreSQL on Ubuntu
This how-to is essentially the same as my previous one, only this time I’ve provided step-by-step instructions for installing Django with PostgreSQL on Ubuntu 7.10.
First and foremost, we are going to install Django from its svn repository, as opposed to obtaining the 0.96 release archive. The reason for this is that the trunk version implements a few new features. The development code is also rather stable and used by most people in production mode, even for sites like the Washington Post.
Install Subversion
sudo apt-get install subversion
Checkout Django
svn co http://code.djangoproject.com/svn/django/trunk django_trunk
Tell Python where Django is
Ubuntu already ships with Python 2.5.1, thus you won’t have to install it. You can verify this by running python in your shell (use exit() to get out of the python shell). What you need to do is inform Python about the location of your django_trunk directory. To do this create the following file:
/usr/lib/python2.5/site-packages/django.pth
Within this file, place only one line containing the path to your django_trunk folder. In my case, this is:
/home/antonio/django_trunk
Of course, change it to the full path location of the directory on your filesystem.
Add django-admin.py to your PATH
The bin directory within the django folder (which is inside django_trunk itself) contains several management utilities. We need therefore to add the following to the PATH (again, change it to your own location):
/home/antonio/django_trunk/django/bin
How you go about doing this, depends on the shell you are using, and I’m assuming you are able to export a shell variable on your own. In case you are using the bash shell (as I do) you could export it in .bashrc. Alternatively, you could just create a symlink to the utility django-admin.py in /usr/bin, but I recommend the former approach.
Install PostgreSQL and Psycopg2
sudo apt-get install postgresql pgadmin3 python-psycopg2
This will install PostgreSQL 8.2.5, PgAdmin III and the driver Psycopg2 for you. Most people at this point will ask, what’s the default password for PostgreSQL on Ubuntu? You can use the following instructions to set the password for the user postgres both in Ubuntu and within PostgreSQL:
sudo su -
passwd postgres
su postgres
psql template1
The last instruction should open the psql shell, where you can run the following:
ALTER USER postgres WITH ENCRYPTED PASSWORD 'mypassword';
Verify the installation
You should be all set now, but let’s verify this right away. Open the shell and run the following instructions inside the python shell (start off with the python command).
>>> import django
>>> print django.VERSION
(0, 97, 'pre')
>>> import psycopg2
>>> psycopg2.apilevel
'2.0'
By running exit() get out of the python shell, and verify that django-admin.py is in your path:
django-admin.py
Type 'django-admin.py help' for usage.
If you obtain a similar output for all three of them, you are really set.
Where to go from here
Now that Django is installed, you can go read the Django Book 1.0 that’s available for free online. Something equally well done and useful is really missing from the Rails community. Above all, experiment, Django (and programming in general) is learnt by doing. The Definitive Guide to Django: Web Development Done Right
How to install Django with MySQL on Mac OS X
Installing Django on Mac OS X Leopard is supposed to be very straightforward, but if you are new to it, you may encounter a few puzzling questions and, in the case of MySQL, even a couple of headaches. I’m writing about this for the benefit of those of you who may attempt and struggle with this feat. MacPorts is not required for this how-to.
First and foremost, we are going to install Django from its svn repository, as opposed to obtaining the 0.96 release archive. The reason for this is that the trunk version implements a few new features. The development code is also rather stable and used by most people in production mode, even for sites like the Washington Post.
Checkout Django
svn co http://code.djangoproject.com/svn/django/trunk django_trunk
Tell Python where Django is
Mac OS X 10.5 already ships with Python 2.5.1, thus you won’t have to install it. You can verify this by running python in the Terminal (use exit() to get out of the python shell). What you need to do is inform Python about the location of your django_trunk directory. To do this create the following file:
/Library/Python/2.5/site-packages/django.pth
Within this file, place only one line containing the path to your django_trunk folder. In my case, this is:
/Users/Antonio/Code/django_trunk
Of course, change it to the full path location of the directory on your filesystem.
Add django-admin.py to your PATH
The bin directory within the django folder (which is inside django_trunk itself) contains several management utilities. We need therefore to add the following to the PATH (again, change it to your own location):
/Users/Antonio/Code/django_trunk/django/bin
How you go about doing this, depends on the shell you are using, and I’m assuming you are able to export a shell variable on your own. In case you are using the bash shell (as I do) then you should have a .profile file in your home directory. Alternatively, you could just create a symlink to the utility django-admin.py in /usr/bin, but I recommend the former approach.
Grab and install MySQL
I would normally recommend PostgreSQL, at least until we have DB2 on Mac, but I realize that many of you use and prefer MySQL, which also seems to be the only one that requires special instructions due to a few installation issues when trying to get MySQL and Python to work together. You can install MySQL by grabbing and running one of the packages that are available on the official site. Choose the one for x86 and Mac OS X 10.4.
Install the MySQLdb driver
Get MySQL-python-1.2.2.tar.gz from SourceForge. Please follow these exact instructions because the source code won’t compile out of the box and will give you the following error when trying to build it:
/usr/include/sys/types.h:92: error: duplicate 'unsigned'
/usr/include/sys/types.h:92: error: two or more data types
in declaration specifiers
error: Setup script exited with error: command 'gcc' failed
Run the following:
tar xvfz MySQL-python-1.2.2.tar.gz
cd MySQL-python-1.2.2
At this point, edit the _mysql.c file and comment out lines 37, 38 and 39 as follows:
//#ifndef uint
//#define uint unsigned int
//#endif
Now, from the MySQL-python-1.2.2 folder run:
python setup.py build
sudo python setup.py install
If you still get an error (and only in that case) you’ll need to edit the site.cfg file within the same folder and set threadsafe = False, before running the two commands above once again.
If instead, you don’t receive an error but you see warnings about files not required on this architecture, don’t be concerned about them. The last step required is to create a symbolic link with the following command:
sudo ln -s /usr/local/mysql/lib/ /usr/local/mysql/lib/mysql
All these adjustments are required because we are building and installing the driver on Mac and not on Linux.
Verify the installation
You should be all set now, but let’s verify this right away. Open Terminal and run the following commands in the python shell (start this with the python command).
Verify that MySQLdb is correctly installed:
>>> import MySQLdb
>>> MySQLdb.apilevel
'2.0'
Now, verify that Django is working:
>>> import django
>>> print django.VERSION
(0, 97, 'pre')
By running exit() get out of the python shell, and verify that django-admin.py is in your path:
django-admin.py
Type 'django-admin.py help' for usage.
If you obtain a similar output for all three of them, you are really set to write the next YouTube.
Where to go from here
Now that Django is installed, you can go read the Django Book 1.0 that’s available for free online. Something equally well done and useful is really missing from the Rails community. Above all, experiment, Django (and programming in general) is learnt by doing. The Definitive Guide to Django: Web Development Done Right
Holy Shmoly, Ruby 1.9 smokes Python away!
Alright the title of this post is a tad sensational sounding, I know, and it’s in part aimed at messing with my many Pythonista friends. We Rubyists have been teased for a long time, due to the slowness of the main Ruby interpreter. Well, it looks like with Ruby 1.9, it’ll be payback time. Just out of curiosity I decided to run a single benchmark (you can hardly call it that) to see how Ruby 1.9 had improved over the current stable version (1.8.6). I wasn’t planning to make a post about it. It was one of those tests that you do at 3 AM in an irb session when you feel you’ve made your daily peace with your actual workload for the night. When I saw the results though, my jaw dropped. I had to blog about this one.
I ran a recursive Fibonacci function, just to stress test a bit of recursion and method calling, and while I was at it, I decided to compare it with Python too. The test was run on Mac OS X 10.5 with my MacBook Pro (Core 2 Duo 2.2 GHz and 2 GB of memory). It’s a single test (which is obviously not a real world example, as you would use an iterative version of the function if it were), and unlike with real programs, it doesn’t stress many features of the language. At least for now, there is no reasonable evidence to conclude that Ruby 1.9 – which will be released for this coming Christmas – will actually be faster than Python 2.5.1 in the majority of situations, but hear me out and check out these very surprising results.
The Ruby code:
def fib(n)
if n == 0 || n == 1
n
else
fib(n-1) + fib(n-2)
end
end
36.times do |i|
puts "n=#{i} => #{fib(i)}"
end
And the Python equivalent:
def fib(n):
if n == 0 or n == 1:
return n
else:
return fib(n-1) + fib(n-2)
for i in range(36):
print "n=%d => %d" % (i, fib(i))
Running the snippets above, I got the following results:
Ruby 1.8.6: 158.869s
Python 2.5.1: 31.507s
Ruby 1.9.0: 11.934s
Ehm, hold on a second! Did Ruby just go from 159 seconds down to 12? Koichi Sasada, do you have an Amazon Wishlist? I was expecting a decent improvement, as I’ve been playing with 1.9 every now and then for a long time – so I knew it was faster – but I was blown away when I timed the latest version from trunk (even if it’s a really silly example that’s being tested). Granted Python is not the fastest language out there, but Ruby 1.9 was still able to execute the script almost 3 times as fast. It’s unbelievable.
Now it’ll be very interesting to run a series of algorithmically equivalent tests for Ruby and Python, and to see just when exactly Ruby 1.9 manages to knock Python out of the water – and where Python has still the edge. If I manage to find some time, I will report the results in this blog. But for now, I’ll say just… wow!
Ruby, Python, Haskell and Objective-C Feed Survey
Having little time to follow the blogosphere and its crazy rhythms of publication is not a good enough excuse for not being up to date. This rings particularly true for me as a technical evangelist at IBM, and as someone who is deeply passionate about the development and the information technology world. The biggest challenge is to quickly and efficiently divide the wheat from the chaff or, in other words, filter out the noise from the overload of signals put out there. For me, feed readers are life savers, I couldn’t cope without them.
I recently adopted a setup that seems to be working particularly well. I purchased NetNewsWire for my Mac and FeedDemon for Windows, and automatically got a one-year subscription to the online premium service from the fine folks at newsgator. The two programs are a joy to use, especially for handling very large group of feeds in a short amount of time, as I often need to do. Each program automatically synchronizes with the newsgator service, therefore no matter which computer I’m using, I’m always dealing with the same folders, subscripted feeds and saved clipping. Sure, there are free services out there like Google Reader or Bloglines, but to me there is no comparison between the experience that I have when using a sluggish web interface and a rock solid, well designed desktop application. If I have the option, I’ll always choose the latter, especially since newsgator allows me to take advantage of a centralized repository of feeds from my desktop programs, just like as if I were using their online service through Firefox. For a few dollars, I got a setup that is working awesomely well for me and it’s saving me huge amounts of time. It also helped me to identify non-updated blogs, and those that I was no longer paying attention to, therein allowing me to reduce my over-all amount of feeds (granted with a conscious effort on my part) to a more manageable total of 160.
As mentioned above, my subscribed feeds are important to me, with a list that changes dynamically over time, as I add and remove entries. That said, I was looking at my Ruby and Rails folder when I decided to share my feeds with you. The list is understandably incomplete (after all, there are thousands of Ruby related blogs) and the presence of planets, aggregators and tags in bookmark services like del.icio.us, generate a few unavoidable duplicates. These are the Ruby/Rails blogs and sites that I currently subscribe to:
- alternateidea.com
- antoniocangiano.com
- blog.codahale.com
- blog.fallingsnow.net
- blog.grayproductions.net
- blog.innerewut.de
- blog.jayfields.com
- blog.leetsoft.com
- blog.segment7.net
- blog.talbott.ws
- blog.zenspider.com
- blogs.thoughtworks.com
- brainspl.at
- chneukirchen.org/blog
- dablog.rubypal.com
- db2onrails.com
- del.icio.us/popular/rails
- del.icio.us/popular/ruby
- demo.mephistoblog.com
- drnicwilliams.com
- eigenclass.org
- eli.thegreenplace.net
- errtheblog.com
- glu.ttono.us
- groups.google.ca/group/comp.lang.ruby
- groups.google.ca/group/rubyonrails-talk
- headius.blogspot.com
- hivelogic.com
- intertwingly.net/blog
- memeagora.blogspot.com
- metaatem.ne
- mir.aculo.us
- ntschutta.com/jat
- nubyonrails.com
- ola-bini.blogspot.com
- on-ruby.blogspot.com
- onestepback.org/index.cgi
- peepcode.com/products
- planetruby.0×42.net
- pragdave.blogs.pragprog.com/pragdave
- rubyblogs.org
- rubyforge.org
- ryandaigle.com
- tomcopeland.blogs.com/juniordeveloper
- twsummary.blogspot.com
- weblog.jamisbuck.org
- weblog.rubyonrails.com
- www.adaruby.com
- artima.com/buzz/community.jsp?forum=123
- chadfowler.com
- clarkware.com/cgi/blosxom
- cornetdesign.com
- danwebb.net
- igvita.com/blog
- jroller.com/obie
- juixe.com/techknow
- loudthinking.com
- oreillynet.com/ruby/blog
- pjhyett.com
- quotedprintable.com
- railscasts.com
- railsenvy.com
- robbyonrails.com
- rubyinside.com
- rubyonrailsblog.com
- rubyquiz.com
- slash7.com
- softiesonrails.com
- technorati.com/tag/ruby
- technorati.com/tag/rails
- therailsway.com
- urbanhonking.com/ideasfordozens
You can download the file Ruby-Rails.opml to easily import all of the above feeds into your own reader.
Since I’m sure there are plenty of other “must have” Ruby feeds and blogs that are not currently on my radar (no word of a lie, I’ve already added more since I put the list together), I openly invite you to write a small entry in your blog as well, and show us what feeds you subscribe to. Please link back to this original post, or I won’t be able to easily find your answer. Consider it a sort of Ruby and Rails feed survey.
And since we’re on the topic, and the amount of feeds that I follow is dramatically reduced now, I’d like to extend an invite for you to do the same thing with Python/Django, Haskell, and Objective-C, assuming you are into any of these communities respectively. Those are the languages that interest me the most and I’d like to start following a good selection of feeds on these topics. If you don’t wish to blog about it, or use the comment section below, you can always write me privately at acangianoATgmail.com, specifying if you are okay with me crediting your list to you. I’d like to collect and organize the most interesting ones in a “results” type of post.
I thank you in advance, as I think it’s an interesting “experiment” that can be quite useful, especially for those who are just starting to learn any of the languages above.
IBM’s Python and DB2 drivers released
I’m glad to inform you that the beta version of the Python and DB2 (IBM databases to be more exact) driver and DBI wrapper have been released in the Python Package Index. You can download the source for version 0.1.0 from here. This includes two components:
-
An IBM defined API based driver to access IBM databases (entirely similar to the Ruby and PHP ones)
-
A Python DBI based wrapper to access IBM databases
The DBI wrapper utilizes the IBM defined API driver, but you can also use the feature-rich API indipendently without the DBI wrapper.
I plan to provide a few examples about the usage of the IBM specific API. The Python driver is almost identical to the Ruby one, hence I may create a joined post for both languages. Now go try it and have fun. If you have any questions, feel free to comment below or send an email to the address opendev@us.ibm.com.
