時間という概念が好きだという話

たまに祝日や時間のライブラリをメンテナンスしたりしている。同僚に「なんでそんなモチベーションが出るのか?」と聞かれて「時間が好きだから」としか答えられなかった。なんというか好きなこと説明することは、根本的に難しいものがあるがやるだけやってみようと思う。

ブラックホールが好き

時間の話をするためには欠かせないが、なんかロマンがあるじゃん。よく分からない感じが良い。光が脱出できないなんてよく分からない存在が現実にあるのがすごく良い。

相対性理論が好き

完全に理解している訳ではないが、高速で移動すると時間がゆっくりになるってやばくないですか?ブラックホールの近くでぐるぐる回ってれば若さ保てるじゃん。

ブラックホールを回らなくても地球を高速で回っている人工衛星は僅かながら相対性理論の影響を受けて、時間がゆっくりになっている。そのため、GPSにはその補正が行なって計算が行われている。意外と身近にある相対性理論

1秒

じゃあ1秒ってなんなの?ってなる。時間は重力や速さの影響を受ける。地上と人工衛星で時間が違う。なんなら、地上とスカイツリーでも差が出る。1秒の定義はありますが、地球は自転してるし、公転もしてるし、太陽は天の川銀河の周りを回ってるし、天の川銀河も移動してるしで地球上での1秒はまぁなんとなく共通認識があるよねくらいの話でしかなくなる。普通に生活する分には全然関係ない。でもなんか気になる。気になってきましたよね?

人間の時間扱い

1日

概ね、太陽の運行によって決まっている。つまり、太陽が一周したら一日としている。一日の始まりは国によってまちまちだった。太陽がもっとも高く上ったのが1日の真ん中だったり、日が沈んだら一日の終わりとだったりする。現在は、大体同じように深夜0時が一日の始まりとして扱われている。良い世界。

タイムゾーン

それぞれの国で昼の12時で太陽が登っててくれないと、普通に生活する分では割と困ってしまうので時差を設定している。飛行機で飛び回っている人にとっては1日が伸びたり縮んだり無くなったりする。太陽が南中に来るタイミングを昼の12時にする国が多いが、わざとずらしているところもある(ヨーロッパ圏)。国が広い場合は分割する必要があるが、細かく分割しているところ(アメリカ)や大きくても一つのことろ(中国)がある。地球が丸さを感じる。

今この瞬間は世界中で同時に存在しているが、今を表す時刻は異なっている。プログラミング的には5月20日21時22分34秒は日本時間の話かサーバーが置いてあるところの話かわからなくなるので、タイムゾーンも含めて保存して置いた方がいい。高速化は知りません。

サマータイム

タイムゾーンを年に2回も変える制度。昼の時間を有効活用したいらしいけど、体内時計が壊れるので最近はなくなる方向らしい。一日が25時間になったり、前の日に巻き戻ったりするため、プログラミング的には嫌いな人が多い制度。私もいい制度だと思わないので、滅びてほしい。

カレンダー

世の中には、いろんなカレンダーがある。本当にいっぱいあるので、書いていたら一冊くらいになるのでやめておきます。西暦や旧暦は知っていると思う。日本では太陽の運行を基準した太陽暦を使って、季節がいい感じになっている。月の運行を基準にした太陰暦は1ヶ月を数えるのには便利だが1年が355日しかないかったりする。グレゴリアン歴も1年の初めの決め方と各月の日数が道理的な理由じゃない。もっとましなカレンダーが使われてほしいと願っている。

西暦だと2021年ですが、和暦だと令和3年。他の国にも暦があってカレンダーと連動して色々あります。和暦は改元するので世界の暦の中でもカオスな方。日本固有の暦を使うなら神武天皇即位紀元を使った方がみんな幸せになれると思う。

そんな感じで時間って色々あるんですよ

考えたらキリがないくらいには時間の話は色々あるので、結構楽しい。

ペアプロと建設的相互作用

概要

教育心理学概論 の6章2節に建設的相互作用というものが出てきます。建設的相互作用を踏まえてペアプロを行なった方がペアプロの効果を高めるためられるかもという内容です。

本の内容

6章 建設的相互作用論

ミシンが縫える仕組みの理解を扱った研究と折り紙を使った計算を扱った研究が出てきます。
ミシンが縫える仕組みの理解を扱った研究では、ペアでミシンが縫える仕組みを納得いく説明を作って欲しいと依頼する。最も詳しく分析できたのは、ミシンは物理的に不可能な機械だと主張した大学院生と修理までしたことがある客員研究員だった。
折り紙を使った計算を扱った研究では、折り紙を渡して「3/4の2/3」に斜線を引いてくださいと依頼する。折り紙を追ってもいいし、1/2と計算してから斜線を引いてもいい。9割以上の人は折り紙を折った。第二試行として「2/3の3/4」を依頼しても、2割りしか計算してから斜線を引くことはなかった。ペアで同じ試行を行わせた場合は、第二試行で7割が計算してから斜線を移行した。

分かるまでのプロセス

「分からない」から「分かる」にいつる間に次の5つのステップを踏むと想定されている 1. ある事物や物事が果たしている機能の1つを「同定」する 2. 同定した機能について、その仕組みを「疑問視」する 3. 仕組みをより詳しいレベルでの機能のつながりとして「探索」する 4. 説明の候補になる機能のつながりを「提案」する 5. 提案した説明が十分正しいかどうか「確認」する

12章 問題を解く時に、2人の方が1人よりも有利になる条件

そもそもコードを書くのは問題を解くのとは異なるが、それは置いておく。
12章では、2人の方が1人よりも有利になる条件の話が書いてある。
2人で行った場合に時間が半分になったり、正答率が二倍になることはそうそうない。2人の手が見えやすい作業を行なった方が、回答に早く辿りつくようだ。逆に2人の手が見えない場合は1人で行うのと同程度の時間で回答にたどりつくようだ。

その他の資料

建設的相互作用に関する論文やブログをいくつか読みましたが、教育心理学概論がまとまっててわかりやすかったです。

感想

建設的相互作用をより高めるために2人が手が見えやすい作業することによってペアプロの効果を高めれそう。2人が手が見えやすいように作業するためには、常に考えていることを口に出したり、行うべきことをTodoリストに書き出したり、行うたいことをテストコードで表現したり、間違っても恥ずかしがったり怒らないようにしたり、良いことをしたら褒めたりする必要がある。2人が手が見えやすいように作業することは簡単にはできることではなく、ある程度訓練する必要があると思われる。

ペアプロにはレビューとは違うものがありそうなメモ2

分かるまでのプロセス

「分からない」から「分かる」にいつる間に次の5つのステップを踏むと想定されている 1. ある事物や物事が果たしている機能の1つを「同定」する 2. 同定した機能について、その仕組みを「疑問視」する 3. 仕組みをより詳しいレベルでの機能のつながりとして「探索」する 4. 説明の候補になる機能のつながりを「提案」する 5. 提案した説明が十分正しいかどうか「確認」する

これらを行うにはペアで行ったほうが良さそうである。

問題を解く時に、2人の方が1人よりも有利になる条件

そもそもコードを書くのは問題を解くのとは異なるが、それは置いておく。
12章では、2人の方が1人よりも有利になる条件の話が書いてある。
2人で行った場合に時間が半分になったり、正答率が二倍になることはそうそうない。2人の手が見えやすい作業を行なった方が、回答に早く辿りつくようだ。逆に2人の手が見えない場合は1人で行うのと同程度の時間で回答にたどりつくようだ。

このことから、2人で作業することで確実に効率的とは言い難い。ただ、常に2人の考えていることを共有しながら作業を行うことによって相互作用を発生させやすいと思われる。

ペアプロにはレビューとは違うものがありそうなメモ

まだ調べ中なのです

経緯

教育心理学概論を読んでいて、

と呟いたら興味深いと言われてしまったのでメモしながらまとめることにした。
この本はまだ9章までしか読んでいませんが、6章と9章がおすすめです。

本の内容

教育心理学概論 の6章2節に建設的相互作用論というものが出てきます。ミシンが縫える仕組みの理解を扱った研究と折り紙を使った計算を扱った研究が出てきます。
ミシンが縫える仕組みの理解を扱った研究では、ペアでミシンが縫える仕組みを納得いく説明を作って欲しいと依頼する。最も詳しく分析できたのは、ミシンは物理的に不可能な機械だと主張した大学院生と修理までしたことがある客員研究員だった。
折り紙を使った計算を扱った研究では、折り紙を渡して「3/4の2/3」に斜線を引いてくださいと依頼する。折り紙を追ってもいいし、1/2と計算してから斜線を引いてもいい。9割以上の人は折り紙を折った。第二試行として「2/3の3/4」を依頼しても、2割りしか計算してから斜線を引くことはなかった。ペアで同じ試行を行わせた場合は、第二試行で7割が計算してから斜線を移行した。

感想

ミシンの話で言えば、新入社員とペアで既存部分のドキュメントの作成するのが良さそうだ。
折り紙の話で言えば、レビューするのは異なる二人で同じような作業をしてすり合わせるような作業だと思って、「1/2と計算して斜線を引く」を思いつくのは確率は2割づつ(4割弱)あるが、ペアで作業したら7割に上がることになる。そんな単純な話でもないだろうが、相互作用による効果はそれぞれ考えるレビューより、ペアで作業した方が高まりそうな気がする。

知らないなら聞きましょうの精神

知らないことは、恥ずかしいことではない。

 社会人はプロフェッショナル集団である。それぞれの専門性を束ねて金儲けをする。それぞれの専門性があり、それぞれ知っていることが異なる。同じプロジェクトや目標に向かうときに共通の知識としてあった方がいいことはある。知っていることが異なるのため知らないことがあるのは当然である。知らないことは当然あるものとして扱うべきで、恥ずかしいことではない。
 学生の頃に授業でやっていないことを知らないことは恥ずかしいかもしれない。テストで良い点が取れなかったら恥ずかしいかもしてない。しかし、会社は学校ではない。均一に教育されない。仕事は授業ではない。知らないことは大した問題にはならない。業務を推敲できないことが問題になる。推敲するために必要なことをすべきで、知らないことを恥ずかしがっている場合ではない。

自分も聞くし、相手も聞く

 聞くことに対してハードルがある。年齢とか性別とか入社歴とか役割とかとか。聞くためにハードルを超える必要がある。お互いに聞けるような関係性を築いていった方がいい。

聞かれたら嫌がってはいけない

 自分が聞いた時に嫌がられたら次に聞くときのハードルが上がってしまう。聞かれた側は、聞かれたときに嫌がるのはよくない。可能な限り丁寧だが短くすますようにするべきだと思う。解るように説明してあげる方が、そこに労力を割くと疲れてしまう。1000文字書くよりもリンクを貼る方が楽だしわかりやすい説明になりがちである。1000文字書く必要があるのなら、ブログにしたり社内wikiにしたりいつでも検索して取り出せるようにしておいた方が良い。一度聞かれたことは、何度も聞かれがちのことである。
 「前にも言った」「何度も言った」「検索してみて」とかはよくない対応だと思う。 それで解決するならわざわざ聞いてはいない。  リンクを読め見てもわからないと言われたのに「リンクを読め」というのもよくない対応である。二度と聞く気にはならない。

終わりに

「知らないなら聞きましょうの精神」ってなんか長いのでもうちょっといい感じの表現があるといいなと思う

iOSの社内ライブラリをやめる

この記事の社内ライブラリはアプリとは別にリポジトリを分けて管理しているコードで、CocoaPodsやCarthageでアプリにインストールできるようにしているが、社内のアプリにしか使っていない物のことです。

なぜ社内ライブラリが必要だったか

大抵の会社ではアプリを一つだけ作っていることは少なく、複数のアプリを開発していることが多い。複数のアプリで社内のAPIにつなぐための通信コードやドメイン関連のコードは共有したい。1つのアプリは1つのリポジトリで管理することが多い。。そのため、共有したいコードをライブラリとしてアプリとは別のリポジトリに切り出して、ライブラリ管理ツールを使ってアプリににインストールして解決している。

アプリを一つのプロジェクトで管理する

具体的なやり方は以下のリンクをみて欲しい。 recruit-tech.co.jp

Xcodegenを使えば複数のアプリを一つのXcodeプロジェクトで管理することは比較的簡単にできるような環境が整ってきている。共通に使うコードをframeworkとして複数のアプリで扱うことができる。

社内ライブラリをやめる

全てのアプリを1つのプロジェクトで管理することができれば、全てのアプリを1つのリポジトリで管理することができます。1つのリポジトリでアプリを管理しているため、社内ライブラリをリポジトリに切り出す必要はなくなります。ライブラリに切り出していたコードも一つのリポジトリで管理できるので、社内ライブラリをやめることができます。

終わりに

私はやりましたが、全ての会社で当てはまるような話ではないと思ってはいます。

XcodegenでBridging Headerの設定の仕方

settingsに特定のキーで設定する。Xcodegenはキーさえわかれば、ほとんどの設定は指定することができる。

  application_name:
    settings:
      SWIFT_OBJC_BRIDGING_HEADER: "path/BridgingHeader.h"
``