心が疲れたときに多くの気づきをもらった考え方

もともと頑張り屋で優等生タイプの私ですが、2019 年に一緒に仕事をしていたメンバーと不仲になったことがきっかけで、急に頑張れない自分に転落していきました。それが自分自身と向き合うことに繋がっていくのですが、そのときに多くの気付きをもらった考え方を紹介します。

心屋仁之助さん

性格リフォーム 心理カウンセリング 心屋 KOKORO-YA | 心理学の技術を使って「本当の自分・本来の生き方を見つける」ことにフォーカスした独自の問題解決方法や性格を変える方法を心理カウンセラーがサポート。

心屋さんは「ずるく生きる」とか「いい人辞めちゃえ」的なことを提唱してる人で、もっと頑張らなきゃ、もっとちゃんとやらなきゃって考えて生きてる人にグサグサ刺さると思います。心屋さんは歌も歌ってて下手だけど、歌詞が沁みます。

公開カウンセリング

www.youtube.com

これまで迷惑をかけたくない、他人にお願いするが心苦しい、自分が出来ないって言うのは嫌、失敗を許してもらえる気がしない、などと思って無意識ですが常に気を張って良い子・気が利く子・褒められる子になるよう努力していました。が、そうしてしまう原因が親に甘えることが出来ないからだということを、この公開カウンセリングを通して質問者の言葉を一緒に繰り返したときに涙がポロポロ出てきたことで気付くことができました。

「お母さん私を見て。私のこともっと大事にして。」って声に出すと、すっごく泣けて😢 数日後に勇気を出してお母さんに電話で弱音を吐きました。

心屋のカウンセリング
心屋の提供している「言ってみる」ことで、自分の知らなかった本心に気付き、さらにその「呪縛」「禁止」「制限」を解いて行くのが「心屋リセットカウンセリング」(対面カウンセリング)です。
https://www.kokoro-ya.jp/counseling/

Podcast - 心屋仁之助の「ホントの自分を見つけるラジオ」

https://podcasts.apple.com/jp/podcast/id1112406793

深い話なのにトークが軽快で冗談も多めなので笑いながらサクサク聞けちゃいます。Podcast の第3回目と第4回目で「前者・後者」という話があるのですが、そこで私は自分はダメなやつだ〜と唱えたことで涙と共に頑張るのを辞める方向へ、人に頼る方向へと少しずつ舵を切ることができました。

話してる最中に頭が真っ白になる(シャットダウンする)人は私と同じ後者です!Podcast 聴くと楽になりますよ。

■【永久保存版・全体概要】前者・後者は世界を救う?! 前者後者ってなんだ? | 心屋仁之助オフィシャルブログ「心が風に、なる」Powered by Ameba

Podcast の中で記憶に残ってる話 >

  • 後者はお姫様ポジション
  • 自立と自活は違う
  • 後者はすでに答えを知ってる人
  • 浮気しないは 100 点満点と同じ。数回の浮気は込み
  • 嫌いにな人に嫌われるって最高!
  • 人生ハードモードを選んでる
  • コンビニの店員さんにムスッとする練習をする
  • 自分が一番怖い人と揉める
  • 頼ることはその人に活躍する場をあげてること

オープンカウンセリング

オープンカウンセリング | 性格リフォーム 心理カウンセリング 心屋 KOKORO-YA

無料で心屋カウンセリングを受けれる場所です。私は以前、心屋の初級セミナーに参加して人前で泣けない自分に気付き、人前で泣く練習がしたくてオープンカウンセリングに参加しました(めでたく人前で泣けました👍)。そして、その時のカウンセラーが月星キレイさんで話しやすくて心地よかったので個人カウンセリングも受け、さらに心のブロックを外すことができました。心屋さんの YouTube 見て言ってみるカウンセリングに興味を持った方はお試しとしてとてもオススメです。

【漫画】パラダイムシフト

「【漫画】パラダイムシフト①ぼくんち こんな感じの漫画です、表現とか苦手な方はす」|-EMI-の漫画

去年、仕事で私の依頼を進めてくれない上司へのイライラと自分がその場凌ぎで付いた嘘が許せず、頭の中は「なんで私ばっかり!?」「嘘を撤回するにはどうしたら良いか…?」などの思考・妄想の嵐。そして、そのとき流行っていた香水の「人を傷つけてまた泣かせても何も感じ取れなくてさ」が無限トリガーになって 2 ヶ月ほど毎日毎日涙が止まらず、また徐々に起き上がるのが辛くなり 2 時間仕事して 4 時間寝て、2 時間仕事して…を繰すような無茶苦茶な日々を過ごしていました。けれどこのままじゃヤバイと思い勇気を出してメンタル病院に行き睡眠薬抗鬱剤で少し回復してたころ、偶然 Twitter で見つけた漫画です。

漫画の「気持ちには寄り添うけど事実とは分けて考える」という考えに感動しました。

f:id:meikotan:20211006131521j:plainf:id:meikotan:20211006131524j:plain

私は自分の気持ちと表面の態度は一致していることが良いこと、そこに裏表のないのが良い状態だと考えていましたが、そうすると相手のことが嫌いなのに表面上嫌いという態度が出せない場合、この人を嫌いだと思う感情を持っちゃいけない、好きになるよう努力しなきゃいけないと考え自分の気持ちを押し殺していました。しかしそれが自己虐待なのです。自分は自分の気持ちに全く寄り添わず自己虐待ばかりしていたことに気付けました。

漫画を読んだあとにふっと「もう薬飲まなくてもだいじょぶだ」と思えて、その日から抗鬱剤を辞めることができました。

前田大輔先生

心療施術のスペシャリスト心理の達人前田大輔 | トップページ
前田大輔 - YouTube

漫画の中に出てくるカウンセリングの先生で、前田先生の Youtube で語られる「自己愛・自己虐待」の話はとても泣けました。我慢は自分の味方にならず相手の味方になったということなのです。

ザ・メンタルモデル(由佐美加子さん)

ザ・メンタルモデル

前提として人は不快な感情(痛み)を避けて生きており、その痛みを避け続けると不都合な現実に直面していくので、その痛みが何なのか見てみようって感じの話です(ざっくり🥲)。YouTube で由佐さんがめっちゃ分かりやすく説明しているのでそれ見るのをオススメします。いま自分の人生がうまくいっていない、常に思考がぐるぐる回っているという方は結構グッとくると思います。そして自分のメンタルモデルが分かると自分がどんな痛みを避ける傾向があるのか、またこうあったら良いなぁと思える世界が分かるようになります。

私はメンタルモデルが「欠陥欠損の克服型」です。常に私はこれをやって良いのか?ダメって思われてるんじゃないか?自分がここにいて良いのか?という存在不安があるんですよね。。でもその不安は無理に無くそうとするものじゃなくて、その不安は在って良い、在るものは在るんだもんの世界に入ることが大事だって気付きました。

f:id:meikotan:20211007122736j:plain

感情を感じる

心屋さんのお話の中で悲しいをもっと感じて、怒りを出してって言われることがあるのですが、私はそれがピンとこなくて…でも由佐さんの感情を感じるワークは順序立てて感情を感じにいけるので、感情を感じるってこういうことだったのか…と頭と体で実感することできました。いまは自分が痛みを避ける瞬間に気付くようになってきて、心がシャって防衛的になるんですよね。そんなときにこの感情のワークの動画を見て感情を感じる・感情は何を私に伝えようとしているのかを見つけるトレーニングをしています。

www.youtube.com

Journey to the Source (JTS

基幹講座JTS(Journey to the Source) および Free Creators | Human OS Migration Technology

現在受講中なので感想は comming soon です。

由佐美加子のメンタルモデル・ワークショップ(由佐塾)

由佐美加子の「メンタルモデル」ワークショップ | 天外伺朗公式サイト

受講したい。

さいごに

こうやって振り返りと本当に良いタイミングで素敵な気付きに出会えたなぁと思いますし、これらの気付きに出会うために悩むこと病気になることは必要だったのだと感じます。また過去の私は自分がカウンセリングに通っていたこと、心屋さんや由佐さんの考え方がオススメだよ!と紹介することに抵抗感があったので、いまこうやって公開できるようになったのは信じられない変化で驚いてます。ここまで長かったなぁ。お疲れ様でした、あやちゃん。

Haskell を触ってみる

Haskell・純粋関数型言語 への興味

オブジェクト指向でなぜつくるのかの最終書は関数型言語への言及でした。そこで出されてたクイズ。

純粋関数型言語Haskell がサポートしてないな仕組みはどれでしょうか?
(複数回答可)
① 戻り値が void 型の関数定義
② return 文による関数からの復帰
③ ローカル変数の書き換え
④ for 文によるループ処理

正解は「全てサポートされてない」で、え?まじかと思って関数型言語に興味がわきました。

こんなときにどうするの?

これを見てぱっと浮かんだ疑問です。

① 戻り値が void 型の関数定義
-> まぁこれはなくても書けるか。

② return 文による関数からの復帰
-> ガード節的なのはどうするの?

③ ローカル変数の書き換え
-> これもなくても大丈夫そう?だけど言語レベルでサポートしてるって斬新

④ for 文によるループ処理
-> map 使うのか?どうやって定義するの?

ガード節的なのはどうするの?

例えば割り算をする関数があったときに、分母になる値が 0 の時だけ割り算させないように 0 を返したい場合。

Javascript の場合

ガード節を使って以下のように書きます。

function warisan(x, y) {
  if(y === 0) return 0

  return x / y
}
 
console.log(warisan(9, 3)) // => 3
console.log(warisan(9, 0)) // => 0

haskell の場合

パターンマッチで事前に弾く。

-- ハイフン 2 つでコメントアウト
-- 型定義
warisan :: Int -> Int -> Int -- 引数と戻り値の型

-- 関数定義
-- 分母が 0 の場合、0 を返す
warisan x 0 = 0
-- それ以外の場合は割り算をして値を返す
warisan x y = (x `div` y)  -- / は int の割り算では使えないので div を使う

普通に if も書ける。

-- 関数定義
warisan x y =
  if y == 0
    then 0
    else (x `div` y)

ガードという書き方(| を使って分割する)を使うともう少し見やすく場合分けが書ける。

-- 関数定義
warisan x y | y == 0 = 0
            | otherwise = (x `div` y)

参考)ここで書かれてる haskell で書かれた fizzBuzz 関数はガードを使って綺麗に書かれてる。
関数型言語Haskellでfizzbuzzプログラムを作成する

ループ処理どうやってやるの?

再帰関数とパターンマッチを使う。

再帰関数の勉強

階乗を求める関数 factorial を作る。
factorial(3) => 3 + 2 + 1 = 6

再帰関数を使わない場合

function factorial(n) {
  let result = 0;
  for(let i = n; i > 0; i--){
    result = result + i
  }
  return result;
}

これを再帰関数にすると?

function factorial(n) {
  if(n === 1) return 1
  return n + factorial(n - 1)
}

これを Haskell にすると?

factorial :: Int -> Int
factorial 1 = 1
factorial n = n + factorial(n - 1)

each を作る

配列の値を 1 つずつ取り出して表示させる関数を作る。
each([1, 3, 10]) =>
1
3
10

再帰関数を使わない場合

function each(array) {
  for (let element of array) {
    console.log(element);
}

これを再帰関数にすると?

function each(array) {
  element = array[0]
  new_array = array.slice(1) // 配列の最初の値を抜いた配列を取得

  if(array.length === 1) return console.log(element)
  
  console.log(element)
  each(new_array)
  return
}

これを Haskell にすると?
表示する関数(print)を foreach に渡してあげる必要があるんだね。

-- 返り値の型が分からないから型定義はしない
-- 型推論) > :t foreach :: Monad m => (t -> m a) -> [t] -> m a
-- Monad が分からないね…
foreach f [element] = f element
foreach f (element:new) = do f element
                             foreach f new

main = foreach print [1,10,3]

参考)Haskell > 繰り返し処理(foreach相当)を行う

map 関数を作る

haskell には map 関数は存在しますが、map 関数の仕組みを再帰関数で書いてみたかったので Javascript で map 関数を作ってみる。

array = [1, 10, 3]
console.log(map(array, increment)) // => [2, 11, 4]

再帰関数を使わない場合

function increment(n) {
  return n + 1
}

function map(array, transform) {
  mapped = []
  for(let element of array) {
    mapped.push(transform(element))
  }
  return mapped
}

再帰関数(自分で考えて書いた => 複雑になった…)

function map2(array, transform) {
  return recursion0(array, array.length, [], transform)
}

function recursion0(array, length, mapped, transform) {
  if(length <= 0) return

  mapped.push(recursion0(array, length - 1, mapped, transform))
  return mapped
}

再帰関数(haskell の map の実装を見て書き直した)

function map3(array, transform) {
  if(array.length <= 0) return []

  x = array.slice(0, 1)
  xs = array.slice(1)
  return [transform(x[0])].concat(map2(xs, transform))
}

参考)お気楽 Haskell プログラミング入門

filter, reduce 関数を作る

map と同様、haskell には filter 関数、foldr, foldl 関数(reduce と同じ)がありますが仕組みを理解したかったので再帰関数で書いてみる。

github.com

感想

  • もっちーとの勉強会のおかげで勉強サボらずにできた。約束の力👊
  • Haskell のコードを Javascript で書き換えたりしたので、Haskell のコードをだいぶ読めるようになった👏
  • 階乗の再帰関数なら javascripthaskell もコードの見やすさは変わらないけど、map など複雑さを増してくると haskell の宣言的な書き方の方がスッキリしてる。
  • パターンマッチが強力で引数の配列の最初の値だけ束縛することができるのもコード量を減らしてるポイントだと思った。
  • haskell のサンプルを見たときに()がなく、スペースで判断なことが多かったので読み辛く感じた。
  • Ruby関数型言語っぽく書ける部分が多いので「if, while を使ったループ」と「ローカル変数の書き換え」はあんまりやってないことに気付いた。
  • map 関数、filtter 関数、reduce 関数の実装楽しかった。自分で作ったのだと無駄が多かったので、haskell の実装(正解)を見て感動した。
  • 高級関数をきちんと学べてよかった。
  • 今後:モナドを頑張って勉強したい…!文脈を持つ計算とは??

参考

THE COACH Academy 受講後の振り返り

受講のきっかけ

友達と話してるときに「あなたはコーチングのコーチに向いてるよ」とアドバイスしていて。そのとき「他人するアドバイスは自分に向けると面白い」という心屋仁之助さんの Podcast での話を思い出して、同じアドバイスを自分に向けてみたら、「私、コーチングのコーチやりたい」に気付いたの。そして以前から Twitter で気になっていた THE COACH Academy に思い切って申し込んだ。

授業の内容

座学3割、グループワーク・シェアが7割のインプットと同時にアウトプットができるような内容。コーチングの「答えは既にクライアントの中にある」「クライアントが気付きたいときに気付く」を信じるということ、そして自分自身に対してもクライアントに寄り添うことで「必要な問いが湧き出てくること」を信じる大切さを強く感じれた。

最後のグループワーク

コーチングレッスンを通した振り返りの時間だったので、私はそこでコーチングを学ぶ前に感じていたモヤモヤを話した。

私はプログラミングスクールの講師業をしている中で、受講生からのキャリア相談も受けいてたが、キャリア相談を受ける自分に限界を感じていた。限界の理由は結局私の人生サンプルを伝えているだけで、その人のモヤモヤした部分が解決できたのかよく分からない。また、私の人生サンプルを伝えることで鵜呑みにされてしまったり、その人の思考に制限や偏りを与えてしまったら嫌だなぁとも思って、言葉が発することに抵抗を感じていた。

しかしコーチングを学び、クライアントが自分で答えを見つける、クライアントの可能性を 100 % 信じて良い、私の意見によって可能性を偏らせなくていいんだって分かった。クライアントを 100 % 信じれる世界は、私の求めていた世界だったし、そんな世界に出会えたことが分かって胸が暖かくなるような嬉しさと心にスッと収まる納得感があった。

今後

身近な人でコーチングのコーチ役をする。月 5 人を目標にしよう。応用 A/B も受けたいけどもう少しコーチ経験を積んでたから、自分の力不足で歯痒さを感じてから受講したい。

(途中)読書メモ:SQL アンチパターン

SQLアンチパターン の読書メモです。

ジェイクウォーク(信号無視)

多対多の関係の場合に交差テーブル(中間テーブル)を作らず、参照先を1フィールドに「カンマ区切りのリスト」で格納するのはアンチパターン

これはやらないなぁ。
交差テーブルを作るメリットとして以下は大きい。

交差テーブルにさらに列を加えることによって、各エントリに属性を追加できます。例えば、製品に連絡先が追加された日付を記録したり、連絡先の優先順位を示す属性をつけたりできます。

私は多対多の関係を表すテーブルのことを「中間テーブル」と呼んでることもあり、名前からは内容が想像できなかったパターン。Wiki では 連想エンティティ - Wikipedia や 連想テーブルだった。英語ではなんて呼ばれてるんだろう。

そして交差を避けるから信号無視なんだって。

ナイーブツリー(素朴な木)

組織図やスレッド形式の掲示板のような階層構造を実装する場合、ノードが parent_id を持つことで階層を表現する隣接リストと呼ばれる設計をするのはアンチパターン。問題点は隣接していない子孫へアクセスして集計などをする操作や、途中のノードを削除してノードを昇格させるなどの操作が難しくなる。

階層構造を実装する設計方法として以下がある。

  • 隣接リスト(アンチパターン
  • 隣接リスト + 再帰クエリ
    WITH キーワードの後に共通テーブル(階層構造の Path 列がある)式を指定する形式を用いることで、隣接リストに格納された階層構造をサポートする。ただし、全てのデータベースでサポートされているわけではないので注意が必要。
    MySQL は 8.0、PostgreSQL は 8.4 でサポートしている
    参考)再帰CTE(共通テーブル式)で階層構造のパスを作る
  • 経路列挙
    経路パス(ファイルシステムのパスのような文字列)を格納する列を保有する。ただし、ジェイウォークのように長さの制限(階層の深さの制限)があったり、参照整合性を DB で維持できないのが欠点。
  • 入れ子集合
    ノードのレコードは自分より下の階層にあるすべてのノードが持つ値より「小さな値」と「大きな値」を保有することで階層を表現する。得意なことはサブツリーに対するクエリ実行で、欠点はノードの挿入や移動をすることで関係する全てのノードの再計算が必要になるので複雑になりがちなところ。
  • 閉包テーブル
    階層パス情報を格納するテーブルを別に作る。

参考)テーブル設計まで細かく書いてくれてる。
階層構造(a.k.a ツリー構造・ディレクトリ構造・フォルダ)をDBでどう設計すべきか - @teitei_tk Blog

子孫へのクエリ実行や参照製合成の意地などを考慮すると、再帰クエリが使える環境であれば再帰クエリを、それ以外であれば閉法テーブルが良いのでは?

自分が階層構造を実装したら…?を考えると隣接リストしか思い付かなかったけど、、読み進めていくうちに以前、階層構造を実装したときは入れ子集合モデルのライブラリ使っていことを思い出した。なんかいい感じに動いてるってだけでライブラリのことをよく知らずに使ってた証拠だね。。反省です。選択肢と選択肢ごとのメリデメを知れたので、今後はライブラリ選定に活かしたいです。

Rails の場合
(参考)Railsで木構造を扱うには|TechRacho(テックラッチョ)〜エンジニアの「?」を「!」に〜|BPS株式会社

ID リクワイアド(とりあえず ID)

すべてのテーブルに主キーとして「id」列を用いるのはアンチパターン

まさに私は Rails に依存してることもあり、何も考えずに id 列を生成してる。。

id という名前は明確な意味を持っていなから、bug テーブルなら bug_id にした方が良いという主張について。いやいや SQL で table 名を付けて列を指定(bug.id)すれば良いじゃんと思ったんだけど、以下の主張に確かになぁとなった。

主キーは「あるテーブル上の1つの行」を識別するためのものなので、主キーの列名でもそのテーブルの種類がわかるようにしておくべきです。そうすれば「bug_id = 1」という情報だけで、データベース上の1行を特定することができます。

あと主キーと外部キーの名前を揃えることで結合条件を on 句の代わりに USING でっていうのも良かった。USING って新人研修的なので習った記憶ある。

これを読んだうえでも主キーを自然キーにする場合以外、すなわち擬似キーを作る場合は id 列にするだろうな。

キーレスエントリ(外部キー嫌い)

外部キー制約をしないというアンチパターン

具体例ではまだ外部キー制約をサポートしていない MySQLMyISAM ストレージエンジンを使っていたから、参照整合性を満たせなくなって、数字の不整合やデータの重複が発生して。そのためにゴミレコードを探すようなスクリプト書いて対応していたそう。

そうか、外部キー制約がなかったときもあるのかぁ。外部キーがなくても良いと思ったことはないけど、強く必要性を求めたこともなく一度つけ忘れたことがあるので、改めて参照整合性の大事さを感じた。

外部キーで関連付けられたレコードに対してどのように対応するかは Rails で書いてしまう(Active Record の関連付け - :dependent)ので、DB 側でも同様の機能をサポートしてること知らなかった。

参考)MySQLの外部キー制約RESTRICT,CASCADE,SET NULL,NO ACTIONの違いは? - Qiita

リアル牧場物語 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号・反芻動物(はんすうどうぶつ)

牛の爪切りは人手

f:id:meikotan:20210524105126j:plain:w400
牛の爪切り

子牛は4,50キロある

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

f:id:meikotan:20210524105352j:plain:w200
生後1ヶ月ほど

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

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

感想

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

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

クリーンアーキテクチャ読書会の感想 #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 さんとは技術力のレベル感が同じぐらいで、一緒に成長してく感じがとても楽しかったです。ありがとうございました😊