@hihihiroroのLog

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

202402 振り返り

引き続きレコーディングダイエットをしている。わかってはいたけど実際につけてみると本当に食べすぎていることが多い。
そしてこれくらい大丈夫だろと思っているものがカロリーや糖質高いことがわかることが多くびっくりする。
でもせっかくなので頑張って続けてみよう。

本格的に副業をしてみたいと思っている。でも自分が何できるかわからないのでどこかでお仕事ありそうな方はぜひ話しかけていただいたり、ご飯や飲みに誘っていただければと思います。

べんきょうかい

所属会社でもTech Conference が始まりそちらの大半を見ることができた。前職もそうだが大きい会社なので、隣が何を使っているかなどわからないためとてもおもしろく見ることができた。
Platform Engineering Meetup では永瀬さんによるちいとぽの話を聞いて全く覚えてなかったので再度読もうと思った。

Platform Engineering Meetup #7
大公開!SUUMOの裏側~データ組織の取り組みLT会
PdM Days
RECRUIT TECH CONFERENCE 2024

ほん

わかっている。わかっているのだが積読本よりも新しく本を買ってしまいそちらが先に消化されていく。
時々積読の中で下の方にいる本から睨まれている気がしているのでそろそろ読みにいかなくては。

えいが

結局観に行くことがなかった。
みたいものはいくつかあるので来月はどこかで時間を取って観に行く。

ぶろぐ

今月は3連休が2回あったからか本がよく読めたなと思っている。
そのため感想も書くことが多くできて良かった。

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

link.medium.com

hihihiroro.hatenablog.com

hihihiroro.hatenablog.com

「実践データマネジメント」を読んだ

データ基盤の運用を行っているがあまり求められることを言われないので、今ってどういうことが必要なのかなと思うことが多い。見かけたので読んでみることにした。

目次は以下。

第1章 データ活用のための人と組織
第2章 データ活用のための環境整備
第3章 データ活用のためのデータ管理
第4章 データ活用を進める際の課題

最初の方はデータ基盤の作成方法やそれらの製品についつての説明などが多かった気がする。データの連携などについてはそれぞれのサービスに合わせた速度、頻度などが求められているものだと思う。別に一日1回でも困らない分析もあると思っている。事業データ側もどこか一回での閉じたデータが必要なモニタリングが必要だったりするかもしれないし、即時に連携してユーザへのレコメンドなどの精度を求めなければいけないものもあるだろう。どのようなデータが求められているかを見極めて連携をすることがまずは大事だろうなと思う。

連携されたあとのデータを使う場合に、元データまでを見にいくのは面倒なことが多いので分析基盤の近くにどのようなデータかがわかるようになっていることが大事だと思う。その際にカラムごとにどのようなデータが入ってくるものなのかをうまくデータソース管理者とうまくやりとりできる仕組みが必要だと感じている。しかし、自分の所属が今だと横断ということもあり遠いなと感じることが多くてもっと食い込んでいかないといけないなと思っている。

最後の章にあったがガバナンスを効かせるのにボトムアップなのかトップダウンなのかという話が少し書かれている。ガバナンスやセキュリティをボトムアップでやると強制力の付け方や、それぞれのやりたいところへの注力などになってしまい本当に守るべきところが守れているかわからないことが出てきてしまうと思う。そのためには一定トップダウンの強い力が必要になってくるだろうなと思う。ぜひとも偉い人たちにはこのあたりを考えてもらえると良いなと思っている。
がちがちになってしまうと使いにくくなってしまうのだろうからうまい具合のガードレールで防げるようになっていると良いんだろうな。

またデータ基盤を使ってもらうためにも、エラー率などはちゃんと出さないといけないなと思っている。SLO がなくても使ってもらえているが今後もっと利用を増やすことができるようにするためには必要だろうな。

まとめ

  • DMBOK を再度読む必要があるということを理解した
  • データマネジメントについての話は多くなかったな
  • まだまだやるべきことはありそうなのでお仕事しよう

「実務で使える メール技術の教科書」を読んだ

実は今までの社会人人生の半分はメールに係る部署で働いていたこともあり、メールの技術については少しは興味があるので読んでみることにした。

目次は以下。

第1章 メールが相手に届くまで
第2章 送受信に使われるプロトコル
第3章 メールサーバーの構築と DNS の設定
第4章 ファイルの添付と HTML メール
第5章 スパムメールを防ぐ技術
第6章 メールの暗号化と署名
第7章 メーリングリストメールマガジン

メールはいろいろ幅広い機能を使うことが多く、それぞれを調べていくととてもやりたいことを探すだけでもとても時間が掛かってしまう。たとえばメールを送るサーバについて調べようと思うとLinuxSendmail の勉強、ドメインやIP アドレス、認証情報についてでDNS 、暗号化や認証、ウイルスなどについてだとセキュリティについての勉強などが必要になる。しかし、それぞれの専門書だと詳しく書かれているがメールについての何かがどこなのかというのは分かりにくいこともある。
本書ではメールで必要になる技術について、幅広く記載がされている。ここから気になって深掘りしたくなったらそれぞれの専門書をさがしにいくことで、無駄な時間をかけずに勉強をしていけるのではないかと思う。

今は自分でメールを送る部分には関わらなくなったのであまり最新の情報を追ってはいない。でも、部署に配属されて最初に日報を送る際に telnet コマンドでメールを送る勉強をさせられたりしたおかげもあるのか、いまだに忘れてないものだなと思った。知識がいまだにあったっぽいので読み終わるのにはそれほどかかることがなかった。

最近だと2023/10 にGoogle からメール送信者のガイドライン がでたこともありメールの送り方について考えている会社が増えている気がする。そのあたりで困っている人たちの手助けなにかしながらお金稼ぐことできないかなーと思ってみたりもした。

まとめ

  • メールで使われる技術についてまとまっていて読みやすかった
  • それぞれが詳しく書かれているわけではないので気になったところはRFC などを読みにいってみたいと思う
  • メールはなくなることもないだろうから情報収集は変わらずやっていこう

「スケーラブルリアルタイムデータ分析入門」を読んだ

ずっと前に買っていたが読んでなかったので、今更ながらラムダアーキテクチャについてちゃんと読んでみようと思って読んでみた。

目次は以下。 

1章 ビッグデータを扱うための新しいパラダイム
2章 ビッグデータのためのデータモデル
3章 ビッグデータのためのデータモデル詳説
4章 バッチ層のデータストレージ
5章 バッチ層のデータストレージ詳説
6章 バッチ層
7章 バッチ層詳説
8章 バッチ層の例:アーキテクチャアルゴリズム
9章 バッチ層の例:実装
10章 サービス層
11章 サービス層詳説
12章 実時間ビュー
13章 実時間ビュー詳説
14章 キューイングとストリーム処理
15章 キューイングとストリーム処理詳説
16章 マイクロバッチストリーム処理
17章 マイクロバッチストリーム処理詳説
18章 ラムダアーキテクチャをより深く学ぶ

リアルタイムデータ連携についてはいまのところ作ることもないし、思想的なこともちゃんとみたことがなかったので読んでみたのだが、体系立てて書かれていて面白く読むことができた。

ローデータはとても大事なものとして存在しており、ローデータさえ異常がなければバッチ処理を何回やり直すことができるため、ローデータは死守する必要があることが説明されている。他にもデータが、重複なのか別データなのがわかるようにハッシュ値をつけて判別できるようにしておく。キューの仕組みを使ってのデータを更新する仕組みなども紹介されていて面白かったし参考になった。

それ以外にも集計時の概算アルゴリズムの説明や、バッチ層とサービス層、速度層のそれぞれの説明やそれぞれで使えるツールでの少しだけ具体的な説明などが書かれていてとても読みやすかった。ストレージについての話も書かれており昔のツールなどだとしても久しぶりなこともあり興味深く読むことができた。今でも使われているものもいくつかあるのでちゃんと理解をしたいなと思っている。

本書は、本当に広い範囲について詳しく書かれているなと思った。
一度読みすすめたくらいでは完全に理解できたとは言えないのでまた少したったら読んでみたいなと思っている。
その時にはカッパアーキテクチャ、その後のデータフロー、ビームモデルについてもまとめて読んでみたいなと思った。

まとめ

  • ラムダアーキテクチャの理論についての思想を読んでみた
  • 他のストリーム処理アーキテクチャとの違いを考えてみたい
  • 自分たちの基盤で必要となるものは何かと考えてはみたい

「ソフトウェアアーキテクチャメトリクス」を読んだ

トラブルが多いなとか、修正に思っているよりも時間かかると言われたりするなと思うことが増えてきたときに社内でタイトルを見かけたので読んでみることにした。

目次は以下。

1章 解き放たれた4つのキーメトリクス
2章 適応度関数テストピラミッド:アーキテクチャテストとメトリクスのためのアナロジー
3章 進化的アーキテクチャ:テスト容易性とデプロイ可能性でアーキテクチャを導く
4章 モジュール生成熟度でアーキテクチャを改善する
5章 プライベートビルドとメトリクス:DevOps 移行を乗り越えるためのツール
6章 組織のスケーリング:ソフトウェアアーキテクチャの中心的役割
7章 ソフトウェアアーキテクチャにおける計測の役割
8章 メトリクスからエンジニアリングへの進化
9章 ソフトウェアメトリクスを使用して保守性を確保する
10章 ゴール・クエスチョン・メトリクスアプローチで未知数を計測する

ソフトウェアアーキテクチャメトリクスとは本書では以下と紹介されている。

ソフトウェアアーキテクチャメトリクスとは、ソフトウェアの保守性やアーキテクチャ品質を計測し、プロセスの早い段階でアーキテクチャ負債や技術的負債の意図しない蓄積を警告するのに用いるメトリクス

p.v

1章ずつ別々のソフトウェアアーキテクトが、知っておくべきソフトウェアアーキテクチャメトリクスが紹介されている。それなので、体系的にまとまっているというわけではなく、実践者からの投稿をまとめているエッセイ集みたいになっている。

話題としてはFour Keys メトリクス、アーキテクチャ適応度関数、モジュール性成熟度指数などが紹介されていた。そしてそれらを使って組織の成熟度を測る方法やメトリクスを用いてアーキテクチャの品質向上に役立たせる方法についても記載されている。
メトリクスを定義しているだけではなく、ダッシュボードを作成し保守性を保っていくなどの話がありとても面白かった。

僕のところではまずは計測するための準備をし、計測してみる。計測できないならば計測できるようにまずは変更をしていく必要があるなと思った。
現在のうちのシステムは泥団子のものが大変たくさんあると思う。よく影響範囲やレビュー範囲を狭めるために分割したいなという話をしているが、それだけではただ単に小さい泥団子になってしまうなと。たしかに困っているのは分割されてないことではなくカオスさなので、まずはメトリクスを決めて取得し、そこから改善を考えていくのが良さそうだなと思った。

読んでいると進化的アーキテクチャでの話がたくさん出てくる。昔読んではいるけどあまり覚えてないなとなってしまったので、再度読み直してみるのが良さそうだなと思った。

まとめ

  • まずは古いシステムなので技術的負債についてのメトリクスを取ってみたいなと思う
  • これから作るシステムではメトリクスの取りやすさも考えながらレビューする
  • チーム一丸ですすんでいくためにチーム内に共有し浸透させたい
  • 進化的アーキテクチャ探して読むんだと思った

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個の要素を保持できるとされており、この容量制限を克服するためには短期記憶と長期記憶が協調して理解をしようとする。長期記憶にない十分な知識がない場合は、文字やキーワードなどわかりやすい単純な情報に頼り、短期記憶の容量が足りなくなってしまうとのこと。単純な情報ではなく、抽象的な概念として記憶するためには、長期記憶に十分な関連情報を溜め込んでおく必要がある。
長期記憶に貯めるためには文法を理解し記憶することで関連情報同士がネットワークとして保存され、新しい情報が入ってきてもそのネットワークに繋がることで、思い出すことが容易になっていくことが大事と紹介されておりなるほどと思った。

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

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

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

まとめ

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