101–110 of 140 posts
I used Repl.it for learning Scheme around 2014. Sadly my company blocked the site thereafter. I'd love to try it again for teaching machine learning.
Why did your company block Repl.it? That's strange.
Hey HN, author and Repl.it cofounder here. It's been a long journey to get to what we're calling 1.0 and HN have been there on every step of the way. We started working on what became Repl.it back in school where we were tired of setting up the development environment on every machine we wanted to code on. It was at a time where everything was moving to the cloud and we thought that, naturally, coding would follow su…
Hey HN, author and Repl.it cofounder here. It's been a long journey to get to what we're calling 1.0 and HN have been there on every step of the way. We started working on what became Repl.it back in school where we were tired of setting up the development environment on every machine we wanted to code on. It was at a time where everything was moving to the cloud and we thought that, naturally, coding would follow su…
repl.it looks awesome. It'd be interesting to hear more about how you're doing provisioning and orchestration. Are you running a Kubernetes or DC/OS cluster by chance? Are you spinning down idle instances after some time? What actually happens behind the scenes to make a deploy go live? etc And then some more general questions - Can I hook a CI into the deploy loop? (Maybe that doesn't quite make sense given the mode…
A bit of context: for every language/environment we have a Dockerfile (naturally) and a JSON configuration that describe how it runs, how it install packages, how it runs unit tests, how it formats code, etc. When we build the container we insert a program that we call pid1, it's the container's interface to the rest of the world.
The container manager creates pools of these containers with some rudimentary predictive logic to make sure we have enough containers to deliver on our promise of "loads in 2 seconds". When we take a container out of the pool, if we're reviving a container, we mount a GCS-backed fuse filesystem with the user code (it needs to be backed by GCS to handle persistence, say you're writing to a log file, it should be there next time you load your project). We then send the relevant setup command to pid1 (either init, or wakeup) which sets up the repl to start the user app, the repl, or what have you.
> What actually happens behind the scenes to make a deploy go live
We poll the container for published ports and the moment we see an open port we add a record to an etcd which stores the routing state. We then send a command to the client that we published a port, which will react by opening an iframe. Then the iframe or any request to the published url will hit our outer reverse proxy which will query etcd to find the container and if the container is alive we will send the traffic to the relevant container manager which has another reverse proxy which sends the traffic to the container.
If the container however is dead (from idling or because of an error) we revive via picking a container out of one the pools and going through the initialization phase described above.
Finally, we also host our own docker image registery so that we can push new images, whether new languages, new versions or what have you.
There is a lot more to talk about here so I or someone on the team will write a post soon.
Earlier quoted context omitted.
Not yet, hoping for a big push oss push next quarter. You want to use it for your ci/cd platform?
OK, thanks for letting us know. We want to use it for our PaaS functionality, but the PaaS will also be used by our Web IDE so it is competitive.
Github seems like they're gearing up to offer a similar service [0]. Cloud9, and notably Glitch [1] offer similar and well executed services. [0] https://github.com/atom/xray#web-compatibility [1] http://glitch.com/
Just for the sake of listing, what "alternatives" are available today ? I can think of 1. Codepen (pure HTML+CSS+JS+frameworks) 2. jsfiddle.net/ (pure HTML+CSS+JS+frameworks) 3. Cloud 9 (full ide?) 4. https://anvil.works/ (pure Python) 5. CaptainDuckDuck ? 6. Repl.It 7. https://glitch.com/ 8. Runkit.io (pure node.js) Other ?
Hey HN, author and Repl.it cofounder here. It's been a long journey to get to what we're calling 1.0 and HN have been there on every step of the way. We started working on what became Repl.it back in school where we were tired of setting up the development environment on every machine we wanted to code on. It was at a time where everything was moving to the cloud and we thought that, naturally, coding would follow su…
I noticed two small issues. First, if you enable gzip on static assets, it will help images load faster. Second, Mason's picture is 2MB, bigger than everything else combined!
Earlier quoted context omitted.
OK, thanks for letting us know. We want to use it for our PaaS functionality, but the PaaS will also be used by our Web IDE so it is competitive.
Cool, I didn't know that Gitlab was going that direction. Really awesome how much surface area you're able to cover.
Hey HN, author and Repl.it cofounder here. It's been a long journey to get to what we're calling 1.0 and HN have been there on every step of the way. We started working on what became Repl.it back in school where we were tired of setting up the development environment on every machine we wanted to code on. It was at a time where everything was moving to the cloud and we thought that, naturally, coding would follow su…
Love the clean, minimal look of your website. Definitely going to keep the Raleway font in mind for future projects. I noticed two small issues. First, if you enable gzip on static assets, it will help images load faster. Second, Mason's picture is 2MB, bigger than everything else combined!
Hey HN, author and Repl.it cofounder here. It's been a long journey to get to what we're calling 1.0 and HN have been there on every step of the way. We started working on what became Repl.it back in school where we were tired of setting up the development environment on every machine we wanted to code on. It was at a time where everything was moving to the cloud and we thought that, naturally, coding would follow su…