To be honest, I was never that fond of that particular extension for a variety of reasons. One of my chief gripes with it is directly related to the way it looks. Powerline uses non-standard patched fonts in order to achieve that segmented look which is not something Vim supports natively. Without them the extension looses a lot if it’s sex-appeal and starts looking a bit plain. To configure it, you don’t just add entries to your .vimrc but instead you need to create a separate dot-folder where it’s settings files are kept. While this neatly separates the Powerline setup from general Vim settings it also adds maintenance headaches. I like to keep all my Vim related config files in a single directory under source control so you can imagine this is less than optimal.

Finally, I have never really felt like I would use any of it’s advanced features. Most of the power-line setups I see on screenshots and in screen-casts are very basic: mode indcation, file path, some file and cursor position info. All of that can be easily set up in just a few lines of VimL. Powerline on the other hand is a monstrous semi-framework that can let you do really frivolous and complex things. For example, it has support for hooking into your power management module by the way of python and displaying battery status in Vim. It can also pull weather notifications from the web and display them in your status line… Though why would you ever want that is beyond me.

It is really a nice an powerful plugin, but it doesn’t seem like something I would necessarily need. For years I have been pretty happy using a very simple status line with just the name of the file and some positioning info along side the excellent Obvious-Mode plugin. It covered most of my needs – my status line would be red in insert mode, gray/cyan in normal mode, depending on whether or not the file had any unsaved changes.

Lately however I decided that I could use more informative status line. I briefly flirted with the concept of using Powerline but since I’m a system nomad who drags his .vim folder wherever he goes that idea died pretty quickly. Instead I decided to create my own status line which displays the information that I care about in a Powerline-like way but without any fancy fonts.

The killer feature for me is that I wrote it. By that I mean that if something breaks or doesn’t work correctly can easily figure out why, and fix it. Power line is pretty big and has a lot of moving parts, whereas my status line is just a dozen lines of very basic VimL so if it breaks, I can easily handle it without loosing too much time.

The result looks like this:

Vim-NeatStatus Plugin

The mode indicator on the left changes color depending on the mode: green in normal, red in insert and blue in replace mode. I also had it turn purple in visual mode but it was kinda buggy (always lagged one keystroke behind) so at the moment it doesn’t do that. I still use Obvious-Mode so this functionality isn’t strictly necessary, but I included it so that it could be used as a stand-alone plugin.

The black box next to mode indicator shows you the server name (which in my case is treated as session name). This may not be useful to everyone, but since I set up my Vim to save sessions on exit I actually like to see that information somewhere.

To the left of the file path I have file type (ie. what language vim thinks this file is written in), file format (important if you jump between systems as much as me) and encoding (as in utf8 or not). The last may not seem fairly relevant to you, but sometimes it does matter: especially if you are trying to parse files in a certain way, or if you create a script that doesn’t run properly because the non-vim text editor decided to insert a BOM in it for shits and giggles.

Next I have the buffer number (which is useful when you have a lot of buffers open) and cursor positioning info with the current line highlighted in pink to stand out and be easily readable. There is also one more bit that is not visible in the picture above: whenever you edit a file, a little pink notification appears in the right corner of your status bar to let you know that the file has unsaved changes. Once again this is a duplication of Obvious-Mode functionality but it can be useful if you decide to install it as a stand-alone.

The colors work both in the graphical Vim as well as in the console (though you may need one that supports 256 colors). I tested it in in Gvim, MacVim and using Gnome-Console as well as Cygwin MinTTY on Windows.

I made the entire thing available as a plugin that can be easily installed via Pathogen like this:

cd ~/.vim/bundle
git clone git://github.com/maciakl/vim-neatstatus.git

If you have your .vim under source control like me then do:

cd ~/.vim
git submodule add git://github.com/maciakl/vim-neatstatus.git bundle/vim-neatstatus
git submodule init
git submodule update

At the moment the colors are hard coded and the plugin is not very configurable as a whole, but that will likely change in the future. If something is broken or the colors look atrocious under some setups let me know and I will try fixing it.

Are you able to change the status line in your favorite text editor? If yes, what kind of information do you put there? Have you written your own status line or are you using a plugin written by someone else?

That’s not the only reason why Iron Man was a tough gig though. It also had a difficult task of reconciling the Iron Man continuity with the events that happened during the Avengers. Whedon didn’t really need to worry as much about reconciling all the plot threads from all the different movies because he was building something new and something bold and he could just pluck the heroes from their element and put them on a flying aircraft carrier. However, Iron Man 3 returns Tony Stark to his own established setting, with a cast of established characters (Pepper Pots, Happy Hogan, Col. Rhodes, etc..). It needs to tie the old with the new somehow, and this is especially difficult in terms of Iron Man mythos.

Iron Man 3

Thor is an alien space-god who fights frost giants and sorcerers with Clarktech magic so it is easy to hand-wave anything on his continuity. Captain is a displaced fish out of water character so anything that happens to him is essentially a blank slate – you can go anywhere with this hero right now and no one will probably make fuss about it. But Iron Man had two movies to establish his own setting. There is a thematic continuity and certain kind of feel to the Iron Man movies and you sort of must at least try to maintain that in order to make a successful sequel because that’s what people want to see. The problem is that in the last two movies Tony Stark fought relatively low powered (at least compared to Loki) rivals in power armors, and magic alien space gods were not even on his map. Going back to that place would be counter-productive.

I must say that Drew Pierce and Shane Black did an admirable job tying the two continuities into one by addressing the dissonance between them directly. Instead of ignoring the world changing events that happened in New York, they become a central point of Tony Stark’s character arc (yes, Tony has an arc in this film – this is new and definitely a welcome addition to the Iron Man franchise). After fighting alongside gods and monsters, the hero feels somewhat inadequate. Thor, Cap and Hulk all have super powers and can fight alien space monster with their bare hands if need be. Iron Man on the other hand is powerless without his armor, and Stark is all too keenly aware of that. Events of Avengers have shook him to the core, and he is still suffering night terrors and panic attacks triggered by memories of the giant wormhole in the sky. As if to compensate, he fills his house with ever more powerful variants of his armor and finding new ways to get the armor deployed and combat ready as fast as possible. Of course it is all for nothing, and he is soon stripped from his high-tech weapons and forced to overcome his insecurities fighting super-powered villains with nothing but the power of his intellect.

This is a solid character arc, and a solid foundation for a plot: something the previous two Iron Man movies didn’t really have. The second installment especially was rather aimless, directionless mess and the third movie is definitely an improvement over that.

A lot of people seem to be upset about the Mandarin bit, but lets face it: was anyone really expecting him to show up looking like Lo Pan from Big Trouble in Little China in this day and age? As much as comic book readers might be fond of the character, the truth is that the original character concept was somewhat racist. The updated movie version (a middle-eastern terrorist with oriental flair trappings) seems not only much more timely but also quite subversive. When Ben Kingsley showed up on the screen I couldn’t believe how calculated his character design was: this Mandarin was the sum of all post 9/11 fears made flesh. Part Bin-Laden, part Kim Jung Il, part super-villain mastermind he was the picture-perfect boogeyman that proponents of the war on terror have nightmares about.

Speaking of Mandarin, let’s talk about the big twist. If you haven’t seen the movie and don’t want to get spoiled I suggest you skip over the stuff in the gray box below.

The acting was pretty decent in this one: Kingsley was great, Downey was doing his thing as he always does, Gweneth Paltrow actually got to punch things… Though only after prolonged session of damsel in distress bondage. The kid was quite terrible, as all children in movies are but at least he was able to set up one of the funniest Downey lines in the movie.

Guy Pierce however was kinda annoying. I can’t really put my finger on it, but something about his performance bothered me. I didn’t necessarily hate him – when an actor can actually make you hate his villain then he is actually doing his job well (see Jack Gleeson, aka Joffrey Lanister – the most hated kid in America and Westeros right now). Pierce’s character just felt a bit boring. Granted it might just be that he was completely eclipsed and overshadowed by Kingsley and Downey in terms of the on-screen presence.

All in all, I think the movie was pretty solid. It might be one of the best installments in the Iron Man franchise so far – or at the very least, better than the second movie. It had a good character arc, some fun plot twists and pretty decent dialogue. Granted, it was not without flaws (movie children usually ruin shit pretty fiercely) and plot holes… For example: can someone explain to me why didn’t Tony open up his indestructible bunker that contained an army of remote operated Iron Man suits earlier? Like right away after crashing in the snow? Or when he got his suit powered up again? Because I can’t fucking figure it out.

python -m this

When I first discovered Python it still had that ugly, pixelated green snake logo all over their website, and the documentation was all like “Monty Python guise, LOL, amirite?”. Over the years it has grown up a lot and became so mature, solid and reliable that people no longer even care about the white space thing as much. For years now Python has been ordinary and almost boring – all the rock stars, novelty chasers and cool kids left it for Ruby long time ago (and then recently left Ruby for things like Haskell and Node) and so serious shit can get done.

But despite being stable and mature environment, Python code is still a joy to work with. The beauty of the language is it’s enduring quality, baked right into the syntax and grammar of the language, and deeply rooted in the community. But as with all languages that have been around for a while, Python is not impervious to cruft, baggage and just plain poor coding. Despite the design of the language it is actually not that difficult to write ugly Python code. It is also not that hard to write pretty good code but in a way that is less than optimal.

So I wanted to share some tips, tricks and best practices for writing Python code that I have picked up from various sources over the years. This is definitely not an exhaustive or all-inclusive list. Rather it is a random assortment of suggestions and ideas that can help you structure your code better, and tools that will help you to do more with less.

Use Virtualenv

Installing packages globally is not always good idea. Especially if you use easy_install which can do funky things such as partial installs caused by network connectivity issues. It is better to keep your global install relatively clean and only install random packages on a project per project basis. Then, even if you mess up your installation you can just wipe the slate clean and start over again without much hassle.

Python doesn’t have native support of installing packages and modules this way, but you can force it to do so using the virtualenv package. The idea behind it is rather simple: you run a command line script and it copies your python environment into the current working directory, and then modifies your path for the current session so that all calls to python search the local folders first.

Here is an example how you would create a virtual environment for your project:

# Copy a clean install of python with no packages to ./Foo
# It will create ./Foo if it doesn't exist
virtualenv --no-site-packages Foo
cd Foo
 
# Update path for current session
source bin/activate

This gives you a clean slate instance of Python with no baggage, which you can now build up with only the packages that are required for your project. Granted, this method litters your project folder with bunch of standard library files which can be annoying.

I usually recommend using virtualenvwrapper alongside with the virtualenv package which provides a set of wrapper scripts that aim to simplify your life. Once you install it, you can define $WORKON_HOME environment variable (usually ~/.virtualenvs) which is going to be the default directory for installing virtual environments. It also simplifies the syntax a little bit, and modifies your prompt to reflect the virtualenv you are working in:

# Create virtualenv in $WORKON_HOME/Foo
mkvirtualenv Foo
 
# Activate virtualenv
workon Foo

The great thing about this approach is that you can have two separate environments (say ENV1 and ENV2) for the same project. For example if you want to investigate a bug that only happens when your code is running on a legacy version of Django, you can easily set it up.

Use pip instead of easy_install

One could argue this is a matter of personal preference, but I personally think that using pip should be considered one of the fundamental best practices for Python. As package managers go, it is simply superior in almost every conceivable way. It has meaningful error messages, it doesn’t leave your system in a weird state if an install fails, it can talk to source control repositories and it provides an uninstall command which lets you easily remove old or deprecated packages you no longer use.

It also allows you to create and use simple text files to track dependencies for your project. You simply create a file (let’s call it requirements.txt like this, simply listing names and versions of packages that need to be installed on the system in order for your code to work:

MyProject
Markdown==2.3.1

Save it with your code, commit it to the repository and forget about it. Later, when you need to deploy it somewhere else you can simply tell pip to fetch all the dependencies like this:

pip install -r requirements.txt

If you are using virtualenv, you can actually easily test that this works by creating an environment with the –no-site-packages switch. Or, if you already have a virtualenv custom-tailored to your project you can run the following command to auto-generate requirements file for yourself:

pip freeze > requirements.txt

Note that this typically dumps all the installed packages into the file, so if you run it globally instead of in a virtualenv you can end up with a really long list of packages that may or may not be related to your project.

Standard Libraries are not always best

Python code is beautiful, except when it isn’t. Most of the standard libraries follow the simple philosophy of Python Zen: they facilitate writing beautiful, simple, flat and sparse code. That said, the standard library has a few ugly warts: like urllib2 for example.

Take the following code snippet for example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

import urllib2
 
url = 'https://api.github.com'
 
req = urllib2.Request(url)
 
password_manager = urllib2.HTTPPasswordMgrWithDefaultRealm()
password_manager.add_password(None, url, 'user', 'pass')
 
auth_manager = urllib2.HTTPBasicAuthHandler(password_manager)
opener = urllib2.build_opener(auth_manager)
 
urllib2.install_opener(opener)
handler = urllib2.urlopen(req)
 
print handler.getcode()
print handler.headers.getheader('content-type')

Is this beautiful? Is it clean? To me, the entire library has a very heavy handed Java feel to it. Compare it to the same functionality implemented using the third party requests library by Kenneth Reitz:

1
2
3
4
5
6

import requests
 
r = requests.get('https://api.github.com', auth=('user', 'pass'))
 
print r.status_code
print r.headers['content-type']

I think that most of us would agree that the latter is cleaner, clearer, more readable and arguably more Pythonic than the former. While it may seem counter-intuitive at first, sometimes picking a few good external packages can make a difference between unattainable mess and a clean and beautiful code.

If at any point you find yourself writing Python code that seems ugly, dirty and cumbersome, chances are there is a better way. You just have to look around a bit.

Use Context Managers

When you are writing code, chances are that sooner or later you will run into a situation where you need to open, lock or reserve some resource and then release it afterwards. The most trivial example would probably be writing to a file:

1
2
3

f = open('myfile','w')
f.write('Hello world!\n')
f.close

The unfortunate truth about code like that is that most of us habitually forget about like #3. And even if we don’t forget it, an exception or an error might prevent it from being ran. This may not happen so often when doing simple I/O but the same pattern is used to connect to databases or manipulating sockets where errors and exceptions are to be expected as a fact of life, and closing and releasing resources is doubly important. You could wrap your code in a try-finally blocks, but as of Python 2.5 and higher the cleaner and simpler way of writing the above is:

1
2

with open('myfile','w') as f:
	f.write('Hello world!\n')

The cleanup is implicit, automatic and triggered whenever you leave the context of the block. This works great with objects, classes and functions that support it, but how do you bake it into your own custom code? It’s relatively simple: you put your set-up code in an __enter__ method and your tear-down code in an __exit__ method and they will be auto-magically called whenever your class is initialized using the with context manager:

1
2
3
4
5
6
7
8
9
10
11
12

# set it up
class DBConnect:
    def __enter__(self):
        # establish db connection
        return self.dbconnection
 
    def __exit__(self):
        self.dbconnection.close()
 
# use it like this
with DBConnect() as db:
    # do stuff

Defining these methods for your custom classes not only makes the code more robust, but also more beautiful, allowing you to avoid writing the unseemly try-finally blocks all over the place.

Create Objects that are Transparent

The Python REPL can be extremely useful tool. I use it all the time to quickly test ideas or poke my code around. Unfortunately it is not always easy to glimpse inside your custom classes and objects this way unless you take steps to make them transparent. For example, let’s say you have a class like this:

1
2
3
4

class Foo:
    def __init__(self, x=0, y=0):
        self.x=x
        self.y=y

The problem you may run into is that objects initialized from this class do not display any useful information when invoked directly or printed in the REPL:

>>> t = Foo()
>>> f
<__main__.Foo instance at 0x02C82940>
 
>>> print(f)
<__main__.Foo instance at 0x02C82940>

A lot of people know that you can simply override the __str__ method to get a nice string representation of your object that can be printed directly, or concatenated to some other text. It is however far less common to see the __repr__ method implemented in a class. It is a pity, because it controls what is displayed in REPL when the object is invoked directly and as such can be tailored to display developer/debug friendly information about the internal state. For example:

1
2
3
4
5
6
7
8
9
10
11
12
13

class Foo:
    def __init__(self, x=0, y=0):
        self.x=x
        self.y=y
 
    def __str__(self):
        return '({},{})'.format(self.x, self.y)
 
    def __repr__(self):
        return '{}(x={},y={})'.format(
            self.__class__.__name__,
            self.x,
            self.y)

Will behave like this in the REPL:

>>> foo = Foo(5,7)
>>> f
Foo(x=5,y=7)
 
>>> print(f)
(5,7)

Implementing the __repr__ method may seem unimportant and insignificant, but it saves lives.. Or at least man hours of debugging.

Lint Your Code

I’m a firm believer in linting your code. It is a good practice that tends to yield saner, more beautiful and readable code most of the time. A lot of people don’t like very aggressive linters because they tend to complain about trivial things such as tabs vs. spaces, lines longer than 80 characters and etc. You should keep in mind however that every dumb linter rule is there for a reason, and generally adjusting your coding style a bit to conform to said rules is never really a bad idea. Granted, if you are working with an existing code base that has never been linted, you might be shocked how much refactoring it would take to get it in shape. But when you start a new project, a rigorous linter is a great thing. It will not only help you structure the code, but it will also catch minor bugs that could otherwise be overlooked.

Personally I’m a fan of PyLint which tends to be super anal and very, very harsh on you. It actually scores your code, runs statistical analysis on it, and keeps track of last few runs so that you can see how much your changes have improved the overall quality of code.

Obviously PyLint is an external tool, but you can also get in-editor, as-you-type linting tools. Sublime has the excellent Sublime Linter which does more than just Python. If you run Vim there is a plethora of plugins that do just that, with the phenomenal Syntastic leading the pack. If you use Emacs then… Then ask Chriss – he will tell you what to use.

I highly recommend using PyLint in addition to any in-editor tool for the aggressive harshness and neat statistics it provides.

Always Be Testing

I don’t think I have to stress the importance of testing your code. At the very least you should be writing unit tests for all your classes. Python fortunately has a built in unit testing framework aptly named PyUnit. It is pretty much the industry standard and it follows the same conventions as JUnit and PHPUnit. If you have used these unit testing frameworks, PyUnit code should immediately look familiar and understandable:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

import unittest
import Foo
 
class SimpleTestCase(unittest.TestCase):
 
    def setUp(self):
        """Call before every test case."""
        self.foo = Foo()
        self.file = open( "blah", "r" )
 
    def tearDown(self):
        """Call after every test case."""
        self.file.close()
 
    def testA(self):
        """Test case A. """
        assert foo.bar() == 543, "bar() not calculating values correctly"
 
    def testB(self):
        """Test case B"""
        assert foo+foo == 34, "can't add Foo instances"

If you want to do something along the lines of acceptance testing, then Splinter is probably the way to go. It has really concise and clean API and lets you create complex tests for web applications fairly easily. The only downside is that it is not really a full fledged test framework like Codeception for example. There is no way to assert or fail tests in splinter – it is meant to be used as an abstraction layer or a component. So you basically just write PyUnit test cases which use Splinter, which works quite well as you end up with all your tests running on the same framework in the same place.

Use a build tool

As you may or may not know, I am a big fan of Rake as a simple build tool. That said, it doesn’t really seem all that kosher (or practical) to use a Ruby build tool for Python projects. Fortunately there is Paver which is essentially Rake of Python world, though perhaps not nearly as popular.

I believe that originally it was created to streamline the creation of distribution bundles and packages, but you can confidently use it to run any number of arbitrary tasks. Like with Rake, your build file is an executable script – you don’t configure your build, you code it. This makes it endlessly extensible and perfectly suited for our puposes.

To start using Paver you just pip install paver and create a pavement.py file somewhere in your project directory. An example file could look something like this:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16

from paver.easy import *
 
@task
def lint():
    print "Linting..."
    # run linter 
 
@task
def test():
    print "Testing..."
    # run your unit tests
 
@task
@needs(['lint', 'test'])
def default():
    pass

You can run it like rake from the command line:

# run lint task
paver lint
 
# run the default task
paver

It is usually a good idea to automate running of your linter and your unit tests with Paver. It allows you to make some changes, then immediately have them analyzed for errors and bad code smells, and ran through all your test cases.

Suggestions?

I hope this was helpful to at least few people out there. I am by no means an authority on Python but I feel like some of these tips can be useful for both novices as well as seasoned programmers. I generally enjoy reading this sort of write-ups because even if I already most of the stuff in the article is always a chance that I will learn something new. What are your favorite Python tips? Have you ever stumbled upon a Python related article or a video which made you go “Wow, this changes everything!”. If so, please share it in the comments.

Why not 13.4 you ask? Well, I’m in my 30′s now which means I’m living on an accelerated time-space curve now. Time simply flows faster than it did when I was in my teens or twenties. For example, I recently refereed to an event that happened back in 2010 as “the other day” because that’s honestly how it felt to me. From that you can probably extrapolate that I am not a huge fan of upgrading my OS every other day (which is roughly how 6 months seems to me). I can hardly give half of a fuck what quirky adjective-animal combination is the most up-to-date one. I just want something semi-stable that is regularly patched, and that has a decent sized package library. I’ve ran non-LTS versions of the OS before, and I was always unpleasantly surprised when Canonical end-of-lifed them and “vanished” the repositories leaving me stranded every 6 months or so. To put it plainly, anything that is not an LTS is not worth my time.

12.4 ships with Unity – Cannonical’s new window manager and desktop environment. There has been a lot of discussion about it when it was first released, and it seems that Ubuntu community has been torn apart between those who like it and those who hate it. Previously I didn’t really have an opinion in the discussion, because I haven’t really used it for anything substantial. I of course checked it out back when it was new, and it looked kinda sleek and a tad bit showy for my tastes but I didn’t outright hate it.

With my switch to 12.4 I decided to give it a fair shake and see how it performs in regular day-to-day usage. Unfortunately, it turns out that all the haters were right: Unity is not that great. It is style over substance. It seems to try so hard to be OSX like that it makes things that used to be simple needlessly difficult.

Here are my biggest complaints about Unity in order of severity:

1. Poor performance
2. No functional pager
3. Terrible application awareness

Let me tackle each of these in turn.

Performance

The machine I replaced my old laptop with wasn’t top of the line. It was one of the rank and file laptops we had in stock, and I might be able to swap it to a beefier dev machine at some point soon. Still, the hardware was nothing to scoff at – a respectable Intel i5 CPU and 4GB of RAM. Nothing to write home about, but we usually run Win 7 with full-blown Areo effects on this hardware, and it handles it without breaking a sweat. Unity was making it work for its money: the fan was whining full speed most of the time, and launching applications would actually freeze up the desktop for a few seconds. Switching desktops was literally painful.

You could argue that it’s not Unity but Ubuntu itself being an unoptimized resource hog. I was concerned by this too, but then I decided to do an experiment and ran the following command:

sudo aptitude install gnome-panel

I then logged out, logged back in and all my performance issues went away. Applications were now launching normally, and switching desktops wen from 1 second lag, followed by jerky animation to an instantaneous flick.

It’s probably also worth mentioning that after trying Gnome Panel, I went back and booted up in the Unity 2D mode to see how it stacks up. It was a big improvement on the default setup and the machine was actually usable. So if you do want to give Unity a whirl, I highly recommend using the 2D mode unless you have a top of the line rig. Of course half of Unity’s charm is how pretty it looks so you will be getting a diluted experience. Along with my other issues, I decided it just wasn’t worth it.

Lack of Pager

Both KDE and Gnome has always had excellent pagers. You know – those little widgets that sit in your task bar and let you switch between your virtual desktops. I always loved the fact that I could just glance onto said pager in the corner of my screen and see the rough layout of my windows on each desktop. Not only that, but I could just click on any arbitrary desktop to switch to it, or grab any of said windows and drag it to a different desktop letting me organize my shit without any hassle. In Unity that functionality is replaced with OSX inspired “workspace switcher” which does the pan-and-zoom-out kind of animation every time you activate it. It’s icon in the dock is static and doesn’t give you that at-a-glance preview which seems like a downgrade.

Note the pager in bottom right which shows you what windows are open on which desktop/display and allows you to drag and drop them.

I liked seeing window outlines in my KDE/Gnome pager. I liked being able to drag windows between desktops without actually switching to those desktops via the pager. The pager was always one of the best features of a Linux desktop. I always miss it whenever I’m working on Windows of OSX. In the past I have tried third party solutions that would add virtual desktops to Windows and pager like functionality of OSX but none of these have ever worked as well as the native KDE/Gnome task-bar widgets.

One could argue that removing the pager in not unorthodox because it mimics OSX behavior that users might be more familiar with. The fact that it was aped from Apple however doesn’t make it good. Personally I am not a huge fan of OSX spaces. I’m glad the functionality exists, but I often find myself wishing it worked more like traditional Gnome/KDE style virtual desktops. It is admirable that Cannonical is trying to learn from the best, but I think in this case they got it wrong. They took something that was working well, and replaced it with something similar but less functional.

Application Awareness

Unity is also missing a task bar. I don’t know about you but I like task bars. I’m very fond of the traditional, one entry per window task management. One of the first things I do when I install Windows is to disable collapsing in the task bar. I like to be able to see how many windows I have open, and be able to switch between them easily with a mouse. Collapsing applications into a single icon on the task bar hides vital information that I need to work efficiently.

OSX doesn’t have a traditional task bar, but it provides some alternatives. When you minimize windows in OSX, you essentially iconify them into custom doc entries. So as long as you command-M your windows instead of letting them go out of focus, you have yourself a functional task bar with one entry per minimized window.

Unity implementation combines worst features from both worlds and ends up with Launcher which is barely workable. Instead of showing you what windows are open on current desktop, Unity adds dots to the left of the icons of apps. One dot per open window on the current desktop… But only up to three dots in total for some reason. Instead of collapsing minimized windows into their own entries it simply hides them. So the only way to find out you have minimized windows on current desktop is to count the dots, then count open windows and subtract.

Pop Quiz: How many instances of Terminal are running here? The answer is five.

You can of course trigger Apple-expose like windows splay by clicking on said dots, but that shows you a preview of all the windows, without differentiating which ones were open, which were in focus and which were minimized. It seems a very haphazard, unfocused take on window management. With a traditional task-bar I can glance on the bottom of my screen and I instantly know how many windowed applications I’m running and on which desktops I have open windows. With Unity I always felt like I was flying blind, never having full awareness of my work environment.

Conclusion

In my honest opinion, Unity is mostly broken by design. I don’t blame Cannonical for trying to design a desktop environment that is easy to use and intuitive. I don’t blame them for abstracting and hiding away a lot of configuration details in lieu of a streamlined and unified look and feel. I don’t mind that they came up with an opinionated desktop environment that makes bold design choices. This is actually a good thing. Linux desktop needs this sort of focus on usability and user friendly environments. I’m glad that Unity exists because it allows us to have discussions about usability and user centric design on Linux desktop – something that used to be an almost foreign concept few years ago.

That said, when you come up with an opinionated framework that makes bold decisions, you risk using established power users. I am unfortunately one of them. I’ve been an Ubuntu user for many years now, but Unity is just not for me. I like traditional task-bars and pagers and I want them to be part of my desktop experience. If I didn’t like them I would probably be using a tiled window manager like real men are supposed to (or so I’m told).

That said, I can see how Unity could provide better user experience for novice users who have not yet developed habits such as juggling many virtual desktops and displays. If you are the type of person who usually runs one or two applications at a time, Unity 2D might actually be a viable option. The large icons on the launcher and search based application finder make it very easy for a Linux novice to find a program they might need for a particular task.

It’s a pity that Unity offers next to nothing to us power users.

Vim and Emacs users are different – take one at random from each camp, put them in a room and sooner or later you will find them talking about that plugin/extension they wrote for their editor. Why is it that majority of people who use these two tools always eventually end up writing custom plugins for their editor, whereas most other programers never do? Perhaps Vim and Emacs simply attract certain kind of minds to them – inquisitive tinkerers and hackers who simply like to tweak and customize things. Or perhaps it is that both these editors are just so easy to tweak and modify that there is simply no barrier to entry. If you have written your .vimrc from scratch (as every Vim user should – don’t let anyone tell you otherwise) then you already know how to write plugins. In fact, you have probably already written a few without realizing it – all you would need to do now would be to dis-entangle them from your config file and generalize them a wee bit so they can be installed as a self contained module. Same goes for Emacs.

Of course, whenever Emacs user and Vim user start talking about plugin developments, the former is bound by law to smugly condescend about the quality of the respective domain specific languages employed by each editor. Emacs uses Elisp which is a Lisp flavor and therefore superior.

You see, the ancient legend says that before the universe was compiled, the creator deity pondered for a spell, and then on the first day said Let there be parentheses! and he saw they were good. Then on the second day he said Let code be data and data be code and there was much rejoicing. Then on the third day he hacked up a meta-programming macro, and fucked off for the rest of the week as the universe generated itself. Then, millions of years later man invented haskell and was like “What now god?” and god was like “Shiiiiieeet, son!” because in his omnipotence he saw it was also pretty fucking awesome, though mostly in an incomparable to lisp in an apples to barnacles kind of way.

The point is, Emacs users have a pretty cool language they can play around with. Us Vim users, on the other hand, have VimL which is… Neither pretty nor elegant. It has no OOP support, weird scoping, too many overloaded syntax level operators that behave differently based on context, no JIT, and it allows (or even encourages) you to write terrible, unreadable spaghetti code that is worse in terms of readability than Perl. You could probably argue about Elisp’s aesthetic flavor with all the parentheses and what not, but at the end of the day it is rather elegant and consistent environment. VimL is quite the opposite: it is quirky, inconsistent mess of a language that grew along with the editor developing strange warts and tentacles along the way. It is much like a giraffe developed by a committee: while it is supposed to be a giraffe, it is actually an aardvark wearing a pineapple fruit hat and a monocle. It is neither glamorous, nor particularly fun to work with – but it will get the job done if you clench your teeth and try to resist the overwhelming urge to slap it in the face for being so goofy looking.

Fortunately for us, we have options. Modern versions of Vim tend to come pre-baked with support for alternate languages such as Python or Ruby for example. So if we wish, we can get away from VimL and write code that looks and reads nicely. Of course such a thing comes at a trade-off. The general rule of plugin development is that the further you go from the native language the editor “speaks” the worse off you are. In case of Emacs, this doesn’t matter because it was largely written in Elisp (except the few small parts that were coded in C). Vim is mostly implemented in C with VimL already being second class DSL so putting another layer of abstraction between us and the editor can become problematic. So the rule of thumb is that for simple stuff you should stick to VimL and fall back on external language only when you have to do some heavy and/or convoluted processing. VimL is closely tied to Vim but not as expressive as it could be when it comes to representing complex program logic.

Python, on the other hand is. While, perhaps not as elegant as Lisp, Python is nice, strong, opinionated and beautiful language. Opinionated, because among other things, it doesn’t give a shit about your preconceived notions regarding the use of white space. Beautiful, because it is the kind of language that will force you to write code that doesn’t look like shit or die trying. It is the language you need, but perhaps not one you deserve.

Also, because it is older and more mature than Ruby and therefore you have a better chance of it being compiled in your copy of Vim. Mature only in software terms of course – after all making Monty Python references in your code is the accepted development pattern and recommended best practice after all.

How do you know if your Vim can handle Python code? Well, it is easy:

• If you are outside of Vim you just run vim –version and look for +python which indicates you’ve got it or -python which indicates that whomever compiled your vim package is a major douchenozzle.

• If you are inside of Vim you can just issue the :py 1 command. If nothing happens, you are good. If you get an error message complaining that py is not an editor command, then… Douchenozzle.

Once you have confirmed that your vim will consume python code, you go about writing a plugin as you would with a VimL one. First, you create a file: say helloworld.vim or something like that. Then, at the top of that file you place some contingency management code:

if !has('python')
	finish
endif

This checks if the user’s editor has the Python support baked in, and silently quits if it does not. This is a nice thing to do, since it prevents someone’s editor from blowing up. Chances are the person who will be installing your plugin doe not read your README file and thus does not realize he needs python support, and therefore his Vim will blow up with a barrage of error messages next time he launches it.

Of course we could try being more explicit, and display an error message along the lines of “Y U has no +python!??” but I personally prefer the silent failure. Don’t get me wrong, explicit is almost always good, but I hate when plugins spam me with error messages on start-up. I keep my .vim/ directory under source control and I clone it onto every machine I work on. Sometimes I don’t have the luxury of using the latest and greatest Vim with all the fancy options. I don’t like to build specialized configs for those special cases – I’d rather use my usual setup, and just have the fancier stuff fail silently and simply be unavailable, rather than vomit stream of warning messages at me every time I do something. But that’s just me.

Next we want to expose some interface to the user in VimL so they can, for example bind it to a command or a key. That part has to be done in VimL. Think of it as bridging the divide between the native language and the external one. Usually, the best way to expose some functionality to the user in an unobtrusive way is to create a publicly accessible function:

function! HeloWorld()
 
endfunc

In general, you can access the Python environment in Vim by issuing the :python command (short version :py). You could technically write an entire plugin by simply prefacing every line with that command, but that would be extremely ugly and kinda crazy. Instead we can do something like this:

function! HeloWorld()
 
python <<< EOF
 
print "Hello World!"
 
EOF
endfunc

Now you can do :source % to load it up, and call HelloWorld() to test it. If all went well, you should see the text Hello World in the status line.

Granted, this is still kinda ugly. Mixing VimL and Python in a single file is definitely non-kosher, and it completely defeats the purpose of this entire exercise: to write plugins in a more elegant language, and make them more readable. Fortunately, there is another command we can use to load up an external python file, and execute it in Vim context: :pyfile (or :pyf). So our ugly function can be reduced to something like:

function! HeloWorld()
    pyfile helloworld.py
endfunc

“That is all well and good,” I can hear you say “but what does this do for us?” To actually do anything interesting as a plugin, your Python code needs access to internal Vim stuff – like the buffer list, or the contents of said buffers. How do we get that?

Well, we get it via the magical vim module. It is magical because it isn’t really a module that you can go and download or install in the usual way. It doesn’t exist on the outside, and can only be imported when the script is called from within Vim. This is both good and bad. It is good, because it makes it completely plug-and-play. If you have Vim with +python there is nothing else you need to do: it just works. On the other hand, it is bad because it requires Vim to work. This means you can’t run your code outside the context of your editor. For example, you may not be able use your favorite Python unit-testing suite to run test on your plugin, unless you mock up the Vim module functionality first. Which in retrospect is what you probably ought to do anyway so I guess it works out.

The vim module exposes bunch of useful objects such as vim.buffers or vim.current.buffer that you can use to manipulate your buffers, files and settings. The current buffer for example is actually a zero indexed array, each element representing a line as a string. Any changes to the elements in said array are immediately reflected on the screen. I will let that sit with you, so you can just imagine the possibilities for fun and abuse here.

If you want to know all the available objects and their details, I suggest you RTFM. Just as an exercise however, lets write a quick and dirty python plugin together.

I work with Markdown files a lot, so I always run them through something like Pandoc to check how will they look in HTML format. Let’s say I wanted to create a plugin that takes current buffer and dumps it into HTML format without the need for Pandoc or any other converter to be installed on the system. Because I’m lazy and I don’t feel like writing actual Markdown converter myself I will just use this Markdown package.

So, first let’s create a VimL plugin file that will load our Python code and call it, say markdown2html.vim:

if !has('python')
	finish
endif
 
function! Markdown2HTML()
	pyfile markdown2html.py
endfunc
 
command! MKD2HTML call Markdown2HTML()

The last line actually binds my function call to a Vim command providing an easy way for the user to run it. Next let’s write our python code:

try:
    import markdown
    import vim
    import string
 
    html = string.join(vim.current.buffer, "\n")
    html = markdown.markdown(html, output_format='html5')
 
    filename = vim.current.buffer.name+".html"
 
    f = open(filename, 'w')
    f.write(html)
    f.close()
 
    print "HTML output written to "+filename
 
except ImportError, e:
    print "Markdown package not installed, please run: pip install markdown"

Bam! Instant plugin. How awesome is that?

Of course the downside of using Python to write your plugins is that the users will need to have their editor compiled with +python in order to use them. Also, every time you use a third party Python package (like I just did above) your users will need to actually install that package on the system. So if you actually try to implement the above, don’t forget to pip install markdown at some point beforehand.

Still, the ability to bring the power of Python and all of it’s packages and modules into your Vim plugins is not something one should scoff at. If you would like to see a real life example of an excellent and popular plugin written in Python, go check out Gundo. It’s actually a plugin I use all the time as I work.

Zelazny is a household name due to the unyielding popularity of his anachronistic, heroic power fantasy series Chronicles of Amber. I only read 1 and a half books from that series, and never really thought much of them mostly because they were just that: fantasy. And you know how I feel about fantasy. Don’t get me wrong: Zelazny writes very well, and the series departs quite a bit from the standard Tolkienesque template all fantasy writers have to work of (as this is essentially the litmus test of the genre). It just didn’t do much for me.

I did however, very much enjoy his Lord of Light which is most definitely a work of Science Fiction, even if it reads much like Fantasy. Zelazny was able to seamlessly blend the somewhat exotic (to us Westerners) myths of the Hindu pantheon with a dash of speculative science fiction creating something very unique and awesome. So awesome in fact that many years later Dan Simmons successfully re-used that formula, but using the more familiar Homeric epic as the backdrop. The premise, and for the most part the overall plot arc are rather similar.

Lord of Light

The big difference between the two however is that Zelazny has more style. His omniscient, third person narrator never really breaks character and recants the story as if it was an old legend. He is deliciously ignorant of the SF elements of the story. Only the characters themselves are allowed to break the facade and utter anachronisms or explain technological gadgets. This, in my opinion gives the book an air of mystery as initially the reader is not privy to the inner workings of this world. It is plain that the magic of the setting is not at all magical, that the individuals who call themselves gods are not at all divine, and that the two moons in the sky, and planetary rings suggest visible at night suggest the story is not taking place on Earth at all.

Part of the fun with this book is slowly unraveling the mysteries of the setting, so I wouldn’t want to spoil too much of the plot. It will suffice to say it is worth reading. The characters are rather vibrant and colorful, and you come to enjoy them. Zelazny is a great storyteller an he weaves the plot threads well in a non-linear fashion creating a tapestry of legends and allegories about an enigmatic hero who is sometimes a prince, sometimes an enlightened teacher, sometimes a traveler possessed by demons and sometimes counted as one of the mighty gods who forged the world. Each story is another piece of the puzzle that helps you understand the enigmatic opening chapter in which someone or some thing is yanked out of Nirvana and incarnated into a human body, to aid a conspiracy in plot to topple Heaven.

I should probably also add that the protagonist is actually someone I could easily relate to and identify with: Sam is the last of the Accelerationist. He is the Prometheus of his world: one who aims to advance the technological progress and bring about change at any cost. His ideals mirror those of mine and I would like to think that if I was in his place I’d embark on a similar quest.

If you liked Simmon’s Illium novels, I highly recommend this book. If you didn’t like them, it is still worth picking up, considering it is shorter, more succinct and strikingly different not only with respect to the setting but also to the writing style. It is just a joy to read.

Vim novices usually come with these preconceived notion of how the tab metaphor ought to work in a text editing context, and become confused when Vim refuses to play by these rules. To put it simply, tabs in Vim are different. They won’t work the way you expect them to, because they were not designed for that. The one file per tab convention is not the Vim way.

Let me preempt the obligatory self-professed “usability expert” snark comments about vim breaking established UI conventions: please kindly go fuck a hedgehog. Bill Joy was establishing his own conventions when he wrote vi while doing your mom long before she spawned you and then became so fat she developed her own event horizon. Complaining that Vim doesn’t implement tabs the same exact way Sublime Text does makes very little sense when you consider the huge architectural differences between these two editors.

The original vi editor, and earlier versions of Vim did not really support tabbed interface. They did however support editing multiple files with a single instance of the program using buffers. If you have ever progamatically manipulated text in some way, you should be familiar with the concept of a buffer. To put it plainly a buffer is the copy of your document that is held in memory as you manipulate it. When you open a file, you load it into a memory buffer, and that’s where your changes are applied as you work on it. When you start a new document, your text is held in a memory buffer until you decide to write it to disk. Vim maintains a list of buffers that it has currently open, and you can view it by issuing the :buffers command (or alternatively the shorter :ls command alias).

You can typically only edit a single buffer at a time, so the current (or active) buffer is the one displayed on your screen, while all the other buffers are hidden away. When you open a new file, a new buffer is created and immediately displayed. The buffer that was being shown before it is not gone, but simply hidden away. Buffers are “like” tabs in modern editors, only they don’t have a graphical UI representation. They work the same though – you activate one of them, and it’s contents become visible while all the other ones are hidden away.

Vim Buffers

You can load any open buffer into your view-port by issuing the :b command followed by a number or partial file name which can be tab completed. The term “view-port” is a key concept here because it helps you understand what is really going on. It is best to think of the display area as a virtual port-hole through which you cane interact with your buffers one at a time.

When you create a split (for example using the :vsplit command) you effectively create two (or more) independent view-ports. Each one has access to Vim’s internal buffer list. So now you can have multiple buffers on the screen at the same time. Or you can load the same buffer in two splits, and watch changes you make on one side be automatically reflected on the other if that’s what floats your boat.

In essence, buffers do everything the tabs in say Sublime Text or whichever other Notepad replacement editor you happen to fancy. They just don’t have the clickable UI warts you might be tempted to fondle with your mouse. Lets face it – using a mouse to operate Vim is kinda like trying to eat tomato soup with a crossbow: it can probably be done, but it doesn’t seem at all practical. In fact, Vim’s buffer list is more flexible than most tabbed interfaces. For example, have you ever tried recursively loading your entire project tree into your editor? Let’s say you have 600 odd source files: what happens if you try to load all of them into your editor of choice? Firstly, chances are your app will crash and burn trying to prerender all these files or hitting some internal memory limits. It will also likely slow down to a crawl trying to create and display tabs in rapid succession (likely refreshing the screen for each one in the sequence). Assuming none of that will happen, your tab bar will likely become completely unusable: tabs will likely be about 1 pixel wide, or will force you to scroll around to find what you need.

Vim on the other hand will slurp up the entire project into buffers without even breaking a sweat because it doesn’t really have to render them unless you actually bring them into focus. Navigating a huge buffer list is actually easier than messing around with hundreds of tabs because you can use tab completion to match partial file names and get to where you need to go very quickly. Vim will also allow you to do bulk-edits using the :buffdo command which lets you run arbitrary vim commands (be it normal mode actions, build-in commands or function calls) on all the open buffers.

So the question is: could we simply force Vim to treat each buffer as a tab for the sake of following the UI convention followed by most of the relatively immature and untested (as compared to vim) editors on the market? The answer is no, we couldn’t. Why? Not because snobbery or entrenched traditionalism. It wouldn’t work because it would break the split screen functionality which is an established feature that predates the tabbed interface by a few decades.

Right now Vim lets you keep splitting your screen into independent view-ports, each of which can operate on a different buffer. How do you reconcile that with tabbed interface? Let’s say you have 7 files open, and you load 4 of them into 2×2 split (split horizontally, then split each half again vertically): what happens to the tabs that were loaded into splits of another tab? Do they disappear from the tab bar? What if you want to swap the contents of the splits? Do you re-shuffle the tab bar every time you split? If no, how do you deal with the tabs that are loaded in other tabs? If yes, how do you prevent tabs from moving around or getting lost? It seems like a very, very difficult problem to solve without altering existing functionality, with little to no benefit for existing users.

Tabs as implemented by Sublime Text and others simply make no sense in Vim world. Which brings us back to the original point of this post: what the fuck does Vim use the tabs for then? I can answer that with an example:

Imagine you are working on some code and you somehow ended up with a 2×2 split as above with 4 buffers on the screen at the same time. Suddenly you realize you need to open another file to tweak a thing or two related to your current task. You don’t want to split your screens any further, but at the same time you don’t want to blow that layout away since you are not done with it. To make matters worse said file is big, complex and ugly, so it ought to be viewed in full screen. In the olden days you would probably suspend (or minimize) your current session, and open another Vim instance to do so. But with tabs you don’t have to. You just open a new tab, which gives you a fresh view-port. One with access to the same buffer list, the same registers and recorded macros. One which you can split into multiple panes if you wish.

Vim Tabs

Vim tabs are essentially work-spaces or view-ports. They are more or less the virtual desktops for your text editor. They are not meant to be bound to buffers, but instead provide you with additional work surface where you can “spread out” the buffers you have opened.

You can of course try to force Vim to follow the “one-buffer-per-tab” convention, but it will always be an uphill battle. I’ve seen people write elaborate VimL scripts to accomplish this. I have seen countless plugins that claim they offer this functionality. But most of them break into thousand pieces as soon as you try to do something fancy with splits, hidden buffers or the :buffdo and :argdo commands. And if you are never going to try anything fancy, complex or weird then what’s the point of using Vim anyway?

From there It is quite easy to fall into a trap of running multiple instances of gvim side by side. While being able to look at two files at once is great, the best way to accomplish this with Vim are splits not multiple windows. Why? Well, when you open a new Gvim instance (ether via GUI or by running gvim from the command line it opens up as a separate process. It doesn’t share the environment of your existing vim instance. What does that mean? It means it can’t access the buffers you have open in the other window, which might actually be what you want. It also isn’t affected by any run-time customizations. It’s argument list, search path and work directory are initialized separately and do not interfere with each other. There are times when this is precisely what you want.

Chances are however that you are working on a few files that are part of the same project and thus you would probably want your Gvim instances to be able to interact. For example you might define a macro in one file, and wish to run it on the other – but you can’t. Hell, you can’t even directly yank and paste between the two windows because they have separate sets of registers. The only way to copy text from one window to the other is by way of the system clipboard, which only works if your version was compiled with support for it.

But what to do if you are a shell fiend, and basically just want to open your files from Bash? Well, you just need to learn one command line switch then:

gvim --remote-silent filename

This will find a running instance of gvim and attach a new buffer to it. From there you can put them side by side using :vsplit (to create a vertical split) and Ctrl-^ to toggle current split pane to the previous buffer and hide the split with :only when you no longer need it. The only thing you have to remember is that you don’t want to use the :q command because it will close the entire application. When you are done with a buffer you save it and then do :bd which in my mind stands for “Be Done!”. There is also the “Be Well!” command :bw which saves the buffer before closing.

Splits and buffers are really the way to go. Throw in tabs for a good measure and you can set up multiple sets of different split panes and flip between them without ever having to take your hands off the home row. But alas, even with cute mnemonics for the buffer closing commands accidents happen. I can’t tell you how many times I had a dozen files open in a single vim session, and in the middle of coding, out of pure habit I typed :wq. Suddenly, all the buffers are gone. All the splits forgotten. All the tabs purged. No data was lost in the process of course, since the files themselves were saved. The undo history was preserved as well because I use Vim 7.3 and enable the persistent undo feature. But the contents of the registers and the buffer list was blown away.

This used to happen to me at least once per day, until I set up automatic session saving for myself. Vim, as any good editor as a session feature. When you issue :mksession command it will save the list of open buffer and tabs as well as your register contents into a file called Session.vim in the current working directory. You can then run gvim -S and it will look for a session file in the current directory and restore from it. Alternatively you can :source that file.

Unfortunately this does not help you with accidental closing of vim, as you need to remember to save the session yourself. Of course you could always add this to your .vimrc:

autocmd VimLeave * :mksession!

This will automatically save a session file each time you close your editor, which is much better. Unfortunately this will quickly litter your filesystem with session files. It is about as annoying as those damn .swp files vim loves to produce by default. I have disabled those long time ago because I have never actually had to use one and decided they were not worth the hassle. Session files in every directory bring back these bad memories. Fortunately you can redirect your session file to somewhere else, like:

autocmd VimLeave * :mksession! $HOME."/.vimsessions/session.vim"

Now however you have only one session file, which gets overwritten every time the editor closes. This works when you accidentally blow away your buffer history like in the example above. But let’s say you are done for the night, and you close vim confident your session is saved. Then you run git commit to commit your changes into the repository. Git of course helpfully launches Vim to edit your commit log, and then happily overwrites your session. Next morning you want to get back to work, and your editor opens with a stale commit log message rather than a screen-full of buffers. Less than optimal, don’t you think?

I’ve been trying to figure out a good way to manage my sessions and eventually got an idea of naming my sessions. You can name your vim instance using the –servername command line switch like this:

gvim --servername dev

You can grab that name inside Vim using the v:servername variable, and use it as a unique name given to your session. Whenever you work on a specific project you launch it with a relevant servername and that session will be preserved. If you later run Gvim without that switch, it defaults to GVIM or an empty string if you ran the console version. This means that editing a commit log won’t accidentally blow away your session.

Here is how I’ve done it:

" where do you want to save sessions?
let g:session_dir = $HOME."/.vimsessions"
 
" Save sessions whenever vim closes
autocmd VimLeave * call SaveSession()
 
" Saves the session to session dir. Creates session dir if it doesn't
" yet exist. Sessions are named after servername paameter
function! SaveSession()
 
    " get the server (session) name
    let s = v:servername
 
    " create session dir if needed
    if !isdirectory(g:session_dir)
    	call mkdir(g:session_dir, "p")
    endif
 
    " save session using the server name
    execute "mksession! ".g:session_dir."/".s.".session.vim"
endfunc

That’s only part of the equation. Once you have sessions that save automatically, you also want an easy way to restore them. So I made another function that runs when you open vim:

" Load session when vim is opened
autocmd VimEnter * nested call OpenSession()
 
" Open a saved session if there were no file-names passed as arguments
" The session opened is based on servername (session name). If there
" is no session for this server, none will be opened
function! OpenSession()
 
    " check if file names were passed as arguments
    if argc() == 0
 
    	let sn = v:servername
    	let file = g:session_dir."/".sn.".session.vim"
 
        " if session file exists, load it
    	if filereadable(file)
            execute "source ".file
        endif
    endif
endfunc

One thing I decided here was that if I was opening a file in Vim, chances are I wasn’t interested in restoring the session. Most of the time when I run Gvim from the command line with a file argument I just want to quickly edit said file and be done with it. So I opted to never bother restoring sessions if a file argument was present.

If vim is opened without specifying a file, then I try to find a session file based on the servername variable. To make this even more seamless I actually added a few aliases to my .bashrc:

alias gv="gvim --servername DEV"
alias g="gvim --servername DEV --remote-silent"
alias gv="gvim --remote-silent"

So when I sit down to work I run gd on its own and it creates a named DEV session for me. Then I use g followed by filename to attach new buffers to it as needed needed. If I ever have to open an unrelated file, I use plain old gvim command which opens up a completely independent instance which doesn’t touch my session data. If I want to attach buffers to that session I can do that with gv. It works quite well, and it also reduces the amount of typing that I need to do at the console – so it’s a win-win in my book.

Back in 2003 when I first got the idea of creating Terminally Incoherent, blogging swiftly becoming one of the hottest buzzwords on the internet. I was of course aware of blogging almost since it’s inception in the late 90′s but I resisted the siren’s call of the new publishing platform because I didn’t think I had anything interesting to say. I remember proudly bashing the idea on forums saying things like “what on earth would I write a blog about” as I was cranking out 6 thousand word analysis posts for new episodes of Farscape, or twice as long posts bashing SciFi Channel for sucking and killing all the good series. I guess most of us back then didn’t fully comprehend what exactly blogging was because of LiveJournal.

LiveJournal was one of the first successful (well, as far as you can measure success in therms of usage and popularity – not necessarily profitability) platforms and it used the “online diary” metaphor. It was it’s primary use case, and how it advertised itself to new users and so this is how we viewed blogging in general: as public vanity diaries. By the time I got into this thing I still didn’t fully understand what to do with a blog, but at least I tried. It actually took me a few years to actually get into something of a rhythm and find the voice for this site. And as soon as I did, something unthinkable happened – I have gained some audience.

I caught the wave and kept riding it. I was never the leader of the pack but I’m actually pretty happy with the way things turned out. I got inbound links from Digg, Reddit and few other influential places (and my server crashed and burned each time that happened) and got quite a few interesting discussion threads in the comments. For the past few years I have always had enough readers for the few adds I display here to pay for my hosting entirely and leaving me with some left-over extra change I can spend on like one coffee at Starbucks. I’d say this is pretty good for a site with unintelligible name and no clear focus.

I mean, how do you explain what Terminally Incoherent is about to someone who never visited it in a few words? It’s a blog about programming, and science fiction, and futurism and movies, and video games and anime and… You basically have to list bunch of unrelated topics which have a single unifying theme: they are things I’m interested in writing about. In short, this is a personal blog written by one guy about his nerdy interests. This is very much a vanity diary – something I never thought I would do, and never set out to create. But that’s essentially what I’ve been writing since 2003.

These days it almost feels like I’m the last guy on the internet doing this sort of thing. This kind of deeply personal, ego driven blogging has went out of vogue. It is something that mostly doesn’t make sense anymore, unless you happen to lead a very interesting life as a celebrity or other type of person of interest whose opinions count. Most of the smaller blogs you see these days have a very narrow, topic oriented focus. Most of the successful ones also have more than one contributor.

I have used to subscribe to a lot of blogs with a profile similar to mine, but most of them have been abandoned. It is actually quite sad, but as I was going through my subscription list tying to slim it down in preparation for Google Reader closing I realized just how many sites I used to read went silent over the years without anyone noticing. I guess this is a natural thing – sites go dead all the time and new ones get created to pick up the slack. Blogosphere seems to have shrunk and consolidated itself around big brand names and personalities.

Today it is easier to create a personal blog than it ever was, and yet few people choose to do so. I think part of the problem is that blogs are a commitment. They take effort. Blog readers expect to read – they expect at least few hundred words per post, and it is apparently more than most people are willing to write in a single sitting.

The explosion of social media has changed the personal publishing landscape, and blogs are no longer the preferred medium. They take time to set up and maintain. They don’t come with built in audience whereas platforms such as Facebook, Twitter or Tumblr do. Why run a link blog if you can just tweet interesting links to your followers? Why bother typing anything if you can just share, tweet and re-blog funny pictures using a bookmarklet. Why bother with RSS if you can have your content filtered and cherry-picked via social media or aggregation sites like reddit. The mainstream has moved onto the next shiny thing, and with them went all those who got into blogging to cash in on the popularity of the medium. The kids who thought it was hip and cool to run a pic blog, travelogue or tech news echo chamber (or whatever else was in vogue at the time) packed their bags and moved over to the social pastures.

Who is left? Well there are only two groups of people who blog today: people who get paid to blog, an those who blog for fun. The first group is the larger one – corporate blogs are still pretty fashionable, and allow faceless profit machines pretend like they have a connection with their victims customers. Journalism is moving online wholesale and the boundary between news stream and a blog becomes blurrier every day. Once upon a time we asked ourselves a question: “can bloggers be considered journalists?”. Today that question seems silly and infantile. Of course they can be: sometimes. Not every person with a blog is a journalist, just like not every person who publishes for a print publication is one. It is about what you write and how you write it.

Unfortunately most online “publications” are not really doing anything even remotely journalistic. Journalism doesn’t really get you enough traffic to make your site profitable. Top ten lists and sexy cossplay galleries do. So 90% of the “professionally” produced blog-like content is essentially garbage: click traps, circle-jerks or worse: paid advertising (aka. unbiased video game reviews).

The other group – one which I’m part of – blogs in their free time. Since we do not seek to gain any profit from our sites, we are free to make our content as shitty, or wonderfully deep. Usually we do a little bit of both (I myself tend to err on the side of shitty, but that’s usually just lack of inspiration). The problem with blogging for fun is that while it is a labor of love, it is still time consuming and resource intensive. Writing a blog post that is actually coherent is not trivial (fortunately I picked the right title for my blog so I am exempt from the coherence clause). It does require effort and commitment. It turns out that most people only have a few years of content in them.

I’ve been producing random content on this blog for close to a decade now. People ask me sometimes why I stuck with it for so long, but I don’t really have an answer. It is a creativity outlet. It is a way for me to organize my thoughts. It is a way for me to create a link to the past. Browsing my own archives is like a stroll down the memory late for me sometimes. I might be talking about some video game or programming project and that’s all you see when you read it. But when I read it, I also recall where I was when I was writing it. It is something very public and yet very personal. And after 10 years of doing it, I only now begin to feel like I’m kinda catching the drift of it.

I probably can’t promise you another decade of Terminally Incoherent (cause you know – we might have a singularity event in the meantime), but I can definitely assure you I am in no danger of quitting anytime soon. If it means I’m the last guy with randomly weird and slightly boring blog on the internet then so be it.

That said, when I was going through my RSS subscriptions I was astonished how many good blogs just died in the last few years or turned to absolute shit. Some ended up link farms, others started chasing profits with pointless garbage entries and some simply switched focus (worst thing that can happen to a good programming blog: the author gets promoted to management, and starts blogging about snooze-worthy managerial stuff instead talking about code). Someone asked me to publish my “must read” RSS list, but when I went to compile I was shocked to realized almost all the blogs in my important folder haven’t had any updates in about a year. I was even more shocked that I didn’t notice it until now.

I was quite upset when I found out Google is shutting down their RSS service, but now that I sat down and analyzed my subscriptions with a cool head I must admit that there are shockingly few live sites on there. My OPML is tumbleweed central – a ghost city full of empty husks that were once interesting and thoughtful publications. I guess it puts Google’s decision in perspective.

So out of curiosity, what blogs do you guys currently read? Who would you recommend to subscribe to and follow and why? I want to re-build my RSS collection where should I start?

The problem with this is that TV watching has always been a social experience. With the mainstreaming of social media, many viewers such as me want to engage with friends and community at large via those channels and discuss the on-screen events as they unfold. Many TV networks such as AMC have noticed this trend and actually encourage it by posting Twitter hash tag suggestions during commercial breaks. It is actually a lot of fun to live tweet your favorite show, and bounce around jokes and/or speculations with other fans. But there is always someone in your social circle who is not watching the show right now and wont be able to watch the show for days and thus becomes very upset at all the spoilers in their feed.

You would think that if you happen to be a fan of some show, and friends with many other fans via social media would know better than to wade into the update stream as a new episode is on the air and expect not to be spoiled. But lets say that live tweeting is just a tad bit inconsiderate. Perhaps we ought to leave a small courtesy window between the original air date, and actual posting of the plot revealing spoilers? What should that window be though? Is the morning after an acceptable compromise? Two days later? Next weekend? A month?

The truth is that spoiler-complainers don’t actually want a compromise. They want their social media to be pristine clean and devoid of spoilers forever. They want to watch their shows on their own schedule (as is their right) and want everyone to hold off any and all discussion of said shows until that an undetermined and arbitrary date when they choose to watch them (which I would say is inconsiderate on their part). In fact, if you happen to be followed by a lot of people, almost invariably you will piss off someone who doesn’t even get the show you are discussing in their region. Yes, I have actually been yelled at by someone who never seen Game of Thrones but was considering “maybe downloading it one day”.

So realistically, the only way to avoid the ire of the spoiler-complainers is to keep your mouth shut, and never mention any of the series you like in your social media feeds, ever.

I got fed up by this and decided to do something about it. The simplest and most direct solution to this problem would of course be to gather all these whining spoiler haters, put them in a rocket and launch it into the center of the sun. But since I don’t have a rocket, I decided to code up a solution instead. Something that would allow me to post spoilers in my tweets without pissing anyone off in the process.

The big thing about posting plot twists and revelations in Tweets is that there is really no way to hide or filter them. Forums and blogs have a long standing tradition of using vertical white space (often known as “spoiler space”) to set the spoilers apart from regular post, or change the font color to obscure the text. Twitter’s limited nature does not allow you to do any of that. There is really no way to hide part of your tweet in any meaningful way… Except of the Twitter Cards functionality.

When you tweet a link to a site which implements Twitter Cards, the users can click on it and it expands to reveal an excerpt and a picture from said link. I figured I could exploit this functionality as a crude way to hide spoilers. So the idea was to design a service that would allow one to create a spoiler text, bind it to a unique URL and then automatically tweet that URL along with a non-spoiler teaser message. Let me show you an example – I could tweet something like this:

Spoiler Tweet

The link in the post would then link to a web page like this:

Spoiler

Note that I’m not showing Game of Thrones spoiler as an example for reasons that should probably be obvious by now. The Twitter Cards integration doesn’t work as of yet, because apparently it takes months for that functionality to get approved. The service however does integrate with Twitter so you don’t actually need to sign up for an account to start posting spoilers. You simply sign in with Twitter and you are ready to go.

I’m actually pretty happy with the URL I was able to nab for this service: dontspoil.us. What I really wish I was able to get was spoil.er but unfortunately the .er TLD is not open to the public yet.

This is how it looks

As with most of my projects, this one is Open Source. You can peruse the code at your convenience over at GitHub.

The front end is my usual: clean HTML5 with a little bit of Twitter Boostrap which in this case I’m using primarily for the responsive grid and pretty buttons. I’m also using jQuery which drives some of the Bootstrap effects, and also lets me do very simple validation on user input.

The back end was written entirely in Ruby, using the excellently simple Sinatra as the web framework and Data Mapper as the ORM. I resisted the urge to host it on my old and busted Dreamhost account like I did with MarkdownJournal.com. As you probably seen that host has major stability problems, so I instead opted for something different: Heroku cloud hosting platform.

If you are not familiar with Heroku, it is basically Google App-Engine style service but with slightly different focus and a lot more flexibility. Whereas Google sort of binds you to its own proprietary API and it’s own proprietary NoSQL data storage, Heroku gives you a wide array of options. For example, in this project I’m using PostgreSQL database hosted and maintained entirely on the service, and running in fully distributed mode.

Heroku’s main strength as a hosting platform is the promise of almost infinite scalability, but that’s not really why I set my service up there. I don’t imagine it becoming popular enough to warrant more than a single Heroku dyno and a dev-mode database plan. I mostly made it to solve my own problem and picked the platform because I wanted to learn more about it. I created my Heroku account couple of years ago, when the service was still young but never really did anything with it until now.

I must say it is interesting environment. Working with it is a little weird at first because it doesn’t always behave as you would expect a regular platform to behave. Because if it’s decentralized nature and its limitations there are little quirks you need to keep in mind – like the differences between the way your app runs locally when you test it, and the way it works when deployed to the Heroku cloud.

I fully expected it to be the most annoying part of the project, but it wasn’t. That distinction goes to Twitter. When I was writing the application I kept running into Twitter API rate limits. I didn’t know this when I set out to create this service but each Twitter app is limited to 15 API requests per minute for each unique Twitter user. This of course includes authentication and any look-ups you may want to do.

For example, in the early version of the app I would authenticate the user using the Twitter OAUth, then look up some information about the account that just signed in such as Twitter username, display name and the profile picture URL. This actually counted as five requests, so I could only refresh the page 3 times per minute. If I accidentally made one request too many, I would get locked out for 15 minutes during which all my requests would be rejected. I quickly learned to cache everything and use as few requests as possible but it was extremely annoying at first.

Anyway, the service is now up and running. The Twitter Cards integration isn’t there yet so for now you have to click on the link to see the spoilers. Eventually I’m hoping you will just be able to expand them. This will have double benefit – it will make it easier for users to consume the spoilers, and it will lessen the traffic on my end allowing me to keep the service on a cheep (and preferably free) Heroku plan.

As usual, comments and suggestions are appreciated. If you manage to break the service, please submit a bug report and I’ll get right on fixing it. Or, if you can code in Ruby feel free to fix the bug yourself and just issue a pull request for faster turnaround time.