The phrase "FBCDN image is not allowed in stream" does not have much meaning to most of the natural world, but to a developer integrating with Facebook features this phrase is a nightmare.  Over the past year we have been developing iPhone apps that will process images in unique ways.  We thought it would be interesting to allow users to share these images with their friends on Facebook, if they have any friends.  The normal procedure is a two part process.  First, a user would upload the image to their very own photo gallery hosted on their Facebook profile.  When that is successful the user could then choose to publish a message to their stream which would include a link to this recently uploaded image.  It was fast and it was fun.

About two weeks ago I noticed that some previously published feeds, and any new feeds, were missing the shared photo.  Immediately I thought there must be a problem with the code.  Let me take a look.  HMMMMMMM.  Everything looks good, but why is the image missing?  Wow, I don't have much time to continue debugging this.  Let me check Facebook Developer Documentation.  Nothing here about missing images.

On the 17th of June 2010 the shock was felt. I was testing a new iPhone app we are working on for in20years.com.  The Facebook integration was complete and I attempted to publish a message to my Facebook profile using a Facebook Photo Gallery image.  The process came to a halt and the dialog read, "FBCDN image is not allowed in stream ..... You can see this because you are one of the developers of the app."  Ouch.  I could indeed see this message and yet I have no idea what it means.  Endless Google searches return nothing.

With shifting priorities in schedule we decided to let this go for the weekend.  Monday morning was a bit more informative.  Facebook Developer Forums erupted in outrage that all existing apps ceased to work due to this error. The official word came through an RSS feed reading:

Serving Images in Stream Stories
Jun 18, 2010 3:21pm

We no longer allow stream stories to contain images that are hosted on the fbcdn.net domain. The images associated with these URLs aren't always optimized for stream stories and occasionally resulted in errors, leading to a poor user experience. Make sure your stream attachments don't reference images with this domain. You should host the images locally.

So what does this mean?  Well it depends on your point of view.  It means Facebook does not have enough consideration for current applications using images in the fbcdn.net domain to grace the developers with a warning of this new policy.  I was experiencing problems for weeks before this statement was released.  It means that developers cannot rely on any implementation of a Facebook API component to behave the way they expect on a day to day basis.  It means that developers must find a way to host their own images if they plan on placing them in a Facebook Stream.  It means we must react with Ninja-like reflexes.

MobilePipes grows up!

The MobilePipes team works hard on our product suite making sure that our customers are buying software that is top notch, bright and shiny, reliable, easy to use, stands the test of time, and, well you get the point!  We could assure all day long that our products meet this criteria but we took the extra steps to prove it. 

MobilePipes was officially certified by Microsoft this month as a certified product.  This means a lot for our marketing and sales material because we get to include the logo all over the place, but more importantly, it assures our customers that they are buying a quality product. 

For those familiar with the process we ensured that our code meets the Microsoft standard for .NET based Web Services, Managed Code, and Windows Server 2008 Hyper-V. 

If you read this blog, one recurring theme is clear for the reader, we love our development tools here at Syndicated Methods!  Javascript has come a long way in recent years, but I would argue that one place it falls short is in the Integrated Development Environment arena.   Yes, I know that Firefox has the Firebug extension, but for me that is more of a debugging environment.  I would much rather that that my IDE incorporates debugging and code quality tools at design time. 

Thanks to Douglas Crockford, we now have a Code Quality tool that targets all that bad Javascript that is out there.  Please read more on his website at www.jslint.com.  But, that only gets us about half way there.  I really want to know when something is wrong while I am writing code.  There is a solution for all of you .net developers.  CodePlex has a project available under the name of JSLint.VS.  Using this Visual Studio add in developers will get code quality feedback on their Javascript at compile time (sorry, no background compiler). 

{ Happy Coding }

** UPDATE [3/6/2009] - Note to self. use a product before you blog about it :).  JSLint itself is a useful tool.  After using it for about a day though I am finding that it is quite brutal on particular syntax.  Specifically around some of the requirements around global variables.  Furthermore, JSlint has major issues with the JQuery framework including the custom code that you write using JQuery.  This makes JSLint a bit of a useless feature for me as most of the Javascript code that I intend to write will be in a framework such as JQuery.  JSLint.vs is also a bit buggy and I started to experience major slow downs with my build.  This will kill my Continuous Integration process, always strive for fast builds, always!  I also didn't like some of the features whrere it adds reminders to fix things into your task list.  I would much rather these be treated as a warning or error much like the legacy compiler in VS.NET.  If anyone has better luck or thinks I am crazy feel free to comment.