전체 글

이번 챕터는 언제 리팩터링 해야 하는가? 어떤 코드가 리팩터링이 필요한 코드인가?에 대해서 다룬다. (적어도 나는)코드가 구조적으로 예쁘지 않아서, 보고 있자니 뭔가 마음 한켠이 불편해서, 같은 '느낌'을 감지하고 리팩터링을 하게 되는데 이런 모호한 기준을 끄집어 내서 문장으로 구체화한 챕터이다. 리팩터링이 필요한 코드가 가지고 있는 공통점, bad smell에 대해서 얘기한다. 무엇이 문제인지 알아야, 그에 따른 해결 방안도 떠올릴 수 있다. 부록B에 보면 bad smell case와 해법이 잘 정리되어 있음. 정리하면서 평소 개발하면서 정립했던 나의 개인적인 의견도 같이 적어 두었음. (인용구로 되어 있는 부분) 3.1 기이한 이름 함수든, 변수든, 클래스든 이름만 보고도 각각이 무슨 일을 하고 어떻..

구축 https://github.com/deviantony/docker-elk JVM Heap이 256m으로 작게 설정되어 있어서 이를 늘려주어야 함. docker-compose.yml 의 `` ES_JAVA_OPTS, LS_JAVA_OPTS`` 설정. 설정하지 않으면 ES나 Logstash 인스턴스가 java.lang.OutOfMemoryError: Java heap space 뜨면서 죽어버릴 수 있음. 설정 후 Management - Stack Monitoring 항목 확인해볼 것. https://www.elastic.co/guide/en/logstash/current/jvm-settings.html 사이즈는 어떻게? 4 ~ 8 정도로 하라고 나와 있지만 여의치 않으면 2g 정도로도 잘 돌아간다. h..

스레드, 컨텍스트 스위칭에 대한 이해 스레드가 수행하는 더 이상 쪼개지지 않는 작업 최소 단위는 CPU instruction 이다. 즉. 어셈블리. interrupt가 들어오면, 지금 하고 있는 인스트럭션 까지 마치고 나서 컨텍스트 스위칭 하게 된다. 스레드 context switching 시, 스레드 컨텍스트(레지스터 등등)가 저장되었다가, 재시작 시 불러와서 이어서 실행하게 된다. e.g., CPU instruction 어디까지 수행했는지는 EIP 레지스터. 직전에 더하려던 값은 EAX 레지스터 등등. 무언가에 1을 더하는 작업을 CPU instruction으로 나누어 보면 최소 아래 3가지로 구성된다. (CAS는 예외) ```assembly load (from mem to reg) add reg, ..

Kotlin Coroutines 기본적인 개념과 docs kotlinlang.org/docs/coroutines-guide.html#table-of-contents 참고 ) Kotlin Coroutine은 어떻게 동작하는가 - CPS 관련 설명, 자주 하는 질문까지 포함한 좋은 발표 자료 참고 ) 어떠한 코루틴이 발동될 때 마다 해당 코루틴은 이전에 자신의 실행이 마지막으로 중단되었던 지점 다음의 장소에서 실행을 재개한다. Kotlin의 Coroutine은 suspend 키워드로 마킹된 함수를 CPS(Continuation Passing Style)로 변환하고, 이를 Coroutine Builder를 통해 적절한 스레드 상에서 시나리오에 따라 동작하도록 구성됩니다. 주의해야 할 점은 suspend fun..

Jackson ObjectMapper 변환 https://stackoverflow.com/questions/10519265/jackson-overcoming-underscores-in-favor-of-camel-case A. @JsonProperty 애너테이션으로 각 필드에 명시해주는 방법 [Java] Jackson ObjectMapper Serialization 좀 귀찮지만, 줄임말 등을 내부 컨벤션에 맞는 이름으로 바꿔줄 수 있어서 오히려 유용할 수 있음. B. 각각의 data class에서 @JsonNaming 애너테이션으로 어떤 이름 변환 사용할지 명시해 주는 방법 ```java @JsonNaming(PropertyNamingStrategy.SnakeCaseStrategy.class) ``` C...

컨슈머? 파티션 리더에게 메시지 가져오기 (Consume) 다른 메시지큐 처럼 소비하면 없어지나? ⇒ X 기본값 7일 동안 저장했다가 삭제 ⇒ 필요하다면 이미 가져온 데이터도 다시 가져올 수 있음 ⇒ 여러 컨슈머 그룹에서 메시지 수신 가능 컨슈머 중요 옵션 group.id 컨슈머 그룹 식별자 fetch 관련 fetch.min.bytes 한 번에 가져오는 데이터의 최소 사이즈. 지정한 사이즈 보다 작은 경우 요청에 응답하지 않고 데이터가 누적될 때 까지 기다림. (default 1byte) fetch.max.wait.ms 사이즈가 작아서 기다린다면 최대 몇 초 동안 기다릴건지? (default 500ms) max-wait 시간 지나면 쌓인 데이터가 min-bytes 보다 작아도 그냥 컨슈머로 보내기 때문에..

Oracle로 설명했지만 대부분의 DB in docker image에서 통하는 내용이다. 문제 상황 Oracle docker image를 사용해서 DB 올리고 작업하고 있는데, insert된 row들 날짜 필드 시간이 안맞는다. (UTC -> Asia/Seoul)로 timezone 설정이 필요한 상황이다. ```sql SELECT SYSDATE, CURRENT_DATE, DBTIMEZONE, SESSIONTIMEZONE FROM DUAL; -- 현재 시각은 한국 기준 05-19 00:38:51 +-------------------+--------------------------+----------+---------------+ |SYSDATE |CURRENT_DATE |DBTIMEZONE|SESSIONT..

Pagination https://en.wikipedia.org/wiki/Select_(SQL)#Result_limits 12c 버전 이후라면? : Row Limiting Clause https://oracle-base.com/articles/12c/row-limiting-clause-for-top-n-queries-12cr1 myjamong.tistory.com/170 12c 이전에는? https://stackoverflow.com/questions/241622/paging-with-oracle https://blogs.oracle.com/oraclemagazine/on-top-n-and-pagination-queries https://use-the-index-luke.com/sql/partial-re..

flyway는 DB에 schema_version 테이블을 유지하면서, DB 상태를 버전으로 관리할 수 있게끔 도와준다. (나중에 DB를 실행해도 버전에 맞게 데이터를 밀어넣어준다.) DB에 데이터가 존재하는 상태에서 flyway를 적용할 때 발생하는 문제 ``` Caused by: org.flywaydb.core.api.FlywayException: Found non-empty schema "SYSTEM" without metadata table! Use baseline() or set baselineOnMigrate to true to initialize the metadata table. ``` DB가 비어있지 않아(상태를 가지고 있어) flyway를 적용할 수 없다는 것. flyway를 사용하려면 ..

블로그 포스팅은 업데이트 X. 상세 내용은 위 pdf 참조. 운영에서는 다른 DB 쓰고, TC는 다른 DB(In-Memory) 사용할 때의 문제점 유닛테스트에서는 DB를 안쓰거나, 간단한 쿼리 정도 사용하게 되므로 In-Memory 사용해도 무방하지만 복잡한 쿼리를 포함하여 실행하는 통합테스트는 In-Memory DB를 사용하면 아래와 같은 문제를 마주할 수 있다. 운영 DB는 Oracle 쓰고 있었는데, TC나 오프라인 환경에서는 H2를 사용하게끔 변경했다. 그러나... 다음과 같은 문제점이 있음. 운영 DB와 In-Memory DB의 문법이 100% 호환 되지 않는다. `` sysdate - ?`` 같은건, 오라클에서는 그냥 사용 가능하지만 H2에서는 타입 추론이 안돼서 ?를 CAST 해주어야 한다...

martinfowler.com/bliki/CQRS.html (번역) CRUD를 모두 같은 모델을 사용해 처리했었다면, CQRS는 CUD를 Command로, R을 Query로 분리하여 설계하는 방법 하지만 문서 전체에서 CQRS는 잘 들어맞는 부분에만 일부 사용할 것을 권장하고 있다. 문서에서 발췌 CQRS는 시스템의 특정한 부분(DDD 표현으로는 Bounded Context)에서만 사용돼야 하고, 시스템 전체에서 사용해서는 안 된다. 이러한 사고방식은 각 Bounded Context는 개별적으로 모델링을 해야 한다는 의미다. (Bounded Context: https://www.martinfowler.com/bliki/BoundedContext.html) 많은 정보 시스템들은 정보를 기반으로 한가지 방식..