Python property

Python 에는 property라는 것이 있습니다.

간단하게 이해하면 Java의  getter/setter등을 대체 할 수 있는 것입니다.

사실 Java에 property 기능이 없어서 getter/setter 와 같은 관용구가 한 예로 사용되는 것이지 좀 더 넓은 의미인데요, python에서는 attribute를 그대로 노출 시키는 것을 권장하는 것 같습니다.

기본적으로 다음과 같이 씁니다. (pybrain code에서 일부 가져왔습니다)

vectorformat = property(getVectorFormat, setVectorFormat, None, "vectorformat can be '1d', '2d' or 'list'")

첫 인자부터 Read, Write, Delete, Doc 로 이해하시면 됩니다.

(아마도)2.6 부터는 decorator로 제공되며 다음과 같이 사용 할 수 있습니다.

@state.setter

def state(self, k):

        if not (0 <= k <= 2):

            raise ValueError("Must be 0 through 2 inclusive!")

        else:

            self._state = k

좀 더 자세한 내용은 다음의 블로그에 잘 나와있습니다.
http://infohost.nmt.edu/tcc/help/pubs/python27/web/property-function.html
http://blog.dahlia.kr/post/2492201571

그것은 언제나 당신의 잘못이다.

얼마 전, 잘 동작하던 프로그램이 잘 동작하지 않았습니다.
build system이 꼬여 있는 것은 아닌가, 이전 로직에 문제가 있다가 이제야 발생하는 것은 아닌가 등의 여러 원인을 생각하고 분석하면서 시간을 보냈습니다.

그렇게 먼 길을 돌아온 끝에 저는 저의 코드에서 작은 실수를 발견했습니다. ('!'를 빼 먹었더군요)

생각해보면 당연합니다. 제가 commit 한 코드 몇 줄이 가장 최신에 반영이 되었거든요-
그럼에도 저는 저 멀리 있는 것부터 의심하고 있었습니다.

'코딩 호러의 이펙티브 프로그래밍'을 읽다 보면 다음과 같은 항목이 나타납니다.

프로그래밍의 첫 번째 원리: 그것은 언제나 당신의 잘못이다.

네, 그렇습니다. 저의 잘못입니다. 사실 당연히 다른 것들보다 제가 방금 넣은 그것이 가장 문제가 되겠지요.

그럼에도 자신을 돌아보기보다 다른 곳을 먼저 확인하는 것을 보고 '참 아직 멀었구나' 라는 것이 느껴졌습니다.

그래도 그나마 다행이라고 위안 삼는 것은 발견한 직후 팀원들에게 바로 저의 실수로 인한 버그라는 것을 인정하고 그에 대한 수정 로그를 공유 했다는 점입니다. (더욱 다행인 건 해당 버그는 널리 알려지지 않았습니다)

아직 부족한 것이 많아서 그런지 스스로의 허물을 먼저 의심하고 인정하는 일이 쉽게 되지는 않습니다.

뭐, 이런 경험을 쌓다 보면 좀 더 나아지지 않을까 하는 생각을 해봅니다.


문제가 생겼습니까?

그럼 스스로를 먼저 의심하세요

Python Dictionary Key로 boolean 사용

요즘 틈틈이 아주 아주 느린 속도로 pybrain code를 보고 있습니다. python을 잘 못해서 공부하려는 목적으로 보고 있는데, 그래서 인지 신기한(?) 코드가 많네요.

오늘 본 코드는 dictionary 의 key 활용입니다.
우선 간단하게 dictionary에 대해서 설명하면  'key'와 'value' 쌍을 가지는 자료형 입니다. 가장 단순한 예로 다음과 같이 쓸 수 있습니다.

>>> dic = {'key1' : 'value1', 'key2' : 'value2'}

>>> dic['key1']

'value1'

유용하게 자주 쓰는 자료형인데요, key 에 boolean이 포함된 tuple이 쓰일 수 있는 것은 생각 못했습니다. 오늘 발견한 코드가 그 예입니다.

    network_map = {

        (False, False): FeedForwardNetwork,

        (True, False): RecurrentNetwork,

    }

자주 쓰이는 코드 형태인지는 몰라도 유용할 것 같습니다. 다음과 같은 것도 가능합니다.

>>> dic = {(True, False) : "t, f"}

>>> dic[(True, 1==2)]

't, f'

키 자체를 평가해서 위와 같이 값을 구해 올 수 있습니다.

 

매일매일 정보를 공유하면서 느낀점

작년에 회사에서 매일 하던 활동이 하나 있습니다.

'정보 공유 활동' 인데요, 매일매일 사람들에게 제가 알게된 유용한 지식을 전달해 주는 활동입니다. 기사나 블로그등을 공유하였는데, 일부는 직접 해보고 간단한 소감(?)을 덧붙여서 공유를 했습니다.

이를 통해 다른 사람들의 의견을 알고 싶었고, 더 나아가서 다른 사람들도 이러한 활동을 부담없이 했으면 좋겠다는 생각에 시작했습니다. 하지만 예상보다 그러한 변화는 적었습니다.

무엇이 문제였을까요? 요즘 읽고 있는 '제프 앳우드'의 '이펙티브 프로그래밍'에서 '예를 통해 리드하기' 라는 글에 다음의 글이 인용되어 있습니다. (원문은 데니스 포브스(Dennis Forbes)의 글이라고 합니다)

겸손하라. 언제나 일단 자기가 잘못됐다고 가정하라. 개발자들은 실수를 저지르지만, 그리고 새로 들어온 당신은 다른 개발자가 저지른 실수를 발견하고 수정할 수 있게 도와야 하지만 당신이 발견한 사실을 자부심을 가지고 발표하기 전에 그것이 정말로 확실한지 여부를 거듭 확인해야 한다. 잘못 발견한 내용을 가지고 떠들거나 하면 당신의 신뢰도에는 회복할 수 없는 결정타가 가해지기 때문이다.

건설적인 비판에 집중하며 끝까지 신중하라. 청취자의 넓히는 것은 방어논리나 보복을 야기할 가능성을 높인다. 팀은 언제나 당신의 동기가 무엇인지 주목하고있으며, 만약 당신이 자신의 업적을 과시하기 위해 다른 사람들의 업적을 훼손하면 곧바로 발각되어 추방될 것이다.

신뢰와 준경을 얻는 최선의 방법은 엄청난 노력과 실질적인 결과를 보여주는 것뿐이다. 모든 사람에게 좋은 개발 방법론을 이메일로 전송하거나, 어떤 기술을 이용하면 훌룡한 결과를 낳을 거라는 식의 조언을 보내는 식의 값싸고 피상적인 대체물은 동일한 결과를 낳지 못하며, 설령 그렇다고 해도 효과가 지속되지 못한다.

행동은 말보다 설득력이 있다. 팀블로그나 위키, 새로운 소스코드 관리 메커니즘, 혹은 새로운 기술에 대해 말하는 것은 값싼 일이다. 누군가 힘든 노력을 통해 그런 것들을 실제로 구현했을 때 당신은 그저 그 아이디어에 대한 소유권을 주장하려고 하고 있을 뿐이라는 사실을 다른 사람들은 이미 잘 알고 있다. 뭔가를 제안하고자 한다면 제안을 뒷받침하는 노력을 실제로 기울여야 한다. 예를 들어 초보적인 사용자 가이드라인이나 팀블로그에서 사용되는 기술에 대한 실제 데모를 통해 팀블로그의 기초적인 작업이 무엇인지 보여줘야 한다. 이러한 노력이 곧 당신의 아이디어가 채택될 것임을 보장하지는 않는다. 이런 노력이 수포로 돌아갈 수도 있다. 그렇지만 팀은 당신이 손쉽게 신뢰를 얻으려고 하는 것이 아니라 실제 동기를 가지고 있다는 것을 보게된다.

모든 상황에 들어맞는 조언은 없다. 모든 애플리케이션이 수많은 방문자를 자랑하는 전자상거래 사이트인 것은 아니다. 어떤 방법이 단지 널리 사용된다고 해서 당신이 들어가려는 그룹에게도 잘 맞는 설계 철학이라고 할 수는 없다.

제가 특히 뜨끔한 항목은 '행동은 말보다 설득력이 있다. 팀블로그나 위키, 새로운 소스코드 관리 메커니즘, 혹은 새로운 기술에 대해 말하는 것은 값싼 일이다. ' 입니다. 물론 저는 공유 활동 자체가 의미를 가지고 퍼지기를 바랬으므로 조금 다르겠지만, 저러한 마음이 없지는 않았는지 반성해 봅니다.
또한, 글에서 말하는 '행동'을 좀 더 구체적으로 실행하지 않을 것이 잘못되지 않았나 싶은 생각이 듭니다.

그래서 올해부터는 그간의 정보 공유 활동을 중단하고 이를 발전시켜 직접 행동한 것을 가끔씩 공유하는 것을 시도해보려고 합니다.

이유는 다음과 같습니다.

• 위에서 언급한 것과 마찮가지로 '값싼 일'을 하고 싶지는 않습니다. 정말 중요한 것을 제가 직접 해보고 그것을 좀 더 깊이 있게 공유하는 것이 참여를 유도하는 것에 더 도움이 될 것으로 판단됩니다.
• 어째서인지 사람들은(저를 포함하여) 매일매일 오는 무언가를 점차 가볍게 생각하는 경향이 있습니다. 시스템의 경고 이메일도 매일보면 느슷해지는 법이죠. 그래서 비정기적으로 정보를 공유하려고 합니다.
• 개인적으로도 얕은 정보를 공유하는 것보다는 이는 그냥 알고 있고, 중요한 것 몇가지를 깊이있게 보는 것이 더 발전적이라고 느꼈습니다.

올해는 저의 활동이 좀 더 긍정적으로 작용하기를 기대해봅니다. 

블로그 시작합니다

30이 되었습니다.

블로그를 시작합니다.

사실 블로그는 처음이 아닙니다. 

그간 무수한 블로그를 만들고 또 접었습니다.

그럼에도 이렇게 '또' 시작합니다.

이렇게 자꾸 '또' 하다보면, 작게나마 무언가 남아가겠지요-

이번 블로그 시작에서 전과 다른점은 제 이름으로 시작한다는 점이네요.

그전에는 익명으로 활동을 하려고 했는데, 왜인지 이제는 제 이름으로 하는 것이 맞다고 느껴집니다. 

굳이 의미를 붙이자면 30이되어서 그런걸까요? (사실 전부터 느낀거라서 이 이유는 아니겠지만요 :) )

그래서 더 책임을 가지고 이번에는 좀 더 오래, 가능하다면 쭉 블로깅을 했으면 좋겠습니다.