Do Not Use Database Trigger

Or rather, use database trigger carefully.

Trigger is convenient and easy to write, but wrong implementation of database trigger can cause serious performance issue.

Basic rule is to avoid database trigger at all cost, find alternative way to achieve same result. Below is a video from Pluralsight showing usage of a database trigger that performs poorly. The slow performance caused by overhead that comes with database trigger, in this case the operation reads more table that necessary. When alternative approach is used (setting default constraint on a column), the difference is significant.

Try it for yourself.

-- Create our demo
CREATE TABLE [dbo].[charge_demo](
    [charge_no] [dbo].[numeric_id] NOT NULL PRIMARY KEY CLUSTERED,
    [charge_no] [dbo].[numeric_id] NOT NULL,
    [provider_no] [dbo].[numeric_id] NOT NULL,
    [category_no] [dbo].[numeric_id] NOT NULL,
    [charge_dt] [datetime] NOT NULL,
    [charge_amt] [money] NOT NULL,
    [statement_no] [dbo].[numeric_id] NOT NULL,
    [charge_code] [dbo].[status_code] NOT NULL,
    [insert_dt] [datetime] NULL;

-- Create our trigger
CREATE TRIGGER [trg_i_charge_demo]
    ON [dbo].[charge_demo]
    UPDATE [dbo].[charge_demo]
    SET [insert_dt] = GETDATE()
    FROM [dbo].[charge_demo] AS [c]
    INNERT JOIN inserted AS [i] ON
        [c].[charge_no] = [i].[charge_no];

Source: Hidden Side Effect of Trigger

HttpContext vs HttpContextBase vs HttpContextWrapper


Good ol’ HttpContext in ASP.Net. HttpContext has no base class and isn’t virtual, thus, is unusable for testing and unmockable. Strongly recommended to not pass it around as arguments. Instead, pass around variables of type HttpContextBase.


New to C# 3.5 and meant to replace HttpContext. HttpContextBase is abstract, thus, it is now mockable. Concretely implemented by HttpContextWrapper.


Also new in C# 3.5 – this is the concrete implementation of HttpContextBase. To instantiate in a normal webpage:

var webContext = new HttpContextWrapper(HttpContext.Current)

The whole idea is to make your code test-able by allowing your test framework to mock the HttpContext.

More detail explanation on here.

.Net 4.5 Claims and Tokens as Standard Model

Notes from Dominick Baier’s .Net 4.5 Claims and Tokens Become the Standard Model.

You can also download Guide to Claims-Based Identity and Access Control book from Microsoft Patterns & Practices.

ClaimsPrincipal & ClaimsIdentity Class

MSDN source for ClaimsPrincipal
MSDN source for ClaimsIdentity


ClaimsPrincipal Inheritance


ClaimsIdentity Inheritance


Identity Specialization


Processing Pipeline (Per Request)


ClaimsAuthorizationManager Class

MSDN source for ClaimsAuthorizationManager


Authorization Context (CheckAccess)

Using ClaimsPrincipalPermission to restrict access. MSDN source for ClaimsPrincipalPermission.


Leap Year Is Not Every 4 Years

When I was first asked to write function for checking leap year, I instantly answered by writing a function to take the year and divided by four. Wrong.

To begin with, the leap year is not every four years. As to why, there are many answers / discussions out there. But, basically:

A year will be a leap year if it is divisible by 4 but not by 100. If a year is divisible by 4 and by 100, it is not a leap year unless it is also divisible by 400.

Based on that, the JavaScript function to check for leap year look something like:

function isLeapYear(year) {
    return (year % 100 === 0) ? (year % 400 === 0) : (year % 4 === 0);

Or an easier way:

function isLeapYear(year) {
    return new Date(year,1,29).getDate() == 29;

SignalR Protocol Endpoints

This applies to SignalR 1.0 and .Net 4.5

Base endpoint


JavaScript proxy








What is Dirty Read?

No, it’s not reading a dirty or muddy book.

Dirty read happens in database processing when one transaction can change value and another transaction can  read the same value before the first transaction is committed or rolled back. In this case, there is a possibility the first transaction roll back causing the second transaction to read invalid value.

Although there is a way to set a database to disallow dirty read, the process degrades performance of an application because of locking overhead. It also decrease system concurrency.

What is Queue and Stack?

Stack is LIFO (last in first out) or FILO (first in last out).

Queue is FIFO (first in first out) or LILO (last in last out).