Friday, July 18, 2008

Vim Tips, part 1

Because I'm such a fan of Vim, and because I have people asking me about it quite often (for tips, general questions, etc.), I figured I'd write a two-part article on the greatest text editor in the world.

There are innumerable key combinations in Vim (well, they are in fact finite, but numerous), so I thought I'd describe the ones that I use most often and find the most useful:

Navigation

  • h, j, k and l - Move left, down, up, or right.

  • gg and G - Move to the top or the bottom of the file.

  • ctrl-u and ctrl-d - Move up or down one half-screen.

  • w and b - Move forward or backward, one word at a time.

  • fX, FX - Move the cursor over the next or previous occurrence of X in the current line, where X is any character.

  • tX, TX - Move the cursor to (not over!) the next or previous occurrence of X in the current line.

  • 0 and $ - Move the cursor to the beginning or end of the line.

  • ^ - Move the cursor to the first non-whitespace character of the line.

  • /[string] and ?[string] - Searches forward or backward for [string].


Tabs

I love tabs. They're a new feature in Vim 7, and I instantly became dependent on them. Here are the commands for using them:

  • :tabe [file] - Open a new tab editing [file]. Don't specify [file] to open a blank tab.

  • gt and gT - Move to the next or the previous tab. If already at the last or first tab, wraps
  • around.
  • Ngt - Move to the Nth tab.

  • :q - Closes current tab.

  • :qa - Closes all tabs and exits Vim.


Editing

  • d - Deletes in the direction of your movement. E.g.: d$ deletes to the end of the line, dw deletes to the end of the current word, dF[ deletes backward to and including the next '[' character.

  • dd - Deletes current line.

  • rX - Replaces current character with character X.

  • ~ - Toggles capitalization of current character. If in visual mode, toggles capitalization of highlighted block.

  • s - Deletes current character and enters insert mode.

  • i - Enters insert mode.

  • a - Moves one character forward and enters insert mode.


Folding

Folding is incredibly useful. It's great for getting large blocks of code out of your way in annoyingly long class files.

  • zf[movement] - Folds lines in direction of [movement]. E.g.: zfG folds all lines from the current line to the end of the file. For [movement], you can also use text objects.

  • zf - In Visual mode, will fold the currently selected lines.

  • zo - Open the fold under the cursor.

  • zc - Close the fold the cursor is in.


Other Tips

  • :% - Replaced by current file. You'll see how this is useful below.

  • :![command] - Execute [command] in the shell. E.g.: !php % - runs current PHP script, !ls - lists files in current directory, !php -l % - checks syntax of current PHP script, !cp % %.bak - creates a backup of current file.

  • :nohl - Turns off highlighting, if it's on. Depending on your Vim's configuration, doing searches (with / and ?) highlight all matches. This will un-highlight all search matches.


This may seem overwhelming if you're new to Vim, but it becomes second-nature as you get used to it. I did not have to check the Vim documentation at all to write this blog post. It is in fact possible to become accustomed to using so many (useful!) Vim commands. Of course, these aren't all I use, but just the most common.

Next post, I'll discuss my .vimrc file, which contains tons of configuration that makes using Vim a lot easier for me. Perhaps you'll be able to use some of my settings to help you, too.

Friday, May 9, 2008

Simplist Launches

So I've been working on a new project lately. I threw it out there for a few friends and on a social news site I frequent for suggestions. I got some great feedback and tweaked many things that made it easier to use and more powerful. The site is live and there are already many active accounts, though I'm still making feature additions and changes as I figure out what works and what doesn't. I'd love to get some more feedback. Check it out:

http://mysimplist.com

Thursday, April 17, 2008

Profiling by Command History

I read a blog post about seeing what commands you use most in your shell. So I went ahead and executed the convoluted awk command to give me a pretty list:


[lucas@sarpedon ~]$ history|awk '{a[$2]++} END{for(i in a){ \
> printf "%5d\t%s \n",a[i],i}}'|sort -rn|head
193 vim
143 ssh
129 ls
108 clear
91 cd
69 screen
65 ruby
34 time
22 scp
19 top


And I got to thinking about how this can say a lot about how I use my computer and how I do my programming. First of all, it's obvious what text editor I use to code--Vim. Second, I obviously do a lot of my coding on other servers, since ssh is the second-ranked command. I use clear a lot because sometimes my CPU gets hot (Thunderbird has an annoying bug that causes it to top off my CPU for minutes at a time), which prints warning messages in my terminal window.

Anyway, sort of a silly diversion, but interesting nonetheless. What commands do you use most often? What does it indicate about your habits?

Tuesday, January 29, 2008

Why Use OO design?

There are several paradigms for organizing and writing code for a web application. I hate to use the word "paradigm", though, since it's a two-bit word, and some common paradigms I've seen aren't worth twenty-five cents.

Hopefully, if you're reading this article, you've already read the others, especially the one on The Basics. In that article, I give a list of important things to keep in mind when developing a web application. I give some superficial advice on how to adjust your design to meet these goals, but now I'm going to give you the best solution that exists at this moment, and it will probably remain so for a long time--the object-oriented (OO) paradigm.

For many of you, especially those who have no formal training in software development, the subject of object-oriented programming (OOP) may automatically turn you off. I can promise that it's not as difficult as the old Java dinosaurs would like you to think (they're looking for job security, you know), and any effort you put into learning OO principles will be repaid ten-fold when you write your next app. Let's see why.

Parallel to my Basics article, I'll cover each point and explain how OO design applies.

OO design makes it easier to code additional functionality in the future.

Everything in a well-designed OO application will be modular and separated from code that does a different task. It also makes following the "black box" principle a breeze. Once you code something that works and has a well defined interface--like public functions (methods) and what those functions get and give back in return--you don't have to look at the internals again. In fact, the rest of your code that may use this "black box" doesn't care what the internals are, either.

This also has the implication that you could code support for a certain feature into your application before you even code the feature itself. This is a great way to force yourself to stick to the "black box" principle and sketch out well-defined interfaces before starting to code a module.

- OO design follows the DRY principle by default. The easiest and most obvious way to follow the DRY principle is to factor your code into functions. OOP forces you to do this, to an extent. At any rate, learning OO principles will also help you think in this direction, even if you're not forced by the paradigm to factor your code.

- OO design requires that you correctly identify relationships in your data. Yes, it's true--sometimes OO programmers get it wrong. It's easy to do. But if you're thinking about everything in terms of objects, sometimes real-world ones, then you'll have a better perspective for accurately seeing these relationships.

OO design makes it easier to maintain your code.

As I mentioned above, using OO design turns your application into a bunch of "black boxes". If you change something in a module, as long as you leave the interface the same, no other code will be affected by your changes. This is a huge time saver. You don't have to lay awake in bed wondering if you've broken some completely unrelated part of your application.

- OO design helps you separate data from code. If your models are the only objects that are tightly related to your data, then most of your code will satisfy this requirement automatically.

- OO design helps you keep things organized. I've gotten confused trying to figure out a 10-page site coded using the "page-by-page" method (which is dreadfully popular). If an OO app is well-designed, even if it has a hundred features, you will be able to navigate the code and find what you're looking for quickly.

OO code is often usable in other projects.

This is an area where OO design really shines. How complicated is the idea of a category? Really, you could code something like this once, and use this code in every project that uses categories. Modular code is reusable, and everything in an OO application is modular.

To conclude...

I hope that I've convinced you that OOP is worth a careful look. Even if you never use it, after learning it, you will be a better programmer. Of course, I can't teach OOP in a single article. There are many, many helpful resources out there for learning about OO design, and I won't dare to try to trump them on my blog. Google is your personal research assistant, and he's just itching for something to do.