The utility of a URL shortener

I've setup Twitter Tools to post links to my blog posts to Twitter and that's been working well. I did this as one of my friends doesn't subscribe to my RSS feed, but likes to read my posts. He is a frequent Twitter user, so this solution works well. Since I haven't been using a URL shortener, some of my posts don't make it to Twitter as the URL and title make the post over the Twitter limit of 140 characters. The other day, I decided to see about solving this.

There are a number of URL shortening services out there, but I kind of have a problem relying on a third party for the service. Also, one of the most popular one, bitly, is under a Libyan top level domain. I found YOURLS the other day and set it up. It was pretty easy to setup and I picked a subdomain for easy management. The Wordpress Plugin for it kept creating extra links and that kind of annoyed me. I found that someone created a Twitter Tools plugin to work with YOURLS. I tested it and it worked perfectly.

So, now all my posts to Twitter are using my own URL shortener. The URL shortener is pretty maintenance free and easy to setup, so as long as I have my blog around, I think I can keep this running.

Struggling with Distributed Version Control Systems, e.g. git

I've been using subversion for version control on just about all my projects for years, whether they were my own projects or for clients. It worked well and I got very used to it. Recently I've been put on projects that use distributed version control systems and have also been working on some open source projects that use it as well. Several of my projects use Mercurial, but most are using git.

As my work on the Mercurial projects has been quite limited, I've fumbled my way through using it without really learning about it. MacHg has been good enough for me to work on the projects. However, one of my projects relies heavily on git, so I've been trying to learn it. I've read a number of tutorials, watched videos, read through Pro Git twice, and still don't feel comfortable with it. After talking with some other developers, I'm not alone in being lost with git.

I consider myself a fairly intelligent person that can learn new technologies. I'm not sure why it has been so hard for me to learn git, but I'm starting to see some of the benefits of it. Another developer I work with has cursed git because he just wanted to look through a snapshot of a source tree, but with a distributed version control system, he had to download the entire repository in order to browse the code (he didn't have access to export the source without the rest of the repository). When he first told me about this, I completely agreed with him on how ridiculous this aspect was, but the more I read (read the same material, that is), the more I'm starting to get how powerful git is.

While git is quite powerful, it is going to require me to change my workflow as git seems to encourage creating branches for every little thing. Branching code, to me, has always been avoided as it was a royal pain and merging was unpleasant. Merging can still be unpleasant with git, but everything I've read seems to indicate it is painless. We shall see.

I wasn't until I found the Git Reference website that the pieces started to make sense. I'm not sure why every other tutorial doesn't make things this clear. Maybe this should be everyone's starting point in learning git.

I'm comfortable with command line tools, but prefer a GUI if at all possible. With subversion, I used to use Versions, but switched to Cornerstone after I tried it and found that it showed diffs right in the app without requiring an external application. Now that I'm using git, there are a number of GUI tools for it, but I've found that Tower is the only git app out there for the Mac that currently has diffs right in the app, so that's my app of choice. There are some things I don't like about it, for instance I like a list of repositories on the left side. However, it's helping me become more comfortable with git.

Maybe I need to write an idiot's guide to git. If a reasonably good developer like me is struggling with git, how can it become widely adopted? Is it that other developers aren't as entrenched in subversion as I? I kind of feel like I'm missing something in how much time I've spent in trying to learn git.

Suggestions for the TSA

I've ranted a number of times about the TSA, so I've decided to offer the TSA some suggestions on how to handle airport security. I ask for nothing in return, even though I'm sure my ideas would be worth millions if I was contracted to do an overhaul of it.

In no particular order:

• Redeploy military personnel to patrol the airports with M-16 machine guns. The wars overseas are not winnable, so put the soldiers in our all volunteer military (not the national guard troops) to work at the airports. The machine guns and troops in fatigues is at a minimum an excellent deterrent. Having flown within the months after 9/11, it was almost comforting to see the military there. The TSA officers at the checkpoints are not very menacing and aren't even armed.
• Bring in bomb sniffing dogs. They'll likely be able to detect explosives more efficiently than the full body scanners or the random swap testing. In addition, if someone is nervous, dogs will make them even more nervous.
• Profile people. This seems obvious, but train personnel to be more observant and watch people that fit certain profiles.
• Watch behaviors. Train all the personnel to watch passengers' behaviors.
• Get rid of the full body scanners. They're a waste of time and money. Return them and get our taxpayer money back.
• Stop the 3-1-1 rule for liquids. Confiscating a bottle of hair spray is ridiculous.
• Do the full body pat downs on people that show signs of being uncomfortable or are acting in a way out of the ordinary; don't do a full pat down on a child that doesn't fit a profile.
• Stop confiscating nail clippers, nail files, etc. If you can get a knife inside of security like I had used for dinner last week, nail clippers aren't going to hurt anyone. Also, look at maintenance workers that have all kinds of tools that could be used as weapons.
• Tighten up perimeter security. There was a story the other day about a castaway in a wheel well that got onto the tarmac.

There are a few things that I don't mind that have been done:

• Reinforcing the cabin doors.
• Prohibiting lines from forming outside the cabin door.
• Taking off shoes; while a little inconvenient, I can handle it.

Let's get real TSA and start being smarter about how the billions of dollars are being spent. The costs can be cut tremendously if we didn't waste it on useless screening techniques.

Storing User Data in Application Support

I recently switched to a new MacBook Pro and decided to piecemeal move my data over so that I wouldn't bring over old crusty preferences and files like that. This has worked quite well, but in two cases today, I found that some user data was stored in the Application Support folder. Since I hadn't copied this directory over, when I ran the apps, I had no data and had to dig through an old Time Machine backup to find the data. To make matters worse, I'm storing my personal data on an encrypted disc image and in order to get the apps to run, I had to create a symbolic link to my disc image's directory that contains the data.

Apple explicitly states in the developer documentation that the Application Support directory:

Contains application-specific data and support files such as third-party plug-ins, helper applications, templates, and extra resources that are used by the application but not required for it to operate. This directory should never contain any kind of user data. By convention, all of these items should be put in a subdirectory named after the application. For example, third-party resources for the application MyApp would go in Application Support/MyApp/. Note that required resources should go inside the application bundle itself.

In ReceiptWallet 1.0, I made this mistake for ease of use and stored user data in this directory, but when I moved to a document based app, I rectified this issue.

Developers, please read Apple docs and store user data in a user defined location or in Documents; Application Support is the wrong location for this data.