Logging Policy
There are different points of view on how logging levels should be used in code. I will share mine.
My assumption is: “There should be no errors in logs when everything is fine.”
There are different points of view on how logging levels should be used in code. I will share mine.
My assumption is: “There should be no errors in logs when everything is fine.”
One of the challenges for start-ups or any new project is to reduce the amount of work while still delivering a full-featured product. Agile methodologies address this challenge on the project management level. Let’s discuss another approach to address it on the architecture level: UI-first development.
StackOverflow-driven JS development:
try {
something
} catch (e) {
window.open('https://stackoverflow.com/search?q=[js]+"' + e.message + '"');
}
Making your web application flawless against security attacks is a challenge for every java developer. In this article I will briefly describe common practical development techniques that can help you to achieve it.
Deploying application into secure environment adds some restrictions on logging and log management. OWASP community gives some useful recommendations.
One of the first requirement of Netty ISO8588 client connector is the support for automatic reconnect.
One of the first receipts I came across was Thomas Termin’s one. He suggests adding a ChannelHandler which will schedule the calling of client’s connect() method once a Channel becomes inactive. Plus adding ChannelFutureListener which will re-create a bootstrap and re-connect if initial connection was failed.
Although this is a working solution, I had a feeling that something is not optimal. Namely, the new Bootstrap is being created on every connection attempt.
So, I created a FutureListener which should be registered once a Channel is closed.