やったこと・書いたもの{2018,5}

PHPでAWS SESから(添付ファイル付き)メッセージ送信をしようとしたらハマった

Fix a typo by o0h · Pull Request #12122 · cakephp/cakephp · GitHub すごく些細なtypoの修正、単独で送るのはあまりお行儀よくないよなぁ〜・・って気がする・・とりあえず見つけてしまったので投げてみた系の。

tech.connehito.com

会社で作ったプラグインがawesome-cakephpに掲載してもらえて嬉しい

プラグイン公開時にリアクションをくださった方が、他薦してくれた様子で。
使い方についての質問Issueを投げてくれていた人。自分が書いたソフトにThanks!!とか言われながらコメントもらえるのうれしいですねぇ〜

で、 Adding Sentry alongside Airbrake for exceptions logging. by jtraulle · Pull Request #298 · FriendsOfCake/awesome-cakephp · GitHub

作っている途中は、ここに名前が載ることを1つの目標にはしていたものの、CONTRIBUTING.md を読んで「要件満たしてないかもな〜」と思って諦めていた次第。
それが、dereuromarkさんがすぐに +1くれていたりで、テンション上がってたw 特に議論やネガティブぽい指摘もなく、無事にとりこまれた〜〜って気づいて嬉し〜

わがままを言ってだいぶ時間を費やさせてもらって書いたプラグインだったので、少し報われたかな〜なんて勝手に思ったり。

今年は社内外でOSSを意識的に作っていきたいなと思っているのと、「もっと切り出せるな〜」って思っている部分があるので、引き続き色々と試していきたい

Composerの更新 -> PRを作る、をCI上で自動的に実行するプラグインを作った(作っている)

業務で利用しているAWFの更新を、チームメンバーでローテで回しているのだがレポジトリの数が増えてくると大変だ。
私も先日、1つのレポジトリの更新作業担当になったことがあった。「手が空いたらやっておいてね」もしくは「スプリントの狭間くらいでやっておいてね」である。
恥ずかしながら機会を逃しているうちに数日が経ってしまい、むきーーー!というところでした。どちらかというと、普段は「更新しようぜ!!」と煽ち立てる役回りだったので立つ瀬がないという事はこの事。

転んだのにタダで立ち上がるのは癪なので、どうにか「CIで自動的にPR作るところまでやってくれ〜〜」という事をするようにした。

github.com

前提として、「こまめにupdateしていけると、修正対応とのコストは劇的に下がる(ほとんどのものは、互換性を保ったまま動いてくれることのほうが多い)」という立場です。
AWF本体の更新というのは大掛かりな部類と考えるが、それですら「ビルドバージョンごとに最新に追従していく」戦略をとることで、これまで大きな問題の発生を避けられているという体感がある*1。また、テストカバレッジも高めに保ててている〜という背景があるのに支えられていると感じる。

てな訳で、「更新しておいたわ!サマリーつけておくから、軽く確認しておいて!!」というPRをCIが自動的に出してくれ・・・という夢を、形にした次第です。

これは結局のところComposer Pluginという形に落ち着いたのだけど、当初はスタンドアロンに「Composerを使役する側」の何かを書こうとしていた。

  • そもそもはyarnにはそういうのあるらしいよという話を聞いて、「composerでもできるっしょ!!」と思ったのがとっかかり
  • お、gemにもあるじゃん
  • どうやるかな〜composerコマンドをスクリプトで叩く感じかな〜
  • まぁshでもgoでもいいよね〜
  • updateしたあとにdiffをとって、内容をPRに書くのは必須だなー。
  • diffを取るのはcomposer使うとすぐできたりするかな・・?
  • あー、じゃあPHPで書くかー
  • どうやって差分取るんだ?composerソースコード読んでみるか・・
  • Command クラス作ってinvokeしたりするのか〜
  • 結構大変そう・・・どうしたものか・・
  • 今回のスコープはあくまで「CI上で動くようなもの」、なら「更新する」って仕事自体はCIに任せちゃっていいな。composer cli
  • そういえば、composer-diff-pluginがプラグインになっているってことは、「更新があったときに結果を受け取ってゴニョ」ができるってことだな
  • なるほどcomposer-plugin、アリだな・・・!

という思考プロセス。
結果としてcomposer-pluginとか、普段からあんなにお世話になっているcomposer本体への興味が向いたのが凄く収穫に感じた。

何度も読んだスライド ↓↓

speakerdeck.com

「いちおう動く」なところまでは行ったので、ひとまず(私が更新を忘れてしまって、かわいそうな・・)会社のレポジトリで試してみる。
テストとか静的解析を入れられていないので、書いた本人ですら「開発途中っていってもテストゼロってやばくない?糞ダサエンジニアじゃん・・・」ていう敗北感が強いのだけど。どうやってテスト入れたら良いのかなーーーーという感じ。*2
やれるところからやっちゃおう、という感じも勿論ありつつ。

そのあたりを形式だけでも整えてしまって、そしたらv1.0.0タグを打ってQiitaとかに使い方紹介記事みたいなの書こうかなーという算段

業務前とか業務後に時間を取ってやったので、それも毎日ではなかったということで、あまりまとまった時間を集中的に取る!!ということはできていなかったのだけど。
2週間前に思い立ち、2日めくらいに「そうか〜composer pluginなら行けそう!」と方針が変わり、最初の1週間で7割位のとこまで行って、実際にtravisのdaily cronで叩いたりして様子を見つつ、いまちょうど2週間目終わりかなって感じ。
1,2週間くらいでひとまず形になる〜〜〜ていう規模のペットプロジェクトは良いのでないかな、と思ったしリフレッシュになりそう

*1:CakePHPが、そのあたりに寛容でドラスティックな変更が入りづらい〜という事情はあると思います。ので、使っているソフトや属している文化次第かなぁ・・といった

*2:実際問題としては、テスト書けるようなモノの方が「やりたいこと」「この実装でやれていること」といった問題点を浮彫にできるので、開発効率は上がる・・ので今回のような形は割と苦しさを感じた

Hugo + CircleCIでブログを作った

前の記事の続き。
最終的にHugoにすることになった。

  • やりたいのは「記事集」みたいなやつ
    • 静的ページとフィードアイテム?みたいな区別はそこまで必要ではない
    • まして立派なトップページとかはいらないんだよなぁ〜
  • Docusaurusは寧ろstaticな「サイト」を主眼としている印象。実際、「トップにfeed並べたいなあ・・」というところで手が止まってしまった
  • 「静的サイトジェネレータ」ってスコープでいくと、(ちょっと古い記事だけど)すげーたくさんあるw
  • その中で、hugo良さそうかな〜と思っていたら会社の人にも「hugoはいいぞ〜」って聞いたので選択

という流れで。

整備にあたって、主にここら辺の記事を参考にさせていただきました。

circleci.com hori-ryota.com chroju.github.io

で、実際に書いたcircleciの設定はこんな感じ。*1

version: 2
jobs:
  build:
    docker:
      - image: felicianotech/docker-hugo:latest
    steps:
      - checkout
      - run: git config --global user.email (ここにemail)
      - run: git config --global user.name (ここに名前)
      - run: echo "machine github.com login (ここにgithub id) password $GITHUB_TOKEN" > ~/.netrc
      - run: git submodule sync
      - run: git submodule update --init --recursive
      - run: git worktree add -B gh-pages public origin/gh-pages
      - run: rm -rf public/*
      - run: hugo
      # ユーザページサイトにPushする
      - deploy:
          command: cd public && git add . && git diff --cached --exit-code --quiet || git commit -m "Rebuilding site" && git push origin gh-pages

workflows:
  version: 2
  build:
    jobs:
      - build:
          filters:
            branches:
              only: master

ちょっと無駄がありそうな気もするんだけど・・・ machine github.com login とかは要らないのかもな?ひとまず調べても試してもいないです。

  1. hugo作れる〜なdocker imageがあるのでそのまま使わせてもらう
  2. themeをsubmoduleで入れているので、checkoutしたらsyncして
  3. 今回は gh-pagesブランチを使ってるので publicディレクトリをsubtreeで gh-pagesブランチ化して*2
  4. hugo コマンドで public ディレクトリ(= gh-pagee ブランチのroot)にサイトを生成して
  5. publicディレクトリに移動して、add & commit & push
  6. workflowsで「マスターの更新があった時だけ実行」というfilterを掛けて
    • master merge時にサイトが更新されるようにする

という流れ。
もうちょいスッキリさせられる気はするけど、とりあえずこれで動く。

しかしながら感動したのは、「hugoって何やってるの?」みたいなところを理解しなくてもそのまま動いた!!という点。
多少コマンドや設定周りでドキュメントを読みはしたものの、ソースコード読んだり〜とかは全くしていない。
よいツールだなぁ〜という印象。。golangだとこんな感じでポータビリティの高いソフトを作りやすいのかな?とか思ったり。

*1:鍵の設定とか環境変数の設定は、以前に済んでいたので。

*2:公開用ディレクトリの中身を一旦rmってるのは、当初のブランチの状態が面倒くさそうだったから。

アウトプットの量にも拘ってみたい〜

大体いつも、自分が「ちゃんとできること増えてるかな〜」とか「強くなっているかな〜」みたいなのを振り返ると絶望的な気持ちになるのだけど、「いやいや・・もっと色々とやってません・・でしたっけ・・・」みたいな。
そのため、「こういうコトしました!」みたいなのを纏めておきたいな〜と思った。

daisuki.nichiyoubi.land

ずっとやろうやろうと思っていて、えいっ!ってやった次第。
そうか、もっとcakeにはPR送っていると思ったぜ・・・と感じる。
昨年中、ふとしたタイミングで「外部から見たときに自分がどんなことしているかって、可視化する気概が無いと何も語られないものだなぁ〜」と気づいた事があり。それからずっと、「やったほうが良いな」と思っていたこと。
もっと強いエンジニアなら、「github.comを見てみな!全部おいてあるぜ!!」だと思うのだけど。そこまで行っていないので・・

自分の owned なものは、さほど言及しなくてもいいと思い、

  • 他者のOSSへのPRやらContribution
  • 会社のブログやOSS

あたりかな?という感じ。
逆に、前のエントリーで触れているpet project系の話だったり、qiitaへの投稿だったりは、それはそれで良いか〜、と思う。

もっと社会貢献できると良いですね。