The Foursquare Blog

That is a pretty comprehensive list. I'm probably in the same camp as you claim to be, having broken every one.

The rules are pretty strong as well. I'm still mulling them over in my mind, but there is one that sticks out as unwise, or poorly written. It is #3, which says: "I will not write a program that fails to do tomorrow what it was able to do yesterday."

Taken purely literally, this prevents all change, all experimentation, all feature-level refactoring. I'm sure this is not what the rule was intended to say. I'm assuming it is more of an encouragement for better testing, so that a bugfix in one area doesn't break a feature in another.

Even taking this rule as a Testing Rule, I think it overreaches. There are steps that programmers can take to prevent regressions, but to assume that it is possible, or even common, to prevent them all is wishful thinking.

I think a better rule would be something like: "I will not refuse or hinder the fixing of a bug that I have caused."

Wow.

I laughed. I cried. I laughed again. I shook my head at how we humans operate. How we judge without even realizing it.

I read in shock at the conditions.

I marvelled at the manners of people in those days, at the work ethic, and at Nellie Bly's determination to finish her mission and her sense of humour in the most downtrodden of situations.

I was moved by the compassion. I was dumbfounded at the lack of it. I understood the fear. I applauded the courage. I cringed at the food. I got angry at the cruelty.

And when I thought it couldn't get worse, the next chapter would blow my mind.

In short, this is a book that needs to be read, and needs to be read today. Not because the exact conditions of the asylums are the same as today, but because the conditions of the heart are the same today.

Seventeen chapters. It will take a while to get through, but it's worth it.

Nearly every blog out there supports comments. Even newspapers are supporting comments now. Everybody wants their say, and everybody seems eager to give them a chance.

So why don't I?

First, let me say it is not because I want to stifle feedback. That is not my goal. But rather, I want to encourage thoughtful feedback and discussion.

You may notice that on some of my blog entries related to advogato, I link to other people's blog posts in my response. This is intentional. Someone may write something. I may respond. He may respond back. This conversation should be visible, via HTML linking, to the readers of both blogs.

If I just added a comment on his blog, the conversation would remain there. My blog readers would be unenlightened. And vice versa.

The size of comments generally does not promote thoughtfulness. It does not reward thoughtfulness. Who really bothers to link to a blog comment? Not nearly as often as people link to blog posts.

I would rather read a shorter conversation of thoughtful posts than wade through a thousand short comments and mini conversations tacked onto the bottom of one thoughtful blog post.

Massively public comments generally detract from a post, in my opinion. There have been many times that I've read an article, thought it was good, and then read something unpleasant in the comments, and moved on, forgetting about the original article entirely. This happens on newspapers and online magazines as well. There are "regulars" on these sites, and their squabbles and arguments are not helpful and do not add anything to the topic.

Why would I want to share with a friend an article that is marred by unsavoury comments?

Of course, on smaller blogs, this is much less of a problem. The regulars are often friends of the author, and the comments are often very positive or at least thoughtful. But do we really need to read five "good post!" comments at the end of a good article? I think not. Better to share it with a friend than congratulate the author. Isn't that what the author wants anyway? More thoughtful readers? If the author truly deserves congratulations, send it by email.

In addition, there is the administration headache of dealing with spam, user accounts, Captchas, and so on. I do not want my blog to be used as a link factory for spammers, nor do I want to have to decide whether to delete a friend's post just because he linked to something self-promoting.

The "check out my product XYZ" style of comments turns a thoughtful blog post into an ad.

If comments are allowed, even more questions pop up. Do you moderate them? Do you censor them? What do you delete? Do you write an Acceptable Use Policy?

Bah.

I would much rather encourage thoughtful discourse in the style of old fashioned letter writing. Have you ever read old letter conversations? Perhaps some old letters between St. Augustine and Jerome? How about old love letters? How about your own old letters?

There is a flow of thought and a degree of thoughtfulness that letters encourage. Each person sits down and reads the whole thing, and then responds to the whole thing, with their own flowing thoughts.

This is what I want to see in the blogosphere. Each writer has their own blog. Each writer responds to others in their own posts on their own blogs. If you don't have a blog, then you write an email to the author, and the author quotes your email in his next blog post.

Slower. More thoughtful. More comprehensive. And it solves the whole spam problem.

This is why this blog does not have comments.

You can watch the video here and read the somewhat long-winded New Yorker article here.

The short version is that he went for a smoke on Friday night, and wasn't rescued until Sunday afternoon. He went through various stages in his ordeal, from patiently waiting for help, to trying to signal someone, to trying to escape, to anger and looking for someone to blame.

It was an express elevator that only served floors #39 and above. According to the article, it stopped around level #13, and when he finally did try to open the doors, all he got was a brick wall.

There was a button for an alarm, but while the alarm rang on top of the elevator car itself, obviously nobody heard it. When he tried to get out through the hatch at the top, he found that it was locked. In fact, it was locked by law, from the outside, for operators to get in, not for passengers to get out. The theory is that it is much more dangerous outside an elevator, riding on top, than inside.

When he was discovered, someone was suspiciously wondering what he was doing in that car. But after talking with the maintenance team through the intercom, he was given a series of button commands that got the car moving again, back to the lobby floor.

I would love to know those commands, and whether they work on most elevators. I guess it pays to have your cell phone with you whenever you're in an elevator. Has anyone checked their cell phone radio range while riding?

One thing thst struck me while watching the video is that... hey, there's a camera! If by chance, any security guard or elevator maintenance person looks at the monitors, what are they looking for? Isn't it a normal thing to see a person inside? Therefore, the best way to signal for help via the video system is to make things look unnatural, or to put a written sign in front of the camera, if you can find it. And to keep the sign there for as long as you are there, since you never know when someone might look at the monitor. Make sure the sign has good lighting as well.

Here are a few links to other pages I found with tips for escaping a stuck elevator.

The saddest part of Nicholas White's story is the end. Although dehydrated, he was rescued, and lived. But sadly, he became a bit of a hermit, working more on the lawsuit than returning to his job. According to the article, he lost his job, got a fairly small settlement, lost contact with his former colleagues, lost his apartment, and remained mostly unemployed when the article was written in 2008. In the end, it took much longer to escape the elevator than just 41 hours.

I was unable to find much news about Nicholas White since, but I sure hope that his life has improved by now.

Instead of merely slapping on a helmet and thinking you're bulletproof, though, take a look at this excellent site on bike safety: How To Not Get Hit By Cars.

Whether you wear a helmet or not, the primary goal for safety should be to avoid an accident in the first place. And this site explains the dangers logically and clearly.

I remember being very impressed by the site the first time I found it a few years ago. It changed the way I ride on the streets. I hope it will help improve your safety as well.

It would still be nice if timegm() was in a library of its own instead of libc. But that's probably asking too much.

Good to know. Thanks!

There is also a very handy set of functions that goes in the other direction. The function gmtime() takes a time_t and converts it to a struct tm in the UTC timezone. And localtime() does the reverse of mktime(), converting a time_t to a struct tm in the local timezone.

The one function missing is the reverse of gmtime().

One way to do it, via standard library function calls, is to adjust the TZ environment variable to "UTC" and then call mktime(), which will then use it as the current timezone. But that gets messy. Not only do you have to save the old TZ setting to restore it afterward, if your program uses threads, messing about with the global TZ variable is hardly safe.

Another way to do it is to use gmtime() as a reference point, and loop while adjusting the original struct tm until mktime() + gmtime() gives you the result you started with. This is brute force and inelegant, but it manages to do the job without fiddling with the global environment.

When parsing ISO timestamp strings, this problem is hit pretty quick. An ISO timestamp can contain a time in either the local timezone or UTC, depending on the trailing 'Z' flag. In my research, it does not appear that more specific timezones can be specified in the timestamp format, so at least we only have two states to worry about.

After much searching, I've ended up with something that I find suitable enough to release. I tackled this problem back in 2007 for the OpenSync project (you can see similar code in the opensync_time.c file), but looking back on it now, the code is not clean enough for me to reuse very easily. And even though there's a vtime2unix converter function, it leaves the burden of timezones to the user.

I took a look at Boost's date_time library as well, and while huge and comprehensive, and though it breaks the problem of time, dates, and durations into nice manageable chunks, it seemed to reverse the status of the C library: it made UTC conversions easy, and local timezone conversions hard. And it reads timezone information out of CSV files... I don't want to have to maintain my own timezone database when the OS does it for me.

So, if I don't want to write my own conversion routines, and if I don't want to maintain my own timezone database, I'm stuck with the C library method, and the first two solutions. Might as well make it easy to use.

The source files for TzWrapper contain the following utilities:

• iso_to_tm() - simple ISO timestamp converter
• utc_mktime() - the brute force UTC to time_t converter
• TzWrapper - C++ wrapper class for setting and restoring TZ

Using TzWrapper, it's now possible to do things like:

	struct tm pacific_tm = { ... };
	time_t t = TzWrapper("Canada/Pacific").mktime(&pacific_tm);
	cout << TzWrapper().Set("Australia/Brisbane").ctime(&t);
 
	const char *iso = "20100430T231500Z";
	time_t stamp = TzWrapper::iso_mktime(iso);

If you have any further tips to make this code better, or pointers to better libraries that make this code obsolete, please let me know!