글쓰는 개발자

요즘 하던 일을 정리하느라, 너무 바쁜 나날을 보내고 있는데 그 덕에 포스팅 주기가 엿가락처럼 너무 늘어지게 됐네요. 될 수 있으면 1주 1포스팅 정도는 지키고 싶었는데...라는 안타까운 마음을 서두로, 이번 포스팅을 시작해보도록 하겠습니다. 이번 도서리뷰도 리액트 책의 리뷰다. 일전에 했던 리액트 관련 도서리뷰(생활코딩! 리액트 프로그래밍)가 입문자를 위한 도서였다면 이 책은 입문자보단 한 단계 더 나아간 사람들이 읽기 좋은 도서라는 느낌을 강하게 받았다. 여기서 왜 한 단계 더 나아간 사람들, 이라는 표현을 썼냐면 이 책에서 설명하고자 하는 리액트에는 함수형 프로그래밍에 대한 저변이 짙게 깔려있기 때문인데 실제로 책의 목차를 보면, 아래와 같이 초반부를 구성되어있다. 01. 리액트 소개 02. 리액트..

특히나 요즘엔, 이상하리만큼 알고있던 지식들의 뿌리를 뒤흔드는 일이 종종 생기는 것 같다. 가령 예를들어 일전에 썼던 [CSS] opacity는 reflow가 발생 안 한다구요...? 포스팅과 같은 일 말이다. 이번 포스팅도 그와 비슷한 맥락에서 출발한다. Vue는 MVVM 패턴과 관련이 없다, 라는 명제에 대한 증명을 위해서. 0. 이 명제의 출발점 시작은 언제나 사소하다. Vue.js 공식 Doc에 나와있는 한 문장으로부터 출발한다. Vue.js와 MVVM패턴은 관련이 없고, 그저 부분적으로 영감을 받았을 뿐, 이라는 이 문장. 오피셜 사이트에 그렇다는데...뭐, 더 할 말이 있겠는가. 1. 그렇다면 왜 나는 Vue.js가 MVVM이라고 생각해왔는가. 자, 그럼 나는 왜 Vue.js는 MVVM 패턴이..

도서리뷰라고 글을 쓰기 시작했는데, 어째 서두가 더 길어져버린 이상한 포스팅 무언가를 배우고자 할 때, 보통 사람은 2가지로 나뉘게된다. 이론은 일단 겪으면서 깨달아가겠다는 실전파와 실천에 앞서 이론부터 탄탄해야한다는 이론파. 둘 중 어떤 방식이 더 뛰어나다, 라고는 누구도 말 할 수 없지만 적어도 나한테는 어떤 방식이 더 좋은가, 라고 묻는다면 대답은 쉽다. 나는 아래에서부터 쌓아올려가는 이론파기 때문이다. 어쩌면, 글 쓰는 걸 좋아하고 읽는 걸 좋아하는 성격탓인지 좀 더 실전보다는 먼저 읽고 쓰며 머릿속에 넣어둬야 마음이 편하다. 그런 입장에서, 어떤 이론 혹은 스킬들을 받아들이고 활용해야할때마다 부딪히는 하나의 벽은 무엇을 보고 공부할 것인가, 이다. 혹자는 공식 문서, 혹은 공식 사이트를 통해서 ..

이 포스팅은 사실 [javascript] var가 let보다 빠르다...? 포스팅을 쓰던 중에, 부가설명이 필요해서 var과 let, const에 대한 내용을 별첨으로 정리하던 내용인데... 이게 또 쓰다보니 제법 길어져서 별도 포스팅으로 발행하게 되었습니다. 0. javascript에서 변수를 선언하기 아이들이 마음껏 뛰어놀 수 있는 놀이터처럼, 컴퓨터로 동작하는 모든 시스템은 메모리라는 놀이터에서 뛰어놀게 된다. 이 놀이터에서 뛰어놀기 위한 값들은 메모리의 한 켠에 적재되고, 적재된 값을 가리키는 변수 혹은 상수를 활용해서 개발자들은 시스템을 구축하게 된다. Javascript도 당연히 변수를 정의하는 키워드가 존재한다. ES6(2015)가 공시된 2015년 이전에는 var이라는 하나의 키워드만 존재..

0. var가 let보다 빠르다고들 한다. 모 프로젝트로부터 헬퍼 요청이 있어서 2주 정도 단기로 투입됐을 때, 코드를 분석하며 의아했던 점 중에 하나는 대부분의 변수가 var로 선언되어있다는 것이었다. 코드를 살펴봤을 때, let을 두고 var를 사용할 이유가 없어보였기에 해당 로직을 개발하신 분께 여쭤봤더니 아래와 같은 답변을 들을 수 있었다. "var가 let보다 빨라요" 사실 당시엔 그런가보다, 하고 넘겼다. 왜 var가 let보다 빠르다는건지에 대한 설명이 부족했지만, 오픈직전의 프로젝트에 헬퍼로 투입된 입장에서 이미 동작하고 있는 로직의 변수선언을 왜 var로 했는지 리뷰하며 수정을 요청드릴 정도로 정신머리가 있지는 았았다. ...물론, 급할수록 돌아가랬다고 변명이다. 개발자로써 직무유기랄까...

문제점 사실 이 부분은 에러라기보단, 아래와 같이 Warning의 레벨이라서, 고치지않아도 node.js 서버의 기동이나 개발시엔 이슈 될 일이 없긴한데... 매번 서버 기동시마다 보이니까, 늘 찝찝한 건 어쩔 수 없다. 해결법 보통 node.js에서 Module not found와 같은 키워드로 시작하는 이슈는 1. 그 npm 패키지 파일이 설치되지 않았거나 2. import하고 있는 대상 파일이 없거나. 이 둘 중에 하나로 수렴하는데, 해당 Warning 메시지 같은 경우에는 2번사항이었다. 해결법부터 설명하자면 ./node_modules/moment/src/lib/locale/locales.js 파일의 코드를 아래와 같이 수정해주면 된다. try { oldLocale = globalLocale._a..

목차 1. ES11문법을 위한 babel의 최신화(Hi, Unexpected token, bye!) 2. polyfills는 Default를 가지고있다. 3. core-js 3 라고 왠만하면 명시하자. ...그리고 -1. 별첨. es6? es7? ㄴㄴ es! 1. ES11문법을 위한 babel의 최신화(Hi, Unexpected token, bye!) 문제점 현재 프로젝트에서 사용하고 있는 컴포넌트의, 새버전이 릴리즈되어 현장에 적용하려하였는데... 아래와 같은 에러 로그를 만나게 되었다. Module parse failed: Unexpected token Unexpected token 이라는 에러는 보통, Javascript 문법을 잘 못 썼거나 컴파일 단계에서 babel이 이해하지 못 하는 구분자(t..

0. 왜 이 포스팅을 쓰게되었는지에 대하여. 이 포스팅은 계획에 없던 포스팅이다. 사실 CSS Triggers에 대한 포스팅은 저번 포스팅으로 끝내려고 했었다. 근데 왜 또, 포스팅을 작성하고 있냐...면, 사실 내가 숱한 기술 블로그 포스팅들을 보면서 답답했던 부분이, 왜 이론은 엄청 방대하고 자세하게 설명들을 하면서 쉽고 직관적이며 이해하기 쉬운 예제는 잘 안 넣어두시는 걸까, 였었다. 그래서 예시가 있으면 이해가 더 쉬울 것 같은 포스팅에는 그때그때 예시를 될 수 있으면 넣으려고 하는데...그래서 저번 포스팅이었던 [CSS] CSS Triggers 에서도 역시나, CSS Triggers에 대한 쉬운 예제 코드를 넣으려 했었다. 근데 아뿔싸, 예상치 못 한 현상을 봐버린거다. CSS Trigger 그..

0. Rendering Pipeline 브라우져는, HTML을 어떻게 해석해서 우리의 눈에 버튼과 텍스트 필드와 아이콘과 테이블과, 지금 읽고 있는 이 글을 보여주게될까? 보통 이에 대한 설명을 단순하게는 'HTML을 해석해서 보여준다'라고들하지만, 순차적인 단계의 입장에서보면 대략 아래와 같은 절차를 거치게된다. 위 그림은 크로미움에서 사용하는 Blink의 렌더링 엔진에서 제공하는 그림이다. 브라우져 별로 사용하는 렌더링 엔진은 다 다르지만, 대부분 위와같은 프로세스에서 크게 벗어나지 않는다. * 브라우저별 Rendering Engine Blink : 크롬, 신형 Edge Gecko : 파이어폭스 WebKit : 사파리 Trident : IE EdgeHTML : 구형 Edge 1. 화면의 요소는 언제든..

기억도 나지않는 어느 날엔가, 누군가 내게 제목과 같은 질문을 했다. "Javascript의 Class도 호이스팅이 되나요?" 그리고 내가 답했다. "네, Class도 당연히 호이스팅 됩니다." 그러자 질문자가 되물었다. "하지만 아래와 같은 코드는 에러를 뱉는걸요?" var foo = new Foo(1, 2); //ReferenceError class Foo { constructor(x, y) { this.x = x; this.y = y; } } "네, 에러를 뱉겠죠. Foo class의 선언보다 사용이 앞섰으니까요." 0. 누구에게나 처음은 있다. 위의 일화가 본 포스팅을 작성하게 된 이유다. 아마도 Javascript를 시작하는 길목에서 처음 호이스팅이라는 개념을 이해할 때면, 우리는 아래와 같은 ..