없으면 없는대로

구글, Nest 개발자 프로그램 오픈

요약
- 구글은 "Nest Learning Thermostat"을 스마트홈 Hub로 발전시킬 전망
+ 향후 실현 가능한 응용 시나리오
    - 구글나우와 연계, Nest 온도조절기에게 "오케이 구글, 온도 좀 낮춰" 라고 말할 수 있게 됨
    - IFTTT와 제휴, 화재 발생시 온도 변화를 감지하여 사용자에게 SMS 전달 가능
    - 벤츠와 제휴, 자동차가 도착 예상 시간을 일러주면 Nest가 미리 집안 온도를 알맞게 조정 가능
+ Nest에 장착된 센서/기능을 다른 기기/서비스들에 개방
    - Motion Detection 센서
    - 온도 센서
    - 화재 연기 및 CO(일산화탄소) 센서
    - Wi-Fi, Zigbee 등 네트워크 기능
+ 다른 기기가 Nest로부터 얻을 수 있는 정보/기능
    - Away 정보: 사용자가 집에 있는지 밖에 있는지에 대한 상태 정보
    - 화재 연기 및 CO(일산화탄소) 경보
    - Rush Hour Rewards 이벤트 정보
    * Rush Hour Rewards : 에너지 소비가 큰 시간에 에너지 사용을 억제할 경우 에너지 회사가 제공하는 보상
+ Nest 연동 기기/서비스 제작시 privacy에 주의해야 함
    - Nest는 사용자의 privacy를 보호하기 위해 최소한의 정보만 공유함
    - 사용자의 이름, 패스워드, 이메일, 주소 정보는 제공하지 않음
    - Nest 연동 기기/서비스를 설치할 때마다 사용자의 <동의>가 있어야 함
    - Nest와 사용자는 언제든지 연동 기기/서비스를 거부할 수 있음
    - Privacy만큼 Security도 중요하기 때문에 모든 통신에 SSL을 적용함

Nest API
+ RESTful API 형태로 <Nest Learning Thermostat>, <Nest Protect Smoke + CO Alarm>, <Home> 객체에 대한 정보 및 기능을 제공함
+ <Nest Learning Thermostat> 객체
    - 현재 온도 조회
    - 타겟 온도 조회 및 설정
    - fan 타이머 설정
    - 온도 모드 조회 및 설정
    - 온라인 상태 및 최근 접속 정보 조회
+ <Nest Protect Smoke + CO Alarm> 객체
    - CO 또는 Smoke 상태 조회
    - 배터리 상태 조회
    - 온라인 상태 및 최근 접속 정보 조회
+ <Home> 객체
    - home에 연결된 기기 목록 조회
    - energy event 상태 조회
    - ETA(사용자의 도착 예상 시간) 설정
    - Away 상태 조회 및 설정
+ RESTful API 호출을 도와주는 client lib 제공
  - 지원 플랫폼: iOS, Android, Web
- API 문서, 샘플 코드, 테스트 도구 제공
- Stack Overflow 사이트 내에 Nest 개발자 커뮤니티 운영

Ref.
- Google Makes Its Nest At The Center Of The Smart Home (2014-06-23)
- Nest Developer Program

(이상)

HTML5 Device API 지원 현황 (2014년 4월 기준)

• W3C를 비롯 웹 진영은 HTML5를 본격적인 OS수준의 App 실행 플랫폼으로 자리매김하려 하지만, 모질라를 제외한 브라우저 벤더(애플, 구글)의 지원이 미미한 상황
  
• 애플과 구글은 앱스토어와 구글 플레이 스토어를 중심으로 하는 네이티브 앱 생태계를 지키기 위해 웹 생태계 활성화에 적극적이지 않음
  
• Device API를 비롯 HTML5 웹앱 생태계가 활성화되기 위해서는 시간이 필요할 전망
  

Device API          표준화 단계      모바일 브라우저 지원현황
--------------------------------------------------------------------------
File API                 WD        FF 27+, iOS 6+,   Android 4.4+
File Reader API          WD        FF 27+, iOS 6+,   Android 3.0+
Filesystem & Writer API  WD        FF x,   iOS x,    Android x
Geolocation API          CR        FF 27+, iOS 3.2+, Android 2.1+
getUserMedia API         WD        FF 27+, iOS x,    Android x
WebRTC API               WD        FF 27+, iOS x,    Android x (Chrome 29+)
Full Screen API          WD        FF x,   iOS x,    Android x
Web Audio API            WD        FF 27+, iOS 6+,   Android x
Vibration API            WD        FF 27+, iOS x,    Android 4.4+
Battery Status API       CR        FF 27+, iOS x,    Android x

좋은 개발 문서를 만났다. Web 개발 Best Practice를 설명하는 문서인데, 개발 프로세스에 대한 설명( Agile Scrum )과 웹 성능 테스트( Performance )에 대한 설명이 좋았다. 그중 개발 프로세스에 대한 내용을 요약한다.

출처: https://github.com/Snugug/north/blob/master/README.md

Agile Process (Scrum)

프로세스 참여자의 역할과 책임 (Roles and Responsibilities)
+ 프로젝트에 너무 많은 인원이 참여하지 않도록 한다
+ Project Owner
   - 프로젝트 하나에 한명의 Project Owner가 바람직
   - 프로젝트 수행 결과물의 Owner
   - 작업 우선순위 결정, 요구사항 결정, User Story 작성 보조
+ Project Manager
   - 프로젝트 하나에 한명의 Project Manager가 바람직
+ Designer
   - User Interface 디자인과 User Experience 디자인 업무 구분 필요
+ Developer
   - Front End 개발자와 Back End 개발자 업무 구분 필요
+ Quality Assuarance
   - QA가 OK하기 전에는 릴리즈 불가

Agile Scrum
+ User Stories

   - 구현해야 할 단위 기능/작업
   - Benefit Statement, Requirements, Size, Value로 구성
   - Benefit Statement
      . 이 기능을 왜 개발해야 하는가? (사용자 관점에서/ 비즈니스 관점에서)
      . [persona], I want [desire] so that [rationale] 형태로 서술
   - Requirements
      . 기능 명세, 가능한 추가 질문 없이 이해할 수 있도록 분명하게 작성
   - Size and Value
      . Size : 작업 규모, 이 기능을 개발하려면 얼마나 많은 노력이 소요되는가?
      . Value : 사업적 가치, 이 기능이 사업적 목적에 얼마나 부합하는가?
      . Size의 적절성에 대한 개발팀의 합의 필요
+ Backlog
   - User Story를 우선순위에 따라 나열한 리스트
   - 백로그에 존재하는 스토리의 우선순위는 Project Owner가 결정
+ Iteration
   - 개발을 수행하는 짧은 주기 (최대 2주 이내)
   - 각 iteration을 sprint라고 부름
   - 매 iteration마다 백로그에서 개발할 스토리를 선택
   - 개발팀은 매일 15분 이내의 scrum meeting을 가질 것을 권장
      . 개발 현황, 개발 결과, 개발 장애물 공유
      . scrum meeting은 가능한 짧게 하고 이후 후속 미팅을 통해 문제 해결 권장
   - 매 iteration을 마무리할 때마다 선택한 스토리가 제대로 구현되었는지 점검
      . 선택한 스토리를 제대로 구현하지 못했을 경우 iteration fail 판정
      . iteration fail은 큰 문제가 아님, 일정을 다시 조정하면 됨

(이상)

벌써 한참된, W3C TPAC 2013 메모

게으름이 깊어졌다. 더이상 기억이 유실되기 전에 2013년 중국 심천에서 열렸던 W3C TPAC에 대한 메모를 남긴다.

11.11.월
# System Application WG
: OS와 긴밀히 통합된 Web App을 개발하기 위한 런타임과 API 도출을 목표로 하는 WG
: Native App과 대등한 Web App의 가능성을 논의
: WebOS 에서 전화 calling에 반응하는 app 등 제작 가능
- Service Worker에 대한 논의
  - Page에 종속되지 않은 WebApp
  - 독자적인 life-cycle에 의해 실행
  - system event 처리
  - scheduled wakeup
- Web Manifest에 대한 논의
  - packaged Web App의 메타 정보 서술 방식
  - 크롬, 파이어폭스 등 브라우저 별 독자 구현 방식의 표준화 논의

# 국내 20여명 참여
  ETRI , 달리웍스(주), SKT, 삼성전자 등

11.13.수
# 총회
: 대강당에 모여 W3C의 현안을 공유
- W3C 표준 제정 프로세스를 기존 waterfall 방식에서 agile 방식으로 변환
- Last Call 단계를 폐지 CR 단계에 흡수
- Recomendation 대신 Standard 사용(용어)

# Telco (Web and Mobile WG)
- 차이나모바일, KDDI, 텔레포니카, 하웨이(다수) 참석
- 텔코는 근원적으로 Openness를 필요로 하며 W3C 등 표준화 기구와 협조해야 함

# Web Redesign
- W3C 웹사이트 개편 방안 논의

11.14.목
# Web Crypto
: 표준화가 상당히 진행된 마무리 단계 (LC)

# Web & Mobile
: 모바일 웹앱 관련 표준화 현황과 향후 이슈 논의

# Web Performance Mini WS
: W3C가 현재 집중하고 있는 분야라고 함
: 인텔(중국), NTT(일본), ??(일본) 3개 회사에서 웹 기술 현황 미니 세미나 개최

이전다음

012

(이상)

장대한 세월 굴러먹은 운영되어온 모질라 프로젝트 답게 문서들이 잘 정리되어 있다. 그들의 오랜 숙적이었던 MS의 MSDN( MS 개발자 네트웍 )을 연상시키는 모질라의 MDN( 모질라 개발자 네트웍 )에서 문서 2개를 골라 요약한다. 한국 모질라 개발팀에서 모질라의 최신 블로그 기사 및 개발 문서들을 잘 번역해서 소개하고 있는 것 같다. 장한 사람들이다. 모질라 프로젝트에 참여하면 세상에 의미 있는 기여를 할 수 있을 것 같은 막연한 설레임이 든다.

모질라 코드에 기여하기
https://developer.mozilla.org/en-US/docs/Introduction
- step 1 : Firefox 등 빌드하기
- step 2 : 모질라에 기여하는 절차 이해하기
- step 3 : 할 일 찾기
    - 평소 불만이었던 문제 해결하기
    - 초보자를 위해 찾아놓은 버그 보기
- step 4 : 버그 해결하기
- step 5 : 코드 리뷰 신청하기
- step 6 : 리뷰 대응하기
- step 7 : 코드를 트리에 넣기
- setp 8 : 반복하기

모질라 코드에 기여하는 요령
https://developer.mozilla.org/en-US/docs/Mozilla_Development_Strategies
- 모질라의 문서는 wiki 기반이다. 직접 수정하라.
- 문서화 스킬이 부족해도 안심하라 문서팀이 도울 것이다.
- QA팀의 역할은 품질을 확인하는 것이지 없던 품질을 추가하는 것이 아니다. 자신의 코드는 자신이 책임져라.
- 일을 시작하기 전에 모듈 리더와 소통하라.
    - 아이디어 단계에서 거절당하는 편이 패치코드를 거절당하는 것보다 덜 아플 것이다.
    - 다음에 할 일을 일러줄 것이다.
    - 막혀있는 문제를 풀어줄 것이다.
- 리뷰를 요청하기 전에 스스로 리뷰하라. 당신의 리뷰 스킬을 높일 필요가 있다.

(이상)