For golf, you don't try harder, you relax more. At the highest level of sports, even rowing, I suspect it's similar. Only in golf do we compare the outcome of a ball flight -- we think we row similar to professionals, but there a ton of difference, you just can't see it in the result of ball flight.
My go-to golf philosophy book is "Cheng Hsin: The Principles of Effortless Power":
> To relax, you must surrender your mind-even the notion that you have a mind. You will find that relaxing your mind is the same thing as relaxing your body. There should be no separation between your mind's activity and your feeling-awareness of bodily sensations and impulses. Feel yourself letting go so that your body isn't "held" so much--this requires doing the same thing with your mind. When you relax your tissues, nervous system, organs, the muscles around your organs, every-thing, then the energy will flow. It is this very relaxation that allows for the energy, or feeling-attention inherent in your body-being, to circulate, develop, and be utilized.
Finding a business / product that actually is working is unique. When you find it, stick with it. Nothing is perfect, and shit is going to be hard, it’s just the next level of the company. Be optimistic — look for what’s working and do more of what’s working. Don’t let pessimism get routed in the way you think. All of that, and fight the urge to build first — sell first.
SELECT * FROM A, LATERAL (SELECT * FROM B ORDER BY a.embedding <-> b.embedding LIMIT 2) AS closest_in_b ORDER BY A.id;
It’s going to have so-so performance. So, don’t hose your production server. Create a vector index on b.embedding. HNSW will be nice for this use case.
Protip: in CRUD applications, most performance issues from the data layer have nothing to do with the database.
Typically, the performance issues are at the ActiveRecord level, when it's initialization 100s of instances of an object to render a table. With Rails, the #1 optimization technique is to use `ActiveRecord::Base.connection.exec_query ` to return a hash instead of initialization objects.
Tether is a fiat currency supported by the crypto oligarchs. It doesn't have to be backed. It just has to avoid taxes, avoid governments, and avoid sequestration.
You can't take a tether and redeem it for a dollar, so it doesn't really even have a price. Tether is just a placeholder for a dollar in the crypto-world.
Furthermore, Bitcoins aren't really priced in United States Dollars anymore, they are priced in Tether Dollars. The price reported on CNBC is tether dollars.
It's so synthetic, even that chart doesn't really matter. So, where can we find real dollars being exchanged for Bitcoin? We can find that in the GBTC trust. I would argue the actual price of a Tether is equal to the GBTC discount, which currently sits at 37%. So, a tether dollar is actually about 0.62 dollars.
Read the article. Retitled article should read “Not all nudges work”.
The interesting bit from the source article is that changes to the mean do not always reflect the value of the nudge. So, when judging a nudge, data should be spun various ways to determine impact on different segments of the population.
Hey, I'm the author this blog. It's intention is to connect technology decisions to financial decisions. Appreciate the feedback.
I totally agree with you on developer productivity. Said another way, to connect technology & finance: early on, when developer cost is much more significant to the company than infrastructure costs, emphasizing developers building the right product is more important than optimizing the infrastructure costs.
Secondly, I am a fan of ORMs. I exclusively use ORMs on CRUD-based actions. The typical first-fix for ORMs I see is to move dashboards, reports, and aggregations to native SQL. Just doing that get you a lot of performance improvements. Recently, for a friend, not associated with Crunchy & not using Crunchy, I helped them lower their cost of database operations from $2500 / month to $500 / month. All I did was find the slowest queries, determine the ORM was running a slow query, and doing an N+1 query , then point them in a direction to fix it. Because their cost of operations were looking at increasing so quickly, they were looking at migrating to a different database, NoSQL, or something else.
Totally agree that it’s “unofficial”, which makes it a when-not-if scenario.
At some point, total collapse of Tether’s pseudo-dollar will happen when the revenue generating exchanges feel they are support bad-money with good. All it takes is one player signaling a lack of support, and others stop supporting as well.
It’s a human psychological problem that’s a old as time. Think crypto can win over human rational to preserve self-interest? (side note: manipulation of self-interest is the goal of “weak hands” / “diamond hands”)
It is one step closer to shutting the doors on Bitcoin as an isolated financial ecosystem. Bitcoin-to-actual-USD is a trackable / taxable event. Whales avoid it like the plague.
By moving to a pseudo-dollar like Tether, market makers can hang out while they wait for a suspect better buy-in price in the future. Should pseudo-dollars go way, they actual-Dollar transactions get a taxable haircut. Additionally, the friction of going from actual-Dollar to Bitcoin increases.
Tether is effectively behaving as a crypto-clearing house with their pseudo-dollar.
These events ultimately lead to the creation of the Federal Reserve for banks to participate in a semi-cooperative system that didn't devolve into save-yourself during times of crises.
The story here is that "unless there is a massive run" is actually a fairly common event.
By taking on a vendor's tool, I would argue you trade off ease for understanding.
If you truly need to shard, it's best to move deliberately and potentially roll your own at the application level. Your understanding of the infrastructure is far more important than sharding for the sake of sharding.
SPA's #1 draw back is that you have to rebuild browser functionality inside of the browser.
The browser natively handles internet connectivity, back / forward buttons, refresh buttons, URL management. Additionally, users have been trained to understand the responses, hit the refresh button, and use the back button. Browsers have gotten better at distinguishing between your internet being down and the website being down.
Good SPAs have to rebuild all of that functionality.