글쓰기 메뉴
1 3

앗 갑자기

모바일에서 붙여넣기가 안 된다
원래 잘 됐던거 같은데..
나만 안되나요?
내 폰은 아이폰 6 브라우저는 기본 인앱인 사파리입니다
0 0
Square

Reason why I chose Nightmare over phantomjs, casperjs, selenium and ...

테스트용이 아니라 자동화, 스크랩핑(automation, scraping) 용도로 헤드리스 브라우저 - headless browser: 그래픽 인터페이스가 없고 프로그래밍으로 컨트롤 가능한 브라우저 - 를 살펴보고 있는데 종류도 많고 문서 읽어보면 각각의 장점도 분명해서 선택이 어렵다.
이럴땐 사용자도 많고 소스도 오랜시간 검증된 안전한 선택이 좋겠다.
하지만 ㅋㅋㅋ 결론적으로 이번 플젝에 Nightmare 를 선택한 이유는..
Nightmare 공홈이 너무 귀여워서 ㅋㅋㅋㅋ
ㅋㅋㅋ 개귀염
phantomjs 를 엔진으로 쓰다가 2배가량 빠르다는 Electron 으로 엔진을 교체했다는 솔깃한 얘기는 덤.
콜백지옥을 경험하지 않아도 되는 코딩 스타일도 덤.
react 로 작성된 웹페이지와 같이 특정 노드를 대기할 수 있는 메소드가 있는 것도 덤.
- 끝 -
http://www.nightmarejs.org/

http://www.seleniumhq.org/

http://casperjs.org/
http://phantomjs.org/
https://electron.atom.io/

https://github.com/dhamaniasad/HeadlessBrowsers [헤드리스 브라우저 리스트 - outdated]

https://en.wikipedia.org/wiki/Headless_browser [헤드리스 브라우저 위키]
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
0 1

Mac Xcode 다운로드 2일 12시간...
느려도 너무 느려 터진 iTunes

쌔끈한 브랜~뉴 맥에 개발 환경 설정하다가 높은 확률로 빡치는 곳. 
Apple Development Center 에서 Xcode 다운로드 시도하면 iTunes 로 넘겨주는데 다운로드 누르면 남은 시간이 고무줄.
아, 제목에 2일 넘는건 뻥이고 2시간 30분 남았다고하네. 2시간 30분. 퇴근하겠는걸?
암튼... iTunes 로 안넘어가고 아래 페이지에서 필요한 파일 찾아서 브라우저에서 다운로드 할 수 있음.
apple 계정으로 로그인은 해야하고..
https://developer.apple.com/download/more/

이어받기가 필요하다거나 브라우저 다운로드가 왠지 모르게 불안하다면 gem 중에 adcdownload 라고 있음. wget 사용해서 이어받기도 되니 필요하면 아래처럼 사용할 수 있음
$ gem install adcdownload --no-document
$ adcdownload get http://adcdownload.apple.com/Developer_Tools/Xcode_8.3.2/Xcode8.3.2.xip
이렇게 실행하면 apple 아이디와 비밀번호 묻고 다운로드 시작. 
다운로드 링크는 물론 저 위에 페이지에서 파일 url 복사한거.
중간에 끊어지면 그 위치에서 다시 같은 커맨드로 이어받기 가능.
[링크]
https://developer.apple.com/download/more/
https://github.com/MagLoft/adcdownload
2 0
Square

자바스크립트 - 넷스케이프부터 jQuery 까지

테크 전문 매체에서 자바스크립트를 "한때 우스운 언어였던" 이라고 표현한 글을 보고 넷스케이프부터 nodejs 까지 간략하게 정리해봐야겠다고 생각했다.
2009년 시작된 nodejs 는 다른 글로 정리할 예정이다.
자바스크립트는 웹브라우저에서 프론트엔드의 동적인 구성과 사용성 확장을 목적으로 1995년 처음으로 넷스케이프에 탑재된 스크립트 프로그래밍 언어로 넷스케이프 직원이었던 브랜든 아이크가 개발했다.
프로젝트 이름은 mocha였고 LiveScript 라는 이름을 짧게 거치며 현재의 Javascript가 됐다.
이 후 십여년간 "자바"와는 무슨 관계냐며 이유없이 욕도 많이 먹었지만 묵묵하게 웹브라우저에서 알럿창을 띄우며 훗날을 기약했다. 열심히 일했다.
브랜든 아이크가 LiveScript에서 JavaScript로 이름을 바꿀 때 최고의 인기언어였던 Java의 유명세를 의식했다는 얘기도 있으니 이유없이 먹은 욕은 아닐지도...
2002년 발명된 - 겸손한 더글라스 크락포드는 이를 발견이라고 했다 - 데이터 표현방식인 "JSON"은 사랑의 큐피트가 되어 몇몇 훌륭한 개발자들을 자바스크립트와 진하게 엮는데 성공한다.
2004년 "Web2.0" 광풍과 클라이언트-서버간의 비동기 통신 방식인 "AJAX"가 폭발적인 인기를 끌며 자바스크립트는 웹개발의 필수요소로 떠오른다.
작은 문제라면 당시 대중적인 웹 브라우저들이 AJAX 를 각자의 방식으로 구현했었고 비동기 통신의 결과를 화면에 갱신하기 위해 필요한 DOM 검색과 선택 방식 역시 제각각이었다는 점.
이런 브라우저간의 문제는 2005년 Prototypejs를 시작으로 jQuery, script.aculo.us, MooTools, ExtJS, Dojo, YUI 등의 "자바스크립트 라이브러리"의 개발로 이어진다.
한참 시절엔 라이브러리 로고로 a4 한장을 채우고도 남았었다.
이 후 몇 년간 계속해서 새로운 라이브러리들이 개발됐고 각 라이브러리들은 DOM Selector 의 성능이나 자바스크립트 객체에 대한 철학과 디자인 패턴, 더욱 미려하고 부드러운 사용자 화면 효과 등의 영역에서 치열하게 싸움을 벌였다.
몇년에 걸쳐 jQuery가 승자의 자리를 확고하게 다지면서 javascript 는 다시 한번 웹(모바일웹) 개발 필수 언어로 자리잡게된다.
이후의 싸움은 nodejs가 불을 지핀 자바스크립트 플랫폼 또는 프레임워크의 싸움으로 AngularJS, Backbone.js 등의 선수들이 등장하는 더 큰, 하지만 조용한 싸움으로 nodejs 를 다루며 얘기해보겠다.
2 2

꿈 얘기

삼사일 전에 꿈을 꿨어.
늦은 새벽에 차를 몰고 집에 돌아왔는데 주차할 곳이 없어서 근처 유료 주차장으로 들어갔지. 하지만 그 곳에도 주차할 곳이 없더군.
시계를 보니 4시 5분. 대충 아무곳에나 쑤셔넣고 빨리 집에 가서 한숨이라도 자야겠다 싶은 마음에 작은 틈에 차를 우겨넣었지. 그러다가 앞차를 받았지. 내려서 살펴보니 앞차 범퍼가 폭~ 들어갔더군.
전화하긴 이상한 시각이라 생각해 급하게 포스트-잇을 꺼내 "제가 그랬어요. 연락주세요"라고 메모를 남겼어.
다음날 잠에서 깨자마자 차도 이상하게 주차해놨고 사고는 어찌됐는지 궁금해서 주차장에 전화를 걸었어.  그랬더니 주차장 아저씨가 엄청 무겁고 진지한 목소리로 "지금 인터넷에 난리났어요." 이러는 거야. 뺑소니로 생각해서 파렴치한 운전자로 어디 커뮤니티에 글이 올라갔나 생각했지.
"아, 제가 메모를 남겼는데요. 일단 제가 다 보상할께요." 라고 말했더니 "이걸 전부 보상하실 수 있다구요?" 이러는거야. 뭔가 잘못됐다고 느껴져서 다시 전화한다며 전화를 서둘러 끊고 브라우저를 켜고 주차장 이름으로 검색을 해봤어.
내 차 주위에 있던 차들 2~3 대가 전소됐는데 그 중 비싼 외제차도 있더군. 꿈속이라 어찌된 건지 주차장에서 있었던 장면들이 확 떠오르는데, 내가 메모를 남기고 떠난 자리에 누군가 기름통을 들고 와서 불을 지른거야. 허허허허허허허!
꿈 속이지만 진짜 심장이 미친듯이 뛰고 불안하고 괴로운 마음에 손발이 떨리고 내 보험 대차한도가 얼마더라.. 내가 뺑소니로 처리되면 보험금은 제대로 나오나? 요즘 일도 없고 돈도 없는데 이걸 아내한테 어찌 얘기하나 이런 생각들로 진짜 간절하게 도망가고 싶더군...
꿈에서 깨고 얼마나 안도했는지 몰라. 꿈이라 진짜 다행이야 ㅋㅋㅋ
담부터 꿈이든 현실이든 꼬딱지로 막을 수 있는 일은 바로바로 꼬딱지로 막아야겠어. ㅋㅋㅋㅋ
1 1

씬디를 만드는 이유 #2

Medium 은 트위터 공동 창업자 중 에반 윌리암스가 만든 글쓰기 플랫폼이지! 2012년도에 오픈했는데 한 2년 묵묵하게 굴러가다가 2014년도부터 한국에도 많이 알려진 것 같아. 요즘은 한국어로 글 등록하는 사람들도 꽤 보이더라고.
글 쓰기 협업툴을 초기 컨셉으로 들고 나왔었는데 - 그래서 단락별로 에디팅이나 코멘트가 잘 기획되어 있지 - 지금은 그것보단 "글 쓰기에만 집중할 수 있는 글 쓰기 플랫폼" 으로 어필되고 있는 것 같아. 물론 사람들이 스킨과 디자인은 잊고 글 쓰기에만 집중할 수 있도록 충분히 아름답고 정리된 디자인을 자랑하지.
기고자와 독자가 충분히 많아지니까 기존 미디어들에서도 미디엄에 채널을 만들어 콘텐츠를 유통시키는 모습도 자주 보이고, 팀이나 브랜드 단위의 채널들이 많이 생기고 콘텐츠 질도 점점 좋아지는 것 같아.
애니웨이, 미디엄에 대한 개인적인 불만이라면 단 하나.. 한국어로 글을 쓸 때 serif 폰트가 설정되어 있는데 이게 보기에 엄청 거시기해. 브라우저 설정에서 폰트를 지정해서 쓰면 되나? 되겠지 뭐.
지저분한 사심을 담백하게 털어놓자면 미디엄 같은 아름다운 플랫폼을 갖고 싶었어. 폰트 설정은 구차한 변명이지. 그냥 내껄 갖고 싶었어! 이게 씬디를 만든 두번째 이유.
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배로 올리겠습니다!" 라고 보고하고 보다 많은 사용자들의 빡을 돌려(?) 주삼. 
0 0

Ubuntu 14.04 - Apache Tika 설치

아파치 티카는 PPT, XLS, PDF 등 수천종의 파일에서 텍스트와 메타정보를 추출하는 툴킷이다.
아파치 소프트웨어 재단의 프로젝트이며 아파치 루씬의 서브프로젝트로 시작됐고 현재는 독립되었다.
티카는 Apache Maven2로 빌드가 가능하나 여기서는 바이너리를 사용한다.
소스나 바이너리 다운로드 URL은 다운로드 페이지에서 확인하자
tika-app
콘솔에서도 유틸리티처럼 사용이 가능하고 --server 옵션으로 서버모드로도 사용이 가능하다. NetCat 등의 커맨드를 사용해 처리결과를 받을 수 있다.
tika-server
보다 서버스러운(!) 서버모드로 RESTful API 를 제공한다.
구동
JRE 는 당연히 설치되어 있어야하고 -jar 옵션으로 간단하게 구동된다. 기본 포트는 9998
구동 확인
브라우저에서 9998 포트로 접속하면 URL 정보가 출력된다.

tika-server 는 PUT 메쏘드만 받으며 리퀘스트 body 로 파일만을 받는다.
Meta 
Text
HTML
추가로, 내가 쓰는 Typhoeus 에서는 아래와 같이 사용할 수 있다.
Apache Tika : http://tika.apache.org/
TiakJAXRS Wiki : http://wiki.apache.org/tika/TikaJAXRS
1 3
Square

XX신문 온라인 기사면 광고 비율

어제 한글날 기념 폰트 다운로드 정보 페이지 업데이트를 위해 구글검색 중 한 뉴스 사이트를 방문하게 됐어. 인터넷뉴스나 언론사 닷컴 사이트에 광고 갯수도 많고 질도 떨어진다는건 익히 알고 있음에도 불구하고 페이지가 열리고 스크롤을 내리는 내내 숨이 막혀 죽을 것 같더군.
그래서 1415 x 908 크기로 브라우저를 띄우고 첫화면에서 광고 비율이 얼마나되는지 확인해봤어.
광고(적색) : 43.71%
기사(녹색) : 12.83%
기타(청색) : 15.30% (제호, 메뉴, 사고 등 브랜드 콘텐츠)
사실 이 영역은 좋아하는 이성이랑 처음 데이트하는 날 헤어스타일이랑 같은거야. 딱 이만큼의 크기로 첫인상이 결정된다는 말이지. 물론 이미 첫인상이 각인됐고 상대방은 페이지에 떨어지면 휙휙~ 스크롤하며 필요한 것만 쪽쪽 뽑아내고 바로 떠나는 만남이 일반화된게 문제지만, 지금이라도 바꿔야하지 않겠어?
오~래 걸리겠지만 머리카락도 단정하게 손 보고 찌개국물 늘어붙은 티셔츠도 좀 빨고... 그리고 진짜 가장 중요한건 거울 좀 보라는거야.
기자들, 편집자들 자사 사이트는 확인도 안하고 네이버에서 자기 이름넣고 기사 읽어보는 웃기는 짓 좀 그만했으면 좋겠어.
지금 어떤 꼴인지 좀 보고 다른 사람 만나라. 민폐야 민폐.