인수테스트 중 랜덤하게 발생하는 403 에러의 원인은 낡은 Xdebug 였다

Codeception 으로 인수테스트를 씐나게 돌리다가 보니, 방금 전에 잘 통과되던 테스트가 갑자기 통과가 안되는 현상이 발생했다. 에러 메시지는 too many open files 였다. ulimit 을 이용하여 열 수 있는 파일의 수를 늘렸는데, 이번에는 랜덤하게 403 응답이 나오는 현상이 발생했다.

찾아보니 Xdebug의 버그가 원인이었으며, 현재는 버그가 수정되었다고 한다. 하지만 MAMP가 사용하는 Xdebug가 버그 패치 이전 버전이기 때문에 이를 업데이트 해줘야 한다. MAMP의 Xdebug를 업데이트 하니 403 에러가 랜덤하게 발생하는 문제 뿐만 아니라 too many open files 문제까지 해결되었다(ulimit 으로 다시 열 수 있는 파일 수를 줄인 후 테스트를 돌려봤는데 문제 없이 작동했다.).

 

<참고자료>

  1. “Too many files open” on Mac OSX after running apache in PHP with XDebug for some time
  2. [SOLVED] Update XDebug in MAMP to work with Netbeans (Mac OS X)

 

leaderboard-728x90

 

XECON 2015 Learning Laravel 발표자료

최근에 좋은 튜토리얼들이 쏟아져나와서 학습 전략이라는 말이 다소 무색해지긴 했지만 그래도 궁금해하시는 분들이 계실 수 있을 것 같아 발표자료를 공유해봅니다.

[slideshare id=55119398&doc=learninglaravel-151115013004-lva1-app6892]

 

leaderboard-728x90

테스트하기 어려운 코드라는 6가지 신호

최근에 의존성 주입을 알게되어서 (신나서?) 마구마구 의존성을 주입하다보니 한 클래스를 생성하는데에 너무 많은 의존성을 주입하는 경우가 생기더군요. 가장 많은 건 13개까지… 그래서 과연 내가 잘하고 있는 것이 맞나 싶어 궁금해하고 있었는데, 오랜만에 들춰본 Laravel Testing Decoded 에서 명쾌하게 ‘아니다’ 라고 얘기해주고 있네요. 참고가 되실까 싶어 책의 내용을 일부 공유해봅니다.

테스트하기 여려운 코드라는 6가지 신호

  1. New Operators
    • 클래스 내부에서 다른 클래스를 생성하는 경우.
  2. Control-Freak Constructors
    • 생성자에서 의존성 주입 역할 이외에 다른 행위을 하는 경우.
  3. And, And, And
    • 클래스가 단일책임원칙을 지키지 않는 경우.
  4. Too Many Paths? Polymorphism to the Rescue!
    • switch 문이 있다면 더 작은 클래스들로 쪼개는 편이 테스트하기 쉬워진다.
  5. Too Many Dependencies
    • 의존성이 너무 많은 경우.(4개 이상이면 리팩토링이 필요하다고 합니다)
  6. Too Many Bugs

책에 다음과 같은 구절도 있으니, 앞으로는 어떻게 하면 의존성과 파라미터 사용을 줄일 수 있을지도 더 생각하면서 코딩해 버릇해야 겠습니다.

“Each time that you remove a dependency or parameter, you’re improving the code.”

JeffreyWay. ‘Laravel Testing Decoded.’

 

leaderboard-728x90

 

ORM 좋네요 좋아

Eloquent ORM을 이용하여 아래의 데이터를 조회하기 위한 코드를 작성했습니다.

  • A가 가진 모든 B들과
  • 그 B들이 가진 모든 C들 중 A와 관련 있는 것만 추린 것들과
  • 그 C들이 가진 모든 D들

그 결과 아래와 같은 코드가 나왔어요. ORM에 익숙한 분들은 이게 뭐? 하시겠지만 저는 굉장히 놀랬습니다 하하. 새삼 ORM에 더 익숙해지면 정말 편리해지겠구나 하는 생각이 드네요.

 

$a = A::find($id);

$a->load([
    'b',
    'b.c' => function($query) use ($a)
        {
            $query->where('a_id', $a->id);
        },
    'b.c.d'
]);

return $a;

 

+
‘b’, 가 없어도 똑같이 동작하네요!

 

leaderboard-728x90

 

대중가요는 앞으로 더욱 찾기 힘들어질것이다

대중가요가 있긴 한가 라는 글을 읽고 든 생각을 적어본다.

대중가요는 대중매체의 결과물이다. 요즘 이 분이 말하는 대중가요가 없는건 더이상 대중매체의 시대가 아니기 때문일 뿐인거다. 지금은 예전과 달리 모든 사람이 지상파 3사만 보고 살지 않는다. 채널은 수십 수백개로 늘었고, 본방사수 할 필요도 없다. 이제 사람들은 원하는 것을 원하는 시간에 골라서 본다. 앞으로 사람들은 더 다양한 매체를 비동시적으로 이용하게 될것이다. 더이상 대중가요는 기대하지 않는게 맞다.

그리고, 아직도 음반 판매량을 운운하는건 시대에 한참 뒤쳐진 의견으로 보인다. 음악시장이 줄어든게 아니라 음반시장이 줄어들었을 뿐이다. 음반은 음악을 전달하는 방법의 일종일 뿐이다. 아무도 워크맨과 시디피를 들고 다니지 않고, 전축으로 음악 듣는 사람도 극히 적은데 왠 음반 판매량 타령인가 싶다.

MyISAM을 쓰면 좋은 경우

스토리지 엔진 선택
– 로그 고속기록에는 MyISAM 에 이름과 시간이 있는 컬럼을 만들어서 기록하는 것이 유리.
– 읽기 전용 테이블에는 MyISAM 이 절대적으로 빠르다.
– 트랜잭션에는 InnoDB 추천

MySQL 퍼포먼스 향상 (1) 아키텍처 중 발췌

1.INSERT 와 SELECT 구문을 주로 사용하는 경우
2.ROLLBACK 트랜잭션을 사용하지 않는 경우
3.테이블을 대규모로 동시에 읽고 쓰지 않는 경우
4.InnoDB 가 제공하는 특별 기능을 사용하지 않는 경우
5.FULLTEXT 인덱스를 사용하는 경우
6.공간적인 컬럼 타입을 사용하는 경우

이런 경우에 MyISAM이 좋습니다.

MyISAM과 InnoDB가 어떻게 다른가요? 중 발췌

하… 로그 데이터베이스는 MyISAM이 더 좋겠군요. InnoDB로 되어있는데 ㅠ
leaderboard-728x90

 

git 사용시 커밋하지 않은 변경사항들을 다른 브랜치에 커밋하기

오늘 한참 작업을 하고 나서 보니, master 브랜치에서 작업을 하고 있었더군요. 뜨어! 지금까지 작업한 내용을 다른 브랜치(제 경우에는 develop 브랜치)에 커밋할 순 없나 찾아보니 다행히 방법이 있었습니다. stash를 사용하는 방법입니다.

git stash // 커밋하지 않은 변경사항을 임시로 저장한다.
git checkout develop // develop 브랜치로 변경한다.
git stash pop // 임시로 저장한 변경사항을 복원한다.

도움을 얻은 글은 How to commit my current changes to a different branch in git [duplicate] 입니다.
stash에 대한 더 자세한 사항은 Git 도구 – Stashing 에 잘 안내되어 있으니 참고하세요.
 

leaderboard-728x90

 

Laravel 마이그레이션 작성시 index 존재 여부 확인하는 방법

Laravel에 테이블이나 컬럼이 존재하는지 확인하는 메소드는 있는데 index 존재 여부를 확인하는 메소드는 지원하지 않아서 다소 아쉬운 면이 있었습니다. 찾아보니 doctrine schema manager 를 사용하면 확인이 가능하더군요. Laravel로 마이그레이션 작성해보신 분들은 아래 예제 코드 보시면 바로 이해가 되실거에요. 아마 doctrine/dbal 패키지를 설치가 필요할 거에요.(확인해보진 않았습니다 ^^ 어차피 renameColumn 하려면 필요하니까 걍 설치 고고)

Schema::table('articles', function($table)
{
    $conn = Schema::getConnection();
    $dbSchemaManager = $conn->getDoctrineSchemaManager();
    $doctrineTable = $dbSchemaManager->listTableDetails('articles');

    if($doctrineTable->hasIndex('title')){
        $table->dropIndex('title');
    }
});

 

leaderboard-728x90

 

Laravel 컨트롤러 테스트 작성 요령

테스트를 작성할 때 무엇을 테스트 할 것인지를 결정하는 것이 참 어려운 것 같습니다. Jeffrey Way 의 조언을 따르니 컨트롤러 테스트 작성에 꽤 도움이 되네요.

“Controller tests should verify responses, ensure that the correct database access methods are triggered, and assert that the appropriate instance variables are sent to the view.”

다음에서 발췌: JeffreyWay. ‘Laravel Testing Decoded.’ iBooks.

  1.  response 를 확인한다.
    1. $this->assertResponseIsOk() 혹은 $this->assertRedirectedTo(‘/PATH’) 등으로 확인할 수 있습니다.
  2. 원하는 모델의 메소드가 작동되었는지 확인한다.
    1. Mockery 의 shouldReceive 로 확인할 수 있습니다.
  3. 뷰에 데이터를 잘 넘겼는지 확인한다.
    1. $this->assertViewHas(‘변수명’) 으로 확인할 수 있습니다.

leaderboard-728x90