리눅스용 Monaco 폰트

코딩할 때는 고정폭 폰트를 써야 한다.
반드시 그래야 하는 것은 아니고, 이런저런 이유로 고정폭 폰트를 쓰는 것이 낫다.
그런데 고정폭 폰트 중에는 마음에 드는 것이 별로 없다.

맥을 사용하기 전에는 Verdana 를 쓰기도 했었는데 이는 고정폭 폰트가 없다. Verdana 이면서 고정폭인 것은 없나 찾아봤는데 없었다. 어쩌면 고정폭으로 바꾸었을 때 보기 싫을 수도 있겠다 하고 애써 외면하면서, 그나마 가장 나았던 bitstream mono 를 사용했었다.

그러다가 맥을 사용하면서, 맥에서 고정폭 폰트로 기본 지정된 Monaco 가 참으로 괜찮다는 생각이 들었는데 맥만 사용하다 보니까 뭐 다른 데서 포트 찾을 일이 없었다.

맥이 사라지고 ubuntu 를 갖고 놀기를 하세월, 그냥 비트스트림 정도로 만족하다가 문득 심술이 나서 폰트좀 바꿔보려 했는데 다 마음에 안 든다.
혹시 모나코 없나 싶어 찾아봤다니... 2006년에도 있었던 것 같다. 혹은 그 이전에도.

http://www.gringod.com/2006/11/01/new-version-of-monaco-font/

위 링크에서 받을 수 있다.

Acer Aspire 5349: 압도적으로 저렴한 노트북

집안 어르신들의 PC 및 노트북을 갈아 드려야 할 때가 되어서 얼마 전 부터 가끔 고민을 해 오다 조금 더 비싸더라도 이래저래 노트북이 나을 것이라 생각하고 본격적으로 날을 잡아 적당한 제품을 찾아 보았다.

어느날 부터인가 나조차도 무슨 CPU가 어떠한지 전혀 모르게 되었다. 한때는 최고 사양의 부품만을 찾아 조립하고 했었는데 이제는 그냥 적당히 돌아가기만 하면 된다 주의다. 사실 지금은 맥북을 쓰고 있으니 그런 고민조차 안 하긴 하지만.

어른들 것을 마련하려 할 때에도 '사양이 처지지 않는' 것을 택하려 했지만 몇 년 전 부터 아톰 계열 CPU가 달린 제품을 써 본 후로는 생각이 많이 달라졌다. 웬만한 작업을 하는데 있어서 CPU 사양이 그렇게 좋을 필요가 없음을.

이것저것 찾아봤더니 생각했던 예산보다 낮은 금액대에서 몇 가지 제품이 눈에 띄었다. 역시 CPU는 AMD 라던가 몇 세대 이전인 코어듀오 이런 것들이다. 그래도 어쨌거나 듀얼 CPU라니 문제는 없을 것 같았다. 그러다 눈에 띈 것이 Acer 제품이었다. 셀러론이지만 가장 최근의 코어 아키텍처를 적용한 CPU를 쓴다(고 읽은 것 같다). 게다가 메모리는 4G, HDD 는 5400RPM 이지만 500GB 짜리다. 요즈음 말레이시아 홍수 때문에 HDD 가격이 폭등했다던데, 이 제품은 아직까지는 그 영향에서 자유로운가 보다.

화면은 15인치라 어른들이 보기에는 오히려 좋을 것 같다. 해상도는 요즈음 표준인 1366x768인데 화면 크기에 비해 낮은 해상도인 듯 하지만 이게 또 어른들 보시기에는 오히려 장점으로 다가온다. 15인치짜리 크기이다 보니 무게는 아무래도 2kg이 넘어 휴대성이 안 좋지만 어른들이 휴대할 리도 없고 집안에서만 쓴다 해도 거추장스럽게 이것저것 늘어놓지 않아도 되니 주위가 지저분해지지 않는 장점이 있다.

가장 중요한 것은 가격인데 나름 이 정도 사양이면서 40만원에 못 미치는 돈으로 구할 수 있다. 요즈음 조립 PC를 얼마에 구성할 수 있는지 전혀 모르지만 그래도 매우 바람직한 가격이라는 느낌이 든다. 불과 2년 전만 해도 '저가형' 노트북이 60~70만원대 였던 것 같으니.

10년 전에 비해 물가는 무지막지하게 올랐으니 물가상승률을 감안하면 당시 노트북 가격에 비해 지금은 얼마나 내린 것인가? 물론 여전히 고사양 노트북은 100만원대 중반을 넘어가지만 최하 100으로도 구하기 어려웠던 시절을 감안하면 지금 노트북은 정말 싸졌다.

게다가 내장 ODD 는 DVD-R 도 아닌 RW 다. 뭐, 이것도 부품 자체가 싸졌기에 그럴 수 있는 것이라면 별로 놀랄 만한 대상이 아니려나.

요즈음에야 검색으로 얼마든지 정보를 취할 수 있으니 제품에 대한 자세한 내용을 시시콜콜히 적을 필요는 없을 것 같다.

15인치다 보니 상당히 큰 느낌이다. 비교해 놓을 것을 같이 찍어놓지 않으니 감이 안 오는데 사실 밑에 깔아놓은 벨킨 패드로 비교를 할 수는 있다. 보편적인 제품이 아니긴 하지만.

가격이 저렴한만큼 마그네슘 합금 뭐 그런 것을 썼을 리가 없고 상판 하판 공히 플라스틱이다. 하판이야 그렇다 쳐도 저가형 노트북들은 상판이 실망스러웠던 경우가 많은데 이 제품은 상당히 무난한 느낌이다. 물론 취향 문제이긴 하지만 충분히 보편적으로 그렇게 느낄 만 한 마감이다.

가격이 싼 이유 중 하나는 M$ 윈도우가 빠져 있기 때문인 것도 한몫 할 텐데 노트북 사자마자 리눅스를 설치하는 나로서는 상당히 만족스러운 부분이다. 하지만 어른들은 윈도우를 써야 해서 Win7을 깔았는데 OS 비용은 고려해 봐야 할 것이다.

제품 자체에 4GB 메모리 모듈이 들어 있는 것은 아니고 2GB 모듈을 별도로 제공하는 것 같다. 따라서 구매서 구매처에서 설치해 보낼거냐 직접 할 거냐를 선택하게 되어 있었는데 항상 그래 왔듯이 직접 하겠다고 했다. 속을 보고 싶은 욕심도 있었고.
그런데 이게 메모리 업그레이드 등 뭔가를 바꾸기 위해 분해하는 것은 상당히 괴롭다. 하판의 나사 24개인가를 풀어야 한다.
업체에서 제공해 준 메모리 모듈의 칩은 킹스톤 것이다. 속에 '원래' 꽂혀 있는 것도 킹스톤 제품인데, 문제는 없을 것으로 생각한다.

윈7 설치 이후 대략적인 웹서핑 및 기타 사진보기, 동영상 재생 등의 작업을 진행해 본 결과 특별히 문제가 있는 것 같지는 않았다. 그냥 소소한 일상 가운데 사용하기에 전혀 무리가 없을 듯 하다.

ASUS X101 + 30GB mSATA SSD + more

친지 분의 부탁으로 넷북을 하나 사게 되었다. 요구사항은 싸고 가볍고 작고 '얇은' 거...

넷북 무게가 대략 1kg 대 초반인데 그걸 가볍다 해야 할 지는 모르겠고, 작은 건 많은데, 얇은 건 없는 것으로 알고 있었지만 아무튼 가격 위주로 찾아보았다.

그러다 눈에 띈 X101. 넷북인데, 얇다. 게다가 덤으로 가볍기까지 하다. 900g 대 라고 되어 있다. 게다가 맘에 드는 것은 윈도우 미포함이라 OS 가격도 빠져 있다. CPU는 조금 처지는 사양이지만 어차피 넷북이니까.

그런데 대략 살펴 보았더니 SSD 지만 8GB밖에 안 된다. 그냥 사용하기에는 리눅스 설치도 버거운 정도의 용량이다. 뭐 갈면 되겠지 싶어 조금 찾아 보았다. 나름 표준(?) 사양의 SSD를 내장하고 있는데 여기저기에 그 사양은 다르게 써 있다. mSATA, micro SATA, mini PCI-e 등. 명확히 확립된 규격은 아니지만 대략 mSATA로 이해하면 될 듯 하다. 얼마 전 까지만 해도 해외에서 구해야 했던 모양인데 지금은 국내에서도 OCZ 혹은 인텔 제품을 구할 수 있다. 그래도 아직까지는 해외에서 구매하는 것이 압도적으로 싸지만 절차상 번거로움을 감안하면 그냥 국내 구매를 해도 되고 30GB대는 거기서 거기다.

하드웨어 한계상 메모리는 2GB까지밖에 안 된다 하니 2GB 모듈로 업그레이드했다.

x101의 윗부분 생김새는 깔끔한 느낌이다. 밋밋한 상태가 아닌 자잘한 패턴 처리를 해 놓았다.

제조사 홈페이지에 가 보면 크기가 나와 있으니 대략 재 보면 될 것이지만 대략 감을 잡아 보기 위해 2.5GB HDD와 비교를 해 보았다.

옆모습.

실물을 보면 정말 얇긴 얇다. 밑에 두께 비교를 위해 괴어 놓은 2.5 HDD 가 없어도 USB 포트를 통해 그 두께를 가늠해 볼 수 있다. 다만 배터리 부분을 보자면 두꺼워지는데, 조금 더 길게 뒤로 빼면서 얇게 했으면 더 좋았을 뻔 했지만.

사진으로도 알 수 있을 것 같은데, 본체 두께를 보고 키보드 두께를 감안하면 내부에 일반적인 2.5" HDD 가 들어갈 수는 없음이 명백하다.

본체 및 부품을 받아들고 업그레이드를 한 후 Win7을 설치했다. 윈7을 설치할 경우 사운드 드라이버 등은 기본적으로 잡는 듯 하다. 아직 모든 드라이버를 설치하지 않았는데, 그 크기 때문인지 펑션 키 열이 없는 5열 키보드라 펑션 키는 다른 키와 조합으로 처리를 해야 한다. 때문에 노트북 키보드에 으례히 있는 볼륨 조절, 밝기 조절 등이 없는데 드라이버를 설치하면 될 것 같기도 하지만 이미 소유주에게 넘겨버려서 모르겠다.

아무래도 넷북이다 보니 조금 느린 감이 있지만 그 크기 및 무게를 감안한 휴대성을 생각하면 나름 쓸만한 제품이라고 생각한다. 원래 설치되어 있는 MeeGo OS 만으로도 나름 갖고 놀 만하긴 한데 아무래도 별도 리눅스나 M$ 계열 OS 를 설치하는 것이 활용도 면에서 나을 것이다. 다만 그러려면 메인 스토리지 업그레이드는 거의 필수이다. 국내서도 약 10만원 정도면 30GB 대 SSD 를 구입할 수 있고, 그 이상 용량은 사치인 듯 하다. 어쨌거나 스토리지는 일반적인 2.5" 규격으로 나온 SSD 도 아니고 mSATA 규격만을 허용한다.

같은 계열에 기본적으로 윈7 을 내장한 x101h 가 있는데 사실상 전혀 다른 하드웨어 스펙이다. 키보드도 6열이며 VGA 포트도 달려 있고 2.5" HDD가 달려 있다고 써 있다. 즉, 케이스 자체가 다르다는 뜻이다. 해외 리뷰에서도 디자인 측면에서 x101h 가 x101보다 못하다 되어 있다. 그 못하다는 기준이 애매하지만, x101h 보다는 더 나은 넷북들이 널려 있는 것 같다. x101 은 그 두께 및 무게 때문에 성능이 조금 떨어짐에도 불구하고 선택할 만한 가치가 있는 제품이다.

친지의 부탁으로 선택한 제품이지만 항상 그 기준은 '내가 쓰고 싶은' 것으로 잡는 것이 가장 바람직한 선택이 아닐까 싶다. 실제로 받아 들고 업그레이드를 진행하면서 맥북 에어 11" 를 소유하고 있음에도 불구하고 내 것을 하나 사서 쓰고 싶다는 생각이 든다.

Metallica - The Unforgiven (Live)

한때 거의 종교와도 같았던 곡, 그룹... 하지만 이것도 다 한때였더라...

C.C.R. : Who'll Stop the Rain?

어떤 사람(들)의 찌질함 때문에 괴로운 나날들... 누가 비를 멈춰 줄 것인가?

아파치 로그를 업신여기다 또 한 번 당하다.

app server log 는 거의 맨날 끼고 살면서 정작 웹서버의 억세스 로그/에러 로그는 등한시하다가 된통 당했다. 빨리 이 나쁜 버릇을 고쳐야 하는데...

업무 중 로컬에서 어플리케이션을 구동했는데, 화면이 이상하게 나오고 스크립트 오류가 발생하였다. 이상하다... 설정에 손댄 것이 없는데... (심지어 소스조차도)
firebug 로 보니 *.js 가 모조리 404 였다. css 도 아니고 js 만. 다른 사람들에게 조언을 구해 보았는데 다들 apache 설정 이야기를 한다.
나는 설정을 고치지 않았고, 그들이 보기에도 설정에는 별 문제가 없어 보였다.

이런저런 삽질 끝에, 결국 아파치 억세스 로그와 에러 로그를 보았더니, 에러 로그에

[Wed Jul 21 16:33:17 2010] [error] [client 127.0.0.1] File does not exist: /usr/share/javascript/XXX.js

가 있다.

아니, 이게 뭘까... 웬 엉뚱한 /usr/share/javascript 를 찾지?
아파치 설정 디렉터리로 들어가보니, /etc/apache2/conf.d/ 에 자바스크립트 관련한 설정이 추가되어 있고, jquery, prototype 가 /usr/share/javascript 에 설치되어 있었다.
기억을 더듬어 보니, 지난 주 말에 레일스 관련한 것들을 설치하면서 javascript-common 이란 것이 추가로 설치된 듯 하다.

우분투가 마음에 들긴 하지만 이런 몇몇 부분들은 조금 납득하기 어렵다.
어쨌거나, 앞으로는 무언가 설치를 할 때 귀찮아도 설치될 파일 목록을 한 번 훑어 보아야 할 것 같고, 아파치 에러 로그도 절대 무시하지 말아야겠다.

장고 프레임워크를 잠시 접으며

무언가 "간단한" 프로그램을 만들게 되어 그 기반으로 이것저것을 고민하다가 장고를 택했었는데, 결국 아직까지는 한계가 있다고 생각하여 rails 로 하기로 하였다. 사실 그 한계가 정말로 한계라고 장담할 수는 없다. 모델 설계에 대한 내 고정관념 때문일 수도 있으니까.

예전에도 잠시 레일스를 보았었지만, 당시에는 레일스보다 장고가 내게 더 맞는 것 같았다. 그런데, 왜 레일스가 그렇게 인기가 있는지는 조금은 더 생각해봤어야 했을 듯 싶다.
레일스 때문에 루비 언어가 각광을 받았던 것에 비해 장고 때문에 파이썬 언어가 각광을 받은 것은 아니니까. 물론 파이썬 언어 자체는 충분히 매력적이다. 그리고 상당히 강력하다고 생각한다.

그러나 아직 장고를 쓰기에는 이른 시점일 지도 모른다.

문제: 0~1 사이의 실수 중 임의의 수를 골라 더해 나갔을 때, 1이상이 되기까지 평균 몇 번을 더해야 하는가?

이 문제와 답을 보았을 때, 막상 어떻게 풀어야 할 것인지 딱히 떠오르지가 않았다.

그냥 심심풀이 차원에서 주변 사람들에게도 문제를 알려줘 보았는데, 관점의 차이 때문이었을까... 실제로 그러한 값이 나오는지 시도해 볼 생각은 못 했었는데 프로그램을 돌려서 값을 구했다. 물론 그 친구는 정확한 답이 무엇인지 모르고 이런 값이 나오는데 맞는지를 되물었었다.

글쎄, 나는 이 쪽 계통에서 밥을 벌어먹고 살면서 왜 코드로 검증해 볼 생각은 못했을까? 전공이 그쪽이라서? 아무튼, 그 얘기를 듣고 생각해보니 프로그램 자체가 별로 어려울 것은 없어 보여서 확인을 해 보았다. 한 1억 번 돌렸더니, 돌릴 때 마다 값이 조금씩 다르기는 하지만 - 당연하겠지 - 대략 다음과 같은 값이 나온다.

2.718...

그럼, 그 "정확한" 수학적인 답은 무엇일까?
이미 이 값을 보고 알아챈 사람도 있을 지 모르겠다.
바로 "e" 이다.

그런데, 왜 하필 e 일까?
잠시 시간이 지난 뒤 문제를 다시 보니, 어떻게 풀어야 할 것인지 감이 오기 시작했다. 생각보다 꽤 복잡한 과정을 거쳐 풀어 보니까 결국 그 수식 - e 의 급수 표현? - 이 나왔다.

Jetty embedding from scratch

이클립스 웹 프로젝트시 WTP 톰캣을 사용하는 것이 너무 번거로워 Jetty DSL 을 사용해보기로 하였다. 연습 삼아 maven2 를 사용하지 않고 수작업으로 진행해 보았다.

우선 jetty 를 받아 보았는데, distribution 버전을 받아 보니 뭔가 매우 복잡하다. 경량이라고 하는데 패키지 크기도 그렇고, 파일 숫자도 그렇고, 별로 경량일 것 같다는 생각이 들지는 않는다. 어쨌거나 *.jar 들 중에 그럴듯한 이름을 가진 것들을 이클립스 프로젝트 라이브러리에 올려가며 동료가 제시한 DSL 을 작성해 보았다.

천신만고 끝에 DSL 에 의한 내장 웹서버 실행은 되었는데, 이건 좀 아닌듯 싶었다. maven 과 tomcat 사용이 번거로워 해 본 일인데, 이렇게 복잡하게 라이브러리 임포트를 한다면 차라리 maven 이 낫겠다 싶었다. 그러다가 문서를 다시 한 번 살펴보니, Jetty HelloWorld Tutorial 에 jetty-all-${VERSION}.jar 를 받아 적용하는 방법이 나와 있었다. 결국, jetty-all 과 servlet-api.jar 두 가지만 라이브러리 의존성에 포함시켰더니 간단하게 웹서버 실행이 가능하게 되었다.

그런데, JSP 지원이 빠져 있다. Jetty 7 부터는 JSP 를 기본적으로 지원하지는 않는다고 한다. 어차피 원하는 바이긴 했지만 당장은 JSP 를 쓸 필요가 있었기에, 조금 더 살펴 보니까 jsp-2.1 과 jsp-api-2.1 을 가져와야 한다고 한다. 이들 라이브러리는 glassfish 에서 표준화된 것들이라고 하는데, 삽질 끝에 결국 기존 jetty 6.x 대 버전에서 jsp 관련 라이브러리들을 가져와서 해결했다. 해결 이후 보니, 해당 라이브러리들을 *.jar 로 착각했었는데, 디렉터리였고 그 안에 조금 복잡하게 jsp 처리 관련 라이브러리들이 들어 있었다.

결국 jsp 를 사용하지 않을 경우 굳이 maven2 같은 빌드 툴을 사용하지 않고도 쉽게 구성이 가능한데, 그냥 maven jetty plugin 을 사용하는 것이 현재까지는 가장 편한 방법인 것 같다.

왜 그들은 JSTL/커스텀태그에 집착할까?

Java Web Application 을 구현하다 보면 항상 사람을 피곤하게 하는 부분이 HTML 쪽 처리이다. 어째서 JSTL/커스텀태그 만을 사용해야 하는지 납득할 수 없다.
기본 루프식도 마음에 안들고 if - (else if -) else 를 지원하지 않는 것도 마음에 들지 않지만(태그 구조상 지원할 수 없는 것이 당연하기는 하다) 파라메터가 있는 메소드를 사용할 수 없다는 점은 정말 최악이다. 이 것 때문에 서버 측 코드 설계까지 좋지 않은 영향을 미친다.

JSTL 에 맞추려고 서버 측 코드 설계를 제대로 할 수 없는 것은 핑계일지도 모른다. 그렇다고 그런 코드를 처리하기 위한 커스텀태그를 만드는 일도 좋지 않다.
단지 출력하는 부분을 처리하기 위해 커스텀태그를 만드는 것은 상당히 귀찮은 작업일 뿐만 아니라 배보다 배꼽이 커지는 작업이기도 하고, 이런 특수한 코드 - 보통 JSTL 로 처리할 수 없는 내용은 독특한 기능이 대부분이다 - 를 처리하기 위해 커스텀태그를 만드는 것 자체가 더 안 좋다. 코드와 커스텀태그가 항상 종합선물셋트로 묶여 같이 붙어다녀야 한다. 재사용성 최악이다. 단지 특수 코드를 억지로 태그 표현식으로 나타내기 위해 하는 커스텀태그 구현을 뭐하러 해야 할까? 그런 태그는 만들어 놓은 사람도 훗날 그 사용 방법을 기억해 내기가 쉽지 않다.
결국 재사용성 높은 태그로 처리하게 하려면 기본적인 Map/Set/List 자료형으로 구현해야 하는데 정작 그렇게 범용성을 부여하기가 쉬운 것도 아니고 막상 만들고 나면 그런 커스텀태그는 대체 어디에 어떻게 사용하기 위한 것인지 애매모호하게 되기 쉽다.

"매우 간단한" 목록형은 JSTL로 간결하게 표현할 수 있다. 그런데 이는 스크립틀릿도 마찬가지 아닌가? 오히려 복잡한 표현식은 스크립틀릿이 더 자유로울 뿐만 아니라 무엇을 하는 것인지 파악하기도 쉽다.
스크립틀릿을 쓰면 가독성이 떨어진다? 말도 되지 않는 소리이다. JSTL 을 쓴다고 가독성이 좋아지지 않는다. 애초에 쓸데없이 복잡하게 만든 HTML 페이지 디자인 자체가 문제다. 브라우저가 무슨 유화를 그리기 위한 캔버스도 아닌데 말이다.

색인을 만들기 위한 한글 자소 단위 분해

프로젝트에 주어진 과제 중 책 찾아보기처럼 가나다 순으로 제목을 모아 놓아야 하는 기능이 필요하게 되었다. 영문이나 숫자는 그냥 첫 글자만 식별하면 되었는데, 한글인 경우 그렇게 단순하지가 않았다. '가', '거', '객' 등을 모두 'ㄱ' 이라는 대표문자로 묶어야 해서, 일단 한글인 경우 첫 글자를 초/중/(종) 으로 분해해서 초성으로 식별을 하는 방식을 사용했다.

source

---

test case

카페북 시연 소감

카페북 시연을 했다.
카페북이란 무엇인가? 나도 잘 모르겠다. 내가 만드는 데 관여했음에도 불구하고. 이렇게 말하는 게 슬프지만, 지구는 돌고 있는데 안 돌고 있다고 말할 수는 없지 않은가?

그런 행사가 으례 그렇듯, 시연은 '고객을 위해' 이런 것을 생각하고 만들었으니 애용해 달라는 내용이었고, '고객들의 입장'은?
굳이 밝힐 필요는 없을 것이다. 내가 일일이 물어 본 것도 아니고, 검색하면 다 나올 테니까.

어쨌건 간에 내 코드의 흔적이 묻어 있는 결과물이 나올 것이라는 사실 자체에 만감이 교차한다.
미우나고우나 시간과 노력을 들여 세상에 내보낸 결과물이니, 그에 대한 감회를 흔적으로 남긴다. 속시원히 말할 수는 없을 지라도.

어딘지 어색한 돈 단위, 16천원

가끔씩 어떤 글을 읽다 보면 요상한 단위가 튀어나온다.
16천원. 1만 6천원도 아닌 16천원.
특히 공공기관 문서에 많이 눈에 띄는 것 같다.

심지어 회사 어떤 사람이 회식비 1/n 하라고 메일 보낼때도 23천원 이렇게 쓴 것을 보았다.

왜 그렇게 살까?

나름 양인들 숫자 세는 단위에서 기인한 것으로 알고 있기는 하지만, 굳이 우리말로 읽으면서까지 그럴 필요는 없지 않은가?

이상하다, 이상하다.

해서, 숫자 표기도 1,000,000 이 아닌 100,0000 이어야 한다. 양인들이야 지들 일상이니 앞의 10 billion 이 1 mega 임을 쉽게 읽겠지만 우리는 "백만"이라 읽는 것이 자연스럽기에 숫자 4개씩 끊어 쉼표를 넣어야 한다. 지금 쓰는 숫자 표기대로라면 16,000 을 16천원이라 읽는다 해도 사실 할 말이 없다. 1,6000 이라 해야 만 6천원이라 읽을 것 아닌가.

드디어 iPhone 을 사다.

드디어 샀다. 나오자마자 산 것은 아니지만 iPhone 이 절대선은 아니기에, 나름 고민해 보아야 할 것이 있었다. 가장 중요한 고려사항은 지속적인 요금 지출이었는데 적어도 지금 쓰는 전화기보다 요금이 더 나오지는 않는다.

이미 Apple 제품들 여러 가지 - Mac mini, MacBook Pro, Time Capsule, Wireless KeyBoard, Mighty Mouse, ... - 를 쓰면서 느끼는 것이지만 뭔가 아쉬운 부분이 분명 있다. 때로는 치명적이라 느끼는 부분도 있다. 예를 들어, 타임캡슐의 경우 ftp/ssh/nfs 는 지원하지 않고 오직 afp 만 지원한다는 점 등...

어떤 기기도 단점이 없을 수는 없고, 아직 제대로 써 보지도 않았으니 단점을 이야기하기는 어렵겠지만 뭔가 애플 특유의 불합리함은 있을 것 같다.
그래도 아이폰을 택했는데, 아이폰을 써 보고 싶었다는 것이 가장 큰 이유가 되겠다. 한편으로는 국내 대기업, 특히 '삼X' 에 대한 혐오감이 너무나 컸다는 점도 작용했다. 장사의 가장 기본적인 원칙 중 하나이지만, 아이폰이 나오고 반응이 좋으니까 그제서야 X니아2(이름도 개떡같아 별로 부르고 싶지 않다)의 가격을 '파격적으로' 낮추지를 않나... 치사하고 옹졸하게도 KT 용으로 발매하는 제품에는 'X니아' 라는 이름을 빼버리지를 않나(그런데 개인적으로는 더 낫다. 그 이름 자체가 혐오스러워서)...
그게 글로벌 기업이라 자부하는 것들이 할 짓인가? (사실 기업이라는 게 원래 그런 것 같기는 하지만...)

요즈음 이런저런 책들을 읽고 있다. 별로 좋아할 수 없는 일본조차도 '고객을 위해서' 가 아니라 '고객의 입장에서' 생각해야 살아남을 수 있다고 하는데 '삼X' 가 한 일은 대체 뭔가?
무릇 스마트폰이라 함은 'application' 중심으로 가야 하는데 하드웨어 사양만 잔뜩 높여서 가격만 엄청 올려 놓았다. 그야말로 덩치만 큰 무뇌아들을 양산한 것이다(실제로는 아이폰보다 스펙이 높지도 않은데 혹세무민하고 있다).
물론 3개 통신사도 이런 부분에 대한 책임에서 자유롭지는 않다. 아이폰 발매를 시행한 KT 조차도.

담배는 과연 그렇게 해로운 것일까?

상당히 오랜 기간 동안 담배를 피웠다. 나름 끊으려고 노력중이고, 요즈음에는 하루에 한두대 정도 필까말까지만 아직 끊었다고 할 수는 없겠다. 누군가 말하기를 담배는 일단 손댔으면 끊을 수 없다고, 그냥 평생 안 피는 것이라고 한다.

담배를 필 때 나오는 해로운 물질은 니코틴과 타르 뿐만 아니라 수천을 넘는 화학물질들이 나온다고 하는데... 어느날 갑자기 의문이 생겼다.

니코틴과 타르는 그렇다 치자. 그런데 이해할 수 없는 물질 목록들이 눈에 띈다. 나프틸아민, 니켈, 벤젠, 비닐 크롤라이드, 비소, 카드뮴 등... 이건 도저히 자연 상태의 식물에서 나올 수 없는 것들이 아닌가? 혹시 토양이 오염되어 축적된 것이라 치면, 다른 채소류들도 마찬가지 아닌가?

지금 파는 담배는 그냥 단순히 담배잎을 말려 발효시켜서 만든 것은 아니라고 한다. 아마도 다양한 풍미를 내기 위해 모종의 가공을 하는 듯 한데 그 때 들어가는 '첨가물' 들이 아마 그런 물질들의 모체가 아닌가 싶다.

물론 그렇다고 천연 상태의 담배라고 해서 몸에 좋을 리는 없을 것이다. 그러나 최소한 그렇게까지 나쁠 것 같지는 않다.
담배를 옹호하는 것은 아니다. 그러나 담배 자체보다는 각종 첨가물들이 그 원흉이 아닌가 싶다. 정말 그렇다면 담배는 정말 부당한 대우를 받고 있는 것이다.

동기유발과 보상의 관계에 대하여

투자한 시간이 가져오는 차이

같이 일하고 있는 사람 중 적어도 개발 실력 면에서 나를 비롯한 주변 동료들보다 실력이 몇 단계 월등한 친구가 하나 있다.

그 친구가 머리가 정말 좋아서 그런 것인지, 실제 경력이 나보다 상당히 길어서 그런 것인지 - 나의 경우로 따지자면 나는 만 7년 좀 넘는 시간, 그 친구는 전공까지 포함시켜 계산하기는 했지만 11년 - 정확하게 알 길은 없다. 그러나 나름 관찰해 본 바에 의하면 상당 기간에 걸친 시간 투자 없이 그런 경지에 올랐다고 생각하기는 힘들다. 아무리 그 친구 머리가 비상하다고 해도.

이미 그 친구는 학부 시절부터 TDD 에 대한 훈련을 해 왔었다. 본인 말에 의하면 그렇지만, 그 말은 충분히 믿을 만 했다. 정확한 시기는 모르겠으나 복학한 이후인 2002,3년 무렵부터라 해도 6~7년 동안 고민하고 훈련을 해 왔다는 계산이 나온다.
반면에 내가 TDD 책을 '읽은' 것이 아마도 2006년도일 것이다. 본격적으로 TDD 가 무엇인지, 그 위력을 실감한 것이 2008년도였으니, 그 차이는 굳이 말할 필요가 없겠다.

흔히 이런 일에 대한 예로 자주 등장하는 것이 "토끼와 거북이" 이야기다. 결국 이 이야기의 교훈이 틀리지는 않았지만 전혀 현실성이 없는 이야기가 예로 등장하는 것은 전혀 공감하기가 어렵다. 그렇다고 더 좋은 예가 있을까 싶지만 예시 자체가 식상한 면도 있고 실제 발생할 수 없는 일이라 오히려 화자의 의도를 방해하는 경우가 많다고 생각한다.

하지만 정말 꾸준함은 당할 수가 없다는 것을 수긍하게 해 준다. 돈을 모으는 것은 결국 시간과의 싸움이라는 이야기를 하는 책을 본 적이 있다. 누구나 복리의 마법을 이야기하지만 결국 그 열매를 맛보기 위해서는 지루하리만치 긴 시간 동안 복리투자를 실천하는 방법 밖에 없다는 것을. 역시 누구나 알 법한 이야기이지만 구체적인 수치가 나오는 얘기라 감은 바로 온다.

많은 곳에서 비슷한 이야기들을 하고 있다. 꾸준함이 가져오는 열매에 대해서. 나는 너무 날로 먹으려 하고 있는지도 모른다.

public method 변경하기

일하던 중 동료 하나가 말을 걸어 온다. 어느어느 프로젝트에서 에러가 나고 있다고. 내가 손대지도 않았는데 왜 나한테 이야기를 할까?

최근에 이런 일들이 몇 번 있었다. 그렇다고 팀원들이 정말 몰라서 그러는 것은 아니다. 오히려 그런 잘못이라면 이 프로젝트에서는 내가 처음 저질렀던 것 같다(하지만 모를 일이다).

수많은(실은 몇 안 되는) 명저들에서 본 내용 중 하나가 public method 는 함부로 고치지 말라고 했다. 혹은 신중을 기하라고 했던가. 그런 내용을 접하기 전 까지 별로 생각해 볼 수 조차 없었을 내용들인데 읽고 나서는 너무나 당연하게 생각되는 내용이라 당연히 잘 할 것이라 믿었었는데 나도 그렇고 동료들도 그렇고, 치명적인 실수를 저지르고 말았다.

동료 A 는 해당 기능을 하는 method 를 더 효율성이 높은 것으로 대체한다고 기존 것을 지웠다. 물론 본인은 충분히 확인을 한다고 하였겠지만, 문제는 그 class 가 구현된 main 프로젝트가 아니고 다른 sub 프로젝트에서 해당 method 를 참조하고 있어서 발생했다.
동료 B 는 단순히 메소드 이름을 변경하는 refactoring 을 했는데, sub project 에 그 변경이 반영되지 않았다. 상당히 신중하고 시야가 남다른 B 였기에 조금 의아했지만 결국 public 메소드에 대한 변경이 그만큼 단순한 일이 아니라는 증거일 것이다.

다들 잘못이라면 잘못을 하긴 했는데 온 세상에 널리 퍼뜨린 라이브러리도 아니고, 범위가 명확한 프로젝트 안에서 다른 참조 프로젝트에 그 변경이 반영되지 않았다는 것은 지금 쓰고 있는 eclipse 잘못인지, 너무 복잡하게 얽혀 있는 지금 프로젝트 잘못인지 모르겠다.

가끔씩 보이는 '_' 는 대체 왜 쓰는 것일까?

가끔 포스터나 프레젠테이션 자료, 목차 등을 보면 '_' 를 사용한 것을 볼 수 있다. 이를테면

목적과 수단 _17

이런 식이다. 대체 왜 '_' 를 저런 곳에 사용할까? 항상 발견할 수 있지 않은 것을 보면 반드시 저렇게 사용해야 하는 것은 아닐 것이다. 게다가 어렸을 적 - 특히 컴퓨터가 지금처럼 널리 퍼지지 않았던 때 - 에는 저런 표현을 볼 수 없었던 것을 생각하면 바람직한 방향은 아닌 듯 싶다.

실제로 뭔가 만들다 만 것 처럼 보인다.

정말로 궁금하다.

cURL을 사용하여 수많은 서버 상태를 확인하기

팀 내에서 일정 주기로 돌아가며 기술 관련 자유 주제를 선정하여 발표하고 있는데, 안 올 것만 같던 내 발표 순서가 돌아왔다.

새로운 주제를 찾기는 어렵고, 예전에 했던 것을 돌이켜 보니 한 3년 전에 하던 것 중 생각나는 것이 있었다. 당시 시스템 관리를 담당하고 있었는데 어느날 팀장님이 배포 이후 모든 서버를 수동으로(!) 확인하라고 한다...

그 방법은 단순무식해서, 다음과 같은 절차를 따르면 된다.

1. /etc/hosts 를 열어 해당 도메인의 서버 ip 를 수정
2. 브라우저 재시작
3. 브라우저에서 http://www.target.com/path/to/test_application 접속하여 확인
4. 1~3 반복

그 팀장님이 왜 이런 방법을 택했는지는 모르겠다. 그리고 왜 나도 이렇게 하라고 했었는지도. 그러나 서버들 각각이 제대로 작동하고 있는지 확인해야 한다는 점에는 동의한다.
한 10대만 되었어도 저 방법을 그럭저럭 감내할 수 있었겠지만, 50대가 넘는 서버를 그렇게 확인하고 싶지는 않았다...

반드시 브라우저로 확인할 필요는 없지 않을까? 뭔가 다른 방법이 있지 않을까? 없을 리가 없다. 이를 위해 쓸만한 것으로 cURL 이라는 것이 있었다. 실제로 이미 스트레스 테스트를 할 때 cURL 로 테스트 대상 서버에 부하를 주고 있었다. 그 스크립트에 사용하던 cURL 명령행은 매우 간단해서 그냥

형식이었고, 이게 제대로 작동하기 위해서 당연히 /etc/hosts/ 에는 www.target.com 에 대한 스트레스 테스트 대상 서버 ip 를 지정해 놓았었다.

그렇다면 curl http://192.168.111.111/path/to/test_application 도 작동하지 않을까?
되긴 된다. 그런데 우리의 www.target.com 은 저런 ip 기반으로 접근할 수 없었다. 그 밖에, Apache NameVirtualHost 를 사용할 경우 전혀 쓸모가 없다.

그래서 생각했던 것이, 스크립트로 /etc/hosts 안의 대상 ip 를 바꿔 가면서 curl 을 실행하는 방법이었는데... 아무래도 좋은 생각은 아니었다. 테스트 이후 /etc/hosts 를 원상복구하는 것이야 일도 아니라 쳐도, 시스템 전체에 영향을 줄 수 있는 부분을 건드리는 것은 별로 좋은 방법이 아니다. 게다가 이러한 스크립트를 실행하기 위해 root 권한을 사용해야 한다는 것도 별로 바람직한 상황은 아니다.

이런 것 말고도 다른 몇 가지 생각을 했었는데 더 바람직하지 않은 방법들이라 굳이 쓸 필요는 없겠다.

결국 cURL community 에서 힌트를 얻어 해결을 하였는데, 다음과 같이 하면 특정 도메인에 대해 어떤 ip 를 사용할 것인지 지정할 수 있다.

간단한 스크립트 등을 작성하여 대상 서버 ip 에 대해 위 명령을 순환하면 된다. 결과 html 을 적당히 처리하여 결과를 판단하면 될 것이다.
사람이 일일이 /etc/hosts 파일을 편집하고 브라우저를 재시동한 뒤 직접 주소를 입력하여 눈으로 확인하는 것은 정말 하고 싶은 일이 아니다.

P.S: 스크립트 혹은 각종 언어에서 시스템 콜을 하는 것이 그렇게 이상할 것은 없다고 생각하지만 보다 세련되게 처리하고 싶다면 libcurl 을 사용하면 된다. 이게 특별히 더 세련된 방법이라 말할 수 있을지는 모르겠다.