I have about 6 years worth (10 gigs) of old project files sitting on my hard drive. I use X1 and think its an absolute god send. Just type in a few keywords and X1 pulls up the file. I used to have to pour through a dozen levels of directories and rely on my rusty memory to try to find files.
What if the flash version has the same form factor as the iPod mini? And instead of making a distinction between HD vs Flash, they'd simply call it "iPod Mini in 3 sizes": 4 gig, 1 gig, 0.5 gig? Same concept as it's big brother's 3 different sizes.
I love the iPod mini interface and form factor. I have a hard time seeing how apple could reduce the size and still produce a great UI. Of course, apple has a great track record for proving pundits wrong...
There are holes of course... 1) I have no idea if it's economically feasible to produce the flash based iPod versions at attractive price points... 2) There's also the question of whether or not offering the mini at lower costs would cause brand dilution (is that the right term? marketing 101 was a long time ago) and damage the precious cachet that apple's built up...
When you talk about the price difference between the mini and the 15 gig, note that the mini comes with a usb 2.0 cable. If you don't have a firewire port, factor in an additional $19 to the cost of the 15 gig. So its more like $69 price difference vs $50.
While I like the concept, can you really spy on the game industry?
I'm not a movie producer (is that INAMP?), but there's a lot of opportunity to get advanced insight into movies well before movie's released. Maybe book rights are bought, screenplay's optioned, casting calls, and even on-location shoots with talkative extras.
On the other hand, how do we usually get info on new games? THe game company releases screen shots, movie clips and grants interviews. They don't release info until they want to. Sure beta's are leaked, but won't every other gaming site review that beta too? For all we know, there could be some great Doom3 killer being developed out in Eastern Europe. Oh wait there is... supposedly.
AICGames may be able to survive by applying their unique style to gaming news or reviews, but don't expect the same industry insider news from the movie site.
Which says that 68% of homes have access to broadband. (I assume that means DSL and cable modems). As someone else so eloquently put before, "satellite latency sucks".
So that means that satellite is targeting the remaining 32%... minus those that have trees or mountains obstructing the southwest sky... lets see, rural folks that don't have trees... i smell a money maker
automated testing is a tricky thing. At the onset, sounds great. But in realty, there's a lot of work that goes into it. For some projects, automated testing is the "right thing" but for the majority of projects, it is not.
**Writing and maintaining automated test scripts takes lot time.** Someone else posted a metric of 10-1, which I believe is quite fair. You really need to treat those scripts as its own mini-development project. You need to map out scenarios for each script and what goal each should accomplish. Coding (yes, even for those record/playback tools... you need to spend quite a bit of time tweaking it). And testing. Testing test scripts? Absolutely. If your test scripts are wrong, you could end up masking real bugs and creating false confidence.
Now the questions you need to ask yourself along these lines are: What is the lifexpectancy of my application? How often do release new code to production? The relevance of these two questions are of a cost/benefit ratio. If I'm going to spend x amount of man-weeks (yes, weeks) to create an automated test suite, am I going to get the cost savings back when I know v2.0 is 8 months away? Maybe. What if I only do two releases in those 8 months? Most likely not. (if you're releasing code to a production system on a per fix basis... well that's another slashdot topic)
In lieu of automated testing, I do have a few suggestions for improving testing.
1) incorporate "impact analysis" as part of your design/code reviews. If someone is planning on touching function y in module x, your architect / tech lead / rest of developers should be able to identify what other areas are going to be affected. When it comes time to test, you know exactly what areas you need to really focus on and which areas can do with a spot check.
2) come up with a sensible schedule for bundling multiple code fixes into incremental releases. Every time you touch production, there's an inherent testing overhead. Bundle a multiple fixes together and that overhead is better distributed.
3) hire dedicated testers. Having someone full time on QA (or part time, split across multiple projects) does wonders. The good ones bring both a great deal of experience for finding "common errors" as well as a fresh perspective to the table to see things that the developers overlook because they're too deep in the trenches. Now of course, dedicated testers may not fit into the budget. Even if you can afford them, developers should always be on the hook for testing. Which brings me to my next point...
4) tell your developers that they better learn to test or fire them. sounds harsh, but testings part of the game. I don't want anyone who doesn't understand the value of testing -- and isn't willing to put in the effort to test -- on my team.
Yes, the Rage is an old card, and not up to snuff with today's standards. However, to dismiss all of ATIs offerings is just plain ignorant. Benchmarks of the from many PC gaming sites show the Radeon giving a GeForce 2 a serious run for its money. For the Mac community, going from the Rage/Voodoo3 level of performance to a Radeon (essentially skipping a generation) is absolutely incredible. Oh, and in response to another post about a voodoo5 in the cube... the physical length of a Voodoo5 is 13 inches. 13 > 8.
Slashdot Mirror
I have about 6 years worth (10 gigs) of old project files sitting on my hard drive. I use X1 and think its an absolute god send. Just type in a few keywords and X1 pulls up the file. I used to have to pour through a dozen levels of directories and rely on my rusty memory to try to find files.
What if the flash version has the same form factor as the iPod mini? And instead of making a distinction between HD vs Flash, they'd simply call it "iPod Mini in 3 sizes": 4 gig, 1 gig, 0.5 gig? Same concept as it's big brother's 3 different sizes.
I love the iPod mini interface and form factor. I have a hard time seeing how apple could reduce the size and still produce a great UI. Of course, apple has a great track record for proving pundits wrong...
There are holes of course...
1) I have no idea if it's economically feasible to produce the flash based iPod versions at attractive price points...
2) There's also the question of whether or not offering the mini at lower costs would cause brand dilution (is that the right term? marketing 101 was a long time ago) and damage the precious cachet that apple's built up...
erm, you sure about that? Cause the "firewire adapter" that came with mine was just a 6-pin to 4-pin plug converter, not a PCI card.
When you talk about the price difference between the mini and the 15 gig, note that the mini comes with a usb 2.0 cable. If you don't have a firewire port, factor in an additional $19 to the cost of the 15 gig. So its more like $69 price difference vs $50.
That said, $199 would have been nice...
While I like the concept, can you really spy on the game industry?
I'm not a movie producer (is that INAMP?), but there's a lot of opportunity to get advanced insight into movies well before movie's released. Maybe book rights are bought, screenplay's optioned, casting calls, and even on-location shoots with talkative extras.
On the other hand, how do we usually get info on new games? THe game company releases screen shots, movie clips and grants interviews. They don't release info until they want to. Sure beta's are leaked, but won't every other gaming site review that beta too? For all we know, there could be some great Doom3 killer being developed out in Eastern Europe. Oh wait there is... supposedly.
AICGames may be able to survive by applying their unique style to gaming news or reviews, but don't expect the same industry insider news from the movie site.
Did a quick google search and came up with this article:
, 00 .asp
http://www.pcworld.com/news/article/0,aid,81284
Which says that 68% of homes have access to broadband. (I assume that means DSL and cable modems). As someone else so eloquently put before, "satellite latency sucks".
So that means that satellite is targeting the remaining 32%... minus those that have trees or mountains obstructing the southwest sky... lets see, rural folks that don't have trees... i smell a money maker
automated testing is a tricky thing. At the onset, sounds great. But in realty, there's a lot of work that goes into it. For some projects, automated testing is the "right thing" but for the majority of projects, it is not.
**Writing and maintaining automated test scripts takes lot time.** Someone else posted a metric of 10-1, which I believe is quite fair. You really need to treat those scripts as its own mini-development project. You need to map out scenarios for each script and what goal each should accomplish. Coding (yes, even for those record/playback tools... you need to spend quite a bit of time tweaking it). And testing. Testing test scripts? Absolutely. If your test scripts are wrong, you could end up masking real bugs and creating false confidence.
Now the questions you need to ask yourself along these lines are: What is the lifexpectancy of my application? How often do release new code to production? The relevance of these two questions are of a cost/benefit ratio. If I'm going to spend x amount of man-weeks (yes, weeks) to create an automated test suite, am I going to get the cost savings back when I know v2.0 is 8 months away? Maybe. What if I only do two releases in those 8 months? Most likely not. (if you're releasing code to a production system on a per fix basis... well that's another slashdot topic)
In lieu of automated testing, I do have a few suggestions for improving testing.
1) incorporate "impact analysis" as part of your design/code reviews. If someone is planning on touching function y in module x, your architect / tech lead / rest of developers should be able to identify what other areas are going to be affected. When it comes time to test, you know exactly what areas you need to really focus on and which areas can do with a spot check.
2) come up with a sensible schedule for bundling multiple code fixes into incremental releases. Every time you touch production, there's an inherent testing overhead. Bundle a multiple fixes together and that overhead is better distributed.
3) hire dedicated testers. Having someone full time on QA (or part time, split across multiple projects) does wonders. The good ones bring both a great deal of experience for finding "common errors" as well as a fresh perspective to the table to see things that the developers overlook because they're too deep in the trenches. Now of course, dedicated testers may not fit into the budget. Even if you can afford them, developers should always be on the hook for testing. Which brings me to my next point...
4) tell your developers that they better learn to test or fire them. sounds harsh, but testings part of the game. I don't want anyone who doesn't understand the value of testing -- and isn't willing to put in the effort to test -- on my team.
my 2 cents and then some...
Yes, the Rage is an old card, and not up to snuff with today's standards. However, to dismiss all of ATIs offerings is just plain ignorant. Benchmarks of the from many PC gaming sites show the Radeon giving a GeForce 2 a serious run for its money. For the Mac community, going from the Rage/Voodoo3 level of performance to a Radeon (essentially skipping a generation) is absolutely incredible. Oh, and in response to another post about a voodoo5 in the cube... the physical length of a Voodoo5 is 13 inches. 13 > 8.