Comment Re:*facepalm* (Score 1) 197
*facepalm*
*REDACTEDpalm*
*facepalm*
*REDACTEDpalm*
When scientists say "theory" they mean something different than what most other people think of when they use the word. "Theory" is used in the "I'm pretty sure the thing I'm typing on is a keyboard, but I could be hallucinating and giving my cat, Whiskers, a backrub" sense. It's the best information that humans have, but we are humble enough to permit the idea that there is something unknown about the subject that could, if someday discovered by research, invalidate it.
It's correct to call evolution a scientific theory, people just don't understand why the word "theory" is used here and it gets misused into making evolution look less like "the only game in town."
> Since we're students, though, no one really has the experience to offer major advice or critiques
See how the other students would feel about internal code or design reviews. They may or may not know what it is and they may take it the wrong way or not like the perceived criticism from peers, depends on your relationship with them.
About none of you having much experience -- maybe not, but part of college is wrestling with challenging questions that you don't know the answer to with people who don't know the answers either. If you're working for the college, even better. It may only lead to marginally better code, but hopefully you would all learn from each other. And it would look good on a resume to say you "improved coding standards and helped foster growth among colleagues by proposing and implementing a peer code review system."
Maybe it's too early...
"Speaking of the future of Office, did you ever notice how people use MS-Word to convince people to use Google Docs?"
Could anyone explain what this means, and what the linked-to page is illustrating?
The original poster is correct. Google's original business plan was wildly different from auctioned search terms. Believe it or not, it was... well, you can do your own research
From what I remember of reading "Googled" by Ken Auletta when it came out, Larry and Sergey didn't have a business plan initially, even after getting venture funding for Google. They tried to make the best search engine they could and assumed money would somehow follow if they developed a great product. After a couple years, I believe the first idea they had was farming out their search services to places like Yahoo -- which iirc was their first deal. When that didn't keep the VCs happy, they gradually became more advertising oriented and never looked back.
So I don't think they had a plan to make money to start with, which is why I initially took issue with the original post when I read it. But I suppose it's fair to say that their original plan was selling search services to other search providers. Is this what you are referring to? (Am I misremembering part of Google's history?)
Very good. For anyone else that wanted to find the source of this, this website: http://www.skypoint.com/members/camilian/humor/SantaAnalysis.shtml claims:
"This was sent via e-mail a couple years ago, circa 1996. Therefore the author's information is unknown."
If someone has more information on the source I'd like to hear it.
A thermostat at a town house the Chamber owns on Capitol Hill at one point was communicating with an Internet address in China
What the fuck is a thermostat doing being accessible from the internet?
I know. Don't they secure these things using NAT?
We used to use usenet. Simple and effective. RIP
We used to use RIP, too. And later, RIPv2. RIP RIP.
What else, as a user, can I possibly do?
Part of what I was saying, for the original asker's question anyway, is that the devs should be working with the ad hoc QA team to help them understand when they haven't given enough information. I understand that the list you gave feels like enough, but for almost any application, the devs will also most likely need the software version and the operating system you were using. For different applications, there may be other things, like a copy of the config file or command line arguments. And any other information, like if it ever worked, or if it never works and you can reproduce it every time on a fresh install (and if there are multiple install methods, tell them which one). That's the kind of feedback they should be giving so you know what they need to fix the problem.
I had an interesting experience in high school when a teacher brought in supplies to make PB&J sandwiches. This seems to be a pretty common lesson: everyone in the class had to write a procedure, and the teacher followed their procedure to try to build the sandwich -- with anything that had to be interpreted being interpreted wrongly. The instruction "open the jar", like "open app", could mean different things to different people. For a dev, opening the app could mean running it from the command line, whereas you might have a desktop link that gets installed by the app's installer (and possibly uses some arguments that the dev won't have put in when running from the command line). Naturally I don't know your software, but the take-away is to be as explicit and unambiguous as possible.
Sometimes that's because the difference between a defect and a feature request is only identified by the requirements document that was never given to QA in the first place. But yeah, it happens sometimes.
You haven't told us anything about what you've done to educate the staff about writing up defects. Have you done anything? Unless they also work as technical QAs, they almost certainly have no idea what is expected in a defect report.
I'm surprised that the primary problem doesn't have to do with listing ambiguous steps to reproduce a defect. For example, "I went to the page again" vs "I clicked the link again" vs "I closed the browser, reopened it, entered the URL, and then clicked the link on the page again."
Of the 3 things you mentioned (#1: screenshots of the YSOD that don't include the page URL, #2: scaled screenshots that are unreadable, #3: the complaint that wants to be a bug report but is still just a complaint), the first two sound like *you* are complaining -- if they're not technical people and they don't know how your system works or what you need to see in order to diagnose a problem, then the first two issues should have been expected.
How do you solve #1 and #2? If you're asking users to perform rudimentary QA, you're going to have to work with them. So, the solution to the first two problems is for you to realize you need to help out in these situations, explain what was wrong and what they can do to fix it next time. They don't know what you need in advance. Progress will be incremental but sure. And if they have to do all this in addition to their other tasks, then be nice while you're doing it.
How do you solve #3? First, if people are complaining then make sure you're not overreacting to a real usability issue and ignoring it because it's not in the format you wanted. Then mail a template with a description field, a steps to reproduce field, an expected results field, and an actual results field, with a description of what each one is. Have a meeting explaining how to use it. Give examples, especially highlighting the need for detailed and unambiguous steps to reproduce.
As bad as e-mail is for tracking issues, if this is a short term thing it may be the best approach. If you can see this going on, getting away from e-mail is a very good idea. Having recently been through a issue tracking system transition, getting everyone used to the new systems took some time even though it was handled very well (and not by me).
Perhaps this has something to do with it?
Spam is UNSOLICITED!
If people signed up for it, then it is not spam.
Spam doesn't have to be unsolicited. Consider the following conversation:
Man: Morning!
Waitress: Morning!
Man: Well, what've you got?
Waitress: Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam; spam bacon sausage and spam; spam egg spam spam bacon and spam; spam sausage spam spam bacon spam tomato and spam;
Vikings: Spam spam spam spam...
Waitress:
Vikings: Spam! Lovely spam! Lovely spam!
Waitress:
The Man made a request for information ("signed up"), yet was undoubtedly spammed. And this by Vikings.
Consider further:
Imagine you receive 5 junk e-mails per day from a site you've never been to. You make a remark to your friend about receiving spam messages. He suggests that you visit the website that is sending you the spam so you can officially sign up for their mailing list. That way, he suggests, it will no longer be spam.
This isn't entirely meant to be humorous... the term "spam" doesn't become inapplicable when someone asks to be spammed.
What about GRE, IP-in-IP/IP6-in-IP, and tunnel mode AH for IPSec? These are all common tunneling mechanisms that do not use encryption, though as you said, they'd have to be supported in the software. I'm prepared to be wrong on this as I don't work with small business equipment, but I would imagine the lowest end boxes that will provide an IPSec VPN will let you do an AH-only tunnel.
Interestingly, some open source IPSec implementations will even allow "encryptionless" ESP tunnels, using "null" ciphers for the ESP encryption. The (old) setkey utility for Linux (and BSD?) allows you to set this, though other utilities will not. Not very useful for anything, but it's another example.
but the consequences of merely possessing one of the interface controllers needed to communicate on the.. er.. somewhat sinister legacy ring bus that Sauron uses are so horrific that security through obscurity has proven more than adequate.
Is that Tolkien Ring?
So you think that money is the root of all evil. Have you ever asked what is the root of money? -- Ayn Rand