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".

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.

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.

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?

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

>"Perhaps the confusion is coming from the fact that a stacktile workflow is more than "pre-known" static content"

We know this. People are saying that you need to have some sort of "pitch" that can't be overloaded by too-many users.

So, either you provision a lot more containers to handle spikes like the ones HN gives.

Or, you scale automatically to handle traffic-spikes. Or, you do some sort of caching. Or, you have an explainer video/tutorial, something.

Just because your product is "interactive", does not mean you have to have an interactive sales-pitch. Because right now, you're losing the valuable attention of HN-eyeballs.

This is absolutely correct. OP unfortunately missed this opportunity. Let's hope other readers don't make this mistake in the future.

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".

Hi, point taken: we can explain on the signup page in more detail why we can't accommodate every user.

Thanks for the feedback.

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.

From what I've seen, part of the "result" is a connection to a linux terminal. Not exactly easy to pre-bake that.

Yeah, you should not process your four examples over and over with that cost