March 6, 2007
@ 03:33 PM

The hottest story on Planet Intertwingly today is Rob Yates' blog post entitled Safe JSON which goes over a number of security issues one can face when exposing services using JSON. He goes ahead to describe the following approaches

Approach 1 - Plain JSON: Simply return JSON

Approach 2 - var assignment: Assign the JSON object to some variable that can then be accessed by the embedding application (not an approach used by Yahoo).

Approach 3 - function callback: When calling the JSON Web Service pass as a parameter a callback function.  The resulting JSON response passes the JSON object as a parameter to this callback function.

There are a number of good responses in the comments. The only thing I wanted to point out is that only Approach 1 can really be called using JSON. The other two are "accepting arbitrary code from a third party and executing it" which is such a ridiculously bad idea that we really need to stop talking about it in civilized company. It seems silly to point out specific security or privacy issues with using that approach when the entire concept of building Web services in that manner is fundamentally insecure and downright dangerous.

PS: It looks like Rob Sayre beat me to saying this. :)


Categories: Web Development

March 6, 2007
@ 03:11 PM

I've been thinking about AJAX a lot recently. Between reviewing a book on the subject, reading some of the comments coming out of the Adobe Engage event and chatting with some coworkers at dinner about WPF/E I've had a lot of food for thought.

I'll start with an excerpt from Ted Leung's post entitled Adobe wants to be the Microsoft of the Web

The problem as I see it
I think that a lot (but not all) apps will become RIA’s, and the base platform technology for RIA’s is very important. Too important to be controlled, or designed by any single party. The current vogue toolchain, AJAX, has this property. It also has the property of being a cross platform development nightmare. On the desktop, you commit yourself to a single cross platform library/technology, and then you spend the rest of your time wrestling with it. In AJAX, you have multiple browsers on each platform that you want to support. Not only that, you have multiple versions of each browser.
Enter Flash/Flex. Flash has a great cross platform story. One runtime, any platform. Penetration of the Flash Player is basically the same as penetration of browsers capable of supporting big AJAX apps. There are nice development tools. This is highly appealing.

What is not appealing is going back to a technology which is single sourced and controlled by a single vendor. If web applications liberated us from the domination of a single company on the desktop, why would we be eager to be dominated by a different company on the web?

Most people who've done significant AJAX development will admit that the development story is a mess. I personally don't mind the the Javascript language but I'm appalled that the most state of the art development process I've found is to use Emacs to edit my code, Firebug to debug in Firefox and attaching Visual Studio to the Internet Explorer processes to debug in IE. This seems like a joke when compared to developing Java apps in Eclipse or .NET applications in Visual Studio. Given how hypercompetitive the "Web 2.0" world is, I doubt that this state of affairs will last much longer. There is too much pressure on Web companies to improve their productivity and stand out in a world full of derivative YouTube/MySpace/Flickr knock offs. If one company finds a way to be more productive and/or build richer Web applications the rest of the industry will follow. This is pretty much what happened with Google and AJAX as well as with YouTube and Flash Video. Once those companies showed how much value they were getting from technologies which were once passe, everyone jumped on the bandwagon. This means that it is inevitable that Rich Internet Applications will eventually be built on a platform that provides a better development experience than AJAX does today. The only questions are how quickly will this happen and which technology will replace AJAX?

Ted Leung mentions two contenders for the throne; Flash/Flex and OpenLaszlo. I'll add a third entry to that list, Windows Presention Foundation/Everywhere (WPF/E). Before discussing what it will take for one of these contenders to displace AJAX, I should point out that being "open" has nothing to do with it. Openness is not a recipe for success when it comes to development platforms. According to TIOBE Java is the most popular programming language today and it was a proprietary language tightly controlled by Sun Microsystems. Before that, it was commonly stated that Visual Basic was the most popular programming language and it was a proprietary language controlled by Microsoft. I believe these count as existence proofs that a popular development platform can rise to the top while being controlled by a single vendor. 

So what will it take for an RIA platform to displace the popularity of AJAX besides being able to build richer user interfaces?

  1. Ubiquity: Over 95% of the Web users are using an AJAX capable browser. Any replacement for AJAX must have similar penetration or it's dead in the water. No one wants to turn away customers especialy when it's competitors aren't doing anything that stupid. 

  2. Debug Once, Run Anywhere: The biggest problem with AJAX is that it isn't a single development platform. Being able to write an application and debug it once instead of having a different debugging and runtime experience for Internet Explorer, Firefox and Safari is the killer productivity enhancer. Of course, there will always be differences between environments but if we can move to a world where RIA development is more like cross-platform Java development as opposed to cross-platform C++ development (yes, I know that's an oxymoron) then we all win.

  3. Continuoum of Development Tools: I don't need expensive development tools to become an AJAX developer, however if I feel that I need heavy duty tooling I can buy Visual Studio 2005 then download ASP.NET AJAX to get a fancy integrated development environment. Any platform that expects to replace AJAX  needs to have a continuoum with high quality, free & Open Source tools on one end and expensive, proprietary and "rich" tools at the other. The Java world with it's culture of Open Source tools like Eclipse, JBoss and Hibernate coexisting with overpriced tools from big vendors like IBM WebSphere and BEA WebLogic is the best example of this to date. That way the hackers are happy and the suits are happy as well. 

So far Adobe seems closer than anyone in getting the trifecta. In a year or two, things might look different.


Categories: Web Development

For the current release of RSS Bandit we decided to forego our homegrown solution for providing search over a user's subscribed feeds and go with Lucene.NET. The search capabilities are pretty cool but the provided APIs leave a lot to be desired. The  only major problem we encountered with Lucene.NET is that concurrency issues are commonplace. We decided to protect against this by having only one thread that modified the Lucene index since a lot of problems seemed to occur when multiple threads were trying to modify the search index.

This is where programming with Lucene.NET turns into a journey into the land of Daily WTF style proportions.

WTF #1: There are two classes used for modifying the Lucene index. This means you can't just create a singleton and protect access to it from multiple threads. Instead one must keep instances of two different types around and make sure if one instance is open the other is closed.

WTF #2: Although the classes are called IndexReader and IndexWriter, they are both used for editing the search index. There's a fricking Delete() method on a class named IndexReader.

Code Taken from Lucene Examples

public void  DeleteDocument(int docNum)
lock (directory)

void CreateIndexReader()
if (indexReader == null)
if (indexWriter != null)
indexWriter = null;

indexReader = IndexReader.Open(directory);

void AddDocument(Document doc)
lock (directory)

void CreateIndexWriter()
if (indexWriter == null)
if (indexReader != null)
indexReader = null;


As lame as this is, Lucene.NET is probably the best way to add desktop search capabilities to your .NET Framework application. I've heard they've created an IndexModifier class in newer versions of the API so some of this ugliness is hidden from application developers. How anyone thought it was OK to ship with this kind of API ugliness in the first place is beyond me.


Categories: Programming

Every once in a while someone asks me about software companies to work for in the Seattle area that aren't Microsoft, Amazon or Google. This is the first in a series of weekly posts about startups in the Seattle area that I often mention to people when they ask me this question.

The iLike service from is one of a new breed of "social" music services which is a category popularized by The service consists of two primary aspects

  1. A website where one can create a profile, add friends, view stats about the music you listen to and see what music is popular among iLike users.
  2. An iTunes plugin which recommends songs from signed and unsigned artists based on what you are listening to and also allows you to see what your friends are currently listening to.

I tried the service and definitely like the concept of getting music recommendations from directly within iTunes. The only downside is that you get samples of the recommended songs (probably the same snippets from the iTunes music store) instead of having the entire recommended song streamed to you. I guess that makes sense since it is a free service and likely makes money via an affiliate program. The company recently got a bunch of funding from Ticketmaster so I expect that they will soon start integrating concert ticket recommendations into their user experience which would explain why they require a zip code when signing up for the service.

The president of iLike is Hadi Partovi who recently left Microsoft for the second time after a stint as a General Manager at MSN where he greenlighted which eventually morphed into the personalized page. One of the key developers of iLike is Steve Rider who was the original developer of

Press: Seattle Times on iLike

Number of Employees: 25

Location: Seattle, WA (Capitol Hill)

Jobs:, current open positions are for a Web / Server (Ruby) engineer, Software Development Engineer in Test, Web/DHTML engineer, Database engineer, and desktop client engineer


Although this has taken much longer than I expected, the Jubilee release of RSS Bandit is now done and available for all. Besides the new features there are a number of performance improvements especially with regards to the responsiveness of the application.

Major differences between v1.5.0.10 and v1.3.0.42 below

This release is available in the following languages; English, German, Polish, French, Simplified Chinese, Russian, Brazilian Portuguese, Turkish, Dutch, Italian, Serbian and Bulgarian.

Download the installer from . A snapshot of the source code will be availabe later in the week as a source code release.

New Features Major Bug Fixes

Categories: RSS Bandit

March 2, 2007
@ 12:23 AM

I just got a phone call from an RSS Bandit user whose daily workflow had been derailed by a bug in the application. It seems that we were crashing with an ArgumentException stating "Argument already exists in collection" when she tried to import an OPML file. This seemed weird because I always make sure to check if a feed URL exists in the table of currently subscribed URIs before adding it. Looking at the code made me even more confused

f1.lastretrievedSpecified = true;
f1.lastretrieved = dta[count % dtaCount];
_feedsTable.Add(, f1); /* exception thrown here */

So I looked at the implementations of the ContainsKey() and Add() in my data structure which lead me to the conclusion that we need better unit tests

public virtual bool ContainsKey(String key) {			
  return (IndexOfKey(key) >= 0);

public virtual void Add(String key, feedsFeed value) {
	if ((object) key == null)
		throw new ArgumentNullException("key");

	/* convert the URI to a canonicalized absolute URI */ 
		Uri uri = new Uri(key); 
		key = uri.AbsoluteUri; = key; 
	}catch {}

	int index = IndexOfKey(key);

	if (index >= 0)
		throw new ArgumentException(
			"Argument already exists in collection.", "key");

	Insert(~index, key, value);

My apologies to any of our users who have been hit by this problem. It'll be fixed in the final release of Jubilee.


Categories: Programming | RSS Bandit

From the blog post entitled The i'm Initiative and new secret emoticon on the Windows Live Messenger team's blog we learn

Not everyone has the financial ability to give money to the causes they care about. That is where the i'm Initiative steps in - it enables Windows Live Messenger users to make a difference by directing a portion of Messenger's advertising revenue to a cause of their choosing.
Wonderful! How does it work?

  1. Use Messenger 8.1
  2. Add the i'm emoticon to your display name by entering the code of the cause you would like to support 
  3. Send and receive IMs
  4. A portion of the advertising revenue generated by your usage of Messenger will be donated to your cause. So the more IMs you send and receive the more money will be donated to your cause.
How does Messenger even generate revenue\money anyway?

Windows Live Messenger is a free service to users. We do include advertisements in the client that help pay for the service and our salaries. With the i'm Initiative you get to decide where a portion of the revenue goes.

The list of codes to create the emoticon are listed in the blog post. I'm using *9mil in my IM handle. This trend of tying charitable donations to the usage of Windows Live services is interesting. It's kinda cool for our users to feel like they are contributing to the betterment of the world simply by using our software the same way they have every day. Good stuff.


Categories: Windows Live

While I was house hunting a couple of weeks ago, I saw a house for sale that has a sign announcing that there was an "Open House" that weekend. I had no idea what an "Open House" was so I asked a real estate agent about it. I learned that during an "Open House", a real estate agent sits in an empty house that is for sale and literally has the door open so that people interested in the house can look around and ask questions about the house. The agent pointed out that with the existence of the Internet, this practice has now become outdated because people can get answers to most of their questions including pictures of the interior of houses for sale on real estate listing sites.

This got me to thinking about the Old Way vs. Net Way column that used to run in the Yahoo! Internet Life magazine back in the day. The column used to compare the "old" way of performing a task such as buying a birthday gift from a store with the "net" way of performing the same task on the Web.

We're now at the point in the Web's existence where some of the "old" ways to do things are now clearly obsolete in the same way it is now clear that the horse & buggy is obsolete thanks to the automobile. After looking at my own habits, I thought it would be interesting to put together a list of the top five industries that have been hurt the most by the Web. From my perspective they are

  1. Map Makers: Do you remember having to buy a map of your city so you could find your way to the address of a friend or coworker when you'd never visited the neighborhood? That sucked didn't it? When was the last time you did that versus using MapQuest or one of the other major mapping sites.

  2. Travel Agents: There used to be a time when if you wanted to get a good deal on a plane ticket, hotel stay or vacation package you had to call or visit some middle man who would then talk to the hotels and airlines for you. Thanks to sites like Expedia the end result may be the same but the process is a lot less cumbersome.

  3. Yellow Pages: When I can find businesses near me via sites like and then go to sites like Judy's Book or City Search to get reviews, the giant yellow page books that keep getting left at my apartment every year are nothing but giant doorstops.

  4. CD Stores: It's no accident that Tower Records is going out of business. Between Amazon and the iTunes Music Store you can get a wider selection of music, customer reviews and instant gratification. Retail stores can't touch that.

  5. Libraries: When I was a freshman in college I went to the library a lot. By the time I got to my senior year most of my research was exclusively done on the Web. Libraries may not be dead but their usefulness has significantly declined with the advent of the Web.

I feel like I missed something obvious with this list but it escapes me at the moment. I wonder how many more industries will be killed by the Internet when all is said and done. I suspect real estate agents and movie theaters will also go the way of the dodo within the next decade.

PS: I suspect I'm not the only one who finds the following excerpt from the The old way vs. the net way article hilarious

In its July issue, it compared two ways of keeping the dog well-fed. The Old Way involved checking with the local feed store and a Petco superstore to price out a 40-lb. bag of Nutra Adult Maintenance dog food. The effort involved four minutes of calling and a half-hour of shopping.

The Net Way involved electronically searching for pet supplies. The reporter found lots of sites for toys and dog beds, but no dog food. An electronic search specifically for dog food found a "cool Dog Food Comparison Chart" but no online purveyor of dog chow. Not even Petco's Web site offered a way to order and purchase online. The reporter surfed for 30 minutes, without any luck. Thus, the magazine declared the "old way" the winner and suggested that selling dog food online is a business waiting to be exploited.

Yeah, somebody needs to jump on that opportunity. :)


Categories: Technology

Today on the Facebook blog I spotted a post entitled FQL which contains the following excerpt

Two and a half months ago, a few of us were hanging out in the Facebook TV room, laying on the Fatboys and geeking out about how to move forward with the API for the Facebook Platform. We had a beta version that was fully functional, but we kept wishing that the interface were cleaner, more concise, and more consistent. Suddenly it occurred to me – this problem had been solved over 30 years earlier by database developers who came up with SQL – the Structured Query Language. What if we could use the same time-tested interface as the way for developers to access Facebook's data?
This isn't a simple problem – with millions of users and billions of friend connections, photos, tags, etc., Facebook's data doesn't exactly fit into your average database. And, even if it did, we still have to carefully apply all of those complicated privacy rules. Facebook Query Language would have to take those SQL-style queries from developers, figure out what data they're actually looking for, figure out if they're allowed to actually see the data, figure out where the data is stored, and then finally go and get the data to return back to the developer. I knew building FQL would be hard, but that's why I couldn't wait to do it.

This is one of those things I used to think was a great idea when I was on the XML team at Microsoft. Instead of exposing your data using APIs, why not expose your data as XML then allow people to perform XQuery operations over the data. In reality, this often isn't really feasible because you don't want people performing arbitrary queries over your data store that may request data too much data (SELECT * FROM blog_posts) or are expensive computationally.

Looking at the FQL developers guide it states that a typical queries look like

SELECT name, pic FROM user WHERE uid=211031 OR uid=4801660

SELECT name, affiliations FROM user
WHERE uid IN (SELECT uid2 FROM friend WHERE uid1=211031)
AND "Facebook" IN AND uid < 10

SELECT src, caption, 1+2*3/4, caption, 10*(20 + 1) FROM photo
WHERE pid IN (SELECT pid FROM photo_tag WHERE subject=211031) AND
pid IN (SELECT pid FROM photo_tag WHERE subject=204686) AND

and return results as XML. I've assumed that what is supported is a simple subset of SQL, perhaps written with Lex & Yacc or ANTLR but it still seems somewhat problematic to move away from the constrained interface of an API and provide access via a query language. It is definitely a lot cooler and more consistent to work with a query language than an API though. Later on when I have some free time, I'll see if I can deduce the grammer for FQL by trying out queries in the Facebook API test console. It looks like there goes one of my evenings this week.

Nice work.


February 27, 2007
@ 06:15 PM

With the hubbub now settling down down I decided to go back and try out Yahoo! Pipes. For a while, I've wanted a feed for articles by Chris Kelly over on Huffington Post so I decided to build that.  After a couple of false starts I created the feed which currently doesn't have any items because there aren't any posts by Chris Kelly in the Huffington Post feed.

Now that I've actually used the service I'm pretty surprised that anyone thinks that this is a service that non-geeks will use. Programming with flowcharts to process RSS feeds seems even geekier than having a Star Trek wedding which was my previous bar for geekiest thing ever.