Well, today didn't go so well. The arteries in Mrs. Li's brain started to
spasm, which is increasing cutting off the flow of blood to her brain. This
is very bad. Tonight they drilled a hole in the top of her head in order to
allow fluid to drain if this becomes a problem.
I think that if I understood the doctor properly today, at this point she
has roughly a 20% chance of surviving without significant brain damage. It
is a good indication that she arrived at the hospital in good condition, but
the current problems may cancel it out.
I don't know what I can do at this point, but I am hoping hard as I can.
It seems like Mrs. Li is going to be at least mostly okay. She's still a bit
confused, there is still some blood in her brain, but her spinal fluid is
continuing to be re-absorbed, she's not in very much pain, and the doctor
didn't have anything interesting to report today. She did re-gain the use of
the right side of her body today, and she can move her legs, so apparently
she is healing as expected.
The one slightly unsettling thing is that she continues to speak mandarin to me rather than english. Considering that her mental faculties seem otherwise in relatively good condition, I am not sure whether to be honored or concerned.
The one slightly unsettling thing is that she continues to speak mandarin to me rather than english. Considering that her mental faculties seem otherwise in relatively good condition, I am not sure whether to be honored or concerned.
PyCon was excellent. I'm sorry I didn't post a writeup immediately. The Divmod unveiling was low-key but uniformly positive. The face-time gave us a good opportunity to work out some team issues. I got to have several wonderful discussions with Jim Fulton about possible Divmod/Twisted/Zope collaboration and I met with Mitch Kapor.
The week of work in NY that followed was also hugely productive. I didn't quite catch up to where I should be, but got very close.
As some of you have noticed, I've been scarce the last few days.
's mom had an aneurism (technically, she has several aneurisms, but one of them leaked blood into her brain) on Friday night and was immediately rushed to the hospital.
Once there, the next morning, she was treated with a procedure that involved inserting a coil into her brain to block off the blood flow leaking. Counter-intuitively, this was relatively noninvasive, and it did not involve opening up her head. The procedure was successful. However, it appears that some additional blood leaked into her brain - possibly because of the unusually strong reaction of asians to anti-coagulants, which the doctor may not have known about.
Now, she appears to be in relatively stable condition, but she is having some trouble moving the right side of her body, responding slightly slower than normal, and having a little trouble speaking. She also didn't quite recognize who I was today, and spoke to me in chinese. It is reasonable to believe this is all because of the sedatives and anesthetics that she was given for the surgery, and we are hoping that's what it is at this point.
Mrs. Li is at St. Vincent Hospital in Manhattan. I've been fulfilling my boyfriendly duties as chauffer and gopher. Ying's cousin Yang* and his wife have graciously provided us with lodging at their house on Staten Island.
* I'm not making this up, though their names are completely different from the words for "Yin" and "Yang" in chinese.
The week of work in NY that followed was also hugely productive. I didn't quite catch up to where I should be, but got very close.
As some of you have noticed, I've been scarce the last few days.
Once there, the next morning, she was treated with a procedure that involved inserting a coil into her brain to block off the blood flow leaking. Counter-intuitively, this was relatively noninvasive, and it did not involve opening up her head. The procedure was successful. However, it appears that some additional blood leaked into her brain - possibly because of the unusually strong reaction of asians to anti-coagulants, which the doctor may not have known about.
Now, she appears to be in relatively stable condition, but she is having some trouble moving the right side of her body, responding slightly slower than normal, and having a little trouble speaking. She also didn't quite recognize who I was today, and spoke to me in chinese. It is reasonable to believe this is all because of the sedatives and anesthetics that she was given for the surgery, and we are hoping that's what it is at this point.
Mrs. Li is at St. Vincent Hospital in Manhattan. I've been fulfilling my boyfriendly duties as chauffer and gopher. Ying's cousin Yang* and his wife have graciously provided us with lodging at their house on Staten Island.
* I'm not making this up, though their names are completely different from the words for "Yin" and "Yang" in chinese.
The name of the company that makes the ticket tracker we use at divmod
(RT, from Best Practical) inspired me to think
about best practices today. It surprises me that the software industry
doesn't really seem to have a consensus about best practices.
There are lots of people who claim they know the best way to do things, whether it be Extreme Programming, the Rational Unified Process, Pragmatic Programming, or whatever. Every one of these groups will gladly sell you a huge pile of books to tell you how to follow their One True Way. There is a huge amount of vitriol expended discussing which Way is the Truest, and I plead guilty to having spread this disease.
I am pretty sure there is a list of things that everybody who is anywhere near decent at developing software always, always does, or pretty much everyone (themselves included) agrees always absolutely should do. I have a feeling there is widespread agreement on these practices where they are known, and a first stab at this sort of list is the Joel Test. I think that Joel's list is still somewhat opinionated and controversial, so my guess at this list follows. I'm leaving out lots of things that I think are good ideas, in the hope that in the future, I can devote all my vitriol to arguing about ideas not on this list.
It seems like the efforts I've read about in order to measure software quality and team quality are all fantastically complicated, expensive processes that overlook these basic issues. It seems premature to segregate your Prototype and Requirements Specifications phases if your programmers can't even use gdb (or equivalent debugger) or cvs (or equivalent version control system).
Is there something obvious I've missed, or is there some circumstance where one of these rules doesn't apply?
There are lots of people who claim they know the best way to do things, whether it be Extreme Programming, the Rational Unified Process, Pragmatic Programming, or whatever. Every one of these groups will gladly sell you a huge pile of books to tell you how to follow their One True Way. There is a huge amount of vitriol expended discussing which Way is the Truest, and I plead guilty to having spread this disease.
I am pretty sure there is a list of things that everybody who is anywhere near decent at developing software always, always does, or pretty much everyone (themselves included) agrees always absolutely should do. I have a feeling there is widespread agreement on these practices where they are known, and a first stab at this sort of list is the Joel Test. I think that Joel's list is still somewhat opinionated and controversial, so my guess at this list follows. I'm leaving out lots of things that I think are good ideas, in the hope that in the future, I can devote all my vitriol to arguing about ideas not on this list.
- Version Control
All code, and when possible all assets (data related to the code such as artwork, "business rules", scripts, and test databases) should be managed with a version control system, such as CVS, Perforce, Bitkeeper, or Subversion. - Build Automation
It should be possible for any programmer involved with the project to produce a running copy of the software from the source code at any time. It should be possible to produce an official, "release" build of the software in order to distribute it to beta-testers or customers with little more effort.
- Test Automation
There should be a suite of automated tests run against the software after every change. When bugs are discovered, tests should be written to ensure that they do not recur. - Bug Tracker
All defects should be tracked so that they are not lost while the programmers are busy working on other things. - Development Tools
Programmers should be well-versed in the use of debuggers and profilers and should use them regularly when attempting to locate bugs or performance bottlenecks. - Human Testers
There should be a person or a department (depending on project size) responsible for testing the software, entering bugs into the bug tracker, and making sure they get fixed. In the absence of a dedicated tester (on extremely small projects) the programmer or programmers should dedicate a reasonable share of their time to integration testing.
It seems like the efforts I've read about in order to measure software quality and team quality are all fantastically complicated, expensive processes that overlook these basic issues. It seems premature to segregate your Prototype and Requirements Specifications phases if your programmers can't even use gdb (or equivalent debugger) or cvs (or equivalent version control system).
Is there something obvious I've missed, or is there some circumstance where one of these rules doesn't apply?
I just had a look at the PyCon Schedule, and
I'm impressed. It looks like the organizers have done an awesome job yet
again. I plan to attend as many talks as I can this year.