Comments on: Suicidal Code

By: Matthias

Matthias — Wed, 18 Jul 2007 11:52:51 +0000

I’ve released a class called ESSTimeTrialClass for this purpose. You can get it over at http://codebeach.org/code/show/36

Long time ago, maybe brian even took this as inspiration :)

Take care!

By: Christopher Humphries

Christopher Humphries — Wed, 18 Jul 2007 02:18:09 +0000

Definitely bookmarking this idea

By: vasi

vasi — Mon, 16 Jul 2007 22:42:34 +0000

I think the ’safe’ Cocoa way to do it is:

nowDate = [NSCalendarDate dateWithString: nowString calendarFormat: @"%b %e %Y" locale: nil];

I still think that dateWithString:… is somewhat underspecified, it’s certainly not as clear as the POSIX strptime(3). But it seems to Do What I Mean in all the reasonable cases, so I guess that’s good enough for me.

Just watch out for that Year Ten-Thousand bug! :-)

By: Daniel Jalkut

Daniel Jalkut — Mon, 16 Jul 2007 19:18:50 +0000

E. Wing: Good to know! That should mean the technique is highly portable, even to other platforms. Since the format is so predictable maybe the best thing is just to parse it myself, but of course I bet some standard Posix call will do it given the right template.

By: E. Wing

E. Wing — Mon, 16 Jul 2007 19:13:27 +0000

__DATE__ is actually defined by the ANSI C standard and is not just a gcc extension. I don’t think there is any locale support.

The date of translation of the preprocessing translation unit: a character
string literal of the form”Mmm dd yyyy”, where the names of the
months are the same as those generated by the asctime function, and the
first character of dd is a space character if the value is less than 10. If the
date of translation is not available, an implementation-defined valid date
shall be supplied.

By: Rosyna

Rosyna — Sun, 15 Jul 2007 20:47:48 +0000

dateWithNaturalLanguageString: is completely dependent on the user’s locale and settings. This means it may “mysteriously” fail in “really bad ways” depending on the user’s settings.

From the documentation:
“This method supports only a limited set of colloquial phrases, primarily in English. It may give unexpected results, and its use is strongly discouraged.”

By: Dan Grover

Dan Grover — Sat, 14 Jul 2007 21:01:39 +0000

I thought that was a pretty cool idea since you mentioned in the other night. Thanks for posting the code!

By: David Van Brink

David Van Brink — Sat, 14 Jul 2007 03:49:09 +0000

Nice!

I’ll add my 1 cent to Dds Dunham & Wareing — in your startup, #if EXPIREAFTERDAYS print “this application will expire soon”, to the console, and the splash screen.

You’ll remember pretty quick about the suicide code then. Or someone else will, before the 14 days are up. Transparency is next to godliness.

By: Daniel Jalkut

Daniel Jalkut — Sat, 14 Jul 2007 00:00:51 +0000

rentzsch: Agreed and amended.

By: David Wareing

David Wareing — Fri, 13 Jul 2007 23:58:05 +0000

To avoid leaving the code in, print out a release checklist and step through it methodically. Once your project is sizable and you have support files to build and add, temp files to remove, server data (e.g. RSS feeds) to upload, scripts to run, etc. then you don’t really want to have to remember crucial stuff. Especially on release day (aka the busiest day of your year).

I find it helps to put all version-specific stuff like this in one header, so that as I go through the release checklist I can make several changes in one place.

One other thing: you may want to check the user’s clock. It’s far from uncommon for a user to report problems with beta time-outs or license validation due to their clock having been set back (either accidentally or otherwise). Get the build date and compare against the current date as returned from the OS. If there’s more than a few days difference (remember your friends in future time zones!) then show a notice to the effect “check your clock” and exit.

Note: if you do this, don’t be tempted to bypass __DATE__ by checking date stamps on arbitrary system or preference files. (They are not at all reliable.)

Note 2: be careful with __DATE__. It represents the time of compilation of that source file only. Thus, if you put your check in some source file, compile it, and never recompile it before release, then __DATE__ will not reflect the overall build date of your project.