Second that. I was tepid on WSL on initial release, but recently decided to try a full switch after hearing good things and I'm glad I did. You're literally using a full Linux distro, it's really fast, and it even has neat integrations with windows like allowing use of windows explorer if you're inclined. And it's totally seamless to use with vscode.
HN user
Daynil
https://dlibin.net
I feel like super easy to host needs to be re-emphasized. We're talking about dropping a single binary into your server and you're off to the races. If only more things were so simple.
Nice, I've actually tried a trackball myself, but with the way I use my desk (sit/stand) it caused more problems than it solved (shoulder issues). Ergonomics is an art I suppose.
I love this new wave of tools coming out for mouseless computer use. Chronic mouse use has destroyed my wrist so I have to avoid using it as much as possible.
I love Shortcat's approach in general, indexing the UI. However, the reliance on the Accessibility API is actually a significant downside in the real world in my experience since so many apps don't properly implement it. I feel like Warpd is a good complement to this, you could use Hint or Grid mode as a fallback when the indexing approach fails.
I wish I could use shortcat or Warpd, but unfortunately I'm on windows. Curious if anyone has any good tool recommendations for windows? Currently, I'm using:
1. Vimium for Chrome (so good, wish I could just use it across the OS).
2. Hunt and Peck: https://github.com/zsims/hunt-and-peck has been my favorite for OS-level use, a simple version of shortcat for windows. But, it's not maintained and not as slick as some of these newer tools.
I haven't touched Python in years, and just recently came back to it. I was very pleasantly surprised to see just how much Microsoft has improved the tooling in VSCode with the recent update (https://visualstudiomagazine.com/articles/2021/05/11/vscode-...). I've only tinkered with it a bit, but it feels on par with the JS/TS experience in VSCode, which is surprising since those are native and have a more robust static types community.
I feel like by far the biggest impediment to my productivity is the knowledge that I have a meeting any time in the next two hours. Unfortunately, that's usually the case.
If you call requiring tens of thousands of dollars of maintenance medication treatment annually for life a solved problem, then absolutely!
Depends on your goals. If you're a software engineer, it won't make a difference, just send two queries to the DB and combine the results before sending them off. If you're an analyst, you'll often get repeated ad-hoc requests. If you have to run 2 queries, then stitch them together, each time you are asked for a report, you're wasting tons of (really boring) time. Even if you ultimately create some code to run and stitch the results together for you, it's just faster and easier to write 1 query wherever possible. Just let the database do the work!
I often read things that say that if you just write the query properly, you can trust the query optimizer to select the right plan. Just trust the optimizer! Unfortunately, in my experience, the more complex your query gets, the more opportunities the optimizer has to get it terribly wrong. I've learned to accept that, if the "clear/clean" version of the SQL (that the human likes to read and write) does not produce acceptable results, you just have to drop more explicit hints to the optimizer about what you want it to do. Query optimizers are truly awesome pieces of software, you just have to learn to work around their limitations when you hit them.
Memory is fundamentally limited anyway. Unless you're going to set up an Anki deck for your Zoom meeting notes, it's unrealistic to try to remember action points from every Zoom call we're on. The brain is an efficient machine, and it will naturally remember things that come up often enough. It works quite well on its own. I don't think I've ever sat down to try to remember how to write a for loop in whatever my preferred coding language is at the time - you just remember it after a few semi-regular lookups.
If you feel your memory is limited in an area you do value instant recall that doesn't inherently produce regular repetition, there are ways to steer your long term memory consolidation. For example, you can train yourself to remember everyone's names when you meet them, if you value that. If you don't value it or put any particular effort into training it, there's no reason to think you've gone senile if you forget the name of most people you meet the first few times.
For most things, I think the second brain solution is ideal. You value something enough to want to be able to recall it at a moment's notice, but you don't have any real need to instantly recall it without reference. We're not taking closed book exams outside of school [1]. This is where all the Zoom notes and book quotes are placed, where you can further digest, interpret and later recall them if and when they become relevant.
[1] https://fortelabs.co/blog/knowledge-building-blocks-the-new-...
I'm going to print this out and frame it.
Keto is absolutely the missing ingredient in most dieters' arsenal. I'm sure most IF'ers end up keto intermittently anyway, but you'd be more efficient at it if you develop the full metabolic machinery for it by specifically targeting it. Would you believe you can avoid feeling hungry without eating all day if you're keto? I never thought it was possible until I tried it. Now when I "forget" to eat when I'm in the middle of a coding spurt during lunch I don't subsequently feel like shit the rest of the day. In fact, I feel great. It's kind of a superpower.
There is an incredible amount of confusion surrounding cholesterol, mostly because of the incredible amount of bad/old/incomplete science around which many major medical associations base their recommendations.
To put it simply, using "cholesterol" as an indicator for anything is a completely oversimplified view originating in the 50s, when we didn't know enough molecular biology to know better. We've since moved on to breaking out LDL (bad) and HDL (good) cholesterol. However, as it turns out even that is too simplistic. There are further sub-classifications of LDL, such as large fluffy LDL and small dense LDL. If subclasifying LDL - Low-Density Lipoprotein - as "small and dense" seems counterintuitive, I agree. I feel like it's a result of the order in which we learned about all the forms of cholesterol, and a reflection of how complex the system is, and perhaps how much more we have left to fully understand it. As it turns out, so many of the perils of what we thought was caused by "high cholesterol", and then "high LDL/bad cholesterol" seem to be most strongly correlated with the small/dense LDL pattern. The irony is, we've been measuring everything but the main culprits, gaining an incomplete picture of what's actually going on, then ended up with wildly ineffective or harmful dietary recommendations as a result. A low fat high carb diet may reduce your cholesterol, but it can wreak havoc in so many other ways.
Bottom line is, eating a low carb, high fat diet increases all of your cholesterol (subject to individual variation), but seems to exert favorable effects on the overall ratio of the individual particles, which may be the important thing. If you're really interested in what's going on with your cholesterol, ask for a LDL particle size test, then you may be able to draw some more meaningful inferences. [1]
To me, it's a good hint that if every physical and mental aspect of your body improved on a diet, it's unlikely a bad thing. Best to discuss these things with your doctor though. Diet science is still a frustratingly murky field, so it's pretty hard to navigate right now. If you want to understand why, I highly recommend Good Calories, Bad Calories by Gary Taubes.
I used to use the snip tool all the time, but I switched to LightShot since they started indicating it would be deprecated. Glad I did, lightshot is so nice.
I don't understand how so many people can anchor their lives to work. If you do that, when you retire, you've lost your meaning of life. I have a list of things a mile long that I just can't get to because 40 hours a week is already spoken for. Early retirement speeds cognitive decline? Maybe if you sit on the beach and/or watch TV all day long, but that sounds kind of miserable if done for more than a few weeks.
It's important to understand the root of the arguments for and against both "not invented here" and "invented here". Both can be considered a poor mindset because it's thinking in absolutes. Certainly, everyone can agree there is no need to "write original code" for every problem you encounter. If there are libraries behind which there are teams of strong engineers (React, Angular), who work specifically on that problem and exhaustively test and iterate on it, why would you take time and productivity away from the development of your product in order to create your own solutions?
On the other hand, if the existing libraries/solutions don't fit your use cases and you spend more time customizing them to work than you do developing your product, or the existing solutions are out of date, unsupported, or appear slapped together, it would certainly be worth working on your own solution to see if you can find a better way. Likewise, experimenting with custom reimplementation is a great way to understand the problems libraries solve in an in-depth way, as Dan suggests, and you may even end up with something better. You just need to be realistic about whether it makes sense to make it yourself or utilize what exists.