How to write rock-solid code

There are 4 simple things I’ve learned over the years (and try to do…) to write solid code:

  • Write modular code
  • Document as you write
  • Have each code chunk complete its task or throw an exception
  • Write unit tests as you debug

These are compiled here largely for my re-reference, but also because I was just discussing it with a friend (also a software developer).  Now to the details, which include a really handy technique I’ve picked up for manual testing.

  • Write modular code.
    • Each piece of code should be short and have a well-defined purpose.  It takes specific inputs (and doesn’t rely on global variables unless appropriate), performs a specific function, and returns specific values.  If you have more than a pageful of code in one method, for example, you need to split it into more methods.
  • Document as you write.
    • Every class, method, handler, subroutine, etc should have documentation appropriate for the language you’re using (e.g. POD for Perl).  If you don’t know what that is, go Google “standard documentation format for <insert_language_here>” right now and learn it.
    • Document:
      • What your code-chunk does in a one-sentence summary.  Your user is looking for modules to use and should be able to read that line in a list and pick the module they need.
      • What parameters (input) does it take?
      • What does it do?
      • What does it return?
    • In a Wiki or similar (I use Google Docs for personal stuff), document the system itself.  If you get to more than 5 classes, you’re going to start forgetting what calls what and where your data flows.  Document data flows and sequence diagrams at least.
  • Have each code chunk complete its task or throw an exception.
    • Each method/handler/subroutine should either complete what it’s asked to do or throw an exception.  As you’re coding, you can start with a general exception at first, then as time passes and you get specific errors happening, you can update the code to throw specific exceptions and possibly catch and deal with them.  This makes several things possible:
      • Calling code can just call the method, not have to check obscure return values.
        • Makes calling code cleaner:
          • getWidget();
          • moveWidget();
          • deleteWidget();
          • Instead of:
          • if getWidget() = -1 then { dealWithBadWidget(); }, etc.
    • Validate inputs to the method. Throw an exception if the input’s invalid. Assuming your caller may give you bad values helps prevent obscure bugs.  Note here that distinguishing between user input vs programmatic input is handy: e.g. input’s the wrong class is a program problem, input’s got a semicolon in “fist name” is a user error.  Throw a different type of exception for each – program problems should alert the developer, user errors should alert the user.
  • Write unit tests as you debug.
    • You’re going to write code to debug anyway, just make them into unit tests.  Follow the format appropriate for the environment/language you’re writing in. Don’t worry about making super-comprehensive tests, just make sure you have (safe) tests you can run that test the things you’re working on.
    • Unit Testing Frameworks:
      Perl: Test::More, but really see “man perlnewmod”
      PHP: PHPUnit
      JavaScript: QUnit
      Java: JUnit
      Python: Unittest
      iOS/MacOS X: Built in to Xcode!
    • If it’s not practical to write automated tests (e.g. for a user flow on a web site, although see Selenium), make a QA script (AKA QA test procedure):
      • Make a 2-column spreadsheet (Google Docs is great for this).  Column one is “Step”, column 2 is “Result”.  I like to keep this really simple and have the result be “PASS” or “FAIL”.  If there are any notes about the failure, I add them as a note attached to the cell.
      • In the “Step” column, list the steps to test the feature, one step and result per line.  Make sure each step and test can pass or fail.  So a test for Google search might look like: “Go to  Page loads and displays a search box.”, “Type ‘pizza pie’ in the search box, hit return. Search results display.”, “Top 3 search results contain the words ‘pizza’ and ‘pie’ in the title.”, “Ads display on the top and right side of the page.” etc.
      • You can also use conditional formatting to make the backgrounds of the Results cells red or green so you get a really clear-at-a-glance picture of whether your code works or not.
      • After you make significant changes, before you push to production, run through the script yourself or have an intern or assistant do it.
      • Tips:
        • Split the tests into multiple tabs (or spreadsheet docs if appropriate) based on feature (think separate unit tests), and name the tabs/docs by feature.
        • Keep the scripts short enough to quickly test a feature, and as long as necessary to include all steps needed to test that feature (e.g. if you’re testing a shopping cart’s order confirmation page, your test will need to include adding items to the cart, signing in and/or registering, entering test payment info, and confirming your order).
        • Write the steps very clearly.  Pretend you’re writing a program.  A person with no technical knowledge should be able to follow your steps without thinking and mark them “PASS” or “FAIL”.  e.g. say “go to, verify a search box displays” and not “load the web site” (which web site?), or “see if it loads correctly” (what’s “correct”? If I’m testing, I may think the error message is “correct” because it’s grammar is accurate).
        • “PASS” or “FAIL” makes debugging easy.  If your steps and verifications can’t pass or fail, break them into smaller steps or separate test sheets.  Your automated unit tests don’t leave vague notes – your manual ones shouldn’t either.

There.  Solid code in 4 steps.

My 3 top productivity tools

GTD helps organize my life, goals, projects, and actions and determine where and when things get done.  4-hour workweek helps with concepts like eliminating useless tasks, focusing on what’s important, work/life balance, and getting things done quickly.  Pomodoro technique helps focus on the task at hand, finish it quickly, and stave off interruptions (almost any interruption can wait 25 minutes or less, and usually doesn’t need to be done once that 25 minutes is up).

See, kept it short so you can go be productive.

How to correct your eyesight without glasses

People keep asking me about the eye charts I have up at work and at home, the rotating monitor windows, etc. Instead of re-generating this email each time, I’m putting it here. 🙂

On Oct 19, 2011 my eyesight was 20/200. Right now (May 31, 2012) I’m reading the 20/30 line on the chart, and can read lower with a bit of effort. I was only fairly consistent with my exercises (and I’m still doing them – I want 20/20).

There are many books/sites/etc on this, most of which boil down to Dr. Bate’s book from the early 1900’s, which (since it’s in the public domain) is available for free here:

The basic exercises are here:

And various eye charts are here:

Some basics if you’re considering doing exercises to correct your vision:

  • If you have glasses, you’ll need to stop wearing them – way too hard on your eyes to go back and forth.
  • If you haven’t worn glasses, don’t – 30 seconds a day per eye with an eye chart can fix/keep your vision.
  • If you have glasses, it takes 30-60 minutes per day of “exercises” (which is really relaxation, not that hard).  The payoff for this effort is:
    • Convenience – no more losing glasses, dropping contacts, packing contact lens solution, cleaning glasses, etc…
    • Cost – no more paying for glasses, contacts, solution, etc
    • Better eye health
    • Ability to see in bright or dark light (I actually see more clearly in bright light now and it doesn’t hurt.  I don’t wear sunglasses (in LA).)
    • Supposedly, prevents presbyopia (loss of ability to focus near/far).

Hints and tips:

  • Note that your vision changes – on my first day of measuring I could get 20/200 to 20/70 with my left eye, and only 20/200 with my right. 3 days later I could get 20/50 with my right, but it still varied between 20/200 and 20/50. Your glasses prescription (DMV test, etc) will be for the level you can see easily and consistently, so I try to use that as my gauge when measuring my eyesight.
  • I’m near-sighted (can’t see objects at a distance), so I don’t record the near-vision card any more (although I should). The book/tools above help with far-sightedness (can see far, not near) also.

How to develop excellent websites and web applications easily

[UPDATED 5/30/2013 for HTML5/CSS3/Responsive Design]

Developing a great website or web application is really very easy, but there are many ways to do it badly, and that makes it difficult.

Here’s how to do it “right”.

  1. A URI identifies each unique resource
  2. Gather your content, and code it in straight, standard, valid HTML
  3. Lay out your content using CSS using responsive design techniques.
  4. Ignore the flashy new technology, stick with well-established basics
  5. Get the user’s language from the Accept-Language header.

These 4 simple rules are all you need to design great sites. Companies are constantly trying to push their fancy new technologies, and browser makers put proprietary features into their browsers hoping you’ll use them, and force people to use their browser. Unfortunately, this just makes your site unusable to people not using that browser.

A URI identifies each unique resource

URI means “Unique Resource Identifier”. Originally, and sometimes still, this meant that a unique string identified each page on a server. It’s a great, simple concept: any given set of content should have a unique URI (yes, that’s redundant). This blog page has a unique string that identifies it. You can send that string to your friends (hint hint), and if they put it in a web browser, they’ll see this article. Seems straight forward, but many many web sites break this rule. For example, if I’m searching for flights on a travel site and have a certain set of flights displayed, I should be able to copy the URI and send it to my friend. Unfortunately, this rarely works. If I load up my shopping cart with stuff at, I should be able to send that cart to my friend. I can’t.

Make your sites RESTful. That’s a fancy word meaning “use the web the way it’s designed”. The O’Reilly “RESTful Web Services” book is excellent extended reading on this subject:

Restful Web Services

URIs are fancy things that can include a LOT of information. Let’s take the examples I gave above and do them right:

Filtering flights

I see filters on web sites done wrong all the time, and it drives me nuts. It’s so easy to do right, and would be so convenient. I apologize, because now you’ll be driven nuts too.

Each element of a filter should be included in the URI. Let’s say you’re setting up a travel site. People fill in departing and arriving airport, dates, and preferred time range. They click a “search” button. The button should encode that search into a GET request (NOT A POST!), which then displays the result. So it might look like (I’ve left a lot of potential detail out, like return time, for brevity).

Say your “flightsearch” page has more filters. It’s really fancy, and clicking a column header sorts by that column. When a user clicks a filter, say selecting a max price of $500 per flight, the URI should change to, say, include “max_price=500”.

Now we sort by price:

Now that’s a nice URI I can email to my friend and say “look at the cool flights to New York, let’s go!”. It’ll have the exact filters I selected and even be sorted the same. This URI represents “Flights from LAX to NYC departing Oct 10, 2011, returning Oct 20, 2011 that cost less than $500 ordered by price”.

Sadly, you’ll see similar results on sites that might include the flight info, but once you start clicking on options like price, time windows, and sorts, those don’t factor into the URI.

Shopping Cart

I’ve never seen this done right, but it’s so easy to do right.

To be RESTful, (and have Unique Resources to Identify), you shouldn’t maintain “state” on the server. That means no session cookies (although I’ll concede to an authentication token, but I’ll get to that later). “But how do I store my user’s shopping cart” you ask? Let’s follow the rule: A shopping cart with certain items in it is a resource. That resource should have a unique identifier. If I go to that identifier (URI) later, I should see the same cart. If I send the URI to my friend, they should see the same cart.

So as I shop and click “add to cart”, my items get POSTed to /cart/myusername. A GET to /cart/myusername returns the items in the cart. Ideally, this would be a basic XML document that gets wrapped with a page layout via an appropriate CSS style sheet (sticking to the content/layout separation rules). That way, you could use it in an API to an iPhone app, or as a mobile web page, or as a normal web page by just using the right style sheet. But we’re not talking about that yet.

From here you might want to let the user set up multiple shopping carts. You could have:

A POST to now would create a new cart and return its ID (e.g. in the resulting web page). Subsequent pages would then POST to /cart/myusername/12345. The user could then create carts specifically to email to friends, e.g. “here’s a cart of all the stuff you need to build the game PC we were talking about”.

For details on how to formulate RESTful URIs, read that O’Reilly book above. And notice that handy URI that takes you to a page on and tells them I sent you. 😉

I’ve mentioned “GET” and “POST” above. These are HTTP methods. There are four total methods: GET, PUT, DELETE, and POST. These tell a server to GET a resource, PUT (change or replace) it, DELETE it, or add to it (POST). So if we were maintaining a database of products, product number 12345 might be identified by the URI A PUT to this URI would change the product. A DELETE would delete the product. A GET would return the product’s info. You wouldn’t POST to this product. However, to create a new product, you would POST to, which could create a new product and return a new product number for it. You can read all about that in the RESTful Web Services book.

I mention HTTP methods because there’s a sub-rule that’s often broken in web pages: GET should be used to retrieve information, and POST should be used to change it. When you’re writing a web form in HTML, you can specify the method in the “form” tag. If you’re doing a search form, this method should be “GET”. If you’re changing a user’s password, it should be “POST”. HTML doesn’t support PUT or DELETE. If you use the wrong method, you’re hindering your site, and you could end up doing real damage in some cases. For example, if you POST a search form, the user can’t bookmark it and send the results to his friends. That could be (lots of) lost business. If you use GET in a form that adds a new product, you could accidentally hit “back”, and that product would be created again. If you reload the page, it’d be created again and again. What if you did that with a credit card order form? That could be hard to explain. Stick with good URIs, and use GET to get, POST to change, and you’ll make great sites.

Gather your content, and code it in straight, standard, valid XHTML

People often do this step backwards, and it gets confusing. They think they want a site to look cool, so the focus on graphics and/or use a template. That’s like painting a picture before you know what you want to paint.

One thing is true of every single web site: its sole purpose is to get some information to someone. Someone wants something, and a great site gets whatever that is to the user as easily as possible. If your site is a store, the perfect site would read the customer’s mind, charge their card, and ship the item they wanted to them. Your job is to get as close to that as possible.

So when you start designing your site, get your content together before ANYTHING else. If you’re starting a store, gather your inventory and marketing text. If you’re advertising your company’s services, get the info about your company together.

Break the information into chunks that are easy to search and navigate. e.g. on most basic company sites, you’ll have a page of contact/location information, a basic introduction page, a page with more detailed info about the company, and a page about your products or services.

Each chunk becomes a resource, and gets its own URI (for a basic web site, that means each page gets a URI, which is what happens if you put a page on a web server anyway. So you’ll get, for example.)

The content goes into straight, boring XML or XHTML. No layout information. If I look at it, it should look like a linear outline. This means any device or browser will be able to display it. Or, an iPhone app could read it.

If you find yourself thinking about layout here, stop it. If you output a navigation menu, it should look like a bullet-point list. Use attributes to give classes and IDs to your elements. Then the CSS can use that information to create any layout you want.

Your page output should look something like this:

My Company - About Us

	css" TYPE="text/css" MEDIA=screen>
<li><a href="/index.html">Home</a></li>
<h1>About Us</h1>
We are a company that does stuff and things ...

Notice there’s nothing about layout in there. The navigation information is just in “li” tags, and the content of the page, if displayed without a style sheet, will just look like a boring outline.
The navigation menu, in REST parlance, provides information to the client about available resources based on the request for the current resource. In short, it tells you places you could go from here. The client (e.g. the browser) could choose to display that information, turn it into buttons in an app, or hide it completely.

Once you’ve got your content in HTML, run it through the validator at If you ever find yourself testing in different browsers, or writing JavaScript that checks what browser the user’s using, slap yourself and stop it. The world wide web works on standards – write your code to the standards and it should work on all browsers. The browser’s job is to render a page according to the standards. If it doesn’t, that’s its problem. If developers follow the standards, browsers that don’t follow them will disappear, because users will switch to a browser that works. If you need content in a different format (e.g. XML for your iPhone app), that should appear at a different URL (for example But if you stick to delivering your content straight up in standard HTML, you won’t have to go through the trouble of providing different “views” for it. (btw, by “different format” I mean delivery to APIs and such, NOT different layouts, which I’ll discuss next. As far as your web site/app goes, I should be able to hit the URL from ANY device and it should just work.

Lay out your content using CSS

CSS is magic. It can do incredible things, including making the boring HTML above look like a full-blown web page. You can add background colors and images. You can place things anywhere on the page you want. You can (must) even have the content resize based on the browser window width. You can specify layouts for different media types, including “screen”, “print”, and “speech”. You can change the color of a button when you click on it. You can turn the navigation list above into a tab-like navigation menu that changes colors when you click on each tab. You can anchor the nav bar to the side of the screen while the rest of the page scrolls. Read all about it at

The point here is, use CSS to lay out the content. If you want to support a different layout on a small screen than a big one, do it in CSS. You can do this through what’s now called “responsive design” (which we called “dynamic layout” back in 1996, but without “media queries”). Responsive design is very simple: lay out your content so that it moves dynamically instead of sitting like it’s on a piece of paper. There are many great articles on responsive design on the web – a couple of my current favorites are responsive design in 3 steps, 5 Useful CSS Tricks For Responsive Design, and iPhone Website Development. There are also excellent responsive WordPress themes (such as “Responsive”, which I’m using at the time of this posting).

I’d like to say a word about “mobile” sites: some sites provide a subset of their main site’s content for mobile devices. This is stupid. Responsive design helps fight this, but some sites still drop content from the mobile versions even then. Bad. Decide if your information is useful enough to include on your site or not. When you find yourself thinking “well, this page has too much information for a smaller screen”, maybe your page just has too much information. Consider breaking it up into smaller resources, or consider just dropping the “too much” part of the information. Don’t clutter the user’s browser and bandwidth just because it’s there. Again, this goes back to the “gather your content first” rule. If the user just wants to know the time, don’t give them a map of the world along with it. [The fancy phrases for this now are “progressive enhancement” or “mobile first design”.]

Ignore the flashy new technology, stick with well-established basics

This is where most developers run into trouble. Which browser should I code for? What technology should I use? Ooh, Cold Fusion looks cool, JavaScript is cool, this new programming language is cool, .NET looks like it makes things easy, I can write nifty menus in Flash, etc, etc, etc…

There’s always something new and cool. The problem is that most of it doesn’t work well, or doesn’t run on a user’s browser, or breaks the rules above.

Stick with what works and you’ll write great sites that won’t give you headaches: UNIX, Apache, PHP, Python, Perl, MySQL, Postgres, JavaScript, Java. For frameworks, Django, Ruby on Rails, and maybe Cake, Drupal, or JEE6. Stick to those and you’ll be writing great sites that’ll actually work. These technologies also let you stick to the rules above easily (well, Cake, Drupal, and JEE6 might not). Try to use MVC design (look that up on Wikipedia). Avoid flash (use JavaScript instead), Cold Fusion (breaks rules), and anything by Microsoft (breaks rules, isn’t reliable – heck, even their browsers break the rules).

Get the user’s language from the Accept-Language header

The web browser will send a header (Accept-Language) that contains a list of languages, in order of preference, that they’d like to see your page in.  If you’re supporting multiple languages on your site (probably a good idea on the World Wide Web), use this list to determine the language you’re going to serve, NOT some geolocation service.  It’s really annoying for, say, someone from California who is visiting France to visit a popular search engine and have it display in French.  There are also countries in which people speak multiple languages (e.g. the United States, Europe, and most of the rest of the world).  The browser tells you what language it wants – give it to them.  If you are (or your client is) concerned about the user not knowing how to set their language, set up a page that tells them.  You can, in addition, let them select the language on your site to override the browser, but don’t just ignore Accept-Language and use geolocation or a menu selection.  If you don’t have access to the Accept-Language header, you can at least get the browser’s language from Javascript with “var language = window.navigator.userLanguage || window.navigator.language;”.  That’s not optimal though.  See this stack overflow post for some solutions.  Also see the w3c spec and this post about setting language and locale settings.

A note about REST and sessions

RESTful services don’t store “state” on the server. That means it doesn’t matter what browser I use, where I come from, or how long I wait between requests. On a RESTful site, I could start a flight search on one computer, bookmark my URI, go to another computer, click the bookmark, and keep going. Or, I could start a shopping cart order on one system, email my friend the URI, and have him place the order for me. Of course, this isn’t how sites work. One big issue is “authentication”. In a RESTful web service, there are a few extra components to that URI request: Authentication (who are you?) and Permission (are you allowed to perform this method on this resource?).

So for our shopping cart, my friend would first have to prove to the server who he is, and then he’d have to have Permission to see my cart. It’s the Authentication step that gets tricky. Ideally, the user would prove who he is (usually using a username and password) with every request. Browsers do support this, but it’s not very friendly. This is usually worked around by using session cookies, which is difficult, non-RESTful, and causes annoying problems like taking the user to a page they didn’t request after logging in, forgetting the information in a huge form they entered, etc.

Instead of using cookies, use HTTP Auth Digest. If you want a pretty login form, you can create one with JavaScript. There’s a good article with code samples by Paul James that shows you how.

How to make Public Transportation work in Los Angeles

[ad#Adsense] On August 29, 2010, Santa Monica’s Big Blue Bus took a step backward in fare handling. Ironically, to announce the change, they ran ads implying that you wouldn’t need to use money on the bus any more. In reality, they were replacing the Little Blue Card (which allowed you to load cash onto the card and pay for your bus fare, transfers, express bus fees, etc) with various trip-based or multi-day-based passes (which don’t allow you to pay for transfers or express bus fees).

So, Dear Los Angeles Public Transportation providers, here’s why spewing advertising billboards about saving gas all over the city isn’t getting people on your busses and trains:

  • Make paying simple
    Seriously, I’ve lost count of the times I’ve driven to work instead of figuring out if I have exactly $1.50 for the trip there and $1.85 for the trip back (and calculating that cost in the first place). Heaven forbid I get on the wrong version of the bus I need to get back (see a lower point) and need to pay an extra amount. Take a hint from Hong Kong and London:

    • Make it easy to load cash on the TAP card (hint: online, in EVERY Metro station, and on EVERY bus)
    • Make the fares simple! Seriously, it’s one rate if you’re staying local, another if you’re going into a different “zone”, another if you’re a student, another if you’re a senior, another if you’re taking more than one bus. GEEZ! It’s easier to buy a car than take the damn bus once! Remember the old KISS rule – Keep It Simple, Stupid
  • Make the busses and trains run more frequently
    Some are fine, some aren’t. If a line runs less frequently than every 20 minutes, it’s basically useless. 5-10 minutes, and you’re talking about replacing my car. 10-20 minutes, and I’ll consider it if I don’t want to drive. 20 minutes, and I’m just gonna be spending my life at bus stops – no longer worth it.
  • Make the busses run reliably
    This one’s huge. I was all set to bus to work and cancel my parking until the day I got left on the street for over 40 minutes one cold night because a bus (scheduled every 20 minutes…) just didn’t show. The busses sole purpose is to get me somewhere – if it fails that purpose, I have to find something else to get me there. LA Metro repeatedly fails that purpose.
  • Make all transit lines use the TAP card
    “Can’t we all just get along?” Really, everyone’s got to use the same payment system to make the system usable. LA’s too big to have to guess at the three systems you might need to use to get somewhere more than a couple miles away (or even less than a couple miles away). The EZ transit pass is ok, but is only affordable if you’re going to only use public transportation; it loses the occasional rider.
  • Make the bus/train lines simple
    Sure, it’s a big city, and the system’s going to be a bit complicated. But at least try for simplicity: Let’s take the 108 Metro bus for example. One out of every three trips, the route extends into Marina Del Rey. Same bus number, different destination. Really? Who thought that would be a good idea? So if you’re waiting for the 108 and need to go to Marina Del Rey, and don’t notice that the head sign says “Fox Hills Mall” instead of “Marina Del Rey”, you just got stuck at the mall, and have to hope you have the extra buck fifty or whatever it is to get the rest of the way (whenever the right version of the 108 comes). Again, the bus just failed to get me where I need to go – time for another solution.

[ad#Adsense]Yeah, I know “running the bus every 10 minutes is too expensive”, and “there aren’t enough people on the bus to warrant it running more than every 45 minutes through this one section, but there is through this other section, and we don’t really want to have it be a transfer because the people coming in from Marina Del Rey would have to transfer blah blah blah”. And so, we widen the 405, because if you take the 761 into the valley, good luck figuring out how to get back (hint: it’s not on the 761). Make it easier to pay, faster to get places, and easier to comprehend, and maybe LA can join the list of world cities in which people who can afford a car use public transportation to get around anyway.