Yesterday I found a typo in a pull request description while browsing another team’s project which I stumbled upon. I mentioned it to the author but it turned out that that part of the text came from the repository’s pull request template, which means every pull request will have this amusing but irritating mistake. I sent them a pull request, modifying the template, to fix the mistake at the source and avoid it in future, and thought that would be the end of it.
It turns out that template was written once and then copied across to new repos, which means this typo actually exists in almost all the pull requests in all of that team’s projects. Well that escalated quickly. This is the point where the average person probably says “OK whatever, it’s not worth it for something so small, there are too many repos, it’s just a small typo, never mind” and stop. A very determined person might actually start opening browser tabs and psyching themselves up to do pull requests. I open my terminal emulator and start writing a for loop. Continue reading
I’ve decided to give Wakatime a second try. It’s a tool that tracks the time you spend programming on different projects by integrating into your IDE. This works well for typical development work where you open your IDE in the morning and type code in it, do commits with it, and everything else related to the project and Wakatime will track that.
I don’t work like that though, so I had two issues with it last time, both resulting in a lower reported time spent working:
- I spent most of the day working on different remote servers and it would be a hassle to set it up in the text editor on each of them and it would undoubtedly cause slowdown on the older servers
- I use the command line tools as my IDE, so the time recorded opening the text editor to make some changes is not representative of the time spent working
This time it’s different because nowadays I virtualise most of the services I work with, using Docker on my local machine, and I’m hoping that using the Wakatime Z Shell integration will give a better record of time spent working on a project. Continue reading
Now that I’ve got steam, I get to be constantly pestered by e-mails sending me keys with which to identify that I am myself. To save a few steps in this annoying, repetitive process I wrote a tiny bash script which finds the key in an e-mail from steam and uses zenity to pop it up on my screen, then added a filter in Evolution Mail to mark these “steam verification” messages as read and pipe them to the pop-up script. This allows me to copy the key with a double-click and paste it into steam with a middle-click, without having to poke around in my mail client for the e-mail and the place where the key is mentioned in it.
In the hope that it saves someone else from this irksomeness, here’s the code for the script:
# Displays a pop-up showing a Steam activation key piped to it by a MUA.
# In the e-mail the steam key is wrapped in <h2> tags
# Author: Sion Le Roux <firstname.lastname@example.org>
# read e-mail from pipe
while read -r line; do
# find <h2>
buffer=$(echo $line | grep 'h2')
if [[ ! -z $buffer ]]; then
#strip surrounding <h2> tags
steamkey=$(echo $buffer | sed -e 's/<\/\?h2>//g')
# display the steam code in a pop-up
zenity --info --title="Steam Key" \
The wiki-like note taking application, Tomboy, maintains a list of user-written add-ins on its website, almost none of which were available in the Arch Linux repositories. Recently I learnt how packages are created for Arch Linux and read up on the standards, so I ‘adopted’ an ownerless add-in package from the Arch Linux User Repository and packaged 6 more.
Finally, I created a meta-package called tomboy-extras which contains nothing but depends on all the working Tomboy add-ins (tested on my laptop) in the AUR, to easily install all add-ins at once. I created a gist on GitHub for each package’s build script and made a repository containing the meta-package’s PKGBUILD file and each gist as a git sub-module named after the package name. The README file in tomboy-extras’ git repository contains links to the gists for the add-ins’ PKGBUILDs so that they can be found easily.
So, if you would like to contribute to one of them, feel free to fork the relevant gist, or leave a comment there, and if you would like to contribute to tomboy-extras itself or have an add-in included, just fork tomboy-extras and send a pull request; I’ll probably be adding more add-ins to it myself already. Also, if you do use any of these packages, please give them a vote on AUR so that we can see how many people use them. If they’re popular, they may be included in the official repositories, who knows!
Recently I did a friend a favour and installed Linux Mint on her laptop as she was a bit frustrated with Windows. Unfortunately I assumed she’d backed up everything before handing it over to me, so I re-partitioned the whole drive to ext4. She hadn’t.
On the bright side the computer was quite new and the only thing she wanted from the disk were some photos she’d taken. Well, that just made it my lucky day because there just happens to be a tool specifically for recovering photos (and a myriad of other filetypes) from disks that have been written over: TestDisk
❗ Note: automated script downloadable at the bottom of this post!
Something you always want to do on a computer, even if only once, is to check its hardware specifications, that is:
- how much RAM do I have?
- how much hard disk space do I have?
- how “fast” is my CPU?
- how much RAM does my graphics card have?
Of course most modern GNU/Linux desktop environments like Ubuntu usually come with some kind of graphical tool to find this information. GNOME’s System Monitor program should provide at least some of what you’re looking for. The information here is more for when you’re staring at a blinking cursor on a black screen trying to remember what the command was to show information about the CPU, RAM or Graphics Card.
This is the third time I’ve had to go on an internet search quest to remind myself how to do this in a Linux terminal. To save myself the trouble in the future, I’m writing down the commands here and if anyone else finds it useful then that’s great, and a second bird is figuratively killed!