레이블이 PHP인 게시물을 표시합니다. 모든 게시물 표시
레이블이 PHP인 게시물을 표시합니다. 모든 게시물 표시

2016-04-17

[번역] 루멘의 등장, 테일러와 인터뷰

원문: https://laravel-news.com/2015/04/lumen/

지난 2015년 4월 라라벨에서 루멘(lumen)이라는 경량 프레임워크 (micro-framework) 를 발표했다.
루멘은 경량 프레임워크 중에서도 후발 주자에 속하는 편이다. 대표적인 경량 프레임워크에는 2011년에 출시한 사일렉스(Silex)나 슬림(slim) 등이 있었다. 아무래도 루멘 제작자가 슬림이나 사일렉스를 사용해보고서 만든 프레임워크라서 비슷한 점이 많다. 그래서 가장 최근에 출시한 루멘에 대해서 알아봤다. 여타 프레임워크와 마찬가지로 단점보다는 장점이 더 많이 보이는 프레임워크다. 많은 장점 중 하나는 라라벨 계열이기 때문에 사용하다가 라라벨로 바로 업그레이드 할 수 있다는 점이다. 또한 루멘 측 발표에 따르면 slim3이나 silex보다 속도 면에서 우수하다고 한다. 과연 사실인지는 더 파헤져 봐야할 내용인 것 같다. 일단 루멘은 라라벨이라는 브랜드를 내세운 것은 확실하다. 2016년 2월 현재, 5.2.0 버전까지 릴리즈 되어 있다.

사실은 경량 프레임워크가 나온 전반적인 배경을 알고 싶었지만 생각보다 찾기가 어려웠다. 대신 발표문이나 인터뷰를 번역해보는 것이 더 이해하기가 쉬울 것 같아서 작성해보았다. 언제나 그렇듯 좋은 번역글은 아니다.



루멘(Lumen)은 빛처럼 빠른 마이크로 서비스와 API를 위해 테일러 오트웰이 구축한 새로운 PHP 프레임워크 브랜드이다. 속도가 중요하다면 루멘은 아주 좋은 선택일 것이다.

이 프레임워크의 뛰어난 점 중 하나는 여러분이 사랑하는 엘로퀀트, 캐싱, 큐, 검증, 라우팅, 미들웨어, 강력한 라라벨 서비스 컨데이너인 라라벨의 기능을 계속 사용할 수 있다는 것이다. 또한 여러분이 루멘으로 프로젝트를 시작한 후에 더 많은 기능이 필요하다면 완전한 기능을 갖춘 라라벨로 변경하는 것은 간단하다.

비하인드 스토리를 더 알기 위해 테일러와 프로젝트에 대해 짧은 인터뷰를 했다. 

루멘을 만들기로 한 계기가 무엇인가?

Envoyer를 구축할 때 나는 이를 지원하는 2개의 작은 "마이크로 서비스"를 썼다. 그 중 하나는 배포 후에 상태를 제크하는 것이다. 그것은 디지털오션* 쪽 3군데에 있는 작은 애플리케이션이다. 애플리케이션을 위해 Silex를 사용했지만 PDO 데이터베이스 연결을 어떻게 설정 하는지 다시 조사 했다. 나는 그저 뛰어난 기능인 DB::update를 사용할 수 있는 아주 작은 라라벨이 설치 되었으면 좋겠다고 생각했다.

* 역주: 디지털 오션은 클라우드 호스팅 서비스 업체 이름이다.

다른 Envoyer 서비스는 "heartbeat" 크론 모니터링이다. 여러 URL이 매 수백분의 1초마다 호출될 수 있기 때문에 수많은 크론 일정이 아니라 하더라도 나는 매우 빠른 것이 필요했다. 그래서 나는 Slim 서비스를 사용했다. 그러나 또 다시 나는 데이터 베이스 연결 뿐 아니라 좀 더 강력한 에러 핸들링을 설치했다. 나는 이번에도 작은 라라벨 "빛" 설치를 원했다.

이 부분이 루멘의 아이디어가 탄생한 부분이다. 충분하게 빠른 방법을 찾기 위해 프레임 워크 구축을 서너번 반복했다. 나는 좋은 평가를 받고 있는 Silex와 Slim보다 빠르다고 할 수 있을 때까지 루멘을 릴리즈 하지 않으려 했다. 나는 대체할 수 있는 선택보다 느린 것을 발표하고 싶지 않았다.

루멘이라는 이름은 어디서 왔는가?

루멘은 라라벨 사용 컴포넌트 "비추다(Illuminate, 이하 일루미네이트)"에서 따왔다. 일루미네이트 컴포넌트는 데이터 베이스, 캐시, 큐 등과 같은 라라벨 프레임워크의 한 부분이다. 그래서 나는 처음에 이름으로써 루멘이 듣기 좋다고 생각했다. 라라벨 같이 세개 대신 두개의 음절 뿐이다. 미친 소리 처럼 들리겠지만 나는 단어를 말할 때 떠오르는 그런 종류와 정신적 이미지에 대해 생각한다. 물론 "빛"을 기반으로한 계보는 잇는다.

라라벨로 바로 업그레이드 할 수 있다는 것은 엄청나다. 이 부분은 처음부터 계획되었나?

그렇다, 그리고 실제로 전체 라라벨 프레임워크를 구성하는 일루미네이터 컴포넌트를 사용한 자연적인 결과이다. 우리가 그 컴포넌트를 사용함으로써 정말 멋진 업그레이드 이야기를 제공하는 것이 쉬웠고 다른 경량 프레임워크 솔루션에는 없는 느낌이었다. 이제 라라벨 생태계에 "공식적"으로 풀스택 프레임워크와 경량 프레임워크 둘 다 포함함으로써 우리는 정말 멋진 업그레이드 이야기를 제공할 수 있다.

어떻게 멋진 기능들을 유지하면서 빠른 프레임워크를 얻을 수 있었나?

또 일루미네이트 컴포넌트의 엄청난 편의성 때문이다. 기본적으로 내가 필요한 모든 것은 풀스택 프레임워크가 결합한 것과 다른 방법으로 "결합 했다". 이는 시스템 로딩 과정에서 최고의 유연성 대신에 루멘의 최고의 속도를 선택 한다는 것을 의미한다. 실제 루멘 프레임워크 저장소는 아마 열 댓개의 파일일 것이다. 나머지는 일루미네이트의 컴포넌트로 대신한다. 이 사실은 정말로 해결 방법을 찾기 위해 서너번 반복했다고 하더라도 여전히 매우 강력한 기능을 제공하면서 매우 빠르게 프레임워크의 기능을 구체화 할 수 있도록 해주었다.

루멘은 큰 성공임에 틀림 없고 나는 여러분이 라라벨로 쉽게 변경할 수 있는 방법은 루멘 뿐 아니라 모든 라라벨 생태계를 위한 거대한 장기적인 이익이라고 생각한다. 루멘에 대한 모든 최신 소식을 보고 싶으면 주간 뉴스 레터에 가입하라. 
continue reading [번역] 루멘의 등장, 테일러와 인터뷰
Share This:    Facebook Twitter

2016-03-23

리눅스, PHP 실행할 때 코드로 인자 (파라미터) 넘기기

리눅스에서 간단한 작업을 할 때 php 파일을 생성한 후에 그 파일을 실행하는 경우가 종종 있다. 경우에 따라 조금 더 확장된 형태로 실행할 때 원하는 인자를 파일 안으로 전달해야할 경우가 있는데, 그럴때 아주 유용한 내용이 아닐까 싶다.
잊지 않고자 글로 남고 놓는다.

파일 실행할 때

리눅스 상에서 php 파일을 실행 할 때 인자를 지정하여 코드상으로 전달하고 싶다면 다음과 같이 전달할 수 있다.

php {실행할 파일명}.php {전달할 변수1} {전달할 변수2} ... {전달할 변수n}

코드상에서 인자 받기

전달한 인자는 PHP 코드 상에서 $argc$argv로 받을 수 있다.
$argc는 인자의 개수, $argv는 인자의 내용을 가지고 있다.
$_SERVER['argv']처럼 받을 수도 있다.

예시

하단은 인자를 전달하여 파일을 실행하고 코드 상에서 해당 인자를 변수로 받는 예시이다.

인자를 전달하여 파일을 실행
php act_migration.php type1 10

코드상에서 전달받은 인자 출력
<?php
print_r($argv);
// Array
//(
//    [0] => act_migration.php
//    [1] => type1
//    [2] => 10
//)

참고:



continue reading 리눅스, PHP 실행할 때 코드로 인자 (파라미터) 넘기기
Share This:    Facebook Twitter

2016-01-06

[번역] PDO 다시소개하기 – PHP에서 데이터베이스에 접근하는 올바른 방법

원문: http://www.sitepoint.com/re-introducing-pdo-the-right-way-to-access-databases-in-php/

본 내용은 PDO에 대해서 다시 소개한 글이다. 데이터 베이스에 대한 작업을 할 때 PDO를 사용하는 것이 얼마나 편리하고 안전한 방법인가에 대해서 초점을 맞춰서 설명하고 있다.


mysqlmysqli인가?

새 기술에 직면할 때 사람들이 확실히 묻는 질문이 있다, 왜 업그레이드를 해야 하는가? 이러한 새 기술이 그들의 전체 애플리케이션을 검토하고 새 라이브러리, 확장 기능, 어떤 것이든 모든 것을 전환하는 노력을 해 볼 만한 가치를 주는 것은 무엇인가?

이는 매우 타당한 관심사이다. 우리는 전에 이에 대해 어느 정도 작성했었지만 왜 우리가 업그레이드할 가치가 있다고 생각하는지 함께 살펴보자.

PDO 는 객체지향이다.

현실을 직시하자. PHP는 급격하게 성장하며 더 나은 프로그래밍 언어가 되고 있다. 보통 동적인 언어가 생겨나면 그 언어는 프로그래머가 거리낌없이 기업 애플리케이션을 만들 수 있도록 하기 위해 더 엄격해진다.

PHP의 경우 더 나은 PHP는 객체 지향 PHP를 의미한다. 이 뜻은 여러분이 더 많은 객체를 사용하고, 더 나은 코드 테스트를 할 수 있고, 재사용 가능한 컴포넌트를 작성하고, 일반적으로 여러분의 연봉이 오른다는 의미이다.

PDO를 사용하는 것은 객체지향과 재사용 가능한 애플리케이션의 데이터베이스 층을 만드는 첫단계이다. 이 문서의 나머지 부분에서 볼 내용과 같이 PDO로 객체지향 코드를 작성하는 것은 생각보다 더 간단하다.

추출

여러분의 현재 직장에서 MySQL을 사용하는 킬러 애플리케이션을 작성했다고 상상해보자.
갑자기 누군가 절차에 따라 여러분이 Postgres를 사용하여 애플리케이션을 마이그레이션 작업을 해야한다고 결정하였다. 여러분은 무엇을 할 것인가?
킬러 애플리케이션: 특정 플랫폼을 반드시 사용하게 만들 정도의 능력이 있는 컴퓨터 소프트웨어를 뜻한다.
참고: http://ko.wordow.com/english/dictionary/?t=killer%20application

여러분은 쿼리를 실행하고 결과를 생성하는 모든 함수는 물론이고 mysql_connect나 mysqli_connect를 pg_connect로 변환하는 것 같이 골치 아픈 부분을 많이 바꿔야 한다.
만일 여러분이 PDO를 사용한다면 아주 간단해 진다. 그저 주요 설정 파일에서 파라미터 몇 개만 변경하면 끝난다.

파라미터를 바인딩 할 수 있다

파라미터 바인딩은 여러분의 쿼리에서 플레이스 홀더를 변수의 값으로 교체할 수 있도록 하는 기능이다. 이 의미는

  • 실행시간에 얼마나 많은 플레이스홀더가 있는지 알 필요가 없다.
  • 여러분의 애플리케이션은 SQL 인젝션에 대해 훨씬 안전할 것이다.

여러분은 객체로 데이터를 생성할 수 있다. 

Doctrine같은 ORM을 사용하는 사람들은 객체로 여러분의 테이블에서 데이터를 표현할 수 있는 가치를 알고 있다. 만일 여러분이 이 기능을 사용하고는 싶지만 ORM을 배우고 싶지 않거나 이미 존재하는 애플리케이션으로 통합하고 싶지 않다면 PDO가 객체로 여러분의 테이블에서 데이터를 생성할 수 있도록 해준다.

mysql 확장 기능은 더 이상 지원하지 않는다! 

그렇다, mysql 확장 기능은 마침내 PHP 7에서 제거되었다. 이 의미는 만일 여러분이 PHP 7을 사용하고자 할 계획이 있다면 mysql_* 대신에 mysqli_* 함수로 변경해야 한다는 것이다. 이는 훨씬 적은 노력으로 유지보수가 쉽고 호환성이 좋은 코드를 작성할 수 있기 때문에 PDO로 업그레이드 하기에 아주 좋은 시기이다.

나는 위에서 말한 이유로 PDO를 여러분의 애플리케이션으로 통합하는 것에 대해 여러분을 설득했길 바란다. 설치에 관해선 걱정않아도 된다. 이미 시스템에 설치되어 있다!

PDO 존재를 확인하기

만일 여러분이 PHP 5.5.X나 그 이상을 사용한다면 이미 PDO를 포함하고 있을 확률이 있다. 확인하기 위하여 간단하게 리눅스, Mac OS X, 윈도우 명령 프롬프트에서 터미널을 열고 다음과 같은 명령어를 따라하라.

php -i | grep 'pdo'

여러분은 또한 웹 루트 아래에 php 파일을 생성하고 phpinfo() 구문을 그 파일에 입력할 수 있다.

<?php
phpinfo();
이제 브라우저에서 이 페이지를 열고 pdo 문자열을 찾아보라.

만일 PDO, MySQL이 있다면 설치 명령을 건너뛴다. PDO가 있지만 MySQL을 위한 것이 아니라면 아래 지침에 따라 mysqlnd 확장 기능을 설치하면 된다. 그러나 PDO 전부 가지고 있지 않다면 절차는 더 길지만 어렵지 않다! 따라 읽으면서 우리는 PDO와 mysqlnd 설치하는 방법에 대해 준비를 갖춰서 이야기 할 것이다.

PDO 설치

만약에 이미 패키지 매니저를 통해 저장소에서 PHP를 설치했다면 (예: apt, yum, pacman, 기타 등등) PDO를 설치하는 것은 아주 간단하고 복잡하지 않다. 그냥 각각의 운영 시스템 및 배포된 곳에서 목록화되어 있는 설치 명령어를 실행하면 된다. 여러분이 비록 해본적이 없어도 스크래치 파일에서 시작할 수 있는 권장 방법을 포함하고 있다.

페도라, 레드헷, 센토스 

우선, 아직 없다면 그들의 블로그에서 제공하고 있는 명령을 사용하여 Remi 저장소를 추가하라. 다 되면 여러분은 쉽게 명령어를 사용하여 php-pdo를 설치할 수 있다.

sudo yum --enablerepo=remi,remi-php56 install php-pdo
참고: remi를 해본적이 없어도 여러분은 remi-php56를 위의 명령어로 원하는 저장소로 변경해야 한다.

물론 아직 설치되어 있지 않다면 다음 명령어를 따라하여 mysqlnd을 설치해야 한다.

sudo yum --enablerepo=remi,remi-php56 install php-mysqlnd

데비안과 우분투

여러분은 우분투에서 Ondrej 저장소를 추가 해야한다. 이 링크는 5.6 PPA를 가리키지만 여러분은 그 버전 뿐 아니라 이전 버전 링크도 찾을 수 있다.

데비안에서 여러분의 시스템에 Dotdeb 저장소를 추가해야 한다.

이러한 방식 모두에서 php5 메타패키지를 설치 한 후에 이미 PDO가 준비되고 구성되어 있다. 여러분이 해야할 일은 간단히 mysqlnd 확장 기능을 추가하는 것이다.

sudo apt-get install php5-mysqlnd

윈도우즈

여러분은 윈도우에서 개발하려면 리눅스 가상 머신을 시도하고 사용 해야 한다, 그러나 그렇지 않은 경우에는 아래 지침을 따라 하라.

윈도우즈 환경에서 여러분은 보통 WampXampp를 사용하여 전체 램프 스택을 얻는다.
또한 windows.php.net에서 바로 PHP를 다운받을 수도 있다. 분명히 후자를 선택할 경우 PHP만 얻을 것이고 모든 스택은 아닐 것이다.
* LAMP 서버 운영에 자주 같이 쓰이는 소프트웨어 약자(L=LINUX (OS) A=APACHE (Web Server) M=MySQL (DataBase) P=PHP (Language))

어느 경우에나 PDO가 활성화 되어 있지 않다면 여러분은 php.ini에서 주석을 제거해야한다. php.ini를 수정하기 위해 LAMP 스택에서 제공하는 기능을 사용하거나 windows.php.net에서 PHP를 다운로드 한 경우 그냥 여러분이 설치 디렉토리로 선택하고 php.ini를 수정한 폴더를 연다. 그런 다음 이 줄의 주석을 제거한다.

;extension=php_pdo_mysql.dll

PDO 시작하기: 높은 수준의 개요

PDO를 사용하여 여러분의 데이터 베이스를 쿼리할 때 여러분의 작업 흐름은 많이 변경되지 않는다. 그러나 하지 말아야할 몇몇 습관이나 해도 되는 다른 습관들이 있다. 다음 단계는 여러분이 PDO를 사용하는 애플리케이션에서 수행해야 한다. 우리는 아래에서 상세하게 하나하나 설명할 것이다.

  • 데이터 베이스 연결하기
  • 선택적으로 preparing statement와 파라미터 바인딩하기
  • 쿼리 실행하기

데이터베이스 연결하기

데이터 베이스에 연결하기 위하여 여러분은 새 PDO 객체 인스턴스하기를 해야하고 데이터 소스 이름을 통과하고 DSN에 대해 알아야 한다.

보통 콜론(;)으로 따라오는 PDO 드라이버 이름의 DSN 구성은 PDO 드라이버별 연결 구문으로 이어진다. PDO 드라이버별 문서에서 추가 정보를 사용할 수 있다.

예를 들어 여기에 MySQL 데이터베이스를 연결하는 방법이 있다.
$connection = new PDO('mysql:host=localhost;dbname=mydb;charset=utf8', 'root', 'root');

위 함수는 DSN, 사용자 이름, 비밀번호를 포함하고 있다. 위에서 인용한 것처럼 DSN은 드라이버 이름 (mysql), 드라이버별 옵션을 포함한다. mysql의 경우에 옵션은 host (ip:포트 형식의), dbnamecharset가 있다.

쿼리

mysql_query()mysqli_query()가 어떻게 동작하는지와 반대로 PDO에는 2가지 종류의 쿼리가 있다. 하나는 결과 (예: selectshow) 를 반환하는 것과 그렇지 않는 것 (예: insert, delete 같은 것) 이 있다. 먼저 간단하게 그렇지 않는 옵션을 살펴보자.

쿼리 실행

이 쿼리는 실행하기에 매우 간단하다. insert를 살펴보자.
$connection->exec('INSERT INTO user VALUES (1, "somevalue"');

기술적으로 나는 이 쿼리가 결과를 반환하지 않는다고 말했을 때 거짓말을 했다. 만일 여러분이 이 코드를 위의 코드로 변경했다면 여러분은 exec()가 영향을 받는 행의 수를 반환하는 것을 볼 수 있을 것이다.

$affectedRows = $connection->exec('INSERT INTO users VALUES (1, "somevalue"');
echo $affectedRows;
삽입 구문에 대해 추측할 수 있듯이 이 값은 보통 하나이다. 하지만 다른 구문의 경우 이 숫자 값은 달라진다.

쿼리 결과 가져오기

여기에 mysql_query()mysqli_query()로 어떻게 쿼리를 실행시킬 수 있는 방법이 있다.

$result = mysql_query('SELECT * FROM users');

while($row = mysql_fetch_assoc($result)) {
    echo $row['id'] . ' ' . $row['name'];
}
그러나 PDO로 하면 훨씬 더 직관적이다.

foreach($connection->query('SELECT * FROM users') as $row) {
    echo $row['id'] . ' ' . $row['name'];
}

가져오기 모드: Assoc, Num, class
그냥 mysqlmysqli 확장 기능과 마찬가지로 여러분은 PDO에서 다른 방법으로 결과를 가져올 수 있다. 이렇게 하기 위해서 여러분은 패치 기능에 대해 도움말 페이지에서 설명한 PDO::fetch_* 상수 중 하나를 통과해야한다. 만일 여러분이 한번에 여러분의 결과 모두를 얻고 싶으면 여러분은 fetchAll 함수를 사용할 수 있다.

아래에 몇 가지 우리가 생각하는 가장 유용한 패치 모드가 있다.
  • PDO::FETCH_ASSOC: 열 이름으로 인덱스된 배열을 반환한다. 이전 예제에서 보자면 여러분은 id값을 가져올 때 $row['id']를 사용해야한다.
  • PDO::FETCH_NUM: 열 숫자로 인덱스된 배열을 반환한다. 이전 예제에서 보자면 첫번째 열이기 때문에 $row[0]을 사용하여 id를 얻을 수 있다.
  • PDO::FETCH_OBJ: 여러분의 결과에서 반환되는 열 이름에 해당하는 프로퍼티 이름으로 익명 객체를 반환한다. 예를 들어 $row->idid 열 값을 가지고 있다.
  • PDO::FETCH_CLASS: 요청된 클래스에서 명명된 프로퍼티에 결과 값 열을 매핑한 요청 클래스의 인스턴스를 반환한다. 만약 fetch_style이 PDO::FETCH_CLASSTYPE (예: PDO::FETCH_CLASS | PDO::FETCH_CLASSTYPE) 을 포함하면 클래스 이름은 첫번째 열 값에서 결정된다. 기억할지 모르지만 우리는 가장 간단한 폼 형태로 PDO가 사용자 정의 클래스로 열 이름을 매핑할 수 있다고 지적했다. 이 상수는 해당 작업을 수행할 때 사용하는 것이다.
참고: 이 목록은 완성된 것이 아니며 우리는 가능한 상수와 조합을 모두 얻을 수 있는 상기 도움말 페이지를 확인하는 것을 추천한다.

예시와 같이 관련있는 배열로 열을 얻어보자.
$statement = $connection->query('SELECT * FROM users');

while($row = $statement->fetch(PDO::FETCH_ASSOC)) {
    echo $row['id'] . ' ' . $row['name'];
}
참고: 우리는 항상 패치모드를 선택하는 것을 추천하는데 그 이유는 PHP가 연관 배열과 일반 배열을 통한 다른 열 값에 접근을 제공한 이후로 PDO::FETCH_BOTH (기본) 같이 결과를 가져오는 것은 두 배 이상 메모리를 잡아먹기 때문이다.

여러분이 위에서 기억하듯 우리가 PDO의 이점을 열거할 때 우리는 이전에 지정한 클래스에서 PDO가 현재 열을 저장하는 방법이 있다는 것을 언급했다. 여러분은 또한 위에서 설명한 PDO::FETCH_CLASS 상수를 보았다. 이제 이것을 사용하여 User 클래스 인스턴스로 우리의 데이터베이스에서 데이터를 검색해보자.

class User
{

    protected $id;
    protected $name;

    public function getId()
    {
        return $this->id;
    }

    public function setId($id)
    {
        $this->id = $id;
    }

    public function getName()
    {
        return $this->name;
    }

    public function setName($name)
    {
        $this->name = $name;
    }

}

이제 우리는 또한 Model, Entity, plain old PHP 객체로 알려진 이러한 경우에 우리가 만든 User 클래스를 사용하여 같은 쿼리를 만들 수 있다 (Java 쪽 Plain Old Java Object에서 가져왔다).

$statement = $connection->query('SELECT * FROM users');

while($row = $statement->fetch(PDO::FETCH_CLASS, 'User')) {
    echo $row->getId() . ' ' . $row->getName();
}

Prepared Statement와 파라미터 바인딩

파라미터 바인딩과 장점을 이해하기 위해 맨 먼저 우리는 PDO가 동작하는 곳으로 더 깊이 살펴 봐야 한다. 우리가 위에서 $statement->query()을 호출했을 때 PDO는 내부로 구문을 준비하고 실행하고 우리에게 결과 구문을 반환한다.

여러분이 $connection->prepare()을 호출할 때 여러분은 Prepared Statement을 생성한다. Prepared Statement는 Blade나 Twig 템플릿을 랜더링 하는 것처럼 플레이스 홀더 값을 받을 때 템플릿 같이 쿼리를 받고, 컴파일 하고 실행할 수 있도록 하는 일부 데이터베이스 관리 시스템의 기능이다.

나중에 $statement->execute()을 호출할 때 여러분은 플레이스 홀더를 위해 값을 넘기고 데이터베이스 관리 시스템에게 실제로 쿼리를 실행하라고 전달한다. 그것은 여러분의 템플릿 엔진에 있는 render() 함수를 호출하는 것과 같다.

실제 예시로 위해 데이터베이스에서 지정한 id를 반환하는 쿼리를 생성해보자.

$statement = $connection->prepare('Select * From users Where id = :id');

위의 PHP 코드는 :id 플레이스 홀더를 포함하여, 데이터베이스 관리 시스템으로 구문을 전송한다. 데이터베이스 관리 시스템은 쿼리를 파싱하고 컴파일 하고 사용자 설정에 기초하여 미래의 성능 향상을 위해 캐싱한다. 이제 여러분은 데이터베이스 엔진에 매개 변수를 전달하고 쿼리를 실행하라고 명령할 수 있다.

$id = 5;
$statement->execute([
    ':id' => $id
]);

그러면 여러분은 이 구문에서 결과를 가져올 수 있다.
$results = $statement->fetchAll(PDO::FETCH_OBJ);

파라미터 바인딩의 장점

이제 여러분은 prepared statement가 동작하는 방법에 대해 더 익숙해졌고 아마 장점에 대해 생각할 수 있을 것이다.

PDO는 여러분의 손에서 사용자로부터 받은 입력값을 이스케이프하고 쿼팅하는 작업을 해야한다. 예를 들어 이제 여러분은 다음과 같은 코드를 작성할 필요가 없다.
$results = mysql_query(sprintf("SELECT * FROM users WHERE name='%s'",
        mysql_real_escape_string($name)
    )
) or die(mysql_error());

대신 다음과 같이 명령할 수 있다.

$statement = $connection->prepare('Select * FROM users WHERE name = :name');
$results = $connection->execute([
    ':name' => $name
]);

저 코드가 충분히 짧다고 느껴지지 않다면 명명된 변수 같이 행동하는 것보다는 그저 플레이스 홀더 번호가 매겨진 것을 의미하는 명명되지 않은 제공 파라미터로 더 짧게 만들 수도 있다.
$statement = $connection->prepare('SELECT * FROM users WHERE name = ?');
$results = $connection->execute([$name]);

마찬가지로 prepared statement를 가진다는 것은 동시에 쿼리를 실행할 때 성능 향상을 얻을 수 있다는 것을 의미한다. 함께 사용자 테이블에서 5명의 무작위 사람들 목록을 검색해보자.

$numberOfUsers = $connection->query('SELECT COUNT(*) FROM users')->fetchColumn();
$users = [];
$statement = $connection->prepare('SELECT * FROM users WHERE id = ? LIMIT 1');

for ($i = 1; $i <= 5; $i++) {
    $id = rand(1, $numberOfUsers);
    $users[] = $statement->execute([$id])->fetch(PDO::FETCH_OBJ);
}
우리는 먼저 준비한 함수를 호출할 때 DBMS에 파싱하고 컴파일 하고 쿼리를 캐싱하라고 요청한다. 나중에 for문 루프에서 플레이스 홀더만을 위한 값을 전달한다. 이것은 애플리케이션이 데이터베이스 결과를 검색하기 위해 필요한 시간을 효율적으로 줄여서 쿼리가 빠르게 실행하고 반환할 수 있도록 한다

여러분은 또한 내가 위의 코드 일부에서 새로운 함수 fetchColumn를 사용 했다는 것을
발견했을 수도 있다. 아마 추측할 수 있듯이 이것은 결과값에서 오직 하나만 반환하는 count, sum, min, max, 기타 다른 함수 같이 컬럼 한 개를 반환하고 쿼리 결과값에서 스칼라 값을 얻기에 좋은 방법이다.

IN 절 값 바인딩
처음 PDO에 대해 배우기 시작할 때 많은 사람들이 난처하게 생각하는 것은 IN절입니다. 예를 들어 우리가 사용자에게 콤마로 구분된 $names로 저장한 이름 리스트로 입력하도록 허용했다고 상상해보자. 지금까지 우리의 코드는 이렇다.

$names = explode(',', $names);

대부분의 사람들이 이 지점에서 하는 것은 다음과 같다.

$statement = $connection->prepare('SELECT * FROM users WHERE name IN (:names)');
$statement->execute([':names' => $names]);

이 코드는 동작하지 않는다 - 여러분은 prepared statement으로 스칼라 값 (정수, 문자열 등등) 에 전달만 할 수 있다! 작업을 수행하는 방법은 - 짐작하겠지만 - 문자열을 직접 구성하는 것이다.

$names = explode(',', $names);
$placeholder = implode(',', array_fill(0, count($names), '?'));

$statement = $connection->prepare("SELECT * FROM users WHERE name IN ($placeholder)");
$statement->execute([$names]);

그 무서운 모습에도 불구하고 2번째 줄은 간단하게 많은 요소를 가지고 있는 names
배열을 물음표 배열로 생성한다. 그 다음 배열 내부에 요소를 연결하여 그들 사이에 ,를 배치하여 효율적으로 ?,?,?,?같은 문자열을 생성한다.
names 배열은 또한 배열이기 때문에 예상대로 첫번째 요소는 첫번째 물음표에 바인드 되고 두번쨰는 두번째 물음표에 바인드 되는 등등 execute() 작업에 전달한다.

파라미터를 바인딩할 때 제공되는 데이터 타입

PDO를 배우기 시작할 때 우리는 위에서 파라미터에 값을 바인딩 하는 것을 보여준 기법은 좋지만 항상 여러분이 바인딩하는 모든 파라미터의 유형을 지정하는 것이 좋다. 왜일까?
  • 가독성: 누군가가 여러분의 코드를 읽을 때 파라미터에 바인딩하기 위해 변수 타입이 있어야 보기에 쉽다.
  • 유지보수성: 쿼리의 첫번째 자리가 정수여야 하는 것을 알고 있다는 것은 여러분이 밖으로 미끄러져 나온 오류를 잡을 수 있다.
  • 속도: 여러분이 변수의 데이터 타입을 지정할 때 여러분은 여러분의 데이터베이스 관리 시스템에 이 변수를 캐스팅할 필요가 없으며 올바른 타입으로 제공하고 있다는 것을 전달한다. 이런식으로 여러분은 데이터 타입 사이에 캐스팅된 (작은) 오버헤드가 필요 없다.
각 변수의 타입을 지정하기 위하여 나는 개인적으로 bindValue 함수를 추천한다. 위에서 플레이스홀더 타입을 지정한 코드를 변경해보자.

$numberOfUsers = $connection->query('SELECT COUNT(*) FROM users')->fetchColumn();
$users = [];
$statement = $connection->prepare('SELECT * FROM users WHERE id = ? LIMIT 1');

for ($i = 1; $i <= 5; $i++) {
    $id = rand(1, $numberOfUsers);
    $statement->bindValue(1, $id, PDO::PARAM_INT);
    $statement->execute();
    $users[] = $statement->fetch(PDO::FETCH_OBJ);
}

여러분도 볼 수 있듯 변경된 것은 execute() 호출 뿐이다. 값을 똑바로 전달하는 대신에 먼저 바운딩하고 타입이 정수라고 지정했다.
참고: 여러분은 아마 1로 bindValue()에 첫 파라미터를 지정했다는 것을 알아차렸을 것이다. 만약 우리가 명명된 파라미터 (추천) 을 사용했ek면 우리는 우리의 파라미터 이름 (예: :id) 으로 전달 할 것이다. 그러나 플레이스 홀더로 ?를 사용한 경우 bindValue() 첫번째 인자는 여러분이 언급하는 물음표를 지정한 숫자이다. 조심하라. 이것은 인덱스 위치 1이며 0이 아닌 1에서 시작한다는 것을 의미한다.

결론

PHP가 향상되면서 프로그래머 또한 이것을 사용한다. PDO는 여러분이 더 나은 코드를 작성할 수 있는 차세대 확장 기능이다. 그것은 일하기에 민첩하고 빠르고 읽기 쉽고 기쁜데 여러분의 프로젝스를 왜 구현하지 않겠는가?

여러분의 프로젝트에 PDO를 구현해본적 있는가? 여러분이 직면한 문제는 무엇인가? 여러분은 마이그레이션해서 기쁜가? 여러분은 어떤 기능을 보고 싶은가? 아래에 댓글로 알려주어라!
continue reading [번역] PDO 다시소개하기 – PHP에서 데이터베이스에 접근하는 올바른 방법
Share This:    Facebook Twitter

2015-09-03

[번역] 의존성 관리 도구 컴포저 - 명령어 줄 인터페이스 / 명령어

* 원문: https://getcomposer.org/doc/03-cli.md

워낙 양이 많아서 나눠서 해볼까 고민하다가 한 페이지인데 나눠서 뭐하나 싶기도 해도 한꺼번에 번역해보았습니다.



명령어 줄 인터페이스 / 명령어

여러분은 이미 명령어 줄 인터페이스를 어떻게 사용하는지 배웠다. 이 장은 사용할 수 있는 명령어를 모은 문서이다.

명령어 줄에서 도움을 받으려면 모든 명령어 리스트를 보기 위해 간단하게 composercomposer list를 호출하고 정보를 얻고 싶은 명령어와 --help를 합쳐서 호출하면 된다.

전역 옵션

다음 옵션은 모든 명령어에 사용할 수 있다.
  • --verbose (-v): 메세지의 자세하게 표시한다.
  • --help (-h): 도움말 정보를 표시한다.
  • --quiet (-q): 어떤 메세지도 출력하지 않는다.
  • --no-interaction (-n): 어떤 대화식 질문도 하지 않는다.
  • --working-dir (-d): 지정되면 작업 디렉토리로 지정된 디렉토리를 사용한다.
  • --profile: 타이밍과 메모리 사용 정보를 표시한다.
  • --ansi: ANSI로 강제 출력한다.
  • --no-ansi: ANSI 출력을 비활성화 한다.
  • --version (-V): 애플리케이션 버전을 표시한다.

종료 코드 과정

  • 0: OK
  • 1: 일반/알 수 없는 오류 코드
  • 2: 의존성 해결 오류 코드

init

라이브러리 장에서 우리는 수동으로 composer.json를 어떻게 만드는지 살펴보았다. init 명령어는 이러한 절차를 조금 더 쉽게 할 수 있다.

이 명령어를 실행하면 일부 기본 값을 사용하면서 대화형으로 항목을 기입할 수 있을 것이다.

php composer.phar init

옵션

  • --name: 패키지 이름
  • --description: 패키지 설명
  • --author: 패키지 제작자 이름
  • --homepage: 패키지 홈페이지
  • --require: 패키지 버전 제약 조건을 요구한다. foo/bar:1.0.0 형식이어야 한다.
  • --require-dev: 개발 요구 사항, --require 참고
  • --stability (-s): minimun-stability항목 값

install

install 명령어는 현재 디렉터리에서 composer.json 파일을 읽고 종속성을 해결하고 vendor로 설치한다.

php composer.phar install

현재 디렉터리에 composer.lock 파일이 있으면 composer.json 파일을 해결하는 대신 그 파일에서 정확한 버전을 사용할 것이다. 라이브러리를 사용하는 모든 사람은 같은 의존성을 얻는다는 것을 보장한다.

composer.lock 파일이 없으면 컴포저는 종속성 작업을 처리한 후에 파일을 생성할 것이다.

옵션

  • --prefer-source: 패키지를 다운로드하는 방법에는 sourcedist 이렇게 2가지 방법이 있다. 안정 버전의 경우 컴포저는 기본적으로 dist를 사용한다. source는 버전 관리 저장소이다. --prefer-source를 사용할 수 있고 존재한다면 컴포저는 source에서 설치할 것이다. 이는 프로젝트에 버그 수정을 하고 직접 종속성의 로컬 git 클론을 얻을 때 유용하다.
  • --prefer-dist: --prefer-source의 반대이다. 컴포저는 가능하면 dist에서 설치한다. 이 명령어는 빌드 서버와 일반적으로 벤더 업데이트를 실행하지 않는 다른 경우에 대체로 설치 속도를 높일 수 있다. 이 옵션은 올바른 설정이 없는 경우 git의 문제를 회피하는 방법이다.
  • --ignore-platform-reqs: php, hhvm, lib-*, ext-* 요청을 무시하고 로컬 기기가 이행하지 않아도 강제로 설치한다. platform 설정 옵션을 참고하라.
  • --dry-run: 만약 실제로 패키지 설치 없이 설치를 통해 실행하고 싶으면 여러분은 --dry-run을 사용할 수 있다. 이것은 설치를 시뮬레이션하고 어떤 일이 일어나는지 보여준다.
  • --dev: require-dev에서 나열된 패키지를 설치한다 (기본 동작이다).
  • --no-dev: require-dev에서 나열된 패키지 설치를 건너뛴다. 자동 로드 생성은 자동 로드-개발 규칙을 건너 뛴다.
  • --no-autoloader: 자동 로드 생성을 건너뛴다.
  • --no-scripts: composer.json에서 정의된 스크립트 실행을 건너 뛴다.
  • --no-plugins: 플러그인을 비활성화 한다.
  • --no-progress: 백 스페이스 문자를 처리하지 않는 일부 터미널이나 스크립트를 엉망으로 만들 수 있는 진행 표시를 제거한다.
  • --optimize-autoloader (-o): 빠른 오토로드를 얻기 위해 PSR-0/4를 클래스 맵으로 변환한다. 특히 실제품에 추천하지만 실행하는데 시간이 더 걸리므로 기본적으로 수행하지 않는다.

update

의존성 최신 버전을 받고 composer.lock 파일을 업데이트 하기 위해서 update 명령어를 사용해야 한다.

php composer.phar update
이것은 프로젝트에서 모든 의존성을 해결하고 composer.lock에 정확한 버전을 작성할 것이다.

만약 여러분이 몇몇 패키지와 일부를 업데이트 하고 싶으면 여러분은 다음와 같이 나열할 수 있다.

php composer.phar update vendor/package vendor/package2
또한 한번에 패키지를 업데이트하기 위해 와일드 카드 문자(*)를 사용할 수 있다.

php composer.phar update vendor/*

옵션

  • --prefer-source: 사용할 수 있을 때 source로 패키지를 설치한다.
  • --prefer-dist: 사용할 수 있을 때 dist로 패키지를 설치한다.
  • --ignore-platform-reqs: php, hhvm, ext-* 요청을 무시하고 로컬 기기가 이행하지 않아도 강제로 설치한다. platform 설정 옵션을 참조하라.
  • --dry-run: 실제 동작 없이 명령어를 시뮬레이션한다.
  • --dev: require-dev에서 설치한 패키지를 나열한다 (기본 동작이다).
  • --no-dev: require-dev에서 설치한 패키지를 나열하는 것을 건너 뛴다. 자동 로드 생성은 autoload-dev 규칙을 건너뛴다.
  • --no-autoloader: 자동 로드 생성을 건너뛴다.
  • --no-scripts: composer.json에서 정의한 스크립트 실행 동작을 건너뛴다.
  • --no-plugins: 플러그인을 비활성화 한다.
  • --no-progress: 백스페이스를 다룰 수 없는 몇몇 터미널이나 스크립트에서 엉망으로 만들 수도 있는 진행바 표시를 제거한다.
  • --optimize-autoloader (-o): 빠른 오토로드를 얻기 위해 PSR-0/4를 클래스 맵으로 변환한다. 특히 실제품에 추천하지만 실행하는데 시간이 더 걸리므로 기본적으로 수행하지 않는다.
  • --lock: 오래된 잠금 파일에 대해 경고를 숨기기 위해 잠금 파일 해시를 업데이트만 한다.
  • --with-dependencies: 허용 목록을 위해 허용된 패키지의 모든 의존성을 추가한다.
  • --prefer-stable: 안정적인 의존성 버전을 우선 시 한다.
  • --prefer-lowest: 가장 낮은 의존성 버전을 우선 시 한다. 최소 요구를 테스트할 때 유용하고 일반적으로 --prefer-stable와 같이 사용한다.

require

require 명령어는 현재 디렉터리에서 composer.json 파일에 새 패키지를 추가한다. 파일이 존재하지 않으면 바로 파일을 하나 생성한다.

php composer.phar require
추가/변경 요청 후에 수정 요구는 설치되거나 업데이트 될 것이다.

만약 대화형으로 요구 사항을 선택하고 싶지 않으면 이 명령어를 통해 통과하면 된다.

php composer.phar require vendor/package:2.* vendor/package2:dev-master

옵션

  • --prefer-source: 사용할 수 있을 때 source로 패키지를 설치한다.
  • --prefer-dist: 사용할 수 있을 때 dist로 패키지를 설치한다.
  • --ignore-platform-reqs: php, hhvm, ext-* 요청을 무시하고 로컬 기기가 이행하지 않아도 강제로 설치한다. platform 설정 옵션을 참조하라.
  • --dev: require-dev로 패키지를 추가한다.
  • --no-update: 의존성을 자동으로 업데이트 하는 것을 비활성화 한다.
  • --no-progress: 백 스페이스 문자를 처리하지 않아서 일부 터미널이나 스크립트를 혼란스럽게 할 진행 표시를 제거한다.
  • --update-no-dev: no-dev 옵션으로 의존성 업데이트를 실행한다.
  • --update-with-dependencies: 새롭게 패키지를 요구한 의존성을 업데이트한다.
  • --sort-packages: composer.json에서 패키지가 정렬되는 것을 유지한다.

remove

remove 명령어는 현재 디렉터리의 composer.json 파일에서 패키지를 제거한다.

php composer.phar remove vendor/package vendor/package2
요청대로 제거한 후에 수정된 요구 사항은 삭제 된다.

옵션

  • --ignore-platform-reqs: php, hhvm, ext-* 요청을 무시하고
  • 로컬 기기가 이행하지 않아도 강제로 설치한다. platform 설정 옵션을 참조하라.
  • --dev: require-dev로 패키지를 제거한다.
  • --no-update: 의존성을 자동으로 업데이트 하는 것을 비활성화 한다.
  • --no-progress: 백 스페이스 문자를 처리하지 않아서 일부 터미널이나 스크립트를 혼란스럽게 할 진행 표시를 제거한다.
  • --update-no-dev: --no-dev 옵션과 함께 의존성 업데이트를 실행한다.
  • --update-with-dependencies: 제거한 패키지의 의존성을 업데이트 한다.

global

전역 명령어는 마치 COMPOSER_HOME 디렉터리에서 실행한 것처럼 install, require, update같은 다른 명령어를 실행할 수 있다.

이 명령어는 환경 변수 $PATH$COMPOSER_HOME/vendor/bin를 추가한다면 전역으로 CLI 유틸리티를 설치할 때 사용할 수 있다. 여기에 예제가 있다.

php composer.phar global require fabpot/php-cs-fixer:dev-master
이제 php-cs-fixer 바이너리는 (당신이 경로를 조정했다는 가정 하에) 전역으로 사용할 수 있다. 만약 여러분이 나중에 바이너리를 업데이트 하고 싶으면 전역 업데이트를 실행하면 된다.

php composer.phar global update

search

검색 명령어는 현재 프로젝트 패키지 저장소를 통해 검색할 수 있다. 보통 이 방법은 패키지스트가 할 것이다. 여러분은 단순히 검색할 조건을 전달한다.

php composer.phar search monolog
여러분은 다중 인자를 통해 둘 이상의 용어를 검색할 수 있다.

옵션

  • --only-name (-N): 이름으로만 검색

show

사용할 수 있는 패키지를 나열하기 위해서 show 명령어를 사용할 수 있다.

php composer.phar show monolog/monolog

name     : monolog/monolog
versions : master-dev, 1.0.2, 1.0.1, 1.0.0, 1.0.0-RC1
type     : library
names    : monolog/monolog
source   : [git] https://github.com/Seldaek/monolog.git 3d4e60d0cbc4b888fe5ad223d77964428b1978da
dist     : [zip] https://github.com/Seldaek/monolog/zipball/3d4e60d0cbc4b888fe5ad223d77964428b1978da 3d4e60d0cbc4b888fe5ad223d77964428b1978da
license  : MIT

autoload
psr-0
Monolog : src/

requires
php >=5.3.0

옵션

  • --installed (-i): 설치된 패키지 목록.
  • --platform (-p): 플랫폼 패키지 목록 (php & 확장 기능).
  • --self (-s): 루트 패키지 정보 목록


browse / home

browse (별칭 home)는 브라우저에서 패키지 저장소 URL이나 홈페이지를 연다.

옵션

  • --homepage (-H): 저장소 URL 대신 홈페이지를 연다.


suggests

현재 설치된 패키지 세트는 모든 패키지 목록을 제안한다. 여러분은
그들의 패키지에 의해 만들어진 제안 결과물을 제한하기 위해
vendor/package 형식에서
선택적으로 하나 또는 여러개 패키지 이름을 건너뛸 수 있다.

옵션

  • --no-dev:require-dev 패키지에서 제안을 제외한다.
  • --verbose: (-v): 증가된 상세 내용은 제안한 패키지 이름과 제안 이유를 추가한다.


depends

depends 명령어는 다른 패키지가 특정 패키지에 의존한다는 것을 말한다. 여러분은 리스트에 포함되어야 하는 링크 유형(require, require-dev) 을 지정할 수 있다. 기본적으로 모두 사용된다.

php composer.phar depends --link-type=require monolog/monolog

nrk/monolog-fluent
poc/poc
propel/propel
symfony/monolog-bridge
symfony/symfony

옵션

  • --link-type : 링크 유형을 여러번 지정할 수 있다.


validate

여러분은 composer.json 파일을 실행하기 전에 혹은 태그를 릴리즈하기 전에 항상 validate를 실행해야 한다. composer.json가 유효하다면 확인할 것이다.

php composer.phar validate

옵션

  • --no-check-all: composer.json에 있는 요구사항이 언바운드 버전 제약이면 경고 (warning) 를 표시하지 않는다.
  • --no-check-lock: composer.lock 파일이 존재하거나 최신 파일이 아니면 에러 (error) 를 표시하지 않는다.
  • --no-check-publish: composer.json 파일이 패키지스트에 패키지로 발행하기에 적합하지 않으면 에러 (error)를 표시하지 않지만 그렇지 않으면 유효하다.

status

만약 여러분이 의존성 코드나 설치된 소스를 자주 수정한다면 status 명령어는 여러분이 로컬에서 변경되었는지 확인할 수 있다.

php composer.phar status

--verbose 옵션를 함께 쓰면 여러분이 변경된 정보에 대해 더 자세히 알 수 있다.

php composer.phar status -v

You have changes in the following dependencies:
vendor/seld/jsonlint:
    M README.mdown

self-update

컴포저 스스로 최신 버전으로 업데이트하기 위해서 그냥 self-update 명령어를 실행하면 된다. 이 명령어는 composer.phar 파일을 최신 버전으로 교체할 것이다.

php composer.phar self-update

특정 릴리즈를 간단하게 업데이트 하려면 다음과 같이 사용하면 된다.

php composer.phar self-update 1.0.0-alpha7

전체 시스템 (전역 설치 참고) 에 설치된 컴포저가 있다면 root 권한으로 명령어를 실행할 것이다.

sudo composer self-update

옵션

  • --rollback (-r): 설치된 마지막 버전으로 롤백한다.
  • --clean-backups: 업데이트 하는 동안 오래된 백업을 삭제한다. 업데이트 후에 컴포저의 현재 버전이 사용할 수 있는 백업 하나를 만든다.

config

config 명령어는 여러분이 로컬 composer.json 파일이나 전역 config.json 파일에서 몇몇 컴포저 기본 설정을 수정할 수 있도록 해준다.

php composer.phar config --list

사용

config [options] [setting-key] [setting-valu1] ... [setting-valueN]

setting-key는 설정 옵션 이름이고 setting-value1은 설정 값이다.
(github-protocols 같이) 배열 값일 경우 허용된 설정 값 인자가 하나 이상이다.

유효한 설정 옵션을 보려면 설정 장을 참고하라.

옵션

  • --global (-g): 기본으로 $COMPOSER_HOME/config.json에 위치한 전역 설정 파일을 운영한다.
    이 옵션이 없으면 이 명령어는 로컬 composer.json 파일이나 --file로 지정된 파일에 영향을 미친다.
  • --editor (-e): 환경 변수 EDITOR가 정의한 텍스트 에디터에서 로컬 composer.json 파일을 사용하여 연다. --global 옵션을 사용하면 전역 설정 파일을 연다.
  • --unset: setting-key가 지은 설정 요소를 제거한다.
  • --list (-l): 현재 설정 변수 리스트를 보여준다. --global 옵션을 사용하면 전역 설정만 출력한다.
  • --file="..." (-f): composer.json 대신에 특정파일을 운영한다. --global 옵션과 함께 사용할 수 없음을 숙지하자.
  • --absolute: 상대 경로 대신에 *-dir 설정값을 패치할 때 절대 경로로 반환한다.

수정된 저장소

추가적으로 설정 영역을 수정하려면 config 명령어는 다음과 같은 방법을 사용하여 변경 사항을 지원한다.

php composer.phar config repositories.foo vcs https://github.com/foo/bar

create-project

여러분은 컴포저로 존재하는 패키지에서 새로운 프로젝트를 생성할 수 있다. 이는 vendor의 "컴포저 설치" 다음에 git 클론이나 svn 체크아웃을 하는 것과 같다.

여기에 여러가지 애플리케이션이 있다.
  1. 여러분은 애플리케이션 패키지를 배치할 수 있다.
  2. 여러분은 어떤 패키지를 확인하고 예를 들어 패치에서 개발을 시작할 수 있다.
  3. 여러 개발자가 참여하는 프로젝트는 개발을 위해 초기 애플리케이션을 설정하기 위한 기능을 사용할 수 있다.

컴포저를 사용하는 새 프로젝트를 생성하려면 여러분은 "create-project" 명령어를 사용할 수 있다. 패키지 이름을 전달하고 디렉토리에서 프로젝트를 만들 수 있다. 여러분은 또한 3번째 인자로 버전을 전달할 수 있고 전달하지 않으면 최신 버전이 사용된다.

디렉토리가 현재 존재하지 않으면 설치하는 동안에 생성한다.

php composer.phar create-project doctrine/orm path 2.2.*
프로젝트를 초기 설정하기 위해 기존 composer.json로 디렉토리에서 파라미터 없이 명령어를 실행할 수도 있다.

기본적으로 명령어는 packagist.org에서 패키지를 확인한다.

옵션

  • --repository-url: 패키지를 찾기 위해 커스텀 저장소를 제공하고 패키지스트 대신에 사용된다.
    composer 저장소를 가리키는 HTTP URL이든 로컬 packages.json 파일 경로든 할 수 있다.
  • --stability (-s): 패키지의 최소 안정성. stable가 기본이다.
  • --prefer-source: 사용 가능할 때 source로 패키지를 설치한다.
  • --prefer-dist: 사용 가능할 때 dist로 패키지를 설치한다.
  • --dev: require-dev에서 설치한 패키지를 나열한다.
  • --no-install: vendor 설치를 비활성화한다.
  • --no-plugins: 플러그인을 비활성화한다.
  • --no-scripts: 루트 패키지에서 정의된 스크립트 실행을 비활성화한다.
  • --no-progress: 백스페이스를 다룰 수 없는 몇몇 터미널이나 스크립트에서 엉망으로 만들 수도 있는 진행바 표시를 제거한다.
  • --keep-vcs: 생성된 프로젝트를 위해 VCS 메타 데이터 제거하는 절차를 건너뛴다. 이 옵션은 인터렉티브하지 않은 환경에서 명령어를 실행한다면 아주 유용하다.
  • --ignore-platform-reqs: php, hhvm, lib-*, ext-* 요구사항을 무시하고
    로컬 기기에서 이행하지 않아도 강제로 설치한다.


dump-autoload

예를 들어 만약 여러분이 classmap 패키지에서 새로운 클래스 때문에 오토로드를 업데이트할 필요가 있다면 여러분은 설치나 업데이트를 쓸 필요 없이 "dump-autoload"를 사용하면 된다.

추가적으로 성능상의 이유로 클래스 맵으로 PSR-0/4을 변환한 최적화 오토로더를 내려 받을 수 있다. 많은 클래스가 있는 큰 애플리케이션에서 오토로드는 매 요청 시간의 상당한 부분을 차지한다. 개발 할 때 전부 클래스맵을 사용하는 것은 그닥 편리하지는 않지만 이 옵션을 사용하여 편의를 위한 PSR-0/4와 성능을 위한 클래스 맵을 사용할 수 있다.

옵션

  • --optimize (-o): 빠른 오토로드를 얻기 위해 PSR-0/4를 클래스 맵으로 변환한다. 특히 실제품에 추천하지만 실행하는데 시간이 더 걸리므로 기본적으로 수행하지 않는다.
  • --no-dev: 오토로드 개발용 규칙을 비활성화한다.


clear-cache

컴포터 캐시 디렉토리에 있는 모든 컨텐츠를 제거한다.

licenses

설치된 모든 패키지의 이름, 버전, 라이센스 목록을 출력한다. --format=json을 사용하여 기기가 읽을 수 있도록 결과물을 얻을 수 있다.

옵션

  • --no-dev: 결과물에서 개발 의존성을 제거한다.
  • --format: 결과물 포맷: text나 json (기본값: "text")


run-script

옵션

  • --no-dev: 개발 모드를 비활성화
  • --list: 사용자가 정의한 스크립트를 나열한다.
수동으로 이 명령어를 사용할 수 있는 스크립트를 실행하려면 그냥 스크립트 이름과 필요한 인수를 선택적으로 전달하면 된다.

diagnose

만일 여러분이 버그나 이상하게 동작하는 부분을 찾았다고 생각하면 여러분은 일반적인 문제에 대해 자동 검사를 수행하기 위해 diagnose 명령어를 실행하고 싶을 수도 있다.

php composer.phar diagnose

archive

이 명령어는 주어진 버전에서 지정된 패키지를 위해 zip/tar 아카이브를 생성하는데 사용한다. 또한 제외나 무시되는 파일 없이 전체 프로젝트를 보관하는데 사용할 수도 있다.

php composer.phar archive vendor/package 2.0.21 --format=zip

옵션

  • --format (-f): 결과 아카이브의 포맷: tar, zip (기본값: "tar")
  • --dir: 이 디렉토리에 아카이브를 작성 (기본값: ".")


help

어떤 명령어에 대해 더 많은 정보를 얻고 싶으면 그냥 help를 쓰면된다.

php composer.phar help install

환경 변수

여러분은 특정 설정을 재정의한 다양한 환경 변수를 설정할 수 있다. 가능하면 composer.json 대신 config 영역에서 이 설정을 지정하는 것이 좋다. 환경 변수 composer.json에서 지정된 값보다 항상 더 우선순위를 가지는 것에 대해 주목할 필요가 있다.

COMPOSER

COMPOSER 환경 변수를 설정하여 composer.json 파일이름을 다른 것으로 설정할 수 있다.

예를 들어,
COMPOSER=composer-other.json php composer.phar install
이 예제를 실행하면 composer-other.lock라는 이름으로 잠금파일이 생성될 것이다.

COMPOSER_ROOT_VERSION

이 변수를 설정하면 VCS 정보에서 추측할 수 없고 composer.json에서 존재하지 않으면 여러분이 루트 패키지의 버전을 지정할 수 있다.

COMPOSER_VENDOR_DIR

이 변수를 설정하면 여러분은 vendor가 아닌 다른 디렉토리로 의존성을 설치할 수 있도록 한다.

COMPOSER_BIN_DIR

이 옵션을 설정하면 여러분은 vendor/bin가 아닌 다른 디렉토리로 bin (Vendor 바이너리) 로 변경할 수 있다.

http_proxy나 HTTP_PROXY

만일 HTTP 프록시 뒤에서 컴포저를 사용하는 경우 여러분은 표준 http_proxyHTTP_PROXY 환경 변수를 사용할 수 있다. 간단하게 여러분의 프록시 URL를 설정한다. 대다수의 운영 시스템은 이미 여러분을 위해 변수를 설정하고 있다.

http_proxy (소문자) 를 사용하는 것이나 심지어 모두를 정의하는 것은 git이나 curl이 소문자 http_proxy 버전을 사용하는 몇몇 도구들 때문에 바람직할지도 모른다. 그렇게 하지 않으면 여러분은 git config --global http.proxy 를 사용하는 git 프록시를 정의할 수도 있다.

no_proxy

만일 프록시를 통하면서 특정 도메인을 해제하려는 경우 여러분은 no_proxy 환경 변수를 사용할 수 있다. 간단하게 프록시를 사용하지 않아야 하는 도메인을 쉼표로 구분하여 설정한다.

환경 변수가 CIDR 표기법으로 작성한 도메인, IP 주소, IP 차단 주소를 승인한다. 여러분은 특정 포트에 제한을 걸 수 있다 (예: :80). 여러분은 *를 설정하여 모든 HTTP 요청 프록시를 무시할 수도 있다.

HTTP_PROXY_REQUEST_FULLURI

만일 프록시를 사용하지만 request_fulluri 플래그를 지원하지 않는다면 여러분은 컴포저에서 request_fulluri 옵션을 설정하는 것을 막기 위해 이 환경 변수를  false나 0으로 설정해야 한다.

HTTPS_PROXY_REQUEST_FULLURI

만일 프록시를 사용하지만 HTTPS를 요청하는 request_fulluri 플래그를 지원하지 않는다면 여러분은 컴포저에서 request_fulluri 옵션을 설정하는 것을 막기 위해 이 환경 변수를  false나 0으로 설정해야 한다.

COMPOSER_HOME

COMPOSER_HOME 변수는 여러분이 컴포터 홈 디렉토리를 변경하도록 해준다. 이는 모든 프로젝트가 공유되는 전역 (시스템 사용자별) 디렉토리이고 숨겨져 있다.

기본적으로 *nix에서 /home//.composer, OSX에서 /Users//.composer, 윈도우에서 C:\Users\\AppData\Roaming\Composer를 가리키고 있다.

COMPOSER_HOME/config.json

여러분은 composer.json 파일을 COMPOSER_HOME이 가리키고 있는 위치에 놓을 수 있다. 컴포저는 여러분이 install이나 update 명령어를 실행하면 이 설정과 여러분의 프로젝트 composer.json를 병합할 것이다.

이 파일은 여러분이 사용자 프로젝트의 저장소구성을 설정할 수 있도록 해준다.

전역 설정이 로컬 설정이 충돌하는 경우에 프로젝트의 composer.json에 있는 로컬 설정이 항상 이긴다.

COMPOSER_CACHE_DIR

COMPOSER_CACHE_DIR 변수는 여러분이 컴포저 캐시 디렉토리를 변경할수 있도록 해주며 cache-dir 옵션을 통해 설정할 수도 있다.

기본적으로 *nix, OSX에서 $COMPOSER_HOME/cache, 윈도우즈에서는 C:\Users\<user>\AppData\Local\Composer 또는 %LOCALAPPDATA%/Composer를 가리키고 있다.

COMPOSER_PROCESS_TIMEOUT

이 환경 변수는 명령어 (git 명령어 같은) 실행을 완수하기 위한 컴포저 대기시간을 조정한다. 기본값은 300초이다 (5분).

COMPOSER_DISCARD_CHANGES

이 환경 변수는 discard-changes 설정 옵션을 조정한다.

COMPOSER_NO_INTERACTION

1로 설정되어 있으면 이 환경 변수는 컴포저가 모든 명령어에 --no-interation를 전달하는 것처럼 동작할 것이다. 이것은 boxes/CI 빌드에서 설정할 수 있다.
continue reading [번역] 의존성 관리 도구 컴포저 - 명령어 줄 인터페이스 / 명령어
Share This:    Facebook Twitter

2015-07-16

[번역] 의존성 관리 도구 컴포저 - 라이브러리

* url: https://getcomposer.org/doc/02-libraries.md

라이브러리

이번 장은 컴포저를 통해서 설치할 수 있는 라이브러리를 만드는지 이야기할 것이다.

모든 프로젝트는 패키지이다

디렉토리에서 composer.json파일을 만드는 즉시 그 디렉토리는 패키지가 된다. 여러분은 require를 프로젝트에 추가할 때 다른 패키지에 의존하는 패키지를 만드는 셈이다. 여러분의 프로젝트와 라이브러리의 차이점은 여러분의 프로젝트가 이름 없는 패키지라는 점이다.

그 패키지를 설치 가능하도록 하기 위해서 이름을 지정해야한다. composer.json 파일에서 name 속성을 추가한다.

{
    "name": "acme/hello-world",
    "require": {
        "monolog/monolog": "1.0.*"
    }
}
프로젝트 이름이 acme/hello-world인 경우에 acme 부분은  벤더 이름이다. 벤더 이름을 제공하는 것은 필수이다.
참고: 만약 여러분이 벤더 이름을 어떤 것으로 사용 할 지 모르겠다면 보통 GitHub 사용자 이름이 괜찮다. 패키지 이름은 대소문자를 구별하고 있지만 모두 소문자로 하고 단어 구분은 하이픈으로 사용하는 것을 규칙으로 하고 있다.

플랫폼 패키지

컴포저에는 플랫폼 패키지가 있는데 시스템에 설치되어 있는 가상 패키지이지만 실제로는 컴포저가 설치한 것이 아니다. 이는 PHP 자체, PHP 확장 기능, 몇몇 시스템 라이브러리를 포함하고 있다.
  • php는 제약 조건을 적용할 수 있도록 사용자 PHP 버전을 나타낸다. 예: >=5.4.0. PHP에 64비트 버전을 요청하기 위해 여러분은 php-64bit 패키지를 요청할 수 있다.
  • hhvm는 HHVM 실행 시간 (아카 힙홉 가상 머신) 버전을 나타내고 제약 조건을 적용할 수 있다. 예: '>=2.3.3'.
  • ext-<name>은 PHP 확장 기능 (코어 확장을 포함) 을 요구할 수 있다. 버전 지정은 여기에 아주 일치하지 않을 수도 있기에 보통 별표 (*) 로 제약 조건을 설정하는 것이 좋다. 확장 패키지 이름 예시는 ext-gd이다.
  • lib-<name>은 PHP가 사용하는 라이브러리 버전을 만들도록 제약 조건을 걸 수 있다. 다음은 <name> 부분에 사용할 수 있는 내용이다 : curl, iconv, icu, libxml, openssl, pcre, uuid, xsl.
로컬에서 사용할 수 있는 플랫폼 패키지 리스트를 보려면 show --platform을 사용하면 된다.

버전 지정하기

패키지스트에서 여러분의 패키지를 발행할 때 VCS (git, svn, hg) 정보에서 버전을 유추할 수 있다. 이는 여러분이 명시적으로 선언할 필요가 없다는 것을 의미한다. 버전 숫자가 어떻게 추출되는지 태그브랜치를 읽어보자.

수동으로 패키지를 만들어서 거나 명시적으로 지정해야 하는 경우 여러분은 그저 version 항목을 추가하면 된다.

{
    "version": "1.0.0"
}
참고: 여러분은 되도록이면 명시적으로 버전 항목을 지정하지 않도록 해야한다. 왜냐하면 태그 값은 태그 이름과 일치해야 하기 때문이다.

태그

버전처럼 보이는 모든 태그의 경우 해당 태그의 패키지 버전이 생성될 것이다. 패키지 버전은 -patch (-p), -alpha (-a), -beta (-b), RC의 선택적인 접미사와 함께 'X.Y.Z'나 'vX.Y.Z' 형식과 일치해야 한다. 접미사 뒤에는 숫자가 따라올 수도 있다.

다음은 유효한 태그 이름의 예제들이다.
  • 1.0.0
  • v1.0.0
  • 1.10.5-RC1
  • v4.4.4-beta2
  • v2.0.0-alpha
  • v2.0.4-p1
참고: 여러분의 태그가 v로 시작할지라도 require 구문에서 버전 제약은 접두사 없이 지정해야한다. (예: 태그 v1.0.0은 버전 1.0.0가 된다.)

브랜치

모든 브랜치의 경우 패키지 개발 버전이 생성된다. 브랜치 이름이 버전 이름과 같으면 버전은 {branchname}-dev가 될 것이다. 예를 들어 브랜치 2.02.0.x-dev 버전을 얻는다 (.x는 브랜치로 인식하기 위해 기술적인 이유로 추가됨). 또한 2.0.x 브랜치는 유효할 뿐 아니라 2.0.x-dev로 전환된다. 만약 브랜치가 버전과 같지 않으면 dev-{branchname}가 될 것이다. masterdev-master 버전이 된다.

다음은 버전 브랜치 이름에 관련된 예시이다.
  • 1.x
  • 1.0 (1.0.x와 같음)
  • 1.1.x
참고: 여러분이 개발 버전을 설치하면 그 source에서 자동으로 가져올 것이다. 더 자세한 내용은 install를 참고하라.

별칭

버전에 브랜치 별칭을 지정할 수 있다. 예를 들어 여러분은 dev-master1.0.x-dev로 지정하고 모든 패키지에서 1.0.x-dev를 요구할 수 있다.

더 자세한 내용은 별칭을 참고하라.

잠금 파일

라이브러리의 경우에 여러분이 원하면 composer.lock 파일을 커밋할 수 있다. 이는 여러분의 팀이 동일한 의존성 버전으로 테스트할 수 있도록 도와준다. 그러나 이 잠금 파일은 그것에 의존하는 다른 프로젝트에 어떤 영향도 주지 않을 것이다. 메인 프로젝트에만 영향을 줄 뿐이다.

만약 여러분이 잠금파일을 원하지 않으면서 git을 사용하고 있다면 .gitignore에 추가하라.

VCS로 발행하기

만약 composer.json 파일을 포함하는 VCS 저장소 (버전 관리 시스템, 예: git) 가 있으면 여러분의 라이브러리는 이미 컴포저가 설치할 수 있는 상태이다. 이 경우에 우리는 github.com/username/hello-world 밑에서 GitHub에 acme/hello-world 라이브러리를 발행할 것이다.

이제 acme/hello-world 패키지를 설치 테스트하기 위해서 로컬에 새 프로젝트를 생성한다. 우리는 acme/blog를 호출할 것이다. 이 블로그는 acme/hello-world에 의존하고 또 그것은 monolog/monolog에 의존하고 있을 것이다. 우리는 어딘가에 새 blog 디렉토리를 생성하고 composer.json를 포함하여 수행할 수 있다.

{
    "name": "acme/blog",
    "require": {
        "acme/hello-world": "dev-master"
    }
}
우리는 라이브러리로 이 블로그를 발행하고 싶지 않기 때문에 이 경우에 이름은 반드시 필요하지 않는다. 이름은 composer.json에 기술되는 것을 명확히 하기 위해 추가하였다.

이제 우리는 블로그 앱이 hello-world 의존성을 찾도록 설정해야한다. 우리는 블로그의 composer.json 패키지에 저장소 사양을 추가하여 이 작업을 수행할 수 있다.

{
    "name": "acme/blog",
    "repositories": [
        {
            "type": "vcs",
            "url": "https://github.com/username/hello-world"
        }
    ],
    "require": {
        "acme/hello-world": "dev-master"
    }
}
패키지 저장소가 동작하는 것과 사용할 수 있는 다른 종류에 대해서 더 자세히 알고 싶다면
저장소를 참고하라.

그게 다이다. 여러분은 이제 컴포저 install 명령어를 실행하여 의존성을 설치할 수 있다!

요약: composer.json 를 포함하는 모든 git/svn/hg 저장소는 캐피지 저장소를 지정하고 require 항목에서 의존성을 정의하는 것으로 여러분의 프로젝트에 추가할 수 있다.

패키지스트 발행하기

자, 이제 여러분은 패키지를 발행할 수 있다. 그러나 매번 VCS 저장소를 지정하 것은 번거롭다. 여러분은 모든 사용자가 그렇게 하도록 강요하면 안된다.

여러분이 눈치챈 다른 것은 monolog/monolg를 위한 패키지 저장소를 지정하지 않았다는 것이다. 어떻게 동작하는 것일까? 대답은 패키지스트이다.

패키지스트는 컴포저를 위한 매인 패키지 저장소이고 기본적으로 활성화되어 있다. 패키지스트에서 발행된 모든 것은 컴포저를 통해서 자동으로 사용 가능하다. 모놀로그는 패키지스트에 있기 때문에 우리는 저장소를 추가로 지정하지 않고도 의존할 수 있다.

만약 전세계에 hello-world를 공유하고 싶다면 물론 패키지스트에 발행하면 된다. 이렇게 하면 정말 간단하다.

여러분은 간단히 패키지스트에 방문하고 "Submit"을 누른다. 가입되어 있지 않다면 가입하라는 메세지가 뜰 것이고 패키지스트가 크롤링을 시작하는 지점에서 여러분의 VCS 저장소에서 URL을 전송할 수 있도록 한다. 완료되면 여러분의 패키지는 누구나 사용 할 수 있다!

continue reading [번역] 의존성 관리 도구 컴포저 - 라이브러리
Share This:    Facebook Twitter

2015-07-09

[번역] 의존성 관리 도구 컴포저 - 기본 사용법(Basic usage)

개인 소장용으로 번역한 자료입니다.
참고용으로만 봐주시고, 틀린 점이 있으면 언제든 태클 걸어주세요.

* url: https://getcomposer.org/doc/01-basic-usage.md

기본 사용법

소개

기본 사용법을 소개하면서 로깅 라이브러리인 monolog/monolog를 설치할 것이다. 아직 컴포저를 설치하지 않았다면 소개 장을 참조하라.
참고: 단순화를 위해 이 소개는 컴포저의 로컬 설치를 가정할 것이다.

composer.json: 프로젝트 세팅

프로젝트에 컴포저를 사용하기 위해서 여러분은 composer.json 파일이 필요하다. 이 파일은 여러분의 프로젝트의 의존성에 대해서 기술할 뿐 아니라 다른 메타데이터도 포함할 수 있다.

require

composer.json에서 지정할 첫 번째 (또는 자주 할) 일은 require 키이다. 여러분은 프로젝트에 의존하는 패키지를 컴포저에 간단히 지정할 수 있다.

{
    "require": {
        "monolog/monolog": "1.0.*"
    }
}
보다시피 require은 패키지 이름 (예: monolog/monolog) 을 패키지 버전 (예: 1.0.*) 으로 매핑한 객체를 가져온다.

패키지 이름

패키지 이름은 벤더 이름과 프로젝트 이름으로 구성된다. 보통 벤더 이름과 프로젝트 이름은 동일하다. 벤더 이름은 그저 이름 충돌을 막기 위해 존재하기 때문이다. 벤더 이름은 서로 다른 두 사람이 각각 igorw/jsonseldaek/json으로 json이라는 같은 이름의 라이브러리를 생성할 수 있도록 한다.

우리는 여기서 monolog/monolog를 요구하고 있고 벤더 이름은 프로젝트의 이름과 동일하다. 고유한 프로젝트 이름을 사용하는 것이 좋다. 나중에 같은 네임스페이스 아래서 연관된 프로젝트를 많이 추가할 수 있기 때문이다. 여러분이 라이브러리를 유지한다면 더 작은 부분으로 나누기 쉬울 것이다.

패키지 버전

이전 예제에서 우리는 모놀로그 버전 1.0.* 을 요청했다. 이는 1.0 개발 브랜치의 버전을 의미한다. 그 버전은 >=1.0<1.1과 일치하는 버전에 해당한다.

버전 제약은 몇 가지 방법으로 지정할 수 있고 이 주제에 대한 자세한 정보는 버전 문서를 참조하라.

안정성

기본적으로 안정된 릴리즈만 대상으로 한다. 만약 의존성의 RC, 베타, 알파, 개발 버전을 얻으려면 안정성 플래그를 사용하여 얻을 수 있다. 의존성 하나당 수행하는 것 대신 모든 패키지를 변경하려면 여러분은 최소 안정성 설정을 사용할 수 있다.

의존성 설치

프로젝트에서 정의된 의존성을 설치하려면 그저 install 명령어를 실행하면 된다.

php composer.phar install
이 명령어는 제공된 버전 제약과 일치하는 monolog/monolog의 최신 버전을 찾고 vendor 디렉토리로 다운로드 한다. 이것은 vendor라는 디렉토리로 외부 코드를 놓는 규약이다. 모놀로그의 경우 vendor/monolog/monolog로 놓는다.
팁: 여러분의 프로젝트가 git을 사용한다면 아마 vendor.gitignore에 추가해야 한다. 절대 저장소의 모든 코드를 추가하면 안된다.

여러분은 install 명령이 composer.lock 파일도 만들었다는 것을 알 수 있다.

composer.lock - 잠금파일

의존성 설치 후 컴포저는 composer.lock 파일에 설치해야 할 정확한 버전 리스트를 작성할 것이다. 이것은 특정 버전으로 프로젝트를 고정한다.

버전 컨트롤에 애플리케이션의 (composer.json과 함께) composer.lock을 커밋한다.

이 내용은 중요하다. 왜냐하면 잠금파일이 존재하면 install 명령어는 체크하여 그곳에 (composer.json에 뭐라고 적혀있든지) 지정된 버전을 다운로드 하기 때문이다.

잠금 파일을 커밋하는 것은 프로젝트를 설정하는 그 누구도 의존성에서 정확히 같은 버전을 다운로드 하지 않을 것을 의미한다. 여러분의 CI 서버, 생산 기기, 여러분 팀의 다른 개발자, 모든 것과 모두는 구축하는 일부에 영향을 미치는 버그를 완화하는 동일한 의존성에서 실행한다. 심지어 여러분이 프로젝트 재설치로 6달 동안 혼자 개발할 때도 새로운 버전으로 많이 릴리즈 되더라도 설치된 의존성은 여전히 동작한다고 느낄 수 있다.

만약에 composer.lock 파일이 없으면 컴포저는 composer.json에서 의존성과 버전을 읽고 updateinstall 명령어를 실행한 후에 잠금 파일을 만들 것이다.

잠금 파일을 만든다는 것은 의존성의 새로운 버전이 나오더라도 여러분은 자동으로 업데이트 받지 않는다는 것을 의미한다. 새로운 버전으로 업데이트 하려면 update 명령어를 사용한다. 그러면 매칭되는 (여러분의 composer.json 파일에 따라서) 최근 버전을 받을 것이고 새로운 버전으로 잠금파일을 갱신할 것이다.

php composer.phar update
참고: composer.lockcomposer.json 파일이 동기화되어 있지 않으면 install 명령어를 실행할 때 경고를 표시할 것이다.

만약 의존성 하나에만 설치나 업데이트를 원한다면 허용 목록에 추가할 수 있다.

php composer.phar update monolog/monolog [...]
참고: 라이브러리의 경우 잠금 파일을 반드시 커밋할 필요는 없다.
라이브러리-잠금파일 참고

패키지스트

패키지스트는 메인 컴포저 저장소이다. 컴포저 저장소는 기본적으로 패키지를 얻을 수 있는 곳인 패키지 소스이다. 패키지스트는 모두가 사용하는 중앙 저장소가 되는 것이 목표이다. 이것은 사용 가능한 어떤 패키지든 자동으로 require할 수 있다는 것을 의미한다.

패키지스트 웹사이트를 방문하면 여러분은 패키지를 둘러보고 검색할 수 있다.

컴포저를 사용하는 어떤 오픈 소스 프로젝트도 자신의 패키지를 패키지스트에 발행하는 것이 좋다. 라이브러리는 컴포저가 사용하는 패키지스트에 있을 필요는 없지만 다른 개발자들이 더 빠르게 탐색하고 도입할 수 있게 해준다.

오토로딩

컴포저는 자동으로 로드하는 정보를 지정한 라이브러리의 경우에 vendor/autoload.php 파일을 생성한다. 여러분은 간단하게 이 파일을 포함하고 자유롭게 오토로딩을 할 수 있다.

require 'vendor/autoload.php';
이 코드는 실제로 외부 코드를 사용하기 쉽게 해준다. 예를 들면 프로젝트가 모놀로그에 의존하고 있다면 여러분은 그저 클래스를 사용하면 자동으로 클래스를 불러온다.

$log = new Monolog\Logger('name');
$log->pushHandler(new Monolog\Handler\StreamHandler('app.log', Monolog\Logger::WARNING));

$log->addWarning('Foo');
여러분은 심지어 composer.json에서 autoload 항목을 추가하는 것으로 오토로더를 여러분의 코드에 추가할 수 있다.

{
    "autoload": {
        "psr-4": {"Acme\\": "src/"}
    }
}
컴포저는 Acme 네임스페이스로 PSR-4 오토로더를 등록할 것이다.

여러분은 디렉토리에서 네임스페이스 매핑을 정의한다. src 디렉토리는 여러분의 프로젝트 루트에서 vendor 디렉토리와 같은 단계가 될 것이다. 예제 파일이름은 Acme\Foo 클래스를 포함한 src/Foo.php가 될 것이다.

autoload 항목을 추가한 후에 여러분은 vendor/autoload.php 파일을 다시 생성하기 위해 dump-autoload를 재실행 해야한다.

해당 파일을 포함하는 것 또한 오토로더 인스턴스를 반환합니다, 그래서 여러분은 변수에 해당 반환값을 저장하고 네임스페이스를 더 추가할 수 있다. 예를 들어 이 예제는 테스트 프로그램에서 클래스를 자동으로 불러오는 데에 유용할 수 있다.

$loader = require 'vendor/autoload.php';
$loader->add('Acme\\Test\\', __DIR__);
PSR-4 오토로드에 추가적으로 컴포저에는 클래스 맵과 파일 오토로드인 PSR-0이 지원된다. 더 자세한 내용은 autoload 를 참조하면 된다.
참고: 컴포저는 자신의 오토로드를 제공한다. 만약 여러분이 제공하는 것을 사용하고 싶지 않다면 자신의 오토로드를 구성할 수 있도록 연관배열을 반환하는 vendor/composer/autoload_*.php 파일을 포함하면 된다.

continue reading [번역] 의존성 관리 도구 컴포저 - 기본 사용법(Basic usage)
Share This:    Facebook Twitter

2015-07-02

[번역] 의존성 관리 도구 컴포저 시작하기 - 소개(Intro)

컴포저에 대해서 소개글을 읽다보니 해석하느라 내용이 눈에 잘 안들어와서 번역 해 보았습니다. 시간 나면 다음 것도 번역해볼까 하지만, 발 번역이라 컴포저에 대한 국문 내용이 필요하신 분들께 죄송하네요. 이 글은 그냥 참고용으로만...

* url: https://getcomposer.org/doc/00-intro.md

소개s

컴포저는 PHP 의존성 관리 도구이다. 프로젝트에서 요구하는 의존 라이브러리를 선언하고 프로젝트에 설치하는 것을 도와준다.

의존성 관리

컴포저는 패키지 관리자가 아니다. 그렇다, "패키지"나 라이브러리를 다루기는 하지만 프로젝트 단위로 관리하고 프로젝트 디렉토리 (예: vendor) 안에서 설치 한다. 기본적으로 절대 전역 설치하지는 않는다. 그래서 의존성 관리자이다.

이 아이디어는 새로운 것은 아니며 컴포저는 nodejs의 npm이나 루비의 bundler에서 크게 영향을 받았다. 그러나 그 당시 PHP를 위한 도구같은 건 없었다.

컴포저는 다음과 같은 문제를 해결 해 준다.

a) 몇몇 라이브러리에 의존하는 프로젝트가 있다.
b) 어떤 라이브러리는 다른 라이브러리에 의존적이다.
c) 의존성을 선언한다.
d) 컴포저는 설치에 필요한 패키지의 버전을 찾아서 설치한다 (프로젝트에 다운 받는 것을 의미한다).

의존성 선언

프로젝트를 생성하고 로그 기록하는 라이브러리가 필요하다고 해보자. 여러분은 monolog를 사용하기로 결정했다. 프로젝트에 추가하기 위해 해야 할 일은 composer.json 파일에 프로젝트 의존성을 선언하는 것이다.

{
 "require": {
  "monolog/monolog": "1.2.*"
 }
}
우리는 프로젝트가 어떤 monolog/monolg 패키지를 요구하는지 간단하게 작성했다. 모든 버전은 1.2로 시작한다.

시스템 요구

컴포저는 PHP 5.3.2 이상이어야 동작한다. 몇몇 세심한 PHP 설정과 컴파일 표시가 필요하지만 설치 프로그램을 진행할 때 호환성에 대한 경고가 표시 된다.
간단한 zip 아카이브 대신에 소스 패키지를 설치하려면 패키지 버전 컨트롤에 따라 git, svn, hg가 필요하다.
컴포저는 멀티 플랫폼을 지원하고 우리는 윈도우, 리눅스, OSX에서 똑같이 동작하도록 노력하고 있다.

설치 - 리눅스 / 유닉스 / OSX

실행 가능 한 컴포저 다운로드

짧지만 컴포저를 설치하는데 2가지 방법이 있다. 프로젝트의 일부분으로서 지역적으로 또는 어디에서나 실행가능하도록 전역적으로 설치하는 방법이 있다.

지역 설치 (Locally)

컴포저 지역 설치는 그냥 프로젝트 디렉토리 안에서 실행하면 된다.

curl -sS https://getcomposer.org/installer | php
참고: 어떠한 이유로 실패하면 php 대신에 인스톨러를 다운받을 수 있다.

php -r "readfile('https://getcomposer.org/installer');" | php
인스톨러는 몇몇 PHP 설정을 체크하고 작업 디렉토리에 composer.phar 를 다운받을 것이다. 이 파일은 컴포저 바이너리 파일이다. PHAR (PHP 아카이브) 라고 하는데 다른 것들 사이에서 명령줄로 실행할 수 있는 PHP 아카이브 형식이다.

--install-dir 옵션을 사용하여 지정 디렉토리(절대 경로나 상대 경로일 수 있다)를 제공하는 것으로 컴포저를 특정 디렉토리에 설치할 수 있다.

curl -sS https://getcomposer.org/installer | php -- --install-dir=bin

전역 설치 (Globally)

여러분은 이 파일을 여러분이 원하는 어디에나 놓을 수 있다. 시스템 속성 PATH에 설정하면 여러분은 전역적으로 접근할 수 있다. 유닉스 시스템에서 심지어 php 없이 실행가능하게 하고 호출 할 수 있다.

여러분은 시스템 어디에나 쉽게 composer에 접근하기 위해서 이 명령어를 실행할 수 있다.

curl -sS https://getcomposer.org/installer | php
mv composer.phar /usr/local/bin/composer
참고: 권한 때문에 실패했다면 sudo 권한으로 mv 줄을 다시 실행하라.
참고: 요세미티 OSX에서 /usr 디렉토리는 기본적으로 존재하지 않는다.  "/usr/local/bin/composer: No such file or directory" 라는 에러가 나면  진행하기 전에 /usr/local/bin/ 폴더를 수동으로 생성한다.

그리고 나서 컴포저를 실행하기 위해 php phpcomposer.phar 명령 대신에 composer 명령을 실행한다.

설치 - 윈도우즈

인스톨러 이용하기

이 방법은 가장 쉽게 컴포저를 설정할 수 있는 방법이다.

Composer-Setup.exe를 다운로드 받고 실행한다. 최신 컴포저 버전을 설치하고 PATH 를 세팅하면 어느 디렉토리에서나 명령 줄로 composer 명령을 그냥 실행하는 것으로 호출할 수 있다.
참고: 현재 터미널을 닫는다. 새로운 터미널로 사용 테스트를 한다. 터미널 시작할 때 경로만 로드하기 때문에 중요하다.

수동 설치

환경변수 PATH 디렉토리를 변경하고 composer.phar를 다운 받을 수 있는 설치 조각을 실행한다.

C:\Users\username>cd C:\bin
C:\bin>php -r "readfile('https://getcomposer.org/installer');" | php
노트: 위의 readfile 때문에 실패한다면 http 주소를 사용하거나 php.ini에서 php_openssl.dll을 사용 설정 한다.

composer.phar 파일로 새 composer.bat 파일을 만든다.

C:\bin>echo @php "%~dp0composer.phar" %*>composer.bat

아직 설정되어 있지 않으면 환경변수 PATH에 디렉토리를 추가한다. 현재 터미널을 닫는다. 그리고 새 터미널을 열어서 테스트 한다.

C:\Users\username>composer -V
Composer version 27d8904


컴포저 이용하기

우리는 이제 컴포저로 프로젝트 의존성 설치할 것이다. 현재 디렉토리에 composer.json 파일이 없다면 기본 사용법 부분을 넘어가도 된다.

의존성을 해결하고 다운로드하기 위해서 install 명령어를 실행한다.

php composer.phar install
만약 전역 설치를 했고 그 디렉토리에 phar가 없다면 이 명령어를 실행하라

composer install
위의 의존성 선언 예제를 따라서 vendor/monolog/monolog 디렉토리로 monolog를 다운로드 받을 것이다.

오토로딩

라이브러리를 다운로드 받는 것 외에 컴포저는 다운로드한 라이브러리의 어떤 클래스든 자동으로 불러올 수 있는 오토로드 파일을 준비한다. 컴포저를 사용하기 위해서는 그냥 코드의 부트 스트랩 과정에 저 줄을 따라서 추가해주면 된다.

require __DIR__ . '/vendor/autoload.php';
와우! 이제 monolog를 사용할 수 있다! 컴포저에 대해서 더 배우고 싶으면 "기본 사용법" 장을 계속 읽으면 된다.

continue reading [번역] 의존성 관리 도구 컴포저 시작하기 - 소개(Intro)
Share This:    Facebook Twitter

2015-06-30

정규식 패턴: 잃어버린 텍스트을 찾아서

정규식은 위키에서는 다음과 같이 설명하고 있다.
정규 표현식(正規表現式, 영어: regular expression, 간단히 regexp 또는 regex) 또는 정규식(正規式)은 특정한 규칙을 가진 문자열의 집합을 표현하는 데 사용하는 형식 언어이다.

  다시 말해서 정규식은 특정한 규칙에 해당하는 문자열을 뽑아내는 작업이라고 설명할 수 있을 것 같다. 예를 들면 이메일 형식의 문자만 추출하거나, URL 형식의 문자만 추출하거나 또는 다른 원하는 규칙에 해당하는 문자열을 다른 문자열로 바꾸고 싶을 때도 정규식을 사용할 수 있다. 이러한 정규식은 파이썬, 자바 스크립트, PHP 등등 많은 곳에서 응용하여 사용하고 있다. 늘 상 사용하는 기능은 아니지만 꼭 필요한 순간은 예고 없이 찾아온다.
  개인적으로 정규식에 대해서 항상 어렵다는 생각을 가지고 있었다. 지금 돌이켜보면 정규식에 대한 막연한 편견이었던 것 같다. 작업을 할 때 특수 문자가 주는 어려운 이미지 때문에 직접 작성하기 보다는 다른 방법으로 우회해서 사용하거나 꼭 필요한 경우에는 예제를 찾아서 변경하여 사용했었다. 어느 것이나 그렇지만 예제를 찾는다는 것은 내게 꼭 맞는 정규식은 아니었다. 그 때 정규식에 대해서 하나하나 뜯어보기 시작했는데 마음 먹고 들여다 본 정규식은 생각보다 어렵지 않았다. 다시 공부한 걸 생각도 할 겸 나와 같은 상황에 빠진 사람들에 조금이나마 도움이 되지 않을까 해서 정리해 보았다.
기준은 PHP로 잡고 정리 했지만 큰 그림은 비슷하기 때문에 한 번 이해하면 어디에서든 쓸 수 있을 거라고 생각한다.

정규식 예제에 사용 할 범주
  • /예제로 사용한 정규식/
  • 정규식을 적용할 문자열
  • []: 정규식을 찾고난 결과 값

정규식의 기본 사용

/blah-blah/
양 쪽에 있는 슬래시(/) 안에 문자를 넣어서 사용한다. 슬래시 안의 문자들을 정규식 패턴으로 인식하고 그 안에 기술된 패턴대로 문자열을 찾기 시작한다. 예를 들어 a라는 글자를 찾고 싶으면 다음과 같이 입력하면 된다.

/a/

a ab abc

[a]
/aaa/

a ab aaa

[aaa]
기본 사용법은 익혔으니 그 안의 내용을 작성하는 방법을 알아보자. 너무 겁 먹지 않아도 된다. 신경 쓸 게 많아 보이지만 생각보다 간단하다. 이 다음부터 나오는 모든 사용법은 슬래시 안에 작성해 주어야 한다.

문장이 시작하거나 끝나는 지점

^blah : blah로 시작하는 패턴

/^start/

start begin!

[start]
전체 문장의 시작이 정확히 start라고 시작하는 패턴을 찾는다. 예를 들어 찾아야 할 텍스트가 everybody start begin!이라면 start로 시작하지 않기 때문에 규칙에 맞는 텍스트는 없을 것이다.

end$ : end로 끝나는 패턴

/end$/

The end

[end]
찾아야할 문자열 중에서 가장 마지막 문자가 end로 끝나야만 한다. 예를 들어 찾아야 할 텍스트가 The end.라면 점(.)이 있기 때문에 규칙에 맞는 텍스트는 없다.

A|B : A 또는 B

/hell|hi/

hell hi hello

[hell]
hello 또는 hi라는 문자열을 찾기 때문에 결과는 가장 처음에 나오는 hell을 찾을 것이다.

여기에서 왜 hi를 찾지 않는지 궁금할 것이다. 이 쯤 해서 플래그에 대해서 알아야 할 것 같다. 기본적으로 규칙을 작성하게 되면 가장 처음 추출되는 문자열 하나를 찾는다. 그러나 제시한 텍스트에서 규칙에 해당하는 문자열을 모두 찾고 싶다면? 그때 플래그를 넣어주면 된다.

옵션 플래그

옵션 플래그에는 여러 가지가 있다. 그러나 가장 많이 사용하는 3가지만 소개하도록 한다. 물론 여기서 소개하지 않았다고 해서 중요하지 않거나 유용하지 않은 플래그라는 것은 아니다. 플래그는 하나만 사용할 수 도 있고 다른 플래그와 조합하여 여러개를 사용할 수 있다.

g: 전체 지정

/hell|hi/g

hell hi hello

[hell, hi, hell]
g 플래그는 전체 문자열에서 작성한 규칙에 해당하는 문자열을 모두 찾아낸다. g 플래그를 붙이지 않으면 규칙에 맞는 가장 첫 번째 문자열만 찾고 책임을 다하지만 g 플래그를 붙이면 규칙에 해당하는 모든 문자열을 찾는다.

i: 대소문자 무시

/hell|hi/gi

HELL hell HI hi hello

[HELL, hell, HI, hi, hell]
대소문자 상관없이 hell에 해당하는 문자열은 모두 찾는다. 또한 g 플래그가 붙었기 때문에 대소문자 구분 없이 hell, HELL 모두 찾아낸다.

m: 여러 줄에 해당 내용을 지정

/hello$/m

HELL hell HI hi hello!
HELL hell HI hi hello
HELL hell HI hi hello

[hello]

/hello$/gm

HELL hell HI hi hello!
HELL hell HI hi hello
HELL hell HI hi hello

[hello, hello]
m의 경우에 헷갈릴 수도 있을 것 같기도 한데 각 줄에서 해당하는 규칙을 찾아낸다. 다시 말해서 ^ 또는 $ 문자는 전체 문자열의 가장 처음 또는 가장 마지막 규칙을 찾아내는데 m 플래그를 사용할 경우 각 줄에서 마지막이 hello로 끝나는 단어를 찾아낸다. 그래서 바로 위의 예제에서는 hello로 끝나는 두 번째와 세 번째 hello를 반환 한다. g 플래그를 붙이지 않은 첫 번째 예제에서는 각 줄에서 작성한 규칙에 해당하는 두 번째 줄의 hello 문자열을 찾고 끝난다.

문자 출력

지금부터는 본격적인 규칙 작성을 시작한다. 가장 많이 사용하고 또 자유자재로 작성해야 할 문자들이다. 다음에서 소개할 내용은 반드시 숙지하고 있어야 하는데 어쩌면 암기하려 노력하지 여러 번 사용하면서 자연스럽게 외워질 수도 있다.

. : 특수 문자 \n을 제외한 모든 문자 한 개

/h./g

HELL hell HI hi hello!
HELL hell HI hi hello

[he, hi, he, he, hi, he]

* : 이전 문자가 0번 이상 반복 (반복하지 않거나 1번 이상)

/d*/g

a dd ddd dddd ddddd aaaaaa

[ , ,dd, ,ddd, ,dddd, ,ddddd, ]
별표(*)가 단독으로 쓰일 경우 0번 이상 반복하는 것까지 찾기 때문에 사실상 공백까지도 결과 범위에 포함한다.

+ : 이전 문자가 1번 이상 반복

/a+/g

a dd ddd dddd ddddd aaaaaa

[a, aaaaaa]

? : 이전 문자가 존재하거나 하지 않거나

/https?/g

http:// https:// httpss://

[http, https]
물음표(?) 앞에 나오는 s가 없거나 있는 경우 모두 찾아낸다.

{n,n} : 숫자를 반드시 지정해야 하며 그 안의 수 만큼 반복

/d{3,4}/g

a dd ddd dddd ddddd aaaaaa

[ddd, dddd, dddd]
d가 3번 이상 4번 이하 반복하는 문자열을 찾기 때문에 3번 반복하는 3번째 ddd부터 5번째에 있는 dddd까지 반환한다.

문자 지정 또는 범위

해당하는 문자 지정

[] 문자열을 사용하면 []라고 감싼 부분이 하나의 문자로 인식 하고 그 안에 작성한 문자열이 해당하는 범위가 된다.

/[ac3]/g

1234
abcd

[3, a, c]
위의 예제에서 보듯 [] 안에 a, c, 3이라는 3개의 문자열이 있다. []는 해당 자리에 문자가 하나 들어간 다는 뜻인데 그 하나의 문자열이 a나 c 또는 3일 때 해당 규칙이 성립한다고 본다. (물론 g 플래그를 사용했기 때문에 해당하는 문자열을 전부 추출한다.)

- : 해당하는 문자 범위 지정

만약 이 안에 하이픈(-)으로 지정하면 범위로 정해진다. 예를 들면 [0-9]라고 지정하면 0부터 9까지의 숫자를 의미하고 [a-z]라고 하면 소문자 알파벳 a부터 z까지가 해당한다. 같은 방식으로 대문자 알파벳 범위도 지정 가능하다. 또한 범위를 결합해서 사용할 수도 있다. 다시 말해서 [0-9a-z]라고 지정하면 숫자 0부터 9까지와 a부터 z까지에 해당하는 문자열 하나를 말한다. 물론 이 상황에서 대문자는 포함하지 않는다.
결국 [0-9]는 모든 숫자를 의미하고, [a-z]는 모든 소문자 알파벳, [A-Z]는 모든 대문자 알파벳이고, 당연히 [a-zA-Z]는 모든 알파벳을 의미한다.
 
/[0-9]/g

1234
abcd

[1, 2, 3, 4]

^ : 해당하지 않는 문자 (또는 범위) 지정

물론 해당 범주에 속하지 않도록 지정하는 규칙도 있다. ^ 문자를 사용하면 되는데 범위를 설정할 때는 문자열의 시작이라는 뜻이 아니라 부정의 의미를 담고 있다. 다음의 예제로 이해하면 더 쉬울 것이다. 0-9를 부정 (^) 하는 뜻이므로 숫자가 아닌 한 문자열을 의미하는 정규식이다.

/[^0-9]/g

1234
abcd

[a, b, c, d]

자주 사용하는 특수 문자

정규식에서는 특수 문자를 표현하는 문자로 패턴을 나타내기도 한다. 그 패턴은 일반 문자열 앞에 백슬래시(\)를 붙여서 특수한 용도로 사용한다. HTML 태그를 아는 사람은 익숙한 내용일 수도 있다. 다음은 자주 사용하는 특수 문자 리스트이다.
  • \n : 새로운 줄 (줄바꿈 용도로 사용하는 엔터와 같음)
  • \t : 탭 문자
  • \b : 공백 문자 (띄어쓰기 용도로 사용하는 스페이스와 같음)
  • \d : 정수 ([0-9]와 같음)
  • \D : 정수가 아닌 문자열 ([^0-9]와 같음)
  • \s : 공백 문자 (\n, \r, \t 등등이 해당됨)

/[\d]/g

1234
abcd

[1, 2, 3, 4]
기본적으로 정규식은 문자 규칙을 작성하는 것이기 때문에 여러 문자를 조합해서 사용한다.
그러나 실제로 \b라는 문자를 찾고 싶을 수도 있다. 그때는 역슬래시(\)를 해당 문자 앞에 붙여준다. 예를 들어 \b라는 문자를 찾고 싶다면 \\b라고 입력하면 된다.

/\\b/g

\b \a \t \b

[\b, \b]

문자 그룹화: ()

찾아낸 문자를 교체한다던가 정규식에 포함되는 내용 중 특정 문자를 추출하고자 할 때는 그룹화해서 문자열을 추출한다. 만약 리스트 태그(<li>)를 추출하는데 그 중에서도 클래스 명이 name인 내용만 추출하고 싶다면 그룹화을 사용하여 작업할 수 있다.

/<li.+?class="name">(.+?)<\/li>/g

<ul>
<li class="name">파무침</li>
<li class="phone">000-0000-0000</li>
<li class="name">파절임</li>
<li class="phone">000-0000-0000</li>
</ul>

[파무침, 파절임]
PHP에서는 preg_replace 함수를 이용하여 문자열을 교체할 수도 있다. 다음은 PHP 공식 홈페이지에서 가져온 preg_replace 예제이다. 첫번째 괄호는 ${1}또는 $1로 치환되고 두번째 괄호, 세번째 괄호는 각각 ${2} 또는 $2, ${3} 또는 $3으로 치환하여 사용한다.

<?php
$string = 'April 15, 2003';
$pattern = '/(\w+) (\d+), (\d+)/i';
$replacement = '${1}1,$3';
echo preg_replace($pattern, $replacement, $string);
?>
April1,2003

탐욕스러운(Greedy), 게으른(Lazy, Non-Greedy)

  • greedy :+ * {n,}
  • lazy : +? *? {n,}?
정규식이 살아있는 사람이라면 기본적으로 욕심많은 사람이다. 그러나 때론 욕심이 많으면 일을 그르칠 수도 있기에 욕심을 자제할 때도 있어야 하는 법이다. 욕심 많은 이 사람을 자제하거나 성격을 바꿀 수 있는 마법의 도구가 있다. 차이점을 알아차린 사람도 있겠지만 탐욕스러운 패턴에서 ?를 붙이면 마음이 조금 덜 탐욕스러워진다. 쉽게 설명하기 위해 가장 처음 요소인 <html>을 추출하려고 하는 아래의 예시를 같이 보도록 하자.
/<.*>/

<html><head><title>제목</title></head>

[<html><head><title>제목</title></head>]
모든 문자가 없거나 반복되는 내용으로 <>로 닫히는 태그를 찾고 있다. 그러나 출력되는 결과는 예상과는 다르다. 괄호로 닫히는 것은 맞지만 우리가 원했던 것은 <html>코드였지만 마지막 >까지 모두 추출해버렸다. 이 탐욕스러운 정규식!

이제 이 탐욕스러운 마음을 조금 진정하도록 도와주자. 다음과 같이 물음표를 붙이면 된다.

/<.*?>/

<html><head><title>제목</title></head>

[<html>]
함께 살펴본 2가지의 예시와 같이 물음표 하나로 정규식의 마음을 쥐락펴락할 수 있다. 이 마법의 문자를 기억하고 황에 따라 조절하며 사용하기 바란다.

예제

이제 대부분의 정규식에 대해서 공부 해 봤으니 실제 예시를 통해서 정규식을 사용해 보도록 하자. 가장 기본적인 전화번호 추출 방식부터 생각해보자.

전화번호(휴대폰 번호)

쉬운 예시를 위해 국제 번호는 제외한 휴대폰 번호만 추출하도록 하자. 전화번호의 경우에는 다음과 같은 패턴을 가지고 있다. 각 자리에는 당연히 숫자만 허용할 수 있고 각 국번 사이에는 하이픈(-)으로 연결되어 있기에 숫자와 정확한 곳에 자리 잡은 하이픈이 필요하다. 그 내용은 다음과 같이 정리할 수 있다.
{숫자 3자리}-{숫자 3자리 또는 4자리}-{숫자 4자리}
요새는 많이 사용 하지 않지만 가운데 국번이 3자리인 휴대폰 번호도 존재한다. 최대한 모든 휴대폰 번호를 수용할 수 있는 패턴을 만들어야 오류 발생율이 적어지기 때문에 3자리도 같이 패턴으로 처리하도록 하자. 이러한 생각을 바탕으로 정규식은 다음과 같이 설계할 수 있다.
/[0-9]{3}-[0-9]{3, 4}-[0-9]{4}/g

010-0000-0000
010-1234-1234

[010-0000-0000, 010-1234-1234]

주소 (URL)

인터넷 주소의 경우에는 전화번호보다는 조금 더 복잡하다. 우선, 한글 도메인은 예시에서 제외하도록 하자. 실제로 한글 도메인이 존재하기 때문에 실 개발할 때 URL을 영문으로만 한정짓는 것은 현명하지 못한 선택일 수도 있다. 그러나 설명을 위한 예시이므로 무시하는 것으로 한다.
URL 주소의 경우에는 워낙 종류도 많고 설정할 수 있는 규칙도 다양하기 때문에 이 내용이 정답이라고 할 수는 없다. {프로토콜}{주소}로 이루어져 있으며 그 중에서 프로토콜의 경우에는 http:// 또는 https:// 로 시작할 수도 있다. 이 부분만 정규식으로 표현한다면 다음과 같다. 슬러시(/) 문자는 정규식에서 사용하는 문자이기 때문에 역슬래시(\)를 작성하지 않으면 오류가 난다.
https?:\/\/
s 문자가 있을 수도 있고 없을 수도 있기 때문에 물음표를 입력하여 표현하였다. 주소 부분은 점(.)이나 하이픈(-) 그리고 문자열로 이루어져 있다. 이 내용은 다음과 같이 표현할 수 있다.
[0-9a-z.-]+
이 두 개의 정규식을 이어서 완성해 보면 다음과 같다.

/https?:\/\/[0-9a-z.-]+\/?/g

https://test010.com/
http://test010.co.kr/
https://test010.kr

[https://test010.com/, http://test010.co.kr/, https://test010.kr]
더 정확하게 표현하고 싶다면 이렇게 할 수도 있다.

/https?:\/\/([0-9a-z.-]+).[a-z]\/?/g

https://test010.com/
http://test010.co.kr/
https://test010.kr

[https://test010.com/, http://test010.co.kr/, https://test010.kr]

마무리

어느 것이든 다 마찬가지지만 실제 해당 기술 자체 보다는 그 기술을 어떻게 응용하고 이용하느냐에 따라서 달라진다. 어쩌면 문자열을 추출하는 작업을 할 때 정규식이 아니라 다른 방식 (substr 함수를 사용한다던가 if문으로 분기로 처리한다던가) 으로 처리하는 것이 훨씬 나을 때가 있다. 그러나 분명 정규식을 사용했을 때 더 편리하거나 정확한 경우가 있다고 믿고 있다. 많은 방법을 알고 있을 수록 작업을 할 때 더 효율적으로 선택할 수 있을 것이다.
모든 정규식을 외울 필요는 없지만 어느 정도 기본적인 지식이 있다면 정규식 검증 사이트에서 테스트를 해볼 수도 있다. 개인적으로 regex101이라는 사이트에서 많은 도움을 받았으나 정규식을 검증해주는 사이트는 얼마든지 많이 있다.


참고:
  • https://ko.wikipedia.org/wiki/%EC%A0%95%EA%B7%9C_%ED%91%9C%ED%98%84%EC%8B%9D
  • https://wikidocs.net/1642
  • http://php.net/manual/en/function.preg-replace.php
  • https://regex101.com/
continue reading 정규식 패턴: 잃어버린 텍스트을 찾아서
Share This:    Facebook Twitter

2015-03-31

phpdocument, 우리의 코드를 예쁘게 포장하는 방법


2015년 1/4분기 미니 프로젝트 

* 혼자 공부하려고 만든 자료이기 때문에 정확하지 않는 내용이나 오류가 있을 수 있습니다. 잘못된 점은 언제든지 고쳐주시면 배우겠습니다.

phpDocumentor란? 

phpDocumentor는 제작한 프로젝트에 대해서 문서화 해주는 도구를 말한다. 공식 홈페이지에서는 'PHP에 대한 세계 표준 자동 문서 도구(phpDocumentor is the world standard auto-documentation tool for PHP.)'라고 설명하고 있다. 
우선은 phpDocumentor가 왜 수면위로 떠오르게 되었는지에 대해서 짚고 넘어가야 할 것 같다. PHP는 본래 컴파일 없이 라인 단위로 처리하는 스크립트 언어이다. 아무래도 스크립트 언어는 라인별 처리라는 개념 덕분인지 진입장벽이 낮아 독학하기에 좋은 언어였다. 그로 인해 사용률이 많아지고 인기가 많아지는 동시에 스크립트 언어에 대한 약점에 대해서 생각하게 되었던 것 같다. PHP 5로 넘어가면서 본격적으로 객체에 대한 개념이 강화되고, 이를 이용한 다양한 프레임워크가 개발되고 있다. 스크립트 언어에 대한 약점을 컴파일 언어에서 그 해답을 찾고자 했던 것 같다. 
컴파일 언어의 대표적인 사례인 JAVA에서는 이미 javadoc이라는 문서화 도구가 존재하고 있었다. 아마도 phpDocumentor는 javadoc의 php 버전이었으리라. 사용 방법도 javadoc과 크게 다르지 않다. php도 객체지향 개념이 나오면서 어떤 정형화된 패턴이 나오는 것이 가정해졌기 때문에 그 공통적인 부분을 문서를 만들 수 있게 되었다.

주석

주석은 자신을 포함하여 프로젝트에 참여하는 사람들에게 쉽게 알아볼 수 있도록 하는 역할을 해준다. 주석을 최소화하는 것을 장려하는 사람들도 있긴 하지만, 프로젝트가 커질 수록 작은 코드가 어떤 역할을 할 수 있는지 모를 수도 있다. 그때 작업자는 그 코드에 대해서 설명글을 달아줄 수 있다. 주석은 사람이 알아볼 수 있게 쓰는 일종이 메모의 역할을 한다.

마무리 

phpDocumentor로 대단한 것을 할 수 있는 것은 아니다. 어쩌면 이 도구로 할 수 있는 것은 자료보관일 뿐일 것이다. 
사실 Phpdoc이 많은 곳에서 쓰이고 있지는 않다. 대부분의 개발자들은 코드를 보면 쉽게 알 수 있을 것이라고 말하거나 귀찮아 한다. 그만큼 손도 많이 가고 굳이 해야 하나 싶기도 하는 작업이 바로 이 작업이다. 프로젝트가 개발자에 종속되는 것은 매우 좋지 않은 현상이며, 많은 개발자들이 수긍할 수 있는 코드가 좋은 프로젝트라고 생각한다. 그들이 쉽게 프로젝트의 유지보수에 투입되려면 한눈에 정리되어있는 문서가 필요한데 문서의 유지보수는 생각보다 어렵다. 그래서 이 도구가 문서를 작성하는 데에 중요한 역할을 하는 것이다. 

continue reading phpdocument, 우리의 코드를 예쁘게 포장하는 방법
Share This:    Facebook Twitter