Robert Basic's blog

Search and replace in visual selection in Vim

by Robert Basic on January 23, 2017.

The search and replace feature is very powerful in Vim. Just do a :help :s to see all the things it can do.

One thing that always bothered me though, is that when I select something with visual, try to do a search and replace on it, Vim actually does it on the entire line, not just on the selection.

What the…? There must be a way to this, right?

Right. It’s the \%V atom.

Instead of doing :'<,'>s/foo/bar/g to replace foo with bar inside the selection, which will replace all foo occurences with bar on the entire line, the correct way is to use the \%V atom and do :'<,'>s/\%Vfoo/bar/g.

I’m using this approach in the HugoHelperLink fuction of my Vim Hugo Helper plugin.

Happy hackin’!

Tags: replace, search, vim.
Categories: Blablabla, Software.

XFCE4 desktop zooming with the keyboard

by Robert Basic on January 19, 2017.

XFCE4 has a zoom feature available when the desktop composition is turned on. By default, holding the Alt key and scrolling up or down the mouse wheel, I can zoom in or out the entire desktop. Once zoomed in, it follows the mouse pointer as to which part of the desktop to show.

I prefer doing as much as possible from my keyboard, and to use the mouse only when necessary.

I don’t care much for desktop composition, the transparent windows and animations are not my thing.

Toggle desktop composition

Given that desktop composition is required for the zooming feature, I want it enabled only when I want to use the zoom feature itself.

Using the following command, I can toggle the composition on and off:

xfconf-query --channel=xfwm4 --property=/general/use_compositing --type=bool --toggle

xdotool to fake the mouse

xdotool is a nice little program that fakes keyboard and mouse input, among other things.

Using that, running the following command from the terminal, zooms in:

xdotool keydown Alt click 4 keyup Alt

and this command zooms out:

xdotool keydown Alt click 5 keyup Alt

Just to make all this even easier, I put these commands in a couple of bash scripts and added them as keyboard shortcuts.

Now I have Super C to toggle the desktop composition, Alt + to zoom in and Alt - to zoom out.

Happy hackin’!

Tags: accessibility, compositing, desktop, keyboard, mouse, xfce4, zoom.
Categories: Blablabla, Software.

Force Python version in Vim

by Robert Basic on January 12, 2017.

Vim can be compiled with Python support. Vim can be compiled with both Python 2 and Python 3 support.

At the same time.

But not really.

Vim can have both of them, but use only one at a time. If you start using one version, there is no way to switch to the other one.

The silly thing is that if you simply ask Vim which version does it support, the first one asked and supported is going to be the one loaded and used. Trying to use the other one from that point will result in an error.

if has('python')
elif has('python3')
endif

Guess which one is loaded? Python 2.

Try calling Python 3 and ka-boom!

:py3 print('hello')
E836: This Vim cannot execute :py3 after using :python

Switch the order around:

if has('python3')
elif has('python')
endif

And now? Yup, Python 3.

Why is this ridiculous? Because if you have a bunch of Vim plugins loaded, the first one that asks for a specific Python version wins! Reorder the plugins and suddenly a different Python version is loaded.

Gotta love the software development world.

Luckily, this can also be used to fix the problem itself.

How?

Force one of the Python versions from the top of your .vimrc file:

if has('python3')
endif

Now you can have a little bit of sanity and be sure what Python version is Vim going to use. Of course, doing this might break plugins written solely for Python 2, so do it at your own risk.

Happy hackin’!

Tags: python, vim, vimrc.
Categories: Development, Software.

Things I learned in the past four years

by Robert Basic on December 30, 2016.

Since yesterday was my last day on a project after four years and two months, I decided to take a look back on those four years and write down some of the things I learned.

Things I learned about being a better listener, a better communicator, a better team mate, a better programmer.

Leave your ego at the door

This is probably one of the hardest and most important lessons I learned. I’m happy that I learned it early into the project.

Ego gets into the way of the actual programming. There is no place for it. People get defensive about their code, become deaf to advice, don’t take criticism well. This slows down the development process, makes communicating difficult, if not impossible.

Criticism of my code is not criticism of me. If I submit a pull request and the reviewer deems the code not fit for inclusion into the project, there is nothing to get upset about. The code needs improvement. If I know how, I’ll improve it, if not, I’ll ask for help how. It is much better and efficient than getting all protective about the code.

Don’t play the blame game

Joe wrote an excellent piece on the blame game more than 3 years ago.

Removing the blame from the entire process is liberating. When dealing with a problem, don’t focus on trying to find the person, or persons, responsible for the issue at hand, but try to understand what caused the problem, what is the best and fastest way to solve it, and how to prevent it from happening again in the future.

I know I was lucky to be working on a project where this blame game was not being played and that there are a lot of teams and companies where there’s a ton of office politics and everyone wants to survive… But that stuff really isn’t helping any one. If possible, at least try to not play it within your team, with your closest coworkers.

Take responsibility

Admitting to a mistake is hard. It’s scary.

Admitting first to myself that I’m not infallible, that mistakes happen makes taking responsibility a lot easier. And it becomes easier over time.

I believe that people tend to react positively to sincerity. Being honest and upfront that I made a mistake, saying sorry, goes a long way. Yes, the mistake might have repercussions, but I’m an adult and I stand by what I did.

Taking responsibility is the professional thing to do.

It’s OK to say I don’t know

I don’t know.

I’ve said it a lot. I’m still here, still alive, the world didn’t come to an end. No one punished me for it. The only thing that happened is that I learned new things I didn’t know before. And guess what? Learning new things is part of the job.

Saying “I don’t know, can you show me please?” is perfectly fine. If we ask for help, we will get it. People like helping.

Knowing the business domain is important

We, programmers, are a smart bunch of people. We solve problems for a living. Without knowing what is the actual problem the business is trying to solve and just waiting for others to give us a solution which we need to translate into code, takes away the problem solving for which we initially signed up for. The business will also miss out on properly utilizing the experience we gained so far.

Understanding the core domain makes it possible to give ideas, work together with other people (not necessarily programmers) to come up with better solutions. Everyone will benefit from this. The business gains by having yet another smart person helping out, and you by learning new things.

Not everything we learn need to be exclusively about code.

Ask why?

This goes hand in hand with knowing the business domain.

Keep asking why. Why is some new feature being implemented, why do they need it? If you are joining a project that is being developed for some time, ask why were some things done in a certain way. It will both make learning the business domain easier and faster and it will also help with getting to know the codebase.

Asking why shows the business owners that you care, and caring about the same things as they do will only be helpful during the project’s lifetime. They will provide help and explanations much easier.

Onto new adventures

Working on this huge project for this long is something I’m truly grateful for. Not everyone gets an opportunity like this, especially this early in their professional career.

I learned a lot from my friend, partner and mentor, Srdjan, as well as from Luka who joined our small team recently.

I’m certain the new year will bring us exciting new challenges. If you have, or know of a project where the three of us could help out, let us know.

The Code4Hire team is here to help.

Tags: about, learning, me, random.
Categories: Blablabla, Development, Programming.

Issues with Vagrant after upgrading to Fedora 25

by Robert Basic on December 24, 2016.

Fedora 25 was released over a month ago, so I decided it was time to upgrade from 24.

Using the dnf plugin system-upgrade the entire process went smooth. The Fedora Magazine, as always, has a nice post on how to upgrade.

So far I ran into only a couple of minor issues with Vagrant.

The first one, which isn’t really a problem, is that Vagrant got downgroaded to version 1.8.x from 1.9.1 which I had installed in Fedora 24. The fix for that is easy, just install the new version again:

robert@odin ~$ sudo dnf install ~/Downloads/vagrant_1.9.1_x86_64.rpm

The second issue was that, well, vagrant didn’t really want to work. When trying to run vagrant up it would spit out the usual kernel module is not loaded error.

The provider 'virtualbox' that was requested to back the machine
'default' is reporting that it isn't usable on this system. The
reason is shown below:

VirtualBox is complaining that the kernel module is not loaded. Please
run `VBoxManage --version` or open the VirtualBox GUI to see the error
message which should contain instructions on how to fix this error.

Running VBoxManage --version provided a helpful message, for once:

robert@odin ~$ VBoxManage --version
WARNING: The vboxdrv kernel module is not loaded. Either there is no module
         available for the current kernel (4.8.15-300.fc25.x86_64) or it failed to
         load. Please try load the kernel module by executing as root

           dnf install akmod-VirtualBox kernel-devel-4.8.15-300.fc25.x86_64
           akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service

         You will not be able to start VMs until this problem is fixed.
5.1.10r112026

Looking at the list of installed packages with dnf list installed I saw that both the akmod-VirtualBox and the kernel-devel packages are installed.

Running the next command fixed the issue:

robert@odin ~$ akmods --kernels 4.8.15-300.fc25.x86_64 && systemctl restart systemd-modules-load.service
Checking kmods exist for 4.8.15-300.fc25.x86_64            [  OK  ]

VBoxManage shows no warnings any more:

robert@odin ~$ VBoxManage --version
5.1.10r112026

and Vagrant works just fine again.

Happy hackin’!

Tags: akmod, fedora, vagrant, vboxmanage, virtualbox.
Categories: Development, Software.