codedifferent.de » Development

Ruby 1.9.1 & Rails 3.0: Bugfix für ‘Invalid .gemspec format’ und RubyGem Warnungen

Christian — Thu, 11 Feb 2010 23:36:16 +0000

Nach dem Upgrade auf Ruby 1.9.1 und Rails 3.0 unter Mac OS X Snow Leopard hatte ich einigen Ärger mit RubyGem Warnungen. Insbesondere, wenn ich den Server innerhalb des Rails-3-Projektes mit dem folgenden Kommando starten wollte:

rails server

Zu Beginn, als ich noch mit dem bundler Gem Version 0.9.3 arbeitete, waren es zwei Arten von Fehlern bzw. Warnungen: Die erste Warnung hat das Termial mit hunderten Zeilen Code gefüllt, wie …

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'

Das Bundler-Team rund um Carlhuda hat den Fehler mit der Bundler Version 0.9.4 behoben … das Problem sollte nach einem Update des Gems also nicht mehr auftauchen.

Das andere Problem war allerdings etwas hartnäckiger. Beim Start des Servers via

rails server

oder beim Durchführen eines Tests via

rake

innerhalb eines Rails-3-Projektes kamen die folgenden Warnungen:

/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 vom Rails-Core-Team hat klar gemacht, dass diese Warnungen kein Rails- sondern ein RubyGem-Bug sind. Ruby 1.9 wird mit einer veralteten RubyGems-Version ausgeliefert … Ruby Version 1.9.1p378 beinhaltet RubyGems 1.3.1. Ich habe natürlich die RubyGems auf Version 1.3.5 aktualisiert mit

sudo gem update --system

aber diese Aktualisierung führte zu zwei RubyGem-Installationen die die Warnungen verursachen.

So, wie kann man das Problem lösen? Ein Löschen von Ruby 1.9.1 und die Neuinstallation haben leider keinerlei Effekt … die Lösung ist im Grunde recht simpel:

Ist Ruby 1.9.1 und Rails 3.0 beta schon installiert …

1. Wichtig: Nach der Installation von Ruby 1.9.1 darf auf KEINEN FALL RubyGems 1.3.5 separat manuell installiert werden – das wäre eine Doppelinstalltion. Das sollte man unbedingt beherigen, wenn man die wunderbare Beschreibung von Dan Benjamin, wie man Ruby, RubyGems, und Rails auf Snow Leopard installiert nutzt.

2. Wenn man also Ruby 1.9.1 installiert hat, RubyGems auf 1.3.5 und Bundler auf 0.9.4 upgedated und Rails 3.0 installiert hat, ist das einzige was man tun muss folgendes:

sudo gem uninstall rubygems-update

Das wars. Keine Fehler mehr!

Falls Ruby 1.9.1 und Rails 3.0 noch nicht installiert ist …

1. Man kann mit Dan Benjamins Rezept starten und modifiziert die Befehle für download, make und install von ruby-1.9.1-p378.tar.gz. Wichtig ist natürlich, dass man rubygems-1.3.5.tgz NICHT wie angegeben installiert.

2. Dann wird das veraltete RubyGems mit folgendem Kommando aktualisiert:

sudo gem update --system

3. Jetzt sollten die Gems rake und sqlite3-ruby installiert werden.

4. Schließlich werden noch die weiteren Gems und rails –pre installiert, wie in den Rails 3.0 beta Release Notes beschrieben.

5. Nach der erfolgreichen Installation von Rails 3.0 beta fehlt noch der entscheidende Schritt:

sudo gem uninstall rubygems-update

6. Am Ende gilt es nur noch zu prüfen, ob einige Gems noch aktualisiert werden können bevor man sich in Rails 3.0 stürzen kann …

sudo gem update

Hope this helps … und hoffentlich spart es etwas Zeit Thx Andy für den Hinweis

WordPress, .htaccess und der MAMP-Startseiten-Fehler

Christian — Tue, 12 Jan 2010 23:46:34 +0000

MAMP, eine lokale Webserver-Umgebung auf dem Mac, eignet sich immer wieder wunderbar für das Testen, Entwickeln und Gestalten mit WordPress. MAMP bringt Apache, MySQL und PHP fertig konfiguriert in einem eigenen Verzeichnis mit. Leider kann die Installation und Konfiguration eines WordPress-Blogs den Zugriff auf die MAMP-Startseite verhindern:

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

Das ist natürlich mehr als ärgerlich, da von der Startseite aus beispielsweise die Konfigurationseite phpMyAdmin, zur Administrierung der MySQL-Datenbank, nicht mehr erreichbar ist.
Bei mir lag es an einer falsch platzierten Datei: Beim Konfigurieren der WordPress-Installation über das Web-Interface wurde eine .htaccess-Datei fälschlicherweise im Root-Verzeichnis meiner Festplatte abgelegt. Etwas beunruhigend – aber ein lösbares Problem

Wie immer: Die Lösung ist wie immer auf eigene Gefahr … insbesondere das Terminal ist ein wunderbares Werkzeug … mit dem man aber auch viel kaputt machen kann!

Die Datei fällt im Finder nicht auf, das sie wie alle Punk-Dateien in UNIX normalerweise nicht angezeigt werden. Also bemüht man das Terminal und sieht sich das Root-Verzeichnis der Festplatte mal genauer an:

cd /

dann

ls -la

Findet sich dort die Datei .htaccess, sollte man sich vor dem Löschen bzw. Umbenennen nochmal den Inhalt genauer ansehen:

cat .htaccess

Am Einfachsten ändert man ihren Namen und macht die Datei sichtbar:

mv .htaccess htaccess-backup

So erscheint die Datei wieder im Finder und richtetet kein Unheil mehr an … wenn man sich sicher ist, dass man die Datei auch nicht mehr braucht, kann man sie natürlich jetzt auch im Finder einfach in den Papierkorb ziehen

RailsConf 2009 in Las Vegas: Registrierung möglich und Beiträge gesucht

Christian — Sat, 24 Jan 2009 19:46:18 +0000

Seit heute ist die Registierung zur – wohl wieder größten – Ruby-on-Rails-Konferenz in den USA möglich: RailsConf 2009. Wie in den vorigen Jahren organisiert O’Reilly wieder das Event. Dieses Mal findet die Konferenz allerdings nicht in Portland sondern in Las Vegas statt – nicht nur das Glücksspiel- und Vergnügungszentrum der USA sondern auch ein begehrter Konferenzstandort
Für die Schnellentschlossenen bis zum 16. März winkt ein Early-Bird-Bonus mit dem sich 200 USD sparen lassen.
Für alle die auf der Konferenz einen Vortrag halten wollen, wurde das Abgabedatum für einen Call for Participation bis zum 17. Februar 2009 verlängert. Da heißt es also schnell sein!
Die Konferenz selbst findet dann vom 4. bis 7. Mai 2009 im Las Vegas Hilton statt.

Viva Las Vegas!

Quellen: rubyonrails.com, RailsConf.com

Problemlösung: 500 Internal Server Error nach WordPress 2.7 Update auf 1und1-Server

Christian — Mon, 12 Jan 2009 20:54:29 +0000

Problem: Nach dem Update des Blogs auf WP 2.7 lief alles bestens. Nur bei manchen Plugins streigte der Server mit “500 Internal Server Error” insbesondere Plugins wie “XML Sitemap Generator for WordPress” oder beim Hochladen von Bildern. Nach dem Aktivieren des “StatPress Reloaded”-Plugins war dann sogar der gesamte Admin-Bereichs des Blogs unerreichbar.

Diagnose: PHP geht der zugeteilte Arbeitsspeicher aus.

Lösung: Auf einem eigenen Root-, Dedicated- oder Virtual-Server ist der Bugfix einfach – hier muss nur die zentrale Einstelldatei für PHP, die php.ini geändert werden und PHP etwas mehr Speicher zugewiesen werden. Auf einem Shared-Hosting-Server wie bei den Webhosting-Angeboten von 1und1 hat man jedoch meist keinen direkten Zugriff auf die php.ini. Hier hilft ein einfacher Kniff:

Man erstellt eine Textdatei mit dem Namen “php.ini” und dem folgenden Inhalt:

memory=20MB

Diese Datei legt man in den Ordner /wp-admin/ der eigenen WordPress-Installation.

Das wars!

jQuery-Tutorials und Plugins für das JavaScript-Framework

Christian — Thu, 08 Jan 2009 18:24:01 +0000

Florian hat auf drweb.de eine lange Liste an Plugins und Tutorials für das beliebte JavaScript-Framework jQuery zusammengetragen. Nicht nur für alle Ruby-on-Rails-Entwickler spannend – sondern im Grunde für jeden Web-Developer der sich das elegante JS-Framework genauer ansehen und damit arbeiten will. Ich hatte das Glück die Präsentation von Yehuda Katz, inzwischem im Plugins-Team von jQuery, auf der RailsConfEurope 2008 zu sehen … war wirklich klasse … ein Blick auf die weiterhin online verfügbraren Präsentations-Slides lohnt sich auf alle Fälle!

Herzlichen Dank nochmal an Florian!

Sicherheitsupdate für WordPress 2.6.2 schliesst die Sicherheitslücke von php mt_rand()

Christian — Tue, 09 Sep 2008 10:03:39 +0000

Das Entwickler-Team der Open-Source Blog-Software WordPress hat gerade die Version 2.6.2 als Sicherheitsupdate veröffentlicht. Die Aktualisierung der eigenen WP-installation ist dringed zu empfehlen – insbesondere, wenn man auf seinem Blog die Regisitrierung für jeden ermöglicht.

Das Update schließt eine Sicherheitslücke, die von der schlechten Implementierung der php-Funktion mt_rand() in vielen populären php-Installationen verursacht wird. Diese Funktion wird für das Seeding des Zufallsgenerators verwendet – und ein guter Zufallsgenerator ist die Grundlage für starke Passwörter und Verschlüsselung. Auch das Sicherheitsrisiko durch überlange Input in MySQL- und SQL-Datenbanken wird mit dem Update adressiert. Stefan Esser hat die beiden Sicherheitsprobleme aufgedeckt … die sicher eine Reihe von php-basierten Open-Source-Projekten betreffen. Danke Stefan!

Neben dem Schließen der beschriebenen Sicherheitslücken sind auch einige kleinere Bugfixes in die Version WP 2.6.2 eingeflossen. Das Upgrade lohnt sich also für alle WP-Nutzer!

Rails Hackfest belohnt den Gewinner mit freiem Eintritt zur RailsConf Europe

Christian — Wed, 06 Aug 2008 13:49:51 +0000

Pratik Naik vom Rails-Core-Team hat gerade ein neues Ruby on Rails hackfest vorgestellt: Monatsgewinner wird derjenige, der die meisten Patche veröffentlicht, die auch in Rails core aufgenommen werden.
Im August bekommt der Gewinner – dank O’Reilly – als Preis freien Eintritt auf die RailsConf Europe. Keep on coding!

Vortrag auf der RailsConf Europe zu “Design on Rails for Usability”

Christian — Tue, 05 Aug 2008 07:10:21 +0000

Vom 2. bis 4. September 2008 findet zum dritten Mal die RailsConf Europe in Berlin statt. Schon letztes Jahr eine Konferenz zum Wohlfühlen – und ein Ort an dem viele der Köpfe hinter Ruby on Rails in der Kaffee-Pause plötzlich neben dir stehen und man die Developer-Community hautnah erlebt. Bei aller Virtualität ist Face-to-Face-Kommunikation die Seele der Community.
Jedem Rails Developer, der es sich einrichten kann, kann ich das Event nur ans Herz legen. Und alle die elegant Webapplikationen entwickeln wollen, aber noch nicht mit Ruby on Rails arbeiten, kann man die Konferenz erst recht nur empfehlen.
Eine Gruppe, die ich bisher an Ruby on Rails Konferenzen besonders vermisse sind die Designer. Denn gutes Applikations- und Interaktionsdesign, gute Usability von Webapplikationen lassen sich nur erreichen, wenn Developer und Designer zusammenarbeiten – und dafür müssen Developer etwas von Design und Designer etwas von Developern verstehen. Deshalb freut es mich ganz besonders, dass mein Proposal genau zu diesem Thema angenommen worden ist. In meiner Dopplerolle als Developer und Designer geht es in meinem Vortrag auf der RailsConf Europe um:

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

Ich freue mich riesig auf die Konferenz – und darauf mal wieder ein paar codedifferent-Blogleser real zu treffen! Und nicht vergessen: Vor der Konferenz noch eine Bratwurst-on-Rails!

Auch dieses Jahr wieder: “Bratwurst on Rails” in Berlin am 01.09.2008 vor der RailsConf Europe

Christian — Wed, 30 Jul 2008 10:29:05 +0000

Die berliner Ruby Usergroup hängt sich auch dieses Jahr wieder schwer für die Community ins Zeug: In der Kalkscheune, nicht weit vom Veranstaltungsort der RailsConfEurope 2008 laden sie alle Ruby-on-Rails-Begeisterten zu einem Networking-Event ein.
Schon im letzten Jahr war das wirklich ein klasse Event – einige Fotos finden sich bei Flickr. Eine gute Developer-Community muss auch Feste feiern können – eins weiß ich gewiss: Ja, wir können!

Also, für alle Ruby-on-Rails-Enthusiasten die am 01.09.2008 – dem Vorabend der RailsConf Europe in Berlin sind: Meldet euch bei Bratwurst-on-Rails an! Wir sehen uns dort!

Schon jetzt: Herzlichen Dank an die Ruby User Group Berlin für die Orga!

HowTo: Ubuntu-Server update via terminal von 7.10 Gutsy Gibbon to 8.04 LTS Hardy Heron

Christian — Tue, 06 May 2008 21:00:31 +0000

Hier ein paar Probleme und deren Lösung beim Update eines Ubuntu-Servers 7.10 (Gutsy Gibbon) auf die neueste Version 8.04 LTS (Hardy Heron). Der “offizielle” Upgrade-Pfad, der auf der Ubuntu Website beschrieben wird hat leider bei mir nicht ganz geklappt – und vielleicht gibt es da draußen den einen oder anderen, der auf die selben Probleme stößt

Noch einige Warnungen bevor ich loslege: Backup des Servers nicht vergessen! Die nachfolgende Beschreibung ist nur für die Leser zur Nachahmung gedacht, die wissen was sie mit ihrem Kommandozeilen-Terminal tun. Natürlich auf eigenes Risiko!

Problem 1: Ich nutze bisher apt-get statt aptitude … beide Systeme darf man jedoch nicht parallel nutzen!
Lösung: Kein Problem, die im offiziellen Upgrade-Pfad beschriebenen Schritte lassen sich auch mit apt-get statt mit aptitude erledigen. Die Kommandos sind also:
$ sudo apt-get update $ sudo apt-get upgrade $ sudo apt-get install update-manager-core $ sudo do-release-upgrade
Bitte NICHT am Ende des Upgrades restarten … Warum? Siehe Problem 3!

Problem 2: Das do-release-upgrade Script startet, bricht dann den Upgradevorgang ab und gibt an, dass auf der boot-Partition nicht genügend freier Speicherplatz zur Verfügung steht:
The upgrade aborts now. The upgrade needs a total of 52.4M free space on disk '/boot'. Please free at least an additional 18.1M of disk space on '/boot'. Empty your trash and remove temporary packages of former installations using 'sudo apt-get clean'.
Lösung: Als erstes kann man die Paketverwaltung mit dem vorgeschlagenen Kommando aufräumen:
$ sudo apt-get clean
… allerdings reichte das auf meinem Server nicht aus. Beim Durchsehen der installierten Pakete wurde klar, dass noch eine Reihe alter Kernel-Versionen installiert waren. Und die liegen alle in der boot-Partition und können zum Teil ohne Probleme gelöscht werden. Mit dem folgenden Kommando läßt sich überprüfen, welche Kernel-Versionen auf dem eigenen Ubuntu-Server installiert sind:
$ dpkg -l | grep linux-image
In meinem Fall konnte ich das alte linux-image-2.6.15-29 und das linux-image-2.6.17-12 ohne Probleme löschen. Doch Vorsicht, die neuesten Versionen des Kernels sollte man unangetastet lassen – so hat man immer eine Fallback-Position.
$ sudo apt-get remove --purge linux-image-2.6.15* $ sudo apt-get remove --purge linux-image-2.6.17*
Nach dem Löschen der alten Kernel-Versionen muss die menu.lst aktualisiert werden:
$ sudo update-grub
Danach checke ich zur Sicherheit immer nochmals, ob die Kernel-Liste nun korrekt ist. Dazu öffnet man die Datei einfach in einem Texteditor – wie vi:
$ sudo vi /boot/grub/menu.lst
Wenn die “automatic kernel list” am Ende der Datei in Ordnung ist, kann man nochmals versuchen den Upgrade-Vorgang zu starten.

Problem 3: Die Ubuntu-Geeks haben dieses Problem beim Update auf 8.04 schon selbst gelöst. Doch beim Upgrade von Feisty Fawn auf Gutsy Gibbon hatte ich richtig Probleme: Das do-release-upgrade funktionierte ohne Fehlermeldung, doch als ich den Server neustarten wollte bootete er nicht! Über das Safety-System des Servers konnte ich den Übeltäter schließlich ausmachen: Die Kernel-Liste war vom do-release-upgrade-Script nicht korrekt angelegt worden!
Lösung: Aus diesem Grund beende ich das do-release-upgrade-Script niemals mit einem Neustart des Servers. Vielmehr re-aktualisiere ich als ersten Schritt die Datei menu.lst:
$ sudo update-grub
Danach checke ich die Kernel-Liste wie oben beschrieben mit einem Text-Editor – hier vi:
$ sudo vi /boot/grub/menu.lst
Ist die “automatic kernel list” am Ende der Datei korrekt, kann man endlich den Neustart des Servers vornehmen.
$ sudo restart

Nach dem Upgrade und dem Restart des Servers sollte dieser wieder via ssh verfügbar sein. Dann läßt sich als kleine Bestätigung die Version der installierten Linux-Version abrufen:
$ lsb_release -a
Das Ergebnis sollte wie folgt aussehen :
No LSB modules are available. Distributor ID: Ubuntu Description: Ubuntu 8.04 Release: 8.04 Codename: hardy
Ich hoffe dieses HowTo bzw. die Beschreibung möglicher Probleme und ihrer Lösungen helfen euch etwas Zeit einzusparen die man bei dem guten Wetter sicher besser nutzen kann