저는 늘 루비(Ruby)에서 예외(exception)가 다른 흐름 제어 메커니즘에 비해 느릴 것이라고 강하게 의심해 왔습니다. 어쨌든 예외는 단순한 break나 return보다 훨씬 복잡한 동작이니까요. 하지만 제 직감이 과거에 틀린 적도 있었기에, 이번 기회에 직접 실험해 보기로 했습니다. 아래 코드에서는 benchmark-ips 젬(gem)을 사용하여 예외, break, return으로 루프를 빠져나가는 세 가지 방식의 상대적 성능을 비교합니다. 웹에서 MRI 1.9로 유사한 벤치마크를 수행한 사례들을 본 적이 있었지만, 저는

열거자(Enumerator)는 Ruby가 강력하고 동적인 언어로 자리 잡은 데 핵심적인 역할을 하는 요소입니다. 그리고 지연 열거자(Lazy Enumerator)는 여기서 한 걸음 더 나아가, 매우 방대한 컬렉션도 효율적으로 처리할 수 있게 해줍니다. 파일은 사실 수많은 줄(line)이나 문자(character)로 이루어진 거대한 컬렉션에 불과합니다. 따라서 지연 열거자를 활용하면 파일로 흥미롭고 강력한 작업을 손쉽게 수행할 수 있습니다. 열거자(Enumerator)란 무엇일까? each 같은 메서드를 사용할 때마다 사실상 열

배열에 데이터가 가득한데, 마치 해시처럼 키/값(key/value) 조회를 하고 싶었던 적이 있으신가요? 다행히 Ruby는 배열을 키-값 구조처럼 다룰 수 있는 메커니즘을 제공합니다. 지금부터 자세히 살펴보겠습니다! Array#assoc와 Array#rassoc 소개 주식 추천 기계를 하나 받았다고 상상해 봅시다. 이 기계는 몇 분마다 특정 주식을 사거나 팔라는 추천을 내놓습니다. 여러분은 이 기계를 컴퓨터에 성공적으로 연결했고, 이제 아래와 같은 형태의 데이터 스트림을 수신하고 있습니다. picks = [ [AAPL, bu

Ruby에는 스크립트가 자기 자신의 소스 파일을 데이터 소스로 활용할 수 있는 방법이 있다는 사실을 알고 계셨나요? 일회성 스크립트나 프로토타입(개념 증명) 코드를 작성할 때 시간을 크게 아껴주는 유용한 기법입니다. 지금부터 하나씩 살펴보겠습니다! DATA와 __END__ 아래 예제에서는 __END__라는 재미있는 키워드를 사용합니다. Ruby 인터프리터는 __END__ 아래에 있는 모든 내용을 무시합니다. 더 흥미로운 점은, Ruby가 DATA라는 IO 객체를 제공한다는 것입니다. 이 객체를 사용하면 마치 일반 파일을 읽듯이

코드가 해당 예외의 생명주기를 직접 제어하지 않더라도 가장 최근에 발생한 예외에 접근할 수 있다면 매우 유용합니다. 예를 들어 애플리케이션에 기본적인 크래시 감지 기능을 추가한다고 상상해 보세요. 잡히지 않은(uncaught) 예외로 인해 발생하는 모든 크래시에 대해 추가 정보를 로그로 남기고 싶을 것입니다. 첫 번째 단계는 애플리케이션이 종료될 때마다 실행되는 핸들러를 추가하는 것입니다. Ruby 커널의 at_exit 메서드를 사용하면 아주 간단하게 구현할 수 있습니다. at_exit do puts the app exited

레거시 애플리케이션을 유지보수하다 보면 가장 골치 아픈 문제 중 하나가 바로 코드가 테스트 가능성을 고려하지 않고 작성되어 있다는 점입니다. 그 결과 의미 있는 테스트를 작성하기 어렵거나, 심지어 불가능한 경우도 많습니다. 이건 전형적인 닭과 달걀의 문제입니다. 레거시 애플리케이션에 테스트를 추가하려면 먼저 코드를 변경해야 하는데, 정작 테스트가 없으면 코드를 안심하고 변경할 수 없기 때문입니다! 이런 역설은 어떻게 해결해야 할까요? 이 주제는 마이클 페더스(Michael Feathers)의 명저 『Working Effecti

Rails 개발이 매력적인 이유 중 하나는, 인증·권한 부여, 사이트 관리, 전자상거래 등 흔히 마주치는 프로그래밍 요구사항이라면 이미 실력 있는 개발자가 해결책을 만들어 젬(gem)이라는 패키지 형태로 공개해 두었다는 점입니다. 물론 Gemfile에 젬을 추가하기만 해도 그 편리함을 충분히 누릴 수 있습니다. 하지만 정작 이 코드들이 어떻게 프로젝트에 연결되고 동작하는지 궁금해 본 적은 없으신가요? 이번 글에서는 Ryan Bates가 만든 CanCan 인증 젬을 예로 들어 다음 세 가지 질문에 답해 보겠습니다. 시야를 조금 넓

요즘 루비(Ruby) 성능에 관한 이야기가 많은데, 그럴 만한 이유가 있습니다. 코드를 조금만 다듬어도 성능을 최대 99.9%까지 끌어올릴 수 있다는 사실이 여러 차례 증명되었기 때문입니다. 그런데 코드를 최적화하는 방법을 다룬 글은 널려 있는 반면, 한 번 최적화된 상태를 어떻게 유지할 수 있는지 이야기하는 글은 드물습니다. 자주 호출되는 메서드 안에 동결된(frozen) 상수 대신 문자열 리터럴을 그대로 삽입하면 그 결과를 매번 신경 쓰지 않게 되기 마련입니다. 이후 코드를 유지보수하는 과정에서 최적화로 얻은 이득은 생각보다 쉽

Gem 설치가 느린 진짜 이유 Gem 설치가 유독 느리게 느껴진 적이 있나요? 가장 큰 원인 중 하나는 바로 문서화 작업입니다. gem을 설치할 때마다 컴퓨터는 해당 gem의 소스 코드를 스캔하고 문서를 생성해야 하기 때문입니다. 로컬 문서는 언제 유용할까? 오프라인 환경에서 자주 gem 문서를 확인해야 한다면 이 기능이 유용할 수 있습니다. gem server 명령어를 실행한 뒤 브라우저에서 https://localhost:8808 에 접속하면 문서를 열람할 수 있습니다. 터미널에서 ri 명령어로 문서를 검색하는 것 역시 편리합

루비에서는 절대 Exception을 rescue하지 마세요! 한 번쯤 들어본 적 있으신가요? 아주 좋은 조언이지만, 이미 내용을 알고 있는 사람이 아니라면 다소 혼란스러울 수 있습니다. 이 문장이 정확히 무엇을 의미하는지 하나씩 살펴보겠습니다. 루비에서는 다음과 같이 예외를 처리(rescue)할 수 있다는 점은 이미 잘 알고 계실 겁니다: begin do_something() rescue => e puts e # e는 에러 정보를 담고 있는 예외 객체입니다. end 또한 에러 클래스 이름을 지정해서 특정 에러만 골

요약: Ruby에서 셸 명령어를 실행하면서 stdout, stderr, 종료 상태를 모두 캡처하고 싶다면 Open3.capture3 메서드를 사용하세요. stdout과 stderr를 스트리밍 방식으로 실시간 처리하고 싶다면 Open3.popen3가 답입니다. 너무나 많은 나쁜 선택지 Ruby에는 셸 명령어를 실행하는 방법이 무려 492가지나 있고, 각각 조금씩 다르게 동작합니다. 아마 여러분도 아래 방법 중 하나를 사용해 보셨을 겁니다. 필자가 주로 애용해 온 것은 백틱(``) 방식입니다. exec(echo hello worl

Ruby에서 자신만의 예외(Exception)를 만드는 것은 생각보다 훨씬 간단합니다. 이 글에서는 단계별로 사용자 정의 예외를 생성하고 활용하는 방법을 알아보겠습니다. 1. 새로운 클래스 만들기 Ruby의 모든 것이 그렇듯이, 예외 역시 하나의 클래스입니다. 따라서 새로운 종류의 예외를 만들려면 StandardError 또는 그 하위 클래스를 상속받는 클래스를 정의하기만 하면 됩니다. class MyError < StandardError end raise MyError 관례상 새로운 예외 클래스의 이름은 Error로

```html Ruby에서 예외(Exception)는 특별한 개념이 아니라 그저 하나의 클래스입니다. 즉, 예외 계층 구조란 Exception 클래스를 상속하는 모든 클래스들의 집합이라고 할 수 있습니다. 다음은 Ruby 2.1 표준 라이브러리의 예외 계층 구조 전체 모습입니다. Exception NoMemoryError ScriptError LoadError NotImplementedError SyntaxError SecurityError SignalException Interrupt

Rails 개발을 하다 보면 콘솔을 정말 자주 사용하게 됩니다. 그리고 이제는 모두가 동의하고 있죠. Pry는 Rails 콘솔 역사상 가장 훌륭한 도구라는 사실을요. Pry에는 기본적으로 내장된 몇 가지 강력한 기능이 있어서, 예전의 낡은 IRB보다 훨씬 쉽게 예외를 다룰 수 있습니다. 전체 백트레이스 확인하기 Pry(물론 IRB도 마찬가지)에서 예외가 발생하면 축약된 형태의 백트레이스가 화면에 출력됩니다. 대부분의 경우 이 정도면 충분하지만, 항상 그런 것은 아닙니다. Pry에서는 wtf -v 명령어를 사용해 가장 최근에

웹 애플리케이션을 개발 환경과 운영 환경에서 효과적으로 관리하고 싶다면, 환경 변수에 대한 정확한 이해가 필수입니다. 사실 이것이 언제나 당연한 것은 아니었습니다. 몇 년 전만 해도 Rails 앱을 환경 변수로 설정하는 개발자는 거의 없었습니다. 그런데 Heroku가 등장하면서 상황이 완전히 바뀌었습니다. Heroku는 개발자들에게 12-Factor App 방법론을 소개했습니다. 12-Factor App 매니페스트에는 배포하기 쉬운 애플리케이션을 만들기 위한 다양한 모범 사례가 담겨 있는데, 특히 환경 변수에 관한 섹션이 큰 영향을

지난 글 루비스트를 위한 환경 변수 가이드에서는 환경 변수 시스템이 어떻게 작동하는지 설명하고, 몇 가지 흔한 오해도 바로잡아 드렸습니다. 하지만 한 독자께서 지적해 주셨듯이, 보안에 대해서는 깊이 다루지 못했죠. 요즘은 비밀 API 키나 기타 중요한 정보를 환경 변수에 저장하는 것이 일반화되었기 때문에, 그 보안상 의미를 제대로 이해하는 것이 무엇보다 중요합니다. 지금부터 하나씩 살펴보겠습니다. 최악의 시나리오 해커가 서버에 루트(root) 권한으로, 혹은 웹 애플리케이션을 소유한 사용자 계정으로 침입했다고 상상해 보세요. 그 순

블록(Block)은 Ruby 언어의 핵심 요소로, 블록 없는 Ruby를 상상하기 어려울 정도입니다. 하지만 람다(Lambda)는 어떨까요? 람다를 적극적으로 활용하는 개발자는 많지 않습니다. 몇 년 동안 한 번도 사용하지 않고 지낼 수도 있고, 마치 옛날 유물처럼 느껴지기도 합니다. 하지만 실제로는 그렇지 않습니다. 람다는 조금만 파고들면 흥미로운 기능들을 숨기고 있습니다. 이 글에서는 람다 사용의 기본부터 시작해 더 흥미로운 고급 활용법까지 차근차근 살펴보겠습니다. 이미 매일 람다를 사용하며 모든 것을 알고 계신 분이라면 바로 아

Rails 앱이 RAM을 지나치게 많이 차지하고 있나요? 사실 이제 와서 놀랄 일은 아니지만, 그렇다고 원래 그런 것이라고 받아들일 필요는 없습니다. 애플리케이션의 메모리 사용량이 커진 원인이 하나 이상의 무거운(bloated) gem에 있을 가능성도 있습니다.Derailed란?최근 Richard Schneeman이 만든 아주 유용한 오픈소스 프로젝트를 발견했습니다. 이름은 Derailed이며, 자동 벤치마킹 도구 모음입니다. GitHub 저장소에서 소스 코드를 확인할 수 있습니다.사용법도 간단합니다. 다음과 같이 Gemfile에

일상적인 업무에서 비트 연산(bitwise math)을 직접 할 일은 많지 않을 겁니다. Ruby의 비트 AND(&)와 OR(|) 연산자는 의도적으로 쓰이기보다 실수로 쓰이는 경우가 더 많죠. &&를 쓰려다 &를 잘못 입력해 본 적 없는 개발자는 드물 겁니다. 하지만 C나 어셈블러처럼 저수준 언어로 프로그래밍을 배웠거나, 저처럼 Turbo Pascal 시절을 보낸 사람이라면 비트 조작(bit twiddling)을 한 번쯤은 경험해 봤을 겁니다. 비트 연산으로 문제를 해결하는 건 정말 멋진 일입니다. 컴퓨

루비 개발자라면 해시(Hash)를 사랑할 수밖에 없습니다. 하지만 해시에는 몇 가지 잘 알려진 단점이 있습니다. Richard가 Hashie Considered Harmful에서 지적했듯이, 해시는 때때로 지나치게 유연합니다. 오타 하나만 있어도 의도하지 않은 키를 할당하고 참조하게 될 수 있습니다. a = { type: F150 } a[:typo] # nil 흔히 사용되는 해시 대안들 해시로 실제 구조화된 데이터를 저장한다면, 굳이 그런 유연성이 필요 없다고 판단할 수 있습니다. 과도한 유연성은 결국 문제를 일으킬 뿐입니다. 몇