Get your students interested, have them use Google Docs using XHTML with xml encoded embedded java code which they marshal and unmarshal using standard java library xml support into and out of whatever editor/development environment that each one wishes to use.
Traditional literacy is not a requirement for effective use of electronic communication, and as a bonus quickly learning an informal communication system (supplemented by verbal/visual content) is the best rapid learning curve in existence ( think of the scores of Pidgin languages that have and still do crop up for bartering over the centuries).
On a wireless net using new low powered devices with solar and other locally available energy sources, this network can reach anyone anywhere.
If this works out even filthy rich folks can use it for casual means and to keep in touch with everyone else while still having their exorbitant gadgets, etc.
I think one of the problems with attempts to provide a laptop for all is not marketing them to everyone (the original buy two keep one and have one shipped to someone who can't buy one was the best model for shared communication and common ground, but it was dropped for simplistic pointless philosophical reasons and I suspect for serious market pressure from vested interests, someone correct me if I'm wrong, I wanted one and liked the idea of someone else getting one who needed it!)
Real Human progress depends on those with more than sufficient marginal means setting aside about 20 percent of the Global marginal resources to build a minimal level of Human infrastructure that provide dignity and opportunity.
The best way to insure that you don't starve is to build a society where no one is allowed to starve even if you occasionally have to eat hamburger.
I applaud Google and I hope they eventually make money fairly for this foresight and imagination.
If you are forced to use adds for revenue then the only real trick is to require that you keep ownership and legal control over the provided add space.
Any legal deal that requires you to give up control and ownership of the leased space except for your standard allowed content agreement should be rejected. Otherwise you've actually given up control fo Wikipedia and it will not be long before your new owners will be dictating their terms to the Wikipedia community.
Also don't fully depend on your add revenue or your survival will be in their hands regardless of your legal contract.
You might lose the big boys in the add business with that policy but do you really want to do business with them?
Those who understand Wikipedia will place their adds there, the others are unwelcome predators that the community doesn't need!
If you are teaching an IDE then use an IDE and treat the language as an afterthought.
If you are teaching a programming language then teach them the language and then introduce an IDE as a productivity tool if you so desire.
Note: IDEs come and go in and out of vogue and if they are vendor specific as may be true in programming shops where the students will work that particular ventor's package, and of cource IDE, may be gone in 6 months. That is not an assumption on my part but an observed fact of life.
IDE's do not reflect the raw behavior of the language and more to the point often can and do make underlying assumptions or operational decisions. Being second guessed by a programmer 2 years ago who thougt that feature of the IDE was cool can be an annoying experience at the best and a fatal one at the worst.
It is difficult enough to get a clean behavior of a particular language relative to its specification in a bare bones environment much less as an embedded component in a complex IDE.
IDE debuggers don't always reflect the true behavior of the program under general hardware/OS conditions. There are also debugging issues, especially in production environments where the IDE cannot be used in many cases.
One of the side effects is often the failure of putting in reasonable program logging and debugging statements because the IDE debugger makes them unnecessary. That can leave you holding the bag at 2:00 am. trying to solve a critical production problem without any usable information.
IDE's can become crutches in that a basic understanding of the programming process is assumed to be the process behavior of the IDE, especially by a novice. Sometimes IDE environments can be buggy (after all they are just an added layer of programming complexity from an operational standpoint).
You don't have to create expert System Programmers with all the nuances of hardware/assembler/compilier specifices, just give them a basic development environment that can edit/compile/build the basic language for the available hardware/os. After you've gotten them working with the basic language give them the option of using an IDE but have some work that is independent of the IDE always included in the exercises for the rest of the course. If you don't want to be pedantic then after the initial introduction make the non IDE related exercises extra credit.
There is nothing wrong with an IDE as a tool, but that is all that it is a tool to managing the programming environment. What counts is what actually ends up running on the hardware and the student's basic understanding of it.
Consider that a student properly exposed in this manner can then move from one IDE to another and even work when necessary without one.
Basic programming practices (Structured logic, Object Related Design), and a real understanding of the basic language behavior relative to the state machine coupled with some workable knowledge of the standard associated libraries goes a long way to building a competent programmer.
X-treme programming is all the rage now, lucky you you just graduated early:)
Pedantry and conventional wisdom, plenty there are in your replies:)
Think out of the box, but wear a raincoat.
Asymmetric programming as in asymmetric warfare.
NUMA
If someone likes doing something then let them do it as it is more efficient then wasting time and energy making someone do what they don't like:)
Walk backwards until you get where you both are now.
Generate the expected output then figure how to get the computer there, both of you team up on the one Professor that won't grade on the curve the third member of your team the computer.
Time is your friend if you don't let someone else make it your enemy. Thinking about a deadline obviously wastes time better used on just about anything else.
Teaching is the best form of learning.
Of the 4 dimensions light prefers the geodesic in time. Your working surface might just as well be hyperbolic or not. Hint: Static structures with the shortest timelines for logic flow:) One can build the road and the other drive the car and swap every now and then.
You can work with anybody if they can work with you.
5 minutes of communication, 20 minutes of work, 2 hours of sleep.
Unless life and death internal conflict is the issue at stake your personal state's of mind during the journey will mean little at the victory celebration even if you never speak to each other again.
Even if you did all the work yourself you would be no worse off than if you were on the project by yourself except that you wouldn't get the 20% credit expected for learning teamwork in the latter case.
In life you will either work with your equal, or someone superior or someone inferior. Working with your equal is usually the most difficult especially if you get along and make the same mistakes;)
Different folks are equal at different times.
Objects, Structured Programming, minimal proofing (Logic envelopes approaching a convex hull, but don't waste time on the optimal fit as soon as you find a sufficient fit). One way in one way out if the predicate is satisfied, else exception until a wrapping predicate is satisfied.
Use your tools, but don't make your work dependent upon the tool.
Sparsely document what is not obvious, otherwise don't waste time on non executables.
Makes you stop and think. At another job awhile back supporting commercial software I got a support call from a customer in France. After we discussed his options, off the cuff I asked him what kind of business they were in. He replied that he was calling from a nuclear power plant somewhere south of Paris. I hope it was for accounting instead of control, as it wasn't specfically certified for such things!
I also got a call from Japan. After we discussed the problem, it was a bank, I asked about the impact of the problem. He replied that his bank was the only one in Japan that processed Master Card and they were down.
I guess it doesn't pay to take anyting for granted even if your just marketing "White Bread" software, not the CIA kind of stuff.
I hope the original requestor on this thread thinks about his coding practice options a bit and doesn't create yet another reason to go home frustrated at the end of the day.
I like the idea of source controlled designs. Having an index on the project name defining both the source controlled code and the designs ties it together without wasting time maintaining links in each module.
Coding practices are generally the BANE of good programming! I've spent more hours in code reviews arguing and wasting time correcting violations of a companies rigid coding guildlines and then spending a few minutes at the end actually fixing a design or coding problem.
DON'T STIFLE CREATIVITY!
Therefore here is what you do:
First code reviews are intended to one: find design flaws, two: Find bugs, Three: allow experienced staff to review the decisions and prevent a tactical solution from causing a strategic train wreck.
If you have a standard language, then get your programming staff together and get them to agree on an automated code formatter. It is a total waste of staff time to spend 20% of their time manually conforming to a coding standard (what a productivity killer!).
Second find a documentation generator (JavaDoc rules, but if your not a Java shop then there are plenty of other code specific options). All the desktop cpu's spinning around should be doing the basic grunt work and the programmers should be adding the icing to the cake.
Comments should supply EXTRINSIC information period! They are there to let people know what is not already obvious from the code!
Intrinsic information should be imbedded in the code itself (it doesn't become obsolete). This means good naming of global variables, avoiding magic numbers, etc.
Interfaces between code components should be independly defined from the particular implementation in the program itself and ideally designed and concocted by senior staff in reviews of what needs to be communicated between components.
All programs which cross communicate MUST use these interfaces period!
Interfaces should be peer-to-peer in that only the information needed to facilitate the communication is defined in the interface definition. Peer specific information should be passed in opaque objects that the peers can revise at will. This allows the peers to rapidly develop without causing ripples throughout the rest of the components.
Follow History:
1: Understand and comply with Structured Code concepts (all basic line code within an object should be formally structured). Any Generic directed Graph can be put into a structure and at least informally proofed. Please try to design modules with one entry - one exit! Error handling should be based on the following concept: If the predicate logic for the module is not violated then continue to the normal exit. If the predicate logic is violated then exit via an exception mechanism and cascade up until you reach a level where the predicate logic is again valid.
2: Use the new Object oriented concepts for container design.
3: Put as much of the logic in the static structure as possible so the dynamic coding pieces are small, concise navigations of the structures.
4. Each thread should work internally as if it were a stand alone serial program.
Finally check out:
The Elements of Programming Style (Paperback)
by Brian W. Kernighan, P. J. Plauger
The object of coding practices is to facilitate the efficient writing of good solid code, not imposing intentionally or unintentionally a bureaucratic nightmare. Stroking the ego of an autocrat does nothing for the company but stroking the ego of the autocrat.
If C++ was statically deterministic during initialization and the templated versions did not grow exponentionally, then it might still be a viable language even though it is an academic version of IBM's PL1.
c was and still is a great generic universal (somewhat portable) assembler language which is why it is at the core of so many OSs.
Why didn't they just generate c from Smalltalk instead of writing C++? Gee I bet that is/was already being done!
And I don't even code in Smalltalk, but am stuck in the Java world for various reasons both good and bad, although I got there through Fortran, Cobol, BAL (IBM's version), PL1, c, 2 years of C++ OJT development, and now the WebSphere container environment.
Primary Questions
What is your target environment, language?
What is your objective?
What is your time line?
What are your available resources and what is their available time to apply to this effort?
Additional questions?
Do you have a working version of the original installed Game?
Can you get the missing source or if not possibly "Reverse Engineer" it?
Get your students interested, have them use Google Docs using XHTML with xml encoded embedded java code which they marshal and unmarshal using standard java library xml support into and out of whatever editor/development environment that each one wishes to use.
Traditional literacy is not a requirement for effective use of electronic communication, and as a bonus quickly learning an informal communication system (supplemented by verbal/visual content) is the best rapid learning curve in existence ( think of the scores of Pidgin languages that have and still do crop up for bartering over the centuries). On a wireless net using new low powered devices with solar and other locally available energy sources, this network can reach anyone anywhere. If this works out even filthy rich folks can use it for casual means and to keep in touch with everyone else while still having their exorbitant gadgets, etc. I think one of the problems with attempts to provide a laptop for all is not marketing them to everyone (the original buy two keep one and have one shipped to someone who can't buy one was the best model for shared communication and common ground, but it was dropped for simplistic pointless philosophical reasons and I suspect for serious market pressure from vested interests, someone correct me if I'm wrong, I wanted one and liked the idea of someone else getting one who needed it!) Real Human progress depends on those with more than sufficient marginal means setting aside about 20 percent of the Global marginal resources to build a minimal level of Human infrastructure that provide dignity and opportunity. The best way to insure that you don't starve is to build a society where no one is allowed to starve even if you occasionally have to eat hamburger. I applaud Google and I hope they eventually make money fairly for this foresight and imagination.
If you are forced to use adds for revenue then the only real trick is to require that you keep ownership and legal control over the provided add space. Any legal deal that requires you to give up control and ownership of the leased space except for your standard allowed content agreement should be rejected. Otherwise you've actually given up control fo Wikipedia and it will not be long before your new owners will be dictating their terms to the Wikipedia community. Also don't fully depend on your add revenue or your survival will be in their hands regardless of your legal contract. You might lose the big boys in the add business with that policy but do you really want to do business with them? Those who understand Wikipedia will place their adds there, the others are unwelcome predators that the community doesn't need!
If you are teaching an IDE then use an IDE and treat the language as an afterthought. If you are teaching a programming language then teach them the language and then introduce an IDE as a productivity tool if you so desire. Note: IDEs come and go in and out of vogue and if they are vendor specific as may be true in programming shops where the students will work that particular ventor's package, and of cource IDE, may be gone in 6 months. That is not an assumption on my part but an observed fact of life. IDE's do not reflect the raw behavior of the language and more to the point often can and do make underlying assumptions or operational decisions. Being second guessed by a programmer 2 years ago who thougt that feature of the IDE was cool can be an annoying experience at the best and a fatal one at the worst. It is difficult enough to get a clean behavior of a particular language relative to its specification in a bare bones environment much less as an embedded component in a complex IDE. IDE debuggers don't always reflect the true behavior of the program under general hardware/OS conditions. There are also debugging issues, especially in production environments where the IDE cannot be used in many cases. One of the side effects is often the failure of putting in reasonable program logging and debugging statements because the IDE debugger makes them unnecessary. That can leave you holding the bag at 2:00 am. trying to solve a critical production problem without any usable information. IDE's can become crutches in that a basic understanding of the programming process is assumed to be the process behavior of the IDE, especially by a novice. Sometimes IDE environments can be buggy (after all they are just an added layer of programming complexity from an operational standpoint). You don't have to create expert System Programmers with all the nuances of hardware/assembler/compilier specifices, just give them a basic development environment that can edit/compile/build the basic language for the available hardware/os. After you've gotten them working with the basic language give them the option of using an IDE but have some work that is independent of the IDE always included in the exercises for the rest of the course. If you don't want to be pedantic then after the initial introduction make the non IDE related exercises extra credit. There is nothing wrong with an IDE as a tool, but that is all that it is a tool to managing the programming environment. What counts is what actually ends up running on the hardware and the student's basic understanding of it. Consider that a student properly exposed in this manner can then move from one IDE to another and even work when necessary without one. Basic programming practices (Structured logic, Object Related Design), and a real understanding of the basic language behavior relative to the state machine coupled with some workable knowledge of the standard associated libraries goes a long way to building a competent programmer.
X-treme programming is all the rage now, lucky you you just graduated early :)
Pedantry and conventional wisdom, plenty there are in your replies :)
Think out of the box, but wear a raincoat.
Asymmetric programming as in asymmetric warfare.
NUMA
If someone likes doing something then let them do it as it is more efficient then wasting time and energy making someone do what they don't like :)
Walk backwards until you get where you both are now.
Generate the expected output then figure how to get the computer there, both of you team up on the one Professor that won't grade on the curve the third member of your team the computer.
Time is your friend if you don't let someone else make it your enemy. Thinking about a deadline obviously wastes time better used on just about anything else.
Teaching is the best form of learning.
Of the 4 dimensions light prefers the geodesic in time. Your working surface might just as well be hyperbolic or not. Hint: Static structures with the shortest timelines for logic flow :) One can build the road and the other drive the car and swap every now and then.
You can work with anybody if they can work with you.
5 minutes of communication, 20 minutes of work, 2 hours of sleep.
Unless life and death internal conflict is the issue at stake your personal state's of mind during the journey will mean little at the victory celebration even if you never speak to each other again.
Even if you did all the work yourself you would be no worse off than if you were on the project by yourself except that you wouldn't get the 20% credit expected for learning teamwork in the latter case.
In life you will either work with your equal, or someone superior or someone inferior. Working with your equal is usually the most difficult especially if you get along and make the same mistakes ;)
Different folks are equal at different times.
Objects, Structured Programming, minimal proofing (Logic envelopes approaching a convex hull, but don't waste time on the optimal fit as soon as you find a sufficient fit). One way in one way out if the predicate is satisfied, else exception until a wrapping predicate is satisfied.
Use your tools, but don't make your work dependent upon the tool.
Sparsely document what is not obvious, otherwise don't waste time on non executables.
Makes you stop and think. At another job awhile back supporting commercial software I got a support call from a customer in France. After we discussed his options, off the cuff I asked him what kind of business they were in. He replied that he was calling from a nuclear power plant somewhere south of Paris. I hope it was for accounting instead of control, as it wasn't specfically certified for such things! I also got a call from Japan. After we discussed the problem, it was a bank, I asked about the impact of the problem. He replied that his bank was the only one in Japan that processed Master Card and they were down. I guess it doesn't pay to take anyting for granted even if your just marketing "White Bread" software, not the CIA kind of stuff. I hope the original requestor on this thread thinks about his coding practice options a bit and doesn't create yet another reason to go home frustrated at the end of the day.
I like the idea of source controlled designs. Having an index on the project name defining both the source controlled code and the designs ties it together without wasting time maintaining links in each module.
I hope the company wasn't designing airplanes :)
Coding practices are generally the BANE of good programming! I've spent more hours in code reviews arguing and wasting time correcting violations of a companies rigid coding guildlines and then spending a few minutes at the end actually fixing a design or coding problem. DON'T STIFLE CREATIVITY! Therefore here is what you do: First code reviews are intended to one: find design flaws, two: Find bugs, Three: allow experienced staff to review the decisions and prevent a tactical solution from causing a strategic train wreck. If you have a standard language, then get your programming staff together and get them to agree on an automated code formatter. It is a total waste of staff time to spend 20% of their time manually conforming to a coding standard (what a productivity killer!). Second find a documentation generator (JavaDoc rules, but if your not a Java shop then there are plenty of other code specific options). All the desktop cpu's spinning around should be doing the basic grunt work and the programmers should be adding the icing to the cake. Comments should supply EXTRINSIC information period! They are there to let people know what is not already obvious from the code! Intrinsic information should be imbedded in the code itself (it doesn't become obsolete). This means good naming of global variables, avoiding magic numbers, etc. Interfaces between code components should be independly defined from the particular implementation in the program itself and ideally designed and concocted by senior staff in reviews of what needs to be communicated between components. All programs which cross communicate MUST use these interfaces period! Interfaces should be peer-to-peer in that only the information needed to facilitate the communication is defined in the interface definition. Peer specific information should be passed in opaque objects that the peers can revise at will. This allows the peers to rapidly develop without causing ripples throughout the rest of the components. Follow History: 1: Understand and comply with Structured Code concepts (all basic line code within an object should be formally structured). Any Generic directed Graph can be put into a structure and at least informally proofed. Please try to design modules with one entry - one exit! Error handling should be based on the following concept: If the predicate logic for the module is not violated then continue to the normal exit. If the predicate logic is violated then exit via an exception mechanism and cascade up until you reach a level where the predicate logic is again valid. 2: Use the new Object oriented concepts for container design. 3: Put as much of the logic in the static structure as possible so the dynamic coding pieces are small, concise navigations of the structures. 4. Each thread should work internally as if it were a stand alone serial program. Finally check out: The Elements of Programming Style (Paperback) by Brian W. Kernighan, P. J. Plauger The object of coding practices is to facilitate the efficient writing of good solid code, not imposing intentionally or unintentionally a bureaucratic nightmare. Stroking the ego of an autocrat does nothing for the company but stroking the ego of the autocrat.
If C++ was statically deterministic during initialization and the templated versions did not grow exponentionally, then it might still be a viable language even though it is an academic version of IBM's PL1.
c was and still is a great generic universal (somewhat portable) assembler language which is why it is at the core of so many OSs.
Why didn't they just generate c from Smalltalk instead of writing C++? Gee I bet that is/was already being done!
And I don't even code in Smalltalk, but am stuck in the Java world for various reasons both good and bad, although I got there through Fortran, Cobol, BAL (IBM's version), PL1, c, 2 years of C++ OJT development, and now the WebSphere container environment.
Primary Questions
What is your target environment, language?
What is your objective?
What is your time line?
What are your available resources and what is their available time to apply to this effort?
Additional questions?
Do you have a working version of the original installed Game?
Can you get the missing source or if not possibly "Reverse Engineer" it?