リアル牧場物語 in 北海道

ボラバイトとして2ヶ月間(9週間)北海道の牧場で働きました。その振り返りです。

牧場でどんな仕事をしたのか？は note - マガジン にまとめています。

きっかけ

今年、オランダへワーホリする予定だったんだけど、コロナの影響で行けず。でもワーホリを調べてたときに牧場等でボランティアをしてる人もいるという情報を知り、牧場の仕事って面白そうだなぁと興味を持ったのがきっかけ。あと感覚的なことだけど、近頃「よく分からないけど動物に触れたい願望」が強まってる気がしてて、もともと苦手だった動物が可愛いと思えるようになったり、サファリパークでゾウやキリンに触れるようになったり。なので牧場に行こうと思えました。

牧場の選び方

以下の3つを条件に入れて検索しました。時期もあったのか私の場合は2件しかマッチせず、1日の休み時間が長い（まとまった時間取れる）牧場を選びました。
※ 牧場の仕事〜1日のスケジュール〜

• 個室あり
• Wi-Fi あり
• 3食付き

個室

個室という表現でなんとなく部屋の中に自分専用のトイレとお風呂もついてるイメージでしたが、私の場合はコロナ自粛の影響もあり1ヶ月間はトイレとお風呂が付いている部屋で、後半の1ヶ月はトイレとお風呂が歩いて10秒ほどの母家のものを共有で使う形でした。確かにこれも個室だけどさぁ…という気持ちになりましたし、トイレが遠いことで無意識に水分を飲むのを抑えてしまい脱水症状になったりして辛かったです。もちろん相部屋よりかはマシですが、想像と違った部屋でストレスを感じました。

Wi-Fi

Wi-Fi はとても弱くてパソコンでチャットする分には問題なかったですが、Zoom でテレビ電話することは難しかったです。また、スマホは Wi-Fi 自体が勝手に切れてしまうほど弱かったので、スマホはほとんど Wi-Fi を使うことができませんでした。自宅で使っているような速度にストレスない回線は期待しないほうが良いのだと分かりました。

3食付

ご飯作るの好きじゃないし、仕事のあとにご飯を作るのは面倒だと思い3食付きにしました。ご飯はとても美味しかったですが、1つだけど盲点で…それは食事は毎回、牧場の家族とアルバイトメンバー全員で食べる必要があるということです。そのため毎回、牧場のお父さんの話に相槌を打ち、牧場のお母さんの料理に美味しいと言い、ほぼ接待をしてる気分でした。私はそういうリアクションを息を吸うようにできるタイプではないので苦痛でした。また、「いただきます」は牧場のお父さんが仕事終わるまで待ったり、片付けも全員食べ終わってから一斉に行うので一回の食事に時間がかかるのも辛かったです。住み込みだけど1人の時間を確保するためにも、もう3食付きにはしたくないです。

次働くときに持っていきたいもの

• 筋肉痛緩和の薬
  慣れない肉体仕事を少しでも緩和するためにあると良いです。
• 胃腸薬
  肉体仕事が過酷だと全身疲労し内臓にも疲労が溜まり、普通のご飯も食べれなくなります。私は下痢にもなりました。そのためアルバイト期間分ぐらいの胃腸薬を持っていった方が良いです。

※ 牧場の仕事〜体調〜

知識

牛の胃は4つ

牛は一度胃に入れたものを口に戻して、奥歯で噛んでを繰り返すことで繊維の多い植物を消化するそうで。人間の胃と同じような働きをするのは最後の胃だけだそうです。
第42号・反芻動物（はんすうどうぶつ）

牛の爪切りは人手

牛の爪切り

子牛は4,50キロある

かわいい。生まれたては毛がカピカピだけどだんだんサラサラになる。

生後1ヶ月ほど

農業従事者の平均年齢は60代後半

農業従事者の平均年齢は66.8歳。高齢化・人材不足・自給率低下など日本の農業問題解決のために注目を集める「アグリテック」とは？

感想

牧場の仕事はもちろん肉体労働で過酷でしたが、それ以上に人間関係で疲弊しました。例えば、この牧場では失敗があると怒って指導する文化やスピードを重視する文化があるので、常に焦りと緊張感がある状況が辛かったです。また、私の同僚は3年間の技能実習制度を使ってベトナムから働きに来ているメンバーで、短期で働く私には優しく、長期で働くベトナムメンバーには厳しかったり、明らかに人種によって態度を変える社員もいる状況（しかもその社員は家族の一員なので怒られない）で心苦しかったです。他に、田舎特有の閉鎖的な人間関係や家族経営の中で寝食を共にしたので、プライベートな時間が少なくどんどん笑えなくなりました。帰る前にベトナム人の同僚との社員の指導が辛いねって話をしたときは悲しくて悔しくて涙が出ました。

2ヶ月という短い間だったからこそ乗り越えられたものの、これ以上長く続けていれば心が折れていたかもしれません。（私の後に入った日本人のアルバイトは2週間で帰りました。）アルバイトに行く前はこれまで体験したことなかった牧場ライフをやってみよう！みたいな気分で来ましたが、働いてみて東京に住んでたら見えなかったものが沢山見えた気がします。いまは自分の無知と無力感でいっぱいですが何か私に出来ることをしていきたいと思いました。

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

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

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

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

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

良い設計とは？

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

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

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

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

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

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

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

漫画にした。

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

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

選択肢を残しておく

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

SOLID 原則

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

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

単一責任の原則

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

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

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

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

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

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

• コンポーネントレベルでは、「閉鎖性共通の原則」
• アーキテクチャレベルでは、「アーキテクチャの境界」を作るための「変更の軸」

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

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

本当にそう思う。

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

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

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

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

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

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

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

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

リスコフの置換原則

リスコフの置換原則 - Wikipedia

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

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

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

依存関係逆転の原則

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

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

Uncle Bob の講演（2021/01/29）

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

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

• Builders Box イベントレポート 〜クリーンアーキテクチャ〜 (前編) - Sansan Builders Blog
• Builders Box イベントレポート 〜クリーンアーキテクチャ〜 (後編) - Sansan Builders Blog

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

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

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

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

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

読書会の感想

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

最後に

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

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

参考

• クリーンアーキテクチャ(The Clean Architecture翻訳) | blog.tai2.net
• Clean Architectureなにもわからないけど実例を晒して人類に貢献したい - エムスリーテックブログ
• 実装クリーンアーキテクチャ - Qiita

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

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

• 2020/03-2021/03
• 週1

読んだ本

• 増補改訂版Java言語で学ぶデザインパターン入門
• Rubyによるデザインパターン

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

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

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

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

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

• 第9章　Bridge
  Bridge パターン - Wikipedia
• 第10章　Strategy
  【Unity】Unityで学ぶStrategyパターン！モンスターに色んな技を使わせよう！【C#】【プログラム設計】 | サプライドの技術者BLOG
• 第12章　Decorator
  Decorator パターン - Wikipedia
• 第14章　Chain of Responsibility
  Ruby: Chain of Responsibilityパターンの解説（翻訳）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社
• 第16章　Mediator
  デザインパターンの使い方: Mediator (1/2)：CodeZine（コードジン）
• 第18章　Memento
  Memento パターン - Wikipedia
• 第21章　Proxy
  Ruby: Proxyパターンの解説（翻訳）｜TechRacho（テックラッチョ）〜エンジニアの「？」を「！」に〜｜BPS株式会社

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

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

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

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

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

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

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

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

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

読書会の感想

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

終わりに

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

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

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

※ オブジェクト指向プログラミング（OOP）

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

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

• オブジェクト指向設計実践ガイド　～Rubyでわかる 進化しつづける柔軟なアプリケーションの育て方
• オブジェクト脳のつくり方―Java・UML・EJBをマスターするための究極の基礎講座
• 増補改訂版Java言語で学ぶデザインパターン入門

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

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

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

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

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

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

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

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

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

プログラミング言語の進化

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

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

オブジェクト指向プログラミングのメモリの仕組み

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

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

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

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

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

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

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

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

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

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

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

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.

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.

✅ 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.

✅ 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.

✅ 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.

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

---

[Official]Imabari City Tourism Map (English)

Proxy パターン for Ruby / Rails

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

• 増補改訂版Java言語で学ぶデザインパターン入門
• Rubyによるデザインパターン

Proxy パターン

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

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

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

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

オブジェクト生成の遅延（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 を経由してアクセスする仕組みになっていることが多いです。これもアクセス制限という関心事をプロキシーに分離している構造です。

オブジェクトの置き場所の隠蔽（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 が透過的であるが故に、そのコントロールをいつでも無効にすることが可能です。