Karma 개발자가 직접 쓴 Karama 에 대한 소개 <논문>

을 요약한다. TDD(Test Driven Development)에 대한 저자의 확고한 신념을 느낄 수 있었다.

TDD

• TDD는 고품질의 SW를 개발할 수 있는 효과적인 방법
• TDD는 문서화 측면에서도 이득, 테스트 코드는 항상 up-to-date한 (개발) 코드의 사용법을 알려준다(알려줄 수밖에 없다)
• 테스트 가능한 코드(testable code)는 재사용성(reusable)이 더 높다

TDD를 위해서는 두가지 전제 조건이 필요

• Testable Code: 느슨하게 결합된 모듈 구조로 코드를 개발, AngularJS 같은 프레임워크가 해결
• Testing Environment: Karma 같은 테스트 자동화 도구가 해결

Karma는

• JavaScript를 위한 Test Runner
• Jasmine 같은 Test Framework 이 아님. 어떤 Test Framework도 사용 가능(Karma의 장점)
• 웹앱 테스트의 가장 어려운 점은 코드를 테스트하기 위해 에디터를 떠나 브라우저를 실행시켜 결과를 확인해야 하는 워크플로우의 단절 (context switching), Karma는 이를 해결하기 위한 도구

Karma 모듈 구성도 (Figure 4.1: The high level architecture)

왜 클라이언트-서버 구조를 선택했나?
웹앱은 다양한 기기와 다양한 브라우저에서 실행, 디바이스와 브라우저의 편차를 테스트하기 위해 클라이언트를 분리했음

(이상)

• yo : 스캐폴딩(Scaffolding : 골격, 뼈대) 자동 생성 도구
• grunt : 타스크 실행 도구
• bower : 패키지(라이브러리) 관리 도구
...들을 잘 묶어 놓은 개발도구이다.

Backbone.js를 써서 프론트엔드 웹앱을 만들 때 폴더 구조와 파일 이름을 어떻게 정할까 고민스러웠는데, 비슷한 고민을 담고 있는 블로그 기사가 있어 요약한다.

• JavaScript는 폴더/파일의 구조 및 이름에 대해 규정하는 바가 전혀 없다.
• 그러니 당신이 어떻게 하고 있더라도 "당신은 옳다".
• 개인적으로 Backbone 등 MVC framework을 사용하는 경우 models, collections, views 등 타입별로 폴더 구조를 가져가는 것에 반대한다.
• contact, mail 등 업무나 역할 별로 폴더 구조를 만들고,
• person.js (model), persons.js (collection), personview.js, personrouter.js 처럼 파일 이름에 타입을 명시하는 방식을 선호한다.
• 하지만, 다시 한번 말하지만 당신이 어떤 결정을 하더라도 "당신은 옳다"

JavaScript File & Folder Structures: Just Pick One

CppCon 2014, C++ 개발자대회 요약

• 구글을 비롯 많은 회사들이 C++ 코드에서 exception을 사용하지 않고 있음. exception은 아직 "solved problem"이 아님.
• 페북, 0.4% 속도 개선을 위한 cheating도 불사. 대규모 서버 프로그램에서는 중요한 이슈. 0.4% 성능개선을 통해 수 $million에 달하는 비용(전기요금)을 절감할 수 있음.
• std::vector<>는 CPU의 명령어 캐시 관련 문제로부터 안전. 다른 std::container<> 류는 안전을 장담 못함.
• 전세계적으로 기술서적 판매는 3% 줄었지만 C++ 서적 판매는 4% 증가. C++ 개발자 저변이 넓다는 증거.
• Bjarne이 "A Tour Of C++" (2013년 9월)을 출간했으며, 책에 대해 진심으로 자랑스러워 하고 있음.
• C++ 언어 표준화는 현재 진행형. parallel/concurrent 처리에 대해 논의하고 있음. 많은 참여 바람.
• 올해가 첫 컨퍼런스로 600 여명 참여. 매해 개최 예정.




출처: CppCon 2014 Is Over (http://hereticalcpp.blogspot.kr/2014/09/cppcon-2014-is-over.html)

요약
- IoT Device 사이의 상호운용성(Interoperability)을 보장하는 표준을 정의하기 위해 Allseen Alliance(퀄컴 주도), Thread 그룹(구글 주도), OIC 그룹(인텔 주도) 컨소시엄이 활동 중
- 삼성전자는 Thread 그룹과 OIC 그룹에 참여 중
- 애플은 아직 컨소시엄에 참여하지 않고 있음


Allseen Alliance (2013년 12월~)
+ 목표
  - 상호 연결 가능한 Thing과 App의 확산
  - AllJoyn 기반 통신 프레임워크의 확산
+ 오픈소스 AllJoyn(올조인)
  - 가전기기/자동차/컴퓨터가 상호 커뮤니케이션할 수 있는 오픈소스 프레임워크
  - 퀄컴이 2011년 MWC에서 처음 공개한 오픈소스 프로젝트
  - 2013년 12월 리눅스 재단으로 소스 이관(리눅스 재단의 11번째 협업 프로젝트)
- allseenalliance.org 에서 코드와 API스펙 다운로드 가능
- WiFi 기반
+ Allseen Alliance가 성공할 것 같은 이유 (Allseen Alliance가 주장하는 이유임)
  - 다양한 분야의 많은 회사들이 참여하고 있기 때문
  - 공개표준 기반 오프노스 프로젝트 AllJoyn을 갖고 있기 때문
  - 이미 AllJoyn을 채택한 상용제품이 존재하기 때문 (LG HDTV, LIFX 스마트 전구)
  - 포괄적 인증 프로그램을 운영하고 있기 때문
- 참여업체: 시스코, 하이얼, LG전자, 파나소닉, 샤프, 퀄컴, MS, 리눅스 재단 등
 

Thread 그룹 (2014년 6월~)
+ 목표
  - Thing마다 상이한 프로토콜 문제 해결
  - 데이터 전송 거리 문제 해결
  - 배터리 제약 문제 해결
+ 가정용 기기들을 연결하고 제어하는 최선의 방법을 찾기 위해 설립
  + 가정용 네트워크 기술의 한계 (as-is)
    - HUB 기기가 죽으면 네트워크 자체가 불통됨
    - 설정이 어려움
    - 기기들이 항상 켜져 있어야 하기 때문에 배터리 소모가 심함
  + Thread 그룹이 만들려는 프로토콜
    - 쓰기 쉬울 것
    - 안전할 것 (Security)
    - 전력 효율이 좋을 것
    - IPv6 기반 공개 프로토콜일 것
    - HUB 없는 MESH 네트워크일 것
    - IEEE 802.15.4 무선 표준 (ZigBee)* 기반일 것
    - 다양한 기기를 지원할 수 있을 것
      * IEEE 802.15.4 무선 표준 : 저렴함과 단순함을 추구하는 사물(임베디드 시스템)을 위한 무선 네트워크 기술 (ZigBee로 통칭), 사람을 위한 무선 네트워크 기술 WiFi와 대비됨
+ Thread 기술의 특징
  - 지금 당장 사용 가능
  - Nest가 이미 초기형태의 Thread 기술을 사용하고 있음
- 교육과 인증 사업 추진 예정
- 참여업체: 구글, 삼성전자, ARM 등


OIC (Open Interconnect Consortium) (2014년 7월~)
+ 목표
  - IOT를 위한 연결(Connectivity) 요구사항 규정
  - 이종 기기들 사이의 상호운용성(Interoperability) 보장
+ 활동 분야
  + Interoperability 제공을 위한 스펙/인증/브랜드 규정
    - IP(네트워크) Protection 제공
    - 기기에 대한 인증 제공
    - 서비스 레벨 상호운용성 제공
  - 표준을 구현한 오픈소스 SW 제공
  - 공개표준, 크로스플랫폼SW 지향
- 참여업체: 인텔, Atmel, 델, 브로드컴, 삼성, 윈드리버 등
- 퀄컴 등의 영리 기업이 올씬얼라이언스를 통해 오픈소스 프로토콜 제정을 주도하는 것에 반대
- 퀄컴과는 경쟁, 오픈소스 공동체와는 협력 표방


oneM2M
- oneM2M은 한국 TTA를 비롯 7개 세계 주요 표준화 기관이 공동 설립한 글로벌 표준화 기구
+ 목표
  - 다양한 산업 직군간 요구사항, 아키텍처, 프로토콜, 보안기술, 단말 관리 및 시맨틱 추상화 표준 정의
- '14년 7.28~8.1 프랑스에서 개최된 oneM2M 12차 기술 총회에서 oneM2M 1.0 표준 승인
+ 참여업체

  - 한국 TTA와 ETSI(유럽), ATIS(북미), TTC(일본), CCSA(중국) 등 7개 세계 주요 표준화 기관을 비롯,

  - 해외기업 AT&T, 스프린트, 에릭슨, 시스코, 화웨이, 퀄컴, 알카텔루슨트, 인텔 등 참여
  - 국내기업 SKT, KT, LGU+, 삼성전자, LG전자 등 참여

(이상)

구글, 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팀의 역할은 품질을 확인하는 것이지 없던 품질을 추가하는 것이 아니다. 자신의 코드는 자신이 책임져라.
- 일을 시작하기 전에 모듈 리더와 소통하라.
    - 아이디어 단계에서 거절당하는 편이 패치코드를 거절당하는 것보다 덜 아플 것이다.
    - 다음에 할 일을 일러줄 것이다.
    - 막혀있는 문제를 풀어줄 것이다.
- 리뷰를 요청하기 전에 스스로 리뷰하라. 당신의 리뷰 스킬을 높일 필요가 있다.

(이상)