오늘 한일

- MVC 프레임워크, JDBC 라이브러리 : JDBC 라이브러리 실습

• 익명클래스를 활용하여 두개의 xxJdbcTemplate를 하나의 클래스로 만듬

• JdbcTemplate와 User의 의존관계 제거

• SelectJdbcTemplate 클래스 구현

• 남은 사항 :

  • SelectJdbcTemplate 리팩토링

  • SelectJdbcTemplate 와 기존의 JdbcTemplate를 합치기

  • 전체적인 리팩토링

- Developer Party DeveLOVE2017 참석

• 스티커 받았다. 스타벅스 쿠폰 받았다.

오늘 느낀점

• JdbcTemplate는 아직도 User와 의존관계를 가지기 때문에 재사용할 수 없다. User와 의존관계를 끊는다.의 요구사항에서 User가 인자로 안넘어가면 어떻게 JdbcTemplate에서 User의 정보를 사용할까 궁금했다. 이전엔 딱히 방법이 안 떠올랐으니 말이다. 근데 차례차례 진행을 하다보니 UserDao에서 추상메소드를 구현하게 되니까 자연스럽게

  JdbcTemplate jdbcTemplate = new JdbcTemplate() {
  			@Override
  			void setValues(PreparedStatement pstmt) throws SQLException{
  				pstmt.setString(1, user.getPassword());
  				pstmt.setString(2, user.getName());
  				pstmt.setString(3, user.getEmail());
  				pstmt.setString(4, user.getUserId());
  				pstmt.executeUpdate();
  			}
  		};
  

  위처럼 작성이 가능 해 졌다. 의존관계를 이렇게도 끊을 수 있다는걸 알게 되서 놀라웠다. 이런식으로 기존에 있던 개념들을 이용한 활용법들을 알때 “이런 방법이 있었구나” 자극도 받고 재밌는거 같다.

• 요번주는 중간 중간 행사를 다니다보니 작업 시간도 적어졌고 흐름도 끊겨서 구현 속도가 느려진 것도 있었던거 같다. 일단 고민을 할만큼 하고서 동영상을 참고 하려고 했는데 내일까지 진행이 안돼고 막히면 내일은 동영상을 참고하며 리팩토링을 진행 해야겠다.

• Developer Party DeveLOVE2017 갔다왔는데 정말 좋은 자리였다. 이런 자리가 처음이다보니 어색한 모습을 보이거나 쉽게 혹은 이번처럼 편히 만나지 못하는 사람들과 대화할 기회가 있었는데 그 기회를 살리지 못한거 같아서 아쉽다. 특히 처음 말을 걸때 어떻게 걸어야 할지 그 부분이 가장 쉽지 않은거 같다.(그 부분에서 실수한 부분들이 있는거 같다..) 내가 아는 개발자 및 공부 중인 사람들은 이전 국비과정과 지금의 코드스쿼드밖엔 없다. 그러다보니 다른 개발자들이(특히나 다양한 경력대의) 어떤 생각을 하고 있고, 어떤 활동들을 하는지 궁금했는데 그걸 경험해 본것 같다. 대화를 나누고 싶었던 분들 중 한분도 다른 분들이랑 대화 중이라 얘기를 못나눴는데 다른 분들이랑 대화 나누기 전에 다가 갈수 있었는데 그걸 못해서 아쉬웠다. 이처럼 스스로가 다른 사람들을 대할때 아쉬운 부분들이 많았는데 그것 자체도 나한텐 좋은 경험이 된거니까 다음에 이런 행사가 있다면 좀더 활발하게(?) 움직여 봐야겠다. 덤으로 자바 관련해서도 이런 모임들이 많았으면 좋겠다.

• Cu 덕분에 오늘 scouter라는 오픈소스 프로젝트를 알게 되었다. 내 옆자리 분이 scouter 개발자셨는데 솔직히 apm이라던지 해당 내용들을 하나도 모르니 아무말도 하지 못해서 아쉬웠다. 계속 아쉬웠다는 말만 쓰는거 같은데 아쉬운건 사실이고 덕분에 새로운 세상을 본거 같고, 더 많이 알아가야 겠다는 생각들이 들었다. 아 오픈소스에 기여해보고 싶다는 생각은 하고 있었지만 무엇들이 있는지 알지못했는데(어떻게 보면 찾아보지도 않았던거지만) 오늘 이렇게 scouter 개발자를 만난것도 인연이니 가장 쉽다는 “오타 찾기!!” 한번 도전해봐야겠다.(fork 완료)

• 스스로 현재 집중해야 할 것들에 집중하자면서 다른 일들엔 일부러 관심을 끄고 다녔는데 그때문인지 확실히 시야가 너무 좁았던거 같다. 근데 이런 행사들을 참여하면서 좋은 자극도 받고 의욕도 불타오르긴 하지만 현재 더 집중하고 싶은 것에 대한 집중도가 분산되는 부분도 있는거 같다. 그런 부분들은 조심하면서 슬슬 다양한 것들에 대해서도 알아가야겠다.

• 좋은 자극이 되었다. 좋은 개발자가 되고 싶다는 꿈은 있었지만 그 좋은 개발자가 어떤 개발자인지는 계속 고민 중이였는데 좀더 가닥이 잡힌 것 같다. 앞으로도 이런 행사들을 통해 다른 분들과 교류를 하면서 지속적으로 자극도 받고 다양한 것들에 관심을 가졌으면 좋겠다. 게다가 나중엔 나같은 초짜한테는 좋은 자극을 주고 싶다.

내일 할일

• MVC 코드 리뷰 및 JDBC 실습

오늘 한일

- W3C HTML5 Conference 2017_FE개발자 구인구직 & 웹 전시회 (링크)참석

• Web payment API (developers.google.com)

  

  아주 간단하게 PaymentRequest에 결제에 필요한 정보를 담아 보내고 response를 받아서 결제를 한다는 아주 아주 단순한 개념.

  구매자 입장에서 쇼핑몰 내에 구매 버튼을 누르면 아래처럼결제에 필요한 정보가 나오고(저장된 정보가 있으면 그걸 활용) pay 버튼을 누르면 결제 끝

  

  표준으로 적용하게 되면 유저들은 더욱 간단하게 구매를 하게 되고 사이트에 상관없이 통일된 UI를 이용하게 됨으로 편의성이 증대된다. 구현하는 사람 측면에도 표준을 따르기만 하면 결제사(카드사?)에 따라 따로 구현 해 줄 필요 없기때문에 간단해 진다.

  단, 한국에서는 빨라야 5년 걸리지 않을까 싶다고 한다. 시도하는 곳이 없다는 측면도 있지만 결정적으로는 한국의 결제 시스템때문에…(한국의 경우 카드사가 직접 카드정보를 입력받고 인증)

• Web payment API에 대해 듣다 알게된 한국의 결제 과정

  

  

  

- 집가는 길에 오리엔트 특급 살인 관람

오늘 느낀점

• 오늘 가장 기억에 남고 관심이 가는 건 Web payment API 였다. 덕분에 다른건 크게 눈에 안들어온거 같다. 몇가지 이유가 있을텐데 이전까진 자바스크립트로 무엇들을 할 수 있는지 몰랐는데(웹게임을 제외하곤 사용자들이 보는 페이지에 대해서만 사용한다고 생각했다) 이번 Web payment API가 자바스크립트로 이용하는 걸 보고 자바스크립트를 웹에서 어떻게 활용하는지에 대해 더 잘알게 된거 같다. 그리고 Web payment API쪽 개발을 해 보고 싶어 자바스크립트를 공부 하고 싶다는 생각이 들었다. 최근 자바&스프링 컨퍼런스는 참여를 못했는데 그때도 참여했으면 이런 자극을 받았을거 같은데 아쉽다.(오늘 컨퍼런스는 대부분 js쪽 내용들이였다)

• 한국의 결제 방법에 대해 알게되니까 자연스럽게 이전까지 내가 쇼핑몰에서 물건을 구매할때 왜 이렇게 번거롭게 구매해야 했는지, 왜 포털들이 자체 캐시를 구매 하게 한다음 그 캐시로 자신들의 상품을 구매하게 했는지 알게 된거 같다. 액티브x, 공인인증서 등 한국의 결제 시스템이 바껴야 할텐데 여러 이해 관계들이 섞여있다보니 쉽진 않을거 같다.

• 최근 알게된 iframe 등 몇몇 내용들이 강연에 나왔는데 왠지 보람 찼다. 아무래도 백엔드쪽 내용들이 없다시피해서 이해 할 수 있는 내용들이 한정적이였는데 최근 알게된 몇몇 내용들 아니였으면 진짜 알아들을 내용들이 더 적었을거 같다. 그리고 아쉬웠던 점 중 하나는 컨퍼런스에 도착하고 노트북을 켜보니 배터리가 없어서 메모를 못했다는 점이다…(기억에 의존하다 보니 벌써 흐릿한 부분들이 많다)

• 최근 들어 앞으로 내가 뭘 개발하고 싶은지 조금씩 생각을 해보고 있었다. 리팩토링을 통해 코드가 점차 나아지는 재미를 느껴서 레가시 코드를 개선하는 일도 재밌을거 같다고 생각 했고, 어릴때부터 일반인들이 많이 사용하는 무언가에 내가 참여해서 만들어 보고 싶기도 했다. 근데 오늘 발표자들을 보면서 Web payment API를 사용해보고 싶다고도 생각했지만, 나도 저런걸 만드는데 참여를 해보고 싶다는 생각이 들었다. 심지어 사내에서 쓰는 API가 아닌 저런 표준 API를 만든다면 그걸 구현해서 만든 서비스에도 내가 기여하는게 되고 말이다. 그리고 웹 표준을 정하는 사람들은 기술서에 소개페이지에 나오는 어마어마하신 분들만 있는줄 알았는데 의외로 다양한 사람들이 있다는걸 알았고, 내가 생각한 것보다는 허들이 낮았다. 하지만 아직까지는 지구에서 안드로메다까지의 거리였던게 이제는 태양정도의 거리다. 멀다. 거기다 대기업을 욕심내야 할 것 같은 느낌이 든다…(석박사 아니면 자리도 없을거 같다)

• 저녁에 공부 하려고 책도 챙겨 갔었는데 강제로 쉼표를 안찍어주면 제대로 쉬질 못하는거 같아서 급 계획을 바꿔서 영화를 봤다. 단순 추리물로 스릴러적 특성으로 긴장감이 많은 영화일줄 알았는데 예상과 다르게 훈훈한 영화로 편히 잘 본거 같다.

내일 할일

• • MVC 코드 리뷰 및 JDBC 실습

오늘 한일

- MVC 프레임워크, JDBC 라이브러리 : JDBC 라이브러리 실습

• UserDao 구현 및 테스트 코드 통과

• UserDao 리팩토링: 포비의 힌트에 나온 메소드들을 구현하여 일부 중복 분리

• InsertJdbcTemplate, UpdateJdbcTemplate 클래스 구현

- 저녁 타임 톰캣 최종분석 차근 차근 보는중

오늘 느낀점

• InsertJdbcTemplate의 insert(User, UserDao) 메소드를 구현하는 단계에서 UserDao를 인자로 넣어주는 부분 구현이 아무리 생각해도 깔끔하게 구현할 방법이 떠오르지 않았다. 계속 떠오르는 방법은 너무 아닌거 같아서 어떤 방법으로 해야하는 걸까 고민을 하다가 2시간쯤 화면만 쳐다봤다. 그러다 일단 구현하고 보니까 애초에 의도가 내가 안좋다고 생각한 방식대로 하는게 맞았던거 같다. 그 상태를 보고 다음 리팩토링을 진행 시키는게 목표였던거 같다. 역시 구현하고 봐야 하는거 같다.

• 가능하면 힌트를 안보고 하려고 리팩토링 요구사항 시작 부분에서 많은 고민을 했는데 결국 아예 안보고 하는건 실패 했다. 아쉽긴하지만 볼링의 경험으로..적당히 끊은거 같다. 이번에 느끼는건 메소드를 분리한다던지 바로 눈에 보이는 곳에서의 리팩토링은 어느정도 익숙해진거 같은데 이번 과제의 주제 중 하나인 API를 사용할 다른 개발자를 배려하면서 프로그래밍하는 연습을 한다 같이 현재 내 사항에서만 적당히 깔끔히 쓰이게 구현하는게 아니라 좀더 범용적으로 쓰일 수 있게 개선하는 작업은 어떤부분을, 어떻게 시작해야 할지 부터 잘 못하는거 같다. 이번처럼 xxTemplate을 만들고 나면 어떤 중복들이 생기는지 보고 그 중복들을 줄이는건 가능하지만, 그런걸 만들어야 한다던지(인터페이스로 구현할까 생각했다) 이후 이걸 좀더 수월하게 쓰게 개선 시켜야 할지는 아직 부족한거 같은데 이번 학습을 통해서 좀 익혀야겠다. 단, 중복을 줄이는 리팩토링은 좀더 수월해진 이유가 반복을 통해서 익혀진거 같은데, 이번과 같은 개선 사례는 나중에도 발생시 금방 떠오릴 수 있을까 싶다. 트램이 한번 다 만들고 다시 만들어봤다는데 나도 그래봐야겠다. 특히나 포비의 힌트를 많이 따르게 되는 경우 세부 구현이야 내가 했지만 내가 짠 느낌이 덜해서 아무래도 내꺼가 되는 느낌이 덜하니까 구현이 완료되면 다시 해봐야겠다.

• 저녁을 먹다 잠깐 나온 mybatis, mysql 대화에서 아차 싶었다. “그래서 지금 내가 구현하고 있는 내용인 JDBC란게 뭐였지?” 순간 이 생각이 떠올랐다. JDBC라는 단어는 이전 9월에 공부하면서 봐서 db쪽 내용이란 것도 알고 있어서 단어 자체는 익숙했다. 그래서 정말 아무생각 없이 JDBC가 뭔지에 대해서는 고민을 하나도 안하고 실습의 요구사항에 대해서만 진행을 하고 있었다. JDBC가 뭔지에 대해서는 간략하게긴 해도 금방 기억났지만 내가 무얼하고 있는지 제대로 인지도 못한 상태로 작업을 하고 있었다는 점에서 스스로 충격 좀 먹었다. 단순히 요구사항에 맞춰 “좋은 코드 만들기” 이런 작업을 하고 있었던거 같다. 내가 현재 뭘 하고 있는지 제대로 인지하면서 진행을 하도록 해야겠다.

• 디비와 관련 있는걸로 알고 있는 JPA, ORM은 아직도 뭔지 모르는 상태다. 그러다보니 JDBC나 몇몇 개념들이 이리저리 섞여 혼동을 하는거 같다. 좀 찾아봐서 뭔지 서로간에 구분을 해둬야 할거 같다. 지금 당장은 구현 욕심이 나는 관계로 이번 주말에 JDBC, JPA, ORM은 간단히 찾아보자. 이전까지는 모르는 단어나 개념들에 대해서는 해당 키워드만 기억해 두고 나중에 필요해질때 차차 알게 될테고 당시에 중요한 개념이 아니니 그때 중요한 것들에 집중 했는데, 이제는 모르는 단어나 개념들은 채워나가면서 진행 할 때가 된거 같다.

내일 할일

• W3C HTML5 Conference 2017_FE개발자 구인구직 & 웹 전시회 (링크)

오늘 한일

- MVC 프레임워크, JDBC 라이브러리 : MVC 프레임워크 1단계 실습

• DispatcherServlet 구현 : 모든 클라이언트 요청을 받는 서블릿

• RequestMapping 구현 : 요청 URL과 컨트롤러 매핑하는 클래스

• ForwardController 구현 : 특별한 로직 없이 뷰(JSP)에 대한 이동만을 담당하는 클래스

- 저녁 타임 톰캣 최종분석 읽음

• 머리 자르느라 별로 못봤다.

오늘 느낀점

• 오랜만에 코딩을 하니 순간 오전에 멍때렸다. 정확히는 어떻게 시작할까 감이 안잡혔다. 그 덕에 어떤식으로 요구사항들을 해결 할까 고민하다가 일단 만들고 보자는 식으로 구현 하다보니 커밋을 활용하지 못하고 한번에 만들어 버렸다.(이런식으로 만드는게 맞나? 확신이 너무 안선 상태로 작업 하다보니 커밋하기가 꺼려졌다) 처음엔 DispatcherServlet의 동작들을 doGet, doPost 메소드에 구현했는데 아무리 생각해도 이건 아닌거 같아서 service를 활용하게 바꿨다. 그 다음 RequestMapping이 미묘한곳에서 가지고 있었는데 이걸 자연스럽게 init를 활용 해서 DispatcherServlet가 가지게 했다. 한 5일정도 코드를 한번도 안쳐서 그런지 순간 감을 잃은 느낌이였다. 여튼 오후에 정신차리고 잘 마무리 했다.

• 사실 ForwardController은 어떻게 forward로 이동할 JSP 경로 정보는 생성자로 전달할 수 있도록 구현한다.는 요구사항의 생성자로 전달하는 부분을 계속 고민하다가 다른 사람의 코드를 힐끔 봤다. 이게 뒤늦게 하는 사람의 특권(?)이 아니겠는가?? 그래도 5분 10분이 아니라 그 이상 충분히 고민해봤다. ForwardController내부만 보고 사용법 자체는 직접 구현 했는데 같은 경로에 대해 재활용을 안하는게 마음에 걸렸다. 그러다 현재 TIL을 작성하다 잠시 고민해보니 아이디어가 떠올랐다.

  public Controller findController(String path) {
  		Controller controller = controllers.get(path);
  		if (controller == null) {
  			return new ForwardController(path);
  		}
  		return controllers.get(path);
  	}
  

  지금 코드는 controllers라는 Map에 포함되어 있지 않는 경로에 대해서는 같은 상태값을 가지는 새로운 controller를 매번 생성하게 된다.

  public Controller findController(String path) {
  		Controller controller = controllers.get(path);
  		if (controller == null) {
        controller = new ForwardController(path);
        controllers.put(path, controller);
  			return controller;
  		}
  		return controllers.get(path);
  	}
  

  이렇게 구현하면 차후에 같은 경로로 요청할땐 새로운 컨트롤러 객체를 생성하지 않고 최초 요청시에 생성하고 Map에 넣어둔 controller를 재활용 할 수 있을거 같다.

  public Controller findController(String path) {
  		Controller controller = controllers.get(path);
  		try {
        return controllers.get(path);
  		} catch (Exception e) {
        log.info(path);
        controller = new ForwardController(path);
        controllers.put(path, controller);
        return controller;
  	}
  

  급 생각났는데 위처럼 if문이 아니라 try-catch문으로 작성하면 조건문을 확인안하고 작동을 하니 더 효율적일 듯 싶다.(새로운 controller가 추가된 기념으로 로그도 찍어주고..) 아니면 try-catch문 자체도 일정 자원을 소모 할까??

• 밖에 춥다.

내일 할일

• MVC 코드 리뷰 및 JDBC 실습

• 톰캣 완벽분석 읽기

12월 01일 ~ 03일 한일

- 성공과 실패를 결정하는 1%의 네트워크 원리 읽음

- HTTP Chunked Encoding이 무엇인지 알아봄

- 인프런의 파이썬 웹 프로그래밍 - Django로 웹 서비스 개발하기 수강 완료

12월 01일 ~ 03일 느낀점

• 책을 읽는데 생각보다 오래 걸렸다. 책 보는 속도가 느린편인 것도 있지만, 학습차원상인지 지나친 반복도 있어서 늘어지는 부분이나

  이 책은 기존의 다른 네트워크 책들과 달리 전체 과정을 쉽게 풀어 설명하고 있어 초보자가 읽기에 그나마 적합한 네트워크 책이다.

  라는 추천 멘트를 보고 읽기 시작해서 술술 읽힐 정도로 쉬운 내용일 거라 생각 하고 봤는데 아니였다. 그래도 작년에 TCP/IP를 공부할때 해당 헤더 구조체 분석 및 세팅, 사용 방법 들을 공부 했던 경험과 의외로 전공의 통신 과목에서 본 듯한 내용들이 나와서 크게 막히는 부분은 없었다.(아마 처음 보는 사람들은 용어나 새로운 개념들 때문에 지레 겁을 먹지 않았을까 싶다) 어디까지나 크게 막힘없이 읽은 이유는 4계층 밑으로는 공부를 하긴 했었고, 해당 내용들을 외운다던지 다 알고 가겠다는 욕심을 가지고 본건 아니여서 기존에 알고 있던 용어들이 무엇인지 등등 파편처럼 퍼져 있거나 구멍나 있던 개념들이 “클라이언트 -> 서버”까지 어떻게 흘러가는지 전체적인 흐름은 깨닫게 된거 같다.(실제로도 호글님 같은 경우는 이 책으로 네트워크 공부를 처음 시작했다던데 그래서 보는게 어려웠다고 했다. 덤으로 책 좋다고 추천 +1 찍어주셨다.)
  거기다 예전부터 헷갈렸고, 인터넷을 찾아봐도 더 헷갈렸던 게이트웨이가 뭔지를 토요일에 CU의 설명 덕에 드디어 해결을 했다.(해당 책을 보게 된 이유 중 하나다) 그 외에도 같은 공유기 내 연결된 기기끼리는 ip를 통한 ssh나 기타 통신이 가능한데 외부로는 왜 불가능한지(내부망 이라는 말은 알았지만 개념이 제대로 없었다), 어릴때 게임 할때 몇몇 경우 방화벽을 풀어줘야 했던 이유, 스타 등 LAN으로 같은 인터넷을 쓰는 같은 아파트 친구랑 게임이 가능 했던 이유 등등 다양한 궁금증이 해결 됐다.
  솔직한 평을 하자면 다 읽고 나니까 좋은 책이였지만 아쉬운 점이라면 지나친 반복을 하는 부분들이 있었다는 것과 osi7계층에 대입해서 정리를 해줬으면 어땠을까 하는 아쉬움이 조금은 있다.(추가로 전이중, 반이중 같이 아예 상반된 개념이 반대로 써져있는 오타도 몇군대 있었다…)그 부분만 뺀다면 나처럼 네트워크 용어에 대해 조금은 알고 있었다던지, 시간적 여유가 되고 읽는게 쉽진 않아도 네트워크가 무엇인지 알고 싶은 사람이라면 추천을 해 드리고 싶다. 혹은 어렵게 느껴진다면 3,4장은 빠르게 넘어가고 1,2,5,6장 위주로 읽을 걸 추천 하고 싶다.

• 위와 같은 이유로 아쉽게도 톰캣 책은 아직 읽지를 못해서 자기 전에 좀 읽다가 자야겠다. 거기다 월요일도 톰캣 책을 읽을까 싶었지만 수,목에 모임도 참석해야 하고 해서 일단은 다시 실습으로 돌아가고 시간 날때 틈틈히 봐야겠다.

• 코드스쿼드에 토요일 알바(?)로 공부하러 오시는 호글님과 대화하는 도중 HTTP Chunked Encoding이란 것이 나왔다.(면접때 물어봤다 하더라, 실제론 한번도 사용하지 않고있다지만…)그래서 급 궁금해서 찾아봤는데 데이터를 보내는 시점에 아직 데이터의 총 크기를 모르는 상황에서 쓴다는 개념인건 알겠다. 근데 그래서 어디서 사용하는지 오리무중이다.(요즘 하드웨어 스펙들을 고려하면 동적 페이지를 생성하는데 그렇게 오래 걸릴 일이 있을거 같진 않다. 만약 그런일이 있으면 그건 서비스 자체를 잘못 만든 경우일 것 같고..) 호글님과 추가적으로 얘기하다가 동영상 스트리밍 같은데 쓰이지 않을까 얘기가 나왔지만 다시 생각해보니 과연 그럴까 싶기도 하고, 실제로는 잘 안쓰이는 스펙 중 하나가 아닐까 싶다.

• 장고 강의를 두달 정도 걸쳐서 천천히 본거 같다. 6시간짜리 강의를 그렇게 봤으니 솔직히 제대로 봤다고는 못하고 장고로 무언가를 만들어 보라하면 인터넷에서 좀 찾아보면서 만들어야 할 거다. 하지만 내가 목표 했던건 “장고가 뭐지?”였지 장고로 무엇을 해보자는 아니였으니 충분히 목표는 이룬거 같다. 왜 빠르게 서비스를 만들때 자바 &스프링이 아니라 파이썬&장고를 사용하라고 하는지 알 것 같다. 장고가 참 많은걸 지원해 준다. 언어자체도 파이썬이 사용하기 편하고 말이다. 하지만 쉽게 제공해주는 만큼 이것도 정말 제대로 만들려면 많은 공부를 해야겠구나 싶다. 쉽게 제공해주는 만큼 제대로 모르는 상태서 쓰기도 쉽고, 일반적이지 않은 세부 세팅들을 바꿀 일이 있으면 그게 가능한 사람이나 정보를 찾기가 쉽지 않을거 같다.(일단 국내 기준에 단순히 내 추측) 현재 자바쪽을 공부하고 있어서 그런지 장고를 경험 해 본것은 좋은 경험이였지만 당장은 지금 이상의 큰 흥미는 안 생기는거 같으므로 현재로선 장고 공부는 여기까지 일것 같다.

• 수강 완료 강의가 하나 더 늘었다!
  
  늘리는 것도 좋지만 나는 하나씩 정복(?)해나가는 기분이 더 좋은거 같다. 그래서 다행히도 스팀에도 아직 돈은 많이 안썼다.

내일 할일

• (일단은)MVC 프레임워크, JDBC 라이브러리 시작