So I got on Amazon and read the first few pages of the prequel to the reviewed book, called "The Trousers of Reality" (link below). I found it so disjoint and jargon-ridden that I came here to ask: Am I missing something? I don't want to bash a book I haven't read fully -- maybe it really is a good book -- but try reading the first few pages for yourself. I belong to the author's target audience, and I can follow the words, but I came away from the chapter on "themes and direction" having very little idea what thoughts the author is trying to communicate.
If anyone here has read it, could you comment if the entire book reads like that, and if this sequel is the same?
Thanks for taking questions. Take business travelers who have a laptop with builtin 802.11, and a 4G card for when they are not around an open access point. With switchboard, they would be able to use the 4G network even when they are connected to the 802.11 and observe increased speeds. That sounds like something a lot of people would use.
Do you consider this to be your target market, or something else?
There's a fine line between soliciting public support and encouraging vigilante justice.
Well... the article does seem to make it pretty clear which side of the line they are on...
We considered them to be armed and extremely dangerous. No one should approach them. No one should attempt to apprehend them except law enforcement. Let me reiterate that caution. Do not take any action on your own. If you see these men, contact law enforcement.
Reminds me of Sagan's "atmospheric beasts", the floaters, sinkers and hunters he imagines in the second episode of Cosmos (see around 53:13) -- though TFA is talking about microorganisms on Earth not postulating life on other planets.
Could someone with a knack for photoshop re-color the water in the picture to a nice blue color, with a caption saying both images are photoshopped? The "original" definitely looks photoshopped, but I admit I wasn't looking for it and I didn't notice until someone pointed it out. To see the the same photo with a sparkling blue river would be a great reminder that we have to keep our skepticism active at all times.
There is also research to suggest that ants connect colonies together using Steiner trees, which are related to minimum cost spanning trees. Network engineers are familiar with these since they're used in the protocol of the same name to prevent layer 2 loops. Now we discover they have a TCP-like throttling mechanism. Next we'll decode a colony as HTTP and figure out they're just playing farmville.
Also: Deborah Gordon (one of the authors of the paper) has an enjoyable book on her harvester ant research called "Ants at work: how an insect society is organized". In it, she talks about other forms of ant communication at a colony level and on an ant-to-ant level. This research isn't in the book since the book is older. Recommended if you have an interest in ants and their colonies and don't know where to start. Check your local library.
If you wanted to put structure into a menu, well how about color? Oh wait, I forgot the design department dumped color in favour of the 'everything-is-grey UI.'
How do you determine if this writer was American or English? (Pause) -- That's correct, it's time for a horse race!
If you wanted to put structure into a menu, well how about color?
They're out of the gates, and "American Author" sprints into an early lead!
American: 1 English: 0
Oh wait, I forgot the design department dumped color
Ah, an obstruction in the track! "English Expositor" got its hoof stuck on a sodding large crumpet and is now clomping along alone like a Billy No-Mates! With such a slowdown, it may never catch up, just like the train schedule!
American: 2 English: 0
in favour of the
But wait, "American Author" has smelled the crumpet and is circling back to investigate! It looks like the rider is shouting to "American Author" at the top of his lungs that its going the wrong way, but he refuses to use his riding crop or otherwise take action to correct the problem.
Now "European Expositor" is gaining ground fast! A more in-depth genealogy analysis may very well reveal that Bob is, in fact, his uncle!
American: 2 English: 1
'everything-is-grey UI'
"European Expositor" has shaken off its handicap and they're on the home stretch! They're neck and neck across the finish line -- it's a tie!
American: 2 English: 2
To finish the story, the riders then dismounted and decided to play a tiebreaker match of football. It ended in another tie, one team scoring two touchdowns and the other netting twelve goals.
However, I don't see in any of the three links where twitter made the statement: "We Promise To Not Be a Patent Troll".
It is really not appropriate to use quotation marks when paraphrasing. It's not only unfair to the person you're allegedly quoting, it's also misleading to your readers.
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."
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?)
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).
Slashdot Mirror
So I got on Amazon and read the first few pages of the prequel to the reviewed book, called "The Trousers of Reality" (link below). I found it so disjoint and jargon-ridden that I came here to ask: Am I missing something? I don't want to bash a book I haven't read fully -- maybe it really is a good book -- but try reading the first few pages for yourself. I belong to the author's target audience, and I can follow the words, but I came away from the chapter on "themes and direction" having very little idea what thoughts the author is trying to communicate.
If anyone here has read it, could you comment if the entire book reads like that, and if this sequel is the same?
http://www.amazon.com/The-Trousers-Reality-Volume-Working/dp/190721500X/ref=cm_rdp_product
Thanks for taking questions. Take business travelers who have a laptop with builtin 802.11, and a 4G card for when they are not around an open access point. With switchboard, they would be able to use the 4G network even when they are connected to the 802.11 and observe increased speeds. That sounds like something a lot of people would use.
Do you consider this to be your target market, or something else?
Give me control of a planet's oxygen supply, and I won't care who runs the banks.
Give me control of the Spice and I'll control the universe.
There's a fine line between soliciting public support and encouraging vigilante justice.
Well... the article does seem to make it pretty clear which side of the line they are on...
We considered them to be armed and extremely dangerous. No one should approach them. No one should attempt to apprehend them except law enforcement. Let me reiterate that caution. Do not take any action on your own. If you see these men, contact law enforcement.
Reminds me of Sagan's "atmospheric beasts", the floaters, sinkers and hunters he imagines in the second episode of Cosmos (see around 53:13) -- though TFA is talking about microorganisms on Earth not postulating life on other planets.
https://www.youtube.com/watch?v=ftpVA04_IFc
As a college professor, you have to teach new things to people who already know everything. That does sound really hard to do.
The clack router is a little old but it's a great idea:
http://yuba.stanford.edu/vns/clack/
There might be too much abstraction for someone first starting out, though.
15 Years of Stuff That Matters -- Phew, glad that's over!
Could someone with a knack for photoshop re-color the water in the picture to a nice blue color, with a caption saying both images are photoshopped? The "original" definitely looks photoshopped, but I admit I wasn't looking for it and I didn't notice until someone pointed it out. To see the the same photo with a sparkling blue river would be a great reminder that we have to keep our skepticism active at all times.
There is also research to suggest that ants connect colonies together using Steiner trees, which are related to minimum cost spanning trees. Network engineers are familiar with these since they're used in the protocol of the same name to prevent layer 2 loops. Now we discover they have a TCP-like throttling mechanism. Next we'll decode a colony as HTTP and figure out they're just playing farmville.
Also: Deborah Gordon (one of the authors of the paper) has an enjoyable book on her harvester ant research called "Ants at work: how an insect society is organized". In it, she talks about other forms of ant communication at a colony level and on an ant-to-ant level. This research isn't in the book since the book is older. Recommended if you have an interest in ants and their colonies and don't know where to start. Check your local library.
If you wanted to put structure into a menu, well how about color? Oh wait, I forgot the design department dumped color in favour of the 'everything-is-grey UI.'
How do you determine if this writer was American or English? (Pause) -- That's correct, it's time for a horse race!
If you wanted to put structure into a menu, well how about color?
They're out of the gates, and "American Author" sprints into an early lead!
American: 1
English: 0
Oh wait, I forgot the design department dumped color
Ah, an obstruction in the track! "English Expositor" got its hoof stuck on a sodding large crumpet and is now clomping along alone like a Billy No-Mates! With such a slowdown, it may never catch up, just like the train schedule!
American: 2
English: 0
in favour of the
But wait, "American Author" has smelled the crumpet and is circling back to investigate! It looks like the rider is shouting to "American Author" at the top of his lungs that its going the wrong way, but he refuses to use his riding crop or otherwise take action to correct the problem.
Now "European Expositor" is gaining ground fast! A more in-depth genealogy analysis may very well reveal that Bob is, in fact, his uncle!
American: 2
English: 1
'everything-is-grey UI'
"European Expositor" has shaken off its handicap and they're on the home stretch! They're neck and neck across the finish line -- it's a tie!
American: 2
English: 2
To finish the story, the riders then dismounted and decided to play a tiebreaker match of football. It ended in another tie, one team scoring two touchdowns and the other netting twelve goals.
The title of this piece on Slashdot was:
Twitter: 'We Promise To Not Be a Patent Troll'
However, I don't see in any of the three links where twitter made the statement: "We Promise To Not Be a Patent Troll".
It is really not appropriate to use quotation marks when paraphrasing. It's not only unfair to the person you're allegedly quoting, it's also misleading to your readers.
Enjoying the science fiction references in this thread more than the discussion stemming from the article.
Ah, but the whole Asimov universe was rich in the metal that mattered.
"Dors!"
*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).