{"id":16,"date":"2014-05-06T16:07:19","date_gmt":"2014-05-06T14:07:19","guid":{"rendered":"http:\/\/blog.thecodecampus.de\/?p=16"},"modified":"2025-04-17T11:41:46","modified_gmt":"2025-04-17T09:41:46","slug":"ein-blick-in-die-karten","status":"publish","type":"post","link":"https:\/\/www.thecodecampus.de\/blog\/ein-blick-in-die-karten\/","title":{"rendered":"Ein Blick in die Karten"},"content":{"rendered":"

Seit dem Erscheinen der Version 1.0 im Juni 2012 entwickeln wir bei WeigleWilczek<\/a>\u00a0sowohl interne als auch Kunden-Projekte mit AngularJS<\/a>. In dieser Zeit haben wir viel \u00fcber AngularJS und die Art und Weise mit AngularJS Webanwendungen zu entwickeln gelernt. Mit diesem und den folgenden Posts m\u00f6chte ich einen Einblick in unseren Entwickler-Alltag, die von uns verwendeten Tools und unsere Erfahrungen mit AngularJS geben.<\/p>\n

Editor oder IDE<\/h2>\n

Grunds\u00e4tzlich l\u00e4sst sich f\u00fcr die Entwicklung einer AngularJS Anwendung jeder Editor verwenden. Syntax-Highlighting f\u00fcr die verwendeten Sprachen JavaScript, HTML und CSS sollten dabei aber das Minimum an Ausstattung sein.<\/p>\n

F\u00fcr viele Leute, die bisher haupts\u00e4chlich mit statisch typisierten Sprachen, die kompiliert werden, gearbeitet haben stellt die dynamische Typisierung und die Flexibilit\u00e4t, die JavaScript mit sich bringt, am Anfang eine gro\u00dfe H\u00fcrde da. Abhilfe kann hier JSLint bzw. der Fork JSHint schaffen. JSLint ist ein Programm zur statischen Code Analyse und kann viele Fehler, die ein Compiler einer statisch typisierten Sprache bemerken w\u00fcrde, ebenfalls bereits zur Entwicklungszeit erkennen.<\/p>\n

Je gr\u00f6\u00dfer ein Projekt wird, desto schwieriger wird es im Code den \u00dcberblick zu behalten und in ihm zu navigieren. Hier kann wie in der statisch typisierten Welt eine gute IDE helfen. Moderne IDEs k\u00f6nnen auch bei JavaScript viele gute Vorschl\u00e4ge beim Navigieren oder bei der Autovervollst\u00e4ndigung anbieten. Diese sind nur immer mit etwas Vorsicht zu genie\u00dfen, da die IDE eben nicht 100% sicher sein kann, ob sie das richtige verschl\u00e4gt. Ich verwende am liebsten WebStorm bzw. den gro\u00dfen Bruder IntelliJ. Achtung: IntelliJ in der kostenlosen Community Edition hat weniger Web-Funktionen als das kostenpflichtige WebStorm, da es eigentlich eine Java IDE ist. IntelliJ Ultimate ist beides: Web- und Java-IDE. Gerade was die bereits erw\u00e4hnte Punkte Navigation im Code und Autovervollst\u00e4ndigung angeht hat IntelliJ sehr viel zu bieten.
\nEiner weiterer der gro\u00dfen Vorteile von WebStorm\/IntelliJ ist das AngularJS Plugin. Durch dieses kann die IDE im HTML Code f\u00fcr die von AngularJS mitgelieferten Direktiven Autocompletion anbieten. Zus\u00e4tzlich kann man bei Expressions wie bei ng-click direkt zur Definition von Funktionen im Scope springen. Im JavaScript Code steht Autocompletion f\u00fcr alle AngularJS Funktionen zur Verf\u00fcgung.
\n\"IntelliJ<\/a><\/p>\n

Alles in allem lohnt es sich meiner Meinung nach auf eine IDE statt auf einen Text-Editor zu setzen und sich ggf. auch in eine neue IDE einzuarbeiten bzw. sie anzuschaffen.<\/p>\n

Tip: Vern\u00fcnftige JavaScript IDE verwenden!
\nAktuelle Empfehlung: WebStorm bzw. IntelliJ<\/div>\n

<\/p>\n

\n\"Angular\n<\/picture>\n<\/a><\/p>\n

Dependency Management<\/h2>\n

F\u00fcr die meisten Sprachen bzw. Eco-Systeme wie Python, Ruby, Java, … gibt es Tools, die Abh\u00e4ngigkeiten zu anderen Bibliotheken verwalten. Der Funktionsumfang ist dabei unterschiedlich. Maven in der Java-Welt sorgt z.B. nicht nur f\u00fcr das Herunterladen der angegeben Bibliothek in der angegebenen Version, sondern auch f\u00fcr das automatische Hinzuf\u00fcgen der Klassen der Bibliothek zum Classpath. Andere Tools sorgen nur daf\u00fcr, dass die Bibliothek runter geladen wird, binden diese aber nicht automatisch ein.<\/p>\n

Im Web-Bereich wurden Abh\u00e4ngigkeiten bisher fast immer von Hand gepflegt. Man l\u00e4dt eine Version von der Website des Projekts runter, legt sie in einem Verzeichnis eventuell unterhalb einer gewissen Ordner-Struktur \u00a0ab und bindet die Datei(en) in die index.html ein. Das hat vor allem den Nachteil, dass man sich auch um die sogenannten transitiven Abh\u00e4ngigkeiten, also die Abh\u00e4ngigkeiten der Abh\u00e4ngigkeiten selbst k\u00fcmmern muss und Konflikte bei kompatiblen Versionen so nur recht schwierig zu bemerken sind.<\/p>\n

Mit bower<\/a> hat das zum Gl\u00fcck ein Ende. Abh\u00e4ngigkeiten werden bei bower in einer Datei bower.json gespeichert und per Kommandozeile mit bower install<\/code> heruntergeladen. Dabei k\u00f6nnen wie im Beispiel unten zu sehen variable Versionsnummern verwendet werden. Bower erkennt Konflikte und fragt welche Version verwendet werden soll. Um das Einbinden der im Paket enthaltenen Dateien muss man sich selbst k\u00fcmmern. Ein Paket muss dabei nicht zwangsl\u00e4ufig JavaScript Code enthalten, sondern kann auch beispielsweise CSS oder Bilder mit sich bringen.<\/p>\n

{\r\n  \"name\": \"w11k-select\",\r\n  \"version\": \"0.3.4\",\r\n\r\n  \"dependencies\": {\r\n    \"angular\": \"1.2.x\",\r\n    \"w11k-dropdownToggle\": \"0.1.x\",\r\n    \"angular-bindonce\": \"0.3.x\"\r\n  },\r\n  \"devDependencies\": {\r\n    \"font-awesome\": \"4.0.x\",\r\n    \"bootstrap\": \"3.1.0\",\r\n    \"es5-shim\": \"2.3.0\"\r\n  }\r\n}\r\n<\/pre>\n
Bower l\u00e4dt die Pakete aus ihren jeweiligen Repositories runter. Es gibt also kein zentrales Repository f\u00fcr alle bekannten Pakete. Das hat den gro\u00dfen Vorteil, dass auch kein zentrales Repository ausfallen kann, wie k\u00fcrzlich bei NPM geschehen.\u00a0Leider ist bower aber etwas anf\u00e4llig f\u00fcr Verbindungsabbr\u00fcche. Das ist besonders \u00e4rgerlich, wenn man bower auf einem CI-Server einsetzt und der Build fehlschl\u00e4gt nur weil bower ein Verbindungsproblem hatte. Beim n\u00e4chsten Aufruf des Builds funktioniert dann meistens alles wieder reibungslos, sofern nicht wirklich ein Problem mit Abh\u00e4ngigkeiten vorliegt.<\/p>\n
Um das Problem zumindest tempor\u00e4r zu umgehen, kann man bower anweisen Pakete nur aus dem lokalen Cache zu installieren und diesen nicht \u00fcber das Internet zu validieren. Daf\u00fcr einfach den Parameter -o<\/i> mitgeben, also z.B. bower install -o<\/code>.<\/p>\n
Eine Stolperfalle hat bower noch zu bieten: bower install<\/i> installiert nur noch nicht vorhandene Pakete. Besteht eine Abh\u00e4ngigkeit zu einem Paket in der Version 1.2.x und es ist momentan Version 1.2.15 installiert, so wird bei bower install<\/i> nicht die neuere Version 1.2.16 heruntergeladen, da schon eine Version des Pakets installiert ist. Ruft man\u00a0bower update<\/code> werden auch f\u00fcr bereits installierte Pakete neue Versionen gesucht. In fr\u00fcheren Bower Versionen hat bower update<\/i> aber keine neuen Abh\u00e4ngigkeiten installiert. Das scheint jetzt behoben zu sein, so dass eigentlich bower update<\/i> ausreichen sollte.<\/p>\n
Auf Nummer sicher gehen: Im automatisierten Build immer bower install && bower update<\/code> aufrufen.<\/div>\n
F\u00fcr die direkten Abh\u00e4ngigkeiten eines Projekts hat es sich bei uns bew\u00e4hrt auf variable Versionsnummern zu verzichten und immer eine vollst\u00e4ndige SemVer-Version anzugeben. Wenn das Projekt (die Abh\u00e4ngigkeit) nicht mit SemVer<\/a> und Tags arbeitet kann man bei bower auch einen git-Commit-Hash angeben. Auch wenn SemVer eigentlich vorgibt, dass Patch-Versionen kompatibel zueinander sein sollen, kommt es immer mal wieder vor, dass die eigene Anwendung mit dem einen Patch-Level funktioniert und mit dem anderen nicht. Damit so etwas nicht erst beim erstellen des Releases auff\u00e4llt, sollte man feste Versionen eintragen und das Update explizit von hand durchf\u00fchren.<\/p>\n
Manchmal kann es auch hilfreich sein eine eigentlich transitive Abh\u00e4ngigkeit als direkte anzugeben um eine fixe Versionsnummer angeben zu k\u00f6nnen wenn in der eigentlichen Abh\u00e4ngigkeit eine variable Version angegeben ist.<\/p>\n
Bew\u00e4hrte Versionierung von Abh\u00e4ngigkeiten
\nFixe Versionen bei Entwicklung einer Anwendung
\nVariables Patch-Level bei Entwicklung einer Bibliothek<\/div>\n
Module<\/h2>\n
Jetzt wissen wir, wie wir Abh\u00e4ngigkeiten verwalten wollen. Aber welche haben wir denn in der Regel so? Bei unseren bisherigen Projekten haben sich einige Bibliotheken und AngularJS-Module als sehr n\u00fctzlich bis unersetzlich erwiesen. In unserer bower.json steht daher fast immer:<\/p>\n