Today I Learned ...
오늘은 코드카타 SQL과 알고리즘 38-40번 문제를 풀고, 일정관리 앱 Dev 과제의 Lv. 4를 진행했다!
🗒️ 코드카타 #21
오늘 진행한 SQL 문제들은 join을 활용해 두개의 테이블을 연관짓고, where in을 활용해 특정 값을 가진 데이터들을 추리는 것이다.
그 중 한 문제에 case when을 사용하는 문제가 있었는데,
case when [조건식1] then [값1]
when [조건식2] then [값2]
else [조건에 만족하지 않을 경우의 반환값]
end as [생성할 컬럼명]위와 같은 형식으로 case when을 사용할 수 있다.
사실 이것도 사전캠프 때 배웠지만.. 안쓴지가 너무 오래되어 다시 찾아보면서 진행해야 했다.
SQL 기본 문법에도 빨리 익숙해져야겠다..
오늘은 총 3개의 알고리즘 문제를 풀었는데,
첫 번째 문제는 두 수를 입력받아서 해당 수의 길이, 높이를 가진 직사각형 형태로 *을 찍는 것이었다.
이 문제는 중첩 반복문을 사용해서 어렵지 않게 해결할 수 있었다.
두 번째 문제는 두 수를 입력받으면, 두 수의 최대공약수와 최소공배수를 구하는 것이었다.
이전에 약수를 찾는 문제를 풀었었기에 최대공약수를 찾는 것은 어렵지 않게 해결할 수 있었다.
최소공배수를 구하는 데에 고민을 했지만.. 찾아보니 최소공배수를 구하는 공식이 있었다.
바로 '두 수의 곱 / 최대공약수'였는데, 최대공약수를 구해뒀기 때문에 최소공배수로 쉽게 구할 수 있었다.
나는 for문을 사용해 최대공약수를 구했지만, 재귀함수를 사용해서도 최대공약수를 구할 수 있다고 한다.
public int gcd(int a, int b) {
if (a % b == 0) return b;
return gcd(b, a%b);
}이렇게 작성하면 된다고 하는데, 사실 왜 이렇게 작성하게 되는 것인지는 이해하지 못했다..
최대공약수 구하는 방법을 조금 더 찾아봐야겠다..
마지막으로 세 번째 문제는 입력받은 수를 3진법으로 바꾸고, 3진법을 앞뒤로 뒤집어 그 수를 다시 10진법으로 바꾸어 반환하는 것이었다.
사실 10진법을 3진법으로 바꾸는 것은 Integer.toString(원하는 숫자, n진수)로, 3진법에서 10진법으로 바꾸는 것은 Integer.parseInt(원하는 숫자, n진수)로
이미 구현되어 있는 Integer 클래스의 메서드들을 활용해주면 된다.
각각의 문제와 풀이는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🖥️ 일정관리 앱 Dev 프로젝트 #3
오늘은 일정관리 앱 Dev 프로젝트의 Lv.4 구현을 끝내고, Lv.5를 시작했다!
Lv.4의 요구사항은 로그인 기능을 구현하고, 필요한 부분에 알맞은 인증 처리를 해주는 것이었다.
어제 로그인과 로그아웃 API 구현까지는 마쳤기 때문에, 오늘은 각각의 API에 어떤 권한이 필요할지를 생각해보고, 필요에 맞게 수정을 진행했다.
일단 일정의 CRUD 중에서는 생성과 수정, 삭제에만 인증 처리가 필요하다고 생각했다.
처음에는 일정을 생성할 때 작성한 유저명과 로그인한 유저의 유저명이 같은 경우와 같지 않은 경우로 구분하려고 했지만,
유저명은 중복이 가능하기 때문에 유저명으로 확인하지 않고 유저ID로 확인을 해야겠다고 생각했다.
또, 이미 로그인을 했는데 일정을 작성할 때 로그인 된 유저의 이름을 또 작성하는 것은 불필요한 동작이라고 생각했기에
Session에 저장된 유저의 정보를 Service 계층에 전달해줘서 일정의 작성자명이 자동으로 생성될 수 있도록 수정하였다.
일정 수정과 삭제의 경우에는 로그인된 유저의 ID와 일정을 작성한 유저의 ID가 같은 경우에만 수정과 삭제가 가능하도록 수정하였다.
그리고 유저의 CRUD 중에서는 유저의 생성과 삭제에만 인증 처리가 필요하다고 생각했는데,
기존에는 유저명에 대한 수정 API만 존재했었다.
하지만, 유저에게 비밀번호 변경이 필요한 경우도 있을 것이기에 비밀번호 수정 API를 추가로 구현하였다.
유저명의 수정과 삭제의 경우에는 일정 삭제와 동일하게 수정하려는 유저의 ID와 로그인된 유저의 ID를 비교한 후에 처리하도록 수정하였다.
그런데, 비밀번호 변경의 경우에는, 현재 비밀번호를 다시 한번 입력하게 하면서
로그인된 유저와 수정하려는 유저의 ID 일치 외에도 기존에 저장된 비밀번호와 새로 입력한 현재 비밀번호의 일치 여부도 확인하도록 하였다.
이렇게 Lv.4도 큰 어려움 없이 잘 해결할 수 있었다!
Lv.5부터는 도전과제인데, 아직까지는 할 수 있는 수준인 것 같아서 도전과제도 시작해보려고 한다.
Lv.5의 요구사항은 Validation을 활용해 다양한 예외 처리를 적용하는 것이다.
오늘은 Validation 활용에 앞서 Exception Handler를 사용해 예외 처리를 진행했다.
기존에 존재하는 예외들은 400 BAD REQUEST와 설정한 예외의 메시지를 반환하고,
내가 만든 커스텀 예외들은 원하는 HTTP 상태코드와 설정한 예외의 메시지를 반환하도록 했다.
하지만.. 사실 아직 비밀번호를 틀렸을 때밖에 만들지 못했다.
내일 이어서 예외 처리를 진행해서 Lv.5를 마무리지어야겠다.
내가 작성한 코드는 깃허브에 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
세상엔 재미있는게 너무 너무 많다..
빨리 과제를 끝내고 배웠던 것들을 하나씩 다 실험해보고 싶다.
