O’Reilly is giving away some programming ebooks for free. Not the greatest of selections, but might still come handy, as subjects vary from Java and Python to micro-services and software architecture. The books are available in ePub, Mobi, and PDF, but you’ll need to register / login to download them.
- Asynchronous I/O support, channels, JSON
- Partials, Lambdas and Closures
- New style testing
- Viminfo merged by timestamp
- GTK+ 3 support
- MS-Windows DirectX support
For a more complete list and details, have a look here.
The TL;DR summary: Vim provides a lot more power now to plugin developers, so we’ll be seeing a boost in both new functionality and old ways getting better.
Here is a mandatory Slashdot discussion with your usual Vim vs. Emacs flame.
P.S.: Emacs has recently released a major update too …
Here is a good Open Source story – “How Google Uses and Contributes to Open Source“, which goes into some detail and history of how Google is working with Open Source community.
I’ve seen this before:
“There are companies and people who just take the software and say, “I didn’t have to pay for it. I can do anything I want. The license file is a big blob of text. I’m not going to read that,” Merlin said.
And I’ve this (quite a few times actually):
Back in its early days, around 1998, Google was a small company. It was using open source just like any other small company. While Google was abiding by licences, they were not giving back much due to several reasons. “Some of it was just run fast and make sure that we have money next month to pay everyone’s salary,” said Merlin.
Having been involved in open sourcing companies’ projects new and old, this is what I firmly believe now is the best strategy:
Go open source from the beginning
Google changed that by writing a lot of things from the ground up as open source or to be open source ready. That was a good lesson that they learned, and that’s a problem many companies face when they want to open source their stuff but can’t because the code was not designed to be open source from the beginning.
This, I think, is an interesting approach too (if you are too small of a company to have research papers and algorithms, consider blog posts, tips and tweaks, case studies, and the like):
Even if Google can’t open source certain code, they found a way to bring that work to the public. “We wrote papers talking about the magic algorithm that we used. We can’t give you the code for the reason I just explained, but we’re giving you the way they work so you can rewrite them,” said Merlin. Google has published hundreds of such papers and people are using it to create projects based on those ideas.
This bit on Android is mind blowing:
Now virtually all of Google’s open source code is on GitHub, except for Android. “The Android distribution is so big and it gets released in big chunks. So, when it gets released, everyone wants to sync that,” Merlin said. “It’s so huge that if we put it on GitHub, it would completely kill GitHub. We use our own mirrors for that, to help out.”
A word of caution for the companies using Open Source software:
Companies have to be extremely careful when using open source. Different projects use different licenses, and you need to be in compliance with them.
Things become complicated when you have projects that you ship. In the case of open source, you need to list the projects that you use and their licenses. In the case of BSD and MIT, you need to list the name and the copyright of the person you got that project from.
You’ll probably need a set of tools to deal with issues like this. For PHP-based projects, composer is indispensable. You can run “composer licenses” command and instantly get information about the project’s license, as well as licenses for each and every dependency in use (thanks to this blog post).
There is a good section on Contributor License Agreements (CLAs). I am slightly familiar with the subject (I signed a few myself), but my experience is limited, especially from the company perspective. I found this part useful, for that distant time when I’ll need to set it up:
Google uses the Apache foundation ICLA, without modifying it or putting anything special in it. CLAs ensure that companies like Google “can re-license your code under a different open source (license) if we need to. Sometimes we need to merge with other projects and that’s what the CLA allows us to do,” said Merlin.
These are just bits and pieces which I found interesting. I wish more companies shared their practices and experiences – in particular those larger businesses, with years of history and a wide variety of challenges.
“FSF [Free Software Foundation] and I don’t have a loving relationship, but I love GPL v2,” said Torvalds. “I really think the license has been one of the defining factors in the success of Linux because it enforced that you have to give back, which meant that the fragmentation has never been something that has been viable from a technical standpoint.”
“The GPL ensures that nobody is ever going to take advantage of your code. It will remain free and nobody can take that away from you. I think that’s a big deal for community management.”
“Please don’t use Slack for FOSS projects” is a compelling case for why you shouldn’t use Slack for Free and Open Source Software projects. Make sure to read the discussion in the comments as well. (By the way, many of the arguments apply to HipChat too).
The suggested alternative is IRC, which I agree with. My only minor disagreement in regards to IRC is using it for companies as well. Companies are much more fragile and sensitive than Open Source community, so it doesn’t work all that well in some places. I think Slack/HipChat work great for company communications, but if you want to have full control over your chat system, then try out Rocket.Chat, which I blogged about earlier this year.
I’ve been a big fan of Amazon AWS for over two years now. One thing that absolutely blows me away is how much activity there is in Amazon AWS development. Every day there is an announcement of a new services or updates to the existing ones. In order to help people keep up with all the updates, Jeff Barr of Amazon was blogging “AWS Week in Review” for a few years.
Now, imagine this – there is so much new stuff going on that it takes hours to prepare each of those blog posts:
Unfortunately, finding, saving, and filtering links, and then generating these posts grew to take a substantial amount of time. I reluctantly stopped writing new posts early this year after spending about 4 hours on the post for the week of April 25th.
This is insane! So he almost gave up on the idea, as it is too time consuming. But people want it. What’s the solution? Go Open Source!
The AWS Week in Review is now a GitHub project (https://github.com/aws/aws-week-in-review). I am inviting contributors (AWS fans, users, bloggers, and partners) to contribute.
Every Monday morning I will review and accept pull requests for the previous week, aiming to publish the Week in Review by 10 AM PT. In order to keep the posts focused and highly valuable, I will approve pull requests only if they meet our guidelines for style and content.
At that time I will also create a file for the week to come, so that you can populate it as you discover new and relevant content.
I think that’s a brilliant move. Those weekly review posts are super useful for anyone involved with Amazon AWS. They should keep coming. But the time cost involved is understandable. So crowd-sourcing this is a smart way to go about it.
I hope this will not only continue the blog post series, but also take it to the new level, with more section, content, and insight.
GitHub blog says that from now on your profile can include the private repository contributions on your profile.
When enabled, these can make quite a difference in the number of the green boxes, showing your GitHub activity. Here’s an example from mine. Before enabling those, showing only Open Source contributions:
And here’s one after, including private repository contributions:
Indeed, it is a more accurate representation of my GitHub activity. Given that these days most of my private repository activity happens on BitBucket and not on GitHub, this is quite surprising.
- 58% of packages include a src/ directory and 5% a lib/ one. That’s surprisingly low to me, that means a lot have the code simply in the root folder.
- 4% have a bin/ directory, including some sort of CLI executables.
- 55% have a LICENSE file, that’s.. pretty disastrous but hopefully a lot of those that don’t at least indicate in the README and composer.json
- 49% have some file or directory indicating the presence of tests (phpunit.xml & co). I am not sure if this is good or bad news to be honest, that depends on your expectations.
I knew this would happen for a long time. I knew it happened. But even if that’s nothing new, it’s still nice to hear – “Linux and open source have won, get over it“:
In 2015, Microsoft embraced Linux, Apple open-sourced its newest, hottest programming language, and the cloud couldn’t run without Linux and open-source software. So, why can’t people accept that Linux and open source have won the software wars?
This is a huge and import change in technology, which has major affect on the rest of the world. It’s nice to know that I’ve played a small part in that.
For those people who think Gimp is the only image editor on Linux, here’s darktable 2.0. I mentioned it briefly before, but never linked to it. Linux Weekly News has reviewed the release candidate recently. Have a look at the features page – it’s quite extensive. If you are more of a visual person, there here are a few screenshots.