On the Path

Programmers Who Launch

My dad is a Vietnam Vet. He doesn't talk much about his war experiences, but one thing he did tell me is that there are two types of soldiers. Those who can pull the trigger and those who can't. This was brought to mind today after meeting with a fellow business owner and hearing the situation he's found himself in with respect to his software project. The business owner is working with an intelligent, experienced developer. But, after several years and many, many $$, he still doesn't have an app that he can use. His business has seen $0 ROI on his extensive software investment, even after all this time.

This got me thinking that there are two kinds of programmers. Those who launch, and those who don't. As a business owner or software project sponsor, my advice to you is to always look for evidence that you have a software developer/team who launches. If possible, start looking for this evidence before you start the project. Does this person or team have a track record of launched/live projects. Do they have working software out in the field that you can look at in it's native environment?

If it's a new person/team, or if you've already started, look for this type of evidence with your project. Is working software being delivered to you on a regular basis (weekly/biweekly/monthly)? Or do you get an occasional dog an pony show, displaying the software to you on a screen, but not available for you and your staff to use, experiment with on your own, interact with in between demos.

You should know in fairly short order if you have the kind who launches or not. If it seems to be the kind who does not, don't wait years. Cut your losses and start looking for the kind who launch.

An Open Letter to Restaurant Owners

Dear Restaurant owner,

I want to eat at your restaurant, but I need to find you first. You need a website. And not just any website. It has to work on a mobile device. If not, you might as well not exist anymore.

In the past few months, I have been out with my friends several times, spontaneously decided to get a lunch, dinner, etc. and had a bad experience with a restaurant's website.

Today's typical dining experience starts with a bit of research on a phone, looking for a menu. I start with the maps app on my iPhone, search for something like "Indian" or "Italian" around my current location, find a restaurant, go to the website, and I'd greeted with a message like "you must install Flash version 9 or higher" if I'm lucky enough to find your website at all.

You know what the cool kids call that? EPIC FAIL.

Even if I can see the website, I'm more likely to find a picture of the owner's family as if they are slaving over a hot stove, the history of the restaurant starting with the owner's mother immigrating in 1977, or a stock photo of a slice of pizza. If there is a menu at all, its an out of date pdf file I'm struggling to view on my tiny screen.

If you care about your restaurant, you should want your customers to find you.

What information should be at their fingertips?

When visiting a restaurants website from my phone, I want:

1. location (including phone number)
2. hours
3. menu

Anything else is just noise on a mobile phone... If I'm planning a catered event, I'll do that from my computer.

But I bought a package deal...

Yes, I'm aware that ground-up website design can be expensive, and restaurants often fall for the "Website for $29.95 a month" marketing ploy, where you get a "billboard-at-a-url" and a scanned menu. You are losing out. You need a real website.

Here's why:

Customers can find what they are looking for

You wouldn't imagine not having a sign outside your restaurant - a website is the same thing to the person actively looking for you. Restaurants think nothing of printing thousands of folded menus and sticking them on every car in a parking lot or every door in a heighborhood. Your website can have a far greater reach than that, and with immediate impact.

you can have a CMS to keep the menu up to date

For most restaurants, the menu on the website is like a time capsule. Dishes come and go... prices change... why shouldn't your website reflect that? With a content management system behind your menu, you can log in to update prices, add specials, etc. Why shouldn't your website be able to tell people what the soup of the day is?

You can tailor your SEO strategy

Try this: Put the name of your city and the type of food your restaurant serves into Google. (If you are in a big city, try your zip code). Is your restaurant's website on the first page? It should be. If you put in the name of your restaurant, are you the first result? If you're not, the first result is probably something like a restaurant review - and you have no control over that! Your worst customer could be the first thing people learn about your restaurant.

With your own website, you can easily influence how search engines view you. That is a topic larger than this blog entry though - its called 'Search Engine Optimization' or 'Search Engine Marketing'.

Further, by having your website as a real website (as opposed to flash or pdf), all your dishes become keywords Google can index. Maybe I'll find you because I searched on "Vindaloo" or "Pad Thai". All those words are pure SEO gold.

You can target your market more effectively

Visitors to your website can be tracked more closely than cattle with tags in their ears. Are most of your visitors coming from a particular neighborhood? Maybe thats the place to target with your door hangers. Is there a neighborhood thats not visiting? Send them a coupon for a free cheesy bread.

Ok, so how do I do it?

I'm not trying to sell you anything here - in fact, our typical projects are much larger than restaurant websites. I just want a better dining experience, so I'm offering you some technical advice:

Use 'Open Technology' standards

Make sure your website firm designs with html/css/javascript. Anything that requires a browser plugin to use (flash, Java, and most likely pdf), are non-starters for your marketing purposes.

Make sure your website looks good on small devices

I'll spare you most of the technical details, but with the kinds of tool we have today, a good website design scales down to work on phones, and scales up to work on big screens. On big screens, sure - show me your family in the kitchen. On my cell phone, echo the design with logos, fonts, and colors, but just give me the menu, hours, and location.

Search Engines are your best marketing tool

You don't need to hire an expensive SEO consultant - in fact, I think that most SEO consultants are the equivalent of Internet Snake Oil. Instead, just make sure your design firm eats and breathes the advice in Google's SEO starter guide. From your business' perspective, you should read a book like Search Engine Optimization (SEO): An Hour a Day or Internet Marketing: An Hour a Day to figure out how you can best market your restaurant.

Thats it! I hope you find this advice useful. Remember... I want to eat your food, I just need to be able to find you when you're just down the street.

What is Crowdsourcing?

We’ve all see the online CAPTCHAs that make you type in a pair of garbled words to prove you’re not a spam-bot. What you might not know is that by doing this, you are participating in crowd sourcing, a way to gather small amounts of data from large numbers of people. In this case, many of those words are used to digitize old books from the Library of Congress. When a computer can't read the scanned text, it "crowd sources" the unknown word. Once two or more people enter the same word for the garbled image, the computer now knows what that scanned word is. It’s pretty amazing to think a few seconds of time from millions of people can create public works of real value. This is the value of “crowd sourcing”.

Can your business use crowd sourcing? It works well for things that are “hard” for a computer to figure out, but easy for humans. For example, “which of these pictures contain pasta dishes?”. Amazon has a service called 'Mechanical Turk' which farms out work like this to interested people in exchange for micro-payments. Say you're willing to pay a penny a picture to have your images categorized or tagged. Amazon’s service will match up your job with interested parties. Amazon gives you back the results just as if a computer had processed the images, but instead the work was done with human intellegence. The results can be integrated into your data, allowing your systems to act on the new information. In fact, we’ve used services like this to verify that profile photos on a social network were all 'G-rated', and to generate transcripts for video files.

Can your business make use of crowd sourcing?

Rails3 and FullCalendar

Fullcalendar is an impressive calendar widget for JQuery, showing you events on a month, week, or day view, and letting you drag them around to reschedule them.

It needed a good sample app showing how to use it in Rails 3, so I wrote one.

Rails3_fullcalendar is a rails application that tries to live up to the rails3 notion of restful ideals.  It does this thanks to the power of Adam Lassek's jquery.rest plugin, which handles all of the wrapping of the jquery.ajax method into create, read, update, and delete methods, and also deals with the complexity of the token's rails uses to avoid cross-site scripting attacks.

Download it from github, run the migrations, and fire up the app.  You'll see an empty calendar, and scaffolding for adding events.  When looking at the calendar view, you can drag events around to change their date and time.  Dig into the code to see how it works.

I'm going to need to prepare a longer rant regarding timezones, but fullcalendar does something nice - it respects timezones (as long as you send it the right time format in the json), and normalizes everything to the local timezone on display...  Now if I schedule something for 12:00 noon in Washington DC during Eartern Daylight Time, it'll end up on the server as 16:00:00 UTC on the server, and if viewed by someone in California will show up on their calendar at 9:00am.

I have some future plans for this demo - including having multiple schedules, and then showing how to overlap them on the same calendar, with the events from each schedule showing up in their own color.  With a view like this, someone can have a calendar 'command center' view, dragging around events from different people's schedules until conflicts are resolved.

RESTful Search

Last night we capped off a great weekend at RubyNation 2011 with a wrap-up dinner (thanks Dr. Nic!). I'm proud that so many CodeSherpas had a hand in putting together this conference over the years. Anyways, during the dinner a fellow attendee, Robert, asked me for my thoughts on RESTful search. "It's just the query string on the index, right?" That is a very interesting question, and as it turns out there's more than one way to do it...

We are all familiar with search and use Google every day. Perform a Google search and it gives you results. But "search" itself is a verb - an activity (bear with me if this seems a bit pedantic).

When using Google, we are really interested in web pages or sites related to our search term: a set of resources related to that term:

  term ("fast cars") -> search (submit to Google) 
    -> resource (a list of web pages related to fast cars)

We will use this as our guide to develop a RESTful search service. I will make use of some Rails conventions in my examples below, but the concepts here apply to any RESTful ideal.

Let's say I'm building a web site for a fantastic Mini dealership, and my site includes search for all cars on the lot. I will need to answer questions like:

Do you have any red & white Mini Coopers with superchargers?

Option 1: The query string!

  Yes this is very obvious.
    GET => /mini_cooper_inventory
  Returns my entire inventory
    GET => /mini_cooper_inventory?color="red"&color="white"
        &supercharger="true"
  Returns the portion of my inventory matching the given
  query parameters

Option 2: A filter resource.

  Aha! I have played a trick on you in Option 1. We were
  already using a filtered resource to see only those
  Coopers in our inventory. We excluded cars that have
  been already been sold, or those on order or in transit.

  To think of filters RESTfully:
    GET => /mini_coopers
  Returns all Mini Coopers that have anything to do with
  my dealership: ones that I have sold, ones that are in
  inventory, and ones on order.

  Because these are such commonly used resources, instead
  of doing a query every time I wanted to look at my
  inventory:
    GET => /mini_coopers?status="inventory"

  I have a dedicated another resource:
    GET => /mini_cooper_inventory

  In Rails you would perform the search in the #index
  method of this controller, and then narrow by any
  other query parameters. A note of interest, the
  mini_cooper_inventory is not backed by a model of
  it's own. REST is not CRUD, but that is a topic for
  another day.

Option 3: A search-results resource

  This is probably useful when you have a really
  complex search that spans several resources. Let's
  say the IRS (yikes!) is askng me for all details on
  all sales made by Duzzy Cheetham or his family in
  the past two years. RESTfully speaking, I'm potentially
  dealing with any of a number of resources in my system:
    mini_coopers
    customers
    sales

  I could use one of the previous 2 options, and search
  for sales matching certain critera:
    GET => /sales?customer_last_name=Cheetham
          &customer_last_name=Swindell
          &date_range=2009-04to2011-04
          &detailed_report=true

  But at this point they query string (Option 1) does not
  seem to be a good fit. I could create a search object:
    POST => /search
  But again, this is not really what I am after, unless
  I am giving users the ability to save searches. What I
  really want is some sort of customer report:
    GET => /customers/:duzzy_cheetham_id/customers_report
  I want to see all purchases made by Duzzy Cheetham and
  his family:
    GET => /all_purchases_made_by_duzzy_cheetham_and_his_family

  Neither of those requests are really reusable or useful
  outside of this one search. Let's try again.
    GET => /search_results/new
  This is the form for doing a complex search (familiar to
  those of you using Rails). Not bad. What's next?
    POST => /search_results
  This creates a new search results report that matches my
  search terms, including date range, customers, and
  whatever else I want to throw in. And if I want 2 types
  of searches, one that returns a list of results, and
  another that summarizes results in some type of report:
    POST => /search_results
    POST => /search_results_reports

  The name of the actual resource is up to you. The search
  submitted can even be given a name that allows users to
  save and re-run searches:
    POST => /search_results/:saved_search_id

Anyways, there are many options when it comes to organizing your applications to work RESTfully - for the way the web was designed. I hope this example gives some food for thought.

Beautiful Visualization

Last night we performed some upgrades and restarted a server with nearly a year of uptime.  This morning I was checking on the status of the server, and saw this graph.  It is a beautiful example of the kinds of things you can see with Munin.

 

You are looking at a graph from munin, showing the usage of memcache of a large Ruby on Rails application.

After the server restarted, the cache was empty.  As the server traffic picked up this morning, more and more database calls and page fragments were generated by users hitting the site.  They were tucked away in memcache so they could be served up faster to the next visitor.  As we get more traffic, this cache fills up, and the website actually gets faster.

The performance gains aren't the subject of this post though - I thought this was a beautiful representation of a day in the life of a server process.  This represents one day period, with time going from left to right, and the three lines representing the amount of data in bytes (green), the number of objects (whether that be objects from the database or pre-rendered pieces of html - red), and the number of connections our rails processes are making to the memcached server (blue).

What does this show me?  I can see that memcache is doing its job - that the rails app is putting data in and getting it out.  I can also see that the cache is filling up... based on the 'hockey stick' curve, I can see we have allocated enough memory to hold the data we are putting in there.  If we hadn't allocated enough memory, I would visually be able to see it 'hit the ceiling'.

I can also tell things about the system overall by comparing to other graphs from munin and other tools.  Comparing this to graphs of mysql queries, I can see the impact of using memcached on mysql (by the number of reduced database queries) By comparing it to processor utilization, I can see the amount that pre-rendering reduces processor load (since we don't spend as much time rendering).

RubyNation 2011 is a Wrap

It is a lot of hard work putting on a conference like RubyNation; Three CodeSherpas are on the organization committee, out of a total of 7.  I'd like to thank Gray Herter for being a driving force behind this conference... it's his baby, and without him, there would be a gaping hole in the Ruby Community in the Northern Virginia/DC Metro area.  I'd also like to thank all of our sponsors.  Without them, this conference would still just be a dream.

Every year the conference gets better and better.  With a live event, there are always issues that have to be solved in real-time (like the programs being delivered late), and each year we hold a retrospective after the conference to figure out what we need to improve.  This year it seems like it was only minor things - nothing that couldn't be handled on the spot with our great staff of volunteers.

If you attended, I'd lke to remind you to please rate the talks you attended.  Nothing helps us improve the conference like real feedback.  If you didn't attend, you missed a great event; don't miss it next year!  Make sure to visit the RubyNation website early and often.  We'll have a signup for next year's announcements available soon.