nagu log

忘れないために

入門 監視のおぼえがき

f:id:csnagu:20191007224613j:plain
入門 監視

はじめに

Mike Julian 著、松浦 隼人 訳な『入門 監視 ――モダンなモニタリングのためのデザインパターン』を読んだおぼえがき。

そもそも『入門 監視』を購入するに至った経緯についてだが、2019年の下期からログのプラットフォームを運用するチームに配属となった。この時点では「ログや監視まるでわからん」といった感想しか持っていなかったため、流石に「これはいかん」となり、少し前に自分のTLで話題になっていた『入門 監視』を読み始めた。

入門 監視を読んでみて

『入門 監視』は、監視ツールに依存しない監視の基本だったり、なぜ監視するのかといった、基本的な部分を丁寧に解説してくれている。
監視のアンチパターンからデザインパターン、ビジネスKPI・フロントエンド・アプリ・サーバ・ネットワークなどコンテンツがたくさんあるが、各章では「何を、なんのために、どのように監視するのか」がまとめられていて非常に良い内容だと思う。

そのため、自分のような「どんな背景があってXXXを監視しているのか」「そもそもなぜ監視するのか」といった基本的な部分を補うのに最適であったように思う。

また、OSSの監視ツールがある中で、商用のSaaSを利用する理由やメリットなどは納得感があったし、業界や企業側の世界観がいまいちつかめていなかった自分としては学びが多かったように思う。ロギングや監視といった主軸のコンテンツからは若干逸れるが、OSSを採用するか商用SaaSを採用するかは、安定稼働までのコストや機会損失、セキュリティ面などを総合的に判断しなければいけなく、必ずしもOSSバンザイな姿勢ではいけないことを学んだ。

その他にも、運用に関する手順書を作成するのは作業途中に人間の判断が必要な場合だけにして、ログやメトリクスを監視することで積極的に自動化してしまおうといった話題は面白かった。

最後の章には総まとめの例題がある。フィクションのコンサルタントを例に、本書を通して学ぶ「何を、なんのために、どのように監視するのか」を確認させてくれる内容となっていた。全体を思い返すのに非常にいい構成だったと思う。

もう少し実務を積んでから読み返すことで新たな気付きがありそうな気がとてもしている。定期的に読み直していきたい。

www.oreilly.co.jp

テスト駆動開発のおぼえがき

はじめに

Kent Beck 著、和田卓人 訳な『テスト駆動開発』を読んだ覚書。
タイミングが良いことに、仕事先のお試しプロジェクトをテスト駆動開発で進める機会があったので、これについても感想を綴ります。

f:id:csnagu:20190901182625p:plain
テスト駆動開発

テスト駆動開発とは

  • Red→Green→Refactorを小さいステップで高速で回す
    • Red ... 書いたテストを実行してレッドバーの表示を確認する
    • Green ... とりあえずテストが通る形で実装する
    • Refactor ... 引数で取得できたり、柔軟に変更できる箇所をリファクタリングする
  • ブラックボックステストを仮定して、投入するものと期待する結果を考える
    • やりたいことを明確に表現できる
  • 実装ではなくテストから先に考える
    • 開発をシンプルにすすめることができる
  • テストを書く理由

個人的に大事だなと思ったのはこんなところ。

特に、やりたいことを最初にテストで表現する、という部分に惹かれた。
実装の前と後に書かれるテストは中身が変わるのかなと思った。というのも、実装後に書くテストはホワイトボックステストになりがち(だと思う)だが、、実装前にテストを書くことでブラックボックステストになりやすいと思う。
その結果、内部の仕様を変更したとしてもテストがコケにくくなり、テストの保守に労力をあまり割かなくて良くなるのかなと感じた。

あとはRed, Green, Refactorを小さいステップで回すことで目標に向かって柔軟に実装できるという箇所が読んでて「素晴らしい…」ってなるポイントだった。

テスト駆動を実施してみて

ここまでは本で読んで「こういうことかな〜」という話。
ここから先は1ヶ月に満たない短い期間でテスト駆動開発を実際に導入してみてのオハナシになります。

実際に導入してみるとなかなか理想通りにはできなかった。
うまくいかなかった事例としては以下の通り。

  • テストで担保するべき最低ラインで意見が割れる
    • そもそも個々人でテスト力がバラバラなので当然
  • Red, Green, RefactorのRedは意識しないとすっ飛ばす
  • 「あれ、これはスモールステップではない...?」
  • テスト駆動のハズが、「こんな感じでは?」と話しているうちに実装が終わってしまう
  • テストがホワイトボックステストっぽくなる

そもそも本読んだだけで、1ヶ月の間で初テスト駆動開発というのは無理があった。
とは言うものの、やってみるとテストのありがたみの片鱗を知ることができたのでいい経験になりました。

AWSボタンを使ってGitHub Contributions風の草を生やしてみた

はじめに

GitHubに草を生やしていくとやっている感があっていい。
自分のGitHubページにアクセスして進捗草が生い茂っていたら「今日も頑張るぞい」ってなるに違いない。
何かをやったということが視覚的にわかるので、自己肯定感もアゲアゲなはず。

こんなふうに、毎日たくさんの進捗草に囲まれていたら、きっと人生楽しくなっちゃいますね。

というわけで、AWS進捗ボタンを利用してGitHub風の芝生を作ってみました。

実際に生えてくるのは青い草です。
青臭いという自戒と、草青むという希望を込めて

動機

  • APIサーバという概念を仕入れたからなんか作ってみたい
  • そういえばAWS進捗ボタン使ってない…そや、再利用しよう
  • GitHubの芝生が枯れてる…人生の進捗はコードだけじゃないはず
  • AWS進捗ボタンはPythonでデータ処理しているからAPIサーバはflaskで作る
  • heroku使ってみよ

こんな動機で出来上がったアーキテクチャ図(作ってみたかっただけ)

f:id:csnagu:20190629150942p:plain
なんちゃってアーキテクチャ図 icon by https://icons8.jp

  1. GitHub Pagesで運用している https://naguu.info へアクセス
  2. herokuで動かしているflask製のapiサーバへGETリクエストを飛ばす
  3. apiサーバが S3 から記録データを取得
  4. apiサーバ内でデータ処理してjson形式でreturn
  5. jsでヒートマップカレンダーとして出力

どんなもの

実際に使っているのがこんな感じ。

f:id:csnagu:20190629145716p:plain
青い芝のdemo

ヒートマップカレンダーはDKirwan氏のcalendar-heatmapをほぼそのまま利用しています。
便利。

github.com

なんちゃってapiサーバの実装はgistを参照。

現状の課題や未来の自分へのTodo

  • naguu.info/ へのリクエストごとにAWS S3からcsvファイルをダウンロードしているから表示が遅い
  • flask製のAPIサーバではGETのたびにデータに前処理を施しているから遅い
  • AWS進捗ボタン側のデータを使ってcontributions毎の時間をグラフで出したら面白いかも
  • ヒートマップカレンダーの実装が人に頼り切り

良い感じの実装方法などあればコメント等で教えてください!

TodoistとTrello、2つのタスク管理ツールの使い分け

はじめに

個人的なタスク管理ツールは主にTodoistとTrelloを使っている。
「シンプルでタスク完了とともにリストからタスクが消えるTodoist」

「タスクをtodo/doing/doneと分けられるTrello」
とでそれぞれ使う方針がだいたい固まってきたため、現在の使い分けをできるだけ具体的にメモしておく。
他にもこんなツールあるぜ!こんな使い方いいぜ!っていうのは教えてほしい。

Trelloではタスクのことをカードって呼んでるので、ここではタスクに統一する。

Todoist

良かったところ

  • UIがシンプルでスッキリして見やすい
  • PC・スマホタブレットどれから閲覧してもほぼ同じように操作できる
  • こなしたタスクはリストから消えていく(実際にはログに残っている)
  • 毎日/明日/3日毎 などで同じ内容のタスクを勝手に作ってくれる機能がある
  • Amazon Echoと連携できる

イマイチなところ

  • タスクに日付を指定しないとインボックスやプロジェクトの中で埋まる恐れがある
  • コメント機能がプレミアムユーザのみ
    • しかもそんな使い勝手がよくない

こんな理由からTodoistは「ぱっと見て理解できる」「時間がかからない軽いもの」「ある日付のみ実行する」タスクを登録するようにしている。
例えば週末の掃除は「毎週日曜日 シンクの掃除」として登録する。すると掃除のリストが出来上がる。実行した掃除項目から手軽に消せるため、残りの掃除箇所がどこかも把握しやすい。
他には「5/23 サイクリング」といった、ある日付のみ実行するものを登録する。
また、Amazon Echoと連携できるので思いつきのメモをとりあえず残しておけるのも◎。

逆に相性が悪いな〜と感じたのは、課題やレポート提出のような「ある日付までに継続的に取り組む必要があるもの」。
それとタスクを分解して小タスクに分けていくのも個人的には使いにくいな〜と感じている。
複雑であったり、重ためなタスクはTrelloのほうが管理しやすい。

Trello

良かったところ

  • リストやボードを使い分けれるので自由度が高い
  • doneリストが増えていくと嬉しい
  • タスクごとに説明やコメントなどの詳細を記述できる
  • Hello Epics(プラグインのようなもの、有料)がタスクの親子関係や全体の進捗を明確にする

イマイチなところ

  • Chromeエクステンションがないと使い勝手が悪い
  • タスクの登録と完了が若干煩雑
  • タスクをソートできない

Trelloは「複雑な内容」「継続的に取り組む」タスクを登録するようにしている。
複雑な内容のタスクはより細かい作業に分割するのが定石である。Hello Epicsを使おう。
次に、継続的に取り組むタスクとして最近はじめた積読の消化がある。Hello Epicsを使おう。
画像で伝われTrello(Hello Epics)の力。

f:id:csnagu:20190511211005p:plain
trello + hello epics

Trelloの各タスクには説明欄とコメント欄があるため、本を読み始めた動機やモチベ、読書メモ等を書き込むのもいいだろう。
長い間doingリストに所属するタスクは理由をメモして、更に小タスクへ分割することもできる。

Trelloは以下記事にあるChromeエクステンション入れると使い勝手が異次元になる。
そのかわりスマホタブレットから閲覧したときは残念な気持ちになる。

qiita.com