These guys have put together a series of free video courses covering various aspects of building a successful blog. There are about 10 free vids in total. Pretty cool. They've done this because it creates good awareness for their other training offers. But the free stuff is pretty good by itself.

Strangely enough, the reason I noticed this was because the presenter has a South African accent. Having one myself I thought I'd give them a punt..!

Here's the link

ToS is something us website owners seem to throw up the day we launch and then "hope to make better" as the months go by. Then we end up only updating it when specific cases of abuse occur on our sites. I'd really be willing to pay a few bucks to have someone else manage this for me each month. What kind of monthly pricing would be acceptable to others...?

I had an idea for a new startup website yesterday which I thought I would share here. I've got to many projects lined up to do it myself, so maybe the idea can be of use to someone else.

Satellite images of the earth at night can convey a lot more information than one would expect. The light that radiates from built-up urban areas can show more than just the expansion of city lights, it can also indicate economic expansion, infrastructure build-out, and energy consumption around the world. This light information could be used as a good proxy for information not readily available from around the world.

The idea is to build a website that would mashup night time satellite images with other information. Perhaps a multinational company could overlay their sales revenue data on a world-wide view of the globe. They could then analyse and see which markets they are underserving or missing completely. Light intensity increases in certain developing countries or cities could indicate economic expansion that they should be addressing.

Of course the real power of a mash-up like this would be if the website could automatically interpret the annual change in light intensity and then relate this back to the information that it's being mashed up with.

Other applications could be environmental organizations looking to track urban expansion, energy companies looking to track growing energy demands, or perhaps commodities traders looking for another piece of information around future inventory levels. I think the applications are endless.

So, hope some clever person out there builds it. If you do, drop me a message and let me know about.

You can make your own too..

Oh well, before the mystery could continue much further I dropped firmly back down to 80th spot for keyword. So it must have just been an anomaly. Just as well, or I might have got a big head or something.. ;-)

Use OAuth...

This one almost shut me down in the first week. When I first started, I decided to use basic authentication. This is a perfectly legal way of doing things, but unfortunately has been abused a lot by hackers over recent months. The basic principle is that you ask the user to enter their twitter username and password and then you use this to authenticate them. It's in fact the same thing twitter does when querying your Google or Hotmail account on sign-up. The problem arises with what you then do with these details thereafter. Phishing sites take those details and use them maliciously. Legitimate sites will either not store the password at all, or will one-way encrypt them so that they cannot be compromised. I started out using basic authentication with one-way encryption, but it was clear this would not be viable going forward. Under risk of being shutdown, I completely rewrote the authentication to use OAuth. This is the preferred method by twitter. It means that you never take a users password, and you instead rely on keys and tokens. Bottom line, if you're creating a web app, use OAuth. Don't use basic auth. Twitter doesn't like it and they will shut you down.

Avoid API Limits...

This can bite you in a nasty way. The limits are real, and you will hit them if you're not careful. First prize is to try to develop in such a way that isn't subject to the limits. An example of this is using HTTP POST's instead of GET's. Creating follows or status updates via the API uses POSTs, and these won't run down your API limit. Running many queries for friend ID's will quickly deplete your limit. It's obviously not always possible to use the API in this way, but sometimes you can. Where you have to use the limits try and pass this on to the user. When you authenticate the user using OAuth you'll use the hourly limits assigned to their accounts, and not the one assigned to your server's IP address. Finally, cache as much as you can. I do one query when the user logs into my site and then update a SQL database with that information.

Allow exceptions...

I've realized it's better to handle a few exceptions rather than query twitter for every bit of information. Too much querying will add delay to your app and will deplete the API limit's. Rather implement in such a way that you allow the user to do a few things that won't work, and then explain to them why it didn't work afterwards. An example here is probably the best way to explain this. Let's say you don't want a user to follow a person they're already following. You could query the API first to see who they're following, and then prevent them from following them. Alternatively, you could allow them to follow anyone, and then just present a friendly error message when they try re-follow someone. The later does far less querying and is just as resilient, and more scalable.

Single log-in...

You'll save yourself a lot of hassle if you just use twitter to authenticate your users. Don't create a separate username and password on your own site. Use OAuth, and then based on the twitter ID you get for that user, create or log the user into your site. The alternative is much confusion from users when they change their twitter username or password. They get out of sync with your site's login details, and they end up doing password recoveries. You'll also convert more sign-ups with the simplified registration process. It's too late for me to change to this model, but next time this will be the way I go.