Hacker Newsnew | past | comments | ask | show | jobs | submit | itsjustjordan's commentslogin

I just swapped all my Claude code spinner verbs to be Warcraft related and was thinking today how I could get it to say “Jobs done” when it needed my attention


Slightly related but today I learned if you Google a font the site changes to that font.


Curious as to how, assuming a successful push in this direction, will affect web design and browsers in general. I potentially see a future where, like responsive design for mobile devices we end up with an "llm-optimised" version of websites.


I was going insane doubting my SSH knowledge, stopped short of creating new keys thankfully!


well on my side I'm the proud owner of a new ed25519 key.. The status page didn't update quick enough


as am I!


I for a second thought was I getting fired


As someone who found out that way twice in the last two years, I also thought I had been let go. Anxiety is a hell of a drug.


Sorry for you, it should be illegal for companies to fire with no notice!


This is the case in many places, but companies would often rather pay you to not work for the notice period rather than have access to digital or physical company property after having been given notice.


I thought my account was hacked and ssh keys removed. Panicked a little bit and then double checked that my keys were still there.

Then went to github status and calmed down.


I briefly entertained the notion that I was fired and my ssh keys revoked. But I still had access to slack and email etc, so I banished that thought.


Was trying to install homebrew on a device and kept wtfing because the clone step kept failing… thought I was crazy


I had just upgraded to Windows 11 last week, and for some godforsaken reason earlier today, I could SSH via WSL but not from the host OS even though they were both using keys served from the Windows OpenSSH agent! I'm just going to blame this service outage and hope for the best tomorrow.


Same - but created new keys :) ... which also didn't work, and then I went to check... oh well.


Sold to CNN in 2016 for $US25M


I have this pinned and read it like once a month just as a refresher to not let it get that far

https://robinrendle.com/notes/take-a-break-you-idiot/


Surely in 2024 we can't be classifying Stripe as just "a payment service"


What else have they done that's worth giving a shit about?


That would be because their goal is tooling and not to be a framework? Bun is the worst example here cause it's literally now a runtime for Javascript! If rewriting all the Node APIs, directly executing TS files etc. isn't pushing a "paradigm" I don't know what is.


Small website bug, hovering over Make.com in the integrations tab on the homepage shows the link and icon for Zapier. Congrats on the launch!


Ah thanks! In the middle of publishing that integration :-) We'll get that fixed.


Like most technologies it depends on how you're using it. When I first starting working in GraphQL, paired with a React frontend I used it in an a similar way to REST, pull the data and then do all the logic of what to display on the frontend.

For me I saw the most benefit when I used the schema to define what to display in the frontend, all the logic of what to display is done on the server and my frontend just becomes simple components that render the pulled schema.


I didn't fully understand what your meant (as I haven't used graphql much), so I asked ChatGPT to explain. It did a decent job, so I figure the answer might help others as well: https://chat.openai.com/share/d708cc93-e920-4b83-b372-83248e...


This seems completely backwards and contradictory to me:

""' Let's return to the user profile example. With GraphQL, instead of the frontend deciding what user data to display and where, this decision-making process can be moved to the server. When the GraphQL server receives a request for user data, the request includes specific fields that the frontend wants. In response, the server sends back exactly what was requested - no more, no less. """

First, it says that the server, instead of the FE decides. Immediately after, it says that "the request includes specific fields that the frontend wants".

If the request specifies the particular fields it wants, then it is the FE deciding what data to display...

So I think ChatGPT has this totally wrong. I'd love to be corrected here, but my understanding is that a (perceived) problem with REST, or at least the way it's used, is that the backend often requires specialized endpoint that anticipate the needs of a particular frontend context. In that sense, they are tightly coupled. This happens because, in order to avoid having to execute dozens of requests in order to fetch the data needed on a particular page or screen, you write some endpoint that is intended, from the outset, for a particular UI in the client app. You also have the opposite problem where an endpoint returns far more data than the client cares about in certain spots. Enter GraphQL: since the client queries for what it needs, it can specify precisely what it wants, ranging from a single nested field to a much more complicated object.

Note: I'm not judging the merits of this GQL pitch. I'm just saying that's the argument, as I've understood it. That being the case, not only is ChatGPT contradictory in the above cited section, but it also has the whole argument backwards.

As always, very glad to be corrected on any of this.


Yeah I had a similar reaction to yh first response. But after I asked a follow up 'But the frontend is still deciding what data to ask for', it gave me a better explanation and then an example.

That final part made it clear to me (assuming it's not a hallucination!).


Huh. I'll read again and closer. I still think it may very well be wrong hah. This is a funny feeling when examining a ChatGPT response closely...you don't know if it's futile because it really just wrong or if there's more there. Maybe I'll continue the conversation with it to tease this out some more. Glad you shared the chat.


the server decides what's on the menu.

the client picks items from the menu

the server sends back exactly those items.

in REST, the server sends all of the items on the menu! as a result you end up creating many different menus.


I'll flesh out my comment a bit more with a small example of what I mean.

We have an inbox list that is a combination of three different entities (direct message, job request, support message), we display all of these in a unified inbox, rather than pulling all the data with REST and sorting through what fields to use to display as a title and what status maps to which styling/label etc. I can just use my InboxPageQuery and render exactly what it tells me to, being able to build or change entire pages just by pushing new server code really helps with speeding up our dev time.

  {
    "data": {
      "inbox": {
        ...
        "inboxItems": [
          {
            ...
            "subtitle1": {
              "__typename": "InboxStandardText",
              "accessibilityText": "Hi Jordan.\n\nSarah has posted a handyman job near you",
              "components": [
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": "Hi Jordan.\n\nSarah has posted a handyman job near you...",
                  "type": null
                }
              ]
            },
            "subtitle2": {
              "__typename": "InboxStandardText",
              "accessibilityText": "You declined this job today",
              "components": [
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": "Declined",
                  "type": "errored_text"
                },
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": " · ",
                  "type": "errored_text"
                },
                {
                  "__typename": "InboxStandardTextComponent",
                  "text": "07/06/23",
                  "type": "errored_text"
                }
              ]
            },
            ...
          }
        ],
        ...
      }
    }
  }


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: