Frankly, it’s not easy. At all (actually this is why I think MySQL is so popular, because of the ease of installation!) So hang tight and read on.

Installation

Russ Brooks says it is better to avoid MacPorts: I must say that indeed, I tried installing PostgreSQL with MacPorts and I got seriously stuck, unable to do anything with it, not even starting the server. So I uninstalled the PostgreSQL MacPorts package and found other options: a PostgreSQL for Mac installer, and Marc Liyanage’s own installer. I decided to go with the first one, since Marc’s installs version 8.1 of the server, and PostgreSQL for Mac offers version 8.3.

The installation goes without trouble, using a standard installer (which means that you need administrative privileges, as usual). However, you want to read these explanations before doing anything ;)

NOTE: if you have trouble installing PostgreSQL using the above installer (as I did after the unsuccessful MacPorts installation / desinstallation), open Terminal.app and try these commands:

$ sudo dscl localhost >cd Local/Default/Users/ >ls

If you see a “postgres” entry in the list of local users, delete it and re-run the installer:

>delete postgres

After the Installation

The installer puts the PostgreSQL installation into /Library/PostgreSQL8. You should add the path to the PostgreSQL binaries in your PATH environment variable before doing anything else:

export PATH=/Library/PostgreSQL8/bin:$PATH (bash) setenv PATH /Library/PostgreSQL8/bin:$PATH (tcsh)

Then, type the following commands to create the default database, owned by the “postgres” user:

cd /Library/PostgreSQL8/ sudo rm -r data sudo mkdir data sudo chown postgres:postgres data cd bin sudo -u postgres initdb -E utf8 /Library/PostgreSQL8/data

In my case (Leopard-powered PowerBook G4) I had the “Shared Memory error” that Russ talks about. So I followed his advice: I created a file named /etc/sysctl.conf with the following contents, then rebooted my computer and everything went fine:

kern.sysv.shmmax=4194304 kern.sysv.shmmin=1 kern.sysv.shmmni=32 kern.sysv.shmseg=8 kern.sysv.shmall=1024

I also used dscl to change the password of the postgres user (otherwise, how to know which is it??)

>passwd postgres postgres

The installer adds some handy utilities on your /Application folder (see the image above). You can also use pgAdmin to manage the database server. Very handy. I tried to use phpPgAdmin but without success (can’t get past the login screen… :(

And that’s it! There are interesting resources out there explaining how to use it from Rails or Django, so I’ll start reviewing them…

This single issue happens all the time, in garbage-collected and non-managed languages, static and dynamic, weakly and strongly typed; you have a handler variable “pointing” to an object, and before calling any methods on it, you’d better be sure that the object is there; you end up using assertions, “if” statements (and all of its variants), boilerplate code all over the place, when everything you want to do is to call that damn method. It’s frustrating, time-consuming and oh so common that we just try to not to think about it anymore. In Objective-C there is an easy solution to this problem: you can safely send messages to (which is roughly equivalent to “call methods on”) nil, but of course, not everyone likes that. I think that this single feature is responsible for a big deal of “user perceived stability” in the whole Cocoa runtime; it exchanges a what could be a potentially fatal, low-level and unrecoverable error (leading to a complete application crash) into a purely functional one; “look, I’ve clicked here and nothing happens!”. The application does not crash anymore, it just does not do what it should, because the object that should have received the message is not there. The user has a smoother experience, and this means a lot in the long term.

The beauty here, shared by Objective-C and Ruby (and as far as I understand, Smalltalk and other languages), is that messages and method implementations are decoupled; you can forward messages from one object to another, creating chains of responsibility; you can log messages before you execute them (doing some aspect-oriented stuff without all the marketing fuss); you can change the implementation (or even remove it and place it somewhere else altogether) without breaking your clients. It brings a whole lot of power, with the small overhead of having a runtime process dispatching methods, which is, yes, takes slightly longer than a virtual method call, and (of course) even longer than compile-time bound method call.

I think that dynamic languages have a definitive advantage in this field, and this is why I prefer them in environments with requirements evolving constantly, where clients more often than not request new features and where you must reduce maintenance costs; not having your app crash in your face is a good sign of software, and languages that allow you to deliver them are fundamental.

Creating this project I have had a practical experience comparing both Django and, of course, Rails. The subject is not new in this blog; however, this time I could play with both frameworks and as such, I can bring my small amount of confusion in this big framework tar pit. Personally, I found Django and Rails much more different than I previously thought. Both frameworks tackle similar problems, sometimes in similar ways; however; but this does not make for a real similarity between both. They have different philosophical approaches to the problem. This must surely have to do with the underlying programming language and their philosophies.

That said, I found Rails much easier to use. It took me far, far less time to do a similar small application in Rails than it took me to do it on Django. And I must say that when I first used Rails, I had never seen a line of Ruby in my life. I will list some pros and cons that I found in the process:

Good things about Django:

• The “automatic administration system”; impressive! (but you can get it in Rails with some external plugins like Streamlined… but in any case it’s a handy thing to have it already in the system!)
• The form subsystem; great!
• Django does not force you a folder layout; nice!
• The Django Book + documentation: really great resources, nothing to say about that.
• The deployment procedure: really much easier than Rails! We’re in something really close to PHP here, while Capistrano has much more to do with Java’s Maven or even makefiles :)
• The native support for RSS feeds! This is a godsend.

Bad things about Django:

• No native support for “environments”, like in Rails; you cannot separate easily the settings for development, testing and production (and you can add more environments if you want!)
• No native support for REST architectures, or at least “easy” AJAX + API support (like the one you find in Rails)
• The “syncdb” system that ships with Django is, at most, primitive, compared to Rails migrations.
• There doesn’t seem to be a built-in infrastructure for tests. There is a primitive built-in test infrastructure. You can add “doctests” to your views and models, and this way you’re “documenting and testing” at the same time. Sorry, but I don’t buy this. Tests are tests, docs are docs. Rails, thanks to rakefiles and unit, functional and integration tests, seems is a much more advanced platform in this sense. You can get even stats of your projects with it! You can test them! Extract the docs! Everything! This is something lacking in Django. Really. Not to speak about the lack in Python of something similar to RSpec, which just by itself justifies the choice of Ruby and Rails in this field.
• Lack of integrated logging. Can you believe this? I had to find an external source of inspiration for this.
• The naming of “Views” for “Controllers” (or said otherwise, the MTV instead of MVC thing) does not make sense to me. Even in WebObjects and Cocoa “views” are, well, “views”…
• The commands for creating, starting or using an application from the command line are slightly harder to remember (or maybe in Rails are just far too easy to remember!)
• The template system; I do not want to learn another language for that. Django uses a really limited one for this matter, and I prefer Rails’ (default) one in this case.
• Finally, Python; I just can’t get used to this language’s syntax. But I can live with that ;) It’s a matter of personal taste, simply.

Of course, these impressions have nothing to do with the power of the platform! Python is a powerful language, and many of the “newbie” observations above have to do with my own lack of knowledge about it. But first impressions count!

In any case, I liked playing with Django & Python; I’m happy to have learnt something new!

Update, 2009-02-26: I’ve posted the code in Github now, and also I’ve fixed its compatibility problems, and now it works with Django 1.0.2.

So how to proceed? Follow these instructions:

1. Open Terminal.app
2. $ sudo gem update --system
3. $ sudo gem install rails
4. $ sudo gem update

If you just do “gem update”, then the current Rails installation will be broken. You must do ‘gem install rails” (which seems odd, because it was already installed, after all). The thing is that since you’ve updated RubyGems with the command 2) above, then you need to re-install Rails. I haven’t tried with other gems, but it could be the same situation for them.

Update, 2007-12-19: Here’s another solution for this problem!

• Paris on Rails : “On ne remplace pas le cerveau d’un ‘bon’ développeur !”
• Um brasileiro no Paris on Rails (with two photos where you can spot me if you look carefully ;)
• On the road….to Javapolis: Paris (with a link to this blog :)

I will add more links as I find them; and don’t hesitate to add yours in the comment section below!

After the lunch break, these were the highlights of Paris on Rails:

1. Christophe Porteneuve talked about Prototype, the project where he is one of the core developers, and also author of THE book about Prototype! Great stuff: he explained everything there’s to know about JavaScript bindings (and the Prototype “bind” method); he also gave an excellent overview of the enumeration methods of Prototype (incredible stuff!), the new Response object in the latest version of Prototype, and also a nice talk about event bubbling. JavaScript 2000%!! To sum it up: this guy is a great presenter, very funny and knowledgeable, and his speech is more than worth the trip to Paris!
2. Sylvain Perez and Guillaume Desrat (president of Ruby France and rubyist since 2002!) enlightened us about how they introduced Rails in RBC Dexia Investor Services making it interact with their SOA, DataWarehouse and backend services, what were the challenges (some), the rewards (many) and the tradeoffs (a few) during that integration. Maybe that “Thought Leader” of James Mc Govern will finally understand that not only Rails is ready for prime time… but it is already used in big “enterprisey” environments!
3. Alexis Moussine-Pouchkine and Jean-François Arcand gave an extremely interesting talk about JRuby, GlassFish and Java in general, and how Ruby is slowly gaining momentum in the Java world! And Jean-François made it really fun to follow thanks to his nice Canadian accent :)
4. David Heinemeier Hansson himself direct from Chicago! He talked over the iChat link about all the new features of Rails 2.0, about backward compatibility issues and how to solve them.
5. Finally, Jean-Michel Garnier from 21croissants (a Barcelona-based RoR company) convinced us that testing is a really important thing to do (which you already knew, by the way, isn’t it?) and how to use RSpec, rcov, CruiseControl.rb, Test::Unit and Selenium in your applications, putting it in context (historically, citing Fred Brooks and Kent Beck, and methodologically, citing Martin Fowler). As Jean-Michel said in his speech, 2008 will be the year of RSpec; and when I look at it, I think he’s right: in RSpec, the spec is the test; the spec is the doc; the doc is the spec. And the other way around, too :)

It is interesting to see some trends in the current Rails landscape:

• There’s an interesting ongoing debate about IDEs: Aptana (ex-RadRails), NetBeans, Visual Studio or… TextMate?
• JRuby is available in stable form: there’s a bunch of new opportunities opening right now!
• Ruby and Rails are both getting the “acceptance status seal” of big companies: it is no longer a “toy” technology.

One thing is fundamentally true: this platform has taken the world as a storm. I’ve first blogged about it in July 2005, and I firmly believe today that any serious software developer should (at least) learn a little bit about it. Rails is here to stay, whether you like it or not. Compare my reports to what happened in Paris on Rails 2006: lots of things have happened in the Rails world, and more are bound to happen in 2008.

All in all, an excellent conference, with around 220 people attending it, from France, Switzerland, Luxembourg, Belgium and even Spain! I’d be happy to talk here next year ;)

Update, 2007-12-11: Peter Sayer, whom I met yesterday in the conference, and shared a few impressions about the current Rails landscape, has published a very good article about it!

1. An introduction to Ruby and Rails done by Laurent Juillard from nuxos: interesting for those that never used Ruby before, and a good thing to do given the number of people in the room that are new to the platform in general. Otherwise, quite boring for those of us who already use it :) But the right thing to do nevertheless.
2. A real-life use case of Ruby on Rails, shown by Aurélien Géron from Wifirst: a very interesting explanation of a company that chooses to jump on the Rails wagon, with answers to both the “why” and the “how”. Very funny explanation of how they had to deal with the Pythonistas inside the company who wanted to use Django instead :) The most interesting thing about this talk is the fact that they will release their webmail application as open source!
3. Yann Lugrin, CTO of Liquid Concept (from Lausanne!) explained about the trouble to “internationalize” a Rails application (particularly about the IMHO biggest problem in Ruby: the lack of direct UTF-8 support!), and how you can use the Globalize plugin to make your sites multi-lingual and multi-cultural. I’m happy I’ve used it to make Parking Friend available in several languages :) Globalize rocks!
4. Finally, Nicolas Mérouze from Yeastie Mobs talked about HAML as an alternative to ERB as the template language for Rails, and how it compares to other options like Markaby or DRYML or MasterView. Very interesting! HAML seems a little bit “Pythonesque” for my taste :) but that’s my opinion. Nicolas also made an interesting comment about SASS and Blueprint, which I had heard about, but never looked at in detail.

In any case, I still have trouble with the technical names and buzzwords in French :) I’m too used to the English versions! Other than that, a nice first part. Let’s see what comes in the afternoon! Now it’s time to have something to eat :)

Update: Read the afternoon report!

Stay tuned!

To celebrate, I’ll be at Paris on Rails next Monday; will you be there too?

For those interested, Django is a powerful, MVC framework for creating web applications using the Python programming language. It is very similar in some respects to Rails, but some consider Django to be better suited for high-traffic websites. I haven’t used Django extensively (nor Python as a matter of fact, besides the typical “Hello World” thingy) so I won’t say anything else but the fact that I prefer Ruby‘s syntax to Python’s.

Of course this is a subjective opinion! In any case, if it’s anything like Rails, it’s worth considering. Definitely. Dynamic languages are the way to go.

Update, 2008-01-11: You might want to check out this other article of mine!