KGDC Tech Conference で LT してきました #KGDC

speakerdeck.com

「息を吸うようにエラーを監視する」というタイトルで発表してきました。

イベントについて

KDDI グループ会社それぞれの技術者が集まって主催するイベントです。

グループ会社とはいえやってることはそれぞれ違うので、アドテクの話だったりインフラの話だったりE2Eの話だったりと、いい意味でバラエティに富んだ楽しいイベントだったと思います。

kgdc.connpass.com

今後継続的に開催していくようです!

LT について

本当は5分にとても収まらない色々があったw

確か入社初日の夜遅くに Slack にアラートが飛んできて、でも誰も反応してなくて、「これ大丈夫なやつですか?」とドキドキしながら聞いて回ったころからするとだいぶいい感じになりました。 (結果大丈夫なやつでスルーされてたんだけど、新参者は分からんので)

最初は一人でひたすら Issue 立てて、聞いて回って記録して、Slackの通知チャンネル整理して。

今はかなりチームっぽくなり、発生したエラーにはすべて何かしらのリアクションが 見える形で されています。

夕会やモブプロはある意味みんなで謎解きしてるみたいな楽しさもあります。

エラー監視と運用のところは自分がコネヒトに入社してから割と力を入れてきたところなので、ひとつ対外的なアウトプットにできてよかったなと思います。

「More Effective Agile」を読んだ

「CODE COMPLETE」のスティーブ・マコネルがアジャイルについて書いたということで読んでみた。

アジャイル関連の書籍はちょこちょこ読んでるんだけれども、久々に「これはいいなぁ!」と強く感じた本です。

個人的に、「アジャイル」ってエモーショナルな部分にフォーカスされがちなときがあると思っている。

一緒に考えるべき技術的な側面がどこか切り離されて表現されているように見えたり、宗教的になって「熱狂的な信者とそれ以外」のように感じてしまったり。

この本はある意味淡々と論理的に、「ソフトウェア開発をいかに効果的に行うか」という話をアジャイルのコンテキストで述べている。(タイトルそのまんまだ!)

「なぜアジャイルでやるのか」という問いに答えるためのヒントがたくさん詰まっていると思う。

非常におすすめです。

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ブログ

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

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

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

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

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