Roland Weigelt

Recently, I migrated a web API from .NET Core 2.2 to version 3.0 (following the documentation by Microsoft). After that, the API worked fine without changes to the (WPF) client or the controller code on the server – except for one function that looked a bit like this (simplified naming, obviously):

[HttpPost]
public IActionResult SetThings([FromBody] Thing[] things)
{
    ...
}

The Thing class has an Items property of type List<Item>, the Item class has a SubItems property of type List<SubItem>.

What I didn’t expect was that after the migration, all SubItems lists were empty, while the Items lists contained, well, items.

But it worked before! I didn’t change anything!

In fact, I didn’t touch my code, but something else changed: ASP.NET Core no longer uses Json.NET by NewtonSoft. Instead, JSON serialization is done by classes in the new System.Text.Json namespace.

The Repro

Here’s a simple .NET Core 3.0 console application for comparing .NET Core 2.2 and 3.0.

The program creates an object hierarchy, serializes it using the two different serializers, deserializes the resulting JSON and compares the results (data structure classes not shown yet for story-telling purposes):

class Program
{
    private static Item CreateItem()
    {
        var item = new Item();
        item.SubItems.Add(new SubItem());
        item.SubItems.Add(new SubItem());
        item.SubItems.Add(new SubItem());
        item.SubItems.Add(new SubItem());
        return item;
    }
    static void Main(string[] args)
    {
        var original = new Thing();
        original.Items.Add(CreateItem());
        original.Items.Add(CreateItem());


        var json = System.Text.Json.JsonSerializer.Serialize(original);
        var json2 = Newtonsoft.Json.JsonConvert.SerializeObject(original);
        Console.WriteLine($"JSON is equal: {String.Equals(json, json2, StringComparison.Ordinal)}");
        Console.WriteLine();

        var instance1 = System.Text.Json.JsonSerializer.Deserialize<Thing>(json);
        var instance2 = Newtonsoft.Json.JsonConvert.DeserializeObject<Thing>(json);

        Console.WriteLine($".Items.Count: {instance1.Items.Count} (System.Text.Json)");
        Console.WriteLine($".Items.Count: {instance2.Items.Count} (Json.NET)");
        Console.WriteLine();
        Console.WriteLine($".Items[0].SubItems.Count: {instance1.Items[0].SubItems.Count} (System.Text.Json)");
        Console.WriteLine($".Items[0].SubItems.Count: {instance2.Items[0].SubItems.Count} (Json.NET)");
    }
}

The program writes the following output to the console:

JSON is equal: True

.Items.Count: 2 (System.Text.Json)
.Items.Count: 2 (Json.NET)

.Items[0].SubItems.Count: 0 (System.Text.Json)
.Items[0].SubItems.Count: 4 (Json.NET)

As described, the sub-items are missing after deserializing with System.Text.Json.

The Cause

Now let’s take a look at the classes for the data structures:

public class Thing
{
    public Thing()
    {
        Items=new List<Item>();
    }

    public List<Item> Items { get; set; }
}

public class Item
{
    public Item()
    {
        SubItems = new List<SubItem>();
    }

    public List<SubItem> SubItems { get; }
}

public class SubItem
{
}

There’s a small difference between the two list properties:

• The Items property of class Thing has a getter and a setter.
• The Subitems property of class Item only has a getter.

(I don’t even remember why one list-type property does have a setter and the other does not)

Apparently, Json.NET determines that while it cannot set the SubItems property directly, it can add items to the list (because the property is not null).

The new deserialization in .NET Core 3.0, on the other hand, does not touch a property it cannot set.

I don’t see this as a case of “right or wrong”. The different behaviors are simply the result of different philosophies:

• Json.NET favors “it just works.”
• System.Text.Json works along the principle “if the property does not have a setter, there is probably a reason for that.”

The Takeways

1. Replacing any non-trivial library “A” with another library “B” comes with a risk.
2. Details. It’s always the details.
3. Consistency in your code increases the chances of consistent behavior when something goes wrong.

While working on a WPF control that handles some aspects of its (optional) tooltip programmatically, I wrote the following lines:

if (ToolTip is ToolTip toolTip)
{
  // … do something with toolTip …
}

This makes perfect sense and isn’t confusing inside Visual Studio (because of syntax highlighting), but made me smile nevertheless.

Explanation:

• The code uses the “is” shorthand introduced in C# 7 that combines testing for “not null” and the desired type with declaring a corresponding variable (I love it!).
• The first “ToolTip” is the control’s ToolTip property (FrameworkElement.ToolTip), which is of type “object”.
• The second “ToolTip” is the class “System.Windows.Control.ToolTip”.

Am 22. August halte ich im Rahmen des User Experience Bonn (UXBN) Meetups den folgenden Vortrag:

Fragen, Fragen, Fragen, …

Die richtige Frage zum richtigen Zeitpunkt kann Diskussionen über UI-Designs wertvolle Impulse geben. Dabei muss weder die Frage noch die Antwort besonders weltbewegend sein – ein kleines Stückchen vorher unbekannter Information verändert manchmal massiv den Lauf der Dinge.

In seinem Vortrag vermittelt Roland Weigelt, dass eine analytische Denkweise auch in den vermeintlich eher von Emotionen bestimmten Bereichen Design und User Experience ein wertvolles Werkzeug ist. Und damit es nicht zu trocken wird, geht es nebenbei um Problemlösung à la Indiana Jones, außerirdische Lebensformen und den Einfluss von Rallye-Streifen auf die Geschwindigkeit von Sportwagen.

Die Teilnahme ist kostenlos, wegen der begrenzten Teilnehmerzahl ist allerdings eine Anmeldung erforderlich.

Infos und Anmeldung auf http://uxbn.de/

tl;dr: If you use Visual Studio Code in your talk, please do the audience a favor, press Ctrl+K, Ctrl-T and choose the theme that best fits the lighting situation, not your personal taste.

Some people like “dark” UI color schemes, i.e. dark background with light text and icons. Others prefer black text on light background. Visual Studio 2019 comes with a light theme by default, Visual Studio Code with a dark theme. So, what is better?

As long you are on your own at work or at home, the answer is “whatever gives you the best experience”.

But as soon as you speak at a conference or a user group meetup, or maybe just in front of your colleagues, it’s no longer about you. It’s about what is best for your audience.

Source code is different from slides

When you are showing source code in a talk, you must find a compromise between the font size and the amount of text that is visible without too much horizontal scrolling. The result is usually a font size that is smaller than what you would use on a PowerPoint slide. That means that each character consists of far less pixels that either lighten or darken the screen. Which would not a problem per se, if we only had to care about the legibility of white text on dark background or black text on light background.

But source code is usually shown with syntax highlighting, i.e. as text that switches between a variety of colors. Because not all colors have an equal brightness, some parts of the source code can be much harder to read than other. This is especially true with dark themes, when the “dark” background does not appear as dark in the projection as intended, because of a weak projector and/or a bright room. The weaker contrast appears even worse when the colored text stands between white text – exactly the situation with syntax highlighting.

Care about legibility first

Proponents of dark themes cite the reduced eye strain when using a dark background. And they are right, staring at a bright screen in a dark room for a long time can be painful. On the other hand, first make sure the audience members in the back do not have to look twice because parts of the source code are hard to read.

Personally, in all the sessions I attended, I had more problems reading source code on dark-themed IDEs than I suffered from eye strain. Your experience may be different, of course.

Don’t theorize, test

When you set up your computer in the session room before the talk, not only check the font size, but also how well both dark and light themes are readable.

Fortunately, you can switch Visual Studio Code’s color scheme quickly. So, before your talk

• press Ctrl+K, Ctrl+T (or choose File > Preferences > Color Theme in the main menu)
• use the up/down cursor keys to select a theme (e.g. “Light+” or “Dark+”, Code’s default)
• and press Enter to use the theme.

Walk to the back of the room and look for yourself. And… be honest.

It’s not about “it ain’t that bad”

When you test your favorite theme in the room, don’t go for “it’s good enough” just because you like that theme. Switch to a different theme and make an honest assessment: Is “your” theme really better in this room, for this lighting situation? If not, choose another theme.

Thank you!

Emaroo is a free utility for browsing most recently used (MRU) file lists of programs like Visual Studio, Word, Excel, PowerPoint and more. Quickly open files, jump to their folder in Windows Explorer, copy them (and their path) to the clipboard - or run your own tools on the MRU items! And all this with just a few keystrokes or mouse clicks.

• Download Emaroo on www.roland-weigelt.de/emaroo

Emaroo vs. Icons

The May 2019 update for Visual Studio Code (version 1.35) features a new application icon. After installing the update, Emaroo will continue to use the old icon, though.

This is because Emaroo caches the icons of executables (as well as those of MRU files and folders) for a faster startup.

To get the new icon, switch to the “settings” page…

…and click “Refresh icons” in the bottom right corner:

Confirm you want to restart Emaroo…

…and the new icon (which is not exactly dramatically different) will appear after Emaroo has refreshed the icons:

Morton Nielsen wrote an article called “The future UWP” about the situation for desktop UI development in the Microsoft technology stack which I found very interesting.

The main takeaways (not actually surprising):

• A lot is happening/changing/developing and it will take some time until the future really becomes clear.
• Quote: “Whether you do WPF, WinForms or UWP, if it works for you now, continue the course you’re on”

Personally, I’ll stay with WPF for my desktop UIs. When .NET Core 3 comes out, I’ll dip a toe into porting my applications.

Emaroo is a free utility for browsing most recently used (MRU) file lists of programs like Visual Studio, VS Code, Word, Excel, PowerPoint, Photoshop, Illustrator and more. Quickly open files, jump to their folder in Windows Explorer, copy them (and their path) to the clipboard - or run your own tools on files and folders with custom actions!

• Download Emaroo on www.roland-weigelt.de/emaroo

About this Release

• Added: Support for Visual Studio 2019.
• Added: The “run or read” feature (Ctrl+R) now also supports “.lnk” files.
  Fixed: Single files not appearing in Visual Studio Code’s MRU list.

Am 10. Mai 2019 halte ich auf der dotnet Cologne 2019 einen Vortrag mit dem Namen “Kochrezepte für pragmatisches GUI-Design”.

Am 26. und 27. Juni bin ich in Nürnberg auf der Developer Week 2019. Am 26. Juni ebenfalls mit “Kochrezepte für pragmatisches GUI-Design”, am Tag darauf folgt dann der ganztägige Workshop “Von Null auf GUI – Design/UI/UX-Praxiswissen für Entwickler”.

Abstracts

Kochrezepte für pragmatisches GUI-Design

• Wie entscheidet man, was man sich von anderen GUIs abschauen sollte - und was nicht?
• Wie stellt man Daten in Formularen und Detailansichten geeignet dar, wenn man von der Fachlichkeit eigentlich keine Ahnung hat?
• Wie bändigt man GUIs mit vielen Funktionen?
• Wie sorgt man dafür, dass Anwender sich nicht von der GUI "ausgebremst" fühlen?

Diese und weitere Fragen beantwortet Roland Weigelt in seinem Vortrag. Am Beispiel konkreter Lösungsansätze bietet er einen generellen Einstieg in eine abstrakte und doch praxisorientierte Denkweise in "User Interface Patterns". Roland greift dabei auf seine langjährige Erfahrung in der Produktentwicklung zurück, wo Pragmatismus und Weitsicht gleichermaßen gefragt sind.

Von Null auf GUI – Design/UI/UX-Praxiswissen für Entwickler

Überall dort, wo kein ausgewiesener UI-/UX-Spezialist zur Verfügung steht, ist es umso wichtiger, dass auch Software-Entwickler grundlegende Kenntnisse in diesem Thema haben. Sei es, um die UI einer typischen Business-Anwendung von "schlimm" nach "brauchbar" zu verbessern. Oder auch, um eine informierte Entscheidung treffen zu können, was man sich von anderen UIs abschaut.

In diesem Workshop vermittelt Roland Weigelt Entwicklern ohne jegliche UI/UX-Vorkenntnisse Gestaltungsprinzipien des visuelles Designs, User Experience-Grundlagen sowie das Denken in User Interface Patterns. Und das stets mit einem Blick darauf, was in der Praxis mit begrenztem Budget machbar und tatsächlich hilfreich ist.

Vortragsteile und praktische Übungen wechseln sich ab, um das Erlernte in Einzel- und Gruppenarbeiten direkt vertiefen zu können.

Für diesen Workshop sind von Teilnehmerseite her keine Vorbereitungen notwendig. Einfach hinkommen, zuhören, mitmachen, Spaß haben und viel lernen.

Anmeldung

• dotnet Cologne 2019: Die Anmeldung startet am 20. März um 12:00. Die Kölner Community-Konferenz wird wie in den letzten Jahren wohl wieder in wenigen Minuten ausgebucht sein – kein Wunder bei Preisen von 35,- bis 65,- Euro für Privatpersonen bzw. 139,- Euro für Firmentickets.
• Developer Week 2019: Die Anmeldung ist bereits möglich, bis zum 9. April gelten noch Frühbucherpreise.