Holding a Twitter Contest: Lessons Learned

Posted by Sheldon Finlay on January 11, 2010

twitter_logo_headerI recently held a Twitter contest for a popular how to knit web site and while the contest was good, I did learn some things along the way which I would like to share.

  1. Make your contest short – Twitter buzz is pretty short-lived. Attention spans wane. One week is the maximum I’d recommend running a contest, unless you think your contest is so exciting it will sustain a longer level of excitement. Your contest will most likely peak after a day or two. If you are giving away a MacBook or Canon 5D, you contest might be an exception. If you are giving away T-Shirts and bumper stickers, stick to a few days.
  2. Have multiple prizes – They don’t all have to be grand prizes. Maybe a handful of consolation prizes, free accounts, t-shirts, whatever. The multiple prizes will appeal to folks and make them more likely to jump into your contest since they have a greater chance to win something cool.
  3. Have people tweet a  message - Create a concise message which advertises your Twitter contest and make it a requirement that folks tweet it. Include a link (shortened of course) to the contest so others will be able to find your contest and join in.
  4. Have people follow you – You want to get followers don’t you? This should be a no-brainer.
  5. Don’t post about your contest like a manic squirrel – People will get tired of you if you are promoting your contest every hour. Find creative ways to give updates on your contest which also double as promotion. For example “Wow, we have had 1,200 people sign up for our contest. If you haven’t signed up there is still time *link*”. Done re-use the same line either, people will catch on.
  6. Use a hashtag – Add a hashtag to your contest message. You want to choose something fairly unique, so go off to search.twitter.com and search to make sure it’s not already being used.
  7. Harvest your contest entrants - You will want to collect your contest entrants and not rely on search.twitter.com to store them for you. Search.twitter.com only goes back about a week and isn’t always reliable. If you are not saving your entrants in some way, you will likely lose some of them. Disenfranchising your contestants isn’t cool man.
  8. Create a script to query Search.twitter.com – I created a small Ruby script to regularly query the search.twitter.com and stick the entrants usernames a database. This way I always ensure I had a list of all contest entries. The script I created took advantage of the Twitter gem and would search for the hashtag and then look to make sure the tweet matched the contest message. The more you automate, the better.
  9. Don’t encourage re-Tweets – This is against Twitter’s contest guidelines and will make Twitter mad and possible show the fail whale. For our contest we just did one entry per twitter user. Some people retweeted and that’s fine. But don’t make it a “whomever tweets this the most wins” contest.
  10. Follow up quickly with winners – Announce and congratulate them on Twitter, post them on your site, and contact them by DM as soon as the contest has ended. Don’t leave your contestants in the dark.
  11. Be prepared for a follower bounce back – Some of your followers who joined for the contest will abandon you as soon as they find out they didn’t win. It’s ok, they were not really into you, they just wanted to win free schwag. You are better off. Get over it already.

Fixing ld: warning: in /usr/local/lib/libz.dylib, file is not of required architecture 4

Posted by Sheldon Finlay on January 08, 2010

I banged my head on this stupid problem for months. It all came about after upgrading my Macbook from Leopard to Snow Leopard (OSX 1.6). I was plagued with this error here and there when I wanted to compile certain software (namely imagemagick and mysql) or install certain native Ruby gem. It was a nightmare, but it seemed I would have to live with it, until I could find the time to reinstall Snow Leopard from scratch.

Google reveals very little useful information for dealing with this error. Everyone seems to have the problem, and yet fixes seem quite elusive. I finally hit upon a fix that worked for me and I’ll share it here in case the solution also works for others. First thing you’ll want to do is install xCode, the developer SDK from Apple. Download the most recent version from the Apple Developer site, as the version on disk might be old. You’ll need the OSX 10.6 libraries. After xcode is installed go to the directory that the problemed libz.dylib file is found and rename it so you have a backup in case things get messed up worse and you need to restore it:

cd /usr/local/lib/libz.dylib
sudo mv libz.dylib libz.dylib.original

Now, when you installed xCode it should have also installed a recent version of libz.dylib in among the SDK files. So the next step is to copy that version of the file to replace the file we just renamed.

sudo cp -rf /Developer/SDKs/MacOSX10.6.sdk/usr/lib/libz.dylib .

That’s it. Go ahead and try to install that pesky ruby gem (rmagick) that wasn’t installing or compile ImageMagick. If you are lucky like me, it should work. I hope this saves some folks a lot of hair pulling. Let me know how it goes!

This may also work for some other dylib files that are problematic such as libexpat.dylib. Just take a look in the lib directory of the OSX 10.6 SDK and see if the file exists. Remember to things up before replacing swapping in the new files.