全く勉強せずにTOEICで720点取った話

Reading/Listening の点数です。大したことないのかもしれないですが、勉強せずに720点というのはある意味化け物だと聞いたので、思い当たることを書きます。

前提

  • もともと英語は嫌いじゃなかったし、得意な方ではあった。
  • 小学校からパソコンでプログラミングをやっていて、英語の命令やエラーメッセージに触れていた。
  • 英検は3級。2級は落ちた(高校時代の話)
  • TOEICで良い点を取ろうと思ったのではなく、あくまで自分の実力を試すつもりだった。

心がけたこと

  • 海外の映画は字幕のものを観る
  • 好きなこと(私の場合、プログラミングやルービックキューブ)に関しては、英語で調べ、英語の文献を読み、英語の動画で学ぶ。
    • 好きなことを幅広いソースから学べ、英語にも慣れられるという一石二鳥
    • 最初はつらい。知らない単語が出てきたら、辞書アプリや辞書サイトですぐに調べる。
    • 英語で検索しようとすることにより、単語力がついたと思う

これを数年続けただけ。
おすすめです。

魔法少女まどか☆マギカ 新編 叛逆の物語 個人的な感想 軽いネタバレあり

朝から飲まず食わずで観たせいか、いまいち展開が頭に入ってこなかった。ドラゴンボールのように、概念がインフレを起こしている。ストーリー的にはもっとシンプルでわかりやすく心にガツンと来るのが好みである。
声優の名演技とか素晴らしい音楽によって涙腺が緩むポイントはいくつかあったし、映像は終始とても素晴らしいものだった。まどマギのキャラクターに思い入れがある人なら堪らないというシーンが多数あったように思う。変身のシーン、とくにさやかのはかっこよかった。

パチスロ 設定不問で勝てる理論(天井狙い編)を簡単に説明してみる。

パチスロ屋は、1台あたり1日5,000円くらいの利益が出るように設定しているといわれている。1日あたりの1台の稼働を5,000回転とすると、800回転あたり800円の利益ということになる(ここで800回転としたのは、1時間ぶん回した場合の回転数がだいたい800だから)。すなわち、何も考えないでぶん回すと時速800円で負けることになる。これはあくまで平均値であり、1時間あたりの客の収支は実際には-26,000円〜+48,000円あたりのばらつきがある。

要は、普通に打つより1時間あたり800円≒40枚の上乗せをするよう努力すればよい。
現実的には時速100枚くらい欲しいので、さらに100枚、計140枚毎時の上乗せがあれば十分である。
具体的な上乗せの方法だが、最低限、小役は全部取ること。押し順ミスはしないこと。これだけで毎時10枚くらいは差をつけられるだろう。しかしこれでは全然足りない。

上乗せのメインは「打ち始め」と「止め時」である。5号機の特に ART 機と呼ばれるものは、天井と呼ばれる機能があり、どんなに遠くても1,500回転も回せば何らかの救済的な当たりが来るようになっている。早い話が、天井に少しでも近い台を、必ず「当たるまで」打つ。結果として天井を考慮しない打ち手より数多くのボーナスを引くことができ、これこそが毎時100枚以上の上乗せを可能にしている(計算したわけではないが、実際の自分の収支からの逆算である)。これにはボーダーが存在し、天井まで残り何ゲームからプラスになるかは各種雑誌で情報を得ることができる。しかしそれも後述の「止め時」を厳守した場合のみ有効である。

私が最も重要視するのが「止め時」である。スロットは機種ごとに適切な止め時(ゲーム数)というものが存在する。しかし最適な止め時を算出するのは至難の業なので、これも雑誌等から妥当なラインの情報を収集する。また、台の状態によっても変化するので、それを察知する努力も怠らない。概ね100Gほどに設定されている台が多い。これを厳守する。理想的には、片手で収まるような残り少ないコインを打ち込んだり根拠のないジャグラーを回したり煙草に交換したり誰かにあげたりするのではなく、1枚残らず会員カードなどに貯玉する。逆にチャンス役などを引いて良い状態になったら、躊躇せず買い足しを行う。
この打ち方は大抵1回のボーナスで終了するので、数をこなす必要がある。それだけに、シビアな止め時が求められる。誤差が何倍にもなってくるからだ。このやり方はたかだか時速100枚しか稼げないのだから。

以上を2年間徹底した結果が下記のグラフである。自分はいわゆるサラスロタイプで、短時間勝負が多く、打たない期間も多い。それでも、1ヶ月単位で負けることもあるものの、平均して104%以上の機械割となっている。これだけの結果が出ているのだから上記の戦略は正しいと自信を持っているところもある。

処理Aと処理Bはどっちを先にやってもいいにも関わらず、テキストファイルではどちらかを先に書かなければならず、読み手にとってその情報はノイズでしかないので、順序の情報を曖昧にするために2次元以上の空間にプログラムを書きたいと常々思っている。

エヴァQ感想ネタバレあり

いつぞや Twitter で「エヴァはオワコン」といったツイートを見かけたこともあり、私自身そう思いかけていたが、観終わってみればそんな気持ちは吹っ飛んだ。きっちり時代に追随していると感じたし、映像作品としてのクオリティも極めて高いと感じた。
嬉しかったのは、観客を舐めていないと感じたところ。私は正直さっぱり理解できなかったが、あの様々な言葉たちが無意味なものであるはずはなく、根底にある物語にあくまで忠実に描かれていると感じた。初心者には意味不明かもという無粋な配慮は全く見受けられない。
そして常識にとらわれない使徒のデザイン。自然に存在する幾何学的なものの怖さを表現したかのようなあれにはいつも興奮させられる。
シンジとカヲルのBL表現はあまりにも直球過ぎて笑ってしまった。
後半になるにつれ、ああ、意外とオリジナルのストーリーからまだ大きく離れてないんだと感じた。しっかりエヴァだった。それでも序盤のあの展開は観客を掴むのには十分なインパクトがあった。
マリのマイペースっぷり、そしてアスカのツンデレっぷりが素敵だった。

おおかみこどもの雨と雪 ただの感想 ネタバレあり

公開初日に観た映画はこれが初めて。意外とゆったりと観られた。

全体的にあっさりしていて、刺激やカタルシスを求める人は物足りなく感じるんじゃないかと思うし、自分自身これで終わりなのかとすこし残念に思ったくらい。

グッときたポイントは3箇所ほどあった。一つめは本当に何気ない場面で、説明することもないほどの場面だった気がする。親子3人で何気なく過ごしてるような場面で、音楽だけがながれているような。

あとの2つはラストに集中する。狼であることを告白する雪に対し、草平が既に知っていたという場面と、雨が親元を離れて狼として咆哮するシーンである。

むしろ見どころは日常のリアルな描き方と美しい映像かもしれない。経験した人ならわかるヒヤッとするシーンが多い。小学生の「やっぱり」というセリフなど、痛々しい子供時代を嫌でも思い出す。

幼少期は雪が狼としての生き方を謳歌していただけに、その後とのギャップがまた痛々しい。

意外と、古き良き映画の記号を多用しているようにも思われた。すぐ思い浮かぶのは、笑うなといっても笑ってしまう花や、亡き夫のところへ行きかけるも、「雨がいないの」と言って一命をとりとめたり。

映画のテーマは何かと言われれば、それは公式サイトのイントロダクションに書いてあるとおり、子育ての映画としか言いようがない。ただそれを忠実に描くだけで良かったのであり、それこそが難しいかっとのだと思う。アニメはそれにちょっと味付けできる。

雪山のシーンはトレイラーのために作られたとしか思えず、あの印象で観るのを躊躇っている人は観たほうがいい。とはいえ映像作品としても本当に素晴らしいと思う。目にも耳にも楽しい。

子供ができたらまた観たいし、観せたい作品。

sbt android plugin でテストできなかった件

はじめに

sbt android plugin とは、ScalaAndroid アプリを書くための素敵な方法だと聞き、特に考えもなく、どちらも経験が浅いのに、手を出しました。
最初のアプリは大した問題もなく、スムーズにリリースできました。しかし、機能追加に伴い、テストを書きたい、となったときに、この android plugin がサポートしている tests サブプロジェクトがうまく動きませんでした。

再現

https://github.com/jberkel/android-plugin/wiki/getting-started を参考に、プロジェクトを作成します。再現のためにすべてデフォルトを選択しました。

$ brew install giter8
$ g8 jberkel/android-app

Template for Android apps in Scala 

package [my.android.project]: 
name [My Android Project]: 
main_activity [MainActivity]: 
scala_version [2.9.1]: 
api_level [10]: 
useProguard [true]: 

Applied jberkel/android-app.g8 in my-android-project

プロジェクトディレクトリに移動して、sbt を起動し、パッケージを作ります。sbt は HomeBrew などでインストールしておいてください。

$ cd my-android-project
$ export ANDROID_HOME=/Applications/android-sdk-macosx
$ sbt

>android:package-debug

エミュレータを起動します。

> android:emulator-start my_avd
> android:start-emulator

問題なくサンプルプロジェクトが起動します。

テストプロジェクトの存在を知る

giter8 で作られたサンプルプロジェクトには、「tests」というサブプロジェクトが含まれています。https://github.com/jberkel/android-plugin/wiki/Building-Android-Test-Projects を参考に実行してみましょう。

> android:package-debug
> android:install-emulator
> tests/android:package-debug
> tests/android:install-emulator
> tests/android:test-emulator

このようになります。

[info] 
[info] my.android.project.tests.ActivityTests:INSTRUMENTATION_RESULT: shortMsg=java.lang.IllegalAccessError
[info] INSTRUMENTATION_RESULT: longMsg=java.lang.IllegalAccessError: Class ref in pre-verified class resolved to unexpected implementation
[info] INSTRUMENTATION_CODE: 0
[success] Total time: 3 s, completed 2012/04/11 16:59:14

何が success だ、と言いたくなります。
ddms でログなどを見た結果、JavaScala もにわかな私の認識では、TypedResource などのクラスの解決がうまくいっていない、といったところでした。

打開

5日ほど試行錯誤したのですが、何とかテストを実行させられた手順が以下になります。

まず android plugin に手をいれるので github から落としてくる。

$ cd ..
$ git clone git://github.com/jberkel/android-plugin.git
$ cd android-plugin

AndroidInstall.scala を編集(対象コミットは 6f6e4b9)

--- a/src/main/scala/AndroidInstall.scala
+++ b/src/main/scala/AndroidInstall.scala
@@ -69,8 +69,7 @@ object AndroidInstall {
      classesMinJarPath, libraryJarPath, manifestPackage, proguardOption) =>
       if (useProguard) {
           val optimizationOptions = if (proguardOptimizations.isEmpty) Seq("-dontoptimize") else proguardOptimizations
-          val manifestr = List("!META-INF/MANIFEST.MF", "R.class", "R$*.class",
-                               "TR.class", "TR$.class", "library.properties")
+          val manifestr = List("!META-INF/MANIFEST.MF", "library.properties")
           val sep = JFile.pathSeparator
           val inJars = ("\"" + classDirectory.absolutePath + "\"") +:
                        proguardInJars.map("\""+_+"\""+manifestr.mkString("(", ",!**/", ")"))

72行目あたり、manifestr から "R.class", "R$*.class", "TR.class", "TR$.class" を削除します。このへんは ProGuard という機構の設定をしているようです。

編集したら、publish-local します。

$ sbt publish-local

サンプルプロジェクトに戻り、project/plugins.sbt を編集します。

--- a/project/plugins.sbt
+++ b/project/plugins.sbt
@@ -1,3 +1,3 @@
 resolvers += Resolver.url("scalasbt releases", new URL("http://scalasbt.artifactoryonline.com/scalasbt/sbt-plugin-releases"))(Resolver.ivyStylePatterns)
 
-addSbtPlugin("org.scala-sbt" % "sbt-android-plugin" % "0.6.1")
+addSbtPlugin("org.scala-sbt" % "sbt-android-plugin" % "0.6.2-SNAPSHOT")

sbt-android-plugin のバージョンを 0.6.2-SNAPSHOT に変えることで、さっき編集したバージョンを読みにいかせます(この説明は自信がない…)。

編集したら、もう一度テストを実行します。

> reload
> clean
> tests/clean
> android:package-debug
> android:install-emulator
> tests/android:package-debug
> tests/android:install-emulator
> tests/android:test-emulator

今度はうまくいくはず。

[info] 
[info] my.android.project.tests.ActivityTests:.
[info] my.android.project.tests.AndroidTests:..
[info] Test results for InstrumentationTestRunner=...
[info] Time: 1.509
[info] 
[info] OK (3 tests)
[info] 
[info] 
[success] Total time: 4 s, completed 2012/04/11 17:25:30

結論

正直、このやり方でいいのかわかりません。何しろ ScalaJava も sbt もにわかなので(だからこそ5日も悩みました)。私的には、AndroidInstall.scala を上記のように編集したことで、管理されたソースである TR.scala がうまく tests プロジェクトに対してエクスポートされたのでは、と考えています。
間違った知識を流布してもいけないので、おかしなところはご指摘いただけると幸いです。