I may be in the minority here, but I personally prefer the "wrong answer" highlighted at the beginning of this article. Scripts are source code. They go in the repo, and they have the same standards applied to them as any other source code. I would much prefer that the code be explicit and rely on few if any third party libraries. I have go scripts that have been functioning in production for half a decade now without modification. They are as "self documenting" as any other go code, and I do not require esoteric knowledge about a third party library to re-familiarize myself with them.
One of the cruel aspects of endurance sports is that they suppress your appetite. You can go out and burn 6000 calories in one race, spend the whole time thinking about all the delicious food you're going to reward yourself with, and then you get there and have zero desire to eat. You sometimes can't even start refeeding until the next day.
Worse still is having to merge in/out of traffic to avoid parked vehicles. In the state of Oregon, you are legally entitled to the same rights as any other vehicle on the road, but that also means you are legally obligated to move over when possible so faster vehicles can pass. In practice, this means swerving into the lane of car traffic to get around cars parked on the curb, and then moving back into the "bike lane", repeatedly. It's frightening, even if drivers here tend to be very considerate to pedestrians.
Rural areas in the PNW are about a 2 on the Bortle scale, and the stars are strikingly vivid. The first time I saw Starlink with my own eyes, I was making an alpine start on Mt St Helens. The cluster of satellites against a backdrop of bright stars was breathtaking, and I got this powerful sense that we were truly conquering the heavens. You could call this another form of light pollution, but it made a pretty big impression on me. It felt more like science fiction than reality.
Are you concerned that you are introducing tech debt into the codebase? Anyone who refactors your code later will also have to refactor your comments (but likely won't).
I used to have fairly poor sleep hygiene but am now pretty good about it. I have had this experience in both states. I had night terrors as a child which eventually gave way to curiosity, and I practiced staying self aware while falling asleep. A common trick you can use is to learn to recognize the signs that you are sleeping, for example by checking your phone. Digital screens will have garbled symbols in a dream. You also might notice altered laws of physics, or suddenly remember that you already went to bed and the dream can't be real. After the first few times, your brain learns how to do it and it happens more and more without effort. Then you can stay self aware while falling asleep, and can start to explore the transition states that you otherwise couldn't see.
Yes, often toward the end of this near-dreaming state, just before entering deeper sleep. I experience a sensation like entering a free fall and lose the ability to move. It takes quite a lot of energy to climb back out of it and regain the ability to move.
That is the normal state of ultra endurance athletes during long runs[0]. A lot of training stimulus is fat adaptation. Coaches will tell you that you begin to exhaust your glycogen stores beyond the 90 minute mark, and I can tell you subjectively that the body switches over around then. I have done fasted runs up to 3 hours before. Runs of that duration are physically impossible without burning fat as fuel.
When I see studies like this, I always wonder if you might get the exact same benefits and more by just going for a run. When I run for more than 90 minutes without taking in carbs, my body goes into a ketogenic state very similar to a multi-day fast. And exercise has additional benefits that simply fasting doesn't.
I listen to a workout playlist on shuffle frequently while training, while slowly adding new music to it throughout the year.
Like others have mentioned, Spotify has completely stopped recommending new music for years now. Even if I start a song radio from a song I've never listened to before, Spotify immediately just starts playing songs from my current year's workout playlist. That is not the behavior I want. Yes, I listen to that playlist a lot, but when I'm not listening to that playlist, I'm trying to find new music. It seems really obvious that that would be the expected behavior, to me at least.
What about distributed systems? I had to reach for this tool recently to trace requests as they propagate through up to 5 separate devices. Not everything is a web app.
> Although the levels of individual pesticides are within legal limits, activists fear the combination of multiple chemicals could be particularly damaging to people’s health.
This is the important part. Activists' fear should not dictate health policy. That should be done by scientists.
This organization, Pesticide Action Network, is opposed to GMOs and other modern farming techniques that kicked off the green revolution, seemingly on principle more than anything else. Consumers absolutely should be vigilant, because industrial food production has a bad track record. But with 7 billion humans to feed and counting, it is not realistic to roll back the green revolution.
E2E tests are still extremely limited and let bugs through, unless they also fuzz somehow. But that will make them even more flaky and difficult to debug, costing more time. It's a tradeoff.
Example: You run some number of operations and then batch them. If you run the exact same operations each time you test, you may not catch conflicts between them. Instead, you'd have to run a random number of, and type of, operations. But then test failures would become extraordinarily difficult to reproduce. You'd have to hope that your tests log exactly what the inputs were, and have a semi-efficient way to recreate those inputs locally.
I have experienced all the same problems that they outline. E2E tests require a huge number of human-hours to maintain, they're difficult to debug when they fail, almost always false positives, and bugs still get through anyway. But for many situations, there doesn't seem to be a better solution.
For most early stage startups, it seems that time would be better spent optimizing your deployments, rollbacks, and real time metrics so you can maintain a high velocity and roll back quickly when you make a mistake.
For more safety critical systems, the cost of maintaining E2E tests needs to be built into the total engineering cost for the project. It's a hidden cost that is often way bigger than you'd expect.
The food supply chain is already mostly automated. Food is not cheap because of the service economy. It's cheap because it only requires work from a very small percent of the population to feed everyone else.
How does this scale though? If you've got integration tests that include state, now you've got to either run your tests serially or set up and tear down multiple copies of the state to prevent tests from clobbering each other. As your project expands, the tests will take longer and longer to run. Worse, they'll start to become unreliable due to the number of operations being performed. So you'll end up with a test suite that takes potentially multiple hours to run, and may periodically fail just because. The feedback loop becomes so slow that it's not helpful during actual coding. At best, it's a semi-useful release gate. Is there another way?
Several years ago, I had to use this trick to automate an MSSQL install via powershell remoting. One of the operations the installer performed was disallowed for powershell remoting sessions. So I set up my script to create a service and then invoke the installer from the service, which worked perfectly. Whatever security checks they had on powershell remoting sessions weren't much more than security theater. Not sure if this is still the case, but it seems that this is still a useful trick.
If you could hop in a time machine at age 80 and go another 80 years into the future, would you? I absolutely would. Even if you do nothing with those 80 years, you're traveling forward in time, seeing technological advances, and watching the future unfold. And this is not even considering the chance that we discover a cure for senescence.
That is correct, to run an on-chain transaction is fairly expensive. There is a lot of ongoing work to address this: Layer 2 solutions like optimistic rollup, arbitrum, etc. EIP-1559 itself will address this problem on layer 1. But the ecosystem is not mature yet. If/when the scaling problem is finally solved, the legacy financial system will change rapidly.
This is really just semantics, because nullable strings do exist in go: *string. The difference is you pay a surprisingly severe performance penalty for them.
Using a map might not be faster as others have pointed out, but it's often more readable. The core library does this in several places. A map[someType]bool makes for nice, readable code:
From the perspective of the star, what impact does relativistic speed have on the rest of the universe? Does it also gain mass? Does that mean that an object accelerating to relativistic speed increases the mass of the universe from both frames of reference?
The brain fog is caused by rapid fluctuations of blood sugar. Low intensity aerobic exercise has a number of positive effects that all play off each other: You metabolize fat more readily as an energy source, which makes your body less reliant on carbs. This alleviates the exhaustion you might normally feel as your blood sugar crashes. And carbs (and especially refined sugars) are routed directly to muscles, blunting the insulin response and increasing insulin sensitivity.
It's actually not a thing in "all" endurance sports. Once you push into the realm of ultra endurance, athlete become so efficient at fat metabolism that they never "hit the wall" so to speak.
You can get the same effect with much less lifestyle disruption just by exercising. Specifically low intensity cardio trains your body to metabolize fat efficiently.