Returning for its second year, Open Jam is an 80-hour game jam brought to you by @Jared-Sprague, @mwcz, and opensource.com. Game jams are focused on creating games with a few constraints, like adhering to a limited time frame in creating a game, staying within a theme, or using only a specific technology. Participants are encouraged to use open source game engines, libraries, tools, and Creative Commons assets.

Last year’s Open Jam theme ‘Leave a mark’ brought about a frenzy of fun games including Stellar Wrath, a game about solar system sabotage created with Godot.

Open Jam is a perfect excuse to experiment with building a game if you haven’t before. With so many tutorials online and a growing number of game engines, it’s easy to make an addictive Java-based text adventure or JavaScript-powered platformer.

The three top-rated games of Open Jam will have their playable demos featured at the All Things Open conference in Raleigh, NC from October 21–23.

Pictured: Stellar Wrath by DualWielding was one of last year’s winners on display at All Things Open.

The 2018 events kicks off on October 5, so keep refreshing the itch.io jam page for the theme announcement, tips, tutorials, and competition details. If you can’t participate in Open Jam, don’t worry—Game Off, GitHub’s very own month-long game jam, will return next month.

Join Open Jam 2018 now

Join us at the GitHub office in Amsterdam for Hacktoberfest’s 5th anniversary! On Tuesday, October 2, from 19:00 to 22:00, we’re celebrating with food, drinks, learning, and great company.

Learn how to contribute to open source from local maintainers, get up to speed on how GitHub works, and make some pull requests. The evening will begin with presentations from local open source maintainers, an introduction to how open source works, and how you can contribute. Then we’ll help new and experienced folks get down to business. Don’t worry—we’ll have plenty of snacks and stickers to help fuel your ideas.

New to open source? We’ll help you along the way. Already an experienced contributor? Come and hack on your favorite project, and help mentor folks! No contribution is too small, and we’ll have lots of help on hand, including @DEGoodmanWilson (GitHub) and @floord (Phusion).

Register now

Date: Tuesday, October 2
Time: 19:00 - 22:00
Address: Spaces Vijzelstraat, Vijzelstraat 68-72, 1017 HL Amsterdam

Can’t make this event? It’s not too late to find another one nearby, or even organize your own event at your club, school, or workplace!

Events are kicking off all around the world:

• Bangkok
• Bhubaneswar
• Luxembourg

…and more, coming to a city near you!

Check out the Hacktoberfest Event Kit for more information.

Join us at GitHub HQ in San Francisco for Hacktoberfest’s 5th anniversary! On Monday, October 1, 2018, from 6:30 pm to 9:30 pm we’re celebrating with food, drinks, learning, and great company.

We’re hosting a workshop on contributing to open source, plus we have some demos and lightning talks from a few guests speakers, including @KyleAMathews (Gatsby creator), @codebytere (Electron engineer), and @michael-watson (Apollo GraphQL engineer). See the Eventbrite page for the complete agenda.

Register now

Date: Monday, October 1
Time: 6:30 pm - 9:30 pm
Address: 88 Colin P Kelly Jr St, San Francisco, CA 94107

Can’t make this event? It’s not too late to find another one nearby, or even organize your own event at your club, school, or workplace.

Events are kicking off all around the world:

• Atlanta
• Glasgow
• Visakhapatnam
• Mauritius …and more, coming to a city near you!

Check out the Hacktoberfest Event Kit for more information.

GitHub Universe is just under a month away. With the countdown officially on, we’re excited to share all of the things you need to know for Universe 2018. Our complete schedule of Universe sessions and speakers is now live, and there’s something for everyone: three tracks, 30 breakouts, a full day of technical workshops, and plenty of learning in between.

Build your own Universe

This year, we’re highlighting the future of software—and celebrating the people and projects that push technology forward. Our three attendee tracks are here to help you build a custom Universe itinerary and get the most out of two jam-packed days at the historic Palace of Fine Arts:

• Developer experience
• Scaling your business
• Enabling your platform

Get into the code

Looking to learn something new? Take the “developer experience” pathway and dive into how the problems of tomorrow are being solved by your peers. Find out what the future holds for your favorite tools and technology—and build your own solutions.

The “developer experience” pathway includes sessions like:

• Code you can hold: Making your first IoT wearable Charlyn Gonda (Uber Engineering) Pick up a soldering iron and put on safety goggles—it’s time to make things. Get started with microcontroller programming, beginning with the Particle Photon board, a wifi-enabled microcontroller.
• Leveling up WebAssembly itself: Going from MVP to brave new world Lin Clark (Mozilla) Unlock the future of WebAssembly and build your own. Learn how to code a WebAssembly module and see your module’s impact on the real world—or at least on the interactive light environment that coming to GitHub Universe. Then take control of the art installation with your WebAssembly module and walk through your creation.
• GitHub Learning Lab: Teaching robots to teach Jason Etcovitch (GitHub) Discover how we built the Learning Lab app using public GitHub APIs and Probot, a framework for building GitHub Apps. Build your own courses on Learning Lab to teach developers how you work, what your product or integration does, or something completely new.

Grow your business to scale

It’s exciting to see your business grow—but growth also comes with its own new set of challenges. Our “scaling your business” pathway offers real-life case studies and insight from some of today’s top business leaders, including how they tackled the unique business demands that come with rapid growth.

Check out more of the highlights:

• GitHub Enterprise at scale: Behind the scenes at Salesforce.com Vamshidhar Gandham (Salesforce), Michael Johnson (GitHub) Wondering how to get started with GitHub Enterprise? Find out why Salesforce started using GitHub, the tools they created to simplify migration, and how GitHub Enterprise has helped them change the face of DevOps.
• The world’s largest company explains why the future needs more women who code Fiona Tan (Walmart) Increasing the number of women who can code, and specifically in the growing field of artificial intelligence, is critical. Examine why women are fundamental to the future of the self-learning algorithms that power AI and why closing the gender gap in STEM is not only important for business, but important for society.
• Moving from mono to multi: How Continental Corporation manages a distributed code base Timm Drevensek (Continental Corporation) Working with larger software projects means you’ll eventually need to decide how to organize your code base. See how the Continental team overcame limitations, how to deal with distributed code bases, and what’s possible when integrating with GitHub.

Keep your platform healthy

Is your platform performing at its best? Follow the “enabling your platform” pathway and explore how leveraging the right tools (and embracing necessary change) can help your platform reach its full potential. Find out how developers from companies like Airbnb, Contentful—plus GitHub itself—keep things running smoothly behind the scenes.

And just a few examples of what else you’ll learn:

• From Monorail to Monorepo: Airbnb’s journey into microservices Jens Vanderhaeghe (Airbnb) Airbnb has grown exponentially over the last few years—and so has their codebase. Hear some of the unique challenges they face as their engineering team grows and how they plan to transition toward a service-oriented architecture—a multi-year effort involving hundreds of engineers across the company.
• Infrastructure as product: Building GitHub’s future Sophie Haskins (GitHub) Learn the story of Moda—GitHub’s internal service platform and set of tools, practices, and ideas for running software on Kubernetes. Discover how we approached big infrastructure changes, what’s worked well, and why we made the decisions we did.
• API mashup: Combining APIs using GraphQL schema stitching Rouven Weßling (Contentful) The best mashups are seamless and natural. In today’s golden age of APIs, nobody would be surprised if you used more than six APIs in a project. But, like songs, they all work slightly differently. Find out how to use schema stitching to annotate the GitHub API with metadata about the repositories and users in an organization, resulting in a more powerful API that’s ready to build great tooling with less effort.

Get even more Universe with Workshop Day

Universe isn’t just product launches and after parties. We want you to go home with the practical tools and experience you need to keep building your best. If you’re looking to learn even more—and get an extra day of Universe—join us a day early for technical workshops on October 15.

Like our conference sessions, Workshop Day features three unique attendee tracks. We’ll cover everything from the secrets of great maintainers to scaling GitHub within your organization. Just pick your path to get started:

• 2018: An Open Source Odyssey - Workshops for individuals and teams interested in innersource, open source, and everything in between
• U, Robot - Workshops for builders and bot lovers 🤖
• Git Runner 2048 - Workshops for future Git and GitHub superusers

Check out Universe Workshops

Your Universe is what you make it

Whether you want the latest coding tools, tips to successfully scale your business from industry experts, or tried-and-trued insights to take your platform to the next level, Universe 2018 is a place for everyone—and an experience completely yours. Tickets are limited, so reserve your seat and conference pathway as soon as possible. We can’t wait to see you there!

Get your tickets

We first started talking about GitHub Apps in 2017 as the recommended way for developers to build integrations on GitHub. With GitHub Apps, developers can use either GitHub’s REST or GraphQL APIs to interact with the GitHub ecosystem and provide a more flexible security model for users. Since announcing, we have released new documentation and guides to help simplify the process of building new integrations or migrating existing OAuth Apps and talking to integrators about their experiences. For those considering building or migrating to GitHub Apps, we thought it might be interesting to share one of those stories from Code Climate.

Code Climate has built on GitHub from the very beginning. Now they’re using GitHub Apps to build bots, manage server-to-server integrations, limit permission scopes, and provide better support to the engineers using their products. Here’s how they build with GitHub Apps, and what they learned in the process, in the words of Chris Hulton, Senior Engineer.

Code Climate Switches to GitHub Apps

Why are we so excited about GitHub Apps?

Though GitHub OAuth provides great capabilities for managing user-initiated actions, it presented us with a few limitations for building server-to-server integrations.

Using GitHub Apps to build bots

In our Quality product, we wanted to provide users with an Automated Code Review feature. Before GitHub Apps, we used individual user credentials to retrieve and post data into GitHub. We couldn’t post review comments on our customers’ pull requests as a Code Climate bot. GitHub Apps solve this problem.

Using GitHub Apps to manage server-to-server integrations

Some of our customers have immediate security policies that don’t allow us to use SSH to clone repository data from GitHub. Prior to GitHub Apps, we implemented HTTPS repository data cloning by rotating through various users’ OAuth access tokens. This means that these HTTPS calls are associated with specific GitHub users, even though they are not initiated by them. With GitHub Apps, we can authenticate to pull this type of data as a service.

Using GitHub Apps to limit permission scope

In the world of GitHub OAuth, read and write access to repository data are bundled together. GitHub Apps provides much more granularity in permissions. We are now able to ask for only the access level we need (read-only) on the specific resources we need (e.g. pull requests). This aligns the requested permission with the services we provide, making our users more comfortable.

How did we go about implementing GitHub Apps?

We found that switching to GitHub Apps did not require our existing system to be substantially restructured. The API endpoints and queries that we implemented via OAuth remained the same for GitHub Apps, and only our method of authentication changed.

For querying, we use GitHub’s graphql-client gem, with our client defined as:

class HTTP < ::GraphQL::Client::HTTP
  def initialize(vcs, access_token)
    super(vcs.graphql_api_url)
    @access_token = access_token
  end
  
  def headers(context)
    {}.tap do |h|
      if (token = context.fetch(:access_token, @access_token))
        h.merge!("Authorization" => "Bearer #{token}")
      end
    end
  end
end

With OAuth, for access_token, we provided the authorized OAuth token of a random user in the organization. Randomization helped us to balance usage across the organization, but was not ideal. We wanted to make the API request on behalf of the organization itself, which is where GitHub Apps came in.

With GitHub Apps, access is provided via short-lived, renewable tokens belonging to the installation, and the installation is granted the appropriate permissions. We introduced a component in our code that would generate a token for the organization’s GitHub App installation using the octokit gem and the credentials of our GitHub App:

  def create_token
    create_token_client.create_app_installation_access_token(
      external_database_id,
      accept: Octokit::Preview::PREVIEW_TYPES[:integrations],
    )
  end
  
  def create_token_client
    @create_token_client ||= Octokit::Client.new(
      bearer_token: generate_jwt_token,
      api_endpoint: vcs.api_url,
      web_endpoint: vcs.web_url,
      connection_options: {
        url: vcs.api_url,
      },
    )
  end
  
  def generate_jwt_token
    now = Time.now.to_i
    key = OpenSSL::PKey::RSA.new(vcs_app.private_key)
    opts = {
      iat: now,
      exp: now + 60,
      iss: vcs_app.external_database_id.to_i,
    }
    
    JWT.encode(opts, key, "RS256")
  end

We then pass this token to the API client in exactly the same way as before, keeping the overall change small and isolated.

Additionally, each generated token comes with an associated expires_at timestamp. To improve performance, we store an encrypted copy of the temporary token along with this timestamp in our database, allowing us to refresh the token only when necessary.

What did we learn in the process?

API Rate Limit Calculation

During this migration, we learned about the different rate-limiting mechanisms between GitHub OAuth and GitHub Apps.

With OAuth, we were able to cycle through user tokens to make API requests. This provided a very high capacity, as each token allowed for 5,000 GraphQL points per hour. When switching to GitHub Apps, however, the rate limit became organization-wide, meaning we had to think more critically about how often we were hitting the API and how expensive our queries were.

To understand our current GraphQL usage, we used the rateLimit object received from our GraphQL queries, and began tracking statistics using StatsD around how expensive each query was, as well as how often the tokens we used approached their rate limits:

  def process_RateLimit(object)
    object = Connectors::GitHub::Graphql::Fragments::RateLimitFragment.new(object)

    prefix = ["graphql", definition.name.demodulize, "limit"].join(".")
    $statsd.gauge("#{prefix}.cost", object.cost)
    $statsd.gauge("#{prefix}.remaining", object.remaining)
  end

We found that many of our GraphQL queries were fairly inexpensive, but we identified one particularly complex query to be expensive (15 GraphQL points) and frequent (every 10 minutes for every repository in an organization). We thought about how this query would perform for a large organization in our system (for example, 100 repositories) when using GitHub Apps:

100 repositories * 15 GraphQL points * 6 queries per hour = 9,000 GraphQL points / hour

This was initially concerning, as the number was significantly more than the 5,000 GraphQL point rate limit provided for an installation. However, another advantage of GitHub Apps is that its rate limit scales with the size of the organization. For installations with more than 20 repositories, an additional 50 requests (or 50 GraphQL points) is provided for each repository per hour.

With this increase, we identified our modified rate limit would be:

5,000 GraphQL points base + 50 additional points * 100 repositories = 10,000 GraphQL points

This provided us with enough capacity to maintain our current system. To help us stay comfortably within our limit going forward, we worked with GitHub to identify additional strategies for keeping our API usage within its rate limit:

• Ingest real-time data via inbound webhooks
• Catch-up with historical data using the API
• Throttle your API requests to stay within your rate limits
• Use conditional requests, where possible (currently only available via v3 REST API)

Impact on User Onboarding

Another lesson we learned during this migration is that GitHub Apps requires a different onboarding approach. Unlike OAuth, where users typically identify themselves and grant access in one step, with GitHub Apps, users are required to leave our site and install the application on GitHub before data can be processed. To smooth out this flow, we use the GitHub App installation endpoints to track the user’s onboarding progress and display in-app calls to action linking out to the GitHub App setup URL (when appropriate).

Wrap up

We are very excited to continue to build on GitHub Apps and to take advantage of all the data exposed through the GraphQL API. We’re also looking forward to partnering with GitHub and pioneering more beta features in the future.

If you’re interested in taking a more data-driven approach to engineering management (and want to see our GitHub Apps workflow in action) check us out!