Sent from Hauptstadt!

ein Blog für den geneigten Leser

Javascript ist und bleibt ein Krampf

Tags: ,

Kategorie Software Engineering | Keine Kommentare »

Wenn ich mir eine Programmiersprache genauer anschaue, interessiert mich nicht, wie man in dieser eine Schleife schreibt oder Eigenschaften zwischen Objekten vererbt. Mich interessieren eher die architektonischen Aspekte, etwa:

  • wie kann ich Code in Module oder Pakete strukturieren?
  • wie leicht lässt sich eine Testautomatisierung erreichen?
  • wie kann ich Code effizient debuggen?
  • welche Bibliotheken gibt es, damit ich nicht alles neu erfinden muss?
  • wie sieht die Werkzeugkette für das Einbinden externer Bibliotheken aus?
  • wie sieht die Werkzeugkette aus, um vom Quellcode zur auslieferbaren Applikation zu gelangen?
  • wie ausgereift sind Werkzeuge für statische Code Analyse?
  • wie gut sind Entwicklungsumgebungen und gibt es beim „Refactoring“ Unterstützung?
  • wie hoch ist die Lernkurve und gibt es etablierte Standards?

Leider bleibt Javascript auch im Jahr 2015 aus architektonischer Sicht ein Krampf. Dummerweise ist es aber ein Krampf, um den man kaum umhin kommt, wenn man Webanwendungen entwickeln muss.

Meine heimliche Referenz für all die Punkte ist Java. Zugegeben, der Vergleich hinkt, da Javascript primär für die Entwicklung von Weboberflächen verwendet wird, während sich Java abgesehen von GWT, Vaadin und JSP auf dem Server tummelt. Nichtsdestotrotz will ich für meine Javascript Weboberfläche genauso wie für meine Java Geschäftslogik eine stabile Build Pipeline und gut strukturierten Code haben. Deshalb sei mir der Vergleich gestattet.

In Javascript wird der Quellcode vor Auslieferung nicht kompiliert, da der Browser ihn interpretiert. Deshalb werden zur Auslieferung meist nur die Quelltexte der verschiedenen Dateien aneinander gehängt und eventuell minifiziert. Soweit so gut. Für einen Unittest hingegen möchte man eigentlich nur die Quelltextdateien verwenden, zu denen Abhängigkeiten bestehen. Da es aber in der momentan in der Praxis verwendeten Javascript Version keine Import Anweisung gibt, ist man auf Krücken wie RequireJS oder Browserify angewiesen. Ein Krampf.

Für den Bauprozess gibt es momentan 2 konkurrierende Werkzeuge: Grunt und Gulp. Auch in der Java Welt gibt es unterschiedliche Werkzeuge, die aber aus unterschiedlichen Epochen stammen:

  • Ant – der Urvater, heute bei Neuprojekten tunlichst zu vermeiden
  • Maven – der jahrelange Platzhirsch, eine sichere Wahl, um die Lernkurve gering zu halten (viele Java Entwickler kennen sich damit aus)
  • Gradle – der Herausforderer, sollte man in Neuprojekten testen

Bei Javascript ist alles in Bewegung und nichts funktioniert richtig. Grunt ist simpel, aber wichtige Plugins sind häufig nicht aktuell und funktionieren nicht. Gulp ist die diesjährige Reinkarnation, Ausgang ungewiss. Und während man bei Java einfach Maven oder Gradle installiert bzw. entsprechende Wrapper gleich mit ausliefert, benötigt man in der Javascript Welt zunächst eine lokale Node.js Installation. Das vereinfacht die Sache nicht.

Abhängigkeiten zu anderen Bibliotheken ist der nächste große Krampf. In Java definiert man solche Abhängigkeiten in seiner Maven oder Gradle Baudatei und man kann sofort mit der Entwicklung beginnen. Bei Javascript steht man wieder vor einem Wust an halbfertigen Tools zur Verwaltung von Abhängigkeiten, etwa Bower, Atomify oder doch nur npm package.json?! Bower lädt definierte Bibliotheken brav herunter, aber man muss sich dann immer noch selbst um die Einbindung dieser Bibliotheken in das Projekt kümmern und mit Grunt/Gulp rumfrikkeln (siehe browserify-shim). Neben einer reinen Javascript Bibliothek gibt es aber auch Komponenten (etwa Bootstrap), die zum Beispiel eigene Bilder, Schriften oder Stylesheets (zusätzlicher Krampf: CSS vs. Less, vs. Sass) mitbringen. Bei der Entwicklung von Bower hat daran anscheinend niemand gedacht und man muss sich dann wieder was einfallen lassen, damit auch diese Dateien korrekt eingebunden werden.

Einen etablierten Standard für die Formatierung von Javascript Quelltext gibt es natürlich auch nicht. Neben der reinen Formatierung gibt es auch noch unterschiedlichste Ansätze, wie man Funktionen und Klassen definiert. Werkzeuge für statische Code Analyse sind ebenfalls nicht ausgereift.

Gut sieht es einzig beim Debugging aus. Hier haben die Browserhersteller in den letzten Jahren massiv investiert und in ihre Browser so genannte Entwicklerwerkzeuge eingebaut. Ohne diese Werkzeuge wären viele Javascript Entwicklungsprojekte sicher schon längst gescheitert. Auch bei den Entwicklungsumgebungen gibt es für jeden Geschmack etwas, vom programmierbaren Editor wie Sublime Text oder Atom bis hin zu den üblichen Verdächtigen wie IntelliJ Idea, Eclipse und Visual Studio. Die Refactoring Unterstützung ist in allen Werkzeugen schwach, was aber in der Natur einer dynamischen Programmiersprache liegt.

Zum Thema Unittest schreibe ich lieber nichts außer: Karma vs. Jasmine vs. QUnit vs. Mocha vs. … :-)

Fazit: Die Lernkurve für einen erfahrenen Entwickler beim Einstieg in die Javascript Welt ist ungewöhnlich hoch. Etablierte Standards fehlen, alles ist im Fluss, jeden Monat kommen neue halbfertige Werkzeuge um die Ecke. Mehr als ein paar zehntausend Zeilen Code möchten man diesen Werkzeugen nicht anvertrauen. Eine einheitliche Linie fehlt, vieles stammt aus der Node.js Ecke, passt aber nur bedingt auf die clientseitige Javascript Entwicklung. Resultat sind schlecht aufgesetzte Projekte mit vielen Speziallösungen, die sich kaum von Projekt zu Projekt wiederverwenden lassen.

Pukeko

Kategorie Rest | Keine Kommentare »

Neuseeland ist das Land der Vögel. Bevor der Mensch vor ca. 700 Jahren erstmals die Inseln betrat, gab es keine Säugetiere auf den Inseln. Deshalb konnte sich in Neuseeland eine einzigartige Vogelwelt entwickeln. Der nur nachtaktive und flugunfähige Kiwi ist heute das Nationaltier Neuseelands. Leider kamen mit dem Menschen auch viele Schädlinge wie Ratten, Possums, Hermeline und zerstörten einen Großteil der ursprünglichen Vogelwelt. Neuseeland kämpft aber mit sehr viel Aufwand um die verbliebenen Arten. Hier ein Pukeko:

ein Pukeko (Purpurhuhn)

Wharariki Beach

Tags: , ,

Kategorie Rest | Keine Kommentare »

Der Wharariki Beach an der nördlichen Spitze der Südinsel war für mich der schönste und spektakulärste Strand. Hier hat die Natur alle Register gezogen! Die ankommende Flut macht das Erkunden der Höhlen ein Abenteuer. In den Höhlen findet man Krebse und Robben. Der Sand ist weiß. Es gibt eine Sanddüne und skurrile Felsen im Wasser. Bei Sonnenuntergang spiegelt sich die ganze Szenerie im von Wellen durchnässten flachen Strand. Malerisch!

Wharariki Beach in Neuseeland

Sozialer Aufstieg durch IT Job

Tags: ,

Kategorie Software Engineering | Keine Kommentare »

Während meiner Überwinterung in Neuseeland habe ich einige Menschen getroffen, die ebenfalls in Neuseeland eine „Auszeit“ verbringen. Die meisten waren deutlich unter 30 – das typische Backpacker Volk. Ein Phänomen war, dass eine hohe Zahl von ihnen „irgendwas“ mit IT machte. Da war der IT Sicherheitsforscher aus Israel, die Java Entwicklerin aus den USA, etc. Auch ich bin ja in der IT Branche tätig. Mein Gefühl war, dass die Arbeit in der IT Branche einem viele Freiheiten ermöglicht, sowohl in finanzieller Sicht als auch in Sachen Flexibilität.

Zu diesem Gedanken passt die heutige Meldung, dass der ursprünglich aus armen Verhältnissen stammende Tamile Sundar Pichai neuer CEO von Google wird. Binnen 10 Jahren hat er sich von der untersten Ebene bis an die Spitze hochgearbeitet.

Allerdings sind wir IT’ler lediglich eine sehr kleine Gruppe von Auserwählten. Das Marktforschungsinstitut IDC schätzt, dass es Anfang 2014 nicht mehr als 11 Millionen professionelle Softwareentwickler gab. Bei einer Weltbevölkerung von gut 7 Milliarden Menschen ist das nichts.

Deshalb wundert es mich noch immer, warum nicht viel mehr junge Menschen sich für einen Beruf in der IT entscheiden?