Yeah my point was that without everyday challenges they lose meaning.
How does one create art without understanding struggle? How can someone find love without knowing how to keep it alive?
People need to make mistakes and then reflect deeply on them. We need to integrate our experiences with our beliefs and values in order to find meaningful expression.
I think the only exception to all of this might be abstract puzzles.
The fan increases air speed at the centre of the rotor, creating a low pressure zone which then sucks in surrounding air. So it helps to place the fan away from the window (roughly far enough that the wind cone "fits" the opening).
I would have loved to see that video 2 months ago. Thanks for sharing.
I tried to put the same kind of desk fan at the window, one way and then the other, for a few hours, to see if it had any effect. It was a very hot day but colder outside than inside. The building's concrete was likely still radiating the heat from the day before and there was no wind.
I see now that my observation at the time was right: it did nothing to the temperature, and it might have worked better if I had put the fan 1-2 meters away from the window, directing it towards the window. Now, whether the effect would have been significant anyway… we'll have to wait for next summer to know, I guess. I'm not particularly looking forward to it, though.
A 20 or 24" box fan still moves a LOT of air- you should get a decent breeze if you guide the air. the largest mistake I see is forgetting that a fan can't blow if theres no air coming or going- you need openings of equal size (larger is better) between where the fan is and where you want the air to come from/go.
An easy mental model is imaging the air is water. Close a door on a room and it'll fill up and block the hose.
PS: a box fan and a 5" thick MERV13 filter makes a heck of an air filter. 2" likely also will work. MERV13 is great, but some HVAC can't handle it, and it takes a couple passes (term is air exchanges per hour, I think) to capture what HEPA does in a single pass.
Not sure then. Maybe concrete really is too hot. Where I am adobe (clay, not company) buildings have traditionally been used in some areas to even out temperatures (desert region. Too hot in the day, too cold at night).
Huh? We've had pretty good translation in some languages in many general purpose contexts for a while. The LLM stuff if you're referring to that to my knowledge only has some gains in some languages in some contexts. Which is exciting no doubt.
Compared to google translate of yore, it’s gotten way more fluent thanks to transformers. Good translation relies heavily on context of course. Voice recognition and text to speech quality have increased dramatically. And near real-time (or as real-time as is possible given a pair of languages) is becoming feasible.
Meanwhile Switzerland is implementing e-ID which gives citizens private and public keys so they can sign and prove things without leaking their whole identity.
The USPS, with their existing delivery infrastructure and massive presence, would be a great fit for doing this in the US. Think like DoD CAC cards, but for ordinary citizens.
Sometimes a problem is a weird combination of hairy/obscure/tedious where I simply don’t have the activation energy to get started. Like, I could do it with a gun to my head.
But if someone else were to do it for me I would gratefully review the merge request.
Reviewing a merge request should require at least the same activation energy as writing the solution yourself, as in order to adequately evaluate a solution you first need to acquire a reference point in mind as to what the right solution should be in the first place.
For me personally, the activation energy is higher when reviewing: it’s fun to come up with the solution that ends up being used, not so fun to come up with a solution that just serves as a reference point for evaluation and then gets immediately thrown away. Plus, I know in advance that a lot of cycles will be wasted on trying to understand how someone else’s vision maps onto my solution, especially when that vision is muddy.
The submitter should also have thoroughly reviewed their own MR/PR. Even before LLMs, coders not having reviewed their own code would be completely discourteous and disrespectful to the reviewer. It's an embarrassing faux pas that makes the submitter and the team all look and feel bad when there are obvious problems that need to be called out and fixed.
Submitting LLM barf for review and not reviewing it should be grounds for termination. The only way I can envision LLM barf being sustainable, or plausible, is if you removed code review altogether.
Writing/reading code and reviewing code are distinct and separate activities. It's completely common to contribute code which is not production ready.
If you need an example, it's easy to add a debugging/logging statement like `console.log`, but if the coder committed and submitted the log statement, then they clearly didn't review the code at all, and there are probably much bigger code issues at stake. This is a problem even without LLMs.
Just call it “committing bad code”. LLM autocomplete aside, I don’t see how reviewing own code can happen without either a split personality, or putting enough time that you completely forgot what exactly you were doing and have fresh eyes and mind.
If person A committed code that looks bad to person B, it just means person A commits bad code by the standard of person B, not that person A “does not review own code”.
Maybe it’s a subjective difference, same as you could call someone “rude” or you could say the same person “didn’t think before saying”.
Person A as can commit atrocious code all day, that's fine, but they still need to proofread their MR/PR and fix the outstanding issues. The only way to see outstanding issues is by reviewing the MR/PR. Good writers proofread their documents.
My preferred workflow requires me to go through every changed chunk and stage them one by one. It’s very easy with vim-fugitive. To keep commits focused, it requires reading every chunk, which I guess is an implicit review of sorts.
Use of server reconciliation makes me think client-side reconciliation would be tricky… how do you preserve smooth editor UX while applying server updates as they arrive?
For example, if your client-sent request to insert a character fails, do you just retry the request? What if an update arrived in the intervening time? (Edit: they acknowledge this case in the “Client-Side” section, the proposal is to rewind and replay, and a simpler proposal to block until the pending queue is flushed)
From a frontend vantage I feel like there may be a long tail of underspecified UI/UX edge cases, such that CRDT would be simpler overall. And how does the editor feel to use while riding the NYC subway where coverage is spotty?
Both ProseMirror and the newer version of CodeMirror have a pretty elegant solution to this: each modification to the document is modeled as a step that keeps track of indices instead of node/text identities, and uses a data structure called a "position map" that the buffered steps can be mapped through to create steps with updated positions, which are then applied to your document.
In practice, it works quite well. Here's more info:
