rails server

At first, when running on bundler 0.9.3, I had two types of errors. The first NoMethodError populated the terminal with hundreds lines of code, like …

WARNING:  # NoMethodError: undefined method ` ' for nil:NilClass 
# -*- encoding: utf-8 -*-
...
WARNING:  Invalid .gemspec format in \
'.rvm/gems/ruby-1.9.1-p378/specifications/spec.gemspec'

The bundler-team around Carlhuda fixed that issue within bundler 0.9.4. So that problem will not occur any more.
The other problem was quite persistent. When starting the server via

rails server

or doing a test via

rake

within the rails-3-project resulted in a bunch of warnings:

/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:14: \
warning: already initialized constant VERSION
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:14: \
warning: already initialized constant RubyGemsVersion
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:194: \
warning: already initialized constant MUTEX
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:196: \
warning: already initialized constant RubyGemsPackageVersion
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:202: \
warning: already initialized constant WIN_PATTERNS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1079:\
 warning: already initialized constant MARSHAL_SPEC_DIR
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems.rb:1084: \
warning: already initialized constant YAML_SPEC_DIR
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/version.rb:72: \
warning: already initialized constant VERSION_PATTERN
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/requirement.rb:20: \
warning: already initialized constant OPS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/requirement.rb:30: \
warning: already initialized constant OP_RE
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/version.rb:246: \
warning: already initialized constant Requirement
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/dependency.rb:18: \
warning: already initialized constant TYPES
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/platform.rb:171: \
warning: already initialized constant RUBY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/platform.rb:177: \
warning: already initialized constant CURRENT
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:39: \
warning: already initialized constant NONEXISTENT_SPECIFICATION_VERSION
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:50: \
warning: already initialized constant CURRENT_SPECIFICATION_VERSION
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:56: \
warning: already initialized constant SPECIFICATION_VERSION_HISTORY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:72: \
warning: already initialized constant MARSHAL_FIELDS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/specification.rb:75: \
warning: already initialized constant TODAY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/source_index.rb:593: \
warning: already initialized constant Cache
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:14: \
warning: already initialized constant DEFAULT_BACKTRACE
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:15: \
warning: already initialized constant DEFAULT_BENCHMARK
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:16: \
warning: already initialized constant DEFAULT_BULK_THRESHOLD
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:17: \
warning: already initialized constant DEFAULT_VERBOSITY
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:18: \
warning: already initialized constant DEFAULT_UPDATE_SOURCES
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:24: \
warning: already initialized constant OPERATING_SYSTEM_DEFAULTS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:30: \
warning: already initialized constant PLATFORM_DEFAULTS
/usr/local/lib/ruby/site_ruby/1.9.1/rubygems/config_file.rb:53: \
warning: already initialized constant SYSTEM_WIDE_CONFIG_FILE

Jeremy Kemper from the Rails core team pointed out that this is not a Rails problem, but a RubyGems issue. Ruby 1.9 ships with an outdated RubyGems … like 1.9.1p378 ships with RubyGems 1.3.1. I did update RubyGems to Version 1.3.5 by

sudo gem update --system

but this resulted in some duplicated rubygem files, which cause the error.

So how can the problem be solved? Deleting and reinstalling Ruby 1.9.1 does not have any effect … but the solution is quite simple:

If you already installed Ruby 1.9.1 and Rails 3.0 beta:

1. Be sure that you do NOT install RubyGems 1.3.5 separately after the installation of Ruby 1.9.1 – this would result in a double installation. So have that in mind when following the excellent instructions to installing Ruby, RubyGems, and Rails on Snow Leopard of Dan Benjamin.

2. If you already installed Ruby 1.9.1, updated to RubyGems 1.3.5 and bundler 0.9.4 and also installed Rails 3.0, the only thing you have to do is:

sudo gem uninstall rubygems-update

That’s it. No errors any more!

If you did not install Ruby 1.9.1 and Rails 3.0 yet …

1. You may start with Dan Benjamin’s recipe and modify it so you download, make and install the ruby-1.9.1-p378.tar.gz but NOT the rubygems-1.3.5.tgz.

2. Then update RubyGems with the command

sudo gem update --system

3. Ensure that the rake and the sqlite3-ruby gems are installed, too.

4. Now install the needed gems and rails –pre as described in the Rails 3.0 beta release notes

5. After the successful installation of Rails 3.0 beta, you now have to do the vitally important step:

sudo gem uninstall rubygems-update

6. Finally check, if any gem needs an update before diving into Rails 3.0 by

sudo gem update

Hope this helps … and saves some time. Thx Andy for the hint

So, I’m really happy that my  proposal, focussing on that issue, was accepted at the conference. In my double role as a designer and developer I’ll talk about

DESIGN ON RAILS FOR USABILITY … Or why designers should start to understand code and developers should start to sketch and use design methods.

I’m really glad be a part of the conferece in September – and to meet all these interesting people – and hopefully some codedifferent-blogreaders, too And please don’t forget to join Bratwurst-on-Rails on the evening before the conference starts.

April 4th/5th 2008: ScotlandOnRails, Edinburgh, Scotland
http://scotlandonrails.com
conference language: English

May 29th – June 1st 2008: RailsConf 2008, Portland, Oregon, USA
http://en.oreilly.com/rails2008/
organized by O’Reilly – conference language: English

June 9th/10th 2008: Rails-Konferenz.de, Frankfurt, Germany
http://www.rails-konferenz.de
conference language: German

June 10th 2008: Ruby en Rails 2008, Amsterdam, Netherlands
http://2008.rubyenrails.nl
conference language: Dutch

September 2nd-4th 2008: RailsConf Europe, Berlin, Germany
http://en.oreilly.com/railseurope2008/
organized by O’Reilly – conference language: English

There are probably a lot more conferences focussing on Rails … just drop a comment so the list can grow

But the burning questions is: Why!

1. Ruby instead of PHP: At first it sounds rather loose to cold-shoulder the sweat and tears of learning PHP – and dig deeply into a quite young and a pure object oriented language. But everybody I talked to in the last months who came from Java or PHP just told me the same story: It’s no big deal to learn Ruby – and the benefits are overwhelming. Ruby enables you to write elegant, readable and easy to maintain code.
2. Vision-Driven-Community: No matter where you get in contact with the Rails community – at a developers conference or in a mailing-list: The basic mood and vision of the community is friendly, catching, international and productive. It’s all about creating something new, something better and more elegant with the power of the community … take a look at the RailsConf 2007 keynote of David Heinemeier Hansson in Portland.
3. Scalability: By now, there are several examples of high scaling web applications with rails. The only con of Rails applications compared to Zend framework apps is the need of a little bit more hardware. But the pros are worth it: faster development and easier maintenance. Twitter, Qype and Xing show it. Especially, the Twitter developers love to twitter about scalability, like Britt Selvitelle auf der RailsConf Europe 2007 in Berlin.
4. REST: Version 2.0 is a big step towards the principle of Representational state transfer. Now REST is deeply implemented into the Ruby on Rails framework. This makes it easy to create consistent interfaces to other systems. REST was nearly buried in oblivion but it’s a sophisticated and strong feature based on the http protocol. Find out more by the free PDF-book of b-simple focusing on RESTful-Rails.
5. Database-Migrations: Rails offers a powerful script based tool to create and redo database structures called migrations. For projects following the principles of “pragmatic programming” this is a perfect tool to create and improve the whole database schema and fill tables with data. Zend want to have a feature like that, too. There is a proposal for that feature – but nobody knows when this will be implemented and how it will function.
6. Test-Driven-Development: Rails still is one of the leaders in TDD by it’s built in creation of test infrastruktur for automated unit- tests, functional tests and integration tests. Zend Framework tries to catch up with its ZFTestManager – but a conclusive integration into the framework is still missing.
7. MultiView: Within Rails, content can be presented in different ways according to the type of request. You easily can create different views to show the data as a CSV file, an RSS feed, a classical HTML page or as a special iPhone page. SlashDotDash shows, how easy it is to create a special iPhone optimized user interface for a rails app.

But there are some specific projects, which are not well suited for Rails:

• … if the application has to run on a shared-host-webspace: Rails is developed to create professional web apps. A simple webspace package at hosters like 1and1 or godaddy are not suited for the deployment of a rails app. Shared-hoster like DreamHost are positive exceptions as they offer Rails on their shared hosts. But there is a growing number of specialized hosters which offer hosting solutions suited for everybody – from private to enterprise. And sure, Rails runs perfectly on a dedicated root server. Ezra Zygmuntowicz, one of the founders of EngineYard, Bruce Tate and Clinton Begin give a lot of insights in their new book Deploying Rails Applications: A Step-by-Step Guide.
• … if the application has to run on a Windows Server: Ruby on Rails is optimized for UNIX/LINUX based systems. It’s fast on the common web-server infrastructures like the different LINUX distributions as well as MacOS X. On Windows machines the performance is enough for development but not enough for most deployments: Ruby on Rails is about ten times faster on non-Windows machines. So, deployments on Windows Servers are only feasible for small intranet settings where the IT department insists on using Windows as a server OS.
• … if you only need the actual date on a static webpage. In this case Rails as well as the Zend Framework are way to big.
• … if you as a developer do not understand an English word There is a lot of information about Rails out there, and there are localized activities, like the German or Spanish user group. But the community is English focused. Not to forget institutions like Peepcode or Railscasts.

My2Cents