trevor-e

Not trying to sound alarmist at all but I am wondering if ultrasounds are safe to be used like this? My understanding is it's basically a high-frequency sound wave which is probably fine for most tissue usage, however here it says it's scattering off of red blood cells. I don't know why that feels so unsettling to me.

it specifically addresses this in the "The escape hatch" section...

What an ordeal, this stuff really scares me, like the post about the Gitlab founder having to diagnose and treat himself. Great to hear you are recovering. If you find yourself in Cambridge I will gladly buy you a beer for how much rg has helped me.

This looks pretty neat and the anti-AI hate in here is getting pretty tiresome.

From what I can tell looking at the codebase compared to Django's, the top-level modules are structured much better and more obvious for AI to discover them. And then inside each module is a descriptive README with lots of description and examples that are helpful to an agent (and human). Not sure why this is being written off as slop or arbitrary changes, it seems pretty obvious to me this is the direction of frameworks.

Right, and I agree with all of that, but that's not related to my point.

You are saying "if you leave the AI attribution in the PR/commit description, it HAS to be a slop PR that was not reviewed by a human beforehand". And I'm saying that's not true at all and you shouldn't assume that.

These are odd takes to me.

was submitted by someone so lazy they couldn’t even edit the commit message. You can see the vibe coded PRs right away.

As others mentioned, this is very intentional for me now as I use agents. It has nothing to do with laziness, I'm not sure why you would think that? I assume vibe coded PRs are easy enough to spot by the contents alone.

I would like to know when someone is trying to have the tool do all of their work for them.

What makes you think the LLM is doing _all_ of the work? Is it really an impossibility that an agent does 75% of the work and then a responsible human reviews the code and makes tweaks before opening a PR?

I heard about how beautiful it is

This used to be the case around Swift 4, but since then they've added so many features and keywords to the language. Now the simplicity and elegance is gone.

Also it seems like there was a marked change in the culture of Swift. It somehow attracted a lot of the "ackchyually" crowd which resulted in a lot of massively complicated features. I liked to occasionally browse the evolution docs and they got more and more complex over time.

Flutter still doesn't support liquid glass on iOS so it doesn't seem like a serious contender to me at this point. And due to the nature of how Flutter is implemented, it's going to continuously be an uphill battle. Maybe it's fine if you intend on having a completely custom UI and don't care about platform look and feel.

There are a couple issues with that definition: - quality is not always correlated with "cheaply made en-masse" - actual slop, assuming you are talking about the food, is more about preventing food waste although it happens to also be cheap.

I'm being pedantic AF because most people refer to AI slop as "low-quality or careless work". And AI is just a tool so it's possible to spend a lot of time making something of high quality with it. I get the outrage with respect to copyright and artist rights, but it certainly doesn't look like slop to me.

Is it slop if enough people enjoyed it to be on the top charts?

telkins.com

I have an endless list of blog posts to write and so little time :(

I'm dealing with a severe health ailment with my cat right now and ChatGPT has been pretty invaluable in helping us understand what's going on. We've been keeping our own detailed medical log that I paste in with the lab and radiology results and it gives pretty good responses on everything so far. Of course I'm treating the results skeptically but so far it has been helpful and kept us more informed on what's going on. We've found it works best if you give it the raw facts and lab results.

The main issue is that medicine and diseases come with so many "it depends" and caveats. Like right now my cat won't eat anything, is it because of nausea from the underlying disease, from the recent stress she's been through, from the bad reaction to the medicine she really doesn't like, from her low potassium levels, something else, all of the above? It's hard to say since all of those things mention "may cause nausea and loss of appetite". But to be fair, even the human vets are making their own educated guesses.

Yep, localization is a huge size bloat for enterprisey apps that support many locales. There is no Apple provided way to dynamically download select localization packs based on the device locale. Meta came up with their own solution: https://engineering.fb.com/2022/05/09/android/language-packs...

The small filesize issue is something we commonly see in games, was surprised to see it for Gmail.

And btw we open-sourced much of our analysis after being acquired by Sentry: https://github.com/getsentry/launchpad

Not sure if this is quite what you are getting at, but the SQLite folks even mention this as a great use-case: https://www.sqlite.org/appfileformat.html

I agree, latency is very important and 300 pops is great, but seems more for marketing and would see diminishing returns for the majority of applications.

Good luck getting 100+ devs to all use the same logical commit style. And if tests fail in CI you get the inevitable "fix tests" commit in the branch, which now spams your main branch more than the meaningful changes. You could rebase the history by hand, but what's the point? You'd have to force push anyway. Squashing is the only practical method of clean history for large orgs.

Thanks for sharing, that is a neat in-between.

The treemap screenshot doesn't look correct. Nearly all charting libs (like Apache Echarts) will group nodes with a heading name, so not sure why they claim it would be hard to notice the "drivers" node. I guess in that screenshot, sure, but that looks like just a bad implementation of a treemap. Maybe this was the case back in 2017?

Flame graphs I have a love/hate relationship with. The hierarchy is very useful, but the name and coloring can be very confusing and misleading. Most people I show them to think red == something bad, but the color is actually just for aesthetics.

Yea looks like Chrome ships a universal binary with both x86_64 and arm64.

This was the same epiphany I had in college when I learned how to actually study. Previously I would try to go fast and cram as much as possible into my head and hope my decent memory could save me. That only got me so far. I eventually realized that slowing down to fully comprehend what I was learning before allowing myself to move on yielded much better results and saved a lot more time in the long run. And as a result my grades shot up.

Yea that was my thought too. I like the idea in principle, but these magic thresholds can really bite you. It claims to be P(99), probably off some historical measurement, but that's only true if it's dynamically changing. Maybe this could periodically query the OTEL provider for the real number to at least limit the time window of something bad happening.

What I’m unsure about is whether diff-only context is actually sufficient for meaningful reviews, or if this becomes misleading without deeper repo and architectural awareness.

The results of a diff-only review won't be very good. The good AI reviewers have ways to index your codebase and use tool searches to add more relevant context to the review prompt. Like some of them have definitely flagged legit bugs in review that were not apparent from the diff alone. And that makes a lot of sense because the best human reviewers tend to have a lot of knowledge about the codebase, like "you should use X helper function in Y file that already solves this".

Sorry I wrote that hastily and my wording seems to have caused much confusion. Here's a rewrite:

The job is to help the business solve a problem, not just to ship code. In cases where delivering code actually makes sense, then yeah you should absolutely be able to prove it works and meets the requirements like the OP says. But there are plenty of cases where writing code at all is the wrong solution, and that’s an important distinction I didn’t really understand until later in my career.

Although funnily enough, the meaning you interpreted also has its own merit. Like other commenters have mentioned, there's always a cost tradeoff to evaluate. Some projects can absolutely cut corners to, say, ship faster to validate some result or gain users.

No, what I meant is sometimes the solution is not delivering any code at all.

Many times in my career, after understanding the problem at hand and who initiated it, I realized the solution is actually one of:

1) a people/organizational problem, not technical 2) doesn't make sense to code a complicated system when it could be a simple Google Sheet 3) the person actually has a completely different problem 4) we already have a solution they didn't know about

My issue with the OP is that it highly emphasizes delivering code. We are not meant to be code monkeys, we are solving problems at the end of the day. Many people I've met throughout my career forget that and immediately jump into writing code because they think that's their job.

Your job is to deliver code you have proven to work.

Strong disagree here, your job is to deliver solutions that help the business solve a problem. In _most_ cases that means delivering code that you should be able to confidently prove satisfies the requirements like the OP mentioned, but I think this is an important nitpick distinction I didn't understand until later on in my career.

Very neat, thanks for explaining. The only drawback I've seen in the past with apps using .NET is the binaries end up pretty huge due to the runtime. I'm assuming that's still the case here? I wouldn't be surprised if this is also an issue with Swift for Android but I haven't looked yet.

Yes it uses native UI by wrapping the underlying frameworks, but that still means there is a layer in between that has to be updated with fixes and new features. Every RN project I've tried in the past turned into a dependency mess since you find edge cases that are not supported by the framework.

It's definitely gotten better like you said but I just prefer to work with the native platform code even if it's a bit of extra effort.

OTA updates are definitely nice to have and I'm surprised there's not a way to do so with native iOS since RN and Flutter already support it. Technically it is possible with dynamic frameworks.

In practice though it's somewhat easy to workaround the lack of OTA with dynamic server configuration for clients.

Xamarin with .NET and MvvmCross falls into the same bucket as RN and Flutter IMO, unless something changed since the last time I looked.

Very excited to see this as an official project!

I've been toying around with multiplatform frameworks like RN and Flutter for a side project of mine but they never feel right. I'd rather use the native UI per platform and have a nice way to share business logic. KMP exists but I think for most developers wanting to build an app it's more common to build for iOS first, and then port to Android later if the app gets traction. With a little foresight of keeping shared code in a Swift Package, it seems like that's getting more and more possible which is great to see.