dcherman

You need to define how much muscle mass you expect to lose. The entire idea behind the bulk/cut cycle is that you want to net gain muscle after a full diet cycle.

It's also not borderline impossible to maintain the majority of your muscle mass, but it depends on how you eat and train. We don't know enough about the person above's diet, training, current body composition, etc. to say anything for certain.

I think the gist of what we're debating is principle of least privilege - give the LLM the fewest privileges needed to accomplish the task and no more, that way you avoid issues like leaking credentials.

The approach you're proposing is that with a well designed MCP server, you can limit the permissions for your agent to only interacting with that MCP server, essentially limiting what it can do.

My argument is that you can accomplish the identical thing with an agent by limiting access to only invoking a specific CLI tool, and nothing more.

Both of our approaches accomplish the same thing. I'm just arguing that an MCP server is not required to accomplish it.

You can make the identical argument for the CLI tool. Allow kubectl, deny everything else.

The same permissions model that works for other tools. In Claude Code terms, allow Bash(kubectl:*). Deny Read(**/.kube/**). That allows kubectl access without allowing the tool to read ~/.kube directly.

Your argument is the same for an MCP server - auth is stored somewhere on disk, what's to stop it from reading that file? The answer is the same as above.

How so? Let's use a common CLI tool as an example - kubectl. Config is generally stored in ~/.kube in a variety of config files. Running `kubectl config view` already redacts the auth information from the config. LLMs could invoke `kubectl` commands without having knowledge of how it's authenticated.

Can't recall if I played on your servers, but I know I played an unreasonable amount of CS 1.6, including on a bunch of WC3 servers when I wasn't playing on ESEA.

If you happen to remember someone going by `nJs` - hi!

Adjusted for inflation?

The point about coverage results is an important one to understand. Something that I like to say when discussing this with other folks is that while high code coverage does not tell you that you have a good test suite, low code coverage does tell you that you have a poor one. It's one metric amongst many that should be used to measure your code quality, it's not the end-all-be-all.

There's another alternative - debug in CI itself. There's a few ways that you can pause your CI at a specific step and get a shell to do some debugging, usually via SSH. I've found that to be the most useful.

I generally would agree, but be careful. You don't know what you don't know, and that could be dangerous. As one example, I would guess that the vast majority of folks are not familiar with what an MWBC is and how they work, however they're extremely common, especially in older buildings. As another example, most folks have never heard of box fill and will just try to shove wires into a box until it fits.

I'm not an electrician and would definitely encourage folks to learn to do this work themselves, but be careful and if you encounter something that is not familiar, pause and learn until you understand what you're looking at, even if that means putting it back the way it was for a bit and doing some research.

You can also use a deploy key. That's how I do it while avoiding adding a PAT to a shared repo

Random aside, were you at KubeCon a couple years ago chatting with Sugu at the whole conference party in San Diegi? If so, hi! I was crazy out of my depth, but listening to folks that know this stuff better than I ever will was one of the highlights of that conference

Agreed, was typing a similar comment, however yours expressed that idea better than mine.

Consider that this pattern contains N different properties that renders N different components (plus the default case), I don't know why you would want to put this into one component rather than having the consumer select the right one themselves. This even introduces the possibility of bugs - what happens if a consumer passes two sets of properties (which admittedly could be somewhat prevented by Typescript)? I don't really see the benefits of this approach for this particular example.

Not only that, but it really illustrates that even well-known, famous engineers can start contributing to a project with simple pull requests that just rename variables or add comments to code for clarity.

Not every pull request needs to be introducing complex/intricate code, and yet it still has value to the project (and the community).

It's not just the raw size of the image, but also about what the image includes; a smaller image often reduces the potential attack surface because vulnerable things just aren't there.

That's one of the major rationales behind the distroless images. Being space optimized is just a really nice side effect.

I agree. While you can accomplish some really interesting things with Proxy, I think that this article presents some poor examples that are actively harmful. I don't expect `delete` to be O(N) (actually worse if you consider the `ownKeys` implementation. I don't expect setting a property (sort) to invoke an expensive sorting operation. The list keeps going.

While I appreciate what the author is trying to accomplish, I think this is an example of what not to do as far as code is concerned.

Most of my practical usage of Proxies to date have been limited to some debugging tools that I wrote for AngularJS to help detect property changes that occur outside of a digest cycle. Don't think I've had any use cases that I've shipped to production code yet, though I believe Vue is considering using proxies for their reactivity model in the future to avoid the need for `Vue.get` and `Vue.set` for previous unknown properties or deletions.

What you're saying is that comparing the existing build time to the new one, the existing one is about 70% slower. You can also phrase it as comparing the new build time to the existing one, it's about 42% faster.

Both are true statements, however people generally like to discuss how much improved the new releases are versus how much worse the old ones are.

Fun fact, it's important to understand that relationship in other areas as well like the stock market; if your holdings lose 50% of their value, they then need to increase by 100% for you to be back neutral :)

This right here is why I'm a large proponent of using ML/AI for computer assisted diagnosis. Unlike a doctor, a computer won't forget about a possible diagnosis.

I'm not saying to replace doctors with ML, but it seems like a great opportunity to provide a list of potential illnesses with associated confidence %s for the doctor to then follow up as potential leads.

Absolutely! I come from a historically Microsoft shop, and the lack of this was by far the biggest barrier when initially learning PostgresSQL since I was still in the mindset of designing stuff as I would in Sql Server.

So do you not have automated tests that run cross browser? If so, what's your method for doing so?

So what do you think your result variable contains in the event that the promise is rejected? Is this semantically equivalent to try/catch?

Hah, was just talking about this a few days ago. I was at work, maybe around 24-25 years old, and couldn't figure out why all of the supposedly high def screens in our conference rooms were so bad, but I could still read them without a ton of difficulty. Was driving home and realized I could no longer comfortably read the license plate of the car in front of me, then it dawned on me what was going on.

Define expensive. 200$? That's the cost of the plumber's time, and now I've got that tool forever. That and I've gained knowledge and know how to fix or build something that I didn't before which is something I take pride in.

In my experience, there's been very few things where it makes more sense long term to just pay someone else to do it so long as you're willing to do a little bit of learning.

They did, but quite honestly they should have just renamed the framework; Angular 1->2 is less of an upgrade and more of a completely new framework that happens to share the same name. It was a mistake imo, but one they made because Angular is a household name amongst web devs.

From what I understand, they've done a better job from Angular 2-5.

This post is entirely going to be based on questions that I would expect an experienced developer that I was interviewing to be able to have a conversation on. This is not a starting point for a beginner.

Understand the language and how it works on a deep level. If there's ever a question of "should this work?", read the spec for that feature - it's generally not that hard to understand.

Understand the runtime. What is an event loop? What's a macro task? A micro task? How does each work? How does all of this integrate with the DOM as far as what might cause a dropped frame, block rendering, etc..?

Understand the ideas behind the framework you're using. I'm not going to recommend an individual one to avoid framework wars, but most of them embrace virtual dom these days, so you should have a basic concept of what that is. Does it make applications faster? Does it make it developing easier?. Another common framework point is unidirectional data flow; why is unidirectional data flow considered a good thing these days? What were the downfalls of bidirectional data flow?

Understand API design and state boundaries. Using the example of a shopping cart, who owns what? Where is the state of the cart stored? An individual item price? Name? How do I add an item to the cart? You can design a cart that functions fantastically, but is completely un-testable if the API is designed wrong or there is not well defined boundaries on what components own what state.

That's a few things off the top of my head.

I've also never found TDD to really be very beneficial except for all but the most trivial utility libraries.

Most of the time, I have an idea of where I want to go, but not necessarily exactly what my interface will look like. Writing tests beforehand seems to never work our since nearly always, then will be some requirement or change that I decide to make that'd necessitate re-writing the test anyway, so why write it to begin with?

The extent of my tests beforehand these days (if I write any before code) are generally in the form of (in jasmine.js terms)

it('should behave this particular way', function() { fail(); });

Basically serving as a glorified checklist of thoughts I had beforehand, but that's no more beneficial to me than just whiteboarding it or a piece of paper.

That said, all of my projects eventually contain unit tests and if necessary integration tests, I just never try to write them beforehand.

UBI does not work mathematically. I posted this a while back, so I'm just copying and pasting from an older response:

Simple back of the napkin math is that based on the 2013 census, we have 242,470,820 adults living in the US. If we pay each of them $12,000 per year, that's $2,909,649,840,000 in additional mandatory spending every single year. That's more than Medicare and Social security combined, and that has no cost of living adjustments built in. The basic math shows that this idea is simply unrealistic as far as I can tell.

UBI in the amount that could be considered a basic living income is infeasible with the current state of the world even if you were to double the tax rates as I would imagine most people in the US can't live on 12K and still be able to have the day to day basics required for living.

Nope! You'd be surprised who it might affect. Families with a few kids (lots of tax credits rather than deductions) that own their own home and have a decent salary could potentially owe the AMT.

If you make more than the exemption amount for your category (between 40-85K or so depending on your situation and tax year), then you should be calculating the AMT to determine whether or not you owe. It affects more people than you might think, even if it just requires the calculation to occur to see if you owe it or not.

The AMT calculation is tedious as hell. Considering that the yearly cost for H&R Block is something like 20$, it's well worth the money just to avoid needing to do that by hand, and that's not even taking into account all of the other time savings features of it. And the cost for the software itself is tax deductible as tax prep costs.

Then you're shipping the entire (or at least large pieces of) language runtime to the client since presumably, you'd need to compile that to WASM as well.