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.
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.
>> a smaller image often reduces the potential attack surface because vulnerable things just aren't there
By the way, the article proposes blind download of artifacts from someplace on the internet, on every build. Not only that can cripple your builds when the source is down (which happens all the time), it can (and that has happened) send you arbitrary infected crap instead of what you wanted.
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.
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.