Try T.M Engineer Blog

多摩市で生息するエンジニアが「アウトプットする事は大事だ」と思って初めたブログ

じぶん Release Notes(ver 0.2022.05)

よくエンジニア系Blogで見る「じぶん Release Notes」

4月の振り返りをしていきます。

技術関連

  • Web APIの理解
  • React, Reduxの理解

読書

読んでいる

アウトプット

qiita.com

仕事の話

最近、CMS Drupalを触りはじめました。
OSSだけど、日本ではWordPressの方が圧倒的に人気なので、日本語情報が少なくてカナリというか無茶辛いです。
でも、作りとしてはDrupalの方がWordPressよりしっかり作られている雰囲気😑
もうすぐDrupal 10が出るそうなので、それもウォッチしつつコチョコチョ触っています。

プライベート

車を購入してからは、車でのお出かけが増えました。
今まで遠くて行けなかった公園やお店、テーマパークなど。。。もう、車なしの生活は考えられなくなりました😭

妻も「バスの待ち時間を気にしなくていいのは楽だー」と言ってくれました。

それに子供が車に興味を持ってくれたことも嬉しい😀
「ドライブくん(車のこと)で出かけたい〜」と言ってくれるようになったので、気軽に車でお出かけできるのは楽です。

相変わらず駐車は苦手ですが、繰り返し練習して克服を目指します!😐

↑こじんまりとしているところだけど、綺麗だった。
HANA・BIYORIより

振り返り(KPT

Keep

  • 「じぶん Release Notes」を継続できた。
  • React, Reduxについて、なんとなく理解できてきた。

Problem

  • 本を読むのが進まない(今読んでいる本は700ページある分厚い本なので辛い。。。)
  • アウトプットが少ない。

Try

  • 今読んでいる本を読み終える。(5月中には読了目指す)
  • React, Reduxについて、引き続き学ぶ!

気になった話題

zenn.dev

知らないことが多かった。すごく勉強になった。

developers.cyberagent.co.jp

オススメする本のレベルが高すぎて驚く。。。

じぶん Release Notes(ver 0.2022.04)

よくエンジニア系Blogで見る「じぶん Release Notes」

3月の振り返りをしていきます。

技術関連

  • Web APIの理解

  • AWS Cognitoによる認証の理解

  • Vite, Vitest, vite-ssg の理解

読書

読んでいる

読了

アウトプット

qiita.com

qiita.com

qiita.com

プライベート

ペーパードライバー講習を終えて、初めて車を購入して無事に納車が完了しました。

f:id:special-moucom:20220402231059j:plain

まだまだ車の運転に慣れないので、土日にできるだけ車に乗るようにしています。

最近は、YouTubeに車の運転レベルの向上を目指す動画をアップされている方もいるので、すごく助かりますね。(時代の進歩を感じます・・・😭

https://www.youtube.com/channel/UC0mPwepVHMKsMJKfMDs5ezg

車を購入してから、まったく車に興味がなかった私が、ちょっとずつ興味を持ち始めて、新しい趣味が出来つつあるのが良いことかなぁと思ってたりもします。

振り返り(KPT

Keep

  • 「じぶん Release Notes」を継続できた。
  • 「Web APIの設計」を読了できた。
  • 前月より多くアウトプットできた。

Problem

  • CI周りの学習、フロントとのAPI設計の共有をなんとかしたい
  • 散財(無駄なものを買いすぎ)が多い

Try

  • Reactに挑戦
  • 今読んでいる本を読み終える

気になった話題

devblogs.microsoft.com

JavaScriptに「コメントとしての型」を入れる話が話題になりましたね。

zenn.dev

これも面白かった。

今、ランニングコストゼロでアプリケーション開発しようとすると、こんな構成になるのかぁ。。。

devblog.thebase.in

これと「Web APIの設計」を読んで、フロントとのSwaggerの共有方法をもう少し改善しないといけないと改めて思った。

具体的には「ReDocの活用」と「フロント向けにモックサーバーをどこかにアップしたい」です。

openapi-generator-clitypescript-fetch も使ったことがなかったので、ちょっと試してみたいと思いました。

じぶん Release Notes(ver 0.2022.03)

よくエンジニア系Blogで見る「じぶん Release Notes」

2月の振り返りをしていきます。

技術関連

  • JavaScript Promiseの理解
  • AWSのCognitoとLambda@Edgeによる認証の理解
  • Vite, Vitest, vite-ssg の理解

読書

読んでいる

  • Web APIの設計

読了

azu.github.io

アウトプット

  • Zenn

zenn.dev

仕事の話

JavaScript Promiseの本を読んで、社内勉強会を開催しました。

JavaScriptで非同期を実現している方法やPromiseのStatic Methodが新規に追加されていたことなど、色々と学びになりました。

社内勉強会も連続して開催することができたので、良かった。

プライベート

昨年から開始したペーパードライバー講習が無事に完了。

しばらくはレンタカーを借りて遠出したりしていましたが、いよいよ車(中古車)を購入することにしました。これで気軽に車に乗ることができる。

初の車購入なので、車やら任意保険やらの情報を集めて理解するのに必死でした。

アルセウス(ゲーム)の方も順調で、気がつけば30時間くらい溶かしてました。

まぁクリアできたのと、子供がいる中でもゲームぐらいはできる環境になったというのが、新しい発見でもありました。

それよりも、マザー、マザー2、ライブアライブなどがリリースって、任天堂は私の時間を積極的に奪おうとするのやめてっ!!

車やゲームで散財が続いているので、しばらくは節約モードに入りたいと思います。

振り返り(KPT

Keep

  • 「じぶん Release Notes」を継続できた。
  • Zennへの投稿ができた。
  • JavaScript Promiseの本」を読了。
  • JavaScript Promiseについて社内勉強会を開催できた。
  • アルセウス(ゲーム)をクリアした。(一旦、ゲーム終了)

Problem

  • アルセウスに時間を取られすぎた。
  • 本を読むのが進まない。。。
  • アウトプットが少ない。

Try

  • 今読んでいる本を読み終える。
  • もう少しアウトプットを増やす。

気になった話題

devblogs.microsoft.com

時の流れは早い。。。キャッチアップせねば。。。

zenn.dev

frourioって国産なんですよね。
名無しさんのポッドキャストでも話されていたので気になってました。 どこかで使ってみたい。。。

github.blog

GitHubが「Mermaid」に対応したとのこと。「PlantUML」は使ったことがあるけど「Mermaid」はないので、これも使ってみないとなぁ。。

じぶん Release Notes(ver 0.2022.02)

よくエンジニア系Blogで見る「じぶん Release Notes」を始めてみる。

技術関連

  • GCPのCloudFunctionsの理解
  • Terraform with GCPでCloudFunctionsの作成
  • AWSのCognitoとLambda@Edgeによる認証の理解
  • Expressの理解
  • Vue3を個人的に学習

読書

読んでいる

読了

  • Clean Architecture

アウトプット

Zenn

zenn.dev

Blog

kodak.hatenablog.com

kodak.hatenablog.com

プライベート

保育園でコロナのクラスターが発生して、仕事をしながら子供の面倒を見るというハードモードに突入した。とはいえ、特別急ぎの仕事はなかったこと、嫁さんの仕事を在宅に切り替えてもらったことで、以前ほど辛い状況にはならなかった。

ペーパードライバー講習も終盤。駐車と登り / 降りをメインに練習している。車も購入するかどうかを家族会議で相談中。

久しぶりのゲームやりたい病が発病。ポケモンアルセウスに夢中。

振り返り(KPT

Keep

  • はじめて「じぶん Release Notes」を投稿できた。
  • はじめてZennへの投稿できた。
  • 「Clean Architecture」を読了、アウトプットもできた。

Problem

  • アルセウスに夢中になりすぎ。。。
  • アルセウス乱入により、調べていたこと。まとめようとしていたことが途中。

Try

  • AWSのCognito / Lambda@Edgeまわりで調べたことをアウトプットする
  • GCPのCloudFunctionsの理解したことをアウトプットする
  • 今読んでいる本を読み終える

気になった話題

risingstars.js.org

これ面白い。ビルドツールはViteが1位に。。。テストツールでPlaywrightって初めて聞いた。

devblogs.microsoft.com

TypeScriptの4.6のBetaも出てた。これも要チェック!

気になったガジェット

gori.me

Bluetootheインカム付きヘッドセットってなかなか無いので嬉しい。
今使っているロジクールのH800に変わるヘッドセットなのかもしれないので、要チェック。

item.rakuten.co.jp

ワタナベカズマサさんがオススメしていたもの。
家で☕を豆で挽きたい人には良さそう。。。

「Clean Architecture 」を読んだ感想

いたるところで有名な Robert.C.Martin氏、いわゆるアンクル・ボブ (ボブおじさん Uncle Bob) の本。Cleanシリーズの3作目「Clean Architecture」を読んだので、その感想です。

Clean Architecture

f:id:special-moucom:20220109015713j:plain

でた、ドーナッツっ!!

よくエンジニア記事で見かける図ですが、「Clean Architecture」を読むことで、なんとなくこの図の意味が理解できたと思うので(私の)解釈を残しておく。

前提

この図の各層と内側に向かう→は、依存関係のルールを表したもの。

円の外側は仕組み。内側は方針を表す。

依存関係のルールとしてソースコードの依存性は、内側(上位レベルの方針)だけに向かっていかなければならない。」(内側に向かう→がそれを表している)

つまり、円の内側は外側について何も知らない。外側で宣言されたデータフォーマットは内側で使用してはならない。ということ。

エンティティ層(Entities)

最重要のビジネスルール部分のレイヤー。エンティティといえば、データベースにもクラス等の表現を用いて使われるものがありますが、それとは別。

もっと抽象的なもので、特定のフレームワークやアプリケーションに依存しないオブジェクトを表す。

ユースケース層(Use Cases)

エンティティの外側。アプリケーション固有のビジネスルール部分のレイヤー。

システムすべてのユースケースが含まれており、ユースケース間で依存関係は持ってはならない。

インターフェースアダプター層(Interface Adapters)

ユースケースの外側。エンティティ層やユースケース層、後述のフレームワーク&ドライバー層のフォーマットにデータを変換するレイヤー。

MVCやMVPアーキテクチャのコントローラー、ビュー、プレゼンターなどはこのレイヤーに位置する。(モデルは、コントローラーからユースケースユースケースからコントローラー、プレゼンター、ビューへ戻されるデータ構造にすぎない。と書かれている)

フレームワーク&ドライバー層(Frameworks & Drivers)

一番外側。フレームワークやデータベース、ツールで構成されるレイヤー。(Web、UIなども含むので、Webから入力するページ等を想像して問題ないと思う)

なお、このレイヤーではコードをあまり書かないようにする。

右下の図(境界線の超え方)

境界線の超え方が書かれている。インターフェースアダプター層のコントローラーとプレゼンターが、ユースケース層へデータを渡す例が書かれている。

また、ソースコードの依存関係にも触れていて、ユースケースからプレゼンターを呼び出す必要があった場合、ユースケースからプレゼンターを直接呼び出すのはNGなので、プレゼンターがインターフェースを実装することを表している。ここの実装は以下SOLID原則に従っている。

SOLID原則

「Clean Architecture」のような実装を行うには、SOLID原則(5つの原則)を理解する必要がある。

S(Single Responsibility Principle): 単一責任の原則
O(Open/Closed principle): 開放閉鎖の原則
L(Liskov substitution principle): リスコフの置換原則
I(Interface segregation principle): インターフェース分離の原則
D(Dependency inversion principle): 依存性逆転の原則

単一責任の原則(SRP)

「モジュールを変更する理由はたったひとつだけであるべきである」と語られているが、この変更する理由というのが「ユーザーやステークホルダー」であるべきとも言われている。

本書では、この「ユーザーやステークホルダー」のことをアクターと呼ぶ。

つまり、言い換えると「モジュールはひとりのアクターに対して債務を負うべきである。」となる。

たとえば、社員クラスがあったとして、そのクラスは様々なアクターで使われるだろう。

その時、モージュルとデータが分離されていない場合、アクター間でデータの不整合が起きる可能性がある。そのため、モージュルとデータはちゃんと分離する。(本書ではFacadeパターンを用いるのが良いと伝えている)

class Employee {
    name() { // NG: データは別に持つべき
      return 'Kodak'
    }

    department(dept: DepartmentInterface) { // OK: データは別クラスで持つ
      return dept.name()
    }
}

interface DepartmentInterface {
  name(): string
}

class SystemEngineer implements DepartmentInterface {
  name() {
    return 'SE'
  }
}

オープン・クローズドの原則(OCP)

「ソフトウェアの構成要素は拡張に対して開いていて、修正に対して閉じていなければならない」と語られている。つまり、「ソフトウェアの振る舞いは、既存の成果物を変更せずに拡張できるようにすべきである」ということ。

class Printer {
  print(printer: PrinterInterface) {
    return printer.print()
  }
}

interface PrinterInterface {
  print(): void;
}

// 機能追加したい場合は、以下「Printer」クラスを増やすだけ。
class DefaultPrinter implements PrinterInterface {
  print() {
    // ...
  }
}

class HtmlPrinter implements PrinterInterface {
  print() {
    // ...
  }
}

class TextPrinter implements PrinterInterface {
  print() {
    // ...
  }
}

リスコフの置換原則(LSP)

「S型のオブジェクトo1に対応する各々に、T型のオブジェクトo2が1つ存在し、Tを使って定義されたプログラムPに対して、o2の代わりにo1を使ってもPの振る舞いが変わらない場合、SはTの派生型」と語られている。

。。。わかり辛い。

NGパターンの代表例として、以下のような正方形クラスが長方形クラスを継承しているようなパターンはNGとされている。

なぜなら、長方形は幅と高さを独立して変更できるのに対して、正方形は両方同時に変更する必要がある。これをユーザーが長方形と信じるとおかしなことになる。

// rectangleには長方形 or 正方形が入る。
// 長方形は幅と高さを独立して変更できるのに対して、正方形は両方同時に変更する必要がある。
// user関数からみるとこれが判断できない。。。
function user(rectangle: Rectangle){
    // ...
}

class Rectangle {
  constructor(protected height: number, protected width: number) {
  }
  setH(set: number) {
    this.height = set;
  }
  setW(set: number) {
    this.width = set;
  }
}

class Square extends Rectangle {
  constructor(height: number, width: number) {
    super(height, width)
  }
  setSide(set: number) {
    this.height = set;
    this.width = set;
  }
}

user(new Rectangle(1,2))
user(new Square(2,2)) // 注意: 継承しているのでSquareでも呼び出せる

こういった場合、インターフェースを使って仕様を事前に設計を綺麗にしておく(たとえば、長方形なのか正方形なのかがわかるメソッドを定義しておくなど・・・)

インターフェイス分離の原則(ISP

一言で言えば「使っていないメソッドを持つクラスに依存してはならない」ということ。

きちんとインターフェースをグループごとに分けて適切に使う。

interface AnimalInterface {
  sleep(): void
  eat(): void
  fly(): void
}

class Human implements AnimalInterface
{
  sleep() {}
  eat() {}
  fly() {} // Humanクラスでは、fly()は使用しない
}

依存関係逆転の原則(DIP

ソースコードの依存関係が(具象ではなく)抽象だけを参照しているもの。それが、最も柔軟なシステムである。」つまり、クラスを呼び出す時は抽象を使えということ。

class Animal {
  createPenguin() {
    const penguin = new Penguin() // AnimalクラスからPenguinクラス(具象)へ依存
    penguin.swim()
  }
}

// 上の方法ではなく、抽象を使う
class Animal {
  createPenguin(penguin: PenguinInterface) { // Animal → PenguinInterface ← Penguin へと依存関係を変える。
    penguin.swim()
  }
}

上のは一例だが、本書においても、例でデザインパターンの1つ「Abstract Factory」を使う説明の記述があった。つまり、クラスを呼び出す時だけでなく、継承においても変化しやすい具象クラスではなく抽象を使うべきだということ。

本書を読んで

前半は、goto文辛いよ話、オブジェクト指向の誕生、そして関数型プログラミングへと歴史の話。

以前、私が読んだ「何故オブジェクト指向でなぜつくるのか」に近しい内容が書かれていた。

kodak.hatenablog.com

そこから、SOLID原則の話とコンポーネント(デプロイ単位)の話・・・で、ようやくクリーンアーキテクチャの話。

ページ数も結構あるので、最初から読んでいると「おいおい、あのドーナッツいつ出てくるんだ?」と何度も思いました。

Clean Architectureは、抽象的な話なので「うーん、わかるような・・・わからないような・・・」ずっと本書とにらめっこしていました。

未だ「完璧に理解した」とは言えませんが、エンジニアBlogや記事等で語られているSOLID原則やClean Architectureについて、話に付いていけるくらいは理解できたつもりです。

付録では、ボブおじさんの職歴について触れていましたね。「ネクタイを強制する職場で、パフォーマンスが出なくてクビになった」とか「あのグラディ・ブーチと仕事ができるのかっ。やる!やる!」みないな話もあって、共感するものがありました。

本書は、読んでいて面白かったし、学びになることも多くありました。

ただ、誰もにでもオススメできるような書籍ではないとは思います。というのも、やはり時代を感じる部分は多々あるからです。本書が発売したのが2018年(英書は2017年)ですし、ボブおじさんが働いていた時代の話はもっと後の話です。なので、現代的なアプリの話はありません。

エンジニアBlogや記事等で語られているSOLID原則やClean Architectureについて、素直に知っておきたいなぁという方にオススメです。