API 문서는 API의 사용 방법을 알려줍니다. 하지만 문제가 생겼을 때는 대부분 혼자 해결해야 합니다. 에러 메시지는 불완전하거나, 오해를 불러일으키거나, 아무런 도움이 되지 않는 경우가 많죠. NoMethodError: undefined method [] for nil:NilClass 같은 메시지를 보고 도대체 무엇부터 해야 할지 막막하기만 합니다. API, 프레임워크, 라이브러리를 배울 때는 모든 것이 순조롭게 흘러갈 때의 사용법만 익혀서는 안 됩니다. 에러가 반환되었을 때 어떻게 대응해야 하는지도 함께 파악해야 합니다.

(이 글은 예전에 필자의 메일링 리스트 구독자들에게 보낸 내용입니다. 마음에 드셨다면 구독을 통해 비슷한 글들을 더 만나보세요!) Rails 생태계는 놀랍도록 빠르게 변합니다. 인쇄 출판물이 감당하기에는 지나칠 만큼 빠른 속도죠. 저처럼 프레임워크와 젬(gem)의 최신 버전을 배우고 싶어 하는 사람이라면 답답할 수밖에 없습니다. 정작 훌륭한 학습 자료들은 대개 몇 버전씩 뒤처져 있거든요. 그래도 이런 자료들은 여전히 큰 가치가 있습니다. 잘 편집된 책, 스크린캐스트, 튜토리얼만큼 라이브러리의 API, 설계 철학, 구조를 깊이 있

메모이제이션(Memoization)은 접근자 메서드의 실행 속도를 높이는 데 활용할 수 있는 기법입니다. 시간이 오래 걸리는 작업, 즉 딱 한 번만 수행하면 되는 작업의 결과를 캐싱해 두는 방식이죠. Rails에서는 메모이제이션이 워낙 널리 쓰이다 보니, 메서드를 자동으로 메모이즈해 주는 모듈까지 포함된 적이 있었습니다. 이후 해당 모듈은 논란 끝에 제거되었고, 지금부터 소개할 가장 보편적인 메모이제이션 패턴을 직접 작성하는 방식으로 대체되었습니다. 하지만 이 기본 패턴만으로는 제대로 동작하지 않는 상황도 분명히 존재합니다. 그래

코드를 테스트 주도로 개발하고 싶은데, 막상 시작이 잘 안 될 때가 있습니다. 객체의 인터페이스가 어떤 모습이어야 할지 확신이 서지 않을 수도 있고, 화창한 여름날에 집중력이 흐트러질 수도 있죠. 생각하고 있는 것을 정말 테스트할 수 있을지 불확실할 수도 있고, 그냥 지금 당장 테스트 코드를 작성하고 싶지 않아 미루고 있을 수도 있습니다. TDD를 하고 싶지 않은 순간에도 TDD의 이점을 누리려면 어떻게 해야 할까요? 프로토타이핑, 버릴 목적으로 만들기 새로운 시스템 컨셉이나 새로운 기술을 사용할 때는 버릴 시스템 하나를 반드

레일즈(Rails) 튜토리얼 몇 개를 끝냈다면, 클래스를 수강하거나 스크린캐스트를 시청해 봤을 수도 있습니다. 튜토리얼 앱을 따라 만들어 보기도 했고요. 이제 레일즈 개발 실력을 한 단계 끌어올릴 때가 됐다는 건 분명합니다. 그런데 어째서인지 막히게 됩니다. 초보자를 위한 책, 강의, 영상은 쏟아져 나오는데, 정작 중급 레일즈 개발자를 위한 튜토리얼은 어디에 있는 걸까요? 예전과는 다른 학습 방식 레일즈 개발자로서 기본기 다지기 단계를 지나는 순간, 학습 자료가 갑자기 사라집니다. 왜 그럴까요? 중급 레일즈 개발자로 성장하는

지난주 Ruby on Rails 팟캐스트에 게스트로 초대받아 출연할 기회가 있었습니다.방송에서는 이 블로그와 메일링 리스트에서 작성하고 있는 글들에 대한 이야기를 시작으로, 책 집필 과정, 좋은 습관을 만드는 방법, 그리고 많은 사람들이 배움의 과정에서 흔히 막히는 지점은 어디인지 등 다양한 주제에 대해 이야기를 나눴습니다.팟캐스트에서 다룬 주제블로그와 메일링 리스트에서 작성하는 글쓰기 이야기책을 집필하며 겪은 경험과 노하우꾸준함을 위한 습관 형성 방법사람들이 학습 과정에서 자주 어려움을 겪는 부분아직 들어보지 않으셨다면, 개발과

Rails의 i18n 라이브러리는 겉보기보다 훨씬 강력한 도구입니다. 단순히 다국어 번역용으로만 쓰라고 만들어진 것이 아닙니다. 화면에 보여지는 텍스트와 그 텍스트를 출력하는 위치를 분리하고 싶은 모든 상황에서 i18n 라이브러리는 유용하게 활용될 수 있습니다. 저는 Avvo에서 근무하면서 i18n을 활용해 정말 흥미로운 작업들을 해왔습니다. 이번 글에서는 실무에서 큰 도움이 되었던 몇 가지 노하우와, 다소 무모해 보이지만 결과적으로 놀라운 성과를 거둔 라이브러리 남용 사례까지 함께 소개하려고 합니다. 자동 HTML 이스케이핑

지난주 Rails 4.2의 첫 번째 베타 버전이 발표되었고, 이미 그 완성도가 인상적이라는 평가를 받고 있습니다. ActiveJob, Web Console, Adequate Record, 외래 키(Foreign Key) 지원 같은 새로운 기능들을 직접 앱에 활용할 수 있다는 점에서 기대감이 큽니다. 하지만 Rails의 진짜 매력은 바로 디테일에 있습니다. 조금만 깊이 들여다보면 잘 홍보되지 않았지만, 일상적인 Rails 개발 작업을 한층 편안하게 만들어 주는 숨은 기능들을 발견할 수 있습니다. 설정 파일 손쉽게 불러오기 솔직히 말하

어떤 애플리케이션도 실제 사용자와 첫 대면 이후에는 원래의 모습 그대로 있을 수 없습니다. 사람들이 실제로 앱을 사용하기 시작하면 반드시 각종 오류에 부딪히게 됩니다. 그래서 대부분의 앱은 운영 환경에 들어가면 오류를 추적하고 보고하는 체계를 갖춥니다. exception_notification 같은 간단한 도구를 쓸 수도 있고, Honeybadger나 Raygun 같은 웹 서비스를 활용할 수도 있습니다. 그런데 곧 문제를 발견하게 됩니다. 똑같은 예외가 하루에도 몇 번씩 반복해서 보고되는 것입니다. 의존하고 있는 외부 웹 서비스

Rails 4.2 발표에는 다가오는 Rails 5에 대한 흥미로운 소식이 담겨 있었습니다. Rails 5는 아마도 Ruby 2.2를 요구할 예정이라고 합니다. 이는 Ruby 2가 제공하는 모든 장점을 제대로 활용하는 최초의 Rails 버전이 된다는 의미입니다. 발표에서는 GC로 관리되는 심볼(garbage collected symbols)과 키워드 인자(keyword arguments)가 언급되었지만, 개인적으로 가장 주목할 만한 Ruby 2 기능은 바로 Module#prepend입니다. alias_method_chain의 장점

(이 글은 몇 달 전 제 뉴스레트 구독자들에게 보낸 내용입니다. 마음에 드셨다면 구독하고 비슷한 글을 더 만나보세요!) 얼마 전 제가 운영하는 앱 하나에서 꽤 묘한 상황을 마주했습니다. Article 모델이 있다고 가정해 보겠습니다. 이 글들은 처음에는 초안(draft) 상태로 생성됩니다. 초안은 최대한 가벼워야 합니다. 본문이 없어도, 심지어 제목이 없어도 즉시 생성하고 수정할 수 있어야 하죠. 하지만 이 글들을 발행할 때는 추가적인 검증이 필요합니다. 제목과 본문 등 필수 요소가 모두 갖춰져 있어야 하는 것입니다. if 문을 여

Ruby를 배우기 전에 Rails를 먼저 배울 수 있을까요? 잠시 동안은 가능합니다. 하지만 앱이 REST 기반 스캐폴드 생성이나 트위터 클론 수준을 넘어 성장하기 시작하면 반드시 벽에 부딪히게 됩니다. 물론 몸으로 익히는 과정에서 어느 정도의 Ruby는 자연스럽게 습득되겠지만, 그 방식으로는 시간이 너무 오래 걸립니다.Rails를 제대로 마스터할 만큼 Ruby를 익히고 싶다면, Ruby를 독립적으로 공부하는 것이 좋습니다. 서점에 가면 Ruby 관련 책이 셀 네 개를 가득 채울 정도로 많습니다. 그중 상당수가 훌륭하지만, 단연 독

루비에서 젬(gem)은 대부분의 경우 그냥 잘 작동합니다. 하지만 루비의 마법에는 큰 문제가 하나 있습니다. 바로 문제가 발생했을 때 그 원인을 찾기가 무척 어렵다는 점입니다. 젬 관련 문제를 자주 겪지는 않겠지만, 한번 문제가 생기면 구글 검색이 의외로 별 도움이 되지 않습니다. 에러 메시지가 너무 일반적이라 여러 가지 원인 중 무엇이든 가능하기 때문입니다. 젬이 루비와 실제로 어떻게 상호작용하는지 이해하지 못하면, 혼자서 이런 문제를 디버깅하기가 매우 힘듭니다. 젬은 마법처럼 보일 수 있지만, 조금만 파고들면 사실 아주 쉽게 이

루비를 배울 수 있는 좋은 곳은 정말 많습니다. 하지만 배움은 단순히 책을 읽거나 영상을 보는 것만이 아닙니다. 진짜 배움이란 문제에 정면으로 부딪히고, 막히고, 고민하고, 답답해하며, 자료를 찾아보고, 문득 이해가 되고, 여기저기 만져보다가, 마침내(드디어!) 동작하는 코드를 완성하는 과정입니다. 배운 것을 직접 사용하지 않으면 오래 기억되지 않습니다. 그리고 제가 직접 경험하며 찾아낸 몇 가지 훌륭한 실천 방법들을 소개합니다. 루비 퀴즈(Ruby Quiz) 루비 퀴즈는 루비로 풀어볼 수 있는 150개가 넘는 짧고 흥미로운 문제

몇 주 전에 저는 RubyGems가 Ruby의 로드 경로(load path)를 관리하는 방식에 대해 글을 썼습니다. 하지만 Rails는 RubyGems를 직접 사용하지 않고, Bundler를 통해 젬을 관리합니다. Bundler의 작동 방식을 모른다면, 젬이 Rails 앱으로 불려 들어오는 과정이 다소 마법처럼 느껴질 수 있습니다. Gemfile에 한 줄을 추가하는 것만으로 어떻게 앱 안에 코드가 들어올까요? Bundler, Rails, RubyGems는 어떻게 협력해서 의존성 관리를 쉽게 만들어 줄까요? 왜 Bundler일까? 저

(『Practicing Rails』에서 발췌한 내용입니다. 뉴스레터에 가입하시면 첫 번째 챕터를 무료로 받아볼 수 있습니다!) 새 앱을 개발하고 있는데, Rails가 자동으로 테스트 파일을 생성해 주었다고 상상해 보세요: test/models/bug_test.rbrequire test_helper class BugTest < ActiveSupport::TestCase # test the truth do # assert true # end end 주석을 해제하고, 적절한 이름을 붙이면 테스트를 작성할 준비가

처음 바둑을 배울 때, 저는 입문서 몇 권을 사서 정독했습니다. 규칙과 기본 전략은 익혔고, 그 안에 분명 재미있는 게임이 숨어 있다는 것도 알았습니다. 하지만 정작 제 눈에는 보이지 않았습니다. 361개의 선택지 앞에서 느낀 압도감 막상 직접 대국을 두려고 하니 혼란스럽고 스트레스를 받았습니다. 둘 수 있는 자리가 361곳이나 되는데, 그중 최선의 수가 어디일까요? 아니, 차마 용납할 만한 수조차 어디일까요? 입문서에서 얻은 지식으로 나쁘지 않은 수를 백 곳 정도로 좁힐 수는 있었지만, 여전히 어디서부터 시작해야 할지 감을 잡기

새로운 라이브러리나 기능을 다루다 보면 문서를 봐도 이해가 잘 안 될 때가 있습니다. 환경 설정이 어려워서 여러 RDoc 문서 사이를 오가며 전체 구조를 파악해야 할 수도 있고, 아예 문서 자체가 존재하지 않는 경우도 있습니다. 아니면 그냥 실제 예시를 많이 봐야 이해가 빠른 학습 스타일일 수도 있죠. 이럴 때 도움이 필요합니다. 하지만 문서 외에 기능 사용법을 어디에서 배울 수 있을까요? GitHub의 숨은 강력한 기능 문서를 넘어 라이브러리나 기능의 실제 활용 사례를 확인하고 싶다면 GitHub 코드 검색을 활용하세요.

Rails에서 스캐폴드(scaffold)를 생성하면 익숙한 respond_to 블록이 함께 만들어집니다. app/controllers/tasks_controller.rb def destroy @task.destroy respond_to do |format| format.html { redirect_to tasks_url, notice: Task was successfully destroyed. } format.json { head :no_content } end end 그런데 i

블록만 받는 함수에 메서드를 그대로 넘겨주고 싶은 적이 있었나요? 아니면 호출하려던 메서드가 객체의 어떤 상위 클래스에서 엉망이 되었는지 추적해 본 적이 있으신가요? 이런 작업들은 method 메서드 하나면 아주 간단하게 처리할 수 있습니다. 잘만 활용하면 의존성을 파악하고, 몇 시간씩 걸릴 디버깅을 단축하며, 코드를 원하는 곳 어디든 보낼 수 있습니다. 람다처럼 쉽게 다루는 메서드 Ruby에는 블록이나 람다를 인자로 받는 메서드가 많습니다. 하지만 람다를 넘기듯 메서드를 다른 메서드에 직접 전달할 수는 없죠. 먼저 metho