Change 마츠 to Matz

Author: hahwul

doctrine/ko.html

@@ -69,10 +69,10 @@ <h3>프로그래머의 행복을 최적화</h3>
         <p>루비의 원래 이단은 프로그래머의 행복을 최우선으로 두는 것이었습니다. 이전에 프로그래밍 언어와 생태계를 이끌었던 많은 다른 경쟁적이고 유효한 관심사들보다도 말입니다.</p>
         <p>파이썬이 "어떤 일을 하는 데에는 하나의 방법, 가능하면 단 하나의 방법만 있어야 한다"고 자랑할 때, 루비는 표현력과 미묘함을 즐겼습니다. 자바가 프로그래머를 스스로로부터 보호하려는 강력한 방식을 옹호할 때, 루비는 환영 패키지에 날카로운 칼들을 포함시켰습니다. 스몰톡이 메시지 전달의 순수성을 강조할 때, Ruby는 마치 폭식하듯 키워드와 구조를 쌓아갔습니다.</p>
         <p>루비는 다른 것을 가치 있게 여겼기 때문에 달랐습니다. 그리고 대부분의 것들은 프로그래머의 행복을 추구하는 데 기여했습니다. 이 추구는 대부분의 다른 프로그래밍 환경뿐만 아니라 프로그래머가 무엇인지, 그리고 그들이 어떻게 행동해야 하는지에 대한 주류 인식과도 충돌했습니다.</p>
-        <p>루비는 프로그래머의 감정을 인식하고 수용하며 높이 평가했습니다. 그것이 불충분함, 변덕, 또는 기쁨이든 간에 말입니다. 마츠는 기계가 인간 공모자에게 미소를 짓고 아첨하는 것처럼 보이게 하기 위해 놀라운 복잡성의 구현적 장애물을 뛰어넘었습니다. 루비는 우리의 마음의 눈에 단순하고 명확하며 아름답게 보이는 것이 실제로는 후드 아래에서 곡예적인 와이어의 엉킴인 착시 현상으로 가득합니다. 이러한 선택은 무료가 아니었습니다 (이 마법의 음악 상자를 역설계하려고 시도한 JRuby 팀에게 물어보세요!), 그래서 그것들이 매우 칭찬받을 만한 이유입니다.</p>
+        <p>루비는 프로그래머의 감정을 인식하고 수용하며 높이 평가했습니다. 그것이 불충분함, 변덕, 또는 기쁨이든 간에 말입니다. Matz는 기계가 인간 공모자에게 미소를 짓고 아첨하는 것처럼 보이게 하기 위해 놀라운 복잡성의 구현적 장애물을 뛰어넘었습니다. 루비는 우리의 마음의 눈에 단순하고 명확하며 아름답게 보이는 것이 실제로는 후드 아래에서 곡예적인 와이어의 엉킴인 착시 현상으로 가득합니다. 이러한 선택은 무료가 아니었습니다 (이 마법의 음악 상자를 역설계하려고 시도한 JRuby 팀에게 물어보세요!), 그래서 그것들이 매우 칭찬받을 만한 이유입니다.</p>
         <p>프로그래밍과 프로그래머에 대한 대안적 비전에 대한 이 헌신이 루비와의 사랑을 확고히 했습니다. 그것은 단순한 사용의 용이성, 블록의 미학, 단일 기술적 성취가 아니었습니다. 그것은 비전이었습니다. 반문화였습니다. 기존의 전문 프로그래밍 틀에서 벗어난 부적응자들이 소속되고 같은 마음을 가진 사람들과 어울릴 수 있는 장소였습니다.</p>
         <p>저는 루비를 발견한 것을 두뇌에 완벽하게 맞는 마법의 장갑을 찾은 것이라고 설명한 적이 있습니다. 제가 상상했던 것보다 더 잘 맞는 장갑이었습니다. 하지만 그것은 그 이상이었습니다. 그것은 '프로그램이 필요해서 프로그래밍을 하는 것'에서 '지적 운동과 표현의 방식으로 프로그래밍에 사랑에 빠진 것'으로 개인적인 전환을 표시한 사건이었습니다. 그것은 <a href="http://www.amazon.com/Flow-Harper-Perennial-Modern-Classics-ebook/dp/B000W94FE6/">몰입의 샘</a>을 발견하고 그것을 마음대로 켤 수 있는 것이었습니다. Csikszentmihalyi의 작업에 익숙한 사람들에게는 이 영향력을 과소평가하기 어렵습니다.</p>
-        <p>루비가 저를 변형시키고 제 인생의 작업 방향을 설정했다고 말하는 것은 과장이 아닙니다. 그 계시는 너무 깊었습니다. 그것은 마츠의 창조물을 전파하는 선교 활동을 하도록 저에게 소명을 부여했습니다. 이 심오한 창조물과 그 혜택을 널리 알리는 것을 돕기 위해서 말입니다.</p>
+        <p>루비가 저를 변형시키고 제 인생의 작업 방향을 설정했다고 말하는 것은 과장이 아닙니다. 그 계시는 너무 깊었습니다. 그것은 Matz의 창조물을 전파하는 선교 활동을 하도록 저에게 소명을 부여했습니다. 이 심오한 창조물과 그 혜택을 널리 알리는 것을 돕기 위해서 말입니다.</p>
         <p>이제 대부분의 여러분이 믿기지 않는다는 듯이 고개를 흔드는 모습을 상상할 수 있습니다. 저는 여러분을 비난하지 않습니다. 만약 누군가가 제가 "프로그래밍은 단지 도구일 뿐"이라는 패러다임 아래에 살고 있을 때 위의 경험을 설명했다면, 저도 고개를 저었을 것입니다. 그리고 아마도 종교적 언어의 과도한 사용에 웃었을 것입니다. 그러나 이것이 진실한 설명이 되려면, 그것이 일부 또는 대부분의 사람들에게 불쾌감을 주더라도 정직해야 합니다.</p>
         <p>어쨌든, 이것이 레일즈에 어떤 의미가 있으며 이 원칙이 어떻게 레일즈의 진화를 계속 이끌고 있는지에 대해 설명하겠습니다. 이를 설명하기 위해 초기 루비를 설명하는 데 자주 사용되었던 또 다른 원칙을 살펴보는 것이 유익하다고 생각합니다: 최소 놀람의 원칙. 루비는 예상대로 작동해야 합니다. 이것은 파이썬과의 대조로 쉽게 설명할 수 있습니다:</p>
 {% highlight ruby %}
@@ -86,10 +86,10 @@ <h3>프로그래머의 행복을 최적화</h3>
 Use exit() or Ctrl-D (i.e. EOF) to exit
 {% endhighlight %}
         <p>루비는 프로그래머가 인터랙티브 콘솔을 종료하고자 하는 명백한 욕구를 수용하기 위해 exit와 quit를 모두 허용합니다. 반면에 파이썬은 프로그래머가 요청한 작업을 올바르게 수행하는 방법을 세세하게 지시합니다. 이는 파이썬이 무엇을 의미하는지 명확히 알고 있음에도 불구하고 (오류 메시지를 표시하고 있기 때문에) 그렇습니다. 이것은 PoLS(최소 놀람의 원칙)의 명확한 예입니다.</p>
-        <p>PoLS가 Ruby 커뮤니티에서 인기를 잃은 이유는 이 원칙이 본질적으로 주관적이기 때문입니다. 누구에게 가장 놀랍지 않은가? 바로 마츠에게. 그리고 마츠와 같은 방식으로 놀라는 사람들에게. Ruby 커뮤니티가 성장하면서, 마츠와 다른 방식으로 놀라는 사람들의 비율도 함께 증가하면서, 이는 메일링 리스트에서 무익한 논쟁의 원천이 되었습니다. 그래서 이 원칙은 배경으로 사라졌고, 사람 X가 행동 Y에 놀랐는지 여부에 대한 논쟁을 더 이상 초대하지 않게 되었습니다.</p>
-        <p>그래서 다시, 이것이 Rails와 무슨 관련이 있을까요? Rails는 최소 놀람의 원칙(To 마츠)과 유사한 원칙으로 설계되었습니다. 더 큰 미소의 원칙(DHH의), 이는 단지 그것이 말하는 그대로입니다: 나를 더 크게, 더 넓게 미소 짓게 할 무엇이든지에 큰 주의를 기울여 설계된 API들. 이렇게 써놓고 보니, 거의 우스꽝스럽게 자기중심적이라는 인상을 주며, 저조차도 그 첫인상에 반박하기 어렵습니다.</p>
-        <p>그러나 Ruby나 Rails와 같은 것을 만드는 것은 적어도 처음에는 깊이 자기중심적인 노력입니다. 두 프로젝트 모두 단일 창조자의 마음에서 비롯되었습니다. 그러나 아마도 저는 여기서 마츠에게 제 자신의 동기를 투영하고 있을지도 모릅니다. 그래서 제가 알고 있는 것으로 제 선언의 범위를 좁히겠습니다: 저는 Rails를 저를 위해 만들었습니다. 우선적으로 저를 미소 짓게 하기 위해서. 그것의 유용성은 제 삶을 더 즐겁게 만드는 능력에 종속되었습니다. 웹 정보 시스템에 대한 요구사항과 요청을 다루는 일상적인 고된 작업을 풍요롭게 하기 위해서였습니다.</p>
-        <p>마츠처럼, 저도 때때로 제 원칙을 위해 어리석은 길을 갔습니다. 한 예로 Inflector는 Person 클래스를 People 테이블로, Analysis를 Analyses로, 단순히 Comment를 Comments로 매핑할 수 있는 영어의 패턴과 불규칙성을 충분히 이해하는 클래스입니다. 이 동작은 이제 Rails의 의심할 여지 없는 요소로 받아들여지지만, 우리가 원칙과 그 중요성을 통합하던 초기에는 큰 논란의 불씨였습니다.</p>
+        <p>PoLS가 Ruby 커뮤니티에서 인기를 잃은 이유는 이 원칙이 본질적으로 주관적이기 때문입니다. 누구에게 가장 놀랍지 않은가? 바로 Matz에게. 그리고 Matz와 같은 방식으로 놀라는 사람들에게. Ruby 커뮤니티가 성장하면서, Matz와 다른 방식으로 놀라는 사람들의 비율도 함께 증가하면서, 이는 메일링 리스트에서 무익한 논쟁의 원천이 되었습니다. 그래서 이 원칙은 배경으로 사라졌고, 사람 X가 행동 Y에 놀랐는지 여부에 대한 논쟁을 더 이상 초대하지 않게 되었습니다.</p>
+        <p>그래서 다시, 이것이 Rails와 무슨 관련이 있을까요? Rails는 최소 놀람의 원칙(To Matz)과 유사한 원칙으로 설계되었습니다. 더 큰 미소의 원칙(DHH의), 이는 단지 그것이 말하는 그대로입니다: 나를 더 크게, 더 넓게 미소 짓게 할 무엇이든지에 큰 주의를 기울여 설계된 API들. 이렇게 써놓고 보니, 거의 우스꽝스럽게 자기중심적이라는 인상을 주며, 저조차도 그 첫인상에 반박하기 어렵습니다.</p>
+        <p>그러나 Ruby나 Rails와 같은 것을 만드는 것은 적어도 처음에는 깊이 자기중심적인 노력입니다. 두 프로젝트 모두 단일 창조자의 마음에서 비롯되었습니다. 그러나 아마도 저는 여기서 Matz에게 제 자신의 동기를 투영하고 있을지도 모릅니다. 그래서 제가 알고 있는 것으로 제 선언의 범위를 좁히겠습니다: 저는 Rails를 저를 위해 만들었습니다. 우선적으로 저를 미소 짓게 하기 위해서. 그것의 유용성은 제 삶을 더 즐겁게 만드는 능력에 종속되었습니다. 웹 정보 시스템에 대한 요구사항과 요청을 다루는 일상적인 고된 작업을 풍요롭게 하기 위해서였습니다.</p>
+        <p>Matz처럼, 저도 때때로 제 원칙을 위해 어리석은 길을 갔습니다. 한 예로 Inflector는 Person 클래스를 People 테이블로, Analysis를 Analyses로, 단순히 Comment를 Comments로 매핑할 수 있는 영어의 패턴과 불규칙성을 충분히 이해하는 클래스입니다. 이 동작은 이제 Rails의 의심할 여지 없는 요소로 받아들여지지만, 우리가 원칙과 그 중요성을 통합하던 초기에는 큰 논란의 불씨였습니다.</p>
         <p>또 다른 예로는 구현 노력이 덜 들었지만 거의 같은 정도의 논란을 일으킨 Array#second에서 #fifth까지 (그리고 좋은 트롤링을 위한 #forty_two). 이 별칭 접근자는 Array#[1], Array#[2] (그리고 Array[41])로도 쓸 수 있는 것을 비난하는 매우 목소리가 큰 구성원들에게 깊은 모욕감을 주었습니다.</p>
         <p>그러나 두 결정 모두 오늘날까지도 저를 미소 짓게 합니다. 저는 테스트 케이스나 콘솔에서 people.third를 쓸 수 있는 것을 즐깁니다. 아니, 그것은 논리적이지 않습니다. 효율적이지도 않습니다. 심지어 병적일 수도 있습니다. 그러나 그것은 계속해서 저를 미소 짓게 하며, 원칙을 충족시키고 제 삶을 풍요롭게 하며, 12년간의 서비스 후에도 Rails에 계속 참여할 수 있는 정당성을 부여합니다.</p>
         <p>성능 최적화와 달리, 행복 최적화는 측정하기 어렵습니다. 이는 거의 본질적으로 비과학적인 노력으로 만들며, 일부에게는 덜 중요하거나 노골적으로 좌절감을 줄 수 있습니다. 프로그래머는 측정 가능한 것을 논쟁하고 정복하도록 교육받습니다. 명확한 결론이 있고 A가 B보다 더 낫다는 것을 범주적으로 보여줄 수 있는 것을 말입니다.</p>