12월 21일 한일

- MVC 프레임워크 3단계 실습 피드백 완료

• 레거시 MVC와 애노테이션 기반 MVC 통합

- 프레임워크 vs 라이브러리 발표 준비

• ppt 제작

• 라이브코딩 준비

• 예제로 사용할 간단한 프레임워크(를 흉내낸) 제작

---

12월 21일 한일

- 프레임워크 vs 라이브러리 발표

- Mockito 테스트 라이브러리를 활용한 테스트

• Mockito를 활용하여 코드 작성

  @Test(expected = EmptyResultDataAccessException.class)
  public void delete_when_question_is_null() throws CannotOperateException {
    when(questionDao.findById(1L)).thenReturn(null);
    qnaService.deleteQuestion(1L, null);
  }
  

  when으로 등록해둔 동작이 실행 될때 thenReturn으로 넣어둔 값을 반환하게 된다.

---

12월 21/22일 느낀점

• 프레임워크와 라이브러리에 대해 설명하기 위해 준비하면서 내가 발표 대상으로 삼은 사람들은 이미 일정 이상의 지식이 쌓인 분들이 아닌 프로그래밍 및 웹에 대한 공부를 시작한지 얼마 안된 분들이였다. 그분들한테 눈높이에 맞춰서 어떻게 설명 해야 할지에 대해서 일주일 내내 고민을 해봐도 방법이 떠오르지 않았다.(어떤 설명도 충분히 어려웠다) 그러다 과감히 더 쉽게 설명하는걸 포기했다. 대신 최근에 MVC 프레임워크 단계를 공부한 경험을 살려서 간단한 프레임워크까지 만들어서는 라이브 코딩을 준비해서 라이브러리와 프레임워크가 각각 어떤 상황에서 생겨났는지를 보여주기로 마음먹었다. 그러면 라이브러리와 프레임워크의 차이를 느끼지 않을까란 생각이였다. 그게 발표 전날 밤 10시경…
  다행히 발표는 나름 성공한거 같다. “처음 설명을 봤을땐 하나도 모르겠다는 느낌을 받았는데(의도했다) 라이브러리와 프레임워크가 나오게 된 과정을 보게되니까 둘의 차이가 아주 당연하고 쉬운 내용인거 같았다. 그걸보고 나니 처음엔 뭔 소린지 몰랐던 ppt의 그림이 의미하는 바를 알겠더라”는 말을 들었다. 프레임워크 및 라이브코딩 준비를 새벽 4~5시까지 했던거 같은데 그말 덕분에 보람찼던거 같다. 아쉬웠던건 언제뻗은지 모르게 뻗어버리는 바람에 ppt를 계획한 페이지들은 다 작성했지만 첫장을 더 어렵고 간결하게 작성해 두고 싶었는데 (핵심만 간결히 적혀있는데 이해 못하는 멘붕에 빠트리고 싶었다) 그러지 못해서 아쉽다. 발표는 준비하는 과정이 진이 빠져서 그렇지 역시 하고 나면 재밌긴 한거 같다.

• Mock테스트를 어렵게만 생각했는데 능수능란하게 쓰는건 어렵겠지만 생각보다 할만 한 것 같다는 느낌을 받았다. 역시 어렵울 거라고 생각하는 많은 일들의 대부분은 처음 시작이 가장 어려운게 아닌가 싶다. 제대로 알려면 추가로 공부를 더 해야겠지만 Mock테스트에 대한 그 허들은 포비 덕에 쉽게 넘어간거 같다.

---

내일 할일

• Spring MVC 실습

• [코드스쿼드 Maker Class] 아두이노를 이용한 아크릴 조명 만들기 참석

• 저녁 친구 약속

오늘 한일

- 09년에 목표로 했던 헌혈 100회 달성

- 용산 아이맥스에서 스타워즈 관람

- MVC 프레임워크 3단계 실습

• MVC 프레임워크 3단계 실습 피드백을 통한 리팩토링 진행중

• 남은 사항 :

  • HandlerAdapter 적용

---

오늘 느낀점

• 헌혈 100회를 목표로 했던 이유는 당시 무언가를 꾸준히 해본 경험이 없었다. 게임 조차도 한 게임을 2~3년 이상 해본게 없다. 솔직히 당시에 네다섯번 했던 헌혈은 문화상품권을 얻을 수 있다는게 큰 이유 중 하나였을 것이다. 그러다 엉뚱하지만.. 나도 무언가를 꾸준히 할 수 있다는 걸 실천해보고 싶었다. 몇번 했는지도 횟수도 알려주니까 그거에 동기 부여도 되고, 수혈이 필요하신 분들한테 도움도 될테니 100번의 헌혈을 목표로 했었다.
  이론상으론 4~5년이면 가능하지만 시간이 흘러 8년만에 목표를 이뤘다. 생각해보면 당시엔 꾸준히 하는 무언가가 하나도 없어서 목표로 했던건데 현재의 나는 공부와 TIL 작성을 꾸준히 하고 있다는 점에서 스스로가 대견스럽기도 하고 헌혈을 꾸준히 하다보니 어느 순간 100회가 된 것 처럼 공부도 꾸준히 하다보면 언젠가는 내가 원하는 목표에 도달해 있었으면 좋겠다.(거기다 200회 및 조혈모세포 기증은 언제 될지 궁금하다)

• 목표. 사실 추상적이다. 그걸 좀더 구체화해가는게 작은 목표 중 하나이다. 일단 지금 잡은 목표는 5년, 10년이 들어서도 공부하고 싶은 것이 있고 그걸 공부하는 것이다. 단순히 ‘해야 될’ 공부가 있어서 하는게 아니라 ‘하고 싶은 것’이 있는게 핵심이다. 간단히 요약하면 지속적으로 성장하는 사람이 되고 싶다.

• 용산 아이맥스서 영화를 관람 했는데 엄청나게 뭐가 다르다는 느낌은 없었지만 덩케르크를 여기서 봤으면 어땠을까 싶은 생각이 들었다. 스타워즈는 광팬이 아닌 관계로 다음번에 정말 좋아하는 영화가 아이맥스로 개봉한다면 다시 방문 할 것 같긴 하다.

• 좋아하는 작가의 책이 어제 발간되서 오늘 도착했다. 언제 볼지는 모르겠지만 오늘 뭔가 내 취미(게임, 영화, 책인데 셋다 간혹 취미 적는 란이 있는 이력서에 쓰기 뭐하다. 다 진짠데…)를 모두 한 것 같다.

---

내일 할일

• MVC 프레임워크 3단계 실습

  • HandlerAdapter 적용

  • 지저분한 부분들이 많아 리팩토링 후 pr

오늘 한일

- MVC 프레임워크 3단계 실습

• 요구사항 1 - 애노테이션 기반 MVC 프레임워크 (완료)

  • reflections.getTypesAnnotatedWith(Controller.class) : Controller 애노테이션이 사용된 클래스 추출

  • method.getAnnotation(RequestMapping.class) : RequestMapping가 사용된 자바 메소드에 URL과 Request 메소드 정보를 추출

  • Map<HandlerKey, HandlerExecution> : URL과 Request 메소드 정보를 가지고 있는 HandlerKey와 클래스와 자바 메소드를 가지고 있는 HandlerExecution

  • 이후 클라이언트로부터 요청이 오면 요청 URL과 메소드를 이용하여 HandlerKey 객체를 만들어 해당 핸들러 메소드 호출

• 요구사항 2 - 레거시 MVC와 애노테이션 기반 MVC 통합 (진행중)

  • 힌트 1 : 기존 RequestMapping를 LegacyHandlerMapping로 변경

  • 힌트 2 : DispatcherServlet에서 LegacyHandlerMapping, AnnotationHandlerMapping 모두 초기화

---

오늘 느낀점

• 요구사항 1을 하면서 생각보다 어려운 것 없는거 같은데 늦어진 느낌이다. 어려운 느낌이 적은 이유는 사실 힌트를 참고하면서 하다보니 그런거 같은데 늦어진 원인은 힌트를 안보고 하려다 늦어진거고, 쉬운 원인은 힌트를 보는것이 문제이다.
  그 간극을 줄일려고 조절하고 있는데 이번 실습 같은 경우는 힌트 하나 없이 진행 해 볼 능력은 부족한거 같다. 그런 부분에서 아쉬운게 같은 단계를 진행하는 동료가 있었으면 힌트가 아닌 논의를 하면서 진행(혹은 일정 논의 후 좀더 빠르게 힌트 참조 여부를 결정 할 수도 있을것이다) 해 볼수 있었을텐데 그럴 동료가 없는게 살짝 아쉽다. 그러다보니 힌트를 더 볼까 말까 갈팡질팡 하다가 더 늦어지는 경향도 있는것 같다.(개인적인 욕심으로 힌트를 안 보고 싶어서 그런면도 있고…)

• 솔직히 이번처럼 살짝 힌트에 끌려 다니는 느낌이 들때는 테스트 코드를 제대로 못 짠다…혹은 자주 사용 안하던 set같은게 나오던지 할때는 말이다. 이번같은 경우는 아예 못 짤것 같진 않으니 일부 진도가 더 진행된 다음 빠진 테스트 코드를 추가해야 겠다.(이번 단계가 늦어지고 있는 느낌이라 구현자체가 더 신경쓰인다)

• 아래와 같이 기본 메소드가 존재하는 인터페이스가 있다고는 들었는데 드디어 봤다.

  @Target({ ElementType.METHOD, ElementType.TYPE })
  @Retention(RetentionPolicy.RUNTIME)
  public @interface RequestMapping {
      String value() default "";
  
      RequestMethod method() default RequestMethod.GET;
  }
  

  생각보다는 구조 자체는 간단한 느낌이다. 추가로 아래에

  RequestMapping rm = method.getAnnotation(RequestMapping.class);
  ---
  @RequestMapping(value = "/users", method = RequestMethod.POST)
  

  getAnnotation()에서 애노테이션에 사용된 값을 이용해 RequestMapping 구현체를 만드는것 같긴한데, 해당 메소드의 내부를 보려고 했는데 한두번씩 만나고 있는 아래의 원인으로 내부 구현물은 못봤다.

  

  원인도 분명하게 적혀 있어서 이전부터 인터넷에서 찾은 방법들을 수행 해 봤는데 왠지 해결이 안된다. 정말 중요한 부분들은 아니여서 매번 아쉽지만 넘어갔는데 문제 해결이 안되는 것도 그렇고 제대로 분석자체도 못하는 것 같아서 찝찝하다. 올해가 가기전엔 확실히 해결 해 둬야겠다.

• 요구사항 2는 힌트 1과 2의 중간 정도 단계인데 어느정도만 작업하면 힌트3까지 끝날것 같다. 오늘 마무리하고 자고, 내일 일이 좀 있는지라 저녁때쯤부터는 피드백 내용도 참조하여 리팩토링을 진행하고 목요일쯤 pr을 보내지 않을까 싶다. 이후 있는 “Spring MVC 실습” 내용이 많아 보이진 않으니 일단은 괜찮을 듯 싶다.

---

내일 할일

• MVC 프레임워크 3단계 실습 마무리

  • 요구사항 2 - 레거시 MVC와 애노테이션 기반 MVC 통합

  • 프레임워크와 라이브러리의 차이점 발표자료 준비

오늘 한일

- 자바 Reflection 실습

• Java Reflection API : 컴파일한 클래스 정보를 활용해 동적으로 프로그래밍이 가능하도록 지원하는 API

- MVC 프레임워크 3단계 실습

• 요구사항만으로 진행 실패, 힌트 참조 시작

---

오늘 느낀점

• 리플랙션이 뭔지 배웠다. 이전 이펙티브 자바의 싱글턴 패턴 규칙에서 private 생성자를 리플렉션으로 공격이 가능하다 했는데 오늘 해보니 충분히 가능 할 것 같다.

• 리플랙션을 사용해보니 다양한 것들이 가능 하던데 그만큼 어떻게 사용해야 할지 쉽진 않은 내용인거 같다. 아직 실습을 제대로 진행 하진 못했지만 이전에 어노테이션 내부 구현 내용은 텅 비였는데도 많은 동작들을 수행 할 수 있게 해준게 이상했었다. 그 비밀이 여기 있었던거 같다.

• 리플랙션에 대한 내용이 적은 이유는 오늘 실습한 내용은 따로 정리 해서 올려봐야겠다.

• 난방기를 마주보고 앉으면 안되겠다. 저녁에 눈이 너무 건조해지고 뻑뻑하다. 게다가 잠이 부족했는지 피로감까지 느껴져서 10분 정도 이상으론 집중이 안됐던거 같다. 그러다보니 진도자체도 별로 못나가고 학습 자체에 소득이 없었던거 같다.(리플랙션에 대해선 알기만하고 제대로 보진 못한 느낌이다) 졸리기라도 했으면 잠깐 자기라도 했을텐데 미묘하게 컨디션이 안좋아서 쉬어야 겠다는 생각이 안든거 같다. 수요일에 개인적인 일정때문에 저녁 전까진 공부를 못할거 같아서 신경쓰이는데 오늘은 1시엔 불끄고 누워야겠다.

---

내일 할일

• MVC 프레임워크 3단계 실습

  • 요구사항 1 - 애노테이션 기반 MVC 프레임워크

  • 요구사항 2 - 레거시 MVC와 애노테이션 기반 MVC 통합

  • 요구사항 1은 끝마치고, 요구사항 2까지 어느정도 완료하거나 중간진행까진 가능하게 하자(18시 이전까지 목표)

16~17일 한일

- RESTful API 공부

• 좋은 자료

  그런 api로 괜찮은가 동영상 자료
  REST API 제대로 알고 사용하기
  REST의 영광을 향한 단계들

• REST API 중심 규칙
  ```
  • URI는 정보의 자원을 표현해야 한다. (리소스명은 동사보다는 명사를 사용) ex) GET /members/1
  • 자원에 대한 행위는 HTTP Method(GET, POST, PUT, DELETE 등)로 표현 ex) DELETE /members/1 ```

• 더 많은 내용들이 있지만 바로 신경쓸수 있는 부분들

  • HTTP 응답 코드의 사용 ```
    • 200 반환 코드를 사용하여 에러 응답을 포함하는 방식과 달리 명시적으로 에러 응답을 사용 ```
  • URI 설계시 주의할 점
    ```
    • 슬래시 구분자(/)는 계층 관계를 나타내는 데 사용
    • URI 마지막 문자로 슬래시(/)를 포함하지 않는다.
    • 하이픈(-)은 URI 가독성을 높이는데 사용
    • 밑줄(_)은 URI에 사용하지 않는다.
    • URI 경로에는 소문자가 적합하다.
    • 파일 확장자는 URI에 포함시키지 않는다.
      ```

- 프레임워크, 라이브러리

• 의외로 간단하다

  프레임워크 : 프레임워크 코드가 내 코드를 호출
  라이브러리 : 내 코드가 라이브러리를 호출
  

  

  

• 추가 사항 (출처)

  프레임워크도 제어의 역전 개념이 적용된 대표적인 기술이다. 프레임워크는 라이브러리의 다른 이름이 아니다.
  프레임워크는 단지 미리 만들어 둔 반제품이나, 확장해서 사용할 수 있도록 준비된 추상 라이브러리의 집합이 아니다.
  프레임워크가 어떤 것인지 이해하려면 라이브러리와 프레임워크가 어떻게 다른지 알아야 한다.
  라이브러리를 사용하는 애플리케이션 코드는 애플리케이션 흐름을 직접 제어한다.
  단지 동작하는 중에 필요한 기능이 있을 때 능동적으로 라이브러리를 사용할 뿐이다.
  반면에 프레임워크는 거꾸로 애플리케이션 코드가 프레임워크에 의해 사용된다.
  보통 프레임워크 위에 개발한 클래스를 등록해두고, 프레임워크가 흐름을 주도하는 중에 개발자가 만든 애플리케이션 코드를 사용하도록 만드는 방식이다.
  최근에는 툴킨, 엔진, 라이브러리 등도 유행을 따라서 무작정 프레임워크라고 부르기도 하는데 이는 잘못된 것이다.
  프레임워크에는 분명한 제어의 역전 개념이 적용되어 있어야 한다.
  애플리케이션 코드는 프레임워크가 짜놓은 틀에서 수동적으로 동작해야 한다.
  
  [원문] 토비의 스프링3 p.95 (1장.오브젝트와 의존관계)
  

즉, 주도권 혹은 제어권이 누구한테 있냐에따라 프레임워크, 라이브러리가 구분 될 수 있다.

---

16~17일 느낀점

• 자료들을 찾다보면 RESTful과 REST API란 용어가 등장을 하는데 둘의 차이가 무엇일지 궁금해서 찾아봤다. 직접적으로 해답을 찾진 못했지만

  오늘날 스스로 REST API라고 하는 API들의 대부분이 REST 아키텍쳐 스타일을 따르지 않는다.
  

  이와 관련된 자료들도 찾다보니 REST API가 아닌 것들을 몇몇 이유때문에 REST API라고 불리던데(해당 내용) REST API가 아닌 REST API와 진짜 REST API를 구분하기 위해서 생긴 용어가 아닐까 싶다.

• 라이브러리에 대해서는 “남들이 미리 만들어놓은 함수들을 가져다 쓸수 있는 것” 이라는 정도의 지식을 가지고 있었는데 화이트과정에서 자바 백엔드는 스프링 프레임워크를 사용 한다는데 스프링이야 프레임워크의 이름일테고 그래서 프레임워크가 무엇인지 궁금했었다. 당시 찾아 봤을땐 제대로 이해가 안돼서 이용하게 되면서 종속성이 발생하면 프레임워크 아니면 라이브러리 이정도로 이해를 하였다. 그러다 오늘 다시 찾아봤는데 위의 두 사진만으로도 다른 말을 추가 할 필요가 없을 것 같다.

• 사실 프레임워크와 라이브러리에 대해 찾아본 이유는 백엔드 내부 발표로 osi 7계층을 활용하여 네트워크에 대해서 발표 하려다가 여러 어려움으로 다른 주제로 할만한게 무엇이 있을까 고민하다가 내가 이전에 궁금해하다가 제대로 해결 못했던 프레임워크와 라이브러리가 어떻게 다를까가 기억나서 찾아봤다.
  일단 발표 준비까진 안하고 스스로 학습차원으로 자료들을 많이 찾아봤는데 생각보다 어려울것 없는 내용인 것 같아 발표를 할 정도의 주제인가 의문점도 들고, 의외로 다들 구분을 할 줄 알거나 다른 사람들한테도 도움이 될 만한 주제인지가 살짝 고민된다.

• 네트워크를 발표 주제로 하기 쉽지 않은 이유가 사실 일단 내용 자체가 어려워서 추가적인 공부가 꽤나 필요하다.(설명을 못 한다는건 아직 제대로 아는게 아니란거라던데…) 어떤 파트를 얼마나 다뤄야 할지나 다른 사람들의 기본지식이 얼마나 있냐에 따라 단어 선택이나 부연 설명의 필요 유무(예를 들면 mac address가 뭔지는 몰라도 단어자체는 들어봤는가 아닌가)가 갈린다. 그래서 일단은 쉽게 가보자 싶어서 내가 이전에 궁금했던 주제를 알아봤다.

---

내일 할일

• JSON API 및 AJAX 실습 피드백 발생시 해결

• MVC 구현 및 Spring 기본 실습 시작(JSON API 및 AJAX 실습이 merge 된다면)

  • 첫번째 요구 사항들 파악
  • 실습 시작