msksgm’s blog

msksgm’s blog

Webエンジニアです。日々の勉強記録、技術書感想、美術観賞感想を投稿します。

2022年12月の目標

概要

12 月の目標です。

勉強関連

以下を勉強していきます。 勉強会を 3 つ抱えているので、勉強時間の確保と進め方を試行錯誤しながら進めます。

  • Kotlin
    • Akiyadego-kt の作成
    • 技術記事の作成
    • 「Kotlin in Action, Second Edition」を読む
    • 技術書の作成
    • 「Advent of Code 2022 in Kotlin」に参加
  • 設計

読書

上述の勉強関連以外では以下の本を読む予定です。

  • 「Git ポケットリファレンス」
  • 「技術書の読書術」
  • 「Lean と DevOps の化学」

美術展

特に目標を決めていません。 久々にどこかに行きたいとは考えています。

技術記事の作成

Kotlin についての記事を書きます。 週 1 で 1 記事投稿は特に目標にしていません。

2022年11月の振り返り

概要

2022 年 11 月の振り返りです。

以下を目標に掲げていました。

msksgm.hatenablog.com

目次

勉強関連

勉強関連 概要

今月も、Kotlin と設計について勉強していました。 Kotlin は RealWorld 作成によってインプットし、週 1 回の技術記事投稿によってアウトプットしていました。 設計は、「ソフトウェアアーキテクチャの基礎」と「Google のソフトウェアエンジニアリング」を読むことによって、知見を深めていました。

勉強時間

勉強時間の結果です。 今月は、約 128時間でした。 10 月も同じぐらいの時間だったのでキープできて良かったです。 勉強時間のアベレージを保ちつつ、より効率的な方法を目指します。

項目 1 週目 2 週目 3 週目 4 週目 5 週目
平日朝の勉強時間 約 5.83 時間(14 ポモドーロ) 約 14.6 時間(35 ポモドーロ) 約 11.7 時間(28 ポモドーロ) 約 9.58 時間(23 ポモドーロ) 約 8.33 時間(20 ポモドーロ)
平日夕方の勉強時間 0 時間 約 0.5 時間 0 時間 0 時間 約 0.83 時間
休日の勉強時間 約 15.4 時間(38 ポモドーロ) 約 10.8 時間(22 ポモドーロ) 約 7.5 時間(18 ポモドーロ) 約 12.9 時間(31 ポモドーロ) 0 時間
RealWorld ペアプロ 4 時間 約 5 時間 約 4 時間 2 時間 2 時間
「ソフトウェアアーキテクチャの基礎」/「Google のソフトウェアエンジニアリング」勉強会 2 時間 2 時間 2 時間 2 時間 2 時間
connpass の勉強会 2 時間 0 時間 0 時間 約 1 時間 0 時間
合計 約 29.2 時間 約 32.9 時間 約 25.2 時間 約 27.5 時間 約 13.1 時間

注力分野

Kotlin

今月も RealWorld の実装をしていました。そして実装が完了しました。 先月末から、以下の 2 つに取り掛かり完了したら、RealWorld が全体として完了だと想定していました。

O/R マッパの選定もおこなっていましたが、ちょうど良さそうなものがなく、結局やめてしまいました。しばらくは素の SQL で実践していきます。

知人と自分の 2 人でやっていたのですが、あたらしく共通の知り合いが Kotlin に取り組もうとしていることから、次の勉強段階に移ろうとしています。 自身も教える立場になり、学び方のベクトルが変わるので、学んだことをまとめつつ、教えられるように意識をかえていきます。 関連として、これを機会に Kotlin で Web API のアプリケーションを作る方法を書籍としてまとめたくなりました。 そのため、12 月末まで、週 1 回 Kotllin の技術記事投稿を目標にしていましたが、中断することにしました。

月初に目標を掲げていた、『「Functional Programming in Kotlin」の読書計画を作成 & 計画的に読む』は、実践できませんでした。どうしても時間がとれませんでした。それにもかかわらず、「Kotlin in Action, Second Edition」を購入してしまったので、どれから読もうか考えています。

別件になりますが、社内で PHPAPI を置き換える議論について考えています。 個人的には Kotlin で置き換えたいのですが、自分のやろうとしていることが、「事業のための仕事」と「人のための仕事」どちらなのか考えています。 Java と Kotlin を比較した際に、明確に Kotlin の方が優位である理由を示せずに困っています。 しかし、Kotlin が選ばれなかったら、組織的の考えと個人の考えが一致しなかったことを理由に辞める可能性があります。

設計

今月の 2 週目に「ソフトウェアアーキテクチャの基礎」を読み切りました。 主にアーキテクチャを選定するときや評価するときの決定基準について学びました。 今まで、コードレベルでの意思決定しかしていなかったので、他人を納得させるためにどのような要素が必要になるのか参考になりました。 特に、印象に残った点は、リスク評価と ADR です。 ビジネス側が持つ重要な関心事の 1 つのはずなのに、今までリスク評価を書き出したことありませんでした。 今後、実務レベルで導入するには必ず必要だと思いました。 もう 1 つは ADR です。 アーキテクチャの技術的な意思決定をどのようにまとめるのかわかっていませんでした。 社内ドキュメントに体系的にまとめるのも良いですが、スナップショット的なまとめ方もできると良いと思い、今後導入しようと思えました。 本書を読むことで、ソースコードレベルに止まらない、アーキテクチャについて考える良い機会になりました。

今月の 3 週目から、「Google のソフトウェアエンジニアリング」を読みました。 エンジニアリングについての話だったので、まとめるのが非常に難しいです。「エンジニアリング」として学ぶのは初めてなので興味深いことが記述されています。 現場、公平性や、チームビルディング、生産性といった普段考え直すことのない部分を読んでいます。 特にスタイルの強制やコードレビューについては、当たり前のようにやっているのに、改善できない部分だったので、今一度考え直しました。 今まで読んできた本の中で最も鈍器なので、負担が重いですが、頑張って 8 週間で読み切ります。

読書

読書概要

今月も、設計と Kotlin 関連の書籍を主体に読んでいました。 後輩との勉強会で Go を学んでいるのでついでに Go の書籍も読んでいます。

読んだ本

「ソフトウェアアーキテクチャの基礎」

msksgm.hatenablog.com

プログラミング言語 Go」

引き続き、職場の後輩と 2 人で読んでいました。内容的に 7 章までで読むのをやめました。

msksgm.hatenablog.com

「初めての Go 言語」

プログラミング言語 Go」の副読本として読んでいます。 いつ読み返しても非常にわかりやすく、名著だと考えています。

「読みやすいコードのガイドライン

こちらの書籍は Kotlin でサンプルコードが書かれていたため読みました。 しかし、想定していたより書籍の難易度が高く感じられたため、途中で読み飛ばしてしまいました。

オブジェクト指向設計実践ガイド」

オブジェクト指向の勉強がしたくなったので、本書を読むことにしました。 読了予定時期は未定です。

「Kotlin in Action, Second Edition」

MEAP で売っていたので技術書作成の参考にする目的で購入しました。 第 1 版と比較して、Kotlin 自体についての説明が増えており、歴史の流れを実感しました。

技術記事の作成

Kotlin 縛りで 1 ヶ月間投稿できました。 そろそろネタが厳しくなってきたのと、技術書を作成したいので、12 月末まで続けるか未定です。

「Kotlin(Spring Boot)の API テスト(MockMVC)で CustomComparator を用いて独自の比較方法を作成」

zenn.dev

「Kotlin(Spring Boot)+ MockMVC + DatabaseRider で簡単 API 結合テスト

zenn.dev

「Kotlin(Spring Boot)のテストコードで @SpringBootTest を利用して DI する」

zenn.dev

「Kotlin(Spring Boot) に ArchUnit を導入する」

zenn.dev

その他

connpass の勉強会

JJUG を視聴しました。

jjug.doorkeeper.jp

まとめ

今月も Kotlin と設計に注力した 1 ヶ月でした。

Kotlin については、約半年間取り組み続けてきたプロジェクトだったので、やりきれて良かったです。 個人開発なのに、この規模で最後までやり切れたのは非常に良い経験になりました。共同して作ってくれた知人に非常に感謝しています。 次は、3 人目として Kotlin 初学者の知人も参画し新しい学習用のプロジェクトを作成します。 今回は自分も教える側になります。これを機会に Kotlin で Web API のアプリケーションを作成する技術書を作成しようと思いました。 技術記事の投稿は習慣化していましたが、より体系化された文章構成を考える必要があります。難しそうですが頑張ります。作成期間は三ヶ月程度で一旦公開を考えています。 そのため、12 月末まで技術記事の週 1 投稿を必ずやるのは、一旦やめようと考えています。

設計は「ソフトウェアアーキテクチャの基礎」を読み切りました。 今回も分厚い本でしたが、勉強会で読み切れてよかったです。 以前の本でもそうですが、さまざまなメソッドを学び、まずは実践すること、そして保守運用することが重要だと考えています。 それに加えて、「今までは異なるパラダイムを持つ人たちにどうやって納得感を持って取り組んでもらえるか」というのが課題になっています。 自分にとっては当たり前のように感じるやり方を相手に受け入れてもらえないのは技術料以外の部分に依存していると考えています。自分は、エンジニア感性(個人的に名付けたもの)に依存していると考えています。 「感性」とは、印象を受け入れるの能力のことです。主に芸術領域で使われる言葉だと考えています。 苦しんだ経験やうまくいった経験が異なることにより、直感的な理解や説得に齟齬が生まれてしまう現象が、エンジニア感性の違いだと考えるに至りました。 感性の違いを説得するには、ロジックを組み立てて説得したり、単に指示したりするだけでは、不十分であることを実感しています。 感性を可能な限り一致させるためには、チームビルディング、ペアプロ、コンテキストの説明、体験学習などがより重要になります。 さらに、どちらかに偏ってしまうとうまくいかないので、言語化と行動の両輪を揃えなければなりません。 これらの活動や理解もアーキテクトやリーダーに必要なの要素だと考えるようになりました。

今年もあと 1 ヶ月になります。 毎月おこなってきた振り返りを 11 ヶ月継続し、四半期ごとの振り返りも 3 回行えました。 来月は年末なので、それに加えて 1 年の振り返りもおこないます。 最後まで継続して来年の目標を立てます。

「プログラミング言語Go」感想

概要

プログラミング言語 Go」を 7 章まで読みました。 7 章は「インタフェース」までです。後の章は平行処理やリフレクションといったレベルが高く難しい内容なので、一旦読むのをやめました。 「前提」「読了時間」「感想」「次に関連で勉強すること」「まとめ」を記述します。

前提

目的

主な目的は以下です。

  • 普段の業務で Go を使っているが、言語の製作者が作成した本書を読んだことがなかった
  • 会社の後輩と Go の知見を深めるための勉強会で課題図書を探していた。若干レベルが高そうだったが、2 人で読むには十分な書籍だと思った

前提知識

実務で、Go を用いたバッチ処理の保守開発をおこなっています。

学習教材については、Tour of Go を何周かしました。ただし、1.18 前なので、Generics が導入されるまえです。

Go の書籍は「Learning Go」を読みました。当時、日本語版の「初めての Go 言語」が出版されてませんでした。そのため、英語版を読んだため説明と理解について若干曖昧な部分があります。

一時期 zenn に Go で戦術的 DDD を実践する記事を書いていました。当時は Go を用いてオブジェクト指向らしく記述しようとして沼にはまっていた記憶があります。なので、Go らしい書き方はよくわかっていないです。

読了時間

1 週間に約 3 時間かけて対象範囲を読み、勉強会は 30 分程度で読み合わせをしていました。 これを、7 週間続けたので、だいたい 24.5 時間程度だったと考えています。

感想

Go の本質的な部分を触れられており、内容が古いですが現在も通じる部分について学べるため、Go エンジニアに 1 読してほしい書籍だと思いました。 理由は 3 つあります。それは、「詳細な言語仕様を学べる」「適切な言葉の使い方を知れる」「インタフェースのコアな使われ方について学べる」です。

「詳細な言語仕様を学べる」は、第 3 章基本データ型、第 4 章コンポジット型において思いました。詳細なデータの成り立ちに加えて、比較可能なことやメモリの割り当てについて知れました。どれも普段は意識することがないため、このような機会で学べてよかったです。
「適切な言葉の使い方を知れる」は、例えば「インタフェースを満たす」です。Java では「インタフェースを実装する」と読んでいたため、Go でも同じように「実装する」と言っていました。制作者側の意図や言語の振る舞いからすると、「満たす」が適切であるため、これからはそうすることにしました。
「インタフェースのコアな使われ方について学べる」で印象に残ったのは Http サーバーとエラーです。 Go は net/http パッケージで可能なため、普段から使っていましたが、ルーティング周りが非常にブラックボックスな印象でした。 本書籍を読み、本質的な部分はインタフェースと DefautServeMux によって、なりったことがわかり非常に腑に落ちました。 API サーバーを作成する際に、Echo や Gin といったフレームワークがありますが、どれも Go を薄くラップしただけなので、一度確認してほしいと思える内容でした。 また、エラーのラップについても触れられていました。Go はfmt.Errorfでラップすることがよくありますが、エラーの比較方法が値になるため個人的にはやっていません。それは「プログラミング言語 Go」が出版されたときからそうだったことを知り、いまだに型比較が全く広まっていないことを知り驚きました。

気になった点は、やはり内容が古い部分です。 Go 1.18 でジェネリクスや any が導入された他、それ以前に、エラーの比較には errors.As、errors.Is だったり、平行処理には context が存在することです。 そのため、初学者にいきなり読むよりは「初めての Go 言語」などを読み、手を動かして Go の経験を少しだけ得た後に読めると良いと思いました。
また、言語仕様が主体で、実用的な部分は対象外なので、「今すぐアプリを作成したい」といった人には向かないと思いました。

次に関連で勉強すること

次に Go 言語の本を読むとしたら、以下の順番で読もうと考えています。

  • 「実用 Go 言語」
  • 「Go 言語による並行処理」

まとめ

Go 言語の制作者が執筆した「プログラミング言語 Go」を読みました。 現在でも通じる本質的な部分を認識でき、一読してよかったと思えました。 内容が古い部分もあったり、すぐに手を動かして実践できる内容でもないので、他の書籍で補完したいと思いました。

「ソフトウェアーキテクチャの基礎」感想

概要

ソフトウェアアーキテクチャの基礎」を読みました。 「前提」「読了時間」「感想」「次に関連で勉強すること」「まとめ」を記述します。

前提

目的

主な目的は以下です。

  • 普段の業務で、設計について意思決定をする機会が多いので、設計の知識についてインプットできる本が欲しかった
  • 知人と設計の書籍について学ぶ勉強会を週一で開催しており、知人からの提案で課題図書になった
  • 近年発売された書籍で現代の課題について学べそうだった。過去の勉強会で読んだ書籍は 2000 〜2010 年代の時代背景の本が多かった

前提知識

設計関連で過去に読んだ書籍を紹介します。

他の、技術的な側面を主題とした書籍は以下です。

チーム的な側面を主題とした書籍は以下です。

DDD を主題とした書籍は以下です。

書籍以外では、普段の業務で「設計標準」と呼ばれる決まりごとを提案・導入・運用しています。 「設計標準」とはチームの課題について、議論して新しく標準として導入することです。 導入して 4、5 ヶ月ほど経過しています。良かった面もありますが、決まり事を守る難しさを実感しています。

読了時間

知人と勉強会を計画し、8 週間で読み切りました。 一度につき、準備に平均 3.5 時間、勉強会は 2 時間程度でした。 そのため、5.5 * 8 時間で 44 時間ほどかけて読み切りました。

感想

本書は、ソフトウェアアーキテクチャの第一法則「ソフトウェアアーキテクチャトレードオフがすべてだ」に乗っ取り、さまざまな観点からアーキテクチャについて評価できるようになる本でした。 どのような状況とアーキテクチャにおいても、「場合による」を一貫して貫き、偏った知見にならないように教えてくれます。 それは、ソースコードやハードウェアに限らず、アーキテクトとしての振る舞いや集団との関わり方についても同様でした。 この書籍を読むことで、「アーキテクチャ」についてモダンな見識を広げられるようになります。 良かった点と気になった点をそれぞれ挙げていきます。

良かった点は 3 つあります。

1 つ目はアーキテクトがあるべき振る舞いについて記述されていることです。 書籍では開発者とアーキテクトが別の役割として、説明されます。 例えば、次の文言があります。

プログラマーは利点はわかっているが、トレードオフはわかっていない。アーキテクトは両方を理解する必要がある」。

そして、開発者からアーキテクトになると技術的な深さよりも技術的な深さが重要になります。 また、アーキテクトは対人スキルを持ち、社内政治を理解する必要があるとも記述していました。
私は、アーキテクトはより技術的な見識が深い人がなるものだと思っていたので、これについて価値観が異なり驚きました。どちらかといえばエンジニアリングマネージャーの役割だと思っていたからです。 しかし、本書を読むことで、アーキテクチャの第一法則に従うと、トレードオフを考えられない場合は、本当の意味で理解していないことに気がつきました。 普段、第三者に設計について述べるときにはトレードオフを意識して話せていないので、これからはかならずメリットとデメリットを述べるようにしようと考えました。

2 つ目は、幅広いアーキテクチャについての紹介があることです。 レイヤードアーキテクチャから始まり、マイクロサービスで終わるアーキテクチャの紹介は、10 章にも渡ります。この章を読むことで、確実にアーキテクチャ知識の裾を広げられます。 中には、マイクロカーネルアーキテクチャやスペースベースアーキテクチャといった全く知見の無いアーキテクチャの紹介もありました。 「現場で使っているアーキテークチャはこのアーキテクチャだ」「現在のアーキテクチャにはこのようなメリットがある」と考えることで、メリットデメリットを理解できました。 関連して、現在は負債になっているようなアーキテクチャでも過去にはベストプラクティスの選択肢の 1 つだったと思えるようになりました。

3 つ目は、アーキテクチャの意思決定やうまくいくためのテクニックとスキルについてです。 特に印象に残ったのは、ADR、リスク分析、チームについてです。どれも自身の抱えている課題に対して役立ちそうだと思ったからです。
ADR は、アーキテクチャの意思決定の過程でドキュメント化しづらいものはスナップショット的にまとめるのは良いと思いました。何が有効なのかと同じぐらい何が無効なのかわかるのは非常に重要だと思いました。
リスク分析は特に刺さりました。さまざまなアーキテクチャを提案してきましたが、ステークホルダーが本当に気にするリスク分析をマトリックス化してまとめて来たことがなかったからです。現在、リプレイスを提案しているので、この本で記述されているリスク分析は必ず早めにやろうと思いました。
最後にチームについてです。チームビルディングについて何度か行ってきましたが、本当にバランスの良い状態になったことはありません。意図的に介入するのも、しないのも良いアーキテクトの役割と知り、実践できないかと思いました。

気になった点は 2 つあります。どれも本の評価を下げるほどのものではなく、個人的に感じたことです。

1 つ目は対象読者の層がよくわからなかったことです。 「基礎」というには幅が広く、「アーキテクトになってから」は遅く感じました。 例えば、アーキテクチャの種類を紹介する章では、ニッチすぎるように感じるものも紹介されていました。しかし、ソフトウェアアーキテクトがどうあるべきかは早い段階で知るべきだと思いました。 あえて言うのならば一瞬でもアーキテクトの知見が欲しければ必読の本だと思いました。

2 つ目は、図の読み取り方がよくわからない箇所が何個かありました。 致命的にわからない図はなかったですが、例えば、図 1-2 から図 1-6 は縦軸と横軸の意図が読み取れませんでした。 文章をうまく図に起こせているとは思えない部分があり、何度か戸惑った印象があります。 あくまで知人と自分の見解なので、自分だけの可能性があります。

次に関連で勉強すること

次は「Google のソフトウェアエンジニアリング」を読もうと考えています。 この書籍を読み終えたら、一旦は設計関連の勉強は終わりではないかと考えています。 または、ソースコードよりの書籍を読もうと考えています。

まとめ

本書籍では、ソフトウェアアーキテクトの幅を広げられる本でした。 主に以下について学べました。

  • ソフトウェアアーキテクチャの第一法則「ソフトウェアアーキテクチャトレードオフがすべてだ」について
  • アーキテクトが、技術的な知識、ビジネス的、チーム的にどうあるべきなのか
  • アーキテクトをうまく運営するための方法について

2022年11月の目標

概要

11 月の目標です。

勉強関連

以下を勉強していきます。 勉強会を 3 つ抱えているので、勉強時間の確保と進め方を試行錯誤しながら進めます。

  • Kotlin
    • RealWorld の作成
    • 技術記事の作成
    • 「Functional Programming in Kotlin」の読書計画を作成 & 計画的に読む
  • 設計

読書

「読みやすいコードのガイドライン」を読みます。

美術展

特に目標を決めていません。

技術記事の作成

Kotlin についての記事を書きます。