I think Cisco was interested in the consumer market. Perhaps they saw what Apple did with the iPod or the iPhone and thought that they could build high end consumer devices for a decent margin. They bought Linksys and Flip and released a couple of other produce lines targeted at the consumer market. I think that the strategy changed a couple of years ago. The recession was in full swing. Cisco's enterprise hardware wasn't meeting its targets, and I think that they told the analysts that Cisco would refocus on their core market. It's a good idea to diversify, but if you simultaneously fail at new markets and start slipping in your core market, something has to change.
Regarding number 3: This is the most interesting one. What if the scientists had predicted the quake (as at least one individual did, albeit as more of a guess)? What would everyone have done differently?
Apparently, some residents were sleeping outside until the reassurances from the scientists on the panel.
Managing a project with everyone in the same office is difficult. (Evaluate candidates. Hire employees. Make sure everyone understands the requirements. Balance workload. Figure out dependencies so that no one is blocked. etc.)
Managing a project where some of your programmers are remote is more difficult, even if they live in the same country and speak the same language.
Managing a project where some of your programmers are in a different country with a different primary language and a different business culture is even more difficult.
If your company is failing at managing local projects, I doubt that you're going to succeed at managing offshore projects.
If you're a small business who wants to use offshoring, I would recommend involving an onshore company to manage the offshoring. It won't be the lowest price, but if they take your project, the results will probably be much better. For example, I would recommend my friends who run this company: www.thesevensoft.com.
Yes and no. I mean, no one wants to buy a crummy product. On the other hand, producers need to be able to sell the product with specific volume and price points to make the profit margins that they plan years in advance. There are some very careful trade offs involved in that kind of work. In business, it's possible to launch and sell a profitable product line and still fail because you came in at a profit margin of 10% instead of 30%.
Isn't that sort of the core of the discussion over HP's WebOS tablets? They can make and sell them, but their desired price point didn't produce the volume of sales that they needed. The product that was crummy at one price point became awesome at another. Can HP find a price where they'll get the sales that they need to make enough profit to make it worthwhile? Even if they can sell the tables for a tiny profit, HP may prefer to focus their time, people, and capital on other, more profitable businesses.
Compared to some other companies, I'm actually impressed with the length of Cisco's technical track. It's possible to a long technical career within the company with regular pay increases and promotions without switching to the "business" side. In many companies, promotions quickly push technical people into management or technical sales or something. I haven't seen that at Cisco.
Of course, I still expect that the people who are closer to sales and major product decisions (VPs and SVPs) to make more than the senior engineers. Fortunately, I've also seen that Cisco is willing to fire upper management if they make too big or too many bad decisions that hurt margins, product quality, etc. Listening to the message Chambers has been putting out, part of the restructuring seems to be aimed at increased accountability in upper management. It's no use to build awesome products if the company can't sell them or can't sell them at a profit.
I believe that smartphones with video overtook the Flip faster than Cisco expected. The Flip was a good little device, but it was too expensive for a single purpose device once smartphones started including HD video recording. Cisco would either have to drop the Flip prices and work for much smaller margins, or it would have to kill the division. It chose to do the latter so that it could use that money on its core products.
I'm always surprised by what information is accessed when systems are compromised from the Internet. Isn't the purpose of SIPRNet to keep classified information off of machines that are connected (in any way) to a public network?
What editor are you using that doesn't generate your getters and setters for you?
In Eclipse, for example, that would be Source > Generate Getters and Setters...
Just don't watch the movie too many times. Eventually you'll forget, and you can go back to imagining whatever you want. This infection of someone else's image isn't a new problem. People have been making realistic paintings and drawings for centuries.
And instead of just bemoaning the lack of imagination, we should think about what is missing when the consumer doesn't supply something himself. I think that it's neat that the technology is advanced enough that Mr. Jackson can show me what he was imagining. But there are things that are difficult to show, and I think that Shelob is a better example of that. After they did a pretty good job with the Nazgûl and the Balrog, I was hoping for more with Shelob. I was disappointed that they just seemed to present her as a big spider. I always wondered how they'd try to convey a sense that she was the "last child of Ungoliant to trouble the unhappy world....who was there before Sauron, and before the first stone of Barad-dûr; and she served none but herself, drinking the blood of Elves and Men, bloated and grown fat with endless brooding on her feasts, weaving webs of shadow; for all living things were her food, and her vomit darkness."
I think that's really hard to convey in a movie, but it didn't seem like they even tried. It's hard to show someone what a complete, oppressive, and malevolent darkness is like. Something that makes your mind forget what light is. Shelob isn't a big spider. She's more like a demon in current terminology: the embodiment of an ancient evil. With good writing and a good imagination in the reader, Shelob becomes much more terrifying than a big spider.
You may want to look into Tasktop. You can connect the task list to one or more task system back ends or just use local tasks. The advantage of Tasktop is that it can track context for each task. That way, when you want to return to a task that you haven't touched in two weeks, restoring the task in Tasktop can get you right back to the web pages, e-mails, etc. that you were accessing while working on the task last time. It also has integration with Eclipse if you do your development in Eclipse.
I'd add Adams's The Knot Book to your list. I've been out of the field for some time, but I remember that this book gave an accessible introduction to knot theory and some notions of topology, presented at a high school level.
It's not exactly a new book, so some of the unsolved problems listed in the book may now be solved. In any case, it's one of the few I know that help a younger student go into more depth in an area where there's still active research going on. It's a difficult subject where many of the theorems can be proved without resorting to higher mathematics.
I'd imagine that there are probably similar texts for some areas of number theory and game theory, but nothing springs to mind. Non-Euclidean geometry may also be an option if the students have already taken geometry, and there were some text books that I found at least partially accessible in high school.
The Mathematical Tourist is even more out-of-date by this time. Since it's really a survey of many areas, it doesn't really meet your need, but you may find it useful yourself for looking into other areas that may be accessible to your students.
Finally, contact your local mathematics and math education departments. The math education folks may have some good suggestions. Many mathematics departments also do some sort of outreach to high school students, so there may also be some faculty there who could offer ideas.
I found that last comment from the article a bit odd. They've dropped the rating on the Prius to 48/45/46. I suppose that I do a mix of driving: some local start and stop around 35 MPH, a lot of commuting on interstates (65 - 80 MPH) and state highways (50 - 60 MPH).
Over the past two years, I generally average much closer to 50 MPG. During the winter (worse battery efficiency), it's closer to 45 MPG. During the the rest of the year, it's generally more like 52 MPG. I don't drive like a maniac, but I'm not super careful about squeezing every last bit of efficiency out of the car. I'm not sure what you'd need to drive like to pull the Prius numbers much below the new figures.
But, yeah, the new numbers look more realistic than the old numbers.:-)
I disagree. I could be very useful in the interview process. We used it just to give us something very concrete and technical to discuss with the engineer. Throwing some people questions makes them very nervous, like they're being tested. Having them bring some of their own code to discuss makes most good engineers very relaxed. Here, they get to show their prospective employer something that they're reasonably happy with. If I ask any questions, they're usually very quick to answer. Now, I'm the "newbie" in the code, and they're just showing me around.
I suppose that it depends why the potential employer wants it. Ask them. Many programmers just "steal" a page of code from some system they're working on even if it is proprietary. If you don't feel comfortable doing that, just work on something for a few hours. Whatever you have time to do. It might not have to be complete or very complex.
When one of my managers started asking new candidates for code samples, it was actually quite useful in the interview process. I really didn't care whether they wrote it or downloaded it. We weren't looking for "do you know how to write code." We were really interested in hearing you talk about code. Hopefully, you sent us something you wrote. But it wasn't critical to the interview that you did.
That is, you'd send us a page or two of code the day before the interview. It didn't even have to be in the programming language we were hiring you for (Java, C++, or Perl). One guy sent us some LISP code. Your interviewers would read over the code. Then, during the interview, we'd take out a copy of the code, ask you to give us an overview of what it does, and ask some more specific questions.
Some examples: For a systems/tools job, one guy just pointed us to a little module in CPAN. The CPAN code had good PERLDOC comments, of course. It was packaged as a module. The guy could explain why he ended up writing it and talk about the code even though it had been a few years since he touched it. Another guy sent us code to a CGI script that he used on a personal web server to track some data between him and his friends. That code was okay, and the guy could explain what he was doing. But it was also a giant flat script. No subroutines. Almost no comments. Program logic and HTML output intervleaved in a somewhat confusing manner. The developer who sent us the CPAN code got the job. Not just on the basis of his code, but it just confirmed everything else we got out of the interviews.
For another position, some developers sent us a page or two lifted from some of their Java code. Of course, in any real application, a page or two of code doesn't show you much. Still, one guy sent us code with what were almost certainly errors in it. Rather than telling the developer, "Um, this looks like an error," we just asked him to explain what the code was doing. I've rarely seen a candidate look so nervous. He didn't really seem to know what the code was doing. Either he didn't write the code, or he didn't really feel comfortable talking about code. Bzzt. Not someone we wanted on our team. In any case, if you're going to steal code, try to have good enough taste to steal good code. And if you're showing me code that you didn't write, at least take the time to read it and understand what it does.
For the same job, another developer sent us code for a few methods. As soon as I started asking about the code, she looked so relaxed. Now we were just two engineers talking about code. She started sketching in the margins of the page to show a rough system architecture and where this code fit in. She explained a bit of the data flow and some use cases where the users interacted with the system. We talked about the data being passed in to one of the methods. At one point, she wanted to explain something, realized that she hadn't sent us that code, and sketched a rough version of the code on the back of one of the pages. Her quick version had a silly error. When I pointed it out, she just laughed and said, "Oh, right. It should be like this," and she fixed it. But she was eager to get back to explaining where that sketched code connected to the other code. That's the kind of developer we were looking for.
That is, use Plone, built on Zope. Do not use Zope itself for what you're trying to do. Zope is a framework. Plone is an Open Source CMS built using Zope.
Plone probably gives you most of what you need "out of the box": users, groups, workflow, searching, content/presentation separation, some standard content types, etc. You'll probably want to customize the style to match your site and eventually create some custom content types. In that case, you'll need to read some of the documentation. Thankfully, there's finally a good Plone book available:
The Definitive Guide to Plone.
Most universities have some sort of "Office of Undergraduate Education." Heck, at large universities, each department may have something like an undergraduate coordinator. Since you're doing online courses, there may be an additional channel to provide feedback specifically about the online content.
When I was in grad school, I remember that I heard a lot of students grumbling and complaining to each other about the profs. You know people like these profs at your job. They're doing as little as they can possibly get away with in their undergrad classes. At many universities, teaching responsibilities only make up something like 10% of the consideration for raises and promotion. The rest is research, committee work, and such.
The only way a prof is forced to meet some minimum standard is year end evaluations from students, which contribute a little to his future raises and promotions, and feedback through administrative channels. I heard one student who had failed a class complaining to the undergraduate coordinator that the prof had basically neglected his duties. The undergraduate coordinator was basically saying that there was little he could do after the class was over and only one or two students came to complain. If, on the other hand, 20% of the students registered a complaint just before mid-term, then there was obviously something wrong. The prof would have probably been put under much more scrutiny. The department may have assigned someone to attend some of his classes and review the material he was giving the students. The prof is not at a university just to teach undergrads, but they do have a professional responsibility to you. The university is in charge of enforce a minimum standard of quality, but they can't do that without a lot of student feedback. If the university fails to act on such issues, then you might not like the product they're providing. Time to take your money elsewhere.
Anyway...long-winded post, but the point is that complaining anywhere but the appropriate channels at your school is not really going to help your situation. It's like complaining to your family about a difficult co-worker and gossiping about him behind his back but never confronting him or his manager directly about your issues. It might help blow off steam. You might get a lot of sympathy. But you're never going to help improve your situation without giving the feedback to the right people.
I've never tried them, and I don't even know whether
they'd run linux, but I've seen "X-Book" laptops
advertised at AccessMicro for under
$1000 without an OS.
On the average, it seems that humans often make decisions by following a locally greedy manner. By "locally," I mean temporally, geographically, etc. By "greedy," I mean less capital and time and effort and inconvenience. One goal then is to structure large (human) systems (like an economy) so that the locally greedy decision will be the "right" decision. Your point of accounting for externalities in the initial cost of a product is one way of doing that. It puts the cost of the long term consequences of a decision into the initial expense. Thus, when I decide which carpet to buy, I don't have to weigh carpet price plus cost of tax increase so EPA can clean up waste water plus increased unemployment benefits for workers displaced by a company moving operations overseas plus the cost of disposing of it in 15 years etc.
Of course, getting people to agree on which decision is "right" is often the problem.
See Zope fishbowl. It's a nice summary of a very lightweight process with some well-written thoughts on why such/any process is necessary.
As far as where to start, start with what you have. Most (not all) developers are happy to put their meeting notes, design docs, and such in a common/standard location and format (I recommend a text-based format in a revision control system) if one is simply designated. Someone whose technical ability they respect may have to remind some of the developers from time to time to put their docs in the designated place or to create a document from some important conversation.
Be careful not to attempt to switch from what you have now (nothing) to something unrealistic (full UML class and system diagrams, workflows, and state transition diagrams for every project). Be realistic and simply start to collect what you've got. Designate a spot for hard copy documentation and electronic documentation. Another easy first step is to designate a common format (ASCII, HTML, PDF, StarOffice, whatever).
Give that a few months to sink in. Then start to list common documents that should normally be associated with a project. Several separate "artifacts" of a project may include requirements, functional (user-visible functionality) design, detailed (class hierarchy and component interaction) design, implementation notes, decision log (bullet items of decisions made with date and those involved).
Remember: something is better than nothing. If each project simply has a decision log (Greg and Sheila decided not to support wizbang with a froznobit because it would cause all the tulips to wilt), then you have a start. Six months later, when someone asks, "Why didn't we use froznobits to implement wizbang? Maybe we should fix that," they'll have somewhere to look for the answer. The same can be said of requirements and functional design. Developers can usually figure out detailed design by long hours spent pouring over code. There's no way to divine what a program is *supposed* to do if there are no comments and no requirements and no functional design.
Future of CP4E (Computer Programming For Everyone)
on
Ask Guido van Rossum
·
· Score: 1
With the move away from CNRI, the Python development team now has private sector employers who presumably demand development time on their projects in addition to the Python core. Since your current employer does not produce educational software, one can only assume that you and your team don't spend much time working on CP4E.
In fact, the CP4E page says "The project is now in limbo; we're still interested, and we're still working on IDLE, but we aren't actively pursuing the other goals of CP4E."
How important is CP4E and its goals to you personally? Was it just an neat idea to try to get funding, or are you personally committed to furthering the vision presented in that proposal? Should we expect to see you involved with similar efforts in the future, or are you simply happy to have planted the idea in other programmers' heads?
Slashdot Mirror
The major problem with Agile is that it is the new software development buzzword, and thus is perceived as a golden bullet for software development.
Golden bullet? What!? Are you fighting wererabbits over there?
I think Cisco was interested in the consumer market. Perhaps they saw what Apple did with the iPod or the iPhone and thought that they could build high end consumer devices for a decent margin. They bought Linksys and Flip and released a couple of other produce lines targeted at the consumer market. I think that the strategy changed a couple of years ago. The recession was in full swing. Cisco's enterprise hardware wasn't meeting its targets, and I think that they told the analysts that Cisco would refocus on their core market. It's a good idea to diversify, but if you simultaneously fail at new markets and start slipping in your core market, something has to change.
Regarding number 3: This is the most interesting one. What if the scientists had predicted the quake (as at least one individual did, albeit as more of a guess)? What would everyone have done differently?
Apparently, some residents were sleeping outside until the reassurances from the scientists on the panel.
Managing a project with everyone in the same office is difficult. (Evaluate candidates. Hire employees. Make sure everyone understands the requirements. Balance workload. Figure out dependencies so that no one is blocked. etc.)
Managing a project where some of your programmers are remote is more difficult, even if they live in the same country and speak the same language.
Managing a project where some of your programmers are in a different country with a different primary language and a different business culture is even more difficult.
If your company is failing at managing local projects, I doubt that you're going to succeed at managing offshore projects.
If you're a small business who wants to use offshoring, I would recommend involving an onshore company to manage the offshoring. It won't be the lowest price, but if they take your project, the results will probably be much better. For example, I would recommend my friends who run this company: www.thesevensoft.com.
Good luck!
"They're fantastic writing, "
no, it isn't
Maybe I missed it, but I was surprised that no one mentioned this WoT review.
Yes and no. I mean, no one wants to buy a crummy product. On the other hand, producers need to be able to sell the product with specific volume and price points to make the profit margins that they plan years in advance. There are some very careful trade offs involved in that kind of work. In business, it's possible to launch and sell a profitable product line and still fail because you came in at a profit margin of 10% instead of 30%.
Isn't that sort of the core of the discussion over HP's WebOS tablets? They can make and sell them, but their desired price point didn't produce the volume of sales that they needed. The product that was crummy at one price point became awesome at another. Can HP find a price where they'll get the sales that they need to make enough profit to make it worthwhile? Even if they can sell the tables for a tiny profit, HP may prefer to focus their time, people, and capital on other, more profitable businesses.
Of course, I still expect that the people who are closer to sales and major product decisions (VPs and SVPs) to make more than the senior engineers. Fortunately, I've also seen that Cisco is willing to fire upper management if they make too big or too many bad decisions that hurt margins, product quality, etc. Listening to the message Chambers has been putting out, part of the restructuring seems to be aimed at increased accountability in upper management. It's no use to build awesome products if the company can't sell them or can't sell them at a profit.
I believe that smartphones with video overtook the Flip faster than Cisco expected. The Flip was a good little device, but it was too expensive for a single purpose device once smartphones started including HD video recording. Cisco would either have to drop the Flip prices and work for much smaller margins, or it would have to kill the division. It chose to do the latter so that it could use that money on its core products.
(Yes, yes. I know that you meant cue, not queue.)
I'm always surprised by what information is accessed when systems are compromised from the Internet. Isn't the purpose of SIPRNet to keep classified information off of machines that are connected (in any way) to a public network?
TFA is talking about the residential white pages. Not the yellow pages.
What editor are you using that doesn't generate your getters and setters for you? In Eclipse, for example, that would be Source > Generate Getters and Setters...
Just don't watch the movie too many times. Eventually you'll forget, and you can go back to imagining whatever you want. This infection of someone else's image isn't a new problem. People have been making realistic paintings and drawings for centuries.
And instead of just bemoaning the lack of imagination, we should think about what is missing when the consumer doesn't supply something himself. I think that it's neat that the technology is advanced enough that Mr. Jackson can show me what he was imagining. But there are things that are difficult to show, and I think that Shelob is a better example of that. After they did a pretty good job with the Nazgûl and the Balrog, I was hoping for more with Shelob. I was disappointed that they just seemed to present her as a big spider. I always wondered how they'd try to convey a sense that she was the "last child of Ungoliant to trouble the unhappy world....who was there before Sauron, and before the first stone of Barad-dûr; and she served none but herself, drinking the blood of Elves and Men, bloated and grown fat with endless brooding on her feasts, weaving webs of shadow; for all living things were her food, and her vomit darkness."
I think that's really hard to convey in a movie, but it didn't seem like they even tried. It's hard to show someone what a complete, oppressive, and malevolent darkness is like. Something that makes your mind forget what light is. Shelob isn't a big spider. She's more like a demon in current terminology: the embodiment of an ancient evil. With good writing and a good imagination in the reader, Shelob becomes much more terrifying than a big spider.
You may want to look into Tasktop. You can connect the task list to one or more task system back ends or just use local tasks. The advantage of Tasktop is that it can track context for each task. That way, when you want to return to a task that you haven't touched in two weeks, restoring the task in Tasktop can get you right back to the web pages, e-mails, etc. that you were accessing while working on the task last time. It also has integration with Eclipse if you do your development in Eclipse.
It's not exactly a new book, so some of the unsolved problems listed in the book may now be solved. In any case, it's one of the few I know that help a younger student go into more depth in an area where there's still active research going on. It's a difficult subject where many of the theorems can be proved without resorting to higher mathematics.
I'd imagine that there are probably similar texts for some areas of number theory and game theory, but nothing springs to mind. Non-Euclidean geometry may also be an option if the students have already taken geometry, and there were some text books that I found at least partially accessible in high school.
The Mathematical Tourist is even more out-of-date by this time. Since it's really a survey of many areas, it doesn't really meet your need, but you may find it useful yourself for looking into other areas that may be accessible to your students.
Finally, contact your local mathematics and math education departments. The math education folks may have some good suggestions. Many mathematics departments also do some sort of outreach to high school students, so there may also be some faculty there who could offer ideas.
I found that last comment from the article a bit odd. They've dropped the rating on the Prius to 48/45/46. I suppose that I do a mix of driving: some local start and stop around 35 MPH, a lot of commuting on interstates (65 - 80 MPH) and state highways (50 - 60 MPH).
:-)
Over the past two years, I generally average much closer to 50 MPG. During the winter (worse battery efficiency), it's closer to 45 MPG. During the the rest of the year, it's generally more like 52 MPG. I don't drive like a maniac, but I'm not super careful about squeezing every last bit of efficiency out of the car. I'm not sure what you'd need to drive like to pull the Prius numbers much below the new figures.
But, yeah, the new numbers look more realistic than the old numbers.
I disagree. I could be very useful in the interview process. We used it just to give us something very concrete and technical to discuss with the engineer. Throwing some people questions makes them very nervous, like they're being tested. Having them bring some of their own code to discuss makes most good engineers very relaxed. Here, they get to show their prospective employer something that they're reasonably happy with. If I ask any questions, they're usually very quick to answer. Now, I'm the "newbie" in the code, and they're just showing me around.
I suppose that it depends why the potential employer wants it. Ask them. Many programmers just "steal" a page of code from some system they're working on even if it is proprietary. If you don't feel comfortable doing that, just work on something for a few hours. Whatever you have time to do. It might not have to be complete or very complex.
When one of my managers started asking new candidates for code samples, it was actually quite useful in the interview process. I really didn't care whether they wrote it or downloaded it. We weren't looking for "do you know how to write code." We were really interested in hearing you talk about code. Hopefully, you sent us something you wrote. But it wasn't critical to the interview that you did.
That is, you'd send us a page or two of code the day before the interview. It didn't even have to be in the programming language we were hiring you for (Java, C++, or Perl). One guy sent us some LISP code. Your interviewers would read over the code. Then, during the interview, we'd take out a copy of the code, ask you to give us an overview of what it does, and ask some more specific questions.
Some examples: For a systems/tools job, one guy just pointed us to a little module in CPAN. The CPAN code had good PERLDOC comments, of course. It was packaged as a module. The guy could explain why he ended up writing it and talk about the code even though it had been a few years since he touched it. Another guy sent us code to a CGI script that he used on a personal web server to track some data between him and his friends. That code was okay, and the guy could explain what he was doing. But it was also a giant flat script. No subroutines. Almost no comments. Program logic and HTML output intervleaved in a somewhat confusing manner. The developer who sent us the CPAN code got the job. Not just on the basis of his code, but it just confirmed everything else we got out of the interviews.
For another position, some developers sent us a page or two lifted from some of their Java code. Of course, in any real application, a page or two of code doesn't show you much. Still, one guy sent us code with what were almost certainly errors in it. Rather than telling the developer, "Um, this looks like an error," we just asked him to explain what the code was doing. I've rarely seen a candidate look so nervous. He didn't really seem to know what the code was doing. Either he didn't write the code, or he didn't really feel comfortable talking about code. Bzzt. Not someone we wanted on our team. In any case, if you're going to steal code, try to have good enough taste to steal good code. And if you're showing me code that you didn't write, at least take the time to read it and understand what it does.
For the same job, another developer sent us code for a few methods. As soon as I started asking about the code, she looked so relaxed. Now we were just two engineers talking about code. She started sketching in the margins of the page to show a rough system architecture and where this code fit in. She explained a bit of the data flow and some use cases where the users interacted with the system. We talked about the data being passed in to one of the methods. At one point, she wanted to explain something, realized that she hadn't sent us that code, and sketched a rough version of the code on the back of one of the pages. Her quick version had a silly error. When I pointed it out, she just laughed and said, "Oh, right. It should be like this," and she fixed it. But she was eager to get back to explaining where that sketched code connected to the other code. That's the kind of developer we were looking for.
That is, use Plone, built on Zope. Do not use Zope itself for what you're trying to do. Zope is a framework. Plone is an Open Source CMS built using Zope.
Plone probably gives you most of what you need "out of the box": users, groups, workflow, searching, content/presentation separation, some standard content types, etc. You'll probably want to customize the style to match your site and eventually create some custom content types. In that case, you'll need to read some of the documentation. Thankfully, there's finally a good Plone book available: The Definitive Guide to Plone.
When I was in grad school, I remember that I heard a lot of students grumbling and complaining to each other about the profs. You know people like these profs at your job. They're doing as little as they can possibly get away with in their undergrad classes. At many universities, teaching responsibilities only make up something like 10% of the consideration for raises and promotion. The rest is research, committee work, and such.
The only way a prof is forced to meet some minimum standard is year end evaluations from students, which contribute a little to his future raises and promotions, and feedback through administrative channels. I heard one student who had failed a class complaining to the undergraduate coordinator that the prof had basically neglected his duties. The undergraduate coordinator was basically saying that there was little he could do after the class was over and only one or two students came to complain. If, on the other hand, 20% of the students registered a complaint just before mid-term, then there was obviously something wrong. The prof would have probably been put under much more scrutiny. The department may have assigned someone to attend some of his classes and review the material he was giving the students. The prof is not at a university just to teach undergrads, but they do have a professional responsibility to you. The university is in charge of enforce a minimum standard of quality, but they can't do that without a lot of student feedback. If the university fails to act on such issues, then you might not like the product they're providing. Time to take your money elsewhere.
Anyway...long-winded post, but the point is that complaining anywhere but the appropriate channels at your school is not really going to help your situation. It's like complaining to your family about a difficult co-worker and gossiping about him behind his back but never confronting him or his manager directly about your issues. It might help blow off steam. You might get a lot of sympathy. But you're never going to help improve your situation without giving the feedback to the right people.
I've never tried them, and I don't even know whether they'd run linux, but I've seen "X-Book" laptops advertised at AccessMicro for under $1000 without an OS.
Of course, getting people to agree on which decision is "right" is often the problem.
See Zope fishbowl. It's a nice summary of a very lightweight process with some well-written thoughts on why such/any process is necessary.
As far as where to start, start with what you have. Most (not all) developers are happy to put their meeting notes, design docs, and such in a common/standard location and format (I recommend a text-based format in a revision control system) if one is simply designated. Someone whose technical ability they respect may have to remind some of the developers from time to time to put their docs in the designated place or to create a document from some important conversation.
Be careful not to attempt to switch from what you have now (nothing) to something unrealistic (full UML class and system diagrams, workflows, and state transition diagrams for every project). Be realistic and simply start to collect what you've got. Designate a spot for hard copy documentation and electronic documentation. Another easy first step is to designate a common format (ASCII, HTML, PDF, StarOffice, whatever).
Give that a few months to sink in. Then start to list common documents that should normally be associated with a project. Several separate "artifacts" of a project may include requirements, functional (user-visible functionality) design, detailed (class hierarchy and component interaction) design, implementation notes, decision log (bullet items of decisions made with date and those involved).
Remember: something is better than nothing. If each project simply has a decision log (Greg and Sheila decided not to support wizbang with a froznobit because it would cause all the tulips to wilt), then you have a start. Six months later, when someone asks, "Why didn't we use froznobits to implement wizbang? Maybe we should fix that," they'll have somewhere to look for the answer. The same can be said of requirements and functional design. Developers can usually figure out detailed design by long hours spent pouring over code. There's no way to divine what a program is *supposed* to do if there are no comments and no requirements and no functional design.
I spend much more time in my car than I spend in CmdrTaco. If anyone here doesn't, we probably don't want to hear about it.
Who said grammar wasn't important?
If you like Python, you can code Java applets in Python syntax, using Java components. See Jython's SourceForge page. In particular, read Compiling Python Source to Real Java Classes
With the move away from CNRI, the Python development team now has private sector employers who presumably demand development time on their projects in addition to the Python core. Since your current employer does not produce educational software, one can only assume that you and your team don't spend much time working on CP4E. In fact, the CP4E page says "The project is now in limbo; we're still interested, and we're still working on IDLE, but we aren't actively pursuing the other goals of CP4E."
How important is CP4E and its goals to you personally? Was it just an neat idea to try to get funding, or are you personally committed to furthering the vision presented in that proposal? Should we expect to see you involved with similar efforts in the future, or are you simply happy to have planted the idea in other programmers' heads?