q <macrokey> <do some stuff>; then q to stop recording. Then @<macrokey> to kick off the macro. Splendid.
53 karma · joined October 3, 2010
q <macrokey> <do some stuff>; then q to stop recording. Then @<macrokey> to kick off the macro. Splendid.
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.
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 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?
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?