February 2005 - Posts

Request for Comments: A ContentRotator Web Control
22 February 05 04:38 PM | Scott Mitchell

I am in the midst of building a custom ASP.NET server control I call skmContentRotator, which is similar in semantics and syntax to the AdRotator control. Like the AdRotator, the ContentRotator has an XML-formatted file that spells out the content to rotate through. The main difference between the two controls is that while the AdRotator randomly rotates through ads, the ContentRotator will rotate through arbitrary content.

In its simplest form, the ContentRotator would just allow vanilla HTML markup to be emitted. Of course, ideally the control would allow for the content to be dynamically determined; for example, if you wanted to display some random welcome messages, you might want to include the current date/time, or the name of the currently logged on user. Or if you ran an eCommerce site you might want to randomly display “hot deals,” which might entail displaying information about a random product from a subset of products (where the product information was stored in a database).

What do you think would be the best way to allow for this dynamic capability? Right now, I'm leaning toward having any dynamic capability required to be wrapped up in a User Control, and then the page developer would reference the path to the User Control in the XML file that spells out the content to rotate through. That is, say one of the random pieces of content you wanted to rotate through was a page that had a DataGrid with some products listed. To accomplish this, you'd first create a User Control - call it RecentProducts.ascx - that had the required Web controls and source code. Then, in the content file you'd add an item like:

<content contentPath=”~/RecentProudcts.ascx” />

On the other hand, if you just wanted to squirt in some static text into the rotation, you'd add a content item like:

<content>
static text
</content>

Any comments on this approach? Are there any features for a content rotator you can think of that are must-have? Any comments/suggestions appreciated.

Filed under:
Tracking a Book's Success
21 February 05 10:14 PM | Scott Mitchell

A common metric authors and other interested folks use to ascertain the success of a book is to examine its Amazon.com sales rank. Brad Abrams took this idea and went a little further with it, ascertaining a book's popularity not only by its sales rank but also by the “buzz“ it had generated in the online world. Brad says that he determines the “buzz“ value through the Google API, although I'm not sure what the numbers correspond to. When putting in the book's title, I don't get nearly the same number of results as the “buzz,“ and I can't find the code Brad uses to determine the “buzz“ in his blog entry.

Regardless, Brad's approach is on the right track. My only concern is that the “buzz” rating might be a bit skewed based on the words in the title of the book itself. For example, the book Programming C# is probably more likely to result in false positives on Google (i.e., pages that use those words or that phrase that aren't talking about the book) than, say, Teach Yourself C# in 24 Hours.

You can check out Brad's results here:

Filed under:
An Example of the Evilness of Comment Spam
17 February 05 02:32 PM | Scott Mitchell

Here's just one example how comment spam is making the blogging world a crappier place (warning: clicking on the following link may cause your browser to jack your computer's CPU to 100% for several seconds): http://dotnetjunkies.com/WebLog/jonne%20kats/archive/2004/01/14/5589.aspx

This link is a blog entry from Jonne Kats asking the blog community if there exists an easy-to-use control for WYSIWYG editing in a WinForms application. I was in search of such a component earlier today and ran across this blog entry, but upon trying to visit the page, my CPU's utilization jumped up to 100% and my browser hung. After a couple seconds of waiting, I restarted my browser and tried again. This time I had more patience and, eventually, the page was rendered.

The reason it took so long to grab was because the page was over 3 MBs of HTML, with apparently hundreds of comments, as the little scroll bar was tiny, indicating that the vertical length of the page was huge. Upon scrolling through the entry, I found that there were about five “real” comments at the top. The rest - several MBs, I'd imagine - were nothing but comment spam. Ick.

Filed under:
An Extensive Examination of Data Structures - Updated for 2.0
17 February 05 08:37 AM | Scott Mitchell

Starting back in November 2003 I wrote a six-part article series for the C# section on MSDN Online titled, An Extensive Examination of Data Structures. This article series examined a number of the built-in data structures in the .NET Framework - arrays, the ArrayList, the Hashtable, the Queue, and the Stack - as well as the fundamentals and working examples of other common data structures - a binary search tree, a SkipList, a Graph, and a Set.

A few months ago I started retooling these articles for the .NET Framework version 2.0, and the six parts of the original article series have been updated and are now published on MSDN Online:

  • Part 1: An Introduction to Data Sturctures - this first part starts by looking at the fundamentals of data structures and then examines two of the most commonly used data structures - the array and the List (the List being a new data structure in 2.0 that is, essentially, a Generics version of the ArrayList). This article series also includes a discussion on what Generics are and their benefits.
    • New to the 2.0 Series - discussion on generics; discussion of the built-in List data structure.
  • Part 2: The Queue, Stack, and Hashtable - this second part starts with an examination of the Queue and Stacks, two data structures that allow for a collection of items to be stored, but place limits on the order with which items are added and removed. The second half of the article looks at the Hashtable and Dictionary objects, which provide a way to store items using key/value semantics.
    • New to the 2.0 Series - the generic versions of the Queue and Stack are used in the discussion; the Dictionary class, new to 2.0, is discussed.
  • Part 3: Binary Trees and BSTs - the third part of this article series is the first that looks at data structures not found in the .NET Framework BCL. Trees are discussed, and implementations of a binary tree class and a binary search tree class are provided.
    • New to the 2.0 Series - the binary tree and BST classes use Generics to allow for type-safe trees; used the yield syntax to provide iterators for the tree data.
  • Part 4: Building a Better Binary Search Tree - BSTs have some shortcomings in that the order with which the data was inserted into the tree can greatly affect its running time. To combat this phenomenon, computer scientists have created various data structures to circumvent the problem. One technique is to have the trees automatically self-balance on insert. Another technique is the SkipList, which maintains a pseudo-tree with randomly assigned heights following a particular distribution that affords the optimal big-O running time.
    • New to the 2.0 Series - the SkipList is now type-safe, thanks to Generics.
  • Part 5: From Trees to Graphs - graphs are a more generalized version of a tree. In this fifth part of the article series, the concepts of graphs are discussed and a Graph class is introduced.
    • New to the 2.0 Series - the Graph class uses Generics; the Graph class has been refactored into a better design.
  • Part 6: Efficiently Representing Sets - a set is a collection of unordered items, and is a construct that's commonly used in mathematics. There are a number of real-world computer science problems that need to be able to efficiently work with sets, yet there is no support for sets in the .NET Framework BCL. This sixth and final part of the article series examines a set class and provides a discussion on a particular set scenario: maintaining a collection of disjoint sets.

Filed under:
Some Free Advice for ISVs
15 February 05 11:10 PM | Scott Mitchell

Over the past couple of weeks I've had the opportunity to try out a number of third-party components for a variety of tasks (source control, bug databases, assorted Web controls for an ASP.NET site, and so on). The goal was to evaluate a number of different products and make purchasing decisions. This last week of experience hardly makes me an expert in this area, but here's some free advice to all ISVs, regardless:

Please, for the love of all that is sacred, make it as easy as possible for me to take your product and try it out.

Here are some things that make it hard for me to try out your product:

  • I have to create an account on your site in order to download a trial version.
  • I have to create some sort of temporary license key through your site before my trial version will work.
  • For third-party Web controls:
    • I have to muck around with Global.asax, copy over directories or support files, or basically have to do other things to try out the functionality on a sample site.
    • The example or quickstart application either is non-existent, requires some manual setup (like me creating a virtual directory), or lacks any English description or comments in the source code.
  • Lack of support forums/FAQs/Knowledgebase available on your website.

The company that I had the best “trial” experience with was, hands down, SourceGear. No need to create an account; no license keys needed. In fact, their products come with a free single-user license, and getting started was just as simple as downloading an MSI file.

For third-party ASP.NET controls, I understand such a licensing scheme might not be possible, but I would strongly recommend making it as easy as possible to try out your software. Perhaps a trial version could not require any sort of license - temporary or otherwise - but instead just periodically emit a copyright notice. Telerik, makers of a number of ASP.NET controls, gets close to this ideal - you can download a license-free version that periodically renders a copyright notice instead of the actual Web control. However, you still have to create an account to download the trial version and their documentation and on-site support material is lacking in many cases.

Filed under:
Review: The Joel On Software Book
07 February 05 02:54 PM | Scott Mitchell

I recently completed the thoroughly enjoyable and lengthily-named book Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity, a collection of writings from popular blogger, ex-Microsoftee, and entrepenuer Joel Spolsky. If you're familiar with his blog, Joel On Software, then you know that Joel posses a unique mix of technological know-how, business smarts, and an entertaining writing style.

Joel's book is a collection of his best blog entries, magazine articles, introductions he's authored for other books, and other such writings. Yes, most of the stuff in this book can be found online, but the printed page makes the material easier to read through; furthermore, the assorted writings are arranged according to topic (as opposed to chronologically), providing a nice segue between essays. Each of the 45 entries are fairly short, ranging from one printed page to a half dozen or so.

The book is arranged into four parts:

  1. Bits and Bytes: The Practice of Programming - this section was one of the most interesting for me, as a developer working in a company of one. This section has two really great essays:
    • Back to Basics - how wise is it to learn computer science (or any science) other than from the ground up? Yet many computer science programs in universities today take that exact approach, starting new students with a high-level programming language like Java. In this essay, Joel examines string semantics and shows how an ill-footed foundation can lead to a myriad of problems. (Joel is, by trade, a program manager, but he has clearly had a solid education in computer science and is able to communicate his ideas and some of the cornerstones of the discipline in crystal-clear prose.)
    • The Joel Test: 12 Steps to Better Code - Joel outlines 12 steps to check to see if your software team is creating quality code or not (of which I blogged about one - keeping a bug database - a few days prior). This particular essay doesn't delve into too great of detail for each of the 12 checkpoints, but many of the accompanying essays in this first section provide a deeper look at Joel's rational.
  2. Managing Developers - the essays in this section are great for those who manage a team of software developers. There are musings on interview techniques and reasons why incentives are counterproductive. The real highlight of this section, though, is found in the last handful of essays, which examines the Law of Leaky Abstractions. (Since I work for myself on a team of one, many of these essays didn't provide direct benefit to me, but what I found interesting was comparing the situations and scenarios presented by Joel and comparing them to past employers or my wife's current company.)
  3. Random Thoughts On Not-So-Random Topics - the highlight of this section was, hands down, the three essays titled Strategy Letter. (Here's a listing of these letters, including two additional ones, on Joel's blog; the book includes Letters I, II, and III.) Essentially, these letters provide high-level business advice. Strategy Letter I compares two polar growth strategies - Ben & Jerry's and Amazon.com's - discussing when growth is more important than money/profit/employee moral, and when the opposite is true.

    The second Strategy Letter examines a common marketing problem in technology: the Chicken and the Egg problem. Whenever a new platform is released - be it a computer operating system, a game console system, a new technology for storing/reading digital media, or something else along these lines - no one wants to buy the platform unless there is software support, but no software vendor is interested in developing for the system until there's a large enough consumer base. In this essay Joel examines this classic problem and looks at how Microsoft did it right with Windows, but messed up with their attempt at online bill paying.

    Strategy Letter III discusses the challenges of entering a marketplace as the new guy when there's already an entrenched competitor. Joel worked at Microsoft during the early 90s when Excel was facing an uphill battle against Lotus 1-2-3, which had the vast marketshare of spreadsheet programs. Joel's advise is to determine what barriers are preventing customers from using your product over your competitors, and working 110% to eliminate these barriers.
  4. A Little Bit Too Much Commentary on .NET - this was the weakest section of all. While it is titled, “A little bit too much commentary...“ I found it to be very little indeed. There are only three essays in this section, one which barely spans a page. Plus the first one is a tad outdated, as it was written in the summer of 2000, shortly after Microsoft came out with the Beta 1 of .NET, and focuses more on Microsoft's marketing spliel about .NET, rather than the technology itself. One area Joel did touch on in this section, though, was the power of ASP.NET, and how it's leaps and bounds better than classic ASP.

I found Joel's book to be one of the best reads I've had in a while. While the book comes in around 340 pages, I blew through it in under a week, reading a handful of essays while on the treadmill. (This book was a really great way to make exercise time go by a lot faster!) One concern I had when buying this book was that virtually 100% of it's content is available already from Joel's website. I thought I might kick myself later for buying the book seeing as I could just read it all online. In the end, though, the printed page worked out very well. Along with the fact that the book form allowed me to read it while exercising, I found the essays easier and quicker to read on paper than on the screen. Furthermore, the essays were arranged well. Additionally, there were a number of essays that are not available on Joel's site (magazine articles, introductions to books, etc.).

My main complaint against this book, though, is that the content is, pretty much, straight from Joel's site. Nothing wrong with that, as there are some great pieces on Joel's site, but I think Joel missed out on an opportunity to go back and update some of his past essays. One or two entries in the book seemed to have an added Postscript, but it would have been nice had he added additional content for the majority of the entries. I often found myself a little let down when a particularly good essay ended - I wish he had added more meat to these top-notch pieces for the book. Also, some of the entries date back to 2000, which make the essays that focus on a particular technology seem a triffle dated.

Despite these two complaints, though, I heartily recommend this book software developers, designers, and managers, and to those who, whether by good fortune or ill luck, work with them in some capacity!

Filed under:
Do You Have a Bug Database?
04 February 05 09:58 AM | Scott Mitchell

I picked up a copy of Joel Spolsky's most recent book, Joel on Software: And on Diverse and Occasionally Related Matters That Will Prove of Interest to Software Developers, Designers, and Managers, and to Those Who, Whether by Good Fortune or Ill Luck, Work with Them in Some Capacity - it's well worth the ~$17 and beats every other book when examining the cost per word in the title. I'll be posting a review of this book once I wrap up the last 100 pages or so, but for now I wanted to touch on one of the points that make up The Joel Test. The Joel Test contains a quick, 12-point checklist that one can use to evaluate their software team.

Checkpoint #4 is, Do you have a bug database? Regarding that checkpoint, here's what Joel has to say:

I don't care what you say. If you are developing code, even on a team of one, without an organized database listing all known bugs in the code, you are going to ship low quality code. Lots of programmers think they can hold the bug list in their heads. Nonsense. I can't remember more than two or three bugs at a time, and the next morning, or in the rush of shipping, they are forgotten. You absolutely have to keep track of bugs formally.

I am a software team of one, but, sadly, I don't use a bug database. In my defense, I employ another one of Joel's suggestions which helps mitigate the shipping of poor quality code: I fix bugs before writing new code. Development typically goes like this:

  1. Client says, “Here are a set of specs,“ and provides a due date.
  2. I map out my plan of attack and start implementing the features in that order. After completing a page, I run a number of simple tests and if I find any bugs, I fix them before moving on to the next item in the spec.
  3. After completing the specs, I return the work to the client. I receive the next batch of specs while the client does more thorough testing on the work submitted. If the more thorough testing reveals more bugs, the client returns a list of bugs and repro steps, and fixing those bugs preempts current work.

This approach works, but I do think there would be advantages to a more formal bug database (rather than just the Word document from the client with the list of bugs they found along with repro steps). Having a bug database would provide a more formal listing of bugs, repro steps, and so on, allowing me to look back at the history of the project's bugs in a much easier manner. A bug database would also afford me the luxury of finishing the new specs before returning back to the bugs in the previous steps, thereby saving a costly context switch between writing new code and fixing old code (although the longer I wait to tackle the bugs, the longer it will take to solve them).

I thought I'd turn to you, my blog readers, and ask for your advice on a bug database. What tools/software do you use? Any recommendations for bug tracking for a company of one? In the simplest form I could just use a simple spreadsheet. But are there advantages to using more targetted solutions, like BugZilla, even for a team of one?

What bug tracking tools do you use, and what has been your experience with them? Do you agree with Joel that it's imperative that bug databases be used by software teams of one?

The Worth(lessness) of CAPTCHAs
02 February 05 09:27 AM | Scott Mitchell

In a previous entry on stopping comment spam, I discussed a gaggle of techniques that can be used to fight the scourge of comment spam. The list offerred five techniques:

  1. Moderation
  2. Use of a CAPTCHA
  3. Banning certain substrings from the comments
  4. Munging URLs in comments to remove the impetus for comment spamming (rel=“nofollow“ being the latest iteration of this)
  5. Require authentication to post comments

After thinking about the topic of stopping comment spam in more detail, along with perusing the flood of blog entries around the Web discussing rel=“nofollow“ and other comment spam-stopping approaches, I want to prune the list and remove options #2 and #4. Don't get me wrong, CAPTCHAs and munging URLs are better options than doing nothing at all, but I think both provide a false sense of security.

Munging URLs Just Plain Doesn't Work at Stopping Spam
The thought behind munging URLs is that by removing the benefit of comment spam - having a comment spammer's URLs improve in PageRank on Google and other search engines - that comment spammers will collectively throw up their hands, sigh, and say, “All right, you win, we'll stop spamming in your blog.“ And for sane, rational folks, that would seem like a sensible reaction. But to a spammer, whose hearts are three sizes too small (and black, and festered), what's the cost of spamming? Virtually nil. So why bother stopping? From the spammer's point of view, in the best case, the blog being spammed doesn't use URL munging techniques; in the worst case, it does, but the links will still be viewed by people who visit the blog, even if the search engines don't spider them.

Consider email spam. Over the years ISPs have developed better filters, email clients, like Outlook, have provided Junk Email filters, tools like SpamBayes exist to use Bayesian filtering, tools like Cloudmark allow the task of identifying spam to be distributed across millions, and challenge/response systems succeed in annoying valid senders and resulting in lost messages from the non-technologically savvy. BUT, despite all of that, do you get more or less spam today than you did, say, five years ago? Exactly. (The graph to the right shows the percentage of spam as a share of global email. More than 80% of email received today is spam, up from 25% or so two years ago...)

For a good discussion on the utility of the rel=“nofollow“ hyperlink attribute, be sure to read: A Step Toward Solving Comment Spam?

You Know What? CAPTCHAs Don't Work Either
A CAPTCHA - short for Completely Automated Public Turing test to tell Computers and Humans Apart - is, as its name implies, a test that can be administered that a human can solve easily, but a computer cannot. Typically CAPTCHAs take advantage of the fact that the human brain is great at recognizing visual images and patterns, while a computer has a much harder time identifying objects in images. Tons of sites uses CAPTCHAs to stop automated computer programs from creating accounts, posting comments, and so on. For example, sites like Yahoo and Hotmail display a string of twisted text over a grainy background that you have to enter into a textbox in order to create your new email account.

CAPTCHAs, though, are becoming less useful as humans find more intelligent ways to write computer programs to solve these little puzzles that were designed to be solvable only by humans. For example, on www.CAPTCHA.net, the site indicates that:

Greg Mori and Jitendra Malik of the University of California at Berkeley have written a program that can solve ez-gimpy with accuracy 83%.... Thayananthan, Stenger, Torr, and Cipolla of the Cambridge vision group have written a program that can achieve 93% correct recognition rate..., and Malik and Mori have matched their accuracy. Their programs represent siginifcant advancements to the field of computer vision.

The latest CAPTCHA breaking programmer is Casey Chestnut, a smart, determined guy with, perhaps, a bit too much time on his hands. Recently Casey decided that he was going to write an AI program that would break CAPTCHAs on a particular blog site, and did so with alarming success. Casey's program is quite impressive and extensive, using a neural network to do character recognition... you can read about all the gory details over at this blog entry.. With his program, Casey observed around a 66% success rate at identifying the CAPTCHA, and posted over 90 comment spam emails on various blogs. An impressive amount of work obviously went into this project, so kudos to Casey. (There's also currently a follow-up FAQ on the CAPTCHA AI post available on the Casey's blog's homepage...)

So CAPTCHAs are pretty useless, but not just because computer programs can solve them with alarmingly high success rates. Imagine that such a CAPTCHA existed that a human could easily identify, but not even the most cleverly programmed computer application could solve. Spammers could still circumvent this CAPTCHA. How? Just have humans solve the CAPTCHA. This has been demonstrated in the past - a nefarious hacker needs to solve a CAPTCHA so he posts it on his porn site to some unsuspecting visitor and says, “Solve this CAPTCHA for me to view free porn!” The visitor obliges, providing the answer to the CAPTCHA, which the program then uses to complete some signup or comment spam process started momentarily ago.

The Best Way to Stop Comment Spam
The only real way to 100% guarantee a stop to comment spam is to do moderation of all comments. Of course that can be a lot of work for the blogger and can be frustrating for the commenter, whose comments might not appear for minutes, hours, days, weeks, or... ever. The second best approach is to have some sort of user account model and only allow authenticated users to post comments. (Similarly, a well maintained global blacklist of comment spam URLs would also be equivalent to requiring authentication; see this entry for more on blacklists.) This has the benefit that if someone does start comment spamming their account can be banned. The downsides here are two-fold:

  1. It requires that posters create some sort of account. Unless there's a global authentication store, like Passport, users will have accounts on various blog systems, which is less than ideal.
  2. Comment spam can still get through. Granted, it's less likely since the comment spammer has to expend more effort to create the account, and the effects of comment spam are amatorized over all those bloggers who use the same authentication store, but comment spam can still creep up, whereas with moderation it should never appear.

The main advantage of requiring authentication, though, is that it does not take much effort on the blogger's side. Their only responsibility is to notify the authentication store managers when some authenticated user has posted comment spam.

The best commenting experience I've seen is in blogs that have married these two concepts. They allow anyone - both anonymous and authenticated users - to post comments, but comments made by anonymous users require moderation.

Filed under:
Searching Your Blog Got a Whole Lot Easier
01 February 05 09:54 AM | Scott Mitchell

If you check out the ScottOnWriting.NET homepage you'll now find that in the upper-left hand corner there's a spiffy “Search” box. Go ahead, type a query in there... you'll be redirected to http://scottonwriting.net/Search.aspx?s=ScottOnWriting.NET&count=10&first=1&query=query, which will show you the results of your search.

The new search page - which you, too, can add to your site in a matter of minutes - is possible in large part thanks to Microsoft's new MSN Search. Today Microsoft unveiled their new “built from the ground up” search and one of the cool features it that the search results can be returned as RSS. (To try it out, go to the MSN Search page and enter a query; at the bottom of the Web page you'll find that little, friendly orange RSS button.) Once I found this, I realized adding search to ScottOnWriting.NET would be a cinch if MSN Search let me search for pages on a particular domain. Thankfully, you can search by a specific site by simply adding site:siteName syntax in the search query.

Creating a search engine for a local site, then, is as easy as having a page that requests the remote RSS file based on the query entered by a user, and displaying the resulting RSS in the page. With my free RssFeed control doing exactly this is a no-brainer, requiring just two lines of code. Therefore, the code and markup for the search page for ScottOnWriting.NET basically looks like:

Source Code
// Build up the request URL for the RSS data
string requestUrl = string.Format("
http://beta.search.msn.com/results.aspx?q={0}+site%3a{1}&format=rss&first={2}&count={3}", searchQuery, “http://ScottOnWriting.NET/“, startIndex, resultsPerPage);

// Bind the results to the RssFeed control
searchResults.DataSource = requestUrl;
searchResults.DataBind();

Markup
<skm:rssfeed width="80%" id="searchResults" runat="server" Font-Names="Verdana"
Font-Size="Medium" CellPadding="5" ShowHeader="False" GridLines="None">

<ItemTemplate>
<span class="title"><a href='<%# DataBinder.Eval(Container.DataItem, "Link") %>'><%# DataBinder.Eval(Container.DataItem, "Title") %></a></span><br />
<span class="desc"><%# HighlightSearchTerm(DataBinder.Eval(Container.DataItem, "Description").ToString()) %></span><br />
<span class="url"><%# DataBinder.Eval(Container.DataItem, "Link") %></span>
</ItemTemplate>

</skm:rssfeed>

Some example results can be seen here.

This is pretty cool, but there are some gotchas.

  1. The RSS feed doesn't provide any information if there's more results. There may be 15 results for the query DataGrid, but the RSS feed, by default, will only return the first 10. There's no way of knowing for sure if there are more results unless you grab another RSS feed, this time asking for records starting at 11. What complicates things is that if there are exactly 10 records, getting the RSS feed starting at 11 won't return nothing; rather it will re-return the first 10 records. Ick. My current solution is to just display a Next button if there are 10 records on the page... it's a hack, since it won't really do what is expected for queries that return a multiple of 10 records, but it's good enough.
  2. I don't know how legal all this is. If you look at the RSS feed's <copyright> tag it says:

    Copyright © 2005 Microsoft. All rights reserved. These XML results may not be used, reproduced or transmitted in any manner or for any purpose other than rendering MSN Search results within an RSS aggregator for your personal, non-commercial use. Any other use of these results requires express written permission from Microsoft Corporation. By accessing this web page or using these results in any manner whatsoever, you agree to be bound by the foregoing restrictions.

    I doubt MS is going to care too much if I use these results for my dinky little blog, but clearly they'd care if I was a company that used this approach to provide search on my Web site in lieu of buying Index Server or Google's searching server, or whatever.

Of course, MSN Search is not the first search engine to provide a programmatic means for accessing their results. Google offers the Google API, a set of Web services that can be used to run queries on Google. In fact, I've written an article on 4Guys on how to create a search engine with the Google API: Searching Google Using the Google Web Service. (And I will likely write up an article on using the MSN Search technique...) The downside of using the Google API is that users are limited to 1,000 queries per day and creating a page to work with the API takes a bit more heavy lifting than just bringing back RSS data and displaying it (although not much more).

A future blog entry, or 4Guys article, will delve into the MSN Search techniques I used to add search to ScottOnWriting.NET, but don't let that stop you from adding this feature to your site today. Armed with RssFeed you could do it without further information in a matter of minutes.

More Posts

Archives

My Books

  • Teach Yourself ASP.NET 4 in 24 Hours
  • Teach Yourself ASP.NET 3.5 in 24 Hours
  • Teach Yourself ASP.NET 2.0 in 24 Hours
  • ASP.NET Data Web Controls Kick Start
  • ASP.NET: Tips, Tutorials, and Code
  • Designing Active Server Pages
  • Teach Yourself Active Server Pages 3.0 in 21 Days

I am a Microsoft MVP for ASP.NET.

I am an ASPInsider.