Building A Better Digital Bat Signal - Part 1 - The Plan

The Problem

Some people find it difficult to unplug from their day job while on vacation. Not me. When we travel, I quickly transition from work being a primary focus to a distant memory.

This is usually a good thing, as travel is precious and I want to make the most of it. But this is problematic, because even when I'm away I want to support customers who depend on me.

The compromise that I've had in place for years is to tell my clients that if they find themselves with a critical emergency, drop me an e-mail with URGENT in the subject line. I then keep an eye on my inbox, and jump on these messages as quickly as possible. This lets me leave the rest of the messages in my inbox to pile up.

What's nagged at me, however, is that my system requires me to monitor my email. This is less than ideal for everyone. I'd like to be able to stop checking email altogether, and my customers would benefit from a system that is not susceptible to human error.

Essentially, I've set up a bat signal, now I need to write some code to alert me if it's lit up.

The Fun Solution

My first thought was to build some wearable tech, perhaps a pendant that would serve to announce the presence of an urgent message. The jewelry would be delightfully simple, signaling state by glowing in one of three colors. Green means all is good, yellow means that I've lost connection to the status-checking service and red means that I have an urgent issue.

While primitive, this color based UX would let me fully unplug, yet react quickly if there was a problem.

The tech to build such a device is inexpensive and readily available. What I'm after is little more than a bluetooth compatible micro controller, a grid of LEDs and some odds and ends to tie them together. This can be simplified even further, if I used a platform like the Circuit Playground Bluefruit, which has both Bluetooth and LEDs built in.

Oh my, would this be fun to build. And there are a number of tutorials on adafruit.com that seem like a great place to start. Ones that jumped out at me include: NeoPixel LED Heart Necklace, DotStar Fortune Necklace and the NeoPixel Ring Clock. All of these involve an LED based piece of jewelry powered by a microcontroller.

But alas, there are a number of demerits with a hardware based approach. In my mind's eye, the pendant is compact and smart-looking. Yet, the project will start its life as a series of raw components and a heap of wires. Turning this jumble of components into a compact and comfortable to wear piece of jewelry is non-trivial to say the least.

There's also the question of battery life: how big a battery do I need, and how can I camouflage it and make it comfortable to wear?

If I did manage to produce my magical pendant, would I be happy to have another piece of tech to bring on travel? That's more hardware to keep track of, charge and generally debug. Will it be worth the hassle?

And finally, the software to power the pendant is broken into three stages. First, there's code that runs on a server to determine the status of my inbox. That code will send a message to my phone. Next, my phone will process this message, and forward it to the pendant via Bluetooth. Finally, the pendant's microcontroller will convert the message from the phone into a glowing LED.

A far more practical phone based solution calls for precisely these first two steps. So, the smart play is to build a phone version of my bat-signal detector first, as I'll need to write this code anyway. In the future, I can opt to add hardware to display this status in a novel way.

So yeah, while it's incredibly tempting to take the hardware based approach, the ideal MVP should rely on the hardware I already own and carry everywhere: my phone.

The Tasker Solution

While a custom hardware solution is sexy, an Android Tasker based solution should be easy. My plan is this: on a Linux server, use the Gmail API to determine whether I have an unread message in my inbox with the word URGENT in the subject line. If so, then my inbox status is urgent, otherwise, I'll consider the status as ok.

Next, I'll send this status as a message to my phone using AutoRemote. AutoRemote is an amazing service that delivers messages to any phone from any system with a web request. In the case of a Linux server, this can be accomplished with a curl command.

On my phone, I'll use Tasker to react to the AutoRemote message. Specifically, I'll map the status message into a background image and then call SetWallpaper to make this new image my background.

In short, a customer will email me with an urgent message, and in short order my phone's background will change to something attention grabbing. That means I don't need to check my email, I just need to interact with my phone, which of course, I do throughout the day.

If all goes well, in less time than it would take to figure out what hardware I need to buy to build the wearable, the entire project can be completed.

Let's do it!

Visting St Louis: From Jail to the Arch

[Composed: 11/3/2023]

I just got back from visiting one of my long-time customers in St. Louis, Missouri. This customer specializes in jail communications. Think specially secured Zoom for prisoners and their loved ones.

This has been a fascinating field to write code for, as it has intense security and legal requirements that must always be met.

While I've worked for this customer for years, this was my first visit and very much felt like a homecoming. When the company started, it consisted of a few individuals; now they have grown into a truly impressive operation.

After our meetings, they asked me what I wanted to check out in the area. Simple: While I wanted to see the famous St. Louis Arch, top on my list was to go to jail. I was hoping I could see the system that I'd been working on for so many years actually deployed in the field.

They were kind enough to oblige, and in relatively short order, I found myself face to face with a hardened kiosk in a local jail that was running the comms software I'd helped build. We got a full tour of the small facility, at least the parts that didn't contain active inmates. I even got to hang out in one of the cells they use for isolating prisoners. It was all quite the experience.

After leaving jail, we made our way to the Arch. While I'd certainly seen pictures of the famous Arch since I was a kid, I'd never appreciated just how massive it is. Nor did I realize that you can go inside of it.

In the lobby, while tickets were being bought for our group, I noticed an obviously 1960s-era tram car. Hmm, I thought, back in the day, that must be what they used to ride up to the top.

Eventually we found ourselves lined up outside narrow hatches, waiting to ride to the top. The doors opened, and people climbed out. At that point, I realized that the retro car I'd seen in the lobby wasn't an artifact; it was a preview. Four of us squeezed into our tiny car and up we went.

The ride takes a few minutes isn't particularly scary. A few times, my brain tried to chime in to trigger a fear response, but I was like, "Brain, chill. It's a fancy elevator ride. We're fine with elevator rides."

The view from the top of the Arch did not disappoint, though again I found my brain trying to convince me to panic. I kept reminding myself to stay cool; the Arch hadn't been blown over in the last 60 years, and it wasn't going to blow over today.

After the Arch, we partook in another St. Louis tradition: eating Ted Drewes Frozen Custard. Now, this is a tradition that I can fully get behind.

Upon ordering, they asked me if I wanted concrete or not? I mean, how could I not want concrete? Of course, I had no idea what they meant, but it was ice cream, so what could be bad about it? Apparently, 'concrete' refers to a "shake so thick that it is served upside down".

At the end of the long day, our little group returned to a shuttered office so I could grab my rental car and head to my hotel. As we pulled into the parking lot, a system alarm went off. In a few minutes, our group had laptops out on a picnic table and were debating the source and fix for the alarm. As I problem-solved with fellow programmers, in person as opposed to over Microsoft Teams, I had to smile at what a surprisingly meaningful way this turned out to be to close out the day. We'd gotten back to our roots.

You've got Questions. I've got Answers. Finally.

If you have an online business, it's a no-brainer to offer a FAQ section on your website. And yet, for years, my website went without this basic page. I'd always been too busy, or had some other execuse, to put it together.

But no more! I finally forced myself to focus on this, and a few hours later the Ideas2Executables FAQs page was born. I've never been so excited over a list of questions and answers before.

Can you think of any business or software development questions you'd like answered that didn't make the list? I'm a question-answering beast now!

When Software Does Good

Below is a video of one of my clients talking about the American Sign Language educational site he runs. One of the many things I love about my job (besides the pants-optional dress code), is getting to help folks change the world. In this case, I may not be the one teaching the parent to help understand their child, or allowing communities to more deeply connect--that's Paul's gift. But I'm proud to do my part to give him the tools so he can work his magic.

View the video

Implementing a weekly hours summary using the Freshbooks API

It's official: we're moving the accounting side of our business away from Quickbooks to Freshbooks. Shira handles the financial side of things, so the switch doesn't have a huge impact on me. It does mean that the home-grown Google Spreadsheets solution I was using for tracking my time is being replaced by the slicker Freshbooks UI. And so far, I'm OK with that. I'm even more OK with the fact that Freshbooks has a Linux command line time tracking solution, which I haven't setup yet, but am excited to play with.

While Freshbooks has many nifty features (and more importantly, it's far, far lighter weight than Quickbooks), one that a few of my customers like seems to be missing. I wrote some custom PHP code to mail folks a weekly summary of the hours I've spent on their projects. That way, we avoid any end of month surprises. Because my previous time tracking solution was Google Docs based, writing code to pull from the spreadsheets was easy. Luckily for me, Freshbooks offers an API and it's just as easy to use.

This last weekend I whipped up a quick PHP script that I could wire into cron. Once a week, it grabs the appropriate time entries from Freshbooks and sends them in an e-mail to the customer. You can view the code here. If you find yourself needing some feature Freshbooks is missing, perhaps it can be of some use to implement it?

Here's a few notes that may be handy if you want to try running this code yourself:

Supply your own .conf.php file. This file contains all the sensitive information about my configuration, so obviously I didn't check it into Freshbooks. It should have the following shape:

<?
define('FB_KEY', 'Your Freshbooks API Key');
define('FB_DOMAIN', 'The first part of your Freshbooks domain name');

define('EMAIL_FROM', 'accounting@yourcompany.com');
define('EMAIL_SHELL', 'email');

function all_customers() {
  return A(
    array('client_email' => 'contact@companya.com',
          'to'           => 'bob@companya.com,' .
                            'alice@companya.com,' .
                            'accounting@companya.com')
  );
}
?>

all_customers() returns an array of all the customers you want to e-mail.

Checkout lib/freshbooks.php to see the wrapper I wrote around the Freshbooks PHP API. I wanted to add a level of convenience around this very helpful library. Additionally, there were some assumptions I could handle at the API level (such as halting if the API returns an error), rather than letting my higher level code deal with them. See: fb_invoke(...) for the core helper function I wrote.

Don't get me wrong, the Freshbooks PHP API is really handy, especially because the Freshbooks API isn't REST based. The PHP API takes care of preparing and parsing XML messages, which while something I've done plenty of times in PHP, is nice to have already done for you.

Don't forget to customize snippets/email.php. Code under the snippets directory is where the formatting of the e-mail takes place. Unless you want to advertise my company, I'd suggest tweaking this so your company name is splashed across the e-mails.

Hope you find it helpful! Grab the code here.

Rule Number One for a Good Business

Some time ago I stumbled on one of Wood Trekker's older posts: Is it Wrong to Profit From Your Hobby? and found it thought provoking. The premise of the article is that some people's attempts to monetize their hobby ends up doing far more harm than good. My off the cuff reaction was something along the lines of: well, if you want to make a *good* business out of your hobby, go for it, but if it's going to be a crappy one, forget about it.

Which begs the question: what's a good business?.

After a number of evening jogs spent rolling this question around in head, I've come the following conclusion:

A good business must do at least one thing: exceed expectations.

Do that and you're off and running. Fail at that, and forget about it. Sure, it might be helpful to set expectations, but that's not really required; people will bring their own.

Consider a lemonade stand strategically placed along a bike trail on a hot day. What's the expectations? The lemonade should be cold and drinkable. Does matter if it's created from a mix that's mainly sugar? Not at all.

Now suppose you want to sell lemonade at your high-end artisan restaurant, with the promise of all organic ingredients and a high price tag to match. Now the expectations have clicked up quite a few notches: for $9.50, this better be the best tasting lemonade I've ever consumed.

Both businesses and products can work. Both can fail. It's all about exceeding the customer's expectations.

Just a Little Impossible: Morris Counting

I'll often advise entrepreneurs I talk with that it's ideal if their Software Idea is just a little impossible. ProgrammingPraxis recently published a challenge / solution that fits this description well. It's quirky, but still instructive. Here's my own word-problem based description of the challenge:

Imagine you're given the task at counting entrants to the state fair (yum!). Your boss hands you one of those crowd counter devices and walks away. As you examine the counter you realize that it only counts up to 255. Once the 256th person walks in, your screwed. The counter won't work anymore.

What do you do? Pray that the state fair has 254 attendees? Flee for your life? If you're Robert Morris, you get creative and devise a new way of counting, one that solves this seemingly impossible problem.

Here's what you do: you borrow a coin from your fellow fair employees and you stand by the gate. The first time someone walks in, you click the counter. Now it reads one. The next time someone walks you, you look down at the counter and flip the coin however many times is shown on its face. If your coin comes up heads every time, then you click the button to increment the counter. And repeat.

So if the counter says 8, then you have to flip the coin 8 times in a row. And if you get heads 8 times (unlikely, but do it enough, and it'll happen), you increment the counter to 9.

When your boss comes by and asks how many people visited the fair you bust out your pocket calculator compute 2^x-1, where x is the number shown on the counter.

Of course, this won't be the exact number of people who visited the fair, but it will be in the ballpark. It'll certainly tell you if there were 10's, 100's or 1000's of visitors that day. And that's far better data than having nothing.

Here's some random executions of the this algorithm:

In some cases, the number is pretty accurate (524 was estimated at 511, 242 was estimated at 255). In other cases, it's pretty out there (2956 vs. 4095). But still, considering that you're making use of nothing more than a very limited counter and a single coin, the results are quite impressive.

The bigger lesson though is the recipe at play here: find a problem which others think is impossible, solve it, and you're on your way to changing the world. That's not too much to ask, is it?

Here's the code that implements the above algorithm:

;;
;; http://programmingpraxis.com/2015/02/20/morris-counting/
;;

(define (show . words)
 (for-each display words)
 (newline))

(define (heads? n)
 (let ((flip (= 1 (random-integer 2))))
  (cond ((not flip) #f)
        ((and flip (= n 1)) #t)
        (else (heads? (- n 1))))))
        
(define (int-count n)
 (+ 1 n))
 
(define (morris-count c)
 (cond ((= c 0) 1)
       ((heads? c) (int-count c))
       (else c)))
       
(define (morris-value c)
 (- (expt 2 c) 1))
  
(define (trial upper)
 (let loop ((n (random-integer upper))
            (i 0)
            (c 0))
  (cond ((= n 0)
         (show "actual=" i ", morris=" (morris-value c)))
        (else
         (loop (- n 1)
               (int-count i)
               (morris-count c))))))
               
(define (test)
 (for-each trial '(10 50 100 200 500 800 1000
                   1500 2000 5000 7000 10000)))

They Had Me At Knicks Game

Jumped on the Acela today and headed to NY to meet one of my clients. Man, that's an easy trip. Anyway, tonight the plan was to take me out to dinner. That plan changed.

Instead they took me to a Knicks game.

And we 'sat' in a luxury suite.

And they brought in Kosher food.

That's not just a bathroom. That's our suite's private bathroom, thank you very much.

If they wanted to impress me, mission accomplished.

The 'Will It Matter' Test?

In the past I've written about how scalability can be overrated. David Kadavy has a well written post on a similar topic: “Will it scale?” is a less important question than “will it ever matter?”:

If you aren’t a big company, especially if you’re a single-person company like mine is, you need to find out if it matters whether something scales or not before you go through all of the trouble of making it scale.

Kadavy's observation applies to streamlining your business. For example, in my business, I could develop an auto responder for interested customers. I could make it smart, too, attempting to figure out what type of service they're after and deliver an e-mail that's customized to this. But, for the quantity of inquiries I get, a simple, human response works perfectly. This part of my business doesn't (yet) need to massively scale.

I think, however, Kadavy's test should be applied to more than just whether to automate internal processes or not. I think it needs to be the question asked at every point in the software development cycle: will this matter? If not, why the heck are we doing it?

I think Knuth said it best: premature optimization is the root of all evil.

A Rule of Thumb for Success

Seth Godin gives lots of insights in this interview, but one quick nugget to take away is this:

If I fail more than you, I win.

(The presumption of course, is that the failures we're talking about aren't the catastrophic kind. They may hurt, but they'll allow you to get back in the game and try again.)

Think about the above statement, and you'll see it has powerful implications.

Give the whole interview a watch, it's more than worth your time:

Thanks to Wisdom and Wonder for pointing me to the video.

Adventures in Venture Capital - The More Things Change, The More They Stay The Same

I'm pretty sure Gideon Lewis-Kraus's piece in Wired tracking one startup's quest to make it in Silicon Valley was intended to describe life in the latest tech bubble. For me, however, it was eerily similar to the dotcom boom of 2000. In fact, the whole thing felt like I was embedded with a group of naive guys heading to Vegas to strike it rich. Slowly but surely, everyone figures out that the games are rigged: the casinos may have been flashy and inviting, but the guys are the mark.

Can you tell I'm a little jaded? What can I say, from my experience, the Venture Capital based start-up world is like a house of cards. I'll be generous and say that everyone's putting forth their most optimistic picture (versus, say, lying): the tech team is talking about code like its written, the business dev team is talking about prospects like they are customers and the VC's are promising rock solid support when it's shaky at best. Everyone's walking around with a Happily Ever After scenario that just might happen. Or, the whole thing may just fall apart tomorrow. Promises, even signed agreements, don't mean much in this world.

Still, the article is right when it talks about how different techies seek different paths. For some, having a sexy title at Google or Microsoft may be the dream, while others get excited about stepping into the ring with Silicon Valley VC's. Sure, the VC's have experience on their side, and they've got self preservation down to a science. But, no VC can resist the next epic idea, and plenty of entrepreneurs think they can beat the odds. As for me, I play on the smaller scale of things, helping folks change the word without first raising millions of dollars (and selling their soul in the process). I recognize that works for me, but not for everyone.

Go read the piece: One Startup’s Struggle to Survive the Silicon Valley Gold Rush, and more importantly, remember this is the rule, not the exception in the Venture Capital world. I know those casinos are tempting, but play long enough and the house always wins.

Kitestring: A Safety-net for Your Cell Phone and Inspiration for the Entrepreneur

My Sister-in-Law sent me this link: This New App Could've Prevented My Friend's Rape. The 'app' in question is Kitestring, a website designed for personal safety.

I've got a few quibbles with the article: (1) It's not obvious to me how this, or any app could have prevented the rape the story describes. And (2), the 'app' isn't an app at all, but a website and SMS based service. So yeah, don't bother searching Google Play or iTunes, you won't find anything there related to site in question.

Still, the article gets points for mentioning the service. I like Kitestring as both utility as well as a case study for entrepreneurs.

The service is quite simple: you report that you're starting a trip of a certain duration. At the end of the trip, the system checks in with you. If you send the system your check-in word, you're all clear. If you don't respond, or send the system your duress code, your emergency contacts are notified. The entire webapp consists of one page where you can set your various 'words', maintain your emergency contact list and customize the message to go out.

The system would work well for those walking home late at night, heading out on a trail for a trail, or even when stopping for gas in a shady neighborhood. I could see using it before heading out on an epic hike or monster bicycling trip. It would provide an automatic backup in case I got lost or delayed. I could even imagine parents using this as a sort of pop-quiz for their kids: they setup a trip on their behalf, and if they don't check in, they get a phone call and tracked down.

The system doesn't do anything fancy with the user's GPS or have extensive options. But I think that's a good thing. The simplicity means that it works, and you'll use it.

As an idea guy / programmer, I'm always going on and on with folks about how they can turn their big-huge-awesome idea into something that they can start building today. I have no idea who's behind Kitestring, and I have no idea what their philosophy actually is, but on the surface it completely matches up to what I tell my customers.

I can see the pitch: let's revolutionize personal security! Let's make it app based, location based and fault tolerant. Let's use a heart rate sensors to detect if the person really is in duress. Let's use the camera to snap a picture of the assailant. Let's integrate this in with 911 so the police can be seamlessly dispatched. Let's develop an advanced algorithm to detect false alarms from true crises. And I say terrific! Let's do it all! But let's start with version 1.0.

Version 1.0 needs to be small (it'll cost you less, be faster to build and more importantly, lower risk) but mighty. It needs to capture the very essence of the idea without having any extraneous features. Ideally, it could be used in a number of contexts, allowing people to re-purpose the system in ways the creators never thought possible. It needs to deliver true value, and pique users interest so that they'll give you feedback on what to develop next. And it needs to be something you can start on today without anyone's permission.

I believe Kitestring has nailed these essentials. Is it perfect? Of course not. But they appeared to have hit all the above points. If you're looking for inspiration for building out your idea, they'd be a good place to start.

Look Ma, My Software's on TV!

The BBC ran a story featuring one of my customers:

We've all heard about making a phone call from jail, but what about a video call? Similar to Skype, video visitation allows inmates to see their friends and family while they talk.

That 'Skype' like software was built by us. And by 'us', I mean me.

While tempting, I won't comment on the thesis of the article itself (that said software will one day lead to the end of face to face visits). But, I will take a bit of pride knowing that the software is helping connect families during a difficult time, and making a safer environment for prison guards in the process.

Here's the full report:

Virginia Beach Quickie

We just finished a wonderful brunch with one of my clients. The food was great and so was the company. But especially impressive was the ocean view, with a pod of dolphins swimming by no less! See, my client is located in Virginia Beach and we came down last night to see them. And now we're headed back to DC.

It's been years since we've been here. Out little strolls on the boardwalk last night and this morning only makes me want to come back when we can spend some serious time in the sun and sand. And when I do, I have every intention of calling it a Business Trip.

Workflowy: your next application mockup tool

Recently I learned of workflowy, a wonderfully simple and clever way to track lists (and lists of lists). It brings me back to the old DOS days of using an Outliner (maybe MaxThink? For the life of me, I can't remember the name of the one I used), which was one of the original Killer Apps I encountered. I still like using a Wiki to track projects and notes, so Workflowy has yet to take hold in my daily workflow. Still, there's no denying it's a cool app.

Yesterday, I was passing along some advice for getting your software idea out of your head and into written form and it occurred to me that Workflowy would be the perfect tool for this.

Rather than focusing on graphical mockups (which are definitely slick, but can be exhausting to create and manage), I suggest folks work in a outline format. Essentially, you want to describe the hierarchy: Roles » Pages » Functionality. This is where Workflowy really shines.

You've got the technique and now the tool, what's stopping you from getting that next great idea out of your head, and into reality? Oh yeah, nothing.

Who Can Learn What From Vine

Vine is a service that allows you to create itty bitty videos (like this one). It's a service that received plenty of buzz, but I hadn't played with it till this last weekend. As case studies go, I think the service offers plenty to learn from. But who should learn what?

Entrepreneurs

In my day job I frequently talk to people about their ideas, and how they can best be turned into software. One of the first things I try to explain is that my little company builds software out in relatively small stages or versions. Figuring out what should go into Version 1 is often tricky. To help, I give my customers three guidelines to work with, all of which Vine appears to have nailed perfectly. They are:

1. Build as little as possible. Playing with Vine, especially on Android, you quickly realize how many features are missing. You can't save a video as draft, control it's privacy access or go back and edit a video. I'm sure there are folks clamoring for these features, but Vine has stayed disciplined (or maybe they have so few resources, they have no choice), that they have yet to build them in.

The negative side of this is that customers are going to kvetch. The positive side is that with all those features missing, you can focus on producing a quality user experience with the features you do create. In this case, Vine is so simple, that you can't stop playing with it. Creating a video is a one touch affair. Another bonus: by building less, Vine has had to leverage existing platforms to pick up the slack. Rather than reinvent a network broadcasting tool Vine uses Twitter. (Of course, Vine was bought by Twitter, so it's no surprise about that relationship.)

Make the tool general purpose. Which community is going to find Vine to be a killer app? It could be obvious ones, like new parents or travelers, but it could just as easily be unexpected groups like ER Doctors or football coaches. By creating a general purpose tool, they leave the door open to attract a number of potentially surprising audiences.

Put another way: by changing their message, Vine can potentially reach a new market; all without any software changes. That's a huge feature if you're software budget is limited.

It really solves a problem I have. This is absolutely key. Building an application missing lots of features you should be a recipe for disaster. But, if it truly solves a problem, folks will stick with it warts and all. They'll even love it. You can even expect your audiacne to find creative ways around these problems. Just as importantly, as you grow, you can add in missing features. So what problem does Vine solve so elegantly? Well, it's a First World Problem, but still a problem: how can I tell my story in a way that's efficient for me to create and efficient for my audience to consume.

Let's say I'm at my kid's soccer game. Sure, I could take out my cell phone and snap a few picture - but will that capture the scene? Probably not. I could capture 15 minutes of video, but who the heck wants to watch all that content? I could edit my 15 minutes of video down to just the good parts, but who has the time for that? Or, I could pop-open Vine, hold down the screen a couple of times, and I'm done. The experienced is captured, and even if it's awful, it's going to be at most 6 seconds long. Surely everyone can stand to lose 6 seconds, right?

By balancing the above three criteria, Vine can afford to build a minimal application, yet still gain a significant enough following. The result: customers will hang around as it grows into a full fledged app.

One of the challenges beginners have with creating software is that much of software they use has far outgrown it's Version 1 days. Facebook, eBay, Quickbooks, etc. are now mature products with millions of dollars invested into them. For the entrepreneur trying to do big things with few resources these are horrible examples to follow. Vine, on the other hand, is in those early stages. But better pay attention quick, my guess is that they are growing a rate where their early-day status will be behind them in no time.

Camera Manufacturers

For years, conventional wisdom was that a cell phone camera would do in a pinch if you didn't have a "real" camera on you. With apps like Vine, though, it's becoming clear that one day people are going to prefer the functionality of their cell phone over a relatively dumb camera. Vine may not be the camera killer app, but I think it certainly is part of a trend.

Consider the Galaxy S3's panorama feature. You can use it to quickly capture a 180 degree or even 360 degree view of a scene. Even when I'm carrying my DSLR, I find that I pull my Galaxy S3 out to capture panoramas. Sure, I could use desktop software to stitch together DSLR images together, but why go through the hassle?

When I shop for a camera I'm considering the following:

• Image quality
• Shutter lag
• Battery life
• Focal length (zoom lens) choices
• Compactness

My Galaxy S3 now has all of those bases covered, except for the focal length options, as well as point and shoot cameras. Heck, in many respects it competes well with my DSLR. Now when I factor in the nifty software tricks and easy sharing my phone offers, and gets harder and harder to justify buying a separate camera. When someone figures out how to add a 28-200mm lens to a cell phone, the race will be pretty much over.

I Love NY

Today I had the pleasure of meeting one of my long time clients face to face for the first time. I did so by hopping on the Acela Express and making my way to NY.

While my trip was brief (I'm heading back now as I post this), it was an enjoyable trip.

It's always fun putting faces to names, especially after you've been working with folks for years.

NY is, well, NY. The skyline is gorgeous, the crowds overwhelming, and the pizza greasy (yum!). What's not to love?

This is my second trip on an Acela Express and I continue to be very impressed. Plenty of leg room, free WiFi and AC Power at every seat makes for a really productive trip. In some respects security couldn't be more laxed. Nobody checked my bags or person. On the other hand, the "see something-say something" campaign is really intensive. A pre-boarding video clip I caught was so thorough I felt like I was participating in a counter terrorism course (remember: there are no suspicious people, just suspicious behavior! Whatever that means.)

I walked away from the video feeling as though security was in my and other passengers hands, not in some central authority. It's an interesting approach, and I wonder how well it works compared to the airport model.

All in all, it was a great trip. I'm only sorry I didn't get more time to wander the streets trying to get more photos.

Business Lessons from Tom and Gary

When I talk to folks about their ideas, I often suggest they try the following mental exercise:

Think through how you would implement your idea if you had no money to work with. Now imagine you've got some money (say, $10-20k). Now imagine you've got millions of dollars. What can you learn from each solution?

The goal behind this exercise is to help individuals let go of the some of the "musts" that they think their software needs, and help them realize that they can do amazing things with less.

I don't expect folks to choose the zero dollar solution, but I often want people realize that it *is* possible. You can have huge impact with a free Blogger account, clever use of Twitter and a handful of marketing books from the library. Over and over I learn that what's important isn't how sophisticated the software is, but how meaningfully it solves real people's problems. Deliver value, and almost everything else will take care of itself.

As you can imagine, I love finding examples of this in the wild. Which brings you to my new favorite discovery: 150 Boom Boxes and the Best Dance Party You’ve Never Been To. That link points to a recent Wired article which features Tom and Gary's Decentralized Dance Party.

Tom and Gary wanted to make an impact in the entertainment world. They could have gone the standard route, and opened up their own dance club, or put together some sort of dance party service. Instead, they came up with their own notion of decentralized dance parties.

The technology is wonderfully simple: an iPod connected to a radio transmitter, and whole lot of cheap boom boxes tuned into that frequency (and locked in with Duct Tape, of course). To top it off, the setup is "controlled" by a Nintendo Power Glove. And by controlled, I mean that it's warn for dramatic effect.

Sure, this isn't truly a Zero Dollar implementation. But for all intents and purposes, it really is. They deliver true value, and in return, folks don't care that the setup is rough around the edges. In fact, that roughness only adds to the effect.

You want to change the world with your idea. Let Tom and Gary show you the way. Solve a real problem, deliver real value, and do it with less. Or, do it with more. Whatever. Just do it!

DollarShaveClub.com - Hilarity Meets Business Advice

Check out this DollarShaveClub.com commercial:

Far funnier than anything I saw during the Super Bowl, or since. When my current batch of Cost Co razors run out, I may very well have to give them a try.

The commercial nails two other points that I'm constantly telling my customers about:

1. Embrace your limitations and use them as a strength. "Stop paying for shave tech you don't need" -- the flip side of this is, our razors aren't as flashy as the competition. Rather than lamenting this, embrace it. Say you're building a web app, and because you're a start up there isn't as much functionality built out yet. Use that as a good thing. Force your software to be simple and easy to use, and free from all that junk nobody really uses.

2. Solve a real problem, and everything else takes care of itself. The value proposition for DollarShaveClub.com is easy: save money, save time. DollarShaveClub.com doesn't need a fancy website, or packaging, or or even amazing customer service - they just need to deliver on this simple premise. If they do, then their customers will have the incentive to stick around as they grow to finally put out a fully mature product.

My favorite example of this to tell my customers about is eBay. When eBay started, there was no Buy It Now, or Make an Offer or even a way to schedule the ending of an auction. If you wanted an auction to end Sunday evening, you had to start it Sunday evening. And the interface was terribly clunky - no way your grandma could ever use it. But, eBay solved two real problems: (a) how can I sell the junk in my basement and (b) how can I trust the people I'm doing business with (aka, feedback). Because they delivered on those items, people hung around while eBay matured into a real product.

How A Boostrapper Sees The World

Two common approaches to developing software: (a) hire an offshore team, (b) hire local. (a) is cheap, but has the potential for fatal communication gaps. (b) is often smoother, but is also typically quite a bit more expensive. What do you? Well, it's easy to throw your hands up and just not take any action. But, in a recent article about Klout, I learned about an option (c):

Once [Fernandez of klout.com] figured out a few basic principles, Fernandez hired a team of Singaporean coders to flesh out his ideas. Then, realizing the 13-hour time difference would impede their progress, he offshored himself. For four months, he lived in Singapore, sleeping on couches or in his programmers’ offices. On Christmas Eve of 2008, back in New York a year after his surgery, Fernandez launched Klout with a single tweet.

Amazing, right? He managed to find low cost programmers and get a high degree of communication; all it took was completely throwing out the most common models for getting software built.

I'm not suggesting that you need to move to some foreign land to get your software idea built, just that it's all about mindset and being creative.