Got a nice little tip today from my friend and colleague Björn. Check out the difference in these approaches for testing strings, using the Equals method:

string someString = null;
if (someString == "gnu") //This is error prone if someString is null
{
}

if (someString.Equals("gnu")) //This is error prone if someString is null
{
}

if ("gnu".Equals(someString))//This returns false, if someString is null
{
}

Nice, huh? :-)

I came across a really cool tool today. Not exactly new, but still pretty cool. It's called Windows SteadyState and it makes it easy to manage computers used for shared access, such as computers in libraries or schools.

Personally I see some possibilities in making a very specific paranoia disappear: You know the feeling - some visiting family member or your media naranja wants to use your laptop. But your laptop is not just any laptop. Your laptop contains code lines counted in hundreds of thousands, it contains all your mail for several yeas back and of course many of your latest party pictures. The laptop in question is indeed your precious one. ;)

Of course, all that data (or at least the important stuff) is backed up on a regular basis, and of course you have created a special account for them to use, which, among other things, disables access to the business section of the disk drive. But still, there are still things that you cannot control in ACLs and policies (yet): why is she hovering her cup of hot tea directly over the keyboard, why is he balancing the laptop on one knee while playing with the remote control to the TV?

Windows SteadyState can help you in a simple way, and make your efforts last. It makes it easy to take some 2. rank computer and make it the "shared" computer in the household, sparing your laptop from manhandling by barbarians with no respect for technology! :)

Check Windows SteadyState out here... 

During the Banedanmark HTS project, the new announcement system described in my previous post, we experienced a relatively large overhead when the Window Forms .net client called our web services.

After searching the Internet I found this posting on via google groups, Web service calls seem too slow, in which the original poster (OP) experiences the same kind of overhead. In his last posting, the OP elaborates on the difference in overhead between anonymous web service calls and NTLM authenticated web service calls, and concludes that Windows Integrated authentication is the bottleneck.

The solution, as described in the last posting, is that you can set HttpWebClientProtocol.UnsafeAuthenticatedConnectionSharing to true. You will gain performance and still have NTLM authentication, however, beceause of the reuse of server connections, you might expose security holes. So check out the links in the last posting and get familiar with the downsides before you start using it.

Cheers.

I have just finished the last page in Neil Strauss' The Game, a non-fictional story about an ordinary guy who turns himself into one of the worlds best and most respected PUAs - Pick Up Artist. Although a wildly hilarious and crazy story about, among other things, how to get a girls phone number in less than 15 minutes, it is not for the easily offended. This book is probably one of the most explicit I have ever read. :| You have been warned...

I was talking to Jesper a couple of days ago, and he suggested that I should write a little background information for some of the Internet resources in my previous post. Even though I consider the resources quite useful as they are, I agree that a little context information would be good for better understanding the value of the link and also for discussional purposes. So please, if you have any input, throw me a comment, ok? :)

In this posting I will elaborate a little on the SOA: The Subscriber-Publisher Model, Introduction and Implementation resource.

First a little background info on the HTS solution, the new announcement system at Banedanmark (who owns the Danish railway infrastructure).

The HTS solution consists of 3 tiers*: the HTS smart client tier (Windows Forms .Net, this is the end user interface), the HTS (high level business logic of the HTS system exposed in an asp.net web service), the HTS Core server (low level logic, that delivers the announcement to the speaker hardware, contained in a windows service, exposed in an asp.net web service via remoting).

Now, the end users works in the HTS smart client in so called workspaces. Each workspace contains a pre defined amount of announcement resources that the user can create new announcements to. The workspace also contains two lists, one for showing scheduled announcements the next 24 hours on the resources, and a list showing processed announcements 25 hours back in time.

Now, as users can work in the same workspace on seperate computers at the same time, and because the HTS server and Core server continuously processes the scheduled announcements, the lists in the workspaces must to be updated to show the state of the system correctly. There are basically two ways to do this, pull or push. Pulling in this context means that the HTS client initiates the update of the lists at certain time intervals and polls for content from the HTS server. Push in this context would be an update of the lists initiated by the HTS server. 

Pull is easier to implement compared to push in this context, and pull was the chosen strategy for the HTS solution. However, ease does not come without a price. There's no doubt that the pull strategy is by no means as scalable as the push strategy. The pull strategy generates a lot of traffic and load to the server, even though no change may have happened on the server and the server therefore has nothing new to show to the user. However, the amount of users was known at design time, and therefore we could calculate on the server load.

However, in a different scenario with a lot more users (or workspaces), a push strategy should be considered. The server could serve many more users and still easily compete with the pull strategy in terms of traffic and load, since there's no or little communication between clients and server when there's no change to show. Only when a change happens are the subscribing clients (or maybe even just a subset of them, depending on how complex your implementation is) notified with new data.

Now, there's many differenct ways of implementing the push strategy, and the link above is one way to do it (however, the solution described was not used for Banedanmark HTS). I have also seen articles and discussions on how to do it with either .Net remoting and MSMQ. In a discussion about a .Net remoting implemention, someone cautioned of two things: Alleged instability of .Net remoting (that is, there's a relatively large chance that the message never reaches the client) and that the notification is synchronous (which can mean that a stalling client can kill the notification round or at least cause a serious delay). On the other hand MSMQ can be used to make an asynchronous notification, where the server puts the message into a MSMQ queue on the client. The client then polls the local MSMQ queue for changes. This is good because the server can deliver to one client and directly continue to the next, no matter if the first client was ready or even responsive. However, when doing this with MSMQ, remember a good rule of thumb: Deliver remote, poll local.

Anyways, even though the above just scratches the surface of how to implement push, it should be clear that push is a little more complex and demands more effort than pull. The advantages should be clear, though...

(As a side note for anyone at Banedanmark, who might be reading this: The communication part in the HTS client is properly wrapped, and is internaly based on events. So, the transition from pull to push, from HTS client perspective, should be a minor change, should you consider changing it. Impact on the HTS server however depends on the chosen technology.)

That's it for now. I hope this background info on the link gave a little insight. Please do leave a comment on subject, content or form... :)

Christer

A lot of coffee was consumed during Banedanmark HTS :)

* I'm leaving out the speaker hardware tier and data persistance tier here for simplicity.