The Daily Parker

Politics, Weather, Photography, and the Dog

Eddie Lampert offers to garrote his own company

Longtime readers know how much I loathe Eddie Lampert for what he did to Sears and for how perfectly he demonstrates the dangers of slavishly following a philosophy that owes a lot to the thought processes of adolescent boys.

Well, my longtime predictions seem to be coming true. Lampert has offered to buy the best bits of Sears (i.e., its real estate and Kenmore brand), which would quickly kill the company. Crain's Joe Cahill outlines some of the offal in this awful person's proposal:

It's not clear, however, just what Lampert is willing to pay. The offer letter indicates the transaction should reflect an enterprise value of $500 million for the home improvement and parts businesses, but doesn't put a price on Kenmore or the real estate, beyond confirming Lampert would assume $1.2 billion in real estate debt. The letter further proposes that the asset sale take place in conjunction with offers by Sears to convert some of its debt into equity and buy back or exchange for equity another slug of outstanding debt. Lampert indicates a willingness to "consider participating in such exchange offer and tender offer," which might increase his equity interest in Sears.

The complex and somewhat vague proposal raises questions about Lampert's many hats at Sears—he's the controlling shareholder, CEO, a major creditor, and—if this transaction goes through—a buyer of key company assets. Let's focus on his role as CEO, where his job is to generate maximum returns on company assets, either through business operations or by selling them for the highest possible price. His offer letter implicitly confirms that he's been unable to do either with Kenmore. Yet he evidently believes he could squeeze strong returns out of the brand if he owned it separately from Sears. Otherwise, buying it would make no financial sense for Lampert and any fellow investors in the proposed asset purchase.

Understandably, this disconnect fuels a growing perception that Lampert is cherry-picking company assets ahead of a potential bankruptcy filing that likely would leave Sears shareholders with little or nothing. Already, a real estate investment trust formed by Lampert has acquired many of Sears' store locations with the intention of remarketing them to higher-paying tenants. "There's a very legitimate case to say he's screwed up the company and now he's trying to take the crown jewels," says Nell Minow, a corporate governance expert with Value Edge Advisors.

No kidding. Thanks, Eddie.

V is for var

Blogging A to ZFor my second attempt at this post (after a BSOD), here (on time yet!) is day 22 of the Blogging A-to-Z challenge.

Today's topic: the var keyword, which has sparked more religious wars since it emerged in 2007 than almost every other language improvement in the C# universe.

Before C# 3.0, the language required you to declare every variable explicitly, like so:

using System;
using InnerDrive.Framework.Financial;

Int32 x = 123; // same as int x = 123;
Money m = 123;

Starting with C# 3.0, you could do this instead:

var i = 123;
var m = new Money(123);

As long as you give the compiler enough information to infer the variable type, it will let you stop caring about the type. (The reason line 2 works in the first example is that the Money struct can convert from other numeric types, so it infers what you want from the assignment. In the second example, you still have to declare a new Money, but the compiler can take it from there.)

Some people really can't stand not knowing what types their variables are. Others can't figure it out and make basic errors. Both groups of people need to relax and think it through.

Variables should convey meaning, not technology. I really don't care whether m is an integer, a decimal, or a Money, as long as I can use it to make the calculations I need. Where var gets people into trouble is when they forget that the compiler can't infer type from the contents of your skull, only the code you write. Which is why this is one of my favorite interview problems:

var x = 1;
var y = 3;
var z = x / y;

// What is the value of z?

The compiler infers that x and y are integers, so when it divides them it comes up with...zero. Because 1/3 is less than 1, and .NET truncates fractions when doing integer math.

In this case you need to do one of four things:

  • Explicitly declare x to be a floating-point type
  • Explicitly declare y to be a floating-point type
  • Explicitly declare the value on line 1 to be a floating-point value
  • Explicitly declare the value on line 2 to be a floating-point value
// Solution 1:

double x = 1;
int y = 3;
var z = x / y;

// z = 0.333...

// Solution 3:

var x = 1f;
var y = 3;
var z = x / y;

// z == 0.333333343

(I'll leave it as an exercise for the reader why the last line is wrong. Hint: .NET has three floating-point types, and they all do math differently.)

Declaring z to be a floating-point type won't help. Trust me on this.

The other common reason for using an explicit declaration is when you want to specify which interface to use on a class. This is less common, but still useful. For example, System.String implements both IEnumerable and IEnumerable<char>, which behave differently. Imagine an API that accepts both versions and you want to specify the older, non-generic version:

var s = "The lazy fox jumped over the quick dog.";
System.Collections.IEnumerable e = s;

SomeOldMethod(e);

Again, that's an unusual situation and not the best code snippet, but you can see why this might be a thing. The compiler won't infer that you want to use the obsolete String.IEnumerable implementation under most circumstances. This forces the issue. (So does using the as keyword.)

In future posts I may come back to this, especially if I find a good example of when to use an explicit declaration in C# 7.

U is for UUID

Blogging A to ZFor day 21 of the Blogging A-to-Z challenge I'm going to wade into a religious debate: UUIDs vs. integers for database primary keys.

First, let's define UUID, which stands for Universally Unique Identifier. A UUID comprises 32 hexadecimal digits typically displayed in 5 groups separated by dashes. The actual identifier is 128 bits long, meaning the chance of a collision between any two of them is slightly lower than the chance of finding a specific grain of dust somewhere in the solar system.

An integer, on the other hand, has just 32 or 64 bits, depending on the system you're using. Not only do integers collide frequently, but given that incrementing integer keys typically start at 1, they collide all the time. Also, using an incrementing integer, you don't know what ID your database will give you before you insert a given row, unless you create some gnarly SQL that hits the database a minimum of twice.

Many people have weighed in on whether to use UUIDs or auto-incrementing integers for database keys. People argue about the physical alignment of rows, debugging and friendly URLs, stable IDs vs deterministic IDs, non-uniqueness across tables, inadvertent data disclosure...lots of reasons to use one or the other.

The bottom line? It doesn't really matter. What matters is that you have sensible, non-religious reasons for your choice.

Both UUIDs and serial integers have their place, depending on the context. If you have a lookup table that users will never see, use serial IDs; who cares? If you use an ORM extensively, you might prefer UUIDs.

If you're new to programming, all of this seems like angels on the head of a pin. So read up on it, listen to the arguments on both sides, and then decide what works to solve your problem. Which is basically what you should do all the time as a professional programmer.

T is for Type

Blogging A to ZNow that I've caught up, day 20 of the Blogging A-to-Z challenge is just a few hours late. (The rest of the week should be back to noon UTC/7 am Chicago time.)

Today's topic: Types.

Everything in .NET is a type, even System.Type, which governs their metadata. Types exist in a hierarchy called the Common Type System (CTS). Distilled, there are two kinds of types: value types and reference types. I alluded to this distinction Saturday earlier today when discussing strings, which are reference types (classes) that behave a lot like value types (structs).

The principal distinction is that value types live on the stack and reference types live on the heap. This means that all of the data in a value type is contained in one place. The CLR sets aside memory for the entire object and moves the whole thing around as a unit. Naturally, this means value types tend to be small: numbers, characters, booleans, that sort of thing.

Reference types also partially live on the stack but only as a pointer to the heap where they keep their main data. The .NET memory manager can move reference types and their data independently as needed to handle different situations.

One of the consequences of this distinction is that when you pass a value type to a method, you're passing the entire thing; but when you pass a reference type to a method, you're only passing its pointer. This can give new .NET developers terrific headaches:

public void ChangeStuff()
{
	var i = 12345; // i is a System.Int32
	var p = new MyClass { Name = "Hubert", Count = i };
	
	ChangeStuff(i, p);
	
	Debug.Assert(12345 == i); // Succeeds!
	Debug.Assert(54321 == MyClass.Count); // Succeeds!
	Debug.Assert("Hubert" == MyClass.Name); // Fails!
}

private void ChangeStuff(int i, MyClass myClass)
{
	i = 54321; // The i in this method is not the i in the calling method
	MyClass.Name = "Humbert"; // But the MyClass is
	MyClass.Count = i;
}

When the CLR passes i to the second ChangeStuff method, it creates a copy of i on the stack and passes in that copy. Then on line 15, we create a third copy of i that replaces the second copy on the stack.

But lines 16 and 17 aren't creating copies of MyClass; they're using the pointer to the instance of MyClass created on line 4, so that any operations on MyClass work on the very same instance.

I recommend new developers read the MSDN article on Types I referenced above. Also read up on boxing and unboxing and anonymous types.

S is for String

Blogging A to ZDay 19 of the Blogging A-to-Z challenge was Saturday, but Apollo After Hours drained me more or less completely for the weekend.

So this morning, let's pretend it's still Saturday for just a moment, and consider one of the oddest classes in the .NET Base Class Library (BCL): System.String.

A string is just a sequence of one or more characters. A character could be anything: a letter, a number, a random two-byte value, what have you. System.String holds the sequence for you and gives you some tools to control them, like Compare, Format, Join, Split, and StartsWith. Under the hood, the class holds the string as an array of char values.

Even though System.String is a class and not a struct, it behaves much more like the latter than the former. Strings are immutable: once you create a string, any changes you make to it create a new string instance. Also, below a certain length, strings live on the stack rather than in the heap, which has consequences for memory management and performance. But unlike structs, strings can be null. This is valid code:

var s = "Hello, world";
string t = null;
var u = t + s;

Strings can also be zero-length or all whitespace, which is why the class has a very useful method String.IsNullOrWhitespace().

The blog C# in Depth has a good description of strings that's worth reading. Jon Skeet also takes on string memory management in one of his longer posts.

R is for Reflection

Blogging A to ZOK, I lied. I managed to find 15 minutes to bring you day 18 of the Blogging A-to-Z challenge, in which I'll discuss one of the coolest feature of the .NET ecosystem: reflection.

Reflection gives .NET code the ability to inspect and use any other .NET code, full stop. If you think about it, the runtime has to have this ability just to function. But any code can use tools in the System.Reflection namespace. This lets you do some pretty cool stuff.

Here's a (necessarily brief) example, from the Inner Drive Extensible Architecture. This method, in the TypeInfo class, uses reflection to describe all the methods in a Type:

using System;
using System.Collections.Generic;
using System.Data;
using System.Diagnostics;
using System.Globalization;
using System.Linq;
using System.Reflection;
using System.Text;

public static IDictionary<string, MethodInfo> ReflectMethods(object target)
{
	if (null == target) return new Dictionary<string, MethodInfo>();

	var thisType = target.GetType();
	var methods = thisType.GetMethods(BindingFlags.Public | BindingFlags.NonPublic | BindingFlags.Instance | BindingFlags.Static);

	var returnList = new Dictionary<string, MethodInfo>();
	foreach (var thisMethod in methods.OrderBy(m => m.Name))
	{
		var parameters = thisMethod.GetParameters();
		var keyBuilder = new StringBuilder(thisMethod.Name.Length + (parameters.Length * 16));
		keyBuilder.Append(thisMethod.Name);
		foreach (var t in parameters)
		{
			keyBuilder.Append(";P=");
			keyBuilder.Append(t.ParameterType.ToString());
		}
		keyBuilder.Append(";R=");
		keyBuilder.Append(thisMethod.ReturnType.ToString());
		keyBuilder.Append(";F=");
		keyBuilder.Append(thisMethod.Attributes.ToString());

		try 
		{
			returnList.Add(keyBuilder.ToString(), thisMethod);
		}
		catch (ArgumentException aex) 
		{
			Trace.WriteLine(string.Format(CultureInfo.InvariantCulture, "> Exception on {0}: {1}", keyBuilder, aex.Message));
		}
		catch (Exception ex)
		{
			Trace.WriteLine(string.Format(CultureInfo.InvariantCulture, "> Exception on {0}: {1}", keyBuilder, ex.Message));
			throw;
		}
	}

	return returnList;
}

The System.Reflection.Assembly class also allows you to create and activate instances of any type, use its methods, read its properties, and send it events.

Reflection is hugely powerful and hugely useful. And very, very cool.

Dogleg

I published today's A-to-Z post a little late because I've had a lot going on this week, between the Apollo Chorus benefit tomorrow, rehearsals, and taking care of Parker.

Yesterday Parker got his sutures out. The vet said he's healing very well, no signs of infection or re-injury, and good progress on using the injured leg. He can go without the Cone of Shame while someone is observing him, and on Friday, he can have it off permanently. Both he and I really, really, really want that to happen.

They also gave me art. Here are his X-rays from two weeks ago, showing his right leg before and after surgery. Before:

After:

The after photo looks painful, but the vet and the dog both assure me it's better than the before image.

Another improvement: he can now go on 10-minute walks, increasing by 5 minutes a week until mid-May when he can go as long as he wants. We're still walking slowly so that he has to put weight on the leg. But today, when he gets his first trip around the block in almost 3 weeks, I'm sure he'll be happier.

Q is for Querying

Blogging A to ZPosting day 17 of the Blogging A-to-Z challenge just a little late because of stuff (see next post). Apologies.

Today's topic is querying, which .NET makes relatively easy through the magic of LINQ. Last week I showed how LINQ works when dealing with in-memory collections of things. In combination with Entity Framework, or another object-relational mapper (ORM), LINQ makes getting data out of your database a ton easier.

When querying a database in a .NET application, you will generally need a database connection object, a database command object, and a data reader. Here's a simple example using SQL Server:

public void DirectQueryExample(string connectionString)
{
	using (var conn = new SqlConnection(connectionString))
	{
		var command = new SqlCommand("SELECT * FROM LookupData", conn);
		conn.Open();
		var reader = command.ExecuteReader();
		foreach (var row in reader)
		{
			Console.WriteLine(reader[0]);
		}
	}
}

(Let's skip for now how bad it is to execute raw SQL from your application.)

With Entity Framework (or another ORM), the ORM generates classes that represent tables or views in your database. Imagine you have an animals table, represented by an animal class in your data project. Finding them in your database might now look like this:

public IEnumerable<Animal> OrmQueryExample(string species)
{
	var result = new List<Animal>();
	using (var db = Orm.Context)
	{
		var dtos = db.Animals.Where(p => p.Species == species);
		result.AddRange(dtos.ForEach(MapDtoToDomainObject));
	}

	return result;
}

private Animal MapDtoToDomainObject(AnimalDto animalDto)
{
	// Code elided
}

That looks a little different, no? Instead of opening a connection to the database and executing a query, we use a database context that Entity Framework supplies. We then execute a LINQ query directly on the Animals table representation with a predicate. The ORM handles constructing and executing the query, and returns an IQueryable<T> of its self-generated Animal data transfer object (DTO). When we get that collection back, we map the fields on the DTO to the domain object we want, and return an IEnumerable<T> of our own domain object back to the caller. If the query comes up empty, we return an empty list. (Here's a decent Stack Overflow post on the difference between the two collection types.)

These are naive examples, of course, and there are many other ways of using EF. For example, for field mapping we might use a package like AutoMapper instead of rolling our own field-level mapping. I encourage you to read up on EF and related technologies.

Go home, April. You're drunk.

So far, this April ranks as the 2nd coldest in Chicago history. We had snow this past weekend, and we expect to have snow tonight—on April 18th.

So it may come as a surprise to people who confuse "weather" and "climate" that, worldwide, things are pretty hot:

The warm air to our north and east has blocked the cold air now parked over the midwestern U.S. Europe, meanwhile, feels like August. And Antarctica feels like...well, Antarctica, but unusually warm.

Note that the temperature anomalies at the bottom of the image above are based on the 1980-2010 climate normal period, which was warmer than any previous 30-year period. In other words, the poles may be 3-5°C warmer than normal now and also 4-7°C warmer than any point in recorded history.

At least, historically, a cold spring means a cool summer here. Lake Michigan is a very cold 5°C today, a few degrees below normal for this time of year, and a huge sink for summer heat later on. Here's hoping, anyway.