Shields.io provides a large collection of badges that you can use in your project documentation (like README.md over at GitHub or BitBucket), which shows a variety of metrics for the project – latest version, number of downloads, build status, and more. Pretty much anything that you’ve seen used by any project on GitHub is supported (I couldn’t think of a badge that wasn’t).
Now, if only there was a way to insert these things automatically somehow …
GitHub added Open Source license descriptions. This is a tiny, but very useful feature, especially for those people who are not very well versed in the differences between GPL, MIT, BSD, and other licenses. I wish there was a way to have something like this proprietary applications. Maybe then people would pay attention to the end user license agreements (EULAs).
we’re launching the Open Source Guides, a collection of resources for individuals, communities, and companies who want to learn how to run and contribute to open source.
Open Source Guides are a series of short, approachable guides to help you participate more effectively in open source, whether it’s:
Finding users for your project
Making your first contribution
Managing large open source communities
Improving the workflow of your project
These guides aim to reflect the voice of the community and their years of wisdom and practice. We’ve focused on the topics we’ve heard about most, and curated stories from open source contributors across the web.
I think it’s a great idea and I really like the execution too. Most of what I know about Open Source comes from years of participation, and from reading old books, manuals and licenses – not something that is easy to share with people who are just getting their feet wet.
GitHub’s Open Source Guides are very simple, concise and specific. And they cover a variety of subjects, not just the legal or technical side of things, but also communications, support, marketing, etc.
GitHub to MySQL is a handy little app in PHP that pulls labels, milestones and issues from GitHub into your local MySQL database. This is useful for analysis and backup purposes.
There are a few example queries provided that show issues vs. pull requests, average number of days to merge a pull request over the past weeks, average number of pull requests open every day, and total number of issues.
I think this tool can be easily extended to pull other information from GitHub, such as release notes, projects, web hooks. Also, if you are using multiple version control services, such as BitBucket and GitLab, extending this tool can help with merging data from multiple sources and cross-referencing it with the company internal tools (bug trackers, support ticketing systems, CRM, etc).
This is not something I’ll be doing now, but I’m sure the future is not too far away.
composer-patches is a plugin for Composer which helps with applying patches to the installed dependencies. It supports patches from URLs, local files, and from other dependencies.
I think this is absolutely brilliant!
It’s quite often that one finds bugs and issues in external dependencies. Once the bug (or even the pull request with the fix) is submitted to the vendor, it can take anywhere from a few hours to a few weeks to be resolved and a new version to be released.
If you have a fix for the problem and need it in your project right away, and can’t wait until the vendor releases the new version, your best choice is to fork the dependency, fix the problem, and use your repository instead of the vendor’s package. This works, but it’s messy.
With the patches plugin to composer, you can still use the vendor’s package and just apply a patch with composer, until the new version is available. Clean and simple.
This also helps with testing things and working with different changes by different people, if you want to try things out – no need to choose between multiple repositories. Just select the patches that you want and apply them at the environment you need.
Given that most development work is happening on GitHub these days, this composer plugin is even more useful than what I might think at first. You see, GitHub provides patch and diff URL for each commit – all you need to do is add the extension to the URL. For example, take this recent commit to my dotfiles repository.
When put altogether, these bits allow one to have a fast (static content combined with HTTP 2 and top-level networking) and cheap (Jekyll, GitHub, Travis and Let’s Encrypt are free, with the rest of the services costing a few cents here and there) static website, with SSL and HTTP 2.
This is a classic example of how accessible and available is modern technology, if (and only if) you know what you are doing.
On a more technical note, I think this is also related to the explosion of editors and IDEs in the recent years, which, as good as they are, aren’t as good as Vim. Vim allows for a very flexible configuration, where your code can be formatted and re-formatted any way you like, making tabs or spaces a non-issue at all.
Regardless of the results of the study, what’s more interesting is the method and tools used. I’ve had my eye on the Google Big Query for a while now, but I’m too busy these days to give it a try. The article gives a few insights, into how awesome the tool is. 1.6 terabytes of data processed in 864.6 seconds:
That query took a relative long time since it involved joining a 190 million rows table with a 70 million rows one, and over 1.6 terabytes of contents. But don’t worry about having to run it, since I left the result publicly available at [fh-bigquery:github_extracts.contents_top_repos_top_langs].
Analyzing each line of 133 GBs of code in 16 seconds? That’s why I love BigQuery.
If you enjoyed this article, also have a look at “Analyzing GitHub issues and comments with BigQuery“, which works with a similar-sized data, trying to figure out how to write bug reports and pull request comments, so that they would be acted upon faster.