The Ultimate Plumber, or up for short, is an excellent interactive tool for anyone who is building complex command sequences for processing text on the Linux command line. If you are a frequent user of grep, sort, cut, awk, sed, and other similar commands, have a look at this demo. I’m sure up will save a tonne of time once you get a hang of it.
Category: Linux
Linux is my primary operating system. I used it on the servers, desktops, laptops, netbooks, and even mobile phones since approximately 1997. I’ve tried a number of distributions over the years, and even created a couple myself. I still look around sometimes to see what others are up to. But most of my machines are running some sort of Red Hat – either a quick and easy Fedora Linux, or a stable and secure Red Hat Enterprise Server, or a cheaper CentOS alternative.
And while by now I am very comfortable in the Linux environment (both graphical and command line), I still discover a lot of new and interesting things about it. When I come across something worthy, I usually share it with the rest of the Open Software world, using this category.
The Illustrated TLS Connection
“The Illustrated TLS Connection” is an interactive guide to the TLS connection, explaining every byte with code, comments, annotations, and more. If you ever wanted to know the details of how this works, I can’t think of a better resource to direct you to. And if you find any issues or can suggest a better explanation, there’s a GitHub repository for you to contribute.
Go Monorepo
As a maintainer and contributor to multiple, and often related, git repositories, I often find myself thinking that there must be a simpler way.
Consider, for example, a variety of CakePHP plugins that we develop and maintain at work. Sure, each one provides a completely separate bit of functionality and has its purpose as a standalone project. But, at the same time, they all have enough overlap that we use a common cakephp-plugin-template repository to keep things in sync, and also require cakephp-utils plugin from all of them.
It’s only natural to consider other ways of doing things. Sure, I tried git submodules before, but they don’t quite cut it. Something is still missing.
Today I came across the Go Monorepo website. Which makes me wonder even further down this road. There are also a few other tools and alternatives mentioned in this article.
That’s not something that I’ll jump into right now, but it’s definitely something I’ll consider to try out in the nearest future.
AnsibleFest Austin 2018 via Jeff Geerling
If you missed the opportunity to attend the recent AnsibleFest Austin 2018 event, here are a couple of interesting links for you, via Jeff Geerling’s blog (aka geerlingguy):
- AnsibleFest 2018 is a Wrap! Slides from my presentation and notes, which links to the slides of the talk that Jeff did.
- Things I learned at the AnsibleFest Austin 2018 Contributor’s Summit, which links to a whole bunch of Ansible tools.
There’s plenty of stuff to play with over the next weekend or two.
Highlights from Git 2.19 and PHP syntax
GitHub blog covers the highlights from Git 2.19, which was recently released.
One particular change that I want to highlight (which GitHub skipped in their highlights, but which exists in the Git release notes for this version) is the syntax pattern update for the PHP files.
Let’s have a look at the full diff of this release. The particular change I am referring to is in the userdiff.c file. Git now understands final, abstract, interface, and trait keywords.
If you are not sure where and how it is used, here are a couple of useful links for you:
- .gitattributes documentation section on settings the syntax of the file for diffs. Basically, you just need to add “*.php diff=php” to the .gitattributes file. Unfortunately, this is done on a per-project level, rather than globally on a user level. (See this blog post for more details).
- More info on the same subject: How Does Git Know What Functions Look Like?
Now that you have it all configured, there are a couple of ways to benefit from this functionality. First, you’ll see a more useful context comment in the diffs. Here’s the screenshot (using an older git version still). On the left, the diff without the PHP syntax configured, and on the right is the diff with the PHP syntax configured:
As you can see, on the left, the context shows that the change was done somewhere in the ChangeLogTrait trait. On the right, the context is much more specific – it shows that the change was done in the public function changelog.
This makes reviewing code changes a lot easier. But there is also one other place where this is useful – in reviewing the history of a particular function. For example, running “git log -L :changelog:ChangelogTrait.php” will produce the git log output containing only the commits and diffs on the function changelog in the file ChangelogTrait.php. Very handy!