Do all the things like ++ or -- rants, post your own rants, comment on others' rants and build your customized dev avatarSign Up
bahua8085126dThe API codebase was probably in /opt or /usr. Or maybe, total amateur hour, in /home. I'm not 100% against splitting logs, but god damn it, they go in /var if they go anyfuckingwhere.
bittersweet30869126dOr don't use log files, log to bugsnag/sentry/rollbar.
A webserver should be automatically deployed from git, and you should be able to rapidly create & destroy webservers. So the server should contain nothing permanent.
Midnigh-shcode1197119d"separate PHP log files in there, split up by customer, so that each customer of ours (we have 120) has their own respective error log! (Why??)"
...are you kidding me? that's actually an amazing idea, no more filtering through global logs to find out what fucked up for the specific customer, now, instead, I can see all of his actions linearly! that's kinda great!
Midnigh-shcode1197119d"Conveniently enough, not ALL errors were being absorbed though, so I still knew the main error_log was working"
...CAREFUL, there's a difference between an error, and an exception, in PHP...!
"but instead ended up throwing an exception"
...yeah... just as I said...
devios16196119d@Midnigh-shcode I think a better idea would be to simply tag each error message with an identifier you could filter by.
But presumably that's the reason he did it, so that if a specific customer was having problems their log could be analyzed and the error figured out, but the problem is noticing the errors in the first place. I'd rather have everything go to a single log file that I can keep my eye on instead of trying to manage 100 or so separate log files.
Your Job Suck?
Take a quick quiz from Triplebyte to skip the job search hassles and jump to final interviews at hot tech firms
Get a Better Job