thatswrong0

Ah yes, the casual defense of cultural genocide based on the fact that other governments have done bad things too.

And seriously, when tf did criticizing the obviously malicious actions of a government become racist.

I cannot fathom how dysfunctional Rockstar must be that this slipped through the cracks for so long given the fact that GTA Online is Rockstar’s cash cow.

6 minutes is insanity and must have turned off so many people from playing.. this person deserved far more than $10k

Yeah the touchbar needs to stay dead.. hopefully this isn't it rising from the dead.

Insanity. How on earth can anyone, let alone a judge with a law degree, think that this is at all reasonable (precedent or not). California really needs to clean house and get some fresh perspective in its legal system. Sidenote: I really do wish the US followed the doctrine of abiding by the "spirit of the law" rather than the "letter of the law" in trivial civil determinations such as this.

Right - the former case is one that’s unavoidable and, in the case the first developer didn’t get it quite right, should ideally be covered by code review, but doing a good code review is IMO pretty hard, and giving that sort of feedback requires that the reviewer also understands the problems at hand (which in our case is frequently not the case as our development teams are small and we’ll often have a backend focused dev reviewing another backend focused dev’s frontend work).

And in the latter case, at least in my organization, we don’t often have hard “must meet” deadlines, but instead have more self-imposed deadlines that become externalized and concrete when these “deadlines” (aka ship date estimates) are communicated org wide.

So all I can figure to do is give zoom talks, write documentation that’s shared to all developers, and try to encourage coworkers to take the opportunity to push soft deadlines back if needed to pay down tech debt.

This is probably a bit of an aside to the implied problem at hand but.. considering this from the React side of my company's codebase, I wish this question was at least kept softly in mind when designing components. I frequently encounter components that were very clearly created as "one-shot"s that are then unfortunately extended by piling on more props and conditional behavior by the next developers who need something like the current component but ever so slightly different.

Often the solution initially would have been to separate out the presentation side of the component from the behavioral wrapper that chooses what data needs to be shown / what actions are performed by interactions. By the time the component arrives at my lap (because I too need something same same but different), however, it has become a monstrosity that can take a long time to disentangle via ADD (anger driven development).

I think asking oneself a simple question such as "how would someone make this search box work with a different data source?" would probably result in components that are decomposed into simpler, smaller parts that allow for much easier reuse and adaptation.

On the flip side, I'm also of the belief that the second developer to touch a component is necessarily better equipped to answer that question, so the onus should probably be on them to make the proper generalizing changes.

(I'm still trying to figure out how to write a document that expresses this idea more concretely to my coworkers because it often isn't quite this simple..)

¯\_(ツ)_/¯

A sitting president with millions of followers has a lot more power to create actual harm via some random tweet than some random teenager with 3 followers. How is this not obvious?

Ew.

I didn't get that desire for purity that you gleaned from it.

The fact is that (as the author pointed out) Golang is missing basic language features that other languages have adopted since the creation of C that eliminate whole classes of errors, and it's pretty easy to accidentally do the wrong thing as a result.

Nil pointer exceptions, for example, don't have to exist anymore.. and yet they do in Go because they couldn't be bothered to add sum types. Its type system is barely a step above a dynamic language. You have to write the same imperative looping code over and over because Rob Pike would rather just use a for loop than something mildly expressive like map or filter (https://github.com/robpike/filter). Every function that does meaningful work is littered with if err != nil { return err }. Etc.

It is easy to write code in Go, but IMO it's not easy to write and maintain a production grade system with any amount of complexity in Go because you _have_ to be careful, you can't encode invariants explicitly and let the compiler find problems for you, and you have to repeat yourself so often.

(Gross oversimplification but..) One seemingly innocuous bug deep in the encryption "library", that no letter could map to itself, plus a bit of social "engineering" in taking advantage of the fact that messages often included the same text (e.g. "heil hitler") often in the same position, with a smattering of German complacency and arrogance assuming that their machine was uncrackable.

Pretty funny that the lessons learned here are still relevant to this day.

All I'm gleaning here is that trying to generalize the experiences and preferences of 400+ million people between the U.S. and Canada isn't a particularly useful exercise. Beyond what country / state / county you're in, I have to imagine that age, race, socioeconomic status, general social preferences, and probably a whole other slew of factors play a significant role in how often people experience religion being thrust upon them in.

Not to say that this is necessarily a useless conversation, but it feels odd to me considering many dang people there are.

Spectacle is a must have IMO.

I set mine up to be Shift+Ctrl+(QWE/ASD/ZXC).. where Q/E/Z/C are for the corners, A/D left and right halves, W/X for top and bottom halves, then S in the middle for full screen. The mnemonic of the "box" formed by those keys on the keyboard is easier for me to remember.

Disagree. CGI is getting "easier" in the sense that even low budget films can do things that used to only be reserved for large budgets. And there's so much CGI in use that you don't notice these days because it's so seamless / not the center of attention (e.g. check out this before/after about Wolf of Wall Street: https://www.youtube.com/watch?v=bP2sJqoZD7g).

But at the end of the day, you still need good direction and editing that involves understanding the limitations of doing things on the computer vs. in camera. I think this video about Dune provides great examples: https://www.youtube.com/watch?v=uIKupTibxKQ. One example provided is that using green screen can sometimes result in "flat" unrealistic lighting because the camera doesn't expose the image the same if representative lighting isn't used to actually capture the shot.

I'm going to go against the general negativity nancy grain and say: this looks nice. I'd use this. The basic terminal experience is _fine_, but it could definitely be a lot better, and this seems to improve a lot of the warts that I have using the terminal.

Telemetry for a beta? Sure, whatever, y'all are being transparent about what is being collected and, as a developer, I can definitely understand the desire to collect information about usage to improve the experience.

It was kind of an impossible task for Forbidden West to replicate the experience of Zero Dawn.. to me the magic of the first game was entirely based around the discovery of why the world became the way it did. The mystery of the second game is not about the state of the world, but instead one cliffhanger aspect from the last game (what caused Hades to go rogue?).

But I’m in complete agreement about with the OP about the “overpolished” aspect of Forbidden West.. just check out the Horizon subreddit right now. They just released a patch that nerfed the legendary weapons in the game. There was no real reason to do that. They didn’t feel horribly broken (especially for how much grinding it takes to upgrade them and how expensive their ammo is to craft). And come on: it’s a single player game. No idea what’s going on at that studio right now.. maybe gearing up for DLC.

Agree with you completely - hooks really aren't magical at all. The only thing that's "magical" is that React takes hook data and embeds it somewhere in the component instance behind the scene.. something that also necessarily must happen with class components. The state has to live somewhere.

I'm always confused by this comment about hooks. You can sus out the basics of how hooks work under the hood by just looking at their relatively simple rules that govern their usage. More from Dan Abramov: https://medium.com/@dan_abramov/making-sense-of-react-hooks-...

I think they are actually _more_ explicit than classes about how the state is stored. IMO `this` in class based components isn't as straightforward (e.g. https://overreacted.io/why-do-we-write-super-props/)

I think I definitely misspoke here - I really didn't mean the devs so much as the companies that employ them. I know full well how difficult such a transition could be. Native Instruments has a ton of resources, and you'd think at the very least their most recent "flagship" synth Massive X would have seen an update by now.. which definitely points to organizational cruft more than anything. Most of the plugins I use that are created by smaller teams have already been updated.

The fact remains though that a loooot of producers use Macbook Pros, and I'm assuming many will be upgrading to M1s within the next couple years. I'm genuinely curious when the pressures will actually force these large organizations to take the transition seriously.

Duda.. getting his lunch eaten by Native Instruments? Vital I understand (a sort-of-free Serum-like synth is certainly a competitor).. but Native Instruments hasn't done anything interesting in the VST space in years. Odd to throw that in there.

My point is that companies like Native Instruments have vastly more resources and developers than one individual developer, and still very few of their supposedly flagship products are M1 compatible. It's been a year and a half, and Massive X still isn't updated. You'd think they would toss at least one developer at it. I guess that maybe points to organizational rot more than anything (I guess Massive X generally being an outdated flop is also evidence of this), but the point stands.

Yeah, I'm completely satisfied. The M1 Pro is definitely the best computer for the money I've purchased, despite it costing an arm and a leg to get more RAM and SSD space.

For my workload (music production), and despite still having to run Ableton through Rosetta, it can handle roughly twice as many tracks as my 2018 MBP (which luckily is _not_ something I purchased). All my previous "problem" projects now run perfectly. And this is all while running completely silently and barely getting warm compared to my 2018 MBP, which runs fans full blast and gets super hot if I so much as glance at Ableton. Can't say I miss the hiss of the fan when I'm trying to mix tracks.

If the developers of plugins I use all the time ever get their ducks in a row and finally get around to updating them to support native ARM (that's the current limiting factor), I imagine it will be even better.

Kind of embarrassing that it's taking some devs so long.. Steve Duda managed to get Serum updated within a couple months of the original M1 release.

It’s pretty audacious to post an article as a source that actually debunks your misinformation at the bottom:

> Missing context. The 6% figure used by users online to calculate COVID-19-only deaths originates from a 2020 database and represents the percentage of death certificates with COVID-19 listed as the only cause mentioned. This extrapolation is misleading, however, and doesn’t take into account that conditions listed in a death certificate may be caused by the virus itself. While a comorbidity may cause someone to be at higher risk of COVID-19, the comorbidity is not necessarily the cause of death.

'apple' and 'slicedApple' would more likely be strings / objects / arrays in the real world. Maybe this still woefully contrived version is clearer?

  function FacebookComment({ commentId }) {
    const comment = useGetComment(commentId);
    const likes = useGetLikes(comment);
  
    return (
      <div>
        <span>{comment.text}</span>
        <span>{likes.length} likes</span>
      </div>
    );
  }

I don't think deal with more braces right now to bring the alternative into existence unfortunately

I feel like if it were actually an order of magnitude less complex, it would be eminently obvious from a blog post about it? Maybe I'm just tired and don't "see it" for whatever reason, or maybe I need to find some better examples.

From the moment I saw a post about immer.js, I was sold because it seemed like an obviously better solution for the vast majority of cases where I would otherwise grab Immutable.js, a library that I wanted to like but inevitably struggled against.

This.. isn't quite as revelatory. I'm not saying it's not all that you claim it is, it's just that from a glance, I don't see how this somewhat different approach addresses the problems I run into often with React in a major way (beyond the claimed performance boost).

> The mechanism that enables code reusability is through composing components

If you think that this:

   return (
     <Apple>
       {({ apple }) => (
         <Slicer slice={apple}>
           {({ sliced: slicedApple } => (
             <DinnerPlane contents={slicedApple} />
            )
           }
         </Slicer>
       )}
     </Apple>
   );

is more desirable than this:

  const apple = useApple();
  const slicedApple = useSlicer(apple);
  return <DinnerPlate contents={slicedApple} />;

Then go for it I guess.

Although you'd have to somehow ignore the fact that you'd end up with an even bigger mess if you want these intermediate functionality steps to interact with the parent component in a non-trivial way, ..

Needless to say, I have written such render-prop and "renderless" components in the past, and I see very little upside compared to hooks.

Class components are fine for the simplest examples, but the moment they start increasing in complexity, they become a bit of a mess. Sharing functionality across multiple components becomes tricky with class components (with the only real option being HoCs / render props). You necessarily have to spread logic across different lifecycle methods.

Hooks allow you to bundle code together by functionality, and consequently allow you to easily extract and share said functionality in a very composable way.

This is my go to for visualizing the difference: https://i.imgur.com/e9K8vfz.gif

This feels like we're trading complexity here for complexity there, and it seems impossible to judge which way is actually "better". I use loops in React all the time but only have used `setInterval` in a component a handful of times..

> Write the Test, they're going to fail cause you have no implementation

But this is where I falter every time: the test necessarily depends on the implementation. I could write a test for my first pass at a function... but then if I decide I need to actually split that function into two or go for a different approach entirely, then I have to basically scrap that test. And then I've just created a bunch of friction that slows down my development process.. for what gain?

And to your point, yes, it may have to do with the fact that often my requirements are amorphous and I discover them as I go. For example, say a designer wants a specific behavior, but then I realize it doesn't work in an edge case that we will probably hit, and fixing that edge case will take twice as much time. So then I work with them to find a less time consuming compromise -> bam, new implementation, new tests.

Or maybe it's not a user facing behavior, and I realize after 10 hours there's a way simpler way of doing the thing I want. Same thing -> new tests.

Once I've got the basic code layout in a satisfying state, only then do I feel comfortable starting tests and ensuring I most or all of my conditional branches -> success and error cases.

I feel like I'm missing something

Agree with the reasoning here, so as a result I almost never use TDD: I pretty much always have to spike + iterate in order to come to a reasonable and clean solution for whatever I'm working on.. no matter how much I've tried to spec things out exactly how they should work, it always ends up being different. I'm also just not great at abstract vs. hands on thinking.

On top of this, I've also come to find unit tests to generally require more work and be less useful for identifying regressions than integration tests for the work I do. Maybe this is just a result of the kind of work I do though.

They also broke the browser extension so it can longer read your personal vault in Dropbox / iCloud, in an apparent attempt to force you to move your passwords onto their servers. Literally removing functionality for the sake of... money I guess. So now I'm stuck copy / pasting all my usernames and passwords. Thanks 1Password.

Unfortunately I still haven't found an alternative that works as well, otherwise I'd have switched a while ago.

Read the article:

> Davis specifically alleged that four seconds were missing from the final moments of the flight — enough to put the engine response outside the certification requirements. His main evidence was an apparent disagreement between the time stamps on the ATC transcript and the flight data recorder. The FDR had a “radio transmit” parameter, which showed up in the data four seconds after the final air traffic control transmission. But this was actually a really basic misunderstanding of how the FDR works: the “radio transmit” parameter is only recorded when one of the pilots makes an outgoing transmission, not when an incoming transmission is received. The data point corresponded to Mazières’ reply to the transmission, not the transmission itself, and matched up perfectly with the official timeline.