Saturday, April 21, 2012

Elevating the head of the bed

This is kinda elementary, but I did it wrong last time; this way is better.

First, I'll show you a picture of the setup: each end has a 2x4 lying edgewise. A 2x6 lies between them, kinda like a bridge. I mis-measured the bed, so the 2x6 is too short; it doesn't reach all the way across. So I put a 2x4 on top of that.

As you can see, this creates a stand, or a prop, about 7½" high, which ought to be high enough. (If you make it too tall, you and everything else on the bed will tend to slide downhill—including the mattress.) How do you keep the 2x4s on the end from just collapsing onto their sides?

I did it wrong the first time; I drove screws through the 2x6 into the 2x4s, but the screws weren't long enough.

You can see the new and improved version at right; that bracket will hold the 2x4 on more securely. I also "toenailed" it in a couple of directions, and added a longer screw, too, through the top of the 2x6 into the edge or each 2x4.

And though the 2x4, lying down atop the 2x6, isn't subject to the same kind of sidewise pressures, I went drove two 2.75" screws through that long 2x4 into the 2x6, so it's a lot more stable than the old version.

The white things on the "foot" are felt pads; I thought they would be kinder to the floor than a 2x4 directly on it.

How about getting the thing under the bed? I used a hydraulic jack, as you can see below. With the bed being right next to the wall, there's not much room for a helper.

That's about it; I slid the stand under the bed, lowered the bed onto it, and pulled the jack out. Then I pushed the bed horizontally toward the headboard; mission accomplished.

If you're wondering why we want to do this... well, let's just say there are lots of reasons why one might want to have the head end of the bed elevated.

Why “#!/usr/bin/python -utt”?

From a colleague's questions I see that my explanation in this post from last year wasn't quite clear, so I'll try to make this one more complete.

First let's talk about tabs. The Python style guide (also known as "PEP 8" [link]), recommends using spaces only, particularly for new projects:

Tabs or Spaces?

    Never mix tabs and spaces.

    The most popular way of indenting Python is with spaces only.  The
    second-most popular way is with tabs only.  Code indented with a mixture
    of tabs and spaces should be converted to using spaces exclusively.  When
    invoking the Python command line interpreter with the -t option, it issues
    warnings about code that illegally mixes tabs and spaces.  When using -tt
    these warnings become errors.  These options are highly recommended!

    For new projects, spaces-only are strongly recommended over tabs.  Most
    editors have features that make this easy to do.
You can see how this works in a very short script like:
if 1+1==2:
        print "I'm still here"
<tab>print "and math still works"
If that's saved in you can run it with python and you should see the two strings:
$ python
I'm still here
and math still works
With "-t" we get a warning about tabs and spaces:
$ python -t inconsistent use of tabs and spaces in indentation
I'm still here
and math still works
With "-tt" (two "t"s) the warning becomes an error:
$ python -tt
  File "", line 3
    print "and math still works"
TabError: inconsistent use of tabs and spaces in indentation

How about that “-u”?

This one is a little more complicated. In a lot of computer programs, when you "print" something, it doesn't display the characters on the screen right away. Instead, it saves them up in an output buffer; it buffers them. Usually this is a good thing, because the program can't display characters all by itself; it has to call upon the system to do it, and it's cheaper to call the system once to display an entire line, rather than calling the system e.g. 42 times (once for each character on the line).

But there are at least two situations where this buffering isn't desirable. One case is when you want to leave the cursor at the end of the line for a while. Here's a silly example:

from time import sleep
print "waiting five seconds...",
print "done."
If you run this simply as "python" then nothing happens for about five seconds, then the line
waiting five seconds... done.
appears all at once. If it's run as "python -u" then the first thing you see is the "waiting five seconds..." part. Then about 5 seconds later, "done." appears.

Another case where buffered output isn't so nice is if your process fork()s (copies the current process, creating a "child" process) with un-displayed characters left in the buffer. Here's an example of weird behavior:

from time import sleep
from os import fork
print "after sleeping, let's try a fork...",
pid = fork()
if pid == 0:
    print "in child process"
    print "in parent process; child is pid", pid
When we run it as "python", we get this:
$ python
after sleeping, let's try a fork... in parent process; child is pid 7370
after sleeping, let's try a fork... in child process
Why? Because at the time we call fork(), the output buffer has "after sleeping, let's try a fork..." -- which isn't displayed yet in the terminal window. When the parent adds "in parent process; child is pid 7370" and terminates the output with a newline character (by default), the output buffer is flushed—its contents are written to your display. But that only flushes the buffer of the parent process; the child's buffer still has those characters.

Thus, when the child process runs, an extra copy of "after sleeping, let's try a fork..." appears on the screen.

What if we run it as "python -u"?

$ python -u
after sleeping, let's try a fork... in parent process; child is pid 7367
 in child process
If you run this yourself, you'll see "after sleeping, let's try a fork..." appear almost immediately (i.e., you don't have to wait 5 seconds for it). When the process executes fork(), the buffer has already been flushed; that's why we don't see two copies of the "after sleeping..." part.

Why is the "child process" line indented by one space? Well, we didn't retain "after sleeping..." in the buffer when we created the child process, but we did retain the knowledge that we weren't at the start of a new line. Thus, the child process thinks we're not at the beginning of a new line, so it prepends a space to "in child process" before displaying it, just as it would if we were truly in the middle of a line. This is just the way Python's print statement works.

I hope that made sense. And since my Python scripts don't have a whole lot of output to the display, it doesn't hurt much to use "-u" all the time. Combining that with Guido's recommended "-tt" option... that's why I pretty much always have "-utt" in my Python scripts.

Saturday, April 14, 2012

Yeah right, Mitt

Mitt isn't quite as much of a liar as Newt—at least this time around.

This is an amazing fact: Fox News—Fox News!—says Romney's case on women and jobs is skewed. Here's an excerpt:

ROMNEY: "This is an amazing statistic. The percentage of jobs lost by women in the president's three years, three and a half years — 92.3 percent of all the jobs lost during the Obama years have been lost by women." — Hartford, Conn., on Wednesday.

LANHEE CHEN, Romney campaign policy director, on the Obama administration Wednesday: "They've done a tremendous amount of damage to American women in this economy."
You know, there are lies, damned lies, and statistics (Mark Twain I think). Fox news adds:
When Obama took office, unemployment for men (8.6 percent) was already sharply higher than for women (7 percent). The rate peaked for men at 11.2 percent in October 2009 and for women at 9 percent a month later.

Since then, the gap has nearly closed. Last month, the rate was 8.3 percent for men and 8.1 percent for women.
Here's an economist at the Bureau of Labor Statistics commenting on MSNBC:
Brian Davidson, an economist at BLS, told First Read: “The math they use is correct; the terminology is completely wrong.”

Davidson noted that women actually make up a larger share of the workforce now than they did in Jan. 2008 before the financial meltdown, and since January 2009, it is a statistically insignificant change.

In January 2008, women made up 48.8 percent of the workforce; in January 2009, 49.5 percent; now 49.3 percent.
FACT CHECK: Romney's women jobs-loss claim paints incomplete picture
By Domenico Montanaro, Deputy Political Editor, NBC News
So where did these job losses come from? 64% (over 3 in 5) came from the public sector. That's right: government jobs. The Republicans want to do what to government? Make it smaller? Lay off more public-sector workers. Right?

So over 3 in 5 of the net job losses for women came from smaller government, and therefore women should vote for Mitt? Dude, most women are smarter than that. Next question: in which states did these public-sector female job losses occur?

This is so embarrassing (for them), but check out the chart at left. It's from the Atlantic -- Why Mitt Romney's ‘Economic War on Women’ Charge Could Backfire by Jordan Weissmann Apr 11 2012, 5:27 PM ET

The takeaway from this chart is: All those job losses for women Mitt's been talking about? 3 in 5 are from smaller government. Over 70% of those are in Texas (the "Rick Perry effect"?) and in states that went Republican in 2010. Look what the GOP has done for women's jobs in state and local governments; imagine what would happen with Mitt in the White House!

Unemployment figures worsened for the first 8-9 months of Obama's term, then they got better.

Mitt, guys like you make me feel embarrassed to be a Republican. I wish you'd tell the truth. "Yeah, we're for smaller government, which means even more job losses at the state and local governments, (and coming soon: federal government!)..."

Friday, April 13, 2012

The #1 cause of marriage problems

I started listening to a series of sermons about marriage; the lovely Carol found them on the Redeemer Pres website—on sale! The first sermon introduced the series; we heard that long passage from Ephesians 5, starting in verse 21. In the version I memorized, 5:21 reads: ...being subject to one another in the fear of Christ.

This verse (Ephesians 5:21) holds the key to the #1 cause of marriage problems, according to Dr. Keller. What is that cause? Self-centeredness! And from my completely arbitrary sample size of one (1) marriage, he's right.

I mean, in my marriage, the #1 cause of problems is self-centeredness: mine in particular. (It's all about me!) We were talking about this in my small group of guys, and I actually told them that. Well, not in those exact words; I think I said "selfish" rather than "self-centered". I mean, I really do want to put the lovely Carol at a higher priority than my ideas and projects and so on... just not right at this moment.

Right? Isn't that an illustration of the problem?

The point I really liked (sorry I don't have the link handy; you can find it just as easily as I can) was his comment that we all have woundedness and selfishness. Though my wounds might make my selfishness a little more severe, I was selfish from the day I was born (sorry, Mom). And so were you! And so were your kids! Little kids do need to be taught to share and to take turns; they do need to be socialized. The idea that kids are born perfect is truly silly.

Anyway, we have wounds, and we need to be cared for; we also have selfishness, and we need to repent. If two people decide that their need to be cared for exceeds their need to repent, that's like two fleas, each thinking the other is the dog.

What if both partners say/think this: "I need to repent of selfishness more than I need you to take care of me; I should put you first, rather than insisting that you care for me first"? Great things can happen. Unlimited possibilities!

May the Lord help us to keep on doing so.

Friday, April 06, 2012

Why do Christians call it "Good Friday"?

The Wikipedia article gives a lot of facts about the day and summarizes its events, how to calculate its date in any given year, etc. The short version is that on the Friday before Easter, the Romans crucified Jesus of Nazareth, or "Jesus Christ" as Christians call him. The death was particularly cruel and horrific, but not "unusual" at the time. Nobody liked to talk about this method of execution; you can read more in this excellent paper.

But what about this horrific death makes it even a mediocre Friday, let alone “Good Friday”? As we Christians believe, it was the day that our sins were atoned for. The guilt and shame of the whole world were on that day piled upon Jesus Christ, and (in the words of this hymn) the wrath of God was satisfied.

How does that work? Wrath -- doesn't that seem kind of, um, judgmental and archaic and so on? The short answer is "no," but let me unpack that a bit.

One of life's big questions is this: Does the universe, the earth, my life mean anything? Or is life, the universe and everything just a meaningless cosmic accident? I'm going to say that the only possible answer is that these things, this planet, your life all mean something. And in your life, your daily thoughts and activities, you also say that life means something. Do you ever get angry at the injustice in the world? When you read about greedy bankers on Wall Street, cruelty and oppression in Syria, the horror of human trafficking? You're angry because you believe these things should not be! They're wrong!

Where do the moral facts of the universe come from? They're not based on your opinion or mine; contrary to the non-cognitivist view of meta-ethics, moral statements are not in the same category as "Go Bears!"; they are rather more like "It's evil to kidnap children and force them to become soldiers or prostitutes because it robs them of dignity and crushes their spirits." And it's not reasonable to say "well, child prostitution may be evil to you, but it's okay by me."

Right? So where do such moral facts come from?

Christians believe that they come from the Creator of the heavens and the earth. We call Moses the Lawgiver, but he was the law conduit; the moral facts of the universe came from God the Creator.

Some of these moral facts are well-understood by most of us -- the obligation to treat each person fairly (Lewis wrote cogently about this in Mere Christianity) for example. "Hey, what did you do that for? What did I ever do to you?"

One of the facts which has become unpopular over the centuries is the need for atonement when we do wrong. Lewis gave a terrific allegory of this in the closing chapters of The Lion, the Witch and the Wardrobe, but the short version is that in the words of the Bible, "the wages of sin is death but the free gift of God is eternal life through Jesus Christ our Lord" (Romans 6:23).

Anyway, what all that means is: Christ lived a sinless life and his death paid the penalty for our sins (1 Peter 2:21-24). This was a wonderful day for you and me, even if you aren't a Christian (1 John 2:1-3), but a horrific one for Jesus, who gave his life for us.

And that's why we call it Good Friday.

Tuesday, April 03, 2012

De-google-izing search results

This keeps happening to me so I wrote a script to deal with it:
  • Google search on something, say "measuring software modularity"
  • See some PDF files in the results
  • "Open in new tab" one of those PDF results
  • The new tab has something that looks like
  • A "what to do with this file?" dialog box appears, suggesting
    • Save the file;
    • Open with something (Acroread, Preview, okular, kpdf, xpdf, etc.)
And what you've got when this is done is the ridiculous URL above

What I want instead of the above monstrosity is simply

Here's some code that'll do that. I have python2.3.something on this Mac OS X 10.4 powerbook (from 2006) and...

#!/usr/bin/python -utt
# vim:et
'''Given a google-ized URL on stdin return the URL of interest.
Example input:

Example output:'''

import sys
import urllib

USTART = '&url='
UEND = '&'

def main(infile):
    for aline in infile:
        aline = aline.rstrip()
        ustart_at = aline.find(USTART)
        if ustart_at < 0:
            print "Can't find '%s'; ignoring" % USTART
        url_start = ustart_at + len(USTART)
        url_end = aline.find(UEND, url_start)
        if url_end == -1:
            url_end = None
        print urllib.unquote(aline[url_start:url_end])

if __name__ == '__main__':