This is still working

$ sudo apt-get install cuetools shntool flac #install needed tools
$ cuebreakpoints sample.cue | shnsplit -o flac sample.flac #read breakpoints from cue and give them to splitter
$ cuetag sample.cue split-track*.flac #add tags to newly created files

Sometimes I need to write in russian using vim. The problem that arise is that normal mode in vim does not work with cyrillic, so I need to switch back and forth between US and RU layouts.

I encountered a problem with the Ubuntu inside Windows Subsystem for Linux. The problem is that windows C: drive is mounted with root user.

Run these commands inside the tmux session you want to change.

:rename-session <new-name>
:attach-session -t . -c <new-default-path>

I recently had to switch from Ubuntu to Windows on my workstation, but thankfully there is a Windows Subsystem for Linux now there and I decided to setup my tools in Ubuntu inside Windows. I will briefly describe the process and a solution for a small problem I encountered.

Another talk about Vim I gave at DevClub. Now it was about vimrc - options, mappings and abbreviations. Sorry, english-speaking friends, the talk is in Russian.

I have a problem. I keep constantly committing (and pushing) to wrong branches and then keep searching for how to move those commits to the right place. So I decided that bash prompt should remind me, what branch I am currently on. I need a scm tool name (because I use several) and a branch.

Yesterday I have released version 1.0.0 of my jenkins2 gem. It’s a API client and a command line application at the same time, that allows you to manage your Jenkins. And to be honest I am proud of the code I have pushed. Here is why:

Imagine you write a driver for Test Kitchen. It’s reasonable, if you want to check, if your driver is working before publishing it. But which approach to take? Building the gem and installing it locally, then manually trying to launch Test Kitchen with your driver, does not really feel the way to do it.

Having big Jenkins cluster requires monitoring many things. Lately we started saving information about what build ran on which machine and when. Jenkins actually provides that feature, this is called “Build history” and can be seen for the whole cluster or for some particular node. Unfortunately, when cluster is quite big (ours has more than 300 executors serving more than 10000 builds per day) Jenkins is not able to show the graph.