Haben Sie schon einmal versucht, den Fehler in Zeile 1 der Datei app.js zu finden, wenn diese Datei aus nur einer Zeile mit einer Zeilenlänge von etlichen tausend Zeichen besteht und weder über vernünftig gesetzte White Spaces noch über Kommentare verfügt? Wartungsfreundlich und gut lesbar ist ein so optimierter Quellcode sicherlich nicht. Zur Hilfe kommt Ihnen hier das Konzept der Source Maps. Weiterlesen
Aus Spaß wurde Ernst und Ernst ist jetzt drei Jahre alt. Das gilt auch für die serverseitige JavaScript-Plattform Node.js. Und nein, dieser Artikel beschäftigt sich nicht mit der Einführung in Node.js und Sie werden auch keinen Webserver in Node.js im Verlauf dieses Artikels programmieren. Nein, dieser Artikel enthält keine einzige Zeile Quellcode. Vielmehr möchte ich darauf eingehen, was Node.js ist und was nicht und auch klarstellen, dass diese Plattform nicht die „Silver Bullet“ der Webentwicklung ist, mit der sich sämtliche Ihrer Probleme lösen lassen.
Mit seinem neuen Betriebssystem, Windows 8, geht Microsoft einen entscheidenden Schritt in Richtung Cross Device System und Internet.
Das neue Betriebssystem bietet zwei verschiedene Modi, zum einen ist der klassische Desktop verfügbar, der mittlerweile seit Windows 95 bekannt ist und dazu dient Anwendungen auszuführen. Der Fokus liegt hierbei auf der Interaktion des Nutzers über Maus und Tastatur. Den zweiten Modus stellt die Metro Oberfläche dar. Diese erinnert stark an die Kacheldarstellung von Windows Phone 7.
Die Anwendungen, von Microsoft auch als Metro-style-Apps bezeichnet, können auf unterschiedliche Arten implementiert werden. Klassisch stehen natürlich C++ und C# als Programmiersprachen zur Verfügung, sie können allerdings auch mit HTML5, CSS3 und Javascript umgesetzt werden, also wie klassische Webapplikationen. Die Umsetzung dieser Apps erfolgt normalerweise in Visual Studio. Hier stehen dem Entwickler die entsprechenden SDKs zur Verfügung. Außerdem sind die neuen Features gut in die IDE integriert.
Das Ziel von Backbone.js ist es, Struktur in eine Javascript Anwendung zu bringen. Zu diesem Zweck stellt es verschiedene Komponenten zur Verfügung, mit deren Hilfe sich das Model-View-Controller Pattern relativ schnell und einfach in einer Javascript Anwendung umsetzen lässt. Um Daten zu persistieren oder vorhandene Daten in die Applikation zu laden, wird in den meisten Fällen eine Serverkomponente benötigt. Backbone.js sieht eine RESTful API zum Server vor, um diese Kommunikation durchzuführen. Die Entwickler von Backbone.js haben sich dazu entschlossen möglichst Komponenten aus existierenden Bibiotheken zu verwenden. So wird zum Zweck der Kommunikation mit einem Server beispielsweise die ajax-Komponente von jQuery verwendet. Weiterlesen
Dieser Blogartikel soll zeigen, wie schnell und unproblematisch es sein kann, eine einfache Applikation mit BackboneJs und Zend Framework umzusetzen.
Als konkretes Beispiel wird hier eine Applikation zur Verwaltung von Adressen verwendet. Mit dieser Anwendung soll das Zusammenspiel verschiedener Komponenten wie Datenbank, Service Layer mit Zend Framework und Applikations Layer in BackboneJs veranschaulicht werden.
BackboneJs gibt als Kommunikationsinfrastruktur zum Backend REST vor. Aus diesem Grund soll in einem ersten Schritt Zend Framework so konfiguriert werden, dass es RESTful mit dem Frontend kommunizieren kann. Im nächsten Schritt wird die Applikationslogik seitens PHP umgesetzt und somit die konkrete Schnittstelle zum Frontend definiert. Aufbauend auf dieser Schnittstelle wird das Frontend umgesetzt.
Im IEEE-Standard 1061 sind Softwaremetriken wie folgt beschrieben:
“Eine Softwaremetrik ist eine Funktion, die eine Software-Einheit in einen Zahlenwert abbildet. Dieser berechnete Wert ist interpretierbar als Erfüllungsgrad einer Qualitätseigenschaft der Software-Einheit.”
Jetzt stellt sich die Frage: Wozu benötigen wir Softwaremetriken überhaupt? Diese Frage lässt sich relativ leicht beantworten: Metriken werden benötigt, um Software und deren Qualität messbar zu machen. Hat man nun diese konkreten Werte vorliegen, kann man die Produkte verschiedener Anbieter anhand bestimmter Kriterien miteinander vergleichen, um eine Kaufentscheidung zu erleichtern. Ein weiterer Anwendungsfall für Softwaremetriken ist, dass sich mit ihnen der aktuelle Stand eines Projekts dokumentieren lässt. Werden Metriken über einen längeren Zeitraum gesammelt, erlauben sie Rückschlüsse auf die Entwicklung in einem Team und einem Projekt.
Das Thema Softwaremetriken ist nicht wirklich neu und auch nicht sonderlich spektakulär. Softwaremetriken sind seit vielen Jahren der Gegenstand von Forschung an verschiedensten Universitäten und damit sowohl praktisch als auch theoretisch sehr gut dokumentiert. Die Probleme treten allerdings schon auf, wenn man den ersten Schritt von der Theorie in die Praxis wagt: Für welche Programmiersprachen stehen welche Metriken zur Verfügung?
Etwas Recherche im Internet zeigt, dass es für Java, C und C++ Werkzeuge zur Erfassung von Softwaremetriken wie Sand am Meer gibt. Diese Tatsache ist allerdings auch nicht weiter verwunderlich, da die Forschungsarbeiten in erster Linie auf diesen Sprachen aufbauen und auch die Notwendigkeit eines lückenlosen Qualitätsmonitorings in diesen Bereichen in großem Maß vorhanden ist.
In unserer täglichen Arbeit sind Metriken im PHP Umfeld relevant. Auch hier existiert ein Satz an Werkzeugen, der die wichtigsten Metriken erfasst. Eine Anforderung an Messwerkzeuge ist, dass diese für den Entwickler keinen unnötigen Aufwand verursachen und die Metriken automatisiert erzeugt werden. Zu diesem Zweck generieren Werkzeuge wie beispielsweise phpunit, phpmd und phpcs Ausgaben in xml und lassen sich damit in eine Continuous Integration Plattform wie Jenkins integrieren. Ist dies erreicht, werden die Werkzeuge bei jedem Commit ins Versionskontrollsystem ausgeführt und es stehen allen am Projekt Beteiligten detaillierte Informationen über die Qualität des Quellcodes zur Verfügung.
Da Javascript zunehmend an Bedeutung in der Entwicklung von Webapplikationen gewinnt, besteht auch hier Bedarf an Qualitätssicherung. Um eine möglichst hohe Qualität im Bereich Javascript durchzusetzen, müssen einige Voraussetzungen erfüllt sein. Das Wichtigste, was hier zu nennen wäre, ist die strikte Trennung von Darstellung und Logik. In der Praxis bedeutet dies: HTML stellt die Struktur der Seite und deren logischen Aufbau dar, CSS wird für die Darstellung und das Layouting verwendet und Javascript beinhaltet die Frontendlogik. Diese drei Bereiche sollten strikt getrennt und in jeweils eigenen Dateien abgelegt werden. Durch dieses Vorgehen können die einzelnen Teilaspekte unabhängig voneinander betrachtet werden.
Die einfachste Kategorie von Metriken, die in Javascript zur Verfügung stehen, sind die sogenannten LOC-Metriken (Lines of Code). Bei diesen Metriken werden die Zeilen des Quellcodes gezählt. Ein Tool, mit dem diese Metriken erfasst werden können, ist CLOC. Hier wird neben der reinen Anzahl an Zeilen unterschieden zwischen eigentlichen Codezeilen, Kommentaren und Leerzeilen und auf wie viele Dateien diese verteilt sind.
In Verbindung mit Konventionen, die für das Projekt vereinbart werden, wie beispielsweise die maximale Zeilenlänge oder höchstens ein Statement pro Zeile, machen LOC Metriken Sinn.
Einen weiteren Satz von Werkzeugen bilden die Unittest-Frameworks. Unittests werden verwendet, um Bausteine von Software, die sogenannten Units, zu prüfen. Voraussetzung, um Unittests zu erstellen, ist eine sinnvolle objektorientierte Architektur der Anwendung.
Die erste Metrik, die für Unittests zur Verfügung steht, ist die Anzahl der Tests. Diese kann von einigen wenigen Tests bis hin zu mehreren Tausenden reichen. Die Zahl der Tests für sich gesehen ist allerdings kein Qualitätsmerkmal. Pro Unit, die getestet wird, sollten mehrere Tests existieren. Die minimale Anforderung ist ein Test für den positiven Fall und einer für den Fehlerfall. Je nach Logik in der Einheit, kann es sein, dass mehrere Fälle abgetestet werden müssen, um sicherzustellen, dass die gewünschte Funktionalität reibungslos abläuft.
Als Framework für die Unittests kann beispielsweise qunit verwendet werden. Ursprünglich entstand dieses Werkzeug für die Qualitätssicherung von jquery, kann allerdings unabhängig davon verwendet werden. Zur Automatisierung und Integration in eine Continuous Integration Plattform wie Jenkins wird jsTestDriver verwendet. Für dieses Tool existiert ein Adapter, der bestehende qunit Tests in jsTestDriver lauffähig macht.
Die Qualität von Unittests lässt sich kaum messen. Das einzige Mittel, das eine Aussage über die Qualität der Tests erlaubt, ist die Testabdeckung. Die Testabdeckung beschreibt, wie viel des Quellcodes wirklich durch die Tests abgedeckt ist, also, ob alle if-Statements berücksichtig sind und ob sämtliche Cases in Switch-Statements geprüft werden. Eine Testabdeckung von 100% bedeutet, dass sämtlicher Quellcode durch die Unittests einmal ausgeführt wurde. Aber auch eine hundertprozentige Testabdeckung stellt nicht sicher, dass sämtliche Kombinationen der Applikationslogik geprüft werden. Hier ist es notwendig, dass sich die Entwickler Gedanken über die auftretenden Fälle machen, Testpläne erstellen und diese gezielt durch Unittests absichern.
Jetzt kommen wir zu einem Werkzeug, das in keinem Javascript-Projekt fehlen darf: jslint. Dieses Programm durchsucht den Quellcode nach möglichen Problemen. Hierunter fallen sowohl die korrekte Einrückung des Quellcodes, als auch ein Komma zu viel am Ende einer Arraydefinition oder Zuweisungen in if-Statements statt einem logischen Operator.
Jslint ist sowohl über ein Webformular als auch offline verfügbar. Da die Implementierung vollständig in Javascript erfolgte, ist es problemlos möglich, dieses Tool auf jedem Rechner über die Kommandozeile auszuführen, man benötigt lediglich eine Javascript Engine.
Im alltäglichen Gebraucht hat es sich als praktisch erwiesen, jslint als Pre-Commit Hook einzubinden und jeden Commit abzuweisen, der fehlerhaftes Javascript beinhaltet. Mit jslint4java generiert jslint xml-Ausgaben und kann damit auch in eine Continuous Integration Plattform wie Jenkins integriert werden.
Einen Schritt weiter geht das Javascript Plugin für die Qualitätsmanagement Plattform Sonar. Mit diesem Plugin werden neben den Prüfungen von jslint auch Codeduplikation und Komplexität gemessen.
Doppelter Code ist in vielen Projekten ein Problem, da aus Gründen der Zeitersparnis einfach Code kopiert wird und nicht sauber ausgelagert und von verschiedenen Stellen referenziert wird. Die Copy-Paste-Detection vergleicht allerdings nicht Codeblöcke Wort für Wort miteinander, sondern auf Ebene des Abstract Syntax Trees. Es nützt also nichts, einfach nur Variablen umzubennen oder Whitespaces einzufügen.
Zur Bewertung der Komplexität benutzt das Sonar Javascript Plugin die zyklomatische Komplexität des Quellcodes. Diese Metrik wird beeinflusst durch die Anzahl der Anweisungen und die Kontrollflüsse zwischen diesen. Weist Quellcode eine zu hohe Komplexität auf, ist er schwer zu lesen. Aus dieser Tatsache folgt ein erhöhter Wartungsaufwand und eine länger andauernde Einarbeitungsphase.
Zusammenfassend lässt sich sagen, dass die Qualitätssicherung im Bereich Javascript momentan noch in den Kinderschuhen steckt. Allerdings ist hier eine rasante Entwicklung zu beobachten. Vor allem im Bereich der Continuous Integration und Continuous Inspection ist eine erfreuliche Tendenz festzustellen. Immer mehr Werkzeuge lassen sich in Plattformen integrieren und ermöglichen so die regelmäßige Prüfung von Javascript Quellcode in einem Projekt.
Allgemein lässt sich festhalten, dass eine Metrik für sich alleine gesehen in den seltensten Fällen wirklich aussagekräftig ist. Kombinationen verschiedener Metriken oder Metrikgruppen hingegen erlauben Rückschlüsse auf die Qualität der Applikation.
Hier ein kurzes Beispiel, um diesen Sachverhalt zu verdeutlichen: Nimmt man eine Funktion, kann man über die LOC-Metrik herausfinden, aus wie vielen Zeilen diese Funktion besteht. Dieser Wert an sich erlaubt kaum eine Aussage, außer, dass eine große Anzahl von Zeilen nicht erstrebenswert ist, da sich diese Funktion dann tendenziell um mehr als eine Sache kümmert. Zieht man die zyklomatische Komplexität zu Rate, kann man schon qualifiziertere Aussagen treffen. Eine umfangreiche Funktion mit einer hohen Komplexität stellt ein Problem dar und sollte in kleinere Einheiten unterteilt werden; eine lange Funktion mit geringer Komplexität deutet auf eine prozedurale Funktion hin, die ebenfalls verbesserungswürdig ist. Sinnvoll sind demnach relativ kurze Funktionen mit moderater Komplexität.
Neben dem reinen Qualitätsaspekt kann durch Metriken auch die Performance des gesamten Teams oder einzelner Entwickler gemessen werden. Hier beginnt die Messung schon bei der Anzahl an Commits oder Lines of Code, die ein Entwickler erstellt. Auch hier gilt, jede Metrik kritisch zu hinterfragen. Interessanter sind dann Kombinationen wie beispielsweise die Anzahl der Zeilen pro Commit. Commits mit einer großen Anzahl von Zeilen sind meist problematisch, da sie dem Prinzip atomarer Commits widersprechen.
Die Metriken eines Projekts sollten allen am Projekt Beteiligten zur Verfügung stehen. Nur durch einen offenen Umgang lassen sich die Vorteile der Softwaremessung ausnutzen. Stehen dem Team alle Informationen über die Qualitätsaspekte der erstellten Software zur Verfügung, können die einzelnen Entwickler gezielt an ihren Schwächen arbeiten und das Projekt gemeinsam stabilisieren und den maximalen Nutzen aus ihren Fähigkeiten ziehen.
At the Mayflower Barcamp 2009 we (Martin, Daniel, Sebastian, Max, Sarah, Peter and Konstantin) started a new project named phpMyBirthday. The main goal of it is to give you a tool to manage the birthday dates of your friends.
To achieve this we first built a import for vcards so that you can easily import the data out of your email-client e.g. Thunderbird or Outlook.
The application base structure is built on Zend Framework in version 1.8 and it makes heavy use of the features of the framework such as the MVC-structure, Zend_Date, Zend_Db, Zend_Form. To improve the usability we decided to use the Javascript framework Dojo, which comes with a huge set of features and allows you to fine tune your application. Another feature of the application is the email notification. You get a notification if one of your friends has birthday soon.
The next steps will be the improvement of the frontend and the enrichment of features in the backend such as extended management of contact data and more import and export interfaces.
Am 13.05. war es wieder so weit: Abfahrt zum alljährlichen Mayflower Barcamp. Hier hatten die Entwickler die Möglichkeit in der idyllischen Berglandschaft Südtirols an verschiedenen Open Source oder Firmen-internen Projekten zu entwickeln. Statt der 3 Tage im letzten Jahr wurde der Zeitrahmen auf 5 Tage verlängert. Damit konnten auch umfangreichere Projekte umgesetzt werden. Insgesamt standen 10 Projekte zur Auswahl.
Aber auch das Rahmenprogramm konnte sich sehen lassen: Am Donnerstag stand ein Besuch im Andreas Hofer Museum am Geburtsort des bekannten Tiroler Freiheitskämpfers auf dem Plan. Im Anschluss fand noch eine Weinverkostung statt. Ab Freitag Mittag wurden die Notebooks gegen Ruder eingetauscht und es ging zum Rafting. Samstag nach Abschluss und Vorstellung der Projekte wurde dann in der örtlichen Brauerei nach einer Führung durch die selbige auf die Erfolge der letzten Tage angestoßen.
Die ab und an etwas langsame Internetverbindung ließ die Projektarbeit öfters mal ins Stocken geraten. Auch hätte man sich ein paar mehr Steckdosen gewünscht. Aber wie auch schon beim letztjährigen Barcamp herrschte eine sehr gute Stimmung, und die Zusammenarbeit in den Teams war hervorragend.
