Getting around a GMail restriction

For several years now, I’ve had a script called checkcards that logs into my local library, collects information on the items my family has checked out and on hold, and sends me an HTML email with the information presented in tabular form.

Checkcards message

I have launchd set up on my office iMac to run this script every morning. My wife also gets a copy through a mail rule on the server.

Until recently, this message was generated through a Python script using the mechanize library and then sent from my iMac via the sendmail command. 12 In late July, I noticed that the email from checkcards had stopped. I’m no email routing expert, but it appeared to me that GMail was refusing to deliver messages routed to it from my computer.

This wasn’t a big surprise. If anything, it was more surprising that GMail had ever accepted messages routed to it from an unauthenticated machine like my iMac. Even back in the 90s, the onslaught of spam had caused mail servers to become more restrictive on who they’d route mail for. I remember having to add special settings to the Exim configuration on my Linux box to get around these restrictions.

With sendmail no longer working, I needed a new way to get my messages delivered. I decided to try out Python’s smtplib module, and after a bit of experimenting I found I could send my messages with just a few lines tacked onto the end of the script. Here are the lines:

206:  # Send the message through GMail.
207:  smtp = smtplib.SMTP_SSL('', 465)
208:  smtp.ehlo()
209:  smtp.login(gmailUser, gmailPassword)
210:  smtp.sendmail(mailFrom, mailTo, msg)

Line 207 establishes the connection to the GMail SMTP server on port 465. Line 208 starts the SMTP communication with an EHLO (extended hello) command. Line 209 then logs on using my GMail credentials (established earlier in the script), and Line 210 actually sends the message. It was much simpler than I feared.

If you’re wondering why I don’t use a service like Library Elf, the answer is simple: my library isn’t in the Elf system. Unless you happen to use the Naperville Public Library, my script won’t be of any direct use to you, but it’s on GitHub anyway, on the off-chance that other people can alter it to fit their own needs. If your family uses the library a lot, a centralized system for tracking everything you have checked out can make your life simpler.

  1. Sendmail is the venerable Unix utility for routing email over the network. It’s legendary for its cryptic configuration file and its vulnerabilities. It was Sendmail that allowed the Great Internet Worm of the late 80s to spread. Given how small the internet was back then, “great” is something of an overstatement, but that’s how it was thought of at the time. 

  2. On OS X, the sendmail command doesn’t really run Sendmail, it runs Postfix in Sendmail compatibility mode. 

Late to Launch

I’m so late to Launch Center Pro. I bought it fairly early on, but never got into using it. Despite the hoopla when it was released, I didn’t understand why I should use an app that basically launched other apps and performed tasks I almost never do, like toggle the screen brightness or turn on the flashlight. I tucked LCP away on one of my never-swipe-to screens and forgot about it. I didn’t pay attention things to Alex Guyot’s encyclopedic guide to LCP or to Phillip Gruneich’s giant list of apps that support x-callback-url because I “knew” LCP wasn’t for me.

I used Drafts, of course. Since much of what I do involves text, it seemed more natural to use actions that start in a text editor. But even with Drafts, I was pretty conservative in my use of actions, because I do most of my real work on a Mac and have focused on creating scripts, macros and other automated workflows that help me there.

Earlier this month I learned what I was missing. After building an overly complicated set of scripts for adding common entries to my work diary, I learned how much simpler a set of LCP actions would be. I now have a color-coded group of actions for all my common diary entries.

Work diary LCP actions

The icons I chose from LCP’s collection may not be the best expression of the concepts, but they were easy to implement and didn’t require any artistic ability on my part. The goal is to have buttons that are distinct enough that I can choose the appropriate one quickly without putting on my reading glasses.

Note that the Diary button itself is in a spot that’s easy to reach with the left thumb. I know that many people hold their phone in their dominant hand, but I’ve never done that. Because I often need my right hand free to take notes, my habit is to have the phone in my left hand.

My other group of actions is for running the scripts that clean up my iPhone screenshots. These are the final versions of scripts that evolved over the course of a couple of months near the end of last year.

iOS screenshot LCP actions

I use color coding to distinguish between the single-image scripts and the pair scripts, and I use icons to distinguish between screenshots taken on WiFi and those taken on LTE. The icon I use for WiFi is actually the RSS icon, and the one I use for LTE is absurdly generic, but they communicate their meaning to me, which is all that counts.

My main LCP screen is pretty sparse.

Main LCP screen

The Scanner button opens JotNot Pro, the app I use for scanning receipts when I’m on the road. It doesn’t do any clever actions; I have it here only because JotNot Pro itself is in a folder on my second screen, so having it here makes it easier to launch.

The Map button opens the Maps app to the address on the clipboard (or it fails miserably if there’s no address on the clipboard). When I arrange a business trip, I put all the pertinent travel information in a plain text file in Dropbox. This includes the addresses of the hotel I’m staying at and any other places I’ll be visiting. When I get in my rental car to drive to one of these locations, I copy its address out of the file and run this action. This may not seem like much of a time-saver—I can, after all, just open Maps and paste in the address—but I’ve found that I often mistap when trying to select the address field in Maps and have to try again. Using the LCP action eliminates the frustration that comes from my clumsiness. The URL for the Map action is[clipboard]&lc-icon=maps

The Convert button is sort of an experiment; I don’t think I’ll keep it. It prompts me for a number,

Prompt for number to convert

then launches PCalc to its conversions section. The URL for the Convert action is


I don’t think this is actually faster than just launching PCalc from the home screen and tapping the A→B button. I just wanted to try out a PCalc URL scheme and the LCP [prompt-num] option.

With iOS 8 and its extensions just a couple of weeks away, I don’t want to get too deeply into Launch Center Pro. Some of the actions I could make might be better done with an extension. I’ll have to explore both possibilites when I upgrade. Too bad I wasted time up until now that could have been saved with LCP actions.

Energy dissipation in damped vibrations

In the previous post in this series (which was four months ago—time flies), we looked at the free vibrations of damped single-degree-of-freedom (SDOF) systems, systems that can be modeled as a spring-mass-dashpot like this:


The position of the mass, [u], can be expressed as a function of time, [t], through the formula

[u = A e^{-\zeta \omega_n t} \cos (\omega_d t - \phi)]

where [\omega_n] is the natural frequency of the undamped system, [\omega_d] is the frequency of the damped system, and [\zeta] is the damping ratio. They’re related to the physical properties of the system through these equations:

[\omega_n = \sqrt{\frac{k}{m}}] [\zeta = \frac{c}{2 m \omega_n}] [\omega_d = \sqrt{1 - \zeta^2} \omega_n]

The other two variables, [A] and [\phi], are determined through the initial position and velocity of the mass. As discussed before, we can start our clock at any time we like; we can, without any loss of generality, set [t = 0] at a point that will lead to [\phi = 0]. This simplifies the solution to

[u = A e^{-\zeta \omega_n t} \cos \omega_d t]

Taking the derivative of [u] gives us the velocity:

[\dot u = -A \omega_n e^{-\zeta \omega_n t} \left( \zeta \cos\omega_d t + \sqrt{1 - \zeta^2} \sin \omega_d t \right)]

where we’re using Newton’s dot notation for derivatives with respect to time.

In an earlier post, we calculated the total mechanical energy of an undamped system and showed how it remains constant over time. Let’s look at the mechanical energy of our damped system. The potential energy is

[U = \frac{1}{2} k u^2 = \frac{1}{2} k A^2 \left[ e^{-\zeta \omega_n t} \cos \omega_d t \right]^2]

and the kinetic energy is

[T = \frac{1}{2} m \dot u^2 = \frac{1}{2} m \omega_n^2 A^2 \left[ e^{-\zeta \omega_n t} \left( \zeta \cos\omega_d t + \sqrt{1 - \zeta^2} \sin \omega_d t \right) \right]^2]

Because [k = m \omega_n^2], the kinetic energy can also be written as

[T = \frac{1}{2} k A^2 \left[ e^{-\zeta \omega_n t} \left( \zeta \cos\omega_d t + \sqrt{1 - \zeta^2} \sin \omega_d t \right) \right]^2]

The total mechanical energy is the sum of these two, [U + T]. Instead of giving it as a long formula, let’s plot it. We’ll have to choose a particular damping ratio, so let’s go with [\zeta = 0.10].

Damped vibration energy balance

Note how the total mechanical energy decreases with time. Where is it going? It’s being dissipated as heat as the fluid in the dashpot gets pushed back and forth by the piston. The total energy curve is wavy because the activity of the dashpot changes with time. When the mass is near the extreme left and right ends of its travel (when [\omega_n t \approx 0, \pi, 2\pi, …]), its velocity is nearly zero and the dashpot isn’t doing much. The total energy is nearly constant during these times. On the other hand, when the mass is moving quickly (when [\omega_n t \approx \pi/2, 3\pi/2, 5\pi/2, …]), the dashpot is at its peak of activity and the total energy drops rapidly.

At the end of the previous post, I questioned the usefulness of analyzing a spring-mass-dashpot system:

Mechanical systems have springy parts and they have mass, but very few have actual dashpots. What good is all this math if it doesn’t represent actual equipment? We’ll talk about the kinds of real-world things we model as dashpots next time.

We model systems using dashpots because that leads to differential equations that we can solve. What we model as dashpots are things that dissipate mechanical energy from the system. For example:

Sliding friction is very common—almost unavoidable. It occurs at joints where parts are supposed to move relative to one another, like hinged joints; but it also occurs at joints where the part aren’t supposed to move relative to one another, like bolted joints. Surfaces held together by bolts are supposed to remain fixed, but they slide anyway—a little bit, back and forth—as the machine or structure vibrates. This slippage causes the parts to heat up, and it’s that transformation of mechanical energy into heat that causes the total mechanical energy of the system to decrease

Materials deformed beyond their elastic limit cannot spring back to their original state, leading to a loss of mechanical energy. Energy is also consumed when cracks form in a material because it takes energy to create the new surfaces on either side of a crack. This is a very common mechanism for energy dissipation in concrete structures.

Both plastic deformation and cracking are forms of hysteresis, but hysteresis also occurs anytime the loading and unloading curves of a material don’t match up.


Image from Wikipedia.

The energy lost during a cycle of loading and unloading is represented by the area between the two curves. Hysteresis can occur in metals even when they’re loaded below the elastic limit, especially when the loading is rapid.

None of these dissipation mechanisms match the dashpot mathematically—that is, the energy loss wouldn’t follow perfectly the wavy curve shown in the energy plot. But we can choose a value of [\zeta] that makes the total energy loss the same, and that’s often good enough. Engineering is not science. The goal of engineering is not to understand our systems perfectly (which we could never achieve); the goal is to understand them well enough to build devices that work.

It’s just a silly phase I’m going through

I saw Guardians of the Galaxy this past weekend and really enjoyed it. There were a few clunky spots, and I have no idea why people are praising Vin Diesel’s voicing of Groot,1 but it was a fun movie. The movie was not, however, about my Guardians of the Galaxy.

Here are my Guardians, straight outta 1975:

Guardians of the Galaxy

Steve Gerber wrote the Guardians stories during my comics collecting days. I was a big Gerber fan back then, and read everything of his I could get my hands on. I have no idea what Marvel plans to do with Howard the Duck, but (Spoiler Alert!) I assume his appearance at the end of the movie was a nod to Gerber’s work on the old Guardians. Or maybe it was just a recognition that a racoon wasn’t the first anthropomorphic animal hero.

One of the old Guardians did make it into the movie. See the blue-skinned guy with the red fin coming out of his head? That’s Yondu, he of the whistle-controlled yaka arrows. Same blue skin but with a bar on top of his head instead of a fin. And the comic book Yondu didn’t have Michael Rooker’s menacing southern accent, probably because he was from Centauri IV.

The token Earthling, Vance Astro2 (in the blue and white outfit), like Peter Quill, left Earth in 1988, but he wasn’t abducted. Astro volunteered. He was put in suspended animation, bundled into a rocket, and shot to Alpha Centauri in a poorly thought-out attempt to save the human race. In the 1988 of 1975, we were all dying of cancer because we’d destroyed the ozone layer.3 How was one man alone supposed to start a colony on another world? Beats the hell out of me.

Marvel didn’t even think to give Astro an awesome mixtape, because predicting rockets to Alpha Centauri was easier than predicting the Walkman. You’d think they could’ve at least given him an 8-track player.

  1. Bradley Cooper’s Rocket Racoon, on the other hand, deserves every bit of acclaim it’s received. 

  2. Yes, Vance Astro. 

  3. As I recall, Marvel used ozone depletion to explain Killraven’s future Earth, too.