오늘 포스팅에서는 Rails 6의 시스템 테스트(System Test)를 살펴보겠습니다. 시스템 테스트는 사용자가 애플리케이션과 상호작용하는 방식을 자동으로 검증하는 테스트로, UI에 포함된 JavaScript 동작까지 함께 확인할 수 있습니다. Rails의 기본 테스트 프레임워크인 Minitest는 시스템 테스트와 아주 잘 어울리며, Rails가 대부분의 설정을 대신 처리해 주기 때문에 몇 단계만 거치면 첫 번째 테스트를 바로 실행할 수 있습니다.시스템 테스트는 Rails 5.1에 도입되었습니다. 하지만 막상 사용하려고 하면 RS

이번 글에서는 하나의 Rails 앱으로 여러 하위 도메인(subdomain)을 지원하는 방법을 알아보겠습니다. funkygames.co라는 게임 웹사이트가 있고, app.funkygames.co, api.funkygames.co, dev.funkygames.co 같은 여러 하위 도메인을 단일 Rails 애플리케이션으로 운영하고 싶다고 가정해 봅시다. 모든 하위 도메인에서 올바른 인증이 수행되고, 중복된 라우트가 발생하지 않도록 만드는 것이 목표입니다.이를 위해 Rails의 강력한 라우팅 기능을 활용하고, 로컬 환경에서 하위 도메인을

오늘은 퍼사드(Facade)라는 소프트웨어 설계 패턴에 대해 알아보겠습니다. 처음 도입했을 때는 다소 어색하게 느껴졌지만, Rails 앱에서 반복해서 사용할수록 그 유용성을 깊이 실감하게 되었습니다. 더 중요한 것은 이 패턴 덕분에 코드를 더 철저하게 테스트할 수 있게 되고, 컨트롤러를 깔끔하게 정리하고, 뷰 안의 로직을 줄이며, 애플리케이션 코드의 전체 구조를 한층 명확하게 생각할 수 있게 되었다는 점입니다.퍼사드는 프레임워크와 무관하게 적용할 수 있는 개발 패턴이지만, 이 글에서 제시하는 예제는 Ruby on Rails 기준으로

Ruby는 개발자에게 높은 생산성을 제공하는 언어로 오랫동안 알려져 왔습니다. 우아한 문법, 강력한 메타프로그래밍 지원처럼 코드 작성 단계에서 생산성을 높여 주는 기능들과 더불어, Ruby에는 TracePoint라는 숨겨진 무기가 있어 디버깅 속도를 획기적으로 끌어올릴 수 있습니다.이 글에서는 간단한 예제를 통해 디버깅에 관해 발견한 두 가지 흥미로운 사실을 먼저 소개하겠습니다.대부분의 경우 버그 자체를 찾는 일은 어렵지 않습니다. 진짜 어려운 것은 프로그램이 어떻게 동작하는지 세부 수준까지 이해하는 것이며, 여기까지 도달하면 대개

Ruby on Rails의 창시자 DHH가 시타델(Citadel)이라는 용어를 만들어낸 순간, 우리는 마침내 AppSignal의 기술 접근 방식을 설명할 완벽한 이름을 얻게 되었습니다. 이거 바로 우리잖아! 드디어 우리 방식에도 이름이 생겼네!라고 외쳤던 기억이 납니다.장엄한 모놀리스(Majestic Monolith)에 더해, 누군가 시타델(The Citadel)이라는 패턴도 정리해주면 좋겠습니다. 단 하나의 장엄한 모놀리스가 애플리케이션의 대부분을 담당하고, 매우 특수하고 이질적인 요구사항을 처리하기 위한 소수의 보조 아웃포스트(

이번 글에서는 Rails 마이그레이션을 깊이 있게 파헤쳐 보겠습니다. 마이그레이션을 여러 요소로 나누어 하나씩 분석하면서, 그 과정에서 효과적인 마이그레이션을 작성하는 방법을 배워볼 것입니다. 또한 여러 데이터베이스를 위한 마이그레이션 작성법, 실패한 마이그레이션 처리 방법, 롤백 수행 기법까지 함께 알아보겠습니다.이 글을 온전히 이해하려면 데이터베이스와 Rails에 대한 기본적인 이해가 필요합니다.마이그레이션 기초(Migrations 101)Rails의 마이그레이션은 애플리케이션의 생명 주기 동안 데이터베이스를 점진적으로 발전시킬

이 글은 원래 Playbook Thirty-nine - A Guide to Shipping Interactive Web Apps with Minimal Tooling에 수록된 내용을 AppSignal 게스트 포스트 형식에 맞추어 수정한 것입니다.애플리케이션에는 반드시 처리해야 할 기능이 많습니다. 하지만 그 로직이 꼭 컨트롤러나 모델에 속해야 하는 것은 아닙니다. 장바구니 결제 처리, 회원가입, 구독 시작 같은 기능이 대표적인 예입니다.이런 로직을 전부 컨트롤러에 넣을 수도 있습니다. 하지만 그렇게 하면 여러 곳에서 같은 코드를 반

대부분의 웹 애플리케이션은 백그라운드 대기열(background queue)을 활용하면 큰 이점을 얻을 수 있습니다. 백그라운드 작업은 오류가 발생하기 쉽거나 시간이 오래 걸리는 부가적인 작업들을 처리하는 데 주로 사용되며, 이메일 발송부터 캐시 업데이트, 심지어 핵심 비즈니스 로직 처리까지 그 범위는 다양합니다.백그라운드 대기열 시스템이 처리해야 할 작업 수가 늘어나면, 이를 처리하는 워커(worker) 풀 역시 함께 확장되어야 합니다. 작업이 유입되는 속도가 일정하지 않은 환경에서는 대기열에 쌓인 작업량에 맞춰 워커 수를 늘리는

Ruby on Rails 패턴과 안티패턴 시리즈의 첫 번째 글에 오신 것을 환영합니다. 이 시리즈에서는 Rails 애플리케이션을 개발하면서 마주치게 되는 다양한 패턴들을 깊이 있게 다룰 예정입니다.오늘은 (디자인) 패턴이 무엇인지 살펴보고, 안티패턴이 무엇인지도 함께 설명해 드리겠습니다. 설명을 더 쉽게 이해할 수 있도록 오랜 역사를 지닌 Ruby on Rails 프레임워크를 활용하겠습니다. 혹시 Rails가 취향에 맞지 않더라도 실망하지 마세요. 여기서 소개하는 아이디어와 패턴은 어떤 기술을 사용하든 충분히 공감하고 적용할 수 있

Ruby on Rails를 사용해 본 적이 있다면 컨선(Concern)이라는 개념을 한 번쯤은 접했을 겁니다. 새로운 Rails 프로젝트를 만들 때마다 app/controllers/concerns와 app/models/concerns 디렉터리가 기본으로 생성되니까요. 그런데 컨선은 대체 무엇일까요? 그리고 Rails 커뮤니티에서는 왜 종종 컨선에 대해 비판적인 이야기가 오갈까요?컨선 한눈에 보기Rails 컨선이란 ActiveSupport::Concern 모듈을 확장(extend)하는 모듈을 말합니다. 그럼 일반 Ruby 모듈과 뭐가

애플리케이션 자체만 모니터링하는 것으로는 시스템 전체를 파악하기에 부족한 경우가 많습니다. 위성 앱(또는 보조 앱)에서 실행되는 서비스가 일상 운영에 큰 영향을 미치는 일이 빈번하기 때문입니다. 데이터베이스 서버가 대표적인 예이며, 백업 스크립트나 기타 백그라운드 작업 역시 시스템 성능을 저하시킬 수 있음에도 종종 간과되곤 합니다.Node.js용 AppSignal APM, Ruby APM, Elixir APM은 앱 자체를 자동으로 계측하지만, 기본적으로 이러한 위성 프로세스까지는 감시하지 않습니다. 모니터링 범위를 전체 시스템으로

Ruby on Rails 패턴 및 안티패턴 시리즈의 두 번째 글에 오신 것을 환영합니다. 지난 포스트에서는 패턴과 안티패턴이 무엇인지 개념을 살펴보고, Rails 생태계에서 가장 잘 알려진 몇 가지 사례들을 소개했습니다. 이번 글에서는 Rails 모델과 관련된 대표적인 패턴과 안티패턴을 자세히 다뤄보겠습니다.모델을 다루면서 어려움을 겪고 있다면 이 글이 딱 맞을 것입니다. 비대해진 모델을 슬림하게 만드는 과정을 빠르게 훑어본 뒤, 마이그레이션을 작성할 때 피해야 할 함정들로 마무리하겠습니다. 그럼 바로 시작하겠습니다.비대해진(Ove

AppSignal은 모니터링을 최대한 쉽게 만드는 것을 목표로 하고 있습니다. 그래서 설정이 얼마나 간편한지 말로만 설명하는 것이 아니라 직접 보여드리는 콘텐츠를 꾸준히 준비해 왔습니다.이번에는 Leigh Hallday와 협업하여 설정 과정에서 알아야 할 모든 것을 담은 영상을 제작했습니다. 앞으로도 이런 유형의 영상을 유튜브 채널에 계속 공개할 예정이니, 새로운 영상 소식을 놓치고 싶지 않다면 지금 바로 구독해 주세요. 다들 아시죠? 😉영상에서 다루는 내용영상에서 Leigh는 Rails 애플리케이션에 AppSignal을 통합하는

애플리케이션 모니터링은 처음 시작하는 단계에서는 꽤 어려운 작업일 수 있습니다. 어떤 지표가 가장 중요한지 파악하고, 어떤 지표들을 조합해야 의미 있는 그래프를 만들 수 있는지 이해해야 하기 때문입니다.사용자의 작업을 더욱 매끄럽게 만들어 드리고자 하는 마음(물론 연휴 ⛄️만은 아니죠!)으로, Ruby 통합에 ActionMailer로 발송되는 이메일 양을 보여주는 매직 대시보드를 새롭게 추가했습니다.매직 대시보드(Magic Dashboards)란?설정 과정에서 AppSignal 에이전트는 애플리케이션 인프라를 자동으로 스캔합니다.

2020년은 모두가 빨리 지나가기를 바라던 해였습니다. 하지만 그런 한 해에도 여러분에게 지식을 나눠준 사람들을 떠올리며, 스트루프와플 하나를 손에 들고 좋은 것들에 대해 잠시 생각해 볼 시간을 가져보는 건 어떨까요?오늘 포스트에서는 독자 여러분께 가장 큰 사랑을 받은 Ruby 관련 게시물 5개를 엄선해 소개합니다. 좋은 음악을 틀어놓고 편하게 읽어보세요.2020년 최고의 Ruby 블로그 게시물 TOP 5 💎Ruby on Rails에서 서비스 오브젝트(Service Objects) 활용하기애플리케이션이 처리해야 할 기능은 많지만,

마이크로서비스 아키텍처란?마이크로서비스 아키텍처는 여러 개의 작은 프로그램을 결합하여 애플리케이션을 구축하는 소프트웨어 설계 패턴입니다. 이렇게 만들어진 작은 프로그램들을 마이크로서비스라고 부르며, 공동의 목표를 위해 협력합니다. 일부 팀에게는 하나의 거대한 애플리케이션을 개발하는 것보다 여러 개의 소규모 애플리케이션을 작성하는 편이 훨씬 적은 시간과 노력이 듭니다.마이크로서비스 지향 프로젝트는 각자 맡은 역할을 수행하고, 별도의 프로세스에서 실행되며, 표준화된 인터페이스를 통해 서로 통신하는 작은 애플리케이션들의 집합으로 구성됩니

모듈과 믹스인은 Ruby를 매력적인 언어로 만드는 핵심 요소입니다. 한 번 작성한 코드를 다른 곳에서도 손쉽게 재사용할 수 있게 해주며, 기능별로 코드를 묶어 관심사를 분리함으로써 가독성과 유지보수성을 크게 향상시킵니다.이 글에서는 모듈과 믹스인의 개념을 살펴보고, 모듈을 생성하고 클래스에 믹스인으로 포함시키는 방법, 그리고 Ruby on Rails 애플리케이션에서 이를 활용했을 때 얻을 수 있는 이점까지 자세히 알아보겠습니다.모듈(Module)이란 무엇일까?모듈은 Ruby의 가장 빛나는 기능 중 하나로, 두 가지 큰 장점을 제공합

Ruby 개발자 여러분께 AppSignal for Ruby의 새로운 메이저 버전인 3.0을 발표하게 되어 매우 기쁩니다! 🎉이번 버전에서는 다른 계측(instrumentation) 젬과의 호환성을 높이기 위해 앱과 젬을 계측하는 방식을 변경했습니다. 또한 Ruby 1.9 지원이 제거되었으며, 지원이 중단된(deprecated) 클래스, 모듈, 메서드 및 계측 기능도 함께 삭제되었습니다.업그레이드 가이드를 꼭 확인해 보세요!이제부터 이번 새 버전이 여러분과 여러분의 앱에 어떤 변화를 가져다주는지 하나씩 살펴보겠습니다. 시작해 볼까요

애플리케이션 성능에 대한 체계적인 모니터링 환경을 구축하는 일은 결코 간단한 작업이 아닙니다. 일반적으로는 먼저 무엇을 모니터링할지 정하고, 코드에 직접 계측(instrumentation) 코드를 추가한 뒤, 마지막으로 수집된 방대한 데이터를 분석해야 하기 때문입니다.하지만 몇 가지 기본 설정만 갖추고 Ruby를 기본적으로 지원하는 APM(Application Performance Monitoring) 도구를 사용하면, 이 과정은 그 어느 때보다 쉬워집니다. 이 글에서는 그 방법을 단계별로 소개합니다.자동 계측 — 손대지 않는 AP

Ruby on Rails 패턴과 안티패턴 시리즈의 네 번째 글로 돌아왔습니다.지난 글에서는 일반적인 패턴과 안티패턴을 소개하고, Rails의 모델(Model)과 뷰(View)에 적용되는 사례를 살펴봤습니다. 이번 글에서는 MVC(모델-뷰-컨트롤러) 디자인 패턴의 마지막 조각인 컨트롤러(Controller)를 집중적으로 분석해 보겠습니다. Rails 컨트롤러와 관련된 패턴과 안티패턴을 함께 짚어보시죠.요청 처리의 최전선, 컨트롤러Ruby on Rails는 웹 프레임워크이므로 HTTP 요청은 프레임워크의 심장과도 같습니다. 다양한 클라