3 ms·

Thanks for the website feedback. I'll do my best to rethink how I present this there. Booste allows GUI code editors like VS Code and Sublime.

mbreese 6y ago
I guess one issue you’ll run into then is that VS Code supports something very similar. Instead of editing locally and syncing, with VS Code, you can run VS Code “locally”, but it can connect to a remote server over SSH where you edit files directly on the remote server and it gives you terminal access to run your code there too. I’m not saying your idea isn’t viable, but there are multiple players moving in this direction. To me, the main thing you’ll have to convince me of is that this is better than editing code locally, but running the code in a local Docker container. For me, this solves the issue of “it runs on my machine”. From my perspective, your main value add is trying to make executing and testing code on a remote server frictionless (it’s not quite there, but pretty good so far). And that you can edit on a low-resource machine, but effectively “develop” on a more powerful remote system. But these might be a tough sell if you’re targeting the HN crowd (which I’m not sure you are).
- edunteman 6y ago
  Thanks for the tip. I've heard mentions of the VS Code tool, but never had it clearly explained until now. Definitely something to watch out for. The "pulling" aspect seems more elegant than the way Booste stores locally and pushes, so I can definitely take that as inspiration. The docker point is fair too. Docker containers solve the machine problem, and are incredibly helpful teck. There are perks of cloud hosting (visibility by team, potential to monitor prod and have the codebox reflect it, performant hardware) that we can layer on top of docker container tech. Just hypotheses, to be clear. But to me, we're doing to Docker what Google Docs did to MS Word.
sneak 6y ago
Are you aware that you can set DOCKER_HOST to something like `ssh://root@example.com` and then run git/editor/docker locally, and the docker client will invoke `ssh` to connect to the remote host and access the socket/daemon? The builds all happen remotely, on big/fast boxes. Coupled along with something like docker-machine for instantiating those remote instances, what does this setup not offer that yours does?
- edunteman 6y ago
  I'd have to play with that alternative for a bit to give you an educated response. Thanks for pointing me toward it!

mbreese 6y ago

I guess one issue you’ll run into then is that VS Code supports something very similar. Instead of editing locally and syncing, with VS Code, you can run VS Code “locally”, but it can connect to a remote server over SSH where you edit files directly on the remote server and it gives you terminal access to run your code there too. I’m not saying your idea isn’t viable, but there are multiple players moving in this direction. To me, the main thing you’ll have to convince me of is that this is better than editing code locally, but running the code in a local Docker container. For me, this solves the issue of “it runs on my machine”. From my perspective, your main value add is trying to make executing and testing code on a remote server frictionless (it’s not quite there, but pretty good so far). And that you can edit on a low-resource machine, but effectively “develop” on a more powerful remote system. But these might be a tough sell if you’re targeting the HN crowd (which I’m not sure you are).

edunteman 6y ago
Thanks for the tip. I've heard mentions of the VS Code tool, but never had it clearly explained until now. Definitely something to watch out for. The "pulling" aspect seems more elegant than the way Booste stores locally and pushes, so I can definitely take that as inspiration. The docker point is fair too. Docker containers solve the machine problem, and are incredibly helpful teck. There are perks of cloud hosting (visibility by team, potential to monitor prod and have the codebox reflect it, performant hardware) that we can layer on top of docker container tech. Just hypotheses, to be clear. But to me, we're doing to Docker what Google Docs did to MS Word.

sneak 6y ago

Are you aware that you can set DOCKER_HOST to something like `ssh://root@example.com` and then run git/editor/docker locally, and the docker client will invoke `ssh` to connect to the remote host and access the socket/daemon? The builds all happen remotely, on big/fast boxes. Coupled along with something like docker-machine for instantiating those remote instances, what does this setup not offer that yours does?

edunteman 6y ago
I'd have to play with that alternative for a bit to give you an educated response. Thanks for pointing me toward it!