xthrowawayxx

> do you think that there has probably been no progress in climate sciences during the last 30 years and thus predictive power is at the same level?

I agree there will have been lots of progress. However, 30 years from now people will probably say that the same thing to excuse todays predictions if they were wrong.

> Counties expected to experience heat indices above 125°F by 2053

Genuine question. How many climate predictions from 30 years ago came true today?

I have npm fatigue.

Just use the language people!

Writing 3 LOC instead of 1 call to an external package is OKAY.

Here's my notes on DynamoDB: How to spend $100k on what would cost $10k with an sql server for a 100x worse service

I assume you're talking about abortion.

How did their ruling infringe on the separation between church and state?

>Increasing theocracy and dissolution of church and state separation

Can you give an example of this?

How do we distinguish between: "VCs are are selected because they go to school X", "school X is good at creating VCs", and "school X receives more potential VCs"?

My guess is probably more statements 2 and 3 for the usual suspects eg Stanford

I think a good thing that laws can't pass without sufficient consensus. If you can bypass consensus for the greater good then so can the other side.

I exclusively use Firefox on Android because of the addons. For me it's the killer feature. Dark mode, ad blocks, YouTube while screen is off. It's made android so much more enjoyable.

>I lost it when at my previous job I found a 20 multiline super complex type defined by another dev, asked him to describe it because I was in a tight deadline and had not time to parse whatever he was defining. He starts with "it's pretty simple" and then used like 10 minutes to describe me what he meant while writing on paper the various pieces getting confused two time

sorry about that

What happens if you get hacked and someone steals your house NFT?

Have a trusted third party transfer it back to you? Or give up your house to the hacker?

yes yes yes! this is so true

Sorrt, I can't tell if this is sarcasm.

Is there something I'm missing? Even the above examples look awful to me

Consider removing as many extra tools as possible to make monorepos actually work.

Eg throw out eslint and prettier.

I find that NodeJS runs eventually out of memory and crashes with applications that do a large amount of data processing over a long time with little breaks even if there are no memory leaks.

Edit: I've found this consistently building multiple data processing applications over multiple years and multiple companies

This is great! I've been using Firefly III for years. However it consumes a good chunk of time to keep up to date at a line item resolution with many cards and accounts across countries as I've not automated any of it.

Which is?

You're right. I don't actually DI always. Only (most of the time) when I have may have multiple implementations of a function, mock the function, or test it with different implementations of its depenencies.

I still use many static functions

How though do they know the ID before the object is created (/ fetched from db)?

Sounds like it's inferior to manually using a DataLoader within every resolver that fetches an object.

eg project has a client. In the resolver for a projects client, you fetch the client from DB. With DataLoader you manually cache the request for the client. With in-built caching you must resolve the client for the server to know the ID, and then on next resolve of the client, after fetching, it matches the ID and doesn't have to resolve it's fields again, but it still had to fetch both times?

I cache at the schema level for each request.

How do GraphQL servers automatically cache objects? I was not aware servers do this. I generally avoid them because of their inflexibility (eg. Unable to support the two websocket subscription sub protocols simultaneously).

What's wrong with it? How do you mock functionality?

This is true

>Decoupling your dependency seems reasonable, but you can do it much simpler.

> type GetProject = (...) => ... > type ProjectCRUD = { get: GetProject, set: ... }

> constructor(private projectCrud: ProjectCrud)

Yep that is a more concise way of doing the same thing. I've considered that approach and it seems perfectly reasonable, even cleaner. The only reason I haven't is because constructors offer a more standardised approach to object creation for service type objects that other developers are familiar with, rather than higher order functions or function constructors. Although my method is kind of bespoke anyway so I could go either way. Another advantage of your approach is composing finer grained functions or objects with methods into more expansive services becomes delightfully easy.

>[1]: https://news.ycombinator.com/item?id=31547975 - I'd love to hear opinions on that.

I've tried to use TypeScriot DI containers... Oh I've tried.. But eventually they all just feel gross.

These days I'm perfectly happy having a bootstrap / createServices method for the application, or with multiple entry points each requiring a subset of services with different configurations, different create<command>Services functions. Works well for CLI apps. Downside is when there are too many entry points with different depenencies, like an HTTP API, you don't want to create a bootstrap method for each entrypoint. In this case I create all services once on bootup. I pass the request context as method argument. Don't have a perfect way yet of doing request-level services like GraphQL caching. Currently I lazy load request level services on request context.

In my experience I prefer grouping by domain over grouping by abstraction

An ISaveable interface would need to be generic but "save" functions might take different numbers of arguments, and of different types.

I've found the advantage of interfaces to be dependency injection, where i can inject a different implementation of an interface without breakijg anything (eg save to s3, to google cloud storage, to filesystem, to memory), or a test version of the function/class.

Abstractions like ISaveable on the service interface just make the code more fragile in my experience in an attempt to save some extra but simple lines of code. Granted it may make sense on active record model classes though.

In Typescript I've started doing

interface IHasSaveProject {

  saveProject(...): ...

}

class HasSaveProject implements IHasSaveProject {

  saveProject(...): {...}

}

class Controller {

  constructor(private readonly IHasSaveProject) {}

  post(...) {
    this
      .hasSaveProject
      .saveProject(...)
  }

}

And basically have a different class for every function

In cases where it really makes sense to have multiple methods on a single class, I do this

interface IProjectService extends IProjectService.IHasGetProject ,IProjectService.IHasGetProject {}

namespace IProjectService {

  export interface IHasGetProject {

    getProject(...): ...

  }

  export interface IHasSaveProject {

    saveProject(...): ...

  }

}

class ProjectService implements IProjectService {

  getProject(...): {...}

  saveProject(...): {...}

}

class Controller {

  constructor(private readonly projectService: IProjectService) {}

  // or

  // constructor(private readonly projectService:
  //  IProjectService.IHasGetProject
  //  & IProjectService.IHasaveProject) {}

  // or

  // constructor(
  //   private readonly hasSaveProject: IProjectSercice.IHasSaveProject
  //   private readonly hasGetProject: IProjectSercice.IHasGetProject
  // ) {}

  ...

}

Seems to be working well for me. Lots of flexibility. Not sure how others like it though.

Please forgive my formatting

how do you jump to arbitrary pages with cursor pagination?

thank you :)

Can someone explain the significance of this like I'm 5?

I once deleted a 15TB database by temporarily shutting off an AWS i3en instance.

Nobody told i3en's have "ephemeral storage" that gets wiped on shutdown.