Lerne mehr über Ruby on Rails mit Martin Labuschins
Ruby on Rails Link Library.
Was für PHP-Entwickler oder Webdesigner eher ungewohnt ist, kommt bei Ruby on Rails regelmäßig zum Einsatz - die Konsole. Das Terminal (bei Mac OS), die Eingabeaufforderung (bei Windows) oder Putty (bei externen Webservern) gehört bei der Ruby on Rails-Entwicklung zum Pflichtprogramm. Das Anlegen der Anwendung selbst, der Controller, der Models und das Rendern der Scaffolds - das alles geschieht nur über die Konsole.
Rails-Applikation anlegen
Für jede Rails-Anwendung muss eine eigene Umgebung angelegt werden. Man geht dazu per cd in das gewünschte Verzeichniss, z.B. C:webserver. Dort legt man dann das Rails_Projekt an:
rails MeineersteRailsAnwendung
Ruby legt nun einige Verzeichnisse und Dateien an, die gerade einmal dazu ausreichen den Ruby-Server zu starten. Doch vorher sollte man die Zugansdaten des MySQL-Servers in der Konfiguration der Rails-Anwendung angeben.
Tipp (Windows): Es ist empfehlenswert, eine Verknüpfung für die Eingabeaufforderung anzulegen. In der Eigenschaften der Verknüpfung kann man im Feld Ausführen in den Pfad angeben, in dem man bei Starten direkt loslegen möchte. Hier kann auch mit Umgebungsvariablen gearbeitet werden. Beispiel: %HOMEDRIVE%webserver
MySQL-Server konfigurieren
Nun öffnet man mit seinem Editor die Datei database.yml, welche sich im Verzeichnis MeineersteRailsAnwendungnfig befindet. Dort gibt man im ersten Bereich development die Zugangsdaten für die MySQL-Datenbank ein. Wozu die anderen Bereiche da sind, erkäre ich ein anderes mal. Hier alle nötigen Angaben mit Kommentar:
development:
adapter: mysql # der Datenbank-Typ. In 99% der Fälle ist es mysql
database: app_development # der name der Datenbank
username: root # der Benutzer der Datenbank
password: # das Passwort des Benutzers
host: localhost # ort der Datenbank. In 99% der Fälle ist localhost richtig
Ruby-Server starten
Nun bewegt man sich mit der Konsole ins Verzeichnis der Anwendung MeineersteRailsAnwendung und führt folgenden Befehl aus:
ruby script/server
Der Webrick (der eigene Webserver von Ruby) startet nun und macht die Anwendung unter dem Port 3000 verfügabr. Mit dem Paramenter -p kann auch ein anderer Port bestimmt werden.
ruby script/server -p 3001
Die Rails-Anwendung ist nun unter http://localhost:3001 verfügbar. Ohne zusätzliche Angabe eines Ports ist sie selbstverständlich unter http://localhost:3000. Der Standard-Port für Hypetext Tranfer Protokoll (http) ist 80. Dort macht sich aber meist schon der Apache breit. Um eine Rails-Anwendung auf Port 80 laufen zu lassen, müsste der Apache dort zuerst deaktiviert werden.
Der Aufruf der Anwendung wird zu diesem Zeitpunkt immer eine Fehlermeldung zurückgeben, da die Models noch fehlen. Die Fehlermeldung Unknown action sollte euch nicht aus der Ruhe bringen.
Falls man die Rails-Anwendung auf einem externen Server entwickelt und schon eine Domain darauf lenken will, empfiehlt sich der Port 80, da er nicht explizit in der URL stehen muss. Die Rails-Anwendung wäre dann direkt unter http://localhost bzw. http://domain.de verfügbar.
Nun haben wir die Rails-Anwendung angelegt, die MySQL-Verbindung hergestellt und den Server gestartet. Im nächsten Artikel über Rails werde ich euch zeigen, wie ihr mit Models und DB-Tabellen arbeitet und wie sehr euch dabei das Scaffolding-System helfen kann. Wer sich nicht solange gedulden kann, kann einige nützliche Links in meinem Ruby on Rails-Ordner in meiner Bookmarksammlung finden.
Bitte lest euch die Kommentare zu diesem Artikel durch. Ich habe einige Sachfehler erst spaeter korrigiert und kann daher nicht garantieren, dass der Artikel nun vollstaending richtig ist. Ich weise sicherhaltshalber einmal auf meinen Haftungsausschluss hin.
Naja, meine Erfahrungen haben gezeigt, dass MySQL das verbeitetste DB-System ist.
Und das die DB meist auf dem selben Rechner wie der Webserver liegt, ist auch höchstwahrscheinlich.
Die Datenbank wird bei meinem nächsten Artikel benötigt. Daher habe ich sie hier als erforderlich dargestellt. Ich kann mir jetzt auch kaum Daten-Verwaltung von Webanwendungen auf statischer Basis vorstellen. Eine DB gehört meines Erachtens einfach zu Ruby on Rails dazu.
Trotzdem erscheint keine Fehlermeldung, nur weil du keine Models angelegt hast. Die Behauptung ist schlicht falsch.
Ach ja, was ich vorher schon wieder vergessen hatte, weil es noch viel falscher und ein wirklich seltsamer Satz ist:
"Ruby legt nun einige Verzeichnisse und Dateien an, die gerade einmal dazu ausreichen den Ruby-Server zu starten."
Beschäftige dich bitte ein bisschen mehr mit Ruby und dem Rails-Framework, bevor du den Lesern hier so einen Schmarrn erzählst. Danke!
Habe die Sache nun verbessert. Musst aber nicht gleich unhöflich werden. Kontruktiv sein ist ja ok ...
Die meist verbreitete Lösung für mehrere Rails-Applikationen auf einem Server laufen zu lassen ist mit Apache einen Proxy einrichten, und gegen hinten dann je nach Domain oder Unterordner, etc. zu den spezifischen Ports weiterleitet.
Interessant. Das wäre ine gute Alternative zum Verzicht auf den Indianer. Hast du zufällig ein paar Links zu dem Thema parat oder Lust darüber zu schreiben?
Noch was, muss dem Sebastian recht geben, beschäftige dich noch mehr mit Rails denn sonst kommt für die Leser nichts gutes dabei heraus. Ich kenne das, ich kam damals auch von der PHP-Welt auf Rails (gut auf der Arbeit habe ich hauptsächlich mit Java programmiert), und um Rails zu verstehen braucht man sehr viel. Beschäftige dich noch ein paar Wochen und schreib dann wieder über Rails, dann ist die Qualität auch um einiges besser.
http://mongrel.rubyforge.org/docs/apache.html
Ist jetzt in Verbindung mit dem mongrel-Server, aber Apache-Konfiguration bleibt genau gleich, d.h. einfach Domain und Ports usw.
Vielen dank für den Link.
Kleine Randbemerkung an Sebastian: Martin hat nie behauptet, dass er ein Profi ist, sondern von seinen "ersten Schritten" geschrieben. Konstruktive Kritik ist von ihm also sicherlich erwünscht, aber bevor du solch ungehaltenen Kommentare äußerst, solltest du vielleicht einen Kaffe trinken, genügend schlafen, oder was dir sonst quer sitzt ändern.
Ich wüsste nicht, was an meinem Kommentar ungehalten und noch weniger was daran nicht konstruktiv sein sollte. Fehlinformationen helfen nun wirklich niemandem, und da man (nicht nur ich, auch Chris z.B.) an den beiden Beiträgen zu RoR sehen kann, dass der Autor noch viel zu wenig Ahnung davon hat, um es Anderen in dieser Form zu erklären, habe ich ihm einfach dazu geraten, selbiges lieber in naher Zukunft weiterzuführen, anstatt potentielle Neulinge mit Halbwissen zu verwirren. Ehrlichkeit ist nicht gleich Unhöflichkeit!
Gegen Ehrlichkeit sag ich nichts, auch nicht gegen konstruktive Kritik. Mein Kommentar hatte nichts mit deiner Kritik an dem Inhalt des Artikels zu tun, sondern mit deinem Tonfall.
Als großer Fan des Rails-Frameworks muss ich Sebastian beipflichten und mich auch etwas gegen Deine Bemerkung wehren, dass die angelegten Dateien und Verzeichnisse gerade einmal dazu ausreichen, den Ruby-Server (besser Rails-Server?) zu starten. Du hast faktisch mit dem Erzeugen der Anwendung eine komplett lauffähige Webapplikation. Zugegeben, sie kann noch nicht viel, aber in ihr steckt eine Menge drin. Dieses Potential zu nutzen und sie zu erweitern ist ja auch Aufgabe des Rails-Entwicklers. Was er dazu braucht, reicht ihm Rails auf einem goldenen Tablett. Übrigens: Rails, nicht Ruby, legt die Verzeichnisse und Dateien an.
Auch wenn es nur ein Ausblick auf den nächsten Teil ist, doch Scaffolding kann beim Arbeiten mit Modellen und DB-Tabellen nicht behilflich sein. Scaffolding erzeugt "nur" Code für Controller und Views. Sorry, wenn ich so penibel bin, aber bei einem Framework, das so sehr auf Patterns und Konventionen beruht wie Rails, ist es enorm wichtig, die Begriffe klar zu definieren und auseinanderzuhalten.
Noch ein Tipp: Wer die Konsole/Eingabeaufforderung nicht mag, der sollte RadRails (http://www.radrails.org) als Editor einsetzen. Bei dieser Eclipse-basierten IDE kann man Rails-Skeletons, Modelle, Controller, Scaffolds, ... über die GUI mit in paar Mausklicks generieren. Wer (unter Windows) InstantRails nutzt, kann sogar auf die Konfiguration von RadRails verzichten.
Bevor diese Diskusion noch so weitergeht:
Die Informationen, die ich hier hingeschreiben habe, basieren auf meinen Erfahrungen mit Ruby on Rails. Es spielt doch für Profis eh keine Rolle, wie ein Änfänger mir Ruby on Rails umgeht.
Mir ist es nur wichtig, anderen mein Interesse für Ruby on Rails mitzuteilen und/oder mit anderen zu teilen. Vielleicht habe ich einige falsche Dinge genannt, jedoch bin ich bereit, eure verbesserungsvorschläge aufzunehmen und zu berücksichtigen. Das war doch noch nie ein Problem. Gerade weil ich noch im lernprozess bin und mein Wissen noch "frisch", wollte ich es aufschreiben. Vielleicht als Notizen für mich selbst, wie viele andere Artikel hier in meinem Journal auch.
Ich zwinge doch niemanden, meine Informationen anzunehmen oder gar zu lesen. Wenn jemand bessere Quellen kennt, wird er doch zu handeln wissen... Da sind Sätze wie "lern mehr und schreib das später auf" teilweise unangemessen. In ein paar Wochen/Monaten habe ich nicht mehr den Blick von aussen/die Neugier eines Anfängers und könnte Kleinigkeiten, die für Änfanger wichtig sind, übersehen, weil ich sie für selbstverständlich verstehe.
1. So sehr mir diese Diskussion auch missfällt, möchte ich doch noch auf folgendes hinweisen: Dein Artikel beginnt mit "Nachdem ich euch einige Grundlagen des Ruby on Rails-Frameworks vermittelt habe" und endet mit "Im nächsten Artikel über Rails werde ich euch zeigen, ..." Ich darf doch wohl deshalb davon ausgehen, dass Du hier nicht nur Erfahrungen beschreibst und das nur für Dich machst, sondern Deinen Lesern was beibringen möchtest. Und da Dein Journal meines Wissens ein gut besuchtes ist, dürfen doch wohl einige Hinweise, die dieses oder jenes gerade rücken, erlaubt sein. Gerade dann, wenn es sich um "Kleinigkeiten, die für Anfänger wichtig sind" handelt.
2. Gilt Dein selbst gezimmerter Blogger-Kodex eigentlich auch für diesen Artikel?
Zu 2. Ja.
a. Ich habe Eure Korrektur-Vorschläge berücksichtigt.
b. Ich glaube selbst, was ich schreibe.
c. Ich habe darauf hingewiesen, dass die Informationen dieses artikels auf meinen Erfahrungen basieren.
d. Ich habe nun noch einen Hinweis hinzugefügt, der den Anspruch auf Korrektheit ausschliesst.
Es tut mir leid. Das nächste mal werde ich mich besser informieren und vermehrt auf die Korrektheit meiner Informationen achten.
FYI: es gibt auch in und für PHP einige MVC-Frameworks.
Ich hab mir RoR in den letzten Tagen auch mal angeschaut und für mich stellt sich vor allem eine wichtige Frage: Gibt es mit RoR vernünftige Lösungen für Mehrsprachigkeit? Bisher war alles was ich gesehen habe Englisch und viele Meldungen kommen direkt von Rails - wie zum Beispiel die aus dem Forms-Generator.
Sicherlich wurde Ruby on Rails primär für englische Applikationen entwickelt. Der Forms-Generator und andere Rails spezifische Ausgaben geben daher standardmäßig englische Meldungen zurück. Doch lässt sich ja alles umschreiben, sodass man die Ausgaben in gewünschter Sprache erhält. Auch eine multilinguale Lösungen müssten möglich sein. Schau dir mal folgende Seiten an, da gibts ein paar Infos dazu:
http://www.hyperionreactor.net/node/103
http://www.myowndb.com/blog/?p=4
http://www.hyperionreactor.net/node/106
Sebastian
21.02.2007
Vielleicht hast du das ja irgendwie anders gemeint, aber der erste Aufruf einer Rails-Anwendung wird normalerweise NICHT "zu diesem Zeitpunkt immer eine Fehlermeldung zurückgeben, da die Models noch fehlen". Es wird sogar noch nicht mal eine Datenbank benötigt, um die ganz normale Rails-Startseite mit Hinweisen zum weiteren Vorgehen und Umgebungs-Infos angezeigt zu bekommen.
Des weiteren frage ich mich, wo du jeweils die 99 Prozent Wahrscheinlichkeit in der DB-Konfiguration herholst.