Low Level IT Sicherheit fürs Handy

 

Diese kleinen USB-Adapter, hier die von Porta Pow, schützen dich und dein Handy vor Angriffen beim Laden. Die Ladebuchse ist ein von Benutzer unterschätztes Einfallstor. So kann man sein Handy auch an unsicheren Orten sicher Laden. Das Laden des Handies ist möglich, Datenübertragung aber nicht.

Die Ladegeschwindigkeit sinkt auf den Normalwert, d.h. schnelles Laden ist nicht möglich.

JMeter never gets old

 

 Now it's much simpler to run system test or load and performance test. You can integrate the good old JMeter into Maven and run the test in the build pipeline. Great.

Biggest advantage: You don't a JMeter installation. JMeter is loaded and run as Maven plugin.

 

Look at the https://github.com/jmeter-maven-plugin/jmeter-maven-plugin

The outcome of tech debt.

Software Bugs are the result of tech debt.

— Mirko Ebert (@mirkoebert) June 20, 2023

 

Es gibt zwei Gründ für Software Bugs

1. Tech debt
2. Komplexität
   

Komplexität ist auch nur eine Form von Tech debt. Baue technische Schulden ab sonst errecihst den Softwarestand wo die ganze Entwicklerkapazität für das Fire Fighting aufgezerrt wird und es keine Resourcen für die Weiterentwicklung gibt. Dann ist die Software tot.

Technische Schulden sind ein oder sogar der Grund für Fehler.

ChatGPT ist keine kuenstliche Intelligenz (KI)

ChatGPT ist keine kuenstliche Intelligenz sondern eine praechtiges Beispiel fuer maschine learning und Computer Linguistik. Jedem Informatiker ist das klar.

 

Um das zu illustrieren, hier ein lustiger Chat mit ChatGPT. Der Chat ist nicht von mir, er wurde mir aus vertrauenswuerdiger Quelle zugeschickt und hat sich Anfang Mai 2023 ereignet. 

Und weiter gehts.

Und zu guter letzt.

Wer jetzt ChatGPT fuer intelligent haelt, tja dann weiss ich auch nicht mehr.

Managing Dependencies for Micro Services

Dependency Hell, das kennen viele Softwareentwickler oft aus mature Projekten. Was bedeutet das fuers Projekt?

1. Es kann nicht auf aktuelle Versionen von Libs migriert werden, Java eingeschlossen. Dadurch bleiben nuetzliche Funktionen verschlossen.
2. Das Projekt ist statisch wie Beton und nur unter sehr grossem Zeitauswand aenderbar.
3. CVEs koennen nicht behoben werden.

Um Dependencies effiktiv zum meisten und obige Schwaechen zu umschiffen, hier ein paar Best Pracices im Umgang mit Dependencies.

1. Goldene Regeln
1. Less is more
2. Convention over configuration
   
2. Versuche mit moeglichst wenig Konfigurationen auszukommen.
3. Versiuche moeglichst wenig Dependencies zu benutzen.
   
4. Benutze Parents wenn moeglich.
5.  Benutze Dependeny Management (Maven) wenn es moeglich ist.
   
6. Benutze nur fixe Versionen von Libs wenn sie nicht im Parent verfuegbar sind.
7. Wenn du Excludes/Includes brauchst z.B. um CVEs zu fixen, dann hinterlasse einen entsprechenden Kommentar mit der CVE Nummer. So kann diese Konfiguration spaeter sehr einfach entfernt werden.
8. Update regelmaessig deine Dependencies um keinen Wartungsstau aufkommen zu lassen. Du kannst leicht einen Check Step in der Build Pipeline einbauen die dir Anzahl der outdated Libs ausgibt.
9. Aktuelle Libs verbessern die Sicherheit, aktuelle Libs haben weniger CVEs. 
10. Pruefe ob Dependencies noch benutzt werden
1. Grep isy dein Freunf fuer Compile Scope Dependencies: grep -r com.strange-package src/
2. Organize your imports
   
11. Das Build file ist genauso ein Teil deines Softwareprojetes wie der Code selbst.

 

Model Driven Architecture ist tot

 Model Driven Architecture (MDA) und alle Verwandte sind seit den fruehen 2000er tot. Trotz viel Energie, Enthusiasmus, Zeit und Geld die in MDA Projekte geflossen sind, gibt es zwei Erkenntnisse: MDA ist sicher tot und UML ist sinnvoll zur Beschreibung von Software-Konzepten.

Weil es scheinbar zu wenige Senior Software Developer gibt, gibt es Heute MDA Zombies. MDA ist von den Toten auferstanden in Form der Generierung von Klasssen aus YAML Schnittstellenbeschreibungen die dann z.B. über Micro Services geteilt werden.

Bei genauerem Hinsehen sieht man, dass dieser Ansatz auch nicht funktioniert. Er hat folgende Nachteile:

1. Aenderungen an der Schnittstelle fuehren zu aufwendigen Abstimmungsprozessen die multiple Teams, oft das ganze Projekt, einbeziehen. Das ist sehr, sehr teuer.
2. Kein Team ist in der Verantwortung, shared  whatever sind gut Beispiele fuer Verantwortungsdiffusion.
   
3. Selbst wenn ein Team Zeit fuer die Wartung aufwenden moechte, so werden die Kommunikationskosten zur Aufgabe fuehren.
4. Weil sich die Softwareanforderungen aendern die Schnittstelle aber in Beton gegossen ist, fangen die Entwicklerteams an der 'offizielle' Schnittstelle vorbei zu arbeiten. Sie haben gar keinen anderen Weg.
   

Was lernen wir daraus:

1. MDA in allen Varianten ist teuer und ineffizient.
2. MDA ist das Gegenteil von agiler Softwareentwicklung .
   
3. Share Nothing ist und bleibt eine Grundlage fuer agile Softwareentwicklung
4. Die Entwicklung von (shared) Bibliotheken ist deutlich anders zur Entwicklung normaler Micro Services.