One thing that a lot of people hate to do is writing documentation. Usually, it’s postponed until development is finished and once it’s done there is rarely time to do it properly. If you get past the struggle of writing it down there is always a problem of keeping it up to date. To avoid those pain points I’m going to explore what we can do with Asciidoctor to simplify this problem.
How to introduce automated checks that will guarantee that conventions are followed in an example of test naming convention. I’m going to focus on creating automated process that will verify if test names do match conventions. Automation will allow us to forget about the rule because the computer will ensure it’s followed. Test that I’m going to introduce will be living documentation inside the project and ensure no one will miss nor forget about the way we group tests.
Imagine the situation when you’ve just released something on production and deployment went fine. You’ve just sent release notes and went out to grab a coffee. Once you are back you see an email with information that feature team have been working on for past 3 sprints doesn’t work at all. Turns out you forgot to change something in production server configuration. In this post, I’m going to present the simplest idea which will help you to avoid this kind of issues.
When I’ve got some free time I try to add new features to springmock. Lately, after adding some new stuff I realized that double definition parsing class has more than one responsibility (class parsing, naming, definition creation, etc). So I’ve decided it’s time to refactor it and split responsibilities into dedicated classes. Once I did that and tests in the shared kernel started to pass I executed mvn verify just to be sure that everything was working and it wasn’t…
Code review is a great process which gradually improves code quality. It is a system you can implement in many ways. In this post I’m going to grumble about one particular way of performing code reviews - when there is only one person responsible for doing code reviews and suggesting/accepting/rejecting changes.
We all love to write new stuff and learn about things. But when we’ve got to do something in one of the older applications we’d rather avoid it and lag as long as possible hoping that someone else will handle it. You shouldn’t be afraid of legacy code (as long it is not ball of mud). You should take the opportunity to look into the past, and learn from it as much as possible.
best practices java javascript
Every codebase depends on multiple external libraries. It is a good idea to stay up to date with external dependencies. It is important to update all security related stuff and it might be helpful or fun to use latest features. I’m going to share my way of staying up to date with external dependencies in maven, gradle and npm.
