HN user

kossae

451 karma

[ my public key: https://keybase.io/kossae; my proof: https://keybase.io/kossae/sigs/nsw7bk2VQ0VQUK5UIo-RVd4_OfvZAYUfG_usv-Yp7zM ]

Posts10
Comments139
View on HN

The point on investment is apt. Even if they achieve twice as much as they’re able to today (some doubts amongst experts here), when the VC funding dries up we’ve seen what happens. It’s time to pay the piper. The prices rise to Enterprise-plan amounts, and companies start making much more real ROI decisions on these tools past the hype bubble. Will be interesting to see how that angle plays out. I’m no denier nor booster, but in the capitalist society these things inevitably balance out.

I still don't understand how, with a properly configured debugger, manually typing print statements is better than clicking a breakpoint at the spot you were going to print. Context overload might be an issue, but just add a 'watch' to the things you care about and focus there.

This is my experience as well, and for now comes down to a workflow optimization. As I feel the LLM getting off track, I start a brand new session with useful previous context pasted in from my previous session. This seems to help steer it back to a decent solution, but agreed it would be nice if this was more automated based off of user/automated feedback (broken unit test, "this doesn't work", etc.)

Yeah I made a decent effort to dig in, as it seemed interesting, but I still have no idea what this is.

On the hiring side of this, we receive a _ton_ of resumes that have no experience in the technologies we're hiring for. Each day there are 5-10 automated resume submissions to our job portal for a single position, and we're a fairly small company. Perhaps hiring managers are both being (more) selective and becoming overloaded with the amount of AI/recruiter-sanitized resumes coming in as well.

I assume this would be more complex than that. Logging (storing personal data), ad revenue from viewers in TX, etc could easily make this a much larger task than the revenue is worth. Even if those were done, you’re then serving content to an entire state completely for free, which makes no business sense.

I’m actually in the same boat right now (primary DB -> Clickhouse). We’re currently trialing Airbyte but it appears they’re removing normalization support for Clickhouse this year. Did you land on a custom solution, or some other ETL/ELT tool?

To mitigate this, I usually always require a .env file for docker-compose containing directories with at minimum a `COMPOSE_PROJECT_NAME` envvar to prevent these naming issues. As long as the env file travels with the directory there are no issues.

Not sure about the original poster specifically, but when I had a herniated disk the two movements that helped the most (and I still perform along with others to this day) were:

- Prone Press Up (https://www.youtube.com/watch?v=Sws_GwrlYO0): Relieves tension in lower back, pressing discs back towards their natural position.

- Banded Hamstring Stretches (https://www.youtube.com/watch?v=msxQR56U7sI): You can use a belt for this if you don't have the bands, but properly and consistently stretching my hamstrings was the biggest thing I did to relieve (and 'cure') my back pain after the herniation.

No More Google 6 years ago

I can highly recommend FastMail. This is the exact scenario I was in, and it has performed far better than Gmail in almost every aspect.

I've been making music for close to 20 years now, and haven't retained a single piece of 'proper music theory', including names of the chords or notes I play. I've been in countless bands across genres, released albums with multiple artists as a producer, and have placed with major record label artists. Every time I try to 'study music' I feel boxed in creatively, and not knowing these concepts has not once hindered my ability to play music collaboratively or create it independently. What exactly can I not accomplish by not knowing a scale, again?

If you have more than one developer working on different features, it’s inevitable they’re going to need different data. Unless you have a tight feedback loop between frontend and backend devs, you’re going to end up with pending unresolved issues requesting they add another field to be returned on a specific, custom “rest-like” endpoint. If you instead put the onus on the frontend to allow arbitrary field requests (of course within limits, typed and auth’d), this is no longer an issue. Of course the api has to have a schema defined, so there could be a request for a new field to be added there. But if all your endpoint returns is what we need NOW, then you will inevitably have to add more data to the endpoints later with new features. This isn’t of course the only benefit of GraphQL, but it’s certainly a nice convenience for those having to make those requests.

The idea is that you can select the exact data fields you need for your UI. In a traditional REST-like response, say for a User model, you may receive all data (within authorization limits) about the user in the response when all you needed was the first_name field. With GraphQL you would just receive first_name without the rest of the unneeded fields, thus reducing the amount of data sent.