If his machine was not configured to secure erase files (unlikely; not the default) when emptying trash, they can be "trivially" recovered by firms like this (HFS+ makes it harder than it should be)
2,815 karma · joined August 26, 2011
Help us optimize trucking and logistics - a $800B industry that still runs on fax machines and phone calls.
We would love more engineers, up and down the stack, and anywhere on the generalist <-> specialist spectrum. We use pretty cutting-edge tech (React, React Native, TypeScript, Node, GraphQL), but we're more interested in engineering chops than any particular tech skills.
I've been here since the beginning (over two years now). The team has grown quickly, but we still have a tight-knit and incredibly smart group of engineers. We have an endless supply of interesting problems including machine learning, service architecture, mobile/desktop/web UX, complicated business modeling, and much more.
Some of our backers include Y Combinator (Continuity Fund), Jeff Bezos, Bill Gates, and Greylock Partners. You can read more about us:
http://www.mosaicventures.com/mosaicblog/2017/7/25/our-inves... https://www.theverge.com/2017/7/26/16027650/convoy-trucking-...
If you're interested in hearing more, reach out and grab coffee with me or one of our other developers. Help us grow an amazing tech team from a very early point in our company's history!
* A network request is kicked off if the cache doesn't contain the data the component declares a dependency on.
* other components that depend on any part of the requested subgraph will update when the response comes in
* query observers (which HoC'd components really are) will similarly fire, potentially triggering other side effects in your application
Help us optimize trucking and logistics - a $800B industry that still runs on fax machines and phone calls.
We would love more engineers, up and down the stack, and anywhere on the generalist <-> specialist spectrum. We use pretty cutting-edge tech (React, React Native, TypeScript, Node, GraphQL), but we're more interested in engineering chops than any particular tech skills.
I've been here since the beginning (over two years now). The team has grown quickly, but we still have a tight-knit and incredibly smart group of engineers. We have an endless supply of interesting problems including machine learning, service architecture, mobile/desktop/web UX, complicated business modeling, and much more.
Some of our backers include Y Combinator (Continuity Fund), the founders of Amazon and Microsoft, and Greylock Partners. You can read more about us: http://www.mosaicventures.com/mosaicblog/2017/7/25/our-inves... https://www.theverge.com/2017/7/26/16027650/convoy-trucking-...
If you're interested in hearing more, reach out and grab coffee with me or one of our other developers. Help us grow an amazing tech team from a very early point in our company's history!
Measuring glyphs, dealing with reflow, kerning, whitespace breaking rules, etc is no fun
https://www.quora.com/What-kind-of-margins-can-non-asset-bas...
At that point, your laptop is basically your 2nd factor - which this software is pretty similar to.
* The caching clients (Relay, Apollo) out there are dog slow for medium to large response payloads. (they're working on it)
* It can add more complexity than you need if used for service<->service chatter (pure RPC may be preferable)
* It's still pretty damn awesome as a data layer, especially to public clients
They're often solving problems that affect large numbers of developers (initially, inside their company). And, because of the scale of a company like Facebook, they can afford to work full time on these projects.
They then open source them because there's no strategic value to keeping them private, and significant upside to building a community around them (and not undermining that).
I'd argue that some of the best open source projects come from large companies - due to the sheer number of developer hours they can throw at them. Small dev shops can't afford it, there are very few OSS foundations, and there just aren't that many people (relatively) that can devote enough time on the side to compete.
(this quote is from the article, in reference to Google aggressively advertising Chrome)
I'm pretty sure that all the ads mentioned in the article have been around for far longer than 12 months. What else might have happened 12 months ago to influence the decline?
Compilers can only optimize so much. GWT/Closure do a very good job of it, too. https://www.peterbe.com/plog/advanced-closure-compiler-vs-ug...
Much of the "slow trash" is already optimized to death - it just dies under the weight of insane complexity (e.g. features), browser support, and overly-generic (IMO) support libraries
> which requires a massive slow polyfill in all but latest Chrome and results in a shit experience for all others (if i recall a related thread correctly).
Tangential: I'm not sure which version of Polymer they're using - but 1.0+ removes the need for most of the polyfilling.
Indeed; Arv is a TC39 member.
> Gmail in particular is still written using GWT, AFAIK, hence the strange HTML, etc. Its current frontend is probably an unsexy maintenance project, with little or no new development; most new features and dev efforts are likely in the "inbox" project, etc.
IIRC, Inbox is also GWT, so that they could cross-compile for the native platforms (https://gmail.googleblog.com/2014/11/going-under-hood-of-inb...)
For a very long time, GWT (Java compiled to JS) was the preferred approach. Then development moved to the Closure compiler (JS following very Java-like patterns), and only very recently is ES6 style code taking off.
Much of the code you see still carries the legacy of GWT/Closure (and there is so much there that porting would be an insane task). It's a slow process. But, for example, YouTube is switching over to Polymer (https://youtube.googleblog.com/2017/05/a-sneak-peek-at-youtu...).
> Google sure spends a lot of resources on this lesser language for how few engineers want to work with it.
Google is a massive company, with many different (often conflicting) initiatives. Chrome spends a lot of effort on JavaScript; but Chrome engineers are (for the most part) not the ones that are writing Google's frontend code.
That being said, there is also a toxic stance from many Google engineers (and management) that JS is a "lesser" language, and that feeling often translates to the devs that work in it.
From what I hear, they are now used pretty extensively internally (and that may have been an end goal)
TL;DR - evergreen browsers, mobile browsers (except for images), IE 11+, and IE 8+ partially supports it