들어가며 처음 프론트와 협업을 해보면서 지금껏 마주보지 못했던 수많은 에러를 마주했다. 그 중 하나가 계속 과제에서 강조했던 CORS 정책 위반이었는데, 처리를 해두었다고 생각했음에도 같은 에러가 났다. 그러므로 오늘의 TIL은 CORS에 대해 알아보고 이를 어떻게 잡을 지 알아보고, 오늘 만난 에러에 대한 트러블 슈팅 또한 해보고자 한다. CORS(Cross-Origin Resource Sharing) 교차 출처 리소스 공유(CORS, Corss-Origin Resource Sharing)는 일반적으로 개발을 배우기 시작하는 단계쯔음 클라이언트 - 서버 간의 통신을 시도할 때, CORS 정책 위반 에러로 처음 접하게 된다고 한다. 이 CORS는 무엇이고 뭐 때문에 우리에게 에러를 던져줄까? CORS는 ..
들어가며 과제 제출을 위해 Readme.md를 작성해야할 일이 생겼다. 깃허브 Readme는 기본적으로 마크다운 문법을 사용하기 때문에 깔끔한 Readme를 위해서는 이 문법을 대강이라도 숙지하고 있어야한다. Notion도 기본적으로는 마크다운 문법을 사용하고 있고, 여러모로 쓸 일이 많은 문법인데 헷갈릴 때마다 구글링하기 번거로우므로 오늘의 TIL은 깃허브 Readme 작성을 위한 마크다운 문법을 간단하게 정리해보고자 한다! 마크다운 문법 제목 # 제목1 ## 제목2 ### 제목3 #### 제목4 ##### 제목5 ###### 제목6 제목1(#)과 제목2(##)은 Header로 취급되기 때문에 수평선이 자동으로 생긴다. 인용 > 인용1 >> 인용2 >>> 인용3 목록 숫자 목록 1. 숫자 목록 2. 숫..
들어가며 2주차 과제를 제출하기 위해 Readme를 작성하면서 여러가지 개념들을 간단하게 정리하는 시간이 있었다. 항해99 e반 공식 TIL 망령으로서 대충 정리한 내용을 블로그에 올리고 싶지 않았지만 조금씩 내려놓지 않으면 이도저도 안될 것 같으므로 오늘의 TIL은 여러가지 정리한 내용들을 종합해서 작성해보고자 한다. 프레임워크와 라이브러리의 차이점 프레임워크와 라이브러리의 차이점은 막연하게 알고 있었지만 막상 설명해보라고 한다면 명확하게 대답하기가 어렵다. 둘다 개발자가 필요한 기능들을 사용하기 편하게 구현해둔 집합체이지만 그 차이점은 존재한다. 둘의 차이점을 알기 위해서는 라이브러리와 프레임워크의 개념을 먼저 알고 있어야한다. 라이브러리(Library) 라이브러리는 단순 활용이 가능한 도구들의 집합..
들어가며 응급실 다녀오느라 과제 제출을 제 시간에 못했다. 내 몸뚱아리는 왜 이렇게 나약한지,, 급하게 과제 마무리를 하고 있는데 다행히 과제 제출 기한이 많이 미뤄졌다! 미처 추가하지 못한 부분들을 깔끔하게 추가할 시간이 생겼다. 코드 리팩토링이랑 살짝 내려놓았던 부분들을 다시 매꿔서 제출해야겠다고 다짐하며 오늘의 TIL은 오늘 적용한 여러가지 기능들을 정리해보고자 한다. application.yml에 있는 민감 정보 .gitignore에 포함시키기 application.yml은 설정파일로 DB의 URL, username, password가 그대로 노출되어있고, S3의 key 역시도 노출되어있다. 이 정보들이 github에 그대로 올라간다면, 해커한테 내 DB랑 S3 해킹해주세요~ 하는 꼴이므로... ..
들어가며 TIL 업로드 하는걸 깜빡해서 15일에 올리는 14일 TIL..!! 오늘의 TIL도 과제를 하면서 겪었던 에러를 트러블 슈팅해보고자 한다! 트러블 슈팅 문제 - DataIntegrityViolationException 에러 could not execute statement; SQL [n/a]; constraint [null]; nested exception is org.hibernate.exception.ConstraintViolationException: could not execute statement not null인 테이블에 null을 집어 넣으려고 해서 나타나는 에러였다. 에러로그에서 바로 힌트를 얻을 수 있는데, 메인 에러 명은 데이터 무결성 위반 예외 이고, 뒤쪽에 적힌 에러명은 제..
들어가며 시도하기 막막했던 부분을 구글링해서 나온 코드로 해결했더니 속 시원하면서도 완전히 이해하고 쓰는게 아니라는 생각에 답답하기도 한 하루였다. 아직 할게 많이 남았지만 긴 시간동안 몰입해서 과제를 했으므로 만족. 집중력이 떨어진 김에 남은 시간은 TIL과 미뤄뒀던 공부 주제들을 포스팅하는 데에 사용하기로 했다. 오늘의 TIL은 과제를 하면서 겪었던 문제들에 대한 트러블 슈팅을 해보고자 한다. 트러블 슈팅 문제 - Timestamp Format 변경하기 결론만 보고 싶다면 세번째 시도를 봐주세요! 유저 정보를 User Entity가 아니라 UserResponseDto에 매핑해서 넘겨주는 방식을 사용하고 있는데, 내가 원하는 포맷인 "yy/MM/dd HH:mm:SS" 포맷이 아니라 기본 포맷으로 반환해..
들어가며 @Valid 어노테이션으로 유효성 검사를 해주고 예외 처리를 해주지 않으면 사진과 같이 에러 로그가 그대로 노출되어버린다. 이렇게 되면 클라이언트 입장에서 유용한 정보를 주기도 어렵고, trace에서 운영환경에서의 구현이 노출되기 때문에 해커의 위협에서 벗어나기 어렵다. 따라서 적절하게 예외 처리를 함으로써 에러 응답을 변경해 줄 필요가 있고, 이 예외 처리 방법 중 가장 좋은 방식이 @RestControllerAdivce (혹은 @ControllerAdvice)어노테이션과 @ExceptionHandler를 함께 사용하는 방식이라고 한다. 다양한 예외처리 방법과 @RestControllerAdivce 어노테이션을 사용하는게 가장 좋은 이유는 다음 글을 참고하자. [Spring] Spring의 다..
들어가며 주특기 PBL 1주차와 2주차의 사이에서 써내려가는 WIL. 우당탕탕 항해99를 시작한 지도 벌써 한 달이 넘어갔다. 스파르타 코딩클럽이라는 이름에 걸맞게 '진짜' 스파르타인 커리큘럼을 얕보고 시작한게 아닌가 하는 후회와 지금까지 이정도로 무언가를 위해 열심히 공부해본 적이 있었나 하는 지난 날에 대한 반성이 물밀듯이 밀려왔다. 많은 생각을 안고 달린 이번 주의 WIL은 항해99에서 제시해준 키워드인 '주특기 PBL 1주차 과제를 하면서 느꼈던 것들'에 대한 회고록을 작성해보고자 한다. 회고록 이라고 썼지만 지난 한 주간의 일기 주특기 PBL 1주차 시작 주특기 1주차에서는 기존에 배웠던 영속성 프레임워크인 MyBatis가 아닌 JPA를 활용하여 개발하는 방식을 처음 배우고 사용해보았다. 언제나..
문제상황 소스트리가 계속해서 튕기는 현상이 나타났다. 전에는 간헐적으로 나타나더니 이번에는 아주 틈만 나면 예기치 못하게 종료되기 시작했다. 소스트리의 예기치 못하게 종료되는 이슈를 해결해보자. 해결과정 해결방법에는 두가지가 있다. 첫번째는 소스트리의 설정을 바꿔주는 방법이다. 1. 소스트리 설정 변경 방식 1) 소스트리 전역 사용자 설정 체크 해제 단축키 - (mac) command + , 해당 창에서 표시되어있는 부분 체크 해제 2) 저장소 창에서 설정 → 고급 → 전역 사용자 설정 사용 체크 해제 이러면 높은 확률로 예기치 않게 종료되는 이슈를 해결할 수 있다. 많은 사람들이 겪고 있는 문제같은데 정확한 원인은 파악된게 없고 다들 추측으로만 이렇다더라 하고 있는 듯하다. 무언가의 충돌 때문인거 같은..
들어가며 처음 써보는 Spring Security와 JWT가 너무 어렵다... 막상 정리하려니 되게 막막하므로 오늘의 TIL은 2주차 과제를 하면서 발생한 에러들에 대한 트러블 슈팅을 해보고자 한다. Lombok으로 생성자 주입하기 의존성 주입을 해주는 방법은 크게 3가지가 존재한다. 생성자 주입 필드 주입 수정자(setter) 주입 이 중 가장 권장되는 방식은 생성자 주입이라고 한다. 생성자는 객체를 생성할 때 한 번만 호출되므로 불변하다는 특징을 갖게되고, 그러므로 final 키워드를 사용할 수 있게 되기 때문이다. 이런 생성자의 특징을 이용하면 Lombok의 @RequiredArgsConstructor로 간단하게 생성자 주입을 구현할 수 있다. @RequiredArgsConstructor는 fina..
