fredifrum

To the author: this is AWESOME.

I find myself caught in the y/t/f <enter> loop all the time. I use a site blocker, but if I do want to visit a site, I end up turning off the blocker and forgetting to re-enable it. This seems like much a better solution that allows me access to the sites I need, but ensures I don't get lost in them, and tracks my usage.

I am seriously so pumped about this, funny that I needed to visit one of my blacklist sites (hacker news) in order to find this. Please keep us posted with updates (settings page of the app?), if I continue to use this I'd be happy to pay for it in the future.

One thing I'd love to be able to do right now is whitelist certain times in the middle of the day. For example, lunch. Punching in 30 mins on a site is an easy fix, but it'd be nice if that were built in.

battery replacements aren't a thing for AirPods. You can send them to Apple to be recycled, though.

I was also wondering this. I use Ideavim for IntelliJ as my primary editor. It is awesome, it will read your vimrc and allows you to set up mappings for any editor action.

I think it does poll, and it's just looking for a diff in the previous message.

It's perfect for a bedside table. Instead of needing to fumble around for a cable when I'm tired, I just place it on the mat. It's handy to have several pads around the house and office so your phone can always been juiced up. My phone rarely goes below 50% anymore, and I basically only bother with cables when I'm traveling. It's awesome.

OK, I get that you don't like unit tests. You also seem to have a very strict and unhelpful definition of what a unit test is. I don't really care for the academia of it, I just want to know that my code works. So, if you call it a unit test or an integration test or a functional test or a behavioral test - whatever. The important thing that it allows me get some idea of whether or not the code is doing what it's supposed to do.

What do you propose instead of testing? Manually QA every single piece of the system for every change? Not a lot of companies have the headcount for a the fleet of QA people that would require.

It still seems like the core of your argument is "Some things are hard to test, so you might as well not test anything at all" - which I really don't buy.

> How about you just answer me this question: Did you still see significant bug volumes after implementing the unit tests for the FileProcessor ?

Kinda tricky to answer this, since there were test for this class from the start. But, overall the answer is "no" - we did not see significant bugs in that class. Occasionally we'd get a bug because the SFTP connection failed, or execution took to long and the connection closed - the type of bug that to you seems to negate the value of uniting testing the FileProcessor. But, without the unit tests for the FileProcessor, I'd have those bugs plus more bugs/bad behavior in the business logic. How is that better, exactly?

The idea that tests reduce performance is ridiculous. Improving performance requires making changes to a system while ensuring it's behavior hasn't changed. This is exactly what testing provides. Without tests, you can't optimize the code at all without fear of introducing regressions.

The fact that something might go wrong in the integration test doesn't mean unit tests for the core logic aren't helpful. Besides, you're probably going to be using an external library for the SFTP connect, so it's very likely to go just fine.

And you can totally use unit tests for what I'm describing. Two classes

- SFTPHandler. Connects via SFTP, downloads latest files off the server, passes contents as a string to the processor class `FileProcessor.process(downloaded_file)`

- FileProcessor. Has one public function, process, which processes the file - doing whatever it needs to. This function can then very easily be unit tested, just passing strings for test files into the function. You can also refactor the `process` function as much as you like, not needing to worry about the SFTP connection at all. The `process` function probably calls a bunch of private functions within that class, but your unit tests don't need to worry about that.

I've used a setup like this in production, it works just fine, and allowed us to improve the performance of the file processing logic and make changes to it very easily and often - without worrying about regressions to the core business logic.

The SFTP file processor is actually a quintessential example of how unit tests can help new developers edit existing code.

A unit test for the processor would mock out all of the SFTP fetching, or move that to a different class, and focus on only the core business logic of processing the file. The core logic could easily be unit tested, and changes could be made to the file processor without needing to replicate the entire SFTP environment in order to determine if there were regressions in the core business logic.

The alternative is needing to spin up a test SFTP environment, or somehow do that mocking in my manual test, just in order to do something as simple as refactor the class or make a small business logic change. A unit test empowers any developer to make those changes, without needing much knowledge of the environment the code runs in.

You are able to go without tests because you're writing entire apps on your own. You know what each file, class, and module is supposed to do, and how to test it for regressions manually.

If you're working on a large team with a large suite of applications, this isn't the case. Very often I'll need to make changes to code that I don't explicitly own, or that I've never seen before today. If this code doesn't have tests, this is a recipe for disaster. I don't really understand what this code is supposed to do. How do I know that my change didn't break any existing functionality? Is it obvious how or even possible to test the functionality in this file manually? Maybe it's a background job that processes a file off of an SFTP server, how long will it take me to set up a manual test for that?

It's also about iteration time. Automated tests allow to you check the correctness of every single change nearly instantaneously. I don't want to need switch to a browser and wait for a form to submit just to check that my code still works after a minor refactor, or to ensure that my typo was fixed successfully. Tests mean that code is much more likely to be refactored often, and will lead to much cleaner and easier to maintain codebases.

Splitwise will continue to work and run. The API is not being shut down, they are simply not authorizing new API applications. The article is wrong and massively misleading.

The article is massively wrong and misleading. The API is NOT being shut down. Current applications can still work, but new ones are no longer being accepted.

See this tweet from Venmo:

https://twitter.com/venmo/status/703353293326655488

> Don't worry, the Venmo API is still available to existing users, we're just not accepting new beta users for now.