Phil Windley's Technometria

February 6, 2012

On Call TA: Distributed Event Network Federation Through Subscription

Recently I wrote about the theory behind federating distributed personal event networks through subscription. This post is about a working demonstration of event subscription in personal event networks.

Scenario

I have two TA for CS462. My TAs are usually in the building, but not sitting at the TA cubicle for CS462. They are happy to be “on call” and answer student questions almost any time if they don’t have to sit in the cubicle away from their usual desk. They have built a KRL ruleset that allows students to text a number and request a meeting. The problem is that you have to copy the ruleset and customize it for each TA. I thought this was a great example for how a federated group of event networks could work together, so I built it as an example.

Personal Event Networks

A little background on personal event networks. Everyone with a Kynetx account has a personal event network. What that means is that when an event is raised to the network any rule installed in the network and listening for that event will respond. Multiple rules can respond to any given event and merely installing a ruleset changes the collection of rules and events that will be seen. We call this concept salience.

Personal event networks can store personal information in a way that an installed ruleset can see and use the data. We’ve also built a general-purpose notification event API and have a simple ruleset that responds to notification events.

General Set Up

For this demo, there are three personal event networks: one for the class that is hooked to the SMS number, and one for each of the TAs. The setup supports any number of TAs. The personal event networks for the TAs subscribe to events from an app (ruleset) installed in the class’ personal event network.

We’ve configured a Twilio SMS number to raise an event (twilio:sms) to the class personal event network whenever it receives an SMS message. A ruleset installed in the class personal event network called On-call TA: Dispatcher watches for this event and dispatches a schedule:inquiry event to the personal even networks of any subscribers. TAs indicate whether they are on call or not by scheduling appointments with the title “On Call” on their personal Google calendar, not a shared one.

The TAs install a ruleset called On-call TA: Demo in their personal event networks. This ruleset is looking for a schedule:inquiry event. The ruleset uses personal data from the network’s personal data management ruleset to customize it. The ruleset’s job is to notify the TA when a schedule:inqury event is received. The notification takes the form of a notification:status event that is handled by the Simple Notifications ruleset. In this case, the Simple Notification ruleset sends an SMS message to the TA. Notice that the TA picks which notification ruleset is installed and this determines how they will be notified. Message and channel are separated.

Any TA who receives a notification and can see the student merely responds to the text and the student is notified that help is on the way. If no TA is on call, the student is told that no one is on call right now.

A few points to emphasize:

None of these rulesets know about the others. They are connected by the event network in a loosely coupled maner.
The subscriptions are made using single-channel tokens that create a one-to-one link between networks. This protects against SPAM and other communications abuses. The relationship can be revoked as easily as it is created.
The behavior of the rulesets isn’t specialized to an individual. The rulesets are general purpose. All the personal data is retrieved from the personal data manager installed in the personal event network.
Anyone who wants to see the schedule:inquiry events from the class personal event network must subscribe to them. At present, that is done by modifying a hand-coded data structure (see below), but it could, of course, be automated to varying degrees.

The Gory Details

What follows are the gory details of how it all works. Keep reading if you’re into that sort of thing.

Dispatching and Subscription

You communicate with a personal event network by raising an event to it using an event signal URL (ESL). Each ESL for a personal event network contains an identifying token (in the form of a GUID). The token uniquely identifies the personal event network that will see the event. An owner of a personal event network can create as many unique ESLs as she likes. Consequently, every entity raising an event to a personal event network has a one-to-one channel to communicate events. These ESLs can be revoked by the owner of the personal event network at will, protecting the personal event network from unwanted events. They could even be set to expire after a given number of uses or after a given amount of time (note: expriry behaviors are not currently built out in the Kynetx system).

Subscribing to events thus requires that the owner of the personal event network provide an ESL, or at least the identifying token from the ELS, to the event publisher. Once a publisher has an ESL, they can raise events to the subscriber whenever appropriate. In the case of the TA dispatcher, any interested parties—presumably the TAs—subscribe to schedule:inquiry events from the Dispatcher ruleset by supplying a token from their personal event network. The ruleset also needs other information from subscribers. We store those subscriptions in a data structure inside the Dispatcher ruleset:

subscribers = 
   [{"name":"Phil",
     "phone":"801362XXXX",
     "token":"072a3730-2e9a-012f-d2da-00163e411455",
     "calendar":"https://www.google.com/calendar/..."
    },
    {"name":"John",
     "phone":"801602XXXX",
     "token":"fc435280-2b60-012f-cfeb-00163e411455",
     "calendar":"https://www.google.com/calendar/..."
    }
   ];

This is hardcoded in the Dispatcher ruleset for now, but could easily be something that is configurable with a little more work.

The ruleset performs a bit of semantic translation on the twilio:sms event to determine whether it is a schedule inquiry or a response from the TA since they both are SMS messages to the same ruleset. If the SMS represents a schedule inquiry, the rule raises an explicit event named schedule_inquiry, causing the following rule to be selected:

rule dispatch {
  select when explicit schedule_inquiry
    foreach subscribers setting (subscriber)
      pre {
        resp_cookie = math:random(99);
      }
      if(onnow("On Call", subscriber{"calendar"})) then {
        send_event(subscriber{"token"},"schedule","inquiry")
          with attrs = {"from" : event:attr("From"),
                        "message": event:attr("Body"),
                        "cookie": resp_cookie
                        };
      }
      fired {
        set ent:return_receipt{"x"+resp_cookie} 
            event:attr("From");
      } else {
        ent:missed_call_count += 1 from 0;
      }
}

The rule loops over subscribers and checks their calendar to see if there is a “On Call” event on the calendar. If so, it sends an event to their personal event network. If not, an entity variable called missed_call_count is incremented (more on this in a minute). The send_event action is something I defined for this demo. It takes the token from the subscriber and the event domain and type (schedule and inquiry in this case). Any event attributes that need to be sent are given as optional parameters to the action. Here’s the definition:

send_event = defaction(subscriber, dom, type) {
  configure using attrs = {}
  mk_esl = function(token, d, t) {
    eid = math:random(9999999);
    a = [token, eid, d, t];
    "http://cs.kobj.net/sky/event/" + a.join("/");
  };
  http:post(mk_esl(subscriber,dom,type)) 
    with params = attrs          
};

Notice the embedded definition of mk_esl that takes a token, domain, and type and creates an ESL. The action uses http:post() to make the call.

As we gain more experience with the subscriber pattern, we’ll probably build in an action for signaling all subscribers for efficiency purposes, but there’s nothing wrong with the way I’ve done it here from a functional standpoint. This is just what needs to be done. By using an ESL instead of short circuiting it in the engine we allow for other event networks to participate.

The Dispatcher ruleset contains another rule that let’s students know when there isn’t anyone on call. The sms_absent rule also respond to the schedule_inquiry explicit event, but only fires when the entity variable missed_call_count is greater than or equal to the number of subscribers (recall that it was incremented in the dispatch rule):

rule sms_absent {
  select when explicit schedule_inquiry
  if(subscribers.length() <= ent:missed_call_count) then 
    twilio:send_sms(event:attr("From"), 
                    ta_sms_num, 
                    "There are no TAs on call right now.");
  always {
    clear ent:missed_call_count;
  }
}

If it fires, an SMS is sent to the student saying that no TAs can respond. Whether or not it fires, the variable missed_call_count is cleared.

Notifying the TA

The TA has installed a TA ruleset that listens for schedule:inquiry events. If the TA has an "On Call" appointment on her calendar, then the explicit event on_call_request is raised with attributes named message and from. The event also includes an end attribute that contains the ending time of the appointment.

rule schedule_inquiry_oncall {
  select when schedule inquiry
  pre {
    thisappt = now(oncall_title, my_calendar);
  }
  if thisappt then noop();
  fired {
    raise explicit event on_call_request for "a16x142.dev" with 
      message = event:attr("message") and 
      from = event:attr("from") and
      end = thisappt => justtime(thisappt.pick(“$.when[0].end”)) 
                      | “later today”;
  }
}

Why check the calendar here if it was checked in the dispatcher? Because schedule:inquiry is a pretty general event. The TA might have other apps installed that also respond to a schedule:inquiry event. For example, maybe she has a “study group” ruleset installed that negotiates meeting times for a study group. When a study group schedule:inquiry events comes in, we don’t want the TA ruleset to respond. Of course, we check it in the dispatcher not only for efficiency purposes but to let students know when no TA is available

The on_call_request event is handled by the notify_ta rule. This rule processes some of the attributes and forms a message. The interesting thing, however, is that it doesn’t SMS the TA. Instead, it raises a notification:status event. The TA must have an app installed in her personal event network to handle this event and notify her in some way. Nothing in this ruleset handles that event.

rule notify_ta {
  select when explicit on_call_request
  pre {
    person = event:attr("from");
    message = event:attr("message");
    end = event:attr("end");
    cookie = event:attr("cookie");
    msg = <<
#{my_name}, #{person} wants to meet in Cubicle 11. 
Your on call until #{end}. 
Respond with #{cookie} to take the appointment. 
'#{message}'
>>;
  }
  noop();
  always {
    raise notification event status with
      priority = "2" and
      application = "TA App" and
      subject = "On Call Request" and
      description = msg and
      _api = "sky" 
  }
}

Note that this rule doesn’t take any action (noop()); we merely want the effect of raising an event in the postlude.

Responding

The system is set up to allow the TA to respond to the student’s request to meet by merely sending an SMS back to the dispatcher. That’s the purpose of the two digit “cookie” that gets sent in-band with the message. The TA responds with any message she likes as long as it starts with the same two digits and the Dispatch ruleset will route the message to the right person.

Whenever Twilio receives an SMS, it raises a twilio:sms event. As I mentioned earlier, there’s a bit of semantic translation that occurs to determine what a twilio:sms event means. That is done by the sms rule in the Dispatcher ruleset:

rule sms {
  select when twilio sms
  pre {
    body = event:attr("Body");
    body_parts = body.extract(re/^(\d\d)\s(.*)$/);
    cookie = body_parts[0];
    msg = body_parts[1]
  }
  if (cookie) then noop();
  fired {
    raise explicit event schedule_response for a16x141 
      with cookie = cookie 
       and msg = msg;  
  } else {
    raise explicit event schedule_inquiry for a16x141 
  }
}

The sms rule looks at the incoming message and if it starts with a two-digit sequence, assumes that it’s a response from the TA and raises and explicit schedule_response event. Otherwise, it raises the explicit schedule_inquiry event. We saw earlier that the dispatch rule responds to the schedule_inquiry event.

The explicit schedule_response event is handled by the process_ack rule that processes the TA responses and sends an acknowledgment to the student:

rule process_ack {
  select when explicit schedule_response
  pre {
    phone_number = event:attr("From");
    ta_record = 
      subscribers.filter(
         function(r){
           phone_number.match(
                   ("/"+r{"phone"}+"/").as("regexp")
               )}
       ).head();
    ta_name = ta_record{"name"};
    ta_msg = event:attr("msg");
    msg = <<
#{ta_name} has been notified and will arrive 
shortly in Cubicle 11. He says '#{ta_msg}'
>>;
    student_num = ent:return_receipt{"x"+event:attr("cookie")};
  }
  if(student_num && ta_name) then 
       twilio:send_sms(student_num, ta_sms_num, msg);
  fired {
    clear ent:return_receipt{"x"+event:attr("cookie")};
  }
}

The rule uses the incoming phone number to filter the list of subscribers to retrieve the TA record in the subscriptions. That record is used to set the TA’s name. We also use the in-band cookie to retrieve information about the student to whom we’re responding. If the student number is found and that message came from a TA in the list, then we send an SMS back to the student and clear the return receipt.

Improvements

This federation could be improved in multiple ways:

Support subscription with an interface that allows TAs to come and go.
Integrate Foursquare data so that TAs who haven’t checked in aren’t contacted.

Conclusion

This blog post illustrates several important concepts.

The demo shows how personal event networks can be federated by subscription to achieve a group purpose.
The demo shows that apps can be installed to customize the owner’s experience.
The demo shows that apps can make use of shared services like the Simple Notification ruleset.
The demo shows how apps installed in a personal event network can make use of personal data stored separately in the network

Through these actions personal event networks provide operating system like services for their owners, giving them a personal cloud that can be customized to work for them.

February 3, 2012

An Operating System for Your Personal Cloud

Everyone has a cloud strategy these days. Of course, when you hear about clouds, you hear questions like “Are we talking about IaaS, PaaS, or SaaS?” This assumes an enterprise-centric view of clouds that is belied by what Robert Scoble calls the game of games. Facebook, Google, and Apple are most selling clouds in various guises and see their cloud strategy as a key to their future.

The problems with these “personal clouds” is that they have no operating system. An operating system is what makes your personal computer personal. Without an OS, it would be a special purpose appliance that does specific things (like run an office suite) but not others (like play a game). There are certainly those who wish that was the norm, but for now, at least, we have general purpose computers that run a variety of applications and can be configured according to the dictates and wishes of their owners.

[An aside for those of you getting ready to comment: yes Facebook allows apps and is an app platform, but they are ancillary to the experience, not core. The core experience is still very much a Facebook-determined thing.]

The user-focused clouds we see today are special purpose. You can’t customize them much or make them do something their builders didn’t envision in the selection of applications that they offer.

In contrast a personal event network is like an OS for your personal cloud. You can install apps to customize it for your purpose, it can store and manage your personal data, and it provides generalized services through APIs that any app can take advantage of.

February 1, 2012

Place-Based Networks

Here’s a thought-provoking piece on place-based networks from Gideon Rosenblatt.

Imagine if the Internet worked the way the real world does - and that physical places still helped build connection and community. That’s the idea behind Place-Based Networks; it’s mobile, social technology to help you connect with people based on your shared interest in a place.
From Place-Based Networks: A New Kind of Social Network » Alchemy of Change by Gideon Rosenblatt
Referenced Wed Feb 01 2012 07:27:40 GMT-0700 (MST)

I imagine that our personal event networks could help with that. If your personal event network knows where you are and what venues you frequent, it can automate things like tagging in your communications, negotiating meet-ups, and so on.

January 26, 2012

Podcatchers for Smartphones

As you might guess, given that I’m Executive Producer of IT Conversations, I like listening to podcasts. I’m also an iPhone user. Not to put too fine a point on it: iTunes sucks rocks for listening to podcasts. The problem is mostly that iTunes has a crappy interface for subscribing to and managing podcasts. It also downloads only one episode per day, with no way to change the defaults. Moreover it will stop downloading podcasts that you haven’t listened to for a while and you have to remember to go in an start it up. I started feeling like I had to “take care of iTunes” like it was a recalcitrant pet or something.

For some reason, it never really occurred to me to download an app for listening to podcasts, although I’ve downloaded several single purpose ones (like the This American Life app). Then Paul Figgiani introduced me to Downcast. I’m in love. I no longer have to fight iTunes and all my favorites are right there waiting for me to listen to them when I go for a walk or drive to work. The interface is good, with plenty of controls for skipping forward and back or adjusting the playback speed. I also like the built-in “share” features although I wish they allowed me to customize the default text for the share.

Unfortunately, Downcast isn’t available on Android. I have an Android tablet (Galaxy Tab) that I’ve used Google Listen on. It’s a functional podcatcher, albeit a little bare-boned compared to Downcast: no speed or skipping controls and no built-in sharing.

So, go grab Downcast, plug in the IT Conversations feed URL and enjoy great tech talks from the longest running podcast on the planet…no matter where you’re at.

January 20, 2012

My Letter to Senator Hatch in Opposition to PIPA

The Honorable Orrin Hatch
104 Hart Office Building
Washington, DC 20510
Fax: 202-224-6331

Dear Senator Hatch,

I’m writing to express my opposition to the Protect IP Act (PIPA). I have a PhD in Computer Science, have taught Computer Science at BYU, started several high-tech businesses in Utah (one of which, iMall.com, sold to Excite@Home in 1999 for $450 million), was the CIO for the State of Utah under Gov. Michael Levitt, and am the Precinct Vice-Chair in Lindon 04.

I’m pleased with Sen Reid’s decision to postpone the vote and with your recent opposition to PIPA. However I’m still concerned that the thinking that led to PIPA will lead to other equally bad legislation in the future.

The problem with PIPA and similar legislation is that it looks at copying as a feature of digital goods that can be selectively disabled. In fact, everything I know about computer technology leads me to believe that copying will only get easier and easier as technology progresses. We will never again live in a time when copying things is as difficult as it is now. And this will be true regardless of the laws we pass because copying is fundamental to the nature of computers and digital goods.

Consequently, efforts to make copying more difficult by technical means (such as the DNS blocking provisions in PIPA and SOPA) hurt legitimate uses of technology while leaving those who would copy without permission plenty of ways to circumvent those measures. You cannot plug this hole by hobbling the Internet and also be a proponent of economic growth. Those positions are incompatible.

I believe that the answer lies in enforcing existing laws in the courts where the accused are afforded due process and in working with other nations to create legal regimes wherein the guilty can be tried and punished. There are no technical shortcuts that will solve this problem.

I’d be happy to discuss this matter in more detail. I look forward to seeing you at the convention.

Respectfully,
Phillip J. Windley, Ph.D.

Note: the paragraph about copying paraphrases Cory Doctorow’s argument in his talk The Coming War on General Purpose Computing. I recommend listening to it.

January 14, 2012

Delivering Flowers with a Distributed Event System: Event Subscription in Action

This semester, I’m teaching a class at BYU, CS462. We’re using Opher Etzion and Peter Niblett’s book Event Processing in Action as the class text. The text uses a flower shop and delivery driver scenario as the running example throughout the book. Here’s a description:

The flower stores in a large city have established an agreement with local independent van drivers to deliver flowers from the city’s flower stores to their destinations. When a store gets a flower delivery order, it creates a request, which is broadcasted to relevant drivers within a certain distance from the store, with the time for pick up (typically now) and the required delivery time if it is an urgent delivery. A driver is then assigned and the customer is notified that a delivery has been scheduled. The driver picks up the delivery and delivers it, and then person receiving the flowers confirms the delivery time by signing for it on the driver’s mobile device. The system maintains a ranking of each individual driver based on his or her ability to deliver flowers on time. Each store has a profile that can include a constraint on the ranking of its drivers, for example a store can require its driver to have a ranking greater than 10. the profile also indicates whether the store wants the system to assign drivers automatically, or whether it wants to receive several applications and then make its own choice.

The following diagram (from the Event Processing Technical Society’s site) illustrates the interactions that take place between various entities:

The example that Opher details in the book has been implemented in several event processing systems.

If you follow my blog, you’ll know I have a particular view of evented systems based on distributed event processing taking place on event networks that are owned and run on behalf of particular entities. We call these personal event networks. In addition to writing a book on the subject, I’ve described personal event networks in various articles on this blog over the last six months:

N.B. If you’re in my CS462 class, it wouldn’t hurt to read them all. :)

Consequently, as we implement the flowershop example in my class, we’re going to do it with a personal event network twist. The result looks something like this diagram:

In the preceding diagram, there isn’t one event system that manages the interactions between the shops and the drivers. Rather, each driver has their own personal event network, each shop has their own personal event network, and the guild has one too. The interactions aren’t simply events raised within a single event network, but rather events raised between the networks of each participant. I’ve shown some of the apps that drivers, shops, and the guilds have installed on their personal event networks, but they would each be individually managed and configured. In fact, it’s reasonable to assume that different drivers or shops might use different apps for the same purpose as long as they understood the events.

The various personal event networks are linked together via event subscription. For example, a driver might subscribe to the delivery_ready event from each of the flowershops she wants to drive for. A driver who has a bad experience with a particular shop, merely unsubscribes from that shop’s delivery_ready events and never sees them again. Similarly, a shop that doesn’t like a particular driver can merely unsubscribe from them and no longer do business with them. I’ll be posting an example soon that shows how event subscription works in a personal event network. There are lots of details to work out and this blog post isn’t the place for them.

There are design choices to be made in this system. For example, there’s a “direct” arrow in the diagram indicating that shop and driver personal event networks can communicate directly. But the guild may chose to intermediate the interactions. In class, we’re going to be implementing the system with a direct connection first and then re-plumb the entire thing to use the guild as an intermediary. Intermediaries introduce interesting dynamics, making many things easier and increasing flexibility.

Overall, this example isn’t terribly different from the fourth-party ecommerce example I wrote about last June except that example featured hardwired connections between the shopper and the merchant rulesets. In contrast, this example uses the idea of event subscription to link merchants and customers. Event subscription takes the fourth-party example from a nice little demonstration to a conception of how VRM could work in the real-world. The diagram shown above can be partitioned to illustrate this:

Together with our ideas about how notification occurs and how personal data can be managed in personal event networks, event subscription creates a powerful system for enabling a completely new kind of interaction between vendors and customers (note that in this example, the flowershop is the customer who is negotiating for and buying delivery services from the drivers).

January 11, 2012

The Live Web is Live!

My book, The Live Web: Building Event-Based Connections in the Cloud, has been released and is on Amazon. Having the book actually available is great, although slightly anti-climatic after the thrill of just being done last November. :)

The book is my look at the future. When Eric Schmidt talks about a personalized house or we contemplate how commerce or health care will change in a completely connected world, that’s the Live Web.

Buying the book: If you are going to order a copy from Amazon, do be a favor and order it on Friday, January 13th. I’m trying to get the book to move up the rankings—if only for a day.

Here’s an excerpt from the Introduction:

For many years, pundits have foreseen a world in which everything will be connected to the Internet. We’re getting there. We now have Wi-Fi—enabled refrigerators, thermostats, and bathroom scales. But what happens after things are online? Will they merely connect to the Internet or will they connect to each other?

Connecting everything we use—products and services—to each other is a powerful idea. An idea that is bigger than mobile and social. Mobile’s big because everyone is connected all the time. Social is big because we’re connected to each other. Connecting us to everything around us is the next step.

Connecting our things to each other and setting them to work on our behalf is transformative. Imagine a world in which your phone automatically mutes the ringer when you start watching a movie. Imagine a world in which your alarm clock sets itself based on your schedule and other information like the weather, the traffic, and your past behavior. Imagine a world in which the mundane parts of business travel or scheduling an appointment with a new doctor are automatically taken care of according to your preferences. That world is the Live Web.

The Live Web: Building Event-Based Connections in the Cloud is a book about specific concepts, architectures, and technologies you can use to build Live Web experiences. This book is not easy; it requires that you think about Web programming from a brand new perspective. That’s hard for any of us. I have no business asking that of you unless there is a big payoff. There is: I believe the ideas and techniques in this book will help you build brand new types of Web experiences unlike those you can create using traditional Web technologies or languages like PHP or Rails. Don’t let this intimidate you. While this book asks a lot, the ideas are familiar and their application is engaging and fun.

The premise of this book is simple, but profound: The Web of the future—the Live Web—will link our lives in ways we can hardly imagine..and you can start building that Web today. While the request-response programming model we’ve been using has led to incredible applications and services, we can do more with a new model that complements—rather than replaces—the thinking that has led us so far. That new model is based on events.

Whereas today’s Web sites are about users interacting with relatively static pools of data, the cloud is giving us a brand new kind of data: data that is flowing, moving, and real-time. Data that links sites and services together. The cloud is about way more than just APIs to data and services—as important as that is. At its best, the cloud creates real-time interactions enabled by streams of data. The problem is that this kind of data doesn’t look like a request. Consequently using the tried and tested tools we’ve used to build Web services won’t take us where we need to go. Event-based interactions are the perfect model for taming these rivers of dynamic data and creating applications that make the most effective use of them.

Event-based applications are more loosely coupled than those built using a request-response model. I cannot overstate the case for loose coupling. As we move to a world in which more and more applications must coordinate their actions on our behalf, there is simply no way that we can pre-plan and orchestrate all the required interactions between them. Using systems that are supportive of and are architected for loosely coupled applications will play an important role in enabling the cloud-based future we envision.

This may seem a little overwhelming, but I have a secret weapon to help you out: a new programming language. I know what you’re thinking, “Wait, I’ve got to think differently about the Web and learn a new language too!?!” But in fact, I think the language helps, rather than hurts.

Tools shape how we think and work. I learned long ago that the best way to think differently about a problem is to create a nomenclature that describes and illuminates the new domain. In this book, you’ll use a language called the Kinetic Rules Language (KRL) to channel your thinking for this new model. KRL will lead you into the world of event-based programming on the Web.

KRL is a rule-based language that is custom built for the domain of event-based applications that operate on real-time data in the cloud. KRL was designed from the ground up with events and the cloud in mind. KRL provides a number of familiar touch-points for users already accustomed to Web programming and JavaScript, but provides a framework for making the most of an evented Web. While KRL is open and runs on an open source rules engine, you can get started with it right away using a cloud-based service.

While the ideas and techniques in this book can be implemented in any language, there is significant value in using a purpose-built language to guide our thinking. Remember, the ultimate value you will gain from this book isn’t learning any specific programming language, but in forcing your thinking down a new road—one in which events, rather than requests, reign supreme.

I’m very pleased with how the book turned out and extremely excited about the ideas in it. I hope you’ll read it, comment on it, review it, and try the ideas out. Undoubtedly, the future will turn out different than I’ve envisioned it, but I think we have an obligation to try to influence the design that emerges. The Live Web is my best thinking about how to do that.

Update: Some people have asked about a Kindle edition. There is a Kindle edition coming, but I don’t know when it will be available.

Organizations Get the IT They Deserve

Technometria

About Phil

Essays

Visit Count

Software

Topic Guides

Categories

Archives

Utah Tech Organizations

Friends

Copyright

Buy My Book

I'm CTO of Kynetx

Dates for IIW

Free Newsletter!

Search

Find Me Elsewhere

Digital Identity

Upcoming Events

Recent Entries