18 ms·

Hi, Dan from stacktile here, I might be misunderstanding your feedback, but I think you're asking why we enable the user to edit markdown in our "try it now" d

Hi, Dan from stacktile here, I might be misunderstanding your feedback, but I think you're asking why we enable the user to edit markdown in our "try it now" demo -- and thus "interrupt the pitch". Our rationale with our live demo is to show what the content creation process looks like for our prospective customer. The visitors to a completed workflow won't have the ability to edit the markdown. again -- I'm sorry about the limited number of users we can support at the moment (and thus the redirect to our signup page).

hmmdiggy 10y ago
I think what OP was getting at was is if you're processing each example on the fly, why aren't the unedited default examples cached so if a user just hits "Run" they can see it working, regardless of whether it's their own content or not.
- danfromberlin 10y ago
  I think the explanation that might be missing here is that every user that hits "Run" gets his or her own linux container in which they will be working. The process of provisioning a new container (especially under high load that we're seeing today) is what takes a few moments. We however do a fair amount of pre-allocation and other tricks to speed this process up.
  - spdustin 10y ago
    I figure that's what you're doing, but man, why do you want to re-run a container when the result is already known?
    - iamjason89 10y ago
      Yeah, you should not process your four examples over and over with that cost
    - danfromberlin 10y ago
      Since the purpose of our product is to give each user his or her own execution environment to freely explore the software that stacktile is helping to demonstrate, we need to give that user access to his or her own container. Perhaps the confusion is coming from the fact that a stacktile workflow is more than "pre-known" static content -- it is markdown coupled to a an interactive, running shell process in which code can be executed. I hope that helps clarify
      - Vendan 10y ago
        The big confusion is that nothing even says what this is truly about before you say "here, try it out". I can understand that having to spin up a linux container per user means there are large resource costs, but I don't understand why you need a linux container to make an interactive tutorial. Further reading on the page clarifies that you are giving terminal access to the linux container and such, but the initial "above the fold" content makes no mention of that, and nor does the "We can't right now, give me your email and I'll tell you when page". Knowing what's involved, I can now understand it, but from a fresh slate, it (to be blunt) looks like you either don't know what caching is, or your system is shit. You might consider an explanation of all that stacktile does on that signup page, so people can see "oh, it's giving me shell on a fresh container, of course that needs lots of resources and such".
        danfromberlin 10y ago
        Hi, point taken: we can explain on the signup page in more detail why we can't accommodate every user. Thanks for the feedback.
        neiled 10y ago
        I think the main point you're not taking yet Dan is that you SHOULD be able to accommodate every user in your sales pipeline demo. Even if you fake it with pre-baked results or something in the meantime, Pick a sample->click next->load static html. If they want to try out their own markdown, then worry about spinning up a container.
spdustin 10y ago
Disallowing editing is only one solution I suggested. The other is: determining that they haven't actually changed the sample text from one of the pre-canned selections, and thus returning the result from a static copy of a previously-performed transformation. Edit: in other words, if a user changes the text from one of the pre-filled selections (MD5 hash of the text would be sufficient to determine this, or even simpler, note whether a keyup event was raised by the textbox), put them in the queue you're using now. If there was no keyup event, then read which selection was made from the drop down and return the already-transformed-in-advance result. Making a potential "ready to hear your pitch" customer wait in line is unnecessary. There can be an "express lane" without compromising the "scenic route".

hmmdiggy 10y ago

I think what OP was getting at was is if you're processing each example on the fly, why aren't the unedited default examples cached so if a user just hits "Run" they can see it working, regardless of whether it's their own content or not.

danfromberlin 10y ago
I think the explanation that might be missing here is that every user that hits "Run" gets his or her own linux container in which they will be working. The process of provisioning a new container (especially under high load that we're seeing today) is what takes a few moments. We however do a fair amount of pre-allocation and other tricks to speed this process up.
- spdustin 10y ago
  I figure that's what you're doing, but man, why do you want to re-run a container when the result is already known?
  - iamjason89 10y ago
    Yeah, you should not process your four examples over and over with that cost
  - danfromberlin 10y ago
    Since the purpose of our product is to give each user his or her own execution environment to freely explore the software that stacktile is helping to demonstrate, we need to give that user access to his or her own container. Perhaps the confusion is coming from the fact that a stacktile workflow is more than "pre-known" static content -- it is markdown coupled to a an interactive, running shell process in which code can be executed. I hope that helps clarify
    - Vendan 10y ago
      The big confusion is that nothing even says what this is truly about before you say "here, try it out". I can understand that having to spin up a linux container per user means there are large resource costs, but I don't understand why you need a linux container to make an interactive tutorial. Further reading on the page clarifies that you are giving terminal access to the linux container and such, but the initial "above the fold" content makes no mention of that, and nor does the "We can't right now, give me your email and I'll tell you when page". Knowing what's involved, I can now understand it, but from a fresh slate, it (to be blunt) looks like you either don't know what caching is, or your system is shit. You might consider an explanation of all that stacktile does on that signup page, so people can see "oh, it's giving me shell on a fresh container, of course that needs lots of resources and such".
      - danfromberlin 10y ago
        Hi, point taken: we can explain on the signup page in more detail why we can't accommodate every user. Thanks for the feedback.
        neiled 10y ago
        I think the main point you're not taking yet Dan is that you SHOULD be able to accommodate every user in your sales pipeline demo. Even if you fake it with pre-baked results or something in the meantime, Pick a sample->click next->load static html. If they want to try out their own markdown, then worry about spinning up a container.

spdustin 10y ago

Disallowing editing is only one solution I suggested. The other is: determining that they haven't actually changed the sample text from one of the pre-canned selections, and thus returning the result from a static copy of a previously-performed transformation. Edit: in other words, if a user changes the text from one of the pre-filled selections (MD5 hash of the text would be sufficient to determine this, or even simpler, note whether a keyup event was raised by the textbox), put them in the queue you're using now. If there was no keyup event, then read which selection was made from the drop down and return the already-transformed-in-advance result. Making a potential "ready to hear your pitch" customer wait in line is unnecessary. There can be an "express lane" without compromising the "scenic route".