tom-jh
> Can you improve the following text for clarity: "When deploying into the enterprise, there is a lot of flexibility when it comes to deciding how you structure the deployment, whether you want to run supporting services on premise, and which ones (if any) you choose to deploy. The decisions depend on how you plan to use our software and your security requirements. We’ll be happy to discuss these with you at [email]."
Result:
> "When deploying our software into your enterprise, you have the flexibility to decide on the structure of the deployment, including running supporting services on premise and selecting which ones (if any) to deploy. Your decisions should be based on your intended use of our software and your security requirements. If you need help with these decisions, please feel free to contact us at [email]"
It did indeed improve clarity and readability without screwing anything up. I just want to run this thing on our whole website/repo now, and I wonder how.
I wish it was the norm.
We're funded from customer revenue. Privacy focused. No VCs, so no moral flexibility needed on our end to meed VC expectations. We don't do any dark patterns. All remote.
There's GitLab, Wikimedia, Cockroach Labs, etc.. there are opportunities out there if you make it a real priority to work at such place.
1) identified str.replace('[ABC]+', '') correctly as a bug (looks like a regex but is string literal)
2) identified various unnecessary code that TypeScript overlooked
3) identified double-unescaping of html (this one would have probably gone unnoticed for years)
And a bunch of other stuff. No actual vulnerability in our case, but still very useful. I'm enabling their checks on every future PR.
This was TypeScript but they support the rest of our stack too (Python, Java). I wonder if this includes Kotlin - will try.
Sure, Java interop will make some code parts look a lot more like Java then like Kotlin, but I can't personally imagine that a team would decide to switch back to Java-only after using Kotlin for a while. Interested to be proven wrong if someone has seen that happen.
We just hired a Kotlin person (really a Java guy who refreshed his Kotlin over the weekend) for this, and we may be hiring more.
I suspect more companies will start looking at Kotlin in the next 2-3 years, especially for green field projects.
* Puppeteer (browser automation) bugs or improper use. Certain sequence of events could deadlock it, causing timeouts relatively rarely. The fix was sometimes upgrading puppeteer, sometimes debugging and working around the issue.
* Vendor API, particularly their oauth screen. When they smell automation, they will want to block the requests on security grounds. We have routed all requests through one IP address and reuse browser cookies to minimize this.
* Vendor API again, this time hitting limits on rare situations. We could have less parallel tests, but then you waste more time waiting.
Eventually, we will have to mock up this (fairly complex) API to progress. It's got to a point where I don't feel like adding more tests because they may cause further flakiness - not good.
Today 3+ years later it's a three person team. Maybe in another year I can have reasonable work life balance again. Maybe.
FlowCrypt does PGP email encryption; easier than anything you've tried.
let you = new TeamMember();
if (
you.know(TYPESCRIPT | SWIFT) &&
you.write(READABLE_CODE) &&
you.hate('9-5') &&
you.areFrom(EARTH)
) {
await you.email('[email protected]');
}RFC4880 may be ugly. Yet great design can still turn it into a good user experience.
I don't think anyone considers TCP/IP pretty. Who cares? When I open my browser, I see none of it.
For some of my users, using Gmail itself is already challenging.
Yet they are sending around PGP encrypted messages, attachments, etc.
Even my mom is using this. For encryption software, moms count double.