Attending WPC is always exciting. The audience is large, the rooms are big and well-equipped, the energy is just right, and there’s always a chance to catch up with friends and colleagues. I especially enjoy seeing fellow Microsoft MVPs and speakers.

As promised, here is a link to the repository with the code I demonstrated; just read the README to get your bearings. Oh, and as expected, someone in the audience got nerd-sniped by that cj bash function I mentioned.

The fine guys at ASP Italia just published the video in case someone is interested.

Yeah, it is in Italian. I got a transcript from MacWhisper and then asked Claude to translate and clean it up. It did a pretty good job, so let me know if there’s any interest in an English transcript; I might post it here.

Speaking of English, I’ve started submitting to international events again, without any luck so far. The conference landscape has changed quite a bit, especially since the COVID break. I still get invited to local ones, while internationals have been elusive. I suspect my change in technology stack plays a role. It was relatively easy to speak abroad when I was into Python. With .NET, not so much. But again, I was into Python in the pre-COVID era, so it is hard to tell which factors are at play and what their weight is.

I will use a Web API as an example project, and since I’ll be using curl live to query it, I’ll need to pipe responses through jq to obtain nicely formatted JSON for the audience.

The problem with jq is that it crashes on 400s or 500s because the response body is empty in those cases. Error responses are inherent to the demo, and crashes are not the most desirable thing during a presentation.

I cooked up a quick bash function that enhances curl and jq. It is called cj (curl + jq) and prevents crashes on errors, displays HTTP status codes with color-coded output (green for success, red for errors), and prettifies JSON responses.¹

As I fully expect someone in the audience to raise their hand and ask what the hell “cj” is, I’m posting it for reference so I can point them here if needed (Hi there!).

The function looks like this:

cj() {
    local response http_code body
    
    response=$(curl -s -w "\n%{http_code}" "$@")
    http_code=${response##*$'\n'}
    body=${response%$'\n'*}
    
    if [[ $http_code =~ ^2[0-9][0-9]$ ]]; then
        echo -e "\033[0;32mHTTP Code: $http_code\033[0m"
        echo "$body" | jq 2>/dev/null || echo "$body"
    else
        echo -e "\033[0;31mHTTP Code: $http_code\033[0m"
        echo -e "\033[0;31m$body\033[0m"
    fi
}

It currently sits at the bottom of my .zshrc file. I might turn it into a script in the future, but it’s probably going to be short-lived, so I’m happy with its current residence.

It’s pretty straightforward, but let’s break it down line by line.

cj() {

Defines a function named cj (short for “curl with jq”), which will wrap the standard curl command with automatic JSON formatting and colored output.

local response http_code body

Declares three local variables scoped to this function: response will store the full curl output, http_code will contain the HTTP status code, and body will hold the response body.

response=$(curl -s -w "\n%{http_code}" "$@")

Executes curl with the -s flag for silent mode (no progress bar), -w "\n%{http_code}" to append a newline and the HTTP status code at the end of the output, and "$@" to forward all arguments passed to the function. The entire output is captured in the response variable.

http_code=${response##*$'\n'}

Extracts the HTTP status code using Bash parameter expansion. The ##*$'\n' pattern removes everything up to and including the last newline, leaving only the status code. This is faster than using external commands like tail.

body=${response%$'\n'*}

Extracts the response body using parameter expansion. The %$'\n'* pattern removes the last newline and everything after it (the status code), leaving only the body content. This is more efficient than using, say, sed.

if [[ $http_code =~ ^2[0-9][0-9]$ ]]; then

Checks if the HTTP status code matches the pattern for success responses (2xx). The regex ^2[0-9][0-9]$ matches any three-digit number starting with 2.

echo -e "\033[0;32mHTTP Code: $http_code\033[0m"

Prints the HTTP status code in green color. The -e flag enables interpretation of backslash escapes, \033[0;32m is the ANSI code for green text, and \033[0m resets the color back to default.

echo "$body" | jq 2>/dev/null || echo "$body"

This one was fun. Attempts to format the response body as JSON using jq. If jq is not installed or the body isn’t valid JSON, stderr is redirected to /dev/null and the || operator triggers the fallback, which simply prints the raw body.

else
        echo -e "\033[0;31mHTTP Code: $http_code\033[0m"

For non-2xx responses (errors), prints the HTTP status code in red color using the ANSI code \033[0;31m.

echo -e "\033[0;31m$body\033[0m"

Prints the error response body also in red color, making errors immediately visible during the demo.

And that is all.

Why Aren’t People Going to Local and Regional In-Person Events Anymore?

For my latest presentation, I utilized the Slides Extended Obsidian plugin, which is based on reveal.js—an excellent option for keeping slide decks within one’s Obsidian vault (I keep all notes, work and personal journals, and knowledge in Obsidian.)

Marp could be a viable alternative to the plugin, as Obsidian notes are just markdown files. The advantage here is that I can further elaborate or iterate on my slides, for example, from the command line, as Marp comes with a dedicated CLI tool that lets you export to PDF, HTML, and more. Additionally, Marp is not based on reveal.js, a tool that has given me headaches in the past.

My understanding is that Marp is more geared toward producing “static” slides intended for PDF or other outputs (HTML included, though). In contrast, reveal-based solutions allow for more advanced features, such as animated slides, which I don’t like and use anyway.

I had intended to record the audio with the idea of transcribing it with MacWhisper and then publishing it here on my site, but I forgot to do so, which is a pity.

The session lasted almost two hours (I had thought it would take less time), during which I deviated somewhat from the script, using slides as a guide that were essentially an adaptation of the notes I had taken during my experiments. I showed the code for the MCP servers I created (stdio and streamable HTTP transports), demonstrated the various ways to link them with LLMs (Claude Desktop, Claude Code, and VS Code), and then shared my thoughts on the entire matter.

I received quite a bit of feedback, both in the room and afterward, when we moved to a pub where we stayed quite late by my standards, discussing AI, LLMs, and their impact on our daily work, which we can certainly define as significant, if not massive. Everyone uses LLMs’ UIs at their job to some extent, but very few are currently into agentic coding (the idea of a future session on that topic is tempting).

One remarkable tool that surfaced during the pub chat is Kotaemon, “an open-source RAG-based tool for chatting with your documents.”.

But the kicker was just before the session when, at the coffee break, an attendant approached me to shake hands and tell me he had known me for a long time because he discovered and used Eve in a research project he was working on years ago. As I recall, he had attended one of my Eve sessions at EuroPython, maybe in Berlin in 2014. As is often the case, he had no immediate need for my project and shelved it as “interesting, and cool that it’s by an Italian author, but I don’t need really it”. Then, a couple of years later, in a time of need, he recalled that little presentation of mine, and, long story short, Eve ended up being adopted by a big, unnamed corp or research institute. I thanked him from the bottom of my heart and told him it was worth preparing for the talk, waking up at 4 am and travelling to Rome to meet him and hear his story. It’s moments like this that make it all worth it. Also, hearing such a Python story at a .NET event was unexpected.

Nothing gratifies me more than seeing my open-source work appreciated and actively used in the wild.

Special thanks to Fabio Spaziani and the whole DotNetCode team for accomodating for my “daily commuter from afar” special needs.

Exactly one year ago we were here, in this same room, at the same conference, presenting C# 12. Some of you in the audience were present back then. If so, please raise your hands. Twelve months later, here we are again, looking at a new version of C#. It’s the new normal; this has been happening, give or take, since the advent of .NET Core and C# 8 in 2019. Previously, C# had a new release every 2–3 years, so the release rate has doubled or even tripled recently. Is this good news? If you’ve followed forums or social media, you might have noticed some controversy about the topic. The main complaint is that the language is changing too quickly, “chasing trends,” with no valuable addition to its core.

Most of these complaints come from old-timers around my age (maybe even ten years younger because I’m seasoned) and have been in the .NET environment for many, perhaps too many years. There’s always a certain inertia, a form of resistance to change, especially when it’s rapid. But I’m seasoned enough to remember when complaints went in the opposite direction: back then, the .NET Framework (the historical, monolithic, Windows-only version) moved like a dinosaur while the world was racing ahead. New languages were blooming. Old competitors were evolving at double or triple the speed, constantly innovating, and—this is key—attracting hordes of developers. There was a critical moment when this attraction became so intense that more and more developers set aside .NET and C# to explore new directions. I know because I was one of them.

Around 2010–11, I was set to create a new, rather complex platform of REST services, and instead of reaching out for my usual .NET toolchain, I chose Python. That marked the beginning of an adventure that lasted years and included the unexpected release of some reasonably successful open-source Python projects. The reasons I decided to abandon .NET and C# were several—not least the frustration with the lack of transparency and a clear path for the .NET ecosystem, its languages, with oh-so-many frameworks enthusiastically presented and then abandoned, changes of direction, and above all, in my case, it all being closed source, which didn’t allow me to dig deeper and understand why certain things didn’t work as expected. I clearly remember when I was writing my first REST service in Python and realized that in this new ecosystem if I didn’t understand what was happening behind the scenes (in my case, with the Flask framework), I could quickly look at what was going on because the entire Flask source code, like Python’s for that matter, was available not only for consumption but it was also open to contribution. Coming from the enterprise closed-source world, it was an empowering sensation.

The discovery of Flask was an absolute revelation, not for its intrinsic features (which were great) but because it was just one of the many options. In Python space, there were dozens of web frameworks at varying stages of maturity. There was a choice and often many different approaches to solve the same problem. I could experiment freely and decide what was best for my use case. Not only was I facing a vast and diverse world, but I could also use the operating system I wanted. Linux was much less demanding, let alone less expensive, for deployment than Windows, and behold! I could use a Mac for development. Open-source, cross-platform, with a vast community not only adopting the language and the standard library but constantly forging new solutions, making them available to the same community, almost always for free. It was the way forward.

I envied that such a thing was unthinkable in my world. But unbeknownst to many, Microsoft was watching and taking notes. To the best of my knowledge, it was mainly the developers inside the corp —the dev team—who, glancing out of the ivory tower, began a campaign of internal lobbying, initially scattered and disorganized and later increasingly coordinated, which in turn led to endless meetings, discussions at coffee machines, and gradually, slowly and then more rapidly, to the advent of the .NET Core project. The metaphor of a snowball slowly rolling down a slope until it becomes an unstoppable avalanche perfectly applies here.

So, years after my departure (not an actual departure—I still worked in .NET for our legacy products), a new and unexpected .NET appeared on the scene. It was open-source, cross-platform, and open to external contributions. We could and perhaps should have a lengthy discussion on the openness to external contributions, but we can all agree that a revolution occurred and was historic in scale. At the same time, Microsoft opened up to other stacks, mainly because of Azure. I was shocked when I was proposed for a Microsoft MVP Award for my work on Python, not C#, at a time when Python had little to nothing to do with Microsoft. It made sense, as there was an urgent need to speak to developers outside its ecosystem—and perhaps even more so to those like me who had left: Hey, look, we’re back, we’re on track, and we’re not evil anymore.¹ 

And there I was, finding my old stack (which I secretly, I admit, considered only museum-worthy) back to relevance, competing on equal footing with the rest of the scene. The delay was costly, though. Even today, I meet colleagues who think modern .NET is just a new version, if not a simple rebranding of the Windows framework of old, and C# is more or less the same, way behind the new kids on the block. It’s a shame, and there are responsibilities. Some choices could have been bolder and more disruptive, starting with naming the new framework—but that’s another story.

Today, I create REST services with Minimal APIs on my Mac and deploy them on Linux via Docker at zero or near-zero cost, just as I would with Python, JavaScript, Rust, Go, or any other stack. The performance is far better than Python’s (C# REST services make circles around Python’s), and the toolchain is rich and powerful, especially around the command line, while many think .NET is still a GUI/Windows thing. Quick release cycles are essential to compensate for lost time (and there was lots of it) and stay on the cutting edge, sending a continuous signal that the platform is alive, thriving, and constantly expanding.

Aldus Manutius, the renowned Venetian printer and publisher of the Renaissance, adopted the Latin motto Festina lente, which translates to Make haste slowly or Hasten slowly. This paradoxical phrase encapsulates achieving careful, deliberate progress quickly and precisely, balancing urgency with caution. I feel that, consciously or not, the .NET team is on track with Manuzio’s goal: they iterate rapidly to achieve progress, balancing urgency with caution.

Nowadays, both .NET and C# focus on performance and while there’s room for growth, the current achievements are extraordinary. We’re competitive with most stacks, if not significantly ahead of them. Frequent, more minor C# releases allow for quick adjustments. Attentive developers adopt them continuously. Meanwhile, those who aren’t in a rush (probably most of Microsoft’s long-time customers, slow-moving conglomerates and the like) benefit from performance gains and technological advantages (multi-platform deployment!) at a low cost because, while the framework and language evolve, great effort is put into preserving backward compatibility. In most cases, migrating to .NET Core and newer versions of C# requires minimal effort.

C# 12 introduced two significant features: primary constructors and collection expressions, with the latter being predominant in terms of syntactic, semantic, and performance importance. They weren’t the only new features but certainly the key ones. C# 13 innovates further but subtly—there’s less syntax and more semantics, building on last year’s new features. The improvements may be less flashy but guide developers in the right direction, often ensuring better performance at zero cost, sometimes even without us having to do anything. As we shall see, it happens because in recent releases—let’s say the last two or three— features were introduced primarily to improve the framework, which is also written in C#. Our higher-level applications benefit from all of this. It is a pattern we’ll observe repeatedly throughout this presentation.

• I love collection expressions. Like primary constructors, collection expressions will see a significant adoption in the long run.

• Collection expressions introduce a new way to initialize common collection values in a terse, unified syntax.

• This is how we initialize collections today:

var x1 = new int[] { 1, 2, 3, 4 };
var x2 = Array.Empty<int>();
WriteByteArray(new[] { (byte)1, (byte)2, (byte)3 });
List<int> x3 = new() { 1, 2, 3, 4 };
Span<DateTime> dates = stackalloc DateTime[] { GetDate(0), GetDate(1) };
WriteByteSpan(stackalloc[] { (byte)1, (byte)2, (byte)3 });

Notice how the code is diverse depending on the type and the context. It is also verbose. Look at how we initialize an empty int array (second line); it’s lengthy and starkly contrasts with the previous line, where we initialize the same type with some actual values. In many situations, casting is needed; again, take a look at the WriteByteArray and WriteByteSpan calls.

• With collection expressions, it becomes like this:

int[] x4 = [1, 2, 3, 4];
int[] x5 = [];
WriteByteArray([1, 2, 3]);
List<int> x6 = [1, 2, 3, 4];
Span<DateTime> dates1 = [GetDate(0), GetDate(1)];
WriteByteSpan([1, 2, 3]);

We enclose items within square brackets, and that’s all. An empty collection is empty brackets. We can, of course, call functions or use variables.

• In many scenarios, the compiler will perform several optimizations. It can allocate the correct capacity or avoid copying data when unnecessary. The compiler can do that because the supported collection types are well-known and have been for a long time. We get these performance boosts for free when we switch to collection expressions.

• Let’s look at that WriteByteArray call. Let’s say that at some point, maybe months or years after it’s been used in many places, we decide to refactor the method and change the argument type from byte[] to int[]. We’d have to refactor the old-style caller to eliminate the casting, which is now an error. We don’t need to do any fix with collection expressions as they come with enhanced inference that will resolve the casting for us.

• On the first line, we’re initializing a new array (we aren’t calling a method with a signature), so with collection expressions, if we try to use var, it won’t work. In that case, we need to be explicit about the type.

• The spread operator allows us to insert variables and constants and to sort of “unroll” another collection within the new one, and it does so with optimal performance.

int[] numbers1 = [1, 2, 3];
int[] numbers2 = [4, 5, 6];
int[] moreNumbers = [.. numbers1, .. numbers2, 7, 8, 9];

foreach(var number in moreNumbers)
    Console.WriteLine(number);

It would be nice if lambdas were allowed in collection expressions, like in other languages (Python), but that’s not yet an option.

• What about custom collections? But let’s imagine I have built a LineBuffer class that inherits from IEnumrable<chrar>; it offers some custom features over its base class. I get an error if I try to use collection expression syntax on it. It is not a common .NET type, and the compiler doesn’t know how to go around it.

public class LineBuffer : IEnumerable<char>
{
    private readonly char[] _buffer = new char[80];

    public LineBuffer(ReadOnlySpan<char> buffer)
    {
        int number = (_buffer.Length < buffer.Length) ? _buffer.Length : buffer.Length;
        for (int i = 0; i < number; i++)
            _buffer[i] = buffer[i];
    }

    public IEnumerator<char> GetEnumerator() => _buffer.AsEnumerable<char>().GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => _buffer.GetEnumerator();

    // etc
}

// this causes a compile error
LineBuffer line = ['H', 'e', 'l', 'l', 'o', ' ', 'W', 'o', 'r', 'l', 'd', '!'];

• We can support collection expressions in our custom types, though. It’s a two-step process. First, we implement a builder method, then decorate the class (or struct) with a CollectionBuilderAttribute. The attribute maps our type to the builder method.

[CollectionBuilder(typeof(LineBuffer), nameof(Create))]
public class LineBuffer : IEnumerable<char>
{
    private readonly char[] _buffer = new char[80];

    public LineBuffer(ReadOnlySpan<char> buffer)
    {
        int number = (_buffer.Length < buffer.Length) ? _buffer.Length : buffer.Length;
        for (int i = 0; i < number; i++)
            _buffer[i] = buffer[i];
    }

    public IEnumerator<char> GetEnumerator() => _buffer.AsEnumerable<char>().GetEnumerator();
    IEnumerator IEnumerable.GetEnumerator() => _buffer.GetEnumerator();

    internal static LineBuffer Create(ReadOnlySpan<char> values) => new LineBuffer(values);
}

The official documentation says the builder must be named “Create,” but that’s false. We can name it however we want as long as it matches the attribute (it’s probably still worth adhering to the suggested practice.)

• Adding collection expression support to custom types is helpful in your codebase, even more so if you’re a library author.

• The syntax of collection expressions is symmetric with that of slicing and pattern matching, a nice touch that keeps the language tidy and coherent. Take a look at this pattern matching switch:

public Grade GPA => Grades switch
{
    [] => 4.0m,
    [var grade] => grade,
    [.. var all] => all.Average()
};

• Visual Studio, VS Code, JetBrains Rider and most other IDEs offer full support for refactoring old-style collection initializations to collection expressions.

• What about dictionary expressions? They are common in other languages (again, Python). When asked, Kathrine Dollard of the C# design team answered that they’re thinking about it, mostly trying to understand the best design, so there’s a chance that we’ll see dictionary expressions in the language in the future.

Also see: C# 12 Primary Constructors.

In a follow-up post, I plan to address Collection Expressions (done) and maybe “type any aliases”; this is about Primary Constructors.

• We can now add a list of parameters to a struct or class declaration. This way, we avoid writing an explicit constructor method, sparing us some boilerplate code.

• What I refer to as ‘primary parameters’ are unique in that they are in scope throughout the type definition; this means they can be used anywhere within the type.

public readonly struct Distance(double dx, double dy)
{
    public readonly double Magnitude { get; } = Math.Sqrt(dx * dx + dy * dy);
    public readonly double Direction { get; } = Math.Atan2(dy, dx);
    public override string ToString() => $"{nameof(Magnitude)}: {Magnitude}, {nameof(Direction)}: {Direction}";
    public double Dx { get; } = dx;
    public double Dy { get; } = dy;
}

• It’s important to note that primary constructor parameters are not class members; therefore, this. cannot be used on them. They can be considered static values, but unlike typical static values, they can also be used in non-static methods, offering a unique advantage (some black magic happens behind the scenes.)

• We no longer need to define and assign a type-level field; the compiler will do that behind the scenes when needed; if a behind-the-scenes backing field is unnecessary, it won’t be created.

• Primary constructor parameters don’t become properties and are inaccessible outside the instance. We can create properties to expose their values if needed. Record types are an exception. Constructor parameters become properties with records, and it makes sense because records are generally used as DTOs, whereas we want the option with class and structs.

• Secondary and parameterless constructors can be added to a primary constructor. They must invoke the primary, passing its values along.

public Distance() : this(0, 0) { }

• With primary constructors, we do not have a method body; how do we handle argument validation? One pattern is to perform validation at property assignation.

public string AccountID { get; } = ValidAccountNumber(accountID)
    ? accountID
    : throw new ArgumentException("Invalid account number", nameof(accountID));

public static bool ValidAccountNumber(string accountID) => accountID?.Length == 10 && accountID.All(c => char.IsDigit(c));

• I like this pattern because it brings property declaration and validation close to each other, making it easier to process and reason about the domain logic. When we perform argument validation in an old-style constructor method, we tend to separate validation and declaration, making it difficult to reconcile the two aspects, especially when we have hundreds of lines between constructor code and property declaration.

• Derived types can have a primary constructor, too; it must invoke the base class’ primary constructor.

public class CheckingAccount(string accountID, string owner, decimal overdraftLimit = 0) : BankAccount(accountID, owner)

• Old-style derived types can still derive from a primary constructor type; a regular constructor will invoke the base primary, as we’ve always been doing.

• Regarding inheritance, we can mix and match primary constructor types with old-style types, making it easy to refactor our libraries to use primary constructors. We know that adopters will have no problem deriving from our refactored types.

• Watch out for “nested captures” of primary parameter values in derived types. If both the derived and the base type capture them, and one (or both) change their captured values, we may end up with non-aligned instance values. Roslyn’s analyzer will raise a warning so we can fix our code or mute the alert with a pragma.

• Visual Studio and Visual Studio code offer built-in support for primary constructors (refactorings, etc.) That’s true for JetBrains Rider or any other IDEs leveraging Roslyn.

• The primary constructor’s original implementation dates back to C# 6 in 2015. It was publicly available in one of those version previews for a short period. Then, it was taken back to the drawing board, only to resurface with record types in C# 9 (?) and custom types in C# 12.

Also see: C# 12 Collection Expressions.

I am thrilled to have the opportunity to present at an international conference once again. On May 9th, I will speak at the ABP Donet Conf'24. My session, titled C #12: What’s New and Interesting, is on a topic I’m passionate about.

With the alignment of C# and Dotnet Core release cycles, the C# release cadence has increased (we’re on a yearly cycle now), while feature quantity has reduced for individual releases, which is good. The faster, smaller iterations allow for quicker course corrections, and introducing fewer new features makes it easier to embrace the changes.

The ABP Dotnet Conf'24¹ will be held online on 8-9th May; the lineup and agenda look great, so reserve a ticket before they are sold out, and see you there!

In the past few weeks, I have spoken about OAuth2 at two different conferences, and OAuth2 has been precisely the subject of my work for the past few months, and it still is now. It goes like this: I study and implement things, and while doing that, I say to myself, hey, this could be an exciting topic for other devs, too. I let the idea cool down for a few days, and then, if it still seems good, I start looking for a fitting call for papers. Magic happens if the proposal is accepted: I am forced to turn from a superficial connoisseur to someone close to a field expert. That’s the level of competence to aim for if one wants to talk publicly, especially on a technical topic.

Something new happened yesterday. As I was writing the OAuth2 documentation for the next iteration of our APIs, I realized I could reuse some of the material from my live sessions. In the talk, it made sense to dedicate a few minutes to explain the OAuth2 Authorization Code Flow, so I used Obsidian Canvas to draw two diagrams, one with a high-level view of the flow while the other would zoom into the details. I could now take the first one, streamline and simplify it, and then include it in our official documentation. And that’s what I did.

That presentation took a while to prepare, but the delivery was good. It took me to a new level of expertise, and part of that work landed in our product. It was all well worth the effort.

I am always particularly excited when I can present the stuff I’m currently working on. Being forced to share as I learn encourages me to go deeper into the topic to reinforce my comprehension and better explain it to the audience—a win-win situation.

While the Rome conference is free, if you are considering WebDay in Milan (you should), feel free to use my speaker coupon P-SPEAKER10 for a 20% discount. If you come to any, don’t be shy and come to say Hi!

It is in Italian¹ and you need to login in order to see it (sorry, I don’t have control over it.)

I presented on the same subject at a DevRomagna meetup a few months ago when C# 12 was in preview and still had several moving parts. Now that the final release is out, it will be interesting to return to the topic to consolidate my knowledge. I suspect that of the many reasons I challenge myself to speak publicly, enriching my knowledge is prevalent. As the adage goes, for learning a subject, nothing beats explaining it in front of a knowledgeable audience.

If you will attend the conference (you should!), remember to meet me and say hi!

Update: the session is now available online.

Drawing from my experience doing the whole thing in production, I’ll essentially be live testing a Blazor app, then take the entire thing to remote CI via GitHub Actions. In the process, I’ll show some of the issues we faced, share how we solved them, and offer some practices we adopted.

WebDay 2023 will be a hybrid event, with over 380 in-person attendees and almost 1300 registered for live streaming. After the exhilarating experience of being back on an actual stage at WPC a few months ago, I’m excited to speak once again in front of a real crowd.

independent, in-person developer conferences are hurting. Based on my own observation as well as talks with organizers and sponsors that I have come to know over the years, the average independent in-person event is still down 30-40% from pre-pandemic attendance levels. And often it seems to require massive discounts or even giveaways to get to this level.

And he offers an interesting theory on why that is:

My hypothesis is that we’ve bifurcated the audience somewhat. The folks that were there almost exclusively for the content have decided that they can do so more cheaply and efficiently online via virtual conferences or recordings. The folks that went for the networking as a primary driver, on the other hand, are largely eschewing online events as not fulfilling their needs. […] So ultimately what we are left with is a lower in-person audience and a lower virtual audience.

As a conference speaker and meetup organizer, I noticed that online events saw low attendance during the pandemic, and they still do today. When available, recordings partially compensate, but only in audience terms. The problem is online events are not conferences. ‘Conference’ originates from the late Latin “conferentia,” itself a derivative of “conferre,” a synonym for the collation of “bring together”¹. A conference is a meeting to discuss some topics. The get-together element is missing in online events, and networking is next to impossible (live chats and ‘virtual after-parties’ are just poor palliatives.) In my book, hybrid events are even worse, as live streaming and recordings discourage live attendance (at the DevRomagna meetups, we often get asked if live streaming or recordings will be available, and the answer is no - either we do live streaming - and we sometimes do - or we do an in-person event, but never a mix of the two.)

Going back to Brian’s musings, I think I subscribe to them. I am not sure attendance will ever get back to old numbers. I am afraid a good portion of those who were regulars became disaffected, and gaining their attention back is a hard gamble. YouTube and Twitch, I think, are phenomenal competitors, and the pandemic hiatus threw a ton of fresh new viewers at them.

PS: Coincidentally, we’re running an in-person meetup at DevRomagna today.

Attendance was great and there was a lot of excitement up in the air; it was evident that people were happy to meet and interact in person again. After the forced two years hiatus, it was great to be back at a big on-site conference, let alone speak at it. I delivered my talk to a packed-full room of nodding, smiling and questioning attendees, which felt fantastic.

I think I’m satisfied with my delivery, although I managed to screw up a few things, most notably showing my Twitter password live (that was a funny moment)¹. I also forgot to mention a couple of things.

• I demoed CLI usage on Bash, but the kind people working on Playwright also provide full Powershell support; the website defaults to Powershell for their demo scripts;
• I never mentioned the obvious: as you’re testing your front-end application with Playwright, you’re actually performing a complete end-to-end test involving your backend. There is great value in end-to-end testing. Several times we caught subtle things that weren’t a direct front-end issue but more the result of the interaction with the backend. And yes (thanks to the guy who asked), your testing environment must support the whole stack.

The slide deck contains most of the code and bash commands I demoed live on stage. It’s nothing too original; I reproduced the examples on the official website with a few variations and additions.

I had fun performing again in front of a real, live crowd. Perhaps the induced break, unexpected and undesirable for many reasons, did me good.

I’m looking forward to giving the same session in English sooner or later, but I should first win my laziness and start looking for exciting events with open CFPs. If you happen to know one, please let me know.

In 2021, FOSDEM was held online. I already mentioned how I miss live events. In that post, I also wrote:

Any conference junkie will tell you that she/he attends for the people first, and only then for the sessions themselves. At these events, the most exciting stuff happens in the corridors, usually during breaks.

At that FOSDEM seven years ago, I experienced one of those corridor moments. It did not really happen in a corridor, however.

I was at the Delirium Cafe one night, with my good friend (and exceptionally skilled Pythonista) Alessandro Molina at my side. Many other conference attendees were there, and we were all having fun doing what nerds do when they gather for a night in the pub. We were sitting at this big round table, me, Alessandro, and three other guys I did not know yet. We all started chatting, enjoying ourselves over a few rounds of tasty Belgian beer. In front of me was sitting this friendly, obviously brilliant (if a little shy) guy from Switzerland. At some point, I don’t remember why, we were talking about PyPy, and getting technical about it. This guy was giving me a rundown on the ins-and-outs of PyPy, and well, I was surprised at how profound his knowledge was. In passing, I said that Alessandro and I knew one guy from the core team, Antonio Cuni. Then I mentioned the original author of the project, Armin Rigo, I think complimenting him on that significant achievement. The guy in front of me nodded and then smiled at me. And then came this weird, jarring moment of silence. That’s when my friend Alessandro nudged me and whispered, “Hey man, that’s Armin Rigo sitting there. Right in front of you.” We all had a good laugh. The next round was on me.

It’s small moments like these that make attending (and presenting at) conferences worth it.

PS. I had all the hints—the brilliant guy from Switzerland who knows PyPy like the back of his hand. Someone wasn’t so smart on that night.

There are some clear advantages in going virtual, but the final result is a net negative. Any conference junkie will tell you that she/he attends for the people first, and only then for the sessions themselves. At these events, the most exciting stuff happens in the corridors, usually during breaks. A little story here. You might know that I run a motorcycle club. Well, the very idea of founding it was actually ignited by a corridor chat, few minutes after I delivered a session. Replicating this kind of in-person interaction online is, well, next to impossible.

As a speaker, I miss presenting live. A simple glance at the audience helps me assess how’s going and eventually adjust my talk direction. The Q&A session at the end? That is often a matter of eye contact and body language. Not to mention the “offline session” that follows if your presentation had any degree of success. With online delivery, that’s all lost.

Also, I suspect not many online attendees actually pay due attention, not compared to the same session presented in-person. I know that’s true for me. When I’m comfortably sitting at my desk, too many things compete for my attention. Every possible distraction is just one click away. And then there’s the family. And my cat, of course.

Speaking of attendance, I would not be surprised to find that many people who sign up for the event won’t actually show up. Again, I know because it happens to me all the time. The commitment I have to put in for attending an in-person conference is much higher, making it more likely that I will actually participate.

Organizers, on the other hand, are incredible. They do a fantastic job in attempting to provide an experience as close as possible to the real one. They are the true heroes of this kind of event. They always have been, even more so now that we’re forced to go virtual. Remember to always have a word of gratitude for your fellow organizer. She/he deserves that.

Alright, enough with the rambling. Here’s where I’m presenting next month:

• Python REST APIs for Humans at CloudGen 2021
• Introduction to F# and functional languages at Scottish Summit 2021

One significant advantage of virtual conferences is that anybody can take part no matter where she/he lives on the planet. So, maybe you will fancy join us?

Soprattutto ho rilevato una forte curiosità su MongoDB, un database non-relazionale verso il quale sembra prevalere un atteggiamento  di generale timidezza: “vorrei ma non oso”, insomma. Per quanto riguarda Flask direi che ormai, nel vasto firmamento dei micro web framework, è una stella che brilla di luce propria.

Per quanto riguarda le registrazioni video potete andare su YouTube o sulla pagina ufficiale di EuroPython (english track e italian track). Ammetto di essere più soddisfatto della versione inglese nella quale – complice anche l’esperienza italiana del giorno prima – credo di essere stato più sintetico ed efficace. Qui mi limito a proporvi le slide:

Ringraziamenti

Un immenso grazie ai ragazzi dello staff di EuroPython che veramente hanno fatto di tutto per rendere questa manifestazione un evento straordinario – e ci sono riusciti  (una settimana di talk su cinque tracce parallele, sprint, hands-on, corsi, cibo di ottima qualità e credo oltre 800 partecipanti).

Vi racconto un episodio giusto per darvi l’idea di quanto questi ragazzi, tutti volontari, si diano da fare e ci mettano passione vera. Nella sessione italiana ho ‘sforato’ (capita anche ai migliori, mi dicono!) e così mi son trovato a sorvolare su un certo numero di slide. Ebbene il mio talk manager e il suo assistente mi hanno proposto di loro iniziativa di tenere una sessione pomeridiana straordinaria per consentirmi di portare a termine la mia relazione. Non capita tutti i giorni, credetemi. Per mia fortuna gran parte delle persone che avevano assistito alla sessione mattutina sono poi tornate per quella del pomeriggio, altrimenti sai che figura!

Se siete pythonisti o vorreste diventarlo non perdetevi la prossima edizione di questo evento internazionale che, con tutta probabilità, si terrà di nuovo a Firenze l’anno prossimo.

Non sono molto soddisfatto della mia relazione: troppo da dire nel poco tempo a disposizione. Mi auguro di aver comunicato bene almeno un paio di cose:

• Ciò che oggi funziona alla grande domani potrebbe non funzionare affatto. Siate pronti a rimettere in discussione voi stessi e il vostro modello di business in qualunque momento.
• Non fatevi ingannare dai fatturati milionari sbandierati ovunque ai quattro venti. Ciò che conta davvero è quel che vi rimane in tasca.

Per una città come Ravenna questo BarCamp è una novità benvenuta e necessaria, come dimostrano gli stessi numeri ottenuti: 170 presenze in sala, 400 spettatori collegati alla diretta streaming, 26 relatori. Complimenti alla CNA per averci creduto accettando una sfida dai risultati non scontati. Grazie di cuore e complimenti vivissimi a Lidia Marongiu, che ha organizzato e diretto l’evento con tenacia e grande professionalità.

EuroPython è la conferenza europea di riferimento per il linguaggio Python. Si terrà anche quest’anno a Firenze, dal 2 al 8 luglio. Sono in programma molti interventi davvero interessanti, cosa che rende ancor più soprendente il fatto che i miei talk siano stati votati così tanto.

Date un’occhiata al sito ufficiale per saperne di più sulla conferenza (in questo momento è ancora possibile approfittare dell’offerta early bird per l’acquisto dei biglietti); maggiori informazioni sui miei interventi tra qualche tempo, quando sarà ufficializzato il calendario dei talk.