ログやコードをissueに貼ったり誰かに送る時は、画面キャプチャではなくテキストデータで扱うと便利

Twitterを見ているとサポートにおけるログのスクショの話で盛り上がっていた。サポートの文脈ではないが、チケットやissueにログやコードを貼り付けるときにはキャプチャじゃなくてコピー&ペーストしてテキストで残す方がいいよという話を最近社内で見かけた。そこで、なぜキャプチャではなくテキストで扱うと便利なのか書いておく。

テキストで残っていると、後から検索できる。検索できるというのはすごく便利で、過去に同じことが起きていたかどうか分かる。ログのキャプチャだと基本的に検索はでき図、せっかくチケットとして記録しているのに活用できなくなる。

内容をコピーできるのも便利。特に、ログにはエラーメッセージそのものやバックトレースなど、様々な情報が記録されている。必要に応じてソースコードを調べたりするのだけど、その時ログの内容をコピーできると多少楽できる。キャプチャだと画像上の文字を読んで打ち込む必要があり、なかなか骨が折れる。

このような「データをどう取得して保存するか」という動きは普段からやっていないとなかなかできないし、蓄積されると後からいい方向にも悪い方向にも効いてくる。テキストで保存していれば5年前のログだろうと見つけられるが、画像だと5年分のログを調べるのは非常に困難だろう。画像キャプチャの方が楽かもしれないが、あえてコピー&ペーストしてテキストで残す、という習慣を身につけておくと長期的に何かと便利なのでおすすめ。

1ヶ月SNS断ちしてみた

SNSを見ないようにしてみて、そこから1ヶ月経過した。見ないようにしてといっても、ミートアップの時にはハッシュタグを眺めたし、DMでのやりとりはしていた。

フォローの整理やキーワードミュートである程度摂取する情報を制御できるが、それでも目にしてウッとなるツイートは多く流れてくる。必要以上に感情的なツイートは見たくないんだけど。SNSを見ないとそういうものから離れられて精神的には非常に良い。しかし、現在の状況だとSNSをやらないことで他者とのコミュニケーションがガッツリ減る側面もあるので、そこは難しい。個別に連絡を取る間柄の関係の人があまりいないので、SNSを見ていないと世界から取り残されているような錯覚を最初は感じた。2週間くらいで気にはならなくなりSNSを見たい気持ちも薄れたが、長期的には孤立に繋がりそうだなーという気がしている。

SNSを見なくなったことの弊害としては、時事ネタが本当にわからなくなるということだった。元々テレビや新聞でニュースを見るという習慣がなくなっていたので、SNSを見なくなると本当にニュースを見なくなってしまった。ワイドショー的な情報を取り込みたくないだけで必要なニュースはチェックしたいので、NHKラジオニュースのPodCastを聞くようになった。BGMとして流しているけど、注目度の高いニュースは何回も報じられるので自然と頭に残る気がする。

追いかけているカテゴリーの最新情報のチェックができなくなるのも厳しい。自分が関心のあるカテゴリーの第一線で活躍している人も多くフォローしている。SNS経由で入手する情報が結構多かったのだなということがわかった。

というわけで、ゆるっとSNSに戻るかなあと考えている。よりミュートを活用していかないとなー。

issueからはじめよ

とは著名な知的生産に関する書籍の名前だが、日々の業務でもissueを作ることからはじめると結構いい、という話。


例えば、何か質問する時。Slackでおもむろに聞いても全く問題はないのだけど、一度issueに落とし込んでから質問することで解決までの時間短縮に繋がったり、後々助かると思っている。質問する時にまずissueを作ることで、情報を整理してこれまで調べたことをまとめられる。また、issue上に調査内容も追加されていくことで調査内容が被ることも防ぐことができる。issue上に時系列に調査内容が追加されるので今どういう状況か、も認識しやすいだろう。また、issueとして残すということはストック情報として残るということ。半年後に同じような困りごとにぶつかった時、issueを検索することで問題解決の手助けになるだろう。Slackでも検索はできるが、すぐに解決しなかった場合情報が散乱することがある。

何か調べる時、オペレーションする時にもまずissueを作るといい。issueを作ることで何を調べて、何をゴールとするのかを整理できるだろう。僕の場合、思いつきで調べ始めてしまって「何が目的だっけ?」となることがある… Slackなどに調べたことをどんどん書いてもいいのだけど、やはり後から検索するにはあまり向いていない。issueだと過去に調べたことも残るので、記憶力が悪い自分には向いている。

結局はケースバイケースなので、全てのケースでissueを作る必要はないだろう。長引きそうなら一度issueにまとめてからそっちで再開するというのでもいい。フロー型のツールとストック型のツールを使い分けて情報をうまく記録していくことが大事である。

Kubernetes Meetup Tokyo #31で「入門!ClusterAPI」というトークをした

Kubernetes Meetup Tokyo #31 で「入門!ClusterAPI 〜k8sクラスターもk8s APIで管理したい〜」というトークをした。スライドは以下。

セッションの後にsli.doを使った質問に何件か答えたのだけど、時間の都合上回答できなかったものが2つあったのでこちらで回答。

[ClusterAPIについての質問] ClusterAPI用のリソース管理ってどうしてますか?

Anonymous

ClusterAPI用のリソースというのがいわゆるマニフェストと仮定すると、他のk8sマニフェストと同じ様に管理すれば良いと思う。結局はyamlファイルなので、同じノウハウを使うことができる。

clusterAPIはclusterのバックアップについても面倒をみますでしょうか

Anonymous

クラスターのバックアップについては、ClusterAPI自身は面倒をみない認識でいる。Workload Cluster、Management Cluster共にVeleroの様なバックアップ専用のソリューションを使うのが良いかと思う。

さて、今回はオンラインでの登壇だったのだが、初めての体験で緊張した。

  • 聴衆の顔が見えないので雰囲気が掴みにくく、トークのペース調整が困難
  • 今回はモニタ2枚で片方に共有用の画面表示、もう片方に発表者ディスプレイを表示したのだが、これだと運営側とのやりとりが完全にできなくなることに発表中に気づいた。チャットなどで何か話しかけられていても気づけなかったかもしれないので、発表者ディスプレイは表示しない様にするなど対策が必要だろう。
  • sli.doを使った質問の仕組みはとてもよかった。これまでの登壇で、一番質問をもらったかもしれない。嬉しい。その一方、質問内容について質問者に確認できないので適切に回答できたかどうかが掴みにくいという課題は感じた。

いくつか課題は感じたものの、概ね体験としてはよかった。自宅にいろいろ設備を整える必要があるのでハードルはやや高いが、場所を選ばずミートアップに参加できるのは良い。他の方のトークもとてもよかったし、楽しかった!

Sidecarを使い、Keynoteの作図をApplePencilで行う

Keynoteの作図をマウスやトラックボールでやると手首や指への負担が大きい。微妙なサイズ変更や移動も疲れる。どうにか楽にできないかと思い、Sidecarを使ってiPad ProにKeynoteを表示し、Apple Pencilをマウスとして使うというのを試してみた。

オブジェクトの選択など、結構やりやすい気がする。文字入力する時にiPadを見ながらキーボードを入力する必要があり、首が疲れるのが難点だが作図する分にはマウスやトラックボールより楽なのではないかと思う。12インチならもっと快適だったかも。