philplckthun

> There really shouldn't be two standard package managers for JS.

I chuckled a little when I realised that npm, Yarn, Yarn 2, and pnpm can all be found alive and well in the ecosystem

As someone who's worked on this, I'm oh so conflicted. Yes, it's mostly a terrible idea, if CodeMirror and the likes work. On the other hand, there's so much default behaviour that's just excellent that'd need to be reimplemented if you started from scratch. It can't be denied that contentEditables have the advantage of just requiring much less code overall.

To this extent, I've written a hook for React/Preact that attempts to be a decent code editor basis on contentEditables: https://github.com/kitten/use-editable

Funnily enough, if you just search the code for "// Quirk" it's easy to see that this experience wasn't pleasant in the slightest. But it did allow me to write a code editor in just about a day which can be found here: https://trygql.formidable.dev/

I'd say, there's plenty of edge cases to take care of. But on the other hand, things like composition, selection behaviour, and other niceties are things that you just have to take care of much less

I'm honestly not sure whether there's really a good excuse to invent a format that's immediately incompatible with all GraphQL tooling out there, which would need to be converted. After all, debugging and logging tools could still display these.

It also conveniently leaves out automatic persisted queries which would replace queries with hashes, or regular persisted queries, where we'd have a limited set of allowed queries on the server-side that it accepts.

I think ultimately when I think of sending GET requests for GraphQL, I'm immediately more worried about the URL length limit. The risk being that at some point in the future we may run over this limit and get into a lot of unexpected trouble.

Also, this article assumes that you can only stringify GraphQL a single way, with spaces. However a not as commonly known detail in the spec is that any commas are treated the same as whitespaces. Hence, this is a valid query:

  {item(id:4){id,name,author(id:4){id,name}}

Which isn't far off from reading a complex query string IMO, works with any existing GraphQL API via GET if the API already accepts GET requests, and isn't a special format that'll need to be learned supporting the full syntax.

There are solutions to simply turn GraphQL requests into (traditional) CDN-cacheable requests. Usually this would be done using (Automatic) Persisted Queries, where a query is not only requested as a GET request, if it's not a mutation, but it'd also do so using a hash rather than an entire query.

This has a couple of limitations that you'd also expect from a CDN cache for REST requests. However, I believe the interesting part about GraphCDN is that it can do more to look at the exact queries and mutations that are run to invalidate queries more precisely.

So, it's likely worth saying that it's not that CDN caching GraphQL is hard, but getting invalidation and a high cache hit rate (just as with REST APIs) is hard.

To be fair, since this has been a while ago it's hard to tell what to do about this. Personally I find it hard to draw any conclusions from this just due to the time that has passed. I don't use Facebook, so maybe it's just my distance from it. But it has happened and it's worth stating that this is basically a psychological experiment and not a simple A/B test, but at a company that most likely at the time didn't have an ethics board to review this.

Other sources list a couple of principles behind the ethics of psychological research. The relevant ones being:

- Minimise the risk of harm - Obtain informed consent

Some of them do state that the latter isn't always exactly possible, since that may influence the outcome.

But the fact of the matter is that Facebook did an A/B test that could inflect serious harm on the quality of life of the participants, who weren't aware of any research being conducted. The latter sounds like it'd be at least the minimum here.

So, I'm not a psychologist, but this does sound like it shouldn't have happened in this way. There were definitely more ethical ways in running this experiment that wouldn't have involved 700K unknowing and potentially unwilling participants.

For what it's worth, I believe there are plans to reactivate the Siemensbahn tracks for a new line by 2025... or so I've read? Can't quite remember.

Not to toot our own horn, but while this mentions GraphQL with Relay / Apollo as fetching clients, with urql and its normalised cache Graphcache we started approaching more of these problems.

Solving the mentioned problems in the article for best practices around fragments is on our near future roadmap, but there are some other points here that we've worked on that especially Apollo did not (yet)

Request batching is in my humble opinion not quite needed with GraphQL and especially with HTTP/2 and edge caching via persisted queries, however we have stronger guarantees around commutative application of responses from the server.

We also have optimistic updates and a lot of intuitive safe guards around how these and other updates are applied to all normalised data. They're applied in a pre-determined order and optimistic updates are applied in such a way that the optimistic/temporary data can never be mixed with "permanent" data in the cache. It also prevents races by queueing up queries that would otherwise overwrite optimistic data accidentally and defers them up until all optimistic updates are completed, which will all settle in a single batch, rather than one by one.

I find this article really interesting since it seems to summarise a lot of the efforts that we've also identified as "weaknesses" in normalised caching and GraphQL data fetching, and common problems that come up during development with data fetching clients that aren't aware of these issues.

Together with React and their (still experimental / upcoming) Suspense API it's actually rather easy to build consistent loading experiences as well. The same goes for Vue 3's Suspense boundaries too.

Edit: Also this all being said, in most cases Relay actually also does a great job on most of the criticism that the author lays out here, so if the only complaint that a reader here picks up are the DX around fragments and nothing else applies this once again shows how solid Relay can be as well.

It's not a cryptographic key or a secret of any kind. In the case of React (or other JS libraries) export identifiers are chosen to expose private APIs for integration purposes with things like developer tooling and other functionality that isn't part of the publicly documented API.

Instead of choosing something like `__PRIVATE` the React library in particular chose something more eye catching: `__SECRET_INTERNALS_DO_NOT_USE_OR_YOU_WILL_BE_FIRED`, which is definitely sure to get people's attention when they look into it, but is essentially just a joke.

We actually don't know what the usual communiqués internally at GoDaddy look like. In a vacuum we can also judge this to be an effective test. In practice there are many unknowns and factors we don't know about though. In my opinion phishing is also an issue at scale when we talk about companies; meaning, there's a likelihood that some will always be more likely to fall for it.

Given how the world has been this year and what some employees maybe have gone through the employees that will fall for this particular phishing emails may actually need more support from their employer.

Either way, this isn't a vacuum and we are talking about a test that is unnecessarily cruel.

Edit: just to make this more constructive, there are always alternatives. Instead of relying on emails only employees could be informed to check in via a second channel in all matters relating to money or a company's IP.

> Sign this thank you to let Apple know consumers are eagerly anticipating anti-tracking protection on iPhone.

I'll only sign a thank you like this when Apple allows other browsers engines on iOS, which is actual consumer-friendly behaviour towards the Web.

No worries! Snark received.

As we go up the engineering career ladder and land on more specialised roles with the necessary experience, both from a technical and managerial perspective, the funnel definitely shrinks. I won't deny that that looks different from place to place, but it's hard to deny that it will take years still for any saturation we see to take place on the higher part of the career ladder as people specialise more as they get there.

Specifically once we started looking for engineering management and principal level roles that still bring the technical expertise we'd expect the hiring pool was definitely not saturated.

> "in talent to do the job."

It's a matter of perspective as well though, so both sides are correct. "The job" here can talk about very different engineering roles and levels, which will have a different hiring pool by market and by saturation.

From my own experience running interviews, even in the same "community's" hiring pool in the same location you can expect large differences depending on what position and skill set you're hiring for at that moment.

I find it more worrying that over years I've seen that some engineers are attempting to optimise the interviewing process on their end. Obviously instead interviews should optimise to appeal to candidates and make the process equitable, quick, and accurate, without nonsense like coding challenges that don't relate to the job.

This really reminded me of SCIgen, made to generate non-sensical CS papers with the same intention https://news.mit.edu/2015/how-three-mit-students-fooled-scie...

I haven’t really played around with installing browsers, etc via Nix on nix-darwin yet. The experience is really good for the most part! Setting it up initially is a little confusing since the installation has to create a volume for /nix, apart from that it’s really smooth.

I choose to replace Nix channels with in-code tarballs of the nixpkgs repository. Sometimes that does confuse darwin-rebuild but it could also be because I’ve set it up slightly incorrectly.

My Nix files are indeed open source! There’s a colour utility and a file that uses them to create theming files. https://github.com/kitten/nix-system/blob/master/config/colo...

Nix is fantastic!

I’ve started using it with nix-darwin on macOS and replacing various dot files tools and loosely coupled files and installed dependencies using Homebrew with clear and declarative Nix scripts has really changed how I manage my development environment.

I even went as far as coding up colour scheme configurations to synchronise colours between Kitty, Tmux, and Neovim, and added some configs to compile Neovim from source to get to some of its newer features, and I don’t think I would’ve done any of that (or rather, kept any of that around) without Nix.

That does sound very interesting. I believe the issue lies in the fact that this is a workflow-based “sales pitch.” What I mean is that this is a difference that doesn’t always apply depending on what tools you use (like client dev tools, type generation / hints, etc)

But what it does do is constrain. Now, constraints are great. They’re always a great tool to introduce new innovations. What I’m ultimately thinking is, how much do you bring to the table compared to persisted queries and tools like GraphQL Code Generator and the added flexibility that comes with those tools?

Genuine questions of course, not criticism

That sounds interesting! But isn’t this like persisted queries (the Relay kind and not Automatic kind) without the benefit of prototyping your queries as a front end dev as you’re working on the front end?

I’d say that’s completely fair still, just wondering. I’d also say I understand the carefulness and stance on “smart clients,” i.e. normalized caching, which is why this isn’t a default in urql, but without it I think the discussion here is much more nuanced.

It’s so to speak much easier to rely on an argument with a smarter client and the Apollo ecosystem, than the rest. Anyway, I like your approach with Wundergraph so I’ll definitely check it out!

That’s a pretty misleading statement, since what you’re linking to does describe how using scalars can help.

Especially if the scalar never includes other data from the graph (other objects) describing the custom format with scalars is just fine.

I think this is the important point here; it’s not hard to call GraphQL and even create a client starting from copying @urql/core for instance, but I suppose at some point if you want the same benefits on your other platforms normalized caching will be of interest, which means it isn’t as trivial to get to feature parity. So I think it’s still a valid point

Core Contributor of urql here, another JS GraphQL client.

I think this post is very good at stating why the particular post it’s referencing (“Why GraphQL” in the Apollo docs) isn’t a full picture overview, and it succeeds at that very well, but I think it doesn’t go on to expand on these views just as much as I’d like to.

If we look at popular comments by the GraphQL community on this it isn’t hard to find that “the quickest & easiest client is to just fetch a GraphQL API” (similarly said quite frequently) and that’s an excellent point.

But going on to say:

> However, you should always consider the cost of adding a GraphQL client to your frontend.

This is definitely true, but as a creator of another GraphQL client I’d say that there are major benefits as well, the main selling point of Apollo, Relay and urql (for the latter this is optional) being that you can utilise a normalized cache.

But these tools often provide great frameworks to solve some of the problems that are stated to be woes with GraphQL, like persisted queries, subscriptions, file uploads, etc. So they’re a great starting point to dip into multiple parts of the community and get out-of-the-box solutions for your problems.

And generally I’d say that sums up GraphQL: it’s not novel or anything new. Instead it combines a lot of ideas into a solid community and ecosystem. With tools like Swagger or gRPC it’s easy to see how any part we look at for GraphQL isn’t novel.

What is great is that the exact set of problems it solves it does so with a larger (and growing) community and a standard that encompasses multiple of these solutions.

Finally, I’d say again, GraphQL clients and servers aren’t “all of GraphQL,” Apollo isn’t GraphQL (although they’ve made themselves synonymous with it) and hence there are different tools, clients, and libraries to create GraphQL servers, clients, and interact with GraphQL APIs. As a user you’ll still have to choose, but a lot of the good parts come from agreeing on one language and standard that allows for introspection and the ease using which we interact with these APIs on the client-side, from simple HTTP calls to more complex caching clients.

> Despite a short lifespan on the npm portal, the library was downloaded more than 370 times

It’s probably worth mentioning that this doesn’t sound like the back door was successful at all. Every package typically has around ~100-200 downloads immediately due to scanners and proxies.

This security response of under a day really sounds like a good improvement, although I still wish npm had some support for signatures so trusted packages can be trusted indefinitely.

> “People may think that current flowing in a resistor causes it to heat up, but the Brownian current does not. In fact, if no current was flowing, the resistor would cool down,” Thibado explained. “What we did was reroute the current in the circuit and transform it into something useful.”

Based on this I understood that it'd indeed cool down and create a heat gradient if it wasn't doing any work, but the difference it'd create is instead used to induce a current, which means it probably wouldn't cool down as long as that potential is used in this way instead (?)

I think it's fine to point out the Thunderbolt mess, or the PD vs non-PD devices (although non-PD is becoming exceedingly rare as far as I can tell at least for "larger" devices), but using the Nintendo Switch seems like a bad example in my opinion, since it explicitly does not follow all USB standards, especially in fact on charging.

Also is there some magical step once you’re a trillionaire? Surely at this point it doesn’t make a difference anymore exactly how rich the guy is.

With Cantonese being mentioned in particular it’s worth noting that China has always acted to eliminate other languages in the country to the point where Cantonese and other languages aren’t spoken anymore in the mainland.

This may seem more efficient to the OP but we’re not talking about a common official language being known by all, but a single language displacing all others for the purpose to homogenise a country that consists of many cultures into a single one.

So it’s important to say: language is not only a tool but a reflection of culture, identity, and your part of society. We can learn a lot about people by learning their languages, and the disappearance of a language is always significant.

Just some thoughts; I actually found this phrasing really interesting, because clearly “you cannot have irreparable harm when you create the harm yourself” is provably incorrect.

The judge won’t let this influence the decision on not extending the injunction to the Epic Games contract with Apple because of an earlier point, which is that two separate contracts exist. It’s interesting that this has been addressed with this flimsy follow-up argument.

Obviously the court shouldn’t let this influence their decision because it was a calculated move, and it’s assumed that Epic is fine with the harm it causes them to make a point. Nonetheless it’s causing them financial harm, which may in the long term be irreparable if in the meantime their player base on iOS shifts to different games.

So all in all, it is a calculated risk but irreparable harm is indeed one possible outcome. Whether Apple takes any responsibility in this depends on how the court decides in the case however. Even if their behaviour is judged as uncompetitive, that may not automatically mean that they’re at all at fault here.

Genuinely ignorant here and curious, would using OpenSSL’s salt option help here? I’m not quite sure why the instructions in the repo specify a fixed IV to begin with

I only ever owned an XPS 13 9350 (~2015) and it suffers from really horrible coil whine, regardless of whether anything is plugged in or not.

I really wonder whether they’ve fixed this issue, as I’ve heard that some models after this one still suffered from the same.

It’s great to see that that’s already supported! I wasn’t aware of that, and it’ll allow Google to pivot this feature towards a similar use-case.

Right now however it seems to primarily be marketed to mobile game developers.