CDKのリソースライブラリを作った。!こういうアノテーションが作られるモチベーションと利点はScrapboxに書いたように:[ECS]のtask停止は[Mackerel]にホストの退役と登録というかたちで通知されるが、その契機となった変化が何なのかがわからない。Events]を購読する[Lambda]が、コンテナの停止理由をMackerelのアノテーションとして付与する。紐付き、揮発していくコンテナより長いライフサイクルで残るため、連続的な変化を追いやすい。aereal-tech......というところ。実行されOSがPATHをよしなに設定するというものだが、ユーザーが追加したパスより優先度高く追加するようになっており、かなり傍迷惑。/usr/local/binなどより任意のパスを優先させたいのに〜〜〜ということがよくある。いうオプションをconfigure時に渡すオプションとかがあったけどなくなっており、仕方なくforkして--disable-etcdirを付けたり、といろいろあったのだが、/etc/zprofileを読まないよう設定することもできて、これがおそらく最もポータブルな対処法でありそう。GLOBAL_RCSするだけ。GLOBAL_RCSでも回避できないこと。commitの日付が1年くらい前だった。かかりきりだったので1年以上やっていたことになる。上から下まで本当にいろいろやれて良かった。CDK......などなど。引きの良いものが並んでいるけど、単に映えることだけを考えて挙げたり選んだわけではなく、必要とされるものや過去の反省を活かして最適な選択肢を模索した結果、これらが妥当と判断したので、すべての要素について選んだ根拠を自信をもって説明できる。矛盾するようだけれどもすべてが最適だと考えているわけでもなく妥協した点や今後より良い選択肢が出そうな点についても心当たりがある。いったリスク含めて説明できるし責任を負えると判断して作れたのは良い経験だと思う。した判断の壁打ちの機会が特に初期は乏しかったので、後から加わったメンバーからツッコミはなかったものの、それは既にできあがったからじゃないの、っていう疑念が無いでもない。別にチームメンバーからのフィードバックを信用していないわけではないけれど、なんとなくこういうことって「便りのないことは元気な証拠」とも言い難い側面があるなあと思うので不安になっているだけだと思う。今、自分が最も困っていてかつ解決すべきなのは、チームでお山の大将に限りなく近付いていることだと思う。自分の考えを理詰めで整理して伝えることが得意だと自負しているが、それが「なんか違う気がする」くらいの指摘を呼ぶ素地が無いように見えているんだと思う。別に自分が受ける批判・指摘の全てに一切の瑕疵があってはならないなんて思っていないけれど、普段チームを引っ張るような役割の人間が常に75点くらいの仕事をしていたら、50点くらいでも赤点のような気がする、って周りに思わせてしまうっていうのは人の心として理解はできる。仕事の面で自分も甘さを見せれば良いのかというとそうではない気がするし、そうだとしてもかなりやりたくない。一辺倒では解決できない問題だと思うので、気長にトライアンドエラーしていくことになると思う。Designの落とし込みやJSSの選択について初期にかなりがっつり会話できたのは良い経験だった。あれこれ比較して当初から本命だったstyled-componentsに落ち着いたものの、比較検討できたことで選択に自信がついた。いったフロントエンドに近いところから始まり、インフラ設計はほぼひとりで、構築は後から加わったSREと一緒にやった。VPCなどネットワーク設計より上のことは一通りやったし、だいたい勘も付いた。Cardsとかに出てくるサムネイルが大きいんじゃないかと思い、写真係やりますよって言い出して長命なシリーズになっている。プロの方が絶対に腕は良いけど、小回りが利くことは強みではないか。登壇speakerdeck.comspeakerdeck.comspeakerdeck.com仕事関係が2つ、完全な趣味が1つ。数は少なめだったけど、仕事の方はまだ出せそうなネタがいくつかあるのできっちり出しておきたい。趣味のほうは、リメイクということで個人的にはちょっといただけない感じがするものの、動くデモが作れたのでトントン。ソフトウェアわりと仕事でやっているプロダクトで必要になったので書いてOSSにした、っていうのが多い。いう便利グッズがあるのでこれを使っているだけ。http.TransportというPerlでいうLWP::Protocol的なやつを差し替えるだけでやっている。72行くらいしか無いけど、Goのnet/httpのおもしろさが詰まっていると思うので気が向いたら読んでみてください。いう発想によるライブラリ。文字列にするNPMパッケージ。CDKでRDSのhostname/portを結合してコンテナの環境変数に渡すために作った。containerとして良い感じに差し込むグッズ。mackerel-container-agentが対応している環境変数などをいちいちドキュメントを見に行かなくてもIDEで補完してくれるようにという目的で書いた。ベータ版の頃はクラスタがFargateとEC2かによって設定の感じが変わるのでまあまあ賢いコードが書いてあったけど、今は単にデフォルト値を与えるくらい。してくれた思い出のライブラリです。tokenやらを環境変数にexportするグッズ。X-Rayのトレースを良い感じに取るプラグイン。ほとんどopentracing版を真似しただけ。migrate-gh-repo2つのGitHubリポジトリでissueやらラベルやらを移行するスクリプト。似たようなツールはいろいろあるけど、ほとんどべき等になっているところとあまり賢くないが故に柔軟性が高いのが売り。numberにコメントでリンクが書き連ねられるだけなので、N:1の移行も問題なくできる。技術的には設定にCUEを使っているのがおもしろポイント。仕事に全振りした1年だった。それなりに得るものもあったけど、どうしてもやったことが仕事の文脈だけだとおもしろみが無いなあと感じてしまう。来年は文字通りの意味でワークライフバランスの良いおもしろ技術探索をやっていく。Codetsconfig.jsonなどはデフォルトで補完が効くが、これはsettings.jsonで追加できる。renovate.jsonを編集する時はこういう設定を入れておくと便利。APIが出た頃に上記記事を書いてもう5年が経とうしている中、最近いろいろなグッズが進化してタイトルにあるような良い塩梅のChatOpsが実現できそうなのでそれのメモ。ActionsこのAPIだけではなんらかの仕事は行われず、ただWebhookのイベントが通知されるだけのAPIになっている。Actionsの存在でできることの幅や手軽さが変わってくる。書いておけば、Deploymentが作られた時にこのYAMLの内容が実行される。always()を指定し、失敗した場合もこのstepが実行する......となっている。APIのパラメータにはtaskやenvironmentがあるのでステージング環境か、アプリケーションのデプロイの他にDBのスキーマ更新などの付随するタスクも表現できたりなど、いろいろ使い出はありそうに見える。Slackからデプロイでは肝心のDeploymentはどうやって作るの、ということだけど、これまでは丁寧にcurlするしかなかったのが最近SlackのGitHub連携から作れるようになった。OWNER/REPOを実行するとこういう画面が出てきて:nリビジョンなどを埋めるとAPIが呼ばれる。Actionsが設定されていれば、ピタゴラスイッチが動き出すという寸法。viewというものがベータリリースされている。https://github.com/aereal/actions-playground/deployments今は本当にログしか出てきていなくて味気が無いけれども、GitHub公式でこういうビューを作ろうとしているのはちょっと期待。APIを使ってちょっとしたビューを作るのはわりと楽だろう。APIを呼び出しているだけなので、なにかうまく動かないということがそもそも起きにくい・起きたとしてもトレースがしやすい・実装の移植がしやすい、という点が嬉しい。なんでもChatOpsにしたはいいがいざSlackが落ちると何もできないという事態に陥ることなく、いざとなればcurlを叩けば良いというのもポイントが高い。APIとActionsの組み合わせだとGitHubが中央にあるので、とりあえずリポジトリを見れば概形がわかるというのも差別化ポイントになりうると思う。Statusなど既に広く使われている機能などと統合されているというのも魅力。Deploymentにrequired_contextsを指定できるので、prchecklistのチェックが完了しなければデプロイが進められない、という制約も簡単に実現・移行できる。APIが盛り上がっとるなということを思い出したのがきっかけ。Flowに近いワークフローになっている。Flowは困ることが増えるなあ、という印象を抱いていた。いえ上記Togetterまとめにあるとおりgit-pr-releaseは様々な点で便利なのは間違いない。Flow的なブランチ運用が根幹にあるものではないと思っていた。APIが進化してきたので注目しているというかんじ。14:221PasswordのChrome拡張どれ使えばいいのか問題2019-10-10相対パス、絶対パス、相対URL、絶対URLどう違うのか微妙にわかりづらいので表にした。URIでないものを「相対URL」としています。schemeが付いている場合のみ絶対URLで他の表現は相対URL、パスの絶対相対とURIの絶対相対は独立している、ということを覚えておくとよさそう。監視』を読んでMackerelの良さを改めて実感した読んだ。新サービスローンチ前に読んでおいてよかった。何かが壊れたら、あなたがそれを直す必要があります。場当たり的対応を減らす自動車メーカーのフォ–ドが、燃料タンクにガソリンがどのくらい入っているか計測する方法がない車を作ったとしたらどうでしょうか。これらは、車が完成してから単に取り付ければよいというものではありません。最初の段階から車にデザインされているものです。自分のアプリケーションにそんなメトリクスはないという時はMackerelネイティブに育った人間なので「監視はこうあるべきだよね」という意識がキャリアが始まった時からインストールされていたことに気がつき、最初から一番良いやつを選べたのは高速道路だなーと思った。このブログはMackerelを開発・提供している株式会社はてなでの勤務時間中に書きましたが、意見は私個人のものです。Codeからtsconfig.jsonのパスを正しく認識させるtypescript-eslintは型情報が必要なルールのためにプロジェクトの場所をparserOptions.projectで指定できる。extensionが実行する時にはtsconfig.jsonを見つけられない。Codeからも正しく見つけられる。package.jsonや.eslintrc.jsonではだめ。大量のリソースを削除するような操作はコンソールでぽちぽちやるとミスりそうで怖いのでスクリプトを書いて適宜レビューしやすいようにしたい。普段使うIAMユーザーの権限だと広すぎると間違ったリソースを削除するなどの事故が怖い。普段からやや広めの権限で生活しているといきなり狭めるのも難しい。今回はversioningが有効なS3バケットを削除したいが、削除するためにはすべてのオブジェクトのすべてのバージョンが削除されてバケットが完全に空じゃないといけない、という問題に遭遇した。そこで実行したいAPIコールとリソースを限定したポリシーをアタッチしたIAMロールを作る。aws-cliを実行する際にrole_arnを指定してAssumeRoleすることで、リスクを抑えられる。InterfaceIAMユーザーにアクセス許可を委任するロールは同じAWSアカウントを指定することもできるIAMロールは使用する主体に応じて作り方・コンソールの画面が違う。ユーザーにアクセス許可を委任するロールの作成」を選ぶ。Managementを読むとあたかもAWSアカウントをまたいだ操作を許可するためだけに使うようにも読めるがそんなことはなくて、IAMロールを発行するAWSアカウントと使用するAWSアカウントが同一であっても構わない。自分は資料を使い回して登壇することに強い抵抗を感じるので心苦しくあったのですが、社内勉強会から飛び出して広いところでぜひ話したいという思いがある一方で、ここから進んだ話をスクラッチから立てるのは今は厳しいという評価もあったので、折衷案としてトークの内容はほぼそのままに、きちんと動くデモを作りなんなら登壇するその場でメロディをつけるくらいのライブ感を出すくらいはやれたら自分も納得できそうだということでproposalを出し、トークする場をいただきました。Audioを使ったデモはうまくいったのですが、MIDIキーボードを挿してメロディをつけるところはうまくいかなかったのでそれだけ心残りです。nodeのゲイン調整をしておらず音が大きすぎたため、メロディが鳴っているはずだけどほとんど聞こえないということが起きていました。nodeを繋げたらよさそう。目新しくも高度でもない話なので失望されないかドキドキしていましたが「おもしろかった」「やってみようかと思った」といった感想をいただけて登壇冥利につきます。トークを聞いた方・このブログを読んだ方はぜひaereal/musikをforkしておもしろコンポーザを作ってください!!!聞いたトーク当日朝までデモを作るなどした結果、時間も体力も尽きてあまり聞けなかったのが悔やまれます。2019メルペイのオンボーディング内容をベースに公開できる内容にしたということで、まずオンボーディングプロセスが充実していることに驚きました。個人的には分散トランザクションを伴う決済システムを開発しているので、わかる〜〜〜と思いながら、やっぱりある程度泥臭くなるよね、と安心しました。2019DQNEOさんによるコンパイラを1から作るライブコーディング。Goのscannerなども使わず、コアの部分はほぼスクラッチから書いていくかんじで他の言語でも実践できそうなつくりなのが真似しやすくて親切設計でした。会場から「そこtypoしています」とかやりとりがあったり、ライブ感があってめちゃくちゃ楽しかった。使わされるだけではなく、ツールとして使う対象にする」「守破離」という趣旨だと理解しました。ActiveRecordが向いていないところもけっこうあるよなー」とわりと対岸の火事気味に聞いていましたが、一方、ライブラリ・フレームワークを使う上で一般的な話だとも思います。これとこれがありますね、というような思考を辿っていくもので、Railsユーザー以外でも得るものが多い内容でした。2019事前から楽しみだったし実際にめちゃくちゃおもしろかったトーク。newが果たされました。素朴な役割のソフトウェアシステムでできあがるというのがおもしろい。そのスケールがめちゃくちゃに大きいというのが興奮します。11月に一般公開があるみたいなので申し込みます。土地だよと聞いて、トラブルに巻き込まれずに済むのか内心ヒヤヒヤしていましたが、無事どころかずいぶん楽しいできごとが多くて好きになりました。ホーム感がありました。駅の近くにクラフトビールのお店がいろいろあったり、雑なところからそこそこのところまで飲食に困らなかったり、なにより荒川が近いのが良い。川で飲んだりすることはけっこう奇行じみていると思われがちだけど、実質立食パーティみたいなもので、席に囚われず歩きまわっていろんな人と話せるというとても合理的なかたちでかなり好き。懇親会が終わったあと20人くらいで荒川に移動したけど、飛び込みで20人も入れるお店はなかなか無いと思うし、見つかっても近くの席以外の人と話すのはなかなか難しいと思う。出入り自由で、飛び入り参加したければ任意でお酒や食べ物を持ち寄るだけでよく実質プリペイドなのも気軽。他人との距離、たしかにという感じ。居酒屋だと近すぎて疲れるけど、川だと自由に歩いて離れられるから気が楽、とかある。あとは、クラブとか行くとうるさいから距離近くなるとかある気がする。荒川はとても広く地元の石狩川を彷彿とさせるスケールで、懐しい顔ぶれと話しているシチュエーションも手伝ってやけに楽しくちょっと懐かしい感じがした。