Home - Stay N Alive

Looking for a Facebook Internationalization WordPress Plugin

Posted on January 17, 2011 by jessestay

As I’m writing my book, I’ve come to realize that a good portion of you that visit here speak another language. In fact, Bahasa Indonesia (Indonesian), Facebook’s 2nd largest market (Indonesia, with over 200 million population), just so happens to have a high ranking in the readers of this blog as well, at least amongst those of you who are Facebook users.

There’s a little known fact about me that you may not know – I lived 3 years as a child in Indonesia, and, while I have forgotten much of my Bahasa Indonesia (as a kid, I could speak somewhat fluently), I do pick up some here and there and I thoroughly understand Indonesia’s culture and would love to have more of you Indonesian readers and visitors have a more comfortable experience on StayNAlive.com. I’ve wondered if it might be worth sending each blog post through Amazon’s Mechanical Turk, pick a few of the top languages visiting here (including Bahasa Indonesia), and see if I might be able to have multiple versions, in multiple languages integrated into this blog’s design. Then I had a better thought – Facebook has its own crowd-source Translation product, Facebook Internationalization. What if I just used that, and allowed you, my readers to translate this blog for your peers and the translation could happen in any language, natively. There’s one problem though – there’s not currently any WordPress plugins that do this yet.

So I’m giving the idea away for free. Facebook has a whole slew of documentation on how to integrate Facebook Translations into a website. I’ll also be including a chapter about how to do this in my book, which I have to focus on at the moment. Because of this, I don’t have the time to write one myself, but I’d love it if anyone felt compelled to build a Facebook Internationalization plugin for WordPress that others could use. If you write one, let me know, let me provide feedback, and I’ll integrate it into the design of this blog and give you as much attention as you need to promote the plugin. If you know of such a plugin, let me know!

Auto-load on scroll plugin?

I have one other request. I think it’s a waste of time to have to click to the bottom of a blog and click again to go through past posts from that blog. I want my blog to work like Twitter.com, where if I scroll down, it keeps scrolling, auto-loading additional content the further I scroll. Is there such a plugin? If not, why not? That’s another plugin I’d promote heavily were it to become available.

If no one jumps to the cause, I may just build these myself when I get some time, but I thought I’d throw it out there in case someone wants a fun project to work on. I think they’re both pretty forward-looking plugins that would see a lot of use.

How is Quora Able to Auto-Like Posts on Facebook?

Posted on January 10, 2011 by jessestay

I’ve been contemplating a way to get Facebook like buttons to work with a brand’s own look and feel, so when you like it on a 3rd party site, it automatically likes the same Page (via Open Graph Protocol) on Facebook. This would be a User Experience Designer’s dream come true, especially those that I work with in my day job trying to design stuff that works with Facebook. Today I remembered that there is a site that is doing just that: Quora. The problem is there is no API method that currently allows Facebook developers to send “likes” to URLs or Pages on Facebook.

Right now on Quora when you click “up” on any answer on Quora, if you’ve associated a Facebook account with your Quora account you have the option, in your settings, to also “like” the page for the answer on Facebook. Doing so shows a post in the news feed that says something like “so and so likes such and such an answer on Quora”, linking back to the answer on Quora. The likes, via Facebook’s Graph API also go up with that click. This auto-posting is probably also helping to contribute to Quora’s massive growth in such a short period of time.

I thought I’d try to hack it to see if I could figure out what Quora is doing. I’m pretty sure they’re getting special access by Facebook to do it. Right now when I send a “POST” method call to https://graph.facebook.com/likes, with http://pathtoanyurl.com in a “url” parameter (and a working, offline_mode, access token), I get a message back from Facebook that says, “App must be on whitelist”.

I’m assuming Quora is on a special whitelist for Facebook to be able to auto-like posts via Facebook’s API, something most developers on Facebook Platform aren’t allowed to do. This would make a lot of sense, considering Quora’s own founders were also some of the original founders of Facebook and most likely have very close ties with the service and its employees.

Now I just want to know, how can I get this whitelist access?

If you have a better answer, answer here, on Quora of course!

Howto: Getting the Logitech Revue (Google TV) to Work With Comcast Cable Boxes

Posted on December 28, 2010 by jessestay

As I’ve Tweeted, Facebooked, and Buzzed about recently, Google sent me a Logitech Revue Google TV unit shortly before Christmas which I will probably be using to write apps for. There are many things I like about it, many I don’t, but I’ll save that review (no pun intended) for another date. I did want to post briefly on an issue I came across that had me really frustrated, as there were no answers on the web.

The issue stems with Comcast Cable Boxes (mine was the HD PVR unit with HDMI out) not working well in receivers that have more than one HDMI cable input connected at a time. I have the Harman Kardon AVR-247 and when I would connect the Comcast Cable box to my Logitech Revue unit, I would get Content Protection errors each time (HDCP – Google it, with “Logitech Revue”). I tried every means of connecting, and no matter what I tried I couldn’t get it to display TV without the HDCP error, a big green message on top of the screen from the Comcast digital cable box.

I Googled it, and came across issue after issue of Comcast customers having similar problems with the Comcast Cable boxes, with no answers, and no response from Comcast (Many were complaining that Comcast was sending them back to Motorola, some saying Comcast was blaming Google, etc.). The only answer I came up with was that the AVR (your receiver) did not work well when it had more than one input in the box, something that was necessary in my situation because I also have an Xbox, an Apple TV, along with a Blu Ray DVD player. The Apple TV and Logitech Revue only have HDMI ports, while the others I prefer to connect via HDMI where possible. The only solution I found was to connect the output of the Logitech Revue unit out to the TV’s HDMI input port, and the Comcast Box into the Logitech Revue, then using the Optical out port of the Revue to connect to the Optical input of the receiver, giving me the sound I need (you may have to read that a few times to get it). My problem was that my TV is still pretty old (but can you argue with 65 inches???), and only has one input HDMI port, which is already being used by the receiver.

So I thought about it, and realized the problem was because I had 2 HDMI cables connected to the receiver. I also happened to have an HDMI hub, which I purchased from Best Buy for about $100, but is also available in various forms starting at around $30 or so on Amazon and elsewhere. I was using this already to power some of the other HDMI devices I was using. So I disconnected the second port completely, and put everything into the HDMI hub. Voila! It worked! No more content protection errors!

So if you’re seeing the HDCP Content Protection errors with your Cable box on the Logitech Revue, you may want to consider going out and purchasing an HDMI hub, get rid of all but one HDMI input into your receiver, and connect everything to your hub. I’m pretty sure this method will work for almost everyone. In the meantime, Comcast told me on Twitter that they are aware of the issue, and they’re working on a firmware fix to hopefully fix the issue on their Cable boxes. It’s good to know they are now recognizing the problem, although they can’t give any ETA on a fix.

It was actually this problem that convinced me to just go get rabbit ears – with a Google TV, an Xbox and Windows Media Center, and an Apple TV, do I really need cable TV any more? Assuming you do, well, here’s the answer.

Geeky: PHP Client Library That Works With the New Facebook Javascript SDK

Posted on March 22, 2010 by jessestay

Occasionally I write more geeky posts that I don’t expect all my readers to understand. I’m going to start prefacing those with “Geeky:” so you can know to ignore them in the future. This is obviously one of those, so if the title doesn’t make sense to you, I don’t blame you for skipping over it all.

I have started playing recently with Facebook’s new Open Source Javascript Client Libraries. It has actually been quite fun to work with, in that they separate all the code out in a manner that’s easy to access, read, and understand how it works. Also, if I ever choose, I can host the Javascript files themselves on my own servers and reduce that potential failure point were Facebook’s servers to go down. (granted, you’re still relying on the Facebook API for them to work fully) I can also contribute to the source in the event I feel something might work better (via my own Github fork).

One problem I’ve come across with the new libraries is that they have simplified the Javascript session cookies so that rather than 5 or 6 separate cookies all getting set and needing to be parsed on the client in order to identify the authorized user, only one cookie is set, and can be parsed using simple URI string parsing functions. This is actually a bonus in that there is less work to be done to authorize the user. However, it means any old server-side clients that parse those cookies the old way will also need to be modified. If you don’t modify your server-side client library to recognize the new cookies, your libraries will not be able to authenticate or authorize the user properly.

I needed a solution for the server side that worked well with the new format. The specific code I’m writing is in PHP so it made sense to go with Facebook’s default PHP libraries, and I created a version of facebook.php that worked with the new Javascript SDK. To set it up is simple – just take this file, unzip it, and replace the facebook.php in your default PHP Facebook client library install with the one you just unzipped.

Unfortunately, the file isn’t backwards compatible, so you will need to choose between either the new Open Source Javascript SDK or the old Facebook Javascript Client libraries. This is because if you use the new Javascript SDK when you log the user out it only deletes the new format of session cookie. Your PHP Client Libraries will set the old format if you don’t replace them with the version above.

There may still be a way to make all this backwards compatible, but for my purposes I haven’t had need to look into it. Also, I’ve only tested this for my own use-cases, so there may be bugs. Please send me a patch if you find any bugs and I’ll update my own version of the file. As soon as it’s possible hopefully we can get this into the Facebook version as well. I’m going to also update the Github Wiki for the new Javascript SDK so others can benefit.

Let me know if anything needs to be updated. You can download the zipped facebook.php file here.

Twitter Launches Facebook Connect Competitor, @Anywhere

Posted on March 15, 2010 by jessestay

I’ve long talked about the MVC model of the Building Block web. Data Repositories like Amazon Simple Storage, Facebook Data Store, Google Data, and others comprise the Model of this new platform. APIs like the Twitter API, the Facebook server-side APIs, or other REST-type APIs compose the Controllers of this web. Then you have the View – something pretty much only Facebook and OpenSocial/Google Friend Connect have covered thus far. The View enables developers to easily integrate and access code from a user’s Client, the web browser. Today Twitter added their entry to that game, @Anywhere.

@Anywhere strives to provide a solution for a huge weakness in the Twitter API Platform thus far. It provides an entire Javascript, Client-side platform for developers and website owners to integrate Twitter easily and simply right on top of their website, no server-side code involved. This is the missing link Twitter has needed to have a truly competitive solution against Facebook’s Connect platform.

Facebook Connect relies on Javascript to provide an immersive experience into the Facebook environment right on top of any website owner’s site. With a few lines of Javascript, and an HTML-like tag language called XFBML, website owners can pretty much copy and paste pieces of code in place and immediately have access to comments, become a fan boxes, post to their stream, and even more if you know a little Javascript as well. It’s unclear if Twitter will be releasing an XFBML competitor (I’d love to help Twitter test if this becomes the case – I wrote the book on Facebook’s FBML), but Twitter is clearly going up against Facebook Connect to provide similar type tools, and I think it’s a very smart move.

I mentioned earlier I was excited about the entry of Josh Elman as product manager at Twitter. I’m unclear if he had anything to do with this, but you can clearly see the Facebook influence in Twitter’s new API. With not only Josh, but several others from the Facebook team now working at Twitter, you can bet they’ve compared and contrasted how they could obtain some of the millions of Facebook developers out there. Making it as easy as possible is the smartest way to do this, and Twitter has already signed on several very big players in the Facebook Connect space, Huffington Post and Yahoo, to be launch partners in this effort.

In addition to those, the most significant partner that I think should not be ignored is Amazon. Amazon, IMO, is the holy grail in Social E-Commerce, and despite not having a Facebook Connect solution, they seem willing to integrate Twitter into their environment. Why they are choosing Twitter over Facebook is beyond me – maybe they have a Facebook deal in the works as well?

I’m very excited about this new announcement. Soon, it will be easy for any developer to very seamlessly, in a single, well-understood language (Javascript), integrate Facebook and Twitter all on a single website with little effort. As a developer, I’m drooling a bit over this. I can’t wait to start playing with it.

Facebook to Developers: "You Decide"

Posted on February 24, 2010 by jessestay

By the time I hit publish on this 5 other bigger blogs will have probably already covered this, but this deserves some praise. One reason I love the Facebook Platform is because they really seem to care about API developers. They do things the “right” way. For instance, they have a beta site where they always release new bug fixes and features before they go live on the site. They always release new API features in “sandbox mode” before going live with them. No other platform releases new features and updates in this manner! Just today they upped their game even more, giving developers full control over this process by letting developers decide when new API features go live.

The service gives developers a new “Migrations” option in their application settings, enabling them to choose when things go live. The first one of these they launched has to do with a bug they’ve fixed which formats empty JSON strings correctly. To enable the feature you just go to your “Migrations” section for your app, and select “on”, and now all empty JSON strings will be formatted in the correct manner. The power of all of this is that you get to decide when these features go live, but you can start trying them immediately!

Of course, all features will eventually go live, but what this shows is that Facebook is willing to keep developers aware of changes before they go live. Facebook won’t be launching features into the wild out of the blue like many of their competitors do quite regularly. Previously, changes would go live, and while they would often show on the beta site, developers had little notice and little time to test them before putting them into production. These changes would break many apps the minute they went into production.

IMO, this small feature changes the game for many other app platforms. NO OTHER major app platform does anything like this. Kudos to the Facebook platform team for continuing to change the game in regards to API development. Since the Facebook platform launched, they have always been ahead in changes like this. I can only hope other API platforms can follow suite in giving developers more control like this. No one likes their applications to break because of simple API changes.

Yahoo Launches SQL Interface to Twitter

Posted on February 9, 2010 by jessestay

Every time I switch to jQuery, Yahoo’s YUI libraries seem to keep luring me back. Just yesterday, Yahoo added one more tool to its arsenal of YQL libraries that actually makes the Twitter API intuitive, giving me another reason yet to switch back to yui, or at least consider using Yahoo a little more as I develop tools for the Social Web. The new YQL set of tables for Twitter enables any developer to use simple SQL-like queries to retrieve and post Twitter data.

For simple user queries, getting a user’s twitter profile data is as simple as something like “SELECT * FROM twitter.status WHERE id=’8036408424′;“. To insert data, you simply need to provide the oauth consumer key and secret, along with the user’s oauth tokens and you can do things like post new status updates for the user, all in Javascript! A subsequent call to post a user’s status would look like:

“INSERT INTO twitter.status (status, oauth_consumer_key, oauth_consumer_secret, oauth_token, oauth_token_secret)
VALUES (‘tweeting from yql!’, ‘@your_consumer_key’, ‘@your_consumer_secret’, ‘@your_access_token’, ‘@your_access_secret’);“

The cool thing about Yahoo’s YQL Twitter interface is I can also choose to only pull specific information out for the user. I’m not quite sure the benefit this gives you considering Yahoo is probably still retrieving the entire subset of data from Twitter (you can’t pull specific pieces of data out of specific objects in the Twitter API), but at least it’s possible, something I’ve been craving from the Twitter API for quite awhile. It is unclear if Yahoo is caching this data, and if so, it could provide some significant performance benefits, with Yahoo doing most of the work on their own backend.

Yahoo’s YQL puts them one level above Facebook’s own FQL query language for accessing Facebook data by enabling developers to not only access data like this for Twitter, but also other environments like Facebook as well. Yahoo has an entire database of “community tables”, where, if specific APIs aren’t provided, the community can create their own tables to that interface and give developers immediate access to those APIs via a simple, standardized SQL interface to those platforms.

This type of API is exactly what I was looking for from the likes of Google’s Friend Connect APIs (and Google has still failed to provide) – a standardized platform where one single API gives me access to all the different APIs out there. Now with standardized SQL I can access almost any API, and if that API doesn’t exist yet I can create my own interfaces into each API that, once created will also have access via that SQL interface.

Yahoo now has my attention with this launch. The API has a web interface, where a call as simple HTTP GET to http://query.yahooapis.com/v1/public/yql?[query_params] returns an entire structure of XML data my application can access. They provide a YUI Javascript interface into the table structure so you don’t need a backend if you don’t want one, and I get all this for all the APIs I interface with.

I will now be looking into the Yahoo APIs as I look to interface the limitless APIs available out there thanks to Yahoo’s focus on cross-platform integration of their YQL interface. I like that Yahoo isn’t being selfish with this. With YQL, Yahoo has finally created a glue that lets me access all the APIs I need to access as a Building Block Web brick builder.

Twitter Testing "OAuth Delegation" With Select Partners – Genius

Posted on February 5, 2010 by jessestay

A common complaint amongst Twitter developers has been that Twitter’s OAuth, the authentication process you see when you click the Twitter login button on a 3rd party website and go to a Twitter-looking page with a “Allow” or “Deny” button, is too complicated. Mainly, from a user experience perspective, users are required to leave the 3rd party site completely in order to log into Twitter, then get redirected back to the 3rd party site again. If anything breaks along the way, the user is left wondering what to do, and valuable logins, purchases, or registrations could be lost. Facebook has solved this by enabling users to do all the login process via Javascript they provide that produces a popup. Users can log into Facebook without ever leaving the 3rd party site. It appears, based on a thread on the Twitter developers list, that Twitter is planning to one-up Facebook by allowing users to log in to 3rd party sites without ever even needing a popup or any type of redirect, and they’re already testing it with select partners.

The topic came up when other developers noticed that the site, TwitPic.com, was allowing direct Twitter logins right on their own website and somehow posts from TwitPic were showing up with the TwitPic name and link next to the post on Twitter. This normally isn’t possible without enabling OAuth login because Twitter has disabled the functionality for any non-OAuth produced Tweet. In fact they have said in June of 2010 they will be completely removing the ability to login through Twitter on 3rd party sites via plain-text authentication. So how is TwitPic doing it?

According to Raffi, an Engineer on the Twitter API platform team, Twitter is currently working on a new “OAuth Delegation” standard that will allow applications to allow users to log in via Twitter on their own sites, while still maintaining the control over Apps that OAuth gives providers and users. So, on TwitPic, for instance, you can log in to TwitPic.com with your own Twitter username and password right on the TwitPic site itself, yet you’ll still have full control on Twitter.com to revoke access to TwitPic at any time you want to. In addition, Twitter, at any time, can remove TwitPic’s ability to publish or access the Twitter API since they still have to use OAuth to make Twitter API calls.

If the hints in the developers list thread prove true, developers will be able to take the plaintext username and password, still store them somewhere, but in order to make calls through the Twitter API they’ll have to somehow send an OAuth key with their requests to Twitter along with some way of identifying the user. My guess is, in essence, the app will send a one-time login on behalf of the user to Twitter (most likely via a secure SSL encryption channel or similar), and Twitter will return to the app an OAuth token to make API requests with on behalf of that user in the future. In my opinion, this is still no different than storing an OAuth Token in a database that would give apps the same access as their Twitter username and password.

Security Concerns

While storage may be no different, I’m sure there will still be those concerned about this approach. For instance, what happens when users get used to entering their Twitter usernames and passwords on 3rd party websites and decide to do so on a malicious website? We’ve seen how used to entering Twitter credentials people get with websites that look like Twitter itself with the rampant phishing attacks recently.

Maybe Twitter is feeling comfortable enough that they can be proactive about such misuses and password collection. The risk is still there though and hopefully the OAuth Delegation Twitter is getting ready to launch will cover this problem.

Partners

Thus far, it seems TwitPic is one of the partners testing this new delegation standard Twitter is working on. Several others were mentioned in the developer discussions about this as well. For instance, Seesmic Look is also taking similar credentials without any OAuth redirect, yet still shows the “Look” source in Tweets generated with the app. One developer pointed out the information that could be retrieved from the new requests, and the security of it all is a little concerning.

Whatever it ends up being, the winners will be desktop and mobile client developers. Right now developing a mobile or desktop app involves deep integration into the browser in order to legally get the user logged into the app. It is why we see so few native desktop clients and so many AIR apps. AIR is a browser-based solution.

I’m very interested to see what happens. The Twitter team is supposed to announce more details very soon and I’d like to find out more about what this means for developers, how secure it is, and how much recoding I’ll have to do to enable it in my app. Whatever it is, you can bet it will be one step simpler than the currently more-simple solution which Facebook provides. This is getting very interesting! Let the API wars begin…

Just in Time for the Holidays, FriendFeed Becomes First OAuth Wrap Provider

Posted on December 17, 2009 by jessestay

About a month ago, Facebook’s David Recordon announced that Facebook was hard at work with the Open Standards Communities on a new OAuth protocol called Wrap. The goals of the protocol seem to specifically provide a way to direct a user through the authentication process through a client-only model, removing the need for developers to do heavy server-side code to authenticate the user. Such a model fits well for Facebook, who, through Facebook Connect, has fought to make it as easy as possible to enable developers to authenticate users via simple Javascript and HTML. It seems Facebook is making through with its promises, by launching FriendFeed as the first OAuth Wrap provider to launch with the new protocol.

The launch comes as a test of a discussion that took place at an OAuth Wrap Community meeting at Facebook headquarters last Tuesday, where it was discussed how to enable client-only authorization of users. In response, Bret Taylor and the FriendFeed team (I guess, according to Luke Shepard, that means there’s still a team?) produced a working prototype of the model, enabling it on their own site. Benjamin Golub, who was responsible for FriendFeed’s API before it was acquired by Facebook, confirmed this with the comment, “FriendFeed supports OAuth WRAP now :). Great job Bret, Luke, and David!” on FriendFeed.

It’s still unclear if this API is available to developers yet, or if it was only a proof-of-concept, but it is clear FriendFeed is very likely becoming a playground for the Facebook team to try out new technologies. This is promising in that if this continues, FriendFeed should continue to see cool new technologies applied to it way before, and even if, they even the light of day on Facebook.com.

I’m very excited to see the Facebook team pushing these new open, client-side APIs, but even more excited to see the FriendFeed team still cranking out cool new technologies, making this the second one today for the site. It’s becoming apparent that the FriendFeed team is finally becoming accustomed to Facebook’s internal technologies and architecture, and my hope is that we will soon to see many “beautiful butterflies” come out of what they’ve been working on over the last few months.

Now, if anyone knows how we can try this thing out I’m all ears!

UPDATE: Benjamin Golub has granted my wishes! He says in the comments: “You can try it out yourself! Register an application at http://friendfeed.com/api/register and then follow along with http://github.com/finiteloop/friendfeed-wrap-example/blob/master/friendfeedwrap.py” – hmmm…new SocialToo feature?

Facebook Posts New Dashboard API Methods, Prepares New Interface

Posted on December 5, 2009 by jessestay

Early today Facebook posted a series of new API methods to their Developer Wiki enabling developers to post updates to what was previously called the “Application Navigation”, but what would now appear to be called “the Dashboard”. The Dashboard API aims to provide an easier interface for users to find updates to their favorite apps without cluttering the stream. At the same time, the Dashboard API tries to encourage more users to bookmark applications and provide applications on Facebook Platform another means of sharing information with their users.

The Dashboard, which will appear on the left-hand navigation either in place of or near the Friend Lists, should launch to users in the next week or two according to a vision statement posted by Mark Zuckerberg recently and the current developer roadmap. When launched, users will be able to bookmark their favorite applications on Facebook or on their favorite Facebook Connect-enabled site and those applications will appear in the left-navigation in the new Dashboard. Applications can then send updates, incrementing a counter when new updates are posted, enabling users to know when new updates are available from their favorite applications. When the user clicks on each application they are taken to a page with the updates.

In addition to traditional applications, according to the new developer documentation there will be a games category in the dashboard. If applications have categorized themselves as a game in the Facebook App directory, their app will appear underneath the Games category. This category appears to try and make it easier for users to manage all their games under one easy navigation so they can focus on the more productive apps beyond just gaming. Other applications appear under an Applications category, and there is also a “Friends’ Games” and “Friends’ Applications” category enabling users to view applications and games their friends are using, I assume.

The new Dashboard API enables developers to do all the things mentioned above, and comes alongside the 6 month developer roadmap announced earlier by Facebook. The roadmap comes with mixed criticism from developers, with some excited for new integration opportunities and better organization, while other developers mad at the removal of some features in the planned changes. One developer I talked to today was frustrated with the frequent changes Facebook makes on the Facebook.com site itself, opting to begin moving his development efforts more over to Facebook Connect where he has more control. I believe that is exactly where Facebook wants him.

The new Dashboard API should provide new opportunities for developers to update their users and easily notify users of changes within their apps. The API, according to the documentation, is available for development and testing now. According to the documentation there is no sandbox for the new API, but developers can start testing these methods on their own servers. It is unclear how developers will be able to begin testing the UI for the new methods.