The actual bill can be found here: http://www.legislature.state.oh.us/bills.cfm?ID=128_SB_243

From the looks of it, they bill is pretty specific in discussing hybrid embryos, and it specifically allows "(1) Research involving the use of transgenic animal models containing human genes;" and "(2) Xenotransplantation of human organs, tissues, or cells into recipient animals, including animals at any stage of development prior to birth, so long as the xenotransplantation does not violate a prohibition in division (B) of this section;"
Any violation of the law is only a misdemeanor, so its meant more to be symbolic then to prevent any ongoing activity.

While grafting and transgenics are fairly common now, I don't think there have been any official reports yet of anyone trying to create a true human/animal hybrid. The biggest hurdle to true hybrids might be the number of chromosomes - while humans have 46, most other species do not. even gorillas and chimpanzees have 48. Source: http://en.wikipedia.org/wiki/Chromosome#Number_of_chromosomes_in_various_organisms

I didn't say anything about the developer writing tests in English, I'm just saying that you need to be clear in what was changed. If the change could be effectively covered with 100 testcases, but your description of the fix is so vague that QA ends up testing 1000 variations, that's a lot of time that could have been better spent on other projects. At my company, the changes in every development log need to be clearly documented for 3 reasons: 1) Future reference, so if that code isn't touched again for years, people can figure out how its supposed to work without reading the code. 2) So QA knows what to test (if there are no instructions, QA will mark it DOA) and 3) So the documentation team can properly document the changes.

  The QA at your company may simply be grunts, but at some companies (like mine) they are just as much of functionality experts as the developers, often more so. Our testing is done manually (no automated tool we've tried has come close to doing it as well without taking 10 times longer to do). Also, I'm working in HIT, so in some areas bugs really aren't acceptable at any level, even if obscure, if it could result in someone being physically harmed. Our developers do testing as part of their process, and all new development is also receives at least two passes of code review, but plenty of bugs still get through to QA because there are potentially thousands of variations.

  Now the OP didn't state what sort of company he's working at, but depending on the type of software it is, and their internal processes, being on QAs good side can be important.

As a Quality Assurance employee at a software company I can tell you that at least in my experience, they will go to QA to ask which developers are doing good development projects. This isn't based so much on the number of bugs in projects that go to QA (although anything that's DOA or has obvious major issues does reflect negatively), but more importantly, make sure to have good documentation for what to test with, necessary setup steps, and any special variations you know of or spotted in development. If QA comes to you with questions about what they're testing, reply to them within a reasonable amount of time.

      The worst projects that get to me in QA usually have one of the following problems:
1) Come into QA before they're actually ready to go due to an "In QA" deadline. This does depend on company policy but I'd rather have it just stay under development for an extra day or two so it doesn't prevent testing in other related areas if its totally broken.
2) Poor documentation (or sometimes none), or worse, documentation that's completely wrong (ex: it has instructions to test workflow X, but it should actually be workflow Y)
3) Instructions that are too general or vague, like "Test everything in {functional area A}". If it was a general change like a library function change, tell QA the various code paths that will hit that function so they don't waste time on related areas that will never touch your code change.
 

I'd be surprised if Microsoft would be willing to drop any Blu-ray or DVD playback support from the next gen X-Box. Even if games were in a proprietary format, someone would find a workaround.

Dreamcast used a proprietary 1.2 GB Disc format, but piracy was still pretty rampant because the system also read CDs (for music playback). Many games didn't fill the full 1.2 GB so they were easily ported to CD-ROM. Other games were made to fit on CD-Rom by dedicated pirates who would compress video or audio files to fit them on the disc.

The article is lacking detail on the exact actions taken, but he is accusing her of logging into his account and posting as him and changing his password, not just posting things to his wall or comments to his status. If she did use his log-in, then he actually has a case.

I believe she was a Freshman; that's generally not 16 year old territory.

It should be pointed out that Google Health is not an Electronic Medical Record, it is an online Personal Health Record, with patient entered data. It may be handy in some cases, such as if you travel a lot and want a common place to keep your allergies and medications, and some basic information may be able to interface with existing EMR systems on a read only basis, but it is in no way equivalent to an Electronic Medical Record.

So it sounds like they're running on epoch time where Jan 1, 2000 = 1, and the bug forced the time/date value to 0 or null. Ultimately it still sounds like that version of the hardware is trying to treat all even years as leap years and the bug handling code is not very graceful about it.

The problems seemed to specifically affect the PSN system along with the older PS3s (I don't have one so I haven't followed the issue that much). I'm going to guess that the date and time is sent from PSN as a single integer in seconds from an epoch time, likely Unix/POSIX time counting from Jan 1, 1970, which is then used by the hardware to figure out the actual date/time for talking to the network, and not your system entered "local" time.
    The system must have been translating the epoch time it to February 29th, which was probably causing an error in some other date checking code.

What I'd be curious to know is if the affected systems now think its March 1 and not March 2.