Disclaimer: I am not advocating any specific tools or methodologies, but sharing a workflow I find to be efficient and pleasant.

I am a huge fan of working with CLI applications. I use Vim for editing code, composing emails, and various kinds of writing. When I have to manipulate huge amounts of email, I use Mutt: it’s intuitive tagging and regular expression engine are extremely useful for the task. I employ ack, awk, grep, and sed - Linux utilities which allow for precise and fast text manipulation.

However, I would not use CLI browsers like elinks or w3m, and the idea of reading every email in Mutt gives me the creeps. I love the visualization web browser offers, something text-based prompt is not able to provide. And it doesn’t have to.

There are two components to most of the tasks performed on a computer: analyzing output and entering input. Certain tasks employ one component more than the other. In most modern applications it’s rare to have both solid control from the user perspective and a pleasant informative UI. With increased visual component, it’s more time consuming to make the application do what you need, especially if your needs are esoteric. With more editing power, visual display becomes less complex in order to make editing tasks easier.

Where visual tools fall short

What is the alternative? Using multiple programs with different levels of control to accomplish one task: to edit text. Each of the programs excels in it’s own field: word processing software allows for beautiful fonts and document presentation, IDE lets you access aggregated meta information about your application. But most of the IDEs and word processors lack the powerful tools needed to manipulate the foundation of what user is working with - plain text.

Ode to plain text

I spend a lot of time writing and editing plain text. Be it source code, emails, documentation, or even blog posts. These tasks take up significant amount of my day, and it is only logical to substitute some of the visual presentation capabilities for effectiveness.

It is hard to mentally process data which is not explicitly and unambiguously visible: different levels of headings, hidden meta information. Unlike more obscuring formats, plain text is all there is - it has nothing to hide. If you don’t see it - it’s not there. If you do see it - you know exactly what it is.

One of my favorite tips from “Pragmatic Programmer” goes:

Use a single editor well

So I learned one editor well, and now I use it for all my writing and editing needs. I don’t have to jump between IDE, browser, and office software. Most of the text I edit is manipulated with one editor. There is only one set of key bindings to know, one skill to master and hone. Fast, without any additional thought, using single text editor and all of it’s powerful features is imprinted in muscle memory. One less task to worry about.

I write my documents in Markdown format, and later convert them to the desired output using pandoc: be it an HTML page, PDF, or a Microsoft Word document. I use Vim, so I can rearrange paragraphs or manipulate lines within a couple of keystrokes. Since I spend so much time editing text, I also touch type, which makes me even more effective at the given task.

Harness the power of the command line

When it comes to bulk manipulating files or working with version control - there is no better candidate then command line applications. There’s no need to go through a number of obscure menus, ticking and unticking checkboxes, and hoping that your desired result can be achieved with a program’s GUI.

Let’s look at a few scenarios some users face in their daily workflow.

Creating a backup

With GUI, you’d have to take multiple steps:

1. Right click file.
2. Left click on “Copy”.
3. Right click on some empty space.
4. Left click on “Paste”.
5. Right click on a newly created copy.
6. Left click on “Rename”.
7. Switch to a keyboard.
8. Type file.bak.

The above steps can be sped up using shortcuts like C-c or C-v, but not by much. Here’s an alternative in bash:

cp file{,.bak}

While first variant would do great for a novice or a casual user - the second method would be much more preferred by an experienced user whose concern is speed.

Recursively bulk replacing text in a directory

Let’s assume we want to do a bulk replace text in a directory and all it’s subdirectories. We have our trusted IDE, let’s assume this IDE is already configured to work with a desired directory.

1. Open your IDE.
2. Select “Edit” menu.
3. Select “Find and Replace” submenu.
4. Click on a “Find” input field.
5. Switch to a keyboard.
6. Type function_to_replace.
7. Switch to a mouse.
8. Click on “Replace” input field.
9. Switch to a keyboard.
10. Type new_function_name.
11. Switch to a mouse.
12. Enable “Search in subdirectories” checkbox.
13. Click “OK”.

Again, this can be shortened a bit with some keyboard shortcuts, but not by much. You still have to switch between keyboard and a mouse a total of 4 times, and you still have to click through all the menus. This does get time consuming if you do this often. Now let’s try to perform the same task in command line:

find . -type f | xargs sed -i 's/function_to_replace/new_function_name/g'

Much faster, if you’re able to memorize the structure. And remembering what the commands do is much easier than it looks. Especially with the help of man or, even better, bro (see http://bropages.org for latter).

The above example demonstrates one of the biggest advantages of command line interfaces: an ability to redirect an output of one program into another, chaining the tools together. In this example, we first get a list of all files use find tool, and then run sed tool on each of those files in order to replace the text.

An output from any CLI tool can be fed into any other CLI tool. This allows for countless possibilities and high adaptability to unscripted scenarios.

Is it worth learning CLI tools over their GUI counterparts?

This depends on what your intentions are. If you’re a power user who writes and edits a lot of text or manipulates bulk amounts of text on a daily basis - than it’s definitely worth it. Time spent learning these tools will pay off. But if you’re a casual user whose needs end with writing an occasional email or two - then you probably don’t need to worry about this.

Hell, if you’ve read this far - this means you’re the former case. I can practically guarantee that you will benefit from employing command line tools and modal editors over their GUI counterparts.

I’ve put together a table for comparison between two. Indeed, there are different times when either GUI or CLI tools excel:

As you can see - both CLI and GUI programs have their pluses and minuses. CLI tools seem to appeal to experienced users, while GUI tools are great for novice users and do excel in representing visual information. No matter what kind of interface you prefer, it’s crucially important to use the right tool for the job.

I got myself into a habit of using vimwiki for the past year: it helps me to keep track of random bits of information, work and project notes, as well as daily goals and achievements. You can read more about vimwiki in an article I wrote a while back: “Personal wiki with vimwiki”.

One of vimwiki’s features I really like is an ability to convert whole wiki to HTML with a single command: :VimwikiAll2HTML. There is one annoyance though: HTML vimwiki pages don’t have any navigation elements: the only way to navigate between pages is by clicking through links within a page or using browser’s “back” button.

Luckily, vimwiki has a setting which allows using custom templates for generating HTML. Assuming your wiki is in $HOME/Dropbox/wiki (can be anywhere else though), make following changes to your .vimrc:

let g:vimwiki_list = [{
  \ 'path': '$HOME/Dropbox/wiki',
  \ 'template_path': '$HOME/Dropbox/wiki/templates',
  \ 'template_default': 'default',
  \ 'template_ext': '.html'}]

After that, create a $HOME/Dropbox/wiki/templates/default.html using vimwiki/autoload/vimwiki/default.tpl as a base. I added simple navigation bar to my default template:

<html>
<head>
	<link rel="Stylesheet" type="text/css" href="%root_path%style.css" />
	<title>%title%</title>
	<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
</head>
<body>
	<a href="%root_path%index.html">Index</a> |
	<a href="%root_path%diary/diary.html">Diary</a>
	<hr>
	<div class="content">
	%content%
	</div>
</body>
</html>

Now it’s much easier to jump between wiki entries. Of course, customization doesn’t end there: you can change styles, add JavaScript and make your wiki all fancy and advanced.

If you’d like to get even better about using Vim, I wrote a book about it: Mastering Vim. I’m pretty proud of how it turned out, and I hope you like it too.

I had to download my Octopress blog to a new machine today and the process of setting up didn’t go as smoothly as I expected. At the end of the day the setup turned out to be simple, and here are the steps:

git clone -b source https://github.com/username/username.github.io myblog
cd myblog
git clone https://github.com/username/username.github.io _deploy
bundle install

In a nutshell, you have to manually add _deploy folder set to track master branch of your Octopress repository. Otherwise rake deploy command fails.

Happy writing!

I’ve had increased interest in writing throughout this year. In addition to being a pleasant and fulfilling activity, it shown a number of benefits in my everyday life and career:

• Composing emails became faster and easier. When you have to reply to a couple of dozen emails a day, speed and attention to details matters. Writing more taught me to write more concise emails which are easy to read.
• Writing a lot isn’t a problem anymore. If I have to write documentation, comment code, or just put together a very long email - I’m not put off by the idea. I’m excited about it.
• Typing speed went up. I already touch type, and constant writing practice increases the acquired speed. Fast typing makes life easier, speeding up mundane tasks, freeing up brain power for more costly activities.
• It’s easy to keep a condensed work log to highlight the issues of the day. Tough programming issues, “Eureka!” moments, meeting notes - this historical data saved me hours or even days of repeating my mistakes.

A while ago, I’ve heard of a thing called “750 words”, a site built around a challenge to write 750 words a day in order to improve writing skills and unleash creativity. This looked like a great idea, and I decided to give it a shot. I prefer to keep my personal entries offline, and I decided not to use the provided service, but to keep a set of plain text files on my local machine. Which worked out just fine. It’s all just text after all.

I lasted for 10 days in a row, which I am proud of (filling up approximately 3 pages a day was no easy task for me). I started of with silly entries about not knowing what to write about, and finished with a piece of a fiction story. That’s a considerable improvement.

By the end of the challenge I was mentally exhausted. But it taught me a very important lesson: the more you write, the better you become. And that’s one of the main reasons I keep crafting new entries for this blog.

This happened half a year ago, I just never got around to writing about it. I will go ahead and start another 750 words spree today. Maybe this time I’ll be able to make it last for the whole month.

I search for things a lot, especially in my code. Or even worse - someone else’s code. For years grep served as an amazing tool for this: fast, simple, and yet powerful. That was until I discovered ack for myself. An incredibly easy to use grep implementation built to work with large (or not really) code trees.

A lot can be said to enforce superiority of ack over grep when it comes to working with code, and it’s all said here: ack’s features.

Amazing thing is - ack doesn’t even need a tutorial. Learning progression is natural and “just happens” by researching necessary use cases as the need arises (ack has a great manual entry).

Here’s a typical use example for ack:

ack --shell 'gr[ae]y'

Searches all shell script files in the current code tree for any occurrences of “gray” or “grey”. It will search .sh, .zsh, and just about dot-anything; ack will even check shebang lines for you.

Ease of use, the fact that it’s ready to use out of the box, extensive file types, native support for Perl’s regular expressions: ack does really good job at searching through code.

Download it from Beyond grep.