shankun

(From GitHub product team)

Thanks, @ianwalter. We plan on having a public feedback repo soon - but in the meantime, if you want to submit ideas, please check out https://support.github.com/contact/feedback.

(From GitHub product team)

Thank you! We couldn't have said it better ourselves. Let us know if you have any other feedback on what we can provide you to plan better. And thanks for your use of GitHub!

Thanks for the feedback on this. We are rebuilding Explore and improving the feeds on it soon, and would love to chat with you if you’re interested. Drop me a line (shankuniyogi at github.com).

I will do a follow-up post on this, once I've learned more. Please stay tuned.

Yes. We will. Please stay tuned.

That is a very reasonable ask. I'll be doing a post-mortem, and talking to all the individuals involved - and will do a followup post on it on the same blog. Please stay tuned. And, again, our sincere apologies.

Hi all, this is Shanku Niyogi. I run the Product team at GitHub. I sincerely apologize for this post. We screwed up. This post was made in error, and we are retracting it. We are always looking to improve our programs for developers, and are working on improvements. But this is not the way to make changes. And it is NOT a goal to end our program. Sorry for the confusion.

Thanks. Yes, this is completely additive to the existing SDK.

Thanks for the feedback. We are actively working on Python 3 support. Stay tuned!

With the interactive CLI, we set out with a similar mission as other cloud CLIs - our first priority was helping users use the GCP CLIs including gcloud and gsutil. With our Interactive CLI, we’ve tried to build something that doesn’t just help new users discover what they can do, but also helps make more advanced users productive, for scenarios such as piping between commands, and shell redirection for read-edit-write workflows. The Interactive CLI provides a full shell environment, and isn’t restricted exclusively to the use of GCP tools.

Interactive CLIs like are a little different than a "cloud shell", which provides a fully cloud-hosted CLI environment. If you want a fully curated cloud-hosted option, check out https://cloud.google.com/shell/. Note that the Cloud Shell includes the Cloud SDK.

Hi all, the Google Cloud SDK team here. The Interactive CLI feature is currently in Alpha, but part of our overall Cloud SDK. The SDK is very much in GA, but we continue to look for your feedback on what we can do to make the SDK experience better and easier to use. If you’ve got feedback, we have a built-in mechanism in the SDK. Just enter ‘gcloud feedback’, and let us know.

When I read "counterfactual regret minimization", I thought this would be about Kellyanne Conway.

This is the new CNN. On the positive side, at least they didn't use "has a cow".

With or without management overhead?

Funny, when I saw this I immediately thought of UpdatePanel (I used to be on the ASP.NET team back then).

The motivation of UpdatePanel was not to provide the best design pattern for AJAX, but provide the fastest path to incremental page updates for ASP.NET Web Forms developers (with minimal code changes) - with all its limitations.

It makes a lot less sense to have a pattern like this in a modern SPA.

No. The old way to change it was in product.json - the product configuration, which got rewritten on every update. The new way to do it is in user settings, which don't get modified.

We're working on it. :)

It is turned on, but you can turn off either crash reporting, or usage telemetry reporting, or both. Please see https://code.visualstudio.com/docs/supporting/faq#_how-to-di.... Scroll down to see more on usage telemetry reporting.

@bbcbasic: there is indeed a difference between our OSS project and Visual Studio Code, which is essentially our distro. For a detailed explanation, please see https://github.com/Microsoft/vscode/issues/60#issuecomment-1....

In addition to the free extension for VS Code (which is free and open source, and available on Mac, Linux, and Windows), we have a free and open source service called CodePush (https://microsoft.github.io/code-push/) for instantly pushing React Native apps to devices.

Electron was indeed originally called Atom Shell, and part of Atom. But it's a general purpose shell for cross-platform apps - it basically provides a native application shell hosting Chromium. And lots of apps - including many that aren't developer tools - are built on it. While VS Code uses Electron, and we contribute to it, we've made a lot of design choices differently from Atom in building the editor and rest of the product.

It might be strange, but many of the engineers on the VS Code team do their development work on a Mac or Linux PC.

Visual Studio Code has a very modular architecture. The tool itself is written in Node.JS and web technologies, on top of Electron, and most extensions have a Javascript component. But most of the language and debugging functionality is built as out-of-process components, which means that they can be built in any technology. For example, our Typescript and Node tools are built with Node; our .NET tools are built in .NET and native code; and most of the functionality of our Go extension is built (by the Go community) in Go.

PTVS is written in a combination of .NET and Python - but with CoreCLR available across all platforms, a lot of that code can be reused. The way they integrate into the tools may be different, but they can share a lot of common code.

Thanks. VIM mode is high on our roadmap.

We do actually have Java syntax highlighting today, though we don't have statement completion and other richer features for it yet.

Thanks. It's definitely high-up on our roadmap.

Thanks Micah, we just added it to the roadmap at https://github.com/Microsoft/vscode/wiki/Roadmap.

VS Code's debugger has an open extension model that allows adding debuggers for other languages. We have Node, Go, and Chrome debugging today, and are planning on adding others.

The Go extension is also available as an open source project, at https://github.com/Microsoft/vscode-go. We've integrated a number of tools built by the Go community, including the Delve debugger, and we are contributing to these projects. We plan on adding other languages as well, including Python - but if you're interested in building extensions for other languages, we'd like to hear from you.

I am not, but I work with them closely. If you'd like to talk to the team involved, send me (shankun_at_microsoft_com) your email and I'll connect you up!

By the way, if you are looking for a production-quality Windows port of Redis, there is a fork available at https://github.com/MSOpenTech/redis. We (Microsoft) provide it in production as Azure's cache service today, and are committed to continuing to work on it.