Erfahrungsbericht: erste Schritte mit Git, Ruby on Rails und MongoDB (Teil 1)

Ich bin ein typischer LAMP-Entwickler. Meine Programmierwelt besteht seit vielen Jahren vor allem aus Linux, Apache, MySQL und PHP. Sowie SVN. Genau genommen bin ich also ein LAMPS-Entwickler ;). Natürlich gibt es zu jeder Komponente dieses Software-Stacks Alternativen. Vernünftige Entwickler werden nicht mit Scheuklappen durch die Welt laufen, sondern nach links und rechts blicken, was sich auf dem Markt tut und wie Aufgaben in anderen Sprachen / mit anderen Tools gelöst werden.

Neue Welten

In meinem Fall gab es vier Dinge, die ich schon länger ausprobieren wollte: das Versionierungssystem Git, die Programmiersprache Ruby sowie das darauf aufbauende Framework Ruby on Rails und das dokumentorientierte Datenbanksystem MongoDB. Natürlich könnte man in einem Testprojekt SVN gegen Git tauschen, in einem anderen auf MongoDB statt MySQL setzen und sich irgendwann an Ruby wagen, um später Ruby on Rails zu lernen.

Das finde ich langweilig. 🙂 Außerdem sinken die Chancen, dass ich alle Komponenten tatsächlich kennen lerne, wenn ich mir dafür vier fiktive Projekte aus den Fingern saugen muss und diese nacheinander aufbaue. Mein Ansatz daher: ich setze alles auf eine Karte und verwende in meiner Testanwendung auf einen Schlag Git, Ruby on Rails und MongoDB.

Die Beispielanwendung

Nachdem ich mich für den Stack entschieden hatte, war die Frage: was soll ich coden? Eine typische Hallo-Welt-Anwendung durfte es nicht werden, denn mit einer trivialen Applikation lernt man keine Sprache kennen. Zugleich war klar, dass der Komplexitätsgrad nicht zu hoch sein darf, damit die Aufgabe für einen Anfänger in dieser Sprache umsetzbar bleibt.

Was weiters klar war: ich schreibe keine Blog-Anwendung und kein CMS. Mir kommt das Würgen bei dem Gedanken, dass noch ein Blog/CMS auf die Welt losgelassen wird. Mit Shops bin ich jeden Tag beschäftigt, weswegen ich auch diese Option ausschließe und ein wenig Abwechslung suche.

Meine Entscheidung war ziemlich schnell klar: es wird ein Issue-Tracker. Gründe dafür gibt es einige:

• Das Thema Issue-Tracking ist als Hallo-Welt-App noch nicht so ausgelutscht wie Blog, CMS und co.
• Man kann schön mit einer einfachen Version anfangen und diese sukzessiv ausbauen.
• Ein Issue-Tracker bietet eine große Spielwiese für den Test verschiedener Komponenten:
  das Verwalten von Kunden, Projekten und Issues, ein User-Management, das Aufzeichnen von Änderungen, Benachrichtigen von Usern und Erstellen von Reports, Bereitstellen von Schnittstellen, Mehrsprachigkeit und und und.
• Es gibt keinen Issue-Tracker, der mich zu 100 Prozent überzeugt. Das weckt den Antrieb, es besser zu machen, selbst wenn es sich nur um eine Test-App handelt. 😉

Die Stoßrichtung war somit vorgegeben: ich schreibe einen Issue-Tracker. Als Orientierung dient das bei uns in der Agentur verwendete und für unsere Bedürfnisse angepasste Bug-Tracking-System Mantis.

Im nächsten Teil

Soviel also zur Vorgeschichte. Im nächsten Posting schreibe ich über meine ersten Gehversuche mit Git.