<?xml version="1.0" encoding="utf-8" ?>
<?xml-stylesheet href="http://rss.egloos.com/style/blog.xsl" type="text/xsl" media="screen"?>
<rss version="2.0" xmlns:dc="http://purl.org/dc/elements/1.1/">
<channel>
	<title>푸바, 30대, 아기아빠. 그런데 개발자.</title>
	<link>http://foobar.egloos.com</link>
	<description>30대의 아기아빠.
그런데 개발자.
어떻게 사는게 좋은걸까요?</description>
	<language>ko</language>
	<pubDate>Tue, 19 Aug 2008 10:47:33 GMT</pubDate>
	<generator>Egloos</generator>
	<image>
		<title>푸바, 30대, 아기아빠. 그런데 개발자.</title>
		<url>http://pds2.egloos.com/logo/1/200608/28/27/a0014727.png</url>
		<link>http://foobar.egloos.com</link>
		<width>80</width>
		<height>67</height>
		<description>30대의 아기아빠.
그런데 개발자.
어떻게 사는게 좋은걸까요?</description>
	</image>
  	<item>
		<title><![CDATA[ 올림픽이 한창입니다. ]]> </title>
		<link>http://foobar.egloos.com/1799002</link>
		<guid>http://foobar.egloos.com/1799002</guid>
		<description>
			<![CDATA[ 
  1988년 서울올림픽부터 시작해서<br />
2008년 베이징올림픽에 이르기까지<br />
6번의 올림픽을 제대로 본 적이 없읍니다.<br />
<br />
그렇다고 스포츠경기를 유달리 싫어하는것도 아닙니다.<br />
그러면 왜 못봤냐.<br />
<br />
항상 그때마다 공부(수험생)를 하던가<br />
프로젝트 Due에 맞추어 개발을 하던가 했읍니다.<br />
<br />
미리미리 해두었다면, 여유롭게 올림픽을 즐겨가며<br />
할것도 다 하면서 살수도 있었읍니다만, <br />
게으름때문에 '올림픽이 뭐가 중요한가'를 외치며 <br />
오늘도 컴퓨터앞에서 뭔가 열심히 프로그램만 짭니다.<br />
<br />
그러면 대가라도 되어있어야 되는데, 그렇지도 않습니다.<br />
<br />
대가가 되던지.. 아니면<br />
다음 올림픽부터는 챙겨볼수 있도록 해야겠읍니다.<br />
			 ]]> 
		</description>
		<category>diary of foo</category>

		<comments>http://foobar.egloos.com/1799002#comments</comments>
		<pubDate>Tue, 19 Aug 2008 10:47:33 GMT</pubDate>
		<dc:creator>foobar</dc:creator>
	</item>
	<item>
		<title><![CDATA[ The law of leaky abstraction ]]> </title>
		<link>http://foobar.egloos.com/1795853</link>
		<guid>http://foobar.egloos.com/1795853</guid>
		<description>
			<![CDATA[ 
  Joel Spolsky가 이야기한 다음의 말입니다.<br />
<strong><br />
<a href="http://www.joelonsoftware.com/articles/LeakyAbstractions.html">All non-trivial abstractions, to some degree, are leaky.</a><br />
<br />
</strong>(누구나 그렇겠지만) 왕년에는 천재였으나 30대에 바보가 되어버린 머리로는<br />
어느정도 복잡도가 넘어가면 머리속에서 발산해버리고 마는 특성으로 인해<br />
개발에 있어서 제일의 화두는 abstraction이라고 생각하고 있읍니다.<br />
Joel의 말에 저도 동감을 하는데, Leaky한 abstraction이라도 적용하지 않으면<br />
바로 발산해버리기 대문에, 계속 적용을 해나갈 수 밖에 없읍니다.<br />
따라서 아무래도 평생동안의 소프트웨어 개발 제일 화두는 abstraction이 될 것입니다.<br />
<br />
그런데 이 법칙은 디자인 패턴에도 적용할 수 있읍니다.<br />
<br />
All non-trivial design patterns, to some degree, are leaky also.<br />
<br />
leaky한 abstraction을 잘 활용하려면, 어차피 해당 abstraction의 detail까지 일단<br />
파고 들어가 다 소화한후에, 활용해야되듯이 (무엇을 깨쳤는가.. 다 잊었읍니다.. 그것이 Zen이다.)<br />
design pattern도 잘 활용하려면, 즉 non-trivial한 design pattern을 활용하여 무엇인가 얻으려면,<br />
해당 design pattern의 본질적인 부분까지 파고들어가야 합니다.<br />
기계적으로 '이럴땐 이거'로 적용하지는 마시라는 것입니다.<br />
<br />
			 ]]> 
		</description>
		<category>소프트웨어 개발</category>

		<comments>http://foobar.egloos.com/1795853#comments</comments>
		<pubDate>Tue, 12 Aug 2008 05:13:07 GMT</pubDate>
		<dc:creator>foobar</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 디자인 패턴 ]]> </title>
		<link>http://foobar.egloos.com/1795848</link>
		<guid>http://foobar.egloos.com/1795848</guid>
		<description>
			<![CDATA[ 
  디자인 패턴의 가장 큰 가치는 커뮤니케이션을 원활하게 한다입니다.<br />
시스템/모듈 디자인을 설명할때, '이건 adapter 패턴을 이용하여 어쩌고 저쩌고..'<br />
'요 widget에 대해서는 observer 패턴을 이용해서 어쩌고 저쩌고'<br />
라고 설명하면, 화자와 청자가 둘다 용어를 알고 있다고 하면<br />
의미가 간단명료하게 전달되기 때문입니다.<br />
<br />
두번째 가치는 소프트웨어 구현테크닉을 모르는 사람이 패턴을 공부함으로써<br />
자신의 구현방법 repository를 확장하는 것입니다.<br />
<br />
그런데 현업에서 많이 이미 구를대로 굴렀다, 알만큼 안다, 라는 분들은<br />
굳이 디자인 패턴을 보면서 시간을 낭비(?)할 필요가 있을까 싶습니다.<br />
<br />
디자인 패턴을 책이나 기타 매체등을 통해 접하면서<br />
'아, 내가 그때 이렇게 한게 이 패턴이었군' 이라고 느끼면서<br />
'역시 디자인패턴은 배워볼만한 것이야' 라고 느낀다면<br />
본말이 전도된 것입니다.<br />
'이렇게 하면 내가 고생하던 문제를 깨끗이 정리할수 있겠네'<br />
라고 느낀다면 공부측면에서 디자인 패턴을 배울 필요는 있읍니다.<br />
그런데, 많은 경우에 디자인 패턴을 전파하시는 분들이<br />
전자에 속하는, 즉 '자신이 이미 알고 있는 것을 다른 경로를<br />
통해 Re-assure해줌으로써 기분이 좋아져서 그것이 실제 가치보다 <br />
더욱 가치가 있는 것이라고 생각하는', 경향이 많은 것 같습니다.<br />
<br />
따라서 디자인 패턴은 다음과 같이 접근하는것이 좋겠읍니다.<br />
&nbsp;1. 자신이 사는 세계에서 패턴 world의 단어가 많이 출몰하는 경우<br />
&nbsp;&nbsp;&nbsp;&nbsp; 커뮤니케이션을 위해 익혀둔다.<br />
&nbsp;2. Enterprise SW를 개발하는 경우에는 해당 시스템의 본질적 복잡도를<br />
&nbsp;&nbsp;&nbsp; 회피하기 위해 구조화된 디자인이 매우 필요하므로 익혀둔다.<br />
&nbsp;3. 1,2가 아니라면 간단한 세미나나 간단한량의 book(let)을 통해<br />
&nbsp;&nbsp;&nbsp; 파악만 해 둔다.<br />
&nbsp;4. 만약 컴퓨터 엔지니어링쪽 Job을 가는 초심 개발자 ( == 학생)<br />
&nbsp;&nbsp;&nbsp; 라면 미래를 위해 잘 익혀둔다.<br />
<br />
뭐, 잘 알아서 나쁠건 없읍니다만, 제 의견은, 시간은 한정되어있고<br />
배울것이 많다면 굳이 디자인패턴쪽에 시간을 투자하는것은 고려해봐라<br />
라는 것입니다.<br />
<br />
<br />
<br />
			 ]]> 
		</description>
		<category>소프트웨어 개발</category>

		<comments>http://foobar.egloos.com/1795848#comments</comments>
		<pubDate>Tue, 12 Aug 2008 04:55:25 GMT</pubDate>
		<dc:creator>foobar</dc:creator>
	</item>
	<item>
		<title><![CDATA[ 창조, 발견 그리고 변화, 결국 공부. ]]> </title>
		<link>http://foobar.egloos.com/1794620</link>
		<guid>http://foobar.egloos.com/1794620</guid>
		<description>
			<![CDATA[ 
  Engineer의 궁극적인 목표는 창조(Creation)이고<br />
Scientist의 궁극적인 목표는 발견(Discovery)입니다.<br />
<br />
세상에 없던 것을 만들어 내는 것이 창조라면,<br />
이미 세상에 존재하지만 아무도 몰랐던 것을 알아내는 것이 발견입니다.<br />
<br />
하늘아래 새로운 것이 없다라는 견해라면<br />
창조라는것도 신이 어딘가에 만들어놓고 숩겨놓았던 것을 끄집어내는<br />
발견이 되겠죠. 그러나 많은 경우에 사용되는 Engineer의 창조 - 협의의 창조 -<br />
는 인간계에 없었던 것으로 생각되고 있던 것을 만들어 내는 것입니다.<br />
<br />
소프트웨어를 개발하는 입장에서, 많은 시간동안 고객이 원하는 기능을 <br />
개발하고 있다보면 단순 노동을 하고 있다는 생각이 들기 마련입니다.<br />
따라서 항상 새로운 것을 만들어보고 싶다는 욕구 - 가지 못하고 있는 길<br />
The road not taken YET -가 머릿속에 맴돌게 되는데,<br />
실제로 짬을 내어 새로운것을 만들어 보려고 한다면 <br />
많은 경우 벽에 부딪혀서, 일상속으로 다시 돌아가게 됩니다.<br />
<br />
사실 창조와 발견 모두 어려운 일입니다. 특히나 가치있는 창조와 발견은<br />
어려운 일입니다.<br />
<br />
따라서 지금으로서는, 언젠가 예고없이 방문할 영감의 때를 막연히 기다리면서,<br />
대신 변화를 꿈꿔야 합니다. 새로운것이 없어도 세상은 바뀝니다.<br />
어느세계의 상식이라는 것이 다른 세계에서는 귀중한 영감입니다.<br />
최근 M.Stonebreaker가 Google의 MapReduce에 대해서<br />
"Not Novel at All"이라고 비판했다고 합니다. <br />
M.Stonebreaker는 많이 유명한 Computer Scientist입니다.<br />
Scientist는 Novelty를 주요시하기때문에 그렇게 말할수 있읍니다만,<br />
제가 말하고 싶은것은 어찌됐건 Google의 Not Novel at All한 MapReduce 역시 <br />
세상을 변화시키고 있다는 겁니다.<br />
<br />
어떻게 보면 Scientist는 신의 유물을 인간계로 끌어내긴 하는데, 그들만의<br />
금고에다가 잘 보관해놓고 있을뿐인지도 모릅니다.<br />
그것을 인간계로 퍼뜨리는것은 Engineer의 몫입니다.<br />
Scientist의 금고 (학술지입니다. 쉽게 말해)를 항상 뒤져가면서<br />
널리 퍼뜨려서, 세상을 변화시킬수 있는 무엇인가가 있는지 확인해야합니다.<br />
<br />
Science세계에서는 새로운 것을 발견하지 않으면 Perish되기 때문에,<br />
가치를 떠나서 새로운 것들이 쏟아져 나옵니다만, Engineer세계에서는<br />
굳이 혁신적인 것을 만들지 않아도 면장은 하기 때문에 Scientist가 끄집어낸<br />
신의 유물이 인간에게 쉽게 퍼지지 않습니다.<br />
<br />
따라서, Engineer라면 공부를 해야합니다. 열심히 공부하다보면, 어느순간<br />
창조의 영감이 찾아와서 붙을것 같다는 생각이 드니까요.<br />
<br />
<br />
<br />
			 ]]> 
		</description>
		<category>diary of foo</category>

		<comments>http://foobar.egloos.com/1794620#comments</comments>
		<pubDate>Sat, 09 Aug 2008 10:37:03 GMT</pubDate>
		<dc:creator>foobar</dc:creator>
	</item>
	<item>
		<title><![CDATA[ Hello, World! ]]> </title>
		<link>http://foobar.egloos.com/1401095</link>
		<guid>http://foobar.egloos.com/1401095</guid>
		<description>
			<![CDATA[ 
  <blockquote>$ cc -o foo foo.c<br />
$ ./foo<br />
Hello, World! <br />
</blockquote><br /><br />			 ]]> 
		</description>
		<category>diary of foo</category>

		<comments>http://foobar.egloos.com/1401095#comments</comments>
		<pubDate>Mon, 28 Aug 2006 07:18:57 GMT</pubDate>
		<dc:creator>foobar</dc:creator>
	</item>
</channel>
</rss>
