The jonki

呼ばれて飛び出てじょじょじょじょーんき

arXiv論文のためのChrome拡張を作った

皆さんはarXivの論文を読んでまとめようとするとき,どうやってその論文情報をEvernoteなりOneNoteなりに書いていますか?私はいちいちコピペしていたのですが,arXivは更新頻度が高いので面倒だなと思い,Chromeの拡張を作って単純作業は自動化しました.

作ったのは2つ.1つずつ概要を説明していきます.もし興味あればChrome拡張のコード説明も後半に載せます.

  1. 論文の主要情報をテキストとしてコピーするもの(arXiv clip

  2. 論文の主要情報を所定のGitbhubにissueとしてポストするもの(arxiv2issue

arXiv clip

下記のような特定の論文ページを開いた状態で,arXiv clipのアイコンをクリックすることで,論文情報(タイトル,著者,コメント部(学会情報が書かれること多い,未記入の場合はスキップ),URL)が下記のようにコピーされます.論文を共有したい時とかに便利です. f:id:jonki:20181228111051j:plain

Learning End-to-End Goal-Oriented Dialog
Antoine Bordes, Y-Lan Boureau, Jason Weston    
Accepted as a conference paper at ICLR 2017
https://arxiv.org/abs/1605.07683

arxiv2issue

これは先程の応用編のようなものです.私は論文をGithubのissueにまとめています.気になった論文をこれまではarXiv clipでコピーした情報を,いちいちIssue生成→貼り付け,とやっていたのですが,面倒なのでissueの生成も自動化するようにしました.こちらも先程と同様に所定のarXivの論文のページでarxiv2issueのアイコンをクリックするだけです.issueに投稿するにあたって,GithubのPersonal Access Tokenというものを使用しています.arxiv2issueのアイコンを右クリックして,生成したトークン,Githubユーザー名,リポジトリ名をセットしておくことで,好きなリポジトリでissueを生成することができます.

Personal Access Tokenの取得方法などは,下記のREADMEを参考にしてみてください. github.com

f:id:jonki:20181228111723p:plain
投稿イメージ

以下コード解説をしてみますが,Chrome拡張に興味がある人は見てみてください.私自身,本機能のためだけにChrome拡張を作ったのでちゃんと勉強していません.下手な書き方など大いにあると思いますがご容赦ください.

コード解説

Chromeの拡張作成の細かいところは,公式のドキュメントに譲り,ここでは機能のコア部分について説明します.

まずarxiv-clipは下記のような構成になっています.ソースコードはこちら

$ tree
.
├── background.js    // 所定のページ(今回はarxiv)を現在のタブが開いているかチェックし,開いていればアイコンを有効化
├── jquery-3.3.1.slim.min.js    // HTMLのパース用に追加
├── manifest.json   // Chrome拡張の宣言ファイルのようなもの
├── popup.html   // アイコンを押したときに表示されるGUI.
├── popup.js  // 下記に詳述

もっとも重要なpopup.jsのコードを貼ります.やっている内容は,カレントタブのHTMLを読み込んでjQueryに流し込み,欲しい情報を取得.取得した論文情報をcopyToClipboard関数を使ってクリップボードにコピーしています.このコピー部分はトリッキーなことをやっていますが,ブラックボックスな関数として使って良いと思います.

ARXIV_URL = 'https://arxiv.org/*';

function getCurrentTabUrl(callback) {
    var queryInfo = {
        url: ARXIV_URL,
        active: true,
        currentWindow: true
    };

    chrome.tabs.query(queryInfo, (tabs) => {
        if (tabs.length > 0) {
            var tab = tabs[0];
            var url = tab.url;
            console.assert(typeof url == 'string', 'tab.url should be a string');
            callback(url);
        } else {
            $('#result').text('not arXiv!');
        }
    });
}

function modifyDOM() {
    return document.body.innerHTML;
}

function copyToClipboard(text) {
    const input = document.createElement('textarea');
    input.style.position = 'fixed';
    //input.style.opacity = 0;
    input.value = text;
    document.body.appendChild(input);
    input.select();
    document.execCommand('Copy');
    document.body.removeChild(input);
};

document.addEventListener('DOMContentLoaded', () => {
    getCurrentTabUrl((url) => {
        chrome.tabs.executeScript({
            code: '(' + modifyDOM + ')();' //argument here is a string but function.toString() returns function's code
        }, (results) => {
            var $dom = $($.parseHTML(results[0]));
            title = $dom.find('h1.title').text().split('Title:')[1];
            authors = $dom.find('div.authors').text().split('Authors:')[1];
            authors = authors.replace(/\n/g, '');
            comment = $dom.find('div.metatable').find('.comments').text();
            if (comment != '') {
                info = [title, authors, comment, url].join('\n');
            } else {
                info = [title, authors, url].join('\n');
            }

            copyToClipboard(info);
            $('#result').text('copied!');

            // hide popup automatically
            setTimeout(function () {
                window.close();
            }, 3000);
        });
    });
});

次にarxiv2issueの説明に入ります.コードはこちら.こちらの拡張はarxiv clipを拡張する形で作ります.追加で必要な機能として,トークンやリポジトリ情報を保存する機構とissueにポストする機能の2つを説明します.

情報を保存するためOptionsを呼ばれるページを作ります.アイコンを右クリックしたときに現れる設定ページのようなものです.基本的にはチュートリアルの例をコピペして,自分用にカスタムしただけです. Give Users Options - Google Chrome

情報の保存には,chrome.storage.syncを利用します.これを利用するとChromeで同期しているアカウント内ではデータが共有され,複数台のマシンを持っている人はイチイチ設定し直さなくてよいので便利です.下記のoptions.html/jsでは,3つのテキスト情報をchromeに保存しています.

<!DOCTYPE html>
<html>
    <head><title>arxiv2issue Options</title></head>
    <body>

        Github User Name:
        <p><input id="user-name"></p>
        Github Repository Name:
        <p><input id="repo"></p>
        Github Personal Access Token (<a href="https://github.com/settings/tokens/new">Get your token.</a> "repo" option must be checked for this extension.):
        <p><input id="token"></p>

        <div id="status"></div>
        <button id="save">Save</button>

        <script src="options.js"></script>
    </body>
</html>
// Saves options to chrome.storage
function save_options() {
    var uname = document.getElementById('user-name').value;
    var repo  = document.getElementById('repo').value;
    var token = document.getElementById('token').value;
    chrome.storage.sync.set({
        uname : uname,
        repo  : repo,
        token : token
    }, function() {
        var status = document.getElementById('status');
        status.textContent = 'Options saved.';
        setTimeout(function() {
            status.textContent = '';
        }, 750);
    });
}

// Restores values
function restore_options() {
    chrome.storage.sync.get({
        uname: '',
        repo: '',
        token: ''
    }, function(items) {
        document.getElementById('user-name').value = items.uname;
        document.getElementById('repo').value = items.repo;
        document.getElementById('token').value = items.token;
    });
}
document.addEventListener('DOMContentLoaded', restore_options);
document.getElementById('save').addEventListener('click', save_options);

f:id:jonki:20181228120401p:plain
設定画面

そしてissueにポストします.先程のpopup.jsを改変するだけで良いです.issue作成のために,Githubのv3 APIを使っています.非常に簡単で,先程のトークンをGETパラメタにセットしているだけです.注意としては,Acceptヘッダにjsonを入れるようにする必要があります.issueはJSON文字列として作り,タイトルや本文などの設定ができます.v3 APIのページにセットできるパラメタリストが載っています.私はtitleとbodyのみを設定して,ポストしています.

// 略
function create_issue(title, body, year, callback) {
    var base_url = 'https://api.github.com/repos';
    chrome.storage.sync.get(['uname', 'repo', 'token'], function(data) {
        var uname = data.uname;
        var repo = data.repo;
        var token = data.token;
        var url = [base_url, uname, repo, 'issues'].join('/');

        var url = url += '?access_token=' + token;
        console.log('URL: ' + url);

        var data = JSON.stringify({
            'title': ['🚧', year + ':', title].join(' '),
            'body': body
        });
        var request = new XMLHttpRequest();
        request.open('POST', url);
        request.onreadystatechange = function () {
            if (request.readyState != 4) {
            } else if (request.status != 201) {
                console.log(request.responseText);
                callback('Failed to post an issue.');
            } else {
                var resp = JSON.parse(request.responseText);
                callback('Issue posted!: #' + resp.number);
            }
        };
        request.setRequestHeader('Content-Type', 'application/x-www-form-urlencoded');
        request.setRequestHeader('Accept', 'application/vnd.github.symmetra-preview+json');
        request.send(data);
    });
}
// 略

まとめ

今回はarXivの論文をまとめるための簡単なツールを紹介しました.arXivは更新頻度が多いので見るのが大変です.こういったツールを活かして,手作業コピペなどの余計な作業時間は極力減らして,うまく効率的に論文を読みたいものですね.

一人語りのポッドキャスト.良い音作りのために必要な作業.

f:id:jonki:20181228001447p:plain おかげさまでポッドキャストLeading NLP Ninjaの配信も約4ヶ月で16回に到達しました.テーマがニッチなのでこれだけの人に聞いて頂けるとは思ってもいませんでした.今回の記事では,私のポッドキャストの録音や編集環境について説明したいと思います.というのも,ポッドキャストを録るにあたってノウハウがMiyagawaさんの記事Rui Ueyamaさんの記事ぐらいだったので,もう少し日本語で情報が合っても良いかなと思い,書いた次第です.更に私はお二方と違って,1人のみでの配信なので,それなりに録音・編集作業への要求レベルが低くて済みます.

www.jonki.net

前提条件としては,下記ぐらいです.Mac環境というのは,編集のみLogic Pro Xを使っているためで,もしWindowsであれば,Audacityでも問題ないと思います.

  • 一人録音
  • Mac環境

今回の記事では,録音環境及び編集環境の2パートで説明をしていきます.

録音環境

私の番組は第5回ぐらいまで,かなりひどい音質です.10回以降あたりから安定するようになりました.ひどい音質にはいくつか理由があります.逆に言うと,これを1つずつ最低限直していけば,高品位な音質になっていきます.1つずつ原因と対策を見ていきます.

録音部屋がひどい

初期では,残響の大きな会議室とかでやっている回がありました.残響が乗ってしまうと正直編集でもどうにもなりません.なるべく残響がない部屋で騒音もない部屋を確保する必要があります.残響の大きさは,例えば1度手を叩いて,その音の余韻が残るかどうかでわかります.Rebuild fmのMiyagawaさんは以前クローゼットでやっていたとのことですが,服などが多いと音を吸収してくれるので残響が少なくてとても良いです.私もアメリカで配信していたときはクローゼットで録音していましたが,日本の住居だと難しいので今は普通の作業部屋でやっています.録音中は嫁には申し訳ないのですが,テレビなどは消してもらっています.環境としてはそこまで良くないのですが,窓を閉める,ドアを閉める,外が静かな時間帯を選ぶ,などでそれなりに回避できています.一人で喋っているので,救急車などが通った場合は,一度発話をやめて,静かになった後に喋り直したりしてます.また後述のマイク環境でもそれなりにノイズ対策ができます.

マイクがひどい

最初はポッドキャストを長く続けられると思っていなかったので,簡単なUSBマイクを使っていました.ただ私の好きなPodcastと聴き比べると,音質の差が明らかになり,これはまずいと思いました.音質の悪いポッドキャストは正直聞くに耐えません.そこで色々試した結果,今の環境に落ち着きました.これに至る前はYetiやAudio-Technica ATR2100-USBなど試しましたが,個人的には,コンデンサマイク,マイクアーム利用可,である必要を感じたため,これらの利用をやめました.マイクには大きく分けて,ダイナミックマイクコンデンサマイクがあります.Miyagawaさんの記事ではノイズが多いような環境ではダイナミックマイクをおすすめしていました.コンデンサマイクは楽器の収音などにも利用されるので,ノイズも繊細に感じ取ってしまいます.しかし,ダイナミックマイクでは,結構声を張る必要があるのと,音が籠もるのでどうも馴染めずいました.今使っているマイクはAston originはコンデンサマイクなのですが,マイクスクリーンと組み合わせるだけで,正直ノイズは気にならないレベルになりました.このあたりの音質評価はdrikinさんがYoutubeで配信していて,これにモロに影響を受けて買いました.マイクが高価なのですが,マイクは録音の心臓部なのでお金をかけたほうが良いです.肌に合わなかったらメルカリなどで売ればそれなりに高音で売れます.またマイクアームも欲しいです.Yetiは机直置きなのですが,キーボードのタイプの振動などを拾いやすい上に,そもそも机上に普段あると邪魔というのがあり,デザインは最高なのですが,メルカリで売ってしまいました.

また録音環境は,これもMiyagawaさんに影響されてZoomのレコーダーにしました.最初はXLR→USB->Macbookにして,Mac上で録音していましたが,Macbook自体のファン動作音やOSの動作不安定性をある程度考慮する必要があるため,録音は専用の録音機器を使ったほうが良いという結論に至りました.このあたりはMiyagawaさんの配信ガイドを是非見てほしいです.やろうと思えば,Live配信や二人以上の同時録音なども可能です.

ZOOM ズーム リニアPCM/ICハンディレコーダー  H5

ZOOM ズーム リニアPCM/ICハンディレコーダー H5

喋り方が悪い

最初はマイク感度などイマイチよくわからず,かなり小さい音で録音していたため,ポストプロダクションでノイズや唾の音などもブーストしてしまう結果となってしまいました.そのため,今では下記に注意しています.

  • マイクはできるだけ口元に近づける
  • 声は大きくはっきりと,フィラーもなるべく避ける
  • 音量レベルは,ちゃんと確認しておく(参考までに今の私の録音レベルはLogic Pro Xでは下記ぐらい)
    f:id:jonki:20181227230838p:plain
    録音レベル(Logic Pro X)
  • マイク音をしっかりモニター用ヘッドフォンでモニタリングする
    音はしっかりとモニターヘッドフォンを使ってモニタすべきです.この音を聞いておけば,ノイズに敏感になって気をつけて録音できます.また無響室で録音しているわけではないので,「サー」といった音は常に聞こえますが,配信する際は,正直あまり気にならないレベルに落とせるので問題ないと思います(モニター用ヘッドフォンで聞いているので,通常リスニング時よりも機敏にいろいろな音が聞こえてしまうというのもあると思います).参考に私の環境では,Zoomのレコーダーのマイクレベルは5.5あたりにセットしてあります.モニター用ヘッドフォンは何でも良いと思うのですが,私はMDR-CD900STに憧れがありつい買ってしまいました.ZoomのH5で聞く場合はフォーンの変換プラグが必要です.余談ですが,プラグは下手に安いのを買うと接触が悪かったりするので,ちゃんとしたブランドのプラグを買いましょう.

SONY 密閉型スタジオモニターヘッドホン MDR-CD900ST

SONY 密閉型スタジオモニターヘッドホン MDR-CD900ST

audio-technica 変換プラグ ATL419CS

audio-technica 変換プラグ ATL419CS

編集環境

私の場合は,1人のため編集はかなり楽ですが,それでも録音時間以上の時間を編集に当てています.定期的な配信をするためにも,私はできるだけ編集は凝らないことにしています.具体的には,音のフェードやBGMなどもまったく使わず,不要な音声部の削除のみをして,細かいポストプロダクションは外部サービスに委託しています.ここでは私が使っているLogic Pro Xでの作業過程をショートカットの説明を添えて追っていきます.プラグインを使わずに基礎機能しか使っていないので,Garage Bandでも同様のことが出来ると思います.

まず準備として,録音したwavファイルをドラッグアンドドロップし,右上の↔,↕で波形がよく見えるようにビューを調整しましょう . f:id:jonki:20181227232404p:plain

これだけです.それではさっそく編集に入ります.編集では無駄な空白時間,言い直し部,フィラー(えー,とか),などを必要に応じて削ります.意図的な空白時間や明らかな言い直しなどはカットすべきですが,フィラーなどは無理して削りすぎなくても良いです.発生が連続していると,余計に他の言葉も削ってしまったり,その分編集作業時間が長くなるためです.

  • スペースキー(音声の再生/停止)

  • < >(シーケンスの数秒の前後移動)

聞く必要のない区間や聞き直しではこれを多用します.

  • CMD+T(トラックの分割です)

不要な部分を削るため,再生シーケンスの位置でトラックを分割します.分割するためには,トラック(音声波形部分)をクリックして選択しておく必要があります.ショートカットが発火しない場合は,音声波形が選択状態にあるか確認してください.不要な部分はその区切られた波形部分をクリックして,Deleteキーで消せます.慣れれば再生を続けながらこの作業ができます.Logic Pro Xでは自動で無声部を削る機能もあるのですが,無駄に削りすぎてしまったりすることを考慮して,結局は全部聞く必要はあるので使っていません.1人録音の場合は,特に頼る必要はないと思います.

  • Shift+A -> Option [(トラックを選択して,左に詰める)

とりあえず不要な部分を削れたとします.そこで削った部分を時系列に左寄せして,無駄なスペースを削りたいと思います.そこでやるのがこの作業です.まず冒頭の録音部分に戻り,トラックの冒頭に再生カーソルをあわせます.そこでShift+Aを押すことで,それ以降の分割されたトラックが選択状態になります.その状態で,Option+[を押すことで,スペースを詰めて各トラックの左寄せができます.これは編集最後に1回やるだけです.

https://media.giphy.com/media/2zotX1QVJRxBIIzxH6/giphy.gif

  • CMD+A -> CMD+J(トラックを全選択して,結合する)

wavとして出力するため分割されたトラックを結合する必要があります.この作業をすると1つのトラックとなります.

  • CMD+A -> CMD+B(トラックを選択して,WAV出力する)

私の場合,Logic Pro Xでの編集作業はここまでなのでWAVに出力します.設定は下記のとおりです.注意として,トラックを選択していない状態でWAV出力しようとすると,オリジナルの音源の長さの文だけ無駄にWAVを出力しようとするので注意です.生成されたWAVの最後が無駄に無声になっていないか注意してください.

f:id:jonki:20181227234625p:plain
WAV出力設定

これでWAVができました.普通はコンプレッサーを使ったり,ノイズを削ったり,音量レベルを揃えたり,色々やる必要はあるのですが,私の場合は,労力削減のため,下記のサービスを使っています.Turing Complete FMでも使っているようです.このサービスは音声ファイル2時間分までは毎月無料で,それ以上は利用時間に応じて利用料金が発生します.私の場合は,月に3時間程度は使っているので,月額11ドルが発生しています.Logic Pro Xをマスターすれば,Auphonicを使う必要はないのですが,音声の編集はそれなりに大変ですし,時間もかかるので,私はAuphonicに全任せしています.個人的にはこれで問題ないレベルの音声になっていると思っています.

auphonic.com

f:id:jonki:20181227235018p:plain
auphonicの設定例

Auphonicに音源をアップしたあとは,しばらく待てば編集作業完了のメールが届き,音声がmp3でダウンロードできるようになっています.あとはこれをポッドキャストホスティングサーバーに上げるだけです.

まとめ

いかがだったでしょうか.1人配信ということで,かなり簡素な編集作業になっているのではないかと思います.それでも現在の私の番組の音質も他の先駆者たちと比べて,そう見劣りする品質ではないのではないかと思います.正しく録音をする,というのがやっかいですが,そこは何とか自分の環境に合わせて調整していく必要があります.5,6回同じ作業をしていけば,自分なりの最適環境に到達するのではないでしょうか?

個人的なFuture workとしては,キャプションに対応して,説明箇所に応じてすぐ再生シーケンスをジャンプ出来るようにしたいと思っています.ただそれをAnchorでやる方法,及び,他のポッドキャストアプリで使ったときの挙動の確認などができていないので,時間を見つけてやりたいと思っています.私の場合は1つの論文を紹介するだけなので,そこまでキャプションは必要ないと思っているのですが,様々なテーマを語るような番組では必須になるのではないかと思います.

ポッドキャストの録音,編集,配信ノウハウはまだまだ全然足りていない気がして,もしこれを読んでくださってるあなたが配信者であれば,そのノウハウを何らかの形でぜひ共有してください.私もまだまだ探り探りなので,ポッドキャスターたちの環境底上げに繋がれば良いなと思っています.

NLPの論文を解説するポッドキャストを始めた

先月からNLP(Natural Language Processing),自然言語処理に関する最近の論文を紹介するポッドキャストをはじめました.

Leading NLP Ninja • A podcast on Anchor

経緯

私はポッドキャストが好きで,特にテック系のポッドキャストをよく聞いていました.中でもRebuild.fmbackspace.fmはお気に入りですが,彼らの話の中で,ポッドキャストを簡単に初められるAnchorというサービスを度々聞くようになっていました.特に配信する予定はなかったのですが,興味がてら触ってみると,スマホだけで簡単に録音&配信ができるようになっており,自分も何か配信したいと考え始めました.

何か配信するとなると,何かの分野ですごい人が,すごいタメになることを配信すべき,みたいな風潮が昔はあった気がしますが,今はYoutuberもすっかり普通になっています.ちょうど色々と発信したい意欲が久しぶりに高まっていたので,何か配信することに決めました.

じゃあ何を配信するかと考えたのですが,Rebuild.fmやTuring Complete FMのような超ハイスペックエンジニア達のトークは,自分のレベルを考えると難しかったので却下しました.ただMisreading Chatでは,論文を紹介して,議論する,という形でこれはやりやすそうだなと思いました.というのも,論文というのは基本的に誰でも読めるところに公開されている場合が多いですし,論文という優良コンテンツは絶え間なく流れてくるので,それを理解する努力さえしてしまえば,面白い話などしなくても,説明するというだけで,立派なコンテンツになります.

前回の記事で少し触れたのですが,読んだ論文をローカルに蓄えておくのは無意味と考えていて,デフォルト公開するようにしていました.githubのissueは本来そのような目的で使うものではないですが,タグ付けできたり,検索できたり,Markdownが使えたり,画像を簡単に貼り付けられたり(簡単に添付する形でアップできる)と,論文のまとめにはとても向いています.ちょうどこれを延長する形でやればいいかなと思い,論文ひとり語りを始めることになりました.本当はもうひとりゲストがいて,分からないところを質問したりした方が良いんですけどね.

www.jonki.net github.com

Anchorについて

Anchorの特徴として,スマホ単体で収録&配信ができる,ということを謳っています.が,正直撮って出しの配信はリスナーにとって聞き苦しいと思います.他のポッドキャストでも多く指摘されていますが,音質が悪いポッドキャストはたとえコンテンツが良くても聞き難いものです.第1回はAnchorの収録機能を使いましたが,それ以降は別に収録したファイルをアップロードしています.Anchorが素晴らしいのは実はスマホで完結する機能ではなく,音源の配信,各種プラットフォーム(Google Podcasts,Overcast等,私は10の環境で配信しています)での自動配信,アクセスログ解析,をすべて無料で提供している点だと思っています.ビジネスモデルが謎ですが,ポッドキャストの配信サーバーを自前で用意しなくてよいというのは,とても素晴らしいです.

f:id:jonki:20180921230736p:plain

良い音作りを目指して

意外にもポッドキャストの音作りにこだわって,それを記事にしている人は少ないです.現状だと,miyagawaさんとueyamaさんの記事がすばらしいリファレンスになると思います.私もそれぞれ100回ずつぐらい読んだと思います. weblog.bulknews.net note.mu

miyagawaさんなどの記事で紹介されているそれなりのマイクと静かな環境を用意すれば,それなりの音質で取れると思いますが,私もまだまだ納得しておらず,音質マニアになっていくのかなぁと思います.ポッドキャスト作成のための動画はあまりないのですが,Macであれば下記のGarage bandを作った作成動画が秀逸です.私はLogic Proを使っていますが,基本同じです. www.youtube.com

現在,色々な環境を試していますが,録音環境が整ったらまた記事を書こうと思います.とりあえず色々試している段階です.

ZOOM ズーム リニアPCM/ICハンディレコーダー  H5

ZOOM ズーム リニアPCM/ICハンディレコーダー H5

現状

現在週1ぐらいの更新を目指していて,現在第7回まで来ました.Misreading Chatさんで光栄にも紹介されたこともあり,現在1エピソードあたり100回の再生数になっています.NLP,しかも対話系の論文の紹介に偏っていて,そもそもの潜在研究者の母数を考えると,相当な数だと思っています.

配信のメリット

当初は割とネタ的に配信したのですが,いざやってみると恩恵が大きいことに気づきました.

ポストプロダクションにおいて自分の説明を聴き直すので,悪い口癖(えー,あー,とか)や分かりにくい説明,をしていることに気づけて,次回以降に向けて反省できる.

もちろん反響があると嬉しい,とかもあるのですが,論文を音声だけで説明している都合,論文を短くまとめ,わかり易く説明する必要があります.これがやってみると結構難しいのですが,このまとめて,説明する能力は,非常に重要な技術だと思っています.また普段自分の話しを聞く機会などないですから,話し方の修正のためには素晴らしい機会になっています.たぶんプレゼンとかもうまくなるんじゃないかと思います(そう思いたい).

公開して反響をもらうことによる承認欲求の充実と匿名他者への貢献

学内や社内でも勉強会をしますが,たかだか10人とかのためだけに,資料を作ったり作ってもらったりするのは,ずっと勿体ないと思っていました.Slideshareなどで共有するならまだしも,privateなネットワークに閉じるのは本当に勿体ないと思っています.基本的にそれらは,公の技術の解説であって,機密事項など普通は1mmもないです.更にそれが一流の研究者が解説した資料であれば,尚更勿体ないです.もちろん間違った解釈を公開してしまう可能性もありますし,それを非難する人もいるかもしれませんが,そんな狭量な人たちよりも,そのコンテンツによって理解が促進して感謝する人の方がずっと多いと私は信じています.

サポーター募集中

ポッドキャストの配信は手間とお金が結構かかっています.そこで今話題のPatreonというクリエーター支援サービスで,私もページを作りました.月額で2ドル,5ドル,9ドルと用意しているので,もしポッドキャスト面白いな,頑張ってほしいな,と思ってくださる方がいらっしゃったら,サポーターをご検討いただけると幸いです. www.patreon.com

みなさんもどんどん情報発信しましょう!

カーネギーメロン大学で客員研究員してきた話

2017年8月から2018年9月の頭まで,約1年間,Carnegie Mellon University (CMU)のLanguage Technologies Institute (LTI)で客員研究員をしてきた.博士号も持っておらず,大学では別の研究としていた私が,どのような留学してきたが,記憶が新鮮なうちに記事をまとめておく.なんとなくこの記事では,ですます,はやめる.尚この記事は,個人の感想であり,企業を代表した記事ではないことは初めに断っておく.

留学決定まで

私の会社は恵まれていて,海外留学制度があり,毎年留学生を何名か輩出している.社内の選考を通過すると,海外ラボで1年間,自由に研究できる権利が与えらる.その間,仕事はしなくて良いので(月報とかはあるが),ほぼ100%研究にコミットできるという,かなり留学者側には美味しい条件になっている(ただ,どういった内容で研究するか,をアピールすることで選考が行われるので,それまでの選考と完全にずれたような研究はできない.が,具体的なテーマ名を決定する必要はない).当時自分のスキルの伸び悩み,キャリアパスに悩んでいたので,割と勢いで応募した.

選考を無事通過したところで,そこから先は自分で留学先を選定し,自分で担当の教授と交渉を行う.コネがある場合はそれを使えればよいが,私の場合は特にそんなものはなかったので,興味のある先生にCVとカバーレターをいきなりメールで送りつけ,交渉を行った.この制度では,研究費,出張費などはすべて会社側で負担してくれるので,金銭的な負担がないのであれば,先生側も客員研究員を受け入れやすいという傾向があるように思える.これまでの留学経験者によると,メールに返信してもらえなかったり,金銭面の折り合いがつかなかったり,先生が退官したりと,第1志望の先生に行ける確率はそう高くはないが,金銭的な負担がないことが功をそうしてか,留学先の先生を決めることができなかった,という人は聞いたことがない.私は言語(対話)系の研究室を選んだのだが,大学院はP2Pのネットワークを研究していたので,言語系の論文など書いたことがなかった.ただある製品で言語系のUIを担当していたのが先生に気に入られたようだった.この先生はCMUのLTIに所属していた.LTIというのはComputer Scienceの部門の中で言語系に関する部門である.かなり大きな部門であり,言語系のトップカンファレンスでCMUがやたら多いのは,まずLTIによる研究だと思う.色々な先生がいるので色々な研究が同じところで行われていて面白い.雰囲気などは,こちらの方の留学日記が参考になると思う.中国・台湾人は本当に多い.

CMUの中国人コミュニティ

留学まで

留学が決定したのは,留学まで残り10ヶ月ぐらい.会社からは基本的なオリエンテーションはあるものの,大学側との契約,渡航準備,ビザ準備,滞在先手配,などは基本的にすべて自分が中心となって行う.もちろん会社側にそれぞれの手配のサポートを行う部門はあるものの,海外転勤などと異なり,その辺りのサポートは手薄い(仕事ではないのであえてそうしているフシがあるが).また,私の場合は,妻に帯同してもらえ,色々と相談しながら決めていった. また事前に先生とはSkypeで面接及び研究の話をした.学生でCMUに入学する場合,TOEFLの点数がそれなりに高くないと足切りされるのだが,客員研究員の場合,先生が英語問題なし!と言えばOKになるらしい.先生方も,色々な外国人を相手にやり取りをしているわけで,英語レベルは流暢である必要はない.そのため,学部生,院生は流暢な英語をみんな喋るが,客員研究員は英語が下手な場合が(私も含めて)結構あるように思える.

英語の勉強は,それまでDMM英会話をやっていた.ただこれもマンネリ状態だったので,GABAに通ったり,Netflixでfriendsを見たり,英語力向上に努めた.が,正直そこまで上達した実感もなく留学に突入する.技術が分かれば,正直英語のレベルはそんなに問題ではない,とか思ってる暇があったら英語勉強しろ.1年経過した今でも英語には困っている.

研究に関する勉強に関しては,論文を読んだりDNNの勉強をしたり,ガッツリと勉強したかったのだが,業務後になってしまうし,渡航準備の事務作業も多くなっていたので,正直微妙な状態で留学に突入してしまった.

滞在先,Pittsburghについて

Pittsburghはペンシルバニア州で,NYとシカゴの間あたり.緯度が高いため,冬は長く,寒い時はマイナス20度ぐらいの死の世界が訪れる.その分,夏はカラっと快適であり,今年猛暑だった日本にいなくて本当に良かったと思う.アメリカの中では中規模都市にあたり,観光に来るような街ではないが,自然の多さ,治安の良さ,物価,のバランスが非常に良い.CMUの他にピッツバーグ大などもある学術都市なので,企業もGoogleAmazonも支社を構えて,優秀な学生を捕まえている.ただし海がないので,海産物は高級で鮭ぐらいしかない.食事は日本食品も扱う中華マーケットにお世話になる.

留学前半(2017年8月〜12月)

Pittsburghに到着して二日後ぐらいにさっそく研究室のミーティングに呼ばれ簡単な自己紹介を行った.当時は先生以外みんなアジア人だった(中国・台湾・韓国).言語系,機械学習の勉強はある程度してきたものの,そこまで知識があったわけではないので,最初の3ヶ月ぐらいはテーマを探しつつ,色々な論文を読んで,DNNのモデルの追試をしたりと,基礎力の向上に努めた.その研究室のプロジェクトにコミットすることもできたのだが,研究というよりは既に開発フェーズに移っていたので,あまり恩恵はなさそうということでプロジェクトに入ることはしなかった.このときは色々なモデルの実装にハマッており,githubに毎日草を生やすのが楽しくなっていた.またスター数も留学してから150近く増えたと思う.スターをくれるのは中華系アカウントが多く,ここでも言語系のリサーチャー人口は中華系が多いなと思うことになった.

github.com

また読んだ論文はgithubのissueに上げると,他の人も見れるし自分も管理しやすいことに気づき,増やしていった.

github.com

ちなみに,LTIでは,いわゆる日本のような大部屋な研究室というのはなく,大きな建物の中に,先生の部屋やPh.Dの人(基本的に2〜4人部屋,入っている人はランダム)などの部屋が雑然と並んでいる.作業スペースが大きいのはありがたいが,日本のような研究室団らんのようなものがないので,ちょっと寂しい.同居人によっては,英語をまったくしゃべらない日も普通に多い.ミーティングを除くと基本的にみんな自分の部屋で作業している.また,大学院生は日本と違って,研究室に所属して論文を書く必要がないので,基本的に接する機会が少ない.相当やる気のある人が授業などと並行して,研究室に所属して論文を書いているようだ.

話を私の研究に戻す.色々なDNNのモデルを勉強して実装して,というフェーズは非常に勉強になったし,楽しかったのだが,そろそろ研究テーマを形にしないとまずい,と思い,研究室での進捗報告を増やしていった.私の研究室では,週に2回全体ミーティングがあり,そのどちらでも自由に進捗があれば発表して良い,という形が取られていた.また先生とも1対1ミーティングを行い,テーマを固めていく.ちょっと寄り道しすぎたかもと反省.研究テーマがある日,頭の中から出てくる,という考えは甘すぎた.

留学中半(2018年1月〜4月)

ACLやSIGDIALという学会の投稿期日が迫っていた.ACLは言語系頂点といっても過言でないトップカンファレンスであり,SIGDIALは規模は小さいものの,対話にフォーカスした最大学会であり,広く認められた学会であったため,こちらを選んで論文を仕上げた.第1稿の完成から10回近く先生に赤ペンを入れてもらえたので,非常に恵まれていたと思う.ただ年末・年始は今思い出しても,胃に穴が空きそうなぐらい辛く忙しい時期で,家か研究室にこもってずっと作業をしていた.奥さんごめんなさい. 更にSIGDIALの結果はrejectで,ダークサイドに落ちる.が,先生に励まされ,なんとか立て直した.私の先生は厳しいことで他の研究者から恐れられていたようなのだが,私にはとても良い先生であった.

留学後半(2018年5月〜8月)

SIGDIALの結果が出るまで,2つ目のテーマに移行していたのだが,rejectを受け,改めて最初のテーマをやり直すことにした.査読者のコメントは,最初は画面が霞んで見えたものではなかったが,よく見ると至極真っ当であり,非常に有益なコメントであった.このコメントをバネに実験を重ね,IEEE SLTという,音声言語処理に関する学会に投稿する.投稿後,2週間は燃え尽き状態になり,2つ目のテーマにちゃんと戻るのに時間がかかってしまった.その関係でこのテーマは留学期間中に終わることなく,留学後,企業に戻ってからも続けることになる.そして帰国間際のこの時期に,SLTから通知が届き,acceptをもらった.留学中になんとしてもacceptが欲しく,胃が痛い日々が続いていたので,この通知をもらった後は,アパートの廊下を全力で走ったのは記憶に新しい.

総括

私はもともと会社ではUI/UXのエンジニアとして働いていたのだが,言語処理に2015年ごろから興味を持ち始め,SIGDIALに聴講させに行ってもらったりと少しずつ勉強を初めた.それは28歳ぐらいのときであり,大学では言語,機械学習の勉強などまったくしなかった(更に専攻の研究も正直しょぼい).そこから海外のトップ大学で,国際学会に論文を出せたのは,我ながら夢のある話だと思った. この1年は,今後の人生においても,もっとも濃密な1年の1つになるのは間違いない.ただ海外の優秀な学生と一緒に研究することで,研究思考不足,英語力不足,を痛感する1年でもあったように思える.ただそれを鑑みても,大局的には貴重な経験であったと思う.私はこれまで素敵な研究キャリアパスを歩んだわけではないし,英語も別にうまくないのだが,こういう道があった,ということは残しておきたく,気持ちが冷めないうちに記事にしておく.留学経験者はいつも「絶対留学したほうがいいよ!」って言ってくるので,「ちっ,うぜぇなぁ」ぐらいにしか思っていなかったが,これからは私も,留学絶対にしたほうがいいよおじさん,として余生を過ごしたいと思う.

pudbで機械学習開発を加速させる

皆さん,python機械学習のコードを書くときに,どのような環境で実装してますか?私は師匠もおらず,自分なりにいろいろ試していたところpudbに落ち着きました.pudbはデバッガーでpdbにUIが付いたようなものになります.pdbC++でいうgdbみたいなもんですが,まぁガッツリ使うのは辛いです.pudbは下記の画像のようにターミナル上でグラフィカルにデバッグをできます. pudbを使うとどのようなことができるのか,この記事ではgifアニメーションをもとに紹介します.

f:id:jonki:20180816043137p:plain:w380

なぜpudbが便利か,AtomVS Codeは使わないの?

動作例の説明の前に,簡単にpudbに落ち着いた理由を説明しておきます. 私の環境だと,GPUが載ったマシンが手元になく(AWS,大学,会社),リモート(SSH経由)で開発する必要がありました.マシンが物理的に近くにあるときは,そのマシン上でVS Codeを動かす分には特に不満はありませんでしたが,リモートでの開発方法がまったく分かりませんでした.どうやらリモートプロセスもアタッチできるようなのですが,ネットワーク設定等,面倒な雰囲気があり試していません. VNCリモートデスクトップではラグが気になり,AWSでは普通GUI付きのインスタンスなんて準備していない状況です. コーディングに関してはvimでいけるものの,printデバッグとか流石に辛いよね,と探して見つけたのがpudbです.逆にリモートでも開発できるデバッガがあるのか,周りの人はどうしてるのか気になってます.

インストールと設定

pip install pudbで入ります.起動は,pudb3 hoge.pyという形で,普通のpythonを実行する形で問題ありません. 初回起動時あるいはctrl-pにより,設定画面がでます.私はここではshellをipythonに,themeをmonokai-256に変えています.ここはお好みで.

カーソル移動

j, kで上下1行ずつ移動.ctrl-dctrl-uでまとまって上下移動.vimと同じですね. こちらはカーソルを動かしているだけで,プログラムは1行目から動いて(実行して)いません.

https://media.giphy.com/media/fQVgVsDClz88mV2vYU/giphy.gif

ステップ移動

nでステップオーバー,sでステップイン(その関数に入り込む),fでその関数内の最後に飛びます.また動画にはないですが,cがcontinueのcでプログラム開始になります.ブレークポイントがない限り最後まで実行しようとします.

https://media.giphy.com/media/69BXk4CVNGPADpML8d/giphy.gif

ファイルを開く

mでファイルを検索し,開くことができます.built-inでない自分で作ったプログラムなどはimportした後でないと検索に出てこないので注意.

https://media.giphy.com/media/MSR1LemjpXBSLilkyE/giphy.gif

ブレークポイント

カーソル行のあたっているところに,bブレークポイントを貼れます.cキーでcontinueなので,次のブレークポイントまで飛びます.この際,プログラム終了前であればctrl-cにより,プログラムを一旦止めることができます.中断処理は次に説明します.(ブレークポイントがない場合,終了まで実行しようとする).またブレークポイントはpudbを終了しても保存されていますので,毎回貼り直す必要はありません.shift-bで右下のブレークポイントエリアに飛べるので,不要なブレークポイントdで消せます.またはすでにブレークポイントが貼ってあるところで,再度bでも消せます.

https://media.giphy.com/media/SIufogiT8bVMQWYTq9/giphy.gif

重い処理の中断

ctrl-cにより,プログラムを一旦停止させることができます.重い処理をしているときに途中結果などを確認するときに便利です.またこの動画ではshift-sによりStackエリアにフォーカスをあて,ファイルを移動しています.カーソルキーで目的のファイルを選択してEnterすることで,該当箇所を開くことができます.

https://media.giphy.com/media/wJ4GzGFy2IgCLossRg/giphy.gif

エラー時のデバッグ

エラーが発生すると,ポストモーテムモードになります.eによりエラーを確認できます.エラー発生箇所で,該当データなどをコマンドラインエリア上で確認したりしてエラー原因を分析します.またshift-sによりスタックエリアに飛べるので,エラーの前のコード部分に飛んでエラー分析,といったこともできます.ちなみにエリアからフォーカスを外すにはctrl-xで外せます.ショートカットがうまく動かないときは試してみてください.

https://media.giphy.com/media/7YDcddngrycxQEC5jL/giphy.gif

現在のコンソールへの出力を確認する

oにより,現在のコンソールへの出力を確認できます.Enterで戻ります.

https://media.giphy.com/media/WNlePpYFMmwZmbvs5W/giphy.gif

shellを利用する

プログラムの途中で,データの中を細かく確認したいときがあります.そのときは画面左下のコマンドラインエリアに切り替えるか(ctrl-x)か,!でshellモードに切り替えてipythonを使うこともできます.ipythonが使えるのでかなり自由にデータを確認したり,簡単なコードを実行できて便利です.エラー発生時に最も威力を発揮するモードです.ipythonから戻るにはctrl-dで戻れます.

https://media.giphy.com/media/1wn4zRyj4zhKagSPNQ/giphy.gif

再描画する

ctrl-lで崩れた表示を再描画します.

https://media.giphy.com/media/3fiCw9o5hcqFZaFZVD/giphy.gif

ショートカットを確認する

?を押せば,ショートカットの一覧が確認できます

リスタートor終了する

qにより,デバッグのリスタートや終了のメニューが選べます.

https://media.giphy.com/media/2tKz4G7BT2kc5icINP/giphy.gif

気をつけておくこと

pudbはデバッガなので,デバッガを起動しないときよりもpythonの実行速度は落ちます(体感的に半分ぐらい).そのため,大きめの辞書を一から構成する,などの処理をpudbの処理中にやるのはあまり向いていません.辞書は予めpickleなどにしておき,それを読み込むようにすることで,時間短縮ができたりします.

まとめ

前回のログTipsに続き,今回はデバッガの話をしてみました.pudbについては多くの記事を見かけるものの,まだまだ知名度は高くない気もしていて,もっと実践開発の知見が貯まればと思い書いてみました.私も自己流なのでまだまだ知らないことが多いと思いますので,こんな使い方も便利だよ,というのがありました是非コメントください.

www.jonki.net