Ruby나 Rails 콘솔을 실행하는 방법은 다양합니다. irb, bundle exec irb, bundle console, rails console이 가장 흔히 쓰이는 명령어죠. 겉보기에는 비슷하지만, 실제로는 각각 동작 방식이 조금씩 다릅니다. 이 차이점을 모르면 여러 가지 문제에 부딪히게 됩니다. ActiveRecord 모델이 데이터베이스에 연결되지 않거나, 파일을 require했는데 엉뚱한 버전이 로드되거나, 당연히 쓸 수 있을 거라 생각했던 라이브러리가 존재하지 않는 경우가 생기죠. 그렇다면 어떻게 하면 상황에 맞는 올바른

Ruby의 each 메서드를 정말 좋아하지만, 한 가지 아쉬운 점이 있습니다. 컬렉션이 비어 있으면 어떻게 될까요? [].each를 호출하면 아무 일도 일어나지 않고 []가 그대로 반환됩니다. 때로는 이것이 원하는 동작일 수 있습니다. 하지만 대부분의 경우, 특히 UI를 개발할 때는 빈 목록을 특별한 방식으로 처리하고 싶어집니다. 예를 들어 데이터가 하나도 없을 때는 별도의 안내 메시지를 보여주고 싶은 경우가 많죠. 그런데 [].each는 nil이 아니라 []를 반환하기 때문에, 어쩔 수 없이 이런 코드를 작성해야 합니다: a

일반적으로 전역 변수는 좋지 않습니다. 하지만 때로는 적절한 위치에 놓인 전역 변수 하나가 코드를 훨씬 단순하게 만들어 주기도 합니다. Rails에서는 요청(request) 중에 한 번 설정한 데이터를 애플리케이션의 모든 계층에서 사용해야 하는 경우가 있습니다. 이 요청을 보낸 사용자는 누구인가요? 어떤 권한을 가지고 있나요? 어떤 데이터베이스 연결을 사용해야 할까요? 이런 정보는 코드 전반에서 접근 가능해야 하므로, 매번 인자로 넘기면 코드가 온통 잡음으로 가득 차게 됩니다. 하지만 Ruby 전역 변수를 사용하거나 클래스 변수

이 글은 몇 달 전 제 뉴스레터 독자들에게 보낸 내용을 바탕으로 작성되었습니다. 매주 이런 글을 받아보고 싶다면 여기서 구독하세요! 이전 글 약간의 편의 기능으로 프로그래밍 흐름 지키기에서는 가장 단순한 추상화조차도 코드베이스를 다루는 즐거움을 배가시킬 수 있다고 이야기했습니다. 그렇다면 나쁜 추상화를 만났을 때는 어떨까요? 분명히 leaderboard라고 지었어야 할 메서드의 실제 이름을 알아내려고 API 레퍼런스를 매번 펴놓고 뒤져야 한다면요? 리팩토링을 시도해도 코드의 한쪽에서는 구조화된 데이터를 넘겨주고 다른 쪽에서는

Rails 튜토리얼을 마치고 직접 앱을 만들기 시작하면 혼란스러워지는 순간이 옵니다. CRUD가 아닌 일반적인 로직은 대체 어디에 넣어야 할까요? 트위터에서 팔로워 목록을 가져오는 기능은 MVC 구조의 어디에 들어맞을까요? 두 사람에게 물으면 네 가지 답이 돌아옵니다. 아니면 스레드가 똑똑한 사람들끼리 몇 시간씩 서로를 비난하는 글타래로 변질되고, 정작 당신만 책상에 머리를 박고 있게 되죠. 어느 쪽이든 결과는 두통뿐입니다. 꿈꾸던 앱을 만들려면 어느 정도의 Rails 바깥의 일반 로직이 반드시 필요합니다. 그렇다면 코드를 어디에

Rails 커뮤니티는 상충되는 조언으로 가득합니다. 테스트 프레임워크는 Minitest를 써야 할까요, 아니면 RSpec을 써야 할까요? 일반 Ruby 객체는 app/models에 두어야 할까요, app/classes일까요, 아니면 lib/일까요?경험 많은 개발자들조차 이런 주제로 끊임없이 논쟁을 벌인다면, 초보 개발자는 대체 어떤 조언을 따라야 할지 어떻게 알 수 있을까요?비결은 생각보다 단순합니다비결은 이것입니다. 그냥 한쪽을 고르고, 그것을 따르세요.무책임한 답변처럼 들릴 수 있습니다. 하지만 이런 논쟁들은 대부분 사소한 철학

직접 만든 앱이 마음에 듭니다. 하지만 한 가지 문제가 있죠. 바로 테스트 코드가 하나도 없다는 것입니다. 원래는 TDD(Test-Driven Development, 테스트 주도 개발)로 작성하고 싶었지만 어디서부터 시작해야 할지 몰라 결국 지금 모습이 되어버렸습니다. 그렇다면 이제 어떻게 해야 할까요? 테스트 없는 앱에서 어떻게 TDD를 적용한 개발로 나아갈 수 있을까요? 1단계: 이미 있는 코드부터 테스트하기 테스트 없이 작성된 코드가 많더라도, 지금이라도 기존 코드에 대한 테스트를 작성할 수 있습니다. 먼저 이미 작성한 코

일상의 사소한 업무에 파묻다 보면 정신을 차리기 어렵습니다. 그렇게 몰입하고 있다 보면, 수많은 작은 걸음이 모여 이룬 실제 성과를 통째로 놓치기도 합니다. 그래서 지난 한 해 동안 제가 쓴 글과 진행한 발표를 돌아보고, 그 과정에서 얻은 가장 값진 배움들을 정리해 보려 합니다. 잘 풀린 일들 1월 10일, 추정치는 목표가 아니라 소통 도구다라는 글로 블로그를 시작했습니다. 2014년 한 해 동안 53개의 글을 올렸으니, 주당 1편을 넘기는 속도입니다! 4월부터는 매주 화요일마다 글을 게시하는 규칙을 세웠습니다. 이렇게 일정을

완벽해 보이던 해결책, 그리고 시작된 예외의 연쇄 정신 나갔던 테스트 문제에 대한 완벽한 해결책을 찾았습니다. DEFAULT_HOST 상수만 오버라이드하면 모든 게 풀릴 것 같습니다. 다만 지저분한 경고 메시지를 없애려면 warnings를 꺼야 합니다. 하지만 이제 모든 테스트가 통과하고, 고친 건 겨우 몇 줄뿐입니다! 그런데 호스트를 오버라이드하지 않고 싶은 테스트가 딱 하나 있습니다. 괜찮습니다. 상수를 다시 오버라이드하고, warnings도 다시 끄고, 테스트가 끝나면 원래대로 되돌려 놓으면 됩니다. 거의 다 온 것 같아

몽키 패치(Monkey Patching). Ruby를 처음 접하는 순간, 그 강력함에 매료됩니다. 핵심 클래스에 메서드를 바로 추가할 수 있으니까요! Time.now.advance(days: -1)처럼 길게 쓰지 않아도 1.day.ago 한 줄이면 끝입니다. 덕분에 Ruby 코드는 읽기도 쓰기도 즐겁습니다. 하지만… 패치가 Hash를 변경하면서 이상한 버그가 튀어나오기 시작합니다. 어떤 코드가 실제로 실행됐는지 파악할 수 없어서, 문제가 생겼을 때 디버깅조차 어렵습니다. 그리고 결국 깨닫게 됩니다. 모든 문제의 원인은 6개월

일부 Rails 앱은 bundle update rails 명령어 한 줄이면 손쉽게 업그레이드할 수 있습니다. 하지만 다른 종류의 앱을 가지고 있다면 어떨까요? 미래로 끌고 가기 귀찮아서 아직도 Rails 4.0, 심지어 3.2에 머물러 있는 앱들 말입니다. 빠른 업그레이드든 고통스러운 업그레이드든, 다음 단계를 따르면 앱을 최대한 매끄럽게 Rails 4.2로 옮길 수 있습니다. 그 과정에서 Rails 4.2의 새로운 기능을 제대로 활용하는 방법도 함께 배우게 될 것입니다. 업그레이드 가이드부터 읽으세요 Rails 업그레이드는

직장에서 팀을 옮겼거나 새 직장에 입사했을 수도 있습니다. 아니면 즐겨 쓰는 오픈소스 앱에서 버그를 발견하고 첫 풀 리퀘스트(PR)를 작성하려고 할 때도 있죠. git clone으로 코드를 받아 app/models 폴더를 열었는데, 정작 아무것도 보이지 않는 경험, 누구나 한 번쯤 있으셨을 겁니다. Rails의 디렉터리 구조는 늘 익숙한 그대로인데도, 정작 코드 속에서는 길을 찾기가 어렵습니다. 그렇다면 낯선 Rails 앱을 가장 빠르게 학습하는 방법은 무엇일까요? 1단계: 프로젝트 용어 사전 만들기 이 앱에서 Player란 무엇일

『Practicing Rails』가 출시되었습니다! 2월 13일 금요일까지 25% 할인 혜택을 누려보세요. 코드를 작성하는 동안 머릿속에는 끊임없이 질문이 떠오릅니다. 이 메서드는 어떻게 호출하지?, 어떤 옵션을 받지?, 숫자 대신 객체를 전달하면 어떻게 될까? 같은 것들 말입니다. 바로 이런 질문들이 여러분의 생산성을 무너뜨립니다. 답을 즉시 알지 못하면 하던 작업을 잊어버리기 쉽습니다. 몰입 상태에서 강제로 이탈하게 되고, 다시 원래 자리로 돌아오는 데 30분이나 걸리기도 합니다. 그렇다면 속도를 늦추지 않으면서 필요한 답

```html Practicing Rails는 압도당하지 않고 Rails를 배우는 방법을 다룬 제 책으로, 드디어 출간되었습니다! 그리고 목요일 밤 11시 59분(태평양 표준시)까지 25% 할인 혜택도 계속됩니다. 책 구매하기: https://www.justinweiss.com/practicing-rails 간단한 배경 이야기 이 블로그를 운영하면서 수많은 분들로부터 비슷한 고민을 들었습니다. 입문용 Rails 책과 영상 강의를 모두 끝내고 Rails의 여러 구성 요소들도 익혔지만, 정작 튜토리얼 수준의 Rails 앱을 넘어서

GitHub 커밋 그래프가 온통 회색으로만 채워져 있나요? 작업할 오픈소스 프로젝트가 필요하겠지만, 굳이 처음부터 새로 시작할 필요는 없습니다. 유용한 사이드 프로젝트를 만드는 가장 쉬운 방법은 지금 개발 중인 앱에서 코드를 꺼내는 것입니다. Rails가 탄생한 방식도 바로 이것이었죠! 그렇다면 어떤 코드를 추출해야 할까요? 그리고 기존 워크플로우를 망가뜨리지 않으면서 어떻게 젬(gem)으로 만들 수 있을까요? 추출할 코드 찾기 앱 깊은 곳 어딘가에, 사실 앱에 속하지 않아도 되는 코드가 숨어 있습니다. 자기 역할을 수행하는

첫 번째 프로덕션 앱을 출시할 준비가 되었고, 이제 외부 서비스와 연동할 차례입니다. 아직 모든 것을 연결해야 하는 상황이죠. 그렇다면 개발 머신을 복잡하게 만들지 않으면서 프로덕션에서 서비스를 설정하는 가장 좋은 방법은 무엇일까요? 환경(Environment) 설정하기 오늘날 프로덕션 앱을 설정하는 모범 사례는 환경 변수(ENV[REDIS_HOST]처럼 생긴 것들)를 사용하는 것입니다. 그런데 왜 그럴까요? 프로덕션 키를 실수로 커밋할 가능성이 줄어듭니다. 주의하지 않으면 중요한 시크릿 키가 담긴 파일

데이터 모델이 복잡해지고 API 응답 시간이 안타깝게도 1초에 육박한다면, 보통 간단한 해결책이 있습니다. 바로 :includes입니다. 모델의 연관 관계(association)를 미리 로드(preload)하면 SQL 호출 횟수를 크게 줄일 수 있고, 그만큼 많은 시간을 절약할 수 있습니다. 그런데 이후에 다시 사이트가 느려지면, 이번에는 응답 자체를 캐싱하는 방법을 고민하게 됩니다. 그리고 여기서 문제가 발생합니다. 캐시에서 응답을 가져오려면 보통 다음과 같은 코드를 작성하게 되는데: results = {lawyer_1: 1, l

ActiveRecord 콜백은 모델의 생명주기 여러 단계에서 코드를 실행할 수 있게 해주는 아주 편리한 기능입니다. 예를 들어 Q&A 사이트를 운영하면서 모든 질문을 검색할 수 있는 기능을 만들고 싶다고 가정해 봅시다. 질문에 변경 사항이 생길 때마다 ElasticSearch 같은 검색 엔진에 해당 내용을 색인(indexing)해야 할 겁니다. 색인 작업은 시간이 걸리고 급한 일이 아니므로 Sidekiq를 이용해 백그라운드에서 처리하는 것이 자연스러운 선택입니다. 이럴 때 after_save 콜백이 딱 맞아 보입니다! 그래서 모

만약 여러분의 Rails 앱이 방문자가 누구인지 전혀 알 수 없다면 어떨까요? 같은 사람이 서로 다른 두 페이지를 요청했다는 사실조차 파악할 수 없다면? 응답을 반환하는 순간 저장해 둔 모든 데이터가 사라져 버린다면? 대부분 정적인 사이트라면 큰 문제가 없을 수도 있습니다. 하지만 대부분의 앱은 사용자에 대한 최소한의 데이터를 저장할 수 있어야 합니다. 사용자 ID일 수도 있고, 선호하는 언어일 수도 있으며, iPad에서 항상 데스크톱 버전의 사이트를 보길 원하는지 여부일 수도 있습니다. session은 바로 이런 종류의 데이터를

버그를 수정하다 보면 가장 빠르고 눈에 띄는 변경이 항상 최선의 선택은 아닙니다. 그리고 눈앞에 있는 코드만으로 전체 이야기를 알 수 없습니다. 쉬운 해결책을 넘어서려면 왜 그런 결정이 내려졌는지 알아야 합니다. 즉, 코드 뒤에 숨겨진 역사를 이해해야 하는 것입니다. 코드를 자신 있게 변경하는 데 필요한 지식을 얻을 수 있는 훌륭한 방법 세 가지를 소개합니다. git blame 활용하기 git blame을 사용하면 프로젝트 내 모든 코드 줄의 모든 버전을 추적해서, 해당 코드가 처음 작성된 시점까지 거슬러 올라갈 수 있습니다.