Yikes, I’d set this stupid thing up well over a year ago, but only recently noticed that my navigation bars were sticking outside the overall page borders on two of the pages, one with no content, and one with minimal content.
My cyber friend, @chorell just discovered that one could fix such barbarities by setting overflow:auto; for a style on the outer container div. So I tried it, and it worked. Thus, I now have
<div id="cont_container" style="overflow:auto;">
and I’m good to go.
Now the only thing to fix is the stupid in-line styling, but I’m too lazy to go to the trouble of loading my style sheet in a text editor, fixing the text, firing up my ftp client, sending the file to my server, etc. Of course, I could just use sexyFileManager to edit directly on the server, but then I’d run into the same problem that happened last time I did that: later on, more extensive overall edits to the site will over write the minor corrections because I forgot to sync what I’d fixed on the server with what I had on my hard drive. Then things that once were fixed will become broken again. Gah!
addendum:
It turns out that I could probably have accomplished the same thing by adding class="clear" to my footer, i.e.
<div id="footer" class="clear">
No worries, things are better indeed.
— lgpiper
Several years ago, it occurred to me to create a Psalm-o-matic for Lent. I have no idea why this occurred to me, it just popped into my head one day and I couldn’t forget it. In theory, we are supposed to be a bit more focused on spiritual things, like scripture and prayer, during Lent. Just because we’re Congregationalists—UCCs actually—why shouldn’t we attempt to bow to tradition, at least a bit. So to make the scripture part a little more palatable—or so I thought at the time—how ‘bout if we each read a Psalm each day? Rather than expect people actually to hunt up a Bible, and then figure out where the Psalms lay in that book, why not just e-mail out a Psalm? If we’re to read Psalms, why focus on the three or four we already know. How ‘bout we read a randomly selected Psalm? That way, in theory at least, we would get through Lent with a representative selection of Psalms, the familiar and the not-to familiar.
Thus was born the idea of the Psalm o’ matic. Now to figure out how to implement it. Of course, I thought it would be cool to write a computer program to do the work for me. I had a job at the time, and was a bit rusty on my programming, so I ended up with the coward’s way. I used the random-number generator function in my spread sheet program to make up a list of numbers between 1 and 150. Then I copied the list over to a schedule, printed it out, and manually e-mailed out the Psalm scheduled for each day. Not all that o’ matic, huh?
I did that for a couple of years, but this year, since I was unemployed, I figured that I should brush off my very rusty shell scripting and try to make a real, bone fide psalm-o-matic. The shell script would, in theory at least, randomly pick out a number from 1 to 150, select the Psalm that related to that number, and do the e-mailing for me. All while I slept.
The first thing I needed to do was come up with a method for generating random numbers from 1 to 150. Of course that’s trivial if you are programming in C or C++, or using a spread sheet, but I was trying to do this in Unix shell scripting, the only way I knew how to send out e-mails automagically. It turned out that what I knew about sending out e-mails—learned in Intro to Unix back in the summer of 2000—was no longer valid, at least not on my system. But I didn’t know that when I began this project.
Anyway, it turned out that generating random numbers from the unix shell was relatively easy. My server at Joyent runs bash-shell scripts, and the bash shell has a build-in shell variable called $RANDOM. $RANDOM returns a random number from 0 to 32767 whenever it is called. To pare this selection down to 1 to 150, I merely had to multiply the $RANDOM variable by 150, divide by 32767, and then add 1 to take care of the fact that Psalms begin with 1 not 0 (zero).
psalmNo=$((1+150*$RANDOM/32767))
and the variable, $psalmNo would indeed be a number between 1 and 150.
So far, so good. Now I just needed to select the appropriate Psalm and send it off. Selecting the appropriate Psalm was trivial, albeit tedious. I made up 150 text files with names like psalm_xxx.txt, where xxx was a number from 1 to 150. Then I just needed to combine three elements, the root of the text-file name, the Psalm number and the extension:
body="$filePath$fileRoot$psalmNo$fileExtension"
Oh, yeah, I forgot to mention, the $filePath thing tells the computer where to find the directory that has all the Psalms in it.
So now we get to what I assumed would be the easy part, e-mailing the Psalm. In olden days, we did something like the following:
mailx -s "e-mail subject" someone@somedomain.com <$body
That is, the file in $body is inserted in an e-mail message to someone with the subject given. Well, it didn’t work. After thrashing around for quite some time, I asked for help and was told that mailx no longer worked because of security issues. I had to use sendmail -t instead.
I’d never heard about sendmail -t before. I guess it didn’t work in the olden days. Or perhaps it just didn’t work at UMass/Lowell, who tend to be a bit behind the times (when I took Java Script, I was told to be wary about things that caused problems with Netscape 2.0. WTF? we were in a post-Netscape era by the time I took that class.)
Anyway, I had to learn about sendmail. That wasn’t overly difficult. I discovered that the -t option meant that the system used the header information embedded in the file. So eventually, I figured out that meant I had to make up the files I e-mailed out with stuff like “To: someone@somedomain.com” at the top of the file, and the text file containing the Psalm at the end. Well, crap, I didn’t want to go through 150 files and put in all the header stuff first. What if I wanted to do something else with the files later on?
Fortunately, this wasn’t a problem. I suddenly remembered about “appending” things to a file. To append things, you just did a double carat thingie, i.e.
cat $body>>$filePath$mailMsg
and you get the stuff in $body, i.e. the Psalm file, appended to $mailMsg, the thing you created with all the header info. So I build it up a bit at a time, starting with the “To: someone@somedomain.com” stuff, adding in the From, Reply-to, and Subject stuff and finally ending with the Psalm file.
So after all this ruminating, we ended up with:
# !/usr/local/bin/bash # psalm o' matic script # # This works as follows: \ me@myServer$ /usr/local/bin/bash psalm-0-matic # If you don't precede with the "bash" it won't work. \ No idea why. # The fully qualified paths through out are necessary \ to make this work as a cron script # # This uses my random number generator script # # Why in the hell am I using vi? # I'm not anymore -- using TextPad with sftpDrivefilePath=\ "/users/home/myUserName/domains/myDomain.org/web/public/Psalms/" fileRoot="Psalm_" fileExtension=".txt"# ***seed Random with a "random" number -- \ then select Psalm o' dayRANDOM=$RANDOMpsalmNo=$((1+150*$RANDOM/32767)) #all 150 -- Oh, yeah!# *****************prepare the message ******************mailMsg="MailMsg"today=`/usr/xpg4/bin/date '+%A, %B %d, %Y'`# ***************** prepare e-mail header ****************dateField="Date: "$today #toField="To: me <lgpiper@myDomain.tld>" #later on it would be fccr-ace. addressFile=pomList toField="To: "`cat "$filePath$addressFile"`\ #pomList is comma delimited: name <user@domain.tld>, ... fromField="From: Larry Piper <me@myDomain.net>" replyToField="Reply-to: me@myDomain.net"\ #later on it would be fccr-ace? subjectField="Subject: Psalm for "$today"--Psalm "$psalmNo# ***************** assemble message ****************** body="$filePath$fileRoot$psalmNo$fileExtension"echo $dateField>$filePath$mailMsg echo $toField>>$filePath$mailMsg echo $fromField>>$filePath$mailMsg echo $replyToField>>$filePath$mailMsgecho $subjectField>>$filePath$mailMsg echo " " >>$filePath$mailMsg echo " " >>$filePath$mailMsg cat $body>>$filePath$mailMsg# *****************send the message ******************/usr/local/bin/sendmail -t <$filePath$mailMsg
Ok, this worked. Getting it to send out automagically turned out to be more trouble than I realized, but I eventually got so I was sending myself Psalms on an hourly basis. Just in time for Lent.
Addendum:
The scheme worked like a charm and we lucked out in that Ps. 119 never came up. Not sure anyone would have been able to slog through that one at one sitting.
Addendum 2:
Man, what a PITA this was to format. I thought these content management systems were supposed to make life easier. I’d have been better off to do the damn thing in raw xhtml. WTF?
Addendum 3:
I forgot that stupid IE will make all content disappear when one uses pre tags with a longish line. They don’t understand the overflow problem. With luck, this is now fixed here. You’ll know things that got fiddled for IE because they have ‘\‘s at the ends of lines. I also made the font size a little smaller in the code blocks. Stupid IE…Sheesh!
Addendum 4:
I can’t believe that I had most of the carats pointing in the wrong direction. I must be partly dyslexic. It’s one thing I didn’t edit the posterous version of this post. Posterous is a PITA for editing, but there was no excuse to delay fixing this for more than a year. WTF? Oh well, it should be ok now.
— lgpiper
I don’t see why the monpage graph needs to be exiled to a side bar. Why not embed it in an article about the usefulness of monitoring one’s web sites? So without further adieu, here’s my effort:
Site Response
So the problem here, is I can embed it either in the side bar or in an article. I haven’t figured out how to do both yet. One of the required variables in the script is the div container for the graph. Can’t have two divs with the same id. So far, I haven’t figured out how to rename the variable in two places, but I’m no programming whiz. Eventually, I’ll get there.
28April08 update
So, I put the graph back in the side bar, which means this page no longer renders a graph. As I said above, eventually, I’ll figure it out, but since this page is no longer on the front, I should fix the side bar.
— lgpiper
Comment [1]
Ok, so I just discovered that if I switch my site status from “testing” to “live”, that the page load times should shorten up. As far as the world goes, the site has been more-or-less live anyway. That is, anyone who knew where to look would find the site. So, it will be interesting to see if this makes any difference. Fortunately, I have my handy Monpage account, so will be able to check things out.
— lgpiper
Comment [1]
Ok, I’m beginning to get a handle on formatting. Because I’m old-school, I want my page to look balanced in all monitor resolutions. So I struggled for quite some time to re-implement my nifty resolution resizer thingie. It was easy enough once I figured out how to link to style sheets and javaScript files on the server to the TxP template. So now I have that part ok (it was trivial, I was just ignorant and the TxP documentation is pretty awful). Now, just to redesign the headers, and learn enough of the TxP forms to make things work properly.
As an aside, I also figured out how to intsall the Monpage tracker on my site. Pretty nifty. I have no idea why my site response is so crappy. My server is lightning fast at serving up static pages. I’m surprised these DB-driven pages are so much slower. Oh well, live and learn.
— lgpiper
Comment [4]