<< Previous | Home

Peter Thiel과 그가 생각하는 미래

PayPal의 창업자이자, 투자자(Facebook, Friendstar, Powerset, Linkedin, Quora, Zynga, Yammer, SpaceX)인 Peter Thiel이 쓴 Zero To One을 읽으면서 Peter Thiel이 어떤 사람인지 궁금했다. 이분은 참 독특하면서도 재밌다. Facebook 투자로 억만장자가 되었고, 그 사람의 투자한 회사들을 보면 미래가 어떻게 흘러가리라 예상할 수 있다.

그리고 Peter Thiel을 알기전에 먼저 Paypal Mafia에 대해 먼저 알 필요가 있다. Peter Thiel은 페이팔 마피아의 대부였기도 했고, 이들은 서로 서로 창업을 한 동료들을 투자해주기도 했지만, 그들이 투자하고 창업한 회사들은 하나같이 유명한 회사들이어서 살표보면 놀랍다.

Paypal Mafia

  • Peter Thiel : PayPal 창업자, eBay에 $1.5 billion에 매각. Facebook, Friendstar, Powerset, Linkedin, Quora, Zynga, Yammer, SpaceX 투자자.
  • Max Levchin : Slide를 Google에 매각해 부사장됨.
  • Elon Musk : Space X 창업, Tesla Motors 창업, Tesla IPO.
  • Reid Hoffman: Linkedin 창업, Facebook, Friendster, Six Apart, Zynga, IronPort, Flickr, Digg 등의 스타트업에 투자하는 등 투자자로 행보를 이어감.
  • David Sacks : Yammer 설립 후 2012년 6월에 $1.2B로 Microsoft에 Exit.
  • Jeremy Stoppelman(Yelp/CEO), Russel Simmons(Yelp/CTO) : Yelp 창업.
  • Steve Chen(Youtube/CTO), Chad Hurley(Big Six/Founder), Jawed Karim(Youniversity Ventures/Partner) : Youtube를 Google에 Exit.
  • Keith Rabois : Square에서 COO로 있다가 투자자로 행보를 이어감.
  • Roelof Botha : Sequoia Capital에서 PayPal 마피아 회사에 많은 자금을 제공하고 있고, Facebook과 Youtube에 투자함.

Singularity



미국의 발명가이자 미래 학자 Ray Kurzweil이 쓴 "How to Create a Mind:The Secret of Human Thought Revealed"에서는 컴퓨터가 인간의 뇌가 가진 패턴을 시뮬레이션이 가능하며, 현재 속도로 컴퓨터의 성능이 상승한다면, 기술이 기하급수적으로(산술급수적이 아니라) 발전하기 때문에 2029년 컴퓨터의 능력은 개별 인간을 뛰어넘고, 2045년엔 전 인류 지능의 총합마저 크게 앞질러 버린다고 그는 예측했다. 이 시점을 그는 '특이점(singularity)'이라고 부른다.

Peter Thiel도 기술적 특이점의 중요성을 매우 느끼고 연구를 위해 2006년 2월과 2007년 5월에 인공 지능 특이점 연구소에 50만 달러의 투자를 하고 있다. 또, NY과 스탠포드에서 개최된 Singularity Summit에 참가했었다.

- 그외 Singularity를 향한 움직임
  • 미국에서 차세대 리더를 육성하고 인류가 직면 한 큰 과제를 해결하는 것을 목표로하는 Singularity University가 개설 되었다. 창립자는 Ray Kurzweil 박사(저술가, 과학 기술자, 미래 학자), Peter Diamandis 박사(XPRIZE), Pete Worden(NASA Ames 연구소 소장), Robert L. Richards 박사(International Space University(ISU)의 창립자 중 한명), Robert D. Richards 박사(ISU의 학장) Michael Simpson 박사, 또한 Google이 스폰서로 지원하고 있다.

해상 국가



Google의 엔지니어였던 Patri Friedman이 2008년 해상 인공 국가 실현을 목표로 캘리포니아의 Seasteading Institute를 설립했는데 자유주의를 표방하는 Peter Thiel이 2011년까지 125만 달러를 투자했다고 한다. Seasteading Institute를 부연 설명하자면, 공해상에 석유 플랫폼과 같은 인공섬을 건설하고 독립 국가를 창설하는 것을 목표로하고 있다. 자세한 내용은 여기를 참조하기 바랍니다.

[첨조 사이트]
Tags : ,

Make에 대해 알아야할 7가지

Make 파일에 대해 그나마 괜찮은 블로그 포스트가 하나 있어 소개합니다. 제목은 "Make 대해 알아야 할 7 가지"인데, 이것만 보면 makefile을 만들거나 만든거에 대한 이해를 도와줄 수 있을 거 같습니다.

구체적인 내용은 아래와 같습니다.

Make는 다양한 유형의 파일들을 자동 빌드하는데 간단하면서도 강력한 도구이다. 그러나 makefile을 작성할 때 문제가 발생하는 프로그래머들도 있고, Make의 기본 지식이 없어 기존에 있는 것을 다시 만드느라 시간을 낭비하는 프로그래머들도 있다.

Make는 어떻게 동작하나?

기본적으로 Make는 첫번째 target에서 시작한다. 이 target을 디폴트 목표(goal)라고 한다.

Make는 현재 디렉토리의 makefile을 읽고 가장 먼저 룰(규칙) 처리를 시작한다. 그러나 Make가 완전히 이 룰(규칙)을 처리하기 전에 룰(규칙)이 종속 파일에 대한 룰을 먼저 처리해야 한다. 각 파일들은 자신의 룰에 따라 처리된다.

사실 이것은 각 target의 재귀 알고리즘으로 되어 있다.
  1. target을 빌드하는 룰(규칙)을 찾아낼 것이다. 만약 target을 빌드할 룰(규칙)이 없다면, Make는 실패한다.
  2. target의 전제 조건이 있는 경우 그 전제 조건과 함께 알고리즘이 실행된다.
  3. target이 존재하지 않거나 전제 조건의 갱신 시간이 target의 갱신 시간보다 이후인 경우 target과 관련된 레시피를 실행한다. 레시피가 실패한다면, (보통) Make도 실패한다.

할당 유형

Make는 makefile을 쓰는 것을 단순화하기 위해 변수가 지원된다. =, ?=, :=, ::=, +=, != 연산자 중 하나를 가지고 할당된다. 각 연산자의 차이점은 다음과 같다.
  • =는 지연된 값을 변수에 할당한다. 즉, 변수가 사용될 때마다 변수의 값이 요구된다는 의미이다. 쉘 명령의 결과를 대입할 때 - 변수가 읽혀질 때마다 쉘 명령이 실행된다는 것을 잊지 마시라.
  • :=::=는 기본적으로 같은 의미다. 이러한 대입은 변수값을 한 번만 처리하고 그 값을 저장한다. 단순하고 강력하다. 이런 유형의 할당은 디폴트로 선택되어야 한다.
  • ?= 는 변수가 정의되지 않은 경우에만 := 역할을 한다. 그렇지 않은 경우는 아무것도 하지 않는다.
  • +=는 더하기 대입 연산자이다. 변수가 미리 := 또는 ::=에 설정되어 있는 경우, 우변은 즉시 값으로 간주된다. 그렇지 않으면 지연된 값으로 간주된다.
  • !=는 쉘 대입 연산자다. 우변은 즉시 평가되고 쉘에 전달된다. 결과는 좌변의 변수에 저장된다.

패턴 룰

동일한 룰(규칙)을 가진 파일을 많이 가지고 있는 경우 모든 target을 일치시키기 위해 패턴 규칙을 쉡게 정의할 수 있다. 패턴 규칙은 target에 '%'가 있는 것을 제외하고는 보통의 룰(규칙)과 비슷하다. 패턴 룰의 타겟은 파일 이름과 일치하는 패턴이라고 판단되며 '%'는 공백이 아닌 부분 문자열에 일치시킬 수 있다.

내 블로그 디렉토리에는 다음과 같은 Makefile을 만들 수 있다.
all: \
    build/random-advice.html \
    build/proactor.html \
    build/awesome_skype_fix.html \
    build/ide.html \
    build/vm.html \
    build/make.html \

build/%.html: %.md
    Markdown.pl $^ > $@
$@가 target을 의미하는 반면, $^ 의존 관계를 의미하는 자동 변수다. 그래서 이 룰은 단순히 마크다운 파일 변환기에 전달하는 룰이다. 패턴 룰의 작성과 자동 변수에 대한 자세한 내용은 설명서를 참조 하라.

디폴트 묵시적 룰

GNU Make에는 기본 룰(규칙)이 있다. 많은 경우 명시적 룰을 사용할 필요는 없다. 디폴트 묵시적 룰 목록은 C, C++, 어셈블러 프로그램의 컴파일 룰과 그들을 링킹(연결)하는 것을 포함하되 제한은 없다. 전체 목록은 Make 설명서에서 볼 수 있다.

Makefile에 아무것도 하지 않는 것도 가능하다. 예를 들어, 단순히 hello.c라는 파일에 프로그램 소스 코드를 저장하고 단순히 make hello를 실행할 수도 있다. Make는 hello.c에서 hello.o를 자동으로 컴파일하고 hello에 링킹(연결)한다.

레시피는 $(CC) $(CPPFLAGS) $(CFLAGS) -c 형식으로 정의한다. 변수를 변경하여 룰을 바꿀 수 있다. 소스 파일을 clang으로 컴파일하기 위해서는 단순히 CC := clang 라인을 추가해주면 된다. 나는 작은 테스트 프로그램을 저장할 디렉토리에 아주 작은 Makefile을 가지고 있다.
CFLAGS := -Wall -Wextra -pedantic -std=c11
CXXFLAGS := -Wall -Wextra -pedantic -std=c++11

와일드 카드와 함수

현재 디렉토리의 모든 C와 C++ 소스 파일을 컴파일하려면 종속성을 위해 다음의 코드를 사용하자.

$(patsubst %.cpp,%.o,$(wildcard *.cpp)) $(patsubst %.c,%.o,$(wildcard *.c))
wildcard는 패턴과 일치하는 모든 파일을 검색하고, patsubst는 적절한 파일 확장자를 .o로 대체한다.

Make는 텍스트를 변환하기 위한 많은 기능이 있으며, $(function arguments) 형식으로 호출한다.

함수의 전체 목록은 설명서를 참조하시라.

쉼표 뒤의 공백은 인수의 일부로 간주되는 점에 주의하자. 공간이 있으면 몇몇 함수에서 예기치 않은 결과가 발생할 수 있기 때문에 나는 쉼표 뒤에 공간을 전혀 두지 않는 것을 추천한다.

call 함수와 사용자 정의 함수, 그리고 eval 함수에서 매개 변수화된 템플릿과 같은 것을 쓸 수도 있다.

검색 경로

Make는 특별한 변수 VPATH가 모든 필요 조건을 위한 PATH처럼 사용된다. 또한 VPATH 변수는 디렉토리 이름을 콜론이나 공백으로 구분한다. 디렉토리의 순서는 Make가 검색하는 순서이다. 이 룰은 모든 파일이 현재 디렉토리에 존재하는 것처럼, 필요 조건 목록에서 파일 이름을 지정할 수 있도록 한다.

또한 세밀한 vpath 지시어도 있다. 이것은 패턴과 일치하는 파일에 대해 검색 경로를 지정할 수 있다. 따라서 include 디렉토리에 모든 헤더를 저장한다면, 다음 행처럼 사용할 수 있다.
vpath %.h include

그러나, Make는 룰의 필요 조건 부분만 바꾸지, 룰 자체를 바꾸지 않기 때문에 룰에서 명시적인 파일 이름에 의존하지 않는다. 대신 $^ 같은 자동 변수를 사용해야 한다.

필요요건에 대한 디렉토리 검색에 대한 자세한 내용은 Make 설명서를 참조하세요.

makefile의 디버깅

makefile을 디버깅하기 위한 몇 가지 방법이 있다.

Printing
첫번째는 단순히 옛날 방식의 출력 방법이다. 다음 Make 함수중 하나를 사용하여 그 표현식의 값을 출력할 수 있다.
$(info ...) $(warning ...) $(error ...)

이 라인을 통과하면 Make는 그 표현식의 값을 뿌려준다.
출력에 의한 추적 방법은 이미 알고 있을 것이다.

Remake
Makefile을 디버깅하기 위해 쓰여진 특별한 프로그램도 있다. Remake는 지정된 target에서 멈춰 일어난 것들을 확인하고 Make의 내부 상태를 바꿀 수 있다. 좀 더 자세한 내용은 Remake와 함께 makefile 디버깅에 대한 기사"를 읽어 보기 바랍니다.

makefile의 디버깅에 대한 또다른 방법을 위해서라면 makefile 디버깅에 관한 좋은 기사"도 읽어보자.
Tags : , ,

조직력의 발전방향은?

우리는 회의에서 논의를 통해 의견을 나눌수록 극단을 지양하고 합리적 중용의 결과를 찾으려는 것이 목표일 것이다. 하지만, 특히 한국에서 회의 구성원들의 지위가, 유명세가 발언의 양, 방향을 암묵적으로 지휘하는 경우가 많다.

지위에 의해 의식이 서열화 되고 발언양이 많아짐으로 논의의 목적이 합리적인 중용을 표방하는데, 이를 무시하고 지위자의 발언 방향으로 귀결되는 경우가 많다. 이는 결국 회의 주도자의 생각과 열정을 뭉개버리고 무념의 팔로워로 전락하게 만들 수 있다.

그리고 유명세가 있는 사람의 발언은 논점이 아닌 전반적인 부분에서 그 사람의 지식을 근거없이 과대 평가를 해버려 그에게 근거없는 자신감을 불어 넣어줘 버리고, 중도보다는 확신과 고집으로 인해 역시 잘못된 논의를 만들어 버리는 경우도 있다.

  • 그렇다면 비전문가, 평직원들의 생각 속에서 더 좋은 아이디어나 논리적인 사고가 발현할 확률은 어떻게 되는 것일까?
  • 집단지성을 성과로 이어지기엔 시간이 허락하지 않는게 현실인데, 그럼 대안은?
  • 맨투맨 의사소통은 언제까지 해야할까?
  • 그럼 다양성, 자율성은 어디까지 보장해 주어야 하는 것일까?

Angularjs 1.2에서 1.3 업그레이드

본 포스트는 Angularjs 1.2에서 1.3으로 업그레이드를 하실분들에게 도움을 주고자 Migrating from 1.2 to 1.3" 문서를 정리한 것입니다. 아직 1.3에 추가적인 버그가 나와서 패치가 되고 있지만 성능부분이 더 좋아졌다고 하니 1.3이 안정화되면 업그레이드 하시길 권고해 드립니다. ^^

1.3 특징

1. 성능
- DOM 조작이나 digest 등 많은 처리에서 3 ~ 4배 빨라졌다.

2. 주목할 기능
- One-time bindings - 표현식 앞에 "::"를 붙여서 interpolate(값할당)가 한번 일어나며, 그 이후에는 감시(watch)되지 않는다.
- ngAria - 기본적으로 (접근성 관련) 액세스 가능한 사용자 지정 구성 요소를 구현하기 위한 새로운 모듈.
- ngMessages - 폼 검증에 대한 피드백(결과)을 쉽게 표시하기 위한 메세지 지시자.
- ngModelOptions - 바인딩된 모델(model binding)의 동작을 사용자 정의가 가능한 지시자. 예로는 아래와 같다.
  • debounce는 모델 업데이트 타이밍 제어가 가능.
  • getter-setter 형식의 모델 바인딩 가능.
  • update-on-blur는 blur시 모델 업데이트.
- Strict DI - 단순화한 DI 구문을 사용해 minify할 수 없는 코드를 찾을 수 있는 옵션(Implicit injection 문법 사용시 오류를 발생시킴).
- Material Design 지원.

마이그레이션 가이드

1. $parse
- prevent invocation of Function's bind, call and apply
angular 표현식에서는 function의 .bind .call .apply를 호출할 수 없게 된다. 기존 function의 행동을 예측할 수 없는 형태로 변경되지 않게 하기 위해서이다.

- forbid __proto__ properties in angular expressions
angular 표현식에서는 proto 속성이 동작하지 않는다.

- forbid __{define,lookup}{Getter,Setter}__ properties
angular 표현식에서는 {define, lookup} {Getter, Setter}를 사용할 수 없다. 만약에 몇몇 사유에 의해 필요한 경우, 위험 요소를 즐이기 위해 wrap/bind를 scope 객체를 통해 사용해라.

- forbid referencing Object in angular expressions
angular 표현식에서는 Object를 사용할 수 없다. Object.keys가 필요한 경우는 scope를 통해 접근할 수 있게 해라.

2. Angular.copy
- preserve prototype chain when copying objects
원본 Object의 prototype을 카피 Object에 적용하기 위해 angular.copy가 변경되었다. 이전에는 원본 Object의 프로토타입 체인 속성을 직접 복사했다.
카피된 객체의 hasOwnProperty 속성만 iterate하면 prototype의 속성은 포함되지 않는다. 이것은 좀 더 합리적인 행동이라고 생각하고 실제 어플리케이션이 행동에 의존하는 경우는 드물다.
만약, 애플리케이션이 행동에 의존하는 경우는 객체(상속 속성 포함)의 모든 속성을 hasOwnProperty로 필터링하지 않도록 iterate하라.
이 변경 사항은 IE8에서 동작하지 않는 기능을 사용할 수도 있다는 것에 주의하라. 만약 IE8에서 동작시키고 싶은 경우는 Object.create와 Object.getPrototypeOf의 polyfill을 사용해라.

3. core
- drop the toBoolean function 'f', '0', 'false', 'no', 'n', '[]'는 더이상 falsy로 간주되지 않고, JavaScript의 falsy값인 false, null, undefined, NaN, 0, ""만 parser에 의해 falsy로 처리된다.

4. $compile
- always error if two directives add isolate-scope and n…
하나의 요소에 isolate scope와 다른 scope를 요청하면 오류가 발생된다. 변경 전에는 isolate가 아닌 scope의 directive 다음에 isolate scope의 directive 순으로 컴파일러가 적용할 경우에는 두개의 directive가 child scope와 isolate scope를 요청하는 것이 가능했다. 지금은 순서에 관계없이 컴파일러 오류를 발생시킨다.
만약 당신의 코드가 지금 $compile:multidir 오류를 던진다면 같은 Element에 여러 directive가 isolate와 isolate 아닌 scope를 요청하지 않았는지 체크하고 코드를 고쳐라.

5. NgModel
- ensure pattern and ngPattern use the same validator
ng-pattern(ng-pattern="exp") 또는 pattern 속성(pattern="{{exp}}")을 angular 표현식으로 사용하고 있다면, 그리고 표현식이 문자열로 평가되는 경우, validator는 정규 표현식 객체 리터럴(/abc/i)로 문자열을 분석하지 않고 전체 문자열을 정규 표현식으로 되어 버린다. 즉, 이 의미는 플래그가 RegExp 객체로 처리되지 않는다. 이 문제를 해결하기 위해 정규식 객체를 angular 표현식의 값으로 사용해라.
//before
$scope.exp = '/abc/i';

//after
$scope.exp = /abc/i;

6. Scope
-
change Scope#id to be a simple number
Scope#$id는 문자열이 아니라 숫자로 되어 있다. 이 id는 주로 디버깅 목적으로 이용되고 있어서, 다른 곳에는 영향을 주지 않을 거라고 생각하고 있다.

7. forEach
- cache array length
forEach는 배열의 초기의 아이템 수만 iterate할 수 있고, iteration 도중에 배열에 추가된 항목은 forEach의 대상이 되지 않는다.
이 변경으로 인해 forEach가 Array#forEach와 동작이 비슷하게 되었다.

8. jqLit​​e
- data should store data only on Element and Document nodes
text/comment 노드에 jqLit​​e의 데이터를 넣을 수 있었는데, jQuery처럼 Element와 Document 노드에만 가능하게 되었다.

9. $resource
- allow props beginning with $ to be used on resources
$resource가 속성을 삭제하는 행동을 기대하는 경우 수동으로 직접 수행해야 한다.

10. angular.toJson
- only strip properties beginning with $$, not $
toJson이 속성을 삭제하는 행동을 기대하면 수동으로 직접 수행해야 한다.


11. $compile
- deprecate `replace` directives
Element를 replace하는 directive를 정의하기 위한 replace 플래그는 다음 Angular의 주요 버전에서는 삭제된다. 이 기능은 성가신 문제(속성을 어떻게 병합하는지 등)가 있으며,이 기능을 해결하는 것보다 더 많은 문제를 야기하고 있다. 또한, Web Components는 DOM에 사용자 지정 요소가 존재하는 것이 일반화되었다.

12. $parse
- remove deprecated promise unwrapping
promise unwrapping 기능은 제거되었다. 이것은 1.2.0-rc.3에서 이미 depreciated되어 있다. 아래 두 함수는 제거 되었다.
  • $parseProvider.unwrapPromises
  • $parseProvider.logPromiseWarnings

13. Scope
- $broadcast and $emit should set event.currentScope to null
$broadcast와 $emit 이벤트의 전파(propagation)를 종료한 시점에서 이벤트 currentScope 속성을 null로 재설정하게 된다. currentScope 속성에 비동기적으로 액세스하는 코드는 targetScope를 사용하도록 마이그레이션 하라.

14. jqLit​​e
- stop patching individual jQuery methods
jQuery의 detach() 메서드는 $destroy 이벤트를 트리거하지 않는다. Element에 붙인 Angular 데이터를 삭제하려면 remove()를 사용하라.

15. $http
- remove deprecated responseInterceptors functionality
지금까지는 response interceptor를 다음과 같이 등록할 수 있었다.
// register the interceptor as a service
$provide.factory('myHttpInterceptor', function($q, dependency1, 
  dependency2) {
  return function(promise) {
    return promise.then(function(response) {
      // do something on success
      return response;
    }, function(response) {
      // do something on error
      if (canRecover(response)) {
        return responseOrNewPromise
      }
      return $q.reject(response);
    });
  }
});

$httpProvider.responseInterceptors.push('myHttpInterceptor');

v1.1.4(4ae46814)에서 도입된 API는 다음과 같다.
$provide.factory('myHttpInterceptor', function($q) {
return {
  response: function(response) {
    // do something on success
    return response;
  },
  responseError: function(response) {
    // do something on error
    if (canRecover(response)) {
      return responseOrNewPromise
    }
    return $q.reject(response);
  }
};
});

$httpProvider.interceptors.push('myHttpInterceptor');

이 API의 자세한 내용은 interceptors에서 확인할 수 있다.

16. injector
- invoke config blocks for module after all providers
이전에는 config 블록이 provider 등록 전에 불려졌기 때문에 동작을 제어하기가 가능했지만, 지금은 항상 config 앞에 provider를 등록되게 되어져 있어서 동작을 제어 할 수 없게 되었다.

예:
이전에는 다음과 같은 코드가 작동하고 있었다.
angular.module('foo', [])
.provider('$rootProvider', function() {
  this.$get = function() { ... }
})
.config(function($rootProvider) {
  $rootProvider.dependentMode = "B";
})
.provider('$dependentProvider', function($rootProvider) {
   if ($rootProvider.dependentMode === "A") {
     this.$get = function() {
      // Special mode!
     }
   } else {
     this.$get = function() {
       // something else
     }
  }
});

$rootProvider와 $dependentProvider 등록 사이에 config 블록이 있어서 응용 프로그램의 동작을 변경할 수 있었지만, 이제는 이러한 방법이 싱글모듈 내에 있어서 더이상 실현될 수 없다.

17. ngModelOptions
- move debounce and updateOn logic into NgMod…
이 커밋은 NgModelController의 API를 변경하고 있다.

$setViewValue(value) - 이 메소드는 $viewValue를 변경하지만, 이전처럼 $modelValue가 변경되면 즉시 커밋하지 않는다. 지금은 관련된 ngModelOptions directive에서 지정된 트리거의 발생에 의해 커밋되도록 되었다. ngModelOptions에 debounce 지연이라는 트리거가 지정되어 있는 경우에는 변경의 커밋은 더 연기(debounce)된다. 대부분의 경우 NgModelController 사용 방법에 큰 영량을 미치지는 않는다. updateOn이 디폴트로 포함되어 있어 $setViewValue는 트리거에 의해 즉시 커밋될(잠재적 연기 가능) 것이다. $cancelUpdate() - $rollbackViewValue()로 이름이 ​​변경되었다. 그리고 현재의 $viewValue 값이 복귀하기 위해서는 $lastCommittedViewValue값으로 뒤로 가야한다. 그럴려면 보류중인 debounce 업데이트와 input을 다시 render하는 작업을 취소한다.

$cancelUpdate()를 사용하는 코드는 다음 예제처럼 마이그레이션 하라.

전 :
$scope.resetWithCancel = function (e) {
	if (e.keyCode == 27) {
	  $scope.myForm.myInput1.$cancelUpdate();
	  $scope.myValue = '';
	}
};

후 :
$scope.resetWithCancel = function (e) {
	if (e.keyCode == 27) {
	  $scope.myForm.myInput1.$rollbackViewValue();
	  $scope.myValue = '';
	}
}

18. $interpolate
- split .parts into .expressions and .separators
$interpolate에 의해 반환되는 function은 .parts 배열을 가질수 없다. 대신, 두개의 배열을 갖게 된다.
  • .expressions - interpolate된 텍스트의 expression 배열. expressions은 $parse로 분석되며, 계산되어질 때 문자열로 변환된다.
  • .separators - 텍스트에서 interpolation 사이를 구분하는 문자열의 배열로,이 배열은 병합하기 쉽게하기 위해 항상 .expressions 배열보다 1 아이템 길다.

19. $animate
- insert elements at the start of the parent container instead of at the end
$animate 부모 컨테이너의 마지막 요소로하는 after 매개 변수를 더이상 디폴트가 아니다. 대신 after가 지정되어 있지 않은 경우에는 새로운 요소를 부모 컨테이너의 첫 번째 자식으로 삽입 할 수 있다.
기존 코드를 업데이트하기 위해서는 $animate.enter() 또는 $animate.move()의 모든 인스턴스를
$animate.enter(element, parent);

에서
$animate.enter(element, parent, angular.element(parent[0].lastChild));

로 변경하여야 한다.

- make CSS blocking optional for class-based animations
전이(transitions)를 사용하거나, 설치 CSS class(class-add와 class-remove 등) 기반의 애니메이션 코드는 스타일이 즉시 적용되는 것을 보장하려면 빈 transition 값을 주어야 한다. 다른말로는, 애니메이션의 코드가 설치 class에서 정의된 스타일을 적용하고, CSS class에서 "transition:0s none" 값이 존재하지 않는 한 즉시 적용되지 않는다. 이 상황은 전이(transitions)는 애니메이션이 한번 시작된 후 베이스 CSS 클래스에 존재하는 경우에만 해당된다.

전 :
.animated.my-class-add {
	opacity:0;
	transition:0.5s linear all;
}
.animated.my-class-add.my-class-add-active {
	opacity:1;
}

후 :
.animated.my-class-add {
	transition:0s linear all;
	opacity:0;
}
.animated.my-class-add.my-class-add-active {
	transition:0.5s linear all;
	opacity:1;
}

자세한 내용은 ngAnimate 문서를 봐주세요.

20. $compile
- add support for $observer deregistration
attr$observe 호출할 경우 더이상 observer function을 리턴해주지 않고, 대신 등록 해제(deregistration) function을 리턴해 준다. 다음의 예에 따라 코드를 마이그레이션하세요.

전 :
directive('directiveName', function() {
return {
  link: function(scope, elm, attr) {
    var observer = attr.$observe('someAttr', function(value) {
      console.log(value);
    });
  }
};
});

후 :
directive('directiveName', function() {
return {
  link: function(scope, elm, attr) {
    var observer = function(value) {
      console.log(value);
    };

    attr.$observe('someAttr', observer);
  }
};
});

21. $httpBackend
- don't error when JSONP callback called with no parameter
에러와 empty 응답에 대한 JSONP의 동작이 변경되었다. 이전에는, JSONP 응답이 비어 있는 경우에는 에러로 간주되었지만 지금은 에러를 발견하기 위한 이벤트를 올바르게 수신할 수 있게 되었다. 이젠 empty 응답도 성공적으로 수신할 수 있다.

22. build
- remove IE8 target from all test configs
IE8은 더이상 지원되지 않는다.

23. input
- support types date, time, datetime-local, month, week
date, time, datetime-local, month, week의 Type은 항상 Date 객체가 필수이다.

용어

  • interpolation : {{}} 값을 채움.
  • debounce : 지정한 값만큼 지난 후 바인딩된 모델값의 변경.

박사란?

그림으로 보는 박사 이야기"인데, 곰곰히 보면 우리에게 주는 교훈은 큰거 같습니다. 가끔 보면서 자신의 위치를 살펴보는 것도 괜찮을 것 같네요.

인류의 모든 지식을 담았다고 생각하는 원을 상상해 보자.



초등학교를 졸업하면 약간의 지식을 얻는다.



고등학교를 졸업할 무렵에는 조금 더 지식을 습득한다.


대학의 학사 학위를 취득하면 전공 분야에서 전문성을 얻을 수 있게 되고



대학원 석사 학위를 취득하면 전문성이 더 깊어진다.



다양한 연구 논문을 읽는다면, 인류 지식의 가장 자리에 다다를 수 있고



가장 자리에 있게 되면 그 부분에 집중하게 된다.



몇 년 동안, 그 경계에서 계속 파게 되고



어느 날, 인류 지식의 경계를 넘어서게 되고



이 홈 부분을 박사라고 부른다.



물론 당시에는 세계가 달라 보인다.



하지만, 큰 그림(전체)을 잊지 마라.



그래서 계속 노력해야 한다.
Tags :

리팩토링이나 코드 리뷰에 사용할 체크리스트


리팩토링이나 코드 리뷰에 사용할 체크리스트로 사용해도 좋을법한 약어들을 공개합니다. 아직 부족하지만 같이 채워나가요. ^^
  • DC(Duplicate Code) - 중복된 코드(중복된 코드나 조건들).
  • BPC(Bad Performance Code) - 성능에 좋지 않는 코드.
  • BN(Bad Name) - 변수나 클래스, 함수 등에 너무 길거나 가독성 떨어지고 일관되지 않은 이름.
  • VS(Violates Specifications) - 가이드나 지침을 따르지 않음.
  • TCL(Too Complicated/Larged) - 불필요하거나 너무 크고 복잡한 함수나 클래스.
  • LP(Long Parameter) - 불필요하거나 너무 긴 인자값들.
  • II(Inconsistent Indentation) - 비일관적인 들여쓰기.
  • NEC(Not Enough Test Cases) - 테스트 케이스가 너무 적음.
  • TMIS(Too Much If/Switch) - 조건 분기가 많음.
  • NC(No Comments) - 주석이 너무 없음.
  • SS(Shotgun Surgery) - 하나의 함수나 클래스를 변경했는데 많은 것들이 영향을 받는다.
  • FE(Feature Envy) - 다른 클래스의 속성과 메소드들을 사용해 다른 클래스와 강한 관계가 성립한다. 모듈(클래스) 독립적이지 못하다.
  • BC(Boilerplate Code) - Getter/Setter 등 맹복적으로 추가되는 반복적인 코드들.
  • TE(Throws Exception) - 예외 처리.
  • NG(Not General) - 너무 범용적이지 않음.
  • DD(Dead Code) - 사용되지 않거나 미리 만들어진, 불필요한 코드들.
  • MN(Magic Number) - 매직 넘버.
  • PD(Platform Dependency) - 플랫폼(언어, 환경 등) 종속성이 있다.
  • AOS(Abuse Open Source) - 오픈 소스 남용.
추가적으로 생각나는 것은 지속적으로 업데이트 하겠습니다. 그리고 여기에 추가할 좋은 약어들이 있으면 코멘트(댓글)나 이메일 남겨주시면 고맙겠습니다. ^^

위임에 관한 70%룰

완벽한 일 마무리와 과로 사이의 균형을 판별하는 공식이 있다네요. 그것이 바로 70%룰이랍니다.

보통 일을 제대로 끝낼려면 다른 사람에게 일을 맡기기보다 자신 스스로가 해야 한다고 생각하는 사람이 많을겁니다. 하지만, 70%룰을 통해 자신의 일을 다른 사람이 해서 70% 정도의 품질만 보장되면 그 사람에게 맡기는 것이 중요하다고 하네요.

모든 일을 혼자 다 할 순 없는 법이니깐요.
CEO가 하는 일을 적어도 자신이 했을때와 비교했을 때 70% 정도의 퀄리티로 할 수있는 사람이 있다면 그 사람에게 일을 맡겨라. 일이 같은 수준의 완성도가 되지 않는다면 좌절하나요? 하지만, 완벽함을 잊으라. 말처럼 쉬운 것은 아니다. 하지만, 맡기는 경우라면 완벽을 요구하는 것은 금물이다. CEO는 작업에 모든 시간을 할애할 필요는 없다. 일에 무한정 시간을 투입할 순 없다. 제때 결과물을 내는 것이 중요하고 거기에 더해 더 영향력이 높은 프로젝트에 투자하는 것이 필요하다.

일을 위임시에 중요한 것은 달성할 목표를 명확히 하고, 그것을 달성하기 위해 무엇이 필요한지를 알고 그것을 팀 구성원에게 전달하는 것이다. 위임에서 가장 어려운 부분은 일을 믿고 기다리는 것이다. 팀의 멤버가 일을 잘 해나갈 것이다라고 믿는 것이다. 위임에서 또 중요한 것은 당신의 팀 구성원이 당신과는 전혀 다른 방법으로 목표를 달성하려고 하는 것을 이해하는 것이다. 그리고 완벽함을 잊기 위해서 무엇을 우선해야 할 것인가를 결정해야 한다. 그 결정할 일은 "완벽함"을 추구 방법이나, 다른 방법도 충분히 결과를 낼 수 있다는 것이다. 팀에 재량권을 주면 과제를 수행하는데 더 새롭고, 좋은 방법을 발견하는 등 더 놀라는 일을 발견하게 될 것이다.
일을 제대로 위임하고 그것을 허용하는 자신의 마음이 중요할거 같네요.

[참조 사이트]
Tags :