Today I release Fanray v2.0-a2, building on v2.0-a1 released from last week.  This release provides the ability to preview a post (issue #208) and other fixes.

The preview will show you exactly how your post will look before you publish it, and it is fast and convenient.  It happens right inside the composer, when you click on the Preview button a dialog pops up full screen to show you the post as if it's published.  The URL of the post is printed on top of the preview window.  To exit you can press Esc or hit Close button.

One thing I want to point out, by design I want each Fanray theme to provide a content.css.  This file is meant for the editor to consume, it includes things like the typography and the content width styles of your particular theme. It enables the users to see a similar styling to the final published post while they are still editing.

But the content.css does not make your content 100% resemble the eventual published post.  This is due to some of the limitations of the editor, for example it currently does not support block source code which is a known issue and will be addressed in the future.  In the meantime, I have come up with a shortcode for you to input block source code into your post.

The ability to preview a post before publish is a much needed feature for the increased usability of the blog composer.  It'd be even nicer if it could have a keyboard shortcut assigned to the preview to help user get into the preview quickly.  Also if you are writing a long post it'd be helpful if there is an option to sync the preview and the editor so you don't always start from the top and have to scroll down.  These nice-to-have additions I don't have time to pursue right now, if anyone in the community is interested please feel free to improve on it.

I hope you find this feature useful :)

I implemented Vuex in my project this week, I'm new to Vuex and this is what I learned.  In a Vue app when you need communication between two components, you have the following choices

• Use events
• Create your own simple store
• Use Vuex

One recommendation I read from the Vue Forum when someone asked about Bus vs Vuex is 

My advice would be as follows: use vuex for everything as a default, and drop back to an event bus when vuex becomes a hurdle.

The basic idea is your Vue app is a tree of components and the tree could be N layers deep, and to pass data between any two components in the tree becomes a challenge.  Events when used here and there is OK but in a large app if you add a lot of them your code becomes cumbersome.  So what the app need is a global object store to contain shared data accessible to all components and that is what Vuex is.

Here I have an issue #252, it describes that when you insert some selected images from the gallery dialog into your post and then you re-open the gallery two things should happen 1. the previously selected images should be de-selected and 2. the Edit, Delete and Insert buttons which only show up when there are selected images should be hidden, neither is happening. Not only that both should happen when the dialog is closed in most cases.

There are 4 ways to close the dialog

1. Click on Insert, this should insert and de-select the images and close it
2. Click on Close, this should de-select images and close it
3. Press "Esc" key on keyboard, this should de-select images and close it
4. Click anywhere outside the gallery, this should close dialog but without de-selecting the images. I find this scenario often happens by mistake not by intention.

The gallery is the child component, it contains the toolbar of buttons and a list of images.  When you select images they are stored in an array named selectedImages on this child component.  The gallery is then contained inside a dialog component which is part of the parent composer. Whether the selectedImages is empty is what controls the visibility of the three buttons on the toolbar.  When I click on Insert I pass the selected images to a method of the parent which then writes out html to the editor.  

When I click on insert I actually could easily de-select the images and empty out selectedImages because the Insert button is part of the gallery component, same with clicking the Close button.  When I press Esc on my keyboard to close the dialog though it is not as simple because that is part of the parent.  In other words the parent needs to access selectedImages on the child. 

I feel this is a great example of when you could use Vuex.

let store = new Vuex.Store({ 
   strict: true, 
   state: { 
       selectedImages: [], 
   }, 
   mutations: { 
       setSelectedImages(state, newSelectedImages) { 
           state.selectedImages = newSelectedImages; 
       }, 
       addSelectedImage(state, image) { 
           state.selectedImages.push(image); 
       }, 
       removeSelectedImage(state, idx) { 
           state.selectedImages.splice(idx, 1); 
       }, 
   }, 
   actions: { 
       selectImage: function ({ commit }, image) { 
           commit('addSelectedImage', image); 
       }, 
       deselectImage: function ({ commit }, idx) { 
           commit('removeSelectedImage', idx); 
       }, 
       emptySelectedImages({ commit, state }) { 
           commit('setSelectedImages', []); 
       }, 
   }, 
});

Then the selectedImages array breaks loose and accessible globally, thus the parent can take a hold of it and empty it when necessary

this.$store.dispatch('emptySelectedImages'); 

Fanray v2.0-a1 has been released!  Fanray v1.0 was a minimal viable blog, you could only post through a client like the Open Live Writer. Fanray v2 builds on v1 and introduces a brand new Admin Panel you can now easily manage your blog's posts, tags, images etc.  Here are a few highlights and tips to get you started and please check out the Wiki for more details.

Get Started

First to get up and running is very easy, just follow the Quick Start steps.  Once you launch the application you will see a revamped setup page to help create your blog.

Site Settings

Once you created your blog, I recommend complete the setup by going to the Settings page and enter your Disqus and Google Analytics information.

The Composer

Bloggers probably spend most of their time writing posts. To help you be productive, I highly recommend spending a few minutes to get familiar with the Composer, particularly the Editor and experiment how to input different content efficiently.

Here is a simple challenge for you to get started, open up the Composer and try input the following

• Paste some html content without styles
• Add heading, list, bold text with Markdown syntax
• Add link without clicking the toolbar, then try move your cursor outside the link to continue typing regular text

Media Gallery

The Media Gallery gives you a grand view of all your blog images.  Here you can upload more images or edit image info etc. The uploaded images are resized and stored on either the file system or Azure Blob Storage, you can configure which storage in the appsettings.json.

Categories and Tags

The Categories and Tags pages allow you to easily manage your blog's classifications.  For categories there is a default category out of box named Uncategorized, go rename it to something you write about. 

Deploy

When you are ready to run this app on Azure, please refer to Deploying to Azure.

Upgrade

If you are running v1.0, the upgrade is very simple.  You can just run v2.0, the EF Core Migrations will upgrade your database for you automatically.  If you prefer to know what changes are being made to your database or prefer to upgrade manually, a .sql script is provided for you.  The file is 1.0-2.0.sql located in the solution's sql folder.

Contribute

Fanray is in its early stages and requires support to move ahead. You can contribute in many ways - ideas, bugs, testing and docs etc.  Follow me @fanraymedia and let me know what you think.

Thank you and happy coding :)

This week I got my first PR thanks to Flyznex, he helped fix issue #234 Login has a very slow response and along implemented a better way to verify if a string is a valid email. 

The issue came up when I found that sometime when I login it took a long time.  I'd put my email/username and password in and click on the login button and nothing would happen, and after a while like a few seconds then it let me in.

PasswordSignInAsync

As Flyznex pointed in the PR, the SignInManager<TUser> class in Asp.net Core Identity has two PasswordSignInAsync methods, one that takes in a string for userName while the other takes in a user object.  If you call the one that takes in the userName, the method will call UserManager.FindByNameAsync(userName); to look up the user first by its userName, hence you make an extra call to the database.

In my Login method I already looked the user up with its userName by calling my UserService method FindByEmailOrUsernameAsync(loginUser.UserName); so I could just pass the user object to PasswordSignInAsync.  My mistake was that I passed in user.UserName instead thus incurred the extra db call.

Verify if a string is valid email

On my login I allow user to use either either user name or email to login.  When a user is logging in I first check if what's inputted is a valid email or not.  If the string is not a valid email then the user is passing in his user name.

So checking if a string is email sounds easy but in reality it is very complex!  If you don't believe me just take a look at Phil Haack's post I Knew How To Validate An Email Address Until I Read The RFC.  Luckily there is a solution provided to us in the .NET documentation How to: Verify that Strings Are in Valid Email Format.  And when you take a look at that implementation it's like 60 lines of C# code just to do this verification, for good reasons.

Before this PR I was using System.Net.Mail.MailAddress class constructor to verify the validity of an email

// bad code, do not use! 
bool isEmail;              
try  
{  
    new MailAddress(emailOrUsername);  
    isEmail = true;  
}  
catch (FormatException)  
{  
    isEmail = false;  
} 

I originally thought good, less than 10 lines of code to get the same thing done.  But this implementation is actually not reliable.  Try pass in this string a@a as input which is not a valid email, it actually returns true!

Another thing to notice is that verifying email feels like a utility feature, as the name of the class in the .NET doc also suggests RegexUtilities.  For that normally we want to use a static method, but this implementation depends on a local field bool invalid = false; that is shared between the two methods inside the class.  But Flyznex was able to fix that by removing this local variable, as a result our implementation now is really simple to use, you can just call Util.IsValidEmail("email.to.verify@test.com").

It's been a year since v1.0 was released, to be able to release more often I need to put in more effort to issue management and planning.  As part of that I want to have a Roadmap that highlights roughly what's coming in the foreseeable future, but first I need a versioning scheme that could work for me.

I came across this Wikipedia page on Software Versioning and found that people use all kinds of schemes to version their releases, it can be anything really.

So I decided to adopt a semver major.minor.patch-(a|b|rc)[1-9] kinda scheme starting v2.0. To get releases to users faster, a release is planned every milestone. Milestones can give or take be weekly or bi-weekly (or a long time if I get stuck :) 

This table shows an example of this version scheme for the next full release cycle. 

Based on that I came up with a Roadmap

• v1.0 - Minimal Viable Product (Oct 2017)
• v2.0 - Admin Panel (Dec 2018)
  • v2.0-a1 - initial v2 alpha
  • v2.0-a2 - feat: preview post in composer
  • v2.0-a3 - feat: dnd images in composer
  • v2.0-a4 - feat: social links
  • v2.0-b1 - fixes
  • v2.0-b2 - fixes
  • v2.0-rc - fixes
  • v2.0-rtm
• v2.1 - Featured image and a second theme
• v2.2 - Navigation
• v2.3 - Pages
• v2.4 - User roles

Finally I'm trying these out for now to see how it goes, as a result the time frame and planned features can change.

I wrote once previously about how I used EF Core migrations to upgrade production database. I have two slots production and staging and I swap them every time I push new code that don't involve database changes.  This week I had to make a data change to production database, it's a reminder of when to use the Swap with preview feature provided by Azure App Services.  

I recently decided to change versioning scheme a bit in hope to turn out releases more often, so the upcoming release originally planned as v1.1 has now become v2.0.  As a result, I opened up issue #235 EF Migration and SQL upgrade files got wrong version numbers to fix the out dated text in these files.

In addition I need to update a record in the __EFMigrationsHistory table, specifically it’s the second row’s MigrationId needs to become "20180530163323_FanV2_0".

To update this record I can run a simple SQL update statement while the site still running, because EF only checks this table every time the application starts up to see if there are new migrations need to be applied.  The challenge is I don’t want a request hit the database before the new code gets there, because the existing code looks for the "20180530163323_FanV1_1" record and if it’s not there it’ll apply migration thus causing problems.

When using Swap with preview, these are the steps to take place:

1. First get staging database and server ready with new data and code (since it’s staging I can just stop the server and do whatever so that’s easy).

2. Update production database with the data change (the production site is still running).

3. Start the swap with “Swap with preview”, this will apply all production configurations to staging slot while still keep production running. It seems you can do this in either slot now, I somehow remember the option was only available in production slot previously.

4. Azure then restarts staging using these production configurations, now staging runs against production database which is OK since staging has the new code.

5. Finally do “Complete swap”, Azure moves the already warmed up staging slot into production.

In conclusion I could do this because it was only a data change.  Consider if there were schema changes then you may not be able to update the production database first while production service is still running, in that case I'd refer to my previous post.  

Fanray uses Serilog and practices Structured Logging.  One of the output sources is Seq.

Setup

The wiring of Serilog happens inside Program.cs

  public static IWebHostBuilder CreateWebHostBuilder(string[] args) => 
     WebHost.CreateDefaultBuilder(args) 
       .UseApplicationInsights() 
       .UseSerilog() 
       .UseStartup<Startup>(); 

And the configuration of it with Seq happens in appsettings.json and appsettings.Production.json. Below is the snippet from appsettings.json with MinimumLevel set to Deubg for local development.

  "Serilog": { 
   "Using": [ 
     "Serilog.Sinks.Console", 
     "Serilog.Sinks.Seq" 
   ], 
   "WriteTo": [ 
     { 
       "Name": "Console" 
     }, 
     { 
       "Name": "Seq", 
       "Args": { 
         "serverUrl": "http://localhost:5341" 
       } 
     } 
   ], 
   "MinimumLevel": { 
     "Default": "Debug", 
     "Override": { 
       "Microsoft": "Information", 
       "System": "Information" 
     } 
   } 
 } 

Structured Logging

Structured Logging enables you to dump entire objects as JSON into the logs and you can later search for them with their properties as search criteria.

For example I have this code in BlogService.cs, it logs a BlogPost object.  Notice the special syntax {@BlogPost}

_logger.LogDebug("Show {@BlogPost}", blogPost);

That outputs the following and notice it also outputs the nested objects inside BlogPost like Category, Tags etc.

{ 
   Type: "BlogPost", 
   CategoryTitle: "Technology", 
   Tags: […], 
   TagTitles: […], 
   Body: "<p>This is a test post.</p>", 
   BodyMark: null, 
   Category: {…}, 
   CategoryId: 2, 
   CommentCount: 0, 
   CommentStatus: "NoComments", 
   CreatedOn: "2018-09-22T02:23:40.0000000+00:00", 
   CreatedOnDisplay: "yesterday", 
   UpdatedOnDisplay: "09/21/2018", 
   Excerpt: "This is a test post.", 
   ParentId: null, 
   RootId: null, 
   Slug: "this-is-a-test", 
   Status: "Draft", 
   Title: "This is a test", 
   UpdatedOn: "2018-09-22T02:23:41.0002676+00:00", 
   User: {…}, 
   UserId: 1, 
   ViewCount: 0, 
   PostTags: […], 
   Id: 5, 
   _typeTag: "BlogPost" 
}

Seq

Seq is the tool that allows you to search through what you have logged taking advantage of Structured Logging.  And it is my recommended way to log during the development of Fanray.

To get started with Seq first download and install it from https://getseq.net/ and then to use it during development simply go to http://localhost:5341.

Search for Objects

To search for an object, say give me all BlogPost with a Body that contains the word "Welcome" case insensitive.

Here are docs on Seq's Filter Syntax and Cheet Sheet  https://docs.getseq.net/docs/query-syntax

Search for a Request

A request is common thing to search through the log, ASP.NET Core outputs detailed debug information during development. 

For example, when I publish a new post from Open Live Writer, I want to see what exactly happens during that request of publishing my post.  Since Asp.net Core provides these detailed info for each request thus you can search for it with its id "0HLH1ICD1KGGF:00000001".  The screen shot below shows the entirety of that request, the bottom rectangle marks the start of the request while the top rectangle marks the finish of it.  From this you are able to see things like all the SQLs EF Core executed, the MetaWeblogAPI newPost endpoint was called and the XML it received and other good stuff.

Last night I updated the namespace of my User class from Fan.Models to Fan.Membership (I probably should have used refactoring tool but didn't) and the web project Fan.Web stopped building.

These are CS0246 compiler errors all saying "type or namespace name could not be found" and pointing to my ".g.cshtml.cs" files.

The actual issues are in the .cshtml files, but Visual Studio points to the compiled version of those .cshtml file. Moreover clicking on these errors in Visual Studio will not open up either .cshtml or .g.cshtml.cs file.  So for a moment I was hanging and guessing on what I should do.

My first response was that compiled Razor pages got cached and didn't get cleaned out.  Then I went all over to find these files, maybe it's getting late at night.  Finally I right clicked and copied the error out to see that they are just locally in my folder src\Fan.Web\obj\Debug\netcoreapp2.1\Razor\Pages\Admin\Categories.g.cshtml.cs

To sum up, Razor pages are compiled into these C# .g.cshtml.cs files, they are located right in your web project's "...\obj\Debug\netcoreapp2.1\Razor\Pages\...".  If your .cshtml pages have namespaces that you just renamed, Visual Studio won't point you to .cshtml but to the compiled version instead.

An unit test failed when I built my code on BitBucket, it threw System.TimeZoneNotFoundException.  It happens where I try to convert a UTC Time to local time in a specific time zone. Interestingly the same unit test passes on my local running Windows 10 and on Appveyor.  

The exact error message is

The time zone ID 'Pacific Standard Time' was not found on the local computer. 

The exception occurred on the following line of code, its parameter timeZoneId got passed in the value "Pacific Standard Time".

TimeZoneInfo userTimeZone = TimeZoneInfo.FindSystemTimeZoneById(timeZoneId);

The issue comes from the fact that there is more than one source that provides time zone values, to list a few

• The Unicode CLDR project
• The IANA time zone data
• Microsoft Windows time zone updates

And they output different time zone values, for example while on Windows you have "Eastern Standard Time", IANA calls it "America/New_York".

I found this cool library TimeZoneConverter that solves exactly this problem with minimal code change, my previous code becomes

TimeZoneInfo userTimeZone = TZConvert.GetTimeZoneInfo(timeZoneId);

It has the ability to work with any time zone provider.

// Either of these will work on any platform: 
TimeZoneInfo tzi = TZConvert.GetTimeZoneInfo("Eastern Standard Time"); 
TimeZoneInfo tzi = TZConvert.GetTimeZoneInfo("America/New_York"); 

Alternatively I read that Noda Time lib doesn't have these issues, for right now before a release I just want to resolve it with the least code change.

I recently made some progress on this blog and wanted to push the latest changes live. I've been using EF Core migrations to assist with any data related changes, and it has worked out very well for me during development. When it's time to push to production I expect it to work just as well, but nonetheless I want to first see what others think about using EF migrations against a production database.  So I found this StackOverflow question Is it OK to update a production database with EF migrations? The short answer is YES! Now having done this myself, I can say that EF migrations used in conjunction with Azure deployment slots makes production deployment really easy. In this post I want to explain my setup and the simple steps I followed to upgrade this site.

Deployment slots

Azure app service deployment slots give you the ability to setup multiple environments like production, staging and test, and quickly swap between them.

This feature is only available on standard service plan or higher. This site was running on Azure B1 App Service plan, so I had to scale it up to a S1. With the standard plan I created a Staging slot.  Also previously I had a S0 SQL Database as my production database, this time I created a Basic SQL Database to serve as the Staging database.

Here I'm trying to save money so I only created two environments, production and staging, and let staging serve as testing.  Theoretically staging should closely mimic production and even share same database.   

In addition to app services and databases I also have separate Application Insights and Blob Storage accounts for each of the production and staging environment, they are not shown on the diagram.

Deployment steps

Step 1

Last year I had my v1.0 app deployed from github on to the production app service, and EF Core automatically populated the production database. This week I did the same thing for the Staging app service and database. 

So by this time the Production and Staging environments have the same exact code and DB schema.

Step 2

I deployed the v1.1 alpha to staging slot and let EF upgrade Staging DB to the newer v1.1 schema. Here I actually have a choice of running a SQL upgrade script myself to upgrade the database or letting EF do it, more on this later. 

This step is critical, because if it works then when I push v1.1 to production it should work too.  But I did encounter a BadImageFormatException right after I pushed v1.1 to staging, this error never occurred to me during development and it took me a while to track down what was happening.  The point is by deploying to staging first gave me the chance to fix that.  

At this moment the entire Staging web app and database got the latest code and working well.

Step 3

It was time to do the swap, but before doing that I made sure I had the slot-specific settings in each production and staging's Application Settings checked. Each environment has their own database, application insights and blob storage, by check marking them these settings are not going with the swap.

Now I was ready to do the swap and I had a choice of doing a Swap or Swap with preview. In either case let's make staging the Source and production the Destination. 

Doing Swap will start swapping the source and destination immediately, and the first time I did this it took about 1 minute and 15 seconds to complete.  Basically Azure first warms up the staging slot and then completes the actual swap. 

The Swap with preview on the other hand is not immediate, according to the Azure Doc the following happens.

• It keeps production unchanged so existing workload on that slot is not impacted.
• It applies configurations of production slot to staging slot, including the production slot-specific settings!
• It restarts the worker processes on the staging slot using these production configuration elements.
• When you complete the swap: it moves the pre-warmed-up staging slot into the production slot, and production slot into the staging slot as in a manual swap.
• When you cancel the swap: it reapplies the settings of the staging slot to the staging slot.

Below is a screen shot that shows when you do Swap with Preview the connection strings used by both slots are the same.

Step 4

When you preview swap, the staging site shows up with production data, in other words Azure warms up the staging slot.  So when you are ready to Complete swap it's actually done more efficiently than previously when I did the direct swap, the complete swap step took only about 20 to 30 seconds.

EF Core Migrations

For the upcoming Fanray v1.1 I made a series of changes to the database schema, including add and rename columns, make column nullable, update existing data and insert new data.  As I mentioned in step 2 I had a choice on how to do the database upgrade, I could either let EF do it automatically or I can use EF to generate an upgrade SQL script first then run that against the database. In some organizations they prefer to have a DBA look over any SQL upgrade script first.  I have tried both ways and both worked perfectly.

To generate the SQL script you can either run the EF PowerShell command Script-Migration or the dotnet CLI command dotnet ef migrations script . 

Final thoughts on what happens during the upgrade 

Remember back in step 3 during the swap preview, the staging actually gets all the production's settings.  As a result EF is actually upgrading your production database at this point already.  Based on the success of step 2 I know this upgrade should work, but while that's happening remember the production website is still running v1.0 of the app against the same database which staging is upgrading to v1.1! 

I tested locally my v1.0 app does work with v1.1 DB schema, but this obviously is an issue if there are breaking changes. The site visitors may experience error during that one-minute swap on the live site.  The first thing comes to my mind to remedy this is to use an old trick app_offline.htm, as discussed in this SO question How to use IIS app_offline.htm file with Azure. The downside of doing this is that even though the swap happens pretty quickly but still during that time your site is down to your visitors.

One of the answers on that SO question mentioned "you should be able to virtually eliminate down time with Azure by running multiple instances".  As I explained above I'm not sure that's the case.  The comment left below this answer is more inline with what I have noted.

My co-founder is actually the Azure expert on our team, and we are already running multiple instances with SQL Azure. However, earlier today, he needed to update the DB schema which meant that part of the site was down for several minutes. When I hit the site, I was redirected to my main ErrorPage. But I would have preferred to have had the app_offline.htm file in the root during those few minutes. I was just under the impression that it's non trivial to be doing file I/O related things on an Azure deployment.

Also Azure provides SQL Database backup so if upgrading the production database fails you can restore it from your backup.  This has been my deployment flow so far, but is there a better way or how are you guys approaching the deployment and upgrade of the production database?  Please let me know what you think.