昨年12月から今年2月にかけて転職活動をして、4月から新しい会社で働くことになりました。きっかけ前職はリブセンスという会社で、主に求人メディアを運営しています。自分は新卒入社から6年間在籍し、データエンジニア/MLOpsエンジニアをしていました。また2018年からは、京都にオフィスを構えて学生アルバイトを受け入れる仕事に取り組んでいました。京都での仕事は、CS/DSの素養のある学生さんを雇ってMLシステムの効果改善やMLOpsツールの開発を手伝ってもらうというものです。よく誤解されるのですが新卒採用が主眼ではなく、あくまでアルバイトとして学業に支障のない範囲で働いてもらい、会社はその成果を享受し、学生は報酬と就労体験を得る、というのが第一の目的でした。会社からすれば採用というわかりやすい結果を求めがちなところで、よくぞこんな企画を実現させてくれたと思います。設立以来、人事・労務・総務・コーポレートITの方々には本当にお世話になり、大変感謝しています。この仕事はとても充実したもので、学生時代の自分よりもはるかに優秀なメンバーと接し、多くの刺激を受けました。これほどの人たちを受け入れるからにはしっかり結果を残さねばと思い、試行錯誤を重ねて、少なくとも投資に見合う成果は出せていたはずです。2020年までに安定的に事業・組織に貢献できる体制が整い、これから拡大というところで、コロナ禍により状況が一変しました。採用活動は全面停止となり、対面でのペアプロやホワイトボードを使うディスカッションもできず、生産性が大きく下がってしまいました。最終的には会社の状況もあいまって、オフィスの閉鎖とアルバイトの受け入れ終了が決まりました。要はこうして手離れが良くなってしまったのが転職のきっかけです。京都オフィス以前からやっていたML基盤構築の仕事でも会社に十分に貢献できたので、良いタイミングなのでしょう。12月 会社選び11月末に上長に退職意向を伝え、年内で候補固め〜年明けから選考〜4月頭に入社というスケジュールを決めました。12月は多くの知人に話を聞きにいきました。エンジニアの同期や友人はもちろん、前職の上司や人事・PdMの先輩後輩、昔のアルバイト先のはてなでお世話になった人たちなど、十数人ほどでしょうか。この2年はなかなか人と会えなかったので、久々の楽しい時間でした。転職相談のつもりが、いけばなと連珠とサイモン・シンの話で盛り上がって気づいたら3時間、なんてこともありました。並行してカジュアル面談にも行きました。データに関わる仕事があること・前職とは別の領域の事業会社であること以外、面談先は特にこだわりませんでした。このとき役立ったのがLAPRASというサービスです。以前Scoutyという名前だった頃に会社に遊びに行ったのを思い出し、ステータスを変更してみると、予め自分でリストアップしていた会社の半数ほどからアクションがきて驚きました。どこまで再現性のある体験なのかはわかりませんが、こちらから連絡する手間が省けたのはシンプルにありがたかったです。これらを経て会社選びの軸が定まりました。まずは現在のスキルが活き、待遇が大きく下がらないこと。次に、前職と異なるデータや問題設定を扱えること。そして、そこにいる人と一緒に働きたいと思えることです。これに沿って面談した中から3社の選考を受けることに決めました。前職の元同僚からもいくつかお誘いをもらったのですが、せっかく初めての転職活動なので普通に市場に出てみたかったのと、知り合いが多いと甘えてしまいそうだったので、今回は遠慮しました。機会があればぜひ飲みましょう！1月 選考開始年明けに3社に応募して選考が開始しました。選考過程は全てリモートでした。各社の選考内容の詳細は書きませんが、どの会社でも一般的な面接と技術課題を伴う面接の両方が設定されました。多少の準備はしたつもりですが、あとでこうすれば良かったなと思うことはたくさんあります。特に仕事についての質問では、地方オフィスの立ち上げというのがエンジニアには珍しい経験だったこともあって、背景や内容を口頭でもっと簡潔に説明できるようにしておくべきでした。逆に良かったのは、職務経歴書を3つのエピソードに絞って Google Docs 1ページに収めておいたことです。前職で採用側での面接を何度かやったのですが、職務経歴書の項目が多いと、自分が聞きたい部分と相手の伝えたい部分が噛み合わないことがありました。そのことを踏まえ、自分の場合は思い切って細かいタスクや技術スタックの話を省きました。それが功を奏して、そこから聞かれたと思われる質問には、概ね自分の話したかったことを答えられたと思います。3社とも選考それ自体が良い体験で、難しい問いが投げかけられることはあっても、不快に思うようなことは一切なく、いずれも最後まで選考を受けました。2月 内定・オファー・承諾初の転職だったのと、Web系としては長い6年という在籍期間、加えて現在の待遇がそれなりに良かったこともあり、満足できるオファーが出るかは正直不安でした。しかし結果的には3社とも無事内定をもらい、待遇もすべて前職以上で全く不満はありませんでした。中にはいまの1.5倍の額を提示してくれた会社もあって驚きました。最後の決定にはかなり悩みましたが、 Ubie のオファーを承諾しました。前職はすでに色々なものが出来上がり存在している環境だったので、キャリアを自由に選べるうちに、新しく動きの速いところに入ってみたい、というのが理由のひとつです。そしてもうひとつ。自分はもともと、コンピュータやデータは生活や経済を豊かにするためのものと考えていましたが、 Ubie のプロダクトに触れていると、困っている人を助けるのにも使えるんだなと感じます。どちらが良い仕事だとかいった考えはありませんが、次は後者にも関わってみたくなりました。そんなわけで4月からは新しい環境です。なんか良いことばかり書いてて、実際前職の仕事の幕切れを除けばつらいことも特にないのですが、泥臭い話とかはいっぱいあるので、またお話しましょう！

転職活動 2022

連珠というゲームをご存知でしょうか？連珠 - Wikipedia簡単に言えば五目並べのルールを競技として成立するように整えたもので、次のようなことが定められています。15x15の盤を使う黒 (先手) のみ三三・四四・長連が禁手になり打つことができない上級者向けに、序盤の均衡を保つため着手に制約を設ける開局規定が存在する昨今の世情により自宅で過ごすことが増えた結果、私はなぜかこのゲームにドハマりしてしまい、こんな記事を書いています。連珠の序盤事情連珠は序盤の比重が極めて大きいゲームです。例えば序盤3手までのこの局面、「花月」と呼ばれる作戦ですが、実は白が4手目をどこに打っても黒が勝てることが解明されている、つまり黒必勝の局面となります。実際は前述の開局規定のおかげで、上級者の対局では黒がこの作戦を採用しても必勝手順通りに進めることはできません。しかしその場合も「制約がなければこの局面が黒必勝である」ことを前提としてゲームが進行するため、上位クラスで戦うには必勝局面とその手順についての知識をある程度身につけておく必要があります。ではこうした知識をどこから得るのか、ですが、連珠は将棋や囲碁などに比べて定石の指導書やオンラインコンテンツがそれほど充実していません。そこでよく用いられる手段が、ひとつはいわゆるAIを使った研究、もうひとつが実戦例を参考にした研究です。今回は後者についての話になります。連珠は国内での競技人口こそ少ないですが、驚くほど国際化と棋譜のデータ化が進んでおり、連珠国際連盟が運営する RenjuNet というサイトで世界中の公式戦の棋譜を閲覧することができます。The Renju International Federation portal - RenjuNetこのサイト自体は機能が限定的で、任意の序盤局面から実戦例を検索することはできないようです。その代わりに全棋譜の一括アーカイブをXML形式で提供しており(!)、有志によってアーカイブを検索するための専用ソフトが公開されています。ただし残念ながら既存のソフトのほとんどは Windows でしか動作しません。そこで今回、Webブラウザで動作する局面検索機能付き棋譜アーカイブビューワを自分で作ってみました。ブラウザで数万局の棋譜を検索するというわけでやっと本題に入ります。ここからはプログラミング寄りの話です。RenjuNet が提供する棋譜アーカイブは、利用規約上転載や再配布が許可されていません。よって、棋譜をDBサーバに保存しておいて検索機能をWebサービスとして提供する、といったやり方はできません。そのため取りうる選択肢は、棋譜アーカイブをユーザ各自が RenjuNet からダウンロードし、それをブラウザで開いて閲覧・検索できるようにする、ということになります。最新の棋譜アーカイブは7万局超の棋譜を含む20MB程度のXMLデータとなっており、局面を入力するたびに全棋譜との一致判定を行うのは流石にパフォーマンスが気になります。そこで思いついたのが IndexedDB を使う方法です。IndexedDB API - Web API | MDNIndexedDB はWeb標準に含まれる技術で、ブラウザ上のストレージにオブジェクトのインデックスを構築することができます。このインデックスは範囲検索・複合キー検索や multi-value に対応しており、 LocalStorage よりも柔軟な用途に対応できます。また JavaScript ライブラリではなくWeb標準としてネイティブに実装されているので、高いパフォーマンスが期待できそうです。今回の「局面から棋譜を検索する」という要件は、局面を符号化したものをキー・棋譜IDをバリューとする multi-value インデックスがあれば実現できるので、 IndexedDB はうってつけの技術といえます。それでは早速、実際に作ったものを紹介します。入力した局面に追従して棋譜を検索できているのがわかると思います。このWebアプリは少し前に「連珠ノート」という名前で私が公開したもので、今回の実装はその一機能として組み込んであり、以下のURLから誰でも使えるようになっています。renju-note.com機能の利用方法は以下の動画でも解説しています。www.youtube.comなお、今のところ棋譜アーカイブの読み込み処理がSafari系のブラウザで動作しないようです。XMLのパースに DOMParser を利用しているのですが、 WebKit の DOMParser はサイズの大きいファイルを扱えないのかもしれません。実装の詳細検索機能の実装は次のような構成になっています。棋譜のインデックスXMLをパースし、棋譜を抽出する各棋譜の序盤3~10手の局面を文字列として符号化するIndexedDB のテーブルに局面符号と棋譜IDを投入する棋譜の検索UIで入力された局面をインデックス時と同じアルゴリズムで符号化する局面符号を用いてテーブルを検索し、局面が出現する棋譜IDの一覧を取得するコードは全て GitHub で公開しているので、興味があればご覧ください。GitHub - renju-note/renju-note以下に主要箇所の簡単な説明を書いておきます。XMLをパースして棋譜を抽出するXMLから抽出したデータは、以降の処理で扱いやすくするため一旦そのまま IndexedDB に投入しています。ここではまだ局面の符号化はしていません。なお IndexedDB のAPIを直接触るのではなく、 Dexie.js というラッパーを使用しています。https://github.com/renju-note/renju-note/blob/v2.0.0/src/database/rif.ts#L238-L276局面を符号化する黒石・白石を1bitとして盤面を1列につき2個の整数、全部で15x2個の整数で表現し、16進数で文字列化して結合したものを局面符号としています。今の用途では単なるハッシュ値を局面符号としてもよいのですが、一応局面を再現できる方式をとっています。また、回転・反転して一致する局面は同一の符号で表現されるよう工夫しています。https://github.com/renju-note/renju-note/blob/v2.0.0/src/database/encoding.ts局面符号と棋譜IDをインデックスするこちらが棋譜検索を実現するためのコアロジックです。棋譜数x10手分の局面を扱うので、最も計算負荷が高い箇所でもあります。手元のMacBook(2018モデル)でChromeを使うと7万局のインデックスに2分程度かかりました。https://github.com/renju-note/renju-note/blob/v2.0.0/src/database/analyzed.ts#L50-L77局面から棋譜を検索する上で作成したインデックスを利用して棋譜を検索しているところです。このメソッドをUIコンポーネントから呼び出して利用しています。IndexedDB のおかげで1回の検索のレスポンスタイムは1~2秒となっています。https://github.com/renju-note/renju-note/blob/v2.0.0/src/database/analyzed.ts#L79-L117おわりに勢いで作ったWebアプリですが、ありがたいことに海外も含めて多くの連珠家の方々に使っていただいており、今後も開発を継続していこうと思います。また機能のテストには複数人の高段者の方にご協力いただきました。皆様快く引き受けてくださり、とても感謝しております。今後ともよろしくお願いいたします。IndexedDB を使ってブラウザ上である程度の規模のデータを検索可能にする方法は、ボードゲーム分野にとどまらず様々な応用ができそうなので、何かの参考になれば幸いです。

IndexedDB でつくる連珠棋譜検索

仕事では機械学習基盤の整備と古い機械学習システムのリプレースをずっとやっていました。その中で得た知見を発表する機会にも恵まれ、前年よりアウトプットが増えました。(2月) Developers Summit 2018Developers Summit 2018speakerdeck.com(8月) 機械学習工学研究会 (MLSE) 現場を交えた勉強会 #1機械学習工学研究会 現場を交えた勉強会 #1 - connpassspeakerdeck.com(9月) Machine Learning Casual Talks #6Machine Learning Casual Talks #6 - connpassspeakerdeck.comまた、9月からは京都オフィスに異動となり、関西の勉強会にも参加させてもらいました。特に学生のときにアルバイトしていたはてなの方々にはとてもお世話になっています。(10月) Machine Learning Meetup KANSAI ※LT発表Machine Learning Meetup KANSAI - connpassspeakerdeck.com会社・個人の技術ブログ等も何件か書きました。analytics.livesense.co.jpyubessy.hatenablog.comyubessy.hatenablog.comqiita.comqiita.com来年は登壇や記事の発表だけでなく、OSS貢献などの直接的なアウトプットも増やしていきたいと思います。

2018年の振り返り

秋から京都に会社のオフィスができて異動になり、以前から交流のあった id:syou6162 さんにご報告したところ、京都に拠点のあるIT企業の合同論文輪読会に誘っていただきました。自分の担当回では推薦システムに関する次の論文を取り上げることにしたので、発表用のノートを兼ねて解説を公開します。Rank and Relevance in Novelty and Diversity Metrics †    ACM RecSys 2011 - Rank and Relevance in Novelty and Diversity Metrics for Recommender Systems  from Pablo Castells www.slideshare.net推薦システムにおける Novelty, DiversityWebサービスを利用していて、以下のような経験をした方は多いのではないでしょうか。ECサイトで、すでに購入した商品と似たような商品ばかりがおすすめに表示される転職サイトで、提示されるおすすめ求人が互いに似たようなものばかりになる使われるアルゴリズムにもよりますが、一般的な推薦システムではすでに評価・選択したのと似たようなアイテムが推薦されたり、推薦されるアイテムが互いに似通ったりしがちです。しかし推薦システムの目的によっては、似たようなものを提示するのではなく、次のような性質が求められることがあります。Novelty (新規性): 今まで見かけたことのない目新しいアイテムを推薦できることDiversity (多様性): 互いに特徴が異なる複数のアイテムを一度に推薦できること本論文では、推薦システムの出力の novelty や diversity についての評価指標を提案しています。また提案指標を用いることで、各アルゴリズムの特徴を客観的に比較できることを実験で示しています。用語以下の解説では次の用語を使います。ユーザ: 推薦システムの利用者アイテム: 推薦システムがユーザに推薦する個々のもの (商品など)ランキング: 一度の推薦でまとめて提示されるアイテムのリストレーティング: ユーザのアイテムに対する評価Explicit (明示的) なレーティング: ５段階のスターなどImplicit (暗黙的) なレーティング: クリックしたかどうかなど先行研究と問題点Novelty, Diversity の改善手法と評価指標推薦システムの Novelty, Diversity を改善する手法は本論文以前にいくつか提案されています。Novelty については、Zhou 2010 が協調フィルタリングとグラフのスコア伝播を用いた手法を提案しています。この研究では評価指標として、ランキング中のアイテムの平均自己情報量 (各アイテムを評価したユーザの割合の対数) を用いています。また Celma 2008 では、 アイテム間の類似関係によるアイテムの発見されやすさを考慮しています。Diversity については、Ziegler 2005 が貪欲法により再ランキングを行う手法を提案しています。また Zhang 2008 ではユーザの選好とアイテム間の類似度に基づく二次最適化問題を解くことで diversity の向上を試みています。これらの研究では評価指標として、ランキング中のアイテム間相互の距離や非類似度を用いています。評価における問題点これらの先行研究について、本論文では次のような問題を指摘しています。まず novelty, diversity に対する定義がそれぞれ異なっており、それらの関係性についてもあまり議論されていませんでした。そのため各研究で独自の評価指標が用いられ、手法同士を客観的に比較することが困難でした。またいくつかの研究では評価指標に次のような欠点がありました。Ranking-unawareness: ランキング中のアイテムの順位変化による影響が考慮されていないRelevance-unawareness: ユーザにとってのアイテムの関連度 (適合度) が考慮されていないこういった問題に対して、本論文ではユーザの行動モデルを用いて novelty, diversity とその関係性を定義できると主張しています。また、この行動モデルを用いて novelty, diversity の評価指標を一般化・定式化することを提案しています。Discovery, Relevance, Choice に基づくランキング評価指標Discovery, Relevance, Choice モデル提案されるユーザ行動モデルは次のようなものです。まず、次の３つのユーザとアイテムの関係を定義します。Discovery (発見): アイテムがユーザに発見される (見られる, 知られる, etc.)Relevance (関連): アイテムがユーザと関連する (好まれる, 役立つ, etc.)Choice (選択): アイテムがユーザに選択される (クリックされる, 買われる, etc.)ユーザとアイテムにこれらの関係が成立していることを、二値変数を用いて , ,  と表します。またそれらの確率を , ,  あるいは , ,  のように表します。例えばECサイトなら、ユーザにが閲覧した商品は  であり、ユーザが欲しいと思う商品は  であり、ユーザが購入した商品は  とである、とみなせます。ここで簡単のため次が成り立つとします。アイテムがユーザに発見されるかどうか (discovery) と関連するかどうか (relevance) は独立であるユーザは自分に関連する () アイテムを発見する () と必ずそれを選択する ()ユーザは自分に関連しない () アイテムは選択しない ()これにより次の式が成り立ちます。以降ではこのモデルを根幹として、アイテムの novelty やランキングの novlety, diversity をモデル化します。ランキング評価指標の一般化本論文が提案する一般化されたランキング評価指標は次の式で表されます。 がアイテムの novelty であり、後ほど discovery, relevance, choice を用いてモデル化されます。 はコンテキストと呼ばれる変数で、ユーザが発見済みのアイテム集合や、アイテムの人気や普遍性をモデルに組み込むために使われます。これによりアイテムの novelty がユーザとアイテムの現在までの関係によって変化することをモデル化できます。アイテムの novelty は  によって重み付けされます。つまり、どれだけ novelty の高いアイテムでも、それがユーザに選択されれる可能性が低ければランキングの評価に寄与しない、という条件をつけることができます。これにより先行研究に対して指摘されていた rank-unawareness や relevance-unawareness の問題を克服することができます。アイテムの Noveltyここからは上述の一般化された評価指標から diversity, novelty を導くため、各項を具体的に定式化していきます。まず  の具体的なモデルとして、次の２種類が提案されます。Popularity-based  Noveltyひとつは novelty を「ユーザがまだそのアイテムを発見していない可能性」とみなした次のモデルです。 には各アイテムを評価したユーザ数などが用いられます。観測されたレーティング全体から  を推定する方法は後ほど紹介します。なお本論文では確率  の代わりに情報量  を使う方法も紹介されますが、実験では省略されるため割愛します。Distance-based Noveltyもうひとつは novelty を「ユーザが既に発見したアイテムとの距離」とみなした次のモデルです。 は  においてアイテム  が選択された場合にアイテム  が選択される確率であり、 はアイテム  の距離 (または非類似度) です。 には、ユーザがランキングを閲覧する前に発見済みのアイテム集合や、ランキング中で対象アイテムの前に出現したアイテムの集合とします。特に後者はランキングの diversity の評価指標を導くのに使われます。ランキングの Novelty, Diversity上記のモデルにより各アイテムの novelty を定式化できたので、次にこれを用いてランキングの novelty, diversity を定式化します。Browsing モデルランキングを閲覧する際には、ランキング上位のアイテムほど選択されやすく、下位のアイテムは選択されにくくなると考えられます。これは上記のモデルにおいて、  が  の  中での順位に依存すると考えることでモデル化できます。ここで、アイテムとユーザの関連度  はコンテキストの影響を受けない (ユーザの過去の行動やランキング中の他のアイテムに左右されない) と仮定すると、次の関係が導かれます。さらに、ランキング  において順位  のアイテム  が発見される確率  が、   についての減少関数  で表されると仮定すると、  は次のように表されます。以上の仮定を導入したモデルを browsing モデルと呼びます。Browsingモデルにおける  は次のように定式化されます。実際の  としては nDCG で用いられる  などをそのまま使うことができます。さて、以上によりランキングの novelty, diversity は次のように計算できます。ランキングの Noveltyランキングの novelty の算出においては、ユーザがランキングを閲覧する以前に知りうる情報をコンテキストとして考えます。すなわち  には事前に観測されたレーティング等を与えることになります。Popularity-based novelty を用いたランキングの novelty は次のようになります。これを論文では expected popularity complement (EPC) と呼んでいます。Distance-based novelty を用いたランキングの novelty は次のようになります。これを論文では expected profile distance (EPD) と呼んでいます。ランキングの Diversityランキングの diversity の計算では、対象のランキングそのものの情報をコンテキストとして考えます。すなわち  となります。ランキングの diversity は次のようになります。これを論文では Expected Intra-List Diversity (EILD) と呼んでいます。レーティングによる Discovery, Relevance の推定以上によりランキングの novelty, diversity を定式化できました。実際にこれらを計算するためには、観測済みのレーティング等の情報を用いて  や  を推定する必要があります。以下ではレーティングを関数  によって表します。Discovery の推定コンテキスト  のもとでアイテム  が発見済みである確率  の推定値は次のように求められます。論文では他のバリエーションについても述べていますが、ここでは割愛します。Relevance の推定 が explicit なレーティングの場合、そのままでは確率  として扱えないため、 ( は微小な差異を無視するための定数) を用いて次のように変換します。論文では implicit なレーティングについても述べていますが、ここでは割愛します。評価実験本論文では diversity, novelty の向上手法ではなくその評価指標を提案しています。そのため実験は「評価指標の評価」を行うためのものとなります。実験では、提案指標を用いることで各種レコメンドアルゴリズムや novelty, diversity アルゴリズムの差異を客観的に捉えることができていることを示しています。評価に用いられているデータセットは次のとおりです。MovieLens 1M: 映画に対する5段階の explicit なレーティングLast.fm: 楽曲アーティストに対する implicit なレーティング (視聴ログ)比較対象の推薦アルゴリズムは次のとおりです。MF: Matrix FactorizationCB: Content-Based FilteringUB: User-Based Collaborative FilteringAVG: Average RateRND: Randomこれらに対して上記の EPC, EPD, EILD をランキング上位50件について計算した結果が次のグラフとなります。(† Figure 2. より)Popularity-base vs. Distance-baseまずは popularity-base, distance-base の novelty によって各アルゴリズムがどう特徴づけられるかを見てみます。グラフの上段は relevance を考慮せずに () 各指標を算出したものです。ここからコンテンツベースのアルゴリズムとレーティングベースのアルゴリズムの違いが顕著に読み取れます。Popurality-base のEPCではコンテンツベースのCBがレーティングベースのUB, MFよりもスコアが高いのに対し、Distance-base のEPD, EILDでは逆にCBのスコアが低くなっています。このことから、提案指標で用いられる popularity-base, distance-base の novelty はそれぞれ各アルゴリズムの特徴を捉えるのに適していると言えそうです。Relevance-awareness の効果次に、提案指標により relevance-unawareness の問題に対処できることを示しますグラフの下段が relevance を考慮した指標となっており、これを上段と比較するとその効果が見て取れます。Relevance-unaware な指標ではAVG, RNDが高い novelty, diversity を示していたのに対し、 relevance-aware な指標ではMF, UBがそれらを上回っています。このことから、 relevance を考慮することで diversity, noveltyが高くともユーザとの関連度が低いアルゴリズムを不当に高く評価しないようにできると言えます。Relevance-aware な指標では、explicit なレーティングに対してはではMFがUBを上回っており、 implicit なレーティングに対してはそれが逆転しています。これらは relevance を考慮しない場合は似たような値となっていたので、 relevance を考慮することで diversity, novelty があまり変わらないアルゴリズム同士の優位性を評価できると言えます。Rank-awareness の効果最後に、提案手法により rank-unawareness の問題に対処できることを示します。これを示すには、同じランキングを様々な diversification 手法により再ランキングした結果を比較する必要があります。実験ではMFの結果を次のような手法で再ランキングした結果を比較対象として取り上げています。IA-Select (Vargas 2011)MMR (Ziegler 2005)NGD (Carbonell 1998)実験結果は次の表にまとめられています。(† Table 5. より)Relevance を考慮した場合のみについて、いくつか結果を見てみます。ベースラインとなるMFを上回るスコアを得ている手法はそれほど多くありませんが、IA-Select は全体的にベースラインを上回る結果を残しています。順位によるディスカウントなしの場合 () とありの場合 () を比較すると、IA-Select は MovieLens, Last.fm の両方でスコアを上げていますが、MMR, NGD はスコアを下げていることもあります。このことから、MMD, NGDでは元のランキングにおいて下位になっている relevance の低いアイテムが上位に浮上している可能性が考えられます。このように、提案手法を用いることで rank-unaware な指標では発見できなかった各手法の特徴を発見できています。おわりに今回は特定の手法ではなく評価指標に関する論文を選んでみました。検索や推薦などのシステムでは、ユーザがシステム求める性質が様々なので、それぞれの目的に応じて適切な指標を選ぶ必要があります。本論文で提案される一般化された指標はそういった様々な場面で応用が効きそうです。またユーザ行動モデルから評価指標を導く一連の考え方は、評価方法を新しく考える必要があるようなケースで参考になりそうです。

論文紹介: Rank and Relevance in Novelty and Diversity Metrics

最近仕事では機械学習を使ったアプリケーションをKubernetes上で運用することが多くなっています。MLOpsのような言葉も次第に浸透してきたりと、システムとしての機械学習をどう運用していくかが活発に議論されるようになってきました。運用に頭を悩まされてきた身としては心強い限りです。この記事ではKubernetes(以下k8s)のようなコンテナオーケストレーション技術が、機械学習システム(以下MLシステム)の実行基盤としてなぜ適しているのかについて考えてみました。注意点として、私はMLアルゴリズムの専門家ではなく、またLinuxやコンテナ技術の専門家でもありません。あくまで仕事としてMLシステムを運用するためにk8sを利用している立場からの考察です。TL; DR:MLシステムの運用には次のような課題が存在する目的によって求められるワークロードの形態が異なる一時的・断続的に大量の計算リソースを必要とする実環境での試行錯誤に伴ってシステムが変遷するコンテナオーケストレーションは次のことを可能にするプロセスの実行環境とそのライフサイクルを独立して管理する異なるワークロードを同一のインフラ上でスケジューリングする→ MLシステムの運用課題はコンテナオーケストレーションによって解決しやすい機械学習システムの運用課題1 - アーキテクチャの多様性MLシステムのアーキテクチャは非常に多様です。計算としての機械学習は「学習」と「予測」という２つのステップから構成されますが、この２つをどのような形態のワークロードとしてシステムを構成すべきかは目的によって異なります。最もシンプルなアーキテクチャは、状態を持たない単一のバッチ処理として学習・予測を一気に行うものです。例えばECサイトで１日１度アイテムをレコメンドするメールマガジンを送信したいといったケースはこの形態で十分と思われます。ここから一歩進んで、新規データに対してオンラインで予測を行うこともよくあります。ECサイトの例であれば、新規ユーザに対して登録後すぐにいくつかアイテムを推薦したい、といったケースが考えられます。オンラインでの予測処理は、リクエストを受けてレスポンスを返すまでの短い時間で計算を完了できることもあれば、リクエストをキューイングしてある程度時間をかけて処理してから改めて結果をプッシュすることもあります。予測だけでなく学習の一部または全部をオンラインで行う場合も考えられます。Matrix Factorizationのようなアルゴリズムを用いたレコメンドで、ユーザが新しいアイテムを評価した場合にモデルを再学習するようなケースがこれに当てはまります。これらに加えて転移学習のような既存のモデルを部分的に更新するような場合まで考えれば、状況はさらに複雑化します。これ以上は詳しく述べませんが、要するに一つのパターンでは解決できないほどMLシステムのアーキテクチャは多岐にわたるということです。2 - リソース消費の非連続性システム形態が多様化しても消費する計算リソースが多くなければ、運用上の問題はそれほど大きくならないかもしれません。しかしMLシステムは概して通常のシステムより大量の計算リソースを消費します。機械学習の学習処理は、簡単に言えば大量のデータに複雑なアルゴリズムを適用して有用な関数(モデル)を獲得するという計算です。処理に必要な計算リソースを肥大化させる要因は、たいていデータとアルゴリズムの両方にあります。このため計算量を削減することがそもそも困難であり、資金を投入して計算リソースを確保することでしか問題が解決できないこともよくあります。しかし多くの場合、計算リソースを大量に消費するのは主に学習ステップであり、予測ステップに必要な計算リソースはそれに比べるとずっと少ないのが普通です。さらに学習は１日や数日に１度、時には数ヶ月に１度行うだけで済むこともあります。画像認識や自然言語処理など、問題が汎用的であるほどモデル全体の学習の頻度は少なくて済みますが、これは学習によって獲得したモデルが長期に渡って価値を発揮できるためです。このことはそれ自体MLシステムの長所でもありますが、運用上は悩みの種でもあります。一定期間に１度しか行われない計算のために常に大量の計算リソースを確保しておくのは大きな無駄となります。しかし複数のシステムを同一のインフラに同居させようとすれば、マシンのプロビジョニングは複雑化し、システムが採用できる技術の制約は多くなります。3 - アーキテクチャ・運用レベルの時間的変化MLシステムの効果は事前に交差検証やバックテストである程度確認できるものの、本質的には実環境で実データを使って運用してみなければ不確実性が大きいものです。このためMLシステムの開発プロジェクトでは早い段階でシステムを実環境にデプロイし、そこで得られるフィードバックをもとに試行錯誤を繰り返す必要があります。試行錯誤の過程ではライブラリや収集・利用するデータはもちろん、クラスタリングか次元削減かといった問題設定までもが変わることもあります。またシステムがある程度の効果を上げるようになれば、学習や予測の頻度を高くしたり、複数のモデルの並行テストやフェイルオーバーが求められることもあります。これは運用においてシステムの実行環境やリソース要件が頻繁に変更されることを意味します。変更のたびにマシンの構築やプロビジョニング、キャパシティプランニングが必要となれば当然運用の負担は大きくなります。さらにMLシステムが価値を発揮するにつれ、ビジネスの売上・利益がそれに強く依存するという状況が生まれることすらあります。もちろんこれは悪いことではないのですが、システムの可用性が失われればビジネス上の損失が生じることを意味するため、運用には相応の信頼性が求められることになります。コンテナオーケストレーションがもたらすもの1 - プロセスの実行環境とライフサイクルの独立化Linuxにおける計算処理の単位はプロセスです。コンテナはプロセスを名前空間・ファイルシステム・ネットワークといった実行環境ごとカプセル化したものです。これを応用すればアプリケーションを依存ライブラリごとイメージとしてアーカイブするといったことも可能になります。プロセスの実行パターンは成否を表すコードとともに終了するか無限に実行を続けるかの２通りしかありません。従って高度なシステムでは、複数のプロセスを時にはマシンにまたがって協調動作させることになります。常に一定数の実行プロセスを維持するサーバや、巨大な計算を並列処理するジョブなどがこれにあたります。コンテナオーケストレーションの導入により、協調する複数のプロセス（＝コンテナ）とそのライフサイクルをひとつのワークロードとして管理できるようになります。多くのオーケストレーションツールは典型的なワークロードのパターンを予め提供しています。例えばk8sでは１つ以上のコンテナからなるワークロードの最小の単位をPodとし、常に一定数のPodを実行するようなワークロードにはReplicaSet、加えてPodの世代管理を行うワークロードにはDeploymentといったビルトインのパターンを用意しています。バッチジョブに適したワークロードパターンとしては、全てのPodを完了まで実行するJob、Jobを定期実行するCronJobなどがあります。コンテナオーケストレーションの特徴は、プロセスのライフサイクルを実行環境とは独立して管理できる点です。実行環境が全く異なるプロセスであっても、ライフサイクルが同じであれば同じパターンが適用できます。これにより従来はミドルウェアやフレームワークが担っていたプロセス管理の役割をオーケストレーションツールに移譲でき、アプリケーションは本来の計算処理とインタフェースの提供に集中できます。2 - 異なるワークロードの同一インフラ上でのスケジューリングコンテナオーケストレーションのもうひとつの役割は、コンテナに対するコア・メモリ・ボリュームといったリソースの割当です。ワークロードが追加されると、オーケストレーションツールは指定されたリソース要件に基づいてクラスタにコンテナ群をスケジューリングします。このリソース要件の指定とスケジューリングの仕組みもまたプロセスの実行環境とは独立しています。例えば全く異なるライブラリやフレームワークを用いて実装されたWeb APIサーバとバッチジョブを同一のクラスタ上でスケジューリングすることも可能です。さらにk8sのようなツールはクラスタを構成する各マシンの負荷状況に応じてワークロードを実行するマシンを選択したり、障害に備えてレプリケーションを分散する機能を備えています。これらの機能を利用すれば、複数のシステムを効率的に運用しつつ信頼性を保つことができます。機械学習システムとコンテナオーケストレーションの親和性ここまでの内容で想像がつくように、先に挙げたMLシステムの運用課題はコンテナオーケストレーションを用いることで解決しやすくなります。まずワークロード形態の多様性の問題には、オーケストレーションツールが提供する汎用的なパターンを目的に応じて選択することで対処できます。k8sであればMLシステムに最も適用しやすいのはJobでしょう。Jobは処理の完了を待つだけでなく、異常終了時のリトライやタイムリミット超過時の強制終了などの機能も持っています。またReplicaSetやDeploymentはオンラインでの学習・予測を行うサーバを実行するのに役立ちます。さらにはSparkやTensorFlowのような大規模な分散処理クラスタをk8sのワークロードパターンを用いて構築することも可能です。次にリソース消費の非連続性の問題には、複数のワークロードを同一インフラ上でスケジューリングすることが有効です。複数の定期実行されるMLジョブを運用する場合、それらの実行時間をずらしてリソースを共有するといった単純な戦略が考えられます。あるいはMLシステムと他のアプリケーションを同居させるという選択肢もあります。ディスクIOやネットワーキングのようなマシン全体のスループットの制限には注意が必要ですが、MLシステムの消費するリソースの大部分はコアやメモリであるため、スケジューリングにおける制約は比較シンプルになります。最後にアーキテクチャ・運用レベルの時間的変化についても、先の２点と同様のことが言えます。システムが進化してアーキテクチャが大幅に変わったとしても、新たなインフラを構築せず既存のインフラ上でワークロードパターンを組み換えるという選択肢を取ることができます。これにより専用のインフラを慎重に設計する時間的猶予が得られたり、成功するかわからないアーキテクチャを一時的に試せるといった利点もあります。リソース消費の増加に対処したり冗長性を確保するためにはクラスタの拡張が必要ですが、その際のマシンのプロビジョニングが個々のシステムに依存するようなことはなくなります。これからMLシステムの重要な運用課題のいくつかはコンテナオーケストレーションにより解決できると思われます。そしてこの潮流はまさに始まったばかりであり、今後さらなる技術的発展が期待されます。記事の締めくくりとして、自分がいま気になっている技術をいくつか取り上げたいと思います。Argo - k8sのCRDとして実装されたワークフローマネージャgithub.comLuigiやAirflowのようなワークフローマネージャをk8sのCustom Resource Definition(CRD)として実現しようというプロジェクトです。個々のステップがコンテナ化されたジョブを、直列・並列・繰り返しなどを含む柔軟なパターンで記述できます。CRDはKubernetesのJobやDeploymentのようなワークロードパターンをユーザが定義できる機能です。Argo UIと呼ばれるUIが提供されているほか、ロードマップでは様々なトリガーへの対応を予定しています。Seldon - k8s上での汎用MLプラットフォームgithub.comk8s上に汎用的なMLプラットフォームを構築しようというプロジェクトです。特定のMLライブラリに依存しない汎用的な仕組みのもとでTensorFlowやSparkなどのフレームワークを統一的に運用するという、非常に野心的な取り組みを行っています。成功するかどうかは未知数ですが、開発は活発に続けられているようです。RiseML - k8s上での深層学習プラットフォームgithub.comk8s上に深層学習プラットフォームを構築しようというプロジェクトです。Seldonに似ていますが、こちらは深層学習フレームワークに特化しています。またコードは公開されているものの、基本的にはPaaSとしてサービスを提供しているようです。Kubeflow - k8s上でのTensorFlow構築ツールgithub.comTensorFlowクラスタとその付随要素をまとめてk8s上に構築しようというプロジェクトです。TensorFlowのTrainingワークフローをCRDとして実装しているほか、JupyterHubやTensorFlow Servingのような付随するシステムをまとめて立ち上げることができます。TensorFlowクラスタを自前で運用したい場合には有効かもしれません。長くなりましたがこのあたりで終わります。参考資料O'Reilly Japan - 仕事ではじめる機械学習Machine learning on kubernetes

機械学習システムの運用課題とコンテナオーケストレーションがもたらすもの

という発表を社内勉強会でしてきました。

５分ちょいでわかった気になるラムダアーキテクチャ

speakerdeck.com社内LT大会でやった小ネタです。Goの標準ライブラリの正規表現実装呼んでたら haya14busa さん出てきてすごい。

正規表現のテストカバレッジを測りたかった話

社内のLT大会にて表記のタイトルで発表しました。資料は以下に公開しています。speakerdeck.com最近仕事ではもっぱら機械学習システムの開発を行っていますが、モデルは作れても継続的な運用や実環境での安定稼働にはまだまだ苦労することが多く、いろいろと模索しているところです。そんな中で今なんとなく考えていることをまとめてみた、という程度の内容ですので、わかったように書きつつわかっていないこともあります（ご容赦ください）。スライドでも紹介している以下の２つの資料は、運用まで面倒をみる機械学習エンジニアとして非常に参考になる内容で、おすすめです。Machine Learning: The High Interest Credit Card of Technical DebtRules of Machine Learning: Best Practices for ML Engineering

エンジニアとしての機械学習との付き合いかた

word2vecによって得られる語の分散表現を用いて文書間の距離（非類似度）を計算する手法についての論文を読みました。せっかくなので解説してみます。[1] Kusner, Matt J., et al. “From word embeddings to document distances.” Proceedings of the 32nd International Conference on Machine Learning (ICML 2015). 2015.TL;DRこの論文では Word Mover’s Distance(WMD) という文書間距離の計算手法を提案しています。提案手法は手っ取り早く言うと次のようなものです。文書A, B間の距離 =語xを語yに対応付けるコスト =例えば次の文書  と  または  との距離を考えてみます。ストップワードを除いた上で、各文書の意味の似ている語同士を対応付けます。さらに各対応付けのコストを語同士の分散表現の距離として算出し、その総和を求めます。下の図は語の対応付けとそのコストを矢印とそれに付与された値で示しています。(Figure 2. (Top) from [1])このコストの総和を文書間の距離と考える、というのがWMDのアイデアとなります。図では  に対する距離が  のほうが  よりも小さくなっています。論文では文書の近傍を求めるタスクにおいて、多くのデータセットで提案手法により良好な結果が得られたとしています。(Figure 3. from [1])特に twitter のような語数の比較的短い文書からなるデータセットでは、従来手法より良好な結果を残しているようです。以下では主にWMDの計算アルゴリズムについて、もう少し詳しく解説していきます。従来の文書類似度計算における課題単純な文書類似度としては Bag-of-Words (BoW) 表現のコサイン値がよく用いられます。しかし文書同士の共通語が少ない場合、BoWでは文書間の意味的な類似度を測ることが困難です。例えば上記の 文書 ,  の単純なBoW表現は次のようになりますが、これらは共通語を持たないためベクトル同士のコサイン値はゼロとなります。従来ではLSIやLDAなどの次元削減手法を利用してこの問題に対処することが試みられていましたが、精度面でそれほど大きな改善を実現するには至っていませんでした。最近ではニューラルネットの発達に伴い、文書自体の分散表現を計算する手法も提案されています。これらの手法は高い精度を実現できると主張されていますが、NN特有のハイパーパラメータチューニングが必要となる場合もあります。WMDの考え方WMDは上記の問題を別のアプローチで解決しようとしています。上記のとおり文書 ,  には共通語こそありませんが、人間の目には media と press のようなそれぞれの語同士は非常に近い意味をもつように見えます。word2vec を用いれば、このような語の意味類似度を捉えた分散表現ベクトルが得られます。WMDではこの性質を利用して文書間の距離を求めます。その考え方は大雑把に言えば、 文書Aの語を類似する（=分散表現間の距離が小さい）語で置き換えて文書Bに変換できるならば、文書A, Bの類似度は大きい（=距離が小さい） というようなものです。このような考え方に基づいて、WMDでは文書A,B間の距離を、A,Bの語同士を対応付けて文書Aを文書Bに変換するのにかかる「コスト」として計算します。語の対応付けのコストまずある語を別の語に対応付ける場合のコストについて考えます。意味の似ている語同士の対応付けはコストが低い、という特性を満たすよう、語同士の分散表現のL2距離をコストとします。すなわち、語  を語  に対応付けるコスト  を次のように定義します。文書の変換コスト次に、語の対応付けに基づく置き換えにより、ある文書を別の文書に変換することを考えてみます。この置き換えにおいては文書中の意味語（ストップワード以外の語）のみに注目し、語順などは考慮しないものとします。先程の  を  に変換する場合、各語を次のように対応付ければよさそうです。この変換のコストは、単純に考えれば各対応付けのコストの総和とするのが良さそうです。イメージとしては、この総和が小さいほど文書は意味的に類似すると言えそうです。問題の一般化これまでの例では意味語の数が同じで、各語も意味的にほぼ１対１に対応づけることができました。しかし次のような文書同士では、単純に語を置換することでは文書を変換できません。任意の２文書間の距離を一貫した基準のもとで計算するには、単純な置き換えによる変換ではなくより一般化された方法を考える必要があります。そこでまず文書の特徴表現として語の頻度分布を用います。例えば ,  の特徴ベクトルは次のようになります。ここでベクトルの各成分は、文書中の語の正規化された出現頻度(TF)となっています。さらに各語に対応する成分を変換先の文書の複数の語に分配することで、語の頻度分布全体を変換先の分布に移すことを考えます。この変換を次のような行列  で表します。例えばこの行列の7行目は、  における語 speak の重み1/3のうち、それぞれ1/4と1/12をそれぞれ  の語 greets と press に移すことを表します。この対応付全体のコストは、それぞれの語同士の対応コストに分配量に応じた重みかけた値の総和として計算できます。ここで、上の行列はあくまで考えられる変換のひとつでしかありません。WMDではそのような変換の中でコストの総和が最小となるものを求め、このコストの総和が文書間の距離とします。最適化問題としての定式化と解法上記の内容を最適化問題として定式化すると次のようになります。行列  の各行ベクトルは、元の文書中の各語に対応します。その各成分は、元の文書の語分布におけるその語の成分を、変換先の文書の各語にどのように分配するかを表します。よって行の成分の総和は、元の文書の語分布における各語の成分と一致します。同様に行列の各列ベクトルの成分の総和は、変換先の文書の語分布に各語の成分と一致します。コストが最小となる変換のコストを文書間の距離とするので、上式を制約条件とする次の最適化問題を解くことができれば文書間の距離が求まります。実は上の最適化問題は Earth Mover Distance (EMD) と呼ばれる最適化問題の特殊な形式になっています。EMDを求めるアルゴリズムは既に知られているので、それを用いればWMDを計算できます。この記事ではEMDについて詳しく解説することはしませんが、以下の記事が詳しいですので興味のある方はご参照ください。aidiary.hatenablog.comWMDの長所と短所WMDの長所としては次のような点が挙げられます。精度が高い直感的にわかりやすいハイパーパラメータが存在しないためチューニングが不要逆に短所としては次のような点が挙げられます。計算量が大きい（類似度計算１回で語数  に対して [tex: O(p3 \log p)] ）このような性質から、単なるBoWの類似度では望ましい精度が得られず、かつ計算量が多くても許容できるようなケースでWMDが有効であると考えられます。なお、ある文書に対する近傍文書を上位k件まで取得できればよいようなケース（文書検索など）では、WMDよりも計算量の小さい下界を利用し、計算量を大幅に抑えることができます。今回はその詳細については割愛しますが、論文には精度の変動の評価も含めて詳しく書かれているので、知りたい方は論文を読まれることをお薦めします。まとめ語の分散表現を文書類似度や文書特徴量に応用する手法は多いですが、ハイパーパラメータチューニングなしに高い精度を実現できるWMDは特に魅力的に写ります。また最近ではWMDを教師あり学習に拡張した論文なども出ているようです。Huang, Gao, et al. “Supervised Word Mover’s Distance.” Advances in Neural Information Processing Systems. 2016.機会があれば実問題で試してみたいものです。追記2017/04/05gensimを使うと学習済みモデルを用いて簡単にWMDを計算できるようです。hironsan.hatenablog.com

Word Mover's Distance: word2vecの文書間距離への応用

なんとなく。AWSGCPはちょっと触ってたけど、AWSは間違ってお金かかってしまいそうという謎の不安があって社会に出るまで敬遠していた。EC2, ELB, S3, Beanstalkのような基本的なサービスに加えてRedshiftとEMRをかなり触ることになった。覚えたり調べたりすることが永遠に尽きない。Ruby今年一番書いた言語。もともとPythonに慣れていたので、スコープに由来のわからない変数やメソッドが現れるのに未だ違和感を覚えてしまう。ライブラリが豊富すぎて技術選択で迷いがちなPythonに比べ、Bundler, Rake, RSpecなどのほぼ必須のエコシステムに乗っておけばそれほど道を踏み外さないのは楽だった。Python意外と自分で書くことは少なく、どちらかというとレビューする事が多かった気がする。自分にとって書いてて一番しっくりくるのは相変わらず。ちょっとしたスクリプトなどはまずPythonで書いてる。Scala今年後半から使い始めた。静的型付の言語は久々だったけど、以前経験したC, C#, Javaに比べて圧倒的に馴染みやすかった。心地よい学習曲線に乗って学べる印象。ES2016ほんの少しだけ触った。大したことをしてないので大した感想はない。JavaScriptって今こんな感じなんだ、ふーん。Ansibleちょっとした環境の構成管理ツールとして使った。最初に覚えなければいけない概念が少し多かったが、公式のベストプラクティスを参考にするとうまく軌道に乗れた気がする。Fluentd使うプラグインのコードを読む機会が多かった。よく使われてメンテされてるプラグインとそうでないものでの品質の落差が激しいのを実感した。Spark今年触ったものの中で一番面白かった。分散処理でスレッドセーフ性が問題になったり、遅延評価が影響してちょっとしたコードの変更が予期しない結果を産んだりといろいろ悩んだけど、その分学びは多かった。来年はSpark StreamingやSpark MLも本格的に使ってみたい。

今年触った技術を雑多に

はじめにSparkの基本的な仕組みデータコレクションの操作のためのAPI1. RDD - ネイティブなオブジェクトのコレクション2. DataFrame - 基本的な型の値からなるテーブルRDD v.s. DataFrame3. Dataset - RDDとDataFrameの長所を併せ持つコレクションRDD, DataFrameからDatasetへの書き換えDataFrameからDatasetへRDDからDatasetへおわりにはじめにLivesense Advent Calendar 2016の11日目の記事です。昨今ではAmazon Elastic Mapreduce (EMR)などのマネージドサービスの登場により、分散データ処理基盤を構築・運用するハードルは劇的に下がっています。Apache Sparkはオンメモリ処理を基本とした高速で汎用的なフレームワークとして人気があります。spark.apache.org2016年の初頭には新しいDataset APIを搭載したSpark 2.0がリリースされました。RDDとDataFrameという2つのAPIを処理の特性に応じて使い分けていましたが、Spark 2.0では多くの処理をDataset APIひとつで実現できるようになっています。従来のRDDやDataFrameを用いた処理は、大抵の場合そのままか多少工夫することでDatasetでも実現できます。RDDやDataFrameについて書かれた記事の方がよく見つかります。この記事では、RDDやDataFrameに関するノウハウをDatasetに応用できるよう、従来のAPIとDatasetを比較しながら紹介していきます。Sparkの基本的な仕組みSparkでは多数のレコードからなるデータを幾つかのパーティションに分割し、複数のコンピューティングノードに分配して展開します。パーティション毎に独立に適用できる処理はノード内で完結し、複数のパーティションのレコードを参照・集約する処理はその都度ノード間でデータの再分割・再分配を行うことでデータを処理していきます。Sparkの仕組みはHadoopのMapReduceと似ていますが、Hadoopが毎回のステップ終了時にHDFSにデータを書き出すのに対し、Sparkではデータをメモリ上に展開したまま複数のステップを連続して実行できるのが特徴です。HadoopよりSparkのほうがパフォーマンスが高いとされています。データコレクションの操作のためのAPIHadoopのプログラミングモデルは、入力データから出力データへの変換をMapReduceとして記述するというものでした。対してSparkでは、各ノードに分散しているデータをプログラムから単一のオブジェクトとして操作できるAPIを提供しています。Sparkにおいてデータのまとまりを扱うAPIとしては、RDD, DataFrame, Datasetの3つが存在します。APIであるRDDが用意されており、Spark 1.3ではDataFrameが追加されました。APIとなり、DataFrameはDatasetに統合されました。以降ではこれらのAPIの特徴を順を追って紹介していきます。Scalaを用いています。1. RDD - ネイティブなオブジェクトのコレクションRDDではデータをネイティブな(JVM)オブジェクトのコレクションとして扱います。class Person(name: String, age: Int, country: String) {  def isAdult = age >= 20}val rdd = sc.textFile("people.csv") // name,age,country  .map(s => s.split(","))  .map(t => new Person(t(0), t(1).toInt, t(2)))val result = rdd  .filter(_.isAdult)  .groupBy(_.country)  .countByKeyprint(result)/*Map(JP-> 50, US -> 20)*/RDDの型は RDD[T] であり、 T は任意の型をとることができます。RDD[T] には次のようなメソッドが定義されています。map[U](f: (T) ⇒ U): RDD[U]reduce(f: (T, T) ⇒ T): TgroupBy[K](f: (T) ⇒ K): RDD[(K, Iterable[T])]このように、RDDに対する処理でにはレコードの型を与えることができます。RDDに対する処理は型安全であり、コンパイル時の型検査によって実行時に型エラーが発生しないことが保証できます。データ形式の不一致によるエラーを防ぐ上で大変便利です。その反面、それぞれのレコードに対応するオブジェクトは処理のたびにシリアライズ/デシリアライズされるため、オーバーヘッドは必然的に大きくなってしまいます。シリアライズの際に参照先のオブジェクトが一緒に複製されてしまい、メモリを大量に消費してしまうこともあります。2. DataFrame - 基本的な型の値からなるテーブルDataFrameではデータを基本的な型の値からなるテーブルとして扱います。Int や String などのプリミティブ型および Array や Map などの原始的なコレクション型のみを用いることができます。// Spark 1.6.0import org.apache.spark.sql.SQLContextval sqc = new SQLContext(sc) // {"name": name, "age": age, "country": country}val df = sqc.read.json("people.jsonl")val result = df  .filter(df("age") >= 20)  .groupBy(df("country")).countresult.show/*+-----+--------+|value|count(1)|+-----+--------+|   JP|       50||   US|      20|+-----+--------+*/Spark SQLを用いると、DataFrameに対する処理をSQLとして記述することもできます。df.registerTempTable("people")df.sql("""  SELECT country, COUNT(*)  FROM people  WHERE age >= 20  GROUP BY country;""").showDataFrameに含まれる値は専用のエンコーダによって最適化されるため、通常のオブジェクトに比べてシリアライズ/デシリアライズのオーバーヘッドやメモリ使用量は大幅に小さくなっています。オプティマイザによって予め最適化されます。RDDとDataFrameで同等の処理を実行した場合、DataFrameが数倍から数十倍のパフォーマンスを発揮することがあります。一方、DataFrameはカラム名や各カラムの型についての情報を型で指定できません。filter(condition: Column): DataFrameagg(expr: Column, exprs: Column*): DataFramegroupBy(cols: Column*): GroupedDataColumn は df("country") や df("age") >= 20 のように作成できますが、これらの実際の値の型は実行時にしかわかりません。DataFrame であり、 RDD[T] のようにレコードの型パラメータを持たないため、カラムの名前や型などの情報をDataFrameの型情報から得ることができません。コンパイル時に検出できず、実行時エラーが発生してしまいます。加えてDataFrameが扱える型や関数は限定されており、RDDのようにユーザ定義の型やそれに対する任意の関数を扱うことは難しくなっています。RDD v.s. DataFrameこれまで見てきたように、RDDとDataFrameには次のように一長一短があります。RDD✅ データ処理が型安全である✅ ユーザ定義の型を扱うことができる❌ パフォーマンスが低い❌ アドホックなクエリ処理が書きにくいDataFrame✅ パフォーマンスが高い✅ SQLを用いてアドホックな処理が書ける❌ データ処理が型安全でない❌ 一部の基本的な型の値しか扱うことができないこのような違いのため、RDDとDataFrameは用途に応じて使い分ける必要がありました。バッチ処理では型エラーを未然に防ぐためにRDDを用い、アドホックな分析クエリでは応答速度とクエリの書きやすさからDataFrameを用いる、といった要領です。3. Dataset - RDDとDataFrameの長所を併せ持つコレクションDatasetはいわばRDDとDataFrameの良い所どりを目指したAPIです。// Spark 2.0.0import org.apache.spark.sql.SQLContextval sqc = new SQLContext(sc)// {"name": name, "age": age, "country": country}val ds = sqc.read.json("people.jsonl")val result = ds  .filter(ds("age") >= 20)  .groupBy(ds("country"))  .countresult.show/*+-----+--------+|value|count(1)|+-----+--------+|   JP|       50||   US|      20|+-----+--------+*/気づかれたかもしれませんが、Spark  2.0のDatasetはSpark 1.6のDataFrameと全く同じように扱うことができます。SQLを発行することが可能です。ここで上のDatasetのデータ型に適合するcase classを作成し、 as によってDatasetに適用してみます。RDDと同様のmapやreduceなどを実行することができます。case class Person(name: String, age: Long, country: String) {  def isAdult = age >= 20}val peopleDs = ds.as[Person]val result = peopleDs  .filter(_.isAdult)  .groupByKey(_.country)  .countresult.show/*+-----+--------+|value|count(1)|+-----+--------+|   JP|       50||   US|      20|+-----+--------+*/これは以下のような仕組みによって実現されています。まず、Datasetの型は Dataset[T] であり、DataFrameは Dataset[Row] と等価です。Row はカラムの名前や実際の値の型を自身の型情報としては持ちませんが、Row 型のオブジェクトはそのスキーマを属性として持つことができます。Row のコレクションである Dataset[Row] も同様にスキーマを持つことができ、特にJSONなどから読み出されたDatasetには自動的にスキーマが付与されます。// {"name": name, "age": age, "country": country}val ds = sqc.read.json("people.jsonl")ds.printSchema/*root |-- age: long (nullable = true) |-- country: string (nullable = true) |-- name: string (nullable = true)*/ここで Dataset[Row] のスキーマに適合する型 U を .as[U] として適用すると、 Dataset[U] 型のDatasetが得られます。scala > val peopleDs = ds.as[Person]res: Dataset[Person] = ... .as[U] の U に元のDatasetのスキーマと同じカラム名・型のフィールドを持つクラスを指定した場合、Rowの各カラムが同名のフィールドにマッピングされます。Scalaではデータモデルをcase classで定義することが多いため、通常はUとしてcase classを用います。as によって得られた Dataset[U] 型には、 RDD[U] と同様の型安全な操作を適用することができます。U の各フィールドの型が、DataFrameで扱えたような基本的な型である場合、レコードの内部表現はDataFrameと同様に最適化されるため、処理のオーバーヘッドはRDDに比べて大幅に小さくなります。このようにDatasetはRDDの型安全性とDataFrameのパフォーマンスを持ち合わせており、これまでRDDおよびDataFrameを使い分けていたようなケースを統一的なAPIで記述することができます。RDD, DataFrameからDatasetへの書き換えここまでSparkの3種類のAPIについて紹介しました。RDDまたはDataFrameを用いたコードをDatasetで書き直す際のポイントを簡単に紹介します。DataFrameからDatasetへまずDataFrameですが、前述のようにDataseにはDataFrameとほぼ同じ処理が適用可能です。DataFrame が Dataset[Row] へのエイリアスとなっており、多くの場合は既存のコードを書き換えずにそのまま動作させることができます。RDDからDatasetへ次にRDDですが、こちらは多少の注意が必要です。データの入力については、 SparkContext.textFile の代わりに SQLCotext.text を使用できます。map や filter などの処理の型定義は RDD[T] と Dataset[T] で同じですが、集約処理については少し違いがあります。RDD[T] の groupBy は groupBy[K](f: (T) ⇒ K): RDD[(K, Iterable[T])] のように、キーと集約されたレコードのイテラブルのペアをレコードとするRDDを返します。Dataset[T] の groupByKey は groupByKey[K](func: (T) ⇒ K): KeyValueGroupedDataset[K, T] のように、 KeyValueGroupedDataset[K, T] という集約処理専用の型を持ちます。またDatasetに対する処理が効率的に実行されるためには、レコードの各カラムの型がDataFrameでサポートされていたような基本型である必要があります。Spark SQL and DataFrames - Spark 2.0.2 Documentationおわりにこの記事ではSparkのRDD, DataFrame, Datasetの違いと、最も新しいAPIであるDatasetを使う際のポイントについて説明しました。詳解 Apache Spark：書籍案内｜技術評論社Introducing Apache Spark Datasets - The Databricks BlogA Tale of Three Apache Spark APIs: RDDs, DataFrames, and Datasets - The Databricks Blog特に最後の記事は、Datasetの特徴をRDD,DataFrameと比較して理解するために非常に参考になりました。今後は実際の利用事例についても発信していきたいと思います。

Apache Sparkの3つのAPI: RDD, DataFrameからDatasetへ

8月に毎月恒例の社内LT大会があり、テーマがVMだったので、1974年の仮想化技術の論文を紹介しました。そのときのスライドを公開します。取り上げたのは次の論文です。Popek, Gerald J., and Robert P. Goldberg. "Formal requirements for virtualizable third generation architectures." Communications of the ACM 17.7 (1974): 412-421.この論文は、コンピュータアーキテクチャの効率的な仮想化が可能であるために命令セットが満たすべき必要条件を定理として形式的に証明したもので、仮想化技術の界隈では知る人はいないほどの重要な論文とのことです。テーマがVMに決まった時はネタが思い浮かばず、しばらくWikpediaを眺めていたら面白そうな内容でしかも発表が1974年（！）ということで、LTの題材に決めました。仮想化技術については全くの素人が付け焼き刃で勉強して論文を読んだだけなので、専門家から見ればいろいろツッコミが入りそうな内容ですがご容赦ください。参考PopekとGoldbergの仮想化要件 - Wikipediax86仮想化 - Wikipedia

1974年の仮想化技術の論文についてLTしました

修論と学会終わって成績表も確認したのでやっと気分が落ち着いた。普通はこういうとき旅行とか行くのだろうけど、高校～大学で日本の８割ぐらいの都道府県は行ったし、海外は面倒なので、特に大きな計画はしてない。近場で鳥取だけまだ訪れたことがないので、日帰りか1泊ぐらいでふらっと行こうかと思ってる。地元にいるのもあと3週間くらいなのでのんびりしたい。最近はiPad miniのKindleでマンガ読むのが楽しみで、ランキングの無料のやつを片っ端からダウンロードして気に入ったシリーズを全巻大人買い、という完全にAmazonの家畜みたいな消費してる。気が付いたら沈黙の艦隊と太陽の黙示録がライブラリに揃っててやばい。勉強はしてて、ちょっと前に話題になったGoogleのTensorFlowを使ったコースを始めて今3つ目の課題に取り掛かったところ。最近のDeepLearningについては、シグモイド関数の代わりにReLUを活性化関数にした多層NNという程度の理解しかなくて、まとまった時間がとれたら勉強しようと思ってたのでちょうど良かった。前やったCourseraのやつと違ってクリアしたらなんかもらえるみたいなのはないので少しモチベーションはちょっと下がる。あとは引越に向けて持ち物の整理してる。minikuraっていうサービス使ってて、段ボール一箱月250円ぐらいで預かってくれるのですこぶる便利。

Pythonで機械学習を使う場合、scikit-learnには何かとお世話になる。豊富な学習アルゴリズムの実装を利用できるのが長所だが、実はアルゴリズムそのもの以外にも、前処理や評価のための様々な便利機能を有している。これらを知らずに使っていると，車輪の再発明をしてしまうことになる。また、機械学習関連のPythonライブラリはscikit-learnと連携できるAPIをもつものも多い。scikit-learnを中心とするエコシステムが成立しているとも言える。中にはコードをほとんど書かずに簡単なモデリングができるようなツールまである。この記事では個々の学習アルゴリズムではなく、scikit-learnに予め用意されている便利機能やscikit-learnと連携できるライブラリなどを紹介する。便利モジュール・パッケージ前処理や評価で使われる一般的なテクニックの多くは既に実装されているので、自分で実装する前にまずは API Reference を眺めてみるとよい。たいていの道具は見つかると思う。自分がよく使うモジュール・パッケージをいくつか紹介する。feature_extraction画像やテキストなどの生データからの特徴抽出・ベクトル化を提供する。自分の場合、テキストをよく扱うので次のようなクラスをよく使う。DictVectorizer: dictをarrayに変換FeatureHasher: feature hashingによってdictをarrayに変換（テキストデータのオンライン学習等で使う）CountVectorizer: テキストを語の出現回数でBoWベクトル化TfidfVectorizer: テキストをTF-IDFでBoWベクトル化preprocessing特徴ベクトルに対して前処理を適用する。scale: 標準正規分布にスケーリングminmax_scale, maxabs_scale: [0, 1] [-1, 1] などの範囲にスケーリングnormalize: 各ベクトルのノルムを正規化label_binalize: カテゴリ特徴を二値化LabelEncoder: ラベルを数値にエンコードPolynomialFeatures: 多項式による組み合わせ特徴を生成cross_validation(k-fold) cross validationを手軽に扱う。train_test_split: データセットを訓練セットとテストセットに分割cross_val_score: k-fold cross validation により各foldの評価スコアを算出metrics各種評価指標の実装。accuracy_score: 精度f1_score: F値precision_score, recall_score: 適合率, 再現率auc: AUCmean_squared_error: MSEgrid_searchグリッドサーチによるパラメータを最適化する。GridSearchCV: 与えられたグリッドから最適なパラメータを自動で選ぶモデルを生成外部ライブラリ外部ライブラリは細かく挙げていくとキリがないので、主なものだけ紹介する。もっと調べたい場合は以下のドキュメントを参照。Related Projects — scikit-learn 0.17.1 documentationScikit-Learn Laboratory(SKLL)用意した設定ファイルに基づいて、モデルの学習や評価などを自動実行する。簡単な評価程度ならPythonコードを全く書かなくてもいいほど。設定ファイルはPython configuration file形式で記述する。以下はTitanicデータセットに対してRandomForest, 決定木, SVM, 等で学習を行い評価するタスクの設定ファイル一例（ここから引用）。[General]experiment_name = Titanic_Evaluate_Tunedtask = evaluate[Input]train_directory = traintest_directory = devfeaturesets = [["family.csv", "misc.csv", "socioeconomic.csv", "vitals.csv"]]learners = ["RandomForestClassifier", "DecisionTreeClassifier", "SVC", "MultinomialNB"]label_col = Survivedid_col = PassengerId[Tuning]grid_search = trueobjective = accuracyタスクの実行はCLIで行う。$ run_experiment evaluate.cfg結果は次のように出力される。Fold:Model Parameters: {"max_depth": 10, "compute_importances": null, "min_density": null, "bootstrap": true, "n_estimators": 500, "verbose": 0, "min_samples_split": 2, "max_features": "auto", "min_samples_leaf": 1, "criterion": "gini", "random_state": 123456789, "max_leaf_nodes": null, "n_jobs": 1, "oob_score": false}Grid Objective Score (Train) = 0.8089887640449438+---+-------+------+-----------+--------+-----------+|   |     0 |    1 | Precision | Recall | F-measure |+---+-------+------+-----------+--------+-----------+| 0 | [101] |   14 |     0.871 |  0.878 |     0.874 |+---+-------+------+-----------+--------+-----------+| 1 |    15 | [49] |     0.778 |  0.766 |     0.772 |+---+-------+------+-----------+--------+-----------+(row = reference; column = predicted)Accuracy = 0.8379888268156425Objective Function Score (Test) = 0.8379888268156425sklearn-pandaspandasのDataFrameを上記のsklearn.preprocessing等を用いて学習用の入力データに変換する。これをdata = pd.DataFrame({    'pet':      ['cat', 'dog', 'dog', 'fish', 'cat', 'dog', 'cat', 'fish'],    'children': [4., 6, 3, 3, 2, 3, 5, 4],    'salary':   [90, 24, 44, 27, 32, 59, 36, 27]})こうしてmapper = DataFrameMapper([    ('pet', sklearn.preprocessing.LabelBinarizer()),    (['children'], sklearn.preprocessing.StandardScaler())])np.round(mapper.fit_transform(data.copy()), 2)こうじゃ！array([[ 1.  ,  0.  ,  0.  ,  0.21],       [ 0.  ,  1.  ,  0.  ,  1.88],       [ 0.  ,  1.  ,  0.  , -0.63],       [ 0.  ,  0.  ,  1.  , -0.63],       [ 1.  ,  0.  ,  0.  , -1.46],       [ 0.  ,  1.  ,  0.  , -0.63],       [ 1.  ,  0.  ,  0.  ,  1.04],       [ 0.  ,  0.  ,  1.  ,  0.21]])（ここから引用）。auto-sklearnデータを与えるだけでアルゴリズム選択・パラメータチューニングを全自動で行い、適切なモデルを生成してくれる。サンプルコードにあるとおり、人間がやるのは AutoSklearnClassifier のインスタンスを生成して fit するだけという便利なのか乱暴なのかよくわからない代物。手っ取り早くベースラインのモデルを作るにはいいかもしれない。その他scikit-learnにはないトピックモデルや構造化学習などのアルゴリズム実装もいろいろある。自分ではあまり使ったことのないライブラリも含んでるので参考程度にどうぞ。https://github.com/ariddell/lda/:lda: LDAPyStruct: CRF等の構造化学習HMMLearn: 隠れマルコフモデルsklearn-compiledtrees: 決定木のアンサンブルモデル（RandomForest, GradientBoostedTree）をコンパイルして高速化追記2016-02-26:scikit-learnにもトピックモデルの実装は含まれているとのこと。id:another16javac さん、ご指摘ありがとうございます。学習アルゴリズム以外のscikit-learn便利機能と連携ライブラリ - yubessy.hatenablog.com実はscikit-learnにもトピックモデルあります http://scikit-learn.org/stable/modules/generated/sklearn.decomposition.LatentDirichletAllocation.html2016/02/25 01:56

学習アルゴリズム以外のscikit-learn便利機能と連携ライブラリ

昨年の10月から12月にかけて Cousera の機械学習オンラインコース "Machine Learning" を受講し、無事完走することができた。www.coursera.orgコースは無料で受講できるが、修得したことを公式に認定する修了証 (verified certificate) を取得するためにはお金がいる。機械学習コースの取得料は$49と安くはないが、記念と思って取得してみた。取得すると以下のようなパーマリンクがもらえて、修了証が閲覧できるようになる。https://www.coursera.org/account/accomplishments/verify/WX835R39AB77もともとアルバイトをしていたはてなでこのコースを利用した勉強会が開催され、それに参加させてもらったのが受講のきっかけだった。運営の id:takuya-a さんをはじめ皆様にはお世話になり、ありがとうございました。developer.hatenastaff.comせっかく修了証の取得までこぎつけられたので、全体を通しての振り返りを書き残しておきたい。コースについて内容講義ビデオ課題勉強会について講義Slack修了証について本人確認情報の登録課題提出時の本人確認後日談コースについて講師は著名な機械学習の研究者である Andrew Ng 先生で、コースはスタンフォード大学によって提供されている。ボリュームは全部で11週分あり、完走には2.5ヵ月ほどを要する。コースは一人でも進められるように設計されていて、きちんと講義を見ていれば課題で詰まることはあまりない。ただ、11週の講義を完走するモチベーションを継続させるのはそれほど簡単ではない。詳しい内容については、例えば以下のリンク先などで既にいろいろな人が書いているので、ここでは個人的な感想を書く。数学を避けてきた社会人プログラマが機械学習の勉強を始める際の最短経路 - Qiita内容大きく分けて教師あり学習・教師なし学習・機械学習応用の3パートからなっているという印象。難しい内容を省きつつ、基本的なアルゴリズムについて丁寧に教えてくれる。受講にあたって機械学習の知識は全く必要ないが、数学についてはある程度の素養が必要。最低限の数学の復習はしてくれるが、少なくとも大学の一般教養の線形代数ぐらいは理解していないとその後ついていくのは厳しい。必要な知識は 線形代数 > 微積 > 確率・統計 という感じ。講義ビデオ毎週の講義は10-15分ほどのビデオの数本からなる。ビデオではスライドを流しながら Andrew 先生がカラーペンでポイントを随時書き込んだりして説明してくれる。自分の場合、SVMやK-meansなど講義で扱っていた多くのアルゴリズムについては既に基礎的な知識を持っているつもりだったが、それでも得るものは多かった。特に Andrew 先生が随所で紹介してくれる実践的なTIPSが面白かった。例えば正則化係数のパラメータを最適化する際にどんなステップで値を変えるべきかといった、経験と勘に基づく秘伝のタレを伝授してもらえる。異常検出で変数を無理やり式変形して正規分布っぽくするのには笑った。有志の方が日本語字幕をつけてくれているのもありがたい。講義が進むとだんだん先生がお茶目になってくるのだけど、訳も追従していて楽しい。Courseraの機械学習のコースに日本語字幕をつけました - 南よ! 海の見える方!課題課題は小テストにあたる quiz とプログラミング問題の exercise の両方が毎週出題される（exerciseは無い週もある）。全て英語。quiz は1本につき5問の選択問題で、毎週2-3本が出題される。選択とはいえ講義をきちんと理解していないと合格点は取れない。excercize はプログラミング形式で、課題提出ファイルをダウンロードし、インストラクションに従って該当部分を実装して提出すると自動採点される。言語は GNU Octave というあまり馴染みのないものだが、課題をこなすだけなら習得はそれほど難しくない。多くの課題でアルゴリズムの本質的な部分以外はすでに実装されており、お膳立てが整っているので、1ステップずつ進めていけば自然に実装が完了するようになっている。自分の場合、これまで本を読んで機械学習を勉強する機会はあったものの、利用する際には scikit-learn などのライブラリを使うことがほとんどだったので、様々なアルゴリズムを実装するのはいい経験になった。講義ビデオもそうだったが、このコースは理論と実践をスムーズに接続してくれる工夫があってとても良かった。勉強会について先に述べた通りコースに沿った勉強会という形で受講を進めており、講義はみんなで見て課題は各自でやるというのを基本にしていた。総じて一人で進めるよりも圧倒的に実りがあった。講義基本的に大きなディスプレイに講義ビデオを写してみんなで見る。自分は同時にマイPCでもサイレントでビデオを流しておいて、数式が理解しにくい場合などにいちいち止めたり巻き戻したりしていた。２画面使えるので便利。ビデオの前後や合間には、参加者の間で適宜疑問点などを口頭やホワイトボードで議論した。参加者のほぼ全員が現役エンジニアなので、このアルゴリズムを実際の問題に適用するとパフォーマンスはどうかみたいな実践的な話もいろいろ聞くことができた。また、機械学習がド専門のという人は居なかったものの、コンピュータサイエンスの他分野で学位を取った人が複数人いたので、理論的な面を解説してもらえたりした。Slack勉強会専用に参加者全員が居る Slack チャンネルを用意してもらっていた。次のように様々なことに使えて便利だった。視聴中のビデオを遮らずに随時疑問点を共有できるビデオの合間の議論の内容を書き残せる参考リンクを共有できるリモート参加できる諸連絡に使える修了証について冒頭に書いたように、このコースでは修了証を $49 で取得できる。日本円だとクレジットカードの海外決済手数料を含めて6000円ぐらいになるので、学生の身としては少しためらったが、お金払ってもいい内容だと思ったので取得を決意した。修了証を得るためには最初に本人確認情報を登録し、課題を提出する度に本人確認を行わなければならない。Course Certificate | CourseraCoursera｜修了証（Verified Certificates）とは : MOOCsブログ本人確認情報の登録本人確認のためには以下の３つの情報を登録する必要がある。タイピングパターン自分の顔写真免許証やパスポートなどの本人確認書類の写真これらは一度 Coursera に登録すればその後は他のコースの修了証をもらうときにも使えるので、手間としては大したことはない。ただし注意点として、この最初の本人情報登録の前に課題をやっても、修了証の取得条件をクリアしたことにならない。コースを数週間分課題までやってから初めて修了証を取得するために本人確認手続をする場合、それまでにやった課題は全て再提出しなければならない。Exercise はソースコードを保存しておけば一瞬で再提出できるが、 quiz はイチからやりなおしになってかなり面倒。また、修了証に記載してもらうために登録する自分の名前は、原則として本人確認書類に記載されたものでなければならない。公開される修了証に記載されるのは名前だけで、顔写真などが記録されるわけではないのだが、ニックネームなどは使用できない。また本人確認書類として免許証を使用する場合、ローマ字が記載されていないので、修了証の記載名もローマ字ではなく日本語名を登録することになる。個人的にはローマ字が良かったのだけど、残念ながらパスポートを持っていなかったので漢字になった。課題提出時の本人確認毎回の課題提出時には必ず本人確認ステップを踏まなければならない。PCの場合、 Coursera Honor Code に従いますという内容の英語の一文をキーボードから入力することでタイピングパターンを照合する。照合が失敗することは無かったが、 quiz でも exercise でも毎回入力しないといけない。スマホ・タブレットで quiz をやったときはタイピングパターンの代わりに毎回顔写真を撮る必要があった。修了証を取得したこと自体は後悔していないが、本人確認書類を提出した後はもう少し確認ステップを簡単にしてほしい。ちなみにタイピングパターンの照合の話がコース中の異常検出の話で出てきており、 Coursera のシステムも機械学習を利用しているっぽい。なので学習データを多く集めるために毎回パターンを入力させていると考えれば納得できなくもない。後日談修了証をLinkedInに資格として登録できるというので登録しておいたら、スペインのベンチャー企業からリクルートメールが届いた（丁重にお断りした）。

Coursera の機械学習コースを完走して修了証を取得した話

昨日書いた今年の目標に書きそびれたけど、今年は積極的にブログ書いていきたい。形から入るタイプなのでテーマも変えてみた。今までこのブログは時折思い出したようにぽつんと投稿するだけで、ほぼ放置状態だった。理由は単純で、特に書くことがなかったからである。心変わりしたのには、最近アルバイトをしたり勉強会に参加したことが少なからず影響している。まだ大したことはないものの、自分にも共有できる知見があるかもしれないと感じることが多くなった。今は研究が忙しいけれど、落ち着いたら機械学習の話とかいろいろ書きたい。また昨年はアルバイトを中心に多くの人にお世話になったので、環境が変わってもちょくちょく近況報告できる場所がほしいというのも理由のひとつ。SNSはそれはそれでいいのだけど、ブログは時間の流れがゆるいので、Twitterフォローするほどでもないけどたまにブログを覗いてみるみたいなことができてよい。とここまで神妙に書いてみたものの、ぶっちゃけブログチャレンジやりたかったのが一番の理由です。ブログチャレンジで「Lv.9 疾風の蒼穹のyubessy」になりました https://t.co/9VE3rj8WAM #はてなブログチャレンジ— 柚餅子 (@yubessy) January 1, 2016「ブログを3日継続」をクリアしました。

ブログ

あけましておめでとうございます。今年は社会に出る予定なので、時間もお金も使い方の自由度が上がると信じてる。とりあえずいくつか目標を書いておく。エンジニア活動最近ちょっとずつエンジニア力ついてきた気がするので、今年は成果を積極的に公開していきたい。自分の性格上、細かいところにこだわりすぎたり完璧を目指してしまうことが多いので、もう少しゆるくやっていきたい。これまで Python3 をずっとメインで使い続けていて、ライブラリのコードを読んだり直したりする機会も増えてきたので、OSSコミットとかもできたらいいなと勝手に思ってる。あとはそろそろまともに Vim 使えるようになりたい。データサイエンティスト活動昨年は機械学習やデータ分析の勉強を頑張った。具体的には京大で開催されたサマースクール MLSS'15 に参加したり、mlss | Machine Learning Summer School Kyoto 2015アルバイトをしていたはてなで Coursera を利用した機械学習勉強会に加わらせてもらったりした。Coursera を利用した機械学習勉強会 - Hatena Developer Blogこちらは課題も完走して Certification を取れたので、あとでブログに詳しく書こうと思っている。ちなみにこの辺に興味を持ったきっかけは、昨年の春に参加した学生向けコンペだった。第1回データサイエンス・カップ 2015 春 - yubessy blog機械学習を勉強していくにつれて、確率・統計の基礎をもう一度きちんとやり直したい気持ちが高まってきたので、今年はその辺をしっかりやりたい。Coursera に味をしめたので、誰かおすすめのコースあったら紹介してください。良いサービスにお金を使う以前はなんとなく月額や年額のサービスに課金するということをためらっていたのだけれど、1年前に思い切って Dropbox Pro に加入してから方針がだいぶ変わり、便利なものには進んでお金を払おうと考えるようになった。昨年は以下のサービスに課金していたが、予想以上に満足度が高かった。Dropbox ProAmazon Prime実は今日も、正月で気が大きくなって2つ新たに課金してしまった。Apple Musicニコニコプレミアムサービスほかに今年は次のサービスに課金することを検討している。Moneytree PLUSGitHub Micro PlanさくらのVPSNetflix Standardfeedly Proはてなブックマークプラス生活24歳にして初めて東京で一人暮らしをする（予定）なので、生活力をつける必要がある。たぶん自炊以外は今までも普通にやってたので何とかなると信じている。健康大学院に入ってから運動の機会が減ったからか、はてなでおいしいまかないを食べすぎたからか、最近体重が増えてきた。なんか運動したほうがよさそう。健康管理に Fitbit 導入したのでとりあえず Charge HR とAria がほしい。おわりに他力本願万歳。www.amazon.co.jp

今年の目標

大晦日なので今年買ってよかった○○エントリでも書こうと思ったけど、よく考えてみたら特に大したものは買っていない。それもそのはずで、この1年は新しい生活のために自分の身の回り（お金・持ち物・生活習慣など）を整理しており、新しいものが増える余地が少なかったのだった。代わりというわけでもないけど、今年は意識的に自分の情報収集環境を充実させようと頑張っていた。その一環で、若干時代遅れ感はあるがRSSリーダーを活用してみた。というわけで、今年購読してよかったRSSフィードをメモしておく。開発・エンジニアHackerNewsの100pt以上限定フィードはいち早く話題を知れてよい。POSTDはソースをたどると良いサイトが見つかったりする。score>100 – hnapp 100">#RSSPOSTD | プログラミングの話題を翻訳して届けるエンジニアのためのニュースメディア #RSS企業の開発ブログは単なる技術エントリよりも組織やチーム開発に関するエントリを重点的に読んだ。Hatena Developer Blog #RSSクックパッド開発者ブログ #RSS有名なOSS開発者のブログも設計思想が垣間見れて面白い。Blog | Armin Ronacher's Thoughts and Writings #RSS機械学習・データサイエンス海外サイトのほうがむしろ説明が体系的でわかりやすい。Analytics Community | Analytics Discussions | Big Data Discussion #RSSAnalytics, Data Mining, and Data Science #RSSLatest Posts – Subjective functions #RSS他に技術ノウハウが参考になった企業・個人ブログ。トレジャーデータ（Treasure Data）公式ブログ #RSSStatsFragments #RSS将棋趣味は将棋観戦です。将棋ペンクラブログ | 将棋ペンクラブ末席幹事による将棋ペンクラブ非公認ブログ。近代将棋に連載していた「将棋ペンクラブログ」のネット版です。 #RSS将棋ワンストップ・ニュース 将棋界や棋士・女流棋士の話題をまとめて読める #RSSお金この前書いたとおりお金のこといろいろ知りたかったので。マネーフォワード公式ブログ #RSSクレジットカードの読みもの #RSSその他理系大学院2年目・就活という点で共感することが多かったブログ。大学院生のネットワークなブログ #RSSおわりに他にも合計100以上のサイトのフィードを購読していたけれど、これはいいなと思うサイトを見つけるのはなかなか難しい。RSSそのものの問題点として、フィード内で記事をフィルタリングをする手段が基本的に無いのは不便だと思った。例えば良い記事があっても更新頻度が多すぎるようなサイトは登録しにくいし、開発者の個人ブログで私生活の記事も含むような場合も購読するか迷うことが多い。なお、RSSリーダーはFeedlyを利用していた。feedly.comFeedlyにはExploreという機能があり、様々なテーマのフィードを検索で見つけることができる。ただし残念ながら日本語のサイトはあまり出てこない。この点に関して、はてなブックマークがRSSリーダーの開発に取り組んでいるらしいのでひそかに期待している。bookmark.hatenastaff.com※ちなみに自分は今年1年間はてなでアルバイトをしていました

今年購読してよかったRSSフィード

うまくいけば来年4月から社会に出ることになるので、今年は家計簿をつけることを目標にしていた。そのため、今年1月からマネーツリーとマネーフォワードという2つの家計簿アプリ(iOS)を1年間使ってみた。moneytree.jpmoneyforward.com結論から言うとマネーツリーに一本化することに決めた。せっかくなので選択の過程を書き残しておこうと思う。以下はあくまで自分の用途からみた主観的な話であり、内容について責任は持たない。比較表下の話を表にまとめるとこんな感じ。マネーツリーマネーフォワード  資産一覧種別集計画面見やすい見にくい資産とポイント別画面同画面出費集計種別グラフ棒グラフのみ円グラフ可通販履歴非対応対応現金管理レシート読み取り非対応対応財布残高自動計算ATM引き出しで対応対応その他無料版の機能高機能制限ありWeb版ありありもう少し詳しくこれまで実家暮らしの学生だったこともあり、自分の持っている資産の総額をきちんと把握していなかったので、アプリに最も求めていたのは資産の推移を把握できることだった。両アプリはいずれも資産一覧・出費集計・現金管理の機能を有しており、自分にとって重要な順に各機能を並べると 資産一覧 > 出費集計 > 現金管理 となる。以下ではこの３つの面についてそれぞれのアプリを比べて気づいたことを書く。資産一覧資産一覧はマネーツリーのほうが見やすい。マネーツリーは「口座残高」タブで全資産および銀行口座・クレジットカード・電子マネー・その他の各残高を一目で把握できる。個別の銀行口座の残高や入出金記録などはその画面から1～2タップでたどり着けるようになっている。マネーフォワードは最近種別集計額を表示してくれるようになったものの、登録金融機関が多いと画面が冗長になって見づらい。また、マネーツリーはポイント類と金融機関をタブで明確に区別しているけれど、マネーフォワードはすべて資産としてひとつの画面で扱っている。個人的にはここは区別してほしい。他にもマネーフォワードはカードの使用額が確定するまで表示できなかったり、通販サイトが残高0の金融機関として表示されるなどの不満がある。出費集計出費集計はマネーフォワードのほうが高機能。マネーフォワードは各月の出費額を色付き円グラフで表示してくれるため、月の出費の割合が把握しやすい。マネーツリーは棒グラフしか出ないので割合を把握するのにはあまり向いていない。またマネーフォワードは楽天やAmazonの買い物履歴を取得しているので、閲覧できる情報量もマネーツリーより多い。例えばKindleの電子書籍を買ったとき、マネーフォワードは書籍名まで見れるが、マネーツリーはクレジットカードの履歴としての "AMAZON DOWNLOADS" というような文字列しか見れない。細かいことを言うとマネーフォワードも自動分類の精度がよくなかったり、カード履歴と買い物履歴の名寄せが失敗したりするといった問題はあるけれど、気になったら手で直せるし、そんなに手間もかからない。現金管理現金管理については、機能の豊富さではマネーフォワードが勝るものの、使い勝手はマネーツリーのほうがよい。当初はマネーフォワードをRecerecoと連携してレシート入力で現金管理をしていた。この機能では、連携する財布を指定しておくとレシートを入力することで差し引き残高が計算されるようになっている。こうしておくとスマホで財布の中身が確認できるのではじめは重宝していたけれど、しだいにパシャパシャが面倒になり、また帳尻が合わなかったりすると修正が大変だったりした。ふと 財布の中身は財布の中を見れば確認できるのでは、 という至極当たり前のことに気付いてからこの機能はあまり使わなくなった。入力画面はマネーツリーのほうがシンプルで使いやすい。マネーフォワードは少し前に画面がリニューアルされた結果、メモの入力がしにくくなかったりして、むしろ使いにくくなったように思う。最近はなるべく現金より電子マネーやクレジットカードを利用しており、こうすると記録が自動で残るので手入力の手間が省けて便利。現金の入出金はは千円以上の出費だけ直接入力している。ちなみにマネーツリーは出費カテゴリに「ATM引き出し」という項目があり、この額が記録した現金出費額と相殺されるようになっているので、うまく使えば手元の現金を把握することも可能ではある。その他上に挙げてない大きな違いとしては、マネーツリーのほうが無料で使える機能が豊富だという点がある。マネーフォワードの無料版は、広告が表示される・金融機関の登録数が少ない・1年以上前の記録が見れない、といった制約がある。家計簿アプリ 資産管理 「マネーフォワード」対してマネーツリーはこれらの制約を設けないことを明言している。Moneytreeのセキュリティへの取り組みについて | Moneytree 一生通帳、家計簿より楽チン！マネーツリーのこの太っ腹っぷりはすごい。またマネーフォワードはWeb版があるのが強みだったが、つい最近マネーツリーもWeb版がリリースされたのでその点においては違いがなくなった。よく言われるセキュリティ上の懸念については、両アプリとも残高照会に必要な最低限の情報しか保持しないので情報が洩れて銀行からお金が引き出される可能性は非常に低いし、不安なら大事なアカウントは連携しなければいいのでここではとやかく言わない。おわりに何度も言っているが、マネーツリーはUI/UXが洗練されていて使い心地が非常によい。対してマネーフォワードは、機能の豊富さではマネーツリーを上回るものの、自分にとっては必要ない機能が多い印象だった。また最近はましになったものの、以前のマネーフォワードはバグが多くてしょっちゅう落ちていた。両方のアプリを1年間ほぼ毎日使った結果、自分にはストレスをほとんど感じさせないマネーツリーが合っているという結論に至った。ただ、人によっては機能の豊富なマネーフォワードが合う人もいるだろうし、この辺は好みの問題かもしれない。最後に、ここまで偉そうにあれこれ言ってみたけど、どちらのサービスに対しても運営にはいい印象を持っていることを記しておきたい。両社ともお金の世界を良くするのに相当な努力をしていることは、例えば以下のような記事からよく伝わってくる。「Moneytree」の利用規約 および プライバシーポリシーの オープンソース化宣言について | Moneytree 一生通帳、家計簿より楽チン！アカウントアグリゲーションのその先の世界を創る | Engineers' Blog何より競合が存在するというのはサービスが良くなっていく上でいいことだと思うし、心の中では今後も両方のサービスを応援していきたい。

マネーツリーとマネーフォワードを1年間使ってマネーツリーを選んだ話

最近Neo4jというデータベースに触れる機会がありました。Neo4jはグラフ構造を扱えるデータベースシステムで、人間関係のネットワークやWebページ間のリンク関係などを扱うのに適しています。グラフデータベースでは「友達の友達の友達」や「10以上リンクされているページ同士の相互リンク」といった情報を簡単に引き出すことができます。これらをRDBMSで実現しようとすると何段ものJOINが必要となり、クエリが複雑になって計算量も増えてしまいがちです。グラフデータベースを使えば、クエリを簡潔に保ち、計算量も抑えることができます。今回は日頃から利用しているはてなブックマークのデータを使い、Neo4j上にはてブグラフを構築していろいろなクエリを試してみました。※はてなブックマークWebおよび公開APIから取得できるデータのみを使用しています。グラフとはここでいう「グラフ」はExcelで描けるようなグラフとは異なり、「ノードとそれらの間の関係によって構成されるデータ構造」のことを意味します。グラフ (データ構造) - Wikipediaグラフ構造はとても興味深い性質をもっており、グラフ理論という数学の一分野で扱われます。グラフ理論 - Wikipediaはてブグラフとは「ユーザがエントリをブックマークしている」ことは、「ユーザとエントリの間にブックマークという関係が存在する」こととみなせます。はてなブックマークでは、たくさんのユーザが各々たくさんのエントリをブックマークしているので、次のようなグラフが生じます。このようなグラフを はてブグラフ と呼ぶことにします。はてブグラフを見れば、エントリの被ブックマーク数はもちろん、「どのユーザ同士が同じページをブックマークしているか」といったこともすぐにわかります。ちなみに、このような２種類のノード（ユーザ・エントリ）をもち、なおかつ異なる種類のノード間にしか関係が存在しないようなグラフを「２部グラフ（bipartite graph）」と呼びます。ユーザ間のお気に入り・入られや、エントリ間のリンクなどを考えない場合、はてブグラフは典型的な２部グラフとなります。Neo4jのインストールやっとNeo4jの登場です。Neo4jはMySQL等と同様に、デーモンプロセスとして動作します。インストールは、ダウンロード→展開→startで済みます。Homebrewを使っていれば、以下を実行するだけでインストールと起動ができます。$ brew install neo4j$ neo4j startNeo4jにはデフォルトでWebインタフェースが用意されており、プロセスを起動した状態で http://localhost:7474/ にアクセスすることですぐに利用できます。データベースは基本的に１プロセスにつき１つです。RDBMSではないのでテーブルはなく、全てのオブジェクトはノードか関係のいずれかです。Cypher: Neo4jのためのデータベース操作言語RDBMSでSQLを使うのと同様に、Neo4jではCypherというデータベース操作言語を使います。以下のCypherプログラムは、ユーザとエントリのノードを作成し、その間にブックマーク関係を付与します。CREATE  (u:User {name: "yubessy"}),  (e:Entry {url: "http://b.hatena.ne.jp/"}),  (u)-[:BOOKMARK]->(e);ノードは (<変数名>:<ラベル> {<属性名1>: <属性値1>, ...}) で表します。ノードXからY間への関係は (<ノードX>)-[<変数名>:<ラベル> {<属性名1>: <属性値1>, ...}]->(<ノードY>) で表します。関係を作成する際には必ず向きを指定しないといけません。ノード・関係のいずれに対しても0個以上の属性を指定することができます。変数名は後方参照で使わない場合は不要です。CypherはWebインタフェースや各言語用のライブラリから実行できます。CypherによるクエリCypherの利点は、パターンマッチによって柔軟なクエリが発行できることです。以下は最も簡単なクエリの構文です。MATCH <変数を含むパターン> RETURN <変数>;このクエリを実行すると、 MATCH 句で <変数を含むパターン> にマッチする構造を探してオブジェクトを変数に束縛し、 RETURN 句で変数に束縛されたオブジェクトを返します。以下ではグラフ中のパターンにマッチする構造を 部分グラフ と呼びます。例えば「ユーザyubessyがブックマークしているエントリの一覧」は以下のクエリで取得できます。MATCH (:User {name: "yubessy"})-[:BOOKMARK]->(e:Entry) RETURN e;このクエリを実行すると、「yubessyというnameのユーザがエントリeをブックマークしている」ことを示す部分グラフを探し、見つかったそれぞれの部分グラフに含まれるエントリを変数に束縛し、束縛されたエントリを全て返す、という処理が行われます。Cypherを使う際には、 () がノード、 ()-[]->() がノード間の関係とだけ覚えておけば、あとは直感的にクエリを書くことができます。クエリ中には ()-[]-() のように関係の向きを指定しないパターンも使用できます。はてブグラフの構築今回はローカルで起動しているNeo4jに、はてなブックマークから取得した以下のようなデータを投入してみました。エントリ: 2015年8月のとある日の「テクノロジー」カテゴリのホットエントリ上位200件ユーザ: 同日時点で上記のエントリを1つ以上公開ブックマークしているユーザ全4086名ブックマーク: 上記のエントリ・ユーザ間に存在するブックマーク全9301件エントリのデータはホットエントリRSS、ユーザとブックマークのデータはエントリー情報取得APIを用いて取得しました。データ取得の際はサービスに負荷をかけないよう、アクセスは直列に行い、10秒以上のインターバルを設定しました。Neo4j上でのデータ表現は次のようにしました。ユーザ: (:User {name: <ユーザ名>})エントリ: (:Entry {url: <URL>, title: <タイトル>})ブックマーク: (<ユーザ>)-[:BOOKMARK {comment: <コメント>, timestamp: <ブックマークした日時>, tags: <タグ一覧>}]->(<エントリ>)はてブグラフに様々なクエリを発行してみる以下では構築したはてブグラフに対し、Cypherを使って様々なクエリを発行してみます。Neo4jのWebインタフェースは非常に優秀で、実行結果をグラフ図として出力してくれます。クエリと合わせてこのグラフ図も載せています。あるユーザのブックマーク一覧先程と同様のクエリですが、ラベルと変数が少し異なっています。今回のデータベースに存在する関係は BOOKMARK のみであり、関係は必ずユーザからエントリに向けて張られるため、パターン中に関係とその向きが含まれていれば、ラベルは省略できます。また、実行結果には RETURN 句で指定した変数に束縛されたオブジェクトしか含まれないため、Webインタフェースでグラフ図を描画するには、描画したいオブジェクトを変数に束縛するする必要があります。MATCH (u {name:"yubessy"})-[b]->(e)RETURN u, b, e実行結果は以下のようになります。緑・青それぞれの丸がユーザ・エントリを示すノードです。タイトルに"JavaScript"を含むエントリに対する、"JavaScript"というタグの付いたブックマーク一覧ノードや関係につけた属性値は WHERE 句による絞り込みに利用できます。Cypherには豊富な種類の演算子が揃っており、正規表現も使えます。また、属性値にリストを入れることもでき、それに対して IN 演算子を適用することもできます。MATCH (u)-[b]->(e)WHERE e.title =~ ".*JavaScript.*" AND "JavaScript" IN b.tagsRETURN u, e, b;実行結果では、ユーザ名は適当な番号に置き換えています。図がそれらしくなってきました。あるユーザの総ブックマーク数SQLと同様に COUNT 等の集約関数を実行できます。MATCH ({name:"yubessy"})-[]->(e) RETURN COUNT(e)このクエリはノードや関係を返していないのでグラフ図は描画されません。8あるユーザがブックマークしているエントリのうち１つ以上をブックマークしているユーザ（name順上位10件）このクエリは言葉で表現すると少し複雑ですが、パターン記法のおかげで何を求めているかが直感的にわかります。上位10件としているのはそのままだと非常に多くのユーザが返ってしまうため、またユーザname順としているのはなるべく異なるエントリがグラフ上に描画されるようにするためで、深い意味はありません。MATCH (u {name:"yubessy"})-[b1]->(e)<-[b2]-(o)RETURN u, b1, e, b2, o ORDER BY o.name LIMIT 10真ん中の「831」となっているのが私（id:yubessy）です。あるユーザがブックマークしているエントリのうち7つ以上をブックマークしているユーザ一覧最後の例は少し複雑です。今回は新しい構文、 WITH 句を使います。クエリを句ごとに説明すると、MATCH (u {name:"yubessy"})-[]->()<-[]-(o)パターン「yubessyがブックマークしているエントリをユーザoがブックマークしている」にマッチする部分グラフを取得WITH u, o, COUNT(*) as c得られた部分グラフを (u, o) の組み合わせ毎にグルーピングし、各グループに含まれる部分グラフ数をcとするWHERE c >= 7部分グラフ数が7以上のグループのみを選択するMATCH (u)-[b1]->(e)<-[b2]-(o)u, oに束縛されたオブジェクトの集合に対し、改めてパターン「uがブックマークしているエントリeをoがブックマークしている」にマッチする部分グラフを取得RETURN u, b1, e, b2, o部分グラフ中の各変数に束縛されたオブジェクトを返すという感じでしょうか。厳密にはちょっと説明が怪しいかもしれません。7という数はグラフ図がいい感じになる値を選んだだけで、深い意味はありません。MATCH (u {name:"yubessy"})-[]->()<-[]-(o)WITH u, o, COUNT(*) AS cWHERE c >= 7MATCH (u)-[b1]->(e)<-[b2]-(o)RETURN u, b1, e, b2, o実行結果中のノードの配置はわかりやすいように編集しました。左側の緑丸の集合が取得したかったユーザの一覧です。ブックマークを示す矢印が壮観ですね。まとめNeo4jにはてなブックマークのデータを入れて簡単なクエリを試してみた、という話でした。グラフ構造は身の回りの至る所に存在しますが、グラフデータベース自体はあまり普及していないようです。これから使う人が増えて、情報がどんどん出てきたらいいなと思います。

Neo4jではてなブックマークグラフをつくってみた

※以下は自分の利用ケースにおける主観的な感想です。仕様は今後変わる可能性があります。ちょっと前にタスク管理をApple標準のリマインダーからTodoistに乗り換えた。最初はTodoistに満足していたが、使っていると時折痒いところに手が届かないことがあった。そこで今度はWunderlistに乗り換えてみると、感じていた不満がほとんど解消されて幸せになることができた。Todoistの不満点有料版限定機能が多い次の機能はTodoistでは全て有料版でしか使えない。完了したタスクの閲覧タスクにラベル付与タスクに時刻指定のリマインダーを指定タスクにメモを付与タスクにファイルを添付Wunderlistではこれらと同様の機能を全て無料で使うことができる。またTodoistでは、これらの機能がメニューに表示されているのに、使おうとすると「この機能はプレミアム限定です」と言われてフラストレーションが溜まることが多かった。サブタスク機能が使いづらいTodoistのサブタスク機能は、タスク間に階層構造を定義するものとなっている。こうすることでサブタスク毎に期日を設定したりできるが、逆に表示がわかりづらくなってしまうことがある。例えば次のようなタスク階層の場合、メイン: 報告書提出 (期日: 来週)サブ: 作成 (期日: 今日)サブ: 上司に確認 (期日: 3日後)サブ: 提出 (期日: 来週)「今日」のビューでは「作成」というタスクが表示されるだけで、この親タスクが何なのかぱっと見ではわからない。Wunderlistではサブタスク機能は有料だが、無料でもタスクに細かいチェックリストを付与することができる。チェックリストは親タスクを選択したときだけ見れるようになっており、チェック項目毎に期日を設定したりはできないが、今のところこれで用は足りている。タスクの分類方法が「プロジェクト」のみ個人のタスク管理ではタスクを「仕事」「趣味」といった単位に分類したいことがあるが、これを「プロジェクト」と呼ぶのには少し違和感がある。Wunderlistはタスクをまとめたものは単に「リスト」であり、さらにリストを「フォルダ」に分類することができるので、様々な使い方に対応できる。Todoistのほうが良かった点Wunderlistに乗り換えることにしたものの、Todoistのほうが優れていた点もいくつかあった。ルック&フィールについてはTodoistのシンプルで無機質なもののほうが好みに合っていた（なので当初は両方を比較してTodoistを選んだ）。また、スマホ版ではスワイプでタスクを完了にできるのも良かった。その他今のところ無料版かつ個人利用のみなので、共有などの機能を使ってみればまた評価は変わるかもしれない。リンクWunderlist | To-do リスト、リマインダー、タスク管理 - App of the Year!To-Doリストとタスク管理。無料、簡単、オンラインとモバイル用: Todoist

タスク管理をTodoistからWunderlistに乗り換えた

機械学習でJリーグの観客動員を予測するコンテストで3位になったので発表会に行ってきた。datasciencelab.jp前から機械学習のコンテストには興味があったけどなんとなく敷居が高くて勇気が出なかった。今回のは学生向けだし手軽にできそうなので、ものは試しと思って参加してみた。発表会は上位者の発表とか本職の人の講評とかとても参考になった。1位のid:puyokwにあとでコード見せてもらって、Rも悪くないなと思い直した（自分は懇親会でひたすらPython3推しまくってた）。GBM/xGBM勉強したい。自分のモデリングの反省としては、生データをもっと綿密に見ていればよかったと思う。トレーニングデータに無観客試合が混じってたり、今季J1に初昇格したチームがあったことに気づけばもう少し改善できたはず。許可をもらったのでコードと発表資料は公開しておく。github.com数ヶ月後に自分で見なおして「こんときは全然だったな」と思えるようになってたい。

第1回データサイエンス・カップ 2015 春

はじめに夏休みにいくつかのWeb系インターンに行ってきた。HadoopとかElasticSearchとかのいろんな技術に触らせてもらえて面白かった。それぞれの内容については、あまりしゃべってはいけないないこともあるので割愛する。インターンに行く前にやっておいて良かったこと、やっておけば良かったことを書いておく。自分用の設定をまとめておく特に1週間とか期間の短いインターンで、会社が用意してくれるコンピュータを使って開発する場合、自分の環境をポータブルにしておくとスムーズに開発が進められる。dotfilesGitHubかBitbucketにdotfilesレポジトリを作って置いとくと便利。GitHubからのクローンやシンボリックリンクを自動化しておくとより便利。シェル: .bashrc, .zshrc などエディタ: .vimrc, .emacs などターミナル仮想化: .screenrc, .tmux.conf などその他: .gitconfig などその他OSのキーボードショートカットやトラックパッドの動作がいつもと違うと地味に気になるので、自分の設定をどこかに書き出しておく。ツールは一覧とインストール手順をまとめておくといい。brew-caskとかを使うのもアリ。MacでiTerm2, Alfred, ShiftItとかを常用していたけれど、最初のインターンではdotfilesしか準備してなかったので、この辺もまとめておけばよかったと切実に後悔した。ちなみにiTerm2は Preferences -> General -> Save Settings to Folder で設定をエクスポートできる。知っておくべきこと当然、Webプログラミングに関する次のような最低限の知識・スキルは身につけておくべき。HTML, CSS, JavaScriptRuby, Perl, PHP, Python等サーバサイドでよく使われる言語のどれか基本的なLinuxコマンド開発上触れることが多いツールについても知っておいたほうがいい。バージョン管理とチーム開発: Git, GitHubSSH接続: ssh, scpコマンドリモート上で動くエディタ: VimかEmacsターミナル仮想化: screenかtmuxパッケージ管理: yum, apt-getなど使うことになる言語やフレームワークはインターン先によって様々なので、それよりMVCフレームワークなどの一般的な概念について勉強しておいた方がいい。フレームワークが違っても基礎にある概念は似たようなものなので、実際に使える言語はひとつとかでもそれほど問題ない。その他種々の手続にいるもの当たり前だけど、交通費・宿泊費・給与などを支給して貰えるとこだと銀行口座情報や印鑑が要る。研究室への周知大学・大学院で研究室に所属している人は予め不在を伝えておく。おわりにWeb系のインターンは基本どこいっても何か学べることがあるので、しっかり準備して楽しんできましょう。

Web系インターンにいくときの準備

当方VimもEmacsも使えないゆとりSublime Textのヘビーユーザなので3の正式版がいつ出るか出るかと心待ちにしてたんだけどなかなか出ないorz本家のβも2013年12月のリリースで止まってるしもう気が気じゃない...それでコミュニティを見てたらこんなスレッドを発見。4月に僕より少し気の短い人が書いたみたい。「3まだ出ないの？」When will sublime 3 be released?Postby toplinuxsir on Mon Apr 28, 2014 4:36 amThe sublime 3 development status is not updated for long timeWhen sublime 3 will be released?最初はみんな楽観的で「出せるようになったら出るよ」Re: When will sublime 3 be released?Postby jbrooksuk on Mon Apr 28, 2014 9:10 amWhen it's ready.「休ませてあげようよ！」Re: When will sublime 3 be released?Postby jbrooksuk on Mon Apr 28, 2014 1:12 pmIt's not dead.People deserve and need holidays.って感じだったんだけど、「TextMateと同じ道をたどるんじゃ・・・」Re: When will sublime 3 be released?Postby kpublik on Fri May 02, 2014 7:06 pmWow, I'm having TextMate flashbacks. Little or vague info from the dev. Forums posts from > apologists and those in denial about the project's status.TextMate was a paid product too, yet the developer has been dragging out an official 2.0 release for years. Most people have moved on, and for a while that was to SublimeText. However, competitors are on the horizon, some with more resources and a lot more professionalism than > Sublime's developer.TextMate missed an opportunity to continue to dominate the text editor market, and now it seems > that SublimeText is making the same mistakes.I paid for ST 2, but doubt I would "upgrade" to 3.0, when (if?) ever that is released.「みんながお金払わないから・・・」Re: When will sublime 3 be released?Postby macjohnmcc on Sat May 03, 2014 5:38 pmThis is what happens when you have a project where only one person is running everything. Especially if the product is not paying for their living expenses.I suspect that because Sublime Text will let you use it indefinitely without paying that many people use it without paying. There may be a huge user base but I suspect a large number of them do not pay.Also figure that Sublime Text works on several platforms that it takes more development and testing efforts so expecting constant updates from the sole developer and tester while desirable isn't likely.だんだん雲行きが怪しくなってきたぞ・・・とその時。「開発版の新いビルド出したよ！」Re: When will sublime 3 be released?Postby jbrooksuk on Mon May 05, 2014 9:41 amI just had a dev build update.おお！死んでなかった！というわけで、開発はゆっくり進んでるみたい。よかったよかった。

Sublime Text 3はいつ出るの？

大学にGitHubが講義しに来てくれた。GitHub Kaigiってのの後でわざわざ寄ってくれたっぽい。最初にCoby Chappleって人がGitHubでの働き方とデザインについてしゃべってくれた。GitHubではリモート作業がデフォルトで、社員の60%がリモートらしい。プログラマばかりではなさそうだし、英語もそんなできる人ばかりじゃないから簡単な話にしてくれたのかもしれない。USBメモリ回して配布してたのがちょと笑えた。それからJordan McCulloughってひとがGitHub入門教室をやってくれた。GitHub専属のトレーナーらしい。そんな仕事があるってことに驚いた。vim使ってる人？」って言われて結構な人数が手を挙げるとJordanがにわかにテンション上がってて微笑ましかった。GitHubの中の人はみんなAtom推しなのかと思ってたけど全然そうじゃなかった。出不精なので大学でこういうのやってくれるの嬉しい。

GitHubが大学に来た

自分のファイル管理方針をまとめただけのもの。バックアップ専用のサーバを使える人とかGitで人生の半分を管理してる人とかは好きにすればいいと思う。あと絶対外に出せないファイルとかも対象外。簡単に言うとこんな感じ。ちょっとでも「無くしたら困る」と思うものはDropboxにぶちこむDropboxが一杯になってきたら使ってないファイルをzip圧縮してGoogle DriveとUSBメモリに移動ファイルがある場所の名前ローカル各デバイスの内蔵ストレージオンラインDropboxGoogle DriveiCloudGitHubBitbucket外部メディアUSBメモリCDDVDファイル管理の詳細ファイルは何でも次の原則に従って管理する。1. ローカルに作成どんなファイルでもいきなりオンライン上に作ったりせず、まずはローカルに作成する。2. オンラインで運用作成後、少しでも「無くしたら困るな」と思ったらすぐオンラインに置く。どのサービスを使うかはファイルの種類による。文書 -> Dropbox写真, 音楽, 動画 -> iCloud, Google Drive公開ソースコード -> GitHub非公開ソースコード -> Bitbucket3. オンラインと外部メディアにバックアップ一度でもオンラインで運用したものはまたいつ必要になるかわからないので、消さない。オンラインが一杯になってきたら、使ってないファイルをディレクトリごとzip圧縮してGoogle Driveに放り込む。Google Driveアカウントはバックアップ専用のものを一つだけ用意しておいて、ファイルの種類によらずそこに貯めていく。それと大容量のUSBメモリを一個用意しておいて、バックアップ用Google Driveを（手動でいいので）ミラーリングしておく。その他ファイル形式はなるべくメジャーなものにしておく昔一太郎文書開けなくて苦労したディレクトリ名・ファイル名にはASCII文字しか使わないシェルで正規表現使って一括処理とかしやすい

個人的ファイル管理

最近Qiitaを始めて、最新の投稿で10件目になった。プログラミングスキルとか大したこと無いけど、研究で英語の自然言語処理ツールとか使ってたので備忘録も兼ねていろいろ書いてみた。マニアック過ぎて誰もストックしてくれないこともあるけどマイペースに続けていこうと思う。http://qiita.com/yubessyPython2のstr/unicodeとencode/decodeMediaWiki APIを使ってWikipediaの情報を取得The New York Times Annotated Corpus英語テキストの自然言語処理ならStanford NLPStanford CoreNLPをPythonから使うStanford CoreNLPのannotator一覧PythonでExcelファイルを作成 + similarity matrixoh-my-zshチートシートSublime Text 2でコマンドパレットのコマンドにショートカットキーを割り当てるPythonのbottleでBASIC認証Markdown万歳。

Qiitaを始めた

マルチディスプレイするときの選択肢として「縦置き」がメジャーかは知らないが、個人的には縦置き（ピボット）可能なディスプレイというのはかなり重宝する。そもそもドキュメントにしろWebページにしろコードにしろ基本縦長だし。まあ最近の高解像度&ワイドなディスプレイはウインドウを横に何個も並べて使うものなのかもしれないが。 自分の環境はこれメイン（右側）：23inch　フルHD（1920x1080）サブ（左側）：19inch　SXGA・90°回転（1024x1280）適当でごめん。 サブは５年ぐらい前のDELL製で、たまたまピボット機能がついていた。フルHDを新しく買ったとき、古いのを捨てるのももったいないのでデュアルディスプレイにしてみたら、これがすこぶる心地良い。サブで開いてるWebサイトを参考にしながらメインを横２分割してコーディング、とか慣れるとすごくはかどる。 SXGA（1280x1024）〜UXGA（1600x1200）ぐらいのディスプレイが余ってる時は、「縦置き」おすすめ。ディスプレイアームとか使えば新しいディスプレイ買うより安上がりだし。ちなみにフルHD以上のを縦置きにするのはかえって見にくい気がする。Googleなんか、一反木綿に見える。

余ってる小さめのディスプレイは縦置きで使うと便利

yubessyと言います。 Pythonが好きです。 よろしくお願いします。

yubessy