How do I write the date to a file in Vim?

I keep a journal at work – you should too, if you’re a software developer. I decided to start adding date and time stamps so I don’t have to think. It’s really easy to do in Vim*, just type this in normal mode:

:r !date

and hit Enter. BOOM the date appears on the next line.

If you’d like a bit more detail on why this works run :help :r, or read the rest of this post. The “r” is short for read and generally means “read from another file”.

It can also read the output of a command. Since you can run external commands in Vim by putting an exclamation mark in front of them, you can do things like :r !pwd to litter your current file with /Users/josh/journal/hopes_and_dreams and the like.

Have fun!


* In Linux-based systems that have the date command at least.

How Do I Write Good CSS?

That’s been the question on my mind ever since I tried to write some CSS and it was terrible! Here are some of the things I’ve been reading.

Maintainable CSS – a guide to using semantic HTML, combined with not trying to write reusable CSS, in order to make modular styles that can be edited without causing problems elsewhere.

Learn Layout – a very clear tutorial on how to position elements on a page.

BEM Key Concepts – I’ve been starting to get my head round BEM (Block, Element, Modifier) as a way of organising styles. This ties in well with the Maintainable CSS piece, above.

.bashrc is your scout badges

In the Scouts you get badges for the things you learn, and you show them off by wearing them on your sleeve, once a parent has stitched them on.

Lately I’ve started curating aliases in bashrc. For anyone who hasn’t used it, it’s a file in which you can store settings for controlling your computer, including abbreviated versions of commands you use a lot (aliases). Some people like to share these files, or snippets from them, to give other programmers ideas for which shortcuts to include in their own collection.

The nature of the file lends itself well to this sharing. You do the work of learning some new command, practise using it until it is part of your everyday toolkit, and then make a shorter reference to it. These references become a list of what you know and can do, and a neat little resume of your command line experience.

Vim in Atom

I installed Atom today as I needed some kind of IDE without forking over a lot of money, or spending time on configuring something. This meant trusting the claim that it works straight out of the box.

Later as I considered whether or not I would use it beyond the one task I needed it for, I googled “vim in atom”. This made me realise that I’ve become acclimatised to Vim to the point that I want its functionality in anything I use, and also begin to wonder why I didn’t just stick to using “vim in vim“.

Luckily, the search results page contained answers to both of these questions.

Why do I use Vim? Partly to score NeckbeardHacker kudos from Unix greybeards, but mainly because it allows you to compose commands so neatly from smaller “words”, as discussed in Why Atom Can’t Replace Vim by Mike Kozlowski. Having become used to hitting commands for “delete three words” (d3w) and suchlike, it’s hardly desirable to go back to Ctrl+This+That shortcuts.

But I’m not a Vim power-user, and as such I want more. Thus, my second question; why don’t I just use vanilla Vim? It lacks a shiny GUI, with lovely nested directory trees, and the plays-well-with-others style of a typical modern IDE. And so I’m waiting for a suitable neovim, or until then, Vim in Atom.

On specifications that can generate code

One might argue that a book about code is somehow behind the times—that code is no longer the issue; that we should be concerned about models and requirements instead. Indeed some have suggested that we are close to the end of code. That soon all code will be generated instead of written. That programmers simply won’t be needed because business people will generate programs from specifications.

Nonsense! We will never be rid of code, because code represents the details of the requirements. At some level those details cannot be ignored or abstracted; they have to be specified. And specifying requirements in such detail that a machine can execute them is programming. Such a specification is code.

From Clean Code, Robert C. Martin.