The Blog

Posts from May 2013

May 31

Game Face

By David Czarnecki

“Game Face” will be our weekly round-up of our internal and external open source work here at Agora Games. Internal open source refers to our public projects that you can find over at our Agora Games GitHub account. External open source work refers to projects that we contribute to in off-hours and may or may not have anything to do with video games because we’re swell folks like that. Pretty simple right? Here goes…

leaderboard

leaderboard allows you to build leaderboards using Redis. The leaderboard (Ruby), leaderboard-python and leaderboard-coffeescript libraries all saw updates this week. In leaderboard 3.2.0, we added a method to be able to remove members from the leaderboard outside a given rank . This same functionality was ported to leaderboard-coffeescript 1.2.0 and leaderboard-python 2.4.0.

Contributor(s): David Czarnecki (GitHub, Twitter) and Simon Zimmerman (GitHub).

May 24

Game Face

By David Czarnecki

“Game Face” will be our weekly round-up of our internal and external open source work here at Agora Games. Internal open source refers to our public projects that you can find over at our Agora Games GitHub account. External open source work refers to projects that we contribute to in off-hours and may or may not have anything to do with video games because we’re swell folks like that. Pretty simple right? Here goes…

chai

chai provides a very easy to use api for mocking/stubbing your python objects, patterned after the Mocha library for Ruby. We’ve had a few rapid fire releases to try and address Python 3 compatibility. chai 0.3.4 incorporates the following:

  • Further fixed global namespace manipulation on test class hierarchies
  • Expectations with a type argument are matched against either an instance of that type, or the type itself
  • Removed unittest2 requirement and termcolor requirement, fixes https://github.com/agoragames/chai/issues/5

 

Contributor(s): Aaron Westendorf (GitHub, Twitter)

torus

torus is a service implementing the Carbon protocol to store time series data using kairos and an HTTP server to query and analyze the data. torus 0.3.2 incorporates the following changes: - Fixed handling of “condensed” and “interval” parameters to “/series” - Fixed handling of “start” and “end” parameters to “/series”

 

Contributor(s): Aaron Westendorf (GitHub, Twitter)

May 17

Game Face

By David Czarnecki

“Game Face” will be our weekly round-up of our internal and external open source work here at Agora Games. Internal open source refers to our public projects that you can find over at our Agora Games GitHub account. External open source work refers to projects that we contribute to in off-hours and may or may not have anything to do with video games because we’re swell folks like that. Pretty simple right? Here goes…

kairos

kairos provides time series storage using Redis or Mongo backends. As of the 0.3.0 release, we have implemented support for Gregorian data intervals (daily, weekly, monthly, yearly) and there is a new API for Timeseries.series(). Check the README for more details.

Contributor(s): Aaron Westendorf (GitHub, Twitter)

leaderboard

leaderboard allows you to build leaderboards using Redis. The leaderboard (Ruby), leaderboard-python and leaderboard-coffeescript libraries all saw updates this week. In leaderboard 3.1.0, we added support for a members_only option when making various leaderboard requests to only return the member data and not rank or score data. This same functionality was ported to leaderboard-coffeescript 1.1.0 and leaderboard-python 2.3.0.

Contributor(s): David Czarnecki (GitHub, Twitter) and Simon Zimmerman (GitHub).

torus

torus is a service implementing the Carbon protocol to store time series data using kairos and an HTTP server to query and analyze the data. With the 0.3.0 release, we upgrade to kairos 0.3.0 to add support for Gregorian dates and date ranges to “/series”, added support for UNIX timestamps or parsedatetime-compatible strings for ‘start’ and ‘end’ parameters to “/series” and added support for ‘steps’ parameter to “/series”.

Contributor(s): Aaron Westendorf (GitHub, Twitter)

May 13

How to do Open Source: A Case Study in 1 Issue and 6 Pull Requests

By David Czarnecki

I wanted to highlight a recent set of contributions from Simon Zimmerman to our leaderboard-python that, in my opinion, reflect how to effectively participate in open source projects. The pull requests are as follows:

  1. StrictRedis not considered when passing connection argument to Leaderboard
  2. don’t deepcopy options (branch: performance)
  3. ASC sorted page_for was broken due to a spelling error (branch: page_for-fix)
  4. leaders() should return an empty list in case of an empty result set. (branch: leaders-return-type)
  5. remove unused calculation in leaders_in method. (branch: unused-calculation)
  6. proposal: consider using named key word arguments instead of **options (branch: options)
  7. add members_only option. (branch: members_only-option)

Aside from the first issue, which is a very clear and concise explanation of where an underlying and undocumented check in the library could trip up potential users of the library, all of the pull requests follow the same pattern:

  • Meaningful title
  • Separate branch with a meaningful branch name per pull request
  • Small, focused and tested pull request that could be evaluated independently
  • Clearly identify a proposal pull request before embarking on code changes that may go against the convention or direction of the project

How does all of this help me as a library maintainer? Well, meaningful titles in a pull request or issue help me to mentally narrow down the extent of the change(s) or the code I might be looking at without having to actually look at the code. To quote George Costanza from Seinfeld, “I like stuff you don’t have to think about too much.” Meaningful titles go a long way to making that happen. Separate branches are nice because I can evaluate the change(s) in the code independently of other feature changes. It also indicates that the contributor took the time to actually read the “contributing to this project” section in the README. None of the pull requests were more than a few lines of code and the ones that added or changed functionality included tests. That always helps since I’m more likely to integrate a pull request immediately if I can pull the feature branch, run the tests and know that the library won’t break in strange and unusual ways. And finally, it’s nice to propose larger feature changes that may affect the entire library in a small spike and to gauge interest from the library maintainer(s). It saves everyone a lot of time if it’s functionality that isn’t desired given conventions or direction of the project.

May 10

Game Face

By David Czarnecki

“Game Face” will be our weekly round-up of our internal and external open source work here at Agora Games. Internal open source refers to our public projects that you can find over at our Agora Games GitHub account. External open source work refers to projects that we contribute to in off-hours and may or may not have anything to do with video games because we’re swell folks like that. Pretty simple right? Here goes…

bnet_scraper

bnet_scraper is our Nokogiri-based scraper of Battle.net profiles. In 0.6.0, we added a GrandmasterScraper to pull all grandmasters by region, improved the portrait code as well as updating portrait names for anniversary.

Contributor(s): Andrew Nordman (GitHub, Twitter)

confirm-with-reveal

confirm-with-reveal is a replacement for window.confirm() using the Reveal modal popup plugin from Zurb Foundation. The latest release this week addresses form confirmation on submit, not on click. You can also check out the plugin in action on the project page.

Contributor(s): Jack Letourneau (GitHub, Twitter)

leaderboard_factory

leaderboard_factory is a gem to help you define and work with a bunch of leaderboards, from, e.g. an ActiveModel object. The latest release fixes the specs to work with the leaderboard 3.0+ gem.

Contributor(s): Matthew Wilson (GitHub, Twitter)

stache

stache is our Rails 3.x compatible Mustache/Handlebars Template Handler, with support for partials and a couple extra niceties to make sharing the raw templates with client-side javascript a little easier. The 1.0.1 release fixes a regression in mustache layout handling.

Contributor(s): Matthew Wilson (GitHub, Twitter)

 

May 10

New Hydra Beta Features - April & May 2013

By Elliott Haase

April was another busy month for the Hydra team and the Hydra closed beta. We accomplished another set of significant milestones that moves us even closer to launching the Hydra closed beta to the public later this year.

Below is an overview of the new features we released during April and the first week of May. Take a quick read, and then head to the Hydra dashboard and give everything a test run. Make sure you let us know your thoughts on the Beta Support Forum as your feedback is extremely valuable.

User Account Enhancements

One of our largest enhancements this month was specific to our user account system. We officially moved from a purely global user account system to an environment specific user account system with our maintenance on May 8th. We made these changes based on beta user feedback, alongside a list of user account enhancements that we felt necessary to deploy after having the Hydra closed beta running for a few months now.

We expect to have development teams of all kinds using Hydra, and we feel its more important to provide developer tools to easily control the user accounts created by their titles, instead of having a purely global Hydra account system that requires all developers to fall in line with one specific setup. These changes help us achieve that.

To read a full overview of the changes and to better understand our thought process, please read our official announcement post.

Dashboard Analytics

The 1st iteration of project analytics was released to the Hydra closed beta dashboard in April. The goal of our 1st iteration was to provide tracking of the most essential project statistics (active users, profile activity, match activity, and other basic feature activity). While these features are still running through basic QA currently, we have laid the foundation and you can begin working with these analytics now.

We have enabled a basic view of per-project-environment analytics that you can access via the “Statistics” link when working within any of your project environments. Additionally, from the statistics page you can select specific stats that you want visible on your environment dashboard (allowing for quick and easy viewing of those stats you view most important for your project).

Active user stats play a significant role in our Hydra pricing plans. On your main Hydra dashboard page we’ve also added active user stats so you can easily view the current usage numbers for all of your projects.

We have a lot more to add to our analytics offering, so please make sure you let us know your thoughts on what’s most important to you!

Data Export

Early in April we released data export functionality to the Hydra closed beta dashboard. You can now export all of your Hydra data to an Amazon S3 account. All you need to do is provide your AWS access key and a secret key (that allows Hydra to create and populate new Buckets) and we take care of the rest. You can create an export once every 24 hours, and you can see the status of your most recent export right on the Hydra closed beta dashboard.

Everything else

In addition to the top level features above, we released a number of additional updates that we’ve detailed below:

1. Facebook User Account Login - The hard work here is done, as we have fully integrated our user account system with the available Facebook API. We haven’t officially released it to our beta users yet as we are closing up QA and SDK updates right now. We’ll be working to make this functionality available as soon as we can.

2. Automatic Leaderboard & Achievement rebuilds - Easily add in new leaderboards and achievements as far after your project launch as you want. When you create a new leaderboard or achievement after your project has launched (and you already have a number of users with existing profile stats), Hydra will automatically rebuild and populate those leaderboards and achievements with existing user profile data for you.

3. Pricing/Payment Processing - We’ve completed the 1st iteration of our payment processing functionality which directly ties into our Hydra pricing plans. We’re using Stripe for payment processing integration, and when we launch the Hydra beta to the public later this year you’ll be able to manage your per-project pricing plans right on the dashboard. It’s our goal to keep payment processing as simple and straightforward as possible.

4. Improved “Getting Started” Guide - We’ve greatly improved the basic user workflow for all new beta users signing onto the Hydra dashboard for the first time. When new users sign on they’ll quickly create their first project, and then walk-through the most essential steps to get Hydra up and running (with the dashboard providing information and tips along the way).

Still to come

Here is a list of the features that are currently under development, and that you’ll be able to get your hands on soon:

Hydra C++ SDK

Environment cloning functionality

*Friends - *Facebook friend import

*Chat/Presence - *First iteration of match/lobby chat functionality

Feel free to post questions on any of these features in our Beta Support Forum, and continue to put our platform to the test. Thanks a ton!

- The Hydra Team

May 10

Hack-a-Thon 12 Pull Request Recap

By David Czarnecki

Now that our latest Hack-a-Thon has wrapped up here, we’ve got a few pull requests and issues filled out with various projects. Here’s a recap:

May 3

Game Face

By David Czarnecki

“Game Face” will be our weekly round-up of our internal and external open source work here at Agora Games. Internal open source refers to our public projects that you can find over at our Agora Games GitHub account. External open source work refers to projects that we contribute to in off-hours and may or may not have anything to do with video games because we’re swell folks like that. Pretty simple right? Here goes…

activity_feed

activity_feed is our Ruby gem for storing and managing activity feeds in Redis. The 2.3.0 release adds a check_item?(…) method to see if an item is in an activity feed.

Contributor(s): David Czarnecki (GitHub, Twitter)

homebrew

homebrew is the “missing package manager for OS X”. We submitted a pull request that was integrated for adding Redis 2.6.13 support.

Contributor(s): David Czarnecki (GitHub, Twitter)

kairos

kairos provides time series storage using a Redis backend and, as of 0.2.0, MongoDB. The latest release is a major refactor, and with the new MongoDB backend, supports many more use cases. The 0.2.1 release also includes optimizations for processing multiple transforms on each data set query.

Contributor(s): Aaron Westendorf (GitHub, Twitter)