ubergeek.de: Artikel mit Stichworten

Raspberry Pi und (ein wenig) Java im Produktionsumfeld

2021-03-14T21:53:00+01:00

Noch im vergangenen Jahr hat sich für uns eine tolle Einsatzmöglichkeit für den Raspberry Pi im Produktionsumfeld ergeben. Das war nicht nur für mich eine schöne Möglichkeit, meine Java-Kenntnisse mal wieder aufzufrischen, sondern auch eine Gelegenheit, in Sachen Hardware etwas Neues auszuprobieren.

Die Anforderungen waren relativ überschaubar: Bisher wurden Windows-Terminals, auf denen eigentlich arbeitsplatzspezifische Anwendungen liefen, »missbraucht«, um mit Hilfe einer kleinen C#-Anwendung per USB angeschlossene RFID-Scanner anzusteuern, um auf das »Vorhalten« von passenden Karten zu reagieren. (Der Kenner wird sich schon denken können, worum es dabei ging.) In der Praxis umständlich wurde es, als nicht nur deutliches Feedback der Anwendung (Lautsprecher sind dort nicht verbaut), sondern zusätzlich einfache Interaktionsmöglichkeiten gefordert waren. Zur Erinnerung: im Normalfall liefen auf den Terminals ganz andere Anwendungen.

Der Raspberry Pi war die optimale Lösung für dieses Problem: er bietet mit Linux nicht nur ein ausgewachsenes Betriebssystem auf kleinstem Raum, er ist günstig in der Anschaffung und es gibt vom Hersteller ein passendes günstiges Touchscreen-Gehäuse in optimaler Größe (7 Zoll), das sich für die Wand-Montage eignet. Einen vergleichsweise lauten Buzzer bekommt man auch im Gehäuse untergebracht, über die GPIO-Pins lässt sich dieser ansteuern. Die Auslagerung auf ein eigenes Gerät und einen eigenen Screen verhindert, dass sich verschiedene Anwendungen und Anforderungen »in die Quere kommen«. Ganz nebenbei werden die regulären Arbeitsplatz-Terminals auch in der Produktion mindestens zum Wochenende gerne ausgeschaltet, was wir bei diesem Anforderungsprofil auch nicht gebrauchen konnten.

Entschieden haben wir uns, vor allem aus Gründen der möglichst kurzen Entwicklungszeit, für eine Java-Anwendung. Einziges Problem dabei: Außer mir hatte in meinem Team bisher niemand für den Linux-Desktop entwickelt, erst recht nicht in Java. Großer Vorteil meines tollen Teams: niemand hatte Angst davor. Ich habe das Grundgerüst und das User Interface entwickelt, um Datenbank-Schicht und anderes haben sich die Kollegen gekümmert. Nebenbei: Um Verbindungsproblemen mit dem zentralen Datenbank-Server zu begegnen, kommt hier eine eingebettete SQLite-Datenbank als Puffer zum Einsatz, so dass auch bei Netzwerk-Problemen keine Aktionen verloren gehen.

Für mich bleibt festzuhalten: Ich bin nicht nur erstaunlich schnell wieder »drin« gewesen in Java, sondern habe festgestellt, dass ich die Sprache selbst und auch die Tools darum herum immer noch toll finde. Das Dokumentationswerkzeug Javadoc war seinerzeit eine fantastische Idee und erledigt seinen Job nach wie vor hervorragend (sehr schade, dass es im PHP-Umfeld nichts gibt, das daran heranreicht oder wenigstens zuverlässig läuft und anständigen Output generiert), die Paketierung als Java-Archiv inkl. Bündelung von Ressourcen und Drittbibliotheken ist schnell und einfach erledigt. Und für unser kleines Projekt haben wir das Build-System Ant verwendet, das zwar nicht Bestandteil des JDK ist, aber für ein Projekt dieser Größenordnung genau das richtige ist. Leider wurde anscheinend über Jahrzehnte weder von Sun noch von Oracle nennenswert Zeit investiert, um ein modernes Look and Feel auch für Linux zu implementieren (Windows und MacOS sind diesbezüglich kein Problem), aber mit dem FlatLAF gibt es eine Open-Source-Implementierung, die einen sehr ordentlichen Job macht.

Alternativ wäre übrigens eine Umsetzung mit Python und Qt denkbar gewesen, was sicherlich (für mich) auch reizvoll gewesen wäre, aber aufgrund des Zeitdrucks und des immerhin vorhandenen Basis-Know-Hows war Java zumindest in diesem Moment die bessere Wahl. (Python übrigens ist ja auch so ein Phänomen: Von vielen als »junge« Programmiersprache wahrgenommen, erlebt sie seit einigen Jahren einen wahren Boom, was mich bisweilen etwas wundert. Ich habe mich tatsächlich schon zu meinen Amiga-Zeiten (oberflächlich) mit Python beschäftigt; jung ist sie nun wirklich nicht mehr. Aber nicht die Sprache ist das größte Problem von Python, sondern das große Thema »Abhängikeiten und Deployment«, aber das wäre mal einen separaten Beitrag wert.)

Generell bestehen in unserem Team keine Berührungsängste vor Technologien, die wir bisher nicht eingesetzt haben. Das ist ein Vorteil, den man nicht überall hat, und der uns flexibel macht. Und wer weiß? Vielleicht werden wir auf der gewählten Basis noch weitere Anwendungen umsetzen, vielleicht wird das nächste Projekt aber doch in Python realisiert? Beide Ansätze würden uns auch erlauben, plattformübergreifende Anwendungen zu entwickeln.

Darüber hinaus war dieses Projekt auch eine schöne Aufgabe für unseren Auszubildenden in der Fachrichtung Systemintegration (für den ich nicht persönlich zuständig bin), der sich um Hardware-Zusammenbau und Betriebssystem-Einrichtung inkl. Fernwartungsmöglichkeiten kümmern konnte. Win-Win, würde ich sagen.

NanoCM ist Open Source

2021-03-14T20:46:00+01:00

Als ich meine Website neu aufgesetzt habe, hätte ich selbstverständlich auch einfach zu Wordpress greifen können – aber als Entwickler konnte ich ja doch wieder nicht anders als ein System nach meinen Wünschen und Vorstellungen selbst zu erstellen. Das Ergebnis habe ich in der Zwischenzeit als unter Open-Source-Lizenz veröffentlicht.

Ein bisschen Inhaltsbearbeitung, User-Login bzw. Session-Management und das zeitgesteuerte Veröffentlichen von Inhalten – das stellt doch niemanden vor besondere Herausforderungen. Wenn man das »so nebenbei« in seiner Freizeit macht, kann es aber dauern 😬 Mittlerweile sind bereits mehr als 60.000 Zeilen Code zusammengekommen (davon mehr als 40% PHP, fast 30% JavaScript, den Rest bilden HTML-, (S)CSS und ein paar sonstige Dateien), obwohl ich noch lange nicht alles umgesetzt habe, was ich mir vorgenommen habe.

Immerhin: die eine oder andere »Sonderfunktion«, die in anderen Systemen nicht gerade zum Standard-Funktionsumfang gehören, habe ich umgesetzt. So lassen sich Inhalte als ePub exportieren, wobei eingebundene Inhalte wie Bilder automatisch eingebettet werden,

Außerdem wird Wert gelegt auf den Datenschutz: Von externen Websites (Google, Youtube, Twitter und Content Distribution Networks [CDN]) werden keinerlei Inhalte direkt eingebunden. Es können zwar Inhalte von Youtube und Twitter dargestellt werden, dabei fungiert jedoch stets NanoCM als Proxy, der die Inhalte entsprechend abfragt und aufbereitet; der User Agent des Anwenders selbst greift niemals direkt auf die externen Sites zu. Ohne vorherige Zustimmung wird nicht ein einziges Cookie gesetzt, nicht einmal ein Session-Cookie. (Das hat den Nebeneffekt, dass bei jedem Seitenabruf ein Cookie-Hinweis erscheint, solange nicht der Nutzung von Cookies zugestimmt wird. Theoretisch könnte man sowohl eine Cookie-Ablehnung und auch die Session-ID per Get-Parameter von Seitenabruf zu Seitenabruf durchschleifen, aber das ist aus mehreren Gründen keine gute Idee.)

Eine noch nicht fertiggestellte Medienverwaltung sorgt dafür, dass im Original hochgeladene Bilder automatisch in verschiedensten (konfigurierbaren) Formaten ausgeliefert werden können, d. h. Bilder werden automatisch skaliert und zugeschnitten; das wird auch genutzt für eine Unterstützung von HiDPI-Bildschirmen.

Ein kleines Wagnis war die von Anfang an stehende Entscheidung, datenbanktechnisch nicht auf ein Server-Client-Modell, sondern mit SQLite auf eine eingebettete Datenbank zu setzen, was eine Zero-Config-Einrichtung ermöglicht.

Das System ist in der Lage, optional anonymisierte Statistiken inklusive Geo-Informationen zu führen. Was mir hier noch fehlt: eine tolle Visualisierung über interaktive SVG-Grafiken, aber darum kümmere ich mich auch noch irgendwann 😉

Es gibt mit dem schönen Emoji-Soft-Keyboard auch ein Feature, das sich fast überholt hat. Unter MacOS schon seit langer Zeit vorhanden, gibt es auch unter Windows 10 seit einiger Zeit eine entsprechende systemweite Funktion (wer es noch nicht weiß: dieses Keyboard wird mit Win+. geöffnet) – unter Linux allerdings mag das durchaus noch nützlich sein, denn hier scheint es eine solche Funktion (noch) nicht zu geben. Falls mir jemand etwas anderes berichten kann: gerne her damit! Auf der anderen Seite: unter Windows gibt es ja bis heute keine simplen Shortcuts, um typografisch korrekte Anführungszeichen einzufügen. Auch für solche Zeichen gibt es in NanoCM ein Soft-Keyboard.

Wie auch immer: Den Quelltext habe ich irgendwann im vergangenen Jahr auf Github veröffentlicht. Wer Lust hast, kann also gerne einen Blick in die Quellen werfen oder sich sogar an der Weiterentwicklung beteiligen. Es kann auch jeder einen Fork anlegen und »sein eigenes Ding« daraus machen. Ich habe mich für die GPL 2 entschieden, die einem praktisch alle Freiheiten einräumt, solange alle abgeleiteten Werke ebenfalls unter dieser Lizenz veröffentlicht werden.

Zu den offenen Baustellen gehört übrigens, dass ich zunächst Dokumentation und Kommentare auf Deutsch geschrieben habe. Das war vermutlich nicht die klügste Entscheidung. Jüngere Quelltext-Teile sind bereits auf Englisch kommentiert; der Rest der Anwendung wird nach und nach umgestellt. Wenn sich jemand an der Weiterentwicklung beteiligen möchte, wäre schon »nur« die Übersetzung ein wichtiger, ein wertvoller Beitrag.

Das Projekt läuft unter dem Namen NanoCM, wobei ich mich noch nicht für eine bestimmte Schreibweise (NanoCM, nano|cm, nanoCM …) entschieden habe. Ich wünsche allen Interessierten viel Spaß beim Blick in den Quelltext und bin offen für konstruktive Verbesserungsvorschläge und Mitarbeit :)