December 2005 - Posts

The Atlas December CTP is coming
12-22-2005 10:06 AM
According to Nikhil we should be able to download the Atlas december CTP from the Atlas community website in a few hours. Although I read the words a 'few hours' last night... I suppose, since as we all are developers, we can quite understand the concept of 'releasing in a few hours' :-)

I have been waiting a while for this one. The current build from october is very difficult to work with, the documentation is also very rigid and hard to follow. I am very pleased to learn that they have killed some of the unusable pesky Atlas controls that were in the previous build, quoting Nikhil:

"You may wonder what about all those atlas server controls we had in our PDC release. Wasn't that our integration with ASP.NET pages? Well, in short, they're gone. These controls were really of out of place. They essentially enabled you to generate XML script using server controls. So in order to use them, you first had to learn XML script, and then you had to map those constructs into server control tags. And despite being server controls, you weren't able to use familiar server-side code and programming models to work against them. For this release, we put in a new set of server controls that have been developed with a different perspective."

After reading Nikhil's post I am quite delighted to see that they are doing their best to give us the programming model we are allready familiar with, which is ASP.NET serverside code. Just have a look at the new incremental updates and partial refreshes, very powerful. Interesting sidenote though... this is exactly the approach the guys from MagicAjax have been working on for a while now.
Large scale architectures
12-19-2005 3:49 PM

TheServiceSide.Net posted an article on "five considerations for large-scale architectures" a while ago. If architecture is not your thing this article might be appealing to you.

If large-scale architecture on the other hand IS your thing I found a very interesting aproach to stateless Arcitecture on Tim Wolter's blog. I knew that Google had an architecture in which they keep all their data in memory without ever hitting the disk, which is in part one of the reasons why Google is so damn fast. What I did not know was that this approch actually had a name.

The basis for this article is actually quite current when looking at the major outages that have been occuring throughout web2.osphere recently...

Of course designing for these kind of architectures can be either a complete overkill ("will our service scale so far that we need to design for this?") or a wasted opportunity ("damn, our service scaled further than we ever had anticipated!").

The thing is, right now I am working on a pet project that might go totally unnoticed or become on of the hot items in .net developers land. Who knows? Will I architect for this? Looking at the little time I have... nah I don't think so :-) Very interesting nevertheless.

Search engines are dead, long live the search engine!
12-08-2005 1:32 PM

Search engines are dead, long live the search engine!

I have been thinking a lot lately about the relevance of results that search engines like Google, Yahoo or MSN-search return. Although the ‘search experience’ is relatively good when your search criteria have a wide scope, the experience degrades considerably when doing very domain specific searches (try searching for SOA in the Dutch version of Google :-)). I’ll try to explain what I mean with this the preceding statement.

A few days ago I was having a discussion with a co-worker of mine who was looking for some background information on deploying a new technology that hadn’t been used before in the organization. His solution was very nice and well architected; it was simply the fact that the influencers needed to be influenced by providing them with some unique selling points.

So I decided to do a Google search on the use of this particular technology within large enterprises. The results I got back weren’t really interesting for me since most of it were about problems people were having while using this particular technology.

The second thing I tried was doing a search in the data my local RSS reader contains. I got back exactly those things I was looking for in the form of blog posts by several developers.

This is an interesting phenomenon and kept me thinking a while. Although I am not fully aware of the algorithms used by the big search engines to index their sites I somehow get the feeling that the relevance of the search results has degraded over time. It occurred to me that there might just be a solution for this problem in the form of the social tagging phenomenon that has been raging the internet the last couple of months.

Social tagging is in essence a way to describe the internet using meta tags. Delicious (http://del.icio.us) is more or less the most active social tagging community on the internet.

People can post links to delicious and add some meta tags describing the link that was posted. The posted link gets added to your personal bookmarks (there are tools that can synchronize these with your local bookmarks). Nothing new you would say? The power lies within the fact that you can see what tags other people have used to describe the same link you have posted (hence the social aspect), and see which links people have posted under these other tags. This is a completely new way of surfing the web and can be quite rewarding with several gems that you might never have found otherwise.

Now I can hear your thought process going… “a user maintained content database is only as good as the sum of its users, this will never work”. I do agree with that.

However, suppose you take the social tagging approach and combine that with the weighting scenarios search engines like Google apply to their data… you might just have found the search engine that gives you the relevant search results that you have been looking for so eagerly. Human intelligence for relevance and quality, machine intelligence for scoping, relationships and quantity.

What also would need for a successful implementation are focused social tagging groups. Delicious is simply a place for all things interesting to everybody. What you would need is a focused amount of people that are tagging the Internet within a specific niche domain.

My domain is that of a “software developer”. We need a community that tags everything within this domain of “software development”, the big win would be our ability to cluster tags because we can accordingly identify and categorize them since we only exist within this specific domain. When searching for “VSTS” our search engine could identify this term as belonging to the (user maintained) cluster of “Visual Studio Team System” or “Team Foundation Server”, which all belong more or less to the same product. I would expect to see all the search results on a given tag returning everything within the cluster of tags this tag belongs to. You can stretch this out to the extent of clusters being children of a bigger cluster or containing relationships with other clusters… the possibilities are endless.

The third aspect that is required for this kind of solution to work is opening up the API. We need to open up everything. Ideally we would like to have our results be included in the search results of the bigger search engines (Google, Yahoo, MSN search) for a broader audience.

Imagine the power of a big search engine crawling these focused tagging communities on the internet (we need to define a common API for this… SSE?) and making use of their content which is probably a lot more relevant since human-intelligence has been used for kick-starting.

In my opinion Web2.0 is all about this (at least, the non over-hyped aspect of it) openness and integration of technology inside the semantic web.

I am thinking about, and working on, applications for making these kinds of scenarios possible. I do think that this is the way to go in the future for improving our search experience. Expect to see an implementation of this concept in the near future. I am very curious what the effect of this little experiment will be.

The Smart Client debate rages again
12-06-2005 4:30 PM
I have been following the discussion on Smart Clients between Rob Howard and Paul Ballard lately. You can find Rob's overview of the different posts here. Altough fun to read, the point of this discussion somehow seems to elude me.

Rob's point of view is that Smart Clients are definatly a good thing in their own aspect, but that the acceptance rate isn't  really impressive. He concludes in his first post with: "Why should you care about writing smart clients. You probably shouldn't. If you can write it as web application do it. It's easier to support, faster to author, easier to distribute, and everyone can run it without installing anything."

In my opinion both Rob and Paul seem to forget mentioning the real business value behind Smart Client applications. We are not talking support, authoring, distribution nor installation but we are simply talking about the ability to maintain local state and integrating with existing (desktop) line of business applications.

At Macaw we have developed several Smart Client applications, one of which I was quite deeply involved with for one of the larger ticketing providers in Holland. In this particular application one possible scenario would be the lady behind the counter which is helping you prepare your flight to Australia. Suddenly her phone rings and a second customer is asking whether his hotel in Spain has allready been booked.

In the previous line-of-business application this lady was forced to write down the phone number of the calling customer, help you first and then afterwards call him back later. Why? Because they used a web application which simply wasn't built for this kind of  multi-tasking scenarions (due to the stateless nature of the Web and the tools that exploit the Web, webbrowsers).

In the new version of this application, which as you can guess was built as a Smart Client, we were able to introduce the concept of sessions. While the lady was working on your request she simply hit the new session button, do some quick checking, answer the calling customer directly and continue with our lovely trip to Australia. We would save te running session in the background and se was able to switch between these inside the same application!

The second thing in which this Smart Client exceeded the traditional Web Appliations was in the utterly complex validation rules required to, for instance, book a flight from Amsterdam to Sidney. There are several thousand airport codes that the user of this application needed to remember before. We can cache these locally and provide UI cues while typing (you can do this with Ajax you are probably going to say... if you look at the complexity of te data we needed to process at runtime, you will disagree). We can validate the availability of a flight before the user is allowed to move to the next screen, heck we can even offer alternative flight plans to the user without having him login to any third system in order to verify these. All of these, very efficiently in one screen.

An not to mention the crashing webbrowsers because of the uttery ugly JavaScript hacks we were able to eliminate because of this. If the user loses power or his network connection, he is able to continue exactly where he left off.

I think I have pimped this application enough and you have a good sense of what we have been able to pull off because we weren't tied to the stateless nature of the web. This is just one of the Smart Client applications we (Macaw) have built.

My point is that there are a lot of Smart Client applications behind corporate firewalls that you or I won't see. The discussion that Rob and Paul are having is about Smart Clients on the web*. There is very litte business value in these because of the reasons Rob mentiones. But there is a lot of value for Smart Clients in the corporate setting where these reasons are no way as expensive as not having a Smart Client.

* There is no law that states that we can't use the internet as a distribution mechanism for our Smart Client, because that is exactly what we do