Many Channels for hi5 Platform Info -- Twitter, IRC, Wiki & More!
| Permalink | Comments (0) | TrackBacks (0)Our team had plenty of work last week helping the platform respond to the tremendous growth we've seen in the recent past. We really appreciate the patience and support of all the developers who are working hard to create applications for our 80 million members globally. If you are one of these developers -- thank you!
We believe we are now in better shape to handle the high load conditions we saw previously (and expect will continue with the ongoing success of our platform). An important learning for us was to maintain multiple communication channels with developers to provide up-to-the-minute updates and other valuable hi5 information, whether through our IRC channel, discussion forum or this blog. More recently, we've also added a Twitter account to our portfolio of communication tools, and a couple rounds of temporary down times have already been twittered (tweeted?) over the last couple of days.
Next week, we'll add yet another way of communicating with us and with each other. Specifically, we will be opening up the wiki on our Developer Center website to enable collaboration. If you have any suggestions for the structure of and navigation between the developer-accessible pages (such as posting sample code, creating feature request pages, interacting with our users to know what apps to build, etc.), please do let us know.
Beyond communication with the developer community, another focus for us has been on setting fair standards for application notifications. Our users expect applications on hi5 to behave according to the high standards we've set for other features of our service, which among other things means that installing applications will not overwhelm their in boxes with irrelevant or misleading information. We've applied over four years of learning into the guidelines we set for creating effective and useful viral channels for our service, and are continually evolving our developer guidelines to inculcate these learnings, while also reacting to the fluid nature of the application landscape. Please check out the latest updates to our guidelines, if you haven't already. We welcome your feedback.
hi5 Co-Sponsoring OpenSocial Week in Buenos Aires – Tech Talks, Hackathon & More
| Permalink | Comments (0) | TrackBacks (0)
hi5 is teaming up with Google, Globant and others to present OpenSocial Week in Buenos Aires, Argentina, from Monday, April 28 – Saturday, May 3. During the festivities, we’ll share information about using OpenSocial on the hi5 Platform to build applications for our 80 million registered members around the globe, including our large user base in South and Central America. I'll be there personally May 2-3 to talk at a couple universities and present at a hackathon.
The complete schedule of each day’s event is located on the OpenSocial API blog here. We look forward to meeting hi5 developers in Argentina face-to-face. Let us know if you’d like to set up some one-to-one meetings to discuss the success of your apps on hi5!
The complete schedule of each day’s event is located on the OpenSocial API blog here. We look forward to meeting hi5 developers in Argentina face-to-face. Let us know if you’d like to set up some one-to-one meetings to discuss the success of your apps on hi5!
Platform Status -- Performance, Performance, Performance
| Permalink | Comments (0) | TrackBacks (0)
Hi folks,
As many of you know we've been working around the clock to target and fix performance and stability issues on the platform. A big thanks for everyone's patience and understanding.
I'm happy to say that we've identified the root source of our stability problems. It's related to notifications in the platform. With notifications off in the past 36 hours we have not seen any of the erratic behavior of previous nights. We have code fixes we will deploy on Sunday that will re-enable notifications for most Applications.
So what happened?
The following histogram of http responses tells the tale:
Starting April 15th we started noticing poor performance overnight. You've seen it, timeouts, 500 errors, gateway timeouts, etc. We started our normal site stability processes to target the problem. Stack traces were generated, memory dumps analyzed, etc. This technique had served us well in diagnosing performance problems generating FOAF data for users with thousands of users. At the same time we added 50% more servers to the pool.
In our analysis we quickly focused our attention to concurrency problems in some portions of our code. We found that Java itself has some serious contention for global Character Set data and Crypto providers. So we spent a lot of time working around these problems. However we'd fix one concurrency problem, and quickly hit another one. This went on for days, we'd think we had the problem solved, then it would come back with a vengeance.
This past friday, the 25th we were dealing with the same issues. We noticed that the poor performance coincided with notification database alerts. At 11:00 we turned off notifications and the entire system was suddenly stable.
With this breathing room we've now had time to finish a project to improve notifications scalability. This code will go out on Sunday, with most applications having notifications functionality by Sunday.
Why Did This Happen?
We underestimated the amount of notifications sent, and the popularity of their use on the site. At first glance this just meant that posting and browsing notifications were slow. We didn't expect that other requests would suffer collateral damage.
Changes Going Forward...
Today we made the following Notifications changes. Our goal is to get Notifications on for all applications while maintaining overall site stability:
Both Operations and Engineering have been happy to get a few good nights sleep since friday. We look forward to working on new features instead of fighting fires.
One final note on platform status -- we know that stats were unavailable in the dev console this weekend and expect to have them back online tomorrow.
As many of you know we've been working around the clock to target and fix performance and stability issues on the platform. A big thanks for everyone's patience and understanding.
I'm happy to say that we've identified the root source of our stability problems. It's related to notifications in the platform. With notifications off in the past 36 hours we have not seen any of the erratic behavior of previous nights. We have code fixes we will deploy on Sunday that will re-enable notifications for most Applications.
So what happened?
The following histogram of http responses tells the tale:
Red is 500 errors, light blue timeouts, dark blue is good responses.
In our analysis we quickly focused our attention to concurrency problems in some portions of our code. We found that Java itself has some serious contention for global Character Set data and Crypto providers. So we spent a lot of time working around these problems. However we'd fix one concurrency problem, and quickly hit another one. This went on for days, we'd think we had the problem solved, then it would come back with a vengeance.
This past friday, the 25th we were dealing with the same issues. We noticed that the poor performance coincided with notification database alerts. At 11:00 we turned off notifications and the entire system was suddenly stable.
With this breathing room we've now had time to finish a project to improve notifications scalability. This code will go out on Sunday, with most applications having notifications functionality by Sunday.
Why Did This Happen?
We underestimated the amount of notifications sent, and the popularity of their use on the site. At first glance this just meant that posting and browsing notifications were slow. We didn't expect that other requests would suffer collateral damage.
Changes Going Forward...
Today we made the following Notifications changes. Our goal is to get Notifications on for all applications while maintaining overall site stability:
- Accepting Notifications Asynchronously
- Applying Notification Retention policy to remove the oldest Notifications from the system (14 day retention)
- Adding Extra Notification Capacity
- Only allowing Notification REST calls with a token generated in the preceding 4 hours.
- Additional privacy controls to insure that the notification is legitimate.
- Conversations with our partners that are using the Notifications Feature the most.
Both Operations and Engineering have been happy to get a few good nights sleep since friday. We look forward to working on new features instead of fighting fires.
One final note on platform status -- we know that stats were unavailable in the dev console this weekend and expect to have them back online tomorrow.
Currently our auth_tokens have a lifespan of 2 weeks, which is unecessarily long and opens the door for potential abusive usage of features like notifications. To address this, we are going to start reducing the lifespan by a day each day for the next 2 weeks until it is 1 day.
We do expect to add support for authentication via API Key + a secret key per application, to allow for things like periodic email newsletters. No ETA on that support yet, but we do know it's a valuable feature that you'll be looking out for in the future.
We do expect to add support for authentication via API Key + a secret key per application, to allow for things like periodic email newsletters. No ETA on that support yet, but we do know it's a valuable feature that you'll be looking out for in the future.
There were some requests that I put up the slides from my talk at web 2.0 expo yesterday. Ask and you shall receive:
http://docs.google.com/Presentation?id=dxpbvz6_141gnxn58d8
http://docs.google.com/Presentation?id=dxpbvz6_141gnxn58d8
I've noticed some developers putting 'view=preview' or 'view=canvas' on canvas page links in activity and notifications. This is generally not a good idea as it's not a good experience for a user who has already installed the application to be sent to the preview view. We only support it so developers can troubleshoot all views of their application from the dev console.
The canvas page (www.hi5.com/friend/apps/displayAppCanvas.do?appId=xxxx) is smart enough to display the preview view if the user has not installed the application yet, so I would highly recommend not specifying a view in your activity and notification urls, and letting the canvas page logic display the appropriate view for you.
The canvas page (www.hi5.com/friend/apps/displayAppCanvas.do?appId=xxxx) is smart enough to display the preview view if the user has not installed the application yet, so I would highly recommend not specifying a view in your activity and notification urls, and letting the canvas page logic display the appropriate view for you.
One common request we've gotten was to return more information about invites to developers. To do this, we've implemented a new lifecycle event for the hi5-lifecycle feature called invitePingUrl. Here's sample usage along with the two previous events, install and remove. This should be added into ModulePrefs:
<Optional feature="hi5-lifecycle">
<Param name="installPingUrl" value="http://yourserver/handleInstall"/>
<Param name="removePingUrl" value="http://yourserver/handleRemove"/>
<Param name="invitePingUrl" value="http://yourserver/handleInvite"/>
</Optional>
This is a good time for a refresher on the existing events, so here's what to expect from each event:
NAME FIRES METHOD PARAMS
installPingUrl After install POST uid = userid of installing user
removePingUrl After uninstall POST uid = userid of uninstalling user
invitePingUrl After invite POST uid = userid of inviter, sent_ids = userids successfully sent to
One other note -- these pings are not currently signed. This has been requested by several developers and we do have a feature request open for this, although we don't have an ETA on that being completed at the moment.
Hope you find this useful.
<Optional feature="hi5-lifecycle">
<Param name="installPingUrl" value="http://yourserver/handleInstall"/>
<Param name="removePingUrl" value="http://yourserver/handleRemove"/>
<Param name="invitePingUrl" value="http://yourserver/handleInvite"/>
</Optional>
This is a good time for a refresher on the existing events, so here's what to expect from each event:
NAME FIRES METHOD PARAMS
installPingUrl After install POST uid = userid of installing user
removePingUrl After uninstall POST uid = userid of uninstalling user
invitePingUrl After invite POST uid = userid of inviter, sent_ids = userids successfully sent to
One other note -- these pings are not currently signed. This has been requested by several developers and we do have a feature request open for this, although we don't have an ETA on that being completed at the moment.
Hope you find this useful.
As of last night, the hi5 Platform release has been rolled out to 100% of our 80+ million registered members across the globe. We're very excited to have been able to complete the rollout process in such a short period of time. We've also been busy reviewing and approving new applications as they are submitted, and are happy to report our gallery now boasts 149 applications (for comparison, we started with 65 at launch on Monday)!
To help spread your apps, we'll be adding a homepage and profile promotion for the Application Gallery starting Monday, and enabling email notifications Monday as well. Let us know if you have any questions about how to leverage our numerous viral channels for promoting your apps – we love all the new ways our users can enjoy hi5 with your apps!
Thanks again to all the developers that have helped make this launch a success. We're looking forward to a huge week next week for applications on hi5, as well as rolling out full access to our wiki and bug tracker, and getting started on hi5 Platform v2!
To help spread your apps, we'll be adding a homepage and profile promotion for the Application Gallery starting Monday, and enabling email notifications Monday as well. Let us know if you have any questions about how to leverage our numerous viral channels for promoting your apps – we love all the new ways our users can enjoy hi5 with your apps!
Thanks again to all the developers that have helped make this launch a success. We're looking forward to a huge week next week for applications on hi5, as well as rolling out full access to our wiki and bug tracker, and getting started on hi5 Platform v2!
Quick refresher on required ModPrefs for gallery approval
| Permalink | Comments (0) | TrackBacks (0)
First off I just have to give a big hats off to all the developers submitting applications over the last week or so. We've been very happy with the submissions we've seen so far. A couple things to keep in mind before submitting your app to the gallery.
We definitely want you to at a minimum have these ModulePrefs attributes defined in your XMLs.
<ModulePrefs
title="My Super Cool App"
summary="Tag line for my super cool app"
description="This app will let you do cool things"
icon="http://someserver/some15x15pixel-image.gif"
thumbnail="http://someserver/some120x60pixel-image.gif"
author_email="this-is-also@required.com" >
as always contact platform-help@hi5.com if you have further questions.
Happy Hacking,
Dave
We definitely want you to at a minimum have these ModulePrefs attributes defined in your XMLs.
<ModulePrefs
title="My Super Cool App"
summary="Tag line for my super cool app"
description="This app will let you do cool things"
icon="http://someserver/some15x15pixel-image.gif"
thumbnail="http://someserver/some120x60pixel-image.gif"
author_email="this-is-also@required.com" >
as always contact platform-help@hi5.com if you have further questions.
Happy Hacking,
Dave
Ranking applications and increasing your exposure to users
| Permalink | Comments (0) | TrackBacks (0)We have gotten many questions about how we rank applications in the app gallery and how an app developer can increase their exposure to users. I'd like to offer a brief explanation about our current and long-term goals regarding application ranking.
Our Goal:
First of all, I wanted to state that our ultimate goal is to provide the richest, most engaging experience to our users. To this end, we plan on offering application developers a variety of incentives/penalties for providing a positive/negative user experience.
Implementation:
At launch we do not have much data to work with, so we decided to provide a randomized application gallery until we have enough data to provide a meaningful sort order of applications. We feel that this will provide the most level playing field initially and let the applications speak for themselves.
As soon as we switch over to using metrics to determine the sort order, we will offer an explanation as to how you can improve your engagement score. The general guidelines we will follow should be fairly self-explanatory. Actions such as installs, views and accepted invites will be positive influences, while rejected invites, blocked applications and removes will be negative influences.
© 2008 hi5Networks