There are lots of ways bad things can happen to your computer and your online accounts, but if you use weak passwords, you’re increasing the risk that something bad will eventually happen to you. There are lots of articles about what makes a strong password, but I want to tell you how to create a strong password that’s easy for you to remember. If you have to write down your strong passwords, then you probably haven’t accomplished much.

If you read the Wikipedia article above, you’ll see that one recommendation is that passwords should be 12-14 characters long. If you’re like most of us, creating a password of that length that includes numbers, letters and special characters can seem daunting. Let me share some tricks I’ve learned in the past decade or so that I’ve been working online.

First of all, passwords containing any part of your birthday or anniversary are usually a bad idea. Especially if that information is displayed in your account online (Facebook). Also passwords that contain your spouse’s name, your kids names, etc. aren’t going to be too tricky in this world of social networking.

So, what do you choose? My favorite method right now is using songs, poems or other text you have memorized in the course of your lifetime to create a long, but easy-to-remember password.

Here’s how it works.

1. Choose your text. For the example, I’m going to use the first line of the Gettysburg address, “Four score and seven years ago our fathers brought forth, upon this continent, a new nation, conceived in Liberty, and dedicated to the proposition that all men are created equal.”
2. Now reduce this to just the first 14 words as such: “Four score and seven years ago our fathers brought forth, upon this continent”
3. Now just use the first letter of each word with proper capitalization and punctuation and you suddenly have a very good password: ‘Fsasyaofbf,utc’.

Notice that the password contains uppercase and lowercase letters and one special character, a comma. Yes, keep the comma in the password. You could also substitute the actual numbers into the text as such: ‘4sa7yaofbf,utc’. Now the password contains numbers, letters and special characters. If you just look at the password it appears completely random, but it’s so easy to remember.

The same thing applies to songs. Perhaps you’re a fan of Sean Kingston, so you choose the chorus of “Fire Burning” which is “Somebody call 911 Shawty fire burning on the dance floor…” Your new password is ‘Sc911Sfbotdf’.

If you’re a Bible reader, you have many, many ways to create complex passwords. For example you may include the scriptural reference in addition to a portion of the referenced passage. You might choose John 3:16, “For God so loved the world, that he gave his only begotten Son…” to create the password, ‘J3:16FGsltw,thghobS’. That one is 19 characters long, contains uppercase and lowercase letters, numbers and two special characters, but it’s amazingly simple to remember.

Using this technique, you can also create a set of strong passwords that you can use on different sites. Perhaps you associate the first letter of the site name with an author, scripture or recording artist/song. Twitter then becomes related to Thoreau or Thessalonians or Til Tuesday, while Facebook is related to Faulkner or First Timothy or Fatboy Slim.

My best recommendation is to start right away with at least one strong password. Get rid of your 4-6 character passwords. Get rid of your birthday or name-based passwords. Pick something that you’ve already memorized and make a password that really works.

Last note: Unfortunately not all web sites allow you to be completely creative with your passwords. Some sites don’t allow special characters. Other’s set limits on the length of a password. Hopefully that will change soon, but until then, you might have to tweak some of your choice to fit some of the sites you use. Don’t let that discourage you from using better passwords on the sites that allow it.

function makeAWSUrl($parameters, $associate_tag, $access_key, $secret_key, $aws_version = '2009-06-01') {
  $host = 'ecs.amazonaws.com';
  $path = '/onca/xml';
 
  $query = array(        
    'Service' => 'AWSECommerceService',
    'AWSAccessKeyId' => $access_key,
    'AssociateTag' => $associate_tag,
    'Timestamp' => gmdate('Y-m-d\TH:i:s\Z'),
    'Version' => $aws_version,
  );
 
  // Merge in any options that were passed in
  if (is_array($parameters)) {
    $query = array_merge($query, $parameters);
   }
 
  // Do a case-insensitive, natural order sort on the array keys.
  ksort($query);
 
  // create the signable string
  $temp = array();
  foreach ($query as $k => $v) {
    $temp[] = str_replace('%7E', '~', rawurlencode($k)) . '=' . str_replace('%7E', '~', rawurlencode($v));
  }
  $signable = implode('&', $temp);
 
  $stringToSign = "GET\n$host\n$path\n$signable";
 
  // Hash the AWS secret key and generate a signature for the request.
  $hex_str = hash_hmac('sha256', $stringToSign, $secret_key);
  $raw = '';
  for ($i = 0; $i < strlen($hex_str); $i += 2) {
    $raw .= chr(hexdec(substr($hex_str, $i, 2)));
  }
 
  $query['Signature'] = base64_encode($raw);
  ksort($query);
 
  $temp = array();
  foreach ($query as $k => $v) {
    $temp[] = rawurlencode($k) . '=' . rawurlencode($v);
  }
  $final = implode('&', $temp);
 
  return 'http://' . $host . $path . '?' . $final;
}

Using the function is simple. The first parameter is a PHP array of AWS parameters, the others are standard associate tags and keys. Here’s an example:

$url = makeAWSUrl(array('Keywords' => 'Jaco Pastorius',                           
                      'Operation' => 'ItemSearch',                          
                      'ResponseGroup' => 'Medium',                           
                      'SearchIndex' => 'Music',                           
                      'salesrank' => 'Bestselling'),  
  'YOUR_ASSOC_TAG', 'YOUR_ACCESS_KEY', 'YOUR_SECRET_KEY');

The result of the above call (using my tags and keys) is:

http://ecs.amazonaws.com/onca/xml?AWSAccessKeyId=[MYKEY]&AssociateTag=blakesblogand-20&Keywords=Jaco%20Pastorius&Operation=ItemSearch&ResponseGroup=Medium&SearchIndex=Music&Service=AWSECommerceService&Signature=qZ%2BheDqfZi79b2Xg0JSP2kgG2FgQn823GLn0m1sVmnM%3D&Timestamp=2009-08-19T22%3A53%3A29Z&Version=2009-06-01&salesrank=Bestselling

As always, give me some feedback, take the code and make it better. Share it and include it in your libraries … have fun!

Fortunately Komodo also provides a simple method for creating extensions within the IDE itself, so I gave it a try. Within a few hours I was able to build an extension to do exactly what I needed and configure it on a per-project basis. I’ve made the extension available as an MIT-licensed, open-source project. As always, this project is included on the open source tools page.

Yesterday he released the plugin as an open source project. I haven’t had a chance to install the plugin, but having worked with Aaron in the past, I’m sure it’s top notch. I looked at the source code and really like the way he developed the integration with WordPress.

If you’re interested in adding Facebook comments to your WordPress blog, I suggest you give Aaron’s plugin a try. I’ve included this plugin on my open source tools page.

So, yesterday’s announcement by the Facebook development team about fql.multiquery couldn’t have come at a better time for me. Experienced web developers (and multi-tiered application developers in general) have all learned that performing work in the proper tier is always the most efficient way to work. Data should be managed in the database tier and as separately from the application tier as possible. This announcement from the Facebook development team is great news for Facebook application developers everywhere. Kudos to them!

In addition to being a fantastic piece of technology by itself, APC also provides meaningful tuning options and detailed statistics. The screen shot here shows just a fraction of the information collected by APC.

So far, my experience with APC has been very positive, but don’t take my word for it. Check out some of the performance results: here, here and here.

As always, tuning to a particular application or server is critical. Be sure to read the manual!

I’m happy to say that despite the missing features, this browser is absolutely amazing on Ubuntu. It’s lightning fast and very stable. I can’t browse to pages that require HTTP AUTH — but that’s the only thing I’ve found that I didn’t notice in the limitations documentation.

Unfortunately Firefox on Ubuntu is not great, so I’m hoping that soon Chrome will be my browser of choice. Or I could just get a Mac.

My solution is not enterprise and it’s not real time, but it will let me know in a reasonable amount of time (Montastic says it checks every 10 minutes or so, based on load). For me, that’s good enough right now because I mostly want to avoid overnight and weekend-long outages that may occur when I’m not checking my computer regularly.

The first step is to sign up at Montastic and set up a monitor for your web site. There’s no learning curve there … just register, type in a URL and Montastic will start monitoring right away. There’s a video screen cast available showing how easy it is to use. After setting up the monitors, Montastic provides a basic RSS feed — that’s where Yahoo! Pipes comes in.

Yahoo! Pipes Configuration for Montastic

The final step I took was to simply run the pipe, then tell Yahoo! to send me the output of the pipe to my cell phone whenever it changes. Since the pipe updates when there is a new failure item, I won’t get an SMS message every time Montastic checks the servers, but only when there is a new failure item.

I haven’t been running this solution for very long, but so far it looks to be a promising concept for keeping an eye on my servers — particularly when I’m going to be away for a while. I’d love to hear ideas about other ways to use Montastic or suggestions for other free website monitoring tools. What do you use?

TwttrList is deeply integrated with the Twitter API, taking advantage of the search, timeline, status, and favorites interfaces. Because of the timing of our release relative to the release, subsequent unrelease and re-release of OAuth for Twitter, we built almost all of the API requests to support both OAuth and username/password. The code for any Twitter request looks like this (slightly simplified):

/**
 * Return favorite tweets list for user specified by OAuth or user/pass.
 *   doc: http://apiwiki.twitter.com/Twitter-REST-API-Method%3A-favorites
 *
 * @param MemberTwitterData object
 * @return list of favorites or null
 */
public static function getUserFavorites($client_twitter_data, $page = 1) {
  $cache_key = internal_hash($client_twitter_data, ...);
  if ($res = ApplicationHelper::memcacheGet($cache_key)) {
    if ($res == 'none') {
      return null;
    } else {
      return $res;
    }
  }
   if (!self::$use_oauth) {
    $curl_options = array(CURLOPT_POST => 0,
                          CURLOPT_HTTPHEADER => array('Expect:'),
                          CURLOPT_USERPWD => $client_twitter_data->screen_name . ':' . $client_twitter_data->twitter_password);
 
    $results = ApplicationHelper::rest_connect('https://twitter.com/favorites.json', ...,  $curl_options);
    if ($results === false) {
      $results = null;
    }
  } else {
    $oauth = new TwitterOAuth(self::$app_token, self::$app_secret, $client_twitter_data->oauth_token, $client_twitter_data->oauth_secret);
    $results = $oauth->OAuthRequest('https://twitter.com/favorites.json', array('page' => $page), 'GET');
    if ($oauth->lastStatusCode() != 200) {
      $results = null;
    }
  }
 
  if ($results) {
    $results = json_decode($results);
    ApplicationHelper::memcacheSet($cache_key, $results, ...); 
  } else {
    ApplicationHelper::memcacheSet($cache_key, 'none', ...); 
  }
 
  return $results;
}

The Twitter OAuth library I chose is the one provided by Abraham Williams and despite the warnings in the comments about not using the library in production code, I found the library to be very stable and usable.

With this structure in place, we were able to switch between using OAuth and Twitter usernames/passwords by simply setting a single boolean value in the Twitter helper class. With the boolean use_oauth set to false, the authentication popup screen we developed displays a username/password form. When true, the popup screen goes through the actual OAuth process. Switching mid-stream is possible as well because each time authentication is required we can simply re-request the new user credentials.

TwttrList obviously uses a lot of request caching. We cache everything we possibly can using timeouts for each type of data based on our best judgment. Search requests are cached for a shorter time than user favorites, for example.

The final large coding piece was to develop a reusable Javascript class to provide consistent display and AJAX functionality on all the pages that are involved in the TwttrList lens display. This class is mostly agnostic to any framework (jQuery, Prototype) because Squidoo is transitioning between frameworks at the moment. The JS for TwttrList is lightweight and very reusable.

The real magic of TwttrList is in its usability, concept and design which is a group effort by the whole Squidoo team. It takes a village to create a great software application and I’m part of one of the best villages around. The creative elements of the design and the constant attention to usability details throughout the application make TwttrList something more than just the nuts and bolts of the code.

Take a look at TwttrList today and let me know what you think. I’d love to answer questions about the implementation (within reason), so ask away!