Phil Windley's Technometria

« January 2011 | Main | March 2011 »

February 28, 2011

Starting a High Tech Business: Making Hard Decisions

I'm the founder and CTO of Kynetx. This series of articles relates my discoveries and feelings about starting a high-tech business. This is the thirty-first installment. You may find my efforts instructive. Or you may know a better way---if so, please let me know!

Suppose you had a big tank. It's got water in it. There's a hole in the bottom and a few small pipes delivering water. Unfortunately the pipes are smaller than the hole. Your goal is to never let the tank run dry. You've managed to get by through periodic deliveries of water from an out of town supplier. He just called to tell you that you're not getting this week's delivery. In fact, it's not coming next week either. He's determined that delivering water to you "isn't strategic." You can run a few more pipes, but that takes time. In the meantime, the water in the tank is getting shallower and shallower. The only solution is to plug up the hole.

This isn't a perfect analogy, but it's a good enough description of the problem to define the solution. Last week was a tough one. On Friday we laid off six amazing people who are more than just colleagues or employees, but friends and people I have huge respect for. Every single person left a hole in our organization that will be hard to fill.

Without getting into details that might embarrass some people, the short story is that Kynetx had a bridge financing round that failed to come together. That happens and looking back, given the data we had I think we made the right decisions along the way. On Wednesday it became clear that the delivery wasn't happening and we couldn't run pipes fast enough. I've been around long enough to know that people represent the lion's share of any budget and any serious cutback always impacts people, their families, and their lives. At a big company there'd be weeks of notice and severance. Unfortunately at a startup, those luxuries just don't exist.

When you find yourself in this situation, the trick is take action quickly enough--before the tank is dry--that you can keep moving forward. The key word there is forward. Kynetx is moving forward: We are still planning to hold the most amazing tech conference Utah has ever seen on March 22 and 23: Kynetx Impact. Come and see what we're doing. The keynotes are amazing and the topics--APIs, cloud-computing, webhooks, events, and real-time Web--will blow you away from your socks. We will be making some great announcements at Impact. We still have some great clients--large and small. We still have a team--albeit smaller--that can deliver. We still do Free Lunch Friday every week.

Bottom line: while we are smaller, we are not in any danger of going out of business. In fact, we're not even in danger of merely marking time. We are rushing forward with our plans and have a doable 2011 strategy that will set us up for a very bright future.

Here are some of the reactions of people impacted by our decisions:

• People thought I was crazy... from Mike Farmer
• So long, and thanks for all the...fishing lessons from Jessie Morris
• Life At A Startup from Mike Grace
• Changing Sails from Sam Curren
• God is a DJ from Wade Billings
• Reduction in Force from Alex Olson
• hmmmmm and then the good with the bad by Amber McNamee

I can't adequately say how profoundly grateful I am to work with people who have great attitudes, understand the world of start ups, think like entrepreneurs, and are gracious even when looking into the teeth of a storm. All I can say is thank you for sharing the journey.

4:25 PM | Comments () | Recommend This | Print This

February 25, 2011

Building a PubSubHubBub Endpoint for Kynetx

The Live Web already exists and is exemplified by emerging technologies and concepts such as PubSubHubBub and webhooks. PubSubHubBub (PuSH) is a method for augmenting RSS and Atom feeds that turns the formerly request-response-style interaction of RSS into one that makes calls to subscribers when relevant updates are posted. Webhooks are a simple way to use HTTP to create event notifications .

Both of these technologies are raising events, although not in a form directly usable by Kynetx. One approach to using them with KRL would be to write a custom endpoint. Often for special projects, however, it's just as effective to put together pieces from existing Web services to do the transformation from one kind of event to another. In this post we'll explore an example that uses both PuSH and Webhooks with KRL that doesn't require writing a custom endpoint.

Prowl is an iPhone application that raises Growl-style notifications on your phone. Those notifications can come from your computer, from the Web, or through the Prowl API. In this example, we'll send notifications to a phone when a Blogger Web site is updated.

Blogger RSS feeds are PuSH enabled, so when the blog is updated, services that have subscribe to the feed are notified immediately. Notify.io is a service that can listen to PuSH-enabled feeds (among other things) and publish the pushed items to a webhook (and other things). Kynetx provides a Web service that translates events raised via a webhook into a Kynetx-style event that KRL understands.

Using these two services together, we can create a translating endpoint that raises events whenever a blog is updated. The wiring diagram is shown in the preceding diagram. We'll configure the webhook service to raise an event with type newpost.

The Prowl API can be easily encapsulated in a KRL module as shown below:

ruleset a16x83 {
  meta {
    name "Prowl Module"
    configure using apikeys = {} and
                    application = "Kynetx"
    provides send
  }

  global {
   send = defaction(title, description) {
     configure with priority = 0
     http:post("https://api.prowlapp.com/publicapi/add")
       with params = {
        "apikey": apikeys.pick("$.apikey"),
        "providerkey": apikeys.pick("$.providerkey"),
        "application":application,
        "priority": priority,      
        "event": title,
        "description" : description   
      }
    }
  }}

This provides rulesets with an action named send that will post the notification to the user's cell phone. Writing a rule to listen for the event from the endpoint and call the prowl:send action is simple. The only thing we need to do is provide the API and provider keys that we get from the Prowl Web site.

First we declare keys and use the module in the meta block of the ruleset:

key prowl {"apikey":"KEY GOES HERE",
           "providerkey": "KEY GOES HERE"}
use module a16x84 alias prowl
   with apikeys = key:prowl()

The rule is simple:

rule first_rule is active {
    select when webhook newpost
    prowl:send(event:param("title"), event:param("text"));
}

When an event is raised with a type that matches newpost, send the title and text parameters of the event to Prowl. The result is a notification on the iPhone like the one shown in figure above.

Of course, it would be just as easy to use the Twilio module to send an SMS. You could do both, based on priority, keyword, or anything else. Providing endpoints for real-time events online gives us the ability to use KRL to glue these event together and create interesting, useful little applications.

2:39 PM | Comments () | Recommend This | Print This

February 21, 2011

Terror and Consent: a Book Review

As I write this, the news about protests in Libya is streaming over Twitter. I've been meaning to write a review of Philip Bobbitt's Terror and Consent: The Wars for the Twenty-First Century for a while because it's given me a new vantage point from which to view and make sense of the events I see in the news.

I reviewed Bobbitt's earlier work The Shield of Achilles and I have to admit, I'm something of a Bobbitt fan. I like the intellectual scaffolding he erects for hanging up and examining current and historical events.

In Terror and Consent, Bobbitt makes the case that "almost every widely held idea we currently entertain about 21st-century terrorism and its relationship to the wars on terror is wrong and must be thoroughly rethought." There's something for everyone here as Bobbitt's approach isn't ideological. Even thought he is, I suspect, a Democrat he picks on their mistaken worldviews as much as he does the GOP's. If the idea doesn't make sense, it doesn't matter to Bobbitt who's idea it is. These are the kinds of writers I prefer.

The book's title comes from Bobbitt's classification of states into two camps. Before discussing them, we should make note of a basic idea: states, no matter what their make-up or character, demand a monopoly on violence. In any functional state, only the government may legitimately exercise violence (broadly interpreted to be any act that threatens, coerces, confines, or kills people in an effort to keep them from doing what they'd otherwise do).

• States of consent are those who derive their power to govern (and hence their monopoly on violence) through the consent of their citizens. Consent necessarily requires the protection of minority rights. States of consent govern on the basis of their legitimacy. Acts that detract from a state's legitimacy, whether in the eyes of their citizens of the citizens of other states, weaken their ability to govern.
• States of terror are those who derive their power to govern (and hence their monopoly on violence) through acts of terror. Terror, in this usage, is a broad concept and can include any coercive act that a government uses to keep citizens from exercising rights of consent. States of terror gain legitimacy from the power they employ against their citizens and others to keep them from doing what they would otherwise lawfully do.

Bobbitt's chief premise is that we are, in fact, in a war against terror. More to the point, the primary enemy we must fight is terror and those who would use it to destroy consent. Recognizing this changes our models for how we must wage war in order to survive.

The other important concept that Bobbitt introduces is that of the "market state" the successor to the nation state. Nation states were the primary constitutional order of the 20th century. Nation states were defined by the nation or people they represented. They three primary kinds of nation states in the 20th century were the fascist, communist, and democratic nation states. The long war of the 20th century (WW I, WW II, and Cold War were all one war in this view) was fought to determine which kind of nation state would prevail.

Market states are a product of the interconnected, globalized world that we live in. Bobbitt explains:

You can see it here in Britain -- when states go from reliance on law and regulation, so characteristic of the nation state, to deregulating not only industries, but also women's reproduction. When states move from conscription to an all-volunteer force to raise armies; in the UK you saw this development in the policy of top-up fees for college tuition. You see it in America with welfare reform when we go from direct transfers, and workmen's compensation, to providing skills to enter the labor market. In all of these instances you are seeing the beginnings of a change in which the state says, "Give us power and we will maximize your opportunity. What you do with it -- that's up to you. We will not assure you equality, and we will not assure you steadily improving security, but the total wealth of the society will be maximized."

The key point that Bobbitt makes about terrorism is that it has existed for centuries and that it has always reflected the structure of the predominant form of the state in any given period. In the 20th century terrorism, the nation state was the key protagonist and terrorism took on a form that mirrored the nation state. Terrorism was aimed at overcoming the nation state. Think about the terrorist groups of the 20th century--they were all aimed at one nation or people breaking away from another. They were about nations.

Twenty-first century terrorism isn't like that. Al Qaeda wasn't formed to overthrow Saudi Arabia or Israel, but to establish a global caliphate for the faithful. In Al Qaeda's view, a global regime of human rights and the connectivity attendant to globalization are incompatible with this goal. For Al Qaeda, terrorism isn't means to the end, but the end itself (see page 62). A constant state of global terror is the "most formidable alternative to the global order of state systems of consent and international regimes of human rights". Of course, Al Qaeda won't be the only group to do this. In fact they may be the least sophisticated of those we'll face in the future.

Weapons of mass destruction (WMD) are becoming more and more likely to fall into the hands of these kinds of terrorists for both technical and political reasons. This makes the survival states of consent contingent on preventing terrorists from getting access to them, dramatically changing the equation for how we must view and respond to world events.

Further, and perhaps more to the point, terrorism can't be dealt with by standard law-enforcement techniques because terrorists will not be dissuaded from committing atrocities by the threat of imprisonment like common criminals. Moreover, terrorism can't be dealt with by the standard strategic means (like war, military tribunals, and so on) because doing so poses a threat to the legitimacy of states of consent. We must forge new rulesets for the 21st century that combine law and strategic means in ways that people in states of consent both understand and support. Legitimacy is what terrorists seek to destroy. We must ensure they can't.

At the same time, we must prevent, not simply respond to, terrorist acts because those acts threaten states of consent by making the government appear to be incapable of delivering security and opportunity to its citizenry.

There are no simple answers. Indeed, there will be years of hard work by people and institutions around the world in coming to grips with this new constitutional order. Bobbitt's books aren't easy reading. They are dense and take work to get through. But if you do, I promise you will never read a newspaper story with quite the same perspective again.

4:42 PM | Comments () | Recommend This | Print This

February 18, 2011

A Completely Connected World Depends on Loosely Coupled Architectures

This article from CNNMoney describes a completely connected world where not just every device, but literally every thing you own "will want to be your friend on the Facebook of things."

At the Mobile World Congress in Barcelona, companies like IBM (IBM, Fortune 500), Qualcomm (QCOMM), AT&T (T, Fortune 500) and Ericsson showed off their vision of a not-too-distant future in which every item in your life, from your refrigerator to your fridge magnets, will soon connect to the Internet or communicate other Internet-connected gizmos.

Here's how it would work: Electric devices like washing machines, thermostats and televisions will be manufactured with chips that allow them to wirelessly connect to the Internet. Non-electric items will either come with low-energy, Bluetooth-like transmitters that can send information to an Internet-connected hub or radio frequency identification (RFID) tags that can be sensed by Internet-connected near-field communication (NFC) readers.

From MWC 2011: Life in 2020 will be completely connected - Feb. 17, 2011
Referenced Fri Feb 18 2011 09:39:28 GMT-0700 (MST)

This is how these articles always are: "everything will have a network connection" and then they stop. News flash: giving something a network connection isn't sufficient to make this network of things useful. I'll admit the "Facebook of things" comment points to a strategy. IBM, or Qualcomm, or ATT, or someone else would love to build a big site that all our things connect to. Imagine being at the center of that. While it might be some IBM product manager's idea of heaven, it sounds like distopian dyspepsia to me.

Ths reminds me of a May 2001 Scientific American article on the Semantic Web where Tim Berners-Lee, James Hendler, and Ora Lassila give the following scenario:

"The entertainment system was belting out the Beatles' 'We Can Work It Out' when the phone rang. When Pete answered, his phone turned the sound down by sending a message to all the other local devices that had a volume control. His sister, Lucy, was on the line from the doctor's office: ..."

Sound familiar? How does the phone know what devices have volume controls? How does the phone know you want the volume to turn down? Why would you program your phone to turn down the volume on your stereo? Isn't the more natural place to do that on the stereo? While I love the vision, the implementation and user experience is a nightmare.

The problem with the idea of a big Facebook of Things kind of site is the tight coupling that it implies. I have to take charge of my devices. I have to "friend" them. And remember, these are devices, so I'm going to be doing the work of managing them. I'm going to have to tell my stereo about my phone. I'm going to have to make sure I buy a stereo system that understands the "mute the sound" command that my phone sends. I'm going to have to tell my phone that it should send "mute the sound" commands to the phone and "pause the movie" commands to my DVR and "turn up the lights" to my home lighting system. No thanks.

The reason these visions fall short and end up sounding like nightmares instead of Disneyland is that we have a tough time breaking out of the request-response pattern of distributed devices that we're all too familiar and comfortable with. This pattern leads us to the conclusion that the only way to make this work is to create directories of things, the commands they understand, etc. But the only way these visions will come to pass is with a new model that supports more loosely coupled modes of interaction between the thousands of things I'm likely to have connected.

Consider the preceding scenario from Sir Tim modified slightly.

"The entertainment system was belting out the Beatles' 'We Can Work It Out' when the phone rang. When Pete answered, his phone broadcasts a message to all local devices indicating it has received a call. His stereo responded by turning down the volume. His DVR responded by pausing the program he was watching. His sister, Lucy, ..."

In the second scenario, the phone doesn't have to know anything about other local devices. The phone need only indicate that it has received a call. Each device can interpret that message however it sees fit or ignore it altogether. This significantly reduces the complexity of the overall system because individual devices are loosely coupled. The phone software is much simpler and the infrastructure to pass messages between devices is much less complex than an infrastructure that supports semantic discovery of capabilities and commands.

Events, the messages about things that have happened are the key to this simple, loosely coupled scenario. If we can build an open, ubiquitous eventing protocol similar to the open, ubiquitous request protocol we have in HTTP, the vision of a network of things can come to pass in a way that doesn't require constant tweaking of connections and doesn't give any one silo (company) control it. We've done this before with the Web. It's time to do it again with the network of things. We don't need a Facebook of Things. We need an Internet of Things.

I call this vision "The Live Web." The term was first coined by Doc Searls' son Allen to describe a Web where timeliness and context matter as much as relevance. I'm in the middle (literally half done) with a book I'm calling The Live Web: Putting Cloud Computing to Work for People . The book describes how events and event-based systems can more easily create the Internet of Things than the traditional request-response-style of building Web sites. Im excited for it to be done. Look for a summer ublishing date. In the meantime, if you're interested I'd be happy to get your feedback on what I've got so far.

10:11 AM | Comments () | Recommend This | Print This

February 15, 2011

Saying Goodbye to ExpertsExchange! Creating a Personal Block List with Kynetx

Yesterday Google announced a Chrome extension that allows you to create a personal block list of Web site URLs. The idea is to reduce spam in search results by letting users block sites from their personal search results. The extension also sends this information to Google so that they can crowdsource their search spam efforts. But what if you want to do this Firefox or Internet Explorer? Or on Yahoo! or Bing? Kynetx to the rescue!

When we saw the Google extension we thought "great idea" but we can do better with KRL. KRL is a language that lets you build extension functionality like this in the cloud and then easily deploy it to Firefox, Internet Explorer, and Chrome. For our purposes, think of it as "GreaseMonkey in the Cloud." Easily updatable, runs anywhere, and quick to build and deploy.

We put out a call on Twitter for the KRL developer community to replicate this functionality in KRL in 24 our less. We had several people working. Ed Orcutt of Lobos LLC met the challenge first.

Ed's PersonalBlock provides a "Block this site" link next to every result, a link at the bottom indicating that there are hidden sites, and a chance to reveal (and unblock) them. You can block a site on Google and it will also be blocked on Yahoo! or Bing. Unblock a site on Bing and it will be unblocked on Yahoo! and Google. The functionality works for all search engines and in all browsers. I have to admit when I tried this out this morning, I was a little giddy that it worked so well and was so easy to do.

Find out how build cool extensions like this at the Kynetx Impact conference on March 22 and 23, 2011.

Here's a video showing PersonalBlock in action:

We're not sharing the blocked domains with Google and other search engines. If we did, that would be completely anonymized and aggregated. Doing that from a Kynetx app would be trivial, by the way.

Get the extension for your browser here and say goodbye to search spam regardless of what search engine or browser you use.

There is coverage of PersonalBlock on ReadWriteWeb as well.

If you're interested in the source code, here's the Gist.

2:16 PM | Comments () | Recommend This | Print This

February 9, 2011

Kynetx is Looking for a Part-Time Programmer

If you're a good developer, have always wanted to work on cutting edge stuff in a fun place, and are looking for part-time work, then Kynetx would like to talk to you.

If you send me email, leave a comment on this post, or call, you will be ignored. If you come to Free Lunch Friday the day after tomorrow or next week, then you can get to know us and we can get to know you. Please RSVP to the plancast so we know you're coming.

This position has the possibility of turning into fulltime employment and what could be more cool than working for Kynetx full time? I pinch myself everyday to make sure I'm not dreaming.

3:35 PM | Comments () | Recommend This | Print This

Starting a High Tech Business: Follow Standard Business Practices

I'm the founder and CTO of Kynetx. This series of articles relates my discoveries and feelings about starting a high-tech business. This is the thirtieth installment. You may find my efforts instructive. Or you may know a better way---if so, please let me know!

The other day my wife was telling me about a friend of our's whose ex-husband "lost everything because his partner was embezelling." I hear things like this from time to time. I'm sure you do as well. But there's really no reason for it. Proper financial controls can help keep everyone honest.

When we started Kynetx, Steve and I sold a plane we'd owned jointly to fund the business initially. There was no income, expenses were relatively low, and it was easy for us to keep track of the finances. Quickbooks was there and we both had a pretty good idea of what our financial picture was--all you had to do was look at the balance.

As we grew, got some revenue, and started looking for external financing we were lucky to find Roy Avondet. Roy is a retired managing partner at Deloitte and wanted to be involved. Steve handed Roy the Quickbooks files and said "all yours!" Roy's been our CFO and financial advisor ever since. Thanks to Roy we're always had accounting practices that outstripped our size.

I'm confident there's never been a point in the history of Kynetx where an individual could take large sums from the company without us knowing and quick. Stealing from Kynetx would require collusion of two or more people and that's where the safety lies.

We were lucky to find Roy, but you don't need luck. There are plenty of accountants who can help you put proper financial controls in place. It's not too expensive and it's not too much hassle. Rather, it's necessary for creating a real business. If your startup doesn't have good financial controls in places, fix it today--it's never too early or too late to start.

8:06 AM | Comments () | Recommend This | Print This

February 8, 2011

Reading for February 8, 2011

• China: Wealth But Not Freedom - I wonder how long this can go on. Indefinately, perhaps, if most people feel satisfied with State actions and it maintains its legitimacy.
• Supposed change in Apple policy has e-book fans worried about their apps - As someone who regularly buys books from Amazon for the iPad Kindle, I'd hate this.
• All abstract strategy discussions are useless - "Strategy is worth thinking about if it causes you to make difficult or non-intuitive decisions."
• Can Government Manage the Economy? - And no, the question isn't rhetorical
• The unearned follow - Nice introspection from Robert
• Chris Heathcote: anti-mega: 40p off a latte. - Wonderful look at what personalized commerce and offerings realy ought to be like
• Obamacare and the constitution: Anthony Kennedy, a nation turns its angry eyes to you - Many thought this challenge would go no where.
• How APIs Are Changing The Way Brands Connect With Consumers - APIs and Brands? They've jumped the shark, maybe.
• Multi-Tenant Data Architecture - An oldie, but a goodie.
• Should we trust Bill Keller? - I have to admit, I didn't even know who Bill Keller was...
• Apple to Tighten Control on Content - More on Apple and its moves to control content on iOS devices
• Cornfield Socialism - Pot, Kettle, Black
• Senator: domain name seizures "alarmingly unprecedented" - "the domain name seizure process does not appear to give targeted websites an opportunity to defend themselves before sanctions are imposed."
• The BCS Turing Lecture with Prof Donald Knuth - Nice report on what Knuth's saying
• The Disruption of Bronze - Bronze was where it was at. Iron was a not so good technology. Classic disruption.
• Jobs, But No Qualified Applicants - The problem with changing needs in the economy is that reeducating people takes a long time.
• Space stasis: What the strange persistence of rockets can teach us about innovation - You've got to love Neal Stephenson...long book or short piece.
• Exodus from Egypt - I'm looking forward to Doug's promised second article. And don't miss my podcast with him.
• The Personal Data Locker Vision Video - This vid is worth watching. It lays out the vision very nicely.
• Students: You Are Probably Not Mark Zuckerberg, So Stay In School - Education is a worthwhile backstop to your billion dollar idea...just in case
• The Personal Cloud - Drummond lays out a vision for personal data stores

9:50 AM | Comments () | Recommend This | Print This

February 4, 2011

"Data Incoming!" Event-Based Systems and Self-Determination

A while ago, Steve was helpfully giving me information related to my driving from the passenger seat. I jokingly told him it would be helpful to me if he'd tag his utterances so I'd know what they were. So he started prepending "data incoming!" to the start of his driving tips. So, he'll say something like "Data incoming! There's a car on your left!"

Wednesday were driving around Mountain View and he said "Data Incoming! Turn left!" I said "That's not data, it's a command." This is a vital distinction and captures perfectly the difference between request-based system and event-based systems. "Car on your left!" is an event. "Turn left!" is a command.

The Web is a request-based system. The client (browser) sends a command to the server "GET this for me!" and the server is obligated to execute the command or say why it can't. The client determines what it wants done and then makes whatever commands are necessary to do it. In an event-drive system, the sender merely says that something happened.

The following table shows this pattern of opposites that makes request-based and event-based system the duals of each other:

	Request-Based	Event-Based
Signal	Request receipt	Event receipt
Nature	"Do this"	"Something happened"
Obligation	At server	At endpoint (client)
Interpretation	On client	On server

The first different is in the type of signal. Where the receipt of a request triggers a request-response system, the receipt of an event triggers event-driven systems. An event is a notification of a state change. Thus the nature of an event is different than that of a request. Whereas a request says "do this for me" an event says, "this happened." In a request-driven system the sender chooses what action to take. In an event-drive system, the receiver interprets the event and determines what action to take.

Event processor has no obligation to the endpoint. Endpoint is obligated to report events and respond to directives. Conversely, a client in a request-drive system has no obligation to the server. It can make a request or not. Servers are expected to fulfill requests.

As we've discussed, the interpretation of what an event means is made by the server. A request, on the other hand, implies that the interpretation---what should happen---has already been made.

This last point is critical. Request-based systems are sender deterministic. Event-based system are receiver determinisitc. The receiver determines what happens. The receiver may choose to ignore the sender or to take action. The sender might not even know that action has been taken.

Because of these differences, the flow control of event processing systems is very different than that of request-response systems. Consequently, applications are constructed differently in event-driven systems.

This has significant implications for programmers of event-based systems. They can be harder to program because the fundamental model is so different than that traditional imperative programming model we're familiar with. We like command-style systems.

On the other hand, the benefits of receiver-deterministic systems--event-based systems--are huge. They largely stem from event-based systems being more loosely coupled than request-based systems. Loose coupling results in systems that are more flexible and less prone to small failures causing large disruptions.

One of my favorite examples is from a May 2001 Scientific American article by Tim Berners-Lee (et.al.) on the Semantic Web. It starts:

"The entertainment system was belting out the Beatles' "We Can Work It Out" when the phone rang. When Pete answered, his phone turned the sound down by sending a message to all the other local devices that had a volume control. His sister, Lucy, was on the line from the doctor's office: ..."

Do you see the problem with this scenario? While the whole goal of the Semantic Web is to reduce coupling by allowing for dynamic data interpretation, the scenario presents a request-based model of interaction. When the phone sends a "turn sound down" command to local devices with volume controls, it has to know which devices are in the vicinity that have volume controls and explicitly script them. Discovery of this kind of information is difficult and computationally expensive (hence the need for the Semantic Web). Knowing what commands to send to which device entails significant complexity.

Imagine a slightly different scenario:

"The entertainment system was belting out the Beatles' "We Can Work It Out" when the phone rang. When Pete answered, his phone broadcasts a message to all local devices indicating it has received a call. His stereo responded by turning down the volume. His DVR responded by pausing the program he was watching. His sister, Lucy, ..."

In the second scenario, the phone doesn't have to know anything about other local devices. The phone need only indicate that it has received a call. Each device can interpret that message however it sees fit or ignore it altogether. This significantly reduces the complexity of the overall system because individual devices are loosely coupled. The phone software is much simpler and the infrastructure to pass messages between devices it much less complex than an infrastructure that supports semantic discovery of capabilities and commands. What's more adding another actor in the system--say a lighting system that raises the lights when there's a phone call--doesn't require that every other device be reprogrammed to know it's there. It simply starts listening for relevant events, interpreting them within it's own domain, and responding as appropriate.

Events, the messages about things that have happened are the key to this simple, loosely coupled scenario.

Event-based systems are much closer to how most people interact with each other. We all know that our friends and family respond better when we give them data and let them determine how they should act instead of trying to direct their lives for them. Our servers don't have feelings or an entitlement to self-determination (yet) but even so we can create more compelling and flexible systems if we pretend that they did. "Data incoming!"

9:53 AM | Comments () | Recommend This | Print This

February 1, 2011

Reading for February 1, 2011

• The AirPlay Network - I follow the news now on Twitter, not the TV. Real-time is real.
• 16 Ways Your Startup Needs To Be Getting Customers by Jason L. Baptiste - Like the idea of conferences.
• Eight Lessons from the life and work of Jack LaLanne - Bootstrapping
• Apple Plans Service That Lets Users Pay With IPhones - Near field communication => General-purpose RFID impersonators
• Explore your LinkedIn network visually with InMaps - I explored mine in some detail in the previous blog post.
• Why 3D doesn't work and never will. Case closed. from Roger Ebert's Journal - I felt like Chicken Little with my dislike for 3D, but I guess I'm in pretty good company.
• When do you pick HBase instead of MySQL? - Facebook's NoSQL entry
• Peer Instruction for Seeing What Students Know (and Don't) - Asking questions and giving time to work out the answers in class pays big dividends in learning.
• Google Shake-Up Knocks $300 Million Off Schmidt's Stake - Don't cry for Eric, he's still worth billions and now has some time to enjoy it.
• How the Internet (Our 21st Century Printing Press) Can and Must Transform Universities - Applying new media to university communities
• Seven ways to think like the web - Love these simple rules
• Day 38 -- Evolution Of Advanced Hello World App - Mike Grace keeps going with his app-a-day posts
• Sandstrom bill runs into some turbulence - Sandstrom's [immigration] bill only has 15 to 20 votes in the House. It takes 38 votes to get a bill
• FBI goes after Anonymous for pro-WikiLeaks DDoS attacks - Anonymous isn't
• Support for the disconnected of Egypt - "On behalf of the future, I ask you of the past to leave us alone. You are not welcome among us. You have no sovereignty where we gather."
• Withings WiFi body scale review: weight data and cool graphs - Data about us finding it's way online and life logging is big business
• Invertible Syntax Descriptions: Unifying Parsing and Pretty Printing - As someone who has spent too much time writing pretty printers, I like this idea
• Microformats and RDFa deployment across the Web - "These results make me optimistic that the Semantic Web is here already in large ways."
• Egyptian Government Attacks Egypt's Internet - They must be suffering major economic repercussions over this. Egypt isn't North Korea--their business depends heavily on the 'Net.
• At Apple, the Platform Is the Engine of Growth - Nice look into Apple's product strategy
• This Valley Bubble is Not of Valuation, but Optimism - Louis Gray argues that there's no bubble, move along...
• Al Jazeera in Egypt is cable's 'Sputnik moment' - The message cable should be getting is not just "carry Al Jazeera," but "normalize to the Internet."
• Learning from our Mistakes: The Failure of OpenID, AtomPub and XML on the Web - On the other hand, sites like StackOverflow have made great hay with OpenID, maybe because they cater to geeks?

7:28 AM | Comments () | Recommend This | Print This