クリーンアーキテクチャ読書会の感想 #techplaygirls

クリーンアーキテクチャ 読書会 with ほくりんさん、Chihiro さんが終了しました。その感想です。

  • 2021/10-2021/03
  • 9:00 - 12:00 ぐらい
  • 毎週 土曜日

クリーンアーキテクチャの概要

開発における私たちのユートピア、すなわち開発メンバーを増やすことなく一定のスピードで開発し続けることができる世界、最小限のコストで最大限の柔軟性を発揮できる世界を実現するために良い設計が必要です。
良い設計とは?それはコードが入出力からの距離ごとにレベル分けされており、入出力に近いものはレベルが低く、遠いものはレベルが高い。そして SOLID 原則をアーキテクチャにも適用し、レベルごとに境界線を引き依存度を減らすこと、またレベルごとの依存関係は必ずレベルの高い方に向かせることで変更が及ぼす影響は最小限にし、レベルの低い更新は決定を遅らせることができる状態のこと。

良い設計とは?

優れたソフトウェアの設計の目的

求められるシステムを構築・保守するために必要な人材を最小限に抑えることである。

設計の品質は計測できる。常に必要な労力が低く保たれているなら、その設計は優れているし、逆にリリースごとに労力が増えるなら、その設計は優れていない。

ソフトウェアを「ソフト」に保つ

マシンの振る舞いを簡単に変更したくないとき、それを「ハード」ウェアと呼んでいる。すなわち、ハードと対比した「ソフト」ウェアは簡単に変更できなければならない。

変更の難易度は、変更の形状ではなく変更のスコープに比例させる

ソフトウェア開発者は、「四角い」ペグを「丸い」穴に打ち込まなければいけないような気持ちになることがよくある。

漫画にした。

f:id:meikotan:20210405123026j:plain
変更の難易度は、変更の形状ではなく変更のスコープに比例させないと辛い

「穴の形状を変えたのはそっちだろ!?😡」と言いたくなるんだけど、そもそもこういった特定の「形状」にとらわれるアーキテクチャにしない方が実用的。

選択肢を残しておく

変更可能な状態にして決定を遅らせたい。これだ!ってものが見つかるまで重要ではない詳細は決めない。決定を遅らせた分、適切に作るための情報が数多く手に入る。形状に依存しないと同じような意味。

SOLID 原則

SOLID 原則のポイントとアーキテクチャに適用する場合のポイントが書かれていた。SOLID 原則ってクリーンアーキテクチャで提唱されてるのかと思ってたけど間違ってたわ。

原則を知ってるからって、すぐには実践できるわけじゃないんだけど。コードを書く上での基準として、すべきであるっていう事は常に心に留めておきたい。

単一責任の原則

コンウェイの法則(システムを設計する組織は、組織のコミニケーション構造をコピーした構造の設計を生み出す)から導かれる当然の帰結。ここのモジュールを変更する理由がたった1つだけになるように、ソフトウェアシステムの構造がそれを使う組織の社会的構造に大きな影響受けるようにする。

モジュールとは一つのソースファイルのこと。

モジュールはたったひとつのアクターに対して責務を負うべきである。

すなわち、アクターの異なるコードは分割するべき。

組織構造とソースコードの責任範囲って全然関係ないものって考えたけど、むしろ影響を受けるようにした方が良いんだね。自分の書いてるソースコードが本当に一つの責任しか負っていないのか?判断基準が曖昧だったけど、アクターを分離しろ!は分かりやすい基準だと思った。

メモ:他のレベルでの同じような原則

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

ソフトウェアの構成要素は拡張に対しては開いていて、修正に対して閉じていなければならない。 言い換えれば、ソフトウェアの振る舞いは、既存の成果物を変更せず拡張できるようにすべきである、ということだ。 これこそが、我々がソフトウェアアーキテクチャを学ぶ根本的な理由だ。

本当にそう思う。

オープン・クローズドの原則の目的は、変更の影響を受けずにシステムを拡張しやすくすることだ。目的を達成するために、システムをコンポーネントに分割して、コンポーネントの依存関係を階層構造にする。そして上位レベルのコンポーネントが下位レベルのコンポーネントの変更の影響を受けないようにする。

これがクリーンアーキテクチャの中心部分の考えだし、円の一例もこれのこと。

f:id:meikotan:20210405140519j:plain
The clean architecture (https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html より引用)

インターフェースの役割は2つ

① 上位レベルのコンポーネント保護

上位レベルのコンポーネントは下位レベルの変更の影響を受けてはいけない。そのため、場合によっては制御の流れと逆転した依存関係にする必要があり、インターフェイスを使用して依存関係逆転の原則を適用する。

② 下位レベルのコンポーネント保護

下位レベルのコンポーネントは上位レベルのコンポーネントであっても自分が直接使っていないものにまで依存すべきではない。(上位コンポーネントの内部を知り過ぎてはいけない)下位レベルのコンポーネントが直接使うものだけに依存できるようにインターフェイスを使用し情報隠蔽を行う。

f:id:meikotan:20210408125615j:plain

リスコフの置換原則

リスコフの置換原則 - Wikipedia

これはもうその通りだし、イレギュラーを認め始めると仕組みがどんどん複雑になってくる。

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

不要なもの(使ってないもの)には依存しないこと。

依存関係逆転の原則

ソースコードの依存関係が具象ではなく、抽象だけを参照しているものが最も柔軟なシステムである。それが難しい場合は、なるべく変化しにくいものへ依存すること。依存したくないのは、変化しやすい具象要素である。

階層ごとの境界を引くために何度も利用される原則。GoFデザインパターン本を並行して読んでたので、この原則の理解が進むに連れて、このパターンはインターフェイスを置くことで依存関係逆転してるなぁということが分かるようになった。

Uncle Bob の講演(2021/01/29)

まるで私たちのために用意されたかのような奇跡的なタイミングで Builders Box by Sansan のイベントに Uncle Bob がきました!!(°▽°) Sansan ありがとう!

講演内容はクリーンアーキテクチャの大まか説明と質疑応答でした。その内容は Sansan のブログを見てください。

印象に残ったことは、以下の質問に対して

よいアーキテクチャは重要な決定を延期させてくれるもの、という点についてはなるほど、と思った。では、延期をした決定はいつすればいいのか? 意志決定の適切なタイミングはいつなのか?

Bob が色んな理由を踏まえながらも「分かるときがくる」って自己確信している雰囲気で、その感覚すごいなぁと思ったし、私に足りない部分でした。めっちゃ自分のこと信じてる感。そういう本人が持ってる空気感を感じれたのはオンラインであっても直接講演を聞けたおかげだし、文字だけじゃない形で話を聞くって大事だよなぁと改めて感じました。

クリーンアーキテクチャ読了後の感想

この本は t_wada さんのツイートで言及されてたのがきっかけで興味を持ち、目次を眺めたときに SOLID 原則について書かれていて読みたくなりました。SOLID 原則はネットの記事でよく見るけどイマイチ理解できてない用語だったので、きちんと学びたいと思ったからです。でも、読み終わった後にこの本で一番印象に残ったのは、1章の「なぜ正しい設計目指すのか?」「どうやって正しい設計と判断するのか?」についての記述です。そこを理解し自分も正しい設計を目指したいと思ったおかげで、SOLID 原則や境界線、一方向の依存関係の重要さがより身に染みた気がします。また、設計について書かれたネットの記事がグッと読みやすくなりました。ただ、この本全体を通して具体例が少なかったので、クリーンアーキテクチャの実例をいくつネットで読んだり、アジャイルソフトウェア開発の奥義を読むのも挑戦したいです。

読書会の感想

読書会メンバーは開発歴はある程度あるってことは一致してるけど、会社は異なっているので視点が幅広く、話していて学びが多かったです。また、日々使っている言語(C#、Typescript、JavaRuby)も全員別々だったので、私が使ってる言語、フレームワークに関しては私が言語化する必要があり、改めて言語化することで気付くことや言語ごとの違いを認識できたりして、とても勉強になりました。そして本当に三人寄れば文殊の知恵で、1人で読んでたら分からないまま素通りしていたことも、深く理解しながら読み進めることができました。感謝。あと3人ともお喋りが好きなので余談もてんこ盛りで笑えました😄

最後に

クリーンアーキテクチャ本の好きな一文を引用して終わりにします。

不完全な知識で運用する可能性があることを認めながら、そうするのが人間であり、人間はそれが得意であることを理解している。我々の弱みよりも強みを生かしてくれる。我々は物を作り、発見する。我々は質問し、実験する。優れたアーキテクチャとは、それが目的地ではなく旅路であること、凍結された成果物ではなく進行形の探索プロセスであることを理解するところから生まれる。

参考

デザインパターン読書会の感想 #techplaygirls

デザインパターン読書会 with Katorie さんが終了しました。その感想です。

  • 2020/03-2021/03
  • 週1

読んだ本

デザインパターンを学ぶモチベーション

きっかけは Global Day of Coderetreat 2018 in Matsuyama で良い設計について考えたことです。そこから綺麗なコードを目指すためにオブジェクト指向を学ばなアカン!と思って、オブジェクト脳のつくり方 を読んでデザインパターンのコンポジットパターンってすげぇ〜となり、デザインパターンを勉強しよう!ってなりました。

そして読書会の半ば、中弛みしそうになったときに Youtube で見つけた 5 Design Patterns Every Engineer Should Know で、エンジニアのキャリアステップのポイントとしてフレームワークを使う側から作る側になる(from a framework customer to a framework creator)ことが必要で、そのためにはデザインパターンを学んだ方が良いよっていう動画を見て「確かに〜頑張るぞ💪」ってなりました。

2冊の本の読み方

私たちは2人とも Rubyist なんですが、Rubyデザインパターン本が絶版ゆえにネットで高値が付いて買い辛かったことと、デザインパターンを言語に偏りなく勉強したいという思いもあって結城さんの Javaデザインパターン本をメインに読みました。Java は基本文法を勉強したことがある程度でしたが、サンプルコードの内容はほとんど理解できましたし、Java 特有の書き方、ライブラリには説明が付いていたので混乱することも少なかったです。

でも途中(5章あたり)から、やっぱり Ruby で書くなら?が知りたいと思って Rubyデザインパターン本をお互いゲットして Java 本で勉強したパターンを Ruby 本でも読むというやり方に切り替えました。けれど Ruby 本は Java 本ほど分かりやすく書かれておらず…難しくて Ruby 本は挫折…結局 Java 本に専念しました。残念😢

そして、最後の方(18章あたり)はお互いのスケジュールの関係で同期的な読書会から、非同期で各自本を読んでチャットで意見交換するスタイルになったのですが、その頃に Ruby 本にもう一回挑戦してみようと思い読み始めたら想像以上にサクサク読めました。成長してる〜嬉しい😌

Javaデザインパターン本について

読みやすい文章で丁寧に解説が書かれている点やパターンごとの構成が統一されている点が分かりやすくて良かったです。慣れるまではシーケンス図やクラス図からプログラムをイメージするのが難しかったり、構成に戸惑ったりして読むのに時間が掛かりましたが、慣れてくると読むスピードがどんどん上がりました。

パターン内の構成は最初に概要があって、サンプルプログラムがあって、UML での解説や発展的な内容、補足に繋がっていく形なんですが、前半のサンプルプログラムを読んでるときは、どういうこと?🤔何でこうやって書くんだろう?🧐と疑問点が出てきて。でも後半の解説でその伏線を回収してくれるので、パターン内のページを行ったり来たりしているうちに納得感が増して、理解に落とし込むことができました。

あと関連するパターンの紹介では、最初の方は他のパターンを知らないので全然分からん…となってましが、後半はあぁ確に目的が違うだけで構造は似てるってことか。とか、この一部の実装を別のパターンで対応できるってことか。とか、分かるようになってきてデザインパターンの理解が進んでることを実感できましたし、過去のパターンを復習するキッカケになったりして良かったです。

物足りないところは実務で使う具体例が少ない点で、実際にどういう場面で使うんだろう?が分からないことが多かったので、ネットでサンプルコードを探して、実務で使うイメージが少しでも持てるよう努力をしました。

サンプルコードが良かった記事メモ

また、Java のサンプルプログラムを VSCode のエディタシェア機能を使って Ruby に書き直したりしました。シェア機能が思ったよりもサクッとできて楽しかったです。

GitHub - dobby618/design_patterns: 学習用「Java言語で学ぶデザインパターン入門」を Ruby で書き直す

Rubyデザインパターン本について

初めて読んだときは読んでるうちに「いまなんの話をしてるんだ…?」になりやすく、難しく感じたので途中で挫折しましたが、Java 版を読み終えるころに再読したらスッと読むことができました。Ruby 版は Java 版に比べると具体例が豊富だったり、RubyRails でどう使われているのか?の解説もあったりしてデザインパターンの理解が進みました。他にもブロックを渡す形やmethod_missingeval など使ったサンプルプログラム、Ruby ならではの注意点なども書かれていたので読んで良かったなと思いました。

また、Ruby 版のサンプルコードは以下の記事にほぼそのまま掲載されているので、絶版で買えない方にも参考になると思います。ただ一度も書籍を読んでない人には少し難しいかもしれないです。

Rubyによるデザインパターンまとめ - Qiita

デザインパターン本を読んだ感想

ライブラリやクラス名にデザインパターンの名前が使われていると、それが何なのか?何のためにあるのか?どうやって使ってほしいと思って作られたものなのか?などの理解が俄然やり易くなりました。

あとパターン名はソースコードだけでなく、例えばサーバとクラアインとの間に置かれる Proxy サーバでも使われているので、キャッシュの保持はリモートプロキシの考え方で、セキュリティ面では防御プロキシだよねって理解できて、あぁこれもパターンだったのか💡という感じでパターンを通して新しい繋がりを見つけられるようになってきました。嬉し楽しい😆なのでデザインパターンを一度体系的に勉強できてホント良かったです。これからはデザインパターンを使いこなせるように精進したいです。

読書会の感想

デザインパターン読書会は朝の時間から始まり、一年かけて丁寧に読み進められて良かったなぁと思います。途中、時間がかかり過ぎて終わるのか…?と不安になったこともありましが、結果的に時間をかけたことで実務や他の本からも少しずつ影響を受けながらデザインパターンの理解を深掘れた気がします。後半は時間が合わなくて非同期に各自で読んでチャットで気になったことをシェアする形になりましが、katorie さんと一緒に声を出して読んでた時期が長かったので、一人で読んでても隣に katorie さんがいる感覚で楽しく読めました。またスケジュールがあったら何か読みたいです。

終わりに

長い間、読書会お疲れさまでした(^ω^)1人だと絶対挫折してただろうし、こんなに深く理解することもできなかったと思うので、katorie さんと一緒に読書会ができて良かったです。あと katorie さんとは技術力のレベル感が同じぐらいで、一緒に成長してく感じがとても楽しかったです。ありがとうございました😊

読書メモ:オブジェクト指向でなぜつくるのか

f:id:meikotan:20210330140725j:plain

オブジェクト指向でなぜつくるのか 第2版の読書メモです。

オブジェクト指向プログラミング(OOP

1. オブジェクト指向はソフトウエア開発を楽にする技術

オブジェクト指向が混乱や誤解を招く理由が書かれていた。私がオブジェクト指向について初めて勉強したときは、説明の中に犬とか猫が出てきた気がする。その比喩では混乱したというより具体的にどう実務のコードに落とし込めるのかがさっぱり分からなかった記憶がある。だから具体的なコードが盛り込まれてる、これらの本

を読んで初めて実務に落とし込む感覚が見えてきたんだよな。でも他人にオブジェクト指向を説明するときは、やっぱり比喩で話してしまうと思う。例えば「大学」クラスにインスタンスが具体的な大学名で、「大学」クラスのスーパークラスが学校で、みたいな話をしたことがある。。

2. オブジェクト指向と現実世界は似て非なるもの

オブジェクト指向が現実世界とどう違うのかが書かれていた。「クラスの位置付けが違う、現実世界の人は自分で判断して行動する。」その通りすぎるんだけど、そこを深く突っ込んで違いを考えたことがなかったから明文されていて気持ちよかった。あとポリモーフィズムの説明「相手が具体的にどのクラスのインスタンスであるのかを意識せずにメッセージを送れる仕組み」、継承の「似たもの同士のクラスの共通点と相違点を整理する仕組み」という表現が明瞭で素敵だった。

3. OOP を理解する近道はプログラミング言語の歴史にあり

機械語でプログラムを書いていた時代からのプログラミング言語の歴史が書かれていた。ITは基本的に過去の改良を繰り返してる世界だから、対象がなんのために出来たのか?という話は、対象の理解を助けてくれるから好き。同じプログラムが機械語アセンブリFORTRAN で書かれてるところが面白かった。16進数で書かれても全然分からん。当時は if や for もローカル変数もなかったのかぁ。クラスもないから結局はグローバル変数を使わなきゃいけないんだって。大変。。

コラム:プログラミング昔話

ちょうどデザインパターンインタプリタパターンを勉強していて、普段使ってる Ruby は C 言語のインタプリタで解析して機械語にされるってことか!じゃぁ C 言語はどうやって…?と考えていたときのコラムだったので、まさか最初は機械語コンパイラを作っていたことにビックリした。

4. OOP は無駄を省いて整理整頓するプログラミング技術

オブジェクト指向の基本的な仕組みの説明でした。インスタンス変数は仲間内(クラス内)だけのグローバル変数、ポリーモーフィズムはサブルーチンを呼び出す側のロジックを共通化する仕組みという説明は新しい視点だった。また、人間が良いプログラムが書けるよう、間違いにくいよう機能が取捨選択され、新しい言語が作られていることが分かった。あと、C 言語と C++ の違いが曖昧だったけど、そもそも C 言語は言語として OOP の仕組みを実装していないことを知った。だから無駄が生まれないし、組み込み系で使われるのか。

f:id:meikotan:20210321143717j:plain:w450
プログラミング言語の進化

5. メモリの仕組みの理解はプログラマのたしなみ

オブジェクト指向で書いたコードがメモリにどのように展開されているのかが書かれていた。これまでの私は「メモリリークを避けるため、大きいデータを読み込むとき(メモリ展開するとき)は一行または数行ごとにする」は意識していたけど、メモリ内部の領域のことやクラスやインスタンスが、どのメモリ領域に展開されているのか?など考えたことがなかった。ポリモーフィズム、継承ではメソッドテーブルが共通化を支援している。これはオブジェクト指向言語自体がどうやって実装されているのか?に繋がるね。メソッドテーブルは仮想関数テーブル(VTable)とも呼ばれるよう。そしてそれを C 言語では自前で実装するらしい。(参考:C言語とオブジェクト指向)この仕組みが分かったら実装できそうな気がしちゃう。

f:id:meikotan:20210321143708j:plain:w350f:id:meikotan:20210321143726j:plain:w350
オブジェクト指向プログラミングのメモリの仕組み

6. OOP がもたらしたソフトウエアとアイディアの再利用

フレームワークデザインパターンについて書かれていた。ちょうど Javaデザインパターンを読み終えたばかりだったので

このようにデザインパターンが使われていることがわかると、そこから開発者の意図を汲み取ることができます。そしてそれにより、適切な利用方法の理解にもつながりま す。

に大いに納得。ハリウッドのくだりで書かれていたフレームワークとライブラリの違い、自分の認識と合っていて良かった。コンポーネントという用語はクリーンアーキテクチャ本でも使われていて、具体的なイメージが未だに曖昧。本の中でも漠然としていた。

7. 汎用の整理術に化けたオブジェクト指向

オブジェクト指向下流工程の「プログラミング技術」と上流工程の「汎用の整理術」という2つの顔を持つことを押さえておいてください。

はい。認識曖昧でした。
現実世界をプログラミングに…じゃなくて、プログラミング技術が先にあって、それが後に整理術に変化した。その考え方ならプログラミング技術の枠は超えないよね

コラム:オブジェクトの向こう側

プログラミング技術のためにコンセプトを作ったわけじゃないんだね。当時、アラン・ケイ氏はこのコンセプトが現実世界のモデル化に使われると思ってたのかな。

8. UML は形のないソフトウエアを見る道具

目的に合わせた UML の使い方が書かれていた。クラス図やシーケンス図、ユースケース図も全部 UML だってこと知らなかった。未だに UML 自体がバージョンアップされてるんだね。

f:id:meikotan:20210321145656j:plain:w350f:id:meikotan:20210321145701j:plain:w350
UML バージョン2で定義されている13種類のダイアグラム

図がプログラムを表現するために使われているのか?整理するために使われているのか?意識したことなかった。私は上流工程に関わることが少ないので、 UML を見る機会としては技術系の書籍(デザインパターンとか)が多いから、プログラミングを表現するために使われているイメージが強い。

シーケンス図でプログラムを動きを表現するとき、メソッドの矢印と実際のコードを結び付けるのによく混乱していた。。でも、整理術で仕事の流れを表現する場合は理解しやすいと思った。あと UML を言語やプログラムでは理解し辛いものを図で分かりやすく表現するための補助ツールとして割り切ってるところが良い。

9. 現実世界とソフトウエアのギャップを埋めるモデリング

ソフトウエアに落とし込むためのモデリングが3ステップで書かれていた。段階的にステップを踏むことで現場の様子からコンピューターに肩代わりさせる部分を分けることができる。これまで自分でモデリングをしたのはツールや規模の小さいサービスが多かったから、正確に3ステップを踏んだことがなくて、"こんな感じ"の感覚で押し切ってた節あるなぁ。業務分析をキチンとやってみたいな。

「業務分析と要求定義をおろそかにすれば、最終的に利用者にとって役立つシステムは決して作れないでしょう。」は心にグサッときた。以前に作ってた個人開発アプリの業務分析と要求定義を試してみたくなったし、モデリングの参考書籍で紹介されていた本も読もうと思った。

10. 擬人化して役割分担さえるオブジェクト指向設計

良い設計のためのポイントが書かれていた。特に意識せずとも依存関係を循環させたことないんだけど、そもそもオブジェクト指向プログラミングが出来てなかったんだろうなぁと思った。増補改訂版Java言語で学ぶデザインパターン入門の Memento パターンで紹介されていた「カメラで写真を撮ってフィルムに記憶する」という例えは、まさに擬人化。

11. オブジェクト指向から生まれたアジャイル開発と TDD

ウォーターフォール開発プロセスの問題点である、動かして初めて分かる課題へどう対応するかの解決策として反復型の開発プロセスがあり、アジャイル開発はその総称として使われている。これまでアジャイル開発という言葉が私の頭の中で一人歩きしていて定義が曖昧だったけど、反復型であることが分かりスッキリした。そしてアジャイル開発のプラクティスとして TDD やリファクタリングがあるのも納得できる。小さなイテレーション単位で開発を行う考え方はフィードバックが早く貰えるということで、TDD はアジャイル開発の考え方をプログラミング作業に取り入れている。

12. オブジェクト指向を使いこなそう

これまでのまとめが書かれていた。サービス指向とマイクロサービスの違いが気になったので調べた。

参考)SOAと何が違うのか、マイクロサービスの要点を4項目に整理 | 日経クロステック(xTECH)

SOA(サービス指向アーキテクチャー)は主に業務プロセスとソフトウエアサービスの分離や、既存のソフトウエア資産の再利用を主目的としている。概念は比較的難解で、実現するためには複雑な技術の理解、ミドルウエア製品の導入などが必要だ。また、SOAでは「分割されたシステム(サブシステム)間の連携をつかさどる部品」が必要となる。この部品はオーケストレーションと呼ばれ、SOAを導入したシステムはオーケストレーションを軸にした一極集中の構成をとる。そのため、オーケストレーションが性能やシステム改修頻度など、さまざまな局面でボトルネックとなることが課題である。

一方、マイクロサービスアーキテクチャー(MSA)ではソフトウエアに対して段階的な機能追加を可能にすること、管理をより簡単にすることなどが主な目的だ。SOAと比較して概念はシンプルで、導入にあたって押さえるべき要素技術も複雑ではない。システム間の連携をつかさどるオーケストレーションのような仕組みも必須ではないため、ボトルネック問題も生じにくい。

13. 関数型言語でなぜつくるのか

純粋関数型言語の特徴を従来のプログラミング言語との比較を交えつつ書かれていた。 関数型言語についての私の知識

  • Ruby関数型言語の影響を受けている(?)map や reduce などのメソッドがある
  • Ruby 2.7 で追加されたパターンマッチ機能は関数型言語で使われている機能である
  • ハッキリ理解してるわけじゃないけど 副作用がない という言葉を聞き齧ってる

レベルです。でも本章の導入クイズで関数型言語へグッと引き込まれた。想像以上に純粋関数型言語の仕様は制約が多く、従来のプログラミング言語とサポートしている機能が全然違っていることに驚いた。この制約のながでプログラム書いてみたい〜という欲が出てテンションあがった。次に「[増補改訂]関数プログラミング実践入門 ──簡潔で、正しいコードを書くために」を読む予定だったので、このタイミングでこの関数型言語の大枠の考え方、特徴を理解できてよかった。

感想

言葉が明瞭。重要な単語をぼぼ一言表現している箇所が分かりやすかった。また、混乱するであろう部分は丁寧に切り分けながら順序立てて解説してくれるところが良い。既に自分が理解してる箇所では再確認と新しい視点をもらったし、自分の足りない部分(モデリング関数型言語)では深堀を参考書籍で勉強しようと思えた。

日本語がほとんど喋れない人が先輩になったときに気をつけたこと

ボラバイトで北海道の牧場に行って、日本語がほとんど喋れない人が私の指導担当(先輩)になりました。私が仕事を覚えきれていない最初の3日は特に辛かったのですが、1週間で慣れてきたので振り返ります。(まだボラバイトは終わってないです)

チーム構成

日本人のリーダー、ベトナム人の先輩2人、私(新人)で、職場の公用語は日本語です。

先輩2人の日本語は最低限の単語(できる、違う、教えるなど)が言えるけど、焦ると日本語が出てこなくなり、あれそれの指示語が多くなるレベルです。

苦労したこと

仕事の目的を教えてくれない

仕事の手順を教えてもらうときに「なぜそれをやるのか」を伝えられないまま、次はこれ!次はこれ!と教わったため、手順を覚えるのに苦労しました。例えばバケツに水を貯める作業が何回かあるのですが、あるときは冷たい水、またあるときはお湯入れる。それを教わるときは次はお湯入れて!次は水入れて!と言われるだけだったので頭の中で記憶として紐付けるのが難しかったです。日本人のリーダーがその場にいれば、お湯だとタオルが臭くなるから水にしている、などの理由を教えてくれました。

先輩たちが仕事の目的を教えられない理由は、まずそれを伝える日本語が拙いので省略しているから。あとは本人も目的を理解していない場合もありました。仕事に余裕が出てきた4日目ぐらいに、なんでこうするの?と聞いたら「こうやって教わった。分からない」と言っていました。とほほ。

見せるだけでポイントを教えてくれない

仕事はほとんど見て覚える式なのですが、どこを見てほしいのか、何がポイントなのかを教えてくれないので、見様見真似でやってみても合ってるのか分からず…感覚を掴むのに苦労しました。とりあえずやってみる→「違う!」と言われて見せらる→やってみる→「違う!」…を何度か繰り返して、やっとコツを掴めることが多かったです。

例えば、洗車機を使って牛の搾乳室を洗う仕事では、牛を識別する機械を濡らさないように注意する必要があるのですが、これは水が飛び散らないように対象に洗車機を近づけて噴射する必要がありました。しかし、見様見真似ではそのコツを習得することはできず、結局、日本人のリーダーに使い方を教わりました。とほほ。

固有名詞で指示してくれない

指示は物の名前ではなく、青いの!白いの!これ!あれ!と言われることが多く、近くにいれば理解できるのですが、2mぐらい場所が離れると何が言いたいのか分からないことが多くて苦労しました。また、自分の日本語の指示が私に伝わらないと舌打ちをされたり、大きな声で何度も同じこと言われました。別の表現に言い換えられないので、ただ感情をぶつけるしか選択肢が残ってないんだろうなぁと思います。とほほ。

動詞の変形が使えない

やって。やる。やった。ぐらいは使えますが、細かいニュアンスの動詞の変形が使えないので私の方で常に脳内変換する必要があり今でも苦労しています。例えば、前日に教わったことを「覚えてる?」と聞きたいのに、「覚える?」と聞かれるので、私はこれから新しい仕事を教わるんだと考えたのですが、結果は確認の声掛けでした。とほほ。

気をつけたこと

気持ちで負けないために声を出す

これが一番大事ですが、先輩たちは自分の指示が伝わらないことで不機嫌になる人たちなので、気持ちが押し切られちゃうと相手のペースに揉まれ、焦ってしまいます。その対策として私は「はい」「わかりました」「ありがとうございます」などの掛け声を大きく出し気合いを入れていました。気持ちを対等に保っておくことで冷静になれます。

慣れてくると相手の日本語が聞き取れないときは「どれ?どういう意味?」と聞き返せるようになり、それも相手のパワーに負けない気持ちで声を出していました。

何が言いたいかを聞き取ることに集中する

声が大きい、語尾が強いなどの表現方法は無視して「この人は何が言いたいのか?」だけを聞き取ることに集中しました。そうすると多少表現がキツくても、言いたいことが理解できれば「了解👌」という気持ちしか生まれなくなりました。

復唱して確認する

相手に伝わってるか分からなくても、こういうこと?と確認するようにしていました。そうすると大体「うん(合ってる)」的なことを言ってくれます。もちろん「うん」と言われても合ってないことは多々ありましたが、たまに間違ってる場合は「違う!」と言ってくれました。

今なにしたら良いのか聞く

先輩は私がミスしたことに対して「これ間違ってる!」「こうするんだよ!」的なことを教えくれますが、教わったあと、私はこれから言われた指摘を修正するの?自分の仕事に戻っていいの?と迷うことが多かったです。なので相手の話を聞いたあとは「今なにすればいいの?」と聞くようにしていました。そうすると「やって」と言われて、自分の仕事に戻れることが多かったです。

確認するときは熟語を使わない

例えば先輩がジェスチャーで洗車機の噴射を端から端まで往復してほしそうな指示をされた場合、確認で「往復」という熟語を使っても多分伝わらないので、私も端と端を指すジェスチャーを交えながら「こっちに行って、こっちに行くってこと?」と聞くようにしてきました。

辛いときの対処法

泣きましょう。友達に愚痴りましょう。

感想

日本語が拙い人が部下ならまだしも、先輩の場合はもう二度とやりたくないと思いました。話すときは私が相手の日本語を脳内変換をするので、常に集中力と強い気持ちも必要です。また、慣れないうちは感情をぶつけられるのも心がやられました。

今はもう1週間、この牧場で働いて仕事を覚えてきたので先輩たちに注意されることも減りましたし、話しかけられても何が言いたいか理解しやすくなりました。よかった。辛かったことも含めて良い経験でした。

Recommend sightseeing spots of Shimanami Kaido and Imabari in Ehime prefecture

I translate "しまなみ海道 & 今治 オススメ観光スポット - FreeDrop" into English.


This travel presupposes that you have a car.

Sunrise Itoyama(Rent-a-cycle)

If you want to cross the Shimanami Kaido Bridges by bicycle, I recommend you rent a bicycle here. There are lots of parking lots and rentable bicycles, and the waiting room is clean. Also, You can climb the Kurushima Kaikyo Bridge that is the first bridge in the Shimanami Kaido Bridges, in no time because the distance from the place to rent a bicycle to that bridge is short. During the busy season, such as Golden Week, you may have to wait to rent a bicycle, so if possible, you should rent it from the day before. I have waited 3 hours at Golden Week in the past.

Also, in the middle of the Kurushima Kaikyo Bridge, there is an island called Umashima that you can only land by bicycle and walking(and get off using the elevator). You can go around it for about 10 minutes. It would be best if you went there.

✅ HP: 今治市サイクリングターミナル サンライズ糸山

Michi-no-Eki "Yoshiumi Iki-Iki KAN"

There is in Oshima that is the first island in the Shimanami Kaido. It is located just off the Oshima interchange.

Ocean weather ship of Quickwater at Strait of Kurushima

You can see the huge whirlpool in front of you. Also, a Guide on the ship talks about "Shimanami Kaido" and "Murakami Suigun" to learn about the history of the area.

f:id:meikotan:20201203071232j:plain

The ship ticket becomes a discount coupon for the seafood BBQ, so you should get on before the BBQ.

✅ HP: 来島海峡急流観潮船(うずしお体験) / 株式会社しまなみ

Seafood BBQ

You can choose the fish and shellfish yourself you want to grill them. Depending on the season, you can eat one whole octopus and many kinds of shrimp. Even if I have eaten lobster, abalone, many other and miso soups, it was about 5,000 yen per person. That is a good price!

If you can eat sashimi, I recommend you try it. The fish are fresh and thick, and the shellfish's texture is crunchy.

f:id:meikotan:20201203071344j:plain

✅ HP: 海鮮七輪バーベキュー / 道の駅 よしうみいきいき館

Kirosan Observatory Park

One of the most marvelous viewing spots along the Shimanami Kaido. It became second place in 【Travel lovers choose! Ranking of viewing spots in Japan at 2017】. It's located less than 10 minutes by car from "Yoshiumi Iki-Iki KAN". If the weather is nice, you can see the shape of the tide and feel the beautiful blue color of the sea.

✅ HP: 亀老山展望公園 | 四国松山 瀬戸内松山|松山市公式観光情報サイト

Nomauma Highland Horse Park

It's free. You can easily meet Nomauma horses. It's cute. You can use this spot to kill time this spot. There are many mosquitoes, so be careful.

✅ HP: のまうまハイランド

Imabari Towel Main Shop

<< Caution >> Not a Towel Museum.
Imabari towels have quality standards, so many manufacturers that have passed the standard make them. Therefore, there are many types of white towels, and you feel fun to compare the feel of the towel, such as hardness, fluffiness, and hair length. Also, You can get handkerchiefs or towels for children that are perfect as souvenirs.

Also, there is a towel lab in front of the shop where you can experience the process of making Imabari towels. If you have a clerk, you can learn about the historical background and how to use the equipment, or you can have the automatic towel maker run on the spot. You can experience the awesome water supply of Imabari towels compared to other towels in the towel lab, and you will definitely want to buy Imabari towels.

※ Differences from the Towel Museum.
The Towel Museum sells not only Imabari towels but also various towels from all over the country. So there are only a few Imabari towels in the Towel Museum. If you are looking for Imabari towels, I strongly recommend you to go to this Imabari Towel Main Shop.

✅ HP: 今治タオルオフィシャルオンラインストア | 今治タオル公式通販サイト | 店舗リスト

The ruins of Imabari Castle

The spotlight illuminates it at night, and it's cool. You can see it just by driving across it.

✅ HP: 今治城 | 今治市 文化振興課

Imabari Yakitori "Seto"

Imabari has a local cuisine called "Imabari-yaki," which is made by grilling yakitori skin on a hot iron plate. I recommend the restaurant "Seto". This Chef feels unique, but everything is delicious. he serves like a course cuisine in the order in which you can eat it deliciously.

f:id:meikotan:20210221125654j:plain

✅ HP: 今治やきとり盛り上げ隊/やきとり店訪問/世渡

Orange sales "Ikkokuya"

If you want to choose oranges while having the shop staff teach them the types of oranges, I recommend. There are sweet or refreshing oranges. Also, I think it's interesting because they sell not-fresh oranges at low prices.

The season for oranges is in winter. There are oranges in summer, but various oranges are in the winter, as shown in the photo. In the summer, there are also Watermelons and other fruits.

f:id:meikotan:20210223042648j:plain

✅ HP: 一国屋(いっこくや)(食料品・お酒) | まいぷれ[西条市]

Public bath "Kiyomasa-no-Yu"

There is hot and loose spring, a sauna, and the dressing area is wide so that you can relax. The hot spring color is transparent and has not slimy, and it warms your body well.

✅ HP: 大浴場 | ようこそ 5500坪の温泉郷へ 四国の名湯清正乃湯

Extra edition

Airport

There is "Michan" in the waiting space for international flights and a photo booth with her frame. It's minor and almost unoccupied.

f:id:meikotan:20210223042359j:plain

✅ HP: 松山空港に新スポット/みきゃんをモチーフにした『MICAN Garden』|トピックス&お知らせ|愛媛県の公式観光サイト【いよ観ネット】


[Official]Imabari City Tourism Map (English)

Proxy パターン for Ruby / Rails

この記事は本の感想、備忘録です。

Proxy パターン

Proxyは代理、委任という意味なので、 Proxyパターンとは、オブジェクトへのアクセスする際に代理のオブジェクトを使うようなデザインパターンです。 (by Technologic Arts | Proxyパターン

f:id:meikotan:20210223124521j:plain

Proxy の実装ポイントは RealSubject とインターフェースを同じにすることです。(透過的)

Main は実際に呼び出すのが Proxy でも RealSubject でも気にしません。RealSubject を直接利用しても、間に Proxy が入っても、問題なく使用できます。

それではなぜ Proxy を置くのでしょうか?目的は主に3つです。

オブジェクト生成の遅延(Virtual Proxy)

RealSubject のオブジェクト化コストが高い場合に有効です。RealSubject が実際に使われるまでオブジェクト化を遅延できます。

class BankAccount
  attr_reader :balance

  def initialize(starting_balance = 0)
    @balance = starting_balance
  end
end

class VirtualAccountProxy
  def initialize(&creation_block)
    @creation_block = creation_block #DI
  end

  def balance
    s = subject
    s.balance
  end

  def subject
    @subject || (@subject = @creation_block.call)
  end
end

account = VirtualAccountProxy.new { BankAccount.new(10) }

アクセス制限(Access Proxy)

ロキシーを使ってアクセス制御を行うと、関心事の分離を上手に行えるという利点があります。 プロキシーが気にするのは、何をすることが許されているのが誰で、許されていないのが誰なのかということです。

class AccountProtectionProxy
  def initialize(real_account, owner_name)
    @subject = real_account
    @owner_name = owner_name
  end

  def balance
    check_access
    @subject.balance
  end

  def check_access
    # ユーザ検証処理
  end
end

ロキシーにセキュリティを実装することにより、簡単にセキュリティ指針を変更したり(サブジェクトを違うプロキシーでラップする)、あるいはセキュリティを一気に取り除く(プロキシーのラップをやめる)ことができます。 それ故にセキュリティの実装に踏み込むことなく BankAccount オブジェクトの実装を変更することも可能です。

Proxy サーバ

Proxy という用語はサーバへのアクセスの踏み台として使われる Proxy サーバの方が身近かもしれません。Proxy サーバ設置の目的はネットワークセキュリティです。社内サーバやお客様サーバにアクセスするときに社内にある Proxy を経由してアクセスする仕組みになっていることが多いです。これもアクセス制限という関心事をプロキシーに分離している構造です。
f:id:meikotan:20210223123144j:plain

オブジェクトの置き場所の隠蔽(Remote Proxy)

クライアント機のプログラムからネットワーク越しの BankAccount オブジェクトにアクセスしたい場合、クライアント機にリモートプロキシーを置き、プロキシー経由で BankAccount オブジェクトにアクセスすることでネットワーク通信部分の処理をプロキシーに任せることができます。

クライアントから見ると、本物の BankAccount オブジェクト上のメソッドだと思って呼び出し、しばらくして(ひょっとすると、かなり長い時間が経った後に)返事が返ってきます。これが、全てのリモートプロシージャコール(RPC)システム動作のほとんどすべてです。

キャッシュサーバ

Web サーバの表示速度を上げるためにクライアントとサーバの間にキャッシュサーバを置くことがあります。これも同じ構造です。

Web ブラウザがある Web ページを表示するとき、いちいち遠隔地にある Web サーバにアクセスして、そのページを取得するのではなく、HTTP プロキシーがキャッシュしてあるページを代わりに取得します。最新情報が必要になったときやページの有効期限が切れたときにはじめて、Web サーバに Web ページを取りに行くのです。

RPC(リモートプロシージャコール)

この構造を知っていると複雑そうに見えていた RPC(遠隔手続き呼出し) の理解が容易になりました。

gRPC(Google RPC)は Google がプロキシの定義方法や通信方法を定めた RPC なのかな。マイクロサービスのサービス間通信でも使うし、もちろん RESTful API の代替にもなる。なるほど。
👀 トレンドマイクロ セキュリティブログ安全を保つためのgRPC実装の注意点を解説 | トレンドマイクロ セキュリティブログ

Adapter との違いは?

Adapter パターンと Proxy パターンはあるクラスをラッピングするという構造は同じですが、ラッピングするクラスが透過的であるか否かが異なります。Adapter パターンは Main が扱いやすいように Subject のインターフェースを変換するパターンです。そのため透過的とは言えません。Proxy パターンは Subject へのアクセスを何らかの形でコントロールするためのパターンで、Proxy が透過的であるが故に、そのコントロールをいつでも無効にすることが可能です。

しまなみ海道 & 今治 オススメ観光スポット

前提は「車」があることです。

サンライズ糸山(自転車貸し出し)

しまなみ海道の橋を自転車で渡る場合、ここで自転車を借りるのがオススメです。駐車場も自転車もたくさんあるし、待合室も綺麗です。あと自転車を借りる場所から来島海峡大橋までの距離が近いのであっという間に橋に登れるのも◎。GW などの繁忙期は自転車借りるのに待つこともあるので、余裕がある人は前日からレンタルしておくと良いと思います。(私は GW で3時間待ちしました😂)

あと来島海峡大橋には自転車でしか降りれない(しかもエレベーターで降りる)馬島という島があり、一周10分ぐらいで周れるので行ってみて!

今治市サイクリングターミナル サンライズ糸山

よしうみいきいき館(道の駅)

今治からのしまなみ海道 1 つ目の島「大島」の道の駅です。大島のインター降りてすぐです。

来島海峡急流観潮船(うずしお体験)

船には必ずガイドさんがいて「しまなみ海道」のこと「村上水軍」のことなどず〜っと喋り続けてくれるので飽きずに観船できます。あと海や島が全部近いので迫力もあるし、天気が良い日は潮がバンバン飛んできて気持ちいです。

f:id:meikotan:20201203071232j:plain

観潮船のチケットは海鮮七輪 BBQ の割引券になるので、BBQ 前に乗るのがオススメです。

来島海峡急流観潮船(うずしお体験) / 株式会社しまなみ

海鮮七輪BBQ

自分で BBQ にする魚や貝を選んで焼いて食べれる場所です。季節によって丸ごとタコが食べれたり、エビの種類も豊富だったり。刺身の種類も季節で変わるのでいつ来ても楽しいです。伊勢海老、アワビ、他にもたくさん、締めの味噌汁まで飲んでも1人5,000円ぐらいでした。安い!

個人的には焼くより刺身派なのですが、同じように刺身派な人は絶対頼んで欲しいです…!本当に新鮮で鯛とかブリとか肉厚がすごいし、貝はコリコリです。

f:id:meikotan:20201203071344j:plain
ミル貝とアジのお刺身

海鮮七輪バーベキュー / 道の駅 よしうみいきいき館

亀老山展望公園

しまなみ海道の写真といえば!な絶景です。【旅好きが選ぶ!日本の展望スポット ランキング 2017】では堂々の第2位になりました(1位は清水寺)。天気が良ければ、潮の形が見えたり、海の色が綺麗なことも感じれると思います。よしうみいきいき館から車で10分もかからない近さなので、天気が良いときは絶対行って欲しいスポットです。

亀老山展望公園 | 四国松山 瀬戸内松山|松山市公式観光情報サイト

のまうまハイランド

無料です。サクッとのまうまに会えます。可愛いです。時間潰しにも使えるスポット。蚊が多いので気をつけて。

のまうまハイランド

今治タオル本店

《注意》タオル美術館ではないです。
今治タオルは「今治タオル」というメーカーがある訳ではなく品質基準なので、その基準をクリアした多くのメーカーが今治タオルを作っています。そのため白いタオルだけでも数十種類存在していて、硬さやふわふわ感、毛の長さなど触り心地を比較してるだけでも楽しいです。あと子供向けやハンカチなども種類が多いのでお土産にも最適です。

また、お店の手前にタオルラボがあり、今治タオルができる工程を体験できます。店員さんがいれば歴史的な背景や機器の使い方などを教えてもらうことも出来ますし、自動のタオル製造機をその場で動かしてもらうこともできます(大迫力です!)。他のタオルとの比較実験スペースでは今治タオルの給水力の凄さも体験できるので、今治タオルを買いたくなること間違いなしです。

※ タオル美術館との違い
実はタオル美術館は今治タオルだけでなく、全国色々なタオルを集めている場所です。なのでタオル美術館には今治タオルがほんの少ししかありません。今治タオルを求めてる方はこちらの今治タオル本店に行くことを強くオススメします。

今治タオルオフィシャルオンラインストア | 今治タオル公式通販サイト | 店舗リスト

今治城

夜はスポットライトが当たっていてカッコ良いです。車で横通るだけでも「おぉ!」ってなります。

今治城 | 今治市 文化振興課

世渡(今治焼き)

今治は「今治焼き」という焼き鳥の皮を鉄板で焼いて出す形が風土料理になっていて、私のオススメのお店は「世渡」です。大将は独特な感じですが全部めちゃくちゃ美味しいです。適当に頼んでも美味しく食べれる順番に、コース料理のように出してくれるので心地良いです。

f:id:meikotan:20210221125654j:plain

今治やきとり盛り上げ隊/やきとり店訪問/世渡

一国屋(みかん🍊の直売所)

お店の人と交流してみかんの種類を教えてもらいながら、みかんを選びたい人向けです。甘いみかんもあれば、サッパリ系もあります。また、日数が経って甘さが薄まったものは安く販売してたりするので、そういうのも面白いなぁと思います。県外の友達へのお土産やプレゼントでも、値段を言えば良い感じに美味しいみかんをチョイスして発送してくれるので、とても安心感があります。

一国屋は最近店舗が新しくなったようです。写真は前の店舗のものです。あとみかんの季節は冬です。夏にもみかんはあるそうですが、写真のようにみかんの種類が豊富なのは冬だけです。夏はスイカとか他の果物も置いてあります。 f:id:meikotan:20210223042648j:plain

一国屋(いっこくや)(食料品・お酒) | まいぷれ[西条市]

清正乃湯(銭湯)

愛媛は温泉が多く、どこも特徴があって楽しめると思いますが、私がよく通っていたのは「清正乃湯」です。熱い湯も緩い湯もサウナもあり、脱衣場もすごく広いのでゆっくりできます。温泉の色は透明でクセもなく、しっかり体を温めてくれます。

大浴場 | ようこそ 5500坪の温泉郷へ 四国の名湯清正乃湯
清正乃湯(愛媛県今治市) - サウナイキタイ

番外編

お土産

■ ちゅうちゅうゼリー(有限会社田那部青果)
空港の1階、「蛇口からみかんジュース」のお店で買えるちゅうちゅうゼリーが一番美味しいです。
田那部青果 愛媛果汁のちゅうちゅうゼリー | 商品詳細 | ANA FESTA

■ どら一(いち) 塩バター(畑田本舗)
あずきが嫌いな私も好きです!
どら一(いち) 塩バター|商品情報|銘菓ハタダ栗タルト 畑田本舗

■ 瀬戸内鯛めしの素(程野商店)
これは空港にはなくて、道後温泉前のお土産屋さんしか置いてないかもです💦
炊き込みごはんの素 瀬戸内 鯛めし 株式会社 程野商店

■ 鯛せんべい
大人数向けのお土産としてオススメです。私が買ってたブランドが分からなかったけど、鯛せんべいは全部美味しいと思います!

空港

国際線の待合ホームには「みきゃん」がいます。可愛いです。みきゃんがフレームのプリクラもあります。マイナーでほぼ人いないので、空港で時間が余ったらぜひ寄って欲しいです。 f:id:meikotan:20210223042359j:plain

松山空港に新スポット/みきゃんをモチーフにした『MICAN Garden』|トピックス&お知らせ|愛媛県の公式観光サイト【いよ観ネット】