퍼놀드

231207W 여느날과 같이 오늘도 강의와 함께 아주 RestFull~ 한 API 작성 공부를 하는 도중, 어느 순간 ResponseEntity라는 녀석을 소개받았다. 이후로 한결같이 대면하며 즐거운 나날(ㅎ)을 보내는 도중 문득 이 녀석에 대해 궁금해졌다. 사실 공부하는 도중에 알게 된 녀석이기에 분명 설명도 들었을 터인데, 일단 쓰고, 또 일단 쓰고 …가 반복되다보니 잊어버린 듯 하다. 덩달아 이전에 쓰던 녀석도 가물가물해져 이번 기회에 알아보기로 했다. 일단 ResponseEntity를 알기 전에 API를 작성할 땐 이러했다. @PostMapping("/products") public ProductResponseDto createProduct(@RequestBody ProductRequestDto ..

231127W 오늘도 Spring Boot와 함께하는 싱나는 코딩중, 수정에 관련된 API를 작성하려던 도중이었다. 수정에 관련해 @Put 과 @Patch 가 있는데, 둘은 같은 듯 비슷한 듯 다른 듯 한 녀석들이라고 들었는데 제대로 이해하진 못한 상태였다. @Put은 전체수정, @Patch는 부분수정 이라는 정도? 이전까진 수정에 관한 API면 묻고 @Put으로 갔었는데, 이번엔 좀 더 이해를 하고 필요에 맞춰서 써보고 싶었다. 일단 당시의 생각대로 작성해봤던 코드다. //프로필 수정 @PatchMapping("/profile/{userId}") public ResponseEntity updateProfile(@PathVariable Long userId, @RequestBody UserUpdatePr..

231126W 며칠 간 이어진 스프링 시큐리티를 이용한 프로젝트. 내가 맡아 구현해야 할 API는 회원가입, 로그인, 비밀번호 수정, 프로필 수정 이렇게 네 가지 였는데, 그 중에서 ‘프로필 수정’을 작업 중이었다. Client로 부터 요청 값을 받을 ‘UserRequestDto’를 작성하고 있었는데, 프로필에 들어갈 자기소개용 필드 ‘content’ 하나를 마련했다. 그런데 언젠가 다른 웹사이트에서 글을 작성하다 글자 수 500자였나 1500자였나 제한이 걸렸던 적이 있었던게 생각나서 이번에 적용해 보기로 했다. 제일 처음 생각난 건 ‘정규식’ 이었다. 회원가입 API를 만들며 작성한 RequestDto에서 ‘username’과 ‘password’필드를 선언했었는데, 각각 제한을 걸어줬었다. @Gett..

231115CW 오늘도 어김없이 밤시간 까지 열심히 Spring 공부를 하던 와중이었다. 상품을 저장하는 웹페이지를 구현하려 API를 작성 중 이었는데, 어느 순간 거슬리는 상황이 발생했다. 상품을 모두 조회하는 API를 작성 중이었는데, return값으로 productService를 주려는 중이었다. VSCode와 마찬가지로 IntelliJ또한 여러 단축키, 자동완성 등 편리한 기능들을 지니고 있는데, 이번에도 “그렇지 착한녀석.” 하면서 Enter를 탁 쳤다. 이젠 빨간줄 뜬다고 무조건 쫄진 않는다. 훗. 해당 productService Class에 메서드 생성을 위해 Alt+Enter를 탁탁! 그런데 어, 예상키론, 제일 하단에 얌전히 뜩, 하고 생성되야 하는데 뭔 자신감인지 필드 바로 아래서 존재..

231115CW 정수 num이 짝수일 경우 "Even"을 반환하고 홀수인 경우 "Odd"를 반환하는 함수, solution을 완성해주세요. 제한 조건 - num은 int 범위의 정수입니다. - 0은 짝수입니다. ...란다. 처음에 작성한 코드 Personal public static String solution(int num) { String answer = ""; if (num % 2 == 1) { answer = "Odd"; } else if (num % 2 == -1) { answer = "Odd"; } else if (num % 2 == 0) { answer = "Even"; } else { answer = "Even"; } return answer; } 아주 하나하나 쭉쭉 작성해놨다. 원래는 -..

231106W 응 그냥 그렇다고. 한참 Spring의 기초를 배우던 중 이었다. 열심히 이것 저것 설정도 하고 코드 작성 후 실행도 해보고 메모도 하면서 공부 중 이었는데, 갑자기 흠칫 하게 됐다. 강사 쌤의 터미널이랑 내 터미널의 메세지가 다른 것. 분명 원하는 값은 나왔는데, 저 네모 안의 메세지가 추가로 있다. 이전 IntelliJ와 Github간 연결해볼 때 몇 번 재설치를 한 경험 후로 사소한걸로 흠칫 흠칫 거리게 되서 바로 검색해봤…더니 별거 아니란다. 빌드시에 나타나는 경고인데, 그냥 단순히 현재 내가 사용하는 Gradle 버전이 낮아 보내는 메세지란다. 고로 그냥 Gradle을 버전업 만 시켜주면 된다는 것. “올? 그냥 너가 쓰는 Gradle 버전 낮은데? 응. 그냥 그렇다고.” 일단 검..

231024~231030C 1101W 끝은 났지만. 이렇게 생애 두 번째 팀 프로젝트 도 무사히 끝이 났다. 뭔가 내가 작업했던 파트만 훅! 하고 훑어왔는데, 실은 이러저런 많은 일들, 작업들이 있었다. Github에 대한 경험이 많지 않아 팀원 초대 받는데도 헤맸고, 분명 Push 한 것 같은데 PR버튼 활성화가 안되서 헤매는 단순한 일들로 시작해서, 다른 팀원과 메서드를 공통으로 사용하게 된다거나, 각자 작성한 코드들이 어떻게 이어지게 할지 의논한다거나, 중간중간 막히는 부분에 대해 질문도 하고, 마감 시간까지 시간이 부족 할 것 같아 주말 밤에 모여서 열심히 달리기도 했다. 중간중간 잡담하기도 하고, 좋은 정보 공유도 하고, 넷상에서의 맵, 각 팀 장소에 모여서 소통하는데 간혹 마이크나 카메라가 연..

231024~231030C 1031W 하나가 되자 코드들아. 이전 글에서 출력문들은 output클래스로 모아놨다고 했었다. 나같은 경우 객실상태를 확인하는 작업이다보니 RoomCheckOutput으로 명명했다. 출력될 내용들을 System.out.println(); 와 함께 메서드에 넣었고, 이를 HotelLounge에서 순서에 맞게 호출해가게 된다. public void printConfirmedCheckedRoomView() { System.out.println("선택하신 객실이 장바구니로 이동되었습니다."); System.out.println("'객실예약대기목록'에서 결제해주세요. :)"); } 위와 같이 대부분 단순 출력만하는 경우였는데, 게중에 하나는 조금 달랐다. public void prin..

231024~231030C 1031W 루프문의 향연, HotelLounge 이제 데이터를 만들었으니 이것들이 차례대로 동작하고 계산되고, 출력되게 만들어 줘야 한다. 우리 팀은 작성하고, 작성될 코드들이 순차적으로 돌아가는 메서드들을 HotelLounge에 작성했는데 큰 틀은 While 루프문 이었다. 루프문 내에서 순차적으로 적재적소에 들어갈 메서드 들을 잘 넣어주면 나중에 Run(실행) 시킬 시, 해당 출력화면에서 어떤 값을 입력하느냐에 따라 해당메소드로 이동하고 그 메서드 내에서 또 다른 메서드들이 호출되고 마지막에 이르러선 메인으로 돌아가고, 다시 시작하고… 이렇게 계속해서 반복할 수 있게 된다. 적어도 실행을 멈추거나, 뜻하지 않는 에러를 만나기 전까진. 그 과정에서 데이터 값들이 서로 맞물리고..

231024~231030C 1030W 객실 하나하나의 정보를 담는 Room과 이를 모아둔 Map, roomList, 그리고 러브룸. 우선 객실 목록 조회를 위한 RoomDatabase(향후 Hotel로 바뀜)클래스를 생성 우선 각 객실별로 호실 번호, 타입, 가격, 그리고 현재 예약 현황을 알 수 있어야 한다. 제일 먼저 떠오른 건 List를 사용하는 거였는데, 이번 기회에 많이 안 다뤄본 Map을, 그 컬렉션 중에서도 대표적이라고 하는 HashMap을 활용해보기로 하고 작성하기 시작했다. private final Map roomList = new HashMap private Hotel() { roomList.put(1, new Room(101, RoomType.MEDIUM, 5400000L, false..