Posts tagged ‘software development’

Edge cases

A few months ago, the parking garage at the San Jose airport ate my credit card. There was noone at the exit so I parked and went hunting for someone who could help me. When I finally found someone, they kindly ejected my card and explained that their machines use a light to detect when you insert your card. Since my card is made of clear plastic, the light shone right through causing the machine to think the slot was still empty.

It’s an obvious oversight, but who do you blame? American Express? The company that made the parking garage payment system? I’m not sure, but I don’t use that card in automated machines anymore.

That experience reminded me of the importance of thinking though edge cases. Most people don’t have clear credit cards, but for those that do, it’s important that they work everywhere. A good software developer can build an application that works 95% of the time. A great one will think of all the unique edge cases (like clear credit cards) and build systems that are smart enough to handle them. At Torbit, we automatically transform websites so they load faster. It’s a tricky process and there are hundreds of edge cases that could trip us up. I often get asked how we compare to various competitors. For us, the big differentator is that last 5%. It’s being smart enough to know what to do with broken CSS or how to handle JavaScript that’s missing a very important semi-colon. It means we do the right thing even when you send us a JPEG with a “text/html” content type.

The last 5% is the hardest part, but oftentimes, it’s the most important.


Managing code releases

Recently I decided to streamline my code release process. I use subversion for my source control which means I push code live by running svn up on each of our production servers. I’m lazy, so I wanted an easier way to do this all at once. The end result is a simple shell script that lets me run svn update commands on multiple servers at once. It shows me the status of svn on each server and gives me chance to confirm that everything is okay before going ahead with the launch.

This example assumes you have two servers (app1 and app2) that are using public key authentication. Obviously, you’ll need to modify this script to work in your own environment. Make sure you replace “/var/www/” with your own document root and change to the IP address of each production server.


# connect to each server and echo their current status
echo "Connecting to app1...\n"
ssh 'cd /var/www/; svn status --show-updates; exit'
echo "\nConnecting to app2...\n"
ssh 'cd /var/www/; svn status --show-updates; exit'
# add additional servers here as needed
tput smso
# confirm the release before publishing
echo "\nDo you want to publish these changes to production? (y/n)\n"
tput rmso
read answer
if [ $answer == "y" ]; then
    # if "y", proceed with the release
    echo "\nPublishing to production..."
    echo "\nPublishing to app1..."
    ssh 'cd /var/www/; svn up; exit'
    echo "\nPublishing to app2..."
    ssh 'cd /var/www/; svn up; exit'
    # add additional servers here as needed
    echo "\nDone"
    # if "n", cancel the release.
    echo "\nCanceled"

How to start MAMP on port 80 without a password

I’m a big fan of MAMP. It’s the fastest way for anyone to get set up with a local PHP/MySQL development environment on a mac. One of the small annoyances with MAMP is that it requires you to enter your password all the time if you want to run it on port 80 (which I do). To be fair, it’s got more to do with UNIX security than MAMP… but it’s still bloody annoying!

I tried Steve Stringer’s technique of using launch daemons, but it just couldn’t get it to work for me.

The trick to getting MAMP to start behind the scenes is knowing that all that pretty GUI does is call a couple shell scripts. Specifically, those scripts are /Applications/MAMP/bin/ and /Applications/MAMP/bin/ (assuming you installed MAMP at the default location).

The second thing you should know is that must be run as root, but must be run as the current user. I created a new shell script to call those scripts appropriately:

sudo /Applications/MAMP/bin/
exit 0

I then added added an exception for that script to my sudoers file so I didn’t need to enter a password when I used sudo. The easiest way to add this exception is to use the ‘visudo’ command as root.

Finally, I used Automator to wrap the whole thing up as an application I could add to my dock. It works! One less daily annoyance in my life!

Since writing this, Damian Gaweda has posted a more elegant solution that’s worth checking out.

5 things I wish someone had told me

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 ( 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.


The value of split testing

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!

 1 comment

When you know just enough to be dangerous

I’ve always been amazed by the number of books that promise to teach you how to program in just a few days or weeks. I recently stumbled across a book at Amazon entitled: Sams Teach Yourself PHP in 10 Minutes. 10 minutes!!!

Why do we think it is possible to learn JAVA in the same time it takes to make a pot of coffee?

It has taken me years to learn how to program and I am still learning new things every day. Imagine if we applied this same thinking to other skills. I’ve never seen a book on how to learn to play the piano in 10 minutes. That’s because everyone knows that learning to play the piano takes countless hours and years of practice. No one should expect to become an expert overnight.

Why are people in such a rush?

Let’s stop spreading this lie that you can learn everything you need to know about programming just by reading a $20 book. You can’t. Sure, you might be able to gain a superficial familiarity, but not the deep understanding that is required to build a real application. Books like this are a great way to explore your interests. Just realize that by the time you finish the last page, you probably know just enough to be dangerous.


The story of how I became a programmer

The story of how I became a programmer is really a story about my dad.

As long as I can remember, my family has had a computer in our house. My entrance into the programming world started when my dad bought me some books on how to program our Apple IIe. I spent hours trying to write programs for that thing!

Then early in high school I decided I wanted to be a website designer. My dad encouraged me to build a website for a local company and see if they would pay for it. I guess my price was too high. I asked for $100 and they turned me down!

My dad told me not to be discouraged, but said “If you really want to be good, you should learn HTML”. So I did.

A few weeks later I was showing off what I had learned about HTML, and my dad said “That’s great, but if you reeeally want to be good, you should learn JavaScript”. So I did. And after I mastered JavaScript, I learned PHP. And after PHP, I learned mySQL.

After I graduated from high school, I went to Clemson to study Computer Science. My dad never had a college education, but he made huge sacrifices so that I could.

During the summer, my dad landed me an incredible internship with a company in Charlotte. By my second summer there, I was the project lead for multiple clients. I probably learned more about programming at Orbis, than I did in college.

For 23 years my dad has shown me how to work hard and not give up. He’s taught me to think outside the box, and has continually pushed me to take on bigger and bigger challenges.

Dad, thanks for being such an incredible example to me. Happy Father’s day! I love you.

 1 comment