In the days after my mother's death, her page at Legacy.com came up in the top five on google when searching her name. It gathered a number of kind messages in the guest book, mostly from friends that were too far away to make it to her funeral.
Fast forward four months, and try to find that page. Google won't show it to you, at least not in the top fifty. If you search at legacy.com, you will find the obituary now lives behind a $3/day paywall, although you can also see most of the header text (her age, date of death, etc) in the search result, so most people would be fine with that.
The ugly part is the guest book. If you happen to remember the link on Legacy.com (composed of a magic twelve-digit number), you are greeted with a notice telling you the page is offline, but for a donation of $40 (one year) or $90 (perpetual) you can "sponsor" the page.
And the Internet Archive kindly reports that none of these pages are archived because of robots.txt.
Neither he nor me can be blamed of the errors in Amazon's database.
Hey there. No offense intended, but if a mistake was made, then a brief explanation and apology will go a long way towards straightening things out.
The editor took the correct link, and changed it to another link, without checking that the new link was correct. That was a mistake - an honest mistake - but nonetheless a mistake.
Does it hurt anyone to say "Oops. My bad." and take responsibility for the mistake?
I understand that there are those who get Type II through no fault of their own, and this makes me happy for them...But they're the minority, and I don't have as much sympathy for the rest.
Yikes!!!
You're happy for some diabetics, and unsympathetic to the rest?
Although I really, really, really hope you're just trolling, I suspect you honestly feel this way. This kind of opinion (bias, prejudice) seems to run pretty rampant these days, and it's one of the reasons that I rarely feel comfortable telling people I'm diabetic.
I'm reading this one right now, and although it does do a good job of presenting C#, I'm getting quite frustrated by the lack of editorial oversight. For example (page 81)
Binary operators such as + and - are associative because the order in which the operatos are applied is not significant; a+b+c has the same result whether a+b is performed first, or b+c is performed first.
There are many similar examples where the author demonstrates a lack of understanding of the material. That being said, most of the mistakes I've seen deal with unimportant trivia (as illustrated by the quote above), and not with core language details. On those points the author seems to be quite knowledgeable.
Even with all my grumbling, I think the book is worth reading. Just remember to use your own judgement when you're reading.
I feel that Meyer's "Effective C++" was a wonderful book, and should be mandatory reading for anyone developing in C++. So I was thrilled to find that Meyer's had endorsed an "Effective C#", even though he wasn't the author.
Unfortunately, I have to say that I was disappointed by Effective C#. The author often made suggestions without explanations. Like "Always use the CLR's built-in types (Int32, String) instead of the C# language specific types (int, string). No real explanation or justification given. (Come to think of it, I'm not sure if the author wanted you to use the built-ins or the CLR types - since no good justification was given, I just can't remember what the recommendation was.)
There is some good content in the book - just not enough to justify the "Effective" title.
As a long term insulin user, I have to cry BS on the parent.
Surely you're not suggesting that insulin leads to necrosis? All the research that I've seen suggests that poor control of blood glucose is the primary cause of complications such as these. And it's that poor control that leads to insulin use in type 2 diabetics.
As an advocate of privacy, I applaud this document. Software developers have a duty and an obligation to consider the privacy of their users. This document helps to uncover some of the issues surrounding privacy, how to avoid risks to privacy, and how to mitigate those privacy risks that are unavoidable.
It's time for software professionals to start taking responsibility for their work.
Without reading the article (does anyone do that, anyway?) it seems to me that this is simply enabling traceless communication. The goal is to ensure that no third parties keep a record of the communication. The message is read, therefore it does exist at least in the mind of the reader (or their digicam, or various screen-shots.)
At the end of the day, the recipient of the communication can "copy" it, but there will never be an external verification of the message. Unless, of course, they had a reliable third party reading over their shoulder.
This is a great thing for "junkie-dealer", "enron-accountant", or "headhunter-candidate" communications. And who could argue against that kind of user? The "unforwardable" pitch is just snake-oil to make things seem more mysterious.
Or, more to the point, how would one go about trying to effectively and objectively compare competing search engines?
For some time now, Search Engine Watch has provided a good editorial and comparison on various search engines. They focus on marketing topics, but also tend to talk a lot about the underlying technology, etc.
Well, the BBC story only claims that this is the first patient cured in the UK. The article plainly states that the protocol has been used a number of times in Canada. Perhaps the poster should have given a better title to this submission....
And while the Edmonton Protocol is exciting news for diabetics, it's somewhat premature to call this a cure. It requires two harvested pancreases for each transplant, and there were not a huge number of such donations available. I think there was something like 1,000 available in Canada annually, which wouldn't even come close to keeping up with the rate of new diagnoses.
Of course there is room for improving the harvest rate for islet cells, and there's a great potential for bio-engineering them - perhaps with stem cells. So this protocol may eventually be useful for all diabetics - and not just the handful of cases that can currently get treated.
There's also a significant question of the long-term effects of the anti-rejection drugs. Still, I'd be happy to risk it personally, if I'm ever given the chance... after 31 years on insulin, I'd be happy to trade to a new drug;)
Slashdot Mirror
Newspapers are archived. Websites are archived.
If they are archived, I'd like to find it.
In the days after my mother's death, her page at Legacy.com came up in the top five on google when searching her name. It gathered a number of kind messages in the guest book, mostly from friends that were too far away to make it to her funeral.
Fast forward four months, and try to find that page. Google won't show it to you, at least not in the top fifty. If you search at legacy.com, you will find the obituary now lives behind a $3/day paywall, although you can also see most of the header text (her age, date of death, etc) in the search result, so most people would be fine with that.
The ugly part is the guest book. If you happen to remember the link on Legacy.com (composed of a magic twelve-digit number), you are greeted with a notice telling you the page is offline, but for a donation of $40 (one year) or $90 (perpetual) you can "sponsor" the page.
And the Internet Archive kindly reports that none of these pages are archived because of robots.txt.
You could probably ... put 2d barcodes on the bottom of your miniatures
These are called fiducials, and there are many examples of their use.
Neither he nor me can be blamed of the errors in Amazon's database.
Hey there. No offense intended, but if a mistake was made, then a brief explanation and apology will go a long way towards straightening things out.
The editor took the correct link, and changed it to another link, without checking that the new link was correct. That was a mistake - an honest mistake - but nonetheless a mistake.
Does it hurt anyone to say "Oops. My bad." and take responsibility for the mistake?
Yikes!!!
You're happy for some diabetics, and unsympathetic to the rest?
Although I really, really, really hope you're just trolling, I suspect you honestly feel this way. This kind of opinion (bias, prejudice) seems to run pretty rampant these days, and it's one of the reasons that I rarely feel comfortable telling people I'm diabetic.
There are many similar examples where the author demonstrates a lack of understanding of the material. That being said, most of the mistakes I've seen deal with unimportant trivia (as illustrated by the quote above), and not with core language details. On those points the author seems to be quite knowledgeable.
Even with all my grumbling, I think the book is worth reading. Just remember to use your own judgement when you're reading.
I feel that Meyer's "Effective C++" was a wonderful book, and should be mandatory reading for anyone developing in C++. So I was thrilled to find that Meyer's had endorsed an "Effective C#", even though he wasn't the author.
Unfortunately, I have to say that I was disappointed by Effective C#. The author often made suggestions without explanations. Like "Always use the CLR's built-in types (Int32, String) instead of the C# language specific types (int, string). No real explanation or justification given. (Come to think of it, I'm not sure if the author wanted you to use the built-ins or the CLR types - since no good justification was given, I just can't remember what the recommendation was.)
There is some good content in the book - just not enough to justify the "Effective" title.
As a long term insulin user, I have to cry BS on the parent.
Surely you're not suggesting that insulin leads to necrosis? All the research that I've seen suggests that poor control of blood glucose is the primary cause of complications such as these. And it's that poor control that leads to insulin use in type 2 diabetics.
Remember to distinguish cause and effect!
As an advocate of privacy, I applaud this document. Software developers have a duty and an obligation to consider the privacy of their users. This document helps to uncover some of the issues surrounding privacy, how to avoid risks to privacy, and how to mitigate those privacy risks that are unavoidable.
It's time for software professionals to start taking responsibility for their work.
At the end of the day, the recipient of the communication can "copy" it, but there will never be an external verification of the message. Unless, of course, they had a reliable third party reading over their shoulder.
This is a great thing for "junkie-dealer", "enron-accountant", or "headhunter-candidate" communications. And who could argue against that kind of user? The "unforwardable" pitch is just snake-oil to make things seem more mysterious.
For some time now, Search Engine Watch has provided a good editorial and comparison on various search engines. They focus on marketing topics, but also tend to talk a lot about the underlying technology, etc.
A recent roundup of engines is at http://searchenginewatch.com/links/article.php/215 6221.
And while the Edmonton Protocol is exciting news for diabetics, it's somewhat premature to call this a cure. It requires two harvested pancreases for each transplant, and there were not a huge number of such donations available. I think there was something like 1,000 available in Canada annually, which wouldn't even come close to keeping up with the rate of new diagnoses.
Of course there is room for improving the harvest rate for islet cells, and there's a great potential for bio-engineering them - perhaps with stem cells. So this protocol may eventually be useful for all diabetics - and not just the handful of cases that can currently get treated.
There's also a significant question of the long-term effects of the anti-rejection drugs. Still, I'd be happy to risk it personally, if I'm ever given the chance... after 31 years on insulin, I'd be happy to trade to a new drug;)
[Oh, and here are some clickable links that the parent post tried to submit: http://www.diabetes.org.uk/islets/trans/edmonton.h tm
and http://www.ahfmr.ab.ca/publications/newsletter/Sum mer00/sum00/inside/diabetes.feat.htm]