Zugegeben, 2020 war es sehr ruhig hier am Blog. Der Hauptgrund lag zum Einen in meinem Job, der hauptsächlich organisatorische und architekturelle Aufgaben bereithält und weniger Entwicklungsthemen und zum Zweiten ging meine Freizeit in das Thema Fotografie.
„Guten Rutsch ins neue Jahr 2021“ weiterlesenWarum Aufgabenlisten oft nicht funktionieren
Oft hat man mehr Aufgaben, als man sich merken kann. Damit man diese nicht vergisst, schreibt man sie auf eine Aufgabenliste. Richtig priorisiert und für den passenden Zeitpunkt vorgesehen, wird die Erledigung sichergestellt. Allerdings sind damit auch einige Fallstricke verbunden.
Wie meine eigene Erfahrung und ein Gespräch mit einem Freund gezeigt hat, bedarf der Umgang mit Aufgabenlisten sowohl einer gewissen Disziplin, als auch einer korrekten Verwendung.
„Warum Aufgabenlisten oft nicht funktionieren“ weiterlesenWie gehe ich mit Legacy Code um?
Niemand will mit Legacy Code arbeiten. Die Gründe sind vielfältig und nachvollziehbar, generell ist Legacy Code auch sehr uncool und häufig ist gar nicht klar, wie damit umgegangen werden soll.
Definition Legacy Code
Bei der Definition, was denn Legacy Code überhaupt ist, gibt es viele Meinungen. Oft wird darunter alter Code verstanden, oder Code, der von nicht mehr im Unternehmen befindlichen Entwicklern geschrieben wurde. In manchen Fällen wird auch der Sourcecode einer älteren Version als Legacy Code bezeichnet. Beliebt ist diese Bezeichnung auch für Code, deren Design/Architektur als nicht-optimal empfunden wird.
Ich sehe das viel pragmatischer und stimme diesbezüglich mit Michael C. Feathers überein: Er bringt es in seinem Buch Working Effectively with Legacy Code auf folgenden Punkt:
The main thing that distinguishes legacy code from non-legacy code is tests, or rather a lack of tests. (Michael C. Feathers)
Code ohne automatisierten Tests ist Legacy Code. So einfach. Dabei ist es vollkommen egal, wann der Code geschrieben wurde und wer das getan hat. Kann er nicht automatisiert getestet werden bzw. wird er es nicht, ist es Legacy Code. Punkt.
Legacy Code verringern
Mit obiger Definition ist es doch einfach, Legacy Code zu entfernen. Es gilt einfach Tests zu schreiben. Zahlreiche Bücher beschreiben zudem, wie man denn Legacy Code umbaut und getestet bekommt. Kaum ein Buch beschreibt allerdings, wie dies im “laufenden Betrieb” möglich ist.
Wir müssen Bugs fixen, Features implementieren, wir haben keine Zeit für zusätzlichen Aufwand.
Die Realität sieht dann aber oft anders aus. Häufig macht alter, ungetesteter Code in großen Mengen viele Probleme. Neue Implementierungen an einer Stelle führen zu Fehlern auf einer ganz anderen (natürlich völlig unerwarteten) Stelle. Die Probleme treten allerdings erst beim Kunden auf, wodurch Bugfixes dringend durchgeführt werden müssen, wodurch wiederum andere Arbeit liegen bleibt. So baut sich zusätzlicher Druck auf. Als Ergebnis werden Abkürzungen genommen, also weniger Wert auf ein sinnvolles Design gelegt, die Stabilität leidet. Die Software wird immer anfälliger und alle Beteiligten investieren immer mehr Zeit in “lebenserhaltende Maßnahmen”.
Wie kommt man nun aus dieser Abwärtsspirale heraus, wenn Zeit rar ist?
Ich sage es mal so: Nichts tun und auf zusätzlichen Aufwand herausreden, oder dass ein Testing gar nicht möglich ist, bringt definitiv keine Verbesserung. Im Gegenteil, es wird immer schlimmer. Man muss also Hand anlegen und aktiv an einer Verbesserung arbeiten.
Stete Verbesserung notwendig
Monatelanges Refactoring und das, über die Jahre, versäumte Aufholen von Tests wird (meist) nicht möglich sein. Kaum jemand akzeptiert (finanziell) monatelanges Entwickeln “ohne sichtbaren Output”. Was aber durchaus möglich ist: Für einen Bugfix können Tests geschrieben werden, gegebenenfalls ist auch ein Refactoring kleinerer Codestellen möglich. Das ist vielleicht nicht viel, macht aber eine Codestelle schon sehr viel sicherer.
Lebt das jeder im Team, gibt es über Monate hinweg viele neue Tests. Das Ergebnis ist eine verbesserte Stabilität. Natürlich ist der Anfang schwer und man glaubt nur durch ein großes Refactoring eine Verbesserung herbeiführen zu können. Die Macht von vielen kleinen Verbesserungen darf man nicht unterschätzen.
Nicht einschüchtern lassen
Vielfach werden diese kleinen Refactorings mit Tests nicht durchgeführt, da der Entwickler der Meinung ist, diese Änderung würde nichts bringen. Das mag durchaus so erscheinen, wenn man 100.000e oder gar Millionen Sourcecode-Zeilen vor sich hat. Aber nehmen wir ein kleines Rechenbeispiel:
Jeden Tag können für 200 Zeilen Code Tests geschrieben werden (um das Funktionieren von Bugfixes zu verifizieren). Das Team hat 5 Mitglieder. Dann sprechen wir am Tag von 1000 Zeilen getesteten Code – und das ist recht gering angesetzt. Grob hochgerechnet reden wir dann von 200.000 getesteten Sourcecode-Zeilen nach einem Jahr, oder ca. 13% der Software, wenn das Projekt in Summe 1,5 Millionen Zeilen Code umfasst.
Mehr getesteter Code bedeutet weniger Bugmeldungen == höhere Kundenzufriedenheit und mehr Zeit für wertschöpfende Maßnahmen.
Nun gut, man könnte nun behaupten, dass es ja 7,5 Jahre bedarf, damit die gesamte Software getestet ist. Das ist wohl wahr, vergessen werden darf jedoch nicht, dass für diese getesteten Stellen Fehler sofort aufgedeckt werden können und daher gefixt werden, bevor der fehlerhafte Sourcecode an den Kunden ausgeliefert wird. Wir haben also nach einem Jahr vermutlich um 10% weniger Fehlermeldungen von Kunden und entsprechend weniger Belastung. In dieser verbleibenden Zeit können entweder neue Features entwickelt werden (was dem Unternehmensergebnis direkt zuträglich wäre) oder aber vermehrt in die Stabilität der Software investieren.
Dass darüber auch die Kundenzufriedenheit gesteigert wird (und vermutlich eher weitere Aufträge nach sich zieht), versteht sich von selbst.
Neue Funktionen nicht ohne Tests
Für neue Funktionen sind verpflichtend (sinnvolle) Tests zu schreiben. Daher wird alles Neue schon testbar aufgebaut und die Wahrscheinlichkeit von durchgerutschten Fehlern ist gering. Zu Beginn ist durchaus etwas mehr Zeit für das Schreiben der Tests anzuberaumen. Der notwendige Aufwand verringert sich durch die aufgebaute Erfahrung aber sehr schnell.
Damit das wirklich funktioniert, muss der Aufwand für Tests mitgeschätzt werden. So kommt der Entwickler nicht zusätzlich unter Druck. Druck würde an dieser Stelle nur dazu führen, dass auch für neuen Code keine Tests geschrieben werden, wir also wieder in unser altes Schema verfallen.
Grundvoraussetzung
Entwickler sind am Ende einer langen Wertschöpfungskette. Dadurch ist der Druck besonders hoch. Vor allem, wenn schwerwiegende Probleme auftreten. Generell haben Probleme sehr schnell gelöst zu werden und Features müssen ohnehin sofort implementiert werden.
Damit Schwierigkeiten in der Stabilität, erhöhter Support-Aufwand und damit hohe “unproduktive” Kosten gesetzt werden können, muss die Entwicklung von allen unterstützt werden. Gerne werden für Probleme auch Workarounds gefunden, die den Kunden zwar befriedigen, für die eigene Software allerdings keine Lösung bringen und das Problem nur verschleiern, oder über die Zeit noch schlimmer werden lassen.
Natürlich ist dabei auch Geduld gefragt. Was über Jahre hinweg versäumt wurde, kann nicht in wenigen Tagen oder Wochen behoben werden. Erste Erfolge sind wohl Monate entfernt, aber sie kommen sicher und sind – das ist das Schlimme an dieser Geschichte – nicht sofort ersichtlich. Es sind die Probleme, die nicht mehr auftreten, aber genau deshalb werden sie auch nicht mehr wahrgenommen. Die produktiven Stunden nehmen allerdings zu und daran kann man eine Verbesserung durchaus messen.
Fazit
Legacy Code ist Sourcecode, für den keine automatisierten Tests bestehen. Es bedarf etwas Mut und Wille um Tests zu schreiben, notwendige Umbauten durchzuführen. Auch wenn dies mühsam und kaum schaffbar erscheint, selbst die kleinste Verbesserung ist eine Verbesserung. Viele kleine Verbesserungen werden über die Zeit zu einer großen Verbesserung. Es gilt also, einfach zu starten, so aussichtslos es auch erscheinen mag, denn nur so kann die Software überhaupt besser werden. Nichtstun macht alles schlimmer. Handle jetzt und sorge für Verbesserungen. Jede noch so kleinste Verbesserung hilft. Alle im Unternehmen sitzen im selben Boot.
Update 13.12.2020: Überarbeitung und Ausbesserungen
Erstveröffentlichung: 23.10.2016
Basteln mit dem Nachwuchs: NFC Tags programmieren
Mein Nachwuchs interessiert sich für Technik, Computer und alles was so dazu gehört. Natürlich wird gerne gespielt, aber schön langsam durstet es ihm nach mehr. Mit kleinen Projekten kann man Technik recht schnell näher bringen, vermitteln und Interessen ausloten.
Richtig gut kamen NFC Tags an. Diese sind für kleines Geld zu haben, aber es lassen sich damit ganz nette Projekte umsetzen.
Auf so eine NFC Chip können unterschiedliche Informationen gespeichert werden. Im einfachsten Fall handelt es sich dabei um einen Link, eine Wifi- bzw. Bluuetooth-Verbindung, eine E-Mail-Adresse oder Telefonnummer, einen Standort oder eine Anweisung, eine SMS zu senden oder eine App zu starten. Kommt das NFC-fähige Telefon mit dem NFC-Tag in Berührung, wird diese Aktion ausgeführt.
Um NFC-Tags zu lesen und zu schreiben ist lediglich eine Smartphone-App notwendig. Hierzu gibt es unterschiedlichste Apps. Eine der einfachsten ist der NXP TagWriter (Android, Apple).
Neben diesen Standard-Funktionen gibt es weitere Apps (z.B. die NFC Tools), die zusätzliche Funktionen unterstützen. So ist es damit möglich, Bedingungen zu setzen und beispielweise folgende Konfigurationen vorzunehmen:
- Smartphone auf lautlos stellen
- Flugmodus aktivieren
- Wenn Sonntag bis Donnerstag, Wecker für den kommenden Tag um 6:00 Uhr stellen
Das kann für viele ein guter NFC-Tag für das Nachtkasterl sein.
Viele weitere Möglichkeiten sind gegeben und laden vor allem auch zu experimentieren ein. Mein Bub hatte viele Ideen und einige davon auch gleich umgesetzt. Für Spaß war gesorgt und auch gelernt hat er viel.
Hinweis: NFC-Tags gibt es in unterschiedlichen Größen (Speicherplatz), mit und ohne Passwortschutz, als selbstklebender Sticker oder als Schlüsselanhänger.
Viel Spaß beim Experimentieren. Die Kids werden richtig Spaß daran haben.
MySQL-Queries mitloggen
Beim Microsoft SQL Server kann man SQL Queries recht einfach mitloggen in dem man mal schnell den SQL Server Profiler startet. MySQL bietet ein derartiges Tool nicht an, zumindest kann es die MySQL Workbench nicht. Dennoch kann man aber die abgesetzten Queries aufzeichnen.
So kann man beispielsweise alle Queries in eine Log-Datei schreiben:
SET global general_log_file='c:/Temp/mysql.log';
SET global general_log = on;
SET global log_output = 'file';
Das kann man dann natürlich auch wieder deaktivieren:
SET global general_log = off;
Weiterführende Informationen finden sich in der MySQL Dokumentation.
Cascadia Code: Neuer Font für Visual Studio Code
Microsoft hat einen neuen nichtproportionalen (monospaced) Font (für Visual Studio Code, Terminal etc.) veröffentlicht: Cascadia Code.
This is a fun, new monospaced font that includes programming ligatures and is designed to enhance the modern look and feel of the Windows Terminal.
Ich habe den Font getestet und finde ihn empfehlenswert. Und so kannst du ihn auch verwenden:
Installation
Öffne die Cascadia Code Releases. Klicke auf Cascadia.ttf und lade somit die Datei auf deinen Computer. Öffne den Font anschließend mit der Windows Schriftartenanzeige.
Links oben kann der Font nun via Installieren am System installiert und registriert werden.
Nun kann der Font in jeder Anwendung verwendet werden.
Font in Visual Studio Code ändern
Unter File > Preferences > Settings > Text Editor > Font kann der verwendete Font in Visual Studio Code geändert werden. Hierfür einfach im Feld Font Family einfach 'Cascadia Code', Consolas, 'Courier New', monospace eintragen. Um Ligaturen zu verwenden, ist das entsprechende Flag zu aktivieren:
Scratch – Kinder lernen programmieren
Ohne Computer läuft heute gar nichts mehr. Umso wichtiger ist es, zu verstehen, wie sowohl Computer, als auch die darauf laufende Software, funktionieren. Um dieses so wichtige Verständnis zu schüren, sollten schon Kinder mit dem Thema des Programmierens in Berührung kommen.
Dazu gibt es unterschiedlichste Werkzeuge. Eines, das ich – aus Erfahrung – sehr empfehlen kann, ist Scratch.
Scratch ist ein tolles Hilfsmittel für Neueinsteiger, vor allem aber Kinder und Jugendliche. Programme bestehen hier aus interaktiven Komponenten, die zusammengesetzt und mit “Leben” versehen werden können. Mittels unterschiedlicher Bausteine können die Komponenten bewegt werden, es ist möglich, auf Ereignisse zu reagieren oder aber auch Sound abzuspielen und vieles mehr.
Durch das Bausteinsystem werden Syntaxfehler vermieden. Statt Frust gibt es schnelle Erfolge und treiben zu weiteren “Spielereien” ein. Innerhalb kürzester Zeit können so zum Beispiel kleine Spiele entwickelt werden.
Kinder lernen so spielerisch einige Grundkonzepte der Programmierung kennen und können so in kurzer Zeit auf komplexere Sprachen umsteigen und sich weiterentwickeln.
Die Voraussetzungen für Scratch sind gering: Ein Computer und ein Browser werden benötigt. Die Entwicklung findet komplett im Browser statt. Die Programme können abgespeichert oder geladen werden und stehen so auch sofort zur Verfügung. Es kann auch offline entwickelt werden. Dazu steht Scratch-Desktop für Windows 10 und MacOS 10.13+ zur Verfügung.
Damit man nicht ganz alleine starten muss, gibt es auch eine große Community und zahlreiche Hilfen für den Einstieg. Vielleicht gibt es ja auch in deiner Nähe ein CoderDojo. Hier in Österreich gibt es das CoderDojo Linz und das CoderDojo Graz. Hier bekommt man Unterstützung, wenn man als Elternteil nicht ganz so firm in diesen Dingen ist.
Besonders hilfreich ist die Liste der Übungsbeispiele des CoderDojo Linz zu Scratch und HTML.
In diesem Sinne wünsche ich Happy Coding und interessante, lehrreiche Stunden mit dem Nachwuchs.
Fazit Zero-Follower-Strategie auf Twitter
In So ist auch Twitter wieder nutzbar habe ich meine Nutzungsstragie auf Twitter komplett umgestellt. Ich folgte niemanden mehr, sondern arbeitete ausschließlich mit Listen.
Das erste Monat war richtig gut. Ich nutzte Twitter weiterhin und arbeitete mit meinen Listen, es funktionierte wunderbar. Die Timeline war leer und ich wurde auch nicht durch Unnötiges abgelenkt. Das äußerte sich darin, dass ich beginnend mit dem zweiten Monat meiner Umstellung Twitter immer seltener nutzte. Nun sind es fast vier Wochen, als ich das letzte Mal etwas getweetet habe. Meinen Zweitaccount (@ne_photos für die Fotografie) hatte ich daraufhin wieder umgestellt (wenngleich auch sehr halbherzig). Aber so richtig schlägt Twitter bei mir nicht mehr ein. Oder anders gesagt: Es hat seinen hohen Stellenwert bei mir verloren. Das liegt aber sicherlich auch darin, dass ich meine Online-Kommunikation sehr stark verlagert habe.
In der nächsten Zeit werde ich wohl meinen Hauptaccount wieder umstellen und dem einen oder anderen wieder folgen. Den Zweitaccount werde ich nicht weiter bedienen, für zwei Twitter-Accounts fehlt mir schlicht die Muse. Da müssen meine Follower damit leben, dass die Themenbereiche bunt gemischt sind.
So long, man sieht sich: @norberteder
ASP.NET Core: DateTime bei der Serialisierung formatieren
Im Standard wird das Datum ISO-konform serialisiert (z.B. dueDate=2019-02-21T00:00:00). In manchen Fällen möchte man das Format ändern, oder aber beispielsweise nur das Datum übertragen. Hierfür bietet JSON.NET (welches bis .NET Core kleiner 3.0 die eingesetzte JSON-Library ist) eine sehr einfache Lösung:
public class JsonDateConverter : IsoDateTimeConverter
{
public JsonDateConverter()
{
DateTimeFormat = "yyyy-MM-dd";
}
}
Nun muss der Converter noch für die gewünschte Eigenschaft konfiguriert werden:
[JsonConverter(typeof(JsonDateConverter))]
public DateTime? DueDate { get; set; }
Ab nun wird das Datum im angegebenen Format serialisiert.
Ab .NET Core 3.0 wird JSON.NET nicht mehr als führende Library eingesetzt, die Integration bleibt jedoch als zusätzliches Package erhalten und JSON.NET somit weiterhin offiziell supported.
HttpContext in .NET Core nutzen
In vielen Fällen ist der Zugriff auf den HttpContext notwendig, sei es nur, um an die aktuellen Benutzerinformationen zu gelangen.
Dies gestaltet sich in einem Controller sehr einfach, da diese Basisklasse den HttpContext über eine Eigenschaft nach außen gibt.
public class DemoController : Controller
{
[HttpPut]
public IActionResult Put([FromBody] Audit audit)
{
ClaimsPrincipal principal = this.HttpContext.User;
if (principal.HasClaim(c => c.Type == "id"))
{
audit.ChangedBy = principal.Claims.First(c => c.Type == "userName").Value;
}
else
{
return BadRequest("error message");
}
// code goes here
return Ok();
}
}
Nun kann man diverse Aufgaben in eigenen Komponenten ausführen. Dort ist der HTTP-Kontext nicht verfügbar. Wie kann nun darauf zugegriffen werden?
Die Lösung besteht in der Verwendung des Schnittstelle IHttpContextAccessor in Verbindung mit der Dependency Injection, die .NET Core bietet:
public void ConfigureServices(IServiceCollection services)
{
// configuration goes here
services.AddHttpContextAccessor();
}
Bei Nutzung der Dependency Injection wird die Abhängigkeit nun bei Klassen, die das Interface IHttpContextAccssor als Konstruktor-Parameter erwarten, übergeben.
public class Auditor
{
private IHttpContextAccessor ContextAccessor { get; set; }
public Auditor(IHttpContextAccessor httpContextAccessor)
{
ContextAccessor = httpContextAccessor;
}
public void WriteAudit(T oldEntity, T newEntity)
{
var user = ContextAccessor.HttpContext.User;
// code goes here
}
}
Diese Klasse muss natürlich noch beim Dependendy System registriert werden:
public void ConfigureServices(IServiceCollection services)
{
// configuration goes here
services.AddHttpContextAccessor();
services.AddTransient<Auditor>();
}
Happy Coding.
Du willst mehr zu .NET Core erfahren? Hier lang.