This is a great discussion !

I agree with Rodric when he said that there is a gap in tooling in the
serverless/FaaS world
This gap provides attractions to come with many tools and ideas on how to
satisfy many needs, education, experimentation, developing, composition,
re-use, debugging,  testing, deploying, testing, and monitoring.

I can see many tools being created even if they target the same need and
even if there is overlap, that's OK, it takes time for adoption and
convention to have a large pool of people agreeing on what's the best tool
for the job, so some tools will continue forward and other tools would just
stay as good experiments or merge into other tools.

For OWShell,  if I were to name it I would name it something along the
lines as OWWorksheet or OWPlayground or OWReplUI not use the "Shell" and
avoid confusion with the current OW CLI/Shell. Maybe is not confusing, but
it's good to clarify that the WSK CLI is very stable client of the OW REST
API and will NOT be replace, it does it's job for unattended deployments in
CI/CD in our production pipeline, also other users already using it today
and OK with it.

This OWShell UI, It has a feeling like Scala Worksheet [1], Swift
Playgrounds [2] mixed with Repls like Scala Repl and [3] NodeJS Repl

There are lot of useful use cases I could see my self pull from this tool,
primarily as experiment and teaching tool for OpenWhisk.
I can see my self giving a talk at a conference or meetup which I typically
only have 45 minutes to show the concepts and values of OpenWhisk, I can
quickly show demos and iterate fast over different ideas, and answer
questions live with the tool.

Similar use cases are along the line of Swift PlayGrounds allows me to have
some visual results on the code next to it, having both side by side,
clicks in people's head on cause and effect, very powerful when getting
started into a platform/language

The REPL aspect it let's me validate ideas on how I think it should or
would work and how actually works of behaves.
One thing is writing a single function with inputs and outputs, but another
more tricky is when I want to use that function in a sequence, or call it
from a trigger, and do a breakpoint.

I like that the idea of exporting / saving session or commands, this allows
me to share with others, or save and use as a starting point when getting
started for a new application with my current workflow of using a project
directory stored in scm (i.e. git) next to my current CI/CD scripts that
leverages the WSK CLI.
This is similar to some tool I found Scastie [4] allows you to play with
Scala code on the Browser and then allow export/download a project I can
take into my git repo and continue from there.

I have being developing tools for a while, I tend to forget that developers
using this tools, they want to use their time working on their code and not
tuning tools, the tools should allow them to do their work and get out of
their way. If they find a tool that would get the compile/deploy task done
so they can continue working on their code they would be happy with that.

Tools are cool and nice to have, but developer's spent most of their time
in the business logic code working with the language at hand.
I tend to spend more time deleting, and recreating apps with this tools,
because I develop the tools, and show demos using this tools, but for my
own apps, I write "deploy.sh" once and call to be called from
Travis/Jenkins and that's it I don't want to touch it again, only when
adding a new file to the project :-)

-- Carlos

[1] https://github.com/scala-ide/scala-worksheet/wiki/Getting-Started
[2] https://developer.apple.com/swift/playgrounds
[3] https://nodejs.org/api/repl.html
[4] https://scastie.scala-lang.org







On Fri, Aug 4, 2017 at 2:49 PM Nick Mitchell <moose...@gmail.com> wrote:

> the current release (1.1.1) does not yet expose the bashy variant. i'll do
> that for 1.2.0, it's ready to go, i just haven't had a chance to include it
> in the dist bundles.
>
> for 1.1.1, you can use the `run` command from within the Shell. this will
> execute a sequence of Shell commands from a file. prior to 1.1.1, we didn't
> expose the `run` command even in the Shell.
>
> we're getting there, especially with all of the great feedback we're
> getting. keep it coming!!
>
> nick
> @starpit
>
>
> On Fri, Aug 4, 2017 at 2:46 PM, Tyson Norris <tnor...@adobe.com.invalid>
> wrote:
>
> > I didn’t get that it can be invoked from a shell in a REPL style, thanks
> -
> > is this possible with the current downloads?
> >
> > I appreciate the value of the UI (looks great btw!) - its just not clear
> > how to do the 'scripted execution’ parts?
> > Thanks
> > Tyson
> >
> > > On Aug 4, 2017, at 11:22 AM, Nick Mitchell <moose...@gmail.com> wrote:
> > >
> > > thanks tyson!
> > >
> > > the tool can indeed be used in a purely bashy way, if that's helpful.
> so
> > > e.g., the following works, assuming for a second that we call the Shell
> > > `wsker` for the purpose of this email:
> > >
> > > wsker activation get foo
> > > wsker action invoke foo
> > > wsker activation get xxxx
> > >
> > > these look familiar, i think? hehe, what i'm getting at is that the
> > command
> > > set overlaps! and you can issue one-off commands to the Shell directly
> > from
> > > bash, if you'd like; or in a bundle via `wsker script.txt`
> > >
> > > i propose that you will quickly discover the value of having the
> electron
> > > app, including:
> > >
> > > 1) your command history is specific to openwhisk, so you don't have to
> > > arrow up past non-whisk commands
> > > 2) the command set is richer
> > > 3) you get visuals for the common and important data
> > > 4) no more copy-paste of that xxxx part of wsk activation get!
> > > 5) an app to itself, with its own icon and one that can be separately
> > > minimized/maximized, or pinned to desktops
> > >
> > >
> > > nick
> > > @starpit
> > >
> > > On Fri, Aug 4, 2017 at 12:23 PM, Tyson Norris
> <tnor...@adobe.com.invalid
> > >
> > > wrote:
> > >
> > >> Some thoughts on this: I think one thing that would make this less
> > >> confusing is introducing a REPL to the wsk CLI (or a wrapper of it)
> > instead
> > >> of introducing REPL as “a desktop application with a gui”. I like the
> > gui,
> > >> but I also think it may be adding a layer of confusion.
> > >>
> > >> Similarly, it should be carefully considered how commands can be
> > >> consistent between REPL and non-REPL usage, e.g. for related CLI auth
> > >> discussion, it would be great if:
> > >> wsk auth
> > >> Had the same effect as:
> > >> REPL: auth
> > >>
> > >> The difference being that wsk auth would store credentials to disk for
> > use
> > >> at next wsk command run, and REPL: auth would store credentials for
> the
> > >> length of the session only. In addition, the REPL may be able to
> > >> conveniently pop up an auth dialog, where the CLI may have to ask you
> to
> > >> load a url, but the end result would be the same.
> > >>
> > >> From there the notion of “REPL has a special language in addition to
> the
> > >> CLI commands” is something easier (at least for me) to get behind, as
> > long
> > >> as things that are not purely session-based are added to the CLI as
> well
> > >> (like auth flavored commands).
> > >>
> > >> Thanks for starting this tool, I think its useful and look forward to
> > >> watching it progress!
> > >>
> > >> Tyson
> > >>
> > >>
> > >>
> > >>
> > >>> On Aug 4, 2017, at 8:59 AM, Nick Mitchell <moose...@gmail.com>
> wrote:
> > >>>
> > >>> With the shell, one would issue `last`. Or `last foo`. With a REPL,
> we
> > >> have
> > >>> the luxury of a flexible command structure that can be tailored to
> the
> > >> task
> > >>> at hand.
> > >>>
> > >>> And, once you are looking at that activation, you can drill down (eg
> to
> > >>> tree view of the sequence), or reinvoke (we can remember the input),
> or
> > >>> reinvoke with new args, or add this action to a sequence now that you
> > >> know
> > >>> it works (append to myseq).
> > >>>
> > >>> These are all plugins, so new ideas can appear as shell commands in a
> > >>> matter of minutes.
> > >>>
> > >>> On Aug 4, 2017 11:49, "Rodric Rabbah" <rod...@gmail.com> wrote:
> > >>>
> > >>>> This is a very useful discussion - thank you Rob for starting it. We
> > >> both
> > >>>> want and need this kind of feedback!
> > >>>>
> > >>>> One of the observations that you noted wrt to the shell is that it
> has
> > >> "its
> > >>>> own language". Indeed there is a language here, in the same way that
> > the
> > >>>> wsk CLI already offers a language for serverless programming using
> > >>>> OpenWhisk. When the language of the CLI is limiting, what do we do
> as
> > >>>> developers? I posit that we layer new languages on top --- my
> favorite
> > >>>> example is "give me the last activation". At one point I polled for
> > how
> > >>>> many bash aliases the community has come up with for this feature!
> > >> Recently
> > >>>> the wsk CLI added `wsk activation get --last`. That's still too
> > verbose
> > >> and
> > >>>> I continue to use my local alias for this command and I expect
> others
> > >> will
> > >>>> too. More concretely, it's too verbose when I'm developing,
> iterating,
> > >> and
> > >>>> debugging.
> > >>>>
> > >>>> In the same way, I've seen developers share bash scripts for
> > automating
> > >>>> other tasks that the current wsk CLI (or really any client) doesn't
> > yet
> > >>>> support. For example: deleting all assets in a namespace, or a
> > package.
> > >>>> These are features I expect will eventually end up in the wsk CLI.
> But
> > >> the
> > >>>> gate for rapidly experimenting with new aliases, plugins, features
> is
> > >> too
> > >>>> narrow today.
> > >>>>
> > >>>> The "openwhisk shell" is a way of normalizing the programming
> > experience
> > >>>> for serverless - it does subsume the CLI in that the wsk commands
> > should
> > >>>> work inside it, but also extends the capabilities to add more
> > syntactic
> > >>>> convenience and make a workflow more fluid - some of these may not
> be
> > >>>> readily possible or practical in a terminal. One of the benefits
> that
> > >> I've
> > >>>> experienced directly is that it makes the iterative programming
> > >> experience
> > >>>> and development for serverless more agile and fluid.
> > >>>>
> > >>>> To me, this is independent of the question of scripting for
> > deployment,
> > >>>> continuous integration, and delivery and hence the context for my
> "old
> > >>>> school" comment - the shell can export a bash script for you, or
> other
> > >>>> artifacts like a serverless framework manifest, for managing a
> > >> deployment
> > >>>> (as examples).
> > >>>>
> > >>>> -r
> > >>>>
> > >>
> > >>
> >
> >
>

Reply via email to