Node.Js – prototyping für Progressive Web Apps

Er sagte, er hätte tausende Kunden, die bereit wären pro Monat 10,- € für die Nutzung einer kleinen App zu bezahlen. Seine Kunden könnten auch mit dem Smartphone ihre Fotos machen. Wenn es noch ein wenig Komfort dabei gäbe, würden die bestimmt zahlen. Für mich wären pro Kunden ein bis zwei Euro pro Monat drin. Wäre das nichts für mich?

Da war er wieder, der Mann mit der Idee und den Kunden. Meine Erfahrung sagte mir, dass das wohl nichts wird. Aber ich könnte etwas lernen. Wieder etwas in Java für Android und dann für IOS implementieren, kam für mich gar nicht infrage. Das hatte ich 2011 gemacht. Wir schreiben das Jahr 2018. Da gibt es bessere Möglichkeiten.

Eine progressive Web App verhält sich wie eine native App. Wenn das rund läuft, kann ich mit react native das auch native machen, wenn es denn sein sollte. Node.Js interessierte mich sowieso schon. 

Ich war bereit für ein neues Abenteuer.

Wie immer war der Anfang furios. Schnell hatte ich node und npm installiert und auch schon die webcam Komponente heruntergeladen. Am Nachmittag liefe eine erste App, die meine USB Kamera für den mini Mac ansteuerte.

Nun fehlten nur noch die Einstellungen für den Zoom und das Licht. War das wirklich so einfach?

„Node.Js – prototyping für Progressive Web Apps“ weiterlesen

Agile Softwareentwicklung für Startups – Scheitern ist alles

Startups scheitern im Normalfall. Die Idee, die eben noch reiche Ernte versprach, funktioniert aus irgendwelchen Gründen nicht. Mein allererstes Projekt scheiterte bei der Hannovermesse 1984, weil IBM die Schnittstelle zur mittleren Datentechnik (lu 2.16) erst ab 1985 ausliefern wollte. Die Arbeit wurde dann vom Bundesministerium für Forschung und Technologie weiter gefördert.

Ein Startup ohne große Eltern kann auf solch einen Ausweg nicht bauen. Deswegen sollte man die Ursachen des nahezu unausweichlichen Scheiterns so früh wie möglich finden. Ich sage hier wirklich Scheitern, weil es weh tun muss, damit etwas gelernt wird. Damit es weh tut, müssen alle Beteiligten zunächst an den Erfolg bei der Entwicklung des nächsten Iterationsschritts glauben und, soweit als möglich, investieren.

Leider schreib sich das Besser als es mit Gründern und ihren Ideen läuft. Diese träumen lieber und stellen sich vor, ihr Vorhaben wäre fertig. Je exakter die Vorstellung ist, umso schwieriger wird das Scheitern. Deswegen werden dann zunächst risikolose Aktivitäten durchgeführt, damit ja nicht gescheitert wird.

Mittlerweile habe ich drei Anfragen von Startups in diesem Jahr bekommen. Die erste scheiterte nach drei Monaten. „Agile Softwareentwicklung für Startups – Scheitern ist alles“ weiterlesen

Node.js – im Notfall

“Also wenn es ein Notfall ist, kann ich auch Node.js”, sagte ich zu Sascha, einem Recruiter am anderen Ende des Telefons. Auf die Gegenfrage, was ich denn gemacht hätte, antwortete ich, dass ich das installiert habe und bestimmt schaffen würde.

Wir beide lachten.

Er meinte dann, dass Node.js schon im Lebenslauf stehen sollte. Ansonsten glaubte dieser Kunde nicht, dass man das kann. Er selber würde mir das zutrauen, aber die Kunden nicht so direkt. Wenn ich da etwas vorzeigen könnte, dann wäre das etwas anderes.

Für mich war das ein Grund den Besonderheiten von Node.js auf den Grund zu gehen:

  • Was ist Node.js
    Ich kannte es um react.js zu webpacken und zu transpilieren. Damit wollte ich React.js Apps zusammenbauen.
  • Was ist die Hürde für Softwerker mit C++/Pascal Background?
    Da muss etwas sein, das den Auftraggeber zögern lässt.
  • npm – Das Node.js Ökosystem
    Hier mal schauen, was für Bausteine herumliegen.

„Node.js – im Notfall“ weiterlesen

Poor Man Push – WordPress Plugin

Mein Poor Man Push konnte mit Kenntnissen in javascript und html ganz nett in eine einfache Homepage eingebaut werden, aber für eine Einbettung in WordPress war das zu kompliziert. Blogger, die in erster Linie bloggen wollen, brauchen hierfür ein Plugin.

Wer einen WordPress Blog betreibt, kann auch Plugins installieren. Diese Plugins realisieren Funktionen, wie z.B. Bilderleisten, Suchen in Blogartikel oder auch den Verkauf von Produkten und so weiter. Unter https://de.wordpress.org/plugins/ kann er aus mehr als 50.000 Plugins auswählen, welches er hinzufügt. Auf der Verwaltungsseite des Blogs, im “Dashboard”, aktiviert und konfiguriert er das Plugin. Zu der Beitragsvorlage fügt er die Widgets, das sind die Teile, die der Leser des Blogs sieht, an die gewünschten Positionen.

So wollte ich das auch mit dem Poor Man Push machen.

Das klang nach richtiger Arbeit. Um das nebenher zu erledigen, brauchte ich Erfolgserlebnisse. Bei Erreichen eines Zwischenschritts, konnte ich feiern und die Arbeit ruhen lassen, da ich nicht immer Zeit hatte.

Der Plan hatte zunächst drei Punkte:

  1. Widget für den Button An- und Abmelden
    Das klang einfach. Ich würde hier Javascript in WordPress einbauen lernen.
  2. Tabelle in der WordPress Datenbank, Funktionen zum Eintragen und Listen im Admin Panel.
    Der Datenbank Viewer sollte mir die richtigen Ergebnisse anzeigen. Ich könnte einfach die Datenbank zu den WordPresstabellen stellen und gut wäre.
  3. Verschicken der Pushnachrichten aus dem Admin Panel
    Hier wollte ich ein Kommandodatei online erzeugen, die auf dem Mac oder einem anderen Gerät mit Kommandozeile heruntergeladen und dort ausgeführt wird.

 

Ich fing mit einem einfachen Tutorial für Widgets und für Plugins an. Der erste Erfolg kam zu schnell, so daß ich vom Weg abkam.  „Poor Man Push – WordPress Plugin“ weiterlesen

Poor Man Push III – Python fügt alles zusammen

Die push Nachrichten verschickt der arme Mann mit einem kleinen Programm auf seinem Rechner. Als Betreiber eines kleinen Blogs freut er sich über eine dreistellige Zahl von Lesern, die mit einer push Nachricht auf neue Blogbeiträge hingewiesen werden wollen. Mit einem kleinen Pythonskript kann er push Nachrichten verschicken, die seine Leser informieren, dass ein neuer Bericht erschienen ist. Er kann sicher sein, dass keine weiteren Daten seiner Leser abgegriffen werden, wie ich das schon beschrieben habe.

An dieser Stelle beschreibe ich dieses Python Skript und wie aus dem letzten Teil sich das Ganze wieder zusammenfügt. Bisher hatte ich nur Front- und Backend getrennt betrachtet. Wenn alles zusammenkommt, hakt es an manchen Stellen noch ein wenig. Das war bisher bei jedem Projekt so.

„Poor Man Push III – Python fügt alles zusammen“ weiterlesen

Poor Man Push II – php Backend mit REST

Nach dem Frontend beschreibe ich hier das Backend zur Speicherung der Abonnements von Push Nachrichten. Ich implementierte es nach dem REST Paradigma. Das Javascript schreibt die Abonnementdaten, die es vom Browser bekommt, per POST in die Ressource pmp.gawehns.de/subscription. Der Webserver speichert diese Daten in einer Datenbanktabelle.

Für den Versand der Push Nachrichten greift ein Programm auf meinem Mac per GET auf pmp.gawehns.de/subscription zu. Der Webserver fragt alle Daten ab und liefert die Abonnementdaten zurück. Das Programm verschlüsselt die Push Nachricht mit dem privaten Schlüssel und schickt diese an den Pushserver. Die Browser mit Abonnement fordern diese Nachrichten dann an. Falls ein Versand fehlschlägt, löscht das Programm den Eintrag per DELETE aus der Ressource pmp.gawehns.de/subscription.

So geht eine Implementierung nach „REST Paradigma“.

  1. Brauche ich dafür ein Framework?
  2. Was ist eigentlich das revolutionäre an diesem doch recht offensichtlichen Ansatz?

„Poor Man Push II – php Backend mit REST“ weiterlesen

Poor Man Push I – das Frontend

Wie mache ich Push Nachrichten ohne eigenen Webserver? Wenn ich den hätte, könnte ich einfach die Libs verwenden und schon kann ich meine Leser per Push über neue Artikel informieren. Ich bin so arm, daß ich meine Webpräsenz bei one.com miete. Damit verfüge ich nur über das php, das alle anderen Mieter auch haben.

Bei WordPress gibt es Plugins, die ich einbauen könnte. Aber die kostenlosen Plugins sammeln Daten per Cookies und machen so ihr Geschäft. In jedem Fall wird das Javascript per importscript(‘xyz’) geladen. Damit kontrolliert ein anderer, was auf meinen Seiten passiert. In dem Beitrag über die Push Trojaner habe ich untersucht, was damit alles möglich ist. Kann das ein normaler Blogger verstehen, was bei diesen Plugins genau passiert? Immerhin muss er das in seiner Datenschutzseite beschreiben.

Das geht auch einfacher:

  1. Minimales Javascript zum Einbetten in Webseiten
  2. Anmeldungen in die Datenbank auf dem Server
  3. Skript zum Versenden der Push Nachrichten auf meinem Mac

Das Frontend ist so klein, dass ich an dieser Stelle auch ein wenig auf Besonderheiten von Javascript aus Sicht eines Programmierers mit C/Pascal/C++ Background eingehen kann. „Poor Man Push I – das Frontend“ weiterlesen

push client als Trojaner

Obwohl der Client bei der Registrierung angab, alle Push Nachrichten dem Anwender anzuzeigen, braucht er das gar nicht zu machen! Es gibt, zumindest beim Chrome Browser, keine Instanz, die die Einhaltung dieses Versprechens prüft. Das liest sich harmlos. Was soll passieren, wenn der service worker eine Nachricht unterschlägt?

Ich baute das einfache Beispiel unter https://www.gawehns.de/pwa aus. Nun kann ich per Push Nachrichten Befehle senden.

„push client als Trojaner“ weiterlesen

push Nachrichten und ihre Verschlüsselung

Die Service Worker können auch Nachrichten entgegennehmen, wenn die zugehörige Webseite gar nicht offen ist. Das wollte ich als Nächstes ausprobieren. Der Anfang deutete schon an, dass das nicht die ganz einfache Sache war.

Zunächst wollte ich die Notification Funktion einbauen. Damit kann eine Webseite Nachrichten außerhalb des Browsers anzeigen. Anstelle eines Alerts wird eine Nachricht angezeigt. Für den Anfang schien das ein allererster Schritt, der dann Mut macht weiter zu gehen.

Auf dem localhost tippte ich die Javascript Befehle in das index.html. Nach Speichern und Laden staunte ich nicht schlecht über die Weigerung des Browsers. Er ignorierte die Befehle. Ich sah keine “Die Webseite möchten Ihnen Nachrichten schicken” Mitteilung.

Sollte hier https erforderlich sein? Das sollte wohl doch so schwer nicht sein. Die beim Stackexchange gefundene Anleitung las sich gut. Ich brauchte Zertifikate, damit eine sichere Verbindung aufgebaut werden kann. Das konnte ich alles mit copy&paste erzeugen lassen. Mein Apache ließ sich auch um die nötigen Plugins erweitern, aber Chrome, mein Browser, prüfte die Zertifikate und lehnte sie ab. Sie seien nicht sicher genug sagte er.

Das traf mich dann doch sehr. Vielleicht lag es gar nicht an das https? Geschwind probierte ich die Befehle direkt auf https://www.gawehns.de/pwa aus. Ich wurde gefragt, ob die gawehns.de mir Neuigkeiten schicken durfte. Ich war erleichtert.

Schnell baute ich eine Hallo Welt Anzeige ein und wunderte mich, dass diese nicht zu sehen war. Im Document Root war die richtige Version, den Browsercache hatte ich geleert, aber trotzdem war im Browser die alte Anzeige. Die http Variante zeigte die geänderte Version. Bei https war die alte. Was tun?

Ich chattete mit Julia vom one.com Support. Sie sah bei http und https die gleiche Version. Ihre Frage, ob ich den Browsercache geleert hätte, nervte. Dann aber wies sie mich auf den “Varnish Cache” hin. Ich sollte diesen ausschalten. So lernte ich, dass der Server noch einen Cache hat, in dem auch statische Daten gecacht werden. Ob das so sinnvoll ist?

Ich las den Hinweis, setze ihn um und freute mich über wenigstens diesen Erfolg. Dann machte ich mit meinen Erkundungen bzgl. der Notifications weiter. Ich lernte so einiges über Kryptographie, Schlüssel und Libs, die man dann einbauen muss, wenn man das kann.

„push Nachrichten und ihre Verschlüsselung“ weiterlesen

Wann laufen die service worker in meinem Browser?

Ich wollte etwas über progressive web apps mit service workern schreiben. Diese service workern stellen Webseiten auch offline zur Verfügung. Seit April 2018 macht hier der MacOS Safari mit. Sie arbeiten im Verborgenen. Nur per Debugger können Sie sie sehen. Im Chrome Browser erreichen Sie den Debugger über das Menü “more Tools/developer tools”. Wenn Sie im Tab application den Eintrag “service worker from other domains” aufklappen, Sie die Domains, die bei einem Besuch ihre service woker installiert haben. Ich staunte nicht schlecht. Es gab schon eine Menge an Webseiten, die so etwas gemacht haben.

Gefragt werden Sie nicht, ob Sie diese in Ihrem Browser haben wollen. Bei Cookies ist das anders. Obwohl Cookies nur Datenpakete sind und nur durch Software, die auf anderen System läuft, gefährlich werden können. Aber diese Javascript Sachen sind Programme und könnten durchaus auch schädlich sein. In jedem Fall sollte diese Software nur ausgeführt werden, wenn auch die zugehörige Webseite wird. Falls dann ein unbedarfter Softwerker Mist programmiert hat, leiden eben die Webseiten des zugehörigen Domains.

Ich wollte sicher gehen und ein einfaches Lehrbuchbeispiel um log Einträge erweitern, damit jeder den Javascript Code bei der Ausführung beobachten kann.

„Wann laufen die service worker in meinem Browser?“ weiterlesen