Okay it’s not that bad but I lately I have had the opportunity to get back into working with Facebook in several projects over the past few months. The good thing is that I’ve been able to work in almost all the ways you can interact with Facebook. I have worked on an external site using Connect and the Graph API, a page tab and a canvas page.

The bad part of doing things this way is that they are all done in 3 totally different ways. Just when I feel I’m doing well with one, another will come up and throw me in another direction. Good thing with that is that I’m getting the experience to figure all 3 methods out. Just with client timelines, it makes it fun when the same end functionality has very different implementation and I don’t have the time to make it perfect.

I do plan on posting some of my findings because I’ve personally had a tough time finding all the information I need online. Hopefully I’ll get a break in the action soon so that I can share.

Two weeks ago Facebook released their own C# SDK for developers to use. I downloaded it right off the bat but noticed that it had a few holes in it but did give a clean way to call their new Graph API.

One of the most glaring issues was that it can’t authenticate fully. I looked all over Google for it and finally found out that it’s an issue with the cookie that Facebook itself writes. The first key in the cookie is access_token and that passes the token from Facebook that allows you to make calls on behalf of the logged in user. Well the cookie’s value itself is one big string wrapped inside of quotation marks so the key is “access_token rather than access_token. This caused some hairpulling on my part but now that it is coded for it, it is working like a charm.

So the code should read like this if you’re using C#:

GetFacebookCookieValue("\"access_token")

Hope that helps anyone who ran into that as I did.

I consider myself a decent programmer but I know that there is a ton more to learn and no one programmer will ever know everything as programming is evolving all the time. But occasionally, programmers come across a decision on how to program a certain site/job. As a C# developer, I always prefer to code in C# but does it make sense to not always do what you’re comfortable in?

For example, if I have a site that I need to create and server isn’t an issue, do I do it in what I’m good at with C# or do I try coding it in PHP?

I guess my question is “would you rather be better at one thing or pretty good at a few things?” What is better for you?

Last week I posted an entry about the new Facebook API that is due to be released sometime this summer. Well today, it was announced that Facebook is opening it up for all users to check out on July 16th. While this isn’t the official launch, it still seems pretty close seeing as how the API is really buggy currently and on the Developer Forums, a lot of the programmers haven’t starting converting their apps over yet.

There is no mention of the “official” launch date as of yet but they say in their post that “early next week, we’ll post more answers to FAQs and share the new policies around the new profile design.” That seems kind of bad since they are opening up the new platform to everyone to check out next week as well. I foresee a lot of people complaining that the apps they have installed don’t work. Of course they don’t, programmers are still working with the buggy API and trying to find their way around in a new, dark room.

I am one who is 100% in favor of the new look and feel that Facebook is releasing but personally I feel that they need to get the API working closer to 100% rather than 50% and have more documentation before they announce to the masses to “come check this out.” Luckily they aren’t requiring all apps to use the new API as of yet but hopefully it won’t come too soon.

As I’ve written previously, I have worked on a few Facebook applications. I’ve gotten quite familiar with the intricacies of Facebook and how things work using its API. It’s an interesting way of doing things if you ever get the chance to check it out.

Anyhow, I’ve been working for the past week or so on getting to know the new API and platform changes that Facebook should be releasing in the next month or so. While it seems that a lot of things will just work as is, there are a couple of main points that will need to be changed for any Facebook app written on the current platform.

The main change I feel is the way that the application publishes feeds. Previously, you would call the Feed.publishTemplatizedAction function. It is pretty basic and relatively easy to understand. With the new platform, this old call is being removed and to be replaced with a couple of API calls. With the old platform, you needed to register your templates, get a Template ID back from Facebook, and then use that to call your feeds whenever.

I had a lot of issues at first getting the syntax correct on how the data was passed to the feeds since there isn’t a lot of documentation on how they are supposed to look. Especially since Facebook changed the call Feed.registerTemplateBundle. But once I got the new changes implemented and the hang of it, publishing feeds stories finally worked as they once did.

The big change to the feed stories is that you are able to have 3 feed sizes. The default is the one-liner. Just like it sounds, one line of copy. Next are the short story and the full story. They are very similar with the exception that you actually register an array of short stories with each one having one less dynamic piece than the one before it. With full stories, you only register one but you can make it large. I’m not sure of the size difference between the short and full stories as I don’t think that has been decided as of yet. If so, let me know.

Those are really the only things that I have done with the new API as of yet. Seems really cool but also a lot of work to keep your old apps working seamlessly. First of all, each application that you have, you will have to run the Feed.registerTemplateBundle API function to get a template ID for your app to use exclusively. Secondly, you will have edit your API calls to now call the Feed.publishUserAction instead of the Feed.publishTemplatizedAction call being made previously. It’s not a “huge” change but still there are a few differences.

My idea for updating the apps that I have worked on was to just change the API code that we use on every project but I have seen that won’t work exactly as I had planned. Currently, I pass the entire feed story as a string into the API call but with the new way, I’m going to have to pass a JSON array because the story itself has already been registered along with the template ID. It’s not a big deal but it would be nice if Facebook made their API a little bit more backwards compatible. But I can see why they are doing it this way. Everything is changing and it would be hard to keep the old stuff working. I would like the ability to register templates like they do it currently through a form on the Facebook site. That way I wouldn’t have to create a page on each app just to get a number back and then remove that page. Seems like kind of a waste to me but it’s still early, maybe they’ll do that.

If you have worked with the new Facebook API, I would love to hear about your experiences and what you think about some of the pending changes. I’m excited to see what changes end up happening and where the platform goes.

So it’s been a while since I wrote but it’s partially because of stuff I’ve been doing with Facebook. That and I’m lazy. I’ve worked on teams that have released 3 applications and in the process of finishing 1 at work right now. Along with those, I’ve personally released 1 and have 2 that I have in the works. So lots of apps in my head right now.

The first app we did is called Finders Keepers. It is a really cool wishlist site where you can keep products on your Wishlist, send your friends items for their Wishlists or buy products. It was my first adventure into a real, fully functional, Facebook application. It was tough but it all came together thanks to a great team and I am proud to say that I worked on it. It is going through some major revisions so keep an eye out for those in the upcoming weeks.

The second app we did was for the Pontiac Game Changing Performance. We worked with ESPN for the College Football season and just last week released the new version for College Basketball just in time for March Madness. We implemented a really nice recruiting component for it that I think helps out with the social aspect that all applications strive to find.

The third application is one that hasn’t been fully released yet but I used the new Facebook JavaScript Client Library. Using this allows you to write applications that do not need to live within the Facebook site. Now any site that can use JavaScript can use it. Really nice and once more documentation shows up, it will get only better.

Personally, I released an RSS reader application last October while I was trying to learn just how the API worked. You can find it here. Simply put, the user adds the feed that they want, how many items, and there it is. Still has some issues with it I am finding but not too bad for a first time app I think. Add it and let me know what you think.

So pretty much since October, I have been working on Facebook apps. I’ve done some in ASP.NET C# and a couple in PHP. I gotta say that each has its pros but being a .NET guy, I had a bit of an easier time with those. But that’s the beauty with the Facebook apps. It doesn’t matter what your comfort level is. You can do it in any language it seems. Facebook releases theirs in PHP and Java but there are many APIs written in whatever language you want. At Terralever, we wrote our own API for the .NET framework and I find it really easy to work with.

So if you’re wanting to get into writing your own Facebook app, it’s really easy to get started. There is a lot of people out there to help now. So do what I did and build a dinky little app and go from there.

I’ve worked on quite a few projects in the time I’ve been in working in development. I’ve noticed a couple of similarities between all projects when a project is inherited from another group. Not too long after the developers get to look at it, something universally is always said by one or more members of the team. “This code sucks.”

I’ve said it myself before but I got to wonder if others do this. There are only a few reasons this could happen:

1. The previous code does suck
2. The new team has better ways of doing things over the previous team
3. The code doesn’t suck, but it’s just what is said when inheriting new code

Now I seriously doubt that most of the code out there sucks but it is a perception that most developers seem to have. Everyone has their own way of doing things and most times, one is not all that better than another; just different.

This is also caused by progress in my opinion. Something that might have seemed correct a few years ago is now seen as obsolete. Also over-thinking a project can cause this. I worked on a site a few years ago that was written using many PHP include files. That’s not such a bad idea but it was overdone because many of its includes had includes of their own and it was a really tough project to maintain. In my opinion, it was a good idea gone overboard.

Occasionally there will be a site that truly “sucks”. I was part of a team that inherited a site that was in dire straights. The code made no sense, the design wasn’t appealing at all and no one visited it. We were lucky enough that the client was aware of these things and we were allowed to start from scratch. Now I wonder if the people working on that site now think that it sucks. Probably

There are many different characteristics that programmers look for in “good” code. The issue is that these characteristics differ between groups of programmers and what is the bread and butter for one team will be nothing more than garbage and a hassle for another. Because programming is such a subjective art, not everyone will agree on the right way to do things because what is right for one person, might not be right for someone else. Everyone and every team has strong and weak points and the idea is to code using your strongest abilities. In turn, that will make your code better.

My goal when I come across new code is to not jump on it and say how horrible it is, but to rather spend some time looking at it and try to understand why certain things were done that way. If you are able to step outside your comfort zone and think of things a different way, you might learn something that you hadn’t thought of before.

So before you announce that the code you just inherited “sucks”, take a closer look at it and try to get into the mind of the previous programmer. If you still can’t make any sense of it, it’s because it probably sucks.