運営者: OKB🍵♨️

この記事の概要📖 [前回の記事] 沈黙が怖くて、自分からいつも喋り出してしまっていた 自分ばかりが喋ることでメンバーの意欲をそいでしまっていた 外部メンターの方からのアドバイスを元に「あえて無言でいるウィーク」を行なった メンバーの意欲を引き出すことが出来たが、怒っていると勘違いされてしまった あえて沈黙でいることが重要だと気づいた🙇‍♂️ 前回の記事で、「あえて沈黙でいることが重要」だということに気づいたという話をしました。 [https://www.okb-shelf.work/entry/keep_silence:embed:cite] 何か問題があった場合に、沈黙がおとずれて、「(気まずい…！)」という想いから自分ばかりが喋り出してしまい、 メンバーの意見やアイディアを引き出すことが出来ず、結果的にメンバーの意欲をそいでしまっていました。 あえて無言でいるウィーク📅 外部メンターの方に相談した結果、「あえて無言でいる」という施策に取り組むことにしました。 やり方は至って簡単で「ただ沈黙するだけ」です。 自分からは何も話し出さず、聞かれたことには答えるという形にしました。 🚣‍♂️・・・ドライバー 🎅・・・ナビゲーターA(自分) 🎃・・・ナビゲーターB 🚣‍♂️「この処理は〇〇という条件分岐をしていますが、どうしますか？」 🎅「…」 🎃「…」 🚣‍♂️「…」 🎃「そこは過去にバグが出たところだったはず」 🎅「そうです！」 🎃「だったら、条件は残しておく必要がありますね」 🚣‍♂️「分かりました。今回追加する仕様の条件は…」 … 外部メンターの方に結果を報告するのは1ヶ月先ですが、すでに2つの結果を得ることが出来ました。 あえて無言でいた結果👻 メンバーの意欲を引き出すことが出来た いつも自分ばかり話し始めてしまっていたため、メンバーが何を考えているのかが分かりませんでしたし、分かっていませんでした。 自分としてはスケジュールを間に合わせることに必死になってしまっていて、焦っていたのだと思います。 あえて無言でいるウィークを行なった所、メンバーが自分の考えや疑問を口に出す回数が明らかに増えました。 やっぱり、自分が話しすぎていたのだと改めて実感することが出来て、悲しいような嬉しいような気持ちになりました。 ただ、まだ分かっていない箇所や、単純な疑問を出すことを控えている印象を受けたので、「もっと聞いていい！」ということを伝えました。 「日本人は積極的に質問をしない、難しく考えすぎてる」と大学生の頃にお世話になった先生から教えて頂きました。 この方は自分の先生とは別の方ですが、同じようなことをお話されているようです。 [https://twitter.com/motcho_tw/status/870589211832795136?s=20:embed] おっしゃるとおり！質問するやつは偉い🙋‍♂️ 怒っていると勘違いされた 無言ウィークが終了して、振り返りをしていると、「ずっと怒ってましたよね」と言われてしまいました。 「え？怒ってないよ！今週はメンターの方と決めた施策であえて無言でいました！」と伝えてはじめて、「そういうことか！」と理解してもらえました。 メンバーからしてみたら、作業の進捗がよろしくないこと、何度も同じ問題でつまづいてしまった際に自分の無言の態度が「怒っているのではないか？」と捉えられてしまったようです。 無言でいた意図を改めて説明して、勘違いを解消することが出来ました。 「もっと相槌をうってほしい」とフィードバックをもらったので改善していきます。ごめんなさい！ 感想🙌 あえて無言でいることは非常に辛かったです。 自分が口を出せば、すぐに解決するような問題もたくさんありましたし、10分ぐらい沈黙の時間もありました。 助け舟をいつ出すのかというは非常に難しい問題ですが、無言でいたことでメンバーの意見や疑問が聞けたのは良い収穫でした。 ただ、無言でいると怒っていると思われてしまうことが分かったので、怒っていないことを意思表示するために相槌をしっかりとうっていこうと思います。

前回までのあらすじ📖 「入門Haskellプログラミング」を読み進めながら、理解を深めるためにElixirを使ってHaskellのFunctorとApplicativeを再現してみました。 [https://www.okb-shelf.work/entry/original_functor:embed:cite] [https://www.okb-shelf.work/entry/original_applicative:embed:cite] Functorは上手く再現出来ましたが、Applicativeはデフォルトで部分適応されるというHaskellの仕様がなければ、完全再現することが出来ず、カリー化した関数で近しいものを再現しました。 FunctorとApplicativeを用いることでがコンテナ、コンテキスト内の値(例: リスト)に対して以下の操作をすることが出来ます。 引数1つの関数をコンテナ、コンテキスト内の値に対して適応する(Functor : fmap) コンテナ、コンテキスト内の部分適応された関数をコンテナ、コンテキスト内の値に対して適応する(Applicative : app) 引数2つ以上の関数を適応することが出来る コンテナ、コンテキスト外の値をコンテナ、コンテキスト内に格納する(Applicative : pure) さて、これだけの操作がコンテナ、コンテキスト内に対して可能になりましたが、現状ではまだ出来ないことがあります。その問題を解決するためにMonadが必要なのです。 Monadとは🤔 HaskellではMonadはFunctorやApplicativeと同様にクラス(型)として定義されており、関数を定義しています。 よく言われるカタカナ表記の「モナド」とはHaskellにおいてはMonadクラス(型)のインスタンスに持つクラス(型)の総称です。試しにMaybeクラス(型)についての情報を見てみると、Monadをインスタンスに持つ事が分かります。Maybeクラス(型)はモナドの1種です。 *Main> :info Maybe type Maybe :: * -> * data Maybe a = Nothing | Just a -- Defined in ‘GHC.Maybe’ instance Applicative Maybe -- Defined in ‘GHC.Base’ instance Eq a => Eq (Maybe a) -- Defined in ‘GHC.Maybe’ instance Functor Maybe -- Defined in ‘GHC....

概要📖 Haskellではエラーが発生した際に対応するためにEitherというモナドを使う EitherはLeft(エラー時)とRight(正常時)の2つの値を持ち、それぞれ別の型の値を受け取ることが可能(Either = Left a | Right b) LeftにはStringがよく用いられ、エラーメッセージを格納することが多い Eitherが必要なのは呼び出し元に、なぜエラーになったのかを伝えるため Maybeではエラー、値なしの理由を呼び出しもとに伝えることが出来ない Elixirで実装するにはTupleとAtomを使うのが良さげ 前回までのあらすじ📖 「入門Haskellプログラミング」を読み進めながら、理解を深めるためにElixirを使ってHaskellのFunctorとApplicative, Monadを実装しました。 [asin:B07SFCMP66:detail] 以上の3つで「入門Haskellプログラミング」のUNIT5で扱われていたコンテキストでの型の操作に関しての項目が終了しました。 いやー、長かった！抽象的な概念が続いたので理解するのにかなり苦労しましたが、何とかUNIT5を終了することが出来ました。 これでコンテキスト内に存在する値に対しての操作(関数適応)が可能となりました🎉 最後のモナド🔥 本書で紹介されているモナドはあと1つです。 Eitherと呼ばれるエラーを扱うためのモナドで、呼び出し元になぜエラーになったのかを伝えるために利用されています。 (The Either type is sometimes used to represent a value which is either correct or an errorより判断) The Either type represents values with two possibilities: a value of type Either a b is either Left a or Right b. The Either type is sometimes used to represent a value which is either correct or an error; by convention, the Left constructor is used to hold an error value and the Right constructor is used to hold a correct value (mnemonic: “right” also means “correct”)....

Hugoの形式で貼り付け tweet はてぶで書いた記事が全くGoogleに登録されないので、別のサービスに乗り換えようかな。 — OKB (@sing_mascle69) November 7, 2021 ref adsense リンク

この記事の概要📖 関数型言語の多くでは値は束縛されるため、不変である 値を再束縛(≒再代入)することが出来ないため、値を更新する際には新たなデータを作る必要がある 更新の度に新たなデータを作ることで、関数型言語でもカプセル化をすることが可能になる 関数型言語では値は不変⏳ 多くの関数型言語では値は不変であり、一度、宣言した変数に束縛されている値を変更することが出来ません。 printName :: IO () printName = print name where name = "okb" name = "okb2" コンパイルしてみると… *Main> :l sample.hs [1 of 1] Compiling Main ( sample.hs, interpreted ) sample.hs:5:9: error: Conflicting definitions for ‘name’ Bound at: sample.hs:5:9-12 sample.hs:6:9-12 | 5 | where name = "okb" | ^^^^^^^^^^^^... Failed, no modules loaded. Conflicting definitions for ‘name’(nameという定義が衝突している)というエラーが出て、コンパイルに失敗してしまいます。 この制限はリストやオブジェクト、マップであっても同じです。例えばリストのN番目だけを更新するということは基本的には出来ず、N番目の要素が変化した新たなリストを作り直す必要があります。 しかしRubyであれば同じ処理のコードが問題なく実行されます。Rubyは再代入(再束縛)を許可しているからです。 他の再代入を許可している言語でも同じ結果が得られます。 name = "okb" name = "okb2" print name # okb2 リストの更新...