科学論･科学史102

前期の科学論･科学史101の評価はBでした.

後期最初の講義だから, 前期から使っていた教科書を持ってくるのを忘れてしまいました. まあ完全に教科書に沿った授業をやっている講義ではないので良いんですが. どうせ初回はガイダンスでしょうし.

｢小さすぎて見えないものを見る｣

原子･分子･素粒子のミクロの世界.

講義で十分にわからない場合は教科書を読むなどして欲しい.

テストなどの形式は前期に引き続き. シラバスに書いている通り, AとBがある. A方式は小テストでと期末試験で評価する. B方式は期末試験1回で評価する.

B方式は就職活動などで講義に来れないことがある学生に配慮して小テストに点を付けない方式を提供するためのものです.

先生もA方式を選んで欲しいそうですね.

私は精神を病んで就職活動からドロップアウトしたためA方式を選ぶことになります.

そう言えばカプコンが面接申し込みしてないのに突如面接日を火曜日に設定して提示して｢受けるか辞退するかメール返して｣と言ってきたことがありました. 講義があるので素直に｢辞退します｣とメール返したら即座にお祈りメールを返信されたことがありました. ｢他の日にずらせないか｣という返信をしなかったのは私の就活後悔イベントの1つです. 申し込んでないのに自動的に1次面接日が決まり辞退したら自動的にお祈られたことは面白くもありますが. 就活のことを思い出して気分が悪くなってきた…

先生が授業中に強調するところや生徒に質問するところは重要なことが多く, テストに出ることが多い.

前期でわかったけれど, この講義, 講義自体には教科書を使うけど, テストは教科書から出なく, 先生の話から出てくる. ADHDの自分は思考がよくあさっての方向に脱線してしまうので, 先生の話を聴き逃してしまうことがあって厳しいことがわかりました. だから, こうやって先生の話をノートに取ることで聴き逃しを防いでいきたいです. 前期も書き留めておけば良かった, 手書きじゃなくてPCを使えばそんなに苦痛ではないですし.

まあ前期の成績がBだったので後期も単位は取れると思いますが…

政府の意向で合格点が50点から60点に上がったので揉め事が発生していたらしい. でも落とすのが嫌だからなんかやるらしい.

この講義, 小テストを行う日を予め発表しているため, 小テストの時だけ来る人が一定数居ます. 小テストの日だけ教室が満杯になるのでよくわかります. そういう人が落ちるのは本人も納得しているので良いらしい.

けれど毎日来て落ちる人が可哀想なので, 後期は講義の日もリアクションペーパー(演習問題)を出すことになったそうです.

このリアクションペーパー出すことでボーナスポイントを発行するようです. そしてリアクションペーパーは毎回出すわけではないけれど, 出す日を伏せることで毎日来る人が得をする仕組みを作るそうです.

当初はリアクションペーパーを5点にしようとしたけれどそうなると小テストも含めた満点が150点で60点合格になるのでそれはちょっとやめるそうです.

リアクションペーパーにまとめを書くことになるらしいです. 学習障害で手書きが非常に苦手な私にとってそれは非常にきつい, どうにかならないのかな.

｢学習障害で手書きが苦手なんですがどうにかならないですか｣と聞いてみたところ｢満点から1点減点する代わりに家でPCで書いてきて来週提出していいよ｣という返事を頂けました. 悩みますね. 私は手書きを行うと非常に苦痛を感じますが, 苦痛を我慢すれば書けないことはないので, 1点減点を許容するかは悩むところです. とりあえず1回やってみるということになりました.

｢インターネットから写してきたようなものは0点になります｣ということなので, ここにメモしているものと同一内容を提出している人は同一人物が書いているということを書いておきます. まあ, 勘違いされることはないでしょうし, 勘違いされたら自分が書いていることを実証すれば良いわけですが.

ミクロの世界. 電流, 小田急線を例えに出す. 温度, 新宿駅を例えに出す.

エントロピーと時間. どうして時間が一方方向に流れるか.

原子と放射線の発見. 原子を発見するのには非常に時間がかかった. 放射線はすぐ発見された.

量子力学とは何か? ミクロの世界とマクロの世界は違うことがだんだんわかってくる. 非常に難しく, 東京大学の学生でも最初はひどく失敗する. 量子力学というものが何か少しでもわかってもらえば良い. 色々な場所で使われているため非常に難しいけれど理解してもらいたい.

物質の起源. マクロの観点からするとビックバンを説明することになる. 宇宙は膨張していて, 時間の向きをとるとどんどん縮まっていく, 今から135億年前の宇宙は小さかった. そういった究極のミクロの宇宙で物質がどう生まれたか. 素粒子→原子核→原子がどのように作られたのか. ミクロの世界を使ってマクロの宇宙を理解する.

リアクションペーパーだけで16点, 小テストで満点を取ったとすると5回のうち3回で合格が決まって, 後は成績が上がるだけ.

persistent上に設計したデータベース上のカラムの命名を間違えてそれを変更できないと思ってましたがやってみたら意外とあっさり変更できました

persistent上に設計したデータベース上のカラムの命名を間違えました.

私はidを入れるカラムにidサフィックスを付けていませんでした.

• persistentの型付けはactive recordと違ってidをintegerではなく独自のnewtypeした型で取り扱うので混同の心配はない
• システムハンガリアン記法が嫌い
• 名前は短いほうが良いと思っていた

のが理由でした.

しかし, やはりuser_idが入るカラムは, userではなくuser_idとするべきでした. IDサフィックスは付けるようにするべきでした.

user <- get userIdのようなコードが出てくるので, idサフィックスを付けないと普通にコードがわかりにくくなります. まあ, それだけならpersistentはレコードのラベルに重複を防ぐためにモデルのサフィックス名を付けるので, count [ProjectUser ==. userId]みたいになって読みにくい以外の問題にはなりませんが, JSON化してデータをネストして出力する時に致命的な問題が出てきます.

例えばuser_idとネストして内容を含んだuserを作りたい時に障害となります.

{
    "project": {
        "id": 1,
        "user_id": 1,
        "user": {
            "id": 1
        }
    }
}

のようなJSONを自然に生成出来ないということです.

元からあるuserカラムを消去してネストしたuserを入れれば実現できますが, 明らかに自然ではないので苦しいです. 今から変えることも不可能ではないですが, かなり工数が変わるので, 現状本質的に問題になっていない部分を変えるのか悩んでいましたしかし, このデータベース設計は完全に失敗だったので, 考えるたびに頭が鬱にやられているため, 手間を掛けても修正しようと思います.

ああ失敗した. ActiveRecordがやっていたようにやればよかった Persistent :: Yesod Web Framework Book- Version 1.4でもIdサフィックスは付けているのだからそのようにすれば良かったんですよね.

webアプリケーション作成初心者だったのに他のフレームワークと違う独自路線をやろうとするから失敗することになる…

変更には数日かかると思ってたのでやることに踏みきれませんでしたが, 意外に2時間ぐらいでコンパイルエラーにならない修正が出来ました. 変更に強い静的型付けの極地であるhaskellの強みを見ました. NamedFieldPunsとRecordWildCardsを多用していたおかげもありますね.

後はPostgreSQLのスキーマの変更SQLを書くだけです. 意外とすぐに書けました. エラーを引き起こしている場所だけを変更すれば良かった.

｢汚いけどデータベースに載ってるから今更変更できない…どうしよう…｣と数日悩んでいたのがアホらしいぐらいにすんなり変更が出来ました.

haskellのレコード構文が一行の時は{}の左右にスペースを入れないことにしました

これまでhaskellのレコードに対するパターンマッチを行う時に左右にスペースを入れていましたが, 一行の時はスペースを入れないようにしました.

具体的に言うとX { a = a }がスペース入れる派閥で, X{a = a}がスペース入れない派閥です.

そもそも何故スペースを入れたいかというと, haskellのレコードに対するパターンマッチが複数行にまたがる場合, それぞれのレコードラベルの左にはスペースを入れる必要があるからです.

X
{ a = "a"
, b = "b"
}

みたいな感じですね. そうすると一貫性を保つためにはスペースを入れたほうが良いのです.

しかし,

• 一行の場合冗長に見える(特にNamedFieldPunsを使った場合)
• RecordWildCardsを使った場合短くX{..}と書きたい
• 複数行との一貫性問題はリストも同じ問題がありますが, リストを一行で書く時は[a, b, c]の用に書いている

という理由から, 一行の時は{}の左右にスペースを入れないことにしました.

まあ, 既存のソースコードに手を加えるほどの変更ではありません. しかし, これからはレコードが一行の時はスペースを入れない, 複数行の場合はスペースを入れる, と頭の中で規約を決めておけば悩むことがなくなるのでスッキリします.

情報リスク管理

当初は受ける予定のなかった講義ですが, 数学系の講義の単位が危ういので急遽追加した講義になります.

StripeのSMS2段階認証が出来ない問題でStripeから返信が来ましたが未解決

stripeのSMS2段階認証が出来ないのでサポートに連絡しましたの件でStripeから変更が帰ってきました.

要約すると｢他の電話番号を使うことをオススメします｣ということですが, 私の持っている電話番号2種で試してみましたが, 両方で出来ないんですよね.

｢まだ検証を完了できない場合は、私に知らせてください。｣と書いてあったので, その旨を返信しておきました.