MULE never gets old. I've been playing since not long after getting out of diapers, and now I'm changing my own kid's diaper (no not while typing). MULE never left. Well, to be fair it wasn't as good around the late 90s up until PlanetMULE, because it was hard to get any friends to play on emulators...and when I tried the network play would always screw up, so I only played about once or twice per year. Still fun just not as good without the human element. Now I can play PlanetMULE with them, and there's extra fun stuff like a tournament ladder and records of play, I'm having a blast and I try to play whenever I can.
I'm still laughing at the random events that transpire, seemingly always at the worst or best time, depending on who you are; still cheering at an especially good production or market price, especially when I know I cleverly manipulated the market; still cursing when I miscalculate my time limit and miss the pub or I get shafted in a land auction; still grinning when my I squeak by with a first place win, revealed by my dude running along the bottom of the screen ahead of the three other players; still reacting in pleasant surprise or abject horror when the store catches fire - more groans or smiles after mentally assessing whether that screws me or allows me to screw others!
I have yet to reach the highest level of colony success! I think I only achieved second best once! One of my goals with this new game will bet to play selflessly with three other good players to see if we can achieve an awesome colony score. Can't wait!
(Overall, the colony delighted the Federation with your exceptional achievement. Your retirement will be luxurious!)
I agree 100%. Unfortunately, to many folks, the distinction isn't quite so clear as dishwasher vs. laundry machine. As a friend once told me, without any knowledge of our requirements, "Your company is pissing away tens of thousands of dollars on Oracle, when you could use MySQL for free!"
A very Republican relative of mine was ranting and raving at the TV before the election. He had on CBS news, and was screaming about how this one anchorwoman is so biased that 72% of her positive comments are pro-Obama. Apparently, in order to be unbiased, her positive comments should have been split 50/50.
Sigh...And all the developers had to do was use binds, which actually make programming easier, too. I wonder if they wrote code to handle the dreaded apostrophe.
I've given simple tests to newbies coming right out of college. If you're applying for a database developer job, but you can't tell me what a transaction is, or what's the difference between the types of joins, I don't want you.
Another interviewee couldn't create a function that returns the items that are in Set A but not set B. He had the option to use any language, pseudo-code or English. Oh and he claimed to have over 10 years of experience as a developer.
I think it was worth spending a matter of minutes to weed out these people.
Can't speak for the others, but in Nethack your death usually comes within the hour, or if you do really well, within several hours. You groan, check out your high score, and start again. Plus the game is mostly about handling random situations, so a replay of levels 1-n isn't going to feel too repetitive (others may disagree).
Caffeine can help your brain...Caffeine can cause hypertension. Water can quench your thirst...Water can drown you. A hammer can be used to put together a shelf...A hammer can be used to bash in your skull.
WTF, first you said they're good, and then you said they'e bad! Science is a load of BS!!
TG-16 had quite a few great, unique games! They had:
- a slew of side-scrolling shooters, among the best ever made (Blazing Lasers, Super Star Soldier, Raiden, Macross 2036, to name a few)
- a couple of great pinball games (Alien/Devil Crush)
- The Bonk series was great
- Dungeon Explorer which was basically 5-player gauntlet with RPG elements
- That racing/RPG combo game was fun
- Dragon's Curse
- Battle Royale - 5 player wrestling madness
- Legendary Axe I/II
- Military Madness (like Advance Wars but older)
I'm sure I could think of more...
Race and level of income are a couple of the basic variables you control for...At least if my knowledge learned from that "research methods in sociology" (as a comp sci major) class actually means anything.:)
"Does it immediately evict the old versions to the "undo" space during a transaction and direct other clients to it?"
The data is updated in place, but a the old row is copied to the undo tablespace. There can be quite a lot of I/O against the undo tablespace. It should be on a fast RAID, or perhaps a separate disk. According to that Tom expert I mentioned, a typical configuration is to put it on a RAID 0+1 ("rollback" is kind of the old name):
o raid 0+1 for rollback. It get written to lots. It is important to have
protected. We cannot multiplex them so let the OS do it. Use this for
datafiles you believe will be HEAVILY written. Bear in mind, we buffer writes
to datafiles, they happen in the background so the poor write performance of
raid 5 is usually OK except for the heavily written files (such as
rollback).
It is true that something like vacuuming needs to be done under the hood - really it's just that the undo data needs to be purged so the undo tablespace does not grow indefinitely. I don't believe old undo data gets much "in the way" because it is not scanned like a table. (I'd have to bring out the docs to give you more detail.) You can set an UNDO_RETENTION parameter which is the number of seconds to retain the undo info for each transaction. You may want to keep this data around for a long time, even after your transaction is finished, to allow for flashback querying (basically "select * from mytable as of 2 days ago" or "flashback table mytable to last week").
What's most important IMO is that updates don't create clutter in the table itself. In Oracle, if you update 1000 rows, all other users are directed to undo if they query the same 1000 rows - for the length of your transaction only. Keep in mind that the undo data will likely be found in memory, in the buffer cache. It needs to be on disk too, though, in case of an instance failure - when you start up the database instance it will rollback all in-progress transactions.
In Postgres, if you update those 1000 rows all other users are directed to the dead tuples - again these blocks are likely in the buffer cache. I don't believe there is any performance difference here. BUT, when your transaction finishes and the dead tuples are still in the way, that's when the Postgres way becomes a problem. Now imagine 1000 rows are updated by a different user every few minutes. It piles up. A regular VACUUM will reclaim the space, but your table may still be fragmented. There is another command, VACUUM FULL, which will compact the table to a minimum number of blocks, however this is a much slower operation and requires an exclusive lock on the table, i.e. you don't want to VACUUM FULL during active hours.
"The Sony story is really quite interesting -- I had no idea that there were major MMORPG's running on postgres! (though a highly modified version no doubt):"
Agreed - we're talking Everquest II and Star Wars Galaxies! I've been meaning to check out EnterpriseDB but haven't had the time...
I've used Oracle for about 3 years and Postgres for about 1. Both are good databases. I may write what you're asking for eventually, but don't hold your breath.:) Here are a few thoughts off the top of my head that might help.
In a way-oversimplified nutshell, Postgres seems sorta-kinda modelled after Oracle. But many times I look into a feature that I've used on Oracle and find it doesn't exist in Postgres or it's not up to my expectations. The Postgres feature might be a little half-assed. One example is the multi-version concurrency control. If you update a row in Oracle, the undo tablespace contains a snapshot of the old version. All other concurrent users are directed to the undo tablespace until the transaction completes. They get the old version of the uncommitted row from the undo tablespace. Postgres on the other hand makes a new row in the table for your update, and the old one is marked as a "dead tuple" whose data can be retrieved by other transactions.
Might not seem like a major difference, but you'll have to "vacuum" your Postgres database periodically to clean up your dead tuples. Otherwise, table scans have to scan over all the dead tuples in addition to the "real" data. Some DBAs simply run a vacuum job every night, or use the auto-vacuum daemon. It's not always so simple however. Imagine you have to update data every morning and get it done ASAP. Well, now that you've updated your 500,000 rows, you have to vacuum the table to keep queries running at a decent speed. When I was still a Postgres newbie, I would just vacuum whenever I remembered. One time I forgot about it for a few days, when I finally ran the vacuum it took 17 hours to complete - granted it was a one disk server. It's just another thing to worry about.
Once I looked for a replication solution for Postgres. Some were incomplete. Slony-I - the most popular Postgres replication solution - seemed like the way to go. But upon delving into it, I found it imposed limitations because it sort of "corrupts" the Postgres data dictionary. I believe this corruption broke triggers on all replicated tables (don't quote me on that). Also Slony-I does not support multi-master replication at all.
Sometimes a feature is just great. Rarely is the Postgres feature better, except in terms of user-friendliness. For instance the psql command line tool blows sqlplus out of the water IMO. (Wow, paginated results, tab completion!)
Oracle has a wealth of OLAP/business intelligence features that are lacking in Postgres. There is a flavor of Postgres called Bizgres that is a bit better in this area, though still lacking in comparison. Bizgres is more cutting edge and doesn't seem to have nearly as strong a community as Postgres. Go to http://www.bizgres.com/bb/ and you'll see there are very few posts.
Oracle has an expert named Tom - asktom.oracle.com - who is a genius and answers all my questions. Postgres has an expert, also named Tom, who is a genius and answers all my questions on the newsgroup.
When would I use one over the other? Personally I would use Oracle if there were no budgetary constraints, but if Postgres definitely met all my requirements, I'd go with that. (Yes yes, I am Captain Obvious.) If you need Oracle's enterprise-level features then Postgres is out of the question. There is however EnterpriseDB, a commercial, Postgres-based enterprise-level database. Several months ago Sony "snubbed" Oracle and went with EnterpriseDB for its MMORPGs. I have not looked into EnterpriseDB myself so I can't comment further.
Well I'm rambling and not getting work done. Hope that helps just a little bit.
Oh yeah? Well [contrives test query using insufficient hardware for Oracle, ignores transactions/logging/concurrency controls/scalability/advanced query options/etc.] my tests indicate that MySQL is 1057 times faster than Oracle! QED
I was referring to materialized view query rewrite, where if a MV can answer your query and the MV is fresh enough for your stale tolerance level, the MV will automatically be used instead...
I switched from Oracle to PostgreSQL. I miss summary management (materialized views, dimensions, query rewrite), various ETL features, streams, data guard, updatable views, multi-table inserts, log miner, flashback, database links, packages, automatic workload repository, OEM, and the several months of my life I spent working around PostgreSQL's lack of anything comparable to these features. (I'm not just listing random features - I've wished I've had all of the above at some point...) PostgreSQL is nice for what it is though - a solid, scalable open source database. And psql is much nicer than sqlplus (tab completion - woo!). And I don't think I've ever gotten the Postgres equivalent of an ORA-600...
You could have four players on Commodore. During auctions and land claim, the two keyboard players used keys on the left and right side of the keyboard. Wasn't a big deal because during auctions you only need up/down controls (2 keys) and during land claim, a single button was needed. During the main turn, you grabbed any joystick.
The Atari version was almost a beta version. The debugged and refined game became the Commodore version.
When you got a Planetquake event on Atari, in addition to halving mining production, there was a "feature" where a mountain would occasionally move and a MULE would disappear. This was removed for Commodore.
I would say MULE as well, but I got tired of single player games a few years ago. If only I could round up some players...
Lately it's been Realmspeak, which is a software version of the classic Avalon Hill fantasy board game Magic Realm. I've been meaning to bring out the board game for my friends for a while now, but the game is so complex I haven't had the time/patience to re-learn it. Now Realmspeak is practically doing the teaching for me. Soon I can teach my buddies! Amazing game.
I return to Nethack (Slash 'EM variant) from time to time. Still haven't beaten it without cheating.
It is my opinion that database independence is a myth, and not necessarily something to strive for, regardless of how great your ORM is. Copying a post I wrote elsewhere (slightly revised):
Over the past decade or so I've worked with several RDBMSs: Oracle, Postgres, MS SQL, DB2, Sybase, Access (if that counts) and a little MySQL (wasn't a fan). If there's one thing I've learned is that each database has a fundamentally different architecture, and database independence is NOT easy to achieve. I'm not even sure if it's desirable.
Switching databases has always been a big, big deal in my experience. This coming from a guy who started on the completely opposite end of the spectrum. I did everything generically - this is just the perspective I was taught in college and literature (black boxing and all that). The first way I ever used a database was by querying MS-SQL doing "select * from mytable" and iterating through the results. I realized that was stupid and learned this whole SQL thing. I learned about ANSI SQL and how I should try to conform to this standard to achieve independence. Then I realized I was using the lowest common denominator and achieving poor results. And coding became much more difficult - had to check against the ANSI standard before using a particular feature: "Darn, x isn't 'ANSI'? Well, I'll do it the hard way..."
If you just replace one database with another, plug-in style, you're going to notice differences (perhaps "bugs"), even with the latest and greatest ORM. With the exception of trivial applications, these differences will affect your application, possibly drastically. For example, you have two users running a transaction on the same row(s) of data. Due to fundamental differences in concurrency mechanisms, Sybase might deadlock (and so one user is rolled back and gets an error) while Oracle runs smoothly. Or MS SQL will give you one answer while Postgres literally gives you a different answer to the same query! And yes, I'm talking about setting the same isolation level in your ORM...
If you use DB2, you're going to have to use repeatable read isolation to get a consistent result set. Not the case with Oracle.
Database A may give you non-blocking reads; Database B does not. Therefore your app plugged into database A may run just dandy. You switch to B and your users complain of slowness. Maybe you then conclude that Database B is bad, but really the problem is that you perhaps unwittingly designed for Database A, thinking that you were database independent all along.
Many developers want to treat the database as a black box - they feel they don't need to know anything about it - they believe they should AVOID knowing anything about it in order to be good object-oriented programmers. The culture supports this notion with terminology such as "data store" and "persistence layer" - just a place to plop down your data and take it out again later, as if it were spreadsheet. In reality, most RDBMSs are very robust with countless features to manage, manipulate, safeguard, and serve your data to many concurrent users.
Why not use the features that make your database special? If you're using a commerical database, you paid a lot of money for these features. Why use the lowest common denominator? Using Oracle's analytic queries I've seen queries run literally orders of magnitude faster than lowest-common denominator queries with Java code on top. I've seen an overnight job transformed into a sub-minute job by using native SQL that lets you do, through a single query (not row-by-row): "If a row having the matching ID exists, update, else insert".
I find it much easier to rewrite the database API (stored procedures) entirely than to deal with the above issues. I've used ORM in the form of Hibernate, in order to solve the database independence problem (wasn't my choice), and I found the cure was worse than the disease - I'd rather translate my 100 PL/SQL functions to PL/PgSQL (maybe a bad example as they're nearly identical - or maybe a good example
Slashdot Mirror
Just bind!
MULE never gets old. I've been playing since not long after getting out of diapers, and now I'm changing my own kid's diaper (no not while typing). MULE never left. Well, to be fair it wasn't as good around the late 90s up until PlanetMULE, because it was hard to get any friends to play on emulators...and when I tried the network play would always screw up, so I only played about once or twice per year. Still fun just not as good without the human element. Now I can play PlanetMULE with them, and there's extra fun stuff like a tournament ladder and records of play, I'm having a blast and I try to play whenever I can.
I'm still laughing at the random events that transpire, seemingly always at the worst or best time, depending on who you are; still cheering at an especially good production or market price, especially when I know I cleverly manipulated the market; still cursing when I miscalculate my time limit and miss the pub or I get shafted in a land auction; still grinning when my I squeak by with a first place win, revealed by my dude running along the bottom of the screen ahead of the three other players; still reacting in pleasant surprise or abject horror when the store catches fire - more groans or smiles after mentally assessing whether that screws me or allows me to screw others!
I have yet to reach the highest level of colony success! I think I only achieved second best once! One of my goals with this new game will bet to play selflessly with three other good players to see if we can achieve an awesome colony score. Can't wait!
(Overall, the colony delighted the Federation with your exceptional achievement. Your retirement will be luxurious!)
I agree 100%. Unfortunately, to many folks, the distinction isn't quite so clear as dishwasher vs. laundry machine. As a friend once told me, without any knowledge of our requirements, "Your company is pissing away tens of thousands of dollars on Oracle, when you could use MySQL for free!"
A very Republican relative of mine was ranting and raving at the TV before the election. He had on CBS news, and was screaming about how this one anchorwoman is so biased that 72% of her positive comments are pro-Obama. Apparently, in order to be unbiased, her positive comments should have been split 50/50.
It wasn't even the PoA. http://www.snopes.com/politics/obama/anthem.asp
Sigh...And all the developers had to do was use binds, which actually make programming easier, too. I wonder if they wrote code to handle the dreaded apostrophe.
I've given simple tests to newbies coming right out of college. If you're applying for a database developer job, but you can't tell me what a transaction is, or what's the difference between the types of joins, I don't want you. Another interviewee couldn't create a function that returns the items that are in Set A but not set B. He had the option to use any language, pseudo-code or English. Oh and he claimed to have over 10 years of experience as a developer. I think it was worth spending a matter of minutes to weed out these people.
Nethack is art. It showed me that given enough time, random events can coincide in such a way that you feel like someone is conspiring against you.
I had the Atari 800 version. It used the keyboard.
Can't speak for the others, but in Nethack your death usually comes within the hour, or if you do really well, within several hours. You groan, check out your high score, and start again. Plus the game is mostly about handling random situations, so a replay of levels 1-n isn't going to feel too repetitive (others may disagree).
Caffeine can help your brain...Caffeine can cause hypertension.
Water can quench your thirst...Water can drown you.
A hammer can be used to put together a shelf...A hammer can be used to bash in your skull.
WTF, first you said they're good, and then you said they'e bad! Science is a load of BS!!
TG-16 had quite a few great, unique games! They had:
- a slew of side-scrolling shooters, among the best ever made (Blazing Lasers, Super Star Soldier, Raiden, Macross 2036, to name a few)
- a couple of great pinball games (Alien/Devil Crush)
- The Bonk series was great
- Dungeon Explorer which was basically 5-player gauntlet with RPG elements
- That racing/RPG combo game was fun
- Dragon's Curse
- Battle Royale - 5 player wrestling madness
- Legendary Axe I/II
- Military Madness (like Advance Wars but older) I'm sure I could think of more...
I used to use my Sega Genesis controllers/sticks on C64. :)
Race and level of income are a couple of the basic variables you control for...At least if my knowledge learned from that "research methods in sociology" (as a comp sci major) class actually means anything. :)
"Does it immediately evict the old versions to the "undo" space during a transaction and direct other clients to it?"
The data is updated in place, but a the old row is copied to the undo tablespace. There can be quite a lot of I/O against the undo tablespace. It should be on a fast RAID, or perhaps a separate disk. According to that Tom expert I mentioned, a typical configuration is to put it on a RAID 0+1 ("rollback" is kind of the old name):
o raid 0+1 for rollback. It get written to lots. It is important to have protected. We cannot multiplex them so let the OS do it. Use this for datafiles you believe will be HEAVILY written. Bear in mind, we buffer writes to datafiles, they happen in the background so the poor write performance of raid 5 is usually OK except for the heavily written files (such as rollback).
source
It is true that something like vacuuming needs to be done under the hood - really it's just that the undo data needs to be purged so the undo tablespace does not grow indefinitely. I don't believe old undo data gets much "in the way" because it is not scanned like a table. (I'd have to bring out the docs to give you more detail.) You can set an UNDO_RETENTION parameter which is the number of seconds to retain the undo info for each transaction. You may want to keep this data around for a long time, even after your transaction is finished, to allow for flashback querying (basically "select * from mytable as of 2 days ago" or "flashback table mytable to last week").
What's most important IMO is that updates don't create clutter in the table itself. In Oracle, if you update 1000 rows, all other users are directed to undo if they query the same 1000 rows - for the length of your transaction only. Keep in mind that the undo data will likely be found in memory, in the buffer cache. It needs to be on disk too, though, in case of an instance failure - when you start up the database instance it will rollback all in-progress transactions.
In Postgres, if you update those 1000 rows all other users are directed to the dead tuples - again these blocks are likely in the buffer cache. I don't believe there is any performance difference here. BUT, when your transaction finishes and the dead tuples are still in the way, that's when the Postgres way becomes a problem. Now imagine 1000 rows are updated by a different user every few minutes. It piles up. A regular VACUUM will reclaim the space, but your table may still be fragmented. There is another command, VACUUM FULL, which will compact the table to a minimum number of blocks, however this is a much slower operation and requires an exclusive lock on the table, i.e. you don't want to VACUUM FULL during active hours.
"The Sony story is really quite interesting -- I had no idea that there were major MMORPG's running on postgres! (though a highly modified version no doubt):"
Agreed - we're talking Everquest II and Star Wars Galaxies! I've been meaning to check out EnterpriseDB but haven't had the time...
I've used Oracle for about 3 years and Postgres for about 1. Both are good databases. I may write what you're asking for eventually, but don't hold your breath. :) Here are a few thoughts off the top of my head that might help.
In a way-oversimplified nutshell, Postgres seems sorta-kinda modelled after Oracle. But many times I look into a feature that I've used on Oracle and find it doesn't exist in Postgres or it's not up to my expectations. The Postgres feature might be a little half-assed. One example is the multi-version concurrency control. If you update a row in Oracle, the undo tablespace contains a snapshot of the old version. All other concurrent users are directed to the undo tablespace until the transaction completes. They get the old version of the uncommitted row from the undo tablespace. Postgres on the other hand makes a new row in the table for your update, and the old one is marked as a "dead tuple" whose data can be retrieved by other transactions.
Might not seem like a major difference, but you'll have to "vacuum" your Postgres database periodically to clean up your dead tuples. Otherwise, table scans have to scan over all the dead tuples in addition to the "real" data. Some DBAs simply run a vacuum job every night, or use the auto-vacuum daemon. It's not always so simple however. Imagine you have to update data every morning and get it done ASAP. Well, now that you've updated your 500,000 rows, you have to vacuum the table to keep queries running at a decent speed. When I was still a Postgres newbie, I would just vacuum whenever I remembered. One time I forgot about it for a few days, when I finally ran the vacuum it took 17 hours to complete - granted it was a one disk server. It's just another thing to worry about.
Once I looked for a replication solution for Postgres. Some were incomplete. Slony-I - the most popular Postgres replication solution - seemed like the way to go. But upon delving into it, I found it imposed limitations because it sort of "corrupts" the Postgres data dictionary. I believe this corruption broke triggers on all replicated tables (don't quote me on that). Also Slony-I does not support multi-master replication at all.
Sometimes a feature is just great. Rarely is the Postgres feature better, except in terms of user-friendliness. For instance the psql command line tool blows sqlplus out of the water IMO. (Wow, paginated results, tab completion!)
Oracle has a wealth of OLAP/business intelligence features that are lacking in Postgres. There is a flavor of Postgres called Bizgres that is a bit better in this area, though still lacking in comparison. Bizgres is more cutting edge and doesn't seem to have nearly as strong a community as Postgres. Go to http://www.bizgres.com/bb/ and you'll see there are very few posts.
Oracle has an expert named Tom - asktom.oracle.com - who is a genius and answers all my questions. Postgres has an expert, also named Tom, who is a genius and answers all my questions on the newsgroup.
When would I use one over the other? Personally I would use Oracle if there were no budgetary constraints, but if Postgres definitely met all my requirements, I'd go with that. (Yes yes, I am Captain Obvious.) If you need Oracle's enterprise-level features then Postgres is out of the question. There is however EnterpriseDB, a commercial, Postgres-based enterprise-level database. Several months ago Sony "snubbed" Oracle and went with EnterpriseDB for its MMORPGs. I have not looked into EnterpriseDB myself so I can't comment further.
Well I'm rambling and not getting work done. Hope that helps just a little bit.
Oh yeah? Well [contrives test query using insufficient hardware for Oracle, ignores transactions/logging/concurrency controls/scalability/advanced query options/etc.] my tests indicate that MySQL is 1057 times faster than Oracle! QED
Yeah, the Oracle Database totally destroyed eBay, Amazon, The Sims Online, World of Warcraft...
I was referring to materialized view query rewrite, where if a MV can answer your query and the MV is fresh enough for your stale tolerance level, the MV will automatically be used instead...
Good point about the rules system though.
I switched from Oracle to PostgreSQL. I miss summary management (materialized views, dimensions, query rewrite), various ETL features, streams, data guard, updatable views, multi-table inserts, log miner, flashback, database links, packages, automatic workload repository, OEM, and the several months of my life I spent working around PostgreSQL's lack of anything comparable to these features. (I'm not just listing random features - I've wished I've had all of the above at some point...) PostgreSQL is nice for what it is though - a solid, scalable open source database. And psql is much nicer than sqlplus (tab completion - woo!). And I don't think I've ever gotten the Postgres equivalent of an ORA-600...
Wow, General Chaos, now that was a fun one that I completely forgot about...
You could have four players on Commodore. During auctions and land claim, the two keyboard players used keys on the left and right side of the keyboard. Wasn't a big deal because during auctions you only need up/down controls (2 keys) and during land claim, a single button was needed. During the main turn, you grabbed any joystick.
i c.php?t=85
The Atari version was almost a beta version. The debugged and refined game became the Commodore version.
There was a particularly nasty exploit (some disagree about its nastiness) on Atari that allowed two players to insanely inflate the colony score. See this thread - http://atarimule.neotechgaming.com/forums/viewtop
When you got a Planetquake event on Atari, in addition to halving mining production, there was a "feature" where a mountain would occasionally move and a MULE would disappear. This was removed for Commodore.
Also turn times were refined for Commodore.
I would say MULE as well, but I got tired of single player games a few years ago. If only I could round up some players...
Lately it's been Realmspeak, which is a software version of the classic Avalon Hill fantasy board game Magic Realm. I've been meaning to bring out the board game for my friends for a while now, but the game is so complex I haven't had the time/patience to re-learn it. Now Realmspeak is practically doing the teaching for me. Soon I can teach my buddies! Amazing game.
I return to Nethack (Slash 'EM variant) from time to time. Still haven't beaten it without cheating.
I enjoy console emulators from time to time too.
It is my opinion that database independence is a myth, and not necessarily something to strive for, regardless of how great your ORM is. Copying a post I wrote elsewhere (slightly revised):
Over the past decade or so I've worked with several RDBMSs: Oracle, Postgres, MS SQL, DB2, Sybase, Access (if that counts) and a little MySQL (wasn't a fan). If there's one thing I've learned is that each database has a fundamentally different architecture, and database independence is NOT easy to achieve. I'm not even sure if it's desirable.
Switching databases has always been a big, big deal in my experience. This coming from a guy who started on the completely opposite end of the spectrum. I did everything generically - this is just the perspective I was taught in college and literature (black boxing and all that). The first way I ever used a database was by querying MS-SQL doing "select * from mytable" and iterating through the results. I realized that was stupid and learned this whole SQL thing. I learned about ANSI SQL and how I should try to conform to this standard to achieve independence. Then I realized I was using the lowest common denominator and achieving poor results. And coding became much more difficult - had to check against the ANSI standard before using a particular feature: "Darn, x isn't 'ANSI'? Well, I'll do it the hard way..."
If you just replace one database with another, plug-in style, you're going to notice differences (perhaps "bugs"), even with the latest and greatest ORM. With the exception of trivial applications, these differences will affect your application, possibly drastically. For example, you have two users running a transaction on the same row(s) of data. Due to fundamental differences in concurrency mechanisms, Sybase might deadlock (and so one user is rolled back and gets an error) while Oracle runs smoothly. Or MS SQL will give you one answer while Postgres literally gives you a different answer to the same query! And yes, I'm talking about setting the same isolation level in your ORM...
If you use DB2, you're going to have to use repeatable read isolation to get a consistent result set. Not the case with Oracle.
Database A may give you non-blocking reads; Database B does not. Therefore your app plugged into database A may run just dandy. You switch to B and your users complain of slowness. Maybe you then conclude that Database B is bad, but really the problem is that you perhaps unwittingly designed for Database A, thinking that you were database independent all along.
Many developers want to treat the database as a black box - they feel they don't need to know anything about it - they believe they should AVOID knowing anything about it in order to be good object-oriented programmers. The culture supports this notion with terminology such as "data store" and "persistence layer" - just a place to plop down your data and take it out again later, as if it were spreadsheet. In reality, most RDBMSs are very robust with countless features to manage, manipulate, safeguard, and serve your data to many concurrent users.
Why not use the features that make your database special? If you're using a commerical database, you paid a lot of money for these features. Why use the lowest common denominator? Using Oracle's analytic queries I've seen queries run literally orders of magnitude faster than lowest-common denominator queries with Java code on top. I've seen an overnight job transformed into a sub-minute job by using native SQL that lets you do, through a single query (not row-by-row): "If a row having the matching ID exists, update, else insert".
I find it much easier to rewrite the database API (stored procedures) entirely than to deal with the above issues. I've used ORM in the form of Hibernate, in order to solve the database independence problem (wasn't my choice), and I found the cure was worse than the disease - I'd rather translate my 100 PL/SQL functions to PL/PgSQL (maybe a bad example as they're nearly identical - or maybe a good example
Good point. Thousands of servers times $60,000 or more = too ridiculous even for Blizzard. Still I'm sure they've sent Oracle a good seven figures.