Today I Learned ...
오늘은 코드카타 SQL 26번 문제와 알고리즘 24, 25번 문제를 풀고, 일정관리 앱 프로젝트를 시작했다!
🗒️ 코드카타 #15
오늘 진행한 SQL 문제는 group by를 활용해 시간대별 데이터의 개수를 구하는 문제였다.
제공받은 데이터에는 날짜와 시, 분, 초가 모두 들어있었는데, 여기에서 시간만 가져와야 했다.
시간만 가져올 때는 2가지 방법을 사용할 수 있었는데,
첫 번째 방법은 date_format([컬럼명], '%H')를 통한 것이었고, 이 방법을 사용한다면 h로는 12시 형태로, H로는 24시 형태로 출력할 수 있다.
두 번째 방법은 hour([컬럼명])을 활용하여 시간만 가져오는 것이다.
오늘은 총 2개의 알고리즘 문제를 풀었는데,
첫 번째 문제는 입력받은 String 배열에서 특정 값이 있는 인덱스를 찾아 반환하는 것이다.
처음에는 String 배열을 그대로 스트림을 활용해 필터링했는데, 그러니 해당 인덱스를 찾을 수가 없었다.
그래서 IntStream을 사용해 인덱스의 범위를 지정하고, 그 안에서 해당 값이 있는 인덱스를 필터링해주었다.
이렇게 어찌저찌 문제는 잘 풀었지만, 다른 사람들의 풀이를 보니 Arrays.asList().indexOf()로 배열을 리스트로 바꾸고, 그 리스트에서 바로 특정 값이 있는 인덱스를 찾을 수 있었다.
indexOf()라는 메서드가 있는지 처음 알았다...
이런저런 문제를 풀어보며 여러 메서드들을 익혀야겠다.
오늘 푼 두 번째 문제는 숫자 배열과 특정 숫자를 입력받아 배열 속 숫자 중 특정 숫자로 나누어떨어지는 수들을 다시 배열로 반환하는 것이다.
for문을 활용해 나누어떨어지는 수들을 리스트로 만들었고, 그 리스트를 스트림으로 받아 오름차순으로 정렬해서 배열로 반환하였다.
이렇게 큰 어려움 없이 풀 수 있었는데, 다른 사람들의 풀이를 보니 처음부터 배열을 스트림으로 받아 필터링을 걸면 되는 것이었다...
해결만 된다고 끝내지 말고 더 간결하게 쓸 수 있도록 생각해봐야겠다.
각각의 문제와 풀이는 깃허브를 통해 업로드해두었다.
GitHub 보러가기
🖥️ 일정관리 앱 프로젝트 #1
오늘부터 스프링을 활용한 일정관리 앱 프로젝트를 시작했다!
일정관리 앱 프로젝트는 필수 구현으로는 API 명세서와 ERD를 작성하고, 일정을 생성하고, 조회하고, 수정하고, 삭제하는 CRUD를 구현해야 한다.
도전 과제로는 댓글을 생성하고, 일정과 댓글을 함께 조회하고, 유저의 입력에 대한 검증을 수행하는 기능을 추가해야 한다.
오늘은 일정관리 앱 프로젝트의 필수 구현 부분을 진행했다.
강의에서 진행한 실습과 거의 비슷한 내용이라 큰 어려움 없이 진행할 수 있었는데, 끝내 하나의 트러블을 해결하지 못하고 끝냈다.
과제를 진행하면서 여러 문제들이 있었다.
먼저는 BaseEntity를 만들 때, 생성일과 작성일에 Nullable을 어떻게 설정할 것인가에 대한 내용이었다.
그런데, 생성일에 붙이는 @CreatedDate 어노테이션과 작성일에 붙이는 @LastModifiedDate 어노테이션에 이미 nullable을 false로 만드는 내용이 포함되어 있다고 한다.
그래서 이에 대해서는 쉽게 해결할 수 있었다.
두 번째로는 전체 일정 조회 부분에 아쉬운 점이 있다.
전체 일정 조회를 할 때 작성자명을 기준으로 조회할 수도 있고, 작성자명을 받지 않고 전체를 조회할 수도 있다.
여기에 대해 Controller에서는 @RequestParam으로 해결할 수 있었는데,
Service에서는 데이터를 받았을 때와 데이터를 받지 않았을 때를 if문으로 나누어서 구현해야 했다.
그러다보니 코드가 너무 복잡해졌는데, 스트림을 활용하면 이를 더 쉽게 해결할 수 있을 것 같기도 하다.
이 부분에 대해서는 나중에 다시 시도해보려고 한다.
세 번째는 PUT으로 update를 실행한 뒤에 DB에는 modifiedAt이 제대로 저장되어 있지만, 반환되는 결과에는 이전에 저장된 값이 반환되고 있었다.
아직 왜 이렇게 작동되는 것인지 모르겠지만...
modifierAt에 대한 setter를 생성하고, update 실행 후 setter로 직접 시간을 변경해주면서 해결할 수 있었다.
이게 왜 이렇게 작동되는 것인지에 대해서는 조금 더 찾아봐야겠다.
마지막 문제는 아직 해결하지 못했는데... @RequestParam에 Long으로 내용을 받을 때 500 에러가 나온다는 것이다.
String으로 지정해 진행하면 아무런 문제 없이 진행이 되었는데, 이걸 Long으로만 바꾸면 인식을 하지 못한다...
구글링으로 이런저런 글을 찾아봤을 때, RequestParam에 이름을 지정해주지 않았거나 필수값이 없거나 하는 등의 문제로 인한 것이라고 하지만,
그 모든 내용들을 적용해서 다시 시도해봐도 전혀 해결되지 않고 있다.
이건.. 내일 다시 시도해봐야겠다.
사실 마지막 문제는 String으로 하면 아무런 문제가 없어서 계속 이걸 해결해야 할까 고민이 되지만...
그래도 뭐가 문제인 것인지는 알고 넘어가보려고 한다.
내가 작성한 코드는 깃허브에 업로드해두었다.
GitHub 보러가기
🙃 오늘의 느낀점
사실 어제 강의를 들으면서 같은 내용의 실습을 4번이나 진행했기 때문에,
오늘 진행한 필수 구현의 내용들은 어제의 실습에서 이런저런 기능을 조금 추가한 것 뿐이었다.
처음에는 어찌저찌 할만 했지만.. 계속 이런 저런 오류들이 나오고 있어서 이걸 도대체 어떻게 해결해야하나 싶다.
일단 계속 검색해봐야겠다...
