Category: C#

Early Adopters in Software Development Team

( You can find podcast audio description at my YT channel)

Experiencing concepts in action is truly transformative. Last week, I witnessed a fascinating dynamic unfold in my mentoring group, which is focused on application development and driven by Early Adopters.

We decided to tackle a project using a .NET MVC boilerplate and intentionally incorporated HTMX, a technology still gaining wider recognition. This combination, along with the classic ASP.NET MVC pattern, Entity Framework (allowing for both in-memory and SQLite database options), HTMX with the Razor engine, and just a touch of JavaScript, provided a genuinely complete full-stack development experience – something I could see fostering a holistic development approach within the group. Furthermore, showcasing their initiative and deeper understanding of security best practices, these Early Adopters even spearheaded the implementation of a robust authorization model, leveraging the built-in power of .NET Core Identity. What followed became a powerful illustration of everything we’ve been discussing, and honestly, solidified for me the critical role of these individuals in any tech endeavor.

Within my group, it was clear who the Early Adopters were. They naturally gravitated towards HTMX, recognizing its potential for streamlining development within the .NET MVC framework. Their understanding of the framework’s architecture and ability to see the potential of new technologies within this context was instrumental in driving the project forward. They weren’t just excited to use it themselves; they became the project’s engine, driving its forward momentum. What impressed me most was their proactive nature. They weren’t content to just code in their own corner. They willingly invested their time mentoring other members, patiently walking them through the nuances of HTMX and our architectural decisions. It wasn’t simply about finishing the project; it was about elevating the skills of everyone involved. Crucially, I realized a significant motivator for these Early Adopters was the ability to develop a working application rapidly. This tech stack enabled us to quickly bring ideas to life, allowing for swift experimentation and validation – a key driver for their enthusiasm.

The communication within the group, spearheaded by these Early Adopters, was exceptional. They fostered an environment of open inquiry and mutual support. No question was too fundamental, and knowledge flowed freely in both directions. I watched as the technical capabilities of the entire mentoring group demonstrably grew. Individuals who initially felt hesitant about HTMX rapidly gained confidence and competence, benefiting directly from these tech-savvy members’ hands-on guidance and patient explanations. The relative simplicity and rapid prototyping capabilities of this tech stack, championed by the Early Adopters, demonstrably lowered the knowledge adoption bar for the mentees. This, in turn, significantly boosted their faith in their abilities and their progress within the project.

Perhaps the most rewarding observation was the emergence of future leaders. Inspired by the initiative and collaborative spirit of the Early Adopters, a new cohort of skillful developers began to rise within the group. They weren’t just learning the technology; they were emulating the leadership qualities they witnessed – the proactiveness, the willingness to mentor, the clear and supportive communication. This was a clear sign of the positive impact of the Early Adopters, and it filled me with hope for the future of our group and our tech mentoring community.

This experience with my mentoring group sharpened my understanding of the importance of Early Adopters. They weren’t just an abstract concept; they were a lived reality that had a tangible impact on my mentees and our project. This experience made me think deeply about the broader implications of Early Adopters in the tech world.

Grandma might also be an early adopter in an unobvious customer segment (ready to leave the world behind). In my next article, You will read more about early adopters in the context of introducing new products to the market. Stay tuned!

Posted on by Tomek 1

I recently submitted two Pull Requests to the Official C# documentation.

Dive into sealed keyword and abstract class constructors.

I recently submitted two Pull Requests to the official C# documentation, and I’m excited to share the story behind them and what I learned in the process. These PRs stemmed directly from exercises on the Exercism.org platform in the C# path, followed by some great discussions in my C# mentoring group. While working through the exercises, I noticed that certain areas in the documentation could benefit from some updates and clarification, so I decided to contribute!

Let’s jump straight into the specifics of my contributions:

PR #1: Clarifying “sealed” for Overridden Methods

My first Pull Request (https://github.com/dotnet/docs/pull/44196) focused on improving the documentation for the sealed keyword, mainly when applied to overridden methods.

During our mentoring session, a question arose about preventing methods from being overridden further down the inheritance chain. We knew about the sealed keyword, but there was some confusion about its limitations, especially regarding methods inherited from the Object class, like ToString().

Here’s the key takeaway I clarified in the documentation:

You can use sealed to prevent further overriding of methods that your class has overridden from a base class, including fundamental methods like ToString(), GetHashCode(), and Equals() that are inherited from the Object class.

Why is this a big deal?

Every class in C# ultimately inherits from Object. This means they all get methods like ToString(). I discovered that you can seal overrides of methods inherited from the Object class in your class! Here is the sample from my Pull Request:

public class Animal
{
    public virtual string ToString() => "I'm an animal";
}

public class Dog : Animal
{
    public sealed override string ToString() => "I'm a dog";
}

public class Beagle : Dog
{
    // This will cause a compiler error!
    // public override string ToString() => "I'm a beagle"; 
}

This provides much finer control over method behavior in class hierarchies.

PR #2: Demystifying Constructors in Abstract Classes

My second Pull Request (https://github.com/dotnet/docs/pull/44223) delved into the sometimes confusing world of constructors in abstract classes.

Our mentoring group discussed abstract classes’ roles, and we realized the documentation regarding constructors could be more apparent.

Here’s what I aimed to clarify:

Even though you can’t directly create instances of an abstract class (they’re like templates), they can still have constructors! And what’s more, those constructors are often protected.

Why have a constructor in an abstract class?

It’s all about initialization. The protected constructor of an abstract class can be used to set up common properties or perform initial actions that all derived classes will need.

The crucial detail about derived classes and constructors:

My PR highlighted that when you define a constructor in an abstract class that takes parameters, derived classes must explicitly call that constructor using : base(). This is because C# does not automatically provide a parameterless constructor when you’ve defined any constructor yourself.

Here’s the example I used in the documentation:

public abstract class Shape
{
    protected string Color { get; set; }

    protected Shape(string color)
    {
        Color = color;
        Console.WriteLine("Shape constructor called");
    }

    public abstract double GetArea();
}

public class Square : Shape
{
    private double Side { get; set; }

    public Square(string color, double side) : base(color)
    {
        Side = side;
        Console.WriteLine("Square constructor called");
    }

    public override double GetArea() => Side * Side;
}

In this example, Square must call the Shape constructor using : base(color).

Default Parameter Values:

I also emphasized that even if you provide default values for the parameters in your abstract class constructor (e.g., protected Shape(string color = “red”)), that constructor will still be invoked when a derived class object is created, even if the call to base() is omitted. In this case, the default values will be used. This behavior ensures consistent initialization, even if the derived class doesn’t explicitly pass arguments to the base constructor.

Conclusion

These two Pull Requests, born from discussions in my C# mentoring group, helped solidify my understanding of sealed and abstract class constructors. I hope that by sharing these insights, especially the nuances about sealing overridden methods from Object and the behavior of default parameters in abstract class constructors, I’ve helped you gain a deeper appreciation for these C# features. Contributing to the documentation was a great way to learn, and I encourage everyone to get involved!

As always, feel free to ask questions in the comments! Happy coding!

Posted on by Tomek 0

Booker – how it started, where is going ?

Since 2021, I have mentored young adults – “high-school+” students.
My entire professional career is related to the Microsoft ecosystem, so I’m offering these young people my knowledge of .net + Azure, together with my leadership and business experience.

Pictures have been captured in the Fujitsu office over the past two years.
This is our second ‘Christmas Eve’. We meet every week during the school year- in the office or on the dedicated Discord server I run. Our team has changed slightly, but we are still growing together. We have finished learning C# programming on the Exercism platform and have moved on to project work. There is a yearly book fair at the Silesian Technical University, and the guys came up with the idea that the fair has the potential to undergo a digital transformation – from a “garage sale” to one based on an application that facilitates the search for textbooks and the linking of transaction sides-buyers with sellers. So we are writing such an application using .Net, Razor Engine + Htmx, Pico.css, and Sql Server. We plan to make a CI/CD on GitHub and select Azure Infrastructure as our hosting environment. The project called Booker can be found here.

What’s the deadline? From what I remember, it’s September. What will we learn from this implementation? Check this blog; I’ll keep you in the loop!

Posted on by Tomek 0