Emergence from Synapses

Simply, Profoundly

[yakshavinglocus-blog]

사내 스타트업 프로젝트 진행 한 달, 즈음하여

한 달째.

최근 완성된 멤버 구성이 아주 좋다. 최근 회의 몇 번을 진행해보면서 더욱 훌륭한 구성에 감탄했다. 돌이켜보면, 구인 사이트에 달랑 글 올려 놓고 사람을 기다렸다면 지금과 같은 멤버는 절대 구할 수 없었다. 특히 디자이너 뽑을 때는 매일 포트폴리오 수십 개를 검토하면서 거의 포기 직전까지 갔더랬다. 그리고 다른 한 분 뽑을 때도 포기 직전까지 갔다. (그리고 매 번 제발 우리에게 오라며 기도까지...)

그럼 이제 릴리즈 시점 즈음에 엄청난 퀄리티의 결과가 나올 것이냐? 그 결과는 이 멤버들이 어떻게 나아갔는가에 대한 이야기다. 그리고 지금의 멤버들은 아직 능숙함 보다는 가능성에 무게 중심이 있다.

[yakshavinglocus-blog]

자전거 타고 작업하러 왔더니 dog피곤

[yakshavinglocus-blog]

He who foresees calamities, suffers them twice over 재앙을 예견하는 자는 불행을 두 번 겪게 된다.

Beilby Porteus

[yakshavinglocus-blog]

외국어 의사소통의 필요 조건

어릴 때 30대 중반까지 5개 국어를 구사해 보겠다는 막연한 결심을 했더랬다. 남들 앞에서 여러 외국어를 능숙하게 하면 멋져 보이겠다는 생각도 있었지만, 오랜 세월이 지나 질릴 때도 됐는데 '5개 국어 구사 계획'을 오랜 기간 이행하는 데에는  다수의 계기가 있다.

무엇보다 큰 계기는 돌아가신 이모부가 만들어 주셨다. 이모부는 미국인이셨다. 나중에 알게 되었는데 MIT 공대를 졸업하신 공학자이셨고, 한국에서는 미군의 미사일 관련 기술 업무를 담당하셨단다. (세운상가 등에서 값비싼 전자 부품들을 찾으셨을 때 알아봤어야 했다.) 이모부와는 이야기를 거의 나누지 못했는데 영어를 책에서만 배웠지 말하기는 경험이 없어 입 밖에 내지도 못했기 때문이다. 물론 바보같은 소심함이었고 나중에 엄청나게 후회했다. 지금도 궁금해 죽겠다. 이모부가 어떤 프로그래밍 언어를 좋아하셨는지, SICP는 보셨는지... (-_-;;) 결국 외국어는 사람들과 직/간접적으로 소통하는게 가장 근본적이고 중요하다는 사실을 눈물 몇 번 흘리면서 되뇌였다. 토플 몇 점 이런 것 보다는 의사 소통하기 위해 노력했던 것 같다.  어쨌든, 그래도 "몇 개 국어 구사하네요?"라는 표현은 들을 때마다 소름돋게 부끄럽다. 토플, JLPT 같은 어학 점수 면에서 보면 그냥 넘어갈 수도 있는데, 정작 뼈저리게 깨달았다던 외국어 익히기의 본질, 의사소통 측면에서 부족한 면이 많기 때문이다. 

The limits of my language are the limits of my world.

Friday One of the many famous aphorisms that have been plucked out of Wittgenstein's Tractatus Logico-Philosophicus is, "The limits of my...

Share on Facebook

Share on Twitter

Share on Google+

Share on Linkedin

Share by email

geopolicraticus

0 likes

 · 

0 comments

"언어의 한계가 내 세계의 한계다." 해를 거듭할 수록 이 말을 대하는 느낌이 달라진다. 처음에는 비트겐슈타인의 말에 딴지를 많이 걸었다. 충분히 길게 설명하면 왠만한 개념은 설명이 가능하다 생각했다. 타이티 섬에는 슬픔이란 단어가 없어 자살률이 높다는 주장 등과 싸잡아 보기도 했고...

그런데 어떤 언어로 의사소통한다는 게 생각보다 많은 속뜻을 담고 있고 있다. 표현의 구조나 어휘를 알고 거의 즉시 반응이 나오도록 노력하다보면, 이게 결국 특정 상황에서 다른 나라 사람처럼 생각하기/반응하기 훈련이 아닌가 여겨질 때가 많다. 문화를 이해해야 한다는 이야기가 흔하게 나오기도 하는데, 좀 거창하긴 하지만 특정 공식이나 문법을 의식하고 매번 한국어 문장을 다른 나라 말로 바꿔가며 말한다면 이는 외국어 학습은 아닌 것 같다. 비슷한 맥락에서 동시 통역은 외국어 능력을 기반으로 한 다른 영역의 훈련이라고 짐작되며, 잘 모르지만 통역대학원의 교과도 그런 내용을 어느 정도 반영하고 있는 것 같다. 

이런 경험을 바탕으로 가끔 배우처럼 나름의 상황을 직접 만들어 몰입해보거나, 영화나 드라마의 상황에 푹 빠져 직접 대사를 따라해보는데 나름 효과가 있다. 더불어 연기에 대한 소질도 발견했다. (-_-;;)b 차가워진 분위기에서 황급히 결론을 내린다.

외국어로 진행되는 의사 소통 과정에서 문맥에 즉각 반응하지 못하는 상황이 지속적으로 반복된다면 그 동안의 외국어 학습은 시간 낭비였다 해도 좋을 듯. 토익/토플 등의 점수가 몇 점이건 간에...

Share on Facebook

Share on Twitter

Share on Pinterest

Share on Google+

Share on Linkedin

Share by email

Dongwook Lee

Fri, Aug 03 2012 17:40:43

ReplyRetweet

0 likes

 · 

0 comments

[yakshavinglocus-blog]

The Wizard of Oz

사회 여러 요소를 재정의하고, 삶의 변화를 주도하는 IT 기술. 그 뒤에선 무관심 일색인 오즈의 마법사가 키보드를 두드리고 있는 걸지도 모르겠다는 생각이 든다.

[yakshavinglocus-blog]

Form ever follows function.

Louis Sullivan

[yakshavinglocus-blog]

The End of Causality

> 경고: SF 소설 아이디어라 뻘소리가 많음 언제가 될지 모르겠지만 인류의 암울한 미래를 담은 글을 하나 쓰고 싶어 가끔 이런 저런 소재를 모아보곤 한다. 요즘 정리되는 방향은, 우리가 추구하며 발전시킨 가치들이 파국적 결과로 나아가는 연료였으며, 결국 슬픈 결말은 필연이라는 식의 내용을 담고 있다. 우주의 모든 문명이 영원히 번영하지는 못한다 가정하면 그 원인을 어딘가에서 찾아낼 수 있을 것이다. 모든 문명의 번영 속에는 파국적 종말의 재료가 가득차 있고 그 속에서 우리는 번영하지 않을 수도, 멸망을 피할 수도 없다. 한마디로 필연들로 단단하게 묶인 '멸망 패턴'이 우주에 숨어있다 뭐 그런 내용 되겠다. 물론 지금 우리가 사는 이 세상도 같은 결론을 가리키고 있다. 어쩌면 자유를 추구하고, 편하게 살고 싶고, 돈을 많이 벌고 싶어하기에 세상은 멸망으로 치닫는 걸지도 모른다. 구체적인 수준이 아니라 재미없을 듯하여 이 정도로 얼버무린다. 일단 바이러스의 창궐, 외계 문명, 자연 재해 같은 넘쳐나는 '똥밟았다' 시리즈보다 더 손을 쓸 수 없는 소재를 찾고 싶었다. 스토리가 완성될지조차 모르겠지만 이야기를 푸는 재미는 결과적으로 보다 쏠쏠해졌다.

[yakshavinglocus-blog]

Dear Kids: Inflation in last 5 years: 11%; Starting pay for computer science grad increase: 40%.

Aaron Levie

[yakshavinglocus-blog]

나와 같은 eigen vector를 가진 사람

[yakshavinglocus-blog]

I think so much of the time today is spent to impress others despite what really important is to go with my flow. No more "Keeping up with the Joneses", it's old-fashioned.

def doSomething(goal:LifeGoal) { goal match { case "to impress others" => None; case "to go with your life plan" => Some("value") } }

[yakshavinglocus-blog]

Including mine, pretty good amount of our life have already been logged for a several years to the internet. So far, the life caching should be performed via devices attached to your body such as cell phone, shoes with nike plus, and so on, or by observing devices like CCTV in London. ps. btw, I wonder why would anyone want to record their life in detail. hmm...

[yakshavinglocus-blog]

Modern webs are APIs

Armin Ronacher

[yakshavinglocus-blog]

Imagine a search engine that simply removed the top 1 million most popular web sites from its index. What would you discover?

http://millionshort.com/

[yakshavinglocus-blog]

구글 코드잼 2012-SR-C 문제 풀이

다이아몬드 상속 찾아내기 ----------------------------- ### 들어가며 평소 자주 보는 [Outsider][outsider]님을 통해 우연히 2012년 [구글 코드잼][codejam]에 참여했다. 코드잼 덕분에 오랜만에 코딩의 즐거움에 푹 빠져보기도 하고, 느려터진 코딩 속도에 자책도 하는 등 유익한 수련의 시간을 보냈다. 언제나 새로운 먹잇감을 찾아 헤매는(?) Outsider님에게 고마운 맘도 든다. 코드잼 문제가 매번 놀라울 정도로 다양한 스토리를 담고 있지만, 프로그램으로 옮기려고 문제를 분석해보면 유사한 형태의 문제들이 반복되는 것처럼 보인다[^1]. 대강 정리해보면 경우의 수(순열/조합), 경로 탐색 등의 알고리듬과 관련된 요소가 많은 듯하다. 코드잼의 여러 문제 중 그 중 경로 탐색을 재포장한 '다이아몬드 상속 판별하기'의 개인적 풀이를 소개한다. ### 문제 내용 물론 실제 문제는 좀 더 길고 구체적이지만 간단히 요약하면 다음과 같다. > 다중 상속이 가능한 언어에서 전체 클래스에 대한 클래스 다이어그램이 주어졌을 때, 다이아몬드 상속이 포함됐는지를 판별해보자. 더 자세한 내용이 궁금하면 [Codejam 2012 Round 1-C][codejam-src] 사이트를 참고한다. ### 접근 다음과 같은 다이아몬드 상속 관계를 살펴본 결과 몇몇 특징을 발견했다.  1. 우선 다이아몬드 상속 또한 미로 찾기 문제와 비슷하다고 볼 수 있다. 미로의 경우 벽이 없는 방향으로만 갈 수 있다. 클래스 다이어그램은 상속한 부모로만 진행이 가능한 미로와 같다. 2. 일반적으로, 자식 클래스 C에서 부모 클래스 P까지 상속을 거슬러 도달할 수 있는 경로가 2개 이상이면 다이아몬드 상속이다. 3. 다이아몬드 상속은 그림을 그리면 항상 닫힌 곡선을 만든다[^2]. 따라서 다이아몬드 상속을 위해서 모든 클래스를 연결해 볼 필요는 없으며, **부모가 2개 이상인 자식 클래스**와 **자식이 2개 이상인 부모 클래스**를 골라 이들의 연결 관계만 조사하면 된다. ### 목표 코드의 형태 경로의 진행은 자식에서 부모를 찾아가는 방향으로 이루어진다고 가정했다. #### 핵심 메서드의 모양(signature) 핵심 메서드인 pathFinder에 시작 클래스(자식)와 종료 클래스(부모)를 전달하면 접근 경로를 포함된 클래스의 List로 만들어 반환한다. 단, 경로가 2개 이상일 경우도 있으므로 최종 결과는 List의 List가 된다. def pathFinder(start: Claz, dest: Claz): List[List[Claz]] 여담으로 클래스 들의 상속 경로를 다음과 같이 ClazPath라 정의했다. type ClazPath = List[Claz] 이제 pathFinder 메서드는 다음과 같이 표현된다. def pathFinder(start: Claz, dest: Claz): List[ClazPath] #### 재귀 함수를 이용한 경로 탐색 경로 탐색 관련 알고리듬은 상당 수 존재한다. [위키피디아의 Tree Traversal][wiki-tt]을 참고하면 다수의 Graph/Tree 검색 알고리듬이 나온다. 여러가지 방법을 살펴보는 것은 물론 좋지만, 개인적으로 다른 알고리듬을 살펴보기 전에 문제를 충분히 고민해보길 권한다. 경로 찾기는 재귀 호출에 익숙하다면 비교적 쉽게 풀이를 생각할 수 있다. 갈림길이 있는 경로, 즉 부모가 두 개인 자식 클래스를 가정해보자.  갈림길 클래스 A에서 갈 수 있는 경로는 B와 C이다. 전체 경로는 B를 거쳐갈 수 있는 경로 + C를 거쳐갈 수 있는 경로의 합이다. List(A,B,D)를 A::List(B,D)과 같이 표현한다면[^3] 전체 경로는 다음과 같은 구문으로 표현된다. pathFinder(A,D) = List( A::pathFinder(B,D)(0), A::pathFinder(C,D)(0)) 같은 형태로 pathFinder를 재귀적으로 사용하면 전체 경로를 구할 수 있다. 목적지에 도달하지 못하고 끝난 경로는 최종 결과에서 제외시킨다. 참고로 만일 재귀가 성능의 저하 요인이 된다면 tail recursion이 가능한 형태로 변경할 계획이다. 문제를 재귀로 접근하는 사고 방법은 이전에 [순열 구하기][tistory-combination]를 통해 공유한 내용과 유사하다. ### pathFinder 1차 버전 작성한 pathFinder의 최초 버전은 다음과 같다. 리팩토링 여지가 다소 있지만 참고하기 바란다. 클래스의 상속관계 정보를 불러오면서 **부모가 2개 이상인 자식**을 출발점으로, **자식이 2개 이상인 부모**를 목적지로 하여 pathFinder를 이용해 경로를 구하고 2개 이상인지 조사하면 된다. type ClazPath = List[Claz] private def _pathFinder(start: Claz, dest: Claz): List[ClazPath] = { if (start.id == dest.id) return List(Nil) val parentIds: List[Int] = start.parentIds.toList parentIds match { case Nil => List(Nil) case list: List[Int] => { list.flatMap(id => { _pathFinder(clazzes(id), dest).map(clazzes(id):: _) }) } }} def pathFinder(start: Claz, dest: Claz): List[ClazPath] = { val paths:List[ClazPath] = _pathFinder(start,dest); paths.filter( (path) => path !=Nil && path.last.id == dest.id ) } ### 정리 개인적으로 알고리듬을 초반에 파악하고서도 손이 버벅대느라 시간을 낭비해서 아쉬움이 남는다. 간단하게 정리해보면 다음과 같다. * 코딩 수련을 제대로 하지 않았다. - 작은 코드만 작성하고, 책 내용만 보기에 급급했던 결과가 아닐까. - 시간 관리가 필요하다. - 코딩을 하며 손이 버벅되는 건 정말 반성 좀 해야겠다. * 문제 해결 능력은 약간 성장했을지도 모르겠다. - 높은 배점의 문제도 프로그래밍 가능한 형태로 분석하는 건 그렇게 오래 걸리지 않았다. - Scala 등의 몇몇 언어를 통해 프로그래밍 접근이 다양해졌다[^4]. [^1]: 하지만 **코드잼 대선배**인 [blmarket][blmarket-tweet]님은 내가 처음 참여했고 초반만 맛봐서 그렇다 하신다. 좀 더 다양한 문제가 있다는 격언을 남기셨다. [^2]: 주어진 그림에서 1-2-3-5-4-1을 연결하면 닫힌 곡선이 된다. [^3]: ::는 cons 연산자이다. [^4]: Scala는 여러 패러다임 언어들의 특징을 적절히 배합한 Hybrid 언어라 다양한 개념을 다루고 있다. 시간 제한으로 구현에 미치지 못한 내용이 많지만, 다양한 접근 방법을 고려하는데 도움이 됐다. [outsider]: http://blog.outsider.ne.kr [tistory-combination]: http://nephilim.tistory.com/135 [blmarket-tweet]: http://twitter.com/#!/blmarket [codejam]:http://code.google.com/codejam [codejam-src]:http://code.google.com/codejam/contest/1781488/dashboard [wiki-tt]:http://en.wikipedia.org/wiki/Tree_traversal

[yakshavinglocus-blog]

Structural Type, Scala에서의 Duck Typing

대강의 정의

duck typing에 대한 정의는 duck test를 정의한 유명한 문장에 잘 나타난다.

오리처럼 소리내고, 오리처럼 걷는다면 오리라고 불러도 무방하다.

좀 더 구체적으로 정의하면, 해당 객체의 타입을 이용해 객체의 적합성 여부를 검증하기 보다는, 특정 객체가 호출하려는 메세지를 이해할 수만 있다면 사용해도 좋은 객체로 간주하겠다는 의미이다. 위키피디아의 duck typing 설명에 의하면, 다음과 같이 "객체를 구성하는 메서드와 프로퍼티가 객체의 유효 여부를 결정한다"고 정의되어 있다.

an object's current set of methods and properties determines the valid semantics

큰 흐름은 같지만, 개인적으로는 Objective-C와 같이 메시지 호출과 객체의 구성 요소(메서드 혹은 프로퍼티)가 동적으로 분리(dynamic dispatching)될 수 있는 언어를 고려하면, "객체가 메시지를 이해할 수 있다면 유효하다고 간주한다"는 말이 좀 더 정확하다고 생각한다. 메세지 디스패칭을 동적으로 정의할 수도 있기 때문이다.

사전 준비

다음과 같이 클래스 Fish, Duck, Person를 정의하자.

class Fish { def swim = println("fish: swim") } class Duck { def quack = println("duck: quaaaack") def feathers = println("duck: white feathers") } class Person { def think = println("person: therefore I am") def quack = println("person: speak qua~~ack!") def feathers = println("person: wear feather clothing") }

Structural Typing

Scala에서는 Structural Typing으로 type safe한 방법의 Duck Typing을 지원한다. 다음과 같이 Structural Type을 이용해 DuckLike 타입을 선언하자. DuckLike 타입은 quack, feathers 메서드가 정의된 어떤 타입과도 호환된다.

type DuckLike = { def quack; def feathers } // Structural Typing def inTheForest( duckLike: DuckLike ) { duckLike.quack duckLike.feathers }

호출 결과는 다음과 같다.

scala> inTheForest( new Duck ) duck: quaaaack duck: white feathers scala> inTheForest( new Person ) person: speak qua~~ack! person: wear feather clothing scala> inTheForest( new Fish ) <console>:9: error: type mismatch; found : Fish required: DuckLike inTheForest( new Fish ) ^

동적 타입 언어와는 달리 해당 메시지를 이해할 수 있는지 미리 검증한다는 점에서 검증 시점의 차이가 존재한다. Ruby나 Python, Objective-C와 같은 다른 언어에서의 duck typing은 소개한 위키피디아 링크에 나와 있으니 참고하자.

[yakshavinglocus-blog]

iOS 5.0에 추가된 Storyboard에 대한 초간단 데모를 만들어 봤습니다. 이전에 ViewController 단위로 이루어졌던 UI 설계를 전체 UI를, 한 자리에서 전체적인 UI를 보는 컨셉으로 바꾼 기능입니다. View 사이의 화면 전환(transition)을 포함한 전체 UI 흐름을 한 화면에서 조감할 수 있게 되었습니다. [웹에 많은 내용이 등록](http://maniacdev.com/ios-5-sdk-tutorial-and-guide/xcode-4-storyboard/) 되어 있지만, 얼추 스터디에서 짧게 소개하기 좋은 초간단 예제는 보이지 않아 작성해 봤습니다.

[yakshavinglocus-blog]

Scala의 def와 val, 그리고 함수 리터럴

스칼라 스터디 진행 중 필요하다고 느껴 def 와 val에 대한 이야기를 나름 정리해봤다. def와 val에 대한 차이점은 스칼라가 function literal 혹은 function value를 어떻게 다루는지 살펴보면 보다 쉽게 이해할 수 있다.

Function Literal과 Function Value

함수 리터럴(function literal)은 (a:Int)=> a+1 과 같은 형태로 표현되는데, 스칼라에서 함수 리터럴은 실제로는 FunctionN이라는 클래스이다. 여기서 N은 인자 개수를 나타낸다. 예를 들어, 인자가 두 개인 함수 리터럴을 나타내는 클래스는 Function2이다. 스칼라에서 함수 리터럴을 클래스로 취급한다는 사실은 아주 중요하다.

참고로 FunctionN 클래스는 def로 만든 일반적인 함수가 아닌, 함수 리터럴을 나타내는 타입임에 주의한다. 확인을 위해 def로 일반적인 함수를 하나 정의해 보겠다.

scala> def sum(a:Int, b:Int) = a + b sum: (a: Int, b: Int)Int

sum의 타입을 보면 (a: Int, b: Int)Int 인데, 나중에 확인해 보겠지만 이는 함수 리터럴에 해당하는 타입이 아니다. 함수 리터럴이라면 Function2 혹은 (Int, Int):Int 타입이라고 출력되어야 한다.

def로 정의한 함수를 함수 리터럴로 정의한 함수로 만드려면 다음과 같이 partially applied function을 이용하면 된다. 출력 결과에 보이는 function2는 Function2의 인스턴스라는 의미인데, function2와 같이 함수 리터럴을 이용해 만든 인스턴스를 function value라고 한다.

scala> sum _ res1: (Int, Int) => Int = <function2>

위 예에서는 모든 인자를 그대로 활용했지만, 다음과 같이 인자 1개를 고정하면 Function2 대신 Function1의 인스턴스가, 다시 말해 function value가 반환됨을 확인할 수 있다.

scala> sum( 1, _:Int) res2: Int => Int = <function1>

이제 본론으로 들어가 function value와 함수를 fist class로 다루는게 어떤 관계인지 살펴보려고 한다.

partially applied function의 결과는 funciton value임을 확인했다. 이게 뭐 어떻다는 말일까? Java 등의 객체 지향 언어를 사용한 경험이 있다면 다음과 같이 특정 변수에 객체의 인스턴스를 보관하는 것이 아주 자연스럽다.

scala> val person = new Person("아웃사이다", 35)

마찬가지로 함수를 변수에 담거나, 인자로 전달하거나, 함수의 리턴 값으로 반환하기 위해, FunctionN 객체의 인스턴스를 특정 변수에 보관하는 것 또한 가능하다.

scala> val sum = (a:Int, b:Int) => a + b sum: (Int, Int) => Int = <function2>

결국 위 코드는 아래와 같다.

scala> val sum = new Function2[Int, Int, Int] { | def apply(a:Int, b:Int):Int = { | a + b | } | } sum: java.lang.Object with (Int, Int) => Int = <function2> scala> sum(1,2) res0: Int = 3

다시 말하면 스칼라에서는 function literal을 클래스로 정의하여 함수를 first class로 만들었기 때문에, 일반적인 객체인 함수(정확히는 function value)는 다른 객체와 마찬가지로 자유로운 전달이 가능하다.

지금까지 설명한 내용을 이해했다면, stackoverflow 등에 올라온 val에 def에 대한 질문들을 확인해보면 조금 더 이해가 잘 될지도 모르겠다. 한국 스칼라 사용자 모임 메일링 리스트에서 def과 관련된 내용을 이야기 하다가 다음과 같은 링크가 등장했는데, 시간이 되면 확인해보길 바란다. 근본적으로는 같은 내용이지만 조금 다른 질문을 하고 있다.

http://stackoverflow.com/questions/3646756/scala-def-versus-val

def 혹은 val을 오버라이드 할 때 유의 사항

간단하게 정리하면 def를 val로 override하지는 못하지만, val을 def로 override하는 것은 가능하다.

scala> class A { val a=0 }; class B extends A { override def a=1 } // 실패 <console>:4: error: error overriding value a in class A of type Int; method a is not stable class A { val a=0 }; class B extends A { override def a=1 } ^ scala> class A { def a=0 }; class B extends A { override val a=1 } // 성공 defined class A defined class B

A = new B 와 같이 선언하여 사용한다고 하면 A.a는 stateless하다고 가정하고 사용될 것이다. 하지만 실제 구현이 def이면 해당 멤버가 상태가 없다는 것을 보장하기 힘들다. 때문에 Scala에서는 def를 val로 override 하는 것만을 허용한다.