Web, Mobile, PHP, Drupal, Symfony, Typo3, Theming, Javascript und mehr

In diesem Beitrag wird eine sinnvolle Anwendung für Node.js auf dem lokalen Rechner dargestellt: eine Web-Browser gestützte Console mit GUI für die Steuerung von Automatisierungsaufgaben, wie sie beispielsweise im Zusammenhang mit Staging & Deployment, Maintenance und Continous Integration für die Web-Portal-Entwicklung typisch sind.

Viele weitere Anwendungsbereiche sind denkbar: Node.js-GUI's für

• Staging & Deployment, Continous Integration, Maintenance für die Webentwicklung (hatten wir schon, der Vollständigkeit halber hier nochmal),
• Medien (Heimkino, Media-Center),
• Synchronisation von Daten (lokal, LAN, WLAN, remote, Cloud, Firma, Kunden, Arbeitsplatz),
• Steuerung von Hardware, z.B. Arduino (Schule, Ausbildung, Hobby, CNC-Werkzeug-Steuerung),
• Steuerung von Haustechnik bzw. Internet der Dinge (Heizung, Strom, Energiemanagement, Licht, Alarm, Überwachung, Garten-/Balkonbewässerung).

In Folgenden wird nur eine Lösung für den ersten Punkt oben (Staging & Deployment, Continous Integration, ...) vorgestellt. Dieser wird zudem nicht vollständig ausgebaut, sondern so ausführlich beschrieben, dass jeder leicht seine eigenen Grunt-Aufgaben hinzufügen kann. Material als Anregung hierfür gibt es in diesem Weblog mittlerweile reichlich.

Test-Driven-Design (TDD) ist ein heißes Thema und kaum ein Entwickler kommt mehr daran vorbei. War dieses Feld zunächst nur von Bedeutung in Projekten, die hoch-kritische Prozesse zum Gegenstand hatten, wie sie für Banken, Kernkraftwerke oder gar den Start einer Ariane-Rakete typisch sind, führte die Integration von TDD-Tools in populäre Entwicklungssysteme bald zu einer teilweise auch modischen Verbreitung.

TDD-Tools müssen nicht wirklich in jedem Projekt eingesetzt werden. Vor allem die reine Lehre führt schnell zu einem zusätzlichen Aufwand für das Schreiben von Tests, der nicht immer wirtschaftlich ist.

Die Theorie verlangt, dass vor jeder Funktion, die geschrieben werden soll, erst die zugehörigen Tests entwickelt werden. Dies erfordert viel Disziplin vom Entwickler, die Kenntnis hochentwickelter Testverfahren (Mocking) und das Vorhandensein von sehr viel zusätzlicher Entwicklerzeit. Der Ansatz verspricht, dass dieses Mehr an Entwickleraufwand später wieder hereingeholt wird durch sehr viel weniger Aufwand beim Debuggen.

In der Praxis wird heute aber auch ein weniger fundamentalistischer Ansatz akzeptiert, natürlich nur dann, wenn es nicht um hochkritische Projekte, wie einen Raketenstart, geht. Viele Entwickler haben sich zudem Gedanken gemacht, wie man entsprechende Tools komfortabel in den eigenen Workflow integrieren kann.

Nach einigem Probieren habe ich für mich für die Frontend-Entwicklung das Jasmine-Framework (Behavior driven Javascript) als Unit-Testing-Tool  entdeckt, das per Grunt sehr einfach in den eigenen Workflow integrierbar ist.

Es gehört zur Philosophie des 3 Purpose Grids (Demo), dass nur wenige rudimentäre GUI- und Design-Elemente zur Verfügung gestellte werden, damit der Desinger bzw. Entwickler Freiraum für eine individuelle Gestaltung behält. Dies ist bei vielen CSS-Frameworks, wie z.B. Bootstrap anders. Dort werden viele ausgefeilte GUI-Elemente wie Tabulatoren, Buttons, Sliders, etc. implementiert, deren Verwendung dann allerdings dazu führt, dass ein damit erstelltes Produkt am Ende erkennbar auf einem Bootstrap-Framework aufsetzt. Wer also ein individualisiertes Produkt realisieren möchte, der muss entweder auf diese Elemente verzichten, was zu einem Overhead in den Sourcen führt oder aber z.B. mittels aufwändiger SASS-Modifikationen einen eigenen GUI-Style generieren, was allerdings sehr spezifische Skills erfordert und nicht ganz einfach sein dürfte. Dies soll aber mit unserem Grid-System nicht passieren.

Trotzdem können wir auf die Unterstützung weniger GUI- und Design-Komponenten nicht verzichten. Wir beschränken uns auf CSS-Unterstützung für:

• Menus,
• Medien,
• Info-Boxen,
• Formulare,
• Tabellen und
• Karten.

Andere machen daraus 6 Artikel. Ich packe hier alles in einen. Schließlich will ich ja auch mal fertig werden mit dieser Reihe.

Damit hätten wir dann den ersten Zweck unseres 3 Purpose Grid erreicht, nämlich die Verwendung als ganz normales CSS-Framework für Portale. Wir werden noch einige weitere Teile benötigen, um alle unsere Ziele zu erreichen.

Unser 3-Purpose-Grid soll Ausgangspunkt sein für eine Vielzahl kleinerer Projekte in diesem Weblog. Ziel ist es, sich dieses Grid (Demo) inklusive aller Ressourcen (Bash-, Grunt-Skripte, Cordova-Vorbereitung, vielleicht Testing, falls ich dazu komme, etc.) herunterzuladen, um dann sofort mit der Implementierung des eigentlichen Entwicklungsziels beginnen zu können. Es ist somit wichtiger Teil des hier praktizierten Workflows.

Deshalb stelle ich hier drei Header- und zwei Footersysteme vor, die man sich je nach Zielsetzung eines Projekts oder persönlichem Geschmack auswählen kann.