슭의 개발 블로그

이 포스팅은 그냥 지난 한 주간 읽었던 것들을 정리하는 포스트입니다. 그냥 예전에 봤던 글 중 나중에 필요한데 뭐였는지 기억 안 나는 글들이 있어서 쓰기 시작했습니다. 보통 하는 일과 관련된 글들이 올라오겠지만 딱히 정해둔 주제는 없고, 그때그때 관심 있었던 것을 읽었기 때문에 지난주에 쓰인 글일 수도 있고 몇 년 전에 쓰인 글일 수도 있습니다. The Configuration Complexity Clock Configuration을 만들다 보면 Rules engine 이나 심할 때는 DSL (Domain Specific Language)까지 만들기도 하는데, 어떨 때는 그냥 하드코딩 하는 것이 가장 적절한 방법일 수 있다는 글이다. Linus's Law given enough eyeballs, all bugs are shallow 리누스의 법칙은 위의 한 줄로 정리된다. 오픈 소스의 근간이 되는 문장이고, peer-review가 필요한 이유로도 많이 언급된다. 문제는 최근의 거대한 소프트웨어서는 버그를 발견하는 데 필요한 enough의 수가 너무 크다는 것이다. 게다가 시스템이 복잡하다면, 그 시스템을 이해하지 못한 개발자는 버그를 발견하기 위한 eyeballs 중 하나가 되지도 못한다. 그렇기 때문에 시스템을 단순하게 유지하는 것이 중요하다. Language Health 각 언어가 오픈 소스에서 얼마나 많이 사용되는지 비교해보는 사이트다. 다만, 어디까지나 오픈소스에서 얼마나 많이 커밋이 있었는지에 대한 비교이지, 얼마나 많은 사람이 사용하는지나, 클로즈드 프로젝트에서 얼마나 많이 사용하는지는 알 수 없다. An introduction to the GNU Core Utilities 리눅스에서 작업하다 보면 필요한 유틸리티 모음. 터미널에서 작업할 때 알면 좋은 것들이다. REST APIs are REST-in-Peace APIs. Long Live GraphQL. GraphQL의 장점에 관해서 쓴 글이다. 근데 ...

SpeechSynthesis 는 Web Speech API의 하나로 주어진 텍스트를 소리로 바꿔주는 TTS API이다. SpeechSynthesis 이전에도 TTS 서비스가 있었지만, 이들은 유료이거나 웹에서 사용하기 불편한 경우가 대부분이었는데 SpeechSynthesis 의 경우 브라우저에 내장되는 API이므로 무료로 쉽게 사용할 수 있다는 장점이 있다. 물론 Web Speech API 자체가 아직 draft 에 해당하기 때문에 브라우저가 지원해야만 사용 가능하다는 문제는 있지만, 2016년 8월 15일 현재 데스크탑에서는 크롬과 사파리, 안드로이드 기본 브라우저인 크롬, 아이폰의 기본 브라우저인 사파리에 지원하고, 파이어폭스는 9월에 지원할 예정이므로 대부분의 모던 브라우저에서는 사용할 수 있다. speechSynthesis 는 5개의 함수를 가지고 있다. 그중 4개는 speak , cancel , pause , resume 이다. 이를 이용해서 재생할 음성을 추가하거나 취소하거나 일시 정지할 수 있다. 이 중 speak 함수는 SpeechSynthesisUtterance 를 인자로 받는다. speak 함수를 호출했을 때, 이미 재생 중인 utterance 가 없고 speechSynthesis 가 pause 되어 있지 않으면, 요청된 utterance 는 즉시 재생된다. 하지만 이미 재생 중인 utterance 가 있거나 speechSynthesis 가 pause 되어 있다면, utterance 는 바로 재생되지 않고 queue에 저장되었다가 후에 재생된다. 따라서 실제로 언제 재생되는지는 utterance 의 콜백을 통해서만 알 수 있다. 이벤트의 종류에 따라서 onstart , onend , onerror , onpause , onresume 등의 콜백을 등록할 수 있다. 또한, SpeechSynthesisUtterance 는 6개의 속성을 가지고 있다. 첫 번째 속성은 text 로 읽을 텍스트를 지정한다. 객체를 생성할 ...

비밀번호는 보안상의 문제로 " ● "으로 표시되기 때문에 오타를 냈어도 확인할 수 없고 잘못 입력하면 앞으로 로그인할 수도 수정할 수도 없어 계정을 그대로 버리는 문제를 발생시킨다. 따라서 비밀번호의 오타는 다른 정보들과는 다르게 큰 문제가 된다. 그래서 일반적으로 회원가입을 할 때, 비밀번호를 두 번 입력하도록 한다. 하지만 이런 방식이 UX를 크게 저하한다면서 다른 방식을 사용해야 한다고 주장하는 글 이 있었다. 이 글에서는 비밀번호를 두 번 입력하는 대신 입력한 비밀번호를 읽을 수 있게 보여주는 토글 버튼이 있어야 한다고 주장한다. 언뜻 들으면 그럴싸해 보이지만 결론부터 말하면 절대 좋은 방식이 아니다. 최소한 웹 환경에서는 절대 해서는 안 되는 방식이다. 비밀번호를 보여줄 수 있게 만드는 방법은 다음과 같은 문제가 몇 가지 있다. 우선 브라우저에서 지원하지 않는다. 현재의 웹 스펙에 password input 을 보여주는 방법은 없다. 따라서 text input 을 이용해야 한다. 문제는 브라우저, 최소한 제대로 된 브라우저(심지어 I.E조차도)는 text input과 password input을 완전히 별도로 처리한다는 것이다. 이 둘의 차이는 단순히 내용이 눈에 보이는가 아니면 " ● "으로 보이는가의 차이가 아니다. 일단 당장 눈앞의 문제로 text input은 password input과 다르게 브라우저가 캐싱하고 자동 완성 한다는 것이나, 브라우저의 비밀번호 저장 기능을 생각해볼 수 있다. 캐시와 관련한 것은 autocomplete 를 이용해서 조정할 수 있지만, 비밀번호 저장 기능은 password input만을 저장하기 때문에, text input을 이용한 상태에서는 어떻게 할 방법이 없다. 사실 비밀번호 저장기능이 중요한 기능이 아니기는 하다. 하지만 이 기능은 포기한다고 해도 여전히 브라우저가 password input과 text input 전혀 별개의 것으로 처리한다는 것은 문제다....

나는 freenode를 구경하거나 친구들과 놀기 위한 용도로 IRC를 사용한다. 데스크탑 어플리케이션도 많이 쓰이지만, IRC라는 프로토콜의 특성상 접속하여 있지 않으면 대화를 볼 수 없어서 freenode에 있는 사람들은 IRC를 계속 접속해놓을 방법을 찾는다. 가장 쉬운 방법은 컴퓨터를 끄지 않고 다니는 방식이지만, 보통 개발자 중에 이런 방식을 사용하는 사람은 없다. 보통은 서버에 터미널 기반의 IRC 클라이언인 WeeChat 이나 Irssi 띄우거나, IRC Cloud 라는 서비스를 사용한다. 하지만 터미널 클라이언트를 사용하면 언제서나 접속할 수 있는 웹 클라이언트가 아쉬워지고, IRC Cloud를 사용하기에는 한 달에 5$ 하는 비용뿐 아니라 WeeChat의 plug-in기능이 아쉬워진다. 그래서 보통은 WeeChat과 IRC Cloud 양쪽을 사용하는 방식을 택하지만, 그렇게 되면 2개의 접속이 연동되지 않기 때문에 불편한 건 어쩔 수 없다. 그래서 WeeChat plug-in을 이용해 위와 같은 웹 서비스를 만들어볼 계획이었다. 우선 채팅 로그를 DB에 저장하는 스크립트를 만들던 중 WeeChat에 완전히 같은 목적을 가진 relay protocol 이 있다는 것을 알게 되었다. Relay protocol은 WeeChat client가 relay 서버가 되어, Relay 클라이언트와 TCP socket을 이용해 통신을 하게 된다. Relay protocol을 사용하면 WeeChat과 완전히 같은 화면을 볼 수 있는 데다가 WeeChat plug-in을 그대로 사용할 수 있다는 장점이 있다. Relay protocol을 사용하는 client는 여러 가지가 있다. Qt를 사용해서 데스크탑 애플리케이션을 만든 QWeeChat , node.js를 이용한 웹 서버 WeeCloud 등도 많이 사용된다. 하지만 내가 사용하는 클라이언트는 Glowing Bear 다. Glowing Bear는 완전히 static 한 web page에서 We...

modern web browser에는 보안을 위한 여러 가지 기능들이 들어있다. 그중 가장 대표적인 기능이 same-origin policy 다. same-origin policy 덕분에 (개발자 입장에서는 약간 짜증 나기는 하지만) 특별히 신경을 쓰지 않아도 보안에 관해 상당히 많은 부분을 커버할 수 있다. same-origin policy의 원칙은 매우 간단하다. 내 사이트가 다른 사이트에서 호스팅 되는 리소스에 의존하는 것을 금지해서, 내 사이트가 오염되거나 다른 사이트에 의해 공격당하는 것을 막는 것이다. same-origin인지 결정하는 것은 매우 간단한데 프로토콜, 호스트, 포트가 같은 URI 를 same-origin이라고 판단한다. 요새는 대부분 개인 서버와 개인 도메인을 사용하기 때문에, 프로토콜과 포트까지 같은지 판단하는 것은 너무 빡빡한 기준이라고 생각할 수도 있지만, 워크스테이션이나 공용 서버에서 작업하는 일도 많다는 것을 생각하면 포트와 프로토콜까지 고려하는 것은 역시 상식적인 판단이라고 할 수 있다. 브라우저에서 많이 쓰이는 http나 https에서는 이 규칙이 상식적이라고 할 수 있다. 문제는 file URI 에서의 동작이다. file URI에 대해서는 어떤 URI를 same-origin이라고 할 것인지 정해진 것이 없고, 브라우저마다 알아서 자신이 옳다고 생각하는 방식으로 구현했다. 우선 오페라 는 file URI도 다른 URI와 같은 정책으로 처리한다. 따라서 file URI로 접근한 페이지에서는 읽기 권한이 있는 모든 파일을 읽어서 리소스로 활용할 수 있다. 어차피 파일은 OS가 access list로 보호하고 있으니, 로컬 파일에 대한 보안을 OS에 맡겨 버린 것이라고 할 수 있겠다. 약간 무책임한 것 같지만, 오페라의 구현이 가장 웹서버 없이 웹 페이지를 테스트하기 편한 구현이다. 반면 크롬 은 modern browser 중에 가장 빡빡한 규칙을 적용한다. 크롬에서는 file URI로 들어오는 요청에 대해 무조...