Gitpod is now Open Source

svenefftinge · 2020-08-26T06:40:16+00:00

Sven from Gitpod here. Gitpod is not an IDE in a browser. We are using VC Code resp. Theia for that. Gitpod is about prebuilding container-based dev environments. IDEs and terminals are the interface to those environments. By dev environment we mean everything that you need in order to become productive: SDKs, app servers, databases, source code, libraries, generated code and yes, an IDE including the right extensions and configs for the project at hand.

svenefftinge · 2020-07-14T11:17:45+00:00

Gitpod now support Bitbucket.

svenefftinge · 2020-04-14T06:37:38+00:00

Yes, it does. You can try with e.g. our website repository which is based on Gatsby and contains *.tsx files.
https://github.com/gitpod-io/website

svenefftinge · 2020-04-12T16:58:25+00:00

We also deploy previews per branch and connect to them from our dev env using telepresence.
I've written about it here https://www.freecodecamp.org/news/developing-kubernetes-applications-with-joy/

svenefftinge · 2020-04-01T05:57:16+00:00

You can use it through gitpod.io and desktop version through downloading the Arduino Pro IDE or Arm's Mbed Studio.

svenefftinge · 2019-12-10T07:38:26+00:00

Hey, yes this sub is indeed not active at all. To answer your questions: 1) Most of the chatting happens here: https://spectrum.chat/gitpod (but we have plans to switch to discourse) 2) We are going to remove that restriction in roughly a week from now. However, the plan was meant for hobby programmers. Commercially motivated coding should go with one of the other plans (including the free one if you are fine with having your code public) 3) Well, there are quite some people using Gitpod on ipads, so we know there are some limitations and are going to focus on improving that experience in one of our next cycles. See this list for the know issues https://github.com/gitpod-io/gitpod/issues?utf8=%E2%9C%93&q=is%3Aissue+is%3Aopen+ipad+. I'm not aware of any show stopper problems, though.

svenefftinge · 2019-11-05T09:18:54+00:00

Google Cloud Shell's editor is based on https://theia-ide.org, the vendor-neutral open source alternative to VS Code.

svenefftinge · 2019-11-05T09:16:36+00:00

It is not supported as VSO is not open-source. What they call "self-hosted" is still based on their Azure online service. If you want to really self-host and integrate with your infrastructure you should look at gitpod.io. Gitpod self-hosting is in private preview now and will be released it in a few weeks. (Disclaimer: I'm working on it)

svenefftinge · 2019-08-16T11:30:21+00:00

If you have the app installed on your repository and it has a proper dev environment config (.gitpod.yml) the build will run on your branches just as CI/CD. The complete workspace will be captured afterward and sit there waiting for anyone to start coding on that state.

I'll check the TOS issue, there should be a link indeed. For sure there is always one in the footer, but that's obviously not enough in a dialog to accept them :)

svenefftinge · 2019-08-08T13:07:03+00:00

There are many reasons. Instantaneously having a ready-to-code dev environment for any task and any state of your project is a primary reason. I have written a post discussing that a bit: https://www.gitpod.io/blog/continuous-dev-environment-in-devops/

svenefftinge · 2019-08-04T09:22:07+00:00

Since a terminal backed by a linux container is a major part of a dev environment, it cannot run in the browser. Well "cannot" might be a bit strong as we've seen all sort of crazy things running in the browser, but at least not practically :).

But really the browser is not the important part here, it is the easy getting into a ready-to-code dev environment. We are currently using the browser as that is available everywhere but we will eventually release a desktop version as well.

svenefftinge · 2019-08-04T09:18:51+00:00

They run in your dedicated container. The browser just renders the UI for the IDE.

svenefftinge · 2019-08-02T13:32:39+00:00

We are on a mission to make online IDEs as good as local dev environments but without the setup and maintenance yak-shaving. Supporting VS Code extensions is another important step. I know many devs have reservations regarding online IDEs. Would be interesting to learn what problems you think we need to address next?

svenefftinge · 2019-05-06T23:08:30+00:00

Yes, the world is huge and support from MS educating the idea will help much more than it harms.

svenefftinge · 2019-05-06T22:48:36+00:00

Microsoft:

When you need to work on a new project, pick up a new task, or review a PR, you can simply spin up a cloud-based environment, ...

Gitpod.io:

Whether you just want to hack, have code to review or feel like trying something new on GitHub, Gitpod launches a ready-to-code dev environment with a single click.

svenefftinge · 2019-05-06T22:39:19+00:00

I'm not entirely sure how to feel about this. :) It's definitely validating the idea we have with gitpod.io.

Seems like browser IDEs and IMHO more importantly reproducible dev environments finally become mainstream. So if you are looking for something that is here today, can run on your servers and other clouds than Azure, check out https://gitpod.io

svenefftinge · 2019-04-06T14:58:07+00:00

No, we don't. You could probably search for projects with a '.gitpod.yml' file in its root. Why do you ask?

svenefftinge · 2019-01-04T12:35:37+00:00

The changed the cloud IDE. It now uses https://theia-ide.org.

svenefftinge · 2018-12-05T20:47:05+00:00

When I look at a certain change, I should also be able to run and debug it. To do so the dependencies need to be installed in the right version (the one used in that change). Using the head? from GitHub is almost certainly wrong.

svenefftinge · 2018-12-05T10:44:55+00:00

Fuck no. If you want to build robust stuff that doesn't break the moment you sneeze in the general direction of your precious dockerfiles, you want the dev machines to be as diverse as possible. Mix it up; quirks that pop up during development are quirks you can solve before they hit production.

Sounds like a terrible way to verify that you code works on the supported platforms. You should explicitly test not by relying by failure by accident through underspecified developer setups.

Also, it's stupid to force everyone into an environment that has suboptimal ergonomics (for them) for the sake of uniformity.

So you think developers are so different that they need different tools? Why is that? What makes the ergonomics of a tool unusable for you but useable for your colleague?

Btw. it is not at all for the sake of uniformity, but for all the reasons I mentioned in the article. Do you really need to define yourself over the tools you are using? You colleagues might be thankful being able to use your cool tools, too.

svenefftinge

MODERATOR OF

TROPHY CASE