Jong10 in Wonderland

Just, move forward

jong10 — Tue, 14 Jul 2009 00:12:00 +0900

적어도 하루에 다섯 번은, 숨이 막힐듯한 불안감을 느낀다. 나는 그들과 DNA부터 다르다는 것 정도는 알고 있고, 어쩌면, 말도 안 되는 것을 바라는 지도 모르고, 20대의 치기(稚氣)일 수도 있다. 후회를 할 지도 모른다. 내 바램들이 10년, 혹은 15년 후에는 이뤄질 지도 모르지만, 다 그냥 뻘 짓이었고, 그냥 평범하게 살 지도 모른다. 그래. 모른다.

그래서, 앞으로 나아간다. 궁금하잖아.

-- 이상한 나라의 종텐.

선택이라는 순간

jong10 — Sat, 11 Jul 2009 19:16:00 +0900

심리적, 정신적으로 힘들었던 1학기가 끝난 기념으로, 또한, 삶의 전환점을 마주하게 된 기념으로, 소소하게 책을 주문했다. “너 그동안 고생했어!” 하면서 나에게 하사하는 작은 상.

하이버네이트 프로그래밍: Harnessing Hibernate
아이폰 프로그래밍: iPhone SDK를 이용한 아이폰 개발
패턴을 활용한 리팩터링

지갑이 얇아서, 아직도 찜 목록에 담겨져 있는 책들도 많다. 데일 카네기의 자기관리론, 패턴 지향 소프트웨어 아키텍처 1권, 이펙티브 자바 2판, 소프트웨어 크리에이티비티 2.0, 소트웍스 앤솔러지, Head First C#, iBATIS 인 액션, 겸손한 개발자가 만든 거만한 소프트웨어… 등등.

책을 살 때면 항상, 모조리 살 수 있는 경제력이 있으면 좋겠다고 생각하지만, 책을 선택하는 순간은 매우 중요한 의식이다. 무엇을 사는지에 따라서, 무엇을 읽는지에 따라서, 내 코드는 물론이고, 사고방식에 영향을 미친다. 좁게는 테크트리에 영향을 미치고, 넓게는 내 인생에 영향을 미친다. 그것들은, 장바구니에 들어가는 운명의 책과, 다시 꺼내지는 운명들 사이에서 결정 된다. 오 이런, 장바구니가 내 삶을 결정하다니!

예를 들어, 오늘 같은 경우, iBATIS를 먼저 배우려고 했는데, Hibernate가 선택 되었다. 자기관리를 시도하려 했지만, 아이폰 개발에 대한 학습이 더 중요하다고 판단당했다. 오늘, 아꿈사의 디자인패턴 스터디에 나가지 않았다면, 집에 오는 길에 다른 개발자와 패턴에 대한 의견을 주고받지 않았을테고, “패턴을 활용한 리팩터링”은 주문하지 않았을 것이다. 이러한 소소한 결정들은, 서로간에 영향을 받으며, 삶의 방향을 변화시킨다. 내가 읽는 책들은 나를 변화시킬 것이고, 다시, 다른 책을 불러모으게 될 것이다.

“모든 것은 모든 것에 잇닿아있다”라는 말을 지난 6개월간 뼈저리게 느꼈다. 지금, 나 자신의 1초 1초는 중요하다. 내일의 나를 구성하는 데에 영향을 미치기 때문이다. 이것은 책에 대한 이야기가 아니다. 삶에 대한 이야기이다. 책은 단지 example일 뿐이다. 순간이 모여서 인생이 된다.

-- 이상한 나라의 종텐.

p.s. 그나저나, 엊그제 샀던 안드로이드 책은 머릿말도 아직 안 읽었는데 -_-;;

Ruby로 15분간 Scheme 인터프리터 만들기

jong10 — Tue, 07 Jul 2009 23:58:00 +0900

우아! 이건 뭐, 킹왕짱임! >_<)=b 몇일전에 Boost.spirit 예제 코드 보면서 떡실신 했는데, 역시, C++보다는 Ruby가 DSL 만들기엔 2천만배쯤 편한 것 같다. 루비로 (Lisp의 친척인) Scheme 인터프리터를 15분만에 만들어낸다. (지아님 미투에서 발견했다.) EDSL이라는 점에서 Yacc보단 Spirit에 가까운, Treetop이라는 파서 제네레이터도 흥미롭다.

(반드시, 풀화면으로 보시길!!)

Scheme interpreter in 15 minutes from James Coglan on Vimeo.

그나저나, Lisp는 역시 문법이 간단하구나 싶다. 해커와 화가에서, Lisp의 초기 문법은 A4 용지 한장도 안된다고 한 것 같은데. 물론, 클로저가 있는 루비였으니 더 쉬웠겠지만. 흠… 위 내용을 파이썬으로 하면 어떻게 해야 할까? 또는, 자바로 구현하려면 어떻게 해야 할까? 또는, C++로 하려면?

-- 이상한 나라의 종텐.

드리밍 인 코드

jong10 — Sat, 04 Jul 2009 13:21:00 +0900

드리밍 인 코드를 읽고 있다. 넷스케이프의 핵심 인력, 초창기 매킨토시의 핵심 인력, 등등의 전설적인 인물들 몇 명이 모여서, 몇 년 간 진행했지만 망해버린 -_- 챈들러 프로젝트에 대한 이야기인데, 상당히 재미있다. 절반쯤 읽었는데, 문장 몇 개를 뽑아보자면…

오늘날 사람들은 넷스케이프를 인터넷 초기에 엄청난 성공을 거두었던 회사로 기억하지만, 넷스케이프 개발자들은 스스로 불가능한 일정에 뒤쫓기고 눈앞에는 피해갈 수 없는 실패와 마주선 사람들이라고 생각했다.

하지만 FAA 프로젝트 참여자들처럼 직접 재앙을 겪은 이들을 제외하고는 새로운 소프트웨어 개발 프로젝트에 참여하는 대부분의 사람들은 과거에 대해 잘 모르고 있거나 미래에 대해 지나치게 긍정적인 경우가 많다. 그들은 그저 이번에는 다를 것이라고 낙관적으로 확신한다.

"맨먼스 미신"에서 브룩스는 바벨탑을 인간이 시도한 두 번째 대규모 엔지니어링 프로젝트라고 말한다(첫 번째 대규모 엔지니어링 프로젝트는 '노아의 방주'였다). 하지만 바벨탑은 동시에 첫 번째로 실패한 엔지니어링 프로젝트였다. 바벨탑 건축 관리자들은 성공을 위한 모든 조건을 완벽히 갖추고 있었다. 그들은 명확한 임무와 인력과 자재, 충분한 시간, 기술을 가지고 있었다. "바벨탑 건설이 실패한 까닭은 건설에 참여한 사람들이 서로 말이 통하지 않아서 협업을 할 수 없었기 때문이다. 사람들 간의 협업이 조직되지 않으면 업무는 중단된다."

하지만 가장 중요한 문제는 속도였다. "저는 사람들을 몰아쳐서 일하는 것을 선호합니다. 위대한 프로그램을 만들기 위해서는 누군가 중심에서 프로젝트에 생명을 불어넣는 사람이 필요합니다. 무자비한 방식으로라도요. 그것이 부재했던 게 문제였죠."

이 책을 읽고 있는 당신이 소프트웨어 개발자라면, 아마 이쯤에서 이런 말을 외치며 이 책을 벽에 던져버렸을지도 모르겠다. "이런 미친 짓은 이제 그만 두라고! 이미 교과서에 나와있는 모든 실수를 저지르고 있어!" 내 생각에 대부분 프로그래머들은 이렇게 생각할 것 같다. "나는 저런 바보 같은 짓은 하지 않을 거야. 나라면 훨씬 더 잘할 수 있다고." 물론 그게 사실일 수도 있다. ...(생략)... 소프트웨어 역사의 연대기에서, 챈들러의 실망스런 진전 속도는 예외가 아니라 오히려 평균적인 경우에 가깝다. 역사는 모든 운전사가 길에서 벗어나는 방법은 다르지만, 그들 모두가 언젠가는 바퀴를 도랑에 처박고 만다는 사실을 여실히 보여준다.

만약 당신이 자신은 분명히 더 잘 할 수 있다고 확신하는 프로그래머 중 한 명이라면 지난 번 프로젝트에서 이런 생각을 한 적이 몇 번이었는지 자문 해보기 바란다. "맞아요. 나는 우리가 아마도 이것을 해야만 한다는 사실을 압니다." (여기에서 '이것'은 소프트웨어 업계에서 잘 알려진 소프트웨어 개발과 관련한 기본 원칙 중 어떤 것일 수도다.) "하지만 지금은 특수한 상황입니다. 우리는 아주 특별한 경우입니다." 앤디 허츠펠드는 이렇게 말하곤 했다. "통상적인 프로젝트란 없습니다. 모든 프로젝트에는 저마다 고유한 특성이 있지요.”

특히, 바벨탑에 대한 비유는 엄청난 것 같다. 망한 첫 번째 엔지니어링 프로젝트라니. 푸핫.
아, Geek에 대한 이야기도 나온다.

긱들과 긱이 아닌 사람들은 왜 사이좋게 지낼 수 없을까? 미국 국방산업대학교에서 최근에 진행한 '정보기술팀에서의 인간 관계 역학' 연구에서는 77개 팀의 IT 전문가들(주로 프로그래머들과 프로그래밍 관리자들)의 머릿속을 해부하려는 시도를 했다. 관찰, 면담, 다양한 설문 등 여섯 가지 측정 방법을 통해 연구자들은 IT 전문가들의 성격 성향이 일반인들과는 근본적으로 다르다는 사실을 발견했다.

헐… 근본적으로 다르대. -_-;;

-- 이상한 나라의 종텐.

The Resurrection

jong10 — Fri, 03 Jul 2009 01:43:00 +0900

총체적 난국이었다. 내 신념이 뿌리 채 흔들리며, 존재하지 않는 가치를 추구하는 것은 아닌지 의심했다. 비흡연자인 내가 담배를 피고, 새치가 나기 시작하며, 머리 속은 온통, “나는 뭘 해도 안 되는 걸까?”라는 생각이 가득 찼다. 가슴은 답답하고, 신은 항상 내 편이 아니라는 생각 뿐이 들지 않았다. 운명은 내 편이 아니었다. 그토록, 너무나 많은 것들을 포기하고, 잃어왔지만, 이젠 더 이상은 버릴 것도 없었다. 이미 모든 것들을 충분히 버리지 않았나? 나는 이미 충분히 지쳐 있었다.

어떻게 보면, 굉장히 사소한 일이었지만, 나에겐 전혀 사소하지 않았다. “잘했어”라는 이야기를 듣는데, 8년이 걸렸다. 난 그냥 단지, “잘했어”라는 말이 듣고 싶었다. 몇 년간 쌓였던 패배감들이 눈 녹듯이 사라지기 시작했다. 집에 오는 내내, 감정에 복받쳐 자꾸만 눈물이 났다. 패배감에 휩싸였던 시간들이 기억에서 떠올라 부유했다. 지하철 유리창 안에 비친 내 모습에, 갈 곳을 찾지 못하고 방황하던 몇 일 전의 내 영혼이 오버랩 되었다.

실질적으로 내 자신에겐 아무 것도 변하지 않았지만, 모든 것이 달라졌다. 유리창에 비친 몇 일 전에 내 모습에게 말했다. 너는 누구니? 나는 종텐이다. 불가능은 없다는 말의 다른 표현이지.

-- 이상한 나라의 종텐.

Java를 위한 Enumerate 기능

jong10 — Tue, 30 Jun 2009 02:29:00 +0900

Python에는 Iterable한 항목을 감싸서 메모리 사용량을 최소로 하면서, 인덱스가 포함된 튜플을 돌려주는, enumerate라는 훌륭한 built-in function이 있다. Java에도 있으면 좋을 것 같아서, 흉내 내봤다.

// coded by jong10
// Enumerator class, version:20090630

import java.util.Collection;
import java.util.Iterator;
import java.util.NoSuchElementException;

public class Enumerator<T> implements Iterable<Enumerator.Entry<T>> {
	public static class Entry<T> {
		private T value;
		private int index;

		Entry(int index, T value) {
			this.index = index;
			this.value = value;
		}

		public int getIndex() {
			return index;
		}

		public T getValue() {
			return value;
		}
	}

	private static class EnumeratorIterator<T> implements Iterator<Enumerator.Entry<T>> {
		private int lastIndex = 0;
		private Iterator<T> iterator;
		
		public EnumeratorIterator(Iterator<T> iter) {
			this.iterator = iter;
		}
		
		public boolean hasNext() {
			return iterator.hasNext();
		}
		
		public Enumerator.Entry<T> next() {
			if (hasNext() == false)
				throw new NoSuchElementException();
			
			return new Enumerator.Entry<T>(lastIndex++, iterator.next());
		}
	
		public void remove() {
			iterator.remove();
		}
	}

	private EnumeratorIterator<T> iterator;

	public Enumerator(Collection<T> c) {
		this.iterator = new EnumeratorIterator<T>(c.iterator());
	}

	@Override
	public Iterator<Enumerator.Entry<T>> iterator() {
		return iterator;
	}
}

사용 방법을 보여주는 JUnit 테스트케이스이다.

@Test
public void testEnumerator() {
	List<Character> list = Arrays.asList(new Character[] {'h', 'e', 'l', 'l', 'o'});
	
	int[] indexes = new int[list.size()];
	char[] values = new char[list.size()];
	
	for (Entry<Character> entry : new Enumerator<Character>(list)) {
		indexes[entry.getIndex()] = entry.getIndex();
		values[entry.getIndex()] = entry.getValue();
	}
	
	assertArrayEquals(new int[] {0, 1, 2, 3, 4}, indexes);
	assertArrayEquals(new char[] {'h', 'e', 'l', 'l', 'o'}, values);
}

자바도 제네레이터가 있으면 좋을텐데…

-- 이상한 나라의 종텐.

대화

jong10 — Sun, 28 Jun 2009 00:19:00 +0900

대화라는 것은, 말하는 사람과 듣는 사람이 있어야 한다. 이 세상에는, 듣는 사람의 입장 정도는 무시하는 것도 대화라 생각하는 사람들이 많다. 그건 그냥, 공기중에 말을 배설하는 거지.

자기는 다 안다는 듯한 오만을 뿜어내는 인간들이나, 청자(聽者)의 인생에 대해 뭘 안다고, 인생 선배(또는 형, 오빠, 누나, 언니)의 입장으로 어쩌고 저쩌고 떠들어대는 부류도 많다. 자기들이 뭐가 되는 줄 아는건지, 오지랖이 넓은 건지, 왜 감히 훈계를 하는지 모르겠다.

화자(話者)가 보기엔 답답한 상황일지도 모르지만, 열 살짜리 아이이든 80살 먹은 노인이든, 각자의 기준과 철학이 있고, 생각하는 바가 다르다. 그런데, 나이 몇 살 더 먹었다고, (상대방은 화자를 그런 존재로 평가하지도 않는데) 인생 선배니 뭐니 하며 지 생각이 우주의 진리인 양 말하는 꼬락서니를 보면 우습다. 조언을 청한 것도 아닌데.

아니면 최소한, 그런 이야기를 하려면, 뭔가 복선을 깔아야 하는 거 아닌가? 충분한 친분이 있는 관계도 아니고, 듣는 사람은 전혀 준비도 안 되었는데, 얼떨결에 비난이나 조언을 들으면 참 어이없다. 왜 이렇게 세상에는, 배려심이 한 개도 없는 인간들이 많은지 모르겠다.

-- 이상한 나라의 종텐.

GET 요청은 멱등이다!

jong10 — Tue, 23 Jun 2009 22:17:00 +0900

우와. 단 4글자를 고치기 위해서, 4시간을 삽질했다!!

학교 웹프로그래밍 팀 프로젝트로, jQuery와 Ajax를 사용하는 웹 어플리케이션의 막바지 작업중이었다. 분명 거의 다 만들었는데, Firefox와 Chrome에선 잘 되는데, Internet Explorer에선 되는 곳도 있고, 안되는 곳도 있는게 아닌가?! 더 웃긴건, ie8에서도 되는게 있고 안되는게 있고, ie7에서도, ie6에서도, 되는 곳이 있고, 안되는 곳이 있었다.

jQuery의 getJSON()으로 json으로 된 내용을 가져와서, 화면에 업데이트 해주는 것이었는데, 처음엔, jQuery의 ajaxForm 플러그인을 의심하다가, async 플러그인을 의심하다가, jQuery 문장의 ready()를 의심하다가, 이거 뭐, 모든 걸 다 의심해봤으나, 도저히 답이 없더라.

근데 참 웃긴게, 클라이언트에서 alert()를 중간에 넣어보면, 분명히 주기적으로 0.2초마다 팝업창이 뜨는데, 서버의 자바 서블릿에선 전혀 호출이 아예 안되는 거였다. 이 뭐 병?? 게다가, 파이어폭스랑 크롬은 된단 말이지.

그러다가 문득, “아! 톰캣이 이거 캐쉬 해주는건가?!!! HTTP의 GET은 멱등이잖아?! 0.2초만에 똑같은 요청이 들어왔으면, 같은 결과를 내보내주는 것이 HTTP 규약상에도 합당하고, 상식적으로 당연하지 않은가?” 하는 생각이 들었다.

그래서, GET을 POST로 바꿨더니…

된다!! -_-;;;

HTTP 요청에서 GET은 멱등이다. 즉, 호출하기 전과, 호출한 후의 서버의 상태는 바뀌지 않아야 되는 것이 HTTP의 규칙이다. 간단히 생각해보면 정말 기초적인 것인데, 아우 정말. -_-

파이어폭스와 크롬의 기본 옵션은, HTTP/1.1의 Expiration이 짧게 설정되어 있기 때문이었나 보다. 반면에, IE는 옵션에서 이걸 “항상 새 페이지를 받는” 것으로 설정하고 쓰는 사람도 있고, 기본값으로 쓰는 사람도 있어서 이런 일이.

GET 요청 시에는 항상 캐쉬 당할지도 모른다는 사실을 고려하자. GET 요청은 멱등이다.

-- 이상한 나라의 종텐.

아이폰 출시를 바라는 이유

jong10 — Sun, 21 Jun 2009 00:35:00 +0900

바다 건너 미국에선 아이폰에서 보는 트위터가 TIME지 표지로 나올 정도인데, 우리나라에선 모바일이나, 이를 이용한 미투데이 같은 것들은 아직도 비주류. 굳이 주류가 될 필요는 없지만, 이들의 성장을 막는 부분이, 특정 회사의 밥그릇이라는 점은 문제가 있지 않나?

많은 개발자들이 아이폰 출시를 바라는 것는, 기계 자체를 쓰고 싶은 것 보다도, 이런 이유 때문이 아닐까 싶다. => [시사저널] 아이폰, 국내 ‘통신 빅3’폭리 담합 구조 깨뜨릴까

이러고 있다.

jong10 — Fri, 12 Jun 2009 22:22:00 +0900

이틀째 집에 못 가고 있다. 캔을 쌓아서 안드로메다로 갈테다.