There are often special items available only for preorders.
Granted, sometimes they are dumb (remember the Gold cartridge for Zelda?) but other times they are nice to have, like the special DVD that came with Xenosaga II that consisted of all the FMV clips from the first game. It helped me remember the complicated plot line from the first game, which enhanced my enjoyment of the second game.
When you preorder a game, you help the company
estimate the demand that exists.
It might even help the store estimate how many additional games they should order.
It would be great if there was a special pre-order price, which would help encourage people to order in advance.
As for paying a couple bucks more for a game from a small store, it is worth it to me. I can ask the people there about games, and they often will tell me about new games coming out that I hadn't heard about. Try asking any question to somebody at BB, WM, etc. About all they know is if it appears in their inventory.
I'm not sure I agree with your examples, but I agree that it is a sign that Open Source is growing up. The article also mentioned how Open Source has transitioned from a few volunteer hackers to corporate backed programmers. GNU went through the same transformation, so again I view this as a good thing.
The only concern is how much influence corporate needs drive open source rather than individual desires. However, I think in the end the coporate influence can help solidify Open Source due to the pragmatic nature of most corporations. I would rather have one fairly standard tool (e.g., Open Office) that works pretty well, is quite common, etc. rather than a wide variety of tools that all do pretty much the same thing.
Rather than building on the shoulders of those who came before, programmers tend to stand on their toes.;^)
A good example of the problem I hope this will solve is the age old/. question: "Which Unix Distro do you recommend?" I'm guessing there are a lot of people who haven't tried Linux simply because it is too confusing taking that first step of getting a "Linux".
I have trouble with the idea that "old people" want simple computers to use for simple things.
I think a better way of looking at it is a simple computer for people who aren't comfortable configuring their own computers. And that isn't limited to "old people".
For example, I'm 60, and am still writing computer programs for a living (and teaching it on the side.) Do you really think I'm looking for a simple computer? On the other hand, I am the one that gets a call when my teenage grandkids have problems with their computers.
Many young people might have less fear of computers, but doesn't mean they are better at it. I recall my grandson when he was very little playing with my SNES. Before I knew it, he had cleared all the save areas on a game my wife and I had spent hours on. He wasn't afraid of what he was doing, but he didn't know what he was doing either. There is a big difference.
There are a lot of people, from young to old, who simply keep clicking "OK" when installing something, and many of them don't even bother to read the questions.
IMHO, a "simple" PC that doesn't let people install programs is doomed to failure. Either the PC will have tons of programs, which will make it complicated to use, or it won't have everything the user wants.
Now, if you can make a computer that is easy to use, and makes it easy to install new programs, then you might have something. But, thinking that you can identify everything the users will want on their computer is wishful thinking.
I live in the Philly suburbs, and when we showed up to vote this morning there was an "extra" person who didn't seem to be official, but checked a computer printout. He didn't find our name, and when we told him that we had been voting there for over 20 years, he kept mumbling "you're not on this list". He went outside to talk to the local sleaze-ball republican politician who is there every year.
The official folks said there was no problem, since we were in the official book (the old-fashioned paper type). I'm wondering how many other Democratic names were "accidentally" lost from the list. I'm also wondering how a first-time voter might react to not being on the list.
True, but my point was: who of the original people involved within Dr. DOS benefitted?
It seems that the only folks who benefit are people who have purchased the assets from the original company (possibly after several transfers).
The reality is that Dr. DOS went out of business, closed up shop, and were no longer a competitor of Microsoft.
Somebody might have gotten some money out of the deal in the end, but the primary goal was to eliminate competition, which is what happened.
Unfortunately, the courts will probably never be a good place to rein in a monolopy. By the time it works it way through the entire legal process, none of the real competitors are still alive to benefit from any decision.
Within the last year, the Dr. Dos suit got settled. Who benefitted from that? And it is unlikely that Netscape (which exists in name, but not much else) would have gotten much out of this suit if things had gone differently.
And as much as I love FireFox,
the biggest thing it has going for it is
the fact that IE development has stagnated
for some time.
When it comes to technology, things change so fast
that any delay in settling any issues
means that whatever decision is finally made,
it will probably be pretty much meaningless.
Inertia is a powerful force,
and most people don't bother to download updates to their OS, let alone
download and install alternative replacements
for something that already came on their box.
I found reading this article quite fascinating. I'm one of those old-timers who remembers what Brooks was writing about. I've read that book several times, and still recommend it to people who want to understand software project management.
But what was most fascinating was the author's impressions of the book. He certainly pointed out artifacts that I had glossed over (they seemed normal to me).
However, I was also surprised at how he interpreted what Brooks said much different than I had.
For example, the above quote was in reaction to the statement:
"Often the fresh concept does come from an implementer or from a user. However, all my own experience convinces me, and I have tried to show, that the conceptual integrity of a system determines its ease of use. Good features and ideas that do not integrate with a system's basic concepts are best left out. If there appear many such important but incompatible ideas, one scraps the whole system and starts again on an integrated system with different basic concepts."
What I think Brooks was saying (or at least what I read from his statement) was that to add a new feature that behaved significantly different than the rest of the system is a bad idea, even if the new feature is very useful.
I don't have the book with me, but I'm guessing it was in the chapter where he talked about the beauty of a cathedral came from the fact that each builder followed the original plan.
(During the middle ages, it took so long to build massive church buildings that the construction spanned the lifetimes of several builders.
In many cases, each new builder had a "better idea", and so their part of the building looked different than the rest.
The result was a patchwork architure
that didn't look anywhere near as nice if any one of the individuals builders had been able to build the entire structure.)
I don't think Brooks was saying to ignore the needs of the users, but rather to make sure your changes fit into the overall structure of the program.
If different parts of the system work differently, it will most likely lead to user confusion.
That is why changes should fit within the framework of the original program.
Imagine a system where the author of each component was able to create their own user interface.
When you select option 'A', you do it this way,
but when you are using option 'B', you have to do it that way.
The end result is a confusing mess, even though each individual component might have a perfectly reasonable way of doing things.
Its just that most people expect a system to have some consistency in its behavior, appearance, and interfaces.
Speaking of ignoring users, however,
I recall reading an article where
Kernighan claimed you should ignore all suggestions when a system is first released.
The reason is that most people are reacting to the fact that they are trying to use the system differently than it was originally intended.
Often, they are expecting the new system to do something in the same way as some other system they used.
Once they get used to working with the system, they are able to anticipate how the system wants them to do something, and they become happier and more productive.
If you rush to implement many of the initial suggestions, you will often start changing the overall architecture and/or interface of the system, which is what Brooks (IMHO) is warning against.
I would think that even non-techies should realize this. Anyone who has looked at the "suggested corrections" in MS-Word should realize that sometimes that program has no idea what you are trying to say, and its "corrections" actually make it worse, not better.
I would hate to see Sun quietly close up shop and go home. Just like I hated to see DEC get sucked into Compaq.
Like it or not, when Sun started,
it had a bold new image of computing that turned out pretty accurate. Much of what they championed are now considered the norm. (The network is the computer).
When Sun started, most of us were using dumb terminals connected to a mainframe.
I recall a VP that kept turning down my requests for Sun workstations because he thought programmers just liked them because they were "cool".
Then one day, he saw a programmer checking boards from several different locations, and displaying debugging information at one terminal.
I never got any resistance for more Suns from him after that.
He became a convert.
If you compare J2EE with.Net,
it seems pretty clear to me which one is the
better environment.
Now, if only Sun could figure out how to make
money from J2EE.;^)
Much of the problem with Sun (IMHO) is in the management of the company.
Much of the rest of the problem is Sun's reluctance to adapt to the times.
(In part, because of the former problem.)
A lot of large government projects use Sun workstations, and many of them don't have the same pressure as others to come up with a cheaper solution.
If lives depend on a system, the fact that you can get something "almost as good" for less money doesn't have the same impact as, for example, a payroll system.
Because of that, Sun should be able to maintain a decent revenue stream, provided they don't end up losing more money than they take in.
I would hope that Sun could come up with some good managment that understands the technology and how it can be used, and how best to capitalize on their strengths.
In other words, not just the bean counter mentality that so often floats to the top of the corporate ladder.
Actually, many companies can and do track personal communications of their employees. In many cases, it is written into company policies, and by accepting employment, you accept their right to do that.
Technically, if you are at work and being paid, you shouldn't be doing anything personal. They're paying for you to be there, and they can demand / expect you to do what you are being paid for, not personal stuff. In fact, if you spend too much time doing personal things, they have the right to discipline, or even dismiss you.
Most companies I've worked for have a clause about "reasonable" personal business during work hours. It is okay to get a few calls from family or friends, but if you spend too much time, they have the right to tell you to curtail personal business.
It is personally reasonable for an employer to expect you to be engaged in whatever activity they are paying you for while you are "on the clock"
Similarly, they are free to open your desk when you are not around. After all, the desk is theirs, not yours. (There was a court case about this several years ago, and the employee lost.)
Employers have the right to control what you do with the computers and phones they provide for you to do the work they are paying you for. You have no right to expect that you can use their equipment, bandwidth, office supplies, etc. for personal use.
Having said this, most employers realize that happy employees make better employees, which is why they allow "reasonable" personal use during working hours.
At the same time, however, they need to monitor personal use to make sure this privilige
is not being abused.
In reality, there is nobody fighting for Linux.
There is no marketing organization, no sales campaign, etc.
There is "just" a lot of techies who are trying to make Linux a great OS, and/or creating great applications that run on Linux (and Windows, usually).
The closest we come to having somebody fight for Linux is IBM.
But let's face it,
if IBM found another way to make more money than Linux (or do more damage to competitors),
there's a good chance they would go that route
and drop Linux.
So, in many ways, the strength of OSS is also its weakness.
There is no central control,
and there is certainly no market-driven pressure.
A lot of time is spent making something "better"
(where better is often defined as more like I want instead of more like you want)
rather than adding the additional features that
are needed to make something commercially viable.
We have all read articles about what it takes to make Linux more palatable for mainstream users.
Many have been on that list for ages,
with little or no sign of a concerted push to address those issues.
Now, I'm not saying any of this is bad.
What I'm trying to point out is that,
if there is a battle,
only one side is actually fighting.
The OSS side - for the most part - are simply doing the stuff they love,
and if somebody else can use it,
that's great!
But if they are the only person who likes what they create,
that's OK.
I must admit that Microsoft's comment about
OSS being a threat to all commercial software developers was way off the mark.
I would be surprised if anyone in the free software world is actually trying to put Microsoft (or anyone else) out of business.
Tweak their noses, sure, but put them out of business? Probably not.;^)
Re:Change one thing at a time
on
Debugging
·
· Score: 5, Interesting
It is nice to see a book that addresses this topic.
I get very frustrated with so many text books
that have at most a small chapter on debugging.
Let's face it, beginning programmers spend more time debugging code than they do writing code,
so why isn't that activity stressed?
I particularly liked the rule about "Quit thinking and look".
I worked with a guy who used what I call the "Zen method of debugging".
He would keep staring at the code, trying to determine what was going on.
I, on the other hand, would throw in some print statements so I could see what was going on.
In one case, he insisted there was nothing wrong with the code, but what he didn't realize was that
an early test failed, which meant the code he was looking at never got executed.
I had suggested he print something out at the start of the routine, but he insisted it wasn't necessary because he knew what it was doing.
He might cover this in the book, but one rule that I stress with my students is, if you make a change and the behavior of the program is the same, back out your changes because either:
You are probably looking in the wrong place
(which is why the behavior is the same)
You could easily have just inserted several new bugs that you won't see until the path you are looking at gets executed.
I often have students insist that their changes should have fixed something, but it turns out the program was actually executing an alternative path that they weren't looking at, or that the problem was much earlier, so when it got to where they thought the problem was, the data was different than they assumed.
True, it isn't government's job to make sure every media player is available on the desktop, but it is government's responsibility to prevent a monopoly from putting competitors out of business.
Consider M$ as something like a cable company. They provide the platform which their customers can use to get whatever they want. Since most cable companies can't produce enough product to fill all the bandwidth, they resell content from other sources. That way, everybody wins. (Some more than others, but at least they stay in business)
I think it would be interesting if M$ were required to provide some number of competitor's products in each category. They could lease products from other vendors and provide them on the Windows platform. This would be similar to how the Bell companies had to provide equal access to their competitors. I would hope there was also some way to prevent M$ from building their own version of the software and put the original companies out of business. At least if they were required to provide the top "N" versions, they could only put the weakest companies out of business.
I also don't think making Windows configurable would be much of a help. Most user's don't configure their machines, they just run with whatever comes out of the box.
Of course, the optimum solution is to define what exactly is an operating system, and require Microsoft to provide that as a single unit. That was the original argument from the browser wars. If Microsoft is allowed to define what should go into "core windows", it will continue to grow and eventually put most other companies out of business.
To be fair, the 'weaker sex' comment isn't from the article, but from the/. blurb. In fact, the article uses the term "powerful women".
The article does, however, mention male ego after having seen a woman use the system.
Re:Your job shouldn't be your life.
on
Dream Jobs of 2004
·
· Score: 5, Interesting
I once read that you should make a career out of your second favorite thing to do. That way, when work got to you, you could relax with your hobby rather than your career.
That said, I think far too many people keep thinking of better things rather than enjoying what they are doing at the moment. If somebody gives me something to do that I don't like, I try to figure out how to make it more enjoyable.
For example, I once had a boss that insisted that I send him a status report each week. (I hate paper work). So, I did what I often do in situations like that... I automated it. I segmented the status report into different sections, created text files for each section, and then wrote some code, along with a Makefile, so that each Friday, I ran a single command, and out came my status report e-mailed to my boss along with other interested parties.
Now, I could have spent time bellyaching about what a lousy job I had been given, but instead decided to make it more tolerable. After it was done, I actually enjoyed submitting status reports.
Now, certainly there are jobs with little or no redeeming value, but most of the people I hear complaining actually have it pretty good. Most have food to eat, a place to stay, and make enough money to make ends meet with a little left over.
Blaise Pascal, in his book Pensees, states that people spend too much of their time regretting the past and dreaming about the future, that they don't have time to enjoy the present. As a result, they are often unhappy when they don't need to be.
Starting comp sci students off with assembly isn't a new idea. My first computer course in the 1960's was FORTRAN, but it started out teaching a simplified assembler language. It helped us understand what the computer needed to work, so when we started writing "high level" FORTRAN programs, we had a clue as to what was going on behind the scenes.
One of the courses I teach is Programming Language Concepts, where I show students a quick intro to assembly, and then show how structured programming language constructs are implemented in assembler.
I looked at a text book a few years ago that taught the bits and bytes along with assembler language within an intro to programming course, so even you young'uns can remember back when this was done.;^)
If people don't follow instructions, is it their fault or the fault of the instructions?
If you have a lousy user interface, you can't sit back and blame it on the user because they can't figure out how you want them to use the system.
Furthermore, a well designed system will alert the user to possible problems. If the system doesn't make it clear that they are previewing their vote instead of actually voting, it seems to me that's the fault of the system more than the fault of the user.
Not only would a paper receipt help track errors, it would also provide a clear confirmation to the voter. If they get a piece of paper that says "no vote" they could go back and try again.
Some people don't vote for all positions. They might vote for the candidates they care about, and leave the other positions blank. That doesn't mean they didn't vote correctly, nor does it mean they didn't follow instructions. But, unless you have a paper trail that the voter can confirm the vote they wanted to cast was counted, and a post mortem can validate an election, you have a poor system.
I've been teaching a class like this for several years, and haven't found a book I really like. (Well, I did once, used it for one semester, and then it went out of print.:-(
I agree with your comment that intro text books tend to deal too much with syntax, and not explain how to use the syntax they learned.
What I have found, however, is it takes a good balance between concepts and practice. Particularly when dealing with people with no programming background, too much theory is just as bad as too much practice.
Another interesting thing I have found is that the class is divided into two groups: those that can learn C easily and finds VB confusing, and those can learn Visual Basic, but can't get C. As a result, I let the students pick whatever language they want to learn with, and show examples in both languages.
What I usually do is discuss some structured programming concept and discuss it abstractly (e.g., if-then-else, while-do, etc.) I then give some generic examples using pseudo-code to show how such a construct would be used. I then show example programs in both C and VB.
Once they have learned that construct, we work on several programs to demonstrate how you can use this new concept to solve problems.
I have a "getinfo" program (prompt the user for info, and then display it) that is written over the length of the semester. Each time we learn a new concept, we see how it can be used to improve the "getinfo" program. This helps them see how all these new ideas fit into the big picture.
Early in the semester, I give them time during class to try to write simple programs. If they don't get help with their first few programs, they probably won't be able to get very far. As the semester progresses, it is up to them to practice writing programs.
I encourage them to write one program with a group. By working together, they can usually avoid spinning their wheels because somebody in the group comes up with an answer.
In lieu of a text book, I have lots of sample programs that they can download from my web site.
Slashdot Mirror
There are often special items available only for preorders. Granted, sometimes they are dumb (remember the Gold cartridge for Zelda?) but other times they are nice to have, like the special DVD that came with Xenosaga II that consisted of all the FMV clips from the first game. It helped me remember the complicated plot line from the first game, which enhanced my enjoyment of the second game.
When you preorder a game, you help the company estimate the demand that exists. It might even help the store estimate how many additional games they should order. It would be great if there was a special pre-order price, which would help encourage people to order in advance.
As for paying a couple bucks more for a game from a small store, it is worth it to me. I can ask the people there about games, and they often will tell me about new games coming out that I hadn't heard about. Try asking any question to somebody at BB, WM, etc. About all they know is if it appears in their inventory.
I'm not sure I agree with your examples, but I agree that it is a sign that Open Source is growing up. The article also mentioned how Open Source has transitioned from a few volunteer hackers to corporate backed programmers. GNU went through the same transformation, so again I view this as a good thing.
The only concern is how much influence corporate needs drive open source rather than individual desires. However, I think in the end the coporate influence can help solidify Open Source due to the pragmatic nature of most corporations. I would rather have one fairly standard tool (e.g., Open Office) that works pretty well, is quite common, etc. rather than a wide variety of tools that all do pretty much the same thing. Rather than building on the shoulders of those who came before, programmers tend to stand on their toes. ;^)
A good example of the problem I hope this will solve is the age old /. question: "Which Unix Distro do you recommend?" I'm guessing there are a lot of people who haven't tried Linux simply because it is too confusing taking that first step of getting a "Linux".
I have trouble with the idea that "old people" want simple computers to use for simple things.
I think a better way of looking at it is a simple computer for people who aren't comfortable configuring their own computers. And that isn't limited to "old people".
For example, I'm 60, and am still writing computer programs for a living (and teaching it on the side.) Do you really think I'm looking for a simple computer? On the other hand, I am the one that gets a call when my teenage grandkids have problems with their computers.
Many young people might have less fear of computers, but doesn't mean they are better at it. I recall my grandson when he was very little playing with my SNES. Before I knew it, he had cleared all the save areas on a game my wife and I had spent hours on. He wasn't afraid of what he was doing, but he didn't know what he was doing either. There is a big difference. There are a lot of people, from young to old, who simply keep clicking "OK" when installing something, and many of them don't even bother to read the questions.
IMHO, a "simple" PC that doesn't let people install programs is doomed to failure. Either the PC will have tons of programs, which will make it complicated to use, or it won't have everything the user wants. Now, if you can make a computer that is easy to use, and makes it easy to install new programs, then you might have something. But, thinking that you can identify everything the users will want on their computer is wishful thinking.
I live in the Philly suburbs, and when we showed up to vote this morning there was an "extra" person who didn't seem to be official, but checked a computer printout. He didn't find our name, and when we told him that we had been voting there for over 20 years, he kept mumbling "you're not on this list". He went outside to talk to the local sleaze-ball republican politician who is there every year.
The official folks said there was no problem, since we were in the official book (the old-fashioned paper type). I'm wondering how many other Democratic names were "accidentally" lost from the list. I'm also wondering how a first-time voter might react to not being on the list.
True, but my point was: who of the original people involved within Dr. DOS benefitted? It seems that the only folks who benefit are people who have purchased the assets from the original company (possibly after several transfers).
The reality is that Dr. DOS went out of business, closed up shop, and were no longer a competitor of Microsoft. Somebody might have gotten some money out of the deal in the end, but the primary goal was to eliminate competition, which is what happened.
Unfortunately, the courts will probably never be a good place to rein in a monolopy. By the time it works it way through the entire legal process, none of the real competitors are still alive to benefit from any decision.
Within the last year, the Dr. Dos suit got settled. Who benefitted from that? And it is unlikely that Netscape (which exists in name, but not much else) would have gotten much out of this suit if things had gone differently. And as much as I love FireFox, the biggest thing it has going for it is the fact that IE development has stagnated for some time.
When it comes to technology, things change so fast that any delay in settling any issues means that whatever decision is finally made, it will probably be pretty much meaningless. Inertia is a powerful force, and most people don't bother to download updates to their OS, let alone download and install alternative replacements for something that already came on their box.
I found reading this article quite fascinating. I'm one of those old-timers who remembers what Brooks was writing about. I've read that book several times, and still recommend it to people who want to understand software project management.
But what was most fascinating was the author's impressions of the book. He certainly pointed out artifacts that I had glossed over (they seemed normal to me). However, I was also surprised at how he interpreted what Brooks said much different than I had.
For example, the above quote was in reaction to the statement:
What I think Brooks was saying (or at least what I read from his statement) was that to add a new feature that behaved significantly different than the rest of the system is a bad idea, even if the new feature is very useful. I don't have the book with me, but I'm guessing it was in the chapter where he talked about the beauty of a cathedral came from the fact that each builder followed the original plan.
(During the middle ages, it took so long to build massive church buildings that the construction spanned the lifetimes of several builders. In many cases, each new builder had a "better idea", and so their part of the building looked different than the rest. The result was a patchwork architure that didn't look anywhere near as nice if any one of the individuals builders had been able to build the entire structure.)
I don't think Brooks was saying to ignore the needs of the users, but rather to make sure your changes fit into the overall structure of the program. If different parts of the system work differently, it will most likely lead to user confusion. That is why changes should fit within the framework of the original program. Imagine a system where the author of each component was able to create their own user interface. When you select option 'A', you do it this way, but when you are using option 'B', you have to do it that way. The end result is a confusing mess, even though each individual component might have a perfectly reasonable way of doing things. Its just that most people expect a system to have some consistency in its behavior, appearance, and interfaces.
Speaking of ignoring users, however, I recall reading an article where Kernighan claimed you should ignore all suggestions when a system is first released. The reason is that most people are reacting to the fact that they are trying to use the system differently than it was originally intended. Often, they are expecting the new system to do something in the same way as some other system they used. Once they get used to working with the system, they are able to anticipate how the system wants them to do something, and they become happier and more productive.
If you rush to implement many of the initial suggestions, you will often start changing the overall architecture and/or interface of the system, which is what Brooks (IMHO) is warning against.
Good point.
I would think that even non-techies should realize this. Anyone who has looked at the "suggested corrections" in MS-Word should realize that sometimes that program has no idea what you are trying to say, and its "corrections" actually make it worse, not better.
I would hate to see Sun quietly close up shop and go home. Just like I hated to see DEC get sucked into Compaq.
Like it or not, when Sun started, it had a bold new image of computing that turned out pretty accurate. Much of what they championed are now considered the norm. (The network is the computer).
When Sun started, most of us were using dumb terminals connected to a mainframe. I recall a VP that kept turning down my requests for Sun workstations because he thought programmers just liked them because they were "cool". Then one day, he saw a programmer checking boards from several different locations, and displaying debugging information at one terminal. I never got any resistance for more Suns from him after that. He became a convert.
If you compare J2EE with .Net,
it seems pretty clear to me which one is the
better environment.
Now, if only Sun could figure out how to make
money from J2EE. ;^)
Much of the problem with Sun (IMHO) is in the management of the company. Much of the rest of the problem is Sun's reluctance to adapt to the times. (In part, because of the former problem.)
A lot of large government projects use Sun workstations, and many of them don't have the same pressure as others to come up with a cheaper solution. If lives depend on a system, the fact that you can get something "almost as good" for less money doesn't have the same impact as, for example, a payroll system. Because of that, Sun should be able to maintain a decent revenue stream, provided they don't end up losing more money than they take in.
I would hope that Sun could come up with some good managment that understands the technology and how it can be used, and how best to capitalize on their strengths. In other words, not just the bean counter mentality that so often floats to the top of the corporate ladder.
Technically, if you are at work and being paid, you shouldn't be doing anything personal. They're paying for you to be there, and they can demand / expect you to do what you are being paid for, not personal stuff. In fact, if you spend too much time doing personal things, they have the right to discipline, or even dismiss you.
Most companies I've worked for have a clause about "reasonable" personal business during work hours. It is okay to get a few calls from family or friends, but if you spend too much time, they have the right to tell you to curtail personal business. It is personally reasonable for an employer to expect you to be engaged in whatever activity they are paying you for while you are "on the clock"
Similarly, they are free to open your desk when you are not around. After all, the desk is theirs, not yours. (There was a court case about this several years ago, and the employee lost.)
Employers have the right to control what you do with the computers and phones they provide for you to do the work they are paying you for. You have no right to expect that you can use their equipment, bandwidth, office supplies, etc. for personal use.
Having said this, most employers realize that happy employees make better employees, which is why they allow "reasonable" personal use during working hours. At the same time, however, they need to monitor personal use to make sure this privilige is not being abused.
I have trouble with the term "battle".
;^)
In reality, there is nobody fighting for Linux. There is no marketing organization, no sales campaign, etc. There is "just" a lot of techies who are trying to make Linux a great OS, and/or creating great applications that run on Linux (and Windows, usually).
The closest we come to having somebody fight for Linux is IBM. But let's face it, if IBM found another way to make more money than Linux (or do more damage to competitors), there's a good chance they would go that route and drop Linux.
So, in many ways, the strength of OSS is also its weakness. There is no central control, and there is certainly no market-driven pressure. A lot of time is spent making something "better" (where better is often defined as more like I want instead of more like you want) rather than adding the additional features that are needed to make something commercially viable.
We have all read articles about what it takes to make Linux more palatable for mainstream users. Many have been on that list for ages, with little or no sign of a concerted push to address those issues.
Now, I'm not saying any of this is bad. What I'm trying to point out is that, if there is a battle, only one side is actually fighting. The OSS side - for the most part - are simply doing the stuff they love, and if somebody else can use it, that's great! But if they are the only person who likes what they create, that's OK.
I must admit that Microsoft's comment about OSS being a threat to all commercial software developers was way off the mark. I would be surprised if anyone in the free software world is actually trying to put Microsoft (or anyone else) out of business. Tweak their noses, sure, but put them out of business? Probably not.
It is nice to see a book that addresses this topic. I get very frustrated with so many text books that have at most a small chapter on debugging. Let's face it, beginning programmers spend more time debugging code than they do writing code, so why isn't that activity stressed?
I particularly liked the rule about "Quit thinking and look". I worked with a guy who used what I call the "Zen method of debugging". He would keep staring at the code, trying to determine what was going on. I, on the other hand, would throw in some print statements so I could see what was going on. In one case, he insisted there was nothing wrong with the code, but what he didn't realize was that an early test failed, which meant the code he was looking at never got executed. I had suggested he print something out at the start of the routine, but he insisted it wasn't necessary because he knew what it was doing.
He might cover this in the book, but one rule that I stress with my students is, if you make a change and the behavior of the program is the same, back out your changes because either:
I often have students insist that their changes should have fixed something, but it turns out the program was actually executing an alternative path that they weren't looking at, or that the problem was much earlier, so when it got to where they thought the problem was, the data was different than they assumed.
True, it isn't government's job to make sure every media player is available on the desktop, but it is government's responsibility to prevent a monopoly from putting competitors out of business.
Consider M$ as something like a cable company. They provide the platform which their customers can use to get whatever they want. Since most cable companies can't produce enough product to fill all the bandwidth, they resell content from other sources. That way, everybody wins. (Some more than others, but at least they stay in business)
I think it would be interesting if M$ were required to provide some number of competitor's products in each category. They could lease products from other vendors and provide them on the Windows platform. This would be similar to how the Bell companies had to provide equal access to their competitors. I would hope there was also some way to prevent M$ from building their own version of the software and put the original companies out of business. At least if they were required to provide the top "N" versions, they could only put the weakest companies out of business.
I also don't think making Windows configurable would be much of a help. Most user's don't configure their machines, they just run with whatever comes out of the box.
Of course, the optimum solution is to define what exactly is an operating system, and require Microsoft to provide that as a single unit. That was the original argument from the browser wars. If Microsoft is allowed to define what should go into "core windows", it will continue to grow and eventually put most other companies out of business.
To be fair, the 'weaker sex' comment isn't from the article, but from the /. blurb. In fact, the article uses the term "powerful women".
The article does, however, mention male ego after having seen a woman use the system.
I once read that you should make a career out of your second favorite thing to do. That way, when work got to you, you could relax with your hobby rather than your career.
... I automated it. I segmented the status report into different sections, created text files for each section, and then wrote some code, along with a Makefile, so that each Friday, I ran a single command, and out came my status report e-mailed to my boss along with other interested parties.
That said, I think far too many people keep thinking of better things rather than enjoying what they are doing at the moment. If somebody gives me something to do that I don't like, I try to figure out how to make it more enjoyable.
For example, I once had a boss that insisted that I send him a status report each week. (I hate paper work). So, I did what I often do in situations like that
Now, I could have spent time bellyaching about what a lousy job I had been given, but instead decided to make it more tolerable. After it was done, I actually enjoyed submitting status reports.
Now, certainly there are jobs with little or no redeeming value, but most of the people I hear complaining actually have it pretty good. Most have food to eat, a place to stay, and make enough money to make ends meet with a little left over.
Blaise Pascal, in his book Pensees, states that people spend too much of their time regretting the past and dreaming about the future, that they don't have time to enjoy the present. As a result, they are often unhappy when they don't need to be.
Starting comp sci students off with assembly isn't a new idea. My first computer course in the 1960's was FORTRAN, but it started out teaching a simplified assembler language. It helped us understand what the computer needed to work, so when we started writing "high level" FORTRAN programs, we had a clue as to what was going on behind the scenes.
;^)
One of the courses I teach is Programming Language Concepts, where I show students a quick intro to assembly, and then show how structured programming language constructs are implemented in assembler.
I looked at a text book a few years ago that taught the bits and bytes along with assembler language within an intro to programming course, so even you young'uns can remember back when this was done.
If people don't follow instructions, is it their fault or the fault of the instructions?
If you have a lousy user interface, you can't sit back and blame it on the user because they can't figure out how you want them to use the system.
Furthermore, a well designed system will alert the user to possible problems. If the system doesn't make it clear that they are previewing their vote instead of actually voting, it seems to me that's the fault of the system more than the fault of the user.
Not only would a paper receipt help track errors, it would also provide a clear confirmation to the voter. If they get a piece of paper that says "no vote" they could go back and try again.
Some people don't vote for all positions. They might vote for the candidates they care about, and leave the other positions blank. That doesn't mean they didn't vote correctly, nor does it mean they didn't follow instructions. But, unless you have a paper trail that the voter can confirm the vote they wanted to cast was counted, and a post mortem can validate an election, you have a poor system.
I've been teaching a class like this for several years, and haven't found a book I really like. (Well, I did once, used it for one semester, and then it went out of print. :-(
I agree with your comment that intro text books tend to deal too much with syntax, and not explain how to use the syntax they learned.
What I have found, however, is it takes a good balance between concepts and practice. Particularly when dealing with people with no programming background, too much theory is just as bad as too much practice.
Another interesting thing I have found is that the class is divided into two groups: those that can learn C easily and finds VB confusing, and those can learn Visual Basic, but can't get C. As a result, I let the students pick whatever language they want to learn with, and show examples in both languages.
What I usually do is discuss some structured programming concept and discuss it abstractly (e.g., if-then-else, while-do, etc.) I then give some generic examples using pseudo-code to show how such a construct would be used. I then show example programs in both C and VB.
Once they have learned that construct, we work on several programs to demonstrate how you can use this new concept to solve problems. I have a "getinfo" program (prompt the user for info, and then display it) that is written over the length of the semester. Each time we learn a new concept, we see how it can be used to improve the "getinfo" program. This helps them see how all these new ideas fit into the big picture.
Early in the semester, I give them time during class to try to write simple programs. If they don't get help with their first few programs, they probably won't be able to get very far. As the semester progresses, it is up to them to practice writing programs.
I encourage them to write one program with a group. By working together, they can usually avoid spinning their wheels because somebody in the group comes up with an answer.
In lieu of a text book, I have lots of sample programs that they can download from my web site.