JPQL (Java Persistence Query Language)은 Entity 객체를 대상으로 쿼리를 작성하는 객체 지향 SQL이다.사용하는 이유객체 중심 개발에 자연스럽게 녹아들 수 있음JPQL은 SQL이 아닌, 객체(Entity) 를 대상으로 작성함테이블/컬럼

봄버맨은 크기가 R×C인 직사각형 격자판 위에서 살고 있다. 격자의 각 칸은 비어있거나 폭탄이 들어있다.폭탄이 있는 칸은 3초가 지난 후에 폭발하고, 폭탄이 폭발한 이후에는 폭탄이 있던 칸이 파괴되어 빈 칸이 되며, 인접한 네 칸도 함께 파괴된다. 즉, 폭탄이 있던 칸

문제 14016번 춘향이는 편의점 카운터에서 일한다. 손님이 2원짜리와 5원짜리로만 거스름돈을 달라고 한다. 2원짜리 동전과 5원짜리 동전은 무한정 많이 가지고 있다. 동전의 개수가 최소가 되도록 거슬러 주어야 한다. 거스름돈이 n인 경우, 최소 동전의 개수가 몇 개

ArgumentResolver등록이 안되는 문제 발생코드오류 코드를 봤을 때 resolver.add(A) A에 들어가는 값이 null 값처리가 된다는 문구를 확인하였고 resolver는 아무 문제가 없었다.한참을 씨름을 하다가 Webconfig 클래스에 @Configu

Admin API의 응답값이 void라서 로깅 시 Request/Response Body가 모두 null로 찍히는 문제PATCH /admin/users/{id}DELETE /admin/comments/{id}void 자체가 잘못된 것은 아니지만 운영 환경 로깅을 생각하

모든 요청에 대해 로그를 남기고 싶다로그인된 사용자만 특정 요청을 허용하고 싶다요청이 들어올 때마다 요청 시간을 측정하고 싶다특정 서비스 로직 실행 전후로 공통적인 검증이나 처리를 하고 싶다다만 이 로직들을 모든 코드에 작성하게 된다면 가독성도 떨어지고 보수하기 굉장히

앞에 필터와 JWT를 사용하여 인증/인가를 구현해보았고 기본적인 개념들을 정리해보도록 하자.또한 오늘 과제를 하면서 알게된 점을 정리해봅시다.@EntityGraph(attributePaths = "user") 기존에 사용했던 방식은 user에 {}가 없었지만, 강의에는

앞으로 과제 하기 전 숙지해둬야할 개념들을 복기 차원에서 정리할 예정이다.필터는 본격적인 스프링 로직이 실행되기 전에 사용자의 요청을 한번 걸러주는 역할을 한다.직접 구현할 필요 없이 많이 사용되는 목적에 따라 이미 구현이 되어 있고 우리는 이중에 하나를 선택해서 사용

팀 프로젝트는 저번 주에 끝났지만 밤샘 작업으로 인해 TIL을 작성하지 못했다. 하지만 그냥 넘기기에는 느낀 것들이 많아 기록하려고 늦게나마 작성해보려고 한다.컨벤션 정리GitHub 정리코드 스타일 정리파일 구조화 통일네이밍 구조 통일공통으로 사용할 클래스 구성 정리머

오늘 하루는 전날 머지 이후 계속되는 리팩터링과 기능 추가로 꽤 긴 코딩 시간을 보냈다. 약 13시간 동안 집중하면서 여러 트러블 슈팅과 학습 포인트가 있었다. 전날 머지를 마치고 각자 리팩터링을 진행했는데, 작업 중간마다 “이거 있으면 좋겠다”라는 의견이 계속 나와

오늘은 저번 주에 마친 각자 API대로 적용을 시켜보려고한다.다만 도메인별 작업을 진행할 때 연관관계로 인해 특정 도메인이 없으면 테스트를 할 수 없는 상황을 생각하지 못했다. 여러 도메인 별로 동시 작업을 하기 위해서는 어떻게 해야될까?기본적인 CRUD 틀만 필요할정

처음으로 여태껏 배운 스택들을 활용하여 팀원들과 함께 프로젝트를 만들게 되었다.확실히 프로젝트만 봤을 때 혼자서 한다고 생각하면 꽤나 걸릴 것 같아보였던 프로젝트였으나, 토의하고 역할분담을 하니 각자 도메인을 하나씩 맡게 되었다.팀원들과 어떤 것을 만들지 공유 하기 위

기존 과제에 기능들이 추가됨에 따라 어려웠던 점들과 궁금했던 점들 위주로 작성하였습니다.기본적으로 연관관계 매핑이 들어감에 따라 서비스계층에서 데이터를 끌고오는 과정이 꽤나 어려웠고, 수정해야될 소요가 꽤나 있어서 난이도가 있었습니다.마지막으로 N+1이라는 문제가 어떠

여태 짠 코드들을 다시 리뷰해보면서 리팩터링하는 시간을 가질려고 하였다.기본적으로 비밀번호 암호화를 하면서 유저의 U/D 기능에만 적용을 시켰는데, 일정과 댓글에도 적용을 시키기로 하였다. 기존에 생성되어 있기에 서비스와 컨트롤러에 수정만 해주면 될 것 같다.삭제 코드

오늘은 페이징 조회라는 것을 다뤄볼 예정이다. 마지막 요구사항인데 일단 페이징 조회가 무엇인지부터 알아봐야겠다.데이터들을 페이지 단위로 쪼개서 보여줄 수 있게 해주는 전략 이라고 볼 수 있다.데이터베이스의 레코드를 개수로 나눠 페이지를 구분하는 것댓글이 2개, 10개일

암호화 하기 예외처리에서 중요하다고 생각하는 부분은 기존의 사용자가 설정한 비밀번호를 암호화 하는 것이라고 생각한다. 일단 전혀 지식이 없기에 구글링을 먼저 해보았다. Spring Boot에 암호화 하는 방법은 꽤나 있었고, 그 중 요구사항에 따라 먼저 직접 적용

숫자 카드는 정수 하나가 적혀져 있는 카드이다. 상근이는 숫자 카드 N개를 가지고 있다. 정수 M개가 주어졌을 때, 이 수가 적혀있는 숫자 카드를 상근이가 가지고 있는지 아닌지를 구하는 프로그램을 작성하시오.첫째 줄에 상근이가 가지고 있는 숫자 카드의 개수 N(1 ≤

어제 예외처리를 일부로 throw IllegarArgument를 통해 전부 처리를 해주었다. 바로 오늘 전역예외처리 를 진행하려고 하기에 여태껏 예외를 발견하고 처리하는 것을 해왔다고 볼 수 있다.저번에 도전기능과제에 커스텀예외클래스와 전역예외처리 클래스를 통해 예외처

오늘은 기존에 만든 로그인 기능을 통해 검증 및 권한 로직을 추가할 예정이었다. 로그인 기능을 만들고 나니 생각이 든 부분이 코드가 남들에 비해 굉장히 길었다는 것이다.비교를 해보니 내가 작성한 코드는 세션에 대한 직접적인 접근이었고, 다른분들은 @SessionAttr

어제 일정에 대한 CRUD가 작성이 완료되었기 때문에 오늘은 유저에 대한 CRUD를 작성을 할 것이다.기존 일정 CRUD와 패턴을 똑같기 때문에 만드는데는 큰 지장이 없었다.다만 유저의 필드가 채워지게 되면서 스캐줄에 있는 작성 유저명이 이제 유저 고유의 식별자를 갖게