sazzal

The reason you need to really care about memory management in game development is because most of the consoles don't have virtual memory. Once you run out (and you don't have that much), your game stops working. It's very similar to embedded system / real-time programming in this way. So you need to plan out how much space everything will use in advance, basically. Lots of fixed-sized buffers and pool allocators.

And the reason you don't use garbage collection is because real-time games can't afford a GC pause.

You can still think of data as 'rows' with MongoDB - objects belong to a collection, which is analogous to a table - and you can query and select only specific fields. The advantage is that you aren't nearly as restricted in the kinds of data you can build. SQL often forces you to split logically related data across several tables and wrestle with complicated joins, simply because a row can't contain sub-arrays or hashes.

Of course, there's no silver bullet - some times you DO want to group together logically different data in a same query. But I've found that in general, I'm not fighting the DB as much when building stuff using MongoDB.

Right now I just don't download random OSX apps for fun. I only download applications that I really need - and I make sure it seems like a reputable company. And I certainly wouldn't download fart apps, or a lot of the other 5-second novelty apps that have a lot of traffic on the app store.

The first time an OSX app store has malware in it, it's going to be big news. And it's going to make Apple look bad, since by putting it in their store their effectively condoning it.

Forgot to mention - the jobs website is http://www.mediagobbler.com/about/jobs

Senior Full-stack Rails Developer - Hollywood, CA, USA

Music professionals are stuck with horribly archaic and kludgy ways of managing their music and collaborating. We're trying to fix this at Gobbler - building a downloadable, networked application that solves these problems for people who create and work with music. Think Dropbox + Yousendit + Source control - all tailored to work with multi-gigabyte music projects.

We're in closed Beta, but are getting ready for a public launch in the next 6 weeks. All of our work has been done on the downloadable application and the backend, so the actual website is pretty ugly (did I mention we're also looking for a Designer?). But we're using a lot of cool technologies, like MongoDB, Node.js, Redis, etc. And you get to work with a small team of very smart people. Plus, we're very well connected to the music industry - it's pretty amusing getting feedback directly from some of the biggest names in music.