WatoBlo

新卒エンジニア

「ご冗談でしょう、ファインマンさん」から読み取る大切なこと

理系のための小説?

「ご冗談でしょう、ファインマンさん」という小説をご存知でしょうか。

物理学を専攻している方ならご存知でしょう。1965年、量子電磁力学の発展に大きく寄与したことにより、ノーベル物理学賞を受賞した物理学者です。

 

※詳しくはWikiへどうぞ

リチャード・P・ファインマン - Wikipedia

 

 

この本は、そんな彼がユーモアに溢れた人生を物語るお話です。

構成は、小さいときのお話からノーベル賞受賞以降のことまで、彼の人生を年代ごとにミニストーリーをまとめた構成になっています。

僕はこの本を読んでいて、少し違和感を感じていました。ところどころ、オチが微妙だったりします。

まぁ創作小説ではないので、当然といえば当然です。

ですがこの本は日本で翻訳され、販売された当時はかなりの人気っぷりだったそうです。何かしら人を寄せ付けることが書いてあるのだろうと思い、読み進んでいくと、ある共通点に気が付きました。

 

ファインマンの志もとい、人生で重要事項にしてあることでした。

それは、自分が見た聞いた感じた物事・人に対して「誠実であること」だったのです。

いやいや、この小説ではファインマンはイタズラをしているじゃないか、もちろんいたずらもしていましたね。

ですが、彼はそのイタズラに実際に行動を移す前に、目の前の人間の言動・事象に違和感を感じれば、すぐに分析を行っていたのです。

なぜ、この人はこの行動をしたのだろう、まずは推測で◯◯という背景があるからだろう、実際にそれをもとに行動してみる、でもやはり違うようだ、そうだ!今度は〇〇をやって、からかってみよう。

 

 

そこにはこの小説の最後のお話である、カーゴ・カルト・サイエンスという1974年のカリフォルニア工科大学の卒業式式辞で語ったことに、全てがまとまっていました。

彼はこう語っていました(※すべて書くわけにはいかないので、短くまとめています

 

この科学の時代になっても、未だに未解決であり、根拠に基づかずに決められる物事や慣習が残っている。これを私は、カーゴ・カルト・サイエンスと呼んでいるのですが、このカーゴ・カルト・サイエンスには、「あるもの」抜けているものがあるのです。この「あるもの」は、諸君ら学生たちが研究を行っていく上で会得した暗黙の「あるもの」です。それは科学的な考え方の根本原理、言うなれば「誠意を尽くす」姿勢です。

 

諸君らが研究を行う際、結果を肯定する原因を並べるだけではなく、悪い要因も含めて省略せずに説明するべきなのです。他の誰が見てもわかるように、包み隠さず公表すべきなのです。

 

こんなお話があります。心理学を学ぶ女子大学生が、ラットを使って実験を行うとします。

 

状況XにおいてAという行動を取るのは、先行研究で証明されています。この大学生はラットがAという行動を優先的に取るのか、状況YにおいてAという行動をとるかを確かめる実験をしようとしていました。大学生は教授に相談し、状況XでAという行動をとる実験を行いたいと促すと、なんと教授は「それは過去の研究で証明されており、時間の無駄である」としたそうなのです。

これこそ誠実さに欠ける姿勢です。その過去の実験が間違っていることを考慮すべきなのです。時間の無駄のせいにして、自分がほしい結果を早望みしているだけなのです。

 

ヤングの実験では、ラットに餌のある方の扉を記憶できるかの実験を行いました。二回目の実験でも、ラットは餌のある扉へ向かいます。

きっと匂いがついているからに違いないと、箱をすべて洗浄し、もう一度実験すると、やはりラットは餌のある扉を当てます。

色で判別しているかもしれない、今度はペンキを塗りたくりました。それでもやはり当てます。

そうか、部屋の光の入り具合に覚えているかもしれない、今度は全く均一になるように光量を調整しました。それでもやはりラットは扉を見事に当ててしまいます。

施行の結果、ヤングは音、つまり部屋の音の反響具合でラットが餌のある扉を当てていることを突き詰めたのです。これこそ第一級の研究です。

 

ですから、先程の女子大学生のアイデアを拒否し、ある結果を得る方法だけを教えるなどという方針を決めてかかるのは、非常に危険なこととしか言いようがありません。

 

 

ファインマンはこの「科学に対する誠実な姿勢」を貫いていたからこそ、計算誤差による間違った法則や電子の軌道が提唱されていた当時の量子物理学に、大きな発見を見いだせたのでしょう。それは過去の研究が間違っているかもしれないという慢心しない志だったのです。

 

 <上巻>    <下巻>

 Amazon.co.jpアソシエイト

 

 理系の方におすすめと書いてありますが、特に文系理系を問わずに楽しめるお話ばかりです。この記事を書いている僕は物理学は専攻していませんし、あまり関係のない情報工学です。ですが僕でもわかる度合いに易しく説明してくれているので安心していいと思います。

 

少しでもファインマン「好奇心」を持ったなら、読んでみてはいかがでしょうか。

今日はこの辺で、ではでは。

 

 

Swiftの備忘録2

使うもの

・UINavigationBar(画面遷移)

・CocoaPods(ライブラリの導入)

・Realm(データベースのライブラリ)

・ローカル通知

===============================

 

・ContainerView(画面遷移)

 *参照*

SwiftでContainerViewを使ってみる - Qiita

SwiftでContainerViewとStoryboardをフル活用して複雑なUIを実現する際の実装ポイントまとめ - Qiita

AlamofireとSwiftyJSONでAPIを叩くチュートリアル - Qiita

 

Swiftの備忘録(最終更新 2018-02-11)

・Optional型について

SwiftではJavaやCのように、宣言だけして代入はしないということをするとコンパイラがエラーを吐く。よって、optional型にすることで変数の中身がnull(Swiftではnilと呼んでいる)であることを許容することができる。←めんどうではあるがわりと大事

・参照について

`weak` を書かないと、循環参照が発生し、メモリが解放されるべきタイミングで解放されないまま残ってしまう(メモリリークが起きてしまう)(メモリリークが多く発生すると、メモリが不足しアプリが落ちてしまう)古い機種だと少し影響があるかもしれない

`@IBOutlet` の場合も、Xcodeが自動的に `weak` を付けてくれるので特に意識する必要はない(現時点では)

取り扱うオブジェクトの数が増えて、(あまり設計として好ましくは無いですが)オブジェクトが相互に参照し合っているような状況が出てきて、循環参照によるメモリリークが疑わしいとなったときに、やっと思い出して使うことを考えてみる。

 

・UI部品について

 IBOutletはUIのパーツをプロパティとして参照するための仕組みで、IBActionはUIパーツのアクションをメソッドとしてコードに追加する仕組みである。

なので、IBOutletは名詞の名前(startButtonなど)を、IBActionは動詞の名前(buttonTapped)をつけるとより分かりやすくなる。

 

・イマイチピンとこないsenderについて

*具体例

func slidshowImage(_ sender: any) {

}

*IBActionで設定したもの

この関数の引数である sender はボタン等のUI部品を表している?

メソッドが呼ばれた時に渡される `sender` は、スライドショーを開始・停止するボタンなので、そこから戻る・進むボタンにはアクセスできない

呼ばれた時点ですでに他のボタンにアクセスできないので

 

・現時点で理解が曖昧な箇所を列挙(2012-02-07)

 ・制約

 ・プロパティ(保持型と計算型という2種類があるらしい)

 ・デリゲート

 

エラーへの対処

  • エラーメッセージをよく読む(読めない場合には翻訳サイトなどを活用する)
  • エラーメッセージのキーワードを見つける
  • エラー箇所の変数や文法などをよく確認する
  • エラーメッセージやエラー箇所に対して何が問題なのかの原因を特定するためにデバッグする
  • エラーメッセージをコピーしてGoogleで検索する(誰かが質問して答えをもらっている場合がある)

UIView

loadView / viewDidLoad

loadViewviewDidLoadは画面遷移後に1度呼ばれる。他の画面に遷移して戻ってきた時には呼ばれない。ViewControllerが生成された時に一度だけ行いたい処理をここに記述します。

viewWillAppear / viewDidAppear

viewWillAppearviewDidAppearはそれぞれ画面が表示される前、表示された後に呼び出されるメソッドです。画面遷移後に1度呼ばれ、他の画面に遷移して戻ってきたときにも呼ばれます。

viewWillLayoutSubviews / viewDidLayoutSubviews

viewWillLayoutSubviewsviewDidLayoutSubviewsはViewが実際にレイアウトされる前、レイアウトした後に呼び出されるメソッドです。UIViewControllerの生成時にViewに何か操作をしたい場合にはviewDidLayoutSubviewsのあとに処理を記述する必要があります。

 

アプリは瞬時に起動する必要があります。ユーザが新しいアプリケーションを評価するために費やす時間はせいぜい1~2分程度である、と言われています。つまり、この短い時間内にユーザが「このアプリは役に立たない、つまらない」と判断されたらアプリがアンインストールされてしまうと思っても良いでしょう。

そのためにはスプラッシュ画面の表示や起動時の余計な処理をできるだけ避ける必要があります。起動時にログインを要求するようなアプリもNGです。ログインしなくても、主な機能をひと通り使ってみることができるのが理想となります。初回起動時にいきなりログイン画面が表示されるとユーザは離れていってしまいます。

また、ユーザに設定情報の入力を要求しないようにすることも大切です。ではどのようにしたらよいのでしょうか?Appleは以下の方に方針を示しています。

  • ユーザの80%のニーズに応えるよう重点的に取り組む。大部分のユーザは、アプリケーションが期待通りに動作するので、改めて設定作業をする必要がありません。ごく一部のユーザしか必要としない、あるいは一度実行するだけの機能については除外します。
  • ほかの情報源からできる限り多くの情報を得る。標準で組み込まれているアプリケーションやデバイス設定でユーザが指定した情報を使用できる場合は、システムに値を問い合わせます。ユーザに値を再入力させてはいけません。
  • 設定情報が必要な場合は、アプリケーション内でユーザに入力を求める。ユーザが入力したあとはこの情報をすぐに保存します。2回目以降は入力をする必要がないようにしておきます。ユーザがこの情報を後から変更する必要がある場合は、いつでもアプリケーションの設定に移動できるように設計しましょう。

Swiftのデリゲートとプロトコル

  • デリゲートが必要なクラス(UITableViewなど)が数多くある
  • デリゲート(委譲)には、処理を代行してくれるクラスが選ばれる(主にViewController)
  • プロトコル(約束)には、空っぽのメソッドが名前だけ詰まっている
  • デリゲートに指定されたクラスで、プロトコル内のメソッドを実装してあげる
  • プロトコルには実装が必須のメソッドと、そうでないメソッドがある

 

画面遷移

遷移するときに呼ばれるprepare(for:sender:)メソッドを記述する。遷移する際に何かしらの処理を行いたい場合はこのメソッド内に記述する。

Cording Bat というプログラミングのトレーニングサイトが良い感じな件

あ、明けましておめでとうございます、watomonです。

 

コードを書いていたら年が明けていました。来年もそうであれば良いなと思っております。

で、色々ネットサーフィンをしていた僕ですが、面白そうなサイトを見つけたので紹介したいと思います。

 

Cording Bat 

http://codingbat.com/java

 

全て英語なので、英語が苦手な人は少し学習しづらいかもしれません。僕も英語が苦手なのですが、別に読めないとか聞いたことが無い単語は今のところ出てこないし、グラマーも易しめなので読めないことはないと思います。

 

 対応言語は JavaPython です。文法をある程度読んでからのほうが良いかもしれません。なので最初の方の問題は、初心者というよりは初級者向けかと思います。段々難しくなるだろうとは思っていますが、何せ僕もさっき知ったばっかりなのでなんとも。

 

解答・解説・アドバイスが丁寧

例えば最初の一番簡単な問題。下の画像を見てもらえるとわかりますが、コメントアウトで「*こうすればいいよ」とかも書いてくれてます。

 

*返り値をtrue falseのまんまではなく、aSmile,bSmileの引数でやっちゃえ的なこと書いてあります。確かにそのほうが綺麗だわ....

 

Warmup-1 monkeyTrouble

f:id:watomon:20180102134243p:plain

 

 僕自身競技プログラミングとかやったことがないので、これで練習しようかなぁと思っております。年明けに良いミニチャレンジにいかがでしょうか!