Until today.

For some reason, the TSA doesn’t allow torch-style lighters. If you want to bring a lighter on board, it has to be a natural flame lighter. That’s fine, as I use a natural flame lighter for my pipes.

Apparently this time they were confused that my lighter might be a torch lighter, so they wanted to check my bag to check it out.

That part doesn’t really bother me. What bothers me is the way the TSA “officer” acted when she found the lighter. Without checking any of the details of the lighter, she assumed that it was a torch and also assumed that the pipe tools that fold out of the side of it included a knife. Of course she didn’t actually TELL me this, because that would have made everything very easy. She got a very snide tone to her voice, and in a loud voice said “Sir, this is not allowed!”

Had she just nicely asked me about the lighter instead of immediately jumping into “gotcha, you evil person” mode I would have responded differently. As it was, her response ended up putting me in defensive mode, so I probably wasn’t completely cool when I informed her that it WAS allowed according to the TSA website.

Her response to that made me fear that I was going to be detained. Something along the lines of “SIR! I’m gonna tell you this ONCE. This is not allowed. If you want to speak to a supervisor, you can.”

So of course I quickly responded “I do,” and it wasn’t until this point that she finally decided to start checking out the lighter. She mumbled, “oh, this isn’t a knife.” The supervisor did what she should have done in the first place: “Is this a torch?” and when I said no, he tested it and said it was fine.

If the first lady had handled this in a more appropriate manner, I wouldn’t have been frustrated, I would have responded better, and we wouldn’t have needed a supervisor. But the power evidently went to her head, and she reacted in a way that was as if it was perfectly designed to make me angry.

The port on the bottom for the dock connector used to be so snug that only the Apple cable that came with the iPhone would work with it. Even the cheap counterfeit cable I got was just a little too big to fit. I couldn’t use the plug on my GoldWing (may she rest in peace) or the plug in Adina’s car, because they were too big. This was the primary reason that I stopped using the bumper on my old phone, and got a more accommodating case which I didn’t like as much overall.

With the new bumpers, there’s a lot more room and they should work with a wider variety of dock cables. I really appreciate this change, even though I rarely use the plug in the Jetta anymore, and I don’t have the GoldWing. It’s still nice that I won’t have to remove the bumper to plug in if I happen to be using a slightly odd cable. In fact, I still have one of the old cables that locks in, and that didn’t work with the old bumper. It works just fine with the new one.

Our setup includes a Mac laptop for each of us, and an iMac for me. We each have an iPhone 4S, and we share an iPad. There are a few things you need to decide about your setup before you know how you want to proceed. Knowing some of the limitations of iCloud will help you decide that.

I'm assuming that you have some information you want to have the same as your spouse (address book, for example, and perhaps a shared calendar) and other information you don't (personal calendar, perhaps).

The easiest way to go about this in my experience is to have one iCloud account that you both share, and then individual iCloud accounts for each user. Here are my reasons (more or less):

1. We've been using the same address book for a long time. There appears to be no good way to share address books across users with iCloud, so we need a joint account for that.
2. We've been using individual calendars for a while, but syncing them to each other's computers via MobileMe so we can see each other's events. The problem is that we also get each other's notifications. With separate iCloud accounts, we can have our own calendar and share them with the other person. They can then set the shared calendar to not show notifications.
3. If you only have one iCloud account that's shared, you'll run into problems with other services like Find my Friends, so you'll need separate Apple IDs for those at the very least, so you may as well have separate iCloud accounts and have more flexibility.

When going about setting this up, I started running into little issues which were mostly related to what Apple makes available for primary iCloud accounts vs what they make available for secondary iCloud accounts. You'll have to think through this a little bit before you decide whether you want to use the shared iCloud account for the primary or the secondary.

1. On a Mac, Bookmarks, Photo Stream, Documents & Data, Back to My Mac, and Find My Mac are only available on the primary iCloud account.
2. On iOS, Photo Stream and Documents & Data are the only two that are only available on the primary account.

So I thought through some of this, and came down on the side of making our shared iCloud account the primary, and our individual accounts the secondary. What this means is:

1. We have to have one shared Photo Stream.
2. We have to have shared Documents & Data.
3. Back to My Mac and Find My Mac are all on one account.

We also put Find my iPhone on the shared account so we can find all the devices in one place.

I mostly went this route because I wanted a shared Photo Stream. If we went the route of having separate accounts, that might be nicer in some ways just between the phones and computers, but would start to get awkward when dealing with the one shared iPad. Also, having Back to My Mac on separate accounts would make it harder for me to snag a file off my wife's computer, although I'm usually on the home network with her laptop, so that's not necessarily a big deal.

The big Siri Gotcha

Now after all this, there's one thing that sneaked up and caused some pain. Siri wants to know who you are, so that it can tie relationships to your address book entry. If you are sharing an address book with your spouse, Siri will change this setting to be the same on both phones. After messing around for a bit, I figured out the only fix is to use a contact for Siri that is not in the shared address book. I did this by turning on address book syncing for the secondary iCloud accounts, which don't actually have any contacts in them other than our basic iCloud info. Then I used those contacts to set up Siri because those addresses are not shared between my wife and me.

Addendum

I'm starting to think there may be a little hitch in the near future with the way I've set this up. As more apps start using iCloud syncing, we could start running into conflicts with things like saved game data, which would be a problem, particularly for Plants vs. Zombies.

If you have any further questions about the setup, ping @fitzage on Twitter and I'll try to update the article accordingly.

Now it may not appear to be turned off at first because some apps don't pick up on it until after a relaunch or two, but this should do the trick.

Of course I actually want this feature for a select few apps. In fact, Safari is the only one I can think of right now. To re-enable this feature in Safari after turning it off for everything else, enter this command in the Terminal:

defaults write com.apple.Safari NSQuitAlwaysKeepsWindows -bool true

Anyone who eats food and has concerns about their weight or their heart needs to read one of these books by Gary Taubes.

Good Calories, Bad Calories is the book to read if you want the most data. The book gets much deeper into the research, and has a massive number of supporting endnotes. Why We Get Fat is kind of the executive summary, although the fact that it's newer means it does have a couple of studies included that weren't available for the first book. It also includes an appendix that has a recommended diet that comes from Duke University, which I don't think the first book had. It's a much shorter and easier read, but just gives the broad brush of the scientific and clinical research.

We know now that carbohydrates make us fat, and it’s been demonstrated in numerous clinical trials that low-carbohydrate, high-fat diets improve each and every one of the metabolic and hormonal abnormalities of metabolic syndrome—the low HDL, the high triglycerides, the small, dense LDL, the high blood pressure, and the insulin resistance and chronically elevated levels of insulin. This suggests the obvious: that the same carbohydrates that make us fat are the ones that cause metabolic syndrome. And it tells us that the best and perhaps only way to treat the condition, as with obesity and overweight, is to avoid carbohydrate-rich foods, particularly the ones we digest easily, and sugars.

Why We Get Fat, Page 198

People are often willing to accept the fact that low carbohydrate diets might be able to actually help you lose weight. The sticking point usually comes in when it's assumed that you may lose weight, but that your heart health will suffer because you're eating more fat in your diet. What these books show with their meticulous analysis of all available research, however, is that this is not the case. Not only do low carbohydrate, high fat diets help us lose weight, they also actually improve our heart health and help prevent other diseases like diabetes, and even cancer and dementia.

Recent studies that compare various diets have continued to support this data. The general results of the low carbohydrate, high fat diets compared to the more commonly recommended low fat, low calorie diets are as follows:

1. They lost at least as much weight, if not considerably more.
2. Their HDL cholesterol went up.
3. Their triglycerides went way down.
4. Their blood pressure went down.
5. Their total cholesterol remained about the same.
6. Their LDL cholesterol went up slightly.
7. Their risk of having a heart attack decreased significantly.

Why We Get Fat, Page 190

To get a little more specific, here is a chart of results from the "A to Z Weight Loss Study" published in The Journal of the American Medical Association in 2007. This study compared The Atkins diet (the poster child for low carb diets), a traditional semi-starvation diet known as the LEARN diet in which carbs make up more than half the calories, the Ornish diet which is an extremely low fat diet, and the Zone diet which has equal parts of fat and protein and a little more carbohydrates than either.

Why We Get Fat, Page 191

Hopefully this gives you enough information to want to want to find out more and read one of the books. If you want to have a healthy weight and a healthy heart, you need to cut out some carbs. How much and which carbs depends on your own specific genetic freakiness. You don't all have to be as extreme as I.

I’m not sure why it took so long to come to this realization, but I finally figured out the source of the problem: by default, vim saves a swap file in the same directory as the file you’re editing. This means that when you’re trying to do simple editing tasks with a file stored on a server and accessed via one of these methods, vim is making a lot more calls to the server than necessary because it’s trying to save actions to the swap file.

After a little searching, I discovered there is a very easy fix: tell vim to save the swap files somewhere else. There are a couple of ways to go about this:

If you just want to implement the change for the current session, you can just enter this command in vim (replacing .vimswap with whatever directory you actually want to use for this purpose):

  :set directory=~/.vimswap

The alternative is to add this to your config file if you want to do this all the time. You could add it to .vimrc or .gvimrc. Personally, I went with .gvimrc. The reason for this is that it only activates when I’m using the gui version of vim (MacVim in this case). This is handy because I use git to push my vim configs to certain servers, and I don’t want to use this setting when I’m making changes using vim on a server. Because I put the setting in .gvimrc, it won’t activate when I’m doing command-line editing on one of these servers.

  set directory=~/.vimswap

This should work just as well for people using vim and ExpanDrive on Windows.

Remember those erasable pens you could get back in the day? The Sharpie Pencil is just as lousy as that, except it erases better.

The quality of the writing is worse than the average low-quality ball point pen. Do yourself a favor and skip this one. If you need something erasable, use a pencil.

This is a little guide to help you find what is making those processes run and kill them.

First, for those of you who may not be as familiar with Mac/Unix conventions, I’ll explain how I’ll be referring to these. I’ll give you file paths in the format of either ~/path/to/folder or /path/to/folder. If the ~ is in front, that means this is in your user folder (the one that shows up with a little house in the Finder sidebar) and if it doesn’t have a ~ in front than the path starts from the root level of your hard drive. So, for example, there is a ~/Library folder, which is the Library folder in your User folder, and there is a /Library folder, which is the system level Library folder. There’s even a /System/Library folder, which is the really low-level system Library.

First, it may be helpful to know where the items in that System Preferences panel are stored: ~/Library/Preferences/loginwindow.plist. Deleting this won’t usually get you anywhere, as anything in there can just be removed from System Preferences.

The first “hidden” place to look is in ~/Library/LaunchAgents. While writing this tutorial, I found a couple of things in there that were ancient that I didn’t want any more. You can just delete any items you don’t want running (although use discretion, as you don’t want to break anything). These are all in the format of com.apple.somethingorother, where the first two parts correspond to the domain name of the company that wrote the program, generally. So you can use this as a guide: if it starts with com.apple, you probably don’t want to delete it. Also, if you have Adobe software installed, and see anything that starts with com.adobe, you probably don’t want to delete that either. You get the idea.

The second “hidden” place to look is in /Library/LaunchAgents (see a pattern here?). These follow the same basic pattern as the one in the user folder, but are going to run in any user account on the computer. In fact, some things that you don’t want running system wide can safely be moved from here to your user folder. If you have any input managers running that rely on SIMBL, you’ll see something here for SIMBL. If you’ve installed any in the past but no longer use them, you will see the SIMBL agent and can delete it. I installed glims recently, which uses SIMBL and has its own file in this folder. Since I don’t want glims running in all user accounts, I can move the launch agent to the ~/Library/LaunchAgents folder instead. This will require at the very least a logout and login to run it from the new location, and that assumes that Glims won’t try to put itself back.

The third place is /Library/LaunchDaemons. These are very similar to the ones above, but I wouldn’t recommend deleting any of them. Basically the difference is that items in LaunchDaemons are system wide (which may mean they run even if no user is logged in) and the items in LaunchAgents are user related (like glims will only run if a user is logged in, but in the default location it will run if any user is logged in).

The fourth place is /Library/StartupItems. Not as many programs use this, but some do. I just deleted a VirtualBox item from here, because I hadn’t used it since the day I installed it.

If these locations don’t solve your problems, you can get into the dangerous ones: /System/Library/LaunchAgents, /System/Library/LaunchDaemons, and /System/Library/StartupItems

These are ones that third party apps aren’t supposed to use, so if you look at them you’ll notice everything in there is likely to start with com.apple or be related to underlying Unix apps. You most likely don’t want to mess with anything in these folders, but if you do see something that shouldn’t be there and it corresponds to a process that is running that shouldn’t be, then kill it.

Lately, I’ve had lots of packages shipped to me via USPS, either from Amazon, Amazon resellers, or other websites. Here are some observations I have:

 
1. USPS package tracking used to be a complete joke. Lately, however, I’ve been pleased with the tracking. It’s not as granular as FedEx and UPS, so you don’t see things like every time it shows up at a facility and leaves, but you do get basic information about how it’s moving. Usually it’s slightly delayed, but it gives you enough information to keep you up to date. I know that I’m going to get it today when I see that it’s been processed through a sort facility in Tucson, even if it doesn’t show as “out for delivery” yet.
 
2. It’s fast. Most of the items are sent Priority Mail, and it shows up just when I’d expect it to. It takes a lot less time to get here from the East Coast than UPS Ground does.
 
3. It’s cheap. From Amazon, I have prime shipping so I never really see the shipping costs associated with my orders. Most of the things I’ve received recently from other places are small enough that they fit well within the cheap Priority Mail range, and are cheaper than UPS Ground would be for the same thing.
   
   When we were in Illinois, my wife realized she hadn’t brought enough of her prescription drugs with her, so we had the dog sitter send us some. Express Mail showed up the next morning for $10. The cheapest (afternoon delivery) option with UPS or FedEx was at least $40.
 
4. It’s reliable. I don’t really have reliability issues with any other carrier either, but USPS has been top notch in this area for me in recent history.

The biggest downside of both UPS and USPS is they don’t have the friendly driver that FedEx does. He’s awesome.

Edit: I guess it was closer to $20 for the express mail package. But still.

Most of the scuttlebutt on the internet seems to be against this change. Personally, I love it.

Much of the backlash is about personal preference, but some of it involves significant misunderstandings. Even Ars Technica had some major misinformation in their post on the subject.

First, I'll address what Ars says about it not muting anything (later adjusting it to saying it just mutes notification sounds). Just like the iPhone it mutes two things:

1. Notification Sounds
2. Game Sounds

The muting of game sounds is no big deal, because you could already easily mute the volume of the entire iPad while using it.

The muting of notification sounds is actually quite useful, however. Now you can listen to music or watch a video without notification sounds being annoying. Before it was all or nothing. When it comes to video, the only thing this really affects is email notifications, since most other push notifications will pop something up on screen interrupting you anyway. With music it's more useful because you may be plugged into speakers or headphones and not be actively looking at the screen all the time, so push notifications won't affect you at all once the mute switch is toggled.

The biggest advantage to me, though, is that I can now mute the iPad without waking it up and typing in my passcode. Previously, I would often go to bed and set the iPad on the bedside table. Then I'd realize I hadn't muted it and I'd have to wake it up to do so. Now I flip a switch. I never had a need to lock and unlock screen rotation while the iPad was sleeping.

At first I thought it was just me and Steve Jobs who preferred it this way, until a friend of mine who also has an iPad was using mine the other day and discovered the mute switch change. She was quite jealous, so I guess there are more of us.