Writings of Urda

The Pilgrim headed west.

The Pilgrim headed west, unaware he was answering a quiet call to duty. The Pilgrim began gathering their things as the villagers all around him watched. For all of the village knew that the west was a foreign land, a dangerous land, a land beyond their peaceful valley. The villagers continued to gather around the Pilgrim as he gathered his things.

“You might not ever return!”

“What if you get hurt along the way? What if someone tries to hurt you along the way?”

“How could you be so selfish to choose the needs of your ‘adventure’ over the needs of the village!”

“Do you not find this life enough?”

The Pilgrim continued to gathering his pack and supplies in silence, as if almost transfixed by a song or tune heard only to him, heard on the rising and falling winds of the far mountains. The people around him continued to grow frustrated, confused, and more emotional as the Pilgrim continued to quietly work. The people and crowd around the Pilgrim slowly faded into background noise, as he finally shoulders his assembled pack, and steps towards the village’s boundary.

“Are you insane? Have you lost your mind?”

“Why would you trade such a good thing going, for something that might not even be?”

“We have problems that need fixed here first, don’t you know?”

“How could you do this to your family?”

The Pilgrim was used to not being understood, how could they after all? An invisible strand, an ethereal voice, a magnetized charge pulled him further and further away from his village. It pulled him further, and further away from his people. It pulled him further and further away from the chanting of the ignorant crowd, as they faded into cosmic noise and radiation.

The Pilgrim placed his first step beyond the village’s wall. That first step felt like the entire world fell below him, as the stars of the cosmos rose from their hiding places to greet him on his path, as he finally realized this, he could begin his journey of understanding into the universe.

The Pilgrim headed west, across the golden plains, towards the evergreen ridges, upwards the snowy mountain tops, until his shadowy figure crossed the apex of the tallest mountain the villagers could see.

The Pilgrim headed west.

I bathed in the waters of the Pacific and I was born again. I was molded and perfected by the startup battlegrounds of San Francisco, my character and ability were put to the test at Amazon, and now I am building the road to space for future generations using everything I have learned so far.

This is my engineering story.

I am happy to announce I have launched my own Mastodon at urda.social/@urda and added an icon to the bottom of my website. You can follow me at @urda@urda.social from any Mastodon server.

Are you wondering what I have been up to? You should visit urda.com/projects and take a look.

Being able to drop certain chunks of code from one piece of software to another piece of unrelated software is a powerful thing. Not only does this save time, but it will also allow you to build a small library of tools you find useful in all your applications. Interfaces in C# is just one of many ways to build more modular objects that have similar behavior.

We are going to create an interface IHuman to build people objects from. Everyone can agree that all people have a First Name, Last Name, Age, and have some ability to speak. So we will wrap that up into a neat interface.

public interface IHuman
{
    string fname { get; set; }
    string lname { get; set; }
    int age { get; set; }

    void Speak(string input);
}

An interface is a very basic chunk of code in C#. It is like a checklist of objects and actions that all derived classes should have. The way each class handles each dimension of the IHuman will be unique to each class. So now we will create just a basic person object from the interface. I will then use Visual Studio to implement the interface, and this will be the result:

public class Person : IHuman
{
    public string fname
    {
        get
        {
            throw new NotImplementedException();
        }
        set
        {
            throw new NotImplementedException();
        }
    }

    public string lname
    {
        get
        {
            throw new NotImplementedException();
        }
        set
        {
            throw new NotImplementedException();
        }
    }

    public int age
    {
        get
        {
            throw new NotImplementedException();
        }
        set
        {
            throw new NotImplementedException();
        }
    }

    public void Speak(string input)
    {
        throw new NotImplementedException();
    }
}

As you can tell, you’ll need to go through each method and implement it for use. I simply took a moment to do some clean up, and added logic to my Speak method:

public class Person : IHuman
{
    public string fname
    {
        get;
        set;
    }

    public string lname
    {
        get;
        set;
    }

    public int age
    {
        get;
        set;
    }

    public void Speak(string input)
    {
        Console.WriteLine(input);
    }
}

Now I can build a simple program and declare a Person Object. Then I can set variables within the object and/or use any of the methods associated with it. Yet, I need another object to describe a programmer. Again, I’ll use the IHuman interface and make the needed changes to my methods. I’m also adding a custom method in this class as another way to speak.

public class Programmer : IHuman
{
    public string fname
    {
        get;
        set;
    }

    public string lname
    {
        get;
        set;
    }

    public int age
    {
        get;
        set;
    }

    public void Speak(string input)
    {
        string result = "";

        foreach (string s in input.Select(c => Convert.ToString(c, 2)))
        {
            result += s;
        }

        Console.WriteLine(result);
    }

    public void DudeInPlainEnglish(string input)
    {
        Console.WriteLine("Sorry my bad... " + input);
    }
}

If you pull the interface and two objects together, you can build a simple console application to prove this proof of concept:

static void Main(string[] args)
{
    Person MyPerson = new Person();
    MyPerson.fname = "John";
    MyPerson.lname = "Smith";
    MyPerson.age = 25;

    MyPerson.Speak(string.Format("Hello I am {0} {1}!",
                                 MyPerson.fname,
                                 MyPerson.lname));

    Console.WriteLine();

    Programmer Me = new Programmer();
    Me.fname = "Test";
    Me.lname = "Urda";
    Me.age = 21;
    string UrdaText
        = string.Format("Hey, I'm {0} {1}", Me.fname, Me.lname);

    Me.Speak(UrdaText);
    Console.WriteLine();

    Me.DudeInPlainEnglish(UrdaText);
    Console.WriteLine();
}

As you can tell the Programmer spits out binary when asked to speak, and it is only when you call the DudeInPlainEnglish method against it is when you get a readable format. The method also appends “Sorry my bad…” to the start of the print out.

If we only had access to the interface, we would know what properties and methods that each class must have when using said interface. Think of this interface as a type of contract, where each class that uses it must (in some fashion) use the properties and methods laid out. You can also think of an interface as a very basic framework for all involved classes.

So the next time you are working on a bunch of objects that are closely related to each other, consider using an interface.

When you create a basic WCF service hosted through IIS, you are greeted with a generic page informing you that “You Have Created a Service”. This is useful since it provides to the developer two critical pieces of information. First it lets you know that the service is up and running, second it provides basic code stubs to query the service with. While this may be fine for development, you might not want to display this page in production. Disabling it is not intuitive, but with some searching through the MSDN documentation I have found the preferred way of changing this page.

When you first setup a service, you’ll see this screen when you visit the service URL:

To disable the HTML “You Have Created a Service” page for your WCF services, simply add this XML inside your Web.config file as a child of configuration

<system.serviceModel>
    <behaviors>
        <serviceBehaviors>
            <behavior>
                <serviceDebug httpHelpPageEnabled="false"
                              httpsHelpPageenabled="false" />
            </behavior>
        </serviceBehaviors>
    </behaviors>
</system.serviceModel>

This block of XML will then cause the raw XML information to be displayed instead of the generic “You Have Created a Service” page. You can fine tune the behavior even more, so you may want to reference MSDN for more information.

So you have your program written out, and you have met all your goals. You are so confident that the program is ready, you rip out the debug statements and other debugging related functionality from it. You fire up the program and feed it the initial values and BAM nothing works! If only you kept the debug calls! Well you can avoid this in the future by using conditions in your code.

If you have ever worked on a complex C# application, you may have seen code such as the following:

#if DEBUG
debug.PrintStackTrace();
#endif

You would have these block in your program everywhere you made a call to the debug class. This adds extra lines to our source code, and can cause issues when you have to make changes to debug handling.

But there is a more elegant way of enabling or disabling debugging. We can add conditionals to our methods based on the build environment. So let’s say we have a debug class with the method named PrintStackTrace. This simply prints out some stack trace where ever it has been requested. Instead of surrounding each method call with #if and #endif we will add a line before our method in the debug class (look at the highlighted line):

// debug class...

[Conditional("DEBUG")]
public void PrintStackTrace()
{
    /* Method code would be here */
}

// Main, or other class...

/* And simply call it normally */
debug.PrintStackTrace();

So now all you have to do is make the call to the method when you like by simply building in DEBUG mode. When we switch to release, the code is stripped out and ignored as if it never existed. If you use the first method, you are adding at least two extra lines to every debug call in your program. This can rapidly increase the length of your source code. Instead the second method only costs an extra line before each method you are using for debugging. Plus, it looks a lot cleaner without all the #if/#endif statements!

There are a few situations where a C# structure will provided better performance than a C# class and other times a class will be faster than a structure. The reason for this is how C# is handling both of these in memory during program execution.

Let’s talk about classes first. A class in C# is a reference type. This means that C# creates references, or pointers, to values in memory for each part of the object. When you copy a C# class you are making a copy of the references to values in memory. Structures have a different behavior than this.

Structures behave like a value type much like an int or a bool. These types are based on values in memory directly, there are no pointers or references in between. These types are said to run on the metal since they do not use references.

Knowing these two bits of crucial information, you can modify some class objects into structures and gain a good performance boost. However, you must make these decisions carefully since a bad implementation of structure will actually cause slower performance. Thankfully we have MSDN to show us a few guidelines on structure uses:

✓ CONSIDER defining a struct instead of a class if instances of the type are small and commonly short-lived or are commonly embedded in other objects.

X AVOID defining a struct unless the type has all of the following characteristics:

• It logically represents a single value, similar to primitive types (int, double, etc.).
• It has an instance size under 16 bytes.
• It is immutable.
• It will not have to be boxed frequently.

In all other cases, you should define your types as classes.

Source: MSDN

All of those points make sense. If something is going to be a structure it should represent a single value (like the other primitive types), it has a small memory footprint, it is immutable (again like the other primitive types), and will not be boxed/unboxed a lot inside other portions of your program. If you cannot meet these key requirements, you should be using a class instead of a structure.

The next time you think you can represent a chunk of information as a structure, you should take a moment and check the requirements. If you do not check for these key points, then your performance will suffer down the road as your application scales out.