CloudBees – Continuous Integration & Delivery leicht gemacht

Wenn man als SW-Entwickler eine kleine Webanwendung für Freunde, Kollegen oder die ganze Menschheit bereitstellen möchte, müssen oft einige Herausforderungen gemeistert werden. Das eigentliche Programmieren der Anwendung geht vielleicht noch recht problemlos. Aber es entsteht ja leider noch allerhand weiterer Aufwand, um beispielsweise die benötigte Infrastruktur zu installieren:

  • Verwendung einer Quellcodeverwaltung (z.B. Git)
  • Installation einer Datenbank (z.B. MySQL, PostgreSQL)
  • Ausführen von Entwickler-Tests (z.B. mit Ant oder Maven)
  • Bauen der Anwendung (z.B. mit Ant oder Maven)
  • Bereitstellung der Anwendung auf einem Server (z.B. mit ssh-Skripte)
  • Testen der bereitgestellten Anwendung (z.B. manuell durch den Entwickler)

Sobald wir öfters neue Anforderungen oder Bugfixes ausliefern müssen, sollten wir diese Schritte nicht mehr manuell durchführen sondern automatisiert haben. Das Zauberwort heißt hier natürlich Continuous Integration und falls wir fehlerfreie Software auch gleich deployen, sind wir schon bei Continuous Delivery. Der CI-Server Jenkins (vormals Hudson) leistet dabei gute Dienste. Den müssen wir uns noch nicht einmal selber installieren, sondern wir bekommen ihn als Platform as a Service (PaaS) von CloudBees bereitgestellt. Dazu liefert uns CloudBees auch alle weiteren Werkzeuge, sodass Continuous Delivery problemlos realisierbar ist:

CloudBees: Continuous Cloud Delivery

Weiterlesen

Advertisements

SMS versenden und empfangen mit BulkSMS

Die erste Kurzmitteilung des Short Message Service wurde am 3. Dezember 1992 (mit dem Text »Merry Christmas«) von einem PC an ein Mobiltelefon im britischen Vodafone-Netz gesendet.

[aus Wikipedia-Artikel zu ‚Short Message Service (SMS)‘: http://de.wikipedia.org/wiki/SMS]

Die erste SMS ist also schon fast 20 Jahre alt und ich habe noch nie eine SMS aus einer Anwendung heraus verschickt. Das wurde aber jetzt mal Zeit! Im Internet findet man eine Vielzahl von Anbietern, sodass man sich erst einmal überlegen sollte, welche Anforderungen eigentlich bestehen:

  • nur Senden von SMS oder auch Empfangen von SMS
  • wird Zuverlässigkeit beim Versand benötigt
  • Kosten der SMS (Einrichtungsgebühr, Anzahl der SMS)
  • API vorhanden für SMS-Versand/Empfang aus eigenem Programm
  • deutscher oder internationaler Anbieter
  • Zahlungsarten des Anbieters
  • Spezialwünsche: Anbieterkennung verschicken, eigene Rufnummer für den Empfang

Einen konkreten Vergleich der Anbieter habe ich im Internet nicht gefunden. Daher hier einen Verweis zu den Preislisten diverser Anbieter: sloono, SMSout, BulkSMS, SMS77. Von den Preisen und den angebotenen Leistungen unterscheiden sich die Anbieter nicht so sehr:

  • zuverlässig und schnell versendete SMS kosten 6-8 Cent/SMS
  • SMS mit unregelmäßiger Versanddauer kosten etwa 3 Cent
  • angebotene APIs sind beispielsweise HTTP, SOAP und E-Mail

Weiterlesen

Heroku – Platform as a Service (PaaS) mal schnell ausprobiert

Als ich vor einigen Jahren das erste Mal die PaaS-Angebote von Heroku (cloud application platform) und Google (App-Engine) ausprobierte, war ich von den Möglichkeiten fasziniert:

  • Installation und Betrieb deiner Webseite/Webanwendung mit Datenbank in der Cloud
  • keine eigene Infrastruktur und damit keine eigenen Server-Konfigurationen
  • kleine Webanwendungen lassen sich kostenlos bei den Anbietern betreiben
  • automatisches Hochskalieren bei Last
  • und alles so einfach und bequem !!!

Natürlich gab/gibt es auch ein paar Nachteile gegenüber dem Betrieb eines eigenen Servers:

  • Programmiersprache ist nicht frei wählbar (früher: Ruby bei Heroku, Python und Java bei Google)
  • Datenbank-Features sind beschrängt, auch die Frage ob SQL- oder NoSQL-Datenbank
  • bei den sonstigen Server-Komponenten (wie Messaging) ist man auf die Auswahl des Anbieters angewiesen
  • höhere Kosten als bei einem eigenen Server, wenn die Last steigt oder mehr Speicherplatz benötigt wird
  • Datenschutzprobleme, falls sich Benutzerdaten in der Cloud außerhalb Europas befinden

Ich hatte damals den Eindruck, dass man sich bei der Architektur der eigenen Anwendung sehr verbiegen muss, damit sie in der entsprechenden Umgebung auch läuft. Trotzdem bieten die PaaS-Angebote natürlich tolle Möglichkeiten, entwickelte Anwendungen schnell im Netz zu veröffentlichen. Und daher habe ich jetzt mal wieder Heroku ausprobiert – es hat sich einiges getan und Heroku fühlt sich wirklich gut an…

Homepage Heroko (einfach schick)

Homepage Heroko (einfach schick)

Weiterlesen

Migration der Konfigurationsdateien des m2e-Plugins (Maven Integration for Eclipse)

Mit dem Eclipse-Plugin m2e (m2eclipse) ‚Maven Integration for Eclipse‘ kann man innerhalb von Eclipse die Mächtigkeit von Maven nutzen. Das Plugin ist mit der 1er-Version von Sonartype zu Eclipse umgezogen, wobei vorhandene Konfigurationen nach dem alten Plugin mit der neuen Plugin-Version nicht mehr funktionieren.

Wenn wir ein bestehendes Projekt mit der Konfiguration nach dem alten Plugin haben, müssen wir nur ein paar Einträge in den Eclipse-Konfigurationsdateien ändern, damit das Projekt mit dem neuen Eclipse-Plugin wieder funktioniert. Die folgenden Anpassungen habe ich mit Eclipse Indigo und der m2e-Version 1.0.100.20110804-1717 ausprobiert.

Zunächst müssen wir die .project-Datei anpassen. Dort müssen wir erst einmal den Nature-Eintrag von

<nature>org.maven.ide.eclipse.maven2Nature</nature>

auf

<nature>org.eclipse.m2e.core.maven2Nature</nature>

ändern, damit das Projekt als m2e-Projekt erkannt wird. Dann müssen wir noch den Builder-Eintrag von

<buildCommand>
   <name>org.maven.ide.eclipse.maven2Builder</name>
   <arguments>
   </arguments>
</buildCommand>

auf

<buildCommand>
   <name>org.eclipse.m2e.core.maven2Builder</name>
   <arguments>
   </arguments>
</buildCommand>

anpassen, sodass der korrekte Builder beim Erstellen des Projekts genutzt wird. Damit sollten alle m2e-Funktionalitäten im Eclipse-Projekt wieder verfügbar sein. Allerdings compiliert das Projekt vielleicht noch nicht.

Wir müssen in der .classpath-Datei noch den Eintrag für die Variable MAVEN2_CLASSPATH_CONTAINER anpassen, damit die Java-Librarys von Maven auch eingebunden werden. Dafür ändern wir die Zeile

<classpathentry kind="con" path="org.maven.ide.eclipse.MAVEN2_CLASSPATH_CONTAINER"/>

auf

<classpathentry kind="con" path="org.eclipse.m2e.MAVEN2_CLASSPATH_CONTAINER"/>

um. Jetzt sollte in der ‚Package Explorer‘-View ein Library-Eintrag „Maven Dependencies“ mit den entsprechenden Java-Librarys vorhanden sein und das Projekt ohne Fehler compilieren.

Es gibt übrigens hier ein kostenloses Online-Buch zu m2e von Sonartype, das allerhand Tipps im Umgang mit dem m2e-Plugin bietet.

GeoJSON erzeugen mit Java

Bei der Webentwicklung hat sich für den Austausch von Daten zwischen Server und Client das JSON-Format bewährt. Es ist gegenüber XML kompakter, lässt sich trotzdem einfach lesen und wird von JavaScript direkt in verwendbare Objekte umgewandelt. Eine spezielle JSON-Ausprägung für geografische Daten bildet das GeoJSON-Format. Dieses Format wird auch von OpenLayers unterstützt, sodass man keinen umfangreichen JavaScript-Umwandlungscode schreiben muss. Der folgende GeoJSON-Code enthält die Daten mit Geo-Koordinaten für drei Plätze in meiner Heimat:

{ "type": "FeatureCollection", "features": [
{ "type": "Feature", "id": 1, "properties": { "name": "", "image": "playground.png"} , "geometry": { "type": "Point", "coordinates": [8.5864, 52.8988] } },
{ "type": "Feature", "id": 2, "properties": { "name": "Balkan-Restaurant", "image": "restaurant.png"} , "geometry": { "type": "Point", "coordinates": [8.5992, 52.9106] } },
{ "type": "Feature", "id": 3, "properties": { "name": "carpe diem", "image": "hairdresser.png"} , "geometry": { "type": "Point", "coordinates": [8.5873, 52.9079] } }
] }

Wie wird jetzt dieser GeoJSON-Code serverseitig generiert? Da GeoJSON auch normales JSON ist, können wir es genauso generieren, wie wir JSON generieren würden. Manche Sprachen unterstützen die Transformation zwischen Objekten und JSON direkt:

  • JavaScript: JSON.stringify($object) und JSON.parse($string)
  • PHP: json_encode($object) und json_decode($string)

In Java müssen wir selber Code dafür schreiben oder eine entsprechende Bibliothek nutzen. Zum Glück gibt es allerhand Java-Bibliotheken für JSON. Mit den Bibliotheken org.json, json-simple und Jackson habe ich ausprobiert, wie leicht das Erzeugen von JSON mit solchen Bibliotheken von der Hand geht. Das ist nur eine kleine Auswahl von den über 20 auf json.org aufgelisteten Bibliotheken.

Weiterlesen

Geodaten aus Datenbank mit Hibernatespatial auslesen

Ich habe mir einige OpenStreetMap-Daten in eine PostgreSQL+PostGIS-Datenbank importiert und möchte diese Daten mit einem Java-Programm auslesen. Dafür scheint zunächst einmal ein ordentliches ORM-Framework (Object-Relational-Mapping) á la JPA (Java Persistence API) sinnvoll, aber leider werden Geo-Typen von JPA 2.0 momentan nicht unterstützt. Dann schauen wir uns Javas Platzhirschen im Bereich ORM an und siehe da: Hibernate bietet die Erweiterung Hibernatespatial für den Umgang mit geographischen Daten. Also, los gehts…

  1. Datenbank mit Geodaten-Tabelle erstellen
  2. Tutorial von Hibernatespatial anschauen
  3. Geodaten-Tabelle mit Geodaten befüllen
  4. Java-Projekt mit Maven, Hibernate und Hibernatespatial umsetzen
  5. Hibernate Criteria-API durch HQL-Abfragesprache ersetzen

Weiterlesen

WiQuery – hübsche Widgets mit Wicket

Viele Java-Entwickler im Web-Umfeld kennen wahrscheinlich das Problem, mit wenig Aufwand soll eine einfache aber auch hübsche Webanwendung erstellt werden.

Während man mit ein bisschen Wicket-Erfahrung schnell die notwendige Logik auf und zwischen den Webseiten programmiert hat, ist ein nettes Design nicht ganz so einfach zu erreichen. Natürlich möchten wir gerne diese Wohlfühl-Atmosphäre schaffen: abgestimmte Farben, weiche Farbverläufe, runde Ecken und schicke Effekte. Und diese stylischen Web2.0-Widgets wären ja auch toll: Autocompletion, Datepicker, Dialog, Accordion, Tabs, Slider, Progressbar…

Mit einer passenden JavaScript-Bibliothek kommen wir unserem Ziel auf jeden Fall näher. Hier mal einige Demos zu den verbreitesten Bibliotheken: JQuery-UI, Dojo, YUI, MooTools. Das Einbinden der vielen hübschen Widgets mit einer JavaScript-Bibliothek hat für Java-Entwickler den Nachteil, dass die Komplexität der Webanwendung erheblich steigt. Am liebsten würden die meisten Java-Entwickler natürlich alles mit Java-Code umsetzen (à la Swing) und müssen sich bei Wicket schon mit der Trennung von Java-Code und HTML-Code auseinandersetzen. Jetzt kommt auch noch JavaScript- und CSS-Code dazu.

Weiterlesen