Greg Young about Over-Engeneering

Bei Youtube bin ich über eine Keynote von Greg Young gestoßen. Link findet ihr darunter.

Die Session trifft einen der wichtigsten Punkte der Softwareentwicklung.

Nachfolgend einige Gedanken aufgegriffen, die mich schon länger beschäftigen und in dieser Session zur Sprache kamen.

Software ist Teil eines Ökosystems. Software wird implementiert um Problem lösen, aber nicht jedes!

90% Aufwand für ein 0,1% Feature ist Ineffizient. Software wird entwickelt um produktive Ergebnisse zu haben, und nicht zuletzt um Geld zu verdienen.

Nur allzu leicht wird vergessen, dass der Motivator eines SoftwareProjektes ein Business Case ist. Und Business bedeutet Riskmanagement. Kein Business ohne Risiko. Business bedeutet auch das man mehr Braucht als eine laufende Software. Wenn eine Software für Edge Cases manuelle  Eingriffe braucht ist das richtig, wenn sie wirtschaftlich sind.

Wenn der CEO einmalig Daten in einem bestimmten Format aus der Datenbank braucht und unsere Standardtools das Format zu   95% erfüllen ist es ok, wenn jemand diese Daten nachbearbeitet.

Es wird nicht in Tagelangen Aufwand ein Tool entwickelt, dasss nur  die restlichen 5 Minuten Arbeit automatisiert.

Das bedeutet nicht dass wir unsichere instabile Software schreiben sollen, sondern viel mehr dass  es Fälle geben kann und darf bei denen ein User , Administrator… eingreifen darf.

Hätten die GitEntwickler versucht ein MergeConflict freies DVCS zu entwickeln, dann hätten wir heute noch keins. So schön so ein System auch wäre, dieser anspruch hätte im Ergebnis nur zum Scheitern geführt.

Eine große Veränderung die stillschweigend passierte ist, dass wir SoftwareEntwickler, Architekten, CTO’s, CEOS,…. miteinander reden müssen.
Die besten Lösungen sind manchmal außerhalb der Softwareentwicklung.

Hieraus erfolgt auch die Verantwortung bewusst und nicht leichtfertig Features und Bugs auch mal zu streichen. Es ist verführerisch unliebsame Bugs oder Anforderungen als Ineffizient abzustempeln.

Erfolgreiche Firmen gehen bewusst und rational überlegt Risiken ein. Es werden bewusst ineffiziente Features und Probleme gestrichen und auch Lösungen ausserhalb der SoftwareEntwicklung gesucht.

Frei nach dem Zitat:

Perfektion ist nicht dann erreicht, wenn es nichts mehr hinzu zu fügen gibt, sondern wenn man nichts mehr weglassen kann.– Antoine de Saint-Exupéry, Terre des Hommes

 

 

Cancelation Token in ASP Core Middleware

In klassischen ASP MVC / Web Api Projekte konnte man als Parameter ein CancellationToken definierne, welches dann beim Aufruf automatisch injiziiert wurde.

Das Token wurde dann in den CancelState versetzt falls der Request abgebrochen wurde.

In ASP Core hat das nicht funktioniert . Bei StackOverflow wurde mir geholfen.

Über context.RequestAborted kann man sich ein Token ableiten.

CancellationToken CancellationToken => context?.RequestAborted ?? CancellationToken.None;

 

RX geänderte NuGet Pakete

Wer bereits Rx genutzt hat und sich wundert, kann sich gerade wundern, dass die Pakete nicht mehr verfügbar sind:

Auf der Nuget Seite steht:

The owner has unlisted this package. This could mean that the package is deprecated or shouldn’t be used anymore.

Allerdings gibt das Github repo Aufschluss. Das Paket ist nun als System.Reactive verfügbar.

The NuGet packages have changed their package naming in the move from v2.x.x to v3.0.0

  • Rx-Main is now System.Reactive
  • Rx-Core is now System.Reactive.Core
  • Rx-Interfaces is now System.Reactive.Interfaces
  • Rx-Linq is now System.Reactive.Linq
  • Rx-PlatformServices is now System.Reactive.PlatformServices
  • Rx-Testing is now Microsoft.Reactive.Testing

Lt. Dokumentation sind keine Breaking changes bekannnt.

Die Projekte werden wegen des entfernten NugetListings nicht mehr im VS NugetPackageManager angezeigt.

Allerdings kann man sie immer noch über die NugetPackage Console installieren:

Install-Package Rx-Core

Owin Middleware Cultures .net 4.6.1

In einem Projekt nutzen wir eine selbst geschriebene Owin Middleware, welche anhand der RequestUrl eine Culture ermittelt und diese setzt.

So ist z.B. MyDomain.de auf die culture de-de  und MyDomain.fr auf fr-fr gemappt.

Der Code ist sehr trival

 public override async Task Invoke(IOwinContext context)
    {
        var culture cultureFromUrl(context)
        Thread.CurrentThread.CurrentCulture = culture;
        Thread.CurrentThread.CurrentUICulture = culture;

        await Next.Invoke(context);
    }

Das hat auch sehr gut funktioniert bis der Code auf .net 4.6.1 geupdatet wurde.Seit diesem Moment wirkt sich die kultur änderung nicht mehr auf den restlichen Owinstack aus.

Ursache ist ein Feature, welches CultureÄnderungen eines Threads von anderen isoliert.

Sofern man nicht eine neue Strategie entwickeln will muss dieses Feature deaktiviert werden.

Um das zu erreichen kann man das Feature über ein Compatibility  Switch deaktivieren

   <add key=“appContext.SetSwitch:Switch.System.Globalization.NoAsyncCurrentCulture“ value=“true“ />

Hier noch der link zu dem Microsoft Connect Ticket und meinem SO post

Dieser Breaking Change ist etwas versteckt unter dieser URL Dokumentiert: https://github.com/Microsoft/dotnet-apiport/blob/master/docs/BreakingChanges/146%20CurrentCulture%20flows%20across%20Tasks.md

 

Artikel über ServiceStack

Auch wenn es hier im BLog leider etwas länger ruhig war, so war ich jedoch nicht untätig.

Um hier mal wieder etwas in Gang zu kommen nachfolgend ein Link zum Artikel Ein Stapel Wunder von Roberto Bez und mir in der dotnetpro. Dies ist  mein erster Artikel für eine Fachzeitschrift und bin schon sehr gespannt ob er den versierten Erwartungen der dotnetpro Lesern gerecht wird.

Weiterlesen

Neuer Video2Brain Kurs über Windows 8 von Gregor Biswanger

957_neu

Von Video2Brain gibt es schon länger einen Einstiegerkurs für die Windows 8 App Entwicklung. S. http://www.video2brain.com/de/videotraining/meine-erste-windows-8-app

Der Kurs hatte mir bereits gut gefallen, allerdings wurden viele Themen nur angerissen. Dieser erste Kurs war ca 3,5 stunden lang.

Nun gibt es den weiterführenden Kurs Windows Store Apps mit XAML und C# – Das große Training. Der Kurs kommt mit einem 11,5 Stunden Programm! und ist in gewohnter Weise auch auf dem iPad und Androidgeräten ansehbar.

Sehr schön finde ich, dass im dem Kurs bei den Windows 8 Grundlagen angefangen wird und man auch den Bogen gespannt bekommt was gibt es in Windows 8 und wie kann ich das selbst programmieren.

Auch bekommt man einen Eindruck davon wann man für RT Entwickeln sollte und in welchem Zusammenhang der normale Desktop steht.

Nachdem man ein erstes Gefühl bekommen hat was Windows 8 / WinRT wirklich bedeutet wird man zunächst über die Grundlagen des XAML Kurses geführt. Dieser Teil hat mir bei einigen anderen Kursen gefehlt oder war zu wenig ausführlich.

Somit ist man also auch nicht darauf angewiesen WPF / XAML Grundlagen zu haben sondern kann dem Kurs komplett von Anfang an folgen.

Man bewegt sich nun nach und nach durch alle Themen die bei der Entwicklung wichtig sind und bekommt gute Hinweise über bekannte Fallstricke.

Der Kurs wird mit zwei Themen die über die Grundlagen hinausgehen abgerundet. So wird zum Beispiel  gezeigt wird wie man  Windows Live über das SDK anbindet.

Übner ca 20 Minuten bekommt man auch einen guten WinRT bezogenen Einstieg in das MVVM Pattern.

Der letzte Teil erklärt an einem Beispiel wie man die eigene App letztendlich in den Store bekommt.

 

Fazit:

Der Kurs bietet einen schönen rundum Blick über alle wesentlichen Grundlagenthemen die man als Interessierter Entwickler benötigt. Es wird auch über den Tellerand geblickt und wichtige Themen die nicht direkt mit der Entwicklung zu tun haben aufgegriffen. So zum Beispiel das MVVM Pattern oder der Release Prozess.

Der Kurs erreicht auf jedenfall sein Ziel und holt den Zuschauer ohne Vorkenntnisse ab und führt ihn zu einem Wissenstand mit dem man ohne Probleme seine erste eigene Windows 8 App entwickeln kann.

Was ich mir allerdings noch etwas mehr gewünscht hätte wären weitere Alltagsthemen wie z.Bsp. „Datenhaltung mit SQLite“ gewesen.  Vielleicht wäre dann aber auch der Kurs zu umfangreich geworden, denn diese 11,5 Stunden wollen erst einmal gesehen und angewendet werden.

Velleicht bleibt ja die Chance auf einen weiteren „Windows 8 Development – In Depth“ Kurs.