第51回情報科学若手の会に参加してきました
毎年9月頃に開かれている情報科学若手の会というイベントがあって、その名前の通り若手と呼ばれる人たちが同じ場所に集まり数日間ディスカッションを交わしたり交流をする場があります。
実際にはディスカッションという堅苦しいものよりかは雑談に近い感じで、Webサイトにもある通りインフォーマルな雰囲気が特徴となっています。
僕はこの会に参加するのは3回目なのですが、実をいうと今まで一度もブログを書いてませんでした。すみません。
会の詳しい内容については他の参加者や幹事の方が数人ブログを書いてくださっているようです。
情報科学若手の会 #51 に参加してきた | κeenのHappy Hacκing Blog
例年は山喜旅館という静岡県伊東にあるレトロなところで開催しているのですが、今年はいろいろな事情があって軽井沢にある軽井沢研修所というところで開催されました。
避暑地と呼ばれるだけあってやはり軽井沢は涼しくていいですね。朝に適当に付近を散歩していましたが、なかなかに快適でした。
この軽井沢研修所、公益財団法人 加藤山崎教育基金によって運営されているそうで、研修所の敷地内には広大な植物園があったりとなかなか「お金の力」を感じる場所でした。
http://www.kato-karuizawa.jp/pdf/map05.pdf
僕は実際に見ていないのですが、他の参加者によると近くで温泉を掘っていた、なんてこともあったそうです。すごいですね。
じつはこの研修所、天皇陛下も訪れるようで、施設案内には乗っていない謎の部屋があったりしましたがどうやら本当のようですね。
天皇皇后両陛下のご日程:平成30年(7月~9月) - 宮内庁
ご挨拶,少時ご歓談(長野県知事,県議会議長,県警察本部長)
とあるのであの謎の部屋を使ってご歓談されるのかと存じます。
セッションの方は面白い発表が多く、一番印象に残ったのはやはりコンテナデータセンタの話でした。「コンテナ即売会」「おっさんレンタル」などのパワーワードに加えて、法律や税金などの問題や実際の作業風景に詳しく言及されていて大変面白い発表でした。世界でも類を見ないトピックなので海外の人の反応はどうなんだろう、と思ったら意外にも英文記事になっていませんでした。少なくとも会場の反応は、質問時に「自分もコンテナデータセンタ欲しくなったんですが」と始める人が多く現れて大人気でした。
他にも面白い発表が多くて、「Lispはすごい」ということがわかりました。Lispはすごいですね。
久しぶりにntddkに会いました。彼の発表 The Art of De-obfuscation は部分的にしか知らなかったことが綺麗に組み立てられていく感じでとても良かったです。Program Synthesisあたりの話は詳しい実装を読んだことがなかったのでなるほど、となりました。
一応僕もショートで「CTFと現実世界」というタイトルで発表をしてきました。
CTFはあくまでも競技だけど、現実世界のバグとの関わりや実際の研究成果が深く影響する場でもあるという主張です。
この手の話はそもそも最新の情報を知っている人がかなり少ない(実際のCTFプレイヤーくらい)ので、今回発表しました。感想や意見などお待ちしております。
ちなみに今回は幹事の一人であるkyontanの車に5人で乗って移動していました。蕎麦やステーキを食べられたし温泉も入れたしで最高でした。しばらく日本にいなかったこともあって少し感動しました。車の手配・運転をしてくれたkyontanにこの場を借りてお礼を。ありがとうございました。
今年も楽しかったので来年も参加したいですね。幹事の皆さま本当にありがとうございました。
CTFの問題を作るときに気をつけること
たまにポエムっぽい記事を書きたくなることがあるんですけど、今回はそういう回です。長いので結論だけ知りたい人はこちらへどうぞ。
CTFブームもここ数年の話ではなくなり、日本でもCTF開催側にチャレンジするチームや会社などが増えてきました。TokyoWesternsを結成して本格的にCTFを始めた2014年終わり頃に比べると、世界的にも日本的にもその数はだいぶ増えたんじゃないかなと思います。日本に限った話で言えば、やはりSECCONをベースとした団体の貢献が多いのは言うまでもないでしょう。Twitterのbioに「CTF」というワードを追加している人の数もかなり増えてきたように思います。
さて、こうした中で多くのCTFを経験すると「問題の質」というのがなんとなくわかるようになってきます。日本のCTFだけだと正直なところまだまだ数が少ないので難しいですが、海外で開かれている多くのCTFに参加するとなんとなく良い問題とそうでない問題がわかるようになってくると思います。そして、CTFを開催する時は「そうでない問題」側に取られてしまう問題の数をなるべく減らしたい、できれば0になるように努力します。
では一体どのような問題が「良い問題」とされるのでしょうか?(ここでは「CTFは現実世界で役に立つ・立たない問題」を議論する気はなくて、そういうのを期待している人は別のところでやってください。)
これについては正直なところ個人の価値観に大きく依存すると思いますが、なるべく一般論として言える(と僕は思っている)ポイントについて言及します。(これは自戒の念も込めて、多くのブーメランを含んでいます)
パズル要素がある
まず一番重要かつ難しいポイントです。我々は基本的には「ハッカー」という、創意工夫によって面白いなにかを達成することが好きな生き物ですから、解法が自明でないことが求められます。この解法が自明足るか否かは参加者によるところが大きくて、多くにとって非自明であればあるほどその問題は難しいと言えます。もし他のCTFで同様のものが出題されている場合はいわゆる「既出」と言われ、そのCTFに参加した人にとっては自明・簡単になります。逆に言えば、より多くのCTFに参加し解法パターンの引き出しを増やすことで、より多くの問題を解けるようになるということです。大学入試とかと同じ原理です。
このパズル要素を適度に含めるのは非常に難しくて、自明でない要素を考えつくには自明な要素をなるべく多く知っている必要があるからです。「CTFに参加したことがない運営が良い問題を作るのは難しい」と言われる所以だと僕は思っています。
本質から外れた妨害要素を入れない
問題を作る上でよく勘違いする人が多いのですが、難しいから良い問題、多くのチームに解かれなかったから良い問題というわけではありません。
たとえばpwnableやreversingの問題があったとして、PowerPCアーキテクチャとか出てきたらうんざりします。なぜうんざりするかというと、「PowerPCは今では一般的ではない」からです。その問題がもしPowerPCの特徴に関連した、あるいは実際にPowerPCで動いていた何かを模して作られたというのならばまだ良いのですが、単純に解析やエクスプロイトを面倒にする目的でそのようなアーキテクチャを選択するのは避けるべきです。もちろんこれはPowerPCに限ったことではなくて、思考停止してVMProtectを噛ませるとかそういうのも含みます。本質的でないところで時間を溶かすのはプレイヤーにとって非常に悪い体験ですし、なにより作問者がその問題の本質部分に自信がないことの現れです。もし作問者が、プレイヤーがこの妨害を突破することにも意味があると考えているならば、突破した時点で部分点を与えるべきでしょう。部分点がない場合は、途中のチェックポイントを通過していようがいまいが解けてなければ0点です。
問題の使い回しをしない
一番やってはいけないことです。CTFの問題を作るというのは非常に大変な作業ですが、埋め合わせのために過去問を適当に変えて出すというのは禁じ手です。少し手を加えるだけで解法が異なってくるような場合はハッカー心をくすぐられて大いに歓迎されますが、例えばプログラミング系の問題でパラメータを適当に変更しただけとか、そういうのは非常に嫌がられます。
なぜかというと、過去問は既にある程度問題を理解しているチームが存在するためです。そのようなチームは過去のコードを再利用しないはずがなくて、これは大きなハンデになってしまいます。有利になったチームは「ラッキー」くらいにしか思いませんが、不利になったチームからすると相手がチートしたときくらい悔しい思いをするでしょう。もちろんこの場合は運営に責任がありますが。
「面白くない」要素が可能な限り排除されている
できれば問題はなるべく楽しく解きたいものです。もちろん何が楽しい・楽しくないかは個人にもよると思いますが、少なくとも無意味な作業は誰だってやりたくないでしょう。
例えばパスワード辞書を使ってブルートフォースをするとログインできて、そこから問題が始まりますみたいなのは最悪です。adminは適当なパスワードを使っているらしいみたいな文言があればまだマシですが、そう言った文脈を一切抜きに辞書攻撃を求めるのはもってのほかです。パスワード辞書なんて正直無限にありますし、片っ端から試せばサーバに負荷もかかります。CTFはペネトレーションテストではありません。どうしてもそういう問題を出したいのならば、参加者数を限定した状態で、相当のスペックのサーバを用意すべきでしょう。もっともそのような環境が用意できたとしても僕は出題したいとは絶対に思いませんが。
他には .index.php.swp
などの典型的なURL予測も含まれると思いますが、これは僕が過去にやってしまったので強い言及は避けます。
解いたときに達成感が得られる
CTFに熱中している人の多くは、「問題を解いた時に得られる達成感が忘れられない」と言います。この達成感は問題を解いたこと自体もそうですが、問題を解く過程における試行錯誤の一つ一つが積み重なって最終的な解を導き出した、という体験を多く含んでいると思います。この試行錯誤の過程が長ければ長いほど問題は難しく感じ、また解けた時の達成感も大きいです。
では試行錯誤の過程をどうやって長くするかというと、
- パズル要素部分を難しくする
- 要素の数自体を増やす
という2種類の方法があります。
1は先に説明した通りで、なるべく典型ではない新規性のある要素が求められます。これは非常に難しいので、多くのCTFでは2の方法をよく見ます。
2は必ずしも良い方法ではなくて、単純に問題の組み合わせになっているだけ、みたいなのは避けるべきです。よく見かけるパターンの一つに「Webパートを解くとPwnパートが出てくる」といったものがありますが、例えばWebがインターフェースとなって呼び出しているバイナリをexploitする問題といった、何らかの関連性やストーリー性を持たせるべきでしょう(全く独立した2つの問題ならば最初から別々に出すべきです)。ただし各要素がそれなりの難易度を持っている場合、前述したように部分点を与えた方がよいです。
まとめ
少し長くなりましたが、完結にまとめると
- 運営するなら少しでもいいからCTFに出ろ
- どうでもいい要素を入れるな
- 使い回しをするな
- エスパーをやめろ(CTFはpentestではない)
- 単に要素をくっつけただけの問題は複合問題ではない
です。よろしくお願いします。
また、CTFを開催するときに気をつけるべきポイントについては、アメリカのPlaid Parliament of Pwning (PPP) というチームの良い資料がこちらにあるので、読んだことない人はぜひ一度目を通して見てください。
pip install --upgrade pip (10.0.0) 後の奇妙な挙動について
TL;DR
pipを10.0.0に更新した後に
~$ pip Traceback (most recent call last): File "/usr/bin/pip", line 9, in <module> from pip import main ImportError: cannot import name main
というエラーが出た場合の対処方法をこちらにまとめた。
こちらの記事で言及したが、pipの挙動がちょっとおかしい。少し調べてみたところ原因がわかったので共有する。一応概要も載せておく。
概要
debian9でaptでpipを導入したあとに pip install --upgrade pip
を行った場合、pipが使えなくなる。具体的には
~$ pip Traceback (most recent call last): File "/usr/bin/pip", line 9, in <module> from pip import main ImportError: cannot import name main
のようにエラーがでて、pipコマンドが使えなくなる。
また、python-pip
を消して手動でインストールしても pip install
でパッケージがインストールされない。debian9またはubuntu17.10を使用しているユーザーは特にハマりやすい。
原因
それぞれの現象の原因を詳しく示す。
ImportErrorの原因
aptでインストールした場合は9.0.1がインストールされるが、pipの最新版は10.0.0である (リリースされたのはつい先日のことである) 。
9系のpipスクリプトの内容は次のようになっている。
pipでインストールしたもの
#!/usr/bin/python # -*- coding: utf-8 -*- import re import sys from pip import main if __name__ == '__main__': sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0]) sys.exit(main())
aptでインストールしたもの
#!/usr/bin/python # GENERATED BY DEBIAN import sys # Run the main entry point, similarly to how setuptools does it, but because # we didn't install the actual entry point from setup.py, don't use the # pkg_resources API. from pip import main if __name__ == '__main__': sys.exit(main())
どちらも pip.main
をそのまま実行していることがわかる。またaptはpipのスクリプトをそのまま使うのではなく、ディストリビューション向けにカスタマイズされている。
次に pip install pip
で自動的にインストールされる最新版10.0.0のpipスクリプトの内容を見てみると、pip._internal.main
を実行していることがわかる。
#!/usr/bin/python # -*- coding: utf-8 -*- import re import sys from pip._internal import main if __name__ == '__main__': sys.argv[0] = re.sub(r'(-script\.pyw?|\.exe)?$', '', sys.argv[0]) sys.exit(main())
実際にpythonのライブラリが配置されているディレクトリ構造を確認してみると、明らかに構成が変わっていることがわかる。
9.0.1
~$ ls /usr/lib/python2.7/dist-packages/pip commands models req vcs basecommand.py baseparser.py cmdoptions.py download.py exceptions.py index.py __init__.py locations.py __main__.py pep425tags.py status_codes.py wheel.py compat operations utils _vendor basecommand.pyc baseparser.pyc cmdoptions.pyc download.pyc exceptions.pyc index.pyc __init__.pyc locations.pyc __main__.pyc pep425tags.pyc status_codes.pyc wheel.pyc
10.0.0
~$ ls .local/lib/python2.7/site-packages/pip _internal _vendor __init__.py __init__.pyc __main__.py __main__.pyc
これに加えてpythonのライブラリが参照されるパスの順序は、$HOME/.local/lib/python2.7/site-packages
の方が /usr/lib/python2.7/dist-packages
よりも優先度が高い。
~$ python -c 'import sys; print sys.path' ['', '/usr/lib/python2.7', '/usr/lib/python2.7/plat-x86_64-linux-gnu', '/usr/lib/python2.7/lib-tk', '/usr/lib/python2.7/lib-old', '/usr/lib/python2.7/lib-dynload', '/home/icchy/.local/lib/python2.7/site-packages', '/usr/local/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages', '/usr/lib/python2.7/dist-packages/gtk-2.0']
そのため、import pip
で参照されるpipは $HOME/.local/lib/python2.7/site-packages/pip
(10.0.0) を指している。しかしaptでpipがインストールされている場合、pipコマンドで実行されるスクリプトは先に示した通り pip.main
であり、これは10.0.0においては存在しない。
つまり最初の ImportError
はpip9を想定しているスクリプトがpip10のライブラリを使おうとしたことによって発生したものである。
この問題についてのissueは上がっているのだが、メンテナーの考えとしては 「_internal
に全ての機能を移動させたのにはそれなりの理由があって、pip.main
はpip10では絶対にサポートしない」というものらしい。
おそらくディストリビューションのパッケージ更新によってpipスクリプトがアップデートされるのを待つしかないと思う。もちろん先に自分でpipスクリプトに手を加えて、pip._internal
を使うようにするのはアリだとは思う。
pip installが動かない原因
まずDebian9 (stretch), Ubuntu 17.10 (artful) 以降の python-pip
パッケージは 9.0.1-2
である。
python-pip 9.0.1-2からパッケージのsourceを取得して展開してみると、debian/patches/set_user_default.patch
という名前のパッチが存在し、パッチの説明には以下のような記述がある。
When running as a normal user in a non-virtual environment, default to --user and --ignore-installed. When inside virtual environments or when running as root, keep the default behavior.
つまりvirtualenv環境下でない場合は、デフォルトで --user
フラグ ($HOME/.local/ 以下にインストールするオプション) を追加する。これにより、このバージョンの python-pip
を使用していると pip install
がほとんど成功するようになるため1 、sudoをつけずともインストールされるのが当たり前という感覚になってしまう。
一方pip10ではinstall時にverbosity levelを2以上 (-vv
) にしないとエラーメッセージが見えなくなった。これはバグと認識されていて、どうやら返り値のチェックを EACCES
ではなく EPERM
にしてしまったことが原因らしい。
そのため、aptの python-pip 9.0.1-2 ユーザーがpip10を使うと pip install
はいつも通り --user
で実行されたものだと勘違いしてしまい、エラーメッセージも特に出ないのでパッケージがインストールされたように見えてしまうわけである。もちろんよくメッセージを見ると Successfully installed [package名]
というメッセージが最後に出ていないので、インストールが正常に終わっていないことがわかるのだがまあなかなか気づきにくいと思う。
解決策
これらに対していくつかの解決策を考えた。
pip9を使い続ける
システムのpipに手を加えるのは少々危険が伴う。もし既存のパッケージに一切影響を与えたくないならば、pip9をそのまま使い続けるのが一つの手である。
set_user_default.patch
が当たってるパッケージを使っている場合、もし pip install pip
を実行してしまうと $HOME/.local/lib
にpip10.0.0がインストールされてしまうため、例のバージョン違いによってpipが起動しなくなる。この場合は pip install pip==9.0.1
などを実行してインポートされるpipパッケージのバージョンを揃えておくと良い。
pip10に乗り換える
aptの python-pip
を消して、/usr/local/bin/pip
にpipをインストールする。pip10のバグによりインストール失敗のメッセージが見えなくなってしまうが、alias pip='pip -vv'
とでもしておくか、普段から気をつければまあ問題はない。
python-pip
で入れたpipでインストールするのはなるべく避けた方が良くて、公式が推奨しているget-pip.pyを使うのがよい。先ほど述べたようにインストール失敗のメッセージが出ない上に、本来pipはデフォルトのインストール先に /usr/local/
以下を使うので、システムにインストールする場合はsudoをつけるのを忘れないようにする。もちろん -vv
を使えばエラーは見える。
~$ python get-pip.py -vv Created temporary directory: /tmp/icchy/pip-ephem-wheel-cache-nCRTal Created temporary directory: /tmp/icchy/pip-install-n4gtqZ Collecting pip ... Installing collected packages: pip Traceback (most recent call last): File "/tmp/icchy/tmp_NGCSM/pip.zip/pip/_internal/commands/install.py", line 335, in run use_user_site=options.use_user_site, File "/tmp/icchy/tmp_NGCSM/pip.zip/pip/_internal/req/__init__.py", line 49, in install_given_reqs **kwargs File "/tmp/icchy/tmp_NGCSM/pip.zip/pip/_internal/req/req_install.py", line 748, in install use_user_site=use_user_site, pycompile=pycompile, File "/tmp/icchy/tmp_NGCSM/pip.zip/pip/_internal/req/req_install.py", line 961, in move_wheel_files warn_script_location=warn_script_location, File "/tmp/icchy/tmp_NGCSM/pip.zip/pip/_internal/wheel.py", line 314, in move_wheel_files clobber(source, lib_dir, True) File "/tmp/icchy/tmp_NGCSM/pip.zip/pip/_internal/wheel.py", line 285, in clobber ensure_dir(destdir) File "/tmp/icchy/tmp_NGCSM/pip.zip/pip/_internal/utils/misc.py", line 86, in ensure_dir os.makedirs(path) File "/usr/lib/python2.7/os.py", line 157, in makedirs mkdir(name, mode) OSError: [Errno 13] Permission denied: '/usr/local/lib/python2.7/dist-packages/pip-10.0.0.dist-info' Cleaning up...
システムのpipに変更を加えずにpip10を使う
pipコマンドで起動するのがそもそもの原因なので、python -m pip
でpipを起動すればなんら問題はない。
alias pip='python -m pip'
この場合システムのpipはどうなるんだと思うかもしれないが、$HOME/.local/lib
をパッケージのパスに追加しているのでrootの場合は /usr/lib/python2.7/dist-packages/pip
が参照される。つまり通常ユーザーはpip10を使い、システムはpip9を使うという奇妙な状態になる。もちろん各パッケージ自体はpythonのバージョンにしか依存しないので、pipのバージョンによって異なるパッケージが入ることはまずない。
まとめ
この問題の根本的な原因はpip10でディレクトリ構成の変更が行われたことにあった。変更にはそれなりの理由があって、pip側で解決策が打たれることはおそらくない。ディストリビューションのアップデートを待つか、自分で対応するしかなさそうというのが現状である。
解決策としてはこちらに示した3通りの方法が考えられる。他にも良い解決策があれば是非教えてほしい。
余談
pipのドキュメントは https://pip.pypa.io/en/stable/ で見られる。 pip 9.0.1のドキュメントを見るためにstableの部分を差し替えて https://pip.pypa.io/en/9.0.1/ にアクセスしたのだが、なんと403になっていた。9.0.3や10.0.0も同様なので、おそらくstableにしかアクセスできないようにして、そのシンボリックリンクとかを最新版に向けてるとかそんなところだと思う。
-
通常
--user
をつけない場合は/usr/local/以下にインストールしようとするため、root権限がないと失敗する。↩
近況1
案の定日記を書くのが面倒になったので毎日の更新をやめた。
いろいろやっている。取り組むプロジェクトの候補を一つ一つ吟味しながら軽く論文を読んだり、OSSのツールがあった場合は適当に試したりしている。
当初はfuzzingなどの自動解析系をやりたいと思っていたが、ここにきて非常に興味深いプロジェクトが増えたので揺れてきた。
アメリカでの生活にはだいぶ慣れた。残るタスクは各種の住所変更と社会保障番号 (SSN) の取得である。SSNがないと税金が払えなくて、給料をもらえなくなってしまうので餓死する。
新しい宿は、インターネットが突然数分死ぬことがあるという点を除けばかなり快適である。インターネットのために研究室へ移動していると言っても過言ではない。今持ってるSIMはなぜかテザリングが使えない。
所持金がそろそろやばいことになりつつあるので外食や余計な買い物を控えている。と思ったら今日は$13くらいするラーメンを食べてUberで帰った。計画性がない。まあUberが紐づいている口座は日本のやつなので直接の影響はないのだが。
なぜUberを使ったかというと、研究室の人に「夜バスに乗るのは危ない」と言われたからである。聞くところによると、ルームメイトが夜バスに乗って強盗に遭い、持ち物全てを奪われたらしい。流石にPCを取られると終わりなのでかなり警戒している。
オンラインでいくつかのCTFにTokyoWesternsとして参加した。HITB-XCTFはなんと1位、Midnight Sun CTFは2位でどっちもfinalsがあるので時間と金と運があれば行くつもりである。最近CTFであまり活躍できていなかったのだが、出発前に参加した0ctfでは最後5分くらいでWebの解法を思いついて通せたし、先の2つのCTFでは結構問題解けたし幸先が良い。この調子でDEFCON予選とかも突破したい。
Linux環境を一新したらpipが壊れた。
pip install --upgrade pipしたらpipが崩壊した、皆さんはpip install --upgrade pipしたらpipが崩壊したことありますか?
— icchy (@icchyr) 2018年4月16日
この現象はすごい面白くて (こちらとしては全く面白くないが) 、debian9で python-pip
をインストールするとシステム (/usr/bin/pip) にインストールされるが、以降のpipコマンドは $HOME/.local/
以下にパッケージをインストールするため、もしpipの更新をかけると新しいpipのライブラリが $HOME/.local/lib
に配置され、以降はそちらのライブラリが優先的に参照されるがpipコマンドは /usr/bin/pip
のままなのでバージョン違いにより実行できないというものである。python -m pip
を代わりに実行したり、$HOME/.local/bin
を $PATH
に追加することによってこのエラーは回避できるのだが、なんと $HOME/.local/bin/pip
は正しくパッケージをインストールできない。全くもってこの原因はつかめていないが、最新のdebian9でやると発現するので気になる各位は試してほしい。そしてもしよければ解決策を教えてほしい。
また気が向いたら更新する。
アメリカ day 8
day 2にも行ったハワイアンBBQに再び行ってみた。今回は昼の時間だったので"Lunch Special"なるものを注文してみた。
割とボリュームがあると思いきやそうでもない。おそらくご飯が対して多くないせいだと思う。
大学に戻って研究テーマの候補をあれこれ思案していると、Ph.Dの学生がやってきてあるテーマについて熱烈なアプローチを受けた。かなり面白そうなのだが、結構実装が重いタイプのやつでなかなかリスキーである。システムプログラミングについては現在修士で取り組んでいるテーマでそこそこしんどい思いをしているのでできれば避けたい。
ついに定住先を見つけたので荷物をまとめて移動した。
大学からちょっと遠くなるものの、スーパーや薬局が近くにあるのでかなり便利っぽい。
前のAirbnbで借りていた家には直接外へ通じる鍵付きドアと家の中へ通じるドアがあって、前者は歪んでいるせいか下に2, 3cmほどの隙間があって、そこからよく虫が入って来て悩まされていた。もちろんAirbnb用にわざわざprivate entryを設けたのかもしれない。
せっかく引っ越したし近くにスーパーもあったので、早速自炊をしてみようということでチャーハンを作った。アメリカの米はインディカ米 (細長いやつ) が主流で、鍋を使って炊くのが一般的である。もちろん炊飯器を使う人もいるらしいがここには炊飯器は無いとのことで、鍋で20分ほど茹でることに。やはり火力も圧力も足りないので、最初に米が炊けたときは芯が残っていた。
ところがこれでチャーハンを作ってみるとめちゃくちゃ綺麗な (いわゆるパラパラ) チャーハンが作れるし、再度火を通すので芯は残ってないしでかなりうまくいった。ジャポニカ米はどうしても粘り気が出てきてしまうので、卵で米をコーティングしていい感じにパラパラ感を出すということをよくやるのだが、その必要が全くなかった。
生まれて初めて綺麗なチャーハンができたのでかなり満足している。
自由に調理器具や食材を使わせてもらえるので、食費がかなり節約できそうだしこれからも積極的に自炊をやっていくぞという気持ちになった。
アメリカ day 6, 7
day6
アリゾナには日本人が運営している日本食材専門店があるらしくて、一度行ってみることにした。
割と品揃えは豊富で、特に調味料の類はかなり揃っていたと思う。
値段はやはり輸入品のためかなり割高である。ものにもよるがだいたい日本での価格の2倍程度だろうか。
外に出たついでに朝飯兼昼飯兼夕飯を食べた。Thai Basilという店があって、その名の通りタイ料理が食べられる。
去年の末にICPCでタイに行ったときにもいろいろ食べたが、アメリカで出るタイ料理はどんなもんだろうとPad Thaiを頼んでみた。
写真だとわかりにくいかも知れないが、やはりサイズが大きい。直径30cmというのは標準規格なのか?
味はタイで食べたのと似たような感じで、タイ語っぽいものが聞こえてきたし多分本場のタイ人が調理しているんだと思う。
一応ウェイターがいるレストランなのでそれなりに値が張った。
day7
まず大学に行ってzardusと研究テーマについてのミーティングをしようとコンタクトを取ったら、
ちょうどShellphishのFishが来ていて、angrのコアなcontributor2人と昼食を取るという非常に貴重な体験をした。
ちなみに食べたのは醤油ラーメン:
味は割と普通で、強いていうなら麺が柔らかかったが普通に美味しかった。
そのあとは各種手続きの為に大学をあちこち歩き回って疲れた。ある程度英語は聞き取れるが、発音がめちゃくちゃ早いとつい聞き返してしまうことが何度も発生してつらい気持ちになる。
次の住居が決まったので少し早く切り上げて明日にも移動しようと思っている。これで少しはAirBnbの宿代が浮いてほしい。
アメリカ day 5
またしても4時に目が覚めた。しんどい
偶然同じ学科に日本人でPh.Dの人がいて、詳しく話を聞かせてもらった。とにかく水分補給をこまめにした方が良いと言われた。聞くところによると夏のやばい日は50℃くらいまで上がるらしい。地獄か?
ハンバーガーをお昼ご飯に選んでしまった。
ここに来てからハンバーガーとピザ以外のものを口にしていない気がするのでそろそろなんとかしたい。あとポテトの塩がめちゃくちゃ多くてしょっぱい。
こんな食事をしているのと不自然な生活リズムが合わさって、一日一食というという日が数日発生している。健康にも良くないし早く自炊をベースとした生活に切り替えたい。
先にあげたPh.Dの方のおかげで家問題が解決しそうである。家探しは基本的に自分で契約するか又貸し (subleaseという) する人を探すしかなくて、前者は十分な収入が求められたり契約期間が1年からと決まっていたりして海外から来たばかりの人には難しい。後者も同様にあまり素性の知れない、安定した身分を持っていない人には基本貸さないらしく、知り合い経由などで頼むのが無難とのこと。
そのPh.Dの方の知り合いにちょうど空きがある家を持ってる人がいたので、家主にコンタクトを取ったところ幸運にもすぐにOKが出た。とても感謝している。