I've used prosemirror enough to have written custom nodes, commands, and custom code around its collaboration model. I got good results with all of this and I don't know any other platform that could have matched it.
The docs are thoughtful. There's an up-front learning curve to understand the architecture. When doing highly customized things, I referred to the source when needed.
For standard rich text, there are a lot of options. Prosemirror shines when you want to build on it as a platform.
They're just saying that hotter air can hold more water, so if the temperature rises, you need to add water to the air, to keep a constant water vapor pressure, and presumably plants have a preferred vapor pressure more than a preferred humidity %, as the same humidity % at different temperatures has a different vapor pressure, is how I read it.
Doesn't humidity already take this into account? It's measured in relative humidity which is the percent saturation of the air. So RH goes down as temperature goes up, unless there's more evaporation happening.
Apparently it doesn't. From what I read, relative humidity is maximum possible humidity divided by actual humidity (probably not the correct terms), whereas vapor pressure deficit is maximum possible minus actual. Fraction versus difference. So the same vapor pressure deficit could correspond to 80% relative humidity at one temperature, and 85% relative humidity at a higher temperature.
Depending on where you live and what plants you are growing and how picky they are, you may need to water less in hot weather (which is counterintuitive to most people). Unfortunately that can either be really good or really bad advice depending on your climate, the time of year, the type of plants you grow, etc so it's not a hard and fast rule, but especially if you have plants that struggle with molds, mildews, and/or fungi, keeping the top of the plant dry and letting the top part of the soil dry out regularly can be the difference between a healthy robust plant and a sickly one.
The safest solution is an in-ground drip system, but that's also one of the hardest.
Honestly the best advice is to find a nice, elderly/retired person (usually women, but not always) who is into gardening in your area and have discussions with them. Bring pictures of your plants to the nursery and/or gardening store, or join a Facebook group or something and you can usually find people. Don't get discouraged if the first few people don't work out. Particularly if you are young, you'll get a lot better results if you are overly respectful and polite, at least until you get to know each other better. Give them the benefit of the doubt if they say something you find offensive and just observe/listen rather than lecture.
Many older generations can be hesitant to engage with younger people because the social customs are just so different and it can make them uncomfortable. Ideally try to watch them do what they do (planting, pruning, tending, mulching, etc), because if you are on HN you may be more scientifically minded, but most of these people just do what they do and don't even think about it or even notice sometimes. It's very much an art to them. If you ask them things like "why do you mulch there and why do you use grass clipping" be prepared for them to have a terrible answer that doesn't make sense, but know that they are probably doing it because it works, but the reason why it works might be an exercise left for you to find out. A lot of them have generations worth of muscle memory and convention that is all good stuff, so don't discard it just because they can't explain why they do it.
This is what they're referencing with that comment. I don't know that there's a "Japanese" style of Ruby, as much as there is a style that looks and reads more like systems code.
"The primary distinguishing characteristic of systems programming when compared to application programming is that application programming aims to produce software which provides services to the user directly (e.g. word processor), whereas systems programming aims to produce software and software platforms which provide services to other software..."
Reasonable, but I'm still not sure what makes code "systems code" or not, by that definition. Is it code that doesn't have a UI/display component mostly, as an observation that lots of Japanese Ruby programmers write code that's distant from the UI layer? Or something else?
I started using Foam[0] a few years ago, but the more I used it, the more I dropped all the tedious bits, and it became nothing more than a big, evolving markdown repo.
I switched from vscode (back) to vim, and it has worked as well or better than it did before. I follow my own rules. I like the Zettelkasten idea of one idea per card, but if I put more related things in the same .md file, that's OK. I didn't like the flat directory structure, and so I have dirs organized by category. My /bar directory is inside my /cooking directory, and for whatever reason, that makes sense to me. Ripgrep doesn't care, and I always find what I'm looking for.
This markdown hierarchy, that still lives in a repo called "foam", has become indispensable to me.
