Blog

Alle Beiträge von Enno Thieleke

Synchrone Arbeitsverzeichnisse mit SVN

In komplexen Projekten arbeiten in den meisten Fällen viele Entwickler an diversen Artefakten. Dazu kommt es schon, wenn Teams aus Mitgliedern mit unterschiedlichen fachlichen Schwerpunkten bestehen, die Unternehmensprozesse (weiter-)entwickeln, wo der Unterbau aus mehreren Domänen zusammengesetzt ist. Leider ist es gängige Praxis, dass irgendwo mehr schlecht als recht dokumentiert wird, welche Verzeichnisse man aus dem Unternehmens-SVN-Repository auszuchecken hat. Tja, und das hat dann auch jedes Team-Mitglied individuell zu machen. Oder?

weiterlesen

Von der neunten in die achte Maven-Hölle

Wenn man im Unternehmen Maven als Software Configuration Management-Software einsetzt, um Software-Artefakt-Abhängigkeiten zu modellieren und auflösen zu lassen, sollte man umsichtig handeln. Natürlich sollte man grundsätzlich umsichtig handeln, aber wenn dieses Unternehmen auch noch wächst oder zunehmend Altsysteme durch neue ablöst, kann ein Abhängigkeits-Graph entstehen, der zwar analysiert werden kann, aber leichte Wartung unmöglich macht. Dieses „Wuchern“ kann man aber in den Griff bekommen.

weiterlesen

Weniger ist meist mehr

Vor kurzem habe ich auf computerbase.de gelesen, dass Google Chrome 28 mit einer neuen Engine versehen wird. Dabei finde ich ein paar Zahlen in dem Artikel besonders interessant. Die neue Engine ist ein Fork von WebKit, in dem über 7.000 Dateien aus dem Quellcode entfernt wurden. Das führt zu einer „Lines of Code“-Ersparnis von 4,5 Mio. und dabei wurde die Hauptaufgabe der Engine, HTML zu parsen, signifikant beschleunigt. Gut, LoC ist heutzutage keine valide Metrik mehr, da Entwickler nicht länger danach bezahlt werden. Deswegen wurde der allgemeine Code Style kompakter, aber dennoch gilt: Angenommen, nur jede fünfte Zeile ist relevant. Fast eine Mio. LoC zu entfernen, dabei Kompatibilität zu wahren und keine der gestellten Anforderungen außer Acht zu lassen ist eine beachtliche Leistung.

Aber warum erst in der 28. Version? Die Antwort ist ganz klar der Fokus. Dieser liegt bei der Entwicklung von Google Chrome auf Geschwindigkeit, Einfachheit und einer geringen Time to Market. Das muss natürlich alles unter einen Hut gebracht werden und so ist die Entscheidung naheliegend, bestehende und quelloffene Technologien (wie WebKit) vorerst 1:1 zu übernehmen und damit frei gebliebene Resourcen an anderen Stellen einzusetzen. Später, wenn Resourcen frei werden (und die quelloffenen Technologien wirklich verstanden sind), können Anpassungen vorgenommen werden.

Das Resultat ist weniger Aufwand bei mehr Funktionalität.