Blogging and readability
May 22nd, 2013 at 11:16 pm by Dr. Drang
Oh, goody! A blog post about blogging! I’ll try to make it brief.
This post by Matt Gemmell about designing your blog for its readers is good, and you should go read it if you haven’t already. I do, however, have some nits to pick:
- I think he’s confusing current fashion for eternal truth when he says sidebars should be removed. Why is it better to put all your meta-info in a header or footer instead of a sidebar? I agree that info about the blog should be reduced to a minimum—and, like Matt, I’ve been pruning mine over the years—but where it goes is more a matter of taste than reader inconvenience. To me, the advantage of the sidebar is that vertical space is more precious on today’s widescreen displays. Use the vertical space for content and put the peripheral stuff on the periphery—that’s where the adjective comes from. Yes, phone displays are different, but phones know how to focus on a single column, don’t they?
- Despite my longstanding complaint that web designers make their body font too small, I think Matt’s decision to increase his body font size is wrong, too. How about just honoring the user’s choice? Yes, most users have no idea they can change the default font size (and Safari 6 made it even harder by removing the Appearance preference pane), but you shouldn’t punish those who do.
- He’s overly dogmatic on the matter of line length and line spacing; there are many combinations that are perfectly readable. I do like that he warns against lines that are too short—a lot of sites today have such narrow content columns it’s exhausting to scroll through to the end of the article.
- He seems to think that any framing of the content is “cruft.” Again, this is fashion, and while it’s fine to be fashionable, this has nothing to do with readability. A few years from now, Matt will be dissatisfied with the broad expanses of white he has today.
- While I’ve had my ups and downs with comments, I still think they’re a net positive for small blogs like mine with a polite and informed readership. I understand why writers with a big audience find comments a pain; why they can’t demonstrate a reciprocal understanding is a mystery to me.
One thing Matt said really hit home:
Consider interaction methods, too: hover doesn’t really work on touch-screens, for example.
The popup-on-hover footnotes I use here seemed really cool when I stole them from Lukas Mathis three years ago, but they’ve worn out their welcome. I still think having footnotes pop up is better than jerking the reader down to the bottom of the post and then back up again, but hover isn’t the way to trigger popups in a world of iPads. That’ll have to change.
Overall, I found Matt’s advice to be sound. I was a little surprised to see his endorsement of Twitter and (especially) Facebook links. These are generally considered douchey among the cool Mac bloggers; I look forward to reading their reactions.
Dropbox/bin
May 21st, 2013 at 8:55 pm by Dr. Drang
It’s so easy to see the inefficiencies in someone else’s workflows, but so hard to see them in your own. When you do finally root out some clumsiness in your setup—no matter how small—and replace it with a more streamlined system, it’s a cause for celebration. This is a small celebratory post.
I’ve kept my scripts in a ~/bin directory pretty much since I started using Linux in ’97. I’m not sure if I learned to do that from someone’s explicit advice or if I just copied the idea from someone. Either way, it’s a pretty common setup in the Unix world: you create this ~/bin directory as a personal analog of /bin, /usr/bin/, and /usr/local/bin; you modify your $PATH environment variable in .profile, .bash_profile, or .bashrc1 to include that directory; and then any executable script saved in that directory can be run from the command line without specifying the full path to it. The advantages of saving to ~/bin instead of one of the system wide bins are
- You don’t need superuser powers to save or modify files in
~/bin. ~/binwon’t get overwritten when you do a system update.
When I moved to the Mac in 2005, I kept this same setup and it’s served me well. But there’s always been one catch. If you have two computers, your ~/bin directories won’t stay in sync unless you create some clever piece of automation to keep each directory up to date with changes in the other. I never did that. I tended to move new scripts written on one computer to the other through CD-ROMs, then USB thumb drives, and then, finally, Dropbox. I often forgot to move scripts and didn’t realize it until I needed one that only on the other computer.
If you look up at the title of this post, you know what comes next, but for some reason it took me a couple of years of using Dropbox to figure it out. While it’s conventional in the Linux/Unix world to have your ~/bin directory just below your home directory, there’s no requirement for it to be there. It can be in any subdirectory of ~. In particular, it can be in ~/Dropbox/bin, where it will automatically sync between however many machines you have attached to that account.
Even after I finally realized this was the way to go, I didn’t pull the trigger. I don’t know why. Maybe it was because I’d lived so many years with out-of-sync ~/bin directories; maybe it was because the tradition of ~/bin was so strong I was afraid to change. Whatever, today I finally copied the contents of ~/bin at work into ~/Dropbox/bin and then did the same at home (skipping over duplicates), so ~/Dropbox/bin has all of my scripts. A quick edit of my .bashrc to change
export PATH=$HOME/bin:…
to
export PATH=$HOME/Dropbox/bin:…
on both machines and the transformation was complete. I now have directories for my scripts on both computers that are automatically synced. Hooray!
In case you’re wondering, I have not deleted either ~/bin directory. There is absolutely no reason in the world for the new system to fail, which is all the more reason to keep a backup for when it does.
-
Or whatever the equivalent is for
zshif you’re one of those weirdos. ↩
Steel in Extremis
May 20th, 2013 at 9:00 am by Dr. Drang
I saw Iron Man 3 with my family Saturday night. It was fun (Ben Kingsley was especially good), but there was a part that bothered me a bit. I tweeted about it later:
Iron Man 3 was fun, but that water tower in Tennessee should’ve fallen long before its leg melted.
— Dr. Drang (@drdrang) Sat May 18 2013 8:56 PM CDT
The tweet got a little attention, so I figured it was worth explaining.
The scene I’m talking about is when Tony Stark is in Tennessee, trying to repair his suit and learn about the first Extremis explosion. After he escapes from the fight in the bar, Tony comes across Killian’s number one henchman who, in that way comic book villains have of being way too elaborate in their plans to kill the hero, melts one leg of the town’s water tower to bring it down onto Tony.
Here he is heating up the leg (big props, by the way, for using a laced design for the column):
And here he is “pulling” it down after the leg is so hot it’s almost dripping:
Both screenshots from fxguide.com.
The problem is that the leg would have failed long before it got to that orangey yellow state. Even though it doesn’t melt until about 2500° F, steel just isn’t very strong above 1000° F.
Here are a couple of charts showing the rapid dropoff of steel’s strength and stiffness (modulus of elasticity) for temperatures above 500°—700°. They’re taken from Brockenbrough and Merritt’s Structural Steel Designer’s Handbook.
These are idealized curves for design purposes, so they’re a little on the conservative side. I have an older version of this book that had a similar chart for strength with actual data points for different structural steels.
For completeness, I’ll mention that an older water tower like the one in the movie would almost certainly be made from A36 steel.
As you can see, somewhere between 1200° and 1300°, the strength of steel is about a third of its room temperature strength. Given that the water tank in the movie was full (it wouldn’t have been interesting otherwise), losing two-thirds of its strength and a similar amount of its stiffness1 in one leg certainly would’ve brought the tower down. It might have collapsed at an even lower temperature.
What color does steel take on a various temperatures? Here’s a handy chart from Swedish steel maker, Uddeholm:
At the temperatures needed to cause collapse, the steel would be only a dull red, not the bright orange and yellow we see in the film.
And in case you’re wondering, yes, pretty much all of the above went through my head as I watched that scene. “Bothered” may be too strong a word for my reaction, but I couldn’t help but notice it. We all have areas of specialized knowledge that get triggered when we see someone get it wrong. This is one of mine.
Why does a column collapsing at the wrong temperature tweak me more than a guy melting steel by touching it? Well, the Extremis stuff is part of the comic book universe; it’s one of the futuristic/fantastic elements that drive the story. Complaining about it would be like rejecting The Lord of the Rings because hobbits don’t really exist. The water tower, on the other hand, is part of our world and should act like it. It wasn’t designed by Tony Stark.
-
The stiffness is important because the leg is a compression member. Compression members fail by buckling, and buckling capacity is governed by both yield strength and modulus of elasticity. The more you know… ↩
Now we see the violence inherent in Hooke’s Law
May 18th, 2013 at 10:31 am by Dr. Drang
This is the post where I explain how I avoided shooting my older son with the head of a screw. Two heads of screws, actually, but we’ll get into the details later. The underlying topic is strain energy, its potential1 for harm, and the respect it should be paid.
As I said a few days ago, the inspiration for this post—apart from the actual incident in which I avoided shooting my son—was this episode of Gabe Weatherhead and Erik Hess’s Generational podcast, in which they talked about the dangers of their respective former professions—Gabe as a research chemist and Erik as a fighter pilot. The dangers associated with being a fighter pilot are pretty obvious; those associated with being a research chemist are probably less obvious, but you can get a good sense of them from the title of the episode: “What Happened When Gabe Set Himself on Fire.”
Like chemistry labs, mechanical testing labs have their own set of dangers, most of which involve the sudden, unexpected release of strain energy. You learned about strain energy in high school physics, although your teacher probably didn’t call it that. Shortly after learning about the forces in springs and Hooke’s Law, [F = kx] (a topic we’ve looked at here once or twice), you learned that the potential energy2 stored in a spring is expressed by this formula:
[\frac{1}{2}k\;x^2]The [k] in the formula is the spring constant, which is a measure of how stiff the spring is. It’s measured in units like pounds per inch or newtons per millimeter—force per length—and is always a positive value. The [x] is the amount, as measured in inches or millimeters or some other unit of length, the spring has stretched from its natural, unloaded length. The sign convention for [x] is arbitrary, but it’s usually taken that positive values of [x] represent lengthening of the spring and negative values represent shortening.
You see, then, that because [x] is squared, the potential energy in the spring is either zero (when the spring is at its natural length) or positive. This makes sense because potential energy is defined as the ability to do work. A compressed spring is able to do just as much work as a stretched spring, so their potential energies should be the same and should have the same sign. And a spring that’s neither stretched nor compressed can’t do any work, so its potential energy should be zero. So far, so good.
The reason Hooke’s Law works on a macro scale for things like coiled springs is that a very similar sort of law works on a micro scale within the spring wire. On the micro scale, the force-displacement relationship, [F = kx], is replaced by a similar relationship between stresses (which are like forces) and strains (which are derived from deformations). In the same way that the potential energy stored in a spring is a function of its stretch, the potential energy in any deformed body is a function of its strain. Hence the term “strain energy.”
The details I’ve glossed over in the previous paragraph would fill, and do fill, volumes. My shoulders are sore from all the hand-waving, but I’ll push on.
When it comes to the ability to do harm, not all strains are created equal. It’s only the elastic strains—those which can be reversed when the load is removed—that present a danger. If you stretch a rubber band in front of your face and let go, it’ll snap back and hit you in the nose. That won’t happen if you do the same thing with a ring of Play-Doh. In a mechanical testing lab, we’re usually applying very large forces to parts and materials that have a lot of reversable elastic strain. And when things break, whether intentionally or unintentionally, the huge strain energy that’s built up as the parts have been loaded is suddenly released and turned into kinetic energy. Lab safety is all about directing that kinetic energy to where it won’t hurt anyone.
Which brings us, finally, to my son and the screw heads. One weekend a few months ago he was helping me finish up a few tests. The tests were intended to break things, and I had barriers set up to block any pieces that might come flying out at us. And of course we were wearing goggles. The tests went smoothly and no one came close to getting hurt.
We ran into a snag while taking the equipment apart. One of the pieces of the test fixture was a pipe clamped in place by four capscrews like this one:
Source: littlemachineshop.com
A side view of the clamping arrangement looked like this, with two screws on the top and two on the bottom (you see only one in each position because its mate is behind it). The screws passed through unthreaded holes in the blue piece and screwed into threaded holes in the green piece.
I had clamped and loosened this pipe many times over the previous month of testing, and internal hex surfaces of the capscrews had rounded out. Finally, after the testing was over, the Allen wrench wouldn’t grip in the screwheads and I couldn’t loosen the clamp and remove the pipe.
So I grabbed a hacksaw, slid its blade down the gap between the blue and green pieces, and drew it back to start cutting. That’s when I noticed my son standing to the left, directly in line with the screw heads.
Let me digress at this moment of high tension3 and explain how bolts and screws work. Most people know that bolted joints4 require sufficient torque to do their job. Many of you have probably used a torque wrench at one time or another. But most people don’t realize that torque, in and of itself, is meaningless. Bolted joints work because of the tension in the bolts, not the torque. The purpose of applying torque to a bolt is to use the mechanical advantage of the thread (which is essentially an inclined plane wrapped around in a helix) to stretch the bolt and induce tension in it. There are, in fact, bolting systems in which a hydraulic machine stretches a bolt directly by pulling on its tail and then spins the nut up tight to maintain that stretch—no torque of any significance is ever applied.
The word “stretch” in the previous paragraph should prick up you ears. Strain energy is stored in every fully tightened bolt because that bolt has been stretched. When such a bolt breaks or is cut, that strain energy gets released somehow, often by sending the bolt head flying.
In this case, there’s even more strain energy available. The flanges on the two clamp pieces are bent under the load of the screws. When the screws are cut, they’ll straighten back out, acting as a catapult to fling the screw heads.
“You need to move around to the other side,” I said.
“Why?”
“Because when I cut through, these screws are going to shoot out like bullets, and you’re standing in the way.”
“Really?” I should mention that my son is sixteen years old and therefore assumes that I’m full of shit. But he moved anyway.
I did a suprisingly good job of cutting evenly through the two top screws, and they snapped almost simultaneously. The screw heads shot across the lab and hit a piece of plywood leaning against the opposite wall with a loud th-thunk. I was vindicated; when I had to cut another recalcitrant screw a few minutes later, he stayed well out of the line of fire.
While I was happy to have proved myself not entirely full of shit, I was annoyed at my brief lapse. I’d been careful during the test but let my guard down briefly during disassembly. I should never have even picked up the hacksaw before clearing him out of the way. Strain energy is not to be messed with.
-
You may not get that joke yet, but Ben Deaton is laughing his ass off right now. ↩
-
Yes, that was the joke. ↩
-
I slay me. ↩
-
There is a technical difference between bolts and screws, but it has nothing to do with this discussion, so I’m going to use the words interchangably from now on. ↩
A simple Drafts work diary
May 14th, 2013 at 10:50 pm by Dr. Drang
Topics for posts are piling up and I don’t have time to write them up. I’ve recently plotted out posts on
- The dangers of stored strain energy and how I avoided shooting my older son with the head of a screw when he helped me run some load tests a couple of months ago. This topic was inspired by the May 4 episode of the Generational podcast, in which Erik Hess and Gabe Weatherhead discussed the dangers of their former workplaces and Gabe’s propensity for setting himself on fire.
- Thermal stresses and why Katie Floyd’s glass baking dish blew up on Mother’s Day. This one would harken back to Dan Rutter’s post on Pyrex, which I read through a link from Marco Arment.
- The alleged design and craftsmanship in this artisanal bottle opener which Justin Blanton made the unforgivable mistake of ordering.
- How revisiting the comic books I loved as a teen has left me disappointed in both the writing and the artwork. The one exception is the early Conan series by Roy Thomas and Barry Windsor-Smith, and that’s probably because I’ve always seen myself as a latter-day Conan—black-haired, sullen-eyed, sword in hand, a thief, a reaver, a slayer, with gigantic melancholies and gigantic mirth.
And that doesn’t include more topical posts that I’ve given up on writing because their time has passed.
So tonight I’m taking the easy way out, with a short post about the iOS Drafts app inspired by David and Katie’s recent iOS Automation episode of Mac Power Users and by the Generational episode with Greg Pierce,1 the developer of Drafts.
Last night I asked a stupid question about Drafts on Twitter:
Y’know what’d be great? If @draftsapp could append to a Dropbox file named according to the date, creating the file if necessary.
— Dr. Drang (@drdrang) Mon May 13 2013 8:16 PM CDT
It was stupid because Drafts can already do what I was asking for, as several kind people told me without snickering. Here’s the Dropbox action I came up with:
In my defense, the reason I didn’t realize I could use a date tag (the thing inside the doubled square brackets) in the name of the file is the name of the option that must be chosen with it: Predefined. It just didn’t seem right to me that a file with a predefined name could have its name defined on the fly. Also, it seemed superfluous to have a Timestamp option for the file name if a timestamp could be provided through tags. Still, the ability to use tags in file names goes back to version 2.5.3—I should have known about it.
Anyway,2 this action is intended to help me keep track of what I’m doing at work, what the action described at the end of this post should’ve been. The idea is to launch Drafts when I switch from one task to another, tap in (or dictate) what I’m about to start working on, and invoke this action. Each time, a pair of lines will be added to a diary file for that day, one with the timestamp and the other with the note I wrote for it. Like this:
1:14 PM
Started 200° test
1:45 PM
Ended 200° test
1:54 PM
Started 300° test
The improvement over the old system is that now I’ll have a separate file for each day, all in the same Diary folder in Dropbox. To me, this is a more natural way to organize diary entries, rather than having them all with time and date stamps in a single big file. Each day’s file will have a name like 2013-05-14.txt.
This is, in many ways, the same sort of thing Katie Floyd is doing with Day One. I like Day One, but I prefer using plain text files in case there comes a time when I want to run some script over my diary files to extract information. I have no plans to do that, but I want leave open the possibility.
Of course the real trick isn’t coming up with a Drafts action, it’s developing and maintaining the discipline to make an entry every time I switch contexts. I’m working on that.
