My G+ Profile
« May 2010 | Main | July 2010 »
June 23, 2010
CTO Breakfast Friday
The CTO Breakfast will be this Friday (Jun 25) at 8am in the Novell cafeteria. Anyone interested in how information technology is used to build products or run companies is welcome. Despite it's name, you don't have to be a CTO to attend--just interested in technology, where it's headed, and the problems of starting and building a high-tech business in Utah. Be sure to view the Google calendar of future CTO Breakfast events.
2:21 PM | Comments () | Recommend This | Print This
June 21, 2010
A Big, Programmable Event Loop in the Cloud
An event loop is a message dispatcher. The loop runs, waiting for events, and responding to them. This is how I've come to think of the Kynetx Network Service (KNS): a big, programmable event loop that runs in the cloud. We haven't always thought of KNS as an event loop, we used to think of it as a ruleset evaluation engine. These ruleset evaluations were tied to users visiting a page. We now view that as just one kind of event (a pageview event, to be specific). We also promoted some other events in the system (like Web clicks and form element changes) to first class events. Thinking of KNS as an event loop that is programmed via rules rather than simply as a ruleset evaluation engine, doesn't change the underlying system very much, but it does change the way we think about how it can be used.
When I wrote about the the addition event expressions to KRL last month, I introduced the idea of KNS being an event loop and explained our event expression language for describing complex event scenarios. These scenarios combine primitive events in various ways. Like any language however, the power of this concept is based on both the expressiveness of the operators for combining primitives and the breadth and depth of primitives that can be combined. Last month, there were just four primitives and they all worked only in the Web event domain: pageview, submit, click, and change. I hinted that more were coming someday; today is that day.
But wait! I'm not just going to introduce a few more event domains and event types within those domains. The changes we made in today's release will allow an infinite number of event domains and types because they're now completely definable by developers writing KRL. In addition, we've introduced the concept of "directives" which are ways for a KRL ruleset to create a set of instructions to send back to the endpoint that has raised a particular event. Here's how it works.
Rules are selected when it's event expression is satisfied. For primitive events, that means that the event is raised and the conditions around that event are met. The syntax for a select statement looks like this:
select when <event_domain> <event_type> {<param_name> <regexp>}*
[setting (<var>*)]
For example consider the following select statement from a KRL rule:
select when mail received
In this event expression, mail is the event domain and received is the event type. Any rule containing this statement will be selected when events matching the event domain and type are raised. Of course event expressions can be more complicated:
select when mail received from "(.*)@windley.com" setting(user_id)
This statement adds a parameter (from) and regular expression ("(.*)@windley.com") along with a setting clause to name the captured variable. You can have as many parameter checks as you want. The select statement shown above will only be satisfied when the event domain and type match and there is a parameter called from that has a value that matches the given regular expression.
Of course, defining your own events is only half of the game. You also want to respond to them. For Web events, KNS responds with Javascript. We expect that there will be many endpoints besides browsers that choose to accept Javascript because of it's flexibility, but simple endpoints will want something easier to consume than a complete Javascript program. We've introduced a send_directive action that provides for this. For example the following action will send a directive named say with a parameter named something that has the value "Hello World".
send_directive("say") with
something = "Hello World";
A rule or ruleset can send zero or more directives to the endpoint as the result of a single event being raised. The endpoint will see them as JSON and can interpret them any way it wants. The developer's job is to
- Design the events that the endpoint will raise
- Design the directives that the endpoint will respond to
- Create an endpoint that does these things
- Write rulesets that the endpoint uses.
Of course, its possible that a single endpoint might have multiple rulesets that use it from multiple developers trying to do different things. I suspect that will be the case for the IMAP endpoint we're working on right now.
Defining events that an endpoint can raise and directives that it can consume is similar to creating a protocol. Since the quintessential introductory example for a protocol is an echo server, I've built one in KRL. We'll define the event domain to be echo and define two event types: hello and message. That means we need at least two rules, one for each event type. We could have more if we want to respond to different parameters. Here's the rules I defined:
rule hello_world is active {
select when echo hello
send_directive("say") with
something = "Hello World";
}
rule echo is active {
select when echo message input "(.*)" setting(m)
send_directive("say") with
something = m;
}
The rule hello_world responds to the hello event by sending the directive named say with the parameter something set to "Hello World". The rule echo responds to an echo event with a parameter called input. That entire value of the input is caputured and bound to the variable m. The echo rule send a directive named say with the parameter something set to the value of m.
It's critical to note that the underlying KNS engine doesn't know anything about the event domain echo or the event types hello and message. We could define these to be anything we wanted and the example would work the same.
Of course, this ruleset with it's understanding of the echo events and directives is useless without a corresponding endpoint to raise these events and consume the directives. Endpoint can be created in any number of different ways. I've written a simple Perl program to do the job. Here it is:
#!/usr/bin/perl -w
use strict;
use Getopt::Std;
use LWP::Simple;
use JSON::XS;
use Kynetx::Raise;
# global options
use vars qw/ %opt /;
my $opt_string = 'h?e:m:';
getopts( "$opt_string", \%opt ); # or &usage();
my $event_type = $opt{'e'} || 'hello';
my $message = $opt{'m'} || '';
my $event = Kynetx::Raise->new('echo',
$event_type,
'a16x66',
{'host' => '127.0.0.1'}
);
my $response = $event->raise({'input' => $message});
foreach my $d (@{$response->{'directives'}}) {
if ($d->{'name'} eq 'say') {
print $d->{'options'}->{'something'}, "\n";
}
}
This simple script uses a module called Kynetx::Raise that I wrote to take the relevant information about the event, create the right URL for the Kynetx event API, raise the event by calling the URL and process the response. You can see that it has the possibility of taking the event type from the command line with the -e switch. If none is given, the event type defaults to hello. Consequently running this program with no arguments results in the hello_world rule we defined above firing and the directive say "Hello World" being sent to the program which prints the message.
Running the program with the -e switch like so:
./echo.pl -e message -m 'KRL programs the Internet!'
results in the string KRL programs the Internet! being printed in the terminal. W00t!
The addition of support for generalized primitive event specifications and directives is a significant increase in the power of KRL to program the Internet. Now any connected device can serve as a KRL endpoint and received instructions from cloud-based KRL programs. Who will be the first to mashup their sprinkler system with Google calendar?
9:59 AM | Comments () | Recommend This | Print This
June 16, 2010
Making It Big in Software
This week on Technometria, Scott and I talk with Sam Lightstone about his new book Making It Big in Software.
The book isn't just about great software personalities, although you could be forgiven for thinking so looking at the cover. This excellent book is career advice for developers at every stage. The interviews with 17 software greats are interspersed between the chapters on everything from what they didn't teach you in school to becoming a leader and visionary. I enjoyed talking to Sam and reading the book.
8:07 PM | Comments () | Recommend This | Print This
June 12, 2010
Early Voting in Utah County: Vote for Joel Wright
I'm encouraging everyone I know to vote for Joel Wright for Utah County Commission. Joel is running against Gary Anderson. Joel is experienced and believes that the proper role for county government in creating jobs is to keep taxes low, plan for and build needed infrastructure, and stay out of the way. Joel recognizes that Utah county will have 1,000,000 residents (twice our current population) in 20 years and the time to plan for that growth is now.
If you're of a mind to vote for Joel, the following table (taken from the Utah County clerk) shows early voting times and locations in Utah County for the upcoming June primary:
Utah County Primary Election 2010 Early Voting Schedule and Locations June 8-11 and June 14-18 |
|
| Location | Times |
| Utah Community Credit Union 1364 North Commerce Drive Saratoga Springs |
1 pm - 5 pm |
| American Fork Library* 64 South 100 East American Fork |
3 pm - 7 pm |
| Orem City - City Building Rotunda 55 North State Street Orem |
1 pm - 5 pm |
| Utah County Courthouse - Rotunda 51 South University Avenue Provo |
8 am - 5 pm |
| Spanish Fork National Guard Armory* 2801 North Main Street Spanish Fork |
3 pm - 7 pm * Friday, June 18, 2010 3 pm - 5 pm |
2:13 PM | Comments () | Recommend This | Print This
June 10, 2010
Starting a High Tech Business: Plugging the Fat Pigeon
I'm starting a new business called Kynetx. As I go through some of the things I do, I'm planning to blog them. The whole series will be here. This is the twenty-fourth installment. You may find my efforts instructive. Or you may know a better way---if so, please let me know!
Some companies are "high-tech" companies. That is, their business model requires building custom technology that differentiates them from their competitors. Others don't differentiate through technology per se, but how they use it. In other words, their business model isn't very dependent upon building intellectual property in the form of software.
As many of you know, Kynetx is a Platform as a Service (PaaS) play. We essentially have a giant, programmable event loop in the cloud. Our business model is to get other folks to use our platform and pay us for the privilege. Anyone who's been is the PaaS business will tell you that occasionally customers decide that they'd like to do it on their own whether for cost, flexibility, or whatever. When one of our customers does that we call it "plugging the fat pigeon." (Yeah, there's a story behind that--ask me sometime.)
The intersection of these two ideas is interesting. We've had one company, whose business model didn't seem overly dependent on high-tech, plug the fat pigeon and hire a developer to essentially recreate small pieces of our platform. That made their business entirely dependent on this small, poorly documented codebase. Of course, you know the rest of the story: the developer quit and now their wondering how to proceed.
I believe that any company whose business model is based on "high-tech" ought to have a founder CTO. There's no way around it. That doesn't mean they ought to write their own code. In fact, I think there are lots of high-tech businesses that can be built on IaaS, PaaS, and even SaaS cloud platforms. I know of many.
But the opposite it also (almost always) true. If you're not a high-tech startup, you have no business (literally) hiring developers to recreate things you can buy somewhere else. You're just asking for trouble. Unless you're big and stable enough to have an IT department, you won't be able to create a codebase that creates lasting value. In most cases you'll end up just like the pigeon plugger I mentioned above: sitting on a business dependent on something you don't understand and can't properly leverage.
The moral of this story: find a platform that does what you want and use it. If you can't find one, then you're looking at a business that will be dependent on the technology you build and you'd better get a CTO co-founder who can code and is incented to stay the course.
2:22 PM | Comments () | Recommend This | Print This
June 7, 2010
Kynetx Code Run I
Image via Wikipedia
Saturday was my birthday. About a month ago, I told everyone at Kynetx that what I wanted for my birthday was some cool Kynetx apps. On Thursday at noon, we shut down normal work and everyone broke into teams. They had 24 hours to program an app that would impress their competition. We called this the Kynetx Code Run; it's loosely modeled after Atlassian's FedEx Day.
The rules were pretty simple:
- Teams can consiste of 1, 2, or 3 people.
- Remote employees are encouraged to be at KWHQ for the event.
- Apps that can be listed in the Marketplace get extra points.
- You may form teams and talk about ideas before June 3, but you may NOT write any code until we start.
- You may work any number of the 24 hours.
- People who aren't Kynetx employees may participate, but each team must have at least one Kynetx employee.
There was also one rule that was specific to our platform: You may only use emits to work around limitations of the runtime and then only if you can present a short plan of how the new feature will be incorporated into the runtime later. KRL has the ability emit raw Javascript and I didn't want people building apps that didn't primarily use KRL for a few reasons:
- I wanted any Javascript that was used to be something we could roll into the platform for everyone's benefit
- I wanted people to explore the boundaries of KRL itself, both it's limitations and the features they might not have ever tried
The exercise was a rousing success. I was very pleased with the efforts of all five teams; they came up with some good apps and all of them surprised me in different ways. Here are the results.
Web Treasure Hunt - This app used KRL to create a treasure hunt across multiple Web sites for children's books. The purpose could be educational or merely fun. What surprised me about this app was the backend that allowed anyone to create a treasure hunt of their own.
Baseball - This app places a single baseball image in the upper right hand corner of certain Web pages. When you click on it, you get a modeal window that gives you baseball news and statistics from other sites as well as a schedule of upcoming games. What surprised me about this app was the great eye candy and the feature that added games to your Google calendar when you clicked on them.
WALLet - This app takes your Facebook Wall off Facebook and onto other sites where you might want to see what your friends are up to. Just want to take a quick peak at your wall without going to the Facebook site? Just tap the tab on the side of your browser and a tray slides out with the most recent posts. It even removes the posts about games so you don't have to waste your time seeing who's gathering eggs or needs fuel. What surprised me about this app is the ability to comment or post right there.
Mantones - This app starts with the premise that you some guys might like certain ringtones on their phone that are, shall we say, less than manyly. After noting the Bluetooth IDs of your friends phones, this app will switch out the ringtone on your phone for something more manly when you are in their vicinity. Of course you could also use it to silence the ringer in a conference room or your boss' office. What surprised me about this app was that it used KRL in a domain completely outside the Web: programmatically controlling your mobile device.
Barnes and Noble - This app is designed to be run as a proxy inside a BN store. The app showed specials and upcoming events. What surprised me was the ability to search events at nearby BN stores and add them to your calendar. I loved that this app was ready to demo to BN or any other retail establishment that offers free WiFi to show how Kynetx can augment that experience.
There were also a few apps written outside the game itself: Cid wrote a stand alone app that kills posts about Facebook games from your wall. I use that one now. Sam and Dave created an app that shows you where your flight is (on flights with inflight Wi-Fi) and lists Wikipedia articles about nearby places or features. Sam also created an app that uses the HTML5 geolocation information to do that same thing for HTML5 aware browsers.
In the coming weeks, we'll document each of these with a video and code, where we can, so that you can see them in more detail. Watch for them on Kynetx Code.
All in all, I was very happy with my "birthday presents." All five teams shows ingenuity and pushed the envelop in different ways. The goal of a Kynetx Code Run is for everyone to have fun and to gain some experience using our platform to build real apps. We weren't disappointed. A big thanks to everyone at Kynetx for making my birthday one to remember!
11:17 AM | Comments () | Recommend This | Print This
June 3, 2010
Auto Importing iPhone Pictures to iPhoto
Image via Wikipedia
One of the things I hate about syncing my iPhone is that it fires up iPhoto everytime there's any pictures that need to be imported. That's a pain. I'd rather that the photos got automatically imported and deleted off the device. Today I figured out how to do it. Note that these instructions assume Snow Leopard.
First thing to know is that Image Capture is your friend. You can use it to determine what happens when you plug in a device that looks like a camera on a device-by-device basis. For our purposes, there's a little known program called AutoImporter. Select that as the program to run when your iPhone is plugged in.
AutoImporter need to be configured to do the right thing. The application is located in System -> Library -> Image Capture -> Support -> Application. Fire it up (without a camera device attached to the computer) and look at it's preferences. If all you want is to have you pictures automatically offloaded into a folder on your computer, just select the folder, give it a naming convention, and determine whether to delete them from the camera or not when you're done. Easy. I did notice it's a little quirky about setting the subfolder name.
The problem is that we want them in iPhoto and that's not an option. Further, if you choose iPhoto as the application to start inside Image Capture, it won't automatically import. So, we have to trick it. Inside the iPhoto Library (inside your Pictures folder) there's a folder called Auto Import. To get to it, you have to right click the iPhoto Library and choose "Show Package Contents." The problem is that you can't do that from inside AutoImporter, so we have to get tricky.
Open the iPhoto Library in Finder and then right click the Auto Import folder and choose "Make Alias". Now move that alias somewhere outside the package (like your Pictures folder). Now you can choose this alias as the folder that AutoImporter puts pictures and select a naming convention for folders created in that folder.
Now, if you've done it right, when you plug in your iPhone, the photos will be copied to this folder and deleted from the phone automatically. The next time you start iPhoto, everything in the Auto Import will be imported.
Hat tip to Macworld "Image Capture Gets Smarter" (couldn't fond the story online to link to) and Mitch Cohen for the information that helped me put this together.
4:22 PM | Comments () | Recommend This | Print This
June 2, 2010
CTO Breakfast on Thursday
The CTO Breakfast will be held this Thursday, June 3 at 8am in the Novell Cafeteria. Anyone interested in how information technology is used to build products or run companies is welcome. Despite it's name, you don't have to be a CTO to attend--just interested in technology, where it's headed, and the problems of starting and building a high-tech business in Utah. Be sure to view the Google calendar of future events.