I guess it's neat that they're doing this. But if wanted a computer and I only had $12, I'd just find one on Craigslist. There's usually a Pentium type computer on there going for cheap.
True enough, but couldn't those same users adjust their own monitor/video settings to achieve the level of brightness they desire? I'd rather have the colors start out more vivid with the ability for the user to dial it back, than for things to start out too dark and end up looking washed out when brightness settings are raised.
This has to do with Blizzard. Ever since Warcraft 3 they have shifted their graphic design to a more cartoonish or anime style.
I think the cartoonish style is more about a means to an end, rather than an end in and of itself. Blizzard prides itself on producing games that will run well on average hardware, and that means reduced scene complexity, especially in cases where you've got arbitrary amounts of geometry on the screen. Because of this, they're limited to broader artistic strokes to convey meaning.
I look at this a lot like stage theater - actors make exaggerated gestures and wear dramatic makeup on stage because they need to transcend the limitations of the medium. Blizzard uses simple polygons and textures because that's the best way to get a whole bunch of em on the screen at any given time. As long as it doesn't break immersion (and I understand for some people it does, but not for me), then I'm fine with it.
Personally, watching the gameplay video I wasn't thinking "these colors look off" or "this seems too cartoon-like". I was thinking more along the lines of "whoa, wall of zombies" and "that thing just bit that guy in half!"
i for one welcome our eurasian einsteinchan overlords
It would never work out. They'd make well engineered high performance cars, and yet suffer from a complete lack of ability to drive them, thus dooming the race to extinction via traffic accidents.
I'm not sure what you mean by tracking the merge points yourself - the act of branching in SVN automatically bumps the version number for the entire repository, both trunk and branch. That version is then automatically assumed to be your base point for your diff and subsequent merge. It's messier in CVS, but unless I'm misunderstanding what you mean by merge point I don't see how SVN is different from what you've described.
I agree with you on the distributed source control bit - that sounds like a nice advantage over more traditional repositories.
I've never used Mercurial before, so I don't know if the comparison fits exactly, but the branch/merge style of development you've described can be done very easily within CVS and SVN. That sort of thing is much cleaner in SVN as you're branching from a base repository revision rather than from a tag that can be moved/reapplied, but it's possible if you're careful in CVS as well. From there, it comes down to personal preference with regard to whatever merge tool you care to use.
I greatly prefer that style of development myself, as it tends to keep the trunk much cleaner, and allows a code reviewer to concentrate on specific changes in a given branch rather than worrying about the stability of the codebase as a whole. Of course, old branches can be a bitch to merge if you've got really active development, but there's probably no way around that no matter what tools you're using.
Seems like that would be an odd choice for the PS3, as it would put a dent in Sony's physical media sales. It could still happen - Sony's various divisions don't seem to work in concert very often - but I'm not holding my breath.
That's a(nother) good reason to push from your transactional database into a data warehouse for this sort of thing. Not only do you relieve your main database of the reporting load, but you can put the data into structures better suited for reports. Underlying transactional schema changes wouldn't be visible to the customer, and could be introduced into the data warehouse in a controlled manner that doesn't break existing queries.
Reporting tools like Birt already do this at a level removed from the database via abstracted metamodels. No reason not to take care of it in the schema as well.
My guess is that if you were hit by this stuff, you'd be dead almost before the nerves could send the signal to your brain telling you, "hey bub, I think you're about to die, so here's some pain for the road."
Yeah, it's the "almost" part that's the problem:-)
Very true. Clearly, the same solution applies here - simply tether the space elevator to skyhooks and quickly change the subject if anyone asks what the other end is connected to.
What the heck does Hurricane Katrina have to do with anything? Sounds like just another politician pandering for votes.
Well, the answer was in reference to the current lack of oversight with regard to political appointees. Given the FEMA response to Katrina, I'd say it was an appropriate comment.
That would imply a correlation between standards compliance and browser adoption. Someone should probably tell MS:-)
Seriously, though, Acid3 compliance is mostly an academic exercise at this point. It's a great goal to shoot for, but making wholesale changes to their core rendering engine for the sake of bragging rights isn't really a good use of their time.
I mostly agree with that, but there would have to be some sort of logical limit. Like, say, the loser must pay the legal fees of the winner up to but not exceeding the amount paid for the loser's representation. Otherwise, any large company in danger of being sued by an individual could just make it clear that they plan on spending millions of dollars in legal fees should anyone bring suit against them.
There are still probably dozens of loopholes in the above, but I'm in favor of anything that shifts the balance more towards the little guy.
It's interesting to note that iPhone doesn't allow interpreted code... while Android doesn't allow native code. Which one of these is more "open"?
From what I've seen so far, the limitations in Android are mostly technical, whereas the limitations in the iPhone SDK are mostly business. From that perspective I'd say that Android probably has a higher ceiling.
Slashdot Mirror
Using parameterized queries with bind variables is even easier, and doesn't split your logic between the app and database tiers.
Oh, well, that's ok then.
Wait, what?
I guess it's neat that they're doing this. But if wanted a computer and I only had $12, I'd just find one on Craigslist. There's usually a Pentium type computer on there going for cheap.
Don't you mean $11.99645643246 dollars?
True enough, but couldn't those same users adjust their own monitor/video settings to achieve the level of brightness they desire? I'd rather have the colors start out more vivid with the ability for the user to dial it back, than for things to start out too dark and end up looking washed out when brightness settings are raised.
This has to do with Blizzard. Ever since Warcraft 3 they have shifted their graphic design to a more cartoonish or anime style.
I think the cartoonish style is more about a means to an end, rather than an end in and of itself. Blizzard prides itself on producing games that will run well on average hardware, and that means reduced scene complexity, especially in cases where you've got arbitrary amounts of geometry on the screen. Because of this, they're limited to broader artistic strokes to convey meaning.
I look at this a lot like stage theater - actors make exaggerated gestures and wear dramatic makeup on stage because they need to transcend the limitations of the medium. Blizzard uses simple polygons and textures because that's the best way to get a whole bunch of em on the screen at any given time. As long as it doesn't break immersion (and I understand for some people it does, but not for me), then I'm fine with it.
Personally, watching the gameplay video I wasn't thinking "these colors look off" or "this seems too cartoon-like". I was thinking more along the lines of "whoa, wall of zombies" and "that thing just bit that guy in half!"
I wonder where the gun owners were when that kilo of coke was made illegal.
For some reason I have a mental image of boiling frogs here.
i for one welcome our eurasian einsteinchan overlords
It would never work out. They'd make well engineered high performance cars, and yet suffer from a complete lack of ability to drive them, thus dooming the race to extinction via traffic accidents.
Tangentially, I wonder what will happen first: we'll be contacted by our alien overlords, or Slashdot will start correctly supporting unicode.
The world may never know.
I'm not sure what you mean by tracking the merge points yourself - the act of branching in SVN automatically bumps the version number for the entire repository, both trunk and branch. That version is then automatically assumed to be your base point for your diff and subsequent merge. It's messier in CVS, but unless I'm misunderstanding what you mean by merge point I don't see how SVN is different from what you've described.
I agree with you on the distributed source control bit - that sounds like a nice advantage over more traditional repositories.
I've never used Mercurial before, so I don't know if the comparison fits exactly, but the branch/merge style of development you've described can be done very easily within CVS and SVN. That sort of thing is much cleaner in SVN as you're branching from a base repository revision rather than from a tag that can be moved/reapplied, but it's possible if you're careful in CVS as well. From there, it comes down to personal preference with regard to whatever merge tool you care to use.
I greatly prefer that style of development myself, as it tends to keep the trunk much cleaner, and allows a code reviewer to concentrate on specific changes in a given branch rather than worrying about the stability of the codebase as a whole. Of course, old branches can be a bitch to merge if you've got really active development, but there's probably no way around that no matter what tools you're using.
while (true) {
if (isSECWatching = false) {
commitEgregiousFraud();
}}
Assignment vs. equality check strikes again!
Half? If the original Fable is any indication with regard to planned vs. included features, prepared to be unsatisfied.
Seems like that would be an odd choice for the PS3, as it would put a dent in Sony's physical media sales. It could still happen - Sony's various divisions don't seem to work in concert very often - but I'm not holding my breath.
Redundant Array of Introspective Dilettantes?
Really Athletically Inept Dorks?
Ridiculously Armored Interactive Dissemblances?
That's a(nother) good reason to push from your transactional database into a data warehouse for this sort of thing. Not only do you relieve your main database of the reporting load, but you can put the data into structures better suited for reports. Underlying transactional schema changes wouldn't be visible to the customer, and could be introduced into the data warehouse in a controlled manner that doesn't break existing queries.
Reporting tools like Birt already do this at a level removed from the database via abstracted metamodels. No reason not to take care of it in the schema as well.
My guess is that if you were hit by this stuff, you'd be dead almost before the nerves could send the signal to your brain telling you, "hey bub, I think you're about to die, so here's some pain for the road."
:-)
Yeah, it's the "almost" part that's the problem
Very true. Clearly, the same solution applies here - simply tether the space elevator to skyhooks and quickly change the subject if anyone asks what the other end is connected to.
What the heck does Hurricane Katrina have to do with anything? Sounds like just another politician pandering for votes.
Well, the answer was in reference to the current lack of oversight with regard to political appointees. Given the FEMA response to Katrina, I'd say it was an appropriate comment.
That would imply a correlation between standards compliance and browser adoption. Someone should probably tell MS :-)
Seriously, though, Acid3 compliance is mostly an academic exercise at this point. It's a great goal to shoot for, but making wholesale changes to their core rendering engine for the sake of bragging rights isn't really a good use of their time.
I mostly agree with that, but there would have to be some sort of logical limit. Like, say, the loser must pay the legal fees of the winner up to but not exceeding the amount paid for the loser's representation. Otherwise, any large company in danger of being sued by an individual could just make it clear that they plan on spending millions of dollars in legal fees should anyone bring suit against them.
There are still probably dozens of loopholes in the above, but I'm in favor of anything that shifts the balance more towards the little guy.
But like I said, I'm out now. I'm going into physics and hopefully a job where I can actually be respected for what I know.
You're going to love being a research assistant.
It's interesting to note that iPhone doesn't allow interpreted code... while Android doesn't allow native code. Which one of these is more "open"?
From what I've seen so far, the limitations in Android are mostly technical, whereas the limitations in the iPhone SDK are mostly business. From that perspective I'd say that Android probably has a higher ceiling.