-
The VOIDRUNNER'S CODEX is LIVE! Explore new worlds, fight oppressive empires, fend off fearsome aliens, and wield deadly psionics with this comprehensive boxed set expansion for 5E and A5E!
Gleemax is Dead
- Thread starter Uzzy
- Start date
Like Luke approaching the Death Star...
Psychotic Jim
First Post
Hmm, well I understand Chainmal miniatures was a wreck before their success with the D&D minis, signifying they learned from the hurdles they ran into with Chainmail. Perhaps it's a chance for the designers to learn from the difficulties they ran into with Gleemax and use that experience to help make sure DDI goes more smoothly.
Samuel Leming
First Post
Are they using SQL Server? I can't tell from just a cancel notice and a http header. Wouldn't surprise me if they are. They'd have to have a reason to not go with a full MS stack.
Anyway, SQL Server has never bitten my ass, so I've no gripes about it. For doing standard corporate CRUD apps that don't require much in the way of performance and do require ACID compliance it is a much better choice then MySQL.
I doubt it's the only cause...
I'm not saying this to insult anybody, but I really do believe that if Wizards had gone with LAMP and the typical programmers and designers that usually work with such they would have had better results.
I don't follow Microsoft in the server world(obviously) so Sharepoint is new to me. Reading a bit about it I can only say WTF were they thinking?
It's not really a Microsoft vs everybody thing.
The more your app deviates from the framework defaults, the more trouble you're going to have with something like Rails. This is almost the same problem I think Gleemax was having. I'm not making an OSS advocacy argument. I'm arguing that they should have used better suited tools.
Sam
PS, I'll look up the Twitter/Rails thing. I could use a good laugh.
[Edit]
Ok, I've read a bit on the Twitter thing. Scaling issues are not what I was expecting. If they had expected that kind of traffic and load, Ruby on Whales was not a good choice for anything past prototyping.
[Edit2]
Though it has nothing to do with the Gleemax crap, the steps that web apps like Twitter, YouTube & Flickr took to scale are fascinating.
Last edited:
Samuel Leming
First Post
As I've said, I'm out of the MS loop. ASP as it was is exactly what I envisioned when I saw that header.
So in a way you actually agree with me.
I'll look into this foul ASP.NET thing, since being ignorant and out of date isn't a virtue outside of politics.
Sam
Samuel Leming
First Post
Good advice. It's not usually worth all the extra baggage and bull you have to put up with.
Sam
Aeolius
Adventurer
"The Head was hardly human, the head is finally dead,
I can live forever in formaldehyde, he said." (Harry the Head - The Residents)
I think WotC should set up shop on Second Life, for their "social networking". They could set up a virtual tavern where gamers could meet, above a virtual dungeon that all could explore. Avatars representing various core races and monsters could be made available for sale, along with props for weapons, equipment, and so on. Members could purchase a virtual plot of land in a nearby village, to keep their belongings. Next door, in a virtual castle, gaming rooms are equipped with tables, chairs, dice, and whiteboards for sharing maps. Second Life is free and cross-platform.
As for the DDI; take klooge.werks and dundjinni, add a bit of Poser and Bryce, and use that instead.
wayne62682
First Post
Aeolius, that's a great idea.
<tangent>
The problem with Gleemax was that it was working alongside PHP based forums, with their own data, and trying to act as a broker between the two. That's why there was so many problems with it. The forums have always been buggy and prone to crashing. As I recall the official word was it had to do with the size of the MySQL database it used, and they couldn't implement clustering for some reason. I'm not even sure what Gleemax used as a database; SQL Server makes sense, but since Gleemax brokered the login to the forums, and the forums use MySQL, maybe it was using MySQL as well?
In any event, I don't think it was an issue of technology chosen, but more a lack of planning prior to hand specs (of course, I doubt there were any specs) to developers, and a lack of budget to properly do things. If you want a MySpace clone and have as big (technically speaking) a fanbase as Magic+D&D+Other games who you can reasonably guess would want to use it (after all, people didn't want to use it largely, I think, because it never worked), you need a decent budget to set up a database cluster for it to scale properly. You can't expect SQL Server Express and 2GB of space to work (NOTE: I don't know what they had. This is an extreme example, obviously) for anything beyond a prototype/limited beta.
Oh, and Ruby on Rails is teh awesome, although the community is rather rabid and David H. Hansson (the creator) seems to have a very elitist, snobby attitude. Twitter's problem is that they didn't plan for it to take off, so when it did they were left scrambling to make it scale, instead of putting measures in place just in case it did scale. Rails can scale adequately if you prepare for it. If you throw together a quick mockup and you suddenly start getting millions of users, you're probably in a bad spot.
</tangent>
<tangent>
The problem with Gleemax was that it was working alongside PHP based forums, with their own data, and trying to act as a broker between the two. That's why there was so many problems with it. The forums have always been buggy and prone to crashing. As I recall the official word was it had to do with the size of the MySQL database it used, and they couldn't implement clustering for some reason. I'm not even sure what Gleemax used as a database; SQL Server makes sense, but since Gleemax brokered the login to the forums, and the forums use MySQL, maybe it was using MySQL as well?
In any event, I don't think it was an issue of technology chosen, but more a lack of planning prior to hand specs (of course, I doubt there were any specs) to developers, and a lack of budget to properly do things. If you want a MySpace clone and have as big (technically speaking) a fanbase as Magic+D&D+Other games who you can reasonably guess would want to use it (after all, people didn't want to use it largely, I think, because it never worked), you need a decent budget to set up a database cluster for it to scale properly. You can't expect SQL Server Express and 2GB of space to work (NOTE: I don't know what they had. This is an extreme example, obviously) for anything beyond a prototype/limited beta.
Oh, and Ruby on Rails is teh awesome, although the community is rather rabid and David H. Hansson (the creator) seems to have a very elitist, snobby attitude. Twitter's problem is that they didn't plan for it to take off, so when it did they were left scrambling to make it scale, instead of putting measures in place just in case it did scale. Rails can scale adequately if you prepare for it. If you throw together a quick mockup and you suddenly start getting millions of users, you're probably in a bad spot.
</tangent>
not to completely hijack, but on development.
I have seen the 'triple the estimate' advice given, and I think it's common, popular, and ridiculous. A smart business won't triple the estimate - a smart business will go in eyes open, generate a REAL estimate, and not force it to be compressed just because it doesn't match your ideal target date. A project doesn't take less effort or time just because you need it by XXX.
What also makes it ridiculous is that it can be assumed that some estimates will be CORRECT - or close to it - so now you're not only tripling the bad estimates, but the good ones as well.
On top of that, the inputs will begin to shrink and get goofy, or other games will be played.
"I know they're going to triple it and that will look bad, so I'll tell them it will take two weeks instead of six" - and so you should have done a x9 for that one.
and what about someone who overestimates to be safe?
It just seems like a bad practice, designed to get around a different set of bad practices (using the goal as the estimate, etc.)
I have seen the 'triple the estimate' advice given, and I think it's common, popular, and ridiculous. A smart business won't triple the estimate - a smart business will go in eyes open, generate a REAL estimate, and not force it to be compressed just because it doesn't match your ideal target date. A project doesn't take less effort or time just because you need it by XXX.
What also makes it ridiculous is that it can be assumed that some estimates will be CORRECT - or close to it - so now you're not only tripling the bad estimates, but the good ones as well.
On top of that, the inputs will begin to shrink and get goofy, or other games will be played.
"I know they're going to triple it and that will look bad, so I'll tell them it will take two weeks instead of six" - and so you should have done a x9 for that one.
and what about someone who overestimates to be safe?
It just seems like a bad practice, designed to get around a different set of bad practices (using the goal as the estimate, etc.)
Similar Threads
