A few months ago, I made a commitment to learn the VIM editor. I was primarily an EMACS user, but I wanted to become proficient with VIM since EMACS is not always available I found myself too slow when using VIM. To learn it, I pretty much told myself that I’m not allowed to use any other editor while programming and just immerse myself in VIM. For the most part, it worked. I’ve been using VIM daily for about 4 months now and I’ve gotten used to it… mostly.

I can see the reasoning and benefits of having a separate mode for inserting text, but for me it isn’t as intuitive to use. Maybe my fingers are just to conditioned to be able to write chunks of text and still be able to copy, paste, etc. The way I work, I edit text while jumping around a lot and that mode leads to a lot of hitting ESC to the point where I’m using more key strokes then on EMACS (where the criticism is that it requires mult-combos to do an action such as ‘C-x C-c’). So I found myself editing text, ESC, move around, ‘i’, edit text. For the most part, I was willing to live with that, but the breaking point is that I just kept making mistakes editing. I’d hit ‘i’ when I’m already in edit mode or be typing outside of edit mode leading to typos and jumping to another part of the screen. I figure that 4 months is enough and while I’ll stay with VIM, I’ll likely be in Insert mode a lot and so I want to reduce bouncing back-and-forth between modes.

I made the following changes to my .vimrc to allow me to do things like move around (without using the arrow keys) and copy/paste without leaving Insert mode:

For those who has been asking for the 2.1 SDK since the Nexus One launch, the new SDK can be downloaded here: http://developer.android.com/sdk/android-2.1.html

“Eat your own dog food” is not an uncommon term in Silicon Valley. It means for a company to use the product they built themselves. If a company offers an email product to customers then they should also be using that same email product. It’s not always easy to eat one’s own dog food especially when that dog food provide a critical business functionality or is fairly new. Email, for example, has become vital for companies and they depend on it to be scalable, stable and reliable, but if you’re eating your own dog food you might be using the pre-production version which might not be 100% stable or it’s missing some functionality and which you need to build yourself. Because of this, even though many tech company talk about eating their own dog food, but don’t really pull it off.

I find Google to be very serious about eating their own dog food. Everything released to the public is also used internally and this includes their APIs. Often companies release APIs but don’t use them internally because they have direct access to the underlying technologies. Google does use their own APIs and during my first two months here, I’ve been learning a lot of the APIs in order to do my work. There are some amazing stuff out there and they are all listed at code.google.com.

Specifically, I’ve been learning the Google Data APIs. There is an amazing amount of access to APIs to allow developers to build sophisticated applications so I encourage everyone to try them out!

Even before joining Google, I was already a fan of two of its services: Google App Engine and Google Apps for Domains. Apps itself brings a lot of value and combined with app engine, it’s especially powerful for small business and start-ups. Apps provides the most essential IT pieces for a business (email, office suite, calendaring) and Google App Engine (GAE) allows the business to build their own software on Google’s infrastructure without the heavy initial investment in hardware and IT infrastructure. This post focuses on just GAE specifically how you can programmatically access app engine from a python script.

The code to authenticate against the production instance of GAE is actually fairly well documented by Google on the GAE site. The issue I ran into is that before I push my code live, I wanted to test it on a development instance. GAE makes setting up a development server easy and comes with its own web server and datastore (database), but the one area where the development environment is different from production is how authentication is handled. The development server doesn’t do real authentication. It just sets the right cookie that simulate that you’ve already logged in. I wanted to write my code with minimal differences between how it calls production and how it calls the localhost. Authentication to your application on production means that you need to get a token from the Google servers, but this doesn’t exists on the dev environment. Looking at how the developer instance handled the login screen, I was able to do the following:

That all there is to it!

I’ve been trying to set up my VIM environment to be more comfortable for me so I can be more productive. It’s getting better although I still miss having a shell inside the editor that EMACS provide. Here is my current .vimrc:

I use 2 plugins: TagList and Bufexplorer along with Exuberant-Ctags to make moving around the code easier.

Sometimes I want to have my bash script behave differently based on how I call it without having to set up different parameter inputs. For example, I might have a script that can sync a file from a local server to one of two remote servers. I can make my script to take in parameters so I can call it using ’syncfiles -h serverA; syncfiles -h serverB’, but sometimes I forget what my params are and it’s easier to remember ’syncToA’ or ’syncToB’.

To do this is pretty simple, yet I always have to look it up each time so I’m writing this as note to myself.

Next, create symlinks to the original source files with the names you chose (i.e. ’symlink syncToA syncfiles’).

As pretty as GUIs are, sometimes it is most efficient to work in a text console which is why I find myself using GNU Screen. However, Screen’s command starts with CTRL-A which is also Bash’s move to start of line command. To have it work, use ‘ctrl-a a’.

Also, screen sets the value of TERM to be screen so if you have any settings based on the TERM value, update it appropriately.

One thing about using screen is that you lose your terminal’s scroll buffer so as line scroll past your view you can’t just use the scrollbar to move up to see what you missed. Instead, screen has it’s own scroll buffer that you can use. You can set the buffer size using ‘defscrollback #’ (where # is the number of lines) in your .screenrc or in the screen command line (ctrl-a). You can switch to the buffer with ‘ctrl-a [‘ (and exit buffer mode with ESC). Navigation follows normal VI keys.

Finally, I noticed that hitting the delete key didn’t send backspace as expected with using the OSX terminal. To correct that, add the following to your .screenrc:

This tip came from here.

To help me learn VIM keys, I put together a cheat sheet which I load onto my desktop much like how I handle my calendar/todo.

I’m not sure how much this cheat sheet will help others because I left out the commands that I already know well and left the commands that I’m currently learning. I expect that I’ll update the list as I get more familiar with VIM.

I’ve always been an EMACS user on UNIX and it sometimes seems like it can do EVERYTHING. The one problem with EMACS is that a lot of production systems (and even many non-prod) won’t install it which means that when I’d have to use vi/vim and I’m just not as fluent with it. Especially since when I’m on those systems means that I’m trying to do fast debugging and navigation, being slowed down by my lack of experience with the editor is really frustrating.

I’ve decided to try to switch to VI/VIM to be the primary editor for awhile to force me to learn. There is no need to tell me that EMACS kicks butt (I agree), but unless you can get emacs installed everywhere, this is really more a decision based on my current situation.

Terminus is a very nice looking font that is well suited for programming editors and terminals.

It is an open source font and many linux distributions have it available. I haven’t tried any for OSX, but you can compile for xterm on OSX/X11 from macports.