Things Found

Up to book pg 81

> everyone can think of someone they’ve worked with who is just maddeningly stubborn—no matter how much people try to persuade them, they dig their heels in even more. What eventually happens to such team members? In our experience, people stop listening to their opinions or objections; instead, they end up “routing around” them like an obstacle everyone takes for granted.

Fluff

> de-risk things early. Enumerate your unknowns and tackle them in priority order based on level of risk. As you progress through a project, risk should strictly decrease, with the largest reductions occurring at the earliest phases of the project.

> Internalize the Pareto principle, also known as the 80/20 rule. It is ubiquitous. 80% of the effort is spent on 20% of the work. 80% of the planning is done by 20% of the team. 80% of the risk in a project is in the first 20% of the project. You get the idea.

> You are a vendor not a partner when your relationship does not make a meaningful difference to your ‘partner’s’ strategy

this is the biggest load of horseshit

> Nothing differentiates professional and amateur developers—except for a habit of validation.

"for-profit" applies to teams even within a "for-profit" org, we often judge success and failure of our FE by usage, we don't have a parallel metric for infrastructure success, we don't run BE/infra projects "for-profit", so they never "fail" (e.g projects that take 5x the estimated time are still a "success" when they ship

> strength applied to the most promising opportunity

> There is no greater way for sharpening strategic tools than the necessity to act. “What would need to happen if this would absolutely have to happen?” Make the hard choice

> No one has advantage at everything. The key is to press where you have an advantage and to side-step situations in which you don’t.

In the late 1800's, ships were just wrecking all the time. I had no idea.

Linked: https://harvardlawreview.org/wp-content/uploads/2021/01/134-Harv.-L.-Rev.-905-1.pdf

> I have been arguing this point for two decades, framing it as “output regulation” rather than “input regulation.” For example, Congress was extremely out of character (in a good way) when it passed the Energy Policy and Conservation Act of 1975, which created the Corporate Average Fuel Economy (CAFE) standards. Rather than regulate inputs — like engine displacement, use of aluminum, etc. — as most governments do most of the time, the Act regulated outputs, mandating that average fuel economy of each producer’s new car fleet must achieve 27.5 mpg by 1985 — a near-doubling over a decade. And it worked, in large part because the auto manufacturers were left the flexibility to figure out themselves how to reach the target result and each one did so in its own way.

> In my observation, there is an implicit assumption that if we set the proper key results that are causally linked to the achievement of the objective, the setting of the key results will make it more likely that the objective will be achieved. But desire (as with hope) is simply not a strategy.

> Web3 promises rewards — maybe even a kind of justice — for “users”, but Ethereum doesn’t know anything about users, only wallets. One user can control many wallets; one bot can control many wallets; Ethereum can’t tell the difference, doesn’t particularly care. Therefore, Web3’s governance tools are appropriate for decision-making processes that approximate those of an LLC, but not for anything truly democratic, which is to say, anything that respects the uniform, unearned — unearned!—value of personhood.

> The somewhat-ridiculed cryptocurrency Worldcoin, with its retina-scanning orb, is one attempt to solve this problem. There are others. They tie themselves into knots trying to arrive at personhood in a universe of wallets.

We spend a lot of time thinking about how to give feedback and how to ignore feedback given in the wrong spirit, but by actually finding a way to find value in the toxic feedback and why it hurts so much, it can be just as rewarding.

> If it’s destructive feedback, you really feel it. The other person designs the feedback to cut deep. That’s their intent. I’m not going to explain the motivation of these humans, but please note their nefarious intent is to land the sucker punch, and it somehow landed. Amongst their toxicity, there is something you heard. When I am in this scenario, I attempt to push the toxicity aside, look in the mirror and ask myself, “Why do I care?” There is always an unintended lesson.

> Here’s one lesson: when constructive feedback stops you in tracks, it feels like your entire world is this feedback. You aren’t this feedback. It’s a sliver. A thread. One paragraph in a very long in-progress story. You are a fully formed human full of skill, will, flaws, strengths, good days, and bad ones, too.

> A common characteristic of NP-hard problems is that they’re strikingly non-local. Any type of local reasoning or optimization you attempt to apply to them will generally break down and doom you to look at the entire problem holistically.

> But if every day your institutions are just a tiny bit less legitimate than the day before, when do you rush out into the street?

> There was no way to preserve sounds before the nineteenth century. Speeches, songs, and soliloquies all vanished moments after leaving the lips. That situation changed in 1877, when Thomas Edison began working on a machine that could mechanically reproduce the human voice. Edison’s team successfully assembled a device on which Edison recorded “Mary Had a Little Lamb,” a nursery rhyme that would become the first words ever spoken by the phonograph.

> Crucially, Edison’s statement is among the first made by the recorded book industry to characterize reading as a secondary activity intended to accompany other pursuits.

> “The library of the future will be one which any man can carry under his arm.”14 Not a bad prediction for 1878.

> First, I can’t help but notice that so many of these process people have never performed either the maker role or the manager role in a strong product company.  They have more enthusiasm than experience or knowledge.  Not only does this put exactly the wrong people in control of how teams work, but these people are prime targets for the armies of consultants and vendors that have figured out that these people are their best path into your company.

> In every strong product company I know, the key to scale has been their leaders.  In particular, their managers, and the commitment of those managers to coaching and developing their makers.

> The person making the new API is expected to change client code to match, but is not responsible for ensuring the change does not break the client.

> There is a secret that needs to be understood in order to write good software documentation: there isn’t one thing called documentation, there are four.

> They are: tutorials, how-to guides, technical reference and explanation. They represent four different purposes or functions, and require four different approaches to their creation. Understanding the implications of this will help improve most documentation - often immensely.

> The Main Thing. As Jim Barksdale famously said: “The main thing is to keep the main thing, the main thing.“ So much of an effective product organization is a result of real focus. There will always be new prospective customers, and new business opportunities, but remember that focus is not saying no to bad opportunities, it’s saying no to other good opportunities.

I don't think this really has anything to do with state updaters: _most of the time_ defining any logic inline is worse than extracting it out and giving it a good name. And I don't really buy the example given to justify it. The flaw in the `CounterActions` component is not the "bad" state updaters, its the poor choice of props. The flow of deciding the childs props based on the parent also seems backwards - the smaller component should be written in isolation with the minimum footprint, the parent is just a consumer of a dumb little component much like any other component you choose to use. If the component wants to do something crazy with the number, that's the component you write so you take a setState, but you probably just want the minimal footprint for the components responsibilities, so a couple callbacks for its actions makes a lot of sense, and everything else works out nicely.

If only I could remember all those blogs that didn't have RSS that I wanted to read along with

https://www.fluvio.io/ A real-time data streaming platform with in-line computation capabilities. Use Fluvio SmartStreams to upload your custom logic and modify data as it moves over the network.

wild that this is a "business"

Very much this.

eh, maybe recruiters know what they're doing, they do it a lot, and their job isn't to get _you_ a job, it's to get as many hires as possible. maybe sending many emails might be a lot faster than sending one highly customized one and be better despite the lower hit rate.

In fact, if I were to grade recruiters from my perspective, I'd give them the exact opposite grades to yegor here. I've never responded to a recruiter email. So for all the Jeffs and Amys, the less time they've spent crafting that email to me, the better job they're doing. The quicker they can move on to the next one the better. And if I want a new job? I'll probably find the place I want to work and apply, I doubt I'd make any use of an inbound request.

I read the abstract and conclusion only.

> Legal corpus linguistics users tended to identify narrow, prototypical examples (for example, a car is a vehicle) rather than nonprototypical examples (for example, an airplane is a vehicle), while dictionary users tended in the opposite direction, supporting more extensive judgments (for example, a pair of roller skates is a vehicle). As such, the verdicts of legal corpus linguistics and dictionary use often diverged from each other.

> For instance, consider what this Article calls the “Nonappearance Fallacy” — namely, the (false) claim that absence of a usage from a large corpus indicates that the usage is not part of the ordinary meaning. One might be surprised to learn that in some modern corpora, there are no airplanes referred to as “vehicles.” Although it is tempting to conclude from this that airplanes are not included in the ordinary meaning of “vehicles,” the experiments show this to be too quick: the majority of ordinary people, law students, and judges evaluated airplanes to be vehicles. The broader insight underlying these critiques is that ordinary meaning diverges from ordinary use.

> India has administered 150 million doses, the third-greatest total in the world. However, the sheer size of India’s population means only 9.1% of Indians have received at least one dose, and fewer than 2% are fully vaccinated.

> Unlike many high-income countries, including the US, India has also exported significant volumes of covid-19 vaccine—it has sent more than 66 million doses to 95 countries since the pandemic began.

> Medical oxygen is in critically short supply in India, with an estimated daily need of 2 million oxygen cylinders far exceeding domestic production capacity.

> “Willpower,” Baumeister and co-author John Tierney write, “like a muscle, becomes fatigued from overuse.”

> “Diets are broken in the evening, not the morning. The majority of impulsive crimes are committed after 11: 00 p.m. Lapses in drug use, alcohol abuse, sexual misbehavior, gambling excesses, and the like tend to come about late in the day.”

> They micromanage, They don’t listen, They don’t value us, They don’t provide feedback, They don’t motivate, They don’t set goals, They don’t delegate, They don’t explain

> The list may be much longer, but I think that the root cause of all of them is the same: managers make appraisal mistakes.

This is unconvincing. Seems like inventing new words to describe existing paradigms of lazy evaluation and getters.

> Nobody will do that either, as innovation in core software engineering, or even learning from the past in core software engineering is basically dead.

> Engineers are a defeated tribe; it’s cheaper to hire an “AI” (Alien or Immigrant) slave to write the terraform or electron front end rather than paying clever engineers well enough to build themselves useful tooling to make them more productive and the world a better place. Consumers will suck it up and buy more memory, along with planned obsolescence, keeping the hardware industry in business. Computers aren’t for making your life easier; they’re for surveillance and marketing, and for manufacturers a consumer good they hope you buy lots of add-ons and upgrades for, and which wears out as soon as possible.

My main disagreement is around the finding that the work is "transformative". Breyer states "Here Google’s use of the Sun Java API seeks to create new products. It seeks to expand the use and usefulness of Android-based smartphones. Its new product offers programmers a highly creative and innovative tool for a smartphone environment. To the extent that Google used parts of the Sun Java API to create a new platform that could be readily used by programmers, its use was consistent with that creative “progress” that is the basic constitutional objective of copyright itself. " and he seems to imply that anything that can be built on top of should be fair use because it can be transformed into something new and creative, which seems to be a very broad interpretation. And when applied to creative works like music samples, seems to open the door on what could be considered transformative.I can build an entirely new song from a combination of samples of another. I would argue that a sample is a "highly creative and innovative tool" and that the sample is copied "only insofar as needed to" create something new. A library of samples is not dissimilar to the building blocks that an API might provide. And as SC continues to say that the copying introduces more programmers to Java, and is beneficial to Oracle, the same would be true for sampling obscure works. I view the argument that a phone is a new "environment" is weak, as far as a Software Engineer is concerned, it's not much different than a low-powered or old computer. Laptops had batteries and cameras for some time before phones came along. In fact, even in 2005, phones were often more powerful than older computers, and since 2020, Apple has started putting mobile chips in their laptops - a MacBook today has a lot more in common with an iPhone than it does a PC from 10 years ago.

The main differentiator might be around the "functional" nature of code, but any Software Engineer will tell you that writing a clean and concise API is hard and undoubtedly creative work, differentiating between "functional" code, or mathematical proofs, or non-fiction writing would be very challenging, and probably goes towards the question of copyright-ability, not fair use. After reading the descent, it seems that Thomas has a similar opinion, albeit with much more snark and ire.

I also disagree with "Amount and Substantiality of the Portion Used". Code is by its very nature hierarchical, and there's no reason it couldn't have been copyright as multiple works, altering the ratios of "lines" copied. Indeed, the copied sections form the very base of the pyramid, which seems to have been recognized but ignored? The notion that programmers already know how to use these APIs is a bit odd to me. "It would have been difficult, perhaps prohibitively so, to attract programmers to build its Android smartphone system without them" - indeed Google has produced two programming languages from scratch since (Go and Dart), both are now pretty widely used, and I can't think of anywhere else where copying something is OK because it's a widely used tool and a new product might fail if they tried to innovate and produce something different (isn't this the innovation that's the point of copyright law?). The "Market Effects" section seemed pretty nebulous and the nature of fair use seems like it's pretty easy to construct arguments in either direction.

> This isn't trying to say mechanism is always good and judgment is always bad! We can predict cases where one might be better than the other - and as with the doctor studies and the gifted program studies, we can test when one is better than the other. I'm just trying to say it's an interesting question that you can't resolve just by throwing a copy of Seeing Like A State at someone.

Chesterton's Fence: Do not remove a fence until you know why it was put up in the first place.

> I actually wrote this note 10 months ago and had totally forgotten about it. An hour ago, I randomly came across it and was quite amused. It includes some ideas which I thought I had started thinking about only recently. But it turns out they’ve been incubating in my mind for a long time. Funny how that works!

> I call working with legacy systems “software archaeology.” It’s like homes built before city infrastructure existed—they weren’t built to connect to city plumbing or a power grid.

> You're unlikely to find a new law as helpful as the old laws are harmful, so focus on getting rid of old laws.

Somewhat surprising that self-tuning software isn't more common. It's common to tune services for the initial loads, and over time this configuration fails to hold up. Maybe alerts help identify issues as the arise, but a service should be very capable of observing it's own load over time, and estimating how different cache schemes/retention would best serve requests. In my experience, cache sizes and durations are just guesses. An hour seems reasonable. 1024 things seems reasonable. Most installations are left at their defaults, regardless of how much disk or memory is available where it's installed.

WASM transforms is pretty cool.

> How do I get all of these technologies talking to each other? How do I begin integrating them into my existing business processes and tech stack? And how do I enable my IT organization to rapidly adopt this emerging technology and bring it to market?

> We saw models taking longer to get into production compared with our previous report’s data, while data scientists are spending more of their time on model deployment.

> In addition to the above complexity, we should also add the fact that it’s not enough anymore to just move data from the points of creation to a data warehouse. Data Pipelines today are built to also sync data from our analytical and processing storage, like the data warehouse and data lake, back to systems where actions can be taken.

> Keep the work parallel, the groups small, and the resources local.

> Prioritize the development of force multipliers.

> If possible, factor work products into independent modules; if not, grow slowly and optimize.

> Scale organizational efforts across a portfolio of synergistic products.

> Keep responsibility assignment matrices small, sparse, and local.

> Prioritize asynchronous information distribution over synchronous.

> What happens inside the boundaries is important.

> Real-time sometimes, asynchronous most of the time.

> Internal communication based on long-form writing, rather than a verbal tradition of meetings, speaking, and chatting, leads to a welcomed reduction in meetings, video conferences, calls, or other real-time opportunities to interrupt and be interrupted.

> Writing solidifies, chat dissolves. Substantial decisions start and end with an exchange of complete thoughts, not one-line-at-a-time jousts. If it's important, critical, or fundamental, write it up, don't chat it down.

> Ask yourself if others will feel compelled to rush their response if you rush your approach.

> If you want an answer, you have to ask a question. People typically have a lot to say, but they'll volunteer little. Automatic questions on a regular schedule help people practice sharing, writing, and communicating.

> Ask if things are clear. Ask what you left out. Ask if there was anything someone was expecting that you didn't cover. Address the gaps before they widen with time.

> Every meeting should be a review of a concrete proposal or to catalyze a future series of asynchronous events, and only called when it will lead to a more efficient outcome than would be possible asynchronously.

> Do not use @-handles unless you are requesting a specific written action or piece of feedback from the person and you provide the proposal and context necessary for them to execute.

> Move a project forward as best you can given the resources available, and if you reach a point where you're blocked, attempt to ship what you have now through a two-way door.

Unclear why this is different from something like docker-compose. Not sure that the dependency graph of your services "emerging" from the dependency configs of each individual service is really how you want to define your architecture, rather than something more intentional.

> In 2019, North Dakota flared 19 percent of its natural gas production.

Related: https://www.bbc.com/future/article/20210126-the-richest-human-made-marine-habitats-in-the-world

> On the other hand, it might be a moment when all the old stories that made sense of the world are collapsing – and in that moment, before the next big story comes along, a mass of trillions and trillions of meaningless fragments rush into the vacuum, and for a brief moment in history we just are immersed in a world that is completely without meaning. And then from somewhere that we can’t possibly imagine at the moment, someone will start to reassemble all those fragments in a completely new way – and out of that will come the new big story. That actually we might be living through a moment of almost complete freedom from meaning, which is why we are so terrified and anxious. It might be like that moment in the eye of a storm. Outside, the giant forces of history roar on – but in the eye it has gone quiet and we are just experiencing, but have no story to tell each other. So in 200 years’ time people will look back at TikTok as the perfect expression of this age. And all the posh novels will be forgotten.

> In practice, I’d recommend using Active Listening techniques, and repeating what the other person had said to make sure you understand it, and responding thoughtfully to the nature of their argument, as well as the details that they presented.

> Data extensions provide a mechanism for attaching arbitrary data to an interface to avoid bloat in core platform data models. For data extensions, we leverage Protobuf’s Any functionality so that teams can add arbitrary data to requests. Services will often store this data or pass it to a logic extension so that the core platform is never responsible for deserializing (and thus “knowing about”) this arbitrary context.

> Historically, we only ever tested the very tip of the iceberg - except the iceberg has now melted, exists in several places in time and locations concurrently, and is also on fire.

> He says that the Republican Party represents the modal American on various characteristics, eg Christian (the most common religion), white (the most common race), straight (the most common sexual orientation), etc, whereas the Democrats represent everyone else (eg Muslims, Jews, atheists, and every minority religion; blacks, Asians, Hispanics, and every minority race; etc). That means the Republicans are more ideologically uniform - Christians are genuinely similar to other Christians, but Jews are only superficially similar to Muslims by virtue of their non-Christianness. That means ideology can't really capture the Democratic Party in the same way it captures the Republican Party.

> An alternate framing might be something like: when America was 80 or 90% white, you couldn't really have race-based coalitions, because the non-white coalition would lose. As America becomes closer to 50% white, race-based coalitions start to be a viable strategy, especially if the non-white coalition can get some moderate level of white support. Since race is an emotional topic that lots of people feel invested in, as coalitions become more race-based, politics is going to get more polarized and emotional.

Awkwardly, the RSS feed appears to bypass their subscription requirements.

A bit simplistic, but an interesting idea of showing a few examples of how some mental models might apply to Product Management. I'm curious if there are specific models that apply to Product Management / Product Development, specifically around the problem solving and conversion of client(s) problems in to a product or platform

"To put this into practice, try categorizing decisions into actions that innovate, sustain, or scale."

> Another way that I like to express that is “create a desert of profitability around you”. I once had a strategy professor define the Google business model somewhat like that, where “Google tries to make every other business around it free or irrelevant”…A desert of profitability shifts consumers to you, and keeps competitors away.

"This article is certain to upset many people" - starting an article like this certainly upset me.

> The result is that in feature teams, the product manager role is mainly project manager, and partly (unskilled) designer.

thread-per-core has a very Java AWT-thread or concurrency-in-the-browser with webworkers vibe to it. no need to worry about concurrent writes, because there's only ever a single thread operating on the AWT or DOM, or when you're in the web-worker you know where that codes being run, so you just don't have to think about concurrency. similar to actors in that way of knowing you're writing code with exclusivity over the thing you're operation on.

Not sure I really buy the link between numbering systems and play here, feels pretty forced...

There's usually something valuable in an fs.blog, but the posts feel very structured. Big Idea. Three examples. Conclusion. And the examples don't always work, they just seem like "Cool Things" the author has learned about and wants to string together, but I'm not quite convinced are really related. I feel the same way about the chapters mental models book.

> Of course, all of this relies upon the fact that you're able to maintain and operate an FDB cluster, but that's the point of building on top of FDB. Once you've figured out how to setup and operate FDB clusters, you can build all of your other distributed systems on top of it and let FDB handle the most complicated portions of the distributed systems so you can focus on the portions that are unique to the problem you're trying to solve.

> We see a future of edge databases that store each "chunk" as a Durable Object. By doing so, it will be possible to build databases that operate entirely at the edge, fully distributed with no regions or home location. These databases need not be built by us; anyone can potentially build them on top of Durable Objects. Durable Objects are only the first step in the edge storage journey.

> A good guiding principle for designing such a system is probably to minimise data movement – i.e. (1) do as much processing as possible as close to the point of data capture as possible, and only send the aggregated results downstream, and then (2) where pools of data do amass, do as much querying of that data as close to the point of data storage as possible and only send the query results back upstream.

> I observe that computation split across end devices, edge, and cloud doesn’t really sit well with batch processing either. We do distributed batch processing within a layer (e.g. map-reduce) but across layers is different. My conclusion is that federated big-data systems are also online systems.

My system: everything, including this, goes in workflowy. I've been using workflowy for years. Super easy, very lightweight, lists on lists on lists. Seems to have been overtaken in feature-space by Roam and other alternatives, but serves the same purpose and is gaining features from those more advanced products slowly. One place to put things means one place to search. Writing and synthesizing is useful, and workflowy is the true minimum amount of structure, very low barrier to entry to committing something. I have a decent amount of categorization, but the main entry points are this Things Found list, and my daily journal of todos/notes/ideas. Monthly I'll do a roll-up of anything straggling, decide if to carry forward or mark as unfinished.

> Studies have estimated that pallets consume 12 to 15 percent of all lumber produced in the US, more than any other industry except home construction.2

Fantastic piece.

aka Redoodle.

“Embedding and pairing make sure we’re solving the problems that product developers are most struggling with in practice, avoiding what’s often called Ivory Tower Syndrome where the solutions don’t match the problems”

“Novels require more readers than poems do, a statement so odd that it puzzles me, even as I agree with it. Tennyson, Browning, and Robert Frost had large audiences, but perhaps did not need them. Dickens and Tolstoy had vast readerships, and needed them; multitudes of overhearers are built into their art. How do you read a novel differently if you suspect you are one of a dwindling elite rather than the representative of a great multitude?”

Found via Brady in a doc about the vision for the concepts team

Comments do a pretty good job of explaining why LW is incredibly off-putting, even if their methods and models are valuable

I wish we had pipes in javascript. And pattern-matching.

I shouldn’t have, it’s itnext after all, but I wonder if anyone knows how to actual do micro-frontends

What up Brie!

so I guess logrocket has just devolved to “find a library, recreate the most trivial example, write a blog-post that’s really just an ad”, no real discussion of if it’s a good idea, when to use it, why it’s so damn verbose, how to do anything remotely interesting using state machines etc

Maybe logrocket should join the itnext ban list

Honestly, I find this terrifying.

Excited to give this a whirl

Explains how he ended up building https://tailwindcss.com/ - unconvinced of the method, though I’d give tailwind a try to see how it feels

Let’s migrate our microservices to monoliths

Let’s migrate our monoliths to microservices

we could do it slowly with outposts?

but no wait back to monoliths

and then back to microservices but this time in different clouds too?

An article in which someone describes how the workspace works.

I should write a blog post about ever 100 PR I write too

I should stop reading shit from itnext, it’s worse than that hackernoon garbage

Still in search of a methodology that’s useful in css module

Just an ad for bit.dev

I don’t really understand what they add other than an index on top of a library - maybe some runtime loading of the component. Seems like fragile integration though.

I’d love a bit of api orchestration

Reading the challenges, this sounds kinda rough. For anything that wants to be truly parallel it seems like choosing a language with concurrency baked in from the start, like Rust or something on the Erlang VM, would be a better fit.

I love a person who’s just willing to do the hard work

With a product named Kafka Connect, it’s really hard to tell what’s OSS and what’s confluent’s product. It all looks like open source, do they just sell support?

Looks like Rockset is yet another third party product you can put your data in.

transactions are cool but when you don’t own the whole data engine (or whatever Foundry is), it seems like you have to spend a lot of time pushing them down it to every nook and cranny of any tool that could be composed into it

“This same thing happened to the concept of the “Data Lake”, which promised vast data collection capabilities to meet all of your data needs. It was simple, just come by whenever you wanted, bringing your collection bottle to fill with some data water to satisfy your thirst for insights. It turns out, this unfiltered water makes people sick, and the volume of the lake drowns people who don’t know how to swim in it. “

From 2006: “For a ring-tone-addicted public” really dates this one.

“Clearly, capability has a stronger effect on expected utility than usability does.”

“The phenomenally popular iPod, Apple’s personal music player, shows how effectively a company can make sales and satisfy customers with a tightly focused solution. As a new digital product, the iPod could have combined numerous features at extremely low incremental cost. Instead, it aimed to be a single-purpose tool that performed so well and so simply that everyone had to have one.“

Does this article spark joy? no.

Apparently the best practices include writing a test to cover any and all behavior by any line of code.

The idea of writing a test that checks that your private callback onOpen containing a single line of code that sets your internal state open to true works correctly seems like madness.

I really don’t understand how anyone is able to modify any code in a code-base where every line and private method and private state are all as you expect them at all times.

The only useful thing I take away from this article is that testing hooks + functional components is hard. That’s okay though, I will continue to avoid hooks, functional components and testing react-y things.

Left me curious as to how many bits you’d need in a bloom filter to efficiently decide if your 100 followers had ridden a given segment

It feels like all the css methodologies basically get thrown out with the css-modules approach, as it automatically enforces a component level structure and discourages sharing of styles across components

There’s probably something useful still to be found in these structures however - I’m still a fan of using modifiers (prefixed with -) for varying styles based on states (like selected, active, etc), and more recently using a single scss file for a whole folder of related (e.g StringEditor, NumberEditor...) or nested components (e.g SimTable, SimTableRow, SimTableHeader) where you the nested components wouldn’t exist outside of the parent.

Great to see that salesforce has finally embraced docker?

Yeah that’s not what that means.

Would be cool to do this for compass actions/applications api calls.

However, “our plugin model works such that they are only ever run on explicit user action” doesn’t really fly for most of our plugin uses.

Their solution is to have a null iframe (no browser history) for the UI + sandbox browser/network features, and then a main-proccess Realm for calls that need to access the document in a non-async way. Cool tech for sure, but this seems like a lot of additional complexity to avoid the two downsides to the iframe approach mentioned earlier: that async is hard and that large data transfer is expensive.

To me, a better approach seems to be avoid the need for copying large amounts of data from the outset with good APIs and a simple model, and to embrace the async nature of running code out of process(ish).

From https://www.infoq.com/news/2019/08/postMessage-performance-study/?utm_campaign=infoq_content&utm_source=infoq&utm_medium=feed&utm_term=global

Answer: No. Keep payloads under 100kb. Keep animation-related payloads under 10kb.

Or, if you’re happy transferring arrayBuffers back and forwards (i.e only accessing the array in one place at a time), using flatbuffers can make this easy to do while still having structured objects, including a TS generator. Maybe one-day we’ll get sharedArrayBuffers back.

This doesn’t do a great job of selling the why behind the idea of moving state off-thread. If you’ve got a local copy of the state for rendering, the only benefit in the standard model is to move the reducing off-thread, but that really shouldn’t be expensive. It’s the services and “sagas” that get expensive.

I’ve been thinking about moving our services/data-loading/etc off the main thread for a while, and with the data-heavy nature of vertex where we often have data for large chunks of time that aren’t visible, it would actually give some fairly nice wins to minimize expensive object-loading/ts-loading/deserializing off-thread and sending a simple model with the data we need to the UI thread.

For our purposes, we “connect” our canvas directly to actions for updates, as canvas doesn’t have a declarative model like react, and the overhead for that model would prevent a performant canvas. As a result we’d want to keep our actions visible on the UI thread, but there’s no reason we couldn’t move state off-thread but have actions visible both sides of the barrier.

The world of Shopify and dropshipping is kinda wild. You can straight-up buy a Shopify-based buisness (and run it into the ground) https://exchangemarketplace.com/