@hihihiroroのLog

ダラダラと。本ブログは、個人の意見であり、所属会社とは関係がありません。

202401 振り返り

気がついたら1月が終わっていた。誰かに時間を盗まれていると思うので盗んだ人はこっそり教えて下さい。
RSGT に参加ができたがトラブル対応と他のイベントが重なってしまい、全部にいれたわけではなかったのが残念。

お前太り過ぎだぞということでRIZAP と会社のおかげで面談とかさせていただいています。レコーディングをしていると明らかにどう見ても食べすぎだろって思っているので、バクバク食べてしまう理由を考えるところからかなと思っている。

べんきょうかい

年が明けたということはRegional Scrum Gathering Tokyo が開催される時期。今年分も無事にチケットを買うことができたため参加ができた。しかし、今年は色々あってスタッフができなかったので初めての一般参加を行っていた。発表を聞くよりも、参加者の方々と話す時間が多かったけど面白かった。これから、発表はビデオで見ていくぞ。

データアーキテクチャはものすごく興味があったのに、当日すっかり忘れていて終わってから気がついてしまった。
失敗した〜。

ほん

正月と新幹線での移動時間で少しだけ本を読む時間が増えた。
映画に行かなくなった分は少しでも本を読む時間を増やしていきたいなと思っている。
勉強をすることを続けているからどこ行っても大丈夫だよと言われたので、それをやめないようにはしたい。

えいが

久しぶりに映画を観に行った。やっぱり大迫力で映画館ならではの楽しみはあるもんだなと思った。
行かない時期が長くなってしまったので今までほどの頻度では行かないだろうけど、ちょこちょことは行くようにしたい。

ぶろぐ

どれもこれも面白かったな。
認知的負荷はどこにでも影響を与えていることが多いと思うので、他の本も読んでみたいな。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「プログラマー脳」を読んだ

自分がコードを書く割合と人が書いたコードを読んでレビューする割合がだいぶ偏ってきた時に、自分ってコード読むの遅くないって思うことがあった。
その時に見かけたので読んでみることにした。

目次は以下

Chapter 1 コードをよりよく読むために
Chapter 2 コードを速読する
Chapter 3 プログラミング言語の文法を素早く習得する方法
Chapter 4 複雑なコードの読み方
Chapter 5 コードの深い理解に到達する
Chapter 6 プログラミングに関する問題をよりうまく解決するには
Chapter 7 誤認識:思考に潜むバグ
Chapter 8 よりよい命名を行う方法
Chapter 9 汚いコードとそれによる認知的負荷を避けるための2つのフレームワーク
Chapter 10 複雑な問題をより上手に解決するために
Chapter 11 コードを書くという行為
Chapter 12 より大きなシステムの設計と改善
Chapter 13 新しい開発者のオンボーディング

コードの理解をする際の混乱について本書では以下のように紹介されている。

  • 知識不足 = 長期記憶の問題
  • 情報不足 = 短期記憶の問題
  • 処理能力の不足 = ワーキングメモリの問題

それぞれが相互作用しながら機能している状態を認知プロセスとして説明されている。
短期記憶は2〜6個の要素を保持できるとされており、この容量制限を克服するためには短期記憶と長期記憶が協調して理解をしようとする。長期記憶にない十分な知識がない場合は、文字やキーワードなどわかりやすい単純な情報に頼り、短期記憶の容量が足りなくなってしまうとのこと。単純な情報ではなく、抽象的な概念として記憶するためには、長期記憶に十分な関連情報を溜め込んでおく必要がある。
長期記憶に貯めるためには文法を理解し記憶することで関連情報同士がネットワークとして保存され、新しい情報が入ってきてもそのネットワークに繋がることで、思い出すことが容易になっていくことが大事と紹介されておりなるほどと思った。

ワーキングメモリが処理できる量の限界を超えることを認知的負荷と呼んでいる。認知的負荷が大きいと、コードを適切に処理することができなくなる。
認知的負荷を下げるために、作業内容を考えなくてもわかるようにコメントを書くや、名前からすぐに推測できるようわかりやすい名前を変数や関数につけるということは納得感があった。確かに名前と処理が揃ってないと、まずは流れを追うことを考えてしまうので理解への処理がすすまなくなるなと。

後半では理解しやすいコードを書き、曖昧な名前や怪しいコードの臭いを避けるにはどうしたら良いかの方法について説明がされている。
理解しやすい名前とは何かを考え、ルールが紹介されていることで品質の高い名前をつけるためにはどうやって考えていくのが良いかが紹介されている。その後では、理想的ではないコードはどういったものかという、これがあったら怪しいと思ったほうが良いというこれまた法則が紹介されている。それぞれになるほどと思うことがあるのでぜひとも調べてみると面白いなと思った。

最後の方では認知的負荷の説明から問題解決やオンボーディングのプロセスについても書かれている。タスクを行っている時や新しい知識を身に着ける時に何を気にするべきかが説明されており、これから新しい人が来た際の説明をする際には気をつけてみようと思った。

まとめ

  • 認知的負荷はコードだけではなくどんな仕事にでも関わっていそうだなと思ったので引き続き勉強してみたい
  • 今まで読むことに時間がかかったコードを再度読んで修正しておけるところは修正しておきたい
  • 長期記憶にもっと溜め込んでおくようにするため勉強は続けよう

#RSGT2024 に参加してきた

今年はスタッフではなく参加者として参加してきた。

ただ、トラブル対応やプライベートな用事などであまりいることができなかった。
セッションとしてはkyon_mm のセッションをお手伝いするために発表の時間中全部いたけど、まともに参加したセッションはこちらと、1日目最初のKeynote のみかな。

それ以外だと縁の木さんのコーヒーを配ったり、廊下にいて通りかかる知り合いとお話をしているだけだったけど、その話はどれもこれも面白かった。
CI/CD 環境は複雑に管理したくないとか、自分がなんだこれって違和感を感じる勘を他の人が同じことができるようになるためにはどのような教育をしていくべきなのかとか、最近どんな開発をしているのかとか、どんな技術に興味があるかとか。
これからデータ領域で働きたいという学生の子と、情報交換をしたりとかもした。きっとジョブボードにデータ基盤やっているということを貼ったから話しかけてもらえたのかなと。仕事は見つからなかったけど、学生との話は面白かった。

スタッフをやらずに参加したのは初だったのでどうやってみんな過ごしているのかなと思っていたけど、真面目にセッション出て話を聞いている人たちが多くて、それはそうだなと思いながらも、人が少ない間にスポンサーブースの方々や僕みたいにブラブラしている参加者、スタッフの方々などとお喋りができたので満足できた。

セッションはこの後ビデオをきっと公開していただけると信じ、そちらでゆっくり見させていただこうかと思っています。

来年は全日参加したいなー。
そして人の名前をちゃんと覚えるんだ。

まとめ

  • 楽しい場を作ってくださっているスタッフ、参加者の皆様ありがとうございました
  • スタッフやってないと何してようかなと考えるんだとわかった
  • 来年もチケット争奪戦頑張るぞ

「クラウドアプリケーション 10の設計原則」を読んだ

レビューすることも多いし、何が正しいのだろうと考えることもたくさんあるので読んでみようとおもった。

目次という名の原則は以下。

第1章 すべての要素を冗長化する (Make all things redundant)
第2章 自己復旧できるようにする (Design for self healing)
第3章 調整を最小限に抑える (Minimize coordination)
第4章 スケールアウトできるようにする (Design to scale out)
第5章 分割して上限を回避する (Partition around limits)
第6章 運用を考慮する (Design for operations)
第7章 マネージドサービスを活用する (Use platform as a service options)
第8章 用途に適したデータストアを選ぶ (Use the best data store for your data)
第9章 進化を見込んで設計する (Design for evolution)
第10章 ビジネスニーズを忘れない (Build for business needs)
付録A 守りは左から固める
付録B 目的別参考ドキュメント集

はじめにで、ベストプラクティスとは何かと言う話から始まっているのが面白い。これが正しいからこれに従えというのではなく、知見であるのでそれに盲目的に従えば良いわけではないことが書かれている。原則を理解することで、効率的なプラクティスの吟味ができるようになると言って、10の原則が紹介されている。
Azure のサービスが少しは紹介されているが偏った話はほぼなく、他のクラウドだろうとオンプレだろうと使える話がたくさん書かれているのでどの環境を使っている人でも読んで役に立つと思う。

読んでいてよく出てくる話は冪等性の担保、疎結合だったと思っている。何回でも実行できるよう作成されていれば、エラー対応などについても考えることが少ないのはそのとおりなので、これからレビューをするときはまずはこのあたりを見るようにしようと思った。
また、運用を考慮した作りにすることが原則として入っていて説明されているのと、ビジネスニーズを忘れないが原則として入っているのがとても良いことだと思っている。ただ、アーキテクチャとして良くするわけではなく、使い改善し続けることが考えられることは本当に必要なことだと思う。ビジネスニーズも、お金に見合わないものを作ってもしょうがないし、誰も欲しがっていないものをいつまでも頑張って面倒みる必要はないので、忘れてはいけないことだと思っているので頷きながら読んだ。

原則の1つとしても入っているし、データストアについては知識を深めたいなと思った。

まとめ

  • ベンダー依存ではないので、どこで動いているシステムについてでも反映できるので自分たちのシステムを見直したい
  • 短い原則になっているので覚えやすい
  • とはいえすぐに忘れるだろうから見直しやすいところに置いておこう

「クラウドネイティブで実現する マイクロサービス開発・運用 実践ガイド」を読んだ

アプリケーションに関わることを忘れないために読んでみようと買ってあったので読んでみたが面白かった。

第1章 マイクロサービス概論
第2章 マイクロサービスの実装
第3章 サンプルアプリケーションへの非機能の実装
第4章 マイクロサービスにおけるデータ管理
第5章 マイクロサービスのテスト
第6章 マイクロサービスのためのCI/CD設計
第7章 マイクロサービスアプリケーションにおけるCI/CDの実装
第8章 発展的なCI/CD戦略
第9章 マイクロサービスの信頼性を支えるオブザーバビリティ
第10章 マイクロサービスの実践プラクティス
第10章 マイクロサービスの今後

1章でマイクロサービスの説明が始まっている。マイクロサービスについてのまとめとして読んでも面白いので読み込んでしまった。体制の話やよくある質問があって、とても面白かった。また、10章ではマイクロサービスの勉強会を開くために、体型知識としてまとめてみるという設定での説明になっていたので、まとまっていて読みやすかったように思う。

また、2から5章までは実際のコードをいじりながらの説明となっていて動きを試してみることができて面白かった。フロントエンドとか普段書くこともないのでただ、少しいじるだけだとしても久しぶりに触って動くところを確認できたのは面白かった。Kubernetes の扱い方や、テストについても記載があるのでアプリケーションを一通り作っていくことが体験できるのは良いなと思った。

また、6から8章はCI/CDについてずっと書かれている。必要なことはわかっていて、なんとなくやることをやってはいるはず。だけどこれを読むとまだまだ足りてないし、やっているということも遅いのでできてないなと思ってしまった。自分たちのシステムについての見直しをしてかないとなと思った。

去年にちょっとだけ勉強したオブザーバビリティについても記載がしっかりとされていた。そのときにもまだまだできてないなと思ったが、今回読み直してみてまだ何も改善してなかったなと思った。
今回読んでみて思ったのはどれもあまり初めましてではなく、復習として読めてサクサクと読むことができた。400ページ超えではあるが、実装部分だったり知っている部分だったりすることがあるだろうから時間をあまり書けずに読めることができたので良かった。

まとめ

  • 復習として読み進めることができて面白かった
  • 自分が人に必要性を説明するときにはどうするだろうと考えながら読めた
  • 自分のシステムで全然できてない部分を少しずつでも改善していきたい

「データ保護完全ガイド」を読んだ

データを扱う仕事をしていることもあり、タイトルが気になったので読んでみることにした。

本書の目次は以下。

1章 データへのリスク:我々はなぜバックアップするのか
2章 SLAを決めるまでにすべきこと
3章 バックアップとアーカイブは全く別物
4章 バックアップとリカバリの基本
5章 データ保護にディスクと重複排除を使う
6章 従来型データソース
7章 データベースを保護する
8章 最新のデータソース
9章 バックアップとリカバリソフトウェアの方法
10章 アーカイブソフトウェアの方法
11章 ディザスタリカバリの方法
12章 データ保護ターゲット
13章 商用データ保護製品の課題
14章 従来型データ保護ソリューション
15章 最新データ保護ソリューション
16章 バックアップシステムのリプレースまたはアップグレード

バックアップをする理由なんて考えることなく、なんとなく必要だからという思いだけで取っている気になっていることが多かったと考えさせられた。
本書ではバックアップとアーカイブの違いが紹介されている。僕がやっていたのはバックアップではなく、本書で紹介されているお手軽コピーをやっていたんだなと思い知った。

バックアップとは、オリジナルから離して保存され、オリジナルが何らかの理由で削除または壊れた後に、そのデータを以前の状態に戻すために使われるデータのコピーと紹介されている。
アーカイブとは、離れた場所に保存されたデータのコピーで、参照用コピーとして使われるために作られ、そのデータの出どころを知らなくても、当該データが見つけられるだけの十分なメタデータとともに保存されたものと紹介されている。

また、バックアップの基礎となるべき基本のルールとして 3-2-1ルールが各所で説明されている。
3-2-1ルールとは、少なくともデータの3つのバージョンを2種類のメディアに保存し、そのうちの1つは別なところに置くべきというルール。確実にバックアップからのリカバリができることを考えるとそうなのだろうなと思う。そう考えると、今まで僕がバックアップとして考えていたことはそもそもバックアップするべきものでもなかったなと考えることができた。
リストアを試すことがあたりまえのように紹介されているが、いままでバックアップされているファイルなどでリストア試したことあると聞いたことがあまりなかったので、戻るところまで試すようにちゃんとしようと思った。

面白かったのはバックアップレベルについての話。名前は知っているが、あまり実践したことは無いので再度勉強できて面白かった。また、同じ章にデータ保護システムの設計の際に必要となる指標として目標復旧時間(RTO)、目標復旧時点(RPO) の説明がされている。実績と合わせてこれらの値をシステムにあう値として決めることで、必要なバックアップの要件を決めていくという当たり前のことが紹介されている。しかし、やってないことばかりなのでシステム設計するときには当たり前のことをやっていかないとなと思った。

まとめ

  • バックアップかアーカイブかなんて考えてなかったなと反省した
  • クラウドSaaS、Docker、Kubernetes、IoT についてのデータ保護についても説明があったので再度読み直してみたい
  • そもそもバックアップが必要なのかどうかから見直すことをやってみたい

202312 振り返り

飲み会にいくつか参加できた。
くだらないことや真面目なことを話すことができてやっぱり楽しいものだなと思った。これからもできるだけ参加できるようならば飲み会には参加していきたいなと思った。ビールが最後の方はあまり飲めなかったから来年はまたビールを飲みに行きたいな。

なにか頑張ったなと思うようなことをやっていきたいと思う。

べんきょうかい

何も行かなかった。
そろそろサボらず行かないとなと思っている。

ほん

電車の移動時間があるのでもっと読めるかと思っていたのだがだいたい眠ってしまっていた。それでも積読をいくつか消化し、買った本も読むことができたので良かった気がするが、こうやって見ると漫画買いすぎだなーと。

えいが

今月も1つも観に行くことはなかった。
映画を観ないことに慣れてきてしまったな。

ぶろぐ

ゆっくりとだが本を読み終えることができたので気になった本については感想を書けた。
正月にも何冊か書くぞ。

hihihiroro.hatenablog.com hihihiroro.hatenablog.com