작성계기 제가 지금 하고있는 프로젝트에서는 메시지를 보내고 비동기로 관리하기위해 RabbitMQ를 사용하고 있습니다. 그런데 RabbitMQ는 말로만 들어봤지 실제로 어떻게 동작을 하는지 그리고 이걸 왜 그렇게 많은 기업에서 요구하는지 알고 싶었습니다. 그래서 Rabb

작성 계기는 이직한 회사에 입사한 지 얼마 안 된 무렵이었습니다. 저희 회사는 CI/CD를 젠킨스로 운영하는데 기존에는 배포할 때 새롭게 반영이 되었는지 확인이 안 되는 문제와 기존 이미지가 업데이트되면 만일의 비상 상황에 이전 버전으로 롤백시킬 수도 없다는 단점이 있

지난 1년동안 취업까지 정말 보람차면서 힘든시간을 보냈습니다.뭐 결론적으로 취업은 했지만 그동안 정말 많은 고난들이 있었습니다. 이것들을 장문으로 적기에는 너무 길어서 간략하게 나열하면서 그동안 1년동안 무엇을 했고 어떻게 힘들었는지 정리를 해보고자 이렇게 간만에 (거

S3 CannedAccessControlList 권한 종류 Amazon S3의 CannedAccessControlList(Canned ACL)는 버킷이나 객체에 대해 미리 정의된 권한을 설정할 수 있는 간단한 방식입니다. 각 Canned ACL의 권한은 다음과 같습니

작성계기 사이드 프로젝트를 진행하던중 이미지 업로드기능이 필요했고 그래서 초기에는 로컬PC에 이미지를 저장하는 방법을 썼고 브라우저에서 로컬PC로 파일을 저장하는 것 까지는 성공 했지만 로컬PC에 저장된 이미지를 브라우저에 출력하는 것은 성공하지 못했습니다. 그러던

일단 크게 2가지 이유가 있다. 최근에 과제테스트를 하면서 Docker 파일을 만들고 Docker 파일만으로 프로젝트를 실행하라는 과제를 받았다. 과제를 무사히 수행했지만 부족한 부분이 있었고 어떻게 보면 이유가 가장 컸다. 최근에 만든 서비스인 JPBoard 서비스를

서론 지난번 VSCode 게시글을 작성하고 오랜만에 작성하는 글입니다. 올 해 시작하고 지금까지 정신없이 바빴던거 같습니다, 현재는 회사를 그만두고 지금 열심히 구직활동을 하고있지만 연이은 실패에 스트레스로 응급실에 갈 정도로 심하기도 했습니다, 하지만 그럴때 마다

프로젝트를 진행하는 과정에서 재부팅을 많이 해야하는 상황이 왔었다, 그래서인지는 몰라도 메모리를 많이 사용하게 되었다. 결과적으로 Gradle을 이용한 clean 및 Build가 되지 않았다, 결론부터 말하자면 메모리 부족으로 일어난 현상이었는데 나중을 대비해 이렇게

시작한 계기 사이드 프로젝트를 진행하면서 동시성 문제 때문에 Redis를 사용하기로 결정했는데 Redis는 메모리기반 데이터베이스라는 것만 알았지 어떻게 사용하는건지 전혀 모르는 상태였다. 하지만 뭐든지 시작이 반이라고 Redis를 사용하는 방법을 찾아보니 직접 설치하

Spring Data JPA, QueryDSL, EntityManager를 쓰면서 실수 한 것들도 있었고 이거는 좀 괜찮은데? 라고 생각한 것들도 있었다, 실수를 줄이고 팁들을 공유하기위해 작성하기로 했다.프로젝트를 진행하다가 기본적인 CRUD를 작성하자니 생산성이 떨

작성계기 작성 계기는 내가 면접을 봤을 때로 돌아가야 한다. 면접 때 자바 11과 17의 차이점에 대해 말해보라는 질문을 받았는데 그때 솔직히 잘 모르기도 했고 당황해서 대답을 못 했던 기억이 난다. 그래서 알아봤는데 괜히 11과 17을 비교하는 것이 아니었다. 간략하

데이터베이스 Key 데이터베이스에서 각 ROW를 구분하는 유일한 식별자를 의미한다, 일반적으로 키는 테이블에서 하나 이상의 열로 값은 유일하고 불변해야한다. 키는 데이터 정합성, 검색, 수정, 삭제등의 작업에서 중요한 역할을 한다. > 데이터 정합성 : 데이터가 올바

정규화(Normalization) 정규화라는 단어는 정보처리관련 자격증을 준비했거나 DB설계를 한번이라고 해봤다면 들어봤을 법한 이론이다. 간단히 이야기하면 테이블간에 중복을 허용하지 않는다는 의미이다. 그리고 정규화를 통해 데이터의 무결성을 유지하면서 DB용량을 줄일

작성계기 JPA를 공부했다면 잘알지는 못해도 반드시 본다고 해도 과언이 아닌 이다. 하지만 내가 아는 트랜잭션은 데이터베이스상의 하나의 작업단위정도로만 알고 있었다. 하지만 조사해본 결과 트랜잭션은 내가아는 것 이상으로 복잡한 기능을 가지고 있다. 그렇기에 트랜잭션의

회사 프로젝트 혹은 개인 프로젝트를 진행할 때 Controller든 Service든 반드시 한다고 해도 과언이 아닌게 의존성 주입이라고 생각한다. 의존성 주입은 사람들마다 말이 다른데 나는 일단 Spring Boot로 프로젝트를 개발하는 사람으로써 의존성 주입에 대해서

말하자면 HTTP란 웹 환경에서 데이터를 주고 받기 위한 프로토콜로 이미 지식은 알고 있지만 개인적으로 본인이 잘알고 있다고 평소에 생각하고 있다면 다시한번 확인하여 본인이 정말로 잘알고 있는지 확인하는 작업을 거친다, 그런의미에서 웹에서 가장 기본적인 지식중에 하나인

나는 Spring Boot를 주로 사용하면서 IoC 컨테이너와 DI 컨테이너에 대해 정리하지 않았다는 사실을 알았는데 IoC와 DI는 스프링계열 프레임워크에서는 정말 중요한 내용이기에 이번에 정리를 해보고자 작성하게 되었다.IoC는 제어반전이라는 의미로 객체의 생성,

사이드 프로젝트를 진행하는데 갑자기 문득 그런 생각이 들었다. 내가 만든 프로젝트를 AWS 아니면 개인 서버를 구축하여 실행시키는 등 다양한 방법으로 운영하게 될 텐데 문제는 운영환경마다 properties 파일의 내용은 전부 다르고 매번 배포할 때마다 하나하나 값을

JPA를 사용했다면 무조건 Entity 객체를 만들어봤을 것이다. 그런데 Entity객체를 생성하는데 주의사항이 존재했다. 나 또한 예전에는 내가 사용한 방식이 문제점인지 모르고 사용했었는데 지금은 하나하나 주의하면서 생성하고 있다. 그런 의미에서 Entity객체를 생

2차 캐시란 2차 캐시는 JPA에 있는 기능중에 하나로 간단히 이야기하면 중복되는 요청이 들어올 시 최초에 들어온 요청은 영속성 컨텍스트에 있는 쿼리문을 실제 DB Table에 실행시켜 값을 가져오지만 2차 캐시를 사용하면 최초의 요청은 DB를 직접 조회하고 똑같은 요