Die Idee und der Name
Hier fängt schon der ganze Käse an. Eine wilde Idee ist geboren! Einer von uns biegt um die Ecke und versucht den anderen davon zu überzeugen und irgendwann gibt es ne erste Version. So wurde bisher jedes Plugin entwickelt. Eine konkrete Planung alá UML Diagramme
existierte nie. Auch existierte nie ein Vertrag mit Anforderungen oder Features. Es gab ab und zu einfache Teamviewer Konferenzen mit Skizzen. Wir sind nur wenige Entwickler mit viel Erfahrung und probieren gerne Neues aus. Starre Strukturen behinderten uns eher, weswegen wir hier hippe mäßig entwickelten.
Ist die Idee grob festgehalten, gibt es die erste Hürde. Der Name. Ja, der Name. Ein Name ist nicht nur einfach ein Wort, es steht für die Idee und den Gedanken dahinter. Jeder Firmen- und Markenname hat eine tiefere Bedeutung und steht für etwas. Es hört sich banal an, aber viel Geld und Zeit geht in Logos- und Markenentwicklung. Unsere Pluginnamen haben auch mal ein paar Tage gebraucht, bis wir den richtigen hatten. Wir haben uns immer an Filmnamen von Tom Hanks, Sir Sean Connery und Bruce Willis gehalten. Warum? Weil sich das irgendwie so ergeben hat. Die guten Namen sind aber alle aufgebraucht, weswegen wir in neueren Miniplugins davon abgerückt sind - Petrus oder Blackgate als Beispiel.
Also steht nun der Name und die Idee fest, was jetzt?
Teamarbeit und Dokumentation
Plugins erreichen gerne mal mehrere tausend Zeilen Quellcode. Deswegen ist es ungemein wichtig, zu dokumentieren. Dazu zählt aber nicht nur die Beschreibung des Codeabschnittes durch Kommentare, sondern auch eine Erstellung der Entwicklungshistorie. So sieht man, wann was entwickelt wurde und kann so schneller Fehler herausfinden. Auch ist eine Teamarbeit ungemein wichtig. Jeder muss auf einer aktuellen Version des Plugins arbeiten können und so muss ständig der aktuelle Entwicklungsstand synchronisiert werden.
Für kollaboratives Arbeiten am Quellcode gibt es so genannt Versionsverwaltungssoftware. Diese kümmern sich darum, dass alle Änderung am Quellcode erfasst werden und unter allen Mitarbeiten synchronisiert werden. Man stelle es sich wie einen zentralen Sachbearbeiter vor, der Änderungen von Mitarbeitern annimmt und in die Akten einpflegt. Ist eine Änderung OK, werden andere Mitarbeiter informiert, diese Änderung zu übernehmen, sonst können diese keine Änderung vornehmen - sie wären asychron. Ihre Einreichungen würden abgelehnt werden.
Wir benutzen die Software GIT, es existieren als Varianten noch SVN, Mercurial und CVS und weitere. Mit GIT erstellen wir sogenannte Repositories für die Plugins und GIT kümmert sich darum, alle Änderungen zu erfassen und zu synchronisieren. Unsere Repositories werden auf Github.com gehostet. Wer also Lust hat, einen Blick in den Quellcode zu werfen, kann dies bequem online tun. Jedes Plugin hat sein eigenes Repository und man kann dort in der Historie - den Commits - alle Änderungen nachverfolgen.
Don't repeat yourself
Programmierer sind extrem faul. Bestes Beispiel sind ja wir selber! Es gilt deswegen beim Programmieren darum, Redundanzen, also überflüßige Doppelungen, zu vermeiden. Warum Quellcode nachprogrammieren, wenn er schon überall verwendet wird? Bei uns ist der Aufbau eines Plugins standardisiert und viele Plugins brauchen gleiche Funktionalitäten. So verwenden viele Plugins Konfigurationsdateien, kommunizieren mit der Datenbank oder senden Nachrichten an die Spieler. Statt nun jedes mal STRG+C und STRG+V zu machen, verwenden wir eine Library mit den nötigsten Funktionen.
Das Problem bei Libraries ist jedoch, dass man diese immer irgendwie einbinden muss. Also runterladen und irgendwie in das neue Plugin integrieren. Und dann auch noch ja die richtige Version nutzen! Da dieser Prozess lästig ist und, da es der Mensch tun muss, auch fehleranfällig ist, haben wir irgendwann eine Lösung gefundet und sie nennt sich Maven. Maven ist ein Quasi-Industriestandard für Softwareentwicklung unter Java und standardisiert Projekte und ihren Entwicklungsprozess. Als hübscher Nebeneffekt kümmert es sich um die selbstständige Aktualisierung und das Herunterladen von Libraries. Auch wird über einen einzigen Befehl aus eine Ansammlung von Quellcode ein fertiges Programm geschnürt, was sonst über mehrere Zwischenbefehle möglich war.
Damit dies geht, braucht man wieder einen neuen Server, ein Repositories für die Bibliotheken. Hier verwenden wir Sonatypes Nexus. Es dient als Information für Maven, wo man diese ganzen Libraries herbekommt. Es kann noch viel mehr, aber mehr macht es in unserem Fall nicht. Es ist wie eine Dropbox für Programme. Hier der Link zu unserem Nexus.
Wir sind ganz froh, wenn es läuft, denn so wirklich administrieren können wir es nicht und wenn mal Fehler auftauchen, sind wir ganz froh, wenn diese wieder verschwinden.
Mit der Hilfe eines weiteren Programmes, Jenkins, kann man so eine schöne Build-Pipeline aufbauen:
Wenn wir eine Änderung am Quellcode auf Github hochladen - pushen - informiert GitHub Jenkins "Hey, eine Aktualisierung ist draußen!". Jenkins, der nur den Quellcode hat, ruft nun Maven auf und erstellt so einen neuen Build, das Artifact. Dieses Artifact ist am Ende das fertige, einsatzfähige Plugin.
Warum den ganzen Krempel? Weil diese Pipeline alle Brot-und-Butter-Aufgaben uns abnimmt und automatisiert. Statt sich mit solchen Aufgaben unnötig aufzuhalten, konzentrieren wir uns auf die reine Entwicklung des Plugins. Alles drum herum ist automatisiert. Klar, es hat lange gebraucht, so ein System aufzubauen, aber läuft es einmal, ist es wunderbar entspannend für den Programmierer.
Laber nicht, komm zum Punkt!
Richtig! Bisher haben wir eher Technologien aus dem Software Engineering gezeigt, aber kein Wort zum Programmieren selber. Der Grund ist, dass man Programmieren nicht einfach in einem Artikel erklären kann. Oder sollte. Wir könnten euch einfach Java Quellcode vorzeigen und sagen "So sieht es aus!". Alle würden "Ooooohhhh","Aaaahhh!" oder ähnliches rufen und das wars dann. Deswegen zum Programmieren das gröbste:
Wir verwenden als Software zum Schreiben des Quellcodes die IDE Eclipse. Man könnte es auch mit dem Standardtexteditor schreiben, aber Eclipse ist wie ein gutes Schweizer Taschenmesser. Komplex, aber schöne viele Hilfswerkzeuge. Autovervollständigung, Autocompiling, Syntaxhighlighting etc. bietet uns Eclipse. Damit man aber dennoch mal was gesehen hat, hier mal ein "Oooooh, Toll!"-Screenshot von Contaos ekliger Stelle:
Als Programmiersprache verwenden wir Java, da dies einerseits durch das API von Minecraft so vorgegeben ist und andererseits unsere Hauptprogrammiersprache ist. Und mehr gibt es eigentlich kaum zu sagen. Ihr könntet hören, es ist Objektorientiert, typsicher, hat eine VM und sonstigen Quark. Dies ist aber eher interessant, wenn man selber Programmierer ist. Und dann kennt man Java eh irgendwie oder hat wenigstens genug davon gehört, um zu wissen, worum es geht.
Abschließend ist zu sagen, dass dieses komplexe System keinesfalls vorhanden sein muss. Oder gar sollte! Wer programmieren lernen möchte, fängt klein an. Am besten auf Lernseiten wie Codeacademy. Möchte man kleine Plugins programmieren, reicht schon der normale Texteditor aus und ein wenig Erfahrung mit Java. Möchte man größere Projekte machen, reicht auch schon nur Eclipse aus. Will man jedoch zu zweit mehrere Plugins verwalten und entwickeln, so kommt man irgendwann an den Punkt, wo dieses System Sinn macht. Bis dahin ist es aber ein weiter Weg.
Ein nicht so weiter Weg ist der nächste Artikel in einer Woche, wo es um die Plugins FalseBook und Fifthelement geht. In dem Sinne wünschen wir eine atomwaffenfreie Nacht und bis zum nächsten Mal bei UglyTech!