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.
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.
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?
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?
q <macrokey> <do some stuff>; then q to stop recording. Then @<macrokey> to kick off the macro. Splendid.