herokuでサブディレクトリをデプロイする

まえおき

herokuを使いたいなーと思って調べています。

herokuにデプロイするときに、 build-pack というものを使用します。
これは、デプロイされるアプリケーションの言語などを自動で推定してくれるやつです。これを設定しないとデプロイできません。

我々はphperなので、 heroku/php というものを使うのですが、公式ドキュメントにあるように、トップディレクトリに composer.json または index.php が必要になります。

Heroku PHP Support will be applied to applications only when the application has a file named composer.json in the root directory. Even if an application has no Composer dependencies, it must include an empty composer.json in order to be recognized as a PHP application.

が、僕はルートディレクトリは

という構成でやってるので、ルートディレクトリに composer.json がなくてデプロイできませんでした。
個人的にこの構成は気に入っているし、わざわざデプロイのためにディレクトリ構成を変更するのもおかしな話です。

解決策

調べてみると、subdir-heroku-buildpackというものを使うと、サブディレクトリのみをデプロイできるようです。

herokuの設定値に PROJECT_PATH という変数を設定し、このbuild-packを heroku/php の前にかましてあげるだけでデプロイできるようになります。

余談

上記のように簡単に設定できるはずだったのですが、私はかなりつまづきました。
というのも、 PROJECT_PATH を設定してるにもかかわらず、 PROJECT_PATH is undefined と怒られるんです。

結局のところ、pushしているブランチが違っていて、 PROJECT_PATH で指定しているディレクトリが見つからないのが原因でした。

エラーメッセージと原因が違うってどうなのよ??となったので、Forkして、ちゃんとエラーメッセージが出る版を作りました。

github.com

よければ使ってやってください。

composerで特定のリビジョンのパッケージを取得する

こちらがわかりやすいです。

akamist.com

なるほどなー!

"{vendor}/{package}" : "dev-{branch}#{hash}"

って書けばええんやな!やったろ!

"laravel/socialite": "dev-3.0#79316f3"

実行!

> composer update laravel/socialite
Loading composer repositories with package information
Updating dependencies (including require-dev)
Your requirements could not be resolved to an installable set of packages.   

あれっいかない!
となったわけです。

ドキュメントにちゃんと書いてありました。

When branch names look like versions, we have to clarify for composer that we're trying to check out a branch and not a tag. In the above example, we have two version branches: v1 and v2. To get Composer to check out one of these branches, you must specify a version constraint that looks like this: v1.x-dev. The .x is an arbitrary string that Composer requires to tell it that we're talking about the v1 branch and not a v1 tag (alternatively, you can name the branch v1.x instead of v1). In the case of a branch with a version-like name (v1, in this case), you append -dev as a suffix, rather than using dev- as a prefix.

getcomposer.org

つまるところ、「ブランチ名がバージョン名っぽい感じのときは最後に .x-devってつけてね」とのこと。

こちらが正解でした。

"laravel/socialite": "3.0.x-dev#79316f3"

hyper + powershellで文字に色が付かないとき

hyper + powershellで文字に色が付かずに ?[39m などと出てしまう現象に遭遇しました。

とりあえず私は以下の方法で対処できたので、記しておきます。

  1. hyperを3系に上げましょう。

    githubから落とせます。

  2. Windowsのバージョンを 1809 まで上げましょう。

    windows version 1809

以上です。

参考:

github.com

Laravel JP Conferenceに行ってきました

タイトルのとおりです。

2/16日にLaravel JP Conferenceに行ってきました。
今回はPHPカンファレンス仙台2019に引き続き、Speaker+Sponsor+Staffのスリーエスで参加しました。

スポンサーとして

スポンサーとしては実質あまり動いてなく、カンファレンスが動きやすいように会社に締め切りつっついたり、会社がアピールしやすいようにカンファレンスに働きかけたりしてました。
二重スパイみたいなもんですね。

スピーカーとして

今回は人生初のレギュラートークをしてきました。
内容は「ServiceProvider, ServiceContainer入門」です。

自分でもしっかりと理解できていない部分があったので、発表の準備をする際にしっかり調査をしました。
そこでDIの色々な説明を見たのですが、その多くがDIとDIコンテナをまとめて説明していたり、DIと型システム(インターフェースや継承など)を混同しているなと感じました。
そこで、今回の発表ではそれらの構成要素をバラして説明することで、サービスコンテナをより深く、よりわかりやすくしようというコンセプトをとりました。
いちおうTwitterの反響では特にマサカリもなかったので、成功だったのかなーという印象です。

ちょっとスライドを準備する時期が遅くなってしまい、前日に発表練習をしてみたのですが、発表練習をすると色々な学びがありました。

スクリーンショット 2019-02-20 16.47.22.png (109.3 kB)

「初めて発表するぞ!」という人は、いちど発表練習をしてみることをおすすめします。
自分の発表を客観的に見れて、学びが深いです。

スタッフとして

コアスタッフとして参加してきました。
個人的にドタバタしていてあまりコミットできず、申し訳ないです。。。
あまり主体的に動けなかったので、そこは課題です。

当日もセッションとワークショップに追われてほぼスタッフ業をできなかったので、事前準備や撤収でちょっとだけ頑張らせていただきました。

今思い返すと、熱量高いチームですごい良かったなぁ・・・という感じです。
熱量あれば何とかなる!みんなもスタッフやろう!

ワークショップスタッフとして

エンジニアの登壇を応援する会にてワークショップをやらせていただきました。
コンテンツの準備などは他のメンバーにお任せして、自分は機材レンタルなどの裏方をやってました。
メンバーが優秀で、かなり周到に用意ができたので、大きな問題もなく進んだなーという感じです。

開催を終えて

スクリーンショット 2019-02-20 17.06.08.png (318.4 kB)

色々な人からフォローされました! でも、あんま技術的なお話してないねんな・・・

スクリーンショット 2019-02-20 17.07.41.png (268.8 kB)

来年の開催は決まってないので、ここらへんの話が気になるところです。

PHPでエラーと呼ばれているものまとめ

PHPでエラーと呼ばれているものをまとめてみました。

誰が見てもエラーとわかるもの

Error

<?php
try {
    $a = $b / $c;
} catch (DivisionByZeroError $e) {
    $a = 0;
}

PHP7から導入されたError
オブジェクトとして扱えて、try, catchできます。
便利ですね。

エラー

Fatal error: Call to undefined method Controller::index() in Controller.php on line 6

PHP5おなじみのこれ。
良い子は @error_reporting(0); を使ってはいけませんよ。

Fatal errorParse error のみをエラーと呼ぶ流派もいるそうです。

エラーか微妙なライン

エラー例外

<?php
function exception_error_handler($severity, $message, $file, $line) {
    throw new ErrorException($message, 0, $severity, $file, $line);
}
set_error_handler("exception_error_handler");

自作フレームワークを作ったことがある人なら誰もがとおるアレ

これをエラーと識別するか例外と識別するかは意見が分かれるところ。

できればエラーと呼ばないでほしい

例外

<?php
try {
    $model->save();
} catch(Exception $e) {
    // 握りつぶしてやる!
}

例外はエラーじゃないのよ!   例外とエラーの違いについては色んな記事があるから読んでみるといいかも。

SPL例外みんなもっと使っていきましょ。

Throwable

例外とErrorのインターフェースがThrowableです。
エラーを含んでいますが、エラーじゃないものも含んでいるのです。

思ってたのと違う

trueが返るはずですがfalseが返ってきました。エラーです。

それはエラーじゃない!ただのバグ!

真っ白い画面

何も表示されないんです。エラーです。

たぶんエラーでてると思うけど、レスポンス返してないだけかも。
とりあえずエラーログ出てないか見てみるのと、 display_errorserror_reporting確認してみよ?

Laravel+Codeceptionのメリット

私は普段、Laravel+Codeceptionを利用してテストを書いています。
今回はLaravel+Codeceptionのメリットとちょっとした小技を紹介します。

Codeceptionとは

CodeceptionPHPのテスティングフレームワークです。
単体テスト・機能テスト・受け入れテストを書けます。
多くのフレームワークをサポートしているのが特徴です。

LaravelでCodeceptionを使用するメリット

Laravelにはテスト機能がついています。
特にLaravel5.4からはLaravel Duskがあるので、Codeceptionの機能をすべてカバーしています。
なので、基本的にはわざわざCodeceptionを利用するメリットはありません。
それでもCodeceptionを利用するメリットとしては、以下のようなものがあります。

特定のフレームワークに縛られない

Laravelのテスト機能を使用してテストを書くと、Laravelから他のフレームワークに乗り換えづらくなります。
Codeceptionを利用する場合は、フレームワークを乗り換えてもテストのロジックはそのまま移行できます。

テスティングフレームワークを統一できる

チーム内で使用しているフレームワークが複数ある場合、それぞれのフレームワークのテスト機能を使用してテストを書くと学習コストが高く付きます。
フレームワークのテスト機能を使用せずにCodeceptionで統一すると学習コストを低く抑えられます。

CodeceptionでLaravel5Moduleを使用するメリット

Codeceptionはそれだけで十分にテストを書くことができますが、Laravel5Moduleを使用することでLaravelの機能を利用してテストを書くことができます。

環境ファイルを使用できる

.env.testing という環境ファイルを作成することで、テスト時にデータベースの接続設定などの環境変数を変更することができます。

DB機能を使用できる

テスト実行時に自動でマイグレーションを実行できたり、自動でDatabaseSeederをもとにデータを投入できます。
テスト前にトランザクションを張って、データを変更させないようにもできます。

EloquentModelを使用できる

データベーステストをする際に、 $I->seeRecord(Article::class, ['title' => 'test']) のようにEloquentのモデルを指定することができます。

ルーティングを使用できる

現在のURLをテストする際には

<?php
$I->seeCurrentPageIs("articles/{$article->id}/show")

のように書きますが、代わりに

<?php
$I->seeCurrentRouteIs('articles.show', $article)

のように書けます。 結構シンプルに書けるようになるのでオススメです。

小技:FactoryMuffinを使用しない

Fakerを利用してテストデータを生成したい場合、Codeceptionの公式ドキュメントでは、FactoryMuffinを使用するように書いてあります。
が、以下の理由からあまり使いやすくありません。

  • PHPDocTagの不足でIDEで補完できない
  • FactoryMuffinの定義の中でEloquentを使用できない

LaravelにはすでにFakerを使用してデータを作成する方法が存在するので、FactoryMuffinを使用せずに以下のようなヘルパーを書いて使っています。

<?php
    /**
     * {@inheritdoc}
     *
     * @return \Illuminate\Database\Eloquent\Model
     * @throws \InvalidArgumentException
     */
    public function have($name, $extraAttrs = [])
    {
        return factory($name)->create($extraAttrs);
    }

    /**
     * {@inheritdoc}
     *
     * @return \Illuminate\Support\Collection|\Illuminate\Database\Eloquent\Model[]
     * @throws \InvalidArgumentException
     */
    public function haveMultiple($name, $times, $extraAttrs = [])
    {
        return factory($name, $times)->create($extraAttrs);
    }

よく使うgit操作まとめ

JetBrainsのIDEにはgitとのインテグレーションツールが入っていますが、「gitはコマンドで叩いている」という人が多いようです。 自分の振り返りも兼ねて、よく使うgit操作をまとめてみます。
なお、私は普段はPhpStormを使用しているので、スクリーンショットはPhpStormの画面になります。

コミット

変更がある状態でCommand+Kを押すと、コミット画面になります。 なお、JetBrainsのgitインテグレーションでは、 ステージ の概念はありません。

スクリーンショット 2018-12-01 15.11.21.png (123.1 kB)

  • ① コミットするファイルを選択します。
  • ②コミットメッセージを入力します。右上の時計マークを押すと、過去のコミットメッセージを参照できます。
  • ③変更を確認できます。

    チェックボックスを外すと、その箇所の変更はコミットされません。
    また、ここから直接ファイルを編集することもできます。

  • ④コミット前に静的なチェックを行うことができます。

プッシュ

コミットがある状態でCommand+Shift+Kを押すと、プッシュ画面になります。

スクリーンショット 2018-12-01 21.09.00.png (42.4 kB)

左がプッシュされるコミット、右側がプッシュされるファイルです。

ログ

Command+9を押すと、ログ画面が表示されます。

スクリーンショット 2018-12-01 21.49.46.png (67.0 kB)

左がコミットログ、右が選択したコミットの変更です。
この画面では、コミットを右クリックすることで、色々な操作をできます。

  • コミットハッシュのコピー
  • リセット
  • チェリーピック
  • リビジョンにチェックアウト
  • 新しいブランチの作成
  • 新しいタグの作成
  • リバート
  • インタラクティブリベース(後述)

ブランチ

VCSメニューから Branches を選択すると、ブランチの一覧を表示できます。

スクリーンショット 2018-12-01 22.16.06.png (17.3 kB)

カーソルを合わせることで、色々な操作をできます。

  • カレントブランチの変更
  • ブランチの削除
  • リベース
  • マージ

スタッシュ/アンスタッシュ

VCSメニューから Stash Changes..., UnStash Changes... を選択すると、スタッシュ、アンスタッシュができます。 スタッシュした内容はスタックできます。

インタラクティブリベース

ログ画面からコミットを選び、 Intaractivily Rebase from Here を選択することで、インタラクティブリベースができます。

スクリーンショット 2018-12-01 22.25.12.png (21.5 kB)

内容は見た目がコマンドでリベースするときと一緒です。
右側にある▲▼でコミットの順番を入れ替えられます。

ヒストリー

右クリックで Git -> Show History で、開いているファイルのコミットの履歴を見ることができます。

スクリーンショット 2018-12-01 22.34.27.png (91.9 kB)

また、コードを範囲選択した状態で、右クリックで Git -> Show History from Selection で、選択している部分のみのコミットの履歴を見ることができます。

スクリーンショット 2018-12-01 22.38.02.png (55.7 kB)

おわりに

まとめてみると、結構色々な機能を普段から使ってることに気づかされました。 gitをGUIで使えると、オプションなどをいちいち覚えなくても問題ないのがいいですよね。 また、diffを高機能なdiff画面で見られるのもポイントです。

まだgitの機能を使ったことがない人は、ぜひ使ってみてください!