BSFactory

subscribeOn() 함수 구독(subscription)이 시작되는 스레드를 변경한다. 데이터 소스를 구독하는 스레드를 변경하는 것 publishOn() 함수 다운스트림(downstream) 연산자가 실행되는 스레드를 변경한다. 데이터 소스에서 발행되는 데이터를 처리하는 스레드를 변경 예시 코드 import reactor.core.publisher.Flux; import reactor.core.scheduler.Schedulers; public class Example { public static void main(String[] args) { Flux.just(1, 2, 3) .subscribeOn(Schedulers.elastic()) .map(i -> { // I/O 작업을 수행하는 스레드 변경 return performIOOperation(i); }) .publishOn(Schedulers.parallel()) .map(result -> { // 결과를 처리하는 스레드 변경 return processResult(result); }) .subscribe(); } private static String performIOOperation(int i) { // I/O 작업을 수행 return "result " + i; } private static Stri

HTTP 통신을 하기 위한 라이브러리 입니다. 리액티브 타입의 송/수신을 하여 Non-Blocking 통신을 지원합니다. 필요할 때 편하게 보기 위해 예제 위주로 기록 합니다. WebClinet 기본 설정 적용하여 Bean 으로 등록하는 방법 @Configuration public class WebClientConfig { @Bean public WebClient.Builder webClientBuilder () { return WebClient.builder() .baseUrl( "https://sample.io" ) .defaultHeader(HttpHeaders.CONTENT_TYPE, MediaType.APPLICATION_JSON_VALUE); } } GET 요청을 보내는 예시 WebClient webClient = WebClient.create( "https://sample.io" ); Mono<String> result = webClient.get() .uri( "/info" ) .retrieve() .bodyToMono(String.class); result.subscribe(System.out::println); POST 요청을 보내는 예시 WebClient webClient = WebClient.create( "https://sample.io" ); Mono<String> result = webClient.post() .uri( "/info" )

Mysql 실행계획 정리 MySQL Explain 결과는 일반적으로 쿼리 실행 시간, 반환된 행의 수, 사용된 인덱스 등을 포함합니다. 실행계획 결과 항목 설명 EXPLAIN SELECT * FROM member WHERE id=1; id: 쿼리의 실행 순서를 나타내는 값입니다. select_type: 쿼리의 유형을 나타내는 값입니다. (e.g. SIMPLE, PRIMARY, SUBQUERY 등) table: 쿼리에서 사용된 테이블의 이름입니다. partitions: 쿼리에서 사용된 파티션의 이름입니다. type: 테이블에 접근하는 방법을 나타내는 값입니다. (e.g. ALL, index, range 등) possible_keys: 사용 가능한 인덱스의 이름입니다. key: 쿼리에서 실제로 사용된 인덱스의 이름입니다. key_len: 쿼리에서 사용된 인덱스의 길이입니다. ref: 인덱스를 사용한 조인 조건입니다. rows: 쿼리에서 반환되는 행의 수입니다. filtered: 쿼리에서 반환된 행 중 조건에 부합하는 행의 비율입니다. Extra: 추가 정보입니다. select_type 쿼리 유형을 나타냅니다. 쿼리가 처리되는지 이해하는데 도움이 됩니다. 쿼리의 처리 방식과 테이블 간의 연결 등에 따라 달라지기 때문에 유형에 맞는 최적화된 방법 선택이 중요합니다. SIMPLE: 단일 테이블에서 데이터를 조회. 단순한 데이터 조회인 경우 입니다. PRIMARY: 다른 쿼리의 서브쿼리로 사용되는 경우가 대부분 입니다. 서브쿼리, 외부쿼리 사용 시 첫 번쨰 쿼리인 경우 입니다. SUBQUERY: 다른 쿼리의 서브쿼리로 사용. 실행 계획이 먼저 실행된 다음 외부 쿼리에 의해 실행 됩니다. DERIVED: FROM 절에 대한 서브쿼리. UNION: UNION 을 사용하여 두 개 이상의 SELECT 문을 결합하는 경우 입니다. UNION RESULT: UNION 연산자로 결합된 결과를 반환하는 경우 입니다. DEPENDENT UNION: UNION 연산자가 서브쿼리에 의존하는

ZSH 히스토리 파일 손상 수정하기 ZSH 사용 중 다음과 같은 오류 메시지를 보게 될 수 있습니다. zsh: corrupt history file /home/bs/.zsh_history 이 오류는 ZSH 히스토리 파일이 어떤 이유로든 손상되었을 때 발생합니다. 히스토리 파일은 사용자가 쉘에서 실행한 명령어들을 저장하는데, 비정상적인 종료 또는 파일 시스템의 오류 등으로 인해 손상될 수 있습니다. 오류 수정 방법 문제를 해결하기 위해 다음 명령어를 실행합니다: cd ~ mv .zsh_history .zsh_history_bad strings -eS .zsh_history_bad > .zsh_history fc -R .zsh_history 이러한 과정은 손상된 히스토리 파일을 백업하고, 가능한 한 많은 유효한 명령어들을 복구하여 새 히스토리 파일에 저장합니다. 자동화 스크립트 위 과정을 매번 수동으로 실행하기는 번거롭기 때문에, 다음 스크립트를 작성하여 자동화할 수 있습니다. $PATH 환경 변수에 설정된 경로 중 하나에 스크립트 파일을 생성합니다. 예를 들어, /usr/local/bin 경로에 스크립트를 만들 수 있습니다. sudo vi /usr/local/bin/zsh_history_fix_corrupt 스크립트 파일에 다음 내용을 입력하고 저장합니다: #!/usr/bin/zsh # Fix corrupt zsh history file echo "Attempting to fix corrupt .zsh_history..." if [ -f ~/.zsh_history ]; then mv ~/.zsh_history ~/.zsh_history_bad strings -eS ~/.zsh_history_bad > ~/.zsh_history fc -R ~/.zsh_history echo "Your ZSH history has been recovered. Please veri

현대 소프트웨어 개발에서 객체 지향 설계(Object-Oriented Design, OOD) 및 리팩토링 은 필수적인 요소입니다. 소프트웨어는 끊임없이 변화하고 성장하는 생명체와 같으며, 이러한 환경에서 효과적인 코드 관리와 유지 보수는 프로젝트의 성패를 좌우합니다. OOD는 코드를 더욱 모듈화하고, 유연하며, 재사용 가능하게 만듭니다. 반면, 리팩토링은 기존의 코드를 개선하여 더욱 깔끔하고 효율적으로 만드는 과정입니다. 하지만 리팩토링은 모든 기능을 다시 테스트해야 하는 어려움이 있습니다. 이때 자동화된 테스트의 역할이 중요해집니다. 자동화된 테스트의 중요성 자동화된 테스트는 리팩토링 과정에서 코드의 안정성을 보장하는 핵심 요소입니다. 이는 코드 변경 시 발생할 수 있는 오류를 빠르게 감지하고, 수정을 쉽게 만들어 줍니다. 특히, Test-Driven Development (TDD) 방법론은 개발 과정에서 테스트를 먼저 작성하고, 이를 기반으로 코드를 개발하는 방식으로 리팩토링을 지원합니다. 이 글에서는 OOD와 리팩토링의 중요성, 자동화된 테스트의 역할, 그리고 TDD의 장단점에 대해 자세히 살펴보겠습니다. 객체 지향 설계 (OOD)의 중요성 모듈성 : OOD는 시스템을 독립적인 객체들로 나눕니다. 이 객체들은 각각의 기능을 가지며 서로 상호작용합니다. 이로 인해 코드의 모듈성이 증가하고, 변경이 필요할 때 특정 부분만 수정하면 되므로 전체 시스템에 미치는 영향을 최소화할 수 있습니다. 재사용성 : 객체 지향 설계는 코드의 재사용을 촉진합니다. 잘 설계된 객체는 다른 프로젝트나 시스템에서도 쉽게 재사용될 수 있습니다. 확장성 : 객체 지향적 접근은 시스템을 확장하기 쉽게 만듭니다. 새로운 기능이 필요할 때, 기존의 객체에 기능을 추가하거나 새로운 객체를 시스템에 통합하기가 용이합니다. 유지보수 용이성 : OOD는 코드의 유지 보수를 용이하게 합니다. 객체 간의 느슨한 결합(loose coupling)은 시스템의 한 부분을