edoism

CloudOS Event Protocol Update

2012-07-14T16:31:00.000-06:00

The Kynetx CloudOS Ruleset and Module provide and event based interface to the Personal Cloud account services. The account services include the ability to manage Personal Clouds, Personal Channels and Rulesets within a Personal Cloud. The CloudOS module provides functions to access the account services and the Ruleset provides includes system Rules that provide access to the account system. This week we have updated the functions provided by the module to operate with the current Personal Cloud, or within another Personal Cloud identified by a Personal Channel.

If you want to used the CloudOS function within the current Personal Cloud simple omit the userToken parameter when calling the function. For example, to uninstall a Ruleset from the current Personal Cloud:

pre {
  rulesetStatus = CloudOS:rulesetRemove("a169x404");
}

However, if you want to uninstall a Ruleset for another Personal Cloud you will need to include a Personal Channel identifier for the target Personal Cloud:

pre {
  authToken = "71760130-a8f8-012f-4a37-00163ebcdddd";
  rulesetStatus = CloudOS:rulesetRemove("a169x404", authToken);
}

Of course in order to use the functions provided by the CloudOS module you must include the following pragma in the meta section of your ruleset:

user module a169x625 alias CloudOS

Documentation on the functions provided are available at developer.kynetx.com. Functions are provided by the CloudOS module to create, destroy and list Personal Channels, to add, remove and list Rulesets, and to create and authenticate with Personal Clouds.

Enjoy!

Personal Cloud Subscription Walkabout

2012-07-05T16:58:00.000-06:00

The objective of this article is to explore the steps necessary to establish Personal Channels between two Personal Clouds. The notion of a subscription in this context is that a Personal Channel is established which permits events to be raised from one Personal Cloud into another Personal Cloud. So we need to create two Personal Channels, one channel for Ben to raised events into Ted's Personal Cloud and a second Personal Channel for Ted to raised events into Ben's Personal Cloud. We begin this exercise with two Personal Clouds, one for Ben and second one for Ted. In addition, there is a well known public Channel into Ted's Personal Cloud which we will call the doorbell.

We will begin the process of establishing the Personal Channels from Ben's Personal Cloud. An event will be raised by Ben into Ted's Personal Cloud over the public channel identified by the doorbell. We will call this a subscription request. As part of the subscription request Ben will need to create a new Personal Channel which can be used to raise events into his Personal Cloud. We will label this new Personal Channel, ChannelA.

subscriptionRequest(ChannelB, doorbell)

When Ted receives the subscription request event he will save the Event Channel Identifier, ChannelA, so that he may use it in the future to raise events back into Ben's Personal Cloud.

Then Ted will respond to the subscription request by raising an event back to Bob over ChannelA. We will call this a subscription confirmation. As part of the subscription confirmation Ted will need to create a new Personal Channel which can be used to raise events into his Personal Cloud. We will label this Personal Channel, ChannelB.

subscriptionConfirmation(ChannelB, ChannelA)

When Bob receives the subscription confirmation he will save the Event Channel Identifier, ChannelB, so that he may use it in the future to raise events back into Ted's Personal Cloud.

Now both Ben and Ted has Personal Channels which can be used to raise events into each others Personal Clouds.

SkyApp Skunkworks: Personal Cloud User Profile

2012-07-02T20:55:00.000-06:00

SkyAppTwo is a single-page application that list the application and channels for the Personal Cloud. Twitter Bootstrap is used to provide a responsive web interface, with the Kinetic Rules Engine (KRE) providing the event processing back-end. The SkyApp is built on a refactored module for accessing the accounting system called CloudOS. Note that after you authenticate the CloudOS Ruleset/Module is installed into your Personal Cloud.

View Demo Online Download Source Code

SkyApp Skunkworks: Personal Cloud Application Template

2012-06-25T13:55:00.004-06:00

SkyAppOne is a single-page application template for the Personal Cloud. Twitter Bootstrap is used to provide a responsive web interface, with the Kinetic Rules Engine (KRE) providing the event processing back-end. This initial template provides an example of how to handle routing via URL hashtags and authentication with the Kynetx account system. Future SkyApp templates will offer additional solution specific examples.

View Demo Online Download Source Code

CRUD in Your Personal Cloud

2012-06-21T10:23:00.000-06:00

In this article we will develop a watch action for form submits within the Sky Event API. Previously we have done CRUD with KRL, which enables the development of data storage modules. While the watch() action works well with the current Blue API, it does not yet support the Sky Event API. We have added a watch_submit() defaction to the SkyKit module so that you can create a data storage module in your Personal Cloud.

View Demo Online Download Source Code

The demo ruleset is executed as a site tag. The ruleset executes a raise_delegate() into a Personal Cloud, with event type formTest.

SkyKit:raise_delegate("formTest", "f6511bf0-9ba1-012f-7a7a-00163e64d091")

With the data storage module ruleset installed in the Personal Cloud, the formTest rule is fired:

rule formTest {
  select when web formTest
  pre {
    eci = "f6511bf0-9ba1-012f-7a7a-00163e64d091";
    firstName = ent:firstName || "";
    lastName  = ent:lastName || "";
  }
  {
    SkyKit:watch_submit("#formDemo", eci);
    emit <<
      $K('#firstName').val(firstName);
      $K('#lastName').val(lastName);
    >>;
  }
}

This rule sets a watch for form submit and displays the current values within the data store. When the form is submitted a Sky Event will be raised into the Personal Cloud associated with the Event Channel Identifier.

rule formSubmit {
  select when web submit "#formDemo"
  pre {
    firstName = event:attr("firstName");
    lastName  = event:attr("lastName");
  }
  { noop(); }
  fired {
    set ent:firstName firstName;
    set ent:lastName lastName;
  }
}

The formSubmit rule will be fired when the form is submitted, saving the values into the data store.

View Demo Online Download Source Code

Enjoy!

Time Travel with KRL

2012-06-20T15:05:00.000-06:00

Well perhaps not time travel in the science fiction sense, but we will be performing transmogrification between time format specification ... which is time travel in the developer sense (grin). A recent project involved reading an RSS feed and formatting it for display within a web page. Unfortunately the pubDate time format in the RSS feed was not compatible with the KRL time library. So we developed a KRL function to convert the time format. Perhaps you will find this function useful when you embark on your own time travels.

The RSS pubDate time string accepted by the KRL function is of the format:

Wed, 21 Sep 2011 15:02:01 -0700

and will be converted to RFC3339 format:

2011-09-21T15:02:01-07:00

We use the function to convert the RSS pubDate, then call the time:strftime() library to generate the needed display format:

krlDate = rss2krlTime("Wed, 21 Sep 2011 15:02:01 -0700");
strDate = time:strftime(krlDate, "%b %d %Y");

Here is the KRL time travel function is all it's glory:

rss2krlTime = function(pubDate) {
  tarr = pubDate.split(re/ /);
  tzoff = tarr[5].replace(re/\d\d$/, "");
  rfcTime = tarr[3] + "-" + mon2num{[tarr[2]]} + "-" +
            tarr[1] + "T" + tarr[4] + tzoff + ":00";
  rfcTime
};

mon2num = { "Jan": "01", "Feb": "02", "Mar": "03",
            "Apr": "04", "May": "05", "Jun": "06",
            "Jul": "07", "Aug": "08", "Sep": "09",
            "Oct": "10", "Nov": "11", "Dec": "12" };

Enjoy!

KRL Quickie: Embedded Site Tags

2012-06-20T11:11:00.001-06:00

Your KRL Ruleset can be executed on your web page by simply embedding a site tag. The end user does not need to install a browser extension for your ruleset to run. Of course you will need to be able to modify the files on the website directly in order to embed the site tag.

To have the ruleset a169x616 excuted on your website, add the following javascript just before the closing body tag:

Adding this site tag to your web page will execute the production version of the ruleset everytime the web page is visited. If you would rather execute the development version of your ruleset add the following javascript just before the closing body tag:

Knock on the Sky and Listen for Events

2012-06-19T10:58:00.000-06:00

With the introduction of the Kynetx Sky Event API you can now raise events to all the rulesets installed in your Kynetx Personal Cloud without the need to specify a ruleset. Prior to the release of the Sky Event API events had to be raised to a specific ruleset using the Blue API. This feature of the Sky Event API extends the late binding nature of the Kynetx platform. As a developer you do not need to hard code a ruleset ID. For the end-user you have the freedom to choose which ruleset you want to respond to an event when it is raised.

View Demo Online Download Source Code

For the developer you can still raise explicit events with the Sky Event API. Simply add "_api" = "sky" to the attributes of your raise explicit statement. Raising an explicit Sky Event in this manner will result in the event being raised to all of the rulesets that are installed in the end-users Personal Cloud. (Aside: At this time the end-users Personal Cloud is that same thing as their Kynetx account.) As a result all installed rulesets with matching select statements will trigger their rules to fire.

The power of the Sky Event API really comes into focus with the ability to raise events into other Personal Clouds! While broadcasting an event within your own Personal Cloud is cool, raising events into other Personal Clouds over event channels is were the magic of the Sky Event API really excels. Sending events in Parallel is an excellent example of using the Sky Event API in this manner.

The pattern that I want to share with you today is how to run javascript when raising a Sky Event into a Personal Cloud. The starting point for this pattern is provided by the send_event defaction developed by Phil Windley in Sending Events in Parallel. There are two important extensions we will make to send_event. First, in order to return javascript, instead of directives, we must raise our event in the "web" domain. Second, to have the javascript executed we must inject the Sky event signal URL into the DOM. This defaction has been release a part of the public module SkyKit.

raise_delegate = defaction(type, token) {
  configure using attrs = {}

  dom = "web";
  eid = math:random(9999999);
  arg = attrs.keys().map(function(x) {
          uri:escape(x) + "=" + uri:escape(attrs{x});
       }).join("&");
   esl = "http://cs.kobj.net/sky/event/" +
         "#{token}/#{eid}/#{dom}/#{type}?#{arg}";
   {
     emit <<
       var r = document.createElement("script");
       r.src = esl;
       r.type = "text/javascript";
       r.onload = r.onreadystatechange = KOBJ.url_loaded_callback;
       var body = document.getElementsByTagName("body")[0] ||
       document.getElementsByTagName("frameset")[0];
       body.appendChild(r);
     >>;
  }
};

To demostrate this pattern we will install a ruleset into a Personal Cloud with a single notify() action:

rule sayHello {
  select when web sayHello
    notify("Kynetx SkyKit Demo", "Hi, I'm App #1") with sticky = true;
}

Then create an Event Channel Identifier for the Personal Cloud:

f6511bf0-9ba1-012f-7a7a-00163e64d091

And finally we will create a ruleset that use raise_delegate():

rule testme {
  select when pageview
    pre {
      eci = "f6511bf0-9ba1-012f-7a7a-00163e64d091";
    }
    {
      notify("Kynetx SkyKit Demo", "Hello, World!") with sticky = true;
      SkyKit:raise_delegate("sayHello", eci);
    }
}

This will not be installed into the Personal Cloud, but will be exeucted as a bookmarket. You can take it for a test drive on Heroku.

View Demo Online Download Source Code

Enjoy!

Making LinkedIn API Calls From KRL

2011-12-30T14:54:00.000-07:00

Using the KRL OAuthModule you can access the LinkedIn API from your Kynetx application. Here's the KRL demo code to perform the authorization.

View Demo Online Download Source Code

Enjoy!

Using Twitter Bootstrap with KRL

2011-11-20T21:38:00.001-07:00

Twitter recently released Bootstrap, a library of CSS styles and set of javascript plugins to kickstart development of webapps and sites. I have found it to be a real time saver when building prototypes with KRL. Since Bootstrap uses jQuery it was easy to enhance the code to work with Kynetx KRL. I have updated the Bootstrap demo pages to use the embedded version of jQuery in KRL. The updated demo includes links to the updated javascript files that can be used with KRL.

View Demo Online Download Source Code

To use the embedded version of jQuery within KRL change the last like in each Bootstrap plugin from:

}( window.jQuery || window.ender );

}( window.$KOBJ );

We are 90% done! The remainder of the effort is to move Javascript includes from the HTML file to the KRL webapp with use javascript resource.

View Demo Online Download Source Code

CSS Inception with Kynetx

2011-10-25T23:22:00.000-06:00

While developing an administrative interface for a web application I only wanted to load the CSS stylesheet for the administrative view when it was needed. KRL provides the ability to define CSS in the global section and load external CSS files. However, both methods insert the CSS into the page every time the Ruleset is evaluated. I really did not want to load hundreds of lines of useless CSS into every page.

View Demo Online Download Source Code

My solution was to harvest the load external stylesheet code from the KRL runtime and wrap it in a defaction.

loadStylesheet = defaction(cssURL) {
  loadCode = <<
    var head=document.getElementsByTagName('head')[0];
    var new_style_sheet=document.createElement("link");
    new_style_sheet.href="#{cssURL}";
    new_style_sheet.rel="stylesheet";
    new_style_sheet.type="text/css";
    head.appendChild(new_style_sheet);
  >>;
  emit << eval(loadCode);  >>;
};

Now I can load external stylesheets programatically:

rule inject_css {
  select when click "#ignite"
  {
    loadStylesheet("http://assets.lobosllc.com/css/inception.css");
  }
}

View Demo Online Download Source Code

KRL Safari: KRUD Redux - Kynetx CRUD with Persistent Variables

2011-10-10T16:29:00.001-06:00

Recent updates to the Kynetx platform related to Hash expressions has given me the opportunity to revisit my previous post. If your WebApp has modest requirements for storage of data it is worthwhile considering the use of Persistent Variables. To demonstrate the salient principles of using persistent variables as a datastore, a simple Kynetx WebApp addressbook is provided.

View Demo Online Download Source Code

The addressbook application stores the name, email and phone number of each person. The addressbook data is stored in a single persistant variable as key/value pairs. With the persons name used as the key:

"SomeName" : {
    "Name"  : "SomeName",
    "Email" : "SomeEmail",
    "Phone" : "SomePhone"
}

Since there is a lot of to wade through, so let me point out that parts specifically related to reading, writing and remove entries in the addressbook. In order to read all of the entries in the addressbook the following ruleset is used:

foreach ent:KRUDaddresss.keys() setting (addressKey)
pre {
  email = ent:KRUDaddresss{[addressKey, "Email"]};
  phone = ent:KRUDaddresss{[addressKey, "Phone"]};
  addressRow = &lt;&lt;
      
          #{addressKey}
          #{email}
          #{phone}
          Remove
      
  >>;
}
{
  append('#panelAddressList .DataTable tbody', addressRow);
}

New entries for the addressbook are entered via a standard HTML form. With a watch() placed on the submit the following rule captures the entry from the form, builds a new entry and adds it to the persistent variable:

select when submit "#formAddressAdd"
pre {
  formName  = event:param("formName");
  formEmail = event:param("formEmail");
  formPhone = event:param("formPhone");
  formHash = {
      "Name"  : formName,
      "Email" : formEmail,
      "Phone" : formPhone
  };

  KRUDaddresss = ent:KRUDaddresss || {};
}
{ noop(); }
fired {
  set ent:KRUDaddresss{[formName]} formHash;
}

Entries are removed from the addressbook by calling the following rule with an entries name as the event parameter:

pre {
  keyName = event:param("keyName");
}
{ noop(); }
fired {
  clear ent:KRUDaddresss{keyName};
}

You can play with the online demo to see the end results. And you can get the source code for the whole WebApp on GitHub. Heads up, there's a lot of code in the WebApp related to the GUI, that's why I wanted to call out the salient CRUD elements above. Enjoy!

11 Oct 2011: Revised code for adding new addressbook entries to use the new expression syntax for Persistent Hashes. When these new expressions are used you avoid loading, binding and transferring the entire hash.

View Demo Online Download Source Code

KRL WebApp Template and Cheatsheet

2011-10-09T19:04:00.000-06:00

Let me share with you the Kynetx KRL template that I use as a starting point for all of the web applications that I develop. The template not only gives me a solid starting point for each Kynetx WebApp, but contains samples of KRL syntax and contructs, as well as reminders of componets to be added prior to release of the WebApp. Before releasing a Kynetx WebApp there are two components that I always include. First, a method for collecting any errors that may be encountered while the WebApp is being used. Second, a method of collecting some basic usage statistics.

View Demo Online Download Source Code

ErrorStack provides a excellent cloud based service to collect errors for WebApps. Since a Kynetx WebApp will be running in the browser of your end-user it will be almost impossible to find out when an error occurs. That's where ErrorStack comes to the rescue! By simply including an ErrorStack application key in your Kynetx WebApp errors will be collected via the ErrorStack service. Absolutely brilliant! As an added bonus Phil Windley provides an error handling module that can be used to send all user and system level errors related to your WebApp to ErrorStack.

StatCounter provides user analytics for your WebApp. Just like you would not launch a website without including analytics, you shouldn't release a WebApp without including analytics. In this template an invisible image is inserted when the WebApp gets run. This will provide you with the basic information about the number of users, which browser they are using, etc. I've made the StatCounter project analytics for this template publicly available so that you can appreicate the value of this service.

The rest of this template contains KRL constructs which I use frequently. But alas I often mistype the exact syntax, so this gives me a single point of reference so that I don't have to search through old WebApps for a sample to cut & paste. There are samples for using the integrated Kynetx jQuery UI libary, including external javascript and CSS resources, raising explicit events, and web events.

Last, but certainly not least there is a link to test the development version of the WebApp using the brilliant Ktest service offered by Randall Bohn. As a matter of fact you can demo this WebApp template using Ktest. Here is a screenshot:

View Demo Online Download Source Code

KronHooks: An Event Scheduling Service for Kynetx Applications

2011-09-01T15:49:00.000-06:00

KronHooks is a time-based event scheduler for Kynetx applications. The Kronhooks service enables Kynetx developers to raise events into the Kynetx Network Services API at regular intervals of 5, 10, 30 or 60 minutes.

The strength of the KRL event based architecture enables a developer to extent the platform to interact with many other systems. KRL already has built-in libraries for interacting with Facebook, Twitter, Amazon and many others. In the past I have developed KRL Modules to pull data from Qwerly, PeerIndex and Empire Avenue, but the development of the KronHooks service takes a different perspective.

The KronHooks service was developed to push events into a Kynetx Ruleset. In essence it is a external service which can be used by a Kynetx developer to raise events into their application on a regularly scheduled basis. In order to receive the events from the KronHooks service a developer only needs to add a select statement to a rule:

select when kronhook igvmgjf

Perhaps a simple example will help to clarify. Let's write a Kynetx application that will send out a tweet every 5 minutes. Not a practical application in the real world, unless you want to be unfollowed by everyone. To build the demo application we will configure KronHooks to raise an event into your Kynetx Ruleset every 5 minutes. The Kynetx rule receiving the event will publish a tweet with the current time.

On the KronHooks site select an interval of 5 minutes and enter the RID of your Kynex application:

Click the Add button and your freshly minted kronhook will be added to the service. You will note that KronHooks has generated an event name for you new addition, in this example the event name is igvmgjf:

KronHooks has already begun to raise events into your Kynetx Ruleset with RID a169x397! So let's add the necessary select statement:

select when kronhook igvmgjf

Here is the KRL source for the whole rule:

rule MyKronHook {
  select when kronhook igvmgjf
  pre {
    hookTime = event:param("hook.time");
    msg = "KronHook raised an event at #{hookTime}";
  }
  {
    twitter:update(msg);
  }
}

Every 5 minutes when KronHooks raises the event into your Kynetx Ruleset, the select statement will cause the rule to fire. In the prelude of the rule the parameter hook.time provided by KronHooks will be retrieved and used to create a status update on Twitter.

Warning: Technical deep dive ahead! The KronHooks service raises events based on the specification given in the Kynetx Network Service API. Thus, a event is raised by performing a POST to:

http://cs.kobj.net/blue/event/kronhook/event_name/rid

More specifically for this demo the URL was

http://cs.kobj.net/blue/event/kronhook/igvmgjf/a169x397

Please consider the KronHooks service a beta. With your feedback we can mature and stabilize it to become a useful production service.

The KRL source for the demo application is available as a gist and the source for KronHooks is available as a public repository on GitHub edoructt/KronHooks.

KRLCode: Kynetx Ruleset Source Code Search

2011-08-30T12:24:00.000-06:00

The goal of KRLCode is to provide a simple interface to search Kynetx KRL Ruleset source code. While many good snippets of KRL have been published in blogs, posted on StackOverflow and released as Gist, it can difficult to find the one you need. I've begun to collect them in a GiHub repository and provide a simple interface to search the collected works of Phil Windley, Sam Curren, Mike Grace, Alex Olson, Steve Nay, Randall Bohn, Aaron Frost and myself.
Your contribution to the KRL Code repository would be most appreciated. Just send a tweet to @KRLCode with the URL of your KRL Ruleset.

Sexy Twitter Authorization for KRL

2011-08-29T09:43:00.000-06:00

A new KRL library has been released that enables you to build a sexy Twitter authorization. The OAuthModule provides a generic process for making OAuth 1.0A authentication and protected resource requests. This means that you can now make your own authorization request to Twitter, and many other services.

Using oauthmodule:get_auth_url function you get a URL that can be used to start the OAuth authorization dance. While you could simple perform the action within the current browser window, it is so much nicer to pop open a new window. So what we've done is attach a click event to the image that was added to the page.

We the images is clicked a new browser window is opened using the URL that was returned from oauthmodule:get_auth_url. Then we have a setInterval timer which watches for the window to close.

Here is the KRL source code

KRL Safari: KRUD - Kynetx CRUD with Persistant Variables

2011-02-04T10:25:00.000-07:00

Got KRUD? In this KRL safari we will be using persistance variables as a database. While most web developers have written code to access a database, most Kynetx applications retrieve their data via RESTful web services. But there are times when a persistant data store is needed. Building a one off web service to host the data is certainly an option, but if the storage needs are moderate you can simply use a persistant variable. After all 2 million bytes of data can be stored in a persistant variable!

To keep the focus on the mechanics a simple data structure is used to demonstrate KRL CRUD ... an array of strings which will be used to implement a tag cloud. The demo provides a web interface to see all of the strings in the tag cloud, add new tags and delete tags. To permit the demo to be accessible to a broad audience, it has been distributed using a site tag. Just visit the demo page to see all of the current tags which have been entered by all who have used the application. You can add a new tag by entering text into the form, then click the Add button. To delete a existing tag simply click on the text of the tag.

While the KRL code has comments thoughout, it should be emphasized that application persistent variables accessed in the rule prelude:

TagCloud = app:TagCloud;

And the updated persistent variable are saved in the postlude:

set app:TagCloud TagCloud;

Adding a new value to the persistent variable is performed using the union operator:

newCloud = TagCloud.union(cleanTag);

Removing a value from the persistent variable is done using the difference operator:

newCloud = TagCloud.difference(tagText);

To see the implementation using a complex data structure take a look at Kynetx App A Day 28 Updating User's List When User Joins App.

Hey! Where's the U in KRUD? Multiple choice response:

Left as an exercise for the reader
Updated was not needed for demo
I'm lazy :)

Enjoy!

KRL Scope Safari: Application Variables

2010-12-22T10:15:00.000-07:00

The safari continues with a tour of persistent application variables. This is the second article in the series to chronicle the investigation of scope and extent of persistent variables in the Kynetx KRL platform. In the first KRL Scope Safari we explored persistent Entity Variables. Application variables in KRL are used to record persistent data within a ruleset. The value of an application variable is retained between execution of the ruleset. So far application variables seem to be the same as entity variables. The difference is that application variables are shared across all sessions of the ruleset. They are not restrained to a single browser session. A truly global application variable!

Note: For another perspective on KRL persistent variables I would highly recommend the Kynetx App A Day article Day 12 - Persistent Variables by Michael Grace.

We need some KRL code for this safari! Starting with the KRL from the last safari we replace all occurrences of ent:safari_entity with app:safari_app. There are three rules in the demo application. The first rule, Safari_Initialize displays a growl notification which includes a title, the current value of the application variable and two html forms which permit the application variable to mutated and cleared. The second rule, Safari_Respond_Submit processes the form submission to mutate (change) the application variable. The last rule, Safari_Respond_Clear processes the form submission to clear the application variable.

The value of the application variable can be accessed inside prelude expressions. In the prelude section of Safari_Initalize the value of safari_app is accessed. Application variables are mutated in the postlude section of a rule. In the postlude section of Safari_Respond_Submit the value of the application variable safari_app is set to the value of newValue. And in the postlude section of Safari_Respond_Clear the application variable safari_app is cleared.

It's demo time! You can follow along with the demo by running the application in two separate browsers at http://kynetx.aculis.net/safari/app.html The screen shots below are taking from Mozilla Firefox and Google Chrome. Starting in Firefox, the very first time the Kynetx ruleset is run the application variable does not exist, so it's value is set to "Just Born!". Note: Your mileage may vary since the application variable will retain it's value from the last user.

The value of the application variable can be changed by entering a new value into the text field.

After the Mutate button is clicked the current value of the application variable is set.

Switching over to the Google Chrome browser, when the Kynetx ruleset fires the value of the application variable is the same as it was in Firefox. This is our proof that the application variable is accessible to all running sessions of the ruleset.

Still in Chrome a new value is entered into the text field.

After clicking the Mutate button the current value is updated.

Back to the Firefox browser, the page is reloaded and we can see that updated value of the application variable is the same as it was in Chrome.

Clicking the Clear button will destory the application variable.

Finally we reload the page in Chrome after it has been cleared.

In the next KRL Scope Safari we will add Modules to the adventure! Will we be able to share an persistent application variable between to different rulesets by using the same module? Stay Tuned!

Enjoy!

KRL Scope Safari: Entity Variables

2010-12-21T12:12:00.000-07:00

This KRL Safari will investigate the scope and extent of persistent variables on the Kynetx KRL platform. We begin the expedition with the most familiar type of persistent variable, the Entity variable. Entity variables in KRL are used to record persistent data within a ruleset. The value of an entity variable is retained between executions of the ruleset. It is important to note that the scope of an entity variable is directly associated with your browser session.

Note: For another perspective on KRL persistent variables I would highly recommend the Kynetx App A Day article Day 12 - Persistent Variables by Michael Grace.

Since the definitive authority is code, here is a KRL ruleset! There are three rules in this demo application. The first rule, Safari_Initialize displays a growl notification which includes a title, the current value of the entity variable and two html forms which enable the entity variable to mutated and cleared. The second rule, Safari_Respond_Submit processes the form submission to mutate (change) the entity variable. The last rule, Safari_Respond_Clear processes the form submission to clear the entity variable.

The value of the entity variable can be accessed inside of a prelude expression. In the prelude section of Safari_Initalize the value of safari_entity is accessed. Entity variables can be mutated in the postlude section of a rule. In the postlude section of Safari_Respond_Submit the value of the entity variable safari_entity is set to the value of newValue. And in the postlude section of Safari_Respond_Clear the entity variable safari_entity is cleared.

Now it's time to start the safari demo of persistent entity variables. You can follow along with the demo in another browser window by visiting http://kynetx.aculis.net/safari/entity.html. When this Kynetx ruleset is run for the first time the entity variable does not exist, and so it is set to the value "Just Born!".

The value of the entity variable can be changed by entering a new value into the text field.

After the Mutate button is clicked the current value of the entity variable is updated.

When the browser window is reload or a new window is opened the current value of the entity variable remains the same.

Clicking the Clear button will destory the entity variable.

Then when the browser window is reloaded, or a new window is opened, we are back at the beginning of this demo.

An extremely important point to note is that entity variables are tied to your browser session in much the same way as browser cookies. You can see this for yourself by running this demo in two separate browsers (e.g. Firefox & Chrome) or by running the demo on two separate computers. Simply running the demo in two separate Firefox windows on the same computer is not the same since the session is the same.

The Scope Safari continues next time when we look at the scope of Application persistent variables on the Kynetx platform.

Enjoy!

Now You Can "Like" Any Company on LinkedIn

2010-11-27T13:47:00.000-07:00

Inspired by Jess Stay's Kynetx application that enables you to like any Tweet on Twitter.com, I wrote a variation which will let you Like any company on LinkedIn.com. The Kynetx application can be installed as a browser extension available for Firefox, Chrome and Internet Explorer from the Aculis website. Once you will the application installed you will be able to Like company pages on LinkedIn.

Here's an example of me liking the Aculis company page on LinkedIn:

Which is displayed in my profile on Facebook like this:

One of the more interesting parts of this Kynetx application is that to avoid having Likes for each of the subordinate company pages on LinkedIn a regular expression is used to extract the company name from the URL:

select when pageview "/company/([\w\-]*)" setting (companyName)

Then the extracted company name is inserted into the call to the Facebook Like widget before it is inserted into the webpage:

href=http://www.linkedin.com/company/#{companyName}

You can take LinkedIn Like for a test drive by installing the browser extension from the portfolio page. And the Kynetx KRL source code for the application has be posted to GitHub as a gist.

Enjoy!

Happy Hack'in with Kynetx JSONPath

2010-11-09T13:46:00.000-07:00

You can doing amazing things with the tools that are available to you, if you only take the time to learn how to use them. That was how I felt after taking the time to dig into the details of JSONPath. The Kynetx KRL language contains a number of mini languages, regex, jQuery, JSONPath, etc. While I was fortunate to have JSON data source for the CloudStatus application, the structure of the data was not usable. Or so I initially thought.

First some background on the CloudStatus application. The CloudStatus application will provide a list of public API services that are having performance issues. Basically it will tell you which services are not ok. Fortunately I was able to find the JSON (actually JSONP) data which is used to build Public API Status. However, the JSON was structured so that it could be easily used to build a website which reports the status of all 26 services, not just report the bad ones. No problem I'll just write another utility application to transform the JSON into a structure that will be easier for the CloudStatus application to consume.

Good idea, right? Well, yes, no, maybe. Honestly I really did not want to spend the time to code, test and debug an application that transformed JSON data. Sorry, it's just too tedious! But being lazy in this regard motivated me to dig into the details of what can be done with JSONPath. It's far more powerful that I initially assumed. And after about 30 minutes I was able to craft a JSONPath expression that extracted the data that I needed. Awesome!

The source JSON data was structured with the list of 26 services in random order. With 6 attributes provided for each of the services, including the name of the service and current status (ok, warn, or err). All that we need for the CloudStatus app is the list of services that are not ok. Using a JSONPath filter expression we grab a list of services where current status is not ok (current_status ne 'ok'). But since we only need the name of the services, not all of the attributes, we'll just retrieve the name:

BadServices = status_json.pick("$..services[?(@.current_status ne 'ok')].name")

Now BadServices contains array of the services names that are having performance issues. And we didn't have to hack a pile of tedious code to transform the JSON into a new structure for our application to consume. Three cheers for JSONPath!

["bing search API", "Box.net API", "Flickr API"]

We still need to get the list into string format so that it can be passed to Twilio, and from an end user point of view we should remove the text "API". Using the KRL join operator we can convert the array to a string:

BadString = BadServices.join(" and ")

Giving us the the BadString:

"bing search API and Box.net API and Flickr API"

Finally, we remove all occurrences of the string "API" using the replace operator.

YouAreBad = BadString.replace(re/ API/g, "")

Which gives us a string containing the list of bad services:

"bing search and Box.net and Flickr"

Enjoy and happy hack'in!

Kynetx Flow of Control in CloudStatus

2010-11-08T17:46:00.000-07:00

The development of solutions within an event based language like Kynetx requires you to remap your architecture skills. It's more common for us to apply object oriented or functional methodology, but not so common to apply an event architecture. To that end I wanted to share with you the architecture of the CloudStatus Kynetx application.

First a brief overview so that you have some context. The CloudStatus Kynetx application provides the status of 26 public APIs. If there are currently any performance issues or service disruptions one quick phone call or text message to (801) 988-9093 will provide the status. When you first call CloudStatus a summary of the services with issues is given, after a short greeting. Then you are presented with a menu of choices. After selecting one of the menu options, and hearing the results, the menu of choices are repeated. Now let's see what that looks like when implemented with Kynetx.

Below is a skeleton of the CloudStatus application. So that we can focus on the flow of control in the application some of the details have been abbreviated or removed. The full source code for CloudStatus Kynetx application is available at GitHub.

The entry point into the application is an incoming call from Twilio, rule #1 twilio inbound_call. After the gretting we raise an explicit event which gives the summary of under performing services. Then another explicit event is raised which takes you to rule #2 explicit givemenu.

Rule #2 is at the top of the multi-select loop and is the center piece of the applications flow of control. One of the main features to note is the parameter passed into gather_start(). It is the event name we have choosen, and it is used in many of the rules which follow. In addition you will notice that we have specified that only one digit will be accepted. So when the caller pressing a single digit we will be off and running.

When the caller presses 1, 2, 3 or 0 rule #3, #4, #5 or #6 is fired respectively. Otherwise, Rule #8 is fired. This is the multi-select pattern! So if the caller presses number 1, rule #3 will fire because it matches the event name statuschoice with the qualifier Digits "1". Recall from above that we choose the event name statuschoice in the gather_start() action. The next rule to fire will be #7 which matches event name statuschoice and any one of the digits 1, 2 or 3. This rule provides the looping which takes us back to rule #2 by raising an explicit event. If the caller presses either the number 2 or 3 the pattern is similar.

If on the other hand the caller presses number 0, then Rule #6 fires, which says goodbye and terminates the call. You will note that Rule #7 does not fire when the Digits is 0, so the caller is not taken back to Rule #2 to hear the menu. The application flow drops through to the end, no loop. there are done.

Finally, if the caller presses any other number then Rule #8 fires, telling them of their poor choice and then taking them back to Rule #2 by raising an explicit event.

Twitter WebHook for Kynetx Applications

2010-11-02T13:03:00.003-06:00

You can have a Twitter WebHook for your Kynetx application by using Notifo and the Push.ly services. Herein are the configuration steps and a simple HelloWorldish Kynetx application. Your Kynetx application will be called where your Twitter account receives a DM, mention, gets a new follower or when someone favorites one of your tweets. Let's jump right into the configuration steps!

For this demo we will be using the aculishook (Aculis WebHook) Twitter account. The first thing you will need to do is to Sign Up for a Notifo account. For this demo we will be using the aculishook account. After you have set up an account at Notifo head on over the Push.ly and sign in with your Twitter account. Once you are signed into Push.ly, enter your Notifo username and select the actions for which you would like notifications (aka WebHook calls). From the screenshot below you can see that I have selected all the actions.

Now let's head back to Notifo to set up the WebHook call into our Kynetx application. On the Notifo site visit the notifications page (Login then click Settings and click on Notification Settings). Then fill out the "Notification Webhook URL" field then click Save.

The construction of the WebHook URL for a Kynetx application is described in the online Kynetx documentation for Webhook Endpoints:

http://webhooks.kynetx.com:3098/h/{appid}/{eventname}

The appid is the Kynetx application identifier assigned automatically when you created your application. You don't have any choice to make here, just cut & paste. For this demo the appid was a169x151. The eventname is completely in your hands, choose something meaningful as you will also need to use it as an event name in your Kynetx application. For this demo application the eventname is notifohook.

Finally we have the Kynetx application which will receive the WebHook calls from Notifo. The bit of Kynetx code that enables your application to respond is in the select statement:

select when webhook notifohook

Notice that eventname notifohook is the same one that was used in the WebHook URL enter at Notifo? Notifo WebHook calls pass along ten parameters which are available as event:param("") within your Kynetx application. This demo application does not do anything particularly interesting with the data received, it's just saved to a Google form.

ruleset a169x151 {
  meta {
    name "Aculis WebHook"
    description << Aculis demo of Kynetx Twitter Webhook  >>
    author "Ed Orcutt"
    logging on
  }

  dispatch {
    domain "example.com"
  }

  global { }

  rule Notifo_Webhook is active {
    select when webhook notifohook
    pre {
      notifo_id          = event:param("notifo_id");
      notifo_message     = event:param("notifo_message");
      notifo_service     = event:param("notifo_service");
      notifo_signature   = event:param("notifo_signature");
      notifo_title       = event:param("notifo_title");
      notifo_to_username = event:param("notifo_to_username");
      notifo_type        = event:param("notifo_type");
      notifo_unix_time   = event:param("notifo_unix_time");
      notifo_uri         = event:param("notifo_uri");
      notifo_webhook_url = event:param("notifo_webhook_url");
    }
    every {
      http:post("https://spreadsheets.google.com/a/aculis.net/formResponse?formkey=dElUWGxHSmppczd5Mnl3S0dRaWE0X1E6MQ&ifq")
        with params = {
          "entry.0.single": notifo_id,
          "entry.1.single": notifo_message,
          "entry.2.single": notifo_service,
          "entry.3.single": notifo_signature,
          "entry.4.single": notifo_title,
          "entry.5.single": notifo_to_username,
          "entry.6.single": notifo_type,
          "entry.7.single": notifo_unix_time,
          "entry.8.single": notifo_uri,
          "entry.9.single": notifo_webhook_url,
          "submit": "Submit",
          "pageNumber": "0",
          "backupcache": ""
        };
    }
  }
}

You can take this demo for a test drive by following the Twitter account aculishook, mentioning @aculishook in a tweet or by favoring one of aculishook's tweets. Then visit the Google Form to see the results. The web page view of the Google spreadsheet is only updated every 5 minutes, so there will probably be a delay before you can see the effect of your action. However, the actually Google spreadsheet is updated immediately from the Kynetx application.

Do let me know if you have found this information useful or if you have any questions!

Enjoy!

BiGoHoo! Search Results Mashed with Facebook Like

2010-10-11T14:33:00.003-06:00

Eager to put the newly released Kynetx Annotation V 2.0 framework to use has given birth to BiGoHoo! This initial release of BiGoHoo inserts the number of Facebook Likes for the search results on Bing, Google and Yahoo!. The Kynetx KRL source code for BiGoHoo is available from GitHub. You may also take BiGoHoo for a test drive by download the browser extension for Firefox, Internet Explorer or Chrome.

Here's a quick screenshot of BiGoHoo in action on Google:

Update 13 Oct 2010: Integration with Twitter and Google Buzz have been added to BiGoHoo. The updated Kynetx source code has been posted to Github.Here's an updated screenshot from Google which includes the integration of social media data from Facebook, Twitter and Buzz:

Kynetx Annotation Framework V 2.0 Basics

2010-10-11T06:50:00.004-06:00

The release of the Kynetx Annotation V2.0 framework provides us with an extensible and feature rich API for the building website mashups. Out of the box the Annotation framework will enable you to develop mashups on Google, AOL Search, Bing, Yahoo! Search, HotBot, Ask.com, AlltheWeb, AltaVista, Facebook and LinkedIn. With just a bit on configuration the framework can eazily be extended to work on other websites not supported by the default configuration. Three basic patterns of annotation are now supported by the framework: local, remote and event.

Below are working examples of each of the three basic annotation patterns. Links are provided to both the KRL source code at GitHub and browser extensions for you to install. Many thanks to Cid and the Kynetx Team for providing us with this awesome annotation framework!

Local JavaScript Annotation
Using local Javascript annotation you provide the annotation framework with a Javascript callback function that will be envoked after the data is collected from the web page. The Javascript callback function will be passed a reference to the item which is under consideration for annotation, a wrapper div element which you can use to for annotation, and the data collected from the web page which you can use to determine how to annotate.

The Kynetx KRL source code for the local JavaScript annotation example in the documentation is available from GitHub. You may also take the example for a test drive by download the browser extension for Firefox, Internet Explorer or Chrome.

Remote Annotation
Remote annotation enables you to call a remote services to determine which items on the web page will be annotated. The remote service will be called using JSONP. The remote service will be passed a list of items, each will contain an item reference, the full URL of the item (e.g. http://live.gnome.org/Cheese), and the domain name (e.g. live.gnome.org). The remote service should return the list of items to be annotated, each with the item reference and any values to pass to the Javascript callback function as data parameters.

The Kynetx KRL source code for the remote annotation example in the documentation is available from GitHub. The source code for the web service is also available from GitHub. You may also take the example for a test drive by download the browser extension for Firefox, Internet Explorer or Chrome.

Event Annotation
The Event annotation pattern is truly the most interesting and powerful of the three patterns. By using the Kynetx Web Event Action the framework fires a rule back on the Kynetx Server, which can either directly annotate or provide data for the annotation to be performed by a local Javascript callback function. The rule is passed both an annotation reference and JSON structure which contains the data collected from the web page by the framework.

The Kynetx KRL source code for the event annotation example in the documentation is available from GitHub. You may also take the example for a test drive by download the browser extension for Firefox, Internet Explorer or Chrome.

It is also possible to directly add an annotation from within the event rule which is fired. So instead of making additions to the JSON data structure, simply call annotate:add_annotation. The Kynetx KRL source code for the javascript annotation via event example in the documentation is available from GitHub. You may also take the example for a test drive by download the browser extension for Firefox, Internet Explorer or Chrome.

Enjoy!