kotlin31 Kotlin Coroutine에서의 TraceId는 어떻게 주입하나 ? - Context 전파와 MDCContext 코루틴을 사용하면서 발생하는 주요 문제 중 하나는 실행 컨텍스트의 전파입니다. 특히 분산 시스템에서 로깅과 추적을 위해 중요한 역할을 하는 traceId와 MDC(Mapped Diagnostic Context)의 사용이 이에 해당합니다. 이번 글에서는 코루틴 환경에서 traceId와 MDC를 어떻게 효과적으로 전파할 수 있는지 알아보겠습니다.요약traceId란 무엇이고 어떻게 활용할 수 있는가 ?traceId는 분산 시스템에서 요청을 추적하고 각 서비스간의 연관성을 식별하는 데 사용되는 유니크한 식별자ThreadLocal과 MDC(mapped diagnostic contexts)란 무엇인가?ThreadLocal은 자바에서 제공하는 클래스로, 각 쓰레드가 자신만의 데이터 복사본을 갖도록 해서, 쓰레드 사이.. 2024. 7. 8. [kotlin] 코틀린 차곡차곡 - 19. Functional (SAM) interfaces 안녕하세요 ! 오늘은 이전 시간에 이어서 코틀린 Functional interfaces에 대해서 알아보도록 하겠습니다. Functional Interfaces 란 ? Functional Interface는 Java 8 부터나온 개념입니다. 이 개념은 그대로 kotlin에서도 사용이 가능합니다. Java의 Functional Interface의 개념이 궁금하신 분은 이전에 제가 이전에 아래 2개의 포스팅을 작성한 적이 있습니다. 해당 포스팅을 참고해주시기 바랍니다. [java8] java의 주요 functional interface - Function, Supplier, Consumer [java8] java의 주요 functional interface - Predicate, Operator functio.. 2023. 2. 7. [kotlin] 코틀린 차곡차곡 - 18. value class (inline class) 안녕하세요. 오늘은 오랫만에 코틀린 알아보는 포스팅으로 찾아왔습니다. 오늘 여러분들에게 소개해드릴 코틀린 개념은 value class입니다. 자 그럼 바로 들어가보도록 하겠습니다. 상황 설명 유저 정보를 담는 Entity를 만들어보도록 하겠습니다. email, hashedPassword, displayName, createdAt 필드를 가지도록합니다. 그리고 email은 email의 특정 형식이 있습니다. 하지만 User Entity에서는 String 형식으로 email을 받고 있기때문에 email 형식을 충족시키지 못하더라도 Entity 생성을 할 수 있습니다. 이러한 검증을 위해서 init을 이용할 수 있습니다. 그리고 email의 경우 domain과 id를 @ 기준으로 분리할 수 있기 때문에 해당 .. 2023. 2. 4. CQRS(Command and Query Responsibility Segregation) 맛보기 - 실습편 안녕하세요. 이전 포스팅에서 우리는 CQRS는 어떤것이고 어떤 장점과 단점을 가지고 있는지 함께 보는 시간을 가져보았습니다. 오늘은 CQRS를 한번 실습해보는 시간을 가져보도록 하겠습니다.이전 시간에 CQRS를 설명할 때 두가지 모델뿐만 아니라 CQRS를 지속적으로 이어주기 위한 사이드적인 매커니즘들이 필요하다고 말씀드렸었습니다. 그러한 부분을 함께 보도록 하겠습니다.1편 : CQRS(Command and Query Responsibility Segregation) 맛보기 - 이론편환경오늘 포스팅에서 사용할 환경은 아래와 같습니다. write DB의 DataSource는 MongoDB를 이용합니다. 그리고 Read 모델의 Repository는 Redis 라고 명시해 두었지만 실습이기 때문에 빠른 구현을 .. 2022. 6. 25. [kotlin] 코틀린 차곡차곡 - 17. require와 check 안녕하세요. 오늘은 오랫만에 코틀린 차곡차곡 시리즈로 찾아왔습니다. 오늘 여러분들께 공유 드릴 내용은 코틀린에서 validation에 대해서 이미 정해져 있는 코드들에 대한 내용입니다. 기존의 validation asis 메서드를 원하는 바로 정확하게 실행시키기 위해서는 실제 본연의 메서드 로직을 실행시키기전에 validation으로 input으로 들어오는 파라미터의 값이나 사용하는 상태 적절한지에 대한 판단이 필요합니다. 이러한 validation은 보통 아래의 2가지로 나눌 수 있습니다. 파라미터 값 자체에 대한 validation 파라미터 값에 의한 기존 Entity를 비롯한 도메인이 가지고 있는 상태에 대한 validation 이러한 valitaion을 구현한다고 하면 기존에는 아래의 코드처럼 일.. 2022. 6. 5. [kotlin] 레거시(legacy) 코드 리팩토링하기 3편 - 리팩토링 진행하기 1편 : 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 2편 : 레거시(legacy) 코드 리팩토링하기 2편 - 리팩토링 진행하기 안녕하세요. 레거시를 리팩토링하는 3번째 시간입니다. 오늘은 이전 포스팅에서 만들어둔 라인커버리지 100%의 테스트코드에 대한 신뢰를 바탕으로 코드가 좋은 가독성을 가지는 방향으로 리펙토링을 실제로 진행해보고자 합니다. 환경 환경은 이전 시간과 마찬가지로 아래와 같습니다. 기본적인 테스트 프레임워크는 JUnit5를 사용하며 mockking을 위해서 Unit 테스트 라이브러리인 mockk를 추가로 사용합니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-t.. 2022. 5. 16. [kotlin] 레거시(legacy) 코드 리팩토링하기 2편 - 라인커버리지 100% 달성하기 안녕하세요. 오늘은 [kotlin] 레거시(legacy) 코드 리팩토링하기 1편에 이어서 테스트를 통해 실제로 라인커버리지를 100% 달성해보는 포스팅을 진행해보고자 합니다. 이전 편은 테스트 코드를 작성해야 하는 이유에 대해서 설명했습니다. 관심있으신 분들은 한번 보시는것을 추천드립니다. 환경 이번 포스팅과 다음 포스팅에 진행되는 test 환경에는 JUnit5와 코틀린 mock에 주로 사용하는 mockk 라이브러리를 이용하였습니다. build.gradle.kts의 implementation는 아래와 같이 선언하였습니다. // JUnit5 testImplementation("org.springframework.boot:spring-boot-starter-test") { exclude(group = "or.. 2022. 4. 23. [kotlin] 레거시(legacy) 코드 리팩토링하기 1편 - 테스트 코드를 작성해야하는 이유 안녕하세요. 서비스의 시간이 오래되면 레거시 코드에 대해 고민이 생기기 마련입니다. 특히 이제는 퇴사한 사람이 남기고간 장황하고 이유를 알 수 없는 코드에 수정이 필요하게 되면 덜컥 겁이나기 시작합니다. 그런 코드들은 생성된 시간이 오래되면 오래될수록 공포감도 커지고 건들고 싶지 않아집니다. 하지만 그렇다고 수정을 안할수도 없습니다. 무작정 수정하게되면 실수 등에 의해서 잘 되던게 오히려 잘못 동작할수도 있습니다. 때문에 우리는 수정하기에 앞서 어느정도 안전장치를 만들어둘 필요가 있습니다. 그것이 바로 테스트 코드를 작성하는 것입니다. 오늘은 레거시 코드에 테스트 코드를 작성하고 커버리지를 올리는 방법에 대해서 알아보는 시간을 가져보도록 하겠습니다. 레거시 코드에 유닛 테스트 코드를 추가하면서 얻을 수 .. 2022. 4. 16. [kotlin] 코틀린 차곡차곡 - 16. kotlin JVM annotation 알아보기 2편 안녕하세요. 오늘은 이전 시간에 이어서 JVM annotation에 대해서 알아보는 시간을 가져보도록 하겠습니다. 오늘 알아볼 코틀린의 JVM annotation은 이전시간에 알아보지못한 @JvmOverloads, @JvmDefault, @Throws, @JvmWildcards 등입니다. @JvmOverloads 코틀린과 자바는 100% 호환 된다고 합니다. 하지만 몇몇 부분에 있어서는 상호 호환이 되지 않는 부분이 있습니다. 그 중 대표적인 하나가 코틀린의 default 값에 대해서 자바에서 호출하지 못한다는 것입니다. 아래 예제 코드를 한번 보면서 좀 더 들여다 보도록 하겠습니다. 코틀린의 함수를 아래처럼 선언하면 이는 아래의 3가지 방법으로 모두 접근이 가능합니다. 코틀린에서 default 파라미터.. 2022. 1. 26. [kotlin] 코틀린 차곡차곡 - 15. kotlin JVM annotation 알아보기 안녕하세요. 오늘은 kotlin JVM annotation에 대해서 알아보는 시간을 가져보도록 하겠습니다. JVM annotation 코틀린은 컴파일 시 자바 바이트코드(.class)로 변환 되어지게 되며 다른 자바 파일들과 상호호환 되게 되고 JVM에 의해서 실행되게 되는 과정을 거칩니다. 이러한 과정 중 코틀린 파일에서 자바 바이트코드로 변경될 때좀 더 정밀한 제어를 할 수 있도록 하는 kotlin annotation이 있습니다. 이러한 어노테이션을 JVM annotation이라고 합니다. 이러한 JVM annotation의 종류는 아래와 같으며 오늘은 하나씩 차근차근 알아보는 시간을 가져보도록 하겠습니다. @JvmName @JvmStatic @JvmField @JvmDefault @JvmOverlo.. 2022. 1. 22. [gradle] buildSrc를 이용한 gradle 의존성 관리 안녕하세요. 오늘은 gradle의 의존성 관리를 좀 더 명확하고 유지관리하게 쉽게 할 수 있는 gradle의 buildSrc에 대해서 알아보는 시간을 가져보도록 하겠습니다. 빌드 도구의 상수와 함수 코딩을 하면 기본적으로 자주 사용하는 함수 또는 상수에 대해서 별도의 파일로 선언하여 여러 곳에서 참조할 수 있게합니다. 이렇게 함으로써 중복 코드를 줄이고 코드의 가독성도 높일 수 있습니다. 이건 이 글을 읽고 있는 개발자이신 여러분들에게는 기본적인 것이겠지요. gradle 에서도 buildSrc를 이용하면 이러한 방법으로 script를 작성할 수 있다는 사실을 알고 있으셨나요 ? buildSrc를 이용하면 build script를 더 쉽게 유지보수하고 가독성을 향상시킬 수 있습니다. buildSrc와 in.. 2021. 11. 22. [kotlin] kotlin 1.4.0 RELEASE 정리 안녕하세요. 오늘은 kotlin 1.4.0 버전 RELEASE에 업데이트 된 내용을 한번 살펴보도록하겠습니다. kotlin 1.4.0 코틀린 1.4.0은 성능과 품질에 집중했다고 합니다. 어떤 점이 변경되었는지 아래에서 바로 알아보겠습니다. kotlin/JVM 기준으로 알아두면 좋을것 같은 것들만 발췌하였습니다. 코틀린 Interface SAM(Single Abstract Method) Java8부터 Interface에 1개의 메서드만 가지게 되면 이를 함수형 인터페이스(Functional Interface)라고 부르며 람다(lambda)식으로 사용할 수 있게됩니다. 이를 SAM(Single Abstract Method)라고도 부릅니다. 대표적으로 Function이라는 인터페이스가 있습니다. @Funct.. 2021. 11. 11. 이전 1 2 3 다음
