TriLe.dev

Identify Responsibilities and Boundaries: The Key to design a Loose Coupling and High Cohesion system

contact@trile.dev (Tri Le) — Sat, 03 Feb 2024 04:00:00 +0000

Loose coupling and high cohesion are two fundamental principles in software design that are often discussed but it’s difficult. After many failures, I believe I have found the key to solving the above problem: clearly defining the responsibilities and boundaries of each component. In this article, I will explain why this is a crucial step and provide practical guidance on how to achieve it.

1. What’re Coupling and Cohesion?

Cohesion is the degree to which the elements inside a module belong together.

Coupling is the degree of interdependence between software modules.

Although the above two definitions are talking about modules, in my experience it ranges from system architecture, to components to classes. I have mentioned its benefits when applied in system architecture in the article The Importance of Modularity and DDD in System Architecture and DDD is the tool that helps us do it.

2. Identifying Responsibilities and Boundaries

To create a loosely coupled and highly cohesive system, it’s critical to identify the responsibilities and boundaries of each module and component. Here’s how to approach this at different levels:

2.1. Applying Responsibility and Boundaries at the Domain Level

When designing at the System Architecture level, a domain-based structure is often the most effective approach, especially for large systems with multiple business domains. Domain-Driven Design (DDD) is particularly valuable here, as it encourages breaking down a complex system into smaller, independent domains with clearly defined responsibilities. This reduces interdependencies and keeps each domain focused on its unique purpose, which naturally leads to a more cohesive and loosely coupled system.

2.2. Single Responsibility

The Single Responsibility Principle is a guiding force behind well-defined modules. Each component, whether it’s a module, class, or function, should have one and only one responsibility. This clear delineation not only ensures that each module is cohesive but also reduces the chance of introducing unintended side effects when making changes. In practice, this means every module should serve a distinct purpose without overlapping with others.

2.3 Interface Dependency

To maintain loose coupling, we need to be mindful of interface dependency. By designing interactions between components around well-defined interfaces, we prevent tightly coupling our system to specific implementations. This is particularly important when working across domains or when modules need to evolve independently. Through dependency inversion and interface-driven design, components can collaborate without being tightly coupled, enhancing the system’s modularity.

3. Who will identify responsibilities and boundaries?

Responsibility definition isn’t a one-person job; it involves collaboration across roles to ensure alignment at various levels:

Solution Architect: For the system level, the Solution Architect defines boundaries across domains and ensures alignment with business goals.
Tech Lead & Developers: At the domain and component level, Tech Leads and Developers take responsibility for identifying boundaries within each domain. They focus on the practical implementation of modularization and are instrumental in maintaining a cohesive design.
Developers: At the level of modules, packages, and classes, individual developers ensure that each element serves its single responsibility, maintaining both loose coupling and high cohesion in the codebase. This layered approach ensures that boundaries and responsibilities are clearly defined and maintained at every level, making it easier to achieve a modular, flexible, and scalable system.

Note: The image above shows responsibilities at each level, responsibilities according to each level. Solution Architecture for system level, Tech Lead and Developer for the domain level, Developer for components-modules, packages, classes.

4. Conclusion

Everything in software architecture is a trade-off.
— Mark Richards and Neal Ford - Fundamentals of Software Architecture: An Engineering Approach

Identifying responsibilities and boundaries within a system requires significant time, effort, and collaboration, and there’s always a risk of failure. However, the rewards for successfully implementing these principles are substantial. A system with well-defined boundaries and responsibilities is easier to maintain, more resilient to change, and allows for a level of flexibility that’s essential in complex, evolving systems.

In short, while defining responsibilities and boundaries may be challenging, the investment is well worth it. A loosely coupled and highly cohesive system not only supports current needs but also prepares you for future growth and adaptability. By taking the time to structure your system around these principles, you’re setting the stage for long-term success.

Reference links

Thank you for reading this far.

The Importance of Modularity and DDD in System Architecture

contact@trile.dev (Tri Le) — Sun, 21 Jan 2024 04:00:00 +0000

When used Modularity and Domain-Driven Design (DDD) together, they can help to create systems that are easier to maintain, more reliable, and more adaptable to change.

Modularity

Modularity is an architectural characteristic that refers to the system being divided into smaller, independent components. These components can be developed, tested, deployed, and maintained independently, improving the efficiency and scalability of the system.

Modularity is closely related to other architectural characteristics, including:

Testability: Modularity improves the testability of the system by allowing components to be tested individually. This helps to reduce the time and cost of testing, as well as improve the quality of the system.
Configurability: Modularity improves the configurability of the system by allowing components to be configured independently. This helps the system to meet the different requirements of users in a flexible way.
Flexibility: Modularity improves the flexibility of the system by allowing components to be changed or extended easily. This helps the system to adapt to changes in the environment or the needs of users.
Agility: Modularity improves the agility of the system by allowing components to be developed and deployed quickly. This helps the system to meet changing requirements in a timely manner.
Maintainability: Modularity improves the maintainability of the system by making the system easier to understand and repair. This helps to reduce the time and cost of maintenance, as well as improve the reliability of the system.

DDD

DDD is a software design approach that focuses on understanding and modeling business domains. DDD uses concepts such as entities, constraints, and services to create accurate and flexible software models.

DDD can be combined with modularity to create systems with high maintainability. By dividing the system into smaller, independent components, developers can easily understand and repair DDD models.

How to Combine Modularity with DDD

To combine modularity with DDD, developers can use the following principles:

Split entities, constraints, and services into separate components. This helps to make DDD models easier to understand and manage.
Use interfaces to connect components. This helps to make components reusable and flexible.
Use common data structures and algorithms for similar components. This helps to reduce duplication and improve maintainability.

Conclusion

Modularity and DDD are two important techniques that can be combined to create systems with high maintainability. By dividing the system into smaller, independent components, developers can easily understand and repair DDD models.

Reference links

Thank you for reading this far.

Kotlin Coroutines vs LMAX Disruptor: Benchmarking for Asynchronous and Concurrent Programming

contact@trile.dev (Tri Le) — Sat, 06 May 2023 04:00:00 +0000

Asynchronous and concurrent programming are critical for building high-performance and scalable applications. But with so many tools available, it can be challenging to choose the right one for the job. In the JVM ecosystem, Kotlin Coroutines and LMAX Disruptor are two popular options for asynchronous and concurrent programming. But which one is better?

Introduction

Kotlin Coroutines is a lightweight and expressive library for writing asynchronous, non-blocking code in Kotlin. It provides an easy-to-understand way to write concurrent programs. On the other hand, LMAX Disruptor is a high-performance inter-thread communication library for the JVM that provides a fast and efficient way to pass data between threads. It’s worth noting that LMAX Disruptor is used as the underlying communication mechanism in many high-performance systems, including the logging framework Log4j2.

To help developers choose the best tool for their specific use case, I conducted a benchmarking project on thanhtrixx/concurrency-library-benchmark (github.com) that compares the performance of Kotlin Coroutines and LMAX Disruptor. The project uses the Java Microbenchmark Harness (JMH) for accurate and reliable performance measurements. The benchmark measures the time it takes for a large number of events to be processed by each library.

Benchmarking Process

To ensure accurate and reliable performance measurements, the project uses the Java Microbenchmark Harness (JMH). My benchmarking project measures the time it takes for a large number of events to be processed by each library. I compare the performance of Kotlin Coroutines and LMAX Disruptor, and then provide results that can help developers choose the best tool for their specific use case.

Benchmark Results

After running the benchmark, the results will be generated in the result directory. For a fair comparison between the two libraries, these results can be visualized using https://jmh.morethan.io/.

Conclusion

Based on the benchmark results, Kotlin Coroutines is the better choice for applications where high throughput is essential. However, LMAX Disruptor may be more suitable for memory-constrained environments. Ultimately, the choice between the two libraries depends on the specific requirements of the application and the trade-offs the developer is willing to make. This benchmarking project can help developers make informed decisions when choosing a tool for asynchronous and concurrent programming. If you’re interested in contributing to this project or have any questions, please reach me to the project maintainers. I always looking for ways to improve the benchmark and make it more comprehensive. In conclusion, Kotlin Coroutines and LMAX Disruptor are both excellent tools for asynchronous and concurrent programming. Understanding their strengths and weaknesses is crucial in making the right choice for your application.

Reference links

Thank you for reading this far.

Comparing Git Flow, Trunk Based and GitHub Flow

contact@trile.dev (Tri Le) — Tue, 02 May 2023 04:00:00 +0000

Việc quản lý mã nguồn là rất quan trọng để đảm bảo tính ổn định và hiệu quả của dự án. Hiện nay, có nhiều phương pháp quản lý mã nguồn khác nhau như: Github Flow, Git Flow và Trunk Based. Trong bài viết này, chúng ta sẽ đi vào chi tiết về các phương pháp quản lý mã nguồn này và tìm hiểu xem phương pháp nào phù hợp nhất cho feature team size từ 2 đến 7 người trong giai đoạn phát triển tính năng cho ứng dụng.

1. Git Flow

Git Flow là một phương pháp quản lý phiên bản và quản lý mã nguồn được đưa ra bởi Vincent Driessen. Phương pháp này bao gồm hai nhánh chính là “develop” và “master”. Nhánh “develop” được sử dụng để phát triển tính năng mới và sửa lỗi, trong khi nhánh “master” được sử dụng để lưu trữ phiên bản ổn định. Trong Git Flow, mỗi tính năng mới được phát triển trên một nhánh riêng biệt, được tách ra từ nhánh “develop”. Sau khi tính năng được hoàn thành, nó sẽ được merge lại vào nhánh “develop”. Sau đó, nhánh “develop” sẽ được merge vào nhánh “master” để tạo ra một phiên bản mới và được triển khai.

Mặc dù Git Flow là một phương pháp quản lý phiên bản và quản lý mã nguồn phổ biến, nhưng nó có một số hạn chế đối với các dự án có tính chất phát triển nhanh, đòi hỏi sự linh hoạt và tốc độ cao. Với Git Flow, mỗi tính năng đều phải được tạo ra trên một nhánh mới, điều này có thể dẫn đến sự rối loạn và khó khăn trong việc quản lý các nhánh.

2. Trunk Based

Trunk Based là một phương pháp quản lý phiên bản và quản lý mã nguồn đơn giản, được sử dụng bởi các công ty có quy mô lớn và đòi hỏi tốc độ cao như Google và Facebook. Trong phương pháp này, tất cả các tính năng mới đều được phát triển trên một nhánh chính là “trunk”, và được đẩy lên server liên tục.

Trong Trunk Based, các tính năng mới không được tách ra thành các nhánh riêng biệt như Git Flow, mà được phát triển trên một nhánh chính duy nhất. Sau đó, tính năng mới được đẩy lên server ngay khi hoàn thành, và được triển khai ngay lập tức. Phương pháp này giúp giảm thiểu thời gian chờ đợi và giảm bớt sự rối loạn của các nhánh. Tuy nhiên, phương pháp Trunk Based có một số hạn chế đối với các dự án có quy mô lớn và nhiều tính năng phức tạp hoặc các dự án chưa ổn định, khi đó sự đồng bộ hóa và kiểm soát chất lượng của mã nguồn trở nên khó khăn.

3. GitHub Flow

GitHub Flow là một phương pháp quản lý phiên bản và quản lý mã nguồn đơn giản và linh hoạt, được sử dụng bởi GitHub. Phương pháp này bao gồm ba giai đoạn: tạo nhánh, phát triển tính năng, và triển khai. Khi bắt đầu phát triển tính năng mới, người dùng sẽ tạo ra một nhánh mới từ nhánh chính, và đặt tên theo tính năng đó. Sau đó, họ sẽ phát triển tính năng mới trên nhánh đó. Khi hoàn thành, họ sẽ tạo ra một yêu cầu pull request (PR) để đề xuất tính năng mới được merge vào nhánh chính. Trước khi merge, tính năng mới sẽ được kiểm tra và đảm bảo tính ổn định. Sau khi merge thành công, tính năng mới sẽ được triển khai.

Phương pháp GitHub Flow có nhiều ưu điểm, đặc biệt là tính đơn giản và linh hoạt. Với phương pháp này, mỗi tính năng mới được phát triển trên một nhánh riêng biệt, tương tự như Git Flow, nhưng không có sự rắc rối của các nhánh. Ngoài ra, phương pháp này cũng giúp đảm bảo tính ổn định của mã nguồn trước khi merge, giúp giảm thiểu sự cố xảy ra sau khi triển khai. Tuy nhiên, phương pháp này có thể gây ra sự cố khi quá nhiều tính năng mới được phát triển trên nhánh chính cùng một lúc, và không có sự đồng bộ hóa đầy đủ giữa các tính năng đang phát triển.

4. Conclusion

GitHub Flow là phương pháp vừa đơn giản vừa linh hoạt và phù hợp cho các feature team size từ 2 đến 7 người trong giai đoạn phát triển tính năng cho ứng dụng. Điều này là do phương pháp này có tính chất tách biệt giữa các tính năng, và giúp đảm bảo tính ổn định của mã nguồn trước khi triển khai. Ngoài ra, phương pháp này giúp giảm thiểu sự cố xảy ra sau khi triển khai, đồng thời giảm thiểu sự rối loạn của các nhánh.

Điểm khác biệt chính giữa GitHub Flow và Git Flow là cách quản lý các nhánh. Trong GitHub Flow, mỗi tính năng được phát triển trên một nhánh riêng biệt và được merge vào nhánh chính sau khi đã được kiểm tra và đảm bảo tính ổn định. Trong khi đó, trong Git Flow, các tính năng được phát triển trên các nhánh feature riêng biệt, sau đó được merge vào nhánh develop để kiểm tra tính ổn định, và sau đó mới merge vào nhánh release và master để triển khai.

Trong trường hợp của Trunk Based, tất cả các tính năng được phát triển trên cùng một nhánh chính (trunk) và các thay đổi được commit trực tiếp vào nhánh chính. Tuy nhiên, đây không phải là phương pháp tốt nhất cho các dự án đang trong giai đoạn phát triển tính năng.

Lý do là Trunk Based là một phương pháp rất rủi ro, vì nó không cho phép kiểm soát chặt chẽ các thay đổi trước khi triển khai. Nếu một lỗi xuất hiện trên nhánh chính, nó có thể gây ảnh hưởng đến tất cả các tính năng khác đang được phát triển trên nhánh đó. Điều này có thể dẫn đến các vấn đề về tính ổn định và khả năng triển khai của ứng dụng. Ngoài ra, khi có nhiều tính năng đang được phát triển trên cùng một nhánh, sẽ khó khăn hơn để quản lý và theo dõi các thay đổi và sẽ tạo ra nhiều xung đột khi merge các tính năng khác nhau.

Vì vậy, GitHub Flow được coi là phương pháp phù hợp nhất cho các feature team size từ 2 đến 7 người trong giai đoạn phát triển tính năng cho ứng dụng. Với GitHub Flow, các tính năng được phát triển trên các nhánh riêng biệt và được merge vào nhánh chính sau khi đã được kiểm tra và đảm bảo tính ổn định. Điều này giúp đảm bảo rằng các thay đổi không ảnh hưởng đến các tính năng khác và giúp giảm thiểu các xung đột khi merge.

Tóm lại, trong quá trình phát triển tính năng cho ứng dụng, có nhiều phương pháp quản lý mã nguồn khác nhau như Git Flow, Trunk Based và GitHub Flow. Mỗi phương pháp có những ưu điểm và nhược điểm riêng và phù hợp với các kích thước và giai đoạn của dự án khác nhau. Trong trường hợp của các feature team size từ 2 đến 7 người trong giai đoạn phát triển tính năng cho ứng dụng, GitHub Flow được coi là phương pháp phù hợp nhất với tính chất tách biệt giữa các tính năng và giúp đảm bảo tính ổn định của mã nguồn trước khi triển khai.

Reference articles

Cảm ơn các bạn đã đọc tới đây.

Parameterized Test in JUnit 5

contact@trile.dev (Tri Le) — Sat, 15 Aug 2020 04:00:00 +0000

Nếu các bạn đã thực hiện unit test với JUnit4 có một điểm yếu là không hỗ trợ parameters cho test method dẫn tới việc phải dupl code rất nhiều gây khó khăn cho việc review, update test case 👎. Điểm yếu này có thể khắc phục bằng TestNG. Rất may, JUnit5 ra đời với nhiều cải tiến, trong đó Parameterized Test là cải tiến giúp ta khắc phục được điểm yếu trên ❤️.

Required Setup

Để sử dụng Parameterized Tests ta cần dependency là junit-jupiter-params.

Với Gradle ta thêm:

1

testImplementation('org.junit.jupiter:junit-jupiter-params:5.7.1')

Với Maven ta thêm:

1
2
3
4
5
6


<dependency>
 <groupId>org.junit.jupiter</groupId>
 <artifactId>junit-jupiter-params</artifactId>
 <version>5.7.1</version>
 <scope>test</scope>
</dependency>

Argument Sources

Các tham số của Parameterized Tests được cung cấp bởi các Argument Sources sau:

@ValueSource

Là cách đơn giản nhất để cung cấp data test cho Parameterized Tests. Cách này chỉ hỗ trợ các kiểu literal sau:

short
byte
int
long
float
double
char
boolean
java.lang.String
java.lang.Class

Ví dụ sau sẽ test hàm String.isNullOrBlank với 6 trường hợp được liệt kê ở @ValueSource:

1
2
3
4
5
6
7


 @ParameterizedTest(name = "#{index} - String.isNullOrBlank() of [{0}]")
 @EmptySource
 @NullSource
 @ValueSource(strings = ["", " ", " ", " ", "\n", "\t"])
 fun `test isNullOrBlank`(str: String?) {
 assertTrue(str.isNullOrBlank())
 }

Và để test 2 trường hợp đặc biệt null và empty ta có thể sử dụng @NullSource và @EmptySource hoặc dùng @NullAndEmptySource.

@EnumSource

Để test với data test là enum. Mặc định data test là tất cả các giá trị thuộc enum. Trường hợp chỉ muốn test một vài giá trị trong enum ta có thể làm giống ví dụ.

Ví dụ kiểm tra những tháng 4, 6, 9 và 11 có 30 ngày thuộc enum Month:

1
2
3
4
5
6


 @ParameterizedTest(name = "#{index} - [{0}] have 30 day")
 @EnumSource(value = Month::class, names = ["APRIL", "JUNE", "SEPTEMBER", "NOVEMBER"])
 fun `test month have 30 day`(month: Month) {
 val isALeapYear = false
 assertEquals(30, month.length(isALeapYear))
 }

@MethodSource

@ValueSource và @EnumSource chỉ có thể cung cấp các data test đơn giản. Những trường hợp phức tạp ta có thể factory method để cung cấp data test. Một lưu ý là factory method phải là static.

Ví dụ này mình sẽ tối ưu so với bài Use Mock to make Unit Test easy với chỉ một test method:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


 @ParameterizedTest(name = "#{0} - {1} -> {2}")
 @MethodSource("provideToTestData")
 fun `test getFullNameCustomerWithTotalBuyPriceGreaterThan`(
 description: String,
 expected: List<String>,
 mockReturn: List<Customer>
 ) {
 val totalBuyPrice = 3_000

 every {
 customerRepository.findByTotalBuyPriceGreaterThan(3_000)
 } returns mockReturn

 assertEquals(
 expected,
 customerService.getFullNameCustomerWithTotalBuyPriceGreaterThan(3_000)
 )

 verify(exactly = 1) { customerRepository.findByTotalBuyPriceGreaterThan(totalBuyPrice) }

 }

và data test sẽ được cung cấp qua:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28


 companion object {
 @JvmStatic
 fun provideToTestData() =
 Stream.of(
 Arguments.of(
 "Empty list",
 emptyList<String>(),
 emptyList<Customer>()
 ),

 Arguments.of(
 "One customer",
 listOf("Tri Le"),
 listOf(
 Customer(firstName = "Tri", lastName = "Le")
 )
 ),

 Arguments.of(
 "Two customers",
 listOf("Tri Le", "Anna Wesley"),
 listOf(
 Customer(firstName = "Tri", lastName = "Le"),
 Customer(firstName = "Anna", lastName = "Wesley"),
 )
 )
 )
 }

Lưu ý: data trả về của factory method phải là Stream của các Arguments. Tuy nhiên JUnit5 có hỗ trợ các kiểu khác như:

DoubleStream
LongStream
IntStream
Collection
Iterator
Iterable
Một mảng của các objects
Một mảng của các primitives

@CsvSource

Data test sẽ được cung cấp bởi comma-separated values

Ví dụ sau kiểm tra hàm String.toUpperCase:

1
2
3
4
5
6


 @ParameterizedTest(name = "#{index} - String.toUpperCase() of [{0}]")
 @CsvSource("trile,TRILE", "tRilE,TRILE", "trILE,TRILE")
 fun `test trim`(str: String, expected: String) {
 val actual = str.toUpperCase()
 assertEquals(expected, actual)
 }

@CsvFileSource

Tương tự như @CsvSource nhưng data test được load từ file.

Ví dụ sau kiểm tra hàm String.toUpperCase:

1
2
3
4
5
6


 @ParameterizedTest(name = "#{index} - String.toUpperCase() of [{0}]")
 @CsvFileSource(resources = ["/trim.csv"], numLinesToSkip = 1)
 fun `test trim csv file`(str: String, expected: String) {
 val actual = str.toUpperCase()
 assertEquals(expected, actual)
 }

với data test file:

str,expected
trile,TRILE
tRilE,TRILE
trILE,TRILE

@ArgumentsSource

Cũng tương tự như @MethodSource nhưng data test được cung cấp bởi một implements class của ArgumentsProvider thay vì một factory method. Cá nhân mình thấy @ArgumentsSource không tốt bằng

Ví dụ test input argument khác null:

1
2
3
4
5


 @ParameterizedTest
 @ArgumentsSource(MyArgumentsProvider::class)
 fun testWithArgumentsSource(argument: String?) {
 assertNotNull(argument)
 }

data test được cung cấp bởi:

1
2
3
4
5
6
7
8
9


class MyArgumentsProvider : ArgumentsProvider {
 override fun provideArguments(context: ExtensionContext): Stream<out Arguments> {
 return Stream.of("apple", "banana").map { arguments: String? ->
 Arguments.of(
 arguments
 )
 }
 }
}

Customizing Display Names

Một điểm yếu của Parameterized Tests đó là hiển thị kết quả test không được rõ nghĩa lắm. Ví dụ như:

1
2
3
4
5
6


 @ParameterizedTest
 @EnumSource(value = Month::class, names = ["APRIL", "JUNE", "SEPTEMBER", "NOVEMBER"])
 fun `test month have 30 day`(month: Month) {
 val isALeapYear = false
 assertEquals(30, month.length(isALeapYear))
 }

sẽ trả về kết quả sau (với Gradle test report):

Test	Method name	Duration	Result
[1] month=APRIL	test month have 30 day(Month)[1]	0.033s	passed
[2] month=JUNE	test month have 30 day(Month)[2]	0.001s	passed
[3] month=SEPTEMBER	test month have 30 day(Month)[3]	0.001s	passed
[4] month=NOVEMBER	test month have 30 day(Month)[4]	0.001s	passed

nhưng sẽ hơi tối nghĩa nên mình sẽ thay đổi chút như sau:

1
2
3
4
5
6


 @ParameterizedTest(name = "#{index} - [{0}] have 30 day")
 @EnumSource(value = Month::class, names = ["APRIL", "JUNE", "SEPTEMBER", "NOVEMBER"])
 fun `test month have 30 day`(month: Month) {
 val isALeapYear = false
 assertEquals(30, month.length(isALeapYear))
 }

thì kết quả sẽ đẹp hơn:

Test	Method name	Duration	Result
#1 - [APRIL] have 30 day	test month have 30 day(Month)[1]	0.034s	passed
#2 - [JUNE] have 30 day	test month have 30 day(Month)[2]	0.001s	passed
#3 - [SEPTEMBER] have 30 day	test month have 30 day(Month)[3]	0.001s	passed
#4 - [NOVEMBER] have 30 day	test month have 30 day(Month)[4]	0.001s	passed

{index} là số thứ tự của các data test.
{arguments} danh sách tất cả các argument name và argument value.
{0}, {1}, … là argument value theo thứ tự bắt đầu từ 0.

Reference articles

Use Mock to make Unit Test easy

contact@trile.dev (Tri Le) — Fri, 31 Jul 2020 04:00:00 +0000

Ở bài viết How to Write Testable Code có đề cập đế khái niệm Mock. Vậy Mock là gì? Và đặc biệt là các sử dụng nó dể thực hiện Unit Test đơn giản hơn nhé.

What’s Mock

Mock là một fake class cho phép ta pre-programmed ở bước runtime nhằm giả lập phản ứng của fake class đó với một lời gọi cụ thể nào đó. Ngoài ra Mock còn cho phép ta verify xem các method trong fake class đã được gọi bao nhiêu lần.

Chà! Định nghĩ nghe có vẻ khó hiểu quá!

Mình sẽ ví dụ test case sau:

Test một phương thức truy vấn thông tin khách hàng mua nhiều hơn 30 triệu từ Database

Khi đó ta có các vấn đề sau khi thực hiện Unit Test:

Khi Unit Test phải tạo connection tới Database hay sao? Trường hợp cho phép connection xuống Database lỡ có ai đó thay đổi Database thì sao?
Làm sao để biết bên trong hàm thực sự truy vấn thông tin khách hàng mua nhiều hơn 30 triệu hay 29 triệu? Số lần gọi truy vấn xuống Database? Vì nếu ta chuẩn bị data trong Database không tốt có thể kết quả trả về của truy vấn 29tr và 30tr là như nhau, cũng như việc ta truy vấn xuống Database 2 lần trong một lần gọi cũng không thể biết vì kết quả trả về là như nhau.

Và khi này Mock xuất hiện như một người hùng và giúp ta giải quyết các vấn đề trên.

Ngoài ví dụ trên Mock còn có thể giúp ta trong các trường hợp sau:

Đối tượng cung cấp thông tin không xác định. Như: trả về số random, thời gian hiện tại, thời tiết, nhiệt độ…
Đối tượng cung cấp thông tin qua database, web service, rpc, cache…
Đối tượng cần tính toán lâu, tốn resource
Đối tượng chưa tồn tại hoặc có thể bị thay đổi. Như trong ví dụ trong bài Custom Exception mình có thể thực hiện Unit Test trước phần SalaryTransfer mà không phải đợi một bạn khác làm phần TransferMoney bằng cách Mock kết quả 💪.
Các lời gọi liên quan tới context như thread context, security context, scope context…
…

Note: Có một bài viết chi tiết của Martin Fowler ở đây, có so sánh về Stub và Mock và cũng như cung cấp rất nhiều thông tin khác về Test nên nếu có thời gian các bạn nên đọc qua nhé. Ở đây mình chỉ muốn giới thiệu về Mock thôi.

Mock and Dependency Injection

Như ví dụ đầu ở What’s Mock nếu theo cách code truyền thống class xử lý và class truy xuất DB có sự liên hệ chặt chẻ với nhau dẫn đến muốn test ta cần phải setup một DB thật và data trong DB cũng phải thật. May mắn nhờ có IoC và DJ (xem thêm ở Inversion of Control and Dependency Injection), ta có thể injection class truy xuất DB vào class xử lý trong lúc runtime và injection mock class truy xuất DB trong trường hợp test. Phần tiếp theo sẽ làm rõ hơn ý mình muốn nói.

Example Unit Test with Mock

Ví dụ có yêu cầu sau:

Hiển thị full name của những khách hàng mua nhiều hơn N từ Database với N được input vào.

Từ yêu cầu trên mình cần implement CustomerRepository:

1
2
3
4
5


interface CustomerRepository : CrudRepository<Customer, Long> {

 fun findByTotalBuyPriceGreaterThan(totalBuyPrice: Int): List<Customer>

}

Và từ các Customer nhận về mình map() thành full name như sau:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


@Component
class CustomerService(
 private val customerRepository: CustomerRepository
) {

 fun getFullNameCustomerWithTotalBuyPriceGreaterThan(totalBuyPrice: Int) =
 customerRepository
 .findByTotalBuyPriceGreaterThan(totalBuyPrice)
 .map { "${it.firstName} ${it.lastName}" }

}

Và setup mock

1
2
3
4
5
6
7


private val customerRepository: CustomerRepository = mockk()
private val customerService = CustomerService(customerRepository)

@AfterEach
fun tearDown() {
 clearMocks(customerRepository)
}

Và đây là một trong các test case:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


@Test
fun `test getFullNameCustomerWithTotalBuyPriceGreaterThan return one customer`() {
 val totalBuyPrice = 3_000

 every {
 customerRepository.findByTotalBuyPriceGreaterThan(3_000)
 } returns listOf(
 Customer(firstName = "Tri", lastName = "Le")
 )

 assertEquals(
 listOf("Tri Le"),
 customerService.getFullNameCustomerWithTotalBuyPriceGreaterThan(3_000)
 )

 verify(exactly = 1) { customerRepository.findByTotalBuyPriceGreaterThan(totalBuyPrice) }

}

Một test case tiêu chuẩn sẽ bao gồm 3 phần:

Setup: từ dòng 5-9, để setup cho mock biết được cần trả về Customer(firstName = "Tri", lastName = "Le") khi customerRepository.findByTotalBuyPriceGreaterThan(3_000) được gọi
Assert: từ dòng 11-14 so sánh kết quả mong muốn với kết quả thực tế.
Verify: dòng 16 kiểm tra xem thật sự mock đã được gọi hay không, được gọi với các tham số như thế nào cũng như số lần được gọi. Một số bạn hay bỏ qua bước này nhưng thật ra nó rất quan trọng vì sẽ tránh được các tình huống như code gọi khác số lần mong muốn, hãy tưởng tượng như ở ví dụ bài Clean Code with Exception chuyển lương nhiều lần cho nhân viên thì như thế nào 😓 hoặc lời gọi cần được thực hiện nhưng lại không tham gia vào kết quả trả về 👿.

Note 1: Ở đây mình sử dụng Spring JPA nên không cần phải có implement class. Các trường hợp khác các bạn cần implement concrete class và Spring sẽ tự động biết mà inject đúng concrete class khi ứng dụng được khởi chạy. Mình sẽ có có bài chi tiết hơn nha.

Note 2: Phần code sample mình update vào repo này nhé.

Kết: Với sự giúp sức của Mock việc Unit Test trở nên đơn giản và đáng tin cậy hơn rất nhiều.

Cảm ơn các bạn đã đọc tới đây và mong các bạn sẽ thích bài viết này.

Reference articles

How to Write Testable Code

contact@trile.dev (Tri Le) — Tue, 28 Jul 2020 08:30:00 +0000

Ở bài viết Introduction to Unit Test đã nói lên được sự quan trọng của Unit Test. Nhưng trước khi áp dụng được Unit Test vào dự án hiện tại hoặc tương lai thì ta cần phải có một “bước đệm” đó học cách viết Testable Code (là Production Code cho phép thực hiện Unit Test dễ dàng). Việc này theo mình là khó khăn và vì thế bài viết này sẽ tổng hợp một số kinh nghiệm của mình để giúp bạn thực hiện việc này dễ dàng hơn.

Trước khi đọc nội dung bài viết. Mình mong bạn hãy đọc những bài sau để có kiến thức nền cho bài viết này:

Write a simple Unit

Khi ta viết một Unit¹ đơn giản sẽ giúp ích việc Unit Test trở nên đơn giản vì các yếu tố sau:

Số Test Case cho Unit ít hơn.
Các dependency mà Unit phụ thuộc cũng ít hơn từ đó việc chuẩn bị hoặc Mock² cho các Test Case cũng trở nên đơn giản.
Hạn chế việc miss Test Case.

Vậy đối với những yêu cầu phức tạp ta cần làm gì?

Câu trả lời là tách yêu cầu trên thành các yêu cầu nhỏ hơn và giải quyết từng yêu cầu. Giống việc áp dụng chiến thuật “chia để trị” vậy đó ;))

Separation Between Logic and Presentation

Việc tách biệt giữa code xử lý logic và code lưu trữ, hiển thị hoặc call API là việc bắt buộc khi muốn dự án của ta có thể dễ dàng bảo trì và mở rộng về sau. Ý tưởng tách biệt này là ý tưởng chính trong các mô hình MVC, MVVM… Vì thế mà ngay cả khi chiến lược đảm bảo chất lượng của dự án không yêu cầu Unit Test thì ta cũng nên thực hiện việc này.

Ngoài ra việc tách biệt này cũng sẽ giúp cho việc đảm bảo Consistency Unit ở phần sau được thực hiện.

Consistency Unit

Tính Consistency ở đây được biểu hiện qua việc với cùng một input thì Unit luôn trả về duy nhất một output. Việc này giúp việc kiểm tra input và output như mình đề cập ở Introduction to Unit Test có thể được thực hiện.

Một số trường hợp không thể thực hiện tính Consistency như:

Hàm liên quan tới random.
Các hàm liên quan tới thời gian hiện tại như tính tuổi hiện tại từ ngày sinh, số ngày chênh lệch ở một thời điểm nào đó so với hiện tại…
Các lời gọi tới external system như DB, API, Cache…
Các lời gọi liên quan tới context như thread context, security context, scope context…
…

Và mình đề xuất 2 cách giải quyết các trường hợp trên như sau:

Tách code logic và code inconsistency kia thành 2 phần riêng biệt. Lúc này input của code logic sẽ là output của code inconsistency. Và ta chỉ Unit Test phần code logic.
Tương tự #1 khi tách ra 2 phần riêng biệt. Áp dụng IoC/DI, lúc này code logic là Client, code inconsistency là Service Implement. Và cũng chỉ cần Unit Test phần code logic với việc Mock² phần code inconsistency.

Apply Ioc/DI

Việc áp dụng IoC/DI giúp ta có thể dễ dàng Mock² các phụ thuộc cho các class cần Unit Test một cách dễ dàng. Ngoài ra việc áp dụng IoC/DI cũng sẽ giúp thỏa được nguyên lý DIP ở phần dưới.

Apply S.O.L.I.D principles

Việc áp dụng S.O.L.I.D đặc biệt có lợi cho việc viết Unit Test vì:

Single responsibility priciple: giữ cho các class chứa các Unit cần test đơn giản nhất có thể. Từ đó số lượng Test Case cho class được giảm xuống.
Open/Closed principle: Giúp ta không phải viết lại các Test Case cho phần code cũ khi cần mở rộng tính năng.
Liskov substitution principe: Đây là nguyên lý khó giải thích được sự liên hệ của nó với Testable Code :(. Ở đây mình giả sử class A phụ thuộc class B, ta đã Unit Test class A và class B rồi. Vậy khi mình viết thêm một class C kế thừa class B và thay thế class B bằng class C lúc này ta chỉ cần Unit Test thêm class C mà không cần phải Unit Test lại class A nếu thỏa LSP. Nếu chương trình thỏa nguyên lý này. Ta sẽ không cần lại Unit Test những class đã được
Interface segregation principle: nguyên lý này đi kèm với SRP sẽ giúp đơn giản hóa việc Unit Test cho các class implement các interface thỏa nguyên lý này.
Dependency inversion principle: Đây là nguyên lý quan trọng để có thể viết Testable Code được. Nếu bạn đã áp dụng IoC/DI như phần trên thì nguyên lý này cũng tự động thỏa.

Kết: Để viết được Testable Code không phải dễ nhưng khi đã làm được thì xem như bạn có thể bước một chân vào thế giới của các developer “xịn” rồi đó. Ngoài ra viết Testable Code nên thực hiện càng sớm càng tốt vì sẽ tốn rất nhiều thời gian, công sức và rủi ro để chuyển code thường sang Testable Code.

Cảm ơn các bạn đã đọc tới đây và mong các bạn sẽ thích bài viết này.

Reference articles

Unit ở đây đối với lập trình hướng đối tượng là method, đối với lập trình hàm là function, đối với lập trình thủ tục là procedure. ↩︎
Mock hiểu đơn giản là cách để giả lập hành vi của các class, method bên ngoài Unit đang được Unit Test. Còn chi tiết thì ở Use Mock to make Unit Test easy ↩︎ ↩︎ ↩︎

What are S.O.L.I.D principles?

contact@trile.dev (Tri Le) — Sat, 25 Jul 2020 02:30:00 +0000

Trên con đường trở thành một developer “xịn” thì việc biết và áp dụng thành thạo S.O.L.I.D là một trong những điều kiện tiên quyết. Nó giúp ta định hình lại tư duy code rất nhiều như việc tổ chắc code, phân chia vai trò và tương tác giữa các module, class, method… Từ đó giúp code dễ đọc, dễ hiểu, dễ maintaince hơn. Nó giúp ta viết các Testable Code để thực hiện Unit Code. Nó là nguyên lý được áp dụng vào IoC/DI. Và còn nhiều ứng dụng khác. Nhưng quan trọng nó sẽ giúp bạn được tăng lương hoặc phỏng vấn tốt hơn đó 😸.

Introduction to S.O.L.I.D principles

S.O.L.I.D là tập hợp 5 nguyên lý định hướng thiết kế và code trong lập trình hướng đối tượng (OOP). Được đưa ra bởi Bob Martin (cha đẻ của “thánh kinh” Clean Code¹) và Michael Feathers. 5 nguyên lý trong S.O.L.I.D bao gồm:

→ S.O.L.I.D là cách chơi chữ từ 5 chữ cái đầu cửa các nguyên lý, cũng khá thú vị phải không ;)).

Single responsibility priciple

A class should only have a single responsibility, that is, only changes to one part of the software’s specification should be able to affect the specification of the class.
— Wikipedia

Nguyên tắt này tuyên bố một class chỉ nên có một trách nhiệm và việc thay đổi nó cũng chỉ vì đúng trách nhiệm đó thôi. Nguyên lý này sẽ rất hữu dụng đối với những dự án lớn nơi mà chỉ cần một thay đổi nhỏ có thể ảnh hưởng tới toàn bộ chương trình.

Open/Closed principle

Software entities … should be open for extension, but closed for modification.
— Wikipedia

Nguyên lý này khuyên chúng ta viết thêm một class mới kế thừa từ class cũ để mở rộng tính năng thay vì sửa class cũ. Nguyên lý này rất hữu ích với những dự án cũ khi mà việc thay đổi có thể ảnh hưởng tới những chức năng hiện tại.

Liskov substitution principe

Objects in a program should be replaceable with instances of their subtypes without altering the correctness of that program.
— Wikipedia

Các object của class con có thể thay thế cho class cha mà không làm thay đổi tính đúng đắng của chương trình. Nguyên lý này giúp đảm bảo tính đúng đắn và ổn định cho chương trình. Đây là nguyên lý rất dễ bị vi phạm nếu developer không chú ý và có thể dẫn đến những hậu quả to lớn.

Interface segregation principle

Many client-specific interfaces are better than one general-purpose interface.
— Wikipedia

Nguyên lý này khá đơn giản khi yêu cầu ta nên chia nhỏ các interface ra sẽ tốt hơn một interface có nhiều mục đích. Lý do của việc này nhằm tránh dư thừa những method cần phải implement khi kế thừa interface nhiều mục đích ở trên.

Dependency inversion principle

One should “depend upon abstractions, [not] concretions”.
— Wikipedia

một định nghĩa dễ hiểu hơn ;))

Entities must depend on abstractions not on concretions. It states that the high level module must not depend on the low level module, but they should depend on abstractions.

Chắc đọc tới đây vẫn chưa hiểu đâu. Đây là nguyên lý khó hiểu nhất vì cũng trừu tượng nhất mà;)).

Mình lấy ví dụ việc lái xe đạp và lái máy bay (ý mình là nghĩa đen nhé 😽). Về cơ bản hai hành động này rất khác nhau. Nhưng nếu ta trừu tượng hóa thành các hành động đơn giản hơn như: bẻ lái, tăng/giảm tốc, thắng thì lúc này 2 hành động trên là tương tự nhau và cụ thể hóa của bẻ lái, tăng/giảm tốc, thắng là khác nhau.

Hãy xem thêm bài Inversion of Control and Dependency Injection để thấy được IOC/DI cũng là một phần của việc áp dụng nguyên lý này nha các bạn.

Kết: S.O.L.I.D là khái niệm khó, việc hiểu nó cũng là một vấn đề với người mới nhưng S.O.L.I.D chỉ thật sự có ý nghĩa nếu được áp dụng vào dự án. Và tin mình đi một khi đã áp dụng được S.O.L.I.D vào dự án thì công việc code và maintaince và test sẽ trở nên dễ dàng. Bài viết này chỉ dừng lại ở mức khái niệm. Việc áp nó như thể nào sẽ có một loạt bài nói riêng nhé.

Cảm ơn các bạn đã đọc tới đây và mong các bạn sẽ thích bài viết này.

Reference articles

Clean Code: A Handbook of Agile Software Craftsmanship là tên của một quyển sách được viết bởi Robert Martin, được xem là sách “gối đầu giường” của mọi developer. Giới thiệu những cách giúp code dễ đọc, dễ hiểu, dễ maintaince hơn. ↩︎

Introduction to Unit Test

contact@trile.dev (Tri Le) — Sat, 18 Jul 2020 02:30:00 +0000

Vào năm 2015 có một sự kiện làm thay đổi suy nghĩ của mình về Testing trong quy trình phát triển phần mềm. Đây là lần đầu tiên mình phải viết report 5 whys 9 steps. Nguyên nhân chính của vấn đề này là mình xem nhẹ Unit Test và hậu quả thì khá nặng nề. Vì sao thì các bạn xem tiếp bài viết nhé ;)).

Trước đó, lúc học đại học thì mình đã biết khái niệm Black Box Test và White Box Test. Khái niệm Unit Test lần đầu mình được biết vào năm 2013 khi mình còn ở Global CyberSoft. Lúc này leader cũng chỉ xem nó mang tính “report”, các “chốt chặn” chất lượng cho dự án hầu hết ở bước Code Review và Test. May mắn thay leader và QC team mình chuyên môn rất tốt nên chất lượng dự án vẫn ở mức tốt.

Vào năm 2015 mình chuyển qua làm việc tại Mulodo. Mình và một em sinh năm 91 tiếp nhận 2 dự án của 2 bạn chuẩn bị rời công ty. Thời gian gấp rút nhưng tài liệu thiếu, tinh thần muốn rời đi làm cho quá trình transfer dự án không được tốt. Kết quả bọn mình đã phải nhận một “bug siêu khủng long” ngay lần change request thứ 2. Nguyên nhân là do sửa lại một hàm utility và vì hàm này được sử dụng ở rất nhiều function nên lỗi này rất nghiêm trọng. Lúc này mình vẫn nghĩ nguyên nhân lỗi là do “miss knowlead” hoàn toàn có thể phát hiện ở bước Code Review. Nhưng sau khi trúng “thông não chi thuật” của Manager thì mình nhận ra lỗi này hoàn toàn có thể tránh được nếu áp dụng Unit Test đúng.

Vậy Unit Test là gì và vì sao nó lại cần thiết?

What is Unit Test?

Unit Test là một bước trong quy trình phát triển phần mềm. Nó được nên được bắt đầu ngay sau Functional Design, trước Implement và kết thúc sau khi Implement xong. Nhằm mục đích đảm bảo phần code được implement đúng với thiết kế. Unit Test được thực hiện bởi lập trình viên và được xem là White Box Test.

Unit ở đây đối với lập trình hướng đối tượng là method, đối với lập trình hàm là function, đối với lập trình thủ tục là procedure. Khi này lập trình viên sẽ liệt kê ra tất cả các trường hợp logic mà Unit đó sẽ chạy qua, từ đó sẽ tạo ra một bộ các input và output (bao gồm cả kết quả mong muốn và lỗi mong muốn) tương ứng cho các trường hợp đó. Framework Unit Test sẽ hỗ trợ xác nhận lại input và output cho từng trường hợp và báo cáo kết quả cuối cùng.

Why do I have to write Unit Test?

Đảm bảo Unit chạy đúng với thiết kế. Sự đảm bảo này lại càng quan trọng trong trường hợp update lại logic của Unit. Giá như mình biết cái này sớm hơn và “người trước” viết Unit Test nghiêm chỉnh hơn thì đã không dính lỗi ở ở trên :((.
Hiễu rõ hơn về yêu cầu và định hướng Implement trước. Như mình đã nói, Unit Test phải bắt đầu trước Implement, khi này ta sẽ liệt kê ra tất cả các trường hợp sẽ xảy ra và chốt được bộ input và output cho các trường hợp đó, giống như việc muốn đi đâu thì cần biết điểm đến vậy đó ;)).
Phát hiện lỗi sớm → tiết kiệm chi phí và thời gian.
Khi viết Unit Test developer cần phải xem lại code của chính mình. Đây cũng có thể xem là một hình thức “ép buộc” tự review ;)).
Giảm tải cho Code Review. Đối với ai đang là lead hoặc phải peer review thì chắc chắn muốn người implement code thực hiện Unit Test.
Phát hiện những lỗi tiềm ẩn mà Black Box Test không thể phát hiện.
Là một phần không thể thiếu trong việc triển khai CI/CD.

Concepts in Unit Test?

Test Case: là một trường hợp logic mà Unit cần test có thể xảy ra trong quá trình chạy. Với mỗi Test Case ta cần phải xác định được một bộ input và output tương ứng.
Assertion: Là một phát biểu mô tả các công việc kiểm tra output cần tiến hành. Như trong JUnit là các hàm: assertEquals, assertThrows, assertArrayEquals, assertNotNull, assertNull…
Test Suite: là tập hợp các Test Case. Các Test Suite có thể phân loại dựa vào module, package, class hoặc thậm chí là Unit tùy thuộc vào số lượng Test Case, độ phức tạp của Unit hoặc chiến lược của người viết Unit Test.
Production Code: Là phần code chính sẽ được chạy khi deploy lên production.
Test Code: Là phần code để thực thi Unit Test, nó bao gồm tất cả các Test Suite. Phần code này sẽ được chạy trong quá trình build và không include vào Production Code. Ngoài ra lập trình viên cũng nên chạy ở local trước khi Merge (Pull) Request.

Kết: Mong sau bài viết này bạn sẽ thấy được sự quan trọng của Unit Test. Kiến thức về Unit Test thì rất nhiều và mình sẽ tiếp tục viết nhiều nâng cao hơn về chủ đề thú vị này. Kết thúc bài viết mình xin trích một câu nói từ Manager cũ của mình người đã giúp mình “thông não” ;)).

Unit Test không phải là trách nhiệm của lập trình viên mà là quyền lợi. Nó bảo vệ chúng ta khỏi những lỗi tiềm ẩn. Vì thế hãy viết nó “bằng cả trái tim”.
— Tài Nguyễn

Cảm ơn các bạn đã đọc tới đây.

Inversion of Control and Dependency Injection

contact@trile.dev (Tri Le) — Sat, 11 Jul 2020 02:00:00 +0000

Vào năm 2012, khi mình vừa mới gia nhập gia đình Global CyberSoft, bước chân vào thế giới lập trình với nhiều bỡ ngỡ 😅 thì 2 khái niệm Inversion of Control (IoC) và Dependency Injection (DI) là khó nhằn nhất với mình nhưng nó lại là nền tảng cho những ứng dụng sau này. Cùng mình tìm hiểu vì sao nó lại quan trọng như thế nhé.

Nội dung bài viết:

1. Dependency problem in OOP

Trong lập trình hướng đối tượng (OOP) có một vấn đề với các chương trình lớn là sự phụ thuộc của các class với nhau trong chương trình. Việc phụ thuộc này làm chương trình rất khó thay đổi, mở rộng cũng như thực hiện Unit Test là không thể với những class bị phụ thuộc vào các class khác.

Khó hiểu quá!!! Mình sẽ lấy ví dụ ở bài Custom Exception để giải thích cho các bạn dễ hiểu hơn nha.

Dưới đây là class diagram của ví dụ: và giả sử ngoài chức năng Money Transfer thì còn có các chức năng khác như: Money Topup, Money Withdraw, Money Exchange Rates… phụ thuộc vào 2 class VietcomBank và VietinBank. Nếu có yêu cầu thay đổi VietcomBank thành một ngân hàng khác thì ta cần phải sửa code lại tất cả các class Money Transfer Money Topup, Money Withdraw, Money Exchange Rates… Hãy tưởng tượng nếu chương trình ta có hàng chục, hàng trăm class. Các phụ thuộc có thể là hàng trăm thì chỉ với “một yêu cầu nhỏ” cũng dẫn tới việc thay đổi cấu trúc chương trình rất lớn và tiềm ẩn nhiều rủi ro.

Để giải quyết vấn đề trên người ta đã đưa ra một nguyên tắc lập trình là Inversion of Control

2. What is Inversion of Control?

In software engineering, inversion of control (IoC) is a programming principle. IoC inverts the flow of control as compared to traditional control flow. In IoC, custom-written portions of a computer program receive the flow of control from a generic framework. A software architecture with this design inverts control as compared to traditional procedural programming: in traditional programming, the custom code that expresses the purpose of the program calls into reusable libraries to take care of generic tasks, but with inversion of control, it is the framework that calls into the custom, or task-specific, code.
— Wikipedia

Choáng rồi phải không ;))

Đấy là định nghĩa của các anh Tây. Còn với mình thì IoC có thể hiểu như một ý tưởng “đảo ngược” lại cách truyền thống khi mà việc khai báo và khởi tạo các phụ thuộc ở các class được chuyển sang cho framework. Nói cách khác chỉ có một nơi làm nhiệm vụ quản lý các phụ thuộc là framework.

Các ưu điểm của IoC:

Tách việc thực thi nhiệm vụ cụ thể ra khỏi code điều phối. Như ở ví dụ Money Transfer thì class Money Transfer không cần quan tâm 2 class VietcomBank và VietinBank làm gì.
Dễ dàng chuyển đổi các phụ thuộc. Như ta có thể khai báo thay thế VietcomBank sang TechcomBank (mới) một cách dễ dàng.
Module hóa chương trình.
Dễ dàng tạo ra các Testable Class. Mình sẽ giải thích việc này sau ở bài về Unit Test.

Nhưng cũng có kèm những khuyết điểm:

Phụ thuộc vào framework.
Khó hiểu đối với người mới.
Những lỗi khi khai báo phụ thuộc chuyển từ compile time sang runtime.
Chương trình khởi động chậm hơn do cần đọc config, khởi tạo các phụ thuộc.

3. What is Dependency Injection?

Ioc là một ý tưởng hay nguyên tắt thôi. Còn việc hiện thực nó thì có nhiều có nhiều cách. Trong số đó cách nổi trội nhất là Dependency Injection (DI). Vậy DI hiện thực IoC như thế nào?

Để hiện thực được IoC thì bên trong DI sẽ có các thành phần sau:

Client: là các class có phụ thuộc.
Service: là các interface hoặc abstract class bị các Client phụ thuộc.
Service Implement: là các implement class cụ thể của Service.
Injector: là đối tượng chị trách nhiệm khởi tạo các Client và Service Implement, sau đó dựa vào các khai báo phụ thuộc ở Client và mapping giữa Service và Service Implement sẽ inject các Service Implement vào trong các Client.

Và các bước mà DI sẽ thực hiện:

4. Implement Salary Transfer by Dependency Injection

Mình đã convert tất cả code ví dụ Money Transfer từ Java sang Kotlin. Đã hứa có bài hướng dẫn chuyển nhưng tới giờ vẫn chưa làm được 😂.

Về DI framework thì mình chọn Srping nhé. Đơn giản vì nó hiện là framework Java mạnh mẽ nhất. Sau đó update lại file build.gradle.kts giống ở đây. Mình sẽ tập trung vào Spring IoC nên các config khác xin phép bỏ qua.

Vì các class SalaryTransfer, MoneyTransfer và SalaryCalculator là Service Implement của lần lượt các class IocdiApplication, SalaryTransfer nên mình sẽ thêm anotation @Component. Lưu ý mình không khai báo Service vì cảm thấy không cần thiết lắm.

Hai class VietcomBank và VietinBank mình không dùng cách thêm anotation @Component vì lúc này có cùng 2 class cùng implement interface Bank và Spring Injector sẽ không biết chọn class nào để inject vào Client của hai class trên là MoneyTransfer. Vì thế mình khai báo như sau ở class IocdiApplication.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@SpringBootApplication
class IocdiApplication {

 @Bean
 fun primaryBank() = VietcomBank()

 @Bean
 fun secondaryBank() = VietinBank()

}

khi tham chiếu với contructor của MoneyTransfer:

1
2
3
4
5
6
7


@Component
class MoneyTransfer(
 private val primaryBank: Bank,
 private val secondaryBank: Bank
) {
 // bla bla bla bla
}

thì Spring Injector sẽ hiểu được sẽ inject VietcomBank vào primaryBank và VietinBank vào secondaryBank. Quá đơn giản phải không ;))

Ta chạy command sau để build

./gradlew clean build

và test thử:

java -jar build/libs/*.jar 11 1000000 EM1

Transfer 11000000 to EM1
VCB only support transfer amount less than 10M
Retry with VTB
VTB transfer success
Transfer Salary success

Bây giờ ta hãy thử hoán đổi vị trí VietcomBank vào secondaryBank và VietinBank vào primaryBank như sau:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


@SpringBootApplication
class IocdiApplication {

 @Bean
 fun primaryBank() = VietinBank()

 @Bean
 fun secondaryBank() = VietcomBank()

}

Build và chạy lại thì kết quả là:

Transfer 11000000 to EM1
VTB transfer success
Transfer Salary success

Như vậy ta chỉ cần đổi phần config ở class IocdiApplication là logic của chương trình có thể được thay đổi.

Kết: IoC và DI có thể xem khái niệm khó hiểu đối với người mới nhưng mong với bài này bạn sẽ hiểu nó hơn. Có rất nhiều framework mạnh mẽ sử dụng hai khái niệm trên như một phần không thể tách rời. Vì thế đây là đòn bẩy để giúp các bạn học lập trình nhanh hơn. Ngoài ra với các chương trình lớn, bạn sẽ không thể viết được các Testable Class là điều kiện tiên quyết để áp dụng Unit Test mà sau này sẽ cứu mạng bạn rất nhiều lần đó ;)). Tin mình đi! Thời gian bạn bỏ ra để học IoC và DI là cực kỳ xứng đáng đấy 💪.

Phần code sample mình update vào repo này nhé. Cảm ơn các bạn đã đọc tới đây.

Resolve Race Condition problems with Map-Reduce and Coroutines

contact@trile.dev (Tri Le) — Sat, 04 Jul 2020 02:30:00 +0000

Tiếp sau bài Kotlin Coroutines Basic Concepts. Bài này mình sẽ tận dụng những kiến thức trên để giải quyết một vấn đề trong Concurrent đó là Race Condition bằng ý tưởng Map-Reduce. Bài này khá ngắn nhưng lại đề cập được 2 chủ đề rất hay là Race Condition và Map-Reduce nên các bạn hãy đọc tới cuối bài nhé ;))

Nội dung bài viết:

1. What is Race Condition?

Hãy nhìn video sau:

và tưởng tượng các chú chó là thread còn trái banh là resource ;))

Không cần giải thích nhiều thì chắc các bạn cũng thấy cũng thấy resource sẽ có thể không chính xác hoặc toàn vẹn nếu có nhiều thread cùng tranh chấp trong một thời điểm.

2. How to resolve Race Condition?

Nguyên nhân của Race Condition là do tranh chấp resource. Vậy chỉ cần giải quyết được vấn đề này sẽ giải quyết được Race Condition, và ta có 2 “trường phái” là:

1. Sử dụng Synchronizations¹ hoặc Atomic Operations²

2. Tránh chia sẻ trạng thái

Quay lại ví dụ về các chú chó và trái banh thì 2 cách giải quyết sẽ như sau:

Sẽ cũng chỉ có 1 trái banh và các chú cho phải đợi tới lượt mình chơi - các chú chó chắc sẽ không được vui 😂.
Sẽ có nhiều trái banh cho các chú chó và chắc chắn chú chó nào cũng vui 💪.

→ vậy chỉ cần phụ thuộc vào điều kiện anh chủ ;))

Trong thực tế, thì trước đây khi phần cứng chưa phát triển, các hệ thống máy tính chỉ có một core, bộ nhớ RAM đắt đỏ thì #1 là sự lựa chọn tốt hơn nhưng tới thời điểm hiện tại mình tin rằng #2 là giải pháp tối ưu hơn.

Tuy nhiên vẫn có một số trường hợp bắt buộc phải dùng #1 như: số dư tài khoản ngân hàng, chỉ số chứng khoán…

3. What is Map-Reduce?

Đọc tới đây chắc bạn cũng đưa ra nhận định #2 là lựa chọn tối ưu để giải quyết Race Condition trong thời điểm hiện tại. Nhưng làm thế nào để hiện thực #2? Một trong những cách hiện thực là Map-Reduce. Vậy Map-Reduce là gì?

Map-Reduce lần đầu tiên được giới thiệu bởi Jeffery Dean và Sanjay Ghemawat lúc đó đang làm việc ở Google vào năm 2004, và là ý tưởng cơ bản để hiện thực Hadoop. Về cơ bản, đây là cách thực hiện của tinh thần chia để trị. Khi thực thi, sẽ có 2 bước là:

Map: chia dữ liệu cần xử lý thần các phần nhỏ và xử lý các phần nhỏ đó.
Reduce: tổng hợp dữ liệu đã xử lý để cho ra kết quả cuối cùng.

Lý thuyết hơi khó hiểu nên bạn xem hình này nha:

đây ví dụ “Word Count” trong bài Hadoop MapReduce deep diving and tuning . Nhiệm vụ là cần đếm số lần xuất hiện của một từ trong phần Input. Với bước Map được chia thành 2 bước nhỏ: Splitting và Mapping, Reduce được chia thành 2 bước nhỏ: Shuffling và Reducing.

Resolve Race Condition with Map-Reduce

Đây là phần chính của bài viết. Mình sẽ implement ví dụ “kinh điển” của Race Condition là increase một biến counter bằng 3 cách: increase bình thường, increase với Map-Reduce và increase với nhiều thread và AtomicLong.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60


fun main(args: Array<String>) = runBlocking {

 val max = 1000_000_000L // the max value which counter need increase to this

 // increase use one thread
 var counterSync = 0L
 val timeSync = measureNanoTime { counterSync = increaseSync(max) }
 println("increaseSync: counterSync [$counterSync] - time [$timeSync]")

 val workers = 5 // number workers to split into sub many increment

 var counterMapReduce = 0L
 val timeMapReduce = measureNanoTime { counterMapReduce = increaseMapReduce(max, workers) }
 println("increaseSync with Map-Reduce: counterMapReduce [${counterMapReduce}] - time [$timeMapReduce]")

 var atomicCounter = AtomicLong()
 val timeAtomicCounter = measureNanoTime { increaseWithAtomic(max, workers, atomicCounter) }

 println("increaseWithAtomic: atomicCounter [${atomicCounter.get()}] - time [$timeAtomicCounter]")

}

// just use for statement in one thread
fun increaseSync(max: Long): Long {
 var counter = 0L
 for (i in 0 until (max)) {
 counter++
 }
 return counter
}

// create workers group then increase couter in each worker and sum it
suspend fun increaseMapReduce(max: Long, workers: Int): Long = runBlocking {
 val maxByWorker = max / workers // max counter of each worker

 val threadPool = newFixedThreadPoolContext(workers, "workerThreadPool") // workers group

 (1..workers)
 .map { async(threadPool) { increaseSync(maxByWorker) } } // create worker jobs
 .map { it.await() } // wait all jobs of workers done
 .reduce { acc, current -> acc + current } // sum max counter of each worker
}

// create thread group and shared couter, each thread will increase shared couter and wait all threads done
fun increaseWithAtomic(max: Long, workers: Int, atomicCounter: AtomicLong) {
 val maxByWorker = max / workers

 val threads = (1..workers)
 .map {// create thread group
 thread {
 for (i in 0 until maxByWorker) {
 atomicCounter.incrementAndGet() // increase atomic opertation
 }
 }
 }

 for (thread in threads) { // wait all threads done
 thread.join()
 }
}

kết quả sẽ show ra như sau:

increaseSync: counterSync [1000000000] - time [304001418]
increaseSync with Map-Reduce: counterMapReduce [1000000000] - time [171316295]
increaseWithAtomic: atomicCounter [1000000000] - time [19268418252]

Ta có thể thấy thời gian của increaseSync with Map-Reduce là nhanh nhất ta xem là 1x thì increaseSync là 1.8x và thật kinh khủng khi increaseWithAtomic là 112.5x. Số liệu chạy lại có thể khác nhưng từ đây có thể thấy trong trường hợp thời gian thực hiện toán tử là nhanh và thời gian để đảm bảo shared state luôn đúng là chậm thì Sử dụng Synchronizations hoặc Atomic Operations là không hiệu quả.

Kết: Khi giải quyết Race Condition trong thời điểm hiện tại thì cách Tránh chia sẻ trạng thái đang là giải pháp tối ưu trong hầu hết các trường hợp, Map-Reduce là một trong những hiện thực của cách trên nhưng vẫn còn những cách khác giải quyết những vấn đề phức tạp hơn. Mong các bạn đón đọc phần tiếp theo của loại bài viết về Kotlin Coroutines để được nhiều vấn đề trong Concurrent và cách giải quyết nhé.

Phần code sample mình update vào repo này nhé. Cảm ơn các bạn đã đọc tới đây.

Trong một thời điểm chỉ một thread được phép thực thi. ↩︎
Là các thao tác *không thể chia nhỏ ra nữa trong đó ngôn ngôn ngữ lập trình hoặc hệ điều hành sẽ đảm bảo các thao tác này sẽ hoàn thành một cách độc lập với bất kỳ thread hoặc process nào. ↩︎

Kotlin Coroutines Basic Concepts

contact@trile.dev (Tri Le) — Sun, 31 May 2020 10:00:00 +0000

Mở đầu loại bài viết về Kotlin Coroutines mình sẽ giải thích khác khái niệm trong Coroutines và tương ứng với các khái niệm sẽ có thêm ví dụ. Qua đó mong bạn sẽ có kiến thức nền về Coroutines và tìm hiểu nó nhanh hơn.

Các khái niệm sẽ giải thích trong bài này:

1. Dispatchers

Đúng như cái tên. Dispatcher có nhiệm vụ điều phối một hoặc nhiều thread làm nhiệm vụ thực thi coroutine. Có các loại Dispatcher như sau:

Dispatchers.Default: là dispatcher mặc định sẽ được sử dụng nếu không khai báo tường minh trong Scope Builder. Nó sử dụng một common pool được chia sẻ bởi các thread nền. Dispatchers.Default thích hợp với các tính toán cần nhiều tài nguyên CPU
Dispatchers.IO: được thiết kế để sử dụng cho các thao tác IO-intensive blocking operations như đọc/ghi file hay blocking socket I/O
Dispatchers.Unconfined: đây là một dispatcher khá lạ. Trong docs cũng nói nó không thường được sử dụng trong code ;)). Dispatchers này sẽ không chỉ định thread nào sẽ thực thi. Nó có nghĩa là khi khởi chạy nó sẽ được chạy bởi thread đang chạy nó, khi resume lại sau khi suspend thì Coroutines sẽ quyết định thread sẽ thực thi
ThreadPool cụ thể được chỉ định được tạo ra bởi newSingleThreadContext hoặc newFixedThreadPoolContext
Các Executor được convert bởi asCoroutineDispatcher

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29


fun main() = runBlocking {

 launch { // context of the parent, main runBlocking coroutine
 println("main runBlocking : I'm working in thread ${Thread.currentThread().name}")
 }
 launch(Dispatchers.Unconfined) { // not confined -- will work with main thread
 println("Unconfined : I'm working in thread ${Thread.currentThread().name}")
 }
 launch(Dispatchers.Default) { // will get dispatched to DefaultDispatcher
 println("Default : I'm working in thread ${Thread.currentThread().name}")
 }

 launch(newCoroutineContext(Dispatchers.Default)) { // will get its own new thread
 println("newCoroutineContext : I'm working in thread ${Thread.currentThread().name}")
 }

 //
 val dispatcherWithTwoThread = newFixedThreadPoolContext(2, "ThreadPoll")

 repeat(10) {
 launch(dispatcherWithTwoThread) { // will get its own new thread
 println("dispatcherWithTwoThread${it.padEnd(3)} : I'm working in thread ${Thread.currentThread().name}")
 delay(Random.nextLong(500, 5000))
 println("dispatcherWithTwoThread${it.padEnd(3)} : I'm done in thread ${Thread.currentThread().name}")
 }
 }
}

fun Int.padEnd(length: Int, padChar: Char = '0') = this.toString().padStart(length, padChar)

2. Scope

Các coroutine được khởi chạy trong CoroutineScope. Mục đích của việc này để quản lý resource. Hãy tưởng tượng khi ta cần thực hiện một tác vụ nặng nào đó trong một hoặc nhiều coroutine, nhưng giữa chừng tác vụ đó không cần thiết nữa, lúc này ta chỉ cần cancel() scope chứa các coroutine của tác vụ nặng trên. Một đặc điểm khác của CoroutineScope là nó có thể chứa nhiều CoroutineScope con.

GlobalScope

GlobalScope được xem như là scope cha của tất cả các CoroutineScope trong ứng dụng. GlobalScope không thể bị cancel() và sẽ tồn tại xuyên suốt vòng đời ứng dụng. Ngoài ra việc sử dụng được khuyên là KHÔNG NÊN. Bạn có thể xem thêm ở bài The reason to avoid GlobalScope để hiểu nguyên nhân nhé.

Scope Builder

Như đã nói ở trên các coroutine sẽ được khởi chạy trong các Scope Builder sau:

runBlocking: chạy một coroutine và sẽ block¹ đến khi coroutine bên trong chạy xong. Không nên sử dụng function này trong một coroutine vì nó được thiết kế để làm cầu nối code thường với các thư viện được viết theo suspending style, thường được sử dụng cho hàm main và trong test.
coroutineScope: Tạo ra một CoroutineScope mới. Scope được tạo mới này là con của scope bên ngoài nhưng overrides lại Job. Function này được thiết kết để parallel decomposition, nghĩa là khi có bất cứ một coroutine nào fail trong scope này thì các coroutine đang đợi xử lý trong scope này cũng sẽ được cancel.
launch: Tạo ra một CoroutineScope mới, sẽ không block² thread hiện tại và sẽ trả về một Job.
async: Tạo ra một CoroutineScope mới, sẽ không block² thread hiện tại và sẽ trả về một Deferred. Như vậy async được dùng khi cần kết quả trả về khi gọi còn launch thì không.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


fun main() = runBlocking {

 val job = launch(CoroutineName("parent")) { // parent scope
 println("Start $coroutineContext")

 async(CoroutineName("child-1")) {
 println("Start $coroutineContext")
 delay(1000)
 println("End $coroutineContext")
 }

 async(CoroutineName("child-2")) {
 println("Start $coroutineContext")
 delay(3000)
 println("End $coroutineContext") // not execute this line
 }

 println("End $coroutineContext") // still wait child-1 and child-2 finish
 }

 delay(2000)
 job.cancel() // cancel but child-2 not finish

 println("Done")
}

3. Context

Mỗi coroutine trong Kotlin đều có một context được thể hiện bằng một instance của interface CoroutineContext. Context này là một tập các thành phần cấu hình cho coroutine, trong đó 2 thành phần quan trọng là Job và Dispatcher.

Context là một immutable. Nhưng ta có thể dùng toán tử plus để tạo ra một context mới.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


fun main() = runBlocking<Unit> {

 println("Current context is: $coroutineContext")

 println("New context with name: ${coroutineContext + CoroutineName("test")}")

 println("Job in current context is: ${coroutineContext[Job]}")

 println("Dispatcher in current context is: ${coroutineContext[ContinuationInterceptor]}")

 launch(CoroutineName("child")) {
 println("Child context is $coroutineContext}")

 println("CoroutineName in current context is: ${coroutineContext[CoroutineName]}")
 }

}

4. Suspending Function

Suspending Function được xem xương sống của Kotlin Coroutines. Khi đó, các function bên trong Suspending Function sẽ được gọi mà không bị block¹. Như thế thread đang handle cho Suspending Function sẽ được trả lại cho JVM và được dùng cho các tác vụ khác. Suspending Function phải chạy trong một coroutine thì mới có tác dụng nhé ;))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


fun main() = runBlocking(
 CoroutineName("parent") +
 newSingleThreadContext("SingleThread") // Dispatcher SingleThread only use one thread
) {

 launch(CoroutineName("child")) {

 doSomeThingToWait(3000) // release thread in SingleThread for another function
 }

 doSomeThingToWait(1000) // use thread in SingleThread

}

suspend fun doSomeThingToWait(waitTime: Long) {
 println("Current context when START: $coroutineContext")

 delay(waitTime) // simulator processing

 println("Current context when END : $coroutineContext")
}

5. Job

Như đã đề cập ở Context Job là thành phần không thể thiếu trong context. Nó cho phép ta cancel(), join() hoặc start() coroutine tương ứng với job đó. Ngoài ra nhờ có job mà ta biết được trạng thái của một coroutine. Các trạng thái của coroutine có thể được biển diễn ở hình dưới:

 wait children
+-----+ start +--------+ complete +-------------+ finish +-----------+
| New | -----> | Active | ---------> | Completing | -------> | Completed |
+-----+ +--------+ +-------------+ +-----------+
| cancel / fail |
| +----------------+
| |
V V
+------------+ finish +-----------+
| Cancelling | --------------------------------> | Cancelled |
+------------+ +-----------+

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27


fun main() = runBlocking {

 val timeNotCancel = measureTimeMillis {
 val job = launch {
 delay(3_000) // done after 3000 ms
 }

 delay(1_000)
 job.join() // wait job done
 }

 println("Time to run not cancel $timeNotCancel ms")

 val timeWithCancel = measureTimeMillis {
 val job = launch {
 delay(3_000) // done after 3000 ms
 }

 delay(1_000)

 job.cancel() // not wait delay(3_000)
 job.join() // wait job done
 }

 println("Time to run with cancel $timeWithCancel ms")

}

6. Deferred

Deferred cũng là một Job nhưng nó chứa kết quả khi coroutine hoàn thành. Deferred được tạo bằng async mà mình đã đề cập ở ScopeBuilder hoặc khởi tạo trực tiếp bởi CompletableDeferred

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38


fun main() = runBlocking {

 println("--------- async ---------")

 val deferred = async { getRandomInt() }

 println("Wait async-getRandomInt result")

 println("RandomInt from async-getRandomInt = ${deferred.await()}")

 println("------ CompletableDeferred ------")

 val completableDeferred = CompletableDeferred<Int>()

 launch {
 delay(1000)

 val result = Random.nextInt(1, 10)

 println("completableDeferred done with result $result")

 completableDeferred.complete(result)
 }

 println("Wait completableDeferred result")
 println("RandomInt from completableDeferred = ${completableDeferred.await()}")

}

suspend fun getRandomInt(): Int {
 delay(1000)

 val result = Random.nextInt(1, 10)

 println("async-getRandomInt done with result $result")

 return result
}

Phần code sample mình update vào repo này nhé. Cảm ơn các bạn đã đọc tới đây.

Thread hiện tại sẽ đợi đến khi function chạy xong thì mới chạy tiếp đoạn code tiếp theo ↩︎ ↩︎
Chạy tiếp đoạn code tiếp theo mà không phải đợi function này hoàn tất. Kết quả sẽ trả về qua callback hoặc một feature object ↩︎ ↩︎

How to use Kotlin in Java project

contact@trile.dev (Tri Le) — Sun, 24 May 2020 10:00:00 +0000

In the article Introduction to the Kotlin Language, I introduced Kotlin and promised to share my experience in the process of integrating Kotlin. This is one of the articles in that series.

First, we need a Java project, and I chose the project sample from the article Custom Exception and this repo!

Run the following commands (you can copy and run them at once):

1
2
3
4
5


# clone git sample repo
git clone https://gitlab.com/thanhtrixx/trile-dev-sample/
cd trile-dev-sample/
# copy to new project
cp -r custom-exception how-to-use-kotlin-in-java-project

Open the IDE. Here, I’m using IntelliJ IDEA CE and follow these steps:

1. Update Gradle build config

Rename the project (skip this step if you don’t need to rename it). Open the settings.gradle file and update it as follows:

1

rootProject.name = 'how-to-use-kotlin-in-java-project'

Add plugins in file build.gradle file:

1
2


// Apply the Kotlin JVM plugin to add support for Kotlin.
id 'org.jetbrains.kotlin.jvm' version "${kotlin_version}"

Similarly, update dependencies

1
2
3
4


// Reflection is a set of language and library features that allows you to introspect the structure of your program at runtime.
implementation 'org.jetbrains.kotlin:kotlin-reflect'
// Reflection is a set of language and library features that allows you to introspect the structure of your program at runtime.
implementation 'org.jetbrains.kotlin:kotlin-stdlib'

Add config for compileKotlin and build jar file

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


tasks.withType(KotlinCompile).configureEach {
 kotlinOptions {
 freeCompilerArgs = ['-Xjsr305=strict']
 jvmTarget = jdk_version
 }
}

sourceCompatibility = jdk_version

jar {
 // This line of code recursively collects and copies all of a project's files
 // and adds them to the JAR itself. One can extend this task, to skip certain
 // files or particular types at will
 from { configurations.compileClasspath.collect { it.isDirectory() ? it : zipTree(it) } }
 duplicatesStrategy(DuplicatesStrategy.EXCLUDE)
}

Finally, add gradle.properties:

1
2


kotlin_version=1.8.0
jdk_version=17

2. Kotlin call Java

Create a directory to store Kotlin class. The rule is that .kt files of Kotlin must be placed in the src/main/kotlin directory:

mkdir -p src/main/kotlin/dev/trile/java2kotlin

Create KotlinSalaryTransfer class with the provided content:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


class KotlinSalaryTransfer {
 private val moneyTransfer = MoneyTransfer()
 private val salaryCalculator = SalaryCalculator()

 fun salaryTransfer(workingDay: Int, salaryPerDay: Int, accountNo: String?) {
 val salary = salaryCalculator.calcSalary(workingDay, salaryPerDay)
 moneyTransfer.transferMoney(accountNo, salary)
 println("Transfer Salary success")
 }
}

fun main(args: Array<String>) {
 val salaryTransfer = SalaryTransfer()
 try {
 salaryTransfer.salaryTransfer(args[0].toInt(), args[1].toInt(), args[2])
 } catch (e: NumberFormatException) {
 println("Parse int error " + e.message)
 } catch (e: SalaryException) {
 println(e.message)
 }
}

Build và chạy thử

# build
./gradlew clean build
# run
java -cp build/libs/*.jar dev.trile.java2kotlin.KotlinSalaryTransferKt 11 1000000 EM1

Please check the result to see if it matches the Custom Exception article ;))

3. Java call Kotlin

Rewrite the VietcomBank class using Kotlin kotlin:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


class VietcomBank : Bank {

 @Throws(SalaryException::class)
 override fun transferMoney(accountNo: String, amount: Int) {
 checkTransferParams(accountNo, amount)

 if (amount > 10000000)
 throw SalaryException(ErrorType.TRANSFER_MONEY_NOT_ENOUGH_MONEY, "VCB only support transfer amount less than 10M")

 println("VCB Kotlin transfer success")
 }
}

Update MoneyTransfer to use the new VietcomBank class:

1
2


// private final Bank vietcomBank = new VietcomBank();
private final Bank vietcomBank = new dev.trile.java2kotlin.VietcomBank();

Build and test

# build
./gradlew clean build
# run
java -cp build/libs/*.jar dev.trile.java2kotlin.KotlinSalaryTransferKt 5 1000000 EM1

The result will be updated as follows:

Transfer 5000000 to EM1
VCB Kotlin transfer success
Transfer Salary success

Conclusion: With this article, you will learn the first step to integrate Kotlin into Java, but the complete transition to Kotlin is a long journey. I will write a few more articles to make it easier for those who want to join me on this journey ;))

I updated the code sample in this repo. Thank you for reading this far.

Update: I have made updates to the content of build.gradle and gradle.properties to align with the development of Kotlin and Java.

Introduction to the Kotlin Language

contact@trile.dev (Tri Le) — Sun, 17 May 2020 02:30:00 +0000

Nếu:

Bạn là một lập trình viên Java và đã chán ngấy với cú pháp dài dòng của nó
Bạn là một developer và bạn muốn code ít hơn để được về sớm hơn ;))
Bạn là một leader và bạn đang phải viết report cho việc có bug trên live do review code quá nhiều
Bạn theo triết lý less code less bug

thì Kotlin có thể giúp bạn ;))

Đến với nhau vì ưu điểm
Rời xa nhau vì những hiểu lầm
— Trí Xàm ;))

Vì thế sau đây mình là những ưu điểm của Kotlin so với Java và từ đó mong bạn sẽ có động lực để tìm hiểu Kotlin.

1. JVM language

Kotlin cũng giống các ngôn ngữ như Scala, Clojure, Grovvy… đều là ngôn ngữ JVM (full list). Vì thế mà nó sẽ có được các ưu điểm sau:

Được build thành bytecode và chạy trên JRE (Java Runtime Environment): sử dụng lại được cơ sở hạn tầng có sẵn.
Sử dụng chung hệ sinh thái và thư viện của Java: là một trong những ngôn ngữ phổ biến nhất Java có một hệ sinh thái và thư viện đồ sộ của Java. Bạn sẽ không phải tốn quá nhiều thời gian để tìm hoặc viết lại các thư viện khi thay đổi ngôn ngữ.
Tương tác được với code Java trong cùng một module/project: bạn có một module/project đang viết bằng Java. Bạn sẽ không cần phải port lại 100% mà chỉ cần một số config build thì bạn đã có được một module/project mà được code bằng cả Java và Kotlin. Các này rất thích hợp cho những module/project yêu cầu tính an toàn và ổn định. Cá nhân người viết cũng đã tiếp nhận vài project viết bằng Java và đã chuyển sang tích hợp Kotlin được gần 2 năm rồi. Khối lượng code Kotlin chỉ chiếm 35% nhưng khối lượng logic đang xử lý thì ước lượng khoảng 70%

Mình sẽ viết một vài bài chia sẻ kinh nghiệm và chiến lượt convert từ Java sang Kotlin. Mong các bạn đón nhận!!

Update: loạt bài mình nói nè From Java to Kotlin

2. Clean, compact, sugar syntax

Để nói về việc Kotlin giúp code ngắn gọn thế nào có khi phải cần một vài bài nhưng trong chapter này mình chỉ nêu một vài đặc điểm mình cho là hay nhất. Ở đây mình xem các bạn đã rành Java rồi nên sẽ k có code Java tương ứng. Còn nếu bạn chưa rành Java thì chơi Kotlin luôn đê.

Main function

1
2
3


fun main() {
 println("Hello world!")
}

Functions

1
2
3


fun sum(a: Int, b: Int): Int {
 return a + b
}

ngắn gọn hơn

1

fun sum(a: Int, b: Int) = a + b

Variables

Kotlin hỗ trợ 2 keywords là val và var để khai báo biến. Kiểu biến nếu không khai báo tường minh sẽ lấy từ giá trị. val và var khác nhau ở chỗ val không cho phép set lại giá trị, còn var thì cho

1
2
3
4


val a: Int = 1 // immediate assignment
val b = 2 // `Int` type is inferred
val c: Int // Type required when no initializer is provided
c = 3 // deferred assignment

String templates

1
2
3
4
5
6
7


var a = 1
// simple name in template:
val s1 = "a is $a"

a = 2
// arbitrary expression in template:
val s2 = "${s1.replace("is", "was")}, but now is $a"

Statement as expression

Các statement như if/else, try/catch, when có thể là một expression nếu cần

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


val bigger = if (a > b) a else b
val color = when {
 relax -> GREEN
 studyTime -> YELLOW
 else -> BLUE
}
val object = try {
 gson.fromJson(json)
} catch (e: Throwable) {
 null
}

Type checks and automatic casts

1
2
3
4
5
6


fun getStringLength(obj: Any): Int? {
 if (obj !is String) return null

 // `obj` is automatically cast to `String` in this branch
 return obj.length
}

Remove `new` keyword

1
2


val rectangle = Rectangle(5.0, 2.0)
val triangle = Triangle(3.0, 4.0, 5.0)

3. Null safety

Chắc các bạn cũng biết Null là một lỗi thiết kế trị giá tỷ đô và để loại bỏ nó Kotlin cung cấp cho ta các công cụ rất mạnh.

Mặc định Kotlin không cho phép biến chứa giá trị null

1
2


var a: String = "abc" // Regular initialization means non-null by default
a = null // compilation error

Để cho phép biến chứa giá trị null cần khai báo tường minh:

1
2
3


var b: String? = "abc" // can be set null
b = null // ok
print(b)

Không gọi hàm với biến có thể null được

1

val l = b.length // error: variable 'b' can be null

Để gọi được cần thêm ?. khi đó kết quả có thể null.

1

val l = b?.length // l is nullable

Kiểm tra null với b và l = 0 nếu b == null.

1

val l = b?.length ?: 0 // if (b == null) then l = 0 else l = b.length

Safe Casts

1
2


val aInt = a as? Int // aInt: Int?
val aIntDefault = a as? Int ?: 0 // val aInt = if (a !is Int) 0 else a as Int

4. Unchecked exceptions

Ở bài Try/Catch Explain mình cũng đã nói không thích nó. Tất nhiên không phải mình mà còn rất nhiều các bài khác:

Và thật là may mắn khi khi tất cả các Exception trong Kotlin là Unchecked exceptions ;))

5. Data classes

Giả sử ta cần khai báo một class User gồm 2 fields name và age với Kotlin ta chỉ cần:

1

data class User(val name: String, val age: Int)

Khi này Kotlin sẽ tự động tạo ra các method:

Các getter/setter
equals()/hashCode()
toString() có dạng: User(name=John, age=42)
copy(): copy giá trị của biến và thay đổi một hoặc nhiều fields. Sẽ nói rõ hơn ở 7. Named arguments

6. Default values

Kotlin hỗ trợ default values cho constructor và method. Mình lấy ví dụ User ở 5. Data classes sửa lại thành

1

data class User(val name: String = "Tri Le", val age: Int = 30)

khi đó ta có thể:

1
2


val trile = User() // User(name=Tri Le, age=30)
val join = User("Join") // User(name=Join, age=30)

7. Named arguments

Tiếp tục với User ở 6. Default values khi kết hợp với named arguments với default values ta thể:

1
2
3


val join = User(name = "Join") // User(name=Join, age=30)
val trile = User(age = 30) // User(name=Tri Le, age=30)
val mary = User(name = "Mary", age = 16) // User(name=Mary, age=16)

khi này code chúng ta rất rõ nghĩa

8. Functional programing support

Lambdas là một big change đối với Java 8 và Kotlin lại nâng nó lên một tầm cao mới.

Giả sử mình define một class Student như sau:

1
2
3
4
5
6


class Student(
 val name: String,
 val surname: String,
 val passing: Boolean,
 val averageGrade: Double
)

từ danh sách các Student trên mình có yêu cầu sau:

Lấy ra 10 sinh viên đã tốt nghiệp và có điểm trung bình lớn hơn 4.0
Ưu tiên cho những sinh viên điểm cao hơn
Thứ tự được sắp xếp theo tên sinh viên (surname rồi tới name)

Với yêu cầu trên với Java ta cần implement khá nhiều. Nhưng với Kotlin ta chỉ cần 4 line ;))

1
2
3
4


students.filter { it.passing && it.averageGrade > 4.0 } // get only students who are passing and with a grade point average of greater than 4.0
 .sortedBy { it.averageGrade } // sort by the average grade
 .take(10) // take first 10 students
 .sortedWith(compareBy({ it.surname }, { it.name })) // sort students alphanumerically. The comparator compares surnames first, and if equal then it compares names

Đây là ví dụ trong bài blog này. Và nếu có thời gian mình sẽ có một bài viết chi tiết hơn nha ;))

9. Extension functions

Đây là ưu điểm mình yêu thích nhất của Kotlin vì nếu có nhu cầu viết thêm method hoặc properties ta không cần viết sửa code, rất thích hợp cho việc tích các module/lib có sẵn. Hãy nhớ rằng đây chỉ là syntactic sugar và không thật sự thay đổi class hoặc instance.

Mình giả sử muốn viết hàm checkEmpty cho String? thì ca cần:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


fun String?.checkEmpty() = this == null || this.isEmpty()

fun main() {

 val nullString: String? = null
 val emptyString = ""
 val string = "hello"
 nullString.checkEmpty() // false
 emptyString.checkEmpty() // false
 string.checkEmpty() // true

}

Tương tự ta có thể extension luôn cả propertie. Lưu ý ở đây extension propertie cần phải tính từ các thuộc tính khác của class hiện tại

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


val String?.empty
 get() = this == null || this.isEmpty()

fun main() {

 val nullString: String? = null
 val emptyString = ""
 val string = "hello"
 nullString.empty // false
 emptyString.empty // false
 string.empty // true

}

10. Coroutines: lightweight thread

Trước đây khi làm việc về mảng Network Programming mình có làm việc khá nhiều với Java thread và nhận thấy nó có những nhược điểm sau:

Java thread chiếm nhiều resource. Không có số liệu chính xác nhưng mỗi thread sẽ sử dụng 330KB với OS 32 bit và 1MB với OS 64 bit. Vì thế một process chỉ có thể tạo một số lượng giới hạn thread
Cần phải giải quyết vấn đề tranh chấp resource ảnh hưởng tới hiệu năng, độ phức tạp của project/module
Khó code, khó test, khó debug, khó trace
Deadlock

Những vấn đề trên có thể được giải quyết với Coroutines. Và chắc chắc cần phải có một loạt bài viết từ cơ bản tới nâng cao để giúp các bạn nắm vững Coroutines.

Trong khuôn khổ bài viết này mình sẽ ví dụ một case mà Java thread không làm được xem như thị phạm ;))

1
2
3
4
5
6
7
8


fun main() = runBlocking {
 repeat(100_000) { // launch a lot of coroutines
 launch {
 delay(5000L)
 print(".")
 }
 }
}

Đoạn code trên sẽ tạo ra 100K coroutines và sau 5 giây sẽ in ra dấu chấm với mỗi coroutine. Và bạn thử implement đoạn code trên với Java thread xem. Mình đảm bảo sẽ có lỗi out-of-memory

Update: loạt bài về Kotlin Coroutine nè

Kết: Mong với bài viết này sẽ giúp cho các bạn có cảm hứng để tìm hiểu về Kotlin. Từ đó nghiên cứu và áp dụng cho những dự án sắp tới của mình.

Optimize Java Exception and benchmark

contact@trile.dev (Tri Le) — Sat, 25 Apr 2020 16:24:15 +0700

In the post Clean Code with Exception I promised to solve the problem of making Exception slow. So this post will go deeper into what Java will do when an Exception is thrown and explain what a stack trace is… and from there will optimize the use of Exception

1. What will Java do when an Exception is thrown?

To clearly understand what Java does when an Exception is thrown, let’s look at the code of the Throwable class, the parent of Exception ;))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


public class Throwable implements Serializable {

 //bla bla bla
 public Throwable() {
 fillInStackTrace();
 }

 public Throwable(String message) {
 fillInStackTrace();
 detailMessage = message;
 }

 public Throwable(String message, Throwable cause) {
 fillInStackTrace();
 detailMessage = message;
 this.cause = cause;
 }

 public Throwable(Throwable cause) {
 fillInStackTrace();
 detailMessage = (cause==null ? null : cause.toString());
 this.cause = cause;
 }

 // fu fu fu
 public StackTraceElement[] getStackTrace() {
 return getOurStackTrace().clone();
 }

 private synchronized StackTraceElement[] getOurStackTrace() {
 // Initialize stack trace field with information from
 // backtrace if this is the first call to this method
 if (stackTrace == UNASSIGNED_STACK ||
 (stackTrace == null && backtrace != null) /* Out of protocol state */) {
 stackTrace = StackTraceElement.of(this, depth);
 } else if (stackTrace == null) {
 return UNASSIGNED_STACK;
 }
 return stackTrace;
 }

 public synchronized Throwable fillInStackTrace() {
 if (stackTrace != null ||
 backtrace != null /* Out of protocol state */ ) {
 fillInStackTrace(0);
 stackTrace = UNASSIGNED_STACK;
 }
 return this;
 }

 private native Throwable fillInStackTrace(int dummy);

 // fe fe fe
}

The above code shows us that all the public constructors of Throwable call the fillInStackTrace() function. So what does this function do and why do we need to call it? To get the answer, let’s go to the next section

2. What is a stack trace? Why do we need to use it?

Suppose we have the following code and try to run it

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


public class Junk {
 public static void main(String args[]) {
 try {
 a();
 } catch(HighLevelException e) {
 e.printStackTrace();
 }
 }
 static void a() throws HighLevelException {
 try {
 b();
 } catch(MidLevelException e) {
 throw new HighLevelException(e);
 }
 }
 static void b() throws MidLevelException {
 c();
 }
 static void c() throws MidLevelException {
 try {
 d();
 } catch(LowLevelException e) {
 throw new MidLevelException(e);
 }
 }
 static void d() throws LowLevelException {
 e();
 }
 static void e() throws LowLevelException {
 throw new LowLevelException();
 }
}

class HighLevelException extends Exception {
 HighLevelException(Throwable cause) { super(cause); }
}

class MidLevelException extends Exception {
 MidLevelException(Throwable cause) { super(cause); }
}

class LowLevelException extends Exception {
}

The result will be the following error:

HighLevelException: MidLevelException: LowLevelException
at Junk.a(Junk.java:13)
at Junk.main(Junk.java:4)
Caused by: MidLevelException: LowLevelException
at Junk.c(Junk.java:23)
at Junk.b(Junk.java:17)
at Junk.a(Junk.java:11)
... 1 more
Caused by: LowLevelException
at Junk.e(Junk.java:30)
at Junk.d(Junk.java:27)
at Junk.c(Junk.java:21)
... 3 more

Analyzing the above error message, we have the following interpretation:

An exception HighLevelException was thrown. The cause of HighLevelException is MidLevelException and the cause of MidLevelException is LowLevelException
HighLevelException appears in class Junk method a file Junk.java line 13 and method a is called from class Junk method main file Junk.java line 4
MidLevelException appears in class Junk method c file Junk.java line 23, method c is called from class Junk method b file Junk.java line 17 and method b is called from class Junk method a file Junk.java line 11
LowLevelException is similar to MidLevelException and HighLevelException but I also have a headache. Of course, if there is an error and need to trace, I still have to do it ;))

And from the above analysis, we can redraw the flow where the exception is thrown how it looks like:

My image above can also be considered a representation of stack trace. To be more specific, stack trace is an ordered list of function calls and is arranged in the order of calls from the most recent to the first call. It is very useful in analyzing, finding the cause and from there deciding whether to fix the error or not.

Back to the question in #1. Then we have the answer. The fillInStackTrace() function is to collect stack trace and it is very useful, isn’t it 🤟

3. Collect stack trace fast or slow?

The answer is very slow and to see how slow you can clone this repo. If you do variables, see #5.

4. Disable collect stack trace and optimize

I rewrote NSTException and simplified the 2 functions getStackTrace() and fillInStackTrace() as the following code:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


public class NSTException extends Exception {

 private static final StackTraceElement[] EMPTY_STACK_TRACE = new StackTraceElement[0];

 public NSTException(String message) {
 super(message);
 }

 @Override
 public StackTraceElement[] getStackTrace() {
 return EMPTY_STACK_TRACE;
 }

 @Override
 public Throwable fillInStackTrace() {
 return this;
 }
}

Now when NSTException is initialized, it will not collect stack trace anymore. Let’s see the results.

5. Benchmark

I will explain a little bit about how to benchmark. I have 3 methods callNotThrowException, callToThrowException and callToThrowNSTException used to simulate the following situations:

callNotThrowException: normal situation, no Exception is thrown
callToThrowException: situation where Exception is thrown
callToThrowNSTException: situation where NSTException is thrown. NSTException stands for No Stack Trace Exception, a custom exception I rewrote, turning off stack trace collection to increase performance

Due to differences in configuration, OS, Java version… the results may vary. And here are the results from my machine:

Benchmark (param) Mode Cnt Score Error Units
Jmh.callNotThrowException 1 thrpt 25 80504640.048 ± 15390305.644 ops/s
Jmh.callToThrowException 1 thrpt 25 703653.862 ± 58119.745 ops/s
Jmh.callToThrowNSTException 1 thrpt 25 41387559.456 ± 6619635.038 ops/s

We note that the 2 results of Jmh.callNotThrowException and Jmh.callToThrowException are 80504640.048 and 703653.862 (ignoring the ± error) then 80504640.048 / 703653.862 = 114 is a very large number.

Conclusion: By using NSTException to turn off collect stack trace, we have the following advantages:

Speed up the application and use memory more efficiently
Make the method signature easier to understand
External control code is easier to understand when separating business code and error handling, I will also have a post about this part

But there is also a disadvantage that there is no stack trace, from which tracing errors will be difficult. Please watch the next post to solve it.

Optimize Java Exception and benchmark

contact@trile.dev (Tri Le) — Sat, 25 Apr 2020 16:24:15 +0700

Ở bài Clean Code with Exception mình có hứa sẽ giải quyết vấn đề làm Exception chậm. Vì thế bài này sẽ đi vào sâu hơn việc Java sẽ làm gì khi có 1 Exception được throw ra và giải thích stack trace là gì… và từ đó sẽ tối ưu việc sử dụng Exception

1. Java sẽ làm gì khi có 1 Exception được throw ra?

Để hiểu rõ Java làm gì khi có 1 Exception được throw ra thì ta hãy vào xem code của class Throwable cha của Exception hen ;))

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54


public class Throwable implements Serializable {

 //bla bla bla
 public Throwable() {
 fillInStackTrace();
 }

 public Throwable(String message) {
 fillInStackTrace();
 detailMessage = message;
 }

 public Throwable(String message, Throwable cause) {
 fillInStackTrace();
 detailMessage = message;
 this.cause = cause;
 }

 public Throwable(Throwable cause) {
 fillInStackTrace();
 detailMessage = (cause==null ? null : cause.toString());
 this.cause = cause;
 }

 // fu fu fu
 public StackTraceElement[] getStackTrace() {
 return getOurStackTrace().clone();
 }

 private synchronized StackTraceElement[] getOurStackTrace() {
 // Initialize stack trace field with information from
 // backtrace if this is the first call to this method
 if (stackTrace == UNASSIGNED_STACK ||
 (stackTrace == null && backtrace != null) /* Out of protocol state */) {
 stackTrace = StackTraceElement.of(this, depth);
 } else if (stackTrace == null) {
 return UNASSIGNED_STACK;
 }
 return stackTrace;
 }

 public synchronized Throwable fillInStackTrace() {
 if (stackTrace != null ||
 backtrace != null /* Out of protocol state */ ) {
 fillInStackTrace(0);
 stackTrace = UNASSIGNED_STACK;
 }
 return this;
 }

 private native Throwable fillInStackTrace(int dummy);

 // fe fe fe
}

Đoạn code trên cho ta thấy tất cả các public constructor của Throwable đều gọi hàm fillInStackTrace(). Vậy hàm này làm gì và tại sao cần gọi nó? Để có được câu trả lời ta đi vào phần tiếp theo

2. Stack trace là gì? Vì sao cần dùng nó?

Giả sử ta có đoạn code sau và thử chạy nó

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43


public class Junk {
 public static void main(String args[]) {
 try {
 a();
 } catch(HighLevelException e) {
 e.printStackTrace();
 }
 }
 static void a() throws HighLevelException {
 try {
 b();
 } catch(MidLevelException e) {
 throw new HighLevelException(e);
 }
 }
 static void b() throws MidLevelException {
 c();
 }
 static void c() throws MidLevelException {
 try {
 d();
 } catch(LowLevelException e) {
 throw new MidLevelException(e);
 }
 }
 static void d() throws LowLevelException {
 e();
 }
 static void e() throws LowLevelException {
 throw new LowLevelException();
 }
}

class HighLevelException extends Exception {
 HighLevelException(Throwable cause) { super(cause); }
}

class MidLevelException extends Exception {
 MidLevelException(Throwable cause) { super(cause); }
}

class LowLevelException extends Exception {
}

Kết quả sẽ có lỗi sau:

HighLevelException: MidLevelException: LowLevelException
at Junk.a(Junk.java:13)
at Junk.main(Junk.java:4)
Caused by: MidLevelException: LowLevelException
at Junk.c(Junk.java:23)
at Junk.b(Junk.java:17)
at Junk.a(Junk.java:11)
... 1 more
Caused by: LowLevelException
at Junk.e(Junk.java:30)
at Junk.d(Junk.java:27)
at Junk.c(Junk.java:21)
... 3 more

Phân tích message lỗi trên ta có diễn dịch lại sau:

Có exception HighLevelException được throw ra. Nguyên nhân của HighLevelException là MidLevelException và nguyên nhân của MidLevelException là LowLevelException
HighLevelException xuất hiện ở class Junk method a file Junk.java dòng thứ 13 và method a được gọi từ class Junk method main file Junk.java dòng thứ 4
MidLevelException xuất hiện ở class Junk method c file Junk.java dòng thứ 23, method c được gọi từ class Junk method b file Junk.java dòng thứ 17 và method b được gọi từ class Junk method a file Junk.java dòng thứ 11
LowLevelException thì tương tự như với MidLevelException và HighLevelException chứ mình cũng hơi đau đầu rồi đó. Tất nhiên nếu có lỗi và cần trace thì vẫn phải làm ;))

Và từ phân tích trên ta có thể vẻ lại flow mà exception bị throw ra như thế nào:

Hình vẻ trên của mình cũng có thể coi là một biểu diễn của stack trace. Nói rõ hơn stack trace là một danh sách có thứ tự của các lời gọi hàm và được sắp xếp theo thứ tự gọi từ các lời gọi gần đây nhất tới lời gọi đầu tiên. Nó rất hữu ích trong việc phân tích, tìm nguyên nhân và từ đó ra quyết định có cần fix lỗi hay không.

Quay lại câu hỏi ở #1. Thì ta đã có câu trả lời. Hàm fillInStackTrace() là đi collect stack trace và nó rất hữu ích phải không nào 🤟

3. Collect stack trace nhanh hay chậm?

Câu trả lời là rất chậm và để biết chậm như thế nào bạn có thể clone repo này. Còn nếu bạn làm biến thì xem #5 nha.

4. Tắt collect stack trace và optimize

Mình có viết lại NSTException và đơn giản hoá 2 hàm getStackTrace() và fillInStackTrace() như đoạn code sau:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18


public class NSTException extends Exception {

 private static final StackTraceElement[] EMPTY_STACK_TRACE = new StackTraceElement[0];

 public NSTException(String message) {
 super(message);
 }

 @Override
 public StackTraceElement[] getStackTrace() {
 return EMPTY_STACK_TRACE;
 }

 @Override
 public Throwable fillInStackTrace() {
 return this;
 }
}

Lúc này khi NSTException được khởi tạo nó sẽ không collect stack trace nữa. Cùng xem thành quả như thế nào nhé.

5. Benchmark

Mình giải thích chút xíu về cách thức benchmark. Mình có 3 method callNotThrowException, callToThrowException và callToThrowNSTException dùng giả lập các tình huống:

callNotThrowException: tình huống bình thường, không có Exception này được throw ra
callToThrowException: tình huống Exception được throw ra
callToThrowNSTException: tình huống NSTException được throw ra. NSTException viết tắt của No Stack Trace Exception là một custom exception mình viết lại, tắt collection stack trace để tăng hiệu năng

Do khác nhau về cấu hình, OS, Java version… nên kết quả có thể khác nhau. Và đây là kết quả từ máy mình:

Benchmark (param) Mode Cnt Score Error Units
Jmh.callNotThrowException 1 thrpt 25 80504640.048 ± 15390305.644 ops/s
Jmh.callToThrowException 1 thrpt 25 703653.862 ± 58119.745 ops/s
Jmh.callToThrowNSTException 1 thrpt 25 41387559.456 ± 6619635.038 ops/s

Ta chú ý 2 kết quả của Jmh.callNotThrowException và Jmh.callToThrowException lần lượt là 80504640.048 và 703653.862 (bỏ qua sai số ±) thì 80504640.048 / 703653.862 = 114 quả là một con số rất lớn.

Kết luận: bằng việc sử dụng NSTException để tắt collect stack trace giúp ta có những ưu điểm sau:

Tăng tốc ứng dụng và sử dụng bộ nhớ hiệu quả hơn
Làm cho method signature dễ hiểu
Code control bên ngoài dễ hiểu hơn khi tách biệt code bussiness và handle lỗi, mình cũng sẽ có bài về phần này

Nhưng kèm đó cũng có nhược điểm là không còn stack trace, từ đó việc trace lỗi sẽ khó khăn. Mời các bạn đón xem bài tiếp theo để giải quyết.

Try/Catch Explain

contact@trile.dev (Tri Le) — Wed, 22 Apr 2020 00:01:01 +0700

Tiếp tục loạt bài về Exception Clean Code with Exception. Bài này mình sẽ nói nói rõ hơn về try/catch và minh oan cho try/catch khi bị chê là làm cho performance của chương trình chậm lại.

Đầu tiên mình xin giải thích try là gì và catch là gì:

try là một từ khoá của Java để khai báo một đoạn code mà trong đó khi throws ra một Throwable sẽ được xử lý bởi đoạn catch khai báo sau đó.
catch là một từ khoá của Java để khai báo một đoạn code sẽ được thực thi nếu bắt được một Throwable được throws ra bởi các đoạn code nằm trong try khai báo trước đó.

try và catch là một cặp luôn luôn đi cùng nhau.

1. Các tình huống sử dụng

Bắt tất cả các Exception

1
2
3
4
5
6


try {
 // bla bla bla
}
catch (Exception e) {
 // fu fu fu
}

Bắt các IOException trước và Exception sau

1
2
3
4
5
6
7
8
9


try {
 // bla bla bla
}
catch (IOException e) {
 // fu fu fu
}
catch (Exception e) {
 // fe fe fe
}

Lưu ý là các Exception con nên nằm trước, các Exception cha nên nằm sau.

Bắt các IOException và RuntimeException và xử lý trong cùng một statement

1
2
3
4
5
6
7
8
9


try {
 // bla bla bla
}
catch (IOException | RuntimeException e) {
 // fu fu fu
}
catch (Exception e) {
 // fe fe fe
}

2. Checked và UnChecked Exceptions

Khi dùng Java một trong những điểm làm mình không thích được ở nó là Checked Exception khi mà nó bắt buộc mình phải handle Exception. Nếu ta cố ý không try/catch cho đoạn code throws ra Checked Exception thì compiler sẽ báo lỗi và không thể build được dù có thể Checked Exception sẽ không bao giờ xảy ra. Điều này dẫn đến code dư thừa không cần thiết.

Mình lấy ví dụ như trường hợp

1

Cipher.getInstance("AES/CBC/PKCS5Padding");

hoặc

1

dataToEncrypt.getBytes("UTF-8");

sẽ luôn luôn cần phải hand exception do signature của nó khai báo sẽ throws ra các Checked Exception cho dù mình đảm bảo code trên không bao giờ bị Exception. Và khi đó code mình sẽ đại loại thế này

1
2
3
4
5
6
7
8


byte [] bytes;
try {
 bytes = dataToEncrypt.getBytes("UTF-8");
} catch (UnsupportedEncodingException e) {
 // f*ck
}
// bla bla bla
...

hoặc

1
2
3
4
5
6
7


try {
 byte [] bytes = dataToEncrypt.getBytes("UTF-8");
 // bla bla bla
 ...
} catch (UnsupportedEncodingException e) {
 // f*ck
}

Đáng lẽ ra nó chỉ đơn giản như vầy thôi

1
2
3


byte [] bytes = dataToEncrypt.getBytes("UTF-8");
// bla bla bla
...

Nói lang mang quá rồi. Vậy làm thế nào để xác định một Checked Exception? Các bạn nhìn hình sau nhé:

Mấy class màu xanh và con của tụi nó là UnChecked Exception còn mấy cái màu đỏ hay là những class con của Exception nhưng không phải RuntimeException là Checked Exception (giải thích rối não vlc :D)

Có một điểm khá thú vị là .NET và các JVM language như Kotlin, Groovy, Scala đều không có khái niệm Checked Exception hay nói cách khác người dùng cần tự biết mà handle Exception thay vì bị bắt buộc handle. Vậy là anh cả Java đã bị đàn em cho ra rìa rồi ;))

3. Try performance impact

Mình thường được các “đại ka” có kinh nghiệm chỉ giáo là không nên dùng Exception với lý do là sẽ làm hệ thống chạy chậm lại. Mà thay vào đó có 2 cách để giải quyết:

Nên trả về thêm thông tin mã lỗi và mình sẽ gặp tình huống giống như bài này Clean Code with Exception.
Gộp tất cả các thông tin xử lý vào một class info. Class info trên sẽ được truyền qua các method xử lý. Khi có lỗi gì thì method đang xử lý sẽ set thông tin vào class info này và cái phương thức gọi cần phải check lại xem có lỗi hay không. Code smell quá ;((

Haizz! Đọc tới đây chắc có bạn sẽ nói đây là cái giá của việc muốn code chạy nhanh. Nhưng thật sự không phải thế. Bản chất try không làm chậm code mà nó chỉ khai báo rằng những đoạn code nằm trong nó nếu có lỗi sẽ được phần code trong catch dưới nó xử lý. Bạn có thể xem kỹ hơn ở đây nhé.

Nói thế thì do đâu mà khi 1 Exception xảy ra làm chương trình chạy chậm lại?

Câu trả lời là do quá trình collect stacktrace làm chậm chương trình. Và mình hứa sẽ có một bài hướng dẫn các bạn giải quyết vấn đề này!

Update: bài mình hứa ở đây nhé Optimize Java Exception and benchmark :)

Custom Exception

contact@trile.dev (Tri Le) — Sun, 15 Mar 2020 00:33:00 +0000

Ở bài Clean Code with Exception mình có nói về cách dùng Exception để giúp code được đẹp hơn nhưng quả thật thiếu sót khi không có một ví dụ hoàn chỉnh cũng như hướng dẫn sử dụng custom Exception để giúp cho Exception rõ nghĩa và cung cấp nhiều thông tin hơn.

Yêu cầu cũng giống như bài Clean Code with Exception. Mình copy qua đây cho tiện khỏi phải xem lại ;))

Viết chương trình tính và chuyển lương cho nhân viên công ty. Từ yêu cầu này cần làm 3 việc sau:

Tính lương cho nhân viên
Chuyển lương tới nhân viên
Điều phối việc tính và chuyển lương

#1 mình đã làm rồi ở bài Clean Code with Exception nhưng nếu xét tổng quát thì #3 cần biết loại lỗi ở #1 và #2. Giả sử #1 cần yêu cần người dùng nhập lại và dừng chương trình, còn #2 thì có thể retry (công ty chuyển lương qua 2 ngân hàng VCB và VTB, VCB lỗi thì thử VTB) ;))

1. Tính lương cho nhân viên

Từ phân tích trên Exception sẽ không thể đáp ứng yêu cầu. Ta cần custom lại Exception

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public class SalaryException extends Exception {

 private ErrorType codeType;

 public SalaryException(ErrorType errorType, String message) {
 super(message);
 this.codeType = errorType;
 }

 public ErrorType getCodeType() {
 return codeType;
 }
}

Với enum define các loại lỗi:

1
2
3
4
5
6


public enum ErrorType {
 UNKNOWN_ERROR,
 CALC_SALARY_PARAMS_INVALID,
 TRANSFER_MONEY_PARAMS_INVALID,
 TRANSFER_MONEY_NOT_ENOUGH_MONEY,
}

Từ đây ta sửa lại hàm tính lương một chút:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public class SalaryCalculator {

 public int calcSalary(int workingDay, int salaryPerDay) throws SalaryException {

 if (workingDay <= 0)
 throw new SalaryException(CALC_SALARY_PARAMS_INVALID, "WorkingDay less than or equal zero");

 if (salaryPerDay <= 0)
 throw new SalaryException(CALC_SALARY_PARAMS_INVALID, "SalaryPerDay less than or equal zero");

 return workingDay * salaryPerDay;
 }
}

2. Chuyển lương tới nhân viên

Bây giờ ta viết những class hỗ trợ chuyển tiền. Giả sử ta tích hợp với 2 ngân hàng VietcomBank và VietinBank. 2 ngân hàng này sẽ phải implement bởi interface

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


public interface Bank {

 void transferMoney(String accountNo, int amount) throws SalaryException;

 default void checkTransferParams(String accountNo, int amount) throws SalaryException {

 if (accountNo == null || accountNo.length() == 0)
 throw new SalaryException(TRANSFER_MONEY_PARAMS_INVALID, "AccountNo null or empty");

 if (amount <= 0)
 throw new SalaryException(TRANSFER_MONEY_PARAMS_INVALID, "Amount less than or equal zero");
 }
}

Mình có implement thêm hành kiểm tra tham số cho việc chuyển tiền qua hàm checkTransferParams

Implement cho VietcomBank

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


public class VietcomBank implements Bank {

 @Override
 public void transferMoney(String accountNo, int amount) throws SalaryException {
 checkTransferParams(accountNo, amount);

 if (amount > 10_000_000)
 throw new SalaryException(TRANSFER_MONEY_NOT_ENOUGH_MONEY, "VCB only support transfer amount less than 10M");

 System.out.println("VCB transfer success");
 }
}

Để giả lập lỗi ngân hàng. Mình sẽ cho VietcomBank bị lỗi khi số tiền lớn hơn 10M

Tương tự với VietinBank nhưng không lỗi

1
2
3
4
5
6
7
8
9


public class VietinBank implements Bank {

 @Override
 public void transferMoney(String accountNo, int amount) throws SalaryException {
 checkTransferParams(accountNo, amount);

 System.out.println("VTB transfer success");
 }
}

3. Điều phối việc tính và chuyển lương

Và cuối cùng là #3 điều phối việc tính và chuyển lương

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


public class SalaryTransfer {

 private final MoneyTransfer moneyTransfer = new MoneyTransfer();
 private final SalaryCalculator salaryCalculator = new SalaryCalculator();

 public void salaryTransfer(int workingDay, int salaryPerDay, String accountNo) throws SalaryException {

 int salary = salaryCalculator.calcSalary(workingDay, salaryPerDay);
 moneyTransfer.transferMoney(accountNo, salary);
 System.out.println("Transfer Salary success");

 }

 public static void main(String[] args) {
 SalaryTransfer salaryTransfer = new SalaryTransfer();

 try {
 salaryTransfer.salaryTransfer(Integer.parseInt(args[0]), Integer.parseInt(args[1]), args[2]);
 } catch (NumberFormatException e) {
 System.out.println("Parse int error " + e.getMessage());
 } catch (SalaryException e) {
 System.out.println(e.getMessage());
 }
 }
}

Ở đây mình viết luôn hàm main để thử chạy luôn. Các bạn có thể xem full ví dụ ở repo này

4. Build và test

Ta chạy command sau để build

./gradlew clean build

và test thử:

java -cp build/libs/*.jar dev.trile.customexception.SalaryTransfer 11 1000000 EM1

Transfer 11000000 to EM1
VCB only support transfer amount less than 10M
Retry with VTB
VTB transfer success
Transfer Salary success

java -cp build/libs/*.jar dev.trile.customexception.SalaryTransfer -1 1000000 EM1

WorkingDay less than or equal zero

java -cp build/libs/*.jar dev.trile.customexception.SalaryTransfer 10 -1000000 EM1

SalaryPerDay less than or equal zero

java -cp build/libs/*.jar dev.trile.customexception.SalaryTransfer 15 1000000 EM1

Transfer 15000000 to EM1
VCB only support transfer amount less than 10M
Retry with VTB
VTB transfer success
Transfer Salary success

Kết luận: bằng việc sử dụng custom Exception giúp code trở nên rõ ràng và nhất quán trong việc xử lý nếu có lỗi xảy ra

Trường hợp thông thường khi có 1 Exception được throw ra thì flow sẽ bị break như ở hàm calcSalary và salaryTransfer
Trường hợp ta có hướng xử lý cho một Exception cụ thể thì ta sẽ thực hiện try/catch và handle như ở MoneyTransfer.moneyTransfer

Clean Code with Exception

contact@trile.dev (Tri Le) — Tue, 21 Jan 2020 08:36:15 +0700

Không biết anh em lúc mới làm quen thế nào chứ lúc mình học Java thì cái làm mình cảm thấy khó chịu nhất là Exception. Cứ hở một chút là bắt try/catch (sẽ có một bài viết chi tiết hơn về vấn đề này) và làm cho code mình trở nên cực kỳ kinh khủng. Nhưng sau thời gian tìm hiểu thì mình nhận thấy đây là một thứ khá hay ho trong lập trình.

Vì sao à? Đọc tiếp nhé :v

Giả sử team mình nhận được một yêu cầu từ síp lớn là viết chương trình tính và chuyển lương cho nhân viên công ty. Từ yêu cầu này síp mình phân tích cần làm 3 việc sau:

Tính lương cho nhân viên -> mình làm
Chuyển lương tới nhân viên -> bạn ngồi kế bên làm
Điều phối việc tính và chuyển lương -> síp làm

Thông số truyền vào số ngày làm việc trong tháng và tiền lương trong một ngày. Quá đơn giản phải k ;)

1
2
3


pubic int calcSalary(int workingDay, int salaryPerDay) {
 return workingDay * salaryPerDay;
}

Sau khi đưa síp review thì bị la! workingDay và salaryPerDay âm thì như thế nào?

Mình nhanh nhẩu trả lời: Thì cái thằng gọi bên ngoài phải handle chứ!
Ổng phản damage: Tao là thằng gọi nè, chú phải tự validate chứ! Đừng quá tin anh. Vừa nói ổng vừa mỉm một nụ cười bí ẩn :~

Thế là hậm hụi ngồi viết lại :(.

Từ yêu cầu của síp ta cần trả về thông tin để síp có thể biết lúc nào thông tin nhập bị lỗi, lỗi cụ thể là gì và kết quả lương nếu không có lỗi. Vấn đề bắt đầu từ đây. Từ signature của hàm dễ hiểu nhìn vào là hiểu ngay. Giờ phải thêm thông tin để hàm gọi biết param truyền vào đúng valid không nên mình trả về là một class chứa lương và mã lỗi, mã lỗi là 0 tương ứng không có lỗi

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22


class SalaryResult {
 private int salary = 0;
 private int errorCode = 0;

 // getters and settters
}

pubic SalaryResult calcSalary(int workingDay, int salaryPerDay) {
 SalaryResult res = new SalaryResult();

 if(workingDay < 0) {
 res.setErrorCode(1)
 }

 if(salaryPerDay < 0) {
 res.setErrorCode(2)
 }

 res.setSalary(workingDay * salaryPerDay)

 return res;
}

Síp review thì lại bắt sửa tiếp. Lý do vì ổng phải điều phối việc tính lương và chuyển lương. Handle mã lỗi thôi thì ổng phải map mấy cái mã lỗi trả về để show cho user. Việc này thì ổng nói không phải là việc của ổng, “It not my business”. WTF x2 ;))

Như vậy mình cần làm cách nào đó để thỏa các yêu cầu sau:

Signature của hàm phải tường minh. Nhìn cái hiểu liền
Trả về cho thằng gọi chi tiết về lỗi nhất có thể
Break flow khi có lỗi xảy ra

Sau thời gian tìm hiểu thì cái vấn đề của mình gặp thì cũng đã có rất nhiều người gặp và nó đã được giải quyết với một cách đơn giản là Exception như sau:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


public int calcSalary(int workingDay, int salaryPerDay) throws Exception {

 if(workingDay < 0)
 throw new Exception("WorkingDay less than zero");

 if(salaryPerDay < 0)
 throw new Exception("SalaryPerDay less than zero");

 return workingDay * salaryPerDay;
}

Như vậy chỉ cần thêm khai báo throws Exception và khi throw exception mình truyền thêm message thì mọi chuyện trở nên rất đơn giản.

Demo chương trình bây giờ như sau:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24


public class Salary {
 public static void main(String[] args) {

 try {
 int salary = calcSalary(21, 1_000_000);
 System.out.println("Salary: " + salary);

 // bla bla ble...
 } catch (Exception e) {
 System.out.println(e.getMessage());
 }
 }

 public static int calcSalary(int workingDay, int salaryPerDay) throws Exception {

 if (workingDay < 0)
 throw new Exception("WorkingDay less than zero");

 if (salaryPerDay < 0)
 throw new Exception("SalaryPerDay less than zero");

 return workingDay * salaryPerDay;
 }
}

Các bạn có thể thay thế thay thế workingDay hoặc salaryPerDay nhỏ hơn 0 để xem kết quả nhé

Kết luận: bằng việc sử dụng Exception ta có thể:

Làm cho method signature dễ hiểu
Trả về thêm thông tin lỗi (nếu có) bằng cách sử dụng custom Exception, mình sẽ có bài nói rõ hơn về cái này nhé.
Code control bên ngoài dễ hiểu hơn khi tách biệt code bussiness và handle lỗi, mình cũng sẽ có bài về phần này

Java String Concatenation Performance

contact@trile.dev (Tri Le) — Mon, 18 Mar 2019 21:35:56 +0700

Hello anh em!
Ở bài trước mình đã giới thiệu các bạn cách tạo một project JMH với Gradle. Bài này mình sẽ so sánh hiệu năng các cách nối chuỗi trong Java.

Cuối bài mình có show một report như sau:

Benchmark	Mode	Cnt	Score		Error	Units
StringAppend.bmStringBuffer	thrpt	5	13566863.27	±	427443.554	ops/s
StringAppend.bmStringBufferx0005	thrpt	5	5529261.499	±	277625.096	ops/s
StringAppend.bmStringBufferx1000	thrpt	5	36998.492	±	2895.325	ops/s
StringAppend.bmStringBuilder	thrpt	5	13462457.33	±	978240.749	ops/s
StringAppend.bmStringBuilderx0005	thrpt	5	5466705.447	±	176616.966	ops/s
StringAppend.bmStringBuilderx1000	thrpt	5	36989.126	±	1716.705	ops/s
StringAppend.bmStringConcat	thrpt	5	27930719.3	±	581249.324	ops/s
StringAppend.bmStringConcatx0005	thrpt	5	7170529.805	±	383608.303	ops/s
StringAppend.bmStringConcatx1000	thrpt	5	47104.039	±	2358.121	ops/s
StringAppend.bmStringJoin	thrpt	5	10204201.92	±	463528.75	ops/s
StringAppend.bmStringJoinx0005	thrpt	5	4322622.068	±	49032.328	ops/s
StringAppend.bmStringJoinx1000	thrpt	5	30493.885	±	1708.261	ops/s
StringAppend.bmStringPlus	thrpt	5	13689364.1	±	509784.615	ops/s
StringAppend.bmStringPlusx0005	thrpt	5	5590364.456	±	277476.212	ops/s
StringAppend.bmStringPlusx1000	thrpt	5	288.086	±	15.175	ops/s

đây là kết quả về so sánh hiệu năng các cách nối chuỗi trong Java.

Và giờ mình sẽ làm giải thích vì sao lại có kết quả như vậy.

1. String Plus (Toán tử cộng)

Đây là cách nối chuỗi phổ biến nhất trong Java. Ví dụ:

1
2


String str = "Hello ";
str += "world";

dòng 1 sẽ tạo ra 1 đối tượng String có giá trị “Hello”, dòng 2 sẽ tạo một String khác có giá trị “Hello world”, nhưng trước khi tạo ra 1 String mới Java sẽ kiểm tra đối tượng đó đã ở trong String Poll hay không. Trường hợp có sẽ không tạo ra String mới mà dùng String trong pool, nếu không có sẽ tạo ra String mới và thêm vào pool (mình sẽ có bài nói chi tiết hơn).

Như kết quả mình show thì nó cách này có hiệu năng tốt ở x1 và x5 nhưng tệ nhất với x1000. Vì khi này Java sẽ chỉ tạo 1 vài String và sẽ không làm ảnh hưởng tới performance với số lần lặp lớn.

2. String Concat

So sánh với String Plus thì tốc độ chênh lệch rất lớn. Vậy tại sao mà có chênh lệch lớn thế? Ta cùng xem code nhé:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


public String concat(String str) {
 int otherLen = str.length();
 if (otherLen == 0) {
 return this;
 }
 int len = value.length;
 char buf[] = Arrays.copyOf(value, len + otherLen);
 str.getChars(buf, len);
 return new String(buf, true);
}

Dòng code trên sẽ tạo ra 1 String mới bằng cách copy char array của 2 String trên. Như thế sẽ không có sự tham gia của String Pool và sẽ tiết kiệm được kha khá chi phí.

3. String Builder

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17


public AbstractStringBuilder append(String str) {
 if (str == null)
 return appendNull();
 int len = str.length();
 ensureCapacityInternal(count + len);
 str.getChars(0, len, value, count);
 count += len;
 return this;
}

private void ensureCapacityInternal(int minimumCapacity) {
 // overflow-conscious code
 if (minimumCapacity - value.length > 0) {
 value = Arrays.copyOf(value,
 newCapacity(minimumCapacity));
 }
}

Ở trên là 2 phương thức sẽ được gọi khi ta thực hiện phương thức append(). Như ta thấy tinh thần cũng giống với concat ngoại trừ việc trả về AbstractStringBuilder thay vì tạo ra một String mới

4. String Buffer

String Buffer là phiên bản Thread safe của String Builder nên việc kết quả chậm hơn là hiển nhiên. Ta có thể xem qua code sau để hiểu cách implement thread safe:

1
2
3
4
5


public synchronized StringBuffer append(String str) {
 toStringCache = null;
 super.append(str);
 return this;
}

Từ khóa synchronized chỉ định trong một thời điểm chỉ có một thread có thể thực hiện được method, và nhờ có nó sẽ đảm bảo thread safe.

5. String Join

Kết luận:

Nếu còn thiếu cách nào anh em có thể comment hoặc là tạo merge request để mình update thêm nhé ; ))

Benchmark với Jmh và Gradle

contact@trile.dev (Tri Le) — Tue, 05 Mar 2019 18:29:49 +0700

JMH là Java Microbenchmark Harness. JMH là công cụ giúp cho cho việc benchmark được chính xác và dễ đàng hơn.
Việc benchmark này cực kỳ có ích đối với ứng dụng cần tốc độ cao, giúp chọn ra thuật toán hay thư viện cho tốc độ tốt nhất.

OK! Lý thuyết vậy đủ rồi, đi vào thực hành nào. Việc chúng ta cần làm là viết 1 project so sánh tốc độ của các cách nối chuỗi trong Java. Nhớ cài java và gradle trước nhé anh em

B1: Tạo ra 1 gradle project. Các bạn mở Terminal ra và gõ lệnh sau:
gradle init
rồi chọn những option sau:

Select type of project to generate:
1: basic
2: groovy-application
3: groovy-library
4: java-application
5: java-library
6: kotlin-application
7: kotlin-library
8: scala-library
Enter selection (default: basic) [1..8] 4
Select build script DSL:
1: groovy
2: kotlin
Enter selection (default: groovy) [1..2] 1
Select test framework:
1: junit
2: testng
3: spock
Enter selection (default: junit) [1..3] 1
Project name (default: jmh-gradle-example):
Source package (default: jmh.gradle.example): tri.le.jmh

B2: Copy Copy thư mục main ra thư mục jmh
cp -r src/main src/jmh
Mục đích của việc này là để phân biệt 3 phần: code chính, code test và code benchmark

B3: Update file build.gradle, thêm id "me.champeau.gradle.jmh" version "0.4.8" vào plugins

B4: Setup xong rồi, giờ viết code thôi ; )). Để nhanh thì anh em copy file này về và mình sẽ giải thích luôn:

1

@Warmup(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)

thực hiện “làm nóng” 5 lần mỗi lần 1 giây. Vậy tại sao cần warmup? Java sẽ tự động tối ưu hóa code, vì thế khi warmup sẽ giúp ta có được kết quả benchmark chính xác

1

@Measurement(iterations = 5, time = 1, timeUnit = TimeUnit.SECONDS)

thực hiện benchmark trong 5 lần mỗi lần 1 giây

1
2


@Fork(1)
@State(Scope.Thread)

JMH sẽ tạo ra 1 tiến trình con cho mỗi case benchmark. Việc tạo ra tiến trình con này để đảm bảo bộ tối ưu hóa được reset lại và kết quả benchmark được chính xác hơn

B5: và benchmark nào
./gradlew --no-daemon clean jmh
kết quả được show ở console hoặc có thể xem lại bằng lệnh sau:
cat build/reports/jmh/results.txt

Benchmark Mode Cnt Score Error Units
StringAppend.bmStringBuffer thrpt 5 13566863.267 ± 427443.554 ops/s
StringAppend.bmStringBufferx1000 thrpt 5 36998.492 ± 2895.325 ops/s
StringAppend.bmStringBufferx5 thrpt 5 5529261.499 ± 277625.096 ops/s
StringAppend.bmStringBuilder thrpt 5 13462457.325 ± 978240.749 ops/s
StringAppend.bmStringBuilderx1000 thrpt 5 36989.126 ± 1716.705 ops/s
StringAppend.bmStringBuilderx5 thrpt 5 5466705.447 ± 176616.966 ops/s
StringAppend.bmStringConcat thrpt 5 27930719.298 ± 581249.324 ops/s
StringAppend.bmStringConcatx1000 thrpt 5 47104.039 ± 2358.121 ops/s
StringAppend.bmStringConcatx5 thrpt 5 7170529.805 ± 383608.303 ops/s
StringAppend.bmStringJoin thrpt 5 10204201.921 ± 463528.750 ops/s
StringAppend.bmStringJoinx1000 thrpt 5 30493.885 ± 1708.261 ops/s
StringAppend.bmStringJoinx5 thrpt 5 4322622.068 ± 49032.328 ops/s
StringAppend.bmStringPlus thrpt 5 13689364.101 ± 509784.615 ops/s
StringAppend.bmStringPlusx1000 thrpt 5 288.086 ± 15.175 ops/s
StringAppend.bmStringPlusx5 thrpt 5 5590364.456 ± 277476.212 ops/s

Anh em có thể tham khảo git repo sau nhé. :))

First post

contact@trile.dev (Tri Le) — Sun, 11 Mar 2018 00:00:00 +0000

This article offers a sample of basic Markdown syntax that can be used in Hugo content files, also it shows whether basic HTML elements are decorated with CSS in a Hugo theme.

Headings

The following HTML <h1>—<h6> elements represent six levels of section headings. <h1> is the highest section level while <h6> is the lowest.

H1

H2

H3

H4

H5

H6

Paragraph

Xerum, quo qui aut unt expliquam qui dolut labo. Aque venitatiusda cum, voluptionse latur sitiae dolessi aut parist aut dollo enim qui voluptate ma dolestendit peritin re plis aut quas inctum laceat est volestemque commosa as cus endigna tectur, offic to cor sequas etum rerum idem sintibus eiur? Quianimin porecus evelectur, cum que nis nust voloribus ratem aut omnimi, sitatur? Quiatem. Nam, omnis sum am facea corem alique molestrunt et eos evelece arcillit ut aut eos eos nus, sin conecerem erum fuga. Ri oditatquam, ad quibus unda veliamenimin cusam et facea ipsamus es exerum sitate dolores editium rerore eost, temped molorro ratiae volorro te reribus dolorer sperchicium faceata tiustia prat.

Itatur? Quiatae cullecum rem ent aut odis in re eossequodi nonsequ idebis ne sapicia is sinveli squiatum, core et que aut hariosam ex eat.

Blockquotes

The blockquote element represents content that is quoted from another source, optionally with a citation which must be within a footer or cite element, and optionally with in-line changes such as annotations and abbreviations.

Blockquote without attribution

Tiam, ad mint andaepu dandae nostion secatur sequo quae. Note that you can use Markdown syntax within a blockquote.

Blockquote with attribution

Don’t communicate by sharing memory, share memory by communicating.
— Rob Pike¹

Tables

Tables aren’t part of the core Markdown spec, but Hugo supports supports them out-of-the-box.

Name	Age
Bob	27
Alice	23

Inline Markdown within tables

Italics	Bold	Code
italics	bold	`code`

Code Blocks

Code block with backticks

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <title>Example HTML5 Document</title>
</head>
<body>
 <p>Test</p>
</body>
</html>

Code block indented with four spaces

<!doctype html>
<html lang="en">
<head>
<meta charset="utf-8">
<title>Example HTML5 Document</title>
</head>
<body>
<p>Test</p>
</body>
</html>

Code block with Hugo’s internal highlight shortcode

 1
 2
 3
 4
 5
 6
 7
 8
 9
10


<!doctype html>
<html lang="en">
<head>
 <meta charset="utf-8">
 <title>Example HTML5 Document</title>
</head>
<body>
 <p>Test</p>
</body>
</html>

List Types

Ordered List

First item
Second item
Third item

Unordered List

List item
Another item
And another item

Nested list

Fruit
- Apple
- Orange
- Banana
Dairy
- Milk
- Cheese

Other Elements — abbr, sub, sup, kbd, mark

GIF is a bitmap image format.

H₂O

Xⁿ + Yⁿ = Zⁿ

Press CTRL+ALT+Delete to end the session.

Most salamanders are nocturnal, and hunt for insects, worms, and other small creatures.

Emoji

https://gist.github.com/rxaviers/7360908#file-gistfile1-md

The above quote is excerpted from Rob Pike’s talk during Gopherfest, November 18, 2015. ↩︎

TriLe.dev

Identify Responsibilities and Boundaries: The Key to design a Loose Coupling and High Cohesion system

1. What’re Coupling and Cohesion?

2. Identifying Responsibilities and Boundaries

2.1. Applying Responsibility and Boundaries at the Domain Level

2.2. Single Responsibility

2.3 Interface Dependency

3. Who will identify responsibilities and boundaries?

4. Conclusion

Reference links

The Importance of Modularity and DDD in System Architecture

Modularity

DDD

How to Combine Modularity with DDD

Conclusion

Reference links

Kotlin Coroutines vs LMAX Disruptor: Benchmarking for Asynchronous and Concurrent Programming

Introduction

Benchmarking Process

Benchmark Results

Conclusion

Reference links

Comparing Git Flow, Trunk Based and GitHub Flow

1. Git Flow

2. Trunk Based

3. GitHub Flow

4. Conclusion

Reference articles

Parameterized Test in JUnit 5

Required Setup

Argument Sources

@ValueSource

@EnumSource

@MethodSource

@CsvSource

@CsvFileSource

@ArgumentsSource

Customizing Display Names

Reference articles

Use Mock to make Unit Test easy

What’s Mock

Mock and Dependency Injection

Example Unit Test with Mock

Reference articles

How to Write Testable Code

Write a simple Unit

Separation Between Logic and Presentation

Consistency Unit

Apply Ioc/DI

Apply S.O.L.I.D principles

Reference articles

What are S.O.L.I.D principles?

Introduction to S.O.L.I.D principles

Single responsibility priciple

Open/Closed principle

Liskov substitution principe

Interface segregation principle

Dependency inversion principle

Reference articles

Introduction to Unit Test

What is Unit Test?

Why do I have to write Unit Test?

Concepts in Unit Test?

Inversion of Control and Dependency Injection

1. Dependency problem in OOP

2. What is Inversion of Control?

3. What is Dependency Injection?

4. Implement Salary Transfer by Dependency Injection

Resolve Race Condition problems with Map-Reduce and Coroutines

1. What is Race Condition?

2. How to resolve Race Condition?

1. Sử dụng Synchronizations1 hoặc Atomic Operations2

2. Tránh chia sẻ trạng thái

3. What is Map-Reduce?

Resolve Race Condition with Map-Reduce

Kotlin Coroutines Basic Concepts

1. Dispatchers

2. Scope

GlobalScope

Scope Builder

1. Sử dụng Synchronizations¹ hoặc Atomic Operations²

Remove `new` keyword