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.

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!

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.

Memcache is just exactly what it says it is — a memory cache daemon (service). It’s lightweight and very fast and can be used for all kinds of caching: page, database, remote data, etc., etc.

I use it on this blog in conjunction with fetching the Twitter comments that appear in the right-hand sidebar on the home page, for example. Here’s the general pseudo code for how memcache is used:

  key = generate_cache_key()
  if (value = is_key_in_cache(key))
    return value
  get_uncached_value() // DB, REST, complex code, etc.
  save_to_cache(key, value)

My actual implementation for the Twitter backtweets looks something like this:

$uri = 'http://backtweets.com/search.json?q=www.thewhyandthehow.com&key=API-KEY';
$cache_key = 'rest-service-' . md5($uri);
if ($result = Helpers::cacheGet($cache_key)) {  
  return $result;
}
 
$result = Helpers::remoteLoad($uri);
// check valid $result here
 
Helpers::cacheSet($cache_key, $result, 20, true);
return $result;

The helper functions look like this (class declaration not shown for brevity):

    public static function getCache() {
      if (self::$cache == null) {
         $temp = new Memcache();
         $temp->connect(MEMCACHE_HOST, MEMCACHE_PORT);
 
         self::$cache = $temp;
      }
 
      return self::$cache;
    }
 
    /**
     * set a value to the memcache
     *
     * @param string key name
     * @param mixed value
     * @param integer timeout (default 1 day)
     * @param boolean compression flag
     * @return boolean success
     */
    public static function cacheSet($key, $value, $timeout = 86400, $compress = true) {
      $cache = self::getCache();
      $result = false;
 
      if ($timeout > 0) {
        $timeout = min($timeout, 2592000);
      }
 
      if ($compress) {
        $result = $cache->set($key, $value, MEMCACHE_COMPRESSED, $timeout);
      } else {
        $result = $cache->set($key, $value, 0, $timeout);
      }
 
    /**
     * get an item from the cache
     *
     * @param string key
     * @return mixed value or false
     */
    public static function cacheGet($key) {
      $cache = self::getCache();
      return $cache->get($key);
    }

As you can see the code is very simple. The cacheGet function is trivial, so no discussion is needed. The cacheSet function is a little more complex, but basically that is to support a very simple calling convention and to ensure that the parameters are sane. One obviously missing check is to ensure that the Memcache variable returned by getCache is valid — I guess I have some work to do.

The advantage for using caching in this manner should be obvious. Instead of requiring an actual HTTP request per pageview, this method keeps a copy around for 20 minutes before initiating another request to the backtweets.com servers. This is friendly to the remote servers while also increasing the responsiveness of my application.

This logic applies to any big, slow or heavy processes that might occur on a web server, not just remote HTTP requests. If your application generates lots of mostly-static HTML markup that is re-used or requested frequently, it could be cached in memcache. If you have any big or frequently-requested database queries, throw the results in memcache and take the load off of your DB server.

AND…

Since memcache is based on TCP/IP, it doesn’t have to run locally relative to your application server. Have one big memcache box, or two, or three, and make requests from all of your application servers.

If your application is falling over because of load, you might want to take a look at the problem spots. You’ll probably find that using memcache will reduce overall load on your database and application servers and increase the responsiveness of your site.

This is not a new concept, but with the recent proliferation of high-profile services such as Twitter OAuth and Facebook Connect, I think it’s time to discuss the pros and cons of using a third-party authentication system for your web site.

Pros

One of the most obvious advantages of using any third-party authentication system including OpenID is that you don’t have to develop the complex systems necessary to validate user registrations, avoid duplicate or spam registrations or manage all of the registration messaging and support. That’s a big deal. If your registration system is too complex because you are trying to ensure that only legitimate users can register, you will undoubtedly lose some potential users who simply find the system too hard to use. Tying into established accounts reduces the barriers to entry for your site.

Another consideration for using a third-party authentication system is the additional features of the third-party service. If you intend to update the user’s Facebook or Twitter status, you’ll eventually need to authorize your user with that service. You may be able to address two needs at one time.

Finally, there is a soft benefit to using a third-party authentication system and that is the added trust. It’s likely that if you use a trusted system or service, your own web site will be implicitly trusted more.

Cons

Using a third-party system does not remove the necessity to keep some user information in a local database or provide some session and cookie management functions. Your web site will probably require additional user information that is not provided by any of the third-party services. Depending on how much of that information is required, using a third-party service may simply add another step to the registration process — increasing the barriers to entry.

Many third-party applications are still evolving. Twitter’s OAuth has only been available for about a month. Facebook Connect is less than a year old and has changed quite drastically (for the better) since its release. OpenID is much more mature as a development tool, but adoption in the user world is still relatively low.

Gotchas

Some things to think about — things that may be pros or cons depending on how your site works with the third-party services.

An advantage of using a third-party for authentication is the fact that there are many to choose from (Twitter, Facebook Connect, OpenID, etc.) so many of your users will already have established accounts with the other sites. But what do you do if your potential user is not connected with any of the third-party sites you use? Consider your audience before committing to a third-party-only authentication solution. If your audience is the bleeding edge web community or if your service is an add-on to the third-party service, you’re golden. Otherwise you may alienate potential users who don’t have and don’t want to be a part of the Twitter-Facebook-etc crowd.

What happens to your users if they decide to leave the third-party site or are banned from using it in the future? People do stop using Facebook, Twitter and other services. People close their GMail accounts (Google provides third-party authentication) and occasionally people are banned from other sites for violations of terms. If your site is not directly related to the third-party site (for example a Twitter search site would be directly related to Twitter), you probably want to make sure that your users can login on your site whether they have an active account anywhere else.

What to do?

I suggest that most sites still need to have a local user login system of some sort. This is to ensure that your users remain your users. Users will not understand or care to know why they can no longer access your site after canceling their Facebook account, they’ll just know that you’ve excluded them and they’ll be upset. No amount of technical mumbo-jumbo will convince them otherwise.

I do encourage the use of third-party authentication systems to add value to your site. There are several reasons to do this:

• Providing additional value-added connections to the third-party services such as updating profile information or status
• Providing social graph information such as which friends of the current user also use your site
• Gathering additional authentication information for your site

Recommendations

Build a simple login system for your site. Limit the amount of information you gather to the absolute minimum you need to provide basic login/account services. This should include a user identifier, password and some method for recovering a lost password. Consider this your first tier of authentication. First-tier users get read access to all of your site and some level of personalization based on their account information.

Next, if your site allows publishing of any information, add a second level of authentication. Since your first-tier users didn’t do anything to prove they aren’t bad robots, they don’t get to publish. This is where you can get creative. Second-tier authentication may be via email (not my preference) or via a third-party authentication system. Choose a third-party that you trust, then have your users authenticate themselves with that third-party and record the authorization information in your user database. Consider the user a second-tier user at that point and enable additional options and services on your site.

The advantages of this tiered approach are many.

• You maintain a local database of users
• You can provide as many tiers of trust as you need with different authentication methods as seem appropriate
• You can provide alternate authentication methods for each tier so your users have many options to authenticate
• If any one of the third-party authentication services disappears or revokes access to a user or group of users, you can provide an alternate method
• You reduce the barriers to entry to your web site
• Your users only encounter authentication barriers as they seek to increase their interaction with your site

Perhaps at some point in the future, OpenID and OAuth or some new thing will be truly ubiquitous and provide all of the features required for completely hands-off authentication services, but right now I don’t think we’re there. Until then, consider a tiered authentication system that provides the best options for you, your site and your users.

The Javascript method works well, but it’s a little inconvenient when I’m copying and pasting several addresses, the JS code and the resulting geolocations in one session. Today I was doing this again and it struck me how convenient it would be to have a browser button that would do what the Javascript does. So I set that up.

In Firefox, I simply added a custom bookmark to my Bookmarks toolbar (View, Toolbars, Bookmark Toolbars). To do this, assuming the Bookmark toolbar is visible, right click (or control click for Mac users) on it and select New Bookmark. In the properties box, enter this Javascript into the location field:

javascript:void(prompt('',gApplication.getMap().getCenter()));

Now you have a button that will display the latitude and longitude of the current map (on the Google maps site) in a convenient Javascript prompt box. Like I said, this isn’t going to change your life, but it might save you a few cycles … and that’s worth something.

Mark Twain

I recently took down a pool fence. It required cutting sections of steel fencing, removing rusty nuts from large bolts in the ground and walls, and cutting bolts. I had been delaying this job for a long time because I’m not a handyman and I don’t have many tools. I had to buy a new wrench and I had to find something to cut the bolts and the fence. Fortunately, my neighbor had the cutting tool and was willing to let me borrow it. As I spent the better part of Saturday afternoon working, I couldn’t help but think about the saying, “To a man with a hammer, everything looks like a nail.”

I’ve worked with a lot of programmers and programmer types in my career and I’ve found that there are many who have a single tool in their box. It may be a programming language or it may be a toolkit or it may be an application that can be scripted or customized with macros. For those people, the solution to every problem is always considered from the point of view of their favorite tool. The best software developers, however, have a rich set of tools and a mindset to approach solutions from multiple perspectives. Sometimes the solution is based on a toolkit or application. Sometimes it’s best served by writing a new application in a high-level programming language. Sometimes it requires working at the database level with triggers or stored procedures.

When presented with a problem, the best developers don’t rush to their toolbox. Instead, the best programmers identify the scope of the problem, consider several options and ask colleagues for input — perhaps borrowing the right tool — before developing a solution.

It’s an amazingly rewarding experience to accomplish something new and acquire a new skill. I suppose I could have taken down my pool fence using nothing but a big hammer, but the result would have been disappointing and I would have learned nothing new. By contrast, I found a great deal of satisfaction in the process of doing something I’ve never done before — and I love the results. It’s likely that I’ll never take down another pool fence in my lifetime, but I learned a few skills that I can apply to all kinds of project that might come up in the future.

When is the last time you added a new tool to your box?

Are you doing what you want to be doing today? Does your work frustrate you or inspire you? Are you happy where you are? If not, move. Really, move your feet. Start living your dreams. Take one step toward your goals. If you are unhappy, make change.

When I meet with my colleagues at Squidoo, I’m reminded how incredibly cool my job is and how amazing the people are that I work with. I get inspired. I hope everyone works with people and in places that are inspiring. If you are not, go out and find that place. It changes everything.

It’s your choice.

Within the past few years, however, the scope of what can be accomplished by relatively simple integration and reuse — especially on the web — has grown significantly. For example, one thing you’ve probably seen is the common use of those funny login pictures that ask you to type in letters to prove you’re human. For a while, every web site manager that wanted to have that functionality had to build it herself or hire someone to do it. Today it’s as simple as integrating with a service like reCAPTCHA. Additionally, you’ve probably seen plug-in functions for polls, guestbooks and many other standard web site features.

Recently, the pace of development in integration with major services has accelerated again. Google has released Google Friend Connect and Facebook has released Facebook Connect, both of which provide deep integration into existing social networks such as MySpace and Facebook. These integration platforms are still evolving but the implications are huge.

By properly integrating with the existing social networks, a site can provide rich social interactions within existing networks of friends without reinventing the wheel. And frankly with Facebook growing at a rate of 700,000 new users per day, the chance of your site competing head to head with them is extremely low. Don’t compete. Don’t reinvent. Integrate.

Integration is the key

Rather than trying to be the next Facebook, take your unique value to the existing networks on Facebook by bringing them to your site. Amazingly, it doesn’t take a degree in computer science to get some basic integrations working on your web site. Realistically, it might take a degree in computer science to do some more complex integrations (and to read the current documentation). To give a perspective, it took me several weeks (with an incredible support team) to integrate Facebook with Squidoo. To add the Facebook comment boxes on this blog took about 30 minutes.

That’s interesting, but so what?

I decided to disable the normal Wordpress comment system and just use Facebook’s new comment box today. The advantage is that when you post a comment on any page of this site, you also (optionally) post that same comment on your Facebook profile with an link back to my site. If you care enough to comment and tell your friends that you made a comment, it implies that you believe your friends will be interested in your opinion of my site. Assuming they are, they click through to my site, make a comment and the thread continues. Suddenly my site is a part of your social network and you didn’t have to go out of your way to make it so. I reduced a barrier and we all benefit.

The Facebook comment box is just one small piece of Facebook Connect. There are similar tools offered through Google Friend Connect for integrating with other social networks (including MySpace). As I said earlier, these tools are very new and rapidly evolving, but it’s very exciting. Right now if you’re managing a web site or building a new one (or just thinking about it) consider the list of features you’d love to have. If they include commenting, user registration, friend invitations and broad publication of user actions, you might be able to cross them off your to-do list and simply integrate.

Imagine

Consider how much energy you can focus on the core purpose of your web site if you don’t have to build technologies to compete against the clearly-dominant market leaders in social networking. I’m so excited about these emerging technologies that I can barely write this post. There’s so much more to talk about, so many examples of how to do it and so many ideas for where it can best be utilized.

Next steps…

This is going to be a core topic for the next few months (rough guess) as I build samples, give concrete examples and provide code to help you integrate with as little frustration as possible. I’m going to focus on Facebook Connect because I haven’t built anything more than a sample application using Google Friend Connect yet.

I’d love to get your feedback! What do you want to know? How would you use Facebook Connect if you could? Ask questions even if you’re not sure what the questions are!

When that happens, I’ll go out of my way to ensure that I clearly mark the message so that you know. If you’re not developing (or managing the development) of a site, you can skip over the posts if you like.

If I geek out too much, let me know!