harg

I believe Monzo is becoming available in the US so this might help improve the situation there, at least for monzo-to-monzo transfers. However I guess the whole system needs improving to allow seamless inter-bank transfers without a middleman.

It would depend on the use case, but as this looks like it's aimed at a technical audience, you'd generally have some sort of CI/CD pipeline that renders the markdoc on a server and deploys the output accordingly, be it a react app, plain html, etc.

In many cases, authors would probably need to run the toolchain locally so they can preview their changes. But publishing would basically be the same as committing code and having a CI pipeline take it from there

I find YouTube basically unusable on any device except for my laptop with an adblocker. The ads are so intrusive and cut in at such jarring moments that it's just not worth it. It's not uncommon to have to tolerate several minutes of ads just to watch a sub-10 minute video.

The point I was trying to make is that your second example doesn't prove or disprove anything. You're simply comparing a primitive value. 1 will always equal 1, regardless of which variable it's stored in.

Your first example is enough to conclude that the locally scoped `event` is the same as the one on the window object, due to the pass-by-reference nature of JS objects. The fact that comparing the two returns true means they must be the same object.

To avoid the whole "what is the `event` variable and where does it come from?" problem they could use

  element.addEventListener('submit', submit)

The second argument to `addEventListener` is a callback that takes the event as its argument. (`element` should be the form and the event should be `submit` for accessibility reasons.)

Also, the author's example comparing `x === window.x` as evidence that it's insufficient to know if the in-scope variable is the same as the one on the window is wrong. The example uses a primitive value (`1`) which in JS are passed by value, so of course whenever you compare 1 with 1 it'll return true regardless of which variable the 1 is stored in. Objects, (that `event`s are an example of) are passed by reference. So you get

  const x1 = {foo: 1}
  const x2 = {foo: 1}
  
  x1 == x1 // true
  x1 == x2 // false
  x1 == {foo: 1} // false

So a simple comparison between objects is enough to determine if they are the same instance. But it won't work to see if 2 different objects contain consist of the same property-values as each other.

I guess one could also just burn the hydrogen directly in a jet engine, which might be lighter than fuel cells and motors

> You don't and they screech about the resulting sprawl as development becomes more diffuse.

Highways create urban sprawl, they don't prevent it.

> the cognitive dissonance it takes to argue that raised highways and highway pits cut through neighborhoods but not let out a peep when it's subway and tram lines doing the same should disqualify one from voting.

But a subway/tram line is completely different from a highway. Trains can move an order of magnitude more people/stuff, don't result in local air pollution, don't create a lot of noise, don't result in road accidents that kill people and destroy property. And that's even before you realise that a subway is underground so you don't need to tear apart neighborhoods to build them and you basically wouldn't know it's there.

Regarding cascading logic with soft deletes; I think the answer is that you don't cascade anything. You basically need to have `deleted_at IS NULL` conditions in your queries to exclude them.

Yes, that's not ideal. Thankfully not too sensitive by itself, but clearly something hasn't been done right.

Usually the public facing keys are restricted in a number of ways to help prevent abuse. E.g. they'll have strict rate limiting, fine-tunable scopes, domain restricted, can only be used in conjunction with a server-side secret.

E.g. Stripe has a publishable key and a secret key. The publishable key links the checkout session to a particular Stripe account, but you can't actually initiate a checkout session without setting a session ID from the server (which requires the secret key). If the 2 keys don't belong to the same account then the checkout session will fail.

Yes, with some services you can proxy requests via your own service. But how is this more secure? If anything you've just increased the potential attack surface.

I'm not sure how bad this actually is. I haven't examined all the env variables exposed, but it's fairly common to expose public-facing api keys for services that require client-side communication with a 3rd party API. E.g. for client-side bug tracking, search etc.

You're assuming that the battery needs to store the total energy requirements of a house for the entire year. Much of the time the energy needs can be met by conventional energy generation (wind turbines, solar, hydro, etc) and the battery is only called upon when there's a shortfall. So you'd only need a fraction of the annual consumption to make it useful. The whole idea is to make renewables more effective by storing the excess. Grid storage will be an important part of the transition to renewables.

But yes, it is expensive, but it's only at the R&D stage. I'm sure could be made cheaper, and the article mentions reducing the cost to $6/kWh.

I recently had to build a simple CRUD webapp in a very short timeframe (a few hours) as a coding challenge. I ended up using Next.js with Prisma (ORM) connected to a SQLite database. Got the job done pretty easily and quickly.

You could just talk directly to the DB using the basic Node SQLite packages/libraries but I found using an ORM like Prisma greatly reduces boilerplate and makes things more robust.

Without falling into an oil debate, no cycle mechanic I’ve ever spoken to uses or would recommend wd40 for chain oil. It’s far too thin and is primarily for freeing stuck parts and cleaning. It’s not meant for long term lubrication - it dries out or get washed off almost instantly.

3 in 1 is fine, but the main advantage of a proper chain lube is that they don’t attract grime and dirt as quickly

Not quite. If your workday ends at 6pm then being on DST means you get usable daylight for more of the year after work. Even if you were prepared to get up and go to bed earlier many jobs have a fixed set of hours.

Except that even smart clothes have a functional use: as clothes. Fake shutters have no utility value.

A closer analogy to dressing up for the opera would be artisanal hand-carved decorative (but functional) shutters basic plain shutters. They both have the same utility but one has nicer aesthetic.

But if you get a load of solid carbon as a byproduct that could offset a lot of the energy cost, assuming the solid carbon is in a useful form.

I think it also highlights that cutting down forests for energy also greatly harms the natural ecosystem that depends on the existence of trees. So there are effects beyond carbon emissions

I think they do understand how ssg works. The issue they’re trying to solve is how to inject env-specific configuration at runtime. Regardless of which ssg you use you still need a way to vary these values at runtime. I don’t think using the ssg itself is a very efficient solution. Things like envsubst work well to template env variables into static assets or server config at image startup.

If you can buy one. I think they stopped making them a year or so ago.

I've heard the DACs on the Chromecast audios are pretty good, so should be plenty hi-fidelity for most people's needs.

This just looks like sharing via the file menu, sadly the web share API doesn't look like it's yet supported. It's still a good addition though.

https://developer.mozilla.org/en-US/docs/Web/API/Navigator/s...

For the general population this probably applies, but in the case of this exploit it looks like it's targeted at specific individuals. If you were someone being targeted by an oppressive government, for example, you might be a bit more cautious when clicking on suspicious-looking incoming media so I think the suggestion has value.

There is a colourblind friendly colour option that you can enable in the site footer

You’d need to send the user to the verify page and populate a form with their token from the url. Then submit the form, either automatically or by getting the user to manually hit a button.

It looks nice for beginners but personally I find that a simple docker-compose file per project that spins up a postgresql container works pretty nicely and is really easy to use. I just run `docker-compose up -d` and I have a database running. Docker containers also stay out of the way of the os and I can run the right versions for whichever project.

As others have mentioned it's the main group of riders in a bike race. However, as is the case in this context, it can also be used to refer to the race in general, given that in the TdF all the riders will generally finish each stage within an hour or so of each other (or else be disqualified) and start the next one all together.

> with the capacity to produce up to 60 gigawatt hours of power per year

Maybe a nitpick but it's interesting how often people confuse power with energy/storage. "gigawatt hours" is a measure of energy, not power.

From my understanding Northvolt is manufacturing batteries, so the "60 gigawatt hours" figure is referring to amount of battery storage they're making. If they were generating power it could refer to how much energy they'll generate over a year, but I don't think that's what it is.

I think it's important to get these details right as it can change the meaning significantly

Also

> building a battery factory so large it would fill 100 football pitches and produce enough power to light 6bn light bulbs a year.

Is the factory generating power? How does the factory produce this much power? Or is it referring to the energy stored by batteries it's producing?

I don’t think the article alleges that ICE cars will disappear overnight. It merely claims that electric car growth will put pressure on petrol stations, forcing them to close which in turn further incentivises people to switch to electric. Seems fairly logical.

All these things take time to happen and hopefully things will change for the better; cleaner electricity, battery tech cleaner, more sustainable. The alternative is new ICE cars which cannot be better.

From my understanding this should work as the schema is introspected ahead of time. This gives all the type information needed for the `useQuery` hook to work properly. Just the queries themselves are generated at runtime; there shouldn't be any need to introspect the schema then.

Where this might have an issue is with persisted queries. But then you'd need some sort of client/server build tooling to keep them in sync.

indeed, the point the parent comment was making is that effective email validation need not perfectly implement the RFC.

dotless domains are going to be so rare in practice (unless your project has some niche use-case) that you can probably ignore them and call them invalid for the sake of simplicity.