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.

To add to what others mentioned, there’s also https://github.com/livebook-dev/pythonx which embeds a Python interpreter into your elixir program.

> People get distracted by the idea of pure capability systems. See the thread above. Pure caps don't work, …

I’m one of those “distracted” people who has never gone far enough with a capabilities-based language to figure out why they don’t work.

I read a lot about E and tinkered with Pony, and it seems that the biggest barrier is bootstrapping/network effects (e.g. lack of available libraries & expertise) rather than something intrinsic to a capabilities oriented security model.

In contrast, I only just learned about Javas SecurityManager from an earlier comment on this post. Reading the documentation at https://docs.oracle.com/javase/8/docs/api/java/lang/Security... leaves me with an impression of more complexity for integrators (as you noted) and a need for vigilance at system boundaries by runtime implementors. Building on reference capabilities seems much much simpler, but maybe that’s just my lack of experience ?

> There are some conceptual and social difficulties with this kind of security, at some point I should write about them.

I guess my comment is a long way of saying: please do!

That’s exactly what the GP wrote: The Goal is the spiritual ancestor of The Phoenix Project.

Yes, sorry for the rather pithy response, but separating out the "what changes" vs. "what doesn't" (config vs. code in your terms) is what makes these things possible.

As you also noted, doing this in plain terraform is kind of a pain, so using a tool like Hiera allows you to skip a lot of the work involved in doing it the "right" way. IMO if you're starting greenfield Pulumi (or CDK, anything that lets you use a "real" programming language) allows you to write (or consume!) that config in basically any form, instead of needing to funnel everything through a Terraform data provider.

In pulumi

     regions = [
       “eu-west-1”,
    +  “eu-west-2”,
     ]

     for region in regions:
         …

> how long until someone gets tired of "extra work" and comes up with "responsive PDFs"?

I hate to break it to you but, https://blog.developer.adobe.com/adobe-sensei-makes-responsi...

This is not at all an accurate description of the compiler work.

I think it’s worth also quoting the rule that the dissenting programmer objected to.

> One of the solutions was to introduce a rule to memoize everything returned by hooks, to automatically prevent future problems with memoization.

… which introduces a systemic performance penalty to prevent outlier performance problems.

The article argues against “heroes”, but I think the more appropriate term is “experts”.

The ruby-lsp project made by Shopify has (or had...) a rails plugin that worked this way. It adds some routes to your server during development and uses them to introspect the running process.

> No one is telling anyone that they are a bad person for voting "someone else".

> If you vote for these people, then yes, you are a bad person

As a foreigner living in Germany, it’s been incredibly disheartening to become more aware of the level of political discourse here. AfD will continue making huge gains (which I’m absolutely worried about) as long as their opponents continue to reason like toddlers.

I unfortunately can’t remember the project, but I’ve seen one take the opposite approach: tagged (& supported) releases are for passing customers only, and everybody else can just follow HEAD.

That file (and entire directory) doesn't seem to exist on my system

Not the poster you're replying to, but when it comes to deploying your own applications: generating Kubernetes manifests with whatever language you're already using and feeding JSON to `kubectl apply -f -` can accomplish the same outcome with less effort.

Helm is still useful for consuming 3rd party charts, but IMO it's status as the "default" is more due to inertia more than good design.

> You can also select a bunch of chats in a thread and fork them into a new thread. We'd maintain links between threads. Coming soon.

Just want to chime in and say this is an essential feature IMO, I hope it’s prioritized.

Others have mentioned CDK, but I want to say that this is almost the exact approach I took on a project recently and it worked out fine. Node script that validates a few arguments and generates k8s manifests as JSON to be fed into `kubectl apply`.

IME, here's no need to involve anything more complicated if your deployment can be described solely as k8s manifests.

Removing the big words from English is encouraged in most business communication. I think both losses are a shame, but they are conscious decisions made by people optimizing for certain outcomes.

Another choice quote from the fine article:

> One largely unappreciated aspect of Scrum is the interchangeable nature of team members.

No chance, "lol" has been in usage for at least 25 years, possibly more than 30.

> If you wanted to actually solve theming, what you should work for is not a constrained helper function like light-dark(), but instead a shared token schema. Today nearly every company has their own token schema and different ways of naming things in the semantic token layer. If we had a shard language here, not only would it be trivial to add light/dark theming (just redefine a few variables that are already provided for you), code could be shared between sites and inherit the theming/branding.

Isn't that the idea behind https://open-props.style/ (and https://theme-ui.com/ in JS land)?

I think it's a great idea, but hampered by the lack of adoption incentives for the very people that need to adopt it for it to become successful (design system/component library authors). It introduces constraints, but the promised interoperability is not really beneficial to the people who need to work within those constraints.