Schlagwort: Cordova

Schulungsjahr 2022 beendet

Gestern habe ich meinen letzten Schulungstag 2022 (falls nicht noch ganz kurzfristig was aufläuft) gehalten (zu Python) und eben habe ich die letzte Rechnung für eine Schulung erstellt und versendet. Damit schließe ich das Schulungsjahr 2022 ab. Allerdings kommt vor Weihnachten noch eine Woche mit Videoaufnahmen bei LinkedIn Learning in Graz, worauf ich mich richtig freue.

Einführung in JavaFX/OpenJFX

Wenn ich die Schulungen dieses Jahr durchgehe, kamen wieder eine ganze Reihe an Themen vor. Wie üblich mit einigen Schwerpunkten, die sich im Vergleich zu den Jahren zuvor aber teils verschoben haben. Andere Themen sind komplett weggebrochen oder ich habe sie nicht annehmen können und ich muss mir überlegen, ob ich die weiter im Schulungsprogramm behalte. Auch wenn ich sie persönlich meist immer noch interessant finde (etwa F#, GWT oder Perl) bzw. unabhängig von direkten Schulungen oft verwende (etwa Eclipse oder alles rund um mein Lieblingsbetriebssystem Linux, wofür ich aber keine aktuelles Schulungsagenda mehr ausgearbeitet habe – zu nahezu allen anderen Schulungthemen habe ich ja eigene Bücher und Schulungsunterlagen und/oder Videotraining bei LiL erstellt).

„Schulungsjahr 2022 beendet“ weiterlesen

Ob das wirklich nötig war?

Ich bin am Zweifeln, ob es wirklich notwendig war, mir ein neues SmartPhone zuzulegen. Denn in der Mittagspause kam ein solches an und eigentlich benötige ich keine neuen Features, die in den letzten Jahren im Umfeld von SmartPhones aufkamen. Aber mein aktuelles Honor View hat seit geraumer Zeit einen Riss im Display, der sich komplett über den zentralen Bereich des Displays erstreckt sowie sukzessive größer wird und sich mehr und mehr verästelt. Dazu hat sich die letzten Tage rechts oben ein weiterer kleiner Riss gebildet. Ich fürchte, dass das Gerät irgendwann ausfällt und das ist ein echtes Problem. Denn die elende 2-Wege-Authentifizierung nimmt immer mehr zu und ich komme damit ohne ein SmartPhone nicht mehr an diverse Dienste wie GitHub, SharePoint etc. Dazu muss ich auch beim Onlinebanking, ebay, Paypal etc. Anmeldungen mit dem SmartPhone bestätigen. Ohne die dazu installierten Apps bzw. mobile Erreichbarkeit wäre es einfach elend umständlich. Ich habe wegen des drohenden Ausfalls von dem Honor View die letzten Monate ein ganz einfaches Nokia-SmartPhone als Notfall-Gerät aufgebaut,. Das habe ich vor einigen Jahren geschenkt bekommen und bisher nur als Testgerät für die App-Entwicklung mit Cordova verwendet – insbesondere im Rahmen meiner Vorlesgungen zur Entwicklung von plattformneutralen Apps an der TH Bingen. Allerdings ist das SmartPhone von einem meiner Söhne mit einem Riss im Display (Zufall) so gut wie unbedienbar geworden und ich habe ihm das Nokia abgetreten. Damit fehlt mir aber ein Backup-Gerät, denn mein altes Galaxy S4 ist zwar noch im W-LAN im Einsatz (Bestätigung von Online-Authentifizierungen, Infrarot-Fernbedienung etc.), aber durch die uralte Software nicht sicher außerhalb vom W-LAN einzusetzen und selbst mir etwas zu schwachbrüstig.

Ich beobachte deshalb schon ein paar Monate einige SmartPhones und nachdem mein Favorit, der sich nach vielen Überlegungen und Testberichten herauskristalisiert hat, am Montag in einer Blitzaktion bei einem Händler signifikant unter den Preisen angeboten wurde, die ich die letzten Monate gesehen hatte, habe ich zugeschlagen.

Es ist ein Samsung XCover 5 Pro Enterprise geworden. Das ist ein Outdoor-SmartPhone bzw. ein Gerät, das explizit für den Einsatz auf Baustellen und im dreckigen Umfeld konzipiert ist. Da ich zu einigen „rustikalen“ Hobbies wie Gleitschirmfliegen oder Montainbiken neige, macht bei mir das SmartPhone schon Einiges mit. Wobei der Riss im Display nicht bei den Aktivitäten aufgetreten ist, wenn ich mich nicht täusche.

Anyway – mir war wichtig, dass das neue SmartPhone robuster und damit nachhaltig wird. Ebenso waren Dinge wie die Navigation inklusive sehr gutem GPS- und Telefonempfang sowie eine lange Laufzeit wichtig. Mein erster Eindruck von dem XCover ist, dass es recht „klobig“ daherkommt. Das gefällt mir gut, denn ich kann diese ultradünnen „Pussy“-SmartPhones nicht leiden. Wobei es im Vergleich zu den üblichen Outdoor-SmartPhones (neudeutsch werden die „Rugged-Phone“ genannt) immer noch fast grazil ist. Es sieht ein bisschen so aus, wie die SmartPhones vor 5 – 10 Jahren ausgesehen haben. Sehr angenehm.

Ich habe mich für das Samsung entschieden, weil ich mit dem S2 und dem S4 früher schon gute Erfahrungen gemacht hatte und Samsung der einzige große Hersteller ist, der den Markt der Rugged-Phones überhaupt bedient. Der Rest sind irgendwelche China-Firmen oder Nischenanbieter. Außer Gigaset ist für mich keiner der anderen Anbieter wirklich infrage gekommen, zumal das alte SmartPhone meines Sohns auch ein Outdoor-Gerät von einem dieser China-Anbieter war – von wegen robust.

Wie sich das XCover in der Praxis bewährt, kann ich noch nichts sagen, denn ich werde es erst die nächsten Tage sukzessive einrichten, vom Honor umsteigen und dieses dann als Backup-Gerät aufbewahren (in der Hoffnung, dass das Display nicht weiter kaputtgeht, wenn das Gerät weitgehend in Ruhe gelassen wird). Was aber an Highlights das XCover schon auszeichnet, ist das:

  • Wechselbarer Akku. Unglaublich, dass das andere SmartPhones kaum noch anbieten.
  • Klinkenbuchse. Auch das fehlt mittlerweile bei diversen SmartPhones
  • Diverse Outdoorfeatures.
  • Bis zu 1GByte große SD-Karte wird unterstützt

Vor Ort – oder doch lieber remote?

Aktuell bereite ich gerade für nächste Woche eine Cobol-Schulung vor. Auch wenn ich die letzten Wochen Vor-Ort-Schulungen gehalten habe – die Sache wird wieder remote laufen. Ebenso wie meine Videoaufnahmen für LinkedIn Learning in der übernächsten Woche. Für mich stellt sich mittlerweile die Frage, ob und wann meine Arbeit wieder ganz oder zumindest überwiegend auf „Präsenz“ umgestellt wird? Denn ich habe für die kommenden Wochen und Monate wieder Schulungsanfragen, die zwingend Vor-Ort laufen sollen. Zum Teil habe ich sie schon zugesagt. Aber Corona, die aktuell katastrophalen Rahmenbedingungen beim Fliegen (heute wird zusätzlich zu den total chaotischen Flughafenbedingungen durch den Urlaubswahnsinn sogar noch in FFM gestreikt), die permanent unzuverlässige Bahn sowie die explodierenden Benzinpreise bzw. allgemeinen Reisekosten lassen mich meine Zusagen bereuen und  überlegen, ob ich nicht konsequent auf „Remote“ bestehe? Vielleicht mit Ausnahme von Schulungen hier in der Umgebung, die ich u.U. sogar mit dem Rad anfahren kann (wie die letzten Wochen) und Videoaufnahmen bei LinkedIn Learning in Graz, denn ich will da unbedingt mal wieder hin. Aber ansonsten?

Ich muss Ende September nach Hamburg. Wie soll ich denn da hinkommen?

  • Inlandsflug? Theoretisch billig, gut und schnell. In der Praxis eine Umweltsauerei und besagtes Chaos an den Flughäfen lassen das im Grunde als Option nicht zu.
  • Bahn? Das klappt bei mir einfach nie. Mein Sohn hat letzte Woche wieder 5,5 Stunden für eine Strecke gebraucht, die nach Plan 90 Minuten dauern sollte, ich habe mein letztes Ziel vor 3 Wochen (Marburg) gar nicht erreicht, weil es einfach in Giessen nicht mehr weiterging, Anschlusszüge erreiche ich sowieso fast nie und ich kann nicht mehr zählen, wie oft meine Fernzüge unterwegs stehengeblieben sind.
  • Auto? Bei den Kosten, den Staus durch die vielen Baustellen und auch wegen der Umwelt wirklich nicht gut. Nach HH sind es weit über 500 Km und da brauche ich ja 6 – 7 Stunden einfach.

Ich liebe HH und das war mit ein Grund, warum ich diese Maßnahme Vor-Ort zugesagt habe, aber ich hoffe dennoch, dass Corona die Sache auch für den Kunden auf Remote zwingt. Doch die Kunden wollen eben wieder verstärkt von Remote weg. Gestern habe ich von einem Schulungspartner, für den ich die letzten Wochen UML und Java bei Fachinformatikern geschult habe, einen Hilferuf bekommen. Denn rein zufällig soll er in einigen Tagen für einen Teil dieser Gruppe eine Cobol-Schulung halten. Mein Schulungspartner ist nun Cobol-Spezialist und macht das seit gut 35 Jahren – früher Host und mittlerweile unter Linux. Er ist also in Cobol fitter wie ich und der Hilferuf ging nicht um konkrete Cobol-Fragen und auch nicht darum, ob ich das übernehmen könne.

Es ging darum, dass beim Kunden neue Corona-Regeln in Kraft getreten sind. Die Gruppe, die Cobol in den Räumlichkeiten des Kunden (einer Bank) lernen soll, besteht aus 4 Fachinformatiker-Azubis und dem Trainer (besagtem Schulungspartner). Wenn in der Schulungszeit auch nur ein Corona-Fall bei einem der 5 Leute auftritt, besteht für die gesamte Gruppe ein Betretungsverbot der Räumlichkeiten des Kunden für die kommenden 5 Tage. Nun hatte ich die Azubis ja über die letzten 5 Wochen immer 2 Tage die Woche in einer Berufsschule unterrichtet und ständig hat jemand wegen Corona gefehlt. Ich selbst habe am letzten Tag auch ein Andenken mitgenommen – trotzt Mehrfachimpfung/Boostern. Was mir nur zufällig aufgefallen war, denn meine Symptome waren so, dass ich normalerweise nie auf die Idee gekommen wäre, mich zu testen oder gar krankzufeiern. Rein die Sensibilität aufgrund des Corona-Hotspots Schule hat dazu geführt, dass mir die Möglichkeit überhaupt in den Sinn gekommen ist. Aber sei es drum – auch wenn die aktuelle Corona-Variante wohl bei 99,9% der Infizierten entweder nicht bemerkt wird oder nicht an die Auswirkungen eines Sommerschnupfens heranreicht – wenn so strikte Zugangsregeln bzw. Isolationsregeln etc. gelten – wie soll man dann noch Maßnahmen vor Ort planen können?

In dem Fall meines Schulungspartners ist die Planung einfach – sie werden vor Ort beginnen (erzwungen vom Kunden) und dann ist es nur die Frage, an welchen Tag abgebrochen wird. Der einzige Grund, warum das im besten Fall durchgehen kann ist, dass die Azubis Ihre Corona-Infektion bei mir in der Schulung bereits hatten und gerade immun sind. Bis zur nächsten Variante des Virus. Aber wie gesagt – vermutlich wird die Schulung abgebrochen und dann muss halt auf remote umgestellt werden. Theoretisch. Denn im Fall von Cobol wird das auf dem Host verwendet oder unter Linux, die Azubis müssen aber im Remote-Fall Notebooks der Firma verwenden, unter denen dann ein Host-Zugriff oder Linux und die verwendete Cobol-Distribution nicht laufen. Der Kunde lässt also Remote quasi technisch scheitert, verbietet aber Vor-Ort mit hoher Wahrscheinlichkeit. Quadratur des Kreises.

Um kurz abzuschweifen – ich habe OpenCobolIDE, MinGW und ein Docker-Image für Cobol als Lösung vorgeschlagen, um Cobol dann unter Windows bei den Azubis zum Laufen zu bringen und gerade die Sache mit dem Docker-Image gestern erstmal selbst getestet, um das nächste Woche selbst neu in meine Schulung zu integrieren. Geht wunderbar und ist quasi die Verbindung der Vergangenheit (Cobol) mit der Gegenwart (Docker). Genau da sehe ich auch in meiner sehr Laienhaften Betrachtungsweise den Hauptsinn von Docker, denn so nutze ich Docker ja auch für Cordova bei meinen Vorlesungen an der TH Bingen.

Aber um die Sache zum Abschluss zu bringen – ich habe die letzten Wochen Kundenwünschen nach Vor-Ort-Maßnahmen wieder zugestimmt, werde das aber beenden. Solange ich es mir leisten kann, werde ich wieder auf reines Remote zurückgehen. Die fehlende Planungssicherheit, die aktuell unmöglichen Reiseumstände und auch, dass mich Corona trotz Boostern und extremer Vorsicht erwischt hat (auch wenn ich keine wirklichen Symptome mitgenommen habe), geben mir keine andere Wahl. Freiberufliche Arbeit muss extrem flexibel sein und richtig planen kann man nie – aber so extreme Unsicherheit ist mir zu viel. Zumal auch das gesamte Risiko bei mir liegt. Wenn ich Corona bekomme, muss ich die Maßnahme abbrechen. Entweder weil es der Kunde oder die Politik immer noch 5 Tage Isolation fordert – auch ohne Symptome (da ist Deutschland leider noch nicht so weit wie etwa Österreich, wo diese Maßnahme endlich abgeschafft wurde). Remote arbeite ich einfach weiter. Oder die Maßnahme wird abgebrochen, weil irgendjemand in der Gruppe Corona hat. Das explodierende Risiko von Reiseproblemen muss ich auch noch tragen. Nein, so geht es einfach nicht, wenn auf der anderen Seite Remote alles einfach und sicher macht.

Ende des Semesters an der TH Bingen

Letzten Donnerstag haben die Studenten meiner Blockveranstaltung zur Entwicklung von plattformneutralen Apps an der TH Bingen ihre Praxisarbeiten vorgestellt. Von den ursprünglich gut 25 – 30 Studenten waren am Ende der Remote-Blockveranstaltung über 6 Tage zu Beginn des Semesters noch so etwa 15 – 20 übrig, von denen etwa ein Duzend dann auch das Projekt abgegeben und in einer Teams-Sitzung vorgestellt haben. Zum Teil haben mich die Apps richtig beeindruckt.

Heute stelle ich noch die Bewertungen ein, schreibe meine Abrechnung und dann ist auch für mich meine Semester an der TH Bingen beendet. Mal sehen, ob ich diese Veranstaltung in den kommenden Semestern noch einmal halte, denn die Basis Cordova fällt so langsam ein bisschen aus der Zeit – auch wenn die verwendeten Webtechnologien und das Cordova-API einwandfrei funktionieren. Aber auch die Fachbereiche an der TH Bingen werden umstrukturiert und Mobile Computing, wo diese Veranstaltung bisher untergebracht war, wird in die „normale“ Informatik eingegliedert. Aber ich würde schon gerne wieder an der Hochschule eine Vorlesung halten – bis auf die extreme Bürokratie und maximal rückständige Verwaltung macht das immer wieder Spass.

Sprung in der Schüssel

Mein SmartPhone hat einen Sprung im Display. Es funktioniert zwar immer noch problemlos, aber das ist auf Bewährung. Es kann jederzeit sein, dass ich das Teil nicht mehr bedienen kann und das wäre ziemlich dumm. Auch wenn ich absolut nicht SmartPhone-süchtig bin, habe auch ich natürlich sehr viele Dinge mittlerweile auf dem SmartPhone, die wichtig sind. Darüber muss ich mir keine Illusionen machen.

Nun musste ich eben erst einmal nachsehen, wann ich mir das Honor View 10 geholt hatte. Es ist nicht so alt, wie ich gedacht habe. Erst von Anfang Januar 2020. Das Gerät war zwar zu dem damaligen Zeitpunkt schon ein Auslaufmodell, aber ich stelle ja die Sinnhaftigkeit der Entwicklung bei SmartPhones die letzten 10 Jahre massiv infrage. Was klar ist, denn bereits vor 10 – 15 Jahren hatten die SmartPhones alle Features, die man wirklich braucht. Nachfolgende Geräte hatten nur von allem „mehr“ (Pixel, RAM, Chips, etc.) oder „weniger“ (Dicke, Gewicht, …) oder waren „schneller“. Es gab die letzten Jahre nichts wirklich Notwendiges oder Neues. Ich bin also definitiv kein Typ, der alle 2 – 3 Jahre ein neues SmartPhone braucht bzw. haben will.

Aber der Riss im Display macht eine Vorbereitung auf einen wahrscheinlichen Abgang von den Honor notwendig. Auf der einen Seite liebäugle ich schon geraume Zeit mit einem Outdoor-Handy. Denn die haben dann doch ein paar Features, die für mich wirklich interessant sind, da ich ja sehr oft in der freien Natur aktiv bin. Vom Montainbiken bis hin zum Gleitschirmfliegen. Ein robustes Gerät mit langer Laufzeit bzw. wirklich viel Akku, gutem GPS, guter Netzwerkverbindung, vernünftigen Outdoor-Sensoren und einem Display, was im grellen Sonnenlicht gut abzulesen und auch mit Handschuhen zu bedienen ist, wäre schon nett.

Andererseits will ich eben dem Konsumterror nicht nachgeben und aus Nachhaltigkeitsgründen Dinge solange wie möglich verwenden. Das gilt auch für technische Geräte – oder vielleicht da sogar besonders. Solange das Honor eben noch funktioniert, will ich nichts Neues anschaffen. Zumal ich noch ein Nokia 3.2 rumliegen habe. Das ist ein ganz einfaches SmartPhone, was schon beim Erscheinen nicht einmal Mittelklassenniveau dargestellt hat, das aber im Grunde neuwertig ist, da ich es ausschließlich als Testsystem bei meinen Vorlesungen zur Entwicklung von plattformneutralen Apps mit Cordova an der TH Bingen verwende.

Ich bereite mich daher aktuell mit zwei Strategien auf einen endgültigen Ausfall von dem Honor vor.

  1. Ich kopiere alle wichtigen Daten vom internen Speicher als Backup auf mein NAS.
  2. Ich richte das Nokia als eine Art Klon des Honors ein und installiere dort alle wichtigen Apps, die ich auf dem Honor habe und konfiguriere alle Accounts so, dass ich bei einem Ausfall nur die SIM-Karte aus dem Honor in das Nokia wechseln muss.

Damit sollte ich erst einmal vorbereitet sein und vielleicht hält das Honor ja doch weiter durch.

Edit: Die Strategien zeigen Schwächen :-(. Das Nokia 3.2 hat nur 16 GByte internen Speicher, von dem bereits gut 10 GByte von Android weggenommen werden. Selbst wenn ich weder Musik noch Bilder oder Videos darauf speichere, bleibt nicht gut Platz für alle Apps, die ich im Grunde gerne installiert hätte. Ich muss mich also auf die wichtigsten Apps beschränken und das ist suboptimal. Und das Backup der Bilder und Daten aus dem internen Speicher des Nokia auf das NAS dauert nach den Schätzungen in Windows 17 Stunden. Wow. Da will mich wohl wirklich jemand zu einem neuen SmartPhone verleiten.

 

OpenStreetMap statt Google oder Bing

Im Rahmen meiner Vorlesung zur Entwicklung von plattformneutralen Apps mit Cordova an der TH Bingen ist mir aufgefallen, dass die Verwendung des Google Map-APIs nicht mehr so funktioniert hat, wie ich es gewohnt war. Ältere, aber erprobte/getestete Codes haben einen Fehler produziert. Ich stelle den Studenten schon seit ein paar Semestern als eine mögliche Semesterarbeit eine App als Aufgabe, die unter anderem die aktuelle Position in einer Karte zeigen soll. Dabei habe ich bisher Google Maps und als Alternative Bing Maps verwendet. Die jeweiligen APIs ließen sich bisher problemlos verwenden. Nur benötigt man mittlerweile bei neuen Versionen der APIs dafür API-Keys. Die sind zwar kostenfrei zu bekommen (mit ein paar Einschränkungen hinsichtlich der erlaubten Verwendung), aber die Generierung ist dennoch mittlerweile etwas umständlich bzw. ich komme mit den unendlich vielen Details und unübersichtlichen Entwicklerwebseiten einfach nicht klar. Die speziellen Features der neuen Versionen habe ich auch bisher nicht benötigt.

Die Version 2 des Google Maps API hat aber keinen API-Key erfordert und war deshalb sowohl für meine Beispiel-Apps als auch viele Webseiten immer noch eine sehr gute Wahl. Nur das Problem in der Vorlesung beim Verwenden der alten Codes hat mich zu der Info auf den Entwicklerseiten von Google gebracht:

The Maps JavaScript API v2 is no longer available as of May 26, 2021. As a result, your site’s v2 maps will stop working, and will return JavaScript errors. To continue using maps on your site, migrate to the Maps JavaScript API v3. This guide will help you through the process.

Ganz toll – einfach die API-Version eingestellt und die bisherigen Webseiten und Apps sind an die Wand gefahren. Bei Bing Maps war es nicht besser – die alten Codes funktionieren auch nicht mehr.

Oft haben das die Betreiber von Webseiten auch gar nicht bemerkt bisher, denke ich. Gestern war ich auf einer entsprechenden Webseite eines Gleitschirmvereins, wo die Karte nicht mehr funktioniert. Klar – man kann argumentieren, dass Entwickler die Verantwortung haben, die Funktion ihrer Produkte regelmässig zu kontrollieren. Aber das ist m.E. nur die eine Seite der Medaille. Man kann auch argumentieren, dass es eine Art „Bestandschutz“ gibt. Was einmal getestet ist, sollte auf Dauer funktionieren. Da sieht man mal wieder, in welche Abhängigkeiten man sich begibt, wenn man fremde Ressourcen und Leistungen nutzt. Die aktuellen Probleme bei einigen Cloud-Anbietern passen in diese Problematik.

Und me culpa – auch auf einer meiner Seiten hatte ich eine Karte mit dem Google Maps API, die nicht mehr korrekt angezeigt wurde und was ich bisher nicht bemerkt hatte – es hatte sich bisher auch kein Besucher beschwert.

Einer meiner Studenten hatte sich vor einigen Tagen wegen dieser ganzen Umstände mit dem Google Maps bzw. Bing Maps API so geäußert, dass er auf OpenStreetMap umsteigen würde. Fand ich eine gute Idee und deshalb hatte ich schon vor ein paar Tagen damit sowie Mapbox experimentiert. Auch in Verbindung mit einer Django-Webseite, weil ich die nächsten Wochen dazu ein Videotraining bei  LinkedIn Learning einspielen will, wo ich diese Techniken in Beispielen nutzen will.

Aber erst einmal habe ich jetzt die Webseite, die ich betreue, auf OpenStreetMap umgestellt.

Die Seite arbeitet mit Joomla! und da taugt das OSModul ziemlich gut, um auf einfache Weise eine Karte von OpenStreetMap in eine Webseite zu integrieren.

 

April-Scherz?

Am Montag habe ich meine Blockveranstaltung zur Entwicklung von plattformneutralen Apps mit Cordova an der TH Bingen begonnen und eben den ersten Block über 6 Tage beendet. Ich glaube, das war das 1. Mal überhaupt, dass ich 6 Tage am Stück bei einer Veranstaltung unterrichtet habe. Klar habe ich schon Samstags geschult, aber nicht Montag – Samstag bei einer Veranstaltung. Aber ich wollte den Block auf jeden Fall vor der nächsten Woche mit dem offiziellen Semesterbeginn durch haben und konnte erst am Montag dieser Woche anfangen. 

Jetzt folgen noch ein paar Fragestunden über das Semester und am Ende im Juli einer Vorstellung der Semesterarbeit durch die Studis. Alles remote vermutlich. 

Anyway – gestern war der 1. April und heute morgen dachte ich, da wäre ein verspäteter April-Scherz am Laufen oder ich in der falschen Jahreszeit aufgewacht. Selbst in Bodenheim liegt etwas Schnee und am Büro in Eppstein sogar wirklich.

Eigentlich wäre ich heute gerne zum Hammerwerfen nach Niederselters gegangen, aber bei dem Wetter bedauere ich nicht, dass ich heute arbeiten musste. Ich habe per WhatsApp auch Bilder vom Sportplatz da gesehen und da ist noch mehr Schnee.

Cordova-Vorlesung an der TH-Bingen

Seit Montag läuft meine Blockveranstaltung zur Entwicklung von plattformneutralen Apps an der TH Bingen. Remote und zu Beginn als Blockveranstaltung über 6 Tage mit ein paar Fragestunden über das Semester und am Ende im Juli einer Vorstellung der Semesterarbeit durch die Studis. Als Basis verwende ich wieder Cordova – auch wenn dessen „Aktualität“ bzw. Verbreitung etwas angekratzt ist. Aber man kann viel daran lernen und es funktioniert. Der Fokus liegt ja sowieso an den verwendeten Webtechnologien und dem Cordova-API.

Preisexplosion beim Raspi

Ich muss zugeben, dass ich mir lange keine Preise für Hardware angesehen habe. Und schon gar nicht für den Raspberry Pi. Hin und wieder krame ich meinen alten Raspi der Version 1 raus und experimentiere damit rum. Aber die Version 1 ist wirklich so schwach auf der Brust, dass man damit eigentlich nur testen kann, welche Minimalhardware für gewisse Dinge notwendig ist und dabei braucht man viel Zeit und Geduld, bis die Programme starten bzw. fertig sind. Und wirklich nützliche Anwendungen habe ich in dem Bereich wenig gefunden, weil ich keine Hardwaresteuerung programmiere. Einzig die Ausführung von einem Python-Skript zur Spamabwehr ist derzeit eine produktive Anwendung des kleinen Raspi. Aber obwohl ich immer noch unter massivem Spambeschuss stehe, haben sich mittlerweile wohl die Antispam-Cloud-Dienste und die internen Spam-Abwehrmechanismen auf die neue Art des Spams eingestellt, die vor einigen Wochen wie eine Schlammlawine durchs Netz gewalzt ist. Der Raspi hat also als Torwächter wieder weniger zu tun. Bei einer anderen Anwendung hat aber die extrem schwache Hardware die Hürden nicht geschafft. Ich wollte für die kommende Cordova-Vorlesung, die ich an der TH Bingen ab übernächster Woche halte, ein Linux-System so konfigurieren, dass Cordova-Android-Apps kompiliert und nach Möglichkeit auch in einem Emulator (oder zur Not auf einem per USB angeschlossenen SmartPhone) ausgeführt werden. Da für Cordova eine ganze Reihe an recht alten Bibliotheken (JDK 8) auf der einen Seite und den elend vielen Ressourcen im Fall von Android auf der anderen Seite verlangt werden, ist meine Workstation nicht passenden konfiguriert – von meinem Matebook mit der kleinen SSD ganz zu schweigen. Und ich habe keine Lust, nur für die Vorlesung meine gesamten Konfigurationen durcheinander zu bringen und zig Sachen da zu installieren, die ich sonst nicht mehr brauche.

Zwar habe ich einen passenden Docker-Container noch von der letzten Vorlesung vorbereitet und auf den neusten Stand gebracht und auch mein altes Terra-Notebook hat Cordova sogar mit Visual Studio verfügbar (das geht maximal bis Visual Studio 2017 und das habe ich aus dem Grund auch noch auf dem alten Notebook gelassen). Aber unter meinen Linux-Systemen klappt die Installation von Cordova und den Android-Ressourcen nicht so richtig. In dem parallel auf dem alten Notebook installierten Linux ist irgendwas zerschossen und ich kann gar keine Aktualisierungen vornehmen. Das muss ich vermutlich komplett neu aufsetzen. Und bei den virtuellen Maschinen habe ich sowohl bei VM Ware als auch VirtualBox eine Reihe von anderen – und ganz verschiedenen – Problemen. Alles nix Tragisches, aber es kostet Zeit und wenn ein Problem gelöst ist, kommt das nächste. Unbefriedigend und es raubt Zeit.

Da kam mir die Idee, entgegen meiner bisherigen Planungen vielleicht doch einen neuen Raspi zu kaufen und den als Linux-System ins lokale Netz zu hängen und je nach notwendigem Ziel immer wieder neu aufzusetzen. Also so eine Art Hardware-Docker-Container-VM-Ersatz. Ich hatte für den ersten Raspi so um die 35 – 40 EUR ausgegeben, bin mit der Erwartung gerade auf die Suche gegangen und fast vom Glauben abgefallen. Die wollen ja teils weit über 200 EUR für die Platine mit ein bisschen Krimskrams dazu. Ne, wirklich nicht. Das hat ja gar nichts mehr mit der ursprünglichen Idee einer möglichst billigen Platine zu tun. Ich schaue mal weiter oder vielleicht gebe ich doch alternativen Platinen eine Chance, bei denen nicht noch zusätzlich ein Hype die Preise hochtreibt. Oder lasse es.

Derzeit kann man wohl weder Sprit bzw. Öl als auch Hardware kaufen. Benzin muss leider ab und zu sein (auch wenn ich weniger fahre und zudem wenn möglich auf das Rad oder eBike umsteige), aber Hardwarekauf kann verschoben werden, bis die Preise wieder normal sind.

Neuer Lehrauftrag an der TH Bingen im kommenden Semester

Eben habe ich meinen Lehrauftrag für das nächste Semester an der TH Bingen unterschrieben und bin wegen der überbordenden Bürokratie auf 180. Ich halte Ende März wieder eine Vorsemester-Veranstaltung zur Entwicklung von plattformneutralen Apps auf Basis von Cordova. Das habe ich schon ein paar mal gemacht und auch wenn Cordova nicht mehr der neuste Schrei ist, finde ich die Idee immer noch sehr interessant. Mit Flutter und Xamarin werde ich aber auch ein paar Alternativen – wenngleich mit anderem Ansatz – einfließen lassen.

Obwohl es als Lehrbeauftragter nur recht kleines Geld gibt – ich halte solche Vorlesungen schon seit mehreren Jahren in verschiedenen Varianten und zu mehreren Themen (früher an der Hochschule RheinMain in Wiesbaden und seit 2016 an der Hochschule Bingen) und auch sehr gerne. Aber der bürokratische Aufwand, der mittlerweile damit einhergeht, verleitet den Spass.

Es ist ist unmöglich, was da an Formularen von der TH Bingen im Vorfeld gefordert wird.

Mehrfach zu unterzeichnende Lehraufträge. Auf Papier. Ok, das kann man noch tolerieren, wenngleich es natürlich DocuSign & Co gibt. Gerade bei einer technischen Hochschule sollte man erwarten, dass solche Techniken da bekannt sind und angewendet werden. Aber sei es drum – mit dem Zeug kann ich leben.

Aber nicht damit, dass ich zig Datenschutzverordnungen und sonstige Formulare ausfüllen musste. In 3-facher Ausführung und von A-Z von Hand. Name, Adresse, Funktion, Ort, Datum, Unterschrift. Dass ich meine Stunden dann auch wieder auf Papier dokumentieren und abrechnen muss, ist nur ein weiterer Stein in der Bürokartiemauer.

So lächerlich, umständlich, unbequem und Steinzeit, dass es mir vollkommen verleitet wird, noch einmal so einen Lehrauftrag anzunehmen. Die Zeit, die ich da brauche, ist zwar nicht die Welt. Aber diese lächerliche Bürokratie regt mich auf. Ich komme mir da – vor allen Dingen mit den Strafandrohungen in diesen angeblichen Datenschutzformularen – vor wie ein Schwerverbrecher, der um Begnadigung ersucht. Solche Zumutungen habe ich nicht einmal gehabt als ich für Polizei und ähnlichen Behörden oder Firmen mit sensiblen Daten gearbeitet habe. Auf der einen Seite kaum Geld zahlen wollen und auf der anderen Seite noch unverschämte Forderungen haben und Steine in den Weg legen – geht es noch? 🙁

Wobei die TH Bingen an sich nicht der richtige Adressat für meinen Zorn ist – die zuständigen Behörden im Hintergrund gehören endlich mal aus der Steinzeit abgeholt. Da muss man sich nicht wundern, dass kein IT-ler für Behörden irgendetwas machen will.

Der erste neue Tipp des Jahres

Nachdem es zwischen den Jahren keinen neuen Tipp gab, wurde heute bei LinkedIn Learning wieder der nächste regelmäßige Entwickler-Tipp zu Python freigeschaltet. Der erste Tipp im Jahr 2022. Dieses Mal verbinde ich die Themen Python und Docker. Gerade mit Docker habe ich ja Anfang letzten Jahres etwas mehr beschäftigt, um eine Cordova-Umgebung für meine Vorlesung bei der TH Bingen bereitzustellen. Damit kann man ja alle möglichen verschiedenen Konfigurationen und Systeme bereitstellen, ohne immer wieder seinen Rechner umkonfigurieren zu müssen. Auch für Python.

Wenn man Docker installiert hat, dann kann man ein Python-Image laden und auf dem Rechner installieren. Das heißt, man hat eine virtuelle Laufzeitumgebung für Python. Das ist vor allen Dingen dann interessant, wenn man verschiedene Versionen von Python benötigt. Dazu muss allerdings auf dem Rechner Docker installiert sein. Das Zusammenspiel zwischen Python und Docker geht in zwei Richtungen. Nicht nur kann man mit Docker eine Python-Umgebung, eine virtuelle Python-Umgebung schaffen, es gibt auch die Möglichkeit, ein Docker-SDK für Python zu installieren.

Aus dem Tonstudio an die Hochschule

Cordova

Ich habe meine aktuellen Aufzeichnungen für LinkedIn Learning (LiL)  abgeschlossen und nächste Woche geht es (virtuell) wieder für 2 Tage an die Technische Hochschule Bingen. Ich hatte da für dieses Semester im Studiengang „Mobile Computing“ nach 2 oder 3 Jahren Pause erneut einen Lehrauftrag angenommen.

Ende März/Anfang April hatte ich da mehrere Tage zu Cross Plattform Entwicklung mit Cordova remote unterrichtet und meinen Studenten die Entwicklung einer App als Semesterarbeit aufgegeben. Die Vorführung steht jetzt am Ende des Semesters an

 

JSF/MyFaces, Microservices, Maven & Co

Ich habe die ersten drei Tage der Woche eine Einzelschulung zu erweiterten Java-Themen gehalten. Es ist kaum zu glauben, aber das war die erste Live-Schulung seit 1,5 Jahren. Obwohl ich in der Zeit sogar sehr viele Schulungen gehalten habe, waren sie allesamt online.
Bei der Schulung ging es grob gesagt um Java. Aber keine Einsteiger-Themen, sondern um eine Betrachtung diverser Themen im Java-Umfeld samt Web für einen erfahrenen Programmierer, der sich mit den Techniken bereits auskennt. So Sachen wie

  • JUnit, Git und Github,
  • Maven und andere Build-Tools wie Gradle und Ant,
  • Docker,
  • Übersicht neue Java-Techniken (vor allen Dingen Lambda-Ausdrücke, Closures und das Modulsystem)
  • JavaFX/OpenJFX/FXML
  • Ausblick Mobile, Android Studio, Cordova
  • Tomcat bzw. Java-Container als Server (Wildfly)
  • JSP/Servlets/JSF
  • Refactoring
  • Microservices (Spring)

Bei der Anfrage hat mich allerdings das Thema JSF (Java Server Faces) doch schwer verwundert. Ich hatte in der Vergangenheit JSF durchaus mehrfach geschult, aber seit Jahren eigentlich nichts mehr damit zu tun. Und ich bin davon ausgegangen, dass das Thema JSF eigentlich ziemlich out ist. So hatte ich das auch schon vor einigen Jahren beurteilt und mich deshalb aus dem Themenkomplex weitgehend zurückgezogen. Die vereinzelten Anfragen zu JSF-Kursen habe ich auch immer abgelehnt. Überhaupt sah und sehe ich bei den Java-Frameworks für das Web eigentlich nicht (mehr) das große Potential. Weder bei JSF (oder gar Servlets/JSP), noch Spring oder Struts.

Aber mein Teilnehmer wechselt demnächst beruflich als IT-Leiter in eine Behörde, die wohl mit JSF 2.3 arbeitet. Alttechnologien halten sich oft ewig. Ich habe ja auch einen Standardkunden, der noch mit Cobol arbeitet.

Da diese Schulung als eine Art Workshop mit Wissensaustausch gewünscht war und JSF etc. nur einen Teil der Agenda ausgemacht hat, habe ich die Sache angenommen. JSF und Web haben wir dann auch geschlossen am dritten Tag abgearbeitet.

Rückblickend war es auch verdammt spannend, sich wieder in die Welt von JSF einzuarbeiten. Wobei dabei uns beim Voranarbeiten ganz interessante Phänomene untergekommen sind, von denen mir immer noch nicht ganz klar ist, ob wir auf den Grund der Tatsachen getaucht sind oder uns verirrt haben.

Gerade bei Java im Web-Umfeld ist m.E. erst einmal die Konfiguration die größte Einstiegshürde. Vor allen Dingen, wenn man da nicht täglich am Schaffen ist. Das fängt schon mit der Konfiguration der Server an. Ganz banal bei der lästigen Tomcat-Einstellung in der Datei tomcat-users.xml, wo mit

<role rolename="manager-gui"/>

<user username="admin" password="admin" roles="standard,manager-script,manager-gui" />

erst einmal freigeschaltet werden muss, dass der Server über das Webinterface administriert werden kann und war-Dateien überhaupt deployed werden dürfen. Mit Wildfly ist es auch nicht einfacher bzw. bequemer.

Da Maven in der Schulung ein großes Thema war, haben wir viel mit Architypes gearbeitet. Auch bei JSF, was wir in der Version 2.3 als Basis genommen haben. Neben den Schablonen in Netbeans und Eclipse, die mit Maven, Ant oder Gradle arbeiten.

Neben dem elenden Konfigurieren über die web.xml und die faces-Konfigurationsdateien gab es ganz ungewöhnliche Probleme mit dem Kompilieren bzw. Deployen der Projekte. Vor allen Dingen Projekte, die ich schon zum Laufen gebracht hatte, als auch die generierten Projekte aus den POM-Dateien wurden vielfach nicht übersetzt oder konnten nicht auf den Tomcat depoyed werden. Teils gingen auch die SSI-Dateien mit den Tag-Libs, aber alleine die Existenz einer Java-Datei im Projekt hat die Übersetzung blockiert. Nicht einmal als Bean oder Controller gebaut, sondern eine leere Klasse im source-Verzeichnis hat genügt, um einen Fehler zu erzwingen.
Andere Projektkonfigurationen haben die Java-Controler und -Beans übersetzt, aber die xhtml-Dateien wurden auf dem Server nicht geparst und damit die Tag-Libs nicht verarbeitet.
In Netbeans gab es bei dem Problemen mit dem Java-Code die unverständige Fehlermeldung, dass source in der Version 6 nicht mehr unterstützt wird und wir die Version 7ff nehmen sollten. Nach diversen Problemen habe ich auf mein Matebook als Ursache getippt, aber auf dem Teilnehmerrechner waren die Fehler exakt reproduzierbar.
Irgendwann hatte ich die Faxen dicke und habe auf einem alten Linux-Rechner die Geschichte von Grund auf neu aufgesetzt. Also zuerst Maven, was noch nicht da installiert war, und dann einen Architype für JSF mit der Konsolenanwendung mvn aus dem Internet gezogen. Damit hat die Sache von A bis Z funktioniert und mir ist aufgefallen, dass ich auf dem Linux-Rechner das OpenJDK 8 installiert habe. Auf unseren beiden anderen Rechnern allerdings das JDK 16 und bei meinem Teilnehmer das JDK 15. Und danach haben wir endlich in einer Konfigurationsdatei zu den JSF 2.3 die XML-Tags gefunden, dass die Entwickler- als auch Zieldatei auf Java 8 festgelegt ist.
Unter dem Gesichtspunkt macht auch die Fehlermeldung von Netbeans Sinn – es müsste bei mir eigentlich heißen source in der Version 16, aber das Feld für die Versionsnummer wurde wohl nur einstellig konzipiert. Aus der 16 wurde die 6 und damit eine vollkommen unsinnige Fehlermeldung. Aber zum Zeitpunkt, wo die JSF 2.3 konzipiert wurden, hatte man vermutlich nicht an Inkompatibilitäten in so hohen Folgeversionen, sondern nur älteren Versionen, gedacht. Wir sind nicht so ganz sicher, ob die JSF bis zur Version 2.3 mit den neuen JDK nicht mehr klar kommen, aber ich denke schon. In der Doku steht explizit auch die Version 8. Das deckt sich mit der Tatsache, dass Cordova auch nur bis zur JDK-Version 8 funktioniert. Das habe ich ja in meiner Vorlesung an der TH Bingen die Tage behandeln müssen.
Die JSF werden wohl als Apache MyFaces weiterentwickelt und stehen mittlerweile in der Version 4.0 zur Verfügung, aber die haben wir uns dann nicht mehr genauer angesehen.

Rund um das Thema habe ich auch noch ein paar nützliche Anleitungen gefunden:

JSF Tutorial
https://www.javawebtutor.com/articles/jsf/
https://www.tutorialspoint.com/jsf/jsf_overview.htm

JSF in Tomcat zum Laufen bringen
https://www.byteslounge.com/tutorials/how-to-configure-jsf-in-tomcat-example

Webanwendungen als Docker-Images herstellen
https://jaxenter.de/apache-tomcat-meets-docker-webanwendungen-als-docker-images-herstellen-23213

Grundsätzlich hat sich mein Eindruck gefestigt, dass im Web Java nicht (mehr) der Bringer ist. Irgendwie reihen sich JSF/MyFaces in andere Projekte wie JavaFX/OpenJFX oder auch Cordova ein, bei denen die Originalhersteller die Entwicklung abgetreten haben und wo es aus meiner Sicht nicht sicher ist, dass diese Projekte auf Dauer sich halten und/oder zuverlässig weiterentwickelt werden.

Wobei die Erstellung eines Spring-Microservice für Tomcat wirklich genial einfach war und die mit einer Anleitung erstellte Version des Microservice absolut flexibel und einfach an beliebige Bedürfnisse anzupassen ist.

Android 11 für mein Test-SmartPhone

Ich habe vor einigen Wochen ein ganz einfaches Nokia-SmartPhone bekommen, das bei einer Firma überzählig war, weil ein Mitarbeit gegangen war. Das Gerät ist zwar ziemlich neu, aber wirklich ganz, ganz einfach und schwach auf der Brust, wenn ich es mit meinem Honor View10 vergleiche. Obwohl das ja auch schon in die Jahre gekommen ist und mittlerweile wohl nicht einmal mehr als Einsteiger-Gerät zu haben ist. Aber ich will gar nicht über das Nokia-SmartPhone lästern, sondern ich bin sogar dankbar, dass ich es als Testgerät für mein Seminar zu Cross Plattform Entwicklung mit Cordova an der TH Bingen zur Verfügung habe. Damit muss ich mir nicht meine tatsächlich in Betrieb befindlichen Geräte mit Demo-Apps vollhauen.
Nun hat das Nokia gestern sogar Android 11 bekommen, was weder auf dem Honor View10, meinem alten Asus-Tablet oder gar meinem „Best-SmartPhone-Ever“ (einem Galaxy S4, was ich immer noch ohne SIM-Karte für die Authentifizierung bei Online-Banking etc. verwende) bereitgestellt wird. Damit kann ich die Apps jetzt auch real in dem aktuellen Android testen und nicht nur in einer Emulation.
Gerade habe ich mal eine Tour gestartet, was denn Android 11 Neues bringt. Fazit: heiße Luft und nichts, was ich je brauchen werde. Mein Vorurteil wird weiter gestärkt – die Entwicklung von mobilen Geräten als auch deren Betriebssystemen bzw. der Software stagniert seit vielen Jahren bzw. bringt rein gar nichts wirklich Neues bzw. Relevantes.

Deutschland, Deine Bürokratie und IT-Rückständigkeit

Vor ein paar Tagen habe ich mein virtuelles Vorsemster-Seminar zu Cross Plattform Entwicklung mit Cordova an der TH Bingen erst einmal beendet bzw. bis zum Ende des Semesters mit 2 (vermutlich) Präsentationstagen der Ergebnisse der Semesterarbeiten unterbrochen. Gestern kam ein Brief von der TH mit dem offiziellen Lehrauftrag bzw. Vertrag.

Im Grunde nicht bedeutend, aber dabei ist mir wieder die unendliche Bürokratie und Rückständigkeit aufgefallen, wenn man in Deutschland etwas mit offiziellen Stellen zu tun hat. Natürlich kommt der Vertrag noch auf Papier und so etwas wie DocuSign will ich nicht fordern, geschweige denn erwarten. Es sind Behörden. Die dreifache Ausfertigung ist natürlich auch typisch Deutsch. Nicht umsonst ist hier auch Klopapier meist dreilagig.

Aber da war noch ein Bürokratie-Zeug dabei, dass ich nur den Kopf schütteln kann. Von einem Blatt zum Datenschutz mit vollkommen an der Realität vorbeigehenden Ausführungen/Anordnungen über ein Corona-Merkblatt mit Regeln, die man seit einem Jahr schon auswendig kennt. Beides war aber noch mal zu bestätigtigen – als hätte man diesen Mist die letzten Jahre und Monate nicht schon zig Mal zur Kenntnis genommen und immer und immer wieder diese Tatsache bestätigt.

Die Krönung ist, dass meine Stundenabrechnung auf Papier (!!) erfolgt. Ich muss handschriftlich (!!) jede gehaltene Stunde eintragen. Man sollte bedenken, dass das T in TH für „Technische“ steht. Da lacht die ganze Welt über deutsche Behörden, weil sie noch Fax verwenden, und eine Hochschule mit modernsten Ansprüchen erwartet Kommunikation und Abrechnung auf Papier und per Post. Wobei ich die TH zumindest teilweise in Schutz nehmen muss – die Abrechnung geht über das Landesamt für Finanzen und mit denen hatte ich auch schon direkt bei Schulungen dort zu tun. Damit sollte mich dieses Level im Grunde nicht überraschen. Das ist nicht nur eine unmögliche Bürokratie, das ist auch technische Steinzeit. Zumindest das Niveau vor Einführung von Computern.

Vorlesungsende zum Semesterbeginn

Heute ist mein virtuelles Vorsemster-Seminar zu Cross Plattform Entwicklung an der TH Bingen erstmal beeendet. Direkt bevor die eigentliche Vorlesungszeit beginnt. Nach den 6 vollen Tagen rund um die App-Entwicklung mit Cordova haben die Studenten von mir zum Abschluss eine Praxisaufgabe (Entwicklung einer App) bekommen, die sie über das Semenster dann bewältigen sollen. Am Ende des Sommersemesters „sehe“ (vermutlich wieder nur virutell) ich sie nochmal an 2 Päsentationstagen, an denen sie dann ihre Ergebnisse vorstellen können.

Wir wollen beim Mac Mini unser geliebtes „Space Grey“ wieder

Ich war früher regelrechter Apple-Gegner und habe mich von dem gesamten Habitat und dem Hype rund um diese „Religion“ richtig angewidert gefühlt. Außer bei ein paar Onlinetraining zur App-Entwicklung unter iOS bei LinkedIn Learning (LiL – damals noch Video2Brain) habe ich rein gar nichts mit Apple-Produkten zu tun gehabt. Aber da musste ich ja zwangsläufig mit einem Mac arbeiten (ein Mac Mini, der bei mir im Zweitbüro immer noch sein Gnadenbrot fristet). Aber sonst wollte ich einfach nicht an das Zeug ran. Selbst bei meinem Buch zu Cordova, bei dem es ja um Cross Plattform Entwicklung für Apps (und damit auch iOS) geht, konnte ich rein mit Linux und Windows als Entwicklungsplattform und Android, Windows Mobile und den Browser als Ziel-Plattform bzw. Emulation auskommen und damit iOS nebenher erschlagen.

Meine Kidds hingegen verwendeten irgendwann an der Schule und jetzt der Uni iPads, aber auch die haben mich absolut nicht überzeugt.

Eigentlich habe ich das erste Mal einen Apple als „richtiges“ IT-Gerät statt reines Mode- und Statusspielzeug wahrgenommen, als wir Corona-bedingt mit meiner Band nur noch virtuell mit JamKazam zusammenspielen konnten. Mit keinem anderen Rechner ist die Sache so gut gelaufen wie mit besagtem alten Mac Mini, der in meinem Büro in Eppstein verstaubte.

Nun bin ich sogar mittlerweile so weichgekocht, dass ich mir die Anschaffung von einem der neuen Mac Mini mit dem M1-Prozessor oder eventuell kommenden M2-Prozessor vorstellen kann. Die neue Architektur von Apple soll ja wirklich herausragend sein.

Mich schreckt noch das Betriebssystem ab (ich kann mit Mac OS nicht arbeiten – fertig), aber ich habe gelesen, dass ein virtualisiertes Windows 10 auf den Geräten schneller laufen soll als auf vergleichbaren Intel-PCs nativ. Das wäre ein gangbarer Weg, wobei die Kosten schon heftig sind und es derzeit wohl die Geräte nur mit winziger SSD (gerade mal 512 GB) und ebenso winzigem RAM (m.W. nur 8 GB oder vielleicht 16 GB) gibt. Aber ich denke schon, dass da demnächst praxisgerechtere Varianten mit vielleicht 1 TB SSD und mindestens 32 GB RAM auftauchen. Weniger sollte es in aktuellen Zeiten auf keinen Fall mehr sein und je nachdem, wie teuer sich Apple sich die Dinger bezahlen lässt, würde ich vielleicht sogar zuschlagen.

Nun habe ich deshalb ein bisschen in Apple-Magazinen gestöbert und eine Schlagzeile zu dem Mac Mini hat mich schon wieder massiv ins Zweifeln gebracht, ob ich mich wirklich in diese Welt begeben sollte? Da war das zu lesen:

Mac Mini – Space Grey kommt zurück
Viele stellten sich die Frage: Warum hat Apple den M1-Mac-Mini nicht in der Farbe Space Grey 2020 gebracht? …

Geht es noch? So etwas ist Thema in diesem Umfeld? Die Farbe?

Au weiha …

Server-Umzug abgeschlossen

Der Umzug meines V-Servers sollte jetzt fertig sein. Der E-Mail-Server läuft und ist hinreichend konfiguriert. Der Spamschutz scheint besser wie vorher zu sein und auch die Kommunikation mit einer E-Mail-Adresse, die bisher nie durchging, hat eben funktioniert.

Soweit ich das sehen kann, sind jetzt auch alle Webseiten von mir wiederhergestellt und gleich mal auf den neusten Stand aktualisiert. Die unwichtigste Seite hat – natürlich ;-(  – die meiste Arbeit gemacht. Aber ich habe zumindest wieder etwas zu der Bedeutung von Eigentum und Gruppenzugehörigkeit unter Linux (und auch WordPress) gelernt und diverse Linux-Shell-Befehle geübt. Bisher war ich wirklich so naiv und dachte, dass Dateirechte die entscheidenden Stellen sind und man spätestens mit 755 auf der sicheren Seite hinsichtlich der Ausführung, dem Zugriff und ggfl. Schreiben in entsprechende Verzeichnisse auf dem Server sein sollte, wenn man Webseiten bereitstellt. Ich habe wegen diverser Probleme eine gefühlte Ewigkeit erfolglos mit den Schreibrechten herum experimentiert (sowohl über FTP als auch direkt per SSH mit chmod bis hin zu 777), bis mir aufgefallen war, dass bei den Webseiten ohne Probleme ganz andere Eigentumsrechte und Gruppenzugehörigkeiten da waren als bei denen mit Problemen. Da lag der Hase im Pfeffer und root ist nicht immer root (zumindest nicht im universellen Sinn – der root des SSH ist nicht immer der root der Webserver oder gar irgendeiner Verwaltungssoftware wie Plesk). Admin fuddeln vielleicht da rum – unglaublich.

Mit chown -R für den Eigentümer und chown : für die Gruppenzugehörigkeit haben sich dann aber (fast) alle Probleme in Luft aufgelöst. Nur die Zugriffs- bzw. Rechteprobleme bei der unwichtigsten Seite (einem Joomla!-System) habe ich einfach nicht in Griff bekommen. Die Seite habe ich dann kurzentschlossen komplett neu aufgesetzt (jetzt aber als WordPress-System) und dann einfach die wichtigsten Inhalte aus meiner lokalen Sicherung eingefügt.

Und da ich gerade dabei war, habe ich auf dem neuen V-CordovaServer Docker angeschaltet und gleich mit meinem Cordova-Skript für die kommende Vorlesung an der TH Bingen getestet. Das ging wie Butter durch ein heißes Messer – oder auch umgekehrt. Alle notwendigen Programme und Bibliotheken wurden problemlos (und fix) installiert und der Container ist sofort gelaufen. Das konkrete Erstellen der Cordova-App für eine Android-Plattform ging ebenso perfekt. Ich habe mich dann noch von einem anderen Rechner per SSH auf dem Server eingeloggt und aus dem Terminal die generierte App aus dem Docker-Container auf das Host-System kopiert. Null Problemo. Unter Linux läuft so Zeug die Docker einfach perfekt.

Ich komme immer mehr auf den Geschmack, meine Kenntnisse um Docker etwas zu intensivieren und zudem mehr mit dem Server zu machen als bisher.

Performance von SSD und HDD testen

Ich bin mit meinem Huawei Matebook sehr zufrieden. Nur ist die Festplatte einfach zu klein. Ich bin dermaßen am Limit, dass ich immer wieder Sachen löschen muss, wenn ich neue Daten oder Programme da benötige. Gerade aktuell musste ich wegen Cordova noch zusätzlich Visual Studio 2017 installieren und damit ist meine Festplatte jetzt nahezu dicht. Ich habe schon diverse Sachen deinstalliert und nur noch eine Auswahl meiner Daten auf der SSD.

Nun hänge ich sowieso immer wieder eine externe Festplatte per USB an. Das taugt für Daten ganz gut (etwa Videos, die ich für LinkedIn Learning einspiele). Aber da die Festplatte nicht einmal USB-3 unterstützt, ist das Auslagern von Programmen auf die Festplatte nur suboptimal und auch bei großen Datenmengen dauert das Laden und Schreiben mir zu lange. Deshalb habe ich mir eine externe SSD mit USB-3/Thunderbold-Anschluss bestellt. Darauf sollte auch das Installieren von Programmen Sinn machen. Gerade portable Versionen werde ich darauf auslagern.

Um aber überhaupt einmal mitzubekommen, wie groß die Unterschiede beim Lesen und Schreiben sind, habe ich mir gerade das Programm CrystalDiskMark geladen. Aber im Grunde kann man die Performance von Datenträgern auch mit Windows-Bordmitteln testen.

In einer Admin-Console oder der Powershell kann die Tests ausführen:

winsat disk -seq -read -drive x
winsat disk -seq -write -drive x
winsat disk -ran -read -drive x
winsat disk -ran -write -drive x

Das werde ich mal auf meinen Rechnern durchspielen – sowohl auf die fest verbauten SSD und HDD als auch die externen Ressourcen an verschiedenen Anschlüssen.