Ich habe in letzter Zeit viel darüber nachgedacht, wie man Tntnet attraktiver machen kann. Angeregt von dem Buch „Open Source Projektmanagement. Softwareentwicklung von der Idee zur Marktreife“ (Von Michael Prokop, Open Source Press; Auflage: 1. Aufl. 27. September 2010, ISBN-10: 3937514600), habe ich mir deshalb Gedanken über die Zielgruppen gemacht.
Herausforderung
Ich sehe für Tntnet potenziell User, die sich grob in zwei Gruppen teilen lassen. Die erste Gruppe besteht aus Usern, die schon sehr viel Erfahrung mit C++ haben und seit vielen Jahren damit arbeiten. Diese User haben vielleicht bisher einen weiten Bogen um Webprogrammierung gemacht, weil sie alles was sie bisher in diesem Bereich gesehen haben für grausame Pfuscherei hielten.
Die zweite Gruppe, die ich sehe, hat sehr viel Erfahrung mit den klassischen Vertretern der Webprogrammierung, wie PHP, Python, Ruby on Rails, Java und den ganzen Frameworks, die damit in Zusammenhang stehen. Diese User haben bisher um C++ einen weiten Bogen gemacht, weil sie glauben, die Sprache sei unelegant und würde die Produktivität hemmen.
Für die erste Gruppe hat Tntnet schon viel getan, um den Einstiegt attraktiv zu gestalten. Für die Entwickler, die aus der C++ Ecke kommen, dürfte Tntnet viele bekannte Konzepte aufweisen. Tntnet bietet die Freiheiten, die ein C++-Programmierer gewohnt ist. Tntnet macht nicht viele Vorschriften, wie ein Projekt umzusetzen ist. Durch Tntnet wird Webprogrammierung für C++-Entwickler abstrahiert und vereinfacht.
Bei der zweiten Gruppe mit Usern, die aus der Welt der hochabstrakten Skriptsprachen mit ihren mächtigen Frameworks kommen, sehe ich noch erhebliche Barrieren. Selbst Java-Entwickler, denen Compiler nicht gänzlich fremd sind, werden sich anfänglich mit dem Buildsystem von C++ schwer tun. Ich fürchte, dass Viele über diese Hürde nicht hinweg kommen.
Lösungsansatz
Diese Überlegung hat mich dazu angeregt, darüber nachzudenken, wie man das Buildsystem vereinfachen kann, um die Barriere für Umsteiger zu senken.
Ich habe mir GNU Make, Autotools, CMake und QMake anschaut. Das sind mächtige Werkzeuge, aber viel zu kompliziert und mit zu viel „Magie“, die irgendwas im Hintergrund macht, das man nicht versteht. Ich habe mir auch kurz das Buildsystem von Code::Blocks angesehen. Code::Blocks ist eine IDE für C++. Es gibt eine sehr schöne Doku darüber, wie man Tntnet mit Code::Blocks verwenden kann. Es gibt nur ein Haken: Man kann keine Tntnet-Projekt mit Code::Blocks übersetzen ohne X, also auch nicht skriptgesteuert durch ein Continuous Integration Server wie Jenkins.
Nachdem ich diese Möglichkeiten alle verworfen habe, bin ich zu dem Entschluss gekommen, etwas eigenes zu probieren und mit einem proof of concept zu beginnen. Zuerst versuchte ich ein Wrapper oder eine „Premake“ zu schreiben, der aus seiner vereinfachten yaml-Konfiguration ein Automake-File baut. Nach ein paar Versuchen stellte ich fest, dass der Weg zu kompliziert ist, da versucht wird, die verwirrende „Magie“ von Automake & Co durch noch mehr „Magie“ zu verstecken. Also habe ich probier ein Build-Tool zu schreiben, das ohne andere Tools auskommt, um die Komplexität zu reduzieren.
Umsetzung
Herausgekommen ist ein Tool, dem ich den Namen Tntmake gegeben habe. Der Code ist auf GitHub zu finden.
Das Tool ist in Ruby geschrieben. Ich habe Ruby nur gewählt, weil ich mich beruflich derzeit damit beschäftigen muss. Als Proof of concept ist das auch okay. Aber die richtige Umsetzung werde ich eher in einer anderen Sprache realisieren, da schon einige Probleme aufgetreten sind. Zum einen ist da die Abhängigkeit zu einer weiteren Programmiersprache, die standardmäßig nicht immer vorhanden ist. Das habe ich zum Beispiel auf Pidora gemerkt. Dann nervt mich die mangelnde Kompatibilität unter den Ruby-Versionen, da ich von C++ anderes gewohnt bin.
Überrascht war ich beim Thema Geschwindigkeit. Im Vergleich zu C++ kriecht Ruby, wie zu erwarten, nur so dahin. Verglichen mit Autotools hingegen, ist mein Proof of concept ohne Optimierungen doppelt so schnell wie Automake. Damit habe ich nicht gerechnet. Um mein eigenes Projekt Peruschim zu übersetzen, brauchte Autotools ca. 2 Min. 11 Sek, Tntmake hingegen nur 53 Sek.
Geschwindigkeit ist aber nicht das vorrangige Ziel von Tntmake. Es soll auch nicht das Bessere Automake sein oder CMake, QMake und Co ersetzen. Ziel ist allein Tntnet-Projekte möglichst einfach zu übersetzen. Ich denke, Umsteiger, die vom Skriptsprachenuniversum kommen, interessiert das Buildsystem erst mal nicht, solange es ihnen nicht im Weg steht. Für große Projekte mit besonderen Anforderungen wird der Ansatz von Tntmake nicht reichen. Diese Projekte realisieren aber in aller Regel Fachleute, die nichts anderes tun haben, als sich um den Build-Prozess zu kümmern und für die dann Tools wie CMake, Autotools und Co kein Hindernis darstellen.
Wie geht es weiter?
Während der Arbeit an Tntmake habe ich das Konfigurationsformat von yaml auf json umgestellt. tntnet unterstützt yaml (noch) nicht. Ich werde im nächsten Schritt probieren, ob es machbar ist, mit Tntnet einen webbasierten Projekt-Wizard zu schreiben, der Tntmake als Backent verwendet. Deshalb war es mir wichtig, das die Konfiguration (gut) Maschinenlesbar ist.
Ursprünglich wollte ich Tntmake multithreading-fähig machen. Ich habe das bereits im Code umgesetzt. Mit dem Flag „tntmake -tb“ kann man das auch ausprobieren. Ich dachte, dass ich das bräuchte, weil Ruby so langsam ist. Aus irgendwelchen Gründen funktioniert Multithreading aber leider nicht. Da ich festgestellt habe, dass Tntmake derzeit schnell genug ist, verwende ich darauf zunächst keine weitere Zeit.
Ich werde in der nächsten Zeit den Code, in Vorbereitung auf eine Reimplementierung in eine andere Programmiersprache, noch etwas aufräumen.
C++ IN THE WEB 