박종명의 아름다운 개발 since 2010.06

클라이언트에 데이터를 저장하다
HTML 5 에는 웹 사이트의 데이터를 클라이언트에 저장할 수 있는 새로운 자료구조인
Web Storage(웹 스토로지) 스펙이 포함되었다

Web Storage 의 개념은 심플하다
'키/ 값' 쌍으로 데이터를 저장하고 키를 기반으로 데이터를 조회하는 패턴이다

그리고 영구저장소(localStorage) 와 임시저장소(sessionStorage)를 따로 두어
데이터의 지속성을 구분할 수 있어 응용 환경에 맞는 선택이 가능하다

Web Storage 는 기존 웹 환경의 쿠키(Cookie)와 매우 유사한 개념이다
사실 거의 차이가 없어 보이기도 하다. 다만 몇 가지 쿠키의 단점를 극복하는 개선점이 도입되었다

그럼 쿠키(Cookie)는?
쿠키는 여전히 유효하고 꽤 적절한 클라이언트 저장도구 이다
HTML 5 에서 Web Storage 스펙을 새로 추가했지만 쿠키를 배제하는 것은 아니다
HTML 5 환경에서도 여전히 쿠키를 이용할 수 있다
다만 어떤 것을 사용할 지는 사용자 선택의 몫이라 하겠다

Web Storage 차이점 (쿠키의 단점?)

- 쿠키는 매번 서버로 전송 된다
웹 사이트에서 쿠키를 설정하면 이후 모든 웹 요청은 쿠키정보를 포함하여 서버로 전송된다
Web Storage 는 저장된 데이터가 클라이언트에 존재할 뿐 서버로 전송은 이루어지지 않는다
이것은 네트워크 트래픽 비용을 줄여 준다는 주요한 장점이 되겠다

- 단순 문자열을 넘어 (스크립트) 객체정보를 저장할 수 있다
문자열 기반 데이터 이외에 체계적으로 구조화된 객체를 저장할 수 있다는 것은 개발 편의성을
제공해 주는 주요한 장점이 된다. 브라우저의 지원 여부를 확인해 봐야 하는 항목이다

- 용량의 제한이 없다
쿠키는 개수와 용량에 있어 제한을 걸어 두고 있다
하나의 사이트에서 저장할 수 있는 최대 쿠키 수는 20 개이다. 그리고 하나의 사이트에서 저장할 수 있는 최대 쿠키 크기는 4KB 로 제한되어 있다. Web Storage 는 이러한 제한이 없다
(그러나 쿠키도 하위키를 이용하면 이러한 제한을 일부 해소할 수 있다.
 그리고 대부분의 시나리오에서 쿠키의 제한으로 까지 데이터를 저장할 일이 없다)

- 영구 데이터 저장이 가능하다
쿠키는 만료일자를 지정하게 되어 있어 언젠가 제거된다.
만료일자로 지정된 날짜에 쿠키는 제거되는 것이다.(만료일자를 지정하지 않으면 세션 쿠키가 된다)
만일 영구 쿠키를 원한다면 만료일자를 굉장히 멀게 설정하여 해결하기도 하였다
(그러나 과연 수 년이 지나도록  쿠키가 유지되어야 할 필요가 있을까?)

WebStorage 는 만료기간의 설정이 없다. 즉 한번 저장한 데이터는 영구적으로 존재하는 것이다
이것이 특별히 장점이 되는지는 잘 모르겠지만 쿠키와의 차이점이라는 것은 분명하다
-----

쿠키와 WebStorage 의 차이점과 개선사항에 대해 알아 보았는데 개인적으로,
Web Storage 가 쿠키보다 훨씬 좋은 이유는 없다고 본다.
다만 한가지 매번 서버로 전송되지 않는다는 특징은 꽤나 유용해 보인다
(특히 경량 환경인 모바일에서는 더욱 더)

그리고 쿠키는 더 상세한 설정이 가능해 어떤 환경에서는 더 적합해 보이기 까지 한다
쿠키에 대한 자세한 내용은 다음의 글을 참고하도록 하자
=> Cookie 제대로 알고 사용하자


로컬 스토로지(localStorage)와 세션 스토로지(SessionStorage)
Web Storgae 는 데이터의 지속성과 관련하여 두 가지 용도의 저장소를 제공한다

우선 기본적으로 Web Storage 는 쿠키와 마찬가지로 사이트의 도메인 단위로 접근이 제한된다
다시말해, A 도메인에서 저장한 데이터는 B 도메인에서 조회할 수 없다는 것이다
이것은 데이터의 보안적 측면에서 당연한 원칙이라 하겠다

- 로컬 스토로지
로컬 스토로지 저장한 데이터를 (명시적으로) 지우지 않는 이상 영구적으로 보관한다
앞서 말한대로, 도메인마다 별도로 로컬 스토로지가 생성된다
windows 전역 객체의 localStorage 라는 컬렉션을 통해 저장/조회가 이루어진다

- 세션 스토로지
세션스토로지는 데이터의 지속성과 액세스 범위에 특수한 제한이 존재한다
세션스토로지는 windows 전역 객체의 sessionStorage 라는 컬렉션을 통해 저장/조회가 이루어진다

데이터 유지 측면:
세션 스토로지는 데이터가 지속적으로 보관되지 않는다
이는 마치 브라우저 기반 세션 쿠키와 그 성질이 비슷한데, 현재 페이지가 브라우징 되고 있는
브라우저 컨텍스트 내에서만 데이터가 유지된다

로컬 스토로지는 브라우저를 종료해도 데이터는 보관되어 다음번 접속에도 그 데이터를
사용할 수 있는 반면, 세션 스토로지는 브라우저가 종료되면 데이터도 같이 지워진다.
즉 브라우저가 종료되면 세션 스토로지도 삭제된다는 것이다

데이터 범위 측면:
세션 스토로지 역시 Web Storage 의 기본 보안 처럼 도메인별로 별도로 생성된다
여기에 더불어 세션 스토로지는 같은 사이트의 같은 도메인이라 할지라도 브라우저가 다르면
서로 다른 영역이 된다(즉 브라우저 컨텍스트가 다르다)

탭 브라우징이나 브라우저를 하나 더 실행해서 같은 페이지를 실행했을 때,
이 두 페이지의 세션 스토로지는 각각 별개의 영역으로 서로 침범하지 못한다는 의미이다
(도메인만 같으면 전역적으로 공유 가능한 로컬스토로지와 구분되는 특징이라 하겠다)


브라우저 지원 현황
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Web Storage 지원 표이다
(데스크탑 용 브라우저 기준이다)

끌어다 놓기(드래그 앤 드롭, Drag & Drop)
끌어다 놓기는 사용자 편의성을 고려한 편리한 UI 기능이라 할 수 있는데,
아래 그림에서 보는 바와 같이 영역 A -> 영역 B로 특정 콘텐트를 마우스로 이동하는 것을 말한다

소스코드의 주석에 상세히 설명을 달았지만 간단히 전체적인 흐름을 설명하자면,
드래그 대상(Source)은 왼쪽 select 박스의 option 항목들이며,
드롭 대상(Target)은 오른쪽 select 박스이다

드래그 대상인 option 요소에 draggable="true" 속성을 부여해 드래그 가능한 상태로 설정하였다
그리고 dragstart 이벤트를 구현하여 드래그 액션이 시작될 때 dataTransfer 객체에
드래그 데이터(여기서는 option 의 ID)를 저장하고 있다

드롭 대상인 오른쪽 select 박스에는 dragenter, dragover, drop 이벤트를 구현하여
preventDefault 함수 호출로 select 박스가 드롭이 가능하도록 설정하였으며
dataTransfer 객체에서 드래그 데이터(여기서는 option 의 ID)를 꺼내온다
이렇게 꺼내온 드래그 데이터를  문서객체에서 조회하여 드래그 대상에서는 제거하고 드롭 대상에
추가하는 로직으로 구성되어 있다

그리고 추가로 드래그 관련 이벤트의 호출 순서를 보기 위한 코드가 각 이벤트에 추가되어 있다

아래는 데모의 실행 화면이다. 먼저 드래그가 중에 캡쳐한 화면이며,

HTML 5 는 위치 정보와 관련한 Geolocation 스펙을 포함하고 있다
(엄밀히 말하자면 이 스펙은 HTML Working Group 과 분리되어 있는  Geolocation Working Group
에 의해 표준화가 진행되고 있다고 한다)

Geolocatoin API를 이용하면
현재 웹 페이지가 실행되는 단말의 위도, 경도와 같은 위치 정보를 얻어 올 수 있다

Geolocation 지원 브라우저 현황
현재 IE를 제외한 대부분의 최신 웹브라우저에서 Geolocation을 지원하고 있다
아래 표는 http://caniuse.com/ 에서 제공하는 브라우저(버전)별 Geolocation 지원 표이다
(데스크탑 용 브라우저 기준이다)

MS IE 9 가 unknown 이라고 되어 있지만 아마 지원하게 될 것이다.
MS 가 HTML 5 지원을 강력히 표명하고 있기 때문이다

그리고 이 코드를 파이어폭스에서 실행한 결과 화면이다
(데스크탑 브라우저에서 테스트 해 봤는데, 구글 크롬과 사파리의 경우 지원은 되는데 위도,경도
 정보가 불러와 지지가 않는다. 파이어폭스와 오페라, 아이폰 사파리에서 정상 동작 확인 함 )

HTML 5 의 많은 기능 중 웹 페이지가 단순 문서 표현을 넘어 응용프로그램과 같이 동작할 수 있도록
하는 주요한 기능 중 하나가 바로 Web Workders 이다

요즘 웬만한 응용프로그램들은 멀티 프로세스, 멀티 쓰레드를 구현하고 있다
웹 페이지도 이러한 멀티 쓰레드 구현이 가능하게 된 것이다

그간 웹 페이지는 단일 쓰레드 모드에서 수행될 수 밖에 없었다
만일 값을 반환하기까지 작업이 오래 걸리는 스크립트를 수행한다면 다른 UI 작업을
스크립트 작업이 종료될 때 까지 대기해야만 했다

그러나 HTML 5 에는 Web Worker 라는 스펙을 추가 했으며 브라우저에서는 이 스펙을 기반으로
멀티 쓰레드 구동이 가능하도록 브라우저를 설계하기에 이르렀다


롱~타임(Long~ Time) 작업은 워커에게 맡기기
이제 스크립트 작업이 오래 걸린다고 해서 페이지를 멈추고 기다릴 필요가 없어졌다
웹 워커는 자바스크립트 코드를 UI 쓰레드와는 별도인 백그라운드에서 수행될 수 있도록 하는 표준적인 방법을 제공하기 때문에 웹 페이지를 가로막지 않고 스크립트를 돌릴 수 있게 되었다

다음과 같은 롱~타임 스크립트 작업에 웹워커는 안성맞춤 일 것이다
- 매우 복잡한 수학적 계산 작업
- 원격지에 있는 리소스에 대한 액세스 작업(또는 로컬 스토로지를 액세스 하는 경우)
- 백그라운드에서 조용히(?) 오랜시간 작업해야 하는 경우
- UI 쓰레드에 방해 없이 지속적으로 수행해야 하는 작업 등

사실 웹 워커 만의 지침은 없다. 일반적인 응용프로그램의 백그라운드 작업을 연상하면 된다


브라우저가 Web Worker 를 지원하나요?
HTML 5 가 아직 산업 표준이 완료된 것이 아니기에 브라우저별로 지원 여부가 상이할 수 있다
그리고 브라우저 버전별로도 지원 유/무가 다르기도 하다

따라서 웹 페이지에 웹 워커를 동작시키기 전에, 현재 페이지를 랜더링 하고 있는 브라우저가
웹 워커를 지원하는지 체크하는 것이 필수이다 (이것은 하위 호환성을 위해서도 중요하다)

브라우저의 웹 워커 지원 유/무 체크는 매우 간단한 방법으로 할 수 있다
전역 윈도우 객체의 워커(Worker) 속성을 살펴보면 된다. 아래는 샘플 코드이다

if(!!window.Worker){
      alert("이 브라우저는 웹 워커를 지원합니다")
}
else{
      alert("이 브라우저는 웹 워커를 지원하지 않습니다")
 }


Web Workers 개념도
웹 워커는 HTML 페이지에서 Worker 라는 객체를 통해 실행된다
HTML 페이지에 Worker 객체를 생성하기 위해서는 워커의 작업을 정의한 자바스크립트파일(.js)
을 Worker 객체 생성 시 전달해 줘야 한다
ex) var worker = new Worker("worker.js")

이후 롱~타임 작업은 .js 파일에 정의된 스크립트로 수행되며,
HTML 페이지와는 서로 데이터를 주고 받을 수 있는 매커니즘이 제공되는 것이다

양쪽 모두 상대에게 데이터를 송신할 때는 postMessage 라는 메서드를 이용하며
데이터를 수신할 때는 onmessage 이벤트를 통해 전달 받는다

아래 그림은 기본적인 (단일) 워커와 HTML 페이지 간 데이터 송/수신 개념도 이다

function sleep(milliSeconds){ 
  var startTime = new Date().getTime(); // get the current time  
  while (new Date().getTime() < startTime + milliSeconds); // hog cpu
}

- HTML 페이지
이제 이 워커(파일)을 이용하는 HTML 페이지를 아래와 같이 작성한다
앞서 정의한 worker.js 파일을 기반으로 Worker 객체를 생성하고 postMessage 메서드를 통해
워커로 메시지를 전달한다. 또한 onmessage 이벤트를 정의하여 워커로 부터 전달되는 메시지를
받을 수 있도록 한다. 그리고 워커의 작업을 중지시키려면 terminate 메서드를 호출하면 된다

<!DOCTYPE html>
<html>
  <head>
    <script type="text/javascript">             
      var worker;     
      function callWorker(){     
        if(!!window.Worker){ //브라우저가 웹 워커를 지원하는지 검사한다   
           
          if(worker) worker.terminate();      //워커가 이미 존재하면 종료시킨다                    
          worker = new Worker("worker.js");  //새로운 워커(객체)를 생성한다      
                      
          worker.onmessage = function(event){ //워커로부터 전달되는 메시지를 받는다
            alert(event.data);
          };
                           
          worker.postMessage("워커야! 깨어나라!"); //워커에게 메시지를 전달한다       
        }
        else{
          alert("현재 브라우저는 웹 워커를 지원하지 않습니다")
        }
      }
               
      function stopWorker(){
        if(worker){
          worker.terminate();
          alert("워커 작업이 중지되었습니다");
        }
      }
    </script>
  </head>
  <body>
    <button onclick="callWorker()">웹워커 호출</button>
    <button onclick="stopWorker()">웹워커 중지</button>   
    <br>   
    <input type="text">
  </body>
</html>

- 실행 화면
HTML 파일을 웹 브라우저(데스크 탑 사파리)에서 실행하면 10초 후에 메시지가 나타난다
또한 워커를 사용했기 때문에 브라우저가 얼어 버리는 일은 없다
즉 10초라는 대기 시간 동안에도 브라우저를 움직이거나 텍스트 상자에 글을 입력할 수 있게 되는 것이다

JQuery 는 오픈소스 자바스크립트 라이브러리이다

JQuery 를 이용해서 스크립트 작업을 하면 웹 표준에 위배되는지 걱정하지 않아도 되며
매우 간단한 문법구조로 많은 처리를 할 수 있는 장점이 있다
또한 스크립트의 안정성도 뛰어나 결과적으로 스크립트 작업의 생산성을 극대화 할 수 있게 된다

JQuery 를 페이지에서 사용하려고 하면 JQuery의 기반 라이브러리를 페이지에 정의해야 한다

일반적으로는 JQuery 라이브러리를 직접 다운로드 해서 페이지에 삽입하면 된다

1) JQuery 라이브러리 파일을 직접 페이지에 삽입하기
http://docs.jquery.com/Downloading_jQuery 에서 최신 버전 다운로드 받는다
(현재 최신 버전은 1.4.2 이다)

그리고 페이지의 head 영역에 해당 스크립트를 포함시킨다
<head>
    <script type="text/JavaScript" src="jquery-1.4.2.js"></script>
</head>

이제 해당 페이지에서는 JQuery 관련 기능을 이용할 수 있게 된다


2) 최소 버전 JQuery 라이브러리 사용하기
JQuery 라이브러리는 풀버전과 최소화버전 두 가지가 제공된다
최소화버전은 사이즈가 작은 대신 디버깅 환경은 제공되지 않는다는 특징이 있다
따라서 개발시에는 풀버전으로 하고 라이브 적용 때에 최소화 버전으로 변경하는 것을 생각해 볼 수 있다. 최소화 버전 역시 JQuery 홈페이지에서 다운로드 받을 수 있다
<head>
    <script type="text/JavaScript" src="jquery-1.4.2.min.js"></script>
</head>


3) 구글의 CDN 서비스 사용하기
CDN 서비스는 굉장히 빠른 속도로 컨텐트를 내려 받을 수 있는 환경을 제공한다
구글에서 JQuery 라이브러리 다운로드를 위해 CDN 서비스를 무료로 제공해 주고 있다

다음의 URL 이 JQuery 가 호스팅 된 곳이다

최소화 버전)
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js

풀버전)
http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.js

역시 이 URL을 head 에 스크립트로 명시하면 된다
<head>
  <script type="text/JavaScript"  src=http://ajax.googleapis.com/ajax/libs/jquery/1.4.2/jquery.min.js></script>
</head>


JQuery 서적에서는 구글의 CDN 서비스를 이용할 것을 다음과 같은 사유로 권장한다
- 안전하고 믿을 수 있다
- 다운로드가 빠르다
- 어디서나 사용할 수 있다(JQuery.js를 늘 들고 다니지 않아도 된다)


3. 마이크로소프트의 CDN 서비스 사용하기
마이크로소프트 역시 구글처럼 JQuery를 CDN 으로 무료 서비스를 제공한다
다음 URL이 그것이다

http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.js
http://ajax.microsoft.com/ajax/jquery/jquery-1.4.2.min.js

팀장님이 알려주신 오픈페인트 서비스
오전에 관련 앱과 게임을 다운받아 보고 조금 사용해 봤다

외국에서 개발한 이 서비스는 아이폰 무료 게임들의 게임 스코어 정보를 저장하여 다른 사람과
랭킹 정보를 공유할 수 있도록 해주며 친구를 맺게 하여 지속적인 공유가 가능토록 한다
또한 채팅 및 게시판과 같은 커뮤니티 기능을 제공하며 트위터와 페이스북과의 연계성도 가지고 있다

예를 들어 특정 게임 실행 후 스코어를 트위터에 바로 등록할 수 있는 기능이 있다
트위터에 자동으로 등록된 글을 보니 게임 시코어는 물론 해당 게임의 앱스토어 URL도 같이 표시된다
일종의 광고인 게임 광고인 셈이다

HTML5 로 제작된 멋진 데모들을 제공하는 사이트이다
음.. 놀랍군.

이건 뭐.. 그럴싸한 HTML5 어플만들려면 자바스크립트를 자유자재로 다룰 수 있어야 겠구만!!

http://www.aplossystems.co.uk/articles/look_at_html_5_canvas/

자바스크립트의 영역이 이렇게 커질(?)줄 몰랐다. 아오~

우리 프로젝트에도 멋진 자바스크립트 개발자가 있어야 하겠지...

아이폰의 사파리 브라우징을 제공하는 사이트가 있었구먼

http://www.testiphone.com/

떱! 난 그것도 모르고 여태껏 내 아이폰 열어서 수동으로 확인했구먼...

이런.. 역시... Know Where 얌... 모르면 손발이 고생한다더니.. ㅎ

그리고 아래는 위 요청에 대한 응답 헤더와 바디 정보의 일부이다
응답 컨텐츠 타입이 자바스크립트이며 JSON 특유의(?) 데이터 포맷인 바디 구성이 눈에 띈다

비동기 호출 (갱신) 주기
그렇다면, 비동기 호출 주기는 과연 얼마로 설정했을까? 일명 폴링 주기이다

폴링주기는 웹 사이트의 성능과 웹 서버의 부담이라는 측면에서 최대한 긴 것이 좋으며
최대한 실시간 같은 갱신 효과라는 측면에서는 최대한 짧은 것이 좋다

폴링주기 설정은 사이트의 특징과 사용 패턴, 웹서버 가용성 및 규모, 네트워크 환경에 따라
환경에 맞도록 최적화 시키는 것이 중요한데, 트위터에서는 어떻게 했는지 궁금해 졌다

비동기 호출을 일정기간 캡쳐했다. 그리고 각 호출간 시간차를 살펴 보았다
재미있는 것은 폴링 주기가 일정하지 않다는 것이다

즉 호출간 매번 일정한 간격이 아니라 조금씩 다른 간격으로 호출되는 것이다
그러나 패턴은 있었다. 항상 같은 간격은 아니지만 간격의 패턴은 유지되고 있었다

대체로 살펴봤을때,
45초 -> 1분 7초 -> 45 - > 1분 7초....와 같은 패턴이 많이 보였으며,
경우에 따라 2분 32초 -> 3분 48초 -> 5분 -> 3분 48초 -> 2분 32초... 와 같은 패턴도 보였다

음... 트위터에서는 항상 같은 간격으로 호출하지 않는다는 것은 명백하다
그러나 일정한 패턴은 유지하고 있다. 그럼 이유는???

글쎄....
처음엔 어떤 상황에 따라 패턴이 분리되지 않나 싶어 꽤 오랫동안 지켜봤다
예를 들어 사이트가 로딩 된 후 사용의 행동이 오랫동안 감지 되지 않을 경우에 간격을 조정한다?
라는 식으로 말이다

즉 항상 일정한 폴링주기가 아니라 나름대로 상황에 맞게 최적의 주기를 설정한 것이 아닌가 했다.
그리고 그 상황과 패턴을 찾고 싶었다

몇 가지 가설을 세워놓고 꽤 오랫동안 패킷을 지켜봤으나 딱 떨어지지는 않았다
다시말해 폴링 주기가 일정한 패턴으로 변경되는 상황을 알 수 없었다

나의 가설이 틀렸던지 아니면 정말 랜덤일수도 있다
몇가지 주기를 설정해 두고 랜덤하게 꺼내 쓴다... 처럼...

뭐.. 어쨋던 정확한 상황을 알지 못했지만 (웬지 관련성이 있을 것만 같은) 한가지는 목격(?)했다
새로운 트윗이 생긴경우 since_id 파라메타 값이 바뀐다는 것이다
그리고 계속 이 since_id는 변화가 없다가 다시 새로운 트윗이 생기면 바뀌는 식이다

어쨋던 점심시간,, 읽고 싶은 책은 1페이지도 못 읽고 문득 든 생각때문에
몇 시간을 보내 버렸다.......