4 ms·
I had to manually download all the invoices from a marketplace each month as they had no "download all" button. I created a script to (download list of invoice
by XCSme 7y ago
I had to manually download all the invoices from a marketplace each month as they had no "download all" button. I created a script to (download list of invoice names, get the invoice PDF based on name, save PDF in folder). All this was done by hardcoding paths and assuming stuff doesn't change, I have implemented this script in a few hours and have been using this it for over two years without any issues (doing each month in 2minutes what previously took 1 hour). What's the problem with that? Yes, sometimes I had small isues (eg. I was being rate limited trying to download PDFs, but quickly added a request delay to fix that issue and it worked again. I think it's a lot faster/more productive to implement what's quickest and adapt along the way, than spend a lot of time implementing the "perfect solution" which probably has the same chances of failing as the quick-and-dirty script.
- ozten 7y agoThis sounds perfect. I think her concern is if your script became the basis for a new product. Now your company depends on it running more often and no one is manually reviewing the output.
- XCSme 7y agoThe final point in my comment was that even if you spend a lot of time trying to make a more reliable product instead of a quick script, you still can't be sure it will never break in the future as the data source can become invalid at any point. Imagine a news website, they update their platform and suddenly all 404 pages actually redirect to first article/post in database instead of correctly returning 404, so your product would crawl the same data each day and say everything is fine, even though it's not. There are infinite such problems that can arise, so even if you have a well-thought product, it still needs some human sanity-checks and updates once in a while.