Wrapping sidekiq into your unicorn process; might be useful for a prototype I have in mind.
"…hard-core players are comfortable mentally manipulating Peggle's complex physics. They can build models about where the ball is going to go, even after the seventh or eight collision. A frustrated casual gamer looks at Peggle and sees chaos; a hard-core one sees causality." Oh – now that _is_ an interesting way to look at things.
This is great: a 25-minute video from Blurst looking at a short prototype they built. During the retrospective, other members of the team question the designers/developers about their intentions, their goals, and examine ways to make the prototype into a better game. There's some good questioning, some nice explanation, and it's a great insight into a process built around rapid prototyping and execution on top of Unity. Interesting to see how another company work on rapid prototypes and then try to "find the fun". Also: making the prototype public is another great piece of explanatory work.
Lovely interview with Dylan Cuthbert, of Pixeljunk, about some of the design processes behind the Pixeljunk games.
"A frequent question people ask us is “how do I transfer my database between my local workstation and my Heroku app?”" The answer is: using taps. Database push/pull, to/from Heroku, and to/from different database vendors. Very, very clever.
05 March 2009
The utility of the original command-line script is now diluted even farther – mainly because you now have to go to the website to scrape the web – but that wasn’t really the point of putting
wotlisten online; the point was to see just how easy deploying to Heroku really was.
The answer is: remarkably so. I wrapped the original script into a little Sinatra application, with two views, and a tiny bit of error handling for convenience. Sinatra’s something I’ve been playing with for a while now: it’s really excellent for wrapping small scripts into little webapps with the bare minimum of extra code, and when combined with lightweight tools like DataMapper, and sqlite, just powerful enough for the lightweight tinkering I seem to do so much of. If you’re a Ruby developer and you haven’t played around with Sinatra, you owe it to yourself to check it out – it’s a lovely library to have in the toolbox.
With the webapp written, I installed the
heroku gem, which helped me create a new remote git branch pointing at my Heroku account. Deployment is trivial – far simpler than using something like Capistrano; all that is necessary is to push my master branch to the
heroku remote, and upon a successful push, Heroku notices that I’ve pushed out a Rack application – and it directs requests to it automatically.
It took about ten minutes to write the Sinatra app, and another ten to get it up and running on Heroku; the single snag I ran into was the same as Tom did – the need to unpack haml into a vendor directory.
I’m very, very impressed. It’s all very well being able to build small, trivial toys like
wotlisten, but it’s often a hassle to deploy or configure them. Heroku really takes most of that pain away, and makes setting a tiny Sinatra app live a trivial task. It’s definitely going into my toolbox – or, perhaps, that should be toybox – for the near future.
I've got a way to go with Abel yet; I can't do FADCs at all, but the earlier stuff looks useful.
The title sequence to a Saturday morning kids' cartoon series. Of Watchmen. It is not, shall we say, particularly reverent. Probably better for it.
Tom's been poking Heroku, and now, so have I. It's proper brilliant: a rackup file, a tiny Sinatra app, and the Heroku gem, and you're building webapps in ten minutes. It's crazy and brilliant, and exactly the kind of thing of which we need more of.
"It’s new fun in some Russian cities, to jump from the bridge with the rope in a big group, when there is no water under the bridge but raw firm ice, also they use to jump at that same moment when the train is going thru the bridge". The pictures explain it pretty well.