I was deeply moved by Your commencement speech in Stanford as I am when I watch it today …

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

Forbidden
You don’t have permission to access /MAMP/ on this server.
Apache/2.0.63 (Unix) PHP/5.2.11 DAV/2 Server at localhost Port XXXX

That’s a big issue, as the start page links to the local phpMyAdmin page for MySQL-database configuration. So you cannot admin the database anymore.
I traced down the problem to a wrong placed file: When I configured the WordPress installation via the web-interface, an .htaccess file was placed in the root directory of my harddrive. Quite scary … but a problem which can be fixed easily

As always: no guarantee and on your own risk … especially the Terminal is a wonderful tool … but if you do the wrong thing, you may be in serious trouble!

You normally do not recognize the .htaccess file within the Finder: all filenames starting with a dot are hidden files in a UNIX system … and the Finder does not show those hidden files. But if you use the Terminal, you can look at all the hidden files easily.
So fire up the Terminal app and go to the root directory of your hard drive:

cd /

then looks at all the files in your root directory:

ls -la

If you find a .htaccess there … you probably found your problem. But look inside the file before your rename or delete it:

cat .htaccess

The easiest way to proceed is to rename the htaccess file:

mv .htaccess htaccess-backup

This way the file is shown in the Finder again and does not confuse your MAMP installation. If you know what to do you can delete the renamed file now within the Finder and drag it to the trash

• Those more than 800 million mobile devices have different screen sizes, different buttons or keyboards and some even have a touch screen. That does not help developers to create stunning GUIs on mobiles where every little pixel needs to be arranged.
• Flash is very performance hungry. That’s why they had to shrink it down to Flash Light – but even flash light is struggling with performance issues on many of the 800 million devices.
• Adobe does not provide a application store infrastructure for its developers … maybe one of the biggest issues of all

But on March 6, 2008 an other threat to Flash and Flash Light appeared: Steve Jobs introduced the iPhone SDK which provided a easy way to create third party applications for the iPhone with high mobile performance and the ability to take advantage of most of the sensors – like touchsceen, accelerometer, microphone, camera. And Apple solved one of the biggest hurdles for mobile application developers: They provided an easy application store solution for the developers to sell their apps or distribute them for free. And also the market for these native iPhone applications is quite attractive: There are more than 50 million iPhones and iPod touch devices out there – all of them having the exact same screen size, all of them having a touch sceen, all of them having an accelerometer. Apple attracted a lot of independent developers as well the big names in game industry with their mobile application ecosystem.
Bringing Flash support to the iPhone Safari web browser was blocked by Apple because of those big performance issues. Apple also did not license Flash Light for the iPhone – quite logic because they built up their own developer base and their own mobile app ecosystem.
The only chance Adobe had was to built up an “injection”-strategy and develop their Flash authoring tool into an Objective-C & Cocoa code generator which allows Flash developers to create native iPhone applications by the press of a button. Then the Flash developers can upload their app to the iTunes AppStore and use it as a selling and distribution channel.
This probably wasn’t an easy job and it will be quite interesting to watch Apple’s reaction on this move. It probably will have a massive effect on the AppStore as this will flood the store with new apps: More creativity and more junk.

Louis Gerbarge spotted the technical issues of the Adobe Flash to native iPhone code generation – and takes a look on the performance and private API issues of the beta version of the CS5 solution. His post makes clear that taking the Flash way won’t offer the Flash developers the features and beauty of the uncountable iPhone SDK 3.x APIs.

Viva Las Vegas!

Sources: rubyonrails.com, RailsConf.com

Diagnosis: PHP is running out of memory.

Solution: If you are running your own root, dedicated or virtual server this is an easy bugfix: You just have to change the php.ini of your server and provide more memory to your PHP installation. On a shared hosting server – like at the webhosting solutions at 1and1 you often don’t have access to that central php.ini. But there is an easy workaround:

Create a text file and name it “php.ini” (without the quotes ) and with a single line of code in it:

memory=20MB

This file has to be placed into the directory /wp-admin/ within your WordPress installation.

That’s it!

Thanks again to Florian for sharing these great links!

The update fixes a security issue caused by the weak implementation of the php function mt_rand() in many popular php-distributions. The function is used for seeding the random number generator. It also addresses the security risk of MySQL and SQL column truncation vulnerabilities. Stefan Esser reported both security-issues which are probably relevant to a lot of other php-based open-source projects. Thanks, Stefan!

Beside the fix of security issues, the WordPress version 2.6.2 also implements some minor bugfixes. Therefor the upgrade to the newest version of WP is highly recommendet to everybody using WordPress.

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.