> I especially dont see what is gained by writing the test after.
I assume you mean versus writing it first, rather than versus not writing it at all.
I've found that TDD works well for bottom-up coding, but not so well for top-down.
With bottom up, I can write the test for a piece at the bottom, write the code to pass the test, and move on. With top-down, if I write the test first, it might be a long while before I have that top-level working, because the bottom bits don't exist yet.
When I feel it's better to write things top-down, I'll often use TDD for the bottom bits I need to write, but for the bits above that, I'll write the tests "on my way back up".
You can follow a community from any software that speaks ActivityPub. So you can be on Mastodon and post/comment to any Lemmy community.
Alternatively, if you want to use lemmy's interface, you can create your own instance and use it only to subscribe to remote communities. This way, your identity is one place but the commuities is in another.
The unfortunate problem being that anything beyond downloading a program and making an identity is too high of a bar for the average person on the Internet. So as long as this friction of choice exists within AP software, mass adoption is impossible and authoritarian social media like Meta and Reddit will continue to thrive.
When people search through alphabetical listings, they usually don't use plain old binary search, but instead use something like interpolation search. For example, if you want to find the word "xylostroma” in the dictionary, you aren't going to start in the middle. Instead, you'll start about 90% of the way through, and then make adjustments based on how far off you were.
Yeah but that is only optimal if you know the general location. Often when you have a bug you don't know where it snuck in, especially if it's something like a race condition.
About 20 years ago I had two computers at work: a Windows PC and a Sun workstation. I used Vim on both. I knew about the vi ]] command, and I'd learned some Vim script. I thought it would be great to have a key binding to take me to the innermost surrounding curly braces, so I wrote a vim script to do this. I picked ]} and [{ as the key bindings.
One day I used the key binding and then realized a few minutes that I hadn't installed the script on that computer yet. After some searching in :help I realized that I'd not only reimplemented a feature that already exists in vim, but I mapped it to the exact same keys.
That's what comments in the other post said, but I don't know if there's new info in the last 3 years.
Looking at their site, the features sound good (though I'm not thrilled about Plaid integration, TBH). They aren't a real bank, though, from their own site:
> Mercury is a financial technology company, not a bank. Banking services provided by Choice Financial Group and Evolve Bank & Trust®; Members FDIC.
The page that links to, https://mercury.com/how-mercury-works, seems to suggest that by using "sweep networks", their clients are able to get even better than normal FDIC protection. Their FAQ also says "Mercury checking and savings deposits are FDIC-insured up to $1M. As a broader effort, we are working on expanding all coverage up to $4M. You can learn more about FDIC insurance through their own FAQ here."
The marketing copy sounds good, but I'm curious to know what others think about these claims.
> 5. When merge happens a dev's PR is squashed into one commit that gets appended to `main`
I don't know if GitHub supports this, but GitLab has a semi-linear history feature. When enabled, it won't let you merge unless a fast-forward merge is possible, but it never does a fast-forward merge.
This give you (IMHO) the best of both worlds: your history is pretty linear and easy to reason about. The "first parent" of each commit on the main branch is a linear chain of the main branch history. However, for more complex changes you don't have to squash. Those intermediate commits will be on the second parent of merges, so they're easy to filter out:
M─┐ [main] merge
│ o commit
M─┤ merge
│ o commit
M─┤ merge
│ o commit
│ o commit
M─┤ merge
│ o commit
> Yes, it can be annoying if your developers are committing nonsense, but then just tell them to not do that, or to rebase locally before pushing.
I'm pretty sure rebasing locally is exactly what the person you're arguing with is arguing for. The original comment in this thread was saying you should never rebase, always just merge.
I assume you mean versus writing it first, rather than versus not writing it at all.
I've found that TDD works well for bottom-up coding, but not so well for top-down.
With bottom up, I can write the test for a piece at the bottom, write the code to pass the test, and move on. With top-down, if I write the test first, it might be a long while before I have that top-level working, because the bottom bits don't exist yet.
When I feel it's better to write things top-down, I'll often use TDD for the bottom bits I need to write, but for the bits above that, I'll write the tests "on my way back up".