글쓰기 메뉴

무엇이란 무엇인가

20180922_233250.jpg

근래에 본 가장 좋은 컬럼.


신디란 무엇인가



다른 글들
3 0

별을 가지고 무려 1년을 전공필수로 공부하였다. 그 중 절반은 경험도 없는 남반구의 것들이었지만, 머리속으로 그들의 위치와 움직임, 의미를 모조리 그렸다.
아직도 해가 지면 얼굴을 들어 하늘을 향하고 별을 본다. 근래엔 화성이 제일 밝고 가깝다. 목성과 금성 사이에서 오락가락한다. 그 길을 따라보다보면 내가 닿을 곳이 보인다. 
별에는 어떤 이야기도 없다. 하지만, 나에겐 별에게 정의된 이야기가 남는다.
1 0

파비콘 만들기

파비콘 관련해서는 소프트웨어도 많고 웹서비스도 엄청 많아서 대충 골라도 무난하게 작업되긴하더라.
그래도 근래에 몇번 유용하게 사용한 파비콘(및 아이콘) 제작 웹서비스라 Donate 는 힘들더라도 링크를 거는것으로 마음의 짐을 덜어보자.
"파비코메틱" - http://www.favicomatic.com/
3 1
Square

너의 이야기

운전을 하다가 눈에 익은 사람을 만났다. 버스정류장에 서있던 그 사람을 꼭 만나야 했었다. 긴머리에 귀에는 이어폰을 꼽고 하염없이 달만 쳐다보는 18살, 나는 짧은 머리에 헬멧을 쓰고 양화대교를 건너기 직전 신호를 받던 23살. 그날 난 18살의 나와 대면했다. 

바이크는 정류장 한켠에 세워두곤 빠른 걸음으로 달려가 그의 손을 잡았다. 
"잡았다."
나는 그당시 내가 만들었던 나만의 미소로 그를 반겼다. 그 미소는 사실 그 아이에게 더 잘어울린다. 그 미소를 직접 만나고 싶어서 지었던 것이다. 물론 미소보단 우울한 표정과 당황한 표정을 볼 수 있었고, 곧 이어 그 아이의 울음이 터져나왔다. 이해한다. 이해 할 수 밖에 없다. 내가 꼭 만나야만 하는 사람이기에. 
너는 참 힘들었구나, 너는 참 우울 했구나, 너는 참 위로가 필요 했구나. 그 말을 담아 안고 달래주었다. 
"그거 알아? 나는 참 짧은 머리가 잘 어울려. 나도 요근래 알았어. 그리고 난 사람을 잘 그려 나 코딩도 잘 한다? 옷도 잘 입고 다니고, 좋은 사람들을 너무 많이 만났어." 널 보니까 이런 이야기만 나온다. 대학은 거기 말고 여기부터 준비해라, 책 많이 읽고 영화는 이런쪽의 영화를 많이 봐라, 영어공부 해라 이런 이야기를 해야 하는거 아닐까 싶었는데 그 표정에선 이런 이야기 밖에 나오지 않았다.
1 0

창문

잠이 오지 않는 밤.
사실 이 어플을 받은건 며칠 전이었는데 도통 여유가 없어서 오늘에서야 처음 켜본다.
어느새 오늘이 되버린 내일, 곧 다가올 새벽엔 눈을 떠야하는데 잠이 도통 오질 않는다. 눈을 감고 잠에 들어 보려다가 포기하고 핸드폰을 뒤적거리던 중에 어플 폴더들 사이에 갈곳을 잃은 이 어플이 눈에 띄었다.
어플을 키자마자 보이는 글자,  '창문'.
글 주제가 창문이라는데, 공교롭게도 지금 내 눈 앞에 창문이 있다.
집 층수가 높아서 창문을 열어두고 침대에 누우면 창이 하늘로 가득찬다. 그 모습이 꽤 봐줄만 하다. 날 좋은 오후 침대에 누워 가만히 하늘을 보고 있노라면 글자 그대로 평화를 느낄 수 있다. 은은하게 들리는 차소리를 배경음악삼아 구름 흘러가는 구경에 시간가는줄을 모른다. 그렇게 몇십분 시간 흘러가는대로 있다보면 잠들지 않아도 머리속이 개운해지고 기분도 상쾌해진다. 그래서 괜히 늘어지는 날엔 창문을 열어 눈에 가득차는 하늘을 즐기고는 한다. 
하지만 근래엔 너무 바빠서 그런 여유를 즐길 순간조차 없었다.
아침에 눈을 뜨면 부랴부랴 준비를 해 새벽 전철에 몸을 싣고 집에 도착하면 내일을 위해 눈을 감고 잠을 부르기에 바쁘다.
요즘은 정말 하루를 산다기 보다 하루를 버텨낸다는 표현이 어울리는 것 같다. 이런 일상속에서 창문은 무늬만 창문인 벽의 일부가 되어버린지 오래다. 
그래서 이렇게 글을 쓰다가 '그래 내 방에 창문이 있었구나.' 새삼 깨닫는다.
이제 핸드폰을 내려두고 눈을 감으면
오랜만에 만난 창문 너머로,
의식을 던져두고 무의식으로 빠져들었으면 좋겠다.
그리고 돌아오는 일요일엔 아무생각없이 창문 너머 구경을 해봐야지.
이제 그만 자고싶다.
잠이 얼른 왔으면 좋겠네.
1 0

우분투 몽고DB 설치 및 부팅 시 자동 실행 - Install MongoDB on Ubuntu & Start MongoDB on system start

설치는 매우 간단하고 MongoDB 공홈에 최신 버전으로 갱신된 문서가 있어 해당 페이지를 참고하면 된다.
공홈 설치 문서 링크:

https://docs.mongodb.com/manual/tutorial/install-mongodb-on-ubuntu/
GPG Key
리스트파일 생성 (16.04. 기타 버전은 공홈 참조)

패키지 디비 갱신
MongoDB 설치

근래의 대부분의 배포본은 Upstart  대신 Systemd를 사용하기 때문에 위와 같이 설치된 MongoDB 역시 init 스크립트를 제공하지 않는다.
service 커맨드로 시작, 중지, 재시작 등의 관리가 가능하나 systemctl 커맨드를 익히는게 바람직하다고 본다.
systemd 를 사용해 MongoDB 를 초기 실행 시키기 위해 다음의 파일을 작성한다.
/etc/systemd/system/mongodb.service

Unit 섹션의 Description 은 서비스에 대한 간단한 설명을 포함한다.
같은 섹션의 After 는 네트워크 연결 후 구동하겠다는 의미
Service 섹션의 User 는 서비스 실행 사용자를 지정하고 ExecStart 는 실제 구동 커맨드를 입력한다.
Install 섹션의 WantedBy 는 실행 타깃을 구분하는데 multi-user.target 은 기존 런레벨 2,3,4 로 일반적인 부팅 시에 동작된다.
구동
상태 확인
정지
부팅 시 실행
systemd 의 target 에 대해 보다 자세히 알고 싶다면 아래의 링크를 참조.
https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/System_Administrators_Guide/sect-Managing_Services_with_systemd-Targets.html
systemd 에 대해 보다 자세히 알고 싶다면 아래의 링크를 참조
http://lunatine.net/about-systemd/
2 1
Square

Basecamp / Trix
리치 텍스트 에디터의 해답이 되길

브라우저 기반의 WYSIWYG 에디터들은 오늘도 전투를 치르고 있다. 최소한 20년은 진행된 전투다.
답답한건 이 전투가 시장에 대한 답을 갖고 있는 솔루션간의 전투가 아니라 Internet Explorer 5.5 시절에 Microsoft 에서 설계한 contenteditable 과 execCommand API 와의 전투라는 점이다.
여기에 더해 다른 브라우저들은 공개된 문서없이 contenteditable 속성과 execCommand 기능을 지원하며 애초에 명세없는 기능들이 각 브라우저별로 다른 방식으로 개발되어 버려 헬게이트가 열린 것이다.
물론, 충분한 수준의 브라우저 커버리지를 갖고 있는 양질의 제품이 많이 있다.
CKEditor, TinyMCE, wysihtml5, Summernote, Froala, Redactor등의 제품들이 WYSIWYG 를 정리할때면 꼭 등장하는 제품들이고 아예 contenteditable 을 버리고 위키처럼 마크업 편집기를 발전시키는 진영도 있다.
하지만 마크업 편집기는 진입장벽이 분명해 관련된 경험이나 이해가 없는 일반 사용자를 대상으로 제공하기는 어렵다.
근래 모바일 환경이 빠르게 발전하면서 모바일 브라우저와 브라우저 엔진들이 빠른 속도로 업데이트되어 WYSIWYG 개발자들이 미친듯이 바빠진 것 같다. 내가 업데이트 내용을 피드로 받는 에디터는 2종에 불과하지만 근래 패치노트들을 살펴보면 iOS 브라우저 관련 버그 수정, Android, iOS webView 관련 버그 수정 등 모바일 관련 업데이트가 지속적으로 늘고 있다.
기능 추가가 아닌 버그픽스 업데이트가 잦아졌다는건 그만큼 최근 환경에 대한 버그가 증가했다는 말이다. 브라우저 기반의 에디터 제품들은 앞서 말한 것 처럼 contenteditable 과 execCommand 를 족쇄처럼 차고 있기 때문에 특정 환경에서 치명적인 문제는 대부분의 제품에 동시에 영향을 끼친다.
WYSIWYG 와 뗄 수 없는 관계에 있는 나는, 이런 상황이 발생할 때 마다 에디터들에 대한 정보를 모으고 테스트하고 HACK 이 가능한 부분이 있는지 살펴보며 좌절하고 그저 시간이 지나 관련된 문제들이 차근차근 정리되길 기다릴 뿐이다.
그러던 중 반가운 소식 하나.
Basecamp 팀에서 trix 라는 새로운 리치 텍스트 입력기를 공개했다.
contenteditable 과 execCommand 에 대한 종속성을 최소화 시켰다고 한다. 관련 내용을 정리해보면,
아! 개행복.
이론적으론 이제 IME 말고는 신경쓸게 없다는 얘기다.
Basecamp 에서 몇년전에 Wysihat 이라고 WYSIWYG 엔진을 오픈소스로 개발하던 적이 있었는데 생각보다 빠르게 개발이 중단되어 Wysihat 엔진으로 모든 에디터를 교체했던 나는 좀 많이 아팠지만 Basecamp 내부에선 더 큰 아픔을 겪고 Trix 가 나왔겠지라고 기대하고 있다.
씬디도 Trix 로 에디터를 교체하기 위해 개발을 진행하고 있으며 많은 개발자들이 Trix 에 관심을 갖고 참여해 WYSIWYG의 지리한 전투가 종식되길 기대해본다.
Trix : https://github.com/basecamp/trix
1 1
Square

[3분 복붙] 기사면 랜딩 PV 2배로 올리기.
브라우저 뒤로가기 제어.
이딴거 만들지 말자.

대부분의 서비스가 보다 많은 활동 사용자를 목표로 함은 분명하다.
하지만 얼마나 많은 활동 사용자가 있는지를 가늠할 수 있는 지표에 대한 목표설정은 좀 다른 얘기라고 생각한다.
심지어 그 목표의 달성을 위한 실현 과정이 사용자들을 열받게 만든다면 이 얼마나 근시안적 추태인지...
PV (Page View, 페이지 조회수) 에 대해 강한 집착을 보이는 국내 언론사들이 근래 "뒤로가기"가 실행되는 경우 이전 페이지로 보내지 않고 메인페이지로 이동되도록 하는 기능을 속속 도입하고 있더라. (좀 됐지.. 내가 잠수였던거지..)
사용자 입장에선 개빡치는 UX. 
그렇지만 남들이 한다니까 자기들도 해달라는 클라이언트의 등장은 당연지사.
해당 기능을 도입한 사이트들을 둘러보니 대부분 광고대행사 등이 제공한 스크립트를 사용하는 것 같더라.
메인페이지를 거치는 것도 짜증나는데 그 중간에 광고까지 껴있으니 개짜증..
이딴거 누가 안만들면 좋겠는데 일개 개발자가 뭘 할 수 있겠냐 고민하다가...
클라이언트에게 만들어준 간단한 스크립트를 모두에게 제공하고 너도나도 다들 도입해서 더 많은 사용자들이 더 빠르게 빡돌게 만들면 슬슬 이딴 쓰레기 같은 기능을 버리지 않을까라는 골때리는 결론에 도달했다.
0.
jQuery 를 사용하고 있다고 가정한다.
1.
아래의 코드를 기사 페이지 등 기능이 동작될 페이지에서 로드되는 js 파일에 추가한다.
3번 라인 정규식 패턴안의 synd\.kr 부분은 자신의 도메인으로 변경한다.
2.
기능이 동작될 페이지 HTML 코드 사이에 아래의 코드를 삽입한다.
완성!
코드는 단순해서 쉽게 이해할 수 있겠지만 몇몇 부분을 설명해보자면...
1. pushState 이후에 replaceState 를 다시 콜하는 이유.
pushState 만으로 history 를 조작할 경우 firefox 에서 백버튼이 골때리게 반복된다.
external > page > main > page > main > external
replaceState 를 다시 콜하면 아래와 같이 의도한대로 동작된다.
external > page > main > external
2. popState 이벤트를 사용하지 않고 hashChange 를 사용하는 이유
페이스북 앱 등 in app browser 를 사용할 때 해쉬가 없는 경우 뒤로가기 실행시 popState 이벤트가 발생되지 않음
해쉬를 추가해야 뒤로가기 실행 시 기존 URL (해쉬없는) 로 페이지 변화없는 이동이 발생하고 이 타이밍에 hashChange 가 콜 됨.
또한, Safari 9버전 이하에서 popState 가 지멋대로 fire 됨.
3. 이건 좀 쓸데없는 설명이지만 location.href 는 history 에 기록되고 location.replace 는 history 에 남지 않기 때문에 replace 를 사용해야함.
지원브라우저
웹이고 모바일이고 html5 history api 를 지원하는 브라우저 (http://caniuse.com/#search=history) 에선 기본적으로 모두 동작된다고 기대할 수 있으나 아이폰 크롬에서 동작안됨.
그 외 페이스북 앱 등 인앱에서 웹뷰를 사용하는 경우도 정상 동작.
Tested.
Microsoft Edge.
Microsoft IE 11.
Firefox 52.x (Windows)
Firefox 47.x (Linux)
Firefox 52.x (Mac)

Firefox 52.x (Android)
Firefox 6.x (iOS)
Chrome 57.x (Windows)

Chrome 48.x (Linux)
Chrome 56.x (Mac)

Chrome 57.x (Android)
Chrome 57.x (iOS) *동작안됨
Safari 10.x (Mac)
Safari 10.x (iOS)
Android 6 browser 4.x
Facebook App
자 이제 자리에서 일어나서 팀장이든 부장이든 상사에게 "저희 PV 를 2배로 올리겠습니다!" 라고 보고하고 보다 많은 사용자들의 빡을 돌려(?) 주삼.