One of the features that really got me into Vim was the macros feature. I actually ran into in accidentally several times when I was first learning the basics (and couldn't get out of recording mode). But macros, and especially the temporary nature of macros, have saved me (collectively) many hours:

q <macrokey> <do some stuff>; then q to stop recording. Then @<macrokey> to kick off the macro. Splendid.

I don't meet many other vim users who like macros but recently I've had call to use them daily. They completely remove any repetitive text editing actions, even relatively complex ones like "take these words, each on a new line and make them keys to an array, with the values initialized to ''"

The only problem is that they take a lot of practice before you get them right first time. After a while though, you learn to record them fairly quickly and they streamline your workflow. They also melt the faces of anyone pairing with you.

The best part is they get better with age. The more vim commands you know, the more opportunities you find for using them.

As a new vim user, I'm still trying to figure out what to do with them.

What do you find yourself macroing, generally?

For me the most important thing was learning to add a 'j' at the end of each macro and running it multiple times. So lets say you want to crack open an array that looks like this:

    $address = array(
     'name'  => '',
     'line1' => '',
     'line2' => '',
     'state' => '',
     'country' => '',
     'postcode' => '',
    );

That's a lot of commas and quotes etc. Nowadays I usually punch this into vim:

    name
    line1
    line2
    state
    country
    postcode

Then I start on the first line and record a macro that wraps that word in quotes, then appends hashrocket, quotes, comma, and then moves to the next line. Run the macro 5 times with 5@<register> and the you get your array.

If you're a heavy macro user, you might find `:noremap <Space> @q` to be handy. Just stick your temporary macro in q (the easiest one to stick it in :), then press the spacebar to run it whenever you want.

According to Aristotle, we uncover theoretical knowledge by exploring that which has no practical (action-based) or productive (product-based) result; and what we possess is that which is known only for its own sake, for the sheer pleasure of knowing.

I've often thought a similar distinction can be made in engineering, where the product is created for its own sake, for the sheer pleasure of seeing it exist. This is one of those. An amazing piece of work. Bravo.

I made the jump from Objective-C/Cocoa development to web app development after Startup School this year. Two things surprised me when I really got down to coding my initial project. First, the sheer number of technologies involved in developing my web app. For me, that's Ruby on Rails, Javascript, jQuery, Ajax, HTML, CSS.

Second, the lack of integration between the various technologies was surprising. I often knew what I wanted a particular page to do, and the solution was to learn a new technology, and then figure out how to shuffle data between the new technology and those technologies I was already using.

Integration problems also crop up in the form of mismatches between technologies. For example, I use bignum integers in my code; but ran into all sorts of interesting problems: Ruby/Sqlite work fine; but as soon as I uploaded the app to Heroku, I uncovered issues with how these integers were being stored in the PostgreSQL. And Javascript needs special routines if it is going to handle bignums. I haven't encountered this sort of mismatch on the desktop.

That said, now that I've got a working app, I think the learning curve was in some ways (though not all ways) less steep than the desktop. A couple of reasons for this, I think:

1) The communities share code prolifically. It is not that there is no code sharing going on in desktop development, but code sharing seems much more prevalent in web development. As a new web developer, this makes my job a lot easier not only because I can just plug in code, but also because I can read that code and learn from it.

2) You can get minimal results quite quickly, which is very encouraging. Again, you can get minimal results quickly on the desktop, but the standards are different on the web. In my experience, a desktop app needs a lot more to be minimally functional than a web app, probably because the level of complexity is different. Yes, web apps can be just as complex as desktop apps; but I think a minimally functional web app is in many ways less complex than a minimally functional desktop app. Just think about all the menus, help files, and other accoutrements you need to get a desktop app minimally functional; web apps can get away with less.

3) The web technologies I depend on are more modern. Compared to Objective-C/Cocoa, Ruby is like a dream. Javascript and less so, but only because it seems more like what I'm used to on the desktop. What can I say, I like syntactic sugar and the readability that comes with it.

So, perhaps web programming is hard, but there are several ways travelling the path is made easier - maybe even easier than on the desktop.

I guess one of the things I'm wondering is whether there is room for a game that is text-based. On the one hand, I like the semi-retro feel, since it is based on a classic game. but on the other hand, I'm wondering whether a text-based ui will prevent the game from getting any significant traction.

One other question: I am using authentication through Facebook and Twitter. Not having to manage accounts (recording e-mails, making forgotten-password functionality, &c.) allowed me to focus on the game itself.

Do you think this authentication method will cut down the number of people who will play the game? Or could not having to sign up, specifically, make people more likely to play?

Ah, but the way the authentication works, you are not actually giving me a Facebook/Twitter password. You actually log in through their systems, and then they let my website know that you are authorized. I never get the password information.

I use the same system used on http://decafsucks.com/login. The authors suggest (perhaps some bias here) that one of the reasons decafsucks.com has had success is they were able to avoid asking for yet another password, and instead piggy-backed on Facebook/Twitter.

Do you think assuring users that I don't get the password (you can see this when you click on one of the login options) is enough, or should I get to work on a separate authentication system?

Sorry if nobody likes this (by the downvoting) but it's the way things are.

Is exactly the same problem with the authentication in AppEngine applications. We never see the passwords, just Google telling us this person is really this user, but people don't care about the details, we just don't want to share our passwords.

Note that I myself have to use this scheme and even I didn't check your web just because of the authentication problem.

This makes me remember to tell you one more thing: don't ever expect your users to read anything you write on your web.

EDIT: Also, it's a bit silly, but try to put some screen captures to get more conversions, even if it's a text based game.