IDE로 Laravel을 개발할 경우 자동완성 및 goto 기능을 지원해주는 패키지다. 파사드와 Eloquent 매직 메서드 때문에 IDE가 타입을 못 잡는 문제를 해결해준다.왜 필요한가Laravel은 편의성을 위해 PHP의 동적 기능을 적극적으로 쓴다. 문제는 IDE가 정적 분석으로 타입을 추론하는데, 이런 코드는 분석이 안 된다는 점이다.파사드 — Auth::user() 는 실제로 __callStatic으로 뒤에서 인스턴스에 위임한다. IDE는 Auth 클래스에 user()가 없다고 본다Eloquent 매직 메서드 — User::where() 는 모델이 아니라 쿼리 빌더의 메서드다모델 속성 — $user->email 은 DB 컬럼이라 클래스에 프로퍼티 선언이 없다매크로 — 런타임에 등록되는 메서드ID..
# Ubuntu 16.04 / PHP 7.2 설치 (아마존 AWS EC2 생성 직후 PHP 설치하기) # GIT 주소GIT : https://github.com/yousung/ubuntu16.04-php7.2-install # 사용방법 wget https://raw.githubusercontent.com/yousung/ubuntu16.04-php7.2-install/master/script/install-php7.2.sh adduser user-id usermod -G www-data user-id id user-id // uid=xxx(user-id) gid=xxx(user-id) groups=xxx(user-id),xx(www-data) sudo -s bash install-php7.2.sh user..
Laravel로 개발할 때 가장 먼저 까는 패키지를 하나만 고르라면 나는 Laravel Debugbar를 고른다. 에러 페이지, 뷰, 세션, 쿠키, 실행된 쿼리까지 한 화면에서 볼 수 있다. 특히 중복 쿼리를 잡을 때 많이 쓴다.설치composer require barryvdh/laravel-debugbar --dev--dev를 반드시 붙인다. 개발 의존성으로 설치해야 운영 배포 시 composer install --no-dev 에서 빠진다.# .envAPP_DEBUG=trueDEBUGBAR_ENABLED=trueLaravel 5.5 이상은 패키지 자동 등록(auto-discovery)이 되므로 config/app.php에 프로바이더를 수동으로 추가할 필요가 없다. APP_DEBUG=true 면 자동으로..
개발자 중에서 SEO가 뭔지도 모르는 사람도 많고, 왜 자기가 만든 사이트가 검색 엔진에 노출이 안 되는지도 모르는 사람이 많다. 설사 그 이유를 알더라도 SEO의 복잡성과 생각해야 할 게 많아서 힘들어하는 분들도 많다.여기서는 Laravel에서 SEO를 쉽게 적용시키는 패키지를 소개한다.설치composer require artesaos/seotoolsLaravel 5.5부터는 패키지 자동 등록이 되므로 config/app.php 수정 없이 바로 쓸 수 있다. 수동 등록이 필요한 구버전이라면 아래처럼 넣는다.// config/app.php'providers' => [ Artesaos\SEOTools\Providers\SEOToolsServiceProvider::class,],'aliases' => [..
개발하면서 ERD를 안 그리거나 잘못 그려서 뻘짓하는 경우가 많다. 테이블을 다 만들고 나서 관계가 잘못됐다는 걸 알면 마이그레이션을 다시 짜야 하고, 이미 데이터가 쌓였다면 일이 훨씬 커진다.유료 툴이 좋긴 하지만, 무료 중에서도 설치 없이 웹에서 쓸 만한 것들이 있다.Aquery Toolhttp://aquerytool.com/국산 웹 ERD 도구다. 직관적인 UI라 따로 설명이 필요 없을 정도다. 잘 모르겠으면 좌측 상단 메뉴의 Help와 Demo를 참고하면 된다.설치 없이 브라우저에서 바로 사용한글 UI, 한글 주석 지원이 자연스럽다테이블 정의서를 엑셀로 내보낼 수 있다개인 무료 플랜 제공국내 SI 환경에서 산출물로 테이블 정의서를 요구하는 경우가 많은데, 그 포맷을 바로 뽑을 수 있다는 게 실무에..
자주 쓰면서 많이 틀리는 HTTP/응답코드 (상태코드) 리스트 일부 개발자들 중에 상태에 상관없이 모든 응답을 200 으로 응답처리하거나, 혹은 정상처리는 200 나머지 에러는 모두 500 으로 처리하는 바람에 FE 개발자와 BE 개발자가 신경전을 하기도 한다고 들은적이 있습니다. 사실 아직 기준점이 없긴 하지만 그래도 모두가 납득이 되는 범위 안에서 응답코드를 작성하는 버릇을 가지는 것이 좋은 것 같습니다. 혼자 개발을 하든 협업을 하든 적어도 200, 400, 500 3분류 이상은 나누는 것이 좋습니다. [ 성공 ] 200 - ok // 성공 201 - create // 새로운 리소스 생성 204 - no content // 리소스 삭제 성공 304 - not modified // 클라의 캐시된 리소..