작은 자유

Array.splice()의 두 번째 인자를 생략했을 때

ohgyun — Tue, 08 May 2012 15:18:02 +0900

발생일: 2012.05.08

문제:

배열 데이터를 잘라서 처리하는 로직을 구현해야 했다.

아래와 같이 짧은 코드를 구현했는데,

크롬에서는 잘 동작하지만 IE8 이하에서 제대로 동작하지 않는 걸 발견했다.

var a = [1, 2, 3, 4, 5];

var result = a.slice(1);

이상하다. 특별히 문제될 부분이 없는데...

왜 이런 걸까...

해결책:

음메.

slice를 splice로 잘못 썼던 게 문제였다... -_-;

splice는 배열에서 특정 인덱스의 아이템을 추가하거나 삭제하는 메서드이고,

아래와 같은 형태로 호출한다.

splice(index, howmany, itemToAdd, itemToAdd, ...)

표준에는 두 번째 파라미터인 howmany 값이 필수라고 정의해뒀지만,

만약 이 값을 생략하는 경우, IE 하위 버전과 모던 브라우저 간의 동작 방식이 다르다.

두 번째 인자를 생략할 경우,

크롬에서는 해당 인덱스부터 끝까지 삭제하지만, IE8 이하 버전에서는 삭제하지 않는 것이 그 차이점이다.

삭제한 엘리먼트를 배열에 담아 리턴하는 동작은 동일하다.

예를 들어,

var a = [1, 2, 3, 4, 5];

var result = a.splice(1);

와 같은 작업을 수행하면.

// IE9, Chrome, FF, Safari

a ==> [1]

result ==> [2, 3, 4, 5]

// IE8 이하

a ==> [1, 2, 3, 4, 5]

result ==> []

와 같은 결과가 나온다.

즉, a.splice의 두 번째 인자를 생략하고 호출하는 액션은,

a.splice(1);

// IE9, Chrome, FF, Safari

a.splice(1, a.length - 1);

// IE8 이하

a.splice(1, 0);

를 호출하는 것과 같다.

단순히 리턴받은 결과를 놓고 본다면,

모던 브라우저에서는 array.splice(1) 과 array.slice(1)의 값은 동일하다.

그래서 쉽게 눈치채지 못했던 것이다.

여튼, 결론은...

철자를 주의깊게 확인하자. -_-;;

랜덤 컬러 생성하기

ohgyun — Wed, 25 Apr 2012 20:31:31 +0900

발생일: 2012.04.25

문제:
그냥 오늘 테스트 코드를 짜다가 불쑥 생각해낸, 랜덤 컬러를 생성하는 간단한 코드~

짧고 간단해서, 종종 쓰면 편할 것 같아 메모해둔다.

해결책:
코드는 아래, 간단하다~

Math.random().toString(16).replace(/.*(\w{3})/, '#$1');

랜덤값을 생성해 16진수로 출력한 후,

대상 문자열에서 숫자 3개를 찾아 '#fff' 형태의 값을 뽑아온다.

요곤 축약형 hex code를 찾아내는 코드지만,

요래저래 활용하면 RGB 값도 한 방에 뽑아올 수 있을 듯 하다.

여튼, 테스트 용도로 적격인 코드.^^

크롬에서 단축키로 북마크 실행하기

ohgyun — Wed, 04 Apr 2012 12:12:06 +0900

발생일: 2012.04.04

문제:
북마크를 크롬에서 동기화해서 사용하고 있는데,

요고,.. 북마크를 단축키로 실행할 수가 없다.

chrome://bookmarks 페이지가 있어서 검색은 되긴 하지만, 이 역시 썩 능률적이지 않다.

좀 더 엘레강스한 방법이 없을깡~~

해결책:

역시나~~

주소창에서 옴니박스로 북마크를 실행할 수 있는 익스테션이 여럿 있다.

그 중 괜찮은 건,
- Quickmarks : http://goo.gl/XiSpY
- Bookmark Search: http://goo.gl/1Q9uB

두 개 큰 차이 없지만, Quickmarks가 더 숏컷이 간단해서 요골 선택해서 쓰고 있다~

편하다!

- 검색 아이디어를 얻은 포스트:

http://nestordave.com/2010/06/16/how-to-open-google-chrome-bookmarks-with-keyboard-shortcuts/

CSS 동적 로딩 후, 완료되었는지 확인하기

ohgyun — Mon, 26 Mar 2012 15:41:22 +0900

발생일: 2012.03.26

문제:
모바일에서 css 파일을 동적 로딩하고, 로드가 완료되면 특정 작업을 진행하려고 한다.

일전에 동적 로딩 모듈을 만들어봤던 기억으로는,
웹킷 계열은 <link> 태그에 onload를 지원하지 않아서 단순히 특정 시간 후에 load 이벤트가 발생하게 작성했었다.
다른 몇몇 라이브러리도 그렇게 했던 걸로 기억하고....

뭔가 더 좋은 방법이 없을까?

해결책:
좀 검색해보니 웹킷 계열일 경우,
타이머로 document.styleSheets의 length를 체크하는 방법으로 로드 여부를 확인하고 있다.

하지만, 페이지 내 다른 모듈에서 css 파일을 동적 로드하는 경우도 발생할 수 있으니,
length 체크만으론 부족해보인다.
좀 더 꼼꼼하게 처리하자면, styleSheets 객체 내 href 속성값까지 확인해야 정확하겠다.
(여기까진 http://www.zachleat.com/web/load-css-dynamically/ 참고)

그러다, 더 좋은 꼼수를 찾게 됐는데, 요고 아이디어가 기발하다.

link 태그를 추가하면서 동시에 같은 URL로 img 태그를 호출하고,
img 태그의 onerror 핸들러를 체크하는 거다.
이미지로 호출된 css 파일이 로드되면 파싱하는 과정에서 에러가 발생하는 것으로 로드가 완료됐음을 파악하자는 아이디어다.
(자세한 내용은 http://www.backalleycoder.com/2011/03/20/link-tag-css-stylesheet-load-event/ 참고)

load 시점을 확실히 파악할 수 있지만, 두 가지 단점이 있다.
1. 같은 리소스에 대한 요청을 2번 보내게 된다.
2. css 파일이 존재하지 않는 경우(404)에도 동일하게 onerror 핸들러가 호출된다.

스크립트에서 타이머를 돌면서 체크하는 것이 나을 지,
요청을 두 번 날리는 게 나을 지에 대한 성능은 좀 더 고려해봐야겠지만,
아이디어가 기발한 것만은 사실이다.^^

----
덧) 안드로이드(2.2, 2.3)에서 테스트해보니, image 파일이 아닌 경우 다운로드가 완료돼도 파싱 에러를 발생하지 않는다.
모바일에서 사용하기엔 적합하지 않은 방법이라 생각한다.

SVN PROPFIND request failed 오류 발생 시 프록시를 확인해보자.

ohgyun — Thu, 22 Mar 2012 17:28:04 +0900

발생일: 2012.03.22

문제:
요새 진행하는 프로젝트에서는 배포 시점에서 스크립트를 압축하지 않고,
압축 툴로 배포할 파일을 미리 만들어두는 방식을 사용하고 있다.

사용하고 있는 압축 툴은 매번 같은 이름의 새 파일을 생성하는데,
아주 가끔 이렇게 새로 만든 파일이 SVN에서 충돌을 일으키는 경우가 있었다.

일단, 커밋하려고 하면 아래 메세지가 출력된다.
svn: PROPFIND request failed on ...

더 이상한 건, Repository view에서 해당 파일을 열려고 해도 열리지 않고,
리프레시를 시도해도 바뀌지 않는다.

원인이 뭘까?

해결책:
PC를 재부팅해보기도 하고,
프로젝트를 새로 체크아웃 받기도 해보고,
다른 개발자가 리파지터리에서 삭제했다가 새 파일을 추가하고 다시 해보는 등등...

여러 가지 시도를 하다 보면 어쩌다 된다... -_-;;

이런 경우가 3~4번 있었는데, 최근 그 원인을 알게 됐다.

바로 프록시 툴이 범인이었다.

HTTP 모니터링이나 DNS 매핑 목적으로 찰스(Charles, HTTP Proxy 툴)를 계속 켜놓고 작업을 하는데,
패킷을 Recording 해놓은 상태에서 업데이트 하거나 파일을 커밋하면 이런 오류가 발생한다.

추측컨데 아마도,..
프록시가 레코딩할 때 파일에 대한 캐시를 가지고 있었는데, 파일이 갱신되니 그러나보다... (음-_-?)

여튼, 정확한 원인은 모르겠으나,.. 이 때 프록시 툴을 끄고 재시도 해보니 잘 된다.

가끔은, 리파지터리 인증 정보까지 씹어 먹는 경우가 있다. -_-
이 때엔, 리파지터리 정보를 갱신해주거나 재로그인 해주니 해결된다.

여튼, 결론은,..

SVN 오류가 날 땐, 혹시라도 모르니 프록시 툴을 한 번 살펴보자.

----
#덧. 2012.03.26

정확한 원인을 찾아냈다.
레코딩 때문이 아니었다.

해당 파일을 찰스에서 로컬 응답(Map Local)으로 사용하고 있었기 때문이다. (Fiddler의 Auto Response)
참고로, Map Local이 설정되어 있는 상태에서, 찰스 프로세르를 종료시켜도 동일한 문제가 발생한다.

테스트 후엔, 잘 끄자. -_-;;

모바일 사파리에서는 placeholder의 word wrap이 적용되지 않는다.

ohgyun — Tue, 20 Mar 2012 11:49:33 +0900

발생일: 2012.03.20

문제:
textarea에 기본 문구가 들어가고, 포커스/블러 시 기본 문구를 숨겨주는 스펙이다.

HTML5의 placeholder를 적용할 수 있는 전형적인 케이스인데,
마크업 쪽에서 value에 직접 할당을 하는 방법으로 전달해줬다.

혹시나 해서, placeholder로 기본 문구를 넣어봤더니,
아니나 다를까 문구가 길어지자 문구가 잘려보인다~

왜 이런겨~

해결책:
W3C 스펙에서 placeholder의 word wrap 부분에 대해선 정확히 정의하지 않은 모양이다.

모바일 사파리에서 문구가 길어질 경우, (overflow:hidden 과 같이) 잘려보인다.

http://stackoverflow.com/questions/7312623/insert-line-break-inside-placeholder-attribute-of-a-textarea

http://www.sitepoint.com/forums/showthread.php?793613-Placeholder-text-does-not-wrap-in-text-field

자바스크립트로 모바일 키패드 열기

ohgyun — Tue, 20 Mar 2012 11:35:34 +0900

발생일: 2012.03.20

문제:
요새 모바일 프로젝트를 진행하고 있는데,
textarea에 포커스를 주는 동시에 키패드를 뿅~하고 나타나게 하는 데서 어려움을 겪은 적이 있다.

'쓰기' 버튼을 누르면 textarea가 있는 곳으로 애니메이팅 되어 이동한 후,
textarea에 포커스를 주도록 하는 스펙이다.

이상하게도, textarea에 포커스가 들어가긴 하는데, 키패드가 열리지 않는다.
원인이 뭘까?

모바일 사파리에서 발생한다.

해결책:
모바일 사파리에서는, 사용자 이벤에 의해서만 키패드를 열 수 있다.

스크립트만으로는 키패드를 열 수 없고,
다만, 사용자 이벤트 함수 실행 범위 내에서는 가능하다.

예를 들어,
onClickButton: function (e) { // 클릭 이벤트 핸들러라 가정한다.
textarea.focus(); // 원하는 textarea의 포커스 이벤트를 호출하면 키패드가 열린다.
}

반면,
onClickButton: function (e) {
setTimeout(function () {
textarea.focus(); // 이 경우, 이벤트 핸들러의 실행 범위를 벗어나므로, 키패드가 열리지 않는다.
}, 500);
}

위 '문제'에서의 상황은,
사용자의 클릭 이벤트 핸들러에서 타이머를 사용해 애니메이팅을 구현했기 때문에,
포커스가 들어가긴 했으나 실제로 키패드가 열리진 않았던 것이다.

여기서는, textarea에 직접 포커스를 주지 않고,
글쓰기 영역까지 이동하는 것으로 스펙을 합의하는 방법으로 해결했다.
꼭 포커스를 주지 않아도 사용성에 큰 문제가 없었기 때문이다.

Mobile JS File Cache Limit

ohgyun — Thu, 09 Feb 2012 18:35:00 +0900

발생일: 2012.02.09

문제:
이번에 모바일 프로젝트를 하나 맡게 됐다.

기획서를 검토하고 구조를 잡던 중에,
예전에 어떤 가이드에서 iOS에서는 스크립트 사이즈가 몇 kb 이상이면 캐시가 되지 않는다고 했던 게 기억났다.

꽤 오래 전이었던 걸로 기억하는데,..
아직도 유효한가?

해결책:
스티브 사우더스가 모바일 캐시 파일 사이즈에 대해 아주 잘 설명해놓은 포스트가 있다.
http://www.stevesouders.com/blog/2010/07/12/mobile-cache-file-sizes/

요약해보면,
한 세션 당, (여기서 세션은 한 페이지에서 다른 페이지로 이동하는 것을 의미한다)
스크립트 한 개의 파일 당 iOS는 4MB까지, 안드로이드는 2MB까지 캐시가 된다.

물론 버전에 따라 약간씩 다르긴 하다.

또한, 폰을 잠궜다가 다시 들어갔을 때에도 캐시는 유효하다.
전원을 껐다 켰을 경우, iOS는 캐시가 모두 삭제된다.

성능 팀에서 테스트 한 자료에 의하면,
스크립트 사이즈가 작을 경우(256kb 이하, iOS4.3) 전원을 껐다 켜도 캐시가 된다고 한다.
스티브 사우더스의 실험 결과와는 차이가 있는 부분이다.

HTML 페이지의 경우, iOS3 이하에서는 25.6kb 이하가 될 때에만 캐시된다고 한다.
아마 내가 기억하고 있던 예전 사이즈가 HTML 사이즈였던 모양이다.
4.3 버전의 경우, 약간 늘어서 128kb 까지 캐시가 된다고 한다.

시간이 좀 된 자료지만, YUI 블로그의 포스트를 참고해봐도 좋겠다.
http://www.yuiblog.com/blog/2010/07/12/mobile-browser-cache-limits-revisited/

Charles 에서 HTTPS 패킷 확인하기

ohgyun — Tue, 31 Jan 2012 19:54:15 +0900

발생일: 2012.01.31

문제:
HTTP 패킷 확인 툴로 찰스(Charles)를 주로 사용하고 있다.
이번에 HTTPS 요청을 테스트할 게 있어서 모니터링을 시도했으나, 자꾸 Fail이 난다.

브라우저는 크롬을 사용하고 있다.

왜 그런 걸까.

해결책:
혹시나 해서 익스플로러에서 HTTPS 모니터링을 시도해보니, 신뢰할 수 있는 인증서냐고 물어본다.
신뢰할 수 있다고 체크하고 진행하니, IE에서는 정상적으로 보인다.

아무래도 크롬에서 인증서를 신뢰할 수 없어 튕겨내는 것 같다.

혹시나 해서, 찰스 가이드를 찾아보니 찰스가 SSL Proxying을 처리하는 방법에 대해 나와있다.

찰스는 브라우저와 SSL 웹 서버의 중간자(man-in-the-middle HTTPS Proxy)가 되는 방법으로 이를 처리한다.
브라우저는 서버의 인증서를 바라보는 대신에, 찰스가 동적으로 생성한 인증서(Charles CA Certificate)를 바라본다.
마찬가지로 응답 시에는 서버의 인증서를 찰스가 받고, 브라우저는 찰스의 인증서를 받는다.
이 방법으로 찰스는 암호화되지 않은 plain text를 볼 수 있다.
단, 브라우저가 찰스가 생성한 인증서를 신뢰해야 한다.

따라서, IE에서 그랬던 것처럼,
브라우저는 Charles CA Certificate가 신뢰할 수 있는 인증서이냐는 보안 경고를 띄운다.
신뢰할 수 있는 것이라 선택하면 진행할 수 있는 것이고, 아니라면 더 이상 모니터링 할 수 없다.

크롬은 IE와 다르게 신뢰할 수 없는 인증서면 암묵적으로 무시하나보다.
아니면 나도 모르게 언젠가 신뢰할 수 없다고 했다던가...

여튼, 요골 해결하려면 찰스가 동적으로 생성한 인증서를 신뢰할 수 있다고 크롬에게 알려줘야 한다.

1. 크롬에서 옵션 > 고급설정 > HTTPS/SSL > 인증서 관리를 클릭한다.
2. '신뢰할 수 있는 루트 인증기관' 탭을 선택하고, '가져오기' 버튼을 클릭한다.
3. 찰스가 설치되어 있는 폴더에서 charles-proxy-ssl-proxying-certificate.crt 파일을 찾아 가져온다.
4. 가져온 인증서를 신뢰할 수 있는 게 확실하냐고 묻는다.
그렇다고 하면 크롬은 찰스가 생성한 인증서를 쭈-욱 신뢰한다.

이 부분을 설정해도 해결되지 않았다면, 찰스에서 SSL 프록시를 사용할 것이라 체크했는지 확인해본다.

1. 찰스에서 Proxy > Proxy Settings > SSL 탭에서 'Enable SSL Proxing'을 선택한다.
2. Locations에 모니터링 할 호스트를 추가한다. 모든 사이트를 모니터링하고 싶을 경우, '*' 을 추가하면 된다.

요호~~ 이제 HTTPS 패킷 확인이 가능해졌다~~~~

크롬 익스텐션에서 document.documentElement 를 찾지 못하는 문제

ohgyun — Thu, 19 Jan 2012 11:42:34 +0900

발생일: 2012.01.19

문제:
며칠 전 크로미엄 버전을 18.0.1010.1 dev-m 버전으로 업데이트 한 이후로,
잘 작동하던 몇몇 익스텐션이 제대로 작동하지 않는다.

어느 부분에서 오류가 나나 찾아봤더니,
익스텐션에서 document.documentElement 를 찾지 못한다.

뭐가 문젤까?

해결책:
크롬 dev 버전이 18.0.1010.1로 업데이트 되면서 발생한 버그로 추정된다.

검색해보니 같은 문제로 2012.01.11에 버그 리포팅 된 것이 있다.
https://groups.google.com/a/chromium.org/group/chromium-bugs/browse_thread/thread/0e668df511f0b381

재현을 위해서는,
1. 익스텐션에서 아래와 같이 content script의 실행 시점을 document_start로 설정하고,
content_scripts: [
{
... (생략) ...
run_at: "document_start"
}
]

2. 스크립트 내에서 document.documentElement 를 접근하면 undefined가 뜨는 것을 확인할 수 있다.

아직 버그가 해결되지 않은 상태라 일단은,
임시 해결을 위해 스크립트 실행 시점을 기본값인 document_idle 로 변경하면 된다.