TOAST UI

필자는 풀타임 개발자의 업무를 작은 회사에서 처음 맡았다. 우리는 BrowserStack을 가지고 있지 않았기 때문에 임시 변통 장치 실험실을 함께 만들었다. 부서진 1세대 iPad와 오래된 버전의 Safari로 그 웹사이트를 봤을때, 필자는 왜곡과 부서진 잔해들이 보였다. 필자는 한때 웹을 "상상할 수있는 가장 적대적인 소프트웨어 엔지니어링 환경"이라고 생각했던 Douglas Crockford의 말을 떠올렸다. 올해 초 Verge 의 광범위하게 공유 된 기사는 웹에서 볼 수있는 "Chrome에서 가장 잘 작동합니다."메시지에 대해 경고했다. 이 문제의 예가 더 있다. 널리 사용되는 메시징 앱 슬랙(Slack)은 Chrome에서만 음성 통화가 작동한다. 도움 요청에 대한 응답으로 Slack은 다음과 같이 설명했다.

Redux Saga는 테스트가 쉽기로 유명하다. 하지만, 더 간단해질 수 있다면 어떨까? Jeremy Fairbank는 더 간단한 테스트를 위해 redux-saga-test-plan을 디자인했다.

AngularJS의 디렉티브/컴포넌트에서 @ < & = 가 실제로 어떻게 동작하는 지 알아보고, < 기호가 어떻게 나머지 기호들을 대체할 수 있는 지 알아보자.

최근에 새로운 프로젝트를 진행하게 되면서 기존에 간만 살짝 보고 있던 뷰(Vue, 이하 뷰)를 본격적으로 도입하게 되었다. 사실 팀에서는 리액트를 선호하고 있었으나 회사 내부에서 뷰의 사용이 빠른 속도로 증가하고 있었고 그에 따라 팀내에서도 뷰에 대한 전문성이 필요하게 되었다. 뷰와 리액트는 서로 영향을 주고받고 발전해나가는 도구들이라 비슷한 부분이 많아 큰 어려움 없이 적응할 수 있었다. 새로운 프로젝트에서는 뷰를 사용하는것 뿐 아니라 다른 개발 환경도 요즘 것들로 업그레이드 해봤다. 웹팩 4 사용하고 테스트 러너도 기존에 팀 내에서 표준처럼 사용하던 카르마(Karma)에서 요즘(이미) 잘나가는 제스트(Jest)로 새롭게 시도해봤다.

우리는 최근 WebAssembly 컴파일이 얼마나 빠른지, 얼마나 빠른 JS 라이브러리를 만들 수 있는지, 거기에 얼마나 더 작은 바이너리를 만들어 주는지 확인했다. 더욱이 우리는 Rust와 JavaScript 커뮤니티의 더 나은 협업을 위한 계획을 세웠고, 이것에는 다른 웹 프로그래밍 언어들을 위한 것도 포함되어있다. 이전 글에서도 슬쩍 말했지만, 나는 wasm-bidgen에 대해서 좀 더 자세하게 알아보려 한다.

ES 모듈은 자바스크립트의 공식적이며 표준화된 모둘 시스템이 되었다. 표준이 된 지는 얼마 지나지 않았지만 거의 10년간의 표준화 작업을 거쳤다. 이제 기다림은 거의 끝나간다. 5월에 Firefox 60(현재는 베타버전)이 출시되면 모든 브라우저가 ES 모듈을 지원할 것이다. 그리고 Node 모듈 작업 그룹은 현재 ES 모듈 지원을 추가하려고 노력하고 있고, WebAssembly를 위한 ES 모듈 지원 또한 진행중이다.

이번 글에서는 Redux-Saga의 Channel(이하 채널)에 대해 정리해보고자 한다. 채널은 Redux-Saga의 초기 버전에서부터 고려했던 API는 아니다. 그런데 Stackoverflow에서 외부 이벤트를 Saga와 어떻게 연결하냐는 질문에서 채널의 필요성이 표면적으로 나타나기 시작했다. 핵심은 Push 기반과 Pull 기반 동작이다.

1부에서는 HOF(Higher Order Function)의 개념부터 시작해서 HOC(Higher Order Component)의 개념이 무엇인가와 어떤 상황에 이용될 수 있는지에 대해 알아보았다. 하지만 1부의 내용만 읽어서는 HOC를 실제 프로젝트에 어떻게 활용할 수 있는지에 대한 감이 잘 잡히지 않았을 것이다. 2부에서는 실제로 간단한 HOC를 만들어보고, 그 과정에서 발생할 수 있는 문제들과 이를 어떤 식으로 해결하는지, 그리고 지켜야할 컨벤션에 어떤 것들이 있는지에 대해 살펴보도록 하겠다.

현재 팀 내부에서는 시니어들이 팀 인력 채용 프로세스를 개선하고 있다. 프로세스 중에서도 현재는 필기시험 문제를 재출제하는 중인데 이게 생각보다 쉽지 않아 매일 매일 서로 의견이 분분하다. 그러던 어느 날 프리미티브에 대한 의견을 나누던 중 자바스크립트의 프리미티브를 객체 같이 사용된다고 설명해도 되느냐 안되느냐의 문제를 놓고 토론을 하게 되었는데 내 의견은 표면적으로 객체처럼 사용할 수 있기에 객체 같이 취급된다고 표현해도 된다는 의견이었고 다른 한 멤버는 중간에 프리미티브 래퍼가 관여하는 내용이기 때문에 그렇게 설명하면 안 된다는 것이었다.

웹 워드프로세서(이하 웹 워드)는 브라우저만 있으면 어디서나 문서 편집을 할 수 있다는 장점이 있어 매력적인 소프트웨어이다. 아직 네이티브 워드프로세서로 할 수 있는 모든 기능을 다 지원하는 것은 아니지만 가까운 미래에는 가능하리라고 믿는다. 2년 동안 웹 워드를 만드는 동안 가능성을 믿고 험난한 과정을 헤쳐 나갔고, 기능을 구현해 나갈 때마다 느꼈던 흥분과 희열은 아직도 강하게 남아있다. 이 글을 읽는 여러분 또한 그런 느낌을 받게 되기를 소망한다.