이 글은 자바스크립트로 처음 프로그래밍을 입문한 자바스크립트 개발자들을 위한 글 입니다. 자바스크립트가 세상에 나온 1995년과 2019년 현재의 웹 생태계는 너무 많이 변했다. 아래는 1998년도 유튜브와 2019년 현재 유튜브 서비스를 캡쳐한 사진이다. 시간이 지남에 따라 서비스들은 이용자들에 입맛에 맞추기 위해 점점 더 복잡해지고 보다 고도화된 대화형 인터페이스를 취하고 있다. 보기만 해도 소름 끼치게 많은 요소들의 인터랙션은 생각만 해도 고개를 젓게 한다. 더 나를 소름 끼치게 하는 것은 이 요소들의 구현은 모두 동적 타이핑으로 이루어진다는 것이다. 이전에는 간단하게 애니메이션 정도만 넣는 시대에서 현재는 모든 웹 어플리케이션들이 SPA 형태로 개발되고 있다. 흔히 우리가 프론트엔드 3대장이라 칭하는 Angular, React, Vue 이 세개의 프레임워크 모두 SPA 형태로 애플리케이션이 구성된다. 라우팅, 상태 관리, 많은 부류의 컴포넌트들로 인해 프론트엔드의 복잡성은 이전 시대와는 차원이 다르다. 또한 현재의 자바스크립트는 프론트엔드 개발 환경에만 국한 되어 있지 않고 백엔드 영역까지 개발할 수 있기에 그 범위에 복잡성은 비교 불가하다. 백엔드가 무슨 말인가, 게임 개발 윈도우 프로그래밍 등 자바스크립트가 사용되는 범위는 매우 넓다....

Problem 상근이는 자신의 결혼식에 학교 동기 중 자신의 친구와 친구의 친구를 초대하기로 했다. 상근이의 동기는 모두 N명이고, 이 학생들의 학번은 모두 1부터 N까지이다. 상근이의 학번은 1이다. 상근이는 동기들의 친구 관계를 모두 조사한 리스트를 가지고 있다. 이 리스트를 바탕으로 결혼식에 초대할 사람의 수를 구하는 프로그램을 작성하시오. 첫째 줄에 상근이의 동기의 수 n (2 ≤ n ≤ 500)이 주어진다. 둘째 줄에는 리스트의 길이 m (1 ≤ m ≤ 10000)이 주어진다. 다음 줄부터 m개 줄에는 친구 관계 ai bi가 주어진다. (1 ≤ ai < bi ≤ n) ai와 bi가 친구라는 뜻이며, bi와 ai도 친구관계이다. 첫째 줄에 상근이의 결혼식에 초대하는 동기의 수를 출력한다. Comment 자신의 친구와 친구의 친구 를 초대할 수 있다는 조건만 성립하면 된다. 아래 예제 인력을 보를 보면 어떤 친구들이 이 조건에 해당 되는가? 6 5 1 2 1 3 3 4 2 3 4 5 그렇다. [2, 3, 4] 이다 (2,3 은 상근이의 친구고 4는 상근이의 친구의 친구다.) 이 외 5와...

이 문서는 PageCall Console 을 개발하면서 인프라 구성이 귀찮았던 개발자 우 모씨가 Lambda, API Gateway, Cloud Formation 등의 AWS 리소스를 활용해 Serverless Architecture 를 구현 하면서 인프라 구성이라는 귀찮은 굴레 속에서 벗어나 코드 본연의 집중할 수 있었던 경험을 공유하고 있다. 뭐가 그렇게 귀찮아 ? 제품을 생산하고 배포하고 유지하는 과정을 높은 가용성과 확장성 있게 구성하는 것은 매우 중요한 일인 반면 꽤나 귀찮은 일이기도하다. 더욱이 자원이 한정적인 소규모 그룹의 경우에는 관리 포인트가 늘어남에따라 퍼포먼스 이슈 또한 배제할 수 없는 걸림돌이 된다. serverless architecture 는 이러한 문제를 해결 할 수 있는 좋은 솔루션이다. 위 과정 중, 개발자에게는** 생산에만 집중할 수 있도록 도와주기 때문**이다. 이로써 개발자는 코드 본연에 신경쓸 수 있기에 비약적인 생산성 향상과 높은 품질의 제품을 생산할 수 있다. 그전까지 나는 위의 모든 과정을 수행해야했다. 대표적으로 우리의 서비스 PageCallAPI(이하 PCA) 의 배포 과정을 한 사례로 들어 수고스러움을 얘기해보겠다. 기본적으로 PCA 배포과정에서는 “Codedeploy”, “Elastic Load Balancer(이하 ELB)”, “Auto Scaling Group(이하 ASG)”, “S3” 등의 리소스를...

S3에 파일 업로드 또는 다운로드 하는 행위에 대해 통상 우리는 서버를 경유해서 진행한다. 경유하는 이유는 AWS는 이러한 행위에 대해 인증 정보(Access Key, Secret Key)를 필요로하는데 이 정보는 외부에 노출이 되면 안되기 때문이다. 하지만 이러한 방법은 매 요청 마다 서버의 자원을 소모하기 때문에 트래픽이 많은 서버스의 경우 다소 부담스러울 수 있을 뿐만 아니라 전송되는 속도 또한 해당 경유 서버에 제약을 받기 때문에 퍼포먼스 이슈 또한 초례할 수 있다. 이때, AWS Signature 를 통해 파일 관리를 한다면 이러한 부담에서 상대적으로 벗어날 수 있다. 또한 이와 같은 방법은 클라이언트에서 주도적으로 S3 리소스를 활용할 수 있기에 제약사항을 두지않고 좀 더 자유롭게 시스템을 구축 할 수 있다. 그러나 이 방법으로 인해 꼭 서버가 불필요한 것은 아니다. 이 문서에서 담고자하는 내용에서는 별도의 Signature 서버를 필요로한다. 물론 AWS Signature 는 범용적으로 사용할 수 있기에 클라이언트 서버 둘다 사용이 가능하는므로 Signature 서버 또한 필수사항은 아니다. 하지만 Signing 서버를 두지 않고, 클라이언트가 주체가 되어 관리하는 것은 보안성 이슈로인해 본인은...

왜 생산성에 집착하는 개발자들은 모두 Vim 에 열광할까 ? 이 질문의 답은 내가 Vim을 적극적으로 사용하면서 알게되었다. 본인은 본래 Vim을 적당히 알고, 적당히 사용했다. 리눅스 서버에서 터미널 상 어떠한 값, 스크립트 등을 변경 또는 추가할때 주로 사용했는데, 이 작업에 있어 정말 최소한의 지식만을 찾아서 했다. 더 효율적인 방법을 찾아 배우려 하지 않았다. 이 작업이 본인의 일에 있어 차지하는 비중이 매우 낮았기 때문이라 핑계를 대고 싶다. Vim 을 사용했다라고 말하기 창피할 정도의 지식을 가지고 했고, 당연히 Vim에 이점 따위 당연히 모르니 아무런 감흥도 없고 오히려 불편하기 짝이 없는 도구라고 단정 지어버렸다. 이와 같은 사고를 가지고 있던 본인이 Vim 을 적극적으로 사용하게된 계기는 새로 이직한 회사로 부터의 시작이었다. 영준님! 우리 개발팀은 Vim 환경을 적극적(강제적)으로 활용하고 있어요. 그 날로 IDE에 Vim 관련 플러그인을 설치하고, vim cheat sheet 을 프린트하여 앞에두고 강제적으로 Vim 을 사용했다. (IDE 의 경우, jetbrains 사 제품군을 기준으로 하고있지만 타 제품군의 IDE 도 Vim 관련 플러그인을 쉽게 찾을 수 있다.)...

이 문서는 CodeDeploy 를 통해 배포 시스템을 구성 하면서 경험한 내용을 바탕으로 정리한 문서이다. 간략한 내용만 다루고 있으므로, 좀 더 상세한 내용을 들춰보고 싶다면 이후에 작성한 “나는 코드를 쓸테니, 너는 인프라를 맡거라.” 문서를 읽어보길 바란다. 아래는 구성 전 논의 된 지향점들 이고, 이에따라 그 때 당시 CodeDeploy 가 가장 적합해서 선택하게 되었다. 쉽고, 용이 무중단 자동화 롤백 안정성 AWS 리소스 최대한 활용 Git 서버로 Bitbucket 을 채택하여 사용하고있는데, Bitbucket 에는 파이프라인이라는 개념이 존재한다. 이를 테면 마스터 브랜치에 푸시한다고 가정하면 이에 따른 프로세스들을 기술할 수 있다. 따라서 마스터 브랜치에 푸시하면, 배포로 간주하고 배포에 따른 스크립트가 실행된다. 기본적으로 S3 의 패키지들이 업로드되고, 이후에 CodeDeploy 클라이언트를 통해 배포가 진행된다. 아래는 간단하게 작성한 위 프로세스에 대한 파이썬 스크립트 이다. from __future__ import print_function import os import sys from time import strftime, sleep import boto3 from botocore.exceptions import ClientError VERSION_LABEL = strftime("%Y%m%d%H%M%S") BUCKET_KEY = os.getenv('APPLICATION_NAME') + '/' + VERSION_LABEL + \ '-bitbucket_builds.zip' def upload_to_s3(artifact): """...

이 문서는 본인(주니어 프로그래머)이 성장에 갈증을 느끼며 작성했다. 아쉽게도 이 갈증의 해소 방법은 담고 있지 않다 왜냐하면 본인도 모르기 때문이다. 따라서 이 갈증은 본인 삶이 끝나기 전까지 계속 함께 할 것 같다. 여기서 성장 이란, 과거 보다 더 나은 현재를 가리키고 있다. 과거를 하루, 일주일, 한달 어떠한 시간의 단위로 정의 하든지 성장한 미래의 자신은 아래와 같아야 한다. 과거 구현하지 못한 내용을 완벽히 구현해 낼 수 있어야 한다. 과거 이해가 되지 않던 개념들을 자연스럽게 활용할 수 있다. 시간이 누적 될수록 과거를 가리키는 시간의 정의는 짧아야 한다. 왜냐하면 시간의 누적은 곧 지식의 누적이며 그러한 지식을 누적하는데 있어 전적으로 문제해결 능력을 바탕으로 하기에 절대적으로 향상할 것 이다. 물론 위의 가정은 본인이 매번 어려운 도전을 자발적으로 이어나가고 있는 것을 전제한다. 만약 이에 해당되지 않는다면 나는 이를 ‘성장이 멈춘 사람’이라 정의하고 싶다. 대개 프로그래머라는 직군은 본인의 공학적 지식과 기술을 통하여 문제를 해결하는 사람이라 일컫는데, 위에 언급한 성장이 멈춘 ‘프로그래머’는 지식의 한계치가 정해져 있기에 지속적으로 성장하고자하는...

근래 대용량 트래픽이나 동시성 이슈등의 관심이 생기면서 Micro Service Architecture(이하 MSA) 에 대해 학습할 기회가 생겼다. 일전에 넷플릭스, 아마존 국내 기술 기업들이 앞다퉈 MSA 를 적용하는 모습을 보며 간략하게 내용을 살펴본적 있지만 당시 실제 필요성에 대해 회의적이여서 그렇게 깊게는 들여다 보지 못한 것 같다. 본인이 머물렀던 곳은 대부분 스타트업이었고, 적은 인원으로 task 를 처리해야했기에 관리 포인트를 늘리는 수고는 지양했다. 하지만 지금와서 생각해보면 이 또한 잘 못된 생각이었다 느끼고 있다. 환경만 잘 구성한다면 적은 인원으로 충분히 소화해낼 수 있다 생각한다. 모든 개념이 그렇 듯, Micro Service Architecture 또한 갑자기 생겨난 개념은 아니다. 아주 오래전부터 이를 행에 왔던 무수한 기업이 있고 지금에 와서야 화두가 되고있다. 이와 같은 형태는 기술들의 일반화라는 순리에 맞추어 다가왔다 생각한다. What is micro service architecture Micro Service Architecture 는 단어가 모든 뜻을 나타내고 있다. 통상 전통적인 에플리케이션 개발 방식의 Monolithic Architecture 와 반대되며, 큰 모형(어플리케이션)을 잘게 쪼개어 추상화한다 생각하면 이해하기 쉽다. 어떤 형태로 추상화할까 ? 커머스를 예를 들어보자....

습관의 힘을 읽고, 습관이 인간에게 미치는 영향에 대해 인지했다. 그 후, 흔히 사회에서 말하는 성공한 사람들의 습관에 대해 궁금해졌고 그렇게 Tools of titans 을 읽게 되었다. 이 책에서 지목하는 타이탄 이란, 자신의 분야에서 최정상에 오른 사람들을 말한다. 성공, 그것은 무엇인가 ? 이 책에서 성공은 아래와 같이 정의한다. 성공이란, 당신이 그걸 어떻게 정의하든 간에 올바른 경험으로 얻어진 믿음과 습관들을 쌓아가다 보면 반드시 성취한다. 체계속에서 사는 사람, 습관을 임의로 만든 사람들이 타이탄들이다. 놀랍게도 난 이 책에서 강조하는 체계 중 하나를 내 것으로 이미 만들었었다. 바로, 일기 다. 난 매일 일기를 쓴다. 이는 내가 하루를 되돌아보면서 느낀점들과 후회 그리고 미래지향적 내용들을 담고있다. 내 자신을 좀 더 직관적으로 바라보는 거울 로써 나는 일기를 사용한다. 이는 그들이 말하는 내용과 일맥상통하다. 일기 이외에도 타이탄들은 여러 습관들을 삶 속에 반영하고 있다. 그들의 사고를 통해, 여러 습관들을 유추해 볼 수도 있다. 타이탄들은 여러 주제의 조언들은 이 책을 시간 가는 줄 모르고 있게 해주었다. 항상 성공한 사람들의 조언은 달콤하다....

Reactive Programming 에 대해 선행된 내용이 없으시다면 이 문서를 참고해보시는건 어때요 ? 이 문서를 이해하는데 좀 더 도움이 되실거에요. 이 문서에서는 RxJS 를 통한 Reactive Programming 에 대해 말하고있습니다. 큰 맥락에 대해서 얘기하고 있으며, 추후 상세 내용들을 잘게 나누어 연재를 하고자 합니다. 큰 맥락이라하면, RxJS가 무엇인지 그리고 주요 특징들과 이를 활용한 간단한 예제들을 간략히 담고 있습니다. 문서 내 References 을 항목을 참고하시면 학습에 있어서 좀 더 도움이 되실거에요. 이벤트 기반의 비동기 처리 프로그래밍 방식이 낯설거나 방대한 API로 인해 learning curve 가 다른 라이브러리와 비교했을 시 좀 더 발생할 수 있습니다. What is RxJS RxJS is a library for reactive programming using Observables, to make it easier to compose asynchronous or callback-based code. Observable Sequences 와 표현력있는 쿼리 연산자를 사용하는 비동기적, 이벤트 기반의 프로그램을 구성하기 위한 라이브러리입니다. 즉, Reactive Programming 을 위한 MS 제공하는 Reactive Extension 중 JavaScript 라이브러리입니다. 이로써 이벤트 스트림과 데이터를 일관성있고 쉽게 다룰 수 있습니다. Angular 2 에서...

Rx(Reactive Extensions) 를 다루기전, Reactive programming 에 대해 학습한 내용을 토대로 정리하여 공유합니다. Rx 의 약자로 Reactive Extensions, Reactive x 둘 다 맞습니다. (Historically, Reactive Extensions. Recently, Reactive x. So, both are correct) 따라서 이 문서에 Rx의 glossary 는 Reactive Extensions 으로 정의하겠습니다. 이와 같이 학습에 혼선을 주는 내용들이 많아서 조금 당혹스러웠습니다 (e.g. 리액티브 프로그래밍과 함수형 리액티브 프로그래밍과 혼동). 이 문서에서 다룰 Observable 이 Promise와 개념적으로 유사합니다 따라서 일전 작성한 Promise 글을 참고하시면 더 도움이 될 것 같습니다. What is reactive programming ? Reactive programming is programming with asynchronous data streams. You can listen to that stream and react accordingly 이 관점으로 볼 때, Reactive Programming 은 Asynchronous dataflow programming 으로도 불립니다. 애매모호한가요? 좀 더 본질에서 얘기하자면 기존의 Imperative Programming(명령형 프로그래밍)은 절차지향 적인 반면 Reactive Programming 에서는 데이터 흐름을 먼저 정의하고 데이터가 변경되었을때 연관되는 함수나 수식이 업데이트 되는 방식입니다. Reactive programming 에서는 기본적으로 모든 데이터는 흐르는 강물이라 간주하고, 그 데이터의...

회사에서 신규 프로젝트를 진행함에따라 환경, 일정 등의 요소등을 고려하여 기술 스택을 정의하게 되었다. 상당부분은 전의 프로젝트와 동일한 기술 스택을 따랐지만, 웹 프론트엔드는 생각이 조금 달랐다. 왜냐하면 당시 기존의 사용한 도구들은 너무 낙후되었고 현 시점과 너무 상이하여 오히려 퍼포먼스를 악화시켰다. 그렇다해서 새로운 도구를 선택하자니, 일정이 고민되었다. 다행히도 일정과 퍼포먼스를 다 만족하는 섹시한 Vue.js 를 만났다. 지금와서 돌이켜봐도 좋은 선택이었다 생각된다. 당시에 정말 뜨거운 감자와 같은 도구라서 안정성에 대해 의구심이 들었지만 실제 만들어진 프로덕트들을 보고 사용하고자 결정했다. 그리고 이 후에 좋은 기회가 생겨서 Vuetiful Korea 4th에서 발표도 진행하게 되었는데, 첫 발표라서 그런지 무참히 깨지고 많은 교훈을 느꼈다. wording 마다 설명 텍스트를 추가했는데, 발표할때 텍스트가 나오지 않아서 wording 만 보고 얘기를 풀어나갔다. 어떻게 끝났는지도 모르겠다. 본래 내성적인 성격도 있고, 낯가림도 심한편인데 이때 절정에 다다른 것 같다. 질문도 몇차례 받았는데, 제대로 답변할 수 없어 끝나고 많이 후회했다. 왜 그렇게 답을 했을까 ? 왜 이 정도 밖에 준비를 할 수 없을까. 결국 모든 건 내...

17년 5월 구글 캠퍼스 서울 입주 당시 고맙게도 정말 많은 프로그램들을 지원받았는데, 그 중 개인적으로 Campus expert summit 프로그램이 제일 기억에 남는다. 해당 프로그램은 2주 동안 미국, 유럽, 아시아의 구글러들에게 현재 겪고 있는 애로사항이나 궁금한점등을 털어놓을 수 있는 기회의 제공이었다. 입주사당 2명씩 소개가 가능하며, 분야(디자인, 기획, 개발 등등) 또한 선별 가능하다. 우리팀은 두명 모두 엔지니어로 요청했고, 2주동안의 짧은 시간이지만 꽤나 유익한 시간을 보낸 것 같다. 구글 개발자는 어떤식으로 개발하는지에 대해 알았고, 흥미를 느꼈다. 그리고 그들의 삶속에서의 개발과 나의 개발은 조금 괴리감이 있다고 생각한다. 언제가 자유롭게, 재밌게 개발할 수 있는 날이 오지 않을까 .. 그 날이 오기전까지 부지런히 배우고 나눠야겠다.

TL;DR Jekyll 에 검색기능을 추가하는 방법을 서술하고있습니다. At the outset jekyll theme 중, search 기능을 제공하는 theme 도 있지만 그렇지 않은 theme 또한 많이 존재합니다. 제가 사용한 theme 또한 그렇구요. jekyll 을 통해 생성한 static 문서들에대해 검색기능을 추가하고자한다면 우리는 client-side 국한되어서 기능을 구현해야합니다. 그 이유는 static 블로그는 dynamic 블로그와 달리 서버와 상호작용이 없기 때문인데 서버에서 부담해야하는 resource를 client 에서 부담하게됩니다. client side 에서 resource를 사용하니 서버의 부담을 줄이는 이점인 동시에 client 환경에 따라 crash 가 발생할 수 단점도 존재합니다. 질의되는 키워드를 변수 q , 현재 작성된 문서들을 변수 p 라고 가정했을 때 p 의 양의 비례되어 client (= 브라우저) 에서 resource 가 사용되기에 글이 아주 많은 경우 좀 더 각별히 신경을 기우일 필요가 있습니다. What do you prefer github 내 jekyll search 기능을 구현할 수 있는 좋은 library 들이 존재한다. 대표적인 library 는 아래와 같다. simple jekyll search jekyll lunr js search jekyll search 위와 같은 선택지 중 그 어떤걸...

티스토리가 싫어요. 티스토리의 불편함을 감수하고 꽤 오랜 시간을 사용했다. 이전에는 클라우드형 뿐만아니라 설치형 블로그까지 모두 설렵했다. 설렵한 항목들 중 그나마 불편함이 적은 티스토리에 정착했었다. 불편함은 이제 너무나 친숙해서 더 이상 불편함을 인지 못하고 있었다. 귀찮음이 불편함을 이긴 순간이었다. 그런데 갑작스레 이전을 생각한 결정적 계기는 에디터 였다. 티스토리 에디터를 통해 본문을 수정하면, 의도치 않게 강제로 p 태그 등에 style attribute 가 추가되었다. 이로하여 내 블로그 글들은 전부 폰트 및 사이드가 뒤죽박죽이 되어, 도저히 글을 읽을 엄두가 안나게되었다. 티스토리 스킨에서 별도로 javascript 로 위 문제에 대한 정규식을 구해 치환해보았지만, 이 또한 클라이언트 사이드에서 불 필요한 coast 였다. 이렇게 클라이언트 사이드에서 강제한다고 한 들, 이미 망가져린 문서 format 을 보니 더 이상의 인내는 없었다. 이사 짐을 꾸려요. 작성한 글들을 markdown 으로 정적으로 정제하고 싶었고, 그 결과 Jekyll, Hexo 라는 선택지가 주어졌고 후보군 둘다 고만고만하여 일전에 사용해본 Jekyll 을 사용하기로 했다. jekyll 에 대해 간략하게 소개하자면 웹사이트 생성 도구다. Markdown, Liquid, YAML, HTML/CSS 등을...