Heh, I worked there for awhile back in '96 when they had the Netscape account (back in Navigator 1.1 days, when 2.0 was an early beta.) I can tell you that it was always as bad as you probably had it.;)
I agree with much of what you said, except the part about Lars Ulrich being able to fill out paperwork or speak in plain English. If that's what it would take for Metallica to protect themselves, well, the future looks bright for pirates.;)
Will anyone from San Diego (or thereabouts) be checking this out? I'm considering taking my jeep out to Ocotillo Wells (out past Julian on the 78.) If anyone is interested in a convoy, lemme know. I went out there a couple years ago (Summer 2000) for a shower and it was a good time.
It's desert, but folks with cars have no problems getting there. Luckily the sand is well packed, 4-wheel drive is not necessary (though to go beyond the dunes it is highly recommended.)
I know that to some it sounds silly to consider an escrow service, but IMO it's the safest way to do business with someone online... especially when that person is as anonymous as ebay allows.
Another option is to limit your bids on high priced items to local sellers. I'm a bass player and purchased a $1200 bass guitar amp from a person on ebay. The only reason I went for such a deal was because the seller lives about 15 minutes from me and agreed to make the exchange in person. I would have never gone for such an expensive deal had the seller lived beyond driving range.
The bottom line? Make sure you are 100% protected before you submit your payment. It's a shitty rule in life, but when it comes down to it... buyer beware.
I'm assuming for the same reason 'yeah' is spelled 'yeha'. I didn't catch that one until I realized it wasn't a Dukes of Hazard reference. Now if only they will release that game! Oh well, so long as I can find a Daisy skin for the Futurama game.
So what do you think the chances are that the AC who posted this ingenious formula is actually the brilliant mathemetician that came up with Slashdot math?;)
24 hours * 7 days in a week * 30 days in a month = 1 month?
Riiiight.;)
$0.25/hour would actually total about $180/month for 24/7 access. That's still insanely expensive for dial-up (these days), however small the chances of someone staying connected constantly actually are.
You mean networks back then weren't really stacks of punchcards carried around town by carrier pigeons? I'm gonna kill that lying COBOL programmer downstairs.
I'm not sure you should apply for that position. I get the feeling from your post that you are the type of coder that often has rounding issues and tends to get stuck in infinite loops.:)
Actually, I did. The summer after leaving Gamespy (Summer '00) I designed and implemented a server browsing platform that used URLs rather than command lines to launch a game and connect to a remote host. Addtionally, for Windows users, it integrated completely within the Windows Shell, allowing servers to be browsed like files, games and game types browsed like folders, anywhere, anytime, in any explorer window. It also persists its UI and in-memory server lists to disk when you launch a game (releasing some of the memory that is much better spent on the game itself, not the server browsing software you don't care about at that moment.) I had originally wanted to do something similar for Arcade, but none of the coders (and I use the term loosely) at Gamespy seemed interested. Too bad, I thought it was a rather cool idea.
It's actually a pretty slick system, though I didn't spend enough time on it then to iron out some of the wrinkles (I think a total of 80-90 hours was spent on it over the course of 6 weeks.) I would have spent more time on it, but a non-compete agreement I had signed (lasting 2 years from my resignation date) prohibited me from releasing the source (as I'm an open-source kinda guy) or releasing a freeware product (as I don't need gamers' hard-earned cash.. they need it to buy more games and video cards!) Now that the non-compete has expired (as of this past March 8), I might think about starting up a new project based on the old idea.
If anyone would be interested in such a project, please email me (kaaos at clanmcp dot com). The project would be for no money, sorry to say, as I don't see the need for charging for a product that anyone could implement with enough time and desire (sorry Gamespy).
I was one of the original Gamespy employees from a few years ago, and I never thought I'd see Gamespy as the subject of a/. story. It just goes to show, before long everything ends up on this site.;)
It doesn't surprise me in the least that this has occured, though I hate to bash on my old company (especially since when I left, I left with enough stock to really want the company to succeed, or liquidate and get it over with, hehe.) Truth be told, the company has always been run by a man who truly couldn't care less about customers, a development manager who can't understand why you don't call virtuals from a constructor, and a project lead who thinks UI coding is the end-all-be-all of computer science. Put them together and you end up with very little experience trying to manage a product that has long since outlived its usefulness.
And before you flame me or whatever, I do know a little bit about which I speak... having written much of the original Arcade myself (though I'm not too proud of the outcome, having followed its progress since I left in '00.)
All in all, you can continue to expect inferior product from an inferior company, shameful as it is. I often lament on how things might have changed were L-Fire and I given a little more freedom to get stuff done. C'est la vie.
Of course, given that 90% of the vinyl you so cherish is pressed with music that was recorded digitally to begin with, the whole argument becomes a bit moot, doesn't it.;-)
Perhaps it could be carried by two European swallows who've tied it on a line... or it could be carried by a African swallow.
-- [McP]KAAOS
Re:Already approaching from the wrong direction
on
64kbps @ 40,000 ft.
·
· Score: 1
I doubt that. Cell phones are perfectly fine to use on a plane between take off and landing as far as I know. Of course, at 30K feet the reception leaves much to be desired.;)
When you look ahead to a large scale rewrite, there are few things you must keep in mind before even attempting such a task. If you expect to jump in and hope to tread water, think again. Unless you sit down before you start dividing the coding tasks up amongst the engineers, you are simply begging to go down the same road twice.
Before you begin, make sure you weight the cost of a rewrite against the cost of maintenance. Many engineers (myself included) feel so ashamed for poor code that they want to dive right in and fix it. Whereas this could potentially solve the problem as far as you can see it, it won't make the financial people happy after watching your team spend 4 times the money than they would just dealing with maintenance. In other words, make sure you are adding a hell of a lot of value with such a huge task. This is a good time to analyze the risk of a rewrite as well. How critical is the system? How many users? How will this affect any users that have built systems around your interfaces? Will they need to recode portions of their systems as well? There are many more questions to ask yourself, but these are generally the ones that will come from people outside of your immediate group (and usually right away.)
If you do decide to rewrite, there are a few things you should do before analyzing the current code base. Review the original requirements and compare them with any new requirements you may have now (or later, if you have any insight into the future, such as rumors of change in business practice, etc.) Once you have worked out any inconsistencies or pitfalls, it's time to compare the original design against the original requirements. Look for inconsistencies between the two. Usually you will come across a few requirements that didn't quite make it into the design as expected (if at all.) If the two are so far apart that there is no feasible reconciliation, your hopes of a rewrite are pretty much dashed - it's time to start looking at a fresh start. Hopefully, however, the design met the requirements adequately, with no "creative designing" put in place to get around poorly thought out requirements. Note that you should do all of this before you start going through the code. Leave the code out of it for now.
Once you have established that you can safely move forward (i.e., the design followed the requirements), hold code review sessions with your entire team, targeted at the original code. Ensure that the design was followed properly and that any bug fixes/workarounds/etc are clearly documented and easy to spot. Usually this is not the case, else you wouldn't be contemplating a full rewrite. This is by far the most painful (and time consuming) task, and is usually the point of failure in rewrites. If not enough attention is paid to the caveats of what you have now (and why they are there and not resolved), you will paint yourself into the same corner with the next go 'round.
Without spending too much time on that topic (which is easy to do, believe me, I've done my fair share of code reviews with large teams), I'll assume that you are planning on continuing with the rewrite.
Once you've made it past the reviews, it's time for a new design. You won't necessarily need to completely redesign the system, but you will have to (at the very least) document a plan that will provide a solid path to the new system. Even if your functionality isn't expected to change, it will, so a mild to moderate design document will be your life-jacket. This will be difficult, as it's no easy thing to feel like you're simply writing the same words over again, but stick with it: you will find new methods in this design that will help to avoid the traps you were caught in the first time around. Have the utmost diligence with this step. Review the design often, and brutally. Bring in members from other teams for sanity-checks - a fresh set of eyes can do wonders, even if they are unfamiliar with your product.
Now, onto the coding!
Whatever you do, do NOT use the original code for anything more than a guideline. Create new projects, start with blank sources, whatever it takes to start anew. When you rewrite a system, you are actually writing a new system that simply mimics the funtionality of the old. Your performance is going to change, your stability is going to change. Don't think for a moment that you will end up with exactly what you had before, only prettier. This is a pitfall that fools many an engineer, especially the engineer who trumpeted the idea for the change.;)
Finally, more than just about anything else, remember this: when rewriting a system, be sure to adopt a coding style that will prevent spaghetti code. Be true to a modular design and cleanly separate the functionality into logical groups. This is always easier in an object oriented language, but very achievable in the procedural world as well. Make sure that this time you document your code inline. In other words, instead of simply commenting your code to say, "This function does this, then that", say something like, "This function performs the following business rules, as dictated by requirement #x, conforming to the component design section 5.1." Tedious at best, but far more valuable than most people realize. Make sure you also document the bug fixes that were migrated into the new code base, also. Eventually, someone will want to review the code to make sure the same bugs that were once in the old system aren't going to rear their ugly little heads in the new system. Finally, unit test the living hell out of your code as you write it. This is the last ditch effort (before QA and integration testing) for ensuring stability (which is the main justification in the end for the rewrite.)
Anyway, sorry for posting a novel, I hope something I had to say here can be of some use. Best of luck should you tackle the rewrite!:)
I would much rather be socially included in society, than be a genius outsider.
If you ask me, anyone willing to give up uniqueness and individuality for comfort needs more help than nearly anyone I can think of. I find it shameful that people are willing to dismiss or hide their difference from those around them for fear of acceptance. What a boring place this would be if everyone felt that way! My opinion is that your flaws, whether they be genetic or otherwise, are what set you apart from the blind hordes of modern culture (read: nameless faces.) How else could you expect to really know yourself?
Besides, the expression of genius is not necessarily more fruitful through communication with other people. In fact, most original expression is often misinterpreted or not even understood at all. Think of the countless musicians, thinkers, poets, et al who we only now have begun to study with enough depth to even hope to grasp their point!
Ultimately, it seems to me that for those who one might label genius, a solitary existence will always outweigh that of the mob, where individuality is feared and discouraged.
Just my 2 pesos, not meant to be a flame or an insult.
Slashdot Mirror
Heh, I worked there for awhile back in '96 when they had the Netscape account (back in Navigator 1.1 days, when 2.0 was an early beta.) I can tell you that it was always as bad as you probably had it. ;)
--
mcp\kaaos
I agree with much of what you said, except the part about Lars Ulrich being able to fill out paperwork or speak in plain English. If that's what it would take for Metallica to protect themselves, well, the future looks bright for pirates. ;)
--
[McP]KAAOS
Will anyone from San Diego (or thereabouts) be checking this out? I'm considering taking my jeep out to Ocotillo Wells (out past Julian on the 78.) If anyone is interested in a convoy, lemme know. I went out there a couple years ago (Summer 2000) for a shower and it was a good time.
It's desert, but folks with cars have no problems getting there. Luckily the sand is well packed, 4-wheel drive is not necessary (though to go beyond the dunes it is highly recommended.)
--
[McP]KAAOS
...which is exactly why most porn stars shave. ;)
The world has plenty of geek chicks. We just don't normally see them as they are nearly indistinguishable from the geek males.
;-)
;P
Oh this is not a troll.
--
[McP]KAAOS
I know that to some it sounds silly to consider an escrow service, but IMO it's the safest way to do business with someone online... especially when that person is as anonymous as ebay allows.
Another option is to limit your bids on high priced items to local sellers. I'm a bass player and purchased a $1200 bass guitar amp from a person on ebay. The only reason I went for such a deal was because the seller lives about 15 minutes from me and agreed to make the exchange in person. I would have never gone for such an expensive deal had the seller lived beyond driving range.
The bottom line? Make sure you are 100% protected before you submit your payment. It's a shitty rule in life, but when it comes down to it... buyer beware.
--
[McP]KAAOS
And god knows we all still miss 'My Little Pony' - the icon of both entertainment and education... a beacon in our miserable little lives.
...mmmm okay.
Wait, no.. I'm thinking of 'Care Bears'. Oh, the humanity.
--
[McP]KAAOS
I'm assuming for the same reason 'yeah' is spelled 'yeha'. I didn't catch that one until I realized it wasn't a Dukes of Hazard reference. Now if only they will release that game! Oh well, so long as I can find a Daisy skin for the Futurama game.
--
[McP]KAAOS
...until some poor 16 year old kid's father buys him a Pacer for his first car, while all of his friends are racing around in Acuras and BMWs. ;)
--
[McP]KAAOS
What do you do with a computer with unlimited speed and an infinite amount of memory?
Finally feel secure in your Windows XP reinstall. Again.
--
[McP]KAAOS
So what do you think the chances are that the AC who posted this ingenious formula is actually the brilliant mathemetician that came up with Slashdot math? ;)
;)
24 hours * 7 days in a week * 30 days in a month = 1 month?
Riiiight.
$0.25/hour would actually total about $180/month for 24/7 access. That's still insanely expensive for dial-up (these days), however small the chances of someone staying connected constantly actually are.
--
[McP]KAAOS
You mean networks back then weren't really stacks of punchcards carried around town by carrier pigeons? I'm gonna kill that lying COBOL programmer downstairs.
--
[McP]KAAOS
I'm not sure you should apply for that position. I get the feeling from your post that you are the type of coder that often has rounding issues and tends to get stuck in infinite loops. :)
--
[McP]KAAOS
Well, that would certainly make it difficult for people in China to tell us what it's like, eh chris? :)
--
[McP]KAAOS
Don't you just love random moderation? How this is flamebait I will never understand.
Take the bad joke as it is... a bad joke.
I believe you may have just set the mood for a port of the Diablo Town Kill hack.
--
[McP]KAAOS
Actually, I did. The summer after leaving Gamespy (Summer '00) I designed and implemented a server browsing platform that used URLs rather than command lines to launch a game and connect to a remote host. Addtionally, for Windows users, it integrated completely within the Windows Shell, allowing servers to be browsed like files, games and game types browsed like folders, anywhere, anytime, in any explorer window. It also persists its UI and in-memory server lists to disk when you launch a game (releasing some of the memory that is much better spent on the game itself, not the server browsing software you don't care about at that moment.) I had originally wanted to do something similar for Arcade, but none of the coders (and I use the term loosely) at Gamespy seemed interested. Too bad, I thought it was a rather cool idea.
It's actually a pretty slick system, though I didn't spend enough time on it then to iron out some of the wrinkles (I think a total of 80-90 hours was spent on it over the course of 6 weeks.) I would have spent more time on it, but a non-compete agreement I had signed (lasting 2 years from my resignation date) prohibited me from releasing the source (as I'm an open-source kinda guy) or releasing a freeware product (as I don't need gamers' hard-earned cash.. they need it to buy more games and video cards!) Now that the non-compete has expired (as of this past March 8), I might think about starting up a new project based on the old idea.
If anyone would be interested in such a project, please email me (kaaos at clanmcp dot com). The project would be for no money, sorry to say, as I don't see the need for charging for a product that anyone could implement with enough time and desire (sorry Gamespy).
--
[McP]KAAOS
I was one of the original Gamespy employees from a few years ago, and I never thought I'd see Gamespy as the subject of a /. story. It just goes to show, before long everything ends up on this site. ;)
It doesn't surprise me in the least that this has occured, though I hate to bash on my old company (especially since when I left, I left with enough stock to really want the company to succeed, or liquidate and get it over with, hehe.) Truth be told, the company has always been run by a man who truly couldn't care less about customers, a development manager who can't understand why you don't call virtuals from a constructor, and a project lead who thinks UI coding is the end-all-be-all of computer science. Put them together and you end up with very little experience trying to manage a product that has long since outlived its usefulness.
And before you flame me or whatever, I do know a little bit about which I speak... having written much of the original Arcade myself (though I'm not too proud of the outcome, having followed its progress since I left in '00.)
All in all, you can continue to expect inferior product from an inferior company, shameful as it is. I often lament on how things might have changed were L-Fire and I given a little more freedom to get stuff done. C'est la vie.
/me waits to get flamed by crt and Walla now
--
[McP]KAAOS
Once you've heard true analog music on vinyl.. played through a tube amp... that opinion will change in the time it takes to recognize the tune. ;-)
--
[McP]KAAOS
Of course, given that 90% of the vinyl you so cherish is pressed with music that was recorded digitally to begin with, the whole argument becomes a bit moot, doesn't it. ;-)
--
[McP]KAAOS
Perhaps it could be carried by two European swallows who've tied it on a line... or it could be carried by a African swallow.
--
[McP]KAAOS
I doubt that. Cell phones are perfectly fine to use on a plane between take off and landing as far as I know. Of course, at 30K feet the reception leaves much to be desired. ;)
--------
[McP]KAAOS
No, it'd be the asterisk key. ;)
------
[McP]KAAOS
When you look ahead to a large scale rewrite, there are few things you must keep in mind before even attempting such a task. If you expect to jump in and hope to tread water, think again. Unless you sit down before you start dividing the coding tasks up amongst the engineers, you are simply begging to go down the same road twice.
;)
:)
Before you begin, make sure you weight the cost of a rewrite against the cost of maintenance. Many engineers (myself included) feel so ashamed for poor code that they want to dive right in and fix it. Whereas this could potentially solve the problem as far as you can see it, it won't make the financial people happy after watching your team spend 4 times the money than they would just dealing with maintenance. In other words, make sure you are adding a hell of a lot of value with such a huge task. This is a good time to analyze the risk of a rewrite as well. How critical is the system? How many users? How will this affect any users that have built systems around your interfaces? Will they need to recode portions of their systems as well? There are many more questions to ask yourself, but these are generally the ones that will come from people outside of your immediate group (and usually right away.)
If you do decide to rewrite, there are a few things you should do before analyzing the current code base. Review the original requirements and compare them with any new requirements you may have now (or later, if you have any insight into the future, such as rumors of change in business practice, etc.) Once you have worked out any inconsistencies or pitfalls, it's time to compare the original design against the original requirements. Look for inconsistencies between the two. Usually you will come across a few requirements that didn't quite make it into the design as expected (if at all.) If the two are so far apart that there is no feasible reconciliation, your hopes of a rewrite are pretty much dashed - it's time to start looking at a fresh start. Hopefully, however, the design met the requirements adequately, with no "creative designing" put in place to get around poorly thought out requirements. Note that you should do all of this before you start going through the code. Leave the code out of it for now.
Once you have established that you can safely move forward (i.e., the design followed the requirements), hold code review sessions with your entire team, targeted at the original code. Ensure that the design was followed properly and that any bug fixes/workarounds/etc are clearly documented and easy to spot. Usually this is not the case, else you wouldn't be contemplating a full rewrite. This is by far the most painful (and time consuming) task, and is usually the point of failure in rewrites. If not enough attention is paid to the caveats of what you have now (and why they are there and not resolved), you will paint yourself into the same corner with the next go 'round.
Without spending too much time on that topic (which is easy to do, believe me, I've done my fair share of code reviews with large teams), I'll assume that you are planning on continuing with the rewrite.
Once you've made it past the reviews, it's time for a new design. You won't necessarily need to completely redesign the system, but you will have to (at the very least) document a plan that will provide a solid path to the new system. Even if your functionality isn't expected to change, it will, so a mild to moderate design document will be your life-jacket. This will be difficult, as it's no easy thing to feel like you're simply writing the same words over again, but stick with it: you will find new methods in this design that will help to avoid the traps you were caught in the first time around. Have the utmost diligence with this step. Review the design often, and brutally. Bring in members from other teams for sanity-checks - a fresh set of eyes can do wonders, even if they are unfamiliar with your product.
Now, onto the coding!
Whatever you do, do NOT use the original code for anything more than a guideline. Create new projects, start with blank sources, whatever it takes to start anew. When you rewrite a system, you are actually writing a new system that simply mimics the funtionality of the old. Your performance is going to change, your stability is going to change. Don't think for a moment that you will end up with exactly what you had before, only prettier. This is a pitfall that fools many an engineer, especially the engineer who trumpeted the idea for the change.
Finally, more than just about anything else, remember this: when rewriting a system, be sure to adopt a coding style that will prevent spaghetti code. Be true to a modular design and cleanly separate the functionality into logical groups. This is always easier in an object oriented language, but very achievable in the procedural world as well. Make sure that this time you document your code inline. In other words, instead of simply commenting your code to say, "This function does this, then that", say something like, "This function performs the following business rules, as dictated by requirement #x, conforming to the component design section 5.1." Tedious at best, but far more valuable than most people realize. Make sure you also document the bug fixes that were migrated into the new code base, also. Eventually, someone will want to review the code to make sure the same bugs that were once in the old system aren't going to rear their ugly little heads in the new system. Finally, unit test the living hell out of your code as you write it. This is the last ditch effort (before QA and integration testing) for ensuring stability (which is the main justification in the end for the rewrite.)
Anyway, sorry for posting a novel, I hope something I had to say here can be of some use. Best of luck should you tackle the rewrite!
-------
[McP]KAAOS
I would much rather be socially included in society, than be a genius outsider.
If you ask me, anyone willing to give up uniqueness and individuality for comfort needs more help than nearly anyone I can think of. I find it shameful that people are willing to dismiss or hide their difference from those around them for fear of acceptance. What a boring place this would be if everyone felt that way! My opinion is that your flaws, whether they be genetic or otherwise, are what set you apart from the blind hordes of modern culture (read: nameless faces.) How else could you expect to really know yourself?
Besides, the expression of genius is not necessarily more fruitful through communication with other people. In fact, most original expression is often misinterpreted or not even understood at all. Think of the countless musicians, thinkers, poets, et al who we only now have begun to study with enough depth to even hope to grasp their point!
Ultimately, it seems to me that for those who one might label genius, a solitary existence will always outweigh that of the mob, where individuality is feared and discouraged.
Just my 2 pesos, not meant to be a flame or an insult.
--------
[McP]KAAOS