Podcasts

Podcast Episode 44 – Blog or Solve Problems

WorkstationThis past week, someone’s comment that they “don’t blog, they solve problems instead” really struck a nerve with me. Not only because I’m a blogger, but because I know just how many times a day that my problems are solved because someone blogged the solution at some point in the past.



Links Mentioned in this Show:
The Original Tweet
The Blog Post that caused the comment
John Sonmez Blogging Course
Soft Skills Book (affiliate link)
Dial2Verify

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

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

C# 6 Features – Expression-bodied Members

I have finally gotten around to looking into C# 6. It was released in July 2015 and available starting in .Net Framework 4.6, but I just hadn’t had any occasion to use it. In order to “force myself” to dig into it a little more, I decided to write a series of blog posts about the new features. The first one out of the gate is Expression-bodied Members.

Expression-bodied Members are just a syntactic sugar on the language. I’m not angry about things that are syntactic sugar. In fact, one of my favorite things about C# 3 was automatic properties, so I’m all in. In reality, it is just about expressing intent more clearly and more succinctly. Here is a very simple example of a method that uses this new feature.

public int DoubleANumber (int input) => input*2;

In this case, I’ve defined a public method that takes an integer and returns an integer. As we are reading left-to-right, there is nothing weird yet. However, after the method name declaration, we change it up and throw the “Anders Operator” aka “Hash Rocket” aka “LINQ Symbol” aka “Goes To” aka “=>” into the mess. Just like LINQ, you can put an expression right afterwards and that is what is evaluated. We are missing the curly braces, sure, but we are also missing a return statement. You don’t need it.

You can also use this simple syntax for properties. Take a look at the following class:

public class Person
{
     public string FirstName {get;set;}
     public string LastName {get;set;}
     
     public string FullName => string.Format("{0} {1}", FirstName, LastName);
}

The FullName property is now just a read-only expression. The alternative would have looked like this:

public class Person
{
     public string FirstName {get;set;}
     public string LastName {get;set;}
     
     public string FullName 
     {
          get { return string.Format("{0} {1}", FirstName, LastName); }
     }
}

Even if you one-lined the FullName property, it would not be as clean as the Expression-bodied version

public string FullName { get { return string.Format("{0} {1}", FirstName, LastName); } }

Fantastic. We’ve seen a way to clean up our code a bit, no down side, right? Well, of course there is a down side. This is only really useful and clean-looking if you have a very simple one-liner to express. If you ramp this guy up a bit, it starts to break down.

// DOES NOT COMPILE
public class Ugh
{
    public int DoLotsOfStuff(int input) =>
        input += 2;
        input = input * 2;
        Math.Pow(input, 2);
}

This doesn’t even compile, for probably very obvious reasons. You can’t do a bunch of work on separate lines and then just hope the last evaluation is what is returned. The error you get is “Invalid token ‘=’ in class, struct, or interface member declaration”. The reason being that C# thinks that the method is just public int DoLotsOfStuff(int input) => input += 2; After that, it is trying to figure out how input = input * 2; makes sense as a free standing line within the class. That isn’t how you declare a method, a property, or a field, so C# freaks out. Of course you could jam all of that on one line, but it may start to get confusing the more you try to do.

So, Expression-bodied Members can be a nice clean way to express your code simply. However, the danger here is that developers could try to play “code golf” to get their code to fit on one line. That would really decrease readability, which defeats the entire purpose. So, I feel like this is a feature to use carefully and sparingly.

Business of Software

Podcast Episode 43 – Older Programmers

Old ManWhy is the average age of a developer so much less than the average age of a professional worker in the United States? Is it because the industry as a whole is striving to keep people out? Are companies replacing people as soon as their salary starts to get higher with people who make half as much and will work twice as many hours for the same salary? Check out what I think about it in this week’s episode.

Links Mentioned in this Show:
Developers Fear Age 30
Older Workers are More Knowledgeable, but Harder to Find
Where do all the Old Programmers Go?
Silicon Valley’s Dark Secret
Neural Network in the Browser

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

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.

SQL

NullIf

NullIfThis post is about a handy little function that works across many database systems, including Sql Server, Oracle, and MySql. I often forget about it and at times even end up coding some workaround that would have been a lot easier if I had just used NullIf(). NullIf takes two parameters. The first parameter is the value to check and the second parameter is the value that should equate to NULL. Let’s take a look at an example to hopefully make this clearer.

First, we will create a table to work from, populate it with some data, and select the results out so that we can see what we have visually.

USE tempdb
GO

CREATE TABLE dbo.JunkData (
	JunkDataId INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
	Name VARCHAR(100) NOT NULL,
	StreetAddress VARCHAR(100) NULL
);

INSERT dbo.JunkData (Name, StreetAddress)
SELECT 'Pete', '777 Main St';

INSERT dbo.JunkData (Name, StreetAddress)
SELECT 'Jeff', NULL;

INSERT dbo.JunkData (Name, StreetAddress)
SELECT 'Dustin', '999 Oak St';

INSERT dbo.JunkData (Name, StreetAddress)
SELECT 'Ron', NULL;

INSERT dbo.JunkData (Name, StreetAddress)
SELECT 'Keith', '';

SELECT Name, StreetAddress
FROM dbo.JunkData;

Our table's contents

In this case, the Street Address column is nullable, but for Keith’s record the developer chose to insert a blank space instead of a NULL for a missing address. If we try to just write a query to get rid of the nulls, we still have the blank space issue. Here is a query that uses COALESCE to get rid of the NULLS and its results.

SELECT Name, COALESCE(StreetAddress, 'Not Provided') AS StreetAddress
FROM dbo.JunkData;

Our results with COALESCE Only

You see that we still have the blank address to deal with. One work around is to use a case statement. Something like “CASE WHEN COALESCE(StreetAddress, ‘Not Provided’) = ” THEN ‘Not Provided’ ELSE COALESCE(StreetAddress, ‘Not Provided’) END AS StreetAddress”. But, that is quite a mouthful and we repeat ourselves several times. However, if we could get COALESCE to treat a blank address like a NULL, we’d have been in business in the first place. That is what NULLIF() does. It evaluates the value we specify as a NULL (in this case a blank space) and then the rest of the query can treat it like a NULL. Here is that example

SELECT Name, COALESCE(NULLIF(StreetAddress, ''), 'Not Provided') AS StreetAddress
FROM dbo.JunkData;

Our results with COALESCE and NULLIF

That’s much more succinct and I feel like it conveys our intent much more easily. Here’s another practical use case for NULLIF(). Given the following table and values, we want to find the average sale on each given day.

CREATE TABLE dbo.Reporting(
  RowId INT IDENTITY(1,1) PRIMARY KEY CLUSTERED,
  SalesDate DATETIME NOT NULL,
  TotalSales MONEY NOT NULL,
  QuantitySold NUMERIC(9,2) NOT NULL
);

INSERT dbo.Reporting(SalesDate, TotalSales, QuantitySold)
SELECT '4/1/16', 432.50, 2;

INSERT dbo.Reporting(SalesDate, TotalSales, QuantitySold)
SELECT '4/2/16', 0.00, 0;

INSERT dbo.Reporting(SalesDate, TotalSales, QuantitySold)
SELECT '4/3/16', 5422.10, 10;

We might write something like the following

SELECT SalesDate, (TotalSales/QuantitySold) as AverageSale
FROM dbo.Reporting;

However, when you do, you get a divide-by-zero error. Sometimes in more complicated situations, that can be a bear to track down exactly what is evaluating to zero in an equation. However, if you ask the denominator to evaluate as NULL whenever it is 0, SQL is much happier. Here’s our query now:

SELECT SalesDate, (TotalSales/NULLIF(QuantitySold, 0)) as AverageSale
FROM dbo.Reporting;

Now, we easily get our results.

Results of Dividing by NULL

This helps identify which records are causing our issue and can now easily be dealt with. If we don’t like NULL in our results, we can use ISNULL() or COALESCE() to put a sensible default answer. Done and done.

Podcasts

Podcast Episode 42 – The Answer to Life, the Universe, and Everything, just kidding – MS Build 2016

MS Build 2016In episode 42, I don’t have the answer to Life, the Universe, and Everything, but I do have thoughts and reactions to Microsoft’s 2016 Build conference. I cover Bash on Windows, Ink, Bots, and Free Xamarin for everyone!


Links Mentioned in this Show:
XKCD Thing Explainer
Cleartext

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

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.