The Spin, Oh My, the Spin...

by jmorris 26. August 2009 21:40

A non software related tale today. Lately I have been amazed about all the 'Green Shoots' stories spun out by the media regarding economic recovery. Driving into work I heard, "Stocks open strong on good news regarding a housing recovery"....what? Well, I checked Marketwatch to see what this "good news" was and saw the following article: "US Stocks Turn Positive After Upbeat Home Sales Data". Wow, home sales climbed 9.7% in july and up 8+% year over year? Year over year growth in this economy is definitluy something to get excited about. I then turned to comments section and found this whoopee of a comment:

"As other have said countless times, please do your due civic duty of accurately reporting the facts. There is no need for the added spin MW. I feel really sorry for the editor because the constant spin is in the articles while the truth is filled up in the comments section. While we all appreciate being given the opportunity to engage in discussion, it is sad when we have to hunt down the facts on our own time. We can handle the truth so please just report the stone cold facts and let us make our own judgments and interpretations. Welcome to reality.

U.S. Existing Home Sales Yr/Yr
$0 – $100,000 Up 38.8%
100,000 – $250,000 Up 8.7%
$250,000 – $500,000 Down 6.2%
$500,000 – $750,000 Down 8.9%
$750,000 – $1,000,000 Down 10.6%
$1,000,000 – $2,000,000 Down 23.3%
$2,000,000 + Down 32.4%

Source: National Association of Realtors"

Original comment is here.

And I thought, what's the real story here? Sales of bottom of the market are up, but the mid-high level is way down. Nothing real exciting here given the 8k government subsidy and the risk taking nature of first time buyers. A little more research gives a more realistic view of the current housing market: Existing Homes: WhatsReally Selling.

The media spin machine appears to be working overtime; to bad the millions of unemployed in this recession/depression aren't feeling so peachy.

Tags: , , , , ,

Use System.Web.HttpRuntime.Cache Instead of System.Web.Caching.Cache for Unit Testing

by jmorris 24. August 2009 21:41

I ran into an interesting problem today while unit testing some code that depended upon System.Web.Cache where the Cache object itself was instantiated, but the internal dictionary was not. What happens is you end up getting null reference exceptions when you try add, remove, etc. anything from the Cache while unit testing. For example:

 



Kinda dififcult to spot what the issue is since it looks like the error is caused by the "PageTemplateKey" not matching on a cached item, but that's not the behavior of System.Web.Caching.Cache. When an item does not exist, null is returned...so what else could be causing this? The "'ContentFactory.Cache.Count' threw and exception" is the dead give away. The internal cache object was not being created in a non server environment.

For my unit tests I am using the Moq framework and mocking the major players of the ASP.NET HTTP stack. Notice that when I perform the setup on the mockContext object below I am setting the return value to be a new Cache(), this is where I am running into the issues described above.



So what to do now? There are at the least to ways to work around this issue: 1) create a mock cache wrapper or 2) use System.Web.HttpRuntime.Cache as a replacement. Opting for simplicity, I switched out the code on my MakeMockContext method to use System.Web.HttpRuntime.Cache and viola, problem solved:


This worked like a charm:

 



The reason why this works is that System.Web.Cache uses CacheInternal, which you guessed it, is set by an internal setter, called SetInternalCache. HttpRuntime directly makes the call to create CacheInternal when you access the HttpRuntime.Cache property.

Tags: , , , ,

Implementing the Command Pattern

by jmorris 19. August 2009 22:38

Command Pattern Background

One of the most ubiquitous software patterns in existence is the Command Pattern:  “Encapsulate a request as an object, thereby allowing for the parameterization of clients with different requests, queue or log requests, and support undoable operations” – GOF. It is generally used in situations where the all of the information necessary for a future call can be ‘built up” sequentially and finally executed at a point in time in the future – i.e. each action is state-full.

A common scenario is an object used to build up a database request taking in several different parameters such as the database name and location, the stored procedure name, any data that needs to be passed to the stored procedure and possibly a transaction object. Once the command has been constructed and all required parts are defined, it is executed, which delegates an action to call the stored procedure on the database and return a result set or perform some operation on an object, with the provided parameters. In the C# world, we are talking about System.Data.DbCommand and its concrete classes such as System.Data.SqlClient.SqlCommand or any other database specific implementation of DbCommand (Oracle, MySql, etc.).

Here is the basic UML diagram of the Command Pattern:

The Command Pattern typically utilizes the following actors:
  1. Client – creates the command object providing the relevant information (parameters) needed to fulfill its obligations
  2. Invoker – initiates the action on the command so that it’s obligations are fulfilled, making the decision of which of the commands actions should be called
  3. Receiver – performs the command object’s obligations, whatever they might be – i.e. makes database call or some other action

The Command Pattern Implemented

The scenario is this: a service exists which takes as input a series of inputs (a query) and returns as output, the results of those inputs as an xml stream of attributes and values. Caching at the service level and several operations are also supported: filtering, sorting, paging, etc.

Each request varies by parameters and is encapsulated as a query object defined by the client. This query object is simply a data structure that contains the fields accepted optionally be the service. The query object is executed by a command object created by the client, who delegates control to the receiver encapsulated by it’s invoking one of its action methods.

The following diagram illustrates the implementation:

 

 

The Command implementation is very simple. It contains an ICommandReceiver reference and IQueryRequest reference which stores a reference to the current query being executed. The command delegates control to the receiver, which performs its work and returns back an IQueryResponse object containing the results of the query.

 

The ContentReceiver class implements ICommandReceiver interface and simply makes the call to the remote service via a WCF client. This happens to be a very simplistic implementation in that much of the heavy lifting (i.e. caching, query generation, etc.) occurs in the service. In this case, we are simply translating a client query into a SOAP request to access the services resources.


The client uses an IQueryRequest object to build up a set of parameters which are consumed by the service endpoint via the command object. The results are returned to the client with an IQueryResponse object. How the results are used is dependent upon the client.




Finally, a simple unit test illustrating the usage:

Tags: , , , , ,

Jeff Morris

Tag cloud

Month List

Page List