PHPStorm で PHP_CodeSniffer をかける #phpstorm

はじめに

開発環境は Docker を利用しており、最初は Docker 上の php を利用して連携しようと思っていた。

実際に連携自体はできるのだが、ホストマシンのスペックの問題なのか、避けられない遅延なのか、Inspection が走るたびに指摘事項が一瞬消えてまたつくという状態になってしまった。

なかなかにストレスフルだったので、結局ローカルの php と連携させることにした。

なおローカルで連携させるなら composer 経由のほうが楽だと思うが、 composer 周りまでローカルで用意するのは避けたかったため利用していない。

PHPStorm は 2020.3.2 を利用。

PHP_CodeSniffer を設定

設定自体は Quality Tools からできる。

f:id:su-kun1899:20210228211354p:plain

Local はたぶん最初から入っているが、 Docker 上のものを使いたいなら事前に CLI Interpreter を設定しておく必要がある(設定しないと選択肢に出てきてくれない)。

Path をフルパスで設定する。うまく認識していれば validate 押下後に成功メッセージが表示される。

f:id:su-kun1899:20210228211451p:plain

phpcbf も利用するなら合わせて設定する。

timeout は Docker 連携の場合引っかかる可能性があるので、30~60秒くらいにしておいたほうがいいが、ローカルなら 5 秒でも問題なさそう。

ちなみに Xdebug を利用していると validate 時に下記のようなエラーメッセージが出る場合がある。

Xdebug: [Step Debug] Could not connect to debugging client. Tried: host.docker.internal:9003 (through xdebug.client_host/xdebug.client_port) :-(

これは PHPStorm 側で Xdebug の Listen を切っている場合に起きてしまう警告なのだが、 phpcs のためだけに常に Listen しておいたり xdebug の有効無効を切り替えるのが微妙だったのもローカルに振り切った理由のひとつ(開発用の環境だと大抵 Xdebug 使うので)。

Inspection を設定

PHP_CodeSniffer validation を有効化する。

f:id:su-kun1899:20210228211626p:plain

自前の設定を利用するには Coding Standard を Custom にする。

ruleset を絶対パスで設定する。

f:id:su-kun1899:20210228211830p:plain

Docker 連携の場合はリモート側のパスで設定する。

これで PHPStorm 上で Inspection が効くようになる。

参考

pleiades.io

「THE MODEL」を読んだ

以前勤めていた職場の同僚に勧められて、てっきりエンジニアリングの本かと思ったら、セールスとかマーケティングとかの本だったという。

エンジニアリングとは少しテーマが違うけど、セールスフォースやマルケトの話が元になっているので、ITサービスに関わっている人なら興味深く読めると思う。

自社の営業組織がどうなってるかとは別に、自分のような非営業職が読むと、ひとつ共通言語を持てて協業がはかどりそうだなと思った。

いわゆるITサービスの営業というものを、そもそも深く知ろうとしたことすらなかったことにも気付かされた。

  • 自社の営業組織やプロセスとの違いはどこにあるだろう
  • 開発組織やプロセスとの違いはどこにあるだろう
  • 開発組織やプロセスと似ているところはどこにあるだろう

上記のようなことを考えてみると色々と学びがある。

分業による効率化とキャリアパスは Web 開発の考え方とはマッチしなそうだなーと思うけど、仕事が労働集約にならないようにとか、協力する(せざるを得ない)ような目標設定する、みたいなところはどんな職種でもそうだよなー、とか。

顧客中心、みたいなのはプロダクト開発っぽいよね。 数字は大事だけど、数字そのものよりそこから何を読み取るかとか、数字だけで評価しちゃだめとか。

具体的な How もたくさん扱っているし、採用やマネジメント、評価にも言及しているのでだいぶお得感のある内容でした。

たぶん自分からは読まなかっただろう本なので、勧めてくれた人に感謝。

Developers Summit 2021に行ってきた #devsumi

デブサミに参加してきた。 行ってきた、といってもオンライン開催だけど。

event.shoeisha.jp

なんとなく感じたこと

聴講したセッションやタイムテーブルを見てると、なんとなく「プロダクトマネジメント」と「EdTech」がトレンドなのかな―という気がした。

EdTech は保守的な教育業界に対して、コロナがある意味強制的な追い風になった側面もありそう。

プロダクトマネジメントの課題は共感を覚えつつ、言葉や役割に解決策を求めるようなケースが増えないでほしいと思うばかり。

オンライン開催について

オンライン開催だけど、スムーズに参加できた。

運営の方々の努力の賜物ですね、素晴らしい。

終日開催のオンラインイベントは多分初参加だったんだけど、自宅でリラックスしながらだとテレビを見ている感じになるw

強いて言えば大体オンライン開催ってチャットが付いてるけど、 SNS と賑わいが分散しちゃう気がしていて、それはちょっともったいないなと思わないこともない。

あと顔出し必須っぽかったのでセッション合間のイベントスペースは行かなかったんだけど、どんな感じだったのかな。

その他雑多な感想

  • DACI という意思決定フレームワークがあるらしい。
    • 面白そうだなと思いつつ、いまいち解決したい課題がどのへんにあるのかあんまりしっくり来ていない
    • 意思決定が遅延しがちな大企業とかだと実感しやすいのかな?
  • atama plus はかなりいい感じにプロダクト開発・組織づくりをしていそう
    • 楽しそうでもあった
  • Quipper の発表はサービス開発してるぞって感じでよかった。
  • 楽しみにしてた Zenn の発表も面白かったので満足
  • デブサミは参加者が幅広いのでセッションがガチャになりがち
    • 初日は(自分が)ターゲット層じゃないなぁ〜っていうのが多かった
    • そういう意味だと二日目は当たりが多くて楽しかった
  • 例のごとく翔泳社がセールをやっているので程々に散財しました

www.shoeisha.co.jp

www.atlassian.com

note.com

認証付きリクエストをテストする #cakephp

環境

  • CakePHP 4.2.1
  • cakephp/authentication 2.5.0
  • 認証はセッション方式

概要

認証付きエンドポイントを何もせずにテストすると、(未ログインで)302転送されてしまう。

セッションに偽の認証情報を入れることで、認証を通り抜けてテストできる。

やり方

公式ドキュメントにある通り。

テスト - 4.x

IntegrationTestTrait を使って、セッションに偽の認証情報を格納しておくだけ。

class FooControllerTest extends TestCase
{
    use IntegrationTestTrait;

    public function testSomething()
    {
        // セッションに偽の認証情報を格納
        $this->session(
            [
                'Auth' => [
                    'User' => [
                        'id' => 1,
                        'username' => 'testing',
                    ]
                ]
            ]
        );

        $this->get('/hoge');
        $this->assertResponseOk();
    }
}

Session を直接確認する

じゃあなんでこれで動くのかと思って、画面からログインして Controller 側で Session を直接確認すると、確かに Auth がキーで入っている。

class FooController extends AppController
{
    public function hoge()
    {
      // key を指定せずに取得
      $this->request->getSession()->read();
      // key を指定して取得
      $this->request->getSession()->read('Auth');

      // ...do something
    }
}

どこで入れている?

そしてどこで入れているのかというと SessionAuthenticator ( \Authentication\Authenticator\SessionAuthenticator::persistIdentity )でやってる。

authentication/SessionAuthenticator.php at 2.5.0 · cakephp/authentication · GitHub

デフォルトだと、 sessionKey が Auth になっているので、その Key で格納されているということだった。

protected $_defaultConfig = [
    'fields' => [
        IdentifierInterface::CREDENTIAL_USERNAME => 'username',
    ],
    'sessionKey' => 'Auth',
    'identify' => false,
    'identityAttribute' => 'identity',
];

「「1日30分」を続けなさい!」を読んだ

「朝30分」を続けなさい!

「朝30分」を続けなさい!

柴田さんのブログで紹介されていたこともあり、2冊合わせて読んでみた。

自分への投資:継続した学習:柴田 芳樹 (Yoshiki Shibata):SSブログ

※柴田さんのブログのポストも本が出たのもかなり前ではある。

自分もそれなりに社会人として働いてきて、習慣の力や継続の大切さは身にしみているので筆者の主張には同意もするし共感もするところもあった。

ただ本の内容としては、ひたすら上から目線の「だからお前はだめなんだ」といった感じがひたすら続く。

「これが自己啓発本ってやつか。。」という感想を持ち、僕には合わないなと思うのであった。

ただ前述の通り、主張には同意できるので、やっぱり継続して頑張っていかんとな、という気持ちにはなった。

GitHub プロフィールを作る

概要

気になってた、GitHub のプロフィールカードを作ってみた。

出来上がりはこんな感じ。

f:id:su-kun1899:20210111225645p:plain

作り方

Managing your profile README - GitHub Docs

ここに載ってる。

ユーザー名と同じ名前で public リポジトリを作ると、 README に書いた内容が自分のプロフィールに反映されるようになる。

Activity を画像にして載せる

github.com

github-profile-summary-cards を使うと、よく使ってる言語とかを画像でビジュアライズして載せられる。

Add to my profile README · vn7n24fzkq/github-profile-summary-cards Wiki · GitHub

手順は Wiki にある。

workflows を作って、 GitHub Actions で実行すると画像が生成されるので、出来上がったファイルを README.md で読み込ませれば良い。

ちなみに定期実行になっているので、先々の活動も勝手に反映してくれそう。

private リポジトリの内容も反映させる

Includes commits and top language stats for private repos. · Issue #5 · vn7n24fzkq/github-profile-summary-cards · GitHub

private リポジトリの内容も読み込ませる方法は上記 Issue から辿れる。

Personal Access Token を発行後、それを yml で使うようにして再実行すればOK。

必要な権限についても Issue で言及されている。

参考

simple-minds-think-alike.hatenablog.com

リモート環境下におけるスクラムイベントのちょっとした工夫 #リモートワーク #scrum #スクラム

これは コネヒト Advent Calendar 2020 5日目 の記事です。

はじめに

コロナの影響もあり、現在は在宅勤務が中心になっています。

コネヒトの開発チームはスクラムを採用していますが、スクラムイベントもリモートで行うようになりました。

この記事ではリモート環境のスクラムイベントを効果的にするために僕らが行っている工夫をいくつか紹介しようと思います。

デイリースクラム

工夫: スピーカーのバトンパス

デイリースクラムは順々に話していく形式が多いと思います。

オフラインであれば並んでる順に自然と話せばいいですが、ビデオ会議だとイマイチスピーカーの順番が定まりません。

またオフラインに比べて、「話し終わったのかどうか」を意外と察しづらい問題があります。

とても小さな工夫なのですが、話終わったあとに次の人にパスを渡します。

「次は○○さん、お願いします」

自分の話が終わったら、これを言うだけでスムーズに進行していきます。

f:id:su-kun1899:20201205230801p:plain

スプリントレビュー

工夫: 自由参加にする

オンラインのビデオ会議のいいところは、場所の物理的な制約を受けないところです。

会議室に入れる人数は限界がありますし、オープンスペースであってもデモが遠くだと見えづらかったりもするでしょう。

僕らはレビューの開始前に、全社員がいる Slack チャンネルでアナウンスし、 Zoom のリンクを共有しています。

f:id:su-kun1899:20201205230637p:plain
お知らせの様子

スプリントレトロスペクティブ

工夫: チェックイン

オンラインのビデオ会議は、良くも悪くも複数人が同時多発的に会話するようなコミュニケーションには向いていないと思います。

そのためレトロスペクティブのような場では、ひとりひとりの発言機会やその時間がオフラインに比べて短くなりがちです。

そこで僕らはレトロスペクティブの最初にチェックインを行っています。

簡単な質問をひとつ用意し、それに対して全員がひとことずつ回答します。

  • このスプリントを天気で表すと?
  • このスプリントは前のスプリントに比べてよかった?悪かった?
  • このスプリントで一番がんばったことは?
  • etc

最初に全員が一度発言することで、参加意識が高まっていきます。

チェックインの詳細については「アジャイルレトロスペクティブズ」という書籍で紹介されています。

バックログリファインメント

工夫: 司会は開発者

これはリモートに限ったことではないですが、リファインメントの司会は開発者(の代表者)が行っています。

以前はプロダクトオーナーがバックログアイテムを説明することが中心でした。

プロダクトバックログについては当然プロダクトオーナーの方が詳しいですが、司会進行をある意味「詳しくない側」である開発者が行うことで、不明点や懸念点を顕在化しやすくしています。

スプリントプランニング

工夫: 一度解散、そして集合

開発チームは機能横断で構成されていますが、メンバーの中では当然専門領域が異なります。

そのためプランニングでは大枠のスプリントゴールを確認したあと、大きく2つのチーム( Native アプリチームと Web チーム )に分かれて細かいタスク出しや見積もりを行っています。

ただそのままだと作業の優先順位や完了目処の認識がずれたりする可能性があります。
(このAPIは早めにほしい、など)

そのため、両チームの見通しが判明したら、改めて最終的な認識合わせとスプリントゴールの調整を行うようにしています。

おわりに

コネヒトの開発チームで行っている、スクラムイベントの工夫をいくつか紹介させていただきました。

スクラムはチームの状況により細部のやり方が大きく変化するものだと思います。

この記事で紹介した工夫が、少しでも誰かのヒントになれば幸いです。

明日は nkuroda さんです。

qiita.com

(追記) イベントやります!

コネヒトでは12/17にオンラインイベント開催予定なので、ぜひ参加してみてください!

connehito.connpass.com