Server side no-cache

To prevent unexpected client caching (e.q. in IE) we implemented NoCacheAttribute in REST services.

We use for services ASP.NET MVC technology. So, we created custom ActionFilterAttribute:

public class NoCacheAttribute : ActionFilterAttribute

{

public override void OnActionExecuted(ActionExecutedContext filterContext)

{

filterContext.RequestContext.HttpContext.Response.Cache.SetCacheability(HttpCacheability.NoCache);

}

}

To use no-cache ability we need just mark our controllers with this attribute. In our case we marked base plugin controller and resource controller (that provides TP entities).

Feature toggling

Today I've listened to the presentation on infoQ http://www.infoq.com/presentations/Feature-Bits.

I've learned several recommendations (if you'll watch it you probably can learn much more :-) )

1.) Do not have a lot of toggles in production at one time. It is really hard to support all of them and leave them independent.

2.) Features with toggles should be independent. Otherwise a real mess can occur.

3.) All toggles should be tested and better with all variations. That is why point 1 is important. Otherwise your QA guys will kill you :-)

4.) The following patterns for implementations were mentioned : Strategy, Factory, Chain of responsibility.

5.) Probably you should automate your tests to test different toggles. Probably we should think about that.

6.) Delete toggles as soon as possible.

7.) Do not have UI for toggles. Otherwise it will be hard to achieve point 6.

The Liskov Substitution Principle. Once more :-)

I hope all we know 5 SOLID principles and Liskov substitution as one of them.

It is:

FUNCTIONS THAT USE POINTERS OR REFERENCES TO BASE

CLASSES MUST BE ABLE TO USE OBJECTS OF DERIVED CLASSES

WITHOUT KNOWING IT

It sounds simple and logical. But actually it is easy to find some code in TargetProcess which breaks this principle.

There is always a temptation to write the following code in derived type :

public class B : A {

public override void DoSomething()

{

if (_some_condition)

{

base.DoSomething();

}

else

{

this.DoSomethingElse();

}

}

}

This {if} statement can be masked much more.

What is the problem of such hierarchy? You do not know how your classes will be used in future. And client of your classes is expecting that A class is a variety of B class. So he/she may write some code which will not work correctly with both A and B instances. And after all some ugly checks may appear :

public void Do(A a)

{

if (a is B )

//...... oh man!?

}

Or probably the code will be refactored and hierarchy will be broken.

The simple idea --- inheritance should be used only if it satisfies Liskov Substitution principle. Otherwise some other patterns should be used for code re-use.

Plugin Mashup: whole folder posting functionality

Hi,

instead of bulky code like:

public class PluginMashupRepository : IPluginMashupRepository

{

public PluginMashup[] PluginMashups

{

get {

return new PluginMashup[] {

new PluginProfileEditorMashup(new[]

{

@".\UI\Mashups\navigator.js",

@".\UI\Mashups\editor.template.js",

@".\UI\Mashups\jquery.utils.js",

@".\UI\Mashups\profileNameSource.js",

@".\UI\Mashups\profilerepository.js",

@".\UI\Mashups\commandGateway.js",

@".\UI\Mashups\errorMessageContainer.js",

@".\UI\Mashups\SubversionProfileEditor.js",

@".\UI\Mashups\registerMashup.js"

})

};

}

}

}

We can use:

public class PluginMashupRepository : IPluginMashupRepository

{

public PluginMashup[] PluginMashups

{

get { return new PluginMashup[] {new PluginProfileEditorMushupFolder(@"UI\Mashups")}; }

}

}

A class PluginProfileEditorMushupFolder was introduced in Plugin SDK in order to simplify whole folder content posting because usually we need to update this repository as UI/Mashup folder is changing.

One XP Episode

We all know about TDD (Test Driven Development) and always try to apply this fashionable practice. Yesterday I read one fine article by Robert C. Martin http://objectmentor.com/resources/articles/xpepisode.htm. There he and his friend are implementing a program which calculates bowling game scores. And one thing impressed me a bit in this article.

Those guys started with common practice : draw object diagram. And the diagram seems logical and correct to me. Then they started implementing unit tests. They wrote tests one by one, but objects that they drew didn't appear in code. The final solution greatly differs from object diagram and contains only two classes. Despite this it looks simple and each class contains single responsibility.

The conclusion is not that object diagram are useless. But all diagrams should be proved by code, and you should not follow them strictly.

I really recommend this artcile for reading. It's a clean example of TDD, and dialogs are rather funny:-)

Seven reasons when IIS restarts web application? No! Even more!

Sometimes we got stuck with a problem which can took hours to figure out and a minute to resolve.

A couple of days ago we run into the issue when Target Process was bloody slow.

After short investigations it comes into our mind that it constantly finishes web application and restarts it again.

It was finishing with no clear reason, no exceptions, etc.

There are seven reasons for application restrart in ASP .Net, but no one was fit into our case.

I won't be telling the whole story, but finally we've found additional reason for application restart:

ASP .Net restarts application when a folder is deleted

It is so when a plugin is started and it's javascript mashup with UI implementation is saved under a new folder on Tp.Web (previously created folder is deleted)

We solved this issue by not creating a folder with plugin mashup javascript. We just store javascript with a new name with plugin name prefix added.