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.

same thing we used to do on supercomputers, allocating memory is very expensive and surprisingly limited.

You also don't want your code to fail after weeks of runtime with an alloc error, if it's going to run out of memory you want it to fail at the start.

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.

<quote>simply because a row can't contain sub-arrays or hashes</quote>

This is not true at all. At least in PostgreSQL you can have arrays and hashes:

http://www.postgresql.org/docs/current/static/arrays.html

http://www.postgresql.org/docs/current/static/hstore.html

Have you actually looked at or used the array stuff in postgres? It's pretty horrible syntactically and worse, very explicit in it's recommended use.

"Tip: Arrays are not sets; searching for specific array elements can be a sign of database misdesign. Consider using a separate table with a row for each item that would be an array element. This will be easier to search, and is likely to scale better for a large number of elements."

Searching an array is a pretty common task, Mongo does really well in its ability to search into objects in a document.

I had to laugh a little at one of the sample queries:

SELECT f1[1][-2][3] AS e1, f1[1][-1][5] AS e2 FROM (SELECT '[1:1][-2:-1][3:5]={{{1,2,3},{4,5,6}}}'::int[] AS f1) AS ss;

Seriously?

Yes I've looked at them. I use them every day. The example you posted its difficult to parse because it deals with multidimensional arrays and also populating one in the inner query. The simple, and much more common case of one dimension arrays is very straightforward. Can you show me the equivalent in MongoDB?

About the performance/scalability warning; I don't deal with very large arrays, a couple hundred items max, and when using a GIN index over the array field, search queries are screamingly fast.

Sure, check out:

http://www.mongodb.org/display/DOCS/Dot+Notation+%28Reaching...

I do not think that this is equivalent, it looks like querying complex JSON objects and not "simple" arrays.

From the "Array Element by Position" example:

  db.blogposts.find( { "comments.0.by" : "Abe" } )

PostgreSQL doesn't have JSON support but it does have XML/Xpath support.

If you stored XML documents in PostgreSQL the similar query to the MongoDB one would be something like this:

  select * from blogposts where (xpath('/comments[0]/@by', doc))::text[] = array['Abe']

Yes it's a little more verbose but not terrible so... at least in my opinion.

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.

When that happens, Apple will devote its considerable resources to making the offender wish he was dead (he had to give up his information to get into the Mac Dev Program, remember?), and then it won't happen again.

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.

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