GAS – was ist Google Apps Script?

Das Unternehmen office:control + setzt für die Büroarbeit verschiedene Google-Anwendungen ein und der Geschäftsführer, Michael Witte, fragte mich, ob ich dafür schon mal etwas programmiert hätte. Ich habe zwar in mehreren Unternehmensprojekten Google Web Toolkit (GWT) eingesetzt und auch mal mit der Google App Engine rumgespielt, aber das meinte er offenbar nicht. Für kollaboratives Arbeiten soll sich ja Google Documents, Spreadsheets und Drive gut eignen, aber wie und was soll man da programmieren?

Er meinte, die Büroarbeit habe er mit einem einfachen papierlosen Workflow schon gut automatisiert und einige Optimierungen wären noch möglich:

  • eintreffendes Dokument scannen, abheften und nie wieder raussuchen müssen
  • Verzeichnis der eingescannten Dateien mit Google Drive synchronisieren
  • Google Documents für selbst geschriebene Dokumente nutzen und unter Google Drive ablegen
  • Nutzung der Google Drive – Volltextsuche zum Auffinden von eigenen oder eingescannten Dokumenten
  • Erfassung von Dokument-Zusatzdaten (Adresse, Datum) mit dem Formulardesigner Google Forms
  • Bereitstellen des Formulars auf einer Website (Google Site)
  • Abspeichern der Formulardaten in einer Tabelle (Google Forms -> Google Spreadsheet)

Das funktioniert schon alles direkt mit den Google-Anwendungen. Und wenn wir etwas wollen, was Google noch nicht anbietet? Dann verwenden wir GAS (Google Apps Script) und die APIs der verschiedenen Google-Anwendungen (Documents, Calendar, Contacts, Drive, Forms, Gmail, Maps, Sites, Spreadsheets):

Weiterlesen

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

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

Kostenlose Karten und Geocoder – welchen Anbieter kann ich nutzen?

Ich habe eine Anfrage erhalten, bestehende Kontaktdaten von Geschäftskunden auf einer Karte innerhalb des Intranets zu visualisieren. Bei den Kartenanbietern können wir zwischen den kostenlosen Karten der kommerziellen Anbieter Google Maps, Yahoo Maps, Bing Maps (Microsoft) und dem freien OpenStreetMap wählen. Jetzt benötigen wir nur noch zu den Adressen der Kontaktdaten die Geo-Koordinaten, damit wir die Kontakte auf einer Karte darstellen können.
Das Auflösen der Adresse zu einer Geo-Koordinate wird als Geocoding bezeichnet, während der umgekehrte Weg, aus einer Koordinate die Adresse zu ermitteln, Reverse-Geocoding genannt wird. Die kommerziellen Kartenanbieter bieten entsprechende Geocoder an und es gibt auch noch weitere kostenlose Geocoder-Dienstleister. Beim Einsatz von Karten und Geocodern muss man einige Punkte abwägen, denn kostenlose Nutzung von Diensten heißt keinesfalls freie Nutzung der Dienste!

Dann überlegen wir jetzt mal, welche Anforderungen wir haben und was wir beachten müssen:

  • die Karte mit den Kontaktdaten der Geschäftskunden soll nur im Intranet (keinesfalls im Internet) einsehbar sein
  • personenbezogene Daten dürfen nicht an andere Unternehmen übermittelt werden (Datenschutzrecht)
  • das Geocoding nur auf Basis der Adressdaten durchführen (ohne personenbezogene Daten)
  • lässt die Lizenz des Kartenanbieters und des Geocoders eine kommerzielle Nutzung zu?
  • maximale Zugriffe, Auflösung, Performanz des Kartenanbieters
  • maximale Zugriffe, Auflösung, Performanz des Geocoders

Weiterlesen

Daten von Webseiten scrapen mit ScraperWiki

ScraperWiki ist ein Internetdienst, der Daten aus verschiedenen Quellen des Internets zusammenführt. Dabei betonen die Macher von ScraperWiki den kollaborativen Charakter ihres Dienstes. Ein Journalist kann beispielsweise eine Anfrage stellen, dass er bestimmte Daten für einen Artikel benötigt, die so zusammengeführt im Internet nicht verfügbar sind. Programmierer können sich dieser Anfrage widmen und ein entsprechendes Scraper erstellen, das die Daten von verschiedenen Webseiten scrapt und zusammenführt. Zusätzlich bietet ScraperWiki Visualisierungen, sogenannte Views, für die Daten an.

Der Programmierer wählt für das Erstellen eines Scrapers zwischen den Programmiersprachen Python, PHP, Ruby und neuerdings auch JavaScript. Die gesammelten Daten werden in einer Datenbank gespeichert und können als CSV, JSON oder SQLite Datenbank heruntergeladen werden. Zusätzlich bietet ScraperWiki eine Abfrage-API per HTTP. Die Abfrage lässt sich per SQL ausdrücken und die Daten stehen dann in verschiedenen Formaten zur Verfügung, wie JSON, CSV, HTML-Tabelle und RSS. Damit die Daten in der Datenbank aktuell bleiben, kann man bei ScraperWiki mit einem Timer festlegen, wie oft das Scraping der Daten durchgeführt werden soll.


Weiterlesen