PHPでAWS SESから(添付ファイル付き)メッセージ送信をしようとしたらハマった
Fix a typo by o0h · Pull Request #12122 · cakephp/cakephp · GitHub すごく些細なtypoの修正、単独で送るのはあまりお行儀よくないよなぁ〜・・って気がする・・とりあえず見つけてしまったので投げてみた系の。
PHPでAWS SESから(添付ファイル付き)メッセージ送信をしようとしたらハマった
Fix a typo by o0h · Pull Request #12122 · cakephp/cakephp · GitHub すごく些細なtypoの修正、単独で送るのはあまりお行儀よくないよなぁ〜・・って気がする・・とりあえず見つけてしまったので投げてみた系の。
プラグイン公開時にリアクションをくださった方が、他薦してくれた様子で。
使い方についての質問Issueを投げてくれていた人。自分が書いたソフトにThanks!!とか言われながらコメントもらえるのうれしいですねぇ〜
作っている途中は、ここに名前が載ることを1つの目標にはしていたものの、CONTRIBUTING.md を読んで「要件満たしてないかもな〜」と思って諦めていた次第。
それが、dereuromarkさんがすぐに +1くれていたりで、テンション上がってたw
特に議論やネガティブぽい指摘もなく、無事にとりこまれた〜〜って気づいて嬉し〜
わがままを言ってだいぶ時間を費やさせてもらって書いたプラグインだったので、少し報われたかな〜なんて勝手に思ったり。
今年は社内外でOSSを意識的に作っていきたいなと思っているのと、「もっと切り出せるな〜」って思っている部分があるので、引き続き色々と試していきたい
業務で利用しているAWFの更新を、チームメンバーでローテで回しているのだがレポジトリの数が増えてくると大変だ。
私も先日、1つのレポジトリの更新作業担当になったことがあった。「手が空いたらやっておいてね」もしくは「スプリントの狭間くらいでやっておいてね」である。
恥ずかしながら機会を逃しているうちに数日が経ってしまい、むきーーー!というところでした。どちらかというと、普段は「更新しようぜ!!」と煽ち立てる役回りだったので立つ瀬がないという事はこの事。
転んだのにタダで立ち上がるのは癪なので、どうにか「CIで自動的にPR作るところまでやってくれ〜〜」という事をするようにした。
前提として、「こまめにupdateしていけると、修正対応とのコストは劇的に下がる(ほとんどのものは、互換性を保ったまま動いてくれることのほうが多い)」という立場です。
AWF本体の更新というのは大掛かりな部類と考えるが、それですら「ビルドバージョンごとに最新に追従していく」戦略をとることで、これまで大きな問題の発生を避けられているという体感がある*1。また、テストカバレッジも高めに保ててている〜という背景があるのに支えられていると感じる。
てな訳で、「更新しておいたわ!サマリーつけておくから、軽く確認しておいて!!」というPRをCIが自動的に出してくれ・・・という夢を、形にした次第です。
これは結局のところComposer Pluginという形に落ち着いたのだけど、当初はスタンドアロンに「Composerを使役する側」の何かを書こうとしていた。
Command
クラス作ってinvokeしたりするのか〜という思考プロセス。
結果としてcomposer-pluginとか、普段からあんなにお世話になっているcomposer本体への興味が向いたのが凄く収穫に感じた。
何度も読んだスライド ↓↓
「いちおう動く」なところまでは行ったので、ひとまず(私が更新を忘れてしまって、かわいそうな・・)会社のレポジトリで試してみる。
テストとか静的解析を入れられていないので、書いた本人ですら「開発途中っていってもテストゼロってやばくない?糞ダサエンジニアじゃん・・・」ていう敗北感が強いのだけど。どうやってテスト入れたら良いのかなーーーーという感じ。*2
やれるところからやっちゃおう、という感じも勿論ありつつ。
そのあたりを形式だけでも整えてしまって、そしたらv1.0.0タグを打ってQiitaとかに使い方紹介記事みたいなの書こうかなーという算段
業務前とか業務後に時間を取ってやったので、それも毎日ではなかったということで、あまりまとまった時間を集中的に取る!!ということはできていなかったのだけど。
2週間前に思い立ち、2日めくらいに「そうか〜composer pluginなら行けそう!」と方針が変わり、最初の1週間で7割位のとこまで行って、実際にtravisのdaily cronで叩いたりして様子を見つつ、いまちょうど2週間目終わりかなって感じ。
1,2週間くらいでひとまず形になる〜〜〜ていう規模のペットプロジェクトは良いのでないかな、と思ったしリフレッシュになりそう
前の記事の続き。
最終的に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
とかは要らないのかもな?ひとまず調べても試してもいないです。
gh-pages
ブランチを使ってるので public
ディレクトリをsubtreeで gh-pages
ブランチ化して*2hugo
コマンドで public
ディレクトリ(= gh-pagee
ブランチのroot)にサイトを生成してpublic
ディレクトリに移動して、add & commit & pushという流れ。
もうちょいスッキリさせられる気はするけど、とりあえずこれで動く。
しかしながら感動したのは、「hugoって何やってるの?」みたいなところを理解しなくてもそのまま動いた!!という点。
多少コマンドや設定周りでドキュメントを読みはしたものの、ソースコード読んだり〜とかは全くしていない。
よいツールだなぁ〜という印象。。golangだとこんな感じでポータビリティの高いソフトを作りやすいのかな?とか思ったり。
大体いつも、自分が「ちゃんとできること増えてるかな〜」とか「強くなっているかな〜」みたいなのを振り返ると絶望的な気持ちになるのだけど、「いやいや・・もっと色々とやってません・・でしたっけ・・・」みたいな。
そのため、「こういうコトしました!」みたいなのを纏めておきたいな〜と思った。
ずっとやろうやろうと思っていて、えいっ!ってやった次第。
そうか、もっとcakeにはPR送っていると思ったぜ・・・と感じる。
昨年中、ふとしたタイミングで「外部から見たときに自分がどんなことしているかって、可視化する気概が無いと何も語られないものだなぁ〜」と気づいた事があり。それからずっと、「やったほうが良いな」と思っていたこと。
もっと強いエンジニアなら、「github.comを見てみな!全部おいてあるぜ!!」だと思うのだけど。そこまで行っていないので・・
自分の owned なものは、さほど言及しなくてもいいと思い、
あたりかな?という感じ。
逆に、前のエントリーで触れているpet project系の話だったり、qiitaへの投稿だったりは、それはそれで良いか〜、と思う。
もっと社会貢献できると良いですね。