The regex that broke a server


I’ve never thought I would see an unresponsive server due to a bad regex matcher but that’s just happened to one of our services, yielding it unresponsive.

Let’s assume we parse some external dealer car info. We are trying to find all those cars with “no air conditioning” among various available input patterns (but without matching patterns such as “mono air conditioning”).

Continue reading “The regex that broke a server”

A beginner’s guide to Git feature branches

Why Git

The proprietary software shaped the Version Control Systems (VCS) to fit its requirements:

  1. the project has a strict release schedule
  2. the team is collocated
  3. the sprint goals are well-defined and the focus goes to a limited number of stories
  4. branching is usually reserved for releases or risky development features
  5. the centralized server is hidden from the outside world

This is the context in which centralized Version Control Systems (e.g. Subversion) have emerged, but that’s not a good fit for open-source projects because:

  1. releases are not imposed by deadlines
  2. the contributors may be scattered all over the globe
  3. new ideas are welcomed, even if radical or time-consuming
  4. branching becomes mandatory as developers work on features rather than sprints
  5. the code is available to the whole world

Continue reading “A beginner’s guide to Git feature branches”

JOOQ Facts: SQL functions made easy


The JDBC API has always been cumbersome and error-prone and I’ve never been too fond of using it. The first major improvement was brought by the Spring JDBC framework which simply revitalized the JDBC usage with its JdbcTemplate or the SqlFunction classes, to name a few. But Spring JDBC doesn’t address the shortcoming of using string function or input parameters names and this opened the door for type-safe SQL wrappers such as jOOQ.

JOOQ is the next major step towards a better JDBC API and ever since I started using it I knew there was no turning back. JOOQ became my number one choice for building dynamic queries and recently it became my standard SQL function wrapper.

Continue reading “JOOQ Facts: SQL functions made easy”

Code review best practices

Code review is a great software instrument and you should definitely use it to improve the quality of your code. But like any other tool, it may be misused sometimes. That’s why I came up with a list of best practices to guide you when reviewing your peers’ code.

  1. Code review is not testing: Code review is a developer-to-developer business and it doesn’t involve any testing. Code review should check if the task requirements are met in the cleanest possible way.
  2. You don’t tell what to code review: The same way you don’t tell a tester what to test, you should never tell your peer what to review. The magic of peer review comes from your peer own perspective on the current task design and implementation. Two minds are always better than one.
  3. You should always check all changes: Bugs may be hidden anywhere and you should search for them diligently. To have the whole picture you need to go through all changes.
  4. Requirements first: Requirements are the most important driving force. After all, that’s what the customer is paying for. If the current changes are suboptimal you need to reopen the issue. If you happen to spot other code sections that need to be refactored you should create new issues instead of reopening the current one. The “single responsibility principle” applies to tasks as well as to coding.
  5. One-to-many activity: If you can’t make sure you grasp the code change intention it’s safer to ask somebody else to review it further.
  6. A way of learning: Code review is a great learning technique especially on large projects. Ideally, you should become familiar with every aspect of your project, but if the project is too large you can at least specialize in multiple modules.

Happy code reviewing!

Subscribe to our Newsletter

* indicates required
10 000 readers have found this blog worth following!

If you subscribe to my newsletter, you'll get:
  • A free sample of my Video Course about running Integration tests at warp-speed using Docker and tmpfs
  • 3 chapters from my book, High-Performance Java Persistence, 
  • a 10% discount coupon for my book. 
Get the most out of your persistence layer!

How to detect the Hibernate N+1 query problem during testing


Hibernate simplifies CRUD operations, especially when dealing with entity graphs. But any abstraction has its price and Hibernate is no different. I’ve already talked about the importance of fetching strategy and knowing your Criteria SQL queries, but there is more you can do to rule over JPA. This post is about controlling the SQL statement count that Hibernate calls on your behalf.

Before ORM tools got so popular, all database interactions were done through explicit SQL statements, and optimizations were mostly targeted towards slow queries.

If you think that using Hibernate absolves you from worrying about the underlying SQL statements, then you are wrong. Hibernate is supposed to ease domain model persistence, not to free you from any SQL interaction.

With Hibernate, you manage entity state transitions which are then translated to SQL statements. The number of generated SQL statements is affected by the current fetching strategy, Criteria queries or Collection mappings and you might not always get what you expected. Ignoring SQL statements is risky and it may eventually put a heavy toll on the overall application performance.

I’m a strong advocate of peer review, but that’s not “sine qua non” for detecting bad Hibernate usage. Subtle changes may affect the SQL statement count and pass unnoticed through the reviewing process. Not in the least, when it comes to “guessing” the JPA SQL statements, I feel like I can use any extra help. I’m for as much automation as possible, and that’s why I came up with a mechanism for enforcing the SQL statement count expectations.

Continue reading “How to detect the Hibernate N+1 query problem during testing”