HTML5 Device API 표준화 현황 (2012년 10월 19일 기준)

Dev 2012. 10. 19. 16:19

HTML5 Device API 표준화 현황 (2012년 10월 19일 기준)

출처: http://www.w3.org/2009/dap/


W3C의 표준화 단계는 WD -> LC -> CR -> PR -> Rec

- WD: Working Draft

- LC: Last Call

- CR: Candidate Recomendation

- PR: Proposed Recomendation

- Rec: Recomendation


스펙별 진행상태

+ Battery Status API, 08 May 2012, CR

+ HTML Media Capture, 12 Jul 2012, LC

- Web App에서의 사진찍기, 녹음하기 방식 규정

+ Media Capture and Streams, 28 June 2012, WD

- media stream 접근 API 규정

+ Network Information API, 7 June 2011, WD

+ Ambient Light Events, 2 August 2012, WD

+ Proximity Events, 12 Jul 2012, WD

+ Vibration API, 08 May 2012, CR

+ Web Intents, 26 June 2012, WD

- Web App 사이의 상호 발견 및 RPC 방식 규정

+ Web Intents Addendum Local Services, 04 Oct 2012, WD

- Web Intent를 통해 브라우저가 Web Intent Service를 발견하고  통신하는 방법 규정

+ Pick Media Intent, 12 July 2012, WD

- Web App에서 사용자의 미디어 갤러리 접근 방식 규정

+ Pick Contacts Intent, 12 Jul 2012, WD

- Web App에서 사용자의 연락처 정보 접근 방식 규정

+ Network Service Discovery, 04 Oct 2012, WD

- 네트웍 상에 공개된 서비스를 발견하는 프로토콜 규정

+ Menu API, 진행상황 없음

+ Permissions for Device API Access, 5 Oct 2010, WD


총 14개의 HTML5 Device API 표준 중 LC이상이 3개, WD이하가 11개.

- Battery Status API, 08 May 2012, CR

- HTML Media Capture, 12 Jul 2012, LC

- Vibration API, 08 May 2012, CR

- Media Capture and Streams, 28 June 2012, WD

- Network Information API, 7 June 2011, WD

- Ambient Light Events, 2 August 2012, WD

- Proximity Events, 12 Jul 2012, WD

- Web Intents, 26 June 2012, WD

- Web Intents Addendum Local Services, 04 Oct 2012, WD

- Pick Media Intent, 12 July 2012, WD

- Pick Contacts Intent, 12 Jul 2012, WD

- Network Service Discovery, 04 Oct 2012, WD

- Menu API, 진행상황 없음

- Permissions for Device API Access, 5 Oct 2010, WD


아직 갈 길이 멀다. 브라우저에서 모든 일을 할 수 있는 세상이 빨리 오길...

(이상)


저작자표시 비영리 변경금지
Posted by ingeeC
,

Javascript MVC Framework

Dev 2012. 8. 14. 19:23

Modern Javascript WebApp 동향

+ SPA : Single Page Application

- 하나의 HTML 파일(Single Page)에 여러 화면을 담아 제공

- 화면이 바뀔 때마다 새로운 HTML 파일을 읽어들일 필요가 없어지기 때문에 응답성이 개선됨

- WebApp의 현재 상태/화면을 hash-url(한 HTML 페이지 안의 위치를 나타내기 위해 사용하는 #으로 시작되는 http://some.domain.com/some-page.html#some-location 과 같은 형태의 URL)로 관리

- hash-url을 이용하여 WebApp의 상태/화면 관리하는 개념을 Routing이라고 하고, hash-url을 해석해서 WebApp의 상태/화면을 관리하는 모듈을 Router라고 함

+ Off-line enabled WebApp

- HTML5의 off-line 지원 기능을 활용, 네트웍에 연결되어 있지 않아도 로컬에 캐시된 WebApp 코드를 이용해서 WebApp을 실행

- Off-line enabled WebApp이 되려면 서버의 도움 없이 실행될 수 있도록 모든 프로그램 로직이 front-end에 존재해야 함

+ BaaS : Back-end as a Service

- WebApp의 front-end에 모든 로직을 담고 정형화된 back-end를 RESTful API 형태로 제공하는 개념

- Back-end가 제공하는 데이터를 가공하는 모든 로직은 front-end에 존재해야 함

=> SPA, Offline enabled Web App, BaaS 등 Modern JS WebApp은 기본적으로 규모가 큰 front-end 코드를 요구함

=> front-end code의 규모가 커짐에 따라 소스코드의 유지/보수 비용을 절감하기 위해 MVC 패턴을 이용해서 WebApp 코드를 구조적으로 만들 필요가 생김


MVC 디자인 패턴

+ 디자인 패턴이란?

- 재사용 가능한 소프트웨어 디자인(설계)

- 검증된 문제 해결 방식

- 필요에 따라 유연하게 적용 가능

+ MVC 패턴이란?

- Model, View, Controller로 소프트웨어 구조를 나눔

- Model은 데이터를 표현

- View는 화면(보통 아무런 로직도 없음)을 표현

- Controller는 M과 V 사이의 조율, 비즈니스 로직을 처리

- 전통적으로 서버-사이드에서 많이 사용됨

MVC를 지원하는 Javascript f/w 종류

+ JavaScriptMVC

- 완성도 높은 성숙한 기술

- all-in-one 솔루션

- 대규모 프로젝트에 적합

- GrooveShark(미국의 음원 제공 서비스)에 적용됨

+ Backbone.js

- 경량

- SPA 제작에 최적

- 다른 컴포넌트와 함께 사용하기 좋음

- MetaLab, SoundCloud, BitTorrent 등에 적용됨

+ Spine.js

- 경량

- Class 개념 제공

- Backbone API에 기초하여 Backbone 개발자라면 추가 학습 비용이 낮음

+ Sammy.js

- Route 기반 앱 개발에 적합한 경량 프레임워크

- Controller만 제공 (M과 V를 제공하지 않음)

- PaperlessPost에 적용됨

+ SproutCore

- 데스크탑 어플 같은 Rich함을 지향하는 앱 개발에 적합

- 대규모 엔터프라이즈 앱 개발에 적합

- 애플 MobileMe에 적용됨


Reference

- MVC and the Web

http://kanian77.wordpress.com/category/software-engineering/mvc/mvc-and-the-web/page/3/

- Tools For jQuery Application Architecture (Extended Slides)

http://addyosmani.com/toolsforjqueryapparchitecture/

- 자바스크립트 웹어플리케이션 개발경험기

http://blog.outsider.ne.kr/787

- Digesting JavaScript MVC ? Pattern Abuse Or Evolution?

http://addyosmani.com/blog/digesting-javascript-mvc-pattern-abuse-or-evolution/

- Scaling Isomorphic Javascript Code

http://blog.nodejitsu.com/scaling-isomorphic-javascript-code

- MVC Architecture for JavaScript Applications

http://michaux.ca/articles/mvc-architecture-for-javascript-applications


(이상)

저작자표시 비영리 변경금지
Posted by ingeeC
,

Javascript 모듈화 (CommonJS와 AMD)

Dev 2012. 7. 3. 09:26

자바스크립트(Javascript) 모듈화


배경

- Web App 로직의 비중이 서버에서 클라이언트로 이동하면서 클라이언트 코드가 거대화, 엔터프라이즈화 됨

- 클라이언트 Web App 개발 언어는 자바스크립트(이하 JS)

- JS를 본격적인 프로그래밍 랭귀지로 사용하려면 모듈화가 선결조건

- 모듈화의 중요성 

==> 유지보수의 간편함

- 시스템이 독립적인 모듈로 느슨하게 결합되어 있어야 관리하기 쉽다

- 어느 한 부분을 수정해도 전체 시스템에 영향을 주지 않는다


히스토리

- JS 모듈 관리를 위한 코딩 표준을 정의하려는 노력이 있었음(CommonJS와 AMD)

- CommonJS

- JS의 활용성을 높이려는 자발적 워킹그룹

- JS를 범용 프로그래밍 언어로 만드는 것이 목적

- 2009년 1월 Kevin Dangoor가 SSJS(서버-사이드 자바스크립트)에 대한 아이디어를 제시하고 사람들을 모으기 시작

- JS 모듈 관리에 관한 코딩 표준을 제시함

- AMD(Asynchronouse Module Definition)

- 브라우저에서의 JS 모듈 활용성을 높일 목적으로 CommonJS에서 파생됨

- AMD는 CommonJS와 interoperable

- jQuery를 비롯 다수의 오픈소스 솔루션이 AMD를 지지

- jQuery의 경우, 1.7부터 AMD 모듈 등록 기능을 지원하기 시작

- CommonJS와 마찬가지로 JS 모듈 관리에 관한 코딩 표준을 제시함

- RequierJS

- AMD 표준을 준수하는 가장 인기 있는 JS Loader

- 기존 JS 로딩의 문제(<script> 태그를 이용 JS 파일을 로딩할 경우...)

- 로딩이 시퀀셜하게 진행

- JS 파일간 dependency가 없을 경우 시퀀셜하게 로딩하는 것은 시간 낭비

- JS 파일간 dependency가 있을 경우 개발자가 script 태그 배열 순서를 신경 써야 함

- RequireJS를 비롯한 asynchronous loader의 역할

- JS를 비롯한 모든 리소스를 가능한 병렬로 로딩

- JS 파일간 dependency를 JS Loader가 지능적으로 관리


전망, 결론

- CommonJS, AMD가 해결하려는 문제의 핵심은 모듈화

- 모듈화는 JS가 보다 범용적인 언어로 자리매김하는 단초가 될 것

- 모듈화는 JS framework(이후 f/w) 패러다임이 변화하는 토대가 될 것

- 지금까지는 모든 것을 해결하는 다목적 f/w가 주류

- 글로벌 네임스페이스를 차지하는 대형 f/w은 다른 JS 코드와 충돌하기 쉽다

- 특정 영역에 집중하는 작은 모듈이 관리하기 쉽다

- 이제부터는 필요한 기능별로 f/w 모듈을 로드하여 사용하는 시대

- 특히 크기가 중요한 모바일 환경에서 중요성 증대

- HTML5가 지원되는 스마트폰 환경에서 활용사례 증가 예상(로컬 스토리지를 통해 모듈 로딩 성능 향상 가능)


(이상)

저작자표시 비영리 변경금지
Posted by ingeeC
,

Git(깃)과 GitHub(깃허브) 요약

Dev 2012. 4. 27. 15:42

솔직히 말해서, 

Subversion 이후로 새로운 버전 관리 툴이 필요할 거라는 생각을 하지 않았다. 그래서 Git(깃)이 세상에 나왔을 때 나는 분노했다. 뭣하러? 새로운 톨이 나오고, 사람들이 열광하고, 아쉬울 것 없던 내가 Git을 배우게 된 걸까?

하지만, Git에 대해 요모조모 알고난 지금, 난 누구에게도 자신있게 Git을 권할 수 있다. 이제 Subversion과 Git 중에 하나 고르라고 하면 Git을 추천한다.


GitHub

- SourceForge와 Google Code를 빠르게 앞서고 있는 오픈소스 프로젝트 근거지

- 단순한 소스 호스팅 뿐 아니라 개발자들끼리의 SNS로 기능하고 있음

- Subversion (SVN)을 오픈소스 호스팅 기반으로 사용하는 SourceForge와 달리 Git을 소스 호스팅 도구로 사용

- 코드 생산자가 아니라 소비자로 활동하기에도 좋다


Git

- Git은 2006년경 BitKeeper라는 리눅스 커널 개발에 쓰던 분산형 패치 도구에 대한 대안으로 리누스 토발즈가 직접 개발한 분산형 소스 콘트롤(Source Control Management) 시스템

- Offline으로 동작 가능하며 거의 모든 기능의 반응 속도가 기존 버전 관리 툴을 압도 (Why Git is Better than X 참고)

- GitHub를 쓰기 위해 Git을 사용하는 사람이 늘고 있음 (GitHub가 활성화 되었음을 의미)


참고자료

- Github, 코드 개발 기반 소셜 네트웍 (http://channy.creation.net/blog/626)

- 웹 항해일지 - GitHub 특집 (http://occamsrazr.net/tt/254)

- The Git 슬라이드 (http://www.slideshare.net/dalinaum/the-git)

- Why Git is Better than X (http://whygitisbetterthanx.com/)

- Git 사용기 (http://help.github.com/be-social/)

- Pro Git (http://dogfeet.github.com/articles/2012/progit.html) 

: 이 책, "Pro Git"은 꼭 읽어야 한다. Git에 대한 완벽한 안내서. 무려 한글! 내용 충실! 책을 이렇게 공개하면 종이책이 팔리지 않을텐데... 저자가 고마우면서도 걱정되는 복잡한 기분.


(이상)


저작자표시 비영리 변경금지
Posted by ingeeC
,

HTML5 버전 Cut The Rope 개발 후기

Dev 2012. 2. 9. 15:12
게임 Cut The Rope의 HTML5 버전이 공개됐다. IE를 비롯 Safari, Chrome, Firefox 등 PC 브라우저는 물론, iPhone, iPad, Android Phone, Android Tablet 등 모바일 기기의 브라우저에서도 실행된다. 
이 개발자들.. 멋지게도 귀중한 경험을 후기로 남겼다. 가치 높은 글이라 줄거리를 요약하여 옮겨온다.

게임:  http://www.cuttherope.ie/ 
원본:  http://www.cuttherope.ie/dev/ 

+ 'Cut The Rope' 게임의 Objective-C 코드를 html5 코드로 포팅하기로 결정
+ 쉽지 않은 도전
- 라이브러리를 제외하고 15,000 라인에 이르는 방대한 규모의 프로그램
- 물리엔진, 애니메이션엔진, 드로잉엔진이 타이트하게 결합되어 최적화되어 있는 상태

+ JavaScript에 희망을 검
- 초기의 JavaScript는 스크립트 실행을 위한 느린 언어
- 현재의 JavaScript는 JIT를 이용 native에 근접한 실행속도를 내는 언어

+ JavaScript 프로그래밍을 위해서는 컴파일 언어를 사용할 때와는 다른 mindset이 필요
+ JavaScript는 struct를 미지원
- JavaScript의 Object를 struct 대용으로 사용할 경우 여러가지 어려움을 겪게됨
- JavaScript에서 Object를 함수의 인자로 전달하면 call by reference됨.
- 따라서 callee함수에서 Object 인자를 수정하면 caller에 영향을 줌
- 그리고 JavaScript에서 Object 생성은 무척 비싼 연산
- 그래서 함수 호출시 Object 전체를 파라메터로 넘기는 대신 필요한 field만 넘기는 방법을 선택함
+ JavaScript의 OO(Object Oriented) 개념은 전통적인 OO 언어와 다름
- JavaScript는 prototype에 기반한 OO 개념을 제공하나 이는 Objective-C와 이질적
- 그래서 JavaScript에 class 기반 OO를 가능하게 하는John Ressing (of jQuery)의 공개 라이브러리를 이용하기로 함

+ Objective-C 코드 말고도 OpenGL을 HTML5 Canvas API로 포팅해야 했음
- 이 작업은 순조롭게 진행됐음
- HTML5 Canvas가 하드웨어 가속을 지원하는 브라우저 위에서 놀랄만큼 빠른 rendering 성능을 보였음
- 일부 기능 (예를 들어 anti-alias line 그리기 기능)의 경우, HTML5 Canvas가 OpenGL ES보다 훌륭했음 (성능/기능 측면에서)

+ 최종적으로 브라우저에서 실행되는 15,000라인 규모의 코드를 만들어냄
- 3주가 지난후, 기본적인 물리엔진, 드로잉엔진, 애니메이션을 위한 타이머를 개발함
- 4주가 지난후, 기본적인 마우스 처리가 구현되어 실제 게임을 실행할 수 있게됨
- 물리엔진은 intensive한 연산 덩어리, 하지만 JavaScript가 놀라운 실행성능을 보여줌. 이제 JavaScript가 느린 언어라는 선입견을 버려야함

+ 개발을 위해 사용한 도구
+ 코딩을 위해 Visual Web Developer 2010 (free version 제공됨) 사용
- JavaScript, css 구문에 대한 autocompletion 기능 제공
+ 실행 및 디버깅을 위해 ie9을 비롯한 firefox, chrome, safari 브라우저 사용
- 동일한 HTML5 코드로 모든 브라우저를 지원할 수 있음을 확인
+ ie9의 JavaScript profiler를 사용하여 실행성능을 최적화함
- 코드의 병목 지점을 찾아 개선함으로써 10배 이상 실행 성능을 향상시켰음

+ 산출물
+ resource loader
- 본 게임의 리소스 크기(6MB)는 일반 웹사이트의 리소스 크기(200~300KB)에 비해 매우 큼
- 큰 리소스들을 안정적으로 pre-loading하고 loading schedule을 조정할 수 있는 JavaScript 'resource loader' 라이브러리를 개발함, 그리고 이를 free open source로 공개함

(이상)

저작자표시 비영리 변경금지
Posted by ingeeC
,

Device API 표준화 현황 (2012년 1월 30일 기준)

Dev 2012. 1. 30. 20:16
HTML5 Device API 분야의 표준화 현황을 정리한다. 현황을 정리하면서 느낀점은 다음과 같다.
- W3C가 부지런히 움직이고는 있지만 Device API는 표준화 초기 단계다 (대부분 Working Draft 단계...)
- 애플보다는 안드로이드 쪽이 그나마 기민하게 반응하고 있다 (오십보 백보지만 그래도...)
 
phone call
- <a href="tel:phone_number"> URI를 통한 전화 걸기 기능
- 표준화 현황: de facto 표준 (W3C 공식 표준 아님)
- 단말 지원 현황: iOS, Android, 블랙베리 등 거의 모든 모바일 기기가 지원함
- 참고 자료: http://www.mobilexweb.com/blog/click-to-call-links-mobile-browsers
 
Indexed DB
- 인덱스가 부여된 Javascript Object 들의 local storage
- W3C가 Web SQL 표준을 폐기하고 대안으로 제시
- 표준화 현황: W3C Working Draft (06-December-2011 규격이 최신: http://www.w3.org/TR/IndexedDB/)
- 단말 지원 현황: 거의 모든 모바일 기기가 지원 않음
- 참고 자료: http://www.html5rocks.com/en/tutorials/indexeddb/todo/

Media Capture
- 카메라, 캠코더, 마이크 연동 규격
- 표준화 현황: W3C Working Draft (14-April-2011 규격이 최신: http://www.w3.org/TR/html-media-capture/)
- 단말 지원 현황: iOS 지원 않음. Android 지원함 (3.0 부터)
- 참고 자료: 
    - http://www.h-online.com/open/news/item/HTML5-Access-to-cameras-and-microphones-1043319.html
    - http://www.wonsuk73.com/19
 
File API
- 로컬 파일 읽기/쓰기 API
- 표준화 현황: W3C Working Draft (20-October-2011 규격이 최신: http://www.w3.org/TR/FileAPI/)
- 단말 지원 현황: iOS 지원 않음. Android 지원함 (3.0 부터)

Touch Event
- 터치 이벤트 규격
- 표준화 현황: W3C Candidate Recommendation
    - Working Draft보다 안정된 상태
    - 15-December-2011 규격이 최신: http://www.w3.org/TR/touch-events/
- 단말 지원 현황: 거의 모든 모바일 기기가 지원함

Contacts API
- 사용자의 연락처 정보에 접근하기 위한 API
- 표준화 현황: W3C Working Draft
    - Stable Draft 상태 (Last Call)
    - 16-June-2011 규격이 최신: http://www.w3.org/TR/contacts-api/
- 단말 지원 현황: 거의 모든 모바일 기기가 지원 않음 (규격의 안정도를 고려할 때 의외)

Calendar API
- 사용자의 일정 정보에 접근하기 위한 API
- 표준화 현황: W3C Working Draft (19-April-2011 규격이 최신)
- 거의 모든 모바일 기기가 지원 않음
 
Task API
- 사용자의 to-do 업무 정보에 접근하기 위한 API
- 표준화 현황: 담당 에디터가 없음, Calendar API에 합쳐질 전망
- 참고 자료: http://www.w3.org/TR/calendar-api/ 

Geolocation API
- 사용자의 위치 정보에 접근하기 위한 API
- 표준화 현황: W3C Candidate Recommendation
    - Working Draft보다 안정된 상태
    - 07-September-2010 규격이 최신 (http://www.w3.org/TR/geolocation-API/)
- 단말 지원 현황: 거의 모든 모바일 기기가 지원

Messaging API
- SMS, MMS, eMail 관련 API
- 표준화 현황: W3C Working Draft (14-April-2011 규격이 최신: http://www.w3.org/TR/messaging-api/)
- 단말 지원 현황: 거의 모든 모바일 기기가 지원 않음
 
 (끝)
 
저작자표시 비영리 변경금지
Posted by ingeeC
,

jQuery Mobile 요약

Dev 2012. 1. 16. 16:59
jQuery Mobile(이후 JQM)의 개요에 대해 간단히 요약한다.

JQM (jQuery와 JQM의 관계)?
- JQM은 jQuery의 확장팩 (jQuery의 light-weight 버전이 아니다)
- JQM은 jQuery를 기반으로 모바일 Web App 개발을 지원하기 위한 코드(HTML/CSS/Javascript)를 추가한 일종의 플러그인(plulg-in)

JQM은 무엇을 제공하나?
- Touch 인터페이스 처리
- 다양한 모바일 OS/Device에 대한 지원
- Theme(UI 테마) 체계

jQuery Plug-in?
- jQuery의 기능을 확장하기 위해 widget 또는 코드 모듈을 추가할 수 있도록 jQuery 팀이 제공하는 아키텍처
- 전세계 jQuery 개발자들에 의해 다양한 plug-in들이 개발/발표되고 있음

jQuery Mobile을 쓰려면 어떻게 하나?
- Web App 소스에 다음 3줄을 추가하면 준비 끝!
<link rel="stylesheet" href="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.css" />
<script src="http://code.jquery.com/jquery-1.6.4.min.js"></script>
<script src="http://code.jquery.com/mobile/1.0/jquery.mobile-1.0.min.js"></script>

(이상)
 
저작자표시 비영리 변경금지
Posted by ingeeC
,

Javascript 스터디 노트 2 (Prototype Chaining에 대하여...)

Dev 2012. 1. 3. 13:17
자바스크립트(이후 JS)는 객체지향 언어다. 하지만 c++이나 Java처럼 타입(class)에 기반한 객체지향 언어가 아니라 객체(object: 실제 인스턴스)에 기반한 객체지향 언어다. JS는 prototype chain을 통해서 객체지향적 특징을 구현한다. 이에 대해 요약한다.

Function & Constructor
- JS는 함수를 intrinsic한 객체로 취급한다. 즉, 함수를 Number나 String, Date 등과 동등한 객체로 취급한다.
- JS의 함수 중 객체를 리턴하는 함수를 Constructor (생성자 함수 객체)라고 한다.
- JS의 Constructor는 객체를 생성하기 위해 new 연산자와 함께 사용된다.
- JS의 Function 객체는 prototype 속성과 constructor 속성을 갖는다 (이 글에서 소문자로 시작하는 constructor는 Function 객체가 갖고 있는 속성의 이름이며, 대문자로 시작하는 Constructor는 생성자 함수 객체를 말한다).
- Constructor의 constructor 속성은 자기 자신을 가리킨다 (생성자 함수 객체 자신을 가리킨다).
- Constructor의 prototype 속성은 Constructor가 생성하는 객체의 [[prototype]] 객체를 가리킨다 (이 글에서 prototype은 Function 객체가 갖고 있는 속성의 이름이며, [[prototype]]은 JS가 객체지향적 특성을 구현하기 위해 사용하는 프로토타입 객체를 말한다. JS의 원본 스펙인 ECMA-262 스펙에서 [[prototype]] 표기법을 빌려왔다).

Prototype Chaining
- 모든 JS 객체는 ECMA-262 스펙에 따라 자신의 [[prototype]] 객체를 알고있다. 하지만 이를 구현하는 방식은 제각각이다. WebKit 계열의 JS 엔진은 모든 객체에 __proto__ 라는 이름의 속성을 부여하여 [[prototype]] 객체를 노출한다. 반면 IE는 [[prototype]] 객체를 외부에 노출하지 않는다 (__proto__라는 이름의 속성이 없다). 그렇더라도 IE 역시 ECMA-262 스펙을 만족시키는 JS 엔진이다.
- 어떤 JS 객체가 외부로부터 메소드나 속성을 요구받으면, 자기가 갖고 있는 메소드나 속성 리스트를 먼저 확인하고, 없을 경우 [[prototype]] 객체에 요구된 메소드나 속성이 있는지 확인한다. 이런 확인 작업을 [[prototype]] 객체의 [[prototype]] 객체를 거쳐 최상위 [[prototype]] 객체까지 계속한다. 이를 prototype chaining이라고 한다.

JS 객체 구현의 실제
다음과 같은 객체 hierarchy를 JS로 구현한다고 가정해보자.

(만들고자 하는 객체 hierarchy와 이를 구현한 생성자 함수)


- Rect 객체는 w(폭)과 h(높이)를 속성으로 갖는다
- PosRect 객체는 Rect 객체로부터 w, h 속성을 계승하고, x(시작점의 x좌표)와 y(시작점의 y좌표)를 추가 속성으로 갖는다

Rect() 생성자 함수와 PosRect() 생성자 함수를 위와 같이 정의하면 JS 엔진은 아래와 같은 관계의 객체들을 만들어낸다. 실체가 없는 타입이 아니라 메모리 상에 실제로 존재하는 객체가 만들어지는 것이다.

(생성자 함수와 prototype 객체 사이의 관계)


- PosRect : 생성자 함수 객체
- PosRect.prototype : PosRect 생성자 함수를 통해 생성하는 객체의 [[prototype]] 객체 
- Rect : 생성자 함수 객체
- Rect.prototype : Rect 생성자 함수를 통해 생성하는 객체의 [[prototype]] 객체
- Object : JS 엔진에 내장된 생성자 함수 객체
 
이 상태에서 다음 코드를 통해 PosRect 타입의 객체 pr을 생성하면... 
pr = new PosRect(1, 2, 3, 4);

JS 엔진의 메모리에는 다음과 같은 관계를 갖는 pr 객체가 만들어진다.

(생성자 함수를 통해 만들어낸 객체와 prototype 객체 사이의 관계)
 

샘플코드 (부록?)
이상의 관계를 파악할 수 있는 샘플 코드를 첨부한다.

test_prototype-chain.html

 
위 파일을 크롬, 사파리 등의 웹킷계열 브라우저 또는 파이어폭스 브라우저로 로드하면 다음과 같은 결과를 얻을 수 있다. IE는 __proto__ 속성을 지원하지 않기 때문에 원하는 결과를 얻을 수 없다 (ECMA-262 스펙이 __proto__ 속성의 존재를 강제하지 않기 때문에 __proto__ 속성을 지원하지 않더라도 IE가 잘못한 것은 아니다). 아래 결과를 통해 JS의 prototype chain 구성 방식을 확인할 수 있다.

var o= pr;
(0) o = PosRect( x=1, y=2, w=3, h=4 )
(0) o.isCustomizedObject = true
(0) o.prototype = undefined
(0) o.__proto__ = PosRect( x=undefined, y=undefined, w=undefined, h=undefined )
--- o= o.__proto__;
(1) o = PosRect( x=undefined, y=undefined, w=undefined, h=undefined )
(1) o.isCustomizedObject = true
(1) o.prototype = undefined
(1) o.__proto__ = Rect( w=undefined, h=undefined )
--- o= o.__proto__;
(2) o = Rect( w=undefined, h=undefined )
(2) o.isCustomizedObject = true
(2) o.prototype = undefined
(2) o.__proto__ = [object Object]
--- o= o.__proto__;
(3) o = [object Object]
(3) o.isCustomizedObject = undefined
(3) o.prototype = undefined
(3) o.__proto__ = null
   
결론
JS가 Class라는 개념을 지원하지 않기 때문에 객체들 사이의 관계를 간편하고 멋진 StarUML을 통해 클래스 다이어그램으로 그려낼 수 없었다. Class들 사이의 관계가 아니라 Object instance들 사이의 관계를 그려야 했는데, StarUML이 이를 지원하지 않아 손으로 그려야 했다. 그만큼 JS의 객체 hierarchy 구현 방식은 일반적인 객체지향 언어와 다르며 독특하다. JS는 객체들 사이의 계승관계를 런타임에 만들고 변경할 수 있는 유연한 언어다. 

(이상)
 
저작자표시 비영리 변경금지
Posted by ingeeC
,

HTML5 프레임 애니메이션 저작 환경 현황 (2011년 12월 기준)

Dev 2011. 12. 29. 16:39
프레임 애니메이션이란 영화처럼 한 프레임 한 프레임의 움직임으로 표현하는 애니메이션이다 (한땀 한땀...). 쉽게 말해 플래시 애니메이션을 말한다. "Flash 대 HTML5" 논쟁에서 시작, HTML5가 대중의 관심을 듬뿍 흡입한 상황이지만, 과연 현실이 HTML5로 플래시를 대체할 수 있는 상황인지 궁금했다.

요약
* HTML5의 SVG와 CSS3 기술로 프레임 애니메이션을 구현할 수 있음
    - SVG : Scalable Vector Graphic. 진작부터 존재했던 플래시의 대안 기술. HTML5의 일부로 포함됨.
    - HTML + CSS3 : CSS3에 frame 단위 애니메이션 효과에 대한 정의가 포함됨.
* Sencha Animator라는 CSS3 기반 공개 컨텐츠 저작툴이 존재함
* Adobe에서 Edge라는 CSS3 기반 상용 컨텐츠 저작툴을 발표함 (현재 preview 상태. '12년 정식 버전 출시 예정)
* 프레임 애니메이션을 구현할 수 있는 요소 기술은 존재하나, 본격적인 컨텐츠를 저작할 수 있는 상용 저작툴이 미흡한 상황임
* SVG와 CSS3 Animation 기능에 대한 브라우저의 지원이 미흡함 (특히 안드로이드 모바일 브라우저) 
(출처:  http://caniuse.com )


Reference
* [HTML5 강좌] 19. SVG
    - SVG로 프레임 애니메이션 저작이 가능하다
* Sencha Animator - HTML5, CSS3 애니메이션 저작 도구
    - CSS3로 프레임 애니메이션 저작이 가능하다
* Adobe, HTML5 저작 도구 Edge 공개 (2011-08)
    - Adobe Edge가 HTML/CSS 기반 애니메이션 저작 기능을 제공한다
* Why has Edge gone with div-based animation over canvas SVG? (2011-08)
    - Edge 개발시 Canvas와 SVG 사용을 고려했으나 성능상의 문제로 채택하지 않았다
    - iOS4에서 Canvas와 SVG 성능이 미흡했다 (약간 자의적 판단...)
    - Edge는 현재 preview 버전이다. 정식 버전 출시시 달라질 수 있다
* [RIA] 스마트한 RIA 구현을 위한 몇 가지 팁 (2011-11)
    - Adobe Edge는 내년('12) 정식 버전 출시 예정이다

(이상) 
 
저작자표시 비영리 변경금지
Posted by ingeeC
,

Javascript 스터디 노트 1 (함수에 대하여...)

Dev 2011. 12. 1. 09:53
자바스크립트를 공부하기 시작했다. 재미 있다. 재미를 나누고 싶어 내용을 요약한다.
자바스크립트는 모든 브라우저에서 실행되는 현실적인 '대세'다. 강한 놈이 살아남는게 아니라 살아남는 놈이 강한거다 (어랏? 어디서 많이...). 자바스크립트는 웹OS, 크롬OS 같은 놈들이 확산되면 더욱 강한 놈이 될거다. 분명하다.


자바스크립트(이하 JS)의 특징
* JS 자체를 몰라도 프로그래밍을 시작할 수 있는 언어 : c, c++, java와 닮았다. 장점이자 단점이다.
* object 기반 객체지향 언어 : class 기반 객체지향 언어와 다르다.
* functional programming language : JS는 function을 특별하게 다룬다.


JS 특징들에 대한 부연설명
조금 더 설명을 덧붙이면 다음과 같다.

*  JS 자체를 몰라도 프로그래밍을 시작할 수 있는 언어 
JS는 c, c++, java로부터 많은 키워드를 차용했기 때문에 c, c++, java를 알고 있는 개발자는 별 부담 없이 JS를 이용해서 프로그래밍을 시작할 수 있다. 장점이다.
하지만 곧 언급하겠지만 JS는 c, c++, java 등과는 본질적으로 다른 특징을 갖고 있다. 기존 언어와 닮았다는 점 때문에 JS 랭귀지를 제대로 이해하고 작성한 코드가 드물다. 이건 단점이다.

* object 기반 객체지향 언어 : class 기반 객체지향 언어와 다른 언어
JS는 c, c++, java 같은 class 기반 객체지향 언어가 아니다.
JS는 객체의 족보(hierarchy)를 (class에 기반한 type이 아니라) real object 사이의 prototype-chain으로 구현한다.

* functional programming language의 특징을 갖고 있는 언어
functional programming language는,
- c, c++, java 같은 imperative programming language와 다른 개념이다.
- 가장 대중적인 최초의 functional  programming language는 LISP이다.
- state와 mutable data를 회피한다.
- 어떤 function의 결과값은 인자에 의해서만 결정된다. 따라서 같은 인자로 같은 함수를 호출하면 언제나 같은 결과를 얻는다.
- multi-CPU, multi-process, multi-thread 환경이 부각되면서 중요도가 커지고 있다.

반면 imperative programming language는,
- fortran, cobol, basic, c, c++, java 등이 있다 (OO Language를 포함)
- 명령에 의해 시스템의 state를 변화시키는 방식으로 동작한다. state 변화를 중시한다.
- 같은 인자로 같은 함수를 호출하더라도 호출하는 시점의 state에 따라 다른 결과를 얻는다 ("referential transparency가 부족하다"고 표현한다).

functional programming language 세계의 주요 개념은 다음과 같다.
- higher order function: 다른 함수를 인자로 받거나 리턴할 수 있다.
- 1st class function: 함수를 다른 intrinsic type (number, string, ...)과 동일하게 취급한다.


JS function의 특징들

함수 정의 방식
아래 두 함수 정의 방식은 완전히 동일하다.
아래 두 함수 정의 방식은 (동작 방식은 다르지만) 동작 결과는 완전히 동일하다 (댓글 주신 @지돌스타님 감사합니다).

1. 변수에 익명함수(anonymous function)를 assign
var myFunc = function(a, b, c) {
    return a+ b+ c;
}

2. Named function을 정의
function myFunc(a, b, c) {
    return a+ b+ c;
}

자바스크립트는 변수의 타입을 느슨하게 규정한다. 따라서,
- 함수 인자를 정의할 때 타입을 지정할 필요가 없다.
- 함수의 리턴 타입을 지정할 필요가 없다.

함수 취급 방식 (1st class function)
함수 및 함수 코드 블럭을 객체처럼 (객체와 동일하게) 취급한다. 즉, 함수를 인자나 리턴으로 사용할 수 있다
/* 함수를 배열 item 데이터로 사용 */
var operators = {
    add:    function(x, y) { return x+ y; },
    sub:    function(x, y) { return x- y; }
};
alert( operators['add'](1, 3) ); //'4' 팝업
alert( operators['sub'](3, 1) ); //'2' 팝업

/* 함수를 다른 함수의 인자로 사용 */
var add;
function setAdd(code) {
    add = code;
}
setAdd(function(x, y) { return x+ y; }); //함수 코드 블럭을 다른 함수의 인자로 전달
alert( add(1, 2) ); //'3' 팝업

/* 함수를 리턴 값으로 사용 */ 
function getAddFunc() {
    return function(x, y) { return x+ y; }
}
var add = getAddFunc();
alert( add(1, 2) ); //'3' 팝업

/* 함수를 선언과 함께 호출 */
alert ( (function(x, y) { return x+ y; })(1, 2) ); //'3'을 팝업

변수 Scope
변수의 참조 Scope는 블럭 ({...}) 단위가 아니라 함수 단위로 결정된다.

function outerFunc() {
    var a = 'hello';
    function innerFunc() {
        alert(a); //innerFunc()이 호출되면 outerFunc()의 a 변수를 참조하여 'hello' 팝업
    }
    innerFunc();
}
outerFunc();

(이상)
PS. 글을 긁어갈 때는 출처를 밝혀 주면 좋겠다. 인터넷 검색중에 출처에 대한 언급 없이 내 글이 걸려 있는 것을 보면 기분이 안좋다. 출처를 명시하고, 원본을 수정하지 않고, 상업적 용도로 사용하지 않는 이상, 본 블로그의 글은 자유롭게 사용할 수 있다.


저작자표시 비영리 변경금지
Posted by ingeeC
,

티스토리툴바