Kategorie: Allgemein

Prohibition für Saugrobby!

Was muss ich da lesen? Besoffene Saugroboter?

Jetzt mal unabhängig von der Frage, ob es schlimm oder lustig ist, wenn Saugrobby wie ein verwirrter Hamster immer im Kreis fährt oder länger als sonst zum Reinigen der Wohnung braucht: Kann ja mal passieren, dass beim Abschlusstest eines Updates irgendwas übersehen wird, nicht wahr?

Ich will auch gar nicht über schlechte Testbarkeit meckern oder spekulieren, wie hoch die technische Schuld der womöglich nicht tip-top sauberen Software der betroffenen Roombas des Herstellers iRobot ist (dear iRobot, if you need help here, drop me a message!). Aber der Anlass ist willkommen für die regelmäßige Erinnung an die inhärente Fehlerfortpflanzung bei Software:

Menschen machen nunmal Fehler, das ist menschlich. Unterläuft beispielsweise einem Frisör ein Fehler, rennt hinterher ein Kunde mit doofen Haaren herum. Unterläuft einem Programmierer ein Fehler, so sind viel, viel mehr, schlimmstenfalls Millionen Nutzer betroffen, nämlich alle, die diese Software verwenden oder den fraglichen Code bei einer Sitzung auf einer Cloud-Instanz durchlaufen, falls es sich um eine Webanwendung handelt.

Während der Frisör deshalb mit einem minimalen Korrektiv auskommt (z.B. dem Kunden den Spiegel hinter den Kopf halten und fragen, ob’s gefällt), muss die Software deutlich höhere Hürden überwinden, um in die freie Wildbahn entlassen zu werden. Da ist zunächst mal die Suite von Unit Tests (Sie haben doch Unit-Tests, oder?), Integrationstests auf einer Testumgebung und die Abnahme auf einer Staging-Umgebung bzw. weitere Ende-zu-Ende-Tests, sei es automatisiert oder manuell. Im Idealfall jedenfalls. Eine Testabdeckung von 100% aller Fälle ist jedoch utopisch. Das gilt umso mehr, wenn Endgeräte im Spiel sind, die über individuelle Daten verfügen (z.B. Aufzeichnungen über die Geometrie zu saugender Räume). Die kann man nicht alle testen. Geht nicht.

Also sind halt bisweilen ein paar Staubsauger-Bots besoffen.

Software wird von Menschen geschrieben, die nicht perfekt sind. Folglich kann auch das Produkt nicht perfekt sein. Deshalb wird Software immer ein Restrisiko mit sich bringen. Es mag bei guten Programmierern (die mein Buch gelesen haben) klein sein, aber nie Null. Wer von Software Wunder erwartet, übersieht den menschlichen Faktor. Wer den menschlichen Faktor übersieht, kalkuliert Kosten für Fehlerbehebung oder Wartung nicht hinreichend in die Wirtschaftlichkeitsanalyse ein – und gelang möglicherweise zu einem Ergebnis größer als Null und ist später überrascht, wenn er draufzahlt.

Disclaimer: Nein, dies ist keine pauschale Entschuldigung für Bugs. Schon gar nicht für solche, die durch guten Code und sauberes Testen vermeidbar gewesen wären. Es ist der ausdrückliche Wunsch nach realistischen Einschätzungen.

Wer die Anfälligkeit von Software mit einrechnet, kommt nämlich auch nicht auf so drollige Ideen wie z.B. autonome Drohnen mit tödlichen Waffen oder diskriminierende Algorithmen für die Sichtung von Bewerbungsunterlagen, Anwendungen also, die ein bisschen weniger witzig sind als besoffene Roboter.

tl;dr: Vermeiden Sie Fehler – aber tun Sie nicht so, als gäbe es keine.

Voller als voll

Wenn der Speicher voll ist, wirft Java bekanntlich einen OutOfMemoryError:

Oha.

Tatsächlich kann der Speicher sogar so knapp werden, dass er nicht einmal genügt, um ein Objekte der Klasse OutOfMemoryError zu erzeugen …

Wer genau hinschaut, kann sehen, dass der Fehler von com.android.vending geworfen wurde, also dem Play Store auf einem Android-Smartphone. Einem virtuellen allerdings, denn das Ganze ist beim Vorveröffentlichungs-Test einer App passiert.

Exkurs

Kleiner Exkurs über Speicher unter Java?

Nein … nur ein klitzekleiner, das Thema ist so groß, dass es gerade nicht in meinen Arbeitsspeicher passt.

Beim Start müssen wir der virtuellen Maschine von Java einen gewissen Spielraum einräumen – Speicher, der dann dem Programm zur Verfügung steht, sei es für Bytecode oder Objekte (es ist wirklich kompliziert). Der Garbage Collector ist ja einer der Hauptgründe, Java zu verwenden, weil er die Entwicklung so schön einfach macht. Programmierer müssen sich keine Gedanken darüber machen, wann sie ihre erzeugten Objekte wieder wegschmeißen müssen. Der Preis ist natürlich, dass der Garbage Collector Rechenzeit verbraucht – und das kann beim Verzicht auf Optimierungen durchaus merkliche Auswirkungen haben.

Zu viel Dingsbums

Beispiel Spiele: Normalerweise besitzen Spiele einen Renderer, der 30 mal pro Sekunde (oder öfter) den Bildschirm neu zeichnet. Da normalerweise bewegliche Dingsbums mit von der Partie sind, müssen Berechnungen stattfinden. Zum Beispiel sind Vektoren zu addieren, etwa so:

Vector3 newLocation = new Vector3(move(dingsbums,oldLocation,timePassed));
drawAt(dingsbums,newLocation);

Die erste Zeile erzeugt ein neues Objekt (newLocation) auf dem Heap. Am Ende der Zeichenfunktion ist es überflüssig, d.h. der Garbage Collector wird es irgendwann wegräumen. Jetzt stellen Sie sich vor, dass deutlich mehr als ein Dingsbums auf dem Bildschirm ist. Alle müssen sich bewegen, für jedes entsteht ein neues Vector3-Objekt, und das 30 mal pro Sekunde. Sie können sich leicht ausrechnen, wie viele Objekte der Garbage Collector letztlich aufzuräumen hat. Schlimmstenfalls macht sich das als Ruckeln bemerkbar, auf jeden Fall verbraucht es Prozessorzeit und damit Energie (also Akkuladung).

Besser ist es also, Objekte wiederzuverwenden. Dingsbums sollte über einen permanenten Vector3 verfügen, nur dessen Koordinaten (vielleicht native floats) ändern sich noch:

move(dingsbums,timePassed);
drawAt(dingsbums.getLocation());

Profilieren

Sie können mit Android Studio im Profiler genauso wie mit Java-Tools wie jmx die Aktivität des Garbage Collectors verfolgen. Ein guter Hinweis ist ein zackiger Sägezahnverlauf der Speicherbelegung. Wird der GC sehr oft aktiv, deutet das auf Optimierungspotenzial hin. Der Profiler zeigt dann an, in welchem initializer besonders viel Zeit draufgeht – damit wissen Sie, welche Objekte womöglich zu oft erzeugt werden.

Bekanntlich beträgt der Anteil der CO2-Ausstoßes der IT weltweit mit ihren ganzen Rechenzentren geschätzt 10-20%. Je effizienter Ihre Anwendung arbeitet, umso weniger ist sie daran schuld. Klingt vielleicht banal, aber nicht wenn Ihre App auf Milliarden Smartphones installiert ist und milliardenfach verwendet wird (und das wollen Sie doch, oder?).

Mehr zum Thema Speicherverbrauch und Effizienz in naher Zukunft und in der nächsten Auflage meines Buchs “Besser coden”.

Schriftarten in Android

Jeder, der schonmal eine Urkunde für seinen Zimmeraufräum-Weltmeister (6-jähriger Sohn) designt hat, weiß, dass man da mit Times New Roman und Arial keine Begeisterung auslöst. Auf 1001freefonts.com gibt es deutlich mehr als 1001 Schriftarten – aber wie kriegt man die in seine App?

Wer schonmal im Layout-Editor in Android Studio etwas herumprobiert hat, wird zumindest auf das hier gestoßen sein:

So weit, so langweilig – mehr als diese vier einfachen Varianten lassen sich hier nicht auswählen. Sie können nicht einfach einen Truetype-Font in irgendein Verzeichnis legen und dessen Namen hier hinschreiben. Wie geht’s also sonst?

Tatsächlich gibt es eine klassische Methode und eine neuere, die ich Ihnen hier kurz zeige.

Typefaces aus Assets

Die klassische Methode klappt nicht ohne Code. Dazu legen Sie zunächst die gewünschte Schriftart im TTF-Format ins Verzeichnis assets/fonts. Damit sorgen Sie dafür, dass die Schrift in Ihr APK eingebaut wird. (Der Verzeichnisname fonts ist willkürlich, Sie können ihn auch irgendwie nennen.)

An dieser Stelle eine freundlich gemeinte Warnung: Es sieht nicht nur unprofessionell aus, wenn Sie auf einem Bildschirm 10 verschiedene Schnörkelschriften verwenden – es kostet auch Speicher und Rechenzeit. Achten Sie darauf, nicht zu viele und nicht zu komplexe Schriften zu verwenden. Letzteres erkennen Sie an der Größe der TTF-Datei.

Und noch eine Warnung: Viele im Netz auffindbare Schriften verfügen nicht über deutsche Umlaute. Und die wenigsten bieten Unterstützung auch für ausgefallene Zeichen. Wenn Sie ohnehin keine fremden Schriftsysteme oder Sprachen unterstützen wollen, können Sie das getrost ignorieren – bedenken Sie aber, dass ein griechischer Nutzer Ihres Spiels beim Eingeben seines Namens für Ihre Online-Highscore-Liste möglicherweise griechische Zeichen verwenden möchte. Wenn Sie dem zugehörigen EditText eine Schriftart ohne griechische Buchstaben zugewiesen haben, sieht der Nutzer bloß kleine Rechtecke.

Genug Warnungen, kommen wir zum Programmcode.

Die Schriftart eines TextViews (oder einer Ableitung davon, wie Button) setzen Sie wie folgt:

textView.setTypeface(typeface);

Das zugehörige Typeface-Objekt erzeugen Sie mit einer einfachen Create-Funktion:

Typeface typeface=Typeface.createFromAsset(am, path);

Dabei ist am der AssetManager Ihres Contexts, den Sie innerhalb einer Activity mit getAssets() erhalten.

Als Pfad path übergeben Sie den Dateinamen Ihrer Schriftart relativ zum Verzeichnis assets.

Schriften per FontFamily

Die moderne Variante funktioniert ohne Code. Font-Definitionen per XML wurde in Android 8 eingeführt und funktioniert dank Rückwärtskompatibilität per AndroidX bis hinunter zu Android 4.1 (API 16), was für ungefähr 99% der verwendeten Geräte auf der Welt genügt.

Nunmehr gehören Ihre Schriftartdateien ins Verzeichnis res/font.

Diese referenzieren Sie einfach im TextView-Attribut fontFamily:

Es lassen sich außerdem FontFamilies definieren, so dass für fette oder kursive Schrift automatisch die passende Schriftartdatei zum Einsatz kommt. Mehr zu Fonts erfahren Sie in der offiziellen Dokumentation:

https://developer.android.com/guide/topics/ui/look-and-feel/fonts-in-xml

Delphi: Unkaputtbar

Kürzlich wurde ich gefragt, ob ich denn Pascal beherrsche. Nun, diese Sprache hat mir mein Informatik-Lehrer in der 9. und 10. Klasse beigebracht, das war so anno 84/85. Dergleichen vergisst man genausowenig wie die Musik, die man damals gehört hat, und die teilweise so ähnlich klang wie prozeduraler Code. Natürlich hat sich seitdem einiges verändert: Ältere von uns erinnern sich bestimmt an die “Delphi-Epoche”, in der so ziemlich jede Free- oder Shareware für Windows mit Borlands praktischer RAD-IDE gebaut wurde.

Aber nicht nur das: Viele mittelständische Unternehmen verwenden immer noch Delphi-Software, weil es schlicht viel zu aufwändig wäre, sie neu zu schreiben, und – nun ja, sie funktioniert ja. Delphi kommt inzwischen von Embarcardero. Es gibt eine kostenlose Community Edition 10.3 des RAD Studio, das immer noch so funktioniert wie vor Jahrzehnten und das Versprechen des “rapid application development” auch hält: Die UI wird mit der Maus gebastelt, heraus kommt am Ende ein 32- oder 64-bittiges Binary, das (mit verlinkten Laufzeitbilbiotheken) sofort auf jeder Windows-Kiste läuft. Inzwischen wurden zig Features, die man zuvor immer nachrüsten musste, integriert, zum Beispiel Git/Subversion, unzählige Komponenten für HTTP, REST, Xml, Gestensteuerung und auch Must-haves wie Refactoring.

Delphi 10.3 Community Edition: Retro-Programming für die kleine UI-Anwendung zwischendurch

Natürlich würde niemand heutzutage ein neues Projekt mit Delphi beginnen, oder? Es muss ja immer gleich eine Webanwendung sein, deployed auf zig Kubernetes-Clustern, Amazon freut sich dann über die AWS-Kosten. Dafür gibt es natürlich gute Gründe (zum Beispiel kann man jederzeit Updates durchführen, ohne dass der Kunde irgendetwas tun muss), und die meisten Menschen, die Pascal sprechen, sind ihrer Rente näher als dem Abitur. Woher sollte man solche Entwickler also auch nehmen?

Da es mit FreePascal/Lazarus auch eine freie Alternative gibt, ist die Zukunft von Pascal gesichert. Sauber programmieren kann man auch mit dieser alten Sprache. Wenn man nicht alles in seine TForm-Klassen stopft (wozu Delphi ja leider ermuntert) und das Single-Responsibility-Prinzip achtet, wohlgemerkt. Delphi unterstützt auch Linux und inzwischen sogar Android und iOS. Ob es eine gute Idee ist, eine App in Pascal zu schreiben, wage ich nicht zu beurteilen, falls jemand sachdienliche Hinweise dazu hat, immer her damit!

Wer’s mal ausprobieren möchte: Die Community-Edition erfordert nur eine kostenlose Registrierung und ist hier erhältlich.

Ganz ehrlich: Ich finde, dass sich Delphi unter Windows langsam und flackerig anfühlt. Die IDE assistiert mir bei weitem nicht so komfortabel wie die von IntelliJ oder VS Code (oder, okay, Opa Eclipse). Es wird nicht im Hintergrund kompiliert, so dass mein korrekter Code rot unterstrichen bleibt, bis ich explizit ein Build auslöse. Man ist ja verwöhnt …

Haben Sie auch Hacker in die Teeküche eingeladen?

Wichtige Mitteilung! Bitte auf keinen Fall kritische Sicherheitslücken in Exchange-Servern entfernen!

Sonst hab ich nix mehr, über das ich mich lustig machen kann.

Liebe Admins. Corona hin oder her: Kritische Sicherheitslücken, für die seit Februar Patches bereitstehen, und die einem Angreifer ermöglichen, Ihr System zu übernehmen, also quasi eine Einladung in die Teeküche Ihrer Firma – wo Sie sicher auch diverse Rechner ohne Passwortschutz herumstehen haben, nicht wahr? So sieht’s aus. Kommt, liebe Hacker, wir haben nix zu verbergen, wir brauchen unsere Daten nicht, verschlüsselt sie ruhig, unsere Vorstände zahlen auch gerne das Lösegeld, das ist immer noch billiger als Leute einzustellen, die sich ordentlich um die IT-Sicherheit kümmern.

Ach, und übrigens soll es auch Mail-Systeme geben, die ganz grundsätzlich weniger anfällig sind als jene von Microsoft. Und nix kosten. Open Source nennt man das, klingelt’s?

Weitere Infos beim BSI

IT-Expertennetzwerk Wetter (Ruhr)

Falls jemand fragt: Ja, ich bin Mit-Gründer des lokalen Netzwerks für IT-Experten in Wetter (Ruhr). Derzeit existiert es in Form einer Gruppe bei Xing. Sinn ist der Austausch unter lokalen IT-Experten zu beliebigen Themen, sei es Mitarbeitersuche, Know-How-Transfer oder Händeschütteln (letzteres erst wieder nach Corona). Wer Interesse hat, IT-Experte ist und entweder in Wetter wohnt oder arbeitet, kann sich gerne melden.

Alternative App-Bezahlmethoden werden endgültig verboten

Ja, Tante Google, kann ja schonmal vorkommen, dass man sich verschreibt, ist ja auch nicht schlimm, denn wir wissen, ja, dass ihr eigentlich schreiben wolltet: Bezahlung von unserem System vorbei wird komplett verboten, um UNSERE EINNAHMEN ZU SCHÜTZEN.

Im Klartext: Google will immer schon die 30% Gebühr einstreichen, denn wo kämen wir denn hin, wenn es da irgendeine Form von Konkurrenz gäbe, dann würde Google schließlich noch pleite gehen, und das wollen wir doch alle nicht, gell?

Für Android-Entwickler, die noch alternative Payments über Links auf Webshops o.ä. verwenden, heißt das: Bis 30.9.21 gibt es eine “extended grace period”, danach werden eure Apps aus dem Play Store geschmissen, wenn ihr die alternative Bezahlmethode bzw. Verlinkung darauf nicht rausnehmt. Unklar ist noch, ob auch schlichte Links auf die Homepage etwa eines Spiels verboten sind (wo dann wiederum ein Webshop aufgerufen werden kann). Ab dem 1.1.2021 müssen neue Apps der neuen Regelung genügen.

Nachhaltige Software

Neulich traten die hiesigen Bürgermeisterkandidaten zu einer Podiumsdiskussion an. Motto: Nachhaltigkeit.

Es ging um Mobilität, Wohnen, Teilhabe. Gut und schön, aber es gibt Aspekte, auf die Bürgermeister wenig Einfluss haben.

Zwei Beispiele:

Mein Acer-Laptop ist ein paar Jahre alt und war nicht ganz billig, er enthält zwei Grafikchips, einer spart Strom, einer zum Spielen. Leider unterstützt Windows 10 den besseren Chip nicht, der Hersteller hat natürlich auch null Motivation, einen neuen Treiber zu schreiben. Die Kiste ist also zum Spielen nicht mehr zu gebrauchen. Wer da die Abwärtskompatibilität abgesägt hat, kriegt von mir die verschimmelte Himbeere der Nichtnachhaltigkeit.

An meinem Arbeits-PC hängt ein ziemlich cooler (da ständig blau blinkender) WLAN-Stick von Asus mit toller Reichweite. Leider wird der enthaltene Chip von Linux-Kerneln ab 5.4 nicht mehr unterstützt. Würde ich also das (natürlich aus Sicherheitsgründen empfohlene) Update durchführen, müsste ich entweder Stunden in diffiziles Herumgefummel an komplizierten Treiber-Quellcodes investieren oder den alten WLAN-Stick wegschmeißen und einen neuen kaufen. Gerade Linux als Open Source-Betriebssystem sollte sich meiner Ansicht nach solche Fehler nicht erlauben. Die nächste verschimmelte Himbeere.

Verbunden sei dies mit dem Aufruf, nur dann auf Abwärtskompatibilität zu verzichten, wenn dadurch keine Hardware obsolet wird.

Nachhaltige Software ist möglich!

Warum KIs schlechter sind als ihr Ruf

KI hier, KI da – Autos sollen sie fahren, in der Medizin beraten oder gleich den ganzen Laden übernehmen. Wie schlecht Deep Learning dazu geeignet ist, zeigt sich immer wieder daran, wie leicht man eine KI überlisten kann. Letztlich vergleicht sie nur eine Eingabe mit immensen Mengen “gelernter” Daten und gibt eine Schätzung ab. Vor einiger Zeit habe ich hier einen Karton gezeigt, den eine KI mit sehr hoher Wahrscheinlichkeit als Nacktfoto identifiziert haben wollte.

Hier nun ein weiterer Test, diesmal mit how-old.net, einer KI von Microsoft, die “gelernt” hat, aus Fotos auf das Alter von Personen zu schließen.

Das Ergebnis schwankt offenbar abhängig von Brille und Gesichtsausdruck (also Faltentiefe) zwischen “ich fühle mich geschmeichelt” und “ok dann geh ich meine Rente beantragen”.

Wenn man sich einmal vage vorstellt, wieviel Entwicklungsarbeit und letztlich Daten- und Energieverbrauch hinter so einem Projekt steckt, muss man ernsthaft die Frage stellen, ob das nicht einfach nur groteske Verschwendung von Ressourcen ist. Nichts gegen Grundlagenforschung: Aber solche Ergebnisse sollten eigentlich nahelegen, dass Deep Learning vielleicht doch einfach zu dumm für die meisten ernsthafte Einsätze ist, und dass es vielleicht in vielen Bereichen doch die bessere Idee ist, menschliche Arbeitsplätze nicht vorschnell durch bräsige, CO2 produzierende Software zu ersetzen.