어니스트컴퍼니 설립 동기에 대한 질문에 제시카 알바는 “두 딸의 엄마로서 안전하고 믿을 수 있는 제품의 필요성을 실감한 것이 가장 큰 동기부여가 됐다”면서, “학습 장애, 천식, 비만, 암 등으로 이어질 수 있는 독성화학물질이 포함된 제품을 우리 아이들이 사용하는 것을 원치 않았기 때문”이라고 밝혔다.

 
 공동창립자 브라이언 리(Brian Lee)는 “제시카 알바가 먼저 적극적으로 움직여줘서 가능했다”며, “그 열정을 배워야겠다고 생각했고 두번째 제안에 흔쾌히 수락했다”고 말했다. 어니스트 컴퍼니는 환경 친화적이며 건강을 생각하는 기업을 위한 제도인 비 코퍼레이션의 인증을 받았으며, 현재 40여 개 제품을 출시하고 있다.
 
 제시카 알바는 어니스트 컴퍼니 제품에 대해 “모든 재료를 투명한 용기에 담아 내용물을 한 눈에 볼 수 있게 했다”면서, “항상 정직한, 최고의 제품을 제공하기 위해 고객들과의 개방적인 대화와 소통을 통해 제품에 반영하려고 노력 중이다. 어니스트 컴퍼니의 제품은 나와 모두의 초협력의 작품이나 마찬가지”라고 말했다.
특히 “친환경 기저귀의 경우 천연소재를 사용했음에도 흡수율이 다른 제품 대비 35~40% 개선되었다”면서, “유해물질, 우수한 성분이 있어야만 성능도 뛰어난 것은 아니다”고 말했다. 또한 “품질뿐만 아니라 제품도 아름다우면 더 좋을 것으로 생각하기 때문에 디자인도 소홀히 하지 않았다”고 덧붙였다.
 
 브라이언 리 역시 어니스트 컴퍼니가 강조하는 가장 큰 가치가 ‘투명성’이라며 “다른 기업처럼 영리를 추구하는 것이 아니라, 가장 독성이 없고 성능이 좋은 제품을 가장 저렴한 가격에 제공하는 것이 최대 목표”라고 힘주어 말했다.
 
 대기업들이 자본으로 시장에 뛰어드는 것에 대한 경쟁 우려는 없는지에 대한 질문에 두 창업가는 ‘원하는 바’라면서 “우리는 보다 많은 기업들이 지속가능하고 자연적인 천연 성분을 사용하길 바라며, 더 많은 기업들이 우리의 의견에 동참하는 것을 언제든 환영한다”고 입을 모았다. 또한 “흥미로운 파트너를 찾아 협력할 수 있는 기회가 앞으로도 많이 있을 것으로 기대한다”고 덧붙였다.
 
 제시카 알바는 “한국의 어머니들은 특히 아이들의 복지와 웰빙에 많은 관심을 갖고 있어서 한국에 오게된 것이 매우 기쁘다”면서, “한국은 아동친화적인 도시라 다시 찾고 싶다”고 말했다.

Honest Company : https://www.honest.com/







 박원순 시장은 알랭 드 보통에 이어 기조연설자로 나섰다. 초협력과 시민들과의 소통을 통한 서울시의 정책에 관하여 강연했다. 그리고 알랭 드 보통의 인생학교에 대한 협력 의사를 밝혔다. 밑에 강연 내용을 정리했다.


 소통과 협력, 이를 넘어선 초협력을 통해 서울시를 이끌어 나가고 있다. 재개발과 뉴타운이 진행되는 서울시는 현재 많은 갈등에 부딪히고 있다. 이를 해결하기 위해 소통이 중요하다. 이전에는 책상에서 이루어 지던 행정을 현지 주민과의 소통을 통해 정책을 만들고 시행하기 시작했다. "현장에는 늘 답이 있다"


 전문가와 시민들을 직접 모시고 청책 토론회를 통하여 시민들의 목소리를 듣고 있다. 또한 찬성과 반대를 하는 사람들을 모두 모아 청책을 진행한다. 시청 앞의 시민발언대를 통하여 시민들의 목소리를 직접 듣고 있다. 그리고 이 목소리들은 동영상으로 녹화되어 해당 공무원을 통해 직접 처리되고 있다.


 SNS 행정을 통해 시민들의 목소리에 귀를 기울이고 있다. 실제로 시민들의 애로사항을 SNS로 통하여 듣고 시에서 해결해나가고 있다. 그리고 소소한 삶의 문제들도 듣고 해결해 나서고 있다. 심야버스 운행이 대표적인 예로 들 수 있다. 소셜 미디어 센터를 통해서 시민들의 제안도 적극 수렴하고 있다. 서울은 응답하는 정부로 탈바꿈이 되고 있다.


 정보 공유 누드 프로젝트를 통하여 시정의 투명성을 제고하고 있다. 특별한 프라이버시 침해, 혼란을 초래하지 않는 정보는 모두 공개하고 있다. 또한 빅데이터를 제공함으로써 앱 개발에 협력하면서 시민들의 편의를 도모하고 있다.



서울시 120다산콜센터 : http://120dasan.seoul.go.kr/

서울시 시민 발언대 : http://www2.seoul.go.kr/event/e_111214_speech/speech.html

서울시 소셜 미디어 센터 : http://social.seoul.go.kr/user/main.web

서울시 열린 데이터 광장 : http://data.seoul.go.kr/

박원순 시장 트위터 : https://twitter.com/wonsoonpark/



 세계적인 베스트셀러 작가, 알랭 드 보통은 인생학교(the School of Life)의 교장으로서 참석해 일상의 지혜와 교육에 관하여 강연했다. 밑에 알랭 드 보통의 강연 내용을 정리했다.


 농부의 아들이 농부가 되는 전통사회와 달리, 현대사회는 스스로 노력하면 무엇이든 할 수 있다고 교육한다. 빌게이츠나 왕족이 되기를 꿈꾸지만 로또 당첨보다 어렵기 때문에 그렇게 되지 못하면 자괴감을 느끼게 된다. 현대 교육은 기술과 지식에 치중되어 있어 살아가는 방법에 대한 교육을 해주지 못한다.


 좋은 교육은 회계, 생물, 엔지니어링 등의 기술적인 실력이나 능력이 아니라 인생의 도전 과제에 현명하게 대처하고 관계를 키우는 방법, 사회에 대한 의무, 잘 살 수 있는 방법에 대한 가르침이 되야한다. 인생에서 중요한 것은 사랑과 직업이다. 가장 도전적이면서 어렵기도 하지만 가장 훌륭한 가치이다.


 주입식 교육은 오래 가지 않는다. 교육방식에서도 설득과 즐거움의 과정이 필요하며 자극과 지식을 제공하고 인내력과 공감, 희망, 지혜 등의 가치를 한께 소통하는 것이 중요하다.


 돈이 아닌 삶의 의미와 목적 의식, 지혜를 얼마나 가졌는지가 성공의 판단 기준이 되야한다. 기술 역시 현대인들에게 진정한 만족감을 줄 수 있는 방향으로 발전해야 한다.


 한국에도 '어른을 위한 학교', '인생학교'를 설립하고 싶다. '인생학교'는 변화와 불확실성 속에서 어떻게 하면 현명한 삶을 살 수 있는가에 대한 고민과 해답을 찾기위해 존재한다.







 2013년, WWW(월드 와이드 웹)의 탄생 20주년을 맞 SDF 2013의 기조연설자로 WWW의 창시자 팀 버너스-리가 올라왔다. 밑의 내용은 팀 버너스-리가 강연 중 한 말을 정리한 내용이다.


 WWW가 있기 이전에 인터넷은 존재했다. 하지만 모든 사람들이 사용할 수 있는 것은 아니었다. 인터넷은 1969년 개발된 이래 20년동안 소수의 대학과 연구기관만 사용해왔다.


 소수가 아닌 다수의 협력과 연결이 가능한 사이버 공간을 만들고 싶었다. 1989년 CERN(유럽 입자 물리 연구소)에서 WWW를 개발했고 이를 특허 신청하지 않고 1993년 4월 30일 무료로 일반에 공개했다. 이 세상에는 많은 문제들이 있고 각자 부분적인 해답을 가지고 있다. 전 세계적으로 산재해 있는 해답의 조각들을 맞추는 방법이 사이버 공간이라고 생각했때문에 WWW를 개발하게 되었다.


 인터넷은 태생적으로 개방되어 있기 때문에 여러 부작용도 생겨나고 있다는 지적을 받고 있다. 이를 해결하기 위해서 웹을 사용하는데 있어 좋은 의도로 시작하는 사이트를 권하고 싶다. 또한 Junk가 아닌 Fact를 찾기 위한 노력이 필요로하다.


 인터넷은 개개인에게 하나의 인권이기 때문에 이를 검열하거나 침해해서는 안된다. 인터넷의 중립성과 개방성을 보장해야만 세계 평화를 구축하는 발판이 될 수 있다.




Hadoop : 대용량 데이터를 분산 처리할 수 있는 자바 기반의 오픈 소스 프레임워크

1. Distributed File System

2. Distributed/Parallel Computing Framework

3. Open Source Project




Hadoop 에코 시스템

  • Avro : 멀티 플랫폼간 데이터 호환 Serialization 도구
  • Cassandra : DHT기반의 분산 데이터 관리 시스템. Hadoop은 사용하지 않고 로컬디스크 이용
  • Chukwa : 분산 환경에서 로그를 수집하기 위한 시스템. 저장소로 HDFS를 이용하고 로그분석을 위해 Map/Reduce를 이용
  • Hama : Map/Reduce 방식이 아닌 BSP(Bulk Synchronous Parallel) 방식의 컴퓨팅 플랫폼
  • HBase : HDFS에 데이터 파일을 저장하는 분산 데이터 관리 시스템
  • Hive : SQL과 비슷한 스크립트 질의를 이용해 HDFS에 저장된 데이터를 Map/Reduce로 분석하는 도구
  • Impala : Hive 질의 문법을 지원하는 준 실시간 질의 실행 플랫폼
  • Mahout : Hadoop 기반 Machine Library
  • Oozie : Hadoop Workflow 엔진
  • Pig : Hive와 유사하게 스트립트 질의를 이용해 HDFS에 저장된 데이터를 Map/Reduce로 분석하는 도구. 단순 스크립트가 아닌 반복문, 제어문, 변수 등 사용 가능
  • Zookeeper : 분산 환경을 관리하는 분산 코디네이터




대용량 파일 시스템

DAS

NAS

SAN

GFS(Google File System) : 구글에서 개발된 파일 시스템으로 많은 구글의 서비스에서 이용


소프트웨어는 공개하지 않고 논문만 공개

http://www.cs.rochester.edu/meeting/sosp2003/papers/p125-ghmawat.pdf



다음과 같은 설계원칙

  • 저가형 서버로 구성된 환경으로 서버의 고장이 번번히 발생할 수 있다고 가정
  • 대부분의 파일은 대용량 파일로 가정
  • 작업 부하는 연속적으로 많은 데이터를 읽는 연산이거나 임의의 영역에서 적은 데이터를 읽는 연산
  • 파일에 대한 쓰기 연산은 주로 순차적으로 데이터를 추가하는 연산. 파일에 대한 수정은 드물게 발생
  • 여러 클라이언트에서 동시에 동일한 파일에 데이터를 추가하는 환경에서 동기화 오버헤드를 최소화할 수 있는 방법 필요
  • 낮은 응답 지연 시간보다 높은 처리율이 좀 더 중요



HDFS(Hadoop Distributed File System)
1. Very Large Scale Distributed File System
    • 10K node, 100 million files, 10 PB(1PB = GB)

2. Use Commodity Hardware

    • Self-Healing : failover, recovery, backup
    • 서버 장애를 일반적인 상황이라고 가정

3. Optimized for batch processing

    • 주로 저장 후 읽기 윚의 데이터 저장
    • 1 File = n개의 64MB size block으로 split
    • 각 block은 서로 다른 node에 분산저장

4. POSIX 표준 API는 지원하지 않음

    • 자체 API 지원(Java, C)



HDFS 컴포넌트

1. NameNode

2. Secondary NameNode

3 .DataNode

4. Client Library




Map/Reduce

Map : 키와값으로 키와 값으로 구성된 목록을 만들어 준다.

Reduce : 키와 목록으로 다시 목록을 만들어 준다.




Hive




HiveQL


3.ubuntu_custom.pdf



우분투 한국커뮤니티

국제적으로 승인받은 팀

-런치패드에 주소가 있고

-포럼이 있고

-메일링리스트가 있고 위키가 있으면 우분투 커뮤니티로 승인을 해준다.(2009.2)

 

sudo apt-get install build-essential

터미널에서 이 명령어 하나로 개발환경을 구축가능하다.

 

우분투는 데비안 패키지를 다 가져다 사용한다.

 

 

 

 

 

커스터마이징

배포판으로 인정 받으려면 가장 중요한 것 – 저장소를 따로 운영해야한다.

 

가상환경과 UCK

가상환경과USB메모리는 배포판 테스트가 용이하다.

Chroot, 버추얼 박스, VMware, USB메모리

 

Ubuntu Customization Kit

http://uck.sourceforge.net/

설치 명령어 : sudo apt-get install uck

기본 실행 : uck-gui

*배포판을 만들 때 여유공간이 5기가 이상을 되야한다.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

UCK 사용법

$./uck-gui

1. 초기환영말

2. 설치 언어 선택

3. 라이브CD 언어선택

4. 부팅언어 선택

5. 테스크탑 환경선택

6. ISO 선택

7. 만드려는 CD 이름 입력

8. 콘솔작업 할지 결정 (chroot 콘솔 )

9. 우비 , 오토런 추가 삭제 여부

10. ISO 풀고 CHROOT 환경 만들고 .. 등등 알아서 ...

11. 항목설정 ( 패키지 매니저 & 콘솔 )

계속 진행 완성으로 가도 되나 여기서 멈추는 이유는 좀더 세밀한 작업을 위해 멈추며 뒤에 가서 추가 설명...

 

 

SQUASHFS : 우분투 CD 700메가를 넘지 않기 위해 SQUASHFS를 이용하여 부팅시 압축을 풀면서 라이브 및 설치환경을 구성한다.

우분투 12.10 700메가를 넘어서 DVD에 담겨있다.(700메가는 의미없음)

 

UCK 주요명령어

uck-gui 정체는 uck 스크립을 순차적으로 실행 해주는 구조 .

uck-remaster-chroot-rootfs

uck-remaster-pack-rootfs

uck-remaster-pack-iso

 

 

 

우분투가 종류가 많은 이유는 여러 사용자를 끌어들이기 위해서이다.

유명환씨가 만든 이분투는 임베디드 개발에 필요한 툴들을 포함되어 있다.

 


2.invehicle_network.pdf



차량에 마이크로 프로세서 100~200여개 탑재

차량은 움직이는 병렬 컴퓨터

 

사람의 목숨이 달려있을수록 보수적인 경향이 크다.

비행기 -> 고속철도 -> 차량

 

기계적인 부품이 없다는 것은 결함이 줄어든다는 것을 의미한다.

유지보수가 줄어든다.

전자, 전기적인 구성요서면 안정선, 부피 등의 모든 면에서 효과를 얻는다.

증기기관에 의해서 인간이 힘을 통제할 수 있게 되었다.

전기의 장점 : 에너지의 생산지와 소비지를 이원화 시켜버렸다.

 

차량의 무게가 줄어들수록 차량의 효효율이 좋아진다. 기계적 부품대신에 전기, 전자적 부품을 사용하면 경량화가 된다.

 

과거의 비행기는 유압식으로 동작했다.

현대의 비행기는 전기, 전자적으로 동작한다.

요즘 차량들은 스캐너장비를 MCU에 연결하여 고장의 원인을 손쉽게 알아낸다.

 

요즘 비행기들은 Power-CPU를 사용한다.

물리적인 장비를 없애고 나서는 선이 문제가 된다.

요즘 비행기와 자동차들의 이슈는 배선의 문제이다.

 

CAN BUS를 쓴다. 비행기용 CAN 규약을 이용한다.

메인 라인을 이용해서 신호를 보낸다. 선의 개수를 줄여 무게를 줄이고 유지보수가 편해진다.

 

1977GM에서 처음으로 ECU(자동차 엔진의 점화시기를 결정)를 도입

트릭컴퓨터로 현재 차량의 상태를 계산한다. 연비를 계산하고 있다가 알려준다.

스캐닝 기능을 이용해서 차량의 고장을 쉽게 진단하게 된다.

 

90년대부터 OBD가 등장한다. 차량의 상태와 연비를 계산해준다.

미국내 차량의 탑재 의무화를 시킨다.

OBD를 연결해서 보면 RPM, 속도, 외부온도, 연비 등이 기록된다.

 

 

 

 

 

 

 

 

 

 

네트워크 아키텍쳐

토플로지 : 네트워크의 형상

실시간 특성 : 이벤트/타임 트리거

물리적 특성 : Connector/Medium의 유형, 최대 전송 길이, 전자파

페이로드 길이 : 전송하는 단위당 패킷의 길이

속력, 가용성, 안정

 

제어정보

LIN : CAN보다 싸게 로컬네트워크를 구성 -> 가격 경쟁력이 없어서 사라지는 중, CAN을 이용하면서 규모의 경제에서 얻어오는 이익을 취하게 됬다.

CAN(high/low) : 차량의 표준, 장비가 늘어나면서 실시간성이 강한 시그널이 문제가 되기 시작했다. 차량의 안정성을 보장하기 위해서 FlexRay를 개발

FlexRay : 이벤트/타임 트리거를 모두 지원한다. 실시간성이 보장되어야 하는 데이터는 타임트리거 방식으로 동작

TTCAN : CAN에서 타임트리거를지우

 

멀티미디어 정보

Bluetooth

MOST : 150Mbps 멀티미디어를 실어나르기 위한 시그널이다.

EatherNet : 100Mbps가 표준

 

 

 

백본을 FlexRay를 설치한다. 비행기를 따라 향후 이더넷으로 설치 추측

제어 정보는 FlexRay, 나머지는 CAN방식으로 구성

 

향후, 가장 높은 가능성은 백본은 이더넷으로 하고 각 부분 모두CAN으로 구성할것으로 추측

 

CAN은 버스구조이므로 라우팅 자체가 어렵지 않다.

 

 

MOST는 링 구조를 사용, 이더넷이 치고 올라올거 같아 MOST는 묻힐것이다.

 

차량내의 각 섹션에 스위치에 장치들이 물리고 스위치들은 백본에 물린다.

하나의 네트워크가 모두를 점유하지는 못할 것이다.

 

CAN은 차량에서 계속해서 살아남을 것이다. 이더넷은 CAN의 백본으로 널리 사용될 가능성이 높다. LINMOST는 향방을 알기 어렵다.

에어백과 ABS 등처럼 안정성과 밀접한 관련성이 있는것은 FlexRay가 쓰일 것이다.

 

 

CAN 구현 방식

Basic CAN

Full CAN

FIFO

FULL CAN w/ Receive FIFO

 

 

 

차량의 시그널 해상도가 더욱 조밀하기 때문에 리눅스를 이용해서 모든 차량의 CAN 시그널을 빼낼 수는 없다.

 

 

고려해야할 점

실시간성

비용

표준과 안전


1.multicore_scheduler.pdf



멀티코어 무어의 법칙

 

ARM – 옥타코어 2015~16

GPGPU롤 활용하려고 한다.

 

클럭 수를 낮추고 분산해서 돌리면 전력면에서 효율적인 효과가 있다.

서버 시장에서도 전력 소모량이 너무 많아서 ARM 서버의 시대가 될거라고 얘기한다.

기존의 서버보다 ARM서버를 사용하게 되면 1/8수준으로 줄일 수 있다.

64비트 우분투도 올려서 ARM 서버를 사용하려고 하고 있다.

 

 

멀티코어의 연구흐름

싱글코어의 시대 ->

멀티코어(호모 지니어스)의 시대 ->

Heterogeneous System

 

 

멀티코어 기술의 한계

새로운 하드웨어가 나와도 소프트웨어 수정없는 성능 개선이 어렵다.

 

주요 연구

전력소모 장벽문제

CPU 3GHz를 넘어서고 전력 소모가 더욱 많아진다.

 

메모리 장벽문제

메모리 처리율 성장속도(매년 10%)CPU 처리율 성장속도(매년 55%)의 차이가 크다.

효율적인 캐시 사용이 중요

 

프로그래밍 장벽문제

멀티코어를 활용한 소프트웨어 개발은 매우 복잡

멀티코어용 프로그래밍 모델의 중요성

 

확장성 문제

멀티코어로 인한 병목현상 : 상호배제와 락킹

                          코어 간 공유캐시 접근 시, 높은 비용

 

Fine-Grained Locking 늘리는 방향

상호배제 락킹 감소

공유 자료구조 줄이는 방향

코어 친화적 스케줄링(Affinity 고려)

효율적인 캐시 활용방향

 

 

 

*암달의 법칙 : 병렬 프로세싱으로 얻어지는 퍼포먼스를 계산하는 공식

멀티코어 구조

 

HomoGeneous

동일한 두개나 그 이상의 코어로 구성

다중 동일코어 사용

코어간의 공유 메모

일반적으로 캐시의 일관성을 위해 하드웨어가 지원해준다

 

 

 

HeteroGeneous

이종의 두개나 그 이상의 코어로 구성

ISA(Instruction Set Architecture)

범용코어와 가속코어를 동시에 사용하는 구조

ASMP

ACMP

 

NVIDIA Tegra

1코어와 쿼드코어간의 전환에서 스레싱 문제가 발생할 여지가 있다.

 

ARM

Big . Little solution System(엑시노스 옥타에 이용)

Cortex-A15(고성능)Cortex-A7(고효율)HeteroGeneous하게 사용하는 구조이다.

Switcher의 소스코드가 공개되어있다.

CCI(Cache Coherent Interconnect)

 

GPGPU System

서로간의 명시적 데이터전송 지원

소프트웨어에 의한 관리

OpenCLGPGPU를 활용한 컴퓨팅 지원(C99과 유사)

작업단위를 분리하면 컴파일러가 CPU GPU에게 작업단위를 할당

 

WebCL을 이용해서 웹에서도 GPGPU를 웹 가속에 이용

NVIDIACUDA

 

 

 

 

 

 

 

 

 

 

 

 

 

리눅스 멀티코어 기술

커널 – Lock Mechanism

       Load Balancing

       CPU Affinity

 

라이브러리 – OpenMP : 병렬 스레드 지원

             OpenGL : GPU를 이용한 렌더링

             WebGL : 웹기반의 3D가속

             OpenCL : GPGPU를 활용한 컴퓨팅

             WebCL : GPGPU를 이용한 웹가속

 

CFS(Completely Fair Scheduler)

 

DWRR(Distributed Weighted Round-Rpbin)

각 코어들의 시간 단위 안에서의 태스크들을 라운드로빈으로 스케줄링해준다.

레드-블랙 트리를 이용해서 쉬는 코어에서 바쁜 코어의 태스크를 가져온다.

 

 

 

*레드-블랙 트리



!!소스리딩의 결과를 통계를 내면 소프트웨어의 품질을 높이는 툴!!

 

예전의 개발 방식은 순차적 폭포수 개발 방식!!

계획 -> 설계 -> 개발 -> 테스트 -> 유지/보수

 

최근의 개발 방식은반복적 점진적 개발 방식!!

Iteration을 아주 짧게 돌려서 기능 부분별로 개발한다.

개발과 테스트를 동시에 진핸한다.

단계별로 Small Release를 한다.

사이사이에 코드 리뷰를 하고 분석을 한다.

 

CI 서버를 이용하여 개발자들이 COMMIT을 하고 통합빌드 -> 릴리즈빌드를 진행한다. => 피드백을 팀장에게 메시지를 보낸다.

 

 

 

무엇이 문제인가??

 

-소스코드는 관리하기 힘들다.

-아무도 있던 소스로 일하기를 원하지 않는다.

-자주 수정하다보니 걸레 수준이다.

-소스를 작성한 엔지니어가 이미 회사를 떠났다.

-프로그래머의 개성이 강하다.

 

 

소스를 보면…..

표준함수가 있는데 안 쓰고 자기가 만든다.

설명이 없는 상수가 많다.

함수의 길이가 길다.

함수, 변수의 이름에 일관성이 없다.

약어, 상징어를 자기 맘대로 쓰는 것

 

 

안전하고 좋은 코드!!

오류 발생 가능성이 적은 코드

테스트가 가능한 코드

보기 좋은 코드

 

 

좋은 코드를 만드는 습관!!

-설계를 미리 고민한다.

-구현 전에 문서를 만든다.

-소스를 반드시 읽자!!

-모든 문제를 분석하자!!

-나만의 문제란 생각을 버리자!!

-비효율적인 답최적의 답, 중간의 답 => 모두가 정답이다!!

-최적화는 뒤로 미루자 깨끗한 코드를 작성하는 것이 먼저 => 구조적인 최적화를 고민

-성능 최적화는 프로파일링 툴로 성능을 평가한 후에 가장 큰 놈만 팬다.

-읽기 어려운 코드는 reuse도 하지 말자

-디버거를 꼭 사용해야 한다.

-warning은 미래의 버그이다.

-코딩의 생산성을 생각하자!!

-문법의 오류가 없어도 오해의 소지가 있다면 쓰지 말자!!

-‘핫 키를 사용해야 한다 => 마우스를 사용하면 손가락 5개를 뺏기게 된다.

 

 

도구를 이용하자!!

에디터, 검사도구, 이슈 트래킹, 버전관리 등등

 

바둑 : 기보를 보며 공부하고 복기를 한다.

코딩 : 남이 만든 코드를 읽고 내가 작성해 본다.

 

 

신뢰성 있는 코드를 만드는 것!!

아주 잘 테스트가 되어있는 소스들은 프로들이 짜도 하루에 10~40줄 정도!!

'Seminar > 소스리딩 워크샵' 카테고리의 다른 글

소스리딩 - 이민석  (0) 2012.08.04


.com bubble 이후

구글 검색 API 제공

아마존 책 관련 API 제공

이베이 물건의 리스팅 API 제공

 

사업을 코어에 집중하고 서비스는 API를 통해서 제공

=> light weight business

 

WEB 2.0

Web as Platform

 

페이스북이 마이스페이스를 제치기 시작한 것은 앱 랫폼을 지원하기 시작한 시점부터였다.

 

Open source => Open WEB => Open API, Cloud

 

 

!!Keyword!!

Open source, Open standard, Open API

 

Open API

Request => parse => use

 

API 1billion club

1. 트위터

2. 넷플릭스

3 .아마존

4. NPR

5. 구글

6. 페이스북

7. 이베이

8.

 

REST

API 서비스 프로토콜

상태를 표현하는 프로토콜

 

JSON

API 서비스 포맷

Java script에서 많이 사용 포맷도 쉽고 포팅도 쉽다.

 

OAUTH

API 권한 부여

사용자의 콘텐츠를 건드리기 위한 권한부여를 위한 API

서비스 이용 시, 권한이나 애플리케이션 승인창들은 OAUTH API를 사용

 

 

Github – Open source developer’s social network

 

API playground – 개발환경을 설치할 필요가 없다.

에반젤리즘

 

오픈 API기술 제공 – DAUM DNA(http://dna.daum.net)

'Seminar > DAUM Boot Camp' 카테고리의 다른 글

오픈API - 윤석찬  (0) 2012.08.04
페이스북 Integration - 김기영  (0) 2012.08.04
OAuth 강의 - 이승철  (0) 2012.08.04

+ Recent posts