728x90
CI Troubleshooting1. CI가 무엇인가CI는 Continuous Integration의 줄임말이옵니다.코드를 원격 저장소에 푸시했을 때, GitHub Actions 같은 자동화 도구가 새 환경에서 프로젝트를 받아 빌드와 테스트를 수행하여 문제가 없는지 확인하는 절차이옵니다.이 프로젝트의 CI 설정은 /.github/workflows/ci.yml에 있사옵니다.CI 동작 흐름은 대략 아래와 같사옵니다.GitHub가 새 실행 환경을 준비함저장소 코드를 checkout함Java 17을 설치함blog 디렉터리에서 ./gradlew build를 실행함컴파일, 테스트, 패키징을 순서대로 수행함즉, CI는 제 PC나 폐하 PC의 로컬 환경을 그대로 쓰는 것이 아니라, Git에 올라간 파일만 가지고 깨끗한..
Elastic Beanstalk로 환경 만들고 RDS 붙이고, 환경변수 넣고, 로컬에서 RDS 붙이기까지배포 전체 흐름 + 트러블슈팅이 글은 스프링부트 코드를 이미 만든 상태에서 출발해서,AWS Elastic Beanstalk(EB) 환경을 만들고EB가 생성한 RDS(MySQL)를 붙이고EB 환경변수로 DB·OAuth 설정을 넣고마지막으로 로컬 PC에서 RDS에 직접 접속하기 위해 VPC·보안그룹·인바운드 규칙까지 손보는 과정을처음부터 끝까지 「큰 흐름」으로 정리한 기록이다.중간에 막힐 때마다 던졌던 질문(「이 에러는 네트워크냐 인증이냐?」, 「엔드포인트는 어디서 보냐?」, 「Publicly accessible이 어디 있냐?」)과,그 질문을 통해 원인을 확정하고 고친 내용도 흐름 사이에 그대로 끼워 넣었..
OAuth 로그인 흐름 — 부팅·요청별 호출자/원인/피호출자/내부로직핵심 한 줄:authorizationRequestRepository(...) 는 save를 호출하는 줄이 아니라,"OAuth2 필터가 나중에 save/load/remove 할 때 쓸 저장소 객체를 등록하는 줄" 이고,실제 saveAuthorizationRequest(...) 호출은 Spring Security 내부 필터가 요청 처리 중에 합니다.0) 부팅 시점 (서버 켤 때 1번): "연결(set)"만 한다 — save는 절대 안 불림구분내용트리거(원인)서버 부팅(애플리케이션 시작)호출자Spring Boot / Spring Framework가 @Configuration 스캔 → @Bean 메서드 실행피호출자 & 내부로직WebOAuthSe..
[BOJ 20055] 컨베이어 벨트 위의 로봇 — 외우지 말고 “규칙을 번역”해서 푸는 시뮬레이션이 문제는 아이디어가 어려워서가 아니라, 규칙을 한 단계씩 정확히 재현하지 못해서 틀리는 문제다.결국 해야 할 일은 하나다.상태(belt/robots)를 잡고, 매 단계 규칙을 그대로 실행한다.1) 왜 “시뮬레이션”이라고 바로 결정하는가문제는 매 step마다 아래 순서를 강제한다.벨트 회전로봇 이동로봇 올림내구도 0 개수로 종료최적화를 고민할 게 아니라, 상태 변화가 정확하면 정답이다.2) “왜 belt는 2N이 필요하지?” (회전 때문에)로봇은 위쪽(0~N-1)에서만 의미가 있지만, 벨트는 2N 전체가 원형 회전한다.회전 후 0번 칸은 원래 2N-1번 칸이 올라온다. // 회전 전: [a0 a1 a2 | ..
실제 HTTP 요청 → 서버 내부 레이어 → DB → 응답 반환까지,스프링부트에서 DAO(Repository), Entity, DTO, Service가 어떻게 흘러가는지 실제 코드 흐름은 아래와 같다✔ 전체 구조 (먼저 큰 흐름) [클라이언트] ↓ HTTP 요청 [Controller] ↓ [Service] ↓ [DAO / Repository] ↓ [Entity] ↓ [DB] 그리고 응답은 반대로 올라옵니다.✔ 상황👉 회원 조회 API GET /users/1 1️⃣ 클라이언트 → HTTP 요청예시 (curl)curl http://localhost:8080/users/12️⃣ Controller (HTTP 입구)👉 HTTP 요청 받는 역할@RestController@RequestMappi..
소개웹 개발에서 드롭다운 메뉴를 구현할 때, 마우스 오버(Hover) 상태가 서브 메뉴로 이어지지 못하고 메뉴가 즉시 사라지는 현상은 흔한 오류입니다. 이 문제의 근본 원인은 mouseout 이벤트가 작동하는 방식과 이벤트 핸들러 내부에서 요소를 잘못 참조했기 때문에 발생합니다. 이 글에서는 문제의 원인을 명확히 분석하고, mouseover/mouseout을 사용하면서도 메뉴를 안정적으로 구현하는 방법을 제시합니다.1. 문제의 진짜 원인: mouseout과 event.target 재탐색문제는 mouseover/mouseout 이벤트 자체에 있다기보다는, 이벤트 리스너가 ****에 붙어 있음에도 핸들러 내부에서 **event.target.closest("li")**를 사용하여 요소를 다시 탐색했기 때문에 ..