13. März 2019

A Coders Take on BREXIT: The Lupus Solution

Usually I avoid politics and that's what I also do in this post. No opinion, I am actually 50:50 anyway. I am enjoying the show. This is purely technical.

In short: EU article 50 is a timer. It can be cancelled and restarted any time. Just like the programming timers we know. So, the solution is exactly what we do in programming: cancel and restart.

On 4 December 2018, the responsible Advocate General to the ECJ published his preliminary opinion that "a country could unilaterally cancel its withdrawal from the EU should it wish to do so, by simple notice, prior to actual departure".

Meaning, that the UK can cancel Brexit any time. But the UK can also restart Brexit at any time again. There are no time limits, no grace periods, no rate limiting on article 50 cancelling and triggering.

That makes the solution obvious: send two letters to the EU back to back.
  • the first with the cancellation of the article 50 process,
  • the second with a new trigger of article 50. 
(In practice you would play it safe and leave one day between cancel and reset.)

The result would be (almost) the same as the already planned 2 year  transition period. The March 2019 date is only the legal departure date. for all practical purposes, the UK leaves 2 years later after the transition period (December 2020). Let's get rid of the transition period and call it a second article 50 process, another two years. Practical separation would then be March 2021, only 3 months later than already planned.

Just make a law in parliament to cancel article 50 AND trigger it immediately again. 

Gives you time for a referendum or a general election or just a good transition period. Anything you want. Gives you time and changes nothing. The move just gets rid of the threatening no-deal timer.

Bonus: an extension of article 50 requires the agreement of all EU members. But the cancel/restart-move can be done by the UK alone.

Bonus Bonus: 2 years transition is what the Brits wanted, but the EU wanted a clean end of year date. So they settled for 21 months. A simple timer reset makes that 24 months again. Owned!

The ECJ handed this solution to the UK. They know what they do. This was not an accident. They mean it. That's the way out. Just do what every programmer does with timers: reset.

_happy_resetting()

PS: it's clearly an exploit and a bit shady. But it's legal. The contract is not meant to be used this way. But many contracts are "stretched". What happened to "no bailout" in the Euro zone? Giving Greece money to be (maybe) payed back in 50 years, is a stretch. What happened to the "prohibition of monetary financing"? Ah, yes, The ECB buy government bonds not directly from he governments, but from the "secondary markets". The ECB so much that the "intermediate" banks are actually straw men, being paid to circumvent Article 123. Another stretch. So, contracts are stretched, if deemed necessary. All we have, unfortunately, is the written word. The written words allow it AND it's necessary.

PPS: If people ever wanted to make exploit proof contracts and laws, then they could ask the gaming industry for advice. They have thousands of specialists who make a living by preventing the exploitation of coded rules. If computer games as an example are too low for you, then ask IT security experts or turn to academics in the field of game theory, the study of mathematical models of strategic interaction between rational decision-makers.

PPPS: In the long run: if you can do it twice, then think n+1. We can do this every other year. Maybe the UK and EU get used to it. Gives the UK a feeling of independence. And that's what it's all about, anyway. Every two years, UK activates article 50 and cancels it two years later. In practice: every other year, Brussels receives a briefcase with 2 letters from London.

28. Februar 2019

Agile mit Super Powers

Superboys: Edict-Abhilekh on Pixabay
tl;dr Scrum Rollen superpowern: Scrum-Master mit agiler Technologie, Product Owner mit UX-Design, Visual-Designer mit Frontend-Programmierung.

In der realen Welt brauchen wir mehr Rollen, als die bekannten Rollen im Scrum: Scrum Master, Product Owner und Entwicklerin.

Außerdem gibt's da noch:
  • Tester, die Test-Ingenieure sein sollten, nicht Durchklicker, sondern Integration-Test-Entwickler und Test-System Managerinnen,  
  • Admins, früher Operator, jetzt Devops, also Devs mit Leidenschaft für Betrieb, 
  • Systemarchitektinnen, die sich oft aus den Entwicklern rekrutieren und auf jeden Fall aktiv in den Entwicklungsteam sein sollten, vielleicht organisiert in Communities of Practice, aka Chapters, 
  • UX-Designer, ständig ein bisschen gebraucht, denn bei jedem Feature mit Business-Value für Benutzerinnen ist UX wichtig, 
  • Visual-Designer, soll ja auch gut aussehen, oft zwischen mehreren Teams geteilt oder sogar extern bei einer Agentur oder beim Auftraggeber. Burst-artige Arbeitslast und deshalb immer in der Gefahr, die Entwicklung aufzuhalten. 
  • Produkt Managerin, die auch gewillt ist mit dem Agile-Team ins Eingemachte zu gehen und zusammen was umzusetzen. Phantastisch, wenn sie nicht aufhört bei Marktpotential/Marktbeobachtung und Anforderungen, sondern selbst die User Stories scheibt. 
  • Marketing, Vertrieb, Controlling, Management… sind auch nötig, damit was geht, schon klar.
Von den Entwicklerinnen verlangt man heute viele Fähigkeiten:
  • Frontend und Backend, jeweils mit ihren aktuellen (und schnell wechselnden) Frameworks, 
  • Unit Tests ohne Zeit-Overhead während des Codings "einfließen" zu lassen, 
  • Integration-Tests und GUI-Tests aufzusetzen und up-to date zu halten während sich UX Workflows ändern, 
  • Beherrschung von Continuous Integration/Deployment Systemen, 
  • Container und Orchestrierung, 
  • Virtuose Bedienung von Code Repositories für Quellcode, Pakete, Container (Stichworte: GitFlow, nuget/PEAR, Dockerhub). Nicht nur benutzen, sondern auch bereitstellen, intern und extern. 
  • Code Reviews und Refactoring
  • Code-Metriken
  • Kenntnis und Benutzung von Monitoring-Systemen für Alarm, Dashboard und KPIs, 
  • Clean Code, Design Patterns, Entwicklungsumgebungen und deren Extensions, 
  • Security (in Code, Libraries aus Repos?, Operating), 
  • Reliability-Engineering, 
  • Skalierung (Up and Out)
  • Konfiguration der APIs und GUIs diverser Cloud-Anbieter und Meta-Cloud-Services, 
usw.

Unter den Entwicklern gibt es Spezialisten für das alles. Aber nehmen wir ein Team von 7, (UX-) Designer, Tester, Admin (ähm, Devops), Frontendler, Backendrin (eigentlich sollen alle alles können, aber nicht jede die Microservices containerisiert ist ein CSS3-Wizard). Dann wird es langsam eng mit den oben genannten Spezialfertigkeiten. Coden sollen sie ja auch noch. 

Warum machen wir das alles?

Damit Features entstehen. Features, die User glücklich machen. Features entstehen durch Coding. Ohne Coding keine Features. Viel Coding - viele Features, wenn sonst alles stimmt.

Fragt man in der Retro "was hat dich in diesem Sprint vom Coden abgehalten?" - typische Antwort: "Meetings", aber auch immer öfter "Infrastruktur" und vor allem: Infrastruktur aneignen, neu lernen und verstehen. 

Ganz viel dieser Infrastruktur macht uns agil bzw. ist nötig für agile Arbeitsweise über Scrum/Kanban hinaus:  Continuous-*, Container, Cloud, Clean Code, Frameworks, Repositories…

Die Infrastruktur hat gemeinsam: Sie ist aufwändig für jede einzeln zu lernen, aber notwendig, und wenn erstmal gelernt, dann völlig OK. Aber bis dahin dauert es.

Deshalb:

Superpower #1: Agile-Coach mit agiler Technologie

Es könnte/sollte/müsste die Aufgabe des Scrum-Master sein, agile Technologien in das Team zu tragen, so wie auch agile Arbeitsweisen in das Team getragen werden. Natürlich soll die Scrum-Masterin nicht dauerhaft den Build-Server betreuen müssen (obwohl sie das kann, wenn sie mehrere Hüte aufhaben will/kann/soll). Es geht darum, dass der Agile-Coach das Wissen in das Team trägt, damit nicht immer wieder wertvolle Entwicklerzeit darauf verwendet wird, zu lernen, wie man einen KPI-gesteuerten Continuous Deploment Prozess konfiguriert. Und wenn wir schon dabei sind: Es ist auch die Aufgabe des Agile-Coaches, die Beschäftigung mit Clean-Code und Design-Patterns zu stimulieren, vielleicht sogar selbst zu schulen, zumindest aber die Seniors dazu zu bringen, dass sie ihr Wissen teilen. Aber dazu muss man wissen, was es zu teilen gibt. Sorry, liebe SMs aus dem Persönlichkeitscoaching, eine agil-technische Scrum Masterin macht das Team nicht nur glücklicher, sondern auch schneller, viel schneller. Und mit schnell kommt glücklich: Superpowered Scrum-Master.

Superpower #2: Product Owner mit UX-Design

Bei allen Features mit Business-Value für Endbenutzer ist UX wichtig. Coding ist dafür da, dass die Funktion funktioniert. Aber "glücklich" werden Benutzer durch gutes UX-Design. Ein Product Owner gießt die Kunden-/Benutzer-/Stakeholder-Anforderungen in User Stories. Bei fast jeder Story ist UX-Design nötig, zumindest Grundkenntnisse, besser umfassende. Eine gute UX-Designerin kann lernen, wie man User Stories schreibt und vielleicht sogar wie man mit Stakeholdern redet. Aber ob ein Product Owner UX lernt? UX-Design ist ein Beruf und gottgleiches User-Story Schreiben eine Berufung. Erst die klassische Ausbildung: gute Anwendungen entwerfen, dann die agile Spezialfähigkeit: User Stories und Kommunikation: Superpowered Product Owner.

Superpower #3: Visual-Designer mit Frontend-Programmierung

Da ist nicht viel zu sagen. Wenn die Visual-Designerin gut ist, wird die Anwendung schön. Wenn sie das, was designed wurde, auch umsetzen kann, ist es toll für alle. Sie muss das Design nicht an den Entwickler übergeben. Es gibt keine Rückfragen, keine Verzögerung, keinen Mind-Bruch. Sie kann beim Design gleich die technischen Randbedingungen berücksichtigen. Keiner muss der CSS-Sklave für die Designerin sein. Die Arbeitslast ist viel ausgeglichener, so dass man kann sich eine ganze Designerin exklusiv pro Team leisten: Superpowered Designer.

Superpower #4: Entwicklungsleiter mit Technik-Coach für Product Owner

Viele Product Owner kommen nicht aus dem technischen Bereich. Das ist gut so, um die Entwicklung mit dem Produktmanagement zu verzahnen. Auf der anderen Seite ist es von Vorteil, wenn die User Stories so geschrieben werden, dass sie 1. In die Gesamtarchitektur passen und 2. die Entwickler verstehen und machen, was gemeint war. Für beide Fälle ist es gut, wenn jemand den Product Owner bei der Formulierung der User Stories berät. Eigentlich sind die Entwicklerinnen die technischen Berater des Product Owners. Aber das kostet Entwicklerzeit, oft von allen. Deshalb bürden wir das lieber der Entwicklungsleiterin auf. Die Entwicklungsleiterin kennt die Gesamtarchitektur, die IT-Strategie und er versteht wie Entwickler denken. Sie schreibt nicht die Stories um. Nur der PO schreibt User Stories. Aber eine Entwicklungsleiterin kann durch Fragen den Product Owner dazu bringen, die Stories so zu schreiben, dass die Entwickler die Stories verstehen und dass sie in das Gesamtkonzept passen. Eine Stunde pro Woche und Team reicht, um die technische Qualität der User Stories deutlich zu verbessern. Gleichzeitig ist es das beste Steuerungswerkzeug der agilen Entwicklungsleiterin, ohne den agilen Prozess zu verletzen. 

Heute sind viel mehr Fertigkeiten nötig. Man muss Fähigkeiten zusammenlegen. Nicht nur bei den Entwicklern, denn die sollen entwickeln. Alle müssen mehr machen und mehr können als bisher. 

Niemand hat gesagt, dass Superkräfte einfach sind.

#SuperPoweredAgile

_happy_powering()

16. Dezember 2018

Kennzeichnungspflicht für Social Bots

Breaking News: Die Bundesregierung erwägt Kennzeichnungspflicht für Social Bots

Social Media Bots sollen sich zu erkennen geben und mitteilen, dass sie keine echten Menschen sind, sondern Automaten, die nur Meinungen multiplizieren. Sie sollen gekennzeichnet werden, damit Leser unterscheiden können, ob das eine Diskussion zwischen Menschen ist oder nur - meistens gegen Geld - Meinungen beeinflusst werden sollen. Das kennt man schon von Werbung, die gekennzeichnet werden muss, damit man sie von redaktionellem Inhalt unterscheiden kann.

Das ist sehr sinnvoll und richtig.

Und weil das so sinnvoll und richtig ist, wurde das schon mal vorgeschlagen. Vor ziemlich genau 10 Jahren: Bot Tagging.

Da hat sich schon mal jemand Gedanken darüber gemacht dass man Menschen (Chatter) in Chatsystemen nicht hinters Licht führen sollte indem man Bots programmiert, die sich als Benutzer ausgeben.

Es gibt Bots, die Werbung machen, Bots die unterhalten und heutzutage sogar Bots, die lügen und Fake-News verbreiten. Letztlich ist politische Beeinflussung durch Bots auch nur politische Werbung in einer besonders ansprechenden vertrauenswürdigen und damit hinterhältigen Form.

Da es so viele verschiedene Bot-Arten gibt, sollte es ein Kennzeichnungssystem geben, das mehr aussagt, als Bot JA/NEIN. Man will wissen
- ob der Bot kommerzielle Werbung macht oder politische,
- ob er der Unterhaltung dient oder eine Servicefunktion erfüllt,
- ob er jugendfrei ist oder - allgemeiner ausgedrückt: die Kennzeichnung braucht auch eine Altersfreigabe.

Schön wäre auch die Angabe eines Themas. Dafür bräuchte man eine Ontologie. Die müsste man sich nicht selbst ausdenken. Der Verweis auf ein bestehendes Verzeichnissystem würde reichen, z.B. Wikikedia-Begriffe als Vokabular oder etwas hierarchisches, wie das (leider eingestellte Open Directory Project oder hier).

Das alles steht in der "Virtual Presence Technical Note 5: Bot Tagging", weil wir bei Weblin das schon damals gesehen haben.

_happy_tagging()


23. November 2017

CSV im US Format im Excel öffnen (Komma statt Semikolon) - Systemsprache kurzfristig umstellen

tl;dr: Systemsprache kurzfristig umstellen. Powershell: "Set-Culture en-US" und zurück: "Set-Culture de-DE"

Man bekommt immer wieder mal CSV-Dateien im US-Format. Die enthalten Komma statt Semikolon als Trennzeichen. Ein deutsches Excel will das nicht anständig öffnen.

Was tun?

Man kann:
  • das CSV als Textdatei öffnen und "," durch ";" ersetzen (viel Spaß mit "," in den Daten)
  • das CSV in .txt umbenennen und im Excel importieren und dabei as Komma als Trennzeichen angeben
Oder: man stellt einfach kurz die Systemsprache um durch ein Powershell Kommando (Commandlet). 

So geht's:
  • Powershell öffnen
  • PS C:\> Get-Culture (liefert: de-DE)
  • PS C:\> Set-Culture en-US
  • CSV öffnen durch Doppelklick
  • PS C:\> Set-Culture de-DE
  • Powershell schließen (oder offen lassen, braucht man immer mal)
Voila, englisches (US) CSV importiert.

(Wenn man es jetzt als CVS speichert, hat man ein englisches CSV in ein deutsches konvertiert).

Kleine Verbesserung (vorherige Einstellung transparent wiederherstellen):
  • PS C:\> $c=Get-Culture; Set-Culture en-US
  • CSV öffnen/bearbeiten
  • PS C:\> Set-Culture $c
Oder man legt sich diese 2 auf das Desktop:
  1. Dateiname: EN.bat
    Inhalt: powershell.exe -Command "Set-Culture en-US"
  2. Dateiname: DE.bat
    Inhalt: powershell.exe -Command "Set-Culture de-DE"
_happy_converting()

19. Mai 2017

CSS Customize Visual Studio Online Task Board - Remove Columns And Make it Denser

I use Visual Studio Online task board a lot for Scrum projects. But I do not like how much screen space it takes primarily because of lots of empty space.

So, I remove the empty space:

  • I do not need the "To be tested" and "Testing" columns.
  • The cards could be smaller with less margins and paddings
That's it.

I use Tampermonkey to inject CSS into the page.

Just install the Tampermonkey Chrome/Firefox extension and use this script:

Before/After:



More info, less white (grey) space.

_happy_tampering()

PS: Once you have Tampermonkey you will see lots of opportunities to change the layout of web sites. You don't have to live with it. You can change it.

For example: a script which make visual studio build colors more pronounced to counter my red-green-color weakness:

5. Dezember 2016

JsonPath

Any time a piece of my software receives a JSON message it must dive into the JSON and extract parameters. Sometimes the JSON is deeply nested and parameters are buried inside arrays of objects of arrays.

I want to access these parameters quickly without dissecting the JSON by looping and if-ing through the layers. In other words: I want single line expressions to dive into JSON and extract values.

You can call it XPath for JSON, but a language integrated compiled way, which his much faster, than XPath and supported by Intellisense (autocomplete).

GitHub project: https://github.com/wolfspelz/JsonPath
NuGet package: https://www.nuget.org/packages/JsonPath

Example: extract the 42 from:

var data = "[ '1st', '2nd', { 'aString': 'Hello World', 'aNumber': 42 } ]"

... parse it:

var json = new Node(data);

... extract it:

int fourtytwo = json[2]["aNumber"];

Invalid keys do not throw exceptions. They return 0 (zero), "" (empty string), or empty list:

int zero = json[1000]["noNumber"];

Of course, you can foreach a dictionary (aka JS object):

foreach (var pair in json[2]) {}

And iterate over a list (aka JS array):

for (int i = 0; i < json.Count; i++) {
    string value = json[i];
}

You can even LINQ it:

json[2].Where(pair => pair.Key == "aNumber").First().Value

and:

(from x in json[2] where x.Key == "aNumber" select x.Value).First()

Now get me the 50 from this JSON:

var data = "[ { 
        aInt: 41, 
        bLong: 42000000000, 
        cBool: true, 
        dString: '43', 
        eFloat: 3.14159265358979323 
    }, { 
        fInt: 44, 
        gLong: 45000000000, 
        hString: "46"
    }, { 
        iList: [ 
            { jInt: 47, kString: '48' }, 
            { lInt: 49, mString: '50' }
        ], 
    }
]";

I can do it in a single line, no foreach no if:

var fifty = json[2]["iList"][1]["mString"];

Other people had the same idea years ago: http://goessner.net/articles/JsonPath/. But there does not seem to be a C#/.NET implementation yet. So here it is: GitHub, nuget.

_happy_jsoning()


26. September 2016

Scrum Gantt als Google Docs Sheet

Im letzten Post zum "Scrum Gantt-Chart" habe ich beschrieben was, warum und wie man aus Scrum-Daten ein Scrum-Gantt als Reporting-Tool erzeugt. Die Scrum-Planung ist weiterhin im Scrum-Backlog, aber das Management (allgemein: die Stakeholder) freut sich sicher über eine Roadmap im Gantt-Stil.

=> Implementierung das Gantt-Charts als Google Docs Sheet <=

Empfehlung:

  • Sheet kopieren: GoogleDocs => Datei => Kopie erstellen...
  • Das eigene Backlog im Eingabebereich auf der linken Seite einfügen
  • Datum "BaseDate" und "Today" anpassen
  • Zeilen und Spalten im Formelbereich an das eigene Backlog anpassen
  • Jede Woche eine neue Version machen und den Stakeholdern veröffentlichen
Wenn die Spalten des eigenen Backlogs kompatibel sind, ist das eine Sache von 2 Minuten


==> Google Sheet

_happy_sheeting(:-)