A collection of articles, ideas, and rambling from a guy who wrote some software that one time.
Sunday, November 30, 2003
Despite being several hours' journey from my lady now, I find I'm glad to be back. Sleeping in my brother's room was no fun. I hope that within a few days I will start to find a normal rhythm again.
According to the plan, Ying is returning on Jan. 2. I'm counting down the days.
(Now, back to your regularly scheduled programming.)
Saturday, November 29, 2003
Thank you so much to everyone who has offered to help Ying and her family in some way. There isn't much to be done now. However, her mother is still moving to New Jersey later this year. I would like to organize a small crowd of people and cars in the NY metropolitan area to help move their stuff, probably sometime after march.
This week my plan is to get my apartment in order. I will unpack some boxes, build some furniture, pay all my bills and tidy up. Then I'm back to NY for a day (or less) to drop off some clothing for Ying for the rest of her stay here. Once back in MA I plan to work for a few weeks, and then return to pick up Ying in early January. After a brief "vacation" to get her settled in (and to wash off some of the darker stains that the previous month has left on our respective souls), life should return to something like "normal".
Normal never sounded so good.
Wednesday, November 26, 2003
On Monday, his liver and kidneys began to fail. I had to rush out of work to pick Ying up so that she could go somewhere to cry for a while. She can't cry at home, because that would send her mother into an emotional tailspin from which she might not recover.
She cried for four hours. The whole time I've known her, Ying has maybe cried for 30 minutes in my presence, up until this point. I've never seen her so upset.
On Tuesday, since nobody in her family was in a state to drive into the city, and they needed to be there, I volunteered my services as a driver. It's the least I could do.
Although he was technically still alive (and still is, to the best of my knowledge) the prognosis was sufficiently bad that we left in the middle of the day to go procure the services of a funeral home. Also, to pick up a picture for the memorial service, which saph is graciously re-sizing to be a decent size.
At this point I gave up on getting any work done this week (and possibly next) and just took off.
Ying cried for another few hours that night.
Wednesday, today, I drove them into the city again. Mrs. Li has already given the "do not resuscitate" order, but Mr. Li is still on a respirator and a blood-pressure medication which is keeping his heart pumping and his lungs working. He's been sedated for a while, so he's hopefully not aware of the pain.
Today they're going to discontinue the medication. It is likely that he will die within a few hours of that.
The worst part of the whole medical situation is that, as I understand it, there's nothing wrong with him except he's going to die. The leukemia was actually successfully treated. The infections are starting to recede. However, in the process of the treatment his organs were so badly damaged that they're simply not functioning any more, and there's no way to treat that.
Of course, the personal angle is no better. Ying's mother has nobody - and I mean nobody - in the area to help her. Ying suspects she may have one friend, but all the family that's here right now has travelled in from far away (and mostly different "far away", so there's not even somewhere she should move). Ying and I are in boston. Apparently the church that Mr. Li belonged to did nothing but send over some people to pray for him.
I don't even know what's happening in my own family any more; I haven't had time to spend 2 hours in a row in the house since monday. When I haven't been driving the Lis around in the city, I've been talking to my friend Mark about this in diners, trying to vent enough that I can be Ying's support.
There's more to say but I don't have the energy for more. I just hope that Ying can be happy again, after this.
Friday, November 21, 2003
- Native integration (such as drag'n'drop from a file manager, copy-paste of pictures from other applications, opening of local files)
- Keyboard Shortcuts
Beyond those requirements, it seems like a web browser can do almost anything required for any kind of text-mashing or abstract, logical application. There are apps like word processors which live or die based on performance of particular functions like turning fonts into pixels, but almost any communications-based application won't need to do something like that.
Monday, November 17, 2003
The good news, though, is that the last release of Quotient was released with literally days to spare! Despite lots of features that didn't make it in (mostly my fault), I'm proud of the whole team for making that happen.
Wednesday, November 12, 2003
Apparently, Bertrand Meyer says
direct assignment of object fields, completely messes up the architecture. So it's a small problem that becomes a huge one.
The problem is small in the sense that fixing it is very easy in the source. You just prohibit, as in Eiffel, any direct access to fields and require that these things be encapsulated in simple procedures that perform the job-procedures which, of course, may then have contracts. So it's really a problem that is quite easy to kill in the bud.
I think that this passage points out an ironic flaw in the way programmers - in particular language and framework designers - perceive programming. The general form of this thinking is: we have problem X, which is indicated (let's say) by the proliferation of direct attribute assignments. So we say, okay, we know how to handle these kinds of problems in code: we just declare that the symptom (direct attribute access) is illegal, it's an error condition, and so another component of the software-generation system (the programmer) will react to this event properly and stop creating the problem X.
This is consistent with the way that software is written: if we have a problem X, which is indicated by a buffer overrun - well, it's too difficult to specify all the myriad ways that problem X might actually manifest - so we fix the indication, and we prevent it from manifesting. We don't sit down and classify every bizarre way that a buffer overrun could affect a running program: there are too many different things that could happen, it's arguably not even possible to specify what problem X might be when it manifests, so we fix the rules so that the variety of problem is impossible.
I think that this may be why Guido van Rossum is such a genius - his perception is largely untainted by this misconception.
The misconception is that you can change a programmer's behavior in the same way you can change a program's behavior. In the case of the programmer, you need to look deeper. You need to look at X and figure out what it actually is. In some cases, direct attribute access is actually not a problem at all - it can cause problems, but it doesn't necessarily. In the cases where it does cause problems, what's really going on? The programmer isn't developing a sufficiently strong encapsulation "contract" between the class and its customers. So we want to encourage the programmer to really think about that because that issue becomes more important as the problem scales up.
In this case, it turns out that while it sounds like a reasonable request to make of the programmer - devote more time to abstract design so that the interfaces will be cleaner and we can manage the project as it scales - it might not actually be possible. The programmer needs to see a working prototype of their system in order to judge how it's going to work in the end, and in order to do that they are going to need to make some sub-optimal choices about the initial abstractions they employ. They won't know which code is simply an implementation detail and which code is really externally published until they find themselves saying "Hey, I just wrote something like N yesterday, and this O looks a lot like an N, why don't I try to use that code I wrote before."
Here's where it starts to bump into a problem I've been thinking about a lot lately. I've been looking at the schedule I set out for myself towards the beginning of last week. A lot of things have happened and a lot of work has gotten done, but almost none of it has gone as planned. We've all been trying to talk about the schedule and update it as much as we can, but a lot of the discussion has either been "Hmm, this is just much harder than I thought it would be" or "I know it's taken 3 days so far but it still looks like a 1-day task." This is notwithstanding getting sick and other vaguaries which affect the rate of progress. Even when work is going ahead full steam, and even when there is nobody "in the loop" but myself, it's incredibly difficult to figure out what is going to need to be done in advance of the doing of it. It's also interesting to observe how even the level of certainty about how close the estimate is needs to be explored - there is a layer of meta-certainty there which is very difficult to express. For example, what I'm working on now, a MIME-generation API, was something that I thought would take a few minutes. Having written the inverse of this code and more than "half" of the generation step, I thought it would be completely trivial. It's not very hard, but it does turn out that it's more than a few hours of work to get done, because there were problems that I had not considered in my previous, super-simplified implementation that turn out to completely break the model I was previously working with.
The Agile Manifesto says that we should value "responding to change over following a plan". In general I tend to agree with the Agile way of thinking, but I don't quite get this one. I don't think it's wrong, really, but it's reactionary. What it's reacting against is the established convention of following an imposed plan which development and/or customer communication have shown to be incorrect. They're saying throw out the plan and keep the customer happy, don't set a schedule up front before it's clear what the priorities should really be.
I can't wholeheartedly agree, though, because I've seen the very positive effect that a plan can have on one's progress. When the plan is actually working, and it's possible to execute to it, it's very personally satisfying and fulfilling. Also, it provides a spur to keep working to achieve a goal that you (arguably) know is attainable.
It's hard to look at a plan and say that it's wrong, though, especially when one isn't really sure. When I'm looking at a 1-day task that has unexpectedly turned into a 2-day task, I hope that it will stay a 2-day task. I have a hard time understanding why things slip and what makes a programming task more or less work, despite a decade of programming experience and 5 years of desperately attempting to estimate tasks accurately before performing them.
To get back to the original point, my emotional reaction as a programmer is to reinforce the existing assertions about deadlines, in the hopes that the wetware in my brain will react to these invariants sensibly, as a component of a software system would. Just as Mr. Meyer sets forth certain assertions about typing and software contracts and assume they will have some bearing on unrelated problems.
On a small, distributed, agile, open-source team using Python, I find my personal time-management strategies reverting to the same comfortable shared hallucinations that make static typing, const correctness, and waterfall product planning all make sense.
Obviously I need to respond more directly and actively to change, to prototype my time and schedule management the same way I'd prototype a program, by trying some strategies quickly to see whether they work without investing too much effort, and when they do work carrying forward with them as far as they'll go.
The main question that I'm wrestling with at the moment is, how do I reconcile this with the slow-moving, context-heavy kind of thinking that programming requires? Each failed prototype is a big, expensive task switch which throws nasty heisenbergian effects into scheduling. Each time I try to measure the effectiveness of the schedule, it slips some more, because by even thinking about measuring the schedule, I'm not thinking about programming.
I think that the answer has something to do with regimentation, i.e. spending an hour, the same hour, every day thinking about planning and absolutely no time outside of that hour.
Tuesday, November 11, 2003
Of course, my luck would run out once I am safely ensconced in my near antiseptic apartment, miles and miles away from anyone who might infect me (and equally distant from anyone who could bring me chicken soup).
It was a good sick, though, as such things go. I was dizzy, disoriented, and my 18-hour nap was fitful and full of surreal images and vivid auditory hallucinations. I particularly liked the dream where I was attending the Simon Belmont VII Memorial Institute for Extraterrestrial Hunter/Killer Studies, hanging upside down by my anti-gravity boots and using a glowing blunderbuss with ammunition reminiscent of tylenol gel capsules to ring a huge church bell to signal the start of class.
Friday, November 07, 2003
Tuesday, November 04, 2003
Monday, November 03, 2003
All the confusion stems from daylight savings time, which is, I might add, a terrible, terrible idea. US time and European time are just subtly different enough to be annoying, but they don't have anything seriously surprising in them.
Python's spiffy new datetime module is aware of these issues, and apparently wishes to avoid becoming embroiled in the hothouse world of temporal politics. Odd design choice, considering that the language was designed by a time traveler. While this is irritating from the point of view of someone who wants to just stuff some date objects into strings formatted appropriately for different time zones, I can see why. The amount of work you'd need to do to properly support every time zone is staggering.
For example, it turns out that israeli daylight savings switch-over time is set every year by the ministry of the interior, so you can't actually anticipate it in software, only retroactively apply the dates.
I have no idea how japanese, russian, african, or chinese dates work yet, and I'm not really looking forward to find out unless it's in the form of a robust