It had the slash after the “.com” but was missing the www and didn’t have HTTPS. At first I thought the problem was the missing www but I was wrong. The problem was in the redirect from HTTP to HTTPS. Lets take a look at the apache site config file for Saturday MP where the redirect lives.
Notice the slash is missing at the end of the redirect? That is the problem. To fix it add a backslash so the redirect looks like:
Redirect permanent / https://www.saturdaymp.com/
After you add the backslash don’t forget to reboot your webserver, which I did. You will also have to clear your browser cache, which I didn’t do. It took me another hour to figure out the above fix actually did work because I didn’t clear out my browser cache. Always clear our your browser cache when testing websites.
P.S. – For those not into 80’s hair bands Slash is the one with hat, curly hair, and memorable guitar licks. The opening to Sweet Child O’ Mine is actually a guitar exercise Slash used for practice and warm-up. Finally make sure you listen to the uncut version. In the cut version almost a minute of Slash’s guitar solo is missing.
https://www.youtube.com/watch?v=YFQaUA-vBbI
Posted inToday I Learned|TaggedApache, https|Comments Off on Today I Learned The Final Backslash is Important in Apache HTTPS Redirects
This post is part of a larger discussion about temporal databases. Hopefully it stands on it’s own but for more context see the Temporal Database Design page.
Most of us have worked with database tables that track some historical information. You add a EffectiveDate column or something similar and usually it’s just limited to a table to two. A Temporal Database is designed so most or all of the tables can track historical information.
The important part is that you can access the historical database using a SQL query and don’t have to look elsewhere, such as audit log. This is what makes a database a Temporal Database, at least according to me.
Degree of Database Temporalness
A database can either be non-temporal, partial temporal, or fully temporal. You can measure the temporalness by the percentage of tables that store temporal data.
Non-Temporal (0% Temporalness): Database has no temporal capabilities.
Partially Temporal (1% – 99% Temporalness): The database has some tables store temporal data but not all.
Fully Temporal (100% Temporalness): All the tables in the database store temporal data.
Type of Table Temporalness
We don’t measure how temporal a table is by percentage. Instead a table is defined by what type of historical data you can retrieve. There are two types of historical data:
You can read the official Wikipedia definition but for our purposes it’s a database where you can query for historical data using SQL.
For example, say you have someone named Chronos who lives in New York but on April 15, 2012 moves to Hong Kong. If you don’t have an historical tracking then you will only be able to see that Chronos lives in Hong Kong. You don’t know where he lived before Hong Kong or when he moved to Hong Kong.
// Instantiate the constraint.
Assert.That(expected, new EquivalentPropertyWiseToConstraint(actual));
// Matches syntax.
Assert.That(expected, Is.Not.Matches(new EquivalentPropertyWiseToConstraint(actual)));
It would be nice to write:
// Directly access the constraint from Is.
Assert.That(expected, Is.EquivalentPropertyWiseTo(actual));
// Chain the constraint in Is.
Assert.That(expected, Is.Not.EquivalentPropertyWiseTo(actual));
To do that you should read the documentation. End of blog post.
So is that joke still funny? No, OK, no more. Lets get back to what we are doing. To access the method using Is you need to override the Is class and add a static method. I recommended making the method name similar to your constraint name. For example:
public class Is : NUnit.Framework.Is
{
public static EquivalentPropertyWiseToConstraint EquivalentPropertyWiseTo(object expected)
{
return new EquivalentPropertyWiseToConstraint(expected);
}
}
Now you can directly access your custom constraint via Is like:
// Directly access the constraint from Is.\
Assert.That(expected, Is.EquivalentPropertyWiseTo(actual));
However, if you try to chain the method it won’t work. For example, this will throw an error:
To fix this we need to create an extension method. The name of the class is not important but the name of the extension method should match the name you used above when overriding the Is class. The method needs to create your constraint and append it to the constraint expression.
public static class CustomConstraintExtensions
{
public static EquivalentPropertyWiseToConstraint EquivalentPropertyWiseTo(this ConstraintExpression expression, object expected)
{
var constraint = new EquivalentPropertyWiseToConstraint(expected);
expression.Append(constraint);
return constraint;
}
}
Now you can chain your customer constraint and the following will work:
// Will compile now that the extension method exists.
Assert.That(expected, Is.Not.EquivalentPropertyWiseTo(actual));
Now you have a fully working custom NUnit constraint. For a working example please see the NConstraint project. End of blog post.
P.S. – Another of my favourite Tragically Hip songs. I used to listen to this song a lot when working late nights at my first programming job.
Everything is bleak
It’s the middle of the night
You’re all alone and
The dummies might be right
You feel like a jerk
My music at work
My music at work
NUnit has has built in constraints for most the tests you will need to write so there is no need to create your own. End of blog post.
OK, that was a bad joke. The first step in creating a NUnit custom constraint is to read the documentation. That’s it. End of blog post.
Not as funny as the first time? Not funny at all? I won’t use that joke again. But you did read the documentation right? OK, good.
The example for this blog post is from the NConstraint project. It shows how I created a custom constraint to compare the property values or two objects. In my case I wanted to write something like:
var expected = new MyClass() { SomeProperty = 1};
// Property values match.
var actual = new MyClass() { SomeProperty = 1 };
Assert.That(expected, Is.EquivalentPropertyWiseTo(actual));
// Property values don't match.
actual.SomeProperty = 2
Assert.That(expected, Is.Not.EquivalentPropertyWiseTo(actual));
Lets start. First you need to override the Constraint class.
public class EquivalentPropertyWiseToConstraint : Constraint
{
}
Then create a constructor that accepts the expected value for the test. In our case it’s the object you want to compare but it could be anything.
public EquivalentPropertyWiseToConstraint(object expected)
{
Expected = expected;
}
public object Expected { get; }
Notice that we save the expected object. In my case I saved it to a public property for unit testing purposes but it could be a private variable. I know, unit testing a new unit test constraint, very meta.
The next thing we have to implement is the logic for the constraint by overriding the ApplyTo method.
public override ConstraintResult ApplyTo<TActual>(TActual actual)
{
}
This method takes a the actual value from the test that you want to compare to the expected. It returns a ConstraintResult contains a reference to the constraint, the actual value, and if the constraint passed or not.
Add whatever logic you need to to the ApplyTo method. In my case I wrote some logic that loops through all the properties of both objects and compares the values. It’s a bit long so I won’t include it in this blog post. In general your method will look something like:
public override ConstraintResult ApplyTo<TActual>(TActual actual)
{
// You code to do the comparison.
// If the comparison succeeds.
return new ConstraintResult(this, actual, true);
// If the comparison fails.
return new ConstraintResult(this, actual, false);
}
Now you should be able to run your tests by instanciating your constraint or using the Matches syntax.
// Instantiate the constraint.
Assert.That(expected, new EquivalentPropertyWiseToConstraint(actual));
// Matches syntax.
Assert.That(expected, Is.Not.Matches(new EquivalentPropertyWiseToConstraint(actual)));
One thing you might notice is the error message is not very descriptive if the test fails.
Expected:
But was: 1
The “But was” part is the actual value you passed into the constraint. In my case I passed in the property value, which was an integer, hence the 1. Your actual value might be different.
To get a better expected message you need to set the description value in the Constraint class. If you have a simple test you could hard code the description. For example the built in TrueConstraint always sets the description to “True” in the constructor.
public TrueConstraint()
{
Description = "True";
}
In my case I needed to set the description in the ApplyTo method. For example if a property does not exist then we set a different description then if the property values don’t match.
// Property does not exist message.
Description = $"expected property {expectedProperty.Name} does not exist.";
// Property values don't match message
Description = $"property {expectedProperty.Name} value to be {expectedValue}";
Once I set the descriptions my test failed messages looked better:
Expected: property IntegerProperty value to be 2
But was: 1
Now your custom constraint is complete but you might notice is that you can’t use the NUnit built in “Is” syntax. For example, you currently can’t write:
So I’m at your house this morning Just a little after nine ‘Cause it was in Bobcaygeon, where I saw the constellations Reveal themselves one star at a time
A common unit test assert I need to do is compare all the property values of one object to another. For example:
[Test]
public void TestSaveWorks()
{
// Create a value to save.
var expectedDto = new SomeDto() {ValueOne = 1, ValueTwo = "Blah"};
// Save the value.
_someDbService.Save(dtoToSave);
// Load the value from the database. The DTO ID
// should have been set by the save.
var actualDto = _someDbService.Find(expectedDto.Id);
Assert.That(expectedDto.ValueOne, Is.EqualTo(actualDto.ValueOne));
Assert.That(expectedDto.ValueTwo, Is.EqualTo(actualDto.ValueTwo));
}
In this test we only have two properties to test but if the object has 10 plus properties to test that would be quite onerous. I often forget to update the tests after I add a new property to the object.
To fix this problem I created a custom constraint for NUnit called EquivalentProperyWiseTo that compares all the property values of two objects. Now the above tests looks like:
[Test]
public void TestSaveWorks()
{
// Create a value to save.
var expectedDto = new SomeDto() {ValueOne = 1, ValueTwo = "Blah"};
// Save the value.
_someDbService.Save(dtoToSave);
// Load the value from the database. The DTO ID
// should have been set by the save.
var actualDto = _someDbService.Find(expectedDto.Id);
Assert.That(expectedDto, Is.EquivalentPropertyWiseTo(actualDto));
}
Notice you don’t need to test each property value independently. Just pass in the two objects you want to test and you are done. High Five!
The EquivalentPropertyWiseTo custom constraint can be found in the just released NConstraints. You can find the latest stable version of the NConstraints on NuGet. If you like living on the edge you can find the developer builds on MyGet.
If you have any questions, spot an bug, or have an enchantment for NConstraints let me know by:
asking a question on StackOverlow with the tag nconstraints.
send me an e-mail to support@saturdaymp.com.
Finally thank you to the NUnit team for creating NUnit and continue to support it. I’ve used NUnit for most of my career to properly test and improve my code.
In TeamCity you can’t use the usual NUnit Runner to run .NET Core unit tests. At least I couldn’t get it to work. I’m sure this will be fixed in the future but for now the below works for me. I got lots of inspiration from this TeamCity blog post.
For this example I’ll use the NConstraints project. It contains a .NET Standard project (SaturdayMP.Constraints) that we want to test and two .NET Core Test projects (SaturdayMP.Constratints.Test and TestClient).
In TeamCity I created a project with the usual first two steps of NuGet Install and Compile.
If you read the TeamCity blog post, the one I got my inspiration from, then you probably noticed it used the .NET Core Runner to compile the project. You might have had to do this when the TeamCity blog post was first written but now using the Visual Studio Runner will compile .NET Core projects.
Before we can add the .NET Core unit test build step we need to install the TeamCity .NET CLI Plugin. Do this by downloading the plugin zip file from here.
Then install the plugin by clicking on Administration in the top right then Plugins List on the bottom left.
Then click Upload Plugin Zip link and choose the plugin zip file you just downloaded.
Once the upload is complete you should see something similar to the screen shot below.
The plugin is uploaded but before it’s active you need to reboot TeamCity. In my case I just rebooted the server.
Once the reboot is complete you can check that the plugin installed correctly by going to an agent with Visual Studio 2017 installed.
Once on the agent navigate to the parameters page and you should see something similar to the below screen shot.
If you don’t see the DotNetCli listed then you either forgot to reboot TeamCity, the plugin didn’t install correctly, or you don’t have .NET Core installed on you build agent.
Now that the plugin is installed we can go back to our project and add the unit test build step. Add a new build step and in the runner type pick .NET CLI (dotnet). Then in the command drop down pick test and finally enter the paths to your projects. If you have several projects you can use wildcards.
If you don’t see all the options in the screen shot above them make sure to click Show Advanced Options. In my case I also enabled code coverage at the bottom of the list.
Now when we build the tests should get executed. You can see the results of the tests in the build log or the tests tab of the build results.
As I said at the beginning I’m sure the NUnit Runner will be updated to handle .NET Core but use the above for now.
If I was a betting man I would bet you work for a small company (99employees or less). Odds are I would be right half the time. How did I come up with those numbers? Using some math and stats I found on the Internet.
About 24% of the working population are public employees (i.e. employed by government). The remaining 76% are employed by private companies with just a hair under 70% working for a company of less then 100 employees.
Share of Total Private Employment by Size of Business, 2015
That means if 100 employed people are reading this blog post at the same time then:
24 are Public Employees
7 work at Large Companies (500+)
15 work at Medium Companies (100 – 499)
54 work at Small Companies (1-99)
Pro tip for job seekers: don’t just apply to large companies. Apply to small companies you never heard of because they hire a lot more people.
Starting a new business is hard. In 2010 study just over half of new business in Canada survive 5 years or more and only 30% survive 10 years. Similar statics for our neighbours in the south.
Saturday Morning Productions has been around for 7 1/2 years, if my maths are correct. Our odds of surviving this long are about 45%. Another way to look at it is if 100 business opened in 2009 then only 45 are still around today.
Why has Saturday MP survived when others business have faltered? I think an important but often overlooked reason is my supportive spouse and business partner, Ada. I know there are other reasons (i.e. hard work, grit, frugality, luck, etc) but when you start a business later in life when you are married with a young daughter then a supportive spouse is a requirement. Well, I guess you could start a new business without the support of your spouse but I wanted to stay married and run a business.
I couldn’t find any data but my guess is that most small business that survive for more then 5 years have a supportive spouse. That or the owners are unmarried or divorced. The closest data I could find was from Thomas Stanley’s Millionaire Mind book and quoted on his blog:
The typical millionaire couple has been together for nearly thirty years and their bond tends to be permanent as well as economically productive. . . . ask the husband or wife to explain their household’s productivity . . . . Each gives substantial credit to the other.
For every 100 millionaires who say that having a supportive spouse was not important in explaining their economic success, there are 1,317 who indicate their spouse was important. Of the 100 who did not give credit to their spouse, 22 were never married and 23 were either divorced or separated. That leaves only 55 in 1,317 [4.2%] who believed that their spouse did not play an important role in their economic success.
So before I thank my wife for her support I would like to thank the spouses of all the small business and hope you will join me. Think of all the small business you have either worked for, I’ve worked for 5 and counting, or done business with.
Thank you to the spouse that looked after the home and kids while the small business owner was working 60+ hours a week. The spouse that was willing to give up the security of regular pay checks, benefits, and pension for someone else’s dream. The spouse that became the companies first book keeper, janitor, and/or secretary. The spouse that worked overtime or a 2nd job to help fund the new business. The spouse that became a partner in the business. The spouse that believed in their wife/husband and loved them through all the ups and downs.
Special thanks to my wife for helping me start Saturday Morning Productions. Thank you for being a business partner and a great consultant. Thank you for looking after our home and daughter when you weren’t consulting. Thank you for continuing to the book keeping while working a full time job at the university. Thank you for supporting me during my summer sabbatical. Finally thank you for continuing to support and believe in me. Love you lots.
P.S. – Happy Anniversary.
I’m falling even more in love with you Letting go of all I’ve held on to I’m standing here until you make me move I’m hanging by a moment here with you
My takeaway from Meatball Sundae is don’t use a new marketing trend because it’s the hip new thing to do. Make sure the marketing you do aligns with your business. If the new marketing you does not align either change your business or don’t bother with the new marketing.
The book was written in 2007 and focuses mostly on marketing using the web but the basic idea applies to any new marketing technology. Just because others companies use dream ads doesn’t mean you need too.
For me personally it means I should understand the social media platforms I use. My Twitter, Facebook, and LinkedIn post mostly links back to this blog. Is that the best way to use these platforms? Probably not.
For October I’ll focus on Twitter and see if I can figure out if it aligns with my basement based business. Do I need to change my business, change how I use Twitter, or give up on Twitter?