Pete On Software

RSS Feed

Down is the New Up

Down is the New UpWhat a time to be a .Net Developer. It used to be that one had to hang your head in certain circles when you were asked about your job. Admitting that you programmed in the Microsoft stack was seen as “less than cool”. All the cool kids were programming in Ruby, Node, Haskell, etc. Pick your poison. It was more popular than ever to write the “Why I’m Leaving .Net” blog post and just vamoose.

Recently, however, Microsoft has been changing ever since Satya Nadella has taken over. In reality, some of the changes started even before his arrival, but they have been leaping forward recently. .Net is Open Source, Microsoft projects are on GitHub and being developed in the open, and .Net has finally fulfilled its promise and is fully cross platform. You can develop full .Net apps on Windows, Linux, or the Mac and you can share the projects between the three without much issue.

Microsoft is now a Platinum Sponsor of the Linux Foundation. That means that Microsoft donates $500,000 annually to help the development of Linux, which is the highest level of sponsorship alongside Oracle, HP, IBM, and others. Google has joined the .Net Foundation to help steer .Net into the future.

TypeScript has gotten some wide adoption. After being made fun of for trying to “un-JavaScript JavaScript”, now some major JS players are using TypeScript. The Angular team at Google eschewed Dart (Google’s own thing) in favor of TypeScript. What is even happening to the world?

SQL Server is on Linux (in preview at the time I write this). That says almost everything there.

Visual Studio is available for the Mac (also in preview). I’m not talking about VS Code, I’m talking full Visual Studio.

The other night, I took a shot at this brave new world. I installed Linux Mint 18 Sarah (MATE version) in a virtual machine on my iMac and attempted to get a fully functional ASP.Net MVC site up and running. I will admit that the tooling is not quite there yet and I did spend about three hours on the entire process, but I learned a lot. There were some versioning issues, but I finally now have a complete working toolchain using VS Code, .Net Core, npm, and tools like Yeoman. Here was my first console application that I wrote:

My first working .Net app on Linux

After that, I got Yeoman installed and configured:

Yeoman on Linux

Finally, I was able to generate an ASP.Net MVC 6 site running on .Net Core developed and running on a Linux box that I set up.

An ASP.Net MVC Site on Linux

The future is here. As Apple continues to get more and more evil and not care about its customers, Microsoft is seeking newer and newer ways to engage developers across all spectrums. Honestly, engaging developers is always what they’ve done well. Now, they are just taking it to the next level. I can’t wait to get more and more of these kinds of applications into production and to be able to hold my head high and say that I’m a .Net Developer. I’m still waiting to read the first “Why I left Node for .Net” post, though 😉

Podcast Episode 47 – WWDC 2016

WWDC 2016The World Wide Developer’s Conference (WWDC) is like the Super Bowl for Apple Developers. Thousands of developers vie to get a ticket and even those without tickets still go to San Francisco and attend ancillary events. As I’ve done the last few years, I watch the keynote and distill it down for you so you can trade 2 hours of your life for about 15 minutes of wrap up 😉

Links Mentioned in this Show:
NES Classic Edition

You can also subscribe to the podcast at any of these places:
iTunes Link RSS Feed Listen on Stitcher

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

C# 6 Features – Nameof Expressions

Name BadgeIn the latest post on my series about C# 6’s features, I want to look at nameof expressions. There are times when you need the string value of variables or methods or classes in your code. That could be to return an argument exception, it could be to have some sort of property changed notification, or it could even be to get the string value of an enumeration value.

Previously, you had to either have “magic strings” in your application or any number of tricks to abstract away what are basically the magic strings. If you changed the name of a variable, parameter, method, class, or enum, nothing would ensure that you went back and updated your “magic strings”. Perhaps if you had written very finely-grained unit tests (and you remembered to update those when you changed a variable name), you might get a warning, but that is a tremendous amount of discipline. That’s where C# 6 is here to save our bacon.

As an example, here is something we might have done previously

public void Useless(string foo)
{
    if (string.IsNullOrEmpty(foo))
    {
        throw new ArgumentNullException("foo");
    }
    
    return;
}

You can see how I could change the parameter name from foo to something else and the compiler won’t care if I fix the call to ArgumentNullException() or not. However, nameof fixes and prevents that.

public void Useless(string foo)
{
    if (string.IsNullOrEmpty(foo))
    {
        throw new ArgumentNullException(nameof(foo));
    }
    
    return;
}

The benefit here is that if I change the parameter and forget to change nameof(foo) like this:

public void Useless(string bar)
{
    if (string.IsNullOrEmpty(bar))
    {
        throw new ArgumentNullException(nameof(foo));
    }
    
    return;
}

You actually will get a compile time error that says “The name ‘foo’ does not exist in the current context”. Some people hate using the compiler as a unit test, but I don’t. It is basically “round one” of testing. I think the issue arises when it is the the only means of testing used, but it is just another tool in the toolbox that we should use.

As I mentioned earlier, you can use it to get the names of classes, methods, and it lets you stop the SomeEnum.SomeValue.ToString() madness. It is the same syntax and would look like this


public class UselessClass
{
    enum UselessEnum
    {
        UselessEnumValue
    }
    
    public void UselessMethod(string uselessParam)
    {
        Console.WriteLine(nameof(UselessClass));
        Console.WriteLine(nameof(UselessMethod));
        Console.WriteLine(nameof(uselessParam));
        Console.WriteLine(nameof(UselessEnum));
        Console.WriteLine(nameof(UselessEnum.UselessEnumValue));
    }
}

// Later when called...
var uselessObject = new UselessClass();
uselessObject.UselessMethod("uselessValue");

// Outputs these values
/*
UselessClass
UselessMethod
uselessParam
UselessEnum
UselessEnumValue
*/

As I said at the beginning of this series, much of C# 6’s features aren’t mind-blowing, but instead are small improvements to help smooth out some edges. Are you using nameof? Are you going to when you get the chance?

Podcast Episode 46 – Disrupted

Disrupted BookI recently finished reading a book by Dan Lyons called Disrupted: My Misadventure in the Start-Up Bubble on the recommendation of my friend Dustin Rogers. This book is an inside look at a company called HubSpot that – according to Lyons – exhibits some of the worst and most stereotypical traits of Silicon Valley companies. In this episode, I review the book and talk about some of the things that drive me nuts about these kinds of companies.


Links Mentioned in this Show:
Disrupted on Amazon
Dustin’s Podcast Episode
HubSpot’s Rebuttal to the Book
HyperDev Announcement
HyperDev Site

You can also subscribe to the podcast at any of these places:
iTunes Link RSS Feed Listen on Stitcher

Thanks to all the people who listen, and a special thanks to those who have rated me. I really appreciate it.

The episodes have been archived. Click Here to see the archive page.

C# 6 Features – Using Static

StaticFor this next post in my series on the new features in C# 6, I’m going to cover the using static syntax. This feature is also 100% syntactic sugar, but it can be helpful. Unfortunately, it also comes with quite a few gotchas.

I’m sure all of us are familiar with writing code like you see below. The WriteLine() method is a static method on the static class Console.

using System;

namespace CodeSandbox
{
    class Program
    {
        static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }
}

Because Console is a static class, we can treat it as a “given” and just now include it in our using statements. Console.WriteLine() is actually System.Console.WriteLine() if we include the namespace. However, since we are including “using System;” at the top of the file, we don’t have to type it out. This is the exact same concept.

using static System.Console;

namespace CodeSandbox
{
    class Program
    {
        static void Main(string[] args)
        {
            WriteLine("Hello World");
        }
    }
}

Now instead of just “using”, I’ve included “using static” and included the full name of the static class, in this case System.Console. Once that is done, I’m free to just call the WriteLine() method as if it were locally scoped inside my class. This is all just really syntatic sugar. When I use Telerik’s JustDecompile to analyze the program and give me back the source, this is what I get.

using System;

namespace CodeSandbox
{
    internal class Program
    {
        public Program()
        {
        }

        private static void Main(string[] args)
        {
            Console.WriteLine("Hello World");
        }
    }
}

If we dig even further into the IL, you can see that it agrees that we are still just making a call to WriteLine() inside of the System.Console class.

.method private hidebysig static void Main (
            string[] args
        ) cil managed 
    {
        .entrypoint
        IL_0000: nop
        IL_0001: ldstr "Hello World"
        IL_0006: call void [mscorlib]System.Console::WriteLine(string)
        IL_000b: nop
        IL_000c: ret
    }

Okay, that makes sense. Seems potentially helpful. Where do these promised “gotchas” come in? Our issues start to arise when you have multiple “using static” declarations in a file. If those static classes have methods inside them with the same name, conflicts can happen. Let’s take a look at one place where this can absolutely happen in a commonly used area of .Net.

using System.IO;

namespace CodeSandbox
{
    class Program
    {
        static string fakeSourceLocation = @"c:\";
        static string fakeBackupLocation = @"c:\backup\";

        static void Main(string[] args)
        {
            foreach (var fileWithPath in Directory.GetFiles(fakeSourceLocation))
            {
                var fileName = Path.GetFileName(fileWithPath);
                var backupFileWithPath = Path.Combine(fakeBackupLocation, fileName);

                if (!File.Exists(backupFileWithPath))
                {
                    File.Copy(fileWithPath, backupFileWithPath);
                }
            }
        }
    }
}

In this simple contrived example, I’m iterating through all of the files in a directory and if they don’t exist in a backup location, I copy them there. This doesn’t deal with versioning, etc, but it does give us some basic System.IO examples to work with. Now, if I try to simplify the code like this, I get an issue.

using static System.IO.Directory;
using static System.IO.File;
using static System.IO.Path;

namespace CodeSandbox
{
    class Program
    {
        static string fakeSourceLocation = @"c:\";
        static string fakeBackupLocation = @"c:\backup\";

        static void Main(string[] args)
        {
            foreach (var fileWithPath in GetFiles(fakeSourceLocation))
            {
                var fileName = GetFileName(fileWithPath);
                var backupFileWithPath = Combine(fakeBackupLocation, fileName);

                if (!Exists(backupFileWithPath))
                {
                    Copy(fileWithPath, backupFileWithPath);
                }
            }
        }
    }
}

This won’t even build. Can you guess why? If you are very familiar with System.IO classes, you might have noticed that there is a System.IO.File.Exists() and a System.IO.Directory.Exists(). Our build error lets us know by saying, “The call is ambiguous between the following methods or properties: ‘Directory.Exists(string)’ and ‘File.Exists(string)'”. One way to get around this is to just be explicit at the ambiguous part like this:

using static System.IO.Directory;
using static System.IO.File;
using static System.IO.Path;

namespace CodeSandbox
{
    class Program
    {
        static string fakeSourceLocation = @"c:\";
        static string fakeBackupLocation = @"c:\backup\";

        static void Main(string[] args)
        {
            foreach (var fileWithPath in GetFiles(fakeSourceLocation))
            {
                var fileName = GetFileName(fileWithPath);
                var backupFileWithPath = Combine(fakeBackupLocation, fileName);

                if (!System.IO.File.Exists(backupFileWithPath))
                {
                    Copy(fileWithPath, backupFileWithPath);
                }
            }
        }
    }
}

I don’t know how that makes me feel. It seems like at least a small code smell. Maybe in these occasions, you don’t use this shortcut if it feels wrong. In general, I could see this being like the Great Var Debate of 2008™. People thought that var foo = new Bar(); was smelly compared to Bar foo = new Bar();, but it seems like most people have moved past it. Maybe I’m just on the beginning of this wave of change and I’ll stop yelling for the kids to get off of my lawn soon. At the moment, however, I’m probably going to file using static in the “not something I’m going to really use” pile.

« Older Entries   Recent Entries »