TLS termination is neither required nor enabled by default, right?
2,918 karma · joined October 31, 2013
[1]: https://www.space.com/aurora-colors-explained
[2]: https://www.nps.gov/articles/-articles-aps-v8-i1-c9.htm
The distinction between using “a” vs “an” is one based on the immediately proceeding syllable sound rather than the letter. If it’s proceeded by a vowel, then use “an”, and if it’s proceeded by a consonant, use “a”.
Because “LLM” is pronounced “el el em”, the first syllable sound is “eh”—a vowel.
The same letter may need different “a”/“an” article based on how the word is pronounced. For example “an LLM” vs “a layer”.
See this for someone smarter than me explain it: https://www.merriam-webster.com/grammar/is-it-a-or-an
I would love to be able to just "walk through" and look around in 3D my house before the insulation & drywall went up. I wouldn't want to pay for those 3D house tours that realtors are using now if I built another house and wanted to do something similar.
I usually hate "infinite scroll" on say a timeline feed, but for calendar, it is exactly what I need as I very often move between months when I'm looking at my calendar.
Is there an extension in Firefox that'll bring the infinite scroll to calendar? Anything on the roadmap officially for that UX?
What happened was this: I requested a ride, and it was confirmed by the driver who was about 15 minutes away. After waiting 10 minutes, the driver would cancel (and presumably go pick up someone else who had a higher fare). This happened literally 3 times, and I sat outside at the curb waiting for 30+ minutes. I gave up, requested a ride with Uber instead which had a similar price (<$2 delta, I think). The Uber driver not only not cancel on me but also was significantly closer causing me to wait less from the moment I requested a ride.
Yes. I wrote: "I was recently just one of those affected by a random issue!"
I don't notice any measurable latency. Heroku exposes their postgres instances directly on the public web (secured with a strong user/pass combo of course), so there's no difference, networking-wise. There's no additional reverse proxy or some tunnel to route through.
Heroku was the cheapest for the very small instance I needed.
The connections are made on-demand and are insanely fast.
Both services have been flawless so far at a much better cost/value proposition.
I understand there's the Rust Book, Rustlings, and Rust By Example at https://www.rust-lang.org/learn. Are there other good resources? Does anyone have a strong suggestion on which of those official resources I should start with?
I have authorized heroku access for fly.io page and yet no projects or applications appear in the last dropdown. Is there currently a known issue with this?
One option I hope you will provide--that I hope is easy enough that you would actually consider--is to provide a key cap set that is completely blank, or is very minimal. I don't need anything printed on my keyboard, and I would prefer to not see such a gorgeous keyboard with all that white printed on it, especially the number caps.
For example, I inputted married, with no dependents with $500,000 salary and in 1977, the federal amount was $299,864 and in 2020 was $133,947. I assume these amounts can be compared without further adjusting for inflation?
Tangentially, did federal taxes really come down that much?
If I have 5 commits that are all whitespace changes, I'll use git rebase to group them into one commit before I push.
If it's a large, complex PR, then I'll reorder my commits and pick-and-choose chunks from the many commits so that they make sense in a progression. For example, I might just add one new component in the first commit. Add a second component in the second commit. Third commit might be integrating those two components into the system.
If my PR consists of both "cleanup" like running black on python, then I'll make that its own commit instead of littering actual functional changes within cosmetic ones.
I try to make it as easy as possible for my reviewers to review my code and actually catch mistakes. I also tell the reviewers to look at the commits separately and not to look at the entire diff which can sometimes be hundreds of thousands of lines of code. Even a large PR with 500+ lines of changes can be easy to review if you structure the commits right. (It's really like many PRs within one PR.)
You may ask, why not have separate PRs then for each commit? Sometimes, that makes sense when it's so large that it's worth having an integration branch that lasts weeks or months. Sometimes, it's not possible to just merge that one commit due to problems it'll cause with compilation or linting or other issues. Also, with separate PRs, it can be more costly (in both CICD resources and the dev's time) to do automated testing on each commit separately.
With some practice, the git rebasing and reordering or restructuring commits is not as difficult as it sounds, especially with the aid of a good git GUI (I like Fork.app) that lets me choose exactly the chunk to commit from a particular diff.
Once I got really comfortable with this workflow, what I'll actually starting doing is... when I'm done with something and ready to put up a PR, I'll flatten (fixup) all my commits into one, and then I'll revert it and commit that. Then I revert the revert but instead of committing that revert-the-revert, I'll stage it. This gives me all of my changes in a staged state. Then I'll pick-and-choose chunks from that entire diff to craft a "narrative" like I was describing before. Once I have everything in the right order, I'll drop the first two commits to get of the initial and revert commits.