It's much easier to detect a single account abusing your API and ban them/require payment. Trying to police an endpoint open to the internet is like playing g whackamole
I would definitely recommend not putting complex logic like this in your cron definitions. Much more annoying to find and debug in the future. I prefer to write a short wrapper script that contains the test logic instead and track/version control it
Some of the alternatives that the author suggests (Slack, Discord, Matrix rooms) are so much worse to search for answers in. Stack overflow has many disadvantages, but it is extremely good at being a publicly searchable repository of answers to common questions
Yeah this is the biggest problem with Discord (and similar platforms) as an alternative. Discoverablity sucks. Even if you are aware and have access, finding useful information is a bitch.
The "closed duplicate" thing is blown away out of proportion than it actually is. I'm convinced people are just pooping on Stack Overflow, not because it's bad, but because they just like complaining about things.
>The "closed duplicate" thing is blown away out of proportion than it actually is.
I hardly use the site and it's happened to me multiple times. I'm sure people that rely more heavily on it see it all the time. I suppose it depends on the sorts of topics you're looking for help with, much like wikipedia or subreddits, a lot of the little niches are seemingly ran by assholes that would rather delete stuff than actually help people find information.
I agree, so much so that about 10 years ago I built a product that did this!
I launched to lukewarm reception, actually applied to YC with it and didn't get much of a look, nor an interview :-) and after a bit of (though certainly far too little) further hustle gave up on it due to circumstances leading me on another path.
Anyway, I was a tiny bit vindicated when about a year later I noticed Stack exchange themselves did a similar product, but as far as I know, it never really hit. They would advertise it in the side banner for quite a few years but it eventually seemed to go away.
It's weird that it didn't work, it always did seem like an incredibly good idea to me - just so good, it's obvious. If such a thing existed, it'd add so much to any company onboarding experience at a minimum, and would also have obvious ongoing value.
And it just seemed like a great strategy to get useful and up to date documentation: to gamify it. There's just an inherent incentive to become the 'Jon Skeet' of your organisation as it were, rather than making documentation this largely anonymous, thankless afterthought it often becomes in practice despite best intentions.
If it's any consolation, I feel like I've been pitched 10 different versions of this product over the years and I've encountered a lot of startups trying to do the exact same thing. You probably didn't get any YC traction because they'd seen the same thing so many times before. I wouldn't be surprised if we could find a YC batch or two that already contained this exact idea.
The problem that comes to mind is that every question and answer that’s posted is something you have to maintain as part of your docs as they rot over time.
I’d be curious to hear what the common solutions to that are.
Maybe it can be used as a limbo to gather FAQs that get crystallized into the real docs and then deleted.
I think a reasonable solution is “people who find the answer should observe that the question was asked eight years ago, and certainly double-check the answer”. If it’s a question about company internal codebases or operations, then you should have access to see the code or resources the answer is talking about.
Good documentation, communication channels and a healthy work environment where colleagues can communicate and help each other are much beneficial than an internal SE.
Documentation doesn’t solve the problem of Q/A situations.
Internal Stack Exchanfes are (were? I’m not sure whether they discontinued it…my old company had one but new one doesn’t) is really good at converting chat style communication into a permanent easily searchable record that can also be easily updated.
You can also avoid many of the pitfalls with stack overflow around over aggressive moderation (not really needed since the volume of questions won’t be as high), or inappropriate commenting of any sort (reach out to the individual directly or even to their manager), etc.
They still sell Stack Overflow for Teams (renamed Stack Overflow Internal or something like that), but the cost is pretty astronomical. If you want private Q&A in your company/school/etc and you've got anybody with the tech clues, you're better off downloading and setting up one of the free tools.
This blog post talks as if mocking the `open` function is a good thing that people should be told how to do. If you are mocking anything in the standard library your code is probably structured poorly.
In the example the author walks through, a cleaner way would be to have the second function take the Options as a parameter and decouple those two functions. You can then test both in isolation.
> If you are mocking anything in the standard library your code is probably structured poorly.
I like Hynek Schlawak's 'Don’t Mock What You Don’t Own' [1] phrasing, and while I'm not a fan of adding too many layers of abstraction to an application that hasn't proved that it needs them, the one structure I find consistently useful is to add a very thin layer over parts that do I/O, converting to/from types that you own to whatever is needed for the actual thing.
These layers should be boring and narrow (for example, never mock past validation you depend upon), doing as little conversion as possible. You can also rephrase the general purpose open()-type usage into application/purpose-specific usages of that.
Then you can either unittest.mock.patch these or provide alternate stub implementations for tests in a different way, with this this approach also translating easily to other languages that don't have the (double-edged sword) flexibility of Python's own unittest.mock.
> This blog post talks as if mocking the `open` function is a good thing that people should be told how to do. If you are mocking anything in the standard library your code is probably structured poorly.
Valgrind is a mock of standard library/OS functions and I think its existence is a good thing. Simulating OOM is also only possible by mocking stuff like open.
> Valgrind is a mock of standard library/OS functions and I think its existence is a good thing.
That is mostly wrong.
Valgrind wraps syscalls. For the most part it just checks the arguments and records any reads or writes to memory. For a small number of syscalls it replaces the syscall rather than wrapping it (for instance calls like getcontext where it needs to get the context from the VEX synthetic CPU rather than the real CPU).
Depending on the tool it can also wrap or replace libc and libpthread functions. memcheck will replace all allocation functions. DRD and Helgrind wrap all pthread functions.
$ cat test.c
void main (void) {
malloc (1000);
}
$ make test
cc test.c -o test
$ valgrind --leak-check=full --show-leak-kinds=all -s ./test
Memcheck, a memory error detector
Command: ./test
HEAP SUMMARY:
in use at exit: 1,000 bytes in 1 blocks
total heap usage: 1 allocs, 0 frees, 1,000 bytes allocated
1,000 bytes in 1 blocks are still reachable in loss record 1 of 1
at 0x483877F: malloc (vg_replace_malloc.c:307)
by 0x109142: main (in test.c:2)
LEAK SUMMARY:
definitely lost: 0 bytes in 0 blocks
indirectly lost: 0 bytes in 0 blocks
possibly lost: 0 bytes in 0 blocks
still reachable: 1,000 bytes in 1 blocks
suppressed: 0 bytes in 0 blocks
> vg_replace_malloc.c:307
What do you think that is? Valgrind tracks allocations by providing other implementations for malloc/free/... .
Are you trying to explain to me how Valgrind works? If you do know more than me then please join us and become a Valgrind developer.
Mostly it wraps system calls and library calls. Wrapping means that it does some checking or recording before and maybe after the call. Very occasionally it needs to modify the arguments to the call. The rest of the time it passes the arguments on to the kernel or libc/libpthread/C++ lib.
There are also functions and syscalls that it needs to replace. That needs to be a fully functional replacement, not just looking the same as in mocking.
I don’t have any exact figures. The number of syscalls varies quite a lot by platform and on most platforms there are many obsolete syscalls that are not implemented. At a rough guess, I’d say there are something like 300 syscalls and 100 lib calls that are handled of which 3/4 are wrapped and 1/4 are replaced.
> Are you trying to explain to me how Valgrind works?
Sorry that wasn't my intention. You are a Valgrind developer? Thanks, it's a good project.
It seems like I have a different understanding of mocking than other people in the thread and it shows. My understanding was, that Valgrind provides function replacements via dynamic linking, that then call into the real libc. I would call that mocking, but YMMV.
I think when testing code with an open call, it is a good idea to test what happens on different return values of open. If that is not what you intent to test for this method, then that method shouldn't contain open at all, as already pointed out by other comments.
If the code's running in a space shuttle, you probably want to test that path.
If it's bootstrapping a replicated service, it's likely desirable to crash early if a config file couldn't be opened.
If it's plausible that the file in question is missing, you can absolutely test that code path, without mocking open.
If you want to explicitly handle different reasons for why opening a file failed differently, by all means, stress all of that in your tests. But if all you have is a happy path and an unhappy path, where your code doesn't care why opening a file failed, all you need to test is the case where the file is present, and one where it is not.
Modifying the file system to be would be kind of like mocking to me. I very much, don't want my daemons or user-facing applications to just crash, when a file is missing. That's kind-of the worst thing you can do.
> Modifying the file system to be would be kind of like mocking to me.
Modifying the file system's implementation would be. Including a valid_testdata.txt and an invalid_testdata.txt file in your test's directory, however, is not 'modifying the file system', any more than declaring a test input variable is 'mocking memory access'.
> don't want my daemons or user-facing applications to just crash, when a file is missing
If the file is important, it's the best kind of thing you can do when implementing a non-user-facing service. The last thing you want to do is to silently and incorrectly serve traffic because you are missing configuration.
You want to crash quickly and let whatever monitoring system you have in place escalate the problem in an application-agnostic manner.
Details matters, but good test doubles here are important. You want to capture all calls to IO and do something different. You don't want tests to break because someone has a different filesystem, didn't set their home directory as you want it setup, or worse is trying to run two different tests at the same time and the other test is changing files the other wants.
Note that I said test doubles. Mocks are a bit over specific - they are about verifying functions are called at the right time with the right arguments, but the easy ability to set return values makes it easy to abuse them for other things (this abuse is good, but it is still abuse of the intent).
In this case you want a fake: a smart service that when you are in a test setups a temporary directory tree that contains all the files you need in the state that particular test needs, and destroys that when the test is done (with an optional mode to keep it - useful if a test fails to see debug). Depending on your situation you may need something for network services, time, or other such things. Note that in most cases a filesystem itself is more than fast enough to use in tests, but you need isolation from other tests. There are a number of ways to create this fake, it could override open, or it could just be a GetMyProgramDir function that you override are two that I can think of.
Even in the case you mention you really shouldn't be overriding these methods. Your load settings method should take the path of the settings file as an argument, and then your test can set up all the fake files you want with something like python's tempfile package
There are a number of different ways to solve this problem. I too use the path of settings in my code, but I'm not against overriding open and all the other file io functions. Of course this article is about python which has different abilities than other languages, what is best in python is not what is best in other languages, and I'm trying to stay at a higher level that a particular language.
> This blog post talks as if mocking the `open` function is a good thing that people should be told how to do.
It does. And this is exactly the problem, here!
> TFA: The thing we want to avoid is opening a real file
No! No, no, no! You do not 'want to avoid opening a real file' in a test.
It's completely fine to open a real file in a test! If your code depends on reading input files, then your test should include real input files in it! There's no reason to mock any of this. All of this stuff is easy to set up in any unit test library worth it's salt.
> then your test should include real input files in it! There's no reason to mock any of this.
That's okay for testing some branches of your code. But not all. I don't want to have to actually crash my hard drive to test that I am properly handling hard drive crashes. Mocking[1] is the easiest way to do that.
[1] For some definition of mock. There is absolutely no agreement found in this space as to what the terms used mean.
I think the sandwich demo is really good. Once you establish the sandwich idea you can start zooming out to OK now you have a cook making multiple sandwiches, now you have a whole kitchen, and use that to talk about levels of abstraction and how SWEs go from solving one specific problem to more general problems by reusing techniques
I think the "joke" is if the US government orders a company to hand over that data, the fact that the servers are physically in the EU won't stop anything
It's one thing if they require the copy of data, and another thing if the President wakes up in a bad mood and orders deleting all the data. Imagine if the whole computing infrastructure for power plants, public transportation, banks, payment systems, large companies gets deleted in a minute.
You should not host the critical data on other country's servers.
I created NPM account today and added passkey from my laptop and hardware key as secondary. As I have it configured it asked my for it while publishing my test package.
So the guy either had TOTP or just the pw.
Seems like should be easy to implement enforcement.
Crucially, it would have to be set up so they need to use the hardware key when pushing any changes. Just requiring a hardware key as a login method does nothing to protect against token stealing, which I believe is the most common form of supply chain attack right now.
