항상 충실하게

1.  사실

1) 코드숨 과제를 진행함

2)TIL을 2번진행함

3)영속성 컨텍스트에 대해 공부함. 특히 컨텍스트에 대해 공부함

4)에러메시지를 보는 법을 익힘

5) 성공하는 프로그래밍 공부법이라는 책을 읽음.

6)카카오코테를 봄

2. 주관 

1) 카카오코테 --> 못넘을 산은 아닌거 같음

2) 내가 스프링에 대해 좀 더 잘알고있었다면, 좀더 양질의 피드백을 받을 수 있을텐데 아쉽다.

3)모르는게 생기면 자꾸 파보려고 한다. 나쁜건 아니지만, 시간과 기회라는 측면에서 충분히 효율적으로 운용하지 못하는 듯한 느낌이 든다.

4) 사실 회고의 가치는 4. 확언에 대한 피드백으로서 작용하는 것이 중요한 것같다는 생각이듬.

정성들여 쓴 확언, 그리고 그에 대한 계획에 따라 세밀한 자기객관화 및 피드백이

더 나아질 수 있는 사람이 될 것같다.

5) 결국 좋은 프로그래머가되려면 많이 알아야하고, 많이 코드를 쳐봐야하고, 많이 피드백을 받아야할 것이다. 그런데 너무 전자에만 매몰되다보니까 약간 노잼+ 의욕저하가 되는 것 같다. 물론 3주차,4주차 보단 나아졌지만..

3. 배운점

컨텍스트에 대하여.

- 일반적 의미: 그냥 텍스트처럼 바로 이해되는 것이 아니라, 다르게 해석될 여지를 주는 정보 및 환경

- 컴퓨터과학적 의미:  멈추고 새롭게 시작될때, 반드시 저장되어야하는 정보들의 최소단위 집합.

ex. 영속성 컨텍스트:

데이터베이스 영속성과 관련된 특별한 컨텍스트를 의미.

영속성 컨텍스트는, 데이터베이스에서 읽거나 할때 캐쉬처럼 작동하기도 한다.

4. 확언

1) 다음주 커리큘럼은 로그인이다. 로그인에 대해, 다음주 회고시 의미있는 배운점을 쓰도록한다.

2) 하루에 7시간은 코드를 치는데 투자한다. 시간을 기록하고 매일 그 것을 달성했는지 확인한다.

3) 지레 겁먹고, 미리 정보를 찾아보기전에 먼저 부딪히고 막히면 찾아본다.

4) 코딩은 신기하고 재밌는 것이다. 모르는 것을 알아가는 재미, 만드는 재미를 놓치지 말자.

4. 확언

발단

이전에 프로젝트를 했을때, 왜 seriallizer를 사용하는지 몰랐다.

굳이 사용해야 싶나 했는데, marshmallow같은 라이브러리까지 있는거보면 필요성이 분명히 있으리라 생각하고 찾아보게 되었다.

전개

은근히 바로 안나왔는데, 그래도 결국 quora에서 찾았다.

https://www.quora.com/Do-I-really-need-serializers-in-Django-Rest-Framework-app

결

 custom code의 양을 줄여준다.

serializer 없이 한두개 정도는 일일히 작성할 수 있지만, 현업에서 대량의 api를 만들어야 하는 경우, 이는 많은 노력이 들어가고 수정보완하기 까다롭게 된다.

발단

네트워크를 공부하다보니, 이 과목은 약간 통신규약을 배운다는 느낌을 접근해야겠다는 생각이 들었다.

그러면, 어떡하다가 그러한 protocol이 탄생하게 됐는지 궁금해졌다.

전개

TCP 개발동기는 나무위키에 잘나와있었다.

그런데 혹시 몰라서 팩트체크를 위해서 영어자료도 찾아봣는데, 아주 틀린정보는 아닌것 같다.

https://namu.wiki/w/TCP

https://en.wikipedia.org/wiki/Bob_Kahn

이 할아버지는 TCP를 만든 사람중에 하나인데, TCP를 만들 당시 DARPA(미 국방부 고등연구원)에서 일한 경력이 있다.

결

미국 국방부가 관심을 갖던 것은 핵전쟁이 발발하더라도 정상적으로 작동하는 네트워크이다.

TCP이전 일반적으로 사용하던 통신방식은 회선교환(circuit switching)인데, 이는 특정 경로만을 설정해서 전달하는 방식인거다.

따라서 특정 경로가 폭격에 바갈나면 통신이 끊어진다.

이에따라 패킷교환방식을 사용하게 되었는데, 이는 데이터를 패킷단위로 나누어, 여러 경로들을 거쳐서 전달되게 된다.

다만 이는 네트워크환경의 안정성이 떨어진다는 단점이 있다. 왜냐하면 모든 패킷이 안전하게 도착한다는 보장이 없기 때문이다.

이에 따라 신뢰성을 보장하기 위한 TCP 방식이 탄생하게 되었다.

1.  사실

1. 코드숨 과제를 완수하지 못했다. 
2. spring인강을 듣고, 책을 보았다.
3. 객체지향에 대한 사실과 오해라는 책을 보았다.
4. 최단거리 알고리즘에 대해 학습하였다.
5. 함께자라기라는 책을 읽었다.

2. 느낌 & 생각들

1. 학습프레임과 실행프레임 중에서 학습프레임에 있어야하는데, 실행프레임에 있었다. 자라기(growing)에 초점을 맞추어야하는데, 잘하기에 촛점을 맞춘것이 아쉽다.
2. 어차피 한번에 이해 못한다. 그냥 코드치고, 공부하다보면 언젠가 이해하게 되는날이 올거다. 일단 다른분들거를 참조해서라도 완성하자. 그리고 회고를 하고 다시 쳐보는식으로하자.
3. 쫄지말자. 틀리면 머어떻누. 피드백해주시는 분들 다 도와주려고 있는분들이다.

3. 배운점

1.  롬복을 사용할 수 있다.

2.  객체지향에 대해 예전보다 조금 더 잘 설명할 수 있다.

4. 확언

1.  화요일까지 무조건. 과제 어느정도 완성해서 올리도록 하자.
2. 지난주에 til 3번정도했는데, 이번엔 5번하자.

발단

docker에 대해 공부하다가, Yaml 파일 형식에 대해 처음 접하게 되었다.

그런데 문득 왜 yaml파일이라는 것이 생긴거지?라는 생각이 들었다.

전개

인터넷에 검색해봤는데, yaml파일을 만들게 된 이유에 대해서는 설명이 없었다.

그래서 yaml 공식문서에 있는 사람에게 메일을 보내 물어보기로 했다.

https://yaml.org/spec/1.0/#id2488873

결론

오렌은 친절하게 답변을 해줬는데, 답변내용은 아래와 같다.

2004년 당시 어떠한 프로그래밍 언어에서도 사용 가능한 data structure를 de/seriallizing 가능한 포맷을 찾고 있었다.

그런데 그때 당시 XML은 이것이 불가능햇고, 우리가 새로 만들게 되었다.

+ 궁금했던 것.

1. Yaml의 장단점은 무엇인가?

장점: 주석 사용가능, 한글을 그대로 사용해도됨

단점: 개행, 공백으로 블록 인식. 이에 따라 한줄로 작성 불가함.

(사실 이는 단점이라기보다는 특징에 가까운 것 같다.)

https://yaml.org/spec/1.2-old/spec.html#id2759572

공식문서에 따르면, JSON의 최우선 디자인 목표는 간단함과 보편성이고 이에 따라 가독성을 조금 포기하는 대신에 생성과 파싱이 용이하게끔 한것이다.

반면에 YAML의 최우선 설계 목표는 가독성과 데이터구조 serialization이다. 따라서 가독성이 매우좋지만, 생성하고파싱하는데 약간 더 시간이 걸린다.

2. Yaml을 restful api에서 데이터 전송형식으로 쓸 순 없을까?

일단 앞서 언급했듯이, json이 좀더 생성과 파싱에 용이하다.

그리고 yaml은 공백으로 구분하는데, 이것은 json파일보다 크게 만들고, json보다 복자하다.

그리고 브라우저들은 json을 natively 제공한다 

하지만 위와 같은 복잡한 구조 떄문에 configuration file로는 yaml이 적합하다.

https://www.quora.com/Why-isnt-YAML-used-instead-of-JSON-for-the-web-as-its-easier-to-read-for-both-humans-and-machines

https://www.quora.com/Will-YAML-replace-JSON

https://stackoverflow.com/questions/1726802/what-is-the-difference-between-yaml-and-json

발단

필자는 경제학도이다. 경제학은 대부분 이미 존재하던 경제현상들을 해석하는 과정에서 발달한 학문이다.

예를 들어 가격이 오른다. --> 수요가 많아져서 그런것이다. 이런 식이다.

그러다보니 이 이론이 왜 나왔는지 딱히 따질 필요가 없다. 

그런데 경제학도로서 컴퓨터 공학을 접하다보니, 도대체 이게 왜 생긴거지? 라는 의문이 드는게 너무 많았다.

전개

사실 이는 너무 당연하다. 

왜냐하면 컴퓨터 과학의 대부분은 이미 있었던 현상에 대한 답이 아니라, 개발자들과 컴퓨터과학자들이 맞닥뜨린 문제에 대한 해결책들을 모아놓은 것이기 때문이다.

예를 들어, 에니악 시절부터 프로세스 쓰레드가 존재하지는 않았을 것이다.

컴퓨터가 발전하다보니, 프로세스가 필요하고, 쓰레드가 필요하니 탄생한 것이다.

사실 그래서 운영체제를 공부하다보면, 약간 한정된 자원안에서 최선을 이끌어내기 위한 컴퓨터과학자들의 분투가 담겨있는 과목같아서 약간 감동적이기 까지 했다.

결

나의 궁금증을 해결하기도 하고, 추후 내가 맞닥뜨릴 문제들의 힌트를 얻기 위해서.

이 시리즈를 작성하고자 한다.