YouTube 동영상

2016년 9월22일에 업로드된 동영상이다. C++ 랭귀지를 만든 Bjarne Stroustrup(베야네 스트로스트룹)이 C++의 과거와 미래에 대해 설명한다. 한번 들으면 좋은데 너무 길다 (1시간43분). 내용을 간단히 요약한다.

- C++ 성공은 운이 아니다. C++ 성공에는 분명한 이유가 있다.
+ 랭귀지 저자가 생각하는 C++
  - 하드웨어를 직접 다루는
  - 오버헤드가 전혀 없는
  - 산업계 현장에서 사용하는
  - 좋은 프로그래머에게 더욱 유용한 랭귀지

- 랭귀지는 조그만 변해도 짐스럽다(구현, 도구제작, 학습이 필요). 변화 방향을 신중하게 결정해야 한다.
+ C++ 변화 방향
  - zero-overhead
  - 메모리 leak 등이 없는 안전한 코드를 만들게 할 것이다
  - 가비지컬렉션 등으로 인한 성능저하는 없을 것이다 (피할 것이다)

+ C++17 출시 임박
  - 아직도 C++98에 머물고 있다면 C++11, C++14로 업그레이드하라.
  - 적어도 현재에 머물러 미래를 준비하라
+ 깃허브에 C++ core guideline 문서가 존재한다
  - 한국어 번역에 참여한 사람들에게 감사한다
- 우리가 매일 사용하는 SW를 보존하기 위해서라도 C++은 계속 발전해야 한다

(이상)

어쩌다보니 혼자 하게 된, ES6에 대한 아주 알찬 소개. 정성을 다해 번역했습니다.

ES6 in depth

http://hacks.mozilla.or.kr/category/es6-in-depth/

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은 큰 문제가 아님, 일정을 다시 조정하면 됨

(이상)