본문 바로가기

분류 전체보기

 (890)
[WIL] Laravel 업데이트 현재 서비스 중인 PHP 프레임워크인 라라벨의 버전은 5.6.39이다.6년전인 2018년 2월 릴리스되었고 현재 마지막 버전은 2024년 3월에 릴리스한 11이다. 오래된 프레임워크 버전을 사용하다보니 여러가지 이슈가 나왔다.의존하고 있는 라이브러리들이 더 이상 업데이트가 되지 않고 심지어 개발 환경을 구축하기 위한 php 버전을 불편하게 설치해야 한다.예) homebrew - php@7.4 no longer works after icu4c 72 upgrade 이를 위해 개인이 만든 brew tab 을 이용하여 낮은 버전의 php 를 설치해야 했다.brew tap shivammathur/phpbrew upgrade shivammathur/php/php@7.4 반면 신규 개발 환경인 Kotlin + Spr..
[Spring] Boot update 3.3.4 to 3.3.5, MethodArgumentTypeMismatchException 변경 사항 확인 by 테스트 코드 지난 주 스프링 부트 버전 업데이트를 진행했다.스프링 부트 버전 변화에 따라 스프링 프레임워크 버전도 업데이트가 되었다.spring boot 3.3.4: spring framework 6.1.13spring boot 3.3.5: spring framework 6.1.14프레임워크의 기능을 테스트할 때를 알기Zarar의 블로그에 좋은 소프트웨어 개발 습관들(Good software development habits)이라는 글을 본 적이 있다.GeekNews에  "프레임워크의 기능에 대한 테스트를 하지 않기"로 변역이 되어 있어서 무조건 프레임워크의 기능을 테스트하지 말자로 들릴 수 있다. 하지만 나는 "프레임워크의 기능을 테스트할 때와 하지 말 때를 알자"로 해석했다.Know when you're test..
[Kotlin] 커버리지 측정 도구를 JaCoCo에서 Kover로 변경하다 그동안 Kotlin을 사용하면서 Java의 도구들을 코틀린 도구들로 변경해서 사용했습니다.JUnit → KotestMockito → MockK회사에서는 SonarQube의 클라우드 버전인 SonarCloud를 사용하여 정적 코드 분석을 사용하고 있었습니다.코드 품질 중 코드 커버리지는 JaCoCo의 XML 테스트 리포트를 이용하여 제공을 하고 있었습니다. 가끔 테스트를 할 수 없는 부분이나 이미 테스트가 완료되었음에도 커버가 안된다는 분석이 나와서 의아함을 느끼고 있었습니다. JaCoCo 오탐들Spring Boot의 애플리케이션을 수행하는 부분 코드를 보면 닫는 괄호 부분도 커버가 안된다고 JaCoCo에서는 표시가 됩니다. 또한 Java에는 없고 Kotlin에만 있는 value class도 어떤 경우는..
[JobRunr] 지연된 작업 기능으로 문자 메시지 상태 조회하기 2022년 8월 진행했던 프로젝트 중에 문자 메시지 발송하는 기능이 있었다.백오피스를 이용하는 직원들은 문자로 고객과 커뮤니케이션을 하는 일이 있었다.자주 사용하는 문구 기능과 더불어 시스템을 통한 메시지 발송 기능으로 시간 비용을 줄일 수 있었다.상태 조회문제는 문자 메시지 발송 후 상태 조회를 하는 방식이었다. 문자 메시지는 서드파티를 통해 수행했는데 1) 폴링 방식과 2) 콜백을 받는 방법 의 크게 두 가지 모두 제공하고 있었다.문자 메시지는 발송 즉시 상태는 곧바로 알 수 없었고 수초 이상 걸릴 수 있었다.따라서 언제 상태가 제대로 되는지는 알 수 없기에 후자 방식이 바람직했다. 하지만 콜백을 받기 위해서는 외부에서 훅(hook)을 줄 수 있는 인터페이스를 준비해야 했다.인프라적인 지원이 필요했는..
[Spring] @Retryable과 @Transactional 는 순서에 따라 동작을 다르게 한다? 금주에 확인한 [Spring] 중첩된 @Transactional의 readOnly 동작 확인 관련해서 인터넷에서 찾아보다가 순서에 대한 글들을 발견했다.[끄적끄적] @Transactional 안에서 retry 사용을 주의하세요 ✔스프링 @Retryable 과 @Transactional의 주석 순서에 따른 프로세스 차이 ❓1번 글은 트랜잭션 안에서 재처리 처리되는 부분이 문제가 될 수 있겠다는 점에서는 동의를 했다.2번 글의 @Retryable과 @Transactional 는 순서에 따라 동작을 다르게 한다는 글을 보고 정말로 그런지 궁금해졌다. 왜냐하면 만약 '내가 프레임워크 개발자라는 관점'으로 생각해보았을 때, 만약 Annotation의 선언 순서에 따라 동작이 달라지도록 구현을 했다면개발자들이 예측..
[Spring] 중첩된 @Transactional의 readOnly 동작 확인 배경이번 주 진행했던 작업 중에 @Transactional(readOnly = true)가 붙은 리포지토리 메서드에서 데이터를 읽지 못하는 현상이 있어서 디버깅을 했다.가설가장 먼저 떠오른 원인은 Writer 인스턴스와 Reader 인스턴스간의 복제 지연(Replication Rag)이었다. 이전 회사에서 복제 지연으로 조회 데이터가 없었던 경험이 있었기 때문이다.당시 주문 도메인을 담당하고 있었다. 주문이 만들어지고 나서 메시지 큐로 이벤트를 보내는 역할이었다. 마침 큐를 소비(consume)하는 클라이언트가 API를 통해 주문 데이터를 조회를 하고 있었다. 문제는 API가 데이터 응답을 할 때 사용하는 DB는 Reader 인스턴스에서 읽도록 구현이 되어 있었다. 당시에는 이런 상황을 위해 Writer..
[Spring] @Cacheable - null 값도 캐싱이 되고 있었다. 발단백오피스에는 사번이 아닌 이메일을 통해 로그인을 하는 정책을 가지고 있었다.IP 대신 Domain 주소를 쓰는 것처럼 본인의 사번보다는 이메일이 외우기 쉽기 때문이다.시스템 내부적으로는 대리키인 사번으로 저장한다.따라서 이메일과 사번을 매핑이 필요했다.또한 입사나 퇴사 같은 이벤트가 발생할 경우에만 바뀌므로 자주 업데이트되지 않는 데이터 유형에 속했다.따라서 latency를 줄이고 불필요한 부하를 줄이기 위하여 DB에서 매번 조회하는 것보다 캐시에서 반환하도록 하고 있었다. 신규 개발자 분이 입사하셔서 DB상 매핑 데이터를 추가했는데 계속 매핑이 안되는 현상이 발생했다.왜 그럴까 고민을 했는데 속으로 혹시 NULL 값에 대한 캐싱 때문일까 생각을 했다. 디버깅으로 오픈소스 스터디오픈소스가 어떻게 동작..
linkedin 에서 이메일 검증 + 링크드인 벤치마킹 블라인드에서는 회사 재직 확인을 회사 이메일 계정으로 한다.linked인에서도 마찬가지로 6자리 번호를 받을 회사 이메일 계정을 입력하라고 한다. 이메일 인증 관련해서 영어로 이름을 지으면 email authentication 등으로 짓는 경우가 있는데이전 Google이나 LinkedIn에서는 둘 다 email verification이라는 용어를 쓰고 있었다. '이메일 검증' 정도로 번역이 될 것 같은데 '인증'이라는 말을 직역하다보니 verification 보다 authentication 를 쓰게 되는 것 같다.이전 회사에서도 관련 유스케이스를 구현할 기회가 있었는데 처음에 email authentication를 쓰다가 나중에 verification로 변경을 했다. 완료화면에 자동 채움(autofill..

티스토리툴바