Private(or Protected) 메서드 테스트 하기

today 2016-12-04 face Posted by appkr turned_in Work & Play forum 0

최근에 회사 일로 검색 서비스를 개발했다. 검색 엔진으로는 Elastic Search를 사용했고, 매일 최한시(off-peak time)에 한 번씩 운영 데이터베이스에서 검색, 필터링, 정렬, Aggregation 등에 필요한 컬럼만 골라 인덱싱하도록 설계했다. 그리고, 재고 수량과 같이 실시간 업데이트가 필요한 값 들은 다른 서비스에서 SNS 메시지 또는 메시지 큐를 이용해서 전달하고, 전달 받은 값을 인덱싱에 반영하도록 구현했다.

Elastic Search는 사용법이 복잡하긴 하지만, 인덱싱된 필드 값에 따라 내림차순, 오름차순으로 미리 정렬된 결과를 받을 수 있다. 그런데, 아무리 실시간 업데이트를 한다고 해도, 인덱싱된 값만으로 정렬이 불가능한 경우가 있고, 이 경우에는 검색 결과를 받아서 후 처리로 배열을 순회하면서 다시 정렬을 해야 한다. 같은 클래스의 Public 메서드가 정렬 요청을 하므로, 당연히 Protected 메서드로 구현했다.

일반적으로 알려진 테스트 모범 사례는 다음과 같다.

  • 내가 짠 코드만 테스트한다. 외부에서 가져온 라이브러리를 테스트할 이유는 없다.
  • Public 메서드만 테스트한다. Private나 Protected 메서드는 Public 메서드가 작동하는데 도움을 주는 메서드들이므로, Public 메서드를 테스트함으로써 자동으로 테스트된다.

후처리 정렬의 정상 작동을 확인해야 할 필요성이 생긴 것이다. 물론 구현한 Protected 메서드의 가시성을 Public으로 변경하면 쉽다. 그런데, 다른 클래스에서 호출하지도 않을 메서드를 Public으로 선언하는 것은 기분이 찜찜하다. 이 포스트에서는 Private나 Protected로 선언된 메서드를 유닛 테스트하는 방법을 설명한다. 결론부터 말하면, PHP의 Reflection API를 이용하는 것이다.

Monolog를 이용한 애플리케이션 로깅

today 2016-12-03 face Posted by appkr turned_in Work & Play forum 0

이 포스트에서는 PHP 커뮤니티에서 De facto(사실상) 표준으로 인식되는 로깅 라이브러리인 Monolog의 사용법을 소개한다. Monolog는 PSR-3 LoggerInterface를 구현한 구현체이며, RFC-5424에서 정의한 심각도 규격(e.g. DEBUG, INFO, ..)에 따라 로그를 핸들링한다. 컴포저를 만든 조르디 보기아노(Jordi Boggiano)가 구현했으며, 파일 뿐만 아니라 데이터베이스, 메일, SaaS 서비스등 다양한 방법으로 로그를 처리할 수 있다.

이 포스트에서는 라라벨 프로젝트에서 기본 로그 저장소인 파일(storage/logs/laravel.log)에 더해서 Elastic Search에도 로그를 적재하는 방법을 다룬다. 다음 도구 또는 서비스를 사용한다.

  • 라라벨: PHP 프로그래밍 언어로 작성된 풀 스택 웹 프레임워크1
  • Elastic Search: 검색에 특화된 데이터베이스. CRUD 및 설정을 위한 REST API를 제공한다.2
  • Docker: 컨테이너화된 애플리케이션 운영 환경을 관리하는 도구3

이 포스트의 소스 코드는 https://github.com/appkr/monolog-scratchpad에서 받을 수 있다.

제가 집필한 책이 어제 출간되었습니다. 웹 프로그래밍을 다룹니다. 웹 프로그래밍을 위한 도구로는 PHP 언어로 작성된 라라벨 프레임워크를 사용합니다.

2016년 초에 완성하고 깃허브에 공개한 무료 온라인 강의를 토대로 제이펍 출판사에 계신 프로페셔널들의 도움을 받아 비문을 고치고 부족한 설명을 보충하였습니다. 게다가 생활 코딩 오프라인 수업에 조교로 자원 봉사(5회?), 8시간 또는 14시간 짜리 라라벨 입문 강의(각 4회씩 총 8회) 등을 통해 입문자와 예비 독자들을 만나며, 여러분들이 어려워하거나 실수하기 쉬운 내용을 캐치하고 책의 내용과 구성에 반영했습니다.

라라벨로 배우는 실전 PHP 웹 프로그래밍

프로그래밍을 생짜 처음 하신다고요?

생활코딩의 웹 애플리케이션 만들기 정도만 공부하신 수준이면 이 책을 시작하는데 무리가 없습니다.

임베디드, 응용, 시스템 프로그래밍을 하시거나/하셨는데, 필요에 의해 웹 프로그래밍을 하셔야 한다고요?

이 책으로 시작하시는 당신은 행운아입니다.

이 곳에서 구매할 수 있습니다. 교보문고, 반디앤루니스, 알라딘, yes24, 인터파크

개발자들은 코드를 보면 코드를 짠 사람의 실력과 성격을 어느 정도 가늠할 수 있다는 얘기를 들었습니다. 마찬가지로, 저희들은 원고를 보고 지은이의 내공과 성격을 어느 정도 유추하곤 합니다. 김주원 님의 원고를 처음 받았을 때의 느낌은 ‘참 꼼꼼하면서 정갈한 분이시겠구나’였습니다. 책 전체의 뼈대와 같은 차례도 탄탄하고, 글을 풀어가는 느낌도 군더더기가 없어서 좋았습니다. 물론, 원고를 받고 책이 나오기까지 많은 분의 도움으로 수정 및 보완 작업을 거치긴 했지만요.

제이펍 블로그 포스트 중에서 (http://jpub.tistory.com/622)

안내 매월 첫째 주 수요일에 열리는 모던퍼그 정기 모임에 책을 들고 참여하시면 저자 싸인해 드리겠습니다.

라라벨-루멘-PHP 날코딩 성능 비교

today 2016-11-07 face Posted by appkr turned_in Work & Play forum 0

라라벨과 루멘, PHP 날코딩간의 성능 비교를 해 보신 분들이 없는 것 같아 직접 해 봤다. 결론은 뻔하지만, PHP 날코딩이 가장 빠르고, 메모리 사용량도 적다. 프레임워크를 써야 이유는 다른 곳에 있으니, 이 실험 결과만 보고 오해나 곡해하지 마시기 바란다.

주의 이 실험은 다른 PHP 프레임워크 또는 다른 플랫폼의 프레임워크와 라라벨 또는 루멘의 성능을 비교하기 위한 것이 아니다(다른 PHP 프레임워크와의 비교는 “How Lumen Is Benchmarked”를 참고하라). 이 실험은 라라벨과 루멘의 기본적인 속도와 필요 리소스를 측정해 봄으로써, PHP 날코딩의 성능과 프레임워크가 제공하는 이점 간의 트레이드오프(trade-off)에 대한 의사 결정 포인트를 제공하기 위한 목적으로 수행하였다.

RPC - Apache Thrift 입문 1부

today 2016-11-04 face Posted by appkr turned_in Work & Play forum 0

RPC(Remote Procedure Call)와 REST(REpresentational State Transfer)는 원격 API를 호출하는 대표적인 방법이다.

REST가 API를 통해 원격 서버에 있는 리소스(모델 또는 데이터)에 대한 상태를 주고 받는다고 생각하는 반면, RPC는 원격 서버의 함수를 호출해서 결과를 얻는다고 생각한다. 그래서 REST에서는 GET /posts/{id} 또는 POST /posts와 같이 원격 서버의 리소스에 접근할 수 있는 직접적인 통로를 제공하는 반면, RPC에서는 URL 엔드포인트는 그냥 통로일 뿐 원격 서버와 클라이언트가 공통으로 사용하는 라아브러리를 시용해서 $client->find($id)와 같이 통신한다.

이 포스트에서는 PHP 프로젝트에서 Apache Thrift RPC 시스템을 사용하는 방법을 설명한다.

CAVEAT 게시판 서비스를 만드는데 RPC를 쓰지 말라! 속도나 강건함을 얻는 대신 디버깅의 편리함을 포기해야 한다. 클라이언트가 멀티 플랫폼으로 구성되어 있어 서버와 주고 받는 메시지를 엄격하게 규정해야 하고, 외부에 공개하지 않는 API일 때만 고려해 볼 것을 권장한다.

keyboard_arrow_up