I think many are getting caught up in terminology and forgetting (or perhaps they never knew) that the overall general purpose of any testing is to eliminate assumptions. Do the requirements really reflect what the customer wants? Does the system really meet the specs? Does component X really perform its job? Or are these things just assumed to be true? Testing gives one the ability to find out.
Now the decision of what to test and what to ignore is an important one, and ultimately it comes down to recognizing one's assumptions. What is one willing to assume, and what must they really know for certain?
It's highly distressing to encounter these people, but many, tech and manager alike, actually think there's nothing wrong with working on production systems. To them that's just how it's done. They know no other way. Trying to educate them is met with blank stares and sometimes even harsh resistance.
A simple to-do list and lab notebooks. The trick with the to-do list is for the tasks to be small enough that you can reasonably do them quickly, and thus you never have a partially complete task.
Apple is the only company I know that attempts to restrict where it's software will run.
Ever heard of Sony or Nintendo? Last I checked, PS3 and Wii discs were not readable on a PC -- technological measures and all that. In addition, their respective software licenses specifically forbid any copying whatsoever, a step required if one is going to use the titles on anything other than the intended hardware.
I agree. A similar scenario can be found in World of Warcraft in the initial quests for Death Knights. But that is obviously fantasy so it's ok, right?
I agree. Lag is a general term, applicable to a wide range of things.
I've heard it argued that ignorance of existing, non-computer terminology and the failure to distinguish between the application of a word and its definition are big problems plaguing the computer industry. This particular exchange would seem to support that assertion.
Why? It's the owner's work, not yours. They decide who gets to use it and under what terms. Is there some reason those terms should not contain a time-limit or allow revocation?
I see nothing wrong with the RIAA's stance here... assuming of course one was aware of this at the time of sale. If not, if there was some expectation of perpetual access to the work, then there's a problem.
I think the point many are missing is that software system architecture is not all about the data. It may be a large part of things, but it's by no means the only concern. Walking into a project with the preconception that one requires what a relational system has to offer is rather naive.
Flat files are a perfectly viable option in some circumstances. Not everything requires data uniformity or the ability to run complex ad-hoc queries, nor does everything need information to be controlled by a separate process running on a different machine. Not every system integrates multiple applications through a shared data-store. The NoSQL crowd isn't arguing that SQL is bad, just overused. There are a great many situations where something like flat files or Berkeley DB is more than sufficient, and yet people still use relational technology. In my experience it's generally because that's all they know. In their mind, if one needs to store data one uses SQL. They don't select the right tool for the job because they honestly don't know there are other tools.
I've noticed that many seem to act like mainstream, consumer products are all that exist. When a product or technology enters that market, it's a novel invention. Look at this thing nobody has ever done before. When it leaves, it's the end of everything. Never mind that these things are often used by professionals and others long before consumers even know about them, and they continue to be used long after consumers have purged them from their minds.
That law simply says it's legal to do A in the course of doing B. It says nothing whatsoever about whether or not one is permitted to do B in the first place.
This is a bit of a double-edged sword. A EULA is a license (that's the L part). If you don't agree to it, then you don't have permission to use the software. So while you may not be subject to the terms of the agreement, the owner of the software can come after you for copyright infringement (i.e. using their work without permission).
Do you really need automatic referential integrity, or are you just trying to save the programmers some time?
Do you really need ad-hoc queries, or are you just trying to save the programmers some time?
Do your application programmers really write such buggy code that they cannot be trusted to write their own integrity/query code, or does your QA just suck ass?
Do you really need a client/server solution for data-storage, or is it just what you know and are comfortable with?
Do you really need an RDBMS as an integration tool for several applications, or are there better options?
The judge is not saying the two are the same. I think perhaps you are misunderstanding the situation.
Copyright law says that one may not duplicate someone else's work without their permission. Whenever you load a piece of software you are duplicating it from disk into RAM. This is a completely legal and authorized copy so long as you have a license from the owner. Should you violate that license, however, it becomes null and void. If you continue to use the software after that point, you are making an unauthorized copy.
Always keep in mind why you are being offered shares rather than cash. Your employer doesn't want to be out of pocket. Rather than increasing their risk they want to increase yours. Consider what your goals are and decide accordingly.
I had a similar issue with their systems. In the midst of the holiday rush, the public Best Buy site claimed Nintendo DSs were in-stock at my local store. Not able to find them once I got there, the associates in that department said they had none. The in-store kiosk said otherwise. They still insisted there were none. Asking in another department, the associate there checked the internal inventory system and discovered they had 24-units. The original associates still denied their existence. Customer service personnel just shrugged it off. Strange how nobody ever physically checked the stockroom nor even expressed concern about a few-thousand dollars worth of high-demand merchandise just disappearing.
I've been using a Mac as a development platform for years. Never had an issue. Just because it's an Apple system doesn't mean one has to use AFS or write Cocoa apps.
As I understand it, the copyright issue has nothing to do with modifying anything in RAM.
Anytime you launch a program, the on-disk binary image is generally copied into RAM for execution. Copyright law permits this sort of duplication as it is necessary for use of the product. However, said permission is contingent upon adherence to any applicable license agreement. Use of a tool such a Glider in conjunction with WoW violates Blizzard's license to the player, thus the player is no longer authorized to duplicate the game image as a necessity of its use, thus any such duplication is technically a copyright violation.
The above describes a scenario in which the individual players are in breach of the law. Blizzard did not go after the players, however. They went after MDY with the argument that Glider's only purpose is to facilitate such illegality.
I think many are getting caught up in terminology and forgetting (or perhaps they never knew) that the overall general purpose of any testing is to eliminate assumptions. Do the requirements really reflect what the customer wants? Does the system really meet the specs? Does component X really perform its job? Or are these things just assumed to be true? Testing gives one the ability to find out.
Now the decision of what to test and what to ignore is an important one, and ultimately it comes down to recognizing one's assumptions. What is one willing to assume, and what must they really know for certain?
It's highly distressing to encounter these people, but many, tech and manager alike, actually think there's nothing wrong with working on production systems. To them that's just how it's done. They know no other way. Trying to educate them is met with blank stares and sometimes even harsh resistance.
A simple to-do list and lab notebooks. The trick with the to-do list is for the tasks to be small enough that you can reasonably do them quickly, and thus you never have a partially complete task.
Apple is the only company I know that attempts to restrict where it's software will run.
Ever heard of Sony or Nintendo? Last I checked, PS3 and Wii discs were not readable on a PC -- technological measures and all that. In addition, their respective software licenses specifically forbid any copying whatsoever, a step required if one is going to use the titles on anything other than the intended hardware.
I agree. A similar scenario can be found in World of Warcraft in the initial quests for Death Knights. But that is obviously fantasy so it's ok, right?
Of course he's right that the mass market is in the middle to low end. But what was it not so? Ford outsells Ferrari. This is not news.
This is absolutely spot on. The consistent element in all of the author's examples is volume. He says nothing new.
I agree. Lag is a general term, applicable to a wide range of things.
I've heard it argued that ignorance of existing, non-computer terminology and the failure to distinguish between the application of a word and its definition are big problems plaguing the computer industry. This particular exchange would seem to support that assertion.
Why? It's the owner's work, not yours. They decide who gets to use it and under what terms. Is there some reason those terms should not contain a time-limit or allow revocation?
I see nothing wrong with the RIAA's stance here ... assuming of course one was aware of this at the time of sale. If not, if there was some expectation of perpetual access to the work, then there's a problem.
I think the point many are missing is that software system architecture is not all about the data. It may be a large part of things, but it's by no means the only concern. Walking into a project with the preconception that one requires what a relational system has to offer is rather naive.
Many application developers need these things ...
And many do not.
Flat files are a perfectly viable option in some circumstances. Not everything requires data uniformity or the ability to run complex ad-hoc queries, nor does everything need information to be controlled by a separate process running on a different machine. Not every system integrates multiple applications through a shared data-store. The NoSQL crowd isn't arguing that SQL is bad, just overused. There are a great many situations where something like flat files or Berkeley DB is more than sufficient, and yet people still use relational technology. In my experience it's generally because that's all they know. In their mind, if one needs to store data one uses SQL. They don't select the right tool for the job because they honestly don't know there are other tools.
I've noticed that many seem to act like mainstream, consumer products are all that exist. When a product or technology enters that market, it's a novel invention. Look at this thing nobody has ever done before. When it leaves, it's the end of everything. Never mind that these things are often used by professionals and others long before consumers even know about them, and they continue to be used long after consumers have purged them from their minds.
Tried it from northwestern Washington-state to California. No problems.
The problem is that the newest ideas ... are either gimmicky, terrible in execution, or blatantly ripping off ...
This describes the majority of products marketed by infomercial. It is (once again) not unique to software.
That law simply says it's legal to do A in the course of doing B. It says nothing whatsoever about whether or not one is permitted to do B in the first place.
This is a bit of a double-edged sword. A EULA is a license (that's the L part). If you don't agree to it, then you don't have permission to use the software. So while you may not be subject to the terms of the agreement, the owner of the software can come after you for copyright infringement (i.e. using their work without permission).
Do you really need automatic referential integrity, or are you just trying to save the programmers some time?
Do you really need ad-hoc queries, or are you just trying to save the programmers some time?
Do your application programmers really write such buggy code that they cannot be trusted to write their own integrity/query code, or does your QA just suck ass?
Do you really need a client/server solution for data-storage, or is it just what you know and are comfortable with?
Do you really need an RDBMS as an integration tool for several applications, or are there better options?
The judge is not saying the two are the same. I think perhaps you are misunderstanding the situation.
Copyright law says that one may not duplicate someone else's work without their permission. Whenever you load a piece of software you are duplicating it from disk into RAM. This is a completely legal and authorized copy so long as you have a license from the owner. Should you violate that license, however, it becomes null and void. If you continue to use the software after that point, you are making an unauthorized copy.
Always keep in mind why you are being offered shares rather than cash. Your employer doesn't want to be out of pocket. Rather than increasing their risk they want to increase yours. Consider what your goals are and decide accordingly.
I had a similar issue with their systems. In the midst of the holiday rush, the public Best Buy site claimed Nintendo DSs were in-stock at my local store. Not able to find them once I got there, the associates in that department said they had none. The in-store kiosk said otherwise. They still insisted there were none. Asking in another department, the associate there checked the internal inventory system and discovered they had 24-units. The original associates still denied their existence. Customer service personnel just shrugged it off. Strange how nobody ever physically checked the stockroom nor even expressed concern about a few-thousand dollars worth of high-demand merchandise just disappearing.
I've been using a Mac as a development platform for years. Never had an issue. Just because it's an Apple system doesn't mean one has to use AFS or write Cocoa apps.
Where's this innovation Microsoft is always whining about?
Popular Science != Science
If the above is true .....
As I understand it, the copyright issue has nothing to do with modifying anything in RAM.
Anytime you launch a program, the on-disk binary image is generally copied into RAM for execution. Copyright law permits this sort of duplication as it is necessary for use of the product. However, said permission is contingent upon adherence to any applicable license agreement. Use of a tool such a Glider in conjunction with WoW violates Blizzard's license to the player, thus the player is no longer authorized to duplicate the game image as a necessity of its use, thus any such duplication is technically a copyright violation.
The above describes a scenario in which the individual players are in breach of the law. Blizzard did not go after the players, however. They went after MDY with the argument that Glider's only purpose is to facilitate such illegality.