vectorformat = property(getVectorFormat, setVectorFormat, None, "vectorformat can be '1d', '2d' or 'list'")첫 인자부터 Read, Write, Delete, Doc 로 이해하시면 됩니다.
@state.setterdef state(self, k):if not (0 <= k <= 2):raise ValueError("Must be 0 through 2 inclusive!")else:self._state = k
프로그래밍의 첫 번째 원리: 그것은 언제나 당신의 잘못이다.네, 그렇습니다. 저의 잘못입니다. 사실 당연히 다른 것들보다 제가 방금 넣은 그것이 가장 문제가 되겠지요.
유용하게 자주 쓰는 자료형인데요, key 에 boolean이 포함된 tuple이 쓰일 수 있는 것은 생각 못했습니다. 오늘 발견한 코드가 그 예입니다.>>> dic = {'key1' : 'value1', 'key2' : 'value2'}>>> dic['key1']'value1'
자주 쓰이는 코드 형태인지는 몰라도 유용할 것 같습니다. 다음과 같은 것도 가능합니다.network_map = {(False, False): FeedForwardNetwork,(True, False): RecurrentNetwork,}
>>> dic = {(True, False) : "t, f"}
>>> dic[(True, 1==2)]
't, f'키 자체를 평가해서 위와 같이 값을 구해 올 수 있습니다.
겸손하라. 언제나 일단 자기가 잘못됐다고 가정하라. 개발자들은 실수를 저지르지만, 그리고 새로 들어온 당신은 다른 개발자가 저지른 실수를 발견하고 수정할 수 있게 도와야 하지만 당신이 발견한 사실을 자부심을 가지고 발표하기 전에 그것이 정말로 확실한지 여부를 거듭 확인해야 한다. 잘못 발견한 내용을 가지고 떠들거나 하면 당신의 신뢰도에는 회복할 수 없는 결정타가 가해지기 때문이다.
건설적인 비판에 집중하며 끝까지 신중하라. 청취자의 넓히는 것은 방어논리나 보복을 야기할 가능성을 높인다. 팀은 언제나 당신의 동기가 무엇인지 주목하고있으며, 만약 당신이 자신의 업적을 과시하기 위해 다른 사람들의 업적을 훼손하면 곧바로 발각되어 추방될 것이다.
신뢰와 준경을 얻는 최선의 방법은 엄청난 노력과 실질적인 결과를 보여주는 것뿐이다. 모든 사람에게 좋은 개발 방법론을 이메일로 전송하거나, 어떤 기술을 이용하면 훌룡한 결과를 낳을 거라는 식의 조언을 보내는 식의 값싸고 피상적인 대체물은 동일한 결과를 낳지 못하며, 설령 그렇다고 해도 효과가 지속되지 못한다.
행동은 말보다 설득력이 있다. 팀블로그나 위키, 새로운 소스코드 관리 메커니즘, 혹은 새로운 기술에 대해 말하는 것은 값싼 일이다. 누군가 힘든 노력을 통해 그런 것들을 실제로 구현했을 때 당신은 그저 그 아이디어에 대한 소유권을 주장하려고 하고 있을 뿐이라는 사실을 다른 사람들은 이미 잘 알고 있다. 뭔가를 제안하고자 한다면 제안을 뒷받침하는 노력을 실제로 기울여야 한다. 예를 들어 초보적인 사용자 가이드라인이나 팀블로그에서 사용되는 기술에 대한 실제 데모를 통해 팀블로그의 기초적인 작업이 무엇인지 보여줘야 한다. 이러한 노력이 곧 당신의 아이디어가 채택될 것임을 보장하지는 않는다. 이런 노력이 수포로 돌아갈 수도 있다. 그렇지만 팀은 당신이 손쉽게 신뢰를 얻으려고 하는 것이 아니라 실제 동기를 가지고 있다는 것을 보게된다.
모든 상황에 들어맞는 조언은 없다. 모든 애플리케이션이 수많은 방문자를 자랑하는 전자상거래 사이트인 것은 아니다. 어떤 방법이 단지 널리 사용된다고 해서 당신이 들어가려는 그룹에게도 잘 맞는 설계 철학이라고 할 수는 없다.제가 특히 뜨끔한 항목은 '행동은 말보다 설득력이 있다. 팀블로그나 위키, 새로운 소스코드 관리 메커니즘, 혹은 새로운 기술에 대해 말하는 것은 값싼 일이다. ' 입니다. 물론 저는 공유 활동 자체가 의미를 가지고 퍼지기를 바랬으므로 조금 다르겠지만, 저러한 마음이 없지는 않았는지 반성해 봅니다.
