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.
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.
The key distinction here seems to be that it uses an in-core database (SQLite), whereas a Go project may depend on an out-of-core database like Postgres, which would then also have to be deployed.
For many projects (especially hobby projects where downtime is tolerable), the former is probably quite sufficient.
Not really because then projects started needing multiple containers and orchestration, and might be fussy about the order the different services come up.
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.
If you're already using Vimium, I suggest trying qutebrowser, which takes keyboard accessibility to a whole new level, by making it a first-class feature for the entire browser.
It does basically cut out the mouse, and had a several-days learning curve for me, but after that it's pretty great. Here are some cool features, off the top of my head:
* Python-scriptable, though I haven't figured out how to use this yet.
* Bind javascript bookmarklets to a keyboard shortcut (use :bind with the jseval command)
* Toggle not only javascript, but image loading and a whole slew of other features, with a keyboard macro.
* Vertical tabs.
* All config is adjustable via commands.
* Keyboard macros like "pop tab into a new window", "clone tab", "close all other tabs", etc.
* Text selection using the keyboard.
* Quite similar keyboard dynamics to vim.
It has a built-in ad blocker, and you should run :adblock-update when you first use it.
Another browser which is similar, but which I haven't gotten into as much, is Luakit.
I have used a trackball for many years since my wrist started bothering me, and I love it. I am right-handed, and I use Logitech's 575 and MX Ergo. I prefer the Ergo, even though it is more expensive. I keep it beside me on the couch where I sit. That way my elbow makes a 90 degree angle. Very comfortable. My keyboard is on my lap and my monitor at eye level.
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 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.
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!
> 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.
This isn't true if you have certain use cases in your application, pagination being one of them. There's no simple way to implement pagination when you have two or more queries that return and unknown number of results and you're tasked with maintaining a consistent order across page changes.
If you make a single query do all the work, it's easy to implement paging in any number of ways, the most performant being to filter by the last id the client saw. If your users aren't likely to paginate too far into the data, LIMIT and OFFSET will work fine as well.
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.
His point was more along the lines of it being poorly designed.
Evolution isn't going to nicely separate functionality into clean, single-purpose biochemical pathways.
It's going to overload something that it already has to support a new feature, leading to a rat's nest of intertwined effects.
The hard part in drug development isn't affecting your target: that's pretty easy to guarantee with modern tools. It's finding out that that target also governs 10 other, completely unrelated bodily functions.
