Today I Learned ...
오늘은 코드카타 SQL 44번 문제와 알고리즘 42-43번 문제를 풀고, 일정관리 앱 Dev 과제의 Lv. 5를 마무리했다!
🗒️ 코드카타 #23
오늘 진행한 SQL 문제는 가격을 1만원대로 끊어서 각 가격대별 물건의 개수를 구하는 것이었다.
처음에는 case when을 사용해볼까 했지만.. 그렇게 되면 거의 8-9개의 경우를 지정해줘야 해서 이 방법은 포기했다.
그 다음에는 round() 함수를 사용했지만..! 생각해보니 round는 반올림을 하는 것이었고, 그래서 계속 계산 결과가 이상하게 나왔었다.
round는 반올림을 할 자릿수를 정할 수 있어서 편하게 사용할 수 있었지만, 내림을 해주는 floor()는 소수점 아래를 버리는 것밖에 하지 못했다.
그래서 결국 원래 금액을 10,000으로 나눠서 floor에 적용시키고, 다시 10,000을 곱하는 방식으로 각 가격대를 나눌 수 있었다.
빨리 SQL의 이런 저런 명령어들을 정리해봐야겠다,,
오늘도 원래 계획은 3개의 알고리즘 문제를 푸는 것이었지만... 마지막 3번째 문제는 결국 해결하지 못하고 끝내게 되었다.
먼저, 오늘 푼 첫번째 문제는 정수 배열에서 3개의 숫자를 뽑은 후 더했을 때 0이 되는 경우의 수를 구하는 것이었다.
3개의 숫자를 뽑아 더하는 것까지는 문제가 되지 않았는데, '경우의 수'임을 망각하고 있었다..
1번째, 2번째, 3번째 수를 더한 것과 2번째, 3번째, 1번째 수를 더한 것은 같은 경우로 쳐야 하는데, 처음엔 이걸 모두 다른 경우로 계산했었다.
나는 이 3개가 같을 수 있는 경우인 6을 최종 결과에서 나누는 방식으로 진행했는데,
다른 사람들의 풀이를 보니 for문에 초기값을 i, i+1, i+2로 잡아 진행하면 굳이 6으로 나눌 필요 없이 계산할 수 있었다....
수학..을 조금 더 공부하자...
그리고 오늘 푼 두번째 문제는 두 숫자를 입력받고, 두번째 숫자의 자릿수대로 첫번째 숫자를 자르고, 잘린 숫자가 2번째 숫자보다 작거나 같은 경우를 구하는 것이었다.
예를 들어, '123456'과 '32'를 입력받았다면, 먼저 '123456'을 '12', '23', '34', '45', '56'으로 자르고, 이 중에 '32'보다 작거나 같은 수가 2개 있으니 2를 반환하면 되는 것이다.
처음부터 숫자를 String 형태로 받았기 때문에, 이전에 문제를 풀 때 사용했던 String.substring()을 사용하면 쉽게 해결할 수 있었다.
for문을 활용해 인덱스 0에서부터, 1에서부터, 2에서부터 끊어갈 수 있도록 했는데, 이때 for문의 조건식에 등호를 빼먹기도 하고,
2번째 숫자와 비교할 때 작거나 '같은' 수를 찾아야 하는데, 그냥 작은 수만 찾아서 실패하기도 했다.
요즘 문제를 푸는 방식이 틀렸다기 보다는 조건들을 빼먹어서 틀리는 경우가 많은데,, 천천히 꼼꼼하게 보면서 문제를 풀어야겠다.
각각의 문제와 풀이는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🖥️ 일정관리 앱 Dev 프로젝트 #5
오늘 드디어 일정관리 앱 Dev 프로젝트의 Lv.5를 마무리했다!!
사실 남아있는 Lv.5의 내용이 Validation을 활용해 입력값에 제한을 두고, 예외 처리를 하는 것 뿐이었기에 당연히 빨리 끝내고 Lv.6도 시작을 할 수 있을 줄 알았다...
그런데,,, Validation을 이상하게 기억을 하고 있었고... 그러니 이상하게 작성을 했고... 그러니 말도 안되는 에러를 만나서 트러블 슈팅을 하겠다고 2시간을 구글링만 하고 있었다...
그래도 이 시간을 통해 새로운걸 하나 배웠으니, 좋다 생각해야겠다..
Validation을 통해서는 Controller 단계에서 사용자의 입력을 검증할 수 있는데,
예를 들어 필수값을 입력했는지, 이메일이라면 이메일 형식에 맞게 입력을 했는지, 제한된 길이를 초과하지 않았는지 등등을 확인할 수 있다.
이때 중요한 것은 Controller 단계에서 한다는 것인데!!
나는 이걸.. Entity에 적용을 하고 있었다...
그러니 아무리 API의 메서드에서 @Valid 어노테이션을 붙여도 얘가 제대로 검사를 할 수가 없고,
그러니 Valid가 잘 작동되는지 확인하기 위해 필수값을 null로 입력했을 때 원래 나와야 하는 MethodArgumentNotValidException 예외가 아니라
ConstraintViolationException 예외가 터지고 있었다.
구글링하며 찾아본 내용을 정리를 하자면,, 두 예외 모두 Valid가 실행되었을 때 발생하는 것이기는 하나
MethodArgumentNotValidException은 Valid를 DTO에 걸었을 때 발생하는 예외이고,
ConstraintViolationException은 Valid를 기본 자료형에 걸었을 때 발생하는 예외이다.
내가 DTO에 어노테이션을 걸어두지 않고 Valid를 사용했으니,, 결국 ConstraintViolationException 예외가 발생할 수밖에 없었던 것이었다...
정말... 컬럼에 nullable, length 등등을 걸때 엔티티에 작성하니 당연히 이것도 엔티티에 작성해야 한다고 생각했지만...
DTO에 작성하는 거였다는 사실...
앞으로 강의 똑바로 듣자...
그래도 이걸 해결하고 나니 Validation 적용은 큰 문제 없이 해결할 수 있었다!
다음주부터는 Lv.6의 비밀번호 암호화를 시작해봐야겠다.
내가 작성한 코드는 깃허브에 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
요즘 정말 많이 놀고, 정말 조금 공부하고 있는데..ㅎㅎㅎ
다음주부터는 진짜 집중해서 과제 빨리 끝내야겠다...
