grncdr

> Git reads that setting from the repository's own .git/config. So a repository can ship this:

Followed by:

> Delivery is worth being precise about, because git never carries this. Cloning a hostile URL does nothing, and neither does fetch or pull.

AI slop nothing burger. The “exploit” has nothing to do with coding agents.

Pretty simple really: do the ads for the frying pan make the direct claim that the pan will put you on the path to becoming highly paid chef? Perhap opening a Michelin-starred restaurant with the skills your new pan has unlocked?

"you can cook better food" and "you can drastically improve your economic situation" are two very different promises (or implications) that should be held to very different standards.

I think the idea is that dedicated security firms and/or automated scanners will discover exploits in the cooldown period.

I was investigating that for entirely unrelated reasons just yesterday and the answer so far seems to be "none". You can patch the server to serve the locally built frontend and it all works just fine.

> rails 1 codebase to rails 8

A bit off topic, but Rails *1* ? I hope this was an internal app and not on the public internet somewhere …

I believe it’s slightly different in that I can declare a value (or parameter) of type T and know that it can’t be null/invalid.

Consider this Java method:

    void frobnicate(bar Bar)
    {
        // is bar null? Who knows?
    }

To get the same behavior in Helix, one would have to declare the parameter type as “Bar?”. If the parameter type is plain “Bar”, callers can still pass you a “Bar?”, but presumably you’d get an NPE at the call site and not somewhere further down the stack.

I’ve never heard of this language before today and don’t have an opinion on it, but I do find the Questionable Types interesting: sort of collapsing Option and Result into one very concise notation.

Ah that’s great. I simply hadn’t read the docs that far

One simple idea* would be an option to exclude certain React elements from auto translation. That would allow users to handle these specific cases “manually” while still reaping the benefits of the automated system the other 99% of the time.

* worth exactly what you paid for it ;)

It’s an interesting idea, but how would such a system handle queries that should cross tenant boundaries? (E.g. system-level reporting)

> Since XHP executes on a server that emits HTML, the most that you can do relatively seamlessly is to replace parts of an existing markup with the newly generated HTML markup from the server by updating innerHTML of some DOM node.

It’s a very long post so maybe I missed it, but does Dan ever address morphdom and its descendants? I feel like that’s a very relevant point in the design space explored in the article.

I’m curious, are you running GoodJob in the same database as the application? For smaller scale stuff this is super convenient, but I wonder if it will become a problem at higher loads.

> If you have a single page front end setup, and a "RESTful" backend

Rails really doesn't encourage this architecture, quite the opposite in fact.

> designers and users of the applications I have been building for years never want just one model on the screen.

... and this is where Rails excels. When you need to pull in some more data for a screen you just do it. Need to show the most recent reviews of a product in your e-commerce backend? It's probably as simple as:

    <%= render @product.reviews.order(created_at: :desc).limit(5) %>

Of course this can have the opposite problem of bloated views taking forever to load, but Rails has lots of caching goodies to mitigate that.

---

Going back to the GP post

> Rails feels like it _prefers_ you build "1 model = 1 concept = 1 REST entity"

That's definitely the simple path, but there are very few constraints on what you can do.