Seems to be closed source?

Founder of Streak (author of the InboxSDK) here. Yes we made the difficult choice to close source this. One of the big value props of the SDK is that it automatically maintains compatibility with Gmail and all other extensions using the SDK.

The way we ensure this is by remote loading most of the SDK from our servers to ensure users are on the latest version of the SDK.

One thing we wanted to prevent was developers including the stock SDK directly in the extension or even forking their own version and including it in their extension because then we can't guarantee it will always be compatible with other extensions or Gmail. We'd have to rely on developers constantly upgrading their dependency on us and submitting an extension update to the chrome store.

There are ways where we can still host the SDK but open source it so people can contribute/inspect the code - we just haven't gotten there yet but it is part of our plans.

Folks should know that this approach will not accommodate upcoming changes to Chrome extensions, which will disallow all remotely-hosted code: https://groups.google.com/a/chromium.org/d/msg/chromium-exte.... More up-to-date guide here https://developer.chrome.com/extensions/migrating_to_manifes..., with a timeline of 2020. I understand why

> one thing we wanted to prevent was developers including the stock SDK directly in the extension

(and I feel for Streak, having worked on a Gmail extension (Mixmax) until recently), but this seems to be exactly what manifest v3 will require. Curious if you have another strategy, @alooPotato.

Cross posting from another comment:

It is true that they are locking down the remote loading. InboxSDK currently has an exemption to this rule (as do some other popular and similar libraries). However, over the long term (think years) we will move away from remote loading. We're currently working with Google on a solution that should retain some of the benefits of remote loading, while allowing Google to statically analyze the SDK for security. It hasn't been finalized but the SDK will be allowed to continue remote loading until that is in place. Remember, we have every incentive to make this work for everyone including ourselves.

That is very interesting! What benefits do you see from using UiPath over testing frameworks?

In graphical interface automation, compatibility is the limiting factor.

Compatibility has an extremely long tail.

The only companies incentivized to implement support for that long tail are those who derive revenue from doing so.

Testing frameworks, by and large, don't derive revenue from that. Process automation frameworks do.

Ergo, if you're sick of "Oh, well that isn't supported", use the latter, even if for the purposes of the former.

Any recommendations of commercial products that worked for you?

We’re using testleft from smartbear, but I can’t really say how it compares to other commercial products.

fyi, the GitHub PR extension[1] for VS Code has review comments in the editor.

[1] https://marketplace.visualstudio.com/itemdetails?itemName=Gi...

Live Share has been super fun to use, and the one underrated capability is the ability to build extensions on top of it. I built a text chat extension[1] on Live Share, and I'm keen to see more extensions that bring shared experiences for developers while writing/reviewing code.

[1] https://marketplace.visualstudio.com/items?itemName=karigari...

Looks great! Is this a validation for GitHub Actions? Trying to understand whether Actions have been getting traction

Gitlab has had fully integrated CI for a long time, and there's a clear benefit to integrating it rather than just providing hooks.

Bitbucket has had CI too, with bitbucket pipelines. I think the innovation here is the UI not the idea of CI.

GitHub Actions is just GitHub implementing features others have had for quite a while. So I guess, GitHub Actions is a validation of their features.

I think GitHub Actions is picking up because of how big GitHub is.

Threw myself at problems, incorrectly perceived them to be the most important goal of my life, failed to achieve results. Did this 3 times on repeat.

I guess I did not really know what "throwing myself" at something meant until after I realized I was burnt out. There's a sense of dehumanization in the process, where the goal/solution becomes bigger than you, becomes more important than anything else. The thrill and excitement of doing something challenging drives you for a while, and it seems logical to not spend time in your "personal life". You lose track of messages in your threads with friends, and once in a while respond with a "sorry I was busy" response that everyone around you has gotten used to from you. To answer more directly, one of the red flags I missed was how I let the problems take control of myself, instead of the other way around.

Got out of it by leaving the company I was working at and worked independently for about a year. Found my own pace, got back in close connection with my friends and family, focused on my relationship.

Looks neat! What happens if you make edits to the files?

I hacked something during the night that supports changes. It creates new commit inside repository for each change.

https://github.com/mochja/giftp

It's an FTP server, and I don't believe it supports PUT, so there is no editing the files.

It should return an error message indicating that the files are read-only, obviously.. :)

Yeah, in this server's case it would respond "502 Unimplemented"

* Wild Wild Country