Every wondered how to automatically figure out the RSS feed for a blog?

Generally speaking, it’s a simple task — just download the HTML for the given blog and use a fancy regular expression to find the associated RSS feed.  In PHP, it looks something like this:

$bloghtml = file_get_contents($blogurl);
preg_match('/<link.*types*=s*[\"']*application/rss+xml[\"']*.*hrefs*=s*[\"']?([^'\" >]+)['\" >]/i', $bloghtml, $match);
$rssurl = $match[1];

The main problem with this approach is that some blogs take a long time to load — and that often translates to your application being slow as well.  On top of that, it’s frustrating to have to download and process an entire page of HTML just to extract one URL.

Recently Google came out with a better solution in the form of their AJAX Feed API.  Using their API, detecting feeds is now easier, faster and more reliable:

$lookup_url = "http://ajax.googleapis.com/ajax/services/feed/lookup?v=1.0&q=".urlencode($blogurl);
$result = curl($lookup_url);

I’ve been using this API for about a month now and have really appreciated the improvements.  If you need to detect feeds, give it a try.  I think you’ll like it.

Root-relative navigation is the way to go.
There are several different ways to organize your navigation system. Some people use relative URL’s (../index.php), others use absolute URLS (http://www.onlineaspect.com/index.php). I’ve found that using root-relative navigation (/index.php) works best for me. It makes it easy to maintain multiple development environments without having to store a path variable and you don’t get into messy situations when you try to include templates from within nested folders.

User generated content should always be stored in your database as UTF-8.
Otherwise you’ll wake up one day and you’ll have people from 92 different countries using your application and you’ll have funky characters all over the place.

One day memcached is going to be your best friend. Start preparing now.
You probably don’t need to implement memcached for your early prototype, but that doesn’t mean you shouldn’t be already thinking about it. Understanding how memcached works now will help you design an architecture that will maximize the benefits of it later.

Don’t ever send an email right now if you can delay it an hour.
The biggest 2 mistakes you could make as web startup are 1) deleting data that shouldn’t be deleted and 2) sending an email that shouldn’t be sent. You can protect your company and your reputation by backing up your data and buffering every email that you’re likely to mess up. Does that newsletter email really need to be sent right now? What if you made a mistake? Remember, there’s no undo button on email. Why accelerate the “oh crap!” moment? Sure, you will make mistakes, but sometimes a simple delay can prevent the whole world from knowing about it.

What you learned in database class isn’t necessarily best for your application.
Relational databases are great, especially in theory. Just be prepared to trade in your favorite normal form when you need to achieve speed and scalability. In particular, avoid joins and cache any counts that you find yourself using on a frequent basis.

This past month I finally broke down and spent $500 to claim the domain name joshfraser.com.  Right now it’s nothing but a landing page for my various content around the web.  I’m looking for ideas on what else I should put there.

Post your suggestions in the comments.  Thoughts on how we can rid the internet of domain squatters are also welcomed.

At EventVue, our first point of contact with our users is by email.  That’s why I’m obsessive about making a great first impression with our emails.  It’s also the reason I work so hard to make sure that we maintain high deliverability rates.

According to George Bilbrey at Return Path, email deliverability is all about sender reputation.  When people hit the “mark as spam” button, it hurts your reputation.  When they click “not spam”, it helps.  When you send hundreds of emails to addresses that don’t exist, your might as well tattoo “SPAMMER” onto your forehead!

What do you do when your email list is made up of unverified email addresses?

How do you tell which ones are good and which ones are bad?  More importantly, what can you do to reduce the number of bounced messages and the inevitable damage to your sender reputation?  Here are a few things that will help:

1) First pass: regular expressions

Your first defense in checking you have a valid email address is making sure it looks right.  Pete Warden recently posted some great examples of how to use regular expressions.  In PHP, you can use the preg_match() function:

$exp = '/[a-zA-Z0-9._%+-]+@[a-zA-Z0-9.-]+.[a-zA-Z]{2,4}/';
if (preg_match($exp, $email) <= 0)
    echo "bad email";

2) Take it to the next level: check for an MX record

A lot of people run their email addresses through a regular expression and quit there.  I’ve found that doing a quick DNS lookup goes a long way towards eliminating typos from dyslexic users.  In PHP, it’s easy to check whether or not a domain has a DNS record for a mail server:

function mx_record_exists($email) {
    $email_parts = split("@", $email);
    // contains exactly 1 @ sign
    if (sizeof($email_parts) != 2)
        return false;

    list($username, $domain) = $email_parts;
    if (checkdnsrr($domain, "MX")) {
        return true;
    }
    else {
        return false;
    }
}

3) Learn from your mistakes: watch your feedback loops

If an invalid email slips past your first two defenses, it doesn’t mean you have to make that mistake again. Create a blacklist for any bounced emails and make sure you don’t send an email to that address again.

As I’ve written here before, I am a huge fan of OpenDNS shortcuts.  I’ve always hated switching over to Safari for the simple reason that my shortcuts didn’t work.  You might laugh, but it’s hard to go back to typing full urls once you’ve gotten used to single letter aliases.  Before you call me lazy, try it for yourself.  I promise, you’ll never go back.

Anyway, last night I finally found the secret to making shortcuts work in Safari.

Open up your System Preferences.  Go to the Network pane.  Select the TCP/IP tab and enter “208.67.222.222″ or “208.67.220.220″ into the Search Domains field.

That’s it.  Simple, eh?  Hopefully this will help someone find the solution faster than I did.

A while ago we had a discussion over whether we should send our invitation emails as plain text or in HTML format.  My gut feeling was that spam filters would be tougher on HTML emails than plain text, but I didn’t know for sure.   And I had NO IDEA which email format would have a higher response rate.

Instead of sitting around talking about it — I decided to test it.

We happen to have a conference with several thousand attendees coming up in a few weeks.  This gave me a great opportunity to do some split testing with our emails.  For the test, I sent out 2459 emails with exactly the same wording.  Half of them were in HTML.   The other half were in plain text.

Of those 2459 emails, 81 (3.3%) either bounced or were rejected by spam filters.  Of the 81 emails that were returned 26 of them were plain text emails, and 55 were HTML emails.  This means that the HTML emails were rejected at more than twice the rate of the text emails.  However, the response rate to the HTML emails was 11% better than that of the plain text emails!

After taking the lower delivery rate into consideration, the data suggests that I could increase our user participation rate 9% just by sending our emails out in HTML format instead of plain text!

Needless to say, this is an exciting discovery for me.  However, I’m not close to done yet.  For one, I still need to prove these numbers hold up with other types of conferences.  And two, I have a lot of other things to test and refine.  I particularly want to see how changing the wording impacts our response rates.   I want to test different layouts on our website.  What would happen if I changed the background color from blue to green?  What if I made the font bigger?

I don’t know — but I’m going to find out!

For those of you that are considering starting your own company, TechStars is a great way for you to get connected, get funded and get your company off the napkin and onto the interwebs.  If you are questioning whether or not the TechStars program is worth it, take a look at what TechStars did for me:

A year ago…

•    When I had a technical question I went to Evan Tishuk or Daniel Von Fange.  That was it.  Those were the only two programmers I knew.

•    I knew one person who worked at Google, and not very well at that.  I didn’t know a single person who worked for Microsoft, Yahoo or Facebook.  I might have had a lot of friends in college, but I didn’t know anyone in the tech scene.

•    I knew the name of one venture capital firm:  Sequoia Capital.

•    I didn’t have any money, nor did I know anyone who wanted to share theirs’ with me.

Today…

•    I’ve got a slew of people standing by to help.  Tom used to work for Oracle.  He gets to hear all my database questions.  Jon is the master programmer behind Intense Debate (the awesome commenting system I use on this blog).  I talk to him about PHP stuff.  Herb is an experienced CTO — he’s also my mentor/coach.   Those are just the people I see on a regular basis — there are dozens more that are a mere email away.

•    Not only do I know people at the big tech companies, I’ve gotten to know the people that are important to us in the conference industry as well.

•    Not only do I know the names of a lot more venture capital firms — I know actual venture capitalists too.  When it comes time for EventVue to raise another round of funding, we’ll know where to start.

•    I still don’t have any money, but at least our company got funded.

 So, what are you waiting for? 

Check out the list of mentors.  Look at the past companies. And apply for TechStars today!

Over the weekend I had the privilege of hanging out with twelve of my best friends from Clemson.  They flew in for MLK weekend, and we spent our time skiing and boarding up in the mountains at Breckenridge.

If you spend any time on the slopes, there is one phrase you will hear a lot:

I didn’t fall this time!

I started wondering — is that really the best we can do?  Is staying on your feet the best metric of success?

Sure, I could get down most slopes without falling — so why do I fall so much?  I’d rather go through some brutal wipe-outs and and improve my snowboarding skills than risk becoming content with my ability.

You might argue that the experience is a lot less enjoyable if you spend most of it on your face in the snow.  Why not recognize your limitations and have a good time on the bunny slopes?  You have a pretty valid argument.  The only problem is this: you’ll spend the rest of your life on the bunny slopes.  You’ll never know what it’s like to push yourself and actually succeed.  Sure there will be frustration in between, but it might just be worth it.

What about you?  Are you continually pushing the envelope and trying new things, or are you content setting the bar just high enough not to get hurt?

Is it worth it?

Did you know that more people die every year from falling down the stairs than from snake bites? Crazy, huh?

Did you know that a child is 100 times as likely to drown in a swimming pool than be killed by a handgun?

It turns out that most of us do a poor job at evaluating risks. We’re terrified of snakes, but don’t think twice about walking down the stairs. Parents won’t let their children play with their friends whose families own guns, but they don’t have a problem with them going swimming every weekend.

I’ve noticed that many startups suffer from similarly poor discernment into risk assessment. Here are a few examples:

Maybe you have a startup but won’t tell anyone what you are doing because you are worried that someone will steal your idea. Instead, you run around with a stack of NDA’s and tell everyone you are in “stealth mode”. As a result, you miss out on valuable feedback that would undoubtedly improve the direction of your product. Sure, there is a chance that someone might steal your idea, but isn’t the greater risk that you will build something that no one wants?

Perhaps you are worried that your web application won’t scale to millions of users. As a result, you spend a large percentage of your time and resources making sure your application is fully scalable. While scalability is an important issue to consider, the majority of preparation for future growth should come after you’ve proved that people want what you have. Is there a risk that your product won’t scale? Sure — but that’s a good problem to have. As Dharmesh Shah recently said:

Don’t fall into the trap of spending your limited resources on planning and preparing for success. Instead, spend them on things that will actually increase your chances of success.

With any luck, your product will experience growing pains at some point down the road, but that shouldn’t be your first concern. Instead you should realize the greater risk is that your company will run out of money before you get a chance to show your amazing product to the world.

Don’t let the perceived risks make you take even greater risks. Instead, try to evaluate them as objectively as you can, and then act accordingly.

DO NOT REPLY TO THIS EMAIL.This mailbox is not monitored and you will not receive a response.

Every email I receive these days seems to contain that sentence in one form or other. A bit rude, isn’t it? Wait, it gets better…

To ensure delivery, please add us to your address book.

Let me get this straight — you want me to add you to my address book, but you won’t even read my emails? Instead you’re going to make me take a 20 minute scavenger hunt around your website to find out how to get in touch with you?

Why?

I’d rather just hit reply.

Here’s an idea: Why not start listening to your customers instead of insisting on having a one-way conversation all the time?

It’s easy:
• Set up a filter to delete all the “Out of Office” emails and the delayed delivery notices.
• Forward the bounced emails to your email management script to remove them from your mailing list.
• Actually start reading and responding to what your users/customers have to say.

Let’s start a new trend and stop using that annoying “no-reply” email address. Come on — we can be more creative than that!