Web Dev full-stack [LAMP] since 2005, but much heavier on the JS stuff these days.
Jack of all Stacks, Master of some.
Always looking to learn new things. Always glad to help out, just ask.
Location
Atlanta, GA
Education
B.S. in Biochemistry 2004, M.S. in Computer Information Systems 2007
Depends on the application and the stack used to deploy it. That should determine what tools are available. Automated ones are nice and can be used to send you notifications of problems.
I would like to point out that every single service that does error/logging/analytics for you, is crap. There, I said, they're crap. They'll for example give you beautiful graphs of how many 404s you have per hour, but they won't show you why it 404d, or how to address it and fix it. They'll give you lots of numbers that are great for meetings with people who also don't understand what is involved in fixing code, but who probably decide what your budget will be for the next six months. They'll show you pretty charts, but can't show you the exact line in the code that threw the error, so you have no idea how to fix it. Don't bother using them.
The best logs you can have are your own. As you write the code, learn to account for errors and exceptions and capture as many of them as you can in your actual code, send correct api responses, and display proper useful messages to users. And always have an "ELSE" that SHOULD never happen and make sure even that logs to a text file somewhere or into whatever tool/service you use to view logs.
For JS stacks everyone hypes up linters, but...really no one gives a damn if you have an empty space at the end of a line or lines longer than 80 characters or if you use spaces over tabs [Tabs ftw]. In JS 99% of your errors will be "undefined" or unfinished promises. Use async/await and check for undefined/NaN/null always and you'll have nearly zero errors your linters actually help solve.
UI/UX errors are just as important as DNS errors, 301s, 404s, 500s, api endpoints failing, bad database queries, and finally, syntax errors.
When something goes to production there should be ZERO syntax errors. If there are any, it means you as the dev failed to even load the page and perform the interactions available on that page or you'd have spotted the syntax errors [regardless of language]
Make sure you have access to view actual log entries. Eg. Server access logs, and error logs for whatever language or framework or tool you're using.
On Apache/Nginx servers those logs are easy to find and easy to review to find the exact point of error in the code so you can fix it.
On automated deployments it can get harder because more things are obfuscated and you should plan ahead and make sure you know where to find the information you need.
Mainly, work with someone who knows their stuff. That will save you more time than any of the above. Just work with someone who actually knows how to debug things and learn from them. This is how you get better at it.
For every stack there's a different way to approach this. For ever language there are different places to look for errors. Each one is fairly simple and no one knows all of them, however any time you're stuck just google it and you should be able to find where errors are logged for that language or stack no problem.
I know I hit on a lot of subjects here, but there's a lot more I didn't even get to, it all just comes down to what languages and stacks you are using, which should then dictate your deployment processes tied to them and thus how you store error logs and review them.
Started coding at the age of 13, now a professional software engineer and Scrum Master, creating and maintaining enterprise solutions. Eat - Sleep - Code - Lift - Repeat 💪🏾
So many subjects in your answer, I love it!
In the past I always stick to the error logs I could see on servers and tried to think of possible errors upfront and handle them on the code.
Then a lot of react side projects came in and I learned about the Error Boundary.
I have a couple of apps running smoothly. But one in particular had reports of strange behaviors and almost every case could be tracked back to data issues.
But it was hard to get proper feedback from users and I was searching for something to catch unhandled errors, be able to push my handled ones too and get not only a stack trace but also some context which user it was, what his actions roughly were before and so on.
I totally agree with you that it would be best to implement my own logging. But because this is just a side project I wanted to have something with less effort. I am even okay with sacrificing the luxury of custom handling if an existing library or service would enable me to implement it rudimentary.
I am testing bugdnag at the moment.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Depends on the application and the stack used to deploy it. That should determine what tools are available. Automated ones are nice and can be used to send you notifications of problems.
I would like to point out that every single service that does error/logging/analytics for you, is crap. There, I said, they're crap. They'll for example give you beautiful graphs of how many 404s you have per hour, but they won't show you why it 404d, or how to address it and fix it. They'll give you lots of numbers that are great for meetings with people who also don't understand what is involved in fixing code, but who probably decide what your budget will be for the next six months. They'll show you pretty charts, but can't show you the exact line in the code that threw the error, so you have no idea how to fix it. Don't bother using them.
The best logs you can have are your own. As you write the code, learn to account for errors and exceptions and capture as many of them as you can in your actual code, send correct api responses, and display proper useful messages to users. And always have an "ELSE" that SHOULD never happen and make sure even that logs to a text file somewhere or into whatever tool/service you use to view logs.
For JS stacks everyone hypes up linters, but...really no one gives a damn if you have an empty space at the end of a line or lines longer than 80 characters or if you use spaces over tabs [Tabs ftw]. In JS 99% of your errors will be "undefined" or unfinished promises. Use async/await and check for undefined/NaN/null always and you'll have nearly zero errors your linters actually help solve.
UI/UX errors are just as important as DNS errors, 301s, 404s, 500s, api endpoints failing, bad database queries, and finally, syntax errors.
When something goes to production there should be ZERO syntax errors. If there are any, it means you as the dev failed to even load the page and perform the interactions available on that page or you'd have spotted the syntax errors [regardless of language]
Make sure you have access to view actual log entries. Eg. Server access logs, and error logs for whatever language or framework or tool you're using.
On Apache/Nginx servers those logs are easy to find and easy to review to find the exact point of error in the code so you can fix it.
On automated deployments it can get harder because more things are obfuscated and you should plan ahead and make sure you know where to find the information you need.
Mainly, work with someone who knows their stuff. That will save you more time than any of the above. Just work with someone who actually knows how to debug things and learn from them. This is how you get better at it.
For every stack there's a different way to approach this. For ever language there are different places to look for errors. Each one is fairly simple and no one knows all of them, however any time you're stuck just google it and you should be able to find where errors are logged for that language or stack no problem.
I know I hit on a lot of subjects here, but there's a lot more I didn't even get to, it all just comes down to what languages and stacks you are using, which should then dictate your deployment processes tied to them and thus how you store error logs and review them.
So many subjects in your answer, I love it!
In the past I always stick to the error logs I could see on servers and tried to think of possible errors upfront and handle them on the code.
Then a lot of react side projects came in and I learned about the Error Boundary.
I have a couple of apps running smoothly. But one in particular had reports of strange behaviors and almost every case could be tracked back to data issues.
But it was hard to get proper feedback from users and I was searching for something to catch unhandled errors, be able to push my handled ones too and get not only a stack trace but also some context which user it was, what his actions roughly were before and so on.
I totally agree with you that it would be best to implement my own logging. But because this is just a side project I wanted to have something with less effort. I am even okay with sacrificing the luxury of custom handling if an existing library or service would enable me to implement it rudimentary.
I am testing bugdnag at the moment.