Ein Docker-Container – und Deine Anwendung läuft überall

„But it works on my machine!“

Diese allseits bekannte Entwickler-Wahrheit deutet schon seit langem darauf hin, daß die Portierung einer perfekt funktionierenden Anwendung in einen anderen Kontext immer schwieriger wird. Immer mehr Tools, Konfigurationen und unvorhergesehene Sicherheitsbestimmungen.. da kann die Präsentation der schönsten Anwendung zum frustrierenden Erlebnis werden.

dockerlogo

Transport im Docker-Container

Die Macher von Docker haben sich gedacht, daß es ja wohl nicht sein kann, daß die Menschheit mittlerweile Waren in jeglicher Form an jeglichen Ort der Welt verschiffen kann, aber die IT-Welt es immer noch nicht hinkriegt, problemlos eine Anwendung von einem Kontext in den nächsten zu portieren. In Anlehnung an diese Allegorie wurde 2013 der Docker-Container erfunden. Ebenso wie ein großer Schiffscontainer ein einheitliches (seit 1956 nach ISO-Norm standardisiertes) Format hat, das gleichermaßen von Schiffen und LKWs transportiert und gestapelt werden kann und mit beliebigem Inhalt zu befüllen ist, ist der Docker-Container dafür zuständig, eine Anwendung beliebiger Art so in sich zu kapseln, daß der Container alle Kontextinformationen übernimmt und sich problemlos in verschiedene Umgebungen verschieben lässt.

docker-containers

Quelle: Eine Folie des Docker Erfinders Solomon Hykes aus seiner Präsentation während der DockerCon Konferenz im Juni 2014.

Weiterlesen

Entscheidung für ein passendes Web Application Framework

Du hast eine spitzen Idee für eine Web-Anwendung und willst am liebsten gleich losprogrammieren. Aber beim Einrichten Deiner Entwicklungsumgebung fällt Dir ein, daß du gerne mal etwas Neues ausprobieren möchtest, das Dir ein paar Arbeitsschritte erspart und ein schickes modernes Design liefert. Du möchtest gerne ein Web-Application-Framework verwenden.

Ein Web Application Framework ist grundsätzlich für die Entwicklung von dynamischen Webseiten, Webanwendungen oder Webservices ausgelegt. Damit werden sich wiederholende Tätigkeiten vereinfacht, die Wiederverwendung von Code und die Selbstdokumentation der Software-Entwicklung gefördert. Begibt man sich allerdings auf die Suche stellt man schnell fest, daß es unendlich viele Möglichkeiten gibt. Deshalb sollte man zunächst festlegen, welche Anforderungen man an ein solches Framework hat und dann die Alternativen nach diesen Anforderungen hin abklopfen.  Die Frage nach richtig oder falsch läßt sich natürlich so einfach nicht beantworten, aber gut ist es doch ein paar Vor- und Nachteile zu kennen.

web-frameworks

Weiterlesen

Datenbanken für Couch Potatoes und Big Data Management

No more SQL?

Viele Entwickler verwenden heute Datenbanken, die ohne oder mit wenig SQL auskommen. Ein Trend der sich NoSQL nennt.

Der Begriff NoSQL wird zunächst durch das defniert was er nicht ist, nämlich kein SQL. Er wurde erstmalig 2009 von Eric Evans für ein Event in San Francisco verwendet. Vorrangig sollte er als provokative Phrase aufgefasst werden, als Abgrenzung zu der strukturierten Abfragesprache SQL. NoSQL hat zum Ziel, Alternativen zum allgegenwärtigen relationalen Datenbankmodell und üblichen Datenbanktechnologien aufzuzeigen, die für bestimmte Anwendungsfälle besser geeignet sind. Mit dem Web2.0 und dem damit einhergehenden Bedarf nach der Verarbeitung großer Datenmengen erfuhren NoSQL-Datenbanken ein sehr schnelles Wachstum. Die Vereinigung fast aller nicht relationaler Datenbanken unter dem Begriff NoSQL zeigte eine ernstzunehmende Alternative zu SQL-Datenbanken auf. Mittlerweile wird der Begriff von großen Teilen der Community als „Not-only-SQL“ aufgefasst, um somit die strikte Abgrenzung wieder aufzuweichen. Es gibt auch viele Hybrid-Lösungen. Je nach Anwendung gilt es die richtige Datenbank auszuwählen und in vielen (vor allem sicherheitskritischen und komplexen) Fällen ist eine relationale Datenbank auch nach wie vor die richtige Lösung. Die NoSQL-Bewegung setzt sich grundsätzlich für eine freie Datenbankauswahl ein und schärft das Bewußtsein für das große Spektrum an Datenbanken, das zur Verfügung steht.

Im NoSQL-Archiv von Dr. Prof. Stefan Edlich sind alle NoSQL-Datenbanken aufgeführt, aktuell bereits 150!

sql-vs-nosql

Weiterlesen

Automatisiertes Testen von Webseiten mit dem Selenium WebDriver

Das Open Source Projekt „Selenium“ zum Durchführen automatisierter Browser Tests gibt es bereits seit 2004. Ins Leben gerufen wurde es von Jason Huggins, während seiner Zeit bei ThoughtWorks, die zu diesem Zeitpunkt hauptsächlich mit Javascript arbeiteten. Obwohl  der InternetExplorer der beherrschende Browser war, wurden bei ThoughtWorks bereits einige alternative Browser benutzt (vor allem Mozilla Varianten). Open Source Testing Tools gab es nur für einzelne Browser (typischerweise für den InternetExplorer) oder es waren Simulationen von Browsern (z.B. HttpUnit) und die Kosten für kommerzielle Tools waren vor allem für kleine Projekte noch nicht bezahlbar .

Glücklicherweise unterstützten alle zu testenden Browser Javascript. Deshalb machten sich Jason und sein Team daran ein Testing Tool in der Sprache zu schreiben die das Verhalten ihrer Applikation am Besten verifizieren konnte. Inspiriert von dem FIT-Projekt wurde eine tabellenbasierte Syntax über das Javascript gelegt und es damit auch Nutzern mit begrenzten Programmierkenntnissen ermöglicht Tests zu schreiben. Dieses Tool wurde 2004 unter dem Namen „Selenium“ (oder auch „Selenium Core“) und unter einer Apache 2 Lizenz veröffentlicht.

Da Selenium in purem Javascript geschrieben ist, musste es auf dem gleichen Server wie die Applikation laufen, um die Browser Sicherheitsbestimmungen zu umgehen. Das war aber nicht immer möglich. Um dieses und andere Probleme zu lösen wurde ein HTTP Proxy geschrieben. Damit ließen sich viele Einschränkungen der  „Same Host Policy“ der Browser umgehen. Dieses Design ermöglichte es, Selenium-Anbindungen für viele Programmiersprachen zu schreiben. Sie mussten nur in der Lage sein eine HTTP-Anfrage an eine bestimmte URL zu schicken. Diese Version wurde bekannt als „Selenese“ oder auch „Selenium Remote Control“ (Selenium RC).

Währenddessen wurde bei ThoughtWorks an einer weiteren Browser Automatisierung gearbeitet: dem WebDriver. 2007 wurde der erste Code hierzu veröffentlicht. Er wurde für Nutzer von Projekten entwickelt, die ihre Ende-zu-Ende-Tests von dem darunterliegenden Test-Tool isolieren wollten. Typischerweise wird dies mit dem Entwurfsmuster Adapter gemacht. WebDriver entwickelte sich aus diesem Bedürfnis heraus und war ursprünglich für HTML Unit gedacht. Die Unterstützung für den InternetExplorer und Firefox folgten aber kurz nach dem Release.

Es gab erhebliche Unterschiede zwischen Selenium RC und WebDriver. Der größte Unterschied war, daß Selenium RC eine Wörterbuch-basierte API hatte, die alle Methoden für eine Klasse beanspruchte, während der WebDriver eine objektorientiertere API hatte. Außerdem unterstützte der WebDriver zunächst nur Java, während Selenium RC Unterstützung für viele Sprachen anbot. Technisch war Selenium Core hauptsächlich eine Javascript-Applikation, die in der Security-Sandbox des Browsers lief. WebDriver versuchte sich in den Browser zu integrieren, und das Browser Sicherheitsmodell zu umgehen, was einen weitaus höheren Entwicklungsaufwand zur Folge hatte.

Im August 2009 wurden beide Projekte miteinander verschmolzen. und der Selenium WebDriver ist das Resultat beider Projekte. Er unterstützt Sprachanbindungen für Java, C#, Python und Ruby. Außerdem bietet er Unterstützung für Chrome, Firefox, Internet Explorer, Opera und die Android und iPhone Browser. Es gibt Nebenprojekte die Anbindungen für Perl und eine Implementierung für den BlackBerry Browser anbieten.

Einrichten der Testumgebung 

Beispiel für Eclipse und Java

Die WebDriver API ist nicht an ein spezielles Testframework gebunden und kann sowohl in Unit Tests als auch in der guten alten Main-Methode verwendet werden.

Weiterlesen