I also think other folks in this thread are referring to mounting on existing DOM in jQuery-esque use cases.
576 karma · joined August 7, 2016
I also think other folks in this thread are referring to mounting on existing DOM in jQuery-esque use cases.
I think this exact capability is what led to such strong React adoption. It's almost viral within an application. The main application that I worked on a few years ago was on Backbone / Marionette and we evaluated React by writing several small but complicated nested components, with state controlled by existing mechanisms. After liking both the flux application architecture and the ease of gradual transition, we pulled the trigger on React. It slowly ate our application from the inside out, but never forced our hand.
React isn't "lightweight" (JSX being the primary hurdle), but it is very easy to adopt incrementally!
>>> betamax((3, 14), (4, 12))
0.29448379324802676
>>> betamaxinv(0.29, allowed_error=0.01)
[((3, 14), (4, 12)), ...]
I assume the results of `betamaxinv` are not unique, and so perhaps there need to be constraints, or return a family of results. I don't know. I'm trying to wrap my head around how OP got A ~ Beta(2,13) and B ~ Beta(3,11) without just brute forcing numbers into `betamax`.What I'm asking is: how do you find parameters for A and B given "P(B > A) = 0.71"?
It makes sense, I'm just surprised the blog never comes out and says "you have to do a brute force search to get the parameters for the likelihoods A ~ Beta(2,13) and B ~ Beta(3,11) for P(B > A) to have about the right value".
> this is an awesome example. is there an easy way (as in non-brute force) to finding the beta parameters that'll match a probability?
The sketchy stuff shows up in cheap components with slim margins (budget AIO watercoolers, budget hard drives, budget PSUs budget/no-name ebay video cards).
I think that this is a feature, not a bug. Part of my maturation from a junior to a senior engineer was learning to trust that simple implementations are ok. I remember often not trusting that the simple thing would work robustly (passing around a list) and reaching for something way more heavy (perhaps a wrapper around sqlite persistence). I now recognize that the simple implementation is better and almost always more robust than something fancy, and I definitely attribute that to internalizing the zen of python over time.
> JS is a pass by value language... except when it comes to arrays and objects, it then becomes pass by ref. Go figure.
It's all pass by value. For objects and arrays, the value passed is the reference.
I'm in awe of his contributions to both computer graphics and Pixar, and I really liked his management book, even if he definitely did some sketchy stuff with wage fixing.
This is a perfect example of where JtbD is stronger than personas. There are lots of people who use both VSCO and Facetune. The thing differentiating those two cases is what they intend to do with a photo, the job to be done. Another simple example of this type is YouTube vs TikTok. How are the personas different?
The case for personas is stronger within a specific task, for example: iMovie vs Final Cut Pro, ffmpeg vs Adobe Media Encoder. Even then it's not the touchy feely aspects of personas that bring value, but instead the basic market segmentation.
I ask because where I work we sync postgres to a secondary store for search, but the way it's done in a piecemeal, application-specific way gives me the heebie jeebies. It almost certainly will result in that secondary store drifting. Unfortunately we can't use something like zombodb [1] as we're on amazon RDS. It seems like you know your stuff, and seeing non-deterministic consistency irritates the heck out of me!
Dead on. I've seen boards of directors ask for fried ice:
Management: We haven't put adequate time into building a sales training program.
Board: Focus only on revenue this quarter. It's the only thing that matters!
Then next quarter:
Board: Why aren't your new sales guys producing?! They need to drive revenue!
Management: Uh... you told us not to spend time on training.
It's really fun to watch his commentary because he relentlessly plays "variations" — possible next moves and sequences — while waiting for the players, explaining the tradeoffs between moves and the consequences they lead to a few steps ahead in the game.
I don't know what to call "variations" but a tree search with heuristics. He does it slowly to explain it to the audience, but I have no doubt the same process runs much faster in his mind.
The RISC philosophy wasn't a mistake. Our architectures have just become more sophisticated so that we don't have to make a binary choice. The hybrid is good. The internal uops get the pipelining advantages of RISC, while we get the encoding compression of a CISC instruction set.
Power limits and memory hierarchy both benefit the 9900k heavily in this comparison, which is why I went with the single-core score. I'd be surprised if an iPhone 11 Pro Max will floor all its cores even for a short microbenchmark. A desktop/laptop A14 will likely look much more competitive in these respects.
• iPhone 11 Pro Max - 1413 (11.0 Klines/sec) https://browser.geekbench.com/v5/cpu/2634126
• 9900K - 1270 (9.89 Klines/sec) https://browser.geekbench.com/v5/cpu/2633843
The A13 is really impressive.
Great stuff. Thank you for the reply!
It's also going to be a driver of 1440 and 4k gaming, because there will be more games that look good enough to make high res gaming worth it.
To get specific about what this enables, I think we will see many more indie games with great looking graphics. The combination of high res asset scans, automatic resolution scaling, automatic texture compression, generally less tight performance budgets that don't need teams to do optimization work (next gen consoles), and a financial model around tools to take advantage of all of this (Unreal + Quixel as the leader here) should make this next generation of games pretty awesome.