Der Gleisarbeiter

Nach dem ich mich jetzt so einige Zeit mit dem Testen von Railsapplikationen beschäftige, habe ich wieder etwas Interessantes herausgefunden.

Wie kann ich meine Goldberg-Tabelleninhalte möglichst einfach in meine Testdatenbank laden?

Eigentlich ganz einfach:

Im Rails_Root

rake goldberg:dump_bootstrap

aufrufen, damit werden die Tabelleninhalte von Goldberg in das Verzeichnis vendor/plugins/goldberg/db gedumpt und zwar im yml-Format.

In den Functionality/Unit-Tests z.B. in der setup Methode einfach den Befehl

GoldbergMigration.load_bootstrap

aufrufen und die Test-Tabellen werden mit den aktuellen Goldbergdaten gefüllt.

Heute hatte ich ein Problem als ich auf ActiveRecord-basierte Sessions umgestiegen bin. Danach funktionierten rake db:migrate und sämtliche anderen Rake-tasks nicht mehr, es kam immer die Fehlermeldung:

rake aborted
uninitialized constant CGI::Sessions::ActiveRecordStore … usw

Den Rake-Task mit dem Action aufruf habe ich von meinem Kollegen Mr. Matt http://matthall.wordpress.com/2006/12/06/how-to-execute-a-rails-controller-action-via-cron/

Um das Problem zu lösen müssen, die beiden Zeilen

require('action_controller') und
require('action_controller/integration')

in die environment.rb geschrieben werden. Danach lief alles wieder, puh, hat mich 2 Stunden gekostet dieses Problem.

Ab dem 1. Juli werde ich bei der Firma Indiginox GmbH als Gleisarbeiter mit RubyOnRails weiterarbeiten.

Die Firma Indiginox ist ein Beratungs- und Dienstleistungsunternehmen für OpenSource – Softwarelösungen. Sie bietet Ihren Kunden Unterstützung z.B. bei der Beurteilung von OpenSource und Web2.0, sowie bei der Projektumsetzung auf Basis dieser Technologien.

In letzter Zeit kristallisiert sich besonders RubyOnRails als Framework für anspruchsvolle Webapplikationen heraus, und so kam es, dass die Indiginox GmbH eine Stellenanzeige für einen RoR-Softwaredeveloper aufsetzte, auf die ich mich bewarb. Unter Tausenden, wenn nicht sogar Zehntausenden von Bewerbern, wurde ich schließlich ausgewählt Wobei mein Vorteil mit Sicherheit war, dass ich so witzig bin! Und vielleicht noch ein kleines bischen, dass ich bereits mit der Indiginox GmbH als Freelancer zusammen gearbeitet habe.

Anspruchsvolle und interessante Projekte, über die ich zu gegebener Zeit berichten werde, sind schon in Aussicht und die Zusammenarbeit mit Ashley und Matthew läuft gut und wir haben immer viel Spaß Mal schauen wie es weitergeht mit mir als Gleisarbeiter.

Ciao! Und alles Gute an euch da draussen!

Gestern hatte ich folgendes Szenario in einem aktuellen Projekt zu lösen:
Das Rails-Framework Goldberg bietet eine einfache Möglichkeit schnell Webseiten mit Rollensystem/Benutzerverwaltung/etc. aufzubauen. Auch Menüs die von den jeweiligen Rechten eines Users abhängen, können einfach generiert werden. Es gibt vordefiniert 3 Benutzergruppen: Public, Member und Admin.

Einer unserer Menüpunkte hieß “Anmelden”, also ein Login und Registrierungsbereich. Das Problem war, da Member und Admin von Public abgeleitet wurden: Auch ein angemeldeter User der eingeloggt ist und damit Member-Rechte hatte sah diesen Menüpunkt “Anmelden”.

Um dieses Problem zu lösen, musste die Rollenstruktur von Goldberg durchbrochen werden. Zuerst habe ich im Goldberg-Setup eine weitere “Permission” hinzugefügt: “Public ONLY pages”. Nur “Public”-User (also anonyme) haben das Recht solche Seiten zu sehen. Die Seite “Anmelden” erhält dann die Einstellung “Public ONLY page”. Jetzt ist aber das Problem nicht gelöst, da Member direkt von “Public” abgeleitet ist und somit auch das Recht hat “Public ONLY pages” zu sehen. Dazu müssen wir die Ableitung durchbrechen. In der Datenbank findet sich eine Tabelle “goldberg_roles”. In dieser muss der parent_id-Wert von “Member” auf NULL gesetzt werden. Damit wird Member nicht mehr von Public abgeleitet. Um jetzt aber dem Member nicht alle Public-Rechte zu verbieten, müssen wir im Goldberg-Setup die Rechte “Public pages – execute” und “Public pages – view” von Hand zu den Rechten der Gruppe “Member” hinzufügen.

Und das war’s,
hat am Anfang bei mir etwas länger gedauert, aber so sollte der Ablauf eigentlich klar sein. Bei Fragen: kommentieren.

Ciao!

Hallo,

nachdem ich heute mal RadRails auf meinem MacBook installiert habe und versucht habe damit zu arbeiten, musste ich leider feststellen, dass kaum etwas funktionierte. Der Web-Server konnte nicht aus RadRails gestartet werden und auch Controller/Models/… erstellen funktionierte nicht.

Die Lösung liegt in den Einstellungen von RadRails. Hier müsst ihr unter Window -> Preferences -> Ruby -> Interpreter einen neuen Interpreter namens “Ruby” anlegen und den Pfad auf den Interpreter setzen. Bei mir war das /usr/local/bin/ruby.
Unter Window -> Preferences -> Rails -> Configuration sollte man zudem noch die Pfade zu Rails und Rake eintragen, mit Linux/Mac im Terminal zu finden mit which rails und which rake.

Ich hoffe das hat euch weitergeholfen.

Schönen Abend noch!
Happy coding!

Gerade eben habe ich einen interessanten Ansatz für Ruby Programmierung unter Mac OS gefunden. Das Projekt nennt sich RubyCocoa und ist hier zu finden: http://rubycocoa.sourceforge.net/doc/index.en.html

Das Projekt ist bestimmt einmal einen Blick wert.

Heute habe ich festgestellt, dass diese Fehlermeldung beim Installieren eines Gem’s daher rühren kann, dass eine zu alte Rubyversion auf dem Rechner aufgespielt ist. Verwendet ihr Mac OS solltet ihr ausserdem darauf achten die Mac Developer Tools von der DVD zu installieren, falls gems bei der Installation eines aus Rubyplugins mit der obigen Fehlermeldung abbricht.

Happy coding!