VCRみたいに実際のHTTPレスポンスを保存してテストで再利用できるライブラリGoを作りました。github.com外部HTTPリクエストをスタブするTest::WWW::StubというPerlのモジュールや、スタブするレスポンスをあらかじめ記録しておいた実際のレスポンスから再現するVCRというRubyのライブラリなどにインスパイアされました。missing.}ローカルにキャッシュが無い初回は実際にリクエストしそれを保存する、次回以降は保存されたレスポンスを再現するので実際にリクエストしない、といった振る舞いをします。freeな実装なところがアピールしたいポイントです。雑なスクリプト中で使う用途なのでかなり雑だけど、これでだいたいうまくいったので満足。2018の16日目の記事です。id:akiymによるOpenSSLはどこにいるでした。地味にOpenSSL系のモジュールはリポジトリのセットアップ時にハマりがちで、かつたまにバージョンアップでビルド引数の渡し方が変わったりする曲者です。Crypt::OpenSSL::Guessはナイスモジュールですね。いう下の句(?)があるのは知りませんでした。id:akiymはキャリア的には一応後輩(?)ですがPerlについては学ぶことばかりです。id:aerealがお届けします。普段はアプリケーションエンジニアですが、最近は社内カメラマンを拝命する機会をいただくことがあり、エンジニアインターン2018や麻婆豆腐なしにどっしり構えられるエンジニアや生きることとコードを書くことが同じエンジニアのインタビューの撮影に携わりました。手前味噌ですがありのまま度の高い率直な内容で楽しんでいただけるかと思いますので、もしまだご覧いただけてない方がいらっしゃればぜひ。はてなブログをはじめとするいくつかのはてなのサービスではジョブキューにTheSchwartzというPerlとMySQLを使ったミドルウェアを利用しています。TheSchwartzの失敗したjobやerrorがいつ消えるのか、そのうち消えるといった認識だったけど、どれくらい経つと消えるのか、どういうタイミングなのか、詳しく知らないなーと思い調べました。ジョブが失敗したときおわりアドベントカレンダーは毎日1つ穴を開けるとお菓子が出てきたりするもので、そこから転じたブログ記事のアドベントカレンダーはもともとささやかなtipsを連続で紹介するといった風情の取り組みだったといいます。id:Windymeltです。年収は?知らなかった......。way.https://docs.docker.com/compose/compose-file/#linksどうすればいいかというと↑に書いてあるようにカスタムネットワークを追加して、それに参照しあいたいコンテナをそれに参加させたらよい。local_dev:おわり意外とさっくり移行できて助かった。ECS.これら眺めてみる。groupをつけかえるというもの。deployment-pipeline.yamlがデプロイCIを構築するCFnテンプレート。CodePipelineで各ステップを実行している。groupを作り、ボタンで承認されたあとで切り替えるLambdaを実行する。新しいserviceを作るCFnテンプレートはservice.yamlにあり、ecs-clusterを作るテンプレートでパラメータを変えて2度実行してliveとbetaが作られる切り替えるLambdaはPythonで書かれたblue_green_flip.pyを実行する。swaptargetgroupがメインのロジック。Blue/Greenデプロイメント」のコードを読む2018-11-19SNSで同僚をフォローするのをやめたSNSというかTwitterで同僚をフォローするのをやめて精神衛生が良くなった。一緒に仕事をするうえでパーソナリティも知りたいなと思って基本的にフォローしていたのだけれど、最近それによって楽しいとか便利と思うことより、きついと感じる機会のほうが多くなったのでやめた。そもそものきっかけは、チームでテックリードというエンジニアのリーダー的な役割を拝命したからだった。チームを良くするためにという思いもあって、チームのエンジニアのそれも職能のうちの一部に限定して基礎的なマネジメントに手をつけはじめた。エンジニアがメンターを務めることになっている。その制度とは別にテックリードとしてチームメンバーのキャリアプランなどを鑑みて、チームと個人がお互いにハッピーになるにはどうしたらいいか、ということを定期的に話している。すると必然とメンバーの個人的な動向を気にするようになる。有り体に言うと最近仕事うまくいってそうだな・調子悪そうだな、とか、そういうこと。調子が良い時は良いけれど、悪い時はだいたい何かあまり楽しくないできごとによって調子が上がっていないことが多い。プライベートで何かあったとか、季節の変わり目でフィジカルがついてこないとか、上司含む他のメンバーと折り合いが付かない、とか。いう動向を察知したら解決に向けて手伝えることはないかと声をかけたりもする。今まで自分の手に負えないような巨大なできごとはなかったので、それなりの負荷でそれなりの点数で解決できたと思っている。少なからず自分にも負荷がかかることも事実なのだった。少なくとも今のところの自分は、相手の感じているストレスを自分なりに受け止めて、まず相手のストレスを柔らげて緊張をほぐす、というやりかたをとる。個人的な体験だけれども、エンジニアという課題を解決するということを生業にしていると、自分が感じているストレスを課題に変換できないことは、自分の能力の不足ではないかとか、そもそも課題ではないのだから周りを変えるかたちでの解決ではなく、自分が適応すべきなのではないか、とかそういうことを考え込んでしまう。言うと自分の感じているモヤモヤを課題というレベルまで昇華できなければ他人と共有できないとさえ思い込んでいる節がある。して冷静な時に書き出してみれば「そんなことないでしょ」と思えるのだけれど、真剣に悩んでいる時あるいは弱っている時は、そういう考えに至ることができない。いう体験は学生時代にはあまりしなかったから職業病みたいなものだろうと捉え、そうすると個人的な特質というより普遍的である可能性が高いだろうから、特に同じエンジニアに対してはまずストレスの置かれている状況に共感を示して「モヤモヤしている状態を伝えてもいい・伝わる可能性がある」という安心をしてほしいな、という思いがある。いった振る舞いは自分の強みでもあると思っている。いったメンタリングが自然にできているのだと思う。いえかなり消耗するので、得意というのも違うかなと思っている。適度に休息が欲しいけれど、そこでSNSでの繋がりがネックになる。離れている時だけTwitterを見るが、そこで同僚をフォローしているとそのツイートに一喜一憂してしまう自分がいる。わかりやすく「仕事がうまくいかない!」とか言っている場合もそうだし、こっちが滅入っている時は「疲れた」という発言にさえ自分の瑕疵を疑いぎくりとする。ほとんどノイローゼみたいな時は、自分がファシリテータを務めたMTGを終えた10分後くらいに「は〜〜」みたいな溜息めいたツイートを見た時は、責められているのかと思い落ち込んだりもした。普通に考えて無関係な確率のほうが高いと思う。考えた結果、同僚をフォローするのをやめた。少なくともチームメンバーはフォローしないことにした。自分の負荷を減らすためでもあるし、またよりよいマネジメントを目指してのことでもある。一緒に仕事をするメンバーのことは、仕事というコンテキストから見える姿のみを見て理解しよう、ということ。大袈裟にいえばSNSとかで仕事とは関係のない思想信条を発露していたとして、それが自分の主義と反するものだった場合、いくら仕事と関係のない思想信条であったとしてどこかしらにひっかかりを覚えずにはいられないと思う。実際にあったSNSでの発言に被害妄想めいた不安を抱いたとして、けっきょくそれを確かめるにはプライベートとかまで踏み込む必要があるが、それは泥沼だ。自分がケアしたいのは仕事仲間としての同僚であって、同僚という人間そのものではない。いうようなことを考えてフォローするのをやめた。そもそもけっこう前から同僚はフォローせずに非公開リストに入れて見ていたのだけれども、それも消した。これは近年のTwitterがリスト機能をぞんざいにしているので、そもそも機能が使えなくなるのでは、といった不安もきっかけだった。ちなみに結果からすると自分は同僚のSNS上の発言や振る舞いを見て落ち込んだりもしたけれど、あくまで自分が一方的な解釈をしただけのことなので、自分含めた人々は好きにSNSをやるのがいいと思う。01:23SNSで同僚をフォローするのをやめた2018-10-30『みんなではじめるデザイン批評』から学んだコードレビューのやりかた同僚が社内グループに『みんなではじめるデザイン批評』を読んだ感想を書いていて、それが良かったのとそういえばこんなことあったなと思い出したので読んだ感想がてら書きます。見る命ずるな、尋ねよ『みんなではじめるデザイン批評』を読んでからデザイナーとの会話だけではなくエンジニア同士でコードレビューをする時にも「まず、意図を尋ねる」ことに気をつけるようになった。(だから、こうすべき)」と思ってもそのまま脳直で出すのではなく、なにか事情があるのかもしれないと思い「こうなっているのはなぜですか?」と聞く。すると「時間がないけど急いでいるので、今は妥協したい」「イケていると思っていないけれど他に思いつかなかった」などの返事がもらえるので「時間がないのは仕方がないので落ち着いて考えなおすというissueを入れましょう」とか「こういうやり方だとしっくり来ませんか?」という返事へ進める。真似しやすいのではないか、と思っている。コードレビューは構造上どうしてもレビュアーに対して権威付けが起きやすいが、質問形式でレビュアーが常に下手に出るよう振る舞う儀式的な関係を強いるとバランスが是正されるのではないかと思う。加えて、この「レビュアーは常にまず自分の未知を想像して尋ねる」という姿勢をいつでも誰にでも強いて、レビュアーとレビュイーというロールで振る舞う時には対等であると意識付けることが肝。コードレビューのやり方として「ここはこうだからこうすべきです」という言い方にしましょうというルールだと、そこまで断定できるドメイン知識や経験のない人はすぐに実践できず、かくあるべきレビュアーとしての振る舞いと現在の自分のあいだに断絶が生まれてしまう。コードレビューでレビュアーを務めることはドメイン知識やエンジニア一般としての経験を積むチャンスなのに、レビュアーを務めるにはドメイン知識や経験が必要、というデッドロックが起きてしまって、これはまずい。模倣しかし「尋ねるレビュー」は誰でも真似できるのが一番の利点だと思う。そのシステムに詳しいエンジニアも、そうでない人も、変更に対して「どういった理由があってこういった変更になったのですか?」と尋ねる。レビュイーはその疑問に明快に答える。言い淀むところがあればそれはより良くするチャンスかもしれない。それはエキスパートであってもそうでなくとも、そうする。それは対象のソフトウェアの知識を効率良く培う方法であるからでもあるし、チームによるソフトウェア開発を効率的に進めるためだからでもある。いった仕事は担当できる人を効率的に増やすために模倣しやすく設計するのが大切だと常々感じる。専門性の高い仕事もある一方、大抵の仕事はまず模倣するところから始まるはずで、裏を返せばそっくり真似のできないやり方はもっと改善の余地が潜んでいそう、とも言えそう。対するフィードバックとして「〜してはいけないです」という表現が活きてくる。何らかの指標に基づいて明らかにやってはいけないと誰でも断定できるときは断定してよい、という「例外」を設けられる。考えを深めると、普段コードレビューで指摘することの大半は、その是非がほとんど決定的じゃないということも考えられる。N+1クエリはバッドパターンだけれど、いついかなる時も致命的かというとそうではない、とか。アクセス数がほとんどないとか、Nが高々10くらいなら、大したことにはならない、みたいなそういう話。今まで書いたことだけやっていれば万事良しかといえばそうではなくて、細かな言い回しに気を付けるといったことは依然として必要だろうと思う。今回はコードレビューにおけるプロセスのうちいくつかを形式的にしようという話でしかないから、そういったウェットな話題は残っている。今回は言及しなかった。タイトルに反して「制作物に対しより効果的でヘルシーなフィードバックをしたい」と思う人にとって『みんなではじめるデザイン批評』は示唆と発見に富んでいることと思います。単行本(ソフトカバー)この商品を含むブログを見る各所で良いという評判を聞いており、ちょうど先々週くらいに京都に台風が来るので自宅に引っ込み続けられるように急いで買った。Amazonでは売り切れていたのでリアル書店で買った。読もうと思ったきっかけテックリードというロールを拝命して1年と数ヶ月が経つ。なんとなく今までの仕事と違うので知識の地図を広げたほうがいい気がするな、と思っていた。現在所属する組織であるはてなとしてはテックリードはマネージャーではなくアプリケーションエンジニアの専門性を高めていく方向性の先にあるロールとされているけれど、マネジメント、とりわけプロジェクトマネジメントについては必要とされるなという感触をおぼえた。見積もりとか計画作りとか、そういう分野は別途学んではいるが、しっくりこないというか要素技術だけ学んでおり有機的に繋がらず身に付いたかどうか怪しいので、シナプスを繋げたいなーとかねがね思っていた。(ので今やったほうがいい)」とか知っているけれど、マネジメントに関してはそうではない。一言でいうと「テックリードはなぜプロジェクトマネジメントをやったほうがいいのか」「どれくらいできるといいのか」みたいなのが知りたい、というかんじかも。そこでこの本が登場し、目次を読むとよさそうだった。実際に読んだところ良かった。学び最近テックリードないしマネジメントを学びはじめたけれど何をしたらいいかわからないや、という人はこれを読むととっかかりが見つかりそう。少なくとも自分は見つけられた。ために」というコンセプトなので、マネジメントについて本格的に書いてあるというより、エンジニアの視点・価値観に近いところからアプローチしてあるのがよい。最初はマネジメントされる側の視点から始まって、メンター、テックリード、チームマネージャー......という風にマネジメントする対象がより大きくなっていくという構成が丁寧。抽象的な精神論ばかりではなく、たとえば「提案を断る時にはいきなり『いいえ』『できません』と言うのではなく『なるほど、そのためにはこういうものが必要ですね』といった風に実現のために必要な対価を求める」といった具体的なテクニックが書いてあって、ほどよいバランス感だと思う。実際に使える・使うかよりも、こういう今の自分でも実践できそうな情報が盛り込まれているかどうかで未知の分野について書かれた記述を信用していいか・地に足が付いているかを判断できるのが良い。自分が所属している組織にはチーフエンジニアやシニアエンジニアといった職位があるが、そういった同僚を他者評価する時にも「期待」が設定しやすくていいと思う。自分が経験していないポジションに求められるスキルや役割への理解が進みやすいということ。各章の冒頭に筆者が書いたとても丁寧なジョブディスクリプションがあり、通り一辺倒じゃない様々な働きについて述べられている。(もちろんこれはあくまで一例であって、自分たちの組織において求めることを自分たちの言葉で書くのが良いし、そうすべきだと思う)ジョブディスクリプションを書くのはこれからテックリードないしそういったポジションを目指すエンジニアにとっても意義がありそうなので、早速やろうという後半のCTOや経営メンバーの章はだいぶ高度で「へー」というかんじでわりと流した。いうことを考えているのだな、という知識がついたのはよい。マネジメントの各技術については別途専門の本を読むのがよさそうに思う。SIGMA|株式会社シグマレンズ交換式カメラを開発・製造しているシグマがカメラシステムを終了させる告知を出して、告知をすること判断自体とその告知内容がとても丁寧で心証が良かったです。前提カメラシステムはカメラボディ自体と交換レンズおよびフラッシュなどのアクセサリからなります。レンズで最低数万、熱心なユーザーは数十万・数百万という単位でお金をつぎ込みます。カメラシステムは複数社が展開していますが、基本的に互換はないので熱心なカメラユーザーはこれから数年・十数年に渡って数十万〜数百万のお金を使う先を吟味して選び、決定しています。FOVEONという他社とは一線を画す革新的なセンサーを採用しており、そのセンサーから得られるイメージはとても熱心なファンをひきつけています。詳しくはメーカーのテクノロジー説明を読んでもらいたいのですが、一言で表すならば技術的な独創性ゆえに「XXXと比べて画質が良い・悪い」といった他のメーカーと同じ次元には立たずに、根本的に出てくるイメージそのものが違う、といったレベルの違いがあります。させてフェイドアウトさせるに任せる、といった方針をとる会社が多いです。下手に行動を打つよりはひっそりと、というのは良し悪しはともかく合理的であるといえそうです。いった慣行・背景がありながらもきっぱりと終了をアナウンスする姿勢からは、システムそれ自体よりもシステムを作ってきたシグマという会社を信頼してくれているという自信が見えますし、ひいてはカメラシステムという息の長いプロダクトに対するビジョンの強さが伺え、ポジティブな印象です。アナウンスがあったからだけではなく、その内容が実に丁寧で真摯だったからだと思います。実現するために最適な仕様です他社とのアライアンスを通じて最高のシステムにしますSAマウントのレンズ生産は続けますLマウントシステムのリリースまでに空白期間は設けません既存のSAマウントをLマウントで使えるよう移行手段を用意します......といった内容です。(いつまでに、どうなる)、新システムへの移行がどうなるか、に絞って書かれています。簡潔でわかりやすいだけではなく、実はこの告知には「申し訳ありません」などの謝罪表現が一切使われていません。これから作る新しいものは絶対に良い自信があるし、それに向けた滑らかな移行手段も用意するから安心して、という強いビジョンが伺えますし、それを根拠付けるシグマからのアクションが提示されているからこそ説得力のあるものになっているのでしょう。新マウントへ変更してより素晴しいシステムを作っていく必要があるというシグマ側の事情も匂わせつつも言い訳がましく見えないのは、けっきょくこの判断は最高のカメラシステムをユーザーに提供したいからです、という視点に立っているからという点も見逃せないです。感想これだけ丁寧にアナウンスしても少なからず反発はあるでしょうし、かなりハイカロリーな決断だと思いますが、シグマのプロダクトに対するビジョンの強さを感じさせ、シグマ製品を愛用している自分のシグマに対する信頼感は増しました。アナウンスからはユーザーに対するケアだけでなく、これから作ろうとするシステムに対する強い自信を感じられます。ユーザーに寄り添う姿勢も、新しいものに対する自信も、どちらか一方だけでは片手落ちで、両方を兼ね備えているからこそ納得感のあるアナウンスになったのでしょう。カメラ業界的には決して大きなパイではないシグマですが、確かな地位を築いており今回のアナウンスはさらにそれを磐石にするものと思います。いち開発者としても感じるところがたくさんあり、業界は違えど、見習いたいところばかりです。2018で話しました。2017に続いてスピーカーとしての登壇で光栄です。なるところだったのでよかったです。トークについてspeakerdeck.com資料はすでに公開しています。#10という社の名前を冠したイベントでもこのシステムについて話したのですが、けっこうおもしろいシステムができたという自負もあったしお待たせしてしまった感は拭えないのでせめて裏側を紹介して「知らなかった、を聞」いてもらえたらな、という思いもありました。実際にbuildersconで話を聞いてもらえる機会をいただけて本当に嬉しいです。実は後半の「ぼくのかんがえたさいきょうのピタゴラスイッチ」以降のスライドは直前に追加したものです。(けどなんとかやっていきたい)」というような話をして刺激を受けて「もっと一般化された・普遍的な話ができるはずだ、したい」と思い捻り出しました。実際できあがった話は、普段から考えていたことを咀嚼したものでかなり納得感がありました。背伸びするきっかけができてよかったです。あと「ぼくのかんがえたさいきょうのピタゴラスイッチ」は「ぼくのかんがえたさいきょうのうぇぶあぷりけーしょんふれーむわーく」をリスペクトしました。これだけでも参加した甲斐がありました。Q&Aすっかり頭から抜けてしまったので、ツイート検索しました。ありがとうございます。これまでのキャリアで最も質疑をたくさんいただけたトークで、とても励みになりました。反応もらえるとうれしいです。Triggerから始めた処理が失敗したとき、DynamoDBから消えているから対応できないのでは?」A「TTLを仕込んだテーブルと仕込んでないテーブルの2つがあり、TTLは証明書期限より2週間早い。nginxのプロセス再起動。memcachedにのっているのでnginxを立ち上げ直しても影響はしない。2018年9月8日Q.「StepFunctionsのJSON手書きつらくならないんですか?」A.「つらいです。schemaがないので全体を把握するのがむずかしい。Goのコードを解析してschemaを作るグッズを作ろうとしている」あともうちょっと質問いただいた気がします。録画見て思い出そうと思います......。聞いたトーク正直いうと他のトークほとんど聞けていないのが心残りです。ただでさえ発表前でナイーブになっているところへ関西にものすごい台風が来たり、地元の北海道で大きな地震が起きたりして、けっこう堪えました。北海道の地震は仕事でもプライベートでも大きな打撃があって冷や冷やしました。【石狩データセンター】お客さまには、大変ご心配、ご迷惑をおかけしており、深くお詫び申し上げます。一部復旧した電力と非常用発電設備により現在も正常に稼働を継続しております。ただいま、非常用発電設備の追加燃料の給油を行っております。2018年9月7日また、会場へ出向いても満員御礼だったということが多かったのもやや残念です。2018昨年のビルコンで僕も「Goで実装する軽量マークアップ言語パーサー」というトークをして興味のある分野だったので聞きました。2018でベストスピーカー賞2位とのことで、プレゼンテーションが上手な方の話を聞いてみたいという興味もありました。実際、幅広いトピックを密度高く紹介するというプレゼンテーターとしては難易度の高い話だったと思いますが、細かい粒度でまとめを挟んだり、構文木など難しい概念はグラフィカルに説明することを徹底されており、唸りました。内容自体だけでなくプレゼンテーションそのものが勉強になりました。2018興味の範囲がWebを中心としている限りおよそ出会うこともなかろうトピックだったので聞きました。AIDなどの払出しがISOだったり、中央集権っぽいのが組み込みっぽいというかWebっぽくなくて新鮮ですね。運営スタッフのみなさまへフィードバックスピーカーディナーよかったですお酒入ってたこともあり1分間ピッチの反応が思ったより良くて発表前にちょっと自信がつきました規模感がちょうどよく、いろんな人と話しやすかったです満員御礼で見れないトークが多く残念でした><街頭ディスプレイみたいな、コンサートホールのホワイエで見れるやつみたいな、立ち見席みたいなのもあると嬉しいかも、とおもいましたとはいえ部屋に入れなかったらHUBへ行くことができて、そこはそこでおもしろい話ができました。さんとイベント後のHUBでゆっくり話ができたのもいい思い出です。ビルコンも3度目ですが、毎度、これだけの規模のイベント運営されるみなさまには頭が下がります。最近、TypeScriptで癒されたさ重視でaws-cdkを見ています。プログラマブルに扱う高級な・抽象的なライブラリと見てよく、概念もほぼ対応しているのですが、Appsという概念はaws-cdkに固有のもので特色たりえるものに見えるので、これについてメモします。基本的に公式ドキュメントに書いてあることの咀嚼しなおしなので、既に読んで理解している人には新しい情報は無いです。Kit......とのこと。この説明はランタイムとしてのaws-cdkに寄った説明でどういった概念なのか掴みづらいです。Appsは複数スタックからなるでしょう、ということです。preProdといった開発環境用のstackを追加しています。これらステージごとのstackなどの集合がappであるという捉え方です。デプロイはどうするかこれもCLIのヘルプを読めばわかりますが、各コマンドは対象となるstackを指定することができます。Kit指定しなければ紐付くすべてのstackが更新されます。aws-cdkの基礎にCFnが存在し、CFnの基本デプロイ単位はstackであることを思い出すと理解しやすい挙動だと思います。ように実行するのがよさそうということがわかりました。Manageraereal.org長らくさくらのVPSでホスティングしていたのだけれども運用がめんどうになったのでこれを機にGCPへ移行した。Manager......の4つ。StorageGCP版S3みたいなオブジェクトストレージ。使い勝手はかなり似ていて、S3同様にウェブサイトとして公開する設定もある。CDNのoriginにする。BalancingAWSでいうALB/NLBにあたるもの。Balancingになる。余談だけど日本語ドキュメントでは「HTTP負荷分散」と訳されていて、動名詞なのかプロダクト名なのかわかりにくい。パスやホストに対してルールベースでbackendへリクエストを送ることができる。使い込んでいないけれどALB/NLBと機能の差異はそんなにないようにみえる。CDNGCPが提供するCDNサービス。APIがあったり、普通なかんじ。CDNに限らないけれど全体的にGCPは安めな気がする。Formationみたいな構成管理するグッズ。YAMLを使うのはCFnと同じだけれども、変数展開などはJinja2というAnsibleでも使われているテンプレートエンジンを採用している。既存のよくできた技術を再利用する筋のよさは後発のGCPならではってかんじ。APIのリクエストパラメータと同じ名前・同じスキーマなのでそちらを参照せよというドキュメントになっており親切。Managerで対応しているか確認できる。APIのドキュメントを引けばよくて便利。置いたのでご覧ください。Managerはよく出来ているし筋がいい印象を持った。会社ではAWSを使っているのでおもしろさ重視でGCPでもっと遊んでいきたい。policyの変換がすごいaws-cdkを見ている。TypeScriptもしくはJavaでAWSの構成管理ができる。CloudFormationのプログラマブルなやつと考えるとよい。TypeScriptは癒しなので癒されました。今日は感動ポイントをご紹介。literalでよいかんじに変換されていそう。ネイティブにいいかんじに実装していこうという気概が感じられて、今後に期待が持てますね。出力するYAMLが、既存のCFnのYAMLと完全に互換を保てたら脱出も楽になるからいいな〜とおもっているのだけれど、そういうオプションはざっと見たかんじなさそう。pathみたいなissueはあるのでなにも計画がないわけではなさそうだけど、あれだったらP-Rを送っていきたい。調べはじめたりしてまあまあ不毛だし、そういうのとってくるAPIあるでしょと思い調べたらやはりあった。内部向けっぽいAPIを無理矢理使っているわけでもないので、まあまあ安定しそう。ブログを報告するスターをつけました引用をストックしましたストック一覧を見る閉じる引用するにはまずログインしてくださいログイン閉じる引用をストックできませんでした。再度お試しください閉じる限定公開記事のため引用できません。