Partnership Opportunities

For those of you who follow this blog, it may seem like we haven’t been too active for a while. Let me assure you that this is very far from the truth – in fact we’ve been very busy lately. We’re now ready to give you a small peek behind the curtain to let you know what we’ve been up to.

When we originally conceived of FriendRunner we imagined that it would be an all-in-one tool that customers could use to load test their Facebook applications. That’s what we built, and so far it’s worked out fairly well. However, we’re beginning to realize that there are some things we could be doing better:

• FriendRunner duplicates functionality that exists in other tools

FriendRunner needs to do things like record and edit test scripts, graph timing results, and lots of other things that standard load testing tools already do (and frankly do very well). Duplicating this effort in FriendRunner takes our attention away from providing more features on the Facebook-centric aspects that really add value.

• FriendRunner customers need to learn yet another tool

People who want to load test Facebook applications don’t spontaneously appear – they typically have experience load testing other web applications and have experience with other load testing tools. Forcing these people to read new documentation and learn how to use a new user interface seems like a waste of their time. Since they’re already experts in other tools, it would be better if we allowed them to use FriendRunner through them.

• People are very clever and come up with usage scenarios for FriendRunner that we never imagined

We occasionally come across potential customers who want to do things with FriendRunner that it was never really designed to do. Instead of saying “No, No, No, you’re using it wrong!!” we’d much rather embrace those people’s resourcefulness and provide them with a great solution.

All of this points to the fact that we’d be much better off by modularizing FriendRunner, and allowing other tools to do part of the work where appropriate. And that’s what we’ve been working on,  so now FriendRunner can be easily integrated with other load testing tools to allow them to test Facebook applications. This opens up a world of possibilities for others to partner with us to provide load testing services for Facebook applications.

Load Testing Tool Vendors

This one’s pretty obvious. Standard load testing tools can’t really deal with Facebook applications, but they can now thanks to FriendRunner. There are several ways of integrating FriendRunner with another tool ranging from the really simple to the highly integrated (which is still pretty easy to do). Vendors of these tools that would like to learn more about how to do this should look here.

Load Testing QA Consultants

Consultants that perform QA services for other companies can expand their offerings by using FriendRunner. Since FriendRunner can work with existing load testing tools, the learning curve is very small and they can be offering services in no time. QA consultants that would like to learn more about this should look here.

Digital Media Agencies

Agencies and contractors who build Facebook applications for brands and companies can use Friendrunner as an additional premium service to offer to their customers. To learn more about how you can benefit while offering your customers more services, have a look here.

The Facebook Graph API

The new Facebook Graph API announced at f8 represents a revolution in the way that Facebook applications will be developed from here on in. You want to get a list of a users’ friends? No longer will you need to weed through the PHP documentation to try to figure out which API to call, and which parameters to pass. Now, all you need to do is make a simple RESTful HTTP call, and get a nicely formatted JSON response in return. How do you format the REST call? Pretty simple, I’m guessing that after you do 2 or 3 of these it will become second nature, and you won’t even need to look at the documentation.

So how will this affect FriendRunner? My initial thoughts is that it will affect FriendRunner in a positive way. All of the original API will still be in force, so nothing there will change. What will change it that FriendRunner will need to support all of the REST API calls at https://graph.facebook.com. But that won’t be so hard because it’s simply getting at the same data that we already provide, just in a different way. But even if it is hard, that’s okay – we subscribe to the “Why does Rice play Texas” philosophy.

Since the RESTful API is language agnostic, the FriendRunner support can be written any way we want, and not necessarily in PHP. This makes us very happy.

Stay tuned to get more information about when we’ll have the new API coded up and ready. In the meantime, all of the investment you’ve made in wriing Facebook apps the old way is secure, and your apps will continue to work. And FriendRunner will continue to be available for testing them.

Redirecting requests to Facebook during testing

In the interest of bringing you the best product possible, we sometimes need to delve into some hairy technical issues. With that in mind, we apologize for the hairy technical issue we’re about to discuss. If you gut it out to the end, there’s a question to answer because we value your opinion.

When load test a Facebook application with FriendRunner, we need to support everything that can happen while running an app. Almost all apps make API calls into the Facebook server to get information about a user and his friends, publish info to a user’s stream, etc. During testing, these calls cannot be sent to Facebook: they must be sent to the FriendRunner server that’s acting as the Facebook server. This is a bit tricky since the application will make these calls to the facebook.com domain, and since we don’t want to force developers to modify their applications, we need to play games with DNS to redirect the calls to us.

Historically, we’ve asked developers to simply modify the /etc/hosts files on their servers running the app to be tested, and point several DNS names (e.g. www.facebook.com, api.facebook.com, etc.) to an IP address we control. No one has ever had a problem with this, it’s temporary, and aside from a short inconvenience it works great.

Today during a technical discussion, we came up with a much better solution to this redirection problem. Instead of changing the HOSTS file, you would modify /etc/resolv.conf  to point to a DNS server that we control. This DNS server would map the facebook.com domains to our servers, and do nothing else. You’d select our DNS server as primary, and whatever you use now as secondary. Of course this change would only happen on the test server, so your employees could still get to their Facebook accounts and not start a revolt.

The reason for this change is that it would make the FriendRunner infrastructure easier to manage and more robust. We thought about whether the change would cause any performance/security/management problems, and frankly we can’t find any downside to it. However, before we make a change like this, we wanted to ask you, our customers and users, whether you’d have a problem with using our DNS server for testing instead of just updating your HOSTS file.

So what do you think? Is there any problem in doing this?

FriendRunner – Now more scalable!

As software developers, we’re constantly reminded to “eat our own dog food”.  Of course, this means that we need to force ourselves to actually use the products we build (in the same way that our customers will) so we can see how difficult they are to use, and that hopefully we’ll improve them for the better. Some people call this “drinking your own champagne”, but they’re just delusional.

With this in mind, we’re happy to report that FriendRunner is now more scalable than ever. Our own testing showed that at higher levels of virtual users, one of our internal components that processes Profiler data would get swamped and could start to fail. That’s right, we humbly and ironically report that the tool you use to test the scalability of your Facebook apps was itself susceptible to scalability problems. We’ve spent the last few days rearchitecting this component so that we can run several copies of it on concurrent machines which can be duplicated as much as the load requires, just like the rest of the FriendRunner infrastructure. The end result is a much more robust and scalable tool that handles large loads easily.

Okay, but why blog about it? Well, we have several reasons:

• We come from a computer security background, so we believe that it’s important to be open and honest about the capabilities of our products. If that includes limitations and problems, so be it.
• To remind ourselves about the importance of testing software products
• Fixing problems like this means that we’re constantly trying to make FriendRunner a better tool
• We found this cool dog food picture, and needed a reason to share it.

So how about your products? Are they really as scalable as you think? Do they have the virtual cojones to stand up to load testing from FriendRunner? Let us know when you’re ready to try it out.

Welcome to FriendRunner Development Zone

FriendRunner is the Cloud-Based Service for Optimizing Facebook Applications. It allows Facebook application developers to test their apps in ways that are not otherwise possible.

This blog is the place for the developers of FriendRunner to discuss the new features that they’re working on, as well as tips for how to get the most out of using FriendRuner. Please feel free to join into our conversation, and suggest ways that we can make FriendRunner more useful to you.