aobdev

Just pointing out that Pylance is a VSCode wrapper around Pyright, which is a static type checker with no primary linting features. The separate VSCode Python plugin however integrates with pylint, flake8, pylama, bandit, etc. and I agree that it is very good.

I'm sorry to point out that the first 5.0 alpha came out in 2014 and still hasn't been released. When people talk about the ecosystem/battle-tested-ness/quality of express I think that unfortunately doesn't extend to anything other than the latest major on npm. It's not "modern" but it's still a good tool.

I'm guessing the renders are not representative of what it will actually look like as the article states that "their initial filing does not provide us with much detail about exterior design". It also seems unlikely that this exact proposal will be approved and constructed as-is.

Frequent backups that include node_modules.

I don’t agree with the above sentiment, but Vue 3 is quite good.

It feels more “complete” to me than react in the sense that I don’t need to keep up with what’s going on with redux vs. alternatives, or what changes are in the latest version of react-router, or what’s going on with Next 13/server components, or update my webpack plugins or decide if I’m moving to vite. Long story short 95% of cases have an official solution.

Similarly, I don’t often have to look beyond the official Vue docs to fully understand how things work. React hooks are good enough but they don’t have the same approachability as Vue’s composition API.

It seems crazy, but it’s true. Also consider that Vite is a wrapper around 2 tools that are impressive in their own right: esbuild and rollup (and the latter was created by the guy who made svelte!)

I’m sure this is true and can be attributed to DST, but do we know if this would be worse than traffic fatalities caused by commuting in the dark during winter months without DST?

Can you elaborate? I’m assuming things go wrong when people don’t get enough sleep but I’m otherwise unaware of the dangers of changing the clocks.

Mortgages are typically issued as non-recourse loans. This may not be true for HELOCs or other risky equity loans, but usually your lender can’t seize your home unless you haven’t been paying monthly.

USB-C?

They serve different purposes. Prisma provides type safety between server and database, tRPC provides type safety between client and server. You’re most likely going to have some logic between those two channels that manipulates and makes those interfaces similar but not quite the same.

Management at the now FDIC-controlled bank will estimate the value of SVB’s assets, such as loans and bonds, and give depositors a fraction of that value to be paid in advance of the sale of those assets. They do this to prevent the collapse of all those companies who were SVB clients, which would be bad for the economy.

Just to be clear, are you talking about a file where each line is its own json object rather than the entire file being one large array?

If so, it’s easy in Python to do the following:

  with open(“file.json”) as src:
      for line in src:
          json.loads(line)

Heads up to the author in case you’re here, you reference a tweet about Next.js but subsequently refer to it as “Nest”.

Unfortunately the given examples (Next and Nuxt) are much slower than traditional template engines, even in "slow" languages like Python + Jinja2. This may not translate into financial cost at the scale of your average startup but it does have a measurable performance cost for each page load.

If I understand correctly, it seems to be a cornerstone of Supabase’s Authorization features. https://supabase.com/docs/guides/auth/row-level-security

Honestly that sounds like fear-mongering, Reddit wants to protect its interests by turning the public against section 230 reform.

What makes this a bad argument against JWTs rather than a good argument in favor of using built-in features of the platform? I agree that any purported issues with JWTs are solvable, but if you don't need the benefits they bring over sessions, why use them at all?

I think the premise of the article, which I wholeheartedly agree with, is that for 95% of software projects developers should choose the simplest implementation necessary to meet the requirements. Sessions come for (almost) free with the framework and most browsers, but JWTs have an additional cost for the problems they solve, which are usually poorly understood upfront.

I think the most secure approach is to store a random id in the database and to also sign it any time it’s exposed to the user (as a cookie or url sent via email). The first benefit is that you won’t be exposed to DoS attacks whereby you’re querying non-existent tokens from your database, and the second benefit is that illegitimate sessions can only be established by compromising both your database sessions table and your application’s signing secrets.

I was about to say “but this one is!” and realized I had confused PostgREST with PostGraphile. If you’re interested in GraphQL, you can check out PostGraphile here: https://github.com/graphile/postgraphile

It’s interesting to me that PostgREST and Hasura are written in Haskell, but PostGraphile is not. Given the complexity in parsing arbitrary GQL queries I think I assumed that Haskell was a better fit for the job, hence the mixup!

These passwords have to be encrypted so they can be retrieved later, right? I don’t think Argon2 works for that purpose.

I hate that these are called models (probably because they extend pydantic’s BaseModel), but if they were called Schema or Serializers would this still be true? Typically what you see in a FastAPI project is a class that parsers the request body, and the same or slightly modified class that serializes the response back out after touching the DB. And this isn’t a new idea, because Flask+Marshmallow and DRF do the exact same thing.

Slightly off topic, but you can chain your language selectors in VS Code settings so that:

    "[javascript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },
    "[typescript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    },

Becomes:

    "[javascript][typescript]": {
        "editor.defaultFormatter": "esbenp.prettier-vscode"
    }

There's always such a mixed response when new web tooling gets posted here that I really can't tell if this is sarcastic or not.

Regardless, I like that this is fast and it is probably going to get a lot of adoption since it will be included with Next.js.

Receipts for the personal items that the airline lost, not for the airfare. You need to prove how much your damages are in order to make a claim.

They’re talking specifically about client-side hashing. You’re right that the system will hash the stolen hash, but only in cases where the system can’t be bypassed (which client side code always can be).

Hey, I wanted to chime in and say that I too am underwhelmed with the support for async in Python libs. Coming from a node.js background, it falls short because you constantly have to think about whether async code is calling sync code, or vice versa, and whether you need an executor, threadpool, etc. Just a mess that gets in the way of productivity IMO.

However, things have been getting better, and in case you haven't seen it, AIORedis[0] appears to be the de facto standard for async in Python (a little better with 1,724,389 downloads this month). It's popular enough that it's been merged with the official redis-py driver[1].

[0] https://aioredis.readthedocs.io/en/latest/

[1] https://github.com/redis/redis-py/releases/tag/v4.2.0rc1

The dual power adapter is in addition to, rather than instead of, MagSafe. The cable has the magnetic connector on one end and usb-c on the other. Dual ports just lets you charge your iPhone/iPad etc. at the same time.

Can you elaborate on how CORS provides an alternative? Responding with a CORS policy to your own client’s preflight requests is not going to do anything for a malicious client’s form POST.

I don’t think anyone here is giving remix enough credit for what they’re trying to do. In fact I’ve been a long time lurker and finally made an account today to share this opinion.

My company is building a B2B ordering system. We take reservations and store fulfillment details with some email and SMS functionality bolted on to a web interface; at least for now it’s a simple business CRUD app. We chose to use Vue for the frontend and Python REST APIs on the backend. And it has been thoroughly frustrating to just ship our MVP, because when I look into our frontend codebase, more than half of it is a bunch of API calls, state management, authentication, and error handling that honestly does not provide much value to the product that we’re offering. I half wish that we had built this in Rails or Django.

Except, we are geospatial-enabled and have a killer interactive map view that powers this whole thing. And it’s not just a single asset-tracking view, but this map component is going to be embedded in several places across the app. And when you zoom, pan, or search the relevant data on screen is updated. I wouldn’t dare try to build this in anything other than one of the big 3 SPA frameworks today.

Why do I have to choose between a traditional app with poor ergonomics for developing frontend JS, and a clunky SPA that reinvents everything the browser has gotten good at in the last 20 years? Remix is a hybrid and I think they are on to something really great here. I can write my server side models and controllers as in days of yore and pass them straight to a renderer that happens to be full blown React + React Router that does as many fancy interactive things on the frontend as I wish once the page is hydrated.

I think it’s easy for backend devs to discount how nice it is to use JSX across the stack if they’re used to a templating language and writing JS sprinkles to manipulate the DOM. And it’s easy for frontend devs to discount how much extra work it is to create an API when your team is only using it internally for a first-party app, because you need APIs for SPAs. But once you realize that you can eliminate these entire bodies of work (manipulating the DOM and writing an unnecessary API), you get the best of both worlds and everything about complicated web dev today feels so achievable.

Even if it’s early days yet, and Remix can’t hold a candle to comprehensive frameworks like Rails, this is much more than just Sinatra or Flask written in JS. I’m seriously excited about where Remix is headed and I’m rooting for these guys all the way.