2014/8/18に見た夢

2014/8/18に見た夢。下記は起きた直後にメモした内容そのもの。

[夢の内容]
品川の駅にいる。
本当の品川駅より小さくてと東京の雑多町の駅という感じ。西日暮里みたいな。
夜で仕事でつきあいのあるインド人と一緒にいる。
駅は高架で上にある。下との間にエスカレータがある。
何かの理由で一人で下に降りる。
先のインド人がそこでから歩いて帰って行った。
駅のしたで外国人の数十人が踊りを行うと言っている。
マイムマイムみたいなみんなで踊る踊り、ただ、名前はあったが思い出せない。
多くは黄色のTシャツを着ている。オレンジの人もいたかも。
それに一緒に加わろうとしていた気もする。
私が加わるのに何か問題がありそうだが、まあ良いだろうと言うのが聞こえる。
私はなんか場違いな感じがしてエスカレータで駅の上に戻る。
何故か時間が夜の12時10分前になってしまっていて、終電から降りてきた人とすれ違う。
明日も朝6時から仕事があるのにこれでは帰れない。困る。
駅員に話しかけて、朝のスーパーひたちを使うとか、新幹線を使うとかを相談した。
常磐線なので新幹線は使えないのに、駅員は大阪方向と誤解していて新幹線がどうこうとか言っている。
しかたがないので降りて駅を出る。深夜の終電の終わった後なので、路地には明らかにガラの悪そうな連中がたむろっている。
絡まれないように足早にそこを立ち去る。どこか泊まれる場所を探そうとしている。
駅を見上げると、駅は大きいマンションの様なビルの一部として作られていて、ホームにN700系のぞみが停車しているのが見える。

何処かの古い平屋か2階建ての大きめの建物の中に入る。古アパートか寮のような所。世にも奇妙な物語に出てきそうな薄暗い所。
そこに勝手に入っているところが見つかると困るので、そこを出ようとする。

その後話が少し途切れて、そこが何故か北海道の実家の側になっている。明け方になっている。冬の終わりで雪が解け始めている。
北海道にいる事に疑問は感じたが、夢だからまあ良いやと思う。夢である事に気が付いている。
駅前通りを南方向に進んで住宅街に紛れ込む。人も家もまばら。
そこで大きい旧家のお屋敷の門を通って中に入る。
地下廊下みたいな所をうろうろする。だれかが侵入して来たと言うような趣旨の人の声が聞こえる。
おばあさんみたいな声。見つかったら困るのでその家を慌てて出ようとする。何故か外の門のところで迷う。
門をどちらに通っても庭になていてそとに出られない?

その後も何故か夜に戻った住宅街の様な所をさまよっている。
とても無機質な感じの住宅街で人の気配はしない。星新一やモモの挿絵にありそうな住宅街。
どこかお店の様な所に入れば良い。人と会えるはず、と思う。
少し歩くと明かりがついている建物が出てくる。小さいビルの様な建物も出てきて町の様な感じ。
ただ、とても無機質で新しくてシンプルで現実の街並みとは全然違う。白い箱だけで出来た模型の町の様な感じ。
背景も真っ暗で、建物以外の物も存在していない。建物の外には誰もいないが、中には人がいるのは分かる。
ある一つの建物に入る。通路が細かい気の壁で仕切られていて迷路みたいになっている。
IKEA等の部屋のショールームの様な人工的で小奇麗ない感じの所。
何かを探してうろついていると、水道の水の音の様なものが聞こえる。台所で洗い物をしている音。
そこに向かって足早に歩く。途中の木の仕切りも手で押しあけて進む。
一枚板で普通は押し開けられないが、夢の中なのでモノを変形されられることに気が付いている。インセプションの様な感じ。
水の音を出しているところにたどり着く。やっぱり台所である人が何か豆腐の入れ物の様なプラスチック製のモノを洗っていた。
何故かとても怒っている。でも、怒られても当然と言う風に自分でも感じている。理由は思い出せない。
何かの暗証番号の様なものを使ってリセットしろと言われている。夢をリセットするという事かも? とても桁数が多い暗証番号。アルファベット混じり。

そこで目が覚める。目が覚めたので夢の事をメモしよう思い、近くにあった白いボール紙の箱に何かメモを書いている。
お菓子のはこの様な少し深いボール紙の箱の内側に書いている。でも、これもまた夢だった。これが夢だとは気が付かなかったが。ここで目が覚める。

2014/7/27に見た夢

2014/7/27に見た夢。下記は起きた直後にメモした内容そのもの。

朝に普通に見た夢と、夜にあんずを寝かしつけている時にも夢をみた。

[朝の夢]
夢の中で、「これは夢の中の出来事だから」と誰かに話していた。
でも夢であることを夢の中で語って良いのかに疑問を感じていた。
どういう状況であったかはよく覚えていない。
夢の中の世界と言うのがどういう所なのかを説明しようとしていた気がする。

[夜の夢]
夜、あんずを寝かしつけるのに添い寝している時にも夢を見た。寝ていたのは30分位か?
TOEICの音声を聞きながら寝たがそれは特に夢には現れなかった。
夢の中でもあんずを寝かしつけていて、階段を降りるとそこは2階だった。
旅館の様に和室を複数ぶち抜きで使っていた布団を7まい位敷いていた。
実家の父の部屋の入り口の様な所で「上に布団を敷いているのになんで下にも敷いているの？」と聞いている。
そばの布団をみるとあんずだけが横になっていた。起きてはいる様子。
ただ、生後数か月の赤ちゃんになっていた。そこで「これは夢かもしれない」と思い、夢の中かの確認をすると、夢と判定出来た。
そこで意識が覚醒したようで映像がなくなって間もなく目が覚めた。

2014/7/26に見た夢

2014/7/26に見た夢。下記は起きてからその日のうちにメモした内容そのもの。

[夢の内容]
どこか古代日本の村の様な所にいる。子供がいる。
何かの理由で捕まっている。
夜暗い中そこから逃げ出した。藪や森の様な所を逃げている。
追手も追いかけてきているが、自分の背よりも高い藪の中を逃げているので見つからない。
藪を抜けるの何故か現代の日本の住宅街風の所にでる。
早朝の曇り空で全体が灰色の感じがする。
家の感じは北海道にありそうなもの。古くも新しくもないが、昭和60年位の街並み?
どこかの家の子として暮らすことになりそうな予感がしている。
何か特別な能力を持っている？

その後は別の夢？
青年の家や研修所の様な大きめの簡易な宿泊施設にみんなといる。
これから朝食を食べに行くところ。
昨晩は夜更かししたようでみな待ったりとしている。
食堂に向かう途中で誰かとすれ違う。「もう食べたの？早いね。」と意外そう。
大学のサークルの合宿の様な雰囲気。
一緒にいる人たちが誰なのかはわからないか、思い出せない。

その後和室の様な5，6人が泊まれそうな部屋にいる。
時間は分からない。みんなの煮詰まった感じからして夜中？
2，3人は女の子だった気がする。
親戚の集まり集まりかもしれない。
何かの相談をしているのか、込み入った話になっている感じがする。

所変わって駅にいる。
ジブリ作品に出てきそうな昭和40年代後半の駅の感じ。
東京郊外位の都会を感じる。
プラットフォームが幾つかあって、そこを階段のうえから見下ろしている。
先の女の子のうちの一人が訪ねてくることになっているらしい。
急に来ることになったらしくて慌てている。
来てほしくない理由が何かあるのかもしれない。
前に誰か別の人が来たときは、乗り換え駅まで迎えに行ったりと世話を焼いた事あったらしい。
ただ、今来ている子は自分でなんでも出来るしっかり者で、こちらのペースに反してどんどん向かってきている。
これもジブリ作品の主人公の女の子の様な感じ。

2014/7/23に見た夢

2014/7/23に見た夢をメモしていたので、それを今日(2014/8/30)に思い出しながら書いてみる。
そういえばそんな夢を見たなあと思い出せるが、詳細は分からなくなっている。

[メモ]
何処か公民館のような殺風景な中位の部屋。２階。
サークルの友達？ 何かを話し合っている。
大学生協の食堂の様なところ。余り物を配っている?

[夢の内容]
何処か公民館のような殺風景な中位広さの部屋。建物は2階建てでその2階の部屋にいる。
夜。サークルの友達の集まりの様な場で5,6人の学生風の人が集まって輪になって床に座って話をしている。
サークルの合宿の夜にありそうな一シーン。メンバは特に知っている人では無かった気がする。

所変わって大学生協の食堂の様な所にいる。古くてあまり綺麗ではない。
自分が学生だったころの食堂のイメージで、昭和40年代のコンクリートの建物。
床がコンクリートむき出しで薄暗い。多分昼間。午前か午後かは分からない。
そこでボランティアサークルの様な人達が食べ物の余りもの配っている。
目的は分からない。知っている人もいない気がする。

[別の夢]
別の夢の事を思い出す。
これも自分が昔通っていた大学の夢。
大学の校舎の中や図書館を歩き回っている。
目的はよく覚えていない。
大学の近くの地下鉄に載っていた気もするがこれはまた別の夢だったかもしれない。

2014/7/22に見た夢

2014/7/22に見た夢のキーワードをメモしていたので、それを今日(2014/8/30)に思い出しながら書いてみる。
そういえばそんな夢を見たなあと思い出せるが、詳細は分からなくなっている。

[キーワード]
インターン、病院、スイッチを作っている。ルナ、だまして入れる、リコー、器具を洗う、教室、自己紹介

[夢の内容]
何処かの研究室の様な所、病院かもしれない。そこの実験室の様な部屋に白衣を着た若い人5,6人が並んで立っている。
へやはあまり広く無くて20畳くらい? 真ん中に大きな机があり、壁に面しても机が並んでいる。
全体的に白い印象がある。
並んでいる若い人はインターンで来た学生の様だ。
そこで作っているのはスイッチかルータの様なもの。ルナと言うシリーズの様だ。
よく思い出せないが学生の中にここがリコーだと勘違いしている人がいる？
だが、それで入社してもらえるなら特に誤解を解く必要はないと思ったり、それではだまして入れる事になるのでよくないと思ったりしている。
もしかしたら同僚とそういう話をしているのかもしれない。
その後何故かそこで試験管などの実験器具を洗っている。
そして教室で自己紹介をしている。大学の入学後の最初の授業の前のオリエンテーションのような感じ。
「自分は社会人で皆さんよりも大分年上ですがよろしく」と言うような事を言っていた気がする。

[別の夢]
この夢を思い出そうとしている時に別の夢の事を思い出した。

同じように研究室いて何かソフトウエアの開発作業をしている。
大学の研究室の様に狭く、一人一人のスペースがパーティションで区切られている。
床はOA床のじゅーたんになっている。綺麗で明るい。
二部屋位あってその間を移動しようとしてる。

[その他]
さらに別の夢の事も思い出した。職場にいる夢、実際の職場とはちがうのだが。

こうしてみると夢を見ているときに活性化している脳の部分と言うのが起きている時とは別にあるような気がする。
そこの一部が活性化すると関連部分も活性化して夢を見ている時の記憶が蘇ってくるのでは？
これはあまり自然な行為とは思えないので、どういう影響があるのか少し引っかかる。

2014/7/21 に見た夢

2014/7/21に見た夢のキーワードをメモしていたので、それを今日(2014/8/30)に思い出しながら書いてみる。
一ヶ月以上前の夢なので断片的にしか思い出せないが。。。

下記のキーワードはメモにはあったが何のことなのか全く思い出せない。

草原、縄跳び、センサーの紐
犬、ボール、南極、国境、テレビ

下記のキーワードのキーワードについては何となく思い出せる。二つの夢の話。

[キーワード]
ゲームの世界、レベル23、ファイナルファンタジー、パーティー弱い、戦う場所

[夢の内容]
ファイナルファンタジーの様なゲームの世界の中にいる。
自分はレベル23、その世界ではかなり強い方らしい。
そこで薄暗い森か何かモンスターがいそうなところ抜けてそのゲーム世界の街にたどり着く。
街は夜のような感じで幻想的などこが光っているとも分からない証明の中にある。
ディズニーシーの中のどこかのアトラクションの中の様な感じの所。サーカスを連想させる雰囲気もある。
人はそれなりにたくさんいて、これもファイナルファンタジーの様な恰好をしてる。
乗り物も走っているがこれも遊園地の乗り物の様に人が歩くくらいの速さで走っている。
そこでパーティを組むことになった。何故か自分の仲間はとても良いわいメンバらしい。
その中では自分のレベル23と言うのはずば抜けて高い。
街の一角、広場の様な所にバトルフィールドの様な所があって、そこで別のパーティーと練習用に戦えるようになっている。
自分たちのパーティーも別のバーティーの挑発を受けて戦う事に。
弱いパーティーだと馬鹿にされている様だが、レベル23の自分にパーティーのメンバは期待しているようだ。

[キーワード]
会社の人、ホテル、レストラン、パスタ

[夢の内容]
一人で外を歩いている。多分昼ごはんを食べる場所を探しているだと思う。
出張からの帰り道の様な感じがする。少し昼ごはん時をを過ぎた位の時間。
天気は薄曇り、薄暗い感じはないが、青空と言う感じでもない。
閑静な住宅街の様な感じの場所の中の、ホテルかマンションの様な建物の中の一家にレストランがある。
建物のに入るためには少し長めのコンクリート階段を入り口に向かう必要がある。
その階段の上には雨除けに赤いビニールみたいみたいなものが張られている。
店に入るとケーキのショーケースの様なものがあり、フロアはそこそこ広くて仕切りなどはない。
サラダバーみたいなバイキング的な場所もあったかもしれない。
フロアの形は四角ではなくて、丸に近いような感じがする。
天井は高く、中葉には高に何らかのオブジェの様なものが飾られている。
もしかしたら、ウエディングケーキかもしれない。結婚式の2次会が出来そうな雰囲気の作り。
人は半分くらい入っている。会社の同僚二人があるテーブルで食事をしているのが見える。
そこに加わるべきか少し迷ってやっぱり一人で食べる事にする。
その店には初めて入る訳ではないようだ。
前に来た時のトマトソースのパスタが美味しかったことを覚えているみたい。
今回も同じものにするか、別のモノを試すべきかを悩んでいる。
結局その後トマトソースのパスタを食べたような気もするし、その前に目覚めてしまった気もするが、そこまでは思い出せない。

ベストですか? 自信は?

私の好きな韓流ドラマのシークレットガーデンの中で、主人公はデーパートのやり手の若社長という設定になっている。
その社長が部下の幹部の仕事に言う決まり文句が、
「ベストですか? 自信は?」
である。

この言葉には対象を問わない普遍的なものがある。

「ベストですか?」は過程、プロセスについて聞いている。
自分が最善を尽くしたか、自分の出来る最高のものになっているかという事だ。
これは絶対的な自己評価で、要する自分が一生懸命やっているならそれで良い。

一方の「自信は?」は結果について聞いている。
自分の仕事の結果が他人を満足させるもの、他人に勝てるものなのかという事だ。
これは相対的な自己子評価で、結果的に上手く行けばそれで良い。

さらにそれを本人に質問して答えさせる事で、自己責任を意識させている。
良いか悪い判断するのも自分であるため、良いという判断したという事も本人の責任になる。

良い悪いの判断さえ本人にさせてしまうと、社長自身は何をしているのだろう?
それは部下がベストで自信を持って行った事を信頼するという事だ。
この「信頼して任せた」いう事に対して責任を持つと言うのが社長の仕事になる。

TSP(Team Software Process)でも同じような考え方がある。
開発チームは常にマネージメントに対して自分たちが最高と思える計画を提案して、マネージメントはそれを信じてそれにしたがう言う考えだ。
これに必要なのは信頼であって、駆け引きではない。
相手に損をさせてその分自分が得をすれば良いというゼロサムゲーム的な発想では上手く行かない。

これは非常に(古き良き?)日本的な発想と合う気がする。
これが欧米の開発プロセスとして出てきたわけだから、間違った欧米化をして日本的な良い面を弱めてはいけない。

歩きながらだと考えに集中しやすい

少し前の話になるが、出張の帰りに駅から家まで歩きながらCourseraのprogfun-004のScalaの課題について考えながら帰った。
少し距離があって一時間位掛かるのだが、その間ずっとあれこれ考え続ける事が出来た。
よく言われるように歩きながらだと考えに集中しやすい気がする。

考えるという行為はそれなりにストレスが掛かる。
考えが出てくる前の「うーん。。。」と言う時には相当エネルギーを消費している。
言葉になる前のアイデアを言葉にしようとしているのか、意識下にある何かを意識上に引っ張り上げようとしているのかは分からないが、そういう類の事が行われているような気がする。

このストレスに耐えられなくなると「考えたけど分からなかった」という事になるので、このストレスにどれだけ耐えられるかが重要になる。
考える時に貧乏ゆすりをしたり、何か体を動かしたりするのはこのストレスを紛らわすため、逃がすための行動だが、歩くと言うのは特に効果的なのだと思った。

頭を使わない単純な行動が良いようなので、普段通る道を散歩すると言うのが一番良いらしい。
同じように、シャワーを浴びているときや、歯を磨いている時にも考えに集中出来るような気がする。

ディスクトップにホームグループのアイコンの非表示

[win8]
Windows8のディスクトップにホームグループのアイコンが出現。
F5を押してディスクトップを最新状態にしたら消えた。
根本的にはサービスを止めれば良いらしいがやっていない。
http://ziddy.japan.zdnet.com/qa5602174.html

NHK「お金と感情と意思決定の白熱教室」(ダン・アリエリー)を見て

TEDでお馴染みのダン・アリエリーがNHKで「お金と感情と意思決定の白熱教室」を行っていた。
勿論内容は行動経済学の解説。とても面白かった。

==== 第1回　人間は“不合理”な存在である！ ====
やっぱり行動経済学は面白い。

人間の「怠惰」を甘く見てはいけない。想像以上に面倒を避ける傾向がある。
デフォルトが決まっていると楽だからそれに引っ張られる。

直感的に正しいことが何時も正しいとは限らない。
多くの人が同じような直感的な間違いをする事もある。
例えば錯覚などで、その直感が正しくないと認識していても、脳はやはり間違った認識を正せない場合もある。

目標や目的などの大きな事よりも目の前の小さな環境の変化に行動は左右される。
小さな変化で良い行動へ導ける可能性がある。
gamificationで目標な目的などの意味のあることの達成のために、バッジの獲得などのあまり意味のない事を経由するのにも通じる考え。

内容の殆どはTEDでのプレゼンの内容と被ってはいたが、改め聞いても面白かった。

また、うちの子供たち等を見ていると、人は不合理と言うのは納得できる。

==== 第2回　あなたが“人に流される”理由(わけ) ====
特に合理的な理由がなくても思わず人に同調してしまう事がある。
これも直感に頼った不合理な行動の一つ。
勿論正しい無難な行動である場合も多いが、何時も正しいとは限らない。
より狭く、より属したいと望んでいる集団に同調しようとする。
「ソーシャル・プルーフ（社会的証明）」=>「みんながやっている事なので正しいはず」という考え方。

相互主義=>「自分もこうするからあなたもこうして下さい」というメッセージ。
自分が先に行動して相手に行動を促す方が効果的。
「Thanks in advance」も「先にお礼を言っておくのでお礼に見合った事をしくれ」と言う一種の相互主義といえるかも。

群集行動。同調の影響で個人が普通では取らない行動を集団では取ってしまう危険性がある。
イジメや暴動もこの一種と考えれる。
意思決定はおかれている環境の影響を多分に受ける。
社会的規範が明確でない場合は、一人が悪い行動をすると、それが許容される行動とみなされて、さらに過激な行動になっていく場合がある。

見られていないと規範に従わない傾向がある。モラルハザード。
ネットの匿名性。

一人の規律違反が集団全体に悪影響を与える。守らないことが許容されるという事が社会規範と見なされてしまう。
断固に容赦なく対処する必要がある。

同調を利用して人に良い行動を取るよう導ける可能性がある。
gamificationのsocial power

==== 第3回　デート必勝法 教えます ！？　～人々の感情をどう動かすか～ ====
感情は人類共通の言語。世界中の誰にでも同じ様に当てはまる。
進化の古い段階で獲得されていて、人間以外の動物にとも共通している。

感情は緊急時に考えなくても行動するための非常装置。
これは原始時代には特に有用だったと考えられるが、直接的な生命の危機に直面する事が少ない現代人にとっては合理的な判断を狂わせる要因になってしまうことが多々ある。

感情は予測したりコントロールするのは難しい。
感情は置かれている環境の影響を受けやすい。環境を変えれば感情も変わる。
頭では理解していても感情は抑えられない場合がある。
感情は長続きしない。

客観的な認識とは両立しない。
感情について客観的に認識して、その感情に何らかの理由を見つけてしまうと感情のスイッチがオフになる。

理性よりも感情に突き動かされている。
感情に上手く訴えかければ強い動機づけになる。
抑えることが重要な場面もあるが、上手く動機に結びつけることも重要。

問題が大きくなるほど感情的には無関心になってしまう。
統計的な話になると想像が難しくて感情スイッチが切れてしまう。
生き生きと想像出来ることが重要。

感情の発端の誤認。
楽しいから笑うのか、笑うから楽しいのか。
感情の発端を把握するのは思っているより難しい。
後付けで理解しやすい理由を付けている場合も多い。
発端の誤認を上手く使って動機づけすることも出来る。

自分は本質的には平均的な人よりも感情の起伏が激しいのかもしれないと思った。
感情の起伏が激しいことから来る問題が発生する事が多かったために、自然と感情を抑えるすべが身に付いた?
感情の発生に理由を付けることで不安が減少するので、感情が発生すると直ぐに何らかの理由を探して感情のスイッチを切るようになってしまった?
今でももちろん感情的な行動をする事はあるが、その後は強い自己嫌悪感がある。これも感情だが。
感情的になって自己コントロールが効かない状況への不安から、感情を上手く使って自分を動機付けることが出来ていない?
感情的であることを無理に抑えているので、感情的な振る舞えを見ると嫌悪感が湧く?(shadow)
最近は嫌悪感が湧いてもそれは自分のshadowを見ているからだと認識して嫌悪感すら抑制している気もする。

子供たちは当然感情の赴くままに生きているが、今後どう感情と付き合って行くかは親の行動の影響を多分に受ける気がする。
上手く感情と付き合って行けるように何か出来ることはあるのだろうか。。。

==== 第4回　ダイエット成功への道！～自分をコントロールする方法とは～ ====
今回は自己コントロールについて。
結局原則にあるのは、人は大きな有意義な目標よりも、目先の小さな欲求、誘惑によって動かされているという事。
大きな目標の達成を目先の欲求と結び付けたり、欲求に捕らわれる前に欲求の影響を受けにくくする状況を作るなどの手がある。

[双曲割引]
人は将来の大きな利益よりも、目の前の小さな利益の方を優先させてしまう傾向がある。
人は現在に生きていて、将来は現在には勝てない。

これは人間がまだ動物だった時から備わっている本能的な所から来ていると思われる。
動物にとっては一寸先は闇で、将来はコントロール出来ないとても危ういもの。
少し先の将来でも自分が生きているかどうか分からないので、将来の利益を当てにするより今の利益を確定させた方が有利。

人間にとって将来は動物比べれば随分不確実さが減っているはずだが、直感は将来を過剰に不確実に感じさせてしまう。
これが色々な局面で不合理な行動を取らせてしまう元凶に思える。

双曲割引とは、同じ利益であっても遠い未来であればあるほど価値は割り引かれて低下するが、現在から近い将来の間は割引率が高く、遠い将来では割引率が小さくなっていくと言う性質を表している。

例えば１年後に10,000円もらえるのと、１年と１週間後に11,000円もらえるのでは、後者を選択する人でも、一年経過して今日10,000円もらえるのと、１週間後に11,000円もらえる状況になった際には、過去の選択と矛盾して今日の10,000円選択する傾向にある。
この傾向は双曲割引で近い将来と遠い将来の割引率が同じでないことに起因していると捉えることが出来る。

[代替報酬]
遠い将来の大きな報酬を得るための行動をさせるためには、その行動を行った時点で何らかの小さな報酬を与えられるようにすると良い。
この小さな報酬自体は将来の大きな報酬と直接関係している必要はない。
これを代替報酬と言う。
よくある例がテストで良い点を取った時のご褒美である。
gamificationも代替報酬を効率的に活用する方法でり、今回の話の中でも触れられていた。

[損失回避]
同じ価値の代替報酬でもより動機付けに作用するようにするためには「後悔」を利用する方法もある。
人は損失回避から報酬を得られる喜びよりも失った悲しみの方をより強く感じる傾向がある。
あらかじめ報酬を前払いしておいて、行動が実施されなかったら没収すると言うのは効果的な方法。

[報酬の新鮮さ]
同じ報酬を何時も受けていると慣れてしまって最初よりも報酬の価値を低く感じる傾向がある。
これを防ぐには報酬には不確実性があった方が良いという事になる。
例えば毎回100円の報酬があるよりも。50円、100円、150円をくじ引きでランダムに与えた方が動機付けになりやすい。

これを損失回避とも組み合わせて、行動が実施されず報酬が与えられない日でもくじだけは引いて、「もし行動していればこれだけもらえたのに勿体ない」と伝えることで後悔の念を引き起こすことも出来るので、更に効果が高まる可能性がある。

[コミットメントデバイス]
目の前の誘惑には簡単に負けてしまうが、ある程度先の誘惑に対しては冷静な判断をすることが出来る。
したがって、将来の誘惑に対して冷静な判断が出来る時点で、将来誘惑が近づいても誘惑に負けないよな手を事前に打てれば有効である。
これが有名なオデュッセウスとセイレーンの逸話にあるように、自分が誘惑に負けた行動が出来ないように冷静な時に手を縛っておくという事になる。
この未来に対して制約を掛ける仕組みをコミットメントデバイスと言ったりする。
人前で行動を宣言して後には引けないようにすると言うのもコミットメントデバイスの典型的な例。

==== 第5回　“お金”の不思議な物語 ====
[ほかのジャンルのモノと比較するのは難しい]
お金を使う時にも本来は機会費用を考えた方が良い。
日本で新車を買いに来た人たちに「新車を買う事で何を諦めたか(機会費用)」を聞いた。
答えの多くは「他の新車を買えなくなった」
これはモノの価値を考える際に、ほかのジャンルのモノとの比較の難しさを表している。
今自転車を買うのとその分を老後の資金として取って置くのとの比較はとても困難。

[お金の相対性]
お金を絶対額ではなくて比率で判断してしまう傾向がある。
100円のモノが110円なら高くて買わないが、1万円のモノが1万10円でもあまり気にならない。
大きな買い物をするときには相対的に誤差と思える金額も大きくなってしまう。
これは特に家を買う時や車を買う時などに顕著。

[支払いの苦痛]
消費のタイミングと支払いのタイミング一致すると支払いの苦痛は大きくなる。
クレジットカードや電子マネーは支払っている気がしないので、支払いの苦痛は小さい。
自動引き落としも同様に支払いの苦痛が小さい。
支払いの苦痛が小さいと無駄遣いしやすくなってしまう。
消費と支払いが直径するような工夫をすれば支払いの苦痛が大きくなり無駄遣いを防げる。
バーで飲むときに一杯づつ、もしくは一口づつ? 現金で会計する。
冷暖房をコインを入れたら一定時間動くようにする。
車の走行メータや燃料計を金額表示にする。

[心の会計]
使い道に応じて心の中で予算枠を決めて使う事。
予算枠の変更をしたくない、もしくはする必要がないと言う心理が働く。
毎月定額で預金をしている場合、それ以上にお金が余っても預金せずに使って良い気分になる。
ポイント還元されると、それはあぶく銭で他のお金と違って無駄に使っても良い気分になる。

[無料の魔力]
0円と10円、10円と20円では同じ10円差だが0円は特別に感じる。
0円であると質が劣るものでも過剰にはびこってしまう。
そうすると他者も0円に値下げする必要が出てしまい市場が崩壊する。(底辺の競争)

[アンカーリング]
一旦基準にする金額が定まると、そこからの高低により割高、割安が判断される。
メーカー標準価格や過去の価格など。
一旦無料でアンカーリングされてしまうと、無料以外はすべて割高に感じて敬遠されてしまう。
ネット上のサービスやアプリなど。

==== 第6回　私たちは何のために働くのか？　～仕事のモチベーションを高める方法～ ====
[努力と成果]
成果に対する報酬の基準が無い場合は、労力に対して報酬が支払われる場合が多い。
簡単に出来たことには低い報酬、中々出来なかった事には高い報酬。
スキルが同じ場合は問題ないが、高スキルのために労力が少なかった場合でもスキルは過小評価されやすい。

[アンダーマイニング]
内発的動機で行動しているところに外発的動機が加わると、内発的動機を弱めてしまう事。

[認知と無視とシュレッダー]
行った成果の認知するだけでもモチベーションは向上する。
成果を無理するのはシュレッダーに入れるのと同様にモチベーションを低下させる。

[オーナーシップ、愛着]
自分の所有物になると価値が高いと感じる。

[手間をかけると価値が上がる]
自分が手間暇かけて作成したものは、他人が作成したものより価値が高いと感じる。

[自社開発主義]
自分のアイデア他人のアイデアよりも価値が高いと感じる。

[やりがい]
産業革命は肉体労働の時代でアダムスミス的な分業と効率化が重要だった。
現代は知的労働の時代でマルクス的なやりがいが重要になっている。

==== 全体を通して ====
行動経済学の面白さが伝わる良い番組だった。
直感に従っては適切に行動できないケースを知ることや、すくなコストで自分や他人や組織により良い行動を動機付ける手法として、ますます行動経済学やゲーミフィケーションが重要になっていくと感じた。

Simon Sinek: Why good leaders make you feel safe を見て

良いリーダの下では安心出来る。
権力者は自分の存在を脅かすが、リーダーは自分の存在を守ってくれる。
リーダが率先してメンバーを守るための利他的で自己犠牲的な行動を取る。
メンバーもそれを見習って他メンバーを守るために利他的な行動を取る。
そういう自分を守ってくれる組織に属していると安心できる。
利害関係ではなくメンバーであればどんな状況でも守られる。見捨てられない。信頼関係が必要。
一番良い例が家族。親子の関係。終身雇用やレスキュー隊、地域社会や国も等もその例。

利他的な行動を取っている人に理由を尋ねると「他人も自分にそうしてくれるから」と決まって答える。
環境がそうさせる。そういう環境に置かれれると利他的な行動をする様になる。

原始時代から人類は生存の脅威にさらされてきた。
それに対抗するためには利他的な相互協力が必要だった。
生存するためには自分を守ってくれる組織に属する事が必要。
本能的に組織に帰属したいと言う社会的欲求が備わっている。
組織に属するためには自分も組織のために利他的行動を取ることが必要。
この帰属欲求と組織から外される事への恐怖は非常に強い動機付けになりえる。
多くの場合は良い方向に働きそうだが、悪用すると人にとんでもない行動を取らせてしまう危険性もあり、注意も必要。

フリーライダーの様に自分は利他的行動はしないで他人の利他的行動の恩恵を受けるのみのメンバーが出てくると一気にモラルが低下して組織が維持できなくなりそう。
これを防ぐために規律で縛ると今度はアンダーマイニング現象でモラルが低下するかもしれない。
利他的行動を尊重する組織文化が必要? 宗教とか?
義理人情や組織への忠誠心といった日本的思想が役に立つような気がする。

Dan Gilbert: The psychology of your future self を見て

[概要]
何故人は後悔する事が多いのか?
人は常に変化し続けている。
未来に対する自分自身の変化を過小評価する傾向がある。
1000人のグループを二つに分ける。
一方には今から10年後の自分がどの程度変化しているかをヒアリングする。
他方には10年前の自分から今までどの程度変化しているかをヒアリングする。
結果、実際に発生した変化よりも将来に変化の見積もりが過小評価の結果になった。
将来を想像する事が困難であるため、過剰に変化しないと思ってしまう。
このギャップが後悔の一因になっている。

[コメント]
言っている事には共感できる。
過去の経験や今の直感を過大評価する傾向があると言う事。
未来の不確実性を過小評価している訳ではないので注意は必要。
不確実性の過大評価->未来予測に対する思考停止->過去と現在の継続の過大評価につながっているのかも。

ではどうやって対応すれば良いのか?
過去の経験や今の直感が今後も持続する事を過大評価しない様に意識する。
過去から変化してきたと言う事を意図的に思い出すようにする。
未来の変化の可能性をなるべく想像して、変化に対処出来る様に準備する。

Programming in Scala, First Edition: Chapter 29

29. Combining Scala and Java
  scalaはJavaのprogramやframeworkと一緒に使われることが多い。
  scalaはJavaの互換性が高いので、普通に使っている分には問題ない。
  それでも時々はJavaとの組み合わせで問題になる場合もある。
  ScalaからJavaへの変換
    特にJavaからScalaを呼び出すときに重要。
  JavaのannotationsをScalaから使う。
    Scalaを既存のJavaのframeworkで使う場合に重要。

29.1 Using Scala from Java
  General rules
    Scalaは標準のJavaのバイトコードに変換される。
    可能な限りScalaの機能はJavaの機能に直接対応付けられている。
      class, method, string, exception等。
      overloaded methodの実行時解決もJavaと同様に出来ない。
        ScalaではやりたかったがJavaと合わせるために諦めた。
    Scala独自の機能もある。
      trait, generic type等
      Javaが持っている複数の機能を組み合わせて実装されている。
      どの様にJavaに変換するかは日々進化している。
        javapの様なツールを使って".class"ファイルを調べれば変換の詳細が分かる。
  Value types
    Int等は可能な限りint等に変換しようとする。
      性能面で有利だから。
    int等が使えるかわからない場合はjava.lang.Integer等のwrapper classeに変換。
      List[Any]に格納しようとする場合等。
  Singleton objects
    Javaのstaticとinstance methodの組み合わせに変換される。
    名前の末尾に$が付加されたJavaのclassが作られる。
    MODULE$というstaticのfieldが付加される。
      起動時にそのclassのinstanceが一つ生成されて格納される。
    同じ名前のclassを持たないstandaloneの場合は異なる。
      $が付かない同じ名前のclassに変換される。
      methodは直接static methodに変換される。
  Traits as interfaces
    ScalaのTraitsは同名のJavaのInterfaceを生成する。
    Javaのtypeとして使える。そのtypeの変数を通してScalaのobjectのmethodを呼べる。
    TraitsのJavaでの実装するのは実用的ではない。
    全てがabstract methodのTraitはJavaのInterfaceに直接変換される。
      JavaのInterfaceをScalaで定義する事が出来る。

29.2 Annotations
  Additional effects from standard annotations
    コンパイラがJava特有の付加的な情報を吐き出す場合がある。
      先にScalaの一般的なルールをチェックして、その後にJava特有の処理を行う。
    Deprecation
      JavaコードがScalaのmethodにアクセスした際にJavaコンパイラが警告を出す。
        ScalaのコンパイラがJavaのdeprecation annotationを付加するので。
    Volatile
      Javaのvolatile modifierと全く同じ効果を持つ。
        ScalaのコンパイラがJavaのvolatile modifierを付加するので。
    Serialization
      @serializable class -> Javaの Serializable interfaceが付加される。
      @SerialVersionUID(1234L) -> private final static long SerialVersionUID = 1234L;
      @transient -> Java transient modifier.
  Exceptions thrown
    Scalaでは例外が補足されるかどうかをチェックしない。
      Javaではどの例を投げるか宣言して、それが補足されているチェックしている。
      でもこれが失敗だったのでScalaでは止めている。
        警告を止めるためにだけに意味の無い例が処理が掛かれることが多かった。
        これは単にコードを読みにくくしているだけ。
    Scalaのmethodは例外を投げない宣言でJavaに変換される。
    JavaからScalaのコード使う際に投げる例外の宣言が必要になる事がある。
      @throws(classOf[IOException]) def read() = in.read()
      上記でIOExceptionを投げる宣言が出来る。
  Java annotations
    Java frameworkの全てのannotationは直接Scalaでも使う事が出来る。
      Javaで書いているのと同じように書けばよい。
  Writing your own annotations
    Javaのreflectionから使えるannotationを作る。
      Scala内でJavaの記法で書いて、javacでコンパイルすれば作れる。
      Scala内に各意味が無いのでScalaのコンパイラではサポートしていない。
        Scalaが何時か自身のreflectionをサポートする時にはサポートするかも。

29.3 Existential types
  Existential typesはJavaのtypeにScalaからアクセスする時に使われる。
    言語仕様の一部としてJavaとは関係なくサポートされてはいるが。
  宣言の仕方
    type forSome { declarations }
  JavaのIterator<?>のScalaでの宣言
    Iterator[T] forSome { type T }
      Iterator[_] と書いても良い。
  JavaのIterator<? extends Component>のScalaでの宣言
    Iterator[T] forSome { type T <: Component }
      Iterator[_ <: Component] と書いても良い。
  Existential typesを使えばTがJava内にあってScala内では不明の場合でも、Tが分からないくても使えるmethod等は呼べる。
  Iterator<?>の?の型を参照する必要がある場合
    型パラメータTありのmethodの引数としてJavaからコールしてもらう。
      型を参照できるようになる。
    戻り値として返す時はabstract typeをmemberとして持つabstract classのtypeをTで確定したobjectを返すようにする。

29.4 Conclusion
  Javaと連携させる時はScalaのJava上の実装も意識する必要がある。

2014/8/20に見た夢

8/20の夢の内容を当日の朝にキーワードだけをメモしておいた。

8/24深夜に上記キーワードを見て思い出せることを書いている。
既に5日弱間経っているがキーワードを見るとそれなりには内容を思い出せる。
そう考えると、夢の内容は忘れてしまっていると言うよりも、思い出せなくなっているだけの様に感じる。
似たような夢を何度も見たり、寝る前や明け方になると過去の夢の事をふと思い出すのも脳の状態が夢を見ていた時と似たようになっているからなのかもしれない。

[キーワード]
坂、原付、ローラースケート、後輩、子供、水、坂、学校?、テント?、砂、注射器、燃料、午後、青い空

[夢の内容]
午後、夕方に近い気がする。3時位？
晴れていてそらが青い。所々に白い雲が見えていたような気がする。
気温については特に暑くも寒くも無く快適で、風もあまり感じていない。
(そういえば夢の中では温度、湿度、風などはあまり感じない気がする)
何故か全体的にただっ広い砂地の様な所、周りは平らで何もない。砂は白い。沖縄の砂浜みたいな砂。
そこに高校の様な建物が建っている。白い2階建てくらいの建物。青年の家や研修所の様な感じにも見える。
すぐそばに丘がある。自然に出来てる丘だが形があまり自然でない。スキー場の様な直角三角形の形をしている。
その急斜面側が建物の方に向いていて、緩斜面側が建物から離れるように続いている。
丘自体は岩肌と言うか、砂利の様な素材に緑の草が生えている様な感じ。
手稲山を登山する途中の急斜面の様な見かけをしてる。

理由分からないがその急斜面側を登っている。結構楽に登っている。相当な急斜面のはずだが。
所々踊り場の様な所あって、そこを経由して登っている。
登るルートも何通りかある様子。

頂上まで登ったら緩斜面を下る事になる。斜面は人工スキー場の様に等幅で大体一直線、途中に若干分岐はあったが。
斜面も全体的に白い砂で覆われている。深さはあまりないのかあまり沈み込みこむような感じでもない。
見晴らしがとても良くて地平線が見えるきがした。町はなくてアニメに出てきそうな緑の森の様な風景が地平線まで続いている。
ここでは若干夕焼けそらの様なそらが少し黄色くなっている感じがした。
そこを下るのにスクーターの様な乗り物に乗っている。
何故か会社の後輩が少し前を走っている。
砂地を走るのでカーブはダートの様に横滑りしながら走る。
特別恐怖もなくて、ゆっくり快適に走り降りている。
(そういえばスキーをする夢も大人になってスキーを全然していないのにたまに見る)
途中で道少し分岐していて、後輩は緩斜面と言うか傾斜が一時的にほとんどなうなっている方を走っていたが、私は方はそのままの斜面を下りて行った。
そうすると途中で崖の様な所を急に上に事にしまった。傾斜が無い道は崖の上にそのままつながってたので、下がった分崖を上らなくてはいけなくなった感じ。
後輩が行った道を行けば良かったと後悔しながらスクーターを持って崖を上る。
これも特に苦労はせずにジャンプしてすいすい登っていく感じ。
(夢の中ではよくある事)

斜面を下りたら何故かその丘から回り込んで再び建物の方に戻っている。
建物には入らずに建物の正面脇の方に経っているテントの様に向かう。
良くお祭りや運動会の事務局が設置されているようなテント。
今度は何故か家族と一緒にいる。乗り物もローラースケートの様なものに変わっている。
少し古い感じのもの。そこにガソリンか灯油の様な燃料を入れる。色は透明ではなくててんぷら油の様な色をしている。
少し大きめの注射器を使って燃料を入れていた。

燃料を入れた後に再び丘を上がる。上がった時の事はあまり覚えていない。
もしくは上りか下りかがあまり意識されない状況になってきたのかもしれない。でも、何となく以降は下りだった気がする。
あんずと二人で坂を下ろうとしてる。
今度は集団下校の小学生のグループの様な人たちと一緒。
何故かコースを外れて外に落ちそうになる。
そこは砂地ではなくて低木が斜面一面に密集して生えている様な所。
低木は密集しているので、その上を歩いてコースに戻ろうとしている。
こーすに戻ったと思っても何故かまたコースを外れていしまう。
低木の間にトトロに出てきた低木のトンネルの様な所がある。
そこは少しだけ水が流れていてウオータースライダーの様になっている。
そこを滑って進もうとすると、上から小学生が滑り降りてきて衝突しそうになる。

そのあたりで目が覚めたきがするが、どこで目覚めたのかはあまり覚えていない。

javascript, bookmarkletのメモ(2014/6頃)

主にbookmarkletを作るためにjavascriptについて調べた。

encodeURI()でbookmarklentのエンコードも出来る。改行は?
javascriptにはヒアドキュメントはない。エスケープして書くしかない。

jquery-ui.jsが読み込まれていないとautocompleteは使えない。
http://stackoverflow.com/questions/11315595/loading-jquery-and-jquery-ui-in-bookmarklet-if-theyre-not-already-loaded
http://blog.ethertank.jp/2010/10/04-17:25:07
jquery-ui.jsも読み込む様にしたら上手く動いた!!

jQuery.noConflict(1)でライブラリの再読み込みを何か制御できるようだが、よく分からない。

iframe内のdomにはdomainが同じじゃないとcross domain制限に引っかかる。

javascriptのeclipseのplug-inもある。
JSDT
Google Chrome Developer Tools

fbLikeSmallerと言う、facebookのlike buttonを小さくするbookmarkletも作ってみた。
アクセス制限でfacebookとlike buttonが読み込めない環境の時に読み込みエラーのボタンが大きくひょじされて読めないため。
//コメント使えないという単純所でハマった。。。

Programming in Scala, First Edition: Chapter 28

28. Object Equality
  2つの値が同じかどうか比較するのは見た目以上に難しく間違いやすい。
  同一性の詳細と同一判定の実装方法について考察する。

28.1 Equality in Scala
  Javaの同一判定とscalaの同一判定の定義は異なる。Section 11.2
  Javaの同一判定は二つある。
    ==演算子
      値型に対しては自然な値の同一性
      参照型に対してはオブジェクトの同一性(型非依存)
    equals method
      参照型に対するユーザ定義(型依存)の本質的な同一性
    ==演算子が参照型に対して自然な値の同一性で判定しない事が分かり難い。
      x, yがstringで同じ文字列であっても、x == yがfalseになる。
  scalaの同一判定
    eq method
      参照型に対するオブジェクトの同一性(Javaの==と同様)
    ==
      値型に対しては自然な値の同一性(Javaの==と同じ)
      参照型に対してはequals methodと同じ
        equals methodをoverrideして==の振る舞いを変える。
      ==を直接書き換える事は出来ない。
        class Anyでfinal methodとして定義されているため。
  equals method
    class Anyで定義されて全ての型に継承されている。
    Anyでdefaultとしてeqと同等に定義されている。
      overrideしなければJavaの==と同じ。
    overrideする事で==の振る舞いを型毎に定義する事が出来る。
      ** 自然な同一性を表すように定義するのが一般的。

28.2 Writing an equality method
  equals methodを正しく実装するのはオブジェクト指向言語ではとても難しい。
    2007年に行われた大規規模なJava codeの調査では殆ど間違った実装になっていた。
  同等性は多くの事の基盤になっているため。
    例えばcollection colにelem1を入れた場合
      "elem1 equals elem2"なら"col contains elem2"もtrueを返す必要がある。
  4つの落とし穴がある。
    1. Defining equals with the wrong signature.
    2. Changing equals without also changing hashCode.
    3. Defining equals in terms of mutable fields.
    4. Failing to define equals as an equivalence relation.
  Pitfall #1: Defining equals with the wrong signature.
    class Anyで定義されているequals
      def equals(x$1: Any): Boolean
    signatureが合わなければ当然overrideにならないが、間違えやすい。
      class Point (val x: Int, val y: Int) {
        def equals(other: Point): Boolean = x == other.x && y == other.y }}
      上記でも一見OKに見えるが、otherの方がAnyではないのでoverrideならない。
        overloadになってしまう。
        override修飾子も必要。
      正しくは下記でpattern matching等で型判定も必要。
      class Point (val x: Int, val y: Int) {
        override def equals(other: Any): Boolean = other match {
          case that: Point => x == that.x && y == that.y
          case _ => false }}
      ** overrideをつければsignatureが違いでコンパイルエラーになる。
  Pitfall #2: Changing equals without also changing hashCode
    hashCode methodもequals methodに合わせて再定義する必要がある。
    hashCodeもclass Anyで定義されている。
      def hashCode(): Int
    hashCodeはhashSetやhashMap等でobjectを検索する際に使われる。
　  o1 equals o2 なら hashCode(o1) == hashCode(o2) である必要がある。
      同一のものは必ず同じhash bucketに入る必要がある。
        hashを使って検索する際に同じhash bucket内しかチェックしないから。
    hashCode(o1) == hashCode(o2) でも o1 equals o2 である必要はない。
      同じhash bucketに複数の要素があっても良い。
        シノニムがあっても解決できると言う事。
    JavaでもequalsとhashCodeを合わせて再定義する様に要求している。
  Pitfall #3: Defining equals in terms of mutable fields
    hashCodeの生成ネタにはimmutableな値のみにする必要がある。
    mutableな値にするとhashSet等に格納後に値を変更した場合問題になる。
      fieldの更新によりhashCodeが変更になってもhash bucketの移動はされない。
      間違ったhash bucketに格納されている事になってしまう。
        contain等のmethodが正常に働かくなる。
    mutableな値を使って同一性判定をしたい場合はequals以外の名前のmethodを作る。
      例えばequalContentsとか。
      equalsとhashCodeはdefaultのobjectのidベースにしても良い。
      ==をこの意味では使えなくなってしまうが、ここはtrade off。
  Pitfall #4: Failing to define equals as an equivalence relation
    scala.Anyで定義されているequals methodは同値関係を満たす必要がある。
      反射律
        x.equals(x)が真。
      対称律
        x.equals(y)とy.equals(x)の真偽が一致する。
      推移律
        x.equals(y)が真かつy.equals(z)が真ならx.equals(z)も真。
    一貫性も必要。
       x.equals(y)の結果が何度呼び出しても同じである事。
          equalsの判定に使われる情報が変更されない限り。
    nullとの同等にならない事も必要。
      xがnon-nullならx.equals(null)は偽
    sub classとsuper classを混ぜてequalsで比較する場合が難しい。
      対称律、推移律を満たすのが難しい。
    sub classのequalsでsuper classには無いfieldも評価するか?
      評価する場合はsub classとsuper classは同一に出来ない。
      評価する場合はsub classとsuper classは同一にした方が便利。
    canEquals methodを使ってsub class側でどのsuper classと同一にするか決める。
      override def canEqual(other: Any) = other.isInstanceOf[super class]
      同一に出来る最上位のsuper classのinstanceなら真を返すようにする。
      super classとは同一に出来ない場合はsuper class=自分のclassとする。
    The Liskov Substitution Principle (LSP)
      superclass instance要求される所ではsub classのinstanceを使える様にすべき。
      sub classとsuper classは同一に出来ない事がLSP違反になるか?
        違反しないと解釈している。
          ?? 同一判定がfalseになっても使えない訳ではないから ??
          ?? 使える必要があっても全く同じ振る舞いをする事は要求されていない??
        ?? 違反すると言っている人たちもいる ??

28.3 Defining equality for parameterized types
  型パラメータを持つclassのequals methodを実装する場合。
    override def equals(other: Any) = other match {
      case that: Branch[_] => ... }
    override def canEqual(other: Any) = other.isInstanceOf[Branch[_]]
  型パラメータをwild cardにしてequalsやcanEqualを実装する必要ある。
    erasureによって実行時は型パラメータの情報は消去されている。
    pattern matchingやisInstanceOf等のrun-time型チェックには使えない。
  型パラメータが異なる場合はequalsはfalseを返すべき。
　  型パラメータチェックできなくても要素を比較した際にfalseになるはず。
    equalsの実装に要素の比較が含まれていれば問題ない。

28.4 Recipes for equals and hashCode
  equals
    super classでfinalになっていないならequalsのoverrideを検討すべき。
    non-final classではcanEqualの実装も検討すべき。
    引数の型はAnyにする。
    pattern matchingで自分の型と一致するかをチェックする。
    canEqualで比較可能かチェックする。
    super classのequalsをチェックする。
    追加したfieldが同一かチェックする。
    型が違い場合はfalseを返す。
  canEqual
    isInstanceOfで同一になりえる型かどうかをチェックする。
    通常は自分のclass
  hashCode
    JavaのhashCodeの生成方法と同じ。
    equalsで参照されているfieldを計算に含める。
    1番目のfieldのhashCodeを求めて41を足す。
    上記に41を掛けて2番目のfieldのhashCodeを足す。
    上記2行を全てのfield分繰り返す。
      override def hashCode: Int =
        41 * (41 * (41 + a.hashCode) + b.hashCode) + c.hashCode
    Int, Short, Byte, CharのhashCodeはそれ自身なので、hashCodeの呼び出しは不要。
    41は奇数の素数
      overflowによる情報ロスを最小にするためには奇数の素数を掛けた方が良い。
      最初の計算値が0になり難い様に41を足している。
        fieldの値が0である事よりも-41である事の方が少ないと仮定。
    super.hashCodeから計算を始めても良い。
    fieldがcollectionの場合もfieldのhashCodeを使えばよい。
      Arrayの場合はhashCodeに要素が取り入れられていないので注意が必要。
        Arrayの要素をhashのネタにしたい場合は要素を個別に扱う必要あり。
    hashCodeをcacheしても良い。
      immutableならdefではなくてvalでoverrideするだけでこれが出来る。
      cacheの分メモリ消費が増えるので注意。

28.5 Conclusion
  正しいequalsの実装は驚くほど難しい。
  case classとして実装すればcompilerが自動的に正しいequals等を実装してくれる。

Programming in Scala, First Edition: Chapter 27

27. Modular Programming Using Objects
  scalaの特徴の一つはプログラム小さくても大きくても同じ技が使えると言う事
  本章ではどうやって小さい部品から大きいプログラムを作成するかを解説する。
  packageとaccess modifierも有用だが抽象化出来ないという制約がある。
    同一のプログラマ内でpackageは再定義出来ない。
    package間で継承が使えない。
    コードを変更しないでpackageの内容を変更出来ない。
  scalaのOOP機能を使えば更にmodularに出来る。
    singleton objectをmoduleとして使う。
    traitやclassをmoduleとして使う。
    traitを使ってmoduleを複数のファイルに分割する。

27.1 The problem
  modularである事の利点
    別々にcompile可能になる事で複数チームで独立して作業できる。
    実装のある部分を取り外して別のものに置き換える事が出来る。
      開発の段階に合わせてテスト用のstub等から本番の環境に移行できる。
  modularであるために必要な事
    インタフェースと実装の分離。
    インタフェースや再コンパイル無にmoduleを交換可能な事。
    複数のmoduleを組み合わせる方法が用意されている事。
  dependency injectionを使えば上記は可能
    SpringやGuice等のframeworkで実現されている。
    Spring
      インタフェースをJavaのinterface、実装をJavaのclassに対応付けている。
      XMLの設定ファイルを使ってmoduleの依存関係の定義と結合を行う。
    scalaでもSpringを利用する事は出来る。
  scalaの言語機能その物を使った方法を本章で紹介する。
    objectをmoduleとして使う事でmodularityを外部framework無しで実現する。

27.2 A recipe application
  例として料理のレシピを管理するweb appを考える。
  domain layerとapplication layerで分離したい。
    domain layer
      ビジネスロジックの実装や外部のRDBへの保存。
    application layer
      UI layerやclientソフトに対するAPI提供。
  テスト様に各部品をmockと交換可能にした。
    交換可能部分をmodule化する。
  scalaなら大小に関わらず同じようにobjectを構成する事が出来る。
    scalaがscalable languageである所以。
  scalaではsingleton objectをmoduleとして使える。
    objectの中にinner classも定義可能。

27.3 Abstraction
  moduleとして扱うsingleton objectの一部をmockと置き換えて使いたい。
  abstract member, methodを使ったabstract classにすればよい。
    abstract class Database { ... }
    abstract class Browser { val database: Database ... }
  abstract classを継承することで一部を置き換えることが可能。
    object SimpleDatabase extends Database { ... }
    object SimpleBrowser extends Browser { val database = SimpleDatabase }
    object StudentDatabase extends Database {
    object StudentBrowser extends Browser { val database = StudentDatabase }

27.4 Splitting modules into traits
  singleton objectのmoduleが一つのファイルに入れるには大きすぎる場合。
    traitに分離してそれをextends, withで合成すれば良い。
  必ず合成されると分かっているtraitのmemberはself typeを使えば参照できる。
    trait SimpleRecipes {
      this: SimpleFoods =>
      object FruitSalad extends Recipe(
        "fruit salad",
        List(Apple, Pear),   // Now Pear is in scope
        "Mix it all together."
      )
      def allRecipes = List(FruitSalad)
    }
    SimpleFoodsのPearを参照出来る。
      this.Pearと解釈されて、thisがSimpleFoodsなので参照出来る。

27.5 Runtime linking
  mainメソッド内でsingleton objectをmoduleとして定義出来る。
    mainへの引数で別のobjectを生成すれば動的にmoduleの組み合わせを変えられる。
    新しいmoduleが加える場合でもmainのみを変更すれば良い。
  mainがconfiguration fileとして使える。
    SpringのXMLを使った定義よりもcompilerのチェックが使えるので強力。

27.6 Tracking module instances
  path-dependent typeを使う事でInner typeを別々のtypeとして扱う事が出来る。
    あるclassの組から複数のmoduleの組を生成する時に使える。
      moduleを特定の組み合わせに制限出来る。
  実質同じpath-dependent typeになっていてもif式等でコンパイラが追えない場合。
    singleton typeを指定する事で対応出来る。
  abstract class Database {
    case class Category(s: String, n: Int)
    val category: Category
  }
  abstract class Browser {
    val database: Database
    def print(category: database.Category) { println(category.s) }
  }
  object db1 extends Database { val category = Category("a", 1) }
  object db2 extends Database { val category = Category("b", 2) }
  def f(x: Int) {
    val db: Database = if (x == 1) db1 else db2
    object browser extends Browser { val database: db.type = db }
    browser.print(db.category)
  }
    dbとbrowser.databaseは同一だがif式があるのでコンパイラは追えない。
    database: db.typeでコンパイラにdatabaseがdbと同じtypeだと伝えられる。
      db.typeはobject dbに固有のsingleton type

27.7 Conclusion
  objectを使ってmoduleを定義する事でclassによる抽象化が可能になる。
  objectの生成は実行時に行われるので実行時に再コンパイル無でmodule構成可能。
    更に実行後にobjectの内容を書き換えればmoduleを再構成可能。
  モジュール化は大規模プログラミングの一部で試すのが難しい。
    どの様な違いが出るのか試すためには大規模プログラムが必要になるので。
  実際に大規模プログラムを読み書きする時に本章のテクニックを思い出せば良い。

Cメールに関するメモ

この前Cメールで電話番号を送ろうしたら送れなかった。。。
下記を調べてみると電話番号とURLは受信できない設定がデフォルトらしい。
また、同じ携帯会社間でしか送れないと思っていたのだが、SMSとして相互接続性もあるらしい。

http://www.au.kddi.com/mobile/service/mail/sms/
SMS (Cメール）安心ブロック機能で電話番号やURLの受信を拒否できる。(初期値は拒否)
SMS (Cメール) 本文メッセージで「有効」と入力 → 090-4444-0011へ送信
SMS (Cメール) 本文メッセージで「解除」と入力 → 090-4444-0010へ送信
SMS (Cメール) 本文メッセージで「確認」と入力 → 090-4444-0012へ送信
国内事業者や海外事業者のSMS (Cメール) も受信/ブロック可能(初期値は受信)

mamorino3のメモ

いちごを単身で北海道のおばあちゃんの家に行かせる事にしたので、連絡用にauのmamorino3を購入した。
結構色んな機能があって取説を見ても中々難しかった。
子供向けの説明は漫画仕立てになっていていちごも自分で読んで使い方を調べていた。
これもあまりわかりやすい書き方とは言えない気がするが、読みやすくはある。

電源OFF

• mamorinoでは子供は自分では電源が切れない!!
• 保護者機能からOFFする必要がある。
• ロック番号を入れる必要がある。
• 電源ボタンで出来るのは疑似電源OFF
• マナーモードの親戚で非常通知や留守電等が使える。
• !!飛行機に乗るときは親が電源を切る必要がある!!
• メールで保護者メニューを表示される機能があるので、ロック番号なしでも可能。

位置確認

移動経路通知

• メールから通知開始/終了が可能
• 防犯ブザーが鳴った時にも開始可能
• 決まった時間に通知する様にも出来る。
• 事前に通知先メールアドレスの設定が必要(mamorino側)
• 位置通知メールが親のメールアドレスに通知される
• URLを開くと位置がわかる。
• 一分毎に通知、5分毎に更新
• 一回で50円、一時間で500円。
• 2時間で自動停止。最大1000円
• !!通知終了を忘れたらパケット代が大量に!!
• EZwebの契約は必要

ココセコム

• 加入済
• 初期費用や月額費用は不要。
• ネットで月二回まで位置確認無料。その後は100円/回
• センタに電話は300円/回。
• 10桁の契約番号(申込番号)と4桁の暗証番号が必要。auの契約とは別なので注意。
• 防犯ブザーが鳴ったらセコムに連絡が行く。
• 親にも連絡が来る。
• 行かなくても良いと言う確認が取れないと現場に行ってしまう。
• 10,000円/回
• ??EZwebの契約は不要?? => Eメールアドレスの登録が必要なので多分必要
• http://www.cocosecom.com
• TEL: 0422-79-8803

安心ナビ

• 未加入
• 300円/月。親のau携帯の方で契約する。子供は無料。
• 位置確認は無料。
• 他にも色々とサービスがある。

ケータイ探せて安心サービス

• 元々は携帯を無くしたときに探すための機能。
• 防犯ブザーがなった場合との連動はなし。
• 月額利用料は無料。
• パソコンからの検索は100円/回
• センターに電話は300円/回
• マナーモードが設定されていても音がなるので注意。
• 利用者暗証番号
• 初期値は暗証番号と同じ。このサービス専用にも変更可能。

自動着信/ハンズフリー

• 両方ONにしておけば電話に出ない場合でも周辺の音を聞いたり呼びかけたり出来る
• 特定EメールCメールからON/OFF切り替え可能

特定EメールCメール

• ワンタッチ1-3に登録されているメールから
• 特定の文字列の件名のみのメールを送ると設定を変えられる
• 自動着信オン/オフ、ハンズフリーオン/オフ、通知開始/終了
• 保護者メニュー

遠隔マナー解除

• ワンタッチ1-3に登録されている電話番号から指定時間内に3回電話すると解除
• 初期設定は3分

Eメールアドレス

• Eメールの利用をOFFにしても移動経路通知は使える
• EZWebの契約は必要

暗証番号等

暗証番号

• Eメールアドレスなどの変更に必要な番号
• 初期値は申込書に書いた4桁の番号

ロック番号

• 本体の設定に必要な番号
• 初期値は1234

PIN1コード

• SIMカードを他の人に使われなくするための機能。
• 3回連続で間違えるとロックされる
• 初期値は入力不要で1234

PIN1解除コード

• SIMカードの裏面に印刷されている8桁の番号
• 変更できない。

Programming in Scala, First Edition: Chapter 26

26. Working with XML
  XMLの半構造化データについての一般的な議論
  scalaでXMLをどうやって扱うかの重要な部分の概要説明
    XMLリテラルを用いたノードの作成。
    XMLファイルの保存と読み込み。
    queryとpattern matchingを使ったノードの分離。

26.1 Semi-structured data
  XMLは半構造化された形式を取っている。
  ツリー構造になっていてplain textよりは構造化されている。
  プログラム言語のオブジェクトよりは構造化されていない。
    タグ間はフリーフォーマット。
    型システムもない。
  半構造化はプログラムでデータをシリアライズする時に非常に有用。
    ネットワーク経由で送信したり、ディスクに保存する場合。
    構造化されているデータ全てをバイナリにする代わりに使える。
      まずは半構造化フォーマットに変換する。
      その後に半構造化フォーマットに元々準備されているライブラリでバイナリにする。
  半構造化フォーマットは色々あるがInternetではXMLが一番一般的。
    ほとんどのOSのほとんどの言語にXMLライブラリが存在する。
    ネットワーク外部性により益々使われる様になっている。
    Internet経由でのやり取りをする場合はXMLを避けて通れない。
  scalaでもXMLの特別なサポートを行っている。
    本章で標準的なメソッドやpattern matchingによる処理を紹介。
    さらに良く使われるidiomも紹介する。

26.2 XML overview
  tagとtextで構成される。
    textは任意
    tagは<tag></tag>
  tagはstart<tag>とend</tag>があって対応付ける必要あり。省略はNG。
    <tag/>: startとendを合わせた表現
    <tag attr="3">: start tagには属性をつけられる

26.3 XML literals
  scalaではどこにでもXMLのリテラルを記載する事が出来る。
  単にstart tagで書き始めればend tagまでXMLリテラルと認識される。
    scala> <a>
             This is some XML.
             Here is a tag: <atag/>
           </a>
    res0: scala.xml.Elem = ...
  Type Elem: XML element
  Class Node: 全てのXML node classの上位の抽象クラス
  Class Text: testのみを保持しているXMLのnode。<a>stuff</a>の中の"stuff"
  Class NodeSeq: XML nodeのsequence
    XMLのライブラリはNodeSeqを処理する様に作られている。
    Nodeは単一NodeのみのNodeSeqとして定義されている。
      NodeSeqに対する処理は単一Nodeに対しても行える。
  XMLの内部にも{}を使ってscalaコードを埋め込める。
    scala> <a> {"hello"+", world"} </a>
    res1: scala.xml.Elem = <a> hello, world </a>
    任意のscalaコードを書けるので、その中に更にXMLを埋め込むことも可能。
    scalaコードの評価結果が埋め込まれてXMLになる。
      空のXMLを表現したい場合はxml.NodeSeq.Emptyを使う。
    評価結果がXML nodeでない場合は、stringに変換されてtextとして埋め込まれる。
    text中の<、>、&はURL encodeされる。
    XMLのtagと同様のstringをつあってもtextとして認識される。
      tagとして認識させたい場合はXMLリテラルかXMLのtype(型)を使う。

26.4 Serialization
  XMLリテラルとbraceによるscalaコードの埋め込みでシリアル化が出来る。
  下記がシリアル化(XML化)の例
    abstract class C {
      val s: String;
      val i: Int;
      def toXML =
       <c>
         <s>{s}</s>
         <i>{i}</i>
       </c>
    }
   下記の様に実行できる。
     scala> val c = new C {
              val s = "hoge"
              val i = 10
            }
     scala> c.toXML
     abstractクラスでもanonymous classを使ってnewできる。
   {}をtextとして使いたい場合は{{、}}を使う。

26.5 Taking XML apart
  多数あるXMLライブラリのメソッドの中で特に良く使うのは3つ。
    XMLを分解するためのメソッド。
    XPath言語に基づいている。
    外部ツールを呼び出すことなく直接scalaから使える。
  Extracting text
    textメソッドを使うと全要素のtext部分が一つのstringに連結されて抽出される。
      scala> <a>Sounds <tag/> good</a>.text
      res8: String = Sounds  good
    URL encodeされている場合は自動的にdecodeされる。
  Extracting sub-elements
    \"tag"メソッドを使うとタグが"tag"の子要素のNodeSeqが抽出される。
      scala> <a><b><c>hello</c></b></a> \"b"
      res10: scala.xml.NodeSeq = <b><c>hello</c></b>
    \\"tag"メソッドを使うとツリー全体を検索して(deep search)要素を取り出す。
      topレベル要素も含めて全体が検索される。
    \、\\はXPathの/、//に対応している。
      scalaでは/、//を別の意味で使うので\、\\とした。
  Extracting attributes
    \"@attr"、\\"@attr"で属性値のNodeSeqが取り出せる。

26.6 Deserialization
  textメソッドを使えばシリアル化してXMLにしたオブジェクトを逆シリアル化出来る。
    def fromXML(node: scala.xml.Node): C =
      new C {
        val s = (node \"s").text
        val i = (node \"i").text.toInt
      }
  ** 実際に定義する時はclass Cのcompanion objectに定義すると良さそう。

26.7 Loading and saving
  toStringを使うだけでもXMLをStringにすることは出来る。
  ライブラリの関数を使った方がより良い。
    encode情報等のdirectiveをつける事が出来るため。
  XML.saveFull(ファイル名, XMLノード, エンコード, エンコードフラグ, ドキュメントタイプ)
    scala.xml.XML.saveFull("therm1.xml", node, "UTF-8", true, null)
    エンコードフラグはencode declarationをつけるかどうか。
    ドキュメントタイプは説明省略。nullで未定義にしておくので良い。
  XML.loadFile(ファイル名)
    scala> val loadnode = xml.XML.loadFile("therm1.xml")

26.8 Pattern matching on XML
  XML pattern
    XMLリテラルと同様の形式。
    {}の内側はscalaのpattern matchingのパターンになる。
      変数束縛、型テスト、ワイルドカード(_、_*)
  (node :scala.xml.Node) match { case <a>{contents}</a> => ... }
    「single sub-node」のみmatchする。
    子要素が一つの場合。
      <a>hoge</a>にはmatchする。
    孫要素があってもOK.
      <a><b>hoge</b></a>にはmatchする。
    子要素が複数ならmatchしない。
      <a><b>hoge</b><b>fuga</b></a>にはmatchしない。
  (node :scala.xml.Node) match { case <a>{contents @ _*}</a> => contents }
    子要素が複数の場合は_*を使ってSeqとしてmatchさせる。
      <a><b>hoge</b><b>fuga</b></a>にはmatchする。
      Seq[scala.xml.Node] = ArrayBuffer(<b>hoge</b>, <b>fuga</b>)
  空白文字
    XMLリテラルを使うときに空白文字に注意する。
    タグ間の改行やタブ等もXMLのtextと要素として認識されるので注意が必要。
    下記だと<a>の子要素として<b>と<c>と</a>の前の改行+空白の3要素も存在する。
      <a>
        <b>hoge</b>
        <c>fuga</c>
      </a>

26.9 Conclusion
  scalaではXMLの特別なサポートとしてXMLリテラルがプログラムの何処でも使える。
  他にも沢山の拡張、ライブラリ、ツールがある。
    scala向けにカスタマイズされたもの
    Java向けだがsalaでもつかえるもの
    言語非依存のもの

Programming in Scala, First Edition: Chapter 25

25. Annotations
  ソースコードに付け加えられた構造を持った情報
  コメントと同じようにプログラム全体、変数、関数、式等の様々要素に付加できる。
  コメントと違うのは構造を持っている事。
    機械処理に向いている。
  この章ではAnnotationの使い方を扱う。
  新しいAnnotationの使い方はこの本の範囲外。
    Chapter 29では追加方法の一つを紹介する。

25.1 Why have annotations?
  コンパイルや実行以外でもプログラムに関係して行えることはある。
    Scaladocの様なドキュメントを自動生成する。
    好みのスタイルに合わせてコードを綺麗に印刷する。
    コードのエラーチェック
      例えばopenの後のclose忘れのチェック。
    試験的なtype checking
      例えば副作用の管理ややpropertiesの所有権の確認。
  meta-programming tool
    他のプログラムを入力として扱うtool
  Annotationによってこれらのtoolを効率的に実行できる。
  Annotationはコンパイルには使われない。コードの実行には影響しない。
  言語自体に各toolのためのAnnotationを組み込むのはtoolが多いので難しい。
    新しいtoolもどんどん出てくる可能性がある。
  scalaでは共通的な最低限必要な物はシステムAnnotationとして定義されている。
  個々のtoolに必要なAnnotationは独自に定義する事が出来る。

25.2 Syntax of annotations
  どの様な定義の宣言部分にも情報を付加できる。
    vals, vars, defs, classes, objects, traits, and types
  methodに情報を付加したいとき
    @deprecated def bigMistake() = //...
  classに情報を付加したいとき
    @deprecated class QuickAndDirty { ...
  expressionに情報を付加したいとき
    (e: @unchecked) match { ...
    typeとしてAnnotationが使われている場合と同様。
  引数を持つより複雑なAnnotationも定義出来る。
    @annot(exp_{1}, exp_{2}, ...)  {val name_{1}=const_{1}, ..., val name_{n}=const_{n}}
    annotは識別子。
    exp_{1} は必須引数。
      普通は定数が使われる。
      スコープ内の他の変数値を参照する事も出来る。
        @cool val normal = "Hello"
        @coolerThan(normal) val fonzy = "Heeyyy"
    name_{1}=const_{1} は順序も任意のオプション引数。
      右辺値は定数のみ。

25.3 Standard annotations
  Deprecation
    今後削除される予定等で使って欲しくないclassやmethodを示す。
    使用するとコンパイラが警告を出す。
  Volatile fields
    feildの不揮発性を示す。
    実装されているplatform(Java等)に依存した扱いをされる。
  Binary serialization
    シリアル化
      オブジェクトをバイトストリームに変換する機能。
      ストレージに保管したり、ネットワーク越しに別の場所に送ったりできる。
    scala自体にはシリアル化の機能は持っていない。
      実装されているplatform(Java等)のシリアル化の機能を使っている。Charter 29
    @serializable
      classがシリアル化可能であることを示す。
      defaultではシリアル化不可。
        普通のクラスは概ねシリアル化出来る。
        socketやGUIをhandleするようなクラスはシリアル化できない。
    @SerialVersionUID(ID)
      シリアル化した際に任意のIDを埋め込める。
      旧バージョンシリアル化されてオブジェクトと互換性が無い場合にチェックできる
    @transient
      fieldがシリアル化不要であることを示す。
      復元されたときはfieldのtypeのdefaultが入れられる。
  Automatic get and set methods
    @scala.reflect.BeanProperty
    fieldに付加するとcompilerがget/set methodをcompile時に自動生成する。
    compile後に有効になるので一緒にcompileされる部分からは使えない。
      一緒にcompileされるのはユーザのコードではなくて同一ライブラリのコード
      ライブライ内なら直接fieldにアクセスすれば良いので実際は問題にはならない。
    scalaではsetter/getterは普通は不要。
      fieldアクセスとmethod呼び出しを同一表記しているので。
    標準のget/set methodを期待しているframeworkのサポートを想定している。
  Unchecked
    (e: @unchecked) match { ... }
    pattern matchingで全パターンを網羅していない時のcompilerの警句抑制。
    Section 15.5

25.4 Conclusion
  platform依存しないAnnotationの使い方について説明した。
  Annotationは新しく定義するよりも使う場合の方が圧倒的に多い。
  scalaの標準Annotationの主だったものを説明。
  Chapter 29ではJava platform特有のAnnotationについて説明する。
    Java platformにしか使えないAnnotation
    Java platformで標準Annotationに追加される意味
    Java由来のAnnotationとの連携、使い方、定義、扱われ方

TOEIC(2014/7/28)当日

今回(月曜日の17時集合)の職場で受けたTOEIC IP当日に行った事。

前の日は早く寝ようと思っていたあまり寝れなくて、AM1時位に就寝。12時前には寝たかった。
この所頭が痛い日が続いていたが、当日はあまり痛くなかった。特に試験中は気にならなかった。

当日の朝にパンを二つ買って出社。
お昼に半個残して、テストの40分前に半個食べて脳にブドウ糖を補給。

試験前は天気も良くて、しかも涼しかったので会場まで10分弱歩くのが良い気分転換になった。

今回は前の日、当日ともずっと緊張していた。
多分前回の点数が良かったのでそこから下がるプレッシャーがあったのと、結構勉強をしたので勉強成果を出したいというプレッシャーがあったから。
テストが始まってから集中出来て緊張も感じなかった。

テストにはHBの鉛筆2本とシャープペン2本と消しゴム2個を持参。
HBの鉛筆2本を使ってマークした。

書き込みは一切行わずに、P3,4では答えがわかったら指で押さえて、聞き終わったらマークした。
P1のdirectionではP4を先読み。後ろから上段を4問分。
P2のdirectionではP3を先読み。後ろから上段を3問分。

問題は思ったより難しかった。韓国版？ でもP7の最初の問題は設問2問だった。韓国版なら3問のはず？

何時もは天井のスピーカを使っているのだが、今回はラジカセだった。
音が割れて高音成分が良く聞こえなかった気がする。
なのでリスニングは音が聞き取れない問題が少しあった。
公開試験ならこんな事はないのかも。

それと、先頭の2分遅れている壁時計を使うと言っていたのに、黒板に書かれた終了時間は正確な時間だった。
なので、最後に2分余ったと思ったらすぐに終わって危なかった。

P1が難しかった。3問位自信なし。
P2も難しかった。
P3,4は大体は分かった。先読みは全問順調に出来た。

P5は間違えないように少しじっくり解いたが、18分掛かってしまった。
頭から全部読んで答えが分かったところで次の問題へ。
選択肢は頭から読んでいる最中にチラ見することが多かった気がする。

P6は6分で終わった。
頭から全部読んで答えが分かったところで次の問題へ。
ただ、空欄から離れたところはかなり飛ばし読みのペースにした。
P5で時間を使って焦っていたので。

P7は49分。
シングルの最後の方の170問目位から時初めて、最後までやってからP7の先頭に戻って解いた。
基本的には最初に問題文を全部読んで、その後に設問、選択肢の順で頭から読んでいった。
ダブルは問題文をそんなに読み返さなくても出来た。
シングルの方が読み返してもよく分からない所があった。

直前までわからない所を飛ばして次に行く方法を使うか迷ったが、結局はやった順にすべてマークしていた。
結果的には時間がギリギリだったのでそれで良かった気がする。
残り2分でまとめてマークしようとしていたら、大変な事になっていた。

ちなみに公開テストは時計も時間のアナウンスもなくて、しかも腕時計以外はNGとの事。