2017/170221-1.jpg

DHH의 생각(을 읽은 후 내 생각)

  • (Rails를 만든 것으로 유명한) DHH가 Quora에서 질문을 받는 세션을 가졌다. [1]
  • 재밌는 질문들이 많았다.
  • 예를 들면
    • “2017년에 Rails 프레임워크를 배울 가치가 뭐야?”
    • “JavaScript 프레임워크가 Rails를 먹게될까?”
    • “왜 Python이 아니라 Ruby로 Rails를 만들었니?”
    • 등
  • 질문만 봐도 막 읽고 싶어진다.
  • 게다가 DHH는 글을 잘 쓴다.
  • 전부 읽은 후, 내 생각과 비슷하다고 느꼈다.
    • 오래전부터 내가 DHH에게 영향을 많이 받았다는 증거겠지.

While we’ve seen a lot a progress in the JavaScript world, we’ve also seen a regression to the complexity-laden world that Rails offered refuge from in the early days. Back then the complexity merchant of choice was J2EE, but the complaints are uncannily similar to those leveled against JavaScript today. That people spent hours, if not days, just setting up the skeletons. The basic build configurations. Assembling and cherry-picking from lots of little libraries and frameworks to put together their own snowflake house variety.

  • 13년 전 J2EE와 비교할 정도로 현재의 JavaScript world를 복잡하다고 DHH는 생각하고 있다.
  • 나도 현재 JavaScript world에서 만들어지는 것들을 좋아하지 않는다.
    • 만약 spreadsheet 정도의 SPA를 만들어야 한다면 redux 등은 어쩔 수 없는 선택지다.
    • 하지만 선택하기 전에, 오버엔지니어링이 아닌지 일단 의심해봐야 한다.
      • 오버엔지니어링, 이른 최적화는 모든 악의 근원이다.
    • JavaScript world는 앞으로 크게 변할 것이다.
    • 아마 몇년 뒤에는 지금과 많이 달라지고, 그 때는 나도 생각이 달라질 수 있겠지.
      • hibernate를 처음 봤을 때의 생각과, 지금의 생각이 다른 것 처럼.

That by formalizing conventions, eliminating valueless choices, and offering a full-stack framework that provides great defaults for anyone who wants to create a complete application, we can make dramatic strides of productivity. … The vast majority of activity today is for yet another option on the a la carte menu. Yet another build system, yet another view library, yet another ORM. Very little activity in integrated solutions.

  • Rails는 full-stack framework를 목표로 하고 있다.
    • conventions을 formalizing
    • 가치없는 선택지 제거
    • 디폴트 제공
    • 등으로 높은 생산성을 만든다.
  • 즉, Rails는 integrated solutions 를 지향한다.
  • 이 목표의 프레임워크는 Rails가 독보적이다.
  • Rails 이외의 대다수 프레임워크는 그 반대편에 있고, 아래의 방향으로 개발된다.
    • 또 다른 option을 만든다.
    • 또 다른 빌드 시스템을 만든다.
    • 또 다른 view library를 만든다.
    • 또 다른 ORM을 만든다.

You get to use Ruby, which, even in a world that has rediscovered the benefits of functional programming and immutability, remains the most extraordinarily beautiful and luxurious language I’ve yet to encounter. Just look at some code. I dare you not to fall in love.

  • Ruby는 함수형 언어의 장점이 재발견된 이 시대에 와서도 DHH가 본 언어중 가장 아름다운 언어라고.
  • 동의 한다.
  • 사실 난 python과 ruby의 선택 시점에서 ruby를 선택했던 이유는 처음엔 단순했다.
    • string interpolation이 ruby에선 되고, python은 안 되는게 가장 컸다. [2]
      • 최근 python3.6 부터 python도 가능하게 됐다. [3]
      • 하지만 앞에 f를 붙이는 것을 보니, 역시 python과 ruby는 보는 길이 다르다.
    • 나는 4-spaces 보다 2-spaces가 좋다. (사소하다.)
    • python 코드도 가끔 읽을 때가 있는데,
      • 매일 python을 쓰는게 아닌 나에겐 python의 list comprehensions는 익숙해 지지가 않는다.
        • e.g. [x**2 for x in range(10)]
      • 그보다 ruby의 블록이 나에게는 훨씬 쉽고, 코딩도 생각의 속도로 가능하고, 읽는 것도 자연스럽다.
        • e.g. (0..9).map{|x|x**2}

Ruby 2.4

  • 지난 크리스마스, (2016-12-25)
  • ruby2.3 이후 1년만에 ruby2.4가 나왔다. [4] [5]
  • 반올림 함수(Float#round)의 디폴트 동작이 even-half가 뒤는 무시무시한 이야기가 있었다.
    • 실제 preview3 까지 2.5.round의 결과가 2 였다.
    • 많은 논란 끝에 결과적으로는 even-half로 동작하는 옵션이 추가되는 걸로 끝났다.
    • even-half 옵션을 내가 쓸 일이 있을까.
  • rails의 ActiveSupport에 있던 Hash#transform_values가 core에 포함되었다.
  • pry의 binding.pry와 동일한 기능이 irb에도 binding.irb로 추가됐다고 한다.
    • 하지만 pry대신 irb를 쓸 이유는 딱히 없어보인다.
  • true/false만 리턴하는 Regexp#match? 가 추가되었다.
    • Regexp#match 보다 (당연히) 빠르다고 한다.
  • MatchData#named_captures가 추가되었다.
    • 아래처럼 이름있는 captures를 Hash로 리턴하는 메소드인데, 아주 편하겠다. 
      /(?<fname>.+) (?<lname>.+)/.match('Ned Stark').named_captures
#=> {"fname"=>"Ned", "lname"=>"Stark"}