YAMAGUCHI::weblog

海水パンツとゴーグルで、巨万の富を築きました。カリブの怪物、フリーアルバイター瞳です。

キャンプを始めるにあたって買ってよかったもの

はじめに

こんにちは、Google Cloudのオブザーバビリティ担当です。Google Cloud Operations suiteとかOpenTelemetryとかやってます。コロナ禍でなかなか気軽に街や観光にいけなくなり、ソーシャルディスタンスを保ちつつできる新しい趣味をということで今年の頭からキャンプを始めました。皆考えることは同じで折しも世の中はキャンプブーム。キャンプを始めるにあたって友達と一緒にグループキャンプなどはできませんでしたが、家族との時間は楽しく過ごせました。キャンプをはじめるにあたってはインターネットで多くの情報を知ることができました。キャンパーは相対的に見てインターネットで情報発信をしている人が多いように感じます。おかげでほぼネット通販で道具を揃えることができたわけですが、使い始めるまでそこまで重要だと思ってなかったけどあってよかったものがたくさん出てきました。そうした細かなものも含めて、本記事では初心者目線で「これがあって良かったな」と思ったものを書いていきたいと思います。

この記事はキャンプアドベントカレンダーの1日目です。

adventar.org

メイン

まずはネットで検索したら色々と事例が出てくるメインのキャンプ道具についてです。

テント

なにはともあれテントです。最初は普通のドームテントとタープを買おうかな、と思っていたのですが、すでにキャンプベテランである id:a2c に「初心者で家族で行くならツールームがいい」と勧められて、ちょうどスノーピークがエントリー用のツールームを出していたので購入しました。

1張り目でグランドシートと専用インナーマットで10万円コースは少し緊張しましたが、買ってみてこれは本当に良かったと思いました。このテントで良かったのはまず設営で迷うことがないことです。テントの設営自体が初めてだったときでもガイロープの本体への取り付けも含めて1時間半程度でできましたし、いまは慣れやガイロープの取り付けをカラビナで行うように変えたこともあって全部で30分程度で設営が終わるようになりました。テントの設営が早く終わるのは何よりも良いですね。

つい先日も最低気温3度の中キャンプをしましたが、前室で灯油ストーブをつけていたら、室内は15度くらいまで上がり、とても快適に過ごせました。雨が降るキャンプでも普通の雨程度では問題なく過ごせましたし、良い買い物だったと思います。幕がポリエステルなので雨の後の手入れも楽なのがいいですね。

いまはタープを張るのも簡単にできるようになりましたが、やはりとりあえずこれさえ建てたら寝て雨が降っても過ごせる場所ができるというのは屋外にいて何より心強いものです。夏の室内の暑さなどは考慮に値する懸念事項ではありますが、全体的に見て私のような 初心者に使いやすいテントだなと思います。

マットと寝袋

キャンプで寝れないと肝心の日中がまったく楽しめないし、それは本当に嫌だったのでマットと寝袋はお金をかけました。

マットと寝袋のおかげで、これまで寝心地が悪くて寝られなかったということはありませんでした。リフレッシュをしにキャンプに行くわけですから、これは本当に用意して良かったなあと毎回思います。

少し失敗だったと思ったのはダウンシュラフは冬に結露で表面が濡れると残念なことになるというところで、ここは今後シュラフカバーを用意するなり、現状応急措置としてやっている毛布の外掛けを続けるなりしようと思います。

バーナー

キャンプを始めようと思い立って調べるまでは焚き火台で調理をするのがメインだと思っていましたが、よくよく調べてみたら焚き火は火力を安定するまでに時間がかかるし、火力の安定も難しいのでバーナーが必要と知り、なるほどなと思いました。で、以前花見などで鍋をしたときに普通のカセットコンロでは難しかったことを思い出して調べてみると、やはりキャンプ用のバーナーは違いますね。ちゃんと風防があって感心しました。

で、このツインバーナーを買ったわけですが、いまのところ安定して使えていて、かつ専用キッチンスタンドを使っても使わなくても、いい感じに調理しやすいので大変重宝しています。もはや逆に焚き火がおまけでこのバーナーがあるだけでキャンプが成立する気すらします。ステンレスで汚れを落としやすいのもいいですね。

椅子

自分は体格が大きいため、背もたれでちゃんと頭まで支えられるものがなかなかなく、かつ色や座面の素材感が好きだったのがコールマンのレイチェアしかなかったので、まずはこれを購入しました。

はじめは持っていたヘリノックスのチェアワンを使っていたのですが、自分はこの背もたれでずっと過ごすのは姿勢が厳しいなと感じたので、背もたれ付きを買いました。またチェアワンは出先でちょっとだけ座りたいという用途ではよかったのですが、長時間座るときに軽量すぎて安定感に欠けるなと思ったのも理由でした。

小物

次は別になくてもまったく問題なく過ごせるけど、あってとても便利だった小物です。これらは主に100円ショップや雑貨店で買ったものがメインです。

鍋敷き(兼焚き火テーブル)

IKEAの鍋敷きです。焚き火台で調理したてのコンボクッカーとバーナーで調理したスープをそのまますぐにテーブルの上に置く、といったことができるようになります。雑に熱いものをテーブルに置けるのは思いの外便利ですよ!

www.ikea.com

しかもこの鍋敷きはステンレス製である程度強度があるので、これと鍛造ペグを組み合わせて簡易的な焚き火テーブルを作ることも可能です。

https://camp-quests.com/wp-content/uploads/2020/04/%E3%82%BD%E3%83%AA%E3%82%B9%E3%83%863.jpg (画像はこちらより引用)

他にも灯油ストーブの上に五徳代わりに置いたりするなど、雑に便利に使っています。

ゴミ箱

ゴミ箱代わりに使っているのが、100円ショップで買ったランドリーバッグです。

ランドリーバッグjp.daisonet.com

普段は薄く畳んでしまっておけますし、キャンプ場に付いたらこれをぱっと広げて中にゴミ袋を入れるだけですぐにゴミ箱になってくれます。また白いメッシュも意外と中のゴミを目隠ししてくれます。これを色違いで持っていて、ゴミの分別をしています。一目でわかるので、非常に便利です!

ランタン

キャンプと言えばランタンですが、ガスランタンや灯油ランタンは危なかったり手入れが大変なので、まずは便利に使えることを重視して次のようなLEDランタンを複数用意しました。

高いLEDランタンはより明るいものもありますが、キャンプであまりに明るいLEDランタンは興ざめになるのと、広い範囲で程よく明るいほうが諸々便利という話を聞いたので、このランタンを4つ持っていっています。それが大正解でほんのり広い範囲が明るくなり、サイトの雰囲気はいいまま、物が暗くて見えないということがなく、夜でも便利に過ごせています。このランタンの場合、明るさが弱なら冬で2晩使っても持つので、とても重宝しています。

ランプ掛け(キャンピング用)jp.daisonet.com

ところでランタンハンガーがダイソーに売っているので、これでポールにもランタンが設置できます。本当に100円ショップのキャンプ道具の充実具合は素晴らしいですね。

スキレット

なぜかキャンプ道具が豊富な100円ショップ界隈ですが、調理器具周りも豊富で、たとえばスキレットもあります。

スキレット Mjp.daisonet.com

アヒージョや目玉焼きなど、ちょっとした調理をするのにちょうどよいサイズで、何より安いのが最高です!スキレット以外にもメスティンやフォーク、スプーンなど、100円ショップで揃えられる調理器具がたくさんあるのは本当に助かっています。

おわりに

キャンプ好きな人と話をすると、すぐキャンプ道具の話になるのですが、はじめてみてその理由がようやくわかるようになりました。キャンプサイトはただの空き地なので、そこに自分が持っていった道具でそこでの数日間をいかに快適にするか、という工夫が必要になります。その工夫を助けてくれるのがキャンプ道具であるからこそ、キャンパーは常に道具に関心があるのだなと、実感しています。今日挙げたものよりさらに便利な道具などがあればぜひおしえてもらいたいです。例えば最近関心があるのは使いやすいキャンプ用の包丁です。

わざわざ不便なところに不便な生活をしにいく、という自己矛盾がある趣味だとは思いますが、空き地から快適な空間を作り上げるというプロセスは、日々無意識に享受している便利さを実感できる良い機会となっています。キャンプを終えて家に帰ってくると、ふかふかの布団やベッド、温かくて気持ちの良いお風呂、気温を気にすることなく物を冷やせる冷蔵庫、安定して強力な火力を保てるガスコンロ、夜でも明るく過ごせる蛍光灯、などそれらすべてが便利に感じられます。

まだこれから色々なキャンプ場で様々なトラブルを経験することになると思いますが、長く不便を楽しんでいこうと思います。

明日は世界の山下さん(@pyama86)です。

「SREの探求」という本が出版されました #seekingsre

はじめに

こんにちは、Cloud Operations担当者です。このたび私が監訳者として関わった「SREの探求―様々な企業におけるサイトリライアビリティエンジニアリングの導入と実践」という本がオライリー・ジャパン社より出版されました。本日より書店ならびに各社オンラインストアでご購入いただけます。

電子書籍版についてはオライリー・ジャパンのサイトよりePub、PDFの各種フォーマットにてご購入いただけます。

www.oreilly.co.jp

TL;DR

「SREの探求」はGoogle以外の企業でSREの導入がどのように行われているのかを記したエッセイ集です。スタートアップからエンタープライズまで、多くの事例を楽しみながら読める一冊だと思います。ボリュームに圧倒されるかもしれませんが、短編集なのでどの章からでも気軽に読み始められます。ぜひご一読ください。

「SREの探求」のおすすめの読み方

SRE本と同様、非常に分量がある書籍になっていますので圧倒されがちですが、本書は一つの技術に関しての入門やハンズオンを行う類の書籍ではありません。本書の執筆に参加した各社のSREが自らの経験を語ったエッセイ集です。したがって、まずは面白そうだと思う章を読んでみる、というのが良いかと思います。どの章から読んでも構わないと思いますし、読む順番も順不同で構わないと思います。一応、下記にあるように、大まかに4部構成になっていて、各部にある章は関連性が高いものになっているので、読む対象を選ぶときの参考になると思います。

本書を読むに当たって、副読本として同じくオライリーより出版されている「SRE サイトリライアビリティエンジニアリング(以下、SRE本)」が手元にあるとより読みやすいかもしれません。もちろんすでにSRE本を読まれていて内容をある程度把握されている方は必要ないと思いますが、他のSRE関連書籍を読んだことがない、という方は各章に登場するSRE関連用語がわからない可能性があります。Google SREのサイトで原著を無料で閲覧可能になっていますが、日本語の資料があったほうが読みやすいという方はぜひご用意ください。

「SREの探求」はどのような本か

本書はDavid N. Blank-Edelmanが編集し2018年9月に出版された "Seeking SRE" の日本語訳書籍です。

この本は、すでに同じくオライリー・ジャパンより刊行されているSRE本、「サイトリライアビリティワークブック(以下、ワークブック)」「データベースリライアビリティエンジニアリング」に続くSRE関連日本語訳書籍の第4弾となります。

本書は、GoogleだけでなくSREを実践している(しようとしている)多くの企業がその経験を様々な観点から語り、それらを4部に分けて編纂したエッセイ集です。私はこれまで、業務上あるいはコミュニティ関連のイベント等で多くのエンジニアや経営層の皆様と関わる中で、SRE(サイトリライアビリティエンジニアリング)の導入について質問をいただいたときに私が社内のSREの方々から学んだ知見を共有してきました。多くの方々が異口同音にその価値に共感しつつも、その実践となるとハードルがあり、難しいと感じている様子を目にしてきました。

私自身は他社へSREの導入の支援を直接行ったことはない*1ので、実際に各社がどのように導入を行ってきたかは各社の公開情報を断片的に集めてきて学んできました。そうした公開情報はブログ記事であったり、カンファレンスの録画やスライドだったりするのですが、まとまった形で参照できる書籍は本書が出るまでは存在しませんでした。私が2018年にGoogle Cloudのチームへ異動しオブザーバビリティの担当をすることになってからそうした情報を活発に調べるようになったのですが、ちょうど異動した直後に本書が発刊され、これは福音と手に取ったのでした。目次に並ぶ社名を見たあと、実際に各社がSREの導入を試行錯誤した様子を見て、共感をするとともに、苦労が偲ばれました。SREの導入には銀の弾丸は無いと改めて確認するとともに、Google以外でももちろんSREは実践できるのだと、あらためて確信できようになる、そんな一冊でした。

第1部はよく耳にする「SREの導入」についてです。たとえば第6章や第7章ではSoundCloud社がProdEngチームを組織するにいたるまでの経緯、そしてSpotifyでのOps-in-Squadsの内容が詳細に語られていますが、その経験は多くの企業、特にスタートアップ企業に当てはまるのではないかと思います。彼らは専任のSREチームなしでSREを実践してきているわけですが、この例はまさに「SREというタイトルやチームがSREを実践する」ということではなく、会社全体としてその実践を行うことが大事であるということが伺いしれます。また逆に第8章や第10章では大企業でのSREの導入について語られています。これらの章は想像通り鮮やかな解決方法などはありません。特に大企業で発生する組織の問題をどう乗り越えていくのか、という点について生々しい経験を見ることができます。

第2部は「SRE本」や「ワークブック」で触れきれなかったSRE関連の各種手法についての紹介です。カオスエンジニアリング、セキュリティ、データベースリライアビリティなど、「SRE本」「ワークブック」以降に出版された各種書籍につながる内容になっているので、まずはここで概要を抑えてから、必要に応じてそれぞれをテーマとした専門書籍を読むと読みやすいことと思います。*2

第3部はSREにおけるソフトスキルとアーキテクチャーの紹介をしています。個人的には重要なソフトスキルであるドキュメントに関する19章は技術書の中ではなかなか語られないドキュメントの重要性を知れる章です。また23章のアンチパターン集も軽快に読め、気晴らしに読むにはもってこいの章です。

第4部は見過ごしてはならない文化的な側面です。SREに寄った文章にはなっていますが、SREのみならず組織全般に言えるような文化的側面についての考察が広くカバーされています。心理的安全性やバーンアウト(燃え尽き)、はてはソーシャルアクティビズムとの関連性など、広く「人間の組織活動」における懸念事項などを深く突っ込んでいます。心理的にネガティブになるような事象はできる限り起きてほしくないのは常だと思いますし、なかなかソーシャルアクティビズムについてこの文脈で書かれた文章は少ないと思うので、そうした経験を書籍で知れることは意義があると感じます。重い話もありますが、おすすめです。

読んでいただければわかるとおり、どの章も「正解」というわけではなく、現組織が試行錯誤の末にたどり着いた最適解であるということがわかります。それと同時にどの章においてもSRE本やワークブックで何度も語られているような、ユーザーに対する信頼性を獲得するための手法や組織作りを行うことに尽力していることが読み取れると思います。こうした経験の共有が読者の皆さまのヒントになることを期待してやみません。

謝辞

監訳者まえがきでも触れさせていただきましたが、あらためて編集者のオライリー・ジャパンの高恵子さん、翻訳者の渡邉了介さんに感謝いたします。

高さんには全体の進行をしっかりと管理いただき、また私と渡邉さんのコミュニケーションが円滑になるように様々な配慮をいただきました。本書の翻訳原稿はすべて各章ごとにGoogle Docsでいただき、その上に私が「提案」の形でコメントを追加し、それを渡邉さんに再度確認してもらい、良ければ承認、認識のズレがある場合には追加でコメントをいただくという形のワークフローを用意していただきました。会社で日常的にこの形式でドキュメントのレビューを行っているため、私としては大変進めやすかったです。

翻訳者の渡邉さんにはただただ感謝するばかりです。600ページ超の本、しかもエッセイが中心でコードや図表が少なく、かつ技術要素が多い書籍の翻訳を、入念な下調べとともにすばらしい品質で行っていただきました。おかげで私が監修する際にはどこに着目すればよいかが分かりやすく、私の負担が大きく軽減されました。また英語そのもののニュアンスが読み取りづらかった文章も文化的背景から調べていただいた上でいくつかの訳の候補を提案いただいたりと、多くの配慮をいただきました。結局コロナ禍にあって、プロジェクト進行中は直接お会いすることは叶わず、またスケジュールの都合等でビデオ会議もできなかった中で、これほどまでスムーズに共同作業ができたのは、渡邉さんの柔軟性と配慮のおかげだと思います。またこうした機会がいただけるのであれば、ぜひご一緒させていただきたいです。

読者の感想など

レビューエントリー

(更新予定)私の方で確認次第随時追加していきます

blog.hiroakis.net

note.com

e34.fm #7で取り上げていただきました!1:04:00頃から @deeeet さん、@rrreeeyyy さんの注目の章の紹介があります。

e34.fm

speakerdeck.com

ツイート

その他

良い香りがするそうです。

しない場合もあります

*1:ところで、Google CloudではCREPSOといった組織がSREの導入支援を行っていますので、ご興味あればご連絡ください。

*2:セキュリティに関してはBuilding Secure & Reliable Systemsがありますし、データベースリライアビリティについては先に上げた書籍があります。

Googleに入社して10年が経ちました

はじめに

f:id:ymotongpoo:20210415170610p:plain

こんにちは、Cloud Operations suite担当者です。2021年4月18日でちょうどGoogleに入社して10年が経ちました。自分は転職で入社したときのことは書いておらず、前職を退職したときの記録しか残っていませんでした。いい機会なので記録として10年間を振り返ってみようかなと思いました。自分用の振り返りで特に推敲もしておらず、読みづらいと思いますが、とりあえずそのまま出します。

Google入社のきっかけ

当時はPython関係のコミュニティ活動やアウトプットをしていて、ちょうどそのときにGoogleのPartner Solution Organization(いまの gTech という組織の前身)のTechnical Account Managerという職種で空きがあるので、受けてみませんかとメールが来たのがきっかけでした。当時はGoogleというとソフトウェアエンジニア職くらいしか知らなかったので、受けてみるまでそういう技術営業的な職種があることもしらず、失礼ながらどういう職種か調べもせず面接を受け始めました。面接を進める中で職種について理解が深まり、対顧客の仕事が多くあり、様々に技術的に問題解決や価値提供をできる職種だと知ったので興味が深まり、幸いオファーがいただけたので転職しました。

いま思い返すと当時面接してくれた人や入社当時の同じチームだった方はいまはかなりの人が退職したり他国のオフィスに転籍してしまっていて、本当に時間が経ってしまったのだなあと実感します。

YouTubeのTAM/Developer Advocate

f:id:ymotongpoo:20110607010509j:plain
YouTubeの本社に初めて出張に行ったときに撮った雑な写真

最初に担当した製品はYouTubeでした。日本でもいまでこそYouTuberを見かけない日はないほど世間に認知されていますが、10年前はYouTubeは日本国内においてはコンテンツホルダー企業からはお世辞にも良い印象は持たれていなかったと思います。自分は対企業の担当だったのですが、ビジネス開発担当の方々の地道な努力もあって、自分が入ったときには依然としてYouTubeと距離を取っている企業は多数あったものの、同時に試験的にでも公式チャンネルを運用してくださっているも企業がかなりありました。すでにYouTubeを使ってくださっている企業はより収益を上げられるように、まだYouTubeを使っていない企業には導入した場合のコンテンツ保護や収益化した場合の予測、導入の際にはツールやAPIの支援、といったことを業務としていました。当時のYouTube事情はMCN*1が日本でもでき始めたりみたいな話もあったので、結構面白い時期に近くでビジネスが変わっていく様子を見れた気がします。

こういう仕事はソフトウェアを開発するというよりもうまく既存ツールを組み合わせたり、手動でやっていることをなるべく自動化するというような運用仕事がメインでしたが、BigQueryが市場に出る以前よりDremelを使ってダッシュボードを作ったり、お手製ツールで数十TBの参照映像ファイルをアップロードしたりと割とコードを書いたり運用的な仕事が多かったなと思いました。またJASRACとの包括契約を結んでいたこともあって、JASRACが権利者に利用料を再配布するためのレポートを作る必要が出て、実際にそのプログラムを書いたりもしていました。いまはもっときれいに書き直されているはずです。

2012年くらいからはYouTube Liveというライブ配信基盤も公開され、イベントのライブ配信の技術サポートなども現地に行って行ったりしていました。今もそうですが、日本のインターネット環境は世界で見ても相当高水準だったため、日本でのライブ配信帯域幅が大きく、またGoogle側の基盤も不安定だったため、何度かP0のアラートを現地から飛ばしたことがありました。配信の現場にてコンテンツホルダー側の責任者が横で見ている状況で、夜中に起きてもらったアメリ東海岸のSREに状況を説明しながらロールバックやパッチを当ててもらうのは精神的にきつかったです。ただ一方で、生で坂本龍一細野晴臣石野卓球ピエール瀧などに会えたり、種子島こうのとりの打ち上げを見れたのは役得でした。

当時日本でYouTubeに関する対外的な技術的な担当者が少なかったことから、必然的にその動画処理パイプラインやライブ配信CDNの仕組みを見たりすることも多く、技術的にも刺激が多かったです。ご存知の通りYouTubeは買収企業でバックエンドはもともとPythonとMySQLだったのですが、入社時にも絶賛MySQLからBigTableへの移行をしていたりと、巨大なマイグレーションを見ることができたのは面白かったです。

また権利処理システムやネットワーク帯域の確保に関する契約など、サービスに関わる法律や交渉にも関わることができたのは今思えば楽しかったです。Googleが海底ケーブルを他社と協業で敷設していることは有名ですが、それが日本のIXに接続された後は各Tier1プロバイダー経由で各ユーザーに接続します。YouTubeトラフィックでいえば世界有数のトラフィック量を誇るサービスだった(である)ため、たとえばGoogleイントラネットワーク*2と各プロバイダとの接続をIX経由ではなく、ピアリングすることでコストを削減できたりします。あるいはエッジノード(Google Global Cache)で人気コンテンツがキャッシュされていればトラフィックの縮小につながるわけです。こうした取り組みの現場に少しでも関われたのは大変貴重な経験でした。このあたりの話は次のページが詳しいです。

peering.google.com

その後、2年ほどしてからDeveloper Relationsチームに移り、YouTube APIを使ってシステム自動化やSNSキュレーションを行っている国内外の企業の支援をするのも楽しい仕事でした。

Partner Developer Advocate

Developer Relationsのチームが組織改編で製品別ではなく役割別になり、自分はYouTubeのチームから大手企業や中堅スタートアップがGoogleの各種製品(Chrome/Web、Androidといったクライアントサイド)を使って連携する場合の技術支援や新規技術の普及をするチームに移籍になりました。このチームでは常にgTechなどで手厚くサポートできる体制が整う前の新しい製品や機能を扱い、かつ四半期ごとに注力する技術領域が移り、キャッチアップが大変でした。本社やヨーロッパのチームは人数が多く、英語のままサポートできることが多かったので割と技術領域に対してメンバーが固定されていましたが、APACのチームは割と自分と同じように四半期ごとに担当を移る動き方をしていました。

日本で展開に関わった製品でいうとChromecast、Tango、Android Lollipop〜Pieの各新機能、Google Sign-in、Google Photos、Accelerated Mobile Pages、Eddystone、Progressive Web App、Chrome Custom Tabs、Google Now、Googleアシスタントなどがあります。事例をあげようと思ったら多すぎたので割愛。いくつかリリースアナウンスとかインタビューとかで対外的に出ていた記事を貼っておきます。

関わった製品はうまく行ったものもあれば、途中でプロジェクトが終わってしまったものもあり、この会社の良いところも辛いところもいろいろと見てきました。たとえばGoogle Photosに関しては、当時前身となったGoogle+のフォト機能があり、そのフォト機能との他社サービスとの連携というプロジェクトがいくつか動いていました。Google I/Oの直前にようやく連携が終わり、I/Oが終わったらプレスリリースを打ちましょうということになって、現地でお祝いをするという予定も立てた上で、先方の担当者とともにGoogle I/Oに向かいました。で、キーノートを現地で見ていたら、まさかのGoogle Photosが発表、連携用のソリューションもその瞬間にdeprecatedになるという大変苦々しいことがありました。*3

f:id:ymotongpoo:20150525034919j:plain
翌日のキーノートで衝撃の発表をされることを知らずに撮影したGoogle I/O 2015の開催前日の会場の外観

Chromecastの日本展開のときは、元々YouTubeにいたこともあり、割と関わりやすい製品*4だったことも手伝って、非常に楽しいプロジェクトでした。実際いまでも新バージョンが展開され続けている製品ですし、自分も毎日使っている製品なので、その立ち上げ時期に関われたのはとてもいい思い出です。

それぞれの製品を深く見ていくにも一人では限界や得手不得手があるので割とムラはあるけれど、Googleが持っている各種クライアントサイド製品すべてに技術的に関われたのは本当に面白い経験でした。関連してAndroidコミュニティやWebフロントエンドコミュニティ、VR、IoT、SEOやゲーム、はたまたカメラ業界など、多くの業界の方々と関わることができたのは幸いでした。やっていた当時は特に何も考えていなかったけれど、いまクラウドの担当になってから、この辺りの知識を持てていることは自分に取ってアドバンテージに感じています。

Cloud Developer Advocate

Partner Developer Advocateでの仕事も5年ほど続いて、チーム自体には不満はなく(むしろ居心地が良すぎた)担当技術領域も広く見ることができたので大変満足していた一方で、自分の担当がほぼ日本だけだったので、次のキャリアを考えたときにもっと他国とのやり取りが多いチームに移りたいと考えるようになりました。また前職に就職したときもそうでしたが、元々はサーバーサイドに興味があってこの業界で就職したこともあって、クラウドのチームに移りました。ちょうどそのときにポジションに空きが出ていたのはラッキーでした。

自分がクライアント側をずっと見ていた時間の中でサーバーサイドの進歩も非常に多く、特にCNCFを中心としたここ5-6年くらいでの発展は目覚ましいものがあります。いまのチームではオブザーバビリティの領域を担当していますが、Googleの中で発展してきたサイト信頼性エンジニアリングの中で重要な意味合いを持つ技術領域で、かつビジネス的にも繋がりが深い領域なので腰を据えて仕事をできている実感があります。

担当領域が単純な技術の話だけではなく、組織運営や企業経営にも関わるテーマでもあるので、しばらくはこのテーマを元にじっくり取り組んでいきたいと考えています。またコロナ禍以降は海外のお客さんに対してプレゼンやワークショップなどを行ったりする機会も増え、元々目的としていた他国との関わりが多くなりました。得難いポジションだと思うので、まだまだ楽しくやれそうです。

Go

上のような部署の変遷と並行して、Go言語の普及とコミュニティ支援みたいなことも仕事としてやらせてもらったりして大変ありがたかったです。入社した直後は確かバージョンが r57 とかで、バージョン番号が weekly タグから切り替わった直後だった気がします。社内のシステムなんかでもちょくちょくGoが採用され始めて、その様子から「この力の入れようとプロダクトの方向性的にはGoは普及する予感がするぞ」と思って使い始めて、徐々に自分の仕事用のツールもGoに置き換え始めていました。

2012年になっていよいよ1.0がでて、「このビッグウェーブに乗るしかない!!」と思ってGo Conferenceをやりたいと思ったのが2012年末でした。一番最初に開催した幻の初回は20人くらいのこじんまりとした会でした。

f:id:ymotongpoo:20130119144443j:plain
TopGateの会議室で開かれた幻の初回

その3ヶ月後にGo Conferenceとして2013年の春に初開催したのでした。

gocon.connpass.com

@tenntennとはここからずーっと一緒に開催していますが、もう今月末のGo Conference 2021 Springで9年目になるというのが信じられません。始めた当初は世界的にもGoのカンファレンスはほぼなく、日本で数百人規模で開催していると報告するとGoチームも喜んで社内スポンサーとなってくれたのでした。TシャツやGopherのぬいぐるみなどはこのときの支援でもらったものをほそぼそと配布していたのでした。*5

【宣伝】去年はコロナ禍によって開催中止となりましたが、今年は初めてオンライン開催で行います。スポンサーのみなさまのおかげで参加費は無料となっていますので、4月24日にお時間ある方はぜひご参加ください。【宣伝終わり】

gocon.jp

Goの初期から関われて良かったことは、Goチームの人と直接やり取りできたことで、Rob PikeやRuss Cox、Andrew Gerrand、といった方々と直接やり取りできたのは非常に貴重な経験でした。*6

f:id:ymotongpoo:20210409224845j:plain
家宝にしているRenee French直筆のGopherイラスト。Go Conference 2014 AutumnでRob Pikeが東京に来たときに「お礼に」と言ってプレゼントしてくれた

もういまではGoは疑うことなく普及した言語になったわけですが、これからジェネリクスが入ってきたりと新しい局面を迎えようとしています。これからどういった発展をしていくのか、引き続き近くで関わっていきたいと思います。

これから

同じ組織に10年所属するというのは人生においても最長で、特にDevRelのチームメンバーは同じ所属で一緒に居続けるという意味では自分の親の次に長い付き合いになる人もいます。出入りが多い会社にあって、こういった長い付き合いが出来るのは本当にありがたいことです。また同じチームだけでなく、多くのチームの多くの優秀な方々と仕事でき、誇張でなく毎日新しい発見があります。

この業界は隣の部署に行く感覚で転職をすることもよく見聞きしますが、自分の場合社内で3年〜5年で部署を大きく移ってきたこともあり、いまだに新鮮な気持ちで働けている気がします。本当にあっという間の10年でした。いまのチームにいる限りは少しでも多くの人の問題解決を手助けできるように努めつつ、楽しくやっていこうと思います。*7

参照

*1:Multi Channel Network、YouTuberが所属する芸能事務所。日本ではuuumがそういった形態として見られるが、海外では現在は潮流が変わっている。

*2:イントラと呼ぶにはあまりにも大きすぎますが

*3:Google PhotosをGoogle I/Oで大々的に発表するため、担当チームがリークを恐れて秘密裏に進めていたようだけれども、それにしてもこちらから対外連携の話はしていたわけだし、流石にこれはないよと思った

*4:製品の関わりやすさというのは、単純に技術としてわかりやすいだけでなく、製品コンセプトが市場に受け入れやすかったり、開発チームがやり取りしやすかったり、といろいろな要素がある

*5:いまはもう世界的にも商業的に行っているGopherConをはじめ多くのイベントが開催されているので、こういう雑な支援はもらえない

*6:RobがGoチームを離れた後もシドニーオフィスに行ったときにもRobが声をかけてくれたりして嬉しかった

*7:辞めそうな雰囲気出てるかもしれませんが、いまは特に現職を辞めるつもりはありません!

Ansibleでリモートのインストールスクリプトの実行をcurlを使わずに記述する

TL;DR

ansible.builtin.uri でコンテンツを取ってきて ansible.builtin.shellstdin を使って流し込む

サンプル

たとえばrustupのインストールは公式ドキュメントでは次のようなスクリプトを使っている

rustup.rs

curl -sSf https://sh.rustup.rs | sh -s -- -y

これをこのまま ansible.builtin.shell に記述して実行すると warning が出ます。たとえばこういう具合にすると

- name: Install rustup
  ansible.builtin.shell:
    cmd: curl -sSf https://sh.rustup.rs | sh -s -- -y

実行時にこういうふうにwarningがでます。

TASK [common : Run rustup] **********************************************************************************
[WARNING]: Consider using the get_url or uri module rather than running 'curl'.  If you need to use command
because get_url or uri is insufficient you can add 'warn: false' to this command task or set
'command_warnings=False' in ansible.cfg to get rid of this message.
changed: [dev]

指摘のように ansible.builtin.uriansible.builtin.shellstdin を使えばパイプの部分をそのまま表現できるのでそのように書き換えます。

- name: Fetch rustup
  ansible.builtin.uri:
    url: https://sh.rustup.rs
    return_content: yes
  register: rustup_installer

- name: Run rustup installer
  ansible.builtin.shell:
    cmd: sh -s -- -y
    stdin: "{{ rustup_installer.content }}"

YAMAGUCHI::weblogの2020年を振り返る

はじめに

こんにちは、Cloud Ops担当者です。いよいよ2020年も最後の日ですね。そして本日は私の誕生日でもあります。例のやつを貼りました。よろしくお願いします。

www.amazon.jp

今年は誰にとっても大変な1年でした。自分のためにも振り返りをしようと思います。

関連エントリ

ymotongpooの2020年

去年立てた目標

目標は立てたものの、コロナ禍においてすべての出張(海外カンファレンスでの登壇)がキャンセルになり、かつ生活を継続する方向でいっぱいいっぱいだったので、2020年前半はほぼ何もできませんでした。

  • オブザーバビリティ関連の展開
    • 今年よりも露出を増やしつつ、OpenTelemetryやpprof周りの開発に積極参加
  • 執筆/翻訳をまとめる
    • 複数の書籍関連の話があったにもかかわらず進捗が大変芳しくなく、各所にご迷惑をかけたいので、来年中に終わらせます。
  • FP業の展開
    • 独立系FPとしてより展開していきたいです

オブザーバビリティ領域に関して

OpenTelemetryとpprof

OpenTelemetryのupstreamに提案をしたりしたのだけれども、プロジェクトのファイルやビルドの構成に大幅に手を入れなければならず、またレビュー担当からも割と冷たい反応をされてちょっとやる気が無くなったので、保留してしまった。一応、アイデアだけは普通に残っているので、upstreamではなく自社のレポジトリで仕切り直してやることにしました。大きなプロジェクトはなかなか大変。

イベントに関しては、OpenTelemetryの仕様があと少しで安定版(ver 1.0)が出る予定なので、いままで仕様が変わりすぎて開催するのをためらっていたところもありますが、そろそろ開催できればと思います。

pprofに関しては、OSSそのものよりもプロプライエタリなサービスであるCloud Profilerについての話を重点的にしていました。特にContinuous Profilingの重要性などをお話する機会が多く、カンファレンスや企業向けのワークショップなど、多くの場所でお話させてもらいました。

observe2020.io logmi.jp tech.mfkessai.co.jp

2021年も引き続きCloud Profilerおよびpprofに関してはノウハウなどを共有したり、フィードバックを開発チームと共有したいと思っていますので、興味がある方がいたらぜひ TwitterでDM、もしくは ymotongpoo [at] google.com までご連絡ください。

Go関連

緊急事態宣言もあり、運営の@tenntenn さん、@budougumi0617 さん、@micchiebear さんと話した結果、Go Conferenceは東京では開催しない決定を早々に行いました。一方で仙台は10月に延期、元々はオフライン開催の予定だったものをオンラインとの並行で開催という形になったので、登壇者として参加させてもらいました。


S3-1 Goにおけるfuzzingとproperty based testing

一方でGopherConは完全にオンライン開催になったものの、開催週だけアメリ東海岸時間で生活することが難しかったため、まったくオンタイムでの参加ができずに終わりました。残念です。

来年はGo Conference 2021 Springをオンライン開催することが決定していて、すでにCfPが始まっています。みなさんの応募をお待ちしております。

www.papercall.io

執筆/翻訳

監訳

まだ第1校の監訳を終えたばかりで、発売日の予定も立っていないことから告知がまだできないんですが、書籍の監訳は実は初めてでした。監訳経験者から「翻訳者の方の技量次第で大きく作業量が変わる」と聞いていましたし、実際自分も翻訳をしたことがあるのでその点は感覚としてありました。

いざ監訳を始めてみると、渡された翻訳は大変読みやすく、また技術的にもいろいろ調べていただいている箇所もかなりあり、非常に進めやすかったです。ただ一方で原著の分量が非常に多く(500ページ超)、それもあって監訳作業は丸1年かかる大仕事となりました。いまはコメントをつけた部分を再確認している状況なので、年明けに第2校が終わる目処が立つのではないかと思います。

また別の本の監訳の話もあるので、そちらの原著のレビューをすぐにしなければならないのですが、そちらは予定より遅れていてご迷惑をおかけしております...

執筆/翻訳

こちらは、2020年はまったく進捗がだせず本当に申し訳ない限りです。2021年はいまよりも生活が落ち着いていると思う(期待)ので、少しずつ進めていきたいと思います。

自作キーボード

もう2つのエントリーで書きましたが、今年の7月くらいから自作キーボードを趣味として始めて、趣味が高じて自作キーボード向けパーツショップを開店しました。

ymotongpoo.hatenablog.com ymotongpoo.hatenablog.com

開店したお店はこちら。

kochikeyboard.stores.jp

開店してまだ2ヶ月ですから正直まだまだ赤字ですが、自分も楽しみながら「お店屋さんごっこ」をしています。開店に至るまで、また開店後も多くの方々、特に自作キーボードコミュニティの方々に助けていただいています。コミュニティに貢献できるように、また早くお店屋さんごっこから事業にできるように、引き続き地道に頑張っていきたいと思います。

来年は自分で設計したキーボードを出すぞ。

生活

2月頭に引っ越しをしました。コロナ禍に入る直前だったので、このタイミングで引っ越せて本当に良かったです。

ymotongpoo.hatenablog.com

前の家からはそんなに遠い場所ではないのですが、今の家は仕事部屋をきちんと作れているので、仕事と生活の切り替えがしやすく、精神的な面で本当に良かったと思います。また前の家よりも断熱効果が高い家なので、強い寒波が来ているこの冬も暖房無しでかなりの時間を過ごせていて、とても助かっています。その分、夏は日差しをきちんと防がないととんでもなく暑くなってしまうので大変でした。

元々は結構出張や旅行で外に出ることが多い性分でしたが、それがすべてなくなって結構ストレスが溜まっているのが正直なところです。夏にコテージキャンプをしたのですが、人混みもなく遠いところで自然に触れられて良いリフレッシュになったので、来年はタイミングを見てキャンプなどをできるようにしたいなと考えています。

また、今年の3月までは会社のジムでほぼ毎日何らかのウェイトトレーニングをしていたのですが、オフィスが全面的にクローズして、まったく出入りできなくなってしまい、まったくウェイトトレーニングができない日々が続きました。はじめは家でHIITなどをしていたのですが、やはり趣が異なるため、ついに9月にジムを契約しました。人が少ない夜の時間帯に行くと貸し切りできるような環境は本当にありがたい限りです。

5ヶ月ブランクはあったものの、いまはコロナ禍前よりも強度が高いトレーニングができるようになりました。

出張/旅行

今年の1月に出張と旅行が3回もありました。

  • 1月1週目 シドニー出張
  • 1月3週目 ロンドン(友人の結婚式)
  • 1月5週目-2月1週目 ニューヨーク&サニーベール出張

ニューヨーク出張に行くときに「どうも新型のインフルエンザが流行っているらしい」というような話があって、マスクを2重にして歩いていました。あれがまさかこんなことになるとはまったく思っていなかったので本当に危なかったです。

ニューヨークに行く際にダブルブッキングによって、人生初のファーストクラスへのアップグレードがあり、大変快適な空の旅を過ごしたのですが、あれが最初で最後の良き飛行機の思い出でした...あの出張以降、パスポートは家の引き出しの中で眠ったままです。早くまた海外出張に行けるような日が戻ってくるといいなあ。

来年に向けて

  • オブザーバビリティ関連の展開
    • OpenTelemetryは安定版がでるので、イベントを行っていきたい
    • Collector関連でOSSを出したい
    • Go関連だとPBTの知見をもう少し深めて、オブザーバビリティに絡めていきたい
  • 執筆・翻訳・監訳をすすめる
    • 執筆はラフでもいいので書いてしまおうと思う
    • 翻訳はコツコツ
    • 監訳の原著レビューを早めに終わらせて、早く監訳プロセスに入れるよう企画を通す
  • FP業の展開
    • 今年は一切できなかったので、ファイナンシャル・プランニング関連でなにかしたい
  • 自作キーボード
    • お店の赤字の改善
    • 自分でキーボードの基板を設計する