Laravel elixir version 기능이 제대로 작동하지 않는 경우

몇 주만에 라라벨로 만든 애플리케이션을 수정하려고 했는데, gulp 명령어를 실행하니 에러가 났습니다.

SyntaxError in plugin 'run-sequence(version)'
Message:
Unexpected token s in JSON at position 41
Stack:
SyntaxError: Unexpected token s in JSON at position 41
at Object.parse (native)
at VersionTask.deleteManifestFiles (/home/vagrant/Code/bookcafe100.com/node_modules/laravel-elixir/dist/tasks/VersionTask.js:113:29)
at VersionTask.gulpTask (/home/vagrant/Code/bookcafe100.com/node_modules/laravel-elixir/dist/tasks/VersionTask.js:71:18)
at VersionTask.run (/home/vagrant/Code/bookcafe100.com/node_modules/laravel-elixir/dist/tasks/Task.js:138:31)
at Gulp.<anonymous> (/home/vagrant/Code/bookcafe100.com/node_modules/laravel-elixir/dist/tasks/GulpBuilder.js:65:67)
at module.exports (/home/vagrant/Code/bookcafe100.com/node_modules/orchestrator/lib/runTask.js:34:7)
at Gulp.Orchestrator._runTask (/home/vagrant/Code/bookcafe100.com/node_modules/orchestrator/index.js:273:3)
at Gulp.Orchestrator._runStep (/home/vagrant/Code/bookcafe100.com/node_modules/orchestrator/index.js:214:10)
at Gulp.Orchestrator.start (/home/vagrant/Code/bookcafe100.com/node_modules/orchestrator/index.js:134:8)
at runNextSet (/home/vagrant/Code/bookcafe100.com/node_modules/run-sequence/index.js:86:16)

한참 삽질하다가 Elixir version is messing up 라는 글에서 ‘public/build/rev-manifest.json 파일이 아래와 같이 되어 있기 때문이라는 걸 알았습니다.

{
"js/app.js": "js/app-e81f312e80.js"
}s"
}

아직까지 rev-manifest.json 파일이 왜 저리 되었는지 원인은 못찾아냈습니다만, 문제를 유발하는 s” } 를 지우니 빌드가 됐습니다. 아오 답답해서 혼났네요.

 

leaderboard-728x90

 

XECON 2016 발표 평가가 나왔어요!

생각했던 것보다 후하게 평해주셨어요! 감사합니다. 🙂
기대했던 것보다 잘나왔으니까 공유 ㅋ

발표 평가 요약

 

# 만족도
– 매우 만족 : 51.4%
– 이정도면 괜찮네요 : 37.8%
– 좋지도 나쁘지도 않았어요 : 10.8%
– 실망했어요 : 0.0%

 

# 이해도
– 이해하기 쉬웠어요 : 61.3%
– 이정도면 괜찮네요 : 32.3%
– 조금 어려웠어요 : 6.5%
– 너무 어려웠어요 : 0.0%

 

# 강의에 대한 의견
– 강의 재미 있었습니다
– 간결하고 이해가 쏙쏙 됐다
– 후배 개발자들에게 좋은 길라잡이가 될 수 있겠다
– 사례로 이해하기 쉽게 설명해주셔서 감사합니다
– 재밌었습니다.
– 지금까지 개발업에 종사하면서 생각해보지 못한 내용들도 있었고 다시 한번 상기시킬수도 있었습니다. 매우 유용했음
– 재미있게 스토리 구성해서 잘 설명하셨어요
– 공감이 되네요
– 더 깔끔하게 정리했으면 좋지 않았을까 합니다
– 제목과 적절한 내용이었습니다
– 재미있게 들었습니다. 신입분들한테 알려주고 싶은 재미있는 슬라이드였습니다

 

– 좋습니다. 사실 PHP 언어 자체의 정보를 기대하긴 했지만 나쁘지 않네요.
– 기대했던 만큼 재미있고 유용했습니다. 재치있는 강의 감사합니다. 아쉬운 점은 슬라이드 오탈자 검사를 하고 강의에 오르셨으면 하는 점이 있습니다.
– 이해하기 쉽고 재밌어요. 중간중간 자료는 좋은데 비속어는 필터링 해줬으면 좋겠어요
– 발표 자료가 아쉬웠습니다

다음에 혹시 또 발표 기회를 얻게 된다면 발표자료에도 더 신경쓰도록 하겠습니다!

XECON 2016 에서 발표한 자료 공유

감사하게도 작년에 이어 올해도 XECON에서 발표를 하게 되었습니다.

꽤 많은 분들이 들으러 와주셔서 감사했습니다. 모쪼록 제가 고민했던 내용들이 조금이라도 도움이 되셨길 바랍니다.

발표 직전까지 자료를 수정하느라 아마도 주최측이 제공한 자료랑은 내용이 조금 다를거에요.

주원님께서 찍어주신 사진도 기록으로 함께 남겨봅니다.

%e1%84%92%e1%85%a7%e1%86%ab%e1%84%89%e1%85%a5%e1%86%a8%e1%84%82%e1%85%b5%e1%86%b7-%e1%84%87%e1%85%a1%e1%86%af%e1%84%91%e1%85%ad

%e1%84%86%e1%85%a1%e1%86%ab%e1%84%89%e1%85%a5%e1%86%a8

깨진 링크 수정 완료

링크가 어떤식으로 깨졌는지 확인해보니 본문 데이터에 addslashes() 가 적용된 것 같았다.
stripslashes()를 적용해서 다시 적용하는 스크립트를 짜서 복구 성공.
그래도 빨리 문제가 해결되서 다행 다행~

라라벨은 시맨틱 버저닝을 사용하지 않는다

최근에 라라벨 책을 저술하신 두 저자분 께서 라라벨이 마이너 업데이트 되었는데 예제 소스코드가 정상적으로 작동하지 않아서 고생하신 것을 본 적이 있습니다. 이와 관련하여 정광섭님이해할 수 없는 라라벨의 릴리스 관리 정책 이란 글을 올리기도 하셨고, 또 김주원님도 관련하여 비판을 하셔서 다른 사람들은 어떻게 생각하나 좀 찾아봤습니다. 여러 사람들이 라라벨 제작자에게 시맨틱 버저닝을 사용하는지 물어보기도 하고, 또 왜 안쓰냐고 따지기도 했던거 같습니다. 이에 대해 아래 보시는 것과 같이 라라벨 제작자인 테일러 오트웰이 직접 라라벨은 시맨틱 버저닝 대신 독자적인 버저닝 시스템을 가지고 있다고 답변하는 걸 발견했습니다.

컴포저(Composer)가 시맨틱 버저닝을 사용하기 때문에, 라라벨도 당연히 시맨틱 버저닝을 사용할거라 생각했는데 의외네요.

스크린샷 2016-06-05 오전 2.55.32

위의 대화 이전에 라라벨 5.0을 발표하기 전에 시맨틱 버저닝을 도입하는 것에 대해 의견을 물은 것 같더군요. 여튼, 시맨틱 버저닝을 사용하지 않고 독자적인 버저닝 시스템을 사용하기로 한 것 같습니다.

스크린샷 2016-06-05 오전 2.57.55

See guzzles discussion on this 라고 해서 찾아봤는데, 이게 맞나 모르겠습니다. 이 링크에서 확인되는 Guzzle 의 버저닝 규칙은 다음과 같습니다.

Essentially, the current versioning scheme works like this

현재(글이 쓰여진 시점인 2013년) 버저닝 제도는 이렇게 작동합니다

 

: For a given version number X.Y.Z,

버전 넘버 X.Y.Z 에서

 

X represents fundamental or paradigm changes to the project,

X 는 프로젝트에 근본적이거나 패러다임의 변화가 있음을 나타냅니다.

 

Y represents major changes or feature additions (possibly including backwards-incompatible changes), and

Y 는 주된 변화나 기능 추가(하위 호환성이 지켜지지 않는 변화를 포함할 수 있음)를 나타내고,

 

Z represents minor changes and fixes that are backwards-compatible.

Z 는 하위 호환성이 보장되는 미미한 변화나 버그 수정을 나타냅니다.

라라벨이 Guzzle 과 같은 버저닝 규칙을 따른다면, 라라벨에서의 Y 는 SemVer 의 X 인 셈입니다. Y 가 변경된 경우, 시맨틱 버저닝일거라고 생각하고 안심하고 업데이트 하다가는 애플리케이션이 갑자기 돌아가지 않는 황당한 경험을 하실 수 있으니 유의하세요.

[참고]

시맨틱 버저닝에 대해 궁금하신 분은 Semantic Versioning 소개 나 공식 문서(한글)를 읽어보세요.

leaderboard-728x90

팀장들이 꼽은 신입 PHP 개발자가 가급적 빨리 알았으면 하는 것들

 

신입에게 권해주는 책이 있다면 그 책에는 어떤 내용이 포함되었으면 좋겠는지 8분의 팀장급 개발자분들께 여쭤보았습니다.

6명 중복 대답

  • Composer
  • PSR

5명 중복 대답

  • HTTP
  • 시큐어 코딩

4명 중복 대답

  • IDE
  • 코딩컨벤션

3명 중복 대답

  • 비즈니스에 대한 이해
  • PDO
  • MVC 패턴(최소한 로직과 표현 분리)
  • Namespaces
  • 인코딩
  • Traits
  • SPL
  • register globals 끄기
  • 매직메소드
  • 경고 메시지를 무시하지 말기

 

leaderboard-728x90

 

인수테스트 중 랜덤하게 발생하는 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