Saturday, January 27, 2018

URL Redirect Tools for Development

Many developers are familiar with Fiddler from Telerik as a tool for creating browser redirects. However, if you need a lighter weight solution a browser plugin may be a better solution. The last few years I've hardly opened Fiddler, as simple browser plugins have been meeting my needs.

The first redirect browser plugin I used was Trumpet in the Chrome browser. You can still find Trumpet in the Chrome store.

Trumpet works great, however the UI is not super polished, and some aspects of it are not intuitive. After a minute or two of tweaking the settings you'll get the desired redirect results. Hopefully...

Firefox 57 is a great browser and I've started to spend more time in dev tools. That being the case, I found myself in need of URL redirection. That's when I found REDIRECTOR. Same concept, but better UI, and it feels more polished and friendly. And it's available in both Chrome and Firefox.

When creating a new redirect, I noticed and appreciated the validation that appears in REDIRECTOR. It helps provide clarity, showing your pattern match does indeed work before you hit save.

It's the little things... If you don't need all the power of Fiddler, give a redirect extension a try.

Monday, January 15, 2018

Messaging Pattern - With RxJS

While doing WPF development, one of the go to patterns is the messenger or pub/sub. The power of this pattern is individual components in a system can remain decoupled, yet communicate with each other. Reactive extensions for JavaScript make it easy to create a messenger for a modern client side application framework such as Angular.

The code flow is simple to describe. Two components use a common messenger service. In one component, a subscriber is registered against the service to listen for messages. In the other component the service is used to send a message. Both components rely on the service, but do not have any knowledge of each other.

Here is an example that can be adapted to your needs.

There are a few things to be aware of. If you do not use messaging class, you may fall into the trap of trying to message data received on an AJAX call . Your code will fail to pass the instance of  check, as you haven't actually created an object instance. This is one reason to follow the pattern of using a separate class for each type of message, instantiating the message and attaching the data.

For some applications it may work better to break the types of messages into categories. Each category can then have a method for sending and a Subject object to subscribe on. This reduces the amount of messaging noise on each channel.

Saturday, November 18, 2017

Keep a Changelog

Over the years developers have utilized several methods to keep user updated on the changes occurring with each application release. One approach is to email users upon each application update, this is intrusive and annoying for users. Another is to dump the git commits into a changelog.  Git commits aren't for user consumption :) The best approach is make the changelog an integral part of your application. The single source of truth that's ever present within the application.

Most developers are familiar with Markdown, as most of our repositories contain a file. Markdown is great at using minimal syntax to describe document layout. This makes it an ideal format to use for changelogs as well.

In a recent project we decided to follow the guiding principles from There are a variety of libraries in NuGet that can convert markdown to html, I utilized CommonMark. With a few lines of code I added an easy to follow changelog to my project.

Here is the core code. Note: the changelog.txt should be a, but Github converts markdown to html, making it render in this post as html. In your code, this file would be a .md file not .txt.

Saturday, November 4, 2017

Entity Framework Core - InMemory Db Names in Tests

The new in memory database provider that's available for EF Core is awesome. If you aren't familiar with it, it lives in the "Microsoft.EntityFrameworkCore.InMemory" NuGet package. One of the quirks of using this provider is that it requires a unique database name for each test. This ensures that you don't have state bleed over between tests. The creation of the in memory database usually looks something like this.
 var options = new DbContextOptionsBuilder()
                .UseInMemoryDatabase(databaseName: "Unique_db_name_here")
At first when writing tests I was utilizing a magic string as in the example above. I came back to some unit test where I'd used unique names such as "test1", "test2" etc. After deleting a test and seeing my magic strings get out of sequence, it became apparent that this was going to be a maintainability nightmare. Hmmm, did I use "test6" yet?

Unit tests methods already have unique names, so why not use the test name? With magic strings this approach would be terrible, but with the C# 6.0 nameof operator this approach works well.

This keeps the in memory names unique and keeps refactoring simple.

Saturday, March 11, 2017

Microsoft Surface Book

Late last year I started a new job where I was supplied with a Surface Book. My last job supplied me with a 10 pound Dellasuras, which I was more than glad to leave behind. With all the hype around the Surface Book I was excited to use one on a daily basis as my primary machine. It's now been close to 4 months with the Surface Book.


  • Weight - at roughly four pounds, its close to 5 pounds lighter than my previous laptop.
  • Build - way better than the Dell, and as other people have noticed, on par with an Apple product.
  • Charger - the charger is lightweight and small, includes one USB port on the brick.

  • Display - the display is amazing overall, but this is Windows, so all of those old applications that are programmed against fixed pixels...  I hope you own a good pair of reading glasses or a magnifying glass. It can get pretty ridiculous. 
  • Display & Table - because the display can split off the keyboard base and become a tablet, its heavier than on a normal laptop. This becomes awkward if you ever try to use the Surface Book as a laptop. It's top heavy.
  • Display Drivers - we've noticed at work that all of the Surface Books display some interesting issues when they are docked.  The main issue being that scroll bars in some apps are really fat. It's more annoying than you'd imagine.
  • Price - for the price you can get several laptops that have equivalent or better internal specs. 
  • Pen - it's there, but I never use it.  It gets lost in my backpack about twice a week. 
Overall, the Surface Book is working well for my needs.  Though I'm not sure I'd by one for a personal laptop.

Tuesday, January 31, 2017

Mocking base class methods using Moq

While working with MVC recently, I encountered a situation where my code interacted with the OWIN context. I wanted to avoid pain in my unit tests, but didn't really have time to create an interface and wrapper for this interaction.  I had already encapsulated the OWIN context interaction to a method in my base class.  When I wrote the code I wasn't exactly sure how I was going to test it.

Turns out its pretty simple to unit test this with Moq. Just remember to set CallBase on your mock object.

//Here we are using Moq to over-ride the base class check access method which calls into the owin context.   
var controller = new Mock<UserprofileController>(_userProfileService.Object, 
    _logger.Object) { 
        CallBase = true 
controller.Setup(b => b.CheckAccess(It.IsAny<string>(), It.IsAny<string[]>())).Returns(accessState);   

Friday, November 11, 2016

Running Web.Config Transforms on Build

Web application deployment typically involves transforming the build depending on the build target.  Typically Visual Studio only runs the standard transforms on publish of the web application (publish profiles).  This can be confusing and frustrating as many expect a different behavior.  It seems intuitive that transforms would be ran on build. 

The following is a simple recipe you can follow to ensure that MS Build will run the correct build target transforms on build.  In the steps below you'll notice it is suggested that the Web.Config in the project directory be removed from source control.  This is because each time you change configuration and build, the web config will be updated.   

  1. In Visual Studio, from the Build menu, open Configuration Manager.  At this point you can add build targets for each one of your environments.

Do what make sense, but a typical set of build targets may look something like this :
  • Debug
  • Staging
  • Pre-Production
  • Release

  1. In your Visual Studio Project, add a folder called Config 
    1. Copy your current Web.Config and its children Web.Debug.config & Web.Release.Config into the new Config folder.  Delete the old files and remove them from source control.
    2. Add a new file Web.($BuildTarget).config named to match your additional build targets by copying one of the existing transforms.

  1. Add a pre-build step in Visual Studio under Project > Properties > Build Events where project folder refers to the name of your project folder where the original web configs existed.
    1. xcopy "$(ProjectDir)Config\*.*" "$(SolutionDir)\ProjectFolder" /Y
  2. Unload your Visual Studio Project and edit the .csproj files xml.
    1. Add an AfterBuild target to the very bottom of the file right before the closing </Project> tag

<Target Name="AfterBuild" Condition="'$(PublishProfileName)' == '' And '$(WebPublishProfileFile)' == ''"> 
    <TransformXml Source="Web.config" Transform="Web.$(Configuration).config" Destination="Web.config" />

Now each time a build is triggered, the web-config will be properly transformed.