fro0116

I'm surprised nobody has mentioned AngelList yet. Well, that's not quite true. I saw a few mentions of AngelList itself but nothing about what I feel is their killer feature for job searching: their salaries tool https://angel.co/salaries

Job posts there usually come with a salary range, and salary can be a deal-breaker for a lot of people (most people?), so seeing salary ranges up front for specific companies & positions you're interested in can help avoid a lot of wasted time on both sides due to mismatch in expectations around compensation.

The tool is even more helpful when you're in that initial stage of looking for work but not sure where to apply to yet, because you can filter for jobs that match a certain salary range, within certain locations/industries, level of funding, tech choices, etc.

I also personally really like job searching platforms like Hired.com, Underdog.io, Triplebyte, and AngelList's own A-List that allow you to apply once to their platform and then have companies come to you with offers for interviews, many of which of also require the company to disclose salary range up front so you can decide which offers are worth your time to pursue.

I'd personally love to see a ROM that focuses less on customizations and adding their own "flavor" to Android, and just attempts to track AOSP as closely as possible while supporting as many devices as possible, so users whose devices are no longer supported by their manufactures (or who just don't like the customizations the manufacturers have made to the UX) can continue enjoying the latest Android improvements in UX & security.

LineageOS is great, and already supports a wide range of devices, but all the features/changes it has accumulated over bare Android means it necessarily has a much harder time porting to the latest versions of Android, and supporting new devices compared a ROM without those customizations.

If a ROM like that already exists, I'd love to hear about it.

All three of the points raised are just dismissing the root of the problem and offering a "solution" using plain CSS classes that relies on everybody following some bespoke convention to work around the problem rather than addressing it head-on like CSS-in-JS solutions do.

1. and 2. attempt to address the lack of modularity in CSS through convention when you can have guaranteed modularity through auto-generated CSS classes that are content-addressed and thereby globally unique by definition with CSS-in-JS. Not to mention you can use a real module system for sharing styles instead of being limited to sharing variables through some global context, which again opens up the possibility of name clashes.

3. recommends a solution for dynamic styles based on yet another CSS feature that relies on global namespacing, and then a fallback based on string concatenation that can't actually address all dynamic use cases. Then it goes on to dismiss the use case entirely, when in a single page application, all styles are inherently dynamic based on the state of the components that are currently being rendered, which is why there's such a painfully obvious impedance mismatch when implementing anything that's truly dynamic using CSS classes, when you have to resort again to concatenating lists of static classes together rather than mapping state to styles directly like you could with CSS-in-JS.

Of course, I'm not saying those approaches can't work at all, nobody is saying that. You can obviously make them work, and people have used those approaches for ages before CSS-in-JS came along. But using the existence of those approaches to dismiss a different approach that tangibly addresses the inherent flaws of those approaches doesn't feel like a particularly compelling argument.

Also learned about Razzle through that thread:

https://github.com/jaredpalmer/razzle

> Universal JavaScript applications are tough to setup. Either you buy into a framework like Next.js or react-server, fork a boilerplate, or set things up yourself. Aiming to fill this void, Razzle is a tool that abstracts all complex configuration needed for SSR into a single dependency--giving you the awesome developer experience of create-react-app, but then leaving the rest of your app's architectural decisions about frameworks, routing, and data fetching up to you. With this approach, Razzle not only works with React, but also Reason, Elm, Vue, Angular, and most importantly......whatever comes next.

Sounds like a really nice alternative to Next.js and Gatsby. Does anyone have any experience with it?

In my mind the answer is in building decentralized apps/services.

A DDoS on a static site cached on just about any CDN that runs logic exclusively on the client is much harder to pull off successfully because it's so much cheaper (practically free?) to mitigate, and doesn't affect any existing users who would already have the necessary resources cached locally.

For 2, this is the one I'm most looking forward to: https://developers.google.com/web/updates/2018/11/writable-f...

Entire classes of PWAs are essentially impossible to build right now because of the lack of ability to work with files directly, think offline editors, offline music players, etc.

You still can't actually change your billing country in Office 365 without starting over with a new account. Even support can't do it.

https://office365.uservoice.com/forums/273493-office-365-adm...

It's a complete shitshow.

Really? I've used mine for a little over a year as a PC display and the burn-in has come to a point where I'm thinking of just throwing it out because nobody in their right mind would pay money to get it off my hands.

Do you happen to have your brightness set to really low or something? I left mine around the default thinking it'd be safe but that totally didn't work out.

For regular TV usage, it's probably fine, but I would not recommend buying one to use as a PC monitor. I did that about a year ago, and I really regret it.

Burn in patterns are everywhere, and especially visible in red channels, so the overall image has a greenish hue. Things like taskbars, tiling window borders, browser titlebars, game HUDs (HP bars especially since those are often bright red), have all left their permanent mark on the display, and have become super distracting.

I'll probably get another OLED eventually to replace this one (I'd try to sell the current one but kind of doubt anyone would pay decent money for it given the state it's in), but will probably use it exclusively for movie watching and maybe occasional gaming sessions. I've been completely spoiled by the movie watching experience of the infinite contrast ratio in a dark room. Nothing else is even comparable. But I'll have to babysit the next one much more carefully to make sure it doesn't suffer the same fate as the one I have.

Any plans for Azure Storage support? They seem to have much cheaper archival storage than the competition, offering $0.002/GB, amounting to $2 per TB, which is half the price of Glacier.

https://azure.microsoft.com/en-us/pricing/details/storage/bl...

> Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway.

https://what-if.xkcd.com/31/

The challenge then, as with essentially every language that doesn't use persistent data structures _as the default_, is having to recursively convert to and from those persistent data structures at the edges of your system where you need to interact with third party libraries that likely won't be consuming/producing those data structures natively.

Unfortunately this is where the value proposition of a non-standard data structure library usually breaks down for general usage. That recursive translation layer sitting at the edge of your system is generally enough to completely blow up your performance budget and many times leave you worse off than if you had just used the default mutable data structures and made naive shallow copies everywhere in the first place.

The best case study for this is JavaScript, which by now has a fairly substantial following of functional programmers, and has an excellent persistent data structures library in ImmutableJS, but the vast majority of functional codebases in JS just end up doing shallow-copy-on-write using the default mutable data structures regardless, because of the difficulty of taking proper advantage of the performance benefits of persistent data structures in an ecosystem that overwhelmingly deals in mutable data structures. That said, the fact that C++ is not a garbage collected language and the associated developer ergonomics costs of having to manually clean up your own shallow copies might skew the value proposition a bit, but given that if you're writing in C++ you're probably in it for the raw performance in the first place, it's unlikely to be enough to tip the scales.

Agreed on all points, but I'd just like to point out the main reason inline objects and inline functions is a perf antipattern in React is not garbage collection pressure, but rather the fact that they invalidate perf optimizations like PureComponent and React.memo because the objects/functions will have new references on each render. If you use those two together, then you're incurring the cost of individual prop comparisons used by PureComponent/React.memo without reaping the benefit of being able to skip the render entirely if no references have changed.

JIT isn't really compiling the runtime performance penalty of the Proxy "away" though.

JIT compilation still involves a runtime performance penalty of the JIT compilation step itself, that has to be traded off against the runtime performance penalty of just running the Proxy logic without any runtime compilation step.

That's a nuanced tradeoff that has to be weighed on a case by case basis by various heuristics, and can reduce the runtime cost of proxies when applied to the right cases (and at the same time, could increase runtime cost if applied to the wrong ones: think overly aggressive inlining and its effects on memory usage), but either way it doesn't result in the Proxy abstraction becoming "compiled away" into something that has 0 runtime cost.

It's not possible to pre-compile away the dynamic part of a Proxy's behavior.

For instance, if you were to receive a random string over some network call and set that on a proxified object, how would you pre-compile the Proxy away such that its runtime behavior is preserved when accessing what could be any arbitrary string?

You'd need infinite space to represent the space of all possible string inputs in order to optimize that away at compile time, which is obviously not feasible.

Exactly this. I take a hard stance against abbreviation in our team's codebases not solely because people might have trouble understanding what they mean (though when you take abbreviation to the extreme, i.e. words to single letters, that becomes a huge problem as well), but also because of the tendency for abbreviation to lead to an explosion in different slight variations of the same name used across the codebase to represent the same things, which increases the chances of missing important pieces in a refactor and decreases the chances of someone being able to find whatever they might be looking for.

Keeping naming conventions consistent across a codebase with multiple people working on it is hard enough to begin with. Abbreviation makes it even harder. Definitely not worth the few keystrokes saved, imho.

Immer is excellent. It makes deeply nested immutable updates a breeze. The API almost makes it feel like you're programming in a fantasy-land future where JavaScript's default data structures were persistent data structures like a proper functional language.

And it accomplishes all that without sacrificing type safety like most string path based approaches to deep updates often tend to do (think lodash.set or ramda.assocPath).

The only reason we haven't gone all in on it yet is the existence of browsers that don't support Proxy (like IE11, which we now unfortunately have to support), where performance takes a huge hit, and those tend to be the browsers that can least afford to take that performance hit to begin with.

What a coincidence. Just earlier this week I was installing yarn in a docker container using their official instructions (https://yarnpkg.com/lang/en/docs/install/#debian-stable) and found out I had to install apt-transport-https for it to work.

Since the image was already apt-get install'ing a bunch of other packages at that point and everything seemed to work, the obvious question that popped in my head was: does this mean none of the other packages I've been downloading used https? That's what led me to this website.

Not trying to make any value judgement of my own here, but I think the parent was more referring to the marginal cost/benefit of a $60 font compared to some of the free options available.

I actually remember running into this issue a lot when building Docker images. Generally you want your docker image to be reproducible so you'd want to lock versions of your dependencies. But when doing this with apt-get install, a lot of the time I find that when a new version of a package is released, the old one gets removed and becomes no longer accessible, so locking versions actually ends up resulting in _more_ build flakiness than just using the latest of whatever package available at build-time, which is obviously not ideal.

Deleting older versions of packages that people may still be relying on seems like a very obvious no-go in a dependency management system. Any idea why this happens regardless? Is it just a matter of costs? Or is there more nuance to it that I'm missing?

I currently have way to much data lying around for any metered cloud storage to be economical, so I'm currently subscribing to both Backblaze and Crashplan for their unlimited storage backup plans.

Crashplan killed off their consumer plan a while ago, so I ended up moving to their business plan at double the price. In my case even at that price it was still worth it considering the amount of storage I'm using.

Anyone aware of other services offering unlimited storage for a single user? I know Dropbox, Google Drive, and OneDrive all offer unlimited storage in their business plans, but they all require a certain number of users before the unlimited storage kicks in.

I like the concept of Privacy.com, but dropped off after signing up because they require linking a bank account through Plaid, which requires you to hand over your online banking credentials, which makes you liable for any fraudulent charges to the account according to the policy of most banks, and gives them access to all the confidential financial information available from your banking dashboard.

A routing number + deposits verification system still gives push/pull access, but offers recourse in the case of fraud, and doesn't expose all of your financial history in the process. It's a tried and true system used by many other reputable online payments businesses. It amazes me that they still don't offer routing number based verification as an alternative, quite ironic considering that the company has the audacity to name themselves Privacy.

Final was a much better product in that regard, because it was a credit card, so you could pay from your bank's bill payment page in a push-only manner without giving away any access whatsoever to your bank. Plus the rewards were much better, and you get access to 30 days of float on your purchases by nature of it being a credit card. Too bad the company behind it was acquihired by Goldman Sachs: https://www.fastcompany.com/40523758/goldman-sachs-buys-cred...

I'm still hoping something similar pops up again eventually.

Exactly. The kinds of transactions that take place by the thousands (just guessing, might be off by an order of magnitude or two?) on a daily basis on AirBnB, i.e. guests giving complete strangers money over the internet in advance to stay in their homes, and hosts inviting complete strangers over the internet into their homes in the first place, simply has no chance of ever becoming mainstream on a platform like Craigslist.

This is precisely because they're the kinds of transactions that most people would never even consider to take part in without first being able to establish a certain level of trust in the other party.

I think this is probably the biggest competitive advantage for AirBnB against challengers in the space. Bootstrapping a 2-sided marketplace is hard enough to begin with, but doing so while building up a network of trust among users so they can comfortably partake in transactions with a high trust-barrier is even harder.

Not to mention sheer storage density that has already far outpaced spinning disks (just not at an affordable price, yet): https://www.theverge.com/circuitbreaker/2018/2/20/17031256/w...

This thing is 30TB in 2.5" format, while the largest capacity HDD I can remember hearing about is 15TB, and that's in a 3.5" format, which is about double in physical volume and weight.

I can't wait for the day when something like this becomes economical, so I can stick two of them in a compact portable NAS for 30TB of redundant storage that I can bring with me anywhere.

Not to mention, SSDs on average seem to have more predictable failure modes that scale based mostly on usage, and tend to be overall more reliable than HDDs that can often suddenly die on you with no warning.

Thanks! Yeah that approach makes a lot of sense for the use cases presented in the post, and may be the most pragmatic path for enabling this workflow.

Although I feel the automated data generation approach still has value in that it can introduce some variance in the dataset to better represent real-world data, potentially uncovering issues in handling of edge cases in the design/implementation of the UI, that the original conveniently customized dataset that came with the design wouldn't. Though such an approach will likely also need to offer the ability for users to override/customize the generated data on a case by case basis in order to be useful for real world applications, so we'll probably end up with a bit of a hybrid approach at the end of the day regardless.

Curious how fragments can be applied to the use case of creating a new item and having a query for the list of items updated automatically? For instance, in the createTodo mutation & todos query example here: https://www.apollographql.com/docs/angular/features/caching....

I was hoping to be able to expose the list of todos on the createTodo mutation response, and have Apollo update the cache automatically by querying for it in the mutation response, rather than writing the newly created item to the appropriate location in the cache manually. From my research into it so far, it looks like that's not currently possible, but I'd love to be wrong about that!

Thank you for the quick reply!

My question was more about how that persistent dataset in your shared development environment is created though. As that dataset has to first exist for people to query against it.

Curious if that creation process is manual or automated somehow through inference on the types in the schema.

My personal major pain point with Apollo is with the need to manually manipulate the cache to keep it in sync after a mutation that adds or removes an item from a list, which feels really clunky and error prone compared to the much more elegant workflow of updating an individual entity, where the cache gets updated automatically by Apollo's normalization. See https://www.apollographql.com/docs/angular/features/caching....

Ideally I'd like to be able to specify a unique identifier for a list through a directive on a query, and then specify the same identifier on the mutation, to have the result of the list in the mutation automatically replace the contents of that key in the cache (or append onto it for use cases like pagination, possibly in combination with another directive for sorting the combined list on the client-side?).

I was hoping to be able to do something like this using the @connection directive: https://www.apollographql.com/docs/react/features/pagination...

Unfortunately, when I tried this it looks like the @connection directive actually creates separate nested keys for mutations vs queries, so unfortunately this use case isn't possible yet. I'd love to hear how others are approaching this problem, especially those using other caching graphql clients like Relay. Or maybe I'm missing some better way to handle this in Apollo itself?

I'd personally be interested in some details on how they're _generating_ the mock data for their server.

As they're using that mock data for testing, the data returned has to be deterministic, so I'm guessing they're either making up mock data manually by hard-coding that data in resolvers on the mock server implementation, or using some kind of fake-data generating library to generate that data dynamically based on graphql type in the schema, with a fixed seed so that the data doesn't change between runs.

I'm hoping to explore the latter approach a bit more as I feel it would be great for testing productivity to have mock data generated from the schema instead of having to manually write them for every new thing added.

> This is what Whatsapp does. Signal never did and has real multi-device support.

This is news to me. Curious then, why is it not possible to use Signal desktop without a phone?

https://support.signal.org/hc/en-us/articles/360008216551-In...

> Can I install Signal Desktop without a mobile device?

> Signal Desktop must link with either Signal Android or Signal iOS to be available for messaging.