The article is slightly wrong. There are plenty of devices that are ingestible (able to be swallowed) but non-digestible (unable to be broken down into smaller parts). Several companies make capsules that take pictures, measure pH, transit time, etc. and are FDA-cleared. This is probably the first one that is electrically powered that is also digestible.
Maybe carry a lot of your stuff on you or hidden. Like these clothes with multitudes of pockets. http://www.scottevest.com/
I agree with this, wish I had mod points. We used it heavily in my Master's program in software engineering. You can get feedback on your code in 2 ways - 1) functional improvements, such as faster algorithms or more efficient memory usage, or 2) code hygiene improvements, such as meaningful comments, plugging memory leaks. Option 2 is way more useful in the long run - it applies to all code you write, unlike option 1 that may only apply to a particular domain or OS or application. Also good code hygiene helps avoid many of the bugs that the compiler will never catch - timing errors and race conditions, one-off/fencepost errors, and stuff that generally doesn't appear in testing unless you've run your program for 25 days straight and it then mysteriously crashes.
It is a bit strange, working through the problems in the book because they are so simple, but really the output of the exercises is a checklist of your own personal improvement points.
You should try reading the Liveship Traders trilogy or the Soldier Son trilogy, both by Robin Hobb. Her characters are so realistic, I felt like I was at a dysfunctional dinner with my family. More annoying and unlikeable than Thomas Covenant by a long shot. (However the plots and the books were quite the page-turners. I'm just talking about the likeability of the protagonist.)
It is very, very difficult to become a pharma company. The startup costs are huge, even if you are not spending any money on R&D of new drugs. The business must first register with the FDA, they have to have all sorts of strict quality controls in place, then the drugs must be tested for efficacy and safety and the results approved by the FDA. I work for a small medical device company and it's going to be awhile before we become profitable and the regulations and requirements for drug manufacturers are very similar.
I heard on the Rush Limbaugh show that it'll be good when we learn what dolphins know until they leak the location of Osama bin Laden's grave.
A few years ago, my parents were shopping around for burial options. My mother wishes to be cremated and my father does not. Being frugal, my mother wanted to know if they could just buy one plot since the cremation urn doesn't take up a lot of space. The funeral planner had to check on the regulations of how many people could be buried in a single plot, and finally said that it would be possible.
I said to my father "Dad, do you realize that Mom is going to be all over your back for all of eternity?!"
The law only lists the What, it does not explicitly tell you How to implement the regulation. Kind of like the difference between a requirements spec and a design spec. The FDA also does not require you to be compliant to ISO 80001, but they will recognize your compliance certificate as a way to easily prove you are meeting the regulation. Otherwise the FDA will have to do a lot of painful digging around in your files (sans rubber gloves and lubricant) to get the proof they're after.
I find it ironic that saccharin is an artificial sweetener but reacts with bitter-sensing cells. I always knew saccharin had a weird after-taste.
I'll dupe my reply to this dupe, but only because I have a clue of what I'm talking about.
I work for a medical device manufacturer. We don't make a life-essential device, but all the laws apply to us as well as the manufacturers that make critical devices. The FDA already has the power to examine a manufacturer's source code. When they come in to perform an inspection, the inspectors have the same powers as federal marshals. They can look at anything - just time and resources are the limiting factors. When a device is submitted for FDA clearance, there is a lot of software documentation that has to be included in the application. Our software section is one of the thicker sections in an application. Depending on the level of concern of the device, a manufacturer has to submit all test results, software detailed design, etc. The stuff we have to do during development here is incredible and we're a minor level of concern.
Regulation requires that all designs be periodically, formally reviewed. It requires that the review includes an independent reviewer and that reviewers are just as (if not more) technically competent than the designer. The FDA may not have the resources to review every line of code, but they do have the resources to look at the documentation from the reviews and to look at the documentation listing the qualifications of the reviewers.
Manufacturers are required to conduct risk assessments for their devices and identify any/all reasonably foreseeable hazards and to mitigate those hazards until they are as low as reasonably practicable or the clinical benefit to the patient outweighs the risk. The risk assessment must be conducted by clinical and technical experts. Each mitigation (or fix or change to a line of code) has to be re-evaluated for risk and possible repercussions to the rest of the device. Testing is also quite rigorous and safety and reliability are the top priorities. Our testing takes months. Changes that affect safety may have to be tested in expensive clinical trials on human subjects and the results resubmitted to the FDA for clearance.
Perhaps by having the public look at source code there will be some bugs found. But I'm sure that the bug has already been considered as part of the manufacturer's risk assessment, and any fixes for that bug will not be fast in coming considering the heavyweight nature of the development process.
I work for a medical device manufacturer. We don't make a life-essential device, but all the laws apply to us as well as the manufacturers that make critical devices. The FDA already has the power to examine a manufacturer's source code. When they come in to perform an inspection, the inspectors have the same powers as federal marshals. They can look at anything - just time and resources are the limiting factors. When a device is submitted for FDA clearance, there is a lot of software documentation that has to be included in the application. Our software section is one of the thicker sections in an application. Depending on the level of concern of the device, a manufacturer has to submit all test results, software detailed design, etc. The stuff we have to do during development here is incredible and we're a minor level of concern.
Regulation requires that all designs be periodically, formally reviewed. It requires that the review includes an independent reviewer and that reviewers are just as (if not more) technically competent than the designer. The FDA may not have the resources to review every line of code, but they do have the resources to look at the documentation from the reviews and to look at the documentation listing the qualifications of the reviewers.
Manufacturers are required to conduct risk assessments for their devices and identify any/all reasonably foreseeable hazards and to mitigate those hazards until they are as low as reasonably practicable or the clinical benefit to the patient outweighs the risk. The risk assessment must be conducted by clinical and technical experts. Each mitigation (or fix or change to a line of code) has to be re-evaluated for risk and possible repercussions to the rest of the device. Testing is also quite rigorous and safety and reliability are the top priorities. Our testing takes months. Changes that affect safety may have to be tested in expensive clinical trials on human subjects and the results resubmitted to the FDA for clearance.
Perhaps by having the public look at source code there will be some bugs found. But I'm sure that the bug has already been considered as part of the manufacturer's risk assessment, and any fixes for that bug will not be fast in coming considering the heavyweight nature of the development process.
Last year's Blizzcon was tremendously popular. So much so that their servers were unable to handle the strain of fans competing for 15,000 available tickets. This year, Blizzard was more prepared; they made an additional 5,000 tickets available and set up a queue so that the transaction servers weren't overwhelmed. CEO Mike Morhaime said during the keynote address that if you weren't able to get into the queue within 30 seconds of its opening, the tickets were sold out before your turn came. Tens of thousands more chose to order the pay-per-view coverage, demonstrating the extraordinary enthusiasm felt for Blizzard's games. Their presentations didn't disappoint. Read on for details on the status of StarCraft II, Diablo III, World of Warcraft: Cataclysm, and the new Battle.net. It's divided into sections by game in case you're only interested in one or two of them.
A computer scientist is someone who fixes things that aren't broken.
