Zeal + Vim = offline CakePHP (and other) documentation

As any long time Vim user, I’m constantly looking for ways to tweak and improve my text editor configuration, and make me even more efficient.  Today, I came across a very handy addition – Zeal – an offline documentation browser for developers. (Thanks to this blog post, which also mentions Dash as an alternative for those of you on the MacOS.)

With Zeal, you can download a whole lot of documentation sets for pretty much any web development technology out there – programming languages, frameworks, libraries, tools, and more.  And then you can easily integrate Zeal with whatever text editor or IDE you are using.

For Vim, there are, as always, several options.  Some of them are listed here. I personally opted for the Zeavim plugin.  The installation is straight forward and everything works out of the box.  After giving a quick try, I decided to adjust my .vimrc file to use CakePHP framework documentation together with the PHP programming language documentation whenever I’m working with any PHP file.  Here’s what I had to add:

" Zeal offline documentation
let g:zv_file_types = {
       \ 'php': 'cakephp,php',
       \ }

Now, whenever I edit a PHP file and hit “,z” (I use comma as a leader, by the way), Zeal window pops up with the relevant documentation search.

It’s super fast. It works offline, and it’s awesome!

Slimming down Docker images

It’s been a while since I posted anything about Docker.  That’s mostly because I still don’t really use it for anything – playing around locally, testing and learning doesn’t count yet.

But just to keep the ball rolling, here are a couple of handy links for the ideas on how to improve your Docker images, so that Docker uses much less space, benefits more from caching, and brings up the containers faster:

Both articles are around the same theme – choose your  base image carefully, try to minimize the layers, use only what you need, and don’t forget to clean up the disk space with “docker system prune“.

This is why you shouldn’t interrupt a programmer

Yup.  This is exactly why you shouldn’t interrupt a programmer.  It takes him at least a few minutes to get back to where he was, irrelevant how brief and unimportant the interruption was.  And that’s why we invented managers (interrupt them all you want!), asynchronous communication (emails, ticketing systems, etc), and other tools and processes.

The most dangerous word in software development

I think this article – The Most Dangerous Word In Software Development – hits the nail on the head.

“Just” implies that all of the thinking behind a feature or system has been done. Even worse, it implies that all of the decisions that will have to be made in the course of development have already been discovered—and that’s never the case.

Every time somebody asks for “just” this little thing or that little thing, I ask them to “just describe it”, or “just answer a few questions”, or “just pay for it”.  Somehow, it never turns up as easy and simple in the opposite direction.