using Programming;

A Blog about some of the intrinsics related to programming and how one can get the best out of various languages.

Getting started with PHP

Getting started with PHP

I started my programming career over 15 years ago...which makes me look really old now that I think about it. When I started my career I started with HTML, then I folded some CSS in, and that's where it sat for a while. Don't get me wrong -- I was a child at the time. Eventually, I started picking up PHP, when I did I think it was version 4.2 or 4.3. That's mostly unimportant, I only learned the basic syntax and programming concepts back then. Eventually I went on to PHP 5, and now even PHP 7.

Through that time I've used a variety of languages and paradigms, but I always return to PHP as a language because it's where I started.

My career started on the web, and it then took a detour into desktop, console, and service-based applications. Now-a-days I do minimal web development, most of my time is spent building large-scale API's and platforms. So I think it's fitting that I write some information on PHP: how to get started, get your environment setup, and build great things.

Setting an Environment Up

Back when I started setting a PHP environment up felt overwhelming. Granted I was brand-new to programming at the time, but it always felt like a daunting task. Over the years it has gotten easier. Partly because I know more now than I did then, partly because of the tooling. We're not going to use any fancy tooling...we're going to do it the old-fashioned way because it's important that you understand what PHP is, and what PHP does.

PHP is just a program

When I started with PHP I thought it was this magical thing, this amazing thing that could never be understood -- and, to be fair, at the time, it was. But as I grew, I realized that PHP is just a program. Yeah, it's a complicated, intelligent, dynamic program, but it's just a program.

Like all other pieces of software on a Windows computer, PHP is just a .exe file that has some .dll files it works with. That's it. Nothing more. That said, when you look at how much is in those files, it starts to become apparent that PHP is not a simple, trivial thing, but a massive, complex system that can do so much.

To get started, we're going to download PHP and play with it before anything else. To do that, go to, and select the latest "Thread Safe x64" version. At the time of this writing, it is 7.4.6 VC15 x64 Thread Safe (2020-May-12 15:28:43). You will want the "Zip" package which should be the first option. Once you download it, extract the Zip file somewhere, and open the folder in PowerShell.

PHP REPL / Interactive Shell

Once you have a PowerShell window open, launch the "PHP interactive shell" with the command:

./php -a

It should print "Interactive Shell", then prompt with php >. At this point, we can type some valid PHP in. For example, we could type echo "Hello World"; and then press enter, after which it should print Hello World, then take us back to the php > prompt.

At this point we are in something called a "REPL", or "Read, Evaluate, Print Loop." Different languages call it different things, in PHP it's the "Interactive Shell", in F# we call it "F# Interactive" or fsi, in Python it's the default action of the command python. The overall idea here is that a REPL, or interactive shell, is a common feature of many programming languages.

Anyway, we're going to play with PHP in the REPL briefly. We want to familiarize ourselves with the idea that PHP is nothing special, and go over some very basic PHP syntax. And I mean very basic.

PHP: Statements end with a semi-colon

The first rule of PHP: all "statements" end with a semi-colon (;). What a "statement" is doesn't matter at the moment, but understand that most lines should have a semi-colon at the end. If you get a PHP error about "unexpected , expected ';'", that's what happened.

PHP: echo

To start with, the echo we used above is just a little bit of magic. What echo does is print a string to the "output" tied to the PHP processor. In a web scenario that's the HTTP session, in our REPL it is our console (which is why we just see it as another line after we press enter).

Essentially, echo says "send this to whoever is running our code."

You can give echo any value, but it will try to print the "string" version of the value. For a number, that's the base-10 equivalent (i.e. 15), for a string it would be just the string, for an object you might get some odd results because the object may not have a "string" equivalent defined.

PHP: Variables

Next, let's briefly go over variables.

A "variable" is a name we use that contains a value. In PHP variables are not declared prior to use (that means that we can make a new variable whenever we want), and they can change types throughout usage (which means we can change a variable from a number to some text to a group of other values).

Declaring a variable in PHP is extremely simple: use the dollar-sign ($) and then any name you like so long as it starts with a letter or underscore and does not contain spaces: $some_variable for example. Once you've named it, you use a single equal-sign and then any value to set it: $my_name = "Elliott";. At this point, we can now reference $my_name later in the program and it will be set to "Elliott":

$my_name = "Elliott";
echo "Hello $my_name";

If you run this in the REPL, it should print Hello Elliott.

We didn't talk about this before, but you can embed variables directly in a string: "Hello $my_name" causes PHP to replace $my_name with the value stored in that variable, in this case, "Elliott".

Another way to do this is "string concatenation", which is necessary sometimes.

PHP: String Concatenation

String concatenation is pretty simple. As the name implies, it is taking two things and constructing a string out of them. (Note: the two things don't need to be strings, they will get converted to strings if they are not already.)

String concatenation is achieved simply by putting a "dot" (.) between two values. Typically, when we do this we include a "space" on either side of the dot, such as: echo "Hello " . $my_name;. This will print the exact same thing as our echo "Hello $my_name";, but there are situations where you will need to use string concatenation.

Also, notice how our "Hello " includes the space between the word Hello and $my_name: this is important because the string concatenation / dot operation will directly combine the two strings, there will be no whitespace added.

PHP: Flow Control

Whether you've programmed before or not, you may not immediately understand what 'flow control' means, but it's typically a pretty simple thing.

Flow control is how a program decides between multiple options of what to do next. It's a way of changing the path the program will take. Imagine a train approaching a track-split. Obviously the train has to go left or right, it can't go both, so we use "flow control" to push it one direction or the other: PHP has similar constructs.

The simplest form of flow control in PHP is the if / elseif / else statement, where elseif and else are both optional. An if statement basically says "evaluate the condition in this statement, and execute the code in the body of the statement when the evaluation turns out to be true." The question is: what is true?

PHP: True and False

Most programming languages have the idea of a "boolean". That is, a value which is only allowed to be one of two options: TRUE, or FALSE. There are no other possible options.

PHP has a pretty large set of methods for deciding if something is TRUE or FALSE, but while it's a lot of decisions, it's rather straightforward. I'll be pulling from, but the following values are considered FALSE, all others are TRUE:

  • the literal boolean constant FALSE;
  • the integers 0 and -0;
  • the floating-point / decimal values 0.0 and -0.0;
  • an empty string ("");
  • a string of "0";
  • an array that has zero elements ([] or array());
  • the type NULL;
  • unset variables;
  • a SimpleXML object created from an empty tag;

Every other value is considered TRUE at the time of this writing. The rules may change, so it's recommended to visit the documentation on the subject.

Back to Flow Control: Testing Conditions

So now that we understand TRUE and FALSE to a limited degree, we can go back to flow control. In order for an if statement to make a decision, it has to evaluate if the condition is TRUE or FALSE.

To evaluate conditions, we need a way to test things, and PHP supplies that via various operators:

  • ==: test if two items are "mostly the same" (we'll go deeper into this later);
  • ===: test if two items are identical (we'll go deeper into this later);
  • != and <>: test if two items are not "mostly the same" (opposite of ==);
  • !==: test if two items are not identical (opposite of ===);
  • >: test if one item is greater than another item;
  • <: test if one item is less than another item;
  • >=: test if one item is greater than or equal to another item;
  • <=: test if one item is less than or equal to another item;
  • <=>: indicate whether one item is less than, equal to, or greater than another item (we'll go deeper into this later);

For now, we're going to ignore ==, !=, and <=>, then we'll talk about the three of them at a later time.

So, to test a condition we will use === to determine if our name is equal to a comparison: $my_name === "Jon". If $my_name was set to "Jon" before this line, then the result will be TRUE, if it was not, then the result is FALSE.

After we test our condition, we create a new "scope" within the if that has the code we want to run. This is achieved by putting an opening brace ({) after the if, and a closing brace (}) after the code we want to run.

Afterwards, we can use an else in the same way to do something different if our condition was not true.

In PHP, we do this simply by putting it all together with parenthesis around our condition as follows:

if ($my_name === "Jon") {
    echo "You owe me a lot of money, Jon.";
} else {
    echo "Hello $my_name";

You'll notice, if you type the first line into the PHP REPL, it gives you php { for the next line instead of php >, this is because the REPL recognizes that you opened a new scope and did not close it yet, so it is going to wait for more code.

Setting up a web environment

Ok, long-winded intro to PHP complete, it's time we setup a web server to process PHP files. This is actually a relatively straightforward process. In many cases you'll find people refer to these as a stack with one of the following names: LAMP, LAPP, LAP, WAMP, WAPP or WAP. What does this all mean?

  • LAMP: Linux, Apache, MySQL, PHP
  • LAPP: Linux, Apache, PostgreSQL, PHP
  • LAP: Linux, Apache, PHP
  • WAMP: Windows, Apache, MySQL, PHP
  • WAPP: Windows, Apache, PostgreSQL, PHP
  • WAP: Windows, Apache, PHP

We're going to setup a WAP server, someday we might make it a WAMP or WAPP server, but for now we don't need any "SQL" component.

If you're running Windows, congratulations! You have the first thing setup. If you're not...I have some bad news: my examples will all be for Windows.

Next, we need to setup Apache and PHP. We'll setup Apache, then we'll tag PHP in.

To setup Apache we need to download a Windows version. The Apache Software Foundation keeps a list of Windows third-parties on their website. We're going to use the Apache Lounge version, which is Apache 2.4 VS16 / VC15 x64 / Win64:

You will also need the Visual C++ Redistributable for Visual Studio 2015-2019 if you do not have it already. Fortunately, Apache Lounge provides a link to a version of it:

Install the redistributable first, then we can setup Apache.

Setting up Apache

Once the redistributables are installed, we can setup Apache. Fortunately, Apache Lounge makes it easy to get things installed. We will install Apache as a service, which means it will start on system boot and logs will be managed by Windows.

We want to put Apache somewhere memorable. For you, I don't care where you put it, but I'm going to put mine under C:\Web\ so that it's somewhere memorable. We want to copy the contents of the Apache24 folder of our download to wherever we decided. With the default setup structure, our web root will be <apache root>\htdocs, so mine will be C:\Web\htdocs.

Once we have Apache copied to our root folder, we need to grab that path (C:\Web in my case) and open the conf\httpd.conf file. Near the top (in my case, line 37) should be a Define SRVROOT ... line, which we will need to modify to the path we are using. Again, we'll use my case:

Define SRVROOT "C:/Web"

Once we've done that, save the file. We're ready to install and run Apache.

To install Apache, open an Admin PowerShell session in the bin folder under your Apache install (C:\Web\bin in my case) and run the following:

.\httpd.exe -k install -n "Apache HTTP Server"

If you get the following error you can ignore it:

AH00558: httpd.exe: Could not reliably determine the server's fully qualified domain name, using <some IPv4 or IPv6 address>. Set the 'ServerName' directive globally to suppress this message

This just means that Apache could not identify a DNS name (such as "") to use. We could specify one, but we don't have one.

Once that is complete, run Get-Service ApacheHttpServer in your PowerShell window, and you should see the following:

Status   Name               DisplayName
------   ----               -----------
Stopped  ApacheHttpServer   Apache HTTP Server

This means that the service has been installed successfully.

Next, run Start-Service ApacheHttpServer, then run Get-Service ApacheHttpServer when that completes. You should see:

Status   Name               DisplayName
------   ----               -----------
Running  ApacheHttpServer   Apache HTTP Server

If all went well, Apache is installed and, more importantly, running. To verify, open a web browser and navigate to http://localhost. You should see a very basic page with the text "It works!"

Adding PHP to Apache

Now that Apache is installed, we need to get back into the PHP folder we downloaded and played with earlier.

First, turn Apache off. You can do this with Stop-Service ApacheHttpServer and then running Get-Service ApacheHttpServer to verify.

Create a folder named php inside your Apache root, for me this is C:\Web\php, copy the files from the PHP 7.4.6 x64 Type Safe download into this folder.

Copy the php.ini-development in your new php directory and rename it to php.ini, mine is C:\Web\php\php.ini.

We will need to edit this new php.ini, so go ahead and open it.

Locate the extension_dir settings (on my version, this is line 755) and uncomment the Windows line (757 on my version) by removing the semi-colon (;) from the beginning, then add your PHP root before the ext, mine looks like:

extension_dir = "C:/Web/php/ext"

Next, we need to edit our httpd.conf.

We want to find the DirectoryIndex line (on my version this is line 285). We want to add index.php before index.html, so the line should read:

DirectoryIndex index.php index.html

Next, we need to add the PHP configuration to Apache. To do this, go to the end of the httpd.conf file and add the following, replacing C:/Web with your Apache root directory:

LoadModule php7_module "C:/Web/php/php7apache2_4.dll"
AddType application/x-httpd-php .php
PHPIniDir "C:/Web/php"

Once that is complete, run Start-Service ApacheHttpServer and then Get-Service ApacheHttpServer to verify.

If Apache restarted properly, load http://localhost again to verify that Apache is running. Notice that you still see "It works!" because we haven't added any PHP code yet.

Add an index.php file in your htdocs location (mine is C:\Web\htdocs), and let's add some PHP:


All PHP pages must use <?php to indicate the start of PHP code, and ?> to indicate the end of PHP code if the file does not end in PHP code.

Once you do this, load http://localhost, and we should finally see a very nice-looking page that has our PHP version listed at the top ("PHP Version 7.4.6" at the time of this writing) and talks about our PHP installation.

Adding some PHP and Apache features

Once your PHP and Apache install is verified, let's add some more features we may or may not use in future tutorials.

To start with, update httpd.conf and do the following:

  1. Locate rewrite_module in the file (mine is line 162);
  2. Uncomment the pound-sign / number-sign (#) at the beginning;

Next, open the php.ini file and do the following:

  1. Locate extension=curl in the file (mine is line 910) and uncomment the line by removing the semi-colon (;) at the beginning;
  2. Locate extension=gd2 in the file (mine is line 914) and uncomment the line by removing the semi-colon (;) at the beginning;
  3. Locate extension=mbstring in the file (mine is line 920) and uncomment the line by removing the semi-colon (;) at the beginning;
  4. Locate extension=mysqli in the file (mine is line 922) and uncomment the line by removing the semi-colon (;) at the beginning;
  5. Locate extension=pdo_mysql in the file (mine is line 927) and uncomment the line by removing the semi-colon (;) at the beginning;
  6. Locate extension=pdo_pgsql in the file (mine is line 930) and uncomment the line by removing the semi-colon (;) at the beginning;
  7. Locate extension=pgsql in the file (mine is line 932) and uncomment the line by removing the semi-colon (;) at the beginning;

Save both of these files and restart Apache. If you don't want to go through stopping and starting the service, you can edit these files while it is running (though none of your changes will take effect) then use Restart-Service ApacheHttpServer and then Get-Service ApacheHttpServer.

Once you have done this, reload your http://localhost page to verify.

  • Find the apache2handler section, and then the "Loaded Modules" cell, and verify that mod_rewrite is in the list;
  • Find the gd section and verify the "GD Support" cell says enabled;
  • Find the mysqlnd section and verify the "API Extensions" cell says mysqli,pdo_mysql;

You may not find all the extensions we enabled in your index.php, and that is OK: some extensions have prerequisites we did not enable. The pgsql and pdo_pgsql require a PostgreSQL driver that is not provided, for example.

All Set

Now that all this is done, we have completed our WAP installation: Windows + Apache + PHP. The next post will start getting into writing more PHP, specifically getting into more topics like looping, functions, and passing data around. As we get into these topics, I will be describing some of the "good practices" around them. (Note: some folks, including myself and past-me, call these "best practices", but I don't know if they are or not. I call them "good practices" because they're things I like to see when looking at someone else's code.)

F# Advent 2019: Dawn of the F# Domain Types

If you use .NET, build your objects in F#

So towards the end of October, I tweeted (as one does) about building domain objects and models in F#. I mentioned a few nice things about it, so today I intend to do a deeper dive into some of those nice things, and talk about why they are concerns you should keep in the back of your head when you make a decision about how to build your domain models.

Now it's no secret that I like F#. I talk about it a lot (among many other things), largely because when I am doing .NET work, there is almost always some F# involved. (It might be a small portion, or it might be a large portion, depends on the project.) As a result, if you've ever spoke with me in person about programming, I've probably talked about it.

Today, I'm going to show you why F# is a very cool tool in the .NET ecosystem, and how F# fixes a lot of class-oriented things that, in my opinion, C# does wrong.

F# does a lot of the heavy-lifting for object-oriented work

One of the most impressive things I feel F# has to offer is the level of generation it offers for object-oriented work. How it can give you a lot of things you usually spend a good chunk of time on for free. Three lines of F# can do something that would take, genuinely, dozens (or even hundreds) of lines of C#.

If you've ever done OOP work, chances are you've had to write a .ToString(), or a .Equals(object), or a .GetHashCode(). Spoiler alert: with F# you don't need to write any of those most of the time. (You can, but it's ill-advised.)

Let's take a common game-development scenario in C#: vectors. In physics, a vector is a distance and direction. Start at the origin (or point (0,0)), then adjust position from there based on the direction given, and the distance, move to the new location.

Commonly, we represent them in one of two ways:

  • r, Θ
  • x, y

You are likely familiar with the (x, y) format: this is standard point representation for the cartesian coordinate system. The (r, Θ) format is common in polar coordinate systems.

Long-winded math aside, the two values can be translated between. We'll build a sizable Vector2 feature-set into our program, and see how the F# and C# of the implementation vary.

A standard C# starting point might be something like the following:

public class Vector2 
    public int X { get; set; }
    public int Y { get; set; }

In F#, we would do something like the following:

type Vector2 = {
    X : int
    Y : int

Alright, so far F# hasn't really lived up to the promise. It's the same length as the C#, and we don't really see any advantages.

Fair. We haven't done anything to really take advantage of F# yet, but one of the things we already have is an implementation of .ToString(), .Equals(object), and .GetHashCode(). It also implements IEquatable<Vector2>, IStructuralEquatable, IComparable<Vector2>, IStructuralComparable, and IComparable.

I could go into a large digression on the intermediate language generated and how it works, why it's important, etc., instead, I'm going to just use a quick screenshot of the generated F# class (left) to the generated C# class (right).

F# and C# comparison

Wow are those different. F# implemented 9 additional methods and even setup a constructor for us. Not so bad. The C# version, on the other hand, is just the two properties. So really, our 4 lines of F# is equivalent to a lot, lot more in C#. In fact, the F# version is even immutable. Sure, we could omit the set in the C# to achieve the same, but then we have to define our own constructor. My point with this first example is to demonstrate how effective F# is at generation. We'll dig deeper into what it means in a few moments.

Now, I could stop here, and I suppose if I were publishing this right now I might, but today I'm going to go a little further.

Why is all this F# generation important?

This is probably the more important part to discuss: why is the generation F# provides so important? Why do I push it as such a major reason to build objects in F#?

It all boils down to a couple basic points:

  1. Structural equality and comparison is important for doing effective matching and evaluation of objects against one-another.
  2. These few functions are extremely important if the object itself is to be used in a HashMap scenario. (I.e. a dictionary key, etc.)

Basically, it boils down to performance and developer ease. A lot of times we want to be able to do something like if a = b then ..., but we find out that there is no = operator between a and b, even when a and b are the same type. So you go ahead and define your own operator, just to need to define a .Equals(object) method and then .GetHashCode(). You will also want both of these implemented if you are using LINQ, as some of the LINQ methods / query syntax require them.

Unfortunately, in C# we don't get those features. Instead we only have a base implementation (the default) for both Equals(object) and GetHashCode(). The base implementations don't do structural equality at all, so two objects that are exactly the same might not match via .Equals(object). (Spoiler: unless they are the exact same instance, they won't match via the default.)

This also comes in to heavy play with struct types, as it's expected that two structures (which are expected to be value types) that are instanced via the same values would be the same. But alas, by default, they are not such in .NET.

So, let's look at some situations we would have to write a lot of manual code for in C#, that F# just gives us.

Scenario 1: you want to determine if an element is in an array.

Let's assume you have an array of elements, and you want to determine if you have a certain element in the array. With the new LINQ syntax in C#, it should be rather simple, no?

var find = new Vector2() { X = 1, Y = 2 };
var results = elements.Where(x => x.Equals(find));

Seems reasonable, should work fine. Except it wont. The problem here is that we don't override .Equals(object), and we don't have a .Equals(Vector2), so our default C# version won't work. Our F# version will work fine though, as we have both of those options in the F# version. One note: for the F# version we must initialize find via the constructor, because it's immutable (which lends well to a later point).

To get the C# version to work, we really just need to pick one of the two to implement, though for fairness we'll actually implement both.

public override bool Equals(object other) => Equals(other as Vector2);
public bool Equals(Vector2 other) => other != null && X == other.X && Y == other.Y;    

So we added two lines (at a minimum) to our C# to make sure this works, but we end up with working code, so we are done here.

First note: your IDE might state that you didn't override GetHashCode(), and it's entirely correct! It's always a best practice to override both if you are doing one of them. Second note: you might find that the two lines printed by the C# version are different than the F# version, and they are. The F# version has a custom .ToString() implementation, which means when we do a print line for it, we get a nicer string.

Scenario 2: you have two collections, and you want to create the collection of the elements present in both.

This scenario is your basic Intersect scenario: you have some elements1 in one collection, and some more elements2 in another collection. You want to create a single collection that encompasses only those elements that are present in both collection.

You might write some code like the following:

var results = elementsA.Intersect(elementsB).ToArray();

In the C# version, you'll find that no elements match no matter how you call the Intersect function, and that the F# version gives you some.

Again, we're missing a key piece, I alluded to it earlier: GetHashCode(). We need it for Intersect to work properly.

So, we'll create a poor implementation:

public override int GetHashCode() => X ^ Y;

Now the C# version works fine.

Note here: the F# GetHashCode() is a good implementation, ours was a poor attempt to make sure that we got something in place for .NET to use. In .NET, it's OK for two different elements to return the same code, because Equals(object) is the final decision maker, but two identical elements may NOT return different hash codes.

At this point, I wanted to go into some performance implications of the C# classes vs. the F# generated objects, but because this post is already long, and also because it's Christmas, I'm going to save that discussion for a later date. In fact, I'm going to target mid-January for that discussion. That said, I recommend doing some tests of the C# vs. F# objects, and especially in usage as dictionary keys. You might find some interesting results.

Additionally, this is all up on GitHub, so feel free to play with the exact code I was using to test our setups.

You're Logging Wrong: Stop It

You're taking Dependencies Wrong

Specifically, you're logging wrong.

Here's the deal, we all at some point think "Oh, I need to log some information, better write an abstraction!"

Because we programmers are too afraid (or arrogant) to take dependencies on someone else's "stuff", we always write our own abstractions. They're usually subtly different, but the 99% similarities are:

  1. An ILogger interface of some sort;
  2. A Log(Severity, message) in the ILogger;
  3. Two or three generic logger implementations;

This is basically the bulk of what most implementations call for. Always something like this.

This might look something like the following, in C#:

public enum LoggerLevel : byte
    Error = 0,
    Warning = 100,
    Information = 200,
    Verbose = 255

public interface ILogger
    void Log(LoggerLevel level, string msg);
    void Log<T>(LoggerLevel level, T obj);

Right? This probably looks familiar. This is a pretty common pattern, so common I call it the "logger pattern."

The purpose is to make it easy to say "Ok, here's an ILogger, do your thing." We have a logger sample for something like an in-memory buffer:

public class BaseLogger : ILogger
    private List<string> messages = new List<string>(10000);

    public void Log(LoggerLevel level, string msg)

    public void Log<T>(LoggerLevel level, T obj)

And we say "great, things are done."

Here's the deal: this is wrong.

What's wrong with ILogger?

Well, just about everything.

  1. It requires an implementation for every target logger, this means a lot of boiler-plate code, etc.;
  2. We always mess it up with trying to support "common" targets (AutoFac, for example);

A great person named David Fowler tweeted about this a few days ago:

This is what the .NET library ecosystem looks like today. Say you develop an interesting library/framework that calls into user code and also does some interesting logging (lets call this library A). A customer comes along and wants to use Autofac and log4net.

They file a feature request on your repository and you do what a good software engineer would do, you make an abstraction, A.ILogger and A.ICanActivateYourCode and you make 2 new libraries. A.Log4Net and A.Autofac. Rinse and repeat this process with libraries A to Z

What you end up with are different abstractions that all look the same but nobody wants to take a dependency because that's a big deal. What if it's the wrong one, what if that package goes away? The benefit needs to be huge in order for your core library to pull more deps.

So a customer that wants to use A, B and C with log4net and autofac install. A, B, C and A.log4Net, A.Autofact, B.log4Net, b.Autofac, C.log4net, C.Autofac.

I call this glue library hell. There are insufficient shared abstractions that exist, therefore everyone makes their own.

Not to mention you have to hope that enough of the API for the underlying libraries are appropriately exposed so that you have a consistent way to configure them.

David's point was that we have a million of the same implementations, but they're ever-so-slightly different.

So what's the 'right' way?

Ah yes, what is the 'right' way?

Well, due to the nature of logging, we are always adding a message / thing to the log, we're never actually doing anything else. As a result, the "right" way to take a logging dependency is not ILogger, but is instead an Action<string>. That is: a function that you pass a message to.

Wait, what do you mean?

Back to our original example, let's say we have a function DoWork, and DoWork takes an ILogger:

private static void DoWork(ILogger logger)
    for (var i = 0; i < COUNT; i++)
        logger.Log(LoggerLevel.Information, "Test");

This seems straightforward. "Yeah, you log the whatever with the Log method on the ILogger." Sure, makes sense.

Calling this is straightforward:

ILogger logger = new BaseLogger();

And viola: we have logging.

But, we want to log with a function instead, so we replace DoWork:

private static void DoWork(Action<LoggerLevel, string> logger)
    for (var i = 0; i < COUNT; i++)
        logger(LoggerLevel.Information, "Test");

Now, instead of taking the ILogger directly, we'll take the Log function:

Action<LoggerLevel, string> logger = new BaseLogger().Log;

Curiously, this makes life much easier on the consumer, as now they don't need a ILogger implementation (and that whole abstraction is just gone), instead, they pass a function.

This means that the consumer can say "here's a function that logs to AutoFac", or "here's a function that logs to log4net", etc.

Even moreso: our implementation is now compatible with any other utility using a logger (should they all use function logging). The same function can be slightly reworked for each utility, assuming they don't share a LogLevel. You just wrap it with a very quick lambda and life is good.

But wait, there's more.

There's one more thing here we should evaluate, which is the obvious: what about performance?

Ah yes, the age-old "is it fast, though?" question.

Everyone wants to make sure their code is fast, they want to make sure they don't have any performance loss. Why? I don't know, it's always something superficial.

So, is it fast? This is a good question, I guess.

Of course, me being me, I benchmarked various types of logging and threw it on GitHub, but the overall consensus was: it is as fast, or faster.

(Sidebar: the nop in the F# version is because of this bug. Looks like Don Syme has thoughts on how we can fix it.)

The Full Results

So I just ran my benchmark alet it do it's thing, I've put the full result below:

// * Summary *

BenchmarkDotNet=v0.11.4, OS=Windows 10.0.17134.407 (1803/April2018Update/Redstone4)
Intel Xeon CPU E3-1505M v6 3.00GHz, 1 CPU, 8 logical and 4 physical cores
.NET Core SDK=3.0.100-preview-010184
  [Host]     : .NET Core 2.1.7 (CoreCLR 4.6.27129.04, CoreFX 4.6.27129.04), 64bit RyuJIT
  DefaultJob : .NET Core 2.1.7 (CoreCLR 4.6.27129.04, CoreFX 4.6.27129.04), 64bit RyuJIT

|                  Method |      Mean |      Error |     StdDev |    Median | Ratio | RatioSD | Gen 0/1k Op | Gen 1/1k Op | Gen 2/1k Op | Allocated Memory/Op |
|------------------------ |----------:|-----------:|-----------:|----------:|------:|--------:|------------:|------------:|------------:|--------------------:|
|               LogDirect |  33.42 us |  0.4143 us |  0.3673 us |  33.36 us |  0.62 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
|             LogDirectFs |  35.46 us |  0.6995 us |  1.4755 us |  35.60 us |  0.68 |    0.04 |     18.8599 |      3.7231 |           - |            78.21 KB |
|         LogViaInjection |  53.94 us |  0.5640 us |  0.4710 us |  54.11 us |  1.00 |    0.00 |     18.8599 |      3.7231 |           - |            78.21 KB |
|       LogViaInjectionFs |  56.81 us |  0.9890 us |  0.8259 us |  56.72 us |  1.05 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
|          LogViaCallback |  47.99 us |  0.5204 us |  0.4868 us |  47.91 us |  0.89 |    0.01 |     18.8599 |      3.7231 |           - |            78.27 KB |
|        LogViaCallbackFs |  50.81 us |  0.3474 us |  0.3250 us |  50.81 us |  0.94 |    0.01 |     18.8599 |      3.7231 |           - |            78.27 KB |
|            LogObjDirect | 666.71 us | 12.3811 us | 12.7145 us | 664.47 us | 12.38 |    0.32 |    185.5469 |     92.7734 |           - |          1093.84 KB |
|          LogObjDirectFs | 668.30 us |  8.1078 us |  6.7704 us | 664.00 us | 12.39 |    0.15 |    185.5469 |     92.7734 |           - |          1093.84 KB |
|      LogObjViaInjection | 709.30 us | 12.1255 us | 11.3422 us | 706.69 us | 13.14 |    0.26 |    185.5469 |     92.7734 |           - |          1093.84 KB |
|    LogObjViaInjectionFs | 705.13 us |  6.9833 us |  6.5322 us | 705.46 us | 13.07 |    0.18 |    185.5469 |     92.7734 |           - |          1093.84 KB |
|       LogObjViaCallback | 671.84 us |  6.9447 us |  5.4220 us | 673.47 us | 12.44 |    0.11 |    185.5469 |     92.7734 |           - |           1093.9 KB |
|     LogObjViaCallbackFs | 669.24 us |  4.6712 us |  3.9007 us | 670.10 us | 12.41 |    0.09 |    185.5469 |     92.7734 |           - |           1093.9 KB |
|         LogInlineDirect |  33.32 us |  0.3477 us |  0.3253 us |  33.24 us |  0.62 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
|       LogInlineDirectFs |  33.43 us |  0.4313 us |  0.4035 us |  33.34 us |  0.62 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
|   LogInlineViaInjection |  33.68 us |  0.6655 us |  0.7121 us |  33.39 us |  0.63 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
| LogInlineViaInjectionFs |  35.91 us |  0.8274 us |  2.4267 us |  35.15 us |  0.64 |    0.03 |     18.8599 |      3.7231 |           - |            78.21 KB |
|    LogInlineViaCallback |  49.10 us |  0.6939 us |  0.6491 us |  49.02 us |  0.91 |    0.01 |     18.8599 |      3.7231 |           - |            78.27 KB |
|  LogInlineViaCallbackFs |  51.15 us |  0.5555 us |  0.5196 us |  51.01 us |  0.95 |    0.01 |     18.8599 |      3.7231 |           - |            78.27 KB |
|  LogInlineDynamicDirect |  76.38 us |  1.4895 us |  1.9884 us |  75.43 us |  1.43 |    0.05 |     18.7988 |      3.0518 |           - |            78.21 KB |

That's a lot of benchmarking. Let's crop that down:

|                  Method |      Mean |      Error |     StdDev |    Median | Ratio | RatioSD | Gen 0/1k Op | Gen 1/1k Op | Gen 2/1k Op | Allocated Memory/Op |
|------------------------ |----------:|-----------:|-----------:|----------:|------:|--------:|------------:|------------:|------------:|--------------------:|
|               LogDirect |  33.42 us |  0.4143 us |  0.3673 us |  33.36 us |  0.62 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
|         LogViaInjection |  53.94 us |  0.5640 us |  0.4710 us |  54.11 us |  1.00 |    0.00 |     18.8599 |      3.7231 |           - |            78.21 KB |
|          LogViaCallback |  47.99 us |  0.5204 us |  0.4868 us |  47.91 us |  0.89 |    0.01 |     18.8599 |      3.7231 |           - |            78.27 KB |

Those are the three lines I want to look at.

First and foremost: the fastest way is to pass the BaseLogger class in directly (i.e.: no ILogger interface usage). That was pretty obviousl.

But, the next, interesting note is that the interface version is actually about 6us slower than passing the function within the interface. This is curious, not only is passing the function a more proper way to do it, but it's also ever-so-slightly faster. (Granted, the margins are tiny and statistically meaningless, but it does prove that there is not discernable performance disadvantage, so that argument is now completely irrelevant.)

The only "bad" difference is that there was an extra 0.06KB allocated, but I assume that's overhead for Action<>. It's also such a tiny amount that if you're using that (or the time, to be completely frank) for justification, you are not making the right decisions.

The only time the interface is a better option is if you are not passing it, but are doing things inline:

|                  Method |      Mean |      Error |     StdDev |    Median | Ratio | RatioSD | Gen 0/1k Op | Gen 1/1k Op | Gen 2/1k Op | Allocated Memory/Op |
|------------------------ |----------:|-----------:|-----------:|----------:|------:|--------:|------------:|------------:|------------:|--------------------:|
|         LogInlineDirect |  33.32 us |  0.3477 us |  0.3253 us |  33.24 us |  0.62 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
|   LogInlineViaInjection |  33.68 us |  0.6655 us |  0.7121 us |  33.39 us |  0.63 |    0.01 |     18.8599 |      3.7231 |           - |            78.21 KB |
|    LogInlineViaCallback |  49.10 us |  0.6939 us |  0.6491 us |  49.02 us |  0.91 |    0.01 |     18.8599 |      3.7231 |           - |            78.27 KB |

Here, you'll note that the overhead of Action<> actually puts the callback version at a significant disadvantage, and a discernable disadvantage in this case.

In Summation

To summarize our discussion:

  1. Don't make an ILogger, it's unbecoming.
  2. Use an Action or Function, it's much more dynamic and reusable.
  3. The only time this is not the case is when the logger is constructed inline with the thing being logged. Then use a regular function or class.

F# / .NET: "Gotcha's"

Recently I've been digging more-and-more into F#, so I want to start putting together a list of things that I occasionally (or regularly) run into that new users of the language (or even those who are substantially experienced) might not have a great time with.

I'll be notating if it's a general .NET "gotcha", or an F#-specific "gotcha."



If you have something you want to see in the list, please let me know either via Twitter or as a comment. I'll try to check back here regularly to keep this list as up-to-date as possible.

Importing F# to the SQLCLR (T-SQL)

Bringing F# into the SQLCLR

It's been some-time since my last post, and don't worry, we're still going to continue the IMAP server. I've been swamped at work, and as a result, haven't had the time to properly dedicate to writing these posts (especially that series, which is a complex topic).

Excuses aside, today we're going to talk about something I recently did for work, which is integrating F# into the SQLCLR (part of Microsoft SQL Server).

For those who don't know, the SQLCLR is a feature of SQL Server that allows one to import .NET assemblies as user-defined functions, or stored procedures. On it's own it doesn't sound impressive, but the SQLCLR allows us to significantly improve performance in some cases, and moderately improve it in others.

I won't go into detail explaining the SQLCLR, a gentleman by the name of Soloman Rutzky does that quite well. I'll let his "Stairway to SQLCLR" give you the introduction.

No, what I'll do today is show you how to import F# into the SQLCLR, instead of just C# or VB.NET. The process is about as straightforward as Soloman describes, but there are a few "gotcha's", so I'm going to include those in our discussion here today.

Without further ado, let's get started.

First: create the project and add the System.Data reference

The first step is obviously to create a project to hold our SQL code. The project should be an F# Class Library, in .NET Framework (I'm using 4.7.1 and F# Core You'll want a module for the functions, and in that module you'll want to open Microsoft.SqlServer.Server, and System.Data.SqlTypes.

Once we've done that, we'll build a function. There are a few rules to creating a function in .NET that can be seen by SQL Server:

  1. The function must have the SqlFunction attribute;
  2. All inputs must be tupled;
  3. All input and output types must be a Sql[Something] type (SqlDouble, SqlInt, etc.);

So, for our example we're going to use a real-world example from my work: distance calculation from two geo-coded points.

To do this, we'll build a function that takes 4 double values: two Latitude/Longitude value sets.

let calculateDistance (fromLat : SqlDouble, fromLon : SqlDouble, toLat : SqlDouble, toLon : SqlDouble) : SqlDouble

That's the signature we'll use, next, we want to define how SQL should treat the function:

    IsDeterministic = true,
    IsPrecise = false,
    SystemDataAccess = SystemDataAccessKind.None,
    DataAccess = DataAccessKind.None)>]

This is where life gets special, so let me explain them piece-by-piece:

  • SqlFunction: this is just the attribute we use, there is also SqlProcedure for stored procedures;
  • IsDeterministic = true: this value should ONLY be set to true if the function is deterministic, that is, given any input value, it returns one and exactly one output, and that two calls to the function with the same input will result in the same output;
  • IsPrecise = false: this value should ONLY be set to true if the function uses the DECIMAL or NUMERIC types, and does precise mathematical calculations;
  • SystemDataAccess = SystemDataAccessKind.None: I'll be completely honest with you, I don't know what the difference between this and DataAccess are, but if you do any reading/writing to/from SQL, you should set it to Read, otherwise, probably use None (there's a small performance cost to setting this to Read, I leave it to you to decide whether or not to do so);
  • DataAccess = DataAccessKind.None: see above;

So basically, what we did here is define a function and tell SQL what it should expect the function to do. One of the most impotant parts is the IsDeterministic flag: this tells SQL that if it called the function for a set of values, it can reuse that result for any subsequent calls with the same set of values. This means it can memoize the results. If your function has side-effects, do not set this flag to true, or you will get weird results. Basically, if your function is truly "pure" (no side-effects), mark it with IsDeterministic = true.

Next: write the code

Alright, so we've covered the hard parts, next, we write the function.

My version of this function used some logic that was specific to my workplace, so I'm going to remove it and we'll write a vanilla function:

let constMod = 1.852 / 1.61 * 60.
let divPi180 = Math.PI / 180.
let div180Pi = 180. / Math.PI

    IsDeterministic = true,
    IsPrecise = false,
    SystemDataAccess = SystemDataAccessKind.None,
    DataAccess = DataAccessKind.None)>]
let calculateDistance (fromLat : SqlDouble, fromLon : SqlDouble, toLat : SqlDouble, toLon : SqlDouble) : SqlDouble =
    let fromLat = fromLat.Value
    let fromLon = fromLon.Value
    let toLat = toLat.Value
    let toLon = toLon.Value

    let fromLat = fromLat * divPi180
    let toLat = toLat * divPi180
    let fromLon = fromLon * divPi180
    let toLon = toLon * divPi180

    constMod *
        ((Math.Sin toLon) * (Math.Sin fromLon) +
         (Math.Cos toLon) * (Math.Cos fromLon) * (Math.Cos (toLat - fromLat))))
    |> SqlDouble

This should be self-explanatory: we basically convert the data and do some simple math on it.

Third: enable SQLCLR

Alright, so that's that entirety of our .NET code.

Now, we need to enable the SQLCLR, because it's disabled by default.

The SQLCLR can be enabled through GUI or T-SQL, I prefer to do it through GUI because I typo a lot.

To enable it:

  1. Right click your server in SSMS;
  2. Click "Facets";
  3. In the "Facet" dropdown select "Surface Area Configuration";
  4. Change "ClrIntegrationEnabled" to "True";
  5. Click "OK";

Easy enough.

Fourth: trust the assembly, and import it

This is one spot where things aren't completely awesome: the FSharp.Core library isn't built to natively support a "SAFE" import to SQLCLR, so we have to trust it first.

To trust the assemblies, we'll want to get a SHA2_512 hash of them, and optionally, a description.

I, personally, don't care so much about the description at the moment, so I'll leave that out and let you locate it if you like. Instead, I'm just going to demonstrate how to hash it and trust it.

We need to trust FSharp.Core, and then our assembly:

DECLARE @hash AS BINARY(64) = (SELECT HASHBYTES('SHA2_512', (SELECT * FROM OPENROWSET (BULK 'C:\path\to\bin\dir\FSharp.Core.dll', SINGLE_BLOB) AS [Data])))
EXEC sp_add_trusted_assembly @hash

Then, our assembly:

DECLARE @hash AS BINARY(64) = (SELECT HASHBYTES('SHA2_512', (SELECT * FROM OPENROWSET (BULK 'C:\path\to\bin\dir\MyAssembly.dll', SINGLE_BLOB) AS [Data])))
EXEC sp_add_trusted_assembly @hash

Easy enough.

Because FSharp.Core isn't built for native SQL Server support (which, if anyone want's to fix, I've included the error at the end of this article), we have to add it with PERMISSION_SET = UNSAFE, which is, well...unsafe.

So, to load our assembly, we need a name, and the path:

FROM 'C:\path\to\bin\dir\MyAssembly.dll'

Not particularly hard. The name ([MyAssembly]) is not restricted to anything other than the regular NVARCHAR(128) for sysname, it does not need to match anything from the DLL, but probably easier if it does.

Finally: create the function

Alright, so our assembly is imported, we have it available, the last part is creating the function.

To create the function, we start it off like a normal T-SQL UDF:

CREATE FUNCTION CalculateDistance
    @fromLat FLOAT,
    @fromLon FLOAT,
    @toLat FLOAT,
    @toLon FLOAT

If you've ever written a T-SQL Scalar-Valued UDF, this should look familiar. We build the signature exactly as we defined it in F#, and that part is super important: the signature cannot vary at all.

Next, we write the UDF:

AS EXTERNAL NAME [MyAssembly].[MyAssembly.Namespace.ModuleName].calculateDistance

The EXTERNAL NAME is a three part name:

  1. The assembly name as specified in CREATE ASSEMBLY;
  2. The assembly namespace and module name, the fully-qualified name of the first outer-container of the function we need;
  3. The function name itself;

Once you've created the function, we're literally all done. You can now call directly into your CLR code:

SELECT dbo.CalculateDistance(@fromLat, @fromLon, @toLat, @toLon)


For those who want to see the performance difference, the original T-SQL function is:

CREATE FUNCTION CalculateDistanceUdf
    @fromLat FLOAT,
    @fromLon FLOAT,
    @toLat FLOAT,
    @toLon FLOAT
    RETURN (1.852 / 1.61) *
        60 *
                SIN(RADIANS(@toLon)) *
                SIN(RADIANS(@fromLon)) +
                COS(RADIANS(@toLon)) *
                COS(RADIANS(@fromLon)) *
                COS(RADIANS(@toLat) - RADIANS(@fromLat))))

The WITH SCHEMABINDING is a hint to try to tell SQL Server to mark the function deterministic, and it is as verified with SELECT OBJECTPROPERTY(OBJECT_ID('[dbo].[CalculateDistanceUdf]'), 'IsDeterministic'), but it still performs significantly slower than the SQLCLR alternative.

I borrowed the test from this article to run mine, and wrote them as follows:



This inserts 1048576 rows to the Numbers table, so it's a good-sized test.

Then we can run each of the following three tests:

DECLARE @fromLat AS FLOAT = 100
DECLARE @fromLon AS FLOAT = 100

SELECT MAX(dbo.CalculateDistance(Num / @fromLat, Num / @fromLon, Num / @toLat, Num / @toLon)) FROM Numbers

DECLARE @fromLat AS FLOAT = 100
DECLARE @fromLon AS FLOAT = 100

SELECT MAX(dbo.CalculateDistanceUdf(Num / @fromLat, Num / @fromLon, Num / @toLat, Num / @toLon)) FROM Numbers

DECLARE @fromLat AS FLOAT = 100
DECLARE @fromLon AS FLOAT = 100

        (1.852 / 1.61) *
        60 *
                SIN(RADIANS(Num / @toLon)) *
                SIN(RADIANS(Num / @fromLon)) +
                COS(RADIANS(Num / @toLon)) *
                COS(RADIANS(Num / @fromLon)) *
                COS(RADIANS(Num / @toLat) - RADIANS(Num / @fromLat)))))
FROM Numbers

You can run these each individually to time them. My times were roughly 645ms for the SQLCLR, 3369ms for the T-SQL UDF, and 703ms for the inline T-SQL. As you can see, the SQLCLR function is faster than the inline T-SQL, and let's us encapsulate the logic in a single function. (This actually came about as an issue because we have the calculation there copied-and-pasted over several dozen queries, often 3-8x per query.)

So, that said, in this type of situation (raw math) there's no reason to use T-SQL for the task, and for something reasonably complex like this, no reason not to abstract it. Dump the code in .NET, write your unit tests, and then deploy the assembly to the SQL server.

Now, that said, there are times I wouldn't use a SQLCLR function, such as when the math is ultra simple: i.e. * 3, and there are times when a table-valued UDF would be far superior, so I don't want to make the suggestion that this will always help, just that it's another thing you can try, and it might actually surprise you.

For anyone curious, attempting to create an assembly in F# throws the following warning:

Warning: The Microsoft .NET Framework assembly 'fsharp.core, version=, culture=neutral, publickeytoken=b03f5f7f11d50a3a, processorarchitecture=msil.' you are registering is not fully tested in the SQL Server hosted environment and is not supported. In the future, if you upgrade or service this assembly or the .NET Framework, your CLR integration routine may stop working. Please refer SQL Server Books Online for more details.

And using a PERMISSION_SET of EXTERNAL_ACCESS or SAFE throws the following error:

CREATE ASSEMBLY failed because type 'Microsoft.FSharp.Collections.FSharpMap`2' in safe assembly 'FSharp.Core' has a static field 'empty'. Attributes of static fields in safe assemblies must be marked readonly in Visual C#, ReadOnly in Visual Basic, or initonly in Visual C++ and intermediate language.