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

Meteor – ein neuer Webframework-Stern

Als SW-Entwickler erlebt man bei der Nutzung von Web-Technologien immer mal wieder dieses Aha-Gefühl, sodass einem sofort deutlich wird: „Diese Technologie wird die Web-Entwicklung maßgeblich beeinflussen“. Die Programmiersprache, das Web-Framework oder die Denkweise, mit der man aktuell ein Web-Projekt umsetzt, wird in wenigen Jahren als schwergewichtig und veraltet angesehen werden.

Dieses Aha-Gefühl hatte ich gerade wieder, als ich die Meteor-Plattform ausprobiert hatte. Es scheint mir einen ähnlich wegweisenden Einfluss zu haben, wie andere bekannte Technologien:

Mit meiner kleinen Beispiel-Anwendung kann ein Anwender (passend zur Bundestagswahl 2013) seine Wahlstimme abgeben, welche Partei er wählt und einen entsprechenden Marker auf einer Karte in der Nähe seines Heimatortes setzen. Als clientseitige Standalone-Lösung läßt sich das einfach mit OpenLayers realisieren, allerdings sollen die Wahlstimmen serverseitig gespeichert werden und andere Clients automatisch benachrichtigt werden! Das Beispiel besteht gerade einmal aus 60 Zeilen HTML-Code und 160 Zeilen JavaScript-Code (davon 100 Zeilen für OpenLayers) !!! Ja, bei so wenig Code kann man sich drei Ausrufezeichen mal leisten.

Meteor: Wahlstimmen auf OpenStreetMap-Karte

Meteor: Wahlstimmen auf OpenStreetMap-Karte

Weiterlesen

REST-Schnittstelle in JavaScript mit Node.js

Ich probiere gerade diverse MVVM-Frameworks (z.B. Knockout) aus und bei den Beispielen werden oft JSON-Daten mit Servern über REST-Schnittstellen ausgetauscht. Jetzt wird es also Zeit für einen eigenen kleinen Server, bei dem wir mit einfachen HTTP-Aufrufen Daten abfragen (GET), anlegen (POST), aktualisieren (PUT) und löschen (DELETE) können. In unserem Beispiel werden wir Bewertungen (Ratings) über folgende API verwalten:

Methode Pfad Beschreibung
GET /ratings Liste aller Bewertungen abfragen
GET /ratings/2 Bewertung mit der Id 2 abfragen
POST /ratings Erstellt eine neue Bewertung
PUT /ratings/2 Aktualisiert die Bewertung mit der Id 2
DELETE /ratings/2 Löscht die Bewertung mit der Id 2

Mir liegt ja eigentlich die Programmiersprache Java am besten, aber einen entsprechenden REST-Server in Java aufzusetzen (beispielsweise mit Spring-MVC und Tomcat) war mir etwas zu umständlich. Mit Ruby on Rails ist man sicherlich flotter am Start, wobei der Trend ja zu JavaScript auf dem Server liegt. Also Node.js schnell mal per Homebrew (bei MacOS) installieren.

brew update
brew install nodejs
brew info nodejs
brew install npm
brew info npm

Weiterlesen

Webdesign vereinfachen mit CSS-Framework Blueprint

Bei der Gestaltung von Webseiten muss der Webdesigner einiges beachten. Insbesondere die unterschiedlichen Darstellungen bei der Vielzahl von Browsern, Geräten und Betriebssystemen sorgen für einen erhöhten Aufwand bei der Umsetzung einer Webseite.

Wer sich viel Zeit und Frust ersparen möchte, entwickelt eine Webseite daher lieber nicht komplett alleine. Stattdessen sollte man sogenannte CSS-Frameworks als Grundgerüst einsetzen und damit die Erfahrungen vieler CSS-Experten nutzen. Die bekanntesten CSS-Frameworks sind:

Die genannten CSS-Frameworks bieten größtenteils ähnliche Funktionen an. Ich habe mich bei meiner Webseite für Blueprint als solide Basis entschieden, weil es besonders schlank ist und trotzdem reichhaltige Funktionen beinhaltet:

  • CSS-Reset, damit alle Browser gleiche Standardeinstellungen haben
  • ein Grid-System womit auch komplizierte Layouts möglich sind
  • gute typographische Voreinstellungen
  • Styling von Formularelementen
  • Stylesheet speziell für Ausdrucke
  • Plugins for Buttons, Tabs und Sprites
  • vielfältige Browserunterstützung (IE ab 6.0, Firefox ab 3.0, Opera ab 9.6)

Weiterlesen

PSI-Probe – ein besserer Tomcat-Manager

Schnell mal eine Web-Anwendung im Tomcat deployen, sich einen Überblick über den Speicherverbrauch verschaffen oder einen Blick in die Log-Dateien werfen – mit PSI-Probe ist das bequem und einfach. PSI-Probe dient der Administration und Überwachung von Tomcat-Servern und bildet damit eine ausgezeichnete Alternative zu dem hauseigenen Tomcat-Manager.

Bei den zahlreichen Features sollte jeder Tomcat-Nutzer PSI-Probe mal ausprobiert haben:

  • einfache Installation als Web-Anwendung
  • Status von Web-Anwendungen anzeigen
  • deploy, start, stop, undeploy von Web-Anwendungen
  • Statistiken zu Sessions und Requests anzeigen
  • Log-Dateien sich live anzeigen lassen
  • System-Properties auflisten
  • Statistiken zu JVM und Garbage Collection
  • Statistiken zu CPU, Speicher, Datei-System
  • und vieles, vieles mehr …
Probe - Applications

Probe – Applications

Weiterlesen

Velocity, Freemarker, Jade4J – Alternativen zu JSPs

Webanwendungen auf Java-Basis werden heutzutage größtenteils mit Hilfe eines umfangreichen Webframeworks (wie Java Server Faces, Google Web Toolkit oder Wicket) realisiert. Viele dieser Technologien bringen ihre eigene Templatesprache mit, die HTML um eigene Elemente erweitern. Falls man allerdings die Web-Basistechnologien Servlets/JSPs nutzt oder das Webframework neben JSPs auch andere Templatesprachen unterstützt (wie Spring MVC), wird der Einsatz einer alternativen Templatesprache vielleicht mit höherer Produktivität und mehr Spaß belohnt.

Solange man nur auf eine Templatesprache wie JSP beschränkt ist, braucht man sich auch keine Gedanken um die Effizienz der eingesetzten Sprache zu machen. Aber in diesem Artikel möchte ich dazu animieren, andere Templatesprachen mal auszuprobieren. Deren produktiven Einsatz sollte man sich natürlich zuvor gut überlegen – einige Aspekte sind beispielsweise:

  • Sprache: Einfachheit und Klarheit versus Ausdrucksstärke und Komplexität
  • Erweiterungen: Erstellung und Einbindung von Bibliotheken (z.B.: Tag-Libraries für JSPs)
  • Werkzeuge: Unterstützung innerhalb von Editoren/IDEs (z.B.: Syntax-Highlighting)
  • Mitarbeiter: Know-How im Team und Bereitschaft neue Sprachen zu lernen

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