Observable results based on a stimulus understood by the player... that is the key to good AI.
1) Make sure the player can understand (or correctly infer) the stimulus 2) Make sure the actor responds in to the stimulus in a way that makes sense to the player = WOW GREAT AI... even if it's a bunch of "if then" statements.
While the goal is easy to describe I can't imagine this is easy to do . . .
It sounds obvious, but you should cover the development process. In many CS classes students work alone, so an OSS model may be strange. How does one go about recieving code, building it, and tracking bugs? Grab some place on SourceForge and have the class run a small OSS project...
The MGM v. Grokster ruling may answer your question. While Grokster is a copyright case, it seems this ruling could be used to create third party liability for the software maker in this case.
"Justice Souter delivered the opinion of the Court.
The question is under what circumstances the distributor of a product capable of both lawful and unlawful use is liable for acts of copyright infringement by third parties using the product. We hold that one who distributes a device with the object of promoting its use to infringe copyright, as shown by clear expression or other affirmative steps taken to foster infringement, is liable for the resulting acts of infringement by third parties."
Object Oriented is a way to abstract code, and it does not impose or preclude a specific technique for saving configuration or state.
In truth, how you define your objects will play a big part and what you are persisting, and thus, how to go about doing it.
I encourage you not to discount your instructor, but rather, consider your object model, game, and decide what actually needs persisted.
(Compare, for example, persisting a Chess Game vs. A Space Invaders Game, vs. a game like Morrowind.)
Like any paradigm, you can find a really horrid way to persist via O.O., or a really elegant ways to deal with this problem too. It's not the paradigm, but the programmer that determines the elegance of the code.
If you are writing Java, Peter Coad in his book Java Design (ISBN 0-13-911181-6) gives a wonderful way of leveraging objects to make clean and elegant object oriented code, (though it does not deal specifically with persistence.)
I agree regarding RTFP. Note though, that the patent is broader than endoding long and latitude. It's patenting the the encoding of *any object location based* on a coordinate system, using the string value of a "Base-N" number.
I'm sure this pantent come back to bite the entire industry as mobile phones (and similar devices) become aware of the geo-positional location of their user and want to share that in a standard way via a URL or similar device.
Your right, investing in more IT is simply investing in capability (in a best case senario.) But that does not create ROI. Intelligence use of information, in part, creates ROI.
Not investing in IT lessens the chance that one will have a chance to leverage information for ROI purposes.
So, say you do lobby? Without IT how do you know what to lobby for? Say you get a tax break, how do you calcuate how much? How do you know if it's really a break, or if the costs are hidden? IT provides the tools to (among other things) analyze the information.
Just thoughts!
Information is why IT Matters
on
Why I.T. Matters
·
· Score: 5, Insightful
I find the discussions around I.T. amusing as I see concern about electronic voting, privacy, file sharing, and IP become the focus of new laws and protests.
I.T. is, at it's heart, technology enabling the collection, storage, retrieval, analysis and control of information.
(This is used to make decisions --- predictive as well as reactionally, as well as manipulate the 'ugly bags of mostly water' who's only connection to this would is via a hand full of easily confused primitive senses, and a questionable ability to accurately remember and/or interpret the data that they provide.)
He who controls the data, could appear to control the world!
I.T. will stop mattering when information stops mattering. As long as information provides power, those in IT have nothing to worry about.
I believe it would be in the community's best interest to establish a foundation solely dedicated to creating, holding and managing OSS patents.
Without such a foundation, it will be hard --- if not impossible --- to protect the IP created by OSS projects. The patents created can be licenses (to commercial companies) for the sole purpose of creating a warchest to defend against patent suits and to fund submissions to the patent process.
Obviously, the current patent system is forcing the community in this direction.
It's imparative that we do not fall behind and lose the ability to create.
While an improperly planned project will, mostly likely end-up behind schedule, there is no guarantee a properly planned project will end up any differently.
First: There is a limit to one's estimation ability. It is described here in a 2001 Slashdot post. here. So unless you've actually done the task before, you may get the estimations wrong... and even if you HAVE done a task before, you may not get the estimations right.
Second: Prefect planning is not possible because change happens. "Market" change, financial change, and thus, time and requirements and features change. Of course, one does not have to adapt, but then again, neither did the trilobite.
Third: People work differently under, and approaching deadlines. A paper on this can be found here Productivity is not flat at all times in the project.
So, let's not make planning more than it's meant to be. It's valuable, but certainly a solution to the problem.
I think that if you want to get rid of crunch time, you have to get rid of market pressures... which in essence mean getting rid of capitalism as we know it.
It's hard to dominate in science and math without a good foundation. I suspect that a general lack of focus and attention on our pulic K-12 school system is what is really hurting the US.
At the heart of the matter is how schools are funded. We can see the issue slowing heating up as some funding programs are being called "unconstitutional." See Kansas and Ohio , and Vermont.
I suppose it all comes down to money in the end. There is a good chance that the next generation of kids will have a better understanding of copyright law than of science.
Your task is not an easy one... don't' expect to write an open source policy on your own, or in one giant document to cover *all* open source. The risks in installing a new OS (Like Linux) are radically different that the risks of letting a handful of developers use Eclipse (an Open Source IDE) and even those are different than using, a small LGPL'd component.
Never-the-less, here is some practical advice: 1) Involve Legal. Educate them, work with them, and understand their concerns. Be their friend!
2) Start asking your various IT managers to place a note about open source in their strategy documents. They do not need to be for it or against it, but they *must* address it. Provide help, as they need it. (Have the Development Managers talk about OpenSource in his particular context, as should the Networking team, and so forth.)
3) Finally, figure out if you have a set way to evaluate software for purchase. If you do, construct procedures to include OSS in your evolutions along side commercial software (This is harder than it sounds.))
There are the beginning steps.
In short, there is no "uber policy" for open source. Treat open source like "just another vendor" as best as you can and you may be pleasantly surprised.
An architect can sometimes be though of as a technical organizer.
It's a role more than a position. An architect steps in when you have a group of developers and you need to get from point A to point B with as little risk as possible (technical and/or otherwise.) You should take into account business goals, technical skillset, marketing requests, and supportability.
One you and your team have layed out the architecure, and aligned it with the various business goals, there is nothing wrong with you taking a *minor* programming task, assuming you have time.
But also realize that architects play by differnt rules than coders. Your skillset in dealing with groups of technical AND non-technical people will be more important that your skillset in a particual language. Your ability to leverage the your companies talented programming staff to produce someting everyone is proud of (and also happens to be on-time and under budget) will be the what you are measured by. Making sure you have an architecure that can adapt you the changing needs of your business... thats a full time job.
You'll really hurt yourself if you try to be a General and an Elite Commando at the same time.... focus on what's inportant for the role you are playing, and let your talented software engineers play their role.
Teach him the OOAD development process. Teach him to analyze specifications, and talk with others to define requirements. Teach him to design an application and break it into pieces so that others (that are not of his intellect) can understand what to do, and contribute to his work. Teach him teamwork, and teach how to work with real people (both techies and non-techies) as he tries to define and create an application.
Tony!!
Slashdot Mirror
... only better.
... that is the key to good AI.
... even if it's a bunch of "if then" statements.
Observable results based on a stimulus understood by the player
1) Make sure the player can understand (or correctly infer) the stimulus
2) Make sure the actor responds in to the stimulus in a way that makes sense to the player
= WOW GREAT AI
While the goal is easy to describe I can't imagine this is easy to do . . .
It sounds obvious, but you should cover the development process. In many CS classes students work alone, so an OSS model may be strange. How does one go about recieving code, building it, and tracking bugs? Grab some place on SourceForge and have the class run a small OSS project ...
Object Oriented is a way to abstract code, and it does not impose or preclude a specific technique for saving configuration or state.
In truth, how you define your objects will play a big part and what you are persisting, and thus, how to go about doing it.
I encourage you not to discount your instructor, but rather, consider your object model, game, and decide what actually needs persisted.
(Compare, for example, persisting a Chess Game vs. A Space Invaders Game, vs. a game like Morrowind.)
Like any paradigm, you can find a really horrid way to persist via O.O., or a really elegant ways to deal with this problem too. It's not the paradigm, but the programmer that determines the elegance of the code.
If you are writing Java, Peter Coad in his book Java Design (ISBN 0-13-911181-6) gives a wonderful way of leveraging objects to make clean and elegant object oriented code, (though it does not deal specifically with persistence.)
Good Luck
I agree regarding RTFP. Note though, that the patent is broader than endoding long and latitude. It's patenting the the encoding of *any object location based* on a coordinate system, using the string value of a "Base-N" number.
I'm sure this pantent come back to bite the entire industry as mobile phones (and similar devices) become aware of the geo-positional location of their user and want to share that in a standard way via a URL or similar device.
I agree.
The Supreme Court has validated the law in question.
So,it's time to stop looking for the Judicial Branch to strike down the law.
Instead it's time to lobby the Legislative Branch to change it!
Your right, investing in more IT is simply investing in capability (in a best case senario.) But that does not create ROI. Intelligence use of information, in part, creates ROI.
Not investing in IT lessens the chance that one will have a chance to leverage information for ROI purposes.
So, say you do lobby? Without IT how do you know what to lobby for? Say you get a tax break, how do you calcuate how much? How do you know if it's really a break, or if the costs are hidden? IT provides the tools to (among other things) analyze the information.
Just thoughts!
I find the discussions around I.T. amusing as I see concern about electronic voting, privacy, file sharing, and IP become the focus of new laws and protests.
I.T. is, at it's heart, technology enabling the collection, storage, retrieval, analysis and control of information.
(This is used to make decisions --- predictive as well as reactionally, as well as manipulate the 'ugly bags of mostly water' who's only connection to this would is via a hand full of easily confused primitive senses, and a questionable ability to accurately remember and/or interpret the data that they provide.)
He who controls the data, could appear to control the world!
I.T. will stop mattering when information stops mattering. As long as information provides power, those in IT have nothing to worry about.
That's pretty funny.
Your sourse link is 404 though. You should consider reposting it.
I believe it would be in the community's best interest to establish a foundation solely dedicated to creating, holding and managing OSS patents.
Without such a foundation, it will be hard --- if not impossible --- to protect the IP created by OSS projects. The patents created can be licenses (to commercial companies) for the sole purpose of creating a warchest to defend against patent suits and to fund submissions to the patent process.
Obviously, the current patent system is forcing the community in this direction.
It's imparative that we do not fall behind and lose the ability to create.
While an improperly planned project will, mostly likely end-up behind schedule, there is no guarantee a properly planned project will end up any differently.
... and even if you HAVE done a task before, you may not get the estimations right.
... which in essence mean getting rid of capitalism as we know it.
First: There is a limit to one's estimation ability. It is described here in a 2001 Slashdot post. here. So unless you've actually done the task before, you may get the estimations wrong
Second: Prefect planning is not possible because change happens. "Market" change, financial change, and thus, time and requirements and features change. Of course, one does not have to adapt, but then again, neither did the trilobite.
Third: People work differently under, and approaching deadlines. A paper on this can be found here Productivity is not flat at all times in the project.
So, let's not make planning more than it's meant to be. It's valuable, but certainly a solution to the problem.
I think that if you want to get rid of crunch time, you have to get rid of market pressures
While this focuses on Games, it's a common occurrence in nearly all deadline driven development activities.
(The production of many term papers seems to parallel this "crunch mode" as well.)
It's hard to dominate in science and math without a good foundation. I suspect that a general lack of focus and attention on our pulic K-12 school system is what is really hurting the US.
At the heart of the matter is how schools are funded. We can see the issue slowing heating up as some funding programs are being called "unconstitutional." See Kansas and Ohio , and Vermont.
I suppose it all comes down to money in the end. There is a good chance that the next generation of kids will have a better understanding of copyright law than of science.
Your task is not an easy one ... don't' expect to write an open source policy on your own, or in one giant document to cover *all* open source. The risks in installing a new OS (Like Linux) are radically different that the risks of letting a handful of developers use Eclipse (an Open Source IDE) and even those are different than using, a small LGPL'd component.
Never-the-less, here is some practical advice: 1) Involve Legal. Educate them, work with them, and understand their concerns. Be their friend!
2) Start asking your various IT managers to place a note about open source in their strategy documents. They do not need to be for it or against it, but they *must* address it. Provide help, as they need it. (Have the Development Managers talk about OpenSource in his particular context, as should the Networking team, and so forth.)
3) Finally, figure out if you have a set way to evaluate software for purchase. If you do, construct procedures to include OSS in your evolutions along side commercial software (This is harder than it sounds.))
There are the beginning steps.
In short, there is no "uber policy" for open source. Treat open source like "just another vendor" as best as you can and you may be pleasantly surprised.
... or all three!
This paper seems to indirectly support Agile Development, and the methodologies that fall under it (XP for instance.)
http://www.agilealliance.org
My 2 cents ...
... thats a full time job.
.... focus on what's inportant for the role you are playing, and let your talented software engineers play their role.
An architect can sometimes be though of as a technical organizer.
It's a role more than a position. An architect steps in when you have a group of developers and you need to get from point A to point B with as little risk as possible (technical and/or otherwise.) You should take into account business goals, technical skillset, marketing requests, and supportability.
One you and your team have layed out the architecure, and aligned it with the various business goals, there is nothing wrong with you taking a *minor* programming task, assuming you have time.
But also realize that architects play by differnt rules than coders. Your skillset in dealing with groups of technical AND non-technical people will be more important that your skillset in a particual language. Your ability to leverage the your companies talented programming staff to produce someting everyone is proud of (and also happens to be on-time and under budget) will be the what you are measured by. Making sure you have an architecure that can adapt you the changing needs of your business
You'll really hurt yourself if you try to be a General and an Elite Commando at the same time
Teach him the OOAD development process. Teach him to analyze specifications, and talk with others to define requirements. Teach him to design an application and break it into pieces so that others (that are not of his intellect) can understand what to do, and contribute to his work. Teach him teamwork, and teach how to work with real people (both techies and non-techies) as he tries to define and create an application. Tony!!