"use strict" in Javascript

The "use strict"; line instructs the browser to apply a strict interpretation of the JavaScript rules which, by making us write cleaner code, allows us to avoid confusing bugs.

JSLint

The Principle of the Good Parts is

If a feature is sometimes useful and sometimes dangerous and if there is a better option then always use the better option.

JSLint is a JavaScript program that looks for problems in JavaScript programs. It is a code quality tool.
When C was a young programming language, there were several common programming errors that were not caught by the primitive compilers, so an accessory program called lint was developed that would scan a source file, looking for problems.
As the language matured, the definition of the language was strengthened to eliminate some insecurities, and compilers got better at issuing warnings. lint is no longer needed.
JavaScript is a young-for-its-age language. It was originally intended to do small tasks in webpages, tasks for which Java was too heavy and clumsy. But JavaScript is a surprisingly capable language, and it is now being used in larger projects. Many of the features that were intended to make the language easy to use are troublesome when projects become complicated. A lint for JavaScript is needed: JSLint, a JavaScript syntax checker and validator.
JSLint takes a JavaScript source and scans it. If it finds a problem, it returns a message describing the problem and an approximate location within the source. The problem is not necessarily a syntax error, although it often is. JSLint looks at some style conventions as well as structural problems. It does not prove that your program is correct. It just provides another set of eyes to help spot problems.
JSLint defines a professional subset of JavaScript, a stricter language than that defined by the ECMAScript Programming Language Standard (the strangely named document that governs JavaScript). JSLint will reject most legal programs. It is a higher standard.
JavaScript is a sloppy language, but hidden deep inside there is an elegant, better language. JSLint helps you to program in that better language and to avoid most of the slop. JSLint will reject programs that browsers will accept because JSLint is concerned with the quality of your code and browsers are not. You should gladly accept all of JSLint's advice.
JSLint can operate on JavaScript source or JSON text.

What is D3 ?

 D3 is a JavaScript library written by Mike Bostock, created as a successor to an earlier visualization toolkit called Protovis. The D3 library allows us to manipulate elements of a web page in the context of a data set. These elements can be HTML, SVG, or Canvas elements, and can be introduced, removed, or edited according to the contents of the data set. 
 So, for example, to create a scatter graph, we use D3 to arrange SVG circle elements such that their cx and cy attributes are set to the x- and y-values of the elements in a data set, scaled to map from their natural units into pixels.
 A huge benefit of how D3 exposes the designer directly to the web page is that the existing technology in the browser can be leveraged without having to create a whole new plotting language. This appears both when selecting elements, which is performed using CSS selectors (users of JQuery will find many of the idioms underlying D3 very familiar), and when styling elements, which is performed using normal CSS. This allows the designer to use the existing tools that have been developed for web design—most notably Firefox’s Firebug and Chrome’s Developer Tools.
 Instead of creating a traditional visualization toolkit, which typically places a heavy wrapper between the designer and the web page, D3 is focused on providing helper functions to deal with mundane tasks, such as creating axes and axis ticks, or advanced tasks such as laying out graph visualizations or chord diagrams. This means that, once over D3’s initial learning curve, the designer is opened up to a very rich world of modern, interactive and animated data visualization. 
                                                                                 -  From Getting Started With D3

Napoleon’s March flow map

Minard’s flow map depicting Napoleon’s dwindling army as he marches toward, and retreats from, Moscow. “Drawn up by M. Minard, Inspector General of Bridges and Roads in retirement. Paris, November 20, 1869.

컴퓨터 프로그래밍에 대한 명언 101가지

※ 원문 : 101 Great Computer Programming Quotes(DevTopic)
 
“사람들은 항상 변화를 두려워한다. 처음에 전기를 발명했을 때 사람들은 두려워했다. 그리고 석탄을 두려워했고 휘발류 엔진을 두려워 했다. 사람들은 자신들이 모르는 것에 대해서 두려움을 느낀다. 그래서 시간이 흐르고 나면 첨단 반도체 기기들도 받아들이게 될 것이다.”

빌게이츠가 이 말을 한 후 컴퓨터는 실제로 우리 삶 어디에서나 쉽게 볼 수 있는 최첨단 반도체 기기가 되었다. 결국 많은 훌륭한 사람들이 사람의 관점에서 컴퓨터와 소프트웨어의 중요성을 되짚어 보아왔다. 그래서 우리는 컴퓨터, 특히 프로그래밍을 강조한 101개의 명언을 모아보았다.

Computers

1. 컴퓨터는 쓸모가 없다. 그것은 그냥 대답만 할 수 있다. (Pablo Picasso, 피카소는 92세까지 살았는데 65세에 ENIAC이 등장했다.)
2. 컴퓨터는 비키니와 같다. 사람들의 무성한 추측을 만들어낸다.(Sam Ewing, 작가)
3. 컴퓨터를 갖게 되자 새로운 대량 살상무기가 만들어졌다.(Janet Reno, 미국 공무원)
4. 컴퓨터와 함께 일하는 것은 멋지다. 그것은 당신과 싸우지도 않고 모든 것을 기억해주고 내 맥주를 뺏어 마시지도 않는다.(Paul Leary)
5. 만일 자동차가 컴퓨터와 같은 개발 주기를 따른다면 롤스로이스는 처음에는 약 100달러 정도 할 것이고, 연비는 갤런당 백만마일 정도가 될 것이다. 하지만 일년에 한 번씩 폭발해 버려서 안에 탄 사람들을 모두 죽여버릴 것이다.(Robert X. Cringely, 테크 저널리스트)

Computer Intelligence

1. 컴퓨터는 점점 더 똑똑해지고 있다. 과학자들은 곧 그들이 우리에게 말을 걸 것이라고 말한다. 여기에서 그들이란 컴퓨터를 말한다. 과학자가 우리에게 말할 리는 없으니까. (Dave Barry, 컴퓨터광 유머작가)
2. 나는 최근에 컴퓨터가 똑똑해져서 전 세계를 지배할 것이라는 공포가 거의 모든 문화권에서 거의 사라졌다는 것을 알게 되었다. 그리고 이것은 정확히 MS-DOS의 배포 시점과 일치했다. (Larry DeLuca)
3. ‘컴퓨터가 생각할 수 있을까?’라고 묻는 것은 ‘잠수함이 물 속을 다닐 수 있을까?’라고 묻는 것과 같다. (Edsger W. Dijkstra, 구조적 프로그래밍, 세마포어 등으로 유명한 컴퓨터 과학자)
4. 100년을 살면서 단지 300 MB 밖에 기억 못하는 것은 너무 가혹하다. CD 한 장보다 못하지 않나? 인간의 조건은 정말 점점 더 초라해지고 있다. (Marvin Minsky, AI로 유명한 컴퓨터 과학자)

Trust

1. 중앙컴퓨터가 말했나, 알투디투? 낯선 컴퓨터는 믿지 않는게 좋아. (C3PO, 스타워즈)
2. 창 밖으로 집어던질 수 없는 컴퓨터는 절대 믿지 마라. (Steve Wozniak, 애플 창업자)

Hardware

1. 하드웨어 : 사람이 발로 걷어찰 수 있는 컴퓨터의 부분(Jeff Pesis, 프로그래머)

Software

앨런 케이, 1945~, 객체지향 프로그래밍의 창시자
1. 오늘날의 모든 소프트웨어는 구조적인 완결성 없이 폭력과 수천 만의 노예들로 벽돌을 한 장 한 장씩 올려 만든 피라미드와 같다. (Alan Kay, 객체지향 프로그래밍의 아버지)
2. 나는 드디어 상위호환성upward compatible이 무엇인지를 알아냈다. 그것은 우리가 오래된 모든 실수를 다 떠안아야 한다는 의미이다. (Dennie van Tassel, 컴퓨터 과학자, ‘프로그래밍 언어의 역사’를 저술했다.)

Operating Systems

1. 버클리에서 나온 두 개의 제품이 있다. 바로 LSD(환각제)와 UNIX 다. 우리는 이것이 우연의 일치라고 믿을 수 없다.(Jeremy S. Anderson, 프로그래머)
2. 2038년 1월 19일 오전 3시 14분 07초, – Unix 세상의 끝 (1970년 1월 1일 이후 2의 32승이 되는 때이기 때문에)
3. 밖에 있는 모든  운영 시스템이 거의 똑같다. 우리 모두 망했다. (2003년 MS의 부사장인 브라이언 발렌타인이 OS를 보안 관점에서 이야기하며)
4. MS가 Windows XP를 내어 놓자 모든 사람들은 ‘이제까지 가장 신뢰성이 높은 윈도우’라고 극찬을 했다. 그러나 나에게는 ‘아스파라거스가 이제까지 가장 확실한 채소 ‘라고 말하는 것과 같았다. (Dave Barry, 컴퓨터광 유머 작가)

Internet

1. 인터넷? 그게 아직도 있어? (Homer Simpson, 만화캐릭터)
2. (19금) “The Web is like a dominatrix.  Everywhere I turn, I see little buttons ordering me to Submit.”  (Nytwind)
3. 이미 수백 만 개의 타자기 앞에 수백 만 원숭이들이 앉아있지만 유즈넷에는  세익스피어가 없다.(Blair Houghton)

Software Industry

1. 컴퓨터 소프트웨어 산업이 이룩한 가장 놀랄만한 성과는 하드웨어 산업이 만들어 놓고 있는 꾸준하고도 놀랄만한 성과들을 착실하게 깍아 먹고 있다는 것이다.(Henry Petroski, 실패 분석으로 유명한 엔지니어)
2. 진정한 혁신이란 시장을 시작하기에는 충분히 가볍지만, 그것을 소유할 힘이 없는 작은 스타트업으로부터 발생된다. “True innovation often comes from the small startup who is lean enough to launch a market but lacks the heft to own it.” (Timm Martin, 게임 개발자)

Alan Cooper, 1952~, VB의 아버지, Ruby의 전신’ 트라이포드’ 개발, IT에 페르소나 최초 도입
3. 위대한 과학은 거인의 어깨 위에 거인이 올라선 경우처럼 어렵게 비유 되곤 한다. 그러나 소프트웨어 산업은 난쟁이 발가락 위에 서 있는 난쟁이처럼 매우 쉬운 것처럼 이야기 된다.(Alan Cooper, 비쥬얼 베이직의 아버지, 제발 안 쉬운 걸 쉽다고 이야기하지 마세요.)
4. 이것은 비트나 바이트, 프로토콜에 대한 것이 아니다. 이익과 손실, 그리고 마진에 대한 것이다. (Lou Gerstner, 맥킨지 CEO)
5. 우리는 마이크로소프트다. 저항은 소용없다. 당신은 결국 우리와 동화될 것이다. (Bumper sticker, 자동차 범퍼)

Software Demos

1. 데모가 아무리 매끄럽다고 하더라도 완벽한 프리젠테이션을 할 확률은 지켜보는 사람의 숫자에 반비례 하며 투입되는 돈에 정비례 한다.(Mark Gibbs, 저널리스트)

Software Patents(특허)

1. 모든 특허는 헛소리다. 그것을 읽느라 시간을 낭비할 필요가 없다. 왜냐하면 특허란 소유권자가 그렇게 할거냐 아니냐에 좌우되기 때문이다.(Linus Torvalds, 리눅스 창시자)

Complexity(복잡성)

1. 복잡성을 통제하는 것이 컴퓨터 프로그래밍의 기초다.(Brian Kernigan, 컴퓨터 과학자, 최초로 C언어 프로그래밍이란 책을 저술했다.)
2. 복잡성은 개발자들의 생명을 갉아먹는다. 그것은 제품을 기획하고 만들고 테스트하기 어렵게 한다. 그것은 보안을 위협하고 사용자와 운영자가 좌절하게 만든다. (Ray Ozzie, 소프트웨어 아키텍트)
3. 소프트웨어 설계를 하는 두가지 방법이 있다. 하나는 빠진 게 없는지 쉽게 확인할 수 있게 최대한 단순하게 만드는 것이고, 또 한가지는 빠진 게 없는지 확인할 수 없게 최대한 복잡하게 만드는 것이다.(C.A.R. Hoare, Quick Sort의 고안자)
4. 좋은 소프트웨어의 기능이란 복잡한 것을 간단하게 보이도록 만드는 것이다. (Grady Booch, UML 개발자)

Ease of Use(사용 편의성)

1. 기억하라. 당신은 컴퓨터 서적이 시키는 대로 하는 바보가 아니다. 실제 바보란 아무리 전문가라고 하더라도 일반인들이 사용할 수 없는 하드웨어와 소프트웨어를 설계하는 사람들을 말한다. (Walter Mossberg, 유명한 테크 저널리스트)
2. 소프트웨어 공급자들은 자신들의 소프트웨어 패키지를 더욱 ‘사용자 친화적’으로 만드려고 노력해왔다. 그 중에서 가장 잘한 일은 브로셔의 ‘사용자 친화적’이라는 단어에 동그라미를 치는 것이었다. (Bill Gates, MS의 창립자)
3. 컴퓨터가 핸드폰과 비슷한 수준으로 사용하기 쉬워지기를 바랐던 남자가 있었다. 그런데 전화기 사용법이 컴퓨터만큼 어려워지면서 그 소원이 자연스레 이루어졌다.  (Bjarne Stroustrup, C++언어를 개발한 사람)

Users

테드 넬슨, 1937 ~, 인터넷의 아버지, HyperText 창시자, 사회학자이자 철학자
1. 어떤 바보라도 컴퓨터를 사용할 수 있다. 그래서 많은 사람들이 컴퓨터를 사용한다. “Any fool can use a computer.  Many do.” (Ted Nelson, HTML을 처음으로 생각해 낸 사회과학자)
2. 고객을 ‘유저’라고 부르는 산업은 딱 두 개가 있다. – Drugs, IT (Edward Tufte, 데이터 시각화의 선구자)

Programmers

1. 프로그래머들은 더 많은 멍청이들을 만들지 않기 위해 TV 시리즈 the Universe와 경쟁하고 있지만 the Universe는 더 많은 멍청이를 만들기 위해 애쓰고 있다. 그런데 아직까지는 the Universe가 이기고 있다.(Rich Cook, 판타지 소설가, 이 다큐멘터리는 컴퓨터 그래픽을 많이 쓰기로 유명했다.)
2. 당신들 대부분이 프로그래머의 3대 미덕을 이미 잘 알고 있다. – 게으름, 괴팍함, 그리고 자만심. (Larry Wall, Perl 언어의 창시자)

시모어 크레이, 1925 – 1996, 슈퍼컴퓨터 크레이의 아버지
3. 프로그래머의 문제점은 그들이 늦어버릴 때까지는 무엇을 하고 있는지 절대 물어볼 수 없다는 것이다. “The trouble with programmers is that you can never tell what a programmer is doing until it’s too late.” (Seymour Cray, 슈퍼컴퓨터 크레이를 만든 사람)
4. 그들이 컴퓨터를 미워할 것이라고 생각하는 사람들이 있다. 그러나 그들이 진짜로 미워하는 것은 형편없는 프로그래머들이다.(Larry Niven, Ringworld  유명한 SF소설가)
5. 꽤 오랫동안 사람들은 그렇게 비싸고 멋있는 것들이 왜 그렇게 쓸모가 없는지 혼란스러워 했다. 그런데 나는 프로그래머가 바보같은 일을 하는 똑똑한 사람들인 반면, 컴퓨터는 엄청 똑똑한 일을 하는 바보 상자라는 것을 알게 되자 비로소 그 심정이 이해가 되었다. 정말 찰떡 궁합이다.(Bill Bryson, 유명한 작가)
6. 붓과 색을 공부한다고 훌륭한 화가가 되지 않듯 컴퓨터 과학을 공부한다고 훌륭한 프로그래머가 되지는 않는다.(Eric Raymond, 인류학자, 오픈소스 운동의 대표 서술가)
7. 프로그래머란 다음과 같은 과정을 거쳐서 전문가로 탄생한 사람을 말한다. 그들은 1) 미완의 문서에서 나온 미완의 도표에 기반한 모호한 가정들로부터 미세한 수준까지 계산해서 답변을 하거나 2)  무언가를 묻기 힘들 정도로 완전히 걸레가 된 부서를 괴롭히기 위해  애매하게 묻는 사람들이 제시하는 부정확한 수단들을 바탕으로 소프트웨어를 개발하는 사람들이다. (IEEE Grid newsmagazine 잡지, 요약하면 굉장히 복잡한 상황에서 일하는 사람이라는 뜻)
8. 해커란 7,8명의 개발자들이 1년 동안 어렵게 개발하는 것들을 단 몇 달만에 혼자서 개발할 수 있는 사람을 말한다. IBM은 어떤 프로그래머들은 다른 이들보다 100배 이상의 더 많은 일을 할 수 있다고  보고했었다. (Peter Seebach, Unix 전문 테크 저널리스트)
9. 최고의 프로그래머는 그냥 좋은 프로그래머들보다 조금 더 나은 게 아니다. 그들은 어떻게 측정하던 간에 보통 사람들 보다 한 자리 수 이상이다. : 창의력, 스피드, 설계능력, 문제해결 능력까지. (Randall E. Stross, 뉴욕타임즈 테크부문 기자)
10. 훌륭한 기계공은 일반 기계공보다 몇 배의 급여를 더 높이 받는다. 그러나 훌륭한 코드를 만들어내는 개발자는 일반적인 개발자보다 1만배 이상의 가치가 있다. (Bill Gates)

Programming

1. 올바로 작동하지 않는다고 걱정하지 마라. 만일 모든 게 잘 된다면, 굳이 당신이 일할 이유가 없다.(Mosher’s Law of Software Engineering)
2. 코드 수를 기준으로 프로그램의 진도를 측정하는 것은 비행기 제작 진도를 무게로 측정하는 것과 같다. (Bill Gates)

제럴드 와인버그, 1933~, 소프트웨어 개발의 심리학과 철학 – 애자일 분야에 지대한 영향을 끼침
3. 코딩이란 사회조직에서 도굴보다는 위면서 관리의 바로 밑 어디엔가 위치하는 직업이다. “Writing code has a place in the human hierarchy worth somewhere above grave robbing and beneath managing.” (Gerald Weinberg, 컴퓨터 과학자, 소프트웨어 개발관련 인류학 및 심리학 교수)
4. 처음에는 컴퓨터 과학과 이론을 배워라. 그리고는 프로그래밍 스타일을 익혀라. 그리고는 모두 잊어버려라. 그저 해킹hack하라.(George Carrette, SIOD의 창시자, hack이란 개발에 몰두하는 것으로 의역할 수 있을 듯)
5. 먼저 문제를 풀고 그 다음에 개발을 하라.(John Johnson, 미국의 유명한 소프트웨어 강사)
6. 낙관론은 프로그래머라는 직업 관점에서 위험물이다. 피드백이 해결책이다.(Kent Beck, Extreme 프로그래밍 방법론의 창시자, 무의식적으로 금방 된다고 이야기하지 마세요. 경험상 진짜 금방 되는 경우를 거의 본적이 없는 것 같네요.)
7. “To iterate is human, to recurse divine.” (L. Peter Deutsch, PDF Interpreter, Ghostscript, PostScript의 창시자)
8. Boolean 이 좋은 것은 당신이 설령 잘못했더라도 한 비트만 바꾸면 된다는 것이다. (익명)
9. Array는 꼭 0이나 1에서 시작해야 하나? 내 생각에는 0.5 에서 시작하면 어떨까라는 내 의견은 충분한 검토 없이 기각된 것 같다. (Stan Kelly-Bootle, 컴퓨터 과학자)

Programming Languages

1. 세상에는 딱 두 가지 프로그래밍 언어가 있다. 사람들이 욕하는 언어와 아무도 사용하지 않는 언어.(Bjarne Stroustrup, C++의 창시자)
2. PHP는 성숙되지 않은 아마츄어에 의해 눈에 띄게 저질러지는 작은 악이라면, Perl은 숙련되었지만 비정상적인 프로들에 의해 눈에 띄지 않게 저질러지는 커다란 악이다. (Jon Ribbens, 개발자)
3. COBOL 은 사람의 마음을 망가뜨린다. 그것을 가르치는 것은 범죄행위로 간주해야 한다.(E.W. Dijkstra, 독일 컴퓨터 과학자)
4. 먼저 BASIC에 노출된 학생들에게 좋은 프로그래밍 스타일을 가르친다는 것은 현실적으로 불가능하다. 그들은 잠재적인 프로그래머로서 재교육으로 치유될 수 없는 정신적인 피해를 입은 것이다. they are mentally mutilated beyond hope of regeneration.” (E. W. Dijkstra, 상동)
5. 내 생각에 MS가 .Net 이라고 이름을 붙인 이유는 유닉스 상에서 안 보이게 하고 싶었던 거다. (Oktal)
6. 아무리 구조가 잘 되어 있더라도 프로그래머가 나쁜 프로그램을 만드는 것을 방지하는 프로그래밍 언어는 없다. (Larry Flon, 구조적 프로그래밍에 대한 연구 저자)
7. 컴퓨터 언어를 설계하는 것은 공원을 산책하는 것과 같다. ‘쥬라기 공원!!!’ (Larry Wall, Perl 언어의 창시자)

C/C++

1. 50년간 연구를 했다. 결국 C++인가 we end up with C++? (Richard A. O’Keefe, Functional Programming 연구에 힘쓰는 컴퓨터 과학자)
2. C,C++을 쓰는 것은 안전가드를 제거한 전기톱을 쓰는 것과 같다. (Bob Gray)
3. C++에서는 스스로 발을 쏘기는 매우 어렵다. 그러나 만일 그렇게 되면 다리 전체를 날려버리게 된다. (Bjarne Stroustrup, C++언어의 창시자)
4. C++ : 친구들이 당신의 개인적인 멤버들과 만날 수 있는 곳. “C++ : Where friends have access to your private members.” (Gavin Russell Baker)
5. 로마 제국이 망한 이유 중의 하나는 그들이 C프로그램이 성공적으로 종료되었는지 표시할 방법이 없었기 때문이다. (Robert Firth)

Java

1. 자바는 많은 부분에서 C++- (=C++ 의 마이너스 버전)이다.(Michael Feldman, SIGAda 의장)
2. (19금)“Saying that Java is nice because it works on all OSes is like saying that anal sex is nice because it works on all genders.”(Alanna)
3. 좋아요. 자바는 프로그래밍 언어가 보여줄 수 있는 좋은 예입니다. 그러나 자바 어플리케이션은 절대 그렇게 되지 않아야 하는 좋은 예입니다.(pixadel)
4. 자바가 정말로 가비지 콜렉션을 한다면, 대부분의 프로그램들은 실행 중에 자기자신을 지워버릴지도 모른다.(Robert Sewell)

Open Source

1. (19금)소프트웨어는 섹스와 같아서 공짜가 더 좋다. (Linus Torvalds, 리눅스 토발즈)
2. 무료 소프트웨어를 두려워하는 사람들은 자신들의 제품이 그것보다 못하기 때문이다. (David Emery, 오픈소스 개발자)

Code

1. 훌륭한 코드는 훌륭한 문서보다 낫다.(Steve McConnell, 개발자)
2. 당신이 6개월 이상 한 번도 보지 않은 코드는 다른 사람이 다시 만드는 게 훨씬 더 나을 수 있다.(Eagleson’s Law)
3. 코드의 90%는 개발 시간의 90%를 설명해준다. 나머지 10%는 그 시간에 일어났던 다른 일의  90%를 설명해준다. (Tom Cargill, 벨연구소 개발자)

Software Development

1. 좋은 프로그래머는 자신들의 두뇌를 사용한다. 그러나 좋은 가이드라인은 모든 케이스를 고려해야만 하는 노력을 줄여준다. (Francis Glassborow, 개발자)
2. 우리의 소프트웨어는 의미있는 요구사항을 거의 가지고 있지 않다. 그럼에도 불구하고 유일한 성공의 척도는 우리의 솔루션이 갈팡질팡하는 고객의 문제점을 해결해 줄 수 있느냐 하는 것이다.” In software, we rarely have meaningful requirements.  Even if we do, the only measure of success that matters is whether our solution solves the customer’s shifting idea of what their problem is.” (Jeff Atwood, StackOverFlow의 창립자)
3. 우리 컴퓨터 프로그램의 슬픈 상태를 고려해보면  소프트웨어 개발은 아직은 어둠의 마법Black Art이다. 아직은 엔지니어링an engineering discipline이라고 부르기는 어렵다. (Bill Clinton, 미국 대통령)
4. 훌륭한 개발팀 없이 훌륭한 소프트웨어를 만들 수 없다. 그러나 대부분의 개발팀들은 문제있는 가족들처럼 행동한다. (Jim McCarthy, AI 용어를 만든사람, 인지 과학자)

Debugging

1. 우리는 프로그래밍을 시작하자 마자 생각했던 대로  만들기 쉽지 않다는 것에 놀라게 된다. 그래서 디버깅이 만들어졌다. 나는 인생의 대부분이 내 프로그램의 실수를 찾아내는데 낭비되고 있음을 알게 된 그 때를 정확히 기억한다. (Maurice Wilkes 이 디버깅을 발견하다. 1949년, EDSAC과 마이크로프로그래밍의 창시자)
2. 디버깅은 처음 코드를 만드는 것보다 두 배는 어렵다. 그래서 만일 당신이 가능한 공들여서 코드를 짜고 있다면 디버깅 하기에는 충분히 똑똑하지 않다는 뜻이기도 하다. (Brian Kernighan, Unix 창시자)
3. 만일 디버깅이 벌레를 잡는 과정이라면 프로그래밍은 그걸 집어넣는 과정이다.(Edsger W. Dijkstra, 구조적 프로그래밍, 세마포어로 유명한 컴퓨터 과학자)

Quality

1. 당신의 컴퓨터에서 돌아가는 건 중요하지 않다. 당신의 컴퓨터로 서비스하는 게 아니기 때문이다. (Vidiu Platon)
2. 프로그램은 섹스와 같다. 한 번의 실수로 평생을 지원해야 한다.  (Michael Sinz)
3. 에러 없는 프로그램을 만드는 데는 두가지 방법이 있다. 그런데  세번째 것만 작동한다. (Alan J. Perlis, 알골 프로그램 창시자)
4. 당신은 소프트웨어 품질을 추구할 수도 있고, 포인터 연산을 할 수도 있다. 그러나 두 개를 동시에 할 수는 없다. (Bertrand Meyer, 에펠 언어의 창시자)
5. 만일 소프트웨어 회사가 맥도날드라면, 수백개의 빅맥 중 하나가 식중독을 일으킬 때 아마 이렇게 말할 것이다. ‘죄송합니다. 고객님. 여기 쿠폰 두 장을 받으세요…’ (Mark Minasi, 윈도우 개발계의 대부, 맥도날드를 비꼬는건가?)
6. 항상 이런 생각으로 개발에 임하라. “내 소스를 유지보수하게 되는 개발자가 내가 어디 살고 있는지 알고 있는 과격한 사이코패스일 것이다.” (Martin Golding)
7. 실수는 사람의 것이다. 그러나 정말 일을 엉망으로 만들고 싶다면 컴퓨터가 필요하다. (Paul Ehrlich)
8. 컴퓨터는 그동안 인류 역사에서 발명했던 그 어떠한 것들 보다 더 빠르고 더 많은 실수들을 사람들이 하게 만든다. – 권총과 데낄라를 제외하고는 (Mitch Radcliffe)

Predictions(예측)

1. 발명될 수 있는 것은 모두 발명되었다.(Charles H. Duell, Commissioner, U.S. Office of Patents, 1899)
2. 나는 전 세계적으로 컴퓨터 수요가 약 5대 정도 있을 것 같다.(Thomas J. Watson, Chairman of the Board, IBM, circa 1948)
3. 말하기 조심스럽고 어리석게 들릴지도 모르겠지만, 우리는 컴퓨터 기술로 이룰 수 있는 것들의 한계에 이른 것처럼 보인다 . (John Von Neumann, circa 1949)
4. 그런데 그게 무엇에 좋나요? (Engineer at the Advanced Computing Systems Division of IBM, 마이크로칩 설명회에서, 1968)
5. 사람들이 자기 집에 컴퓨터를 가지게 될 이유는 전혀 없다.(Ken Olson, President, Digital Equipment Corporation, 1977)
6. 640KB이면 모든 사람들에게 충분하다.(Bill Gates, 1981)
7. 윈도우 NT는 2GB 램을 지원합니다. 2GB 이상을 필요로 하는 어플리케이션은 없을 것이기 때문입니다. (Microsoft, on the development of Windows NT, 1992)
8. 우리는 팜파일럿 족들이 WipeMe 1.0을 들고 나올 때까지 절대 종이없는 사무실을 만들지 못할 것이다. (Andy Pierson)
9. 이대로라면 사람들의 근육은 퇴화해버려서 버튼을 누를 손가락만 남을 것이다. (Frank Lloyd Wright)

전쟁의 법칙

You are not Superman.
당신은 절대 슈퍼맨이 아니다.

Recoilless rifles have recoil.
무반동포는 반동이 있다.

Suppressive fire? wont suppress enemies.
제압사격이라고? 적을 제압하지 못한다.

Never share a foxhole with anyone braver than you.
당신보다 용감한 사람하고는 절대 엄폐호를 공유하지 마라.

Always keep in mind that your weapon was made by the lowest bidder.
당신이 들고 있는 총은 최저가입찰 생산자가 만들었다는 사실을 잊지 마라.

If your attack is going well, its an ambush.
공격이 잘 진행되고 있다면 매복이 있다는 뜻이다.

If you cant remember . . . the claymore is probably pointed at you.
클레이모어를 설치할 때 제대로 안 봤다면 십중팔구 적 쪽이 아니라 내 쪽으로 설치해놨다.

All five second grenade fuses are three seconds.
모든 5초짜리 시한신관은 3초에 터진다.

Try to look unimport!!!ant. The enemy may be low on ammo.
별로 안 중요해 보여야 한다. 그럼 적이 탄약을 아껴줄 수도 있다.

The easy way is always mined.
좀 쉬워 보이는 길에는 언제나 지뢰가 깔려 있다.

Teamwork is essential. It gives the enemy other people to shoot at.
팀웍은 매우 중요하다. 적이 나 대신 다른 사람을 쏠 테니까.

If the enemy is in range, so are you.
적이 사거리에 들어와 있다면 당신도 마찬가지임을 명심하라.

Make it too tough for the enemy to get in ... and you cant get out.
적이 진입하기 힘들게 장애물을 깔아놓으면 꼭 내가 나가기도 힘들다.

Tracers work both ways.
예광탄은 쏘는 놈이나 맞는 놈이나 다 보인다.

The only thing more accurate than incoming enemy fire is incoming friendly fire.
적의 사격보다 더 정확한 건 아군의 오인사격이다.

Radios will fail as soon as you need something desperately.
무전기는 당신이 필요로 하는 순간 고장난다.

The bursting radius of a grenade is always one foot greater than your jumping range.
수류탄의 유효살상범위는 항상 당신이 피한 것보다 살짝 넓다.

The law of the bayonet says the man with the bullet wins.
총검의 법칙 : 탄환 남은 놈이 이긴다.

Precision bombing is normally accurate within plus/minus two Kilomiters.
정밀폭격은 보통 한 2km 빗맞으면 잘 맞은 거다.

The side with the fanciest uniforms losses.
제복 멋진 쪽이 진다.

If you are short of everything except enemy, youre in combat.
당신이 적 빼고 모든 게 부족하다면, 당신은 지금 전투중인 것이다.

No plan survives the first few seconds of combat.
작전계획이란 건 도대체 전투 개시 후 몇초 이상 가는 법이 없다.

Ammo is cheap; your life isnt.
탄환은 매우 싸다. 당신 목숨은 안 그렇다.

전쟁 명언

당신은 전쟁에 관심이 없을지 몰라도, 전쟁은 당신에게 관심이 있다.

- 트로츠키

“무척 힘들었지만 돌이켜보면 그마저도 아름다웠노라는 식으로 포장되는 것, 이엇이 추억의 본질입니다. 예를 들어 ‘그 옛날 전쟁중엔 이랬지. 그때가 좋았는데 하던 것이 훌륭한 전쟁이었어, 누가 뭐래도 위한 시대였다고‘와 같은 위험한 발언으로 변질되는 것입니다. 애니메이션에서 전쟁을 묘사할 때도 제작자의 메시지를 담는다면 괜찮지만, 전쟁을 단순하게 묘사하기만 하는 것은 큰 죄악이라고 나는 믿고 있습니다” 

- 데즈카 오사무

“부자들이 전쟁을 선언하면 죽는자들은 가난한 자들이다.” 

- 장 폴 샤르트르

“인류가 전쟁의 종말을 이룩해야 한다. 그렇지 않으면 전쟁이 인류의 종말을 가져다 줄 것이다.”

- 존 F 케너디

“전쟁은 위대한 서사시와 위대한 영웅을 남기는게 아니라 전쟁은 욕심과 자만에서 탄생되며 남는건 눈물과 고통, 피만 남게 되는 비참한 것임을 우리는 깨달아야 한다.

- 클라우제비츠

한 장수의 공을 위해 수많은 병사들이 백골이 되는구나. 

- 조송의 질언절구 기해서 中

나라가 크더라도 전쟁을 좋아하게 되면 반드시 망하는 법이다. 또 아무리 천하다 태평하더라도 전쟁에 대한 만일의 준비를 잊어버리면 반드시 위험한 법이다. 

- 문장궤범

늙은이들이 전쟁을 선포한다. 그러나 싸워야 하고 죽어야 하는 것은 젊은이들이다.

- 허버트 후버

더 이상의 전쟁은 안된다! 

- 폴란드 그단스크에 위치한 베스테르프라테 반도의 기념비.

맨 먼저 전쟁을 일으킨 자에게 저주가 있으라. 

- 크리스토퍼 말로

모든 것은 전쟁만으로 해결되는 것이 아니다. 

- 손자병법

전쟁에서는 어느 편이 스스로를 승자라고 부를지라도 승리자는 없고 모두 패배자뿐이다.

- 챔벌린

전쟁에서의 승리를 아름답게 여기는 자는 곧 살인을 즐기는 것이다. 

- 노자

평화를 원하거든 전쟁에 대비히라. 

- 베제티우스.

전쟁은 잔인한 것이다. 그걸 바꿀 필요는 없다. 잔인하면 잔인할수록 빨리 끝나니까

- 윌리엄 테쿰셔 셔먼

전쟁을 간단히 설명하자면 인류의 모든 범죄를 다 모아놓은 것.

전투를 하기로 결심했다면 전투력을 집중시켜라

그 어떤 것에도 힘을 분산시키지 말라.

일개 대대 병력으로도 그날의 승리를 결정지을 수 있다.

- 나폴레옹

적을 알고 나를 알면 백 번 싸워도 위태롭지 않을 것이다.

나를 알고 적을 모르면 승률은 반반이다.

나도 모르고 적도 모른다면 전투를 할 때마다 위태로울 것이다.

- 손자

죽고자 하면 살고 살고자 하면 죽는다 한사람이 길목을 막고 지키면 천명도 두렵게 할 수 있다.

- 이순신

전쟁에 일관된 명령만큼 중요한 것이 없다.

강대국을 상대로 한 전쟁은 반드시 한 사람의 지도자가 이끄는 하나의 기반에 근거한, 하나의 군대에 의해서 이루어져야 한다. 

- 나폴레옹

전쟁에서의 성공은 전쟁의 황금률을 얼마나 잘 실천했느냐에 달려 있다.

황금률이란 속도 - 단순함 - 과감함 이다. 

- 조지 패튼

작전계획이란 적의 주력부대와 맞딱트리고 난 이후 바뀔 수 있다.

따라서 지속적으로 꾸준히 계획하는 것만이 의미가 있다. 

- 헬무스 몰케

부하의 생명을 희생시키는 것보다는 탄약을 허비하는 것이 훨씬 낫다는 것을 명심하라.

- 조지 패튼

군인의 손에 책이 놓아졌다면, 그 즉시 군복을 벗는 것이 조국에 대한 마지막 충성이다.

- 남재준(전 육군 참모총장)

터전을 포기하지 말라. 잃은 것을 되찾기보다 가지고 있는 것을 지키는 것이 경제적이다.

- 조지 패튼

적이 예측할 수 있는 곳에 절대 공격하지 말라. 

- 조지 패튼

승리는 가장 끈기 있는 자의 것이다. 

- 나폴레옹

전쟁의 승패는 계획이 아닌 실행에 달려 있다. 

- 조지 패튼

싸워서 이기는 군대는 먼저 이길 수 있는 태세를 갖추어 놓고 싸움에 임하며, 패하는 군대는 먼저 싸움을 걸어 놓고 뒤늦게 이기고자 한다. 

- 손자

해양을 지배하는 자, 모든 것을 지배한다. 

- 테미스토클레스

일단 전쟁이 선포되면 공격적이고 적극적으로 임하라.

적은 방어의 대상이 아니라 철저히 패배시켜야 하는 대상일 뿐이다. 

- 머핸

흔히 우리는 계획을 세운 후 환경을 그 계획에 맞추려고 하기보다는 환경에 맞춰 계획을 세우려고 한다. 지휘관의 성공과 실패는 환경에 계획을 맞도록 변화시킬수 있는 능력 여하에 달려 있다

- 조지 패튼

전쟁에서 예측할 수 있는 일은 한가지 예측대로는 일어나지 않는다.

- 칼 폰 클아우제비츠

전투는 작전과 대량살상에 의해 승리한다. 하지만 위대한 장군일수록 작전에 더 기여하여 인명피해를 줄인다.

- 윈스톤 처칠

무의미하게 사는것 보다 무엇인가를 위해 싸우는 것이 더 낫다.

- 조지. S. 패튼장군

우리가 전쟁을 끝내지 않으면 전쟁이 우리를 끝낼 것이다.

- H.G. 웰즈

전쟁터에서 누군가 죽었을때 그의 죽음을 애도하지 말라 대신 자신이 살아남았음을 신에게 감사드리거라

- 조지 S. 패튼장군

영국은 모든 전투에서 패할 것이다. 최후의 전투를 빼놓고서는.

런던이 점령된다면 독일군은 내 시체를 이 의자에서 끌어내려야 할거요.

전투기는 우리 국토를 구원해 주겠지만, 궁극적으로 이 전쟁에서 승리를 가져다 줄 것은 폭격기이다.

한명의 죽음은 비극이요, 백만명의 죽음은 통계이다.

- 처칠

우리는 전투( 戰鬪 )에는 졌지만, 전쟁( 戰爭 )에는 아직 지지 아니했다.

- 드골

스탈린그라드에서는 7초에 한명꼴로 독일병사들이 죽어가고 있습니다. 1초,2초...7초, 방 금 또 한사람이 죽었습니다.

- 모스크바의 한 라디오방송

나의 기갑부대는 2개 군단 이상의 가치가 있다.

- 버나드 몽고메리 영국 장군

이건 전쟁이 아니라 살육입니다.

- 노르망디 상륙작전의 한 미군 병사

절대적으로 판세가 불리할 때는 한장의 카드에 모든 것을 걸어 보는 모험도 해볼만 하지 않겠는가?

- 발지전투 당시의 알프레드요들 독일 육군참모총장

전차들은 가솔린이 있는 한 앞으로만 달려가기만 하면 돼. 가솔린이 떨어지면 전차에서 내려서 뛰어가!

- 조지 패튼 

용기있게 행동해라. 불운하다면 불행에 맞서.

하나의 철 십자훈장 보다, 한대의 탱크와 기름을 다오. 

- 롬멜

이제부터 도이치 역사에 항복이란 단어가 적히지 않을 것을 전세계에 선언하노라.

대중의 수용성은 아주 한정되고 지성은 작다. 그러나 대중의 망각 능력은 엄청나다. 

국력은 방어에 있는 것이 아니라 침략에 있다.

- 아돌프 히틀러

이제 우리 독일해군이 할 수 있는 유일한 일은 가능한한 멋지게 죽는 방법을 찾는 것 뿐이다.

- 에리히 레더 독일 해군 참모 총장

악한 인간 일수록 훌륭한 군인이다. 

- 나폴레옹

희망이 적으면 적을수록 평화는 더 많이 존재한다. 

- 윌슨

주사위는 던져졌다. 

- 카이사르

평화로 가는 길은 없다. 평화가 길이다. 

- A.J. 머스트

항상 전쟁에 대비해 있는 것이야말로 전쟁을 피하는 가장 확실한 방법이다. 

- 멘토르

전쟁을 방지하는 가장 확실한 방법은 그것을 겁내지 않는 것이다. 

- 존 랜돌프

전쟁의 승리는 최후의 5분에 있다. 

- 나폴레옹

Culture eats strategy for breakfast

Culture eats strategy for breakfast 
 by Peter Drucker

what do we mean by?

• In our client work we learn again and again that great strategies can be resisted by strong enterprise cultures. We call this “culture eats strategy for breakfast”

• A culture can be a powerful animal that counteracts and resists attempts to change, no matter how good the strategy is

t

Empathic embarrassment

Empathic embarrassment 

     : Situational and personal determinants of reactions to the embarrassment of another.

 

By Miller, Rowland S.

 

Journal of Personality and Social Psychology, Vol 53(6), Dec 1987, 1061-1069.

 

Abstract

Two experiments investigated the reactions of observers to actors' embarrassments. The first study manipulated the nature of the prior interaction between actor and observer (cooperative, competitive, or independent) and the observational set of the observer (empathic or nonempathic). The observers' self-reports and measures of their skin potentials indicated that an empathic set and any prior interaction generally increased their responsiveness to the actors' plight. Moreover, independent, empathic observers reported reactions that appear to be empathic embarrassment, embarrassment felt with another even though one's own social identity is not threatened. The second study showed that empathic embarrassment is strongest in subjects of high embarrassability who are chronically susceptible to embarrassment. The results portray social embarrassment as a robust, pervasive phenomenon that nevertheless affects some people more than others. The possible origins of empathic embarrassment and the joint influences of perception, interaction, and personality on the experience of empathic embarrassment are discussed. (PsycINFO Database Record (c) 2016 APA, all rights reserved)

펠리칸(Pelican) Classic 200 Cafe Cream

펠리칸(Pelican) Classic 200 Cafe Cream

프림이 녹기 전 커피잔을 보는 듯한 따뜻한 느낌이다.

황금색 펜촉까지 영혼을 끌어들이는 마력이 있다.

피보나치(Fibonacci) in C

#include 

/* buff array for memorization */

int buf[10001];

/* buff array initialize */

void init(int arr[], int s){

     int i;

     buf[0]=0;

     buf[1]=1;

     buf[2]=2;

     for(i=3;i

          arr[i]=0;

     }

}

/* Fibonacci main function */

int Fibo(int i){

     if(but[i] != 0) return i; 

     return Fibo(i-1) + Fibo(i-2); 

} 

The Free Lunch Is Over

The Free Lunch Is Over A Fundamental Turn Toward Concurrency in Software By Herb Sutter The biggest sea change in software development since the OO revolution is knocking at the door, and its name is Concurrency. This article appeared in Dr. Dobb's Journal, 30(3), March 2005. A much briefer version under the title "The Concurrency Revolution" appeared in C/C++ Users Journal, 23(2), February 2005. Update note: The CPU trends graph last updated August 2009 to include current data and show the trend continues as predicted. The rest of this article including all text is still original as first posted here in December 2004. Your free lunch will soon be over. What can you do about it? What are you doing about it? The major processor manufacturers and architectures, from Intel and AMD to Sparc and PowerPC, have run out of room with most of their traditional approaches to boosting CPU performance. Instead of driving clock speeds and straight-line instruction throughput ever higher, they are instead turning en masse to hyperthreading and multicore architectures. Both of these features are already available on chips today; in particular, multicore is available on current PowerPC and Sparc IV processors, and is coming in 2005 from Intel and AMD. Indeed, the big theme of the 2004 In-Stat/MDR Fall Processor Forum was multicore devices, as many companies showed new or updated multicore processors. Looking back, it’s not much of a stretch to call 2004 the year of multicore. And that puts us at a fundamental turning point in software development, at least for the next few years and for applications targeting general-purpose desktop computers and low-end servers (which happens to account for the vast bulk of the dollar value of software sold today). In this article, I’ll describe the changing face of hardware, why it suddenly does matter to software, and how specifically the concurrency revolution matters to you and is going to change the way you will likely be writing software in the future. Arguably, the free lunch has already been over for a year or two, only we’re just now noticing. The Free Performance Lunch There’s an interesting phenomenon that’s known as “Andy giveth, and Bill taketh away.” No matter how fast processors get, software consistently finds new ways to eat up the extra speed. Make a CPU ten times as fast, and software will usually find ten times as much to do (or, in some cases, will feel at liberty to do it ten times less efficiently). Most classes of applications have enjoyed free and regular performance gains for several decades, even without releasing new versions or doing anything special, because the CPU manufacturers (primarily) and memory and disk manufacturers (secondarily) have reliably enabled ever-newer and ever-faster mainstream systems. Clock speed isn’t the only measure of performance, or even necessarily a good one, but it’s an instructive one: We’re used to seeing 500MHz CPUs give way to 1GHz CPUs give way to 2GHz CPUs, and so on. Today we’re in the 3GHz range on mainstream computers. The key question is: When will it end? After all, Moore’s Law predicts exponential growth, and clearly exponential growth can’t continue forever before we reach hard physical limits; light isn’t getting any faster. The growth must eventually slow down and even end. (Caveat: Yes, Moore’s Law applies principally to transistor densities, but the same kind of exponential growth has occurred in related areas such as clock speeds. There’s even faster growth in other spaces, most notably the data storage explosion, but that important trend belongs in a different article.) If you’re a software developer, chances are that you have already been riding the “free lunch” wave of desktop computer performance. Is your application’s performance borderline for some local operations? “Not to worry,” the conventional (if suspect) wisdom goes; “tomorrow’s processors will have even more throughput, and anyway today’s applications are increasingly throttled by factors other than CPU throughput and memory speed (e.g., they’re often I/O-bound, network-bound, database-bound).” Right? Right enough, in the past. But dead wrong for the foreseeable future. The good news is that processors are going to continue to become more powerful. The bad news is that, at least in the short term, the growth will come mostly in directions that do not take most current applications along for their customary free ride. Over the past 30 years, CPU designers have achieved performance gains in three main areas, the first two of which focus on straight-line execution flow: Increasing clock speed is about getting more cycles. Running the CPU faster more or less directly means doing the same work faster. Optimizing execution flow is about doing more work per cycle. Today’s CPUs sport some more powerful instructions, and they perform optimizations that range from the pedestrian to the exotic, including pipelining, branch prediction, executing multiple instructions in the same clock cycle(s), and even reordering the instruction stream for out-of-order execution. These techniques are all designed to make the instructions flow better and/or execute faster, and to squeeze the most work out of each clock cycle by reducing latency and maximizing the work accomplished per clock cycle. Chip designers are under so much pressure to deliver ever-faster CPUs that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster Brief aside on instruction reordering and memory models: Note that some of what I just called “optimizations” are actually far more than optimizations, in that they can change the meaning of programs and cause visible effects that can break reasonable programmer expectations. This is significant. CPU designers are generally sane and well-adjusted folks who normally wouldn’t hurt a fly, and wouldn’t think of hurting your code… normally. But in recent years they have been willing to pursue aggressive optimizations just to wring yet more speed out of each cycle, even knowing full well that these aggressive rearrangements could endanger the semantics of your code. Is this Mr. Hyde making an appearance? Not at all. That willingness is simply a clear indicator of the extreme pressure the chip designers face to deliver ever-faster CPUs; they’re under so much pressure that they’ll risk changing the meaning of your program, and possibly break it, in order to make it run faster. Two noteworthy examples in this respect are write reordering and read reordering: Allowing a processor to reorder write operations has consequences that are so surprising, and break so many programmer expectations, that the feature generally has to be turned off because it’s too difficult for programmers to reason correctly about the meaning of their programs in the presence of arbitrary write reordering. Reordering read operations can also yield surprising visible effects, but that is more commonly left enabled anyway because it isn’t quite as hard on programmers, and the demands for performance cause designers of operating systems and operating environments to compromise and choose models that place a greater burden on programmers because that is viewed as a lesser evil than giving up the optimization opportunities. Finally, increasing the size of on-chip cache is about staying away from RAM. Main memory continues to be so much slower than the CPU that it makes sense to put the data closer to the processor—and you can’t get much closer than being right on the die. On-die cache sizes have soared, and today most major chip vendors will sell you CPUs that have 2MB and more of on-board L2 cache. (Of these three major historical approaches to boosting CPU performance, increasing cache is the only one that will continue in the near term. I’ll talk a little more about the importance of cache later on.) Okay. So what does this mean? A fundamentally important thing to recognize about this list is that all of these areas are concurrency-agnostic. Speedups in any of these areas will directly lead to speedups in sequential (nonparallel, single-threaded, single-process) applications, as well as applications that do make use of concurrency. That’s important, because the vast majority of today’s applications are single-threaded, for good reasons that I’ll get into further below. Of course, compilers have had to keep up; sometimes you need to recompile your application, and target a specific minimum level of CPU, in order to benefit from new instructions (e.g., MMX, SSE) and some new CPU features and characteristics. But, by and large, even old applications have always run significantly faster—even without being recompiled to take advantage of all the new instructions and features offered by the latest CPUs. That world was a nice place to be. Unfortunately, it has already disappeared. Obstacles, and Why You Don’t Have 10GHz Today CPU performance growth as we have known it hit a wall two years ago. Most people have only recently started to notice. You can get similar graphs for other chips, but I’m going to use Intel data here. Figure 1 graphs the history of Intel chip introductions by clock speed and number of transistors. The number of transistors continues to climb, at least for now. Clock speed, however, is a different story. Figure 1: Intel CPU Introductions (graph updated August 2009; article text original from December 2004) Around the beginning of 2003, you’ll note a disturbing sharp turn in the previous trend toward ever-faster CPU clock speeds. I’ve added lines to show the limit trends in maximum clock speed; instead of continuing on the previous path, as indicated by the thin dotted line, there is a sharp flattening. It has become harder and harder to exploit higher clock speeds due to not just one but several physical issues, notably heat (too much of it and too hard to dissipate), power consumption (too high), and current leakage problems. Quick: What’s the clock speed on the CPU(s) in your current workstation? Are you running at 10GHz? On Intel chips, we reached 2GHz a long time ago (August 2001), and according to CPU trends before 2003, now in early 2005 we should have the first 10GHz Pentium-family chips. A quick look around shows that, well, actually, we don’t. What’s more, such chips are not even on the horizon—we have no good idea at all about when we might see them appear. Well, then, what about 4GHz? We’re at 3.4GHz already—surely 4GHz can’t be far away? Alas, even 4GHz seems to be remote indeed. In mid-2004, as you probably know, Intel first delayed its planned introduction of a 4GHz chip until 2005, and then in fall 2004 it officially abandoned its 4GHz plans entirely. As of this writing, Intel is planning to ramp up a little further to 3.73GHz in early 2005 (already included in Figure 1 as the upper-right-most dot), but the clock race really is over, at least for now; Intel’s and most processor vendors’ future lies elsewhere as chip companies aggressively pursue the same new multicore directions. We’ll probably see 4GHz CPUs in our mainstream desktop machines someday, but it won’t be in 2005. Sure, Intel has samples of their chips running at even higher speeds in the lab—but only by heroic efforts, such as attaching hideously impractical quantities of cooling equipment. You won’t have that kind of cooling hardware in your office any day soon, let alone on your lap while computing on the plane. TANSTAAFL: Moore’s Law and the Next Generation(s) “There ain’t no such thing as a free lunch.” —R. A. Heinlein, The Moon Is a Harsh Mistress Does this mean Moore’s Law is over? Interestingly, the answer in general seems to be no. Of course, like all exponential progressions, Moore’s Law must end someday, but it does not seem to be in danger for a few more years yet. Despite the wall that chip engineers have hit in juicing up raw clock cycles, transistor counts continue to explode and it seems CPUs will continue to follow Moore’s Law-like throughput gains for some years to come. Myths and Realities: 2 x 3GHz < 6 GHz So a dual-core CPU that combines two 3GHz cores practically offers 6GHz of processing power. Right? Wrong. Even having two threads running on two physical processors doesn’t mean getting two times the performance. Similarly, most multi-threaded applications won’t run twice as fast on a dual-core box. They should run faster than on a single-core CPU; the performance gain just isn’t linear, that’s all. Why not? First, there is coordination overhead between the cores to ensure cache coherency (a consistent view of cache, and of main memory) and to perform other handshaking. Today, a two- or four-processor machine isn’t really two or four times as fast as a single CPU even for multi-threaded applications. The problem remains essentially the same even when the CPUs in question sit on the same die. Second, unless the two cores are running different processes, or different threads of a single process that are well-written to run independently and almost never wait for each other, they won’t be well utilized. (Despite this, I will speculate that today’s single-threaded applications as actually used in the field could actually see a performance boost for most users by going to a dual-core chip, not because the extra core is actually doing anything useful, but because it is running the adware and spyware that infest many users’ systems and are otherwise slowing down the single CPU that user has today. I leave it up to you to decide whether adding a CPU to run your spyware is the best solution to that problem.) If you’re running a single-threaded application, then the application can only make use of one core. There should be some speedup as the operating system and the application can run on separate cores, but typically the OS isn’t going to be maxing out the CPU anyway so one of the cores will be mostly idle. (Again, the spyware can share the OS’s core most of the time.) The key difference, which is the heart of this article, is that the performance gains are going to be accomplished in fundamentally different ways for at least the next couple of processor generations. And most current applications will no longer benefit from the free ride without significant redesign. For the near-term future, meaning for the next few years, the performance gains in new chips will be fueled by three main approaches, only one of which is the same as in the past. The near-term future performance growth drivers are: Hyperthreading is about running two or more threads in parallel inside a single CPU. Hyperthreaded CPUs are already available today, and they do allow some instructions to run in parallel. A limiting factor, however, is that although a hyper-threaded CPU has some extra hardware including extra registers, it still has just one cache, one integer math unit, one FPU, and in general just one each of most basic CPU features. Hyperthreading is sometimes cited as offering a 5% to 15% performance boost for reasonably well-written multi-threaded applications, or even as much as 40% under ideal conditions for carefully written multi-threaded applications. That’s good, but it’s hardly double, and it doesn’t help single-threaded applications. Multicore is about running two or more actual CPUs on one chip. Some chips, including Sparc and PowerPC, have multicore versions available already. The initial Intel and AMD designs, both due in 2005, vary in their level of integration but are functionally similar. AMD’s seems to have some initial performance design advantages, such as better integration of support functions on the same die, whereas Intel’s initial entry basically just glues together two Xeons on a single die. The performance gains should initially be about the same as having a true dual-CPU system (only the system will be cheaper because the motherboard doesn’t have to have two sockets and associated “glue” chippery), which means something less than double the speed even in the ideal case, and just like today it will boost reasonably well-written multi-threaded applications. Not single-threaded ones. Finally, on-die cache sizes can be expected to continue to grow, at least in the near term. Of these three areas, only this one will broadly benefit most existing applications. The continuing growth in on-die cache sizes is an incredibly important and highly applicable benefit for many applications, simply because space is speed. Accessing main memory is expensive, and you really don’t want to touch RAM if you can help it. On today’s systems, a cache miss that goes out to main memory often costs 10 to 50 times as much getting the information from the cache; this, incidentally, continues to surprise people because we all think of memory as fast, and it is fast compared to disks and networks, but not compared to on-board cache which runs at faster speeds. If an application’s working set fits into cache, we’re golden, and if it doesn’t, we’re not. That is why increased cache sizes will save some existing applications and breathe life into them for a few more years without requiring significant redesign: As existing applications manipulate more and more data, and as they are incrementally updated to include more code for new features, performance-sensitive operations need to continue to fit into cache. As the Depression-era old-timers will be quick to remind you, “Cache is king.” (Aside: Here’s an anecdote to demonstrate “space is speed” that recently hit my compiler team. The compiler uses the same source base for the 32-bit and 64-bit compilers; the code is just compiled as either a 32-bit process or a 64-bit one. The 64-bit compiler gained a great deal of baseline performance by running on a 64-bit CPU, principally because the 64-bit CPU had many more registers to work with and had other code performance features. All well and good. But what about data? Going to 64 bits didn’t change the size of most of the data in memory, except that of course pointers in particular were now twice the size they were before. As it happens, our compiler uses pointers much more heavily in its internal data structures than most other kinds of applications ever would. Because pointers were now 8 bytes instead of 4 bytes, a pure data size increase, we saw a significant increase in the 64-bit compiler’s working set. That bigger working set caused a performance penalty that almost exactly offset the code execution performance increase we’d gained from going to the faster processor with more registers. As of this writing, the 64-bit compiler runs at the same speed as the 32-bit compiler, even though the source base is the same for both and the 64-bit processor offers better raw processing throughput. Space is speed.) But cache is it. Hyperthreading and multicore CPUs will have nearly no impact on most current applications. So what does this change in the hardware mean for the way we write software? By now you’ve probably noticed the basic answer, so let’s consider it and its consequences. What This Means For Software: The Next Revolution In the 1990s, we learned to grok objects. The revolution in mainstream software development from structured programming to object-oriented programming was the greatest such change in the past 20 years, and arguably in the past 30 years. There have been other changes, including the most recent (and genuinely interesting) naissance of web services, but nothing that most of us have seen during our careers has been as fundamental and as far-reaching a change in the way we write software as the object revolution. Until now. Starting today, the performance lunch isn’t free any more. Sure, there will continue to be generally applicable performance gains that everyone can pick up, thanks mainly to cache size improvements. But if you want your application to benefit from the continued exponential throughput advances in new processors, it will need to be a well-written concurrent (usually multithreaded) application. And that’s easier said than done, because not all problems are inherently parallelizable and because concurrent programming is hard. I can hear the howls of protest: “Concurrency? That’s not news! People are already writing concurrent applications.” That’s true. Of a small fraction of developers. Remember that people have been doing object-oriented programming since at least the days of Simula in the late 1960s. But OO didn’t become a revolution, and dominant in the mainstream, until the 1990s. Why then? The reason the revolution happened was primarily that our industry was driven by requirements to write larger and larger systems that solved larger and larger problems and exploited the greater and greater CPU and storage resources that were becoming available. OOP’s strengths in abstraction and dependency management made it a necessity for achieving large-scale software development that is economical, reliable, and repeatable. Concurrency is the next major revolution in how we write software Similarly, we’ve been doing concurrent programming since those same dark ages, writing coroutines and monitors and similar jazzy stuff. And for the past decade or so we’ve witnessed incrementally more and more programmers writing concurrent (multi-threaded, multi-process) systems. But an actual revolution marked by a major turning point toward concurrency has been slow to materialize. Today the vast majority of applications are single-threaded, and for good reasons that I’ll summarize in the next section. By the way, on the matter of hype: People have always been quick to announce “the next software development revolution,” usually about their own brand-new technology. Don’t believe it. New technologies are often genuinely interesting and sometimes beneficial, but the biggest revolutions in the way we write software generally come from technologies that have already been around for some years and have already experienced gradual growth before they transition to explosive growth. This is necessary: You can only base a software development revolution on a technology that’s mature enough to build on (including having solid vendor and tool support), and it generally takes any new software technology at least seven years before it’s solid enough to be broadly usable without performance cliffs and other gotchas. As a result, true software development revolutions like OO happen around technologies that have already been undergoing refinement for years, often decades. Even in Hollywood, most genuine “overnight successes” have really been performing for many years before their big break. Concurrency is the next major revolution in how we write software. Different experts still have different opinions on whether it will be bigger than OO, but that kind of conversation is best left to pundits. For technologists, the interesting thing is that concurrency is of the same order as OO both in the (expected) scale of the revolution and in the complexity and learning curve of the technology. Benefits and Costs of Concurrency There are two major reasons for which concurrency, especially multithreading, is already used in mainstream software. The first is to logically separate naturally independent control flows; for example, in a database replication server I designed it was natural to put each replication session on its own thread, because each session worked completely independently of any others that might be active (as long as they weren’t working on the same database row). The second and less common reason to write concurrent code in the past has been for performance, either to scalably take advantage of multiple physical CPUs or to easily take advantage of latency in other parts of the application; in my database replication server, this factor applied as well and the separate threads were able to scale well on multiple CPUs as our server handled more and more concurrent replication sessions with many other servers. There are, however, real costs to concurrency. Some of the obvious costs are actually relatively unimportant. For example, yes, locks can be expensive to acquire, but when used judiciously and properly you gain much more from the concurrent execution than you lose on the synchronization, if you can find a sensible way to parallelize the operation and minimize or eliminate shared state. Perhaps the second-greatest cost of concurrency is that not all applications are amenable to parallelization. I’ll say more about this later on. Probably the greatest cost of concurrency is that concurrency really is hard: The programming model, meaning the model in the programmer’s head that he needs to reason reliably about his program, is much harder than it is for sequential control flow. Everybody who learns concurrency thinks they understand it, ends up finding mysterious races they thought weren’t possible, and discovers that they didn’t actually understand it yet after all. As the developer learns to reason about concurrency, they find that usually those races can be caught by reasonable in-house testing, and they reach a new plateau of knowledge and comfort. What usually doesn’t get caught in testing, however, except in shops that understand why and how to do real stress testing, is those latent concurrency bugs that surface only on true multiprocessor systems, where the threads aren’t just being switched around on a single processor but where they really do execute truly simultaneously and thus expose new classes of errors. This is the next jolt for people who thought that surely now they know how to write concurrent code: I’ve come across many teams whose application worked fine even under heavy and extended stress testing, and ran perfectly at many customer sites, until the day that a customer actually had a real multiprocessor machine and then deeply mysterious races and corruptions started to manifest intermittently. In the context of today’s CPU landscape, then, redesigning your application to run multithreaded on a multicore machine is a little like learning to swim by jumping into the deep end—going straight to the least forgiving, truly parallel environment that is most likely to expose the things you got wrong. Even when you have a team that can reliably write safe concurrent code, there are other pitfalls; for example, concurrent code that is completely safe but isn’t any faster than it was on a single-core machine, typically because the threads aren’t independent enough and share a dependency on a single resource which re-serializes the program’s execution. This stuff gets pretty subtle. The vast majority of programmers today don’t grok concurrency, just as the vast majority of programmers 15 years ago didn’t yet grok objects Just as it is a leap for a structured programmer to learn OO (what’s an object? what’s a virtual function? how should I use inheritance? and beyond the “whats” and “hows,” why are the correct design practices actually correct?), it’s a leap of about the same magnitude for a sequential programmer to learn concurrency (what’s a race? what’s a deadlock? how can it come up, and how do I avoid it? what constructs actually serialize the program that I thought was parallel? how is the message queue my friend? and beyond the “whats” and “hows,” why are the correct design practices actually correct?). The vast majority of programmers today don’t grok concurrency, just as the vast majority of programmers 15 years ago didn’t yet grok objects. But the concurrent programming model is learnable, particularly if we stick to message- and lock-based programming, and once grokked it isn’t that much harder than OO and hopefully can become just as natural. Just be ready and allow for the investment in training and time, for you and for your team. (I deliberately limit the above to message- and lock-based concurrent programming models. There is also lock-free programming, supported most directly at the language level in Java 5 and in at least one popular C++ compiler. But concurrent lock-free programming is known to be very much harder for programmers to understand and reason about than even concurrent lock-based programming. Most of the time, only systems and library writers should have to understand lock-free programming, although virtually everybody should be able to take advantage of the lock-free systems and libraries those people produce. Frankly, even lock-based programming is hazardous.) What It Means For Us Okay, back to what it means for us. 1. The clear primary consequence we’ve already covered is that applications will increasingly need to be concurrent if they want to fully exploit CPU throughput gains that have now started becoming available and will continue to materialize over the next several years. For example, Intel is talking about someday producing 100-core chips; a single-threaded application can exploit at most 1/100 of such a chip’s potential throughput. “Oh, performance doesn’t matter so much, computers just keep getting faster” has always been a naïve statement to be viewed with suspicion, and for the near future it will almost always be simply wrong. Applications will increasingly need to be concurrent if they want to fully exploit continuing exponential CPU throughput gains Efficiency and performance optimization will get more, not less, important Now, not all applications (or, more precisely, important operations of an application) are amenable to parallelization. True, some problems, such as compilation, are almost ideally parallelizable. But others aren’t; the usual counterexample here is that just because it takes one woman nine months to produce a baby doesn’t imply that nine women could produce one baby in one month. You’ve probably come across that analogy before. But did you notice the problem with leaving the analogy at that? Here’s the trick question to ask the next person who uses it on you: Can you conclude from this that the Human Baby Problem is inherently not amenable to parallelization? Usually people relating this analogy err in quickly concluding that it demonstrates an inherently nonparallel problem, but that’s actually not necessarily correct at all. It is indeed an inherently nonparallel problem if the goal is to produce one child. It is actually an ideally parallelizable problem if the goal is to produce many children! Knowing the real goals can make all the difference. This basic goal-oriented principle is something to keep in mind when considering whether and how to parallelize your software. 2. Perhaps a less obvious consequence is that applications are likely to become increasingly CPU-bound. Of course, not every application operation will be CPU-bound, and even those that will be affected won’t become CPU-bound overnight if they aren’t already, but we seem to have reached the end of the “applications are increasingly I/O-bound or network-bound or database-bound” trend, because performance in those areas is still improving rapidly (gigabit WiFi, anyone?) while traditional CPU performance-enhancing techniques have maxed out. Consider: We’re stopping in the 3GHz range for now. Therefore single-threaded programs are likely not to get much faster any more for now except for benefits from further cache size growth (which is the main good news). Other gains are likely to be incremental and much smaller than we’ve been used to seeing in the past, for example as chip designers find new ways to keep pipelines full and avoid stalls, which are areas where the low-hanging fruit has already been harvested. The demand for new application features is unlikely to abate, and even more so the demand to handle vastly growing quantities of application data is unlikely to stop accelerating. As we continue to demand that programs do more, they will increasingly often find that they run out of CPU to do it unless they can code for concurrency. There are two ways to deal with this sea change toward concurrency. One is to redesign your applications for concurrency, as above. The other is to be frugal, by writing code that is more efficient and less wasteful. This leads to the third interesting consequence: 3. Efficiency and performance optimization will get more, not less, important. Those languages that already lend themselves to heavy optimization will find new life; those that don’t will need to find ways to compete and become more efficient and optimizable. Expect long-term increased demand for performance-oriented languages and systems. 4. Finally, programming languages and systems will increasingly be forced to deal well with concurrency. The Java language has included support for concurrency since its beginning, although mistakes were made that later had to be corrected over several releases in order to do concurrent programming more correctly and efficiently. The C++ language has long been used to write heavy-duty multithreaded systems well, but it has no standardized support for concurrency at all (the ISO C++ standard doesn’t even mention threads, and does so intentionally), and so typically the concurrency is of necessity accomplished by using nonportable platform-specific concurrency features and libraries. (It’s also often incomplete; for example, static variables must be initialized only once, which typically requires that the compiler wrap them with a lock, but many C++ implementations do not generate the lock.) Finally, there are a few concurrency standards, including pthreads and OpenMP, and some of these support implicit as well as explicit parallelization. Having the compiler look at your single-threaded program and automatically figure out how to parallelize it implicitly is fine and dandy, but those automatic transformation tools are limited and don’t yield nearly the gains of explicit concurrency control that you code yourself. The mainstream state of the art revolves around lock-based programming, which is subtle and hazardous. We desperately need a higher-level programming model for concurrency than languages offer today; I'll have more to say about that soon. Conclusion If you haven’t done so already, now is the time to take a hard look at the design of your application, determine what operations are CPU-sensitive now or are likely to become so soon, and identify how those places could benefit from concurrency. Now is also the time for you and your team to grok concurrent programming’s requirements, pitfalls, styles, and idioms. A few rare classes of applications are naturally parallelizable, but most aren’t. Even when you know exactly where you’re CPU-bound, you may well find it difficult to figure out how to parallelize those operations; all the most reason to start thinking about it now. Implicitly parallelizing compilers can help a little, but don’t expect much; they can’t do nearly as good a job of parallelizing your sequential program as you could do by turning it into an explicitly parallel and threaded version. Thanks to continued cache growth and probably a few more incremental straight-line control flow optimizations, the free lunch will continue a little while longer; but starting today the buffet will only be serving that one entrée and that one dessert. The filet mignon of throughput gains is still on the menu, but now it costs extra—extra development effort, extra code complexity, and extra testing effort. The good news is that for many classes of applications the extra effort will be worthwhile, because concurrency will let them fully exploit the continuing exponential gains in processor throughput.

Copyright © 2009 Herb Sutter

JSON

JSON (JavaScript Object Notation)은 경량의 DATA-교환 형식이다. 이 형식은 사람이 읽고 쓰기에 용이하며, 기계가 분석하고 생성함에도 용이하다. JavaScript Programming Language, Standard ECMA-262 3rd Edition - December 1999의 일부에 토대를 두고 있다. JSON은 완벽하게 언어로 부터 독립적이지만 C-family 언어 - C, C++, C#, Java, JavaScript, Perl, Python 그외 다수 - 의 프로그래머들에게 친숙한 관습을 사용하는 텍스트 형식이다. 이러한 속성들이 JSON을 이상적인 DATA-교환 언어로 만들고 있다.

JSON은 두개의 구조를 기본으로 두고 있다:

• name/value 형태의 쌍으로 collection 타입. 다양한 언어들에서, 이는 object, record, struct(구조체), dictionary, hash table, 키가 있는 list, 또는 연상배열로서 실현 되었다.
• 값들의 순서화된 리스트. 대부분의 언어들에서, 이는 array, vector, list, 또는 sequence로서 실현 되었다.

이러한 것들은 보편적인 DATA 구조이다. 사실상 모든 현대의 프로그래밍 언어들은 어떠한 형태로든 이것들을 지원한다. 프로그래밍 언어들을 이용하여 호환성 있는 DATA 형식이 이러한 구조들을 근간에 두고 있는 것은 당연하다.

JSON 에서, 이러한 형식들을 가져간다:

object는 name/value 쌍들의 비순서화된 SET이다. object는 { (좌 중괄호)로 시작하고 } (우 중괄호)로 끝내어 표현한다. 각 name 뒤에 : (colon)을 붙이고 , (comma)로 name/value 쌍들 간을 구분한다.

array은 값들의 순서화된 collection 이다. array는 [ (left bracket)로 시작해서 ] (right bracket)로 끝내어 표현한다. , (comma)로 array의 값들을 구분한다.

TCP/IP 관련 Internet 조직도

✓ Internet Society (ISOC): The Internet Society (www.isoc.org) guides the future of the Internet by overseeing Internet standards, public policy, education, and training. ISOC members include corporations, interna- tional and governmental organizations, and individuals. The Internet Activities Board (refer to third bullet), the Internet Engineering Task Force (refer to fourth bullet), and the Internet Research Task Force are all part of the ISOC.
 
✓ Internet Corporation for Assigned Names and Numbers (ICANN): The nonprofit corporation ICANN, at www.icann.org, is in charge of assign- ing Internet addresses. ICANN, pronounced “eye can,” is run by an inter- national board of directors and funded by the Internet community.
 
✓ Internet Activities Board (IAB): IAB, at www.iab.org, defines the architecture for the Internet. The IAB — just say its letters, “i-a-b” — also oversees the Internet’s protocols (TCP/IP). The IAB contains subcom- mittees of volunteers who set standards and work on new solutions to Internet growth problems.
 
✓ Internet Engineering Task Force (IETF): IETF, at www.ietf.org, is a community of more than 70 informal committees responsible for keep- ing the Internet up and running every day. The IAB supervises the IETF, which is pronounced simply “i-e-t-f.” You can join the IETF working groups to help draft and develop standards for TCP/IP protocols. 

여자들도 군대가야된다고 생각하는데 어찌생각하시는지

이스라엘 : 여자도 남자처럼 2년 6개월 군복무를 하고있다.

독일 : 여자가 군대에 직접 가진 않지만 여자가 국방세를 내서 군인들 월급을 준다. 

프랑스  : 군복무자들에게 다양한 혜택이 주어지는 프랑스는 남자들만 10개월간 복무하는 군대를 군인수요가 적어지면서 직업군인제로 전환했으나, 대신 현행 "소집"제도는 존속시킬 것임을 발표했다. 이 같은 소집제도가 남성에게만 적용됐지만, 2002년부터 소집제도가 남녀모두 적용돼서, 남성은 물론 여성도 징집대상에 적용된다고 한다.

대만 : 여자는 국방세를 내고, 1년간 의무적으로 지정노동현장에서 저임금 노동을 한다. 

스위스 : 입대시 4개월의 군사훈련을 받고, 나머지는 예비군 훈련을 받으며, 예비군 훈련으로 인한 수입의 불이익을 나라와 직장에서 반반씩 물어준다. 시민권의 근본인 이른바 시민군제도가 군대로부터 여성을 배제하는 것뿐만 아니라, 결국 사회 속에서 여성을 차별하는 기본적인 제도라 비판하며, 스위스 여성계에서 남녀모두 의무적으로 군복무를 해야한다며 강하게 주장한 한편, 여군 사령관으로 임명된 오이제니 폴락이란 여성은 사정이 허락한다면 현 병역제도가 모든 여성들에게도 의무화되어야 한다고 주장했다. 

스웨덴 : 남자만 8개월간 월30만원을 받으며 군복무를 했지만, 2000년도에 정부에서 남녀공동 병역의무제를 도입하자고 제안하였고, 지금까지도 논의가 진행중이라고 한다. 남녀 평등한 병역의무를 위한 의도 및 해외파병에 따른 방어병력의 부족과 출산율 저하로 인한 징병 대상 감소가 원인으로 추정된다.

태국 : 여자가 국방세를 내서 군인들 월급을 준다.

에리트레아 : 여자도 남자처럼 1년 6개월 군복무를 하고있다. 

말레이시아 :  2004년부터 지원병제도에서 남녀공동 병역의무제로 전환을 하였다. 남녀모두 18세가 되면 6개월간 군복무를 해야한다. 

수단 :  최근 여성에게도 병역의무를 부과하는 병역제도가 마련되었지만, 아직까지 새 법령을 시행하지 않고 있다. 앞으로 수단에서는 남녀모두 평등하게 병역의 의무를 이행하게 된다. 

쿠바 : 여자도 남자처럼 3년 군복무를 하고있다.

베냉 : 남여 공동병역제를 실시하고 있다. 

북한 : 여자도 남자처럼 3년 군복무를 하고있다.

한국 : 아무 의무없음. 부사관과 장교로만 입대한다.