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.

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.

Google My Business

Vor einiger Zeit ist mir bewusst geworden, dass „Hinz und Kunz“ bei Google Maps mit ihren Unternehmen eingetragen sind. Selbst mit den Kleinsten. Klar – das habe ich im Grunde schon häufig „gesehen“, aber eben nicht im klassischen Sinn „wahrgenommen“. Schon gar nicht, dass ich das mit einem „Geschäft“ – also  „My Business“ – auch machen sollte. Warum denn nicht?

Gut – nicht zuletzt durch Corona bin ich beruflich mehr oder weniger bis Anschlag ausgelastet und Marketing bzw. Werbung für neue Aufträge muss ich im Moment nicht machen. Aber es ist natürlich nicht klar, dass die Situation auf Dauer so bleibt. Gibt ja den Spruch, dass man für die Krise vorsorgen sollte, wenn es gerade läuft.

Also habe ich mich in Google Maps mit meinen beiden Standort eingetragen. Und wenn es nur Traffic auf meine Webseite leitet und damit meine Bücher und Onlinevideos bei LiL gekauft werden.

Jetzt hat mir nach der Anmeldung Google Post zugeschickt unter dem Stichwort „Google My Business“. Mit einem Gutschein für Google Ads. Den kann ich in der Tat gut nutzen, um meine im Eigenverlag publizierten Bücher ein wenig zu promoten. Denn da gibt es mittlerweile gleich 4 Stück.


Reguläre Ausdrücke – Kurz und bündig
Reguläre Ausdrücke - Kurz und bündig - von Ralph Steyer

Reguläre Ausdrücke – Kurz und bündig

Seitenzahl: 104 Seiten

ISBN: 9783753136493

Verkaufspreis: 11,99 €

XML – Kurz und bündig
XML - Kurz und bündig - von Ralph Steyer

XML – Kurz und bündig

ISBN: 9783753133423

Format: DIN A5 hoch

Seiten: 128

Softcover 14,99 €

Erscheinungsdatum: 13.12.2020

COBOL – Grundlagenkurs für Ein- und Umsteiger
COBOL - Grundlagenkurs für Ein- und Umsteiger - von Ralph Steyer

COBOL – Grundlagenkurs für Ein- und Umsteiger

Seitenzahl: 188 Seiten

Sprache: Deutsch

ISBN: 978-3-753139-03-6

Verkaufspreis: 21,99 €
Erscheinungsdatum: 26.12.2020

Aufzucht und Pflege kleiner Webseiten mit HTML – Grundlagen der Webseiten-Erstellung
Aufzucht und Pflege kleiner Webseiten mit HTML - Grundlagen der Webseiten-Erstellung - von Ralph Steyer

Aufzucht und Pflege kleiner Webseiten mit HTML – Grundlagen der Webseiten-Erstellung

ISBN: 9783741828829

Format: DIN A5 hoch

Seiten: 300

Erscheinungsdatum: 01.07.2016

Alle guten Dinge sind 3

Nachdem ich über den Dezember bereits im Eigenverlag zwei komplett neue Bücher zu XML und ein Buch zu regulären Ausdrücken veröffentlicht habe, habe ich Nägel mit Köpfen gemacht und gleich im Anschluss mein Buch zu Cobol aus dem Jahr 2017 komplett überarbeitet. Es kamen dabei gut 35 Seiten hinzu. Vor allen Dingen viele neue Beispiele. Aber auch die bestehenden habe ich gründlich überarbeitet, Aktualisierungen einfliessen lassen, einige Fehler und Ungenauigkeiten korrigiert und auch das Layout überarbeitet. 

Damit sollte das neue Buch zu Cobol auf ein paar Jahre hinaus zu gebrauchen sein, denn wirklich Neues tut sich bei Cobol ja nicht. Was konträr zur wieder steigenden Bedeutung von Cobol ist, denn ich verrate kein Geheimnis – COBOL gilt seit vielen Jahren als veraltet. Dennoch – gerade die Corona-Krise hat den Bedarf an COBOL-Kenntnissen wieder angekurbelt, denn viele alten Programme bei Behörden, Banken und Versicherungen sind immer noch in COBOL geschrieben. Die neuen und gestiegenen bzw. veränderten Anforderungen in Verbindung mit der Corona-Krise haben Anpassungen notwendig gemacht und dafür wurden und werden COBOL-Kapazitäten benötigt. Nur gibt es kaum noch COBOL-Programmierer, denn diese kommen mehr und mehr ins Rentenalter. Deshalb werden in der letzten Zeit auch wieder Fachinformatiker auf COBOL angesetzt. Das hätte man vor einigen Jahren niemals gedacht.

Das ist die Eckdaten zum überarbeiteten Buch:

  • Sprache: Deutsch
  • ISBN: 9783753139036
  • Format: DIN A5 hoch
  • Seiten: 188
  • Erscheinungsdatum: 26.12.2020

XML – Kurz und bündig – mein neustes Buch

XML - Kurz und bündig
XML – Kurz und bündig

Ich habe in den Wochen vor dem Jahresende so langsam meine Schulungen zurückgefahren, um einmal etwas zur Ruhe zu kommen und andererseits Zeit für die Überarbeitung meiner Joomla!-Schulungsunterlagen beim Herdt-Verlag zu haben.

Nur gibt es massive Verzögerungen bei der Veröffentlichung der Version 4 von Joomla! und es macht wenig Sinn, die Überarbeitung auf die Betaversion von Joomla! aufzubauen. Also habe ich die frei gewordene Zeit genutzt und mein ganzes bereits über die Jahre gesammeltes Material zu XML in eine Buchform gegossen. Auch wenn ich normalerweise für grosse Verlage Bücher schreibe, publiziere ich hin und wieder auch im Selbstverlag. Bisher habe ich auf diese Weise bereits ein Buch zu HTML und eines zu Cobol veröffentlicht. Hier gibt es nun mein neustes Buch zu XML.

Das ist die Eckdaten:

  • ISBN: 9783753133423
  • Format: DIN A5 hoch
  • Seiten: 128
  • Erscheinungsdatum: 13.12.2020

Das Buch wurde ein Lehrbuch für den Einstieg in XML. Es soll sowohl beim Selbststudium helfen als auch Basis dafür sein, in entsprechenden Kursen XML zu lernen. Der Fokus liegt auf dem Erstellen von XML-Dokumenten und dem Verstehen der Logik und Syntax. Aber auch die Validierung von XML-Dokumenten wird gezeigt und, was man mit XML in der Praxis machen kann. Das Buch wendet sich im Wesentlichen also an Leser, welche die Erstellung sowie das Lesen und Verstehen von XML-Dokumenten als auch Anwendungen mit einer XML-Basis (z.B. SVG, XHTML, Datenbank-Export und -Import, Erstellung grafischer Oberflächen, etc.) lernen wollen. Es ist also explizit ein Einsteigerbuch geworden.

Corona sorgt dafür, dass wieder mehr Cobol-Wissen gebraucht wird

Was ist schon seit 30 Jahren totgesagt und wird aktuell wieder massiv gesucht?

 

Cobol-Wissen! 

 

Allgemein ist Cobol angeblich sowas von out. Seit Jahrzenten.

Golem meldet nun jedoch, dass derzeit viele alte Mainframes und Programme überlastet bzw. in Schwierigkeiten sind, weil niemand mehr die alten Cobol-Codes lesen und und die Programme warten kann. Helfen sollen auf Cobol umgeschulte Entwickler, weshalb IBM in Zusammenarbeit mit dem Open Mainframe Project der Linux Foundation sogar gratis Cobol-Kurse anbieten soll. Da bin ich natürlich ganz Ohr, denn meine Schulungsmaterialien zu Cobol können da eine gute Ergänzung sein, denke ich.

Der Grund für die Initiative bzw. den aktuell explodierten Bedarf ist, dass vor allem in den USA die Systeme für Meldungen der Arbeitslosigkeit auf Grund der Coronakrise teilweise noch in Cobol geschrieben sind und auf Mainframes von IBM laufen.

Aber auch darüber hinaus werden derzeit vor allem in der öffentlichen Verwaltung und im Finanzwesen noch sehr viele Cobol-Anwendungen eingesetzt.

Ich bekomme es ja persönlich bei den Versicherungen mit, wo ich seit ein paar Jahren wieder angehende Fachinformatiker und Hochschulabsolventen auch in Cobol  schule. Als ich damit angefangen habe, neben C# dort in einer kombinierten Maßnahme auch Cobol zu schulen, habe ich jedoch kein modernes Schulungsmaterial zu Cobol gefunden. Zumindest nicht auf Deutsch. Deshalb habe selbst Unterlagen geschrieben, die ich dann in den Schulungen eingesetzt habe.

Nach den ersten Durchläufen wurde sie in Buchform überführt. Die vertreibe ich in etwas unterschiedlichen Ausführungen sowohl im Selbstverlag als auch als beim Herdt-Verlag im Form einer sogenannten Trainer Edition, die außerhalb des normalen Verlagprogramms läuft. Beide Varianten habe ich gewählt, weil die letzte Zeit kein Verlag noch einen ausreichenden Markt für Cobol gesehen hat, um ein „reguläres“ Buch zu riskieren.

Und natürlich kann auch meine Adaption von dem Cobol-Training bei LinkedIn Learning (LiL – ehemals Video2Brain bzw. Lynda) von der Welle profitieren.

Tja – besondere Zeiten mit Corona führen zu unerwatbaren Situationen. Jetzt gibt es den Markt für Cobol-Literatur und ich bin gespannt, ob ich das an Verkaufszahlen bemerke. Denn auch mit diesem momentanen Anstieg des Bedarfs muss man eindeutig sagen, dass Cobol wirklich veraltet und ein recht kleiner Markt ist. Dennoch – laut  IBM gibt es auf ihren Rechnern geschätzte 220 Milliarden Zeilen Cobol-Code, die noch genutzt werden.

Da die erfahrenen Cobol-Programmierer naturgemäß weniger werden, ist eine Investition in Cobol-Grundkenntnisse also garantiert sinnvoll.

Das Ende von Visual Basic

Es ist vielleicht etwas drastisch formuliert, aber VB hat fertig. Schon seit Jahren hat Microsoft immer wieder angekündigt, bei .NET nur noch auf C# und C/C++ zu setzen. Jetzt ist es amtlich, dass die letzten Neuerungen für VB mit .NET 5 kommen. Dann wird der Versionsstand eingefroren.

Was aber nicht heisst, dass man in absehbarer Zeit VB-Programme los ist bzw. nicht mehr mit VB programmieren wird. Das Beispiel Cobol zeigt es! Seit 30 Jahren totgesagt und – zumindest bei Banken und Versicherungen – immer noch stark im Betrieb.

Ein bisschen unter den Tisch fällt die Zukunft von F#. Denn auch hier hat Microsoft das Interesse verloren, wobei man zugeben muss (auch wenn ich dazu ein Videotraining veröffentlicht habe), dass diese Sprache von Anfang an ein Nischendasein geführt hat.

COBOL-Unterlagen als Buch

COBOL wird schon lange tot gesagt. Es gibt jedoch unverändert zig Millionen von COBOL-Codezeilen. Gerade in Banken und Versicherungen werden COBOL-Programme immer noch eingesetzt und es ist nicht absehbar, dass diese Programme umgestellt werden. Deshalb beschäftige ich mich doch tatsächlich seit Mitte des letzten Jahres mit „echter“ COBOL-Programmierung. Warum „echter„? Mit COBOL ich mich nämlich schon seit Ende des Studiums zu tun. Konkret seit meinem ersten Job nach meinem Studium. Aber nicht mit der konkreten Programmierung von COBOL-Programmen. Sondern damit COBOL-Programme auf „modernere“ Techniken umzustellen und COBOL-Programmierer in neuen Programmiersprachen weiterzubilden. Ganz ehrlich – ich habe mich immer als eine Art „Totengräber“ von COBOL gesehen. Was auch daraus resultiert, dass ich an meinem ersten Arbeitstag direkt die COBOL-Workbench in die Hand gedrückt bekam. Mit den Worten:

„Wir haben noch eine Lizenz für dich gekauft, aber du wirst die nicht mehr brauchen.“

Allerdings hat man seit vielen Jahren nicht mehr in die Ausbildung von COBOL-Programmierern investiert und jetzt gehen die Programmierer so langsam in Rente, die COBOL beherrschen. Es besteht also ein wachsender Bedarf an frischem COBOL-Wissen. Das resultiert nicht zuletzt darin, dass bei Fachinformatikern und auch in Hochschulen wieder COBOL auf dem Lehrplan steht und Banken oder Versicherungen ihre Mitarbeiter wieder in COBOL ausbilden.

COBOL - Crashkurs
COBOL – Crashkurs

Diese Tendenz wurde mir 2016 immer deutlicher und deshalb habe ich mich vom „Totengräber“ zum „Sanitäter“ für COBOL gewandelt und erste Trainings dazu aufgebaut und gehalten. Etwa das Videotraining bei Video2Brain.
Aber auch Liveschulungen und da habe ich keine für mich brauchbaren Unterlagen gefunden. Die waren entweder viel zu teuer, vor allen Dingen viel, viel zu alt und haben mir auch sonst nicht gefallen.

Deshalb habe ich flux eigene COBOL-Unterlagen erstellt, die ich jetzt in ein Buch überführt habe. Ich bin also kein langjähriger COBOL-Programmierer, sondern eher ein kritischer, wenn auch treuer Begleiter, der aus der Sicht modernerer Sprachen COBOL beurteilt. Der Vorteil dieses vermutlich etwas ungewöhnlichen Blicks ist, dass ich aus der Verbindung vieler Sprachen eine Menge Lehren ziehen konnte und vergleichende Dinge sehe, die in dieses Buch einfließen.

COBOL - Einstieg und Grundlagen
COBOL – Einstieg und Grundlagen

Nun habe ich ja verschiedene Verlage, für die ich regelmäßig schreibe. Aber Rand- oder Nischenthemen (und dazu zählt ein neues COBOL-Buch auf jeden Fall – trotz der beschriebenen Aktualität bei der Ausbildung) sind da kaum unterzubringen. Deshalb habe ich das Buch – wie auch das HTML-Buch – im Selbstverlag publiziert.

HTML
HTML

Dazu wird demnächst auch noch ein alternativer Weg als Trainerunterlagen erscheinen.

Die alten Sprachen kommen wieder

Im monatlichen Ranking schafft Go dagegen nach wie vor nicht den Einzug
in die Top 10, sondern befindet sich auf dem 13. Platz – vor einem Jahr
lag es jedoch auf Platz 54. Dart ist auf dem 17. Platz noch deutlicher
von der Top 10 entfernt.
In der monatlichen Spitzengruppe findet sich
jedoch mit Perl die Programmiersprache, die im Jahresverlauf mit 0,91
Prozent am drittstärksten zulegte.

Da schau. In einem Beitrag bei Heise zu Go und Dart, was ja recht neue Programmiersprachen sind, die wohl einen immensen Zuwachs, aber insgesamt noch eine sehr geringe Verbreitung haben, habe ich in der Mitte einen interessanten „Nebensatz“ entdeckt. Perl wächst wieder!
Das deckt sich mit meiner Erfahrung, dass die Alttechniken einfach nicht tot zu bekommen sind.

Zumal Perl wirklich eine sehr gute Technologie ist, die das viel populärere PHP sowas von in den Schatten stellt. Mal sehen, ob sich die Entwicklung auf meine Videotrainings zu Perl und mein Schulungsbuch zu Perl auswirkt.

Dabei ist Perl ja nicht die einzige „Alt-Programmiersprache“, mit der ich mich die letzte Zeit wieder intensiver beschäftigt habe. Auch Cobol steht seit einiger Zeit bei mir an.

Während meiner gesamten Arbeitszeit (also wirklich direkt nach Ende des Studiums) bin ich mehr oder weniger als Totengräber von Cobol aktiv (Umstellen von Cobol-Programmen auf „moderne“ Programmiersprachen und Umschulen von Cobol-Programmierern auf neue Sprachen wie Java oder C#) und jetzt halte ich nach meinem Videotraining zu Cobol sogar übernächste Woche meine erste Cobol-Schulung. Gerade bei Versicherungen und Banken wird immer noch sehr viel mit Cobol gearbeitet, aber die Programmierer mit entsprechenden Kenntnissen gehen in Rente. Dementsprechend nimmt das Know How immer mehr ab und es bedarf Nachwuchs. Nachdem ich mich also gut 20 Jahre immer auf die neuesten Technologien konzentriert habe, schaue ich jetzt also wieder in die Historie. Da wird es wohl auf durchaus längere Zeit einen interesanten Markt für mich geben. Aber die neuen Technologien werde ich sicher nicht ganz aus den Augen verlieren.