Posts

Over the past year and a half, I’ve been gradually improving a legacy system at my company. Queries containing business logic, tables composed of dozens of columns that look like random alphabets, complex code that requires careful examination to understand where to start making changes… I often had to confirm with team members if my understanding was correct, and I was never confident about modifying the code. One of the reasons why it’s difficult to easily touch the points we want to fix is the ‘dependency’ problem. If you want to modify B, but A, C, D… are using B in multiple places, modifying B becomes a challenging task. I want to briefly document the tools that helped analyze this dependency problem in the process of improving the architecture and the tools we used to make it into rules shared by the team. (We’ve made some improvements, but it’s still ongoing) ...

Recently, I nearly misinterpreted code authored by a team member contrary to its intended purpose. The implementation initially appeared counterintuitive, prompting thorough reinvestigation documented herein. The team member’s code utilized generics for creating a method applicable to API invocations in a versatile manner. The explanation referenced employing an identical technique to Mockito library’s mock() method, warranting examination. Type Inference in Mockito’s mock() (Version: mockito-core 4.9 or higher, included in spring-boot-starter-test from 3.1 onwards) ...

intro Although I use Spring regularly, I sometimes get confused with configurations in less familiar situations. Recently, while reviewing bean configurations in a project, I encountered a case where both a List type and the type of objects inside the List (for convenience, I’ll refer to them as List<T> type and T type) were configured, as shown in the code below. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 @Bean List<Cake> availableCakes() { return List.of( lemonCake(), chocolateCake(), strawberryCake() ); } @Bean Cake chocolateCake() { return new Cake("Chocolate"); } @Bean Cake strawberryCake() { return new Cake("Strawberry"); } @Bean Cake lemonCake() { return new Cake("Lemon"); } Code that receives and uses List<Cake>: ...

intro Following the previous article specification pattern (1) concept and implementation, I want to explore through specific examples in which situations this pattern is useful. I’ll also introduce various implementation methods when applying the pattern to code. Use Cases for Specification 1. Validation When validating an object to determine if it meets certain requirements or can be used for a specific purpose. Examples: Invoice sending application: When an invoice is overdue → mark it in red Reservation application: When a product exceeds the limited quantity or the current time is before 2 PM → disable the reservation button 2. Selection When selecting objects from a collection that satisfy specific conditions. ...

Express domain rules simply and explicitly

What is JSON Schema? JSON Schema is a declarative language that allows you to annotate and validate JSON documents. (annotate: to add notes / validate: to verify) ⇒ As the name suggests, it’s a schema for JSON, used to describe and validate items. The sender of data can describe the data and define types, and the receiver can validate the data through the schema before using it. Simply put, it can be described as a specification created to reduce various difficulties when exchanging data in JSON. For example, you receive data in JSON from an API or message queue: { id: "34", … }. How should we interpret this? Is it always a string? Could it have been sent incorrectly? If I set up parsing to receive it as a String, but one day it comes as an Integer, how should I handle it? To solve these problems, you can clearly specify the data structure through a schema and ensure data quality. Because there’s a standard specification on ‘how to define the schema’, you can automate the reading and sending according to the standard. Let’s see what it looks like. ...

Recording thoughts about recruiting that might help future me

Recently, I made the decision to depart from the organization where I had been employed for slightly over one year. This was the first company I joined after specifically evaluating the problem domain they were addressing. I resonated deeply with the challenges the organization sought to resolve—more profoundly than at any previous employer—and I consider the work undertaken to have been valuable. The team members were exceptional. This assessment remains unchanged even at this moment of departure. Nevertheless, various factors led me to conclude that the organization and I must pursue divergent paths. ...

Introduction to Proxyman, feature utilization methodologies, and implementation procedures

Recently, I had the opportunity to utilize JPA’s @ElementCollection feature in production code after an extended period. Due to substantial knowledge decay and absence of documented reference materials, the initial implementation required extensive research and deliberation, during which various errors were encountered. This article presents a concise compilation of key considerations. Understanding @ElementCollection JPA’s @ElementCollection annotation is employed for mapping value type collections. It is utilized when referencing collections defined not as @Entity but as basic types or Embeddable classes. At the database level, this creates a separate table. Consider a simplified example where a User’s “Application” entity exists, and multiple “desired dates” can be selected: ...