Ein Gespräch mit David Heinemeier Hansson über die Verdienste von Open Source, warum Ruby on Rails eigentlich schon 2.0 genannt werden solle und wie Logik aus Datenbanken ferngehalten werden sollte.
David Heinemeier Hansson ist der dänische Autor von Ruby on Rails, einem Ruby-basierten Open-Source-Entwicklungsframework, das seit seiner Herausgabe 2004 schnell populär geworden ist. Rails geht von einem anderen Ansatz der Softwareentwicklung aus, den Hansson "eigenwillige Software" nennt. Ein Teil der Flexibilität wird dabei zu Gunsten der Einfachheit geopfert.
Das Ergebnis soll größere Produktivität und bessere Entwicklererfahrungen erbringen und nach der schnellen Annahme von Rails auf dem Markt, scheint dies auch bei vielen der Fall zu sein. Selbst größere Unternehmen bringen Rails ins Spiel, zum Beispiel die BBC, die damit ihre Datenbank aus Jahrzehnten von Fernseh- und Radioprogrammen für das Web aktiviert hat. Das Framework war auch gewisser Kritik ausgesetzt, aufgrund von Einschränkungen wie unzureichender Unterstützung einiger üblicher Datenbankfunktionen. Rails 1.0 wurde Mitte Dezember 2005 herausgegeben.
David ist kürzlich von Kopenhagen nach Chicago umgezogen, wo er Partner bei 37signals ist, Entwickler des Basecamp-Projektmanagementsystems und anderer Web-Anwendungen. Er sprach mit ZDNet über Ästhetik, Open Source und die Freude am Programmieren.
ZDNet: Woher rührte Ihr erstes Interesse an Ruby? Wie war es, diese Sprache zu lernen?
Heinemeier Hansson: Ich war ausgebrannt vom Programmieren in PHP und Java. Wie sehr ich es auch versuchte, ich schien niemals so produktiv zu sein, wie es der aktuellen Aufgabe angemessen wäre. Durch die banale Plackerei der Compilerarbeit verzettelte ich mich ständig. Ich habe Code geschrieben, der nicht dazu diente, das Programm für mich oder meine Mitarbeiter besser verständlich zu machen, sondern nur den Compiler zufrieden zu stellen.
Also war ich bereit für ein bisschen frische Luft. Und Ruby fiel mir genau zum richtigen Zeitpunkt auf. Ich brauchte nur wenige Tage, um festzustellen, dass es mir wirklich gefiel, und nur etwa eine Woche, um ausreichend Machbarkeitsnachweise zu erstellen, die mich überzeugten, dass hiermit der nächste Auftrag für die nächste Anwendung, an der ich gearbeitet habe (Basecamp), möglich wäre. Nach etwa einem Monat hatte ich so viel Produktivität und Glücksgefühl beim Programmieren gewonnen, dass ich mir geschworen habe, nie wieder zu PHP oder Java zurückzukehren.
Und das war schon in den Tagen, als Rails noch nicht Rails war. Heute ist die Anpassungsphase oft viel kürzer. Ich habe von Leute gehört, die sich nach nur wenigen Tagen mit Rails von ihren vorherigen Umgebungen auf immer verabschiedet haben. ZDNet: Sie sagten, ein großer Anteil beim Wechsel zu Ruby bestand einfach darin, dass es Sie glücklich machte. Dieser Faktor wird bei der Diskussion über die Vorteile einer Sprache gegenüber der anderen nicht so häufig genannt - warum ist das wohl so?
Heinemeier Hansson: Die Sprache ist sehr wichtig. Rails ist Rails wegen Ruby. Ruby ist es, das den Arbeitsablauf ermöglicht, die Knappheit, die Schönheit und letztendlich die Freude am Programmieren mit Rails. Während Frameworks in anderen Programmiersprachen bestimmt von dem lernen kann, was wir in Rails getan haben, kann doch die gesamte Erfahrung niemals nachempfunden werden. Sie ist zutiefst mit Ruby verknüpft.
Das soll nicht heißen, dass man kein anderes Framework erstellen kann, dass auch cool oder "besser" sein kann, je nach der Messlatte, die man dabei anlegen will. Es ist aber trotzdem kein Rails.
Wie auch immer, Ruby macht mich glücklich, weil ich damit wunderschönen Code schreiben kann. Ästhetik und Freude hängen eng zusammen. Es geht nicht nur darum, die Arbeit zu erledigen. Es geht auch darum, mit der Art, in der die Arbeit erledigt wird, zufrieden zu sein. Man muss auch motiviert sein, diese Art zu verbessern, und auf die Ausführung stolz sein können. Mit hässlichem Code kann ich das einfach nicht. Mit Ruby kann ich der Hässlichkeit entfliehen. Und darum kann ich mit Ruby beim Programmieren glücklich sein. Glücklichkeit führt zu Motivation. Motivation führt zu Produktivität.
ZDNet: Warum glauben Sie, ist Ruby nicht bekannter? Man sagte, Rubys "Perl-igkeit" sei ein bisschen altmodisch, stimmen Sie da zu?
Heinemeier Hansson: Perl hat viele Leute ausgebrannt. Entweder direkt oder über Geschichten, die darüber kursieren. Also ist es nur natürlich, dass die Leute vorsichtig reagieren, wenn sie eine neue Programmiersprache sehen, die nicht verheimlicht, dass sie ein paar Tricks von Perl gelernt hat. Sie nehmen an, dass, da diese eine Funktion vorhanden ist, wie etwa regelmäßige Ausdrücke als Syntaxelemente der ersten Klasse, auch alle die Schwierigkeiten übertragen werden, die sie in der vollständigen Perl-Erfahrung erlebt haben. Aber das ist natürlich dumm. Ruby hat eine Handvoll Ideen von Perl übernommen und sie in einem Kontext versetzt, in dem ihr Schadenspotenzial deutlich verringert wurde. Auch wenn die Funktionen selbst ähnlich erscheinen, unterscheidet sich der Kontext, in dem sie eingesetzt werden, deutlich genug, sodass die früheren Tendenzen einfach nicht erscheinen. Aber das ist natürlich schwer zu verkaufen. Gebranntes Kind scheut das Feuer. Um klarzustellen: Ich habe zwar Verständnis für diese Bedenken, aber ich betrachte sie auch als falsch. Ruby hat massenweise gute Ideen von Perl übernommen. Darauf sollten wir stolz sein. Man nimmt die guten Sachen, sortiert sie neu und übernimmt die Oberhand.
ZDNet: Können Sie uns einige spezielle Dinge nennen, die Sie an Ruby mögen, verglichen mit Sprachen wie PHP oder Python?
Heinemeier Hansson: Den Reiz von Ruby kann man nur schwer in wenigen Punkten beschreiben. Warum ist der Ipod so viel angenehmer zu benutzen als die entsprechenden Geräte von Creative? Man kann nur schwer auf ein paar Funktionen zeigen und sagen, hier, darum. Es geht um Ästhetik, Gefühl und Freude.
Aber wenn es sein muss, gibt es schon einige Funktionen von Ruby, die diese Ästhetik bewirken. Am wichtigsten sind die Blocks; anonyme Methoden, die durch ihren Einsatz erklärt werden. Dinge wie die Arbeit mit Sammlungen, der Umgang mit Transaktionen und das Herausstellen von Ressourcen wie Open Files, werden viel sauberer. Wir können domänenspezifische Sprachen erstellen, die eingebettet und dadurch klar und prägnant sind. Blocks sind vermutlich meine Lieblingsfunktion bei Ruby, und die gibt es bei PHP, Python und Java nicht.
Außerdem macht die Einfachheit, mit der man Code schon während der Definition einer Klasse ausführen kann, den Code einfach schöner. Oberhalb dieser Funktion haben wir domänenspezifische Sprachen für verschiedene Aspekte in Rails definiert, wie Assoziationen (has_many, belongs_to), Validierungen (validates_presence_of, validates_length_of), Filter (before_filter, after_filter) und noch mehr.
Insgesamt geben also die Inspirationen aus Perl, die oben genannten Funktionen und der vollständig objektorientierte Ansatz - selbst Zahlen und Zeichenketten sind Objekte in Ruby, im Gegensatz zum Beispiel zu Java - Ruby einen unglaublich reines und angenehmes Gesicht. Man kann umfangreiche Domänenmodelle ohne all das Bausteingefummel und die anstrengende Fleißarbeit aufbauen, die Java und andere statische Sprachen dieser Art zu so einer Plage machen.
Ruby greift das Produktivitätsproblem an, indem die Kernelemente so ausdrucksstark wie möglich werden, sodass der Programmierer nicht auf IDEs und andere Tools zurückgreifen muss, zusätzlich zur Sprache, um seine Arbeit zu erledigen. Nur wenige Programmierer würden heute auch nur in Betracht ziehen, Java ohne Eclipse/IDEA oder C# ohne Visual Studio zu verwenden, aber viele Programmierer sind fröhlich dabei, Ruby-Code in guten Texteditoren zu schreiben, die ohne Spezialisierung für eine bestimmte Sprache erschaffen wurden, wie Textmate in OS X, einer der großen Hits in Ruby/Rails-Kreisen. ZDNet: Könnten Sie etwas detaillierter beschreiben, wie Sie bei der Entwicklung von Rails vorgegangen sind?
Heinemeier Hansson: Der hilfreichste Ansatz bei der Entwicklung von Ruby war die Idee, dass Frameworks Auskopplungen sind. Sie sind die allgemeinen, nützlichen Teile, die Sie in vorhandenen Anwendungen finden. Sie sind keine Vorhersagen und kein Kaffeesatzlesen darüber, was ein Programmierer bei einer zukünftigen Anwendung vielleicht haben möchte.
Ich habe mich also nicht hingesetzt, um Rails zu erstellen. Ich wollte Basecamp erstellen, eine echte Anwendung, die wir bei 37signals entwickelt haben. Diese Anwendung hat das Design des Frameworks angetrieben, indem ich eine neue Funktion in Basecamp implementiert habe, dann habe ich den Code angesehen, abstrahiert, extrahiert und weitergemacht.
Bis heute ist dies immer noch unsere wichtigste Quelle für neue Funktionen in Rails: Kram, den wir erst in echten Anwendungen einbauen, dann extrahieren. Rails ist eine Sammlung von Lösungen für echte Probleme, denen die Mitwirkenden ausgesetzt waren.
ZDNet: Sie sagten vorhin, dass Sie kleinere Teams bei der Entwicklung vorziehen. In welchem Maß wird Rails immer noch auf diese Weise entwickelt, in Anbetracht seiner Popularität? Wie konnten Sie mit wachsender Projektgröße die Entwicklung in einer kleinen Gruppe konzentriert halten?
Heinemeier Hansson: So lange wie möglich kontrollierte ich die Entwicklung von Rails, indem ich der einzige war, der Patches in den Codespeicher anwenden konnte. Alles lief über mich. Damit war eine Vision gesichert und eine Kultur festgelegt. Heutzutage sind wir eine etwa 12köpfige Gruppe mit festgelegten Rechten, und davon führt etwa die Hälfte die Rechte regelmäßig aus. Damit wird der größte Teil von Rails weiterhin von einem sehr kleinen Team entwickelt oder zumindest überprüft.
Aber wir erlebten einen riesigen Ansturm von Beiträgen engagierter Programmierer, die Rails aus allen Blickwinkeln erweitert haben. Neue Patches und Tickets über Grenzfallprobleme prasseln in einem enormen Tempo auf uns ein, so schnell, dass wir gar nicht mithalten können. Aber das ist in Ordnung. Ich übersehe lieber aus Versehen einen guten Patch, als dass ich drei schlechte aufnehme.
ZDNet: Wie passt Ihrer Meinung nach Ihr Ansatz zum Konzept des konzeptuellen Framework der Agile Softwareentwicklung?
Heinemeier Hansson: Sowohl 37signals als Firma als auch Ruby on Rails als Framework sind eng an die Entwicklungsphilosophie von Agile angelehnt. Viele Prioritäten von Agile sind bei Rails gleich mit drin. Wir haben unglaublich starke Testeinrichtungen, eine engmaschige Änderungs- und Auswirkungs-Feedbackschleife, um kleine Iterationen zu fördern, und allgemein eine Abneigung gegenüber großen Vorschusslorbeeren.
Dem Ansatz von Agile positiv gegenüber zu stehen ist also mehr oder weniger Bedingung, um auf den Zug von Rails aufspringen zu können. Es gibt definitiv einen Austausch zwischen Kultur und Code in Rails. Wer nicht mit dem Agile-Programm mithält, wird in Rails vermutlich nicht gut hineinpassen. ZDNet: Wie wichtig ist es Ihrer Meinung nach, dass Sie Ihr eigenes Framework entwickelt haben, auf das Sie aufbauen können?
Heinemeier Hansson: Höchst wichtig. Allzu oft folgt man dem Weg "schnelles Release, häufiges Release", ohne dabei die Einschränkungen und Fallen zu erkennen. Ich habe schon so viele Open Source-Pakete gesehen, die angekündigt und herausgegeben wurden, bevor sie eine starke Vision oder eine eigene Kultur entwickelt hatten. Und wenn man etwas herausgibt, ohne dass Vision und Kultur gefestigt sind, dann werden Menschen angezogen, die starke Vorstellungen darüber haben, wohin das Projekt gehen soll, andere Vorstellungen als man selbst, und das führt dann zu internen Kämpfen und Richtungsverlusten.
Ruby on Rails hat es geschafft, diese Form zu durchbrechen, da es eine klare Vision und eine gefestigte Kultur hatte, sodass wir neue Mitglieder aufnehmen konnten, die mit statt gegen den Strich bürsten wollten.
Mein Rat an heranwachsende Open-Source-Programmierer lautet also, genau zu überlegen, ob "schnelles Release, häufiges Release" der richtige Schritt ist. Schreitet erst zum Release, wenn ihr etwas habt, was wirklich nützlich ist, und nehmt keine anderen Beiträge auf, wenn ihr noch nicht auf einem einigermaßen festen Kurs seid. Seid der Kapitän.
ZDNet: Wie kam es , dass Sie sich für eine Open-Source-Lizenz entschieden haben? Warum die MIT-Lizenz und nicht zum Beispiel GPL?
Heinemeier Hansson: Rails stammt aus dem pragmatischen Bedarf eines Business mit dem Wunsch, einiges zu teilen und einiges zu behalten. MIT schien in diesem Zusammenhang besser zu passen als GPL. Es war mir nicht so wichtig, mit Gewalt von anderen Menschen Beiträge zurück zu Rails zu erhalten. Wenn Sie Ihre Erweiterungen nicht im Kernframework freigeben, dann haben Sie es vermutlich sowieso nicht verstanden, also bezweifle ich, dass Ihr Patch für mich interessant sein könnte.
ZDNet: Sie haben gesagt, einer der Vorteile, ein Programm als Open Source anzubieten, liege darin, die positive Stimmung und die gute Presse um diesen Ansatz herum zu nutzen. Wenn Sie dies vor 15 Jahren getan hätten, als Open Source noch ein Novum war, hätten Sie dann die gleiche Entscheidung getroffen?
Heinemeier Hansson: Open Source war ein großer Erfolg für Rails, für mich persönlich und für 37signals. Ich habe so viele großartige Ideen erhalten, so viel schönen Code und habe so viele wunderbare Programmierer kennen gelernt. Ich bin heute ein sehr viel glücklicherer Programmierer als damals, als ich noch alleine gearbeitet habe. 37signals ist eine viel glücklichere Firma, da uns so viel Arbeit abgenommen wurde, die wir sonst selbst erledigen müssten.
Also betrachte ich den Goodwill als Bonus. Es ist wundervoll, dass Menschen uns bemerken, dass wir so viel Gedankengut anziehen können. Aber selbst wenn wir nur ein Hundertstel des derzeitigen Einflusses erhielten, würden wir noch als Sieger hervorgehen.
ZDNet: Wird Rails jemals Dinge wie gespeicherte Prozeduren und Trigger unterstützen? In welchem Maß wird dies begrenzen, wer das Framework verwenden kann und für welche ernsthaften Anwendungen es verwendet werden kann?
Heinemeier Hansson: Wie ich schon sagte, geht es bei Rails um Probleme, denen die Mitwirkenden ausgesetzt waren. Wir arbeiten nicht für andere Leute. Wir konnten also das Programm für unsere Bedürfnisse optimieren und kümmern uns nicht um den Rest. Rails macht nichts, um gespeicherte Prozeduren und Trigger zu unterstützen, da keiner unserer Mitwirkenden dies zu brauchen schien.
Und offen gesagt, wenn jemand meint, dass "Ernsthaftigkeit" eine Bezeichnung ist, die auch nur vage mit Datenbankfunktionen wie gespeicherten Prozeduren und Triggern zu tun hat, dann passt dieser Mensch wahrscheinlich sowieso nicht zu Rails. Macht also nichts, wenn Sie einen Bogen um Rails machen. Es ist nicht unser Ziel, Menschen zu helfen, die an unserer Hilfe nicht interessiert sind.
Wenn Sie jedoch ein Entwickler sind, der im allgemeinen gut mit der Kultur von Rails übereinstimmt, aber Funktion X wegen Ihrer Arbeit unterstützen müssen, dann freue ich mich, wenn Sie daran für Rails arbeiten. Vielleicht wird dies kein Teil des Kernframeworks, aber ein wertvolles Plugin, das anderen in ähnlichen Situationen helfen kann.
Die Welt wird weder heute noch morgen in Rails neu geschrieben. Wir brauchen also Brücken, und jeder ist willkommen, eine eigene Brücke zur Party mitzubringen. Viele haben es bereits getan. So haben wir die Unterstützung für Datenbanken wie Oracle und DB2 bekommen, unter anderem. ZDNet: Manche meinen, dass Sie verrückt sind, diese Sachen nicht zu unterstützen. Ganz allgemein, wie entscheiden Sie, was wichtig ist und was nicht, wenn es zum Backend kommt?
Heinemeier Hansson: Ich möchte jetzt kein Blatt vor den Mund nehmen: Die sind mir egal. Ich bin kein Verkäufer. Ich arbeite nicht an Rails, um anderen zu gefallen, ich arbeite, um mir zu gefallen. Das ist das Schöne an Open Source. Ich kann meine Technologieentscheidungen treffen, ohne Einschränkungen durch Althergebrachtes oder durch schlecht beratene Kunden. Wenn Sie Rails nicht "kaufen", fällt mir kein Zacken aus der Krone. Es gibt viele Menschen, die es kaufen, weil sie die gleichen Prioritäten haben. Wie es auch immer scheinen mag, ich bin nicht hier, die Welt zu retten. Und ich bin nicht hier, Sie zu retten.
Wenn Sie also die Unruhe, die Rails aufs Tapet bringt, besser ignorieren können, wenn Sie mich als "verrückt" bezeichnen, bitte sehr. Vielleicht ist das eine zutreffende Bezeichnung für mich, von Ihrer derzeitigen Lage aus gesehen. Und wenn Sie aus dieser Lage nicht entkommen können oder wollen, dann ist es wohl am besten, mich und Rails als verrückt abzuschreiben und am nächsten Tag mit einem Lächeln zur Arbeit zu gehen. Motivation und Glücklichsein sind sowieso die wahren Produktivitätsantriebe.
Und um auf die Einzelheiten einzugehen: Es ist kein Geheimnis, dass ich kein großer Fan von Logik in Datenbanken bin. Ich glaube nicht, dass die Datenbank ein geeigneter Ort ist, ein kohärentes Domänenmodell zu warten. Und ich meine nicht, dass man mehrere Anwendungen über die Datenbank integrieren sollte.
Wenn Sie dies befolgen und Ihre Datenbank vom Zugriff mehrerer Anwendungen abschirmen, können Sie die gesamte Logik, die Sie in gespeicherten Prozeduren, Trigger und was nicht noch alles abgelegt hätten, in ein objektorientiertes Modell investieren, das die letzten gut 20 Jahre Fortschritt in der Softwareentwicklung nutzen kann.
Nein, Sie können nicht einfach über Nacht von einer datenbankzentrierten Integration in eine servicebasierte umschalten. Wenn Sie also derzeit in einem Laden arbeiten, der über die Datenbank integriert, dann nennen Sie mich vermutlich "verrückt", weil ich diese Datenbanklogiktools nicht nutzen will. Und das ist in Ordnung, dann rede ich nicht mit Ihnen. Ich rede mit jemandem, der vor der Wahl steht, wie die Anwendung und ihre zukünftige Integration strukturiert werden soll. Und dem sage ich: Vermeide Logik in der Datenbank.
ZDNet: Gibt es Rails-basierte Produkte, die in Ihren Augen besonders herausragen?
Heinemeier Hansson: Haufenweise. Ich freue mich wirklich, alle diese coolen Dinge zu sehen, für die Rails seit der Freigabe genutzt wurde. Wir haben Leute, die Rails für alles nutzen, von sozialen Sites über Hypothekenanträge, den Verkauf von Babykleidung und Rechnungsversand bis zur Verwaltung humanitärer Einsätze. Ich glaube, Rails ist an so ziemlich jeder Webanwendung beteiligt, die man sich vorstellen kann.
Aber um nur eines hervorzuheben: Mir gefällt 43things.com sehr gut. Es ist von einer Gruppe ehemaliger Amazon-Mitarbeiter, deren Mission lautet, die Welt zu verbessern, indem sie Leuten helfen, ihr Ziel im Leben zu erreichen. Das ist solch ein nobles Vorhaben, und die Tatsache, dass über 200.000 Leute versuchen, ihre Ziele mit 43things.com zu erreichen, ist fantastisch.
ZDNet: Eine Besonderheit an Rails ist, dass es lieber versucht, etwas Bestimmtes sehr gut zu machen, statt für jeden einigermaßen geeignet zu sein. Was ist die Idee hinter diesem Ansatz? Warum sieht man diese Idee nicht öfter?
Heinemeier Hansson: Keiner möchte zugeben, dass er nichts Besonderes ist, dass sein Problem die gleiche banale Sache ist, mit der auch jeder andere kämpft. Menschen glauben lieber, dass sie einzigartig wie eine Schneeflocke sind, mehr als ihnen gut tut. Es ist also eine große Verlockung zu glauben, dass Sie für Ihren kleinen Buchladen die gleichen Werkzeuge brauchen wie Amazon für die Verwaltung von Millionen von Büchern, aber das stimmt nicht. Die Werkzeuge, die die größten Probleme dieser Welt wunderbar lösen können, sind meist total daneben bei der Lösung dessen, was die meisten Menschen meistens brauchen.
Und das ist der Punkt, auf den wir mit Rails abzielen: Was die meisten Menschen meistens brauchen. Um dahin zu kommen, mussten wir erkennen, dass wir gar nicht so besonders sind. Und dass man die wirklich besonderen Bedürfnisse sowieso nicht abstrahieren, extrahieren oder verallgemeinern kann, also sollte man die besser aufsparen, bis das Problem wirklich auftritt. ZDNet: Es gibt einige Softwareprojekte auf dem Weg, die einen "eigenwilligen", entwickelten Ansatz im Sinne von Rails zeigen. Sehen Sie diesen Ansatz als Teil einer größeren Entwicklung bei Software? Warum geschieht dies jetzt?
Heinemeier Hansson: Eigenwillige Software ist ein Begriff, denn ich geprägt habe, um den Aufstand gegen das Trugbild objektiver Software zu beschreiben. Dass Software von Anfang an so konfigurierbar wie möglich sein sollte, damit jeder Benutzer es genau seinen Bedürfnissen anpassen kann. Eigenwillige Software traut sich zu sagen, dass der Kunde nicht immer König ist. Dass nicht immer alles eine Frage der Einstellungen ist, dass Entscheidungen auch einmal zum Besseren getroffen werden können.
Ich würde mich freuen, wenn diese Vorstellung eine stärkere Basis gewinnen könnte. Seien Sie der Küchenchef, bereiten Sie mir eine Codemahlzeit zu, die ihrer Ansicht nach die bestmögliche ist. Ersparen Sie mir den Bausatz.
ZDNet: In welchem Maß ist Rails Ihrer Meinung nach für Unternehmen geeignet? Ist das wichtig?
Heinemeier Hansson: Rails ist viel nützlicher für Unternehmen als The Enterprise. Ich glaube, bei letzterem zählt zum größten Teil das Erscheinungsbild, "wegen X ist noch niemand entlassen worden", überaltete und teure Software, die keiner wirklich mag. The Enterprise wird Rails vermutlich niemals mögen, weil es dabei keine Spesenkonten gibt, keine Verabredungen zum Golf, keine Vertreter, die monatelang werben und nichts vom Prestige einer großen Firma.
Aber im Unternehmen werden die Leute, die Software brauchen, die echte oder sogar große Geschäfte macht, vermutlich Rails genau so lieben lernen wie die kleinen Mitspieler. Es ist einfach eine kluge Geschäftsentscheidung, weniger Geld auszugeben, um gute Software zu entwickeln.
ZDNet: Meinen Sie, dass Rails Ruby soweit antreiben kann, dass es so etabliert werden kann wie etwa PHP?
Heinemeier Hansson: Es gibt immer unterschiedliche Bedürfnisse. Rails wird niemals das Passende sein, um Ihrer Homepage nur ein bisschen dynamischen Inhalt hinzuzufügen. Aber ja, ich denke schon, dass Rails Ruby dabei helfen wird, bei den Projekten zu konkurrieren, in denen es auf die Qualität der Programmiersprache ankommt.
Viele Programmierer bleiben meiner Meinung nach viel zu lange bei PHP. Sie haben das Programmieren mit ein paar einfachen PHP-Skripts gelernt und verwenden es einfach weiter, trotz wachsendem Verlangen nach Weiterentwicklung. Viele erkennen wahrscheinlich gar nicht, dass Programmieren auch deutlich anders ablaufen kann, dass durch einen Szenewechsel ein Teil der Schmerzen aufhören könnte.
ZDNet: Wenn ein Entwickler festgestellt hat, dass er mit etwas wie Zope die Anwendungen genau so schnell vom Tisch bekommt wie mit Rails, gibt es dann noch einen Grund, warum er die komplizierten Sachen, die Zope machen kann, gegen die Einfachheit von Rails eintauschen soll?
Heinemeier Hansson: Im Gegensatz zu Zope glaubt Rails nicht an Komponenten höherer Ebene. Wir versuchen gar nicht, Businesslogik zu abstrahieren. Also gibt es keine standardisierten Autorisierungs- oder Zugriffskontrollsysteme. Es gibt keine Inhaltsdatenbank. Es gibt keine dieser Spezialisierungen, da ich nicht daran glaube, dass sie funktionieren. Sobald eine Komponente höherer Ebene groß genug wird, um Interesse zu wecken, werde ich mehr Arbeit damit haben, sie zu konfigurieren, als wenn ich das, was ich brauche, einfach neu erstelle.
Also versucht Rails, nur an den Sachen unterhalb der Trennlinie zwischen Infrastruktur und Businesslogik zu arbeiten, den Sachen, bei denen die meisten Menschen meistens die gleiche Lösung brauchen. Wo es möglich ist, eigenwillig zu sein, ohne die Art der machbaren Anwendungen einzuschränken. ZDNet: In welchem Maß ist Leistung immer noch ein Problem bei Rails? Sehen Sie das als fortlaufendes Problem oder nur als temporäres Problem vor Version 1.0?
Heinemeier Hansson: Für die große Mehrzahl der Anwendungen ist Rails mehr als schnell genug. Wir haben Anwendungen in Rails, die Millionen von täglichen dynamischen Anfragen auf recht normaler Hardware handhaben. Rails lässt sich einfach fantastische gut skalieren.
Und seit den frühen Tagen hatten wir die wertvolle Hilfe von Leistungsfachleuten wie Stefan Kaes, der Dinge immens verbessert hat. Heute ist es für viele Leute nicht mehr als Problem zu erkennen.
ZDNet: Wie war die Reaktion auf Release 1.0? Es war als eine Art Qualitätssiegel gedacht. Haben Sie festgestellt, dass Menschen wegen der Bezeichnung 1.0 Interesse zeigten?
Heinemeier Hansson: Mit Sicherheit. Rails 1.0 ist viel einfacher an Management und Kunden zu verkaufen als es bei Rails 0.14.3 der Fall war. Das ist zwar in technischer Hinsicht völlig sinnlos, aber Wahrnehmung ist Wahrheit. Wir haben also sicher Menschen gesehen, die beeindruckt waren, endlich die Version 1.0 auf dem Markt zu sehen. Um die Wahrheit zu sagen, wir hätten das längst erkennen sollen und Version 1.0 schon vor einem Jahr freigeben sollen. Dann könnte jetzt schon Rails 2.0 herauskommen und das hätte der Wahrnehmung noch mehr geholfen.
Können Sie uns etwas über kommende Funktionen erzählen, zum Beispiel Switchtower und The Conductor? Werden diese Teil von 1.1 sein?
Heinemeier Hansson: Die Entwicklung von Rails verlangsamt sich in gewisser Weise selbst. Wir sind in der Nähe des Limits dessen, was die meisten Menschen brauchen, unterhalb der Infrastrukturschneide mit Rails. Statt also alles bis zum "Geht-nicht-mehr" zu verschönern, haben wir unsere Aufmerksamkeit den Werkzeugen zugewandt, die einen Rails-Ansatz an das Gedankengut in anderen Bereichen als nur dem Framework unterstützen können.
Das erste Beispiel dafür ist Switchtower. Es wurde von meinem Kollegen, dem 37signals-Programmierer Jamis Buck erzeugt, um uns bei der Verwaltung des Einsatzes von Basecamp, Backpack und unseren anderen Anwendungen zu helfen, sobald wir von einer Einzelservereinrichtung auf einen 10-Server-Cluster gewechselt sind. Es umfasst den Vorgang, bei dem neue Versionen einer Anwendung live geschaltet werden, ohne auch nur eine Anforderung im Prozess zu verlieren und ohne Auszeiten bei den meisten Vorgängen.
Switchtower ermöglicht uns also, 10mal täglich eine neue Version von Basecamp hochzuladen, ohne dass die Benutzer dies merken, außer wenn ihnen die neuen Funktionen und die behobenen Bugs auffallen. Dies spielt eine unglaublich große Rolle dabei, nicht den Verstand zu verlieren, wenn die Anwendung aus ihrem ersten Kästchen herauswächst und man sich vergrößern muss.
Der Conductor ist das nächste Tool, an dem wir schon ein wenig gearbeitet haben. Es ist ein Tool, mit der man Anwendungen besser entwickeln kann. Viel mehr kann ich zu diesem Zeitpunkt noch nicht sagen. Wir werden dieses Programm schon bald umgesetzt haben.
ZDNet: Welchen Zeitrahmen sollten wir bei 1.1 denn so im Kopf haben?
Heinemeier Hansson: Rails 1.1 soll demnächst herauskommen, wann auch immer das dann letztendlich ist.