このエントリーをはてなブックマークに追加

はじめに

こんにちは、@ttskch です。今日はちょっとした小ネタで、以下のツイートの焼き直し記事です :hand:

伝えたい内容はこのツイートでほぼすべて言い終わっているのでこの記事を書く意義はかなり謎ですが(笑)、一応細かいところを軽く補足しつつ記事の体裁にしてみようと思いますので、よろしければ最後までお付き合いください :joy:

※ GitHubを使っていることを前提とした内容になっていますのでご了承ください :pray:

WIP-PR駆動開発とは

WIP-PR駆動開発とは、開発の最初にWIP(Work In Progress:進行中)な状態からPull Requestを作ってしまって、そこにどんどんコミットを追加しながら開発を進めていく開発スタイルのことです。

開発の途中経過がGitHub上で可視化されるため、チームで開発している場合の情報の透明化に一役買ってくれます。もちろん一人での開発にも使えます。

WIP-PR駆動開発のやり方

基本的には以下のような流れで行います。

  1. ローカルでmasterから開発用のトピックブランチを切る
  2. そのブランチに git commit -m "[ci skip] wip" --allow-empty などのようにして空のコミットを追加
  3. とりあえずこの空のコミットをGitHubにpush
  4. GitHub上でmasterへのPull Requestを作成
  5. ローカルで開発を開始(最初のコミットは git commit --amend で空コミットと結合する)

「まだ何も開発してない状態でPRを作って、それから開発を始める」というのがポイントですね。

※ 空コミットのコミットメッセージに書いた [ci skip] はCircleCIやTravis CIなどのCIサービスでビルドをスキップさせるためのキーワードです(参考: CircleCI / Travis CI

めんどくさい

やってみると分かりますが、ブランチを切る度に空コミットを作ってpushしてGitHubのWeb UIでPull Requestを作って、という作業はまあまあめんどくさいです :dash:

そこで、一連の作業をシェルスクリプトで自動化してしまいましょうというのがこの記事の主旨です :muscle:

hubコマンド

シェルスクリプトを書く前に、お使いのマシンに hub というコマンドをインストールしておいてください。これは、GitHubの操作をコマンドラインで行うためのGitHub公式のCLIツールです。

https://hub.github.com/

このコマンドを使ってシェルスクリプトからPRを作成します。

hubコマンドには色々な機能がありますが、hub browse で今いるプロジェクトのGitHubリポジトリをブラウザで開いてくれる機能だけでもめちゃ便利なので、WIP-PRしない人もとりあえずhubコマンドは入れておくことをお勧めします。

hubコマンドの利用にはGitHubの認証が必要

hubコマンドを使うためには、当然ながらGitHubの認証が必要です。

ユーザー名とパスワードでも認証できますが、2FAを設定している場合は毎回2FAトークンの入力が必要になってしまうので、GitHub上でPersonal Access Tokenを発行して設定ファイルに記入しておくのがお勧めです。

https://github.com/settings/tokensGenerate new token というボタンからトークンを作成できます。スコープは repo だけでOKです。

作ったAccess Tokenを ~/.config/hub というテキストファイルに以下のようにユーザー名と合わせてセットしておけば、それ以降特に意識せずに認証ができます :ok_hand:

github.com:
- user: user_name
  oauth_token: xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

gitのサブコマンドは自作できる

ところで、gitコマンドのサブコマンドは簡単に自作できるということをご存知でしたでしょうか。

やり方はとても簡単で、 git-hoge といったファイル名の実行ファイル(シェルスクリプトなど)をパスの通ったディレクトリに置いておくだけです。こうしておくと、 git hoge のようにハイフンなしでそのコマンドを実行できます。

というわけで、今回はシェルスクリプトを git wippr というgitのサブコマンドとして実行できるようにしてみます。

実際のシェルスクリプトの内容と使い方

では、いよいよ実際のシェルスクリプトの中身です。(最初のツイートでネタバレしてますが笑)

#!/bin/sh

# 第1引数の文字列をブランチ名としてブランチを切る
git checkout -b $1

# 空コミット
git commit -m "[ci skip] wip" --allow-empty

# push
git push -u origin $1

# hubコマンドを使って、第2引数の文字列をタイトルとしてPRを作り、作られたPRをGoogle Chromeで開く
# ※ macOSでGoogle Chromeがインストールされている場合の例です
hub pull-request -m $2 | xargs open -a "Google Chrome"

これを /usr/local/bin/git-wippr に保存して、以下のようにして実行可能なパーミッションを設定すれば完了です :ok_hand:

$ chmod u+x /usr/local/bin/git-wippr

使い方も見たまんまで、masterブランチにいる状態で

$ git wippr branch-name "PRのタイトル"

という感じで実行すれば、 branch-name という名前でブランチが切られて、そのブランチからmasterへのPRが PRのタイトル というタイトルで作成され、Google Chromeで自動的にPRの画面が開かれます。

なんて便利なんでしょう :tada:

番外編

シェルスクリプトの中に

# hubコマンドを使って、第2引数の文字列をタイトルとしてPRを作り、作られたPRをGoogle Chromeで開く
# ※ macOSでGoogle Chromeがインストールされている場合の例です
hub pull-request -m $2 | xargs open -a "Google Chrome"

という箇所がありましたが、この方法だとリポジトリに PRのテンプレート がセットされている場合にもそれは適用されずにdescriptionが空のPRが作成されてしまいます。

これを回避する代替案として、上記の箇所を以下のように書き換えることもできます。

# hubコマンドを使って、標準のブラウザでGitHubのPR作成画面を開く
hub compare

この場合、git wippr コマンド実行時にPRのタイトルまで決めてしまうことはできなくなりますが、その代わりに、PRテンプレートが反映されたdescriptionが入力された状態のPR作成画面が開かれます。(PRのタイトルも、作成画面であとから入力することになります)

個人的には最近は個人開発でしかWIP-PRを使っておらずPRテンプレートとかほとんど使ってないので先述の方法をご紹介しましたが、チーム開発メインでPRテンプレートを多用する方は、こちらの方法のほうが便利かもしれません。

コマンド名を変えて2つとも作っておいて使い分けるという手もありますね。

おわりに

というわけで、140文字で書けることを長々と記事にしてお送りしました(笑)

ご自身の好みに合わせてカスタマイズしたりしつつ、ご活用いただければ幸いです :raised_hands:


このエントリーをはてなブックマークに追加

こんにちは。下田です。

Symfonyで開発していると必ず触ることになる、services.ymlについて。
最近ですが、このservices.ymlに記述するだけで実現できてしまう機能が意外とたくさんあることを知りました。
今回はそれらの機能について、どんなものがあるのか調べてみました。

(以下、Symfony4.2での記述です)

services.ymlでできること

インジェクションいろいろ

まずは基本、 あるオブジェクトを他のオブジェクトに注入したい時に書く方法です。

コンストラクタインジェクション

基本形の argumentsです。
コンストラクタ引数の変数名をkey、実際に渡すオブジェクトをvalueに書きます。

services:
    App\Service\MessageGenerator:
        arguments:
            $logger: '@monolog.logger.request'

セッターインジェクション

コンストラクタではなく、setterメソッドを使ってオブジェクトを注入する時のyamlの書き方です。
callsを使うと任意のsetterを呼ぶことができます。
(※実際、setterではなくとも任意の関数をcallできるようです。用途がぱっと思いつきませんが:thinking:

services:
    App\Service\MessageGenerator:
        calls:
            - method: setLogger
              arguments:
                  - '@logger'

省略形で以下のようにも書くことができます。

services:
    App\Service\MessageGenerator:
        calls:
            - [setLogger, ['@logger']]

参考:https://symfony.com/doc/current/service_container/calls.html

また引数に@?を使うと、 注入したいオブジェクトがcontainerにない場合は無視する という書き方もできます。

services:
    App\Service\MessageGenerator:
        calls:
            - [setLogger, ['@?logger']]

上記の例では、 @loggerのインスタンスが存在しない場合はそもそも setLogger()がcallされません。

参考:https://symfony.com/doc/current/service_container/optional_dependencies.html#ignoring-missing-dependencies

@?でオプショナルにできる機能はついさっき先輩に教えてもらいました。多謝:pray:

タグによる自動注入

symfonyの開発を進めていると tags: ['twig.extension'] とか tags: [{name: form.type }] などなど、tags:を書くことがあるかと思います。

あれは特定タグのつけられたオブジェクトたちを、まとめて別のオブジェクトに注入する働きがあります。

(例えば、tags:['form.type']を付けられたものは、ここらへんでまとめて注入処理をしているようです)
参考:https://symfony.com/doc/current/service_container/tags.html

また、symfonyに最初から用意されているタグ以外にも、オリジナルのタグを作って好きなオブジェクトにまとめて注入することもできます!

services:
  app_sample.foo:
    class: App\Sample\SampleFoo

  app_sample.bar:
    class: App\Sample\SampleBar

  # ...

  App\SampleResolver:
    class: App\SampleResolver
    calls:
      - ["addSample", ["@app_sample.foo"]]
      - ["addSample", ["@app_sample.bar"]]
      - ["addSample", ["@app_sample.baz"]]
      - ["addSample", ["@app_sample.foo2"]]
      - ["addSample", ["@app_sample.foo3"]]
      # ...
      - ["addSample", ["@app_sample.foo100"]]

これが

# config/services.yaml
services:
  app_sample.foo:
    class: App\Sample\SampleFoo
    tags:
      - "myapp.sample"

  app_sample.bar:
    class: App\Sample\SampleBar
    tags:
      - "myapp.sample"

  # ...

  App\SampleResolver:
    class: App\SampleResolver
    # 大量のcallsが減ってスッキリ!

こう書けます。

具体的な方法は弊社記事に詳しい説明があります。
前述のcalls:をたくさん書かなければいけない場面に遭遇したときなどにオススメです :smiley:

遅延読み込み

実際にはめったに使われないのに、他のインスタンスの初期化に必要なため毎回インスタンス化しなければならず、しかもインスタンス化すると重くて困るようなオブジェクトやサービス(例えば、処理失敗の時だけ必要なloggerや、外部APIクライアント等)に遭遇したことはありませんか?

そういったオブジェクトには lazy: trueを付けることで、そのオブジェクトが実際に必要になるまでインスタンス化を遅らせることができます。

依存関係が複雑になってくるとインスタンスの生成順序なども問題になってきますが、そんな時でもlazy:オプションで実際のインスタンス生成を後回しにすることで解決できるかも知れません。
参考:https://symfony.com/doc/current/service_container/lazy_services.html

Factoryパターン

あるクラスを直接インスタンス化せず、ファクトリを利用してオブジェクトを生成したいときがあります。(同種のインスタンスがたくさん必要なときや、インスタンス生成手順に複雑な処理が必要なときなど)

そんなときはファクトリクラスを作ると思うのですが、services.ymlでもファクトリクラス名とメソッド名を記述することで、ファクトリを使ったインスタンス生成を利用できます。 factory: を使います。

例えばこんな感じでファクトリクラスを作った場合、

class NewsletterManagerStaticFactory
{
    public static function createNewsletterManager()
    {
        $newsletterManager = new NewsletterManager();
        // ...
        return $newsletterManager;
    }
}

services.ymlの記述はこんな形になります。 keyに生成したいクラス名を書き、生成に使うファクトリクラス名とメソッド名を factory:に記述します。

services:
    App\Email\NewsletterManager:
        factory: 'App\Email\NewsletterManagerFactory:createNewsletterManager'
        # 配列でも書けるが、古い書き方
        # factory: ['App\Email\NewsletterManagerStaticFactory', createNewsletterManager]

上記はファクトリメソッドがstaticの場合ですが、そうでない場合でもファクトリクラス自体を先にインスタンス化しておけば普通に使えます。

services:
    # 先にファクトリをインスタンス化して、サービス登録しておく
    App\Email\NewsletterManagerFactory: ~

    App\Email\NewsletterManager:
        factory: 'App\Email\NewsletterManagerFactory:createNewsletterManager'

参考:https://symfony.com/doc/current/service_container/factories.html

まとめ

以上、個人的に便利でスゴい!と思ったものや、実際に使っているものを羅列してみました。
services.ymlの記述を工夫するだけで実現できてしまうことが思いの外多くて驚きでした。

また今回、それらの機能について調べることで、背後にある有用な設計パターンについてもたくさん知ることができました。
設計の引き出しをたくさん増やしておけば、「何だかうまくいかないな…」と思った時でも、ひらめきが生まれるかもしれません :bulb:

今回紹介した機能は公式のサービスコンテナのドキュメントにまとまっていますので、皆様も是非services.ymlについて調べてみて下さい!
https://symfony.com/doc/current/service_container.html#learn-more


このエントリーをはてなブックマークに追加

2019/03/29〜3日間に渡って行われている PHPerKaigi 2019 にて、「設計力を上げる!バリエーションの見極め術」を発表しました。

https://speakerdeck.com/77web/she-ji-li-woshang-geru-bariesiyonfalsejian-ji-meshu

日々コードレビューや同僚との設計相談をしている中で、私が着目しているif〜else〜で良いときとダメなときの見極め方をうまく説明したいなぁ、と思っていたことをまとめたものです。
発表中に「なぜこれが良い例なのか、詳細は去年の後藤さんのトークのスライドを見てください」とご紹介したスライドは PHPerKaigi 2018 ベストトーク賞「SOLIDの原則ってどんなふうに使うの?」スライド公開・配布 にあります。 TrackAが満席になり、立って聞いてくださった方もいて、本当にありがとうございました!

イベントはあと1日あるので、いろいろなトークを聞いて、普段めったに会えない関東や他地方のエンジニアとも話して、目一杯楽しんで帰りたいと思います。
会場で見かけた際はお気軽に声をかけてください。