鯨飲馬食

いろいろつまみ食いで勉強したことのメモ書き

「嫌われる勇気」を読んだがわからないところがあったので整理してみる

book

嫌われる勇気―――自己啓発の源流「アドラー」の教え

嫌われる勇気―――自己啓発の源流「アドラー」の教え

同僚からお勧めされたので読んでみたが、難しくて理解できなかった部分がある。自分に取って身近な話題であるソフトウェア開発と対比させつつ、整理してみる。

課題の分離（たぶんわかったところ）

使っているソフトウェアがうまく動作せず、問題の切り分けをしているとしよう。

うまく動作しない原因としては

  • 自分の使い方が間違っている場合
  • そのソフトウェア自体の不具合を踏んでいる場合

があり得る。ソフトウェア自体の不具合の場合には、自分の使い方が悪いのかといくら悩んだところで無駄 1 で、まずはこれらのうちどちらなのかを切り分けるのが大事である。

そして、使い方の問題ではないと判断したら、そこから先を深追いしないと決めることは無責任な態度ではない。

自身が解くべき課題は、そのソフトウェアを使って何かしらの問題を解決することであり、その不具合を直す事ではないのだから。手立てとしては、

  • そのソフトウェアを使うこと以外の方法で解決する
  • 不具合の報告をして、直してもらう

などがあるだろう。後者で行く場合には、現象と期待動作、再現手順の情報を整理して、開発者に上手く伝えることまでは自分の課題であり、報告した結果、それを直してもらえるかどうかは自身がコントロールできることではない。2 場合によっては並行して他の方法を探すことも責任ある振る舞い。

「課題の分離」で書かれていることは、コヴィーの「7つの習慣」で出てくる「影響の輪」に集中せよという話と同じだな。

承認欲求に寄らない貢献感（わかってない気がするところ）

オープンソースソフトウェアの不具合を見つけて、手元で修正してプルリクエストを送る場面を考える。

プルリクエストを送る時に考えていることは、自分が見つけた不具合を、誰か他の人が踏むこともあるだろうし、将来の自分がまた踏むかもしれないから、それが直ったら気持ちいいなとかそういうことかな。

送ったプルリクエストは取り込まれることもあれば、違う修正方法のがいいと却下されて別の修正がされたり、それは不具合じゃないよと単に却下されることや、あるいは反応が得られないこともある。

修正が取り込まれなかった場合に自分はそれぞれどういう考え方をしてるか。

別の修正がされた場合は不具合自体は直っているので、報告したことで役に立ったと思える。不具合じゃないよと答えてもらったらそのことは記録に残るので、後で不具合なのかどうなのかと悩む人が減るかもしれない。3 反応が得られないとしたら、そのパッチ当てたらローカルでは不具合回避できることが後から来た人にもわかるし、あるいはあまり活発にメンテナンスされていないんだという事実がわかるようになったりするので、まぁ良いかなと思ってる。

結果がどうあれ、自分の行動は誰かの役に立ってるんじゃないかなと思ってるけど、それが承認欲求に寄らない、自分の主観によって得られる貢献感と考えていいのかな？

役に立つ先の「誰か」が将来の自分ってこともよくあるので、そういう時は昔の自分に感謝したり、昔の自分やるじゃんと自画自賛するし、開発者や他で同じ問題にはまってた人からありがとうって言われることもあって、そういう時はうれしい気分になるし、次もやろうって気になる。それって承認欲求に依存してしまってないのかな？

  1. 色々な使い方を試した結果、不具合の回避方法を見つけるということはあり得るかも。↩

  2. オープンソースソフトウェアの場合は、報告しておきつつ、自分で修正にも取り組むこともできる。↩

  3. たまに、いやそれは違うだろと思う理由で却下されることもあって、悔しい気分になったりする。↩

git stashの仕組みが面白い

git

git stash はコミットとしてデータ保存してるんだということを知って、調べると色々分かって面白かったという話。

きっかけはこのツイート

refs

ステージングされた変更とローカルの変更がある状態で stash する

f:id:yoichi22:20200521075646p:plain

コミットが二つできてる。WIP on ...というマージコミットと index on ...というコミット。

f:id:yoichi22:20200521075702p:plain

WIP on ...にはローカル変更が入った作業ツリーの状態が、index on...にはインデックスの状態が保存されている。

f:id:yoichi22:20200521075726p:plain

reflog

複数 stash した場合はどこに行ってんだろうと思ったので探したら、reflogにあった。

f:id:yoichi22:20200521075917p:plain

untracked files

作業ツリー内に履歴管理されてないファイル（HEADのツリーに存在しないパス）がある場合、git stash のオプション -u か -a を指定すればそれも含めて保存してくれる。

オプションによって何が保存されるかは、こないだ整理したものを Qiita に書いてました：

qiita.com

というわけで、履歴管理されてないファイルがあるところで git stash して git log --oneline --graph stash すると、こんなグラフに。

f:id:yoichi22:20200521074257p:plain

3つの親を持つマージコミットができている。

面白い。

数学ガールの秘密ノート 整数で遊ぼう

book

数学ガールの秘密ノート/整数で遊ぼう (数学ガールの秘密ノートシリーズ)

数学ガールの秘密ノート/整数で遊ぼう (数学ガールの秘密ノートシリーズ)

  • 作者:結城 浩
  • 発売日: 2013/12/18
  • メディア: 単行本

数当てマジックは子供の頃出会ったときは、何か不思議だなーで済ませてしまっていた気がする。ちゃんと理解できてなかった。今回ユーリと一緒に思考をめぐらせて理由がわかり、すっきりして面白さが増した。そこまで行くと、31の謎の答えはすっと出てきて、プログラマーやって来て得したな俺という感じでした。

数学的帰納法は、前から大好きな証明方法だったので、久しぶりに使う機会もらえて楽しめた。

最後に出てくる「ぐるぐるワン」はいくつかの視点から法則を見つけていくのが面白かった。ぐるぐる繋がりでルービックキューブが頭に浮かんで、自分はルービックキューブはでたらめにぐるぐる回して、たまたまうまく行くの繰り返ししかしたことなかったけど、法則性わかると別の楽しみ方が出来るようになるかもね。

ぐるぐると言えば、こないだTwitterで見かけた詰将棋も面白かった。手元に盤がなかったのでSpreadSheetに駒を書いて動かしてました。

会議のリーダーが知っておくべき10の原則

book

会議のリーダーが知っておくべき10の原則――ホールシステム・アプローチで組織が変わる

会議のリーダーが知っておくべき10の原則――ホールシステム・アプローチで組織が変わる

一番目の原則、ホールシステムを集めるというのが全体を通して繰り返し出てくる。必要な人が誰なのかあやふやなまま進めたり、対立を恐れて必要な人を集めるのを避けていると、結局時間を無駄にしてしまう。時間はとても貴重な資源なので、まずは必要な人を明確にして集めることが大事と感じた。

状況によっては問題を解決するのを先送りにして、それより前に対立を表面化してコモングラウンドを見つけさせたり、沈黙を解決すべき問題として扱わず自律的な行動を促したりと、会議をファシリテートする上で取り入れたいこともいくつか見つけることができた。

サブグルーピングを極めるの章の、自分以外の支持者が一人居ると多数派の意見に屈せず、自分が正しいと思うものに確信を持ち続けることができるというアッシュの実験結果が興味深かった。会議をやっていて、良い意見なのに他の意見が出たらさっと引っ込めちゃって勿体無いなと感じる場面があるのを思い出した。そういうときの自分の行動は、もっと詳しく教えてと質問をして、その答えに詰まって結局引っ込めることになることが多かった。支持者を先に見つけておくと引っ込めずに済む可能性が高まりそうなので、次は本書に書かれていた「ほかに誰かいませんか」を使ってみようと思う。

帯分数の掛け算のやり方は一つ？

math

息子(小６)が算数の宿題の帯分数の掛け算、割り算で苦戦しているのを横で見てて、算数の問題の解き方について思ったことがあるのでまとめます。

2\frac{3}{5} = 2+ \frac{3}{5}

の左辺のような書き方を帯分数と呼びます。その意味は右辺にある「整数と分数の和」です。

帯分数同士の掛け算の問題は例えば

問題： 2 \frac{1}{5} \times 2 \frac{1}{2} を計算せよ

です。これに対して、

回答（間違い）： (2 \times 2)(\frac{1}{5} \times \frac{1}{2}) = 4 \frac{1}{10}

と、ありがちな間違いに嵌っているようでした。

おそらく学校では「帯分数は仮分数にしてから掛け算しなさい」と習っていると思いますが、おそらく

  • 帯分数を仮分数に変形するという面倒な一手間をかける理由がわからない。
  • ◎ もっと楽に計算する方法があるのではと推測する。
  • ▲ それっぽく計算したら正解しないかなと楽観的な期待で適当に計算。

という思考の流れになったのだろうと想像しました。

算数の問題は答えは一つだとしても、一般にそれを解く方法はいくつもあります。なので、より楽な解き方がないか探すのはとても良い行動だと思います。ただし楽であったとしても正解に辿り着けない方法だと意味がなく、自信の持てない方法で解いた後には、導いた答えが正しいか確認する必要です。正しいと確認できたなら、次は自信を持って使える楽な解き方を見付けたことになります。正しくなかったなら、解く方法ではなかったので、別の方法を考えないといけません。

今回の場合は、上で書いたありがちな間違いは確かに正しくない答えになっていて、一方で帯分数を仮分数にするという一見面倒に思える方法は、割と楽な解き方なので、そのことを見ていきましょう。

答え合わせ

まず先ほどの例題について、答えがあっているか確かめましょう。

帯分数は整数と分数の足し算に書き直せます。

  • 2 \frac{1}{5} = 2 + \frac{1}{5}
  • 2 \frac{1}{2} = 2 + \frac{1}{2}

書き直せるというか、最初に書いたようにこれが帯分数の定義です。それぞれの右辺にある整数と分数の足し算を、足し算の記号「+」を省略して左辺のように書き表しましょうという決まりです。(Wikipedia:分数#帯分数)

このことを踏まえて問題の式を変形し、小数にして計算すると、

2 \frac{1}{5} \times 2 \frac{1}{2} = (2 + \frac{1}{5}) \times (2 + \frac{1}{2}) = (2 + 0.2) \times (2 + 0.5) = 2.2 \times 2.5 = 5.5

となります。一方で上で書いた回答の方は

4 \frac{1}{10} = 4 + \frac{1}{10} = 4 + 0.1 = 4.1

答えが合わないですね。

その差は何か？

間違った答えと、元の問題にあった式との間で、どうして違いが出たのでしょうか？先ほどは小数にして計算しましたが、分数のまま分配法則を使って変形してみましょう。

2 \frac{1}{5} \times 2 \frac{1}{2} = (2 + \frac{1}{5}) \times (2 + \frac{1}{2}) = 2 \times 2 + \frac{1}{5} \times 2 + 2 \times \frac{1}{2} + \frac{1}{5} \times \frac{1}{2}

ここで1項目と4項目だけ取り出すと、

2 \times 2 + \frac{1}{5} \times \frac{1}{2} = (2 \times 2)(\frac{1}{5} \times \frac{1}{2}) = 4 \frac{1}{10}

と、先ほどの間違った回答に一致するのがわかります。つまり、間違っていた方では、2項目と3項目

\frac{1}{5} \times 2 + 2 \times \frac{1}{2}

の分を足し忘れていました。どおりで答えが合わないはずです

ひとまず答えを

問題の方に戻り、さらに計算を進めて、一つの分数にまとめて行きましょう。分配法則を使って、掛け算をした後に足し算をするという解き方です。

2 \frac{1}{5} \times 2 \frac{1}{2} = 2 \times 2 + \frac{1}{5} \times 2 + 2 \times \frac{1}{2} + \frac{1}{5} \times \frac{1}{2} = 4 + \frac{2}{5} + 1 + \frac{1}{10} = 5 + \frac{2 \times 2 + 1}{10} = 5 + \frac{5}{10} = 5 + \frac{1}{2} = 5 \frac{1}{2}

小数にすると5.5で、先ほど計算した結果と一致していますね。

もっと楽に出来ないか

もっと楽な計算方法がないかを考える前に、別の例を使って、分配法則の話をもう少し掘り下げてみましょう。

一般に二つの数を足したものを掛け合わせる場合、分配法則

(a + b) \times (c + d) = a \times c + b \times c + a \times d + b \times d

が成り立つので、左辺のように「先に足してから掛ける」のと、右辺のように「先に掛けてから足す」のどちらで計算しても結果は同じになります。

例えば a = 1, b = 2, c = 3, d = 4 の場合には

  • (1 + 2) \times (3 + 4) = 3 \times 7 = 21
  • 1 \times 3 + 2 \times 3 + 1 \times 4 + 2 \times 4 = 3 + 6 + 4 + 8 = 21

とどちらで計算しても同じ結果になります。二つやり方がありますが、どちらも正解です。

では、別の見方をして、どちらが楽か？を考えてみましょう。左辺と右辺でそれぞれで行う演算は

  • 左辺 (a + b) \times (c + d)：足し算2回、掛け算1回
  • 右辺 a \times c + b \times c + a \times d + b \times d：掛け算4回、足し算3回

で、演算の回数が少ない前者の方が楽な気がしますよね。

帯分数の話に戻る

帯分数の掛け算の話題に戻りましょう。先ほどは分配法則で展開した形を使って、先に掛け算からやっていました。 今度は逆に足し算から先にやってみましょう。

2 \frac{1}{5} \times 2 \frac{1}{2} = (2 + \frac{1}{5}) \times (2 + \frac{1}{2}) = \frac{2 \times 5 + 1}{5} \times \frac{2 \times 2 + 1}{2} = \frac{10 + 1}{5} \times \frac{4 + 1}{2} = \frac{11}{5} \times \frac{5}{2} = \frac{11 \times 5}{5 \times 2} = \frac{11}{2}

\frac{11}{2} = 5\frac{1}{2} なので先に掛け算からやった結果と一致していますが、どちらが楽でしょうか？

最終的に一つの分数にまとめることを考えると、先に掛け算からやった場合にも結局通分をして足し合わせる必要があり、先に足し算をしてしまった方が、私は楽だと感じました。帯分数と帯分数の掛け算をするときには、まず先に足し算をしてしまう、つまり仮分数に変形して、その後で掛け算をするのが楽に思えるので、「帯分数は仮分数にしてから掛け算するのがオススメですよ」と先生（あるいは教科書）は言いたかったのだと思います。ただし、何を楽と思うかの感じ方は人によるかもしれませんね。

まとめ

帯分数と帯分数の掛け算をする方法は一通りではなく、例えば

  • 分配法則を使って先に掛け算をしてから足し算をする
  • 先に足し算をして仮分数に変形し、その上で掛け算をする

というやり方があります。どちらで計算しても正解に辿り着くことはできるので、やりやすい方法で計算すれば良いです。どちらも正解です。他にも解き方はありますが、答えが合わない解き方（例えば、最初に書いた間違った回答の計算方法）はダメです。あと、答えが合っていても、たまたま合っていただけで、解き方が間違っているということも有り得ます。

一般に算数の問題の解き方は一つではありません。教科書で書かれている解き方は、正しい答えに辿り着く方法であり、かつ「理解しやすい」あるいは「割と楽」といった面でオススメの方法を書いてくれています。教科書にあるやり方でまずは解いてみる。さらに他に解き方はないかな？と考え、教科書に書いてあったやり方と理解しやすさを比べたり、どちらが楽か比べたりして、色々な解き方を見ていくと面白いですよ。

数学ガールの秘密ノート 学ぶための対話

book

冬休み読んだ本の中で一番印象に残っている本。登場人物の「僕」のように、粘り強く時間をかけて、学ぶ対象の面白さを伝えていけたら良いなー。教える中でその面白さの理由を再確認していけたら素晴らしいなー。と思った。

数学ガールの秘密ノート/学ぶための対話 (数学ガールの秘密ノートシリーズ)

数学ガールの秘密ノート/学ぶための対話 (数学ガールの秘密ノートシリーズ)

教える側の態度

  • 大切なことは繰り返し伝える。
    • 話を止めてよい
    • どんなことでも何度でも質問してよい
    • まちがってもよい
  • 相手の様子を見たり、具体例を作ってもらったりして相手の理解度を確かめながら進める

これらは意識していきたいと思う。

大切なことは前にも言ったしもう言わなくてよいだろうとか、相手のことを考えるのを忘れて先へ先へ進もうとしてしまった時に思い出して、焦らず進む。

「どうして」の意味

「どうして」は間違いを指摘するものでも相手を責めるものでもないけど、相手には違う意味で取られる可能性がある。

自分の経験と重なる部分があり考えさせられた。

  • レビューで理由を問うただけなのに、突然コード直されてきて困惑することたまにある。
  • 本の中では対面のコミュニケーションでだったけど、文章でのやり取りの場合はより誤解が生まれやすい傾向がある。

事前に関係性が築けていて、どういうことを気にして、どういう態度でレビューにあたっているかが共通認識になってるとよいのかな。

一方で、誤解が生じるのも「まちがってよい」の一例なのかもな、とも思った。誤解されて、認識を訂正して、すり合わせていけばよいんだよ、とこの本は言ってくれてる気がした。

心理的安全性

学習する組織について興味があり「チームが機能するとはどういうことか」を読んでいるけど、そこで触れられている心理的安全性の話とも繋がることが色々書かれていた。

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

チームが機能するとはどういうことか――「学習力」と「実行力」を高める実践アプローチ

猫とUNIXパイプが繋いでくれたもの

go longcat

2019年の最終出勤日、恒例の納会LTでパイプについて話しました。

UNIXパイプはコマンドの出力を別のコマンドの入力に繋げてくれる機構です。発表の中では、猫の画像をターミナルに表示するlongcatというソフトウェアとUNIXパイプを使って、加工した猫の画像を表示させる方法を説明しました。

f:id:yoichi22:20191229171133p:plain

資料とQandA

speakerdeck.com

Q. 何で太らせようと思ったの？

「longcat はオプションで縦に伸ばしたり何匹か並べたりできるけど、横に伸ばせなかったので」と当たり障りのない答えをしたけど、健康診断で安定の脂肪肝を告げられた後に、年末パーティでフォアグラ食べて罪悪感に苛まれたのが後を引いてたのだと思います…

Q. 何で base64 ってわかるの？

酔っててその場では答えられなかったけど、冷静な今なら英数と / と + しか出て来てないのでわかりますね。パディングの = 見ればわかるのではという話が出たけど、パディングは必ずしも入るとは限らないのでそれに頼らずにわかるようにならないといけない（いけないことはない）

年の締めくくりにこの話をした経緯

他の登壇者はみんな構成しっかりしていたのに、私の話はWhyが完全に抜けてるし、あちこち飛躍してました。聞いてた人はここ見ないだろうけど書いておこう。

longcat との出会い

会社でやってるLT大会でlongcatのことを知って遊び始めたのがきっかけで、ターミナルに画像を表示する仕組み(Sixel Graphics, iTerm2 Inline Images Protocol)とかに興味を持ちました。

yoichi22.hatenablog.com

10月のhacktoberfestでは、longcatだけでなく、iTerm2にもフィードバック投げたりしました。

github.com

楽しいシェル芸

そして12月、シェル芸Advent Calendarで楽しそうな記事を見つけて、これターミナル上で出せたらいいのになと思いました。

qiita.com

ファイル出力したものがimg2sixelで表示できなかったのでissue投げたり

github.com

そのあとtextimgの方をパイプ出力でGIFを吐けてなかったのを修正したりして

github.com

最終的に、無事にターミナルで表示できるようになりました。

パイプが繋いでくれた

longcat と iTerm2 とか、textimg と libsixel とか、プログラムの連携部分で両方にフィードバックする機会を与えてもらって、その一部を繋いでくれたパイプってすごいなーって思った。それ自体の機能であるプログラムの入出力を繋げることだけじゃなく、知らなかったプログラムと私、それまで参加してなかった開発コミュニティと私を繋げてくれたのすごいなーって思ったのが、LTでパイプについて話すことにしたきっかけでした。