Coding Convention

Posted 2006. 11. 21. 00:46
C/C++ 언어로 프로그램을 작성하다 보면 가장 힘든 일이 코딩 표준(coding standard)를 지키는 일이다. 프로젝트에 투입된 개발자가 두 명만 되도, if, for, while 등의 키워드 뒤에 괄호 "("는 공백을 하나 넣을지 말지 등 미묘한 문제에 일일이 합의를 봐야 하고, 가끔은 소모적인 논쟁을 해야 한다.

C/C++ 코딩 시 외부 코드를 가져와서 내 소스 트리에 녹여 넣을 때는 가장 먼저 고민하는 일은 코딩 표준을 맞출 것인지그대로 두고 사용할 것인지에 있다. 물론 이 과정을 자동으로 해주는 자동 리포매터(reformatter)들이 많이 있고, 다양한IDE가 이를 지원하지만 리포매터에 내 코딩 표준을 지정해주는 것도 결코 쉽지 않은 일이다.

자바가 C/C++보다 편한 아주 사소한 이유 중에 하나는 자바는 썬에서 밀고 있는 자바 코딩 표준(Java Coding Convention)를 준수하는 경우가 많고, 여기서 크게 벗어나는 변종이 많지 않다는 점일 것이다. 파이썬의 경우 블록의 시작이 { }와 대신에 공백 문자(white space)이고, 코딩 표준이 거의 하나로 통일되어 있다는 면에서 더 편안한 느낌을 준다.

JavaSpaces의 디자이너인 Ken Arnold는 Style is Substance라는 블로그 글에서 공백과 코딩 스타일까지 모두 언어 문법으로 처리해서 코딩 표준을 안 따르면 컴파일 에러로 처리하자는 다소 급진적인 주장을 한 바가 있는데, 이 생각에 100% 공감하는 바이다.

자바 보안 안티패턴(antipattern)

Posted 2006. 11. 20. 23:54
오랜만에 포스팅합니다. 블로그에 글을 안 쓰는 것도 관성이 있는지 한 번 쉬기 시작하니깐, 계속 쉬게 되는군요.

12월 마소 원고 마감이 다가와서, 오늘 또 열심히 달렸습니다. 12월 호의 주제는 "자바 보안 프로그래밍"입니다. 흔히 C/C++ 프로그램에만 보안 문제가 있을 것이라고 생각하는데, 자바 프로그램도 C처럼 버퍼 오버플로나 포맷 스트링 버그는 없어도 다른 유형의 보안 문제들이 존재하고 있습니다. 실제로 자바원(JavaOne) 2006에서 Secure Coding Antipatterns: Avoiding Vulnerabilities라는 세션이 열리기도 하였습니다.

이번 마소 원고는 이 자바원 세션에 소개된 예제를 중심으로 자바 프로그램에는 어떤 보안 문제가 있고 어떻게 해결해야 할지를 다루고 있습니다. 사실 새로운 이야기는 별로 없고, 주로 자바원에서 다루었던 내용을 조금 더 상세히 설명하는 방식으로 했습니다.

자바 보안 안티패턴

[1] 객체가 불변(immutable)한다고 가정한다.
[2] 신뢰하지 못하는 출처(source)에 기초하여 보안 검사를 한다.
[3] 슈퍼 클래스의 변화를 무시한다.
[4] 입력 값 검사(input validation)를 하지 않는다.
[5] public static 필드를 잘못 사용한다.
[6] 생성자에서 발생한 예외(exception)가 객체를 파괴할 것이라 믿는다.

각각의 자세한 내용은 마소 12월 호에서 만나요 :) 미리 궁금하신 분은 웹으로 제공되는 자바원 세션을 직접 들어보시면 됩니다.

An Introduction to Software Engineering

Posted 2006. 11. 8. 00:07
'컴퓨터공학소개' 수업에서 소프트웨어 공학(Software Engineering)에 대한 소개를 했습니다.




구성은 크게 2 가지로 나누었습니다.

1. 소프트웨어 공학이 왜 필요한가?
2. 소프트웨어 공학이란 무엇인가?

짧은 시간(20분)에 1학년 학생들을 기준으로 소프트웨어 공학이란 분야를 설명하려니, 생각보다 어렵더군요. 내용 중에 보면 소프트웨어 크기가 증가함에 따라 중요한 학문의 범주(dominant discipline)가 바뀐다는 말이 있습니다(Stu Feldman).

10^3 Mathematics
10^4 Science
10^5 Engineering
10^6 Social Science
10^7 Politics

코드가 10^7, 즉 천 만 줄을 넘어가면 소프트웨어는 정치가 된다 말은 일종의 '농담'이면서 '진실'이기도 합니다. 10^8이 넘어가면 무엇일 될까요?

Static Analysis for Security

Posted 2006. 11. 7. 15:56
포항공대유닉스보안연구회(PLUS) 정기 세미나용으로 정적 보안 검사 도구에 관한 발표 자료를 만들었습니다. 보안 검사 도구인 ITS4를 만든 Cigital 사의 Static Analysis for Security라는 글을 참고로 하였습니다.




정작 보안 검사 도구는 정적 검사(static analysis) 기술을 응용해 실행 없이 소소 코드만 분석해서 잠재적인 보안 위협을 잡아내는 도구입니다. 패턴이 널리 알려진 취약점의 경우 보안에 대한 전문 지식 없이도 손쉽게 자동으로 검출할 수 있다는 장점이 있습니다.

여기서 소개하는 도구는 다음과 같습니다. C/C++을 이용해서 시스템 프로그래밍을 작성하시는 분이라면 관심을 가지시면 좋을 듯 합니다.

- Boon
- CQual
- xg++
- Eau Claire
- MOPS
- Splint

/proc 파일 시스템

Posted 2006. 11. 6. 20:51
리눅스 커널에 새로운 기능을 추가로 구현할 경우, 이 기능을 유저 프로그램이 이용할 수 있게 만들기 위해서는 인터페이스를 열어주어야 한다. 커널이 유저 프로그램에 인터페이스를 제공하는 방법에는 크게 2가지가 있는데,

(1) 커널 시스템 콜 테이블에 엔트리를 추가하여, 새로운 시스템 콜을 만들어준다.

(2) /proc 파일 시스템을 통해 데이터를 주고 받을 수 있는 창구를 열어준다.


전통적으로 리눅스를 비롯한 UNIX에 새로운 커널 기능을 추가하는 방법에는 (1)과 같이 새로운 시스템 콜을 사용하는 방식이 선호되었다.  모든 시스템에서 사용하는 범용적인 기능이라면, 시스템 콜을 추가하여 모든 유저 프로그램이 이용할 수 있도록 하는 것이 맞을 것이다. 이 방식을 사용하려면 시스템 콜을 호출해주는 유저 라이브러리가 수정된 커널과 함께 배포되어야 한다.

하지만 (1)번 방식의 경우 플랫폼이 달라지면, 유저 라이브러리도 변경되어야 하는 불편함이 있다. 왜냐하면 시스템 콜을 호출하는 소프트웨어 트랩(software trap)의 구현이 아키텍처마다 다르기 때문이다. 어떤 아키텍처에서는 int 80h가 커널 모드로 진입하는 명령인데 비해서, 전혀 다른 명령을 쓰는 아키텍처도 있다. 문제는 C 언어 레벨에서는 커널 모드로 진입하는 트랩을 발생시킬 수 없다는 점이다. 따라서 새로운 플랫폼이 추가될 경우 시스템 콜을 호출하는 라이브러리를 추가로 작성해 주어야 한다.

따라서 리눅스 커널 모듈의 경우, 시스템 콜을 추가하는 방식보다 /proc 파일 시스템에 읽고 쓸 수 있는 파일을 생성하여 커널과 데이터를 주고 받는 방법을 선호한다. /proc에 있는 파일을 통해 유저 프로그램은 파일 쓰기를 통해 커널에 데이터를 전달할 수 있고, 파일의 내용을 읽어서 결과를 전달받을 수 있다. 이 방식은 모든 플랫폼에서 호환 가능하기 때문에 (1)의 시스템 콜 추가 방식과 달리 플랫폼 간 호환성이 보장된다.

proc 파일 시스템을 이용하는 방법은 "The Linux Kernel Module Programming Guide" Chapter 5. The /proc File System를 참고하자.

Good Ideas, Through the Looking Glass

Posted 2006. 11. 3. 15:01
"Good Ideas, Through the Looking Glass"는 파스칼, 오베론(Oberon) 언어의 아버지인 Niklaus Wirth(1984년 Turing Award 수상자이기도 합니다)가 Computer Science 역사에 등장한 여러 가지 아이디어를 뒤집어보면서 작성한 글입니다. 특히 Wirth의 전문 분야인 컴퓨터 아키텍처, 프로그래밍언어 등을 중심으로 서술하고 있습니다.

Wirth는 스위스 연방공대(ETH)를 중심으로 발달한 파스칼 계열 프로그래밍 언어의 거두라고 할 수 있는데, 의외로 "함수형 언어"에 대해서는 큰 회의를 가지고 있습니다. 그의 논리는 State의 중심의 현대 컴퓨터 아키텍처에서, Stateless한 함수형 언어는 필연적으로 구현이 까다롭고 직관적이지 못하다는 것입니다. Stateless한 함수형 언어가 State한 아키텍처 위에서 구현되다 보니 편법을 동원한 복잡하고 까다로운 개념들이 등장할 수 밖에 없다는 거죠.

가비지 콜렉션은 자바, C# 등에 사용되면서 요즘은 명령형 언어에도 일반화되었지만, 원래는 함수형 언어의 전매 특허 같은 것이었습니다. Wirth에 따르면 가비지 콜렉션은 새로 계산한 값을 기존 변수에 대입하지 못하고 계속 새로운 메모리 공간에 저장해야 하는 함수형 언어의 태생적인 구조로 인해 필수 불가결한 요소가 되었다고 합니다. 즉 함수형 언어에 가비지 콜렉션이라는 멋진 개념을 추가한 것이 아니라, 함수형 언어이기 때문에 가비지 콜렉션을 추가할 수밖에 없었다고 보는 것이 맞다는 거죠.

함수형 언어의 기여로는 '함수형'이라는 특징보다는 'Nested Structure'가 더 중요했다고 이야기하고 있습니다. 그 외에 Concurrency에 대해서도 Side-effect가 없는 함수형 언어가 유리할 수도 있지만, 궁극적으로는 객체지향 언어가 더 유리할 것이라는 전망을 하고 있네요.

Single Assignment

Posted 2006. 10. 30. 10:10
함수형 언어(functional language)처럼 변수에 값을 한 번만 대입할 수 있는 언어를 Single Assignment하는 언어라고 부른다. 대표적인 언어로는 Erlang, Haskell, SISAL 등이 있고, 컴파일러가 최적화를 위해 쓰는 언어 중간 언어인 SSA(Static Single Assignment)도 이름에서 알 수 있듯이 Single Assignment 하는 언어이다. 이들 언어의 특징은 사이드 이펙트(side effect)가 없기 때문에 여러가지 컴파일러 최적화에 유리하다는 점이다. SSA를 사용하면 다음 컴파일러 최적화가 가능하다(혹은 더 쉬워진다).

Static Code Analysis

Posted 2006. 10. 29. 23:36
IEEE Software에 Panagiotis Louridas가 기고한 [Static Code Analysis]라는 글을 읽었습니다. 이 글은 Static Checker의 사용을 권장하고 있습니다. Static Checker란 프로그램을 수행하지 않고 코드나 바이너리를 읽어서 개발자들이 흔히 하는 실수를 자동으로 잡아 주는 프로그램을 말합니다. 이 글에 언급된 것처럼 자바의 경우는 FindBugs, PMD, CheckStyle 등의 프로젝트가 유명한데, 이미 많은 개발자들이 사용하고 있는 것 같더군요. Klockwork라는 프로그램은 저도 처음 들어봤는데, 비슷한 기능을 하는 상용 도구로 언급하고 있습니다.

저 역시 예전에 마소에 FindBugs를 소개한 적이 있습니다. 메릴랜드 대학(Univ of Maryland)에 교환학생을 갔을 때, 제가 들었던 과목의 교수가 FindBugs를 만든 Bill Pugh 교수님이었거든요. 수업 시간에 자연스럽게 FindBugs의 사용을 권장해서 그때 정적 프로그램 분석(static program analysis)의 매력에 빠졌는데, 이후로 줄곧 관심있게 지켜보는 주제가 되었습니다.

프로그램 분석은 간단히 말해서 프로그램을 실제로 수행시켜 보기 전에 프로그램의 여러 성질을 파악해서, 버그가 있는지 없는지를 판별해 내는 기술이다. 우리가 버그를 찾아내기 위해 흔히 사용하는 기술인 테스팅은 런타임에만 버그를 찾을 수 있다. 하지만 테스팅이 모든 프로그램 수행 경로를 실행시켜 보는 것이 불가능하기 때문에 버그를 찾아내는데 한계가 있는 반면에, 프로그램 분석은 프로그램을 실제로 실행시키지 않으므로 탐지 가능한 모든 버그를 찾아낼 수 있다.

마이크로소프트웨어 2006년 4월호 [버그 잡기. 프로그램 분석 도구를 이용하자.] 서광열

전화 면접(Phone Interview)

Posted 2006. 10. 26. 17:21
그동안 중간 고사 기간이라 정신이 없어서 포스팅을 못했습니다.

오늘 메일로 날라온 조엘 온 소프트웨어 글을 보니 [The Phone Screen]이라는 글이 올라왔더군요. 회사가 채용 공고를 내면 정말 똑똑하고 많은 경험을 한 멋진 개발자의 이력서들이 산더미처럼 몰려오는데, 실제로 만나보면 형편 없는 경우가 많다는 겁니다. 개발에 쏟아야 할 귀중한 시간을 이런 엉터리 지원자들에게 쏟으면 아까우니깐, 일단 전화 면접을 통해 기본적인 사항을 확인하자는 거죠.

최근에 취직 준비를 하면서 두 회사에 지원했는데, 우연치 않게 두 회사 모두 전화 면접이 있었습니다. 썬 마이크로시스템즈에는 자바 VM 엔지니어로 지원했는데, 1차로 서울 썬 오피스에서 면접을 본 후에 이스라엘에 있는 CLDC 제품의 매니저와 전화로 2차 기술 면접을 하더군요. 전화 면접은 30-40분 정도 진행이 되었는데, 생각보다 간단한 내용들을 위주로 물어봤습니다. TCP와 UDP의 차이점은 뭐냐, malloc()과 free()에 메모리 사용량을 측정하는 코드를 삽입하려면 어떻게 하겠느냐 등이었죠.

또 한 회사는 일본에 있는 DMP라는 임베디드 시스템용 그래픽스 칩을 개발하는 회사입니다. (최근에 ohhara님이 KLDP에 소개글을 올렸습니다.) 이 때도 전화 면접을 했는데, DMP 쪽에서는 사장님과 여러 엔지니어들이 함께 배석을 했습니다. 일반적인 질문들을 하다가 기술 면접에 들어가서는 링크 리스트(linked list)에서 중간에 있는 값(middle element)를 찾는 가장 빠른 방법을 말해보라고 하더군요. (정답은 여러분들도 생각해보세요.) 

개인적으로 전화 면접은 좋은 아이디어라고 생각합니다. 특히 일본에서 한국 개발자를 뽑는 경우 비행기 표와 호텔 비 등 상당한 비용을 지불해야 하는데, 간단한 전화 한 통으로 바보 개발자를 골라낼 수 있다면 상당한 비용 절감 효과가 있는 거겠죠. 물론 지원자들도 이에 발맞추어 변화할 겁니다. 전화 면접이 일반화되면, 앞으로 전화 인터뷰 잘하는 법에 대한 강의도 생겨나겠죠?

지름신 강림! 책 구입.

Posted 2006. 10. 22. 01:36
요즘 스트레스 받아서 "인터넷 쇼핑"을 해버렸습니다. 아마존 Wish List에 있던 책들 중에서 일부를 구매해 버렸습니다.

"Model Checking" Edmund M. Clarke;

"Software Requirements, Second Edition" Karl E. Wiegers; Paperback;

"The Best Software Writing I: Selected and Introduced by Joel Spolsky" Joel Spolsky; Paperback;

"Wicked Cool Java: Code Bits, Open-Source Libraries, and Project Ideas" Brian D Eubanks; Paperback;

"Classic Set Theory" D.C. Goldrei; Paperback;


"Program Analysis"나 "Model Checking" 쪽은 틈틈이 공부해 두려고 하는데 계획대로 될지 궁금하군요 :) 어쨌든 일단 질러놓고 봅니다.

동적 타이핑에 대한 오해

Posted 2006. 10. 21. 04:13
블로그에 몇 번 글을 남겼던 "동적 타이핑에 대한 오해"를 주제로 이번달 마이크로소프트웨어 "스텝 바이 스텝" 원고를 마무리 지었습니다.

근래에 파이썬, 루비를 비롯한 스크립트 언어가 인기를 얻으면서, 동적 타이핑(dynamic typing)이라는 개념도 주목을 받고 있다. 동적 타이핑은 자바, C/C++처럼 컴파일 타임에 타입 검사를 수행하는 정적 타이핑(static typing)과는 달리, 프로그램을 실행하는 런타임에 타입 검사를 수행한다. 덕분에 이런 언어들은 타입 선언이 필요 없는 간결한 문법이 특징인 경우가 많다. 생각보다 많은 개발자들이 동적 타이핑에 대한 환상을 가지고 있는데, 이 글에서는 스크립트 언어에 얽힌 동적 타이핑에 대한 오해를 풀어보려 한다.

오해1: 동적 타이핑은 테스트 주도 개발(TDD)에 유리하다?
오해2: 동적 타이핑은 코드 중복을 줄인다?


마소 11월 호를 참고하세요 ^^ (상당 부분의 글은 제 블로그에 있는 내용을 수정해서 사용했습니다.)
Tiobe Software는 코딩 표준을 지키는지 확인해주는 도구로 돈을 버는 회사다. 이런 종류의 일로도 돈이 될까 싶은데, 어쨌든 멀쩡히 회사가 잘 돌아가고 있으므로 신기할 따름이다. 이 회사는 매달 프로그래밍 언어의 순위를 매겨 발표하는 것으로도 유명한데, TPC 인덱스라는 지표를 이용해서 순위를 계산한다. 또 순위에 따라서 언어에 A, B,C 등으로 등급도 매기는데 A 등급은 주류 언어라고 분류한다. 얼마 전에 루비가 A를 받으며 주류 언어에 편입했다고 자랑하는 것을 본 것 같다.

Design by Contract의 문제점

Posted 2006. 10. 20. 16:04
현재 DbC 도구나 언어는 계약 관계를 표현하는 방법이 쉽지만은 않다. 간단한 예제들은 이진 표현(예를 들어 a >= 0.0)으로 간단하게 필요한 조건을 표현할 수 있었지만, 실제 프로젝트를 적용해 보려고 하면 생각보다 다양한 상황을 표현할 수 있는 방법이 필요함을 알 수 있다. 예를 들어 배열로 넘어온 인자에서 모든 값이 0보다 커야 한다던지 하는 경우 지금의 DbC 도구들로 표현하기가 어려운 면이 있다.

사실 계약에 사용되는 언어는 또 다른 프로그래밍 언어인 셈이다. Contract4J의 경우도 @Pre, @Post, @Invar 등에 사용되는 언어는 자바와 유사하지만 자바와는 또 다른 계약을 표기하기 위한 언어이다. $return이나 $old 같이 특수한 값을 지정할 수도 있어야하고, 계약 언어 특유의 요구 사항에 따라 자바 언어와는 다른 여러 가지 기능을 지원할 수도 있어야할 것이다.

이런 계약 언어가 아직까지는 초기 단계이기 때문에 표현력이 많이 떨어지는 편이다. 현재 UML의 OCL(Object Constraint Language)를 계약 언어로 사용하기 위한 노력들이 있는데, 관련 도구들이 발전한다면 앞으로의 상황은 점점 나아질 것이다. 하지만 금으로서는 DbC 언어의 한계가 사용에 걸림돌이 되는 것만은 사실이다.

Java SE 6의 테마

Posted 2006. 10. 20. 11:09
호환성(compatibility): 자바는 이미 성숙한 플랫폼이기 때문에 하위 호환성을 깨뜨리는 변화에 대해서 극도로 민감하다. 이미 많은 벤더들이 크든 작든 자바 플랫폼에 많은 투자를 하고 있기 때문에, 새로운 자바 플랫폼이 이전 환경과 호환되지 않는다면 막대한 규모의 경제적 손실이 발생할 것이다. 실례로 Java 5에 Generics를 추가하는 여러 가지 대안 중에 가장 효율적인 방법은 아니었지만 JVM을 전혀 수정하지 않는 대안이 선택된 바 있다.

개발의 편의(Ease of Development): Java 5의 Generics나 어노테이션(annotation)은 개발의 편의를 위한 지원이라 볼 수 있다. 이와 관련된 Java 6의 항목은 스크립트 언어 지원, 쉬운 데이터베이스 접근, 소스 코드 컴파일, 어노테이션 처리, GUI 디자인 도구 등을 들 수 있다.

진단, 모니터링, 관리(Disposability, Monitoring & Management): Java 5에 포함되었던 JMX(Java Management Extension)이나 JVMTI(Java Virtual Machine Tool Interface) 등이 여기에 해당한다. 특히 JVMTI는 기존의 디버깅 인터페이스(JVMDI)와 프로파일링 인터페이스(JVMPI)를 통합해서 하나로 만들어서, 다양한 자바 개발 도구 작성에 도움을 주고 있다. 여기에 디버깅 플래그 없이 시작된 어플리케이션의 진단이나, 현재 수행 중인 자바 어플리케이션의 힙 메모리를 살펴볼 수 있는 기능 등이 추가적으로 필요할 것이다.

기업 환경 데스크톱(Enterprise Desktop): 최근에는 웹브라우저 기반의 가벼운 클라이언트(thin client)가 가지는 한계 때문에 리치 클라이언트(rich client)가 다시 주목을 받고 있다. 현재 자바는 네이티브 데스크톱 환경과의 통합이나 텍스트 출력, 테이블 표시 및 조작 등의 기능이 부족한 상태이다.

XML과 웹 서비스: 원래 자바 5에서 웹 서비스 관련 클라이언트 스택을 모두 제공할 예정이었는데, 릴리즈 시간을 맞추지 못하고 제외된 바가 있다. 그 사이에 XML과 웹 서비스에 관련된 요구 사항은 더욱 커졌는데, 자바 6은 이러한 요구사항을 반영하고 있다.

투명성(transparency): Java 5까지 자바 플랫폼의 개발 과정을 보면, 썬이 작업을 끝마칠 때까지 어떤 식으로 구현되는지에 대한 내용을 전혀 알 수가 없었다. 반대로 자바 6 이후부터는 이러한 명세서(specification) 작성과 참조 구현(reference implementation) 개발 과정에 투명성을 주었다. 현재도 자바 개발 사이트에서 자바 6의 JDK를 다운받아 설치하고 실행해 볼 수 있다.
자바 6에 포함된 가장 큰 변화 중에 하나는, 클래스 파일의 포맷을 일부 변경하였다는 점이다. 이 변경은 “Split Verification”이란 개념을 지원하기 위해서이다.

현재 자바 클래스 파일을 JVM이 로딩할 때는 올바른 클래스 파일인지 검증하는 과정을 거친다. 그런데 클래스 파일 검증은 상당한 시간이 걸리고 메모리 자원도 많이 요구하는 프로세스이므로, Java ME 같이 리소스가 제한된 환경에서는 클래스 파일 검증 자체가 힘들어지는 경우가 종종 있었다. 그래서 Java ME를 사용하는 일부 플랫폼은 클래스 파일 검증 기능을 사용하지 않는 경우도 생겼는데, 이렇게 하면 성능은 향상되어도 심각한 보안 문제를 초래할 수 있다.

Java ME(CDC, CLDC)는 이에 대한 대안으로 클래스 파일을 생성한 쪽에서 일부 검증을 미리해서 보낸 후에, 클래스를 로딩하는 쪽은 간단한 계산만으로 클래스 파일이 안전하다는 것을 증명할 수 있게 만들었다. 원래는 JVM 쪽에서 모두 해야 할 검증의 임무를 분담했다는 점에 착안하여 이러한 검증 과정을 "Split Verification"이라고 부른다. Java 6에서는 "Split Verification"을 SE에서도 지원하기 위해 클래스 파일 포맷을 일부 수정하는 작업을 한 것이다.

OCaml 공부를 위한 참고 자료

Posted 2006. 10. 19. 02:35
OCaml 언어 공부를 위한 참고 자료입니다. 앞으로 지속적으로 갱신하려고 합니다.

* Objective CAML Tutorial
http://www.ocaml-tutorial.org/

소프트웨어 원칙

Posted 2006. 10. 19. 01:22
구글 홈페이지에 가보면 소프트웨어 원칙을 게재해 두었습니다. 구글이 소프트웨어를 작성할 때 따르는 길잡이인 셈인데, 다음과 같은 항목이 있습니다.

1. 설치
2. 사전 공개
3. 간편한 제거
4. 명백한 행위
5. 스누핑
6. 건전한 프로그램 제공

간단히 요약하면, 사용자를 속여서 은근슬쩍 프로그램을 설치하고서는 지우지도 못하게 만드는 프로그램을 만들지 말라는 뜻입니다. 또한 동의도 없이 사용자의 컴퓨터 자원을 남용하는 행위도 하지 말라고 권고하고 있습니다.

물의를 빚었던 네이버의 터보 플레이어나, 동의 없이 사용자의 컴퓨터/네트원 자원을 은글 슬쩍 사용하는 각종 파일 다운로드 사이트 등을 볼 때 안타까운 마음이 듭니다. 사용자가 바보가 아닌 이상 그런 문제가 생기면 이미지에 상당한 타격이 갈 텐데 말이죠.

샵 가이드(Shop-Guide) 프로그램처럼 소리 소문 없이 깔려있는 프로그램을 보면 울화통이 치미네요.

구글 코드 서치(Google Code Search)

Posted 2006. 10. 18. 18:12
최근에 구글에서 웹 상에서 공개된 코드를 검색해주는 서비스인, 코드 서치(Code Search) 서비스를 오픈했습니다. 원래 의도는 당연히 개발자들이 필요한 코드를 쉽고 빠르게 검색하여, 생산성을 올릴 수 있게 도와주는 것일 겁니다. 코드 검색은 프로그래밍 언어를 대상으로 하는 만큼, 자연어와 달리 정규 표현식(Regular Expression)을 이용해서 검색이 가능합니다.

하지만 최근에 해커들이 보안 취약점을 찾는 방법으로 코드 서치를 많이 활용하고 있다네요. 취약한 코드의 패턴을 정규식으로 만들어 구글 코드 서치에 돌리면, 해당 버그를 가지고 있는 코드들이 대량으로 검출되는 세상이 되었습니다. 최근에 본 블로그 글인 "Google Code Search ~= Hacker's best friend?"에 관련 내용이 좀 있으니 관심 있는 분들은 보시기 바랍니다.

허무한 논쟁들.

Posted 2006. 10. 16. 12:51
소프트웨어 개발도 공학(engineering)인 만큼 상황에 따라 적절한 도구와 방법을 사용해야 함이 자명하지만, 아직도 많은 사람들은 자기만의 도그마(dogma)에 빠져서 필요 없는 논쟁에 시간을 쓰는 것이 아닌가 싶다. 인터넷에서 만나는 프로그래밍 언어나 플랫폼을 놓고 벌이는 논쟁의 대부분은 수준 이하의 투덜거림에 지나지 않는다. 이미 수십 년 전에 프레드릭 브룩스(Frederick P. Brooks, Jr.)가 "No Silver Bullet: Essence and Accidents of Software Engineering"에서 남긴 교훈이 받아들여질 날은 멀기만 한 걸까?

I believe the hard part of building software to be the specification, design, and testing of this conceptual construct, not the labor of representing it and testing the fidelity of the representation.

qmake

Posted 2006. 10. 16. 10:29
make 프로그램을 사용하면서 느낀 불편함 중에 하나는 사용이 쉽지 않다는 것이다. 간단한 어플리케이션 하나 컴파일하기 위해서도 복잡한 makefile 룰이 필요한 경우가 종종 있다. makefile은 또한 가독성이 떨어져서 남이 만들어놓은 makefile을 읽고 원하는데로 수정하기란 쉬운 일이 아니다.

프로그램이 윈도우즈와 유닉스 등 두 가지 이상의 환경에서 수행되도록 작성되어 있다면, makefile의 복잡도도 그만큼 올라가기 마련이다. 하지만 대부분의 경우, 라이브러리(CFLAGS, LIBS)를 지정하고 소스, 헤더 파일만 원하는대로 포함시킬 수 있으면 된다. 플랫폼에 따라서 몇 개 정도 파일이 바뀌는 것이 전부이다.

이런 요구사항을 쉽게 작성한 후에, 유닉스에서는 makefile, 윈도에서는 Visual Stduio Project 파일을 자동으로 생성할 수 있으면 좋겠다는 생각을 했는데, QT의 qmake가 비슷한 일을 이미 해주고 있었다. qmake 룰에 대한 특별한 설명 없이도 다음 룰을 보면 쉽게 이해할 수 있다.


    CONFIG += qt debug
    HEADERS += hello.h
    SOURCES += hello.cpp
    SOURCES += main.cpp
    win32 {
  SOURCES += hello_win.cpp
    }
    unix {
  SOURCES += hello_unix.cpp
    }
    !exists( main.cpp ) {
  error( "No main.cpp file found" )
    }
    win32:debug {
  CONFIG += console
    }
« PREV : 1 : ··· : 7 : 8 : 9 : 10 : 11 : 12 : 13 : NEXT »