At Any Price

[1.0 stars] [IMDb Link] [Amazon Link]

Mrs. Salad loooves Dennis Quaid. Ever since Breaking Away. So this was a must-get-for-my-sweetie at Netflix.

I'm not jealous or anything. And I'm pretty sure I would dislike this movie anyway.

Dennis (I call him Dennis) plays Henry Whipple, Iowa farmer. (Although, according to IMDB, "Iowa" is mostly played in the movie by "Dekalb, Illinois".) Henry is an aspiring agricultural mogul, even to the extent of attending a fellow farmer's funeral in order to make a pitch to buy the deceased's acreage. He also sells seeds for "Liberty Seed" an eeevil corporation (standing in for Monsanto, I think), and he's guilty of some bad behavior there too.

One of Henry's two sons, Dean (played by Zac Efron), is still at home. Henry would like him to take over the dynasty, but Dean would prefer to become a NASCAR driver. Who wouldn't? He's moody and self-centered, and treats his girlfriend like shit.

I might have liked this movie better if any of the main characters were more likeable or interesting, or if they overcame their character flaws to redeem themselves. But (as the movie develops) they only reveal more flaws, succumb to them, and are not called to account.

Your mileage may vary. Roger Ebert, before he was promoted to doing movie reviews for God, gave it 4/4 stars. And this guy found Dennis "at his most vulnerable and entertaining in a long time." I thought he—sorry—read his wooden dialog perfunctorarily, as if he realized what a sucky movie he'd been roped into.

Last Modified 2014-01-04 10:08 AM EST

Reading Schedule Generator

[] December 2017 Update: More changes, described at end of article.

October 2017 Update: I regret that I let this article get badly out of whack with reality. Notably, most of the links to my code, which were on the old UNH "pubpages" server, went stale when I retired. In addition, I've cleaned up the code some and fixed a nasty Daylight Savings Time-related bug. I hope. Further notes at the bottom of the article.

Note: this post is out of whack with normal Pun Salad content. Only recommended for:

  1. computer geeks who (like me) tend to approach everyday issues by asking: how could I write code to make this easier?; or
  2. psychologists who might be interested in whatever mental aberration causes the behavior exhibited in (a).

A few years back I noticed I was doing a miserable job of reading the magazines to which I was subscribed; the new issue would show up and I would have just read few if any articles in the previous one.

A similar problem with books: I would check them out of the library and return them unread. And my to-be-read pile of owned books just was getting bigger.

What worked for me was to set up a reading schedule for each "new" book or magazine. Simply read through a reasonable, fixed number of pages each day, until done. Lather, rinse, repeat.

I'm currently implementing this scheme by generating a calendar-format schedule for each item in HTML. Example for a book I read back in 2014, Freedom™ by Daniel Suarez:

[Sample Reading

I (1) print the schedule from my web browser, (2) cut it out, (3) attach to a card, and (4) use the result as a bookmark for the item. And each day, I try to meet the page goal for each item.

(Not that it matters, but for magazines I staple the schedule to one of the subscription cards that invariably accompany each issue. For books, I tape it to one of the plastic advertising cards the Yankee Candle company sends us, which are significantly more substantial.)

Now I'm not psycho about this: it's OK to get ahead of the goals if the material is compelling and I have the time. It's also OK to fall behind if there's just too much other stuff going on. (However, in my experience, just knowing that I've "fallen behind" is just enough self-nudging motivation to carve out some extra time to catch up later.)

Enough for the mechanics, on to the code. For a long time I ran a Perl script from a Linux command line to generate a schedule. But I realized that it would be (slightly) more flexible to set up an HTML form to get the schedule parameters, calling a CGI backend to display the result.

The form I'm using is here. (Do I have to mention that you can use your browser's source-viewing capabilities to view the HTML source? Nah, probably not.)

[December 2017: there used to be a screen shot here. That's silly. Just visit the form to see what it looks like.]

[December 2017: removed paragraph about the jQuery datepicker, no longer used.]

The form also uses a CSS stylesheet found here; I originally wrote it to make the documentation I wrote at UNH look better, and it has a lot of cruft. Feel free to steal and clean it up.

So you fill out the form, for example:

Schedule Generator Form]

[Note: it doesn't look exactly like this any more. I urge you to try it yourself.]

… hit the submit button and the resulting page should produce the appropriate schedule. (I'm pretty sure it would work for you if you want to try it.)

The real work is performed by the Perl CGI script, which relies heavily on the smarts contained in the, HTML::Template, and Date::Manip Time::Piece modules. If you'd like to look at that (feel free to adapt it to your own preferences if you are so inclined): the plaintext Perl file is here and the html-prettyprinted version is here. The HTML template used by the script is also important and that's here.

Additional notes (October 2017).

  • As previously mentioned, the original version of the CGI script lived on the UNH "pubpages" webserver, where I enjoyed root access. It's now on the Pun Salad server, where I don't. This is problematic when you need to install some random CPAN perl module.

    Solution (or, at least, what I'm doing): use cpanm to install necessary modules "unprivileged" and put use local::lib; in scripts to find them. (This seems to work for CGIs, surprisingly.)

  • The most recent bug squashed was one I've struggled with for years: if your timezone does DST, not all days are 24 hours: the "spring forward" day has only 23; the "fall back" day has 25. This resulted in strange behavior when a reading schedule traversed one of those days.

    The fix turned out to be relatively easy: tell the script to pretend it's in the UTC timezone. Duh. That's accomplished by (for example) the line

    $startdate->config( 'setdate', 'now,UTC' );

December 2017 Update: Some minor surgery on this tool to report.

  • After years, I noticed that, in many cases, I wanted to spend a specific number of days reading a book or magazine. This involved me looking at a calendar, and finger-counting to figure out what end-date to specify in the form.

    Duh. That's an unforgivable user interface sin, is it not?

    So the input form now requests either (a) the end-date for the reading schedule, or (b) the number of days the schedule should run from the start date.

    If you enter both, the end date will be ignored, but why would you do that?

    I would put up a screen shot, but you can just look for yourself at the actual form.

  • The form has been otherwise (ahem) brought into the 21st century. Title, start date, start page, and end page input fields now sport the HTML attribute required. The type attribute is used specify that the title should be text, the start/end pages should be number, and the start/end dates should be date.

    That means the web browser's native date-picker UI will be used for date entry instead of the previous jQuery datepicker. (Some old browsers don't support this, but since I'm not being paid to support old browsers, I can say "gee, that's too bad", without guilt.)

  • Some Javascript is still used for client-side verification: the start page has to be less than the end page, either the number-of-days or the end-date input has to be there, and if the end-date is specified, it has to be after the start date.

  • Web Security 101 saith: your CGI must still check the validity of its inputs. So all that code is still in the CGI. But…

  • I also modified the CGI script to use the Perl Time::Piece module for calendar arithmetic instead of Date::Manip. This greatly simplified the code, and (somewhat surprisingly) Time::Piece seems to do the right thing when the reading schedule overlaps a Daylight Saving time warp.

    I still think Date::Manip is vital for heavy-lifting Date/Time calculations. But it's overkill here.

Last Modified 2017-12-31 11:08 AM EST