없으면 없는대로

Firefox 빌드하기 2

윈도7에서 빌드환경 갖추기

개발PC 1호기에서 멋지게 한방 빌드를 끝낸 다음, 개발PC 2호기에서 다시 한번 파이어폭스 빌드를 시도했다. 보기 좋게 실패했다. 실패 증상은 다음과 같았다.

- DirectX SDK가 설치되지 않았다. 빌드 과정에서 DirectX가 설치 되지 않아 빌드 못해먹겠다는 에러가 발생했다.

- 우여곡절 끝에 DirectX SDK를 설치하고 빌드했더니 LNK1123 링크 에러가 발생했다.

 2:48.22 Executing: link -NOLOGO -OUT:crashinject.exe -PDB:crashinject.pdb -LARGEADDRESSAWARE -NXCOMPAT -RELEASE -DYNAMICBASE -SAFESEH -DEBUG -DEBUGTYPE:CV -DEBUG -OPT:REF @d:\mozilla-central\obj-i686-pc-mingw32\build\win32\tmp3vs529.list module.res kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib secur32.lib netapi32.lib kernel32.lib user32.lib gdi32.lib winmm.lib wsock32.lib advapi32.lib secur32.lib netapi32.lib
 2:48.22 d:\mozilla-central\obj-i686-pc-mingw32\build\win32\tmp3vs529.list:
 2:48.22     crashinject.obj
 2:48.22
 2:48.22 LINK : fatal error LNK1123: failure during conversion to COFF: file invalid or corrupt
 2:48.22

TIP1,

2호기는 Windows7 머신이었다. 여기에 VS2012를 설치했던게 문제의 원인이었다. Windows7에는 VS2010을 권한다.

TIP2,

DirectX SDK 2010년 June 버전과 MS의 최신 SDK들이 잘 맞지 않는다 (설치시 충돌이 일어난다). DirectX SDK를 설치할 때는 VS2012 관련 SW들을 모두 제거하고 설치해야 한다. 그리고, tool 설치 순서가 중요한데, DirectX SDK --> Windows7 SDK --> VS2010 Express 순서로 설치할 것을 권한다.

TIP3,

VS2010 계열 빌드 도구(리소스컴파일러)와 VS2012 계열 빌드 도구 사이에 충돌이 있다 (실행시 LINK 에러가 난다). 순간의 욕심으로 VS2012를 설치했다가 파이어폭스 빌드 실패를 맛보고 있는 상태라면, VS2012 관련 SW 전부, .Net SDK 관련 SW 전부, Windows SDK 전부를 제거한 다음, 필요한 빌드 도구들을 위의 순서대로( DirectX SDK --> Windows7 SDK --> VS2010 Express ) 다시 설치하고 시도해 볼 것을 권한다.

(이상)

Firefox 빌드하기

https://developer.mozilla.org/en-US/docs/Simple_Firefox_build

준비물 갖추기 (for Windows)
    - VC++ 2010 (official) or 2012; Express(free) 버전도 무방
    - VC++ 2010을 쓸 경우 Windows 7 SDK도 추가 설치
    - June 2010 DirectX SDK 설치
    - MozillaBuild 패키지 설치
        - 설치후 c:\mozilla-build 디렉토리의 start-msvc10.bat (VS 2010) 실행, 콘솔이 정상적으로 실행되는지 확인
소스 가져오기
    - hg clone https://hg.mozilla.org/mozilla-central 실행, mozilla-central 디렉토리와 소스가 생성됨
빌드하기
    - mozilla-central 디렉토리에서 ./mach build 실행
실행하기
    - Windows: obj-.../dist/bin/firefox.exe 실행
소스 업데이트하기
    - mozilla-central 디렉토리에서 hg pull -u 실행

정말... 아무런 힘 안들이고 한방에 빌드가 끝났다. 모질라 만세~!

WebRTC 현황 요약 (2013.6.21. 기준)

- WebRTC는 브라우저 간의 실시간 통신 서비스(음성통신, 화상회의)를 위한 표준기술

- 안드로이드 단말에서의 WebRTC 지원 현황

- 2013-04-16, WebRTC가 안드로이드 파이어폭스에 구현됨

- 디폴트 설정은 off

- ICS 이전 버전에서는 사용에 문제 있을 수 있음

- 이유는 제조사에 따라 일부 하드웨어의 경우 성능이 부족함

- 그리고 일부 제조사 단말에는 WebRTC를 위해 필요한 안드로이드 API가 부재함

- 그러나, 갤탭 10.1 안드로이드 3.2의 경우 비디오 콜이 정상 수행됨

- 2013-06-03, 크롬 안드로이드 베타 최신 버전에서 WebRTC 지원 시작함

- 2013년 6월 현재, 안드로이드 내장 브라우저는 WebRTC를 지원하지 않음

Reference

WebRTC support on Android

http://www.morbo.org/2013/04/webrtc-support-on-android.html

2013-04-17

You Can Try WebRTC on Chrome for Android Beta Now

http://www.chromestory.com/2013/03/you-can-try-webrtc-on-chrome-for-android-beta-now/

2013-06-03

[인터넷] 웹 브라우저에서의 실시간 통신기술

http://weekly.tta.or.kr/weekly/files/20124031104031_admin.pdf

2012-06-04

(이상)

asm.js에 대하여

배경

- 파이어폭스 팀에서 개발

- 파이어폭스 차기버전 JavaScript 엔진(OdinMonkey)이 asm.js 지원 예정

- 모질라에서 asm.js를 이용하여 Epic의 언리얼 엔진3(heavy한 게임엔진)를 시연함

개요

- JavaScript의 subset

- 새로운 언어가 아님

- 기존 모든 브라우저에서 실행 가능함

- asm.js를 지원하지 않는 JavaScript 엔진도 asm.js 코드를 실행시킬 수 있음

- 변수 타입을 엄격하게 체크하는 문법을 정의(기존 JavaScript는 변수 선언시 타입을 지정하지 않음)

- 변수 타입을 엄격하게 정의하면 JIT(실행시간 컴파일) 뿐 아니라 AOT(Ahead Of Time: 실행전 컴파일)이 가능해짐

- 파이어폭스는 조만간 asm.js에 최적화된 컴파일러를 제공할 예정이며 벤치마크 결과는 "경이적"

전망

- 모질라는 기존 언어로 개발된 코드를 asm.js 코드로 변환해주는 도구 제공을 약속

- 특히 엄격한 타입 체킹 언어인 C/C++은 asm.js 코드로 변환하기에 최적인 언어

Reference

- Big Web App? Compile It! 

   http://kripken.github.io/mloc_emscripten_talk/#/

- [번역] asm.js : 컴파일러를 위한 low level, 고도로 최적화 가능한 JavaScript의 서브셋

   http://atconsole.com/2013/04/04/%EB%B2%88%EC%97%AD-asm-js-%EC%BB%B4%ED%8C%8C%EC%9D%BC%EB%9F%AC%EB%A5%BC-%EC%9C%84%ED%95%9C-low-level-%EA%B3%A0%EB%8F%84%EB%A1%9C-%EC%B5%9C%EC%A0%81%ED%99%94-%EA%B0%80%EB%8A%A5%ED%95%9C-javascript/

- asm.js에 대해서

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

(끝)

JavaScript 빌드 도구(build tool) 동향 요약

스캐폴딩(scaffolding) 기능을 중심으로...

보일러플레이트(boilerplate) 도구

- 보일러플레이트는 코드 재사용을 위해 코드 골격을 미리 구성해 놓은 것

백본 보일러플레이트(backbone boilerplate)

- Backbone.js 프레임워크를 이용하는 프로젝트를 위한 보일러플레이트

- 소스 위치: https://github.com/tbranyen/backbone-boilerplate

- 다른 백본 보일러플레이트도 있지만 이 프로젝트가 제일 좋음 (스스로 좋다고 주장함)

    - requireJS를 잘 지원

    - 라이브러리 소스를 있는 그대로 (변형하지 않고) 사용

    - 빌드 시스템을 구비

    - 샘플 앱을 지원

    - 필요한 골격만 지원

스캐폴딩

- 스캐폴딩은 MVC f/w 특히 RoR(루비 온 레일즈)에서 널리 사용되기 시작함

- 어플리케이션 구축에 필요한 뼈대를 자동 생성해주는 기능

- 기본 파일과 디렉토리 구조를 매번 새로 만들어야 하는 번거로움을 제거

grunt

    - grunt는 node.js 기반의 JavaScript 빌드 도구

    - 설치방법: node.js가 설치된 상태에서 npm install 명령을 이용 설치

        - node.js는 이제 JavaScript 실행환경일 뿐 아니라 훌륭한 개발환경

    - package.json 파일에 grunt 실행에 필요한 모듈 서술

        - 프로젝트 root에 두며 소스 버전 관리 대상

        - npm install 명령을 실행하면 필요한 모듈이 자동 설치됨 ( 다시 말하지만, node.js는 이제 훌륭한 개발환경! )

        - npm init 명령으로 기본적인 package.json 파일을 생성함

    - gruntfile.js 파일에 일괄 처리할 작업을 정의

        - make 시스템의 makefile에 해당

        - grunt 0.3.x 버전에서는 gurnt.js로 통용됨 

        - grunt 0.4.x 버전에서 gruntfile.js로 이름 변경됨

        - 프로젝트 root에 두며 소스 버전 관리 대상

        - grunt plugin이 package.json에 들어 있고, 

            npm install 명령으로 설치됐다면, 

            gruntfile로 쉽게 실행시킬 수 있음

        - pkg 섹션

            - pakcage.json을 가리키는 역할

            - package.json에는 프로젝트 관련 메타데이터가 정의됨

            - pkg.name 같은 형태로 메타데이터 참조가 가능

        - meta 섹션

            - 내부 속성으로 banner만 있음

            - 합치거나 축약할 때, js 파일 상단에 자동으로 넣는 주석 지정

        - lint 섹션

            - JSHint를 이용 JavaScript 파일 테스트

            - 테스트할 파일 목록을 자유롭게 grouping하여 지정 가능

        - qunit 섹션

            - jQuery의 테스트 프레임워크인 QUnit을 이용 테스트 수행할 대상 파일을 지정

            - PhantomJS가 설치되어 있어야 함

            - lint 섹션처럼 테스트할 파일 목록을 자유롭게 지정 가능

        - concat/ min 섹션

            - 파일을 합치거나(concat), 공백을 제거해서 축약(min)시키는 작업을 실행

        - watch 섹션

            - 지정된 파일이 변경될 경우, 지정된 작업을 수행

        - jshint 섹션

            - lint 섹션을 실행할 때, JSHint 툴에 전달할 옵션 정의

            - 실행 섹션이 아님

        - uglify

            - min 섹션을 실행할 때, UglifyJS 툴에 전달할 옵션 정의

            - 실행 섹션이 아님

grunt-bbb

    - grunt-bbb는 grunt의 플러그인

    - bbb는 Backbone Boilerplate Build를 뜻함

    - npm install -g bbb 명령으로 설치 ( 다시 말해 node.js는 이제 정말 훌륭한 개발환경! )

    - 사용 명령어

        - init (bbb)

            - bare boilerplate 프로젝트 생성

        - init:module (bbb)

            - 새로운 모듈 생성

            - model, collection, view를 통합하는 module 생성

            - js, css, html 생성

        - server (bbb)

            - 웹서버를 띄워 프로젝트를 실행

Reference

- http://blog.outsider.ne.kr/892

- https://github.com/tbranyen/backbone-boilerplate/wiki/Getting-started-overview

- https://github.com/tbranyen/backbone-boilerplate/wiki/Installation

- http://gruntjs.com/

- https://github.com/backbone-boilerplate/grunt-bbb

http://www.w3.org/Mobile/mobile-web-app-state/

2013년 2월

0. 개요

- 현재 웹기술이 full-featured 모바일 앱을 만들만큼 충분히 무르익음

- W3C는 웹앱 개발 기술을 확장하기 위해 노력하고 있으며 관련 교육 링크도 운영하고 있음 (http://www.w3devcampus.com/writing-great-web-applications-for-mobile/)

1. Graphics

- SVG : Scalable 벡터 그래픽 표준

- Canvas : 2D programmatic API 표준

- 폰트 : WOFF(Web Open Font Format) 표준

- Fullscreen API, Screen Orientation API 표준

* WebGL(3D graphic API)은 W3C 밖에서 표준화 작업 진행 중(Khronos Group)

* 표준화 안정 단계, 표준 적용 활성화 단계

2. Multimedia

- <video>, <audio> 태그 : 과거 image처럼 멀티미디어 요소를 Web의 1st class citizen으로 취급

- Encrypted Media Extensions : DRM 컨텐츠 재생에 관한 표준

- Pick Media Intent, Networked Service Discovery API : DLNA 컨텐트에 대한 접근 표준

- HTML Media Capture : 카메라, 마이크(녹음) 등에 의한 captured 컨텐트에 대한 접근 표준

- Web Real-Time Communication WG 활동 중

- Web Audio API : 오디오 컨텐트에 대한 분석, 수정, 합성을 위한 API 표준

- W3C Web and TV Interest Group : 모바일 Web을 통해 TV 시청 경험을 풍요롭게 하는 연구 진행 중

* 표준화 초기 단계, 표준 적용 초기 단계(모바일에서 활용 제한적)

3. Device Adaptation

- Device Description Repository API : 다양한 장치 특성(스크린 크기, 입력 장치 특성, 미디어 기록/재생 특성 등)을 조회할 수 있는 server-side API 표준

- Media Capture Streams API : 카메라, 마이크 등의 media capture 장치 제어 표준

- CSS Media Query : 반응형 layout 지원 표준

- Adaptive images(picture 태그, srcset 속성) : 화면 크기에 최적인 이미지를 다운로드 하도록 지원

* 표준화 초기 단계, 표준 적용 초기 단계

4. Forms

* W3C는 모바일 기기의 제한된 입력 기능을 보완하기 위한 form 구성 요소를 지원하기 위해 노력 중

- date and time <input type="date">: OS가 제공하는 native calendar 컨트롤 사용 지원

- <input type="email">, <input type="tel">, <input type="url"> : 데이터 형태에 따른 키보드 지원

* 표준화 안정 단계, 표준 적용 초기 단계

5. User interactions

- Pointer Events : 터치 기기 및 마우스 등의 전통적 포인터 기기의 이벤트 관련 표준

- vibration API : 햅틱 피드백(진동) 관련 표준

- IndieUI Events : 기기별 specific 이벤트를 한 레벨 추상화한 이벤트 표준("click", "key press", "touch" 이벤트를 대신하는 "undo", "next page" 이벤트)

- Web Notifications : 웹을 통한 사용자 notification 표준

- Speech API Community Group : 음성인식 기반 사용자 인터랙션 표준 논의 중

- Mobile Accessibility, WAI-ARIA : 장애인을 위한 웹 접근성 관련 표준 논의 중

* 표준화 초기 단계, 표준 적용 초기 단계

6. Data storage

- Web Storage : 브라우저를 통한 간단한 데이터 저장/관리 API 표준

- File Reader API, File Writer API, FileSystems API : 정교한 파일 관리 API 표준

- Indexed Database API : 로컬 DB 관리 API 표준

- Quota Management API : 웹앱을 위한 로컬 저장공간 확보 관련 API 표준

- Web Cryptography API : 데이터 암호화 관련 API 표준

* 표준화 초기 단계, 표준 적용 초기 단계

7. Personal Information Management

- Contacts API, Calendar API : 주소록, 일정 정보 관리 API 표준

* 관련 API 표준이 Web Intents 기반 API 형태로 대치되고 있는 중

* 표준화 아주 초기 단계, 표준 적용 전무

8. Sensors and hardware integration

- Geolocation API : 센서를 통해 기기의 현재 위치를 알아내는 API 표준(GPS, WiFi 네트웍, Cell 네트웍 등의 방법 등 중 가능한 방법을 이용)

- DeviceOrientation Event Specification : 센서를 통해 기기의 가로/세로 상태를 알아내는 API 표준

- Battery Status, Proximity sensors, Ambient Light Events 등 표준 stable 단계

- NFC WG : NFC 관련 표준 논의 중

* 표준화 안정 단계, 표준 적용 초기 단계

9. Network

- XMLHttpRequest : AJAX API 표준

- Cross-Origin Resource Sharing : 현재 웹 페이지와 다른 도메인의 자원을 공유하기 위한 표준

- Push API : 웹앱이 (브라우저에 활성화되지 않은 상태에서도) 서버로부터 전달되는 메시지를 수신하기 위한 표준

- WebSocket API : 저비용 양방향 통신 지원 표준

- Web Real-Time Communications : P2P 데이터 통신 지원 표준

- network-information API : 현재 이용하고 있는 통신망의 bandwidth 등의 정보를 파악하기 위한 표준

* 표준화 안정 단계, 일부 표준 적용 단계

10. Communication and Discovery

- Messaging API : sms://, mms://, mailto:// 등 URI 스킴 기반 메시지 전달 표준, Web Intents 방식으로 재정의될 예정

- Networked Service Discovery API : DLNA등 로컬 네트웍 서비스와 웹앱 사이의 seamless 협업을 위한 표준

- Web Real-Time Communications WG : 커뮤니케이션 관련 표준을 주도적으로 논의 중

* 표준화 초기 단계, 표준 적용 초기 단계

11. Packaging

* 웹앱을 오프라인 상태에서 이용하기 위한 표준과 웹앱을 app store를 통해 유통할 수 있는 포맷으로 만들기 위한 표준

- ApplicationCache : 웹앱을 오프라인 상태에서도 이용하기 위한 표준

- W3C Widgets : 웹앱을 ZIP 형태로 패키징하기 위한 표준

* 표준화 안정 단계, 일부 표준 적용 단계

12. Performance & Optimization

- Web Performance WG : Navigation Timing, Resource Timing, Performance Timeline, User Timing 등 웹앱 성능 최적화 도구 개발 중

- Page Visibility API : 페이지가 보이지 않는 시점에서 네트웍 자원 사용을 억제하기 위한 표준

- battery API : 배터리 잔량에 따라 자원 활용을 억제하기 위한 표준

- Web Workers : 리소스를 많이 소비하는 작업을 백그라운드 스레드로 처리하기 위한 표준

* 표준화 안정 단계, 표준 적용 초기 단계

코너스톤 WDK (Cornerstone WDK)

SKT가 만든 코너스톤 WDK (Web Dev. Kit)를 소개합니다.

코너스톤 WDK의 핵심은 코너스톤 프레임웍 (이후 f/w)입니다. 코너스톤 f/w을 만들면서 염두에 두었던 생각들을 요약합니다. 상세한 내용은 http://cornerstone.sktelecom.com 에서 확인할 수 있습니다.

1. 힘 빼고 만들었습니다.

SKT가 처음부터 끝까지 세상을 새로 만들겠다는 못된(?) 욕심을 버리고 접근했습니다. 거인들의 업적을 존중하면서 그 어깨 위에 작은 노력을 더해 세상에 기여하겠다는 철학으로 접근했습니다. 개발자들에게 인기 높은 검증된 오픈소스 f/w들을 기반으로 코너스톤 f/w을 개발했습니다. 이미 익숙한 f/w들을 근간으로 하고 있기 때문에 개발자 입장에서는 학습 비용이 적을 뿐 아니라, 코너스톤 f/w을 쓰기 위해 학습한 내용을 다른 f/w들을 개별적으로 쓸 때도 활용할 수 있을 것입니다.

2. Modern Web App 개발의 최신 동향을 담았습니다.

Modern Web App 개발의 최신 기술들을 지원합니다. 코너스톤 f/w은 UI f/w 뿐만 아니라 모듈화, MVC (Model-View-Control 패턴), RWD (Responsive Web Design) 등 Javascript 프로그래밍의 핵심 동향을 모두 포함하고 있는 full featured Javascript f/w 입니다. 그리고 코너스톤 f/w은 UI f/w과 MVC f/w 사이의 정합성을 맞추는데 상당한 노력을 기울였습니다. 코너스톤 f/w을 이용하면 개별 f/w들을 따로 선택하고 이들 사이에 정합성을 맞추는데 소요되는 비용을 줄일 수 있습니다.

3. 모바일에서의 성능 보장을 위해 노력했습니다.

코너스톤 개발을 시작할 당시, 세상에 공개된 거의 모든 모바일 UI f/w들을 검토하고 성능을 비교했습니다. 코너스톤 f/w은 트위터 Bootstrap을 UI f/w의 근간으로 선택했습니다. Bootstrap의 간결함을 유지하면서 Bootstrap에 모자란 모바일 Widget과 기능을 추가했습니다. 조심스럽지만, 현재 시점에서 가장 빠르고 안정적인 모바일 UI f/w이라고 자신합니다.

4. 한글 문서를 제공합니다.

정말 공들여 만든 한글 문서를 제공합니다. f/w을 만들면서 배우고 느낀 내용을 모두 담으려고 노력했습니다. 한국의 SW 분야가 성공하려면 제대로된 한글 개발문서가 축적되고 공유되어야 한다고 생각합니다. 코너스톤 개발문서가 조그만 기여를 할 수 있으면 좋겠습니다. 코너스톤 f/w 개발문서는 정적으로 고정된 문서가 아니라 샘플코드를 작성하고 결과를 확인할 수 있는 살아있는 문서입니다 (http://cornerstone.sktelecom.com/livedoc/).

운 좋게도 훌륭한 개발자 분들을 만나서 신나게 개발할 수 있었습니다. 하지만 아직은 미약한 시작입니다. 개발자 분들의 소중한 의견을 듣고 싶습니다. 코너스톤 블로그에 의견 남겨 주세요.

BaaS 개요 및 현황

+ BaaS란?

    - 모바일 어플리케이션에 특화된 클라우드 서비스

    - 서버사이드 개발 능력 없이도 손쉽게 Backend를 구축

    - 모바일 생태계와 밀접한 관련이 있음

    - '11년 태동된 따끈한 서비스 사업

+ BaaS를 사용하지 않으면(즉, 서버사이드를 직접 개발하면),

    - 서버사이드 SW 개발에 막대한 비용 소요

    - 운영 인프라 확보에 막대한 비용 소요

    - 운영 라이선스 확보에도 막대한(?) 비용 소요

    - Time to Market 보장 못함

+ BaaS 서비스 종류

    - 데이터 저장

    - Push Notification

    - Social 통합

    - 사용자관리/권한제어

    - Rating

    - 인증

    - Location

    - Billing 

    - 사진 저장 및 공유

    - 기타등등...

+ BaaS 사용자들이 선호하는 서비스 순위

    - 1위 Location Service(35%), 2위 Notification(33%), 3위 Rating(11%)

+ BaaS의 목표

    - 서버코드를 작성 않고도 클라이언트가 서버 API를 호출하여 필요한 Backend 서비스를 이용

    - 모바일 어플리케이션의 개발 효율 제고

+ BaaS의 기능이 확장되면서 PaaS와 경계가 모호해지는 경향이 존재함

    - 커스텀 API 생성 지원

    - Java, Ruby, Python, Lua 등을 통한 Biz로직 커스터마이징 지원

+ 관련 업체

    - Appcelerator : Titianium 개발업체, 최근 BaaS 업체인 Cocoafish를 인수함

    - Parse : 공개 베타 종료, 정식 서비스 오픈함

    - 기타 StackMob, Kinvey, Apple iCloud, RhoMobile 등

    - 현재(2012년 04월 기준), BaaS 참여업체는 최소 20개

+ BaaS 제공업자가 고민해야 할 점

    - 클라우드를 통한 확장성(Scaling), 높은 가사용성(Availability)

    - Backend 데이터 보안(Security), 신뢰성(Reliability)

    - 서비스 재사용성(Reusability of Services)

        - 서비스가 특정 App과 tightly coupled되지 않게 주의해야 함

        - 그래야 App 개발 생산성을 보장할 수 있음

+ BaaS 사용자가 고민해야 할 점

    - 벤더 안정성

        - 벤더가 갑자기 가격정책을 변경하면?

        - 벤더가 갑자기 없어지면?

+ BaaS 가격 정책 예시(API 호출 횟수에 따라 과금)

    - free tier: 500,000 calls/month 까지 free

    - paid tier: 500,000 calls/month 이후, 

        - 매 1000 calls 당 $0.2

        - 10 million calls/month 당 $249

        - 매 1000 calls 당 $0.15

    - enterprise tier: 비밀?

Reference

BaaS(Backend as a Service) 에 대하여

http://www.mimul.com/pebble/default/2012/05/05/1336192251452.html

The Rise of Mobile Cloud Services: BaaS Startups Grow Up

http://www.readwriteweb.com/mobile/2012/04/mobile-backend-as-a-service-ec.php

StackMob: The Complete Technology Stack for Mobile Apps

http://www.readwriteweb.com/mobile/2011/01/StackMob-the-complete-technology-stack-for-mobile-apps.php

Open Source Mobile Backend as a Service

http://apievangelist.com/2012/08/28/open-source-mobile-backend-as-a-service/

Mobile Backend as a Service Roundup and the Future of Web APIs

http://developerthinktank.com/roundtable/mobile-backend-as-a-service-roundup-and-the-future-of-web-apis/

Appcelerator, Cocoafish 홈

http://cocoafish.com

Buddy Announces Pricing!

http://us2.campaign-archive2.com/?u=89af861528a693bdec7af3af7&id=5ae7773b1a

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

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

(이상)

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