The Daily Parker

Politics, Weather, Photography, and the Dog

D is for Database

Blogging A to ZWelcome to day 4 of the Blogging A-to-Z challenge. After yesterday's more theoretical post on the CLR, today will have a practical example of how to connect to data sources from C# applications.

Almost every application ever written needs to store data somewhere. If you're deploying a .NET website into Microsoft Azure (like this blog), you will probably connect it to an Azure SQL Database. Naturally, Visual Studio and C# make this pretty easy.

Here's the code that opens up a database connection and prints out to the Trace window what it's opened:

#region Copyright ©2018 Inner Drive Technology

using System.Configuration;
using System.Data.SqlClient;
using System.Diagnostics;

#endregion

namespace InnerDrive.DailyParkerAtoZ.WeekOne
{
	public static class DataConnections
	{
		private static string ConnectionString => ConfigurationManager.ConnectionStrings["Database"].ConnectionString;

		public static void Connect()
		{
			using (var connection = new SqlConnection(ConnectionString))
			{
				connection.Open();
				Trace.WriteLine($"Connected to {connection.DataSource}");
			}
		}
	}
}

Let's take a look at that line by line.

Lines 3-6 tell the compiler that the objects referenced in the executable code come from those four namespaces (which I'll talk more about on April 16th). The SqlConnection class, for example, lives in the System.Data.SqlClient namespace. If I didn't have the using statement on line 5, I'd have to reference the class and its namespace as System.Data.SqlClient.SqlConnection, which is cumbersome.

Line 13 creates a ConnectionString property that gets its value from a configuration setting. More on that below.

Line 17 first sets up a different kind of using statement, which makes sure that whatever the expensive SqlConnection class does while its alive, it gets cleaned up when it finishes on line 21—even if it throws an exception. Then the same line creates a new SqlConnection object and assigns it to the variable connection.

Line 19 attempts to open the connection to the database. If it succeeds, line 20 prints out the name of the data source. If it fails, it throws an exception that whatever method called this one can catch.

The configuration file looks like this (but with a real database, user ID, and password):

<?xml version="1.0" encoding="utf-8" ?>
<configuration>
	<connectionStrings>
		<add 
			name="Database" 
			connectionString="server={server name}.database.windows.net;initial catalog={database name};persist security info=True;user id={user ID};password={password};"
		/>
	</connectionStrings>
</configuration>

Notice that the name on line 5 corresponds to the configuration setting name on line 13 of the C# code. That's how the code knows which connection string to read from configuration.

Finally, there's also a unit test, which looks like this:

#region Copyright ©2018 Inner Drive Technology

using InnerDrive.DailyParkerAtoZ.WeekOne;
using Microsoft.VisualStudio.TestTools.UnitTesting;

#endregion

namespace InnerDrive.DailyParkerAtoZ.UnitTests
{
	[TestClass]
	public class DataConnectionsTests
	{
		[TestMethod]
		public void CanConnectToDataSource()
		{
			DataConnections.Connect();
		}
	}
}

If the call to DataConnections.Connect() succeeds, the test passes. If the call fails, the test fails and shows the exception that gets thrown.

You can download the code for all of these posts here. You'll have to change the configuration information in the unit test project's app.config file to make it work, of course.

C is for Common Language Runtime

Blogging A to ZDay 3 of the Blogging A-to-Z challenge brings us to the heart of .NET: the Common Language Runtime (CLR).

Microsoft defines the CLR as the run-time environment which "runs the code and provides services that make the development process easier." That isn't the most helpful definition, so let me try to elaborate.

As I described Sunday and yesterday, the .NET compiler takes your source code from C# or whatever other language you use and compiles it down to one or more managed modules containing intermediate language (IL), which get further compiled into assemblies.

When your program runs, the CLR is the thing running it. It loads your assemblies and then handles all the tasks your program needs to survive, like memory management, thread synchronization, exception handling, security, etc. It actually does this through Just-in-Time compilation (JIT), when it translates the IL into your machine's own language. This means that when an IL instruction is executed for the second time, it runs in native CPU code.

The CLR also manages .NET's common type system (CTS), which "defines how types are declared, used, and managed in the common language runtime," according to Microsoft. Types (my topic for April 23rd) are therefore a part of every .NET program, even (gasp!) Ruby.NET. I'm picking on Ruby because in that language, ever instruction gets interpreted at run time, making it possible to use types that you haven't defined. The CLR and the CTS prevent you from doing that.

To learn a lot more about the CLR, I strongly recommend Jeffrey Richter's CLR via C#, which I mentioned Sunday.

Canine User Experience

Yesterday, the Nielsen Norman Group released groundbreaking research on user interface design for dogs:

There are several key usability guidelines that help dogs to have the most usable experience on modern websites and apps, particularly on mobile, tablet, and other touch-based interfaces:

  • Consistency is critical. While consistency in any user experience is important, with dogs, it’s even more so. Experienced dog trainers will tell you that, for dogs to learn proper behavior, consistency in enforcing routines, expectations, and commands is critical. Some common UI culprits that provide extra difficulty for dogs are swipe ambiguity, gestures without signifiers, tap uncertainty for flat UI elements like ghost buttons, and unusual placement of common elements like navigation and search.
  • Tap targets must be large. We recommend 1cm2 for human tap targets, but paws (whether belonging to cats or dogs) require larger tap sizes (of at least 3-4cm2, or even larger for Labradors and Great Danes).
  • Gestures must be ergonomic for dog physiology. While many wearable interfaces now involve gestures such as swiping left or right to dismiss notifications or switch apps, these need to be modified for more ergonomic canine movements (such as “shake”). Dogs have a greater ability to move paws with precision up and down, but dogs’ range of motion along the horizontal axis is limited and relatively imprecise, so all gestures must account for this limitation.

They also give special guidance on the risks of using hamburger menus and pie charts.

B is for BASIC

Blogging A to ZFor day 2 of the Blogging A-to-Z challenge, I'm going to talk about the first computer language I learned, which is still alive and kicking in the .NET universe decades after it first appeared on a MS-DOS 1.0 system disk: BASIC.

BASIC stands for "Beginner's All-Purpose Symbolic Instruction Code." The original specification came from John Kemeny and Thomas Kurtz at Dartmouth College in 1964. Today it's one of the core .NET languages included with Visual Studio as "VB.NET" (for "Visual BASIC," Microsoft's dialect of BASIC released in 1991).

Yesterday I showed you a "Hello, World" application written in C#. (You can download the source code here.)

Here's the VB.NET version:

Module Program

	Sub Main()
		Console.WriteLine("Hello, World!")
		Console.ReadKey()
	End Sub

End Module

What's different? Well, a lot of things: no braces, no include lines, no semicolon line endings...and that's just for a 2-line program.

But look at what's the same. Because this is a .NET program, the actual guts of it look almost exactly the same. There are two calls to different methods on the Console object, and except for the missing semicolons, they are identical to the calls in C#.

Here's the IL:

.method public static void  Main() cil managed
{
  .entrypoint
  .custom instance void [mscorlib]System.STAThreadAttribute::.ctor() = ( 01 00 00 00 ) 
  // Code size       19 (0x13)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  ldstr      "Hello, World!"
  IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_000b:  nop
  IL_000c:  call       valuetype [mscorlib]System.ConsoleKeyInfo [mscorlib]System.Console::ReadKey()
  IL_0011:  pop
  IL_0012:  ret
} // end of method Program::Main

Wow. The IL is exactly the same. So both the VB.NET and C# code compile down to functionally identical assemblies.

And that's one of the most important characteristics of .NET: it lets you write code in any language you want (as long as someone has written a compiler for it), and run it on any platform you want (as long as there's a CLR for it).

I worked with Visual BASIC from versions 1 to 6, and then did one project in VB.NET before switching to C# in 2002. You really would need to pay me a lot of money to go back to it. I believe C# is more expressive, more concise, and more able to reflect my intentions than VB.NET.

But there is nothing wrong with VB.NET. If you want to use BASIC, enjoy. With the .NET ecosystem, it's up to you.

A is for Assembly

Welcome to the Daily Parker's 2018 Blogging A-to-Z challenge!

Blogging A to ZWe're starting today with a fundamental concept in Microsoft .NET software development: the Assembly.

Microsoft defines the assembly as "a .dll or .exe file that can contain a collection of APIs that can be called by apps or other assemblies." In other words, an assembly is the basic unit of delivering .NET software to the rest of the world. An assembly "fully describe[s] and contain[s] .NET programs."

When you compile .NET source code, the compiler creates one or more of these files, each of with contains an Intermediate Language (IL) representation of your original code. You can then distribute the .dll or .exe files to any computer that has the correct version of the .NET Common Language Runtime (CLR) installed on it.

I've created a Visual Studio solution for this challenge. Today we're looking just at one small piece of it, which looks like this:

using System;

// ReSharper disable CheckNamespace
namespace InnerDrive.DailyParkerAtoZ.HelloWorld
{
	internal static class Program
	{
		// ReSharper disable once UnusedParameter.Local
		private static void Main(string[] args)
		{
			Console.WriteLine("Hello, World!");
			Console.ReadKey();
		}
	}
}

If you're new to .NET, don't worry about all the pieces. This two-line program compiles into an assembly called HelloWorld.exe, which internally looks like this:

.method private hidebysig static void  Main(string[] args) cil managed
{
  .entrypoint
  // Code size       19 (0x13)
  .maxstack  8
  IL_0000:  nop
  IL_0001:  ldstr      "Hello, World!"
  IL_0006:  call       void [mscorlib]System.Console::WriteLine(string)
  IL_000b:  nop
  IL_000c:  call       valuetype [mscorlib]System.ConsoleKeyInfo [mscorlib]System.Console::ReadKey()
  IL_0011:  pop
  IL_0012:  ret
} // end of method Program::Main

Again—we're not going to get into a lot here. Suffice to say, that IL above is what actually lives in the assembly, and what the CLR will execute when you run the program. The assembly also contains a manifest, describing what it contains, and some metadata about its version, author, and whatever else the programming team has added to the assembly info file.

As with all of the topics for this year's A-to-Z challenge, I'm only scratching the surface. There is a ton more to read online and in some solid books on the market. The best information about assemblies I've found is in Jeffrey Richter's CLR via C#.

Note: the Visual Studio Solution for this challenge requires Visual Studio 2017 and the .NET Framework v4.7. ReSharper is also recommended.

April come she will

Blogging A to ZThe A-to-Z Challenge starts tomorrow, and I'm all set to go with a list of 26 topics on programming with Microsoft .NET.

Now I just need to write the actual posts.

It's interesting to me how vacations don't actually lend themselves to much productivity, even when that's the explicit purpose of the vacation.

Anyway, if I do my job today, the first post will hit at noon UTC tomorrow. If I don't do my job today, it'll hit sometime later than that.

This guy again

Longtime readers know how much I loathe Eddie Lampert, who represents to me everything that is wrong with the adolescent philosophy emitted years ago by Ayn Rand.

Well, in next month's Vanity Fair, William Cohan sits down with the child king of hedge funds and hears him out:

[Lampert's] triumphs are largely obscured by his worst mistake: the 2005 merging of Sears, the iconic retailer whose doorstop mail-order catalogue was once a fixture in nearly every American home, with the downmarket Kmart chain, which he had brought out of bankruptcy in 2003. Twelve years on, this blundering into retail has made him a poster boy for what some people think is wrong with Wall Street and, in particular, hedge funds. Under his management the number of Sears and Kmart stores nationwide has shrunk to 1,207 from 5,670 at its peak, in the 2000s, and at least 200,000 Sears and Kmart employees have been thrown out of work. The pension fund, for retired Sears employees, is underfunded by around $1.6 billion, and both Lampert and Sears are being sued for investing employees’ retirement money in Sears stock, when the top brass allegedly knew it was a terrible investment.

The vultures are circling, waiting for Lampert to throw in the towel so they can try to make money by buying Sears’s discounted debt. But Lampert continues to claim that’s not going to happen if he can help it.

Treasury secretary Steven Mnuchin “has been a shareholder and a member of the board of directors of Sears Holdings from the day that the combined company was formed [until becoming Treasury secretary], so he spent 11 years at Eddie’s side. . . . [With] all of Trump’s focus on jobs, job preservation, job creation, somebody ought to ask his secretary of the Treasury what his involvement has been for 11 years in the destruction of well over 100,000 jobs at Sears.” (A spokesman for Mnuchin declined to comment.)

Cohan treats Lampert fairly, I think. I didn't learn a lot, though. And Lampert still runs Sears, and still will find some way to make back most of the money he, personally, has invested in it. Too bad not enough of the right people think what he did to Sears and its employees is criminal.

Staycation: Day 1

Man, I've needed this for a while.

It's 11:15 on a Monday, after doing nothing of commercial or professional value for an entire weekend, and I'm finally at Inbox Zero for the first time in months.

My to-do list currently has 30 items (plus 6 already finished) ranging in complexity or duration from "set up coffee with so-and-so" to "45,000 steps." Inbox Zero was not on the main list, but my inbox is itself a to-do list, so that counts too. In a few minutes I'll have finished with the physical items on my desk that need sorting, and then...breathe in.

Meanwhile, Parker is still not putting weight on one of his legs. We'll be stopping by the vet this afternoon. His giardia has cleared up (I think; I haven't looked that closely), and despite whatever is wrong with his leg, he's happy to walk on the three that still work properly.

Also, just a little blog housekeeping: the A-to-Z Challenge starts Sunday, so over the next week I might have fewer general posts so I can get a head start on the longer posts for April.

Blogging A-to-Z Challenge Topic 2018

Blogging A to ZAs I mentioned a couple of weeks ago, The Daily Parker will participate in this year's Blogging A-to-Z Challenge. Today's the official Theme Reveal day. My topic will be: Programming Concepts using Microsoft C# .NET.

My topics will include:

  • Compilers vs Interpreters
  • Generics
  • Human factors (and errors)
  • LINQ
  • Polymorphism

...and will finish with a real-world practical example on April 30th.

I will also keep up my annoying political and Parker posts through April. And, full disclosure, many of the 26 A-to-Z posts will be technical and more involved than just linking to a Washington Post article. Because of that, and because I want a consistent publication cadence, I'm going to write them ahead of time, even if it's just the night before.

A-to-Z posts will start at noon UTC (7am Chicago time) on April 1st and continue through the 30th, with Sundays off. You can find them directly through their A-to-Z Tag. Enjoy!

1.5 Gs

As of just a few moments ago, I passed 1.5 billion seconds old.

Yes, this is a thing most people don't really think about, but as someone who works in software, this actually has some significance—and another Y2K problem that will occur just a few months before I get to 2.0 Gigaseconds (Gs) in 2038.

The problem is a thing called the Unix epoch. Computers can only count as high as they have bits to count. Unix computers, which include Macs and most of the infrastructure of the Internet, count time in seconds from 1 January 1970 00:00 UTC, which was (at the moment I'm typing this) 1,521,383,994 seconds ago.

Everyone knows computers can count to awesomely huge numbers. But you need to give them enough bits to do that. Unix time is measured by a 32-bit number, which can count up to 232-1, or 4,294,967,295 (in binary, a 32-item string of 1s), which is enough seconds to count just over 136 years.

But you sometimes want to measure things that happened in the past, so Unix time takes the first bit of the 32-bit number and makes it a sign. If the first bit is 0, the time is in the present. If it's 1, the time is the number of seconds before the beginning of the epoch. So this cuts the measurable period in half, to 68 years. Specifically, Unix time rolls over at 3:14:08 on 19 January 2038.

The fix is simply to use a bigger number. Today, 64-bit numbers are no big deal, and they give you 263-1 (9,223,372,036,854,775,807) seconds to work with in either direction. That's roughly 292 billion years, which is sufficient to measure most human-scale activities.

So, knowing all this, and knowing that I was born in the first year of the Unix epoch, it wasn't difficult to figure out my "epoch" birth moment at 9:12 CDT this morning.

But there's a catch. As I mentioned, computers count by 2s, not by 10s, so this entire post is a lie. I'm not 1.5 Gs old; I'm just over 1,500,000,000 seconds old. 1.5 x 230 (i.e., 1.5 giga anything) is 1,610,612,736, so I won't be 1.5 Gs old until Unix moment 1,631,995,056, which will be 18 September 2021 at 19:57:36 UTC.

So check back in three and a half years. I'm sure I'll have another post about this nonsense then.

(For those of you keeping score at home, I was 1.0 Gs old on 13 September 2004 at 20:09:04 CDT, during a lull in blogging. Else I'm sure I would have mentioned this then.)