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.

7 Antworten

  1. Daniel Puglisi sagt:

    Hallo Matthias

    Viel Spass mit Rails. Ich entwickle selber seit ungefähr einem Jahr mit Rails unter der Haube und bin keineswegs enttäuscht.

    Falls du Sass bereits angeschaut hast, kann ich dir noch Compass empfehlen. Compass bringt vorgefertigte CSS3 Mixins und weitere Funktionen mit sich, die die Entwicklungszeit um einiges verkürzen können ;D

    lg Daniel

  2. Hallo,

    @Daniel: cool – die Idee gefällt mir auch sehr gut. Mit APIs versehen können wir dann die Tracker-Suite starten. 😉

    @Jörg: Dankeschön – die ersten Schritte gefallen mir schon sehr gut, obwohl ich erst an der Oberfläche kratze.

    @Sarah: ich hätte ja gehofft, du gibst mir jetzt Tipps und ich kann etwas abstauben! 😀

  3. Sarah Mischinger sagt:

    Bin auch gerade daran Ruby/Ruby on Rails incl. Git zu lernen. An eine neue Datenbank trau ich mich aber nicht heran – versuche aber mit Sass zu arbeiten (naja bis ich mit meiner App beim wirklichen Stylen befinde dauerts noch…)

    Werde nun weiterhin verfolgen wie es dir so geht mit deiner App und hoff ich kann dadurch auch ein paar wertvolle Tips für meine Arbeit abstauben 😉

    lG Sarah

  4. Super Herangehensweise.
    Alle Bugtracker like Mantis, Eventum und und und haben Ihre Stärken aber auch Macken.
    Als „alter“ leidenschaftlicher LAMP“S“ Entwickler habe ich meine Erfahrungen mit MongoDB gemacht und wünsche dir genauso viel Freude daran!

  5. Daniel Lang sagt:

    Bin schon gespannt und freue mich auf die nächsten Posts!

    Ich mach das selbe übrigens grad mit RavenDB, nur dass es da ein „idea tracker“ ist, bei dem man Ideen posten und raten kann, ähnlich Uservoice.

  1. 01.09.2011

    […] 1. September 2011 von Matthias ZeisIn den ersten beiden Artikeln dieser Serie habe ich von meiner Hello-World-App und meinen ersten Erfahrungen mit Git erzählt. Heute schildere ich meine ersten Vergleiche […]