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.

With every year that passed, as Perl 6 produced more press releases than actual code, the attractiveness of Perl as a platform declined. Sure, it still had users. Sure, it still had people starting new projects. (The Modern Perl movement was a decent attempt to bring wider enthusiasm back into the ecosystem by dispelling some of the worst myths of the language. It modeled itself after JavaScript: The Good Parts without realizing that Perl lacked JavaScript's insurmountable advantage of ubiquity. Who could have predicted that Objective-C would be interesting again a year before the iPhone came out?)

What it didn't have was a clearly defined future, let alone an articulated one.

We have broken HTTP. We’ve done it for years in fits and starts, but apps have completely broken it. HTTP was a good specification which we’ve steadily whittled away.

URLs have a purpose. We are very cavalier about that purpose. We don’t use canonicals. We’re sloppy about switching back and forth between HTTP and HTTPs. We don’t bother to logically structure our URLs. We rebuild websites and let all the links break. We don’t appreciate that crawlers are dumb and they need more context than humans.

The author goes on to complain about the misuse of HTTP methods and status codes as if he had never heard of REST APIs. Overall, though, he makes some good points.