jupyter に themes を適用する
最近眼精疲労がヤバイのは jupyter notebook の背景が白いせいだと思ったので themes を設定した
— ろにゃ (@roronya) 2016年12月3日
jupyter に themes を簡単に設定することができる jupyter-themes を紹介する。また、jupyter-vim-binding と併用する際の設定についても書く。
jupyter-themes
jupyter に themes を設定できるコマンドツールを pip で入れられる。
$ jt -t onedork
これで themes は設定できる。
jupyter-vim-binding との併用
選択セルに themes が適用されない問題
jupyter-vim-binding と併用すると、CSS が競合して選択セルに themes が適用されない。これは jt コマンドに -vim オプションを付けることで解消できる。
$ jt -t onedork -vim
normal モードのカーソルの色を変える
デフォルトでは normal モードで緑のカーソルがチカチカとしている。せっかくなので themes にあった色を設定したい。これは~/.jupyter/custom/custom.css
を編集して変更できる。ファイルの冒頭に下記のように追加する。#0095ff は onedork でのカーソルの色に合わせている。
.cm-fat-cursor .CodeMirror-cursor { background: #0095ff; } ...
諸注意
- jt コマンドを叩くと custom.css が上書きをされるので、カーソルの色の変更をする設定は最後に行う。
- jupyter notebook の再起動をしないと themes が適用されない。ブラウザのキャッシュにより変更がされていないように見える場合があるので、シークレットモードで確認をする。
MySetting
jt コマンドは -vim 以外にも色々オプションが付けれる。私はセルの幅を広くした。デフォルトでは 970 であるが、手持ちのノートブックの解像度を考えて 1300 とした(-cellw 1300)。また、jupyter-thems では画面上部のファイル名やツールバーが無効化されているのでこれを有効化する(-T -N)。
$ jt -t onedork -vim -cellw 1300 -T -N
【Symfony2】DoctrineFixturesBundle で作ったフィクスチャを phpunit から呼びたいとき
機能テストをするときにテストデータを DoctrineFixturesBunle で作った LoadHogeData クラスを使いたいとき
- LoadHogeDataクラスが ContainerAwareInterface を実装しているときどうするか
- LoadHogeData が外部キー制約で怒られるときはどうするか
について書きます。
ほとんど以下の「テストコードからFixtureをロードする」項目からのコピペです。
こうしました。泥臭さが出るけど致し方ない。
- LoadHogeDataクラスが ContainerAwareInterface を実装しているときどうするか fixture に自分で Container をセットする。
- LoadHogeData が外部キー制約で怒られるときはどうするか SET FOREIGN_KEY_CHECKS = 0 を無理やり叩いて外部キー制約を無効化する。
use AppBundle\DataFixtures\ORM\LoadHogeData; use Doctrine\Common\DataFixtures\Loader; use Doctrine\ORM\EntityManager; use Symfony\Bundle\FrameworkBundle\Test\WebTestCase; use Doctrine\Common\DataFixtures\Executor\ORMExecutor; use Doctrine\Common\DataFixtures\Purger\ORMPurger; use Symfony\Component\DependencyInjection\ContainerInterface; class HogeFuntionalTest extends WebTestCase { /** * @var EntityManager; */ private $em; /** * @var ContainerInterface; */ private $container; public function setUp() { # kernel のブート { $kernel = static::createKernel(); $kernel->boot(); # } # EntityManager の取得 { $this->container = $kernel->getContainer(); $this->em = $this->container->get('doctrine.orm.entity_manager'); # } # 外部キー制約の無効化 { $connection = $this->em->getConnection(); $connection->exec('SET FOREIGN_KEY_CHECKS = 0'); # } # フィクスチャの実行 { $loader = new Loader($this->container); $fixture = new LoadAccountantData(); $fixture->setContainer($this->container); # ContainerAwareInterface を実装している場合インスタンス化してから自分で container をセットする必要がある $loader->addFixture($fixture); $fixtures = $loader->getFixtures(); $purger = new ORMPurger($this->em); $purger->setPurgeMode(ORMPurger::PURGE_MODE_TRUNCATE); $executor = new ORMExecutor($this->em, $purger); $executor->execute($fixtures); # } # 外部キー制約の有効化 { $connection->exec('SET FOREIGN_KEY_CHECKS = 1'); # } } …
外部キー制約で php app/console doctrine:fixtures:load
がたたけ無いときはこっち
doctrine:fixtures:load で外部キー制約で怒られるとき
[Doctrine\DBAL\Exception\ForeignKeyConstraintViolationException]
このエラーが出る。
結構調べたんだけど、結局データベースごと作りなおすしか無さそうでした。
というわけで、僕は以下のコマンドを叩いています。
php app/console doctrine:database:drop --force;php app/console console doctrine:database:create;php app/console doctrine:schema:update --force;php app/console doctrine:fixtures:load
データベースを作って壊してスキーマをアプデートしてフィクスチャをロードします。
星を撮る
— ろにゃ (@roronya) 2016年10月27日
友達が買った車は大きな車体に静かなモーター音で田舎道を走って、僕たちを秋のスキー場へ運んだ。暗闇だった。きっと紅葉が始まっていて山は綺麗に色づいていたのだと思うが、今日の興味の対象外だった。写真が好きだったらしい祖父の遺品のひとつ、キャノンの FD マウントの広角レンズを取り付けた愛機を抱えて静かな高原を少し登った所に三脚を構えた。安物なので足は伸ばさない。腰をかがめて設定を確かめる。レリーズケーブルは買っていない。のでタイマーで撮る。シャッターボタンに軽く触れると 2 秒後にシャッターの開く音がして、32秒後にもう一度鳴った。カシャンッ!!と小さなマシンにしては大き過ぎる音が鳴るが、僕は結構気に入っている。
Factorization Machines について輪講で発表した
「隣のチームは Factorization Machines 使うらしい」とチームメイトが言ったのは、もはや内定先である弊社の冬インターンだった。当時の僕は「へえそうなんだ(Matrix Factorization の別名かな)」というトボけたことを思ったが、もう大丈夫。わかりました。
で FMs がわかってしまえばなんかコンペで強かったと聞く Field-aware FMs もすぐわかる。
http://www.csie.ntu.edu.tw/~r01922136/slides/ffm.pdf
ぱっと見ると FMs で O(n2) から O(kn) までパラメタを削減できたのに FFMs では O(kn2)になっとるやんけ!これじゃあスパースなデータで推論できんやろ!と思ったんだけどこうなるのは一番極端な場合で、変数をクラスタリングしておけば、現実的にはクラスタ数 f がオーダーに加わって O(kfn) になるということです。
FFMs おもしろいですね、汎化してから特化していてそれで良く推定できるという…。じゃあ今度はそのクラスタ間の相互作用考えたほうがええやんけつってクラスタ間の相互作用を表す重みをl次元ベクトルで分解してパラメータ数 O(klfn) のモデルが提案されて…みたいなことは無いんだろうか。やってみたら面白いのかも知れない。
輪講ではボスが SVM をこの程度でこき下ろすのは納得いかないと言っていた。そもそも回帰に使う SVM とはちょっと違うとも言ってた。僕は SVM 勉強不足でよくわからないが…。論文中で双対問題への変換がデメリットのような雰囲気で書かれていたのだけどこれが僕はよくわからなかった。ボスも別にデメリットなんて無いよと言っていたけど…。
マクロスΔ最終回と黒澤明の「生きる」
僕はマクロスΔはマクロスシリーズとして認めたくないなあと思った。色々と説明不足なのだ。あるいは説得力の不足だ。何よりマクロスシリーズとしてのエッセンスの不足が深刻だった。マクロスシリーズとはなにか。マクロスシリーズとは敵とみなしていたモノとの出会う話だ。出会うっていうのは争うことじゃなくて認めることだ。排除ではなく包摂だ。愛がテーマだったはずのマクロスで、敵からも味方からも恨まれる第三の敵を作って、これを尽く叩き潰してしまったマクロスΔの最終回は、マクロスシリーズの在り方として筋が悪かったと、おもいます。
あるいは、やっぱり、説得力の不足だ。黒澤明作品を僕は今日始めた見たんだけれど、フィクションに必要なのは説得力なんだと、身にしみてわかった。鑑賞後に胸に湧く自然な感想の中にもやもや感が全然無くて、この圧倒的説得力に僕は感心した。
マクロスΔは第三の敵を問答無用で叩き潰してしまった。そこに説得力は無かった。第三の敵の死に際の「なぜ理解しない!」ってセリフが虚しい。大多数に理解されなければ切って捨てていいのか?これを否定してきたのがマクロスシリーズじゃないか。マクロスシリーズがシリーズとして成り立ってきた掟を破るには、理由が、説得が、必要だったはずで、これをやっていないから、マクロスΔはまだ続きのシナリオがちゃんと用意されていて、マクロスシリーズのひとつとして完成するために、完結編を映画でやるのかもなと思いました。