中国式英語勉強法
前に僕の研究室に配属していた、1個下の中国人留学生は
とても英語がうまい人でした。1個下なのに英語での交流会でも
英語のプレゼンテーションでも凄く積極的に行動できていて、
俺より若いのにこんなに英語が流暢に出来るのかよ反則だ、
だなんて何度も思ったものです。
彼は昨年の震災をきっかけに中国へ帰ってしまいましたが、
彼とは今でもFacebook上でメッセージのやり取りを続けています。
あるとき、僕は自分の英語能力が全然上達しないことに悩み、
次のようなPostを自分のページに投げました:
"""
(原文訳)
誰か、俺の英語のスキルを上昇させる方法について教えてくれる人いない？
長くても単純な文章なら比較的簡単に書けるし読める（と、思う）んだけど、
ひとたび少しでも文章が複雑になると、その文のある程度の意味すら
読み取れずに全く理解することができなくなるんだ。いい方法ないかね？
ここ数年、英文のオライリー本をずっと読み続けているけれど、
全然英語の能力が継続的に向上しているように感じられない....
""""
すると、その中国人留学生が丁寧にもこんなアドバイスをしてくれました。
"""
(原文訳)
君と同じく英語を母国語としない僕が行った、中国での英語の学習法が
少しでも君の役に立ってくれると嬉しい。
1. テスト。
TOEICより、多くの中国人の学生はより高度なテストである
TOEFL,IELTS,そしてGREの勉強をする。恐らく、これらの要求する
そのレベルの高さにより、彼らの英語のレベルが
引き上げられているのだと思う。
2.語彙。
GREを受けるには膨大な量の単語を覚える必要がある。
なので、短時間内に膨大な新しく覚えた単語の中から
適切なものを選択する能力は
GREではとても重要だ。この勉強が英語の能力を向上させるのに
もっとも重要だと僕は考えている。
3.構文。
君が十分な語彙力を持っていて、膨大な単語の中から正しい意味を
すばやく認知できるのであれば、新しい構文を覚えることは
長くて複雑な文章をすばやく理解するのにとても役に立つ。
4.時間。
GREでは60分の制限時間しかない。これはまた、英語の学習を
促進させるために特に重要だと僕が思っているものだ。
制限された時間内に答えるために、君は「英語を日本語に変換する」
という考え方から「英語で考える」という考え方へ強制的に
シフトさせられるだろう。
この中の1つや2つでも君の役に立ってくれたならとても嬉しく思う。
よき週末を！
"""
彼のメッセージを読んで、日本の(大多数の英語の学習者が行っている)
英語の勉強法の課題がかなり見えてきたような気がしました。
日本では,最近どこに行っても英語といえばTOEICで、
英語の勉強=TOEIC, 英語ができる=TOEICの点数が高い、
といったTOEIC崇拝のような文化ができてしまっているように思います。
つまり、すべての基準がTOEICになってしまっているのです。
しかし、TOEICは彼の言うような「とにかくたくさんの語彙を覚えないと点が取れない」
ような構成にはなっておらず、月によっては語彙が殆ど分からなくても
(副詞しか入らない部分に穴埋めをする問題で1択だけ --lyがある、とか)
解けてしまう問題が沢山出題されることもあります。
つまり、TOEIC=英語を使ううえで必要な能力すべてを測るもの ではない
というごく当たり前の事に気づき、TOEICで埋められない穴を埋めるような
勉強をしなさい、ということを彼は教えてくれたのだと思います。
(だから説明文上で、TOEICに明らかに抜けている"語彙の充実化"を
埋めるためのGREが何度も現れているのでしょう)
また、TOEICは世界的に見てもかなりベーシックなレベルのようです。
一般的にTOEIC800点(筆者は795点ですが...)はTOEICの高得点保持者、
というような認識をされるように思いますが、
1年前にその中国人にTOEICの公式テキストを数日間貸したところ、
「こういっちゃ悪いけれど、問題が単純過ぎてびっくりしたよ。
こんな問題が本当に試験に出たら中国の大学生は皆ほぼ満点を取れてしまうよ」
と言われて返されました。
(その後、「このテキストは公式が出している模擬テストだから難易度分量全部まんま
だぜ」と伝えたら苦笑いしてました (^^;
つまり、世界的なスコープで見たときに、TOEICが800点しか取れないというのは
英語がかなり不自由だと言われても仕方がないレベルだと考えられます
(実際、筆者もあらゆるシチュエーションでぺらぺら、
という訳にも行きませんし、確かにかなり不自由です。）
恐らくTOEIC700-800台の人にとっての残りの200-250点は
「複雑な構文の解読」や「マイナーな語彙の適切な選択」、
および「短時間での適切な選択」であるはずなので、
TOEICでより高得点を目指したい場合でも、早めに中国人の彼の言う勉強法に
切り替えたほうが効率がいいのかな、なんて思いました。
これからは、TOEICの本を読み漁ることはやめて、
当面はGREの勉強にシフトして英語の学習を進めてみようかなと思います。
また何か進展や気付いたことがあればこちらに書きます。
"4時間半熟睡法" についてマインドマップにまとめた
昔読んだ本なのですが、最近ふと読んでみて意外と守れていない事が多いなと感じたので
復習の意味も込めてマインドマップ化してみました。
- 作者: 遠藤拓郎
- 出版社/メーカー: フォレスト出版
- 発売日: 2009/06/19
- メディア: 単行本（ソフトカバー）
- 購入: 17人 クリック: 133回
- この商品を含むブログ (53件) を見る
”How to Sleep Better”の内容をマインドマップでまとめた
最近寝付きが悪くなってきたので、
こちらのサイトに載っている内容をマインドマップでまとめてみました。
http://www.helpguide.org/life/sleep_tips.htm
内容的にはそれほど目新しいものではなく、
健康番組とかでよくあるような内容のものばかりですが、
基礎の再確認として役に立つかもしれません。
前回同様、覚書のお役に立てれば嬉しいです。
ポモドーロ・テクニックの覚書をマインドマップで書いた
最近、ポモドーロ・テクニックという時間管理術を知りました。
イタリアの大学生が自分の勉強を効率化する為に開発したものらしいのですが、
アジャイル開発でも良く使われるTime-boxing手法が使われていたり、
脳科学者の茂木先生の推奨するタイムプレッシャー手法や
望ましい集中法、及び教育学者トニー・ブザンさんの提唱する
インターバルの理論などがふんだんに取り入れられていて
なかなか興味深いものでした。
●ポモドーロ・テクニックについて日本語で紹介しているサイト：
http://stack3.com/old/pomodoro_technique.html
http://bizmakoto.jp/bizid/articles/1003/23/news043.html
●ポモドーロ・テクニックを日本語で開設した書籍：
http://www.amazon.co.jp/%E3%82%A2%E3%82%B8%E3%83%A3%E3%82%A4%E3%83%AB%E3%81%AA%E6%99%82%E9%96%93%E7%AE%A1%E7%90%86%E8%A1%93-%E3%83%9D%E3%83%A2%E3%83%89%E3%83%BC%E3%83%AD%E3%83%86%E3%82%AF%E3%83%8B%E3%83%83%E3%82%AF%E5%85%A5%E9%96%80-Staffan-Noeteberg/dp/4048689525
●公式サイト（英語）
http://www.pomodorotechnique.com/book.html
今回は、公式サイトのPDFを読んで勉強し、ノートにまとめたものを
マインドマップ化したのでそれを公開します。
自分の覚書のために書いたものなので初見では意味不明だと思います。
上記の文章のうちいずれかに目を通し、全体の流れを覚えたら
覚書として使えるかも知れません。もしお役に立ちましたら嬉しいです。
PyConJPでGuido van Rossum氏と生電話させてもらってみた
今日はPythonistaの日本の祭典、PyConJPに行って参りました！
RubyKaigiの時と同様、様々な分野から優秀かつ気さくな方々が沢山来ていて、
また10名近い素敵なPythonista達との人脈を作る事ができました(^^)
全体的な雰囲気としては、RubyKaigiよりも学術的な雰囲気が強かった気がします。
あくまで俺個人の勝手な想像上の例えですが、RubyKaigiには大学のサークルでRubyをやっている
人がサークル活動の一環で来ているような感じの人達が多く、
本PyConJPではPythonを学術的な分野の一つとして捉えている院生のような人達
（大学院生のような雰囲気や素質、匂いを持っている人）が多く参加されていたように思えます。
ばったり会った初対面の人と「さっき○○について話していましたよね、あれは…」
というふうにすぐに打ち解けて話せる感じのイベントで、ホントに気兼ねなく話せてとても楽しかったです。
しかもその突発的な雑談の全てが高度で、日本のPythonista達のレベルの高さの片鱗を見た気がしました。
セッションも勿論ですが、イベント中のありとあらゆるシチュエーションで
総じて沢山勉強になるような時間でした。
今回のイベントで一番衝撃的＆感動的だったのは、
Pythonの父ことGuido van Rossum氏と生でテレビ電話ができたことです。
休憩スペースの所に「Guidoへの質問コーナー」のようなものがあり、
気になって近くに行ってみると、気さくなスタッフさんが俺に話しかけて下さいました。
スタッフさん「あ、質問しますか？」
俺「...え？どういう...すみません、ここは何のコーナーなんですか？」
スタッフさん「今Guidoと電話が繋がっていて、Guidoに直接質問ができるコーナーです」
俺「え？！Guidoさんとお話ができる..生で話せるんですか？！」
スタッフさん「ええ、そういうコーナーですから 笑」
周りの人と一緒に「英語はちょっとなー…」などと言いつつ、
でもGuidoさんと直接お話ができる機会なんてもう二度とないかも知れないし、と思い、
大恥をかくつもりでGuidoさんとの対談をお願いしました。
...Guidoさんは予想をはるかに超える程紳士的でクールな方でした。
俺(以下Ryo) 「こんにちはGuidoさん、私は大学院でインタプリタの研究をしている者です。特にJITコンパイラについての研究を行っています」
Guidoさん(以下Guido)「おお、とてもクールだね！よろしく。お話出来てうれしいよ。」
Ryo「私もとても嬉しいですし、こうしてあなたとお話しできるのが今でも信じられません。」
Guido「ハハハ、ありがとう！ JITコンパイラといったね？じゃあ君はPyPyを使った事があるかい？」
Ryo「！ 勿論です！PyPyの論文も読んでいますし、今その事について質問しようと思っていたところです！」
Guido「お、いいね！何だい？」
Ryo「GuidoさんはPyPyについてどう思われていますか？えぇとつまり...良い印象をお持ちなのでしょうか？」
Guido「勿論だよ。様々なPython実装が増えてくれることは私にとってとても嬉しいし、JITはとてもクールだ。
私はプロジェクトが進むのを楽しみにしている一人でもあるんだよ。」
Ryo「そうなんですか。Guidoさんは3.x系へメインストリームが移り変わる事を望んでいらっしゃると思ったので、
2.x系統しかサポートしていないPyPyによって3への移行がストップすることを懸念されていると思いました。」
Guido「いやいや、その時はPyPyが3.0に対応してくれるのを待つよ。そうなるだろうし、そうなるのが一番いい。」
Ryo「なるほど。ありがとうございます。Python3.0関係でもう一つお聞きしたいのですがいいですか？」
Guido「勿論。どうぞ。」
Ryo「ありがとうございます。えぇと、GuidoさんはPython3.0に世の中でのメインストリームになるまで何年かかると考えていますか？」
Guido「5年だよ。Python2.xの時だって、マイナーバージョン+1の度におよそ1年でメインストリームが移り変わってきた。
その傾向を見ると、今はPython3を使う人だって着実に増えているし、5年以内に3.0に移行するだろうと私は考えている。
Googleでも3に移行するつもりの人が殆どの筈だよ。」
Ryo「なるほど！つまりGoogleは5年以内にPython3xに移行するということですね！」
Guido「ハハハ,そう来たか！今のは私の完全な個人的な思想であって、Googleの構想や決定とは一切関係ない事を補足しておくよ。」
Ryo「分かってます、勿論分かってます（笑） では、後ろで待っている人がいるので変わります。お話、本当にありがとうございました！」
Guido「どういたしまして！研究(勉強)頑張ってね！」
Ryo「はい！ありがとうございました！」
...と、気になっていたPyPyプロジェクトやPython3の事についてGuidoさんの生の意見が聞けてしまいました。
本当、冗談抜きに、今日程曲がりなりにも英語を勉強しておいて良かったと思えた日はありません。
もうこういう機会はもしかすると訪れないかも知れないけれど、
もし、もう一度Guidoさんと話せる機会があれば、
今度はインタプリタの研究者としてもっと流暢な英語でより突っ込んだ事を話したい。本気でそう思いました。
今日からまた新しい気持ちで研究と英語の勉強に打ち込めそうです。
このような素晴らしい機会を与えて下さったPyConJP運営者の方々、
特にお誘いくださった上チケットまで譲って下さった @rokujyouhitoma さんに深くお礼を申し上げます。
本当にありがとうございました。
RubyKaigi1日目にPythonistaの俺が潜入してみた
俺はPythonistaでRubyはあまり気合を入れて勉強したことが無い浅学者なのですが、
色々な友人が参加するということと、丁度今大学で進めている研究
（インタプリタとかVMとかJITとかそっち）に関連した発表が
3,4個あるということ(と開催地が地元なので家からちょー近かったの）で、
この度Student Passでお邪魔して参りました。
当日の雰囲気：
例の中学生コミッタの子も発表していました。
俺が今迄発表したことのある学会ですら1セッション30人単位程度のものですから、
それを考えるとただただ凄いの一言でした...。
今回、技術面よりも、むしろ啓発的な意味での恩恵のほうが多く得られたかもしれません:-)
以下、興味のあった発表とそれに対する”俺なりの”感想か考察を。
[ Next version of Ruby 1.8 and 1.9 ]
CRubyコミッタの皆さんによる、次のCRubyに向けた実装を先行公開。
インタプリタのコア部分（C99?）からprivateなアトリビュートを指定する機能が
聴衆にはウケていた模様(private constantと呼ぶそうな)。
これを用いると言語のコア部分でメンバへのアクセス制限が可能となるらしい。
個人的には、インタプリタ言語でprivateを厳格に定めてもその恩恵が薄いのではと感じた。
アクセス指定子の本質はヒューマンエラーの防止の筈であって、
コンパイル時にアクセス違反を指摘するという使われ方が
最も適している、それを実行時にチェックしようということになると、
結局の所「private/protectedなメンバが外部から呼ばれる事によるバグ」
という稀なケースの"実行時アサーション"の自動化が可能になるだけでは？
どうなんだろう。あまり魅力を感じなかったので
周りのRubyist達が歓喜している理由が全然分からなかった。
後は、例の中学生コミッタが作ったUnitTestの並列実行化。
中学生にしては恐ろしい程発表の質と技術力が高かった。
ただ、欲を言えば、もう少し「根拠」の部分に多く興味を持って欲しかった。
発表中「2コアで計測したら2.7倍になりました！理由は他の人に評価を
投げたので分かりません」
とか、「1コアの場合では早くなる訳がないんでマルチコアのPCを使って下さい」
とかいう所があったんだけど、結局、「こうじゃないか」という考えを
「こうなった」という結果から「こうだったからこうなったんだ」という
エビデンスを得ない事には実際のところ何故その結果が現れたのかは
さっぱり分からないので、これらに対する考察を自身でやってみて欲しかった。
ちなみに質疑応答でもこれらのトピックにはきちんと議論が始まって
（これが発表のいい所ですね）、2コアで2倍より高い性能が出ているのは
各テストケースに生じるアイドル時間がスレッドのプリエンプションによって
埋まるからではないかという話だった。
（だから1コアでも早くなるのではないか、という考察）
でも実際はどのようなテストケースをどのようにマルチスレッド化したのかに
全く触れられていないから、ひょっとすると元のテストケースコードを
マルチスレッド化させる為に書き直したらそちらの方が効率がずば抜けて高かった、
という可能性も捨てきれないし、あとはHTが効いているんじゃないかとか、
（これはスリープやアイドルに入るのかも知れないけれど）I/Oの順番待ちを
しているスレッドをプリエンプションしたんじゃないかとか、
高速化した理由は沢山考えられる。
となると、「そもそもこの性能向上は並列化によってもたらされたものなのだろうか」
という点に疑問符が付く。やはりこういう発表を行う際には
どのような実験環境でどういう実験を行ったのかを明確にして、
その結果から仮説をバックアップするようなストーリーを聞かせて欲しい。
（まぁこの世界ではその点は後でソースコード読めよ、っていうのが常識なのだろうけど
[軽量Ruby]
経済産業省が絡んでいるらしい何気にスゴいプロジェクトのよう。
メモリ使用量の削減＋処理系のサイズの削減＝軽量Ruby とのこと。
中身はCRubyのサブセットで、携帯電話などの組み込み系アプリケーション向けの
軽量処理系。FPGAに持たせた機能をRubyから直接利用できる機能を
軽量Rubyの標準ライブラリとして提供するらしい。
Matzさんの軽量Rubyのアーキテクチャのスライドを見た限りだと、
軽量Ruby用コードを軽量Ruby VM用のBCへコンパイルして使うらしい。
（勘違いしてるかも）
となると、雰囲気的にはJavaのアーキテクチャと似てくるのだろうか。
（組み込み系ならしょうがないか、という気もするけど..。）
[CRubyGCの並列世界]
マーク&スイープ方式のGCで、
マークの部分をdequeを用いて並列化してみましたというお話。
冒頭でGC = Grief sheed Collectionだと発表者は主張。
ってことはRubyにはキュウべぇが載っているのか。
発表での"dequeのpushとpopは要素が2個以上であれば競合しない"
という部分が凄く引っかかった。
発表では競合についてかなり丁寧に解説していたのにdequeのatomicityについて
一切触れていなかった（ように思えた）が、
少なくともC++のstd::dequeはatomicではないし、
Intel TBBでもatomicityの保証されたdequeは提供されていない。
「まだSEGVが度々起こるバグが取れていない」と言っていたのも
この辺りが盲点になっているのではないだろうか
（と思ってしまうのはちょい短絡的かな）。
（とは言っても C++を使っているともSTLのdequeを使っているとも言っていなかった
ので、自身でdequeを実装された可能性も大アリだが）
C++のdequeは確か固定長の配列で実装されていた筈なので、
場合によってはpushの呼び出しでメモリが総出でお引っ越しする可能性もある。
そこにatomicityがないのだから、同時に呼ばれたらヘタすりゃSEGVる筈。
この事を発表者に質問したかったのだが、あいにく時間が押していたので
質問が1件だけに制限され、その1件にこの質問はちょっとどうかな、と
もじもじしていたら、結局、only oneの質問は前列にいた人の
「まどかマギカのネタについて教えて下さい！」
というハートフルな質問で締めくくられましたとさ！
お前ら大好き！
