Empower non-programmers to generate an OPK script for a USB drive #32

rjcorwin · 2015-04-30T22:42:24Z

We'll build a GUI that talks with hub.openpipekit.org, presents some forms to users, and then gives them a download to put on a USB Drive for their Pipe hardware.

Template started here -> https://gist.github.com/rjsteinert/32c43313cf80e4ce6c10

rjcorwin · 2015-05-01T16:07:41Z

When we build autorun files for Linux, when we build a sketch, we create a recipe... for a robot. Sometimes robots shoot rockets and talk about coming back, but a lot of times they are just picking something up and putting it down; there are different types of Robots. A Pipe is a kind of Robot. When we create a Pipe script, we create recipe for a Pipe Robot. For example...

blink yellow

watch -n60 "./drivers/opk-temper1-cli-0.5.0/pull --path USB1 | ./drivers/opk-phant-cli-0.3.0/push --url data.sparkfun.com --public_key E9fejd9efjfj --private_key IIF9efejfese83n" &

blink green

That's a pretty simple Pipe Robot that pulls from a temperature sensor every 60 seconds and pushes it to a phant server. It's also a recipe that someone else could use for their own needs by replacing the public and private key parameters.

blink yellow

watch -n60 "./drivers/opk-temper1-cli-0.5.0/pull | ./drivers/opk-phant-cli-0.3.0/push --url data.sparkfun.com/ --public_key G44jd9oDJetbsoh --private_key iDIgensiDeksj" &

blink green

This is pretty common in coding. You write some piece of code and it ends up as a template for when you want to do the same thing but with slightly different ingredients. The trick is to remember which ingredients should or can be replaced. This is sometimes solved by setting some variables at the top of the file to remind us of what can be tweaked in the script. Another approach is to generate the code by feeding data to a template, often referred to as a "generator", or "scaffolding", or "automatic programming". I'm interested in shareable generators for our MVP.

Imagine if I published a generator for a recipe like...

blink yellow

watch -n<%= frequency_in_seconds %> "./drivers/opk-temper1-cli-0.5.0/pull | ./drivers/opk-phant-cli-0.3.0/push --url <%= url %> --public_key <%= public_key %> --private_key <%= private_key %>" &

blink green

If I gathered some ingredients like...

{
  frequency_in_seconds: 60,
  url: data.sparkfun.com,
  public_key: E9i4kf93e9jf3,
  private_key: Eeife3e00fkkfh
}

... and then ran those ingredients through the generator I would end up with a recipe like ...

blink yellow

watch -n60 "./drivers/opk-temper1-cli-0.5.0/pull | ./drivers/opk-phant-cli-0.3.0/push --url data.sparkfun.com --public_key E9i4kf93e9jf3 --private_key Eeife3e00fkkfh" &

blink green

Imagine an app that...

Users can submit generators.
Users can find other people's generators.
A User can tell the the App to parse a recipe into a configurable form that the user then fills out and gets an autostart/sketch file as a download.

In hindsight, what we have been prescribing around drivers is to build a driver that describes itself as half of a generator in a pipe. Put two together and you get a pipe. A Pipe is a type of Robot, and a point we will not lose sight of. We can build a GUI App that, from OPK Compliant CLIs, can generate generators that can then be used in the mentioned workflow above. This is a "generator of generators", sometimes referred to as a generator with sub-generators. But back to MVP, before the generator of generators, I think we need a healthy, low barrier to entry, social way of sharing and using generators.

With the goal of build an app that can use generators to build recipes, we're free to start being creative with our own hand written recipes and see how they evolve into generators, and then later into sub-generators.

Let's build recipes, lets build recipes, lets build robots!

dwblair · 2015-05-01T16:34:44Z

This is brilliant.

It sort of reminds me of some of the approaches to 'generating embed code' for HTML: e.g. for video you want to embed, you're asking to check off dialog boxes / enter text in fields to specify certain features -- width / height / format -- and then you're, in real time, the HTML that this generates, and which you could then paste into your own HTML code.

Maybe that's an accessible potential approach -- showing the user how changing options affects the autostart script, live?

I really like these ideas!

One caveat that occurred to me: in the end, the action is happening via these command line drivers and the scripts that run them. Here, we're trying to build accessible entrees into that, by autogenerating useful combinations of these CLIs and scripts. This can be useful and important; but it also adds another 'layer' on top of the action -- and we end up with another 'language' -- a sort of 'metalanguage' that the user needs to learn ...

In the end, I guess I'm just backing up RJ's idea, here, and love the recipe idea -- but right now I'm thinking of it terms of a 'language' metaphor: what we've done so far w/ OPK is to specify a sort of loose 'pipe grammar' for how to build up sensor data flows: "Let's PULL data from a sensor and then PUSH that data to a database"

PULL [sensor] | PUSH [database]

Now we're talking about scripts that use this basic grammar to accomplish more data flows -- monitoring several sensors every 5 minutes, say.

If you really understand the grammar, and how to form sentences, then you're good to go. But for people who don't quite grasp the grammar, or who want to use some of the tricks (colloquialisms?) of the UNIX command line, we provide a 'phrasebook' ...

PULL data from a [TEMP SENSOR] and a [CONDUCTIVITY SENSOR] and PUSH it to [PHANT DATABASE]

[OPK code here]

Another thought just occurred to me: this is also sort of like having a book of 'common pipe fitting arrangements' or something ...

... maybe it'd be nice to have a graphical metaphor for what we're doing?

rjcorwin · 2015-05-01T18:37:04Z

What are those games called that you fill out a verb and then an adjective and then a noun and then a .... and then it shows you a story using those words and it's totally ridiculous?

dwblair · 2015-05-01T18:42:03Z

Mad Libs!

http://www.madglibs.com/showglib.php?glibid=185

On Fri, May 1, 2015 at 2:37 PM, R.J. Steinert notifications@github.com
wrote:

What are those games called that you fill out a verb and then an adjective
and then a noun and then a .... and then it shows you a story using those
words and it's totally ridiculous?

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

rjcorwin · 2015-05-01T19:21:48Z

Haha ya. Mad Libs.

So one of the "pipe dreams" of computing is the ability to tell a computer to do something in plain English like...

"Make me a sandwhich."

Oh wait, it's a computer, so...

sudo apt-get install sandwhich --directory /home/me/belly

Converting statements from humans to something computers understands has a long way to go. It seems like most of the speech recognition out there is a Mad Lib. For example, the Mad Lib, or statement maybe is a good way putting it, that we're after in it's most simple form is :

"On a [hardware], pull from [sensor] and push to [database] every [number] seconds"

Going after this "pipe" statement is what I was doing in the On-Pipe App. Here's a screenshot of the last question for the Mad Lib that results in a computer statement.

A simple sentence but the devil is in the details. Those things you fill out for each "filler" in the Mad Lib result in various dependencies, specific drivers, lots of options to determine how those drivers work, etc. The schema I've been brainstorming for hub.openpipekit.org is a sort of Ontology that a computer can work with that users define that result in being able to do that particular statement as a Mad Lib.

I must say though, these kinds of projects are tough. There's a reason why loose JSON APIs with accompanying documentation are popular on the web and APIs based on RDF/Ontologies are mostly ignored. Working with a strict vocabulary is HARD. Hard to program and hard for end-users to wrap their minds around.

rjcorwin · 2015-05-01T22:12:14Z

Wireframe of a "Recipe" page. It's kind of like gist.github.com except each gist is a recipe template and there is a form below that allows you to customize the recipe for your needs.

rjcorwin · 2015-05-04T14:52:47Z

I whipped up an App that picks up a json file that describes a recipe and presents it like so. In this example I set the {{number}} ingredient to 30, clicked "Bake It", and now we see the Recipe script in the Muffin box with {{number}} set to 30. Next step is to tie this app to a backend with user authentication and the ability to create new recipes. That will get us to MVP, then we can work on improving this UI to make it inviting for both programmers and non-programmers. I'm also interested in brainstorming the name for this kind of thing. It's not just about pipes, it's recipes for robots.

chrowe · 2015-05-04T21:33:11Z

Mad Libs Input Form

Interesting that https://ifttt.com/ uses the recipes term as well

https://zapier.com/ has some good examples of how to handle complex forms that are conditional based on the input and the output.

rjcorwin · 2015-05-05T01:59:12Z

Wooooow. That article on Madlib style forms is really interesting. We could
incorporate the form into the statement and get rid of the muffin because
the code would just be the result of what is in the statement. That makes
documenting the variables in the form and the statement the same thing. I
think that might be a really good idea.

On Monday, May 4, 2015, Chris Rowe notifications@github.com wrote:

Mad Libs Input Form
http://tynerblain.com/blog/2010/03/01/measuring-interaction-design/

Interesting that https://ifttt.com/ uses the recipes term as well

https://zapier.com/ has some good examples of how to handle complex forms
that are conditional based on the input and the output.

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

RJ

rj@rjsteinert.com
http://rjsteinert.com
http://twitter.com/rjsteinert
http://github.com/rjsteinert

rjcorwin · 2015-05-05T02:55:54Z

Bam. Working prototype. Two screenshots. First one is the form on load. Second one is after the user types the number sixty. The recipe code updates on every keystroke in the statement form.

Screenshot 1

Screenshot 2

dwblair · 2015-05-05T08:28:44Z

SO. COOL.

On Mon, May 4, 2015 at 10:55 PM, R.J. Steinert notifications@github.com
wrote:

Bam. Working prototype. Two screenshots. First one is the form on load.
Second one is after the user types the number sixty. The recipe code
updates on every keystroke in the statement form.
Screenshot 1

[image: screen shot 2015-05-04 at 10 51 21 pm]
https://cloud.githubusercontent.com/assets/156575/7466416/7672d9a4-f2b0-11e4-9046-49207958506b.png
Screenshot 2

[image: screen shot 2015-05-04 at 10 54 52 pm]
https://cloud.githubusercontent.com/assets/156575/7466428/a1dab526-f2b0-11e4-9a0c-9a9dd348a90c.png

—
Reply to this email directly or view it on GitHub
#32 (comment)
.

rjcorwin · 2015-05-08T05:43:19Z

I now have a Drupal backend running that provides Recipe json objects. The URL is on Github but it's actually pulling data from a Drupal site hosted on Pantheon. More work to be done but we're getting there!

http://openpipekit.github.io/Recipe-App/#recipe/1

rjcorwin · 2015-05-18T18:25:55Z

rjcorwin · 2015-05-25T20:49:20Z

Quick note on personas...
Recipe Developer: Someone with some coding background that is capable of making Recipes.
Robot Builder: Someone who may have no background in coding but can use Recipes to build robots.

Yeobot is in the picture now. Because Yeobot clones a repository that could contain compiled binaries for sensor drivers, there is less pressure on Recipe Developers to make a "Jack in the Box" script that downloads and compiles dependencies. This is good! Less of a barrier to entry for Recipe Developers.

With no Jack-in-the-Box, something still needs to act as a build machine that runs the Yeobot command that downloads the Recipe and transforms it according to variables set by the Robot Builder. Hosting a special build machine is one way but probably an unsustainable option at the moment because it would require us to host and maintain more software. So... Dogi and I talked about how to turn Robot Kitchen into a Jack-in-the-Box builder that would hand over something to the Robot Builder that would result in their own Raspberry Pi acting as a build machine.

The method we are closest to achieving is putting the yeobot script on our R-Pi build and having Robot Kitchen generate autorun.sh files like the following.

#! /bin/sh

yeobot --repository git@github.com:rjsteinert/Yeobot-pull-from-Temper1-push-to-Phant.git --variables '{"{{wifi-name}}":"pirate","{{wifi-password}}":"ship", "{{number}}":"60","{{phant-url}}":"{{data.sparkfun.com}}","{{phant-field-name}}":"temperature","{{phant-public-key}}":"IDdfe3fij3j", "{{phant-private-key}}":"dkfiDfeEJekehje"}'
reboot

What that would do when it runs is a clone that results in replacing itself (because that repo has an autorun.sh script) and then using the variable input from the Robot Builder.

We also discussed how if we are generating JITBs, why not also generate some network configuration and not have to depend on Recipes to take care of that.

#! /bin/sh

pirateship --ssid pirateship
yeobot --repository git@github.com:rjsteinert/Yeobot-pull-from-Temper1-push-to-Phant.git --variables '{"{{wifi-name}}":"pirate","{{wifi-password}}":"ship", "{{number}}":"60","{{phant-url}}":"{{data.sparkfun.com}}","{{phant-field-name}}":"temperature","{{phant-public-key}}":"IDdfe3fij3j", "{{phant-private-key}}":"dkfiDfeEJekehje"}'
reboot

This is nice so you don't have to write 3 different Recipes to connect a temper1 sensor to phant depending on wether you want to connect to WiFi, 3G USB, or Ethernet.

But how about another step further in this direction that makes this all seem less cryptic to Robot Builders that might inspect the files that Robot Kitchen generates... Going the Adafruit way maybe Robot Kitchen does not generate autorun.sh scripts, maybe it just generates config files that some Daemon on our R-Pi build is listening for.

{
  "wifi": {
    "ssid":"pirate",
    "password":"ship"
  },
  "recipe": {
    "url": "git@github.com:rjsteinert/Yeobot-pull-from-Temper1-push-to-Phant.git",
    "variables": {
      "{{number}}":"60",
      "{{phant-url}}":"data.sparkfun.com",
      "{{phant-field-name}}":"temperature",
      "{{phant-public-key}}":"IDdfe3fij3j",
      "{{phant-private-key}}":"dkfiDfeEJekehje"
    }
  }
}

This would result in the Daemon running the commands from the prior autorun.sh example yet it would be much more readable to the Robot Builder, some of whom would be able to make this by hand without the help of Robot Kitchen.

rjcorwin added 0 - Backlog 2 - In progress and removed 0 - Backlog labels Apr 30, 2015

rjcorwin self-assigned this Apr 30, 2015

rjcorwin changed the title ~~Generate autostart.sh from a GUI~~ Empower non-programmers to generate an OPK script for a USB drive Apr 30, 2015

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Empower non-programmers to generate an OPK script for a USB drive #32

Empower non-programmers to generate an OPK script for a USB drive #32

rjcorwin commented Apr 30, 2015

rjcorwin commented May 1, 2015

dwblair commented May 1, 2015

rjcorwin commented May 1, 2015

dwblair commented May 1, 2015

rjcorwin commented May 1, 2015

rjcorwin commented May 1, 2015

rjcorwin commented May 4, 2015

chrowe commented May 4, 2015

rjcorwin commented May 5, 2015

rjcorwin commented May 5, 2015

dwblair commented May 5, 2015

rjcorwin commented May 8, 2015

rjcorwin commented May 18, 2015

rjcorwin commented May 25, 2015

Empower non-programmers to generate an OPK script for a USB drive #32

Empower non-programmers to generate an OPK script for a USB drive #32

Comments

rjcorwin commented Apr 30, 2015

rjcorwin commented May 1, 2015

dwblair commented May 1, 2015

rjcorwin commented May 1, 2015

dwblair commented May 1, 2015

rjcorwin commented May 1, 2015

rjcorwin commented May 1, 2015

rjcorwin commented May 4, 2015

chrowe commented May 4, 2015

rjcorwin commented May 5, 2015

rjcorwin commented May 5, 2015

Screenshot 1

Screenshot 2

dwblair commented May 5, 2015

rjcorwin commented May 8, 2015

rjcorwin commented May 18, 2015

rjcorwin commented May 25, 2015