Mitch Resnick: Let's teach kids to codeを見て

TEDのMitch Resnick: Let's teach kids to codeを見た。

子供にプログラミングを教える事の意義について。
昔同僚に教えてもらったMITで作っている言語"Scratch"の話だった。

Scratchはブロックイメージを使ってGUIでプログラム出来る。
新しいScratchではカメラや音声やセンサを使って仮想と現実を結び付ける機能に力を入れている。

現代の子供は"degital native"と呼ばれたりしているがITを使っているだけで作ってはいない。
読み書きと同じアナロジーで読むことだけではなく、書くことも学ぶべき。
書く事を学ぶことで新しい表現手段を手に入れる事が出来る。
皆がプロの物書きでない様に、プロのプログラマになる必要はない。
基礎的な書く能力としてScrachの様な簡単な言語を使えるレベルで良い。

Scrachの他にもプログラミングを初心者が学ぶ環境が増えている。
Codecademy, CodeDojo, Girls Who Code, Black Girls, etc...

プログラムの作成を通して、論理思考や段取りや協力の仕方などものづくりの基礎も学べる。

Scrachを教えるafter schoolで自作ゲームの点数表示の仕方が分からない生徒がいた。
生徒に変数の使い方を教えてあげたらとても「感謝」された。
先生が生徒に何かを教えて感謝されると言うのは学校の現場では少ないのでは?
ポイントは生徒に「これを実現したい」と言う強い動機があった事。
動機付けられていれば理解も深まる。

講演者の83歳の母親もScrachでプログラムを作れる様になったと言うのも凄い話。

英語は簡単で発音も聞き取り易かった。

Yves Morieux: As work gets more complex, 6 rules to simplify を見て

TEDの「Yves Morieux: As work gets more complex, 6 rules to simplify」を見た。

仕事が上手く行かない理由は複雑さにある。

複雑さに対して組織やプロセスを複雑化して対処すると余計に上手く行かない。
責任部署を増やしてメトリクスで管理するのでは上手く行かない。
現実を上手く表していないメトリクスを満たすために個々の部署がそれぞれ動く。
本質的な部分を外して部署間の連携が上手く行かなくなる。

簡単にすればもっと上手く行くようになる。

役割や肩書ではなくて他人が実際は何をやっているかを知る。
レイヤーを減らしてまとめ役を強化する。
ルールを減らして個々の判断の裁量を大きくする。
結果が実施者に直接返って来るようにして自分事として捉えられるようにする。
余分なリソースを持たせない様にして他人に頼むしかない状況にする。
失敗を責めずに、協力しなかったこと、協力を要請しなかったことを責める。

eclipseのJava補完設定

下記記事を参考にした。
http://ser1zw.hatenablog.com/entry/20110130/1296393620

補完表示トリガーの文字数を増やした
補完表示されるまでの時間を短くすることも出来るが、これはやっていない

式と値

式と値(特に関数値)の違いについて急に分かった気がする。

評価のタイミングや回数がどうなるかを色々考えている時にピンと来た。

式を評価すると値を返す
変数参照も式であり評価すると格納している値を返す
関数適用も式であり評価するとbodyの評価結果返された値を返す
定数も式であり評価すると定数値を返す

値そのものは評価出来ない
operandとしての機能しかない
opecodeと組み合わせないと評価できない => 式

関数値は関数適用と言う式を構成できる

(let ([x e]) (f x x))
eは一回しか評価されない
eが関数値を戻しても、xに対する変数参照が評価されるだけ
関数適用にはならない

thunk,stream,generatorの様に引数が無い関数値だと混乱しやすいので注意
変数参照なのか関数適用なのか

Windows 8.1 全画面表示でチャームや隠れているタスクバーが表示されない

Windows 8.1 で全画面表示でチャームや隠れているタスクバーがマウスを画面端に移動させても表示されなくなる場合がある。
特にEclipseを全画面表示しているときに発生しやすい。
動きとしては全画面表示のアプリケーションがデスクトップよりも前面に来てしまっている感じがする。

タスクマネージャーからエクスプローラを再起動すれば復旧するが、使い難い。。。

YouTubeにScreencastを初投稿

Courseraのandroid-002の課題でアプリ動作のScreencastの提出も推奨されていたので、YouTubeにScreencastを初投稿した。

PCのディスクトップの動画録画は下記のソフトで行った。

[AG-デスクトップレコーダー]
http://homepage2.nifty.com/t_ishii/ag/index.html
http://www.vector.co.jp/soft/winnt/art/se484960.html?ref=vec

[設定]
キャプチャレート: FPS
=> コマ数を減らすため。

モード: バッファリングエンコード
=> PCの処理負荷を減らすため

メインコーデック: WMV
=> 高画質にするため、品質指定、品質100にした
=> 音声は使わないので一番低レートを指定

入力オーディをデバイス: 使用しない
=> 今回は音声は使わないので

上記設定なら3分の動画で35Mbyte程度になった。

[YouTube]
アップロードにはGoogle+のアカウントいるらしい。元々googleにログインしていた状態だったので特に問題なし。

Google+アカウント設定で情報の公開範囲を「自分だけ」に設定
一括設定が見つからなかったので個別に手動で設定。
原因不明で未入力の情報の公開範囲が設定できなかったので後で情報入れる際には注意する。

YouTube右上のの「アップロード」ボタンから「限定公開」でアップロードしただけ。
限定公開とは言っても動画のURLを知っていれば誰でも見れてしまうので注意。

「マイチャネル->動画の管理」でアップロードした動画の一覧が出せる

動画を選んで、「詳細設定」からコメントや埋め込みの許可や言語を設定。
「アノテーション」から動画の説明を追加。
「動画加工ツール」で不要部分を削除。=> 反映されるのに時間が掛かるので注意。

プログラム言語上の概念の学習の効用

色々な課題を解決するのに共通して重要なのは問題を適切に分割すると言う事。
部分問題同士の関係をシンプルにして、ある部分問題の事を考えているときに別の部分問題の事を考えなくても良いように分割する。
全体を俯瞰的に考えると言う行為と、ある部分を詳細に考えると言う行為は、人の性質として同時には行えないような気がする。
したがって、この部分問題同士の関係が疎になる様に上手く分割することが重要となる。

ソフトウエアの設計は物理的な自由度が高いので色々な分割の方法が考えられる。
建築やハードウエアの設計よ様なより物理的なものと、数学や哲学の様なより観念的なものの中間にあたる。
ソフトウエアのメタな設計ノウハウは他の分野でも役立つし、他の分野のノウハウもソフトウエア設計に役立つ。

プログラム言語自体の設計もソフトエアの設計の一つなので、設計方針の好例として参考にする事が出来る。
アプリケーションよりドメインに依存しないソフトウエア設計上の共通的な一般化された問題を考えて設計されている。
さらに、多くのプログラム言語設計にも共通の概念が存在する。
これがより一般化された共通的なソフトウエア設計上の概念を表している。
したがって、複数のプログラム言語の共通の概念を学ぶことは、色々なソフトウエア設計に役立つ一般的な概念を学ぶことにつながる。

また、今後は一つの別となプログラム言語で全ての課題に対処するのではなく、課題の性質によって適切なプログラム言語を使い分けるやり方が主流になると考えられる。
プログラム言語の共通概念を学んでおけば、複数のプログラム言語を早く正確に習得できるようになる。

さらに、これは他人の設計を理解するのにも役立つ。
他人の書いたプログラムを理解する事が難しいのは、問題の分割の様な中間的な概念が存在しているから。
これを共通的な概念が使われていれば、それを理解している人同士では理解が容易になる。

Scroll lock

[excel]
カーソルキーでセルの移動が出来ずにスクロールする様になってしまた。
エクセルのフッター部分にscroll lockと表示されている。

キーボードのscroll lockをキーで解除出来る。

キーボードに無い場合はソフトキーボードを出して解除する。
=> アクセサリ->コンピュータの簡単操作->スクリーンキーボード->ScrLk

2014/10/15に見た夢

2014/10/15に見た夢をその日の朝にメモした内容。
中々ファンタジー系の夢で面白かった。

垂直の壁を登っていく、雲の上、天まで届いている。
壁は人工物の様に真っ平で、厚さは5m位、白っぽい色をしている。
幅は無限大でどこまであるか見えない。高さも非常に高くて、見下ろしても地上が見えない。

壁の片側には建築現場の足場の様な物が備え付けられている。上りやすくするため。
そこをジャンプしながら登っていく。上った後はその衝撃で足場が崩れていく
自分には大きな羽が生えている。ペガサスの様な感じの羽。
ただ、飛べる訳で無いみたいで、足場をジャンプしながら登っている。
てっぺんの少し前からは、手で上るべきという事になっているらしくて、そこで羽がとれる。
もう一人一緒に上っている人がいる。女の子。アダムとイブの様な感じ。
壁を乗り越えると天上界がある。神の世界。誰もいない。
霧が掛かっている様で灰色一色、地面は平らで灰色の砂と濃い緑の草と、所々白い粒の大きい砂の様なものが落ちている。見た目は合成肥料の様な。
そのうちに白い物は雪だと分かる。すると雪がゆっくり降っている事に気が付く。風もない。
海辺であることが分かる。でも波も無くて大きな水たまりのような浅い感じの水辺。
大きめの帆船の様な船が遠くに泊まっているのが見える。

大きなクラシックな洋館がある。2階建位。学校の施設の一部として使われている?
巨人も住んでいる所の様だ。部屋の扉のノブが頭の上の高さにある部屋がある。
部屋の中は個人の居室の様な狭い部屋。入るとドアがしまってロックされてしまう。
ロックが手の届かない高さにある。ジャンプして開けて外に出る。
出るとハウスキーパーの様な人が居る。恐ろしい所だとか言っている。
一回の踊り場の所で先生と合う。外国人の中年の男性。
勝手に色々なところに入らない様に注意された。

シーンは変わって、知らない街に居る。近代的な良くありそうなところだが、外国のような違和感がある。
無機質なところだから現実味に薄い?
バスやタクシーに乗るための、道ではない少し広いスペースの所に居る。
実家の駅の建て替え前のバス乗り場の感じに似ている?
そこから職場の人とタクシーに乗って何処かに向かおうとしている。
職場の人とは言っても知らない人だが。
クラシックカーのタクシーに乗りたいと言う話をしている。
一緒に乗っている一人が自分は結構クラシックカーのタクシーに乗っていると言い、
他の人が羨ましいねえとか言っている。

2014/10/8に見た夢

2014/10/8に見た夢を、その日の朝にメモしたキーワードをもとに2014/10/15の夜に内容を書いている。
あまり覚えていない。。。

[キーワード]
電話、開発依頼、隣の課長、聞こえなくなる

[内容]
会社にいる。といっても実際に通っている会社とは見た目は違う。
築20年くらいの研究施設の様な感じで、良く夢に出てくるところと感じは似ている。
大学の実験室の様なかんじがする所。
そこに電話が掛かっている、一緒にいるのは隣の部の課長。何時も一緒に仕事をしている人。
電話にでると新しい開発の依頼の電話の様だ。
何だろうと思って聞こうとすると、電話から何も聞こえなくなってしまう。。。

2014/10/7に見た夢

2014/10/7に見た夢を、その日の朝にメモしたキーワードを元に書いている。

[キーワード]
ラグビー、部活、OB、
本、個人出版、
研修所、建て替えたあと、部屋、外から入る、スリッパ、食堂、
その人が居なくなる、
海、潜水服、爆弾処理チーム、子供、気圧で無理、
チームで泳ぐ、潮が速くて流される、エース登場、
坂を滑り降りる、全身に黄色いオイル、スライダーの様な所

[内容]
ラグビーか何かの部活のOBの集まりで研修所の様な所に来ている。
さらにそこに本を自費出版しようとしている人も来ている。(これは新聞の連載小説の影響かもしれない。)
研修所は建て替えた直ぐ後の様で新しい。白のイメージ海のすぐそばに立っている。
その海の方から、庭から中に入る裏口の様な所から部屋の中に自費出版しようとしている人と一緒に入る。
そこから正面の玄関の傍の食堂の方へ向かう。
裏口から入るときにスリッパが必要な事に気が付くが、正面側の入り口の下駄箱に置いている事に気が付く。
その人が多分食堂の方にいって居なくなる。
その後海の方に出る。先ほど建物に入ったそばの海の中。結構深い。螺旋階段の様なものが海中に伸びている。
そこに潜水服を着て他のメンバと一緒にいる。爆弾処理のチームだ。
子どもは潜水服内の気圧が高いから一緒に活動するのは無理だと言うような話をしていた。
その後チームのみんなと一緒に泳いで現場に向かう。潮の流れが速くて上手く進めない。
そこにチームのエースが登場する。彼ならきっと上手くやってくれるに違いない。
海に向かて大きな坂がある。平らな坂で巨大なプールのすべり台の様な、スライダーの様な、横幅が広い坂。
その坂を全身に黄色いオイルを塗ったエースメンバが滑り降りていく。

2014/10/6に見た夢

2014/10/6に見た夢をその日の朝にメモした内容。

敵と味方に分かれている。
仕事の職場の人とか、部活関係の人とか、幼稚園の人とか沢山入り混じっている。
凄い破壊力がある爆弾が使われようとしている。
何か教団様な人達もいる。
円形のコロッシアムの様な、遊園地の自由に遊べる広場の様な、すり鉢状で真ん中に階段があって上に行ける遊具の様な所に向かう。
そこは敵の陣地で、誰かが中に侵入するのを助けようとしたりもしている。
敵の知り合いの人とも事情を話したりしている。
切迫感は無くて、レクリエーションのゲームをしているような雰囲気。
病院の様な所のベッドに寝ているシーンもあった。誰かをかくまっている。敵の病院中。自分は敵のメンバだが相手側に味方している?

emacs: 文字コード

;;; Windowsを使う際のデフォルトの文字コードの設定
(set-default-coding-systems 'cp932-dos)

::: ascii文字しか使っていない事の確認方法。
ファイルを読み込んだ時にus-ascii-dos or undecided-dosになっているはず。
mode-lineは-\--
us-ascii-dosに変更して保存しようとするとacii以外入っていると警告が出る。
警告に問題になっている文字へのリンクが張られている。
what-cursor-position (C-u C-x =)を使えばカーソルがある文字コードの情報が分る。

chrome tips

使っているextension
Gestures for Google Chrome
User-Agent Switcher for Chrome

extensionのデータの保存場所
C:\Users\[ユーザ名]\AppData\Local\Google\Chrome\User Data\Default\Local Storage\chrome-extension_[拡張機能のID]_[数字].localstorage
※IDは「拡張機能」のページ（chrome://extensions/）で [デベロッパー モード] をクリックすると一覧に追加表示されます

ユーザデータのバックアップ
C:\Users\[ユーザ名]\AppData\Local\Google\Chrome\User Data\Default

PDF readerからテキストをコピー出来ない場合あり
=> 単語の途中で改行されて-が入っている時。

ポジティブに学べるのは何故か?

自分は勉強好きでポジティブに学べる方だと自負しているが、その理由を自己分析してみた。

負の感情を抑えたい、制御したい
=>意識化、理性的、合理的な理由を探す
=>客観的、冷静、公平

自分の本質として、不器用で色々な事が上手くできなかったコンプレックスあり
自分はダメで人より劣っていると感じている
=>ダメであっても許されたい
=>他人のダメな所に寛容。ダメところがあるのは皆同じ。特別な人などいない。
=>自分も他人と同じく素晴らしいはず。
=>自分も他人も頑張れば出来る様になるはず。

失敗しても悪意があると思われたくない。
=>他人の失敗を悪意よりも状況、能力不足と判断。
=>能力はスキル、学習で改善できる。
=>自分も他人も頑張れば出来る様になるはず。

2014/10/5に見た夢

朝起きてすぐに夢の事を思い出してこのメモを書いている。

早寝したのでたくさん夢を見た気がする。

夢の中で明晰夢の時によくやるリアリティチェックをしていた。
それなのに夢の中だという事は気が付かなかった。

夜に一人で今住んでいるところの近くを歩いている。
何かをしようと思っていたが、それが出来なくなって当てが外れたので時間が潰せるようなことを探しているみたい。
何処かのお店に入って飲もうかとも思ったが、一人で入るのは気が引けるので迷っている。
結局駅に行って東京方面の電車に乗ることにした。
時計を見るとすでに夜の8時なので、このまま行くと直ぐに帰りの電車に乗る必要あると思う。
普段は腕時計をしていないのにここでは腕時計をしていた。
電車は近未来的な電車で新幹線の様な寝台車の様な電車。
乗ってしばらく走ってから、乗っていても無意味な事に気が付いて、慌てて途中の駅で電車を降りる。
柏位の地方都市の感じ?
駅から直結の地下街や駅ビルで何かしようと思って地下街への入り口を眺めても店が閉まっていたり、興味のある店がなかったりする。
駅のホームに戻ると、電車の車掌が自分が探している人が電車に乗っていると言ってくる。
電車が何かの都合で走らなくなってしまったので、泊まるところが無いから電車の寝台車両に泊まっていると言っている。
それで電車に入って会いに行っても良いと言っていた。

別のシーンでは山の中に家族と一緒にいる。親戚も一緒の気がする。
山は林の中で、林には葉が無くて葉が落ちた後の感じの灰色になっている。
外に立ってい話しているのだが、何処かに車で向かう話をしている。
ナビの様な電子的な画面を見ながら、ここなら通れるかも知れないとかいっている。

その後どうやって来たかは覚えていないが、山の中の古い古民家の様な所に来ている。
どうも古くからあるうどん屋さんの様だ。
そこで古くから伝わるうどんを食べさせてもらう。
カレー何とかといっていたが、全然カレーの味はしない。
コメを炊くようにゆっくりうどんを煮ているとかで、煮込みうどんの様にとてもやわらかい。
コメの代わりにするために具も入れていないと言っていた。
食べてみると伸びたうどんの感じだった。お腹の調子が悪いときには良いかもとか言っていた。

その後、その店を出ようとしたときに、
昔の着物を着た人か、妖怪か、幽霊かわからないけれど、狐が化けたような人が出てくる。
話していると、ジャンプして入り口の靴箱の上に飾られている達磨のようなずんぐりとした、でも歌舞伎の様なとても派手な人形、置物に変形した。
それで、来るときに置物だと思っていた物は生きていて、こちらの行動を始終監視していたという事に気が付く。
同じような置物がもういったいいて、これも生きている。

そこの店を出た後に親戚と一緒にアーケード街を抜けてタクシーに乗ろうと言っている。
皆の姿を見るとどうも法事の後だったようだ。
アーケード街の出口の所でタクシーに呼んで、たくさんいるので順次乗っている。
アーケード街を振り返ると、地面に生首の様に首から上だけを出した人が数人いる。
実際は地面に体が埋まっているだけらしい。
どうやって地面に入っのか聞くと、地面を柔らかくして体をめり込ませたと言っている。

マインドマップ

CourseraのProgramming Mobile Applications for Android Handheld Systemsのスライドを見ていて気が付いた事。

スライドの一枚目にあるマインドマップは概要を捉えるのに役立ちそう。
各pdfの一枚目に別々のマインドマップがついている。復習のも使えそう。
Chrome->印刷->PDFに保存で一枚目だけを保存できる。
人が作ったのを見るのではだめで、自分で作らないとダメな気がする。
マインドマップのお手本としても良いかもしれない。

革新的と保守的、バランスが大切

[革新的と保守的、バランスが大切]
人によっても異なるし、同じ人でも状況によってモードが変わる。
感情と逆方向のブレーキを理性で掛ける事でバランスを取る。
基本的に人は保守的なので、過剰な不安や恐怖を抑制して挑戦する事が大切。
逆に、目の前のリスクには敏感でも長期的なリスクは過小評価されるので注意。

2014/09/26に見た夢

2014/09/26に見た夢を2014/09/27の夕方にキーワードを見ながら思い出している。
忘れてしまいやすい夢でもキーワードをメモすればある程度は思い出せる。
忘れていると言うよりは思い出せなくなると言うのが正しい気がする。

[キーワード]
お腹が痛い、トイレ、公衆トイレ、何かの施設の、SAみたいな？、綺麗、和式が何故か多い、間違えたと思ったらまちがえていない、あんず。
キーボード、おじいちゃん、あんずのため、二つに分かれている、本体とキーボード、本体の裏にも一オクターブ位の鍵盤、高機能、小さい鍵盤もあり、自動伴奏、実際に音がなっていた、銀色のプラスチック、灰色のプラスチック、本体は四角い、綺麗な場所、家ではない、ジュータン、白い、プレイルームのような、家族しかいないが。
あるいている、集団で、これから戦闘がある？、少し行くと待ち伏せされているとしっている、前に通ったから、交差点、信号、実家の傍だと思っているが、実際はちがう、もう少し荒廃した感じ、明るい、青空？、中東の様な？

[内容]
横っ腹が痛い。右の下の方。
SAの様な何かの施設のトイレがある。大きな建物の一部で外から入るような公衆のトイレ。
建物の全貌は分らないが新しくて何処かのパビリオンの様な感じもする。
ちゃんと男女確認して入ったが間違えたか心配になって入り口で確認する。間違っていない。
何故か和式が多くて洋式が少ない設計になっている。
そこにあんずを連れて行って用を足させようとしている。

次のシーンは何処かの施設の屋内。
プレイループの様な少し広めの部屋の様な感じがする。
図書館の幼児向けコーナーの様に床が絨毯のようなものでおおわれている。
新しい。絨毯の色は少し濃い青色で、壁などは白色、部屋が白色の腰の高さ位の棚で区切らてている状態になっている。
父親がやってきて演奏に使うキーボードを置いて行った。
入り口で渡してそのまま外に出て行った。
四角い濃い灰色で外観はプラスチック製の感じがする。メカメカしい感じで色んな機能がありそう。
何故か鍵盤が裏面についていて、普通の大きさの鍵盤が一オクターブ分だけついている。
箱自体は大きめのノートパソコンを少し厚くしたくらいの大きさ。
そこに外付けのキーボードを接続した使える。
外付けのキーボードは普通の安めの子供が使うようなキーボード。
銀色のプラスチック製の筐体に青色の部品やスピーカーのカバーが付いている。
キーはミニ鍵盤で4オクターブ位はあるかもしれない。
さらに一段上の部分にさらに小さい一オクターブ位のキーが付いていて、そこで自動伴奏などの機能を使える。
どうもあんずがあそぶために父親が置いていったらしい。
実際に自動伴奏機能などを動かして音楽がなっていた。特に何か知っている曲では無かったが。

次はのシーンでは外を歩いている。中東を思わせるような、少し荒廃した感じがする。アメリカの様な感じもする。
空は晴れていて青い。立て物は白くて高い建物はない。広めの道路を歩いている。
舗装されている感じがしないが、土の上と言う訳でもなさそうだ。
車道も歩道も無くて、車も走っていない。20人位の若者と一緒に歩いている気がする。
ガラの悪い連中で、棒などを手に持っている。どうもこれから戦闘の様なものが行われるらしい。
何故かはわからないが今後待ち伏せされている事が自分には分っている。
昔見た映画を再び見ているような感覚で、すでに経験した事を追体験しているらしい。
歩いている場所も気がつかないうちに実家の側になっている。押しボタン式信号がある交差点に向かう橋の上あたりを歩いている。

マニュアル作成セミナー

[感想]
セミナーの進め方、内容共に良かった。
=> マニュアルだけではなくてドキュメント全般、さらにはソースコード記載にも応用できる。
各参加者から良いマニュアルのポイントとなると考えている事をヒアリング。
=> これによって、その組織のマニュアルに期待するところが見える。
セミナーの中で各自から問題点を上げる事で、問題の共有の場としても活用出来る。
マニュアルの設計にもPSP手法(計画、概念設計、見積もり、進捗追跡、レビュー)が使える。
マニュアルを作るための規格もマニュアル。
=> 同様の方法で改善できるはず。

[ポイント]
マニュアルに求められる目的を意識する事が大切。
どこに書いてあるのか分かりやすいと言う事も重要。
=> 目次から調べられるように、目次だけで概要が分かるようにする。
=> ページデザインを工夫して、ページの何処に何が書いてあるか分かりやすくする。
マニュアルにも訴求力が必要。
=> マニュアルを見てみようと思わせる何か。
運用しやすさも重要。
各文をなるべく前後の文脈に非依存にする。
=> 文単位での再利用が出来る。
一文一意。
箇条書きの活用。
主語と目的語を明確にする。
情報のまとまりに分かりやすい名前を付ける。
=> グルーピング
=> ソースコード関数名や変数名の命名と同じ。

2014/9/24に見た夢

2014/9/24に見た夢を朝メモした内容を見ながら夜に思い出しながら書いている。
それなりにストーリー性のある夢だった気もするが、キーワードをメモする時点で大分を忘れていた。

[キーワード]
タクシー、飲み会の帰り、会社の同僚、沢山の人、学生?
昔辞めた会社の同僚、仕事上の付き合いのある人、人形、
実家、自分の部屋、二階、
ベランダの様な所をよじ登る。白いコンクリートの様な壁、腕だけで上る、落ちそう。

[内容]
会社の同僚との飲み会の帰りの様な感じ。
一緒にタクシーに乗ろうと言っている。
タクシーに乗るために何処かの建物に向かっている。坂の上にある建物。
街中ではなくて、郊外の他にあまり建物が無い様な所。
その建物に入るために、階段を上っているが、学生の様な人が階段の段上に並んでいる。
それに一緒に並んで上に行くのを待っている。

実家の2階にいる。新しいたてかえた後の実家。
その2階の廊下から自分の部屋の戸が開いていて中が見えている。
昼前位の様だがブラインドが降りていて部屋の中は薄暗い。散らかっている。
特に人の姿は見えない。

次のシーンは全然知らない建物。2階位のあまり高くない所。
窓の外にのベランダの様な所。狭い。コンクリートの様な厚い白い壁で囲われている。
そこに下から素手で登ろうとしている。
途中までよじ登れるが、壁が厚くて上手く向こう側まで手が回らなくて上り難い。

また別のシーン。
どういう訳かわからないが別世界に来ているらしい。そんなに変わったところはないが。
何か建物の中にいる。昼だと思うが灰色。普通の家と言うよりも小さなビジネスビルの様な所？
一緒にいるのは仕事の取引先の人。仕事の話をしている訳では無さそうだが。
人かと思ったら精巧に出来た等身大の人形。キューピー人形の様な材質で出来ている。人と同じように歩いている。
どうもその人形が襲ってくることを恐れている様な感じがする。具体的に被害が有った訳ではなさそうだが。

Eleanor Longden: The voices in my headを見て

TEDのEleanor Longden: The voices in my headを見た。
英語が難しすぎて一回目に聞いたときはほとんど内容が分からなかった。
その後スクリプトを読んで何とか理解できた気がする。
分からない単語も30語位あった。

頭の中で自分の意思とは無関係に声が聞こえると言う人の話。
最初は自分の行動のナレーションの様な無害なものだった。
しかし、医者などに相談して声を悪と認識する様になるとより声が自分に対して攻撃的な発言をする様になった。
最終的には、声が自分が直視できないストレスの代弁者であると捉えて、声を受け入れて共存できるようになった。
International Hearing Voices Movement と言う活動、団体もあり、声が聞こえる人達を支援している。

Programming in Scala, First Edition: 読後感

Programming in Scala, First Editionのオンラインブックを一通り読み終えた。
700ページ相当の本で、半年の間、約100時間掛けて、5000行程度のメモも取りながら読んだ。

内容は多少古くて最新バージョンとの差分はあったが、非常に興味深く勉強になる内容だった。
一番はプログラム言語学者であるScalaの作成者が著者であるという事。
単なる使い方に留まらず、なぜ必要か、どういう思想に基づいているのかについても他の言語との比較も交えながら詳しく述べられている。
さらに設計上の妥協する必要があった部分や今後改善が必要と思われる部分についても書かれている。

メモを取りながら読むと言うのも時間は掛かるが理解を深めるには良いやり方だった。
自分の言葉で改めて書き直すことにより、自分の理解できていない部分の認識や、どう理解しているか考えをまとめることに役立った。

メモを頭から読み直して、最後まで読み終えた後の理解状況に合わせて推敲すべきではあるが、それはまたの機会に取っておくことにして、次のhaskellの勉強を開始する事にする。

2014/9/21に見た夢

2014/9/21に見た夢を2014/9/21の昼にキーワードを見ながら思い出している。
夜更かしをしたせいで睡眠時間が4時間半くらいだったので起きた時にすぐに夢の事を忘れてしまった。
でも布団でうとうとしている時に何か夢を見ていた気がすると思って思い出そうと色々考え見たら少し思い出した。
確か結構切迫感のある夢だった様な気がする。

[キーワード]
追いかけられている、
海、風が強い、渡れない。
エレベータ、二手に分かれる、ホテル、大学
Lビジュアル系、2階、食堂、コンサート、階段を降りる。

[夢の内容]
何かの理由で追われている。悪の組織か何か？
建物と言うか、遺跡と言うか歴史的なものを感じる何か大きな建物の渡り廊下のの様な所を走っている。
屋根や塀の様なものはあるけれど、窓がなくて開放的な廊下の様な所。
晴れていて空は青い。海の近くの岸壁の上にた立てられている。お城かお寺かそのような所。
石造りかもしれない。そこの途中での何故か海とつながっている部分に出る。
波の上を何らかの方法で渡ろうとしている様だが、風が強く潮の流れが速くて流されそうになる。

その後のシーン続きかもしれないが、もっと近代的な昭和的な大きな建造物の中にいる。
ホテルか、大学の中の様な感じ。敵と二手に分かれてどちらが早くつくのかを競っている。
エレベータに乗り込んで何処かにむかおうとしている。

次のシーンは、海辺の観光施設、一階がお土産屋さんで二階が食堂になっているような感じの建物の2階にいる。
食堂の場所を使ったコンサートの様なものが行われている。
机が片づけられて椅子が並べられている。人もそれなりにいるはずだが、そこは全然記憶にない。
白い窓が沢山ある見晴らしの良い作り。昼間で空は青くて気持ちのいい天気。
席の正面のステージ的なスペースに数人の男性が出てきて歌っている？
一人がビジュアル系の様な人で、それがデスノートのLらしい。観客からも凄い人気の様だ。
出演しているメンバはLも含めて敵の様で、自分はその空きに螺旋階段を下りて何処かに逃げようとしている。

2014/9/20に見た夢

2014/9/20に見た夢を2014/9/21にキーワードを見ながら思い出している。
それなりにストーリー性があった気がするがそこまでは思い出せない。

[キーワード]
会社、不具合、前辞めた後輩、帰らない、飲み会、2次会
広い部屋、自己紹介

[夢の内容]
会社にいる。会社でソフトウエアの開発をしている。
場所は研究室の様なパソコンが沢山おいてあるところ。
やぱり普段仕事をしている所とは違う所だが。
どうもソフトのバグを直そうとしているとこらしい。
後輩の一人がバグがあると言って騒いでいる。
そこに昔辞めた後輩が遊びに来ている。
バタバタしていてゴメンね、の様な事を言っている。
夜。室内だから実際はよく分からないが。
後輩がそろそろ帰ると思っていたが、やっぱり帰らなくても良いかといっている。
飲み会の2次会まで参加してから帰りたいと言っている。好きにしていいよと答えている。

その後、先のシーンの続きかどうかよく分からないが広い部屋にいる。
合宿所か研修所の研修室の様な広さ。
机などは置いてない。そこに２、３０人位の人が輪になって立っている。
男女同数位要る感じがする。大学のサークルの合宿の夜の様な感じで、皆ラフな服装をしている。
いる人達も知らない人たちだが、20代位の若い人の集まりの様な木がする。
そこでこれから自己紹介をすると言っている。その自己紹介について何か思う所あって話していた気がするが、何を話していたかは思い出せない。

Windows 8 のIMEで誤入力した予測入力を個別削除する

入力候補をTabで選択してCtrl+Delで個別に削除出来る。
http://snow-white.cocolog-nifty.com/first/2013/05/windows-8-ime-c.html

2014/9/19に見た夢

2014/9/19に見た夢を2014/9/20の夕方にキーワードを見ながら思い出している。

[キーワード]
ホテルの様なところ、中年の女性、有名人?
大学の先輩、空いている建物、ガラス張り、借り上げる?
駅、お金、十円や一円と小さなプラスチックの灰色のトークン?

[夢の内容]
ホテルの宴会場の様な所の会場の出入り口付近の廊下にいる。結婚式場のような感じ。
そこに中年の女性が関係者５，６人と一緒に話しながら歩いている。
その女性は有名人なのか地位のある人なのかグループの中心で周りの人が気を使っている感じ。

その建物を出て外を歩いている。大学の時に世話になった先輩と二人で歩いている。
地方都市の商店街の様な所。早朝で人気が無い。飲み会で徹夜明けなのかもしれない。
そらは灰色。3階建てくらいのテナントが入れるようなビルがある。
道に面した全面がガラス張りの中が見えるタイプ。
ガラスは少し局面を帯びている。
右側に3階まであがる階段も見える。
中は空っぽで全部開いている様だ。
先輩が部屋を探していると言っていたので、ここはどうだろうと話している。
全部貸し切ればちょうどいいかもしれないとか。

そのまま歩いて電車の駅の様な所に入った。
かなりだだっ広い。朝の活気があり人がたくさん歩いている。
先輩はいつの間にか居なくなっていて、一人でいる。
駅の中のお店に用があるようだ。床屋か喫茶店か何か。
だだっ広い駅中に５０ｃｍ位一弾床が高くなった所に、壁も仕切りも無い状態で存在している。
アイランドキッチンの様にそこだけ浮かび上がっている。
行きつけの店の様で、女性の店員に話しかけられる。どうも付けの支払いをしてくれと言われているらしい。
伝票と既に支払った分のお金が入った封筒を手渡される。
それを4人掛け位の普通のテーブルにおいて中身を出すと、十円玉や一円玉が数十枚入っている。
その他に灰色の一円玉の半分くらいの系のチップの様な、トークンの様なものも入っている。
これもお金の代わりに使えそうな感じがする。
ジャラジャラとお金を机に広げていると、向かいに座って同じような事をやっている人の小銭と混ざりそうになって困っている。

2014/9/17に見た夢

2014/9/17に見た夢について2014/9/20の夕方にキーワードを見ながら思い出している。
一部キーワードについては全然思い出せない。
他のキーワードも3シーンを断片的に覚えている感じ。
夢についてメモを取る様にしてから、よく言われるように夢の内容を覚えている事が多くなった気がする。
そのぶん、特に印象的でもない夢を覚えている事も多くなったので、だんだん書くのが億劫に。。。
うーん、特に印象的なものやリアルなものだけを書くことにした方がいい気もするが。。。

[キーワード]
会社、会社帰り、駐車場
外、細い路地、電柱
会社、合宿、電話会議、HTTP
デパート、ズボン、学生、家族

[夢の内容]
会社にいる。会社の外にいる。会社の駐車場が見えている。
みんなが会社から帰る時間。郊外にあるハイテク機器開発をしていそうな会社。
敷地も広そうで周りには多少緑もありそうな所。他に建物や家はなさそうなかんじがする。
そこの駐車場から誰かが車で買えるのが見えている。軽自動車か小型車。

次のシーンは意味はよく分からないが、細い路地が見えている。
住宅街の塀の間の細い路地。本当に細くて幅が1m位しかない感じがする。
そこに電柱が右左交互に建っていて、見通せない状態になっている。
そこをどうにか潜り抜けようとしているらしい。

次のシーンはデパートの紳士服売り場の様な所にいる。
ズボンを試着室で試着している。ベージュに薄い大きなガラが入っている。ガラというか牛の模様みたいな感じ。
「こんなの買う人いるのかあ」と思っていると店員が黒いズボンを持ってくる。
学生ズボン。自分はもう社会人なのに学生に見えたのかなあ思う。
試着して裾上げの長さなども計ってしまったが、家族にもう行くと呼ばれる。
何も買わないで手間だけかけて申し訳ないと思いながらそこを離れる。

emacs keybord macro counter

#emacs keybord macro counterがある。これでインクリメンタル数値も入れられる。
https://www.gnu.org/software/emacs/manual/html_node/emacs/Keyboard-Macro-Counter.html


In a keyboard macro definition, insert the keyboard macro counter value in the buffer (kmacro-start-macro-or-insert-counter).

C-x C-k C-i
Insert the keyboard macro counter value in the buffer (kmacro-insert-counter).

C-x C-k C-c
Set the keyboard macro counter (kmacro-set-counter).

C-x C-k C-a
Add the prefix arg to the keyboard macro counter (kmacro-add-counter).

C-x C-k C-f
Specify the format for inserting the keyboard macro counter (kmacro-set-format).

Learn You a Haskell: Table of contents

[Learn You a Haskell for Great Good!]
http://learnyouahaskell.com/

著者: Miran Lipovaca
ライセンス: creative commons license

「Learn You a Haskell for Great Good!」を読んで思った事をメモしておく。
翻訳や解説を目的とするものではなく、個人的なメモ。

Table of contents
1. Introduction (1)
1.1 About this tutorial (2)
1.2 So what's Haskell? (3)
1.3 What you need to dive in (4)
2. Starting Out (5)
2.1 Ready, set, go! (6)
2.2 Baby's first functions (7)
2.3 An intro to lists (8)
2.4 Texas ranges (9)
2.5 I'm a list comprehension (10)
2.6 Tuples (11)
3. Types and Typeclasses (12)
3.1 Believe the type (13)
3.2 Type variables (14)
3.3 Typeclasses 101 (15)
4. Syntax in Functions (16)
4.1 Pattern matching (17)
4.2 Guards, guards! (18)
4.3 Where!? (19)
4.4 Let it be (20)
4.5 Case expressions (21)
5. Recursion (22)
5.1 Hello recursion! (23)
5.2 Maximum awesome (24)
5.3 A few more recursive functions (25)
5.4 Quick, sort! (26)
5.5 Thinking recursively (27)
6. Higher Order Functions (28)
6.1 Curried functions (29)
6.2 Some higher-orderism is in order (30)
6.3 Maps and filters (31)
6.4 Lambdas (32)
6.5 Only folds and horses (33)
6.6 Function application with $ (34)
6.7 Function composition (35)
7. Modules (36)
7.1 Loading modules (37)
7.2 Data.List (38)
7.3 Data.Char (39)
7.4 Data.Map (40)
7.5 Data.Set (41)
7.6 Making our own modules (42)
8. Making Our Own Types and Typeclasses (43)
8.1 Algebraic data types intro (44)
8.2 Record syntax (45)
8.3 Type parameters (46)
8.4 Derived instances (47)
8.5 Type synonyms (48)
8.6 Recursive data structures (49)
8.7 Typeclasses 102 (50)
8.8 A yes-no typeclass (51)
8.9 The Functor typeclass (52)
8.10 Kinds and some type-foo (53)
9. Input and Output (54)
9.1 Hello, world! (55)
9.2 Files and streams (56)
9.3 Command line arguments (57)
9.4 Randomness (58)
9.5 Bytestrings (59)
9.6 Exceptions (60)
10. Functionally Solving Problems (61)
10.1 Reverse Polish notation calculator (62)
10.2 Heathrow to London (63)
11. Functors, Applicative Functors and Monoids (64)
11.1 Functors redux (65)
11.2 Applicative functors (66)
11.3 The newtype keyword (67)
11.4 Monoids (68)
12. A Fistful of Monads (69)
12.1 Getting our feet wet with Maybe (70)
12.2 The Monad type class (71)
12.3 Walk the line (72)
12.4 do notation (73)
12.5 The list monad (74)
12.6 Monad laws (75)
13. For a Few Monads More (76)
13.1 Writer? I hardly know her! (77)
13.2 Reader? Ugh, not this joke again. (78)
13.3 Tasteful stateful computations (79)
13.4 Error error on the wall (80)
13.5 Some useful monadic functions (81)
13.6 Making monads (82)
14. Zippers (83)
14.1 Taking a walk (84)
14.2 A trail of breadcrumbs (85)
14.3 Focusing on lists (86)
14.4 A very simple file system (87)
14.5 Watch your step (88)

Programming in Scala, First Edition: Appendix A

Appendix A Scala scripts on Unix and Windows
  Unixのshell環境でshell scriptとしてscala scriptを実施する方法。
    Scalaのスクリプトを下記の様に記載する。
      #!/bin/sh
      exec scala "$0" "$@"
      !#
      // Say hello to the first argument
      println("Hello, "+ args(0) +"!")
    実行権限を与える。
      $ chmod +x helloarg
    shell scriptと同様に実行できる。
      $ ./helloarg globe
  Dosのコマンド環境でバッチファイルとしてscala scriptを実施する方法。
    ファイル名をhelloarg.batとする。
    ファイルの先頭に下記を記載した後にscalaのscriptを記載する。
      ::#!
      @echo off
      call scala %0 %*
      goto :eof
      ::!#

予言の自己成就

オイコノミアでやっていたことで「予言の自己成就」と言うのがあった。

特に合理的な根拠が無くても「こうなるはずだ」と予言する事によって、そうなった場合に備えるように人が行動を変えてしまう事で予言した状態になってしまう事。
例えば「この子は将来学者になれる」と予言されて、それなら勉強させようと親が思って勉強できるような環境に子供を置くことで本当に学者になってしまうと言うような事。
もしくは、「この特徴を持った人は会社を直ぐにやめてしまう」と予言されて、「すぐやめるならその特徴を持った人には重要な仕事は任せられない」と周りが考えて行動してしまうと、本人もやりがいが無くなって本当に直ぐにやめてしまうと言うような事。

似たような話に「統計的差別」と言うのもある。
これはあるグループにある傾向を持つ人が多い場合、その傾向を持たない人がいるにも関わらず全員にその傾向があるものとして扱われてしまう事。

「願いを言い続ければ何時かは叶う」と言うのも自己暗示的な要素意外に予言の自己成就的な要素もあるのかもしれない。

O'Reilly Head First Series

O'Reilly Head First Series
http://www.headfirstlabs.com/readme.php
脳の特性を考えた学習に適した本のシリーズ。コンセプトが面白い。

脳に「これは重要な情報だと」思わせる必要がある。

同じことを何度も繰り返す。
絵を使う。
会話形式を使う。
演習問題を解いて手を動かす。
感覚を刺激する表現を使う。笑い、驚き、面白さ。
複数の手段で学ぶ。
左右の脳両方を使う。
ストーリーを示す。
質問を出す。
物ではなくて人々を使う。

学習自体についても学ぶ必要がある。

TOCfE

TOCfE(Theory of Constrain for Education)と言う物があるらしい。
ザ・ゴールのTOCによる問題解決思考?
TOCと言えばプロジェクト管理のCCPMだけかと思っていたが、色々とあるらしい。
制約(対立関係)に着目すると言う基本原則は同じ。
ロジックブランチ、クラウド、アンビシャスターゲットツリーと言うツールを使う。
解決方法は簡単には出ないが、障害なら出しやすいので先に障害をまとめる。
その後に、各障害に対する一歩前進した中間目標とそのための行動を考える。

2014/9/16に見た夢

2014/9/16に見た夢を2014/9/16の深夜にキーワード見ながら書いてる。
キーワードは起きた後に直ぐに書いた。
昨夜は11時頃に早寝して6時半位まで睡眠時間が取れたので、結構夢の内容を覚えていた。
また、夢の中で一時的に夢であることを認識していたが、その後またその事を忘れてしまった気がする。

[キーワード]
仕事で開発している装置、バスの様な所のなか、新しいソフト、問題発生、でもハードが古かった、新しいハードを探しにいく。
仕事、トラブルの対応、お客さんと外を歩いている、東京、灰色、建物に入る、仮想世界への爆弾、黒い、巨大かぼちゃ大、機械的
人がたくさんいる場所、宿泊施設、雑魚寝、女性率高い、高校の時の友人、さらにへやの置く、自分の場所?
屋外の風呂、マンションのベランダの様な、都会、コンクリート打ちっぱなし、二つに分かれている、足湯が出来そう。
二人の小さい人が向かい側に現れる。これは夢だと気が付く。が、すぐに夢であることを忘れる。針金のような武器。
捕まっている。守るべき誰かと一緒にいる。連行されている。乗り物にのる。空飛ぶ簡易的な乗り物。
他の犯罪者と一緒。２階位の高さ。商店街の様な狭い道の２階位の高さを飛んでいる。
吹き矢の様なものを拭いてみるように言われる、職場の同僚が吹く、弾が飛び出して何処かで爆発。
その反撃に空飛ぶ機会に載った誰かが攻めてくる。一機だけ

[夢の内容]
バスの中にいる。バスは止まっているような気がする。普通の昼間。灰色。職場の人数人と一緒にいる。
仕事で開発している装置がバスの一番前の所に設置してある。本来はバスに載せるような装置ではないのだが。
装置が上手く動作していない。未接続のコネクタ部分に接続を示すLED表示が出ている。明らかな不具合。
新しいソフトを載せたための問題と考え調べているところで、同僚の一人がハードウエアが試作品だったので壊れているかも知れないと言い出す。
それなら早く行ってくれよ〜、と思う。その同僚にはよくそういう事で困らせられた事があった。

その後シーンは変わって街の中を５，６人で歩いている。灰色。秋葉原の様な込み入った感じの所で人も沢山いそう。
一緒に歩いているのは知らない人たちだが、仕事のお客さんらしい。トラブル対応の最中らしい。
ある建物に入っていく。どんな建物かよく分からないが、東京の電車の高架部分と一体化しているビルの一階の様な感じ。
あまり新しい感じはしない。雑然としている。

そこではコンピュータゲームの中の様な仮想世界への攻撃をしようとしている。
黒い巨大かぼちゃ大の爆弾。黒いベースに銀色の部品が付いている。超合金の様な機械的な感じがする。
仮想世界への攻撃なら電子データのはずなのに、物理的な物体を使おうとしていることに違和感を感じている。
入り口付近の爆弾が置いてあるところからおっくに進むと、フェリーの2等船室の雑魚寝部屋の様な所に出る。
人がたくさんいて雑魚寝している。その中に高校の頃の男の友人も寝ていたが、何故か彼の周りは女性率が高いので不思議に思っている。

さらに自分の座る場所を探してなのか部屋の奥に進んで行く。
部屋の窓の外に出る。コンクリートの打ちっぱなしになっていて縦に細長いベランダの様な感じ。高さは2階位。
そこにお湯が溜めれるようになっている。二つの部分に分かれていて、小さい方にお湯をためると足湯に丁度いいと思ったりしている。
大きい方の奥の壁の四角所に二人の小さい人が現れる。体長1m位。膝を抱えて裸で正方形の部分にハマっている感じ。
ここでこれは夢なんだと認識したが、すぐにその事を忘れてしまう。二人は神様か守護霊らしい。
自分のこの後の戦いに協力してくれるらしい。針金のようなものを使った攻撃で協力してくれるらしいが、それだと自分にも絡まって危ないなあ、と思う。

その後建物から外に出ることになる。
建物入り口が2階位の高さにあって、そこから四角くて細長い屋根もない簡易なゴンドラ風の乗り物に乗り込む。
空飛ぶゴンドラ。どうも捕まったらしくて、犯罪者数人がすでにゴンドラに乗っていた。
ハリウッドのSFアクション映画の様なシーン。
子供か誰か守る必要がある人と一緒に乗った。前の隅の方で犯罪者と関わらない様にしている。
飛んでいる所は商店街の歩行者天国の様な雑多な所の2階位の高さを飛んでいる。
そのうち乗っている人の一人が長い吹き矢の様な筒が4本くらい平行についている武器を出して試しに拭いてみろと言っている。
職場の同僚がゴンドラの中央付近に乗っていて、その武器を拭いてしまった。
弾の様なものが後方に飛び出して弧を描いて少し離れた場所に着弾して爆発する。
不味い、攻撃する意思はな無いのに。。。
その攻撃に対する反撃をするために小型の飛行機械にのった敵がゴンドラに向かって来る。一機のみ。正面から。
人より大分小さい何かが載っている。ゲームのキャラクターの様な感じ。
飛行機械自体も人一人分くらいの大きさ。機体全体が銃の様な形をしている。
ゴンドラの正面のすぐ近くでホバリングして、照準を合わせている。

Programming in Scala, First Edition: Chapter 32

32. GUI Programming
  ScalaのGUIの開発にJavaのSwingベースのframeworkを使う。
  複雑さを隠ぺいしているので簡単に使う事が出来る。
  Scalaで単純化した後でも沢山の機能がある。
    Eclipseの様なIDEを利用して作るのが良い。
  良く知らないライブラリを最初に使うのにはIDEは向いている。
    どの様なmethodやclassやobjectが使えるかなどを補完できる。
  ** ScalaのSwingのサポートは終わって、今後はJavaFXベースのscalafxに移行する??

32.1 A first Swing application
  簡単なScalaのGUI
    // Swingを使う場合のimport
    import scala.swing._
    // SimpleGUIApplicationをextendsする。
    //   コマンドラインアプリケーションではscala.Applicationをextendsしていた。
    // main methodやswingを使うための事前設定が行われる。
    object FirstSwingApp extends SimpleGUIApplication {
      // top leveのGUI部品を定義する。
      //   通常は任意のデータを格納できるFrame
      // mainから呼び出されて処理される。
      // MainFrameが閉じられるとアプリケーションも終了する。
      def top = new MainFrame {
        // title等はpropertyとしてモデル化されている。getter、setterがある。
        //   def title: String
        //   def title_=(s: String)
        title = "First Swing App"
        // Containerで他の(複数の)部品を格納できる。
        //   Seq[Component]をsetterのcontents_=で設定する。
        // frameもContainerの一種だが一つの部品だけを格納できる。
        contents = new Button {
          text = "Click me"
        }
      }
    }

32.2 Panels and layouts
  複数の部品を持つGUI
    import scala.swing._
    object SecondSwingApp extends SimpleGUIApplication {
      def top = new MainFrame {
        title = "Second Swing App"
        val button = new Button {
          text = "Click me"
        }
        val label = new Label {
          text = "No button clicks registered"
        }
        contents = new BoxPanel(Orientation.Vertical) {
          contents += button
          contents += label
          border = Swing.EmptyBorder(30, 30, 10, 30)
        }
      }
    }
  Frameは一つしか部品を持てないので、複数部品を持てるPanelを使う。
    Panelの部品のレイアウトによって色々なsubclassが用意されている。
      適切なレイアウトを選択するのはGUIでは最も難しい事の一つ。
        どんな大きさでも上手く使える様にするのが難しいから。
    BoxPanelは単に部品を並べるだけのシンプルなレイアウト。
      contentsはbufferになっていて+=演算子で部品を追加できる。
    部品に枠をつけるborderもSwing.EmptyBorderで四辺の太さを指定する。
      枠線もobjectで指定する。
  Labelは編集できないテキスト表示様の部品。
  GUIの基本構成
    部品のclassから部品を生成して他の部品のcontentsに設定する。
    top frameをrootにする木構造になる。

32.3 Handling events
  ScalaではJavaと同様に"publish/subscribe"アプローチを使っている。
    publisherがeventを発生させてsubscriberが受け取る。
    publisherのインスタンスはevent source
    subscriberのインスタンスはevent listener
  listenTo(source)を使ってeventをsubscribeする。
  deafTo(source)を使ってeventをunsubscribeする。
  eventを受けてからの処理の仕方はScalaはJavaより大分簡単。
    Javaではlistenerのnotifyメソッドが呼び出されるのみ。
    notifyメソッドは間違いやすくて手間のかかる処理。
    このせいでコードが書きにくくなっている。
  Scalaではeventはcase classとしてlistenerに渡される。
    case class ButtonClicked(source: Button)
  全てのeventはscala.swing.eventで定義されている。
  reactionsプロパティにPartialFunctionを追加する事でeventをハンドル出来る。
    var nClicks = 0
    reactions += {
      case ButtonClicked(b) =>
        nClicks += 1
        label.text = "Number of button clicks: "+ nClicks
    }
  reactionsはstack的に登録の逆順でhandlerを適用する。
  -= 演算子でhandlerを削除する事も出来る。
  ?? あるhandlerにmatchしても次のhandlerにも渡ってしまう ??
  ?? 複数のobjectで共通のsourceをsubscribeした時も登録の逆順 ??

32.4 Example: Celsius/Fahrenheit converter
  Celsius/Fahrenheitの温度変換GUIアプリケーション
    // scala._パッケージはimport済なので、scala.は省略できる。
    import swing._
    // scala.swing._パッケージをimportしたので、scala.swingは省略できる。
    import event._
    object TempConverter extends SimpleGUIApplication {
      def top = new MainFrame {
        title = "Celsius/Fahrenheit Converter"
        // 一行の編集可能なTextField
        object celsius extends TextField { columns = 5 }
        object fahrenheit extends TextField { columns = 5 }
        // ウインドウの幅に応じて左上から右下に部品を自動配置するPanel
        contents = new FlowPanel {
          contents += celsius
          contents += new Label(" Celsius  =  ")
          contents += fahrenheit
          contents += new Label(" Fahrenheit")
          border = Swing.EmptyBorder(15, 10, 10, 10)
        }
        listenTo(celsius, fahrenheit)
        reactions += {
          // back tick``は必要。
          // fahrenheitだと任意のオブジェクトとmatchして変数fahrenheitにbind。
          // `fahrenheit`だとobject fahrenheitにのみmatch。
          // object Fahrenheitとして定義すれば変数にはならないので個別にmatch。
          case EditDone(`fahrenheit`) =>
            val f = fahrenheit.text.toInt
            val c = (f - 32) * 5 / 9
            celsius.text = c.toString
          case EditDone(`celsius`) =>
            val c = celsius.text.toInt
            val f = c * 9 / 5 + 32
            fahrenheit.text = f.toString
        }
      }
    }

32.5 Conclusion
  Scalaの機能でJavaのSwingをシンプルで統一的に出来ている。
  propertyのエミュレーションと演算子のoverload
    propertyの定義が簡単になる。
    += でpropertyを割り当てる事が出来る。
  「全てはオブジェクト」の思想
    GUIアプリケーションのmainメソッドも継承出来る。
    つまらないセットアップ処理などを隠ぺいできる。
  first-class functions and pattern matching
    イベントハンドリングをreaction component propertyとして簡単に扱える。

2014/6/10-2014/9/14の良かったこと

良かったことは#3goodでtwitterに書いているのでブログには載せる必要ない気がするが、消すのが何となく勿体ないので。
twitterにしか書いていないものもあるのでちょっと中途半端だが。。。

==== 2014/6/10 ====
昨日まで雨だったが、出張の今日は天気が良くてよかった。帰りも駅から歩いて帰ってきた。
バスで初めてSuicaを使えた!!

==== 2014/6/11 ====
#Coursera #posa-002 Week 2 Results 無事に満点で完了!!

==== 2014/6/16 ====
#scala 3週間ぶりにProgramming in Scala, First Edition精読を再開!
#Coursera #posa-002 4th virtual office hourを見た。onlineでも一緒に同じ講義受けているというの刺激が有って良い。

==== 2014/6/20 ====
#codecademy の #jQuery のspriteを動かす課題が面白かった。確かに簡単に動きのあるページが作れそう。
いちごがテストの時に見直しをして２問直せたと言っていた!!

==== 2014/6/21 ====
#codecademy jQuery Eventsバッジ獲得!!
子供たちと児童館で人生初一輪車挑戦。片手捕まりで漕げるようになった!!
畑の学校でジャガイモの収穫。早速食べておいしかった。スイカの試食もあった!!

==== 2014/6/22 ====
アマゾンインスタントビデオストアのクーポンで見た「イブの時間」が面白かった！！思ったよりあまり作品が登録されていないみたいだった。
車エアコンが効かなくなったので近所のディーラーに持っていった。リレーの接点が焼けてたとの事でその場で修理出来た!!
「かんたんかけいぼ」のプレゼン原稿を読んだが中々良く出来ていて面白かった。ゲーミフィケーションのオンボーディングに通じるものがある。

==== 2014/6/23 ====
手塚治虫のブッダの映画版を見た。うーん、そんなに面白くなかったような。。。クーポンの消化なので良しとしよう!!
#TOEIC 久々に新しい問題集「新TOEIC TEST 900点特急 パート5&a6」を注文した!!

==== 2014/6/28 ====
朝ゆっくり寝られた。
今日は過ごしやすい気温だった。
扇風機の気流で風船を浮かせるミニ実験が大成功。子供たちが大喜び。
あんずといちごとお散歩がてら近くのスーパに昼ごはんの冷凍ピザを買いに行った。
久々に #ORIROBO を作ったらスーパーオリロボの手がハサミの新種になってしまった!!

==== 2014/6/29 ====
Amazonのインスタントビデオのクーポンの期限だったので7本まとめてレンタルした。１か月で見切れるかどうか。。。
隙間時間でTOEICの文法も問題を結構復習出来た。

==== 2014/7/5 ====
#codecademy jQuery 完了!!
#codecademy PHP開始!!
いちごと二人でイオンでお買い物の待ち時間に宿題を出来た!!
7で買った苺のしろくまが美味しかった。

==== 2014/7/6 ====
いちごが「かけ算とカレンダーの秘密」を受講してきた。面白かったみたいで良かった。
いちごと一緒の隣町の公民館に行った。新しくて綺麗だった。図書館もあり少し勉強も出来た。
懸案だった5月人形を片づけられた。
懸案だった床屋にも行けた。クロサギ18巻が面白かった。

==== 2014/7/12 ====
久々に沢山眠れた。
子供たち3人と児童館の一輪車教室に行った。暑い中サンもいちごも頑張った。
マンゴーヨーグルトが美味しかった。

==== 2014/7/14 ====
Windows 8.1にバージョンアップ
#codecademy Introduction to PHP バッジ獲得!

==== 2014/7/20 ====
板チョコが中に入っているアイスが濃厚で美味しかった。
今朝は９時半くらいまでゆっくり寝られた。

==== 2014/7/21 ====
久々に子供と一緒に朝まで寝ていた。10時間位。夢も沢山見た。
#codecademy 500 Exercises

==== 2014/7/22 ====
#codecademy I've got the badge, "Control Flow: Switch"
今日もあんずと一緒に10時半くらいから朝まで寝られた。

==== 2014/7/23 ====
一か月ぶりにLang-8に投稿出来た!!

==== 2014/7/24 ====
#Coursera #mobileclound 自己紹介を投稿!
星新一のショートショートのドラマ。

==== 2014/7/26 ====
昨日早寝した分早起きして朝活(英語の勉強)出来た。

==== 2014/7/27 ====
昨日は12時前に眠くなったところで寝て、今日は8時位に起きた。理想的な睡眠時間?
The #Lang-8 friend comes to Japan now and she mentioned she saw my home town on the train.
スーパーの朝のタイムセールにぎりぎり間に合った。

==== 2014/7/30 ====
メール誤送信対策マクロの拡充。PersonalData誤送信に対応した。

==== 2014/8/1 ====
プログラマーの三大美徳「怠惰」「短気」「傲慢」を知った。興味深い。

==== 2014/8/2 ====
妖怪ウオッチ零式の発売日。イオンで抽選権はぎりぎりもらえたが外れた。
懸案だった財布を偶然バーゲン価格で購入できた。
懸案だったいちごの携帯を購入。何とか設定が終わった。色々考えられている。

==== 2014/8/3 ====
砂沼サンビーチに行った。波のプールが面白かった。
いちごから初メールをもらった。

==== 2014/8/4 ====
昨日は夜10時ころに子供たちと一緒にねて、今日は6時半に起きて朝活出来た。
久々にLang-8に投稿!

==== 2014/8/7 ====
MEslotが当たった!!
5時前に起きて朝活出来た。

==== 2014/8/8 ====
#codecademy 70streak達成!! 2ヶ月ぶりにmax streakを更新!!

==== 2014/8/9 ====
#codecademy While Loops in PHP budge gotten.
#coursera I enrolled Programming languages.
昨日は早寝したので今日は早起きして朝活出来た。
今朝は久々に涼しかった。
JMOOC gaccoに登録！

==== 2014/8/12 ====
ひいおばあちゃんち
もも三昧
おじいちゃんと買い物。袋無くしたが見つかった。
あんずがジャンプ、元気。

==== 2014/8/13 ====
とまと、ぶどう、お坊さん
順調に帰宅できた。
飛行機であんずが初の一人座席。
帰りの電車で席を譲ってもらった。

==== 2014/8/14 ====
早起きして朝活。
7月のTOEIC(IP)の結果がもう来た。最高得点をリーディングで45点、合計で20点更新!
#Cousera #mobilecloud-001 Assignment様の環境構築がやった出来た。結構面倒だった。

==== 2014/8/15 ====
#3goodは完了
psycho-pass、カステラ、labyrinth

==== 2014/8/16 ====
休日出勤だったが予定より大分早く帰れた。
帰りに雨が降り始めたがひどくなる前に帰れた。

==== 2014/8/17 ====
今日も早寝早起きして6時から朝活。 #coursera にも面白いコース色々あるが、どれを受講するか迷う。。。
2週間ぶりに #lang-8 に投稿!
あんずの七五三の撮影をした。和装も洋装も可愛く撮れた。あまり緊張もせずに良かった。
七五三の撮影の後にショッピングモールでステーキハウスのオープン記念割引でステーキが食べられた。
今日も涼しくて過ごしやすい天気だった。

==== 2014/8/18 ====
今日も早寝早起きして6時半から朝活。
#codecademy I got Max Streak Count of 80 budge!

==== 2014/8/19 ====
#codecademy I got Functions, Part I budge.
いちご、サンと早起きしてラジオ体操に行けた。

==== 2014/8/20 ====
ラジオ体操。くろちゃん

==== 2014/8/22 ====
朝早起きして朝活。

==== 2014/8/23 ====
#codecademy I got Max Streak of 85 budge!
おまつり、徒歩、バンバン、もじもじ

==== 2014/8/24 ====
#cousera #mobilecloud-001 全クイズ、課題が完了した。6週間のコースを5週間で終われた。
サン誕生日、ケーキ、流しそうめん、水風船
#lang-8 投稿。
javascriptに関するblog記載。

==== 2014/8/25 ====
8/20の朝に見た夢についてブログに記載できた。まだ9個位未記載のネタが残っている。。。

==== 2014/8/26 ====
NHK「お金と感情と意思決定の白熱教室」(ダン・アリエリー)を見終わった。面白かった。ブログに記載。http://kuronosuke1.blogspot.jp/2014/08/nhk.html
#codecademy I got Functions, Part II budge!
サンのお誕生会が幼稚園であり、いちごと二人きりで家でお昼ごはんを食べた。

get it done guyを久しぶりに読んだ。
Leave Your Laptop at Home: Taking Notes by Hand Is Better
手書きノートの勧め。

==== 2014/8/27 ====
#coursera Introduction to Computational Finance and Financial Econometrics開始! #lang-8 にも投稿!
朝寝坊したが何とか朝食も食べて会社に間に合った。

==== 2014/8/28 ====
#codecademy I got Max Streak Counts of 90 budge.
#coursera の #compfinanceの課題で一発で満点が取れた!!

==== 2014/8/29 ====
自然数に0を含める場合がある事を知った。集合論では0を含める方が一般的らしい。
サンの誕生日プレゼントのサッカーボールが来た。軽い。
子供3人とお留守番だったがいちごとサンでご飯の準備をしてくれた。知らないうちにずいぶん成長している。
けん玉の技の決まりが良かった。極意剣も2回出来た。

==== 2014/8/30 ====
久々にたっぷり寝れた。10時間位。
「寝ているときに見る夢」のブログを6エントリ作成。http://kuronosuke1.blogspot.jp/search/label/%E5%AF%9D%E3%81%A6%E3%81%84%E3%82%8B%E3%81%A8%E3%81%8D%E3%81%AB%E3%81%BF%E3%82%8B%E5%A4%A2
#Cousera と連携している #Datacamp をやってみた。かなり洗練されたインタフェースで使いやすい。

==== 2014/8/31 ====
#Datacamp Introduction to R を一日(2時間15分)で完了!
あんずが公園でブランコに乗りながらアナ雪を熱唱(笑)！
花火、赤飯

==== 2014/9/1 ====
いちごが夏休み明け初日から自分で起きれた！
今朝も9時間位睡眠して6時から朝活。
#記憶術 の場所法で20個英単語?を暗唱したが、今日も覚えていた。キーになる場所をもっと増やしてみる? 早く場所と結び付けるためには毎日練習が大切。

==== 2014/9/2 ====
#codecademy I've gotten Max Streak Count of 95 budge! How long can my streak go?
#記憶術 の場所法のベースに従兄の家を使ってみた。

==== 2014/9/3 ====
#codecademy I've goten Objects in PHP budge.
本の内容読む前に目次、読んだ後も目次を見て内容を思い出すと定着しやすい。

==== 2014/9/4 ====
夢を見たことは覚えているが、何の夢だったか思い出せない。
log1234と言うのが出てきた。MOOCで計量経済学の講義を受けているのと関係ありそう。
#記憶術 昨日、一昨日で記憶した40個は覚えている。もっと場所を増やす?

==== 2014/9/5 ====
プチ朝活?
他人が作ったVBA(excel)の動作をデバッガで解析出来た。
今週は大体早く帰れた。

==== 2014/9/6 ====
畑の学校の採れたての落花生を茹でたら美味しかった。
寝ているときにみた夢に関するブログを6本書いた。

==== 2014/9/7 ====
#codecademy Max Streak Count of 100!!
子供たちの夏休みポイントのご褒美にダイソーでお買い物。
あんずがパピネスチャージプリキュアのジグソーパズルを上手に出来ていた。

==== 2014/9/8 ====
会社の後輩に沖縄に行く時の飛行機で読んだ村上春樹のアフタダークをあげた。
お月見の団子が美味しかった。
あんずが自家製のキュアフォーチュンの衣装で大喜び。

==== 2014/9/9 ====
サンが「おとうさんのほん」を作ってくれた!! 似顔絵とハートと「ありがとう」と書いてあった。
あんずからお手紙をもらった。折り紙に何か線を書いてくれていた。

==== 2014/9/11 ====
#codecademy Object-Oriented PHP budge gotten!

==== 2014/9/12 ====
#codecademy Max Streak Count of 105

==== 2014/9/13 ====
サンが掃除の前に部屋の片づけを手伝ってくれた。手伝いゲームだと言っていた。ゲーミフィケーションの素質あり!?
いちごも今日は素直に宿題をやっていた。通分を予習で教えたが楽しそうに聞いていた。
久しぶりに10時間半くらいたっぷり寝られた。
サンが昼ご飯の焼そばを７分割したら１５分で食べられた。やはり短期的な目標と目に見えるフィードバックが大切。ゲーミフィケーションのアイデアは使える。

==== 2014/9/14 ====
#Coursera compfinanceのAssignment 4: Matrix Algebraを1st Attemptで満点を取れた!
サンのピアノのグレード試験に一緒に行った。無事に終わった。
近所の農協の直売所で買ったＢ級品のナシが安くておいしかった。

2014/9/15に見た夢

2014/9/15に見た夢を2014/9/15の朝に書いている。
起きてから30分位しかたっていないが、すでに忘れそうなので今まずキーワードをメモした。
断片的なシーンしか覚えていない。
場所の移動を伴うような、連続的なストーリーを覚えている場合といない場合がある。
ストーリーを覚えているものはその後も忘れにくいが、断片的なシーンは直ぐに忘れてしまう気がする。
ストーリーを覚えていない断片的なものの方が直近の現実の経験の影響を受けている気もする。

[キーワード]
学校、家、為替

[夢の内容]
車で大学の様な所を訪ねている。
特に大学に用事が有るような感じはしない。
東京の都内にある大学の様に、道がごちゃごちゃしたところに建っている。
建物の全体像はわからないが、大学と言うより古い高校か中学校のような感じがする。
木造の校舎。一階の入り口付近の廊下の様な所、階段の踊り場の様な所にいる。
それなりの数の人が慌ただしく歩き回っている。普通の高校の休み時間の様な感じで。
その後学校を出たところの外にいる。学校を一緒に訪ねて人たちを待っている様だ。
何故か簡易的な建物の中にいる。一部屋で床に座っている。
こちらは現代的でプレハブの様な建物。そとは丁度暗くなった後の夜の始まり。
そこに子供たちが戻ってくる。多少愚図っていたが、まあ、普通につかれている感じ。
さらにもう一組の子供と親が戻ってる。子供が愚図って泣き叫んでいる。
知り合いか親戚の様だが、実際は知らない人たち？
子供は疲れているのだからしょうがないと言うような事を考えている。

次のシーンは、何か昭和の最初の頃のような感じがするシーン。
全体的な色合いがセピアトーンになっている。
朝ドラの影響を受けている？
誰か朝ドラの主人公の様な人が住んでいた所に家が３軒建っていると言う話をおじさん方している。
少し離れた丘の上か、空から撮ったようなセピアトーンの写真のようなシーン。
小さく３軒の２階建ての洋風の家が見える。２軒が横に並んでいて、１軒が右の家の後ろに隠れている。
何かいわくつきの場所だったが、無事に新しい家も建った言うような話をしている。
そこの場所がを観光マップの様なものに記載されていないので、地図上に丸いマークをつけようとしている。
そうするとそこのマークは他のマークと重なっているだけで記載されていないわけではないから追加不要といわれる。
よく見ると、他のマークは赤色だが、そこのマークは青色になっている。これが重なっている場合の表記なのか？

次のシーンは仕事関係の人たちと為替か何かの話をしている。
発注後の価格変動リスクを発注側と受注側どちらが取るかという事。
さらに発注後に業務内容の変更があった場合のリスクをどうとるかという事も話している。
これは今やっている仕事の内容の影響を受けているのかも知れない。
話している相手は知らない人たち。グループで堅苦しくない雰囲気で５０代くらいの人たちと話している。
一方的に内容を変えたら下請け法上マズいだろと言うようなことを言っている人もいる。
為替の話はなかなか大変で、自分の息子もそれが嫌で会社に行きたくないといったり、その決断を先送りにしていると笑っていた人もいた。

上の話を書いているうちに一つのシーンを思い出した。
会社の女性が私服から制服に変更になったと言うような話。
一緒にいるのは高校の時の部活の知り合い？
制服を着るのが恥ずかしいと言うような話をしている。
勤務するフロアも変更になるという事で、元々の私服を見ていないのだから、制服に変更になっても皆ギャップを感じないから大丈夫と言うような話をしている。
場所は天井を高くてだたっぴろい大きな部屋。社員食堂がありそうな感じだが、机などもあまりない気がする。
白くて明るい。無機質な空間。人はたくさんいる。蛇行して並んでいるような気もする。
人が沢山いるところから離れて、横長の腰の高さ位の扉がないオープンな棚の場所に何かを探しに行く。
そこで発注関係の書類を見ていて、それが上のシーンに繋がっていくのかも知れないが、何とも言えない。
棚も真っ白で無機質な感じ。
よくテレビのコントなどで天国の世界のシーンがあるが、そこと感じはとても似ている。白くて明るくて何もない。無機質。
臨死体験などである天国の世界とかはこのような夢のイメージと関係あるのかも。

2014/9/14に見た夢

2014/9/14に見た夢を2014/9/14の夕方に思い出しながら書いている。
朝起きたときに夢の事を覚えていたのでメモしようと思ったが、結局メモしなかった。
二つの夢を覚えていた気がするのだが、片方が忘れてしまった。
夕方まで忘れないだろうと思っていたのだが、やはりメモしないと思えてられないのかもしれない。
昨日の夜は前の日にたくさん寝たせいか寝つきが少し悪かった。
夢の内容は前の日に見たり聞いたりした内容の影響を受けている様に思える。

[夢の内容]
断片的でストーリーや状況は覚えていない。
暗い部屋にいる。ゲームセンターの雰囲気だがもっと狭くて不特定多数の人がいるような感じがしない。
そこでゲーム機のモニターのところでデジタル画面のスロットマシーンをやっていた。
前の日にネットの何処かなのサイトでスロットマシーン見たのの影響か？
６回やったが全部外れた。
そのマシーンなのかべつのマシーンなのか分からないが、ゲームの画面から対話型のプロンプトを出してコマンドを打ち込める状況になっている。
これは前の日にやったDatacampのRの演習を影響を受けている気がする。
その画面でゲームのC++のソースコードも出力させられることがわかって、出力させている。
一緒にいた小学生に、コードを見れるんだからそれを編集してやりたいことをやれば良いとかは話している。
これも前の日に小学生の話を聞いたことが影響しているような気がする。

2014/9/13に見た夢

2014/9/13に見た夢をその日の11時頃に書いている。
今日はたくさん寝られたのでそれなりに覚えていたいた気がするが、そんなに連続的には覚えていない。
3つの夢のシーンを覚えている。

[夢の内容]
ストーブを買いにお店に来ている。
沢山のストーブが並んでいる。
どんな店かはあまり覚えていないが、スーパーやホームセンターと言うよりも、専門店の様な木の暖かさを感じた。
ストーブは北海道で使うような本格的な石油タンクを外付けで使うようなもの。
昭和的な艶消しの黒い塗装のストーブが多い。
夢の中で今持っているストーブと同じようなものを買う事にしたようだ。
シャンパンゴールドのストーブも気に入ったようだが家に合わないのであきらめた様子。

次は家の中のシーン。自宅の様だが本当の自宅とは違う。
1DK位に小さいアパート。古い。汚い感じはしないが散らかっていて雑然としている。
そこに多分家族と一緒にいるような気がする。
居間の床にみんなで座っている。大きめの本の様なものが郵送で届いたものを開けている。
本の様な平べったいもののはずなのに、なかから2匹の子犬も出てきた。
本がどんなものだったかはわからない。犬が本物か作り物か判断できないでいると、犬がおしっこをし始めて慌てて拭いたりしている。
どうも本物らしい。
台所の所で話していると犬がやってきて小さいサッカーボールの様なものを蹴ってくる。
それがちょうど顔をあたりに飛んできて、受け止めて投げ返すとコントロールよく顔の正面に蹴り返してくる。
なかなか上手いねえ、というような事を話していると、顔にボールがぶつかってしまったような。。。
犬が狭い部屋の中を走り回って壁にぶつかったりしている。
可愛らしい姿を見て、猫派だけど犬も良いかもと思ったりしていた。

次は会社。製品の開発をしている。テストをしようとしているのだが、テスト対象の製品を新しい機種に入れ替えようとしているらしい。
一緒にいるのはあまり知らない人たち。何時もの職場のメンバとは違う気がする。
全体的に白っぽくて研究所の様な雰囲気の所にいる。
何か不具合が有った様で、再現条件か何かを喜一多様な気もする。

Programming in Scala, First Edition: Chapter 31

31. Combinator Parsing
  時々小規模の特定目的の言語(フォーマット)を扱う必要があるかもしれない。
    ソフトのコンフィグファイル、Wiki記法、Markdo記法、JSON
      XMLよりももっと簡単に読み書きしたい。
    検索用の制御文字入りの文字列の解釈
  構造を解析するためのパーサが必要。
  オリジナルのパーサを自作する。
    難しい。工数が掛かる。
  既存のパーサジェネレータを使う。
    沢山のパーサジェネレータがある。
      C言語: Yacc、Bison
      Java: ANTLR
    スキャナージェネレータも一緒に使う事が多い。
      Lex、Flex、JFlex
    使い方を憶える必要がある。(曖昧なエラーメッセージを含む)
    プログラムとの結合方法を調べて合わせる必要がある。
    プログラミング言語や開発環境の制約も受けるかもしれない。
  内部DSLを作成する。
    Scalaでパーサを構成するためのコンビネータを定義する。
    文脈自由文法の構成要素と一対一で対応させられるので分かりやすい。
  本章で出てくる新しい言語仕様はaliasingのみ。
    他はこれまで出てきた言語仕様を組み合わせて実現する。
      parameterized types, abstract types, functions as objects, operator overloading, by-name parameters, and implicit conversions
  本章はこれまでの章よりも難しい。
    コンパイラに関するバックグランドがあると分かりやすい。
    正規文法と文脈自由文法の予備知識が必要。

31.1 Example: Arithmetic expressions
  文脈自由文法の記法
    |         選択
    \{ ... \} 0回以上の繰り返し。
    [ ... ]   オプション
  算術計算の文脈自由文法の定義
    expr     ::=    term  \{"+"  term  |  "-"  term\}.
    term     ::=    factor  \{"*"  factor  |  "/"  factor\}.
    factor   ::=    floatingPointNumber  |  "("  expr  ")".
    加減算と乗除算の優先度も組み込まれている。
  Scalaのコンビネータパーサへの変換
    単純な文字列置換で変換できる。
    trait JavaTokenParsersを継承したクラスに含める。
      floatingPointNumberはこのtraitに含まれている。
    パーサはメソッドとして定義するので"def"をつける。
    result typeを指定するために": Parser[Any] ="
    シンボルの連続を表すためにシンボル間のスペースを"~"に変える。
      "~"はoperatorなので前後にスペースを入れてもOK。
    |         => | のまま。
    \{ ... \} => rep( ... )
    [ ... ]   => opt( ... )
  算術計算のScalaのコンビネータパーサの定義
    import scala.util.parsing.combinator._
    class Arith extends JavaTokenParsers {
      def expr: Parser[Any] = term~rep("+"~term | "-"~term)
      def term: Parser[Any] = factor~rep("*"~factor | "/"~factor)
      def factor: Parser[Any] = floatingPointNumber | "("~expr~")"
    }

31.2 Running your parser
  object ParseExpr extends Arith {
    def main(args: Array[String]) {
      println("input : "+ args(0))
      println(parseAll(expr, args(0)))}}
  上記でスクリプトの引数の文字列が文法に従っているか判定出来る。
    parseAllの代わりにparseを使えば先頭から文法を満たしている部分までを解析。
  $ scala ParseExpr "2 * (3 + 7)"
  input: 2 * (3 + 7)
  [1.12] parsed: ((2~List((*~(((~((3~List())~List((+
  ~(7~List())))))~)))))~List())
    toStringメソッドが強力なので、Parseを見やすく出力出来ている。
    1~12文字目までをparseした結果のleafに置き換えられている。
  $ scala ParseExpr "2 * (3 + 7))"
  input: 2 * (3 + 7))
  [1.12] failure: `-' expected but `)' found
  2 * (3 + 7))
             ^
    失敗した場合の例。
    toStringメソッドが強力なのでコマンドっぽく使えている。

31.3 Basic regular expression parsers
  正規表現にマッチするパーサを作れる。
    object MyParsers extends RegexParsers {
      val ident: Parser[String] = """[a-zA-Z_]\w*""".r
    }
    上記はJavaの識別子にマッチするパーサ
  継承関係
   scala.util.parsing.combinator
     RegexParsers
       JavaTokenParsers
         Arith
           floatingPointNumber

31.4 Another example: JSON
  JSON: JavaScript Object Notation
    データをやり取りするのに良く使われるフォーマット
  JSONの文脈自由文法の定義
    value        ::=    obj  |  arr  |  stringLiteral  |
    floatingPointNumber  |
    "null"  |  "true"  |  "false".
    obj  ::=    "{"  [members]  "}".
    arr  ::=    "["  [values]  "]".
    members      ::=    member  \{","  member\}.
    member       ::=    stringLiteral  ":"  value.
    values       ::=    value  \{","  value\}.
  JSONのパーサ
    class JSON extends JavaTokenParsers {
      def value : Parser[Any] = obj | arr |
                                stringLiteral |
                                floatingPointNumber |
                                "null" | "true" | "false"
      def obj   : Parser[Any] = "{"~repsep(member, ",")~"}"
      def arr   : Parser[Any] = "["~repsep(value, ",")~"]"
      def member: Parser[Any] = stringLiteral~":"~value
    }
    repsep(member, ",")は0個以上のカンマ区切りのmemberの並び。
      repsepもコンビネータ
  ?? 入力文字列の空白文字は自動的に区切り文字として扱われている ??

31.5 Parser output
  パーサの戻り値のデフォルト動作
    文字列: そのまま
    正規表現: マッチした文字列そのまま
      JavaTokenParsersを継承しているstringLiteral、floatingPointNumberも同じ。
        正規表現パーサで実現しているから。
    列挙P~Q: case class ~のインスタンス。~(P, Q)
    列挙P~>Q: Q
    列挙P<~Q: P
    選択P | Q: パースが成功した方
    繰り返しrep(P), repseq(P, Q): PのList
    オプションopt(P): Some(R)かNone
  デフォルトの戻り値では使いにくいの^^オペレータで変換する。
    P ^^ f: Pのパース結果をRとすると、f(R)に変換して返す。
  小数をDoubleに変換するパーサ
    floatingPointNumber ^^ (_.toDouble)
  文字列"true"をScalaのtrueに変換するパーサ
    "true" ^^ (x => true)
  パースした結果を使いやすくしたJSONのパーサ
    class JSON1 extends JavaTokenParsers {
      def obj: Parser[Map[String, Any]] =
        "{"~> repsep(member, ",") <~"}" ^^ (Map() ++ _)
      def arr: Parser[List[Any]] =
        "["~> repsep(value, ",") <~"]"
      def member: Parser[(String, Any)] =
        stringLiteral~":"~value ^^
          { case name~":"~value => (name, value) }
      def value: Parser[Any] = (
          obj
        | arr
        | stringLiteral
        | floatingPointNumber ^^ (_.toDouble)
        | "null"  ^^ (x => null)
        | "true"  ^^ (x => true)
        | "false" ^^ (x => false)
        )
    }
  Summary of parser combinators
    "..."        literal
    "...".r      regular expression
    P~Q  sequential composition
    P <~ Q, P ~> Q       sequential composition; keep left/right only
    P | Q        alternative
    opt(P)       option
    rep(P)       repetition
    repsep(P, Q)         interleaved repetition
    P ^^ f       result conversion
  Turning off semicolon inference
    下記の様に|を行末にすれば括弧が無くても問題ない。
      def value: Parser[Any] =
        obj |
        arr |
        stringLiteral |
        ...
    パーサを書くときは|を行頭に書きたい事があるので、その場合は括弧が必要。
      def value: Parser[Any] = (
          obj
        | arr
        | stringLiteral
        ...
    Section 4.2にあるように、括弧が無いと文末と解釈されてしまうから。
  Symbolic versus alphanumeric names
    パーサコンビネータをアルファベット表記にすべきか? 記号表記にすべきか?
    記号表記のパーサコンビネータの利点
      短い。
      優先度と結合側を制御できる。
        それなりの記号を考えて割り当てれば。
      文法とコンビネータが見た目に分かりやすい。
    記号表記のパーサコンビネータの欠点
      憶える必要がある。知ってないと使えない。
        そもそもうろ覚えでは使えないから、あまり欠点にならないはず?
  Choosing between symbolic and alphabetic names
    その記号を使うのが一般的なら記号を使う。
      足し算にはaddではなくて+を使う。
    casual readersにも分かりやすくしたかったらアルファベットを使う。
    DSLには記号を使う。
      DSLはアルファベットにしてもcasual readersには多分理解できない。

31.6 Implementing combinator parsers
  以下の節ではこれまで述べたパーサの実装について解説する。
    一般的なコンビーネータの設計原則について知ることが出来る。
  以下の節では特に断らない限り下記を前提とする。
    scala.util.parsing.combinator.Parsers traitの定義内での実装の話。
  パーサの本質は、何らかのinput typeからparse resultへの関数。
    type Parser[T] = Input => ParseResult[T]
  Parser input
    type Input = Reader[Elem]
    Elemは抽象型であり、サブクラスのパーサで定義する必要がある。
    ReaderはStreamと同様だが読み込まれた場所を記録している。
      scala.util.parsing.input
    ElemはCharの場合も多い。
      RegexParsers、 JavaTokenParsers
    Elemはseparate lexerで分割したtokensであっても良い。
  Parser results
    成功と失敗の二つのサブクラスをがある。
      sealed abstract class ParseResult[+T]
      case class Success[T](result: T, in: Input)
        extends ParseResult[T]
      case class Failure(msg: String, in: Input)
        extends ParseResult[Nothing]
    パーサをチェーンするために成功時にはInputも含まれている。
      純粋関数的なアプローチでパースしている。
        副作用無しでstreamの内容は変わらない。
        パーサは処理しなかった残りの部分を次のパーサに渡す。
    失敗するときにもInputを含めているがこれはエラーメッセージを出すため。
    Tはcovariant(共変)
      Stringを返すパーサはAnyRefを返すパーサと互換性があると言う事。
  The Parser class
    Parserクラスの実装
      abstract class Parser[+T] extends (Input => ParseResult[T])
      { p =>
        def apply(in: Input): ParseResult[T]
        def ~ ...
        def | ...
        ...
      }
    Parserは実際はfunction type Input => ParseResult[T]を継承したクラス。
      scala.Function1[Input, ParseResult[T]]を継承している。
    apply()を定義しているが、これはドキュメントで使うため。
  Aliasing this
    abstract class Parser[+T] extends (Input => ParseResult[T]) { p => ...
    p => の部分はthisのaliasを宣言している。
    id => で val id = this と同様な使い方が出来る。
    Section 27.4のtraitのself typeと同様の使い方。
    inner classからouter classのthisにアクセスしたいときに使う。
      class Outer { outer =>
        class Inner {
          println(Outer.this eq outer) // prints: true
        }
      }
    Outer.thisと同じ意味だが、短くて分かりやすい任意の名前を付ける事が出来る。
  Single-token parsers
    どんな単一のtokenにも適用できる一般的なパーサelemを定義している。
      def elem(kind: String, p: Elem => Boolean) =
        new Parser[Elem] {
          def apply(in: Input) =
            if (p(in.first)) Success(in.first, in.rest)
            else Failure(kind +" expected", in)
        }
    pはパースするための関数。
    kindはエラーメッセージ表示用のどんなtokenを期待しているのか示す文字列。
  Sequential composition
    列挙演算子~はParserクラスのメソッドとして実装されている。
      abstract class Parser[+T] ... { p =>
        ...
        def ~ [U](q: => Parser[U]) = new Parser[T~U] {
          def apply(in: Input) = p(in) match {
            case Success(x, in1) =>
              q(in1) match {
                case Success(y, in2) => Success(new ~(x, y), in2)
                case failure => failure
              }
            case failure => failure
          }
        }
    自身がパーサpで引数としてパーサqを取る。
    そこから新しいpとqの列挙パーサをinner classとして生成して返す。
      p(in)のpはパーサpのthisのalias
    type T~Uはcase class ~のパラメタ化した~[T, U]と同じ意味。別表記。
      p op qがop(p, q)の別表記であるのと同様。
    <~、~>も~を使って定義出来る。
      def <~ [U](q: => Parser[U]): Parser[T] = (p~q) ^^ { case x~y => x }
      def ~> [U](q: => Parser[U]): Parser[U] = (p~q) ^^ { case x~y => y }
  Alternative composition
    選択演算子|もParserのメソッドとして実装されている。
      def | (q: => Parser[T]) = new Parser[T] {
        def apply(in: Input) = p(in) match {
          case s1 @ Success(_, _) => s1
          case failure => q(in)
        }
      }
    自身がパーサpで引数としてパーサqを取る。
    そこから新しいpとqの選択パーサをinner classとして生成して返す。
      p(in)のpはパーサpのthisのalias
    p(in)が成功したらpの結果を全体の結果とする。
      qについては評価しない。short circuit
    p(in)が成功したら同じ入力をqに適用する。
      pが読んだ後の残りではなくて、巻き戻して適用する。
        実際はpが読む前の入力を保持しているのでそれを適用する。
    両方失敗した時はqのエラーメッセージを出力する。
      この実装の良し悪しはSection 31.9で述べる。
  Dealing with recursion
    ~や|の引数qはby-nameパラメタになっている。
      実際にパラメタを演算に使うまで評価されない。
    これで再帰的な定義が可能になる。
    o  def parens = floatingPointNumber | "("~parens~")"
    通常のby-valueパラメタだったら無限呼び出しになってstack overflowになる。
  Result conversion
    result変換関数の適用もParserのメソッド。
      def ^^ [U](f: T => U): Parser[U] = new Parser[U] {
        def apply(in: Input) = p(in) match {
          case Success(x, in1) => Success(f(x), in1)
          case failure => failure
        }
      }
    自身がパーサpで引数として変換関数fを取る。
    そこから新しいresultを持つパーサをinner classとして生成して返す。
      p(in)のpはパーサpのthisのalias
    Parserクラスのメソッド定義はこれで終わり。
  Parsers that don't read any input
    Parsers traitの中に入力を消費しない二つのメソッドが定義されている。
      Parserクラスの中ではないので注意。Parserクラスもtraitの中の定義の一つ。
      def success[T](v: T) = new Parser[T] {
        def apply(in: Input) = Success(v, in)
      }
      def failure(msg: String) = new Parser[Nothing] {
        def apply(in: Input) = Failure(msg, in)
      }
    successはresultを取って入力を読まずに成功するパーサ。
    failureはエラーメッセージを取って入力を読まずに失敗するパーサ。
  Option and repetition
    Parsers traitの中でオプションopt、繰り返しrep、repsepも定義されている。
    列挙、選択、結果変換の組み合わせで実装出来る。
    def opt[T](p: => Parser[T]): Parser[Option[T]] =
      p ^^ Some(_) | success(None)
    def rep[T](p: Parser[T]): Parser[List[T]] =
      p~rep(p) ^^ { case x~xs => x :: xs } | success(List())
    def repsep[T, U](p: Parser[T], q: Parser[U]): Parser[List[T]] =
      p~rep(q~> p) ^^ { case r~rs => r :: rs } | success(List())

31.7 String literals and regular expressions
  // 正規表現と文字列リテラルのパーサはParsers traitのsubtraitで定義されている。
  trait RegexParsers extends Parsers {
    // 入力を文字Charに特化したParsers
    type Elem = Char
    // implicitなのでStringやRegexをパーサに変換する必要があれば自動的に呼ばれる。
    // 従って文法の定義の時の文に直接文字列や正規表現を書ける。
    // "("~exp~")"はliteral("(")~exp~literal(")")に暗黙変換される。
    implicit def literal(s: String): Parser[String] = ...
    implicit def regex(r: Regex): Parser[String] = ...
    // シンボル間の空白の扱いも定義している。
    // デフォルトは全て読み飛ばす設定。
    protected val whiteSpace = """\s+""".r
  }
  // シンボル間の空白の扱いを変えたいときはwhiteSpaceを上書きする。
  // 下記にすれば空白を読み飛ばさずにそのままパースする設定になる。
  object MyParsers extends RegexParsers {
    override val whiteSpace = "".r
    ...
  }

31.8 Lexing and parsing
  文法(syntax)解析は字句(lexical)解析と構文(syntactical)解析に分けられる。
    構文解析をパースと言う事も時々ある。
    字句解析の問題をパースの問題と言う事もある。
  ScalaのParsers traitは両方に使う事が出来る。
    ElemをCharにすれば字句解析
    Elemをtokenにすれば構文解析
  字句解析用のコンビネータ scala.util.parsing.combinator.lexical
  構文解析用のコンビネータ scala.util.parsing.combinator.syntactical
    使うときはScaladocで調べる。
  普通は正規表現ベースの字句、構文解析を両方行うパーサで十分。

31.9 Error reporting
  エラーメッセージをどう出すかは難しい。black art
    パースに失敗した時に沢山の違った失敗が発生している。
      選択|の全部の選択肢が失敗してる場合。
      再帰的にパーサが定義されている場合。
  最後にパースした部分のエラーを表示するルールにしている。
    再帰の一番深い部分のエラーメッセージ。longest match
    選択の場合は最後の選択肢のエラーメッセージ。
  JSONパーサのエラーメッセージ
    [1.13] failure: "false" expected but identifier John found
      { "name": John,
              ^
  これはJSONのvalueパーサのの最後の選択肢が"false"だから。
    def value: Parser[Any] =
      obj | arr | stringLit | floatingPointNumber | "null" | "true" | "false"
  エラーメッセージ出力用のパーサを最後に追加すれば改善出来る。
    def value: Parser[Any] =
      obj | arr | stringLit | floatingPointNumber | "null" |
      "true" | "false" | failure("illegal start of value")
    [1.13] failure: illegal start of value
      { "name": John,
                ^
  最後にパースエラーになったエラーをlastFailureに保存している。
    可変変数に上書きで保存しているので、最後のエラーが残る。
      varなので関数プログラミング的ではない。
      valに作り替える事も出来が大変。

31.10 Backtracking versus LL(1)
  選択P|Qを使うときにバックトラッキングが発生する。
    Pでいくつかのtokenを読んだ後に失敗した時、QにPと同じtokenを再度与える。
  バックトラッキングする際に左再帰は使えない。
    無限ループになるから。
    左再帰を使わない様に文法を変換する。
  バックトラッキングしない様に文法を書き換える事が出来る場合もある。
  LL(1)文法はバックトラッキングを必要としない。
    多くの言語がLL(1)になっている。
      JSONや四則演算もLL(1)
  バックトラッキングが必要ない場合は列挙演算子~の代わりに~!を使う。
  バックトラッキングをしなければ、処理した入力を捨てても大丈夫。
    解析も線形計算量で完了できる。
  ?? LL(1)文法については良く理解できない。何でbacktrackingが不要になる ??

31.11 Conclusion
  scalaのパーサコンビネータを使う事で少ないコードで自由文脈文法を扱える。
  scalaのライブラリなのでscalaとシームレスに組み合わせる事が出来る。
  簡単に作れるのに加えて拡張性も高い。
  専用ツール(yacc, bison)に比べて性能が悪いと言う欠点がある。
    バックトラッキングが効率的ではないから。
      バックトラッキングの繰り返しが指数関数的な計算量になる場合もある。
      LL(1)文法にして~!演算子を使う事で回避できる。
    入力の解析とパーサの構築を混ぜて行っているから。
      これを改善するには別の実装にする必要がある。
      全てのパーサをcase classにして木構造にする。
      これを効率の良いパーステーブルに変換する。
        標準的なパーサジェネレータのアルゴリズムを使って。
      この変更をしても文法の定義は変更する必要がない。
      パーサの構築を解析とは分けて行えるので、一回構築すれば繰り返し解析できる。
      LALRのような高速のアルゴリズムを使う事も出来る。
  高性能パーサはやれば作れて、作ったらscalaのライブラリに簡単に入れられる。
  高性能パーサを作った後でも今のパーサを残す意味はある。
    簡単で理解しやすい。
    入力が小さいときは効率は問題にならない。

2014/9/10に見た夢

2014/9/10の朝見てキーワードをメモしておいたのを、2014/9/10の夜に見ながら思い出してみる。
ただ、今朝の夢は朝の時点でもかなり断片的にしか思い出せなかった。
また、複数の夢が混ざっているような気がする。
沢山寝てゆっくり起きた方がちゃんと夢を覚えている気がする。
脳の疲れが十分に取れた状態で見た夢は思い出しやすい？

[キーワード]
ビリアード、国民宿舎の様な所、食堂、職場の人、食事をとりに行く、ビュッフェ?、皿が汚れている、
実家、時計、電池がない、プロレス、ゲーム、怒られている、対戦、

[夢の内容]
壁と言うか部屋の天井一面でビリヤードの様に球を転がして当てたりするゲームをしている。
盤が大きいので球もビリヤードの球の2,3倍はありそう。
何故か部屋が90度傾いていて、天井部分が壁の様に垂直に立ち上がっている面でゲームをしている。
何故か球は落ちない。くっついている。夢の中でも落ちそうだと心配している。
一緒にいるのは隣の部の部長。他に会社の関係者が数人いるかもしれない。
場所は国民宿舎の様なあまり新しくない宿泊施設の部屋の中。
ゲームの途中だが部屋から出て食堂に向かう。
食堂は小奇麗で小さめの食堂。行くのが少し遅くなって大体席が埋まっている。
全員分の席が丁度あるはずなので、空いている場所を探して座ろうと話している。
ビュッフェスタイルなので皿を持って食べ物を取りに行く。
何故か食べ物の大皿を載せているテーブルも食べる人が座る席になっている。
食べ物は何があったか思い出せないが、洋風で結構おいしそうだった気がする。
取ろうと思った時に皿が汚れている事に気が付く。
誰かがすでに使った後の様に何色かのソースが付いている。
どうしようかと困っている。

別の夢だと思うが、実家にいる。夜寝る前位。
本物の実家とは違うが、実家だと認識している。家族か親戚と一緒にい要る。
目覚ましをセットしようとしてかデジタルの箱型の時計を出す。
デザリング用のWiFiルータみたいもの。携帯の電池残量表示の様なものが付いていて、それがなくなっている。
充電してくるのを忘れたと思い。準電気を出そうとする。

また別の夢だと思うが、小さ目の体操ルームの様な所にいる。
そこで何かプロレスの様な組み合って行うゲームの練習をしている。
何かマズいことをやった様でインストラクターの様な人に怒られているが、それには不服の様子。

日経BizGate「もう「顧客に聞いたニーズ」では儲からない」を読んで

会社の人に勧められて日経BizGateの「もう「顧客に聞いたニーズ」では儲からない」を読んだ。
http://bizgate.nikkei.co.jp/article/78124916.html

ブルーオーシャンを探す。
顧客にニーズを聞いただけでは見つからない。<= グロービス著『実況マーケティング教室』 今まで探してこなかった領域を探す。 =>「ジョハリの窓」の「未知の窓」
顧客に聞くのではなくて行動や対話を観察してその背景にあるニーズを探る。
=> MROCやオンライン・エスノグラフィーを使う。
購入後に製品/サービスが使用価値が最大化する様に環境を準備する。
=> トヨタの86ではオーナーのためのコミュニティサイトを立ち上げている。
顧客と共に製品/サービスが使用価値を創っていく。
=> 価値共創

2014/9/9に見た夢

2014/9/9の朝に見た夢を昼に書いている。
夢を思い出せるかは朝の起き方と大分関係がありそう。
無理やり起きると起きた瞬間は夢の事を憶えていても、ぼんやりしていて頭が覚醒しきる前に忘れてしまう。
今日も起きた直後は覚えていたが、ぼんやりしている内に忘れて、その後朝何か別の事をしているときに思い出した。
ただ、思い出したと言っても断片的でほんの少しだけだったが。
そこで時間が無かったのでメモはしなかったが昼にその事を再度思い出して書いている。

[夢の内容]
従兄の家に居る。最近記憶術でこの家を場所法のベースにしてみたので影響している?
何をしているのか思い出せない。
その後何故か、お店の様なところに行ってレジに並ぶ。
会社の同僚の人も並んでいる。5人以上の結構な列になっている。
コンビニの様な感じの店。空港の中の様に白くて明るくてきれいな印象がある

Simon Sinek: How great leaders inspire actionを見て

TEDの「Simon Sinek: How great leaders inspire action」を見た。

人を動かすのは物や結果ではなくて相手の信念に自分が共感出来るかと言う事。
Why->How->Whatの順序で考える必要がある。
信念を持ちそれを実現する方法を考えて結果を出す。
結果を求めるために手段を考えても人を動かすことは出来ない。
Appleやライト兄弟やキング牧師が良い例。
これは人の脳の構造と同じ。neocortex->limbic
人は理性に動かされるのではなくて、感情によって動かされる。
信念は感情に訴える事が出来る。
マーケットで成功するには16%以上の普及率が鍵。そこがtipping port。
そこを超えると残りの「皆持っているから買う」と言う層を巻き込める。
最初の16%に訴えるためにはその人たちの信念に訴えかける必要がある。
信念が人を動かすと言うのは子育ての様な日常生活についても当てはまる気がした。
また、TSP/PSPで言われている「自分たちが出来る最高の計画を出せばマネージメントを説得できる」も同じ気がする。

Programming in Scala, First Edition: Chapter 30

30. Actors and Concurrency
  Javaでもマルチスレッドプログラミングはサポートされている。
    一通り必要な機能はそろっている。
    大規模な複雑なシステムを上手く作るのは困難。
  ScalaではActorライブラリを用意している。
    Javaのモデルより使いやすい。
  例としてChapter 18の回路シュミレーションのマルチスレッド版を扱う。

30.1 Trouble in paradise
  Javaの組み込みのスレッドは共有メモリとロックをベースにしている。
    各オブジェクトをmonitorに関連付ける。
    共有データをsynchronizedになっているコード部分からアクセスする。
    ロックを使ってsynchronizedのコードが他スレッドから割り込まれない様にする。
  大規模で複雑になると共有メモリとロックでは安全に作るのが困難。
    どのデータが他のスレッドからアクセスされるのか把握している必要がある。
    どのロックを取るべきかを把握している必要がある。
    デッドロックしない様にする必要がある。
    机上チェックのみでプログラムを正しく作るしかない。
      コンパイル時に間違いをチェック出来ない。
      テストもタイミングに依存して問題を摘出出来ない場合がある。
    ロックを過不足なしに実装する必要がある。
      過剰にロックしても問題になる。ロック不足でも問題になる。
      安全のためにロックを多めにするという戦略も使えない。
    Java 5のjava.util.concurrentライブラリより使いやすくはなっている。
      それでもロックと共有メモリベースなので本質的は難しい。
  Scalaではメッセージパッシングモデルを使えるようにした。
    共有メモリやロックより使いやすい。
      デッドロックや競合が発生しにくい。

30.2 Actors and message passing
  Actorとは?
    スレッドの様なentity
    メッセージを受信するためのメールボックスを持っている。
  一番簡単なActorの例
    scala.actors.Actorをextendして使う。
      act()メソッドを実装する。
      start()メソッドでスレッドを生成、実行する。
    import scala.actors._
    object SillyActor extends Actor {
      def act() { for (i <- 1 to 5) {
        println("I'm acting!"); Thread.sleep(1000) }}}
    SillyActor.start()
  actor関数を使えばstart()メソッドを使わずにいきなりThreadを生成、実行出来る。
    scala> val a = actor { Thread.sleep(1000); println("hoge") }
    a: scala.actors.Actor = scala.actors.Actor$$anon$1@1d638bc
  ! メソッドでactorにメッセージを送る
    scala> SillyActor ! "hi there"
  receiveメソッドでメッセージを受け取る
    val echoActor = actor { while (true) { receive {
      case msg => println("received message: "+ msg) }}}
    receiveはpartial function(Section 15.7)にメッセージを渡す。
      caseにマッチするメッセージのみが渡される。
      マッチしないものは単に無視される。
  メッセージを送るときにブロックはされない。
    何時でもメッセージを送ることが出来る。
    ?? blockingにしてタイミングを合わせる事は出来ない ??
  メッセージを受信しても割り込まれない。
    receiveが呼ばれるまでメッセージはキューの中に溜まっている。
    ?? キューが一杯になったら? キューの大きさは制限出来ない ??
  ?? actorを外から強制的に止める方法がない? Java threadのstop()は使えない??

30.3 Treating native threads as actors
  actorの中ではJavaのnative threadを一つか沿い令嬢使っている。
    actorを普通に使っている限りでは、どうマップされているか意識する必要はない。
  元々Javaのnative threadとして使われているthreadをactorで扱う事が出来る。
    Thread.currentを直接は使用できない。
      actorとして必要な情報が足りないから。
    Actor.selfを使う。
      これはshellからactorのデバッグをする時にも便利。
      shellが動いているthreadをactorとして使える。
        scala> self ! "hello"
        scala> self.receive { case x => x }
        res6: Any = hello
      shellを永久にblockするのを避けるのにreceiveWithinでタイムアウト指定する。
        scala> self.receiveWithin(1000) { case x => x } // wait a sec!
        res7: Any = TIMEOUT

30.4 Better performance through thread reuse
  actorはJavaのthread上に実装されている。
  Javaのthreadは名前に似合わずに「重い」
    沢山メモリを消費する。
      数約万のobjectを作れる様なVMでも数千のthreadしか作れない。
    threadの切り替えに時間が掛かる。
      数百サイクルのプロセッサ時間を消費する。
  性能を上げるためにはthreadの生成と切り替えをなるべく少なくしたい。
  reactと言うメソッドを使えばこれが出来る。
    receiveと同様に部分関数を引数にとる。
    receiveと違ってNothingがreturn type。
      メッセージハンドラを評価するのみで関数から戻らないということ。
    実行結果は他のactorにメッセージを送るなどして受け渡す。
  reactはThreadの生成や切り替えをしない実装になっている。
    関数から戻った後処理が無いので呼ぶ前までのコールスタックが不要。
    ?? クロージャのみ保持しておけOKと言うこと ??
    あるメッセージを処理したら同じthreadで別のactorを処理出来る。
    receiveの替りにreactを使えば原理的にはsingle threadでOK。
      マルチコアの場合はそれに見合うだけのthreadを使うように実装されている。
  極力reactを使うようにすべき。
  reactから戻れないのでメッセージを受信した後の処理も全てreactから行う必要あり。
    通常はact自身のようなtop levelの処理をメッセージ受信処理後に呼び出す。
      ?? 要するにループにしておくということ??
    Actor.loopを使えばblock内にreactがあってもループ処理を実現できる。
      ?? 抜けるときはどうする? exceptionで抜ける?
  return typeがNothingだと言う事は関数から戻らないと言う事だが、exceptionでは抜けられる。
    reactについてもこれは成り立つ。
  reactの実装について。下記ほど単純ではないが、概念的にはそうなっている。
    actorのstartを呼ぶと、threadが割り当てられてactが呼ばれる。
    actからreactを呼び出すと処理できるメッセージがあるかを調べる。
    ?? あったらメッセージを後で処理する準備をしてexceptionを投げる。??
    無かったら自身を"cold storage"に保管した後にexceptionを投げる。
      後でメッセージが来たら復活出来るように。
    どちらの場合でもreact->actはexceptionで無理やり完了させられる。
      actを呼んだthreadはexceptionを捕捉して、次の処理に移る。
        actorを呼んだと言う事は忘れてしまう。
    複数のメッセージは処理するためには部分関数内からactを再び呼ぶ必要がある。

30.5 Good actors style
  actorの良いところはactors styleでマルチスレッドプログラムが出来る事。
    良いactors styleで書くためのガイドラインを本節で示す。
  Actors should not block
    actorはメッセージ待ち以外でblockすべきではない。
    blockしている最中にメッセージを処理できないから。
      三竦みになってdeadlockする可能性がある。
    blockする代わりに起床用のメッセージを送るhelperのactorを使う。
      sleepの代わりに一定時間後にメッセージを送るhelperを使う。
      このhelper自体はメッセージ待ちしないのでsleepしても問題ない。
    ** UNIX系でも待ちをselect等で一本化すべきなのと同じ。
  Communicate with actors only via messages
    メッセージのみで通信すべきで、共有データを使うべきでない。
      共有データを使うと結局ロックも必要となってactorの良さが生かせない。
    ただし、scalaでは共有データ、ロックとの併用も許してはいる。
      ここはerlangよりも自由度がある。
      信頼できるライブラリで共有データ、ロックが隠ぺいされているなら使っても良いかも。
      actorで作り直すことも出来るが、どちらが簡単で安全か?
    If you're considering shared data and locks
      ?? ダーティーハリーの"Do I feel lucky?"の一節が参考になる。??
  Prefer immutable messages
    actorのactメソッドの中でもthread-safeとかを気にしなくて良い。
      非同期、mutalbeなオブジェクトも使える。
      "share-nothing model"と呼ばれている。
    メッセージに入れて送るオブジェクトだけは例外。
      thread-safeか意識する必要がある。
    一番良いのはimmutableにする事。
      case classにするのが簡単。
      Scalaのimmutableライブラリや自作のものでもOK。
      安全な上にリソースをあまり消費しないで済む。
      並列計算をする場合は特に有効。
        actorを使わない場合でも有効。
    mutableにする場合はどのactorにアクセス権限があるのか明確にする必要がある。
      mutableなオブジェクトを送ったらそれ以降はアクセスしないなら安全。
        その後、他人が修正する時に間違うリスクはあるが。。。
      アクセス権限をメッセージでやり取りする方法もある。
      複数でアクセスする必要があるならコピーすべき。
        単にコピーするよりimmutableに変換してコピーするほうが望ましい。
  Make messages self-contained
    通常のメソッド呼び出しではリターン後に呼び出し元は何をすべきか分かっている。
    actorの場合はreceive後にどうするかを決めるのが難しい場合がある。
      send後にreceiveするのはしばらく後の場合もある。
      send時の状況を思い出す必要があるため。
    メッセージに冗長な内容を含めてこれを保管する。
      requestの内容をresponseにそのまま含める。
        requestがimmutableならあまりリソースを消費しない。
      selfを含める。
        メッセージが誰から来たのか分かりやすくなる。
      case classにしてwrapした方がコードが分かりやすくなる。

30.6 A longer example: Parallel discrete event simulation
  Chapter 18の離散事象シミュレーションをactorで並列実行可能にする。
    並列化すればマルチコア等を使って高速化できる。
    シミュレーションの各々の要素をactorにする。
  Overall Design
    Chapter 18を大きく変えずにactorで並列化出来る。
      各々の要素をactorにしてeventをメッセージにすれば良い。
      各要素で共通している部分はtrait Simulantとして各要素でextendsする。
    各要素の同期方法
　    clock actorを用意して各要素をクロック同期させる。
      clock actorから各要素に各周期の開始をpingメッセージで伝える。
      各要素は処理が終了したらpongメッセージでclockに知らせる。
      ping/pongにはパラメータは本来不要だが、分かりやすくするためにtickを入れる。
        debugの時に特に有効。
    各要素を直接通信させずにclockを経由させる。
      各要素が直接通信すると、各周期の終わりが何時なのか判断できない。
        他の要素からさらにメッセージが来るかも知れないから。
      各要素は次の周期のためのイベントをclockに送る。
      clockはそれをまとめてagendaとして各要素に送る。
      各要素はpingを受けたらagendaを処理する。
    シミュレーションの開始。
      全ての要素を立ち上げて、受信可能状態になったらclockを動かせば良い。
  Implementing the simulation framework
    メッセージをcase classで定義する。
      case class Ping(time: Int)
      case class Pong(time: Int, from: Actor)
      case class WorkItem(time: Int, msg: Any, target: Actor)
      case class AfterDelay(delay: Int, msg: Any, target: Actor)
      case object Start
      case object Stop
    core frameworkへの追加要素
      Clock class と Simulant trait
    class Clock extends Actor {
      // running = falseで上がってStartメッセージが来たらtrueになる。
      // falseの間はclockからメッセージを出さないので要素は動作しない。
      // これにより初期化中はメッセージを使わずに普通に関数を呼んでOK。
      private var running = false
      private var currentTime = 0
      private var agenda: List[WorkItem] = List()
      // 存在する全ての要素
      private var allSimulants: List[Actor] = List()
      // current time tickの処理がまだ終わっていない(Pongを返していない)要素
      // busySimulantsがemptyになったら次のtickに進める。
      // tickを進める時にallSimulantsをbusySimulantsにコピーする。
      private var busySimulants: Set[Actor] = Set.empty
      // Startメッセージ来るまで何もしないので、先にactorとして起動しても安全。
      start()
      // 要素をClockに登録する。
      def add(sim: Simulant) {
        allSimulants = sim :: allSimulants
      }
      // tickを進める処理とtick中のメッセージ受信に処理を分ける。
      def act() {
        loop {
          if (running && busySimulants.isEmpty) advance()
          reactToOneMessage()
        }
      }
      // tickを進める処理。
      def advance() {
        if (agenda.isEmpty && currentTime > 0) {
          println("** Agenda empty.  Clock exiting at time "+ currentTime+".")
          self ! Stop
          return
        }
        currentTime += 1
        println("Advancing to time "+currentTime)
        // Ping前にagendaを要素に送っている。
        // Ping前はClockは受信しないので、要素からメッセージを送っても影響なし。
        // 要素はPing受信直後にPongを返すことになる。
        processCurrentEvents()
        for (sim <- allSimulants) sim ! Ping(currentTime)
        busySimulants = Set.empty ++ allSimulants
      }
      private def processCurrentEvents() {
        // currentTimeより前の物は無いはずだが念のために<=にしている。
        // currentTime>_.time が見つかったらその時点でループを止めても良い。
        val todoNow = agenda.takeWhile(_.time <= currentTime)
        // agendaはinsert時にtickでsortされているので前から順番に捨てられる。
        agenda = agenda.drop(todoNow.length)
        for (WorkItem(time, msg, target) <- todoNow) {
          // currentTimeより前の物は前tickで既に処理されて存在しないはず。
          assert(time == currentTime)
          target ! msg
        }
      }
      def reactToOneMessage() {
        react {
          case AfterDelay(delay, msg, target) =>
            val item = WorkItem(currentTime + delay, msg, target)
            // insertはListing 18.8と同じ。tickでsortされる様に挿入する。
            agenda = insert(agenda, item)
          case Pong(time, sim) =>
            assert(time == currentTime)
            assert(busySimulants contains sim)
            busySimulants -= sim
          // Startは単にrunning = trueのみでOK。
          // reactを抜けた後loop=>advanceで動作が始まる。
          // Start直後のtick=1だけ特別扱い
          //   Ping受信後にagendaがSimulantから送られてくるように細工してある。
          case Start => running = true
          case Stop =>
            for (sim <- allSimulants)
              sim ! Stop
            exit()
        }
      }
    }
    // 各要素の共通部分
    trait Simulant extends Actor {
      val clock: Clock
      // 共通メッセージ(Ping/Stop)以外の処理。subclassで定義。
      def handleSimMessage(msg: Any)
      // Start直後のtick=1のPing受信後のみに実行される立ち上げ処理。subclass。
      def simStarting() { }
      def act() {
        loop {
          react {
            case Stop => exit()
            case Ping(time) =>
              // Start直後のtick=1だけ特別扱い。
              // Ping受信後に最初のagendaをClockに送る等立ち上げ処理する。
              // それ以外ではClockからのagenda受信処理の中でClockに送り返す。
              if (time == 1) simStarting()
              // Start直後のtick=1以外はPongを返すのみ。
              clock ! Pong(time, self)
            case msg => handleSimMessage(msg)
          }
        }
      }
      // インスタンス化されるタイミングactorとしてはstartさせる。便利だから。
      // メッセージを受けるまで何もしないので安全。
      start()
    }
    Chapter 18の並列化前のコードと同様に驚くほど少ないコードで実現出来た。
  Implementing a circuit simulation
    シミュレーションする回路(Class Circuit)の実装。
      wireとgateとclockからなる。
      wireはtrue/falseを保持するのみ。
      gateはwireを結合する。入力wireの値から出力wareの状態を変更する。
      wire、gate等はClass Circuit内のみで使うので、sub classにした方が良い。
  class Circuit {
    val clock = new Clock
    // simulation messages
    // gateからwireの状態をセットするためのメッセージ
    case class SetSignal(sig: Boolean)
    // wireからgateにwireの状態の変化を知らせるためのメッセージ
    case class SignalChanged(wire: Wire, sig: Boolean)
    // delay constants
    // 必要に応じてdelayを変更できるように定数に定義しておく。
    // ** C言語でよくある#defineで定数を定義するのと同じ。コード変更必要。
    val WireDelay = 1
    val InverterDelay = 2
    val OrGateDelay = 3
    val AndGateDelay = 3
    // Wire classes and methods
    class Wire(name: String, init: Boolean) extends Simulant {
      def this(name: String) { this(name, false) }
      def this() { this("unnamed") }
      // Wireをnewする時にはouterのCircuitがnewされていて、その中のclockを使う。
      val clock = Circuit.this.clock
      // Wireがnewされる時に呼ばれる。
      clock.add(this)
      private var sigVal = init
      // WireをInputとしているGateのリスト
      private var observers: List[Actor] = List()
      // SetSignalのメッセージを受け取ったらobserversにSignalChangedを知らせる。
      def handleSimMessage(msg: Any) {
        msg match {
          case SetSignal(s) =>
            if (s != sigVal) {
              sigVal = s
              signalObservers()
            }
        }
      }
      def signalObservers() {
        for (obs <- observers)
          clock ! AfterDelay(
            WireDelay,
            SignalChanged(this, sigVal),
            obs)
      }
      // 信号の初期状態をobserversに知らせる。
      override def simStarting() { signalObservers() }
      // WireをInputとしているGateの追加。初期化時のみなので関数コールでOK。
      def addObserver(obs: Actor) {
        observers = obs :: observers
      }
      override def toString = "Wire("+ name +")"
    }
    // Gate classes and methods
    // and/or/invertの3種類のGateを実装する。
    // 共通分はabstract classにする。
    // 共通化のためにintertも2入力に統一して、片側を無視する様にする。
    // 無視する入力は常にfalseのDummyWireと接続しておく。
    private object DummyWire extends Wire("dummy")
    // Gateの共通部分
    abstract class Gate(in1: Wire, in2: Wire, out: Wire) extends Simulant {
      def computeOutput(s1: Boolean, s2: Boolean): Boolean
      // defでも定義出来るが、valにした方が定数であることを表しやすい。
      val delay: Int
      val clock = Circuit.this.clock
      clock.add(this)
      in1.addObserver(this)
      in2.addObserver(this)
      // 入力のWireの状態のキャッシュ。
      // 変更時しか通知されないため保持する必要あり。
      var s1, s2 = false
      // 入力が変更されたらそれをキャッシュして更新後の出力を通知する。
      def handleSimMessage(msg: Any) {
        msg match {
          case SignalChanged(w, sig) =>
            if (w == in1)
              s1 = sig
            if (w == in2)
              s2 = sig
            clock ! AfterDelay(delay,
                SetSignal(computeOutput(s1, s2)),
                out)
        }
      }
    }
    // 各Gateはutilityメソッドの副作用としてする。
    // delayの設定と演算の定義を行う。
    // 抽象クラスGateをanonymousクラス経由で直接newする。
    def orGate(in1: Wire, in2: Wire, output: Wire) =
      new Gate(in1, in2, output) {
        val delay = OrGateDelay
        def computeOutput(s1: Boolean, s2: Boolean) = s1 || s2
      }
    def andGate(in1: Wire, in2: Wire, output: Wire) =
      new Gate(in1, in2, output) {
        val delay = AndGateDelay
        def computeOutput(s1: Boolean, s2: Boolean) = s1 && s2
      }
    // inveter自体は1入力だが内部でGateを生成する際にDummyWireに置き換える。
    def inverter(input: Wire, output: Wire) =
      new Gate(input, DummyWire, output) {
        val delay = InverterDelay
        def computeOutput(s1: Boolean, ignored: Boolean) = !s1
      }
    // misc. utility methods
    // Wireの状態を表示するutilityメソッド。
    // 要素の一つとして登録するだけでOK。
    def probe(wire: Wire) = new Simulant {
      val clock = Circuit.this.clock
      clock.add(this)
      wire.addObserver(this)
      def handleSimMessage(msg: Any) {
        msg match {
          case SignalChanged(w, s) =>
             println("signal "+ w +" changed to "+ s)
        }
      }
    }
    // clockにStartメッセージを送ってシミュレーションを開始する。
    def start() { clock ! Start }
  }
  Circuit classの使い方。
    Circuitをnewする。
    Wireをnewする。
    Gateをutility関数を呼び出して作成する。
    気になるWireをprobeする。
    start()を呼び出す。
  Circuitの拡張。
    Circuitをextendsしたtraitを作れば要素を追加できる。
      Circuitのメンバに自由にアクセスする事が出来る。
    加算器の追加。
    trait Adders extends Circuit {
      def halfAdder(a: Wire, b: Wire, s: Wire, c: Wire) {
        val d, e = new Wire
        orGate(a, b, d)
        andGate(a, b, c)
        inverter(c, e)
        andGate(d, e, s)
      }
      def fullAdder(a: Wire, b: Wire, cin: Wire,
          sum: Wire, cout: Wire) {
        val s, c1, c2 = new Wire
        halfAdder(a, cin, s, c1)
        halfAdder(b, s, sum, c2)
        orGate(c1, c2, cout)
      }
    }
    使うときは下記。
      val circuit = new Circuit with Adders
    classの代わりにtraitを沢山用意すれば必要な部分をmixして使える。
      val circuit = new Circuit with Adders with Multiplexers with FlipFlops ..
  Trying it all out
    実際のシミュレーションの例。
    object Demo {
      def main(args: Array[String]) {
        val circuit = new Circuit with Adders
        //直後にimport circuit._する事でcircuitのメンバに簡単アクセスできる。
        import circuit._
        val ain = new Wire("ain", true)
        val bin = new Wire("bin", false)
        val cin = new Wire("cin", true)
        val sout = new Wire("sout")
        val cout = new Wire("cout")
        probe(ain)
        probe(bin)
        probe(cin)
        probe(sout)
        probe(cout)
        fullAdder(ain, bin, cin, sout, cout)
        circuit.start()
      }
    }

30.7 Conclusion
  コンカレントプログラムは素晴らしい。
    コードを簡単に出来る。
    マルチコアを活用して性能を上げられる。
  コンカレントプログラムは地雷原。
    thread, lock, monitorで正しくdeadlockや競合を避けるのは大変。
  actorを使えば地雷原から脱する事が出来る。
    reactを使えば性能も改善できる。

記憶術: 場所法の試行

過去の自分の家、従兄の家の場所で各20箇所で記憶は憶えやすかった。

さらに過去の自分の勉強机と姉の勉強机の各10箇所も使ってみた。
机の構造的には全く同じなので、若干記憶が混ざりやすいかもしれない。
登場人物とストーリーを分ければ何とかなるかも。
結局は机のパーツに結びつけるときでも家の様に小人でシーンをイメージしていた。

個数や位置関係等の構造が明確に記憶出来ているものなら何も場所法のベースに出来る?
ノートを建物の平面図の様に区切って、その構造を記憶できれば丸暗記出来る?
更に、本のページで行えば本を丸暗記出来る?

目次の構造を使って記憶すると言う方法は実践している人がいるらしい。

Benjamin Zander: The transformative power of classical musicを見て

TEDの「Benjamin Zander: The transformative power of classical music」を見た。

ピアノの実演やジョークを交えてテンポも良く素晴らしいプレゼンだった。
その分英語は早くで聞き取るのが大変だったが。。。
誰でもクラシック音楽を聞いていその素晴らしさを感じる素養を持っている。
音楽が分からないと言っている人は単に今までその機会が無かっただけ。
指揮者は自分で演奏する訳ではないので、演奏者の能力を如何に引き出すかが仕事。
これは多くの他の仕事にも共通する事。
「これが最後の言葉になったら後悔するような事は言わない」

記憶術の場所法のベースを作る方法

記憶術でよく使わるのが記憶する対象を何かの場所に対応づけて覚えるという場所法。
一連の場所を記憶の中で辿る事で結び付けられた内容を思い出すことが出来る。

これを行うためにはベースとなる一連の場所の記憶が必要。
記憶する量を増やすためにはベースも増やす必要がある。

とある話では訓練により6,000〜10,000のベースを持つことも可能らしい。
これはタクシー運転手が沢山の道順を記憶出来ているという事と同じような話らしい。

ベースを増やす方法を考えてみた。

[既に記憶している身近にある場所を使う]
自分の家の中
会社などの良く行く建物の中
自宅から会社などの良く通る道

[既に記憶している過去の場所を使う]
昔住んでいた場所
昔よく行ったところ

[自分の身の回りの場所をデジカメで撮影して記憶する]
実際に行ける場所をデジカメで撮影する
撮影した画像を見ながら記憶してベースする

[自分が実際に行った事はない場所の写真の場所]
一連の場所を辿れるなら、実際に行った事が無い場所でもベースできるのでは?
google mapのストリートビューやgoogle earth等も使える可能性がある。

[ゲームや映画、漫画、小説等の各世界中の一連の場所]
ゲームの中の一連の場所も辿れるならベース出来そう。

[自分で記憶のための一連の場所を創作する]
シムシティ等の様に記憶用に自分で街を作成してベースにする事は出来ないか?
他のモノや街を設計して3Dデータとして内部を散策できるソフトがあれば使えそう。
さらにそこにイベントの様にストーリで記憶対象も埋め込めるソフトなら強力。
自分で構築した世界の分、記憶に強く定着出来る可能性がある。

Second Life, Opensim