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).
Unfortunately it still counts external contributors as users in the account, which makes it too expensive for my organizations, but it’s good to see them trying.
GitHub blog is “Announcing Open Source Guides“:
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.
GitHub blog introduces Topics – a tagging/labeling mechanism for GitHub repositories, which makes searching by technology, topic, etc so much better.
This is a much welcome feature.
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.
So, this gives you a way of applying any commit on GitHub (and other repositories) via composer to any of your dependencies. This is mind blowing!
“S3 static site with SSL and automatic deploys using Travis” is a goldmine of all those simple technologies tied into a single knot for an impressive result. It has a bit of everything:
- Jekyll – simple, blog-aware, static sites engine, for managing content.
- GitHub – for version control of the site’s content and for triggering the deployment chain.
- Travis CI – for testing changes, building and deploying a new version.
- Amazon S3 – simple, cheap, web-enabled storage of static content.
- Amazon CloudFront – simple, cheap, geographically-distributed content delivery network (CDN).
- Amazon Route 53 – simple and cheap DNS hosting and domain management.
- Amazon IAM – identity and access management for the Amazon Web Services (AWS).
- Let’s Encrypt – free SSL/TLS certificate provider.
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.
Improvements to the code review
Approve or require changes
You’re no longer left on your own to figure out if a comment was important. Or if that emoji means “Go ahead, looks great!” Or “Please no, this is likely going to bring the site down!”
With Reviews, you can leave your comments as suggestions, approve the changes, or request additional changes—on any pull request.
Improvements to the GitHub Profile page
See what’s behind your green squares
GitHub profiles show your life and career as a developer. We’ve taken the contribution graph to new heights with your GitHub timeline—a snapshot of your most important triumphs and contributions.
But there is more – projects, notes, comment drafts, etc. Check the full announcement.
Here is an interesting bit of research – do people prefer tabs or spaces when programming the most popular languages?
Tabs or spaces. We are going to parse a billion files among 14 programming languages to decide which one is on top.
The results are not very surprising and somewhat disappointing (for all of us, tab fans):
As far as PHP goes, I’m sure the choice of spaces has to do with the PSR-2 coding style guide, which states:
Code MUST use 4 spaces for indenting, not tabs.
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.
Git 2.9 has been released a few days, bringing in some very useful functionality, such as showing renamed files in git diff and git log, forbidding the merge of two branches that have no common ancestors, configurable path to hooks, and more. All are welcome changes, making the life of a developer easier.
But what I found interesting is how two largest git companies – GitHub and BitBucket – reflect on it. Surely, the new release is important to both, but it’s insightful to see which features each of them looks at first. Have a look: