Aaron's Thoughts

Part of the reason I choose C# for larger web projects, and a big reason I point to when people ask me about my tech preferences is the nice, clean, managed strongly-typed objects. "I want to know if I'm using my variables correctly at compile time, not after users start getting errors". Is this short sided of me? Am I being a code-purist, or prude?

About 6 months ago I started to let my guard down. There was a really great article written by Alexandra Rusina in the February 2011 issue of MSDN that gives you the C# skinny on var, dynamic, and object:

Understanding the Dynamic Keyword in C# http://msdn.microsoft.com/en-us/magazine/gg598922.aspx

Having read that, I get the difference, but why do I want to dance around without the fences? Why treat the standard int the same I would a string / value pair? It's chaos. It's all "var", it's groovy, right? No. What is this, PHP?

My "ah ha" moment was a couple weeks ago at the Mix11 conference in Las Vegas. I do a lot of Facebook development, and a lot of pulling my hair out because of the world of pain that is Facebook development. With facebook, you can get at user data using their old REST apis, their FQL queries, FQL multi-queries, and now their Graph APIs (and GraphAPIs with queries). The strongly typed control freak in me was declaring objects like "FriendLinks", "Friend", "FamilyConnection", "PhotoTag", etc. It got out of control. At Mix, I was really eager to hear from the creator of one of the C# libraries for Facebook, Jim Zimmerman about the status of his library, Facebook C# SDK. If you do Facebook development I highly recommend watching his talk in its entirety: http://channel9.msdn.com/Events/MIX/MIX11/OPN06 

What struck me the most of Jim's talk is that Jim feels my pain. For as much as Facebook can give a developer, they hide it in cracks and corners of their API. Sometimes you have to call their Graph API, get a result, then call an FQL query. Sometimes the result changes with new data because they've introduced a new feature. Deprecation of older APIs is quick. It's a very dynamic API. Which is exactly what led Jim to create the SDK the way he did. "I'm not writing a wrapper API around Facebook", he says with absolute conviction. I don't blame him. Instead, this SDK gives developers the tools we need.

I decided to give it a whirl. Here's the easy one, the Graph API for getting "me" (this user):

var client = new FacebookWebClient();

dynamic me = client.Get("me");
ViewBag.Name = me.name;
ViewBag.Id = me.id;

Nice! Now, no matter what Facebook adds to the "user" object, I can take advantage of it. if they added a profile property favorite_candy, it's just me.favorite_candy, and I've got it implemented. OK, but I might not mind adding a property to a Facebook.User object. So this is kinda cool, but I'm not totally sold.

Next, I'm going to commit to start poking around at some of the FQL (Facebook Query Language) tables I can query: http://developers.facebook.com/docs/reference/fql/, specifically, I want to query for all the photos I am tagged in from the photo_tag table: http://developers.facebook.com/docs/reference/fql/photo_tag/

var query0 = "SELECT pid FROM photo_tag WHERE subject=me()"; //photos I am tagged in

try
{
    var result = (IList<object>)client.Query(query0);
}
catch (FacebookApiException ex)
{
    throw;
}

Here's the data just back from Facebook's servers (I'm tagged in 356 photos):

Nice! So, I can make up queries and get back dynamic objects. OK, so that's cool, but even these smaller name/value pair type queries STILL hadn't sold me on ditching my safe zone of inteli-sense warm fuziness. Here's the clincher. I want all friends who are tagged with me in photos, and which photo we were tagged, as well as when that tag happened. Yes, you read that correctly. This scenario gave me pause and excitement. I don't want a strongly typed object anymore. Also, I need an FQL Multi-query to make this happen, starting with the query above where I select the photo ids of all the photos I am in. Here's that using the C# SDK:

var query0 = "SELECT pid FROM photo_tag WHERE subject=me()"; //photos tagged in
var query1 = "SELECT pid,subject,created,text FROM photo_tag WHERE pid IN (SELECT pid FROM #query0)"; //friends tagged in photos with me
try
{
    var result = (IList<object>)client.Query(query0, query1); //multi-query

    var resultPhotosUserIn = ((IDictionary<string,object>)result[0])["fql_result_set"];
    var resultTagsOfPeopleInPhotos = ((IDictionary<string,object>)result[1])["fql_result_set"];
}
catch (FacebookApiException ex){
     // Note: make sure to handle this exception.
     throw;
}

And here's my new frankenstein object. What's nice is if I didn't qet the FQL query right, or those data fields returned data differently than I expected, I can preview it in the debugger.

This makes a lot of sense now. If you're doing a lot of interesting Facebook queries, dynamic variables are your friends. Jim's approach also makes sense. As the Facebook API changes, he doesn't have to rush to his computer to update wrapper classes that we all have to wait to download.

Oh, and to sweeten the deal, this Facebook C# SDK is available as a NuGet package. Check out the install guides. Using NuGet you can have all this magic in your project in 5 minutes. 

In a previous post I walked through some of the new features Facebook has launched for us third-party websites. In a nutshell, facebook users can share their friends' information. That means under normal privacy permissions, your friends can share your likes, your posts, your birthday, etc to third party sites. The example is the birthday card site, it needs to know all of a user's friends' birthdays in order to send them all cards on the right day.

When facebook launched "Places", I was curious, so I dugg in a big and sure enough, the same thing exists. Friends can share the check-in locations that their friends have posted. If you don't want this functionality, find this screen:

Go to "Account" -> "Privacy Settings"

At the bottom of the page is a section called "Applications and Websites" click "Edit Settings".

Next, find the section called "Info accessible through friends". This is the information you grant friends to share with third party sites. You might want some of these, like, you may not get a birthday card if you don't share your birthday. Choose wisely though, if you use "Places" and you check in to places you'd rather nor broadcast (why are you putting them on facebook anyways?) you should uncheck this box.

Yesterday Facebook launched a whole bunch of new tools for web developers with the idea being that outside sites can taylor better to you, the user, with more information about you. Indeed, this has always been the idea; a website could look different, suggest different things, and show you what your friends have been up to on the site. To do this, facebook gives developers simple things that show up if you are already signed in to facebook: the "like" button, comments boxes, and list of friends who liked or commented on that site.

Beyond that, we, the web developers, have to ask you to log in with those blue facebook buttons. When we set up that login feature, we get to decide how much from your facebook account you are authorizing us to see.

SO... read VERY carefully these kinds of dialog boxes, they tell you what the developer has requested access to:

Great, so YOU know to be careful... but do your friends? That's not a trivial question, because with that same "Allow" button above users can approve third party sites to access the profile, photos, statuses, comments, likes, friends, groups, notes of all their friends! In fact, here is the full list, see the column called "Friends permissions": http://developers.facebook.com/docs/authentication/permissions

As a result, everyone you are currently friends with have a lot of power to share YOUR information with websites outside facebook -- a little scary if you ask me.

I encourage everyone to review the following new privacy permissions by following these instructions:

1) Log in to Facebook and go to "Account", then "Privacy Settings"

2) Click on "Applications and Websites"

3) Find the section "What your friends can share about you" and click the "Edit Settings" button.

4) On this screen you should decide what your friends can share about you to third party sites. THINK ABOUT THIS CAREFULLY.

Ultimately, you are the owner of your content so be careful what you post about yourself. Third party websites can store your data once they have it, so deleting stuff you don't want about you on facebook doesn't delete it from existence.

Keep in mind, this is new, so we have to see how things go. The notion that a website can personalize to you means that it needs some info. AND, facebook is leading the way towards a single sign on for all sites so that you don't have to recycle those 3 passwords all over the web which is a big security issue. My two cents though is that these particular privacy settings are too burried for how important they are.