おおよそ日報のようなもの。 昨日は研究のための環境を整備したり、TOEICの結果を受け取りに行ったり、本を読んだり映画を見たりしていた。
研究の環境としてOpenWrtというのを使おうとしている。これはLinuxカーネルが動くルータ向けのファームウェアで、なかなか面白い。ファームウェアは特にハードウェアの制御において重要な役割を持っているソフトだが、OpenWrtの場合はかなり高いレイヤについてもインタフェースも備えており、ルータをまさしくLinuxコンピュータのように扱うことができる。このOSに習熟することで、ルータという非常にコンパクトなコンピュータシステムをハックすることが可能であり、これによってかなりコンピュータの知識を底上げできるのではないかという期待感が湧き立っている。ちょっと研究が楽しくなってきたかもしれない
おおよそ日報のようなもの。昨日は大学生協が主催しているTOEICを受験してきた。大学生協が主催しているといっても、テスト形式自体は公式の公開試験と同じものである。リスニング45分、リーディング75分の形式。問題の漏洩はまずいので、内容自体には言及しない。
試験会場入りは朝の9時半くらいで、着席時間は10時だった。着席時間から試験開始まで30分くらいの待ち時間があった。すでに机の上も片付けるように指示されているから、この30分は本当の意味での待ち時間となっている。自分は半月前くらいから瞑想の練習を真面目にするようになったが、昨日のこの待ち時間がこの半月の中で最も質のよい瞑想ができた。試験開始前くらいにはかつてなかったレベルの、非常に穏やかな精神状態になっていた。
試験はリスニングから始まる。手応え的にはリスニングの方は想像よりもできた感じがするのに対して、リーディングについては思ったよりもできなかったという感想だった。事前のデモンストレーションが足りていなかったので、時間配分や急いでやる場所と時間をかける箇所の緩急がよくわからなかった。結果としては時間が足りなくなって、最後の15問くらいを塗り絵することになってしまった。リーディングは持ち時間75分に対して問題が100問くらいあるので、前半の文章の補完問題をいかに早く終わらせるかが重要になる。試験の最後の30分くらいは資料読解をすごく頑張って、１分１問くらいのペースを保っていたが、全体に渡ってもこのペースだったので75分で８０問程度しか解けないのはある意味当たり前なのである。前半の問題を例えば1分３問くらいのペースで片していたら、後半に多少は余裕が生まれるのだろうと思う。スコアはどれくらいか、少なくとも500は越えていて欲しいところだが、よくわからない。返ってくるまでは記憶から忘却して待ちたいと思う。
ただ、スコアを抜きにして全体としての体験を考えると、なかなかよい感じだった。土曜の午前中に集中して何かに取り組むというのはなかなか爽快なものである。
おおよそ日報のようなもの。週末に一度TOIECを受けようと思っているので昨日は公式問題集を解いたりしていた。今回の受験ではスコアはそこまで重要でないのだが、どれくらいになるのか気になる。周囲の様子を見ていると、とりあえず目標は600くらいで設定するのが堅実な気がする。自分のTOEICスコアがどれくらいなのか知らないので、600がどれくらいの難度なのかわからない。話に聞いたところによると700代半取るとまぁ良いのではないか、というくらいらしいので、とりあえず600点を取れるくらいだったら、追加勉強次第でなんとか研究生活をやり過ごせそうな感じがする。試験が近づいてきて、4xx点とか5xx点とか取っちゃったらどうしようという不安も高まっているが、ここは徹底的受容というのを思い出して、もしもそう言った点数を取ってしまったら取ってしまった時でまた勉強すれば良いのだ、と考えることにした。筆記試験に持っていく書類はともかくとして、TOEICは何度も繰り返し受けられるので、点数向上を目指して今後何回か継続的に受けていきたいところではある。研究室内で定期的にTOEICの模試を解く文化というかイベントみたいなのを作ったらどうですかね、みたいなことを言ってみたら常駐の面子はかなり肯定的だったので、今後は研究室でも定期的にTOEICの練習をすることになるかもしれない。研究室は日中は割とガヤガヤしていて、試験を受ける環境としてはあまり適していないが、そう言った中でも解けるように練習をすることで、集中力と注意力の訓練にもなるのではないかと思う。
メモ：珍しく夜まで研究室に残ってみたら、終盤かなり雑談が盛り上がって楽しい感じだった。いつもいつも残って作業というのは、ちょっと考えものだが、たまに残ってみるのはいいかも。
おおよそ日報のようなもの。大学でグループワークをする機会が結構な頻度であるのだが、基本的に失敗する。いくつか原因があるのだが、大学の講義特有の事情を排除して最も一般的な要因を抽出すると、互いを見知らない状態でグループワークが進行するから、ということになるだろうと思う。おそらくグループ・ディスカッションとかのレベルだったら互いをみしらなくてもある程度の水準くらいには達すると思うが、成果を作るところまでやる必要があるグループワークとなると事情が変わってくる。まずは成果を作るために相当量の仕事量が発生するので、その期間中グループメンバーをその仕事に拘束する必要がある。そして、実際に形にする段階で、これまで考えてきたアイデアに曖昧性があったのだと気づくシーンも多くある。グループメンバーのモチベーションや知識量にも違いがある。プロジェクトが長期的になればなるほど、それは顕著に響いてくる。チームメンバーに何かをやらせる、とか、きちんと話し合いをする、お互いの作業状況を把握する、とかそういうことが簡単にできるグループであればうまくいく率は高いと感じているが、そのためにはチームメンバー同士がある程度以上見知った状態でなくてはならない。大学のグループワークではあまりそういうのは期待できない。
大学に限らず、どこでもこういう問題は起きていると思う。伝達ミス、理解の齟齬などが原因となっているミスがよくニュースになっているが、見知らない人間同士が集まってうまく仕事をするということ自体、困難が伴うことなのだろうと思う。
"vice versa"って聞き慣れないイディオムだなぁ。”逆もまた”という意味らしい。見かけたのはThe Guile Reference Manualの冒頭で、文章が
"It is easy to call Scheme code from C code and vice versa, giving the application designer full control of how and when to invoke the interpreter."
のような感じ。あえて日本語訳するとすれば、
「SchemeのコードはCのコードから簡単にコールすることができ、その逆も可能です。このことはアプリケーションのデザイナーにいつ、どのようにインタープリターを呼び出すかについての完全な制御を与えます。」
のような具合だろうか。
夜型人間は英語でなんと書けばよいのか迷ったのだが
夜型人間 -> a night person
昼型人間 -> a day person
でいいらしい。ちなみに朝型の場合は a morning person
なんかそのまんまだなｗ
〜型っていうので a type of ~ とか ~ oriented とか言いそうだと思ったけど、もっと単純だった。でも単純なほうが良いですね
思えばなんでもかんでも〜型、〜的とかつけるたがるのは日本語の悪いクセかもしれない
