From 8924d78fdfa6de326a38da2a01eaffb8e05acb18 Mon Sep 17 00:00:00 2001 From: HAHWUL Date: Mon, 19 Aug 2024 23:51:23 +0900 Subject: [PATCH] Add korean doctrine Add korean doctrine Update link for korean doctrine Add korean doctrine Update Korean doctrine content and wording --- doctrine/de.html | 3 + doctrine/es.html | 1 + doctrine/fr.html | 1 + doctrine/index.html | 1 + doctrine/ko.html | 290 ++++++++++++++++++++++++++++++++++++++++++++ doctrine/ru.html | 1 + doctrine/zh_cn.html | 1 + doctrine/zh_tw.html | 1 + 8 files changed, 299 insertions(+) create mode 100644 doctrine/ko.html diff --git a/doctrine/de.html b/doctrine/de.html index 0dab6b5a..84d57625 100644 --- a/doctrine/de.html +++ b/doctrine/de.html @@ -50,6 +50,9 @@

Die Rails-Doktrin.

  • 繁體中文
    • +
  • + Korean +
    • diff --git a/doctrine/es.html b/doctrine/es.html index 3fa34793..cbcb50d0 100644 --- a/doctrine/es.html +++ b/doctrine/es.html @@ -29,6 +29,7 @@

    La Doctrina Rails.

  • Russian
  • 简体中文
  • 繁體中文
    • +
  • Korean
    • diff --git a/doctrine/fr.html b/doctrine/fr.html index ba2f11a3..05d7dc84 100644 --- a/doctrine/fr.html +++ b/doctrine/fr.html @@ -29,6 +29,7 @@

    La doctrine Rails.

  • Russian
  • 简体中文
  • 繁體中文
    • +
  • Korean
    • diff --git a/doctrine/index.html b/doctrine/index.html index e6a2f8d5..38458ccc 100644 --- a/doctrine/index.html +++ b/doctrine/index.html @@ -29,6 +29,7 @@

    The Rails Doctrine.

  • Russian
  • 简体中文
  • 繁體中文
    • +
  • Korean
    • diff --git a/doctrine/ko.html b/doctrine/ko.html new file mode 100644 index 00000000..35b64567 --- /dev/null +++ b/doctrine/ko.html @@ -0,0 +1,290 @@ +--- +title: The Rails Doctrine +permalink: /doctrine/ko +redirect_from: + - /doctrine/ko/ +--- + +
    +
    +
    +
    +

    The Rails Doctrine.

    +
    +
    +
    +
    David Heinemeier Hansson
    +
    +
    +
    + + +
    + +
    +
    +
    +
    +
    + +
    +
    +
    +
    +

    Ruby on Rails가 놀라운 성공을 거두며 두각을 나타낼 수 있었던 이유는 새로운 기술과 시기에 맞는 타이밍 덕분이었습니다. 하지만 기술적 우위는 시간이 지나면서 약화되기 마련이며, 좋은 타이밍만으로는 장기적으로 움직임을 유지할 수 없습니다. 따라서 Rails가 어떻게 계속해서 관련성을 유지하고, 그 영향력과 커뮤니티를 확장해 나갈 수 있었는지에 대한 더 넓은 설명이 필요합니다. 저는 그 지속적인 원동력이, 그리고 앞으로도 그럴 것이, Rails의 논쟁적인 원칙이였다고 제안합니다.

    +

    이 원칙은 지난 10년 동안 진화해왔지만, 가장 강력한 기둥 중 대부분은 창립 당시의 것들입니다. 저는 이러한 아이디어의 근본적인 독창성을 주장하지 않습니다. Rails의 주요 성과는 프로그래밍과 프로그래머의 본질에 대한 광범위한 이단적 생각을 중심으로 강력한 부족을 결집하고 육성한 것입니다.

    +

    이제 서론은 이쯤 하고, 제가 생각하는 Rails 원칙의 가장 중요한 아홉 가지 기둥을 소개합니다:

      +
    1. 프로그래머의 행복을 최적화
      2. +
    2. 설정보다 관례
      3. +
    3. 메뉴는 오마카세
      4. +
    4. 단일 패러다임 없음
      5. +
    5. 아름다운 코드 찬양
      6. +
    6. 날카로운 도구 제공
      7. +
    7. 통합 시스템 가치
      8. +
    8. 안정보다 진보
      9. +
    9. 큰 텐트 세우기
      10. +
    +
    +
    +
    +
    + +
    +
    +
    +
    +

    프로그래머의 행복을 최적화

    +

    루비가 없었다면 레일즈도 없었을 것입니다. 따라서 첫 번째 원칙적 기둥이 루비를 만든 핵심 동기에서 직접 가져온 것은 당연합니다.

    +

    루비의 원래 이단은 프로그래머의 행복을 최우선으로 두는 것이었습니다. 이전에 프로그래밍 언어와 생태계를 이끌었던 많은 다른 경쟁적이고 유효한 관심사들보다도 말입니다.

    +

    파이썬이 "어떤 일을 하는 데에는 하나의 방법, 가능하면 단 하나의 방법만 있어야 한다"고 자랑할 때, 루비는 표현력과 미묘함을 즐겼습니다. 자바가 프로그래머를 스스로로부터 보호하려는 강력한 방식을 옹호할 때, 루비는 환영 패키지에 날카로운 칼들을 포함시켰습니다. 스몰톡이 메시지 전달의 순수성을 강조할 때, Ruby는 마치 폭식하듯 키워드와 구조를 쌓아갔습니다.

    +

    루비는 다른 것을 가치 있게 여겼기 때문에 달랐습니다. 그리고 대부분의 것들은 프로그래머의 행복을 추구하는 데 기여했습니다. 이 추구는 대부분의 다른 프로그래밍 환경뿐만 아니라 프로그래머가 무엇인지, 그리고 그들이 어떻게 행동해야 하는지에 대한 주류 인식과도 충돌했습니다.

    +

    루비는 프로그래머의 감정을 인식하고 수용하며 높이 평가했습니다. 그것이 불충분함, 변덕, 또는 기쁨이든 간에 말입니다. 마츠는 기계가 인간 공모자에게 미소를 짓고 아첨하는 것처럼 보이게 하기 위해 놀라운 복잡성의 구현적 장애물을 뛰어넘었습니다. 루비는 우리의 마음의 눈에 단순하고 명확하며 아름답게 보이는 것이 실제로는 후드 아래에서 곡예적인 와이어의 엉킴인 착시 현상으로 가득합니다. 이러한 선택은 무료가 아니었습니다 (이 마법의 음악 상자를 역설계하려고 시도한 JRuby 팀에게 물어보세요!), 그래서 그것들이 매우 칭찬받을 만한 이유입니다.

    +

    프로그래밍과 프로그래머에 대한 대안적 비전에 대한 이 헌신이 루비와의 사랑을 확고히 했습니다. 그것은 단순한 사용의 용이성, 블록의 미학, 단일 기술적 성취가 아니었습니다. 그것은 비전이었습니다. 반문화였습니다. 기존의 전문 프로그래밍 틀에서 벗어난 부적응자들이 소속되고 같은 마음을 가진 사람들과 어울릴 수 있는 장소였습니다.

    +

    저는 루비를 발견한 것을 두뇌에 완벽하게 맞는 마법의 장갑을 찾은 것이라고 설명한 적이 있습니다. 제가 상상했던 것보다 더 잘 맞는 장갑이었습니다. 하지만 그것은 그 이상이었습니다. 그것은 '프로그램이 필요해서 프로그래밍을 하는 것'에서 '지적 운동과 표현의 방식으로 프로그래밍에 사랑에 빠진 것'으로 개인적인 전환을 표시한 사건이었습니다. 그것은 몰입의 샘을 발견하고 그것을 마음대로 켤 수 있는 것이었습니다. Csikszentmihalyi의 작업에 익숙한 사람들에게는 이 영향력을 과소평가하기 어렵습니다.

    +

    루비가 저를 변형시키고 제 인생의 작업 방향을 설정했다고 말하는 것은 과장이 아닙니다. 그 계시는 너무 깊었습니다. 그것은 마츠의 창조물을 전파하는 선교 활동을 하도록 저에게 소명을 부여했습니다. 이 심오한 창조물과 그 혜택을 널리 알리는 것을 돕기 위해서 말입니다.

    +

    이제 대부분의 여러분이 믿기지 않는다는 듯이 고개를 흔드는 모습을 상상할 수 있습니다. 저는 여러분을 비난하지 않습니다. 만약 누군가가 제가 "프로그래밍은 단지 도구일 뿐"이라는 패러다임 아래에 살고 있을 때 위의 경험을 설명했다면, 저도 고개를 저었을 것입니다. 그리고 아마도 종교적 언어의 과도한 사용에 웃었을 것입니다. 그러나 이것이 진실한 설명이 되려면, 그것이 일부 또는 대부분의 사람들에게 불쾌감을 주더라도 정직해야 합니다.

    +

    어쨌든, 이것이 레일즈에 어떤 의미가 있으며 이 원칙이 어떻게 레일즈의 진화를 계속 이끌고 있는지에 대해 설명하겠습니다. 이를 설명하기 위해 초기 루비를 설명하는 데 자주 사용되었던 또 다른 원칙을 살펴보는 것이 유익하다고 생각합니다: 최소 놀람의 원칙. 루비는 예상대로 작동해야 합니다. 이것은 파이썬과의 대조로 쉽게 설명할 수 있습니다:

    +{% highlight ruby %} +$ irb +irb(main):001:0> exit +$ irb +irb(main):001:0> quit + +$ python +>>> exit +Use exit() or Ctrl-D (i.e. EOF) to exit +{% endhighlight %} +

    루비는 프로그래머가 인터랙티브 콘솔을 종료하고자 하는 명백한 욕구를 수용하기 위해 exit와 quit를 모두 허용합니다. 반면에 파이썬은 프로그래머가 요청한 작업을 올바르게 수행하는 방법을 세세하게 지시합니다. 이는 파이썬이 무엇을 의미하는지 명확히 알고 있음에도 불구하고 (오류 메시지를 표시하고 있기 때문에) 그렇습니다. 이것은 PoLS(최소 놀람의 원칙)의 명확한 예입니다.

    +

    PoLS가 Ruby 커뮤니티에서 인기를 잃은 이유는 이 원칙이 본질적으로 주관적이기 때문입니다. 누구에게 가장 놀랍지 않은가? 바로 마츠에게. 그리고 마츠와 같은 방식으로 놀라는 사람들에게. Ruby 커뮤니티가 성장하면서, 마츠와 다른 방식으로 놀라는 사람들의 비율도 함께 증가하면서, 이는 메일링 리스트에서 무익한 논쟁의 원천이 되었습니다. 그래서 이 원칙은 배경으로 사라졌고, 사람 X가 행동 Y에 놀랐는지 여부에 대한 논쟁을 더 이상 초대하지 않게 되었습니다.

    +

    그래서 다시, 이것이 Rails와 무슨 관련이 있을까요? Rails는 최소 놀람의 원칙(To 마츠)과 유사한 원칙으로 설계되었습니다. 더 큰 미소의 원칙(DHH의), 이는 단지 그것이 말하는 그대로입니다: 나를 더 크게, 더 넓게 미소 짓게 할 무엇이든지에 큰 주의를 기울여 설계된 API들. 이렇게 써놓고 보니, 거의 우스꽝스럽게 자기중심적이라는 인상을 주며, 저조차도 그 첫인상에 반박하기 어렵습니다.

    +

    그러나 Ruby나 Rails와 같은 것을 만드는 것은 적어도 처음에는 깊이 자기중심적인 노력입니다. 두 프로젝트 모두 단일 창조자의 마음에서 비롯되었습니다. 그러나 아마도 저는 여기서 마츠에게 제 자신의 동기를 투영하고 있을지도 모릅니다. 그래서 제가 알고 있는 것으로 제 선언의 범위를 좁히겠습니다: 저는 Rails를 저를 위해 만들었습니다. 우선적으로 저를 미소 짓게 하기 위해서. 그것의 유용성은 제 삶을 더 즐겁게 만드는 능력에 종속되었습니다. 웹 정보 시스템에 대한 요구사항과 요청을 다루는 일상적인 고된 작업을 풍요롭게 하기 위해서였습니다.

    +

    마츠처럼, 저도 때때로 제 원칙을 위해 어리석은 길을 갔습니다. 한 예로 Inflector는 Person 클래스를 People 테이블로, Analysis를 Analyses로, 단순히 Comment를 Comments로 매핑할 수 있는 영어의 패턴과 불규칙성을 충분히 이해하는 클래스입니다. 이 동작은 이제 Rails의 의심할 여지 없는 요소로 받아들여지지만, 우리가 원칙과 그 중요성을 통합하던 초기에는 큰 논란의 불씨였습니다.

    +

    또 다른 예로는 구현 노력이 덜 들었지만 거의 같은 정도의 논란을 일으킨 Array#second에서 #fifth까지 (그리고 좋은 트롤링을 위한 #forty_two). 이 별칭 접근자는 Array#[1], Array#[2] (그리고 Array[41])로도 쓸 수 있는 것을 비난하는 매우 목소리가 큰 구성원들에게 깊은 모욕감을 주었습니다.

    +

    그러나 두 결정 모두 오늘날까지도 저를 미소 짓게 합니다. 저는 테스트 케이스나 콘솔에서 people.third를 쓸 수 있는 것을 즐깁니다. 아니, 그것은 논리적이지 않습니다. 효율적이지도 않습니다. 심지어 병적일 수도 있습니다. 그러나 그것은 계속해서 저를 미소 짓게 하며, 원칙을 충족시키고 제 삶을 풍요롭게 하며, 12년간의 서비스 후에도 Rails에 계속 참여할 수 있는 정당성을 부여합니다.

    +

    성능 최적화와 달리, 행복 최적화는 측정하기 어렵습니다. 이는 거의 본질적으로 비과학적인 노력으로 만들며, 일부에게는 덜 중요하거나 노골적으로 좌절감을 줄 수 있습니다. 프로그래머는 측정 가능한 것을 논쟁하고 정복하도록 교육받습니다. 명확한 결론이 있고 A가 B보다 더 낫다는 것을 범주적으로 보여줄 수 있는 것을 말입니다.

    +

    그러나 행복 추구는 미시적 수준에서 측정하기 어렵지만, 거시적 수준에서는 더 명확하게 관찰할 수 있습니다. Ruby on Rails 커뮤니티는 바로 이 추구 때문에 여기에 있는 사람들로 가득합니다. 그들은 더 나은, 더 충만한 직장 생활을 자랑합니다. 이 감정의 집합체에서 승리가 명확합니다.

    +

    따라서 결론을 내리자면: 행복을 최적화하는 것은 아마도 Ruby on Rails의 가장 형성적인 열쇠일 것입니다. 앞으로도 그러할 것입니다.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    설정보다 관례

    +

    Rails의 초기 생산성 모토 중 하나는 "당신은 아름답고 독특한 눈송이가 아닙니다"였습니다. 이는 헛된 개성을 포기함으로써 평범한 결정의 수고를 뛰어넘고, 정말 중요한 영역에서 더 빠르게 진보할 수 있다고 주장했습니다.

    +

    데이터베이스 기본 키의 형식이 무엇인지 누가 신경 쓰나요? 그것이 "id", "postId", "posts_id" 또는 "pid"인지 정말 중요한가요? 이것이 반복적인 숙고를 할 가치가 있는 결정인가요? 아닙니다.

    +

    Rails의 임무 중 일부는 웹을 위한 정보 시스템을 만드는 개발자들이 직면하는 반복적인 결정의 두꺼운 정글을 마체테로 베어내는 것입니다. 이러한 결정은 수천 가지가 있으며, 한 번만 내리면 되는 것이고, 누군가가 대신 해줄 수 있다면 더 좋습니다.

    +

    설정을 관례로 전환하면 숙고에서 벗어날 뿐만 아니라 더 깊은 추상화를 성장시킬 수 있는 풍부한 필드를 제공합니다. Person 클래스가 people 테이블에 매핑된다는 것을 의존할 수 있다면, has_many :people로 선언된 연관 관계를 Person 클래스를 찾도록 매핑할 수 있습니다. 좋은 관례의 힘은 넓은 범위의 사용에서 배당금을 지급한다는 것입니다.

    +

    그러나 전문가의 생산성 향상을 넘어, 관례는 초보자의 진입 장벽도 낮춥니다. Rails에는 초보자가 알 필요도 없이 무지 속에서 혜택을 받을 수 있는 많은 관례가 있습니다. 모든 것이 왜 그런지 알지 못해도 훌륭한 애플리케이션을 만들 수 있습니다.

    +

    프레임워크가 단지 두꺼운 교과서이고 새로운 애플리케이션이 빈 종이라면 이는 불가능합니다. 어디서부터 어떻게 시작해야 할지 파악하는 데 엄청난 노력이 필요합니다. 시작하는 전투의 절반은 당길 실마리를 찾는 것입니다.

    +

    모든 조각이 어떻게 맞물리는지 이해할 때도 마찬가지입니다. 모든 변경에 대해 명확한 다음 단계가 있을 때, 이전에 만들어진 다른 애플리케이션과 동일하거나 매우 유사한 애플리케이션의 많은 부분을 빠르게 진행할 수 있습니다. 모든 것에는 제자리가 있고, 모든 것은 제자리에 있습니다. 제약은 가장 능력 있는 마음조차도 해방시킵니다.

    +

    그러나 모든 것과 마찬가지로, 관례의 힘도 위험이 따릅니다. Rails가 너무 많은 것을 쉽게 할 수 있게 만들면, 애플리케이션의 모든 측면이 미리 잘라진 템플릿으로 형성될 수 있다고 생각하기 쉽습니다. 그러나 대부분의 가치 있는 애플리케이션은 어떤 방식으로든 독특한 요소를 가지고 있습니다. 그것이 5% 또는 1%일지라도 말입니다.

    +

    어려운 부분은 언제 관례에서 벗어날지를 아는 것입니다. 언제 이탈하는 세부 사항이 충분히 중대하여 탈선을 정당화할까요? 저는 대부분의 아름답고 독특한 눈송이가 되려는 충동이 잘못 고려되었으며, Rails에서 벗어나는 비용이 과소평가되었다고 주장하지만, 그 중 일부는 그렇지 않기 때문에 모든 것을 신중하게 검토해야 한다고 생각합니다.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    메뉴는 오마카세

    +

    어떤 음식이 좋은지 모를 때 레스토랑에서 무엇을 주문해야 할지 어떻게 알 수 있을까요? 셰프에게 선택을 맡기면, "좋은" 것이 무엇인지 알기 전에 좋은 식사를 할 수 있을 것이라고 가정할 수 있습니다. 이것이 오마카세입니다. 요리에 대한 전문가가 될 필요도 없고, 어둠 속에서 운 좋게 선택할 필요도 없이 잘 먹을 수 있는 방법입니다.

    +

    프로그래밍에서 이 관행의 이점, 즉 다른 사람들이 스택을 구성하도록 하는 것은 설정보다 관례에서 얻는 이점과 유사하지만 더 높은 수준에서 이루어집니다. CoC가 개별 프레임워크를 최적으로 사용하는 방법에 집중하는 반면, 오마카세는 어떤 프레임워크를 사용하고 그것들이 어떻게 함께 맞물리는지에 관심을 둡니다.

    +

    이는 사용 가능한 도구를 개별 선택으로 제시하고, 개별 프로그래머에게 결정할 특권(그리고 부담!)을 부여하는 존경받는 프로그래밍 전통과 상충됩니다.

    +

    분명히 "작업에 가장 적합한 도구를 사용하라"는 말을 들어보셨을 것이고, 아마도 고개를 끄덕였을 것입니다. 이는 너무나 기본적인 것처럼 들려 논쟁의 여지가 없어 보이지만, "가장 적합한 도구"를 선택할 수 있으려면 "가장 적합한" 것을 자신 있게 결정할 수 있는 기반이 필요합니다. 이는 생각보다 훨씬 어렵습니다.

    +

    이는 레스토랑에서 식사하는 사람의 문제와 유사합니다. 여덟 가지 코스의 식사에서 각 코스를 선택하는 것처럼, 각 개별 라이브러리나 프레임워크를 선택하는 것은 고립된 작업이 아닙니다. 두 경우 모두 목표는 전체 저녁이나 시스템을 고려하는 것입니다.

    +

    그래서 Rails에서는 프로그래머가 자신의 도구 상자에서 각 도구를 선택할 수 있는 개별 특권을 줄이는 대신, 더 나은 도구 상자를 제공하기로 결정했습니다. 그 배당금은 다음과 같습니다:

    +
      +
    1. 숫자에서 오는 안전: 대부분의 사람들이 동일한 기본 방식으로 Rails를 사용할 때, 우리는 공통된 경험을 갖게 됩니다. 이 공통 기반은 사람들을 가르치고 돕는 것을 훨씬 더 쉽게 만듭니다. 접근 방식에 대한 토론의 기초를 마련합니다. 모두가 어젯밤 7시에 같은 쇼를 봤기 때문에 다음 날 그것에 대해 이야기할 수 있습니다. 이는 더 강한 커뮤니티 의식을 조성합니다.
      2. +
    2. 사람들은 동일한 기본 도구 상자를 완성하고 있습니다: 풀스택 프레임워크로서 Rails는 많은 움직이는 부분을 가지고 있으며, 그것들이 어떻게 함께 작동하는지가 개별적으로 무엇을 하는지 만큼이나 중요합니다. 소프트웨어의 고통은 개별 구성 요소에서 오는 것이 아니라 그들의 상호작용에서 오는 경우가 많습니다. 구성 요소가 동일한 방식으로 구성되고 실패하는 공유된 고통을 완화하기 위해 모두가 노력할 때, 우리는 모두 더 적은 고통을 경험하게 됩니다.
      3. +
    3. 대체는 여전히 가능하지만 필수는 아닙니다: Rails는 오마카세 스택이지만, 여전히 특정 프레임워크나 라이브러리를 대체할 수 있습니다. 단지 그렇게 할 필요가 없을 뿐입니다. 이는 개인적인 취향이 명확해질 때까지 이러한 결정을 미룰 수 있음을 의미합니다.
      4. +
    +

    Rails에 오고 머무르는 가장 학식 있고 숙련된 프로그래머조차도 메뉴의 모든 항목에 반대하지는 않을 것입니다. (그렇다면 아마도 Rails에 머물지 않았을 것입니다.) 그래서 그들은 대체를 신중하게 선택하고, 나머지 큐레이션된 공유 스택을 다른 사람들과 함께 즐깁니다.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    단일 패러다임 없음

    +

    단일 중심 아이디어를 선택하고 이를 논리적 결론까지 따르는 것을 건축적 기반으로 삼는 것은 강한 감정적 호소력을 가집니다. 이러한 규율에는 순수함이 있으며, 프로그래머들이 자연스럽게 이 밝은 빛에 끌리는 이유가 분명합니다.

    +

    Rails는 그렇지 않습니다. 그것은 단일하고 완벽한 천 조각이 아닙니다. 그것은 퀼트입니다. 여러 가지 다른 아이디어와 심지어 패러다임의 복합체입니다. 각각을 단독으로 비교하면 보통 충돌하는 것으로 보일 수 있습니다. 그러나 우리가 하려는 것은 그것이 아닙니다. 이는 우수한 아이디어의 단일 챔피언십이 아니며, 단 하나의 승자를 선언해야 하는 것도 아닙니다.

    +

    우리가 Rails MVC 파이에서 뷰를 구축하는 템플릿을 예로 들어보겠습니다. 기본적으로, 이러한 템플릿에서 코드를 추출할 수 있게 해주는 모든 헬퍼는 단지 큰 함수 모음일 뿐입니다! 심지어 단일 네임스페이스입니다. 오, 충격과 공포, 이는 마치 PHP 수프와 같습니다!

    +

    그러나 저는 뷰 템플릿의 많은 추상화에서와 같이 개별 함수가 상호작용할 필요가 거의 없을 때, PHP가 개별 함수를 제시하는 데 있어 옳았다고 주장합니다. 그리고 이 목적을 위해, 단일 네임스페이스, 즉 큰 메서드 모음은 합리적인 선택일 뿐만 아니라 훌륭한 선택입니다.

    +

    이것이 우리가 때때로 뷰를 구축할 때 더 객체 지향적인 것을 원하지 않는다는 의미는 아닙니다. 많은 메서드가 서로와 그 아래의 데이터와 상호 의존하는 경우, 이를 래핑하는 프레젠터 개념은 종종 의존성으로 인해 시큼해진 메서드 수프에 대한 완벽한 해독제가 될 수 있습니다. 그러나 이는 일반적으로 드문 경우에 해당합니다.

    +

    비교해보면, 우리는 일반적으로 MVC 레이어 케이크의 모델을 객체 지향적 선의의 주요 요새로 취급합니다. 객체에 적합한 이름을 찾고, 일관성을 높이며, 결합도를 낮추는 것이 도메인 모델링의 재미입니다. 이는 뷰와 매우 다른 레이어이므로 다른 접근 방식을 취합니다.

    +

    그러나 여기서도 우리는 단일 패러다임의 원칙을 따르지 않습니다. Rails의 Concern(관심사)은 Ruby의 믹스인(mixins) 기능을 활용하여 개별 모델에 매우 넓은 기능 범위를 부여하는 데 자주 사용됩니다. 이는 Concern 메서드가 상호작용하는 데이터와 저장소에 직접 접근할 수 있도록 함으로써 Active Record 패턴과 잘 맞아떨어집니다.

    +

    Active Record 프레임워크의 매우 기초조차도 일부 순수주의자들을 불쾌하게 합니다. 우리는 데이터베이스와 인터페이스하는 데 필요한 로직을 비즈니스 도메인 및 로직과 직접 혼합하고 있습니다. 이러한 경계의 혼합! 그렇습니다, 왜냐하면 이는 웹 애플리케이션 고양이를 벗기는 실용적인 방법으로 입증되었기 때문입니다. 웹 애플리케이션은 거의 항상 도메인 모델의 상태를 지속시키기 위해 어떤 형태로든 데이터베이스와 대화합니다.

    +

    이렇게 이념적으로 유연한 것이 Rails가 다양한 문제를 해결할 수 있게 하는 것입니다. 대부분의 개별 패러다임은 문제 공간의 특정 부분에서 매우 잘 작동하지만, 자연스러운 편안함의 영역을 넘어 적용될 때 어색하거나 경직됩니다. 많은 중첩된 패러다임을 적용함으로써, 우리는 측면을 덮고 후방을 보호합니다. 최종 프레임워크는 개별 패러다임이 허용했을 것보다 훨씬 더 강력하고 능력 있습니다.

    +

    이렇게 많은 프로그래밍 패러다임과의 다중 관계의 대가는 개념적 오버헤드입니다. Rails를 잘 사용하려면 객체 지향 프로그래밍만 알아서는 충분하지 않습니다. 절차적 및 함수적 경험도 잘 갖추는 것이 바람직합니다.

    +

    이것은 Rails의 많은 하위 언어에도 적용됩니다. 우리는 뷰를 위해 JavaScript를 배우거나 때때로 복잡한 쿼리를 위해 SQL을 배우는 것에서 여러분을 그리 많이 보호하려고 하지 않습니다. 적어도 가능성의 정점에 도달하기 위해서는 말입니다.

    +

    그 학습 부담을 덜어주는 방법은 단순히 시작하기 쉽게 만들고, 프레임워크의 모든 측면을 이해하기 전에 실질적인 가치를 지닌 무언가를 만드는 것입니다. 이를 위해 Hello World로의 빠른 접근을 제공합니다. 이미 준비된 테이블과 제공된 애피타이저가 있습니다.

    +

    생각은 초기부터 실질적인 가치를 제공함으로써, Rails의 실무자들이 빠르게 레벨업하도록 장려할 것입니다. 학습의 여정을 장애물이 아닌 기쁨으로 받아들이도록 말입니다.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    아름다운 코드 찬양

    +

    우리는 컴퓨터나 다른 프로그래머가 이해할 수 있도록 코드를 작성할 뿐만 아니라, 아름다움의 따뜻한 빛 속에서 즐기기 위해 코드를 작성합니다. 미적으로 만족스러운 코드는 그 자체로 가치가 있으며, 열정적으로 추구해야 합니다. 이는 아름다운 코드가 항상 다른 우려 사항보다 우선한다는 의미는 아니지만, 우선순위 테이블에서 완전한 자리를 차지해야 한다는 의미입니다.

    +

    그렇다면 아름다운 코드는 무엇일까요? 루비에서는 종종 루비 고유의 관용구와 맞춤형 도메인 특화 언어의 힘이 교차하는 지점에 있습니다. 이는 모호한 경계이지만, 시도해볼 만한 가치가 있습니다.

    +

    다음은 Active Record의 간단한 예입니다:

    +{% highlight ruby %} +class Project < ApplicationRecord + belongs_to :account + has_many :participants, class_name: 'Person' + validates_presence_of :name +end +{% endhighlight %} +

    이것은 DSL처럼 보이지만, 실제로는 세 개의 클래스 메서드 호출로 기호와 옵션을 받는 클래스 정의일 뿐입니다. 여기에는 특별한 것이 없습니다. 하지만 확실히 예쁩니다. 확실히 간단합니다. 이 몇 가지 선언만으로도 엄청난 힘과 유연성을 제공합니다.

    +

    이 아름다움의 일부는 설정보다 관례와 같은 이전 원칙을 존중하는 데서 옵니다. 우리가 belongs_to :account를 호출할 때, 외래 키가 account_id라고 불리며 프로젝트 테이블에 존재한다고 가정합니다. 참가자 연관 관계에 Person 클래스 이름을 지정해야 할 때, 우리는 그 클래스 이름 정의만 필요합니다. 이를 통해 외래 키와 다른 설정 지점을 다시 유도할 것입니다.

    +

    다음은 데이터베이스 마이그레이션 시스템의 또 다른 예입니다:

    +{% highlight ruby %} +class CreateAccounts < ActiveRecord::Migration + def change + create_table :accounts do |t| + t.integer :queenbee_id + t.timestamps + end + end +end +{% endhighlight %} +

    이것이 프레임워크의 힘의 본질입니다. 프로그래머는 ActiveRecord::Migration 서브클래스처럼 특정 관례에 따라 클래스를 선언하고 #change를 구현하면, 프레임워크는 그 주위의 모든 작업을 처리하고 이 메서드를 호출해야 한다는 것을 알 수 있습니다.

    +

    이로 인해 프로그래머가 작성해야 할 코드는 매우 적습니다. 마이그레이션의 경우, rails db:migrate를 호출하여 데이터베이스를 업그레이드하고 이 새로운 테이블을 추가할 수 있을 뿐만 아니라, 다른 호출로 이 테이블을 삭제할 수도 있습니다. 이는 프로그래머가 모든 작업을 직접 수행하고 라이브러리에서 워크플로를 연결하는 것과는 매우 다릅니다.

    +

    때로는 아름다운 코드는 더 미묘합니다. 가능한 한 짧거나 강력하게 만드는 것보다는 선언의 리듬을 흐르게 하는 데 더 중점을 둡니다.

    +

    다음 두 문장은 동일한 작업을 수행합니다:

    +{% highlight ruby %} +if people.include? person +... +if person.in? people +{% endhighlight %} +

    그러나 흐름과 초점은 미묘하게 다릅니다. 첫 번째 문장에서 초점은 컬렉션에 있습니다. 그것이 우리의 주제입니다. 두 번째 문장에서 주제는 분명히 사람입니다. 두 문장의 길이에는 큰 차이가 없지만, 두 번째 문장이 훨씬 더 아름답고 조건이 사람에 관한 곳에서 사용될 때 저를 미소 짓게 할 가능성이 더 높다고 주장합니다.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    날카로운 도구 제공

    +

    루비는 많은 날카로운 도구를 기능의 서랍에 포함하고 있습니다. 이는 우연이 아니라 의도된 것입니다. 가장 유명한 것은 기존 클래스와 메서드를 변경할 수 있는 능력인 몽키 패칭입니다.

    +

    이 능력은 종종 단순히 평범한 프로그래머가 다루기에는 너무 과도하다고 비난받아 왔습니다. 더 제한적인 환경에서 온 사람들은 이 기능 때문에 루비가 파멸할 것이라고 상상하곤 했습니다.

    +

    무엇이든 변경할 수 있다면, "something bold".capitalize가 "Something Bold"를 반환하도록 String#capitalize를 덮어쓰지 못하게 막을 방법이 무엇일까요? 이는 로컬 애플리케이션에서는 작동할 수 있지만, 원래 구현에 의존하는 모든 종류의 보조 코드를 망가뜨릴 수 있습니다.

    +

    정답은 아무것도 없습니다. 루비에는 이성적인 판단을 저버리도록 날카로운 도구를 사용하는 것을 막을 프로그래밍적 방법이 없습니다. 우리는 이러한 좋은 감각을 관례, 유도, 교육을 통해 강요합니다. 부엌에서 날카로운 도구를 금지하고 모두가 숟가락으로 토마토를 자르도록 강요하는 것이 아닙니다.

    +

    몽키 패칭의 반대편에는 2.days.ago와 같은 놀라운 기능을 수행할 수 있는 능력이 있습니다 (이는 현재 날짜로부터 이틀 전의 날짜를 반환합니다). 이제 여러분은 이것이 나쁜 거래라고 생각할 수도 있습니다. String#capitalize를 덮어쓰는 것을 방지할 수 있다면 2.days.ago를 잃는 것이 더 낫다고 생각할 수도 있습니다. 만약 그렇다면, 루비는 아마도 여러분에게 맞지 않을 것입니다.

    +

    그러나 핵심 클래스와 메서드를 변경할 수 있는 능력이 루비를 언어로서 파멸시켰다고 주장하기는 어렵습니다. 반대로, 이 언어는 프로그래머의 역할에 대해 다른 급진적인 관점을 제공했기 때문에 번성했습니다: 프로그래머가 날카로운 도구를 신뢰받을 수 있다는 것입니다.

    +

    그리고 단지 신뢰받을 뿐만 아니라, 그러한 능력 있는 도구를 사용하는 방법을 배울 수 있다는 것입니다. 대부분의 프로그래머가 더 나은 프로그래머가 되기를 원하고, 날카로운 도구를 사용하면서 손가락을 자르지 않을 수 있는 능력을 갖추기를 원한다고 가정함으로써 전체 직업을 향상시킬 수 있다는 것입니다. 이는 매우 야심찬 아이디어이며, 다른 프로그래머에 대한 많은 프로그래머의 직관에 반하는 것입니다.

    +

    날카로운 도구의 가치를 논쟁할 때 항상 다른 프로그래머에 관한 것입니다. 저는 아직 "이 능력을 신뢰할 수 없으니, 제발 저에게서 빼앗아 주세요!"라고 말하는 프로그래머를 본 적이 없습니다. 항상 "다른 프로그래머들이 이것을 남용할 것 같습니다."라는 말입니다. 이러한 부성주의적 태도는 저에게 매력적이지 않았습니다.

    +

    이제 Rails로 넘어갑니다. 프레임워크가 제공하는 도구는 언어가 제공하는 것만큼 날카롭지는 않지만, 여전히 충분히 날카로운 도구가 있습니다. 우리는 이러한 도구를 키트의 일부로 제공하는 것에 대해 사과하지 않을 것입니다. 사실, 우리는 동료 프로그래머의 야망을 신뢰할 수 있는 용기를 축하해야 합니다.

    +

    Rails의 많은 기능은 시간이 지남에 따라 "너무 많은 자유"를 제공한다고 논쟁되었습니다. 그러나 현재 유행하는 예는 concerns 기능입니다. 이는 루비의 내장 기능인 모듈 주위에 얇은 구문 설탕 층을 두른 것이며, 단일 클래스가 여러 관련 있지만 독립적으로 이해되는 관심사를 캡슐화할 수 있도록 설계되었습니다 (따라서 이름이 붙여졌습니다).

    +

    비난은 concerns가 객체를 부풀리기 쉬운 프로그래머에게 새로운 서랍 세트를 제공한다는 것입니다. 이는 사실입니다. concerns는 실제로 그렇게 사용될 수 있습니다.

    +

    그러나 큰 오류는 concerns와 같은 기능을 제공하지 않음으로써, 심지어 약간의 능력을 가진 손에 의해 사용될 때 개념의 우아한 부분적 분리를 허용하는 기능을 제공하지 않음으로써, 프로그래머를 건축적 행복의 길로 인도할 것이라고 생각하는 것입니다. 만약 여러분이 부엌 싱크대를 과도하게 채운 concerns에서 제외할 수 없다면, 그렇지 않더라도 우아함의 빛나는 등대를 얻을 가능성은 낮습니다.

    +

    날카로운 도구를 다루는 법을 배우지 않은 프로그래머는 아직 머랭을 만들지 못할 것입니다. 여기서 중요한 단어는 '아직'입니다. 저는 모든 프로그래머가 완전한 능력을 갖춘 루비와 레일즈 프로그래머가 될 수 있는 길, 아니 권리가 있다고 믿습니다. 그리고 능력 있다는 것은 그들이 언제, 어떻게, 그들의 상황에 따라 서랍에 있는 다양한 때로는 위험한 도구를 사용해야 하는지 알 만큼 충분히 지식이 있다는 것을 의미합니다.

    +

    이는 그들이 그곳에 도달하도록 돕는 책임을 포기하는 것이 아닙니다. 언어와 프레임워크는 누구든지 전문가가 될 수 있도록 도와주고 안내할 수 있는 인내심 있는 교사가 되어야 합니다. 도구를 잘못 사용하고, 약간의 피, 땀, 그리고 아마도 눈물까지 흘리는 실수의 땅을 거쳐야만 신뢰할 수 있는 길이 있다는 것을 인식하면서 말입니다. 다른 방법은 없습니다.

    +

    루비 온 레일즈는 셰프와 셰프가 되기를 원하는 사람들을 위한 환경입니다. 처음에는 설거지를 할 수도 있지만, 주방을 운영하는 위치까지 올라갈 수 있습니다. 그 여정의 일부로 최고의 도구를 신뢰받을 수 없다고 말하는 사람들의 말을 듣지 마세요.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    통합 시스템의 가치

    +

    Rails는 다양한 맥락에서 사용할 수 있지만, 그 첫 번째 사랑은 통합 시스템을 만드는 것입니다: 장엄한 모놀리식! 전체 문제를 해결하는 전체 시스템입니다. 이는 Rails가 실시간 업데이트를 위해 필요한 프론트엔드 JavaScript부터 프로덕션에서 데이터베이스를 한 버전에서 다른 버전으로 마이그레이션하는 방법까지 모든 것에 관심이 있다는 것을 의미합니다.

    +

    이는 우리가 논의한 것처럼 매우 넓은 범위이지만, 한 사람이 이해하기에 현실적일 정도로 넓지는 않습니다. Rails는 특히 이러한 전체 시스템을 만들기 위해 일반주의 개인을 장비하는 것을 목표로 합니다. 그 목적은 전문가를 작은 틈새로 분리하고 지속적인 가치를 지닌 무언가를 만들기 위해 그러한 전체 팀을 필요로 하는 것이 아닙니다.

    +

    개인을 강화하는 데 중점을 두는 것이 통합 시스템을 가리킵니다. 통합 시스템에서는 많은 불필요한 추상화를 제거하고, 레이어 간의 중복을 줄이며 (예: 서버와 클라이언트 모두에서 템플릿), 무엇보다도 시스템을 절대적으로, 확실히 분산시키기 전에 분산시키는 것을 피할 수 있습니다.

    +

    시스템 개발의 많은 복잡성은 A와 B 사이의 호출을 제한하는 요소들 간의 새로운 경계를 도입하는 데서 비롯됩니다. 객체 간의 메서드 호출은 마이크로서비스 간의 원격 프로시저 호출보다 훨씬 간단합니다. 분산의 영역으로 들어가는 사람들을 기다리는 실패 상태, 지연 문제, 종속성 업데이트 일정의 새로운 세계가 있습니다.

    +

    때로는 이러한 분산이 단순히 필요합니다. 다른 사람들이 HTTP를 통해 호출할 수 있는 웹 애플리케이션 API를 만들고 싶다면, 많은 문제를 감수하고 처리해야 합니다 (비록 요청을 보내는 것보다 요청을 받는 것이 훨씬 쉽지만 – 다운타임은 다른 사람의 실패 상태입니다!). 그러나 이는 적어도 개인 개발 경험에 가해지는 제한된 피해입니다.

    +

    더 나쁜 것은 시스템이 조기에 분해되어 서비스나, 더 나쁘게는 마이크로서비스로 나뉘는 경우입니다. 이는 종종 현대 인터넷 애플리케이션을 원한다면 시스템을 여러 번 구축해야 한다는 오해에서 시작됩니다: 서버 측에서 한 번, JavaScript MVC 클라이언트 측에서 한 번, 각 네이티브 모바일 애플리케이션마다 한 번 등. 이는 자연의 법칙이 아니며, 그렇게 할 필요는 없습니다.

    +

    여러 앱과 접근 방식에서 전체 애플리케이션의 큰 부분을 공유하는 것이 가능합니다. 데스크탑 웹과 네이티브 모바일 앱에 포함된 동일한 컨트롤러와 뷰를 사용할 수 있습니다. 가능한 한 많은 것을 그 장엄한 모놀리식, 즉 통합 시스템 내에서 중앙 집중화할 수 있습니다.

    +

    속도, 사용자 경험 또는 개발자를 조기에 분산시키는 잘못된 속성 측면에서 거의 아무것도 포기하지 않고도 이 모든 것을 할 수 있습니다.

    +

    우리가 추구하는 것은 대부분의 것을 갖는 것입니다: 개별적으로 조정되고 분산된 애플리케이션의 모든 힘과 단일 통합 시스템의 사용 용이성과 이해를 모두 갖추는 것입니다.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    안정성보다 진보

    +

    Rails처럼 10년 이상 존재해 온 시스템은 자연스럽게 경직되는 경향이 있습니다. 과거의 동작에 의존하는 누군가에게는 모든 변화가 문제가 될 수 있는 백만 가지 이유가 있습니다. 그리고 개인에게는 그 이유가 타당합니다.

    +

    그러나 보수적인 목소리에 너무 귀를 기울이면, 우리는 반대편에 무엇이 있는지 결코 알 수 없습니다. 우리는 진화하고 성장하기 위해 때때로 과감히 깨고 변화를 시도해야 합니다. 이러한 진화가 Rails가 앞으로의 10년(또는 그 이상) 동안 생존하고 번영할 수 있게 할 것입니다.

    +

    이론적으로는 이해하기 쉽지만, 실제로 받아들이기는 훨씬 어렵습니다. 특히 주요 버전의 Rails에서 하위 호환되지 않는 변경으로 인해 애플리케이션이 깨질 때 그렇습니다. 그럴 때 우리는 이 가치를 기억해야 합니다. 안정성보다 진보를 소중히 여기며, 문제를 디버그하고 해결하고 시대에 맞춰 나아갈 힘을 얻기 위해서입니다.

    +

    이는 불필요하거나 과도한 고통을 무작위로 가하는 면허가 아닙니다. 2.x에서 3으로의 대규모 Rails 마이그레이션은 많은 사람들에게 여전히 상처로 남아 있습니다. 그것은 힘든 일이었습니다. 많은 사람들을 오랫동안 2.x에 남겨두고, 일부는 설득할 수 없을 정도로 실망했습니다. 그러나 큰 그림에서 보면 여전히 가치가 있었습니다.

    +

    이것이 우리가 계속해서 해야 할 어려운 거래입니다. 오늘 우리가 하는 변화로 인해 Rails가 5년 후에 더 나아질까요? 향후 몇 년 동안 작업 큐잉이나 WebSockets와 같은 다른 문제 도메인을 채택함으로써 Rails가 더 나아질까요? 그렇다면, 이를 감수하고 작업을 수행합시다.

    +

    이 작업은 Rails 자체에서만 필요한 것이 아니라, 더 큰 루비 커뮤니티에서도 필요합니다. Rails는 루비의 발전을 돕기 위해 구성원들이 최신 버전을 더 빨리 채택하도록 유도하는 최전선에 있어야 합니다.

    +

    우리는 지금까지 매우 잘 해왔습니다. 제가 시작했을 때부터, 우리는 루비 1.6, 1.8, 1.9, 2.0, 2.1, 2.2, 2.3, 2.4, 2.5, 그리고 이제 2.6으로 이동했습니다. 그 과정에서 많은 주요 변화가 있었지만, Rails는 루비를 지원하고 모든 사람이 더 빨리 프로그램에 참여할 수 있도록 도왔습니다. 이는 루비의 주요 대중화자로서 Rails가 제공하는 특권이자 의무의 일부입니다.

    +

    이것은 체인의 보조 도구에도 해당됩니다. Bundler는 한때 논란이 많은 아이디어였지만, Rails가 공유된 미래의 초석으로 삼겠다는 주장 덕분에 오늘날 당연하게 여겨집니다. 자산 파이프라인과 지속적인 명령 프로세스인 Spring과 같은 것들도 마찬가지입니다. 이 세 가지 모두 성장통을 겪었거나 여전히 겪고 있지만, 장기적인 가치의 명확성 덕분에 우리는 이를 극복할 수 있었습니다.

    +

    진보는 궁극적으로 사람들과 그들의 변화 추진 의지에 관한 것입니다. 이것이 Rails Core나 Rails Committers와 같은 그룹에 평생 자리가 없는 이유입니다. 두 그룹 모두 프레임워크의 진보를 위해 적극적으로 일하는 사람들을 위한 것입니다. 일부에게는 그러한 진보에 대한 기여가 몇 년 동안 지속될 수 있으며, 우리는 그들의 서비스에 영원히 감사할 것입니다. 다른 사람들에게는 수십 년 동안 지속될 수 있습니다.

    +

    마찬가지로, 우리는 커뮤니티의 새로운 구성원을 계속 환영하고 격려하는 것이 매우 중요합니다. 우리는 더 나은 진보를 이루기 위해 신선한 피와 신선한 아이디어가 필요합니다.

    +
    +
    +
    +
    + +
    +
    +
    +
    +

    큰 텐트를 세우다

    +

    많은 논란의 여지가 있는 아이디어를 가지고 있는 Rails는 모든 사람들이 항상 모든 원칙에 완전히 순응하도록 요구한다면, 이념적 은둔자의 고립된 그룹이 될 수 있습니다. 그래서 우리는 그렇게 하지 않습니다!

    +

    우리는 이견이 필요합니다. 우리는 방언이 필요합니다. 우리는 다양한 생각과 사람들이 필요합니다. 이러한 아이디어의 용광로에서 모두가 공유할 수 있는 최고의 공통점을 얻을 수 있습니다. 많은 사람들이 코드나 신중한 논쟁으로 그들의 의견을 기여합니다.

    +

    그래서 이 원칙이 이상화된 형태를 설명했지만, 일상적인 현실은 훨씬 더 미묘하고 흥미롭습니다. Rails는 리트머스 테스트가 거의 없기 때문에 하나의 큰 커뮤니티를 지원할 수 있습니다.

    +

    제가 종종 심각한 불만을 표명한 테스트를 위한 DSL인 RSpec의 지속적인 성공이 완벽한 증거입니다. 제가 왜 그것이 옳지 않다고 생각하는지 얼굴이 파랗게 될 때까지 소리칠 수 있지만, 그것은 여전히 번창하고 번영할 수 있습니다. 그 점이 훨씬 더 중요한 것입니다!

    +

    Rails가 API로 등장한 것도 마찬가지입니다. 저의 개인적인 초점과 헌신은 뷰를 포함하는 통합 시스템에 있지만, 클라이언트와 서버를 분산시키고자 하는 사람들에게도 Rails가 잘 작동할 여지가 분명히 있습니다. 우리는 이것이 부차적인 임무로 공존할 수 있는 한 이를 받아들여야 하며, 저는 그것이 확실히 가능하다고 믿습니다.

    +

    큰 텐트를 세운다는 것은 모든 사람에게 모든 것을 제공하려는 것이 아닙니다. 단지 모든 사람을 파티에 환영하고, 그들이 자신의 음료를 가져오도록 허용하는 것입니다. 우리는 다른 사람들이 우리와 합류하도록 함으로써 우리의 영혼이나 가치를 잃을 필요가 없으며, 새로운 맛있는 음료를 섞는 방법을 배울 수도 있습니다.

    +

    이는 공짜로 이루어지지 않습니다. 환영하는 분위기를 만들기 위해서는 노력이 필요합니다. 특히 커뮤니티의 기존 구성원들과 똑같은 사람들만을 끌어들이려는 것이 목표가 아니라면 더욱 그렇습니다. 진입 장벽을 낮추는 일은 항상 진지하게 받아들여야 할 작업입니다.

    +

    문서에서 철자 오류를 수정하는 것에서 시작한 다음 사람이 다음 위대한 기능을 구현하게 될지 모릅니다. 하지만 미소를 짓고 작은 기여에 대해 감사하다고 말하면 동기 부여가 흐르게 되어 그 가능성을 발견할 수 있습니다.

    +
    +
    +
    +
    diff --git a/doctrine/ru.html b/doctrine/ru.html index e8be0057..ccd11779 100644 --- a/doctrine/ru.html +++ b/doctrine/ru.html @@ -30,6 +30,7 @@

    Rails Соглашение

  • Français
  • 简体中文
  • 繁體中文
    • +
  • Korean
    • diff --git a/doctrine/zh_cn.html b/doctrine/zh_cn.html index 0d515920..d226f8f8 100644 --- a/doctrine/zh_cn.html +++ b/doctrine/zh_cn.html @@ -29,6 +29,7 @@

    Rails 信条

  • Français
  • Russian
  • 繁體中文
    • +
  • Korean
    • diff --git a/doctrine/zh_tw.html b/doctrine/zh_tw.html index 78d359e5..bc56b9d6 100644 --- a/doctrine/zh_tw.html +++ b/doctrine/zh_tw.html @@ -30,6 +30,7 @@

    Rails 基本主義

  • Français
  • Russian
  • 简体中文
    • +
  • Korean