This is a site you use to test clients – mobile apps, browsers, and many other applications that use HTTP applications and TLS – the Transport Layer Security protocol. We have designed a lot of tests that checks if your browser or client application really checks the identity of the server it’s trying to connect to. It is important that developers understand how TLS works and how site verification works.

A command-line tool that helps you clean up Git branches that have been merged into master.

Packages under development aren't always ready to be in the main Debian archive. But that doesn't mean it should be hard for people to install them. When asking people to test programs, it is most convenient to present it in the way they are expecting: as a package. For this, a personal repository is useful. The tools for doing this are available in Debian, but the method is not well documented. This article attempts to do that.

Stream allows you to build scalable newsfeed and activity streams in hours instead of weeks. The documentation will get you up and running quickly. At the moment we have official clients for Ruby, JS/Node, Python, PHP and Java. Furthermore there are also example apps and Framework integrations available for Rails, Django and Laravel.

Keywhiz makes managing secrets easier and more secure. Keywhiz servers in a cluster centrally store secrets encrypted in a database. Clients use mutually authenticated TLS (mTLS) to retrieve secrets they have access to. Authenticated users administer Keywhiz via CLI or web app UI. To enable workflows, Keywhiz has automation APIs over mTLS and support for simple secret generation plugins.

My goal in this guide is both to answer these questions, and, more importantly, provide an overall framework you can use to think about how to answer these questions.

One of the hardest parts of building for Android is making your app work well on all phones. While device fragmentation often brings forth concerns on design, the bigger struggle will be behind the scenes in managing memory, rendering smooth graphics, and maintaining battery life.

So, why don’t we use git-flow at GitHub? Well, the main issue is that we deploy all the time. The git-flow process is designed largely around the “release”. We don’t really have “releases” because we deploy to production every day - often several times a day. We can do so through our chat room robot, which is the same place our CI results are displayed. We try to make the process of testing and shipping as simple as possible so that every employee feels comfortable doing it.

There are a number of advantages to deploying so regularly. If you deploy every few hours, it’s almost impossible to introduce large numbers of big bugs. Little issues can be introduced, but then they can be fixed and redeployed very quickly. Normally you would have to do a ‘hotfix’ or something outside of the normal process, but it’s simply part of our normal process - there is no difference in the GitHub flow between a hotfix and a very small feature.

PostCSS is a tool for transforming CSS with JS plugins. The growing ecosystem of PostCSS plugins can add vendor prefixes, support variables and mixins, transpile future CSS syntax, inline images, and more.

PostCSS is used by Google, Twitter, Alibaba, and Shopify. Its most popular plugin, Autoprefixer, is one of the most universally praised CSS processors available.

PostCSS can do the same work as preprocessors like Sass, Less, and Stylus. But PostCSS is modular, 4-40x faster, and much more powerful.

The hub subcommand for git, allows you to perform many of the operations made available by GitHub's v3 REST API, from the git commandline command.

You can fork, create, delete and modify repositories. You can get information about users, repositories and issues. You can star, watch and follow things, and find out who else is doing the same. The API is quite extensive. With this command you can do many of your day to day GitHub actions without needing a web browser.