과거의 내가 미래의 나에게

지난 글에서는 자료구조에 대해 훝어봤다. 하지만 개념 하나하나를 구글링으로 검색하며 공부했기 때문인지 전반적인 흐름을 파악하는 데 아쉬움을 느껴서 이번 주에는 책방을 들러 자료구조 관련 책을 여러 권 살펴보았다. 많은 책이 있었지만 내가 고른 것은 "그림으로 배우는 알고리즘"이란 책이다. 많은 자료구조 책이 자료구조의 종류에 대해 깊게 설명하거나 많은 예시를 통해 다양한 학습을 유도하는 스타일로 이루어져있는데, 내가 원하는 것은 디테일이 아닌 전반적인 흐름을 파악하는 것이었다. 그리고 내가 고른 이 책이 데이터-자료구조-알고리즘의 구성으로 프로그래밍 기초의 흐름을 쉽게 설명해주고 있었기에 많은 공부가 되었다.오늘은 이 책을 읽으면서 느낀 점과 익힌 내용을 정리해보려한다. 데이터, 자료구조 그리고 알고리즘..

시작은 vue의 반응형 원리를 공부하기 위함이었다. vue의 반응형 코드가 어떤식으로 구현되어있는지 공식문서와 영상을 시청하다가 map, set, weakmap, weakset 같은 것을 쓰는 것을 보았다. 몰랐던 것은 아닌데 따로 공부한 적은 없으니 잘 알지 못했고 그에 따라 거의 사용하지 않았던 것이다. 내 작업사항에는 데이터 가공이 상당 수가 있음을 상기하고 반응형보다는 먼저 위와 같은 자료구조를 공부할 필요성을 느껴서 오늘은 자료구조에 대해서 전반적으로 살펴보았다. 자료구조란? 사실 map, set 이런 애들이 자료구조라는 것도 이번에 처음 알았다. 자료구조와 알고리즘. 많이 들어봤고 프로그래머로써 필수지식이라고는 하는데 솔직히 잘 와닿지 않아 등한시하였던 것 같다. 그러나 이번을 계기로 이것저것..

axios를 사용하다가 문득 axios는 어쩌다 나온 라이브러리인지 궁금하게 되었고 이에 대해 거슬러 오르다가 HTTP의 발전과정에 대해서 전반적으로 살펴보게 되었다. 늘 그렇듯 하나의 궁금증이 산을 넘고 넘어 요상한 방향으로 결론나게 되었는데..이 글도 비스무리하게 HTTP 요청 라이브러리에 대해 알아보려다가 HTTP의 성장 과정에 대해서 알아보는 글이 된 것 같다. 이제부터 HTTP가 어떤식으로 성장하고 발전해나갔는지를 알아볼 것인데 HTTP가 등장하게 된 모체인 웹의 역사와 결부되어서 이야기해나가야 할 것이다. 웹의 시작 그리고 HTTP의 탄생 웹의 시작에 대해서는 다른 글에서 썼으니 간단하게 짚고 넘어가도록하자. WWW, 그러니깐 웹이 탄생한 이유는 연구문서나 대학문서들을 저장해서 그것들을 언제 ..

상태코드가 다 끝나지 않았지만 일단 HTTP 메소드에 대해 글을 쓰는 이유는... 프로젝트를 하다가 이번에 같이 작업하시는 백엔드 분이 RESTful한 API를 작성하시기에 이를 사용하다가 REST한 API의 근간이 되는 HTTP 메소드에 대해 얼른 미리 공부해봐야겠다 생각해서 잠시 상태코드를 멈추고 정리를 해본다. HTTP 메소드란 HTTP에서 사용되는 요청 방법을 나타낸다. 즉 클라이언트가 서버에서 이루어져야 할 동작을 지정하여 요청을 하는 방법이다. 동작에 대한 뚜렷한 의사표시가 있기에 특정 리소스를 서버가 어떻게 다룰지 명확해지기에 웹의 동작을 예측 가능하고 효율적으로 설계할 수 있게 된다. HTTP 메소드는 총 9개가 존재하지만 자주 쓰이는 것은 5개정도 뿐이다. 1. GET: 리소스를 조회를 ..

우리 팀은 현재 프론트엔드의 마이그레이션이 진행중이다. 우리 팀 중에서 프론트를 맡고있는 내가 이 마이그레이션에 관련된 모든 스택을 정했는데, 지금 정한 이 스택이 정말 맞는 길인지 아직도 불안에 떨고 있었다. 내가 정한 스택인데 왜 불안할까 생각해봤더니 이 스택으로 정한 이유를 명확히 설명하지 못하기 때문인 것 같았다. 따라서 시간을 왜 내가 기존의 vue2 환경에서 vue3으로 스택을 정하게 되었는지 글을 써보며 내 마음을 다져볼까 한다. 마이그레이션의 시작 우리 팀은 vue2 환경으로(그 당시에는 그냥 vue였겠지만) 프론트를 구축하였다. 제품이 처음 탄생할 당시에는 프론트를 전념하는 개발자는 없었고 그저 세상 모든 것을 개발할 줄 아시는 개발자가 최소한의 프론트를 만들었다고 한다. 왜 vue2를 ..

저번과 마찬가지로 요새 글 쓸 시간이 많이 없어서... 오늘도 300번대 상태 코드만 알아보고 글을 마무리할 것 같다. 3xx (Redirection): 요청을 완료하기 위해 추가 동작이 필요함 300번대 상태 코드는 리다이렉션을 나타내며 이는 클라이언트의 리퀘스트를 완료하기 위해서는 클라이언트가 요청한 리소스가 다른 곳에 있다던가, 서버가 요청을 처리하기 위해 추가 동작이 필요한 경우 등 리퀘스트가 정상적으로 처리를 종료하기 위해 브라우저 측에서 특별한 처리를 수행해야 할 때 사용된다. ■ 300 (Multiple Choice): 요청에 대한 응답이 하나가 아닌 둘 이상일 때를 나타낸다. 클라이언트가 HTTP 요청을 하였는데 해당 요청이 하나의 리소스가 아닌 둘 이상의 리소스를 가리킬 때, 서버는 그 ..

이번에는 저번 시간에 이어 200번대 상태 코드를 알아 볼 것이다. 300번대까지 한꺼번에 작성하고싶지만 처리해야할 다른 일이 많아서 오늘은 짧게 가야할 것 같다. 2xx (Success): 요청이 정상적으로 처리됨 클라이언트의 리퀘스트를 정상적으로 처리했다는 뜻이다. 단순히 성공했다고 알리는 것 뿐 아니라 어떠한 행위가 성공했는지에 대한 정보가 나타나있으니 잘 구분해서 보자. ■ 200 (OK): 서버가 클라이언트의 요청을 성공적으로 처리하였을 때의 응답 코드이다. 어떤 HTTP 메소드가 사용되었냐에 따라 성공의 의미가 달라진다. * GET: 요청한 리소스를 불러와서 메시지 바디에 전송 완료 * POST & PUT: 요청한 수행 결과로 나온 리소스가 메시지 바디에 전송 완료 * DELETE: 삭제 완료..

클라이언트가 서버에게 리퀘스트를 보내고 그 결과가 어떻게 되었는지 코드로 알려주는데 이를 상태코드라고 한다. 상태 코드는 3자리 숫자와 설명으로 나타내며 숫자의 첫 번째 자리는 상태 코드의 클래스를 의미한다고 한다. 상태 코드의 클래스는 5개로 정의되어있고 클래스의 정의만 지켜진다면 정의된 상태 코드를 변경하거나 독자적으로 상태 코드를 만들어도 상관없으니 너무 얽매일 필요는 없을 것 같다. 1. 1xx (Informational): 요청을 받아들여 처리중. 임시 응답으로 HTTP 1.1버전부터 추가되었다. 2. 2xx (Success): 요청을 정상적으로 처리했음 3. 3xx (Redirection): 요청을 완료하기 위해서 추가 동작이 필요 4. 4xx (Client Error): 요청의 내용이 잘못됨..