Buzzbeeper.com is open for business

Buzzbeeper is a simple, easy-to-use, low-cost cloud-based service that gives your customers a fun, 10-second survey to find out how you’re doing (via text message, twitter, or telephone). And when a customer isn’t happy, it “beeps” you before they even leave the store so you can fix the issue on the spot. Plus an integrated social network referral system. Plus coupons. Plus text message campaigns. Some very exciting “beta site” deployments suggest this is a real “game changer” for retail businesses.

Buzzbeeper is a new cloud-based telephony app built upon Heroku, Amazon AWS, Twilio, and Tropo.

“Baba Pardner’s Yoga-in-a-cup Chai”

Sometimes I bring a thermos of chai to yoga class (or meetings).

According to my scientific guesstimates, drinking one cup of chai is equivalent to 23.4 sun salutations.

Here’s my recipe that makes 8 cups.

In 8 cups of cold water, add:

  • 8 Cinnamon sticks about 4″ long
  • 1 TBSP shell-less Cardomon seeds (whole, not ground, but crushed a little bit if you have a mortar and pestle)
  • 2 TBSP whole black peppercorn
  • 10 whole Star Anise seeds
  • 10 thinnest-possible slices fresh Ginger
  • 1 TBSP cloves
  • 2 TBSP real vanilla extract
  • 1 TBSP fennel seed (optional, but I like it)

Bring to a light boil, cover, simmer on lowest setting for 4 hours or more (I do 6 hours).

Add 8 TSP good loose tea (I use half green jasmine and half black assam).

Simmer covered (still lowest setting) 60 minutes. Stir once or twice. Simmered so long, the tea itself will be slightly bitter, which nicely (and authentically) offsets the spices and the honey and milk.

Add 1 cup cold whole milk. Simmer (lowest setting) covered another 20-30 minutes. Stir once or twice.

Turn off heat. Add 1/2 cup honey. Use the good stuff. Stir in. Taste. Add a little more milk and/or honey to taste. It needs to be sweet… experiment with adding even a little more honey to a cup of chai and find out for yourself what the “sweet spot” is.

Pour through strainer into glass jar. Serve and enjoy.

Stays great for 5 days or more if you refrigerate it promptly. Easy to reheat, or, on a hot day enjoy over ice.

Adding SSL to an app hosted at Heroku

[POST UPDATED 9/7/2012 TO REFLECT NEW HEROKU SSL ENDPOINT SETUP]

A friend needed some help adding SSL to their custom-domain-name app hosted at Heroku, and it wasn’t entirely trivial. We found bits and pieces in several places, but never found clear and complete instructions.

I previously recommended rapidssl.com even though their docs are pretty abysmal. $49 for one year for a single-domain certificate, and it took them about 1 hour to generate and email the certificate. However, a year later we bought a rapidssl certificate from cheapssls.com for under $10

Suppose your app domain is myapp.mydomain.com, your

1. Generate the command that generates the “CSR”

This wizard worked fine and has clear directions on what goes into each field.
https://www.digicert.com/easy-csr/openssl.htm

However, you’ll need to change their default country code from “us” to “USA” the lowercase ‘us’ isn’t correct. Click Generate. That creates the Unix command needed to generate the CSR.

2. “cd” to whatever directory you want to save your keys in. We put them in the “allmyapps” parent directory of the Heroku app.

3. Copy the command and paste it onto the command line of your unix shell (we used Mac terminal). It looks something like openssl req -new -newkey rsa:2048 -nodes -out myapp_mydomain_com.csr -keyout myapp_mydomain_com.key -subj "/C=US /ST=Washington /L=Spokane /O=myco inc /CN=myapp.mydomain.com"

4. that generates a text file called myapp_mydomain_com.csr and one called myapp_mydomain_com.key Copy the .csr file to your clipboard. Type
cat myapp_mydomain_com.csr
then copy everything between and including the lines that start —–BEGIN and —–END

Note: Heroku won’t let you have a passphrase in your key file, so don’t add one. Using the command shown, we weren’t prompted for one, so it wasn’t a problem. I have seen blogs that refer to removing the passphrase.

5. Go to cheapssls.com [ we discovered cheapssls.com resells rapidssl certs at a fraction of the price] and click the button to get a single-domain certificate and choose the rapidssl option for under $10. Select “one year” assuming that’s what you want. Click Continue.

6. Paste the .csr file you created/copied to your clipboard in steps 3/4 into the big text box and click Continue.

7. The website will parse the CSR file and display the information encoded in it… be sure you have the domain name right, etc., then click Continue.

8. Fill out your admin/tech/billing contact info, which unless you’re doing this for a corporation will likely be you in all three cases.

9. Complete the order process on rapidssl.com. It includes entering a phone number so their automated system can call you to confirm you draw breath. The onscreen instructions are simple. The order process takes maybe a minute or two.

They will give you a list of possible email addresses to send your certificate, receipt, etc. One of them should already work for you (the email contact for the domain name), if not, you have to create a new email address and get it working BEFORE you go any further. In our case, we had to go to Godaddy and create a postmaster@mydomain.com forwarding address since we could not get email at any of the choice listed.

10. After 49 minutes (in our case) rapidssl.com emailed our certificate. Two actually… one is a ‘chain’ certificate which we deal with soon.

11. You need to take the certificate text from the email and save it into a .CRT text file in the same directory you used earlier. I suggest using the same naming convention as the CRT generator used, so you’d
(a) copy to your clipboard the FIRST certificate text (including those begin/end dashed lines) then
(b) type into your unix shell: cat > myapp_mydomain_com.crt then Enter
(c) paste the certificate text then
(d) hit Enter then
(e) press control-D to terminate the file.
Verify it: At the command prompt type cat myapp_mydomain_com.crt (NO > this time) and verify the file got created correctly.

12. Do the same thing for the intermediate ‘chain’ certificate (the second certificate in the email from rapidssl) using cat > myapp_mydomain_com_chain.crt

13. There is NO step #13. It’s bad luck.

14. Now create the .PEM file. Near as I can tell, it simply has your main .crt, then your chain .crt file appended to each other in that order. Here’s the sequence of commands we used:

openssl x509 -in myapp_mydomain_com.crt -out myapp_mydomain_com.pem

openssl x509 -in myapp_mydomain_com_chain.crt >> myapp_mydomain_com.pem

15. You need to enable the SSL ENDPOINT addon with: heroku addons:add ssl

16. Now, finally, you get to use the heroku gem to schlep the key etc over to your heroku app. That means (which I never saw documented) you need to cd into the directory with your heroku app. In our case that’s one directory “down” from where we’ve been working… which measn onc ein that directory when we refer to the .key or .pem file we need ot point ‘up’ 1 directory… In your case, adjust the path to the .key and .pem files according to where you store them.

heroku certs:add ../ssldir/myapp_mydomain_com.pem ../ssldir/myapp_mydomain_com_chain.key

17. Heroku instantly displays a message telling you to add a CNAME to your DNS that points to some long name similar to appid-1234.herokussl.com

Since the CNAME already existed in his DNS, we edited it, changing it form proxy.heroku.com to the long domainname they specified.

18. A few minutes later, it was all working… going to https://myapp.mydomain.com worked fine, no certificate warnings, etc. (DNS can take a while to propagate, but I’ve found it usually happens within 5 minutes.)

FINAL TIP: you may need to reboot your PC (or flush your dns cache) for your PC to “see” the new DNS settings because the old settings (proxy.heroku.com) are probably cached on your PC. On a Mac OSX 10.5 you’d type dscacheutil -flushcache then type host myapp.mydomain.com to see if the DNS changes have taken effect.

Someday we may fail to find the images we need on istockphoto. But not today.

Huge selection of photo and vector art, good search/lightbox capability, low cost, essentially unlimited use (for many purposes), easy pay ‘n download.

My favorite feature? Ability to download reasonably clean watermarked comps so we can play around with storyboards and mock-ups until we decide exactly which ones to use.

What’s not to like? http://istockphoto.com

Web CSS templates that did not disappoint… Templateworld.com

Often a friend will ask me to help them with ideas for their website. Most of the time a turnkey pre-built website offered by most hosting providers will suffice, so that’s what they end up doing.

But last week a friend needed help with a site that needed some flashy storyboard/slideshow features and it all needed to look very nicely crafted. But spending hundreds of dollars (if not thousands of dollars) on the website just wasn’t in the cards.

Thus began my first-ever descent into the world of ready-to-go web templates. It was actually quite interesting.

I won’t even address the zillions of sites offering “free templates” other than to say from what we saw (after looking at hundreds of examples) you (a) get what you pay for and (b) you cannot even tell what you are/aren’t going to get because most sites have a single graphic preview that, well, fails to show how poorly the page source code is designed.

So the bad news is, if you’re serious enough about your website to spend the time to create it, you’re going to pay something for the design.

The good news is, for $50 you can have a selection of nearly 1000 unique designs in 3 or 4 color variations each with all kinds of interactive javascript goodies pre-baked such as sliders and slideshows. In fact, for $50 (one time, not a recurring fee) you can download as many as you want, although limited to 20 per day. (This was helpful because my friend used one template for his site, but downloaded a few other templates just to copy/paste some cool style/javascript goodies from other sites… mix n match.)

For example, my friend went with http://demo.templateworld.com/full-websites/123a then modifed the images and tweaked some of the colors.

Curious about the quality of the template implementation I rolled up my sleeves to help my friend tweak his site. His modifications were easy to do because, by golly, the template CSS is properly designed, documented, and then used in the 9 pre-built sample html pages — we did not see a single example of someone manually over-riding the stylesheet, which we often saw on the “free” templates.

Plus support! Saturday evening we we sent an email asking how to turn off the automatic advance between slides on one of the javascript gizmos the template included. Got an email back an hour or two later.

$50. One time. Instant online activation/download permission. With support. Wow. Templateworld.com

Great support from a surprising corner: Godaddy

Actually it’s not surprising, their 24×7 support is excellent, and they have mastered the art of turning support calls into selling updates, renewals, and upgrades.

But yesterday was interesting. I called about a slight issue I had installing an app on a domain. They answered within 3 minutes and answered my question, stayed on the phone while I did it, then explained what the next steps would be as the app was automatically provisioned (database created for me, etc., etc.).

About 5 minutes after the call, the same guy called me back, saying he was reviewing the progress and noticed my DNS setting still had the domain forwarded and explained what I needed to do now so I would be able to access my app once the provisioning was complete.

Color me impressed for such proactive support!

Lemons to lemonade when the airline strands you

I always though this was kind of obvious, but a number of friends thought this was clever so I’ll pass it along…

Last week I was supposed to return from NYC (Newark, the only airport to use when flying to/from NYC) via Denver back to Spokane. Weather delays the morning of the flight meant not only would we miss our connection in Denver, we could not get a flight the next day either. So we’d be stranded in Denver, on our nickel (no vouchers, since weather delay).

When that happens, I look at the upcoming flights, pick a place I’d much prefer to be stranded instead (San Francisco in this case), and without exception I get the flight I want if (a) there are seats and (b) if it’s closer to my destination than where I’m starting from (e.g., the right general direction) and (c) I point out they won’t be giving me vouchers so the least they can do is send me where I have friends to stay with.

So the next day, my daughter and I had a nice day in San Francisco, saw some friends, ate some dim sum and tapas… essentially a free round-trip for two to SF compliments of United.

Squeeze that lemon.

Outsourcing success tidbits

Last year we did a pretty cool “local O2O” (Online-to-Offline) project with a local TV station. The budget and timeframe were tight. And this project simply begged to be done with Ruby on Rails for a host of reasons.

We came in on-time, on-budget, with an exceptional end result after using elance.com to find a team in India.

Aside from insisting on and talking to references and seeing sample work, here’s a few tidbits we learned about making that work. To get a good bid (always go fixed-price) you have to have a good spec. Some keys include breaking the project into Phases, starting with a clear spec for Phase I, breaking that into at least 10 milestones. Some ingredients for a good spec are:

  • A full database schema. A fuzzy idea of the database, and/or turning the schema design over to anyone who’s not proven to be exceptional at it, is a train wreck. I repeatedly heard from good developers that a well-designed database lets them bid one-third to one-half of what it would cost otherwise. Take the money you’ll save and invest it in the schema design.
  • Mock up screens. You can not rely upon text, you have to show the fields, the buttons, etc. (It’ll help solidify your thinking, too.) Let me say this. The only three spots where we ran into ambiguity issues were the three places where we played a little loose on the sample screens, thinking it was “obvious” what those screens would look like.
  • Spec the environment. If it has to run on Heroku, make that clear.
  • Spec the unit tests. Contract developers in my experience do lousy job at this unless unambiguously required to do it right. And it’ll cost a lot less if part of the original bid than if you say later “oh hey, what about hitting X% unit test coverage.”
  • Include 2 or 3 major “gotchas”. Purposefully put at least 2 or 3 things into your spec that don’t make a lot of sense or contradict other elements of the spec. See who catches that. It’s instructive in picking a development team. As a trivial example, suppose part of your spec you’re going to run at Heroku. Put some aspect in your spec about storing files in some folder on the website. If they know their stuff they’ll immediately point out Heroku has no local file system, that you’ll probably want to push files over to S3. It’s a fair test IMO, because those sort of gotchas will happen anyway, so you’re entitled to ‘test’ developer’s ability to catch them before they spend you money writing code that won’t work.
  • Daily involvement. Generally, the closer you can come to full time co-involvement, the better the results. We setup a testing tag-team to test every feature as it was implemented, and actually designed the spec for incremental development and testing.
  • Spec comments and readability. I’m all about comments (lots) and code clarity (not using every cool shortcut the language offers, favoring understandability by humans over saving a few CPU cycles.) I provide examples of obtuse but fun little shortcuts that I don’t want to see, and the old fashioned way I do want to see it done instead. If I really wanted uber-dense tight code I’d go back to doing it all in APL or Forth. What I want is code anyone can look at and understand months from now.
  • Git / github. If you aren’t using it, do.
  • Daily code review. Review code as it’s checked in. Catch bad habits early.

Obviously that’s the tip of the iceberg, but those simple tidbits saves us a lot of time and hassle.

IMO Tropo not ready for prime time. Went with Twilio.

Subtitle: “When you are betting your ass on a platform, if you have a choice of platforms, bet on the company that has to deliver an actual working solution to survive, not on a company for whom the platform is an interesting diversion from their core business.”

I like the folks at Voxeo a lot. But I had to shut down an earlier business because their business model of paying per-port per-year is unworkable for a business with significant peaks and valleys in usage. (The business was a voice message broadcast system for schools, etc., where virtually all of the user activity happens within fairly narrow time frames. But after a short eval period we had to pay for ports 24x7x365 even though our customers’ usage occurred during perhaps 10% of a typical week. And since users expect messages to go out in a timely way, simply having 1/10 as many available channels was not an option.)

So I was very excited a year or two later when they introduced Tropo, cloud based telecom with no per-port fees, pure pay-for-use business model. even though it was too late for the prior business.

When a new project that required voice and SMS came along, I thought Tropo would be perfect. But Twilio looked interesting as well. We built a fairly significant app that handles inbound and outbound voice calls and SMS, and looking at the claimed features, Tropo looked like a hands down winner. Nonetheless, we architected the product to be relatively platform neutral “just in case.”

Once again, my belt-and-suspenders approach to app architecture paid off because Tropo was a lot of cool things, but “ready for prime time” is not among them.

Going into the project, here’s what initially convinced us to incorporate the Tropo platform:

Supposed advantages of using Tropo over Twilio:

  1. Tropo is based on Voxeo, a mature and highly profitable company/technology, Twilio is a startup
  2. Tropo has voice recognition, Twilio doesn’t
  3. Tropo apps can (supposedly) send/receive tweets via an associated Twitter account, allowing you to (supposedly) build very cool automated Twitter apps. Twilio doesn’t. In fact, when you go to tropo.com their headline reads “Add Voice, SMS, Twitter, and IM to Your Applications”
  4. Tropo has 24×7 tech support, Twilio doesn’t.
  5. Tropo is (supposedly) more robust, built as it is upon the Voxeo platform.
  6. Tropo has a very generous “free for development” policy so you can get up and running without paying for phone numbers and messages.

We dabbled with both at first, to get our feet wet, then proceed to build our app on Tropo. Addressing each of those (supposed) Tropo advantages in order, here’s why we were absolutely compelled to switch to Twilio.

  1. The overall impression I got was that Tropo being a disruptive pay-for-use business model offered by hugely successful company is that, well, they’re just dabbling with this… that Voxeo has no current profit motive to make it work right… their mainline business is (a) doing just fine thank you and (b) might even be disrupted if Tropo works too well. That’s just my impression, but it’s based on the following:
  2. Voice recognition. This claim is actually true, although Tropo does not offer (built-in) the full range of VXML grammars that make voice recognition practical. And we found that ambient noise makes it unusable for Real World Apps if your users are commonly on cells, in restaurants, or cars.
  3. Twitter. UPDATE: This seems to have been fixed recently. So far so good. In my experience, attaching a Twitter account to Tropo app works for maybe one day. Then the connection to Twitter silently dies, and there is NO way to tell it’s happened. YouR app just stops receiving tweets. There is no API to verify or restore the connection. You have to remove the Twitter account, then re-add it, manually. But remember… you have no idea when your Tropo/Twitter connection is broken. We tested several Tropo apps, with several Twitter accounts, over several weeks and the results were absolutely repeatable… Tropo apps fail to respond to Tweets within a day or two. It just plain doesn’t work. And it’s not Twitter’s fault… another thing we tested was whether an app like Hootsuite would ‘keep’ it’s connection to Twitter persistently and during the same several weeks of testing, had zero problems with Hootsuite. Now, I’m all about ‘things will get better over time’ except… well… when the company’s headline says it works… it kinda needs to work.
  4. Tech support. Actually this was a tie. We’d send support requests at midnight and get a prompt “I’ll have someone look at this” reply from a human at Tropo, but the actual answers came faster from Twilio about half the time. And on some major issues (Twitter, ‘lost’ SMS messages) it took Tropo a week, even two to respond, whereas we never waited longer than a working day from Twilio.
  5. In our experience, Twilio is more robust, period. Let me count the ways:
    • UPDATE: this ‘feature’ was finally removed so they no longer opt-out your users for you. If your user texts the word STOP to your Tropo app, your app does not get to handle the opt-out… Tropo does it automatically, and silently throws away all traffic to that user. Your app never knows about it (neither does the user!), and for all you know your messages are going through. This is wrong. A telecom platform should not silently throw away messages. (Twilio doesn’t presume to opt-out your customers, they let your app do it so you can keep track of it!)
    • Tropo silently fails to deliver SMS messages if your app sends them too fast. And there’s no specific rate, just general guidelines of ten per minute. Twilio lets your blast them out as fast as it wants, then Twilio handles the rate limiting to 1 per second. In other words, Twilio is designed for reliable message delivery, Tropo is “best efforts” and (even worse) does not inform your app when something went wrong.
    • To simulate modest concurrent user loads, we wrote a two very simple tester apps: one app sends 10 SMS messages to another app. We never, not once, got all 10 SMSs to make it on Tropo. Twilio never missed a message. Tropo support said that’s strictly an artifact of apps-talking-to-apps related to their gateway, that it would not happen if multiple cell phone users were talking to, but…. would you bet your ass on that? (Me neither.)
    • Tropo doesn’t have the very helpful callbacks Twilio offers that let you do post-sessions.
    • There’s five more items on my list, but candidly, IMO the issues of Tropo discarding or losing messages, silently, under multiple circumstances, should be enough to cross them off any developer’s list.
  6. Free vs pay-for-use during development. Tropo is free. Twilio isn’t. At Twilio a phone number costs $1/month at Twilio. Text messages or phone-minutes are 2 or 3 cents each. Dude, if you’re building a business do you even care about $20 to $40 in telecom charges during a month of testing? (Me neither.) What you do care about is building something that works reliably when your users use it.

So that’s why we are deploying based on Twilio, not Tropo. (Though we left our Tropo code in place for when they get it together on the message-delivery-reliability front, and get Twitter working, we’d love to use that feature.)

But the moral of the story is clear to me: if your providers aren’t betting their asses on doing a great job for you, you may not want to bet your ass on their services. Ditto hosting, web design, you name it.