Tech Blog

Jay's Technical blog

TypeMock Isolator for SharePoint for free

25 November 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

Here’s the info:

"Typemock are offering their new product for unit testing SharePoint called Isolator For SharePoint, for a special introduction price. it is the only tool that allows you to unit test SharePoint without a SharePoint server. To learn more click here.

The first 50 bloggers who blog this text in their blog and tell us about it, will get a Full Isolator license, Free. for rules and info click here. "

(and yes, I’m trying to get a license)


"Subsonic" for Services found: Subsonic 3 + ADO.NET Data Services (Astoria)

18 November 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

About a month ago if you asked me what was big in my dev world (in other words what are you looking for).  I would have promptly told you that I was looking for the "Subsonic" of services. In other words I wanted to create a database and hook a connection string and have everything generated for me... I want drop dead simple.

Astoria was as close as I could get, but it didn’t quite achieve what I was looking for. Don’t get me wrong, it’s easy enough. I’m just not sure what I think of EF yet which is not to say that I don’t like it... just that I sometimes want something simple. Rob Teixeira has noted that for some there are "too many knobs." I’d have to say I’m somewhat in that camp (although I’m not very informed either and I’m not a huge lover of Linq to SQL either).

I love the simplicity of Subsonic. I really do, and I really want to leverage something that simple for building a Data Service. Rob Conery (I love Rob... You can have ScottHa or Haacked... I’ll take Conery... He’s my hero!) recently released a preview of Subsonic3.0 which is fully Linq-Queryable and also has the normal Subsonic Query engine... it’s the best of all worlds (except it’s not backwards compatible).

Since my readings from John Papa’s book taught me that Astoria doesn’t need an EF model that regular classes could work, and I have a personal project that could use an easier more service friendly manner of editing/viewing data, I decided to try this out.

Preview 1 was an abysmal failure. Well, to be fair I quit because Preview 2 came out. I stuck with Preview 2 and earlier today I got it all working.

  1. Here’s how to do it. #1 follow Rob’s instructions (on any of the links I’ve provided and get Subsonic stuff working). I did all this in a separate DLL project.
  2. Create a regular web site (or web project)
    1. make sure there is a connection string in the web.config that has the same name as the "ProviderName" variable in the _Settings.tt file
    2. Add an ADO.NET Data Service to your web site/project.
    3. Add this attribute to your service class
      [System.ServiceModel.ServiceBehavior(IncludeExceptionDetailInFaults = true)]
    4. Next set the DataService T type to the "DB" class of your Subsonic generated class. It will look something like this:
      publicclass NorthwindService : DataService<Northwind.DB>
  3. Tada! You are done...

A couple notes

Both Preview 1 and 2 build a class model that exposes an object/class called "DB." Think of this class as "Context" (even though EF and Linq2SQL context classes do a lot more). For the sake of Astoria, you just need a class that exposes all your entities in an IQueryable manner (which "DB" will do).

I ran into one error that was messing me up. If you make name of your Primary Key IDs "ID" then everything in the above worked fine. If it didn’t I am going to provide an alternate set of templates (TT files) for you to use. What’s missing is that Astoria expects an "ID" property. You can get around this by tagging each entity class with

[System.Data.Services.Common.DataServiceKey("{tablename_id}")] 

This also means that you have to include the System.Data.Services.Client.DLL in your Subsonic project.

My TT files (based on Preview 2)

I added a new variable in _Settings.tt that let’s you turn off the attribute used for setting the PK in your entity classes. It’s called "EnableForUseWIthAstoria." Here they are :

Closing thoughts

With all this in hand you should be able to create Astoria Services with any DB that Subsonic supports (which I believe is a larger number than what EF currently supports.

Additionally, like Rob Conery, I want to stress this is all experimental. This code might run off with your wife, children, it might decide to use your PC late at night to play video games thereby increasing your electricity, etc. (in other words this is all experimental right now... have fun with it, and be careful ... you probably don’t want to use it for live/mission critical code).


TUX: Update...

13 November 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

Last night we had a fabulous night at TUX. I really think we are starting to hit stride now. Shawn Cady (our resident Dev-signer) did a fantastic presentation on using heatmaps for UX analysis. Before launching into this demo he decided to do a fabulous overview of UX. His thoughts echoed my own as I was planning on having an open discussion on this very topic.

I would be remiss if I missed mentioning that Marc Aniol followed up with a demonstration of Astoria (ADO.NET Data Services) being used with MS Ajax Templates (and Virtual Earth, and a little jQuery). It was very natural for Marc to frame his very practical demo in light of UX.

Don’t worry if you missed Shawn’s talk, we’re planning on revisiting this topic in January (that’s right we are taking the month of December off). If you came the first week and haven’t come back, you need to come back. Why? Last night was the first night that I felt like we addressed some of the issues with the first night (like "what was I/Jay thinking doing a hardcore JS discussion for the first meeting?") Seriously, I am very excited about TUX and not just as a I guy helping to run it.

Our plan is to record the follow up "What is UX?" session and make it available on our TUX user group site. After that we will require all speakers to review this video and to put their talk into context of this discussion (of course, this isn’t a hard rule... we’ll always help the speaker frame their talk).

What we are about at TUX is exploring this topic of User Experience, and trying to learn together how we can all do a better job of making our apps friendlier to our users and provide a decent experience to them.


Multiple threads to improve UX (User Experience)

11 November 2008
Jay Kimble

[WARNING! This is an archived post and as such there may be things broken/missing here.. you have been warned.]

Shawn (of TUX -- BTW, we have a TUX meeting coming up tomorrow night) pointed me to a pretty cool article yesterday. It’s the End Bracket in this months MSDN Magazine. You can read it online here.

Perry (my boss and also of TUX) and I have been talking about some things related to our ASP.NET app’s reporting module (among other things) that additionally got me thinking.

This is pure theory (and potentially a really strange idea)... I admit this up front, but I’m going to throw it out for all to see (and potentially make fun of or to improve on).

The idea (in case you are skipping the MSDN article) is this: if we could predict what the user will do next we could fire up a thread and attempt to pre-load the result into a cache before it is even requested, so that when it is requested we could immediately respond to the user with a result. If the user doesn’t request the item, we can simply throw away the result.

What this does for the UX is that our UIs seems very fast because they are predicting exactly what the user will do. BTW, that Windows OS that no one likes (and is lampooned by the Mac commercials) does this; from what I understand it does things to try to predict what you will do next (and acts accordingly). For Windows/Desktop apps this stuff is easily accessible and used... for web apps not so much (read on).

The Caveats of Background Threads with Web Server processes
[WARNING: Before I continue, by no means am I threading guru. I understand enough to actually talk about the topic. Beyond playing with PLINQ at a very minimal level, I have never written an app that triggered background threads, so understand that like many things I am NOT an expert... just a mad scientist playing with forces he doesn’t fully understand <wink />]

Here’s the problem (as I understand it... you are welcome to correct me and I will be more than happy to correct this section). If you attempt (and I’m not sure that you can without much effort) to spin off a thread from an ASP.NET server process that thread will die the moment that the web request is complete, so you either have to wait for your thread to complete before ending the web request (not really a viable option when the idea is to pre-load something and get it later) or you have to figure out how to spawn that thread into its own process which will live until it completes (my brain starts swirling at this point... something about App Domains and other stuff... bottom line is that it doesn’t work directly from an ASP.NET process).

This is a problem I have found interesting, but have never really devoted a lot of brain cycles to because I haven’t had a use/need for it.

Jay’s Crazy Background Loader Service Idea (very early in my thought processes)
What we need is a Windows Service whose entire job is to execute background tasks for the ASP.NET. It would share our data model or any other library that our web server would use except that it would only be used for loading data into the cache and would be thrown away after a specified period of time (or if the user chose a different path your web app could clean up the cache). What would really help this thing out would be to use MS Velocity or memcached so that the ASP.NET app and the Windows Service shared the same cache area (and distribute it over several machines.. if you have them) [BTW, if you haven’t researched distributed memory cache mechanism you would be wise to do so sooner than later... I’m really impressed with the idea, and the effect they have on apps --at least what I’ve read about them-- is truly impressive]. ASP.Net ThreadService [Wow! a diagram!]

Anyway, you have the diagram now of what’s in my head

Alternatives -- Ajax mechanisms
Since Ajax does async processing we could also do something like this with pure JS code. Simply by calling services we could predict the user’s actions and load the data in memory and simply use it when the user requested it. The only problem with this that I see is that while modern day JS still sometimes seems fraught with memory leaks and memory heavy clientscript apps sound a little scary to me. I think it’s doable, but you are definitely going to want to minimize the amount of data you would want to load. This really brings us to a bigger question...

How liberal do you get with "pre-loading"?
The more I think about all this the more I start to ponder how often would one do this. Should it be done only with the long running processes (those database queries that take more than a few seconds)? Is it OK to use it with smaller datasets (faster running database selects). Obviously we don’t pre-run database updates as that would be really bad IMO, but long running updates could be tossed into the same threading mechanism (and return quickly as long as the app didn’t need an ID back from the process. Should you load up every GB of memory your machine has? What if your web site gets popular and you are encountering hundreds of hits a minute? It’s a good problem to have, but maybe it creates bigger problems. Maybe creating a farm of machines whose purpose is to run background threads and have a central controller to direct the web app to the next machine to run a process on. It’s something to ponder. Not sure if its quite viable for ASP.NET (but I sure would like to try it... at least in a simple scenario where pre-loading the data will always net a result that is needed later).