Blog Posts (in Japanese) | Democratizing Data

TikTokで勝手にアカウントが作られ続けるので、Claudeでカナダのprivacy法に則って通報をした

Fri, 24 Apr 2026 17:27:00 -0700

Warning

この記事は、Claude Opus 4.7とのやり取りを通じて解決した問題の顛末を、Opusに書かせたものです。ある程度のレビューはしていますが、情報の確実性はご自身で再検証することをおすすめします。

tl;dr

自分が使った覚えのない TikTok アカウントが、僕のメアドで2つ作られていた（@chezou2 と @nigtg679）
TikTok はメアド認証なしでアカウント登録を許可している。これが構造的な同意の欠落
TikTok サポート経由で1つ目を削除させたが、しばらくして別のアカウントが同じメアドで作成され再発
カナダの規制機関2つに通報した
- （）に違反として通報
- （Office of the Privacy Commissioner of Canada） に違反として正式 complaint 提出
OPC は2025年9月に既に TikTok 相手に joint investigation の Report of Findings ( ) を出しており、僕の complaint はその文脈に乗る形になった
カナダ居住者なら同様のケースで使える手順をまとめておく

何が起きたか

2025年11月頃から、noreply@account.tiktok.com という送信元から「新しいデバイス（LGE LM-Q730）からログインがありました」というメールが届くようになりました。僕は LG の Android 端末を持っていません。そもそも TikTok のアカウントを作ったことがありません。

メールの宛先は僕のプライベートのGmailのメアド。メール内では @chezou2 というハンドルが言及されていて、僕のハンドル（@chezou ベースのもの）に近い名前で誰かがアカウントを作ったらしい、ということがわかりました。

ここで気付いた違和感: TikTok は、メアド認証なしでアカウントを作らせている。僕のメアドに「このメアドで TikTok アカウントを作ろうとしている人がいます、本人ですか？」という確認メールは一度も来ていない。にもかかわらずアカウントが成立している。

つまり、登録時のメアド入力に対する所有確認が一切行われていません。誰でも他人のメアドでアカウントを作ることができ、本来の所有者は通知メールを受け取り続ける構造になっている。

1回目の対応：3月にTikTokサポートへ

3月15日、TikTok の privacy report フォーム（https://www.tiktok.com/legal/report/privacy）から「Report a potential privacy violation」として通報しました。

返信は feedback@tiktok.com から、テンプレ的な内容で「アカウントを削除したい場合は、ログインして設定画面から削除してください」というもの。そもそも自分のアカウントじゃないからログインできない、というのが問題の本質なのに、こちらが所有者であることを前提とした応答が来る。

返信して「これは僕のアカウントではない、誰かが僕のメアドで作ったものだ、削除してほしい、PIPEDA 適用の話だ」と書きました。すると次の返信で、こう言われた。

アカウント所有を確認するため、以下の情報を提供してください: 登録日、最初のログイン場所、登録時のデバイス、登録時の電話番号、リンクされた SNS アカウント…

これに答えられるわけがない。答えられないこと自体が、僕が所有者でない証拠です。再度返信して、「これらの情報を提供できないこと自体が、僕がアカウントを作っていない証拠だ。所有者であることを示せという要求は、non-user からの申し立てには構造的に応えられない」と書きました。あわせて「30日以内に解決しない場合は OPC に formal complaint を出す」と通告。

その後、@chezou2 は削除されました。

ところが再発

僕が TikTok への返信で「30日以内に解決しなければ OPC に formal complaint を出す」と通告していたのですが、その期限が過ぎた翌日の4月16日から、別の送信元（notification@service.tiktok.com、Reply-To が edm.feedback@tiktok.com）からメールが来るようになりました。今度は @nigtg679 という別のハンドル宛て。フランス語で「Mrs-mama💕✨️😘 t’a envoyé un message」みたいな、フランス語圏ユーザーからのメッセージ通知。

つまり、@chezou2 が削除された後、また別の誰かが僕のメアドでアカウントを作ったわけです。

ここで個人の問題を超えていることがはっきりしました。個別アカウントを削除しても、TikTok がメアド認証を実装しない限り、永遠に同じことが繰り返される。

ちなみに Reply-To にある edm.feedback@tiktok.com の edm は業界でいう “Electronic Direct Mail”、つまりマーケティングメール基盤の符牒。TikTok 自身がこれらの通知メールを marketing email infrastructure 内で扱っている、という小さな証拠でもあります。

規制当局ルートを2本

ここで「個別削除を申請し続ける」のは無限ループだと判断し、規制当局に持ち込むことにしました。カナダで使えるルートは2本あります。

（Canada’s Anti-Spam Legislation） /

CASL は同意なき商業電子メッセージ（CEM）の送信を規制する法律。ポイントは：

違反に対して 罰金を課す権限 が CRTC にある
TikTok からの通知メールは「TikTok プラットフォームへの利用を促進する」 = 商業活動の促進、と解釈できる
transactional notification（アカウント所有者向けの取引通知）の例外は、僕が アカウント所有者ではない ので適用できない

通報先は（spam@fightspam.gc.ca）。実は メールに直接転送できる（オンラインフォームより楽）。コンテキスト説明メールを1通送り、添付として証拠メールを .eml 形式で5通同梱して送信しました。

注意点: SRC は個別の case outcome を complainant にフィードバックしません。だから「処理が終わったら教えて」という期待はできない。集積されたデータが enforcement target の特定に使われる、という形。

（Personal Information Protection and Electronic Documents Act） /

PIPEDA は個人情報の収集・使用・開示に同意を求める法律。本件で問われるのは Schedule 1 の Principle 4.3（Consent）。

OPC への formal complaint は経由。ここで罠がありました。

フォームの自動ロック問題

最初に試した時、フォーム内に「他の機関に同じ件で complaint を提出していますか？」という質問がありました。CRTC SRC に出しているので素直に「Yes」と答えたら、システムが自動的にセッションを終了させ、「他の手続きを完了させてからまた来てください」というメッセージで蹴られました。

しかし SRC は個別フィードバックを出さない（前述）ので、待っていても「終了」は永遠に来ない。これでは PIPEDA 申立てが事実上不可能になる。

Information Centre 経由でリカバリ

OPC にはがあり、自由記述2,000文字以内で問い合わせができます。ここに「自動ロックされた、CASL と PIPEDA は対象としている問題が違う、どうしたらいいか」という旨を送ったところ、24時間以内に OPC の担当から書面で返信が来ました。

返信内容は要約すると：

TikTok の privacy contact（TikTok Inc., Culver City）へ書面で連絡することを推奨
それでも解決しない場合は、formal complaint を提出してよい
フォームの「他機関への complaint」質問には 「No」と答え、free text section で状況を説明 してほしい

OPC自身がフォームのバグ的挙動を認識していて、回避方法を書面で指示してくれた、というわけです。

Formal complaint の構成

OPC オンラインフォームは Part A（組織への接触履歴）/ Part B（管轄判定）/ Part C（詳細・救済）の3部構成。Part C は4つの自由記述欄があり、それぞれ500〜2,500文字制限。

法的根拠の組み立てとしては:

Principle 4.3 (Consent): 同意なしに個人情報（メアド）を収集・使用している
Principle 4.3.2 (Meaningful consent): メアド認証がない以上、同意の存在を裏付ける機構がそもそも存在しない
Reasonable expectations of a non-user: PIPEDA Findings （Facebook が non-user のメアドを friend suggestion に使った件）が直接の precedent

要望としては:

PIPEDA s.17.1 に基づく Compliance Agreement — メアド認証義務化、non-ownership-based の苦情プロセス整備
僕のメアドに紐づく全アカウントの削除
僕のメアドの blocklist 登録
Public Report of Findings の発行（僕と同じ被害に遭っている人がいるはず）

添付資料は8ページ以内、25MB以内で、TikTok サポートとの3月の往復スレッド・OPC Information Centre からの返信・11月の security notification・4月の social notification サンプルを PDF 化して同梱しました。

既存の OPC × TikTok の文脈

書きながら気付いたのですが、OPC はすでに2025年9月に TikTok 相手の Report of Findings ( ) を出しています。OPC、CAI（Quebec）、OIPC BC、OIPC AB の4機関 joint investigation で、主に未成年者からの同意取得とターゲティング広告の問題に焦点が当てられたもの。

僕のケースは未成年者問題ではなく、non-user の同意を得ない個人情報利用という別の角度ですが、「TikTok の同意取得の実務全般に問題がある」という OPC の認識と整合する話。投稿のタイミングとしては悪くない（OPC の興味の射程内に入りやすい）。

ちなみにこの Findings の中では、BC PIPA と PIPEDA の jurisdiction 関係についても整理されていて、cross-border data flow の場合は両者が “airtight seal” で適用される、という理屈が示されています。僕が BC 在住で TikTok（シンガポール法人）相手という構図でも、PIPEDA 適用に問題がない理由がここで補強されます。

カナダ居住者へのチェックリスト

同じような状況に遭遇した人向けに、手順を整理します。

ステップ0: 現状把握

不審なメールの送信元、送信日時、本文内容を保全する
Gmail なら spam フォルダから救出してラベル付け（30日で自動削除されるので注意）
本文中に出てくる「自分のものではないアカウントハンドル」をメモ

ステップ1: 相手企業に書面で連絡

企業の privacy report channel から書面で連絡する（メール、フォーム、どちらでもよい）
PIPEDA を引用する（信頼性が変わる）
「自分は所有者ではない」「メアド所有者として削除を要求する」を明確にする
30日以内の解決を促す

ステップ2: CRTC SRC に CASL 通報（マーケ性のあるメール）

に状況説明＋証拠 .eml を添付して送る
フォーム経由より、メール直接転送のほうがヘッダー情報が完全に保持されて証拠能力が高い
個別フィードバックは来ない前提

ステップ3: OPC に PIPEDA complaint

まず Information Centre に状況を聞く（フォーム経由、2,000字以内）
24〜48時間で返信が来る
指示に従って formal complaint を提出
添付資料は8ページ以内、25MB以内

注意点

OPC は現在処理遅延あり（数ヶ月）。すぐに結果は出ないと割り切る
BC OIPC（州機関）にも管轄が及ぶ可能性があるが、cross-border の場合は PIPEDA 適用が筋。OPC が必要なら自動的に振り分ける
OPC は order-making power を持たない（罰金を課したり強制執行したりはできない）。最強のツールは Compliance Agreement (s.17.1) で、これは Federal Court で強制執行可能。だから明示的に要求する価値がある

雑感

（ここは人間が書いています）

今回、Sonnet 4.6で調査を開始したのだが、正式にcomplaintする段になって念のため出たばかりのOpus 4.7で検証をさせたところ、だいぶ間違いや思い込みを正せたのでよかった
- たとえば「30日対応がなければ OPC に行ける」という Sonnet の主張は、実は法的根拠がなく Sonnet が圧力装置として勝手に設定した期限だった、というのを Opus に指摘された。これは戦術的には機能するものの、法的デッドラインと誤認すると別の判断ミスにつながるので、確認できてよかった。
こういう法律系の調査を全部自力でやるの相当厳しいので、リファレンスはAIに取ってこさせて自分でも確認するのが良さそう
こういった重めのトラブル解決を考えると、個人でLLM系のサービスを契約しないと辛いですね…

AI時代の転職活動記録

Fri, 17 Apr 2026 21:25:00 -0700

今回、転職活動をするにあたって、AIをフル活用して活動をした。前職ではGithub Copilotが個人アカウントだが会社にコントロールされていたので、せっかくだからとClaude Proを契約して望んだ。

2年前くらいの転職活動でhiring managerと話ができないreferalは全部書類で弾かれた反省から、今回はLinkedInで自社の採用担当から連絡が来たものを受けることにした。並行して知り合いにreferalを頼んだ。今回はLayerXをreferalしてくれた友人と同じチームに入ることになり、採用ペースが全く合わなかったため他の選考は辞退した。

転職活動でやったこと

主にやったことは以下のようなことである。

Claudeを使って企業調査をした
LLMと内省し、何が得意、何がやりたい、何がやりたくない、何が苦手、などを徹底的に言語化した
毎日Apple Notesにジャーナルをつけた
スケジュール管理のサポートをClaudeにしてもらった
過去のプロジェクトで達成したことや苦労したことをエピソードバンクとしてNotionに書き出して、ClaudeにコピペしてSTAR methodのbehavioral interviewスクリプトを生成させた
resumeは元となるものを用意しておき、エピソードバンクも活用してJDを食わせて都度調整した
LeetCodeは年間契約していたが、Claudeもやらなくて良いと言ったのでやらなかった（実際には、LeetCode的tech interviewをしないと書いてあるところを中心に受けたのもある）
- Big TechはLeetCodeの難易度が上がっているという話も聞くので、Data Structure & Algorithm苦手勢としては受けなかった
Technical interviewの宿題は、週末体調崩していたのでClaude Opusと対話してコードを書かせた
同時期に転職活動をしていた仲間内で状況を共有し合っていた

とにかく、テキストを書いて増やしていくと、LLMに投げると更に深堀りできるし、言語化が加速していくのがしんどいがとても良かった。

以下には、特にAIを活用するためにしたことを書いていく。

Claudeを使った企業調査

これは、 shiumachiさんに教えてもらったやり方なのだが、会社のカルチャーを理解するために企業調査をClaudeにさせたのがとても良かった。

XXX という会社について調査してください。会社としてのビジョン、経営者や創業者の思想や価値観、会社の文化、ビジネスモデル、ビジネスとしての発展性など、転職先としてどれだけ魅力的かについて調査してください。レポートは日本語で書いてください。MLEあるいはAI Engineer、Backend Engineerとして転職活動をしようとしています。

特に経営者や創業者の思想や価値観は非常に重要で、ここを理解することで営業ドリブンの会社なのか、エンジニアリングに重きを置いているのか、投資家に寄っているのかなどがわかる。

LLMを使った内省

これもshiumachiさんに勧められたのでやってみたのだが、以下のことをLLMと問答をすることで整理していった。

やりたいこと
やりたくないこと
できること
できないこと
好きなもの
嫌いなもの

これは結構重要で、自分がMLEからAIへとフィールドを広げていくのにあたって、「古典的なMLを含んだHuman-in-the-loopの必要なprobablisticなコンポーネントを含むシステムの設計や実装」がやりたいという、MLEとしての自分を再定義することが出来た。

ジャーナル

これもshiumachiさんに勧められてはじめた。まあ、日報みたいなもので、そのときにやったこと、あるいは感情を残していった。これも残しておくと更に深堀りするポイントが見つかるので、都度LLMに食わせて問答をしていった。

エピソードバンク

もともとは、レジュメ更新のために過去のプロジェクトの棚卸しをしていったのだが、過去のレジュメには書いたけどもう落としてしまった話や、過去の行動面接対策で書き記したエピソードをNotionで1ページにまとめて、新しいエピソードも追加した。このエピソードバンクを作ったのはとても良く、STARメソッドに従った行動面接の想定問答をOpusに生成させて後はそれを覚えるなりチラ見しながら話せばいいのである。

同時期に転職活動をしている仲間との進捗共有

エンジニアコミュニティで同時期に転職活動をしている人がいたので、その人たちに活動を共有しつつお互いの状況を把握していた。これは良くて、そういうやり方があるのかー、とか今どきそういう面白い面接あるのねー、などと刺激になった。

ほとんどshiumachiさんの影響によってAI活用していた気もするが、実際だいぶ初速がついた。転職活動として退職の通知をした後も、様々なことが起こったのだがそれらを解決するためにもプライベートで契約をしたClaudeには大活躍をしてもらった。法律周りとか自分で調べるのめちゃくちゃしんどいし、転職前にLLM関連の予習をするのにも大活躍した。ある意味仕事よりもハードにこちらのリソース管理をされていた気がする。

LayerXで働き始めました

Fri, 17 Apr 2026 18:33:00 -0700

友人であるに誘われて、4/1にLayerXのAi Workforce事業部に入社しました。居住地は引き続きバンクーバー（の2つ隣の市です。いわゆる「神奈川」の代表点としての「横浜」みたいな説明）です。

前職でCEOが「AI Native企業になる！」と言い続けていたので、Bet AIする会社に入ってみたらどうなるかな、と思って入りました。

riywoさんとは同じチームですが、僕はStaff Software Engineerとして働いています。が、やることはいっぱいあるので、よしなに問題を解決していってくれ、という係をやっています。TDでの経験も生きるとこがいっぱいあるなーと思って、口を突っ込ませてもらっています。

久しぶりにスタートアップな感じの勢いを感じており、クックパッドの時の終わらない文化祭前みたいな感じでとてもワクワクしています。動くものをサクッと作ってデモして、それを見て盛り上がって顧客の課題を解決していこうというのはAI時代にはとてもいいですね。

CEOのfukkyさんやCTOのymatsuさんが、日々手を動かしたりしつつビジョンを共有してくれるのはとても新鮮です。ymatsuさんと話したときに「手触り感がわからなくなると終わる」という言葉はとても印象に残っています。

かれこれ10年近くアメリカ企業で働いており直近使ってきたのは英語とルー語だったので、日本語がでなくなっているのが目下の悩みです。とはいえ、元外資系のエンジニアも増えてきているみたいなので、アメリカンな割とダイレクトコミュニケーションでも生きていけそうです。

転職活動についてはのでよければお読みください。

Treasure Dataを退職しました

Tue, 31 Mar 2026 19:08:00 -0700

2026/3/31付けで7年半務めたTreasure Dataを退職します。

過去記事

原初のMLチーム（傭兵期）

入社したのはArm買収直後のタイミングでした。最初は3人しかいない当時CTO（元CEO）直下の遊撃部隊としてのMLチームからはじまりました。前職ではSales Engineer（AWSで言うところのSA）だったので、実はSWEに戻るための転職活動は結構大変でした。（TDから声をかけていただいたさんには感謝）

ただ、その中でも面接でプロダクト志向がとても強いとの出会いがTDの入社の決め手だったのを今でも覚えています。そして、その直感は正しく、の開発なんかで一緒に働くのはとても楽しいときでした。彼とは今も友人関係として良くしてもらっています。

この時代は、顧客のMLキャンペーンのお手伝いをさせていただいたり、Custom Scriptと呼ばれるPythonをTreasure Workflow（TDのhosted digdag）上で動かす機能のPythonがまともに動くようなML use case及びそのサンプルコードを作ったり、顧客ミーティングに飛び入りで売り込みをさせていただいたりと、遊撃部隊ならではの幅広い活動をしていました。顧客ミーティングにスライド持っていってデモして売り込んだのは、まだまだ小さい組織だったのもありますがCloudera時代の経験が生きた瞬間でした。

AudienceチームでのCDP開発（一人一殺時代）

CTOのArmでの活動が増えてきて、MLチームが維持できないという話になり、CDPを開発しているAudienceチームに移籍する話になりました。その時、海外で働きたいという話を再度上司であったCTOにしたところ「TDを通じて海外で活躍できるエンジニアを増やしたい」とVancouverへのrelocationを快く応援していただいたのは、とても感謝しています。

仕事としては、CDPの画面を新しくするのに伴って、フォルダ構造を取り入れるためのプロジェクトで各種機能の実装をRailsでしたり、サーバーサイドKotlinでRealtime ID Stitchingを実装したけど出なかったりといろいろとやりました。一人一殺と言われていた時代です。

幸いなことに、Vancouverで北米西海岸にいるPdMやUXデザイナーと一緒に仕事する機会も多かったです。Clouderaで英語に多少自信をつけておいたのでガッツで乗り切りました。（そもそも、TDの人々がnon nativeの英語に寛容なのが大きい）

このとき、Rubyコミッターでもあるnaruseさんとkaneko.yさんのチームで働き始めたのですが、その後もずっと社での戦略的な振る舞いをどうするかのアドバイザー的なことをずっとしてもらい、大変お世話になりました。この二人の現状認識と議論、ツッコミは今思い返しても良い訓練になりました。

特に、なんかわからんけどうまく行かない、という状況をメタに整理して、「なぜこの人はこのようなことを言っているのだろう」という「筆者の気持ちを推測する」ことを無限に繰り返していたのですが、これが非常に後々まで役に立つスキルとなりました。何かしらの矛盾している声明が出たときに、昔であればともすれば感情的に「何いってんだ？」と反発するようなことを思ってしまったのですが、今では「ああ、これはこの人も混迷を極めており、助けを求めているのだなあ」と判断できるようになりました。

これは、僕が割とエンジニアとしてはempathyを強めに感じてしまう方なのですが、彼らは現象とその背後にある論理を徹底的に言語化するということに長けており、ある種感情を理詰めで理解するという営みだったと思います。社会性を模倣から獲得することで伸びたスキルなのかもしれないとも思いますが、僕には足りていない要素だったので、他では得難いスキルを得ました。

また、kaneko.yさんと退職前に反省会をしたときに、「丸くなりましたね」と言われて、ふと人に動いてもらうためにどう言葉をかければいいのか、というのを仕事では使えるようになっていたのだな、と思いました。（家庭ではよく怒られが発生するのでまだまだなんだとは思います）

naruseさんがkaneko.yさんをEMラダーに移るよう説得したときの「正しいものを作るには、それをできる力を自分で得る必要がある。」という言葉は、後のTech lead業をするに当たって都度都度振り返った言葉でもあります。Principal業は割と境界をどう押し広げるか、ということの繰り返しだったことが大きいです。

途中でチーム再編があり、Vancouverで一人他は全員東京メンバーになったときにも、ex-Cookpadのよしみでinohiro氏を社内から引き抜いてきたりと、チームを安定化するのにも貢献できたのは良かったです。

2回目のMLチーム

2年半くらいMLプロジェクトのTech Lead業をやっていました。MLプロジェクトのエンジニアリングをリードとして何でもやる係を任され投入されたのですが、なんだかんだでMLチームを作っていく仕事も任されるようになりました。最初は、チーム所属を変えないでSr Eng Directorと密にやりながら進めていったのですが、紆余曲折ありMLチームを直接率いる事になりました。

そのあたりは以下の記事でも書いたとおりなので、よければ見てください。

自分が骨を砕いたのは、いかにMLという力を使って顧客価値を出していくのかということでした。、それを実現するためにあの手この手を尽くしました。

結局、MLプロジェクトのリードをするようになって、3回くらいメンバー入れ替えに伴うチームの立て直しをしました。採用はとても重要で、妥協なくやらないとリカバリに半年とか平気で飛ぶというのも学びました。（自分で言うのもなんですが）粘り強く今持っている手札で出来る打ち手を考え続けるということをやり続けられたかと思います。

途中で組織変更があって、レポートラインがSr Eng Director直になったことも、自分のキャリアとしては非常に大きな転換でした。彼のコミュニケーションスタイルはとても粘り強く相手の意図を汲み取るために全力を尽くす、というスタイルで、理解が難しい発言や声明も自分がアクション可能な形へと落とし込む力はとても勉強になりました。

彼はIT業界で長くやっていることもあり、ドットコム・バブルやリーマン・ショックなどの変化を経験してきているわけです。そんな中で、AIによる様々な変化に対してどう向き合ってるか聞いたところ「ソフトウェアエンジニアリングにおいて、新しいパラダイムが来てもいつもすべての問題を解決するわけではない。新しい課題も生まれる。それを解き続けるのがエンジニアリングだ。AIもそうだと思っている」との言葉をもらいました。これは非常に心強い言葉だなと思うとともに、隙間時間でOpenAI Agents SDKを触って自分の業務を自動化したりしてる、という変化に適応し続ける姿勢に裏打ちされているものであるのだと再認識しました。彼の口癖は “We should be prepared for the changes, even if that’s a hard change.” （先回りして考えておけることは考えておく。たとえどうしようもない変化でも、覚悟しておくだけで折れずにいられる）というもので、これは僕も強く共感を覚えています。

自分の上司の中でも彼の右腕として働けたのは、とても学びも大きく良かったです。これが、 thought leaderなんだなと感じました。

終わりに

7年半と自分のキャリアとしては一社で過去最長の勤続をすることとなりました。そして気がつけばVancouverに来てちょうど5年経ち、こちらで働いた期間のほうが長いのも感慨深いです。

次は明日から相変わらずVancouverから新しい会社で働きます。今度は、AIの世界にどっぷり浸かろうと思います。

ワークフローテンプレートをskillに埋め込んで、LLMの役割を「生成」から「レンダリング」に変えた話

Sat, 28 Mar 2026 18:03:00 -0700

MLワークフローのLLMによる自動生成の夢

会社のというML機能では、(MLではないが)RFMや推薦、Contextual Banditといった処理を行う機能がある。特にMLの予測処理をスケーラブルに実行するために、ML用APIをcallすると裏側でAWS Batchが起動して並列でworkerを立ち上げるという仕組みを取っている。この並列実行をするためには、入力テーブルをprofile（マーケティングキャンペーンの対象となるエンドユーザー）ごとに集約するという割り切りを入れることで、スケーラビリティを確保している。これらの処理は、digdagのworkflow（.digファイル。実際にはTreasure Workflow と呼ばれる hosted digdagで実行される）と、workflow内に記述されるSQL（Hive または Trino）とで管理されるワークフローからML APIがdigdagの http> operatorで呼び出される。

元々のプロジェクト開始時の座組としては、こうした前処理的・後処理的なワークフローはProfessional Serviceと呼ばれる有償のポストセールスエンジニアのMLEが自分たちで作成したテンプレートを元に、PSを購入した顧客にそのワークフローを展開していたのだが、この枠組みを超えて多くの顧客へ展開したいということで、LLMによるワークフロー・SQL生成が期待されていた。だが、モデルが日々良くなってるとはいえLLMによるワークフロー・SQL生成を安定して行うことは難しく（例えば、TD固有のUDFはぱっと出てこない）、何度か挑戦していたが諦めていた。

Claude Codeの進化とエージェント用CLI

そんな中、会社でAI Native企業になるというCEOの号令のもとClaude Codeの全社導入が進んだ。ソフトウェアエンジニアだけではなく、PdMやSolution Architect、営業にまでClaude Codeの利用が拡大された。特に重要な取り組みとしては、TDの各種マイクロサービスのAPIを叩ける統一的なエージェント用CLIのと、tdxを内包したデスクトップアプリケーションであるの貢献が大きい。Claude Codeとtdxが連携することで、エージェントがマーケティングのジャーニーを作成したりTDにあるテーブルの分析結果を可視化したりできるようになったのである。CEO自ら社員向けにオンボーディングチャレンジタスクを作ったりして利用加速を進めた結果、自社内及び顧客環境でも様々な自動化が進んでいる。

この流れで、・社内向けのSkills marketplaceが誕生した。これらを利用することで、作業の再現性が高まり、複雑な処理の自動化が加速しているのである。

ワークフロー生成におけるエージェント用CLIの功績

tdxの一番大きな功績は、Treasure WorkflowのエンドポイントをCLIから叩けるようにしたことで、Claude Codeがワークフローを作成、push、実行、結果を見て改善というフローが自律的に回せるようになったことである。ワークフローというものは実行するのに少なくとも数分、長ければ1時間以上かかるものもあるため、。

それを、Claude Code + tdxのおかげで、生成したワークフローを実行し、バックグラウンドに積んで実行結果を検証というサイクルが実現可能になったのである。これは革命的である。

APIとのやり取りを含めて一気通貫できるエージェント向けCLIは、もはやなくてはならない存在であろう。

MLワークフローテンプレートのskill化

とはいえ、冒頭でも書いたようにClaude Codeのモデルがいかに賢くなったとはいえ、事前知識がない顧客など、誰が実行しても安定的に納得の行くワークフローをLLMに生成させるのは困難である。

そこで、問題の見方を変えてみた。ワークフロー・SQLをスクラッチで生成するのが難しければ、設定ファイルのパラメータを元にワークフローとSQLを生成するテンプレートを作ればよいのである。つまり、テンプレートをskillに埋め込むことで、LLMの責任範囲は「ワークフローとSQLをスクラッチから生成する」ことから「データや問題に適したパラメータを選ぶ」ことへと狭まる。つまり、欲しいワークフローはあらかじめテンプレート化することでそこは確定的な処理として扱うのである。「」の応用といったところか。

この発想は、cdp-apiがDBの値をもとに動的にdigdagのworkflowを生成するというところから着想を得た。

digdagワークフローのJinja2テンプレート

実際にskillとして行ったのは、Jinja2でdigファイルをテンプレート化し、LLMは config.yml をsingle source of truthとしてすべての変更可能なパラメータを置き、設定値を決定することにフォーカスをさせた。 .dig.j2 というあまり世の中で見ない拡張子を見たときは、ちょっとドキドキした。

内部ではレンダー時に決定するパラメータ {{ }} と、digdagの変数として記述できるランタイム時のパラメータ ${ } を使い分けている。前者は、例えばSQLのエンジンがHiveかTrinoかによって分岐させたり、使うアルゴリズムやハイパーパラメータの候補が事前に決定できる場合に使われる。後者は、例えばハイパラチューンをした結果をテーブルに格納し、その結果をSQLで取得した際に動的に学習タスクに割り当てる、みたいなときに使う。

OpenAPI = agentとの契約書

テンプレート化をする際に厄介なのが、ML APIに渡せるパラメータが複雑であり、それをどのようにagentに教えるかということである。幸いにも、自分たちのプロジェクトでは、ML用エンドポイントのパラメータはOpenAPIで管理されており、そのspecで網羅的に渡すことが出来た。

元々、MLソリューション実行時にはOpenAPIからで生成されたmodel.pyでパラメータのバリデーションを行っていたのだが、機械可読な仕様である openapi.yml をエージェントに渡すことで、それを翻訳したmarkdownにskill化していた。標準フォーマット万歳である。

skill作成 agent VS skill使用 agent

skill作成中に作ったskillのテストどうするのがいいの？とClaudeに聞いたら、別プロセスでagent立ち上げて試行錯誤をするのが良いと教えてもらったので、それを実践した。これは非常に良い体験だった。

具体的には、skill使用agentを使うときは、OpenAPIやskillのドキュメントを自分で読むわけではないので、「このアルゴリズムとこのパラメータの組み合わせを実行したい」みたいな欲求が湧いてくるのである。通常、手動でやる sanity check だと頭に仕様が乗っており、面倒で複雑なパラメータの組み合わせはサボりがちなのだが、agentに任せれば簡単にできるという欲が湧いてくる。

しかし、skill使用agentから帰ってきた言葉は「skillを見たけどまだその組み合わせはOpenAPI的には実装されていない」という答えだった。一応、QAのend to endのテストもあると思っていたのに、危ないところであった。実際にはOpenAPIを手動で管理していたため、Pythonコード内部では実装されていたが、リクエストから受け付けるパラメータの漏れがあるのが見つかった。

このバグを早急に修正して、development環境にdeployし、skillもupdateしたところ、新しい組み合わせのパラメータをさも今までもあったかのようにClaudeは使いこなしていた。流石である。

開発しながらskillも作ることで、実行環境を用意することがかなり恩恵があるということを学んだ瞬間である。

まとめ

こうして得られたskillを社内skills marketplaceに共有することで、今まで有償PSが作っていたworkflow作成ステップを簡略化し、さらには有償PSを買っていない顧客でも利用可能となった。

また、Treasure Studioの恩恵として、MLで予測した結果を可視化できるようになり、簡単に分析・モデル改善のサイクルが回せるようになった。これらの分析のパターンもskill化していくと良さそうだが今回はスコープ外とした。

この記事を書くときにClaudeと壁打ちをしていたのだが、「LLMの強みは問題の構造を理解することとパラメータ推論」とClaudeは主張している。それを支援するための一気通貫したCLIを用意することで、生成→実行→修正のループを自律的に回せるようになる。そこでループの複雑なタスクをテンプレート化することで、ドメイン知識のある人間と、（知識がない人が使う）agentの役割分担ができるのだと学んだ。

Montréalに10年以上ぶりに行った

Fri, 27 Mar 2026 18:40:00 -0700

3月の上旬にworkationとして友人を訪ねがてらMontréalとOttawaに数日行ってきた。

Vancouver近郊に住んでいるため、東海岸の春はどんなものかと思いながら行ったわけだが、3日いる中であったかくて寒いという東海岸らしい寒暖差を体験した。体感14℃の春の陽気から、体感-10℃のfreezing rainで学校が休みになるという差の激しさは驚きだった。

モントリオールの寒暖差 ( より)

初めて行ったときに比べて変わったのは、自分の年齢とDuolingoで学び続けたカタコトのフランス語力、生きていくには困らない程度の英語力だったわけだが、Vancouverに5年も住んでいると大きな驚きはあまりなくなっている。

街の感じは、良くも悪くもヨーロッパを感じた。石畳の上をスーツケース引っ張るのが大変なのはヨーロッパっぽいし、街並みに突如と現れる石造りの教会が多いのもそうだ。カフェに入ったらパンもお菓子も美味しいのはフレンチのこだわりを感じて良い。なんだけど、街行く人の歩きタバコも多く、バス停の屋根の下でタバコ吸って占拠してる人、それに伴うゴミに溢れる街並みを見ると、ドイツを思い出した。

今回は、友人に教えてもらってBounceを使って荷物を預けたのだが、それはとても良い体験だった。モントリオール中央駅近くのカフェに預けたので、深夜便で空港から移動をして朝ごはんをゆったり楽しむことができた。Bounceは参加しているホテルやカフェなどの施設が荷物を預かってくれるサービスなのだが、自分が預けたところは従業員しか入れないところに置いてくれており、安心感も高かった。置いておくのでよければどうぞ。

フランス語初学者としては、Montréalで注文をするのはフランス語の練習にちょうどよい。“Je voudrais un café au lait … with oat milk"なんてチャンポンに嫌な顔せず受け止めてくれた。

Montréalの街並みは昔の記憶よりもコンパクトで、ノートルダム聖堂を始め多くの道で工事をしており、のを感じた。しかし、ノートルダム聖堂でフリーWiFiが提供されているのを見たときは時の流れを感じた。YVRでApple Watchのバンドが壊れかけているのに気づいてぶらぶらとApple Storeまで散策をしたのはなかなか良かった。Apple Storeはだいたい目抜き通りにあるので、その都市の中心部を散歩する口実にはちょうどよい。

ノートルダム聖堂で提供される無料WiFi

宿はローカルのところがいいかなー、と、ケベックの会社が運営している host-me.ca という会社で民泊を予約したのだが、本当に酷い体験をしたのでマジでおすすめしない。お値打ちな宿をGoogleが「host-me.caが大元です」と出したので、Claudeに相談しながらも駄目だったら話の種になるわーと予約を取った。

が、チェックインのための鍵のコードが待てど暮らせど来ない。事前にearly checkinか早めの荷物預け入れができないか問い合わせた時についでに聞いたら「チェックイン24時間前までには送ります」とメールで言っていたにも関わらず来ない。前日の夜空港で（フィリピン等の外部委託の）サポセンに電話で問い合わせたら「お前のクレカの決済が通っていない」と言い始め、当日朝空港についたあとで、メールと電話で「約束のサービスが提供されないのでクレカのチャージバック依頼するからもう泊まらない」と言った直後に電話がかかってきて「今システム登録したから」「24時間前じゃない、24時間以内だ」「夜遅くに問い合わせされても無効だ」などと嘘や言い訳を並べ立ててきた。結局、当日ホテル取り直すよりは安いということでそのまま泊まったが、問い合わせ対応で過ごす空港のラウンジは過去一番時間が経つのが早かった。

宿自体は小綺麗でさっぱりしていたが、いかんせんという再開発エリアのため、夜一人で歩く自身はあまりない感じだった。周りに店も多くないので、観光客向けのエリアではない。なので安いんだなと改めて実感した。

Ottawaのfreezing rainで凍る枝

翌日はOttawaの友人夫妻の家を訪ね泊めてもらった。Ottawaのブリュワリーも良かったし、友人宅でいただいたMalawi料理のNsimaも美味しかった。freezing rainもice stormも何のそのということで行き帰り無事過ごせたのは良かった。

Montréalに帰る途中の凍った海

二都市をふらっと行って思ったのは、なんだかんだOttawaのほうが好きだなあということ。Montréalは思っていたより大都会で、3路線乗り換える地下鉄があるくらいである！poutineもOttawaで食べたもののほうが美味しかったのはココだけの話。もう人の多いところは無理なのだなあと思いVancouverに戻り雪山を堪能したのであった。またOntarioは行きたいものである。

ボランティアデーでWikipediaの太平洋時間（Pacific Time）の改善をした

Wed, 25 Mar 2026 17:46:00 -0700

会社のボランティアデーというのがあるので、何がいいかなと思って色々とClaudeと話したところ、WikipediaのにBC州のタイムゾーンが「太平洋時間」に変わるという発表を受け編集したのを思い出したので、それ関連の改善をした。

これは、2026/3/2に唐突に発表された話に基づいて、Wikipediaの太平洋時間という新しい「タイムゾーン」の話を更新したのだが、今日ふらっと見てみるとカナダ時間のページのBC州の項目が山岳部標準時の下の太平洋夏時間という表記になっており、うーんなんじゃそりゃとなったので、の日本語訳をした。

成果物は、を見てほしい。（ついでに太平洋時間の記述を、）

ハマりどころ

Wikipediaの存在しないページを翻訳するのは今回初めてだったのだが、色々とハマった。

LLMの翻訳をそのままは当然駄目
公式翻訳ツール「コンテンツ翻訳」は英日ではなんの訳にも立たないし、なんなら邪魔
Pacific Timeはタイムゾーンなのか論争

1に関しては、機械翻訳について結構ちゃんとがある。このケースG3のリンクにある表現は一昔前の基準ぽいが、こういうことが書かれており、問題を避けるために自分で翻訳をした。

以下のような記事は、機械翻訳が翻訳のベースとされているという事実により、百科事典の記事として正確性の問題が発生する可能性がある誤訳が含まれていることが推定されるため、削除の対象となります。

いずれかの機械翻訳の出力結果と完全に一致する文が記事に多数残されていたり、「ですます調」の修正などの翻訳文の微修正にとどまっていたりする場合。

いずれかの機械翻訳をベースにしつつ人の手が加えられているが、誤訳または日本語として不自然な文章が残されている場合。

2はケースG3からもリンクされているんだが、翻訳エラーが出るだけならまだしも、原文を転写することもできない。一度翻訳を転写するという規定を選んだが最後、空のブロックを作成しようとすると自分でやった翻訳も消える。多分、一からページ作るほうが速い。

Pacific Timeは山岳部標準時なのか、そもそもタイムゾーンなのか論争

このを見てもらうとわかるのだが、どうも自分が翻訳したブリティッシュコロンビア時間のもととなったTime in British Columbiaというページは Pacific Time (British Columbia)という名前だったようだ。

Talkをみると、UTC-7は山岳部標準時と呼ぶべきである派閥がPacific TimeはUTC-7なのでMSTの下に入れようとしている。類似例としてサスカチュワン州は通年UTC-6なので。

カナダのタイムゾーン

Mappify - 投稿者自身による著作物, CC 表示-継承 4.0, リンクによる

つまり、UTC-6は夏時間であれば山岳部夏時間（MDT）、そうでなければ中部標準時（CST）と表記すべきという話である。同様にして、UTC-7通年のPacific Timeは山岳部標準時（MST）と表現されるべきという主張である。

だが、BC州民としてはBC州の法律でという呼称は制定されており、その名称を無視するのはいかがなものかと思うわけである。

にも書かれる、BC州首相のDavid Ebyの言葉と、その翻訳を持って締めようと思う。

British Columbia premier David Eby decided to make the switch before the US due to poor relations between the two countries since the second Trump administration began, saying British Columbia should “stand on our own two feet as a province in relation to everything, including time zones”.

ブリティッシュコロンビア州のデビッド・イービー首相は、第2次トランプ政権の発足以来の米加関係の冷え込みを受け、米国に先駆けて時間帯を変更する決断を下した。イービー首相は、「時間帯の問題を含め、あらゆる面において、ブリティッシュコロンビア州は州として自立した姿勢を貫くべきだ」と述べている。

「Agents SDK+αのTipsを一人で書いていくアドカレ Advent Calendar 2025」を追走した

Fri, 20 Mar 2026 18:03:00 -0700

さんが書いてくださった、OpenAIのの追走をした。子供の春休みで有給取っていることもあり、春休みの宿題よろしくやってみた。

レポジトリはこちら:

このスレッドで試した様子を書き出している

（追走を）完走した感想だが、以前にLangChainとChromaをベースに社内のConfluenceを検索するRAGシステムを社内のハッカソンで作ったとき以来のフレームワークで、Agentのパターンを頭に入れたうえでどういう実装をしているのかを学ぶのにとても良かった。

Claude Opus 4.6に自習計画を立ててもらいながら、重要なところ、スキップするところをリストしてもらったが、先にこの記事を読んでおくとパターンが整理されて良かった。

なお、一番大事なのはネタバレが重要なフィクションを例として使えること。元々の記事では銀魂と終末のワルキューレ、僕の場合は、ヴィンランド・サガでいきました。

また、並行して会社の業務の一環としてというCLI toolと連携するための社内skillsを作っていたのも理解を深めるのに役に立った。やったこととしては、というプロダクトのソリューション、RFM、NBP（推薦）といった公開済みのソリューションを中心に、 digdag のworkflowテンプレートをJinja2テンプレート化してskillにまとめるというもの。これにより、スクラッチからdigdagのワークフローを作る必要がなく、パラメターをagentが設定すれば、tdx経由でworkflow push/runをして予測結果も可視化して分析できた。

世の中の流れ的に、エージェントの制御を自前実装するよりもClaude Codeやcodexに渡したほうが速いみたいなのが来てる感じはするけれども、その裏側でどう動いているのかを考えて設計できるようになったのは何よりだった。

あとは、メモリ周りの知識がまだ欠けているのもありそこをキャッチアップしつつ、合わせてなんかも学んでいきたい。

Oh-my-zshを辞めた

Thu, 19 Mar 2026 18:56:00 -0700

OMZは特に何も考えなくても楽に設定できたので使い続けていたが、GH Copilotなどでshell起動が重いと怒られるようになっていたところ、joker1007さんのこんな投稿を見かけた。

#izumork01 でa_matsudaさんがRubyとAIでshellを作る話をしていたので、久しぶりにzshrcの盆栽やるかーと思い立ちついにoh-my-zshを完全に削除した。zshの起動が大分早くなったので結構影響あったなーと。後、補完がちょっと豪華になるcarapaceとか入れてみた。
— joker1007 (@joker1007.bsky.social) 2026-02-26T06:05:36.507Z

ので、脱OMZをした。

: ターミナルの見た目をカスタマイズ用
: 主にgitの補完

今のところ、WSL2の環境で動かしているけど悪くはない。Starship用にNerd Fontを入れないといけないのだが、JetBrains MonoのNerd Fontをからダウンロードして使っている。

starship.tomlもこんな感じにしている。

Pages CMSからSveltia CMSに移行した

Thu, 19 Mar 2026 11:06:00 -0700

去年の夏にのだけど、色々と気になる点が出てきたのでSveltia CMSに移行した。

モチベーション

にも書いたけど、Pages CMSの以下の問題が起因だった。

タイムゾーンの扱いが雑（とにかく+00:00に落とす）だったのと、けど修正する気があまりなさそうだったこと
Hugobloxが推奨するコンテンツ(index.md)と画像が同じフォルダに置かれる構成を実現するのがかなり面倒くさい。結局手で画像をuploadしていた

やったこと

認証のためにCloudflare WorkersにSveltia CMS Authをデプロイした
Pages CMSの .pages.yml を static/admin/config.yml にClaudeが移植した
static/admin/index.html をドキュメントからコピペした
Pages CMSがdropしたタイムゾーンの問題をClaudeで復旧した

一番の難所は、Sveltia CMS Authのデプロイだけど、元々、Cloudflare Pagesを使っていたのでやることはのREADMEにあるデプロイボタンを押して手順に従うだけだった。簡単。Herokuを思い出す。

詳しくは以下のPRを見てください。

感想

Pages CMSの小さい不満点が色々と解消されているのがとても良い。例えば、400以上のpostがあるときにPages CMSだと10秒以上開くのにかかるのだが、Sveltia CMSは2秒くらいで終わる。速い。

また、M↓ボタンがあるので、これのおかげで最悪md形式で手動で直せるのがとても良い。今まではGitHubに行って手で修正していた。これは、mobileからの操作を考えたときに最悪の体験だったので、かなり助かる。

後はきめ細やかさが色々と伝わってくる。この記事を書いているときに、GitHubの障害が発生していたのだが、それのwarningが出ている。Client sideで動いてるのにこれは感動。

しかも、この画像はクリップボードからスムーズにアップロードすることができた。 Pages CMSではこの画像をスクリーンショットからアップロードしてコンテンツと同じフォルダに置くという営みが非常に難しかったから、感動もひとしおである。(この機能はばかりらしい。なんというスピード感!）

また、作者のkyoshinoさんは日本語話者なので、我々CJKの民がハマるIMEによる入力を気にしてくださっているのが伝わる。変換するのに苦がないのって本当に大事。

というわけで、しばらくは楽しく試してみようと思うが、大きな問題がない限りはこのままお世話になるだろう。

Principal と器用貧乏のあいだ

Sat, 07 Mar 2026 20:36:31 -0800

はじめに

Staff+ Engineerは高機能雑用と思いながら仕事をしてきたが、思った以上に多様なこともあり、では書いてきたけど、なかなかまとまって考えを整理することはできていなかった。

そして、自分の与えたインパクトをレジュメに上手く表現できないことにもしばらく悩んでいた。これは、思ったよりも間に落ちたボールを拾うことが求められており、それをやって価値を出すことが思った以上に重要なんだけど、レジュメではキラキラした成果を求められるからである。

（キラキラした成果＝とかね）

自分の立ち位置はずっと、「顧客に価値のある製品を届けるために何でもやる」である。その何でもの幅は人によって違うのだと思う。なので、取っ掛かりとしてでおなじみのWill Larsonのと比べることで紐解いていこう。

4つのStaff Archetypes

Will Larsonの4つのStaff Archetypeをおさらいとしてまとめてみる（Gemini 3 Thinking modeでブログ記事から要約）。

1. Tech Lead

特定のチーム（あるいは数つのチーム）に深く関わり、技術的な方向性と実行をリードする役割。

特徴: チームの技術的な意思決定に責任を持ち、複雑なタスクの具体化やブロックの解消を行う。
主な活動: 実装よりも、チーム全体の技術的なビジョン策定やメンバーの育成、プロダクトマネージャーとの調整に比重を置く。最も一般的で、シニアエンジニアからの延長線上でなりやすい形態である。

2. Architect

特定の技術ドメイン（API設計、フロントエンド、インフラ戦略など）において、組織横断的な成功と品質に責任を持つ役割。

特徴: 複数のチームにまたがる技術戦略を立案し、長期的な技術的整合性を保つ。
主な活動: ビジネスニーズと技術制約を深く理解し、組織全体のアーキテクチャを導く。大規模な組織や、負債が蓄積した複雑なシステムを持つ企業で必要とされる。

3. Solver

組織にとって重要かつ困難な技術課題を解決するために、特定のチームに留まらず動く「火消し」のような役割。

特徴: 実行リスクが高い問題や、解決策が見えない複雑な課題に投入される。
主な活動: リーダーシップ層からの要請に基づき、問題が発生している現場へ赴き、解決次第次の課題へと移る。組織レベルの調整よりも、純粋な技術的突破力が求められる。

4. Right Hand

CTOやVPといった経営幹部の「右腕」として、その権限を借りて組織の複雑な問題を解決する役割。

特徴: 技術だけでなく、ビジネス、人、プロセスが交差する領域で、経営陣の意図を組織に浸透させる。
主な活動: 幹部の会議に出席し、組織的なボトルネックの解消や戦略の実行を支援する。エンジニアが数百人規模になるような巨大組織で見られる稀な形態である。

とはいえ、Will Larsonはこうも言っている（より引用。naniで翻訳）。

この分類は網羅性よりも実用性を重視していますが、これまでのところ、話を聞いたスタッフプラスエンジニアは全員、このいずれかのカテゴリに当てはめることができました。もちろん、分類しやすい人もいれば、そうでない人もいますが。

どうにも自分は「そうでもない人」なのではないかと思ってこの記事を書き始めた。

自分の仕事をArchetypeで分解する

自分が今の職場でPrincipal Software Engineer、あるいはTech Leadとしてどのような立ち位置にいたかを簡単に説明しよう。

Tech Leadという正式なタイトルはなく、会社のMLプロダクト開発をエンジニアリング的に全部を引っ張っていくエンジニアの総責任者的な立場として動いていた。組織構造としては、1年ほど前にCTO兼VPoEによって整理がなされ、複数のエンジニアリングチームを統括するSr Engineering Director直下のレポートラインとして、Principalである自分とMLチームのEngineering Managerがピアとして存在する形になった。いわゆるTwo-in-a-boxなどと呼ばれるスタイルである。

ここ3年くらいでやってきた主なことをArchetypeで分解してみよう。

【Tech Lead / Architectとして】
- ML学習・予測基盤（Python, FastAPI, AWS Batch）のグランドデザイン設計からPoC、スケール検証、リリースまで一貫して主導し、2人で5ヶ月でリリースした
- RFMの予測処理をスケーラブルにして最大100倍高速化し10億ユーザーの処理をサポートした
- 推薦のMLソリューションのモデルのPoC実装をし、スケーラブルなアルゴリズム選定を行った
【Right Handとして】
- CTOやプロダクトリーダーシップに直接エンジニアリングロードマップを説明し、スポンサーを獲得しにいった
  - 1年かけてML基盤刷新のスポンサーシップを獲得し、リリースまでこぎつけた
- プロダクトロードマップのドラフトも作成し、EngだけでなくProduct ManagerやVPoPへのプロダクトの方向性を提案した
【Solverとして】
- PSチームから「お客さんにこの機能が今すぐ必要」とエスカレーションが来た際、遊撃隊として飛び込み、1〜2週間で本番リリースして火消しを行った
- 実装していたメンバーが急遽いなくなったプロジェクトの未完のコードを、プロダクショングレードになるように書き直した

書いてて気づいたのだが、これ以外にも以下のようなことに気をつけていた。

メンバーのモチベーションを考慮したタスクアサインとキャリアを見据えたプロジェクト計画（例：adminコンソール作りなど退屈な作業は自分が巻き取り、チャレンジングなタスクをメンバーに渡す）
UXデザイナーにデータモデルの複雑さを伝えるためのドラフトUIデザイン案の作成
JDの抜本的な書き直しと面接のgatekeeper
EMへの1:1での間接的な評価インプット

ようするに、やっていたことは（英語圏だと）なんだけど、注力するところとしてはプロジェクトが失敗しないように＆成功するように必要な隙間に落ちたボールは重要度に応じて全力で拾いに行っていた。それにより、自分の職責ってなんだっけな、などと迷うことも多かったが、世のStaff Engineer本を読んでいると多かれ少なかれ皆やっていることだと思い、歯を食いしばってアンブロックしていた。

なぜStaff+のスコープは広がるのか

一般的には、Two-in-a-boxの形態は役割分担の幅はあれどよく知られている。例えば、で Charity MajorsはEMとTLの共同について記している（naniで翻訳）。

技術系エンジニアのリーダーは、需要が供給をはるかに上回るほど圧倒的に不足しています。最も一般的な解決策は、かつてエンジニアだったものの実務からは長く離れており、今はピープルマネージャーとして概念や専門用語を理解している人材と、現役のテックリードを組ませて、協同でチームを率いさせることです。この少しばかり扱いにくいやり方ですが、多くの場合、かなりうまくいっています。

また、では全チームにEMがいて、多くのプロジェクトではTLを別途置きEMと協業する、あるいはTLがいない場合はTech Lead Managerとして両方を兼務する。

彼らの場合は、EMとTLの役割分担は以下の通りである（naniで翻訳）

エンジニアリングマネージャーは、主にピープルマネジメント（人員配置、コーチング、成長支援）と組織戦略（組織のリスク、業務効率、チーム憲章、成果）に注力します。

テクニカルリードは、主にテクニカルリーダーシップ（技術的な実行、技術戦略、技術文化、ロードマップの実現可能性と実行）に注力します。

このようにして、様々な領域に注意を払えるように認知負荷を分担していくのがTwo-in-a-boxのメリットである。

だが、MLのような技術的に深い知識を求められるドメインでは、EMとTLの技術的な深さにギャップがある場合、どうしても精度の高い技術的意思決定ができなくなりがちである。その結果、「分担」から広い範囲でTLへの「委譲」になっていき、TL側のスコープは広がってしまう。例えば僕の場合は、タスクアサインやリソース配分までTLとして決定しており、AsanaのEMの役割のいくらかを委譲されていた。

自分の場合は、Two-in-a-boxの体制は思った以上にうまく行ったと感じており、特にお互いの棲み分けがきっちりでき領分が決まってしまった後は、互いに自走するだけであった。基本路線としてPeople ManagementはEM、Technical LeadershipはTLといったように分担すること、共通のSr Engineering Directorにピアとしてレポートすることで、TL側のスコープの広がり自体は組織的には受け入れられる体制になっていた。この体制になる前は、結構お互いの仕事を奪い合うような形の衝突がちょこちょこ起きていたため、組織構造をうまく作るというのは大事なのだと実感した。

結局のところ、EMとTLがお互い信頼しあい、自律的に仕事を進められる体制になっていれば、多少ボーダーがどちらに寄っているかは些細な問題である。

自分のキャリアとしての振り返り、あるいは高機能雑用の再定義

ここまで色々と文章を書いてきたが、自分のやってきた仕事や広げてきたスコープを改めてArchetypeを元に整理すると

Tech Lead/Architectとしての技術的意思決定とデリバリー
Right Handとしてのエグゼクティブへの技術戦略の提案と承認獲得
Solverとしてのクリティカルな問題解決力
- ときにはStaff+以上の範囲（PdM, PjM, UXデザイナー, EMの一部）でもやるときはやる

となる。

Staff+としての高機能雑用業は、ただの雑用ではなく、「組織に必要な複数のStaff+機能を一人で担っている」と言えるのである。

Will Larsonもちょっとびっくりするかもしれない。

でもまあ、こういう動きができる人はスタートアップ色が色濃い企業では重宝されるとは思う。

同じ悩みを持つ人へ

Staff+として働いているときに高機能雑用として何がコアなのかを見失いそうになった場合、まずはArchetypeを振り返ってみて自分が何を成しているのかを言語化してみるのをおすすめする。

AI時代には言語化をすることで深堀りができるようになるため、AIと壁打ちしてでも言語化してみるとよいだろう。自分自身もshiumachiさんにAIと対話して内省すると、より自分への理解が深まり伸ばす方向が見つかる、という旨のことを教えてもらいやってみているが、（半端な仕事より）集中が求められるため疲れはするが得るものも大きい。

後は、自分自身が正気を保つためには、スタッフエンジニアに関する書籍の事例がとても心の支えになった。もどちらも手元においておくとよいだろう。自分がつらい経験をした後に読むと、スルメのように味わい深い読書体験ができる。

高機能雑用は、Staff+として活躍していることの表れなのかもしれない。ただし、やるべきことのビジネスインパクトは考えて優先順位付けをすることは忘れないでほしい。

「ちょっとしたことでうまくいく発達障害の人が上手に働くための本」を読んだ

Mon, 22 Dec 2025 18:09:00 -0800

家族に勧められて冬休みの課題図書よろしくこの本を読んだが、色々と良かった。

この本は、ADD・ADHD・ASD・LDなどの特性を持った当事者が、どのような特徴的な振る舞いをするのか、それらに対してどのようなワークアラウンドがあるのかを書いた本である。診断されたわけではないが、家族にこういった特性があるというメンバーがいることもあり読んだ。シリーズとしていくつか本が出ているが、この本は働く上でのよくある話とそれの対処法を書いたものになる。

本書を読んで一番学びが大きかったのが、「時間感覚が乏しい」「強い興味が出ることしかモチベーションがわかなくてできない」という点である。

前者は、ADHDの傾向として、追い詰められて締め切り直前にわーっとやってしまうというパターンが多い。これは、時間の感覚が薄く、計画を立てるのが非常に苦手、ということから現れる。なので、先延ばしにしてしまいがちである。のようなカウントダウン式の予定管理アプリを活用したり、締め切りを公言するのが良いという話だった。また、細かいゴールにタスクを分割するという方法も提示されていた。これに関連して、ASDは優先度の判断が苦手、という話も書かれていた。何が最優先なのかは文脈とともに判断されるため、重要性と緊急性とを書き出した判断しようという話があった。

ADHD傾向が強いと後者は興味がないタスクは完遂できないという振る舞いに現れる。複数のタスクを用意しておいて、飽きたら違うことをやるなどをして対処をするのが良いと書かれていた。

このように、具体的なあるあるとそれに対してどのように対処するのかを、アプリやソフトウェアの力も借りつつ具体的なワークアラウンドが提案されているため、当事者の人もそうだがボーダーの人が読んでも「こういう振る舞い自分もちょいちょいするけど、こういう対処ができるのか」という学びがある。

こうしたスペシャルニーズが必要な人に対しては、そうでない人に対して言われている一般的な方法（タスク管理はこうしろ、など）は曖昧性が高く通じないことが多いため、当事者の人の具体的な工夫を知ることで、引き出しを増やせるおくのはとても良かった。

2025年を振り返って

Sat, 20 Dec 2025 21:30:00 -0800

2025年は記憶が薄いので完全に忘れる前に記録しておこうと思う。

プライベート

今年は引っ越しをしたのでめっちゃバタバタした。それに伴いDIYで家の修繕をしまくった。家の3割くらいの壁を塗りなおしたり、家じゅうの天井のライトを交換しまくったり。後残りの修繕個所は、と呼ばれるセントラルヒーティングの暖房の交換と乾燥機の排気管の交換、洗面所のボウルと天板の交換くらいか。まだまだ道は長い。

夏休みにはオタワにも行った。オタワはケベック州と川向なので、フランスの文化の色が濃い。パンやケーキに対する執念が違うため、どこのお店のケーキも程よい甘さでおいしかった。やはり、激アマケーキはアメリカの文化なんだなあというのを再認識した。

オタワに行ったついでに、オオカミがガラス張りのリビングから見えるParc Omegaにも行った。夜通し遠吠えが聞こえるなど、動物好きの人にはたまらない環境だろう。ハイシーズンはめっちゃ高いけど、一泊だけするのでも楽しいと思う。朝ごはんもつけるとケベックのおいしいパンなどが楽しめるのでお勧め。

今年は完全にスノーボードに転向をして黙々と練習をしている。まだまだ初心者コースもまともに滑れないけど、来年こそは中級コースが滑れるようになりたい。

仕事

ここ2年くらいは、Tech Leadとして機械学習のプロダクトを作るためのロードマップ策定からチーム作り、果てはCTOなどのエグゼクティブへのスポンサー継続のための活動などずっと続けている。

ようやく今年は新しいML基盤を本番投入できたし、幾つかのMLソリューションを顧客提供ができた。とはいっても自分はメインでコードを書くことは基本的にはしておらず、チームメンバーに委譲をするというのをこの1年半弱は辛抱強くやっている。チームビルディングも仕事のうちの一つと思って、モチベーションの維持ができるタスクのアサインや、心理的なブロッカーを取り除いたりなんかもやっている。

ML仕事をしているのに全社トップダウンでスクラムが導入されることになったので、した。未だに全くうまくいってないので、皆がどうやっているのかが気になっている。

年の途中でエンジニアリングディレクターが代わったりして大変だったけど、今はなんとかやっている。あと少しでメンバーが一通り揃ってやりたいことができるようになるのだが…。

Agentic coding全盛なため、ミーティングやランダムな割り込みだらけだったところでもコードが生成できるようになったのは大きな変化だったが、たり、といろいろ歯を食いしばった一年でもあった。

OSS活動

今年は仕事で使っているOSSのPRを二個作ったのと、必要に迫られてforkしてCUDA 12.x対応したりしていた。

uvxが便利そうなので小物社内ツールを公開したりもした。

RのパッケージのリリースもLLMの助けを借りてできるようになったのは良かった

買ってよかったもの

温度設定ができる電気ケトル。保温機能付き。こちらで使っていた安いケトルとは比べ物にならないくらい速くお湯も沸くし、温度設定ができるのは日本のポット以来なので助かる。難点はカナダで買うと温度がファーレンハイトで書かれていること。しかし、日本の商品は60, 70, 80, 90, 100と書いてあって、そうだよね、、、という気持ちになる。

引っ越してから6時間以上停電することが2回、3時間程度停電することもちらほらあって、今年は外れ年だなと思いながらUPSを買い足したのだが、無線ルーターとプロバイダのモデムが2時間持ったのはとても助かった。ついでにAnkerの大きいバッテリーも買ってUSB PDから5V2Aのケーブルに変換できるやつも買ったので、次回はトータル8時間くらいはインターネットができそう。

来年に向けて

今年は、アニメを見たりB’zのライブ動画を無限に見て正気を保とうとしていた。ゲームをやる気力がわかないので、もうすこし運動を増やして体力を増やしていきたい。

AI時代のPrincipal Engineer

Tue, 09 Dec 2025 22:30:00 -0800

AmazonのPrincipal Applied ScientistのEugene Yanさんの記事に触発されたので書いてみる。

AI時代にPrincipal EngineerがAIとどう向き合い、どう生き残るかを書こうと思う。

なお、上記の記事にもある通り “1. Different principals will have different flavors.” なので、Principalと一言で言っても企業・チームによって千差万別であることに注意していただきたい。

1. AIは “frenemy”

2025年のソフトウェアエンジニアリングにおいて、AIの存在を無視することは難しくなってきている。特にコード生成においては、AIを使わないでコードを書くことが企業で働くうえで許されなくなりつつあるように感じている。企業によっては、AI生成されたコードの行数や使用token数をKPIとしてトラックしているという話も聞く。また、AI Native企業になろうと各社躍起である。

コードを自分で書いていく上で生成AIを使ったagentic codingは非常に助けになる。結構まとまった量のコードが生成されるので、生成しては捨て、という試行錯誤が速くなる、という話もある。また、隙間時間を使ったコーディングがしやすくなったので、ミーティングの合間にコードを生成する、なんてことも前より格段にしやすくなった。

ただしこれは、ICとして実装することだけに集中するならば、という前書きがつく。「何か」を生成するスピードは速いのだ。

なんだけど、過去にでも書いたように、コードレビューが業務の大きな割合を占めるであろうPrincipalにとっては、自分の背中を打ち抜く何かに代わる。自分ひとりだったり、似たような技術レベルの集団においてagentic codingはかなり有利に働くだろう。が、それはコードをちゃんと読めてレビューができてというのを暗黙のうちに仮定していることになる。このレベル感やコードの質に関する期待値がメンバー間ずれると、 “it works” と “but it’s broken"の間でのせめぎあいが発生する。

言い換えると、AIを使う人間の特性が増幅される傾向にあると言ってもよいかもしれない。人間が手で書いていたころは、およそ同じ方向を向いていたように感じていても、AIが人の営みを加速させずれを増幅させると、コントロールしてすり合わせるのがかなり難しくなる。

そういう意味では、AIは friend でもあるし enemy となりえるのである。

2. 必要なのは英語力、コミュ力。次に技術力とキャッチアップできる力

英語力と言っているのは、筆者がカナダに住みアメリカ企業で働いているからであるが、言語化能力と言い換えてもいいかもしれない。

コードを書く作業がagentに委譲されると、次第に業務の割合として増えてくるのが、部署間調整だったりメンバーのモチベーションマネジメントだったりといったソフトスキル側になってくる。日々誰かを説得し、何をするべきか、これはやるべきことなのかを言語で表現し、ありとあらゆることをunblockするのが仕事になる。

例えば、一緒に働いているプロダクトマネージャーに色々と決めてもらいたい、そうしたときに技術的なお膳立てをする必要があるだろう。あるいは、コードレビューをしていて設計的な問題を指摘したときに、自転車小屋の議論かと相手がやる気を失ってるのが伝わってくることもあるだろう。

そうしたときに、テキストコミュニケーションならば、AIに英語の下書きをしてよい表現に改善してもらうということはできる。

だが、生成された英語のレビューが迅速に自分でできないと、間違いや怪しい表現などに気づくことができないのである。人間がボトルネックになってしまう。素早く行動に移すためにも、英語力を上げより意図した表現をすぐに出せるようになる必要がある。そして、口頭での会話ではAIなんかに聞いてる暇なんてない。

コミュニケーション能力の重要性も上がっている。メンバーが非常にフラストレーションを感じているような反応があったときに、なぜそのような反応になったのかを考え想像することが、モチベーションを管理する上でも非常に重要である。例えば、おなかが痛いのかもしれないし、あるいは家族とけんかをしたのかもしれない。あるいは、子供が学校でトラブルに巻き込まれて、担任をすっとばして校長果ては教育委員会にエスカレーションをしているのかもしれない。

なぜ、このようなことを言っているのか、その真の理由は何なのか。そう、「筆者気持ちを答えなさい」問題である。これを考える作業はPrincipalになって格段に増えたし、その検討をAIを使ってサポートしてもらうことはできても、結局人間の機微は自分で考えないといけないのである。

何度となく、AIの遺電子の「」のようにAIがコミュニケーションの文面を全部代わりに作ってくれるようになればいいのに、と思ったことか。

なお、Principal Engineerになっているのであれば、技術力的には何かしらの専門領域に一家言ある人だと思うので、AIを取り入れて新しいことをキャッチアップし続ける力さえあれば大丈夫だと思う。無論、AIのいうことだけを真に受けていてはハルシネーションの海に溺れてしまうので、論文や書籍、オープンソースのコードを読んだり書いたりするという素振りはとても大事である。

キャッチアップに対するスピード感は以前よりも求められる速度がぐっと上がっている。

3. AIを自分で使い倒し、AI slop detectorを身に着ける

おそらくChatGPTやGeminiなどを使って質問したり議論をするということは、日常的にやっていることだと思う。それに加えて、Claude Codeなどのcoding agentを使ったコード生成もやって日々の業務のコードを書いたり、スクリプトを作ったりなどもしているだろう。

AIを使い倒して業務活用するのは、今後の生き残りのためにもどんどんした方がいい。そして使い倒しておくと、AIが生成したを見分ける嗅覚が備わってくる。ここが非常に重要で、ドキュメントやスライド、コードもレビューするときにこの嗅覚があると「あ、これは真面目に読まなくていいな」など早期にフィードバックをすることができる。

人間の時間は有限であり、ノーレビューでAI生成物を渡されたら突き返すべきである。

4. Principalは孤独、AIは良い壁打ち相手。でも気をつけろ

アメリカ企業ではネガティブフィードバックや改善の提案をするときにお作法がある。最初の9割誉めて最後の1文2文で重要な改善事項を提示する、といった具合だ。あるいは、英語として主語を無生物主語にして遠回しに言う、みたいなやり方もある。

英語が第一言語ではない筆者にとってこのお作法は、非常にしんどい。文化の違いも大きいし、シュガーコーティングしすぎると相手に伝わらないこともまあまあある。

そこで活躍するのがGeminiなんかのAIだ。Gemini 3 Proなんかだと、かなりコーチングめいた事も言ってくれ、こういう流れで整理をした方がいいと提案してくれるし、何なら「うまくいきますように」なんてお祈りまでしてくれる。

でもね、今のLLMはしょせんなので、人間の都合の良い出力ばかり出しがちなのを忘れてはいけない。どこまで行っても、十分なコンテキストをLLMに渡すことは困難なわけで、再利用できる「前回までのあらすじ」みたいなのを用意して工夫はしているけど、会話を重ねると過去のコンテキストを忘却してしまうものである。

あと、人間にすっと歩み寄った物言いを言われ続けていると、解消しないといけない衝突が発生したときにLLMが一緒になって「相手が悪いです！その理由を徹底解説します！」なんて言ってくる。

LLMがいうことは、ある種のフィルターバブルみたいなものである、そのバイアスを補正するのは人間なのである、という強い覚悟が必要である。

5. AIは996に追い込もうとしてくる

coding agentのおかげでコードを書き始めるまでの静止摩擦係数が激減した。これはミーティングなどで忙しいPrincipalにはありがたい側面ではある。このおかげで何が起こるかと言うと、ちょっと晩御飯を食べる前にプロンプトでコードを生成開始する。すると、ご飯を食べてる時にも結果が気になってソワソワし始めて、見に行ってしまう。通知が出ている。次の指示を出す。

別の同僚は、飲み会に移動する前のエレベータ待ちの時にプロンプトで指示を出していた。

コードを書き始める静止摩擦係数がほぼ0になったおかげで、AIが深夜まで残業をするのを誘発するのである。

Werner Vogelsが言うように、(レビューのない) 、ある種の依存性があるのだ。

Staff+と呼ばれるラダーになってくると、皆が皆やっていることがちょっとずつ違うため道を見失いがちである。他の人の本やブログなどの言葉を読むことで、自分が正気を保てて来たところはあるので、この文章が誰かの助けになればうれしい。

もちろん、何か他にいい話があれば何かしらの方法で教えてほしい。

Principal Engineerが読む「スタッフエンジニアの道」

Tue, 25 Nov 2025 22:32:00 -0800

オライリーから出ている「スタッフエンジニアの道」をを通じてご恵贈いただき、第1部と3部を読み終えてしずかなインターネットに書評を書いたのがおよそ一年前、そこからさらに1年かけて第2部を読み終えたので感想である。1年前に読んだ文は最後の方に貼っておく。

私は、Principal Engineerとしてコードを書くハンズオンだけではない数々の仕事をこなしてきている。自分はMLを使った製品開発のTech Leadとして、チームメンバーを育てながらロードマップを切り開き、またリーダーシップからのプロジェクトの投資を継続してもらうようにスポンサーになってもらう活動を続けてきている。

この本では、先達たちの「こうしてきた」エピソードや実例、どのような考え方をもとに動くべきかといった試行錯誤を書き連ねた本だ。どのように考えて自分にとってそして会社にとっても重要なプロジェクトを選び、スポンサーを獲得し、メンバーが助けを求めていれば西へ東へ奔走し、求めていなくても助けに行き、プロジェクトが進むためにあらゆることをする、そういったStaff+と呼ばれるエンジニアに向けての、実例集である。

なので、体系立てようとしても厳しい。なんだけど、ふた昔前のEngineering Managerが何をするのかわからん状態のように、Staff+ Engineerが何を期待されているのかわからん問題というのがあるので仕方がない。これは、会社やそのステージによって、Staff+に求められる役割が全然違うのである。本書を読んでいると、「Staff+はコードは書いてもいいがクリティカルパスはお前がやるな」と書いてある。ちゃんとほかの人に委譲できる体制を作らないといけないのである。

この本の見どころは、第2部がプロジェクトをどう進めるか、そして進まないときはどうするか、みたいなことが書いてある。これが良いのである。ただし、胃が痛くなるので心が健康なときしか読めない。なので、読み進めるのに1年かかった。

また、チームメンバーやProduct Leadershipが総入れ替えみたいな出来事が数回ほど起きる中でのチームメンバーの育成はなかなかヒリヒリする仕事であった。そんな時にもこの本は役に立つ。どうやって、チームメンバーに適切な仕事を与えたりモチベーションアップをしたりするのか、そういうことも書いてある。

高機能雑用になりがちなStaff+が、心のよりどころとして使える本である。プロダクトマネージャーが「どうしてあなたは一人月分コードを書かないのですか？」と聞いてきたときに、ちゃんと反論できるようになるわけである。「オライリーの本にも書いてあったけどね、誰かが戦略的な意思決定を進めていかないといけないんです。で、コードも片手間に書いているけど、私がブロッカーになってはいけない、そういうことも書いてあるんです。」天下のオライリー印を使うのだ。

私は社内のPrincipalの中でも、比較的戦略的・政治的な振る舞いが求められることが多く、今はSr Engineering Directorの助けを借りたり、外部からの玉を打ち返せるような支援をするみたいなことをしている。 ¹ そういう時に、自分と同じようなことをしている人が少ないこともあり、どうしても孤独になりがちでGeminiと無限に壁打ちをするみたいなことが発生する。しかし、書籍は（ある程度盛っているかもしれないが）生きた人の爪痕であり、大変に支えになるのである。

そんな迷えるソフトウェア業界のStaff+ Engineerにお勧めの書籍である。

最後に、過去にしずかなインターネットに書いた書評を貼っておく。興味がある方は読んでみてほしい。

終わり

からご恵贈いただいて、前々から積んでいた「スタッフエンジニアの道」を冬休みの課題図書よろしく読み進めている。

本当は、きちんと読み終わってから感想を自分のブログにでも書こうと思っていたのだが、読んでいるうちに色々と思うところが増えてきたので、dumpしておこうと思う。

この本は、いわゆる"Staff+ Engineer"と呼ばれるIndividual Contributor (IC) の上級職にまつわる話である。順番は色々あれど、Junior, Intermediate, Seniorの上に来るものという位置づけであると本には書いてある。

なお、Staff+がSeniorより「偉い」というわけではないのは、以下の本書の脚注で書かれている筆者の好きなSeniorの定義からもわかる。

「昇進するのを止め、現在の生産性、能力、アウトプットのレベルをキャリアの残りの期間継続しても後悔のないレベル」

ただ、Staff+と呼ばれるこのポジションに関する書籍がいろいろと出てきているのは理由がある。この本をいただくきっかけになったriywoさん、とのご飯のきっかけにもなったのだが、Staff Engineer以降になると会社によっても何をやってるかばらばらになるし、道を見失いがちになるのである。

かくいう自分も、春(注: 執筆当初2024年)にPrincipal Software Engineerにpromotionしてからというものの、やっていることは変わらないと思いきや、プレッシャーは増えて責任範囲も順調に拡大してきて、道を迷いそうになりながらも踏みとどまっているのが現状である。

Staff+が何をするのかというといろいろと書いてあるのだが、「大局的な思考を持ち、大きなプロジェクトを実行し、よい影響を与えるようなことをする」というのがざっくり良いまとめであると感じる。そのため、

戦略を立てたり、プロジェクトを立て直したり、標準を設定したりしている時間には、コーディングや新しいシステムのアーキテクチャを設計したりといった、ソフトウェアエンジニアとして評価されるような多くの仕事はできません。

という事実にも直面する。自分の与えられる影響を大きくするには、コードを書くことも大事だが、そうではない取り組みも大きい。これは、ステークホルダーが多かったり、重要度の高く困難なプロジェクトを割り当てられるのも大きい。

そう、結局は重要な技術的課題を解決するためになんでもやるのだ。こういうと、「」のある種正統進化だなあともさえ思えてくる。

当然、コミュニケーション力とやらも求められる。ラダーの上の方のエンジニアの機会費用は高いから、ちゃんとVPなどのサポートを得て(得続けて)、やるべきことをやりましょう、という話である。

これはある種の社内政治だなあ、うーんと思っていると、見透かされたように言われる。

エンジニアは時々、組織に関するスキルを「政治的なもの」として軽視することがあります。しかし、システムの一部である人間を考慮し、解決べき問題を明確に理解し、長期的な結果を把握し、優先事項についてトレードオフを行うといったスキルは、優れたエンジニアリングの一部です。自分の組織をどのようにうごかすかをわかっていなければ、あらゆる変革がはるかに困難になります。

そう、ゲームのルールが変わってきているのを直視しないといけないのである。今まではランダムエンカウントのターン制RPGをやっていたと思ったら、リアルタイム性が高くなってきた戦略シミュレーションになっていたのだ。それを示唆するように、本書でも霧のある戦争マップの中でマッピングせよ、みたいな話が出てくる。あー、FEの索敵マップね。社内の色々な関係者のマップ書いたり、プロジェクトのゴールに辿り着くまでのマップ書いたり、それを更新し続けたり。

これらは、ある意味では(大企業で大嫌いだった)社内政治とどう向き合うかという話に他ならない(そしてそれは！)。結局は、ビジネスの営みはステークホルダーが色々といて、重要度が上がれば(予算がつくつかないは別にして)出てくる口の数は増える。そういう中では、今いるチームのアーキテクトとマネージャーとで週次である種の「現状認識会」をできていたのは、よかったのかもしれない。この間辞めたCXOのプロジェクトへの影響は、隣のプロジェクトにPdMのリソース持ってかれてる、などなど本書で言うところの、トポグラフィーマップを更新し続けていたのだ。

ある種の社内政治は、日本、アメリカ、エンプラ、スタートアップを問わず、どこでも発生しうる、というのは過去の経験でも感じていたし、Will Larsonの本でも言及されていた。

これ以外にも、技術ビジョンや戦略の立て方の話、他のメンバーのロールモデルになる話、どうやってリーダーシップを発揮するのか、みたいな話が本書には書かれており、自分の通ってきた道と過去の失敗の反省をしながら読んでいる。しかし、自著の「」もそう感じていたが、痛い目を見てはじめてわかる書籍に書かれた事の重みというのはあるのだなあ、と痛感する。

また、自分が直接の部下ではないが、MLチームの技術リードをすることになった関係で、色々ともがいた年でもあった。いかにチームを回るようにして、タスクブレイクダウンをし、そして来クオーターの計画を立てるのか。ある種のTLM的な感じでICのモチベーションを最大化するのに心を砕いたり、色々とはじめての挑戦も多く、正直に言って今までの経験があまり生きない一年だった。

そんな中本書を読むと、シニアに対するメンタリングで何ページも書かれていたのは、不要なアドバイスをしてはいけない、何を求められているかを解きほぐすのに労力を割くべきだし、アドバイスをしたくなったら(センシティブな情報は抜きにして)ブログやsocial mediaに書くのがいいだろう、と書かれている。耳が痛いなと思いながら、この文章をdumpしたのであった。

そう、どうやったらCTOに投資を継続してもらえるかとか、なぜMLが会社にとって重要なのかを何度も何度も説明する仕事である ↩︎

最近の人類のレビュー疲れ

Fri, 19 Sep 2025 21:26:00 -0700

今年に入ってやたらレビューの時間が増えた。これはコードもそうだしドキュメントもそうだ。そして、これによる疲れも急激に増加している。

もちろんこれは、LLMによる支援によってアウトプットの速度と量が増加したからだ。そして、必ずしも質が向上しているわけではなく、むしろ下がっているように感じる。当然、自分の生産性も下がっている。

自分の頭をダンプし、どういう課題があるか、そして、どう向き合っているかを書いていこうと思う。

他人を経由したプロンプティング

私は、機械学習のプロジェクトのテックリードとしてしばらく働いている。その仕事として、などの技術文章を書くことも多いが、レビューする機会も多い。

機械学習で難しいのが、プロジェクトが変わり解く課題がちょっと変わると、がらりと全然違う知識が必要になり、新規に論文を読む必要が出てくる。

今までずっとRailsでwebアプリケーションを作っていた人が、ある日突然「Rubyだから同じでしょ」とRubyのパーサージェネレーターの仕様のドキュメントをすっと渡され、すべて生成AIで生成されているのはなんか見てわかるがどうそれをレビューするか、真っ当な仕様になるよう意見するかという問題を想像してみてほしい。きっと、おもむろに他言語の実装を読むなり論文を読むなりして脳内にインデックスを作ったうえで、レビューをすることになるだろう。

そういう世界観でレビューをする仕様というのは、本当にしんどく、こちらが生成側より知識がある状況に持って行くまで一苦労、そして適切なコメントを繰り広げると待っているのが、すべて生成AIで作られたコメントで反論され、また修正もドラスティックに今までのコンテキスト無視で大規模に上書きされるのである。

こうした状況を、私は「他人を経由したプロンプティング」と表現しているのだが、はっきり言って自分が論文読みながらLLMと議論したほうが手っ取り早いことがほとんどである。

「LLMが生成した文章は、LLMにレビューさせればいいじゃない」と思う読者もいるかも知れないが、これは難しい問題をはらんでいる。じゃあ、そのLLMによるレビューの正しさを誰が担保するのか？という問題である。自分でLLMと対話をしても常々感じるのが、「」であるということである。出てくる出力は一貫性がなく、同じ質問を3回繰り返すと3回違うことを結構言ってくる。どうするかというと、その傍らで論文や既存実装、ドキュメントを調べて、どれが尤もらしいかを自分で選ぶ必要がある。

今のLLM・生成AIは人間の能力の限界がすべてを規定すると信じているのだが、proxyたる間に入った人はproxyを貫く限りは必要がなくなるので、適切にマネージャーにエスカレーションをする必要がある。

なお余談だが、LLMで生成した文章は、特定の単語が高頻度で出てくる、などで検出されることも多いが、英語が第一言語ではない民にとっては第一言語特有のクセの有無で見抜かれる、ということもままあるので、きちんと生成された結果には自身を持って自分の意見として他人に渡すようにしよう。

自己レビューの欠如、あるいは目が滑る問題

前節でも書いたが、生成したものを自己レビューをしないというケースは往々にしてある。これはただただ不信感を増やすので今すぐやめたほうがいい。しかし、自己レビューをしても目が滑ってしまうというケースも多いのが実情である。

マネージャーとの1:1で教えてもらったが、同一人物であっても自分が生成させたコードのレビューは甘くなり、他人の生成したコードのレビューは厳しくなる傾向があるらしい。わかる。

なぜこれが起こるかと考えたときに、自分の手で書かないコードは往々にして自分の脳内キャッシュに乗らないのである。それに、Claude Codeでコードを生成させていると、diffをいちいち見るのはかったるくなるようなUXになっている。なので、auto approvalモードで一通り動くものを生成させて、それをレビューすることになる。が、まあ、大量に変更されたときには細かいところの理解は追いつかない。そして、なんかunit test通ってるからOK、となりがちなのである。

クソデカコミット

最近、ほとんど1コミットで +10,000 -7,000 みたいなPRを受け取った。ビッグバンコミットPRである。

LLM、特にAuto approvalモードでコードを生成すると、agentが試行錯誤を大量にする。そして、agentic codingの特徴として、大きな塊をガンガン上書きする。同一人物が手で書いていたときにはリスペクトしていた既存の設計は、LLMが生成したPRではかなり無視されていた。

、という研究がある。大きい複雑な変更をするのは、を読んだが、まあそうだよねという気持ちになった。

あとは、タスクを適切な単位に切り出すのはLLMは勝手にはやってくれない。こちらで丁寧に指示しないとなかなか難しいと感じている。

なお、機械学習のような探索的な実装のときに、適切な粒度のコミットをするのはすごい難しいというのは普遍的な問題であるのは、オープンクエスチョンのままだ。

生成側とレビュー側のインセンティブ構造の違い

「LLMを使うとコーディングの生産性があがった！」ということを主張したい人は多く、多くの人々がAIによる生産性改善を強く信じており、それができないといけないというハイプが来ているからだと理解している。

で、コードを生成するスループットについては、様々な議論があるのは認識しているが、上る可能性はあると思う。なんだけど、レビューする側は特に速くなることはまだない。全部LLMにレビューを任せるにはもうちょっと（最低一年くらい？）かかるだろう。それに、生成する人がLLM（他人）が生成したコードをレビューするのは今までにはなかったフェーズである。一手多くなるのはコストである。

そうすると、目が滑って自己レビューが甘くなったけど大量に生成されたコードが増えてくる。つまり、生成側は生成スループットを上げることを最大化し、レビュー側はそんなことはお構いなしに質を担保しなければならない。このインセンティブ構造の違いが、レビュー疲れの主原因だろう。

コーディングレビューでの向き合い方

じゃあ、どうしているか。正直銀の弾丸はまだ見つかっていないが、色々と試行錯誤をした結果を共有したい。

1. 生成側がGitHubで他人のコードとしてレビューをする

これは自分も過去に大きめコミット(+700とか)のPRをやらかした反省から、最近は実装時にローカルのVSCodeで毎回LLMが生成したコードをレビューしてapproveするのに加えて、GitHub上でPRをdraft状態でレビューするようにしている。

こうすることで、自分の中でのマインドセットがレビュワーモードに切り替わり、色々とだめな点を見つけることができた。

当たり前に見えるが、レビュー専用のviewを使うというのは、他人のコードレビューと同じメンタルモデルになるのが良いのだろうと思う。

2. ドキュメントドリブンで開発をする

で、いくつか参考になる取り組みがなされていたので、それを自分も試してみた。

私がこの記事と実際のコミットから学んだ重要なポイントは、以下の3点である。

人間が作業をして30分くらいで実装できるタスク粒度をLLMに必ず与えること（contextがあふれるため）
要件定義→外部設計→作業計画の流れ
さらには上記のドキュメントを一緒にコミットする

非常に重要なポイントとしては、要件定義書、外部設計書、作業計画書、（＋受け入れテスト）をドキュメントとして実装とともにコミットすることで、コミットが多少大きくなっても意図が人間に理解しやすいという点である。また、作業計画をきちんと整理することで、適切な粒度の開発とコミットをLLMの手綱として用意できるのである。これがないと30分程度の

試しに自分も社内ツールとして書いていたスクリプトをOSS化することで、この方式を試してみた。

OSS化するときに社内向けのコードを調整するためにちゃんとしたコミットをお見せすることはできないが、大まかには以下のような流れで作業をした。（GitHub Copilot + Sonnet 4）

まず、やりたいことをAgent modeでSonnet 4と議論して、 , に整理をする。
さらにやるべき実装のTODOリストをPhase毎にチェックボックスでリストを作らせて、として保存する
これらのドキュメント及び開発のお作法、ツールセットなどをに作成させる
Phase毎に実装をして、コミットをする。その際にplan.mdのチェックをしてコミットをしていく。
次のPhaseに移る際にはagentのコンテキストをclearしてAGENTS.mdとplan.mdを読ませて作業をさせる
予定していたPhaseが終わり次のマイルストーンに移るときは、 docs/milestone1 というフォルダを作り、 plan.md を移動、 docs/plan.md は空のファイルにして新規マイルストーンを開発開始する。

OSSとしての実際のPRは以下のような感じである。

正直、コミット粒度は大きくて機能がいくつかまとまってコミットされているが、やろうと思えばチェックボックス一個単位でのコミットもplan.mdを管理しているため容易にできる。

つまり、設計レベルで大きな問題がないかをドキュメントで理解できるのが良い点である。もし、設計がまずっていたら、実装を読まなくてもそこに立ち返って議論ができるので、不毛なレビューも回避しやすいと考えている。

文章レビューでの向き合い方

正直わからん。同僚が言っていた「LLMが生成した文章を盲目的にそのままスルーしてくる人は、みのもんたがワイドショーで言ってたから真実！と言ってくる人と変わらないよね」というのがしっくりくる。

生成文書をproxyしてくる人に対しては、エスカレーションの文言をLLMに作らせて適宜エスカレするのが良いというのが自分の経験上唯一の対策である。日本語で逐一問題となるデータポイントを列挙して、まとめてもらう。元来要約はLLMの得意分野だし、アメリカ企業によってチューニングされたモデル（Gemini）は、アメリカ式フィードバックの方法にチューニングされている。

まとめられない

色々と課題とそれに対して行ってきたことを書いてきたが、正直今も手探りである。しかし、基本的にはLLMの限界はそれを使う人間の限界であるため、その人間の能力をどうすれば最大限に活用できるのか、ということを主眼に人間がワークフローを作っていく必要がまだまだあるだろう。

Pages CMSの設定をした

Sun, 24 Aug 2025 12:09:00 -0700

以前からiPadなどのモバイル端末でHugoの記事を書く方法を模索していたのだけど、そんななかでmehoriさんのこの記事を知ったのでPages CMSを試してみた。

結論から言うと、Hugoのフォルダ構造 (/articlename/index.md) はまじめにサポートしていないのと、それによりなこと、そもそも、iPhoneからことなどあるが、まあとりあえずiPadから日本語で文字だけの記事は設定できたのでよし。

途中、めちゃくちゃマイナーなYAML frontmatterのパースエラーが出たけど、ワークアラウンドも見つけることができた。

コードを読めば何とかなるレベルなのだけど、必要最低限のものはあるのでいいかな。

現状、こんな設定です。

併せて、wowchemyからhugo-bloxに移行をしたけど、そっちもまあまあ大変だった。詳しくは PRを見てもらえれば。しかし、Hugo Academic -> Wowchemy -> Hugo Bloxと名前変わりすぎだろ…。

Amazonアフィリエイトの画像が出なくなっていた問題も画像出さないように修正した

移行した後に検索が動かないことに気づいたんだけど、

pagefindのインデックス作る設定をCloudflare上でbuild commandに追加 -> && npx pagefind --source 'public'
CloudflareのRocket Loader周りの試行錯誤をしたけどにした

というので何とか動き始めた。けど、日本語はまともに検索できなさそう。仕方ない。

久しぶりの夏休み

Fri, 22 Aug 2025 00:49:00 -0700

仕事が珍しく急ぎの仕事がない状態になったので、ふらっと週末にくっつける形で休みを取った。というのも、RTA in Japanをやってるのに全然見れなくて仕事なんてしてる場合じゃない、となったのである。

休みといっても旅行をするわけでもなく、放置していたお下がりのゲーミングPCにWindows 11を入れて子供に渡したり、ついでにというVancouverの会社の電動昇降机がセールしていたので子供に買ったりした。

あとは、妻が壁の色が気に入らないというので、キッチンや風呂の壁にペンキを塗ったりもした。カナダでは人件費が高いことや、そもそも業者が約束の日に来ないなんてこともよくあるので、皆DIYで済ますようになるのである。

ブリュワリーで子供と物理テトリスをしたり、近所の肉屋を開拓してラム肉のシェパーズパイも堪能した。ドーナツ屋さんも甘くなくて最高の店を見つけることができた。

仕事に戻ると寝る働く食べる寝る、というだけになりがちなので、まとまった休みは大事である。

機械学習プロジェクトとスクラム

Fri, 02 May 2025 13:43:50 -0700

機械学習プロジェクトをいくつかこなしてきたが、直感的にはスクラムが機械学習に向いていなさそうというのを思っていた。が、社内で議論をしたときに「Technical Storyを使えばタスクを2週間に収まるように分割できるはず。そして、それをすれば2週間で価値がでるはず」と言われて、ちゃんと反論ができなかったので世の中ではどういう取り組みがあるのかも含めて、言語化するためにこの記事を書いている。

disclaimer

著者はMLの経験は長いが、別にスクラムに詳しいわけではなく、開発メンバーとしていくつかのプロジェクトに参加したことがある程度である。

調査方法

Gemini 2.5 Pro (experimental)とブレスト
Redditを中心に体験談を調査

想定していた課題

MLプロジェクトでは、iterativeな開発が必ず発生する。これは特に途中で探索的なフェーズ（EDAやモデル開発）が必ず挟まり、総じてそれらのフェーズは手戻りが発生する。

こうした手戻りが高確率で発生するのに対して、「2週間で顧客価値を出す」sprintとの相性はすこぶる悪いと思っていた。

Technical Storyを使う

Technical Storyとはなんぞや。色々と調べてみたけれど、この記事の冒頭の例がしっくりくる。

As a developer, I want an automated build So that I can be sure my code works.

実際にこういうstoryをちらほら見かける。

なのだけど、上記の記事ではビジネス価値（business benefit, 顧客価値と同義だと認識している）はどこにあるのか？ということを考えたときに、以下のようなテンプレートに落とし込んでビジネス価値を確保し、またfeatureを埋め込めばよい、という主張である。

In order to will need .

これを経由して、さらにブラッシュアップするとこうなる。

In order to As a I want to <do something, or use or be restricted by some feature>.

In order to stop bots from spamming the site As a member of the commercial team, I want users to fill in a captcha box.

めでたしめでたし。本当に？

MLプロジェクトにおけるビジネス価値

MLプロジェクト、およびMLプロダクトにおけるビジネス価値は、顧客に何かしらの良い影響を与える何かを提供することであることには変わりない。

何か良い精度のモデルが学習できたら、即時顧客価値が提供されるわけではなく、実際の本番環境に予測結果をサービングできるようにして、初めて顧客に価値を届けることができる。あるいは、予測結果をもとにした分析結果をまとめて、アクショナブルな提案をレポートにまとめてプレゼンすることかもしれない。

翻って、こうした顧客価値を数日～2週間のチケットで提供できるか？というと結構難しいと思っている。往々にして、モデルを開発しているタイミングでは、デプロイ先がなかったりすることもある。

一つの方向性としては、Geminiが言うように「リスク削減や不確実性の低減をsprintゴールとする」という発想である。直接的な顧客価値ではないが、ビジネス価値はたしかにある。「この特徴量が予測に効きそうだ」とか「このアルゴリズムはこの問題には不適当だった」などの知見を得られただけでも価値はある。そう考えるのである。

しかし、なぜ2週間にフィットさせるのが難しいのか？こうした疑問にヒントを与えてくれたのが、だった。

タスクレベルの開発フローの違い

では、以下のような図をもとに、典型的なソフトウェア開発と、MLでの開発のタスクの進み方を比較している。

曰く、従来型のソフトウェア開発では、タスクレベルで見れば、タスクの進行が直線的であるのに対し、MLプロジェクトではタスクが循環的であることが多い。（以下の図はともにから引用）

従来型のソフトウェア開発での直線的なタスクは、言い換えるとプロジェクトを完了させればよい「完了型」のタスクだとも言われている。

もちろん、MLプロジェクトでも従来型のソフトウェア開発のような直線的なタスクもある。例えば、データインジェスチョンパイプラインや基本的な前処理、デモ用のでのアプリ開発、予測用のAPI開発などである。

一方で、探索的・実験的なタスクは、データ理解・仮説立案・検証という作業を繰り返す循環型のプロセスである。何が難しいのか。2週間のsprintの中で、予測精度が向上する保証はないので何もコミットができないのである。

MLプロジェクトでのスクラムを実践する方法

ではどうするのか？そうは言ってもトップダウンで2 week sprintが降りてきたから、どのように実践していくかを考える必要がある、という方もいるかもしれない。

Redditでの議論をいくつか眺めていると、以下の2つのアプローチがあった。

1. スクラムをやめてKanbanを使う

いきなり身もふたもない話であるが、agileな開発をするのに何もスクラムをworkflowとして採用するのが必須ではない。

Agile Data Science with Rでもでこういった指摘がされている。

Both methodologies are applied with great success and it’s important to keep in mind that they are a means to an end, not religions. The Agile values and principles should be the primary guideline and when selecting one of the workflows you do so because it is the best way to work in an Agile way because its the best fit for the given situation.

ScrumかKanbanかは信仰ではなく、目的を達成するためにチームが最適なもの選び、それが最適かをモニターするのが大事、という指摘である。

著者の会社では、スクラム経験豊富な人も多かったため当初スクラム採用したが、モデル開発でうまくいかなくなり、結局Kanbanに移行したという話がある( )。

理由としては、スクラムは厳格すぎて探索的・実験的フェーズでは柔軟性が低いことがあげられている。またデータも見ないで性能向上にコミットもできないのは先述した通り。そのため、story pointをつけるよりtime boxingの方ががいいという指摘がある。

Scoping for data science is then not just estimating how long a task will take to complete, it is also time boxing. If used in this way, the scoping should be done in time units, not in a subjective measure such as story points. The data scientist should not take longer for the task than the team agreed upfront, wrapping up even when he does not feel completely finished.

DSは納得いくまで実験をし続ける傾向にあるので、終了条件を厳密に決めるより、時間で区切った方が良いというのは研究フェーズでは合理的である。

実際には、以下のような6つのレーンを持つKanbanを採用したようである。ただし、いくつかのタスクでは仮説検証段階でモデルの精度が上がらないことを確認して終了することもあったそうだ。

to do
test hypothesis
code review hypothesis
update model
code review update model
done

まったく同様の指摘（Kanbanを使え、time boxingをしろ）は。

Don’t confuse agility with solely scrum and its sprints, which are the root of the problem and work poorly in research mode.

この具体例なんかはわかりやすい。

Example: build a PoC in a week. If AUC exceeds X then it’s promising and let’s spend another 3 months on further extensions (data, features, architecture, hyperopt) and putting all into production. If there was no AUC gain on the last week, we do not extend any further. Inside this 3 month time box - execute pure Kanban, task by task, which allows you to take different paths as needed (agility), not waiting till your sprint finishes in 3 days. You already know your new feature is poorly designed and you need to start on tweaking it right now.

つまり、time-boxingをして、その中で仮説検証をしてうまくいったら続きをやる、という意思決定をしていくのである。

また、もう一つのポイントとして、MVPの代わりにMVM (Minimum Viable Model)をさっさと作ること、というのを Agile Data Science with Rの著者は提案している。例えば、最初は線形回帰などのシンプルなモデルを限定したユーザーにMVMとしてデプロイ、次いで特徴量を追加し、最後により複雑なモデル(本文中ではRandom Forestが挙げられていたが今ならNNベースのアプローチもあるだろう)をデプロイする、というような流れである。

これは先のtime-boxingとの話ともつながるが、無数の選択肢の中から確度の高い道を探して枝刈りする取り組みの一つとして、MVMをフックにするのはいいアイデアだと思う。

2. Hypothesis Based Storyを使う（スクラムに手を入れる）

別のでは、スクラムとKanbanを組み合わせるというアプローチがあった。長期的なプロジェクトではスクラムを採用し、リサーチタスクではtime boxingを使用しているというものである。

特に、スクラムに対して以下のような変更をしたようだ。

hypothesis based stories (instead of user based)
foregoe stand ups, people keep their tickets as research logs and @ people when they need help. - Product owner can read the tickets if they want to know where we are
monthly retro rather than per scrum, wider focus
tickets largely written by the data scientists then priorities by product owner

仮説ベースのstoryを書く。スタンドアップをやらないで、チケットにリサーチログを書く。手助けがいるときはチケットでメンションする。Product Ownerは自分から情報を取りに行く。チケットはデータサイエンティストが書いて、優先順位はProduct Ownerがつける。つまり、DS/MLEに自分の仕事に集中してもらう、ということである。

特に、Hypothesis Based Storyはユニークである。なぜなら、先ほどのTechnical Storyにビジネス価値の話を思い返すと、MLにおける仮説検証フェーズでのビジネス価値は「リスクを低減する、不確実性を下げる」としか書きようがないからである。また、「仮説を立てて検証をする」こと自体をチケットのゴールにすることで、「ちゃんとした仮説を立てないといけない」という意識が生まれ、結果は「仮説が正しかった/間違っていた」ということでcloseできる。

The point is that the exit criteria is provable and the delivery is typically the proof. Likewise, disapproving the hypothesis is still a success, we learned something.

storyの例も併せて紹介しておこう。

“We believe a fine tuned distilbert architectures will allow us to identify cases with a precision of greater than .95 and a recall of greater than .7.”

“We believe it should be possible to transform a given article within our dataset to our standardised form without additional datasets or augmentation”

“We believe x metric can best be explained to stakeholders using a combination of shap values and distribution charts”

余談: MLプロジェクトでProduct Ownerは何をするのか

余談ではあるが、Product Ownerがチケットを作らないのであれば何をするのか、ということについて詳しく書かれた章がある。(5.6 The Product Owner Role)[https://edwinth.github.io/ADSwR/a-methodology-for-agile-data-science.html#the-product-owner-role]

まとめると

Stake holderとのコミュニケーションを一手に引き受ける。DS/MLEにはタスクにfocusしてもらう
DS/MLEの作ったタスクについて議論をしてscopingを通じて整理をするのを手伝う
DS/MLEの作ったタスクを優先順位付けする
DS/MLEの気づかないビジネス側の懸念点を指摘する

といったところである。

読んでいると、DS/MLEの時間はSWEよりも価値が高いように書かれているように感じる。

まとめ

ざっと調査してみたが、以下のような結論に至った。

厳格なスクラムはMLプロジェクトには向いていない
研究・探索フェーズと開発フェーズでworkflowを分ける
研究・探索フェーズでは、story pointではなく時間で区切る
研究・探索フェーズでは仮説検証を軸に進める（Hypothesis Based Storyを書く、Kanbanを使う）

time boxingの考え方と仮説検証を中心に調査タスクを進めていくというのは、MLプロジェクトにおいては当たり前であるが非常に強力なサポートとなるだろう。

では、冒頭の「Technical Storyを使えばタスクを2週間に収まるように分割できるはず。そして、それをすれば2週間で価値がでるはず」という言葉に対する返答としては、

ビジネス価値は「不確実性の低減」という理解をする
Technical StoryよりもHypothesis Based Storyを使うか、Kanbanに移行する
2週間という枠で具体的なゴールを決めるよりも、時間で区切って可能性の枝刈りを素早く回していく

ということになるだろう。

2024年を振り返って

Tue, 31 Dec 2024 16:34:12 -0800

2024年中はバタバタしていて書きそびれたので、2025年に書いています。

仕事

今年はありがたいことに、春にPrincipal Software Engineerにpromotionした。Staffの時にはPrincipal相当の働きをしているという自負はあったのだが、いざpromotionするとふるまい方が今までとはかなり違ったものを求められて、日々戸惑いながらもがいている。

ざっくり言うと、会社でのMLプロダクト開発における技術的リーダーシップを発揮する、いわゆるtech leadとしてふるまっているが、チーム編成が色々とトリッキーだったりすることもあり、技術的な方向性をProductチームやSenior Engineering Director陣とすり合わせたり、チームメンバーのモチベーションをどうしたら上げられるかを考えたり、ということを悩みながら進めてきた。

オライリーの「スタッフエンジニアの道」へのにその辺の話をざっくり書いたので興味があれば読んでほしい。

子供を育てるのでも七転八倒しているのに、他のチームのメンバーのこともメンタリングしたりするとは、人生とは思いもよらないものである。

こういう悩みの中、Staff+の仕事は会社によっても全然違うこともあり、Vancouverで働く、と飲んでざっくばらんな話をする機会が持てたのはよかった。2025年も続けていきたいし、他にも仲間が欲しい。

OSS活動・対外活動

今年は、仕事の関係もあってという推薦のPythonパッケージへといくらか貢献をした。ざっとみると、仕事の合間に書いた割にはことになる。

なんだけど、メインの議論がTelegramでされているようで、もうこれ以上コミュニケーションチャンネルを増やしたくないという僕のわがままもあり、Telegramには入っていない。そのため、なかなか大きめの変更を入れてもらえるような丁寧なコミュニケーションができず、時間がかかるものも多い。

昨年contributeしたChromaはいくつかマージされたが、いくつかは放置されてcloseされたりリポジトリがarchiveされてしまった。仕方ない。

それ以外だと、という地元の小さい企業がやっているミールキットの。GitHub ActionsとCloudflare Pagesを使っているので維持コストもほぼゼロで、Vangohanの方にも公式リンクが貼られてうれしい限り。

プライベート

春に友人と二人でヨーロッパへ行く機会を得た。ドイツはFrankfurt、EstoniaのTallinn、フェリーで渡ったフィンランドのHelsinkiを廻った。15年ぶりのHelsinkiはさらに雰囲気が変わっておりVancouverと比べても大都会だなあという気持ちで圧倒された。フライトも9時間前後でつくので、犬を預けられるようになったら家族でまたヨーロッパは行きたいものである。

2024年はスノーボードの練習を開始した。昨年も滑りに行ったujihisaさんの奥さんがスノボのインストラクターをやっているということで、家族でレッスンを受けてはじめた。雪山が車で30,40分と近いので自分のペースで練習できるのがとても気に入っている。

子供は徐々に英語の方がだんだん強くなってきている。日本語学校へ行って漢字の勉強をしたり漢検の取得を目指したりしている。3年半経ってだいぶ馴染んだのは良かった。

ゲームも久しぶりにSatisfactoryをはじめた。が、途中で仕事が忙し過ぎて無気力になって止まってしまっている。とりあえず一通りクリアしたいところ。探索が楽しいので工場建築が進まない。

来年に向けて

直近いろいろと現金が吹っ飛んでいくイベントに見舞われて、本厄ってこれかーと思いながら家計のやりくりをうんうんうなっているここ数週間なのだけど、色々ともう少し落ち着きたいものである。

「海外生活経験ゼロからカナダでソフトウェアエンジニアになった話〜英語勉強＆就活対策〜」を読んだ

Thu, 20 Jun 2024 16:46:46 -0700

@nappan23 さんの「海外生活経験ゼロからカナダでソフトウェアエンジニアになった話〜英語勉強＆就活対策〜」を読みました。

この同人誌は、nappan23さんがカナダでソフトウェアエンジニアになるまでに、どういう取り組みをしてきたのか、という話が書かれています。

目次を見るだけでも、思った以上に真面目に数々のオプションを比較して、それらについて考察をされていて、気合が入っています。(技術書典のサイトには目次ないのね)

もちろん、（本文中での注意書きがあるように）ビザの情報やジョブマーケットは水物で、最近ではカレッジに対するビザ回りを厳しくしようというカナダ政府の動きもありますし、高金利が続く中北米のTech業界はlayoffが続き、職を得るのが難しい状況になっています。

そんな中でも、この同人誌に書かれた文章からは、どういったマインドセットがいいんだろう、どういう要素が重要なんだろう、ということに示唆を与えてくれていると感じました。

特に、以下の文がとても強いメッセージを伝えてくれていると思います。

ほんの少しだけ英語ができて、コミュニティの力を借りたおかげで海外就職ができた。英語と人脈とビザと運を味方につけられれば、相応の準備をすれば、海外就職は「一握りのすごい人だけ」ができるものではない

常々、英語は最低限の文法知識とかがあれば、あとはガッツで補えると思っているのですが、どうやって英語学習を続けるか、が一つの鍵なんだよなあと改めて感じました。そして、一番の支えとしては、自分が所属する技術コミュニティがあること、ここが大きかったんだろうなというのを強く思いました。

あと、海外移住をするために必要なのは割と勢いが大事だと思っていて、やっぱりそうなんだなと再確認させていただきました。

自分自身も、カナダに移って文化の違いを感じ、馴染む部分も大きいなと思いながら生活をしています。

London Tech Talkでも（たしかで）話題に上っていましたが、憧れドリブンでえいやっと進めるのが大事な局面も大いにあると思っていて、そういう勢いを大事にしていきたいなと思いました。

この同人誌は、海外で働くことに興味がある人にとって、本文中では女性やノンバイナリへのメッセージがありましたが、それ以外の多くの人にも得るものがあるのではないかと思います。

2023年を振り返って

Sun, 31 Dec 2023 00:00:00 -0800

今年もあと一日になりましたが、一年を振り返っていきたいと思います。

OSS活動・対外活動

ChromaというVector DBのOSSにコントリビュートしました。ChromaはRAGやLLMの文脈でよく使われるもののようです。

tabula-pyの裏側にjpype経由で使うようにして速くしたのですが、残念なことに Python 3.12 サポートがかなり時間がかかったので今はoptionalにしています。

また、tabula-pyの質問はStackOverflowに流していたのですが、ということが分かったので、今までの感謝とともにGitHub Discussionsに移行しました。

あとは、NotionをscrapingしてPDFにするやつなんかも作りました。

RubyKaigi 2023にもただの参加者としてですが参加できたので、その様子をバンクーバーのえんじに屋podcastでお話させていただきました。

View this post on Instagram

A post shared by Aki Ariga (@chezo.uno)

また、Frogさんでキャリアのインタビューもしてもらいました。行き当たりばったりなキャリア経験ではありますが、きれいにまとめていただきました。

仕事

昨年炎上プロジェクトに投入されて火消しをするも、いろいろあってぽしゃり、そしてまた、別の炎上プロジェクトに投入されてそちらはなんとかかんとか生き延びている、という状況です。突っ込まれてから、4カ月後の社外カンファレンスでデモまでこぎつけられたのは、ML系プロジェクトだからだなぁという良い経験をさせていただきました。6 pageのレポート作成からのexecutiveの説得、UX設計、PRD議論、アーキテクチャ設計、実装、他のエンジニアリングチームのとりまとめとまあ全部やりました。

最近の悩みは、クオーターごとに実装期間がほぼ1週間くらいしかないことでしょうか。楽しい時間は一瞬で過ぎ去ってしまう。。。soft skillを生かして仕事では動いていますが、やはりhard skillも伸ばしておかないと上流だけしかできないのね、と言われてしまうのが怖いです。スタッフ+としてどう生きていくのがいいのだろうか。副業などで手を動かす仕事をやりたいものです。

社内ハッカソンで、RAG (retrieval augmented generation)のアプリを作りました。を使い、さくっとデモアプリまで行けました。なお、RAGは短文で検索するときの検索性能が全然でないため、OOBじゃ全然使えないということも学びました。しかし、検索と推薦は楽しいですねぇ。

プライベート

PRカードをついに手に入れました。永住権自体は昨年末に得ていたのですが、物理カードを得たので、これでビザ的には一番安心できる状況ですし、海外旅行も行けます。あと、海外の会社で働くのも楽になりました。

スキーを20年ぶりに再開してドはまりしています。ujihisaさんと何度も滑りに行ってますがローカルの山まで30分、Whistlerまで2時間なので更に滑りまくりたいです。今年はエルニーニョ現象のため、雪が全然なくてつらいです。パラレルをちゃんとものにしていきたい。

View this post on Instagram

A post shared by Aki Ariga (@chezo.uno)

あと、忘れもしないのは銀行のコールセンターにを受けたこと。Scotiabankという銀行を移住時に開設したのですが、全国一律のコールセンターの人に英語わからない認定を食らって。上司が出てきて謝罪をもらったんですが、そういう銀行を使うのは癪なので、TDに移行してすべてうまくいっています。1Passwordで自社名とconflictすることくらいがネックなだけです。なお、ショックだったのは、某日本人コミュニティで「あなたの考えすぎじゃないですか」というセカンドレイプを受けたことでした。 unconscious biasのトレーニングを会社で受けていてよかったなと思った瞬間です。

転んでもただは起きぬということで、を受けるようになりました。理屈より実践という感じの手法なのですが、なるほど実際そうするのねーというのが身についてきて、けだるい英語のリスニングができるようになった気がしています。

12月を丸っと休みにしたのですが、家族が次々と怪我をして看護休暇として追われています。ずっとワンオペで子供と犬の世話をしている日々なので、ゆっくりとした休みが欲しいなあと思う次第です。

振り返りと来年に向けて

今年は、いろいろと迷いの多い一年だったように思います。来年は40の大台に乗るので、仕事方面は人生で一回くらいプロモーションしていきたいなと思いますし、プライベートは英語とスキーを上達したいと思っています。

中長期的には、Greator Vancouverで家を買うには大体 1M CADが必要なのですが、その頭金として300K CADを貯めればいいことが分かったので、何とかしていきたいと思います。手っ取り早いのは、スタートアップで一発当てて$1M手に入れるか、big techに入って高給取りになることなんですが、まずは地道に貯めていこうかなと思います。

2年半バンクーバーエリアに住んでみてわかったのは、家賃上昇が激しく（Vancouver cityは2023年12月で）living costはめちゃくちゃ高いわりに仕事があまりない（シニア以上はシアトルはじめUSに人が流れてしまうのが定番）という現状なんですが、医療費がかからない、スキーに行きやすいなどのメリットとの天秤でまだこの地にとどまることになると思います。が、平均年収$59Kの国で$100K超えの年収がないと一人暮らしできないVancouverやTrontoは異常なので、職があればAlbertaなどに行くのが良いんだろうなぁ。

Social media関連は色々と整理したり¹展開しなおしたりしたのですが、人と話すことで刺激を得たいと思っているので、Vancouver近辺にいらした際にはお声がけください。もちろん、近隣にお住いの皆さんは引き続きよろしくお願いいたします。

某toxicな持ち主のプラットフォームからは完全撤退しました ↩︎

携帯からSlackを消した

Sun, 20 Aug 2023 17:44:43 -0700

休みの時の仕事の通知をコントロールする術をずっと模索していた。これは、放っておいても仕事のSlackを見てしまい即レスポンスを返してしまう習性があるからだ。

これをやっていても自分の精神的な疲れは溜まる一方で、別に給料が上がるわけでもないし、そこまで感謝されるわけでもないなということに気づいた。

友人からiOSの集中モードを教えてもらって「これだ！」と思っていたものの、Googleカレンダーは対応していないなどなかなかうまくいかないことも多かった。

結局、こんな感じで対応することにした。

Jiraなどの通知系を全部Slackに集約する。モバイルアプリの通知はオフ
会社のSlackのスペースからログアウトする
Gmailの会社アカウントの通知を切る
仕事しないときは睡眠時以外はパーソナルモードにする
会社のカレンダーは、パーソナルモードの時にはフィルターする

つまり、情報は欲しいときにプルで入手するという方針である。

オンコールのアラート対応など困ったときはPager Dutyで飛んでくるだろうという割り切りである。優秀な同僚が、会社の携帯ポリシーがいやだから自分のスマホに会社関連のものを入れていないというのを聞いたのも決め手となった。

今のところダウンサイドとしては、ミーティングのために慌てて帰ってきたらホストが体調不良でキャンセルされたのに気づけなかったことくらいである。スマホがない時代は、PCでしか仕事できなかったし、なんとかなるのではないかと思ってやっている。

あと、コミュニティ系のやり取りはDiscordですることが増えたのも大きいように思う。

楽天モバイルを利用してiPhoneを海外で機種変するとSMS代がかかる

Sun, 06 Aug 2023 16:50:23 -0700

tl;dr

海外で楽天モバイル回線を使用したままiPhoneを機種変更すると、100円×N回の国際SMS料金が請求されるようになりました。

詳細

iPhoneを機種変更するときに、iMessage/Facetimeのアクティベーションに失敗し続けることがあります。

特に楽天モバイルでは、楽天回線の圏外でiMessageなどのアクティベーションをしようとすると失敗することが観測されてきました。

アクティベーションがうまくいかない時iPhoneの仕様上 +44 の番号へSMSが自動的に送り続けられます。

ところで、海外で楽天モバイルを使う際、iPhoneだとSMSの送信や標準電話アプリでの電話の送受信で料金がかかります。

以前はこのアクティベーションのSMSは料金がかからなかったようなのですが、今年4月に機種変更をした際に2カ月遅れで謎の調整金という費目で1月後れで請求されるようになったようです。

この仕様はFAQにも書かれており、サポートに問い合わせてもこのドキュメントが出てくるだけです。

調べても、ウェブの情報は海外では楽天モバイルが良いという情報しか出てこなかったので、備忘録として書き残しておきます。

2023年8月からpovoが海外ローミングをできるようになったようです。海外での番号維持及びSMSでの多要素認証には(eKYCのハードルを除くと)povoが一番よさそうです。

25年ぶりにスキーを再開した

Wed, 05 Apr 2023 13:38:23 -0700

バンクーバーは、最寄りのスキー場まで車で30分で行けるので有名です。30分圏内にスキー場が三つ(Grouse, Cypress, Seymour)もあるので気軽に行けます。有名なWhistlerも1.5時間で行けます。

3月の後半に春休みが2週間あり、仕事もどうせ進まないだろうなと思いながら、子供を午前だけの半日スキー教室に5日間通わせました。子供が気に入ったらシーズン券を買ってもよいかなと思っていたのですが、折角だし休みを取って待ってる間に自分もスキーを滑ってみたのですが、ハマってしまいました。

自分が最後に滑ったのは25年くらい前の子供の頃なので覚えているか不安だったのですが、マッスルメモリーが覚えているものですね。ボーゲンを辛うじてできるレベルで止まっていたので、パラレルを目下練習中です。

長期間やっていたプロジェクトが突如なくなったのもあり、うっかり春のシーズンパスを買って6回くらい滑りに行きました。朝に子供を学校に送って迎えに行くまでに滑るということが気軽にできるのでとても良いです。

3月後半なのに雪が降った直後の晴れた日に、さんさんとGrouse Mountainで滑れたのは最高でした。

でも、曇ると一気に見えなくなりますね。

雪と桜が同居している不思議な体験をしました。

この投稿をInstagramで見る

有賀康顕(@c.hezou)がシェアした投稿

また一つ年を取った

Fri, 27 Jan 2023 22:36:50 -0800

2023年も1月があっという間に過ぎてしまいました。先日、誕生日を迎えて40歳の大台目前になりました。誕生日に行った歯医者にケーキを渡されたり、Appleサポートに2時間奪われたりとなかなかよくわからない忙しい日を過ごしました。今週めちゃくちゃ忙しかったので、今日になってしまいました。

例のリストはこちらです。

のですが、カナダの永住権を取得しました。カナダの永住権は5年更新で住み続けられるというもので、市民権とは違い選挙権はありません。が、それ以外は大抵OKというものです。

で、誕生日の前日にPRカード（アメリカでいうグリーンカード）が届いたので、ようやくカナダ国外に出られるようになりました。 5月の松本でのRubyKaigiに久しぶりに参加しようと思いますので、皆さんよろしくお願いします。

2021年の4月にバンクーバーにやってきて、もうすぐ2年ですがこちらにタイムラインをまとめました。

PR取得に向けて社内の動き出したのが2021年6月だったので、動き出しから1年半、Express Entryの申請からは1年4カ月かかったことになります。

そもそも、社内のリロケーションを始めたのが2020年3月だったので、work permitで動き始めてから2年9カ月でここまで来たことになります。いやー、長かった。

カナダのwork permitは通常会社に紐づいていますが、layoffされたりしても。

とはいえ、永住権を持っていれば首になっても例えば日本の会社の仕事をすることも問題なくなるわけですね。安心感がだいぶ違います。

というのも、出身国ではない国にいると、いつ何時政府から追い出されるかというリスクを伴いながら生活をするので、目に見えないストレスが溜まります。日本だったら、仕事が嫌になったら転職すればいいという気持ちになれますが、なかなか足場が固まらない状態では、日々何が起こるかわからないという不安を抱えながらただ耐えながら生きていくことになります。これが地味にきつかったです。

今年は、Duolingoでのフランス語の勉強に加えて、ASLを学び始めたり、rebuildでmiyagawaさんが苦手だと言っていた競プロ的なところにもチャレンジしてみようかなーと思っています。

帰国した際には、遊んでやってください。

Timeline for Canadian PR

Fri, 27 Jan 2023 16:02:00 -0800

Time line for work permit

2020/03 Started internal process for relocation
2020/11 Got internal approval. Start working with the immigration agent
2021/01/28 Submit documents for work permit
2021/02/09 Received work permit with family
2021/02/22 Received Travel Authorization
2021/04/02 Relocated to Vancouver

Time line for PR

2021/06/28 Ask HR to start process for PR
2021/07/14 Submit documents for ECA (Educational Credential Assesment)
2021/07/26 Received ECA
2021/08/05 Submit Express Entry profile. Score was 337.
2021/08/18 Register for BC PNP
2021/08/24 BC PNP Invitation to Apply Notice
2021/09/23 Missed BC PNP deadline because of the agent forgot it
2021/09/29 2nd Register for BC PNP
2021/10/05 2nd BC PNP Invitation to Apply Notice
2021/10/06 Submit BC PNP
2021/10/26 Received Express Entry Nomination. Score was 937.
2021/10/28 Confirmation of Provincial Nomination
2021/10/30 Took medical exam
2021/11/22 Submit eAPR
2022/07/26
- Received Medical Request Notice while it had been submited
- Re-upload Medical Document
2022/12/15 Inviation PR Confirmation Portal
2022/12/23
- PR Portal Invitation & Submit
- Took Photo for PR at London Drugs
2022/12/29
- Received eCoPR 🎉
- Submited MSP card status change
- Recreate CRA account
- Request new SIN number
2023/01/9-16 Received new SIN number
2023/01/24 PR card received. Everything completed.

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

iOSでの休暇中の仕事の通知管理

Tue, 10 Jan 2023 16:58:00 -0800

iOS15から集中モードが加わって、その中でもパーソナル集中モードというのがあったので、年末年始の休暇に試してみた。

簡単に言うと、パーソナル集中モードでは業務用のアプリからの通知をオフにできるというのが一番のメリットだ。

以下の記事に大まかな概要が書いてあってわかりやすい。

Androidではwork profileがあるので、が、iOSではごちゃまぜの世界観なのがとても厳しいと思っていたところだった。

実際に試してみた結果、いくつかの問題が出てきた。

GmailやSlackなど仕事でもプライベートでも使っているアプリで通知がコントロールしきれない
通知を知らせないアプリに指定しても、対応していないため突き抜けてくる（Confluence、お前のことだぞ）

2個目は仕方がないので通知を完全にオフにして心の平穏を保つことにした。別にAtlassianアプリからの通知はSlack連携とかもしてるし不要だと気づいた。

1個目は、Gmailに関しては一応アカウントごとに通知をオフする機能があったので、それでオフにした。ただし、これだと「すべての受信トレイ」で突き抜けてくるので、ぐっと堪える必要がある。正直、気持ち悪い。

Slackについては、通知のスヌーズはあるけれど、これやってもバッジの数がぐんぐん成長してmentionを受けるたびに数が増えてきて気持ちが悪いので、サポートに問い合わせたところ、その組織からsign outしてください、とのことだった。そうですか、と思いながらサインアウトしたけど、機能要望は出しておいた。

Gmailもすべての受信トレイのバッジ出すならログアウトするほうがいいのかもしれない。でも、毎週末ログアウトしてサインインするのはとてもじゃないけれどやってられない。

なお、Apple製のメール、カレンダーなどのアプリはアカウントごとにフィルターする機能がある（のに今気づいた）ので、これを設定すれば通知が来なくなりそうだ。

Android版Apple Musicといい、iOS版Google Podcastといい、相手のプラットフォームだと痒いところに手が届かなくなるのは、宿命なのだろう。

サードパーティ製のアプリは、気になるようであれば都度サインアウトして復帰時にサインインするしかやはりなさそうである。ただし、某社のように休日に対応しないとレイオフが走るような会社の人には使えないだろう。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

2022年を振り返って

Fri, 30 Dec 2022 14:59:13 -0800

に引き続き、2022年の振り返りです。 RTA in Japanに触発されてなぜかを見ながら書いています。

クリスマスに胃腸をやられて一週間弱ずっと寝込んでいました。ようやくPCの前に座れるくらいの元気が戻ってきました。

今年はバンクーバー生活も二年目で色々と落ち着いたかと思いきや変化も大きい年でした。

OSSや対外活動

振り返ってみると、おかげさまで今年はちょこちょこといろいろなところで学会活動や、イベント登壇などをしたりできました。

MLSEのワーキンググループは無事次世代に引き継ぐことができたかなあと思ってほっとしています。

ばんくしさんからお声がけいただいて、MLエンジニアのキャリアについて放談させていただきました。大変準備してくださっていてとても助かりましたし、自分のキャリアを振り返る良いきっかけになりました。ありがとうございます。

OSS活動も細かなレコメンド用ツールを作ってリリースしたり、sqllineage や sqlparse の upstream に貢献したりできてよかったです。

Netlify CMSがメンテナーが転職したため、Hugo + Netlify CMSの構成が日本語では使い物にならないことが確定したので、そこだけが頭を悩ませています。

また、不義理をしていた副業社はいったん契約を解除して仕切り直しとなりました。

仕事

仕事は昨年とチーム変わらず、西海岸メンバーは1人増えたので大変心の余裕が増えています。 RailsとSQLにdigdagがりがりみたいな生活から、後半はDynamoDBとサーバーサイドKotlin、少しApache Flinkみたいな感じにシフトしています。新しく入った若いメンバーに、一貫性壊れてませんか？とか言われながら久しぶりのJVM言語にあくせくしています。

チームの仕事はCookpadでもお世話になった青木峰郎さんのこのトークがわかりやすいかなと思います。

しかしこのチーム、Rubyコミッタが現旧4人いてすごいですね…。n月刊ラムダノート著者も2人います。すごい。

Podcast

ご縁があってSennaさんとYuyaさんのホストしている、バンクーバーのえんじに屋 Podcastに出演させていただきました。

また、久しぶりに自分のPodcastも更新しました。ニュージーランドでCGアーティストをしているTahkoさんとの海外トークをさせていただきました。Avatarの続編は映画館で見たほうが良い美しい映像となっているようなので、是非。

プライベート

詳細は別途まとめようと思いますが、ひとまずeCoPRが出ました。これで永住権（≠市民権）を獲得したことになるので、5年更新で滞在することができます。よかった。

また、これに合わせて副業等を前よりもやりやすくなったかなと思います。もしご相談があればメールやDMなどでご連絡ください。

takuti先生と現地の友人にも誘われてハイキングに行くようにもなりました。一回目が残雪残る雪山でしたが、あれくらいなら行けるという自信をもらいました。マイクロスパイクやスノーシューが欲しい今日この頃です。

日本はモンベルがあるのが安くてよい製品を手軽に手に入れられてよいですね。

View this post on Instagram

A post shared by 有賀康顕 (@c.hezou)

また、家族に犬が増えたので、犬連れでキャンプデビューもしました。ギアを買いそろえたので来年もまた行きたいです。

View this post on Instagram

A post shared by 有賀康顕 (@c.hezou)

しかし、改めて気づいたのがバンクーバーは水がおいしいからか、地酒もありクラフトビールも多く、ワインもおいしい。果物もリンゴやブドウ、ブルーベリー、イチゴなどが豊富でさくらんぼもあるなど非常にローカルの恵が豊かでありがたいです。

インビザラインも始めたのですが、歯科衛生士が1.5時間首で支える姿勢で歯にいろいろ取り付けをやったため、頚椎椎間板ヘルニアが再発しました。今は少し良くなってきていますが、勘弁してほしいです。お茶も飲めないし22時間装着しろということで、かなりQoL下がっていますが、お金払った分はなんとかやり切りたいと思います。

2023年に向けて

まだ、PRカードが届いていないので日本への渡航ができませんが、運転免許の更新のために一度帰国する予定です。よければごはんやらビールやら飲みましょう。

Wowchemyをv5.5.0からv5.7.0に上げた

Fri, 16 Dec 2022 17:23:22 -0800

毎年アドベントカレンダーの時期にHugoのテーマであるWowchemy (旧 Academic) のバージョンを上げています。

今年は、唯一参加したアドベントカレンダーもNotionで済ませてしまったので、恩恵にはあずかれませんでしたが、それでもまあ定期アップデートは大事ですね。

Wowchemyは、スタートするときはサクッとstarter kitから作成できるのですが、変更に追従し続けるのが結構厄介で破壊的変更をガンガン入れてきます。が、ドキュメントは最新のバージョンのものしかなく、 Release noteを見てあとはソースコードを見る羽目になります。正直面倒くさい。

というわけで、今回v5.5.0からv5.6.0、v5.7.0に上げたので何をしたかを備忘録的にメモしておきます。

v5.6.0

v5.5.0からは結構大きな変更が入りました

config.yaml (or toml) や params.yaml の構造が大幅に変わった
- そのままだと検索、Gravaterなどが無効になるので注意
go.modの依存するmoduleパスの変更
Algoliaを検索に使うと壊れる

config,params.yamlの変更は、特にどこにも記載がないのでソース読みながら根性で直していきます。特に、 “features” 系は適切に設定しないと、検索が消えたりして大惨事なのでお気をつけてください

多分、rootの設定はいくつか間違っている気もしますが、もう諦めました。

しかし、tomlの構造をパースするのは僕には難しいのでyamlのほうが楽かもしれませんね。

2個目については、ローカルで試すときは例によって hugo mod get をすればよいです。

hugo mod get github.com/wowchemy/wowchemy-hugo-themes/modules/wowchemy/v5@v5.6.0

Algoliaは試してみたのですが、エラーが止まらなくて諦めました。

v5.7.0

特に大きな影響もなくそのままいけました。過去一楽なアップグレードでした。

hugo mod get も6を7に変えるだけです。

hugo mod get github.com/wowchemy/wowchemy-hugo-themes/modules/wowchemy/v5@v5.7.0

Algoliaを試したけど挫折した

v5.6.0にも書いたのですが、Algoliaを試して辞めました。

検索自体はよさげなんですが

Hugoの生成するindex.jsonを取り込むとMedium由来の -- みたいなハイフンが複数つながるURLが - と一個に正規化されたperemalinkと解釈して、無限にredirectsを設定する羽目になる
Algolia Crawlerを使うNetlify pluginがあるのですが、それを使ってinstantsearchから検索をすると検索結果が空になる

特に後者が致命的でした。なんか、便利そうだけど壊れてて使えないという体験がつらかったので諦めました。

サポートに問い合わせをすればいいのかもしれませんが、もうその気力もなく…。

また、来年Wowchemyのアップグレードをしたいと思います。

日本のサービス解約RTA～カナダ編～

Mon, 28 Nov 2022 16:41:00 -0800

これはの6日目の記事です。

昨日はさんでした。

さて、と呼ばれる現象については皆様もご存知かと思います。日本にいるとあのゲームが買えない、このハードが買えない、このサービスが契約できないというアレです。

日本のサービスもご多分に漏れず、そういうケースがままあります。

というわけで、カナダで残念ながら解約した日本のサービスたちとその難易度を紹介したいと思います。

楽天モバイル (おま国なし)
Disney+ (日本)
Kyash

楽天モバイル (難易度 ★☆☆☆☆ 所要時間10分)

楽天モバイルは素晴らしい携帯キャリアです。海外でも2GB 980円で通信ができるし、日本の電話番号やSMSも使えるので愛用しています。

無料で維持できるときに予備のAndroidの番号を発行していたのですが、流石に月額無料は無理になったので、1回線解約しました。

解約導線がパッとわからなかったので、Googleでに到達してアプリから解約すればできました。

おま国もなく、とても簡単にできました。素晴らしい。

なお、機種変更したときにeSIMの移行がクイック転送に失敗しましたが、eSIM再発行すればよかったので、事なきを得ました。

Disney+(日本) (難易度 ★★☆☆☆ 所要時間30分)

日本で契約したDisney+ですが、Avengersを一気に履修するなどいろいろなコンテンツにもお世話になっていました。ですが、カナダで契約し直したほうがいいなと思い解約をしました。

解約の動機の一つとして、日本のサービスなので日本のIPから接続しないと見れないという問題がありました。そうです、おま国です。

仕方ないなー、と思ってGoogleで「ディズニープラス」とでも検索してたどり着いたのが、。

解約はおろかアクセスすらさせてもらえません。Cloud Frontレベルで弾かれています。マジか。

まあ、仕方がないのでこういうときのためのVPNを使い事なきを得ました。

余談ですが、日本のいろいろな行政サービスは、日本に親族知人がいることを前提としており、なかなかハードルが高くて笑ってしまいます。戸籍謄本を取得するときに、現金での支払のみ（昔は国際郵便為替なるものでギリギリできた）なので、日本に縁者がいない場合は行政書士にお願いする必要があるそうです。日本にVPNサーバーは立てておかないといけないんですねぇ。

TP-Linkの適当な無線LANルーターは、OpenVPN機能もついているのでおすすめです。TP-Linkアカウントがあれば、遠隔からもファームウェア更新ができます。すごいですね。

みなさんも、念のため実家等にVPNサーバーを置いておきましょう。

Kyash (難易度 ★★★★☆ 所要時間約2日)

日本にいたときは割り勘やらAliExpressの支払いなどでお世話になっていたKyashですが、ある日アプリを開いてログインしてみると利用制限されてしまいました。1年ぶり二度目の利用制限です。

1年前のときは、サポートに問い合わせたら翌営業日には復活したのですが、今回はサポートから現住所が確認できる本人確認書類（免許証、マイナンバーカード、運転経歴証明書、在留カード、住民票の写し）を提出し、居住国を申告してください、と言われました。

ところで、カナダのBC州では運転免許証はこちらのに切り替えるときに没収される仕組みです。マイナンバーカードもまあカードはあるけど、すでに署名は使えない状態になっています。

素直に居住国を申告し、毎回本人確認書類提出は面倒なので退会したいと連絡したところ、利用規約で「日本居住者に限り提供するサービスです」と書かれているため利用できないという返信が来ました。

なるほどね、そうですか。

で、「利用制限中は退会の手続きができない。公的書類等を提示しないと制限中のままにする。退会したい場合は帰国後にサポートに問い合わせてね」という旨のご連絡をいただきました。

マジかー、帰国費用請求できるかな？などという邪な気持ちも発生しましたが、念のためにスキャンしておいた免許証の画像をお送りして、翌営業日には担当部署に確認していただき、更にもうその翌日、退会処理が無事なされました。めでたしめでたし。

不正アクセス対策やマネーロンダリング対策が厳しくなっているのはわかります。本人確認書類で免許証やマイナンバーカード必須にすると、それを没収されるケースでにっちもさっちもいかなくなるんですが、エッジケース過ぎて普通気づかないですよねぇ。

みなさんも、念のため本人確認書類は没収される前に画像でスキャンしておきましょう。

番外編: 日本の郵便の転送届（難易度★★★★★ 所要時間 1週間）

解約ではないですが、日本の郵便物を念のため実家に転送するように設定していました。出る時は日本にいたのですが、オンラインで設定できて便利だなーと思って今年も今年も延長しようとした所、大きな問題が。

マイナンバーカードの読み取り！または本人確認書類を写真で読み込み！いわゆるeKYCが導入されました。eKYCのポイントは住所も大抵チェックされるのと物理カードが必要なことです。免許証もないし、マイナンバーカードも実家の住所にはしていません。

なお、葉書での提出や郵便局への届出はプロセスは変わっていないので、実家の親にお願いをしてことなきを得ました。うーん、最悪そのために帰国するとか考えると頭が痛いですねえ。

マイナンバーカードが2024年までには海外在住者にも発行できるようになるので2023年には色々と便利になるかも？

カナダのサービスのおま国はないのか？

あります。Android TVでカナダのCBC（中部日本放送ではない）など放送局のアプリをダウンロードしようとしたときに、日本のGoogleアカウントだとダウンロードできなくて詰んだりします。そういうときは、iOSでカナダのApp StoreからダウンロードしてCastしたりと工夫が必要になってきます。

明日はさんです。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

カナダのいいとこ悪いとこ

Sun, 13 Nov 2022 18:34:00 -0800

カナダ（バンクーバーエリア）のいいところと悪いところを書いていきます。例によって、バンクーバーエリアの半径5km圏内の話しか書いていない可能性が高いのでご注意ください。

名前	タグ	詳細
医療費が無料	👍	国民皆保険制度なので、病院での診察や入院での費用がかからない。薬代は会社で入る民間保険である程度カバーされる。
歯科治療費は高い	👎	会社の入ってる民間保険である程度カバーされるが、基本的に半年に一回の定期チェックしかできない。虫歯が見つかったり詰め物が取れると一回300ドルコース。歯周病の治療が発生すると1500ドルコース。日本で直したほうが良い。
高校まで公立学校は無料	👍	所得制限も特にない。
学校でELL (English Language Learning)へのサポートが手厚い	👍	ESLの学生向けに特別な授業が開かれたりしてサポートが厚め。ただし、学年やレベルが進むと薄くなる。
学校のクラスの人数が少ない	👍	学校にもよるかもしれないが、1クラス20人行かない程度のクラスサイズで助かる。
特別支援向けのサポート教員がついている	👍	クラスに特別支援が必要な生徒にサポート教員がついてマンツーで支援している。日本と違い支援級が分断されていないので、多様な子がいるのが当たり前と感じられる。
大人も学び続けることができる	👍	新たな職種にチャレンジするために学校に通っている人や、学びたいことがあるので学校に通う大人が結構いる。
ビザ・永住権が取りやすい	👍	これは州や職種にもよるだろうけど、移民国家なのでかなりビザが取りやすい。特にテック業界だとBC州では優遇されており、2年目で永住権を取得するという話も普通に聞く。また、配偶者もオープンワークパーミットが簡単に出るので、本人のワークパーミットに加えて配偶者も現地で働くことができる。
アジア系スーパーで日本食材や中韓の食材が容易に手に入る	👍	日本のお菓子や日本みたいな味のケーキ（ショートケーキ）も食べられる。味覇も売ってる。
外食が美味しい	👍	物価が上がっているので、値段は上がってきているが、高いお金を払わなくてもそれなりに美味しい物が食べられる。ただ、事前にGoogle Mapなどでのレビューを見たほうが良い。
食が多様	👍	特にベジタリアンやヴィーガンの人が多いため、代替乳や食材が豊富。どのカフェでも牛乳を変えてもらえるし、コレステロールなしのナッツミルクなどのアイスも普通のスーパーに売っている。冷凍うどんも普通のスーパーにある。
子連れに優しい	👍	スーパーやホームセンターで子連れでレジに並んでて困ってると助けてくれたりする。バスや電車も小学生までは無料で乗れる。
犬に優しい	👍	ドッグランも多いし、トレイルで散歩している犬も多い。また、犬が好きな人も多いらしく、丁寧に挨拶してくれる。エリアによるけれど、住宅街は夜女性が一人で犬の散歩をしている人もまあまあ見る。大型犬を飼っている人も多い。
山や自然が近い	👍	ハイキングやスキー場に車で３０分かからず行ける。アウトドア派じゃなくてもでかけたくなる。散歩にちょうどよい湖も多いし、ダウンタウンから近いスタンレーパークで貸自転車で走るのも気持ちが良い。
美術館・博物館は少ない	👎	ちょいちょいあるけど東京ほどはない。NYCとかヨーロッパのほうが多いだろう。
多様性を維持するための取り組みが多い	👍	アメリカと比べると、先住民族（Indigenous people）の問題に真摯に取り組もうとしている（ようにみえる）。もちろん、侵略して土地を奪った歴史に対して、まだまだやるべきことだらけであるがが、地方政府の会見の前にIndigenousの人々への敬意を表明したり、前向きに進んでいるように思う。移民国家として、Asianなど様々な人種をfeatureする月があって学校や図書館でも取り上げているので、子供に教えてもらうことも多い。
ビールが美味しいしブリュワリーも多い	👍	市にブリュワリーが2個しかないと煽られるくらいにはブリュワリーが盛ん。ローカル感があってとても良い
ノンアルコールビールも美味しい	👍	クラフトビールのノンアルビールもある。
ラーメン屋は結構ある	👍	そんなに並ばなくてもそれなりに美味しいラーメン屋さんを堪能できる。
近くに大きいモールがある	👍	自然が近い割に、Apple Storeが入ったモールなんかもあって、買い物には困らない。
車の維持費が安い	👍	良くも悪くも法定点検がないので、自主的な点検を毎年するのと、保険のお金くらい。保険も日本のそれよりは安い。
車の運転が雑	👎	いろいろな国で免許を取得した人が来るので、結構運転が荒い人が多い。車線変更にウィンカーを出す人は奇跡。右折時にウィンカーを出したら死ぬ病気の人は多く、たまに左折でもウィンカーを出さない人もいる。お互い空気を読みあって運転している。名古屋のほうがマシかもしれない。なお、車線変更や店から出るときの割り込みは入れてくれることが多いので、根は優しい人が多いのだろう。
おま国が多い	👎	アメリカでは売ってるのに、カナダになると売ってない、売っててもラインナップが少ないということが多い。基本輸入になる。ガジェット類も日本みたいに多くない。だいたい日本より高い。
図書館のデジタルライブラリーが良い	👍	アプリでデジタルライブラリーから本を借りることが簡単にできる。また、オライリーのSafariも市が提携しており、無料で読める。
税金は安くはない	👎	所得税も日本と同じかちょっと高い感じ。消費税は食料品にはかからなかったりものにもよるが、嗜好品などは最大13%。
税関連のシステムがひどい	👎	不足分を支払いしたのに、毎月請求されるとかでその度に朝6時に起きて電話をしないといけないはめに。
電話での交渉が多い	👎	電話好きすぎる。電話じゃないと話が進まないことが多い。英語で電話で交渉をするガッツが常に求められる。
携帯電話・インターネットが高い	👎	携帯はMVNOの2GBで $30 、インターネットも1Gbpsの光回線が $110 とかなのでとても高い。光回線は理論値近く出るのはいいんだけど…。
家賃はとても高い	👎	バンクーバー周辺はカナダ1高い。トロントよりも高い。バンクーバーのスカイトレイン（電車）の駅近郊とかだと、3ベッドルーム月2500～3000ドル以上は覚悟した方がいい。家を買うなら長屋みたいなので3BR 1Mドルコース。宝くじが当たらないと買えない。その原因も、政府の申請フローが重たいからとか、中国系資本がガンガン投資で買いまくってるとか色々言われているが、すぐに安くなる雰囲気はない。お隣アルバータ州は家賃は安いので、Alberta is calling youなんてキャンペーンをしている。が、保守よりな州なので僕はちょっと向いてないかなあ。
金を払っても仕事をしない人々がいる	👎	不動産屋などに、修理の依頼をしても結局半年くらい修理されるまでにかかったりして、2日に一回くらい電話やSMSで催促をしないといけない。常に何かを追い立て続けることになる。修理を依頼された業者も仕事が雑で、修理を依頼したのに壊されて別の業者にお願いするハメになることも。しかも時間通りに来ないし連絡もなくすっぽかすことも。
物価が年々上がり続けてる	👎	YoYで8%とか上がるし、食料品は11%とか上がる。如実に物価上昇がわかるレベル。
銃や刺殺の事件が増えている	👎	ここ最近ではあるが、銃やナイフで人が殺される事件をニュースで見る機会が増えた。ギャングの抗争とかもエリアによってはあるけれど…。
日本みたいな温泉はない	👎	あっても塩素消毒されて水着で入る温水プールみたいなもの。
自己主張が求められる	👎	なんでも主張しないと存在しないものと思われるので、日本にいるときよりもガンガン言わないといけない。慣れたけどMPが足りないときがある。
日本のコンテンツにはあまり困らない	👍	漫画や技術書も電子書籍で買えばいいし、アニメもVPN使えば大きな問題にはならない。いい時代になったなあ
ウイスキーもワインもいける	👍	BC州にはオカナガンという一台ワインの産地がありローカルワインが楽しめる。また、ライ麦のウイスキーがカナダでは盛ん。ライ麦のウイスキーはハイボールで気軽に飲める。クラフトビールみたいに小さい醸造場もちらほらあり、いろいろなウイスキーを探す楽しみもある。
バスや電車が充実してる	👍	都市部のバスや電車は時刻通り(あるいは早く)に来る。バスには自転車も乗せられる。スカイトレインは本数も多く3分に一本とかのペースで来るので、割と東京の感覚に近い。
パンが美味しい(サワードーやライ麦パン)	👍	日本のふわふわパンも中華系パン屋さんや日本人のパン屋さんに行けば買えるけど、ヨーロッパ系のサワードウやライ麦パンが美味しい。特にサンドイッチにハムやサラミを挟むととても美味しい。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

機械学習工学研究会夏合宿2022でMLインフラ運用WGを終了しました

Fri, 15 Jul 2022 15:16:04 -0700

2019年から土橋さん ( ) と共同幹事をしていた、機械学習工学研究会 (MLSE) の「本番適用のためのインフラと運用WG」を、6月30日～7月2日に開催したで終了しました。

2022年MLSE夏合宿での議論

今回の夏合宿では、過去開催してきた討論会やカンファレンスで上がっていた、本番適用をするための課題をリストアップし、現在も課題となっている部分を中心に議論をしました。

議論に使ったMuralはGitHubにexportしてあります。

黄色以外の色のものは当日追加したトピック、左下の赤で囲まれた部分はさらにそのまとめになります。

活動をまとめていて気づいてきたのは、多くのMLOpsツールを提供するベンチャーやクラウドベンダーによって、自動化をするためのOSSやマネージドサービスはそろってきているものの、組織やプロジェクトのフェーズごとに必要なものが違ってくるということでした。

フェーズによるML基盤の変遷としては、Karteの基盤の変遷の話を思い出しました。

少人数でのML基盤としてはCADDiのマネージドな環境を駆使した基盤も参考になると思います。

また、組織やチーム作り自体が大きな障壁になりうる話も頻繁に聞いており、これは研究者的なモデル開発をする人と運用をするdeveloperをチームとしてどう構成すればいいのか、どうやってナレッジや成果物を共有すればいいのか（研究開発部門が子会社など）、チーム作りの課題が浮き彫りになりました。

あとは、機械学習やデータを活用したプロダクトづくりの文化の醸成も、銀の弾丸がない中で各社試行錯誤していることがうかがえました。これは、プロジェクトのKPI設計をビジネスサイドに理解してもらう難しさや、作り切りでOKだった従来型のソフトウェア製品とは違った変化に対応し続ける必要がある機械学習システムの「運用」の理解を得る難しさが課題に挙げられました。

振り返ってみて

企業の事業部門に在籍しながら3年というスパンで学会仕事をするのは、なかなか大変だったなというのを改めて実感しました。COVID-19による社会情勢の変化、海外移住（夏合宿のような長時間イベントは時差的に厳しい）など個人の状況の変化、会社のチームの異動（上司が変わるたびに説得をする必要がある）と、長期的に継続する社外活動というのは思うようには進まないものだなという当たり前のことを感じました。

もう一回程度、事例共有カンファレンスがしたかったですが、最近ではでそういった話が日本語でも展開されているので、そちらにも期待です。

今後について

今後は、（我々も事前にすり合わせたわけではないのですが）ちょうどをはじめとする皆さんがこの夏合宿から開始した、に引き継がれていきます。今後の活動が楽しみです。

過去の活動の様子

kawasaki.rb 9年の歴史を振り返って

Sat, 18 Jun 2022 13:25:00 -0700

これは、kawasaki.rb 10周年突入LT大会に際して、kawasaki.rbの9年の振り返りです。

もともとは、これの話をする予定でした。

第一回開催 (2013)

初回からPythonの話だったりRubyコミッタによるC言語とGCの話だったり、多様な言語の様子が見て取れますね。これは狙っていたところでもあり、言語非依存なRubyコミュニティというある意味矛盾した存在意義を打ち立てるのに成功したのかな、と思います。

元々は、asakusa.rbちょっと~~ガチで近寄りがたい~~みたいなところもあり緩い場として始めましたが、まあ結果オーライということで。

迷走期 (第2～6回)

ミューザ川崎の会議室で定期開催するかと思いきや、隔月で居酒屋でLTをするという企画をしていました。焼肉しながらLTするというハードな企画ものもありました。

第7回 NTT-ATさんの会議室で安住の地を得る (2014)

長い間お世話になっていた、NTT-ATさんの会議室で開催することができました。

なお、NTT-ATさんの関係者の方々に教えてもらって、川崎駅ので懇親会を開催するようになり、紹興酒が定番のお酒になりました。これが、オンライン懇親会も仮想狸で行われるようになった所以です。

第8回パーフェクトRuby読書会をはじめる (2014)

yokohama.rbでの読書会をヒントに、楽して安定的に開催をする方法を獲得します。それまでは、主催者がLTの登壇者を一生懸命募り、なさそうなら自分が発表するというストロングスタイルをしていたのですが、この時から安定して開催する目途が立ちました。

音読してライブコーディングをしながら突っ込むというスタイルは、賛否両論あるかとは思いますが、主催側にとっては福音でした。

しかし、ツッコミながら読み進めるスタイルは、深く突っ込んだ議論ができる反面、一回で1ページも進まない事態も生み出すのでした。

Ruby Kaja (2014)

Ruby Hirobaというイベントでコミュニティの貢献者を表彰するという取り組みがありました。この当時の地域Rubyコミュニティの数の多さがうかがい知れます。

第18回 N周年 LT大会を発明する (2014)

今でこそ定番になったN周年記念LT大会が始まりました。これは日本で一二を争う緩さのLT大会として有名で、スライドを東海道線でiPhoneで作る人や、ブログで話す人、果ては手ぶらで写真だけで話し始める人など様々でした。

LT大会を重ねていくと様々な報告も受けることになりました。

神奈川 Ruby 会議 01 (2015)

yokohama.rbさんと共同で初めての地域Ruby会議を行いました。ペアプロ大会は、出題を鍋谷さんにお願いして企画しましたが、ほかにないもので盛り上がりました。

初心者からコアな人まで楽しめるようにと、エモい回にしたのですが、あとから歴史を振り返ってみるとRubyConfなどのエモさからコアな内容に振ったRubyKaigiへの流れに逆行していましたね。まあ、無知というのはある時何かを生み出すこともあります。

川崎 Ruby 会議 01 (2016)

名前は変わりましたが2年連続で地域Ruby会議を開催していました。よく考えるとすごい。

mameさんの基調講演Rubyによるファミコンエミュレータの話に始まり、C#、Scala、Roomba、Rails、サーバレスの話など多岐にわたるテーマでした。

主催者打ち上げで、松田さんが紹興酒をカメでたのんだり、二次会のハードロック居酒屋の思い出が懐かしいです。

第47回ミューザ川崎に戻る (2017)

諸般の事情から、NTT-ATさんの会議室からミューザ川崎へと拠点を移しました。移転してしばらくしたらWiFiも使えるようになって、電源もプロジェクターも借りられていたのでなかなか良い環境になっていました。

第49回 joker1007さんによるサイン＆じゃんけん大会が行われる (2017)

kawasaki.rbはその遅い長い読書会によって、パーフェクトRubyの売り上げに結構貢献したという自負を持っており、ついに著者の一人であるjoker1007さんが乗り込んできていただいて、サイン本のじゃんけん大会がありました。

第82回 After COVID-19の時代 (2020)

さくっとDiscordで開催をすることで、COVID-19の広がりにも対応してきました。

しかし、kishimaさんの自作ハード/ファーム/ソフト Family mrubyによるテトリスデモは、リモートとは思わせない熱いプレゼンでした。

第89回パーフェクトRuby読書会が終わる (2020)

2014年1月に開始したパーフェクトRuby読書会。ようやくその幕を下ろしました。

進みが遅いのが有名で読み終わったのはでした。丸6年10か月も読み進める間に第二版も出ていたのでした。

第93回プロと読み解くRuby 3.x NEWS を読み始める

パーフェクトRubyの後継として、プロと読み解くRuby 3.0 NEWSを読み始めました。Rubyの最新版についにキャッチアップできるとなって、皆でツッコミながら噛みしめています。

kishimaさん、Ruby Kaigiに登壇 (2020)

kawasaki.rbにもよく参加していただいているkishimaさんが、上述のFamiry mruby の話でRuby Kaigiに登壇されました。別にkawasaki.rbが特別何かをしたわけではないんですが、感慨深い思いでした。（多分コミッター以外の参加者から初登壇？）

第95回創設者、海外逃亡したってよ (2021)

2021年4月から、ファウンダーのchezouが海外に逃亡移住したため、ブログ係としてもずっと貢献していただいていたperanikovさんを中心とした皆さんにバトンタッチをしました。

chezouは毎年節目のLT大会に顔を出すだけのおじさんになってしまいましたが、粘り強く続けていただいて感謝です。

しかし、こんな雑な振りでなんとか回していただいていてありがとうございます。

9年を振り返って

この記事にも書いたのですが、言語非依存な技術系地域コミュニティとして、地理的特性を生かしたkawasaki.rbははじまりました。

これは、kawasaki.rbが拠点とする南武線沿線には電機メーカーが多く工場を構えており、東京都心のスタートアップやいわゆるウェブ系の会社よりもお堅い会社が多かったのでした。

また、始めた当時は「ウェブ系vsエンプラ」「Ruby vs (エンタープライズ）Java」といった対立構造もよくあおられており、「仕事でRubyを書きたい」みたいな人も多かったように思います。今となってはこの対立構造自体も懐かしいですね。

かくいう私自身も、一社目の年配社員に「休日もコード書いてるの？え、まじで？」と言われて、もっと気軽に技術のことについて話したいなぁと思ったことがあり、テックな話の出来る場所としてありがたい存在でした。

その後、時代が進むにつれて、Rubyだけではない地域Rubyコミュニティが表れてきているのが観測されています。やはり、地方では技術コミュニティがそもそも希少なことが大きいのだと思います。業務後にカジュアルに技術の話をできる場所、エンジニア同士の話ができる場所というのは貴重ですね。筆者が顔を出しているも似たような効用を発揮しています。

しかし、COVID-19以降オンライン開催されるようになったことは、善し悪しがありました。遠隔地から気軽に参加できるようになった反面、日本全国のコミュニティとしのぎを削って認知を獲得するという意味ではなかなか大変だなあと感じています。

地域Ruby会議を開催していた時は、やれば認知を獲得できて新規参入を得られるというのがわかっていたのですが、主催のコストはなかなか高く、LT大会を毎年開催するという形に今は落ち着いています。

他にやっていてよかったこととしては、会の開催を省力化して惰性で開催できるようにしておいたことです。これにより、引継ぎのコストが比較的抑えられたのではないかと思います（主観でしかないですが）。

今後もkawasaki.rbの10年目が盛り上がって、ゆるゆると次の10年も進めていけることを楽しみにしています。

おまけ: kawasaki.rbの人気言語は何か？

第1回からのchezouによるの結果、人気の言語（？）をランキングしてみました。

一番人気の言語はRubyでした。ダントツですね。二位はPython、三位はGoでした。

?はどういれればいいんだろうという悩ましいものを入れています。ふんどしとかね。気になる人は元のスプレッドシートを見てください。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

バンクーバーのえんじに屋 #81,82 宇治拾遺物語

Thu, 09 Jun 2022 00:15:00 -0700

バンクーバーのえんじに屋に出演したので、の mazzoさんのように話しそびれたことをメモしていきます。

元ネタはこちら

現職について

もともとは当時CTOだった太田さん直下のMLチームに配属されたが、紆余曲折あってチームが解散し、Audience Studioという主にマーケター向けにCustomer Data Platformを提供しているサービスの開発をしています。RailsでAPI書いたりSQLやdigdagのworkflowを生成したりしています。最近はサーバーサイドKotlinのプロジェクトも関わり始めました。

太田さんの記事はこの辺が直近話題になっていました。

海外移住

よくよく考えてみたら、クックパッド辞めるときに海外で働きたいと思って飛び出たのでした。当時はお家騒動前で海外事業部へ転籍できる人は限られており、今ほど海外へ出向する人は少なかったです。2016年にやめてから2021年だから5年越しに海外移住ができたのでした。それくらいかかるもんですねぇ。

TD入社当時上司だった太田さんに海外移住に挑戦したいと話したときに、「子供が英語環境で育つことで、グローバルな人材になって将来的な選択肢を増やしたい」という話を聞いてその思いを強くしたのでした。

ビザと永住権

永住権周りに関しては（僕はまだ取得していませんが）、元同僚のtakutiさんの記事がまとまっていてわかりやすいです。しかし、入国して1年4ヶ月で永住権取れるのはすごいですね。アメリカだとこのスピードでグリーンカードの取得は難しいでしょう。

永住権（Permanent Residency）は市民権と異なり選挙には参加できませんが、5年毎に更新さえすれば（5年間で規定の日数以上カナダに滞在すれば）いいので長く住むなら取ることになると思います。

カナダのビザのいいところは、本人がsponsorついたwork permitもらえれば、配偶者もOpen work permitを手に入れることができることです。とはいえ、カナダは割と資格重視なところが強く、おとなになってからもcollegeに通ったりして資格を取得する人は多いように見えます。学校のお迎えで話をすると子育てしながら資格を取得して新しい職を得ているという話をゴロゴロききます。

アメリカ企業への就職

Clouderaに誘ってくれたshiumachiさんのこの記事がよくまとまっていますが、英語を使って外資系で働くと給与水準が上がることは大きな魅力でした。Clouderaのときは黙々と仕事をしていたらtotal compensation で前職比1.5倍くらいになっていたのは衝撃でした。

あと、アメリカ企業でちゃんとマネージをするマネージャーの元で働く機会を得たり、多様性を肌で感じたりすることができました。後者は特に自分にとって大きな事で、日本の企業で働くときはどうしてもモノリシックな文化を前提としがちなので息苦しいなと感じ始めています。

英語の勉強法はここで書いたとおりですが、DMM英会話を1年近くほぼ毎日やって、Podcastを聞くという感じでした。

しかし、飲み会で英語がわかるようになったと書いていますが、今思うと完全に嘘でした。「完全に理解した」になっていただけでした（なんもわからん）。

MLエンジニアの転職

自分の話をするよりも、メタに転職する松岡さんの話を紹介すればよかったなと後悔しています。

すべての企業でここまでのレベルが求められるかはわからないのと、”ML Engineer”と言っても企業によって求められるスキルセットがまちまちなのでJob Descriptionをよく読むと良いと思います。

多様性の話

前職の時にまあ色々あった話をしたと思いますが、その時に支えになったのが、エリンメイヤーの「異文化理解力」でした。

こちらに書評があります。

Nakamataさんの回も、多様性の話が聞けてとても面白かったです。

家族がNetflixのクィアアイが好きなので、そういう意味ではリベラル寄りな好みだという自覚はあります。

しかし、自分のpodcastも久しぶりに収録したくなりました。話すのは楽しいですね。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

sqllineage を使って digdag のログから Treasure Data のクエリのリネージを作ってみた

Thu, 05 May 2022 19:58:10 -0700

データリネージとは、DBなどでどのデータがどこから来てどこに行った、という「来歴」とも呼ばれる情報です。

自分がこの言葉を知ったのは、前職でCloudera Navigatorという製品を扱ったときにこの機能が実装されていることを知りました。引き継いだ複雑なSQLなどのワークフローを渡されたときに、どういう流れになっているのかを可視化できるのがとても魅力でした。

Cloudera Navigatorのlineage。 https://docs.cloudera.com/documentation/enterprise/6/6.3/topics/cn_lineage_generation.html より

そんなlineageですが、Pythonの sqllineage というパッケージで分析・可視化できることを知りました。

sqllineage は Pythonで実装されているSQLのlinegaeを解析する部分と、Reactで実装された可視化のウェブアプリケーション sqllineagejs で成り立っています。

実は去年ぐらいにちらほら使っている人がいたのは後から知りました。

これを使ってTreasure Dataのデータの流れの可視化をしてみたいと思ったのですが、TDではちょうどworkflowエンジンのdigdagのログに実行されたSQLが書かれているのに気づきました。

そこで、digdagのTDのSQLを実行する td>, td_ddl> オペレータからSQLを抽出・変換するコマンド、 digdaglog2sql を作り、可視化をしてみました。

詳しい使い方は、GitHubを見ていただければと思いますが、Python 3.7以上が入っている環境であれば、pipで簡単にインストールできます。

pip install --user digdaglog2sql

TDからダウンロードしてきたワークフローのログがあれば、そこからSQLを抽出して保存できます。

digdaglog2sql --input workflow-log.txt --output output.sql

また、ワークフローのSession IDを指定すれば、そこからSQLに変換した結果を保存できます。

export TD_API_KEY=1234XXX/YYYYYYYY
digdaglog2sql --session-id 12345 --site us --output output.sql

また、endpointオプションを使えば自前でホストしたdigdagからもSQLを取得できます。

digdaglog2sql --session-id 12345 --endpoint digdag.example.com --output output.sql

注意点としては、2022/05/05現在のPyPIにある sqllineage とその裏側で依存している sqlparse の最新バージョンでは、 Trino やHiveなどの一部の機能がうまくColumnレベルのlineageの解析ができません。

Note

2022/05/11 現在、sqllineageの Hive, Trino に関する問題は修正され 1.3.5 でリリースされました。これに伴い、sqllineageをsourceからインストールする際に必要だったnodeも不要になりました。

2022/10/06 sqlparseの 0.4.3 もリリースされたので　upstreamの修正はすべて反映されました。

~~今、Pull Requestを出しているところなので、これらがリリースされれば解決されると思います。~~

✅ -> 1.3.5 でリリース済み
✅ -> 1.3.5 でリリース済み
✅ -> 0.4.3 でリリース済み
✅ -> 0.4.3 でリリース済み

~~ひとまず、パッチを当てたbranchをGitHubに用意したので、 nodeをインストールした環境で以下のようにインストールしてください。~~

pip install git+https://github.com/chezou/sqlparse.git@trino#egg=sqlparse==0.4.3.dev0
pip install sqllineage

sqllineageをインストールした後は、出力したSQLファイルを指定すれば、可視化できます。

$ sqllineage -g -f output.sql
 * SQLLineage Running on http://localhost:5000/?f=output.sql

ブラウザを開けば、このようなColumnレベルやテーブルレベルの lineage が作成でき、拡大縮小もしながら眺められます。

SQL lineageの例

ぜひ、試してみてください。

年度途中に海外移住した年の給与・退職所得の扱い

Mon, 07 Feb 2022 18:34:00 -0800

日本法人を年度途中に退職し、海外移住で非居住者になった場合、様々な気づきにくいポイントがあります。

ここでは、その基本を簡単にまとめておきます。

関連する税金の話

支払日が移住後の給与所得、退職所得の扱い

移住後に受け取った給与所得

例えば、3月31日付けで日本法人を退職し、4月1日に海外へ移住、最終月の給与支払いが4月25日に行われたとします（月末締め翌月25日払い）。その時、3月いっぱいの給与は国内源泉所得に当たるため、日本での所得税の課税対象になります。

ただし、支払日が4月なので既に税法上の非居住者の扱いになるため、所得税は20.42%の課税になります。また、退職後の給与、賞与であっても雇用保険料は引かれます。

なお、非居住者になった後の給与所得は源泉分離課税のため、出国前の所得税に関する確定申告（総合課税）とは別になります。源泉分離課税は控除等対象ではなく、引かれて終わりになるため、総合課税の申告に混ぜないように注意してください。

移住後に受け取った退職所得

例えば、3月までの退職金が、4月移住後5月25日に支払われたとします。~~これは受取日が非居住者になっているため、源泉所得税が20.42%かかります。~~

居住者の退職所得であれば、短期間の勤務であれば 勤続年数×40万円 の退職所得の控除が発生します。ですが、非居住者の場合は控除は発生せず何もしないと 20.42% の所得税が源泉分離課税されて終了になってしまいます。

なお、非居住者の退職所得には20.42%の所得税以外が引かれることは通常ありません。源泉徴収票を見て、そうなっていなければ会社に問い合わせましょう。

それでは不公平だというので、非居住者に対して退職所得の選択課税という制度があります。

非居住者の退職所得の選択課税について

非居住者の退職所得に対する不公平感をなくすため、申請すれば控除されて還付される「退職所得の選択課税」という制度があります。これは、自動では適用されず申請すると退職所得の控除が適用されるという制度です。

ただ、相当特殊な話なようで、国税庁のサイトから適切な説明を見つけることはできませんでした。

書き方は、以下のサイトの書き方を参考に確定申告書Bの申告書に「退職所得の選択課税の申告書」という但し書きをタイトル付近の余白に書いて提出すればよいそうです（川崎南税務署談）。

この書類は、分離課税に関する申告書ため、通常の確定申告書とは別に用意する必要があるので注意が必要です。

それぞれ、納税管理人に提出してもらいましょう。

納税証明書を会社経由で申請しよう

一般的に、国内源泉所得については日本に源泉分離課税で所得税を支払うことになります。そのため、その分の所得税を支払い済みであることを居住国（私の場合はカナダ）に証明することで、控除等が受けられるでしょう。

その際の証明には、非居住者の源泉所得税の納税証明書を取得すると英文併記の公的な書面が手に入るため有用です。

詳しくは以下を御覧ください。

基本的にはこの書類が支払金額等の源泉所得税ベースで計算できる、正しい書類となります。

なお、源泉徴収票が間違っていることはままあるようなので、自分で検算して間違っていたら訂正を要求できるような胆力が必要です。

また、国税局電話相談センターの回答も間違っていることが往々にしてあります。結局は納税者自身がどうあるべきかを先に学び、それをもとに納税先の税務署に不明点がなくなるまで確認をするのが良さそうです。また、自分の置かれてる条件はきっちりと説明しないと、想定しなかった分岐が発生するケースもありますので、気を付けてください。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

3ファイル追加してGitHub ActionsでHugoにレコメンド記事を表示する

Tue, 25 Jan 2022 18:41:33 -0800

こんにちは、早いものでもう40の大台が迫ってくる誕生日を迎えました。前日にブースターショットを打ったので、一日中ほとんど寝込んでいました。必要な人のために、を置いておきます。

さて、Hugoにはキーワードベースの関連記事の表示をする機能があります。

しかし、キーワードベースの関連記事も悪くはないのですが、折角なので自分で関連記事のレコメンドをしてみたくないですか？そう思っていたら、さんの Prelims というオープンソースを見つけました。

Prelimsは、Hugo（やJekyll）のFront matterと呼ばれるメタデータの部分にキーワードやレコメンド記事を足してくれるものになります。

レコメンドの方式自体は、今実装されているのは古典的なTF-IDFを用いたコンテンツベースの類似文書を出してくる方式ですが、Front matterを後から処理してレコメンド記事を追加するというシンプルだけどスマートな方法に感銘を受けました。

ただし、Prelimsはflexibilityを重視しているため、例えば日本語のtokenizerやstop wordsなどは自分で設定をする必要があります。

このあたり、ちょっと慣れていないと難しいかなとも思ったので、というCLIツールを作り、config用のYAMLファイルを用意すればGitHub Actionsでrecommendできるようにしました。

用意するものは以下の3つです。

prelims-cli用の scripts/config/myconfig.yaml
関連ページを表示する layouts/partials/page_related.html
prelims-cliを実行する GitHub Actions

実際の例をgistに貼りました。

myconfig.yaml については、 content/blog が英語の content/post が日本語の記事をおいている想定です。この3つのファイルを追加すればHugoであれば関連記事が、冒頭の画像のように出てくるはずです。

内部的には日本語のtokenizerはSuachiPyのfull辞書を使い、最も長いCモードで形態素単位を設定しています。ただし、prelimsが生成する keywords は少しノイジーだなと思ったので、自分のサイトでは recommendations のみを利用しています。

僕はものぐさなので、タグやカテゴリを豆にメンテナンスできないのですが、レコメンドのおかげで過去の関連記事のリンクも出せるので便利だと感じています。また、自分の記事は自分の持ち物なので、それに対してレコメンドしてML的なsandboxとして遊ぶのは楽しいなと感じています。

この環境を使うことで、Netlify CMSでの執筆等Python環境を用意することができないところでも執筆して、レコメンド記事を作成することができます。もしよければ、 prelims を使ったレコメンドを試してみてください。

prelimsを使ってHugoの記事にレコメンドを追加する

Fri, 14 Jan 2022 21:35:00 -0800

シンプルだけど、アイデアは賢いなーと思ったHugoやJekyllの記事にレコメンドを足す、prelimsを使ってみた。

prelimsはなんてことない、TD・IDFでキーワード生成したり、そのコサイン類似度で記事の類似度を出してコンテンツベースのレコメンドを生成してくれるもの。

takutiさんは、gulpでやっているようだっただけど、僕が使ってるHugoのWowchemyに対してやってみた。

実際のcommitを見てもらうのが早い気もするが、JekyllやHugoにあるFrontmatterというメタデータに recommendations というキーワードを追加して生成してくれるというもの。Hugoのビルド自体はそんなに遅くならない、はず（というのは、サイトの相対URLを生成して名前解決はビルド時に行うので、記事数が多くなると重くなりうる）。

ちょっとハードルあるかなというのが、自分で下記のようなPython scriptを書かないといけないところ。まあtokenizerとかstop wordsとかどうすんねん問題があるので致し方なし。

あとは、Hugoの Wowchemyというテーマを使っているけど、 layouts/partials/page_related.html という名前でこういうものをつくる必要があるのです。

{{ if isset .Params "recommendations" }}
<div class="article-widget content-widget-hr">
 <h3>{{ i18n "related" }}</h3>
 <ul>
 {{ $candidates := where .Site.RegularPages "Type" "in" site.Params.mainSections }}
 {{ $rec := apply .Params.recommendations "lower" "." }}
 {{ $filtered := where $candidates "RelPermalink" "in" $rec }}
 {{ range $filtered }}
 <li><a href="{{ .Permalink }}">{{ .Title }}</a></li>
 {{ end }}
 </ul>
</div>
{{ end }}

config.toml には params.mainSections を指定することで、指定したSectionのタイプに対して表示されるようにできます。

[params]
 mainSections = ['post', 'blog']

ゆくゆくはclickかなにかでCLI作ってwrapしてしまうかなぁ。

2021年を振り返って

Fri, 31 Dec 2021 16:05:03 -0800

に引き続き、年末の振り返りです。まだ西海岸時間は2021年です。

なにより、家族でのが大きな変化でした。

仕事

去年とチームは変わらず、場所だけが変わってコツコツと働いています。ただ、組織改編等もあり蓋を開けてみれば元々の東京のメンバー＋西海岸タイムゾーンに一人という状況になったので、だいぶ働き方は変わりました。結果としてスピード感は上がったので良かったかなと思います。

今年もRailsとSQLとdigdagをガリガリと書いているのは変わらず、更には様々なYAMLをRubyで生成するみたいなこともやっています。 DynamoDBの気持ちになって考えたりと少し毛色が違うこともできました。

SEや営業の皆さんと議論しながら仕様に落としていくみたいなことをやっていたので、ほどではないけど、現実的な落とし所とお客さんの必要な物とを抽象化していくみたいなことを楽しんでおります。

西海岸タイムゾーンで仲間が増えると僕が嬉しいので、興味のある方はご連絡お待ちしております。

副業は、上に書いたとおり東京とのやり取りが平日増えて、オーバーラップタイムが多くなったので、後半は何もできない状態になってしまいました。このまま不義理を果たし続けるのも良くないので、来年はちょっと枠組み変えていきたいなと思います。

執筆など

怒涛の一年だったので忘れていましたが、。

執筆当時はML Opsはだいぶふわふわしてるかなぁと思っていたのですが、その後1年でだいぶ戦うエリアが固まって来たのかなぁといういみでギリギリ間に合ったという印象です。

また、嬉しいことに他の人の人生に少なからず良い影響を与えることができたようなので、出してよかったなと思います。

「仕事ではじめる機械学習」は広く問題を見直したいときによく読み返しています、何度読み直しても良い本ですね！
コミュニティへの貢献がつながったのは計算してこうなったのではなく、あとから見返すとこうなっていたというものなので、振り返りをやってよかったと思います
— 龍一郎 (f.k.a Asei Sugiyama) (@K_Ryuichirou) December 30, 2021

なお、ML Ops界隈でご活躍されている @K_Ryuichirouさんのこの振り返りは良かったので、ML Ops界隈の人は是非読むといいと思います。

しかし、執筆のない年越しは穏やかなものですね。

プライベート

あとは、お金のトラブルに悩まされる一年でした。増えるはずだったお金が消えそうになったり、もらえるはずだったお金が突如なしになって最終的にはダマで2割引されたり、源泉徴収された所得税がなかったことになってるぽかったり、税率多く取られてたり、、、。¹

その度に関係者に殴り込みにいったり、国税局に電話したりと様々なことをしていましたが、お金の基盤が揺らぐと安定なんて軽く吹っ飛びますね。

MLSEに関してはドタバタだったので、大きな貢献があまりできずに終わってしまいました。来年は締めの年なのでそこに向けてがんばります。

移住関連に関してはこの記事に書いたので、興味がある人は読んでください。子供が落ち着いたのが本当に良かった。

趣味や漫画、アニメ

趣味というほどではないですが、YouTubeにGoProで撮った車載タイムラプス動画や自転車動画を上げてます。カラグレまでは至らないけど、それでも楽しいです。

見る方でもYouTubeは色々見るようになりました。

ドラクエ3のチーフプログラマの内藤かんチャンや

AIciaさんの動画なんかを見ています。

他にも、Duolingoでフランス語をぼちぼち続けています。

漫画は去年紹介した6冊のうち、元々アニメ化していたものも含めて4冊がアニメ化した・するということで、メジャーなものしか追っかけてないのかなという気持ちです。

Landreaallと最果てのパラディンは、個人的に大好きなファンタジーの双頭なので今後も元気に続くといいなと思います。

毛色が違うところでは、この辺は面白いです。

もし、第二次大戦後に東京がベルリンのように東と西で分断されたら、という世界を描いた作品。独特の世界観が惹き込まれます。

地政学の知識を活用して様々な問題を解決していく、令和のマスターキートンみたいな漫画。

ファンタジー系でいうと、バルドローエンも渋いおっさん好きにはたまりません。

アニメは色々と豊作でしたが、最果てのパラディン、ブルーピリオド、本好きの下剋上、無職転生、蜘蛛ですがなにか？、転スラ、灼熱カバディ、ドラゴン家を買うなどを見ていました。

アニメではありませんが、水曜どうでしょうのヨーロッパ21カ国完全制覇を通しで見ました。ついにアイルランドにたどり着いたときは感激でしたね。自分の価値観と大きく違うんだなぁという認識ができたのもよかったです。

2022年に向けて

ドッタンバッタンと変化の激しかった一年だったので、来年は落ち着いて精神と肉体の健康第一で行きたいと思います。

今はもうそれらの問題を引き起こした原因はいないので、今後は新たな問題は起こらないはず…。失ったお金は投資で取り戻すかな…。 ↩︎

バンクーバーに移住して8か月が経った

Fri, 17 Dec 2021 07:00:00 -0800

この記事はの18日目です。昨日はのリンゴの話でした。

今年も早いもので12月になってしまいました。

実は6月にもkawasaki.rbでこんな話をしていたのですが、今年4月にグレーターバンクーバーエリア（東京圏みたいな感じ）に家族で移住したので、ぼちぼちと一年振り返って生存報告を書こうと思います。

カナダもリンゴの種類は豊富で、毎日食べてます。酸味が多い種が多く売られていますが、フジなんかもこちらで栽培したものが手に入ります。

四季が豊か

春はあちこちに植えられた桜がお出迎えしてくれましたが、（熱波も来たけど）30度を超えることがまずない乾燥した爽やかな夏、色とりどりの紅葉がきれいな秋、たまに雪が降る冬と、とても変化がはっきりしています。東京より少し寒い地域にいるのとあまり変わらない感じですね。

Spring

Summer 1

Summer 2

Fall 1

Fall 2

Winter

インターネットは速い

Shawというケーブルテレビ系のネットを使っていますが、1GBの契約で900Mbps前後出るので結構速いです。先日、gfx氏の奥さんのお勧めするtp-linkのdeco AX3000にしたら無線でも800Mbps台出ました。

deco AX3000

ビールはおいしい

スライドでも書きましたが、ビールはあちこちにクラフトビール屋さんがありおいしいです。

さんのこの記事を見ると、より雰囲気がわかるんじゃないでしょうか。

また、BC州では酒屋じゃないとアルコール飲料が買えないこともあり、ノンアルコールビールもよく売っています。 basukeさんがお勧めしてるノンアルコールビールAthletic Brewingも Amazon.ca で買えるし、クラフトビールのノンアルコールビールもあります。

料理をするようになった

バンクーバー周辺ではリッチモンド市を中心に中国系コミュニティが強いです。そのおかげもあり、T&Tというバンクーバーを拠点とするアジア系スーパーがあちこちにあり、日系スーパーにいかなくても日本の食材も比較的手に入りやすいです。

野菜の違いに最初は戸惑ったものの、カボチャがKabochaとして売られていたり、さつまいもも日本からの輸入やKorean YamとかAsian Yamとか呼ばれて普通に売っています。

また、賃貸の家に大抵ガスオーブン（ないしは電気でそれに相当するもの）がついているため、bakeするのはとても楽です。

Tortia Pizza

トルティーヤ記事を使ったピザ( )。サルサソースやワカモレ、トルティーヤチップなどメキシカンの食材も豊富なのが楽しい。

Sanma

日系スーパーでサンマを買って焼いた様子( )。これもガスオーブンでいい感じに焼ける。

Home made humburger

チーズをとけさせるのを忘れたお手製ハンバーガー。ハンバーガー用の冷凍パティとパンを買ってきて挟むだけのお手軽品。

karaage

エアフライヤーで揚げた唐揚げ( )。こっちだと肉は塊でドンと売ってることや、油を固める製品が高いので、エアフライヤーでトンカツや唐揚げをしてる

Air fryer

ティファールのエアフライヤー。中を見てみると電熱線とファン、そしてアナログタイマーというシンプルな一品。

あと、こちらはベジタリアンやヴィーガンの人も多いため、乳製品の代替食材が豊富です。例えば、アーモンドミルクやカシューナッツのアイスなどが比較的手ごろな値段で手に入ります。なので、コレステロールが気になる人としては大助かりです。

時差は大変

今のチームのメンバーは東京に結構いるので、時差を考慮した働き方は割とすぐに体調を崩したりしてしまいがちです。月曜から木曜は日本とオーバーラップしている時間帯を長めにとりたくなるけど、朝は学校の送りもあり起きる時間はずらせないので、ペースを作るまでが大変でした。

ある時、同僚から月～木は少し遅めまで働いて木金の勤務を少し短めにしているという話を聞いて、今は金曜日勤務する時間を短めにしています。このスタイルにするようになって、だいぶ肉体的にも精神的にも負荷感が減ったかなという感じです。

家賃は高い

家族4人で住むのに、押し詰めて2 Bed Rooms、仕事部屋も確保しながらだと3 Bed Roomsの部屋くらいはほしいところですが、Vancouver市内で。

Greater Vancouver Areaは海に近いVancouver City, North Vancouver, West Vancouverは高く、Burnaby, New Westminster, Surrey, Coquitlam東の内陸部に行くほど安くなっていきます。そもそも、賃貸では2BRまでの物件が多いことに加えて、コロナ下で郊外の広めの家の需要が増えたため、家族住まいによい部屋を探すのが大変です。

家の値段はずっと横這いだったのが上昇し始めたので、できればさっさと買ってしまいたいものです。が、戸建ては8 Bed Rooms 10 Bath Roomsとかで1M CAD以上からスタート、マンション的なコンドも900K CAD前後が多いので、まとまったお金を得ないと厳しそうです。

家を借りるのに保険が必要です。うちはSquare Oneを使っていますが安くて良いです。こちらのから見積もりをすると$10のアマゾンギフト券が手に入るそうです。

医療費は基本タダ

MSPと呼ばれる皆保険に入るのですが、これに入っていれば医者の診療は無料です。薬代はかかりますが、会社のextended health careを使うことである程度帰ってきます。その代わり、予約をして待つ必要があるため、日本のようにふらっと立ち寄ることがしにくいです。walk in専門の病院もCOVID-19の時勢で原則予約必須になりました。

子供がいる家庭としては医療費には結構敏感なので、結構助かっています。

なお、歯医者やレーシックの治療なんかはお金がかかるので、なんでもかんでもただというわけではありません。

小学校も無料

小学校に上がる前のday careは結構高いようですが、小学校では保護者がwork permitを持っていれば学費はかかりません。日本でいう高校までかからないので、助かりますね。

なお、英語が全く話せなかった子供も、10か月経った最近になってようやくクラスの子とやり取りができるようになってきて、学校生活も落ち着いてきたように思います。上の子は授業でフランス語も始まっているので、英語に加えて少し大変そうです。

バスや電車も子供の料金が今年無料になり、BC州は子育て支援を加速しており子持ち世帯には優しいように感じます。

子連れ移住については別途まとめたのでこちらを見てください。

夏は日が長く冬は短い

Deer lake

緯度が高いけれど、夏の気温は30度いかない程度、冬も下は0度前後とカナダの中でも過ごしやすいVancouverですが、日照時間はかなり変化が激しいです。

夏は夜9時半くらいまで空が明るいため、近所の公園で子供が遊んでいる声も聞こえてきます。一方、冬になると朝8時になっても日が昇らず、4時には日が落ちます。そもそも、冬は雨期のため日が出る日が少なく週に一回でも雨が降っていなければテンションがあがります。

外に積極的に散歩に出かけるようになったり、公園や山に子供と一緒にハイキングをするようになったりと、今までとは違うことをいろいろチャレンジして楽しいです。そして、今になって夏の大切さをかみしめています。

Light house park

とはいえ、今年は夏の40度近くまであがるheat waveや、先月にBC州内陸部で起こった洪水など、今までとは違うことがいろいろと起こっているのを感じます。

振り返ってみて

保険の面や教育の面で、アメリカよりも子育てがしやすいと思ってカナダに来ましたが、思った以上に楽しんでいます。特に、食の面が東京ほど安くはないですが充実しており、自分としてはよかったと思っています。

また、このエリアはAsianの比率も高いため、多様な文化に触れながらもある種の安心感もあります。

実は、今年1月にビザ申請を提出して移住をしたわけですが、11月には永住権の申請も出すことができました。まだ、結果の受け取り待ちですが、アメリカに比べてもSoftwareを生業としている人にとっては、ビザも取りやすく移りやすい国だと思います。取得出来たら、また時間を見つけてtimelineを整理していきたいと思います。

明日はです。

カナダのバンクーバーエリアに子連れ移住した

Wed, 15 Dec 2021 13:01:00 -0800

この記事は、「」のスピンオフである。

「バンクーバーエリア」と書いているのはいわゆるGreater Vancouverと呼ばれる場所に住んでいる（具体的には隣のBurnaby）けどわかりやすいのでそう書いている。（神奈川県民だけど横浜らへんに住んでるという感じのあれ）

移住タイミング

日本の学校の年度が切り替わる2021年4月の頭に移住をした。これは学年が変わると諸々大変だろうなと言う思いからそうした。結局、2週間の隔離や家探しをしていたおかげで現地のelementary schoolに通い始めたのが5月の頭で6月末にはこちらの学校が終わってしまったので、慣らし運転という感じになった。

子連れ隔離生活

隔離の条件は情勢によって様々変わるだろうが、自分のときは2021年2月に急遽カナダ政府が14日隔離のうち冒頭3日間は政府指定ホテルを確保しろという今思えば一番厳しいときで、バタバタだった。

最初3日間は政府指定ホテルに宿泊、その後別のホテルで11日間宿泊するという流れだった。

教訓としては、窓の開かない部屋で14日間子供と一緒に生活すると、親も子も共に発狂しそうになるということであった。ホテルでは外の空気を吸うことができないのが息苦しく、また子供もちょっとでも退屈になると親を呼び立てるという状況であった。最初のホテルは広くて日当たりも良好だったが、一部屋全部つながっており常に子供と対峙する必要があり気づかれをし、後半のホテルは二部屋あるが一部屋は陽が全く当たらない部屋だったのでテレビを常に付けて明かり代わりにしていた。

事前の対策としては、takuti氏のこのブログを穴が空くほど読みこんでいた。

インスタントの食料なども含めて荷物の輸送には、プラ段とキャリーカートが良かった。

あと、人間の数以上のPCやiPadを持ち運ぶために、各自リュックを用意して機内に持ち込んだ。

洗濯はホテルの部屋で家族4人分を手洗いするのがなかなかハードだった。元CAのブログなどを読み漁って実際役に立ったのは、セームタオル。洗濯物をこれに包んでシャワースペースで踏むと脱水ができる。めちゃくちゃ吸水して絞ればすぐに乾くので必需品。

その他、携帯ハンガーと物干しロープを持っていった。ロープはかけるところがあるかどうかは賭けだが、折りたたみハンガーは非常に重宝した。

エンタメとしては家族で3台のSwitchを持っていき、現地でリングフィットアドベンチャーをやるつもりだったが、荷物預かりの部屋にリングコンを入れっぱなしにしてしまったので、フィットボクシング2を購入した。やはりフィジカルに体を動かすのは非常によく、これを買ってから子供も親も落ち着きが増した。

薄手のヨガマットはホテル生活にあると運動もストレッチもできるのでかなり便利。

Chromecast with Google TVは、ホテルの無線LANの認証もブラウザ経由で突破できるため、非常に重宝した。これのおかげでNetflixで無限にジブリを子供が見たため、今では僕よりジブリ作品のカバー率が高い。

家＆学校探し

子連れでの家探しとはすなわち学校探しのことでもある。

市や州にもよって学校の年度の切れ目が違うようだが、と呼ばれる期間、幼稚園、elementary school、secondary schoolに通う。子供が通っているelementaryはGrade K,1,…とはじまり7まである。年齢的には日本の1年生がGrade 2になる感じで1 grade上になる。

バンクーバーエリアでは現地の公立小学校（elementary school）に入るしか選択肢はなく（あとはホームスクーリング）、通うとしたらどのあたりの小学校が良いかというのを検討した。

公立のelementary schoolはcatchment areaと呼ばれる学区があり、住む場所が決まると自動的に学校が決まる。ただし、越境通学も教育委員会から許可が下りれば可能らしく、そこはネゴシエーションの世界のようだ。この国は何でもネゴシエーションである。

具体的にはSchool Rankingサイトでスコアが高すぎず低すぎず（以下のサイトで6〜7.5くらい）のところを見つけて、その中でESL率が相対的に高く、Special Neesもそれなりに割合が高く、French Immersionが高くないかを調べた。また、可能であればアジア人の割合も調べた。

というのも、

ESL率が低いとnativeしかおらず英語が全くできないうちの子供への対応が手薄になるであろう
French Immersionもフランス語に特化していると、いきなり英語とフランス語を同時に習得するのは厳しいだろうしESLへの配慮が薄いかもという危惧
Special Needsが低いと学校としてそういう子を受け入れない方針だったりする可能性があるだろいうという危惧

を考えていたからである。（実際、別の小学校のKinderに入れようとしたら発達に問題があるかもとか言われて断られたから学区を越えたという話も聞いた）

アジア人の割合が高いと良いと感じているのは、「当たり前」がそれぞれのルーツの数だけあるであろいうという目論見からであった。ランチや各自持ち込むおやつの時間での食べ物に対するいじめや偏見が少ないだろうという予想もあった。実際、韓国のりをおやつに持ち込む子もいて、今までで不評だったのは食べる煮干し（魚の頭が残ってるから？）とナッツ入りのお菓子（ナッツアレルギーの子がいるため）くらいであった。

ちなみに、ランチは学校で注文することもできるが、ピザとかそういう感じなのでおにぎりとおかずを小さい弁当箱に詰めて持たせている。ランチが終わると昼休みは雨でも雪でも外に駆り出されるので、防水の靴や長靴、上から履くレインパンツは必須。

家のタイプは、一軒家、コンドミニアム（いわゆるマンション）、タウンハウス（縦長の長屋スタイル）が主にある。高層階のコンドミニアム以外は基本的に木造で、日本よりも古めの物件が多いことも有り上の階の足音が普通に聞こえる。これは日本では普通やる吸音材などを床下に入れないためらしい。なので、子供の騒音が気になるなら高層のコンドミニアムか（階下に人がいない）タウンハウスが良いかもしれない。こっちに来て驚いたのが一軒家の地下階や二階だけを賃貸に出すというのも多いので、そういうスタイルの場合は騒音トラブルはそれなりにある様子。

なお、家を借りるときは大抵Home Insuranceに入っていることが求められるのだが、同僚などに聞く感じ Square Oneがネットで申し込めて安いのでよく使われている。以下のURLから見積もりをすれば$10の、契約をすれば$25のAmazonギフト券がもらえるのでよければ使ってみてほしい。

あと、家を借りるときは半月分のSecurity Depositを払うなどまとまったお金がいるので、もしカナダの銀行にお金が入っていなければ、Wiseを使って日本から送金するとよいだろう。以下のリンクから申し込みをしてくれると手数料も無料になるクーポンが発行される。

なお、BC州ではドライバーズライセンスを手に入れる時に日本の免許証を渡さないといけないのだが、Wiseの初回送金は本人確認で住所記載欄のある古いパスポートか免許証が必要なため、試しに一度送金しておくと良いだろう。（でないと、パスポート更新で詰む）

英語

子供によって合う合わないがあるので、一概には言えないのだが、我が家の場合はラッキーなことに移住から8ヶ月経った今は子どもたちは英語にかなり慣れてきている。

我が家の場合、新学年がはじまったばかりの9月くらいまでは学校行きたくないと泣きわめくことも多かったが、年度が変わるとELLと呼ばれる英語初学者向けの授業などサポートが安定し、また学校の校庭が公園になっており、そこで遊ぶ友達も何人かできたためぐんぐん吸収している。

日本では、特段英会話の教育を熱心にしていたわけでもない。妻がやの動画をYouTubeやNetflixで見せていた程度だ。

セサミストリートは、主に文化面での多様性に関する話がふんだんに出てくるのがよく、色んな国のlunchの話だったりが出てきてこちらの学校に移ってもすんなり受け入れることができたと思う。

Alphablocksはいわゆるフォニックスのルールをキャラクター化されたアルファベットと一緒に学べるのでおすすめ。

なお、妻は英語には抵抗はなく学校の他の保護者との会話も妻のほうが良くしているので、そこは楽をさせてもらっている。（怪しい人じゃないと主張するためにお天気会話をすべきとよく言われる）

医療費と健康保険

カナダは健康保険については国民皆保険（MSPと呼ばれるプランに入る）なので、病気や怪我など病院での治療は基本無料で受けられる。ただし、歯科や眼科はお金がかかる。視力検査は子供は年に一回まで無料なので、学校で視力検査がない代わりに自分で行く必要がある。

MSPについて子供は、study permitを持っている場合international student扱いになり、BC州ではMSPのお金として月に75ドルかかるので注意が必要。永住権を取れればこれが不要になるので結構大きい。

教育資金の積立

カナダは、子供の教育資金の積立にRESP (Registered Education Savings Plan）というものがある。これを使うと拠出金額の20%マッチングしてくれたり、税制上の優遇がある。BC州は9歳までに申し込むと。

なんだけど、study permitだとSINと呼ばれるマイナンバーのようなもの（税金を払うための番号）が子供に発行できないので、永住権を待たないといけない。

なお、RESPの他にもRRSPやTFSAなど子供には関係のない税制優遇されている投資口座があるので興味があれば調べてみると良い。

子供向けのイベントがたくさんある

自然が豊かなカナダなので、ハイキングやらバイクパークやら楽しむことは色々ある。そして、北米ではよくあるイベントとして、パンプキンパッチと呼ばれるハロウィンのかぼちゃを農場に行って拾ってきたり、いちご狩りも一大イベントである。クリスマスツリーを買ってきて飾り付けなんかもする。

Michaelsと呼ばれる、creative系のあれこれが安く売ってるお店に行けば、絵の具やらオーナメントやら色々手に入るので、創作が好きな子供にはぴったりだろう。

クリスマスは一大イベントで、街中が飾り付けされている。

学校でも、今日はXXデーなので、何色の服を来てきてください、とかパジャマデーなのでパジャマで投稿してねとか色々ある。色指定の服はMichaelsで様々な色のシンプルなTシャツが売ってるのでそれで済ませるとよい。

習い事

市のスポーツセンターでは、水泳教室やスケート教室が安く開催される(水泳教室は$3以下で8週)ので、皆それに行かせるのが多いよう。友人のお家では空手教室に通ってたりすると聞く。

厄介なのが、水泳教室の募集開始時は一斉にウェブで予約するので、複数端末からアクセスして予約合戦を繰り広げる必要があるところ。

スケート教室なんかは少し遠いところで開催されたりするので、住んでる場所にもよるが車があったほうが送り迎えはしやすい。けど、バンクーバー近辺は北米で最も優れた公共交通機関とも評されたTransLinkが運用する鉄道やバスがある（酷い遅延はあまりなく、バスは予定より早く通り過ぎることもある！）ため、住む場所によってはそれらも使いこなせるだろう。

日用品の買い物

子供の服や文房具などの消耗品は、Metrotown駅にあるカナダで二番目に大きいモールのMetropolisに買いに行く。ユニクロも無印もZaraもH&Mもなんでもある。消耗品はWalmartにいけばいいし、日本の文房具をメインに扱うお店もある。

防水のジャケットやブーツは、Mountain Warehouseというカナダのモンベルが安くて品質もそれなりに良いのでそこで買っている。やはり、ブラックフライデーが一年で一番安いようだが、もともとはカナダにはブラックフライデーの文化はなく、Common Wealthの国として12/26のUnboxing dayがセールの時期だったらしい。

ちなみに、北米は返品文化と言われるが、Amazonで頼んだものが既に壊れてるとか動かないみたいなのは日常茶飯事なので、返品がカジュアルに行わているという実感。

そうそう、Amazonで思い出したが、日本の感覚でAmazonで買い物をするとたまに混乱することがある。例えば、東海岸から発送されるので1週間くらい平気でかかることもある、とかPrimeマークついてるからと油断すると、アメリカや日本から届いて1-2週間かかるとか。広大な国土を持つと輸送には時間がかかるんだなあと思わされる。

なお、PCやデジタルガジェット系は日本より入手が非常に難易度が高く、中国系の製品がアメリカでは売ってるけどカナダでは売ってないということも多いので、必要であれば日本で買うのが良い。

8ヶ月目での所感

学校が一クラス20人しかおらず、授業も日本よりも自由にのびのびとやる感じ（教科書も配布されないし先生の裁量次第）みたいなのもあって、こちらの生活に想像以上に馴染んでいる様子。日本の学校ではCOVID-19後、様々なトラブルがあったのだが、カナダの先生はメールで困りごとを連絡するとさっと対策をしてくれたりするので非常に助かっている。

このまま大きな問題もなく成長してくれることを願うが、おそらく学校とのタフなネゴシエーションはどこかで発生するだろうという心づもりで生活をしている。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

日本国外で出版社と取引をする際の所得税の源泉徴収の扱い

Tue, 09 Nov 2021 17:40:00 -0800

⚠️ この記事は2021年11月段階で体験したことに基づき書いています。この情報は、あくまで参考程度に止め、原則的に税に関する不明な点はに電話して確認してください。

私はカナダに居住をしており、日本の税務的には非居住者となります。カナダは日本と租税条約を結んでおり、源泉徴収が必要なケースでも日本に支払う所得税の軽減をすることができます。

今回は、出版社との2種類の取引をするにあたって、カナダ在住の私が調べて実施した源泉徴収の扱いとそれに伴う手続きをこの記事にまとめます。

私がした取引は、以下の2つの種類の取引をしました

書籍の印税（著作物の使用料、いわゆるロイヤリティ収入）
書籍の有償での校正

これらの取引が、どのように源泉徴収されるべきか・されないべきかを書いていきます。

重要なソース

以下の手引を一通り読むと良いでしょう。ここに書いてあるのは令和3年度版なので、年度が変わると法令が変わる可能性があります。

令和3年度版源泉徴収のあらまし第10 非居住者又は外国法人に支払う所得の源泉徴収事務
租税条約に関する届出書等の電磁的提供に関するFAQ

重要なポイント

そのという点が最も重要なポイントになります。

非居住者か？
所得が国内源泉所得か？

「源泉徴収のあらまし第10 非居住者又は外国法人に支払う所得の源泉徴収事務」より。個人の非居住者は、国内源泉所得の場合にのみ源泉徴収の対象となる

上の表を見ると、非居住者でかつ国内源泉所得である場合において源泉徴収が発生することがわかります。この書類は源泉徴収対象外の場合がわかりにくいので気をつけてください。ではこの2つの要件を見ていきましょう。

非居住者か？

非居住者とは、国税庁のによると

我が国の所得税法では、「居住者」とは、国内に「住所」を有し、又は、現在まで引き続き1年以上「居所」を有する個人をいい、「居住者」以外の個人を「非居住者」と規定しています。

となります。

この「住所の推定」は以下の別紙によると、2つの要件のどちらかに該当するかで判定します。

その者が国外において、継続して一年以上居住することを通常必要とする職業を有すること
その者が外国の国籍を有し又は外国の法令によりその外国に永住する許可を受けており、かつ、その者が国内において生計を一にする配偶者その他の親族を有しないことその他国内におけるその者の職業及び資産の有無等の状況に照らし、その者が再び国内に帰り、主として国内に居住するものと推測するに足りる事実がないこと

私の場合は、日本国籍なので2は関係ありません。1に関してもソフトウェアエンジニアは一般的に継続して一年以上居住することを通常必要する職業であり、非居住者の判定ができそうです。

国内源泉所得か？

「国内源泉所得」というのは、「源泉徴収のあらまし第10 非居住者又は外国法人に支払う所得の源泉徴収事務」にも以下のように記載されています。

課税対象とする所得をその所得の発生源泉地が国内にあるもの、いわゆる国内源泉所得に限ることとしています。

実際には、判定に関する条件として以下の2つがポイントとなります。

恒久的施設を持っているか
その所得の区分は租税条約上、課税対象となっているか

恒久的施設

恒久的施設は、ざっくりいうと日本に商売をするための拠点を持っているかということなのですが、これ自体で一つの記事が書ける類のものなので、割愛します。少なくとも、日本国外で執筆活動を行い日本の出版社と取引をしていている人は持っている可能性は低い（例えば、実家は特に恒久的施設とはみなされない）ので、調べて見てください。

租税条約上の課税対象か（印税）

所得の区分に関してですが、印税（著作権使用料）は「使用料等（十一号所得）」となります。これは、租税条約を結んでいる国によって扱いが異なってきます。

以下の引用した表を見ると、アメリカの場合は源泉地国免税のため日本では免税、カナダは債務者主義を取っている国になるため、日本の出版社との取引の場合は日本にて源泉徴収がなされます。ただし、カナダの場合は租税条約により最大10%までの軽減税率が適用されます。

「源泉徴収のあらまし第10 非居住者又は外国法人に支払う所得の源泉徴収事務」より

租税条約上の課税対象か（校正作業）

校正作業の場合は、一般的にその作業によって著作権がレビュアーに発生しないため、人的役務の提供（サービスの提供）という扱いになります。この所得は「人的役務の提供事業の対価（六号所得）」となります。

この場合、租税条約の多くは恒久的施設がない限り、原則として日本の租税は免除されることになります。

つまり、この作業をした場合源泉徴収は行われません。もし、源泉徴収がされてしまった場合は後述の誤納額の還付請求を行います。

実際の手続きは何をするか

著作権使用料に関する手続き

著作物の使用料に関しては以下の書類を源泉徴収前に出版社を介して提出します。

源泉徴収前で、支払いまでに手続きが間に合いそうな場合
- 使用料に対する所得税及び復興特別所得税の軽減・免除（申請書名「租税条約に関する届け出書（使用料に対する所得税及び復興特別所得税の軽減・免除）」
源泉徴収後
- 租税条約に関する届出書
- 租税条約に関する源泉徴収税額の還付請求（申請書名「租税条約に関する源泉徴収税額の還付請求書」）
  - 出版社側で「源泉徴収納付書の控え」が必要（取得に時間がかかるので要注意）

これらの租税条約に関する書類の提出は令和3年から電子的にPDFで提出が可能となりました。

以下の書類に詳しいですが、

電子署名を行い電子証明書を付す
源泉徴収義務者から通知された識別符号（ID）及び暗証符号（パスワード）を用いる
源泉徴収義務者に届出書等提出者等確認書類を提示する

とされています。

電子署名はハードルが高いので使わず、提出者等確認書類も領事館などで「居住者証明」の取得が必要となり、こちらの取得の金銭的・人的コストがかかるため、IDとパスワードによる提出を行いました。

こちらは、出版社にIDとパスワードを発行してもらい、それをもとにPDFのファイル名のprefixにIDを付与して(GivenId_tax_refund.pdf)、複数書類あったのでzipにパスワードをかけて送付しました。IDとパスワードの使い方・管理方法については特に法令での指定はないようです。

また、合わせて滞在国でtax returnをする際に源泉徴収済みであることを示す納税証明書を、出版社に依頼して取得しましょう。

源泉徴収に係る所得税及び復興特別所得税の納税証明願（申請署名「源泉徴収に係る所得税及び復興特別所得税の納税証明願」）
- 出版社側で「当該源泉所得税及び復興特別所得税を納付した際の所得税徴収高計算書の写し」として「源泉徴収納付書の控え」が必要（取得に時間がかかるので注意）

人的役務の提供に関する手続き

もし、印税以外の人的役務に関して源泉徴収されてしまった場合は、以下の書類を出版社に提出するよう依頼します。

源泉所得税及び復興特別所得税の誤納額の還付請求

💡 消費税は非居住者が海外で作業した場合は免税になります。そのため、消費税の請求はしないようにしましょう

困ったら国税局電話相談センターに電話しよう

日本で雇っている税理士がいればもちろんその方に相談すればよいのですが、困ったらに電話しましょう。出国時に所轄税務署が決まると思いますので、そこに電話をして問い合わせます。担当の税務署に一度電話をかけて、1→ 1(所得税)または2(源泉徴収等)を選びます。

出版社もこうした作業はたまにしか発生しないため、その時々の法令の改正についていけないことが多いです。また、申請をしないと間違った納税をしたときに二重課税になる恐れがあります。自分で調べて電話相談センターの人から得たアドバイスをもとに進めると、円滑に手続きが進むと思います。

なお、難しい問題の場合電話の折り返しがありうるため、日本との電話は楽天モバイルと楽天ミニがとても役に立ちました。

記事が気に入ったらbuymeacoffeeでサポートしていただけると嬉しいです

オライリーから「仕事ではじめる機械学習第2版」を出版しました

Sat, 24 Apr 2021 16:48:57 -0700

Table of Contents

4/23に「仕事ではじめる機械学習第2版」をさんとさんとともに出版しました。電子版は、Kindleでは購入できない ¹ のでぜひからDRMフリーのPDF、EPUBをご購入ください。

コードは今回はGitHubとGoogle Colaboratoryにあります。詳しくは、GitHubのレポジトリをご覧ください。

なお、第一版のコードはにあります。

同人誌やが出た2017年から4年の歳月を経て、この度改訂版を出すこととなりました。

皆さまのおかげでAmazonの書籍ランキングでも、こともあったそうです。ありがたい限りです。

[2021/04/26追記]
ジュンク堂書店池袋本店とEbookの販売でも1位を獲得したようです。ありがたや〜

[/追記]

改訂版の見どころ

おかげさまで、第1版も非常に好評をいただいて、紙版が出てから3年間地道に応援いただいていました。今回、改訂にあたって古くなった情報を見直したり、新しく書き直し、追加したりと様々行いました。その結果、約1/3が新たに執筆されたページとなり、厚さも前回よりかなり分厚くなっています。

第２版、めっちゃ分厚くなってるやんか pic.twitter.com/TNWOsqMf8N
— ところてん (@tokoroten) April 16, 2021

大きな違いは初版の目次と比較していただいてもわかるかとは思いますが、以下のポイントが大きな変更点になります。

機械学習基盤とML Opsの章の追加 (chezou)
効果検証の章の大幅改訂（hagino3000）
退職予測をテーマに予測モデルの解釈をする (tokoroten)
オンライン広告における機械学習モデルの役割と運用 (hagino3000)
エンジニア向けの数式を少なくしたバンディットアルゴリズム解説 (tokoroten)

おまけ:目次

オライリー・ジャパンのサイトに行くのも面倒くさいという方のために、以下目次です。

まえがき

第I部

1章　機械学習プロジェクトのはじめ方
 1.1　機械学習はどのように使われるのか
 1.2　機械学習プロジェクトの流れ
 1.2.1　ビジネス課題を機械学習の課題に定式化する
 1.2.2　類似の課題を、論文を中心にサーベイする
 1.2.3　機械学習をしなくて良い方法を考える
 1.2.4　システム設計を考える
 1.2.5　特徴量、教師データとログの設計をする
 1.2.6　実データの収集と前処理をする
 1.2.7　探索的データ分析とアルゴリズムを選定する
 1.2.8　学習、パラメータチューニング
 1.2.9　システムに組み込む
 1.3　実システムにおける機械学習の問題点への対処方法
 1.3.1　人手でゴールドスタンダードを用意して、予測性能のモニタリングをする
 1.3.2　予測モデルをモジュール化してアルゴリズムのA/Bテストができるようにする
 1.3.3　モデルのバージョン管理をして、いつでも切り戻し可能にする
 1.3.4　データ処理のパイプラインごと保存する
 1.3.5　開発/本番環境の言語/フレームワークを揃える
 1.4　機械学習を含めたシステムを成功させるには
 1.5　この章のまとめ

2章　機械学習で何ができる？
 2.1　どのアルゴリズムを選ぶべきか？
 2.2　分類
 2.2.1　パーセプトロン
 2.2.2　ロジスティック回帰
 2.2.3　SVM
 2.2.4　ニューラルネットワーク
 2.2.5　k-NN
 2.2.6　決定木、ランダムフォレスト、GBDT
 2.3　回帰
 2.3.1　線形回帰の仕組み
 2.4　クラスタリング・次元削減
 2.4.1　クラスタリング
 2.4.2　次元削減
 2.5　その他
 2.5.1　推薦
 2.5.2　異常検知
 2.5.3　頻出パターンマイニング
 2.5.4　強化学習
 2.6　この章のまとめ

3章　学習結果を評価するには
 3.1　分類の評価
 3.1.1　正解率を使えば良いのか？
 3.1.2　データ数の偏りを考慮する適合率と再現率
 3.1.3　F値でバランスの良い性能を見る
 3.1.4　混同行列を知る
 3.1.5　多クラス分類の平均の取り方: マイクロ平均、マクロ平均
 3.1.6　ROC曲線とAUC
 3.1.7　分類モデルを比較する
 3.2　回帰の評価
 3.2.1　平均二乗誤差
 3.2.2　決定係数
 3.3　機械学習を組み込んだシステムのA/Bテスト
 3.4　この章のまとめ

4章　システムに機械学習を組み込む
 4.1　システムに機械学習を含める流れ
 4.2　システム設計
 4.2.1　混乱しやすい「バッチ処理」と「バッチ学習」
 4.2.2　バッチ処理で学習、予測、予測結果をDB経由でサービングする
 4.2.3　バッチ処理で学習、リアルタイム処理で予測、予測結果をAPI経由でサービングする
 4.2.4　バッチ処理で学習、エッジのリアルタイム処理で予測する
 4.2.5　リアルタイム処理で学習をする
 4.2.6　各パターンのまとめ
 4.3　教師データを取得するためのログ設計
 4.3.1　特徴量や教師データに使いうる情報
 4.3.2　ログを保持する場所
 4.3.3　ログを設計する上での注意点
 4.4　この章のまとめ

5章　学習のためのリソースを収集する
 5.1　学習のためのリソースの取得方法
 5.2　公開されたデータセットやモデルを活用する
 5.3　開発者自身が教師データを作る
 5.4　同僚や友人などにデータ入力してもらう
 5.5　クラウドソーシングを活用する
 5.6　サービスに組み込み、ユーザーに入力してもらう
 5.7　この章のまとめ

6章　継続的トレーニングをするための機械学習基盤
 6.1　機械学習システム特有の難しさ
 6.1.1　データサイエンティストvs ソフトウェアエンジニア
 6.1.2　同一の予測結果を得る難しさ
 6.1.3　継続的トレーニングとサービングの必要性
 6.2　継続的トレーニングとML Ops
 6.2.1　リリースのアジリティを上げるための機械学習基盤
 6.2.2　ML Ops：機械学習基盤におけるCI/CD/CTを目指す取り組み
 6.3　機械学習基盤のステップ
 6.3.1　共通の実験環境
 6.3.2　予測結果のサービング
 6.3.3　学習、予測共通の処理のパイプライン化
 6.3.4　モデルの継続的学習・デプロイ
 6.4　予測結果のサービングを継続し続けるために
 6.4.1　監視・モニタリング
 6.4.2　定期的なテスト
 6.5　この章のまとめ

7章　効果検証：機械学習にもとづいた施策の成果を判断する
 7.1　効果検証の概要
 7.1.1　ビジネス指標（メトリクス）を用いた施策の評価
 7.1.2　施策実行後の効果検証の重要性
 7.1.3　オフライン検証とオンライン検証
 7.1.4　指標の選定
 7.2　因果効果の推定
 7.2.1　相関関係と因果関係の区別
 7.2.2　ルービンの因果モデル
 7.2.3　セレクションバイアスによるみせかけの効果
 7.2.4　ランダム化比較試験
 7.2.5　過去との比較で判断するのは難しい
 7.3　仮説検定の枠組み
 7.3.1　なぜ仮説検定なのか
 7.3.2　コインは歪んでいるか
 7.3.3　獲得ユーザーの継続利用率の比較
 7.3.4　差の信頼区間を求める
 7.3.5　偽陽性と偽陰性
 7.3.6　p値ハック
 7.4　A/Bテストの設計と実施
 7.4.1　2 群の抽出と標本サイズ
 7.4.2　継続的なA/Bテストと終了判定
 7.4.3　A/Aテストによる均質さの確認
 7.4.4　施策同士の相互作用に注意
 7.4.5　A/Bテストの仕組み作り
 7.5　オフライン検証
 7.5.1　ビジネス指標を使った予測モデルの評価
 7.5.2　反実仮想の扱い
 7.5.3　Off Policy Evaluation
 7.6　A/Bテストができないとき
 7.6.1　観察データを使った効果検証
 7.7　この章のまとめ
 7.8　こぼれ話：絶対に成功するA/Bテスト、A/Bテストの母集団ハック
 7.8.1　母集団コントロールによるA/Bテストのハック
 7.8.2　休眠顧客へのアプローチ
 7.8.3　バックボタンハック
 7.8.4　母集団ハックを見抜く
 7.8.5　休眠顧客を使った低リスク実験による成功事例の積み上げ

8章　機械学習のモデルを解釈する
 8.1　Google Colaboratory にインストールされているライブラリをバージョンアップする
 8.2　学習用のファイルをアップロードして確認する
 8.3　線形回帰の係数から原因を読み解く
 8.4　ロジスティック回帰の係数から原因を読み解く
 8.5　回帰係数のp値を求める
 8.6　決定木の可視化から原因を読み解く
 8.7　ランダムフォレストのFeature Importance の可視化
 8.8　SHAPによる寄与の可視化
 8.9　従業員満足度をSHAPで可視化する
 8.10　この章のまとめ

第II部

9章　Kickstarterの分析、機械学習を使わないという選択肢
 9.1　Kickstarter のAPIを調査する
 9.2　Kickstarter のクローラーを作成する
 9.3　JSONデータをCSVに変換する
 9.4　Excel で軽く眺めてみる
 9.5　ピボットテーブルで色々と眺めてみる
 9.6　達成したのにキャンセルされたプロジェクトを見てみる
 9.7　国別に見てみる
 9.8　レポートを作る
 9.9　今後行いたいこと
 9.10　この章のまとめ

10章　Uplift Modelingによるマーケティング資源の効率化
 10.1　Uplift Modelingの四象限のセグメント
 10.2　A/Bテストの拡張を通じたUplift Modelingの概要
 10.3　Uplift Modelingのためのデータセット生成
 10.4　2 つの予測モデルを利用したUplift Modeling
 10.5　Uplift Modelingの評価方法、AUUC
 10.6　実践的な問題での活用
 10.7　Uplift Modelingを本番投入するには
 10.8　この章のまとめ

11章　バンディットアルゴリズムによる強化学習入門
 11.1　バンディットアルゴリズムの用語の整理
 11.2　確率分布の考え方
 11.3　事後分布の考え方
 11.4　事後分布の信用区間上限を用いた実装例
 11.5　UCB1
 11.6　確率的なバンディットアルゴリズム
 11.6.1　Softmax 法
 11.6.2　Thompson Sampling 法
 11.7　各種バンディットアルゴリズムの比較
 11.8　文脈付き多腕バンディットのブートストラップ法による実装
 11.9　現実の問題での課題
 11.9.1　報酬が届くのに時間がかかる
 11.9.2　オフライン実験するためのログデータがバンディットによって偏っている
 11.9.3　有効なアームは流行の移り変わりで時間変化する
 11.9.4　最善なアームが最適ではないことがある、多様性の価値
 11.9.5　アームが途中から追加される
 11.10　バンディットアルゴリズムと、A/Bテスト、Uplift Modelingの関係性
 11.11　この章のまとめ

12章　オンライン広告における機械学習
 12.1　オンライン広告のビジネス設定
 12.1.1　広告枠の売買
 12.1.2　DSPの行動方策
 12.1.3　ファーストプライスオークションの特徴
 12.1.4　入札の流れ
 12.2　問題の定式化
 12.2.1　市場価格と勝率
 12.2.2　効用（Utility）
 12.3　予測の役割と実装
 12.3.1　オーディエンスのレスポンス予測
 12.3.2　勝率（市場価格）の予測
 12.4　広告配信ログの特徴
 12.4.1　フィードバックループ
 12.4.2　不均衡データ
 12.4.3　カーディナリティの大きなカテゴリ変数
 12.4.4　打ち切りデータ
 12.5　機械学習予測モデルの運用
 12.5.1　予測を外したときの対処
 12.5.2　継続的なモデルの訓練
 12.6　この章のまとめ

あとがき
参考文献
索引

↩︎
(海外移住に出産に本業のデスマラッシュにと、全員なぜか締切と重なる様々な出来事があった) ↩︎

2020年を振り返って

Thu, 31 Dec 2020 05:06:15 -0800

久しぶりの年末の振り返りです。振り返ってみるとみたいですね。

コミュニティ・学会活動、OSS活動

MLCTとMLSEの幹事的存在として主に配信担当として活動しました。フロントに立っていただいた上田さん、土橋さんには頭が上がりません。

(kawasaki.rbのブログより)

MLSEでは今年は様々な困難はあったものの、2回ののとML基盤についてのオンラインカンファレンスをしました。

kawasaki.rbも8年目に突入しましたが、2月にお休みした以外。

OSS活動はtabula-pyはissueを苦なく裁く仕組みづくりに注力しました。そのネタで発表もしました。

tabula-pyはCOVID-19の影響で2月以降もユーザが増えていたようで問い合わせも昨年に比べて増えていたように思います。3年前は100スターとか言って喜んでたけど今見たら1.3KってGitHubに丸められてました。すごい。

あとは、久しぶりにRパッケージをしたりしていました。

仕事

有償トレーニングのテキストを作りました。おかげさまで今年始まったばかりですがかなり好評と聞いています。また、トレーニングに関してのが良かったです。

他にも、今年もにかすることができたので良かったです。

チームが変わってRailsとSQLとdigdagをガリガリ書いていますが、なんとか食らいついています。

あと、副業としてLegalForceさんのML基盤の構築のお手伝いをしています。こちらも実際の業務フローがどうなっていくかを考えながらの議論が大変楽しいです。

買ってよかったもの、買ってあってよかったもの

車を買ったんですが、この情勢下でストレスを減らして移動ができたり買い物ができたりと良かったです。あとは、作業部屋がある家に住んでいて本当に良かったなと思います。

マイク周りはずっと警察啓蒙活動をしていました。自分のマイクはBETA58Aを買いました。ダイナミックマイクはいいぞ。

個人的には、MLSEのオンラインカンファレンスは発表者の皆様の協力のおかげで聞きやすく議論に集中しやすい音環境ができたんじゃないかなと思っています。

オンラインで配信されるライブをよく見た年でした。B’zのSHOW CASEやTricolorやOjizoのライブを堪能していました。

漫画・映画

隙間時間で使えるものとして漫画を読むことが多いのですが、この辺がとても気に入っています。

アンデットに育てられた少年の成長の物語。絵も話の流れも良くて引き込まれます。

一目惚れした北欧貴族が軍で活躍する女性と契約結婚からはじまる物語。フィンランドかスウェーデンの北部かなという感じでご飯も美味しそうだしキャラも良い。癒やし。

ガンガン、Gファンタジーから続く世界観のファンタジーの物語。主人公がやや無双気味ではあるが、悩み仲間とともに精神的な成長を遂げていくさまはとてもよい。

各所でおすすめされたので読み始めたけど良い。いわゆる、ポスト魔王討伐もの。長命のエルフが旅をする物語。一話一話で多くは物語が完結するテンポの良さ。ドファンタジーで良い。

アニメを先に知って続きが気になって漫画を買ってしまった。破天荒な主人公がハチャメチャに常識を破壊しながらのドタバタ劇。ラジオが好きなのでこういうものづくりの世界なんだなと垣間見られるのが良い。

若さと青春と芸術系の答えのない世界のぐちゃぐちゃと。アート系のTwitchの配信を見ていると、本当にこの人達は（自分たちと違って）答えも評価尺度も評価関数もない世界で戦ってるんだなと思うが、それを端的に表現している作品。自分にはそこまで黒歴史をえぐられる感はないが、人によってはかさぶたを剥がされる感覚に陥るらしいので注意。

あとは、Disney+でMarvel作品を1から見ています。アイアンマンが苛ついたりする事が多いですが、全体的に安心できるクオリティで見ていて楽しいです。

2021年に向けて

原稿執筆は年に1個までだったなとか、動画編集をもう少しできる時間を確保したいなと思いつつの2020年でしたが、2021年はリングフィットも継続して体をいたわりながら家族ともども健康な1年を過ごしたいなと思います。

メッシュWiFiが安定しないので有線LANを張り巡らせたんだが

Thu, 10 Dec 2020 07:00:00 -0800

このお話は、の11日目です。昨日はwozozoでした。多分彼はこの記事をチラ見して「長過ぎる。地雷乙」と言うでしょう。

3階建ての家でインターネットを安定させるために、NETGEARのOrbiというメッシュWiFiを構築していたのだが、どうにも調子が悪いので有線LANを張り巡らせました。これはその奮闘記です。なお、筆者はネットワーク系は素人なので用語などが不正確な場合がありますががあしからず。あと、面倒なので以降語尾はですます調じゃなくなります。

メッシュWiFi購入

事前にメッシュWiFIを色々調べたが、どうもNETGEARのOrbiが良いらしいという話を聞いていた。NETGEARが素晴らしいのは購入前にこういう環境だけどどのモデルを買えば良いのか？という相談をできること。これは素晴らしい。当時WiFi-6対応のモデルは出ておらずでかい筐体のOrbiと日本向けの小さいOrbi Microの二種類が出ていたのでどちらを何台買えば良いのかわからなかった。

電話でこういう環境でこれくらいの広さなんだけどと言うと、「3階建ての場合はOrbiを3台です。これ以外ありません」とサポートの人が自身を持って答えてくれた。へー、そうなんだ。Microの方が安いしそこまで広くないからそれでいいかなと思っていたけど餅は餅屋だ。そう思ってOrbiをサテライト2台付きの3台セットを購入した。

設置した当初は、うおおお無線LAN速い！安定する！と喜んでいたが、よくよく設置して調べてみると1台で全部屋カバーしてるじゃん。まあいいか、一応レスポンス良くなるし。と思いながら、サテライト1台は封印することに。

しかし、その時はまだ地獄の始まりだということを知らなかった。

フルWFHのはじまり

例によって全面的なWFHが2月から始まって、テレカンをする機会が激増した。すると、なんか無線LANが遅いことに気づいた。OrbiはIIJmioひかりが使っているDS-Liteこそ対応してないが、をオンにしてみるもまだ遅い。色々と切り分けてみると、Orbiの設置場所を変えたときにNTTの終端装置とOrbi間のLANケーブルを変更したのだが、その時に古いケーブルを指したらCat 5eでも有線LANの速度が全然出ていなかった。ケーブルって劣化するんだ…。

それでも、どうも夕方特定の時間帯のテレカンが途中で途切れる減少に気づいた。あと、ちょいちょい深夜にサテライトがピンクの光を発して落ちている（のをSynologyのNASの疎通確認が落ちたメールで気づいた）。

夕方といえば、電子レンジじゃないか。NTTの終端装置が置かれた2階にOrbi本体を設置し、1階の作業部屋のサテライトに飛ばしているのだが、すこし距離があるため2.4GHz帯を使ってサテライトとの通信をしているぽいぞ。あれ、5GHz帯のバックホールとは一体…。この辺からwozozoから「また地雷踏んだの」と言われる日々が続いた。

ともあれ、これが続くようでは仕事に支障をきたす。Orbiには幸い有線バックホールという親機とサテライト間を有線でつないでメッシュをより安定させる機能があることは知っていた。そんな折、太田さんのこの記事を見て書いた感想からお墨付きをもらったので有線LAN工事をする決意を固める。

それが出来るなら、1番良いです。この状況下、たぶん投資価値ありますw
— Kazuki Ohta (@kzk_mover) August 20, 2020

有線LAN工事をする

いろいろ調べて、ウェブソフトさんという会社を選んだ。

ポイントは以下の3つ

Cat 6aに対応していることをサイトで明示していた
Webで依頼した仮見積もりの詳細をメールで返信してくれた（他社は電話でまくしたてるように返してきた）
値段も妥当な範囲だった

今サイトを見るとHTTPSじゃないし懐かしい感じのサイトだが、見積もりや対応含めて良さそうだなと思ったのでお願いすることにした。

事前にわかっていたのだが、我が家には壁コンセントの裏にがほとんどなかった。「ほとんど」というのは2階と3階にはついていたが、肝心の2階と1階にはなかったため、壁に穴を開けて屋外配線をすることにした。

壁のLANコンセント

TVのアンテナはないのにアンテナ線だけ張り巡らされていたが、壁からCAT 6aが生えてきた

工事の結果こうなった。めでたしめでたし、かに思えたが…。

不安定な有線バックホールとの戦い

しばらく安定したかのように見えたのだが、まだ一つ謎の現象が残っていた。

ちょいちょい深夜にサテライトがピンクの光を発して落ちている（のをSynologyのNASの疎通確認が落ちたメールで気づいた）

そう、これがまだ続くのである。

正確には朝起きると1階のOrbiサテライトがピンクの光を発して死んでいるのである。定期的にネットワークのトラブルシュートからスタートする一日は非常にストレスフルだった。大体、西海岸の人々とやり取りするため朝8時台からテレカンが入っているのだ。朝ご飯の準備をしながら子供の面倒を見てインターネットの面倒も見る。さらに寝てる間のメンションも見る。どう見てもキャパオーバーである。

NETGEARのサポートに問い合わせても、Orbi一式を初期化してください、と言われそれでなんか復活した雰囲気、みたいなのを繰り返していた。

そうした時にMLSEのオンラインカンファレンス配信担当をする日の朝に事件が起きた。

もう耐えかねて、有線バックホールなのになぜ死ぬ、と思いながら1階のOrbiに有線でぶら下がっている端末を全部物理のHUBに切り替えて、Orbi自体の有線バックホールを使わないようにした。

ひとまずこれでカンファレンスは凌いだものの、数日したらまさかの現象が発生した。

悪さをする端末の特定

こんどは朝起きたらOrbi親機もピンク色になっているのである。OrbiやNTTの終端装置も再起動をするも、翌日になるとまた再発するというのを2日繰り返した。大体寝る前に見つけてOrbiの再起動をしていたのだが、2日目の朝には再起動をしてもネットワークがつながらない。切り分けてみると、そもそも有線LANで接続したNTTのルータにもpingが通らないしIP直接叩いても反応がない。

うーん、と思ってやたらランプが点滅してる経路があるなということで追いかけてみると、そこには会社のMBPがいた。試しにそいつ（につながっているThinkPadのType-Cのドック）につながっているLANケーブルを抜いてみた。

戻った。不安定だったのが嘘のように戻ったのである。NTTのルータにもすぐに接続ができるようになった。

ははーん、過去の親会社のVPNソフトが悪さをして1Mbpsとかしかでなくなる罠にハマったので、会社のMacでなにかやんちゃなソフトウェアが動いているに違いない、と思い調べた。案の定、Code42とかいうバックアップソフトのLAN側の帯域を制限したらだいぶ安定するようになった。どうやらこのソフト（だけではないのかもしれないが）、スリープ時とアクティブなときとで帯域制限が違う値が設定できるのだが、スリープに入るとものすごい勢いで通信をしていたらしい。そりゃ昼間に気づかないわけだ。加えて、ThinPadのType-CドックはUSB接続のLANアダプターとは違い、ACアダプターで給電していてそれはもうすこぶる安定している。熱でやられて速度が遅くなったりしないのだ。ThinkPad Type-Cドックはいいぞ。というわけで、安定して通信をすることを許していたらしい。

会社のMBPは、夜電源を抜くと翌朝再起動しないと起動しない呪いにかかっていたためドックに繋ぎっぱなしにしていたのである。それが裏目に出た。

なお、今は帯域制限してもなんか怪しい気がしたので、ドックから有線LANを抜く運用にしている（ドックとは！ちなみに、okapisさんによるとLinuxでドックがものすごいパケットを送るケースがあるらしいのでドックの可能性もあるかもしれない…。なお、会社のITの人も有線LANは夜にぬけと言っていました）

おかげで今はすこぶる調子が良い。

天井の配線

ついでに天井にも有線LANの配線をした。

Key takeaways

本文に書いたものも書かなかったものも学びとして。

有線LANのケーブルは腐るので古いものは捨てよ
iPhoneやiPad, PCは買い換えると無線LANの規格が新しくなってそれだけで速度向上が見込める
ボトルネックの切り分けのために有線LANポート内蔵のPCはあったほうが良い
会社の端末固有の問題か切り分けるために同じOSの端末でABテストをできると良い
最適化を繰り返すとボトルネックが移動する（ので、逐次潰していく）

最後に、友人からのありがたい言葉を貼っておく。

安易に安定を求めて裏切られるの味わい深いですな。カオスエンジニアリングを讃えよという神のお告げでは。
— Kiyoshi Mizumaru (@kmizumar) November 19, 2020

明日はねじです。

インターネット

機械学習工学研究会の「機械学習基盤本番適用と運用の事例・知見共有会」を開催しました

Tue, 10 Nov 2020 05:18:19 -0800

さん共同で、機械学習工学研究会（MLSE）本番適用のためのインフラと運用WG主催の、「機械学習基盤本番適用と運用の事例・知見共有会」をオンライン開催しました。

イベントのconnpassは以下のリンクです。

さんによるツイートのまとめはこちらです。

YouTubeの動画

YouTube Liveの配信はアーカイブとして見ることができます。

当日の資料

感想

今回、僕は企画とCfP系のとりまとめ、当日は配信担当をさせていただきました。当日の司会進行は土橋さんにおまかせをしてしまったのですが、いつもながら質疑応答の仕切り力は素晴らしい限りだなと思いながら聞いていました。

今回のトピックは、機械学習チームが解散したという衝撃的な話からはじまり、NLPを中心とした機械学習基盤、リアルタイム予測基盤、モバイルやエッジ向けの機械学習など多岐にわたる発表が充実していました。個人的に特に思ったことは、一言に機械学習基盤といっても組織や規模、フェーズに応じたアーキテクチャが採用されているというように感じました。これはMobility Technologies大西さんの発表で、Kubeflow Pipelinesを選んだ理由に「ブラウザベースでパラメータを入力できること」ということがありました。

当たり前ではありますが、システムの要件は組織の体制やビジネス要件に規定され、それが機械学習基盤でも変わらないということが改めて実感できました。

今後も、MLSE 本番適用のためのインフラと運用WGではこうした機械学習基盤のアーキテクチャやパターンを明確にするために、討論会などの活動を続けて行きたいと思います。

Google Colaboratory上でVS Code(code-server)を動かす

Thu, 16 Jul 2020 17:56:00 -0700

iPadからアクセスする図

元ネタはToward DataScienceの記事から。mediumの有料記事なのとssh tunnelとか冗長だったので簡潔なノートブックを作った。

何ができるか

Colabで動かしたVS Code(code-server)がブラウザからアクセスできる
sshのトンネルとか不要なのでiPadとかからもVS Codeが動く
Google Driveにデータを永続化するので、セッション切れてもまた再開できる
code-server側のパスワードを設定できるので、一応誰からでも使えるわけではない（ランダムでアタックされるとかは知らない…）

やること

のfreeアカウントを作り、Auth tokenを手に入れる
下のnotebookをColabで動かす。途中でgetpassで要求されるngrokのAuth tokenと、code-server用のパスワード（これは自分で生成する）を入れる
print(str_ssh) で出てきたURL（2個めのセルの実行結果）にアクセスする

とりあえず、tabula-pyのpytestが走るのは確認できた。罠としてはデフォルトvenvが入ってないので、 apt-get install python3-venv を実行しておくほうがいいこと（1個めのセルに入ってる）。

code-serverでパスワードを要求される図

pytestが完了した図

なお、iPadからの実行時、Blutoothキーボードがないとterminalに仮想キーボードがかぶってうまく入力できないので注意が必要。

機械学習工学研究会（MLSE）の夏合宿 2020で本番適用のためのインフラと運用に関する討論会を開催しました

Sat, 11 Jul 2020 02:00:00 -0700

さんとMLSEの夏合宿で、本番適用のためのインフラと運用WGの討論会を開催しました。 WGのモチベーションはをご確認ください。

MLSEの夏合宿自体の概要は、さんがまとめてくださった記事がわかりやすいと思います。Discordを中心に130名を超える参加者がオンラインで様々な議論をするというスタイルでした。

実は我々のWGの討論会自体は第一回はオフラインで開催しました。そちらの。よければ御覧ください。

今回の討論会のまとめは、以下の2つのトピックについて議論をしました。

機械学習における監視・観測とアーキテクチャ例
責任分解とシステム

もう少ししたらGitHubのレポジトリにまとめを上げる予定ですが、その中から興味深かった話題を紹介したいと思います。

COVID-19の影響は予測モデルを更新し続けることである程度抑制できた

これは、PFNの丸山さんが話題に出してくれたのですが、deeplearning.aiのnewsであるやでも言及されていた、「COVID-19によって人間の行動が変わってしまって予測に対する影響は出なかったのか？」という問いが投げかけられました。その中で、ある広告系の企業の参加者が、「入力データもモデルも毎日更新しているので、現状は対応できていると考えている。毎日モデルを更新するのが大切」という知見を共有してくれました。

もちろん、劇的に前提条件が変化をする問題ではなかなかそのままのロジックや特徴量が使えないということもありうるとは思いますが、モデルを継続的に学習しつづけることで、変化に追従するというのは長期間機械学習システムを運用していく上でなくてはならないのだと改めて思いました。

学習したモデルは、組織のありかたで渡し方はおろか渡せるものも変わる

予測モデルを誰が学習するのか、という話題のなかで、小さなチームでは学習も予測も一人でやるという状況が出たのに対して、日本の大企業では特にで、研究所で学習したモデルや学習をするためのコードを渡せず仕様書のようなドキュメントで開発部門に渡すしかない、という話が出ました。言われてみればそういうケースもありうるのかと思いつつ、部門の切れ目でAPIを用意するという立て付けも取れるかもしれませんが、研究所で学習や予測APIを提供するといった体力があるところも限られてくるとは思うので、日本の会計や税務的に難しさが発生するのかと、ハッとした瞬間でした。

モデルのリネージは決めてとなるOSSがない

これは討論会で出た話では有りませんが、実験管理は徐々にOSSで出てきているが、モデルの作成に至るまでのリネージはOSSとしては決定版がないよね、という話が何度か出てきました。もうシャットダウンしてしまったDotscienceではこうしたを持っていましたが、まだOSSでは良いものは私の知る限りではないように思います。こうしたこともあり、サイバーエージェントではモデルのリネージを管理するためのツールを内製で開発しているそうです。OSSとしてカバーするのは難しいかもしれませんが、各社が自社のサービスの上でのソリューションを提供してくるかもしれません。

夏合宿全体を通じた感想

Discordを通じた議論や発表はとても体験としてよかったと思います。特に、人工知能学会のポスターで苦痛だったExcelで書かれPDFで出力されたパスワード付きZoomのリンクをクリックして移動するという地獄の体験をしたあとでは、Go Liveでどういう発表をしているのかもプレビューで覗けますし、軽量な音声だけで議論も進むので活発な議論ができていたのではないかと思います。

ただ、会社のポリシーでP2Pのプロトコルを使っているDiscordのアプリは使えず、会社のMBPでは非力だったためか画面共有の表示が安定してされなかったのは難しいところではありました。GPUマシンでは安定しているので、MBPでは少し厳しいですね。

我々の討論会ではZoomを使って議論をしたのですが、Muralと呼ばれるMiroのようなオンラインホワイトボードも使っていたので、複数のグループに分かれて付箋を貼っていくスタイルでも良かったかもしれません。

ただ、ご多分に漏れずDiscordの参加人数が10人を超えてくると、議論が一本にしかならない関係もあり並列して話をするのは難しい印象でした。

最後に

9月頃にWGとして、各社で携わった機械学習基盤の知見共有をするためのオンラインカンファレンスを実施予定です。もう少ししたら、公募を開始しようと思いますので、機械学習システムを構築している話や、構築しようとしたけどうまく行かないといった話をシングルトラックのセッションとして発表していただければと思います。

Google MeetとYouTube Liveでオンラインミートアップの配信をした

Fri, 29 May 2020 01:54:07 -0700

先日、というイベントの配信担当をした。

会社ではZoomを使っているけど、Google Meetが今なら無料で使わせてもらえるということで、ありがたくMeetで発表をしてそれをYouTube Liveで流すということをした。

ライブでの配信は同時参加者ピークで250名くらいで、配信も一瞬ネットワークの問題で乱れが発生したが、ほかは概ね安定していた。

世の中のイベントの配信情報は、ZoomばかりでGoogle Meetでやっている例があまり見当たらなく、あっても細かいOBSのレイアウトどうしたんだよ！と思っていたので、ここに書いていく。

tl;dr

MeetでOBS自前配信はしんどいのでZoomが使えたらそちらを使いましょう
リハーサルは大事。特に発表者の接続チェックはしましょう

構成

Google Meet -> OBS -> YouTube Live

という至って普通の構成。これにsli.doの質問と自作のバナー画像を貼り付けていた。

Meetのエンタープライズプランなら、YT Liveへの配信も楽にできたらしいが、無料なので致し方なし。

準備にかかったコスト

今回始めてYouTube LiveをOBSで配信したのだけど、配信事故とかの話もチラチラ聞いていたので、

運営でのリハ
一人でのOBS設定のチューニングも兼ねたリハ
直前のリハ

の3回リハをした。特に2個目のは、画像バナー作成や最適な設定を見つけるまでに試行錯誤して休日ほぼ一日潰してしまった。家族には感謝しかない。

ただ、一度レイアウトを組めば（ウィンドウサイズの調整はいるけど）再利用できそうなので次回以降はもっと楽になりそう。

配信の体制

基本的に以下のような体制を敷いた。

司会
配信オペレーション
YouTube Live監視 & Twitterなどのコメント

OBSのレイアウト

左上にMeetの画面を配置し、右側にsli.doのプレゼンテーションモードのウィンドウを小さくしてはりつけ、下側にGoogle Slideで作ったバナー画像を貼り付けた。

sli.doが管理者でなくてもプレゼンテーションモードにできたので、それの横幅を狭めればそれっぽい画面になった。ただ、管理者のときに出てくるものより太いので注意が必要。

テロップはあるといいとは思ったのだが、気づいたのが配信開始直前だったのでやらなかった。

その他のOBSの設定は普通にGPUを使ってnvencを使うことと1080pで出力するところを調整したくらい。あとは、スタジオモードで作業をしたほうが色々とトランジションしやすくて良い。

作ったレイアウトは、

バナーとsli.do付き
Meetの画面フルスクリーン
待機画面用の画像

の3つを用意しておいた。特に2はもし1がうまく行かなかったときのために保険として用意をしたが、幸いにして使う必要はなかった。

WindowsでOBSを使ったので、画面から出るMeetの音声をそのまま流して、自分のマイクの音はMeetにだけ乗るようにした。こうすることで、ディレクターっぽい指示をたまに出していた。なお、物理ノブがあるオーディオインターフェースでマイク音量をコントロールできたのはやはり良かった。

今は色々と在庫がないが、evo4とか安いのがよければWindowsの評判はいまいちだがUM2あたりを持っておくと良い。

Meetならではの気をつけること

以下の4つの注意点がある。

Meetのレイアウト
画像の解像度を上げる
発表者の接続チェックは忘れずに
音量のノーマライズが暴れるのをなんとかする

Meetのレイアウト

Meetのレイアウトはデフォルト自動でワチャワチャ変わっていくのだが、見ている方は落ち着かない。今回は右側に顔が並ぶ設定に固定した。ただし、このレイアウトは自分ひとりでテストしようにもできないので、事前のリハで確認したいところ。

あと、発表している人以外はビデオカメラをオフにしてもらったが、リアクションがわかりにくいので登壇者は全員顔を出しても良かったかも知れない。

なお、レイアウトは通話ごとに設定するぽいので忘れないように。このレイアウトでも、発表者の顔の位置は固定できないので、PinPで発表者だけの顔をOBSで切り出すのは絶望的なのでやめましょう。Zoomだとビデオオンにしてる人だけ写すということができるようなのだが、Meetの場合は顔出しをするためだけの、別のコールをもう一つ作ってそれを切り出してPinPにするのが良いらしい。

画像の解像度を上げる

Meetの画像の解像度はデフォルト360pなので、720pに開始後に上げること。そこをよしなにしてくれないのがMeet。忘れないように。

発表者の接続チェックは忘れずに

これは、Zoomでも同じかも知れないが、画面共有には罠が潜んでいる。発表者の接続チェックはしたほうがいいだろう。

今回、一人Keynoteだけを共有できずSpeakerDeckで発表するというのを直前に変更せざるを得なかった。あと、配信者としてはこのタイミングで各自の音量の確認をしておくこと。

音量のノーマライズが暴れるのをなんとかする

大体の通話アプリは音量がノーマライズされるのだが、Meetのそれは凶悪。気を緩めるとすぐに音割れをする勢いの音量をだしてくるので、OBSのレベルメータを常に注視して調整し続ける。疲れる。本当に疲れる。これを避けるために、一度仮想マイクデバイスを間にかますとかいうテクもあるらしいが未検証。

暴れるのは飛影の右手だけで十分。

改善点

いくつかやっておけばよかったものとして

YT Live URLの事前告知 (eventをリハと分けて先に作ればよかった)
マイクの指導

一個目は知識不足の勘違いからきた。リハ前にイベントを予め作って告知すれば良かった。

二個目は、マイクの最終指導をすればよかった。コンデンサマイクを持ってても場所が悪いと残響ひどくなる。EarPodsはスレを防止するために止めるおなど。マイクの設置についてはこの動画を見てもらえば良かった。

あと、やっぱりMacBook Proの内蔵マイクは残響がひどくてだめだったので、こちらで買ってでもマイクを用意してもらったほうが良かった。

まとめ

Google Meetでのオンライン配信、悪くはないけれどいろいろなノウハウがあるのでぜひチャレンジしてほしい。有料のZoomがある人はそちらでやるのがやはり楽だろう。

テレカン・発表用にマイクを用意しよう

Fri, 03 Apr 2020 23:23:00 -0700

by Kai Pilger, Unsplash

最近、いろいろな人からテレカンやリモートプレゼン用の機材を聞かれることが増えたので、ここにまとめておく。

頼むからMBPの内蔵マイクやAirPods Proを使わないでという気持ちで書いている。

tl;dr

背景雑音や残響対策を許容できるならUSB接続のコンデンサーマイクが一番安上がり
USB接続ヘッドセットは定価の倍くらいになっているので、USB接続のダイナミックマイクとマイクアームが買えるならベスト
USBオーディオインターフェース＋安いダイナミックマイクとマイクアームが、音的には一番良い。価格もオーディオIFを抑えればそこそこ

基本的に音の大きさは距離の二乗に反比例するので、マイクとの距離を保つことが重要です。

市場の在庫がどんどん減ってるのでコスパの良い選択肢は減っている。買うなら早めに買ったほうが良い。

すべからず

会議室にあるようなスピーカーマイクを使わない。あれは複数人で話をしたり聞いたりするのに特化をしているが、ヤマハのそれなりのを選んでも音は電話レベル。ご家庭に三人同時に参加者がいない限りは不要
有線の安いイヤホンマイク（線の途中にマイクが付いてるやつ）は音がひどいのと衣ずれのノイズがやばいので使わない
BTのマイクを使わない。プロファイルのせいか、大抵音が悪い。電話レベル
AirPodsのマイクを使わない。個人的にはこれよりMBPの内蔵マイクの方がマシ。電話レベルに毛が生えた感じ
- AirPodsに音の酷さはこのnagikoさんのエピソードを聞くとわかると思う
PCの内蔵マイクを使わない。MBPの場合でも残響がひどかったりして聞くのに負荷が高い。音の特性としては悪くないが、マイクとの距離が保てないため遠くでボソボソ喋ったり疲れてきて声が小さくなると、音が全然判別できない。使うなら常時腹から声を出せ。オンライン飲み会に使うならこれくらいでもOK

おすすめ構成1: USB接続のダイナミックマイク＋マイクアーム

手軽だが種類が少ないため、入手性が微妙。音は背景雑音や残響を拾いにくいため、安定する。予算10000円前後。

AT2005USBはまだギリギリ在庫がありそう。SAMSONのQ2Uは安いけど取り寄せなため厳しい。

マイクアームがあるとキーボードのタイプ音などを拾うのを防ぐ。マイクアームは、正直どんなのを買っても大丈夫。千円前後でいいだろう。

なお、マイクの設置に関してはこの動画が非常に参考になる。

[2020/04/28追記]

厳密にはダイナミックではありませんが、距離に対する減衰がかなりきつめのコンデンサーマイクのMarantz 888Mがお手頃で良い（書いている時点で3000円）。ネックは遠いと音量が小さくなってしまう（30cmくらい離れるとかなり音が小さくなる）ので、付属のマイクスタンドは使わず必要に応じてマイクアームを用意するのが良いだろう。

[/追記]

[2020/11/09追記]

Marantz 888Mに付属のUSB-DACはmacOSで長時間使うと暴走することが知られているので、自前で用意するのが吉。

[/追記]

おすすめ構成2: USBオーディオインターフェース＋ダイナミックマイク＋マイクアーム

音が良く、入手性もそれなり。予算さえ許せば一番おすすめしたい構成。予算10000〜30000円程度（2020/04/04現在）。1週間前はもっと安く抑えられたんだが…。

オーディオインターフェース

エントリーモデルで評判が良いのはYAMAHAのAG 03。分解能が24bitで録音できるので小さい音も拾いやすいらしい。あと、オーディオIF側でミックスができるので、配信したい場合にPCの音とマイクをハードウェア側で混ぜられるので便利。Amazonだと1週間で5000円くらい値上がりしたので、サウンドハウスやヨドバシも見てほしい。トータル3万円前後。

[2020/04/23追記] どうやらAG03が市場から消えたみたいなので、UR12あたりでも買っておこう。

[/追記]

最安路線で攻めたいのであれば、ベリンガーのUM2が良さそう。ただ16bitまでしかとれない。トータル1万円前後。

ダイナミックマイク

マイクは安いので十分。ベリンガーのXM8500みたいな3000円程度のもので良い。

XLRケーブル

キャノンケーブルともいうXLRケーブルが必要。長さは自分の環境に応じて選ぶべし。

マイクアーム

構成1を参照

おすすめ構成3: USB接続のコンデンサーマイク＋マイクアーム

これが執筆時点で一番安くおさまるコース。予算7000〜8500円（2020/04/04現在）

MarantzのPod Pack 1やMPM-1000Uあたりが手頃。

ネックは部屋の残響が多い場合反響音でめっちゃ聞きづらい音になることと、エアコンや家族の生活音までの乗ってしまうこと。前者は吸音材を貼るなどの対応がいる。

自分が使っているのはMPM-2000Uだが、程々の指向性はあるのでYeti Blueとかよりはいいんじゃないかと思っている。

MPM-1000Uはマイクアームが付いていないので別途購入すること。

番外編

USBヘッドセットはSennheiserのSC 135 USB-CやSC 160 USB-Cあたりが良いそうだが、在庫がない。他の安いヘッドセットも定価の倍になっているので、絶望的。

[2020/04/23追記] USB接続ではないですが、SW-TR2は圧迫感も少なく良いそう。今なら半額キャンペーン中とのこと。

[/追記]

最後に

在庫もなくなりつつあるので、その時その時で選べる良い選択肢を選んで、良いテレカン＆発表ライフを過ごしてほしい。

なお、オンライン飲み会程度ならMac内蔵マイクで適当にやれば良いだろう。

pandas 1.0 のpd.NAのハマりどころ

Sun, 01 Mar 2020 02:17:00 -0800

pandas 1.0.0 からexperimental featureとして登場した pandas.NA 。これは今まで0.x系では numpy.nan で表していた missing valueを pandas.NA で表現しようというもの。

この検索しにくい名前のおかげで、情報を探してもなかなかたどり着かないので苦労をする。公式の “What’s new in 1.0.0” の “Experimental new features” の項と hkzmさんのQiitaの記事がよくまとまっているので困ったらここに立ち返るとよい。

この記事では、nullableなdtype周りでハマったことをまとめていく。

そもそもなぜ `pandas.NA` が登場したのか

以下のドキュメントには、 numpy.nan 周りの説明がざらっと書いてある。特にcastされるときの挙動は今でも役に立つだろう。（というか昔の説明がなくなっているように思う）

pandasを利用されている方は、このintからfloatへのcastに遭遇したことも多いだろう。pandas 0.24から (pandas.Int64Dtype() いわゆる Int64 。 int64 はnumpyのdtypeを指すので注意。 Int32, Int16, Int8 もある) も登場し、Intのままで NaNを保持できるようになった。

In [1]: arr = pd.array([1, 2, np.nan], dtype=pd.Int64Dtype())
# pd.array([1, 2, np.nan], dtype="Int64") でもOK
In [2]: arr
Out[2]:
<IntegerArray>
[1, 2, NaN]
Length: 3, dtype: Int64

では、なぜpandasはfloatにデフォルトcastしているのだろうか？

実は、 NaN というのはIEEE 754でfloatと決まっているのである。

だから、 numpy.nan もfloatだし、pandasはもともと numpy.nan があるとfloatのdtypeにcastしていたのである。IEEEで決まっていたら仕方がない。 type() を調べても nan は float になるわけだ。

In [1]: np.nan
Out[1]: nan

In [2]: type(np.nan)
Out[2]: float

In [3]: float('nan')
Out[3]: nan

In [4]: type(float('nan'))
Out[4]: float

`pandas.NA` の登場と、新しいdtypeの追加

仕方がないというわけにはいかないので、pandasは通称 Int64 を導入したのである。しかしこれだけでは、。また、 str も object 型というなんでもごった煮のdtypeで扱いたくない。というので、pandas 1.0.0から pandas.BooleanDtype() (string表記は "boolean")と pandas.StringDtype() (string表記は "string")が登場した。また、合わせて pandas.NA も登場した。

つまり、nullableな型は以下のように遷移してきた。

0.23まで
- float, object
0.24〜0.25
- float, object, Int64, Int32, Int16, Int8
1.0以降
- float, object, Int64, Int32, Int16, Int8, boolean, string,

Nullable Valueの有無でのハマりどころ

以下はpandas 0.23.4, 0.25.3と 1.0.1で比較をしている。最初は1.0前後で比較をしようとしたが、大きな変更は0.24の前後で変わっていたようである。

`Int64` を指定したDataFrameで `numpy.nan` ではなく `pandas.NA` が返ってくる

0.25以前では dtype="Int64" を指定したときは、 numpy.nan がmissing valueとして返ってきた。

In [13]: df = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}], dtype="Int64")

In [14]: df
Out[14]:
 a b c
0 1 2 NaN
1 3 4 5

In [15]: df.c.iloc[0]
Out[15]: nan

In [16]: type(df.c.iloc[0])
Out[16]: float

In [18]: pd.np.isnan(df.c.iloc[0])
Out[18]: True

これが、以下のようになる。

In [2]: df = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}], dtype="Int64")

In [3]: df
Out[3]:
 a b c
0 1 2 <NA>
1 3 4 5

In [4]: df.c.iloc[0]
Out[4]: <NA>

In [5]: type(df.c.iloc[0])
Out[5]: pandas._libs.missing.NAType

In [6]: np.isnan(df.c.iloc[0])
Out[6]: <NA>

そうだよね、と思うだろうがこれに伴い以下の挙動が変わってきている。

Noneへの置換をしたい場合

これは0.24で Int64 導入時からの挙動だが、 Int64 のdtypeのcolumnは、手でNoneを代入すると numpy.nan や pandas.NA が保持される。これは df.where や df.applymap などで numpy.nan や pandas.NA を置換しようとしてもdtypeを変えないと None に置換できないということを意味する。 df.replace は object dtypeになる。

0.25.3の挙動

In [25]: df
Out[25]:
 a b c
0 1 2 NaN
1 3 4 5

# cは何も変わらない
In [26]: df.where(pd.notnull(df), None)
Out[26]:
 a b c
0 1 2 NaN
1 3 4 5

# cがfloatにcastされてしまう
In [27]: df.applymap(lambda x: None if np.isnan(x) else x)
Out[27]:
 a b c
0 1 2 NaN
1 3 4 5.0

# cはobject dtypeにcastされている
In [38]: df.replace({np.nan: None})
Out[38]:
 a b c
0 1 2 None
1 3 4 5

In [39]: df.replace({np.nan: None}).dtypes
Out[39]:
a Int64
b Int64
c object
dtype: object

1.0.1での挙動

In [2]: df = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}], dtype="Int64")

In [7]: df
Out[7]:
 a b c
0 1 2 <NA>
1 3 4 5

In [3]: df.where(pd.notnull(df), None)
Out[3]:
 a b c
0 1 2 <NA>
1 3 4 5

# np.isnanはTypeErrorを返す（当たり前）
In [5]: df.applymap(lambda x: None if np.isnan(x) else x)
TypeError: boolean value of NA is ambiguous

# pd.isnullならOK。floatには変わる
In [6]: df.applymap(lambda x: None if pd.isnull(x) else x)
Out[6]:
 a b c
0 1 2 NaN
1 3 4 5.0

# cはobjectに置換される
In [8]: df.replace({np.nan: None})
Out[8]:
 a b c
0 1 2 None
1 3 4 5

In [9]: df.replace({np.nan: None}).dtypes
Out[9]:
a Int64
b Int64
c object
dtype: object

1.0.1でのNullableなtypeを使わない挙動

In [27]: df2 = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}])

In [28]: df2
Out[28]:
 a b c
0 1 2 NaN
1 3 4 5.0

# cはobjectになる
In [29]: df2.where(pd.notnull(df2), None)
Out[29]:
 a b c
0 1 2 None
1 3 4 5

In [30]: df2.where(pd.notnull(df2), None).dtypes
Out[30]:
a int64
b int64
c object
dtype: object

# cはfloatになる
In [31]: df2.applymap(lambda x: None if np.isnan(x) else x)
Out[31]:
 a b c
0 1 2 NaN
1 3 4 5.0

# cはobjectになる
In [33]: df2.replace({np.nan: None})
Out[33]:
 a b c
0 1 2 None
1 3 4 5

In [34]: df2.replace({np.nan: None}).dtypes
Out[34]:
a int64
b int64
c object
dtype: object

まとめると以下の表のようになる。

Name	non-nullable dtype	nullable dtype
df.where	object にcast	変化なし
df.applymap	float にcast	float にcast
df.replace	object にcast	object にcast

`df.to_dict(orient="record")` の挙動の罠

行ごとにデータを処理したいのであれば、 df.to_dict(orient="record") を使うことができる。が、これは後述するように挙動がバージョン感で差異があったり、古いバージョンではちょっと想定と違う挙動をするので df.to_records を使うほうが良い。具体的には、0.23以前は、カラムごとに nan の有無でdtypeを変えることが期待されるが、行ごとにdtypeを揃えに行こうとするため、 nan がある行が含まれていると全行 float に変わってしまった。なお、1.0.1ではこの挙動は期待通りに修正されている。

0.23.4

In [37]: df = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}])

In [38]: df
Out[38]:
 a b c
0 1 2 NaN
1 3 4 5.0

# 全部の値が numpy.float64 にキャストされている
In [39]: df.to_dict(orient="record")
Out[39]: [{'a': 1.0, 'b': 2.0, 'c': nan}, {'a': 3.0, 'b': 4.0, 'c': 5.0}]

In [40]: type(df.to_dict(orient="record")[0]['a'])
Out[40]: numpy.float64

In [41]: type(df.to_dict(orient="record")[0]['c'])
Out[41]: numpy.float64

1.0.1

In [2]: df = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}])

In [3]: df2 = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}], dtype="Int64")

In [4]: df
Out[4]:
 a b c
0 1 2 NaN
1 3 4 5.0

In [5]: df2
Out[5]:
 a b c
0 1 2 <NA>
1 3 4 5

# Cのみfloatに、他はintのまま変換されている
In [6]: df.to_dict(orient="record")
Out[6]: [{'a': 1, 'b': 2, 'c': nan}, {'a': 3, 'b': 4, 'c': 5.0}]

# 基本、numpy.int64で保持されている
In [7]: df2.to_dict(orient="record")
Out[7]: [{'a': 1, 'b': 2, 'c': <NA>}, {'a': 3, 'b': 4, 'c': 5}]

In [9]: type(df.to_dict(orient="record")[0]['a'])
Out[9]: int

In [10]: type(df2.to_dict(orient="record")[0]['a'])
Out[10]: numpy.int64

In [11]: type(df.to_dict(orient="record")[0]['c'])
Out[11]: float

In [13]: type(df2.to_dict(orient="record")[0]['c'])
Out[13]: pandas._libs.missing.NAType

df.to_records を使った処理例は以下の通り。

1.0.1

In [2]: df = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}])

In [3]: df2 = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}], dtype="Int64")

In [4]: df
Out[4]:
 a b c
0 1 2 NaN
1 3 4 5.0

In [5]: df2
Out[5]:
 a b c
0 1 2 <NA>
1 3 4 5

In [25]: df2.to_records(index=False)
Out[25]:
rec.array([(1, 2, <NA>), (3, 4, 5)],
 dtype=[('a', 'O'), ('b', 'O'), ('c', 'O')])

# listで受け取りたい場合
In [26]: list(df2.to_records(index=False))
Out[26]: [(1, 2, <NA>), (3, 4, 5)]

# コラム名を取得したい場合
In [27]: df2.to_records(index=False).dtype.names
Out[27]: ('a', 'b', 'c')

# nullableなdtypeを使わない場合の type
In [19]: list(map(lambda x: type(x), df.to_records(index=False)[0]))
Out[19]: [numpy.int64, numpy.int64, numpy.float64]

In [22]: list(map(lambda x: type(x), df.to_records(index=False)[1]))
Out[22]: [numpy.int64, numpy.int64, numpy.float64]

# nullableなdtypeを使った場合の type
In [23]: list(map(lambda x: type(x), df2.to_records(index=False)[0]))
Out[23]: [int, int, pandas._libs.missing.NAType]

In [24]: list(map(lambda x: type(x), df2.to_records(index=False)[1]))
Out[24]: [int, int, int]

0.23.4

In [45]: df = pd.DataFrame([{"a": 1, "b": 2}, {"a": 3, "b": 4, "c": 5}])

In [46]: df
Out[46]:
 a b c
0 1 2 NaN
1 3 4 5.0

In [47]: df.to_records(index=False)
Out[47]:
rec.array([(1, 2, nan), (3, 4, 5.)],
 dtype=[('a', '<i8'), ('b', '<i8'), ('c', '<f8')])

# 各値のtype
In [48]: list(map(lambda x: type(x), df.to_records(index=False)[0]))
Out[48]: [numpy.int64, numpy.int64, numpy.float64]

In [49]: list(map(lambda x: type(x), df.to_records(index=False)[1]))
Out[49]: [numpy.int64, numpy.int64, numpy.float64]

dtypeの比較ができない場合がある

Int64 などは numpy.dtype と比較できるが、 boolean, string とは比較できない。うっかり、DataFrameのdtypeごとに比較しようとすると死ぬ。

In [60]: pd.Int64Dtype() == "boolean"
Out[60]: False

In [61]: pd.Int64Dtype() == "Int8"
Out[61]: False

In [62]: np.dtype('float64') == "Int8"
.venv-10/bin/ipython:1: DeprecationWarning: Numeric-style type codes are deprecated and will result in an error in the future.
 #!/Users/aki/src/pytd/.venv-10/bin/python3.7
Out[62]: False

In [59]: np.dtype('float64') == "boolean"
---------------------------------------------------------------------------
TypeError Traceback (most recent call last)
<ipython-input-59-bc057c799968> in <module>
----> 1 np.dtype('float64') == "boolean"

これは回避の仕方が見つかっていない。

まとめ

当初は pandas.NA の挙動を調べるつもりで1.0前後の差異を調べたが、気がつけばすでに0.24のときに変わっていたことがわかった。1.0内での挙動も違ったりするし、 StringDtype などは experimental featureなので挙動は今後も変わりうる。msgpackへの変換などでPythonのpremitive型に変換するのは気をつける必要がありそう。

Jupyter Notebook/LabsをMLのどのフェーズで使うのか？

Sun, 09 Feb 2020 22:34:01 -0800

機械学習ではよく使われるJupyter Notebookですが、これを使ってプロダクションで動くコードを書くのは非常に難しいなと思い、皆どのように使っているのかを知りたくてアンケートをとってみました。

結果としては、多少拮抗しているのですが、EDAから予測までJupyter派が多かったようです。ついで、学習のプロトタイプまで、EDAだけ派と続いています。

この質問で失敗したなと思ったのは、「MLの開発」と書いたものの、研究・実験用途で使っている人とプロダクションまで持っていく用途で使っている人が混ざってしまったであろうという気がしています。ただ、1000票以上集まったので面白い結果となったのではないでしょうか。

その他の回答としては、Emacs派や全部.py派、全部C++派などがいることがわかりました。

はい，IPythonです。エディタですのであちこちカーソルを動かせます。別窓で*.pyを書いて，全部または範囲指定した部分を実行し，出力だけこのIPythonの画面に出すこともできます。 pic.twitter.com/Kkn6pxTUOR
— Haruhiko Okumura (@h_okumura) February 9, 2020

EDA から全部 .py でやっています。（僕の書き方が悪いだけかもしれないですが）Jupyter をメンテナンスするコストが高く、EDA を後から再現しようとしても動かなかったりするため、処理の要素ごとに関数を書いてそれらはメンテナンスをし、EDA は関数の組み合わせを変えることによって行っています。
— horiem (@yellowshippo) February 9, 2020

はい、可視化も .py でしています。初期の試行錯誤中にどうしても保存しておきたい図などは手動で保存してドキュメントなどの形にしていますが、基本的にはさっさとメンテ可能なコードを書いてしまって、実行のたび必要な絵が（解析条件とともに）自動的に保存されるようにしていますね。
— horiem (@yellowshippo) February 9, 2020

R派なので実はEDAとPOCまではRで、その先のPOCとプロトタイプの中間ぐらいのところまでをNotebookのPythonで書き、そこから先は他の人にお願いしてます https://t.co/Ehdj1MykMK
— TJO (@TJO_datasci) February 9, 2020

この結果が一概にML Ops的なプロダクション運用のことを考えた最適とは言えませんが、少なくとも現状でMLを取り組む人はかなりJupyterを愛用していることが伺えます。

2019年に買ってよかった漫画

Mon, 13 Jan 2020 09:53:00 -0800

Photo by Miika Laaksonen on Unsplash

出張などで国際線に乗ると、時間を消費するために漫画を買い込んでいきます。そんな僕が2019年に買ってよかった漫画を紹介します。割とメジャーどころが多いかもしれません。

アルテ

中世？イタリアの女性画家の話。女性が画家として働くのは珍しい時代に悩み、真剣に絵や絵の対象と向き合っていく。人間模様や主人公の成長が楽しい

空挺ドラゴンズ

アニメもNetflixで全話一気配信している。捕鯨船ならぬ捕龍船の乗組員たちのお話。アクションものかと思いきや主人公ミカの龍食に書ける食い意地でできているお腹が空く内容が多い。アニメも原作以上の見どころが増えていてどちらもおすすめ。1,2巻は今無料

BEASTARS

こちらもアニメがやっていたのでメジャーなタイトル。一言でいうと大人版ズートピア。肉食獣と草食獣が表向きは仲良く、しかし獣の本能と向き合いながら生きている世界の話。主人公のレゴシがとことん素直でいい狼で清々しい。少々血なまぐさいので苦手な人は避けたほうがいいかも。

ヘテロゲニアリンギスティコ

魔界のモンスターと言語・非言語両方を駆使してコミュニケーションを図る人間の言語学者の話。小説では表現が難しいようなコミュニケーションを上手く描いている。のんびりした世界観の中でコミュニケーションとは、と考えさせられる良い作品

片喰と黄金

ゴールドラッシュ時代に、飢饉真っ只中のアイルランドからアメリカはカリフォルニアを目指す漫画。ヴィンランド・サガの幸村先生の紹介で知ったけど、辛い局面でも前向きに前へ前へと倒れ込む勢いの主人公には元気をもらえる

鹿楓堂よついろ日和

鹿楓堂は「ろくほうどう」と読む。和風喫茶店を営む若い男性たちが美味しいメニューと個性的なお客さんたちとのやり取りが心温まる漫画。風邪で寝込んだときに読むと食欲が湧く程度には美味しそうな漫画です。割とのんびり読めます。

ライドンキング

どう見ても某国大統領なプルチノフ大統領が、突如飛ばされた異世界で様々な獣に乗る(ライドン)する話。劇画タッチの大統領と綿密に書き込まれた獣が送るギャグも多めのアクション漫画。某国では絶対に販売できないという噂もあるが、大統領は強く優しくかっこいい。大統領は強いんだけど、その振る舞いにはいつもいつも腹が捩れる。

2019年末年始に見た映画

Sat, 04 Jan 2020 14:13:00 -0800

パッドマン 5億人の女性を救った男

インドの生理用ナプキンを低コストで作った人の実話をもとにした映画。2001年にもなってナプキンを使わず汚い布で生理に対応していたインドで、55ルピーかかるナプキンを2ルピーまで抑えて製造する方法を確立した話。見応えがある良い作品。自作にかける妄執にも似た狂気的な執念を見ると、起業をするというのはこういうことかと思わされる。

シティーハンター THE MOVIE 史上最香のミッション

原作の大ファンのフランス人が監督主演までした作品。シティハンターのもともとのノリに下ネタ成分を倍増させた、いい意味でフランス製同人作品。これはもうアメリカでもヘタをすると日本でも作れない。頭空っぽにしてみられるバカ作品。

映画すみっコぐらしとびだす絵本とひみつのコ

大人向けの絵本を彷彿とさせるいい話感が少し強くて、自分には合わなかった。小さい子は楽しんでいたよう。心が擦れているからか。

スター・ウォーズ/スカイウォーカーの夜明け

エピソード9。7から見始めたにわかなのだけど、間のスピンオフ2作含めて5年見てきた割に一番？が並んだ。昔からのファンには良いんだろうなーと思いながら唐突な設定に置いてけぼりを喰らった。レイア姫が未公開映像を駆使して出ていた点と最後の盛り上がりはテンション上がったけど…、歴史に詳しくないと感情移入しづらい展開でした。多分、次に公開されると言われてるエピソード10はいいかな…。

ブラザーサンタ

原題は、Fred Clauseでサンタクロースの兄のお話。Googleのインターンに乗り込むインターンシップや俺たちニュースキャスターなどのおばか映画に出演するヴィンスヴォーン主演。彼が出るとどの作品も同じノリのおバカな役になってしまうのはご愛嬌。ケヴィンスペイシーをしてこのバカ作品に出すかという感じで下らないのが良い。

キングスマン

飛行機で見たゴールデンサークルが良かったので一作目も見た。Play Movieのジョニーイングリッシュのおすすめに出ていたのでコメディ要素もあるかなと思ったら、1作目はガチスパイ物だったがよかった。むしろ、ジョニーイングリッシュの3作目はこれのパロディであることがよくわかった。なぜ、イギリス映画はアメリカのIT成金を悪役にしたがるのか。

ちょいちょいブラックなユーモアや表現が出てくるのはイギリスを感じる。威風堂々をBGMに頭飛ばすとか…。スウェーデン王女は一作目からいい味だしてます。

Pythonistaのためのdigdag py> operator開発ガイド

Mon, 23 Dec 2019 07:00:00 -0800

Table of Contents

この記事は、の24日目です。

今年の夏に新しくTreasure Dataで使えるようになったPython Custom Scriptingですが、開発する際にどういう点を気をつければ良いのかという質問をいただくことが多いので、今日はTreasure Workflowとdigdagのpy> operatorを使った開発の際に気をつけることを書いて行こうと思います。

なお、Treasure WorkflowとありますがOSSのdigdagでも活かせる内容があると思います。

なお、既にPython Custom Scriptingが試せる環境にある方は、このGoogle Colab notebook で一通り試すことが出来ます。

workflowをpushするまえにローカル環境で開発とテストをする方法

基本戦略:Pythonのタスクを合理的な粒度にまとめる

Treasure Workflowやdigdagのサーバーモードでは、タスク間の中間ファイルを置くためのストレージがないため、一つ一つのタスクの粒度が大きくなりがちです。特に、Treasure Workflowでは一つ一つのtaskでコンテナが起動するため、そのオーバーヘッドを無視できません。一方で、一つの巨大なタスクは、開発時のデバッグを難しくさせます。そこで、開発時の戦略としては一つ一つは最低限の塊に分けた関数を用意します。そして、必要に応じてそれらを束ねる関数を用意するのが良いでしょう。

Treasure Workflow向けのworkflowをローカル環境で開発するにはいくつかの選択肢があります。

Treasure Dataの公式Dockerイメージを使う
Dockerイメージと同じPythonの仮想環境を使う

1. Treasure Dataの公式Dockerイメージを使う

基本的にはTreasure Dataが提供している公式イメージを利用すると、本番環境と同じイメージが使うことができるので良いでしょう。

その際には、他のPythonスクリプトの開発と同様に、切り分けた単体で実行できるようにして開発するのが良いでしょう。

if __name__ == "__main__":
 your_function("default_argument")

2019/12/23現在、最新のDocker imageは以下の2つです。

digdag/digdag-python:3.7
digdag/digdag-anaconda3:2019.03

PyCharmのProfessional Editionを持っている場合、Dockerのコンテナにremote debuggerがアタッチできるので便利です。詳しくはをご参照ください。

2. Dockerイメージと同様のPythonの仮想環境を作る

Python は仮想環境を作るための venv と呼ばれるモジュールがあります。これを使うことで他のプロジェクトと分離したパッケージの環境を作ることができます。

digdag-python:3.7

digdag-python:3.7と同様の環境を作るには、次のgistからrequirements.txtとconstraints.txtをダウンロードします。

その後、以下のようにコマンドを実行することでDockerイメージと同様のPython環境が構築できます。

$ python -m venv .venv
$ source .venv/bin/activate
(.venv)$ pip install -r requirements.txt -c constraints.txt

Note

この方法では、OSによる差異まで吸収ができない場合があります。例えば、digdag-python:3.7はDebianベースなので、OSレベルのパッケージ管理は apt-get を使いますが、それをスクリプト内に書いても実行ができません。

digdag-anaconda3:2019.03

anacondaイメージと同じ環境を作りたい場合は、gistからenvironment.ymlをダウンロードします。

その後、以下のコマンドを実行するとデフォルトの環境に依存するパッケージをインストールします。

conda env update -n base -f environment.yml

なお、新しい環境を構築したい場合は、environment.ymlの中の base を my-env など好きな名前に変更した後、以下のコマンドで新規仮想環境を作成してください。

conda env create -f environment.yml

py> operatorを含んだworkflowをローカルで実行する

もし、ローカル環境でworkflow全体を実行したい場合は、 ~~を使うことで、本番環境に近いdigdag環境が用意できます~~。

Warning

2019/12/23現在は、Treasure Dataではv0_10を使っていますが、将来これは変わる恐れがあります。

Warning

2021/02/14現在、v0_11へと移行しました。今後は適宜適切なブランチを使うようにしてください。

py> operatorにパラメータを渡す

py> operatorにパラメータを渡すには2つの方法があります。

digdagの引数を使う
環境変数を使う
digdagの変数でやりとりする

1. digdagの引数を使う

以下のような py_scripts/examples.py というスクリプトがあるとします。

def print_arg(msg):
 print(f"Message is {msg}")

msg という変数を print_arg という関数に渡す場合、以下のようなdigdagのtaskになります。

+simple_with_arg:
 py>: py_scripts.examples.print_arg
 msg: "Hello World"
 docker:
 image: "digdag/digdag-python:3.7"

もし、複数の引数をPythonの関数へ渡したい場合、digdagの引数を増やせばよいでしょう。

ここで注意してほしいのが、digdagの変数はPythonにシームレスに渡されるということです。つまり、 **kwargs などで引数を受け取る場合、意図しないdigdagの変数がPythonに渡る可能性に注意してください。

例えば、上の例では docker という変数には {"image": "digdag/digdag-python:3.7"} という辞書型の変数が代入されています。ですので、 **kwargs で受けるのではなく、明示的な引数の指定を強くおすすめします。

た、同様に意図しないdigdagの変数と py> operatorの引数の衝突が起こる場合があります。以下のようなワークフローがあったとします。

_export:
 td:
 database: my_db

+simple_with_arg2:
 py>: py_scripts.examples.print_arg_td
 msg: "Hello World"
 docker:
 image: "digdag/digdag-python:3.7"

このとき、Pythonのスクリプトは以下のような関数を持っているとします。

def print_arg_td(msg: str, td: str = None):
 print(f"'msg' is {msg} and 'td' is {td}")

simple_with_arg2 タスク実行時に print_arg_td 関数へ渡される引数 td は何になるでしょうか？通常のPythonの感覚では、デフォルト値である None が期待されます。しかし、 digdagのワークフローで td という変数がすでにexportされているため、引数 td には {"database": "my_db"} という辞書が格納されてしまいます。これにより、変数 td の型(dict)が期待されていたもの(str)との不一致が起こりうるのです。

このようなミスマッチを避けるために、digdagで予約されている変数やよく利用される変数を避けたほうが良いでしょう。特に td という変数や以下の変数は避けたほうが良いです。

td.endpoint
td.apikey
td.use_ssl
td.proxy.enabled
td.proxy.host
td.proxy.port
td.proxy.password
td.proxy.user

これらの既に利用されている変数は将来的に変更される可能性があります。

digdagの組み込み変数は次のドキュメントをご参照ください。

また、digdagは int から str など意図しない型の変換を行う場合があります。そのため、型のチェックや明示的な変換をおすすめします。

2. 環境変数を使う

環境変数は、py> operatorに変数を渡すためのもう一つの方法です。

TDのAPI keyやAWSのsecret keyなどセキュアな情報はこの形式でやりとりすることが多いです。

例えば、以下のような simple_with_env というタスクがあったとします。

+simple_with_env:
 py>: py_scripts.examples.print_env
 _env:
 MY_ENV_VAR: "hello"
 docker:
 image: "digdag/digdag-python:3.7"

このとき、 MY_ENV_VAR は以下のようにPythonから取得できます。

import os
def print_env():
 print(f'Env var is {os.environ["MY_ENV_VAR"]}')

Treasure Workflowではセキュアな情報を扱うためにdigdagの secrets を格納するデータベースを提供しています。

Digdag Secretsの設定フロー

Projectを td workflow push でプッシュする
secretsを td workflow secrets でデータベースに格納する
secretsを {secret:my_secret} という形式でworkflowに書き、環境変数経由でPythonにわたす

環境変数での受け渡しをしないとsecretsはPythonに渡されません。例えば、以下のようなワークフローとPythonスクリプトでは正しくsecretsに格納された td.apikey という情報が渡されます。

+simple_with_env2:
 py>: py_scripts.examples.access_td
 _env:
 TD_API_KEY: ${secret:td.apikey}
 docker:
 image: "digdag/digdag-python:3.7"

import os
def access_td():
 # Able to fetch API key like "1234/XXXX"
 apikey = os.environ["TD_API_KEY"]
 # Do awesome execution

しかし、以下のようにdigdagの引数として渡した場合はsecretsが評価されません。

+simple_with_env_ng:
 py>: py_scripts.examples.access_td_ng
 apikey: ${secret:td.apikey}
 docker:
 image: "digdag/digdag-python:3.7"

def access_td_ng(apikey):
 # Always shows "${secret:td.apikey}" instead of actual API key like "1234/XXXX"
 print(apikey)

secretsに関する詳細は、をご参照ください。

3. digdagの変数を使う

digdagのpy> operatorとして実行するPythonスクリプトでは、 import digdag とすることでdigdagモジュールを利用することが出来ます。

以下のように、 digdag.env.params と呼ばれる変数に辞書のようにアクセスすることでdigdagの変数を直接読むことが出来ます。

def read_workflow_env():
 import digdag
 print(digdag.env.params["my_msg"])

このとき、実行するworkflowは例えば以下のようなものになります。

_export:
 my_msg: "awesome message"

+simple_with_arg2:
 py>: py_scripts.examples.read_workflow_env
 docker:
 image: "digdag/digdag-python:3.7"

なお、読み込みだけではなくdigdag.env.storeを使うことでdigdagの変数の書き込みもできます。ただし、あまり大きな変数の受け渡しはしないほうが良いでしょう。

def store_workflow_env(msg):
 import digdag
 digdag.env.store({"my_msg": msg})

このdigdagモジュールは、digdagがpy> operator実行時に動的に生成しているため、ローカルでは実行できないことに注意してください。ローカルの実行を考慮する場合は、 try-expect を利用するのが良いでしょう。

try:
 import digdag
 digdag.env.store({"feature_query": feature_query})
except ImportError:
 pass

PythonやOSのパッケージのインストール方法

Treasure WorkflowではDocker imageに入っていないパッケージは os.system や subprocess.runを使い実行します。

import os, sys
os.system(f"{sys.executable} -m pip install --upgrade pytd==1.4.3")

import subprocess
# arguments should be passed by list
subprocess.run([sys.executable, "-m", "pip", "install", "--upgrade", "pytd==1.4.3"])

この際、パッケージのバージョンを指定しましょう。

OSのパッケージのインストールの場合も同様です。

import os
os.system("apt-get update") # Need to run before doing apt-get install
os.system("apt-get install -y wkhtmltopdf")

py> operatorを含むディレクトリ構成

一つのプロジェクトでは、以下のようなディレクトリ構成をおすすめしています。

my_project
├── README.md
├── config
│ ├── params.test.yml <- Configuration file for run through test. Mirror params.yml except for `td.database`
│ └── params.yml <- Configuration file for production
├── awesome_workflow.dig <- Main workflow to be executed
├── ingest.dig <- Data ingestion workflow
├── py_scripts <- Python scripts directory
│ ├── __init__.py
│ ├── data.py <- Script to upload data to Arm Treasure Data
│ └── my_script.py <- Main script to execute e.g. Data enrichment, ML training
├── queries <- SQL directory
│ └── example.sql
├── run_test.sh <- Test shell script for local run through test
└── test.dig <- Test workflow for local run through test

この構成に従ったdigdagプロジェクトをcookiecutter-digdagを使うことで簡単にテンプレートから生成できます。

実行時のエラーを通知する

Pythonのスクリプト実行時に発生したエラーをSlackなどで通知したい事があると思います。 digdagは _error: でworkflowが失敗した際の処理をできますが、そのとき${error.message}の中にPythonの例外情報が入っています。

以下のようなworkflowとPython scriptがあったとします。

+simple_raise_error:
 py>: py_scripts.examples.error_sample
 docker:
 image: "digdag/digdag-python:3.7"

_error:
 echo>: ${error.message}

def error_sample():
 int("a1234") # raises ValueError

このとき、以下のようなログが得られます。

2019-12-24 23:06:32 +0900 [INFO] (0039@[0:python]+simple^error): echo>: Python command failed with code 1: invalid literal for int() with base 10: 'a1234' (ValueError)
 from Traceback (most recent call last):
 from File ".digdag/tmp/digdag-py-2-1815457087076518360/runner.py", line 165, in <module>
 result = callable_type(**args)
 from File "/private/var/folders/y9/bnjb3krn39s22rmg_wvlnf7m0000gp/T/digdag-tempdir2111531196420040503/workspace/1_simple_1_2_2945225080250994454/py_scripts/examples.py", line 5, in print_arg
 int("a1234")
 from ValueError: invalid literal for int() with base 10: 'a1234' (runtime)

この例では、echo> operatorでエラーを出力しているだけですが、Slack等に例外を送ることで定期実行しているPythonタスクの通知が簡単に行なえます。

まとめ

このように、様々なポイントをおさえることでTreasure Workflowの開発をしやすくなるかと思います。また、digdagでもいくらかのポイントは使うことができるかと思います。

Facebook Prophetのplotをmodelオブジェクトなしでする

Sun, 08 Dec 2019 07:36:00 -0800

Facebook Prophetを使っているときに、グラフのプロットは model.plot() などを使うと思います。しかし、 model が存在せずもとの訓練データと予測結果のデータだけあるときにプロットしたいという場合もあるかもしれません。

基本的には、以下のコードを再利用すればplotできます。

実際のコードは以下の通り。

予測結果を df に、訓練データを df_prev に入れています。

気をつけないといけないのは、 ds カラムがきちんとソートしないといけないこと。

IBIS 2019の機械学習工学企画セッションに登壇しました

Wed, 04 Dec 2019 07:24:00 -0800

この記事は、の5日目です。

こんにちは、chezouです。先日、PFNの比戸さんにお声がけいただきIBIS 2019という日本で最大の理論系機械学習のワークショップで、に「継続的改善をし続けるための機械学習基盤の課題」というタイトルで発表しました。理論系のワークショップというのは知っておりアウェイ感半端なく、も受けましたが、なんとか実務者の皆様に届いてくれたのではないかと思っています。

Machine Learning in productionに対する9つの課題は、世の中にまだまだ整理されているものではなく難産だったので色々と議論ができればと思っています。9つの課題とdotscienceのLuke Marsden氏によるReproducible, Accountable, Collaborative, Continuousというを元に整理してみたのですが、どのような課題と抽象化を行っているのか、そしてそれがどういう嬉しさがあるのかへの理解の一助となればと思います。

Concept drift?

「学習時と予測時の分布の違いを検出するデータバリデーションが大事」という話をしました。で、この「学習時と予測時の分布の違い」というのを"Concept drift"という表現を使って説明をしたのですが、 shima__shima先生からもご指摘をいただき、どうも違うのではないかということで色々と調べたり議論をしていました。Concept driftは英語圏では雑に、特に産業界ではそれでいいかなという表現であるという認識です。ただ、もともとはストリームデータに対するdriftという定義があるようです。

人によっては"Covariate shift"(共変量シフト)や"Domain shift"という表現をするということから、Covariate Shiftがいいのかなと思っていましたが、“Delayed effect"という表現が時間的な変化に対する表現としてよいようです。ただ、個人的にはスライドでも書いたように光の変化は時間変化というよりは仮定する前提条件が覆された例だと思っているため、Delayed effectも少し狭いかなと思っていました。

なお、GoogleはTensorFlow Extendedの論文中で"training-serving skew"という表現を使っています。

以下、shima__shima先生の説明が参考になるかと思います。

共変量シフトは統計系の文脈ででてきて抽象的に分布が違うといった意味合いで最初に出てきました．
転移学習は機械学習分野で類似したデータという感じででてきました．2000年中頃はいろいろ呼び名がありましたが今では転移学習に落ち着いていると思います． https://t.co/4n1NXdWPAE
— しましま (@shima__shima) December 3, 2019

同じころ，コーパスの分野の違いというあたりから，Hal Daumé さんあたりがNLP分野でドメイン適応という言葉を使い始められました．
時間による変化で起きるならdelayed effect という言葉もあります．https://t.co/qVmBdO2fz3
— しましま (@shima__shima) December 3, 2019

機械学習工学セッションの他の発表

他の発表は、NIIの石川先生による機械学習工学とテストの話 ( )、STORIA法律事務所の柿沼先生の機械学習と知財の話( )でした。

石川先生の機械学習を工学として捉え直したときの説明や、adversarial testなどテストの最近の状況は自分自身追いかけられていなかったのでとても良かったです。

柿沼先生はAI模擬裁判などでご存知の方も多いと思いますが、先生の知財の話は学習済みモデル含めたシステムの権利は受託したベンダーか発注者のどちらにあるのか、という話も面白く、実践的で知見に富んだ話でした。ぜひML関係者はスライドを読むと良いと思います。また、柿沼先生への比戸さんの質疑から派生した議論をメールでさせていただいたのですが、機会があったら公開したいと思っています。

RとTreasure Data

Tue, 03 Dec 2019 07:00:00 -0800

この記事は、 3日目です。

公式ドキュメントは、のですが、RからTreasureDataを使うにはRJDBC以外にもいくつかの方法があります。

基本的には、RPrestoとRTDをおさえておくのが良いでしょう。

- Facebookが開発しているPrestoのR client。TreasureDataでもアドホックなクエリを投げるときに便利
- Rからdata frameをTreasure Dataにアップロードするのに使えるR client
- (12/18追記) レポジトリの場所がtreasure-dataの下になりました
- RStudio社が開発するRのSpark clientであるsparklyrのplugin
- 内部で使うtd-sparkはSparkのサポートバージョンが上がるのが速いが、sparklyrのSparkの新バージョンサポートが遅いので少し低調なメンテナンス

実際の、RPrestoとRTDの使い方は以下のRmarkdownを見ていただくのが良いかと思います。

RTDのインストール

インストールは、 devtools::install_github を使うか、 install-github.me を使うことでできます。

RTDは v0.2.0 からCRANに上げるのを辞めました。これはこれで一つの記事が書けるのですがそれはまた別の機会に譲ろうと思います。

余談ですが、CRANとの戦いの際にはr-wakalangの皆様に支えていただきました。Rに関する開発はもはやあそこなしには成り立ちません。にぜひ参加するといいと思います。パッケージングから統計モデリングも話まで物凄い勢いで有識者が答えてくれます。

source("https://install-github.me/treasure-data/RTD@v0.2.0")

インストール後は、apikey と endpoint を適切なものを渡して上げることで、uploadができます。例えば nycflights13 パッケージの flights データをアップロードしてみましょう。

library(RTD)

client <- Td(apikey = Sys.getenv("TD_API_KEY"), endpoint="api.treasuredata.com")
td_upload(client, "test", "flights", nycflights13::flights, overwrite=T)

v0.1.0 ではembulkが必須でしたが、今のバージョンは bulk import APIを使うようになっているため、特に追加でツールをインストールする必要はありません。

RPrestoでの接続

src_presto する際には、 user に TDのAPI keyを渡すこと、hostはを参照してください。schemaはDatabase名、 catalogは td-prestoのままにしてください。

library(RPresto)
library(dplyr)

db <- src_presto(
 host="https://api-presto.treasuredata.com",
 port=443,
 user=Sys.getenv("TD_API_KEY"),
 schema='test',
 catalog='td-presto'
)

flights_tbl <- tbl(db, 'flights')

flights_tbl にテーブルが変数として割り当てられました。が、実際にはdplyrの諸々の処理を実行するときにSQLが走るのでalias程度に考えてください。

dplyrとggplot2で可視化する

それでは、 flights_tbl をdplyrを使い集計して飛行機の平均遅延時間などを算出して、ggplot2で可視化してみましょう。

delay <- flights_tbl %>%
 group_by(tailnum) %>%
 summarise(count = n(), dist = mean(distance, na.rm = TRUE), delay = mean(arr_delay, na.rm = TRUE)) %>%
 filter(count > 20, dist < 2000) %>%
 collect

# plot delays
library(ggplot2)
ggplot(delay, aes(dist, delay)) +
 geom_point(aes(size = count), alpha = 1/2) +
 geom_smooth() +
 scale_size_area()

このような図ができたかと思います。

それでは、HappyなRとTreasureDataライフを！

Rパッケージ開発の闇

Sat, 30 Nov 2019 03:32:00 -0800

tl;dr

CRANに上げてたパッケージにGitHubのみリリースのパッケージへ依存を追加したら、自分もCRANに上げられなくなった
CRANはclosedな手動の塊なので、もう上げないよと依存先のメンテナは言った
もうCRANは忘れて、GitHubに上げればええやん ← イマココ

ここまでのあらすじ

1年前にこんな記事を書きました。

実はこれを書いていたのは、先日も記事に書いたRTDを久しぶりにリリースするというときだったと思います。

当時は、なんでこんなにリリースコマンドのときに質問ガンガンするんだとか思いながらこれを見ていたと思います。

ご存じない方のために説明すると、CRANとはRのセントラルパッケージリポジトリで、承認を得ないと登録できません。PyPIと違って、きっと malicious なパッケージもこれで防げますね！そこまで見てるかはしらんけど。

[2019/12/06追記]

全然だめみたいです

[/追記]

実はCRANサブミット時に、linterなどチェックを通しつつパッケージがルールにマッチしているかを人手で最後のチェックをしているのです。なので、2週間に一回くらいアップデートしろとか色々書いてあります。当時は、へー、頑張ってるんだなーとか思いながらサブミットをしていましたが、何しろ12月だったのでメールの返事が帰ってきません。なんだ、おいこのプロセスと当時も思っていました。余談ですが、日本人は正月に休みますがアメリカやヨーロッパだと12月がホリデーシーズンです。

久しぶりにCRANにパッケージをサブミットした

で、1年弱たって、RTDに新機能を追加してバージョンアップを図ります。今回は、msgpackを使ったバルクインポートを導入です。ついに、embulkへの依存が不要になりました！

ところで、Rのmsgpack実装は野良のものがわらわらあるんですが、msgpack streamに対応していたのがこのパッケージでした。

正直data frameからmsgpack streamへの変換がハマりどころいっぱいありましたが、なんとか実装できました。

で、このパッケージCRANに昔はあったようなのですがarchiveされてしまっていました。

最初は、 DESCRIPTION の SuggestsとRemotesに書いておいたのですが、まぁ devtools::check にRemotesが引っかかるではありませんか。そっかー、そういうこともあるよねー、という気持ちで困ったときのr-wakalangに相談してみました。

すると、識者の意見が出るわ出るわ。いやー、本当にr-wakalangは最高ですね！

テクニックとして出たのは、Suggestsには書くけど適宜ユーザーには必要になったらインストールさせるよう関数を用意するというものでした。

それでは、諸々済ませていざサブミット！

やあまた会ったね、Uweさん。彼は実は1年前にもすごく待った末にrejectしてくれました。なになに？SuggestsにあるやつがCRANにないって？うーん、困ったなということでまたr-wakalangにすごすごと戻ります。

なるほど、cran-comments.md! そうだね、僕たちには説明をする場所がある！というわけで、cran-comments.mdに実行時にインストールするから問題ないよ。という説明を書いて再度submit!

ところで、僕のcran-comments.mdは読んでくれたかな？まぁ読んでないよね。なになに、“Let me read them for you” だって？僕そのドキュメントもう何回もよんだわ！

うーん、どうやらrnaturalearthはCRANには上がっていませんが、Additional_repositoriesに上がっているようです。なるほど、これなら install.packages で入れられますね。

Additional_repositories: http://packages.ropensci.org

探してみると、GitHub pagesにRパッケージをアップロードしてがいました。なるほど！自前レポジトリに上げればCRANに上げれるんだ！

はて、CRANにパッケージを上げるために依存先を自前リポジトリに上げる…？控えめに言って糞だぞ？

依存先をCRANへと上げるようお願いする

仕方がないので、作戦変更です。msgpack-rの作者に頭を下げてCRANにあげてくれ！と頼むしかありません。自分のパッケージじゃないものを上げるために自前でリポジトリをホストするなんて正気の沙汰ではありません。

で、帰ってきたお返事（の抄訳）がこちら。

前述したとおり、CRANでは最後の人手でのチェックがあるのですが、そこの際にサーバサイドでチェックが走ります。で、このチェックというのがローカルで確認できるものとはどうも違うようで、特にWindowsのC依存のあるビルドが絡んでくると大変です。msgpack-rはRcppを経由してCで書かれたものをwrapしているので、当然そこの面倒臭さはつきまといます。

誰得なんだこのシステムは。

というわけで、CRANは諦めました。

GitHubにリリースでええやん

GitHubからのインストール自体は、 devtools::install_github を使えばできるのですが、 devtools が入っていない人もいるかも知れません。でもね、そういう人のためにinstall-github.meという便利なサイトがあるんです。

source("https://install-github.me/chezou/RTD@v0.2.0")

と書けばバージョンを指定してインストールができます。アップデートは多分自分でしないといけませんが…。

Rのパッケージを書くのは過去、RTD含めて3個しか行っていませんが、今どきこのきつい中央集権的なレポジトリのスタイルは厳しいなぁと思いました。

今ではCRANのパッケージを削除したいくらいです。GitHub最高！

VeinのiOSショートカット複数URL対応しました

Fri, 29 Nov 2019 23:16:00 -0800

この記事はの10日目です。昨日はでした。

VeinはNextIntが作ってる情報共有プラットフォームです。内輪のコミュニティや会社の中で皆がなにを見てるのかをカジュアルに共有する場所です。

作った思いはところてんが山のように話してるので見てみてください。

VeinはAndroidアプリしか現状モバイルにはないのですが、iOSはkikuchyさんの作ったショートカットがあります。

ただ、これはテキストに複数URLが入っているとうまく処理できなかったので改良しました(お前のことだぞ、ニコニコ漫画iOSアプリ！)

これでニコニコ漫画の尊い回をシェアし放題ですね。

また、Veinの隠し便利機能としてpostしたものをSlackに共有するというのができるのですが、僕はfavしたものをSlackのtimes的なチャンネルに流しています。で、いちいちveinにいってfavするのが面倒なのでfav対応のショートカットも作りました。最後のpostするときのパラメータに vote=true を入れているだけです。

なお、余談ですが、ショートカット編集するとTwitterやFacebookなどショートカット対応アプリは同時に投げれます。Slackは無理でした。

Twitterとの同時投稿はこれを使えば出来ます。なお、Appを選んで差し替えればFacebookとの同時投稿もできます。

明日はなんでも溶かすtaichiさんです。

mecab-python3を捨ててnatto-pyにしよう

Thu, 28 Nov 2019 21:58:00 -0800

tl;dr

~~mecab-python3は使い勝手が悪いのでやめよう~~ 後述するPaulがメンテナになってWindowsも含めたwheelが提供されたので今はだいぶマシです
- IPAdicを使う場合にpip installで辞書を入れる必要があるのは注意（なんでwheelに辞書混入してたんや)
代わりはがおすすめ
- fugashiも選択肢としてあります（が、デフォルトUnidic推しなのでIPAdic使いたい人は説明読んでね）

mecab-python3を止める理由

メンテナが変わってDebianのパッケージを書いている人になったため、ユーザ寄りというよりは開発側の理屈が強く優先されるようになった。良くも悪くもUNIX的な思想？（一つ一つのやれる事は小さくというパイプ的なアレ）なんだが、これがすこぶるwheelのfat binary packageの方向性と相性が悪いと思う。具体的には

Source build時にswig必須に
WheelもIPAdicのみサポートでLinuxとmacOS向けのみ

つまり、Neologdがデファクトとなった現代では使いづらさしかないのでやめたほうがいい。機械学習の教科書的な本では必ずmecab-python3が出てくるが、あれは古い話と思ったほうがいい。

MacとLinuxのユーザは迷わずnatto-pyを使いましょう。nattoシリーズはFFIベースでmecabを使うので、余計なバインディングのビルドは必要ありません。また、作者にお話を聞いたところ、Windows環境で動かすことを一つのモチベーションにしているとのことなので、割とWindowsユーザにも良いかと思います。

Windowsユーザは以下の記事を読んで、libmecab.dllを手に入れてnatto-pyを使いましょう。

余談だが、最近spaCyがfugashiというMeCabのCython wrapperに依存するように変わったが、これは今のところUniDic専用だ。この背景はmecab-python3がほぼIPAdic専用になったからだろう。なお、韓国語はnatto-pyを使っている。

natto-pyは作者に聞いたところ、もうmecabがメンテナンスされていないのでnatto自身もあまり大きな変更はしないだろうとのこと。

natto-pyの簡単な使い方はこれを見るといいと思う

mecab以外の方向性

sudachiPyとGiNZA, spaCy の組み合わせに期待している。これは、マストドンのトレンドワードの記事を読んでもらえれば使い方はわかるだろう。

ただ、sudachiPyはmecabと比較すると速度的に遅いことと、sym linkを使っている関係でまだWindowsでは動かないというネックがある。Windowsで動かすの自体は対応してもらえそうな雰囲気を感じているので、手伝っていきたい。

SentencePieceはNN向けの前処理にはいいと思うけど、語彙数を決めて分割しにいく性格から、トレンドワードをとりにいく的なのには向かないんだろうなと思っている（教えて詳しい人）。

mecab-python3はオリジナルのクリエーターが、もう使ってないんじゃないかなー。彼の最初に作ったモチベーションは簡便なパッケージを用意すると言うところだと思うのにどうしてこうなった。

[20191217追記]

[/追記]

[20191225追記]

どうやら、fugashiの作者のpolmさんが新オーナーになる方向で進んでるらしい。新しいrepoは下記になる予定。

[/追記]

ストレートネック向け最近の枕事情

Tue, 26 Nov 2019 03:17:00 -0800

以前、首狩り族のネックピローをいただいてから、かなりストレートネック気味な状況が改善されて非常に良い。

ただ、出張がちょいちょいあってそのたびにつらい思いをしていたのだけれど、実家で使ったときにとても高さも低くて快適だったので、先日の名古屋出張で急遽これを買った。東急ハンズにも売っているので急いで買いたい人にも便利。

何がいいかって、とにかく高さが低い。3cmくらいしかないんじゃないかな。その割にしっかりしてる。さらに、こんな感じでくるくるっと巻けるので持ち運びもできるところもよい。

補間的にこの首を乗せるアイテムも使っていますが手軽にマッサージができて気持ちいいです。

GitHub ActionsでIssue templateに従っていないissueをcloseする

Mon, 25 Nov 2019 00:52:00 -0800

GitHub ActionsはissueやPRのcreateをトリガーに動いてくれる。

このActionを使えば正規表現でtemplateをチェックして自動でcloseする。経験上、面倒くさい人は大抵読まずにtemplate全消ししてくるので、貧弱な正規表現でも十分役に立つ。

実際のworkflowはこちら。

ポイントは以下のように雑に .*((PATTERN_A)|(PATTERN_B)).* と書いてあげれば良い。

issue-pattern: ".*((Is your feature request related to a problem)|(Check list before submit)).*"

なお、この正規表現はJavaScriptの RegExp として動くのでChromeのconsoleなんかでテストすればいい。

var regexp = new RegExp(".*((guidelines for Contributing)|(Check list before submit)).*");
regexp.exec("aaaaaaaguidelines for Contributingbbbb")
// (4) ["aaaaaaaguidelines for Contributingbbbb", "guidelines for Contributing", "guidelines for Contributing", undefined, index: 0, input: "aaaaaaaguidelines for Contributingbbbb", groups: undefined]

こんな感じで動く。

GitHub ActionsでAPI tokenを使ってPyPIへリリースする

Sun, 24 Nov 2019 23:59:00 -0800

ふと思い立ってtravisを捨ててGitHub Actionsを使ったPythonのテストを行うようにしてみた。また、ついでにPyPIへリリースもできるようにしてみた。

GitHub ActionsをPythonのテストに使う

GitHub ActionsをPythonに使うメリットとしては

OS (Ubuntu, macOS, Windows) や Python versionのmatrixが使えて複数バージョンのテストが楽
JDKなど追加の依存のインストールも uses を使ってサクッとできる
起動もまあまあ速い

といった点が上げられる。

例えば、JDK 12を入れようと思ったら、このような記述をしてあげれば良い。楽。

- uses: actions/setup-java@v1
 with:
 java-version: '12'
 java-package: jdk
 architecture: x64

一方、残念な点としては

Windowsのtemp directoryへの書き込みが何故かできない
マイナーなハマりどころに対して情報が少なくデバッグも厳しい

というところだろう。

実際のテストのワークフローはこちら

GitHub ActionsからPyPIへリリースする

実際のworkflowを見てもらうと速いと思う。

もともと、公式で用意されていたWorkflowはReleaseが作成されたときにpublishされるというものだったが、でタグを付けるとバージョンも付与されるようにしていたので、

tagをpush (するとversionも付与される)。あるいはtagをGitHubで作成しても良い
GitHub Actionsによって、tagからreleaseが作成される
releaseからwheelを作成、PyPIへAPI Tokenを使ってpublishする

という流れを作ってみた。便利なのはtagを打ってpushするだけでこれが行けること。

ポイントは

on:
 push:
 tags:
 - 'v*'

のように、トリガーをtagsにすることと

deploy:
 needs: release

のように、 release jobを依存関係として追加すること。

PyPIのAPI Tokenは、予めPyPIにて取得しておく。Project単位でのscopeを設定できるので、今回はtabula-pyのアップロードのためにだけ使うことにした。 Projectの Settings → Secrets から PYPI_USERNAME を __token__ に、 PYPI_PASSWORD を pypi- からはじまるAPI Tokenにすれば良い。ちょいちょいこの仕様が変わっていたこともあるので、最新情報はを確認してほしい。

TWINE_USERNAME: ${{ secrets.PYPI_USERNAME }}
TWINE_PASSWORD: ${{ secrets.PYPI_PASSWORD }}

Workflowの中にはtwine用の環境変数が用意されている。便利。

digdagのworkflowをCIでrun throughする

Sun, 17 Nov 2019 08:38:00 -0800

以前、kawasaki.rbやマジフェスでdigdagのworkflowのデバッグやテストどうすればいいんだ〜という話をしました。

この話は、でかいデータと戯れるworkflowをどうdebug、テストすればいいのかという話から、PyCharmとDockerでdebugするという話をしましたが、今回はworkflowを実際にrun throughできるようにするためのtipsとそれを実現するためのcookiecutterを作ったので紹介しようと思います。

cookiecutter-digdag

はPythonで書かれたプロジェクトを作るためのテンプレートです。内部ではPythonのtemplate engineであるjinja2を使っており、普通HTMLをレンダーするために使うものをconfiguration fileやfile名、directoryに使ってしまおうと言うものです。

$ pip install --user cookiecutter

でcookiecutterをインストールしたら、

cookiecutter https://github.com/chezou/cookiecutter-digdag

とすれば、ディレクトリ以下に新しいpy> operatorを使ったdigdagプロジェクトができます。

my_project
├── README.md
├── config
│ ├── params.test.yml <- Configuration file for run through test. Mirror params.yml except for `td.database`
│ └── params.yml <- Configuration file for production
├── awesome_workflow.dig <- Main workflow to be executed
├── ingest.dig <- Data ingestion workflow
├── py_scripts <- Python scripts directory
│ ├── __init__.py
│ ├── data.py <- Script to upload data to Arm Treasure Data
│ └── my_script.py <- Main script to execute e.g. Data enrichment, ML training
├── queries <- SQL directory
├── run_test.sh <- Test shell script for local run through test
└── test.dig <- Test workflow for local run through test

run through testをCIで走らせるためのポイント

これだけだとふーんなんですけど、ポイントとしては test.dig に詰まっています。

_export:
 !include : config/params.yml

_error:
 td_ddl>:
 drop_databases: ["${td.database}"]

+ingest:
 call>: ingest.dig

+execute:
 call>: {{cookiecutter.main_workflow}}.dig

+cleanup:
 td_ddl>:
 drop_databases: ["${td.database}"]

特徴は

config/params.yml にDB名の設定を指定する
ingest.dig でデータのDBの作成とデータの書き込みをする
{{cookiecutter.main_workflow}}.dig (デフォルトは awesome_workflow.dig )でcookiecutter使用時に指定されるメインのワークフローをcallする
cleanup と _error taskでDBを削除する

という4点です。

実際には、テストは run_test.sh を実行することで行われるのですが、その中身を見てみましょう。

mv config/params.test.yml config/params.yml
{{cookiecutter.digdag_path}} run test.dig

digdag_path はデフォルト digdagとなり、local modeでdigdagを実行します。

mv config/params.test.yml config/params.yml と params.test.yml に差し替えをするのですが、

# Target Database on Treasure Data
td:
 database: "{{cookiecutter.database}}_${session_uuid.replace(/-/g,'_')}"
 table: {{cookiecutter.table}}

このように、 _${session_uuid.replace(/-/g,'_')}とユニークな文字列を作ることで、一時的なDB名を作るようにしています。

このやり方をすることで、メインのワークフローに極力触ることなく、CIでlocalモードのdigdagを使い走り切るかのテストができます。実際にこの構成で行っているworkflowの例はレポジトリにあるので、参考にしてください。

150 successful Machine Learning models: 6 lessons learned at Booking.comのメモ

Sat, 16 Nov 2019 13:15:00 -0800

各所で話題のBooking.comがKDD2019で発表した論文のメモ

元論文:

何を予測しているのか

Traveler preference model
Traveler Context Model
- 家族なのか、カップル、友達同士か、ビジネスか観光か、など
- 家族判定をすると子供の入力を促す
Item space navigation model
User interface optimization model
Content curation
- これだけきいてなかった
Content Augumentation

3 MODELING: OFFLINE MODEL PERFORMANCE IS JUST A HEALTH CHECK

MLCTで昔からグノシーの関さんが言っていた話だが、実際にモデルの精度改善とKPIとが相関すらないのを図示していて良い。

あと、精度改善してもKPIはサチるからな、という話も言われてみればそりゃそうだ。

ProxyとなるKPI(CTR)に過剰に最適化しても、本当のビジネス指標のCVRは上がらない、という話はCTRに寄せすぎた不快な広告の話を思い出す。

5 DEPLOYMENT: TIME IS MONEY

予測のレイテンシーが30%上がると0.5%CVRが下がったので、相関あるか見てみたよという話。

高速化のための手法

Model redundancy: モデルをコピーしてクラスターにdistribute
In-house developed Linear Prediction engine: 自前で線形予測エンジンを内製。内積を使うモデルを高速化
Sparse model: パラメータ数が減ると計算時間が減る
Precomputation and caching: 特徴空間が小さいときは予測結果をKVSに入れる。大きいときでも高頻度のリクエストをメモリにキャッシュする
Bulking: ネットワーク負荷を減らすためにまとめて1リクエストにする
Minimum Feature Transformation: 特徴計算の回数を減らして高速化する

なお、これらはシンプルなインターフェースでデプロイとmodelのconsumeができるように抽象化されており

prediction latency
high availability
fault tolerance
monitoring

をクリアしている。

モニタリング: 教師なしの赤信号

Issues for label dependent feedback
- Incomplete feedback
  - 特定の条件下（予約時）ではtrueラベルがつくが、そうではない条件のときにtrueラベルがつかず発火しない
- Delayed feedback
  - 数日〜数週間、数ヶ月後にしかtrueラベルが得られないケース。
教師なしのResponse Distribution Charts
- 予測結果のhistogramで判断
- 0-1の中心に高頻度の単峰性の山 → High bias model or high Bayes error in data
- 極端に高頻度なmodeがあるとき → スケールミスか学習データの外れ値
- ノイジーな分布は極端なsparse model
- 双峰性の分布は2クラスをきちんと分類している
便利なヒューリスティクスだけど、modelが高品質かどうかはわからない
estimators（regression?） or rankersには使えない

他で紹介されていないところを中心にメモしたが、論文直接読んだ方が面白い。

spaCyとGiNZAでマストドンのトレンドワード抽出をしてみた

Sat, 16 Nov 2019 07:24:00 -0800

Google Colabolatoryのフォームを使えばエンジニアではない人もテキスト解析をぽちっと解析できる環境ができることがわかったので、マストドンのトレンドワード分析のためのノートブックを書いてみた。

ノートブックはこちら。

なぜMeCab + NeologdではなくspaCy+GiNZAなのか

最初は、mecab+neologdを使っていたのだけれど、名詞だけの抽出だと"MacBook Pro"が"MacBook"と"Pro"と単語が分割されすぎる嫌いがあってコンテキストが欠落してしまうと全然うれしくないと思って頭を抱えていたところ、spaCyとMegagon Labsが開発する日本語用のGiNZAのチュートリアルを見つけたので試してみた。(どうでもいいけど、GiNZAはPyPIでwheel配布しないかな…)

spaCy+GiNZAを使うと、以下のような簡単なコードで、キーワード（この場合、固有名詞と名詞句）が取れる。

import neologdn
import spacy
nlp = spacy.load('ja_ginza')

def extract_words(sentence):
 docs = nlp(sentence)

 words = set(str(w) for w in docs.noun_chunks)
 words.union(str(w) for w in docs.ents)
 return words

text = "キーワードを抽出したいセンテンスをここにいれます。"
extract_words(neologdn.normalize(text))

特に名詞句を勝手にとってくれるのが楽で、先の"MacBook Pro"が1単語として獲得できる。

また、Neologdは辞書をいちいちgit cloneしてbuildしないといけないため、インストールに時間がかかるため、Colabで実行するにはちょっと待ち時間が長い。

実際に使った感じ

マストドンでは、さんが特定の期間のtootをリストできるがあるのだけれど、これのURLを入れればその期間（一日全体のキーワードだったり、Podcast放送中）のキーワードが取れるので意外と便利。

とはいえ、ストップワードをチクチク設定しているのはいつもの通り。本当はbotをどこかで動かして定期的にtootしたいところだが、気が向いたらかな。

ある日の上位20個のトレンドワード。デスストが流行ってる

NotionのページをCloudflareでsub domainに転送する

Sat, 16 Nov 2019 06:50:00 -0800

Notionはリッチなメモツール（？）としてじわじわと人気が出ている。モバイルアプリでもPCでも書けるのでメモ書きや調べ物をするのにも重宝しているし、最近ではwebクリッパーがあるので便利にセルフブックマーク用途に使っている。

mediumのpay wall圧力のおかげでblogの移行先を色々と探していたのだけれど、まずは雑なメモを置ける場所を公開してみようと思う。

2021/10/29追記 ~~この方法は完全に使えなくなったので、諦めてをにリダイレクトすることにした。~~

カスタムドメインの設定方法

残念なことに、Notionまだカスタムドメインを提供していないのだけれど、それをCloudflareのworkerを使って実現するgistと記事を見つけたので試してみた。

大まかなやり方は

「Cloudflareのworkersを使うとJavaScriptを使ってredirectを設定できる」

というものである。

オリジナルのgistはmayneyaoさんがこちらに上げている。

mayneyaoさんは英語がネイティブでないため、スクリーンキャストを使って説明をしているが、英語の記事にはこちらの記事があり、こちらのほうがわかりやすかった。

サブドメインの設定方法

どちらの記事でも、サブドメインなしのドメインを設定しているが、これに付け加えてsub domainを指定したいときの設定を書く。

1. javascript中のMY_DOMAINをサブドメインまで指定する

見ていただければわかるとおり。

const MY_DOMAIN = "memo.chezo.uno"

ちなみに、 START_PAGE はパブリックなユーザー名の入っていないページなのでGoogle Chromeのプライベートモードなどで確認してから貼ると良い（自分はこれにドハマリした）

あと、CORSヘッダーはデフォルトが全部受け入れることになっているので、ちょっと制限した。

const corsHeaders = {
 "Access-Control-Allow-Origin": "chezo.uno",
 "Access-Control-Allow-Methods": "GET",
 "Access-Control-Allow-Headers": "Content-Type",
}

2. DNSでCNAMEを指定する

この場合、 memo というCNAMEをにProxiedされるように設定を追加すればよい。

以上で、がNotionになっていると思う。

Pythonのdigdagクライアントtdworkflowを作った

Sat, 16 Nov 2019 05:14:00 -0800

はsimpleなyamlでworkflowを書けるOSSでTreasure Dataが中心になって開発しています。

digdag本家のv0_10ブランチをベースにPythonクライアントを作りました。位置づけとしてはdigdagのREST APIを叩く薄いwrapperです。

GitHubにソースコードは公開してありますし、にもおいてあるので

pip install tdworkflow

で試すことができます。

Google Colaboartoryノートブックがあるので、TDアカウントがある人は試してもらえると良いと思います。（実行にはGoogleアカウントでログインが必要です）

Treasure Workflowにつなぐ例

import os

from tdworkflow.client import Client

apikey = os.getenv("TD_API_KEY")
client = Client(site="us", apikey=apikey)
# Or, write endpoint explicitly
# client = Client(endpoint="api-workflow.treasuredata.com", apikey=apikey)

projects = client.projects("pandas-df")

secrets = {"td.apikey": apikey, "td.apiserver": "https://api.treasuredata.com", "test": "secret-foo"}

client.set_secrets(projects[0], secrets)

client.secrets(projects[0])
# ['td.apikey', 'td.apiserver', "test"]
client.delete_secrets(projects[0], ["test", "td.apiserver"])

digdagにつなぐ例

Treasure Workflowのための、と書いてあるけれどOSSのv0_10ブランチベースなので、0.9.x系でも動くと思います。以下の例ではにあるdigdagサーバーに接続しています。

import tdworkflow
import requests
session = requests.Session()
client = tdworkflow.client.Client(endpoint="localhost:65432", apikey="", _session=session, scheme="http")
client.projects()
# [Project(id=1, name='python-tdworkflow', revision='134fe2f9-ded3-4e7c-af8e-8a82d55d688b', archiveType='db', archiveMd5='5Lc6F6m3DtmBN4DA5MzK8A==', createdAt='2019-11-01T13:03:26Z', deletedAt=None, updatedAt='2019-11-01T13:03:26Z')]

モチベーション

目的としては、Google Colabolatoryからtreasure-boxesというサンプルワークフローをTDにデプロイすることが当初のゴールでした。digdadのsecretsを設定するのにdigdag CLIからじゃないとだめとかが面倒くさいなあと思い、まぁREST APIがあるから大丈夫だろうと思ってカッとなって作りました。

ドキュメントとGitHub repo

最近やたらとapidocとSphinxでドキュメント生成しているのだけど、その話もまとめられればと思っています。

APIデザイン等は変更される可能性がまだまだありますが、バグなどがあれば、GitHubのissueへお願いします。

『n月刊ラムダノート』創刊記念パーティに登壇しました

Mon, 03 Jun 2019 21:33:18 -0700

さる5/30に『n月刊ラムダノート』創刊記念パーティーという名のコルーチン祭りを開催しました。

同僚のさんからふらっとトレジャーデータ東京オフィスにイベントスペースができたので、エンジニア向けイベントやりませんか？と振られたので、軽いノリでやってみました。同会場でほぼはじめての100人近くに向けたイベントで、Envoyのオペレーション等々参加者の皆様にもお手間をおかけしましたが、無事できてよかったです。（TDマーケチームの皆様、ラムダノートたかお様、とてもとてもお世話になりました）

僕は『「MLOpsの歩き方」を書いた話』というタイトルで、n月刊ラムダノートに寄稿する方法について話しました。

また、僕の話は前座だったのですが、本命のコルーチンの話は大いに盛り上がりました。座談会の様子を録音してPodcastとしてリリースしたのでよければこちらもお楽しみください。

「n月刊ラムダノート」の記事の書き方～「MLOpsの歩き方」編

Thu, 28 Mar 2019 12:01:40 -0700

先日、ラムダノートから創刊された「n月刊ラムダノート」に「MLOpsの歩き方」を寄稿しました。

他の著者の記事などでいろいろと話題になっていますが、「TCPの再送制御機構」から『「コルーチン」とは何だったのか？』、そして僕の書いたMLOpsの話までと、幅広いテーマが取り扱われています。

個人的には、かしたのでちょっと嬉しかったです。

僕が書いた内容はMLOpsと呼ばれる、機械学習システムやプラットフォームで皆が手探りに行っている本番環境への適用や運用が、なぜ機械学習が絡むと難しいか、どういうアプローチがあるのか、といったところを（網羅的ではないかもしれませんが）ある種サーベイ論文のような形でまとめてみました。良ければ読んでいただいて感想を聞けると嬉しいです。

寄稿するまでにしたこと

「n月刊ラムダノート」は皆様の記事の寄稿を受け付けています。詳しくは以下の記事をお読みいただければと思います。

ターゲットとしている記事は、上記の記事から抜粋すると

「自分が専門とする分野の解説を、関連する他分野の技術者や若者に向けて残しておきたい」
「公開したい技術文書があるけれど、論文のようにフォーマルな内容ではないから、個人ブログで公開するしかないかな」
「技術書を書きたい。でも、いきなり本を一冊書くのは大変だ」

という感じです。「仕事ではじめる機械学習」のときも思いましたが、プロに編集していただくと、自分の思考や考えが理解されやすい形に整理されるというメリットがとても大きいので、知ってもらいたいネタがある人は是非応募して欲しいと思っています。

でも、「いきなり雑誌の寄稿とか…」と思う方の助けになればと思い、自分がしたことなどをまとめていこうと思います。

1. 寄稿する決意を固める

2018年11月頃にさんから、「こういうような雑誌を立ち上げたいんだけど、BERTの記事書いてもらえませんか？」と言われたのがきっかけです。BERTの話はもっと適切な人がいると思ったのでお断りしましたが、かねてよりまとまった文章にしたいと思っていたMLOpsについて書かせてくださいという話をしました。

いろいろと雑誌の方向性をお聞きする中で、人工知能学会の「」という、あるトピックに関する論文よりは軽いサーベイ記事のことを思い出し、サーベイ＋それらを体系化ができればいいなと思いOKしました。

議論の中で「いろんなIT系技術書から1章ずつ選んできた解説記事の集まり」というコンセプトも出てきたのですが、わかりやすいなと思う反面1章が一番大変だったなぁ…というのを思い出しました。

2. 書く内容をぼんやり考える

記事募集の中でも言及されていたように、まずは以下の質問に自分で答えを作ります。

この記事を理解するために、読者が最低限できてほしいこと（〇〇は理解していてほしい、△△を使った経験がほしい、など）
この記事を読むと、どうなれるか（〇〇の論文が読めるようになる、△△を作れるようになる、□□で話ができるようになる、など）
この記事に対する執筆者自身の専門性（研究者である、職務で〇年間利用している、実装を開発した、など）
この記事に近い内容の既刊書や記事（可能なら参考文献とは別に）

この時点で、GitHubのprivateレポジトリをいただいていたので、issueにまとめていきました。

また、合わせて章立てやコンテンツを考えるためのMindmapを作りました。とはいえ、自分の知っているだけの情報で足りるかがわからないので、3の情報収集と並行してブラッシュアップしていました。

MLOpsの歩き方のマインドマップ

3. 下調べをする

MLOpsは産業界でボトムアップに動いている分野なので、まとまった論文になっているものはそこまで多くないのが現状です。ベースとなるGoogleのMLの技術的負債に関する論文や、すべての起点であるGoogleのTFX論文、それからFacebook, Uber, Airbnbなど各社の論文、スライドを改めて読み始めます。（なお、TFX論文は各社のML基盤に影響を与えているのでMLOpsに興味がある人は読むことをおすすめします）

文章の構造や論文やスライドはを使ってメモしていきました。以下が、そのメモです。本文というところに初稿へのリンクもあります。

Notionの編集画面

Notionのいいところは、だらだらと1ページで書き始めて一部をくくりだしてsubページにしようと思う場合手軽にできるところです。

4. 初稿を書く

材料を揃えたら、あとは考えていた構成に合わせて書いていくだけです。とはいえ、サーベイ的な要素が強いので「どう体系化したらいいだろう」というのは手探りで整理をしていきました。ちょうど、年末年始という時間があったので、「年末進行失敗するとこうなるのか～」と思いながら書いていました。

まず目指したのは、の「内容をすべて書き出した」状態です。

「執筆・編集のためのGit（GitHub）ワークフローを考えてみた」より

ちなみに、初稿を書くのもNotionで書いてMarkdownでexportしました。iPad Proで原稿を書いたり、途中で調べたものの追加をPixel 3でやったりといろいろなデバイスや環境でやれるのが楽でした。

5. 編集に入っていただく

ざっと書き出して、自分の中で構造をある程度こねこねしたら、いよいよGitのcommitをしてGitHubでの編集に入ってもらいます。

とはいえ、この段階では事例紹介色が強く、課題と解決策の対応が弱いという不安を抱えながらpushしました。この不安はissueとPRをしていただきながら編集によって解消されたのですが、一人では解決できなかったと思います。

PRベースの編集の様子

著者である自分はコンテンツの足し算をしたがるのですが、編集者からは足すことはできないので、構造に手を入れたり引き算をすることで論旨を明確にするのだ、という話を聞いたときには目からウロコでした。

6. 上がってきたPDFをチェックする

紙とPDFでのですので、上がってきた原稿が体裁を整えた形のPDFになって受け取ります。これを最後にチェックして、ミスのチェックをします。いつも思うのが、MarkdownやRe:view, Sphinxなどが生成するPDFから商業用の体裁になると、中身がすごく良くなったように感じますね。

最後の修正を終えたら、著者としては原稿への作業は終了です。

7. 発売前に宣伝する

これはoptionalなのですが、発売前に自分たちが主催するMLCTというイベントがあったため、そこの主催者のお話のコーナーで宣伝させていただきました。

なお、そこで宣材用に草稿を渡していただいたのですが、表紙を見て初めて他の著者の方を知りぶったまげました。

記事を書いてみませんか？

技術書典のおかげで、技術系同人誌に対するハードルがとても下がったと思います。「n月刊ラムダノート」はテーマ設定がきちんとできれば、それに近い感覚でプロの編集を受けられるのは良いのではと思います。紙の力はまだまだ偉大で、職場などで物理で広まるというのは強力です。その恩恵を手軽に受けられるのも魅力でしょう。（在庫とか自分で管理したくないよね…）

ブログを書くより腰を据えて書きたいけど、本を一冊書くのはしんどいし時間もかかる。プロの編集の力も借りて、自分の頭の中にある情報をまとめて広めたい、そういう人には「n月刊ラムダノート」はピッタリの場所でしょう。

首や肩に優しい海外出張に便利な道具達

Sat, 09 Mar 2019 16:01:03 -0800

ちょくちょく人に海外に行くときに持って行った方が良いものを聞かれるので、メモがてら書いておきたいと思います。首や肩を痛めてから、色々と試行錯誤をしているのですが、ある程度形になってきたかなと思うので愛用品を紹介したいと思います。

一般的旅行用品

トランクを整理する系は、無印良品にお世話になっています。

定番ですが、吊るして洗えるこのポーチはタオルハンガーに引っ掛けて置けるので良いですね。

ポーチの中に必要なシェービングジェルや寝癖直しなどはこの手のもので整理しています。

トランクの中はこれで整理をしています。たためるので必要に応じて小さくできるのが便利ですし、形状も箱型なのでトランクの中を効率よく使いやすいです。

合わせてこちらの洗濯できるケースもあると、滞在先で洗濯する場合や帰ってきてからの洗濯物を入れるのに便利です。

紙パンツ

backspace.fmのdrikinさんオススメの一品。出張が一週間以内の時にはハッソーの紙パンツが便利です。ファミマで売っている紙パンツと同じで、不織布ベースですが履き心地が良く、普通のパンツとの違いは前の穴があるかどうかくらいです。最近は2週間程度洗濯機が付いているコーポレートアパートに滞在することが多いので、活躍する頻度が減っていますが、国内旅行でも帰ってからの洗濯物が減って便利です。

ケーブル整理

旅行用の充電器やケーブル類はこちらのゴムで固定できる商品にまとめています。小さいケーブル類や変換系、果ては充電器までまとめられるので便利です。

出張用のケーブル類を常にセットしておいて、ぱっと取り出せるようにしています。

着圧タイツ

以前、さんがオススメしているのをみて試してみましたが、フライト後のむくみ、足の釣り感が減って大変楽でした。フライトの直前、直後に履き替えるのが少しだるいですが、その後のパフォーマンスを考えると良いものです。

ノイズキャンセリングイヤホン

ノイキャン性能で言えばBOSEのQCシリーズが有名ですが、音の作りが好みではないので今はSONYのWI-1000Xを使っています。東京から西海岸へ行くのならギリギリバッテリが持ちます。（東海岸やヨーロッパは無理）

イヤーピースのサイズが合わないという人もいるようなので、必要に応じて別途買うといいと思います。

合わせて機内では、AukeyのBTトランスミッターを使って映画を見ています。

ウェストポーチ

機内でパスポートやペン、小物を保持しておくのに、ウェストポーチがあると便利です。荷物検査の時にも出す必要がなければ財布やスマホ等を中に入れておいてそのまま流せるので便利です。ちょっとサイズは違いますがノースフェースのものが軽いので普段から愛用しています。

ネックピロー

空港で適当に買ったものを使っているのですが、なかなか便利です。リバーシブルになっていてクッションにもなるしネックピローにもなるものです。リンクは同じものがなかったので似たようなものです。

日本の人は空気で膨らませるものを使っていることが多いのですが、アメリカなどだとリュックにぶら下げている人しか見なかったのでこのタイプにしてみましたが、準備も楽だし普段もクッションとしてランバーサポートがわりに使えるので重宝しています。

スーツケース

国内メーカーのAceのブランドであるProtecaを使っています。友人のymotongpooの勧めで90L前後あるといいぞとのことだったので、360sにしました。

縦にもあけられるので、空港の最後に荷物調整するときのもサッと出し入れしやすいのが良いです。また、出張時だけではなく家族4人の2泊3日の国内旅行でも大活躍しています。

ストレッチ系

肩の凝りが首に来てパフォーマンスが落ちる状態になってしまったので、フォームローラーは欠かせません。必要に応じて、ストレッチポールのハーフサイズも持って行っていますが、おもに活躍しているのはこちらの方です。

PC関連

首やら肩やらにダメージを負った関係で、キーボード諸々の作業環境は結構気にしてます。以前はThinkpadのトラベルキーボードを持って行っていたのですが、前回の出張からオウルテックのコンパクトな分離型のBTキーボードに切り替えましたが、なかなか良い感じです。

以下はマウンテンんビューオフィスへ出張した時の写真ですが、このうち、モニター以外は日本から持って行ったもものです。

キーボードはこちらのオウルテックのものです。打ち心地は軽いですが、分割なので肩が疲れにくくなかなか良いです。

PCスタンド

PCスタンドはだいぶ前から使っているこれです。macだとヒンジが開角度に制限があるので高さが稼ぎづらいですが、それでもあると首が負担少なくなりかなり楽です。

マウス

家ではLogicoolのBTトラックボールを使っているのですが、持ち運びも考えて出張時はLogicoolのMX Anywhere 2Sを使っています。買ったときは気づいていなかったのですが、エルゴノミクス的なつくりになっているので、負担感は少なめです。

USB-C PD充電器

軽さこそ正義！ということで、backspace.fmのdrikinさんおすすめのRavpowerから出ているUSB-C PD充電45Wが可能なものを使っています。GaN（窒化ガリウム）のおかげで82gと軽量でiPhone 7sより一回り小さい大きさです。カバンにとりあえず突っ込んでおけば、飛行機の中でも空港やラウンジでも活躍します。

ケーブルも、USB-C<-> LightningケーブルやUSB-C<->micro USBを用意しておけば、大抵これ一個でなんとかなってしまいます。

とはいえ、急速充電はいらないしモバイルバッテリーからはUSB-Aだし、みたいなケースもあると思いますが、そうしたときにはAnkerのこの便利な変換アダプタセットのケーブルを使っています。

実は変換プラグ単品を買ってどうにかしようとした時もあったのですが、どこかに行ってしまいそうだったのでこっちに切り替えました。GoPro Hero7で自転車動画を撮るのにもお世話になっています。

あなたの知らない煽りの世界

Sat, 15 Dec 2018 22:06:00 -0800

この記事はの17日目です。

世の中にはAIを使ったchat botのような、高度なやりとりをするコンピュータが増えつつあります。コンピュータとやり取りすると人間はencourageされるのか？という疑問をお持ちの方もいるかと思いますが、そんな疑問を持つあなたはこの記事を読むことで、いかにコンピュータが人間の感情に対して働きかけてくれるかを学ぶでしょう。

それでは、ある日のエンジニアたちのチャットでのやりとりをお楽しみください。

Rのtest frameworkのtestthatの煽り力が高い

Frustration is a natural part of programming :)

ちぇぞーさんまた煽られてるの

なにこの機能ｗｗｗｗ
Rすげぇな！
テスト結果で煽りメッセージでるフレームワーク初めてみたよ！

っつうかさ、テスト結果レポータに煽りメッセージ入れるって発想すごくない？

バリエーションあるw

"Keep trying!",
"Don't worry, you'll get it.",
"No one is perfect!",
"No one gets it right on their first try",
"Frustration is a natural part of programming :)",
"I believe in you!"

特に励ましているように見えねぇのは俺の問題？

オレにもそう見える

上っ面っぽさがあるよな

No one is perfect!
特にお前

adjectiveになにはいるんだろ

praise <- function() {
 x <- c(
 “You rock!”,
 “You are a coding rockstar!”,
 “Keep up the good work.”,
 “:)”,
 “Woot!”,
 “Way to go!”,
 “Nice code.”,
 praise::praise(“Your tests are ${adjective}!”),
 praise::praise(“${EXCLAMATION} — ${adjective} code.”)

praiseってモジュールがあるｗ

なんだよこのPRは

いいじゃんこのモジュール
bot性が高すぎる

辞書作ってマジで作りこんでんじゃねぇかｗｗｗｗ

メッセージ豪華にするために依存追加してるからな

アホでしょｗ

このコミット、R界の神と呼ばれるHadleyがコミットしてんじゃんかよwww (編注：このcommitを入れたのは日本では「Rの神」とも呼ばれるです。彼のサイトに行くと熱い視線に「こっちみんなwww」と草が生える事うけあいです。)

OpenBSDのsshかなんかも、パスワード間違うと煽ってこなかったっけ

sudoか

それ OpenBSD というより、sudo の機能だったな

AC\_ARG\_WITH(pc-insults, \[AS\_HELP\_STRING(\[ — with-pc-insults\], \[deprecated\])\],
\[case $with\_pc\_insults in
 yes) enable\_offensive\_insults=no
 AC\_MSG\_NOTICE(\[ — with-pc-insults option deprecated, it is now the default\])
 ;;
 no) enable\_offensive\_insults=yes
 AC\_MSG\_NOTICE(\[ — without-pc-insults option deprecated, use — enable-offensive-insults\])
 ;;
esac\])

— with-insults オプションを付けてビルドすると、出るようになるらしい。

Speak English you fool つよい

\[xxxxx@yyyyy ~\]$ sudo ls
\[sudo\] xxxxx のパスワード:
The more you drive — the dumber you get.

できたｗ

まだあるな

AC\_ARG\_WITH(all-insults, \[AS\_HELP\_STRING(\[ — with-all-insults\], \[include all the sudo insult sets\])\],
AC\_ARG\_WITH(classic-insults, \[AS\_HELP\_STRING(\[ — with-classic-insults\], \[include the insults from the “classic” sudo\])\],
AC\_ARG\_WITH(csops-insults, \[AS\_HELP\_STRING(\[ — with-csops-insults\], \[include CSOps insults\])\],
AC\_ARG\_WITH(hal-insults, \[AS\_HELP\_STRING(\[ — with-hal-insults\], \[include 2001-like insults\])\],
AC\_ARG\_WITH(goons-insults, \[AS\_HELP\_STRING(\[ — with-goons-insults\], \[include the insults from the “Goon Show”\])\],
AC\_ARG\_WITH(python-insults, \[AS\_HELP\_STRING(\[ — with-python-insults\], \[include the insults from “Monty Python’s Flying Circus”\])\],

頑張りすぎだろw

classic-insults

ほう
これはたのしそうだ
無駄にくっそ作り込んであるな

煽っていこう
!煽り (編注: !からはじまるワードはbotコマンドで、ランダムでDBから何かが引かれる)

pyspa-bot
出力に慎みなきこと。

なにげにこのbotのチョイス神がかってた

#ifndef OFFENSIVE\_INSULTS

今まで見た中で一番圧強いdefine

#ifdef PC\_INSULTS
 “Listen, broccoli brains, I don’t have time to listen to this trash.”,
#else
 “Listen, burrito brains, I don’t have time to listen to this trash.”,
#endif

何が違うのかわからん

ブリトー → メキシコ料理、文化的背景を連想させる
ブロッコリー → PCに配慮

ポリコレか

その分岐作る方がPCに問題ありそうｗ

いかがでしたか。人はこのようにしてコンピュータからエネルギーを貰っているし、それを支えるソフトウェアエンジニアの力が感じられたでしょうか？

明日は、みんなだいすきwozozoです。

Windows 64bitでMeCab(とKyTea)を使う方法 2018

Fri, 30 Nov 2018 20:05:57 -0800

こんにちは、日本語のテキスト処理してますか。

最近はBERTやらTFhubで使えるのEmbeddingのモデルが一段と増えてきて、楽しいですね。BERTで用いられるWordPieceや、MeCabの作者としても有名な工藤さんの新作、といった新しいTokenizerが出てくる一方で、TFhubで用意されているNNLMのtokenizerは公開されていないので結局MeCabで頑張らないといけない(少なくとも当初 )など、2018年の今でもMeCabの重要性は変わらず続いています。

そこで、今回はWindowsでも形態素解析をしたいという人にどうしたらいいんだっけという話の2018年12月版をしたいと思います。

tl;dr

64bit版のMeCabインストーラーが欲しい場合はikegami-yukinoさんのが便利でしょう。PythonはもPypiに用意していただいています
最新のWindows用のMeCabのexeとdll、ipadicがzipでほしいという人は、私がを使ってください。Python用wheelもありますし、Rubyの人にもです
KyTeaも合わせてとを用意しました

なぜこの記事を書くに至ったか

今年に入って、MeCab/SentencePieceの作者の工藤さんによる形態素解析本も出てきて、ますます皆さんの日本語処理熱は高まっているかと思います。

PythonでのモダンなNLPの処理向けのライブラリspaCyでは、他の言語との兼ね合いでPure Python実装のJanomeからUnidicベースのMeCabに。需要は高まっています。

[https://spacy.io/usage/models](https://spacy.io/usage/models) Spacy depends on MeCab (mecab-python3)

また、日本語の機械学習の本が新たに出ていますが、大抵の場合Pythonでmecab-python3を使いましょうとありますが、ためSWIGも用意しsourceからのビルドが前提です。Windowsの人にそれを要求するのはハードルが高いです。

64bit WindowsでMeCabを使うには

メモリ16GBは人権という言葉もありますが、この前提には4GB以上のマシンでは64bit OSを使っているということが前提だと思います。とはいえ、MeCabのには32bit版のバイナリしか存在しておらず、自前のビルド環境を用意していないことが多いWindowsの皆様におかれましては面倒くさい状況になっていると言えます。まさか、が役に立つときが来るとは…。

しかし、３年前のMinGW用の修正が今年になってマージされたときにMSVCでのビルドが壊れてしまいました。一応PRを投げましたが、いつマージされるかはわからない状況です。

また、ikegami-yukinoさんという方が64bit版exeを配布されていますが（windows用wheelも）、CIでexe実行してインストーラ回すのどうすればいいんだっけということで、zipで固められたものがほしいなぁと思いました。

韓国の先立ちはCIでWindows向け、辞書（ipadic）、 Python用のwheelをbuildしているのを見つけました。

これはいい。ということで、車輪の再発明をしました。

Yet another MeCab binaries for Windows x64 & x32

GitHubのreleaseにて最新のMeCabをベースにしたしています。

やったことは、とにだいたい詰まっていますが、先程送ったPRをベースにMSVC用のMakefileを改めて作り、それらをCIでビルドしています。また、各Pythonバージョンごとのwheelも作っています。

libmecab.dllを使えばRubyなど別の言語のMeCabバインディングからも利用することができます。というのを手元で確認しています。

なお、Unidicは同梱しようと思えばできると思うのですが、皆大好きnelodogdはshell scriptやawk、perlの塊でビルドする必要があり、WSL使ってUbuntu用意するのが最短のようです（敗北感しかない）。

Python拡張モジュールのbuildの話

そもそも、Pythonのパッケージでは予めビルドされたwheelという仕組みがあります。これのおかげで、ユーザは自分の環境でビルドすることなくさくっと pip install awesome-package するだけでC拡張があるパッケージが入れられるわけです。Rubyでいうところの gem install nokogiri で苦しまなくても良いような仕組みがあるということです。

WindowsのPython拡張周りの辛さ

Windows用のPython拡張モジュールを用意するためには、PythonのバージョンにマッチしたVisual Studioのバージョン（あるいはビルドツール）を用意しないといけません。詳しくはPythonコミッター稲田さんの以下の記事をご参照ください。

考えようによっては、MSVCの環境を用意すればWindowsのバージョンに依存しないバイナリパッケージが用意できるので、非常に楽です。少なくともmacOSはもっと楽なのですが、なぜ楽と言えるのかについてもお話しようと思います。

余談: Linux用wheelを用意する

Linuxにおいては、様々なディストリビューションの違いがある中で、各種環境で共通のwheelを用意するのは難しい問題でした。しかし、Windows/macOSでwheelが使われるようになり、その恩恵をLinuxでもあずかれるようにということでmanylinuxという枠組みができました。最初にできたのはmanylinux1というもので、互換性を考慮してCentOS 5のDocker imageをベースとしてwheelをビルドします。に詳細は記述されています。

作り方等々は稲田さんの記事と、PyPAのリポジトリが参考になるでしょう。

お気づきの方もいらっしゃるかもしれませんが、CentOS 5ベースのgccで新しいプロダクトのbindingを用意するのは地獄です。現に（非常に議論が沸き起こっているところですが）TensorFlowはmanylinux1というタグを使っているにもかかわらずもっと新しい環境で用意したwheelを用意しています。

これに対してCent OS 5もEOLになることなどを踏まえて、manylinux 2010が準備されています。以下のissueを見る限りでは、次のpipからmanylinux2010を扱えるようになり、そろそろ準備が整ってきているようです。

KyTeaのWindowsバイナリとPythonバインディング

MeCabで得た知見を生かして、ついでにKyTeaもWindows用バイナリとPythonバインディングをpip installできるようにしました。本家にもPRを送ったんですが、appveyorの設定がまだされていないので、fork版をお使いください。

なお、 pip install kytea でようになっています。（WindowsのPython 2.7は除く）issueがあればこちらにどうぞ。

加入しているサブスクリプションサービス 2018

Tue, 13 Nov 2018 20:11:53 -0800

以前、の人が書いていた気がするのだけど、 wozozoに聞かれたのでメモがてら書いていく。

契約中のサービス

JetBrains All products pack – IntelliJとPyCharmのために買った。良い
Netflix – 最近は見るものが減ってきたけど今季は転スラがあるので良い。子供には必須
Amazon Prime – デリプロの中でも最強のADPとの戦いが増えて、どうするか悩み中
YouTube Premium – 子供に英語の動画をChromeCast Ultraでガンガン見せているようなので、広告スキップが必須。
freee – 確定申告用
1Password.com – 買い切り版持ってたらMacユーザ限定半年無料キャンペーンがあったので移行した。Linuxでも使えるのが良い
Notion.so – リッチなメモ用のアプリ。プラットフォーム選ばず使えるのがとてもよい。書きごごちも気に入っている
DMM英会話 – 英会話のメンテナンスに。最近は会社でvipabcのトライアルがあるのでそっちがメインに
IDCFクラウド – サブスクリプションではないが、Podcast用のサーバを置いてる。けど更新もできてないしそろそろGitHubに引き上げようかな…

契約をやめたサービス

Google Play Music – YouTube Premiumに移行したため解約。Play Music自体は自分の音源をあげられるので、マイナーなゲーム音楽やアイリッシュバンドの曲を聴くのに必須
Audible – 「盾の勇者の成り上がり」を最新刊まで聞いたらコイン制に移行したのでやめた。声優が読み上げるラノベはとても良いです。首を痛めてた時にはお世話になった。今ならをしてるらしい。
Bookscan – プレミアムライト会員を必要な時に適宜入ったり解約したりしている。いつになったら、統計や機械学習の教科書が電子で買えるようになるんだ…

契約を検討しているサービス

Adobe Creative Cloud – backspace.fmを聞いてるとAuditionを手に入れるためにちょっと欲しくなっている。らしい。
Office 365 – 買い切り版のライセンスも古いので切り替えようか検討中

Thinkpad X1 CarbonとMacBook Proとで使える充電可能なUSB Type-Cのハブを選ぶ

Sat, 27 Oct 2018 21:11:26 -0700

“two phones on white table” by on

転職をして、業務で使うマシンがMacBook Proになったので、自宅用のThinkpad X1 Carbon (5th Gen, 2017モデル)と共通して使える充電とUSB-Aがはやせるハブ(とかマルチポートアダプタとか色々言われているもの)を探しました。

最終的に選んだもの

以下の2つを買いましたが、買ってから2ヶ月弱安定して動作しています。

ここに至るまでにいくつかの充電器やハブを買っては返品を繰り返していたので、備忘録として書きたいと思います。

要件

USB Type-C Power Delivery(PD)で充電できる
USB-Aのポートがある
HDMI 4kは60Hzでないので気にしない

X1 Carbon 5th GenはUSB Type-Cで充電をするのですが、W数が45Wより少ないと充電できないように本体側でコントロールをしているという罠があります。それをいかに乗り越えるかが今回の課題でした。あと、Amazonのレビューを調べると「X1Carbonでは使えません」というコメントが散見されます。なので、利用可能という実績があるものを探さないといけないです。MacBook ProはNintendo Switchの充電器でも充電できるくらい、結構ゆるゆるです。

HDMI 4k 60HzはThunderbolt 3ポート一個では帯域が足りないため、複数の機能をもたせたハブでは実現不可能なので諦めました。Thunderbolt 3-Display Portケーブルを別途使っています。

ハブを経由するとW数が下がる

X1 Carbon付属の充電器が45Wで、直接刺すと充電できるのにハブを経由すると充電ができなくなる、という現象が根本的な原因でした。厳密に言うとスリープ状態では充電できるけど、稼働時には充電されないのです。これに気づいたのは、Lenovoの純正のハブでも経由すると充電できないという記述がなされていたためです。

実際に検証しようとしたときに、45Wクラスの充電器は安価に手に入るのですが、60Wクラスの充電器でそれなりに安価で比較的安心して使えそうなものが見当たらず検証するのに苦労しました。ここに至るまでには、使い始めて1週間で熱暴走して死んでしまったハブもあり、USB PDがあるときちんと熱管理をできているようなものを探さないといけないというのもポイントでした。中には「高温になりますが大丈夫です」などと商品説明で開き直っているものもあり、注意が必要です。

たまたまEngadgetでPSEマークがついているというレビューをみたを見つけ買うことにしました。更には、1週間で壊れたハブを経験したので、ある程度信頼できそうなブランドでかついざとなれば返品・交換が容易にできそうなものということで、を購入しました。

この苦労、おそらく2018年モデルだとしなくて良いみたいですが、参考になれば。

RISECampに参加した

Wed, 24 Oct 2018 16:01:02 -0700

10/11–12にUC Berkeleyのが主催していたbootcampに参加しました。kawasaki.rbでも少し話しましたが、参加報告です。雰囲気はがわかりやすいです。

\[2018/11/29追記\]

動画とTutorial用のバイナリが公開されました

\[/追記終わり\]

RISELabはSparkで有名なAMPLabの後継となる研究室で、彼らが作るML関連のライブラリ・フレームワークのハンズオンをするというのが会の趣旨です。

RISELabのStack

上の図のオレンジと緑の部分が彼らが作っているフレームワークになるのですが、その中でも以下のものについての紹介がありました。

RAY, RLlib, Tune: Pythonの分散処理フレームワークRAYと、それを使った強化学習ライブラリRLlib、パラメータチューニング用のライブラリTune
Flor: MLのモデル作成のための実験をtrackingするためのライブラリ
Clipper: MLモデルのServing用のAPIサーバを立てたり管理するためのライブラリ
PyWren: AWS Lambdaを使った並列処理のためのライブラリ
Opaque: Apache Sparkを使った暗号化したDataFrameを処理するライブラリ
WAVE: Decentralised authorization for IoT

tl;drという名の感想

機械学習エンジニアリングは複雑で、モデルのデプロイ・サービング、実験の再現性やトレーサビリティはプロダクションへの重要なパートになる気がする。やもそういったMLOpsの部分を狙っている
機械学習のワークロードはすべてPythonでやるぞという意気込みを強く感じた。会場からはSparkとどう連携するの？みたいな話もよく出たが、PySparkで一応…みたいな答えが多かった。特にを使ってオブジェクトばらまいて並列分散処理をすればいいじゃんという発想は単純ながら力強い。そして、Apache Arrowでノードのworker間のshared memory作るというのは今どきだなと。PythonはDSLとして便利なポジションになってるのかなぁ

たまたま、帰りの飛行機で聞いたTWML AI podcastでもこんな話が出ていました。

以下、ざっとハンズオンを行った順に紹介をしていきます。

RAY, RLlib, Tune

RAYはこのRISELabのセットの中での基礎となるフレームワークです。READMEにもある通り、以下のようなdecoratorを書くだけでPythonの処理を並列・分散処理できるというコンセプトのものになります。

MLの処理をDSLとして抽象化します。特徴としては、

FunctionをTasksとして
ClassをActorsとして

として、Actorモデルを使って並列処理を行います。 @ray.remote というデコレータを書くと、その関数はRAYのWorkerで実行されるという仕組みです。

ポイントとしては、Pythonのobjectをcloudpickleというpackageを使ってserializeしてWorkerに投げてしまうということです。裏側にはノードごとのshared memoryとしてApache Arrowもいるため、Workerの共用メモリとしてオブジェクトを格納します。データの並列化どうするんだろうなと思ったら、ModinというPandas on Rayというライブラリも開発しているようです。”Modin is a DataFrame for datasets from 1KB to 1TB+”と言っているので、皆が困っているサイズ感のDataFrameを扱えるようになるかもしれません。

チュートリアルは、こちらのrepoと同じものを実際にJupyterLabでハンズ・オンしました。

RAY自体はなるほど、と思って生々しいコードを書いていたのですが、それをベースにしたという強化学習のライブラリとというパラメータチューニング用のライブラリを使ってみて、隠蔽されたアプリケーションとして使うとML用の並列処理を行うのには良いなと感じました。

なお、WorkerのPythonのdependencyはあらかじめ解決した上で走らせてねということなので、複数プロジェクト走らせたりするのにはまだまだ自前で頑張る部分がありそうです。

Clipper

Clipperは、MLの予測のためのAPIサーバを簡単にデプロイできるようにするためのライブラリです。

コンセプトとしてはData scientistにパフォーマンスが気になる本番のAPI部分のコードを書かせることなく、スケーラブルなAPIサーバをコンテナベースでデプロイできるようにするということです。基本的には対応しているPythonのMLライブラリであれば、Dockerfileも書かないで予測の処理のコードを書いて、それをPythonからデプロイするという流れになります。

また、内部ではPrometheusのコンテナも立ち上げて、特定のmetricsをトラッキングできるようになっています。

Flor

Florは機械学習の実験のトレーサビリティを上げ、再現性を高めるためのライブラリになります。

機械学習では、feature engineeringなどのデータの加工をしたり、パラメータの探索をしたりしながらパイプラインを作っていきます。そこで、よくあるのが過去のパイプラインを再現したいのに、既にobjectが上書きされていて戻せないといったことがあります。Florでは、それを再現可能にするために色々と補助をしてくれます。

少しFlor流の書き方をしないといけないのですが、それをすることで実験同士の処理のdiffを見たり、処理のパイプラインを可視化したり、他の人から引き継いだ実験の中間データを後から再度取得したりすることができます。

MLでは実験のreproducibilityをどう作るのかという話がよく話題にあがるため、その一つのアプローチとして良いのではないでしょうか。ただ、大きいデータになったときの中間データを効率的に保存できるかは少し気になりました。

PyWren

PyWrenは、AWS Lambdaのようなサーバレスアーキテクチャを使って並行処理を行うためのフレームワークです。（まだ、GCPやAzureでは動かないっぽい）

以下はパラメータチューニングのノートブックですが、mapとfilterで処理を並列にばらまくことで分割しています。

また、これだけではなくNumPyWrenというNumpyの処理を同様に並列化するというプロジェクトも進んでいるようです。

PyWrenに関してはLambdaのアップロードできるイメージ？のサイズの制限があるため、shared objectを外部サーバに出したりと充実したPython Package周りを入れるために工夫をしているようです。

Opaque

OpaqueはSparkSQLをHardware Enclaves (Intel SGX, AMD SEV etc)の上で走らせて、セキュアな分析を可能にするものとのことです。チュートリアルでは、病気に関するデータセットを使ってSpark DataFrameを処理しましたが、まだScalaでしか動かないようです。

WAVE

IoTのための中央集権型ではない認可のための仕組みです。

RISECamp 2017の動画

チュートリアルでは、二人の人がペアになって、それぞれのスマートホームを模したライトや温度センサーに対して変更や読み取りの権限を与えて操作をするということを行いました。

これだけだと、なんでこの流れでこれが紹介されるの？と思いましたが、最後に行ったRay, Clipper, Flor, WAVEの統合ハンズオンでは、RayとRLlibでpongの強化学習を行うための予測モデルを作り、Clipperでモデルをデプロイし、更にそのモデルの予測のための権限をWAVEで管理するという形でした。予測モデルの権限管理をするという発想があまりなかったので興味深かったです。

スライドやVideoはまだ出ていませんが、当日YouTube Liveでも中継していたので、そのうちに上がると思います。

あと、JupyterLab/Jupyter Notebookでのハンズオンを二日間フルでやりましたが、FIXMEを残しておいて修正したらassertでうまくいったかチェックをするというスタイルは、自分でも進捗を確認しやすいので良かったなと思います。

Treasure Dataに入りました&Plazma tech talkで話しました

Thu, 18 Oct 2018 09:12:26 -0700

気づけば入社して2ヶ月ほど経ってしまいましたが、Treasure Dataに入ったと思ったらArmに入社していました。

Machine Learning teamの3人目のエンジニアとして、HivemallやTD上での機械学習周りの開発と、お客様へのコンサルティング等々をやっていきます。振り返ってみるとML的に強い人と同じチームで仕事するのは初めてな気もするので、楽しいです。

入社2日目には話すことが決まっていたPlazma tech talkのスライドはこちらです。TD上でのML何ができるんだっけという話の整理と、今開発中のpy> operator on TDを使うと何がML的に嬉しいんだっけという話を書いています。個人的にはIoTを考えた時のエッジでの予測みたいな話も見据えたcapabilityの広がりが大きいところかなと思っています。

親も読みたい子供とネットの向き合い方を考える二冊

Tue, 26 Jun 2018 13:55:48 -0700

“Two young girls stand reading from a book outdoors in the sun” by on

伊藤淳一さんの以下の記事を読んで、子供にネットの話をどう教えるのがいいのかなぁと悩んでいたので、件の記事で紹介されていた本と、そこから派生して仲間内で紹介してもらった本を読んだので紹介したいと思います。

伊藤さんの記事も長いですが、ソフトウェアに携わるエンジニアでかつ子を持つ親として考えさせられる内容でしたので、時間があれば読んでみると良いと思います。

11歳からの正しく怖がるインターネット: 大人もネットで失敗しなくなる本

こちらは、伊藤さんの記事でも紹介されていたGREEの小木曽さんの本です。恐らく、「渋谷の交差点の真ん中で高校生がプラカードを掲げた写真」の話をしてる人というとピンと来る方も多いかと思います。SNSに投稿する事は、渋谷の交差点でその投稿を掲げることと同じ事だよ、という話や魚拓やスクショなどの話と共に、ウェブに上がった情報は消せないし残り続けるよ、という話を分かりやすく説明しています。

この本の特筆すべきところは、アイスクリームの冷凍庫に入った写真をあげてしまう事件など、いわゆる炎上した事件を各種紹介してくれているところが非常に良いところです。ある事例では、炎上した学生がその後就活でも結婚でも「炎上させた人」として拒否され続けているという、重荷を背負って生きている話も挙げられていました。

また、炎上したら言い訳をせず、まずきちんと謝罪をしましょうのようにどのように振舞うべきかという話や、子供の間でのSNSの特徴的な使い方やトラブルなど、多くの人と話しており経験も豊富な著者だからこその話が多く、ソフトウェアエンジニアの目線からも正しい情報が提供されていて安心感を感じました。ネットと向き合うためにはリスクとベネフィットとのトレードオフであるという事を何度も書かれていて非常に好感が持てます。

一方でいくつか気になる点もありました。本書の位置付けからはある意味仕方のない話ですが、全編を通してマイクロソフトのエヴァンジェリストの西脇さんがいうところの「」で終始しているように見受けられるところです。これは、想定読者が小学校高学年・中高生もターゲットにしているためだと思うのですが、どうすれば（意識の高い人ではない）普通の人の興味をひき続けられるのかという点を意識して、ユーモアに混じった円やかな口調ではありますがホラーストーリーを積み重ねています。仕方のないこととはいえ、救いがない話も多く少し胸焼けしてしまうかもしれません。

もう一つの問題は、子供の興味を引こうとするあまり、「変態」という語を乱用しているように見受けられることです。特に、肖像権の説明の際に「私が女子高生の格好をしていて街中を歩いていたら、変態ですよね（だから、不利益が生じうる写真や動画のアップロードはリスクがありますよ）」というような表現があり、妻とも「（2016年出版だけど）この表現は2018年には厳しいかもね。女装がしたいけど悩んでる高校生には辛い」という話をしていました。

この辺りの話は、自分も西脇さんのセミナーに参加したり本を読んだりして、どのように人に受け入れやすいプレゼンをするかという事を常々考えていたので、ともすると集中力や興味に欠ける子供を対象にどうしたら聞いてもらえるか、頭に残るかという事を考えた上での「北風と太陽」の選び方なんだとは思います。西脇さんも言っていましたが、北風を使うときは不必要に傷つける人を作らないようにしないとなと再確認しました。

細かいことを書きましたが、親がこの本を読んで知識を得る分には得られるものも大きいですし、後述する「ネットのルール」と合わせてぜひ一度読むのをおすすめします。

学校では教えてくれない大切なこと 12 ネットのルール

この本は、小学校低学年からでも読める漫画を中心としたネットとの向き合い方になります。全般的にギャグ漫画のノリで、主人公の少年とその父親（たまに母親）が失敗していくのをネットに詳しい祖父がガイドしていくという流れです。IDパスワードの命名や管理やアイドルからのメール詐欺に引っかからないなど、小木曽さんの本よりは幅広いテーマについて扱われています。

この本の良いところは、シリーズ通して比較的低年齢の子供でも自分で読んで理解できるところにあります。さすが漫画。無料とうたうアプリをダウンロードする時は正規ストアか気をつけてねとか、著作権の話と違法ダウンロードの話も含まれており、書いてある内容も、やや安全側に倒しているきらいはありますが、ソフトウェア関係の人間としてみても間違っていないと思います。

ただ、炎上したときは何も返信等しないでおきましょうというような小木曽さんの本との対応ポリシーの違いや、困ったら親に相談しようという、子供向けの本としては正しいが親としてどうするかを判断する必要があるので、小木曽さんの本と合わせて読む事で、家族で考えておくのが良いでしょう。

ここからは蛇足ですが、冒頭の伊藤さんの問題提起の話を読んで感じたのは、小学校の招聘する講演は、先生が判断できる材料がなかったり、対象となるものに対する知識が足りなかったりするなどで、問題のある講演者を呼ぶリスクは潜んでいます。自分の子供も、犬や猫の殺処分の場所や方法を明示する動物愛護団体の講演を保護者参観の日に見せられて頭を抱えた覚えがあります。結局、これは構造上避けられないものである事を認識した上で、各家庭で正しい知識を教え自衛するしかないのかなと思います。

ご家庭での子どもとネットに対する考える良い材料になれば。

退職します

Mon, 18 Jun 2018 17:06:01 -0700

この記事は、最近流行りので有名なからお送りしています。

一部の方にはお伝えしましたが、先週がClouderaでの最終出社でした。2年3ヶ月はあっという間に過ぎて行きました。同僚のとに退職ブログ書いてくださいよと言われたので、初めて書いてみます。

はじめての外資で働くということ

研究職からWeb系でのソフトウェアエンジニアを経て、いわゆる外資ベンダーでのプリセールスのセールスエンジニアとして今回0からの弱くてニューゲームをさせてもらいました。セールスエンジニアのお仕事は、同僚ののこの記事がわかりやすいかと思います。

ただ、Clouderaのセールスエンジニアのロールは継続的に使っていただくために割となんでもするという感じで裁量も大きく、Field Data Scientistという風に名乗らせていただいて、Spark周りのBig Dataの話とデータ活用の話、それから機械学習の話を幅広くさせていただきました。

おかげさまで、国内外での発表も色々とさせていただきましたが、USのエンジニアブログにも5本ほど執筆させてもらい、での発表や、自社の全エンジニアが集まる社内テックサミットでの発表などかなり自由気ままに活動させていただきました。これも日本の同僚や過去一番働きやすい上司たちのおかげです。

また、や、なんかもワークアラウンドを見つけたりPR投げたりするという形で業務に関連のあるOSS活動もできたのは良かったです。なので、気づけば社内でも有数のconda職人になっていたかと思います。

もちろん、普通のセールスエンジニアとしての活動もしてました。国内最大級のノード数を持つお客様の、クラスタマイグレーションの支援をしたりもさせていただきました。出来るだけお客様の望む物を噛み砕いてサポートするというように心がけて、多岐にわたって支援させていただくよう努めました。

外資というかアメリカ資本の会社に入ってわかったのは、顔を合わせて一緒に飲んで名前を覚えてもらうことの重要性（Gmailのアイコンで顔を見かけると、MLとかでも助けたくなる）と、その時に興味を持ってもらえるようなコントリビュートを事前に社内で行なっておくことでした。APAC最古参社員のshiumachiや、テックサミットでいつも「お前日本人か、diceはどこにいる？」と聞かれる世界のdiceと共に仕事をしていたときに、自分も会社の中で認知してもらいどんどんコントリビュートしたいと思っていたのですが、それは達成できたと思います。最後の年にはプロダクトのロードマップを議論するProduct road map sessionに、ML系のField代表の一人として議論できたのは貴重な経験をさせてもらったと思っています。

US企業と日本の企業との違う点・同じ点

US企業との日本の企業との違うところはいろいろ感じましたが、特に以下の3つがありました。

英語ができないと死ぬ。が、入社時はしょぼくてもなんとかなる
文化の違いから、本物のマイノリティであることを痛感する
タイムゾーンの違いが辛い
空気読んでくれる人はほぼいないので、成果をとにかく主張する

英語は身内の外資系エンジニアの間で話をしていたのが、とりあえず英検二級くらい入社時にできればなんとかなるのではという話をしていました。英語がある程度できれば、酒を飲んで楽しくテックな話で盛り上がって仲間になれますし、お互いのリージョンでのあるある話でも盛り上がれます。

文化の違いは、以下の過去の記事を読んでもらえばいいと思いますが、とにかく、diversity & inclusion に積極的に取り組んでいても、アメリカ人とその他という当たり前な構図に気づかされることが多かったように思います。日本にいると、日本生まれの日本語話者の男性は当たり前だけどマジョリティで、そういう意味で自分がマイノリティになることはなんだかんだでなかったんだなとハッとしました。

タイムゾーンの違いは、途中から仕事で関わる人にNYCベースの人が増えてからが大変でした。時差13時間はどう頑張ってもお互いがちょっとずつ我慢するしかないので、（自分にとっては）日程調整にも気を使うし面倒だなぁという気持ちでした。とはいえ、結構カジュアルにchatしようぜと言われてHangoutしたりしていたので、JST 21 pmから会議開始とかができればまだ早い方で御の字だなぁと思いながら会話していました。

日本の会社と変わらぬ点としては、以下のようなものがありました。

強い人と一緒に働くのは楽しい
上司に恵まれると仕事しやすい
生存戦略の建て方

自分にとっての生存戦略は今までと変わらず、（その組織の中で）自分が強いところはどこかというのを見つけてコントリビュートすることでした。社内には、HadoopやSpark、Java/Scalaに関しては詳しい人が山のようにいるので、そちらの方面は詳しい人を頼りつつ、PythonとML系の話を掛け算で攻めていくようにしていました。例えば、自分のにさんの知見を英訳して展開しては社内に共有したのもその一環です。

Photo by [Andhika Soreng](https://unsplash.com/@dhika88?utm_source=medium&utm_medium=referral) on [Unsplash](https://unsplash.com?utm_source=medium&utm_medium=referral)

次は、MLOps系の話に自分で取り組んだり、実際に自分でdeveloperとして手を動かしてプロダクトに貢献したいという思いもあり、セールス寄りの世界から少し離れようと思います。かなりキャッチアップしないと…。とはいえ、頸椎を痛めたこともあり、PCもタブレットもスマホも使うと痛みが走るし、薬のためにアルコールも飲めないので、まずは少し静養しようと思います。

必要な人向けのWish listです。お使いください。

機械学習工学研究会キックオフシンポジウムに登壇しました

Wed, 16 May 2018 22:03:57 -0700

タイトル通り日本ソフトウェア科学会の研究会、に登壇しました。さんから声をかけられた時はカジュアルに受けたのですが、蓋を開けてみれば大御所の方々ばかりで恐縮しながらの発表でした。

僕の発表内容としては、書籍「仕事ではじめる機械学習」の話からデプロイパターンの話と、機械学習特有の難しさはどこから来るのかという話をしました。

時間が20分だというのに資料を一通り作った後に気づいて、かなり表層的にさらっとしか話をしませんでしたが、詳しい方からすると当たり前の話しかできませんでした。

話しきれなかったこと

お気づきの方は、参考文献等を見てわかるかと思いますが、機械学習特有の難しさという話は、主に以下の3つからピックアップしてきた話になります。

個人的には、どれも語り尽くされた感があるところはあったのですが、特にTFXの論文がプラットフォームの話だけではなく、典型的な機械学習の問題をどのようにシステムとして回避しているかという話が詰まっていて良かったので改めて補足したいと思います。。

例えば、「入力データのスキーマを作ってチェックする」という話が書いてあるのですが、ここでいうスキーマとは、カテゴリ値の種類を列挙したり、期待される統計値の幅を予め記述しておくというJSONSchema的なspecに近いものです。特に学習時のデータの分布と予測時の分布が極端に異なるということは往々にしてあるのですが、それをデータのスキーマでvalidationすることでアラートを上げてコントロールするというのは目からうろこでした。

また、予測結果を他部門の人が使うエピソードがあるのですが、その中で「締切に追われるエンジニアは、サクッと使えるものは使ってしまうものである」みたいなことが書いてあって、ですよねーと一人頷いていました。

3つ目のLucy Parkさんの発表資料は、Joel test for better Machine learning systemsというサブタイトルの通り、何をクリアすればいいかできていないとまずいかという11の質問項目を提案しています。

Do you keep your data versioned as well as your code?

Do you have an experiment database?

Do you have specified evaluation metrics?

Do the evaluation datasets match the needs of your users?

Can you reproduce your experiments in one step?

Do you have up-to-date documents?

Do you have the best computational resources money can buy?

Do you have tools to test model training?

Do you have tools to interpret your models?

Can you easily replace a component of your algorithm?

Does your team have a clear vision?

詳細はスライドを見ていただければと思うが、この中でデータのバージョン管理をしてる？という話が出ていたが、これはまだベストプラクティスがないよねという話がスライドでもされています。

少量データであれば、なんとでもなるのだが規模が大きくなってきて、かつ変更が入るようなデータをどう保持するのかというのは、自分でも気になって社内で議論したことがあるのですが、いわゆるDWHに入っているようなデータは、 (日本語だとがわかりやすい)という方法を使えば逐一スナップショットをとるのではなく、変更を管理できるという方法を教えてもらいました。

一方で、のようにgit likeにデータのバージョンを管理する方法というのも提案されていて、バイナリのデータはこちらのほうが良さそうだと思っています。

機械学習の予測では、一度異常が起きた時の原因究明が難しく、問題の切り分けのためにソースコードを遡るだけでなく、学習データ自身やモデル自身を遡る必要があるためここの話は非常に実用上重要になってくると思います。

あとは、バージョン管理をするのと同時に、依存関係を記述するモデルのリネージが重要になってくるだろう話もしました。モデルのリネージの話はまだこれといったツールがあるわけではないのですが、予測結果を利用してさらに別のプロダクトを作るというケースがあるように、何がどの結果をつかっているのかというのを可視化できるツールというのが、今後機械学習に依存したプロダクトが増えるに連れて重要度を増すでしょう。

機械学習システムにどういう立場で関わるか？

パネルディスカッションなどを通じて感じていたのは、機械学習システムを作る人が誰でどう関わるのかというのが人によって大きく異なるというのを改めて感じました。

いわゆるコンサルやSIとして係る場合、発注者と受注者の関係が発生します。この場合、要件定義を先にして…のようにウォーターフォールで客が作りたがるという話が出ていましたし、ソフトウェア工学的にもそうした立場に立った意見が目立ったのかなと思います。

そこに関しては、発注者自身が受け入れ要件を理解して定義できないといけないよね、などという話も出ましたが、幸いにして日本語だと機械学習システムのプロジェクトの進め方関連の書籍が拙著以外にも出ているので、そういった立場の方々はぜひ一度読むとよいのではないでしょうか。

個人的には、データドリブンなプロダクトを作るという観点では、ドメイン知識を持っている人が一番強いと思っており、最初はがっつり機械学習のシステム構築を支援するけれど、段々と発注側の人を育てる方向にシフトをしていき、最終的には内製化できるのが理想的ではないかと考えています。

機械学習が詳しい人の強みとしては、「どういう問題の切り出し方をしたら、機械学習で解けるか」というところだと思っています。この問題定義は、なかなか場数を踏まないとできるようになるのは難しく、そこをお手伝いすることが僕自身も多いです。それ以外のどう手を動かすかといった知見を少しずつトランスファーしていくのが、継続的に改善を必要とする機械学習システムでは良い形なのではないかと思います。

思った以上にCI,CDの話が出てこなくて、「ん？」と思っていたのですが、改善をし続けるという話が自社内でやれるかどうかでスピード感も変わってくるのかなという観点を得ることができました。

最後になりますが、司会の丸山先生や登壇者の皆様、500人規模の大規模な運営をしていただいたスタッフの皆様ありがとうございます。交流会でも非常に濃密な議論が出来てとても楽しかったです。

新しいPyPIでMarkdownのドキュメントを使う

Mon, 16 Apr 2018 20:55:15 -0700

長い間、Pythonでパッケージを作った場合、構造化されたドキュメントを使う場合は、 (reST)でドキュメントを書く必要がありました。

ところが、に教えてもらったのですが2018年2月にアクセプトされたのおかげで、PyPIのドキュメントがtxtかreSTでなければいけないという制約が外れました。そこで、昨日新しくなったばかりのPyPIでMarkdownがレンダーできる方法を試してみました。

(必要に応じて)ライブラリをupgradeする

Markdownが扱えるようになったのは、からです。古いバージョンだとMarkdownがレンダーされないので、合わせてpipとwheelをupgradeしておきました。

$ python -m pip install --upgrade pip $ pip install –upgrade wheel
$ pip --version pip 10.0.0 from c:\\users\\chezo\\documents\\source\\tabula-py\\venv\\lib\\site-packages\\pip (python 3.6) $ pip list
Package Version Location
-—————- ———– ————————————–
(…snip…)
setuptools 38.1.0
(…snip…)
wheel 0.31.0

setup.pyを編集する

long_description_content_typeという項目をsetup.pyに追加することで、reST以外の形式を使えるようになります。Markdownであれば例えば以下のようになると思います。

long_description=open(‘README.md’).read(),
long_description_content_type=”text/markdown”,

元々README.mdを読むようにしていたので、今回は long_description_content_type の行を追加するだけで済みました。

実際のPRはこちらです。

wheelを作ってtwineでアップロードする

後はいつもどおりwheelを作ってtwineでPyPIにアップロードしました。なお、

$ python setup.py bdist\_wheel $ twine upload dist/*

test.pypi.orgのMarkdownのドキュメントの様子

今回はこれだけのためにpatch versionを上げるのもなぁということで、test.pypi.orgにあげています。

参考文献

の関連箇所

「初めての自動テスト」を読んだ

Tue, 16 Jan 2018 19:54:23 -0800

「初めての自動テスト」をご恵贈いただきました。発売してからだいぶ経ってしまいましたが、良い本だったので紹介したいと思います。

この本は、アジャイルサムライの著者でもあるJonathan Rasmussonが、過去の自身の経験やSpotifyでの経験を元にテストについてまとめた本になります。対象読者は、テストに詳しくない開発者、昔ながらのテスター、チームリーダーを想定しています。僕もこの本がクックパッドで働きはじめたときに読めていたらどんなに助かったかと思いながら読み進めていました。

UIテスト、統合テスト、ユニットテストのピラミッドを考え、ユニットテストを厚く、UIテストはほどほどにということが、RailsとJavascriptを用いたWebアプリケーションを題材に書かれています。Google Chromeのデベロッパーコンソールの使い方から説明してくれているように、コードを普段書いていない人でもとっかかりやすいように随所に配慮がされています。

その一方で、不安定なテストはどうあるべきか？という話や、モックはどうあるべきか？といった、実際にテストを書いていくと必ずぶつかる話が整理されていて、今実際にテストを仕事で書いているけど、どうするのがいいんだっけ、という話が盛り込まれています。結構この手の話は、極端な方に振りたがる場合もありますが、コンフリクトする二つのたちばがあったときに両方のメリットを比較し、バランスを取ることを促しているのが印象深かったです。

また、「実機に勝るテストはない」というコラムではSpotifyの車載機器連携でモックを多用しすぎて見逃したバグの話など、自動テストだけじゃなくてUIがあるものはやっぱりそうだよねーという前職の経験を思い出しながら読んでいました。

経験豊富なソフトウェアエンジニアの皆さんには少し物足りないかもしれませんが、日々悩みながらテストを書いている開発者や、コードはあまり得意ではないけどというQA担当者両方に良い書籍だと思います。

Google Homeはスマートプラグと「部屋」でグルーピングすると便利

Tue, 02 Jan 2018 17:40:14 -0800

Google Homeを発売日に買ってから色々と試行錯誤をして来ましたが、だいたい構成が固まって来たので書き残しておきます。

下の図が大まかな構成です。

図中のSPはスマートプラグの略です。

もともとは、フィリップスの4kモニターの前段にHDMIオーディオ分離器とHDMI切替器を使っていました。分離した音声は、光オーディオケーブルでHDMI端子のないアンプにつながっています。

HDMI切替機には、Chromecast UltraとAppleTV、PC、Nintendo Switchなどが付いています。これをNature Remoで切り替えます。この切替はIFTTTを使い、Google AssistantとNature Remoを使い連携をするというごく普通の構成で行なっています。

厄介なのがPhilipsのモニターです。このモニターはリモコンでは操作が出来ず、入力信号がオフになればスリープにはなりますが、電源は裏側のハードスイッチによるオンオフのため、切替器や音声分離器で電源を制御していました。ですが、4k60Hz対応（HDCP2.2も対応）のものに切り替えたタイミングでスリープが出来ないという状況になりました。切替器は以下のものを、分離器は別の似たような製品を使っています。

せっかくGoogle Homeもあることだし、できれば音声でモニターの電源をオンオフしたいと思い、スマートプラグを導入しました。

このスマートプラグを使うと、Smartlifeというアプリと連携をすることで、Google Homeからの操作ができるようになります。また、Google Assistantアプリの中でスマートホームの設定からデバイスを「部屋」に所属させることができます。もともとはこの部屋というのは、部屋の照明などを一発でつけたり消したりするものだとは思うのですが、これで「モニター」という部屋に4kモニターとアンプを所属させることで一斉にオンオフをしています。便利。

他にもスマートプラグの便利なところは、当たり前だけど電源のトグルができること（人類は状態を覚えたくない）と、Google Assistantで機器のエイリアスを設定できるため、日本語でも英語でも共通の設定で動くことです。Nature Remoで不便だなと思っていたところが解消されて非常に便利です。

皆さんも是非楽しいGoogle Homeライフをエンジョイしてください。

2017年を振り返って

Sat, 30 Dec 2017 18:27:50 -0800

2017年を振り返って

に引き続き、振り返っていきます。

2017年は仕事に家庭に激動の一年だった気がします。もはや、年初の方は覚えていない。。。

初めて薄い本を出したらオライリーから商業誌になった

4月の技術書典2でなぜか初めて同人誌を出すことになりました。そこからあれよあれよというママにトントン拍子でオライリーから続けて電子版で出版となり、気づけば紙の書籍も来年1月に出版されることになりました。

きっかけは、pyspaのチャットでお蔵入りした原稿を供養しようぜといってさんさん両氏と同人誌を書くことにしたのですが、日頃考えていること、話していることが皆様の手元に届けられてよかったです。特に、機械学習に関連する泥臭いエンジニアリングまわりのところは、最近でこそ話題になるようになりましたが、あまり論文にもならず論点にもならなかったのですが、これが一つの議論のたたき台として使えればなぁと思っています。

Strata Data Conference Singaporeで発表した

仕事ではじめる機械学習で整理した機械学習システムのアーキテクチャの話をしました。英語で40分のトークだったのですが、ちょっと時間配分をミスったり慣れないGoogle Slideでやったら時間カウントし忘れてたりバタバタしましたが、発表後に捕まえてもらって議論をさせていただき有益でした。

とはいえ、スクリプト用意して臨んだらフリースタイルで話せる感じにはならなかったので、今度は歩き回りながら話せるようにしたいです。

じつはStrata NYCも行ったのですが、こちらはオライリーが主催するAIカンファレンスが直前にあったためか、ML・DL系が少なかった印象にあります。なので、個人的にはSingaporeの方がML系の話、特にデプロイやプロダクション関係の話が多くて楽しかったです。

会社の英語ブログデビューをした

デビューしたと思ったら、年間4本と想像していた以上に書いていました。中にはRStudioのエンジニアにレビューしていただいたものもあり、色々レビューの大切さを感じています。会社の英語ブログを書くともれなくネイティブチェックを無料でしてもらえて非常に勉強になりました。

スターが100超えたOSSができた

PDF中のテーブルからPythonのDataFrameを抽出するがスター100を超えました。また、v1.0も出すことができて安定稼働したかなと思います。おかげさまで、英語や中国語での紹介記事も書いていただきありがたい限りです。

なお、継続のコツとしては、限られたリソースなので質問系はStackOverflowに流すようにイシューテンプレートを作ること、基礎的な質問はFAQに詰んでテンプレートに従わないイシューはガンガンクローズする運用にしました。

また、sparklyrにした小さいコントリビュートが含まれたものがリリースされたりと、当初思っていたよりはOSS活動できたかな、と思います。

家庭周りの話

相変わらず出張は多いので、妻の負荷をできる限り抑えるようにしたり気晴らしに出かけたりということを心がけてしました。家族旅行は地味に大事なんだなとおもいます。総じてある程度はできたけど、もうちょいやりようがあるのかなと思います。複数の家族が集まってワイワイやるのはとても楽なのでそういう手抜きの機会を増やしたいなぁ。

また、はじめてのワンオペ育児は自分にとってはいい経験となりました。自分がしんがりを務める体験はするとしないとで全然重みが違いますね。

2018年に向けて

家庭と仕事、そして健康を手に入れるための運動のバランスをうまく取りたいなと思います。

特に今年は仕事ではCloudera Data Science Workbenchという新プロダクトが出たこともあり、そちらの支援を全力でしてきました。合わせて社内外の機械学習系の導入に向けて教育やコンサル的な振る舞いをする機会が増えて、Data democratizationをしていくってこういうことだよなぁと思いなかなか楽しかったです。

Cloudera Data Science Workbenchは、k8sとDockerをベースとしたMLやDSの基盤として非常に便利で、コラボレーションのためのツールです。GPUもコンテナに紐付いて起動できるので、sandboxとしても非常に使い勝手が良いです。端的にいうと、Jupyterをgitとかで連携しやすくしたいい感じのものです。

後半は家庭のこともあり、割と一年全力疾走して来た気がするので、来年はもう少しバランスを取りつつ健康を高めていきたいと思います。筋トレとプロテインはちょいちょいと続けているのですが、腰が辛いのでジムに通うなどして運動を行っていけたらと思います。

英語に関しては、相変わらずDMM英会話でほぼ毎日続けています。多少壁を感じて来たのでなんとかしたいところです。

資産運用もそろそろ始めたいと思います。まずはiDeCoからやろう。

Appendix

最近会社のslideshareアカウントにスライド置くことが多いので、昨年の発表リストを貼ります。

Big Data Analytics Tokyo
Data Engineering and Data Analysis Workshop #1
人工知能学会 SIG-SWO研究会 42回
Cloudera World Tokyo 2017
Strata Data Conference Singapore 2017

2017年に買ってよかったもの

Fri, 29 Dec 2017 20:31:43 -0800

今年もあと少しで終わりですね。というわけで、今年買ってよかったものを書き連ねていきたいと思います。

去年のものはこちらです。

本の執筆もこのマシンで大部分行いました。軽くてバッテリーの持ちもよく非常に良い機体です。

詳しくは以下の記事を読んで下さい。

ゼンハイザー MOMENTUM On-Ear Wireless

国内外含めて飛行機での移動が増えたので、ノイズキャンセリングのオーディオが必要となり買いました。BOSEは音が好みではないのでゼンハイザーのこのヘッドホンを買いました。オンイヤーなので長時間つけているとちょっと圧迫感があるのが玉に瑕ですが、HD595, 650ともに持っている人なので、音は僕の好みにぴったりです。

今なら、飛行機用ならSONYのもいいけど、このネックバンドタイプのイヤホンを選ぶかなぁ。10時間のバッテリー持続と軽さを兼ね備えているので…。もう4ヶ月早く売っていれば買ったものを…。

Anker のUSB type-C 付きの充電器

これのお陰で出張時の荷物がAC不要になったのでコンパクトになりました。USB type-C のPD対応のものはなかなか外れだらけなのですが、規格にあったものを探して行き着いたのがこれです。

\[2018/01/06追記\]
Type-C情報で有名な によると、2017年8月に製品改修を行い、現在のバージョンではX1Cは充電できないようです。 Thx to さん
\[/追記\]

Google Home/Google Home mini。そしてNature RemoとSmart plug

Google Homeのおかげで、子供の計算練習用のタイマーもはかどり、またやスマートプラグを使うことで、リモコンでの操作を声でしたり、グルーピングしたオーディオ機器類を音声で一発起動できたりと便利です。また、幼稚園児の日本語の発音練習にも良かったようです。

Nature Remoの代わりにSiriとこれを連携している友人もいるようです。

ヨガマット

腕立てはプッシュアップバーでいいけど、腹筋やストレッチには直床は痛いなと思っていたので買いました。特にストレッチには便利です。

食洗機

諸般の事情で食洗機を導入しました。前職ではオフィスに食洗機があったので威力は知っていたのですが、拭かなくて良いのと油汚れを任せられるのは楽ですね。事情の詳細は下記を御覧ください。

Ergohuman Fit

腰を痛めているのでErgohuman Fitを買いました。Workaholicというお店で試し座りした上で買ったのですが、的確にアドバイスをしてくれるので是非店に行くといいと思います。

しかし、今年は物入りな年だったなぁ。。。

ワンオペ育児がやってきたヤァ！ヤァ！ヤァ！

Fri, 22 Dec 2017 22:01:03 -0800

この記事はの24日目です。昨日はでした。車のローンも繰り上げ返済できるから印税で返済しましょう！という話はしびれますね。

まきさんのいい記事を読んだ、いやぁ前向きな心持ちで育児をしていくの大事だよね、という話を学ばせていただきました。

生活リズムを作ってサイクル作るのは大事ですし、部屋は別でも布団に子供だけで突っ込んで寝かせるのはある程度年齢が進んでくればできるようになるかもしれません（うちは妻のおかげでなりました）

今回は、そうは言っても予期できないことは色々あるよねという話を書きます。

さて、「ワンオペ育児」という単語を聞いたことはあるかと思います。読んで字のごとく、一人で子育てをすることです。牛丼チェーンのワンオペで深夜対応すると言うところから転じてできた言葉だと思いますが、僕自身仕事がら海外出張1週間とか結構あるので、出張中「ワンオペ育児辛い」という疲弊したメッセージが妻から届くこともしばしばありました。

まぁ、そうは言っても仕事だし仕方ないよねと思いながら申し訳ない気持ちでいっぱいだったのですが、幸か不幸か妻が利き手を手術し数ヶ月使えないという展開になりました。そう、僕のもとにもワンオペ育児がやってきたのです。

我が家は、小学校低学年1人と幼稚園児が1人という4人家族です。実家はお互い現在居住地から遠く、ヘルプはあてにできない状況。今でこそ包丁は握れないけど、力のいらないことならできるようになってきたので、かなり分担できていますが、術後当初は二人いる子供の面倒を見ながら、基本一人で家事を回すわけです。最初の一週間は妻が痛みで寝込む中、弁当を用意し、朝ごはんを準備して、子供を学校へ送り出し、幼稚園まで送り、その後ご飯の仕込みをしながら仕事。妻の昼食を用意し、仕事。幼稚園の迎え、晩御飯の準備をし、洗濯をし子供を寝かしつけ、仕事。この1週間が永遠につづくのではないかと思い、絶望的でした。特に、弁当は厄介で飲み会で遅く帰った翌朝も6時に起きて必ず弁当を用意するというプレッシャーは絶大で、一度こりて以来夜のイベントは遠慮するようになりました。

この状況を打開するために、幾つかの策を講じました。

食洗機を導入した

今回幸いにして手術日は分かっていたので、事前に練った策として食洗機を投入することを決意しました。pyspaで賃貸で古い団地式のキッチンでも意外と行けると言われたので、ビックカメラに行き設置可否の確認及び工事諸々含めた見積もり依頼、そして設置に至りました。ビックカメラの食洗機の見積もりは無料で可能なため、急ぎの場合は店舗に行って日程交渉すると2,3日くらいで来てくれます。今回は最初に店舗に行ってから運良く1週間以内に設置できました。（窓際から補助台を使い設置するスタイル）

設置場所は、キッチンの窓に少し掛かる感じでパナソニックの食洗機用のステンレス台と脚を導入しました。そこも含めての見積もりに来てくれるので安心です。

食洗機は手を怪我した妻には無くてはならないもので（水仕事ができない）、副次的な効果として食洗機回している間に時間ができました。特に朝の忙しい時間を肩代わりしてくれるのが非常に大きいですし、妻からは育児の辛さが激減したと言われました。

朝ごはんをシリアルに変えた

朝ごはんは以前はパンを中心とした食事だったんですが、今回負荷を下げる目的で完全にシリアルに変えました。普段はパンを焼いてベーコンエッグを作ってミニトマトやら多少の野菜を準備してという流れだったのですが、自分の健康診断の関係もあり家族はフルグラ、自分はオートミールと豆乳にしています。副次的なメリットとしては豆乳でプロテインが飲めるようになったので少し飲みやすくなりました。

調理代行の依頼

もう一つの策として、家事代行特に作り置きの代行を依頼しました。

こちらは決断が遅れてしまったこともありギリギリに（とは言っても１週間前くらい）依頼をかけたんですが、結局DMMオカンもCaSyもタスカジも使いませんでした。我が家の場合、マッチングが恐ろしく難しかったというか苦痛だったからです。切羽詰まってる状況でのお見合い感覚のマッチングはかなり精神的に答えました。

おそらく、あるサービスで感じたのは、大抵移動時間30分以内という縛りがある代行者しかおらず、駅からバスで移動もある我が家ではマッチングが成立しづらいんだろうなと思います（事実断られました）。また、次の週末に作り置きを依頼できないと死ねる、という状況なのにマッチングまでに時間がかかったりというのも辛かったです。普段の余裕がある時は別にいいんでしょうが、初めての体験で急いで決めたいのに個別の状況を伝えることもできずシステマチックなマッチングで全然人が見つからず、これは都内か駅近だけのものか…と泣きそうになったのを覚えています。サービスやってた側からすると、そんな細かい条件を省くほうがコスト的には見合うのでそのとおりなんですが。

結局、市のシルバー人材センターに電話依頼したら、状況を慮って急ぎで人を見つけてくれて作り置きの依頼ができました。初回の打ち合わせは祝日なのにシルバー人材の方に代行で来ていただき、スムーズに手続きを開始することができました。また、お互い助かることに、調理代行者は徒歩圏内に住んでおり、元々食堂での調理作業を生業としており、かつ費用も一時間千円で2.5hで6品以上作っていただき、ただただ助かるばかりです。

なお、食材は以前から西友ネットスーパーと生協、Amazonでほぼ調達をしていたので、作り置き日の前日にまとめ買いをしておけば良いのと、調理してくださる方が割とコストを意識しながら作ってくださるので、妻が通常作るより食材を節約して作ってくださるのが思わぬ効果でした。

実は依頼する前にも一度、自分一人で1週間分の作り置きはしたのですが、土日まるまる潰して6品くらいしか作れず子供と出かける時間もなくなり途方にくれていました。シルバー人材のおかげで、子供と公園に行ったりする時間も取り戻せました。

乾燥機は毎日回す

その他としては、ドラム型洗濯機の乾燥機を毎日回すようにしました。それ以前は、フィルターの掃除が毎回しないといけなくて面倒、電気代も結構持ってかれるというところから週1くらいしか使っていなかったのですが、今はフル稼働しています。洗濯物を干す時間が相対的に減ったので、限られた時間を引き出すという目的には良いでしょう。

もちろん、これを実現するには会社もリモートで働くことを許してくれていたりという好条件もありました。サポートしてくれた同僚にも非常に感謝しています。

とにかく、世の中の育児大半が実家サポート前提で組まれている気しかしないよなぁと、基本的な戦略としては以下のようになるかなと思います。

お金で解決できるものはなりふり構わず投入する
諦められるものは全力で諦める
インターネット以外の方法もあたる

特に、シルバー人材センターのような、ローカルでインターネットじゃない方法も当たってみるものだなというのが大きな知見です。Lucene syntaxを脳内で組み立てられても、家事代行者は見つけられないし、AIも家事は代行してくれない。

途中でも書きましたが、今はだいぶ作業を分担できるようにはなったのでかなり楽にはなりましたが、ピーク時は終わりのない1週間を乗り切るのに必死でした。

でもこれ、介護でもやるんかな…。

明日の締めは我らがdanchoこと@hiroki_niinumaです。

オライリーから「仕事ではじめる機械学習」が出版されます

Thu, 19 Oct 2017 11:19:18 -0700

技術書典2で好評だったが、この度技術書典3に合わせて商業誌になります！今回もさんとさんとの共著になります。と言っても、基本電子版のみなので技術書典会場では購入できませんし、手にとって見ていただくことが出来ませんのでお気をつけください。なお、自社イベントであるでプリント・オン・デマンドで物理本を少部数限定で販売する予定です。

【追記】Ebookはこちらから買えます

【/追記】

【追記2】電子版大好評に付き2018年1月16日に物理版も出ました。Amazonさんで売り切れている場合は、お近くの本屋さんにお問い合わせください。

【/追記】

まえがきより

どういう本なの？

まえがきのスクリーンショットを貼りましたが、この本は多くの機械学習の本とは異なり、機械学習の実務で使えるようになるために知りたい、機械学習を含めたシステムのアーキテクチャや機械学習プロジェクトの進め方、効果検証をどうするのかということをまとめました。

めざすところのイメージ

既に多く刊行されているTensorFlowやChainerでディープラーニングをしてみようというものでもなければ、機械学習の理論をわかりやすく解説するといった類のものでもありません。やCourseraので学んだけど、実際の仕事に活かすにはどうしたら良いだろう？という疑問に答えているつもりです。また、大学の講義などで機械学習は学んだけど、実際仕事で機械学習のプロジェクトを進めるときはどうすればいいんだろう？という人にも得るものがあると思います。もちろん、敢えて数学の基礎には触れないなど、全てのことを網羅的に書けているわけではありませんが、僕やhagino3000さん、tokorotenさんたちの「業務をする上で身についた当たり前」をdumpした本になります。

hagino3000さんのA/Bテストの話はp値だけでなく検定力の話も含まれております、どういう罠があるかという気をつけるポイントも触れられています。

tokorotenさんのキックスターターの分析は、機械学習をする前の探索的分析とレポーティングの例としてとても面白いです。特に彼独特の語り口で、思考を追いかけるような気持ちで楽しめます。

【追記】

tomo_makesさんにわかりやすい図解をしていただきました。ありがとうございます！【/追記】

薄い本との差分は？

技術書典2で ”Big Mouth Data 2017 Spring” を購入いただいた皆様ありがとうございます。そんな皆様にも、新たに書き下ろしの章が増え、強力なレビューアー陣によるマサカリを反映した読みやすい文章などもう一度おすすめできる内容になったかと思います。

マサカリを投げきった人の感想

以下のような差分があります。

hagino3000さんによる、統計的検定と効果検証、A/Bテストの章を追加
tokorotenさんによるマーケティング施策への機械学習としてUplift Modelingの章の追加
chezouより機械学習の評価の章の追加
瀧澤さんによる日本語の大幅なimprove
美しいカラー図表

結局、ページ数としてはPDFで200ページ近くという思っていたより大きいボリュームになり、読み応えたっぷりになりました。

どこで買えるの？

オライリー・ジャパンのEbook Storeで10/22(日)買えるようになります。物理本については、11/7(火)のにお越しになっていただければ会場限定でPODのものが買えます。（サイン会も予定しています）

なお、同日販売の知人の書籍としてはさんの「Goならわかるシステムプログラミング」とtk0miyaさんの「Sphinxをはじめよう」が出ます。とくにお二人には同人誌のときにSphinx方面でのサポートを絶賛していただきました。よければ合わせて読んでみてください。

1章機械学習プロジェクトのはじめ方
- 1.1 機械学習はどのように使われるのか
- 1.2 機械学習プロジェクトの流れ
— 1.2.1 問題を定式化する
— 1.2.2 機械学習をしなくて良い方法を考える
— 1.2.3 システム設計を考える
— 1.2.4 アルゴリズムを選定する
— 1.2.5 特徴量、教師データとログの設計をする
— 1.2.6 前処理をする
— 1.2.7 学習・パラメータチューニング
— 1.2.8 システムに組み込む
- 1.3 実システムにおける機械学習の問題点への対処方法
— 1.3.1 人手でゴールドスタンダードを用意して、予測性能のモニタリングをする
— 1.3.2 予測モデルをモジュール化をしてアルゴリズムのA/Bテストができるようにする
— 1.3.3 モデルのバージョン管理をして、いつでも切り戻し可能にする
— 1.3.4 データ処理のパイプラインごと保存する
— 1.3.5 開発/本番環境の言語/フレームワークは揃える
- 1.4 機械学習を含めたシステムを成功させるには
- 1.5 この章のまとめ
2章機械学習で何ができる？
- 2.1 どのアルゴリズムを選ぶべきか？
- 2.2 分類
— 2.2.1 パーセプトロン
— 2.2.2 ロジスティック回帰
— 2.2.3 SVM
— 2.2.4 ニューラルネットワーク
— 2.2.5 k-NN
— 2.2.6 決定木、ランダムフォレスト、GBDT
- 2.3 回帰
— 2.3.1 線形回帰の仕組み
- 2.4 クラスタリング・次元削減
— 2.4.1 クラスタリング
— 2.4.2 次元削減
- 2.5 その他
— 2.5.1 推薦
— 2.5.2 異常検知
— 2.5.3 頻出パターンマイニング
— 2.5.4 強化学習
- 2.6 この章のまとめ
3章学習結果を評価しよう
- 3.1 分類の評価
— 3.1.1 正解率を使えば良いのか？
— 3.1.2 データ数の偏りを考慮する適合率と再現率
— 3.1.3 F値でバランスの良い性能を見る
— 3.1.4 混同行列を知る
— 3.1.5 多クラス分類の平均のとり方: マイクロ平均、マクロ平均
— 3.1.6 分類モデルを比較する
- 3.2 回帰の評価
— 3.2.1 平均二乗誤差
— 3.2.2 決定係数
- 3.3 機械学習を組み込んだシステムのA/Bテスト
- 3.4 この章のまとめ
**4章システムに機械学習を組み込む
**- 4.1 システムに機械学習を含める流れ
- 4.2 システム設計
— 4.2.1 混乱しやすい「バッチ処理」と「バッチ学習」
— 4.2.2 バッチ処理で学習＋予測結果をWebアプリケーションで直接算出する（リアルタイム処理で予測）
— 4.2.3 バッチ処理で学習＋予測結果をAPI経由で利用する（リアルタイム処理で予測）
— 4.2.4 バッチ処理で学習＋予測結果をDB経由で利用する（バッチ処理で予測）
— 4.2.5 リアルタイム処理で学習をする
— 4.2.6 各パターンのまとめ
- 4.3 ログ設計
— 4.3.1 特徴量や教師データに使いうる情報
— 4.3.2 ログを保持する場所
— 4.3.3 ログを設計する上での注意点
- 4.4 この章のまとめ
**5章学習のためのリソースを収集しよう
**- 5.1 学習のためのリソースの取得方法
- 5.2 公開されたデータセットやモデルを活用する
- 5.3 開発者自身が教師データを作る
- 5.4 同僚や友人などにデータ入力してもらう
- 5.5 クラウドソーシングを活用する
- 5.6 サービスに組み込み、ユーザに入力してもらう
- 5.7 この章のまとめ
**6章効果検証
**- 6.1 効果検証の概要
— 6.1.1 効果検証までの道程
— 6.1.2 オフラインで検証しにくいポイント
- 6.2 仮説検定の枠組み
— 6.2.1 コインは歪んでいるか
— 6.2.2 二群の母比率の差の検定
— 6.2.3 偽陽性と偽陰性
- 6.3 仮説検定の注意点
— 6.3.1 繰り返し検定をしてしまう
— 6.3.2 有意差とビジネスインパクト
— 6.3.3 複数の検定を同時に行う
- 6.4 因果効果の推定
— 6.4.1 ルービンの因果モデル
— 6.4.2 セレクションバイアス
— 6.4.3 ランダム化比較試験
— 6.4.4 過去との比較は難しい
- 6.5 A/Bテスト
— 6.5.1 2群の抽出と標本サイズ
— 6.5.2 A/Aテストによる均質さの確認
— 6.5.3 A/Bテストの仕組み作り
— 6.5.4 テストの終了
- 6.6 この章のまとめ

第II部

**7章映画の推薦システムをつくる
**- 7.1 シナリオ
— 7.1.1 推薦システムとは
— 7.1.2 応用シーン
- 7.2 推薦システムをもっと知ろう
— 7.2.1 データの設計と取得
— 7.2.2 明示的データと暗黙的データ
— 7.2.3 推薦システムのアルゴリズム
— 7.2.4 ユーザー間型協調フィルタリング
— 7.2.5 アイテム間型協調フィルタリング
— 7.2.6 モデルベース協調フィルタリング
— 7.2.7 内容ベースフィルタリング
— 7.2.8 協調フィルタリングと内容ベースフィルタリングの得手・不得手
— 7.2.9 評価尺度
- 7.3 MovieLensのデータの傾向を見る
- 7.4 推薦システムの実装
— 7.4.1 Factorization Machineを使った推薦
— 7.4.2 いよいよFactorizatoin Machineで学習する
— 7.4.3 ユーザーと映画以外のコンテキストも加える
- 7.5 この章のまとめ
**8章 Kickstarterの分析、機械学習を使わないという選択肢
**- 8.1 KickstarterのAPIを調査する
- 8.2 Kickstarterのクローラを作成する
- 8.3 JSONデータをCSVに変換する
- 8.4 Excelで軽く眺めてみる
- 8.5 ピボットテーブルでいろいろと眺めてみる
- 8.6 達成したのにキャンセルされたプロジェクトを見てみる
- 8.7 国別に見てみる
- 8.8 レポートを作る
- 8.9 今後行いたいこと
- 8.10 おわりに
**9章 Uplift Modelingによるマーケティング資源の効率化
**- 9.1 Uplift Modelingの四象限のセグメント
- 9.2 A/Bテストの拡張を通じたUplift Modelingの概要
- 9.3 Uplift Modelingのためのデータセット生成
- 9.4 2つの予測モデルを利用したUplift Modeling
- 9.5 Uplift Modellingの評価方法、AUUC
- 9.6 実践的な問題での活用
- 9.7 Uplift Modelingを本番投入するには
- 9.8 この章のまとめ
参考文献
あとがき

PyConJP 2017に参加した

Fri, 08 Sep 2017 20:24:23 -0700

2年ぶりにPyConJPに参加しました。2日間参加してきたので、メモがてら書いていきます。

興味深かった話

pandasとdaskのコミッターのさんの基調講演。pandasに対してどうコントリビュートしているかという話を中心に、OSS活動をしていこうと思わせる（1日目とは打って変わって）良い基調講演でした。

特に印象的だったのが、pandasの中ではAirspeed Velocityを使ってCIでベンチマークを取りコミット間の処理速度が低下していないかを検出しているという点です。Pythonのパッケージなので、他の言語では難しいかもしれないということです。ともすると速度のデグレは気づきにくいことも多いですが、OSSでそこまできっちり見ているのは素晴らしいと思いました。

なお、pandasやビジュアライズに入門するには昨日でたJupyter本が良いです。

リクルートテクノロジーズのさんによる分析基盤とカルチャーを作っていく話。どの話も、あーあーあるあるという感じで会場も共感の嵐でした。結局、現場のユーザが使うためには、独りよがりな基盤を作っても使われなければ無いから、コミュニケーションを取っていって必要なものを作っていこう、という泥臭さしかない話でした。こうしてデータドリブンで仮説を作っていく話はとても良いと思います。

Cookpadのさんの発表。自分が課題感感じているところかなと思ったら少し違った話でした。通常、ソースコードはgitなどでバージョン管理をするのに対して、モデルは比較的バージョン管理をしやすいけど、入力データのスナップショットをとることが難しいので、repeatabilityを確保するのは難しいよなと思っていたのですがその問題提起の話でした。

モバイルやセンサーからくるデータは遅延して到達したり、後で更新したりするみたいな時があったときや、データの欠損があったりしたときに、そのまましれっとモデルの更新をすると、データが原因なのかモデルがダメなのか何がダメなのかがぱっと切り分けられなくて、モデルの更新をしにくくなるという状況なのは辛いなという認識です。例えるならば、バージョン管理もテストもない状態でコード変更をして神に祈ってデプロイするイメージに近いです。（ゴールデンスタンダード使ったりなにか悪くなってることは検出できますが…）

解決方法はまだまだ発展途上だなというか、PySparkでETLしてS3上にHive形式のテーブル作ってそれをImpalaでもPrestoでも叩けばええやんという気持ちでいっぱいだったのですが、問題自体は重要な話であり、Googleなんかはどうにかしてクリアしているポイントのようなので、僕自身もなんとかしたいと思っている場所だったりします。良い解決方法考えていきたいところです。

もう一件、テキスト処理をPythonでやる話がありました。話の殆どは知ってる話だったのですが、spaCyが日本語対応したらしいよという話を聞いて、実はjanomeがTokenizerに使われているのをしりました。

なお、RからもspacyRというwrapperを使えるようでopenNLPとrJavaに疲弊している人は使うと良いようです。

感想

PyConはあまり知り合いも少なく、アウェイ感があるのですが、なんか地味に知り合いが増えてきたこともあり色々と話しをできてよかったなと思います。

実は一番印象に残ったのは、shimizukawaさんやtakuan_oshoさんなどインターネッツの中でしか見たことがない方とお会い出来たりお話できたことでした。また、色々とお話をしていると「ああ、aodagさんの文章を翻訳した人ですね」と言われて、地道な活動をしてきてよかったなと思います（虎の威を借る何とやらとも言う）

また、英語セッションで質問をしたら、何故か英語圏の人に囲まれて日本語のテキスト処理とコーパスが辛いんだけど、とか言う話を議論できたのは良かったです。

一方で発表は、今回初日のキーノートがただの会社の紹介に終止したマーケティングで終わったり、海外勢のデータ系がやってみた系が多かったりと結構辛かった一方で、日本人の発表者は非常に濃い良い発表が多く良かったなぁと思いました。特にcondaとwheelのfragmentationについてはなんとかならんかなと思って質問しましたが、お茶を濁されたのが悲しかったです。

ただ、自腹で1万円払って来年も行くかというとプログラム編成がデータ系が横に並んで厳しかったり、発表のクオリティの分散が激しかったりと悩ましいなぁというところです。自分はデータ系しかほぼ見てないのですが、2年前に参加したときはjanomeの話とか濃い話がありそう思わなかったのですが、RubyKaigiの方が講演のクオリティの平均が高い（ハズレを引きにくい）のかなと思いました。aodagさんのパッケージングの話とか（資料しか見てないけど）昔からの人の発表は安定感あったのですが…。

とはいえ、プログラム編成も投稿が山のようにきたりしている現状、SciPyあるいはScientific Programming, Data Analysis & MLみたいな言語を絞らないカンファレンスを日本でやって、それでガス抜きをしないとPyConには荷が重いだろうなぁと思います。イメージ的には、みたいな言語非依存なカンファレンスの科学計算版で、industrial trackとbeginner trackとresearch trackの3本立てでちょっと学会よりはゆるい感じの集まりかなぁ。

いずれにせよ、Pythonは今後もお世話になっていくので、PyCon JPの運営の皆さんに感謝しつつ燃え尽きないよう継続してって頂きたいなぁと思います。

Pythonの環境構築を自分なりに整理してみる

Fri, 25 Aug 2017 21:58:07 -0700

先日、 kawasaki.rb の懇親会で「AWS LambdaのためにPythonはじめたいんです」とか「機械学習系の本を読み始めたので、そこに書いてあったcondaではじめました」とかいう話を聞きました。

コレ読んでおけ系の記事は既に色々とあるんですが、今回は自分で触ってきて使っている環境を中心に説明をしようと思います。想定読者としては、Rubyを使っていたけど最近Pythonにも手を出すようになってきたという人です。

書き始めてから思ったんですが、ぶっちゃけPythonコミッターのmethaneさんの以下の記事を読めば十分な気もしてきましたが、一例としてお読みいただければと思います。

私の立ち位置

もともとは、数年前まで年に一回Python3でNLTKやらscikit-learnやら機械学習や自然言語処理の環境を作ろうと試みては失敗してPython使うものかと思っていた人でした。それが、Anacondaで環境導入すると、面倒なことは何も考えずに済むということを知り、CookpadではAnacondaを前提に環境構築を勧めていました。

今は、ymotongpooに「郷に入っては郷に従え」と言われたため、pip+virtualenv/venvで全てをこなしていますが、これで困ったことは特にありません。macOS, Windows, Linuxそれぞれでやっていますが、大きな苦労もなく大丈夫だなという印象です。

先に言っておくと自分のPython力はそこまで高くないです。もともとはRailsで開発はしていましたが、Pythonはほぼ機械学習やデータマイニング系のコードを一人で書くということが多いです。いくつかPythonのライブラリは書いて入るのですが、チーム開発の経験はないためその観点は弱いということを認識いただければと思います。

なお、仕事ではので、適材適所だなと思ってこの話を書いています。単純にpyenvやcondaを使うな、というつもりはありません。リスクとベネフィットのトレードオフで選んでください。

環境構築のあれやこれや

以下では、macOS, Windows, Linuxで自分がどのように環境構築をしているかについて書いていこうと思います。

最低限の前提知識

Pythonの実行環境の導入・パッケージ管理周りに出て来るキーワードについて簡単に説明します。

pip: パッケージインストールのためのツール。Rubyでいうところのgem。パッケージはPyPIというRubyで言うところのrubygems.orgから取ってくる。
virtualenv: パッケージを切り分ける仮想環境を作る人。Rubyで言うところのbundlerに近いが、Pythonの利用するバージョンも指定するのでrbenvのruby-build抜きの機能を持っている感じ
venv: Python 3から公式として入ったvirtualenv。ただし、venvはPythonのバージョン指定ができないとか、Debian/Ubuntuでは余計な依存関係が発生するとかで私は使ってません。

\[2017/08/30 追記\]

venvはバージョンの指定が出来ないのではなく、2.7と3.6との切り替えができないという意味でした。 python3.5 -m venv some-great-envで切り分けられます。
私自身パッケージ開発に2.7サポートをする場合があるのと、Ubuntu使いなのでvirtualenvを使っています。

\[/追記\]

以上が、多くのPythonistaに使われている基本的なツールセットです。このあたりの話は、PyPAと呼ばれるパッケージ管理関係の標準と参照実装を決める目的で設立された団体によってとして扱われています。（後述のcondaもでてきますが）

conda: Continuumという会社が作っているPythonを中心とした科学計算のパッケージ管理をするためのプラットフォーム
pyenv: rbenvのPython版。Pythonのソースからのビルドと、Pythonの実行環境（バージョンなど）の切り替えをする

これらは、特定の目的のために使うことが多いものです。

実行環境の導入

2017年においては、Python 3系の最新版を入れておけばだいたい生きていけると思います。が、何かしらの辛い事情で2系も使わないといけない場合もあるかと思います。

その場合は、自分はOSのパッケージ管理ツールでPythonを入れています。例えばUbuntuで apt install python-dev とするとPython 2.7が apt install python3-dev をすると今ならPython 3.6が入ります。同時に入れると

/usr/bin/python #<- 2.7
 python2 #<- 2.7
 python2.7 #<- 2.7
 python3 #<- 3.6
 python3.6 #<- 3.6

という感じで入ります。 brew installでも python と python3 で2系と3系両方入れることができます。

バージョンの切り替えは、後述のvirtualenvで実行するバージョンを切り替えます。逆に言うとpyenvでのバージョン切り替えは、ライブラリ開発者のように細かいバージョン切り替えが必要な人でなければ不要でしょう。

なお、homebrewは彼らの方針で過去バージョンのPythonはpyenvを使ってくれ、と言っています。MacPortsは普通に過去バージョンが入りますし、Ubuntuはを使えばこの問題は解決される話です。homebrewで切り替えたい人はpyenvを使うほうが楽でしょう。

WindowsだとChocolateyで入れるか、オフィシャルのインストーラで入れれば良いです。（ Python 3.6からは py というコマンドが用意されており、それを使うとバージョンを切り替えた実行もできます）

なお、絶対にやってはいけないのはSystem Pythonを使い続けることです。System Pythonは往々にして古いことが多く、またyumなどシステム上重要なシステムに依存しています。うっかり、 sudo pip install などしようものなら、環境を壊してしまう恐れがあります。

なお、環境構築に関する話は、以下の記事が参考になるでしょう。

パッケージ管理

まず、大前提として先程も書きましたが sudo pip install hogehoge をするのは辞めましょう。システムPythonはOSで使っているため、これの環境を壊すことは危険です。

プロジェクトごとにパッケージのバージョンを依存関係を切り替えるのには virtualenvを使います。以下の aodagさんの資料を読んで下さると良いと思います。

また、Python 3に関しては以下の venvのチュートリアルがわかりやすくまとまっています。Debian/Ubuntu以外の人はPython 3だけで良ければ venv で十分かと思います。

ここに書いてあるけど大事な話としては、 virtualenvでPythonの実行環境を切り替えられる話をしておきます。

まずは、以下のようにしてユーザ領域に virtualenvを入れます。

$ wget https://bootstrap.pypa.io/get-pip.py
$ export PATH="~/.local/bin/:$PATH"
$ python get-pip.py --user
$ pip install virtualenv --user

# Windowsの場合は特に考えずにpip installで良い
> pip install virtualenv

virtualenvでは、プロジェクトの下に仮想環境を作ります。プロジェクトルートで以下のコマンドを実行すると

$ virtualenv venv -p python3.6

Python 3.6を実行環境とした、仮想環境ができます。

$ echo venv >> .gitignore

で、 .gitignore に追加しておくとよいでしょう。

次に、 activate して仮想環境を有効化します。

$ source venv/bin/activate(venv) $

#Windows
> . venv/Script/activate

この状態で、 pip install scikit-learn とすると venv 以下にパッケージが入ります。仮想環境の利用を止めたい場合は deactivate コマンドを使いましょう。

pip 7.1以降ではconstraints.txtというGemfile.lockのようなものが扱えるようになりました。 pip freeze で現在インストールしているライブラリとバージョン一覧がでます。

(venv)$ pip freeze -l
pylint==1.7.2
pyparsing==2.2.0
pytest==3.2.1
requests==2.18.4
six==1.10.0
tox==2.7.0
urllib3==1.22
virtualenv==15.1.0

(venv)$ pip freeze -l> constraints.txt
(venv)$ cat constraints.txt
pylint==1.7.2
pyparsing==2.2.0
pytest==3.2.1
requests==2.18.4
six==1.10.0
tox==2.7.0
urllib3==1.22
virtualenv==15.1.0

ここに、プロジェクトに必要な必要なライブラリをrequirements.txtに記述します。

(venv)$ cat requirements.txt
requests
pyparsing

そうすると、以下のコマンドで必要なライブラリの必要なバージョンを入れることができます。

(venv)$ pip install -r requirements.txt -c constraints.txt

condaの話

Anacondaは機械学習などの科学計算向けのPythonディストリビューションです。Anacondaは、推奨パッケージを含めて入れるAnacondaと、自分で必要なパッケージを入れるMinicondaが入ります。Anacondaは（今はないですが）昔はDjangoを入れているなど重いパッケージも入ってくることがあるので、きちんとデフォルトパッケージを調べてから使いましょう。

なお、Pythonディストリビューションと書いてありますが、Rなど他の言語の環境を作ることもできます。

Anacondaはvirtualenvと違い、独自の仮想環境を作ることができます。特徴的なのは、 --copy というオプションを付けるとライブラリや.soなどをシンボリックリンクを作らず、コピーするということができるため、仮想環境一式をzipやtarで固めると、そのまま実行可能な形で使いまわせることです。

$ conda create -n myenv --copy python**\=**3.6
$ conda activate myenv

つまり、通常 apt などのOSのパッケージ管理で入れるようなところも、condaのパッケージで管理をします。condaはPyPIとは異なる独自のパッケージリポジトリを持ち、そちらにOSごとにバイナリをアップロードします。ですので、OpenCVなど同じ名前の同じものを入れるためのパッケージが複数のユーザによってレポジトリに登録されていたりと結構雑多な印象があります。

多くの機械学習の本では、condaを使えと書いて有ることが多いのですが、Windows以外ではあまり使わないほうが良いと私は考えています。

理由としては、以下が上げられます。

2017年においては、 wheel というバイナリパッケージのフォーマットがデファクトになっているので、condaの当初の目的の科学計算用のパッケージ（gfortanとかに依存していて辛い）を簡単に入れるという目的はcondaでなくてもできる。
普通に入れると、macOS/Linuxの (厳密には、 condaの方が先にPATHが通ってしまう) \[[issue](https://github.com/ContinuumIO/anaconda-issues/issues/1119)\]
パッケージ開発者は、condaユーザーではないことが多く、彼らからするとJRubyやRubyinius（あるいはWindows固有の不具合）など通常使わない環境でのサポートを求められるように感じる。
condaの世界で閉じていないNative extensionのビルド（Cython依存など）でincludeしないといけない情報などがうまく渡せず、はまると辛い
Distributionごとの違いが発生する場合もあるのに、OSレベルの違いしか考慮できない

ですので、Windowsの人や、開発は通常しないけど機械学習を体験してみたいという人はcondaを使うと良いでしょう。あるいは、pyenvの管理下でMinicondaを入れるか、私自身はDockerの中でcondaを使っています。

ただ、ScipyなどWindows用の一部は pip installでは入らないので wheelをダウンロードする必要があります。この点は正直condaの方が良いかと思います。

歴史的な詳細は下記が詳しいです。端的に言うと、wheel以前の古いバイナリフォーマットがいまいちだったため、condaを作ったという形になります。

カルチャーの違い

RubyとPythonでは色々と文化が違うのですが、一番大きな違いは個人的には以下の2点だと思っています。

できるだけ依存するものは最低限の薄いものが良い。ブラックボックスは好まないという思想
Rubyはいいものを皆が試して事実上のデファクトスタンダードになるのに対して、提案されたPEPという「標準」を合議して決めていくというスタイル

なので、Rubyはパッとデファクトが決まる印象がありますが、Pythonはじっくり議論の上で標準を決めていくという印象があります。（コレもあって、過渡期の実装が色々出てくる）

また、こうした経緯からかPythonの人たちはきっちり例外まで補足したがる傾向にあると思います（例えるなら、Pythonは数学科の数式にきっちり向き合う感じと、Rubyは工学部の数式に対する雑な扱いのような感じ）。なので、昔からのPythonistaが書くドキュメントは長くなる傾向にあると思いますが、そういうものだと思って割り切るしかないと思います。

まとめ

個人的には、普通に使う分にはvirtualenv/venvとOSのパッケージ管理ツールでPythonを入れるというので、私は良いと思って使っています。

ただ、プロダクション要求などで必要なものもあると思うので、condaとpyenvは適材適所で用法用量を守って使いましょう。

参考文献

OSSベースの機械学習が強い理由

Wed, 02 Aug 2017 11:29:59 -0700

英語版は _

TensorFlowの登場以降、OSSベースの機械学習の盛り上がりは加速しています。Kerasの作者のさんの言葉が、この状況を非常に端的に表しています。これだけでも十分だとは思いますが、この記事では、なぜオープンソースの機械学習が強いのか、最近のどういった流れがあるのかを整理したいと思います。

tl;dr

機械学習やDeep Learningのフレームワークが充実してきた
論文が査読前に公開され、他社も簡単にアルゴリズムの検証ができるようになった
多くのプレーヤーの参戦により、アカデミアでの機械学習の研究がレッドオーシャン化した
他社にないアルゴリズムで一発勝負、実装は秘密、というアプローチが厳しい

牧歌的な時代

5年前10年前の世界では、先端の機械学習に取り組んでいるのは大学などの研究室、大企業の研究所や一部の先進的な企業がほとんどでした。特に、ラベル付きのデータ量は現在よりも少なく、アルゴリズムを突き詰めて性能を向上させたり、特徴量エンジニアリングを頑張って性能を改善したりしていました。

この時代の先端の機械学習は、特に大学を中心としたアカデミアの人たちが国際会議に投稿をし、それが査読を通ったものが共有されるという形でした。実装が共有されることは今ほど多くはなく、各研究者は先行研究をスクラッチから再実装するということが多かったように思います。早くて半年、場合によっては1年以上のサイクルで新しいアルゴリズムがでてくるという時代でした。

オープンソースの機械学習ライブラリ/フレームワークとしては、古くはWekaのような機械学習用のライブラリを使う人もいれば、scikit-learnもされましたが、今ほど多くのソフトウェアエンジニアの間ではメジャーではなかったように思います。どちらかというとlibsvmやliblinearなど単一/少数のアルゴリズムのものが多く使われていた時代でした。

変化の激しい時代

2017年の現在では、機械学習に取り組む人は10年前に比べれば圧倒的に増えたのはみなさんもご存知のとおりだと思います。アカデミアが中心だった時代から、データを持つ企業の人達にも広がってきました。特に、機械学習に取り組んだことのないソフトウェアエンジニアにも身近な存在になったと感じています。私の主催しているkawasaki.rbでも今まで業務で機械学習に取り組んだことのない人が、Deep Learningに取り組み始めたという話を聞いて驚きました。この背景には、やはり企業が機械学習に使えるデータを貯めることが一般的になったこと、そして優れた機械学習フレームワークが増えたこと、GPUによるDeep Learningの効率的な計算が可能となったことなどが挙げられます。

TensorFlow, Chainer, MXNet, Caffe2, PyTorchなどの数々のDeep Learningのフレームワークだけでなく、XGBoost, Lightgbmなどkaggleで流行って使われるようになったオープンソースのライブラリも多いです。当然、scikit-learnも複数のアルゴリズムを試すフレームワークとして当然使えるものになっています。

オープンな論文の盛り上がり

こうしたは流れを支えているのは、一つは機械学習のコンペティションサイトのと、もう一つはと呼ばれるオープンな論文を投稿する場所の存在があります。（arxivは査読プロセスが入っていないため質が担保されておらず、それを論文と呼んでいいのか、などの議論はありますが、ここでは論文スタイルのドキュメントをざっくり論文と呼びます）

以下の記事に、arxivに投稿された機械学習関連（特にDeep Learning）の論文投稿数について記述があります。こちらの記事によれば、機械学習関連の論文の投稿数が、2017年には5年前に比べて4倍以上になっているという指摘がされています。

A Peek at Trends in Machine Learning

arxivの論文は、（査読がないこともあり）日々新しい論文が投稿されます。つまり、Google、Facebook、Microsoftなどの先端の取り組みが、査読前にどんどん論文として公開されています。これは、特に1年や半年単位で目標を設定して取り組むような従来型の大企業の中央研究所にとっては、機械学習の先端のアルゴリズム自体を研究開発するのはかなりのチャレンジになってきていると感じています。これについては「ただ部品を足しているだけ」という批判もありますが、牧歌的な時代のスピード感から目まぐるしく変わってきているのは明らかです。

最近では、日夜新しいarxivの論文を読み漁る人のために、新着論文をより良くチェックするためのという取り組みもされています。

arXivTimesのダッシュボードをリリースしました

オープンな論文が加速するオープンソースの機械学習

今年の3月にDeep Forestという論文がarxivで公開され、”Deep Learningよりも性能が良い”という主張もあって話題になりました。日本でもQiitaに訳が公開されるなど話題になったので記憶に残っている人もいるかと思います。

実はこの論文で提案された手法は、論文が出た日（2017/2/28）の約一週間後（2017/3/5）にはR実装がでてきて、その後Python実装も出てきました。このやり取りは、以下のLightGBMのissueでなされ、論文の再現性がないのではないか（謳われているような性能が出なかった）という話になりました。

arxivで公開された論文のOSS実装が1週間後には実装が出てきてコミュニティの議論が始まる、というスピードの時代になっている象徴的な出来事です。

また、会議によっては論文投稿時に実装を公開することが求められる国際会議も増えてきていると聞きます。

雑感

機械学習のアルゴリズム自体を考えることは非常に重要な仕事です。そして、オープンな論文、コンペティション、そしてOSS化されるという流れの加速、そこから得られた新しい知見を素早くビジネスへ適用するのがとても速くできる時代になりました。

個人的には、アルゴリズムそのものよりも、それをビジネスに活かすにはどうすればいいか、というところにフォーカスすることのほうが楽しい時代になってきたのでは、とも思います。

この状況を翻って言うと、「自社だけができる特別な機械学習のアルゴリズム」というのを押し出していくのはうまくいかない時代に入ったともいえます。（もちろん、アカデミアの人たちはデータを用意できればこうした最先端の取り組みを今後も推し進めていくでしょうが）企業1社で、Google、Facebook、Microsoftなど世界の多くの最先端の人たちよりも素晴らしいアルゴリズムが素早く出せる理由は何でしょうか？それが、オープンソースベースの機械学習の強い理由でしょう。

アカデミアでは昔から「」という言葉が知られていますが、先行研究という巨人に乗って次に進むということを示しています。オープンソースベースの機械学習でも、「巨人の肩に乗る」ということが顕著になってきています。

グローバル企業でコミュニケーションを円滑にするための「異文化理解力」

Sat, 29 Jul 2017 19:45:33 -0700

同僚のから勧められて、エリン・メイヤーの「異文化理解力」を読んだ。グローバル企業で働く人間として非常に示唆に富んだ良い本だった。

よく「日本は」「海外は」という議論が巻き起こることがあるが、これはそもそもナンセンスだなとぼんやりと思っていたことを明確にしてくれた。それは、文化は国によって相対的なのだ、ということである。

無論、こう書くと「自分は日本人の中でも特殊だ」とかいう国の中での分散はもちろんあるのだが、それが当たり前と生まれ育ってきたものは何が特殊なのかは相対化しないと認識できない。本書の中では、「」ということに対して、デンマーク人は特に違和感なく話しているという例が出ている。

これは、ただ国ごとにステレオタイプを列挙しているというよりのではなく、メイヤーは多くの国のビジネスをするマネージャーなどに対して調査をした。その結果、以下の8つの指標について、国ごとに相対的に比較をすることで、カルチャーマップというものを記述している。

コミュニケーションは「ローコンテクスト」？「ハイコンテクスト」？
評価の際のネガティブ・フィードバックは「直接的」？「間接的」？
説得方法は「原理優先」？「応用優先」？
リーダーシップは「平等主義」？「階層主義」？
決断のステップは「合意志向」？「トップダウン式」？
信頼はの構築は「タスクベース」？「関係ベース」？
見解の相違の解消は「対立型」？「対立回避型」？
スケジューリングは「直線的な時間」？「柔軟な時間」？

具体的には、下記の記事にフランス、ドイツ、中国、日本でのカルチャーマップの例があるので見てみると良いだろう。（なお、記事のグラフでは点で記述されているが、実際には正規分布のような分散の平均が点で結ばれていると思ってほしい、と書籍には書いてある）

この中の例では、同じアジアでも中国と日本は決断に関しては中国がトップダウン式で、日本は合意志向といったように、国ごとに大きな違いがある。反対に、ドイツと日本では時間が直線的に流れている（きっちりと時間を守るのが当たり前という認識で良い）が、中国はかっちりとスケジューリングをするのではなく変化に柔軟に対応する文化である。

つまり、我々がざっくり「アジア人だから」と言っても、その国によって相対的な文化差があり、それを踏まえた上で考えなければならないし、同じように「欧米」とくくるのも危険だということである。（オランダ人とアメリカ人のネガティブ・フィードバックの違いのエピソードは非常に印象深かったので、読んでみると良いと思う）

個人的には、この本を読むことで、オランダみたいなヨーロッパの人でもアメリカ人の褒めまくるのは胡散臭いと思っているということを知れたし、「ああ、だからアメリカ人は褒めまくるのか。アメリカ人のメールの文頭の”awesome!”は日本の『お疲れ様です』くらいでちょうどいいな」という知見を得られた。

シリコンバレーベースのグローバル企業で働いていると、会社にもよると思うがなんだかんだでアメリカの色が強くて、”diversity”というのも彼らが考える枠の中なのだなぁということを認識することがある中で、こうした本を読むことで、日本人としての自分の立ち位置を再認識し、どう振る舞うかを考え直す良いきっかけとなった。

Thinkpad X1 Carbon (2017)をWindows 10/Ubuntu 17.04デュアルブートにした

Sun, 09 Jul 2017 08:11:00 -0700

前回について書きましたが、今回はUbuntu 17.04とのデュアルブートについて書きます。

Ubuntu 17.04 on 4k monitor

基本的に、X1 Carbonに最初から入っているWindows 10がBitlockerが有効化されていてセキュアなので、以下を参照しながらデュアルブートにしました。（とはいってもうっかりUbuntu側をセキュアにし忘れた）

新しいマシンなので、OS新しめにしておいたほうが良いかなと思ったので、Ubuntuは17.04にしました。とりあえず、長く使うかもわからないなぁと思ったので、楽にできるで入れました。

トラックポインタ＆タッチパッドが動かない問題

デフォルトだと、16.04も17.04もトラックポインタもタッチパッドも動きません。USBのThinkpadキーボードがあったのでなんとか回避できましたが、これができないと結構きつかったです。

ursmさんのブログのお陰でマウス系が動かない問題も回避できました。(とりあえず、カーネルパラメータにpsmouse.proto=impsを指定してる)

これだと、タッチパッドに手を置くと誤動作するので、BIOSでタッチパッドをオフにしておきます。

1Password問題

1Passwordに依存していたのですが、Keypassとかを入れるのはだるいなということで、1PasswordはWineを使って入れています。あまり困っていないです。

USキーボードでの右AltでIME on/左AltでIME off

人間はIMEの状態を覚えたくないので（２回目）、右AltをIME on/左AltをIME offにします。やり方は、ここを参考に設定しました。

ただし、キーボード(日本語)が存在しないと、Mozcで入力しているときなぜか日本語配列になってしまうので、なければ追加します。

Ctrl-Capsの入れ替え & Emacs風キーバインド

gnome-tweak-toolを使う。

sudo apt-get install gnome-tweak-tool

ちなみに、gnome-tweak-toolでEmacs風のキー設定にできる。こちらはWindowsでkeyhacをやるより賢く？、テキスト入力エリアのときだけEmacs keybindになってくれるので、自分のようなぬるいEmacs keybindを求めている人には助かります。

ただ、この方法だとmediumのようにkeyboard shortcutをJSで奪ってくるタイプのサイトには負けるらしく、もう少し厳密に必要な人は別の手段が必要そうです。

デュアルブート下で時計がずれるのを防ぐ

そのままだと、Windowsに戻ったときに9時間時間がずれるので、Ubuntu側で設定を変えておく。

sudo timedatectl set-local-rtc true

Grubの設定変更をGUIでする

Ubuntuをprimaryでやろうとしたけど、Windowsの方をよく使っているので、Grubの優先順位をGrub Customizer使って変える。

sudo add-apt-repository
sudo apt-get update && sudo apt-get install grub-customizer

エディタはVisual Studio Code

別にJet Brains製品でもいいんですけど、とりあえずVSCodeをdebから入れておきました。

Python3とJupyterを入れる

ymotongpooさんの記事にもあるとおり、Debian/Ubuntu系のvenvは余計なものを入れるらしいので、virtualenv入れて使っています。

sudo apt-get install python3
pip3 install virtualenv
virtualenv hoge
. hoge/bin/activate

iRubyを入れる

まずは、rbenvとruby-buildを入れます。

次にiRubyですが、READMEに従って入れましょう。ただ、一点libzmq-devは16.04にしかないのでlibzmq3-devを入れましょう。

READMEのインストール手順を改変したのがこちら。

sudo apt install libtool libffi-dev ruby ruby-dev make
gem install cztop

sudo apt install git libzmq3-dev autoconf pkg-config
git clone
cd czmq
./autogen.sh && ./configure && sudo make && sudo make install

gem install iruby
iruby register –force

\[追記\]

とのことです。わざわざ自分でビルドしなくても、 sudo apt install czmq でいけるのかな。

\[/追記\]

Sphinxの執筆環境

Dockerのドキュメントに従って入れる。操作に sudo いることすら知らなかった。。。

あとは、以下の通りでOK。

sudo docker pull chezou/sphinx-recommonmark
sudo docker run -it -v $(pwd):/documents chezou/sphinx-recommonmark:latest make latexpdfja

\[追記\]user権限でもいけるとのこと\[/追記\]

iPhoneでの有線テザリング

勉強会などでテザリングが必要なときがよくありますが、その場合は

sudo apt-get install ipheth-utils
sudo modprobe ipheth

とすればOKです。これを永続化するためには、先程のサイトにあるように /etc/modules への登録をお忘れなく。

pbcopy/pbpaste

xselを使えばいけます。やり方はこちらのとおりです。

sudo apt-get install xsel

xselをあとは以下のようにaliasを設定すればOK。 ~/.zshrcに入れました。

alias pbcopy**=‘xsel –clipboard –input’
alias pbpaste=**‘xsel –clipboard –output’

環境変数周り用にenvchainを入れる

AWSのsecretsなんかを引数に渡して実行するために便利なenvchainを入れました。READMEに従うだけです。今回、libsecretのヘッダが入っていなかったので入れました。

sudo apt install libsecret-1-dev

まとめ

指紋認証とか細かいものは動きませんが、Skypeも入ってDMM英会話もできそうだし、BluetoothもWiFiも特に不安定なことなく動いています。Slackもアプリあるので困りません。会社的のVPNも通るし。

その他細かい設定は以下のサイトからつまんで設定しました。

困っていることとしては、例によってメモアプリをどうするかという点（これはGoogle Keepでなんとかやろうとしている）と、辞書をどうするかという点（これは絶望的）です。まぁ、ブラウザベースで頑張るかなぁ。

MBPからThinkpad X1 Carbon(2017)に移行した

Fri, 07 Jul 2017 20:14:24 -0700

joker1007さんもこともあり、MacBook Pro Retina(2015) 15インチが重すぎてしんどいので、を買いました。2.04kgから1.13kgへと大幅軽量化しました。外での打ち合わせや出張も結構増えてきて、Macは電源も含めると辛い重さになるので思いきって買いました。背中と腰が死にそうなので軽さは正義です。( 色々ご相談に乗っていただきありがとうございました！）

選定のポイントは

1.3kg以下
英語キーボード
メモリ16GB
15万円くらいまで

という条件で選んだのですが、最後まで残ったのはDell XPS13とX1 Carbonだけでした。最初は値段の安さと軽さに惹かれてZenbook 3をメインに機能と値段の比較表を書いていたんですが、途中で店頭でキーボード触ってみて、日本語キーボードだとホームポジションのままでエンターを打てない体になっていることに気づいたため、急遽USキーボードの条件を追加しました。最終的には、i7/512GB SSD(NVMe)/16GB RAMとモリモリになったため、17万くらいにはなったのですが、同じ構成をmacで組もうとしても20万は軽く超えるし重いので(macbookは軽いけどAirより遅いらしいし、MBP 13インチも1.37kgで26万で2コアi7だし)、良い選択をしたと思っています。\[追記\]ちなみに、1.3kg以下のマシンになると4コアは無理で、どちらかというとCore mとかYシリーズをどうしたら避けられるかという戦いになります。なので、はなから4コアは捨てています。\[/追記\]

合わせて買ったもの

HDMIはついているので、プレゼン用にVGA変換コネクタを買いました。問題なく動いています。

職場のモニターがDisplayPortじゃないと最大解像度が出なかったので買いました。自宅のフィリップスの4kモニタはHDMIで4k出ています。

付属のケーブルが長いため、短くするために購入しました。

なお、モバイル用のACアダプタとしてSwitchの充電器を買ったのですが、W数が足りなくスリープ時にしか充電しませんでした。

macOSからWindows 10/Ubuntuデュアルブートへ

512GBのSSD積んでいるのでWindows 10とUbuntuのデュアルブートにしています。会社の業務でOfficeとWebexへ依存しており、両方共Linuxでは厳しいということもあり、デュアルブートにしています。とはいえ、VMでもいいじゃないのという話もあるのでおいおい構成は見ていきたいと思っています。社内のエンジニアでLinuxメインでGoogle SlideとWebex on VMの人もいるみたいですが、様子見中です。

Ubuntuのデュアルブートはちょこっとハマりどころはあったのですが、また別途詳細を書こうと思います。

\[追記\]書きました \[/追記\]

Windowsの開発環境周りの設定

基本的にはymotongpooさんのまとまった記事を参考にしました。

Powershellをベースに、以下のものをいれました。

Python 3

Cmderの代わりにbabunも試しましたが、chocolateyでemacsもpython3も入らずに諦めまいした。

choco install poshgit
choco isntall python3

Cmderのフォント

特にこだわりはなかったので、RictyDiminishedを使いました。

Python 3とjupyter環境の導入

chocolateyでpython3を入れれば、 python で起動します。簡単ですね。

でも、numpyやscipy、pandasやjupyterはAnaconda使わないと簡単に入らないんじゃないの？と思う方もいると思いますが、Python 3ではwheel形式のバイナリでインストールすれば詰まることなく入れることができます。

今回は、下記のブログを参考に導入を勧めていきました。

といっても、厄介なのは様々な事情でscipyが pip install scipy では入らないので、からWindows用のwhlをダウンロードしてきて、pipで入れます。ついでに、numpyもmkl最適化されたものを入れます。（なお、良い子はvenv使って仮想環境activateしてから使いましょう）

pip install –upgrade pip
pip install numpy‑1.13.1+mkl‑cp36‑cp36m‑win_amd64.whl
pip install scipy‑0.19.1‑cp36‑cp36m‑win_amd64.whl
pip install jupyter notebook

これで、いつもどおりjupyterを起動できます。

jupyter notebook

jupyter notebook on Windows 10

irubyのインストール

chocolateyからRubyをインストールしたんですが、MSYSへの依存があるからダメだ！みたいなことを怒られたので、Ruby InstallerからRubyを入れ直しました。

後は以下の方法を使いiRubyを入れました。

が、後から調べてみると、もあるみたいです。まぁ、今回はいいか。

Sphinxでの執筆環境

以前blogにも書いたとおり、Dockerベースでやっています。

注意しないといけないのが、current directoryの指定のしかたが、 $(pwd) から ${PWD} にPowerShellだと変わることくらいです。

docker run -it -v ${PWD}:/documents chezou/sphinx-recommonmark:latest make latexpdfja

なお、エディターはVisual Studio Codeを使っています。

Emacsライクなキーバインドの設定

しばらくmacを使っていたので、ctrl+f/b/p/n/a/eなどで移動がしないとテキストを書くときの生産性が下がってしまいます。ここは、keyhacとfakeymacsを使って、対応しました。

ただ、そこまでEmacsの制約強い環境が必要というわけでもないゆるふわなので、結構fakeymacsよりはゆるくしています。config.pyはです。

Ctrl-Capsはお好みの方法で入れ替えてください。僕は普通にレジストリで入れ替えてしまいました。

右AltでIME on、左AltでIME off

macのときもUSキーボードで右cmdでIME on、左cmdでIME offにしていたのですが、これはalt-ime-ahkを使っています。（人間はIMEの状態を覚えたくない）

本当はkeyhac一つでやろうと思ったんですが、alt空打ちの設定をすると、他のAltと同時押し全パターンを記述しないといけない臭いがしたので諦めました。

日英/英日/英英辞書/シソーラス

ここが完全に鬼門で、macOSの辞書.appはチートであることを改めて思い知らされています。仕事柄英語の読み書きは非常に多いのですが、良い解が見つかっていません。昨今、英辞郎の辞書も暗号化がかかったみたいで、串刺し検索できる質の良い辞書がない感じです。

今は、アプリとしてはを使いつつ、を併用しています。

また、DMM英会話用にはChrome Extensionで以下の2つを使っています。Google Dictionaryの方は日本語を出すことで、ダブルクリックで選択すると英日と英英が同時に出ます。記事を読みながらの辞書引きには良いです。

なお、英文を書くときには文法をチェックしてくれるGrammarlyにもお世話になっています。Grammarlyは同僚のスコットランド人も使っていると聞いて有料会員になっていますが、海外のカンファレンスのproposalを書くときも、Businessの固めのチェックモードに切り替えることで対応ができて良いです。

メモアプリ

macOSではQuiverを使っていたんですが、Quiverはmacでしか使えないので、Google Keepを試してみています。最終的に、ConfluenceのWikiにコピペするのが辛いのですが、Windows/Linuxまたいだメモはなかなか良いのがないので悩み中です。

Apple Wireless Keyboard/Trackpadはどうしたか

結論から言うと使わないことにしました。キーボードはを買えば行けるのですが、これを買うのにもう少し足すとThinkpadのキーボードが買えるため、そっちに合わせることにしました。特に、Chromeのタブ移動がCtrl+page up/downなので、fn押しながら矢印がきつくなったのが主因です。

トラックパッドも頑張って有償のソフト入れてもスクロールと右クリックができるようになるだけなので、ちょっと辛いなと思って切ることにしました。

まとめ

マシンが軽量になり、性能は高くなり、総じて満足しています。Windowsも昔に比べると、そこまで問題を感じないですし、だめならLinuxメインで行けばいいかなと思っています。

Ubuntu周りの話はまた別の機会があれば書こうと思います。

企業がユーザを守るための学術データ公開

Thu, 25 May 2017 19:17:16 -0700

人工知能学会（以下JSAI）で発表された論文が、Pixivのデータを「晒した」ということで盛り上がっています。詳細は、以下のtogetterを見ていただければと思いますが、ざっくり言うとPixivで公開されていた女性向けランキングトップ10の二次創作小説（R-18）に対して「有害表現」を分類するという目的で、作者名とURLを論文に書いて炎上したということになります。

なお、以下のまとめの片方はコンテンツ提供側に、片方が学術的な立場に偏ったものになっています。今回、これに対して一つの解決策になるかもしれないと思い、自分の考えを書きます。

企業によるデータ公開の嬉しさ

私は、前職で主に大学などの公的な研究機関向けに自社のコンテンツを学術目的で提供するという取り組みを行っていました。詳細は、以下のブログを読んでいただければと思いますが、論文を書くためのデータを提供しますよ、という話でした。

【2017/05/27追記】
こちらでいただいたのですが、Pixivさんはしていますが、学習済みのモデルは利用できる用途が非常に限定されるので、多くの研究者にとってはあまり嬉しくありません。
【/追記】

前提としては、（Webサービスにはよくある話ですが）投稿していただいたコンテンツは会社に帰属するという規約ではあるものの、ユーザさんに対して不利益があってはいけない、という立場でデータ公開をしていました。

研究者へのメリットとしては、以下のような物を狙っていました。

通常中の人しか手に入らない、まとまった量のデータが手に入る
後発の研究に対して再現性を担保されている（標準的なデータセットたりうる）
チャンスが有れば、共同研究の糸口になる（資金獲得のルートを手に入れる）
クローラを書く時間を、研究に当てられる

特に一点目については、IT系の特定の大企業が情報を独占しており、それが外に出ることがまずない、という指摘がなされていますし、それも原因でアカデミアからどんどん優秀な研究者がGoogleやFacebookなどの企業に吸い込まれているという話もあります（個人的には、ユーザに有益なサービスを提供する事がデータを集める重要なポイントだとは思いますが）。以下の記事からも、データは新しい石油だという事がわかります。

一方、提供をしていた企業側としての狙いは以下のようなものでした。

自社に関係のある研究を加速することで学術界に貢献をする・優秀な学生にリーチする
最先端の技術を自社コンテンツに適用したものを、いち早く応用につなげる
コンテンツID、ユーザ名などをマスキングすることで、論文に対して直接的な情報を出さなくても良い
自社のユーザが不利益を被るようなものをpublishさせない

この中でも特に最後のポイントについて書きたいと思います。

ユーザを守るためのデータ公開

あまりこの点については触れられることはなかったかもしれませんが、クックパッドでは論文投稿の前にドラフトを送ってもらうことを約束してデータ公開をしています。これは何のために行っているかというと、法的・広報的にNGなものがないか、ということもありますが、ユーザに対して不利益が生じることはないか、という事を確認するために確認をしていました。

例えば、「機械学習を使って、人の直感にあったマズイレシピランキングができました」という発表がもしあったとして、それに対して当然投稿者は不快な感情をいだきます。こうしたものに対して交渉するために、チェック機構が存在します。もし、手法が学術的に価値があったとしても「本当にマズイレシピでなければいけないのか。美味しいレシピランキングでも成立するのでは」などというように、本質に触れないポイントで改善の余地があるかもしれません。コンテンツ提供者にとって、投稿物は自身の表現の一つであり、プラットフォーム側は最大限それを尊重しなければいけません。学術向けにデータ公開することで、本丸である大切ユーザが離れては本末転倒です。

データ公開による利用側・提供側のコスト

こうした確認をするために投稿の数週間前に、原稿を送ってくださいと言っていたのですが、これは投稿者側にとっては負担が大きいです。ギリギリまで改善するのが当たり前な大学の研究者にとっては、そのとおりだと思います。これについては、データ公開企業の確認者はさらにギリギリの〆切の中改善案を提案しなければいけないことや、大企業の研究所では投稿の数週間前に、社外発表申請のためにドラフトを社内申請しなければいけないということもあるのを知っていただければと思います。

もう一つ、公開データを利用したい研究者に対する負荷として存在するのが、「研究科長の印鑑を押すこと」です。これは、良く「たかだかデータセット手に入れるために印鑑いるのだるいわー」と言われていたのですが、あくまで一種の契約を結ぶので、トラブル発生時に研究者（学生の場合もあります）に対して責任を問うのではなく、企業として組織同士で話せるようにという配慮の元、そういう条件を課していました（法務の人も交えてそういう立て付けにしました）。

結局、どういう形がいいのか？

ここは、はっきりいって企業側が最低限のコストを払えるかにかかってきます。体力がない企業にとってはできないというのは間違いありません。ですが、トレードオフを認識した上でも、ユーザを守るために敢えて利用条件を付与した上で公開するという方法もあるのではないか？と思い、今回の記事を書きました。

学術界としては野良でクローリングするよりも、公開データを使ったほうが再現性も保証されるので共通のベンチマーク対象になり、望ましいということがあります。そして、そちらを使うのが当たり前になるという効果が狙えます。

また、今回の論文をデータ公開されて自分が確認をしていれば、著者と事前に議論をして不快に思われる部分をどうにかできたんだろうなぁと思います。

JSAIについては、いつぞやの表紙問題も含めこういった炎上案件に対しては迅速に適切に対処してくれる学会だと思っています。無理はしないように、適切に対処されることを望んでいます。

体験したことのない概念を教えるということ

Wed, 24 May 2017 18:07:52 -0700

最近、子供にルビィのぼうけんやスクラッチの本を買ったら子供が読んでとよくせがまれるようになった。

ルビィのぼうけんはパパが隠した宝石を見つけるために様々な謎を解いていくという、フィンランドのリンダさんが描いた絵本だ。本の後半には、練習問題があり、パズルのような謎で、子供としては楽しく算数のようなパズルを解いていく感覚で取り組んでいる。

例えば、人参、青リンゴ、ピーマン、オレンジなどを、緑グループと果物グループのベン図にそれぞれ配置する、なんて問題は幼稚園の頃には難しかったが、小学生になった今ではさらっと理解できるようになり、子供自身の成長を感じる。

ルビィのぼうけんの訳者のとりいさんはpodcastでも笹田さんと共にインタビューさせていただいたのだけれど、訳語に対してとても丁寧に考えてらっしゃるなというのが読んでても伝わってくる。True/Falseは英語的には簡単な語だけど、真偽という言葉は難しい、などと当たり前だけど大事な子供の目線で言葉選びをきちんとされている。

そんな娘が、最近ルビィのぼうけんの続編とスクラッチの本にハマっている。

コンピュータの国のルビィは、アリスよろしくいなくなったマウスポインタを探すために、コンピュータの中に旅をする。そこで出会うのが、0/1で話すスイッチやCPU,GPUなどのハードウェア達。前作のジャンゴくんやユキヒョウ達よりももっと特徴的な仲間達と出会うのだ。そう、コンピュータの仕組みを説明する絵本なのだ。

読み終わって練習問題がやりたいと言い出す子供と見ていると、付録の紙で自分のオリジナルのコンピュータを作ろうとか楽しい。1週間で家の中のコンピュータを探してみよう！という課題もうんうん唸りながらいろいろ探して来た。うちの子供賢いんじゃないの、とかちょっと親バカなことも頭によぎった。

で、ふと、しめりけセンサー（湿度センサー）とおされる力センサー（圧力センサー）などのセンサーところになると、止まってしまった。これらのセンサーどういうところで活用できるかな？という課題なのだが、そもそも湿度ってなんだっけ？からわからないのである。「湿度とは空気中の水分の含有率で」、なんて話は通じないわけである。さあ困った。雨が降った時はジトジトするよね、とか、晴れた日はカラッとするよね、とか知識の引き出しから様々なものを見つけて来ては説明するが、腹落ちしている様子はない。

同じような話が、スクラッチの本でもあった。ゲームをほぼやったことのない子供に対して、アクションゲームとは、ロールプレイングゲームとは、というのを説明したのだがイマイチピンと来ていない。夫婦で「大昔の人が伝聞から想像した象が支える世界みたいなのイメージしてるんだろうね」と話をしている。結局、自分で見聞きしたもの体験したことのないものを教えるのはすごく難しいという結論に至り、ウノやらなんじゃもんじゃといったボードゲームなんかを買った。（なんじゃもんじゃはカードのキャラに名前を勝手につけて覚えるという3歳児でもまぁ遊べるシンプルルールでおすすめ）

セサミストリートに学ぶ知らない概念を教えるということ

以前どこかでも言及をしたが、セサミストリートでは俳優などに一つの英単語を説明してもらう動画を公開している。

この動画は、ロードオブザリングのガンダルフことイアンマッケランがクッキーモンスターに resist という単語を教えている。最初は欲しいものを我慢することだよ、とか、この宝物である指輪（もちろん例の指輪）が欲しくても手に入れないことだよ、とかいっても通じないわけである。（いとしいしとなのに！）

ところが、「君の大好きなこのとっても美味しいチョコチップクッキー。これ、食べたくて仕方ないよね？でも食べない。これが resist 」と言うと「あああああー！クッキーを食べたい、けど食べない。resistわかった！」と一発で理解するわけである。そう、やはり自分の事として考えられる体験に裏打ちしされて概念を獲得していくのが一番手っ取り早いのである。なので、最近はどういう体験をさせてあげられるかというのを以前より良く考えるようになった。

当たり前の事ではあるんだけれど、抽象的な概念を獲得していく事が多くなってくると、子供の根源的なこの獲得の流れを忘れてしまうなぁと気づいた瞬間だった。

Amazonで買ったThinkpad トラックポイントキーボードを修理した

Wed, 19 Apr 2017 11:58:17 -0700

みんな大好きトラックポイントキーボードですが、僕も昔使っていて最近miyagawaさんが使っていると知って再び使うようになりました。

今はThinkpadがIBMからLenovoに移管したので、故障などしたらLenovoに問い合わせる必要があります。ですが、保証書には3年保証と書いてあるものの、問い合わせ先のドメインがIBMのままで連絡先がわかりません。そのため、Amazonで買って故障を経験した人が、「次回は修理ができるように通常の販売店で購入します」と書くなど皆さん苦労されているようです。今回買って3ヶ月（厳密にはWishlistからいただいてから3ヶ月）で壊れたトラックポイントキーボードを修理したので、やり方をメモしておきます。

出版社/メーカー: レノボ・ジャパン
発売日: 2013/06/25
メディア: Personal Computers

1. 保証書とAmazonの購入履歴を用意する

Amazonは、アカウントサービスの注文履歴から、「注文の詳細／購入明細書」というのが見ることが出来ます。通常、Amazonで買った保証書には、店舗名等は記載されていないのですが、こちらの購入明細を用意できれば問題はないそうです。

僕の場合は、wishlistからいただいたものだったので、送っていただいた方に連絡をしてPDFを送付していただきました。

2. レノボ・スマートセンターに問い合わせる

電話で問い合わせをします。携帯からだとお金がかかるので注意してください。電話は、「Thinkpadシリーズ」と「その他・よくわからない場合」で分岐するところがあるのですが、なんとなく後者にしてしまいました。

症状とともに連絡をしましょう。なお、自分の場合はある朝起きたら熱を持ったキーボードが反応しなくなっていたため、修理を依頼しました。ケーブル起因なのか、マシン起因なのかということを問われるので、事前に切り分けをしておくと良いでしょう。

3. メールで保証書とAmazonの購入履歴を送付する

先方から教えていただけるメールアドレスに対してメールを送ります。すると、折り返し電話がかかってきます

4. 交換品が送られてくるのを受け取る

交換品を佐川急便さんが送ってきてくれました。大体2,3日で配送されましたが、在庫が切れたタイミングなどでは1週間ほどかかることもあるそうです。

5. 故障品を送り返す

数日後、別便で故障した品を受け取りにくるそうです。来るそうですと言っているのは、まだ自分の場合はsend backをする前の状態だからです。正直、iPhoneなどと同じようにその場で発送できてもいいのにな、と思います。

というわけで、Thinkpadトラックポイントキーボードが壊れても、無事交換していただけます。安心して使い倒せますね！

Docker imageを用意してWindows/macOSでスムーズに同人誌を作った話（Sphinx編）

Sat, 08 Apr 2017 09:47:29 -0700

こんにちは、ハイラルに移住したchezouです。最近は、Rから始まりRで終わる言語をよく書いています。

いよいよ明日に迫ってきたですが、お-13でとして頒布を行います。内容は、僕の機械学習の実務におけるtipsとfastFMを使った推薦、@tokorotenさんのKickstarterの分析、@hagino3000さんのスプラトゥーンのデータマイニングということで盛り沢山です。初めての同人誌ですが、140ページを超えた薄くない薄い本になりました。

是非買いに来てください！

tl;dr

技術書を書くときに、LaTeXを含んだDocker image使ってCIでビルド出来るようにすると共同執筆が捗るよ

前回までのあらすじ

今回は、メンバーがWindowsの人とmacOSの人の混成チームであったこと、全員がPythonに馴染み深い人だったので、reStructuredTextベースのSphinxで書きました。

なお、メンバーの中には一度Jupyter notebookで下書きを書いて、それをnbconvertを使ってrstとして変換する人もいました（賢い）。この辺、Jupyterは元々Pythonのエコシステムなので数式含んだJupyter notebookをrstまで変換できるなら、良い選択肢かもしれません。

SphinxのDocker imageの作り方等は過去に書いているのでそちらを参考にしてください。

なぜDocker imageを用意したか？

原稿執筆は余計な障害（環境構築とか）が入ると、その対応で燃え尽きる
原稿執筆は往々にして〆切ギリギリから開始するので、最短距離を走れるようにしたほうが成功確率が上がる
OSが異なる環境でのLaTeX周りのトラブルシュートをしたくなかった
ビルドにコケる原稿のpushが防げた

この目論見はすべて当たりました。実際に、共著者の皆様からはすぐに執筆開始できたとの喜びの声をいただきました。

[追記]

じつはどちらもLinuxで書いていたともいえることがわかりました…

windowsの中のvmwareの中のubuntuの中のdockerで執筆環境を動かしていたので、Windows環境かと言われると疑問符が……

執筆自体は、ubuntuのhomeをwin-sshfsでwin側にマウントしてterapadでやってましたが。

— ところてん (@tokoroten)

おもしろ執筆環境。

— ところてん (@tokoroten)

お、自分は何も見ずにrstが書けるようになった時点でdocker runしてるAmazon Linux上のvimで執筆してました

— 超循環評価器@中欧放浪中 (@hagino3000)

[/追記]

Sphinxのdocker imageでできたこと

WindowsでもmacOSでもすぐに書き始められる状況を準備できた
Gitlab CIを使って、マージされたものをCIでPDFを用意する
奥付を作る
（docker image関係ないけど）re:viewで書きかけていた原稿をreSTに変換できた

奥付については、少しトリッキーなので後述します。

Sphinxのdocker imageでできなかったこと

原稿のグレースケール化（Adobe Acrobatでやった）
納得の行くfontの埋め込み（ヒラギノを使うためにmacOSでフォントを埋め込んだ）

Previewのグレースケール化は信用ならないので、グレースケール化には少なくともmacOSだとAcrobatが必須かもしれません。

fontの埋め込みは、IPA系のフォントだとライセンス的に問題なくコンテナ内で埋め込めるのですが、日本語の太字が綺麗にでなかったので結局MacでSphinxをビルドしてヒラギノを埋め込みました。¹ そのおかげで、tokorotenさんの原稿の画像サイズが少しずれて手直しが入りました。。。dockerベースでフォント埋め込みまでやっていればいけたのに…。無念。

奥付の作り方

以外とハマったんですが、以下のgistのように一度citationをflashすれば行けます。デフォルトでは、citationが必ず最後に来るようになっていますが、それを回避できます

Re:VIEWの書きかけの原稿をreSTに変換できた（相互変換出来る時代に）

実は書きはじめのときに、shirouさんがRe:VIEWの原稿をSphinxの原稿に変換していただきました。ありがとうございました。

github.com

何故か手元にあった結構ボリュームのあるRe:VIEWの原稿を変換できて、大体の問題は解決されているのではないかなと思います。

なお、逆向きのSphinxの原稿からRe:VIEWを出力するプラグインもあります。これで、気が変わって別のフォーマットにexport/importが容易になりましたね！

github.com

おわりに

今回は、shirouさん、shibukawaさん、tk0miyaさんといった#sphinxjpの皆様にお世話になりました。困ったことがあったときに、日本語で聞ける環境があるというのは非常に助かりました。

それでは、明日は秋葉原UDX2階のアキバ・スクエアで僕と握手！

ヒラギノは商用利用可能とのことです ↩︎

Indigogo ではじめてバックして来た dot を使って3ヶ月がたった

Mon, 30 Jan 2017 14:02:42 -0800

最近のbackspace.fm でdotが「来る来る詐欺」でAir podsに完全に飲み込まれたという話が出ていたので、きちんとレビューしてなかったのを思い出したのでレビューします。

dotは一言で言うと、AirPodsみたいな小さいBluetoothイヤホンです。

はじめての Indigogo

僕がバックしたのは、miyagawaさんがdotみたいなイヤホンをinstagramか何かで買ったというのを見て、これかな？と勘違いしたからだったんですが、2015年12月にindigogoでバックしてたみたいです。ステレオで$79+$29のシッピングコストです。最初の申込みから少し遅れていたのですが、当時は2016年4月に届く予定と言っていて、結局届いたのは2016年の10月でした。

はじめてのIndigogoで学んだのは、バックしたときが欲しい気持ちの最大値になっていて、届く頃には類似品が出てきて市場が開拓されていて切ない気持ちになること。こなれたものを手に入れたいなら待っていたほうがいいのかもなーと思いました。

dot レビュー

www.instagram.com

箱はこんな感じでおしゃれ。

www.instagram.com

中身もきちんとオシャレに梱包されています。

www.instagram.com

充電器兼ケースは、イヤホンがそれぞれマグネットでひっついて充電されます。重さもたいしてないので、ポケットの中に充電ケースを常に入れておいて、オフィスや家についたら充電するような感じにしています。

ケースの充電はケースを2つに割って真ん中にある穴にmicro USBで刺すのですが、真ん中で別れるところもマグネットでひっつくため、バラバラでどっか行ってしまうということはありません。ただ、ケースを充電しながら給電できるのは、片方だけなので注意が必要です。また、モノラル二個としても使えるので、片方充電してもう片方は聞き続けるという使い方も可能です。公称値で3時間持つと言っている電池ですが、backspace.fmや最近のrebuildは通しで聞けるかどうかはわかりませんが、充電器を忘れて往復2時間弱の通勤で充電しないでも再生し続けられたので、なんとかなるかもしれません。

www.instagram.com

大きさは小さめの腕時計よりも更に小さい感じ。AnkerのIE20と比べて見ても小さいのがわかります。

Bluetoothのペアリングは、JabraよりはいいけどAnkerのIE20と同じくらいかなという印象です。めちゃくちゃ安定はしてなくて、街なかでちょこちょこ切れる感じだけど、我慢できる範囲です。最近のiOSのアップグレードで接続は安定してきましたが、一度ペアリングが切れかけると片方ずつ接続が復帰するので同期するまでに少し時間がかかります。¹

音については、個人的にはIE20の方がクリアで好きかなという印象です。個人的には、こもった感じがしてそんなにいい音だとは思いませんでした。遮音性に関してはIE20よりもよく、うっかりすると周りの音を聞き逃す感じです。

操作は、最初に同時に長押ししてペアリングをして、その後iPhoneなどとペアリングするという流れです。一度Dot同士をペアリングしてしまえば、後は気楽に使えます。電源オンは両方のスイッチを3秒くらい長押しする感じです。タイミングずれててもいいですが、どっちが右か左かはまぁ音がでるのでそれを聞いて間違っていたら入れ替えています。電源オフはどちらかのスイッチを3秒くらい長押しすると両方消せて、1秒長押しするとSiriが起動する感じなのは今時の感じですね。マイクの拾いはそんなに良くないかな、と思うので、あまりメインで使うのには向いていないのかもしれません。

軽くて小型なので、カジュアルに持ち運びができてポケットにとりあえず突っ込んでおくという運用ができるので気に入っています。

今となってはAirPodsが安定していると評判なので、そちらのほうが良いかもしれませんが、$100で手に入ったということではいい買い物をしたな、と思っています。

前のiOSのときはブチブチ切れていて本当に辛かったけど、最近は良い ↩︎

また一つ年をとった

Wed, 25 Jan 2017 04:44:08 -0800

同い年のmirakuiさんがCTOになったりして、そろそろ組織に中で立ち回りが変わる年代なのかなと思ったりしてる。ちょうど一年前の今頃今の会社の面接を受け、初めての英語の契約書を1日2日で読んだりして、色々と慌ただしくしたところから首にならずに一年経った。backspacefm聞いてると、外資は当たり出し続けないと干されるよねみたいな話もあったので、価値を出し続けていきたい。コードを書く時間は減ったけど、いいペースで新しいプロダクトがでる変化の激しい会社なので、誰の役に立つものなのか考えて伝えていくのは楽しいと思ってる。幸いにして同年代がオフィスにもpyspaにも多いので、自分の役回りにあまり不安はないので、できることを少しずつ広げようとしている。

また、kawasaki.rbが三年半以上続いているのもありがたい限り。Rubyだけではない地域の技術の集まりとして、これからも細々と続けていきたいです。

最近のトピック - 在宅勤務のしすぎで運動不足のため、夫婦で30日スクワットトレーニングを始める。楽しい - podcastの出演者を探すのがちょっと大変になってきた。相棒/出演者欲しい - 昔全然聞けなかったが普通に聞けるようになってた - Pythonばっかり書いてたら、Rも書くようになった。dplyr便利

最後に、例のリストです。

Gitlab CIを使ってSphinxのドキュメントを自動でPDFにビルドする

Mon, 23 Jan 2017 04:38:35 -0800

gitlab.comは自前でDocker image登録できたり、CI持っていたりと便利ですね。しかも、privateレポジトリもお金かからないという太っ腹。技術書典2に向けたレポジトリはgitlab.comで管理しています。

今回は共著者にPython使いが多いためSphinxを使って書いているんですが、Sphinxはcommon markでも書けるのでmarkdownでも文章を書くことが出来ます。

前回の記事では、数式入りのmarkdownからPDFを生成するDocker imageを作りましたが、それを使うと簡単にGitlab-CIでPDFが生成できます。

やり方は簡単、あなたのSphinxのプロジェクトに、以下のような.gitlab-ci.ymlを書くだけ。もちろん、必要に応じてpathsは変更してください。

image: chezou/sphinx-recommonmark:latest pdf: script: - make latexpdfja artifacts: paths: - build/latex/techbookfest02.pdf only: - master

こうすると、masterにpushしてCIが成功する度に、PDFが生成されてダウンロードできます。

めっちゃ簡単。お試しあれ。

数式入りのmarkdownをSphinxを使ってhtml/pdfにする

Sun, 22 Jan 2017 08:11:24 -0800

Sphinxでmarkdown拡張を扱うためのrecommonmarkというライブラリがあります。これを使うとreSTではなく、markdownを書いてhtmlやPDFが吐けるようになります。

詳細は以下のエントリにやり方がまとまっています。

tech.3rd-p-zombie.net

実は、このrecommonmarkはconfigに設定を書くだけで、数式をmarkdownの中に埋め込めるのでした。

conf.pyの上の方に以下をimportし、

import recommonmark from recommonmark.parser
import CommonMarkParser from recommonmark.transform
import AutoStructify

source_suffixの修正、source_parsersの追加

source_suffix = [".rst", ".md"]
#source_suffix = ".rst"
source_parsers = { ".md" : "recommonmark.parser.CommonMarkParser" }

最後尾に以下を追加します。

def setup(app):
 app.add_config_value(
 "recommonmark_config",
 { "enable_math": True, "enable_inline_math": True, },
 True)
 app.add_transform(AutoStructify)

すると、

$$ (a + b)^2 = a^2 + 2ab + b^2 $$

とかくと、以下の数式の部分のようになります。( )

また、inlineの数式も以下のように書けます。 ( )

This formula `$ y=\sum_{i=1}^n g(x_i) $`

ただ、残念ながら式番号を出す方法はわかりませんでした。

[追記]

数式番号ですが、conf.py に math_number_all = True を入れるとどうなりますか https://t.co/tH2ouf7Hk6
— shirou - しろう (@r_rudi) January 22, 2017

conf.pyにmath_number_all = Trueを足せば数式がでました。ですが、参照はできないと思うので参照が必要な場合はreSTで書く必要があると思います。

math_number_all=True

[/追記]

$ make latexpdfja

とすれば、PDFが、

$ make html

とすればhtmlが生成されます。

さくっと書くときにはmarkdownで行けるのはありがたいですね。

Sphinxとlatex環境を用意するのが面倒な人向けに、docker imageも作りましたので活用してみてください。

参考

macのJIS配列のキーボードをKarabiner使わずにUS配列にする

Thu, 19 Jan 2017 14:17:07 -0800

macOS Sierraに上げる前に、Karabinerが動かない問題をなんとかしたいと思っていました。 El capitanでちゃんと検証してから上げないと、色んな人みたいに死ぬなと思ってに移行できるか検証しました。

今回の要件

JIS配列の本体のキーボードをUS配列で使いたい
外付けのUS配列のキーボードで右cmd単体でかな（IME ON）、左cmd単体で英数（IME OFF）として使いたい

とくに、1.についての情報がみつからなかったので、実際に試してみた。

Karabiner-ElementsでUS配列にする

最近のKarabiner-ElementsはGUIがついているので、かなり楽ちんで、設定項目は2つ。

1つ目は"Virtual Keyboard"のKeyboard Type: ANSIを設定すること。これで大体USキーボードの配列になります。

2つ目の設定は、“Simple Modifications"でinternational3をgrave_accent_and_tildeに変えれば行けた。これでかつる！KarabinerのJIS->USと揃えるにはinternational1も同様に割り当てれば良さそう。

ちなみに、検証はAnkerのBTキーボードで試しました。安いUSキーボードとしてはそこそこ使えます。

出版社/メーカー: Anker
メディア: エレクトロニクス

cmd->英数,かな

これは、使えば大丈夫。

しばらくこれで試してみようと思います。問題なければSierraにあげてみます。

サイバー攻撃としてのフェイクニュース

Sun, 15 Jan 2017 21:55:32 -0800

このポストは、最近もやもやっと思っていることを吐き出したポエムである。厳格なファクトチェックを経たものと期待しないで欲しい。

tl;dr

サイバー攻撃としてプロパガンダをばらまくことを行うハッカーグループがいる
彼らはfake newsサイトをいくつも作って選挙等に介入している
不正アクセスして得た結果を、自分たちに有利な情報をフィルターしてWikileaksに流し、ニュースの情報源をコントロールしている

本文

ここ最近、日本でも”fake news”という単語を聞くようになってきた。僕が聞いたのは、rebuild.fmでその単語が出てきたときだったが、何故出演者がFacebookも引き合いに出して、怒りを感じているのかがわからなかったので少し調べてみた。もちろん、足りない視点などあるとは思うので、見つけたらこっそり教えて欲しい。

日本語でフェイクニュースや偽ニュースと言うと、虚構新聞のことか、とかマスメディアが嘘ついてるんでしょ、みたいなイメージがパッと思い浮かぶかもしれない。（ちなみに、DMM英会話で話をしているセルビアの人にも話を振ったら「ニュースは総じてfake newsである」みたいなことを言っていたので、そういう人は一定数いるのだとは思う）つい最近、NHKのニュースでBBCがフェイクニュースを検証するという記事が流れたが、ファクトチェックをするのは良いことだ、という程度のはてブを見ても反応しか見受けられなかった。

確かに、アメリカの大統領選ではテレビ討論でもファクトチェックをリアルタイムでするなど、事実確認にはかなり厳格に行っているように見える。

しかし、なぜ今更ファクトチェックの話をBBCが言うのだろうか？なぜ、fake newsが問題視されているのだろうか？確かに、ニュースとしてアメリカの選挙にロシアがfake newsを通じて干渉していた、という話は聞くがどのようなことが問題なのだろうか。ロシアのアメリカ大統領選への干渉は以下のコラムがわかりやすくまとまっているので、ご存じない方は一読すると良いだろう。

プロパガンダを攻撃とするハッカーグループ

実は、ドイツもロシアからのfake newsを中心とした攻撃に頭を抱えている。

このSecurity Affairsの記事によると、ドイツの外交情報機関（BND、連邦情報局）のブルーノ・カール長官はこう言っている。

「（国民の間に）『政治不信の感情を作り出すことだけを目的として行われるサイバー攻撃』の存在も報告されている。これらは公の発言に対する、そして民主主義に対する一種の圧力であり、受け入れられないものだ」とカール長官は『南ドイツ新聞』に語った。

いわゆる、プロパガンダというものは第二次世界大戦のときの新聞などを使った情報統制などをイメージしていた。しかし、現代においてfake newsを他国を攻撃するための武器として使われているのである。

記事によると、これらはAPT28というロシアのハッカーグループが中心となって行なっているというのである。政治的なダメージを与えるために機密文書を盗み、それをばらまくというのである。（この「ばらまく」というのにも問題があるがそれは後ほど説明する）本文中ではドイツがロシア政府は直接指示している証拠はつかめていないが、容認している根拠は示せると言っている。つまり、プロパガンダを中心とした政治への干渉を目的としたハッカーグループが存在しているということである。

は新しい戦場となりつつある。BfVは「（心理戦による軍事行動）の一環として行われるプロパガンダ活動」の急増を観察しており、また「ドイツの政党、および議会を標的としたフィッシング攻撃」の数が跳ね上がっていることを指摘した。

という指摘もあり、ただの経済的なダメージを与えるフィッシング攻撃やDDoS、クラッキングといった攻撃から、国に対しての攻撃を目的とした攻撃に切り替わっていることが伺える。

ソーシャルメディアとfake newsの親和性

特にここで指摘されている「ソーシャルメディア」というのが厄介で、何故”Fakebook”などという指摘を受けているのか。

ニューズウィークジャパンの記事によると、

一連の嘘のニュースは米国の主要ニュース・サイトに掲載されたニュースよりもフェイスブックでのシェア数が多かったという調査結果が出ています。

米国のニュースサイトよりもFacebookの影響が大きかったことが指摘されている。

また、東洋経済の記事によれば、

ロシア政府はまた、クリントンに関する捏造された「ウソの情報」を拡散した。たとえば、同氏が「パーキンソン病を患っているという事実を隠している」、あるいは、「ローマ法王がトランプ支持を公言した」など、事実とは異なる情報を、フェイスブックやツイッターなどSNSを通じて広く拡散した。

とあり、SNSを通じた嘘の情報を流しているという話である。これだけを見ると、「こんなデマに自分は騙されない」と思ってしまうかもしれない。（少なくとも自分は最初に聞いた時にそう思った）

しかし、Facebookを通じたニュースには別の問題も指摘されている。Tech CrunchはFacebookのInstant Articlesの二次効果について指摘している。Instant Articleは

But the hidden, second-order effect was that publishers had their identities sterilized. Instead of people reading on their websites with their custom branding, unique visual style and heavy promotion of their other stories, the Facebook-hosted Instant Articles from different outlets looked largely identical.
（筆者抄訳）
しかし、隠された2次効果は、出版社がアイデンティティを無菌化したということだった。出版社のカスタムブランド、ユニークなビジュアルスタイル、そして他の関連ストーリーの重い宣伝が付いたウェブサイトの代わりに、FacebookがホストしているInstant Articlesは様々な出版社の記事がそっくりな見た目になった。

Instant Articlesの例（画像は[公式blog](https://media.fb.com/2016/04/12/instant-articles-now-open/)から）

Instant Articlesの例（画像はから）

確かに、一番左の画像を見てもらうとわかるが、情報源がどこかがわかりにくい。右二つの開いたあとの記事も、ロゴなどはできるだけ少なくなるようになっている。Facebookのアプリからニュースを見る比率が高くなると、ソースを意識的に気にしないと、どこのニュースか見失ってしまいやすいのも頷ける。

対象的に、Googleも似たような目的で検索結果から高速に記事を見ることができるAMPでは、配信元が大きく出るようになっており、比較的誤解はしづらいデザインとなっているようにうつる。

GoogleのAMPの例（画像は[公式ブログ](https://japan.googleblog.com/2016/02/blog-post_25.html)から）

GoogleのAMPの例（画像はから）

加えて、FacebookなどのSNSを通じたニュースを、何度も同じタイトルを見るうちに自分の頭のなかに刷り込まれて、興味を持って開いてしまうという経験はないだろうか。僕自身は複数回見たら「そろそろ読むかな」という気になることが多い。一度見たものや聞いた音楽は、二回目以降に出会うと親近感が湧くのと似ているかもしれない。

ソーシャルメディアからの記事を読むことは避けるのは難しいし、そこに紛れてるfake newsを避けるのは困難だ。信頼のおける友人がシェアしていたり、意見を表明して議論が盛り上がっていると、あたかもその記事の内容は（間違っていたとしても）真実かのように思えてくるときがある。

昔はSNSを通じたニュースを見るときも、大学の先生だからロジカルに裏取りしているだろうとか考えていた時期もあった。が、結局3.11の後にわかったのは、専門外の話は話半分で聞かないといけない、権威などというものはあてにはできないということだと思っている。

プロパガンダに利用されるWikiLeaks

では、Facebookのニュースの供給源である、新聞などのメディアはどうだろうか。先程の東洋経済の記事によると、

ロシアが民主党だけでなく、共和党のメールシステムもハッキングしていたとCIAが報告したことだ。つまり、ロシアはウィキリークスを使って民主党のメールを拡散したものの、共和党のメールは拡散しなかったということ。

とあり、スノーデン事件のときのように、大きな国家の不正を暴く存在という印象づけられていたWikiLeaksが、今度はリークする情報をコントロールすることで他国を攻撃するツールになっているのである。ジャーナリストがメディア側も些細な事だからと論旨が覆る話をサラリと流したりすることもあるため、バイアスが係ることは否めない。正しさハラスメント問題を使われた時にも受けてがなんとかしないといけないとは思っていたが、それ以前に情報源が操作されていたり印象が操作されているということが起こりうる時代なのである。

だからといって、すべての記事にファクトチェックをしていられるほど人生は無限にはない。情報ができる速度のほうが人がファクトチェックする速度より速いのだ。だから、冒頭の記事のようにBBCがファクトチェックを行うと宣言したのであり、のである。Facebookもしている。

ソフトウェアエンジニアとしてできることは？

しかし、人手では限界があるだろう。をしていたりもするが、残念ながら多くの人が本当と思わされてしまったことを全自動でfakeやプロパガンダと判定するのは、WELQのようにクラウドソースされた怪しい記事を、Googleは残念ながら自動で弾くことはできなかったように、まだ難しいと個人的には思う。

や、のように、fake newsはまぬけな対岸の火事ではなく、サイバー攻撃として仕組まれているものの一つであるという可能性を疑って見たほうが良いと、一エンジニアとして思う。

ちょっと昔だと、陰謀論乙、と思っていたのだが、いかんせんしてから、雲行きが怪しくなってきた。

一エンジニアとして、今後どういう情報による攻撃が起こり得て、それをどうすれば防げるのか、というのは、興味深くもあるが、それを防ぐというのはかなり難しそうな気がしている。おそらく、機械学習やが解決の糸口につながるとは思うが、まだまだギャップは大きいように思う。

「」という言葉が、杞憂で終わるように、できることを考え続けていきたい。選挙期間の選挙に関するネット上の発言は禁止されるという、馬鹿みたいな昔に戻るというディストピアだけは避けたい。

非英語ネイティブにとってのOSSのメンテナンスコスト

Sun, 01 Jan 2017 15:29:31 -0800

disclaimer: この記事を書いている人はClouderaというHadoop/Sparkのディストリビューターの会社にいます。

codelunch.fmの20回目を聞いていろいろ思うところがあったのでつらつら買いてみます。

codelunch.fm

この回のcodelunch.fmでは、前職の同僚である丸山さん（）とさんが、お互いの家庭環境の変化を交えながら個人プロダクトの開発について話しているエピソードです。これ自体なかなかおもしろい回なので、趣味でプロダクト開発している人は聞いてみるといいんじゃないかなと思います。

丸山さんはやを精力的に開発していますし、hokacchaさんはやを作られています。彼らの話していた、個人で趣味プロダクトを開発するモチベーションは何かというところは、以下のようなことが話されていました。

自分が欲しいと思ったものを作りたい
他にも同じ問題で困っている人を自分のプロダクトで助けたい
新しい技術を試したい
あわよくば、自分の作ったプロダクトで有名になりたい（承認欲求を満たしたい）

どれも同じエンジニアとしてはそうだよねという気持ちになります。

そんな丸山さんのESDoc関連の発言を見ていると、アクティブじゃないから他のにマージしろとかなかなか悩ましいなぁと見ていて思います。

ESDocに対する僕のコミットの少なさが、「他ツールとの統合」という話に発展してしまって、何とも言えない気持ちになってた。というissueにv0.5.0のリリースをもってようやく返信した。https://t.co/hy4vlxh017
— Ryo Maruyama (@h13i32maru) December 26, 2016

本質的にはgithubのissueが辛いだけかもしれませんが(丸山さん自身もと言っている)、スターが1000を超える程度の人気のプロダクトは色々な人のアテンションを引くため、言葉を選ばず言うと「乱暴な」issueが立ちやすいのかもしれません。¹ですが、自分もスター19くらいのというbindingも本家に拾われてからいろいろissueが来るようになりました。

OSSを出すパターンとしては、ざっと考えた限りでは以下のようなパターンがあるんじゃないかと考えます。カッコ内はその目的です。

誰も作っていない欲しいものがないから作ってOSS化する（自分をユーザとして満足させる、承認欲求を満たす）
会社で書いていたコードのうち、一部を汎用的に切り出してOSS化する（同じ問題を解いている他の人を楽にする、会社の認知を上げる、転職後もコードを使えるようにする）
会社として、大きいコードを戦略的にOSS化する（他社との差別化、プロダクト自体の認知を広める）

下に行けば行くほど、メンテナンスする人数も増えていくと思います。ここで、OSSのメンテナンスコストという点について考えたいと思います。というのも、個人ですべてOSSとしてメンテしていくときにこういうのをどう処理すればいいのかな、と考えたのがきっかけでした。

うーん、なんだかなぁ。僕にとってはこの話はすごく小さな問題だと思うので、「提案ありがとう。でも対応しません。なぜなら好みじゃないから」というので終わりにしたい。そこをわざわざ議論するのに体力と時間を使いたくない。https://t.co/6RTWifmmEZ
— Ryo Maruyama (@h13i32maru) December 30, 2016

前職のクックパッドに入る前は、OSSに対する考えとしては、ソースコードは公開されており、コントリビュートの機会が開かれている素晴らしいものだと素朴に思っていました。RubyやSolrにお世話になり、自分もC++のコードの小さいbindingを書いたりしていました。

クックパッドに入った後は、社内でも使っているし社外にも使えるものはOSSとして公開しようという流れでOSSを出しているのを見てきました。業務として使うコードを公開することでユーザが増え、コードのクオリティが上がり会社の認知も増えるという効果も得ることができていた様に感じます。ある意味では、その企業が業務としてのOSS活動をサポートしているからできることだとも思います。プロダクトにもよりますが、1人ないしは数人で開発をしているという開発状況になると思います。

Clouderaに入って、HadoopやSparkといった巨大なOSSは一社ではとてもじゃないけれどすべてをこなすことが出来ないものであるという認識になりました。良くも悪くも複数の企業やなどのファウンデーションでメンテすることで、そのコードを長く使えるようにしているものだということを学んだのです。 OSSコミュニティとして他社と共同開発をしながら、一方でビジネスでは競争をしているという形になります。当然、個人や一社で開発するより圧倒的にフルタイムの開発人数は多くなります。

では、継続的に個人の趣味コードをOSSとしてメンテナンスしていく上での、メンテナンスコストはなんでしょうか？

一つの要素としては、先程から書いているように開発リソースの問題です。

開発者の時間は有限ですし、ユーザーが増える速度はコントリビュータが増える速度より速いです。 ESDocに関してはのもさばく負荷が高い理由になるでしょう。コミットしてくれる人を集めたり、issueを消化してくれるメンテナを集めたりしてとして動くのもありかもしれませんが、個人として自由な裁量を持った開発をしたいという人もいるでしょう。こうした中でどのように、増え続けるissueと戦うべきか、というのは難しい問題です。なお、このあたりの話は、Sphinxメンテナのtk0miyaさんの記事とFreeBSDのPort maintainerのjj1bdxさんの記事が興味深かったです。

tk0miya.hatenablog.com qiita.com

もう一つの要素としては、英語に困らない人にはノンネイティブの辛さが想像できない問題というのもあると思います。

自分のボスは、ネイティブと議論するときと英語が得意でないノンネイティブが混ざるときで、話すスピードもそうですが使う語彙を変えて話してくれます。しかし、githubのissueなどpublicな場所ではこうした気を使ってくれる人は（自分の体感としては）珍しく、こちらが気合を入れて英語を読んだり書いたりする必要があります。丸山さんとも昔話しましたが、issueの返信だと「この解釈で本当に良いんだろうか」とウンウンうなるときも少なくなく、スラングに苦しめられる時も多いです。²All Ears Englishでも、「アメリカ人はノンネイティブの英語に慣れていないから、崩れた英語から汲み取ることができない」という話もありましたし、ここは結局ノンネイティブが頑張るしかないのですが、ネイティブにもここらへん認識してもらう方法はないものか、とも思います。

例えるなら、対面で話しができるスムーズさとメールでのみやりとりしかできないときの負荷のギャップが、ネイティブ同士のやりとりとノンネイティブがネイティブとやりとりするギャップに相当するんじゃないかなと思います。

もちろん、PR貰ってコードでやり取りするのはやりやすいですが、GithubでOSS活動をするということはそれだけでは済みません。僕自身も英語で問い合わせメールが来てissueで辛いやり取りをして以来、最近はそういうコストをどうしたら抑えることができるかということを考えています。ユーザーを拡大したければ英語でマーケティングをするのも大事になってきますし、英語圏の開発をしてくれるファンを増やせればもっと楽になるのかもしれませんが…。³

とりとめもなくまとまりもないですが、他の人はどう考えて立ち向かっているのか教えてもらえるとうれしいです。

もしかすると、彼のアピールの仕方が「他より良い」という点で攻めているので面倒なissueが立ちやすい可能性もあります ↩︎
がないと死にそうになります ↩︎
Issue templateやFAQである程度は対処できるとは思いますが決定打にはかけるなとも思います ↩︎

2016年を振り返って

Sat, 31 Dec 2016 08:11:50 -0800

ブルガリアンスクワットをして筋肉痛でプルプルしています。大晦日も元旦もほぼDMM英会話の予定しかありません。

2016年は、世界的にも激動の年でしたが、個人的にも色々な大きなことが起こり激動の時代でした。¹

昨年の振り返りはこちらです。

Cookpad TechConf、DS祭り、CWT2016で発表した

どれも自社イベントですが、今年は外で発表する機会を例年より多くいただきました。来年も、の発表から幕開けです。

転職した

CookpadからClouderaに転職しました。Sales Engineerというロール、初めての外資ということで慣れない事だらけですが、引き続き、機械学習やデータサイエンス周りでの強みを活かしてやらせていただいています。英語は入社してからDMM英会話をほぼ毎日やったら、最低限社内でやりとりをする力と飲みながら英語話す力は得ることが出来たので、意外となんとかなるかもな、と思っているところです。抵抗感が減ったのと、ちょっと気合を入れれば何かしらの英語はアウトプットできると思えるようになり、瞬発力が前よりはついたなと思えたのが良かったです。

instagram.com

良いなぁと思うのが、同僚で40歳を越えたエンジニアが日本にも何人かいて、その人達がエネルギッシュに働き続けているのと一緒に働けることです。40歳を越えたらマネージャーにならなければならないのかな、とかコード書けないのかなという不安が払拭され、さすが外資だなと思った瞬間です。もちろん、腕に覚えがある人だから生き残ってこれているというのはあるとは思いますが、うちのAPACのdirectorも飛行機で世界飛び回りながらいつも新しく書いたコードの話してくれるので、負けていられないと思う気持ちでいっぱいです。

instagram.com

また、転職の流れで同僚からひょんなことからpyspaに誘ってもらいました。温泉にはまだ言ったことがないですが、お世話になってます。

川崎Ruby会議01を主催した

kawasaki.rbが母体となって主催した地域Ruby会議です。コミッターの方々も参戦していただいたのに、良い意味でRuby色の薄いリージョナルだったと思います。

kawasaki.rbも細く長く続いており、参加してたら転職できた人や、参加してたら起業した人、参加してたら無職になったけど仕事が手に入った人(あるいは採用できた人)などコミュニティとして横のつながりができているなと思います。

(ブログエントリとpodcastが)rebuildデビューした

naoyaさんに紹介されて、データエンジニアリングとデータサイエンスの違いの話がrebuildデビューしました。自分で聞いてた時に突如現れた時にはお茶吹きそうになりました。rebuildはに入ると文字起こしや一人語り回も聞けますし、本放送とライブ放送直後の配信と二回聞けてお得感満載です。

本を執筆していた

お誘いいただいて一年くらい執筆活動をしていました。音楽性の違いにより解散してしまったのですが、24月の技術書典で供養したいと思います。

その時の切り出したものがこれらの記事ですが、からも引用されて嬉しかったです。

また、記事を書くに当たってののPythonライブラリをPython3対応する人になっていました。

出張が多かった

昨年までとはうって変わって、今年だけでパロアルト、ラスベガス、シンガポールと年に三回出張で海外に行く機会がありました。研修でUSの様々なところから来たエンジニアや営業とはなしをしたり、APACのチームミーティングでシンガやインド、オーストラリアなど様々な国の人とロールプレイをしたりとハードでしたが、成長も実感できました。ただ、妻が一人で子供を二人面倒を見る期間が出来てしまうので、ワンオペ状態となっていたのは悩ましい限りです。

今年書いたコードなど

小物が多いです。あまりコード書けていないので、来年はもう少しコード書けるといいなと思います。tabula-pyももう少しなんとかしたい。

2017年に向けて

総じて今年は、やることを減らしてできることをやるぞ、というスタンスで来ました。自分のできる範囲内でこなせたんじゃないかと思っています。家族への負荷がもう少し下げられればなと思います。

社内で思ったより色々貢献できることがありそうだぞ、ということが分かってきたので、社内外ともに色々とアウトプットしていきたいと思います。

もう一つ、筋肉を付けて加齢に伴う色々な問題を解消していきたいと思います。

のっけから余談ですが、UKに縁のあるボスが来日中にBrexitの結果を受けて落胆していた様子と、エグゼクティブたちが来日中にトランプの勝利を見てショックを受けているのを見て、波乱の年だったなと思います ↩︎

2016年買ってよかったもの 10選

Fri, 30 Dec 2016 15:27:13 -0800

ハード中心ですが、2016年に買ってよかったものを書いていきます。10選と言いつつ、枝分かれをしているものがありますがご愛嬌ということで。転職をしたこともあり、必要となったものが大きく変わったのですが、今回は自分の生活を楽にしてくれたものを買えたなという気持ちです。

Philips 43型 4kディスプレイ

出版社/メーカー: Philips(フィリップス)
発売日: 2016/04/15
メディア: Personal Computers

このモデルの良い所は、

40インチ超えで7万以下と安い
IPS液晶なので斜めから見る場合でも色の変化が少ない
なので、輝度を落としてもちらつかない

という点が挙げられます。特に、安い10万以下のモデルでフリッカーフリーの液晶はおそらく2016年末の段階でも他にないのではないかと思います。なお、4kで40インチ以上は大きいのではないか？ということが言われますが、PCを繋いで利用するのにはフォントサイズ等を考えると43インチが丁度良いと思います。

1枚で作業領域が4倍になる（視線移動が複数枚より少なくなる）
高解像度の映像も見れる
Netflixなどを家族で見られる
少し離れても度の弱い眼鏡でも見られる

会社のMBPは4k対応で、私物のMBP late 2012は4k対応はしていないのですが、3840×2160の解像度で出力することはできます。

椅子と机についてよく聞かれるのですが、机はIKEAののものを、椅子はバランスボールを使っています。

出版社/メーカー: カワセ(KAWASE)
発売日: 2012/04/05
メディア: スポーツ用品
購入: 17人クリック: 37回

PCを使っている場合、距離としては近いので全体を一目できませんが、それでも視線移動だけで十分広さを活用することができます。特に資料を作るときにパワーポイントを3画面とマインドマップを開けたのは、コンテクストスイッチが減りとても効率が上がりました。

合わせて買ったものとしては、MinDP->DPケーブル、マウス、Bluetoothキーボード、液晶クロス、クリーニング液を買いました。

出版社/メーカー: Rankie
メディア: エレクトロニクス

出版社/メーカー: ロジクール
発売日: 2015/07/16
メディア: Personal Computers

出版社/メーカー: Anker
メディア: エレクトロニクス

広い画面になると普通のメガネ拭きなどではとてもじゃないけれど掃除が大変だったので大きいクロスを買いました。子供がティッシュで吹いてくれて傷がついたりしたのも、簡単に復旧できました。

出版社/メーカー: サンワサプライ
発売日: 2004/03/21
メディア: Personal Computers
購入: 57人クリック: 173回

出版社/メーカー: エレコム
発売日: 2005/10/27
メディア: Personal Computers
購入: 16人クリック: 17回

なお、でも、MBP late 2012ではFull HD以上の解像度が安定して出せなかったので、素直にminiDP->DPのケーブルを利用するのが良いと思います。

もともと持っていたリモコン付きのHDMI切替器と、DAC付きアンプ、パッシブスピーカーを組み合わせて使っています。HDMI切替器があると便利なのは、Chromecastのようにスリープモードがない端末を付けているとモニターが点きっぱなしになってしまうのを防ぐことができます。また、HDMIから音を光デジタル出力で分離できるので、本体のいまいちなスピーカーを使う必要がありません。もちろん、デジタルAVアンプが1台あればそれで十分かと思います。

出版社/メーカー: ティアック
発売日: 2015/08/03
メディア: エレクトロニクス

出版社/メーカー: サンワダイレクト
メディア: エレクトロニクス

Roomba

奥さんへの負荷が下がるし、部屋に物を置かない生活が手に入るので、子持ちの家庭には必須でした。

出版社/メーカー: iRobot (アイロボット)
メディア: その他

ポータブルPCスタンド

出版社/メーカー: Next Step
メディア: エレクトロニクス

外や家で作業をするときに、これを持っていくことでかなり肩こりが減りました。miyagawaさんはじめ多くの人はを愛用しているようですが、こちらの製品でも僕には十分でした。

Shure MV88

出版社/メーカー: SHURE
メディア: エレクトロニクス

rebuildのmiyagawaさんがオススメしていたので買いました。これとiOS端末を持っていくことで、どこでもPodcastの収録や映像の録画ができるようになりました。特にRubyKaigiでmirakuiさんとの収録をできたのはMV88のおかげです。

rubyist.club

deuter グラント

出版社/メーカー: deuter(ドイター)
メディア: スポーツ用品

自転車で出勤することもでき、15インチのMBPが入るものを探していたらこれに到達しました。同僚が使っているノースフェイスのバッグもよかったのですが、腰で止めることができるのが良いです。国内の1泊程度の出張であればこれ1つで十分ですし、海外出張のときの機内持ち込みにも良いです。

毛玉取り器

出版社/メーカー: テスコム(TESCOM)
発売日: 2010/10/20
メディア: ホーム&キッチン
購入: 7人クリック: 10回

妻の希望で買ったのですが、電源がつながるタイプのためパワーが強く驚くほどよく毛玉が取れるそうです。子供の服なんかによく使っています。

Bluetoothオーディオ製品

AnkerのSoundCoreは再生時間が24時間と長く、一週間くらい充電しなくても良いので気に入っています。

出版社/メーカー: Anker
メディア: エレクトロニクス

2個めのAnker SoundBuds Sport IE20はなぜか高い並行輸入しかありませんが、こちらは非常に便利です。とりあえず、外に出る時これで十分と思わせてくれたのは大きいです。音はまぁまぁで、充電の仕方が微妙ではありますが良い製品だと思います。

出版社/メーカー: Anker
メディア: エレクトロニクス

Jabraの片耳タイプのヘッドセットは、外を出歩く時やHangout等のテレカン時に良いです。

出版社/メーカー: Jabra
発売日: 2015/03/06
メディア: エレクトロニクス

dot

EARINのような耳の部分だけのBluetoothヘッドセットです。こちらは充電器が磁石でくっつくようになっており、スタイリッシュで使いやすいです。電池も一回の充電で1時間半くらいは連続再生できるので、長くないrebuildであれば問題なく聞けます。¹ 特性として接続してから聞けるまでに少し時間がかかるのと、音はそこまで良くないのを除けば非常に良い買い物をしたと思います。

箱みかん

出版社/メーカー: YAMATAベジフル.net
メディア: その他
クリック: 1回

今年の冬は、子供が非常にみかんを食べるので箱で買うことにしました。近所のスーパーで箱売りをしている店が見つからなかったのでAmazonで買っていますが、子連れで買うのが厳しいのでかなり助かっています。これのおかげで、冬の風邪によるダウン率が下がっている気がします。

アシックスのセミオーダー中敷きの靴

前職とロールが変わったため、外を出歩くことが増えました。そのため、ビジネスにもカジュアルにも使えそうな靴を探していたのですが、自分の足の形に合う靴がなかなか見つかりませんでした。もちろん、既成靴じゃないものを注文するという方法もあるかとは思いますが、今回はアシックスで足の形を計測し、自分にあった中敷きをしくことで解決しました。歩人館とよばれる直営店で計測をしてくれますが、横に広めで高さが低めの足の自分にとっては、ここのおかげでかなり楽な靴を買うことができました。

いくつか、トレーニンググッズも買ったのですが、来年はこれらをちゃんと使えているよという報告にできればなと思います。

残念ながらbackspace.fmは厳しいです ↩︎

今年読んで面白かった漫画 2016年編

Sun, 25 Dec 2016 13:30:04 -0800

海外出張の移動やKindle Unlimitedとかもあって結構漫画を読む機会が多かったのですが、今年読んだ漫画のオススメを書いていきます。

買っているものと、マンガワンで一気読みしたものとあります。マンガワンはDAUを上げるための施策がよく出来ていて、12時間毎にチケットが4枚回復して4話まで読めるという設計(iOS。Androidは時間制限)はなかなか良く出来ています。4チケット以上持つことができないので、回復時間が来たら読まなきゃ、という気持ちになります。実際このスタイルは結構成功している部類に入っているのか、コミコなどの他のアプリも似た手法を取ってきています。なお、定期的に入れ替えられる「一気読み」がなかなか良く、まぁ10巻以上のものは普通に全部読み終わらないので、追加チケットを買うか別のところで買わざるを得ません。

さて、前置きはこの辺にして本題に入ろうと思います。どちらかと言うとメジャーな作品が多いかとは思います。

マージナル・オペレーション

作者: 芝村裕吏,キムラダイスケ
出版社/メーカー: 講談社
発売日: 2014/01/10
メディア: Kindle版

ラノベ好きゲーム好きニート体質の主人公がやっとの思いで就職した会社が倒産し、民間軍事会社の「内勤」を始める。この内勤というのが曲者で、「グラフィックもしょぼくできの悪い戦略シミュレーションゲームのよう」なものを進めていきます。成績良くこなしていく主人公が見たものは…。ということで、同名の小説を元にした漫画で戦争ものの作品が好きな人は良いと思います。

ブラック・ラグーン

作者: 広江礼威
メディア: Kindle版

Netflixでアニメも見れる作品です。タイの無法者が集まるロアナプラという架空の都市を舞台にした、ガンアクションものです。テイストとしては現代のカウボーイビバップという感じで、あのノリが好きな人は良いと思います。

AIの遺電子

作者: 山田胡瓜
メディア: Kindle版

人間とヒューマノイドが共に暮す近未来社会でのオムニバス作品です。主人公は人工知能の専門医ですが、手塚治虫や星新一を読んでいるような面白さです。人間とヒューマノイドが結婚もできる時代に、それでもロボットは行動が制限されている、みたいな設定の中、様々な人やヒューマノイドが苦悩しながら生きていきます。

かもめ☆チャンス

作者: 玉井雪雄
メディア: Kindle版

自転車漫画です。さえない信金のおじさんがある時自転車に目覚めるという作品です。弱虫ペダルなんかよりは比較的地道に成長していくので、読んでいて親近感がわきます。完結しています。

オメガトライブ / オメガトライブキングダム

作者: 玉井雪雄
メディア: Kindle版

作者: 玉井雪雄
メディア: Kindle版

かもめ☆チャンスの作者の玉井雪雄の作品。主人公がひょんなことから人類が新しい種に進化し、そこから世界を巻き込んだ新しい戦いがはじまります。本作品は、梶秋一や桜一郎など非常に強烈なキャラクターが所狭しと駆け回るのも面白いところです。なお、かもめ☆チャンスで梶も桜もちょっと違う名前で出ています。完結しています。

盾の勇者の成り上がり

作者: 藍屋球
出版社/メーカー: KADOKAWA / メディアファクトリー
発売日: 2014/07/23
メディア: Kindle版

同名のラノベの漫画化作品。異世界転生した主人公が災厄と戦うために与えられた伝説の武器が盾だった…。自分一人では攻撃力がないため、虐げられながら仲間を探しながら旅を続けていく話です。人間周りの駆け引きが多く、異世界に行くけれど地道に努力するタイプの作品です。

中卒労働者から始める高校生活

作者: 佐々木ミノル
出版社/メーカー: 日本文芸社
発売日: 2013/12/06
メディア: Kindle版

家庭の事情で中卒の主人公が働きながら妹と一緒に定時制高校に行く話です。定時制高校だから、様々な年齢や経歴（普通高校を退学したり、若い時代には高校に行けなかったり）を持った生徒が通っていてそこで起こる人間模様が描かれています。

ろんぐらいだぁす！

アニメにもなった自転車漫画です。タイトルの通り、長距離を自転車で走るだけの話ですが、少しずつ乗れるようになって成長していく様が読んでいて楽しいです。のんびりぼーっと読めるので気分転換にはちょうどよいです。なお、読んでいるとどう見ても美少女の中はオッサンにしか見えません。

Landreaall

作者: おがきちか
出版社/メーカー: 一迅社
発売日: 2012/12/07
メディア: Kindle版

剣と魔法との中世ファンタジーものです。最初は辺境の貴族と囚われの姫との恋物語という雰囲気ではじまるのですが、王都の学園に行くに従って様々な国の思惑が絡んできます。ファイアーエムブレムやファイナルファンタジータクティクスのような中世をテーマとしたシミュレーションゲームが好きな人には良いでしょう。もともとはKindle Unlimitedで読み始めたのですが、思った以上に人間模様の描写が面白くのめり込んでしまいました。

スティーブズ

言わずと知れた、スティーブジョブズ、ウォズニアックによるApple創業からのお話。ジョブズの現実歪曲空間やアランケイの東條シーンなど、漫画っぽいアレンジで非常に楽しく表現しています。裏取りをしながらも、伝記を読むよりも話として楽しめるように作られています。

まおゆう魔王勇者「この我のものとなれ、勇者よ」「断る！」

作者: 石田あきら
出版社/メーカー: KADOKAWA / 角川書店
発売日: 2016/08/26
メディア: Kindle版

もともと2ちゃんねるに投稿された小説の漫画版。ようやく完結しました。魔王と勇者が戦わず世界をより良くするよう手を結んだら、という話です。文明の進んでいく様子や他種族混成の軍隊による戦いが展開されるのが面白いです。

シドニアの騎士

作者: 弐瓶勉
出版社/メーカー: 講談社
発売日: 2015/02/23
メディア: Kindle版

アニメにもなった作品。完結しました。宇宙で未知の生命体との戦いを繰り返していくという、王道的なSFものです。rebuildでなおやさんが話題にしていたので覚えている方も多いと思います。宇宙ものが好きな人は是非。

市場クロガネは稼ぎたい

作者: 梧桐柾木
出版社/メーカー: 小学館
発売日: 2013/03/29
メディア: Kindle版

稼ぐことが正義とされる学園で、財閥の御曹司である市場クロガネが一文無しからスタートして稼ぎまくる話。外部のお金が全く使えない世界で、自分の実力だけでチャレンジして稼いでいくという資本主義を凝縮したような学園です。漫画としてデフォルメされていますが、少年誌にしては経済的な要素を盛り込んできていて、インベスターZとは少し違う系統ですが面白いです。

ヴィンランド・サガ

プラネテスの幸村誠の作品。ヴァイキングの時代のアイスランドやノルウェー、イギリスなどの戦いの話。血なまぐさい所も多いですが、結構史実も調べた上で作品を書いているようで幸村先生の遅筆さ丁寧さが際立ちます。少しずつ進んでいますが、緊迫感が続いており面白さは変わりません。

振り返ってみると

振り返ってみると、プラネテスやビバップみたいな宇宙モノや中世の時代物、戦争ものが好きなようです。他にも面白い作品があればどんどん読んでいきたいと思います。

#eigo と私〜あるいは子持ちの業務外活動の続け方

Wed, 21 Dec 2016 05:00:00 -0800

こんにちは、温泉行きたいです。この記事は、の21日目です。1日前は、の保険の話でした。

Clouderaという外資系のHadoop/Sparkを中心としたプラットフォームを提供する会社に今年転職しました。そこで生きていく上で必要な #eigo の話を中心に2016年を振り返ります。

転職した

にも書きました。今ちょうど9ヶ月経ちましたが、まだ首にならずなんとか頑張ってやっています。

シンガポールでAPACのSales Enginnerでのミーティングに行ったら、いろんなアジアの国の英語とディスカッションをして揉まれました。日本のチームは成長中なので、グローバルに比べると相対的に人数も少なく、Doug CuttingやMLlibに詳しいSparkコミッターのSean OwenをはじめとするUSのエンジニアと話す時間が多くあるのがとても楽しいです。

機械学習周りを自分の強みとして、いくつかの発表もさせていただきました。

さらに機械学習の話に加えHadoop/Spark周りの技術やスキル増やしており、考えられることの幅が広がっているのを実感できます。また、会社の新しいプロダクトや大きな変更が3ヶ月毎に起こるので、それを理解し広めるのに終わりがなく、息をつく暇もありません。

全然関係ないのですが、Clouderaに誘ってくれた @shiumachi さんとはIngressのコミュニティ運営で繋がったのですが、人生何が何につながるかわかりませんね。でも、今回の転職で「この人達と働きたい」という想いを重視したのですが、それには間違いがなかったなと思っています。

英語の話

転職のところでも書きましたが、英語はDMM英会話とiKnow!、podcastで継続して学習しています。DMM英会話の話をkawasaki.rbでLTしたらインタビューもしていただきました¹。

eikaiwa.dmm.com

DMM英会話は先生のばらつきがありますが、いろいろな国の多くの先生と話せるのが良いです。フィリピンの先生から自分の好きだった合唱団がなくなってしまった話を聞いたときは感慨深いものがありました。また、ニュースの教材が、VOAからよい感じにピックアップしてくれる²ので気に入っています。 DMM英会話のスケジュールをGoogle カレンダーに登録してるのですが、最近見つけたこのブックマークレットが非常に便利です。

10月はこんな感じです。11月に長らく風邪を引いてしまったので、ちょっとブランク空きましたが、会社からもDMM英会話のお金を出してもらっているので、手を抜くわけにはいきません。

単語については、そろそろiKnow!からvocabulary.comに移行しようかとも悩んでいますが今のところアプリもあるし、効率良くできるのでiKnow!で続けています。iKnow!はPCでやると圧倒的に効率良くできるので家でできるときはそうしていますが、通勤でやることもあります。

最近おすすめのpodcastとしては、All Ears English, GCP Podcastです。GCP Podcastは技術的な話も分かりやすく説明してくれ、スピードもそこそこなので良いです。

www.allearsenglish.com www.gcppodcast.com

英語の学習は筋トレみたいなもので、使わなければ衰えていきます。実際、風邪でダウンしたりしてレッスンをしばらくやらないと、lとrの発音周りで舌が回らずに苦労します。あとは、語彙にしろ表現にしろ、引き出しの多さを増やさないとと思っています。 Duolingoの萩原さんも言うとおり、語学学習は継続してやる人が伸びると言いますし、DMM英会話のような低価格で毎日継続するのが一番得な料金体系³はペースを作りやすいのが良いです。

jp.techcrunch.com

業務で英語を使うようになって、以前に比べて明らかに話せるようになったなぁという実感はあります。例えば、妻の友人のスウェーデン人カップルと2年前に話したときは、片言で会話する感じだったのが今は難なく話せるなという実感を得ています。一方で、英語がほぼネイティブの人同士の手加減のないスピードで議論をしている環境にいくと、まだまだしんどいです。DMM英会話のインタビューのときにお試しでいただいたネイティブ講師のチケットを試した時にも、ネイティブの人の語彙の豊富さと速い言い回しがとても訓練になりましたが、語彙セットが違うのが一番苦労します。

特に、Cloudera World TokyoのJulietの発表の統計や物理、数学用語の訳をして感じたのですが、専門用語の英語の語彙が圧倒的に少ないと感じています。半分英語の学習と称して、を学んでいますが、Quizがバグってる、Hopfield NetworkやRBMは2016年にやる必要があるのかなど色々な障壁と戦いながら続けています。

英語が前よりできるようになって良かったことは、コミッターや同僚との議論が気楽に望めるようになったことに加えて、各国のエンタープライズやスタートアップ系のソフトウェア関係の状況が前よりも見えてくるようになったことです。例えば、ソフトウェアの文脈ではアメリカ全体が凄いというよりはシリコンバレーは特に特殊な環境で天下一武道会みたいな場所である、とか、エンタープライズ系の企業はどの国でも似たような慎重さがあるんだなとか。

一方、英語ができるようになって残念なこともありました。例えば、GitHubで公開した簡単なラッパーに関する質問がメールで飛んできてそれをIssueに誘導したらをりしました。これは、多くの人と接する機会が生まれる反面、出会う人の分散も広くなるので仕方のないことだとは思います。

妻子を持ちながら仕事以外の活動を続けるには

を月一で開催したり、を主催したり、たまにを収録したりしていると、たまに「お子さんがいるのによく時間がとれますね？」と言われる時があります。

確かに、今年は3ヶ月に一回海外出張もしていたので、妻への負荷は上がった面もあります。また、1年位本の執筆に勤しんでいたこともあり、週末に子供を外出させることをサボっていたところもあります。なお、本は諸般の事情により企画がなくなったのですが、レビューいただいたpyspaの面々からはchezou概念本と呼ばれ一部から「まだなの」と定期的にツッコミが続くため、に応募しています⁴。「サークルカットって何？」と妻に聞いたら「カタログに載せるやつじゃん。必要なら作るよ」という心強い環境なので、通ったら技術書典でお会いしましょう。

DMM英会話も原則毎朝やるようにしていますし、週末にCourseraのコースをまとめて取り組んでいたりしますが、リズムを作って継続するということが良かったのかなと思います。こうしたリズムは、執筆活動を継続していたときに通勤時間に書いたり週末に書いたりという時間を作っていたのでできるだろうなという気はしていました。

今年に入ってゲームをすることが圧倒的に減りました。new 3DS LLも買ったんですがなかなか聖戦の系譜が進まない…。情報の収集等も基本はてブのマイホットエントリーとpodcastを聞き流す程度です。以前に比べてあまり勉強会に行かないようにしています。これは、人から執筆するなら勉強会は行かないほうが良いと言われたのもあってです。場を作る側の意義は認識しているのでkawasaki.rbは継続していますが、参加したのは大きなイベントだとRuby Kaigiくらいでしょうか。有り体に言えば、自分の時間は有限なので取捨選択を意識的にするようにはしています。

ただ、そもそも出社時間に融通がきくこと、お客様とのミーティング等がない限り自宅で働くことも許容されている⁵ので、そこが大きく効いていると思います。また、妻が体調崩したときにも子供の面倒を見ながら家で仕事をすることができる環境なので、そこは助かっています。⁶

あとは、できるだけ継続するためのコストを削減することを意識しています。kawasaki.rbは場所はNTT-ATさんのおかげで悩む必要もなく、ペースメーカーとしての読書会があるので手ぶらで参加もできます。DMM英会話もレッスンが終わったら強制的に翌日のレッスンを予約するルールを適用することで、翌日の時間を選ぶだけの問題に帰着させています。

今年一番の買い物

家庭内/業務での業務効率を上げるために、ルンバ870とPHILIPSの43インチの4kモニタを買いました。

出版社/メーカー: iRobot (アイロボット)
メディア: その他

出版社/メーカー: Philips(フィリップス)
発売日: 2016/04/15
メディア: Personal Computers

洗濯乾燥機はもともとあったのですが、ルンバは何故これまで買ってこなかったのかというくらい活躍しています。Amazonのタイムセールさまさまです。後は、食器洗浄機があればいいんですが、賃貸だとなかなかスペース作るのが難しいので悩ましいところです。

ルンバのおかげで部屋が以前より片付くようになったので、PHILIPSの43インチモニタを買いました。これは、おそらく2016年12月段階では7万円前後までの低価格の4kモニタの中では頭一つ抜きん出ています。IPS液晶なので見る角度による色の変化が少ないこと、フリッカーフリーなので輝度を下げてもちらつかないことが挙げられます。4kモニタの生産性は目の視線移動だけで4枚のモニタがあるのと同義になるというところでしょうか。Cloudera World Tokyoでの発表資料を作る際は、社内のスライド2枚とマインドマップを開きながら自分のスライドを書いて効率がかなりあがりました。

また、モニタにChromeCastとAppleTVが繋がっていますが、主にChromeCastが活躍しています。妻が子供にYouTubeを見せたり、Netflixを見せたりしています。 ChromeCastの良いところは、HDMI-CMCに対応しているモニタならYouTubeアプリからキャストを開始すると電源連動で起動するのでキッチンからリビングの操作が可能です。(残念ながらフィリップスのモニタは対応していない) また、スマホの制御とは独立してChromeCastが動くので、ChromeCastでYouTubeを再生しながらキッチンではpodcastを聞くということが可能です。ChromeCastのYouTubeアプリにはキューが存在し、それに見せたい動画をリストに突っ込めば適切な動画のみを見せることができます。キューが枯渇しても関連動画やオススメ動画が出ないので、うっかり子供に見せたく無い動画が出てくるのを防げます。

当たり前の話ではありますが、業務や家庭内の活動の生産性を上げるための投資は惜しんではいけないなと思います。

子どもと #eigo

子供がNetflixのエルモズワールドという番組を気に入ったおかげで、今ではYouTubeにあるセサミストリートシリーズ(Sesame Studios)を見ているようです。

ちょっと前にピコ太郎さんのPPAPのエルモとクッキーモンスター版のが出ましたが、これ以外にも実はアメリカで有名な俳優さんやアーティストとコラボをしていたりします。ロードオブザリングのガンダルフにクッキーモンスターが"resist"という単語の意味を学んだり、スターウォーズパロディをしたり、ワンダイレクションとコラボしたり。

横で聞いていると、自分の語彙力が小学生以下なんだなと改めて気づかされます。

まとめに変えて

今年は新たな人たちとつながることができたのが特に大きな年だったなと思います。これだけ色々とやっていけるのは、妻のおかげだなぁと思っています。本当に感謝しております。来年は今より子供を外に連れ出したいなぁ。

明日は@mopemopeさんです。

英会話未経験とはテクニカルタームですね :) ↩︎
など、日本人に合いそうな記事がわりと多い ↩︎
1日1回25分で4950円で、レッスンは翌日持ち越しができない ↩︎
↩︎
社内ミーティングもビデオ通話でも大丈夫 ↩︎
夫婦で体調崩したりしたときのリカバリー方法をいい方法を見つけたいです。まだ、ファミサポなどは試していません。 ↩︎

iPhone 6sのバッテリー交換には電話サポート+エクスプレス交換がオススメ

Sat, 17 Dec 2016 11:05:14 -0800

噂のiPhone 6sのバッテリー交換に当選しました。症状としては、突然電源断が起こるというもので、ちょいちょい突如落ちる現象には悩まされていました。

当選確認は、以下のサイトでシリアル番号をいれることで確認できます。

当選したら、以下のサイトから「修理サービスを申し込む」で進めていきます。

で、ここからが本題ですが、特に東京近辺の人たちは、カジュアルにアップルストアに行けるため、すぐに終わるため店舗に行って修理交換をすることが多いと思います。ですが、今回は一斉にバッテリー交換が発生したため、バッテリーの店舗在庫が切れていたり、代替となるiPhone6sの在庫も切れているという状況になっていたそうです。

今回は、店舗ですぐ交換できないという情報を同僚などから聞いていたため、試しに電話サポートを受けて見ることにしました。というのも、電話サポートならその時々のおおよその在庫状況を把握していることが期待でき、最短の選択肢を提示してくれると考えたからです。

「今すぐアドバイザーと話がしたい」を選ぶと、30秒後に電話がかかってきてトントン拍子に話が進んでいきました。「rebuildでアメリカ人は何でも電話で解決したがる」ということを言っていましたが、やはり音声情報でやりとりするのは密度が高いためスピーディーに解決しました。先方も数をこなしていたため、的確なポイントを聞いていただけましたし、予想通り店舗は在庫が切れているため1,2週間かかり、かつ複数回店舗に行かなければならないということを教えていただきました。

また、音声でやりとりしているため必要な時のみ「iPhoneを探す」をオフにするなど、合理的なタイミングで必要最小限の作業をするのですみました。おそらく、チャットサポートだとやりとりが倍になっていたのではないかな、と想像します。

最終的には、という、ヤマトの宅急便で新しいiPhoneと交換してくれる方法を教えてもらい、そのまま電話で手続きが完了しました。

エクスプレス交換は家で受け取りをしなければならないという手間はかかりますが、受け取り即発送となるので受け取ることができれば復元するだけです。また、通常の宅急便と同様に再配達のお願いもできるし、原則的に追加のお金がかかるわけではないので店舗に複数回行く必要もなく良かったです。

**[12/18追記]**エクスプレス交換はAppleCare+加入だと無償で使え、そうで無い場合は3000円程度かかるそうです。地方などでAppleCareに入っておらずリコールにお金かかるとすると、かなり酷いですね…。また、クレジットカードで7万円程度のお金が保証金として引き落とされ、後日返却されます。 thx @tsuboi !

iPhone 6sのバッテリ問題で本体交換すべくブログを見てAppleに電話。Appleによると、Express交換はApplecareなしだとオプション料金3000円。また、クレカ必須で本体代が一時課金される。

— S.TSUBOI (@tsuboi)

[/追記]

結果として、月曜に手続きをして金曜に交換完了するという5日で済んでしまったので、とても満足しています。また、はじめてアップルの電話サポートを受けましたが、他の日本のメーカーのようなたらい回しや待たされる体験もなく、やりとりも無駄にへりくだることもなく非常に気持ちが良かったです。

交換時には、SIMも抜いて保護フィルムもカバーも外さなければいけないので、フィルムは買い直しました。

出版社/メーカー: OAproda
メディア: エレクトロニクス

当選したけどまだ交換していないという人は、お試しあれ。

Rubyで深層学習を使った音声合成Amazon Pollyを使ってWebサイトの読み上げ音声合成してみた

Thu, 01 Dec 2016 15:10:05 -0800

今日のre:InventでDeep Learningを使った音声合成サービスのAmazon Pollyが発表されました。正直、DLを使ったの音声合成が話題になったのなんて今年に入ってからだと思っていたのに、もう商用化したんか！という気持ちでいっぱいです。

[2016/12/02追記]

PollyがDLベースという話はに、“Polly is an Amazon AI service that uses advanced deep learning technologies to synthesize speech that sounds like a human voice. “と書かれていますが、DNNを一部のモジュールとして使っている波形接続型じゃないの？とのことです。なので、「DLを使った」という表現に修正しました。

Amazon Polly sounds like concatenative TTS, neither parametric nor WaveNet. I can hear concatenation glitches in its samples.
— Heiga Zen (全炳河) (@heiga_zen) December 1, 2016

多分DNNをどこかのモジュールで使ってる単位選択型です。Appleもそうだったりします。
— Heiga Zen (全炳河) (@heiga_zen) December 2, 2016

なので、のように音声を直接生成しているわけではなさそうです。

[/追記]

Amazon Pollyはのサービスとして展開していますが、画像認識(Amazon Rekognition)、音声合成(Amazon Polly)、音声認識と自然言語理解という対話用のコンポーネント(Amazon Lex)が使えるようになりました。画像認識についてはGoogleのVision APIで話題になりましたが、その他の2つはちょっと変わっていると思いますがこれはおそらくSiriのような対話エージェントであるのバックエンドを切り売りしているんだと思います。

Pollyが凄いのは、AWS CLIで簡単に音声合成がされるということです。しかも、お値段は月500万字までは無料で、その後も$0.000004/文字と非常に安く、本一冊で$2.4くらいという驚異的な安さです。なので、ちょっと前にrebuild.fmでスクリプト書くだけで音声合成でpodcastできるんじゃないみたいな話題がありましたが、。

AWS CLIを使ったbashのサンプルコードはこんな感じです。かんたんでしょ？

$ aws polly synthesize-speech \
 --output-format mp3 --voice-id Joanna \
 --text "Hello my name is Joanna." \
 joanna.mp3

また、サポートしている言語数も2016/12/01現在で、ヨーロッパ言語を中心に以下の24言語をサポートしています。

アイスランド語
イタリア語
ウェールズ語
オランダ語
スウェーデン語
スペイン語 (カスティリヤ)
スペイン語 (米国)
デンマーク語
トルコ語
ドイツ語
ノルウェー語
フランス語
フランス語 (カナダ)
ポルトガル語
ポルトガル語 (ブラジル)
ポーランド語
ルーマニア語
ロシア語
日本語
英語 (インド)
英語 (ウェールズ)
英語 (オーストラリア)
英語 (米国)
英語 (英国)

日本語も聞いていて結構自然に聞こえており、ちょいちょい単語の認識に失敗するときは変なアクセントになりますが、レキシコンで単語を登録すれば自分で改善もできそうです。サンプル音声はこんな感じです。

chezou.tumblr.com

[2016/12/02追記] Google翻訳に手伝ってもらって。それの生成した音声も貼っておきます。

soundcloud.com

[/追記]

で、Mediumなんかの記事の中に面白い記事をよく見るのですが、英文だとなかなか途中で挫折するので、音声にすれば聞くんじゃないかと思い、記事を音声に変換するコードをRubyで書いてみました。以下にコードがあります。

gist.github.com

ポイントとしては、幾つか重要な制約があります。

API一回あたりの文字数が1500字¹（なので、catでmp3を結合している）
長い音声は、5分以降が切り捨てられる

詳細は以下を参考にしてください。docs.aws.amazon.com

実際には、ちょうどHckr newsで見つけた以下の記事の音声を聞いてみました。意外と聞けます。

もうちょっと頑張ってRSSを取得すれば、特定のサイトの最新の記事の音声を生成して、Dropboxに保存した音声をモバイルから再生するということもできそうですね。

正直、安くて多言語でそれなりに自然で何よりAPIが使いやすいということで、既存の日本の音声合成を頑張ってきた企業は大変だなぁという気持ちになりますが、いろいろな使い方ができそうで楽しみです。

厳密には、“1500 billed characters (3000 total characters)“と書いてあるけど"billed characters"がわからない ↩︎

icloudのカレンダーに来るイベントスパムを避けるための設定変更

Sat, 26 Nov 2016 05:17:55 -0800

最近、めちゃくちゃicloudのカレンダーにレイバンのスパムが来るようになってうざいので、通知されないように回避するためのicloudの設定方法を書いておく。

1. PCのブラウザでiCloud.com へ行きカレンダーを開く

2. 左下の歯車から環境設定を開く

3. 「詳細設定」の「イベント参加依頼の受信方法」の設定を「xxxx@yyyy.comへメールを送信」にする

この設定にすると、設定したメールアドレスに通知が来るのでメールを削除するだけになる。

補足

追加された予定を通知しないように削除するには、icloudに新規カレンダーを追加してそちらに移動してから、カレンダーごと削除すると招待した輩に通知をすることなく消せる

参考サイト

Cloudera World Tokyo 2016で機械学習プロダクトの作り方を話しました #cwt2016

Mon, 14 Nov 2016 15:05:21 -0800

さる11/8に、自社の主催するで、機械学習プロダクトの作り方について話をしました。

図: Hadoopの生みの親 Doug ( )と握力王新沼さん ( ) の対談イベントの様子

from

データの民主化の話、データサイエンティストとデータエンジニアの役割分担とチーム構成、機械学習の業務フロー、Cloud Nativeなデータサイエンスといった盛りだくさんの話をしました¹ 。

話の中で特に言いたかったことは2つ、P.16のリスクを取ってくれる責任者を捕まえようという話と、P.29の機械学習込みのプロダクトは改善をし続けないと死ぬという話です。あとは、できるだけ機械学習をしないで、サンクコストが生まれる開始前に撤退ラインを決めておこうということも言いました。

個人的には、今回 Cloudera のエンジニアリングチームと共にしているJuliet( )の話や、さんの話も、自分からお願いをしたのですがお互い相補的な話でとても良かったと思います。

from

特にtokorotenさんの話は、データ分析チームのアンチパターンが並んでいます。どれも耳が痛い話です。また、A/Bテストから機械学習にアップリフトモデリングを通じてどうつなげていくかという話もとても面白いです。

3人の話を総合すると、データサイエンティストとデータエンジニアという区分では、こういった人たちが求められているのかなと思っています。

ビジネスの意思決定をデータから支援する人
プロダクトの改善を予測モデル含めてデータドリブンで行う人
データ基盤を作るデータエンジニア

Cloud Native な話

Cloud Nativeのデータサイエンスの話は、時間の関係でちょっと話足りなかったのですが、同僚のの話を見ていただけると良いと思います。

from

機械学習やデータ分析の文脈で言うと、今までImpalaとかHive on SparkとかはHadoopクラスタを持っている人の持ち物というイメージしかなかったんですが、昨今S3を始めとしたオブジェクトストレージに置かれたデータを直接処理できるようになったのが大きな変化だと思っています。

特に、HiveやImpalaのテーブルさえ作っておけば、S3に直接SQLを投げられるようになったというのは大きな変化かなと思います。を使うと、一時的なクラスタを上げ下げ増減が簡単にできて、永続化層をS3にするだけという感じになります。そうすることで、必要なときに必要な量のクラスタを立ち上げて対話的に分析をし、ワークロード決まったらバッチ用に組み替える、なんてことも容易になってきます。

少しずつではありますが、RedshiftやBigQueryに対する第3の選択肢になってくることを期待しています。

思い返してみると、この手のあるある…辛い…って話MLCTでよくやっていたのであった ↩︎

homebrewを移動してiRubyが壊れたときに見直すポイント

Fri, 28 Oct 2016 21:50:25 -0700

kawasaki.rb #041 で得た知見です。

/opt 以下から /usr/local 以下にhomebrewの場所を戻しました。理由はhomebrew caskが/optから/usr/localに移ったためなんですが、これに伴いrbenvで入れたirubyがopensslを/opt以下から探すようになってしまったため、壊れてしまいました。

いつもはjupyterでパーフェクトRubyの読み会をやっていたんですが、この日はこれを解決するのが間に合いませんでした。

で、このときにどうしたかというと、以下の記事に従って解決しました。

iruby register –force
jupyter kernelspec install
iruby notebook

これで大丈夫です。
実際には、僕は iruby register --force をやって、それを /.ipython/kernels/ruby/kernel.json にコピーしました。

困ったところとしては、ipythonからjupyterに名前が変わったので ~/.jupyter 以下に何かおけばいいだろうと思って色々こねこねしてたんですが、結局大事なのは ~/.ipython が重要でした。 jupyter --paths をやると ~/.jupyter しかでてこないので騙されてしまいました。気をつけてください。

RNNLMベースの形態素解析器 JUMAN++ をhomebrewでインストールできるようにした

Sat, 15 Oct 2016 09:20:47 -0700

京大の黒橋・河原研から最近出たをmacOSのhomebrewでinstallできるようにしました。

JUMAN++はRNNLMというディープラーニングベースの言語モデルを使っています。こちらの記事を読んで知ったという方も多いのではないでしょうか。

インストール方法は、現段階では後述する理由のためhomebrew-coreにはまだ入っていないので、tapを使ってください。

[2016/10/23追記] やっと本家homebrewに入ったので、tapは要らなくなりました。 [/追記]

$ brew install jumanpp

github

JUMAN++のサイト凄い

JUMAN++のサイトには解析を試せるWebアプリケーションがあるのですが、それがなかなか面白いです。

この「どうも、julialang界の頑固おじさんです」というフレーズを解析した結果がです。

こういうラティスを出力してくれます。

楽しい

JUMAN++とMeCabどっちがいいの？

冒頭のQiitaの記事に対してはRNNLMベースだからというよりは、辞書の改善によるものなのでは？という話はMeCab作者の工藤さんからも指摘があります。

これってほとんど辞書による改善だと思う...https://t.co/NnbXreOR48
— Taku Kudo (@taku910) October 13, 2016

さんが精力的に更新をしているとの比較をしているため、MeCab側としては現在普通に入手可能なMeCabの辞書としては最も良いものを使っていると思います。なので、neologd以前に良く問題とされていた「最近の用語が入っていない」という部分に関しては議論の対象にはなっていませんね。

表記ゆれや長音記号のハンドリングに関してはことです。 JUMANの頃からWikipediaを使った語彙獲得やオノマトペの処理など、未知語獲得を黒橋研として頑張っている印象がありました。

また、部分アノテーションか辞書かという話に関しては、以前から議論が分かれている所です。

JUMAN++(の前のJUMAN)とMeCabの比較は以下が詳しいのですが、使っている文法が違ったりなど癖が違うので注意が必要です。

個人的にはneologdが頻繁に辞書を更新してリリースし続けている状況に対して、JUMAN++の側がどれだけの頻度で更新されたモデルが出せるというところが実用的な差になるのではないでしょうか。普通のエンジニアが部分アノテーションのためのコーパスを作り続けるのは、正直かなり厳しいと思います。¹ でも、4万5千文を再学習することで性能がMeCabを越えたと言っています。

現段階では、実際に比較をしてみてどちらが用途に合うのかを判断するのが良いと思います。

なお、読み推定がしたい場合はを使うといいと思います :)

homebrew-coreに入っていない理由

この記事を書いている段階では、upstream(v1.01)のMakefileにあるバグのため、makeに-jオプションを付与して並列でビルドすると失敗する問題があります。

このパッチを当てれば大丈夫です。

で、何故これがcoreに入っていないかというと、

特定のワークアラウンドが必要（並列ビルドを抑える ENV.depararelize を使う）な場合は、upstreamのissueを立ててそこへのリンクを貼る必要がある
juman++は2016/10/15現在レポジトリが公開されておらず² 、publicなissueがない
homebrew-coreにはupstreamにマージされないパッチを当てるFormulaは受け入れられない

つまり、 homebrewでビルド時のバグが有り、かつpublicなレポジトリ（正確にはpublicなticketやissueなど）がない という条件下ではcoreに登録することはできないようです。気持ちはわからなくもないけど、すべてGithubにissueがある（あるいは公開MLがある）という前提はちょっと不寛容じゃないかと思います。 Githubで公開されていることしか考えていないんでしょうかね…。

はじめての、新規Formula作成でしたがちょっと疲れました。。。

sugyanさんのアイドルコーパスも好きだから続けられると思っているし、それくらいコーパス作るの大変 ↩︎
じきにとのこと ↩︎

PDFの表をpandasのDataFrameにできる tabula-py 作った

Sun, 11 Sep 2016 15:19:54 -0700

RubyKaigiに参加するとコード書きたいという気持ちが高まって良いのですが、今回はPDFの表を読み込んで pandas の DataFrame に変換できるを作りました。これをもってRubyKaigiの参加報告とさせていただければと思います。

tabula-pyとは

というJavaで書かれたPDFから表を抽出するライブラリをPythonでうすーくラップしたものです。実装を見てもらえばわかると思いますが、本当にsubprocessでJavaのプログラムを叩いて標準出力で受け取るというだけしかやっていません。

もともとは、Rのtabula実装がかなり色々できるのを知ってPythonがないらしいというので作りました。Rの実装はマジでJavaをごりごり書いていて尊敬の念を抱いています。

github.com

使い方

インストールはpipで入ります。

pip install tabula-py

こんな感じで使えます。

from tabula import read\_pdf\_table df = read\_pdf\_table("data.pdf")

詳細はnotebookを見てください。

# RubyKaigiの成果と感想

rubyist.clubでさんをゲストにした
tabula-pyを作った
個人的には、Julianのが一番おもしろかった。事前にまつださんに聞いていたからこそ辿りつけたのであった
daru周りは色々と頑張っているけど、visualization周りをどうするかが肝だろうなと思いながら作者と飲めたので良かった
機械学習の話は個人的には、sklearnのモデルを読み込んでpredictするとかが良いのかなと思っているので、とかとかみたいにinter-languageな方向を強化していくのがいいんじゃないかなと思いながら聞いていた

今後の展望

Py4jを使えばRと同じことができるのは確認ができたのですが、JavaをPythonの上で書かされている感が半端無いので困ったら考えようと思います。

川崎Ruby会議 01を開催しました #kwsk01

Tue, 23 Aug 2016 15:25:47 -0700

さる 8/20 に川崎Ruby会議01を開催しました。

regional.rubykaigi.org

川崎Ruby会議は、の主催する地域Ruby会議です。ちゃんとしたまとめはるびまに出ると思うので、ここでは開催の経緯なんかを簡単に書こうと思います。

なお、発表内容が気になる方はにあるスライドや動画へのリンクを見ると良いと思います。

きっかけは Ruby Kaigi 2015

に参加したところ、に「次のregionalはやらないの」と言われ、基調講演者が決まればありかもと答える
翌日、miyagawaさんと飲んでると話して、「2回以上続くregionalはやっぱり特定の地域コミュニティがやってるね」と言われる
さらに翌朝、帰る直前のに会って「川崎のregionalやるとしたら、基調講演とかしていただけます？」「いいよ」と快諾いただく
次のミートアップで、kawasaki.rbのメンバーに「発表してみたい？やってみたい？」と聞いたら思いの外反応が良かった

というようにトントン拍子でした。

自分としては、やるならいつもの地域コミュニティの皆が話せる場をつくりたい、と思っていたので、これはこれで良かったです。

とにかく楽をする

神奈川の時はペアプロあり、パネルディスカッションありのもりもりだったのですが、今回は「できるだけ楽をする」ということに徹しました。東京Ruby会議11はのでかなり重い感じだったのと対象的に、我々は

手間を掛けない¹
お金をかけない

という方式で行きました。

なので、どうしてもやりたい！という人が現れないかぎりは、「やれたら良いよね」はやらないという方針のもと進めてきました。

当初はサイトロゴもなしで行こうとしていました。スタッフTシャツも皆大好きで行こうとしていました。そしたら、ロゴを作るよと実行委員のの奥さんが言ってくださり、更にはミュートンの可愛さが理解できないためかTシャツもデザインをしていただくという流れになりました。いつもありがとうございます！

正直、この方法はやる気のある人に負荷がかかってしまうというデメリットはあるものの、手を動かす人が一番推進力はあるかなとも思うので、悩ましいところです。

なお、ぺらさんの奥様経由でが届いているので共有させていただきますね。

igaigaさん(@igaiga555)が投稿した写真 - 2016 8月 20 1:46午前 PDT

やってみた感想

コンセプトの「kwskバザー」は、多分なんのこっちゃわからんだろうなぁと思いながら提示しましたが、大江戸Ruby会議の「生活発表会」からヒントを得ました。始めた3年前の当初からPythonの話もあり、ずっと「kawasaki.rbはkawasaki.pyなのでは！？」というご指摘をいただき続けてきたので、いつもどおりやっていれば多様性がでるだろうな、という思いもあり、それを全面に出してみました。

都内だと特定の言語でも人が集まるかもしれませんが、川崎まで来ると遠い人は来ないのとRalisやってる人口も相対的に都内より少ないので、地域に根ざしたテックコミュニティとしてやってきました。なので、C#やScala、はてはサーバーレスアーキテクチャの話が出てきたわけです。

実際にその多様性について、簡単にまとめたリストが以下になります。気になる方は是非スライドや動画で確認してみてください。

Rubyとファミコンの仕様
C#とC++/CLI
Scala
Rubyと思ったら猫動画
Rails
Railsから気がつけばPHPに変わっていたでござる
“Railsエンジニア"はただの枕詞のサーバーレス
Python
Elixer本の宣伝
世界をまたにかける話
Rubyと思ったら数学の話で終わってしまったでござる

作者: Dave Thomas,笹田耕一,鳥井雪
出版社/メーカー: オーム社
発売日: 2016/08/19
メディア: 単行本（ソフトカバー）

また、パーフェクトRubyの読書会も続けているためか、「Ruby初心者です」という方もちょこちょこ来ていただいています。kawasaki.rbがきっかけで今回発表された蓑島さんのように一人エンジニアの環境で独学で業務でコードを書くようになった人、転職した人、Herokuのイベントに登壇した人、Railsを学び始めて起業した人など様々な人がいるのも特徴です。正直、Rubyにとても詳しい人には物足りない側面もあるのかもしれないとは思うのですが、asakusa.rbなどとはまた違った路線で来ているのかなと思っています。「ここに来れば困ったことを質問できる」とか「ここに来れば自分の知見を気軽に発表できる」という場所を続けてきたかいがあって、今回のregionalにつながったのだと思います。

作者: Rubyサポーターズ,すがわらまさのり,寺田玄太郎,三村益隆,近藤宇智朗,橋立友宏,関口亮一
出版社/メーカー: 技術評論社
発売日: 2013/08/10
メディア: 大型本

個人的には、のうち、

効果を検証せよ：実行平均時間の単純比較ではなく統計的検定とか使うといい。有意差がなかったら変更を捨てろ。

がとても印象的でした。普段検定というと限定された時にしか使われないという偏見があったのですが、ソフトウェア開発にも生きてくるというのは目から鱗が落ちました。

発表・参加いただいた皆様、どうもありがとうございました。そして、実行委員の皆様、本当に何もしない実行委員長でしたが全力でサポートいただきありがとうございました。

なお、を開催しますので、興味を持たれた方は是非ご参加ください :)

Tokyuリスペクト ↩︎

「夏真っ盛り！Spark + Python + Data Science祭り」を開催しました＆Ibisを紹介しました #summerDS

Tue, 26 Jul 2016 10:27:38 -0700

2016/07/25に「夏真っ盛り！Spark + Python + Data Science祭り」を開催しました。

connpass.com

今回はClouderaに入って初めてのコミュニティイベントということでしたが、なんと400人を超える応募をいただいてとてもありがたい限りです。会場をご提供いただいたDMM.comラボ様、発表いただいたサイバーエージェントの内藤さん、DMM.comラボの加嵜さん、LTの皆様ありがとうございました。

togetter.com

pandasを大規模データにつなぐIbis

from

Ibisはpandasの作者でもある Wes McKinney( ) の作っているライブラリです。ひとことで言うと、pandasのプログラマブルな処理を大規模データにもできるようにします。大規模データは高速なSQLエンジンにまかせて、pandas likeなDSLでpandasと連携できるようにしており、データがTB以上のデータに対してもSQLを書かずに試行錯誤できます。

なお、日本語の情報はかなり少ないのですが¹ 、こちらのが参考になると思います。もし、Impalaを試すのであればか、を使うとブラウザでポチポチするだけでAWS, GCP, Azureに簡単にImpalaクラスターが立てれるのでおすすめです。Director導入方法はが参考になります。

Ibisの詳細は資料を見ていただければと思いますが、いくつか補足をしたいと思います。

SQLじゃなくてプログラマブルなのは何が嬉しいの？

pandasをお使いの方はわかると思いますが、SQLに比べると試行錯誤がやりやすいと思います。例えば、SQLの途中結果を変数に格納できるので、途中までの処理は共通でそこから先を複数パターン作るというのも同じ変数に格納して、後段のメソッドチェーンを変えれば楽にできるというメリットが有ります。使っている感覚はRailsのActive Recordみたいなイメージです。

Sparkより7倍速いのは嬉しいの？

大事なのは15TBのデータを4.4秒で処理できる² というスピード感です。処理を投げて帰ってくるまでの時間が短いと、思考の中断が減ります。例えば、ビルドやテストに時間がかかってコーヒーをいれにいく、みたいな経験はあるんじゃないかと思います。その断絶がなくなるので、考えを継続できますし、ポッと思いついたことをどんどん試行錯誤できます。

Sparkとの住み分けは？

Ibisは、WesがPythonでend to endでPythonを使って分析をしたいという想いでスタートしています。個人的にはJupyterとともに対話的に試行錯誤をする強力なツールになっていると思います。もともとImpalaとPython/pandasをつなぐものとしてスタートしたのですが、RedshiftやPrestoなども今後対応していきたいということも言及されています。なので、プロトタイピングにJupyterとIbisを使うというのが良いと思います。プロトタイプ後にSparkSQL³ でバッチとして安定化をはかるということもできるでしょう。

もう一つの方向性としては、ように、大規模な機械学習はSpark + MLlibで、絞った後のデータはIbis + scikit-learnでみたいな使い分けは可能だと思います。

サイバーエージェント内藤さん： Amebaにおけるレコメンデーションシステムの紹介

from

Amebaでの協調フィルタリングによるHBaseを使ったリアルタイムレコメンドの話。 Hadoopスタックだとリアルタイム性を出すのにはHBaseを使うのが多いのですが⁴ 、更にClick数を取得してバンディットアルゴリズムも使っているというのは凄いですね。

単純なA/Bテストをするという話はDMM.comラボの加嵜さんもお話されていましたが、バンディットアルゴリズムを組み合わせることで、レコメンド結果が複数のロジックの中でも良い物に動的に改善されていくという仕組みが入っています。僕個人としてはこうした取り組みを聞いたことがなかったので、とても驚きました。

DMM.comラボ加嵜さん：Sparkを活用したレコメンドエンジンのパフォーマンスチューニング＆自動化

from

チューニングの話もインパクトが大きかったですが、jsonで「レシピ」を書けば、自分のサービスのレコメンドモデルができるという話はとても驚きました。これを使えば、レコメンドに詳しくない人でも簡単にサービスに導入できそうです。おそらく、ログフォーマットをきちんと統一して横展開をしているのでしょうね。

LT

horiken4 さん：初めてのSparkでハマったこと

Google Data ProcでSparkを使ったら/tmpにjarが貯まるなど、いろいろハマった話を紹介いただきました。

uryyyyyyyさん：EMR上でPython3系でpysparkする話

qiita.com

EMRにAnacondaをいれてPySparkでモデルを作る話でした。逆質問でJuliaを使ってると答えた人が2人くらいだったとのことで寂しかったです。

suthio さん：Sparkで実装しているレコメンドエンジンの基本的なパフォーマンスチューニングについて

DAGを見よう！という話でした。そして、ポケモンGO仲間を募集しているとのことです。

終わりに

やはり、自社で手を動かして取り組まれているという話は、様々な知見が含まれていてとても楽しかったです。 AmebaのHBaseを使ったリアルタイムレコメンド＋バンディットアルゴリズムという構成や、DMM.comラボさんのレコメンドの「レシピ」を書くだけで新規サービスのレコメンドモデルができるという話は衝撃的でした。

自分がホストしたイベントの中では過去最大の募集人数だったのですが、大盛況のうちに終わりました。ご協力・ご参加いただいた皆様ありがとうございました。今回参加できなかった方もたくさんいらっしゃると思いますので、また次回もこういったイベントをできればと考えています。乞うご期待ください。

しかし、日本でIbisというと某研究会しか出てこないので非常につらい ↩︎
↩︎
こちらもIbisのスコープに入っています ↩︎
リクルートさんも ↩︎

JupyterからSpark clusterを操作できるlivy + sparkmagicを試してみた

Tue, 12 Jul 2016 04:50:00 -0700

Spark Summit 2016でもトークがあったSparkのREST serverであるlivyですが、上のSpark clusterとJupyterをlivyを使って繋げられるようにしたと聞いて、早速試してみました。

Jupyterって何？という方は簡単に言うと、ブラウザで各種言語のREPLが動くものと思ってもらえばいいです。詳細は過去に書いた以下の記事を読んでみてください。

techlife.cookpad.com

livyとは

はSpark clusterをコントロールするためのREST Serverです。 Microsoftはこれとjupyter notebookのを使ってHDInsightとjupyterをつなげるようにしているそうです。

MSの取り組みはSpark Summit 2016のトークがわかりやすいです。

このsparkmagicの構成図がわかりやすいですね。

なぜlivyがいるのか？

Sparkは通常gatewayにつないで処理をするが、ユーザー管理は通常のHadoopと同じ形になります。つまり、localにsparkユーザーみたいなのが必要とかになってちょっと面倒。とはいえ、jupyter server立ててそこのユーザーと同期するというのも面倒くさい。 livyを使えばREST server経由でSparkの処理を行うことが可能になります。

としては以下のとおりです。

複数のSpark job、複数のクライアントから使える長時間動くSparkContextを持てる
cacheしたRDDやDataFramesを複数のジョブやクライアントで共有できる
複数のSparkContextを同時に管理でき、YARN/Mesosで動くクラスターがLivy Serverの代わりにfault toleranceとconcurrencyを実現する
Jobはprecompileされたjarやコードスニペット、Java/Scala client API経由でsubmitされる
Apache Licenseで100% オープンソース

それだけだと僕にはあまり嬉しさがわかりにくかったのですが、手元で管理したJupyterと繋げられるようになるというのが個人的には最大のヒットでした。 Jupyterは、データエンジニアリングや機械学習系の取り組みをメモして共有するのにはとても便利なので、クラスターのSparkがあたかもlocalにあるように操作できるのはとてもありがたいですね。

予め用意するもの

Hadoopクラスター
- 今回はで作ったCDH 5.7を使った。お手軽にSparkクラスターを用意出来て便利
- Cent OS 7で用意
- git, mavenを入れておく
jupyter環境

準備

重要なレポジトリは以下の2つ。

まずはlivyからいれていきます。

Rをインストールする

requirementsに書かれているので一応用意しました。

$ sudo yum install -y epel-release $ sudo yum install -y R

livyをbuildする

$ git clone git@github.com:cloudera/livy.git $ cd livy $ mvn -Dspark.version=1.6.0 -DskipTests clean package

今回試した時はtestがこけたので、-DskipTestsをつけました

livyを起動する

今回はCloudera Manager経由でsparkを入れたので、環境変数をこんな感じでセットします。

$ export SPARK\_HOME=/opt/cloudera/parcels/CDH-5.7.1-1.cdh5.7.1.p0.11/lib/spark $ export HADOOP\_CONF\_DIR=/etc/hadoop/conf

livy.confに以下の1行を追加しないとYARN modeで起動しない

livy.server.session.factory = yarn

ここまでできたら、livy serverを起動します

$ ./bin/livy-server

別のterminalで動作確認をする

$ curl localhost:8998/sessions{"from":0,"total":0,"sessions":[]}

デフォルトで8998番のportが使われるので、必要に応じてportを開けるなりsshでport forwardingしてください。

jupyter側のsparkmagicの準備

にあるとおりにinstallします。

$ pip install sparkmagic $ jupyter nbextension enable --py --sys-prefix widgetsnbextension

wrapper kernelを入れます。pip show sparkmagicのLocation以下で実行します。以下の場合だと /Users/ariga/.virtualenvs/ibis/lib/python3.5/site-packages になります。

$ pip show sparkmagic --- Metadata-Version: 2.0 Name: sparkmagic Version: 0.2.3 Summary: SparkMagic: Spark execution via Livy Home-page: https://github.com/jupyter-incubator/sparkmagic/sparkmagic Author: Jupyter Development Team Author-email: jupyter@googlegroups.org Installer: pip License: BSD 3-clause Location: /Users/ariga/.virtualenvs/ibis/lib/python3.5/site-packages Requires: ipywidgets, pandas, ipython, requests, mock, autovizwidget, numpy, nose, ipykernel, notebook, hdijupyterutils Classifiers: Development Status :: 4 - Beta Environment :: Console Intended Audience :: Science/Research License :: OSI Approved :: BSD License Natural Language :: English Programming Language :: Python :: 2.6 Programming Language :: Python :: 2.7 Programming Language :: Python :: 3.3 Programming Language :: Python :: 3.4 $ cd /Users/ariga/.virtualenvs/ibis/lib/python3.5/site-packages $ jupyter-kernelspec install sparkmagic/kernels/sparkkernel $ jupyter-kernelspec install sparkmagic/kernels/pysparkkernel

~/.sparkmagic/config.jsonををもとに入れます。

jupyter notebookの起動

起動する前に、curlでlocalからlivyに通信できるか確認しましょう。

$ curl YOUR\_HOSTNAME:8998/sessions

jupyter notebookでいつもどおり起動をしてPySparkを選べばOK

notebookの例はこちら

gist.github.com

gistには出てませんが、こんな感じでSparkに対してSQLで処理した結果を簡単にvisualiseできます。sparkmagicすごい！

%%localでlocalのcontextに行ったりするのがまだなれないですが、magic commandの %%sqlで実行した結果をDataFrameで受け取れたりと、いろいろ便利そうです。

参考URL

そのモデル、過学習してるの？未学習なの？と困ったら

Sun, 29 May 2016 14:57:39 -0700

Q: うわっ…ワタシのモデル過学習してる…？

機械学習をしていると、「やったほぼ100％の性能でました！」みたいな話がちょこちょこでて、その度に「あー、はいはい過学習乙」とか「」とかいう話になると思います。

過学習というのは、とても雑に言うと「学習に使ったデータに対してはバッチリ正解できるけど、知らないデータに対しては全然当たらない」というモデルのことを指します。昔センター試験の英語を受けた年に突如出題傾向が変わったのですが、塾でバッチリ対策をしていた人々が「うわー、今年傾向変わって全然解けなかったー。きっと他の人も解けなかったよね」という話をしていたのですが、今思うとこれもある意味過学習ですね。

この辺は、PRMLなんかから伝統的に説明される、回帰モデルに対して高次のモデルをフィットさせていくと、やり過ぎになるよねみたいな話が書いてあります。

作者: C.M.ビショップ,元田浩,栗田多喜夫,樋口知之,松本裕治,村田昇
出版社/メーカー: 丸善出版
発売日: 2012/04/05
メディア: 単行本（ソフトカバー）
購入: 6人クリック: 33回

では、どういう時に過学習が起こるかというと、これもざっくり言うと以下の時に起こります。

データが少ない時
モデル¹ が、問題に対して複雑すぎる時

書いていて表裏一体な気がしましたが、「じゃあこれどうやって気づけばいいの？」ということを思うと思います。その答えが、今度日本語版が出る"Python Machine Learning"に分かりやすく書いてありました。日本語版も6月に出るので楽しみですね！

作者: Sebastian Raschka
出版社/メーカー: Packt Publishing
発売日: 2015/09/23
メディア: Kindle版

作者: Sebastian Raschka,株式会社クイープ,福島真太朗
出版社/メーカー: インプレス
発売日: 2016/06/30
メディア: 単行本（ソフトカバー）

A: learning curveとvalidation curveを見よう

（以降の図は"Python Machine Learning"英語版の本より引用です）

この図は、わりと有名なbias-variance tradeoffの図です。 bias-varianceのトレードオフはを見るとわかりやすいのですが、とても端折って書くとHigh varianceの状態が過学習（overfitting）で、High biasの状態が未学習（underfitting）です。

これだけだと、ナンノコッチャって感じなので言葉で説明すると、横軸をデータサイズとした時に、過学習（High Variance (+ Low bias)）の時は訓練データに対する精度( 図中のtraining accuracy。なお、ここでの精度とは？という話は詳しく言及しないですが、詳しくは参照。個人的には、accuracyでもprecisionでも指標はケースバイケースで良いと思います)がとても高く、検証データに対する精度(図中のvalidation accuracy)は低いです。なお、訓練データは学習に使ったデータ、検証データは元のデータから訓練データを除いておいた検証用のデータと思ってください。

それに対して未学習(High bias (+Low variance))の時は、データサイズを増やしても訓練データと検証データに対する精度が共に低い状況です。²

ポイントとなるのは

desired accuracy、つまり求める精度に対して低すぎないか
訓練データの性能だけ高すぎないか

ということです。

learning curveを描く

では、どうやってこれらの状況に気づけば良いのでしょうか？もう既に少し書いていますが、learning curve（学習曲線）とvalidation curve³ を書けば良いのです。

これは、learning curveの例です。先ほど少し簡単に説明を書いてしまいましたが、横軸をデータサイズとして持っているデータをサンプリングして増やした時に、どのように訓練データと検証データの精度が推移するかを描いたグラフです。幅があるのはCross Validationした際の精度の最大値と最小値です。learning curveを描いた時に、訓練データに対する精度だけ高かった場合は過学習を疑いましょう。（この例は、原著では少し過学習の気があるけど、訓練データと検証データの精度の差が小さいので許容範囲だよね、って書いてあります）対処法としては、データ量を増やすかモデルが複雑すぎるのでもっと簡単なものを使うかのいずれかです。（もちろん、正則化を入れるというのもありです）

また、データサイズを増やしても精度があがらなければ（accuracyが0.3らへんでさまようとか）、未学習と思えばよいでしょう。この場合は、モデルをもっと複雑なものを使うのが良いでしょう。

[追記]なお、ニューラルネットワークのように、SGDを使い何度もepochを繰り返して損失が計算できる場合は、損失を用いてlearning curveを書きます。[/追記]

validation curveを描く

もう一つの方法としては、validation curveを描きます。以下はその例です。

この例は、ロジスティック回帰の正則化項の逆比であるCパラメータを横軸にとっています。右に行けば行くほど正則化項の意味が弱くなり（つまり過学習しやすくなり）、左に行けば行くほど正則化項が強くなり（遊びが強くなりすぎる）ます。

このように、パラメータに対するfitting具合を見るのがvalidation curveです。これを描くことで、適切なパラメータを見つけることができるでしょう。

まとめみたいなもの

以上のように、learning curveやvalidation curveを描くことで、そのモデルが過学習しているか未学習なのかを判別できます。

いろいろ書きましたが、解決方法としては、cross validationするとか、とか色々あります。それについてはさまざまな書籍やブログで記述されていると思うので今回は書きませんでした。

また、この辺の話はPython Machine Learningに丁寧にコードとともに書かれているので、是非発売されたら買うといいと思います。訳の監督もsfchaosさんなので期待が高まりますね！

学習アルゴリズムと読み替えてもOK ↩︎
以前、AI学会の研究会で先生が「それは未学習なのでは？」というツッコミをしていたのが、意外と未学習を気にしないのではという思いに至った端緒です ↩︎
訳語わからない⇨検証曲線と訳しているそうです ↩︎

機械学習の分類の話を損失関数と決定境界を中心に整理してみた

Sun, 08 May 2016 17:06:39 -0700

機械学習の分類の話を、主に決定境界と損失関数の観点から整理してみました。とはいっても、k-NNとか損失関数関係ないのもいます。

最初ははてなブログに書こうとしたのですが、数式を埋め込むのが辛かったのでjupyter notebookにしました。

github.com

[追記]

githubだと日本語を含む数式のレンダーが壊れるので、nbviewerの方がいいかもしれません。

[/追記]

パーセプトロンが見直されたのはなんでだっけ、SVMってどういう位置づけだっけ、というのを確認できればなぁと思っています。多層パーセプトロンまでに至るところの流れがうまく伝わればなぁと思っています。間違いなどがあれば、是非ご指摘いただければ嬉しいです。

本当はcourseraのMachine Learningのコース前の人に届けば嬉しいんですが、きっと修了した人にしか伝わらないかなぁ。もし、まだNgのコース終わっていない人がいたら、感想聞いてみたいです。

データを一箇所に集めることでデータ活用の民主化が進んだ話

Thu, 05 May 2016 15:20:46 -0700

先日、この記事を読んで分析のハードルを下げること大事だよね、というのを思い出したのでつらつらと書いてみようと思います。

qiita.com

内容としては正直タイトル詐欺で、SlackからRDSにクエリ発行できるようにして、各種権限を持っているエンジニアでなくても分析できるようになったよ、という話です。

ここでいう「データ活用の民主化」というのはかっこ良く言ってみたかっただけで、「データ分析を生業にしている人以外もデータを活用してビジネスを進められるようになる」というくらいのニュアンスだと思って下さい。「データ分析」というとアナリストの人がやること、みたいな職務が分かれている環境もあるとは思いますが、そうではない会社（前職）の一例です。

データ活用が広まった流れ

数秒〜数十秒で対話的にクエリが返ってくると、トライアンドエラーが100倍くらいできる
今まで実行計画を気にして避けていたことにガンガン挑戦して、新しいメタデータ達が付与される
エンジニアがSQLに慣れ親しむ¹ と、ノウハウがチームや社内ブログに蓄積される
身近なエンジニアがサポートできるようになり、Webディレクターの人もSQLを覚えてKPIを主体的に考え始める

こういう流れでSQLが社内のエンジニアからWebディレクターの人たちに広まっていきました。また、SQLの苦手意識が減ってきたことで、プロダクトのフェーズに応じて変化するKPIを考える力が、数字が得意ではないWebディレクター² にも身についてきました。

前提

この流れを支える前提としては、

Redshiftに入るデータを整備するいわゆるをしている人³ がいた事
が「データの移動は悪だ！必要なテーブルは言えば集める！」⁴ と一貫して主張し続けて、一箇所でSQL叩けばだいたいなんとかなる（と思える）ようにしてくれていたこと⁵
分析をする人が楽できるようにsshやproxyもなしでみたいなGUIクライアントで直接Redshift叩けるようにしてくれたこと

といった事実があります。 3つめのポイントなんかは、前述のQiitaに書かれていた記事のポイントですよね。

ここでいう「データを一箇所に集める」ということは、分析する人の立場からすると「一箇所でSQL叩けばだいたいなんとかなる」という状況です。もちろん、処理方法はSQLに限った話ではないですが、

分析のために余計なデータ転送のコストをかけない
一定の前処理はなされており、何かしらの統一した方法でデータを処理すればよい

という状況を想定しています。

ここまでお膳立てされて、最初は面倒くさいと思って僕含むRubyに逃げていたエンジニアたちもと言い始めるに至りました。

また、多くのWebディレクターの人たちはRubyなどのスクリプト言語は書けない人がほとんどでしたが、データが一箇所に集まったおかげで「SQLだけ覚えればエンジニアの手を借りること無く色々できる！」と思っていただけたのも良かったのかもしれません。

@mineroaokiさんの思想はこちらのスライドにたっぷり詰まっています。P.12から「一箇所にまとめる」話がありますので、そこだけでも読んでみると良いでしょう。

from

なお、Airbnbはようですが、分析に必要なデータが一箇所にまとまっていると言っても差し支え無いでしょう。

ちなみに

実はもう一つの要素として、インフルエンサーとなるディレクターの人が居たのも事実です。彼女は、今やもしているようですが、昔はSQLができなくてエンジニアに毎回お願いしていたそうです。その当時一緒に組んでいたエンジニア（SQLはめちゃ得意）が、あまりに面倒くさそうに対応するのが嫌でSQLを覚え始めたと聞きました。その後、社内のデータ分析相談チャットで質問しまくったり、青木さんに質問したり、使ったクエリを自分のメモとしてストックすることで、他のディレクターに3,4段はネストするサブクエリ含んだSQLを展開するに至っています。

彼女がSQLを武器にできるようになったのはもう一つ、青木さんの本の助けもあったと聞いています。おそらく、他のWebディレクターの人たちにとっては、同じポジションの人に相談できるのは似たようなところを躓いたりした経験を聞けたりするのが良いのだと思います。

作者: 青木峰郎
出版社/メーカー: SBクリエイティブ
発売日: 2015/06/30
メディア: 単行本

データを一箇所に集めると民主化が進むのか？

もちろん、ただ集めるだけでは進みません。

「一箇所に集める」とはデータ分析をする人のコストを徹底的に下げる、ということに他なりません。データ分析基盤を用意する人にとっては正直面倒なことも多いとは思います。ですが、使ってもらってなんぼのデータ分析基盤は、最大限分析する人にやさしくするのが必須です。自分より苦手意識を持つ人に、「あちらのDBは実行計画気をつけて、こちらのDBはjoinすると辛いから…」みたいな面倒くさいことやってくれると思いますか？

その上で、そうしたデータをどう料理すればいいのかを、まずはエンジニアを中心とした比較的データやSQLに慣れ親しんでいる人がお手本を見せます。もちろん、得られた知見を含む、加工したデータも蓄えていきます。

このときに、社内Wikiやブログではコピペで動く状態のクエリ（コメントもできれば付けて）と結果を添えて共有すると良いでしょう。 SQLが苦手な人でも、「コピペではじめるDAUの分析」みたいなタイトルの記事だったらきっと読んでくれます。

良いツールや本を広めていくのと同じように、「何ができるようになるか」という具体例とともに、少しずつ仲間を増やしていくことが大事です。

データ活用の民主化が進むと

の話でも、「検索セッション」の話が出てきていますが、検索チームなら「検索セッション」を見て仮説を立てて検証するよね、というように、生のデータを見るだけではなく、セッションのような塊で見ることで仮説を立てる、ということがデータに詳しくない人（元のデータやクエリを作った人ではない人）でもできるようになります。

もちろん、Jupyter notebookのようなノートブック系のツールが発展することで、それらが加速することはあると思いますが、本質的に大事なのは「データにどういう切り口を与えて見ればいいのか」ということを、多くの人ができるようになることです。

パソコンやワープロが普及したことで、タイプライター専業の人の職がなくなってしまいましたが、その代わりに何かをしたい人がワープロを道具として新しいことを生み出すことができるようになりました。 SQLやデータも同じで、データ活用の民主化が進むことでドメインに対する知識やパッションを持った人が、道具としてのデータを使って新しいことを生み出すことができるようになると信じています。

この話を他の人にすると「でも、それエンジニアが凄い会社だからできたんでしょ？」と言われるのですが、多分データを一箇所に集めて誰でも分析できるようになった時にどうなるか、というイメージがわかないのがコストを割けない1つの原因なのではないか、と思いこういった記事を書いてみました。もちろん、特にデータエンジニアリングを中心にいくつかの技術的ハードルはあるとは思いますが、チャレンジする価値はあると思います。

前職はRuby大好きな人が多かったため、アプリケーション用のSQLはかけるけどサブクエリやWindow関数バリバリの分析用クエリ書ける人は最初は少なく、手元でRubyで処理することが多かった ↩︎
後に、もともと学校の算数・数学大嫌いだったと笑いながら言っていたのが印象的でした ↩︎
@mineroaokiさんたち ↩︎
実際に、テラバイト規模のデータを移動するのにN時間とかアホみたいなことも世の中にはあったりしますよね ↩︎
もちろん、権限ないと見れないスキーマとかもありましたが ↩︎

転職しました

Wed, 30 Mar 2016 15:32:21 -0700

はじめての転職エントリです。一部の方にはお伝えしましたが、先週からClouderaで働いています。

まとめ

Ruby大好きポエム
プロダクトエンジニアポエム
データ大好きポエム

お前だれよ？

kawasaki.rbやMachine Learning Casual Talks、Julia Tokyoなどのミートアップをやってます。なお、今後もコミュニティ活動は続けていきたいと思います。

Rubyが好きでクックパッドに入った

仕事でまったくRailsを書いていない人だった¹ のに、「Rubyが好きです！Rubyistなら一度は働いてみたいです！NLPと機械学習はやってきたんですが、世の人の役に立つものを作って使ってもらいたいです」とミーハーな気持ちで挑んだのですが、なんとか拾ってもらえて2年8ヶ月働くことができました。

「Rails書いたことないのに採用されて驚いた」と飲んだ時に話したら、同僚のが

「自分がわかるスキル持ってるかどうかだけで判断すると、多様性が失われて硬直するよね」

ということを言っていてなるほどー、と思いました。その考えのおかげで他のエンジニアとは違った成果を出すことができました。

入社して歓迎ランチに迎えに来てくれた赤い髪の人を見て「これが噂のWeb系か…」と思っていたら、青や緑の髪の人がいて² 、最初のうちはめっちゃビビってました。仕事し始めるとそんな彼らは暖かく指導してくれて、修行をさせていただきました。³

前職での仕事を振り返って

同僚はキレッキレ⁴ で誠実な人が多く、特に現場が自分で考えて動いて進めていく人ばかりで、常に「お前はここで何がしたいの？貢献できるの？」というのが問われ続けていた環境でした。

自分が取り組んだ仕事はいくつかあるのですが、副菜提案のレコメンドをしたり、ディレクターと1から有料会員向けのトップページのリニューアルをしたり幅広い事をさせてもらいました。

でも、1社目で培ったSolrの脳内クエリビルダーや、NLP、機械学習の知識を適切に活かせるようになったのは、1年位過ぎてからでした。複雑なアルゴリズムで凄いことをするより、シンプルだけどユーザーの欲求を最短で満たせる方法を選ぶべきということに気づいてから、機械学習は手段であり、それより大事なプロダクトの本質について考えることに時間を割くようになりました。

優秀なエンジニアや情熱あふれるディレクターと仕事をするなかで、プロダクトを作ること、それを通じてユーザーの課題を解決することが好きだということに気づいていきました。いわゆるプロダクトエンジニアっぽい感じでサービス開発をしていると、最先端の技術を使ったりミドルウェアをリリースしてないとダメなんじゃないかという、悩みにぶち当たることもありましたが、彼らとは興味が違うんだなという事に気づいてから楽になりました。

一時期、優秀なエンジニアがいれば何でもできると思ってた時があったのですが、一緒に仕事していたディレクターが、それこそ我々が技術書を買い漁るように、大学の頃からレシピ本を買い続けている、という人で、逆立ちしてもこの人の愛を持ったプロダクトにはかなわん、と思いながら一緒に仕事できたのもまたいい経験でした。

最後1年は、研究開発を加速するべく、データの学術公開やアカデミアとのリレーションシップの構築にも携わらせていただきました。特に、データ公開やハッカソンのおかげで、それまでバイトでRails書いてました！みたいな、プロの新卒がほとんどだったところに、データ系の能力を持った学生への門戸を開けたのは良かったと思っています。

あとは、終盤はのエバンジェリスト業を社内で勝手にやっていました。クックパッドに不本意ながらPythonを広めたのはワタシです。

振り返ると、機械学習がある程度わかり、Railsも書けて、プロダクトを作ることが好きというちょっと面白いエンジニアになっていました。バランス感覚を持ったジェネラリストになれればいいなと思っています。

転職のきっかけ

段々と「Rubyで仕事をしたい」から「プロダクトを通じて価値を届けたい」「データをビジネスに変えたい」という方向に考え方がシフトしてきました。 DeepLearning以降、特にTensorFlowがリリースしてから、機械学習界隈の変化のスピードの加速とコモディティ化が激しくなってきて、身の振り方を考えないといけないなと思い始めました。

一方で、garyuさんの本を読んで「USに行きたいのなら日本法人に入るのが定石」というのを学んで頭の奥底に溜まっていました。

作者: 竜盛博
出版社/メーカー: 技術評論社
発売日: 2015/10/08
メディア: Kindle版

そんな中で、を読んで、「なるほど、英語で仕事をするという選択肢は自分のキャリアにとっても重要だな」という想いが強くなった時に、一緒に飲む機会があって誘われて面接を受けて入ることになりました。⁵

前々からセールスエンジニアは、ユーザーに価値をどうやったら届けられるかを考える点で、BtoBにおけるプロダクトエンジニアだなとshiumachiさんの言葉を読んで感じていました。

今の上司がとても良い人で彼に惚れたというのも大きいです。マネージャーだけど最新の技術に対しても常にキャッチアップをし続けて、かつ非ネイティブに対してもとても辛抱強く接してくれて、ここまで条件の良い上司はめったに出会えない（＝自分に言い訳ができない）と思っています。 Hadoopを中心としたエコシステムにもう一度飛び込んで、データ基盤のインフラ周りについてもがっつり取り組みたいなと思っています。色んなデータをみてどう価値を生み出すかを考えるのが好きなのですが、仕事をすることが、データを活かしてビジネスに変えることにつながるので、今からワクワクしています。

今の様子

今回もまた優秀な同僚に囲まれ、社内にある膨大な情報の中で泳ぎまくりたい衝動を抑えながら⁶ 、久しぶりのHadoop周りを楽しんでキャッチアップしています。グローバルではそれなりに人数がいる会社ですが、ソースコードは自由に見られるしMLの議論もオープンだし、風通しはとてもよいです。英語もまだまだだけど、とDMM英会話を使って必死に頑張っています。

会社が変わって、社内の機械学習チャットルームがなくなった分情報少なくなるかなと少し心配していたのですが、Data Science系のMLがあってそこを眺めてテンション上がっています。自分の強みを活かしつつ、少しでも多くのデータが価値を生み出せるように貢献していきたいです。

ちなみに、1社目を転職するきっかけとなったApache Nutch, Luceneを ⁷ が作っていたということを、今更ながら知り、なるほどこれは必然だったかという想いでいっぱいです。⁸

念のため補足すると、簡単なSolr検索のデモアプリをRails2系で書いて、後はSinatraでAPIサーバー書いてたり、OSS活動はしてたけど、他の人からするとほぼ0レベルだった ↩︎
大体元ドワ勢 ↩︎
本当にyoshioriさんとmakimotoさんには頭が上がらない ↩︎
人生N周目以降の強くてニューゲームっぽい人が多かった ↩︎
なお、昨年末から転職活動はしていたので、例の話とは関係ありません ↩︎
クックパッドの社内wikiのGroupadもたいがい時間泥棒だったけど、それを上回る時間泥棒っぷり ↩︎
Hadoopの生みの親。今はClouderaのChief Architectをしている ↩︎
1社目を出るきっかけがRubyとSolr,Nutch,Hadoopだったので、MatzとDougが僕の人生を変えたと言っても過言ではない ↩︎

#CookpadTechConf 2016でクックパッドの研究まわりの取り組みを発表しました

Sun, 24 Jan 2016 16:00:00 -0800

1/23に開催されたで、クックパッドの研究開発に関する取り組みを紹介させていただきました。

from

メッセージとして伝えたかったことは、

という主にtoB向けに提供しているクックパッドの検索履歴を可視化したサービスを開始しました
普段はAndroid書いてるアプリエンジニアが、自らレシピをカテゴリ分類できる仕組みがありますよ

ということです。

[2016/01/25 10:04追記] たべみるの学術アカウントは無償提供させていただいております [/追記]

たべみるは、社内でも季節の食材やトレンドを見てレシピを選定するためにも活用しているのですが、地域ごとの差異なんかもわかったりします。なので、生の検索データではないのですが統計的に見やすくなった情報をインタラクティブに調べることができるので、研究のあたりを付けるための仮説を出すためには十分使えるんじゃないかなと思っています。

もう一つは、アプリエンジニアも機械学習できる仕組みの話ですが、これには少し端折った点があります。普通の機械学習をするためには（DeepLearningはまた違うけど）、テキストから適切な情報を取り出してベクトルに変換する必要があります。そして、その変換の仕方が肝になってきているのですが、そこは既に知見があるので仕組みの裏側に隠蔽されています。また、今回の資料にはないですが、クックパッドにはユーザーが推薦するカテゴリ情報というものがあり、カテゴリベースで正解データを与えることが出来ます。そして、それがかなり有用な教師データとなっています。

あとは、さらりとデグレを防ぐために性能をチェックしてます、という話も含めていますが、ここに至るまでに痛い失敗をしたのでこういう形に落ち着いています。機械学習の予測モデルは、確率的な要素が含まれるので普通のrspecなどのテストではなかなか検出できません。そこで、少数の評価セットを予め用意しておいて、性能が一定基準以下になったらアラートをモデルの更新を止める仕組みが入っています。過去には、これがなかったために、テキストからベクトル化するために使っている辞書データのミスマッチで予測器が壊れてしまったこともありました。

比較的小さいチームなので、特に気をつけているのがその研究はユーザーにどういう価値があるのか？という事を考えること。自分が取り組んでいる情報推薦なんかは割りとプロダクトと表裏一体なのですが、これからも先端を見据えつつ実際に役に立つ技術を追求していけたらと思います。

今回、運営側の方々も少数精鋭で開催していただいて本当にありがたいと思います。1月のカンファレンスは辛いんですよね…¹ 。楽屋で青木さんがmirakuiさんを煽るのを聞きながら皆で爆笑したり、いつものカンファレンスとは一味ちがった楽しみ方ができました。去年は神奈川Ruby会議の開催をできて、今年は32歳になる前にCookpad TechConfで登壇と大きな経験を積めて本当にありがたい限りです。

ちなみに、今日が誕生日なので例のリスト置いておきますね²

大晦日・元旦に神奈川Ruby会議の打ち合わせした記憶が蘇ってきます ↩︎
この手法、2年連続である ↩︎

2015年を振り返って

Wed, 30 Dec 2015 13:41:51 -0800

今年は色々と挑戦をし、成功したもの失敗したもの多くの体験ができました。

雑感

その中で痛感したのが、背中を預けられる仲間と働くことの重要性でした。通年を通じて会社の同僚に散々言われつづけてきた2つの言葉があります。

責任を取らない人の言葉は気にしてはいけない。自分で責任を取り権限を掴め。

この言葉が実行できたのは今年の終盤でした。開き直ってしまえば、しんどさはあるもののどんどん進めていくことができるようになりました。

本当にそれは自分がやるべきことか？断れないから引き受けていないか。自分のキャパを過大に見積もりすぎてはいけない。

年の中盤から意図的に参加する勉強会を絞ったり、主催も控えめにデリゲートできるものはデリゲートしてきました。結構切り捨てるものは切り捨てました。けど、もう少し抑えられる気がしています。

自分の「得意」が何で、それを踏まえた上で何を伸ばしていきたいか、何でもやる、からもう少し指向性を持たせて歩を進めてきました。

とくに上の2つを言っていた人が最初の先輩に聞いたという

履歴書に書ける仕事を選べ

という話は、とても印象に残っていて今後の指針にもなっています。

コミュニティ

「コミュニティおじさん」と呼ばれて久しいですが、仕事が多忙で苦しいことも多少ありましたが充実した一年でした。

友達がいない/自分の求める勉強会がないなら、勉強会を立ち上げてみるのはいいんじゃないかと思います。少なくとも似た興味を持つ人が集まって来て毎月飲み会も開催できます¹

神奈川Ruby会議

なんといっても今年の最初から神奈川Ruby会議という大きいイベントを開催しました。

podcast

というPodcastをにあこがれてはじめました。

きっかけは神奈川Ruby会議のパネルディスカッションをもっと深掘りしたいという気持ちだったのですが、最近では"Rubyist"という縛りが厳しすぎたかなぁという気持ちになっています😅

来年も月1くらいで継続していきたいと思います。

なお、rebuildのは無事家庭内稟議が通りました。

ちなみに、今年聞いているpodcastはこんな感じです。わりと通勤のながら聴きなので英語は左の耳から右の耳です。。。

tech系
- - 長いけどWindowsネタやガジェットネタのRSS追いかけない代わりに聞いてる。結構濃いトークできる業界の人がサラリと出てくるので、まずは興味のある話だけ聴くのがオススメ
ML系
- - ゲストにHinton出てきたりとメジャーな企業の研究者が出てきて豪華なのでオススメ。音はいまいち
英語
- - 「Friendsは今でも英語の日常会話の学習に最適なの？」という質問が中国の人から出るなど、USの文化だったり語学学習者に適したコンテンツが多い

kawasaki.rb

神奈川Ruby会議との相乗効果で、新しい方々に参加していただけるようになりました。 GolangだけでなくPythonやScala、はてはRailsブートキャンプに参加した話など多様なアウトプットをしていただける場になり、地域に根ざしたコミュニティができているのではないかと思います。

from

勉強会の懇親会にぴったりなお店も教えていただくことができ、大満足です。

tabelog.com

MLCT

今年も2回開催できました。安定して胃が痛くなる実務でよくある苦労話が多く聞けており、主催者冥利に尽きます。毎回、やってよかったと思いながらタイムキーピングとかもしないで聞けるのが一番いいのにな、と思っています。最近、開催するとHivemallのmyuiさんやGoogleの佐藤さんなどLTでさらりと大御所がトークしてくださることが増えており、恐縮することが増えています。

mlct.connpass.com mlct.connpass.com

MLCTはスピーカーのアサインとテーマ設定がなかなか難しくて、コンスタントに開催できないのが苦しいのですが、話したいことあるよ！という方がいましたらご連絡ください。

Julia Tokyo

一年に3回開催することが出来ました。だんだんとDeep Learningな話が増えてきており、楽しい限りです。言語縛りは有りますが最適化や機械学習が好きな人が集まってきてトークする流れが定着しているのは良いなぁと思います。

プライベートな開発

Julia

個人的にもJuliaの一年でした。特にTinySegmenter.jlを時差を最大限に活用した高速化をしたのはいい思い出です。

MeCab.jlとTinySegmenter.jlで少しずつ日本語のテキスト解析事例が増えてきたので嬉しい限りです。来年はもっときちんとしたものを作りたいなぁと思っています。

Jupyter notebook & pandas

iRubyを通じてですが、githubがレンダーするようになったのと、pandas-tdが非常に便利なことから職場で普及活動をしていました。

jupyter notebookのいいところは、試行錯誤をしやすいことと再現性が担保されることです。なかなか伝わりにくいその魅力もアニgifとハンズオンで広まって、会社のブログで書いた記事も大分広まって良かったです。

techlife.cookpad.com

また、ここに至るまでにさんの10年本がなければ至らなかったです。結局何事にもSQLが必要だと思い知らされた一年でした。

作者: 青木峰郎
出版社/メーカー: SBクリエイティブ
発売日: 2015/06/30
メディア: 単行本

翻訳のお手伝い

Lean Analyticsの日本語版の翻訳のお手伝いをしたのですが、今年出版されました。

作者: アリステア・クロール,ベンジャミン・ヨスコビッツ,林千晶,エリック・リース,角征典
出版社/メーカー: オライリージャパン
発売日: 2015/01/24
メディア: 単行本（ソフトカバー）

もともと、昨年社内で読書会をしていたのですが、データ分析をするものの心構えとして大事なことが詰まっている本です。

harupongさんみたいに翻訳をゴリゴリやっている人とのレベル差も知ることが出来て良い経験でした。

サービス開発という仕事

とは違って、逆立ちしても叶わないディレクターの作りたい世界を作るために自分の武器は何を提供できるか、というのを考えながら進めてきた一年でした。² 最初はコンセプトメイキングを横で眺めていただけだったのから、自分もその世界観にずっぽりハマるきっかけをいただき、何をすればいいのか何が必要なのか何があればこの世界観に繋がるんだろうかということを考えていました。

また、それを後方支援するために資料作ったり数字出したりログ設計して集計したり、ということをやりながら、裏側の仕掛けを考えたりRails書いたりhamlとsassかいたり、泣きながらCSS修正しまくったりしていました。

サービス開発は常にこれでいいんだろうか、ピボットはいつすべきなんだろうかと考えながら一歩一歩進むので、胃がキリキリしますよ。納得の行くものが出来た時には充実感を感じますね。

以前一緒に働いたディレクターのこの言葉の、少なくとも何割かは実感できた一年でした。

サービス開発をするエンジニアは、圧倒的な技術力を発揮したりプロセス改善をどんどんしていくというよりは、コードが書けなくとも何を作るのかを常に考えたりクマさんのように話を受けたり、はたまたぶれそうになった時にツッコミを入れたりということが大事なんだということを実感しました。

まとめ

言葉にすると当たり前のことばかりでも、それらが自分の血肉になった一年でした。

また、今年はいい人との出会いも出来たなぁと思っています。結構いい年齢の人と話すことで「こういうアプローチでビジネスを回していくんだ」というのが少しずつ見えてきて、仕事の違った面白さも見えてきています。

来年も、もっともっと成長できるよう挑戦をしていきたいと思います。

ただし、LINEのアカウントは交換していない ↩︎
成長している人の側で仕事するのは楽しいですね！ ↩︎

2015年に買ってよかった物まとめ

Tue, 29 Dec 2015 12:33:41 -0800

書いておくと後から検索できることもあり、今年買ってよかったものを書いていこうと思います。

1. 防水Bluetoothスピーカー

出版社/メーカー: Patech
メディア: エレクトロニクス

お風呂にも使えるし、キッチンでも冷蔵庫に貼り付けたりして使えて便利です。水の音に負けない程度の音量を稼げて、iPhoneやiPadで単純に再生するよりもながら聴きが捗ります。 Podcastを聞くのにちょうどよいです。Podcastの音をAirplayで良いスピーカーに繋いで出すとあまり音が頭に入らないんですが、ちょっと昔のラジカセみたいな感じでちょうど聴きやすくなります。妻もこれを使って英語のPodcastを聞くようになっています。

2. 二重窓フィルム

出版社/メーカー: Nitoms
メディア: ホーム&キッチン

これは結露がかなり減るのでオススメです。劇的に変わりました。普通のプチプチみたいなのとは異なり、窓ガラスから少し浮かせた位置にフィルムを両面テープで固定するものになります。二重窓をフィルムでつくり上げる形ですね。

特に網入りガラスなど割れる可能性がある窓にも適用できるのと、毎日結露していた窓がかなり水滴がなくなりました。賃貸の方にもオススメです。

3. Synology DiskStation DS215j

出版社/メーカー: Synology
発売日: 2014/11/30
メディア: Personal Computers

本当はこれ単品でレビュー書きたかったんですが、結果としてここでの紹介になってしまいました。もともとQNAPに入っていたディスクが壊れたので、いい機会だから2枚刺さるNASにしようと思い選びました。僕が買った当時はSynologyしかbox.comとのsyncに対応しておらず¹ 、必然的にSynologyを選ばざるを得なかったのですが、使い勝手は割と良いです。

そもそも、シングルコアからデュアルコアのCPUに変わったことも有り、転送速度もかなり改善したのが大きいですが、アプリ周りも良い感じです。ただ、家の外からアクセスする際に結構細かくファイアーウォールなどを設定できる反面、どれが設定に必要なのかが少しわかりにくいので玄人向けという印象です。

なお、ハードウェアのスペック重視でいくならAsustorのNASがいいんだろうなと思っています。

NASは4年くらいに一回買い換えるのがいいかもしれません。

ディスクはNAS用途の24時間稼働を想定した赤いやつを買っています。

出版社/メーカー: Western Digital
メディア: Personal Computers
購入: 5人クリック: 6回

4. サイクルロッカー

出版社/メーカー: 株式会社サイクルロッカー
メディア: その他

室内で自転車を置きたかったのですが、それまで横置きしていて場所をとっていたのでこれを買いました。地震が来ても大丈夫な感じで安定しています

5. Panasonic LEDかしこいテールライト SKL090

出版社/メーカー: Panasonic(パナソニック)
発売日: 2012/03/09
メディア: スポーツ用品
購入: 3人クリック: 10回

いわゆる、振動でテールライトがオンになるやつです。これまで夜走り始める前にいちいち電源をオンにしていたのが必要なくなって地味に便利です。

6. サンシェードとDCモーター扇風機

出版社/メーカー: 大徳商事株式会社
メディア: Tools & Hardware

出版社/メーカー: 山善(YAMAZEN)
メディア: ホーム&キッチン

時期を逸してしまった感はありますが、今年の夏にこれを導入したおかげでかなり快適に過ごせました。特にサンシェードは温度上昇が劇的に抑えることができ、とてもよかったです。体感で温度が違うことが感じることができる程度には効果がありました。

DCモーター扇風機もほとんどお値段しないわりに、静かだったので子供が寝ている時にも活躍しました。

というわけで、今年は色々なものを買いました。dotとかは来年レビューを書こうと思います…。

今はQNAPも対応したようです ↩︎

Julia Tokyo #5を開催しました #JuliaTokyo

Fri, 25 Dec 2015 13:02:48 -0800

さる12/19にを開催しました。¹

togetterのまとめはこちら。

togetter.com

資料はまだいくつかしかアップロードされていませんが、今回は機械学習の話やDeep Learningの話が多かったように思います。

juliatokyo.connpass.com

個人的に印象的だったのは、hshindoさんのMerlin.jlです。さくっとDeep Learning用のフレームワークを実装できるのは驚きでした。

また、今回運営サイドとしては、さまのスポンサードをいただいており、Slackとの連携出来て嬉しい感じです。

本編

さんのイントロ

speakerdeck.com

さん Juliaチューニングハンズオン

を題材に、Juliaのボトルネックをprofileしながら高速化していくハンズオンでした。

oyamadさん QuantEcon.jl の DiscreteDP の紹介²

github.com

oyamad先生のゼミ（経済学部）では来年からJuliaが必須になるそうです！

さんメカジョさんとジュリアたん

from

MITのJuliaの研究室ではジュリアたんステッカーがマシンに貼られているそうです。世界を股にかける！

さん MXNet.jl+AWS GPU: DeepLearning Super Powers from ~ $0.35hr

Mocha.jlの作者はMXNet.jlに移行したそうです。というわけで、GPUもCPUも分散で行けるMXNetに移行しよう！という話でした。 AndreさんがAMIも作ったそうです。

Releasing an AMI with everything you need to run GPU enabled MXNet.jl

— Andre Pemmelaar (@QuantixResearch)

さん Neural POS-Tagging with Julia

NAISTの松本研では、Pythonを使う学生とF#を使うhshindo先生が共通の言語としてJuliaを使い始めているそうです。紹介のあったMerin.jlは、characterベースのPOS taggingをNNを使ってやりたかったから作ったとのこと。パット見たかんじChainerっぽい書き方で、DLができます。

github.com

資料はこちら。

LT

bicycle1885さん v0.5に入りそうな気がする変更

資料

さん Juliaでオンライン線形分類器つくった

Exact Soft Confidence Weightedを実装したよ、という話。会場からも実装が綺麗と評判でした。

github.com

from

さん Hierarchical Temporal Memory どうでしょう

次回、HTM.jl作ってみた、乞うご期待。

docs.google.com

さん AROW

でも有名なkazoo04さんのAROW.jlの話。 SCWにAROWにとオンライン学習アルゴリズムが一通り揃った感ありますね。

github.com

さん JuliaでCUDAを扱うのはらく～だ

全然楽じゃなさそうです…。maleadtさんのCUDA.jlが理想に近いそうですが、上手く動かないという…

github.com

from

さんテキスト分析

MeCab.jlとTextAnalysis.jlを使ったテキスト分析の話でした。JMW仕事しろ案件

qiita.com

さん声質変換

福山雅治が歌う関白宣言を、さだまさしが歌うように声質変換する！ということで胸熱な話でした。続編があるようで、期待大です。

まとめと雑感

懇親会では、さん寄贈「データサイエンティスト養成読本　機械学習入門編」争奪じゃんけん大会がありました。

まさか、遠方からの参戦があるなど日本全国にJuliaが広がっている機運が高まっています。Advent Calendarも無事終わって、時代はJuliaですね！

qiita.com

週3勉強会開催のフィニッシュdayでした ↩︎
どうでもいいけど、はてなブログPDFをgithub上の埋め込むすべがないな。。。 ↩︎

Juliaで得られたマイナー言語を盛り上げる方法 #JuliaAC

Thu, 24 Dec 2015 16:00:00 -0800

この記事はの最終日です。

Juliaは大分マイナーな言語で、日本語による情報が殆ど無かったのですが、以下の要因で大分盛り上がってきていると思います。

イベント（JuliaTokyo）を年数回開催している
Advent Calendarを毎年開催している
エヴァンジェリスト(a.k.a bicycle1885)が宣伝し続ける

1. イベントを年に何回か開催する

最近は大分3つ目の要素がでかいなと思ってきているのですが、そもそものJuliaTokyoのスタートとしては僕がMachine Learning Casual Talksを開催したところ、偶々来ていたbicycle1885さんがいたということと、Tokyo.RでJuliaの宣伝をしていたさんとで意気投合して始めました。

この手のマイナー言語の通例としては英語圏でなんだか盛り上がっているらしいぞ、でも日本語の情報もないし何が嬉しいんだっけ？というケースが圧倒的に多いと思うのですが、やる気のある人が3人いれば勉強会を継続的に開催できます。¹ 負荷分散大事。

最近は、にスポンサードもしていただいて、情報の共有も少しずつすすめております。²

2. Advent Calendarを毎年開催する

かなり広がりを感じたのがQiitaで開催したです。きっかけは同僚の[gfx]( gfx )氏に煽られてはじめたのですが、何とか25日埋まって良かったです。³

Qiitaは最近情報が溢れてきて質が云々とかいう議論がたまに出てくるのを見かけるのですが、ことJuliaに関して言えば「試してみた」「installしてみた」とかでも全然情報としては価値がありますし、投稿していただけるととてもうれしいです。
JuliaTokyo名物「Juliaはじめて24時間以内枠」というLT枠がいつもなんとなくあるのですが、こうした気軽にやってみた/作ってみた/試してみたという行為が日本語の情報を増やすことにつながるので、正の連鎖がつながっていきます。
また、Julia自体が変化の速い言語なので、過去の記事と同じ事をやっても実行できないということがざらにあります。ですので、「最新の入門情報」というのは非常にありがたいわけです。

もちろん、ガチ勢は放っておいても英語の情報を取ってくるのですが、日本で裾野を広げるためには日本語の情報が欠かせません。

今年は名古屋方面にもJuliaが広まっているのを実感して、とてもうれしい限りです。

3. エヴァンジェリストを確保する

最後のエヴァンジェリストを確保するという話は、結構大変かも知れません。我々の場合、エネルギーもある程度の時間もある優秀な大学院生がJSoCというグラントも取って開発しちゃったり研究に使っているのですが、彼が常に「Julia良いよJulia」「これからはJuliaの時代」と言い続けている⁴ ことで、じわじわと広がっているように見受けられます。そのおかげで、ウサギィさんやNAISTの松本研にまでJuliaが広がっていると聞き、やはり良いと言い続けることと情報を蓄積し続けることは大事だなと通関しています。

無論、そもそもの言語としてのウリ（NumPy, SciPyでできない行列計算以上のことをやるときに速さが欲しい）がなければこれも無意味ではあります。しかし、いかに良い言語であっても広まらない時は広まらないし、そこまで良いと思っていない言語でもデファクトになるという時はあります。であれば、自分の好きな言語を広めると幸せになれるんじゃないか、と思います。

後はなど、他言語との比較を行うことができると、より他言語のユーザーに認知が広まるのではないでしょうか。

まとめ

最後にテクニカルではない話になってしまいましたが、Juliaの事例を通じていろいろな言語が盛り上がっていけばなと思います。

この辺僕が死んだら開催されなさそうなkawasaki.rbとは対称的ですね :p ↩︎
コミュニティ運営で重要なのはSPOFを作らないことだと思っているので、esaなりSlackでのchat opsなりは負荷分散のために非常に重要。負荷の集中を舐めてはいけない ↩︎
途中までだいぶ一人カレンダーの様相を呈していた ↩︎
壊れたロボットの用に同じ言葉を繰り返す作戦にしか思えない ↩︎

Machine Learning Casual Talks #4 を開催しました #MLCT

Mon, 21 Dec 2015 05:24:03 -0800

まさかの一週間内に自分の主催する勉強会が3回重なるデスロードを走ってきたchezouです。¹

前回からだいぶ感覚があきましたが、MLCTをさんの火付けのもと開催しました。²

mlct.connpass.com

テーマはさん発案のDevOpsをもじった"DevData"というテーマでしたが、奇しくもデータ分析チームの立ち上げ方とどうやってビジネスにコミットしていくか、という話になりました。

まとめはこちら

togetter.com

chezou オープニングトーク

from

さん「プロトタイプで終わらせない死の谷を超える機械学習プロジェクトの進め方」

from

リブセンスでデータを活かしたプロダクトを作るに当たり、リスクとリターンを鑑みてビジネスとしてどこを狙うべきかということを様々な手法を駆使して進めてこられた様子がわかります。

DMM.comラボ田宮さん「ビッグデータチームを発足するにあたって気をつけておきたいn個のこと」

from

DMM.comラボでのデータ分析チームの立ち上げの話。読まれないレポーティングなど、あるある話から現実に活かされるようにするためにはという試行錯誤を知見として教えていただきました。

ディスカッション

複雑なモデルと簡単なモデルどう考えて選ぶのか？など、実際の機械学習としてエレガントな方向と泥臭いところのバランスをはじめ色々な話を聞くことが出来ました。

さん「Gunosy分析チームとA/Bテスト運用」

speakerdeck.com

Gunosyのデータ分析チームの現在の話、LTではもったいない話でした。会社の規模もおおきくなりだいぶチームのあり方やABテストの取組み方も変わったようです。

@yamakatu さん「ヤフオク！と分散表現」

資料まってまーす

Google佐藤さん「GoogleのMLについて」

残念ながら資料は公開されないということですが、Vision APIの話を中心にTensorFlowなどの話をしていただきました。Vision APIは一般物体認識のタスクではかなり便利そうですね。特に、手書き文字認識も頑張っていたり、ガリガリ君の立体物の文字認識をきっちり出来ていたのはさすがだなと思いました。

火曜MLCT, 水曜kawasaki.rb, 土曜JuliaTokyo！！ ↩︎
言い出した割にはLTだけだったので後で🍣反省会を開きましょう ↩︎

小さい子供が自分から薬を飲みたくなる「おくすり飲めたね」 #childadvent

Sun, 20 Dec 2015 16:00:00 -0800

この記事はの21日目の記事です。

前日は、さんのでした。

今回はまったくテクノロジーの話をしません。¹

1行で

「おくすり飲めたね」を使うと、子供が薬をのむのが好きになった

言いたいのはこれだけです。はい、解散。

流石にそれは短すぎるので…

おくすり飲めたねとは、龍角散が出している薬を包むゼリーです。

出版社/メーカー: 龍角散
メディア: ヘルスケア&ケア用品

我が家で愛用しているのは、パックタイプのものでキャップを外して中を押すと少しずつクラッシュされてでてきます。

うちの子供達はよく咳が出たりして薬のお世話になることが多いのですが、これを使う前はすぐにむせたり吐き出してしまったりと親子で疲弊していました。

ある時薬局でおくすり飲めたねの存在に気づいて試してみたところ、子供が「おいしい」といって薬をすすんで飲むようになったではありませんか。下の子なんかは、上の子だけが薬を飲んでいると「私も薬を飲みたい」と泣き始める始末。

本当にこれがなかった頃の我が家は

薬を出す→治らない→飲む期間が伸びる→薬を出す→….

というように毎日が戦争でした。

味についての注意

味が複数ありますが、いちごはAmazonのお急ぎ便対応なので重宝します。我が家のメインはこれです。
そして、たまにでる抗生物質なんかはチョコレート味で包まないと、恐ろしく苦くなってしまい出してしまうので注意が必要です。

出版社/メーカー: 龍角散
メディア: ヘルスケア&ケア用品

近所のドラッグストアにも売っているとは思うので、お子さんが風邪を引いた時など、一度ためしてみると良いのでは？

明日はzuzuさんのエントリです。

ひどい ↩︎

Juliaの情報を収集しつづけるには

Wed, 09 Dec 2015 16:00:00 -0800

この記事はの10日目です。昨日は、bicycle1885さんのでした。

Juliaは変化が速い言語なため、最新の情報を追い続けるのが必要な言語です。しかし、初心者にはその変化の速さになかなかついていくことが難しいです。

そこで、今回はJuliaの情報を追いかけるための情報源について書いていきます。

なんといってもJuliaの日本語情報で一番お手軽なのはさんの情報を追いかけることです。

twitter.com bicycle1885.hatenablog.com

また、JuliaTokyoのslackも出来たのでこちらで気軽に質問していただくのも良いでしょう。

英語で最新情報を追う方法はいくつか有りますが、 bicycle1885さんに一番おすすめと言われたのが JuliaLang/juliaのNEWS.mdの変更を追いかけることでした。

ということで、RSS feedを作ってみたのでお使い下さい。

他にも、redditのjuliaカテゴリや

www.reddit.com

juliaの著名な方々がpostするJulia関連のblogを集めたjuliabloggers.comなんかも良いでしょう。

www.juliabloggers.com

これらのfeedはjulia-tokyoのslackにも流れてくるようにしたので、そちらに居るだけで皆でワイワイする様子が見ることが出来ますね。

なお、僕は大好きはSN比が悪いのであまりオススメしないとの言葉。

というわけで、今後もJuliaを追いかけ続けたい方々に向けた情報でした。

どんな子供も好きになる、「うーやん」を広めるたった1つの方法

Sat, 05 Dec 2015 16:00:00 -0800

このエントリは、の6日目です。

「うーやん」とは？

うどんです。

本の正式名称は「うどんのうーやん」です。

「うーやん」とは？

働き者のうどんです。

人手不足の煽りを受けて、自分自身で配達に行きます。
世が世なら、世界中の仕事が人工知能によって奪われて「うーやん」は自ら配達に行く必要は無かったのかもしれません。

「うーやん」とは？

哲学です。

そこに川があるから渡り、

そこに山があるから登ります。

さらに、食べてしまおうと迫り来る鳥との戦いでは、唐辛子さんとの熱い友情も見ることが出来ます。子供の情操教育にぴったりですね。さらに、前編関西弁で記述されているため、関東地方に住む子供にとっては方言を通じて「地域によって言葉が違う」という多様性を学ぶことができます。¹

「うーやん」を広める唯一の方法

ここからは僕が取った方法なので、再現性が高いかわかりませんが、5歳未満の子持ちの同僚がそこそこ居る会社に所属されている方なら通用すると思います。

Wishlistに子供向けのものを入れている人（子供の誕生日とかだとなお良し）に、 頼まれてもいないのにもう一品うーやんを追加して 送りつける
届いた子供が気に入ったという話題が出るので、社内でとても面白いという評判を広める
次々とお子さんを持っている同僚が買いはじめ、お子さんがいない同僚にも広まる

こうして、普段自分の子供の話すらしたことがない同僚からも「うーやん見てみたいんですけど」と言われるまでになります。

2歳位のお子さんをお持ちの同僚と話をしていると、思った以上に「どういう絵本を読めばいいのかわからない」と困っている人が多いように感じました。でも紹介した、のように、おまかせで毎月届けてくれるサービスを使うのも良いかもしれません。

小さいお子さんをお持ちで、まだうーやんを持っていない方は是非一度手にとって見るとよいでしょう。

作者: 岡田よしたか
出版社/メーカー: ブロンズ新社
発売日: 2012/08
メディア: 単行本
購入: 1人クリック: 75回

明日は、ohesotoriさんの記事です。

SympyとJupyter notebookで数式のメモを取ろう

Mon, 23 Nov 2015 13:02:07 -0800

さんによるSympyの紹介がとてもよい感じだったのですが、Sympy Liveわざわざ使わなくてもJupyter notebook使えるのでは！？と思ったので試してみました。¹ わざわざ、というと語弊があると思いますが、手元でメモ＋αとして管理するのにはJupyter notebookの方がいいかなと思っています。

myenigma.hatenablog.com

Sympyはでも見ていて、ふーん、凄いなと思っていた程度なのですが、単純に数式を記述するだけではなく、それを方程式として展開したり微分、積分したりできるのが良いですね。単に数式をメモするだけならJupyter notebookでLaTex記法で数式を書くことができます。

meison_amslさんのものを Jupyter notebook で実行しただけのお手軽版はこちらです。

gist.github.com

グラフもさくさくっとかけるので、極限求めるついでにグラフ書くとかするととても便利ですね。（これがあれば、PRMLもらくらく戦えるのかな…）

kindleでも売っているInstant Sympy Starterですが、ちょうどPacktのアンケートに答えたらなんでも$5で買えるキャンペーンがやっていたので、そちらで買いました。 Packtは一度買うとガンガンクーポン来るし、月額定額で読み放題とかもできるみたいなので、Kindleで買うくらいならPacktで買うのも良いかもしれません。

作者: Ronan Lamy
出版社/メーカー: Packt Publishing
発売日: 2013/05/23
メディア: Kindle版

www.packtpub.com

完全に人の褌で相撲を取るやつですね… ↩︎

IDCFクラウドの500円サーバーでpodcast serverをはじめて8ヶ月が経ちました

Sun, 22 Nov 2015 13:30:37 -0800

どうも、最近PSYCHO-PASSを見終わってシュタインズ・ゲートを見ています。この記事はIDCFクラウド1周年キャンペーンを応援する記事です。¹

Rubyistといろいろなことを話すpodcast をはじめて半年経ちました。最近リリース前のドタバタでご無沙汰していますが、12月には次回の配信をできると思います。

IDCFクラウドは、さんが使ってますよー、というのをいつかのお友達紹介キャンペ言っていて知りました。おかげさまで、そこからクーポンを使ってしのいでいます :)

。クーポンのおかげでほとんどまだお金を払っていないのですが、それを割り引いてもカジュアルに使うのには良いです。 AWSほど複雑な設定はしづらいですが、逆に言うとシンプルに使えるのが便利です。本当はプログラマブルにAPI経由で使えるようなのですが、そのへんの経験が浅い自分でもGUIベースで使えるので楽ちんです。ゆくゆくは、itamaeで構成管理をしたいなぁと思っています。

S1プランは500円で使えるのですが、オブジェクトストレージとかを使わない分には本当に500円を超えることはまず無いです。オブジェクトストレージはCyber Duckとかを使うことでS3のように便利に使えるので良いのですが、転送量課金が結構大きいので、おそらくpodcastのような転送量が増えるコンテンツにはノード内にデータをおけるならそれで済ますのが良いでしょう。また、オブジェクトストレージはちょいちょい障害の報告がきますが、通常のノードはほとんど落ちることはないので、安定して使えます。

ドキュメントや使用事例がweb上の情報としては少ない感じがするのがあれですが、それを補って余りあるお値打ち感が魅力です。

是非、この機会に使ってみるとよいでしょう！

つまり、宣伝ですね ↩︎

TinySegmenter.jlをGoと比較して負けたと思ったら若者が最適化してくれた

Sun, 08 Nov 2015 11:00:00 -0800

先日、を書いたら各方面から反響を頂きました。

repeatedly.github.io

woxtu.tumblr.com qiita.com

そんな中で、ikawahaさんがGoでも同様の最適化を実装していました。

ikawaha.hateblo.jp

それと比較するために、とりあえずして比較しました。

Ruby	Perl	Python	Node.js	C++	Go	Julia	Julia (hash optimized)
132.98	134	111.85	105.31	48	10.50	11.70	10.35

実はTinySegmenterMakerのshogo82148さんが一部のhashのkeyをordしたIntで表現するというさらなる最適化を進めていたので、ちょっと負けてしまったのですがJuliaのDictを生成するときのhash計算が遅いということをので、Julia本体の最適化が進めば同じくらいにはなりそうだね、ということがわかりました(表のhash optimized)。

ちなみに、SGJ先生は「実は言語間の比較ではなくて最適化の比較になっていたんだけどね（てへぺろ）」を告白しており、ikawahaさんの目の付け所は正しかったようです。

そういう意味では、Stringとしても処理できるし頑張れば最適化できるJuliaは楽しいですね、という気持ちになりました。今時のコンパイル型の言語だと突き詰めれば似たような性能になるんでしょうね。

Amazon Fire TV Stickを買ったらApple TV+ChromeCast-ちょっとになった

Mon, 02 Nov 2015 15:42:22 -0800

Amazon Fire TV StickをPrime会員割引で\1980で買いました。（定価は\4980)

出版社/メーカー: Amazon
発売日: 2015/10/28
メディア: エレクトロニクス

なぜFire TV Stickを買ったかというと

安かった
iOS/Androidのアプリで音声認識ができるのを知っていた(→音声認識リモコンいらない)
4k写せるモニタなかった(Fire TVはいいかな)

という3点からです。

出版社/メーカー: Amazon
発売日: 2015/10/28
メディア: エレクトロニクス

これと大分構成違いますよね？

Pros/Cons

Pros

AirPlayを受信できるソフトを立てるとAirPlayが受けれる
NetflixやYouTubeなどFire TV側のアプリが対応しているとChromeCastと同様にアプリからCastできる
AirPlayとかChromeCastでまともに見れないニコニコ動画のアプリがあって、最低限の使用に耐えている

Cons

無線が結構弱い/Apple TVやMacBook Proの直下に置くと5GHz帯の無線が繋がらなかった
なんだかんだでリモコン前提なので、操作が若干だるい（Apple TVやChromeCastほどスマホで操作する感じじゃない）
情報が殆ど無い（困ったらReddit探すのがよい）

やると良いこと

AirReciever入れるとAirPlayサーバーになります。ただ、Netflixは飛ばせたり飛ばせなかったりしたので、挙動が怪しいです。 iPhoneのMusicアプリとかの音楽系のアプリは普通に動いたので十分かな、と思います。

出版社/メーカー: ?方儿
発売日: 2014/06/24
メディア: アプリ

自分がよく使うアプリやスマホと連動させたいアプリはFireTV側で入れておく必要があります。特に、ChromeCastに慣れていると、アプリを入れないとCastできないという仕様はぱっとわかりませんでした。（OSレベルでサポートしていないけどアプリレベルでサポートしているという意味）

総括

完全に互換ではないけど、AirPlayサーバーにもなるし、アプリが限定的だけどChromeCastの代わりになるので割と満足しています。 5000円だったら買ってもいいんじゃないかな、と思う一品です。

ただし、情報が圧倒的に少ないので英語で調べられる人がいいと思います。罠にハマった時は大分辛かったです。（2.4GHZじゃないとしばらく繋がらなかった…）

試していないけどHDMI-CECに対応しているので、もしかしたらChromeCastのように転送したらテレビが自動で付くとかもできるかも（できないかも）おもちゃとして買うのにはまぁまぁ良いのかなと思います。

なお、当方ChromeCastの音声飛ばす版の販売を喉から手が出るほど待っています。

「ネットフリックスの時代」にはコンテンツの山に埋もれなさせないためのヒントが詰まっていた

Tue, 27 Oct 2015 02:20:31 -0700

backspace.fmでもよくゲストに出ている西田宗千佳さん( )の書かれた、「ネットフリックスの時代−配信とスマホがテレビを変える」読んだ。

作者: 西田宗千佳
出版社/メーカー: 講談社
発売日: 2015/10/16
メディア: Kindle版

一言で言うと、Netflixは「イッキ見」という新しいスタイルを中心とした視聴スタイルを作り出し、次々コンテンツを見せるためにレコメンデーションが存在している、という内容だ。

西田さんはテレビとかガジェットを中心としたジャーナリストだが、よく取材されていて非常にわかりやすく書かれていた。特に、Netflix周りの事だけでなく、国内のdTV周りの取り組みや対比としてのApple Musicまでのストリーミングミュージックの流れがコンパクトにまとまっていた。

特に4章、5章の音楽と映像コンテンツの対比がぼやっと考えていたところを整理してくれてよかった。

プレイリストという考え方は短い時間で消費するコンテンツの反復利用性をベースに組み立てられた考え方

音楽の性質としてその反復性示して、映像はそこまで反復して楽しむものではないという特性の違いを明らかにしている。言われれば当たり前なのだが、レコメンデーションをする立場としては、ECサイトでの購入みたいな繰り返しの少ないものと、音楽のような反復性の高いものでは使う手法が違ってくるし見せ方も違うということが再確認できた。きっと、レシピはその中間くらいなんだろう、ということも見えてくる。

また、見放題系のサービスでは、コンテンツが増えてきて何があるかわからなくなるということが往々にしてある。結局見つからないコンテンツはないと同じとバッサリ言ってしまう。グーグルの時代以降検索ができれば良いという発想に成りがちだったが、「いかにコンテンツとの出会いを提供するか」が肝で、検索はその部分の一つでしかないということを改めて意識させられた。そうした背景を前提にすれば、SpotifyやNetflixがレコメンデーションを自然に忍ばせるのは納得感がある。サービス体験の中で自然にレコメンデーションを忍ばせるのは結構注力しようと思わないと、取って付けた感しかでなくて受け入れられない。 Spotifyのある曲を中心とした類似曲の自動ラジオや、Netflixのおすすめ動画がホーム画面を埋め尽くすのは良い表現方法である。

今やNetflixだけでなく、dTVも裏で人手でのメタタグの作成を頑張っているということが書かれており、5章では自動Appleのプレイリスト方式(自動でプレイリストを生成して人手でチェックをしているらしい)とラジオ方式(曲やアーティストから類似曲でラジオを生成する)の比較がなされている。個人的にはプレイリスト方式の方が納得感のあるコンテンツを得られて好きなのだが、USでは開発速度に勝るラジオ方式のサービスの方が広まっているようだ。日本国内でもソニーのMusic Unilimitedがプレイリスト方式取り組んでそのプレイリスト増える速度が遅くて結局Spotifyベースにピボットした事例もあるらしい。一見思想的に良さそうでもビジネス的に最適解ではないというのもあり得るのである。

これ踏まえた上で、レコメンデーションのトップ会議RecSys2015のNetflixとSpotifyの人々によるチュートリアルを見ると、タグの話が全く書かれていなくて頭を悩ませる。多分特徴量の一つになってるのかな。

from

実は、この本を読む前にドワンゴの川上さんの「鈴木さんにもわかるネットの未来」も読んでいたのだが、電子書籍が良いというのはイデオロギーであり宗教だ。音楽を見るとCDから電子に移行してビジネスモデルが変わる度にビジネスがシュリンクしている、という旨の事が書かれていた。西田さんはテレビからスマホが隙間時間を奪っているため定額制の配信サービスに以降するのは自然な流れ、と書いているが、ビジネスのパイは小さくなるような気もする。両者に主張を比較するのも面白いだろう

作者: 川上量生
出版社/メーカー: 岩波書店
発売日: 2015/07/16
メディア: Kindle版

コンテンツに埋もれる時代に、どのように多様なニーズに応えるのか、多分UGCだとアプローチは違うのかもしれないが示唆に富んだ一冊である。

TinySegmenterをJulia移植したらMITの先生に指導してもらえた話

Wed, 21 Oct 2015 16:43:17 -0700

先日、工藤さんがJavaScript向けに作った日本語のコンパクトな分かち書きツール、TinySegmenterをJuliaに移植したを作りました。もともとは、PyconJPでを聞いたら居ても立っても居られなくなって、簡単なTinySegmenterを移植したんですが、そしたら思いもよらぬ展開が待っていました。

[2015/10/22 23:38 追記] 計測の問題をさんから指摘いただいたので再計測しました。

パッケージ登録時にMITの先生からツッコミが入る

Juliaのパッケージはというセントラルなレポジトリで管理されています。ここに登録されたパッケージはPkg.add("TinySegmenter")とREPLで実行するだけでパッケージが導入できます。¹

ここに登録をしようとした時に、「日本語の分かち書きツールなのに、パッケージ名が一般的すぎるのでは」というをMITの先生(以下、SGJ先生)からいただきます。Juliaのパッケージの命名規則はにもあるのですが、portingの時はそのまま名前を付けても良さそうなので反論をして、翌日マージされました。

パッケージ登録後、1週間ほぼ毎日issueが立つ

僕の初期実装はmhagiwaraさんのを参考に、割とベタに実装をしていました。

ですが、LLっぽい書き方で書いていたため、多くのツッコミどころがあったので、最適化したらどう？的なissueがぼっこぼこ立ちました。プライベートのコードでこんなにissueもらったのは初めてだったのですごい嬉しい反面、一番多い時で夜寝る前に一個こなしては朝起きると次のissueが立ち、出社前に一つ片付けたら昼にもう一個増えるみたいな、時差をフル活用したハードな指導が始まりました。

最適化としては主に以下のような最適化をしました。

const使おう
RegexやめてCharに展開しよう
DictのkeyはCharのTuple使おう
Stringはコピーが発生するのでStringBuf使おう

日本語が読めないSGJ先生、オリジナル実装のバグを見つける

面白かったのは、途中で日本語が全くわからないSGJ先生² がオリジナルの実装にバグを見つけたところ。半角カタカナの"ｸﾞ"がUnicodeでは二文字になるはずなのに、それを考慮した実装になってないからスコアが反映されてない、という点。工藤さんにも確認しましたが、ご本人も昔のことなので詳細は覚えていないが今の実装は間違っていそうだという事を確認しました。気づいた原因は、DictのkeyをCharのTupleで表現する関係で、文字数応じた型宣言をしていたからなんです。³

実際には、日本語の中で半角カタカナはほとんど出てこないのでそこまで影響は出ませんが、ASCII圏の力を思い知らされました。なお、ここの議論で日本語知らない人に英語で半角カタカナ全角カタカナの議論をする必要があり、泣きそうでした。この頃にはPRも来ていたのですが、とか来ていたのも、今となっては良い思い出です。

SGJ先生の狙いは

「なんでこの人はこんなマニアックな日本語の分かち書きプログラムに、熱心にissue立てるんだ？」と謎に思いながら、毎日の宿題のようにこなしていたのですが、最後の課題 issueを見て納得します。

そう、ベンチマークだったのです。

おそらく、最初のパッケージ名反論の時に、「TinySegmenterは多数の言語で実装されており日本人には一般的な名前だ」と主張した時に調査し、気づいたのだと思います。

というわけで、Python実装のバグを見つけて直したり、Python3対応したり、Node.jsのファイルの読み込み方調べたりしながら、ベンチマークとりました。

その結果がこちら。(詳細は )

[2015/10/22 23:38 追記]

@repeatedly 先生が色々指摘をしてくれて、Pythonのループ回数が10分の1だったり、Juliaのコードが足りなかったり、Rubyの実装も高速化していただいたので計測しなおしました。なお、D言語でのベンチはこれからです。

JavaScript	Python2	Python3	Julia	Ruby
9.62	93.08	23.94	1.46	19.44

[追記ここまで]

JavaScript	Python2	Python3	Julia	Ruby
121.04	92.85	29.64	12.36	(933+)

メタメタした実装で遅すぎたRubyを外したグラフはこちら。

最適化をしたJuliaは確かに速いです。そして、意外だったのはPython 3.5.0の速度。Unicode周りの実装が刷新されたという話は聞いていましたが、Juliaの二倍程度に肉薄してくるとは。条件にもよるかもしれないけど、文字列処理するNLPerは3系に今すぐ移行したほうが良いのでは？と思いました。

最後に、SGJ先生はjulia-usersのMLに成果を。なんか、一人JSoCって感じですね。

まとめ

Juliaでパッケージを作ると、MITの先生が指導してくれる
Julia速いけどCharacter辛い
Pythonは3.5.0に今すぐ移行しないと！

というわけで、今後はC++やgoと比較するためにのJulia template作って比較したいね、と話しています。にもtryしたいなぁ。

12/19(土)に Julia Tokyoのが開催されます！いつもJuliaはじめて24時間枠の発表もあるので、お気軽に参加・発表しに来て下さい！

METADATAに登録しないで、githubからcloneすることもできます ↩︎
なお、ご専門は最適化の様子でNLP関係ない ↩︎
この頃には、2015年にもなって日本人がChar型のある言語を触るのしんどい心折れそうでした ↩︎

バッキバキになっていたNexus5を$40で修理した

Mon, 19 Oct 2015 01:06:18 -0700

Ingress をやるときに自転車のマウンタから飛んでしまってバキバキになってしまったNexus5。大きい画面でKindleも読みやすい！と言っていたけど、ガラスが割れてから使用率がぐっと下がっていました。

Googleプレイ版は修理するのに三万円近くするというので四万円で買った機体の修理代じゃないなと思って諦めていたのですが、ふとした事からebayで変えの液晶を探したら$40.23で売っていたので買ってしまいました。(Amazon.co.jpだと一万円くらい)

買ったのはから。注文から2週間くらいで届きました。

Amazonだとこれかな。

出版社/メーカー: エスエスケイ
メディア: エレクトロニクス

ケースを開ける道具やドライバーも付いているとの触れ込みでしたが、Y字ドライバーは含まれていませんでした。なので適当に家にあった小さいマイナスドライバーで代用。

やり方は、に書いてあるのをそのままやれば良いです。

だいたいレベル感としては、ノートPCのHDD換装くらいなのでお手軽です。

途中の新旧液晶パネルの裏側とバックパネルたち

途中最大の山場はバッテリーを両面テープから剥がす時。これは少しドキドキしました。

新しくなった画面(気泡が入ってるのは、ガラスフィルム適当に張りすぎたからです)

液晶はものによってはタッチの効きが悪くなると聞いていたのですが、今回買ったものについては特に問題ありませんでした。

先生に捧げる記事でした

PyConJP 2015に参加した #pyconjp

Mon, 12 Oct 2015 09:24:25 -0700

はじめてPyConJPに参加してきました。

スライドまとめは以下が詳しいです。techstars.jp

最近、会社ではJupyter notebookの伝道師として振る舞っており¹ 、その結果として空前のpandasブームを巻き起こしました。データ分析/機械学習といえばPythonだよね、というのは、pandas-tdを契機に使い始めてからかなり傾倒しています。²

そんなpandas周りの話やデータ分析の他社事例が聞ければと思って参加したPyConですが、想像していた以上に参加者のdiversityを感じました。海外からのスピーカーや参加者も多く、Ruby Kaigiのような国際カンファレンスに近いなという印象を受けました。また、スタッフや登壇者含め会場の女性の割合が高いため、PyLadiesの効果が出ているんだろうなーという印象を受けました。もしかしたら、RailsGirlsよりもPyLadiesの方が範囲が広いからコミュニティとして長く続いていくのだろうか、とも思いました。

さて、参加して聞いた発表の中でも特に面白かったものを抜粋しようと思います。

pandasによるデータ加工時の注意点やライブラリの話

from

pandasのDataFrameは便利だけど中のデータが保証されないから辛かったので、作ったよというさんの話。 JSON schemaっぽいなと思いました。

Daskの話とpandas internal

speakerdeck.com speakerdeck.com

pandasとDaskのコミッターであるさんの発表。 pandasはSciPyの10倍以上のCythonの塊であるとかCategorical Value³ を使ったほうが速くなるよとか、pandasの速度出すためのtipsや背景がしれたのは良かったです。また、データ量が増えてきたらDaskのDataFrameを使うと並列処理できるよ、というのも知っていたけどマイクロベンチとともに提示されると使って見たい気持ちが高まりました。

この2つの発表だけで元が取れた感じがしました。

Pythonで作って学ぶ形態素解析

from

IPADICを使って、pure pythonで実装されたMeCab互換の形態素解析器janomeについて、作者のさんが丁寧に解説してくれました。特にFSTの話はなるほど、図解が分かりやすく良かったです。ただ、いつもフォントサイズが小さいのはなんでだろう…。

なお、janomeの話聞いて帰ってからテンションが上がったので一人sprintしてを作ってしまいました。

アドネットワークのデータ解析を支える技術

from

Voyage groupでこの夏さんのデータ解析チームの話。

特に、14ページ目の広告の広告主、メディア、オーディエンス、Voyage groupのプレーヤーに応じた4つの取り組むべき問題が分かりやすかったので引用します。

from

また、BigQuery版のpandas-tdであるの存在が分かったのも収穫でした。VoyageさんでもJupyter notebookをリポジトリで管理して情報を共有しているとのことなので、自分の選択は間違っていなかったなという気持ちです。

雑感

はじめていったPyConJPですが、600人近くの規模を少ないスタッフで取りまとめてくださっているのは感服しました。また、参加者・発表者の diversity が高かったのも良かったです。

また、普段Pythonを使わない人としてはaodagさんのはありがたかったです。結構Webのドキュメントはバージョンばらばらで何をやればいいんだっけ、とかWheelなんで嬉しいの？とかわかっていなかったので、初心者には助かりました。

全般的にもう少し事例紹介よりもコアな技術的な話が増えるといいなぁという気もしていたのは、メインがPythonのユーザーじゃないからなのかな。

↩︎
その辺りは近々会社のブログに書こうと思っている ↩︎
DataFrames.jlにはない！ ↩︎

IIJmioの「おうちでナンバーポータビリティ」使って自宅でMNPした

Thu, 08 Oct 2015 14:00:00 -0700

IIJmioのファミリーシェアプランにSIMを追加する際に、9/16に始まっていた「おうちでナンバーポータビリティ」を使ってみました。

www.iijmio.jp

おうちでナンバーポータビリティの流れ

IIJmioあるあるなのが、ドキュメントがしっかりしていなくてやり方がいまいち分からないという問題があったのですが、流れとしては以下のとおりです。

旧キャリアにMNP番号発行以来をする
IIJmioの申し込みをする
翌日simが届いたので、所定の電話番号に電話をかける（24時間自動応答）
数時間後にSIMが開通している

IIJmioのファミリーシェアプランに音声通話プランを追加するときには、免許証などの身分証明書がいるのですが、 iPhoneのカメラで取ったものをそのままアップロードするだけで済みました。スムーズに行けば全工程2日くらいです。

一番時間がかかったところは、ソフトバンクでMNP番号を発行するところでした。非常にお手軽なので、SIMの受け取りさえできればビックカメラみたいな店頭でのMNPはいらないなというように思います。

以下から申し込んでもらうと、2ヶ月間10％データ量が増えますので、よろしければどうぞ。

www.iijmio.jp

注意：複数のミニマム・ライトプランをファミリーシェアプランにして、更にMNPでSIMを追加するのは面倒

我が家のSIMの構成はもともと

妻iPhone（ミニマムプラン）
自分Nexus5（ミニマムプラン）

だったのを、

妻iPhone（ファミリーシェアプラン）
自分Nexus5（ファミリーシェアプラン）
自分iPhone（ファミリーシェアプラン、MNP）

としようとしました。

しかし、このページで3月ぐらいからずっと言われている、複数プランをファミリーシェアプランにまとめる機能は、2015/10/08現在まだ提供されていません。

そのため、二段階に分けて作業を行いました。

妻のSIMをファミリーシェアプランにする（翌月頭変更）
1と同時に自分のNexus5用のファミリーシェアプランSIMを申し込む（翌月頭SIM到着）
Nexus5のミニマムプランのSIMを解約する（当月末までに解約）

IIJmioの契約は日割り計算されないため、3のタイミングには注意が必要です。僕の場合は、解約タイミングを失敗して1ヶ月使わないSIMが遊ぶはめになりましたのでお気をつけ下さい。。。

出版社/メーカー: IIJ
発売日: 2014/12/15
メディア: エレクトロニクス

出版社/メーカー: IIJ
メディア: エレクトロニクス

番外編：iPhone6s「対応」のケースは対応していない場合がある

今回iPhone6sのsim free端末を買いました。そこで、発売前からケースとガラスカバーを手配していたのですが、ケースは失敗しました。

spigenのハイブリッド系のケースだったのですが、画面保護のためハードなバンパーが端っこ数ミリ盛り上がっていました。これが曲者で、左端を強く押す3Dタッチが全く効きませんでした。サイズの上では6s対応でも、機能の上では対応していないケースがあるようなのでご注意を。

結局僕はTPUの柔らかいケースを買ったのですが、非常に満足しています。

出版社/メーカー: エレコム
発売日: 2014/09/19
メディア: エレクトロニクス

余談ですが、ケースをしばらく買わないで使っていた5sは買取価格が6千円ほどさがりました…。売るのであれば、ケースは付けて外で長時間スマホを持ち歩くゲームはやらないほうがいいですね😇

吸盤付きお風呂スピーカーがPodcast聞くのにすごい便利

Wed, 07 Oct 2015 16:47:53 -0700

前々からBluetoothのお風呂ラジオをほしいなーと思っていたのですが、昔に比べるとかなり安くなっていたので買いました。

出版社/メーカー: Patech
メディア: エレクトロニクス

Amazonで2000円を切っているので勢い余って買ってしまったのですが、非常に重宝しています。お風呂では鏡につければ安定しますし、音量もそれなりに大きいです。

この商品を選んだ決め手は、「ロードバイクのトップチューブにもつきます」って書いてあったからなのですが、よくよく読んでみると大分無茶してる使い方でした…。¹

一番嬉しいのが、冷蔵庫にくっつくということ。

食器を洗ったり料理をしながらPodcastを聞くことが多いのですが、iPhoneのスピーカーだと水の音などに負けて聞き取れないことが多々有りました。しかし、このスピーカーにしてからはそういう問題がなくなって安定しています。

特にOvercastでsmart speedを使っていると、sやtなどの子音がほとんど聞こえなくなってしまうため、日本語が聞き取りにくくなりがちなのですが、そういった問題もクリアできます。

肝心の音は、モノラルだけど値段に比べると少しマシかなという印象です。普通にpopsとか流しても昔のラジオっぽい雰囲気がでてよいです。

カラビナついてるから、どこかにぶら下げるのは良いかも ↩︎

MeCab.jlをJulia v0.4.0-rc2に対応した

Tue, 22 Sep 2015 19:16:08 -0700

ついに、Julia v0.4.0-rc2が2015/9/19出ましたね！ Dictの[:symbol => :value]といったsyntax sugarがなくなったりして、自分が作っているMeCab.jlでも対応をしました。

詳細はPRを見ていただければと思いますが、を使えば基本OKです。

github.com

（PRボロボロだったのであとから修正を加えました…）

bicycle1885さんのCompat.jlの解説もとてもわかり易いです。

qiita.com

なお、Juliaの複数環境の構築はsymbolic linkでjulia3, julia4, julia-devみたいなのを用意するのが良いです。 IJuliaも含めたやり方は以下に詳しいです。

qiita.com

ちなみに、Google codeが死亡したおかげでMeCabのソースがGoogle driveに移動したのですが、そのおかげでソースのファイル名を指定できないBinDeps.jlが死んだので初issueとPR投げました

github.com

Juliaの困ったときは、以下に日本語でissue立ててもらうかで聞いてもらえると良いです！（めっちゃお世話になりました）

「データサイエンティスト養成読本機械学習入門編」を読んだ

Wed, 09 Sep 2015 15:14:09 -0700

明日発売の「データサイエンティスト養成読本機械学習入門編」を著者の一人の福島さん( )にいただきました。きっかけは、福島さんが「機械学習ソフトウェアの外観」という特集でJuliaの紹介をしていただいたからでした。

作者: 比戸将平,馬場雪乃,里洋平,戸嶋龍哉,得居誠也,福島真太朗,加藤公一,関喜史,阿部厳,熊崎宏樹
出版社/メーカー: 技術評論社
発売日: 2015/09/10
メディア: 大型本

この本は著者のPFI比戸さんが自身のブログでも描かれているのですが、

一般向けに機械学習を応用面から説明する記事・書籍は増えています。しかし、そこで興味を持って実際に使い始めようとすると、大学講義の教科書として用意された学部生・院生向けの機械学習入門書で理論の基礎を学ぶ以外の選択肢、具体的には手を動かすところから始める日本語の書籍が（特にR言語周辺以外では）少ないように思えました。

とあるように、対象としては最初の入門として、オライリーの「」を読んだけど、もっと詳しく知りたいがきっかけが掴めない、という人にぴったりなんじゃないかと思います。

以下に目次を書きます。ご存じの方は分かる通りとても豪華な執筆陣です。データサイエンティスト養成読本シリーズの中でも、過去最高に充実してるといえるでしょう。（そして、おそらく過去最高の厚さ！）

第1部しくみと概要を学ぼう！

特集1 機械学習を使いたい人のための入門講座…… 比戸将平

特集2 機械学習の基礎知識…… 馬場雪乃

特集3 ビジネスに導入する機械学習…… 里洋平・戸嶋龍哉

特集4 深層学習最前線…… 得居誠也

第2部手を動かして学ぼう！

特集1 機械学習ソフトウェアの概観…… 福島真太朗

特集2 Pythonによる機械学習入門…… 加藤公一

特集3 推薦システム入門…… 関喜史

特集4 Pythonで画像認識にチャレンジ…… 阿部厳

特集5 Jubatusによる異常検知…… 熊崎宏樹

個人的に特におすすめなのが、第1部比戸さんの特集1「機械学習を使いたい人のための入門講座」と馬場先生の特集2「機械学習の基礎知識」、第2部福島さんの特集1「機械学習ソフトウェアの概観」です。この3つの特集を読むと、機械学習の歴史的な流れから基礎的な概念、そしてどのようなライブラリが存在するかがコンパクトにつかむことができるでしょう。

ただし、特集2は大学の学部生が読むのにちょうどよい感じの数式が出てくるので、数式が苦手な方は豊富な図とそのイメージをつかむ程度で、まずは良いかもしれません。

この3特集を読んだ上で、他の好きな特集をつまみ食いする、というのが読むのに楽かなぁと思いました。

この本の内容自体は、僕自身は知っていることも多かったのですが、普段あまりscikit-learnを使わずにRや素のlibsvmなど他のフレームワークで機械学習をしている人にとっても、「今どきの機械学習のフレームワークが交差検定やグリッドサーチなど何を標準で提供しているのか」、そして「今どれを選ぶのが良いのか」、ということを見つめなおす材料としてとても良くまとまっていると思います。

また、いきなり流行りに乗ろうとして「」や「」を買ってしまって積んでしまった人にはこちらの本で入門するのが良いと思います。初級者から中級者に向けて書かれた良書だと思います。本書が機械学習入門の羅針盤となることでしょう。

#tqrk09 で Accept LT してはじめての Gem をライブリリースに失敗しました

Sun, 30 Aug 2015 14:10:51 -0700

Tokyu Ruby Kaigi 09 でAccept LTのトリで話しました。 3分だってのに盛りすぎ、かつDEMOで接続が悪くなるという前回もあった失敗を重ねてはじめてのGemをライブリリースすることに失敗しました。

なお、カリーヴルストは無事リリースできました。

instagram.com

レシピはクックパッドって便利なサイトを使いました。

簡単★カリーヴルスト by エスビー食品cookpad.com

その後、きちんとリリースしたので今では Macをお使いのあなたなら、

brew install kytea gem install kytea

で kyteaがRubyから使えるようになります！

kyteaはどんな子かというと、三期も放送されているという「Working」に対してきちんと読み推定をしてくれる優秀な形態素解析です。

$ echo Working | mecab Working 名詞,固有名詞,組織,\*,\*,\*,\* EOS $ echo Working | kytea Working/名詞/わーきんぐ

YAPCの間使って頑張ってSWIGの挙動を調べた結果、Ruby側で更なるwrapperを書くという屈辱を味わっていますが、おかげで、ぼちぼちな使い方ができるようになったのでよしとしています。

str = "今日はいい天気です。"kytea.segment(str)#=\> ["今日", "は", "い", "い", "天気", "で", "す", "。"]kytea.tag\_info\_of(str)#=\> "今日/名詞/きょう は/助詞/は い/形容詞/い い/語尾/い 天気/名詞/てんき で/助動詞/で す/語尾/す 。/補助記号/。 "kytea.tags\_of(str)#=\> [{:surface=\>"今日", :tags=\>[[{:tag=\>"名詞", :val=\>3.610404674503611}], [{:tag=\>"きょう", :val=\>1.0726515803715995}]]},# {:surface=\>"は", :tags=\>[[{:tag=\>"助詞", :val=\>3.5500698037485963}], [{:tag=\>"は", :val=\>100.0}]]},# {:surface=\>"い", :tags=\>[[{:tag=\>"形容詞", :val=\>2.5966088884369523}], [{:tag=\>"い", :val=\>100.0}]]},# {:surface=\>"い", :tags=\>[[{:tag=\>"語尾", :val=\>2.7064013574728385}], [{:tag=\>"い", :val=\>100.0}]]},# {:surface=\>"天気", :tags=\>[[{:tag=\>"名詞", :val=\>4.220721634732509}], [{:tag=\>"てんき", :val=\>100.0}]]},# {:surface=\>"で", :tags=\>[[{:tag=\>"助動詞", :val=\>2.9093304720685786}], [{:tag=\>"で", :val=\>0.99994530321086}]]},# {:surface=\>"す", :tags=\>[[{:tag=\>"語尾", :val=\>2.5160490891753264}], [{:tag=\>"す", :val=\>0.9998735552127426}]]},# {:surface=\>"。", :tags=\>[[{:tag=\>"補助記号", :val=\>3.070959942739055}], [{:tag=\>"。", :val=\>100.0}]]}]

ブログを書いて、サントリーさんの応募ハガキを投函するまでがTokyu Ruby Kaigiなので、エンドレスTokyuにならないよう頑張ります！

YAPC::ASIA Tokyo 2015参加してきた #yapcasia

Sat, 22 Aug 2015 18:27:50 -0700

初参加にして最後のYAPC::ASIA Tokyoに行ってきた。

イベント開催したい熱が高まった
コード書きたい気持ちが高まったので、Mykytea-rubyの
意外とはじめての参加でもぼっちにならずに済んで良かった

聞いた

はてなブックマークのトピックページの裏側 - YAPC::Asia Tokyo 2015yapcasia.org

個人的には、はてなブックマークのトピックページの話は資料は読んでいたけど、こんな重そうな処理どれくらいのマシンと時間で処理しているのかとか聞きたかったのが聞けてよかったです。 ESのクラスターは本番とは別のクラスターで、結構メモリ積んで処理してるとことで、やはりNLP系の処理は重いですよねー、と話しました。

DeepLearning の前に知っておくことがある！再帰型のニューラルネットワークや自己組織化マップについて語ろう - YAPC::Asia Tokyo 2015yapcasia.org

1日目はまさか2つのセッションで自分が引用されるとは思っていなかったので光栄です。

@muddydixonさんのSOMの話は、大分酷いブコメを付けたので怯えさせてしまったようでしたが、その後ご本人とお話をして認知よりの人と工学寄りの人との立ち位置の違いを認識しました。ちなみに、僕自身も2000年代前半にSOMを使っていたので、ブコメは完全にブーメランでした。

Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN - YAPC::Asia Tokyo 2015yapcasia.org

@yusukebeさんの Podcastを支える技術では、機材写真が出る度にテンションがあがって、wish listに追加するというどうしようもないやつでした。自分のpodcast始めた話が引用されていたのでとても嬉しかったです。「ドメイン取得駆動開発」はとてもいい方法ですが、.fmドメインは高いので半年放送を継続出来てから買えばいいと、codelunch.fmの中の人に聞きました。

質疑応答でも補足したのですが、家で収録できない人は市民向けの会議室が安くてそこそこ静かでオススメです。（場所にもよるかもしれないけど）結構楽器の練習に使われるようなところもあるので、是非狙ってみてください。

【特別企画】YAPCあるある（仮） - YAPC::Asia Tokyo 2015yapcasia.org

YAPCあるあるの話やCONBの人の設営の話、LTで勉強会をはじめました、的な話を聞いていたら自分もまたイベントやりたいという気持ちが高まってきました。（でも、大規模なのはかなり大変なので、そのうちかなーとは思います）特に都心以外で勉強会を開催するのはとても有意義で、自分の家の側の隠れたソフトウェアエンジニアを発掘できるチャンスなので、是非やるといいと思います。

雑感

YAPCは廊下で人と話すのが楽しいということで、色々な人と話しました。そして、普段なかなか休日には書けないコードを書いたりしてはかどりました。

各所でpandas最高おじさんとして話まくっていたのは私です。（そのうち、Jupyter使ってpandas-tdとかRedshift叩く話をブログに書く）

今回得られたYAPCに関係ない知見

SWIGでRuby binding作るとstd::stringはASCIIでしか帰ってこない
Juliaでanyenvはjlenvを自分で作らないといけない

Apple Music のプレイリストを中心としたレコメンド戦略

Wed, 08 Jul 2015 15:52:00 -0700

膨大な音楽というコンテンツの海に放り出された時に、人は何をするだろうか。

今回Apple Musicをさわってみて、様々な路線から音楽との出会いをつくろうとしているな、と感じたのでまとめておく。

きっと、Apple Musicについてその辺の話がbackspace.fmで出てくるかなと思って期待していたんだけど、どちらかというと話の中心は「邦楽がない」みたいなコンテンツの内容中心だった。¹

放送中に、さんのを読んでいてなかなか良かったんだけど、更に見てみると西田さん ( ) の記事がとても良くまとまっていた。

大体言いたいことが記事に書いてあるんだけど、以下の気になった4点を補足したい。

プレイリストを中心としたレコメンドは、音楽にはあっている
曲やアーティストから展開できる「ステーション」は、YouTubeのミックスリストと同じ世界をめざしている
影響を受けたアーティスト/同じタイプのアーティストといったデータベースとしてもきっちり作ってきている
「アクティビティ」がいい感じ

プレイリストと音楽

プレイリストは「誰か詳しい人の意図したテーマ」を介してレコメンドできるので、理由が伝えやすくて受け入れやすい。

例えば、「雨の日に家で聴きたいロック集」なんてのが雨の日に出されると、「お、聞いてみようかな」って感じになる。もう一つ、楽曲がApple Musicに増える速度よりも、プレイリストが増える速度の方が速くすることができるので、変化を生みやすい。これは、毎日聞きながらLove(♡)をつけることで、どんな変化がするのか、というのを楽しむことがしやすいし、ある一定の場所にサチるのを抑えることができる。

まつおさんの話でもあったけど、Appleが金をかけてプレイリストを作りこむのは、多様性を確保するためだと思う。素人のプレイリストが山ほどあっても最終的にはマス指向の平均的なものになってしまって、何の楽しさも得られない。そういう意味では、誰かが真剣に考えた切り口＝プレイリストとして価値が大きいんだと思う。

ステーション

ステーションは、アーティストや楽曲を起点として、連続で曲が聞けるものである。ぶっちゃけ、YouTubeのミックスリストのApple Music版である。 YouTubeのミックスリストは良いんだけど、音質が悪い曲とかに行き当たることがあったり、広告動画が入ったりちょっと嬉しくないシーンも有った。けど、Apple Musicではお金を払っていい感じの曲を無限に聞くことができるわけである。

しかも、OS組込みで好みに合うか否かを★でフィードバックできるのだ。こりゃ凄い。

ちなみに、ちょっとアグレッシブだなと思うのが、アーティスト名で検索してアーティストリストに到達すると勝手にフォローする所。これは、ちょっと意図していなかったかも。

データベースの作り込み

押尾コータローと同じタイプのアーティストに、村治佳織やゴンチチを出す、みたいな、ベーシックなアーティスト間の関係性をきっちりと作りこみをしている。これは凄い。「影響を与えたアーティスト」みたいなのも用意しているので、プレイリストで「エリック・クラプトンが影響をうけたサウンド」みたいなのもできるわけだ。

ユーザー自信に回遊をさせるためだけでなく、プレイリストを作るためにもデータをきっちり作りこんでいる。天晴である。

アクティビティ

これだけでなく、シーンにそったプレイリストを用意してくれている。場所が凄いわかりにくいのだけど、Newの下の方にある。おもてなし、ドライブといった定番のものだけでなく、作業中、勉強中、失恋、目覚め、といったものまである。

こういうシーンやフィーリングに対して楽曲を提供するのは、未知の曲に出会うきっかけとしては良いと思う。プレイリストはURLを持っているので、さながらネットで共有できるラジオだ。

雑感

Apple Musicの"For You"の初期の精度がいまいちだし、邦楽少ないし微妙だなーと最初は思ったのだが、好きなアーティストが居ることがわかった瞬間にどんどんはまっていったし、そこから♡をつけることで、知らなかったけど好きなアーティストと似たジャンルのアーティストが出てきて楽しくなってきている。

プレイリストというテーマを提案するのは、これからのレコメンドでは結構重要になってくるのではないかと思っているが、それ以外にも全力で攻めてきている感じが好感を持てて良い。

この放送中の話では、初期のレコメンドの設定がBeats Musicのそれと同じらしい ↩︎

日本人向けPodcastやるならIDCFクラウドが良さそう

Sun, 07 Jun 2015 14:00:00 -0700

というpodcastをやっているのですが、の上で動いています。

tl;dr

IDCFクラウド月500円で3TBまで転送量無料なので、国内向けPodcastには便利

いいところ

安いこと。 IDCFクラウドは、一番小さいインスタンスなら月500円で使えて月3TBまで転送量が無料です。¹ ただし、この構成だと15GBのボリュームしか使えませんが、まぁpodcastのデータはたかが知れているので大丈夫でしょう。 Mackerelも無料で制限されたプランがついてきます。

あと、ちょいちょい3000円クーポンを配るので、試しに始めるのは気軽にできます。

わるいところ

料金体系がわかりにくいところです。AWSもたいがいなんだと思いますが、IDCFクラウドもよくわからないです。

僕がハマったのは、オブジェクトストレージ(S3 compatibleなストレージ)。こちらは50GB未満の保存料は無料だけど、転送量は月10GBまでしか無料でなくて、Matzに宣伝していただいたrubyist.clubはあっさり超えたので辞めました。

また、も厄介で、とろうと思った時にいくら掛かるのかパッとわからないし、シミュレータではスナップショットの「ス」の字も書いてない。おそらくアーカイブデータなのはわかるけど、この不親切さはちと厳しい。

IDCF自体の障害はちょこちょこ発生しているようですが、今のところCDNも経由してるしなんとかなっています。

録音環境

ついでですが、以前にも少しが、ソフトウェア構成が変わったので書きます。

Skype
- でバックアップ用に会話を録音
GarageBand
- 自分の声の録音および、領域のカット
- で音量調整をしてる
- yusukebeさんはlevelatorで調整しているみたいですが、こちらの方がより自分で調整できるので気に入っています

以前書いたsoundflowerは、クロックが狂う原因になることがわかったので使用をやめています。

ゲストの環境の典型的なパターンは

iPhoneで口元で録音
- みたいなアプリでwav形式で録音をしてもらう
Mac/iPadなどでSkype

という構成にしてもらっています。これは、口の近くでiPhoneを置いて録音することで、ゲインが稼げてかつ音量も安定するからです。結構キーボード叩く音とか入っちゃうんですけどね…² 。指向性のマイクを持っていない人がゲストのことが多いので、こういう方法でアプローチしています。

たしか、rebuild.fmは使ってて2~3TB無料なので、それくらいなら大丈夫かと踏んでいる ↩︎
🐸の声も入ってしまった ↩︎

pip install kyteaできるようになりました

Sat, 06 Jun 2015 10:14:41 -0700

先月のkawasaki.rbで、Rubyistなのにgemより先にPypiデビューしましたという話をしました。

from

中身は、kyteaをpipから入れられるようにしたよということですが、ちょっとsetup.pyへの恨み節も入ってます。 SWIGに対応している、実はとか、しかもそのとか…。 SWIGオワコンなんですかねぇ。

bundle gemみたいな方法が確立してないから、ディレクトリ構成もよくわからないんですよね。

kytea 0.1.0 : Python Package Indexpypi.python.org

一応、gem化も進めていますがあまり需要がなさそうなので、真面目にやっていません。

参考

Python - PyPIにパッケージ登録する - Qiitaqiita.com

Googleドライブやカレンダーの共有権限を管理するにはGoogle groupsが便利

Wed, 20 May 2015 17:37:16 -0700

ネットで調べていてもGoogle Appsの情報しか出ないので、備忘録として書きます。

Googleドライブは情報共有するのには手軽なツールなので、使っている人も多いと思います。

一方でドライブの公開範囲を公開にしておいて、出すべきではない情報が漏れてしまうということもあると思います。

そこで、今回はその解決方法としてGoogle groupsの便利な使い方を紹介します。

やり方

やり方はとても簡単で、共有したい人が参加するGoogle groupsを作成して、閲覧/編集権限をgroupsのアドレスに付与するだけです。

会社でGoogle Appsを使っている人はチームのMLを作ってそこに権限を与えたりしていると思いますが、あれと同じです。

ただし、注意点としては、ドメインへの公開がなくて全世界への公開がデフォルトであることに気をつけてください。

メリット

役割に応じてフォルダに権限を付与できるので、権限の管理がしやすい
参加希望者のメールアドレスを知らなくても、登録フォームが存在する
ログイン状態でないと見れないので、編集履歴のログが残る

1についての補足ですが、一般メンバーのグループと管理メンバーのグループなどロールによってグループを分ける事で、管理者のみ編集可能なドキュメントなどが容易に管理できます。

おまけ:Googleカレンダーで共有カレンダーも作れる

公式ヘルプにもある通り、カレンダーの共有メンバーにGroupsを設定すると、そのメンバーで共有カレンダーが作れます。

編集権限も一括で与える事ができるのでとても便利です。

以上、Google groupsの便利情報でした。

rubyist.club はじめてました #rubyistclub

Sun, 03 May 2015 03:00:00 -0700

というドメインが勢い余ってとれたので、podcastを始めました。でも話題になっていた、静的ファイルを置くためだけにIDCFクラウドにインスタンス立てて、nginx立ててっていう無駄なことをやっています。¹

もともとは、さんと神奈川Ruby会議のポストモーテムで「トークセッション人数多かったから消化不良気味でしたね」という話から、個別にお話させていただければもっと引き出せたのかもしれないという話からスタートしました。²

もう一つ考えているのが、勉強会や地域Ruby会議といったオフラインミートアップに対して、少し違ったアプローチを取れないだろうかという考えもあります。オフラインのミートアップでは、実際に会ったからこそできる話や生で受ける刺激は、他の手段ではなかなか得ることができません。

地域Ruby会議のような規模のイベントは距離や人数、日程の制約など様々なハードルを超えることで実現できるとても有意義なものです。その一方で、開催するのにはかなりのリソースをかかる割に、リーチする人は3桁程度の人にしか届きません。もう少し多くの人に届けるにはどうしたらいいだろう、と考えました。

音声podcastというメディアは、講演動画に比べてながらで聴きやすく通勤や運動、家事などをしながら聞くというスタイルが以前より増えてきている気がします。また、でも触れましたが、podcastには懇親会で親しい仲の人たちが話をするのに聞き耳を立てるような、なかなか聞けない話を聞けるというメリットもあると思っています。³

ともあれ、音量調整⁴ やらジングル作成など、はじめての事だらけで色々お聞き苦しい点もあるかもしれませんが、温かく見守っていただければ嬉しいです。感想やでのレビューもお待ちしております。ゲストのRubyistも募集してます。

うっかりnginxのバージョン上げたら、設定ファイルが壊れて今日さっきまで落ちていた。この辺いい感じに安定させたい ↩︎
miyohideさんが、podcastに出演するのにノリノリだったので始めたという説もある ↩︎
誤解なきよう補足すると、僕自身地域Ruby会議の開催には今後も携わっていきたいと考えていますし、その存在価値を否定するものではありません ↩︎
第二回はカエルの鳴き声に負けた… ↩︎

Machine Learning Casual Talks #3 (略称MLCT)やりました #MLCT

Sat, 02 May 2015 14:41:44 -0700

先日、を行いました。

久しぶりのMLCTでしたが、今回も濃密な議論が行われました。

今回、発表資料を乗せるとともに、開催にあたってカジュアルとは、何故始めたか、を改めてお知らせしたので、それをこちらにも書いておきます(次回は募集ページに書こう)

発表資料

from

まさか、Hivemallのユーザーと開発者が同じ場所で発表するとは思っていませんでした。

[LSTMで話題分類]( john_smith /lstm “LSTMで話題分類”) from [__john_smith__]( john_smith )

でLSTMやろうとしたら、ドキュメントなさすぎてうまく行かなかったというお話でした。補足記事も上がっています。

RNNこれくしょんでLSTM使おうと思って失敗した話をMLCTでした - Java Coffee Cafejohn-smith.hateblo.jp

カジュアルとは

さんのこれをみてください。

AWS Casual Talks#1 で説明したカジュアルとはを再掲

— con_mame (@con_mame)

これだけでは、わかりにくいと思うのですが、第一回のMLCTでさんが説明もなしにこのスライド(P.26)を流したというのがわかりやすいと思います。

from

ディスカッションをメインにするという点はTokyo WebMiningなんかも似ているのですが、ある程度の前提は知っているというつもりで話してもらっているので、突っ込んだ議論ができていると思います。

何故はじめたのか

そもそも、機械学習をWebサービスなどのシステムに組み込む上で、論文にならないけど大事な工夫が多くあると思います。そういうのどうしてるの？と皆に聞ける場所が欲しいと思い始めました。

そしたら、という、まさにという感じのWorkshopがNIPSに併催されていたりしました。( が発表されたあそこです)

募集方法について [2015/05/02 21:50追記]

こういうモチベーションなので、「これから入門したい！」という人にはお互い不幸になることが容易に想像できました。「機械学習」というとはやりの言葉として追いかけようとしている人も増えているとは思いますが、最低限を終えている人をターゲットにしたいという思いはありました。

ただ、どうすればそういう人にリーチするかという解がわからなかったのと、connpassの抽選機能はので、一度は試さないといけないなと思い、rand()の神様にすべてを託しました¹ 。

結果としては、GWに突入している人も多かったのかガチな人が多かった印象です。こちらとしてはあまり言いたくないけど、「ドタキャンした人は今後お断りする可能性があります」という事を書いておくのは大事だと認識しました。

の先着+抽選という手法や、の各種レベルの発表枠など色々方法がありそうだとは考えています。この辺、同じ悩みを抱えるであろうPydata.tokyoの人の知見を聞きたいところです。

というわけで

次回は"DevData"というテーマがいいというお話をtokorotenさん方面からいただいています。

にある通り、指名もできるが今回は運営意外は指名しなかった ↩︎

#JuliaTokyo で #juliaわからんという雑なレポジトリを立てた話をしたら julia.tokyo ができてた

Sun, 26 Apr 2015 15:25:18 -0700

を @soramiさんと @bycicle1885 さんと開催しました。

第3回にお越しの皆様、楽しい時間をありがとうございました！結論は「julia-wakalang」に質問や要望を書こう、ですかね。ひとつ書いてみました;

— Sorami Hisamoto (@sorami)

そこで、というリポジトリの話をしてきました。

from

資料にも書いたとおり、日本でのJuliaがもっと盛り上がるようにさんの「」という記事を参考にして、「こんなのがあったらな」「こういうことがわからないんだよなー」というのをissueでやりとりするための場所を作りました。

日本語のドキュメントを増やしたり活用事例を増やすのもすごく大事なのですが、実際問題わからないことをわからないと聞ける場所があるのが大事なのではないか、そしてそれは現代ならgithubのissueではないか、と思って作りました。

こういうコミュニティの議論を行う場所としては、google groupsやFacebookなんかが今は多いと思うんですが、うまくはまらない時はやりとりが活発にならないという悩みを抱えていました。

idobataやSlackなどでチャットベースのやりとりをする場所を作る方法も考えましたが、昼間チャットをチェックできない人には辛いなと思っていました。

issueならwatchしておけばMLのようにメールも飛ぶし、MLみたいに登録していない人でも議論に参加できます。

また、雑なissueとしてのdreamタグは好評で、とりあえず誰の責務でもないけど夢や妄想を書けるのって大事だよねーと懇親会で話していました。

Twitterでと書くと僕がissue立てるかもしれません。

副産物としてというorganizationを作ったら、というサイトができました。

あわせて、も合流したので、いよいよ盛り上がってきました。

Juliaの情報を増やして、もっともっと盛り上げて行きたいと思います！

Googleフォームで作った申請フォームからSlackに通知をする方法

Tue, 03 Mar 2015 16:31:31 -0800

Slackは連絡先を知っている人が参加することが多いですが、ゲームのコミュニティ等相手の連絡先がわからない場合もあると思います。(IngressとかIngressとかIngressとか)

そういう時のために申請フォームを作って、Slackに通知をするための方法をまとめます。

1. SlackのIncoming Webhookを設定する

Slackのを新規作成する。デフォルトの部屋は適当に選べば良い。

Webhook URLのURLを記録しておく。

2. Googleフォームを作る

今回想定している項目は、以下の4点

紹介者名
名前
あなたのG+プロフィールページ
メールアドレス

3. Slack通知用のスクリプトを作成する

フォームのツール -> スクリプトエディタを開く

通知するためのコードを書く。以下の例では、public channel(#public_notify)にメールアドレス以外の情報を、private group(private)にすべての情報を通知しています。

urlのところには先ほど取得したWebhook URLを設定します。

function sendToSlack(body, channel) { var url = "https://hooks.slack.com/services/XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX"; var data = { "channel" : channel, "username" : "invitation bot", "text" : body, "icon\_emoji" : ":gohst:" }; var payload = JSON.stringify(data); var options = { "method" : "POST", "contentType" : "application/json", "payload" : payload }; var response = UrlFetchApp.fetch(url, options); } function test() { sendToSlack("It's a test message", "#public\_notify") } function onFormSubmit(e){ var body = "公開版申請が来たよ\n"; var introducer = ""; var applicant = ""; var plusUrl = ""; var itemResponse = e.response.getItemResponses(); for (var j = 0; j \< itemResponse.length; j++){ var formData = itemResponse[j]; var title = formData.getItem().getTitle(); var response = formData.getResponse(); body += "【" + title + "】\n"; body += response + "\n\n"; switch (title) { case "紹介者名": introducer = response; break; case "名前": applicant = response; break; case "あなたのG+プロフィールページ": plusUrl = response; break; default: break; } } var bodyPublic = "@" + introducer + "さ〜ん\n" + applicant + "さんがお呼びよ！\n"; bodyPublic += "確認したら「" + applicant + "さん確認しました！」と発言してね\n【Google+】" + plusUrl; sendToSlack(bodyPublic, "#public\_notify"); sendToSlack(body, "private"); }

Slackへの通知が動くかどうかは、test()を実行してみると良い。

最後に、フォームが送信された時にこのスクリプトが動くようにonFormSubmit()のトリガーを設定します。

このとき、スクリプトからドキュメントへのアクセス権限を求められるので承認します。(これがないと、設定できない)

なお、デバッグの時は最後の通知に今すぐという設定を追加するとエラーが分かりやすくなってよいです。

うまくいけば、こういう通知がでることになります。

参考URL

#ingress のpodcast「水やり通信」を始めました #mizuyari

Thu, 19 Feb 2015 16:45:18 -0800

こっそりと、いつぞやのを仕掛けたBersergaさんとingressニュースを紹介するpodcastを始めました。

水やり通信

Michiaki Ariga
ゲーム／趣味
¥0

Ingress専門のPodcastなんて国内にはないだろう!?と思って始めたのですが、アイデアを思いついた頃は他のpodcastは存在していなかったけれど、昨年12月からさんが始まっていました。

地域Rubyコミュニティpodcastをやる前の素振りとして始めたのですが、プロの方にポスプロをしていただいたりジングル作っていただいたりと超展開になって嬉しい限りです。

イメージとしてはのingress版があってもいいかな、というのが発想のスタートです。 Ingressの情報って大抵がGoogle+から流れてくることが多くて(それを他のblogが広げている)、もうちょっと多くの人に中で何が起こっているのか伝わるといいなぁという想いもあります。

本当は青も緑も両方楽しめる番組にしたいのですが、ツテがあったのが自分と同じ青の人だったので、少しそちら側に偏っているかもしれません。是非、緑の方もお便りやゲスト出演をお待ちしています。

隔週くらいのペースを目指してゆったりマイペースでやろうと思いますので、よければ購読してみてください。

録音環境

Software

ソフトウェア的な構成は前のエントリで書きました。

ただ、この構成少し無駄があったり複雑だったりする(LineInは2つもいらなさそう)ので、次回はmiyagawaさんおすすめのを使ってシンプルにしてみようと思います。

今回は、Bersergaさん側もダイナミックマイク用意したりしていたのですが、途中のケーブルがダメだったので、急遽iPadでskypeをしました。

音質的には、まぁまぁ聞くには耐えるくらいかなと思いますが、ポスプロが大変だったとのことなので、次回のSkype録音はそれぞれが録音するスタイルにしたいと思います。

僕もそうしてます。Skypeは参照＋バックアップで、各自ローカルでとったものをマージ (double ender) です

— Tatsuhiko Miyagawa (@miyagawa)

HardWare

大昔に多重録音向けに買った機材が役に立っています。

マイク: BEHRINGER XM500
AudioIF: m-audio fast track usb
卓上マイクスタンド
マイクケーブル

出版社/メーカー: BEHRINGER
メディア: エレクトロニクス
購入: 11人クリック: 47回

出版社/メーカー: M-Audio
発売日: 2004/11/20
メディア: Personal Computers
購入: 3人クリック: 7回

出版社/メーカー: KC
メディア: エレクトロニクス
購入: 28人クリック: 80回

今は、ニコ生や歌ってみたなどのおかげで、個人向けのオーディオインターフェースのエントリーモデルが増えてきたので、こういうのもいいかもしれません。

出版社/メーカー: BEHRINGER
メディア: エレクトロニクス

ダイナミックマイク二本使う場合は、これが一番安価で手軽そうです。

出版社/メーカー: Steinberg
発売日: 2010/08/02
メディア: エレクトロニクス
購入: 1人クリック: 17回

サーバー側の環境

Github pages + octopress

Github pages

kozytyさんののですが、音声ファイルはGithub pagesに置くのが良さそうです。

これは、podcastがいつまで続くかわからないので、最初はできるだけ無料で済ませたかったのですが、今はなようなので、CDN使ってそこそこの速度で使えているんじゃないかなと思っています。

feedburner

購読者数などの統計情報を把握するのに、feed.pressがよく使われます。しかし、去年の夏頃にfeed.pressが全有料化したので、今回はfeedburnerを使いました。

元となるfeedは、を使って生成しています。

ハマりどころ失敗したところ

Show notes

rebuild.fmのようなリンク付きのshow notesを表示させるためには以下の情報が参考になります。

条件としては、``entityの中の

``を使わない
``を使う
descriptionの中身のXMLをescapeする

の3条件を満たす必要があります。

今回、feed burnerを使っているのですが、設定の途中で"I’m a podcaster"みたいな選択肢を選ぶと"SmartCast"というオプションが選ばれます。しかし、これを選ぶとfeedburnerがitunesタグを勝手に付与しようとします。今回はJekyllのtemplateで生成するデータの方を使いたいので、下記の画面でSmartCastのチェックを外し停止します。

スクリーンショット 2015-02-19 23.43.57.png

しゃべりかた

早口になるのでゆっくりしゃべる
相槌は基本打たない

特に後者はpodcast独特ですが、ラジオ番組とかでも相槌って基本打たないんですよね。結構我慢してる。これは、話者だと気にならないんですが、第三者として聞いていると邪魔なんですよね。情報量がない。なので、相槌は我慢した方が良いです。

iTunes storeの登録

iTunes storeの登録はすぐに出来ると謎の勘違いをしていましたが、1週間弱は承認までに必要です。水やり通信の場合は4日かかりました。

最後に

今回のpodcastを始めるにあたって、のさんやのさん、のさんには、色々アドバイスとモチベーションをいただきました。ありがとうございます。

地域Rubyコミュニティ podcast の方も近々始めようと思いますので、そちらもお楽しみにして下さい :)

word2vec可視化するやつをipython notebookから見れるようにした

Wed, 18 Feb 2015 10:45:17 -0800

オライリーから出てる、の付録についてくるさんが書いた可視化のコードがあります。

word2vecのword-analogyを可視化した - 西尾泰和のはてなダイアリー

これを、ipython notebookから扱えるようにしました。

今回ipython notebookから使えるようにしたのは、厳密には上記のコードではなくて、のコードなのですが、ある単語の周辺にある単語をPCAで2次元に縮退させて可視化してくれます。

ipython notebookに関しての説明は、過去の記事を参照してください。

同じ要領で、ベクトルの引き算をした空間の可視化の奴もできると思います。

注意点としては、MacだとBoost.Pythonがsystem Pythonに対して入れなければならず(anacondaだと死にました)、ドはまりしたことでしょうか。やはり、こうしたグラフをインタラクティブに生成するのはipython notebookの得意領域ですね

Garagebandでskypeとマイクの音を別トラックで録音する方法

Sat, 14 Feb 2015 15:50:08 -0800

最近、rebuild.fmやwada.fmを聞いていると、自分もpodcastをはじめてみたいという気持ちが強くなってきました。

試験的にskype経由でpodcast向けの録音をしてみたのですが、skypeのゲストと自分の声が別々の方が後々の編集作業が楽になるぞ、ということで以下のサイトを参考にやってみました。というか、ほとんどこの記事の日本語版という内容になっています。

用意するもの

設定

経路1
- Skype -> Soundflower (2ch) -> Soundflower (16ch)の1,2ch
経路2
- マイク -> Soundflower (16ch)の3,4ch

ざっくり全体の設定を示す画像を先にはっておきます。

LineIn

LineInは音をroutingするためのものです。

LineInはアプリ自体をコピーして2つ開きます。

1つめのLineInでは、Inputを自分のマイク(写真では内蔵マイク)、OutputをSoundflower (64ch)にします。さらに、Advanced...を開いてOutputのLeft channelを3に、right channelを4にします。

2つめのLineInでは、InputをSoundflower (2ch)、OutputをSoundflower (64ch)にします。さらにAdvanced...を開いて、Output Left channelを1, Right channelを2にします。

設定が終わったら、Play Thruを押します。

Skype

入力を、自分のマイク(今回は内蔵マイク)、呼び出し音を自分の出力(今回は内蔵出力)、スピーカーをSoundflower (2ch)にします。

こうすると、Skypeの出力がSoundflower (2ch)を経由してSoundflower (16ch)の3,4chに出ます。

SoundflowerBed

SoundflowerはMac用の仮想サウンドデバイスです。

Soundflower (2ch)をBuild-In Outputにします。こうすることでSkypeの音を自分のヘッドホンなどに出力します。

なお、64chの方はnoneのままにすることで、自分の音が遅延して聞こえる嫌な体験をしなくてすみます。

Garageband

基本的に、トラックを全部削除して、新規トラックを作成するときにSoundflower(64ch)の1/2と3/4を分けて追加します。

まず、トラック→新規トラックでSkype側を録音するためのトラックを追加します。その際に、リアル音源を選んで音源の設定を押した後、モノ1(あるいはステレオ1/2)を選びます。

同様に、自分のマイク用のトラックを追加します。先ほどと同様にして、最後の入力をモノ3(あるいはステレオ3/4)にします。

バージョン古いですが、こちらの動画も参考になります。

ちなみに

最近のiPadのマイクはそこそこ良いので、とりあえず相手が機材を持っていないのであれば、iPadかiPhoneのskypeから参戦するのも良さそうです。

で配信できるということがわかったので、最初のPodcastはJekyll(octopress)をGithub pagesで使って無料で構築することにしました。

ゆくゆくはIDCクラウドフロンティアもクーポンがあるので、そっちも試してみたいです。

神奈川Ruby会議を開催しました #kana01

Sat, 24 Jan 2015 16:41:03 -0800

去る2015年1月17日に神奈川Ruby会議を行いました。にはスライドや動画も上げましたのでよろしければご覧ください。また、るびま班が近々レポートを上げてくれるはずですので、そちらもお楽しみに。

スタッフの反省会はこれからですが、その前に自分自身で振り返ってみたいと思います。

なぜやったか

僕自身、に参加したのがはじめてのRubyコミュニティの活動への参加でした。予備知識もなく行ったのですが、Rubyの世界にもっと飛び込んでみたいと思ったのを覚えています。そして翌月からはyokohama.rbに通うようになり、kawasaki.rbを立ち上げました。

kawasaki.rbを開催する中で、RailsをやっていないRubyistに来てもらえることが結構多いなーと感じていました。また、昼間はJava/PHPで趣味でRuby書いてますみたいな人も多いように感じていました。勉強会や地域Rubyコミュニティは東京に集中しているけど、神奈川みたいな東京以外にもRubyを触っている人はいっぱいいるはずで、そういう人たちで集まってリージョナルをやると一味違った会になるのではないか、という想いが強くなりました。また、普段あまり勉強会に出ないエンプラな人たちとっても、Rubyコミュニティに参加できるきっかけになるようなリージョナルをやりたい、と思いました。そして、エンプラな人やWebな人が様々な場所でクロスする、そんなきっかけの会議になるといい、そう思っていました。

techyじゃないリージョナルRuby会議

会議中にも僕自身言ってしまったのですが、「エモいリージョナルRuby会議」だったと思います。プログラムを考える段階で、技術に触れるのはむしろペアプロだけになるな、とはわかっていましたが、あえてそういう構成にしました。ペアプロは準備をきちんとしただけあって、かなり楽しんでいただけたようで嬉しかったです。

それは、Railsという前提を持たないで、楽しんでもらうにはどうしたら良いだろうか、ということを考えた結果でもあり、はじめてのリージョナルがどういう形ならモチベートされるだろう、ということも考えていました。

高橋会長が偶然にも講演の中で「勉強会で勉強するのは思ったより効率が悪い」という話をされていましたが、それについての説明で「つながりを作ったり、疑問に思ってること/わからないことを質問したり、モチベーションを高めたりするという効果が大きい」というを話されていました。モチベーションを維持したり上げたりするのに、こういうリージョナルのようなイベントや勉強会は非常に良いという想いを僕自身持っており、面白いことをやっている人の話を聴くだけで、自分も創造的な活動をしようという気になってきました。それを恩返ししたいと思っていたのでした。

もう一つ、せっかくだからRubyにまつわる色々な立場の人を集めて、自身の言葉でエンジニア(やその先から発展したマネージャー、経営層)の考えに触れたいとも思っていました。トークセッションを中心に、「何を作ったか」ではなくて「どう考えてきてどう歩んでいるか」にフォーカスするような話をお聞かせいただきました。ソフトウェア業界の歴史自体がまだ浅く、キャリアパスについて何がベストプラクティスかがわからないという人も多いのではないでしょうか。そうしたなかで、咳さんのチームの中での帽子を発明してもいいんだよ、という言葉ではありませんが、絶対的なパスが無い中でいかに自分の道を選ぶかの事例として参考に出来る部分があれば良かったなと思っています。

技術的な楽しみは、ペアプロでやってもらえばいい、そう割りきりましたが、結果的に幅広いレベルの人に楽しんでもらえたようで良かったです。

切り捨てたもの

コミュニティのLTの時間を設けませんでした。これはあえて割り切っていたのだけれど、結構色々な方から「LTの募集はいつですか？」と聞かれました。コンセプトによるとは思うのだけど、大江戸Ruby会議のように「生活発表会」というスタイルでやるのであればLTの時間は設けても良いと思います。

ここらへん、次回やるとしたら(コンセプトにもよるけど)多分やるのかなぁと思います。

今回、yokohama,kawasakiの両コミュニティの助力を得ながら進めていったのですが、もっと協力したかった、という声をいただいたのも事実です。ですので、普段やっていることベースで表現する場所があってもよかったな、というふうに思います。

やると決めてからの流れ

前半戦

2014年の4月にはサイボウズLiveに一つ目のToDoができていました。この段階で会場にはだいたい当たりをつけて交渉を始めていました。ちなみに、日時の決定はもう少し先までかかったのですが、ShibuyaRuby会議やTokyu Ruby会議など様々なリージョナルとかぶる日程になりそうだったので、年をずらしての開催としました。

コンセプトも決めて、登壇者もこの人にお願いしたいというのを話し合いで決めて、満足して1,2ヶ月止まるということもザラにありました。

後半戦

サイトを作ったり、トークセッションの打ち合わせをしたり、Tシャツ作ることにしたり、色々ありました。

Tシャツは、アンチハラスメントポリシーを決めた段階で相談できる相手がわかりやすいのが大事であろう、ということもあり導入しました。 @ さんにはとても感謝しています。

のPaulにも色々相談に乗ってもらって助かりました。

開催当日

設営はNTT-ATさんにほぼ全面的に協力していただく形で、ほとんどお任せ状態でした。朝会をやり、バタバタしながらのオペレーションでした。(特に、1syoさんとmiyohideさんには大分助けられました)

当日、実行委員長は他に何もやっちゃいけないという当たり前のことを痛感しました。

ツール

チャットにはFacebook Messengaerを使い、タスク管理にはサイボウズLiveを使いました。今どきだったら、Slack+Github private repoなのだとは思うが、2014/2とかの段階ではまだSlackという選択肢をあまり考えられていませんでした。

特に我々のコアスタッフの中にはGithubが社内proxyで阻まれている人がいたため、モバイルアプリが安定していることと、Githubのprivate repoはお金がかかるため、プロジェクトが終わった時に削除するとデータもアクセスできなくなるというデメリットが発生します。あと、サイボウズLiveについては、一元管理ができるという期待を持って使っていました。実際には通知周りや検索、モバイルアプリの辛さが重なりました。

結局は一覧・検索性の高さが大事で、それが担保されていなければ一元管理した所で意味が無いと気づいたのはもう色々やり始めた後でした。

今やるなら、Androidアプリも安定してきたこともありSlack+Google Docsでの共有で進めると思います。Google DocsはGoogle groupsでメンバー管理をすると、グループに対する権限のコントロールが簡単になります。ただし、緊急の時のためにFacebookでつながっているとMessengerで電話がかけれるのでおすすめです。

ちなみに、公式サイトは既に立ち上がっていたkawasaki.rbにのっかる形でJekyll in Jekyllにしました。(かなりハマりどころが多くて同一orgに二個サイトは辛かった)

感想

はじめての実行委員長業務で不慣れな中を、色々と手から溢れることをスタッフの仲間に支えてもらってなんとか走り抜けることができました。

個人的には、お話いただいた講演はどれも想像していた以上に、Rubyistとしてソフトウェアエンジニアとしてどう進んでいくべきかという考える種に富んでいた内容で嬉しかったです。

特に高橋会長の「文化としてのRubyを広めていく」という話を聞いて、まさに自分がこの会議でやりたかったことだとうのを再認識させられました。Rubyが良い理由は様々なところにあって、「Gemfileやbundler便利じゃん、なんでこの言語にないのよ？」って気軽に展開していく様とか、当たり前と思っているところが実はRubyの文化を背景にしているからなんだなぁと振り返っていました。

あと、気づけば31歳になっていたので、miyohideさんが「コミュニティ活動していて嬉しかったこと」としてあげていた、例のリストを共有して終わりたいと思います :)

非エンジニアのコミュニティにSlackを導入した話 #ingress

Thu, 15 Jan 2015 17:10:49 -0800

普通の人達¹ の集まりである、Ingressの地域コミュニティでSlackを導入してそろそろ3ヶ月になったので、知見を書こうと思います。

Ingress内でのコミュニケーション

Ingressではゲーム内のチャットはcommと呼ばれるものがありますが、ほとんど使われていません。

その理由は主に2つあります。

commは行動ログが流れる中でメンションができるというスタイルをとっているため、特に関東圏では流れるデータ量が多すぎてiOS版のcommはフリーズの原因として嫌われている
全体公開のチャットと自陣内のチャットとがタブ一つ隣り合わせのため、うっかりチームチャットを公開してしまう事故が多発する

そこで、多くの場合はGoogleアカウントとの親和性の高いGoogle+での広い地域のコミュニティ² と、地元の地域チャットとしてHangoutの組み合わせで使われてきました。これは、どうも国内だけの話ではなく、台湾ではLINEが使われるなど別のチャットサービスが使われることで、ゲーム内チャットの代替を果たしてきました。

特にHangoutでのチャットはゲームに対するモチベーションの向上に大きく寄与しており、一人だとめげそうでも仲間と一緒に活動を報告しあうことで継続してプレイをする気が増します。

これらのことから、Ingressは。

Hangout to Slack

日本のIngress人口は、iPhone版の登場と同時に爆発的な人口増加をすることとなります³ 。2014/12に開催された公式イベントDarsana Tokyoでは5000人を超える参加者が参加したと言われています。

しかし、プレイヤー人口が増えるとHangoutでのチャットが辛くなるのです。もともとHangoutはLINEなどと似たような指向のメッセージングアプリのため、グループチャットが100人以上参加できないという制約があります。従来、Hangoutの人数の上限に達したらどうしてきたかというと、地域を細かく分割して再配分をするという方法で対処してきたのですが、その周期がどんどん短くなってきていました。

そこで、職場の人たちと使っていたSlackの導入を提案してみました⁴ 。

昨今ではと言われるSlackですが、実はあのTim Brayも、Ingressの地域コミュニティのツールをHangoutからSlackに移行していたようです。

先ほどのTim Brayの記事にもありますが、Hangoutは以下の様な辛さがありました

100人以上のチームを作れない
エージェント名(ゲーム内の名前)とGoogle+の名前の対応付けが困難
PCからの利用が辛い
大人数のチームに複数所属していると、アプリがしょっちゅうクラッシュする
iOSにはデフォルトで入っておらず、招待の許可を緩めないと招待されたことに気づかない
参加者をbanできない
APIを使うのがハードルが高い
ビデオ通話を誤爆する

Slackの強み

SlackはIRCの系統の色が強く、チャットをするためのツールです。なので、SlackではHangoutと比較して以下のようなことができます。

エージェント名を表示名にできる
ユーザに対するメンション
メッセージの編集、削除ができる！
チャンネル毎に自分の未読まで戻りやすい
通知の制御(HangoutだとチームごとにON/OFFしかできないが、all/mentionのみ/なし、がチャンネル単位で選べる)
botやIFTTTなどとのインテグレーションが簡単にできる
検索が便利
チーム内のチャンネル(部屋)の移動コストが低いので、チャンネルを気軽に作れる
PC側のアプリ/Webアプリが優秀

特にチャンネルの作成/捨てるコストが低いので、皆思い思いのチャンネルを作っています。特に人気なのは飯テロチャンネルで、地元の人達がおすすめのご飯やさん情報や🍶情報が、写真とともに流れてきてとても便利です。

Slackは無料だと保持・検索できるメッセージ数が1万件まで、インテグレーションの数が5つまで、という制限があります⁵ が、普通に使うぶんには特に問題は感じていません。

非エンジニアの人へ普及するために

私達のようなソフトウェアでご飯を食べているようなエンジニアにとっては、こういった新しいツールはあればほっといてもどんどん使って行きます。逆に、そうでない人も多く参加するのがIngressの面白いところです。高校生からまで幅広い層がいたりします。

そうした人の中には、Hangoutの使い方もよくわからないという人も結構います。また、英語のソフトは全くダメ！という人も多くいます。そう、Slackはすべて英語なのです。

PCのブラウザだと丁寧なチュートリアルがあるのでだいぶ楽ですが、モバイルアプリだと写真の設定のために、ブラウザの設定画面開かないといけないなど結構不親切です。

こうした問題をクリアするために、有志が丁寧なスクリーンショット付きのマニュアルを作り共有することで、敷居を下げる努力をしてくれています。

余談ですが、変化の激しいWebサービスのマニュアルを更新し続けることはかなりしんどいです。自分も普段はWebサービスの提供側なので、ドキュメントを追従し続けるのは結構辛いのはわかっていますが、丁寧にマニュアルを作ってくれたコミュニティの仲間には頭が上がりません。

このドキュメントは、同陣営の他のSlackへも利用してもらえるように横展開しています。

さらに便利にするための工夫

Welocomeメッセージのような定型文bot

slackにはslackbotという、キーワードに対して定型文を返すbotがいるため、新規参加者に対するテンプレなんかをこれで提示するようにしています。最近では、slackbotは改行した文を出力できないため、Google Driveの特定のドキュメントを取得して、welcomeメッセージを出すbotも出現しています。

Google Driveの共有フォルダ

Google Driveのフォルダに対して、Google groupに権限を付与するとそこに参加しているgroup全員が読み書きできるようにしています。そうすることで、ファイルやディレクトリ単位での権限を人単位でコントロールすることが無くてかなり楽です。

ちなみに、当初はesa.ioでドキュメント共有をしており評判も上々だったのですが、ゲームのコミュニティではお金を捻出できないため諦めました。

参加申請処理のための部屋

我々は、参加申請のためのGoogleフォームを用意して、そのメールをIFTTTで特定のprivate groupに通知するようにしています。こうすることで、特定の人だけが参加申請処理をすることなく負荷分散を図っています。

気軽にいいねをするために

というのを入れています。

気軽なポジティブ・フィードバック好き - yoshiori.github.io

chezou++

みたいな感じで書くとスコアが加算され、誰かを簡単に褒めることができて便利です。

Ingressコミュニティでの多様性と化学反応

普段自分がいるのは会社や勉強会だとRuby界隈の人が多いのですが、Ingressという軸で集まっていると、様々なスキルセットの人が集まってきます。自宅に24Uのラック設置している人もいたり、普段なかなか会えない感じの面白い人がいます。言語的にもPHP、Java、Python、JSなどいろんな人達が自分の得意な言語でサクッとbotやウェブアプリケーションを実装しています。⁶

趣味のプログラミングは、自分の作りたいもの、やりたい事をいかに見つけるかが大事だと思うのですが、こういうゲームコミュニティでのツールやアプリづくりも直接的なユーザーの顔を想像しながら開発ができるので楽しいです。また、普段あまり触らない言語でも共同で作業するためにさわってみようかなーという気になるので、新鮮な気持ちで色々作ることが出来ます。

コミュニティの形成

コミュニティの人数が増えてくるということは、盛り上がる反面、トラブルが起こったりすることも増えるかもしれません。

ちょうど、Team Geekを読んでいた時に、このHRTの考え方はゲームのコミュニティでも十分生きるなと思っていました。以下にしてIngressに集中できる環境を作るかが、コミュニティ形成で大事なことになります。仲間内でのつまらないいざこざは、時間とエネルギーの無駄になるので、スムーズなコミュニケーションが出来る場を作れるようになっていきたいです。

Art of Communityもコミュニティ運営に非常に役に立つとさんから勧められているので、読んでみようと思っています。

作者: Brian W. Fitzpatrick,Ben Collins-Sussman,角征典
出版社/メーカー: オライリージャパン
発売日: 2013/07/20
メディア: 単行本（ソフトカバー）

作者: Jono Bacon,渋川よしき
出版社/メーカー: オライリージャパン
発売日: 2011/05/26
メディア: 大型本
購入: 38人クリック: 1,022回

追記

[ ]

slackについてはよく知ってるので、それよりも非エンジニアの人から見た感想がきになる

さんからコメントいただいたので、少しメンバーに聞いてみました。ざっくりとした感想というよりは、良い/悪いを聞いてしまったのでもしかすると気になっている所とずれているかもしれません。

女性の方

slackのここが良い→英語だけど、画面を見るだけで大体の機能がわかる。分かりやすい。

ここが辛い→スマホからだと@名前と入力し辛い(予測変換で名前が出ないので長い名前だと打ち間違える)、連続して違う発言をすると文章が前後でくっ付いてひとつになって読みにくいとかでしょうか

チャットはHOのようなセリフのコマ画面？が出る、出ない、というので話しやすさが違うなーとは感じますが、慣れました（笑）

(この方は、半角スペースを入れないと補完されないということに気づいていないようでした)

男性の方

slackのここが良い→チャンネル設定や出入りが自由にできる。

ここが辛い→スマホアプリだとハングアウトの絵文字が使えない

男性のWebデザイナー

絵文字追加できるのが良い

発言の削除・編集ができるので事故が減った

スマホでは絵文字の名前がわからないと呼び出せないのが辛い。

スマホでは参加チームが多くなった時の切り替えが多少面倒臭い。

LINEのようなスタンプが無いｗ

画像投稿の画像を拡大したい時、スマホではワンクッション入るのが面倒。

男性の方

slackはandroidからだと絵文字が小さくて何なのか見えない。あとやっぱ一般的に英語なのがたぶん壁(一番高い)。

検索できるけど、すぐなくなる

アイコン画像を拡大したい衝動にこたえてくれない

HO=Hangoutです。結構Hangoutに慣れている人が多く回答してくれているっぽくて比較が多いようですが、英語だけど苦にならないという人と、英語だから辛いという意見が割れているのが興味深いです。逆に言うと、それ以外の点では複数チーム切り替えとかの難点を除けば受け入れられているという印象です。我々はMacアプリを前提に考えてしまうのですが、モバイル・アプリのみの人やWindowsの人もいるため、そこら辺もケアしながら進めるのが大事ですね。特にAndroidアプリはiOSに比べて足りない要素が多いので、今後に期待です。

プレイスタイルが廃人な人たちもいるけど、そういう意味とは違う ↩︎
例えば ↩︎
私自身もiPhoneで始めた口ですが ↩︎
どうも聞いてる感じだと日本のIngressコミュニティの中でも、最初期にSlackを導入したのかもしれません ↩︎
2015/01/15現在 ↩︎
個人的にはPHPの人とこんなところで共同作業するとは思っていなかった ↩︎

Docker上にnbviewerを立ててiruby+Nyaplotで描いたグラフを共有できるようにしてみた

Sat, 10 Jan 2015 19:19:31 -0800

昨年末にでも話題になった、RubyのライブラリMikonとNyaplotで生成したグラフをipython notebookとして社内のGHEでも共有することを目標に、をlocalのdocker上で立ててみました。

ちなみに、1/10のyokohama.rbでモクモクした成果です。

(今回は手元で検証したため、Macでdocker環境を構築しています。GHEでの検証までは行っていません)

nbviewerとは

皆さん、はご存知でしょうか？

ipython notebookは以下の特徴を持ちます。

対話的に書いたコードと実行結果が描画されて、それを保存できる
markdownも書ける
nbviewerを使えば、notebookが共有できる！
Python,Ruby,Juliaが対応している

Rubyの例ですがTokyu Ruby会議で発表したスライドを貼っておきます。 kawasaki.rbではipython notebookで。

from

これだけだと魅力がわかりにくいと思うので、実行結果を貼ります。描画したグラフも共有できるのが大きな魅力だと思います。

もしかすると、Gunosyの粟飯原さんがをご覧になった方もいるかもしれません。

また、Mining the Social Web 2nd Editionがを用意していたりします。(コードの教育にも向いていると思います)

この、ブラウザで手軽にipython notebookの結果を見れるようにしているのがnbviewerです。githubで公開されているレポジトリやgistなら特に問題なく静的に再現してくれるのが特徴です。 nbviewerのいいところは、Python, Ruby, Juliaの実行環境がなくてもjsonをレンダーしているだけなのでブラウザで表示できることです。

便利なnbviewer+ipython notebookですが、社内のGHEに使いたい場合は自分でnbviewerを立てなければなりません。そこで、今回はnbviewerを手元のMacとboot2dockerで動かしてみます。

Macでdocker

Macではを使ってVirtualBox上にdockerの環境を立てます。

brew install boot2docker boot2docker init boot2docker up

もしboot2docker initに失敗したら

自分の環境のVirtualBoxは古かったので、途中でこんなエラーがでました。

error in run: Failed to initialize machine "boot2docker-vm": exit status 1

を見ると、VirtualBoxのバージョンが古いとダメなようなので、VirtualBoxをアップデート後に

boot2docker delete boot2docker init

で無事起動しました。

Jupyter Notebook Viewer

Dokcer上でnbviewerを動かすには、用意されているdocker imageを使えばよいです。

基本的には公式に従えば大丈夫です。

基本的にgistやgithubのレポジトリに置いたipynbを表示するのに使うので、予めgithubでapi tokenを取得しておきましょう。

docker pull jupyter/nbviewer docker run -p 8080:8080 jupyter/nbviewer -e 'GITHUB\_API\_TOKEN=YOUR\_API\_TOKEN'

nbviewerを起動する

open http://$(boot2docker ip 2\>/dev/null):8080/

これで、あなたのブラウザにdocker上のnbviewerが見れるはずです！

以下のURLを入れて試してみました。

Nyaplot 3Dのグラフはマウスでグリグリ動かせるので楽しいですね。

RubyのMikon+Nyaplotで可視化

さて、Mikonとd3.jsを使ったiruby上の可視化ライブラリNyaplotを使って可視化してみます。

MikonはRubyにおけるpandasのような位置づけで、表形式のデータ操作が得意なライブラリです。いわゆる、Rで有名ながRubyで扱えるようになります。 NyaplotはJuliaでいうところのGadfly的な位置づけで、グラフの描画ができるライブラリです。面白い事例では地図の可視化とかも出来たりします。

MikonはNMatrixに依存しており、こいつがCBLASなど依存が激しくMacでビルドをするのが大変だったので、こちらも。

docker pull domitry/sciruby-docker docker run -i -p 9999:9999 domitry/sciruby-docker:latest open http://$(boot2docker ip 2\>/dev/null):9999/

今回は次のgistを可視化してみました。

nbviewerで見る場合は

こんな感じでipython notebookが無事見れるようになりました。

雑感

今回、GHEでの検証まではしていませんが、概ねGHE上のgistやレポジトリのipython notebookを描画することはできそうな目処が経ちました。

しかし、MikonとNyaplotを使ったグラフ描画は別途サーバサイドで用意する必要がありそうです。 Nyaplot自体は依存関係は薄いのですが、Mikonを使おうと思うとするとNMatrixのビルドが大変だったりするのでdocker上のiruby notebookを立ちあげなければなりません。この状況だと、手元にあるcsvなどを食わせようとした時は、dockerで立ち上げたipythonサーバにデータを移して食わせる必要があるなど、社内で普及を促すのにハードルが高い印象を受けました。

2014年を振り返って

Wed, 31 Dec 2014 14:23:45 -0800

後数時間で終わりますが、去年書き忘れていたので書いていきます。

できた

仕事
- Railsで最低限仕事で迷惑かけない程度のコードが書けるようになった
- 仕事で機械学習の知識活かしたOutput(レコメンデーション)が出来た
翻訳
- 翻訳記事だけど、はじめての ¹
- Jekyllのに参戦
- Lean Analyticsの
コミュニティ
- Machine Learning Casual Talksをはじめた。第3回も来年やりたい(お声がけはすでにしている)
- kawasaki.rb開催1年続けることができた
- Juliaと出会ってJuliaTokyoをお手伝いし始める。はじめて本を作者様からいただける機会も
- をそそのかされてはじめて、(今日ついに)完走。協力いただいた皆様に感謝
(小さいけど)LTしまくった
Juliaのpackageを3つくらい作る(gemも…
社内勉強会x3を大体完走
Ingressをはじめてドはまりする
- そこをフックにslack広めたり
- 膝を壊してチャリ通できなくなったり
- したり

やる

を無事やりとげる
kawasaki.rbの参加者の皆様のoutputの機会を増やしたい
Railsの知識を伸ばす
ElasticsearchとIngressで遊ぶ
Deep Learningで遊ぶ

振り返って

全般的に、皆様にご迷惑をおかけすることが多かった今年、来年は調和を保ちつつ技術を伸ばしていけたらと思います。特にRails関連と設計関連をまずは。

コミュニティ業務ばっかりやっているとたまに不安になるんですが、自分が楽しいことをやる、あわよくば技術で楽しさを生み出す人を増やす、そういうことができればと思っています。

はてブUTF-8に対応したからか、wordpressのはてブ数壊れてる ↩︎

社内でLean Analytics読書会を終えました

Sun, 28 Dec 2014 17:47:33 -0800

社内でLean Analytics読書会をやった

今年の4月末に、Lean Analyticsを読もうという話を氏が社内ブログで言い出したことにより始まり、5月から12月まで毎週1章を読み進めていくペースで読んでいきました。(かつまさん、ありがとうございました！) 英語の本の読書会と言っても、翻訳をしてそれを読み合わせるというよりは、皆が事前に読んできて分からなかったこと、きになったコトを話したり、内容から広がった自分たちのサービス開発の上での経験談を話して盛り上がるという会でした。

このスタイルで得られることは多く、だけではなく、社内外の様々な事例に突っ込んで議論できたのがとても良かったです。古参の人の持っている知識ってなかなか新参者には伝わる機会が少ないのですが、いい話がどんどん出てきたのが素晴らしいことでした。

Yokohama.rbのLT大会で紹介した

本の中でも特に印象に残った話をのLT大会で話してきました。

from

ここで紹介している話は、15章の"Emphathy"という章で、新規サービスで「顧客に届けるべき価値とは何か」を考える際に、

十分に厄介か、たくさんの人々に関係するか、既にそれを解決しようとしているか

という3つを考えろ、ということでした。特に、この3つ目のポイントが重要で「バラバラの靴下を履いてしまう現象は十分に厄介で多くの人を煩わせているが、それを解決しようとしている人はいるか？」という例が目からうろこでした。

自分や周りのディレクターの行動が変わった

一緒に仕事をしていたディレクター¹ と話していて変わったよね、と言っているのが「施策を打つときに、サボらず必ず指標を考えそれを追いかけるようになった」ということでした。

本書では、“One Metric That Matters"という言葉が繰り返し出てくるように、指標を一つに絞れということがよく言われます。それは、PV² のような「Vanity Metricsを避けろ」という意味でもあり、「指標はフェーズによって変わる」という意味でもあります。何故、“One Metric That Matters"が大事なのかというのを、様々な会社での豊富な具体例とともに語られるため、施策の仮説を考えてそれを表現する指標は何か？その指標がどうなったときに、どういう行動を取るか？というのを必ず考える癖が身につきました。指標は次の行動を起こすものでなければ意味が無い、というのはまさにその通りだと実感しています。

僕自身、機械学習やデータ分析が好きな人なのですが、そうした人にとっても得られるものは多くあると思うのでおすすめです。データは意志を決定するための道具であり、ビジネスはパッションとともに進めていくものである、というのは、ただの分析本には出てこないなぁと改めて思います。

翻訳レビューも参加した

できるところだけでいいですよ

— 角征典 KADO Masanori (@kdmsnr)

人生で初めて本の翻訳レビューに参加させていただきました。さんのように猛烈なレビュー³ は出来ていませんが、jekyllのドキュメント翻訳から発展してこのような挑戦が出来たのはとても貴重な経験になりました。イディオムとか回りくどい言い回しとかは、日本語にする時大変なのを改めて学びました…。

ので、是非読むことをおすすめします。

数字が苦手で本書を読むまで指標を追うのが嫌いだったそうです ↩︎
本文中では一時期2ページに1回くらい、意味のない指標だと否定されている ↩︎
一時期harupong砲がgmailの通知を爆発させていた ↩︎

Juliaでword countして気づいたこと #JuliaAC

Tue, 23 Dec 2014 16:00:00 -0800

この記事は、 24日目の記事です。昨日はでした。

悲しいお知らせですが、このブログを通じてわかったのは、Python > Ingress >>> Juliaという人気度だということでした。Ingressの話は今回しません。

当初は、Cで書かれたライブラリをバインディングする方法について書こうと思っていたのですが、r9y9さんによるが出ていたので、必要なくなったかなと思い、Juliaならではの型の話をしたいと思います。

このお話は、自分がの回答をまとめたものです。

気軽にコミッターから斧が飛んでくるのがいいですね。さすが、Karpinskiさん[^1]

Ruby脳のWord count

僕は自然言語処理が好きなので、word countをちょくちょくやります。MapReduce時代以降Word countはHello worldの代わりに急成長していると言えましょう。 Rubyでword countをするなら、Hashを使ってこう書きます

hash = Hash.new{|h, k| h[k] = 0 } words.each do |word| hash[word] += 1end

もし、閾値以下の単語を除去したいならもう一回ループを回して、判定しますが、頻度top N個の単語を取り出したいときはどうしますか？

top10個の単語を取り出したいときはこう書きます。

hash.sort\_by{|\_,v| -v}.take(10)

簡単ですね。

Juliaの世界でのWord count

では、Juliaでも同様のことをやりたくなった場合どう書きますか？ Dictをsortしたいですよね？

できないんです

julia\> sort( sort(r::UnitRange{T<:real at range.jl:531 sort sort.jl:346 range.jl:534 sort.jl:364>
<p>あれれ？調べていると、過去には<code>sort_by</code>が出来た時期もあったようなのですが、今は出来ないようです。</p>
<p>そこで考えだしたのは、DataFrameを使えばいいんじゃない！って方法</p>
<pre class="code" data-lang="" data-unlink>dict = Dict{String, Int64}("apple" =&gt; 100, "town" =&gt; 250, "space" =&gt; 24)
df = DataFrame(word = collect(keys(dict)), count = collect(values(dict)))
sort(df, cols = [:count], rev = true)</pre>
<p>でも、このDataFrameの作り方、<code>convert(DataFrame, dict)</code>で単純にできる形式と全然違うので不安ですよね。
なので、<a href="https://groups.google.com/d/topic/julia-users/uIotqx3M12g/discussion">有識者に聞いてみました</a>。</p>
<h1>julia-usersで聞いてみた回答</h1>
<p>閾値処理をしたいなら、<code>Dict()</code>作って二回ループ回せばいいし、Top　N個の単語を取ってきたいのなら、<a href="http://julia.readthedocs.org/en/latest/stdlib/collections/#priorityqueue"><code>PriorityQueue()</code></a>を使うのがいいよ、との回答でした。</p>
<p>後からsortするとo(NlogN)かかるじゃん。それだったら、最適なデータ構造を使えばいいんじゃないの、ということでした。確かに。</p>
<p>こんなコードになります。
書き方も処理速度もほとんど代わりませんね。<code>Collection.dequeue!(pq)</code>して、必要な回数だけ取り出しましょう。</p>
<pre class="code" data-lang="" data-unlink>julia&gt; f = open("input.txt")
IOStream(<file input.txt>)
julia&gt; text = readall(f);
julia&gt; function count_word(text::UTF8String)
mecab = Mecab("-O wakati")
counts = Dict{UTF8String, Int}()
for word in split(sparse_tostr(mecab, text))
counts[word] = get(counts, word, 0) + 1
end
counts
end
count_word (generic function with 1 method)
julia&gt; @time count_word(text)
elapsed time: 0.953731616 seconds (29676144 bytes allocated, 24.68% gc time)
Dict{UTF8String,Int64} with 13583 entries:
"ウィキ" =&gt; 1
"TAKE" =&gt; 2
"null" =&gt; 4
"変革" =&gt; 5
"クソ" =&gt; 1
"228" =&gt; 3
"迫っ" =&gt; 1
"村山" =&gt; 1
"寺嶋" =&gt; 1
"リビング" =&gt; 1
"国籍" =&gt; 1
"ベーコン" =&gt; 1
"出す" =&gt; 13
"Core" =&gt; 5
"当選" =&gt; 2
"moguno" =&gt; 1
"Brainfuck" =&gt; 1
"積ん" =&gt; 4
"backup" =&gt; 2
"stress" =&gt; 1
"Qw" =&gt; 1
"細かい" =&gt; 3
"従って" =&gt; 1
"括弧" =&gt; 1
"ある程度" =&gt; 1
"法" =&gt; 14
⋮ =&gt; ⋮
julia&gt; function count_word2(text::UTF8String)
mecab = Mecab("-O wakati")
counts = Collections.PriorityQueue()
for word in split(sparse_tostr(mecab, text))
counts[word] = get(counts, word, 0) - 1
end
counts
end
count_word2 (generic function with 1 method)
julia&gt; @time count_word2(text)
elapsed time: 0.891081099 seconds (24265472 bytes allocated, 20.83% gc time)
PriorityQueue{Any,Any,ForwardOrdering} with 13583 entries:
"ウィキ" =&gt; -1
"TAKE" =&gt; -2
"null" =&gt; -4
"変革" =&gt; -5
"クソ" =&gt; -1
"228" =&gt; -3
"迫っ" =&gt; -1
"村山" =&gt; -1
"寺嶋" =&gt; -1
"リビング" =&gt; -1
"国籍" =&gt; -1
"ベーコン" =&gt; -1
"出す" =&gt; -13
"Core" =&gt; -5
"当選" =&gt; -2
"moguno" =&gt; -1
"Brainfuck" =&gt; -1
"積ん" =&gt; -4
"backup" =&gt; -2
"stress" =&gt; -1
"Qw" =&gt; -1
"細かい" =&gt; -3
"従って" =&gt; -1
"括弧" =&gt; -1
"ある程度" =&gt; -1
"法" =&gt; -14
⋮ =&gt; ⋮</file></pre>
<p>型と多重dispatchがある分、なんでも同じようにできるわけではないこと、そしてそれをやるのが本当に最適手なのかを考えることができました。
なお、julia-usersは気軽に質問できてどんどん斧が飛んできて楽しいので、みなさんも読むことをおすすめします！</p>
<p>明日はkimrinさんによるJuliaで楽器を作ろう！です。楽しみですね。</p>
<div class="footnote">
<p class="footnote"><a href="#fn-23bc65e3" name="f-23bc65e3" class="footnote-number">*1</a><span class="footnote-delimiter">:</span><span class="footnote-text">本人のアイコン、バイキングの帽子をかぶっているのが有名ですよね</span></p>
</div>
</:real>

#ingress でフルタイムのプロエージェントと出会った話

Mon, 15 Dec 2014 07:20:00 -0800

この記事はの15日目の記事です。昨日はさんのでした。

Darsana参加してきたよ

頒布会戦利品の皆さん。にゃんぐれすかわいい

Darsana参加された皆さん、お疲れ様でした！ ResistanceのゆるふわA10¹ なので負けて悔しい気持ちもありましたが、初めての公式イベントに参加できてとても楽しかったです。

特に最終戦はotsuneさんと戦うことができたので(そして人数的にもイーブンの中でポータルを死守できました！)、ぎりぎりの白熱した戦いを繰り広げることが出来てとてもよかったです。

現場では本州を囲む緑の巨大CFに囲まれたものの、「我々は局地戦を淡々と行うしかないんだ」とチームで話しながら、ポータルを死守し運良く4戦全勝できました。

(写真はbungaさんにご提供いただきました)

終了後にその裏側では熱い攻防が繰り広げられていたのを後から知り、さらに胸が熱くなっています。

(写真は_かなこさんにご提供いただきました)

八丈島-台湾間、北海道-韓国間での緑のリンク、妨害のための九州-中国間のCFなど、両者の思惑が飛び交っています。そして、敵ながら本州を囲むCFが1回目の戦いの途中でできたのは天晴とも思いました。また、そのCFが崩れたのも最後の戦いの終了2分前という、熱い戦いとしか言いようがありません。吹雪の中の襟裳まで行ったamacatさんの話は読み返しても胸にこみ上げるものがあります。

コミュニティの話は表に出づらい

Ingressはプレイ=活動領域が駄々漏れになるという特性上、BlogやTwitterやFacebookでその活動を報告するのは避けられる傾向にあります。(FBにクロスファクションのコミュニティもありますが、読む専門です…)

しかし、本来ゲーム内に用意されているチャットであるCOMMは、全体チャットによく誤爆する、iOS版では東京だとすぐに固まることから、ほとんど使われていません。そのため、大きな地域ごとに存在するGoogle+のコミュニティとHangoutなどのチャットアプリケーションが活用されています。(ちなみに、台湾ではLINEが活用されているとか)

今回のDarsanaの情報共有にもGoogle+のコミュニティが活用され、様々な活動が展開されていました。また、我々のチームではHOの代わりにSlackを用いることで、Google Documentやpostへのリンク機能を活用して、情報へリーチしやすい状況を作って共有していました。 (ちなみに、HOはポジション的にはLINE的なメッセージングアプリの位置づけのためか、グループチャットとして100人までしか参加できないという悩みがあり、Slack² の方にシフトしつつあります)

コミュニティってだるくない？

世の中にはソロプレーヤーで活動されている人も多いと思います。ですが、ジョンハンケ氏の「外に出て、人と交流を」という設計思想上、一人でプレイするには壁にぶつかると思っています³ 。

Niantic Labsの創設者で、かつてGoogle Earthを開発したジョン・ハンケ氏（※本誌インタビュー記事、5月掲載）は、ユーザーに外出を促すことがコンセプトとしている。具体的には「世界が舞台」「動いて遊ぶ」「新しい視点で街を見る」「現実世界で友情を育む」という4つの要素で設計されているのだという。

「Ingressで痩せる」は本当だった、ローソンともコラボ開始 - ケータイ Watch

レベル7ポータルまでは近所に3人エージェントがいればできますが、レベル8は8人いないとできないです。プレーヤー密度が高まったとはいえ、自然発生的にP8に到達するのはちょっと大変だし、レベル8ができると壊しにくる敵も圧倒的に増えます⁴ 。

そこで、地域のコミュニティではFlash Farming⁵ を呼びかけて行ったりします。こうしたファーミングも地域コミュニティに呼びかけて、気ままに集まった人でやる、みたいなことが多く開催されます。

自分のいる地域のコミュニティは割と緩いつながり⁶ で、オンゲのチームチャット⁷ のような位置づけです。「どこどこ、P8リーチですねー」とか「今日は帰りに敵のファームよってきますー」「俺も俺も」とかわいわいやりながら盛り上がっています。

特にいいなーと思うのが、「どこどこのラーメンが旨い！」と飯テロ展開したり、「どこどこで飲んでる」とか「ここのドーナツは美味しい！」「今日はどこどこでお祭りですねー」など、長く住んでる地元民なら知っているけど別の地域から引っ越してきた人にはなかなか知りづらい地元情報がいっぱい知れて最高です。

プロのフルタイムエージェントとの出会い

今年の夏の暑い日々、地元のコミュニティでは朝から晩まで活動しているエージェントの話題で持ちきりでした。我々の中では「絶対に爺ちゃんエージェントだ」「サイボーグなのでは？」と話をしていたのですが、「今日は自分のガーディアンが壊されたー！」「うひゃー、今日はうちだー」などと毎日阿鼻叫喚でした。一番すごかったのが、猛暑日の朝6時から夕方5時までずっと活動し続けていた日があり、流石にCOMMから「熱射病には気をつけてー」等の声援をこちら陣営からも送ったりしていました。

その翌日、出勤前の時間に自分の地元のオーナーポータルを攻めている攻撃通知が来たので、文字通り朝ごはんもそっちのけでリアキャプ⁸ しにいきました。(当時の僕はまだまだひよっこだったので、攻撃通知を受けてはドキドキしたりムキーッとなっていました)。すると現れたのは、白髪のおじいちゃんがママチャリにまたがっているではありませんか。前日の一日プレイしていた時はまだ徒歩だったけど、今日リアル課金をして自転車をゲットしたので遠征しに来た、とのこと。話してみるととても気さくなおじいさんだったので、そこから仲良くなって何度か飲みに行かせていただいたりしました。

なんでも、「定年退職後暇だから家でずっとネットをしている毎日だったのが、Ingressをはじめてから毎日外で活動することになって、女房も喜んでいる」というではありませんか。これが、Ingressによって人生変わった人なのかー！と驚いたものの、「お互い碁敵みたいなものですよね。敵がいるから自分も楽しませてもらえている」という広い心に当時小物だった僕はいたく感銘をうけたのでした⁹ 。本人の、「プロエージェントになったが、毎日が充実している」という楽しく語る姿が、とても印象深く焼き付いています。(ちなみに、その方は自分がゲームバランスを崩してしまう可能性があるのを理解した上で、実績稼ぎをすすめていらっしゃいました)

さいごに

Ingressやってると、あれな人と絡まれたりすることもありますが、こういう新しい出会いが生まれるのは他ではない魅力なので、是非みなさんも楽しんでください

明日はさんの「Ingressガチ勢への道」です。

膝に矢を受けてしばらく活動休止していた ↩︎
余談ですが、我々のコミュニティでは結構年上の建設系のおっちゃんもSlackを使いこなしています ↩︎
実際、レベル8になって一人でやるのがきつくなったという仲間が結構います ↩︎
うちの近くの駅ではすぐ近くに敵が密集している地帯なので、1日と持たない日々が続いています ↩︎
レベル8以上のエージェントが8人以上集まってレベル8ポータルを作ること ↩︎
地域によっては厳しいところもあるという噂も聞きますが… ↩︎
といいつつちゃんとMMOやったことがない ↩︎
リアルキャプチャー。エージェントにリアルで会うこと ↩︎
その後攻撃通知を切った ↩︎

#JapanR で話題だった「データサイエンティスト養成読本R活用編(通称"Julia入門本")」を読みました #JuliaAC

Fri, 12 Dec 2014 16:02:00 -0800

この記事はの12日目の記事です。

昨日12/12に発売された、データサイエンティスト養成読本 R活用編をいただきましたので、読ませていただきました。

シリーズ第一冊目の「データサイエンティスト養成読本」と比較するとよりRに特化した内容になっています。

里さん、酒巻さんによる心構え的な話や基礎となる統計知識でざっと外観したあとで、
市川さんのRでのモダンな集計方法
福島さんの時系列分析の基礎
安倍さんによる.NET FrameworkからRを使う話
和田さんによるH2Oやparallelの話
さん、西薗さんによるJuliaの話

が展開されています。

表紙を見ていただくとわかりますが、「Julia入門」の文字がでかでかと掲げられています。凄い。日本の商業誌ではJuliaについて書かれた本は、おそらくはじめてだろうとのことです¹ 。

話としては、Juliaの出来た歴史的な経緯と基礎的な使い方が記されています。Juliaってなんだろう？という人には外観をしる上で取っ付き易い文章になっていると思います。特に本文中にでてくるJohn Myles White² やStefan Karpinskiなど、コアなコミッターの情報がちりばめられているのはJuliaというググらビリティの低い名前から情報を収集する重要な緒となると思います。

ここで興味をもった人は、の記事を色々読まれると良いのではないでしょうか。

Julia以外で特に興味深かったのは、市川さんによるdplyrやtidyr, pipeRの話です。特に、dplyrのSQLっぽい集計処理やpipeRでのメソッドチェーンっぽい処理を見ていると、「それ、Ruby(Active Record)でできるんやで」と一周回ってきた感覚になりました³ 。

本書は割りと濃い話が多いので、Rの入門書を読んだけど、もっとモダンな書き方をしたい！応用したい！という人にオススメです。また、Rの人たちが使い始めているJuliaってどんな言語だろう？と興味が湧いた方にもオススメです。

薄い本は既に出ています ↩︎
入門機械学習やバンディットアルゴリズム入門の著者としても知られる ↩︎
もちろん、Rで処理できるけど速度が速いことが売りですが ↩︎

Juliaのパッケージ公開はREPLからできる #JuliaAC #julialang

Wed, 10 Dec 2014 16:00:00 -0800

この記事は、の11日目の記事です。 10日目は夜道先生のでした。

Juliaのパッケージを作っても、野良パッケージを作るだけでは多くの人に使ってもらえません。 RでいうCRAN、Rubyでいうgemのように、Juliaではというエコシステムでパッケージが管理されています。パッケージはすべてgithub上ですべてホスティングされています。(だから、先日のみたいなのに巻き込まれると何も出来ません…) METADATA.jlもPull Requestベースで管理されているのですが、中身について議論されることはあまりなく、基本的に1日程度でどんどん取り込まれます。(CRANは厳正な審査がいるそうですね！)

また、パッケージをMETADATA.jlに登録すると。ちなみに、デイリーでstableとnightlyバージョンでテストがこけるととかがあります。

さて、パッケージの作り方はさんの下記のJuliaTokyo #1のスライドが詳しいです。

from

今日は、そこで検証されていなかったPkg.publish()についてご紹介したいと思います。そもそも、この発表の段階ではGithubののですが、。

Pkg.update()して(この場合は更新なので)Pkg.tag("PackageName")して、Pkg.publish()するだけです。初回はパスワードの入力とアクセストークンの入力が求められるので、 REPLに入力をしましょう。

すると、自分のMETADATA.jlがbranch切られてpushされて、ブラウザが開いてPull Requestが作られます。(自分が試した時はChromeがちょうどクラッシュしたので、手でPR作りなおしたのでもしかするとMETADATA.jlのページが開くだけだったかもしれません)

最高便利！

明日はbicycle1885さんの「PythonistaのためのJulia100問100答」です。

Japan.Rで"MeCab.jlつくってみた"を発表してきた #JuliaAC #JapanR

Sat, 06 Dec 2014 10:18:20 -0800

何故か、Facebookでさんとの話をしてたら、さんに補足されてしまったので、LT発表してきました。

の紹介と、R,Ruby,Juliaでのベンチマークについて話しました。

ベンチマーク結果を見ると、gcを切ったらRにはなんとかかっています。

当日のはこれです。ベンチマークに使用したコードはこちら

各言語のversionはこんな感じです。

$ ruby -v ruby
2.1.0p0 (2013-12-25 revision 44422) [x86_64-darwin13.0]
$ julia --version
julia version 0.4.0-dev+1752
$ r --version
R version 3.1.2 (2014-10-31)
-- "Pumpkin Helmet" Copyright (C) 2014 The R Foundation for Statistical Computing Platform: x86_64-apple-darwin13.4.0 (64-bit) R is free software and comes with ABSOLUTELY NO WARRANTY. You are welcome to redistribute it under the terms of the GNU General Public License versions 2 or 3. For more information about these matters see http://www.gnu.org/licenses/.

やる前はRに対して圧勝！とかならないかなぁとか思っていたのですが、そもそもMeCabをバインディングしてるだけじゃん、と気づいた時には甘かった。敵は、Rではなかったのです。Cだったのです…。

共有ライブラリを配布して、それをRから呼べるようにしているだけとは恐れ入りました。 RMeCabは、まさか頻度カウントをするための関数まであるとは思ってもみなかったのですが、基本的に遅くなる処理はCにまかせてしまうというのは戦略的には合理的ですね。

おまけ

会場ではきちんと言えなかったのですが、Juliaのバインディングをする上でのPros/Consはこんな感じです

Pros
- Cを書くことなくCのバインディングができる
Cons
- C++は現状(特にMacからは)辛い
- gc!
- 文字列処理が遅いかも？(要検証)

Rubyに対して遅いのは、ちょっと検証してみます。

特に「Cを書くことなく」という点は素晴らしく、 MeCabのnodeの構造体に対応するtypeを作れば、それでcastしてくれてJuliaから扱えるようになります。

からCのコードを抜粋

struct mecab\_node\_t { struct mecab\_node\_t \*prev; struct mecab\_node\_t \*next; struct mecab\_node\_t \*enext; struct mecab\_node\_t \*bnext; struct mecab\_path\_t \*rpath; struct mecab\_path\_t \*lpath; const char \*surface; const char \*feature; unsigned int id; unsigned short length; unsigned short rlength; unsigned short rcAttr; unsigned short lcAttr; unsigned short posid; unsigned char char\_type; unsigned char stat; unsigned char isbest; float alpha; float beta; float prob; short wcost; long cost; };

対応する

type MecabRawNode prev::Ptr{MecabRawNode} next::Ptr{MecabRawNode} enext::Ptr{MecabRawNode} bnext::Ptr{MecabRawNode} rpath::Ptr{Void} lpath::Ptr{Void} surface::Ptr{Uint8} feature::Ptr{Uint8} id::Cint length::Cushort rlength::Cushort rcAttr::Cushort lcAttr::Cushort posid::Cushort char\_type::Cuchar stat::Cuchar isbest::Cuchar alpha::Cfloat beta::Cfloat prob::Cfloat wcost::Cshort cost::Clong end

mecab_node_path_tは使っていないので捨てています。

Cの場合、headerに構造体を先に宣言すれば、お互いが依存する構造体を記述できますが、Juliaの場合はそれができないためPtr{Void}で受けています。

Julia環境構築 2014 ver. #julialang

Tue, 02 Dec 2014 16:05:00 -0800

3日目の記事です。

1日目、2日目の記事を読んで、とりあえず試してみよう！と思った人のためのお話です。

Macに移って久しいのでWindows, Linuxの事情は薄くなりますがご勘弁を。

事前知識

Juliaはまだまだ鋭意開発中の言語なので、変化が激しいです。割とStableを使ってる人が少ないかもしれません。なので、Stableの導入の仕方とNightly buildsの入れ方を書いておきます。

自分はv0.4(Nightly builds)を使ってます。少なくとも、2014年には0.2系以前を試す必要は無いと思います。

入れるもの

Julia
anaconda
IJulia
LightTable(IDEが欲しければ)

Julia

Windows

するのが一番手軽です。

StableもNightlyもこれでいいでしょう。

Mac

お手軽に試すには

するのが一番手軽です。

/Applications/Julia-0.X.X*.app/Contents/Resources/julia/bin/julia に~/bin/以下にシンボリックリンクを貼るなどして、PATHを通しておくとよいでしょう。

Homebrew

からcloneしてビルドするのも良いですが、から入れるのが楽です。

$ brew update $ brew tap staticfloat/julia $ brew install julia

Nightlyを入れるには

$ brew install julia --HEAD

でOKです。

gccとかを更新した時は、と良いでしょう。

Ubuntu

Stable

PPAを使ってaptで取得できるようにするのが楽です。

$ sudo add-apt-repository ppa:staticfloat/juliareleases $ sudo add-apt-repository ppa:staticfloat/julia-deps $ sudo apt-get update $ sudo apt-get install julia

14.10からは普通にapt-get install juliaで入るようです

Julia は Ubuntu 14.10 で普通に apt-get できるし、いずれ追加するつもりですよ

— Yusuke Endoh (@mametter)

Nightly

$ sudo apt-add-repository ppa:staticfloat/julianightlies $ sudo apt-add-repository ppa:staticfloat/julia-deps $ sudo apt-get update $ sudo apt-get install julia

RHEL/CentOS系

RHEL系はEPEL使えば行けるそうです

IJulia/anaconda

IJuliaはIPythonをベースにしたブラウザ上で動くJuliaの対話環境です。ガッツリパフォーマンスチューニングしたい人には向かないですが、グラフ書いたり分析したい人には適しています。また、LightTableなどのエディターで実行結果を表示する時にも必要になるので入れておくのが良いでしょう。

IPythonの環境を入れるのがだるいので、Pythonの環境がまだないよ/こだわりないよって人は、anacondaを使うと良いでしょう。 MacでもシステムPythonだとIPythonのバージョンが古いとかなんとか色々はまるので、anacondaにしておくのが良いでしょう。

少し前のですが下記のサイトやIJulia本家の記述が参考になりますが、こちらにも簡単にまとめておきます。

IPython(Anaconda)とIJuliaが凄すぎる件 - アドファイブ日記

JuliaLang/IJulia.jl

して入れる
IJuliaを入れる

Pkg.add(“IJulia”)

anacondaが入っていればこれで大丈夫なはずです。後は下記でIJuliaを起動後、適当なノートブックを作って試しましょう。

$ ipython notebook --profile julia

便利なショートカットはこちら

ipython 0.12 の notebook

LightTable (optional)

emacsやvimでjuliaのプラグインを入れるのも良いと思いますし、IDE的なものが欲しいよという人はLightTableを使うといいです。補完もできて、Cmd+Enterで実行結果も確認できます。

もあるようですが使ったことがありません。

Lightable - LightTable + JewelでJuliaの環境を作る - Qiita

ちなみに

JuliaのREPLは実はかなり強力で、対話的に開発したいだけならREPLだけで良いという人もいます。

すごい大事な話を忘れていた。これがJuliaのREPLの補完力です

— chezou (@chezou)

juliaのREPL凄い便利。タブを押すとこういう奴らがいることがわかるが、何が凄いかって ∛ 8で2.0って返ってくる所

— chezou (@chezou)

僕自身は、なんだかんだでREPL+SublimeTextで書くことが多いです。

明日は再びbicycle1885さんです。

wordpress.comからはてなブログにお引っ越ししました

Sun, 30 Nov 2014 16:28:46 -0800

Markdownで書くのが辛くてwordpress.comからお引っ越ししました。期待していたJuliaのsyntax highlihgtが無くて切ないです。

Tokyuのあれとか書こうと思っていたのですが、irubyの良さについては真面目に書こうと思います。

基本的に参考にしたのはこのサイトです。

まさか、syntax highlightを移行するためにはてなダイアリーを経由しないといけないとか、はてなダイアリーの作成場所が巧妙に小さく分かりにくくされていたりとか、はてダ作ると緑スターもらえたりとか辛かったです。

wordpress.comからエクスポート
MT形式に変換
syntax highlightをsuper pre記法に置換(エディタで色々なパターン見つけて置換)
はてダにimport
はてなブログに移行
slideshareとかツイートの独自記法を見つけて悲しくなる(←今ここ)

本当は6も一括置換すればよかったんですが、3からループするのはもういやだなぁと諦めました…。 Juliaのsyntax highlightが欲しければQiitaに書くか、Gist貼ればいいんですね！

RubyKaigi行ってきました & RubyHirobaで「神奈川Ruby会議01」告知LTしてきました #rubykaigi #rubyhiroba #kana01

Sun, 21 Sep 2014 15:07:11 -0700

いっぱい面白い発表があったけど、諸般の事情により完結に

RubyKaigi

“Inside RubyMotion for Android"がやばかった。まさか、REPLを使ってAndroidのviewを動的に変更しているデモを見られるとは
@tmm1氏の"Ruby 2.1 in Production"がとにかく"Profile! Profile! Profile!“ということで、Ruby2.1に上げるまでに徹底的にプロファイルツールを作成して遅いところを潰していく姿勢に会場とともにため息ばかりついた
須藤さんの"Three Ruby usages - High-level interface, Glue and Embedding - Inside Droonga"を聞いていると、GlueとしてのRubyをSWIG以外の方法でも触るべきだと感じた。JuliaはCしか叩けないけど、割りと楽なんだよな
amaで@gogo_tanakaさんの質問「数値計算にもRubyが盛り上がらないんですか？」の回答を聴くと、感覚が少しずれているなーと感じた。多分、ユーザがやりたいのは数値計算をして仕事をしたいのであって、数値計算ライブラリを作りたいわけではないという点に尽きるかなと。数式知らなくてもSVDしたい、みたいな
会期中に意識高まって、Juliaのpackageを2つリリースメール流した
- ADAGrad.jlも実装していたけどDictとArrayどちらを使うべきかわからないので保留
Ingressのagent各位ともっと交流すればよかった

RubyHiroba

2015/1/17に開催する神奈川Ruby会議01の宣伝をしてきました
公式サイトはです → になりました
- Jekyll in another Jekyll辛かったけど、会期中に解決できてよかった

Introduction to Kanagawa Ruby Kaigi01 #kana01 from Aki Ariga

iruby notebookの紹介は東急できちんと準備してやりなおそうと思います
にコミュニティ紹介の記事を書いて投稿するとよいと@muryoimplさんに言われました
@beroberoさんの発表の質疑で、「何故数値計算にPythonなどではなくRubyを選んだんですか？」という質問が出てきたのを見て、なるほどこういう切り口もあるのかと思った。ちなみに、berobero氏曰くJuliaはSciRubyよりマシくらいな位置づけとのこと
Railsガイドを翻訳しているさんとお話出来てよかった。の宣伝もしてきましたよ
悲しみのMagsafe2忘れ…

MeCabのJuliaバインディングMeCab.jlを作りました

Mon, 15 Sep 2014 05:09:52 -0700

Juliaから日本語形態素解析器として最も有名なを使えるを作りました。

まだ、METADATA.jlにのですが、きっと明日には使えるようになっていると思います。
[2014/09/15 23:33追記] マージされました！

How to use

簡単な使い方は

Pkg.add("MeCab")

を一度していただければ、こんな感じでアクセスできます

using MeCab mecab = Mecab() results = parse(mecab, "すももももももももものうち") for result in results println(result.surface, ":", result.feature) end

JuliaでCのコードをbindingするには

基本的には、公式マニュアルを読めばいいです。

とかだけ書くと大分辛いのですが、ポイントはccallを使えば良いということです。

例えば、以下の様なCのコードがあったとします。(マニュアルより引用)

int main(int argc, char \*\*argv);

すると、Julia側のコードはこう書けばよいのです。

argv = ["a.out", "arg1", "arg2"] ccall(:main, Int32, (Int32, Ptr{Ptr{Uint8}}), length(argv), argv)

問題は、ポインタが帰ってくる場合どうすればいいのかです。
これは、意外と簡単で第二引数をPtr{Void}で受けてあげれば良いです。

返り値が構造体なんかの場合は、対応するimmutableをJuliaで作ってあげて、unsafe_loadすれば良さそうです。

なお、関数ポインタも受けれるとか。

ただ未確認ですが、構造体のメンバに構造体がいる場合はどうやればいいのかわかりませんでした。
(なので、今回はmecab_node_tは諦めた)

コンストラクタとデストラクタ

MeCabのtaggerの様にに、Cで確保したポインタを保持しておく場合、コンストラクタで作りデストラクタで解放するのが良いようです。

bicycle1885さんのこの記事を参考に、実装してみました。

type Mecab ptr::Ptr{Void} function Mecab(option::String = "") argv = split(option) if(length(argv) == 0) argv = [""] end ptr = ccall( (:mecab\_new, "libmecab"), Ptr{Void}, (Cint, Ptr{Ptr{Uint8}}), length(argv), argv ) if ptr == C\_NULL error("failed to create tagger") end smart\_p = new(ptr) finalizer(smart\_p, obj -\> ccall((:mecab\_destroy, "libmecab"), Void, (Ptr{Void},), obj.ptr)) smart\_p end end

ポイントはfinalizerを実装すると、それがデストラクタとして働くということです。

C++は？クラスとかnamespaceとかは？

どうも扱えないようです。
色々と調べたのですが、特にnamespace周りは鬼門のようです。

なので、extern Cをしながらwrapperを一枚書くのが良さそうですね。

最後に

思ったより簡単にバインディングができました。
多分、Kytea.jlも書けそう。

この内容をでLTしてこようと思います。

データ分析への向き合い方~Machine Learning Casual Talks #2を開催しました #MLCT

Fri, 29 Aug 2014 15:07:00 -0700

先週火曜日にを開催しました。
発表は、グノシー関さん、PFI比戸さん( )、さん、カメリオから柴田さん、さんに発表頂きました。
発表していただいた皆さん、Yahoo!Japanのさんはじめお手伝いいただいた皆さん、本当にありがとうございました！

togetterのまとめ( )

[2014/08/30追記]
Gunosy関さんのスライドが落ちていたので追加しました。

tl;dr

仮説なきデータ分析はやめよう
施策の価値を人手で検証して、必要に応じて機械学習を使おう

詳細

今回は、さんが「機械学習とKPI」というテーマを所望されていたので、それで各スピーカーにお話いただきました。
お互い示し合わせていなかったのに、Lean StartupのMVPの話を中心に話を組み立てていたのが非常に興味深かったです。
特に、グノシーの創業者の一人関さんが「B to Cサービスの現場から考える機械学習活用」という発表をされたのですが、

普段からクックパッド社内でも考える内容に非常にマッチしていて(機械学習をやるやらないは別にして)、データを活かす上での心づもりとして有益な情報でした。

ポイントとしては以下の三点です。

機械学習の精度と、ユーザー価値は別物である
まずは施策の価値を人手で作って(MPV)、検証後機械学習を適用する
仮説がなければKPIを追いかけても意味が無い

もう一つ、PFIの比戸さんの発表も、データを扱う人なら必見の内容です。

ビール大好きな人のコメントが的を射ています。

このページ、機械学習に限らずデータほげほげ系であるあるすぎて、ウッってなるなｗ

— tagomoris (@tagomoris)

from

LT

@motivic_ さん「素人がDEEP LEARNINGと他の機械学習の性能を比較してみた」

from

どう見ても素人詐欺です、本当にありがとうございました

@samurai01T さん「カメリオの記事の本文抽出」

内容もさることながら、初心者向けの機械学習おすすめ本の提示がよかったです。は読みやすくていい本ですね。

本文抽出といえば、さんのExtractContent( , )を使っていた記憶が蘇りました。

Akira Shibataさん「カメリオ精度向上に使った学習アプローチ」

最適化手法は古典的な方法を使っているそうなのですが、特徴的なのがクラウドワークスを使ってラベルを収集していること。
USだとAmazon Mechanical Turkを使うのが一般的に行われているのですが、日本でマイクロタスクを出して機械学習の正解データを作っているというのは感慨深いものを感じました。

まとめ

グノシー関さんの「数値は神である」、PFI比戸さんの「機械学習は苦しい」という話に表されるように、機械学習を「つかう」という点にフォーカスした会でしたが、機械学習をしない人にとっても、どうデータと向きあえばいいのか、というエッセンスが凝縮されていました。
僕自身も聞いていて"Lean Analytics"にあった、「行動に移せない指標は意味が無い」という話を具体的にした話を聞けて、局所最適解に陥らないデータ活用について考えさせられました。

#JuliaTokyo 01で「Julia100本ノック」を発表してきました

Sat, 05 Jul 2014 15:06:54 -0700

で発表してきました。
取りまとめをしてくださったさんには感謝です。

事の発端は、を読んだとで「Julia勉強会やりましょう！」といったことでした。
そこで、とコンタクトをとり、始まりました。

まさか、本家のJuliaConの半分の40人近くの参加者が集う場になりました！(Julia歴24時間以内の人も多かったですが…)
togetterは

先日公開した、の発表をしてきました。

日本でおそらく一番Juliaにコミットしているさんと意気投合したら、いつの間にかやることが決まっていたJuliaTokyoですが、貴重な日本語の資料が集まったいい機会でした。

また、さんにはJuliaConの様子を世界でおそらく一番最初に報告してもらったり、Feature Engineer vs Machine Learnerなんて話も飛び交って非常に面白い場でした。

パフォチューするのに読んでおくべきページはです

パッケージの作り方とか、C++のバインディングどうしたらいいの…な話とかが聞けて個人的には大満足でした。
また、IDEどうしたらいいんだよ！問題は非常に白熱をして、Julia Studioはオワコン説、IJulia最高！いやいや素晴らしいだろ。グローバル変数書いたら負けだからIJuliaとかどうなの、REPLの補完最高では？みたいな熱い戦いが繰り広げられました。

さて、第二回は？という話が出ていましたが、きっと発表者ドリブンだと思いますが、おそらくフェーズとしてはカンファレンススタイルよりもくもくする会を定期的に開催するのが良さそうですねーという話をしていました。

みなさん、Scikit-learnをpure julia移植すればワンチャンありますよ

Julia100本ノック

Sat, 21 Jun 2014 15:06:49 -0700

に引き続き、という、面白いnumpyの練習問題があったのでそれのJulia版を作成しました。
実際には46個しかないのと、numpyの便利関数がなくて挫折したものとかいくつかありますが、pythonistaな方々はオリジナルと比較してJuliaの世界に来ていただければ楽しいのではないかと思います。

この話で得たものをまとめて、で発表してこようと思います。
コードは最後にgistのを貼るとして、発表するための雑感をメモしておきます。

調べるべき所

で検索
関連パッケージにないかどうかを調べる(from google)
- 特になどの基本的なパッケージは調べると良い
githubでissueを調べる
Matlabではどう書くかを調べて、その関数名を調べる
Numpyでどう書くかを調べてMatlabに変換する
- 他言語のドキュメント(英語)がわかると、特定の処理を検索するためのワードが分かって良い

numpy, matlabとの比較

matlab, numpyは歴史があるため充実した便利機能が沢山あることを実感
Matlabはおろか、Pythonよりストイックな感じ
- 「Matlabである○○はありませんか？」「No!それ高速に処理できないだろ！」
- “removed pascal(matlabであった関数)”
- 「これあると便利だと思うんだけど」「IMHO 一つのことを複数のやり方でやれるのはどうかと思う」
たまに、独自の関数名をつけてきて辛い
- argmaxならわかるのにindmaxってなんだよ(2014/06/22追記:argmaxにrenameされそうなです)

code

[2014/06/22追記]

レポジトリを作りました。最新のものはこちらをどうぞ
を見えるようにしました。nbview便利すぎる

[2014/06/24追記]

しました。結構array comprehension使えという話が多く、vectorizeしない方がいいんだよ！というツッコミが新鮮です

Machine Learning Casual Talks を開催しました #MLCT

Sat, 07 Jun 2014 05:06:04 -0700

昨日6/6(金)に、クックパッドでを開催しました。
はじめてこの規模の勉強会を開催したので、色々とどたばたしてしまいましたが、発表・参加・準備等協力していただいた皆様ありがとうございました！

募集開始して30分もしないうちに枠が埋まり、一時は100人を超える応募をしていただき注目されている分野であることを改めて認識しました。当日も天候も悪い中40名近くの方に集まっていただき、そして一言も"カジュアル"の定義をしていなかったのですが、意図していた定義どおりの活発な議論ができて良かったです。
特に、「ハイパーパラメーターの説明を一言もせずに進んでいく会なのか…」というコメントに対して、海野さんが「libsvmのCについて説明したのはかなり分かりやすくしたつもりだった」という返答が象徴的でした。
(なお、カジュアルの定義はcon_mameさんのこちらがわかりやすいです。)

発表者の立ち位置も、機械学習のシステムを社外に提供する立場、機械学習のライブラリを作る立場、自社サービスで機械学習を含めたシステムを作る立場と、三者バランスよく様々な話に展開して良かったです。

個人的には、Jubatusのバグの歴史を聞かせていただけたことが、とても価値があったなと思いました。
次回の開催も、PFI方面やGunosy方面から発表したいという話が来ていますので、発表者が揃い次第案内できればと思っています。

発表資料

chezou 「オープニングトーク」

「機械学習のテスト自動化コトハジメ」

「Jubatusにおける機械学習のテスト」

, 「パーソナライズニュースを支えるML業務のまわしかた@Yahoo! JAPAN」

LT

「pythonでカジュアルにディープラーニング」

Gunosy 関さん「グノシーを支える機械学習業務プロセス」

「scikit-learn入門とお願い」

Cookpad 原島さん「レシピの自動分類」

追記

当日最も衝撃的だった情報

Julia vs Python: ビットコインオプションのモンテカルロシミュレーション

Tue, 06 May 2014 15:06:37 -0700

Justin Huang( )さんのJuliaとPythonの比較記事(原題： )が非常に面白かったので、翻訳してみました。

Juliaは科学計算・数値計算向けの言語として高速さを売りにしている言語で、Rからの移行を進める人たちも増えているようです。

以前訳したという記事を読んでいた時に、そういえば、Juliaって言語があったな、と思って調べていました。( しましたし、で出てくるベンチマークも印象に残っています)

今回のJustinさんの指摘では、普通のプログラマーにとってPythonよりもJuliaの方が、特定の高速化を意識せずにコードを書けるため、プロトタイプに向いているのでは、という点が興味深い視点でした。

なお、元の文章とコードの権利はJustin氏に(いくつかのPythonのコードはDr. Hilpischに)帰属します。
翻訳を快諾していただいたJustin氏に感謝します。

なお、翻訳の間違い等ありましたら、chezouまでご指摘ください。

[2014/05/07 15:30追記]
で vectorizeしないで4倍速くなるコードが紹介されています。

jwmerrill 氏曰く、

In general, carefully written devectorized Julia will be faster than equivalent vectorized code because it is possible to avoid allocating containers at intermediate stages of the computation. This is surprising for people coming from e.g. Matlab, R, or Numpy, because vectorized code is often faster in those environments.

ということなので、Juliaは驚くべきことに、vectorizeしない方が高速になるようです。やばい

私は最近、HackerSchoolに参加した時にStefan Karpinskiに聞いたを紹介した。
Juliaはとても高速で高性能な科学計算言語をターゲットとしており、その速度はCのネイティブコードに近づきつつある。
Python quants in NYCに参加した後、が金融分析におけるPythonの処理速度についてのプレゼンテーションを聞いた時に、JuliaとPython/numpy stackを比較することを決めた。

これはJuliaとPythonの対決ではなく、むしろ同じ問題を2つの言語で解いて比較をする練習である。
ipython/ijuliaのコードを添付したので、よかったら試して欲しい。

Monty Python Bitcoinとは

もしかすると、的はずれなことを言うかも知れないが、やろうとしていることを簡単に説明してみる。
基本的に、古典的なオプション価格問題のモンテカルロシミュレーションをJuliaとPythonの両方で解き、2つの言語で取られているアプローチを比較する。

モンテカルロ法

モンテカルロ・シミュレーションは、確率的なテクニックである。
ランダムな確率分布を使いサンプリングを繰り返すことで、複雑なシステムをシミュレートする。典型的には精度のために極端に大きな数をサンプリングする。

シンプルで概念的な例としては、カジノでクラップ(私がお金を捨てるのに好む方法だ訳注: )を繰り返しプレイし結果を記録して、あるベットに対する特定のオッズを見つけることが挙げられる。

ビットコインオプション

私がビットコインオプションと言う時は、ヨーロッパのコールオプション形式の理論的なビットコインのストック・オプションを意味する。なぜなら、ビットコインに関するものはすべて興味深い(し、もっとクリックを稼げる)

幾何ブラウン運動

株価はランダムウォークに従い、予測できないという金融理論がある。
この仮説に従い、モンテカルロシミュレーションによりビットコインのヨーロッパコール・オプションの評価したい。ビットコインの価格変動をランダムウォークでシミュレートする。(今回は、ランダムな連続値をシミュレートする架空の手法として幾何ブラウン運動を考える)

株価モデル

ビットコインの価格がとマルコフ過程に従うと仮定する。

ビットコインのボラティリティを算出する

ビットコインに対する一般的な論点はボラティリティである。
今日ビットコインを買うことのリスクは、明日には半分の価値になっているかもしれないことだ。
rに対する案を出すためには、ビットコインのボラティリティを計算する必要がある。
Bitstampで交換されたビットコインの(分単位でリサンプリングした)価格変動の対数に対する標準偏差を利用した。2013/03/01以降の年率を算出した。

import pandas as pdimport numpy as np# read in bitstamp USD trade data with columns time, price, volumebitstamp = pd.read\_csv("bitstampUSD.csv" , names=[&#039;time', 'price', 'volume'], index\_col=0)bitstamp.index = pd.to\_datetime((bitstamp.index.values[^1] e9).astype(int))# resample the csv data to minutely data for volume and pricevolume = bitstamp.volume.resample(&#039;1min', how='sum')value = bitstamp.prod(axis=1).resample(&#039;1min', how='sum')# obtain the volume weighted average pricevwap = value / volume# pad data with repeating values# then grab a years worth of data starting from 01 March 2013bitstamp\_pad = vwap.fillna(method=&#039;pad', limit=10)bitstamp\_year = bitstamp\_pad.ix[&#039;2013-03-01':'2014-03-01']# calculate the return and volatilityreturns = np.log(bitstamp\_year / bitstamp\_year.shift(1)) returns.std()\*np.sqrt(returns.size) \* 100## output: 260.70492740919627

残念ながら、Juliaのツールには時系列データに対するものが現状では全くない。
と呼ばれる素晴らしいパッケージがあり、データフレームの処理と変換を行ってくれる。例:

using DataFrames bitstamp = readtable("bitstampUSD.csv", colnames = ["time", "price", "amount"])

残念ながら、これが生のJuliaコードで時間周期に対するfillnaやresampleのような関数を書かずにできる最大限のことである。

また、DataFrames.jlはpandasのパッケージよりCSVの読み込みは遅いし、インデキシングもサポートされていない。

Pythonでのモンテカルロシミュレーション

これ以降のほとんどのPythonコードはDr. Hilpischのもので彼にクレジットがあることを注意して欲しい。
( )

ここで、_sigma_と他のパラメータをPythonで書かれた単純なモンテカルロシミュレーションを実行することで得られる。
ここでのコードでは基本的に、上述した数式で表されるビットコインの価格が取りうる経路の数Iを生成している。

## Simulating Geometric Brownian Motion with Python#import mathfrom random import gauss# ParametersS0 = 600; # current bitcoin pricer = 0.02; # risk neutral payoff, assumed 2% for this exercise, in reality probably less.sigma = 2; # extremely high sigma due to spike in bitcoin prices late last yearT = 1.0; # 1 Time cycleM = 100; # 100 stepsdt = T / M # dt# Simulating I paths with M time stepsdef genS\_py(I): # initialize array to hold all of our paths S = [] # for each path i to Ifor i in range(I): path = [] # for each step t to M + 1for t in range(M + 1): if t == 0: # append S0, our starting value to the front of the path path.append(S0) else: # take a random normally distributed number z (mean = 0, std = 1)# and append it to our current path z = gauss(0.0, 1.0) St = path[t - 1] \* math.exp((r - 0.5 \* sigma \*\* 2) \* dt + sigma \* math.sqrt(dt) \* z) path.append(St) S.append(path) return S

これは、基本的なPython的な経路を作る方法である。10万経路をシミュレーションして、時間を計測するとこうなる:

I = 100000%time S = genS\_py(I)# CPU times: user 40.8 s, sys: 887 ms, total: 41.7 s# Wall time: 42.1 s

くだらないミスがないか確認するために、matplotlibで簡単なグラフを描く。

bitcoin_plot

もし、ビットコインの価値が凄い大きさになっていたり0になっていたら、間違いなく調べ直すべきだ。

Juliaでのモンテカルロシミュレーション

今度は、Juliaでやってみよう

# # Simulating Geometric Brownian Motion with Julia # # Parameters const S0 = 600; # current bitcoin price const r = 0.02; # risk neutral payoff, assumed 2% for this exercise, in reality probably less. const sigma = 2; # extremely high sigma due to spike in bitcoin prices late last year const T = 1.0; # 1 Time cycle const M = 100; # 100 steps const dt = T / M # dt # Simulating I paths with M time steps function genS\_jl(i::Int64) S = {} for i in 1:i path = Float32[] for t in 1:(M + 1) if t == 1 push!(path, S0) else z = randn() st = path[t - 1] \* exp((r - 0.5 \* ^(sigma,2)) \* dt + sigma \* sqrt(dt) \* z) push!(path, st) end end push!(S,path) end return S end

Juliaの文法はいくつかの注意すべき点を除いてほとんど同じだ:

arrayのindexは1始まりである。Pythonは0始まりなのに対して
randn()は平均0、標準偏差1の正規分布からランダムな数を生成する組み込み関数である。
Juliaの ^() vs Pythonの ** や push!() vs .append()などの関数
グローバル変数に対する定数宣言(10x倍速くなる)

I = 100000 @elapsed S = genS_jl(I) # 2.243841008

しかしながら、Juliaで書かれた全く同じコードが20倍も速いのだ！これは、Juliaが勝ったことを意味するのだろうか？このアルゴリズムの一実装に対する速度の面においては、Yesだ。しかし、実際にはそうではない。これは、後述するようにもっとも効率的なモンテカルロシミュレーションのモデル化手法ではない。

ビットコインのコールオプションの評価

さて、演習の一部としてビットコインの価格に対して、理論的なヨーロッパのコール・オプションの評価をしたい。
満期になると、コール・オプションの価値は次式で表すことができる。

$latex max((S\_t - K), 0) $

ここで、Kはオプションの行使価格とする

オプションの行使価格を K = $1000 とすると、どちらの言語でも単純に計算できる

python

K = 1000.0C0 = math.exp(-r \* T) \* sum([max(path[-1] - K, 0) for path in S]) / Iround(C0, 3)# 361.203

julia

K = 1000.0 C0 = exp(-r \* T) \* sum([max(path[end] - K, 0) for path in S]) / I round(C0, 3) # 374.496

注意：これらの2つの計算における値は、試行回数を増やすと361に収束する。

ここでは、arrayの最後の要素にアクセスする方法([end] vs [-1])以外、言語による違いはほとんど無い。

ベクトル化した数式の処理

しかしながら、ベクトル計算をすることでより高速に処理をすることができる。
ベクトル化のテクニックを使うことで、乗算を1つの要素を何回もループで回すのではなくベクトルに対し一度で処理ができる。
これは、コンパイラやハードウェアによる最適化の恩恵を受けやすく、かなり処理時間が速くなる。

PythonではNumPyというパッケージを使ってベクトル化できる。

import numpy as npdef genS\_np(I): S = S0 \* np.exp(np.cumsum((r - 0.5 \* sigma \*\* 2) \* dt + sigma \* np.sqrt(dt) \* np.random.standard\_normal((M + 1, I)), axis=0)) S[0] = S0 return S %time S = genS\_np(I)# CPU times: user 1.07 s, sys: 147 ms, total: 1.22 s# Wall time: 1.38 s

おお、ベクトル化した計算で桁違いに処理が速くなった！先ほどと似た方法で、オプションの理論値を$1000の行使価格として計算ができる。

C0 = math.exp(-r \* T) \* np.sum(np.maximum(S[-1] - K, 0)) / Iround(C0, 3)# 367.457

まったく同じベクトル化がJuliaでもできる。

function genS\_jlvec(I) S = S0 \* exp(cumsum((r - 0.5 \* ^(sigma, 2)) \* dt + sigma \* sqrt(dt) \* randn((M + 1, I)), 1)) S[1,1:end] = S0 return S end @elapsed S = genS\_jlvec(I) # 1.430265529

JuliaのメリットとしてはNumPyのようなライブラリーが不要だということだ。我々は素のJuliaを使っている。驚くべきことに、Juliaのナイーブなloopでの実装は、ベクトル化された実装と同程度に速い！これは、アルゴリズムの単純なプロトタイピングに非常に向いていることを示す。ある種の計算でナイーブな実装を駆逐することで猛烈な高速化を期待する、Pythonが提案できない価値のある論点である。

最後に、Juliaでオプションの値を計算する文法はほとんど同じである:

K = 1000.0 C0 = exp(-r \* T) \* sum(max(S[end, 1:end] - K, 0)) / I round(C0, 3) # 359.783

結論

Python Loops: 42.1 s
Julia Loops: 2.24 s
Python Vectorized: 1.38 s
Julia Vectorized: 1.43 s

Juliaは、科学/数値計算にとってとても大きなポテンシャルを持っているように思える。
ナイーブなループを使った、ビットコインの価格のモンテカルロの経路シミュレーションはPythonよりもかなり速く、ベクトル化して最適化された計算と同じオーダーの速度だった。
つまり、今回の分析での重要な知見だと考えている：
Juliaは計算的に困難な問題を効率的に解くにあたって、ベクトル化された処理を必要としない。

Juliaはベクトルや行列の計算にNumPyのような外部ライブラリを必要としない。
他の化学計算言語が険しい学習曲線であるのとは異なり、Juliaは普通のプログラマーにとって極めて読みやすくなる。
処理速度は前述のとおり明確に速い。

残念ながら、DataFrames.jlなどJuliaのデータ分析のためのツールは、Pythonのpandasと比較して性能面、機能面ともに成熟してるとも安定しているとも言いがたい。
Juliaのコミュニティは若く成長している。
だから、様々な人々が言語に対して貢献することで、私はこれらの点で多くの改善や成長がなされることを期待している。しかし、それまでは私はPythonとpandasの行く末を見ていく。

すべてを考慮した上で、メインストリームとして採用されることを約束はできないが、私はJuliaを試すことをおすすめする。
私としてはJuliaのコミュニティに貢献したいと強く思っている。

Files

Thanks

Dr. Yves J. Hilpisch (inspiration)
Neeraj Wahi (options pricing)
James J. Porter (Julia)

kawasaki.rb #011 を開催しました #kwskrb

Sat, 26 Apr 2014 15:06:31 -0700

4/23にを開催しました。
次回で1年になるのかと思うと、感慨深いです。
なお、kawasaki.rbは毎月第4水曜の19:30-開催しています。(最終週だと思われていたのでご説明)

パーフェクトRuby読書会

2-9 例外〜 2-12 組込みの変数/定数までを読みました。

組込み変数の、$-Fはワンライナーの-Fと互換だよねー、といった話や、RailsとMySQLでprecisionを使おうとしたら予約語でハマったという話が出ました。

次回は、ついに3章に突入です。

AngularJS+SinatraでTurbolinks: さん

Angular jsとsinatraでturbolinks from Minori Tokuda

@snowcrush さんのblogは、AngularJS + Sinatraで構成されているそうですが、
google botsはJSで動的に生成されたページにindexを貼ってくれないので、
なんとかして拾えるようにしましたという話。
“これってTurbolinksじゃん！Railsで良いじゃん！“という結論には、笑ってしまいました。

TokyuRuby会議07でLTしてきました #tqrk07

Thu, 03 Apr 2014 15:06:26 -0700

無限プレモルが出るという危険な楽しいイベント、でのにドラの音を付けたよ！という話をしました。

こんな感じでご家庭でもドラの音を楽しみながらLTできます！

Gong anyware from Aki Ariga

本当はデモをするつもりだったのですが、いい感じに出来上がっていたので肝心の音を鳴らすことができませんでした。せっかく、iPhone, iPad, Androidで動作確認をして会場で準備までしてたのに！

あと、同僚に教えてもらった大事な情報として、フリーの音素材を探すのにはがいいよ！ということをお知らせしそびれたのが悔やまれます。

大抵、Webで音を鳴らす場合再圧縮したり切ったり貼ったりすることが多いので、加工をできる音素材が必要なのですが、
自作のものでない場合、ライセンス的にどうなのか不安になると思います。

そんな時、CC0ライセンスの音素材を探せるfreesoundはめっちゃ助かりました。

ちなみに、持ち込み飯はキッシュを作りました(レシピはそのうち投稿します）。ラップにつつまずホールで持っていけばよかった。

切る前はこんな感じでした

青梗菜とベーコンのキッシュ

ツナと長ネギの味噌キッシュ

なお、飯王の写真を見せた所、妻から次回飯王を目指せとの指令が下りました。

kawasaki.rb #010 を開催しました #kwskrb

Sun, 30 Mar 2014 15:06:20 -0700

kawasaki.rbもいよいよ10回目を開催してきました。
まさかの1日二回LTという展開でしたが、無事に話すことが出来て良かったです。

togetterは

パーフェクトRuby読書会

2-7-7 Regexp, 2-7-8 %記法の括弧, 2-7-9 手続きオブジェクト(Proc), 2-8 様々な代入式まで読みました。

はじめて翻訳記事を書いたら300ブクマ超えた話 (chezou)

を翻訳した時に思ったことを書きました。

はじめて翻訳記事を書いたら300ブクマ超えた話 from Aki Ariga

Jekyll ドキュメントの日本語翻訳レポジトリを作った話( さん)

@kk_Atakaさんによる、Jekyllのドキュメントの翻訳の話。
ご本人のブログの記事をもとにお話していただきました。

特に、本家のリポジトリが英語しか想定しておらず、「言語ごとの翻訳を本体に入れるつもりはない」と言われているため、
本家との差分をどう管理していけば良いのか、という話を議論しました。
懇親会で、さんのを使って本体の更新を反映させやすくできると良いですねーと盛り上がりました。

Railsのhelperでnamed capture使ったらハマった話 (chezou)

当日人気のない話でしたが、ActiveSupport::SafeBufferはRegexp.last_matchがそのままだと取れないので気をつけよう、という話でした。

gsub with ActiveSupport::SafeBuffer from Aki Ariga

次回は、4/23(水)に開催予定です。
申し込みは下記からおねがいします。

4ステップでDoorkeeperにコメント欄を追加する方法

Sun, 23 Mar 2014 15:06:15 -0700

Doorkeeperはコミュニティなどのイベントを行うのに便利ですよね。
そんなDoorkeeperですが、他のzusaarなどのサイトと比較してコメント欄がデフォルトでついていないので、
Disqusと連携してコメント欄を追加する方法を書きます。

僕がやった時は日本語で情報が見つからなかったのですが、
@yumu19ですらはまっていたので、結構挫折している人がいるのかも…、と思いブログに書くことにします。

1. Disqusのアカウントをとる

アカウントの取り方はメモを取っていないのですが、多分普通にメール認証すれば良いはず…。

2. “Add Disqus to Your Site"をクリック

ログインした後のtop右下の"Add Disqus to Your Site"をクリックする

3. 必要な情報を埋めていく

“Site name"はdescriptionなので適当に決めればOK。

“Choose your unique Disqus URL"で入力する情報が、後のDoorkeeperで入力する情報。
“Category"も適宜入力すればOK

“Finish registration"を押せば、完了。

その後に出てくるscriptの生成画面はdoorkeeperには関係ないので、気にしなくて良い。

[

4. Doorkeeperのコミュニティ管理画面の"連携機能"を開く

“Disqus shortname"に、さっき作ったDisqus URLの.disqus.comの前の文字列を入れる。
今回の例だと"kawasakirbtest"を入れて保存する

[

これで、冒頭のようなコメント欄がイベントページの下部にできます！

kawasaki.rb #009を開催しました #kwskrb

Sat, 01 Mar 2014 04:03:51 -0800

去る2/26(水)にを開催しました。

togetterのまとめはこちらです。

パーフェクトRuby読書会

2-7-4 配列, 2-7-5 ハッシュ, 2-7-6 範囲(Range)をやりました。

Hashでは、自分で作ったクラスをHashのkeyに用いる場合はどうすればいいのか、という話がでました。
自作クラスにhashメソッドとeql?(other)メソッドを定義すれば、
自作クラスでも同値性判定が行われるという確認をしました。
(やっててよかった、レシピブック&yokohama.rb…)

コードで書くと、こういう感じですね。

class Fooattr\_reader :a, :bdef initialize(a, b) @a, @b = a, b enddef hash@a%10 + @b%7enddef eql?(obj) @a == obj.a && @b == obj.b endendf1 = Foo.new(1, 2) f2 = Foo.new(1, 2) f1.eql?(f2) # =\> trueh = {} h[f1] = "foo"h[f2] # =\> "foo"

Rangeでは、(1..-1)のような負の数までのRangeってなんであるんだろう？という話をしました。
使用するケースとしては、Arrayにアクセスするときary[1..-1]というのを渡すよねー、という話になりました。

LT

BestGems.org (ぺけみさおさん)

LTはさんによると、さんによるpandasの紹介(資料公開されたら追記します)が発表されました。

ぺけみさおさんの、BestGems.orgはRubyGems.orgを毎日クローリングして、
DL数の変化を見ているというシンプルながら価値のありそうなアプローチでランキングを作られていました。
実際にランキング作って分析するのって、楽しいですよね。

ランキングを分析しているとというgemの人気が上がっているとのことでした。

pandas紹介するよ(aflc_jpさん)

aflc_jpさんのpandasの紹介は、Pythonのデータ分析によく使われるライブラリである
の基本と使い方のexampleを紹介してもらいました。

説明を聞くと、pandasはRでよく使われているDataFrameを扱えるようにしているところが特徴のようで、
SQL likeにgroupbyして集計をしやすくなっているという話でした。
例としてはオリンピックのメダルのデータを使って、日本が歴代メダル数を稼いだ種目などを表にしていました。
Excelに出力することもできるので、分析はpandasでreportingはexcelで、という使い分けができるようです。

改めて実感したのは、IPython notebookは便利だなーということ。
IJuliaで便利さは実感していたのですが、Rubyの実行もブラウザベースでやれるようになるそうなので、
kawasaki.rbのパーフェクトRuby読み会でもIPythonベースにしようかなー。

次回は、3/26(水)に開催予定です

「はじめてのパターン認識」読書会に参加しました #はじパタ

Sun, 23 Feb 2014 14:06:04 -0800

先日開催されたにさんに誘われるままに参加してきました。

部分空間法の話の続きとカーネル主成分分析分析のお話が中心でした。
この本、タイトルはやさしそうな雰囲気を出していながら、普通に数式をきちんと書いてくれている本で、わりときちんと読まないと読み落とす感じがたまりません。
でも、こうやってわりと網羅的に書いてくれる本って一昔前にはなかったので、自分の中の情報を整理する意味でも良いかなーと思いました。

また、「Juliaを使った機械学習」という釣り気味のタイトルでLTしてきました。

Juliaを使った機械学習 from Aki Ariga

実際には、使うとおしゃれなグラフが書けますよーというレベルでしかなかったのですが、D3.jsなんかとも親和性高い描画エンジンなのでよければ使ってみると楽しいですよ。

kawasaki.rb #008 を開催しました #kwskrb

Fri, 24 Jan 2014 14:05:59 -0800

2014/1/22にkawasaki.rbの第8回ミートアップを開催しました。

togetterはこちら

パーフェクトRuby

パーフェクトRubyは、2.7.3シンボルまでやりました。
ヒアドキュメントの様々なテクニックを学ぶことが出来ました。

ヒアドキュメントに、第2引数渡せたり、

バッククオートでくくると、ヒアドキュメントの実行結果が帰ってくるとか。

あと、===はcase...whenのためだけのもの、という感じだそうで、=~や!~のような左辺と右辺の対称性がないからハマるという話でした。 when節には、lamdaを渡せるのは初めて知りました。

いつ使うんだろう。。。

chezou “なぜ科学計算にはPythonか？”

本当は、はじめてはてブでホッテントリ入りした、的な話をしながら、技術的な話の翻訳についての悩みなどアレコレを話そうと思ったのですが(実際、そっちのほうが資料は多くなった)、会場からの希望でこちらの話をしました。
さんのという話にも通ずるところがあるのですが、技術的な話の翻訳って日本人同士で協力し合うことができないかなー、とか思ったりします。
なので、この話も来月以降に翻訳の話はしたいと思います。

なんで、Rubyではダメなのか？という話やら、GPU屋さんはPythonの方が人気だねとか、昔「京でRを動かしたいんですが」とかいう話が…、4,5年前に科学計算がRubyの3番目位の注力事項になっていたのがmrubyに流れてしまった、など様々な話題が展開されました。

個人的には、一番重要なのはNumPy,Scipyのレイヤーをどうやって作り続けていくかということと、統計や機械学習のデファクトなgemができるといいのかなー、と思いました。

あと、Numpyのベンチマークを探していたら ¹に行き着いたのですが、実はGoが結構速いということに驚きました。(GoってOpenBLAS使えないですよね？)

より引用

もしかすると、並行処理とも相性のいいGoでの科学計算ライブラリが充実する日が来るかもしれません。

Rubyのコミュニティなのに、Pythonの話をしていて、、、と思うのですが、次回はPythonistaな方の立場からお話を聞こうと思います。

「シングルスレッドでのベンチマークは、科学計算ではあまり価値がない」とさんの言葉↩

kawasaki.rb #007 を開催しました #kwskrb

Fri, 24 Jan 2014 14:05:53 -0800

2013/12/18にkawasaki.rbの第7回を開催しました。
この会から、(同じミューザ川崎内ですが)NTT-ATさんに会場をお借りするようになりました。

第6回で、居酒屋LTをやることを挫折したので、毎月会議室でミートアップを行うようになりました。

togetterのまとめはこちら

パーフェクトRubyは、2.6のモジュールまでやりました。

chezou “Active ModelとNaive Bayesを仲良くする baby_faceを使ってみた”

というGemを使ったサンプルアプリとしてを作りました。
BabyFaceはActiveModelなどとナイーブベイズ分類器とをつなぎ合わせることができる便利なGemです。
なんてことはない、投稿したテキストが、DQかモンハンかSkyrimかを判定するだけの簡単なアプリです。
最初はHerokuに上げておこうと思ったのですが、無料で使うにはDBのレコード数の制限が厳しいとかあったので、localで動かしたものでデモをしました。

ポイントとしては、学習が

def self.create\_with\_train(text, category) e = Entry.create(comment: text) method = "train\_#{category}".intern e.baby\_face.send(method) enddef self.open\_and\_create(file, category) line = 0 open(file) do |f| while l = f.gets next if l.nil? || l.chomp!.empty? break if line == 10000 line += 1 create\_with\_train(l, category) endendend

これくらいで簡単にかけることと、日本語の分かち書きにはを使いました。これならmecab&bindingのインストールとか要らない！便利！とか思っていたら、今どきはhomebrewでサクッとはいるんですね。。。

def segment(text) @tagger ||= TinySegmenter.new @tagger.segment(text, ignore\_punctuation: true)end

さんの"自分のほしいものをどんどんつくろうよ"という話

いつもblogにはお世話になっている、suginoyさんの、Railsだと簡単にWebアプリケーション書けるんだから、自分のほしいものを皆どんどんつくろうよ、というお話。

Rubyのカンファレンスサイトをscrapingしてきて、podcastにしちゃえ
をゴニョゴニョしている
suicaの使用履歴とかをRailsで管理できるようにしてます

などなど、いい話でした。

懇親会では、Kanagawa Ruby会議やりたいですなー、とか盛り上がりました。

kawasaki.rb #006 を開催しました #kwskrb

Fri, 24 Jan 2014 14:05:48 -0800

去る2013/11/27にkawasaki.rbの第6回を開催しました。
togetterは

さんの"Appiumを使ったiOS(Android)受け入れテスト"

テスト自動化フレームワークであるを使うことで、Rspecを書いてiOSの検査ができます。更に、スクリーンショットを自動で撮ることで、デザインのレイアウト崩れなどの検査をしやすくすることができます。

実際に動いている動画を見ると、なるほど！と思うので、こちらを見ると良いと思います。

chezouの"Rubyと機械学習"

タイトルは大分大きく出ていますが、最近訳したの興味のベースになっている話でも有ります。なぜ、PythonではRubyに比べて、科学計算が活発に行われているか？という点に対して、NumPyやSciPyといった数値計算のライブラリが活発に利用されているから、Railsで機械学習を扱えるライブラリがあまりないから、という話をしました。

余談ですが、会場に使ったお店は、予約の段階でプロジェクターを使えると聞いていたのですが、当日現地に行ったら、「持参したプロジェクターを使えます」という話にすり替わっていました。。。

Kawasaki.rb #005を開催しました #kwskrb

Fri, 24 Jan 2014 14:05:31 -0800

大分たってしまいましたが、2013/10/23にKawasaki.rb #005を行いました。

さんによるの話をしていただきました。
quine-relayとは50言語¹が次々に次の言語を生成し、一周してRubyに戻ってくるというコードであります。

togetterによるまとめはこちらになります。

肝心のスライドは、諸般の事情[^problem]により公開できなさそう、ということですが、
Quineの解説は以下の資料が詳しいです。

Ruby を用いた超絶技巧プログラミング（夏のプログラミングシンポジウム 2012） from mametter

ポイントとしては、“いかに次の言語の文字列をprintするか"というところが大きいようです。
特に、エスケープが増えてしまうと、様々な言語の制限(主に文字数制限)に引っかかってしまい実行できなくなるという問題があるようで、takesakoさんのやら文字列圧縮などを使い工夫することで、それらをうまく回避しているとのことです。

また、内部ではで次の言語でのprint文を書けば、順番に生成するようになっているので、言語を増やしたいとかいう人はpull-requestを送るといいと思います。(D言語とかJSXとか、TypeScriptとか…)
なお、言語の選定基準はDebianのapt-getで導入できる言語、というのを想定していたとのことです。(が、MacではhomebrewがClojureのサポートを打ち切った等の問題が有り、VMでやるのが良さそうです。)

なお、quine-relayは経済効果をも生み出していたようで（！）、Quoraだかredditだかで「quine-relayの解説したらお礼にお金を払うよ！」と言っていた人に解説をした人がいくばくかのお金をもらっていたそうです。
(もちろん、mameさんにはなんのお金も渡っていないですよ)

有名なBrainfuckやWhitespaceに始まり、果てはVerilogとかINTERCALとか！
[^problem] : 様々なが含まれるため ↩

科学計算における均質化、あるいはなぜPythonが着実に他言語のシェアを奪っているか

Fri, 17 Jan 2014 18:01:18 -0800

最近、何故科学計算でPythonがほぼ一人勝ちなのか気になっていたのですが、氏による、という記事が、その答えに近づける鍵なのかもしれないと思い、試訳をしてみました。
彼は心理学とニューロイメージングを専門とする研究者であり、元々Rを中心に様々な言語を利用していたのですが、最近ではPythonばかり使うようになってきたとのことです。

(更なる議論としては、も興味深いです。)

訳すこと自体が初めてで拙い訳だとは思いますが、間違い等がありましたらコメント等で指摘ください。
翻訳の公開を快諾していただいたYARKONI氏、翻訳のアドバイスをいただいたmrkn氏に感謝します。

ここ2年で、私の科学計算のツールボックスが着実に均質化している。
2010,2011年くらいは、私のツールボックスは以下のものを使っていた。

Ruby: テキスト処理や雑多なscripting
Ruby on Rails/JavaScript: Web開発
Python/Numpy(たまにMATLAB): 数値計算
MATLAB: ニューロイメージング¹データの解析
R: 統計的分析
R: プロット、可視化
それ以外のもののために、他の言語/環境の開拓

2013年には、こうなっている

Python: テキスト処理や雑多なscripting
Ruby on Rails/JavaScript: Web開発。DjangoやFlask(Pythonのフレームワーク)もたまに使う
Python (Numpy/SciPy): 数値計算
Python (Neurosynth, NiPyなど): ニューロイメージングデータの解析
Python (Numpy/SciPy/pandas/statsmodels): 統計的分析
Python (MatPlotLib): プロット、可視化(Webベースの可視化にはJavaScriptのd3.jsを使う)
Python (scikit-learn): 機械学習
他言語の開拓は顕著に減った

もうお分かりだろう。

私が使うツールの均質化(Pythonification?)が進むことで、定期的に最近のPythonのエコシステムの驚くべき成長について考えるようになった。数年前までは、多くの時間を髪をかきむしりPythonがもっとRライクなら良かったのにと祈ることに費やさない限り、Pythonでは本当の統計を扱うことはできなかった。(そしてそれは、を考えていることを告白するに等しい)
ニューロイメージングデータはSPM(MATLABベース)やFSLなどの様々なパッケージで解析されるが、完全な機能を持って、フリーで、オープンソースなPythonの代替になるものはなかった。機械学習や、自然言語処理、Webアプリーケーションの開発のためのパッケージは出現し始めたばかりだった。

今日では、科学計算のあらゆる方面のためのツールがPythonならすぐに手に入る。そしてますます多くの事例で、競合の美味しいところを奪っている。

Rを例にとって考えてみよう。Rが手軽にそのまま使えるというメリットは、大量のメモリを必要とするデータセットに対しては適応できない弱点として認識されていた(もちろん、あなたが時間を投資するならことができることは知っているが、多くの科学者は時間がない)。しかし、Rが大規模データに首を締められる方法や言語としての間抜けさを嫌っている人たちでさえも、しばしば迅速で重大なデータ処理が求められた時にRに戻らざるを得なかった。頑張ってPythonや他の高級言語にピボットや集約、整形、粉々にするためのコードを書くことはできたが、それをしようと思ったか？Rののような美しいパッケージは、他言語では実装に何時間もかかる処理を、2,3行のコードで実現できる。否定的な側面としては、学習曲線がそれぞれのパッケージの比較的複雑なAPIを学習するのに密接に関わる(例えばggplot2は信じられないほど表現力が高いが、学び直すのに毎回3ヶ月はかかる)。そして、Rの全般的なぎこちなさについて取り組まなければならない。しかし、概して明らかにその価値はあった。

現在に戻って考えよう。先週、誰かが2,3年前私がRで書いたシミュレーションコードについて聞いてきた。私は、それらについて調べるためにR Studioを叩いたが、R Studioをとても長い時間使っていないように思えた(実際には6ヶ月にみたない期間だと思うが)。NumPy/SciPyとMatPlotLib, pandas, statsmodelsの組み合わせはRを効果的に置き換え、そのことにすら気づいていなかった。あるときから、“本当の"データ分析が必要なときに、Pythonから逃げRを使うことをやめた。その代わり、pandasとstatsmodelsに自分のコードを移行することを始めた。そしてそれと同様のことが、機械学習(scikit-learn),自然言語処理(nltk),ドキュメントパース(BeautifiulSoup)、そして多くの他のPython以外で処理していたことで起こった。

開発や分析のすべてを一つの言語で行うことには、結局かなりの利点がある。第1には、1つの言語であらゆることができるようになると、Rubyは内包表記の代わりにブロックを使う、Pythonではarrayのサイズを取得するのにlen(array)をarray.lengthの代わりに使うなど、認知的ながなくなる。認知的なオーバーヘッドを最小限にして問題を解けばよくなる。もちろん、違うプロジェクトの異なる言語間でのインターフェースについて心配する必要もなくなる。Pythonでテキストをパースして、そして最終的に求める内部フォーマットにし、RやMATLABに他の分析をさせるために異なるフォーマットでディスクに書き出すことほどいらいらすることはない²。さらに、これらの類のことは重大なことではない。PythonからCSVやJSONを長時間かけて書き出して、Rに読み込むことはなくなる。しかし、それは納得がいく。統合的な開発はより複雑さを増す。なぜなら、益々多くのコードがディスクの中のあちこちに散らばるからだ(少なくともあなたが私の整理整頓能力と同じならば)。
これでは、インターフェースのためのつまらないラッパーを書くという「データ分析(笑)」で日が暮れてしまう。本来データをどう変換し、扱うべきかを考える代わりに。
つまり、あなたの美しい分析のためのコードが、醜いopen(), read()といったI/Oコールにまみれてしまうのだ！これらのオーバーヘッドすべてが、単一言語で書けば瞬く間に消える。

便利さは別としても、もう一点付け加えると、Pythonの科学計算のエコシステムではすさまじい量のPythonベースのツールが存在する。これらは、現段階でクラス最高のスコープ、使いやすさ、(Cバインディングの美徳であるところの)パフォーマンスを実現している。scikit-learnより使いやすい機械学習パッケージは想像できない。scikit-learnは、幅広いアルゴリズムが実装されており、、。同様に、pandasに移行してからRのデータ操作の機能を恋しくなったことはない。実際に、Rでは知らなかった新しいトリックをpandasで見つけ出している(それについてはいつか書こうと思う)。pandasがことを考えても、Rや他のツールに戻る理由がどんどん減っている。

気をつけて欲しいのが、私は他言語で行ってきたこと すべてを Pythonで実装しろと言っているわけではない。それはもちろん正しくない。例えば、いくつものRにあるような統計的なパッケージの代替になるものがない(lme4のPythonで使えるものがあれば、私に教えて欲しい)。信号処理の分野では、多くの人々がPythonで替えの効かないMATLABのツールボックスやパッケージとべったりだと思う。シビアな性能を求められる人や、とてもとても巨大なデータセットに対して取り組んでいる人にとっても、低級なコンパイル言語における非常に最適化されたコードの代替にはならない。従って、言うまでもなく私の言っていることがすべての人に適用されるわけではない。しかし、多くの科学者には受け入れられると睨んでいる。

個人的には、私のやることの90-95%がPythonで快適にこなせる所まで来ている。どの言語を新規プロジェクトで使用するかを決定するときに、「学びたい/使用に耐えられる中でのベストなツールは何か？」から「本当にPythonでやる方法はないのか？」と考えるようになってきている。時にはマイナス面があるということは否定しないけれど、概してこの考え方は良いことである。例えば、ほとんどのデータ分析をRで行っていた時代だったら、いろんな統計的なパッケージについて何をしているかを調べるためにこねくり回していたと思う。そんなことはもうしたくない。目的のない統計的な探求より、Rの知識をリフレッシュする苦痛に耐えるほうがマシだ。逆に、ただ単純に言語的な純粋さを保つために、他の言語より好きではなくても結局Pythonのパッケージに行き着く場合もある。例えば、RailsのORMであるActiveRecordは、明らかにPythonのSQLAlchemyより好きだ。でも、同一のアプリケーションでPythonとRubyのコードを混ぜることは許しがたい。明らかにコストはかかる。しかし、それはかなり小さいコストであり、個人的には、Pythonをほとんど全てに使うことで気にならなくなる。同じ経験をしてきた研究者を多く知っているし、これを提案することは不公平であるとは思わないが、今となってはPythonは多くのドメインにおける科学計算でデファクトとなりつつある。もしこれを読んでいるあなたがPythonに触れたことがなければ、今はじめるしかない！

追記:
この記事を書き始めてから書き終わるまでに(2週間くらいだろう)、2つのPythonベースのデータ可視化のパッケージを新しく見つけた。
Michael Waskomの (複雑な図をとても高度に抽象化してggplot2のように美しく書くことができる)と、Continuum Analyticsの (これはwebベースの可視化³を大きく変える可能性を持っている)である。Pythonのエコシステムのスピードを考えると、自分の考えを分析コードに直接してくれるPythonパッケージを使う時が来ることも夢ではないかもしれない。

訳注: ↩
2.
PythonとR等の間に、オブジェクトを内部的にやりとりできる様々なインターフェースがあることは知っている。私の経験上、これらは断然ポジティブではないし、常に複数の言語をまたぐために余計なコードを書く手間は依然として残っている。 ↩
3.
そう、あなたが聞いたことは間違っていない。Pythonを使ってwebベースの可視化をするのだ。Bokehは静的なJavaScriptとJSONをPythonから生成する。あなたはネイティブなJSコードを書くこと無く、魅惑的な図をウェブページでユーザに見せることができるのだ。 ↩

語感やリズムが楽しいハッとする絵本3冊

Sun, 08 Dec 2013 14:05:36 -0800

この記事はに参加しています。

まさか、パーフェクトRubyの感想を書く前に、まさかの読み聞かせアドベントカレンダーに参加することになりました。

我が家には3才児ともうすぐ半年になる二人の娘がいます。特に上の子は(娘にとっての)祖父母から、というサービスで毎月絵本が届くので、数々の絵本を読んでもらうのが大好きです。

ブッククラブは、絵本の専門店の店員さんが、年齢に合わせた絵本を選定して送ってきてくれるもので、定番どころだけではなく自分ではなかなか手を出さないような絵本も届けてくれます。

そんな中で、我が家に届いた印象深い3冊の絵本を紹介したいと思います。

だからこぶたちゃん

posted with at 13.12.06

北山葉子
偕成社
売り上げランキング: 429,943

おとうさんはぶた、おかあさんもぶた。だからぼくはこぶたちゃん。

にもあるように、0才児〜でも読めるシンプルな絵本。リズムがとても軽快で、聞いている子供を飽きさせません。

でも、引用したように、こぶたちゃんがこぶたちゃんであるという意味について書いているのは、ちょっぴり哲学的。「おおきくなるまでこぶたちゃん」という締めもトートロジーっぽいですが、小難しい言葉をこねくり回さないで、こぶたちゃんはこぶたちゃんなんだよ、ということを教えてくれます。

大きくなった娘は、「ぶーぶー」と合いの手を入れてくれるようになりました。

ころころころ

posted with at 13.12.06

元永定正
福音館書店
売り上げランキング: 22,901

元永さんの作品は、谷川俊太郎との作品である「もこもこもこ」も有名ですが、こちらの「ころころころ」を紹介したいと思います。( )

この作品は、色玉がかいだんみちやでこぼこみちを転がっていく様が描かれている作品で、とても鮮やかな色が子供に楽しく映るようです。

ともすると単調な内容ですが、バラエティ豊かな色彩感につられて、大人も「ころころころ」の表現の仕方を「でこぼこ感を出すにはどうしたら？」などと工夫したくなります。そうしていくうちに、日本語のアクセント表現の豊かさに気付かされました。

絵本を読んでいると思うのですが、読み手がどうやって子供を楽しませるか工夫の仕方は十人十色で、世界観の広がり方が違うのが素敵ですよね。妻と私とで読み方が全く違ったのに驚いた作品でも有ります。

たぬきのじどうしゃ

posted with at 13.12.06

長新太
偕成社
売り上げランキング: 271,955

衝撃的な絵本といえば、長新太の作品は群を抜くでしょう。この作品を読んだとき、五味太郎もかわいいものだな、と夫婦で大笑いしてしまいました。( )

「かいぶつがでたのです。たすけてちょうだい。」
さかなにたのまれたたぬきのおじさんは、こわごわ、かわのほうへいってみました。
すると、かわのなかからかいぶつがでてきました。
さあ、たぬきのおじさんはどうずるでしょう？

この絵本が届いて、娘に読もうと帯に書かれているこの文言を読んだ時、「？？？」と頭が一瞬真っ白になり、次に「そんなバカな」と思い読み始めるわけです。

帯は嘘をついていませんでした。
内容は意味がさっぱりわからない(突っ込みどころ満載の)超展開なので、是非一読していただきたいのですが、「ぽんぽんぶうぶうぽんぶうぶう」「げろげろげー」などオノマトペが多彩で、子供もリズム良く語感を楽しんでくれています。

こうしてみると、語感やリズムが楽しい本は、日本語の読むことを通じた表現の可能性を広げてくれて、子供についつい読んでしまいたくなりますね。

Kawasaki.rb #004を開催しました #kwskrb

Sun, 06 Oct 2013 05:10:10 -0700

9/25(水)にKawsaki.rbの第4回ミートアップを行いました。
今回は偶数回なので、居酒屋LTの回でした。

例によって、鍋をつつきながらパーフェクトRubyを読みました。
パーフェクトRubyは「2-1-3 トップレベル」まで行きました。

LT1: Sinatra Hijackerと（Rack Hijacking API）の紹介 (Minori Tokudaさん)

LT1本目は、Tokudaさん( )によるのご紹介。

Sinatra hijacker from Minori Tokuda

Rack Hijacking APIを使って、ソケットを横取りしてSinatraでWebsocketの通信をしよう！というライブラリです。

require 'sinatra/hijacker'

class YourApp < Sinatra::Base
 register Sinatra::Hijacker

 websocket '/ws' do
 ws.onopen{ws.send_data "hello"}
 end
end

こんなかんじで、シンプルにwebsocketの通信ができるようになります。お手軽ですね。

LT2: リアルタイム形態素解析 morph-websocket (@chezou)

リアルタイム形態素解析 morph-websocket / kawasaki.rb #004 from Aki Ariga

LT2本目は、自分ののご紹介とデモでした。websocketつながりということで紹介させていただきました。

形態素解析器Kyteaをバインディングしてwebsocket使って叩けるようにしましたよ、というお話です。
KyteaじゃなくてMeCabでもできるんですけど、作ったときはなぜかRubyバインディングがうまく呼べなかったのでKyteaだけにしたという感じでした。

次回は

ついに、mameさんによるの解説をしていただけることになりました！
募集はで近日開始する予定です。
10/23(水)はミューザ川崎音楽工房に集合だ！

Kawasaki.rb #003を開催しました #kwskrb

Sun, 06 Oct 2013 04:10:03 -0700

大分遅くなりましたが、去る8/28(水)にKawasaki.rbの第3回ミートアップを開催しました。

この回では、新しい試みとしての読書会を行いました。
本が販売されてから間もなかったのですが、会場いらっしゃった方の15名くらいが本を持っているというすごい状況になりました。

また、2本のプレゼンも非常に盛り上がりました。

さんにまとめていただいたtogetterは。

パーフェクトRuby読書会

まずは1章から突っ込みながら読んでいくことに。
途中でサンプルクラス中でputsメソッドをpustとtypoした時に、「pustメソッドを定義すれば行ける！」という展開があるなど非常にRubyらしさを満喫できました。
やはり前々から聞いていましたが、Rubyの全くの初心者向けというよりも、多少触っているけど色々知りたい！という人が読者層なんだなーという事を再確認しました。

@gotokenさんによるNumRuのお話

LLで数値計算といえば、PythonのNumPyが有名ですが、それを参考に作られたNumRuというRubyのライブラリがあります。
これは、FORTRANを裏で扱うことでRubyでも数値計算が高速に処理できるというもの(だと理解しています)。

NumRuが一番分かりやすく詳細に書かれているのは、でしょう。
Pythonのmatplotlibみたいに色々描画をすることもできるようです。

ただ、NumRuという名前があまり浸透していないのは、おそらく「」の名前空間としてNumRuという名前を用いているだけというのが大きいのかなー、というのと、地球惑星シミュレーションの人たちがメインで使っているので汎用的に使えるのかがあまりわからないところと、FORTRAN系のインストールが結構骨だというところでしょうか。。。

特に、FORTRAN周りのインストールはNumPy,SciPyあたりでも結構ハマるのですが、NumRuのHomebrewのFormulaをごとけんさんが作ろうとされたようですが、当日には間に合わず…。期待しております。

GSLとかもあるんですけど、このへんはNumPy,SciPyなどとの比較を行ったり、エコシステムが回るようになっていくと、Rubyで数値計算をするという話が増えるんじゃないかなー、と思っています。

@kishimaさんによるmrubyとwebrubyのお話

さんによる、mrubyとwebrubyのお話をしていただきました。
お忙しい中発表していただき感謝です。

内容は、mrubyの紹介とwebrubyの説明、TokyuRuby会議で使った抽選アプリのデモを見せていただきました。

(2013/10/30 スライドを追加しました！)

Introduction of mruby & Webruby script example from kishima7

の説明は、がわかりやすいですが、Emscriptenを使ってブラウザ上でmrubyを動かそうというものです。
LLVM,clangを経由してではありますが、JSとmrubyがつながるなんて胸が熱くなりますね。

デモは、webrubyとenchant.jsを使ったものになります。Tokyuの時のデモが以下のツイートで紹介されていたのでお試しください:)

LLまつりに参加しました

Sun, 25 Aug 2013 15:05:14 -0700

年に一度の軽量言語のイベント、LLまつりに行ってきました。

過去にも、LL Planet,Decadeと参加してきましたが、今年は初めてのマルチトラックになりました。

Ruby Kaigiもそうだったのですが、複数トラックあるのは良し悪しあるなぁというのが正直なところでした。
狭い方の会場が埋まってしまったりとか、裏番組が盛り上がっているのがTwitterで流れてくるとしまった！と思ったりとか(笑)

参加したのは、以下の3つのセッションを聞きました。

午前のプレゼンテーショントラック
とびだせ！LL〜リアル世界をプログラミングする〜
Infrastructure as LL 個人的に印象に残ったのは、の勉強会アンチパターンとInfrastructure as LLでした。

勉強会アンチパターン

内容は下記のサイトに詳しいですが、勉強会を主催・発表していく上でどうやったら継続的に開催できるか、というのがテーマ。

アンチパターンに入るのがラスト3分とか、色々突っ込みどころは大きかったですが、
個人的には、

勉強会勉強会というメタな勉強会(というかカンファレンス？)がある
「月に300以上のIT勉強会が開催している。その成功・失敗を共有できたらいいのでは」
いかに価値を創造するか？という点に共感、というか考えさせられました。

「開催/発表/参加コストよりメリットのほうが上回らないと続かない」という指摘もごもっともで、
いかにコストを下げるか/メリットを上げるかを考えていくのは大事だなーと。

ちょうど、を始めたこともあり、継続的に続けていけたらと思います。

Infrastructure as LL

伊藤直也( )さんと、ペパボの黒田( )さん、クックパッドの成田( )さんによる、Chefやpuppetなどを中心としたDevOpsの話。

特に印象に残ったのは、伊藤直也さんの

「昔、10台くらいのサーバにdeployをしてくれる人がいたが、typoとか繰り返すと怒られるのが嫌でdeployしづらくなった」

という経験から、DevOpsの流れを求めていたという話がある中で、

「今は、逆にInfra側が(流行に乗って)Chefとかを導入することが目的になって、Devとの距離ができているのではないか？原点を見失ってはいけない」

という指摘が、本質は何か？ということを考え続けて進めていくのが大事だと、改めて気付かされました。
誰が何を求めているのか？嬉しくなるのか？ということですよね。

結局、その流れで考えると、開発者にとってはHerokuのようなPaaS的なインフラを意識しないでデプロイできる環境がが求められていて、@sora_hさんがその環境を作っているなど、世の中としても方向に向かっているようです。

ちなみに、「入門Chef Solo」は5000部売れていて、おそらく日本で一番売れてる技術書の電子書籍では？とのことでした。

まとめ

今年は、チュートリアルセッションやプレゼンテーショントラックなど多様なセッションがあり、例年よりも偏らずに幅広い話が聞けて楽しめました。

The Idea of Northの楽譜を買った

Fri, 23 Aug 2013 15:05:09 -0700

オーストラリアのアカペラグループ、The Idea of Northの楽譜を少し前に購入しました。
混声4人のアカペラグループで、オリジナルやアレンジなどいい曲を書いています。
何より、SATB4人だと集めやすい。

こんな感じの曲を歌います。これはIsn’t She lovely?のアカペラアレンジ。

少し手間はかかりますが、からクレジットカード(Paypal)を使いネットで決済ができてPDFで送ってもらえるので、Rajatonの時に比べるとだいぶ楽です。

簡単に方法を書いていきます。

メールする

最初にして最大で、そして最後の難関。
にメールします。

例えばこんな感じ。

Hi,

I’d like to purchase following scores in PDF format.

楽譜A

楽譜B

How much do they cost?

すると、メンバーのNaomiさんが返信してくれます。
最初、事務スタッフ的な人が返信してくれるんだろうと思って5営業日返信なかった時に、「早くしてくれよ、円が安くなってるんだから」とか言ったのは平謝りするしかありません。

で、だいたいこういうことを言われます。

4人分のライセンスからしか売れないよ
4人ライセンス35豪ドルだよ
法に触れるから、4コピー以上しないでよ！絶対ね！ちなみに、追加ライセンスを買う場合は5豪ドルで買えます。

Paypalで支払う

ちゃんと行くと、Paypalの請求がメールアドレス宛てに来ます。

で、そこで支払いをしてください。Paypalアカウントを持ってると大分楽でしょう。
なくても、きっとクレジットカードがあれば支払えると思います。

メールで楽譜が送られてくる

支払いが確認されると、メールでNaomiさんからPDFが届きます。
Paypalのおかげで楽ちん！

この間たったの2週間

注意事項

英語でのやりとりなので、多少面倒なところがあります。
後、相手はツアーとか忙しい人なので、返信までが通常のお店の感覚でいては辛いです。

ちなみに、一度PDFを持っていると後はライセンスの購入だけなので、一瞬でかたが付きます。

もし、楽譜がほしいけど相談したい！という方がいらっしゃれば、コメントいただければと思います。

Kawasaki.rb #002 開催しました #kwskrb

Fri, 02 Aug 2013 23:08:43 -0700

ちょっと時間がたってしまいましたが、川崎地域でRuby関連の技術者が集まるKawasaki.rbのを、去る7/24に行いました。

今回は偶数回なので飲み回だったのですが、というお店で実施しました。焼肉LTの実現！

実は店のプロジェクターを使えるのは持ち込みDVDだけ、という罠があったのですが、なんとかプロジェクター持ち込みでスクリーンだけは使わせてもらえました。

二人に焼肉LTをしてもらいました！焼肉LTの様子はこんなかんじでした。

焼肉LTとは #kwskrb pic.twitter.com/mOJcRJhI5E
— Kentaro Goto / ごとけん (@gotoken) July 24, 2013

さん「Capistrano紹介」

ブログ記事も書いていただきました！ありがとう！

Capistranoの基本的な部分を紹介していただきました。
レシピを用意すれば、後からdeployする人はあまり意識しなくていいんですよね。

スライドはこちら

Capistrano紹介 at kawasaki.rb #002 #kwskrb from Tsubasa Yumura

さんgroongaの紹介の話

資料は

groongaとは？
ruby bindingのrroongaの話
ニコニコ動画のコメントを検索できるようにしてみた個人的には、groongaが鳥山明な名前にしか見えなくなったこと、おそらくニコニコ動画最古の"Ruby"という文字列がレッツゴー陰陽師に埋まっていたという事実が驚きでした。

今後やりたいこと

毎回のtalk以外にもやりたいことを色々と募集したいと思っています。

Ruby初心者のためにを毎回30分ずつくらい読むのはよさそうだなーという話をしていました。
むしろ今ならですかねー。標準添付ライブラリの解説も付いていることだし。

というわけで、こちらにコメント頂いてもいいんですが、良ければからご意見をくださいませ。

次回予告

次回は、8/28でミューザ川崎音楽工房会議室2でお会いしましょう！
さんによるmrubyのお話が予定されています。

発表者も募集中です！かあたりにご連絡ください！

Kawasaki.rb #001 第1回ミートアップを開催しました #kwskrb

Fri, 28 Jun 2013 21:06:14 -0700

6/26にKawasaki.rbの第1回ミートアップを開催しました。

ありそうで以外となかった、川崎でのRubyの勉強会です。
初心者からコアな人までざっくばらんに話が出来ればと思って始めました。
Doorkeeperの参加者を見ていただくとわかるのですが、予想以上に豪華な顔ぶれでhomeなはずなのに、ドキドキが止まりませんでした。(参加者の2割近くコミッターとか！！！)

当日、NKT77さんとたるいさん( )にトークをしてもらいました。

@kishimaさんによるtogetterまとめは。

01. NKT77さん「Hadoop with Ruby-僕がPythonを選んだ理由」

このタイトル自体は僕が付けた釣り仮題なのですが、内容としてはRubyをHadoop Streamingで使うときにHashが遅いという事例の紹介でした。( 恐縮したのはここだけの話)

20130626 kawasaki.rb NKT77 from nkt77

(2013/07/04 資料を追加しました)

ざっくりまとめると

Hadoop streamingでRubyを使うときに、Stringで100万程度のkeyのHashを作ると結構遅い
HashのLookupも非線形に速度が増えている
Pythonにしたら10倍速くなった(AWSのEMR料金も10分の1に！) という内容です。しかし、AWSのおかげで処理時間=お金に換算できる世界になったのが、改めてインパクトが大きいですね…。

なお、HashがPythonと比較して遅い原因としては、

GC
Hash関数がsiphashなため
rehashの際の閾値がRubyの方が保守的といった理由が考えられるとのことでした。(間違いがあればご指摘ください)

02. たるいさん(@taru) 「メモリアロケーションからみた拡張ライブラリに大切なこと」

メモリアロケーションからみた拡張ライブラリに大切なこと from Masaya TARUI

資料を見ていただければ内容はわかると思います。

初めての拡張ライブラリの作り方
ArrayがGCされないようにRB_GC_GUARD()しましょう
GC.stress = trueすると、GC強制的に走らせて再現しにくいバグを潰せる
NKT77さんが報告していたGCのせいでHashが遅いのはtrunkでは改善しました！(凄い！) 最後の、Hashの速度向上については田中哲さんも確認されたようです。

kawasaki.rb #001 であった、GC のせいで Hash が遅いが trunk は問題ないというのを追試してみた。たしかにそんなそういう感じになっている。 pic.twitter.com/mrtKNViEsq
— Tanaka Akira (@tanaka_akr) June 28, 2013

当日は散々、「Rubyの集まりじゃないのかよ！」とか「Pythonを宣伝する場所かよ！」とか突っ込まれていましたが、これで皆さん安心してHadoop StreamingでRubyを使ってもらえますね。

今後は、初心者にやさしいネタも考えつつ進めて行きたいと思います。（いらないのかな？)

次回は、7/24(水)に居酒屋LT(というか焼肉LT)をやりますので、準備ができましたら有る方はメーリングリストとDoorkeeperで告知しますので、興味があれば登録していただければと思います。

MacのiTunesでAirPlayが繋がらない時にやるべき1つのこと

Sun, 14 Apr 2013 03:04:52 -0700

先日、WindowsマシンをAirPlayサーバにするが、その後など各所でAirPlayサーバが盛り上がっています。

しかし、実際に使っていると、iPhoneからは飛ばせるのにMacのiTunesからだとAirPlayサーバにつながらない事態が頻発しました。(AppleTVでも同様でした)

調べてみたところ、どうやらMacのIPv6をオフにすれば良いとのこと。

Macのターミナルをたちあげて

networksetup -setv6off Wi-Fi

と入力するだけ。

どうやら、AirPlayサーバがIPv4でlistenしているのに、Clientがv6で話かけていることが原因のようです。

でも、この先IPv6オフにしていていいんだろうか。。。

参考URL：

WindowsでAirPlayを使うならShairport4w

Wed, 09 Jan 2013 03:01:45 -0800

シェアウェアではとかもあるけど、ServerがWindowsで良いのならSharport4wがおすすめ。

AirPlayはiOSやMacなどのデバイスから、Serverへ向かって音や映像を飛ばす規格です。そのうち、SHarport4wは音声だけを受け取るようにできる、AirplayサーバをWindowsに立てることができます。
我が家では、を手に入れてしまったのでこれを活用しない手はないと思いNetbookもどきにDACを接続し楽しんでいます。

AppleTvでは、複数のデバイスからAirplayを実行すると後から前の命令を奪うことができるのですが、Sharport4wは後の命令はエラーが出てしまいます。まぁ、古い再生を停止すれば良いのでそんなに問題が出ることはないと思います。

これで、Google Chromeのリモートデスクトップとかを頑張って使っていた生活からおさらばできそう。

あかぺら村のキリックさんがblogを再開されました！ - A Cappella - Best ofが素敵！

Wed, 09 Jan 2013 03:01:16 -0800

素敵なアカペラCDを通販されていたあかぺら村のキリックさんが、この度blogを解説されたようです！

その中で、素敵なCDを紹介されていたので、こちらでも紹介したいと思います。

amazon.co.jpのリンクは！

ドイツのアカペラを中心とした

です！

なかなか素敵な曲が多かったので、ご紹介します。

視聴できないものも、( なら全部視聴できます！)

[CD 1]

( )

[CD 2]

いやぁ、The Kings’ SingerはContempolalyの中でも輝いていますねー。すごいなー。

Autopagerize-rubyのMechanize版を作った

Wed, 09 Jan 2013 03:01:09 -0800

にも書いたけど、Ruby向けAutopagerizeをMechanize対応してみた。

特徴はMechanizeのrobots.allowをそのまま流用できること。
それ以外は正直httpclientの方が早いと思います。

いまいちよくわからないのが、forkした場合のgemspecの扱いとpull requestすべきか否か。
オリジナルとは違うhttpのclientしてるからそのままでいいか。

11/28にThe Real Groupのニューアルバムが出る！

Sat, 17 Nov 2012 01:11:17 -0800

2012/11/28にThe Real Groupのニューアルバム、がでるようです。

The Real Christmasに続きクリスマスアルバム第二弾ですね。楽しみです。

しかし、本人達がFacebookで自分たちの演奏動画を投稿する時代なんですね。

パワーポイントに色づけしたソースコードを簡単に貼る方法

Mon, 12 Nov 2012 01:11:33 -0800

パワーポイントに色づけしたコードを貼るのって、皆どうやってるのか不思議に思っていたのですが、どれもちょっと面倒だなという感じでした。

GNU Source-highlightを使う方法：
SCiTEを使う方法：
Visual Studioを使う方法など: 色々ある中で、その本質が「HTML等の形式でクリップボードに保持して、パワーポイントに貼り付ける」、ということに気づいたので、試しにGithubにGistで書いてみたら見事成功しました。

手順は至って簡単、

色づけしたいコードをで作成(ものによってはPrivateにしておく）
Gistからコピーして、パワーポイントで「形式を選択して貼り付け」で「HTML形式」で貼る 2．は最近のPPTだと、貼った後に横に出現するアイコンから、「元の書式を保持する」を選ぶともっと楽かもしれません。

これは便利だ！

Websocketを使ってリアルタイムに形態素解析をするmorph-websocketを作ってみた

Fri, 09 Nov 2012 20:11:51 -0800

morph-websocket画面

WebSocketを使ってリアルタイムに形態素解析結果を出力する、morph-websocketを作りました。

テキストボックスに入力すると、リアルタイムで形態素解析結果が出力されます。

ソースコードは、いつものようにgithubに置きました。

思いついたので、勢いで作りました。今まで、バッチ的にまとめて処理をしていたものに対して、リアルタイムで解析結果が変われば、何か見える世界が変わるかなーと思ったのですが、そんなに変わりませんでした。変わったのは寝る時間だけか。

最初はMeCabを使おうと思ったのですが、0.994のrubyバインディングがCreateModelできない現象にぶち当たって諦めました。なので、とRuby使ってます。

あ、ついでにMykyteaがKyTea 0.4.2に対応しました。

参考URL:

Ola Gjeiloの"Sunrise Mass"がゲーム音楽みたいで格好いい

Thu, 01 Nov 2012 02:11:53 -0700

でさんのキャロルが特集されていました。

Ola Gjeiloさんの名前は良く聞くものの、曲は聴いたことがなかったので調べてみたところ、
キャロルより格好いい"Sunrise Mass"を見つけて大興奮していました。
Steve DobrogoszとEric Whitacreを混ぜた感じというイメージです。

特に3曲目のCityが大好きです。
結構、弦が格好いい曲かなーと思ったら、キャロルは素敵なアレンジです。なかなか歌い甲斐がありそうです。

ライブ録音がされているようでしたので、思わず購入してしまいました。

Coventry Carol
[soundcloud url=" " iframe=“true” /]

The First Noel
[soundcloud url=" " iframe=“true” /]

楽譜はPanamusicaさんで買えるようです。
これは人気が出るわけだなー。

Amazonの1GB/1円ストレージGlacierをコマンドラインで使うglacier-cmdの使い方

Wed, 31 Oct 2012 05:10:45 -0700

大分前に発表されました、AmazonのというサービスをLinuxサーバから使用したいと思い、Javaでわざわざ書くのも面倒だと思い色々探していたところ、glacier-cmdというツールが良い感じだったのでご紹介します。

ちなみに、WindowsならなどのGUIソフトが楽です。

Glacierの特徴

Glacierは1GB/1円でデータが無制限に保管できる
Upload以外の作業は4時間待たされる
Download時の転送料は普通にかかる(＝そこまで安くない)

安いのには理由があります。Upload以外の作業は、大体Jobを実行してから4時間待たされるのです。
たとえば、Downloadする前に、このファイルを落としたいんだけど、とJob投げて、準備ができたらダウンロード、という流れです。
また、最新のファイルリストを取得するにも4時間待たされます。(なので、大体のクライアントがファイルリストをローカルでキャッシュしています)

後、Download時の転送料金は相対的に高く感じます。10TBを保管するのにはus-eastのリージョンで、月$100(約8千円)なのに対し、同量をDownloadした場合$1,228(約10万円)かかります。
詳細は下記を参照ください。

削除自体は無料なので、通常のデータを置くのには適さず、二度と見ないかもしれないけど念のためとっておきたいといった類のデータの保管に向いています。Amazon自身もあまり取り出さないことを想定しているようです。

まぁ、テープドライブを使って自前で管理するよりは楽できるかな、という感じなのでしょうか。

glacier-cmdの利用前に用意するもの

AWSのAccess Key
AWSのSecret Key
Amazon SimpleDBのドメイン名(後述) そもそも、AWSのアカウントは持ってることを前提にします。そうすると、きっとAccess KeyとSecret Keyも持っていると思います。

SimpleDBとその利用目的

SimpleDBとは、Amazonが提供するHTTPで利用可能な簡単なDBです。

Glacierはファイルダウンロードや削除時にはハッシュのようなアーカイブIDで操作をし、
それらの情報を記憶するためにglacier-cmdはSimpleDBを利用しています。

SimpleDBはSQLのTableの概念に相当するdomainというものがあります。
例えばこれを、ユーザごとに作成することで、各自のファイルのリストを管理します。

SimpleDBのdomainの作成方法

私自身は、RubyからSimpleDBを扱えるというgemでdomainを作成したのですが、
既存のツールで何とかしたい場合は、ブラウザベースのものを使うのが簡単かと思います。

なお、right_awsの利用には下記を参考にさせていただきました。

下記ツールを解凍し、index.htmlを開く(Chromeでは動作できず。Firefoxは動作確認済み)

Explore APIからCreateDomainを選択し、Domain Nameにmy-glacier-dbなど適当な名前を入れて、Invoke Requestをクリックする

参考：

glacier-cmdのインストール

 $ mkdir ~/env $ cd ~/env $ virtualenv glacier $ source ~/env/glacier/bin/activate (glacier)$ git clone https://github.com/uskudnik/amazon-glacier-cmd-interface.git (glacier)$ cd amazon-glacier-cmd-interface (glacier)$ python setup.py install

今回はvirtualenvを使っているのですが、globalな場所にインストールしたい場合は、適当な場所にインストールするのが良いでしょう。
基本的に、次回以降glacier-cmdを利用する際は source ~/env/glacier/bin/activateをしましょう。

glacier-cmdの初期設定

~/.glacier-cmdに設定を書き込む
例)

[aws] access_key=AWSアクセスキーを書く secret_key=AWSシークレットキーを書く [glacier] region=us-east-1 bookkeeping=True bookkeeping-domain-name=作成したSimpleDBのdomain名を書く logfile=~/.glacier-cmd.log loglevel=INFO output=print

Glacierのvaultと呼ばれるデータの保管場所を作成する

$ glacier-cmd mkvault Test

```
vaultの作成結果を確認する
```

$ glacier-cmd lsvault

以上でGlacierの使用準備は完了です。

利用するコマンド群

後は必要に応じて以下のコマンドを利用してください。

下記のコマンドを利用時は毎回

$ source ~/env/glacier/bin/activate

を実行してください。

データをuploadする。(upload時に発行されるアーカイブIDが今後の利用に重要)

$ glacier-cmd upload Test /path/somefile –description “Test data”
ファイルリストを取得する(ためのjobを発行する。実際に取得するには4時間後、再度実行する)

$ glacier-cmd inventory Test
SimpleDBに格納されたファイルリストを取得する

$ glacier-cmd search Test
データをダウンロードする

$ glacier-cmd getarchive Test アーカイブID

…4時間後

$ glacier-cmd download Test アーカイブID –o outfilename

データを消去する

$ glacier-cmd rmarchive Test アーカイブID
Jobの実行状況を調べる

$ glacier-cmd listjobs

ちなみに、searchコマンドはglacier-cmdが利用しているSimpleDBにファイルリストをキャッシュしているものを取得するだけです。なので、FastGlacierなど別のツールでUpload,Downloadした際には齟齬がでてしまいます。
その場合は、inventoryコマンドを2度4時間程度の間隔を空けて行うと反映されると思います。

結構面倒ですが、とにかくいつ使うか分からないデータや、手元の外付けHDDにとりあえず保管してあるけど一応冗長性を持たせたい、とかいう用途には良いでしょう。

東京ゲームショーで売っていたのSymphonic Fantasies Tokyo のCDがネットで買える！

Fri, 05 Oct 2012 02:10:55 -0700

Source: via on

最近お世話になりっぱなしの、で知ったのですが、東京ゲームショーでSymphonic Fantasies TokyoのCDが販売されていたようです。

正直、本家のWDRの演奏よりも東京混声合唱団のクオリティが高く、素晴らしい演奏でした。ドイツ版をゴミ箱に捨ててでも日本版のCDが欲しかったのです(ドイツ版もクオリティは高いですよ、ええ)

しかし、終わってしまったゲームショーを悔やんでもしかたありません。

ところが、symphonic fantasiesのオフィシャルに飛んでみると、なにやらSymphonic Fantasies Tokyoという怪しいリンクが。

クリックしてみると、売っているではありませんか！

というお店で普通に売っていました。支払いは、クレジットカードまたはPaypalで支払えるので比較的簡単に買えます。でも、届くまでには2週間以上かかるんじゃないでしょうか。まだ来ていません。

これで買いそびれた人も、素晴らしい日本の演奏を堪能できますね！

一応、イベント会場限定ということなので、まだ買うチャンスはあるようですが、ネットで買った方が早いと言う人はオススメです。

参考URL:

Finlandの伝統的な楽器カンテレをモダンに演奏するIda Elina

Thu, 04 Oct 2012 02:10:52 -0700

Finland大使館の後援の元行われた、モダンカンテレ奏者Ida Elinaのライブ。

前の記事でも少し紹介しましたが、カンテレというギターを寝かしたような伝統楽器を、押尾コータローのようにリズミカルに演奏するIda Elinaさんの曲が素敵です！

シベリウス音楽院在学中に北海道教育大学に留学していたようです。札幌での演奏は多かったようなのですが、今回は東京にも来てくれました。
しかし、札幌とフィンランドは気候的にまだ近いのかな？

Ida Elina-Good News

彼女の曲は、フィンランドぽい暗さや重々しさよりもすがすがしさを感じさせます。
これで25歳とはこの先が楽しみであります。

Ida Elina - Unelmien Keikka

Ida Elina - How sweet is the love

個人的には初期に作ったというFinland語の曲も、言葉の響きが暖かくて好きです。

Distant Worlds music from FINAL FANTASY THE CELEBRATIONのチケット応募開始！

Tue, 02 Oct 2012 19:10:54 -0700

さんで知ったのですが、FINAL FANTASYのオフィシャルな演奏会のチケット応募が始まったようです。

公式サイトは。

応募受付期間が、10/1（月）から10/14（日）と短めですので予約はお早めに。

日程は、下記の通りです。

・2012年12月26日(水)　18:00開場/19:00開演　　会場：東京国際フォーラムホールA(東京)
・2012年12月29日(土)　17:30開場/18:00開演　　会場：グランキューブ大阪(大阪)
・2012年12月31日(月)　17:00開場/18:00開演　　会場：東京国際フォーラムホールA(東京)

いや、この日程は厳しいなー。

参考URL:

想像もしなかった場外戦〜iPhone 5とAndroidの対決がこんなところまで！！ #TEAMiPhone と #TeamDROID の戦い

Tue, 02 Oct 2012 15:03:48 -0700

一度は聞いたことがあるiPhoneの着信音のあの音から、こんな曲ができるなんて！

このブログでもたびたび紹介している多重録音アカペラのPeter Hollensが新作を発表していました。
タイトルはなんと、“iPhone vs Droid”！あのお馴染みの(?)着信音のメロディに歌詞をつけてR&Bシンガーのと対決しています。

Peter Hollens のiPhone versionはこちら。

J RiceのDroid versionはこちら。

なんでも、お互いYouTubeのチャンネルの登録対決をしているようです（笑）。

そして、まさかのと、Google play、で買えるようになるまでのが用意されているようです（笑）

歌詞もYouTubeで見れるのですが、相変わらずのApple信者とそれをDisるDroidファンという構図になっています。

It just works
it doesn’t matter what the specs are
iphone 5
might even trade my wife for

（ちゃんと動いてる。iPhone 5のスペックなんて問題じゃないんだ。妻と交換したって良い）

とか、「妻と交換しても良い」とか、良くできた信者ですね（笑）

それに対する、Droid派の反論が笑えます。

You just dropped a thousand bucks at the apple store
And bought a thinner version of the iphone 4

(Apple storeで数千ドルも不意にした。そして、iPhone 4の薄いバージョンを買ったんだ）

「薄いバージョン」とか！（笑）Droid派の反論は続きます。

no navigation
no public transportation
no steve to fix it
you’ll never find youre way back home

(ナビもない、交通機関もない、直すSteveもいない。家に帰ることだってできやしない)

時事ネタを取り込んでくるとはやりますね。

まさか、a capplla界にまでこの対決が繰り広げられるとは！！

●当ブログのPeter Hollensの記事はこちら

harmonia ensembleが新しいCD"翼-WINGS-"を9/29に発売

Fri, 28 Sep 2012 02:09:36 -0700

合唱楽譜でお馴染みのが、で紹介していたので知ったのですが、元World Youth Choirのメンバーなどで構成される合唱団がニューアルバム"翼 -WINGS-“を明日9/29に発売するようです。

コンクールの全国大会の演奏や、定期演奏会の演奏などが詰まっているようです。
前作も素晴らしい出来だっただけに、今作も期待であります。一度生で聴いてみたいなー。

プロモーション用のYouTubeの楽曲は相澤直人さんの宿題が用意されているようです。

前作の” “のぜんぶ（相澤直人作曲）も素敵でした。

販売元のブレインのサイトは。
合唱楽譜と一緒に買いたい方は、Panamusicaさんのへどうぞ。

収録曲は以下の通りです。

宿題 / 相澤直人
追分節考 / 柴田南雄
鳥籠 / 高橋悠治
島へ / 武満徹
○と△の歌 / 武満徹
翼 / 武満徹
死んだ男の残したものは / 武満徹
小さな空 / 武満徹
明日は晴れカナ、曇りカナ / 武満徹
ソーラン節 /北海道民謡（三善晃）
花 / 喜納晶吉（信長貴富）
Io mi son giovinetta / C.Monteverdi
Jesu,meine Freude / J.S.Bach
Es ist nun nichts Verdammliches an denen /J.S.Bach
Ihr aber seit nicht fleischlich / J.S.bach
Weicht,ihr Trauergeister / J.S.Bach
Virga Jesse / A.Bruckner
Tristis est anima mea / F.Poulenc
Christus est natus / D.Mocnik
Ne cakaj na maj / B.Lesjak
Heal the world / M.Jackson(C.Borela)

SINGSとDobrogoszが再び共演

Tue, 25 Sep 2012 15:03:37 -0700

スウェーデンのJazz Pianistであり作曲家でもあるSteve Dobrogosz氏と、素敵な実力派合唱集団SINGSが日本で再び共演することが決まったようです。

日時：2012年10月20日(土)
会場：日本基督教団東京山手教会
開場：17：30 開演：18：00
チケット：全席自由 2000円

個人的には、Lord I’m Freeの演奏がまた聴けるのかと思うとワクワクします。

生演奏への期待と価値

Mon, 24 Sep 2012 15:03:32 -0700

[gallery]

ここ最近、意図せずライブや演奏会に連続で参加させていただいており、非常に優秀な音楽消費者をしています。

それぞれの演奏(といっても一個はシンポジウムだが)の感想を書こうとも思っていたのだが、それよりも「生演奏で聞けて嬉しかった」「生で聴いたのにガッカリだった」という現象に出くわして、何故両極端なことを思ったのだろうと考えていたので、ここに少し書いてみようと思います。

生演奏で聞けて嬉しかったライブ達

最近、2つのライブに出会いました。一つ目は、クロノトリガー/クロスなどの作曲でお馴染みの光田康典氏のシンポジウムが9/13に行われました。(詳細なレポートはが詳しいので是非お読みください。)

そこでは、と呼ばれる尺八の神永大輔氏を中心とした、ヴァイオリン、ベース、ドラム、キーボードという異色の編成のバンドのライブ演奏が披露されました。特に、神永氏はクロノクロスの「時の傷痕」を聴いて光田氏の曲に惚れ込み、そのメロディから尺八を始めることを志されたそうです。(実際に原曲も尺八だったとは後から気づいたそうです)

神永氏もそうですが、ベースの岩田氏も光田氏の大ファンとのことで、演奏者が大興奮しておりました(笑)確かに、作曲者の前で演奏する機会って中々ないですもんね。
シンポジウム自体無料で開催されたのですが、とても愛のある演奏で幸せな空間でした。特に自分の好きな時の傷痕が聴けたのはとても良いアレンジで鳥肌物でした。小さなスタジオが一体になったのを思い出します。

もう一つ、素敵なライブを聴いてきました。
フィンランドの伝統的な楽器カンテレを、モダンに演奏するIda Elinaさんのライブでした。
Unelmien Keikkaという素敵な曲を紹介します。

そもそも、カンテレという楽器を知ったのが3日前だったのですが、ふらっと行ってきました。（YouTubeを見て良さそうだなとは思っていました)彼女は札幌に留学生として音楽を学びに3年前日本に来たそうで、そこで出会った方々や体験を通じて演奏活動を続けることを決意されたんだとか。

彼女の演奏する曲は、明るくきらびやかな和音を中心に使っており、とても聴いていて元気になります。(こんなことを言っては失礼かもしれませんが、フィンランドの音楽って割と重々しい曲が多いイメージなんですよね。好きなんですけど)たとえば、Good Newsという曲なんかがそういうイメージになります。

ライブのお値段も良心的で軽食という名の軽いビュッフェ付きで2000円でしたので、お釣りが帰ってくるんじゃないかという勢いでした。特に、「さくら」や「あかとんぼ」のカンテレアレンジを織り交ぜた、日本人への配慮がとても嬉しく、小さな箱でしたが純粋に楽しめました。

期待していたPress Start 2012

は、FFの植松伸夫氏やスマブラの桜井政博氏、指揮者の竹本泰蔵氏らが企画をしている「ゲーム音楽の紅白」(桜井氏談)です。過去に2回ほど聴きに行ったのですが、特に2010年の公演が素晴らしく鮮明に記憶に残っています。
今年はSkyrimのOpening Themeやゼルダの伝説スカイウォードソードの曲を演奏するなど期待をしていました。Skyrimの曲はPeter Hollensというドヤ顔で有名( の村長談)な多重録音アカペラーとヴァイオリンのLindsey Stirlingとの演奏が格好いいです。1人の声と1本のヴァイオリンで、、、というくだりにはつっこまずにいられませんが。

東京フィルの安定した演奏で、竹本泰蔵氏の熱い指揮による素晴らしい演奏がBunkamuraオーチャードホールにて行われました。
ですが、大好きなSkyrimを聴いてズコーッとなってしまいました。

Press Startというのは席の当たり外れがものすごく大きいんですね。Bunkamuraオーチャードホールには初めて行ったのですが、2階席のサイドバルコニーではない端っこの席になりました。で、2009年の「エースコンバット・ゼロザ・ベルカン・ウォーのギターが全く聞こえなかった」という記憶が蘇りました。

悪い予感はやはりあたりました。PAさんはおそらく1階席の中央後ろに居たためでしょう、2階席の端っこでは音のバランスがよろしくありません。弦の音が団子になって左のスピーカーからのみ聞こえてくる。しかも、高音のみが飛んでくる位置だったため、刺さる刺さる。 「何故、コンサートホールへ来て、スピーカーの定位を気にしたり特性を気にしなけりゃならないんだ」 というのが率直な感想です。基本的にスピーカー越しに音を聞かせるようなバランスだったため、せっかくの繊細なオケの楽しさが台無しでした。倍音もほとんど感じられないし。

後、どうしてオケ判の合唱って適当なんだろうと思うくらい、合唱が残念でした。10人ほどの編成でマイクを使ってフルオケに対して演奏というのが無謀だと思うのです。しかも、マイクに乗らない発声だったのか、Skyrimの迫力もアンプで増幅しました感が……。
リトルジャックオーケストラとChor Crystal Manaの演奏はアンプラグドだったこともあるでしょうが、非常によいバランスで感銘を受けたのです。だからこそ、ゲーム音楽のオフィシャルの集大成であるPress Startには期待していましたが、裏切られてしまいました。(しかしながら、東混のSymphonic Fantasiesは別格でしたね)

PAって凄い大事ですね。(オーケストラの演奏会にPAがいるかはよく分かりませんが)ちなみに、ソロの歌物は良く聞こえましたよ。

何が違ったのか？

漠然とではありますが、箱の大きさに比例してチケット料金と期待が大きくなってしまうのだろうなー、と思っています。

集客力のある大きな箱では、それに見合った企画やゲストと、それに見合ったお値段が設定されます。それ自体は自然な事だと思うのですが、エンターテイメントとしてのライブが目指す方向が音楽以外の所に軸足を置いてしまったら、少なくとも自分が求めるライブではないのだろうと思います。

後、お値段に見合ったトータルなクオリティを無意識のうちに求めてしまうのでしょう。
プロのケーキ職人と素人の違いは、作る側の状況によらず安定した味を保てること、と聞きます。指揮者が良ければいい、編曲者が良ければいい、オケが良ければいい、それでもまだ足りない時があるんだなと思い知らされました。

つまり、Press Startはプレオーダーでチケット買えないと地雷踏む可能性があって、怖くていけないということですね。。。

後は、Ida Elinaさんは少し違うかもしれませんが、ゲーム音楽にとっては演奏者の曲に対する愛も大きいと思います。そこは、プロオケだとどうしても薄れてしまいがちですしね……。

個人的には、Press Startという企画自体は大好きだし、ゲーム音楽を引っ張っていただきたいと思っているのです。ゲーム業界が少し元気がない状況ですが、ゲーム音楽がもっともっと広がってくれると嬉しいと思います。
自分にできることは何もないのかなぁ。

pficommonのpfi::text::jsonでシリアライズ/ デシリアライズしてみた

Sun, 12 Feb 2012 04:02:30 -0800

のjsonライブラリを試してみました。
pficommonのjsonライブラリはboostみたいにjsonと自分で作ったクラスのオブジェクトとのシリアライズ/デシリアライズができるのがとても魅力です。
その一方で、結構には書いてないことが色々あったので、メモしておきます。

いつものようにコードはgithubにあります。

今回のポイントは以下の通りです。

wafの使い方
基本的なアクセスの仕方
stringとjsonの相互変換
オブジェクトとのシリアライズ/デシリアライズ

1.wafの使い方

wafはmakeの代わりのビルドシステムで、pythonでビルドします。詳細な使い方はを参考にしてください。
基本的には、wscriptと呼ばれるMakefileのような物をソースコードがあるディレクトリにそれぞれ書きます。
この際、各ディレクトリに置かれたwscriptが再帰的に呼ばれるので、モジュール毎にディレクトリを切り分けている場合は、そのモジュールの必要なライブラリなどを書いておくべきです。

例としてsrcディレクトリにあるwscriptをのせます。

def build(bld): bld.program( source = 'json-test.cpp', target = 'json-test', includes = '. ../include', lib = 'pficommon\_text pficommon\_data', use = 'JSON TEST' )

見れば分かると思いますが、sourceにソースとなるファイル、targetにビルドした後の実行ファイル名、includesにヘッダーファイルの場所を書きます。libにはライブラリ名を列挙します。このとき、複数の場合はスペースで区切ればOKです。

で、できたらこんな感じでビルドします。

./waf configure ./waf

2.基本的なアクセスの仕方

良くあるmapみたいなアクセスをしていって最後にjson_castをします。

cout \<\< json\_cast(js["user"]["id"]) \<\< endl;

3.stringとjsonの相互変換

基本的にはstringstreamを経由します。

実際にはこんな感じでします。

#include \<pficommon/text/json.h\> #include \<sstream\>using namespace pfi::text::json;using namespace std;namespace util{ json string\_to\_json(string str){ json js; stringstream ss(str); ss \>\> js; return js; } string json\_to\_string(json js){ stringstream oss; oss \<\< js; return oss.str(); } }

こんな感じで使います。

json js = util::string\_to\_json("{\"foo\":true, \"bar\": \"buzz\"}"); string str = util::json\_to\_string(js);

4.オブジェクトとのシリアライズ/デシリアライズ

ドキュメントにもありますが、自分で作ったクラスのjsonへのシリアライズをしたい場合は、シリアライズしたい変数をMEMBERマクロで登録しておきます。
boostのような感じですね。

class SouvenirDef {public: pfi::data::optional\<std::string\> name; pfi::data::optional\<int\> price; pfi::data::optional\<bool\> famous; pfi::data::optional\<bool\> funny; template \<class Archive\> void serialize(Archive &ar){ ar & MEMBER(price) & MEMBER(famous) & MEMBER(name) & MEMBER(funny); } };

シリアライズしたいときは、to_jsonを、デシリアライズをしたい時はvia_json_with_defaultを使うと良いでしょう(json_castでやると不足したkeyがあるとbad_castになってしまうので)。

stringstream ss("{\"name\":null,\"famouse\":true}"); Souvenir sv2; ss \>\> via\_json\_with\_default(sv2); cout \<\< to\_json(sv2) \<\< endl;

いくつか注意点・ポイントです。この辺、知っておくと無駄にハマらないかと思います。

基本的な型はpfi::data::optionalを使う。使わないとnullをシリアライズできない。シリアライズしたい型はpfi::data::optionalを使う。~~デシリアライズしたい場合は使わない。~~
配列を表したい時はvector, ハッシュを表したい時はmapを使う。
pairとmapは使えない。特に1点目ですが、サンプルコードのSouvenirクラスを見てください。

class Souvenir { public: std::string name; int price; pfi::data::optional<int> max_price; bool famous; bool funny; template <class Archive> void serialize(Archive &ar){ ar & MEMBER(price) & MEMBER(famous) & MEMBER(name) & MEMBER(funny) & MEMBER(max_price); } };

このmax_priceのようにpfi::data::optionalとすると、変数に値が入っていない場合にto_jsonでシリアライズするとnullになってくれるのですが、以下のように直接クラスの値を参照しようとすると、値の有無が0/1で取得できる形になってしまいます。

[20120320追記]

optionalで宣言した型を取得する場合は、ポインタのように*演算子でアクセスするようです。
が参考になるそうです。@eiichiroi さんありがとうございます！

pficommonのoptionalの件(jsonと、メンバにoptionalを持つユーザ定義型の相互変換)についてですが、optionalも(デ)シリアライズできるようになっていました。optionalな変数へのアクセス方法を少し変えて貰えれば大丈夫だと思います

— Eiichiro Iwata (@eiichiroi)

ドキュメントに書かれていなくて申し訳ないのですが、optionalはポインタのようなものです。値を取り出すときには、*(sv2.max_price)のような感じで取り出す必要があります。ポインタと違う点はoptional間で値を共有しない(コピーする)ところです

— Eiichiro Iwata (@eiichiroi)

> [@chezou](https://twitter.com/chezou) 正確な挙動についてはsrc/data/optional.hを、使い方の雰囲気についてはboost optionalでググるとなんとなく分かるかと思います。もし何かうまくいかない点や分からないところがあったら、また教えてください
>
> — Eiichiro Iwata (@eiichiroi) [2012, 2月 28](https://twitter.com/eiichiroi/status/174541460249645057)
<script async src="//platform.twitter.com/widgets.js" charset="utf-8"></script>
stringstream ss("{\"name\":null,\"famous\":true,\"max\_price\":1200}"); Souvenir sv2; ss \>\> via\_json\_with\_default(sv2); //max\_priceは型をpfi::data::optional\<int\>にしているため、1/0の値で格納される//アクセスは\*(max\_price)でアクセス cout \<\< "name:" \<\< sv2.name \<\< " price:" \<\< sv2.price \<\< " max\_price:" \<\< \<strong\>\*(sv2.max\_price)\</strong\> \<\< " famous:" \<\< (sv2.famous ? "true" : "false") \<\< " funny:" \<\< (sv2.funny ? "true" : "false") \<\< endl; //max\_priceをjsonにする場合は問題ない cout \<\< to\_json(sv2) \<\< endl;
このため、 **jsonを入力としてデシリアライズしたい場合はpfi::data::optionalを利用しない変数を、シリアライズしてjsonに出力したい場合はpfi::data::optionalを利用した変数にしないといけません。**

きちんと*演算子でアクセスすることで、入出力対象な形で利用できます！

それでは、pficommonで楽しいJSONライフを！

Mercurialと親和性の高いリポジトリブラウザRhodeCodeをインストールしてみた

Sat, 07 Jan 2012 01:01:19 -0800

Mercurialと連動するブラウザベースのリポジトリ管理システム、を導入したのでその際のメモを書き残します。
一言で言うと、githubみたいなものを社内などで運用したいというニーズに応えるものです。
gitlabとかも試してみましたが、ドツボにはまったので結局RhodeCodeに落ち着きました。

デモは

RhodeCodeの特徴

ブラウザ上でリポジトリを作成できる(これ重要)
diffやコミットログがブラウザ上で見られる
ブランチも可視化してくれる
プロジェクトをグループでまとめることもできる
意外と導入、運用は簡単だった
そのうちgitにも対応する予定らしい
あまり日本語で情報が少ないかも

Rhodecodeのインストール

基本的にオフィシャルに従う方針で行きました。
ただし、virtualenvを使った方が環境を汚さないと思うので、そうすることにしました。

ユーザは、適当にadduserで作ってください。
今回はhgというユーザを作りました。

adduser --system --home /home/hg/ --group --shell /bin/bash hg sudo mkdir /var/www/rhodecode-venv sudo chown hg:hg /var/www/rhodecode-venv virtualenv --no-site-packages /var/www/rhodecode-venv # hgが一般権限で利用できるようにする必要がある source /var/www/rhodecode-venv/bin/activate sudo mkdir /var/www/rhodecode sudo chown hg:hg /var/www/rhodecode cd /var/www/rhodecode pip install rhodecode

RabbitMqの導入

一応入れました(結局使ってないかも？)

sudo apt-get install rabbitmq-server

Rhodecodeの設定

cd /var/www/rhodecode paster make-config RhodeCode production.ini paster setup-app production.ini

途中で、リポジトリの場所、adminユーザの名前、パスワード、メールアドレスが求められる
実行する

paster serve production.ini

問題点

・UnicodeDecodeErrorが出る
hgユーザの言語設定を下記で解決。
日本語ja_JP.UTF-8にしてMercurialをインストールすると、どうやらRhodeCodeがこける模様。

export LC\_ALL=C

rhodecode-init.shを作成。

./rhodecode-init.sh

#!/bin/bash export LC\_ALL=C source /var/www/rhodecode-venv/bin/activate cd /var/www/rhodecode paster serve production.ini

実行方法

とりあえず、起動時にrhodecode-init.shを実行することで運用しています。
本格的に動かすならinit.dなどに書いた方がいいかも。

sudo -u hg ./rhodecode-init.sh

2012年の抱負

Sun, 01 Jan 2012 04:01:58 -0800

あけましておめでとうございます。

昨年は妻と子どもと共に楽しい一年を過ごしました。

パパ業一年目は、自覚を育てるとともに、自分以外の人を中心に生活を回すということを定常的に行うという、今までの人生になかった経験を積んできました。

エンジニアとしても、Webアプリ動画あったーの公開や、KyTeaのラッパーMyKyteaの公開など、ちょっとしたものではありますが作ったものを公開するということが出来ました。

さらに、普段はアクセスの貧弱なblogではありますが、iMessageやiPhone for Everybody、MeCab の記事が未だにアクセスいただいているように、調べても見つからなかったこと、自分で試した解決した事に価値を見出してもらえるということがわかりました。

そんなわけで今年はこんな一年にするぞ、という思いを述べて行こうとおもいます。

基本方針:家族との時間を取りながら、自分のスキルも磨いていく

昨年は、兎に角はじめてのことばかりだったので、子どものことだけを考えてきた一年だったとおもいます。今は少しずつ余裕とは呼べませんが、隙間が作れるようになってきたので、自身のスキルを磨いて行こうとおもいます。

具体的には以下の通りです。(意気込み順)

Rubyistと言えるくらいRubyと仲良くなる(メタプログラミングRubyを読むことから)
アルゴリズムを実装しながら学ぶ(良書を探すところから)
勉強会に参加して社外のエンジニアと繋がる(TokyoNLP、さくテキ、RubyKaigi系あたり？)
MyKyTeaをPythonで学習から解析まで一通りできるようにする(引数対応、学習対応)
TOEIC800点超え
@acappella_event のリツイート精度向上方針の検討(カテゴリ分類に落とす？合唱用語解析モデル作る？)
C++を学ぶ(Effective C++を読む)
HerokuでWebアプリを作る(動画あったーの作り直し？)

家のことや趣味でやりたい事としてはこんなことを考えてます。

規則正しい早起き生活の定着
育児の負荷分散
フィンランド語を学んでFBのRajatonのWallが読めるようになる
アカペラで新曲一曲以上歌って録音する(定期的に歌うことを定着させる)
Rajatonの曲を合唱の世界に広める

粒度がバラバラで幾分抽象度も高いものも含まれますが、無理なく取り組んで行きたいと思います。
どうぞ今年もよろしくお願いいたします。

2011 in review

Sat, 31 Dec 2011 18:01:47 -0800

あけましておめでとうございます。
去年のブログの統計を出してくれるんですね。

今年も自分で気になったことをまとめていきたいと思います。

WordPress.com 統計チームは、2011年のあなたのブログの年間まとめレポートを用意しました。

概要はこちらです。

シドニーオペラハウスのコンサートホールには2,700人が入場できます。2011にこのブログは約 53,000 回表示されました。シドニーオペラハウスのコンサートに置き換えると、満員のイベント約20回分になります

レポートをすべて見るにはクリックしてください。

伊藤恵司・名島啓太両氏の選んだ『学生合唱のための「スチューデント・ソングブック」』が熱い！

Sun, 25 Dec 2011 04:12:03 -0800

結構良い仕事をしている、合唱楽譜販売店のですが、その良質なコンテンツとは裏腹に中々Webに情報が流れていないのが玉に瑕だったりします。

そんな中で、パナムジカで全ての大学生のための愛唱曲集として紹介されていたが素敵なのでご紹介いたします。

選曲はなにコラなどでおなじみの伊藤恵司氏とJCDAの理事でもある名島啓太氏の両名。

この曲集には、ルネサンスからロマン派までの外国曲、日本の合唱曲のスタンダードナンバー、新しい日本の合唱曲など、今の大学生に歌って欲しい26曲が収録されています。

とありますが、

実際曲目を見ると納得のArcadelt,Byrd,Victoria,Bachといった鉄板どころから、国内では三善、木下、松下、信長、千原各氏、さらには最近注目の相澤直人氏、北川昇氏といったラインナップ。男声の斎太郎節、女声のコチャールSalve Reginaと幅広く歌い継がれて欲しい曲が集まっています。

収録曲の詳細は以下の通り。

収録曲
【世界の合唱曲】
Innsbruck, ich muss dich lassen (Isaac) / Matona mia cara (Lassus) /
Now is the month of Maying (Morley) / Ave Maria (Arcadelt) /
Ave Maria (Victoria) / Ave verum corpus (Byrd) /
Dir, dir,Jehova, will ich singen (J.S.Bach) /
Ach, arme Welt (Brahms) / Locus iste (Bruckner) /
Abschied vom Walde (Mendelssohn)
【日本の合唱曲】
遙かな友に (磯部俶) / 七里浜 (團伊玖磨) /
木とともに人とともに (三善晃) / 卒業 (新実徳英) /
夢みたものは… (木下牧子) / 鴎 (木下牧子) /
たったいま (松下耕) / ほほえみ (信長貴富) /
なみだ (北川昇) / ここから始まる (北川昇) /
宿題 (相澤直人) / アヴェ・ヴェルム・コルプス (千原英喜)
【男声合唱曲】
斎太郎節 (竹花秀昭編曲) / 見上げてごらん夜の星を (秦実編曲)
【女声合唱曲】
Salve Regina (Kocsar) / ほたるこい (小倉朗)

パナムジカさんの

各団の新しい「愛唱曲集」としてのみでなく、合同演奏など横のつながりを広げることにもきっと活躍するに違いないこの「スチューデント・ソングブック」。
大学生のみならず、昔学生だった(!?)一般の合唱団にもどうぞ！

という言葉に込められていますが、昔学生だった人としても欲しい一冊であります。合同演奏や親睦会で気軽に歌える曲が増えると楽しいですよね。
後は、パナムジカのサイトに一曲一曲のパーマリンクが付けば問題なしなんだけどなぁ。。。

全ての大学生のための愛唱曲集

正規表現ライブラリre2の簡単な使い方まとめ

Sat, 26 Nov 2011 14:02:56 -0800

先日、 Google製正規表現エンジン。

シンプルな使い方は、前の記事を見ていただければ分かると思うのですが、色々やってみようと思った時に、意外と独特の癖があってやりたいことをやるのに少し手間取ったので、メモがてらまとめておきます。
本家のは思ったよりあっさりしていて、基本的にはを見るのが良いのですが、それもいまいちわかりにくいところがあったので、を見ながら試したことを書きます。詳細が知りたい人はテストコード見た方が早いかもしれません。

[2011/11/28追記]
Windows Visual Studio向けのforkがでたようです。これでVisual Studio使いの人も安心ですね！

[2011/12/03追記]
re2winは日本語の文字列をマッチングさせようとしても、Invalid UTF-8とエラーがでてしまいます。
どうやら内部で文字列がUTF-8であることを期待しているようです。文字コード変換をしないといけません。

gistにもを置きました。

お品書き

FullMatch:文全体にマッチするかを判定
PartialMatch:文の一部分にマッチするかを判定
PartialMatchN:特に部分マッチした文字列を取得したい時に
FindAndConsume:部分マッチする文字列を繰り返し取得したい時に
Replace:パターンにマッチする最初の文字列を一置換
GlobalReplace:パターンにマッチする全ての文字列を置換
Extract:マッチする文字列を抽出して利用したい時に
サンプルコード

0.はじめに

re2を扱う上で知っておいた方が良さそうなポイントです。

後方参照に対応していない
Unicode文字列にも対応している
対応している(していない)シンタックスは後方参照については以下のように書いてありました。

RE2 supports submatch extraction, but not backreferences.

If you absolutely need backreferences and generalized assertions, then RE2 is not for you, but you might be interested in , Google Chrome’s regular expression engine.
( from )

ここで言う後方参照とは、"(.n)\1"というパターンで"anan"という文字列にマッチさせるというように、マッチした文字列を使ってパターンを作りたいという場合の事だと思います。単にgroupにマッチする文字列を抽出するだけならば可能です。
また、どういうシンタックスが使えるかは確認しておくと良いと思います。

1.FullMatch:文全体にマッチするかを判定(boost::regex_match)

FullMatchという関数で、あるパターンが一文全体にマッチするかを判定します。
マッチすればtrueを返し、groupを作っていれば引数として用意したstringやintにそのグループに該当する値を返します。

string s,t;
string str("あぶらかたぶら");
re2::StringPiece input(str);
re2::RE2 re("(.ら).(.ぶ)");
if(re2::RE2::FullMatch(input, re , &s, &t))
 cout << "s:"<< s << " t:"<< t << endl;
else
 cout << "Not match." << endl;

if(re2::RE2::FullMatch(input, ".(.ら).(.ぶ)." , &s, &t))
 cout << "s:"<< s << " t:"<< t << endl;
else
 cout << "Not match." << endl;

出力結果は以下のようになります。

Not match. s:ぶら t:たぶ

2.PartialMatch:文の一部分にマッチするかを判定(boost::regex_search)

先ほどは、一つの文字列全体を考慮したパターンを考えましたが、今回は部分文字列で一致すればOKという関数です。

string s,t;
string str("あぶらかたぶら");
re2::StringPiece input(str);
re2::RE2 re("(.ら).(.ぶ)");
if(re2::RE2::PartialMatch(input, re , &s, &t))
 cout << "s:"<< s << " t:"<< t << endl;

出力結果は以下のようになります。

s:ぶら t:たぶ

3.PartialMatchN:特に部分マッチした文字列を取得したい時に

今までのやり方だとマッチしたかを判定することに重きを置いていて、取得した文字列を後から利用したい時には必要な数だけ変数を用意しなければならず、統一的に扱いづらいという問題があります。

そこで、任意の数のgroupを取得したい場合には、PartialMatchNを使います。
(なお、全文一致の場合はFullMatchNになります。以降の関数にもXXXXNという物が存在することが多いようです)

このやり方はさんに教えていただいた方法です。も参考にしてください。(教えていただきありがとうございます！)

string str("abcadca");
re2::RE2 re("((a.)(..))");
re2::StringPiece input(str);
int groupSize = re.NumberOfCapturingGroups();
vector<re2::RE2::Arg> argv(groupSize);
vector<re2::RE2::Arg*> args(groupSize);
vector<re2::StringPiece> ws(groupSize);

for (int i = 0; i < groupSize; ++i) {
 args[i] = &argv[i];
 argv[i] = &ws[i];
}
re2::RE2::PartialMatchN(input, re, &(args[0]), groupSize);
cout << groupSize << endl; string s;

for (int i = 0; i < groupSize; ++i){
 cout << ws[i] << endl;

出力結果

3 abca ab ca

4.FindAndConsume:部分マッチする文字列を繰り返し取得したい時に(boost::regex_regex相当？)

パターンにマッチしている文字列が何回出てくるか分からない場合に、この関数を利用するといいと思います。

string str("あぶらかたぶら");
RE2 re("(.ぶ)");
re2::StringPiece input(str);
string r;

while(re2::RE2::FindAndConsume(&input, re, &r) ){
 cout << r << endl;
}

出力結果

あぶ たぶ

5.Replace:パターンにマッチする最初の文字列を一置換(boost::regex_replace)

パターンに一致した文字列のうち、最初に出てきた文字列のみを置換する場合、Replaceを使います。
全てのマッチする文字列を置換したい場合は、GlobalReplaceを使います。

string s = "PerlRubyPython";
re2::RE2::Replace(&s, "P", "D");
cout << s << endl;

出力結果

DerlRubyPython

6.GlobalReplace:パターンにマッチする全ての文字列を置換

Replaceの全ての文字列を置換する場合です。
ただし、文字列"banana"に対するパターン"ana"のようにオーバーラップする場合は対応しません。
この場合は、一回のみマッチするようです。

string s = "PerlRubyPython";
re2::RE2::GlobalReplace(&s, "P", "D");
cout << s << endl;

出力結果

DerlRubyDython

7.Extract:マッチする文字列を抽出して利用したい時に

Replaceはどちらかというと、入力された文字列の一部を変える時が多いと思いますが、
Extractはマッチしたgroupを抽出して、新たに文字列を生成したい場合に使える関数です。

string s;
RE2::Extract("foo@bar.com", "(.*)@([^.]*)", "In domain \"\\2\", user \"\\1\" is exist!", &s);
cout << s << endl;

出力結果

In domain "bar", user "foo" is exist!

サンプルコード

上記全部の例を含んだサンプルコードはこんな形になります。にも同じ物があります。

コンパイルはこんな感じ。

g++ -Wall re2testbasic.cpp -o re2all.out -lre2 -lpthread

ソースは以下。

#include <iostream>
#include <string>
#include <re2/re2.h>
#include <vector>

using namespace std;

void test_fullmatch(){
 string s,t;
 string str("あぶらかたぶら");
 re2::StringPiece input(str);
 re2::RE2 re("(.ら).(.ぶ)");
 if(re2::RE2::FullMatch(input, re , &s, &t))
 cout << "s:"<< s << " t:"<< t << endl;
 else
 cout << "Not match." << endl;
 if(re2::RE2::FullMatch(input, ".(.ら).(.ぶ)." , &s, &t))
 cout << "s:"<< s << " t:"<< t << endl;
 else cout << "Not match." << endl;
}

void test_partialmatch(){
 string s,t;
 string str("あぶらかたぶら");
 re2::StringPiece input(str);
 re2::RE2 re("(.ら).(.ぶ)");

 if(re2::RE2::PartialMatch(input, re , &s, &t))
 cout << "s:"<< s << " t:"<< t << endl;
}

void test_partialmatchn(){
 string str("abcadca");
 re2::RE2 re("((a.)(..))");
 re2::StringPiece input(str);
 int groupSize = re.NumberOfCapturingGroups();
 vector<re2::RE2::Arg> argv(groupSize);
 vector<re2::RE2::Arg\*> args(groupSize);
 vector<re2::StringPiece> ws(groupSize);

 for (int i = 0; i < groupSize; ++i) {
 args[i] = &argv[i];
 argv[i] = &ws[i];
 }
 re2::RE2::PartialMatchN(input, re, &(args[0]), groupSize);
 cout << groupSize << endl;

 string s;
 for (int i = 0; i < groupSize; ++i){
 cout << ws[i] << endl;
 }
}

void test_findandconsume(){
 string str("あぶらかたぶら");
 RE2 re("(.ぶ)");
 re2::StringPiece input(str);
 string r;
 while(re2::RE2::FindAndConsume(&input, re, &r) ){
 cout << r << endl;
 }
}

void test_replace(){
 string s = "PerlRubyPython";
 re2::RE2::Replace(&s, "P", "D");
 cout << s << endl;
}

void test_globalreplace(){
 string s = "PerlRubyPython";
 re2::RE2::GlobalReplace(&s, "P", "D");
 cout << s << endl;
}

void test_extract(){
 string s;
 RE2::Extract("foo@bar.com", "(.\*)@([^.]\*)", "In domain \"\\2\", user \"\\1\" is exist!", &s);
 cout << s << endl;
}
int main(int argc, char \*\*argv){
 cout << "test FullMatch" << endl;
 test_fullmatch();
 cout << "test PartialMatch" << endl;
 test_partialmatch();
 cout << "test PartialMatchN" << endl;
 test_partialmatchn();
 cout << "test FindAndConsume" << endl;
 test_findandconsume();
 cout << "test Replace" << endl;
 test_replace();
 cout << "test GlobalReplace" << endl;
 test_globalreplace();
 cout << "test Extract" << endl;
 test_extract();
 return 0;
}

出力結果

test FullMatch
Not match.
s:ぶら t:たぶ
test PartialMatch
s:ぶら t:たぶ
test PartialMatchN
3 abca ab ca
test FindAndConsume
あぶ たぶ
test Replace
DerlRubyPython
test GlobalReplace DerlRubyDython
test Extract

おわりに

駆け足で説明したので、分かりにくい点や間違いがあるかと思います。
その際にはまでご指摘いただければと思います。

後方参照さえ必要なければ、boostから乗り換えられるんじゃないかなーと思っています。

enjoy!

Google製の正規表現エンジンRe2を日本語で試してみた

Fri, 25 Nov 2011 14:02:51 -0800

C++で正規表現を使う時、boost::regexを使うことが多いと思っていたのですが、何故か1.46.1以降(といっても1.48.0しか試していませんが)、regex_search,regex_matchがNullPointerExceptionぽく落ちるので、解決方法を探していました。

そこで、試してみたのがです。
インストールは簡単です。Mercurialが必要ですが、Ubuntuではaptで簡単に入ります。(ちなみに、Ubuntu11.04で試しました)

[2011/11/28追記]
もう少しだけを書きました！

まず、入っていなければMercurialのインストールです。

sudo apt-get install mercurial

で、適当な所にre2をcloneして、インストールです。

hg clone https://re2.googlecode.com/hg re2
cd re2
make test
sudo make install
make test install

で、試してみたコードが以下のものになります。

#include <iostream>
#include <string>
#include <re2/re2.h>
#include <cassert>
using namespace std;

int main(int argc, char **argv){
 string s,t;
 string str("あぶらかたぶら");
 RE2 re1("(.ら).(.ぶ)");
 assert(re1.ok());

 if(RE2::PartialMatch(str, re1 , &s, &t))
 cout << "s:"<< s << " t:"<< t << endl;

 return 0;
}

出力結果はこうなりました。

s:ぶら t:たぶ

勿論、部分マッチだけでなく、FullMatchやReplaceもできます。
ただ、可変数マッチしたものを全部取り出すのはやり方わからないんですよねー。
マッチした物をeachで取り出す的なことがしたいんですが。

[2011/11/26追記]
PartialMatchNを利用すれば解決できると、に教えていただきました！
ただ、結構トリッキーなので、下記記事中のサンプルコードを見るのが早いと思います。ありがとうございます！

exampleはにたくさんあるので参考にしてください。

とりあえず、正規表現だけ欲しければre2を使ってみるのもよいかもしれません。

参考URL:

iMessageをiPadとiPhoneで使い分ける方法

Sat, 15 Oct 2011 05:10:14 -0700

iMessageを複数のデバイスで同一Apple IDで使う場合に、どちらか一方に送る方法を検討したらわかりました。

元々は、家にいる妻が使うiPadと外に出ている自分のiPhoneと切り替える方法が欲しくて考えました。でも、Apple IDのアカウントが同一だと両方の端末にメッセージが届いてしまうわけです。これがiCloudだ！（違）

20111016追記
iCloudを同一AppleIDで夫婦で使い分ける方法がmacjさんから紹介されてしました。合わせてどうぞ。

で、本題です。

iMessageにメッセージ着信用のアドレスを複数設定する機能があります。設定の仕方は下記サイトなどを参考にしてください。

で、話は簡単。複数の端末それぞれに別々のアドレスを設定するだけです。

例えばiPadとiPhoneがあり、Apple IDに登録したメールアドレスがAAA@gmailだとします。で、iPad用に設定したいアドレスBBB@gmailと、iPhone用に使いたいアドレスCCC@softbankだとします。

メッセージ着信用アドレスは下記のようになっているとします。

iPad: AAA@gmail, BBB@gmail
iPhone: AAA@gmail, CCC@softbank, +81XXXXXXX(電話番号）
AAA@gmailに送信
→iPadとiPhone両方に届く
BBB@gmailに送信
→iPadに届く
CCC@softbankに送信
→iPhoneに届く
+81XXXXXXXに送信
→iPhoneに届くこんな感じです。
わかりましたか？

ちなみに、AAA@gmailに送る場合に注意ですが、iMessageはToがわからないので（ちなみに、fromも結構怪しいです）、送る方はどれに送っているかわかりますが、送られる方はAAA@gmailに送られているのか、別のアドレスなのかわかりません。
なので、自分宛か複数宛か判別できないで面倒なことになる可能性があるかもしれませんので、ご注意ください。

それでは、楽しいiMessageライフを！

久しぶりに合唱楽譜を買った

Sun, 09 Oct 2011 15:02:40 -0700

最後に購入したのは、だなぁと思いながら、ふっとpanamusicaから新刊案内が来たので久しぶりに購入することにしました。

今回購入したのはこちら。

さんによる作曲の曲集です。harmonia ensembleが歌う「ぜんぶ」が素敵だったので購入しました。
ボブ・チルコットとデイヴィッド・ブラックウェル編纂のキャロル集。トラディショナルな曲を新しい作曲家が編曲しているという感じのようです。
以来歌いたかった、Lord I’m freeなどの曲が入っている楽譜です。歌いたい！

どれも楽しみですねー。

cJumanのインストールをちょっと簡単にするcJuman-installer

Sat, 01 Oct 2011 15:02:34 -0700

cJumanというさんの作成された、形態素解析器Jumanをpythonから使うためのSWIGで作られたラッパーがあります。

「入門自然言語処理」でも紹介されているのですが、インストールが少し面倒でした。

特にこの辺。

>|bash|
gcc -c cJuman_wrap.c -fPIC -I/usr/include/python2.4
gcc -shared *.o -o _cJuman.so
sudo install -m 644 _cJuman.so cJuman.py /usr/lib/python2.4/site-packages/
|

ドイツでFONICのプリペイドSIMを使って光ポータブルを試してみた

Sun, 25 Sep 2011 01:09:29 -0700

ドイツで光ポータブルを使って、FONICのプリペイドSIMを使ってみました。

ソフトバンクやdocomoの海外パケット定額は2000〜3000円/dayとお高め、MIFIも980円/day〜ともう一声という風に感じていたため、現地でプリペイドSIMを購入してみることに。

事前にtwitterやブログなどで先人達の情報を仕入れて臨みました。
参考URLはこちら

今回は、kaufhofというドイツ版ジャスコに入っている家電量販店、Saturn（ざとぅーんという発音なんですね）にて購入しました。現地で住んでいる人に、この辺りで英語が通じる携帯屋はないか？と聞いたら教えてもらいました。
デュッセルドルフは英語が通じない所が多い気がします。あと、車がないと店に行けないので、旅行がてらの調達は結構厳しいです。

余談ですが、ドイツは思った以上に英語が通じませんでした。
更にSIMやらAPN周りの専門用語を分かっている人が必要なので、なかなか大変です。

必要なもの

光ポータブル（SIMフリー版）
SMSが使えるSIMフリー携帯
インターネット回線
iPhoneやiPadなど使いたいWifi機器

1.プリペイドSIMを購入する

今回選んだSaturnですが、なかなか曲者でした。
事前情報では「O2やVodafoneはアクティベーションとチャージにはドイツ語必須なので、公式店舗で購入してアクティベーションとチャージをやってもらうように」とあったのですが、その事実に気付いたのは、購入後でした。
APNについての情報は事前に気にしていたのですが、アクティベーションとチャージには意識が回っていませんでした。

「データ定額で3G使えるプリペイドSIMはないか？SMS使える携帯ないから、他の手段でアクティベーションできるものが良い」と聞いたところ、オススメされたのがFONICのプリペイドSIM。
9ユーロで10ユーロ分のチャージが含まれており、定額もtagflatという日単位の定額で2.5ユーロ/day, 一ヶ月25ユーロ/monthとお得です。回線はO2のMVNOということで、APNを聞いてみたところ、O2のものでいけることが分かりました。
肝心のアクティベーションも、「インターネットでできるよ！」と言うので、信じて購入しました。途中でt-Mobileの方がアクティベーションの不安がないという記憶を思い出し、店員に在庫はないか？と聞いてみたら、「在庫切れだ」ということ。ここで諦めてしまいました。（これが全ての敗因！ドイツは諦めたらそこで試合終了です）

2.アクティベーション、チャージ

電話かインターネット( )でチャージということでしたが、電話は恐らくドイツ語。そんなん無理だ！と思い、滞在先でPCをお借りしてWebでのアクティベーションを試みました。
でも、全部ドイツ語！英語がひとかけらもなく、心が折れそうでした。

を調べ当てて、参考にFONICのユーザー登録とアクティベーションしました。
チャージもWebで行いました。
最初、FONICのサイトのユーザー登録とアクティベーションが同義だと思い、チャージ出来ずにかなりハマりました。

ここまで、SMSレスで行けました。

3.データ定額オプション(tages-flat)の設定

結論から言うと、これは完了しませんでした。

やり方は、FONIC(あるいはO2)のSIMが使える携帯電話からSMSで、

START TAGESFLAT

と送れば良いそうです。
良いそうです、というのは、お借りしていたSAMSUNGの携帯電話では全て大文字で入力する方法がわからず（！）、諦めて最初の一文字だけ大文字でやったのですが、無理でした。

ちなみに、USBスティックタイプの通信モジュールだと、デフォルトでtages-flatになっているようです。これも後から知りました。

従量課金であっという間にチャージが尽きてしまいました。

通信の繋がりやすさ

O2は都市部に強いという話は聞いていましたが、郊外の滞在先ではちょっとつらかったです。夜間にシャッターが降りると、ほとんど通信できなかったです。それでも従量制ではチャージが削れていくんですよね…。

まとめと教訓

SMS使えるSIMフリー携帯必須。
契約はキャリア公式店舗で最後まで面倒みてもらうこと。
コストが多少かかっても良いなら、の方が楽(\1280/day)
英語でやり取り出来るのは すごい楽 。英語勉強するの大事！

KyTeaを他言語で使うラッパー+αまとめ

Thu, 22 Sep 2011 22:09:10 -0700

さんの作られたKyTeaを他言語で利用できるラッパーですが、
拙作のMykytea意外にも色々とあるようなのでまとめておきます。

KyTeaって何？って人はやこちらのがわかりやすいですが、
一言で言うと形態素解析や読みの推定を行ってくれるものです。
MeCabと違って読みの推定をまじめにやってくれるようです。

Ruby

(@chezou作)

Python

(@chezou作)
( さん作。 )

Perl

( さん作)

番外編

sinatra :
NLTK :
( さん)
( さん)

NLTKからKyTeaでコーパスを読み込むJPKyteaTokenizer作りました

Wed, 14 Sep 2011 15:02:18 -0700

KyteaをPythonから使うMykytea-pythonを使って、NLTKラッパーを書いてみました。

NLTKって？

といえば、オライリーでも「」という日本語の書籍が出ているくらいメジャーなPythonの自然言語処理用ライブラリです。ちなみに、日本語の処理の12章は。
手っ取り早くエッセンスを掴みたい場合は、nokunoさんの以下の記事がよくまとまっていると思います。

入門自然言語処理自体は、言語系の人でも自然言語処理に取り組めるように、具体的な事例ベースで書いてあるので、取っつきやすいです。初めて自然言語処理を学ぶ人にも、形態素解析からナイーブベイズや最大エントロピー法といった機械学習の話とそれらを体験できるライブラリの使い方があり、コーパスに対して実際にどう処理されるかを感じることが出来ます。また、Pythonの入門書としても具体例ベースなので、ジェネレータやリスト内包表現などがわかりやすいと思いました。

JPKyteaTokenizerって？

さて、KyTeaは入門自然言語処理の12章でも名前は紹介されているのですが、Pythonから使えるわけではなかったためか、名前の紹介にとどまっています。

そこで、Mykytea-pythonを使ってnltkでコーパスを読み込むJPKyteaTokenizerを作りました。

ソースはいつも通りgithubにあります。

あらかじめとをインストールしてください。
使い方は、test_kyteatokenizer.pyを見ればだいたいわかるとは思いますが、青空文庫のをdata/ginga.txtに保存してTokeizeしています。

#!/usr/bin/env python# -\*- coding: utf-8 -\*-from nltk\_jp import \*from nltk.corpus.reader import \*from nltk.corpus.reader.util import \*import kyteatokenizer jp\_sent\_tokenizer = nltk.RegexpTokenizer(u'[^ 「」！？。]\*[！？。]') reader = PlaintextCorpusReader("data/",r"ginga.txt", encoding = 'utf-8', para\_block\_reader = read\_line\_block, sent\_tokenizer = jp\_sent\_tokenizer, word\_tokenizer = kyteatokenizer.JPKyteaTokenizer())print ' '.join(reader.words()[20:80])

実行すると、こんな感じになります。

$ python test\_kyteatokenizer.py ふう に 川 だ と 云 （ い ） わ れ たり 、 乳 の 流れ た あと だ と 云 わ れ たり し て い た この ぼんやり と 白 い もの が ほんとう は 何 か ご 承知 で す か 。 」 先生 は 、 黒板 に 吊 （ つる ） し た 大きな 黒 い

本当は、tagged_words()で品詞とれたり読みもとれたり出来るようにすると嬉しいんだろうけれど。。。

(蛇足)入門自然言語処理の誤植

Amazonで買ったのに、第1刷を手に入れることが出来たのですが、の正誤表に無い誤植がちらほらあるんですね。まだ、全部は目を通していないのですが、気がついたものだけ書いていきます。

P.88 3.1.4 RSSフィードの処理、1つめのソースコード13行目 nltk.html_clean → nltk.clean_html
P.89 3.1.5 ローカルファイルの読み込み 4つめのソースコード1行目 f 7= open → f = open
P.224 5.5.7 性能の限界ソースコード 4行目 nltk.ConfusionMatrix(gold, test) → nltk.ConfusionMatrix(gold_tags, test_tags)
P.228 5.7.3 意味的な手がかり 6行目「verjaardag」というドイツ語 → 「verjaardag」というオランダ語

Jコミの漫画ビューアはiPadでも読める

Wed, 20 Jul 2011 04:07:24 -0700

以前、大々的にラブひながPDFで読めると話題になった絶版漫画公開サイト、。
その後、特に追いかけていなかったのですが、ホイホイ呼ばれて久しぶりに行ってみました。

PDFでは動的な広告が入れられないということから、基本オンラインビューアーで見て人気のあるものはPDFになるというモデルになったとかで、iPadで見られないかなーと思っていたら、意外や意外。すんなり読めました。速度は、まぁこれくらいならギリギリ許容範囲かなという程度。

で、肝心のラインナップですが大分増えていました。結構気になる作品も増えていたので並べてみます。

八神健の作品が他[ , ]にもあるので、今度読んでみたいと思います。密・リターンズ！は連載当時マレーシア人の美大生と何故かメールで語り合ったなぁ、と懐かしい思い出がよみがえってきます。
しかし、ギャグ王系はJコミで展開するのも良さそうですね。

肝心のサラダデイズは、妻に「進●ゼミの漫画みたい」と言われてちょっと凹みました。いやぁ、今見ると構造は似たり寄ったりなのだけど、如何にしてパターン増やすかで苦労したんだろうなーと、一話読み切りものの苦労を感じてしまいます。

アカペラを聞きながら英語を勉強できる！？Podcast- Mouth off

Tue, 19 Jul 2011 04:07:50 -0700

タイトルは釣りです（笑）

皆さんは、コンテンポラリーなアカペラの曲をどうやって知っていますか？
サークルの先輩？友人に曲を紹介してもらう？
いいですねー。
ただ、なかなかリアルで頻繁に会えるアカペラーがいない人にとっては、ネットでの情報収集って重要ですよね。

でも、YouTubeの海からお気に入りの曲を探すのは大変！

そこで、コンテンポラリーアカペラのPodcast、の出番です。
このPodcastは様々なジャンルのアカペラを、毎週三十分1時間程度の番組で多く紹介してくれるのが魅力です。一曲当たりの時間は短いですが、逆に言うと好みではない曲はさらりと流せるので聞き疲しにくいと思います。好きな曲は曲名を追っかければいいですしね。

英語のPodcastなので、英語の勉強にもなるかも！？（笑）オススメの番組です。しかし、日本でもなんかでPodcastやらないかなー。

URL

sinatraでKyTeaをブラウザから試すkytea-sinatra作ってみた

Mon, 18 Jul 2011 15:02:01 -0700

先日のエントリで書いたとおりを使って、試しにブラウザから解析結果をみられるkytea-sinatraを作りました。

といっても、sinatraとhamlを使ってちょっと出力結果を見られるようにしたのシンプルなものです。
イメージとしては、このような形でブラウザから簡単に解析結果が利用できると何か面白いことができないかなーと思っています。
本当はどっかのサーバで動かして、jsonとかで気軽に解析結果を取得できるとかになればいいんですけどね。

ソースはgithubにあります。

KyTeaとMykytea-rubyをインストールした後、Mykytea.soをkytea-sinatraと同一のディレクトリに入れてから実行してください。

gem install sinatra haml bundler
# (または、 gem install bundler; bundle install)

ruby kytea\_sinatra.rb

で、ブラウザで

を開けばOK。
なお、mecab-rubyも入っている場合は、下記のスクリプトを実行することで出力結果が比較できます。

ruby kytea_sinatra_mecab.rb

出力結果は冒頭の感じです。

＃しかし、API修正されたその日のうちに、それで十分じゃんとか思ったのはここだけの話。
＃全部叩けるようにするか、MeCabで言うところのparseToString, parseToNodeに絞ってアクセスできるようにしたかの違いだとは思う。
＃@seikichiさんの.iの方がキレイだと思います。

参考URL

KyTea:京都テキスト解析ツールキットをRuby, Pythonから使えるMykyteaを作ってみた

Fri, 15 Jul 2011 05:07:29 -0700

[2011/07/23追記]
SWIGで生成したmykytea_wrap.cxxをgithubに追加したので、SWIGのインストールは必要なくなりました。それに伴い実行すべき事が当初と変わっています。

KyTeaというさんが作られた、テキストの形態素解析や読み付与ができるツールがあります。

処理のイメージですが、少し前のバージョンの物ですがさんのがわかりやすいと思います。

これをRubyやPythonなどのLLで使えることができれば、Webアプリとかでも使えるようになって嬉しいのでは、と思いラッパーを書いてみました。
Ubuntu 11.04, KyTea v0.3.1, SWIG 2.0.1 Ruby 1.8.7, 1.9.2, Python 2.7.1にて動作を確認しています。
KyTeaと同じApache Licence 2.0でお使いください。

Ruby向け：
Python向け：

Mykyteaの使い方

kyteaをダウンロード＆インストール

を参考にダウンロード＆インストール

wget http://www.phontron.com/kytea/download/kytea-0.3.1.tar.gz tar -xzf kytea-X.X.X.tar.gz cd kytea-X.X.X ./configure make sudo make install kytea --help

うちの場合、「libkytea.so.0が見つからない」といわれたので、LD_LIBRARY_PATHを/usr/local/libに通しました。

export LD\_LIBRARY\_PATH=$LD\_LIBRARY\_PATH:/usr/local/lib

[2011/07/17追記]

sudo ldconfig

こうすれば良いだけだったんですね。。。参考URL：

SWIGをインストール

[2011/07/23追記]
SWIGで生成したmykytea_wrap.cxxをgithubに追加したので、SWIGのインストールは必要なくなりました。

SWIGは、異なる言語へラッパーを作るのをサポートしてくれるソフトです。今回はこれを使ってラッパーを作成しました。
SWIGを使えば、javaやperlなどの他の言語のラッパーも作れるはずです。

今回は、SWIGのバージョン1.x系列ではRuby1.9.2向けのラッパーが作れなかったため、2.x系列をインストールします。

sudo apt-get install swig2.0

githubからMykyteaをダウンロード

git cloneでソースを入手します。

git clone git://github.com/chezou/Mykytea-ruby.git

もしくは、githubからブラウザでDownloadしてください。python版はrubyをpythonに読み替えてください。

Mykyteaの共有ライブラリを作成する

ダウンロードしたソースに対して、共有ライブラリを作成します

[2011/07/23追記]
SWIGで生成したmykytea_wrap.cxxをgithubに追加したので、SWIGの実行は必要なくなりました。もしmakeに失敗したら、最初に下記を実行してください。

swig2.0 -c++ -ruby -I/usr/local/include mykytea.i

(pythonの場合は下記)

swig2.0 -c++ -python -I/usr/local/include mykytea.i

Rubyの場合

ruby extconf.rb make
Pythonの場合 [2011/07/23追記]
setup.pyを追加しましたので、pytonの場合は以下を実行してください

python setup.py

下記はmake方法です。

swig -c++ -python mykytea.i g++ -c mykytea\_wrap.cxx -I/usr/include/python2.7 g++ -c mykytea.cpp g++ -shared mykytea.o mykytea\_wrap.o -o \_Mykytea.so -lkytea

-I/usr/include/python2.7 の部分は適宜バージョンなどによって場所を読み替えてください。
(ちなみに、python版に入っているなんちゃってMakefileはpython2.7でしか通りませんorz
autoconfの使い方が分からない…)

動作を確認する

Rubyの場合

ruby mykytea_test.rb

Pythonの場合

python mykytea_test.py

でテストプログラムを実行してください。
下記のような実行結果が得られるはずです。(注釈はでません)

#分かち書きの結果を出力
今日
は
い
い
天気
で
す
。

#タグ付き結果を文字列で出力
今日/名詞/きょうは/助詞/はい/形容詞/いい/語尾/い天気/名詞/てんきで/助動詞/です/語尾/す。/補助記号/。

#表層及び1位のタグとスコアを出力
今日 /名詞/3.2847062802112355 /きょう/1.3268831168939792
は /助詞/3.924858405365926 /は/100.0
い /形容詞/2.591390241156937 /い/100.0
い /語尾/2.155161693042765 /い/100.0
天気 /名詞/4.7486561215119565 /てんき/100.0
で /助動詞/2.8068949386999753 /で/100.0
す /語尾/2.7237397162868087 /す/100.0
。 /補助記号/3.3392877514055774 /。/100.0

#表層と、全てのタグとそのスコアを出力
今日 /名詞/3.2847062802112355 /言いよどみ/0.0 /代名詞/-0.12999710377780294 /きょう/1.3268831168939792 /こんにち/0.0
は /助詞/3.924858405365926 /言いよどみ/-3.6483403104137224e-17 /代名詞/-0.23536067702781097 /は/100.0
い /形容詞/2.591390241156937 /動詞/0.0 /言いよどみ/-0.00428323670492603 /い/100.0
い /語尾/2.155161693042765 /言いよどみ/-3.946495907847236e-17 /web誤脱/-0.23382596743536913 /い/100.0
天気 /名詞/4.7486561215119565 /言いよどみ/-9.215718466126788e-18 /web誤脱/-0.18273736539912366 /てんき/100.0
で /助動詞/2.8068949386999753 /言いよどみ/-1.5937771935536915e-17 /動詞/-0.21163142806550297 /で/100.0
す /語尾/2.7237397162868087 /言いよどみ/-1.4690939437178585e-17 /代名詞/-0.36184293534455636 /す/100.0
。 /補助記号/3.3392877514055774 /言いよどみ/1.9136168344369153e-17 /代名詞/-0.268961070659961 /。/100.0

使い方の詳細についても、サンプルプログラムを見れば大体分かると思います。

タグの取得について

KyTeaで取得したタグですが、次のような構造体に格納しています。

struct Tags{ string surface; vector\< vector\< pair\<string, double\> \> \> tags; };

これに対し、getAllTags()でタグを取得するとこうなります。

今日 /名詞/3.2847062802112355 /言いよどみ/0.0 /代名詞/-0.12999710377780294 /きょう/1.3268831168939792 /こんにち/0.0

で、上記の出力に対するタグはjsonで書くとこんな感じになってます。

{ surface : 今日, tags : [[[名詞 , 3.2847062802112355], [言いよどみ , 0.0], [代名詞 , -0.12999710377780294] ], [[きょう , 1.3268831168939792], [こんにち , 0.0] ]]}

tagsの部分ですが、タグとスコアのペアの系列が二つあります。一つ目の系列が品詞で二つ目の系列が読みです。(v 0.3.1ではこの順番のようです)

これは、KyTeaのタグが特に形態素だとか読みだとか特定のラベルを取得しているのではないため、バージョンやモデルやconfigによっては別のラベルになり得るということが考えられます。

まとめ

KyTeaのRuby,PythonラッパーMykyteaを作りました。結局は、KyTeaにラッパーコードを書いて、SWIGで共有ライブラリを作っただけです。

内部のコードはあまりスマートではありませんが、とりあえず出してしまいました。
コメントなどありましたら、当ブログまたはまでご連絡ください。

今後の予定としては、sinatraで簡単なWebアプリとの連携をさらっと書いてみたいです。
【2011/07/20追記】

参考URL

Rajatonの楽譜を日本から買う方法 - Sulasol or あかぺら村のCD屋さん?

Sat, 02 Jul 2011 15:01:50 -0700

当ブログでも何度か紹介しているフィンランドのヴォーカルアンサンブル Rajatonの楽譜を購入しました。購入したのは、Nouse lauluni等の曲です。この曲は良い曲ですよ！詩は一部カレワラからとられているようです。

録音が良くないですが、Rajaton自信が歌ってる動画はこちら。

アマチュアのガチャピン動画はこちら。HDで見ると音質は良いですよ。

彼らの歌う曲(特にMia Makaroffの曲)はアカペラを歌う人たちだけでなく、日本の合唱人たちも楽しめるのではないかと日々思っているわけです。
(松原千振先生も、Rajatonのことを賞賛されているようですし、演奏もされているようです)

しかしながら、日本から楽譜を購入する手段があまり知られていないため、中々敷居が高いのではないかと思っています。Panamusicaでも取り扱ってないみたいなんですよね。
そこで、日本からRajatonの楽譜を入手する方法をご紹介します。

1. 楽譜の出版元SULASOLから購入する

のもしくはメール( )で購入が可能です。(英語でのやりとりとクレジットカードが必須なので、それらが無理な方は2のあかぺら村のCD屋さんがおすすめです)
僕自身はメールで聞きましたが、フォームの方が確実でしょう。メールを適当な書き方をしたらSpam認定をされて4日くらい待たされました。(その後は割とスムーズにいき、2日くらいでやりとりが終わり、1週間後くらいには届きました)。

流れとしては、

フォームでオーダー依頼orメールでオーダー依頼
確認のメールが来て、クレジットカードの番号と裏の確認番号をメールで二回に分けるかFaxで連絡する(僕はFaxにしました。光電話だと安いんですよね)
確認のメールを受け取ったら、わくわくしながら待つ Rajatonの楽曲はおよそにあります。
引用すると、

Mäntyjärvi, Jaakko: Tórramat do nóebaengil (Evening Hymn) (S644)
Rissanen, Säde: Jabberwocky (S654)
Gustafsson, Kaj-Erik: Varhaiskesä (S781)
Chydenius, Kaj: Stabat Mater (S919)
Kostiainen, Pekka: Salus infirmorum (S938)
Kostiainen, Pekka: Sancta Maria, Vas Spirituale (S939)
Makaroff, Mia: Butterfly (S971)
Makaroff, Mia: Were You There (S1038)
Makaroff, Mia: Mitä kaikatat kivonen (S1039)
Makaroff, Mia: Armottoman osa (S1040)
Makaroff, Mia: You can’t stop me! (S1041)
Makaroff, Mia: Lintu lauleli lehdossa (S1074)
Makaroff, Mia: Kaikki maat te riemuitkaatte (S1189)
Chydenius, Jussi - Wuorela, Essi: Kaipaava (S1217)
Chydenius, Jussi - Wuorela, Essi: Kaipaava SSAA (S1217B)
Sippola, Laura: A Poison Tree (S1225)
Sarmanto, Heikki - Chydenius, Jussi: Un-Wishing Well (S1415)
Chydenius, Jussi: Läksin minä kesäyönä käymään (S1448)
Sariola, Soila: Nouse lauluni (S1452)

およそというのは、購入できる楽譜の全リストと価格はには先ほどのRajatonのページに無い曲も一部あります(PakkanenとかはExcelにしかありませんでした)。

なお、残念ながらDobbin’s Flowery Valeは作曲者が「もう二度と出版したくない」と思っているらしく、絶版のようです。(Sulasolの担当者からメールで聞きました。)

2. あかぺら村のCD屋さんから購入する

国内でなかなか手に入らないアカペラのCDを販売してくださっている、というサイトがあります。こちらは、という世界の様々なアカペラを紹介するサイトのキリックさんが販売をされています。多少手数料がかかってしまいますが、日本語で郵便振込で購入できるのが嬉しいところです。

僕も何度かCDの購入にお世話になったことがあるのですが、その際にRajatonの楽譜も扱ってくださいとお願いをしたのがきっかけで、楽譜をおいていただいています。

英語が苦手でSulasolの公式はちょっと、とかクレジットカードはちょっと、という方には良いのではないでしょうか？

もちろん、これ以外の楽譜サイトはあるかと思いますが、特別調べていなかったりします。情報がありましたら、お知らせください。

日本でますますRajatonが演奏されますように！

あの人がツイートした動画を連続再生サービス「動画あったー」をはじめました

Sun, 01 May 2011 15:01:45 -0700

「あの人っていつも面白い動画をつぶやいてるんだよねー」

そう思うことありませんか？

「検索キーワードでわざわざ探すのは面倒だけど、あの人のツイートしてる動画が見たい」

「仕事してる時にツイートされた動画ってキャッチしづらいけど、帰ってからまとめてみたい」

そんな人のための、ツイート動画連続再生サービス「動画あったー」をはじめました。

動画あったー

使い方

見たい人の ツイッターIDを入れて検索するだけ。
そうすると、その人がツイートした動画が自動で連続再生されます。

たとえば、@YouTubeJapan のツイートしている動画を見たい場合は、のような検索結果になります。

ただし、現在Firefoxでは上手く動かないです。。。ごめんなさい。
Google ChromeとSafariがおすすめです。IEも8なら一応動かないことはないかも、って感じです。

後、 1時間に15回くらいしか検索ができません 。API制限があるので、使いすぎには気をつけてください！

まだまだ問題点もあるかと思いますが、試しに使ってみてください。

気になることはまたは公式Twitterアカウントまでお願いします！

iPhone for everybodyの2年縛りを解除したらパケット定額フラットにしかならなかった

Sun, 01 May 2011 04:05:24 -0700

一言で言うと、iPhone for everybodyを使ってパケット定額フル( )で契約したら、パケット定額forスマートフォンに変更できなかったという話です。
現在、パケット定額forスマートフォンやパケット定額フルで契約されている方は対象外かと思われます。

二段階定額のままiPhone3Gの2年縛りを外せるか

自分は2009年5月にiPhone3Gを契約したのですが、最近のソフトバンク網のつながりの悪さを考えて、2年縛りを外すことを計画していました。

その時、参考にした記事の一つがこのtogetter。

この記事では、二段階定額制のについて、こう言及されています。

自分としては、WiMAXなどと組み合わせることも検討していたので、パケット定額forスマートフォンは重要な選択肢の一つでした。

サポートセンターに電話をしてプラン変更の前に「パケットし放題フラットとパケットし放題forスマートフォンは自由に切り替え可能ですか？」と質問をさせていただいたところ、最初はできると聞いたのですが、その数分後に折り返し電話がかかってきました。

「現在、パケットし放題forスマートフォンへ移行出来るのは、2011年11月11日以前にiPhoneをご契約されて、かつ契約時にパケットし放題フラットしか選択できない時期のお客様のみです」との連絡でした。

どうも話を聞いてみると、パケットし放題forスマートフォンへ変更できる人というのは、 パケットし放題フラットしか選べなかった人への救済措置 だ、という事なのです。

選べる選択肢は

なので、自分のようにパケット定額フルとiPhone for everybodyで契約した人は、

現状の二年縛りを更新することで二段階定額を選ぶ
パケットし放題フラットに変更をして二年縛りを外すという選択肢を選ばなければならないようです。選択肢がほぼありませんね。

なお、現行のとは二年縛りの付いた新しいホワイトプランでないと、契約ができないようです。

先日のソフトバンクWi-Fiスポットの件といい、なかなかソフトバンク側に不利な事はどんどん変えられていきますね。

iPad2とともに無料Wi-Fiスポットをゲットする二つの方法

Fri, 29 Apr 2011 23:04:06 -0700

1.3Gモデルを買いましょう。

自動的にソフトバンクWi-Fiスポット(i)が二年間無料で付いてきます。

2.AppleStoreかソフトバンクショップでWi-Fiモデルを買いましょう

iPad2Wi-Fiモデルは、決められた店舗（AppleStoreとソフトバンクショップと 一部量販店 ）でしか、ソフトバンクWi-Fiスポット(2year)はつきません。
“一部量販店” というのがくせ者です。少なくとも ビックカメラ、ヨドバシは対象外 のようです。(ヤマダ電機も？)

厄介なことにiPadの時ははついていたらしいヨドバシカメラも、今回は “一部量販店” の定義から外れているそうです。ビックカメラは以前からやっていないと店員さんに教えていただきました。

ビックカメラやヨドバシカメラなどの量販店で登録のやり方を書いた紙を渡されても、対象外ですので気をつけてください。
情報がきちんと行き渡っていないんでしょうね。

以上、当たり前の情報かもしれませんが、自分のように「iPad2はどこでもソフトバンクWi-Fiスポットがついてくる」と勘違いしてしまう人のためにまとめました。に教えていただくまで気づきませんでした。ありがとうございます！

参考URL

#ちなみに、3つ目のtogetterは自分でまとめたのですが、煽りたいと言うよりは自分のような誤解で無駄なエネルギーを使うことが減るようにと思いまとめました。
#無論、適切な説明をSB、 一部以外の 量販店はすべきと思いますけど。

エリック・ウィテカー氏、予定通り来日！

Sat, 09 Apr 2011 15:01:28 -0700

合唱指揮者であり作曲家でもある、さんによると、ことエリック・ウィテカー氏の、への来日が予定通り行われることが明らかになりました。(@hanagoroさんありがとうございます！)
しかも、福島での講習会も(福島の方々が希望されるなら)行きたいとのこと！
素晴らしい！

これで君もウィテカーになれる！？「誰でもウィテカー」はじめました #darewite

Sat, 09 Apr 2011 15:01:23 -0700

20110409追記：Whitacre氏が改めてそうです！！

最近、日本の演奏会でもよく演奏される人気の合唱作曲家、。先日公開された、Virtual Choir 2.0でもおなじみですね。

そんなEric Whitacreになりきれる、「誰でもウィテカー」という何の役にも立たないTwitterサービスを始めました。
使い方は簡単。
にアクセスしてツイートするだけ。そうすると、Whitacreの口癖である"Woo hoo!“というノリノリワードをツイートできます。さらに、クライアント名が「誰でもウィテカー」になります。

使用例：

明日は給料日だぜ Woo hoo!
今度のTED Talksに呼ばれちゃったぜ Woo hoo!
うちの娘が可愛すぎてやばい Woo hoo!
クリスマスは彼女と過ごすぜ。画面から出てきてくれないけどな Woo hoo!
「誰ウィテ」でツイートしてたら、ドンドン合唱曲のイメージがわいてきて作曲しまくりだぜ Woo hoo! え、本当に口癖かって？ほらね。使ってるでしょ

え？Virtual Choir 2.0を知らないって？この動画を早く見るんだ！

本当に口癖か調べてみた今回、「誰でもウィテカー」を作るにあたって、「最近、よくウィテカーは"Woo hoo!“って連呼してるよな。ReplyもWoo hoo!だけのとかあるし」という直感からウィテカーになりきるには"Woo hoo!“といえば良い！ということになりました(笑)

本当にWhitacreの口癖が"Woo hoo!“か調べてみました。

今回は、Pythonとnltkを使って最近200ツイートを調べてみました。すると、驚くことにbi-gram(2語)の頻度を見てみると

Woo hoo! 10
Virtual Choir 9
of the 6
to the 6
Choir 2.0 5
one of 5
with the 5
I could 4
and I 4
at the 4

なんと言うことでしょう、“Virtual Choir"よりも"Woo hoo!“の方が頻度が高いではありませんか！

ちなみに、uni-gram(1語)を見てみると、

the 61
I 46
“;-)” 42
you 29
a 28

第3位に”;-)“という顔文字が(絵文字に変換されてしまうため"“でくくっています)。この顔文字も使えば大丈夫。特に、適当なReplyをしたいときに

@XXXXXX “;-)”

を使えば完璧です。

ちなみに、tri-gram(3語)の頻度を見ると、安心の結果が出ています。

Virtual Choir 2.0 5
tell you how 4
Wish I could 3
the Virtual Choir 3

まとめ

WhitacreになりきれるWebサービス、「誰でもウィテカー」を始めました。
ウィテカーになりきるには、“Woo hoo!“と”;-)“を使えばOK！

参考URL

(Twitter@Anywhereの参考にさせていただきました)
(Twitter@Anywhereの参考にさせていただきました)
(NLTKの参考にさせていただきました)

Peter Hollensの"Firework"一人アカペラが格好いい

Fri, 08 Apr 2011 04:04:30 -0700

で知ったのですが、Peter Hollensという人の一人アカペラアレンジがカッコいいです。

オレゴン大学で音楽の学位 (Vocal Performance コース) を取得し、現在、m-pact や The House Jacks の CD を手がけたことで知られるサンフランシスコ大手のアカペラレコードレーベル “A Cappella Records (ACR): )” のディストリビュータとして活躍しています。そのアレンジの才と歌唱力は折り紙付き！

とのことで、その実力をご覧ください。

原曲はKaty PerryのFireworkです。こちらがその原曲。

個人的には、Peter Hollensのアレンジの方が好きです。いや、この調を選ぶセンスは良いなぁと思いますよ。
イントロのonononoみたいなところが耳に残って離れませんねー。

では、日本のための祈りの曲も！

それでもTake6は来日する

Thu, 07 Apr 2011 15:01:11 -0700

【20110531追記】[オフィシャルサイトによると、Take6の来日は2012年2月に延期されたようです。

期待させてしまった方はすみません。]( )

先に断っておくと、推測混じりのお話です。

以前、でも来日すると紹介したアカペラグループTake6ですが、多分来日するみたいです。

FacebookのTake6のページにがあります。

日本の被災者のために祈りを込めて歌ってくれています。

その冒頭で、

「地震、津波、原子力に苦しむ日本の友人達に」

と言うあたたかい言葉があります。

また、その一方で4/7現在Take6のサイトにて、が公開されています。一部引用します。

At this point, we are not sure of the best way to help, but we will offer

our prayers to God on your behalf. He knows all and sees all.

We are looking forward to seeing you soon in Tokyo.

現時点でどうしたらあなた達の役に立つことができるか、まだわからないのですが、

あなた達のために神に祈っております。神様はすべてご覧になっています。

日本でお目にかかれる日を待ち焦がれております。

勿論、この先どうなるかは分かりませんが、きっとTake6はこういう状況の中でも敢えて来日してくれるという希望が湧きました。

まだまだ、のようですので、5/30,31に是非コンサートを楽しみたいものです。

ガチャピン sings Rajaton？

Wed, 06 Apr 2011 15:01:06 -0700

きっかけは、君のラジオがリニューアルしている様子がはてブのホットエントリ入りしたところから。
あの手のYouTubeの検索マッシュアップではRajatonを検索するようにしているのですが(本人達の演奏が少なくノイジーなのです)、今回も見事にアマチュアやら関係ない動画がざっくざっく引っかかりました。

ところが、そんな中でアマチュアなんだけど中々良い演奏をしている動画が見つかったのです。
それが、こちら。

というガチャピン人がRob McLarenさんとコラボしている動画です。Rajatonオフィシャルでちょろっと聞けるだけのこの名曲ですが、YouTubeにこのクオリティでアップロードしたのは快挙だと思います。

で、この動画のメロディーを歌っているのがメゾソプラノ(真ん中上)なんですが、こいつがくせ者です。というかガチャピンです。最終的にはになります。お腹痛い。

でね、このガチャピン、亀にもなるんですよ。

懐かしのタートルズです。

そのほかにも、ドッカンドッカンかめはめ波うったり、ポケモン歌ったりしてます。この二曲は英語版の曲自体が格好いいのでそういう意味でも聞いてみてください。

YouTubeのチャンネルは。
ちなみに、ではMP3がダウンロードできます。

Eric WhitacreのTEDでの講演が公開

Wed, 06 Apr 2011 15:00:59 -0700

当ブログでも Eric Whitacre氏のVirtual Choir。YouTubeを通じて合唱しようぜという企画です。2月頃にWhitacre氏がVirtual Choir2.0に関してする、という話が挙がっていたのですが、ついにようです。

まだ、日本語の字幕は出ていませんが、基本的に動画を使ったわかりやすい説明をしているので、英語があまり分からなくても何となく楽しめるものとなっています。
内容としては、今までのVirtual Choirの取り組みの説明と、今回のSleepの動画の作成過程と、その内のいくつかの歌い手の動画の紹介。(9才の少年からおじいさんまで参加しているとか！)
最終的なSleepの演奏動画も12分頃から2分ほど見られますので、そちらが気になる方はどうぞ。

ちなみに、Downloadもさせてくれるみたいです。

JCDA合唱の祭典2011〜第12回北とぴあ合唱フェスティバルへのはどうなるのかまだ分かりませんが、是非来ていただきたい物です！

知らなかったけど、があったんですね、、、

、という話をのですが、こちらもうまくいくといいなー。

Googleカレンダーの場所情報をGoogleマップに表示する方法

Fri, 04 Mar 2011 14:00:54 -0800

に登録していると、ふとイベント情報の開催地を地図上に表示したくなりました。

探してみると、があってYahoo!pipesを使ってやった人がいるようです。(日本語の紹介記事は )

どうやるかというと、Google CalendarのXMLのアドレス(カレンダー設定のところにあるURL)をにつっこみます。
More Optionsで得られるKMLデータのURLをGoogleマップのクエリに投げるとできあがりです。

になります。

ただ、Googleマップに表示はしているものの、Googleカレンダーの場所情報から地図情報に変換しているのは米Yahoo!の仕事なためか、精度がよろしくありません。

頑張って、GoogleカレンダーとマップのAPIを使って処理するしかないのでしょうか。。。

DropboxがHTML公開を簡単にする- @acappella_event関連まとめサイト作成してみた

Thu, 03 Mar 2011 14:00:49 -0800

何を作ったか？

@acappella_eventがつぶやいているアカペラ/合唱カレンダーを見やすくはっつけるサイトがほしかったんです。
あと、Pana Musicaの新刊botがつぶやいている新刊情報も見やすくしたかったんです。

で、ここにできたものがあります。

[2011/12/10追記]
現在はこちらに移行しております。(ほとんど同じ物ですが)

なぜ、Dropboxか？

Wordpress.comはiframeやscriptが使えないという安心設計になっているため、google calendarやtwitterのTLウィジェットを貼り付けることができませんでした。

で、それらを見るためのサイトをGoogle App Engine上においてみようかとも思ったのですが、マシンを移行したこともあり面倒だなぁと思っていました。

そんな折に、を見つけたわけです。簡単に言うと、HTMLをDropboxのPublicフォルダに置くと、公開できるというもの。

レンタルサーバも要らなければ、広告も入らない。 うまくやれば、 CSSも使えるんじゃね？ と思い始めてみたわけです。

できた

以前読んだ、HTML5とCSS3使うと簡単に？サイトが見栄え良くできるというを参考に、もりもり書いていきました。

正直言うと、最近HamlやらSassをSinatraとともに使っていたので、生のコード書くのだるいとか思っていましたが、Windows付属のメモ帳で2時間くらい調べながらかけて書いたらできあがりました。xyzzy入ってないマシンでやるもんじゃないですね。Windows7はUTF-8のファイルがはけるようになったから、勢いでやってしまいました。

ちなみに、カレンダーに情報登録してくださる方は随時募集しておりますので、@chezouまでtwitterでご連絡ください。

Twitterの合唱大喜利は楽しい

Wed, 02 Mar 2011 14:00:43 -0800

Twitterでしばしば見かけるのですが、誰からともなく大喜利が始まることがあります。たとえば、何かの「あるあるネタ」なんかの広がりも面白いです。

手前味噌ですが、合唱ネタを中心にこんなものが過去にありました。

皆でネタを広げて、さらに皆で追加してという流れが面白いですね。

ただ、twitterの日本語検索が結構漏れが多いので、ハッシュタグを先につけておいた方が良いかと思います。こういった盛り上がりを自動的にとぅぎゃれないだろうか。。。

マユールティールーム川崎店とティーハウスマユール宮崎台店の違い

Sun, 13 Feb 2011 14:00:38 -0800

先日、川崎のアゼリアにあるマユールティールームと、宮崎台にあるティーハウスマユールに行ってきました。写真は、宮崎台のマユールのチキンカレーです。

元々、川崎のアゼリアにあるには、リーズナブルなお値段でおいしい茶葉が買えるということで、ちょこちょこお世話になっていました。
いつの間にやらとのことで、チェックもしていました。(あまり更新はされていないようですが )
席は少なくカウンター4席くらい、テーブル席がソファー有りで3つ(2人×2＋3人)とこぢんまりとしていますが、ソファーのおかげで赤ちゃんがいてもなんとかなりました。ちなみに、アゼリアの多目的トイレが近くにあるのでおむつ替えも比較的容易でした。

で、先日いただいたのがこのフォンダンショコラと。ホワイトショコラチャイは初めて飲んだのですが、チョコがほどよく溶けてなかなかおいしかったです。フォンダンショコラもほどよい甘さでよかったです。

ちなみに、マユールに始めていったときに、「チャイをお願いします」と言うと「どのチャイですか？」と問い返されて驚きました(笑)5種類くらいのチャイから選ぶことができます。

ある日、ツイッターでがあることを知ります(オフィシャルサイトは )。川崎店が既にチェーン店がなさそうな雰囲気のお店だったので、たまたま同じ名前なのかなとか思っていたのですが、どうも関係がありそうです。
そして、さんからので行かないわけにはいかなくなりました(笑)

雨の中、宮崎台の駅から徒歩3分かけて行ってみました。すると、入り口付近には見慣れたクジャクのマークのお茶が！そして、ランチタイムは14時までと既に過ぎていたのですが、チキンカレーとタルトタタンをいただきました。
スパイシーでちょっと辛めだけど、どんどん食べられるそんなカレーでした。辛いのが苦手な妻でもぱくぱく食べていました。タルトタタンは、アップルパイのようなタルトです。すごくリンゴの味が生きていておいしいタルトでした。ほっぺた落ちます。

ちなみに、何も考えずに行ってからおむつ替えの問題を思い出したのですが、たまたま空いていた時間帯だったため、空いている席でいすを並べておむつ替えをさせていただきました。本当にありがとうございます。

肝心の「川崎店とはどういう関係なのか？」という疑問を、お店の方に聞いてみました。すると、

元々、五反田のマユールジャパンが紅茶の卸売りをしていること
川崎のマユールと宮崎台のマユールは姉妹店みたいなもの
川崎のマユールの店長は紅茶のインストラクターも持っていることもあり、新しい飲み方なども研究されており、お茶を楽しむのにぴったり
宮崎台のマユールは、お茶はもちろんマユールの茶葉を使用しておりおいしいが、店長さんの丹精込めてつくられたデザートは絶品ということがわかりました。

まとめますと、 お茶を楽しむなら川崎店 へ、 デザートを楽しむなら宮崎台店 の方が、よりこだわりの味を楽しめておすすめです。
いつか、五反田のお店も行ってみたいです。

Take6が2011/05/30,31に来日公演！

Tue, 08 Feb 2011 04:02:09 -0800

が非常にださいのですが、Take6が東京にて来日公演するようです。
5/30(月),5/31(火)の二日公演で、初日がアカペラのゴスペル、R&Bの演奏、二日目が新日本フィルとの共演Jazz、Classicalの演奏のようです。アカペラが良い人は初日の夜でしょうか。
チケットは、ならびにメンバー向けの先行発売は2/6からもう開始しているようです。
一般発売は、 2/20 からのようです。

詳細は、を確認していただくとして、概要は以下の通りです。

会場：すみだトリフォニーホール
日時：2011/05/30 ,31 開場18:30 開演19:00
タイトル：TAKE 6 ジャパンツアー 2011 “All About TAKE 6 from Gospel to Classic”
第1夜：ゴスペル＆ R&B ナイト
第2夜：ジャズ＆クラシック・ナイト with 新日本フィル
チケット：2公演セット券：S\14,400　A\12,600 各1回券：S\8,000　A\7,000
(トリフォニークラブ会員ならびにブルーノート東京JAM SESSIONメンバーは、
2公演セット券はS\12,800　A\11,200、各1回券は各10%引き)

コンテンポラリーアカペラの大御所なので、是非聞かれてみてはいかがでしょうか？
オフィシャルサイトに、Youtubeの動画がいくつかのせられているようです。

Acer Aspire 1410をcrucial RealSSD C300に外付けDVDなしに換装した

Sat, 05 Feb 2011 02:02:47 -0800

●せっかちな人のための結論

RealSSD C300いいよ！SATA2でも十分HDDに比べて恩恵感じられるよ！１万円なら全然あり！
記事の内容としては、外付けDVDなしでリカバリしないでSSD(64GB)への移行する際のポイントを書いていきます。

●はじめに

ある日、メインで使っている第１世代ののCPU(CoreSolo!)が、昨今のAtomにすら負けているということを知り悔しくなって新しいマシンを手に入れることを模索し始めました。
（誰だよ！「ノートPCにはDual Coreは要らない、敢えてCore Soloにしたんだ。」とか言ってたVaio開発者は！)
でも、なかなか物入りの時期なのと、自分好みの軽量のマシン(1.3kgとか重くて持てない)が、手頃な値段のものがMacBook Airくらいしかなかったので、妻のために買ったけど音楽再生専用機になっていたAcer Aspire 1410 (いわゆるCULV)を接収することにしました。
きっかけは、某巨大掲示板に「CULVノートはCore i5を狙うよりもSSDにした方が幸せになれるんじゃ」ということが書いてあったのが背中を押してくれました。

●用意するもの

RealSSD C300
Acer Aspire1410
SATA-USB変換ケーブル or 2.5inchケース

・SSD

今回購入したSSDはの64GBのモデルです。早いのに1万円程度と手頃なのが魅力的です。SATA3で本来の実力を発揮できるらしく、Sandy BridgeのCPU買った人が一緒に買っているようです。なお、 国内正規代理店のものは3年保証 、 並行輸入品は1年とか半年とかの保証 だったりするので、買う店は選んでください。
内容物はSSDのみなので、バックアップツールやSATAをつなぐケーブル等は用意しないといけません。(当たり前ですよね)

・マシン

Acer Aspire1410はCeleron SU2300という安いながらDual Coreのなかなかできる子です。Windows7の64bitを積んでいるのでメモリを4Gまで増やしてあります。
ただし、リカバリディスクを作成するのに外付けDVDドライブを購入する必要があります。今回は一応リカバリディスクは作成しましたが実質的には使いませんでした。
ちなみに、購入したのはこちらの (Buffalo DVSM-PS58U2-WH)。小さくないしちゃちいです。初期不良つかまされましたがTSUKUMOがさくっと交換してくれたので無事使えております。

・SATA-USBケーブル or 2.5inchケース

SSDにHDDの内容を移すために使いました。

●やり方

0.SSD交換のイメージをつかむ

の記事にある、を見て交換の仕方をつかみます。
っていうか、簡単です。開けてケーブル抜いてさすだけです。

1.SSDをSATA-USBケーブルで接続する

外付けドライブとしてSSDを認識させます。

2．HDDの中身をSSDにバックアップ

こちらのサイトを参考にさせていただきました。

簡単に言うと、リカバリディスクではリカバリ領域をバックアップできないので、を使ってHDDを丸ごとCloneしましょうということです。
このソフトは、コピー元のドライブ(HDD)のサイズがコピー先(SSD)より大きくても、実際の使用量がコピー先のサイズを超えていなければ適当に調整してくれます。もちろん、自分でパーティションサイズを変えることも可能です。今回は元々のCドライブの領域以外は最小としました。
詳細なやり方はの記事などを参考にしてください。
ちなみに、Partition Cloneは一つのパーティションしかコピーできず、Windows7はCドライブの領域以外にMBRに相当するパーティションが必要なため今回はあきらめました。

ドライブのcloneにはおよそ30分程度かかりました。

3.HDDをSSDに入れ替える。

先ほどのの通り、裏蓋を開けてHDDをSSDに交換します。ドライバーは普通の＋ドライバーでOKです。

4.起動する

普通にWindows７が起動します。しかも、今までの設定のまま。

5.SSD向けに設定を調整する

通常、Windows7はSSDにインストールするとSSD用に最適な設定をしてくれるのですが、HDDのCloneのためいくつかの設定を変える必要があります。

詳細はこちらのサイトを参考にしつつ、以下のことをしました。

自動デフラグの停止
Prefetch/Superfetchの停止
WebキャッシュをRamdiskに Ramdiskはが楽ちんです。Firefoxのキャッシュもボタン一つで設定できます。

●ベンチマーク

こんな感じです。ランダムwriteがちと遅いですが、読み込みは速いです。

●ちなみに

リカバリ領域からのリカバリもばっちりできました。ただし、のはリカバリでは無理でした。当たり前か。

リカバリ後のベンチマーク結果はこちら。

●結論

SSDいいよSSD。 劇的に速くなるという感じではないけど、Windows7の起動後や休止状態からの復帰後の壁紙見えてから実際に安定して使えるまでの重い時間が皆無になりました。
Windows7は休止から復帰が速くなったように見えて、実はログオン後に逐次読み込みしてるのが重くて嫌だったんですが、4Gのメモリでも素早く復帰します。
1万円でこの効果は大きいですね。120GBの容量がほしかったり、ランダムwriteを気にする方はintelのssdにした方が幸せかもしれません。

無料でiPhoneの標準カレンダーにアカペラ/合唱カレンダーを表示する方法

Fri, 17 Dec 2010 14:00:21 -0800

AppBankで話題になっていたこのカレンダーの記事を見て、気づきました。もiPhoneでみられるじゃないか！

やり方は簡単。先ほどの記事を参考にしながら、以下のURLを登録してくださればOKです。

URLは、メールやらtwitterやらでiPhoneで取得できるようにすれば良いでしょう。勿論、このやり方だと書き込みはできないので、その点はお気をつけてください。

この話自体は割と知られてると思っていた話なんですが、Googleカレンダーの公開カレンダーにもicalのアドレスがあったということを忘れていました。

ちなみに、 カレンダーに予定を書き込んでくださる方を大募集中 です！
合唱の演奏会やアカペラのライブの告知がしたい方は、google calendarを編集できるメールアドレスを用意して是非までご連絡ください。

カレンダーに登録すると何が嬉しいか？が自動的に前日、当日に宣伝してくれます。
詳細は、の記事をどうぞ。

夜のヴェネツィア

Fri, 12 Nov 2010 22:11:52 -0800

夜というか早朝のサンマルコ広場から見た景色です。なんというか、不思議な雰囲気が漂っていますね。この年は実は歴史的なアクアアルタがあった年となったようで、着く数日前にはだったようです。なので、わざわざ腰くらいの位置に踏み台で通路を組み立てて、水に濡れないようにしていました。街中では若いお姉さんが、レインブーツを華麗にはきこなしていました。

最初は何か分からなかったのですが、朝になると潮位が上がり通路の必要性がようやくわかりました。わざわざそれを準備したり撤去したりする人がいるのを眺めて、街の人たちは慣れているのだと感心したものです。

instagr.amが面白い

Sun, 07 Nov 2010 14:00:00 -0800

今更ですが、をはじめました。内容はざっくり言うと写真共有のSNSでiPhone専用のAppが簡単にフィルターかけられて楽しいわけです。色々言及されていますが、Twitterやfacebook,flicker,Tumblrまで連動して投稿できるという。古いiPhoneってカメラもへぼいし、アプリは3Gでもサクサク動くので良い感じです。なんとなくPicasaからinstagramへ写真を流す方法無いかなーとか思っています。iPhoneから流さないと行けないのが、最大の特徴でもあり悩ましい点でもあります。結構、写真たまってきたんだよなー。 instagramはお出かけしないとあまり活躍しない気もしていますが、色々試してみようと思います。

MeCabをRuby 1.9.2 on Windows7(64bit版)で使う方法

Wed, 13 Oct 2010 14:59:53 -0700

Windows7の開発環境を構築するに当たって、なんとなくRubyを1.8.7から1.9.2にしてみました。
そしたら意外とx64でMeCabを使えるようになるまでにハマったのでメモしておきます。
Makefileとかよく分からないなりに頑張ったのですが、かなりいい加減だと思います。

方針としては、libmecab.dllをx64環境でコンパイルしなおして、次のサイトを参考にしてmecab.rbを作ります。(ついでに、元々ので実装されていたsparse_tonode(str)も使えるようにさせていただきました。ありがとうございます！ )

Windows版のMeCabをとりあえず入れておく。
MeCabのソースを入手し、展開する。
src以下にある、mecab.h, feaure_index.cpp, wrier.cpp, Makefile.msvc.inを修正する
mecab.h
・254行目　#ifndef SIWG → #ifndef SWIG
・257行目 #endif を 260行目の};の前の行に挿入 feaure_index.cpp
・311行目 case 't': os_ \<\< (size_t)path-\>rnode-\>char_type; break;
→ case 't': os_ \<\< (unsigned int)path-\>rnode-\>char_type; break; wrier.cpp
・236行目 case 'L': \*os \<\< std::strlen(sentence); break;
→ case 'L': \*os \<\< (unsigned int)std::strlen(sentence); break;

Makefile.msvc.in → Makefile.msvcにファイル名変更
・5行目 /MACHINE:X86 → /MACHINE:X64
・7行目、8行目

DDIC_VERSION=@DIC_VERSION@ → - DDIC_VERSION=102
DVERSION=”\”@VERSION@”\”" → - DVERSION=“\”0.98″\”"

2011/01/11追記:
Visual Studio 2010ではcommon.hに #include を追加する必要があるそうです。
詳しくはこちらを参照(Thanks to id:mayukiさん！)

Visual Studio 2008 x64 Cross Tool コマンドプロンプトでnmake
できたlibmecab.dllをlibmecab64.dllなど適当な名前にして、libmecab.dllと同じフォルダに移動
とを参考にしてmecab.rbを作成

# -*- coding: windows-31j -*-
require "dl/import"
require "dl/struct"

module MecabFunc
 extend DL::Importer
 dlload 'libmecab64.dllの場所'
 typealias('size_t', 'unsigned long')
 extern "mecab_t\* mecab_new2(const char\*)"
 extern "const char\* mecab_version()"
 extern "const char\* mecab_sparse_tostr(mecab_t\*, const char\*)"
 extern "const char\* mecab_strerror(mecab_t\*)"
 extern "void mecab_destroy(mecab_t \*)"
end

module MecabLib
 class Mecab
 include MecabFunc

 @mecab=nil

 def initialize(args)
 @mecab=MecabFunc.mecab_new2(args)
 end

 def version()
 MecabFunc.mecab_version()
 end

 def strerror()
 MecabFunc.mecab_strerror(@mecab)
 end

 def sparse_tostr(str)
 MecabFunc.mecab_sparse_tostr(@mecab,str)
 end

 def sparse_tonode(str)
 #http://nlp.sfc.keio.ac.jp/~aihara/nlp.html でのaihara氏の実装です。
 prev=nil
 head=Node.new()
 tmp_str= "#{sparse_tostr(str)}"
 tmp_str.split("\n").each{|line|
 buf=Node.new(line,prev)
 if prev!=nil
 prev.next=buf
 end
 prev=buf
 if head.next==nil
 head.next=buf
 end
 }
 head
 end

 def destroy()
 MecabFunc.mecab_destroy(@mecab)
 end

 class Node
 @prev=nil
 @next=nil
 @surface=nil #形態素の表記
 @pos=nil #品詞
 @root=nil #原形
 @reading=nil #読み
 @pronunciation=nil #発音
 attr_accessor :prev,:next,:surface,:pos,:root,:reading,:pronunciation

 def initialize(line=nil, prev=nil)
 @prev=prev if line != nil
 if line == "EOS" #EOSの時
 @surface=line
 @pos="EOS"
 @root="EOS"
 @reading="EOS"
 @pronunciation="EOS"
 else #それ以外
 linels=line.split("\t")
 @surface=linels[0]
 fetls=linels[1].split(",")
 @pos=fetls[0..5].join(",")
 if fetls[6]==nil
 @root=""
 else
 @root=fetls[6]
 end
 if fetls[7]==nil
 @reading=""
 else
 @reading=fetls[7]
 end
 if fetls[8]==nil
 @pronunciation=""
 else
 @pronunciation=fetls[8] end
 end
 end
 end

 def hasNext()
 if @next==nil
 false
 else
 true
 end
 end
 end
 end
end

mecab.rbの名前をmecab64.rbとでもつけます。実際に呼ぶときは、RUBY_VERSIONで切り替えたりしています。

# -*- coding: windows-31j -*-
require "mecab64"
m = MecabLib::Mecab.new("")
puts m.version
puts m.sparse_tostr("本日は晴天なり。")
node = m.sparse_tonode("本日は晴天なり。")
while node.hasNext
 node = node.next
 print node.surface + " : " + node.pos + " : " + node.root + " : " + node.reading + " : " + node.pronunciation + "\n"
end

とすると、次のような結果が出るはずです。

0.98
本日名詞,副詞可能,*,*,*,*,本日,ホンジツ,ホンジツ
は助詞,係助詞,*,*,*,*,は,ハ,ワ
晴天名詞,一般,*,*,*,*,晴天,セイテン,セイテン
なり助動詞,*,*,*,文語・ナリ,基本形,なり,ナリ,ナリ
。記号,句点,*,*,*,*,。,。,。
EOS
本日 : 名詞,副詞可能,*,*,*,* : 本日 : ホンジツ : ホンジツ
は : 助詞,係助詞,*,*,*,* : は : ハ : ワ
晴天 : 名詞,一般,*,*,*,* : 晴天 : セイテン : セイテン
なり : 助動詞,*,*,*,文語・ナリ,基本形 : なり : ナリ : ナリ
。 : 記号,句点,*,*,*,* : 。 : 。 : 。
EOS : EOS : EOS : EOS : EOS

PRESS START 2010でゲーム音楽演奏会情報をゲットした

Sat, 11 Sep 2010 14:59:48 -0700

ゲーム音楽の演奏会情報フリーペーパー2083なるものをでいただきました。

どうも調べてみると、ゲーム音楽情報のポータルサイトというサイトがあったということを知りました。2009年10月に立ち上がったところみたいで、

ファミコンが誕生した1983年から100年後の2083年には、
ゲーム音楽が現在のクラシック音楽のように、
たくさんの人に認知され、演奏され、
優秀なアーティストが集まり、発展していき、そして、文化を変える。

というコンセプトを元に、
ゲーム音楽の演奏情報ポータルサイト「2083WEB」というメディアと
という楽団を
立ち上げました。

というコンセプトのようです。

最近、ゲーム音楽を中心に演奏するアマチュア団体も増えてきているみたいですし、素晴らしい取り組みだと思います。４STAR ORCHESTRAも楽しみですねー。演奏会も東京だけでなく、神奈川、大阪、兵庫、宮城、千葉と色々広がっているようです。

本当は演奏会情報をこちらに書こうと思ったのですが、ポータルがあるならそれで十分かもという気がしてきました(笑)

しかし、ゲーム音楽でこのようなポータルサイトができるのに、何故合唱ではこういうサイトがないのでしょうか。(いや色々あるかもしれませんが、ここまでまとまっていない感があるのです。。。)
せっかく連盟まであるのになー。

PRESS START 2010行ってきた

Sat, 11 Sep 2010 14:59:42 -0700

本日、に行ってまいりました。
(写真はプログラム、この演奏会にあわせて発売した、フリーペーパー2083)
20100912追記

CDはどうやら、そんなに数生産しないのでしょうか？欲しい方は早めに買った方がよいかもしれません。専売のようです。

一言で言うと非常に良かったです！素晴らしい演奏でした。

特に良かったのが、クロノ・トリガー/クロノ・クロスメドレー。去年も思いましたが、一曲目の気合いの入れ具合が違うのがこの演奏会の特徴なのでしょうか。カエルのテーマや魔王決戦とかは鳥肌ものでした。そして、トリガーとクロスでは若干パーカッションの編成が違うのか雰囲気も少し違っていて楽しめました。最後のChrono Cross-時の傷跡-でしめるあたりがわかってらっしゃる。トリガーのころのメロディを使って終えるわけですね。素晴らしい編曲！
ちなみに、メドレーの詳細は次の通りでした。

予感/クロノ・トリガー/風の憧憬/カエルのテーマ/魔王決戦/エピローグ-親しき仲間へ-/
凍てついた炎/マブーレホーム/Chrono Cross-時の傷跡-

後は、 「ファミコンここまで出てるのにメドレー初級者編」 が非常に楽しめました。やはり、にわかな僕にはタイトルしか知らないものも多かったのですが、ファイアーエムブレムとドクターマリオはメロディの第一音くらいからわかりました。基本的にメドレーと言いつつも、毎回切ってつなげているだけなので最初にパーカッションがリズムを整えるときのリズム感と、使用される楽器の編成で分かるんですよね。特にスネアで入ってきたファイアーエムブレムはこれしかない！と思っていました。もしかしたら、会場の方はゲーム大好き原曲大好きな方が多いけど、オケ編曲されるのには慣れていない方が多かったのかもしれませんね。でも、分かったら(分からなくても)手拍子してくださいね、というのは良いですね。盛り上がります。鬼ヶ島の反応の少なさは少し笑えましたが。

今年の演奏は神奈川フィルだったのでとても良かったです(昨年はゲームに対する愛が少なかったように感じたのですが)。ただ、アレンジャーの個性が強い曲がちらほら見受けられたかなー、という印象もありました。古代祐三氏のゼルダの伝説(スマブラ版は )は、当初3分の曲だと思って書いてしまった幻のバージョンを下敷きにされているそうで、とても楽しみにしていました。ですが一カ所、ゲームの2分版にはないメロディの調が変わって変奏するところの和音に違和感を感じてしまい、んーなんだかなーと思ってしまいました。原曲や色々なオケアレンジに慣れてしまったからかなぁ。
あと、ロックマン2のワイリーステージ1のアレンジは、おっくせんまんの影響が強すぎたためか、Aメロの部分のメロディが弦であっさり背景的に流されてしまったのが物足りなかったです。

しかし、今回は 「ワイルドアームズセカンドイグニッション」 のメドレーでまさかの「口笛ソロ」を聞いてしまいました。演奏していたのは氏なのですが、どう考えても楽器です。ここまでビブラートや音色をコントロールできるんですもの。楽器です。それを駆使するなんてたまりませんでした。

朧村正の三味線も楽しくてしかたありませんでした。弦とかと違ってリズムを刻んでいくのが、凄く全面に押し出されていてかっこよかったです。そして、尺八もあんなに近くで見られたのは感激でした。ビブラートするときは首を振るんですね。

そして、リズム天国の忍者は相変わらず大盛り上がり。特に今年も行った会場の人から選んでの対決は、桜井さんのまさかの素手宣言に驚かされたのもつかの間、さらに驚きの連続が。まさか、手だけでなく、足踏みや口笛、正拳付き＋かけ声、オス！のかけ声などやりたい放題(笑)そんなお茶目な桜井さんが大好きだー！

MOTHERメドレーは素晴らしいの一言です。やはり、元の曲が良いからなんでしょうね。ボーカルのメロディー・チューバックさんは、EIGHT MELODIESの歌詞をうっかりミスってしまって舌出していましたが(笑)杉並児童合唱団は安心の実力を発揮していただきました。ありがとう！

なお、アンコールはメロディー・チューバックさんによる、のデモ(クロノトリガーの世界変革の時/ロマサガ3の四魔貴族バトル1)、そしてRomancing SaGa -Minstrel Song-を演奏していました。特にロマサガはメインテーマが本人によるピアノ演奏付きというサプライズも！いやぁ、堪能させていただきました。

というわけで、今年は非常に満喫させていただきました。流石5th Anniversaryですね。

ゲーム音楽の演奏会情報フリーペーパー2083なるものが一緒に付いていたのですが、そこに書かれていた演奏会情報は長くなってしまったので、で書きたいと思います。

豚組行ってきました

Sat, 04 Sep 2010 05:09:12 -0700

前々から噂には聞いていたのですが、一度も行っていなかった西麻布のに、さんに連れられて夫婦で行ってきました。

いやぁ、ご飯を食べて幸せな気持ちにさせてくれるお店というのは久々です。
トップの写真の3cmの琉香豚も柔らかくて余裕でかみきれるし、ヒレカツも柔らかくてんまかったです。栄晶豚(一番下の写真)というほとんど白身の豚も食べたのですが、いやー脂身ってあそこまで美味しくなるんですね。そこまで重たくなくプルっプルでした。
あと、なんでも、料理長が元々フレンチの方らしく、ラタトゥイユも出てきたのですがそれの味がよくしみていてたまりませんでした。
お店の方々の気遣いもあたたかく、また、是非行きたいお店です。

オオムラサキの羽化をCanon iVIS HF M31で撮影してみた

Sun, 22 Aug 2010 14:59:31 -0700

ので、それを使って動画をとってみました。なかなか写真と違ってどういうストーリーでとるのかとかを考えないといけないのが難しいところです。

北杜市にあるという所で撮影したのがこちらの動画。

撮影しながら思ったことが、撮るのにかなり集中しないといけないため、自分の目で見ることがなかなか難しいこと。後、個人的にはオオムラサキが国蝶であることも妻に教えてもらうまでに知らなかったのですが、実際の羽化に立ち会えるとなったらとてもワクワクしましたね。子どもにもこういう体験が大事なんだなぁと思う一方、デジタル教科書なんかで「映像で見せればいい」と言う人は、それはベターな手段ではあるけどベストではないと気づいているのかな？と思いました。やはり、実際に自分で体験したことというのは記憶に強く焼き付くしモチベーションも高まるというものです。そうしたバーチャルでは得難い体験（バーチャルではというよりも、そのイベントに立ち会えたという感覚が大事なのかも）というのは、大事になっていくのでしょう。 10年ほど前に、インターネットが発展するときにどんどん部屋にこもるんじゃないか、という危惧がなされていた記憶があるのですが、そのとき「皆が外に出たくなるようなインターネットになるにはどうしたらいいだろうか？」と思っていたら、mixiやらTwitterやらで外に出たくなるインターネットの環境というのはあっという間に広がったのに驚きを隠せないです。

しかし、今時は限定公開などでフルHD動画を共有すれば、実家にいる祖父母に孫の顔を見せるのは一番楽なのかも、とか思いました。

「学校教育の情報化に関する懇談会」第8回のメモ

Fri, 30 Jul 2010 14:59:26 -0700

先日7/28に開催されたの聞きながら書いたメモです。はこちらにありますので、きちんとしたものはそちらを参照ください。

今回の議論の目的は、修正されたを確認、議論することです。ビジョン骨子自体はWeb中継が始まってから15分後くらいにひっそりと公開されたので、まだきちんと目を通していません(早いうちに確認したいです)。が用意されていますのでそちらも参照ください。

個人的に重要と思ったものを、メモから抜粋してきます。
一言でそれぞれまとめると、

日常的な経験から協働的な学びを(玉置委員)
グラフィカルなCGなどパッシブなわかりやすいコンテンツではなく、抽象化・モデル化能力を育てる訓練を(新井委員)
情報を仮説を持って能動的に収集できるようにすべき(村上委員) という感じでしょうか。日常からの協働的学びと能動的な情報収集、情報処理能力という点は非常に共感できます。
○玉置委員
協働的な学びを日常から子どもたちが経験することが大事では？
日常生活のはてなを書き込んで、子ども同士で議論・解決をする。子供版熟議カケアイ、美術作品の見せ合いなど
日常的に情報端末を使い、学校の中できちんとコミュニケーションをできるようにすることで、21世紀にふさわしい学びができるのではないか。
活用が広がるような例を。

○新井委員
「わかりやすい」に関する懸念。
デジタルコンテンツは、「電磁場、惑星など観測・実験などで確認できないものを、見ることが出来るようになる。数式よりわかりやすくなる」という一般的な考えがあると思うが、これは逆ではないか。
惑星の大きさを物差しで測るのではなく、モデルと数式でこうなっているのではないか？と考えるのが骨である。理科の考え方は、少量のデータから抽象的なモデルを作ることが重要。パッシブなデジタルコンテンツでは代替は不可能、むしろ悪化させる。
またデジタルを活用する方法として、データを班ごとではなく、クラス全体で共有するというような、協働学習のベースとして情報機器を活用するべき。

○村上委員
今の学校でデジタル黒板などを使ったときのイメージが、わかりやすい以外が見えないことに懸念。
情報化がもたらしたものを教育でどう使うか？は書かれているが、膨大な情報を能動的に仮説を持って取りに行かないと何の意味がない。プロダクティブに仮説を持って取りに行こうという子どもたちが出てくる。
わかりやすい授業をやることで、こうした環境で生き残れる子どもができるのか。
ゆとりで足りなくなったコンテンツを増やしても、情報を仮説を持って取りに行けないと意味がない。

以下、聴きながらとったメモです。

2010年7月28日(水)
学校教育の情報化に関する懇談会第8回

「デジタル教科書教材協議会設立シンポジウム」参加しました

Fri, 30 Jul 2010 14:59:20 -0700

さる7/27に、デジタル教科書や教材を推進する民間中心の団体、が発足しました。
シンポジウムの内容は、各種記事がまとめていますし、内容の要約は、片山さんがにまとめてくださっていますのでご参考にしてください。
Usreamは前半が、後半(孫氏講演から)がにあります。

会場には600人超、ニコ動・Ustなどネット視聴は1万人以上(翌日の文科省の懇談会で報告されています)というほどの熱気でした。ソフトバンク孫氏の終始熱いプレゼンに会場が魅了されていたようにも思います。また、藤原氏の軽妙なトークも会場が湧きました。デジタル教科書に対する期待が伝わってきたと思います。
一方で、先にものを作ってしまえ、実証実験してしまえ、という姿勢は、子ども達に何を教育すべきなのか、それは本当にデジタル教科書・教材が答えなのか？というところが、孫氏、藤原以外ほとんど触れられておらず残念でした。(孫氏にしても、子ども達に感動を、という曖昧な主張をされていたのみで、現場の先生には「視聴覚教室や電子黒板でいいじゃん」と反論されそうだと思いました。)
藤原氏が「DSなどICTを活用したドリル学習による学力向上は証明されている」と述べたのに対し、小宮山氏が「私は本当に証明されているとは思わない。後でご議論をさせてください」というやりとりが、会のバランスがとれているという意味で健全な議論ができるのではないかと感じました。

登壇者の主張をまとめると、下記のような印象でした。

○三菱総研小宮山氏
知識が爆発的に増加・細分化し、絶えず変わっていく中で先生もついて行けない。
これら全ての問題がITで解決できるとは思わないが、答えの相当を担うだろう。
スピード感を持って、どんどん良いものを実証実験で検証を行っていくべき。（ラピッドプロトタイピング指向）

○慶応大中村伊知哉氏
現状のデジタル教科書の状況、他国の状況のよいまとめをなさっていました。

○マイクロソフト樋口氏 (なんとかビジネスモデルを確立したい)
今の日本はやばい。
東芝CM1でデジタル教科書のデモ実施。
海外で展開できるビジネスモデルを確立したい。

○ソフトバンク孫氏 (強いリーダーシップを発揮するための二元論的論理展開)
30年後の日本が生き残るためのビジョン展開として、知的レベルの向上を提案。
結果の平等を批判。国内で格差がなくなっても、国際的な格差が生まれる。
30年後の企業人が求められるもの＝リーダーシップ、競争意識、知的能力、グローバル交渉力
プレゼン能力、思考力、検索能力、分析力を学校教育で教えるべき。
丸付けなどITの得意なところはITに、人間の先生がやるべきところは先生に。

○学芸大藤原氏
協働的学びの模擬授業の実践と、それに対してクラス全員の意見を集約するのに情報機器が必要だという主張。
ドリル学習などの反復学習は、機械なら99回間違えても100回目に正解すればほめてくれる。人間だとこうはいかない。(これは教員を馬鹿にしているとの批判も考えられる)
校長がダメだから、多くの校長を変えろ。

というわけで、細かくメモったものをまとめもせずにはっつけます。備忘録代わりです。

2010/07/27 13:30-16:10
デジタル教科書教材協議会設立シンポジウム
＠明治記念館　曙の間

1TEXT file → ページ毎管理 → 1TEXT fileとしてダウンロード可

Tue, 20 Jul 2010 14:59:18 -0700

・著作権管理システム
・公開系システム

まとめ
1．コンテンツとフレームワークの切り離しを実施
→教育現場はどう受け止めるか？
2．多様な利用の可能性
実験書、実験ガイドブック、種々のワンストップサービス
3．著作権処理の困難(日本国民の活動に不利益)
4．オリジナリティとは何か？(この活動はどこにも保護されていない)
5．大学の研究？社会へのサービス？→大学の社会貢献
社会貢献にお金を割いていると、教育や研究にお金を避けなくなってくる。誰が負担をするのか？大学が事業として手を伸ばせないか？
6．双方向性、協調作業をどう可能にするか？
7．「理想の教科書」はコンテンツか？システム化？
・教師がtextB,Cを持つ学生を同時にまとめて教える
・textAを使うもの同士が協調作業できる
→これらを包括したプラットフォームがほしい
利用者の様々な工夫を生かせる、コンテンツが載せられるプラットフォームが欲しい

Q.UT-eTEXTはコンテンツとフレームワークが分かれていないように見えるが、再利用しやすいシステムになっているのか？
A.元の材料となるファイルは独立して存在しているので、そこから変換すれば大丈夫。
Q.プラチナ構想に乗るのか？乗せるべきではないのか？
A.18歳に自然に分かるものであれば乗せられる。ただし、今は一方通行にしかなっていないので、双方向なものフィードバックを出来るようにしなければならない。「私が知りたい物質科学は違うんだ」という声こそ重要。それをシステムに乗せることが出来れば、プラチナ構想に応えられる。

○UT-eTEXTをささえる　東大　大瀧友里奈
著作権の問題をどう考えるか

東京大学での実績
UTOCW(東京大学オープンコースウェア)
他人の著作物については、全て許諾をとっている(2005年から)

講義資料入手
↓
図版・画像等の出典確認作業およびリスト化
↓　　　　　　　　　　　　　　　　　↓
オリジナル　　　　　　　　　　　　　引用
↓　　　　　↓　　　　　　　　　　　↓
全オリジナル　自著だが出版社で加工　　　↓
……

著作権に問題ないように、差し替え、許諾を得るなどする

・Wikipediaから著作権フリーの画像を探す
・書籍、論文は著作者に問い合わせる
・ウェブ掲載物も同様
・許諾は講義のよって大きく異なる

90分あたり0〜170件
生命科学、都市科学、情報科学は多い傾向

対応を判断しないといけない場合
・家電や車の写真は誰の著作物なのか？
・建築物、工業製品はどこに許諾をとるのか？
・連絡先が不明の場合(出版社倒産、著作権者不明など)

これまでの課題
・膨大な作業量
・時間がかかる→既に過去の話題となってしまう
・情報の共有化が鍵→重複、漏れを避ける

著作権管理システムの構築
・コンテンツ管理と連動
・データベース化し、ノウハウを蓄積
連絡先 or 著作物を利用不可能

今後の課題
・資料作成時点からの改善
・許諾を得やすい出典のリスト化

Q.有料化はできないのか？
A.したいが難しい。国立大学法人がどこまでそれをやるのが許されるのかが分か
らない
Q.著作権が来年切れる、などあるのか？
A.ある。そういうものを管理するために、検索が出来るデータベースになってい
るのが重要。

○教科書の電子化が拓く可能性　神奈川大学　何森仁先生
資料参照

○教材を電子化して教育現場を変える」　東京大学　三宅なほみ先生
中京大学でIT基盤を使った、協調学習を研究していた。

電子化したかった一番の理由は、一つの章を書くのに最低3つの資料が出てく
る。教科書を出版するときは短いものを捨ててしまう。
一つのひな形として電子的にとっておける、ニーズに合わせた記述ができる、こ
れが電子化の一つの意義ではないか。

教材電子化の目的は？
・今できていなくてやりたいことは？

教育をどうしたいのか
・教育の質を上げたい←教員視点
・やり甲斐のある勉強をしたい←生徒視点
レベルの低いところから高いところまで対応する

教材電子化ビジョン
・学習者にとってのメリット

教材を学習者自身が編集して「自分なりに納得」し
他人の納得と比較吟味して
適用範囲を段々拡げ、その記録を取っておく

・教員にとって

同じ教材を教員が試して体験を共有し、
どうしたら教育の質が上がるのかを相互吟味して
「教育の質向上」コミュニティを活性化する

電子化すればコミュニティが出来ていく

教育をどうしたいのか？
・教育の質を上げたい

楽しく、真剣に学んで欲しい
今より進学率が上がればよい……だけか？

・やり甲斐のある勉強をしたい←生徒視点

分かるようになりたい
テストの点数があがる……だけか？

教育をどうしたいのかに「？」が付く理由
・目指されているのは、今の教育や学習では達成されていないこと

教員にも生徒にも「ゴール？」が見えない
新しい教え方はいろいろ提案されるが判断根拠が分からない

何が本当にベストな状態なのか？というのが分からない、見たことない

「？」への当面の答え
・学びのゴールは「発生的(エマージェント)」で多様

「自分なりのわかり方が他人と違うこと」が次のゴールを生む
「自分がとける(成果を適用できる)課題が他人と違うこと」が次の段階の学習を意欲づける

小学校5クラスあれば、皆違うことを教えれば、廊下で情報交換する、という話はあるが実現はされていない。
・教え方の原理は実践結果の相互吟味によって納得できる
二度と同じことは起こらないので、ケースを積み上げるしかない

「？」当面の回答支援
・学びのゴール←多様性を保証
・教え方の原理←教員間の相互吟味

教育現場を変える
・学習ゴールの多様性保証

学習者中心型学習形態へのシフト
学習履歴の保存、活用(自分と他の人の意見の比較)

・実践の共有・相互吟味保証

教材と実践結果の共有

先生が他の先生の教材を使ってフィードバックを返せる

教員ネットワークによる相互吟味

これら二つは相互にフィードバックされて良くなっていく
→電子的に履歴活用・相互吟味すので、電子化教材が2つがつながっていく

学習者中心型授業へのシフト
・自分の考えを外化して、意識的に見直したり作り替えたりする機会を積み上げる

「目的」のある外化によって意識かを容易にする
外化の履歴を振り返り、編集できる環境を準備する

・他人の考えを参考に、自分の考えを社会的に編集して抽象度を上げる

抽象レベルを上げるのに有利な聞き手の役割を重視
他人の外化履歴も活用できる環境を準備する

学習者中心型授業の仕組み
「雲はどうしてできるのでしょう？3つの資料の内容を組み合わせて答を作っ
てください。何故そういう答になるかも説明してください」(中学生)
・ある程度分かる部品を分担して担当
・各部品担当が一人ずつ集まって課題を解く
・各グループの解を総合的に検討して納得する

授業の成果
・雲の出来方を自分なりに説明できるようになる
・子供たちの感想

雲がどうやってできるか、予想していたのとまったくちがってびっくりした
曇って水蒸気の集まりじゃないの？
水滴と水蒸気って何が違うの？？？←元に戻ったのではなく、ここまで理解

できたと考えるべき
・どの程度

楽しかったか(35)楽しくなかった(1)
理解できたか(34)できなかった(2)

もう一つの例：「わかるとはどういうことか」(高校生)
・3つの資料

行間が読める
知っていることは覚えやすい
多義的な解釈も出来る

・「わからなくても、経験や知識がちょっと足りないだけ……かも」

実際のジグソー法の授業風景のビデオ
・先生同士で共有できるデータとは？
・Team Teachingでやる
・エキスパート(3つの担当)に分かれる。読むと分かること、記憶、脳について
・ジグソー(3つを併せる)

このような情報をCoREFで共有できるようにしていきたい
→高校数学の教科書も申請すれば使える(HTMLベース)

「使い方キット」に教案などがある

教材が共有できることの効果
・教員コミュニティの育成

教育委員会などと協力している

・教材作りへの「社会人プロ」の参加を容易にする

「教育現場の多様化」のモデル事業

学習履歴の活用
・授業ビデオと音声記録

失敗分析や知見もわかる
→学生のコメント「偏差値40くらいとは思えない、私たち」

電子化教材有効利用のためのIT基盤
・双方向性の確保

閲覧＋ダウンロード＋編集して投稿＋新規発信

→クラス全員の子供の音声を個人個人に切り分けて、テキスト化してほしい
・履歴の収集機能

ビデオ記録

・一部を切り出してコメントを付けweb上で共有する機能

音声記録

・クラス全員の話し合い音声記録からテキスト化

Q.早稲田非常勤の方。教員の能力・指導力を高めるためのDBを作る研究をしている。登録が非常に煩雑だと思うがどのように対応しているのか？
A.記録はかなりの部分で取りっぱなしになると思う。分析の時に、ここで何が起こっていたか知りたい！という時のために取っている。天井に360度カメラを付けて後からズームして分析できるというシステムは500万

○全体討論・まとめ　吉見俊哉先生
7つの論点
・小宮山先生

知の構造化

小柴先生が宇宙論から話していた。コペルニクスはなんで地動説を唱えたのか？アイゼンシュタイン「印刷革命」という書籍の中で言及。「新しい科学的発見があったわけではない。知識のプラットフォームにおける変化：グーテンベルグの印刷技術の発明。コペルニクスは50〜100年前の科学者と違って、自分の書庫を集めることが出来た。データへアクセスしやすくなった。データの比較検証して構造化することが出来るようになった。」これは、現代にも通じる。デジタルメディアのおかげで、莫大な情報に包まれている。情報の海の中で学問的に意味があることは、アクセシビリティの向上を、知の構造化へどのように結びつけるか？
たくさん情報が使える人が増えても仕方がない。自らの視点から情報をまとめあげることができるかが、教育として重要である。

Recycle

「資源をRecycleすれば資源に乏しい国じゃなくなる」という話は、物質だけの話ではない。知や文化自体をRecycleして構造化し直すことが重要。文化・コンテンツは生産→流通→消費という流れになりがち。テレビ・映画・芸術など様々な文化もRe-useしなければならない。蓄積して循環させないといけないという時代になっているのだろう。

うねり

「さざ波をうねりに変えなければならない」というのは、社会運動の語。60年安保、反日米安保のデモ行進？戦後からの「運動」というものが変わってきた。反体制運動→市民運動→社会全体が考えなければならない問題になった。
・藤原先生、大瀧先生

フレームワーク

フレームワークとコンテンツの分離とコンテンツの転用可能化。
何故日本の社会がGoogle,iPodを生み出せなかったのか？それがフレームワークとコンテンツの間にある問題に関係あるのでは？それは、標準化が出来ているのか？という問題に関係している気がする。

著作権とは何か

世界的にロスが大きい問題。文化的なリソースがあるのに使えない、最大のネック。著作権不明著作物(オーファン？著作物。みなしご著作物)。どうもはっきりしないために処理できないケースが多い。文化庁長官の裁定制度はあるが、非常に煩雑で処理が大変。公共的な合意ができない。

・何森先生、三宅先生

教科書とは何か

仮説：教科書の方が本より古いのでは？
知識の三脚台モデル：図書館(集積場)、教育カリキュラム(プロセス)、百科事典(情報)
百科事典は教科書に近い。
教科書は印刷された本そのものではない。教える/学ぶプロセスそのものである。学校、大学などができた中世、近世に戻るとその答があるのでは？技術と法的制度、学校現場の実践が組み合わせられながら実験されているのが現状。

教師とは何か

Wikipedia,Google,YouTubeなどで、誰かの知識が皆の知識になっている＝匿名化している。明確な著者がいるときは、間違いを犯しても責任の所在が明らかである。匿名化した場合は誰の責任かが曖昧化してしまう。教師はそういう意味でエキスパートである。専門性・エキスパート性をどう担保するかが重要。

・藤原先生
計算物理のシミュレーションで何十年かけてやってきたことを世の中に残したい。知識やプログラムを作ってきたが、もう一度作り直さないと世の中に出せない。モジュール化されていないため、更新しにくい。外部に公開するためには作り直しが必要。
研究した知識を公開するために標準化が必要。それをUT-eTEXTでやっている。

・大瀧先生
日本の中での教育が、教室の中だけでなくなっている。教育で使う場合はOKとい
う先生も多い。東大がリードしていきたい。

・何森先生
小中高の教師とは、生徒に分かってもらってなんぼ。若手の先生が手書きの資料をたまたま作っていったら、生徒は心がこもっているからそっちにして、と言った。匿名化については、「何を信用するか」という教育していけば良いのでは。大学の先生は分かってもらおうと思うよりも、熱を込めて伝えれば十分では。

・三宅先生
プロセスとしての教科書は電子化にとてもあう。
「オリジナリティに対する著作権」というのは面白くなる。「ガモフー」の話が面白いと言うが、それを紹介した人がすごいのでは。
エキスパート性とは、全ての人にわかりやすく説明できる人ではないか。

説明の多様性がとれるのが重要だと思う。

Q.日本人は機械設計はできるが、多国籍の人を引っ張っていってリーダーシップを発揮できる人が少ない。比較文化、比較言語を構造化してmulti cultural/lingualな人材が育つと思うがどう思うか？
Q.教育家庭新聞西田氏。高等教育に使われるものなのか、小中は範囲外なのか？
Q.NTTデータ重木氏。電子化教材がテーマ。エンドユーザが直接データを使える
のがコンピュータ利用の最大のメリットだと思う。学習者そのもののインタラク
ティブ性をどう考えるのか？
Q.産学連携を加速するフレームワークを。ニーズを産業界へ。
Q.理想の教科書をどのように大学教育で使えばよいのか？効果測定をどのように
するのか？
Q.子供にとって「知の構造化」が本当に重要か？優先順位として一番重要なのか？やる気のない先生をやる気のあるようにするのがポイントだと思う。どうする？

・藤原先生
A.産業の中での研究というものが、どういう考え方でやっているのか分からない。企業が何を目的に何を研究しているのか出さない。MDAを結んでも10分の一くらいしかわからない。人の流れがもっとあっても良いのでは。
ニーズとシーズがかみ合わないことについて。状況を大学教員が理解していない。UT-eTEXTを他大学が使えるか？という話は、是非使って欲しい。しばらくはフリーで使っていただくつもり。

・大瀧先生
A.著作権管理システム、編集システムは大学のみならず使ってもらえると思うので、一声ください。

・何森先生
A.やる気のない先生・社員は多い。パレートの法則の紹介。
先生は報告をしている。「来週の授業をどうするか」ということを。文科省の指導要領通りやりなさいということが、ことごとく言われる。やる気がなくなる。教員にもっと自由にやれる環境を。

・三宅先生
A.マルチカルチャー/リンガルの話。中京大の学生が苦手と思った英語のMITの授業のビデオをみていた。
一人の人間が、どういうところで何をやってどうなっているのか？大勢として日本人はどうなのか？という情報がない。1ケースのものすごく長いスパンの情報が集められると良いだろう。

・吉見先生
A.リーダーシップ。従来の大学教育の仕組みが、リーダーシップを発揮するものではないのではという批判は受け止める。が、大学だけの問題ではない。どうも、日本は知識を大切にしない社会なのではないか？本人だけが優れているから大切ではなく、社会の中での相互性によって人物ができるのでは。博士や修士が企業でどれだけ大事にされているのか？まっさらな状態で欲しい、というのでは大学の知識は大切にされていないのでは。
修士や博士をとれば、キャリアパスが広がる、というのではうまく社会へつながらない。社会の側で大学、大学で学んだ知識を大切にすべき。
アーカイブの話。岩波映画の保存活動をしている。岩波科学映画、理科教材として良くできている。古いが良い教材。良いコンテンツは古びない。ストックされて蓄積されるのが良い。NHKアーカイブスの公開化が進み始めている。国会図書館も同様。これをさざ波からうねりに変えていくのがこれから。

○藤原先生の締めの言葉

シンポジウム「教育の未来を拓く電子化教材」(UT-eTEXT)メモ

Tue, 20 Jul 2010 14:59:15 -0700

7/16(金)に東大で開催されたシンポジウム「」に行ってきました。
個人的にはその前の週のよりはビジョンベースの話が聞けて楽しかったです(EXPOはシーズベースというか既存製品の皮を教育にしただけの感が強くて……)。が、まだ現場とのギャップは大きいような気がします。
また、にもお会いすることが出来て楽しかったです。他分野の人との交流は新たな気づきが得られて良いですね。

当日、僕が三宅先生の発表へのし損ねた質問です。現場でこれを聞きたかった……。
「教員間のコミュニティの形成すばらしいと思います。膨大なデータを記録したときに、履歴が爆発するとどれを見ればいいのか分からなくなると思いますが、どのように分析すればいいか、多忙な現場の先生がぱっと見て分かるような何かアイデアはありますか？」

さて、当日取ったメモを備忘録として残します。今回は資料等が後悔されるわけではなさそうですが、漏れや誤解などもあると思いますので参考程度にしてください。

また、関連サイトのURLを下記に記します。

のサイト( ありがとうございます！ )
と開発時のメモは以下の通りです。

2010/07/16(金) 13:00-17:00
教育の未来を拓く電子化教材シンポジウム
＠東大法文2号館2F1番大教室

○小宮山氏
教わる方の視点は多様。
多様な視点に応えられないと教育は成り立たない
→構造化されて、ICTで実装された教材

2050年には人間の価値観と知とをつなぐ(知の構造化)研究を半分の研究者が行っているだろう。

社会と学術がリアルタイムでつなぐ

e.g)12人の生命科学の教授が作る、3冊の生命科学の教科書
→羊土社の理工系、生命科学系、文系進学者向け生命科学の(ICT)教科書を作成

生命科学の進歩が早すぎて専門家でもついて行けない
著名な先生でも「自分はかなり原理的なところで間違っていた」と言った。
→Wikipediaみたいな形式で構造化していくことが重要

教師用、生徒用、保護者用の知識データベースをクラウド上に置いて、進んだ個はどんどんやれるし、遅れている子は自宅でまたは進んだこと一緒にやっていくのが良いのでは。
iPadやKindleなどは、ほとんど課外活動にしか使えない
(課外授業、遠足、クラブ活動、修学旅行etc…)
50分の授業の積み重ねが大事。それに対応しないといけない。

50分授業1学期に対応したデジタル教科書をつくる
英語：8年間受けても話せないのは教育が悪い！
民間の塾、英会話教室の知恵を動員すべし。日本人がどうすれば英語がで
きるかは、外国は教えてくれない。日本人が開発しなければならない！
理科：生命科学はコンテンツ作成した
環境：日本が強い
IR3S Sustainability Science(世界で初めての機構)
芸術：日本の芸術はなくなってしまうかも！？

教員の集団としての対応力不足→社会人の大量導入とICTの高度利用

教員の不足：人数、専門的能力、「多様性」
日本の余剰資源：日本の余剰資源 60〜70歳、女性

日本はモデル転換が必要
途上国モデル(坂の上の雲：国主導で産業導入)→先進国モデル(霧の中：暮らしを良くしようとすれば、新産業が興って国が強くなる)

プラチナ社会＝21世紀の住みたいまち　を作らなければならない

Q:生命科学の教科書はどれくらい評価されているのか？
A:分かる人には分かる、評価されている。しかし、あまり見ている人がいない。
日本では56大学で採択されている。文系のための生命科学を「生命科学入門」として使っている。
既に電子教科書になっている。

○大学の知の開放　「理想の教科書」UT-eTEXT：東京大学　藤原毅夫教授

進化する教科書：Wikiをベースにしたself-editedな教科書

のべ1200〜1500人が学術俯瞰講義を受講
オムニバス講義ではなく、複数教員で1つの講義をつくる。
学術俯瞰講義サイト
UTOpenCourseWare
PodCastも配信中

・電子教科書が何故理想には遠いのか？
将来像(目的)が不明確。フレームワーク先行、コンテンツ不十分
iPadは、5年も経てばフォーマットが変わって使えなくなる

理由1：大規模IT企業先行、技術の進展のスピードが早い
理由2：電子化に伴う著作権のあり方が未整理
広い意味での教育に対して著作権は自由ではない。
著作権の考え方が各国で異なる。(e.g. Fair Use)
理由3：再利用が困難(コンテンツの陳腐化、高いソフト依存性)

1.コンテンツの使い回しを可能にするために、コンテンツとフレームワークの分離。面倒な新技術は使わない
2.著作権処理の一元管理・効率化

学術俯瞰講義のサイトは今週から完全オープンにしてある。しばらくはオープンにするが、いつか閉じてしまうかもしれない。
ビデオと講義のPPTが並んでいる。講義の書き起こしも付いている。
講義の書き起こしの文章からきちんとした説明のある所へリンクを貼れる。
話題に挙がっている本もすぐにリンクをたどるとAmazonで買える。
＃東京大学研究博物館のページへのリンクもある

UT-eTEXTのシステム概要(東大、情報技研、オーム社で共同開発)
・編集システム

苅谷剛彦、山口二郎「格差社会と教育改革」読了

Mon, 05 Jul 2010 14:59:10 -0700

社会教育学者の苅谷剛彦氏と政治学者の山口二郎氏の対談による、格差社会についての議論をまとめた本です。

本書の主張するところを簡単にまとめると、教育とは公共性を持つものであり、ある意味押しつけである。新自由主義のもと規制緩和・自由化をしていってサービス化をするのは格差を拡大する、というところだと思います。

気になったところは概ね以下の通りです。

予算はかけずに、あれもやるべきだ、これもやるべきだと盛り込むポジティブリスト方式のやり方は止めるべきである。予算とやりたいことを両輪として考えるべき。

教育の公的性質を強調し、教育のサービス化を問題視している。とくに、新自由主義的な「選択の自由」を主張する言説は都会など恵まれた環境にいる場合には良いが、田舎に生まれた場合の不利益・効果のなさは大きい。「移動コスト」はゼロではない。

教育というのは本来時間のかかるものである。それを短期間で成功する、という仮定のもと評価するのはおかしい。

見所は、

P.14 図1「国家予算と義務教育費の伸び率」における、教育費の伸び率の悪さ、

P.20図2「PISA数学学力の変化」での、フィンランドと日本の比較における低学力層の学力低下

P.25図5の都道府県の財政力と児童一人あたりの教育費の関係の変化、これは年を経る毎に財政力がある自治体が教育にお金をかけなくなっていく(＝1学級単位の人数の増加)

等のデータに基づいた議論が、議論をわかりやすく導いてくれます。

この本は、とても薄い割に議論がしっかりとしています。ちょうど安倍内閣のバウチャー制や学校選択制に対する批判が行われていた時期の話なので、今の時期に読むと少し感覚が違うかもしれません。新自由主義は国民は望んでいない、予算と人と教育理念を共に展開していくべき、という主張はすっきりしていてわかりやすいと思います。特に都会の感覚で自由化を進めていくことに対する問題提起は重要でしょう。
苅谷氏の本を読み始めるのには最適かなと思います。

福田誠治著「フィンランドは教師の育て方がすごい」読了

Tue, 29 Jun 2010 14:59:04 -0700

フィンランド教育を日本に紹介している福田誠治氏の著書です。フィンランドの教育が現状の形になった理由を、教員養成課程を中心に分析。著者は一貫して構成主義的な教育が重要と主張しています。

フィンランドの教員養成課程としては主に、下記の様な特徴が記述されています。

教師が、医師や弁護士並にの専門職扱いなので、尊敬されまたやりがいも感じている。(大学に入る段階で選別されているので、皆教師になれる)
実習期間・回数が多く、理論と実践を両輪で進めていく大勢になっている。
実習も複数人でサポートしながら行う。授業後は綿密な反省会を行う

その他のフィンランド教育の特色としては、このようなことが書かれていました。

そもそも教師は、授業のことしかほとんどやらない。カウンセラー等と役割分担がはっきりしている
国の根幹として個人中心で教育することに素養があった
テストの点数で管理するのではなく、目標の達成度で子どもの進度を把握フィンランド教育の問題点としては以下のことが記述されています。
学校で部活などの時間がなくいじめなどが起こってもはけ口が少なく、子どもたちも学校があまり好きではない
整った学習環境のため、出来ないことは自分自身が努力しないせいとなってしまう。
移民がドロップアウトする率が高い

新自由主義の規制緩和の流れと、国としての教育観が個人主義的・現場への裁量を多く与えることによる機会均等への努力がうまく交わって、現状の形に行き着いたと考えられる、というのが著者の言いたいことなのかなと思いました。このことからも単純に日本に適用するのは難しいかな、という印象です。ほぼ公教育のみで、教師は医者や弁護士並にに尊敬されており、その質を保証するだけの狭き道です。それが維持できるのも、人口が日本より少ないかの国ならではではないでしょうか。538万人と1億2700万人の差は大きいでしょう。

ただ、日本としても参考にするべきと思った点が、ヨーロッパは国民教育から市民教育へと移行している、ということです。従来は国民としてのまとまりを作るための知識を教えていくという姿勢だったのに対し、これからは大学での単位互換だけでなく、EU内での移住を前提としたヨーロッパ市民としての素養を教育していくということだそうです。グローバル化によって、教育というものが一国の話だけではなくなってきたのです。この点は、現状のICT教育の議論を見ていて気になっていた疑問に対して一つの観点だなと思います。

公教育の再生が望まれる中で、現状の点数至上主義ではない教育とは何か？という問いに対する一つの解が、PISAで言われている読解力や21世紀型スキルなのだと思います。グローバルな学びを得ていくためには自ら問題点を見つけ解決していく構成主義的なアプローチを身につけていくことが重要となるのでしょう。個人的には、企業が求める人材を育てるというのは教育において一つの要求なだけであって、それが全てではないと思います。ともすると、大学入試に最適化しがちだった教育が、企業の求める人材像に最適化するのは本質的な取り組みではないように思います。

とりとめもなく書いてしまいましたが、フィンランドの教育実習の模様と、この本の最後に付けられている フィンランドの学習指導要領は必見 です。学習指導要領は大まかなガイドラインでしかない、という書き方が本書の中にも何度も指摘されていましたが、これを読んで現場の先生は地域にあった教育を展開していかなければならないのか、そう思いました。相当に頭を使わないといけないようです。一部、フィンランド教育を礼賛したり、自説に引き寄せような気がする点もありますが、学習指導要領と教育実習の様子だけでも読む価値はあるかと思います。

Canon iVIS HF M31がやってきた。フルHD楽しい

Sat, 26 Jun 2010 14:58:59 -0700

【追記】撮影した映像をに投稿しました。

5/22まで5000円キャッシュバックキャンペーンと言うことで、買ってしまいました。

近所のビックカメラの方が安い説とか、注文したところが2chで評判悪いところだったとか、後から発覚した様々なネガティブ要因がありました。しかし、無事に届いて触っていたらひゃっほいと楽しくなるばかりです。

併せて後から買ったものとしては、

を買いました。

保護フィルムはタッチパネルの汚れよけとしてですが、ちょうどというか少し足りないかもくらいな感じです。縁まで覆いたい人には向いていないかもしれません。僕にはちょうどでしたが。
miniHDMI-HDMIケーブルは対応モニタがある人は必須ですね。実家とかでパッと見せるのにフルHDの動画をささっと見せられるのは魅力です。
ケースに関しては、割とぴったりという印象です。予備バッテリを買ったら入るかどうかが心配なサイズです。逆に言えばコンパクトでぴったりとも言えます。

まだ買っていないもので、いずれ買おうと思っているのが、SDHCカード 32GB。よく分からないけど、Class6以上が良さそうな感じなのでしょうか。かなぁと思っていますが、なかなか今時の事情が分からないんですよね。
予備バッテリは純正品は高くて手が出ないので、互換バッテリで行こうと思います。で、、のどちらにしようか悩んでいます。前者が実働どれくらいなのかで変わってくるんですよねぇ。

ちなみに、画質は素人ですが満足。手ぶれもしっかり脇を締めていれば気にならない程度。録画したAVCHDのデータもYouTubeに簡単にフルHDで投稿できて、思いの外あっけない印象です。色々調べてみたんですが、結局.mtsファイルをYouTubeでアップロードすれば、後はよしなにしてもらえます。付属のツールも編集しないのならあんまりお世話にならなくてすむかも、という感じです。今は、YouTubeって知人だけにURLを公開する限定公開ができるので、(URLがばれなければ)実家の家族とかにも簡単に見てもらえて便利ですね。これから楽しみだー

「学校教育の情報化に関する懇談会」第6回のメモ #johokon

Tue, 22 Jun 2010 04:06:47 -0700

本日6/22に開催されたの聞きながら書いたメモです。きっとそのうちに動画が上がると思いますので、きちんとしたものはそちらを参照ください。
それまでのつなぎとしての個人的なメモです。間違いや聞き漏らしもあるかもしれないので、ご了承ください。

議論の流れで主要と思ったものは、
・従来の目標が明確で比較的普及の進んだハードウェアだけでなく、ソフトウェア、特にコンテンツ共有の仕組みを国主導で普及を進めていくべきだ。(50インチテレビだけあって、コンテンツがないという事例の紹介)
・ICT支援員によるサポートの充実を。そのためには、司書教諭がメディア教諭という形で情報処理教育の中心となり安定雇用化を。
・21世紀型の教育へとシフトしていくにあたり、教員養成課程の改革だけでなく、現職の教員の研修などの仕組みを作っていくべきだ。そのためには、校内研修と教育センターの活用が重要である。

特に、授業でのICT活用法の話、ICT支援員の話と、21世紀型の教育に関わる人材育成の議論が行われました。

なお、次回第7回は7/7(水)15：00〜事務局のビジョンの骨子の提案

についてだそうです。

以下、詳細です。

学校教育の情報化に関する懇談会第5回のメモ

Tue, 15 Jun 2010 14:58:48 -0700

文科省が主催する、の。
この懇談会は、世界的なICT化の流れに対して学校教育へどう適用すべきか、情報化時代の教育はどうあるべきか、ということについて議論されているものです。

特筆すべきは、熟議カケアイという文科省が運営する掲示板サイトで、一般の人(保護者、研究者、教員など多岐にわたる)が議論を行っていることですが、(学校教育のICT化については「」で議論されていました。現在は書き込みできません。)また、を始めとする議論の動画が公開されています。時代の流れを生かした画期的な試みと言えます。
更に画期的なのが、このカケアイで議論された内容というのを委員の方々がチェックしていて、議論のネタにする。そして、文科省の方々がまとめて懇談会の場で配布し、意見として吸い上げようという姿勢が感じられる点です。もちろん、これが最終的のどれだけ残るか/減衰するかは見守っていかなければなりません。

第5回で個人的に興味深い意見としては、横浜国立大の野中氏による「持続可能なシステム構築のため、どういう学校でも使える、長期にわたっても効果のあることを実証すべき。目標や成果も学校ごとでバラバラなときにどう評価するか評価方法の検討を」というものがありました。
教育の評価は社会への貢献などで図ろうとすると十年単位でしか効果が見られないのが辛いところです。かといって、単純な試験の点数に最適化するのはもってのほかと思います。そうした中で、いかに多様な価値観で教育を行っていき、それを評価するのか、これが重要になってくるでしょう。裏返せば、「学校で学ぶべきことはなんなのか？」ということを考えていくことに他ならないと思います。懇談会を聞いていると、しばしば、学習者中心主義的な考え方がこれからの教育に重要となってくる、というような印象を受けます。

教育に関しては素人なのですが、どのような教育が望ましいのか考え続けていきたいと思います。また、是非ともお忙しい現場の小中高の先生にも、こういう議論があるんだということが伝われば、と思います。きっとベストプラクティスだけでなく、現場の様々な声、感覚がこれからの教育をよりよくする糧となると思います。PISA型の学力やなど、今の教育の現場とはもしかしたら直接は繋がらないかも知れない、けれどもパラダイムシフトが起こりうる考え方をチェックしていくことが重要なのかも知れないと思います。

以下に個人的ではありますが、議論を見ながら取ったメモを残しておきます。詳細は動画をご覧ください。

第5回で主に議論された点は、

子供たちにすべき「情報教育」はどのようなもので、どうすべきか
校務のICT化について
予算の枠組みについてということが中心に議論された。

1つめの情報教育に関してまとめると、以下の3つの観点がある。
１）使い方を教えるコンピュータリテラシ教育
２）アルゴリズムやOSの仕組みなど情報の技術の中身についての教育
３）情報を処理(収集、選択、発表)するための教育
現状の特に高校の情報科の教育では１）に終始してしまっているが、今後は21世
紀型スキルを含めて３）について教育を行っていくべきだとの意見が多く見られ
た。３）の実現方法については、まずは小中学校にも情報科の教科を設けて１）
と共に小学校から一貫して教えていくべきだ、という意見と、国語や数学、社会
など現在ある教科に組み入れるべき、そのために教員養成課程から変えていくべ
きだという意見が対立した。

また、校務のICT化に関しては2点NIIの新井氏から知見の発表があった。
・教育委員会の専用回線(24Mbps)を各校が分配して利用するため、一つの学校がネットを一斉に利用すると他の学校が使えないなど、インターネットコンテンツがまともに利用できない。
・教育クラウドでの校務支援に際し、成績票などの帳票の様式の違うため全ての統一化は困難。クラウドとローカルで行うことを切り分け、クラウド側はオープンな形式にして持続可能なシステムにすべき。

予算については、国主導で推進していかないと全国的に進まないという点についての意見が相次いだ。

学校現場の負担軽減プロジェクトチーム（中間まとめ）についてのメモ

Wed, 12 May 2010 14:58:43 -0700

何が教育現場の問題なのかを調べたいと思ったら、この資料にたどり着きました。ざっくりとしたメモです。情報薄いです。

学校現場の教員の負担についての調査。

行政による調査文書
調査研究(モデル校)事業
生徒指導
会議
授業準備・成績処理が教員の業務負担の原因で、改善方法としては、
業務の組織化
情報の共有化が重要としている。

教科書の国際比較された報告書についてのメモ

Wed, 12 May 2010 14:58:37 -0700

という国立教育政策研究所の報告書を読んだメモです。2009年3月の報告書です。
デジタル教科書やら教育の情報化に関連して調べた際の個人的なメモなので、細かいところはオリジナルの報告書を参照してください。まちがっとるやんけ、とかありましたらご指摘ください。特に入試周りは胡散臭いです。
#というか、途中で力尽きた感があります。。。

この報告書は、日本、アメリカ、カナダ、イギリス、フランス、ドイツ、フィン
ランド、韓国、中国、台湾の理科、数学の国際比較を行ったものである。前半
は、各国の教科書・教育制度についてのまとめ、後半が2教科の教科書の内容比
較である。

○教科書の方向性の違い

教科書の使用状況

大まかに欧米とアジアで異なるのは、大学入試に向けた勉強が重視されるか否か
という点である。
日韓中台は、教科書の使用が義務づけられており、教科書も国定ないしは検定教
科書で採択権限は学校以上のレベルである。一方、欧米は(国によって異なる
が)、教科書使用の義務は無く、教師が選べる場合も多い(英仏芬)。特に、フランスは教科書を通しで使う先生が25％というデータが(少し古いようだが)ある。

- 義務の国

・日本、韓国、中国、台湾

- 義務が無い国の使用状況

・教科書中心：アメリカ、イギリス、フィンランド
・教科書は教材の一つ：カナダ
・自由：フランス、ドイツ

教科書の持ち帰り

欧米の多くでは、無償貸与なため持ち帰りはしないことが多い。場合によっては
初めから家に置くことも。
持ち帰りする国は、日本、フィンランド、中国。韓国、台湾も無償給与もしくは
有償なので持ち帰りはできるかもしれない。イギリスも、Sixth formは持ち帰る。

教科書と情報化

アメリカは教科書の部分部分にパスコードがあり、教科書会社のサイトで関連情報などを調べられるようだ。自宅学習をWebで行うことも多いため、教科書の選定基準の一つに、Webを利用した学習の利用料の値段がなってくるとのこと。イギリスではWebの情報を授業に活用している。また、韓国は国が開発した教材データベースが活用されている。数学はコンピュータによる作図や定理の検証などを行われているようだ。

○大学入試の違い

入学試験無し

・高校卒業試験のみ(ドイツ)
・筆記試験無し(カナダ)

入学試験はあるが教科書と関係が弱い

・論述試験のみ(フランス)
・教科書と直接対応なし(アメリカ)
・教科書が十分カバー(フィンランド)

入学試験あり

・GCE・Aというコースと筆記試験の統一試験(大学の教養のようなもの)(イギリス)

Eric WitacreのVirtual Choirが凄い！これは日本のアマチュアでも広まるべき

Wed, 21 Apr 2010 14:58:32 -0700

さんので知りましたが、WhitacreのVirtual Choirがやばいです。何はともあれ実際の動画を見ていただけば、その凄さを体感できるはずです。

Whitacreのオリジナルの記事は。に日本語に訳してくださった記事があります。こういう映像を見ていると、生で歌うことの楽しさももちろん大きいですが、それとは別のアプローチで合唱を創る喜びがあるのかと思うとワクワクします。
以前、でも妄想していましたが、Webを通じて知り合った仲間や距離が離れてなかなか集まれない仲間同士で、「一曲歌ってみるか！」ってことが実現しやすくなったんじゃないかと思います。も出来た時代ですし。ワクワクしますねー。

「学校教育の情報化に関する懇談会」のライブ配信が行われるそうです〜情報化と教育

Tue, 20 Apr 2010 14:58:27 -0700

最近、遅ればせながら色々と教育における情報化について調べることが多いのですが、こんな懇談会が4/22(木) 16:00-行われるそうです。(配信のリンクは文科省のトップからリンクが近々張られるそうです。)

趣旨としては、

（1）授業におけるICTの活用について（デジタル教科書・教材、情報端末・デジタル機器、学校・教員等の在り方を含む）
（2）ICTを活用した校務支援について
（3）ICTの活用に関する教員へのサポート等について

つまり、デジタル教科書を始めとする授業への情報端末の活用、情報機器を活用した採点業務などの効率化、情報端末を先生が使えるようにすること、について話が為されるようです。この懇談会への流れは、どうも原口総務大臣がとして「2015年までに全ての小中学校全生徒にデジタル教科書を」という目標を掲げていることが大きいようです。( が詳しいです)
本当は、懇談会の傍聴をしたかったのですが、既に満席とのことでライブ配信の恩恵にあずかろうと思います。(しかし、この時間は現場の先生見られるのでしょうか)

デジタル教科書と言えば、ソフトバンクの孫さん始めとした方々がデジタル教科書協議会の設立目指して動いているようです( , )。また、従来の教科書会社もようです。twitterでもで盛り上がっており、今とても熱い分野だと思います。紙の教科書からデジタルの教科書へ、大きなパラダイムシフトが起こる可能性があり技術者としてとてもワクワクします。

しかし、デジタル教科書についてもビジネス的に興味深いとは思いますが、個人的には上記懇談会の2,3番目の項目が気になります。特に、3についてかなり重要になってくるのではないかと思っています。

こちらに、平成20年度の公立小中高校等のがあるのですが(詳細なPDFは )、資料を見て感じるのは 「かろうじて授業準備にWordやExcel、インターネットが使える」 という印象です。「A 教材研究・指導の準備・評価などにICTを活用する能力」、つまり授業の準備に情報機器が利用できるという項目が「わりにできる」と「ややできる」を併せて72.6％なのに対し、「B 授業中にICTを活用して指導する能力」が 56.4％ 、「C 児童のICT活用を指導する能力」が 58.5％ と途端にできる人が少なくなっています。このままでは、デジタル教科書が普及したところで従来の紙の教科書と同じ使い方しか出来ないことが危惧されます。最大化の操作を教えられ感動し、最小化の操作まではちょっと覚えられない、と言われた先生もいらっしゃるとか……。前者の72.6％もどの程度できるのかというのを、それこそ一度全国一斉に試験をしてみた方が良いのかもしれません。

また、少し話がそれますが、「D 情報モラルなどを指導する能力」は4つ項目があり平均すると66.8％なのですが、よくよくみてみると、D1〜3の「情報社会での行動に責任を持ち、相手のことを考えた情報のやりとりができるように指導」のような一般的に情報化社会についての技術的なことにあまり依存しない3項目の平均を取ると68.6％、それに対し「D4 児童がパスワードや自他の情報の大切さなど、情報セキュリティの基本的な知識を身につけることができるように指導する」が61.3%と落ちています。現状の情報技術や動向を大まかにでも知らず一般的な倫理道徳感だけでは、情報モラルを教えきるのは厳しいのではないかと私は不安に思います。
一方で、愛知県の ( )や、のFlashによる体験教材、による情報モラル教育のための体験ソフトウェアなど、インタラクティブに分かりやすい教材を提供しようという機運は高まっているように思います。こうした教材の情報がもっと分かりやすく提供されるような、のようなポータルサイトやtwitterのアカウントなどで広まってもよいのかもしれません。

将来はこうした教材の共有や校務分掌などが全部クラウドの向こう側に置かれて、先生や保護者が意識することなく教育できるようになるのかもしれない、と淡い期待と共に妄想しています。
個人的には情報モラル、ネットリテラシーについては新しい技術がどんどん出る中、保護者でのフォローしきるのは難しいとも思いますので、社会全体で支えられる枠組みが出来れば、と思います。また、技術者としてそうした枠組みを作るお手伝いができたら幸せです。

"Laula kultani: European Folk Songs for mixed voices" がうちにきた

Mon, 29 Mar 2010 14:58:21 -0700

されていたを衝動的に買ってしまいました。だって、Folk Songsって書いてあるんだもの(Pana Musicaの紹介文は。しかし、Pana Musicaはいい紹介記事を書くのに、パーマリンクがないため紹介しづらいなぁ。今時パーマリンクなし、RSSなしだとGoogle先生などに補足されづらいので辛いと思います。勿体ない。)ヨーロッパの様々な合唱団がお国のFolk Songsを歌うコンピレーションアルバムという位置づけのようです。

CDとしては素性がわからなかったので不安でしたが、なかなかどうしていいCDじゃないの。Carol of Bellsのオリジナルとなった曲(Ščedryk)がとても好きです。ウクライナ民謡だったのね。ちなみに、このYoutubeの映像は別の団体の演奏。この演奏よりもCDの方が素敵です。

Webをみたら、演奏団体が曲ごとに書いてあるところが見あたらなかったため、ジャケットから情報を拝借してきました。Webに情報が載っていた方が詳しい方が色々コメントくださるかなぁと思って書いてみます。ただし、一部フォントの関係で正しく表示されていないものもあります(cの上にvとか)。

全体的に外れの演奏が少ないいい音源だと思います。しかし、やっぱりハンガリーは和音聴けばハンガリーだってわかるなぁ。

No. Country Composer Title Choir
1 FI Finnish Traditional Laula kultani, folk song Murtosointu Chamber Choir
2 DE Friedrich Silcher Ich weiß nicht, was soll es bedeuten Südfunk Chor
3 DE Johannes Brahms Wach auf! II (“Wach auf, meins Herzens Schöne”), folk song for chorus (& piano ad lib), WoO 35/7 Junges Vokalensemble Hannover
4 DE German Traditional In einem kühlen Grunde NordDdeutscher Figural Chor
5 LU Pierre Nimax, Jr. Wéi meng Mamm, song for chorus Kammerchor Konservatorium Luxemburg
6 CH Hansreudi Willisegger Du fragsch mi, song for chorus Oberwalliser Vokalensemble
7 AT Anton Anderluh O Diandle, tiaf drunt im Tal, song for chorus in G major Wiener Kammerchor
8 IT-Germ Felix Resch In Klausn isch Kirchtig, song for chorus Kammerchor “Leonhard Lechner” Bozen
9 BE-Flem Vic Nees Gildebroeders, song for chorus Capella di Voce
10 NL Henning Schmidt Daar was laatst, song for chorus Ensemble ECU06
11 UK English Traditional Early One Morning, folk song The Cavendish Singers
12 IE Irish Traditional The Star of the County Down, folk song Madrigal 75
13 IS Jón Asgeirsson Vísur Vatnsenda-Rósu, song for chorus The Hamrahlíð Choir
14 NO Norwegian Traditional Poul sine høns i haven lod flyve (Paul and His Hens), folk song Bergen Domkantori
15 DK Danish Traditional Jeg gik mig ud en sommerdag (I went out on a summer’s day), folk song Tritonus
16 SE David Wikander Kristallen den fina (The Fine Crystal), song Örebro Chamber choir Sweden
17 UA Mykola Dmytrovich Leontovych Ščedryk, song for chorus National Music Academy Kiev
18 PL Jozef Swider Góralu czy ci nie zal, song for chorus Absolwent aus Cieszyn
19 CZ Czech Traditional Okolo Hradisca, folk song luventus paedagogica Praha/Besharmonie Praha
20 SK Czech Traditional Janicko, zltovlas (Golden-Haired Johnny), folk song OZVENA Vranov n.T.
21 SI Oskar Dev Ribce po murjici pvavajo, song for chorus in G major Slovenia Chamber Choir AVE
22 HR Croatian Traditional Vehni, vehni fijolica, folk song Academic Choir Ivan Goran Kovačić
23 CS Croatian Traditional S’one strane Dunava, folk song Trinity Church Choir Zemun, Beograd
24 BG Fillip Koutev Polegnala e Toudora (Todora’s Dream) St. St. Cyril and Methodius’ Chamber Choir
25 MK Macedonian Traditional Ajde, slusaj, Angjo, folk song Slovenia Chamber Choir Megaron
26 IT-Germ Paolo Bon Lu guarracino, song for chorus Coro Vox Cordis, Arezzo
27 CH-Ital Hansreudi Willisegger Scià, scià Peppina, song for chorus Scheweizer Jugendchor
28 ES Spanish Traditional El vito Grupo Vocal Alisios
29 ES Spanish Traditional La Tarara Grupo Vocal Alisios
30 LV Latvian Traditional Rïga dimd, folk song Ave Sol
31 AL Fahri Beqiri Shkoj e vij flutrim, song for chorus Kosova Philharmony Choir
32 GR Greek Traditional Syrtos Rhodou, folk song Corfu Municipality Choir
33 CY Greek Traditional Psintri Vasilitzia mou, folk song (Cyprus) POLYFONIA Chamber Choir Cyprus
34 AM Komitas Sew a cobani sowne, song for chorus Armenian Chamber Choir
35 EE Estonian Traditional Kungla rahvas, folk song Mixed choir “Noorus” ( produced by Estonian Radio,2006)
36 HU Hungarian Traditional A jó lovas katonának, folk song Budapesti Monteverdi Kórus
37 ES-Basq Javier Busto Agur juanak, song for chorus Coro Hodeiertz Abesbatza

ちなみに、各地方の略称はを参考にされると良いかと思います。いや、途中まで日本語にしようかと思っていたのですが、流石に地方が散見されると僕の実力では無理と判断しました。。。すみませぬ。

世界変革の時〜ラヴォスのたった一つの買い方

Mon, 22 Mar 2010 14:58:16 -0700

初めてが現れたときの絶望感と言ったら……。想像を絶するものがありました。出自の分からない異形の者を倒し、そして更なる戦いへと挑むその姿を見ていったら、剣と魔法の世界からはおよそ想像の付かないものとの戦いに。いやぁ、本当に名作でした。クロノトリガー。

そんなラヴォスがお手軽に購入できるようになったので、買ってきました。

たいとるはもちろん釣りです。ごめんなさい。
ちなみに、ラヴォスはというケーキ屋さんで、「レモンタルトください」と言えば、買えます。少し黄色いですが、きっと亜種か変色しているだけに違いありません。倒すのには強靱な歯もいりませんので、ご安心してお買い求めください。

ちなみに、先日のお祝いでキャンドルを使ってお茶とケーキをしました。そのときにラヴォスが現れたのです。もちろん、妻との協力でなんとか倒すことが出来ました。

ちなみに、日本にこだわらずイタリアに行けば、を買えます。クロノファンの方は是非！

アカペラのイベント情報とかをつぶやく@acappella_eventの使い方

Sun, 21 Feb 2010 13:58:11 -0800

でも少し書いていたんですが、twitterでというbotを作りました。前から少しずつ色々試していたのですが、ようやく基本的なところができたので使い方を簡単にまとめたものを残しておきます。

@ は
1)合唱/アカペラについて検索して投稿
2)@を飛ばされるとそれをリツイート
3) のアカペラ/合唱カレンダーから当日のイベント情報を投稿(する予定)
の3つをするbotです。

より抜粋。

もう少し詳しく説明すると、

1)は、twitter検索した情報をつぶやきます。「アカペラ or 合唱」と「情報 or 告知 or 開催 or 募」あたりのクエリを使ってます。なので、変な情報も拾ってきますし、漏れもありますがこの辺はまぁ今くらいでいいかなと思っています。
(20100829追記：公式リツイートで検索した情報をつぶやくように修正しました参考： firegoby)
2)は、「@acappella_event ○○」とつぶやくと、その発言自体を公式RTします。まだまだfollowerが少ないのですが、広めたい情報や告知したい情報は@で飛ばしていただければ5分程度でRTされるはずです。なお、つぶやきの頭に@acappella_eventと書かないとRTされないのでご注意ください。
3)は、試験運転状態なので上手くいっているか少し不安ですが、細々と更新していますから以下の3種の情報をつぶやきます(願望)。

当日の予定を朝6時につぶやきます。
翌日の予定も午後11時くらいにつぶやきます。
新規登録されたイベントもつぶやきます。今のところ3.の新規イベントは安定しているのですが、1,2が様子見な形で怪しいですTwitterの調子がよければ動いています(20100711追記)。

以上が@acappella_eventの機能です。どちらかというと、他力本願なbotなので色々な人に活用していただければ盛り上がって嬉しいなぁと思っています。特に、の編集に協力してくださる方大募集中です。ダイレクトメッセージなどでgmailのアドレスをお教えいただければ、登録いたします。ではなんか面倒くさそうな感じがしたので、GAEの練習がてらbotを作ってみた感じです。そんなにたいしたことはしていないのですが、備忘録がてらそのうち参考にしたサイトなどをまとめたいと思います。

練馬アカペラコンテストに行ってきた

Sun, 07 Feb 2010 04:02:01 -0800

2/6に開催されたに行ってきました。

初めてアマチュアのアカペラのライブ的なもを聞いてみたのですが、とても楽しかったです。教えてくださったとてもには感謝です。また、さんやさんにお会いできたので良かったです。@toriuzuraさんお疲れ様でした！！素直な声が良かったです。

参加された団体名と分かる範囲での曲目は以下の通りです。(敬称略、曲名は漏れや間違いあるかもしれません。ご容赦ください。曲名のメモをしてくれた妻に感謝！)

○MERRELL
・Rain drops keep falling on my head (TRY-TONE)
・September

○Wiz (準グランプリ)
・White Christmas (TRY-TONE)
・The Christmas Song (Vox One)
・You raise me up (TRY-TONE)

○ピノキオ(グランプリ)
・童謡メドレー「この道-赤とんぼ-もみじ-雪」
・How high the moon
・Spain

○Siestα
・Moon River
・(曲名わかりませんでした……)
・未来予想図II

○あぽろーぐ
・(Smooth Aceの曲?)
・逢いたいね(Smooth Ace)
・無敵(Smooth Ace)

○ASTERISK
・Poison Tree ( Rajaton )
・The Wishing tree (The King’s Singers)
・Butterfly ( Rajaton )

○むらさきのうえ♪
・南風(レミオロメン)
・奏(スキマスイッチ)
・Distance(オリジナル)

○aquamirage
・Scarborough Fair(オリジナルアレンジ)
・Middle of the River
・The Voice(Celtic Woman)

○Potion(審査員特別賞)
・Prayer For Peace(The Idea of North)
・Fly me to the moon
・(曲名わかりませんでした……)

バラエティに富んだ曲やアレンジを楽しむことが出来ました。圧倒的なステージ作りやノリノリの曲、和音で攻める感じなどなど。特に、皆さん難しい和音やリズムの曲にバリバリ取り組んでらっしゃる姿が印象的でした。今までの自分の経験してきた歌と、アカペラな方々の取り組んでいるものとの違いみたいなところが少し分かった気がします。発声方法や求められている方向性が少し違うのかなぁと思いました。割とJazzよりな和音でぶつけることが多いためか、マイクにのせたときに映えるからか、直線的な声だなぁ、と。特に、優勝したピノキオ(東大のOBバンド？らしいです)が、優勝記念でもう一曲歌ったThe Real Groupのを聞いてそれを強く実感しました。リードのお二人はガンガンぶつけていくという感じが自分にはまねできない感じがしました。(個人的に、これを聞いて自分でThe Real Groupを歌うのは無理かもなぁと思ってしまいました)ちなみに、ピノキオのベースの人はThe Real Groupの変態(ほめ言葉)Anders J.の、超絶低い＆難しいリズムをオリジナルよりもアップテンポで難なくこなされいたので卒倒しそうになりました。彼みたいなベースになるのは楽器の違いなので厳しいですが、一緒に歌える機会があったら幸せだろうなぁと。そして、ピノキオのテノールの人はご自分でアレンジをされているようで、4声へのアレンジも全く問題なく聞けました。また、本戦で歌われていた曲もアレンジが面白かったです。
ただ、全体的に気になったのは和音の難しい曲にいつもチャレンジしているためか、和音がはまる感覚があまり体に染みついてないのかなぁという感じのするところが結構多かった気がします。特に、複雑な和音をぬけて太純な3和音になったときにも崩れたままというのが、なんだかなーという風に思いました。音の勢いはあっても一体感がない感じですね。アーティキュレーションを付けて歌うところが印象に残るというのはよく分かりますが、もっとハーモニーを感じることが出来たら幸せだなぁと思いました。

個人的には、がRajatonにチャレンジしていたのには大きな拍手を送りたいです！(いや、実際にも送っていたのですが)。後ろに座っていた(推定Time Five目当ての)おばさまの「コンサートじゃないんだから」とか「あー、ラテン語の宗教曲歌ってた所ね」(ラテン語なんて歌ってませんでしたよ、英語ですよ)等という声にも負けず応援していました。選曲センスが素敵すぎ！Rajaton大好きな自分でも、まさか日本でRajatonの曲が聴けるとは思っていませんでした。感謝感激。しかも、難しい曲だったんですが、ちゃんと聞けるレベルまで持ってきていたのが素晴らしかったです。もちろん欲を言えば色々言いたいことはありますが(Butterflyは2番以降全パートフォルテになってしまったのは残念！パートごとのメリハリがないとわかりにくい曲になってしまいます……)、アマチュアでこんな水準で演奏できているのはかなり頑張っていると思います。ちなみに、アメリカにはこんなもいます(笑)

結局なんだかんだで、生の声を重ねることをベースに教会で歌うような宗教曲からポップな曲まで幅広く歌える、Rajatonみたいな歌い手になりたいなーという思いが強まりました。

追記：全部俺なRajaton Boyな彼はですが、していました。しかも今度は720pのHD画質で(笑)

合唱とアカペラのカレンダーをGoogle Calendarで作ってみた

Tue, 19 Jan 2010 13:58:00 -0800

自分のために作ってみたものですが、にありますので良ければ使ってみてください。手で見つけたものを少しずつ書いているものなので、色々と漏れがあります。ありまくりだと思います。また、自分が合唱の方が敏感なので、アカペラのイベントは全然拾えてません。もし、よろしければ情報をお待ちしております。まで@飛ばしていただくか、このblogにコメントでもOKです。
また、書き込んでくださる方も随時募集中です。基本自分のためのカレンダーではありますが、情報を集められたらいいなーと思っています。

今後の実現できたら嬉しい機能を妄想してみると、

twitterから@でカレンダーに登録
その日のイベントを呟くbot
ぴあやe-plusから情報を収集してきて(半自動で)登録 1つめに近いことは、を使えばダイレクトメッセージでQuick addができます。ただ、複数人での登録が出来るかどうかはイマイチわかっていませんので、検証の余地があります。もしくは、自分でcronで回すとかかな。2つめは、の情報を参考にすればできるやもしれません。3つめについては、e-plusはRSSを吐いているみたいなのですが、ぴあはイマイチよく分かりません。ただ、奴らの情報力はやはり大きいと思います。今度来日するスウェーデン放送合唱団も、先日のカペラのチケットを検索していたらひょっこり検索にひっかかったのです。
自動で出来ると嬉しいことたちです。

フェラーラのジョスカン〜ヴォーカルアンサンブルカペラ定期公演

Thu, 14 Jan 2010 13:57:54 -0800

の演奏会に初めて行ってきました。
曲目は、以下の通りです。

ジョスカン・デ・プレ　ミサ《フェラーラ公エルコレ》
Josquin des Prez (ca.1450/55-1521), Missa Hercules dux Ferrariae
ジョスカン・デ・プレ「神よわたしを憐れんでください」（詩編51編）
Josquin des Prez, “Miserere mei Deus” (Psalmus 50)
グレゴリオ聖歌　ミサ固有唱 Gregorian chant, Proprium missae

ルネッサンスは専門外なのですが、非常に楽しめました。目黒の聖アンセルモ・カトリック目黒教会にて演奏を聴いてきました。天井の高い教会で、久しぶりに倍音がわんわんと鳴っているのを体感しました。また、演奏前に曲目の丁寧な解説がついていたため、本来楽譜を持っていないとわからないような曲の構成に対しても気づくことができ、一層楽しめました。Hercules dux Ferrariaeという文字列が、“レドレドレファミレ"という音型になるということは歌付きの解説があって初めてわかったものでした。

ちなみに、この楽譜たちは本番で皆さんがみていた楽譜たちです。人の胴体ぐらいの大きさがありました。

12月に読んだ本

Fri, 01 Jan 2010 01:01:57 -0800

読書メータにこんな機能あったのね。しかも画像付き。便利だわー。ちょっと貼り付けてみる。というか、あまり本読んでなかったのねぇ。twitterに時間を奪われていたのかな。

12月の読書メーター
読んだ本の数：5冊
読んだページ数：1254ページ

感動の、というよりは、納得の最終回。最初ラストを理解するのに少し時間がかかったが、切ないというかむなしいというか。おまけ漫画を読むと生き返る。また、1巻から一気に読み直すと感覚が違うんだろう。
読了日：12月31日著者：

非常に興味深い一冊。特に、各会社の社長が様々な立場からゲーム会社の社長となり、それぞれの考え方をもっているのが如実になっているのが良く伝わってきた。ただ、これを読んで国内のゲーム会社にいようかと思うと、任天堂以外海外にあまり向いていないんじゃ、と思ってしまい悩ましくなる。
読了日：12月31日著者：

論理構成がハッキリしていて、読みやすい。twitterの今までが簡潔にまとめてある。今まで使っていた人にも、これから始める人にも、良く使い方が分からない人にもお勧めの良い本です。
読了日：12月30日著者：

興味深い情報もいくつか見受けられるが、酷く読みにくい。何も分かっていない人が何も分かって無いなりに、中身があるんだかないないんだかわからないことを書いてる。色々取材した、ということだけが価値のある一冊。
読了日：12月23日著者：

うーん、いまいちグダグダな終わり方。きっとスピンオフがでるに違いない。のだめと千秋の関係に興味ある人は楽しいのかなぁ。
読了日：12月01日著者：

今更ながら2009年で読まれた記事

Fri, 01 Jan 2010 01:01:07 -0800

あけましておめでとうございます。今年もよろしくお願いします。

さて、Wordpressに移行して早数ヶ月ですが、統計情報が簡単にアクセスできるのが大変便利で気に入っております。そんななかで、去年一年(もやってないか)で一番読まれた記事は、
でした。ここら辺、皆さん苦労してるんでしょうねぇ。うちは結局Officeを買ってしまいましたが、ふりがな問題は誰かもっとスマートに解決しているのかなぁ。
が次点でした。すみません、アクセスしていただく割には結局Simplify Musicを購入していません。そこまで家でiPhoneで音楽を聴かなくなったのが主な理由でしょうか。

というわけで、段々と自分の作業ログめいたことが多くなってきていますが、今年もよろしくお願いします。

最相葉月著「絶対音感」を読了した

Wed, 23 Dec 2009 00:12:42 -0800

本の大まかな内容は、音楽に素養がない記者が、絶対音感の言葉の響きに惹かれて解明しようとした努力の軌跡である。まとめると、
・絶対音感の定義は曖昧だが、その中でもレベルがある
・相対音感教育もあわせてすべき
・後藤みどりのルポ
といったところかな。とにかく、取材した順に並べてるんじゃないかというくらい読み辛いのだが、面白いところもいくつかあった。

著者の分からないものを分からないままに、研究者や音楽家の言葉を集めて語る手法は、研究をかじったことがあるものならムズムズするに違いない。特に、○○学者や音響学会の名前を出すことで、権威付をして引用をする姿勢は記者独特というか、学術的でないために耐えるのが辛かった。そして、後藤みどりのルポの生き生きとしていること！彼女の書きたかったところはここなのだと読み解けて、逆にほっとした。

と、苦言ばかりもなんなので、この本を読んでよかった点を。
1.音楽家や研究者の言葉を豊富に集めてあること
これだけの量の文献や取材をするのは相当骨が折れたに違いない。著者の知識不足や教養不足による、切り貼りの下手さが目立っても、やはり集められた言葉自体には重みがあります。佐渡裕氏の言葉はいちいち興味深いです。

2.絶対音感教育の歴史が知れたこと
特に、戦時中の戦闘機の音の弁別のために利用されようとしていたというエピソードは、普段の音楽に触れる生活では得られないと思います。

3.絶対音感のカテゴリがぼんやり見えてきたこと
絶対音感のカテゴリとしては、音名がなんとなく分かるという人、それが左脳で言語のように理解できる人、覚えた音とピッチがずれると気になる人、そうでない人、という感じだと思います。
絶対音感教育のやり方を読むと、実は絶対音感を教えるときは和音で教えてしまうというのが驚きでした。むしろ、習わないJAZZや不協和音などからは普通と同じように分析的に聴くしかないということ。つまり、パターン認識の学習をさせてるだけだということになるのではないかと思うと、機械でも面白いことができないかなと思ってしまいます。
関屋晋の「だいたい音感」をふと思い出しまた。

音楽、音響とかの予備知識があると怪しい記述にうんざりしますが、普段なかなか読めない武満徹氏や佐渡裕氏の言葉やエピソードち触れられるという意味では楽しい本でした。ただ、著者がよく分かっていないことを、人の言葉を借りて切り貼りしてるだけなので、知ってる人はイライラ、知らない人はさっぱり分からない気もします。

粒谷区民合唱団の一つの実現方法(妄想) - #tlros を通じて思ったこと -

Thu, 17 Dec 2009 13:57:33 -0800

最近、twitterで曲を歌うことになりました。なんというか、アカペラーや合唱人との繋がりが楽しくなってきたのですが、まさかこんな展開になるとは思っていなかったので楽しさが増してきました。
TLに、三善晃や武満徹の文字が流れる日が来るとは！

で、そんなわけでさんが編曲したThe last rose of summerを歌うことになりました。( ,ハッシュタグ: ,楽譜などはまとめにあります。というか、さんには感謝!) 正直２年くらいまともに歌っていなかったので、かなりいろんないみで不安だったりするのですが、何事も挑戦と言うことで参加してみました。

粒谷区という日本語の仮想の区があるそうですが、粒谷区民合唱団はないの？というのをどなたかが呟いていたのです。(調べてみると、とは既にあった！)確かに、これはあっても面白そうだなぁと思ったのですが、オケと違って歌って結構録音しやすいんじゃないかと思うんですよね。そこで、粒谷区民合唱団の実現方法について妄想してみました。

簡単に言うとこんな特徴のソーシャルサービスの形が面白そう。

各自が自分の歌いたい曲の歌いたいパートを、どんどんUploadしていく
曲名、作曲者名などをタグで管理
twitterアカウントでログインする
自由に他の人の声に重ねていける(ライセンスはの継承(Share Alike)みたいな形？) 自分が歌った色々なパートを持ち寄って一つの楽曲を作り上げるということ。これができるとすごく面白いんじゃないかな。「誰々のにあわせましたー」というコメントとタグを付けて、パートごとに歌った音データをUpするのが良いのではないかな？現状で、未完成品をシェアして作り出せるようなサービスってあるんだろうか。なければ、作れたら楽しいだろうなぁと思います。こんなサービス知ってる人がいたら教えてください。なければ、、、つくれたら幸せ！？

もちろん、実際に集まって歌えたらもっと楽しいと思います！

ふたご座流星群は今晩から。14日AM2時がピーク

Sun, 13 Dec 2009 13:57:27 -0800

前回のしし座流星群の時には逃してしまったので、今回こそはきちんと押さえておこうと思います。 .

今回のピークは、１4日の午前２時だそうです。今晩はうちのあたりは曇りなので、明日の夜にチャレンジしようと思います。この時期なので、あたたかい恰好をして臨みたいと思います。
「あたたかい」といえば今日会ったアメリカからの留学生が、「あたたかい」という言葉の発音が難しいと言っていました。日本語は全部に母音を入れるのが大変なんだ、ということみたいです。類似品で「肩たたき」も難しいんだとか。早口言葉は難しいのかも。

After Devil Forceを発掘した

Sat, 05 Dec 2009 13:57:22 -0800

昔々、Compileというゲーム会社があったのだが（中略）、実家に帰ったら晩年の作品であるAfterDevilForceを発見してしまいました。当時、中学生だった自分には、最終面だけはクリアできなくて諦めた記憶があります。

どういう話の筋かというと、小国クォーダが傭兵で外貨を稼いで国の生計を立てていたのですが、それら傭兵を率いる王が急死し、急遽攻めてきた同盟軍でもある大国ラウルを退けるという話です。基本的に、奇襲や撤退戦など力押しでなんともならないので、頭を使って戦わなければならないというのが珍しいと思ってプレイしていました。SRPGって終盤に行けば行くほど味方がもりもり強くなっていって、ボスだけ急激に強くなると言う印象があったのですが、最初から最後まで敵軍有利な状況しかなく、何ユニット以上撃破して退却させるという渋いクリア条件が楽しいところでした。１０年前のゲームですが、良くできた作品です。

で、久しぶりにXPで起動してみて音が大分違うなぁとか（SoundBlasterを狙って作られたMIDIなので音色が違う）、ぶつぶつ言いながらプレイしていたのですが、やはり最後の７面は無理ゲーだったので、ニコニコ動画で参考までにプレイ動画を見てみました。そしたら、ある意味チェスのようにかなり頭を使ってクリアされていたわけです。

なんというか、ぬるゲーマーの自分としては最後は力押しというか、ゲームに頭を使ったら負けだと思っているので（ぇ、プレイ動画を見て満足してしまいました。

ちなみに、色々と攻略記事を探していたら、を見つけて喜んでおりました。なんでも、とか。もあるのですが、もうこれが世に出ないかと思うと惜しいの一言です。権利問題とかガチガチなんだろうなぁ。続編前提のシナリオだっただけに、残念です。

お安くお手軽アカペラ多重録音のための機材

Thu, 26 Nov 2009 13:57:16 -0800

本格的に始めよう、というわけではなく、とりあえずアカペラで多重録音を始めてみようと思ったため、機材を簡単にそろえてみました。

PCで録音をすることが前提（Webでデータをやりとりして重ねることが想定された）なので、購入したのは

マイク
オーディオインターフェース（IF）
マイクケーブル
マイクスタンドの4点です。基本的に値段重視です。うっかり挫折しても投資を後悔しないように。質が良いかはあけてみてのお楽しみ。

マイクは、にしました。値段の割にはいい音だそうです。音の癖はS58に比べると多少あるかもです。マイクケーブルは、。500円と安価ですがそこそこ良いみたい。スタンドも。こちらもお買い得なのです。
オーディオインターフェースは安さ重視ということで、昔だったらEdirolのUA-25とかだったのですが既に生産停止しているようで。結局、にしました。7000円弱で手に入るならいいかなと。

しめて、12000円程度で導入できました。週末には届くので今から楽しみです。
それまで、厳しい特訓が待っているみたいですが……。ルネサンスは厳しいよー

The Real Album

Thu, 26 Nov 2009 13:57:09 -0800

Pass Me the Jazzがすてきなアルバムです！

Bumboo Beeもすてき。

新体制になって日本では初めてのアルバムなのですが、全体的な印象としてはポップな感じです。Emmaはこれからの活躍に期待という意味で、楽しみにしています。まだまだ若々しいかなぁという印象です。他のメンバーの変態っぷりは健在です。クラシカルではないポップな彼らが好きな人は、手に入れたい一枚だと思います。

JBL reference 410を修理に出すことに決めた

Wed, 18 Nov 2009 02:11:03 -0800

いつからか、片方の音が出なくなったうちのJBL reference 410だったのですが、ふらっと調べてみたら意外と修理にお金がかからなさそうというのが分かったので、修理に出すことにしました。（ちなみに、多分に巻き付けてたから悪くなっちゃったのかも、と思っています。。。）

お値段は、

・プラグのみの交換の場合\3675(技術料込み）
・それ以外の場合は\7000

と思ったより高くないことが分かりました。もちろん、自分で修理する人もいるとは思うんですけど、今回ちょっと断線っぽくないので諦めて修理にしようかなと。一時期e-bayでは$45くらいでいっぱい出品されていたんですが、今では生産完了品だからかほとんど出回らなくなりました。お値段の割に上品な音使いが気に入っている品なので、大事にしたいです。

参考URL:

iPhoneケースを買い換えた

Sat, 14 Nov 2009 04:11:21 -0800

もともと、を使っていたのですが、先日開けようと思ったら接続部の薄いところが折れているのに気付いて買い換えました。6月に買ってわずか5ヶ月の命でした。iPhone本体は傷など付いておらず、気に入っていただけに残念です。

で、そんな折にを見て良い機会だから買い換えました。

ちょっとはめて使ってみた感想ですが、

クリスタルジャケットに比べて表面に段差がないので、本来のiPhoneってこんな感じなんだーと新鮮です。ポケットに入れた感じは以前より分厚くなったので、もう一台の携帯と一緒には入らないのかなぁ、と思います。最大のポイントであるカードを入れて似非おサイフケータイ化作戦は、懸案事項が出来たため保留中です。

ビックViewスイカを入れるのはちとリスキー
が入らない基本的に、モバイルSuicaの代わりに使えるのがベストなので、家でのSuicaチャージが必要となってくるわけです。ですが、現状持っているチャージ対応SuicaがビックViewスイカだけなので、携帯ごとなくすとショックが大きいかなぁと思っています。記名式のSuicaでも入手すれば、安心して使えるなぁと。

バスカードについては、基本的に頻繁に使うのでこれとSuicaを同時に刺したいと思っていたのですが、残念ながら少し磁気カードの方が大きいので入らなかったです。上を少し切ってしまえば良いのかなぁとか考えたけど、そうすると通らなくなったりするのが怖いですしね。。。一枚だけなら曲げつついれれましたが、奥までいれると引っかかって出てこなくなってしまいました。

カードのホルダー感はばっちりで、一枚でも落ちそうにありません。これから有効活用していきたいと思います。

無線コントローラ

Sat, 14 Nov 2009 01:11:32 -0800

そういえば、を買った。っていってもけっこう前ですが。思ったような遅延は感じられない。そんなにシビアなゲームはやってないからか。
ただ、最近プレイするのがCoD4だから、全く意味ないという‥ はWindows版は12/23と遅いのが残念すぎる。待てないので、もう少し今のバージョンで練習しよう。

Nas Navigator2をWindows7(64bit)で動かす方法

Wed, 11 Nov 2009 04:11:25 -0800

ですが、なんとか動かすことに成功しました。グラフィックボードのドライバ関係もあって、再インストールした後に行いました。

1．管理者権限で、setupを実行する
2.nassvc.exeを管理者権限で実行できるようスタートアップにショートカットを置く

つまり、nassvc.exeがNASの自動実行のためのパケットを出し続けているようです。ただ、管理者でないユーザでの実行は確認していないです。

Buffaloはちと最近厳しいのかなぁ。

RAJATON BEST of 1999-2009がうちにきた

Tue, 10 Nov 2009 13:56:43 -0800

いつの間にか、Finlandのアカペラグループのベストアルバムが出ていたので購入してしまいました。(日本でのRajaton情報はさんが詳しいです。最近はいらっしゃるようです)

本当はThe Real Groupの一番新しいアルバムも買ったのですが、新メンバーお披露目、という印象程度で今日まで来てしまったので、いつか多分書きます。。。

で、CD自体はベストということで、今までのアルバム結構持ってるから知ってる曲ばっかりかなぁーと思ったら、CDにしていなかった曲も2曲納められていました。La Dolce VitaとTosi lapselinen joulusikermä, Liveですが、前者はYouTubeなどでTVの映像が良く出てくる歌謡曲みたいな曲です（映画の曲らしい？）。

それよりも、お目当てはDVDです。結構JouluというDVDと重複があるのですが、ButterflyのLive映像は以前のDVDにはありませんでしたし、LuntaとKertosäkeen nainenという曲が素敵です。前者は、雰囲気イケメン（笑）なPVで魅了してくれます。後者はメンバーが楽器を演奏（！？）しながら奏でる楽しげな曲です。このDVDのおかげで更にRajatonが好きになりました。ただ、PALなので日本ではPCでしか見られないと思います。

総括すると、CDは入門者にもおすすめな手堅い曲がきっちり入っていて、かつDVDも良い曲揃いですので、Rajatonに興味のある方は是非買いです！お値段も22ユーロ程度とお値打ちです。国内で入手する場合は、が手軽で良いのではないでしょうか。

やっぱりButterflyは名曲です！

追記：
関心空間の素敵な記事を書いていた方もヘルシンキで手に入れられたようで、羨ましい限りです。

いつのまにか、wptouchが導入されていた

Tue, 27 Oct 2009 14:56:37 -0700

昔探したときはまったく情報がなかったものですが、いつの間にかしていました。って、10/22ってすごい最近だし。

こちらとしては、記事を書くだけで自動的にiPhone/iPod touchでアクセスしたときにwptouchが動いてくれるみたいです。
最近は、fc2といいiPhone対応が進んでいるみたいで便利です。3GでRSS flash g経由でAppbankを開くと、画像が多すぎて頻繁に落ちるのは辛いですが……。

【メモ】Windows7用動作確認系リンク

Mon, 26 Oct 2009 14:56:32 -0700

とりあえず、二件しかないけどメモしておく。

Logitecがオーディオに本気出してきた！？

Mon, 26 Oct 2009 14:56:26 -0700

iPhone/iPod用のマイクです。44/22kHzのwavで録音できる代物で、iPhoneやiPodに刺すだけで使えるみたいです。一つ前の機種は会議用として販売されたそうなのですが、多くのユーザが音楽用途に使いまくって「音が割れるぞ！」とクレーム出しまくったら出たという代物らしいです。Amazonのレビューには逆に「会議用途には使えません」とわざわざそれを皮肉ったものも（笑）実売6000円くらいと、ちょっと手が伸びる価格帯なのがやばい。いつか買ってみたい一品です。

NAS Navigator2が悪さをする@Windows7 64bit

Mon, 26 Oct 2009 14:56:21 -0700

091111追記：解決方法は。

一回だけなんですが、Nas Navigator2がRun time errorを出してくれました。

で、調べてみると

どうも、管理者モードでインストールしないとダメみたいです。
で、改めてアンインストールしようとしたら、それができない。コンパネからもスタートメニューからも、ダメ。BuffaloはWindows7（というか64bit？）対応があまり積極的でないとも聞きます。そろそろio-dataに切り替え時なのかなぁ。

追記：
ネットワーク上のTera/LinkStationを検索中です　が出て止まりません！NASにも三角アイコンがついてるし……。だめだぁ、こりゃ

さらに追記：
なぜか、スタート→すべてのプログラム経由でアンインストールできた。下手に互換モードとかにしてもいけないみたい。よくわからん。ダメルコの時代に戻ったのか？

Mac対応していないNASのプリントサーバー機能を使うには

Sun, 25 Oct 2009 14:56:16 -0700

前々からやりたいと思っていたのだができなかったことだったのだが、今回Windows7を導入にあたってトライしてみたらあっさりできた。基本発想としては、Windows用にsamba経由で共有されているNASなのだから、MacのWindows用プリンタの共有を使ってみたら？という考えだ。
これが、見事に的中した。

環境は、
Printer:Canon MP610
NAS:
Mac OS X Leopard

1. の最新版をインストールする
2.Macの「プリンタ設定ユーティリティ」から＋ボタンを押し「ほかのプリンタ」を追加する
3.ネットワーク上で見えるNASのWorkgroupの下にあるプリンタを選び、ドライバはMP610の後ろにGimpprintとか書いてあったと思います。

以上で完了です。最初ドライバが見つからなかったときはどうしようかと思いましたが、意外とすんなりといけました。

参考：

Windows7 64bitをDG33TLMになんとか導入した

Fri, 23 Oct 2009 14:56:10 -0700

予想外に時間がかかってしまった、64bit版の導入。つまずいたところを忘れないようにメモする。

今回の問題は、intel dg33tmlのドライバ周りがデフォルトでは32bit版なのか、Windowsエクスペリメントインデックスが完走しなかった。行ったポイントは２つ。

1.BIOSのアップデートを念のため行う
2.インテルのサイトでドライバアップデート。一応、チップセット、LAN、グラフィックを３つしっかりいれないとうまくいかなかった。
64bitのほうがスコア値があがりました。
ネックは、グラフィックか。

Windows7がきた！入れた！XP mode試した！

Fri, 23 Oct 2009 14:56:05 -0700

64bit版を入れ直す←もうすぐここ

Windows7の製品版が来ました。RC版で触っていたから、そんなに驚くこともなくスムーズに導入できました。
基本的なソフト（ATOKやらFirefox,iTunesにIDMangerなどなど）を入れ終わって、XP modeの実力を試したら、64bit版を入れ直そうと思います。

まってろよ！64bit Windows7！

VAIO Xに心ときめく

Sun, 18 Oct 2009 14:56:00 -0700

IYHって単なるマリオ的雄叫びだと思っていたら、衝動買いをしてしまったということだったんですね。これだから、ネットの略語は面白い。

今更ながら、CEATECにての実機を触ってきました。名前をど忘れして、Vaio type Xとかで検索してもでなかったのですが、で検索したら出てきたという。Google先生も頑張ってらっしゃる。
実機を触ってみた感触としては、恐ろしい軽さ。これなら鞄に入れっぱなしにしておいても苦にならないだろうという印象。個人的には、ノートは軽くて薄くなければ意味がない、という思想の基、SRX-3E→Type Gと来て壊れやすいが愛着もわいているVaioなので、こういう薄くて軽い路線は大歓迎。今Type Gがあるから我慢できるものの、何も無ければIYHしてたところだと思います。

ただ、Type Gの時にCore Soloでも我慢できる！とか思って、結局処理重いなぁとか思っているので(1.8inch HDDとかウィルスバスターのせいも大いにあるかもしれないが)、Atom系は微妙なんだよなぁ、と我慢しております。

ただ、根本的にiPhoneがあれば大体事足りる生活が出来つつあるので、おそらく旅行に行った先での手軽に利用できるマシンとして、という位置づけかなぁ。

CEATECいってきた

Sat, 10 Oct 2009 14:55:54 -0700

去年と比べると少し勢いが薄れたかな、という印象でした。写真は海浜幕張駅の様子。あさから、階段を降りるという行列を楽しんで来ました。
個人的には音響よりのメーカーが出展していなかったので、残念でした。昨年はVictorやPioneerがスピーカーやイヤホンを試聴させてくれたのに。。
自分が見た中では、三菱のREALと東芝のセルREGZAのスピーカー、dynapocketのノイズ抑制、ドルビー先生のデモくらいかなぁ。
テレビ対決は、お金の掛け具合の違いもあり、REGZAの方がよろしかったです。デモの方法の違いも大きいかなぁ。一方がJAZZライブに対し、もう一方が映画の予告編。しかも、ミサイルの爆音ですらあまり感じなかったという…。値段の差ですかねぇ。
ドルビー先生のは、PCに組み込みしないとダメみたいなんで、そんなもんかなぁと。むしろ、試聴用ヘッドホンがHD555なのを見て、やはり映画向きなんだなぁーと実感。

家電メーカー各社は、東芝を除いてメインはエコと3Dなので、あまり楽しめませんでした。むしろ、KDDIのテレビとの連携（番組推薦等）を見て家電の世界に入って来たかと思ったり、ドコモの眼球操作（筋電ではなく、左右しか取れないらしい）を見て、新たなインターフェースの可能性感じたりしてきました。

Windows7を予約した

Fri, 25 Sep 2009 14:55:49 -0700

GIGAZINEを読んでいたら、に触発されて予約してしまいました。
色々調べていたら、どうやらWindowsXP HomeからもWindows7 Professionalに移行出来る模様。RC版を使ってみる感じでは、普通にいけます。特に問題は感じないです。
あ、とはVistaにすら対応していないので、諦めました。まぁ、１００円で買ったからいいか。

Motion Blue YOKOHAMA

Thu, 24 Sep 2009 14:55:44 -0700

初めて赤レンガ倉庫に行ってきました。お目当てはモーションブルーで行われたJAZZピアノ。
ちょっと優雅なディナーと洒落込みました。

テナーサックスの色っぽい音色や、ウッドベースの温かい音を満喫してきました。
帰りは赤レンガ倉庫のお店を見て回るも、あまりパッとしたものもなく。連れ曰く、劣化パルコとのことです。趣はあるんだけどね。

[

](l_1600_1200_ca074d00-f85d-4139-b129-5ed39958279b.jpeg)

PCでワイヤレスコントローラを使うには

Tue, 22 Sep 2009 14:55:38 -0700

ふと思い立って、WiiよろしくPCもワイヤレスコントローラでゲームをやってみたい、と思ったので調べてみた。

おおざっぱにまとめると今のところ、3つの方法が有力かなぁ。

普通に売っているLogicoolやHORIのPC用のコントローラを買う
PS3用のDual Shock3を買う
XBOX360用ワイヤレスコントローラを買う 1．普通に売っているLogicoolやHORIのPC用のコントローラを買う(\4000程度)
普通すぎる選択肢ですが、たとえばなんかがあるみたいです。これだと、難しいことを考えずに使える模様。

2.PS3用のDual Shock3を買う(\5500程度)
にアダプタを買えば良いみたいです。デスクトップにはbluetoothアダプタが無いのでこうするしかないのかな。前者が\4400、後者が\1050ということです。PS3が無い環境ではちとためらうお値段。

3.XBOX360用のワイヤレスコントローラを入手する(\9000程度)
今となってはあまりオススメできない方法。ワイヤレスゲームアダプタというUSB側のアダプタ(\2100)が、現在入手するのが困難なのがその理由です。で、代替案としては\5000ちょいするを買ってPCにつなぐと良いようです。コントローラ(\3780)と併せて\9000弱か……。高いなぁ。

というわけで、手元にPS3もXBOX360も無い身としては、1のLogicoolのコントローラを買うのが無難そうです。しかし、シミュレーションゲームくらいしかやらないんだったら、ワイヤレスキーボード＆マウスで事足りそうなので、気が向いたらか。

参考URL:

RENT ブロードウェーツアーを見て来た

Sun, 30 Aug 2009 01:08:13 -0700

今更ながら、報告です。
行ける日程が急遽変更になったのですが、運良く譲っていただいていけることとなりました。
まさか、映画でみたマークに、ロジャーに会えるとは思っていませんでした。日本に来たことに感謝。
生のバンド演奏に震え出す思いでした。ロックミュージカルだわぁ。
また、高良さんのダンスのキレも全然違っていてよかったです。日本人で背が低いことを感じさせないのが凄い。

一度生で見れたのは幸せでした。二回目もみたくなったくらい。

RENT Billboard

瑞巌寺

Wed, 12 Aug 2009 03:08:40 -0700

歌に聞きし瑞巌寺にいってきました。雄島はあいにくの雨のため諦め。

しかし、岩にしみいる蝉の声というのはこういう風景をさすのだろうなあと思いながらめぐってきました。

お寺そばの蕎麦屋さんにて食べた穴子天丼はやばいくらいのボリュームでした。なんとか食べ切ったけれど。

その後、秋保温泉に。お高めなホテルの日帰り温泉にて満喫。

総じて楽しい仙台松島紀行でした。

]

MASA FESTA中止

Wed, 12 Aug 2009 02:08:52 -0700

なんということか。RAJATONが、THE REAL GROUPが…。
残念でなりません。そして、今後の海外アーティスト招聘に悪い影響が出ないと良いのですが。

HOUSE JACKはすでに来日してるみたいなのにね…

ポケモン新幹線

Thu, 06 Aug 2009 19:08:14 -0700

たまたま乗った新幹線がポケモン新幹線でした。
車内でスイカを500円以上使うとオリジナルストラップがもらえるというのでゲットしたのですが、iPhoneにはストラップをつける穴がないことにもらってから気づきました。

というわけで、七夕祭りで街は賑やかです。

読書メーターの面倒なところ

Thu, 23 Jul 2009 14:55:06 -0700

なんか、あれを始めてから殆ど本を読んでいないのであまり参考にはならないかもしれませんが、使ってみた雑感を。

以前はexciteのライフログ機能を使っていたのですが、WordPressに切り替えたときに、乗り換えてみました。ライフログの評価は本以外にも可能で☆のレーティング＋コメントという形式だったのに対し、読書メーターはコメントのみです。で、書いてみると見た目的にあまり長文を書く気には慣れない。見た目がはてブっぽいんですよね。
当初は、読書メーターでコメント書いてそれを殆ど使い回してブログのエントリーに出来ないかなとか考えていたんですが、どうも微妙です。

でも、今何を読んでいるのか(積んでいるのか)が明示されるのは良いですね。モチベーションが多少は上がる気がします。

FUJIYAMA

Wed, 22 Jul 2009 20:07:36 -0700

先日行ってきた河口湖です。貸別荘から見える富士山が素敵でした。
バーベキューは楽しいですねぇ。

帰りは40km以上の渋滞に飲み込まれました。怖るべし、海老名。

Masa festaのチケットが来た

Sat, 11 Jul 2009 05:07:59 -0700

最近、とみにコンサートに通っていますが、八月に行われるMASA FESTAのチケットが届きました。
お目当ては最終日のRAJATONです。今から楽しみ。

しかし、運営がどうなのかなぁとかおもっていましたが、ビラはしっかりしていたので、よかったです。

Steve Dobrogoszの動画がたくさんある件について

Thu, 09 Jul 2009 14:54:56 -0700

以前の動画がYouTubeにありました。たくさんあるので、一部紹介したいと思います。ちなみにがいるようです。この充実度からするとオフィシャルなのかな？

一番有名な合唱曲MASSからKyrie。この演奏もそうですが作曲者の意図が分かるというか、なるほどそう言うイメージで作ったんだ！と驚きです。ピアノが歌っている。

Lord I’m Freeのリハーサル？模様。本番もアンコールもかっこいい！につきます。変態ベースがいる。羨ましい声。あこがれます。

七夕キャンドルナイト

Tue, 07 Jul 2009 05:07:25 -0700

今年は晴れだか曇りだかわからない七夕でした。駅の近くでキャンドルナイトをやっていたので、行ってきました。
ハート形のキャンドルや、メッセージキャンドルなどがあり綺麗でした。にしても、多かったのは近隣のお店の宣伝やらコミュニティFMの宣伝やらも。川崎にもあるんだー。
今度聞いてみよう。

関東はGame Musicほいほいだ

Sun, 05 Jul 2009 14:54:45 -0700

が今年もやってまいりました。今年こそはチケットを購入したので、万全の体制で臨みたいと思います。

他にも、関東にはアマチュアのGame Musicの演奏団体がいくつかあるようです。

○ 神奈川県を中心としているブラスバンド。選曲がかなりきてます。

FCB 9thより。今年もライブやるようです。

○ 素敵な演奏がニコ動にいっぱいあるです。

オープニングからの再現度が違います。

なんというか、効果音が頑張りすぎです。

かけ声ナイスすぎ(笑)

今年はFCBにも行きたいですねぇ。

成就院の紫陽花

Sat, 20 Jun 2009 00:06:13 -0700

激混みの江ノ電に乗って鎌倉は成就院にきています。
人も多いけど、紫陽花もたくさんありました。素敵なお寺です。

途中で見付けたアバウトな看板。大仏か海岸か。間違ってはいないんだけど、笑える。

iPhoneに望むこと

Thu, 11 Jun 2009 14:54:34 -0700

最近、tumblrをメモがわりにquoteすることが多いのですが、iPhoneでtumblrを使う機会も増えてきました。
iPhoneではリブログすることがほとんどだったりするのですが、tomblooライクに引用したいんですよね。現状、Googleリーダーで気になる記事をスター付けるくらいなんですが、余り検索する気にならないんですよね。何がメモしたいか、その部分を残したいと思ったときに残せる方法ってないのかなー。んー

新型iPhone 3G Sの価格について

Tue, 09 Jun 2009 14:54:29 -0700

.を見てみるとやばい、やばすぎる。
１６GBで11520円、３２GBで23040円って、、、あれ、１６GBをスパボ一括で29800円で買ったのに涙が出てきそうだ……。

いや、まてよ。たしか以前で旧iPhoneから新iPhoneに切り替えても、違約金は発生しないという話をしてたので、一括で払い終えていると言うことはiPhone3G Sを更に機種変で買えば、16GBのカメラ付きiPod Touchを手に入れたってだけか……？

だまされそうだー。

ちなみに、バッテリー交換などをするときにデータが飛んでも良いように、Windowsで手っ取り早くアドレス帳を管理しようとOffice買いました。今、本数限定でキャンペーン価格で手に入るのよねぇ。アップグレードとはいえ、のは大きいわぁ。
ちなみに、学生さんので、これを逃す手はない！

LinkStationのWebアクセスとSimplify Music 2@iPhone

Sun, 31 May 2009 01:05:01 -0700

NASに蓄えてある音楽へどうやってiPhoneからアクセスするかを考えたときに、2つの方法があったので、検討してみた。(Simplify Music2はまだ試してないですが)

方法としては、

BuffaloのNASに付いている機能であるLinkStationのWebアクセス機能
Simplifi Music 2 というPC上のiTunesの楽曲を共有するアプリの二通りの方法が考えられる。
ちなみに、我が家のNASはという代物で、最初の発表の時にはiTunesの共有サーバ機能が告知されていたのに、買ったときには既にその機能は削られていたという代物。あれ？kogureさんところに情報乗ったときには、OKだって書いてあったから信じてたのに、、、(ちなみに、後継機であるはiTunesサーバ機能が搭載されているのであった)

今回は、Webアクセス機能を試してみた。(ちなみに、Simplify Music2の情報はこちらでどうぞ。 )
色々調べているうちに、外から見なくて良いならBuffalo.comを経由してアクセスする必要ないんじゃね？と思っていたら、このサイトを発見した。

まさしく、望んでいた情報だった。つまり、ローカルのNASにアクセスするのみであれば、Webアクセスの設定時に「NASのIPアドレス」を設定すれば良いだけだったのだ。通常は、Baffalo.comを使うという設定になるが、うちではUPnPも静的NATの設定も上手くいかなかったから、苦肉の策でもあった。そしたら、意外にもローカルで回す分にはこれで十分いけるみたい。しかも、外にポートを開放していないから外部にNASを晒すというリスクも減るでしょうしね。

Webアクセス機能の実際の使い勝手としては、イマイチだった。

大量の曲(50G以上)が存在しているときに、フォルダを開いてブラウジングして目的の曲を探すのは面倒。というかやる気にならない
一曲ずつしか再生できないので、BGMにしようという目的には全く向かない。というか不可能。で、結局試してみた物の、お蔵入りになりそうな予感です。どちらかというと、この機能は遠隔地の人にファイルを提供するためのもの？なのかもしれません。iPhone用の画面も一応ありますが、、、おまけみたいなものですね。

今度は、Simplify Music2を試してみたいところ。ネックは、PCを起動させておかないと共有音楽にアクセスできないことかなぁ。

三菱東京UFJのコールセンターが素晴らしい3つの理由

Sat, 30 May 2009 14:54:18 -0700

今日、UFJ Directの関係でコールセンターに電話をしたのですが、過去のSoftbankやWillcom、新生銀行とは比べものにならないくらいの対応で驚きました。

フリーダイヤルに携帯でかけてもはじかれない
土曜の夜10時でもオペレータが対応
オペレータが出るまで2コール 1．は、はじかれるだろうと思ってiPhoneでかけてみたらあっけなく繋がり驚愕。
2．は、Webには24時間繋がると書いてあったんですが、どうせ自動音声案内のみだろうと、たかをくくってスピーカーモードにしていたら驚愕。
３．は、スピーカーモード＆キーパッド表示にして操作していたら、階層が2階層(即ち二回ボタンを押すだけ)で、オペレータに行きまして慌てて切り替えてたら2コール目くらいでオペレータが出ました。驚愕。

きっと、この対応をするために相当なお金をかけているとは思うのですが、平日の9時-17時とかいう会社が多い中で、大いに助かりました。

MUFGすごいよ、MUFG！

X ZABADYのシリコンカバーを買ってしまった

Sat, 30 May 2009 05:05:33 -0700

結局、のシリコンカバーを追加注文してしまった。

しかし、オフィシャルからしか買えず、値段も840円とちとお高め。更に送料が263円。。。まとめて買うと、逆に1050円以上の商品は送料630円になるという……。普段いかにAmazonに慣れていたか痛感する瞬間でした。
元の物が4000円しない物だけに、ちょっと高いなぁと思う。さらに、佐川の代引きオンリーなところが、微妙。まぁ、宅配ポストとか無いからいいんだけどさ。

まぁ、2年くらい使ったら破れるわな、とそこは文句は言わないのです。しかし、SoundhouseでEtymoticResearchの消耗品買えるみたいな、他の業者にも取り扱いが出来るようになってくれれば良いのに、と思う次第です。

最近は、ニコニコ動画でフノレボイス　ドラクエ３をお風呂で見ていたのですが、ニコニコは夜は重いので、で適当にJazzを聞く方向にシフト中です。Bill Evansくらいしかわからないんだけどね。Rockapellaとかも聞ければ良かったんだけど。

お風呂でiPhone+ニコ動は良いよ

Wed, 27 May 2009 14:54:07 -0700

.
こちらのサイトと同様にうちでもZABADYでiPhone突っ込んでニコニコ動画を満喫していました。久しくニコ動を見ていなかったので、歌ってみたとかフルボイスドラクエ3とか色々漁って楽しんでおりました。

ところが、先日ZABADYに穴が。。。

やはり、iPhoneは大きいため結構無理矢理入れていたのがたたったのかなぁ。後、をケースにつけているため相当分厚くなってしまったからとも思えます。とりあえず、穴の空いたZABADYはリビング用ラジオとして生きる道を見いだしました。

もう一個ZABADYを買うか、ジップロックで頑張るかが悩みどころです。とりあえず、今日はジップロックで行くかな。

- 追記–

と思ったら、シリコン交換できるらしい。でも、買うところがみつからないー

- 追記2–

どうやら、で買えるみたい。

クロノトリガーの「時の回廊」が名曲すぎる

Sun, 24 May 2009 14:54:02 -0700

あまりそう思ってなかったんですが、聞いてみてどのシーンで使われていたのか思い出せず検索してみたら、こんな動画が出てきました。
クロノトリガー『時の回廊』全部俺の声（CHRONO TRIGGER Corridors of Time）

意外と、原曲をとらえたいいアレンジだと思います。素敵。高音質な物が

そしたら、こんなクロノトリガーのメドレーアレンジが。

クロノトリガーの作曲をされたは、昔から周りにファンがいたので名前は知っていましたが、改めて良い曲をかく人だなぁと再認識。

iPhoneでExpress予約ができるアプリ

Tue, 19 May 2009 05:05:03 -0700

元々、W-ZERO3から乗り換えた大きな理由として、JR東海のExpress予約ができないからでしたが、そんなときがあり感激して乗り換えを決意しました。

そんななか、別の方がようで、115円ですが販売されています。

非常に便利。というか、そもそもJR東海が携帯かPCでしかアクセスできない状態にしていたこと、そしてJR東日本の駅では発券も変更もできないから、遅延が起こったときにはPCで変更してくださいとか言われることとか、基本的にはJR東海が手抜きをしているだけとも言えますが……。これによって、ようやくExpress予約を気軽に変更できる！

iPhoneとの1週間

Mon, 18 May 2009 14:53:51 -0700

はじめて生で小夏ちゃんを見た。梅雨くん（ちゃん？）も見てしまった。それをiPhoneので実況板を見ていたのですが、流れが速くて追いつかないという現象を見てしまいました。すごいわー

で、iPhoneを一週間使ってみて色々と戦ったわけですが、大体どの問題も一通り誰かが通ってきた道でした。というわけで、備忘録として簡単にメモしておきます。

i.softbank.jpの着信時に音が鳴らなず画面通知のみ。ならすためには、iBifflite(有料)を使うか定期的にフェッチをするようにする必要がある。後者は１回鳴るだけだが、無いよりマシ。
コピペができない。頑張ってブックマークレット使うればいいんだろうが……。
上に類して、メールで電話番号やメアドの変更が来たときにすぐに登録できない。一度ワン切りandメール送信をすれば登録可能。
PCからファイルを転送するのにソフトがいる。とりあえず、を使ってみる。これで十分。
Docomoやauの.がらみの酷いアドレス("..“や”.@")をBCCに入れたまま送信しようとすると何も送れない。再利用もできない。必要に応じて一人一人Toで送ることはOK。ちなみに、２００人とか一斉に送っても問題なし。
同じメールを何回も送りたい場合は、メモで作成して送るようにすれば良い。これ重要。
はgmailなんかの"+hogehoge"を使っているとログイン出来ない。もちろん、洗練されたUIやWinodwsMobileにないキビキビした動作は素敵です。というか、これに慣れると戻れないです。素晴らしい。細かいところは、まぁスルーできる範囲内かな。
障壁としては、完全に電話として移行するのがつらいというところでしょうか。PDAとかモバイル端末としてなら全然問題ないと思います。

Apple storeがWe'll back soonに……

Sat, 16 May 2009 14:53:46 -0700

もうすぐ、新型iPhoneだとかiPod touchの発表なんでしょうね。amazonでも32G touchが20000円引きで売られていることですし。

なぜ気づいたかって？Xcodeをダウンロードしようとしたら、メンテナンス中だったからだよ。iTunesStoreはXcodeの入手には必要なかったみたいです。そういえば、、、
参考URL:

今起きている問題は、Buffalo製のLS-C1.0TLに保存してあるiPhoto Libralyが不可視フォルダになって見えないということ。これにより、開けない状態になっているわけです。で、ターミナルを立ち上げて、dfをしてみると、どうもiPhoto Libralyが置いてあるディレクトリが複数あるわけです。

/Volume/photo
/Volume/photo-1
/Volume/photo-2
で、それぞれ中を見てみると、無印と-1のところにはiPhoto Libralyのみ入っている状態。作成されているのがそれぞれ休みの日の夜中だから、もしかしたらNASがバックアップしている時にiPhotoを開いていて、変なことになったのかなぁ、とか勘ぐってみる物の原因は不明。

明日起きてから対処ですわ。

- 関連サイト–

[MacOSX 不可視ファイルの解除方法（&パスの通しかた） - WEB + PC[
もしかしたら、Nas navigator2を入れたときに自動マウント利用するようにしたのが悪いのかも。キーチェーンがおかしくて、大抵ゲストアカウントでマウントされてるし。

読書メーターはじめました

Sat, 16 May 2009 14:53:40 -0700

をはじめました。
今までは、exciteのライフログで読んだ本を管理していたのですが、なんとなくこちらに移行してみます。別に何が変わるというわけではないのですが、読んだ本の状況ががグラフになるのが良いなぁと。
ただ、だらだら読むだけで満足してはいけない、とか読書にかけたお金は投資じゃなくて浪費だとかいう話もあるのですが、気分転換に読む読書も大事だと思っています。

というわけで、試してみようっと。

こんにちは、iPhone

Tue, 12 May 2009 14:53:35 -0700

iPhoneさんがやってきた。
なかなかおもしろいおもちゃだ。いろいろな可能性を持っている感じ。
WordPressも、アプリからかけるし。電話帳と携帯移行の連絡が厄介かな。後は、ドコモのドットが入った人は強制的に連絡とれずなのもちと辛いか。

Ad[es]→iPhoneアドレス帳移行メモ

Sun, 10 May 2009 05:05:54 -0700

- 090510 2145追記–

この方法では、「フリガナが消える」、「全てのアドレス帳が移行できない」といった根本的な問題がありました。まだ解決できていません。

- - - 090513追記

結局、Outlook2003でやりました。はぁ

アドレス帳の移行に躓くのがiPhoneのイニシエーションらしいので、躓いてみた。最終的に出来た方法を下記にしめします。

下記のConvVCF2を利用して、Ad[es]のアドレス帳情報をVCFデータにする。
ちょっと頑張って100件以下にＶＣａｒｄを分割する。(その場合、文字コードは変えない)
メールでiPhoneに添付して送る。
iPhoneでVCFを開いて追加しまくる。Ｏｕｔｌｏｏｋもいらないし、何故かＭａｃのアドレスブックやiPhoneのアドレス帳に100件以上登録できない問題も回避できます。よかったよかった。

というわけで、こんにちはiPhoneさん。２９８００円でスパボ一括で買えました。幸せ幸せ。

さよならWillcom、さよならAd[es]

Thu, 07 May 2009 14:53:25 -0700

GW中ずっと悩んでいた案件に解を出しました。友人たちには感謝感謝。

結論としては、iPhoneに移行ということになりました。コストで決まらない要素がたくさんあるというのが大きな理由です。通信速度、WindowsMobileの糞UI、機種は変わらないのにアドレス変更連絡を出す苦痛。これらを総合すると、月280円で維持できるとしても端末としての魅力がないのであれば、Ad[es]には魅力がないという結論になりました。
対してiPhoneは、OSのアップデートも近日控えているように、touch発売から2年たった今も共通のプラットフォームで使い続けることができています。
操作系の不満をいつでるかわからないアップデートを待たず、ユーザアプリに頼り不安定になっていくのもばかばかしいなと。

ま、実際の決め手は相談の電話をしようとしたときにAd[es]がフリーズしたことなんですけどね。

Ad[es] VS iPhone(値引き合戦)

Tue, 05 May 2009 22:05:42 -0700

最近のiPhone for everybodyとWillcomのGWキャンペーンの比較。Ad[es]をメインで持っていて、でもそろそろ愛想を尽かしたのでデータ専用の端末としようかなぁ、という人と考えてください。隣にAppleの回し者がいるけど、スルーの方向で。
基本的に各月パケット代はフルまで使う前提です。

ケース1：Ad[es]を解約せずに使い続ける場合
[月額]
WILLCOM定額プラン:2,900円
リアルインターネット:2,100円 (cf.オプション・データ定額下限1,050円)
ユニバーサルサービス料:8円
計：5,008円/月
(なお、現行での請求額はおよそ6,000円/月)

ケース2:Ad[es]を解約して、GWキャンペーンに乗っかる(〜5/7)
[解約コスト(*)]
年間契約解約手数料:2,100円(2年目以降の場合。初年度は4,200円。7月に解約すればなし)
割賦残高:8,050円
小計:10,150円
[購入費用]
WS002IN(DD)購入代金:16,800円
サポートコイン10コイン:-5,000円
契約手数料:無料(29歳まで。〜5/31)
小計:11，800円
[月額費用]
新つなぎ放題:280円(24ヶ月)
ユニバーサル使用料:8円
小計:288円
備考:番号変更の連絡は必須。WindowsMobileの使いづらさは我慢し続ける
参考:

ケース3:Ad[es]を解約してiPhone 16GBに移行する場合
[解約コスト]
(*)と同じく、10,150円
[購入費用]
iPhone 16GB: 42,240円
お店のポイント10%:-4,224円
ただともクーポン:-5,000円
新規契約手数料:2,835円
小計:35,851円
[月額費用]
パケット定額フル:4,425円
ユニバーサル使用料:8円
小計:4,433円
備考:2年間の縛りが分割支払い意外に存在。9,975円。2年ごとのタイミングでしか解約できないことになる。

グラフにまとめるとこんな感じ。

各キャンペーンの月別コスト

○まとめ
コスト的には、Willcom乗換が圧倒的に安い。ただし、WM6の仕えなさ加減と面白さがあまり感じられないこと、iPhoneのUIを見るとそっちに心惹かれるものがある。
ただ、iPhoneは買い換えが2年間非常に厳しいことがネックである。逆にwillcomのGWキャンペーンであれば、維持したままの浮気も可能な額と言えよう。ただ、今までのようにPublic携帯とするのは通話コストの増加(10.5円/30秒→31.5円/30秒)が厳しいか。(ちなみに、ホワイトプランの通話料は21円/30秒)

端末の魅力でiPhoneに押し切るか、コストでwillcomにするか、これが悩みどころ。多分iPhoneに押されるとは思うが。。。

Ad[es]を解約するために

Mon, 04 May 2009 14:53:14 -0700

.を読んでいたら、W-value selectで最安プランに変更して持ち続けることには意味がないらしい。待ち受け専用として持つ意味を感じるかというところのようだ。
とっとと15コイン(≒7500円分？)使い切ってしまって、解約するのが吉かな。

- 追記–

willcom store見たら、電池パックくらいしか買えないみたい。一応、Ad[es]の電池パックでも買うかなぁ。意味ないなぁ。

iPhone 16GBとiPod touch 32GBどちらでもいいんじゃない？とか思っていたけれど、見る限りでは、touchだとOSが無料でVer.UPできないみたい。これは後悔しそう。今のところは、一台で我慢するかiPhone 16GBに手を出すかだなぁ。

MoneyLookが便利な件について

Sun, 03 May 2009 23:05:24 -0700

なるものを友人から教えてもらいました。

これは、銀行口座やクレジットカードの情報を一括で管理してくれるソフトです。Microsoft Moneyは有料なのでフリーのものを探していたら、これに出会いました。

できることは、

銀行口座の入出金の管理
クレジットカードの仕様履歴の管理
モバイルSuicaの入出金の管理（！）

ということで、家計簿を付ける際に困っていたところが解決できそうです。最近は、電子データでクレジットカードなどの仕様履歴を確認しなければならなく、かつWebでの確認は適当にならざるを得ないインターフェースだったので、このソフトでOfflineでじっくり確認できるようになりました。

ただ、IDとPasswordをこのソフトに入れなければならないこと、Y!Japanが絡んでいること等が気になる人は避けた方がよいかもしれません。

ほぼ日がiPhoneを持ち上げてる

Sat, 02 May 2009 14:53:03 -0700

でiPhoneが欲しくなってきた。

半分ほんと、半分はAdvanced[es]の一人ネガティブキャンペーンのおかげ。

Willcom×Ad[es]に対する現状の評価は、

遅い
重い
安くない

の３拍子揃ったものとなっている。特に、iPhoneが実質ほぼパケットし放題と同じ金額で手に入るキャンペーンをやっているおかげで、遅いWillcomのメリットがなくなった。そして、8円携帯にパケ放題を付けるくらいなら、、、というレベルになっているのは驚きを隠せない。

＃ちなみに、パケットし放題２はSMSに課金がされるようになる詐欺仕様らしい

一番安いのは、Willcomをつぶして8円携帯にパケットし放題を付けることだが、iPhoneという玩具で遊んでみたいのもあるんだよなぁ、と今更ながら悩んでおります。

しかし、自分の中で必要な理由がハッキリとないってことは買わない方がいいんだろうなぁ。

はじめまして、WordPress

Sat, 02 May 2009 14:48:14 -0700

exciteがちょっと不満になったので、こちらにお引っ越しです。本当はデータも全部お引っ越ししようかと思って、色々試したのですが技術的に可能なことが分かったところで満足して面倒になったので、やめました。

もしかしたら、本とヘッドホン関係だけ移行するかもしれませんが。
それでは、よろしくお願いします。

- - - 追記—-

本と音楽関係だけは連れてきました。
exciteの移行にはにお世話になりました。

チャンネルはそのまま！Vol.1

Sun, 26 Apr 2009 14:48:20 -0700

[

チャンネルはそのまま! 1―HHTV北海道★テレビ (1) (BIG SPIRITS COMICS SPECIAL)

佐々木倫子 / 小学館

どうでしょうでおなじみの、HTBがモデルになっているらしい、というポップにつられて買ってしまいました。
開けてみるとすばらしい！魔神がモデルになっている小倉部長が良い味出しています。どうでしょうファンの人なら是非楽しめるはず！

スコア:

]( )

となりでダ・ガーンを絶賛オススメされています。ガオーンが可愛いらしいです。

It don't mean a thing.

Mon, 13 Apr 2009 14:50:33 -0700

がかっこいいです。
Fight of Foo Birdsもかっこいいですが。

この辺のThe Real Groupが歌っているような曲の元曲やら、アレンジ曲を集めてみたいなぁと、思ってRealのCDをニマニマしながら聞いております。

新居にはクローゼットがない

Sat, 14 Mar 2009 20:03:00 -0700

押し入れはあってもクローゼットがありません！
箪笥は置く場所がありません！というか引越の時にも大変そうです。お値段も（ｒｙ

というわけで、の一番大きいやつを買いました。
動機は、頑丈そうだから。というこれにつきます。以前使っていたホームセンターで買ったやつは、量はかけられそうだったのですが、耐荷重が低すぎて、下に落ちてくると言う始末。なので、耐荷重だけは気にしながら買いました。

で、使ってみて良い感じです。和室に置いているのですが、カバーがあるおかげで埃も気にならないですし、強度もまぁまぁ。
ただ、強度に関しては組み立ての時の精度によって結構変わってきそうなので、一人で組み立てるのはお勧めしません。

全般的に買って良かったなと思います。アマゾン的には☆４つかな。二人で組み立てれれば５つになったかなと。

MasaFestaのコンサート情報が出始めました

Sat, 14 Mar 2009 19:03:00 -0700

のコンサート情報が明らかになりました。まだ、ですが、予定も出ています。とりあえず、Rajatonを聞くために日曜日には行こうと思います。チケットとれるかなー。
8/20(木)：MOSAIC、m-pact
8/21(金)：Pitsj 、The House Jacks
8/22(土)：Riltons Vänner
8/23(日)：Rajaton、Take6

お値段は、全席指定でS席￥18,000、A席￥15,000、B席￥12,000
通しなのかなぁ、と思いますが、これで一回の値段だったら……

—-追記

MasaFestaにRajatonが！！

Mon, 09 Mar 2009 14:50:44 -0700

やばい！生で聞きたいと思い、Finlandまで行ってもすれ違いだったRajatonが向こうから来てくれるとは！

で聞くのが一番手っ取り早いかもしれませんが、とてもすてきなアカペラグループなのです。
コンサートだけでなくて、academyも行きたくなってきた……。夏休みをここでとれば行けるしなぁ。

過去のエントリ
○Masa Festa

続報Masa Festa

Tue, 03 Mar 2009 04:03:00 -0800

Realの男性陣が来日するとのことです。ひゃっほう！

世界最大規模のアカペラ祭が日本で

Sat, 28 Feb 2009 20:03:00 -0800

によると、Masa Festaというアカペラのお祭りが日本で2009/8/19〜8/23に行われるようです。
（公式サイトは )

主な構成は、コンテスト、アカペラレクチャー、コンサートの３つのようです。
コンテストは全国20カ所で行われるアマチュアコンテスト。時間が5分以上9分以内となっている他は曲数曲目は自由。
アカペラレクチャー（アカデミーが本当の呼称）は、今日（3/1）から申込み開始のようです。Take6などの講師が来日するそうです。メニュー見た感じは、ボイパとかそっち方面かー、ってのでスルー。

とりあえず、The Real Groupとかが来るわけではないみたいですが、ほいほい行ってしまいそうなタイミングです。お盆休みをそこでとれば良いんですね、分かります。

TRY-TONEがMY SpaceとYou tubeに

Sat, 17 Jan 2009 22:01:00 -0800

にいつの間にかTRY-TONEのオフィシャルページが出来てました。(Thanks! さん)

1/18付けで一番上にある約束が、どうみても先日のLAZONA川崎のクリスマスライブな気がして仕方がないんですが。あの客周辺の女の子の声とか、後ろのグループ名の投影の仕方が、特に。

愛がいない部屋

Tue, 18 Nov 2008 13:48:25 -0800

石田衣良 / / 集英社
ISBN : 4087463044
スコア選択: ※※

掴まされた。

今度は悪い意味で。懲りずに買ってしまった。恋愛小説フェア(笑)がやっていたので、なんとなく買ってしまった。帯をしっかり読めば良かった。

「DV、セックスレス、不倫。切なく胸を締め付ける恋に、光は射すのか――。」

この帯で避ければ良かった。1ポンドの悲しみなどで良い印象を持っていた氏の恋愛小説だが、この作品は毛色が違う。私にはあわない。

全てが女性視点で書かれていて、男がダメなのだ。しかも、それが全て女性に悪い部分はないように描かれている。そして、出てくる男性は大抵「仕事に生きている」のである。それが、非常にリアルなのである。つまり、自分もこの男と同じように堕ちてしまうのではないか、そういう不安をかき立てられる。特に、最後の表題作「愛がいない部屋」では、「あの手の男は、みんな最初のうちはそうなのよ。それで手のひらを返す」「所帯をもった最初のうちは、敵も尻尾をださないものよ」など、強烈な言葉が投げかけられる。

一方的に攻められる気がして、良い気分ではない。おかげさまで大分落ちた。小説に求めているのは爽快感というエンターテイメントなので、ちょっときつかった。

良い時代になったねぇ

Sat, 08 Nov 2008 13:51:05 -0800

関東に来たからには一度は行ってみたいと思っていた、。
つい先日、9thの演奏会があったのですが（残念ながら行けなかったのですが)、今ではニコ動にではありませんか。

いや、オフィシャルがこういうことをやってくれるってのは、一昔前では(ネットワークリソース的な問題で)ありえなかったのに……。著作権とか色々面倒だったのに……。良い時代になりましたね。

任天堂メドレーが楽しめました。いや、他も聴きたいし次は生で聴きたいです。本当に。

音律と音階の科学

Thu, 06 Nov 2008 13:48:36 -0800

小方厚 / / 講談社
ISBN : 4062575671
スコア選択: ※※※※※

物理学の専門家による、音楽の「音律と音階」の解説書。非常にためになる。音楽と数学についての本は色々あるのかもしれないけれど、実験心理学的な話を絡めているのが面白い。
どういうことかというと、心理実験を元にして二つの重音に対して、違和感を感じるかを不協和曲線というグラフを描いた。そして、それをベースにピタゴラス音律や純正律が何故用いられてきたか、心地よいかを論じている。非常に面白い。ただし、ターゲットとして音楽を知っていることを前提にしているようだ。仕方ないか。

これでいいのだ

Thu, 06 Nov 2008 13:48:31 -0800

赤塚不二夫 / / 文藝春秋
ISBN : 4167753278
スコア選択: ※※※※

赤塚不二夫の自叙伝。がばいばあちゃんを読んだときも思ったのだが、昭和の時代を生き抜いた氏や氏の両親の話は読んでいて面白いですね。戦時中や戦後の子どもたちの伸びやかなこと(別に今の子どもがどうのと言いたいわけではないですが)

気楽に読める一冊です。

a-cappella.comから注文の品が届いた

Thu, 30 Oct 2008 14:51:10 -0700

名前の通り、アカペラのCDやら楽譜が入手できるサイト。
いやね、今の円高のビッグウェーブに乗って購入……、円高傾向が高くなる前の話ですね。
今回頼んだのは、The Real GroupのNothing but The Real Groupと Live in Stockholm,それからA cappella in Acapuluco, I Sing, You singの楽譜たち。
Waltz for Debbyの楽譜は売り切れでした。残念。ちなみに、Realが歌ってるアレンジを今回初めてまじめに聞きましたが、ベースはBill Evansが女性シンガーと一緒に演奏しているものですね。途中の展開の仕方が違うけれども。2番はやはりオリジナルの展開が躍動感あって好きだなぁ。

というわけで、歌いたい曲がどんどん増えていきます。

何故かiTunes storeで買ったm4pが音が出ない

Wed, 29 Oct 2008 14:51:16 -0700

そうなのだ。しかも、その症状が出たファイルは、前のマシンでバックアップして新しいマシンに復元した日本語のファイルばかり。ファイルも日本語の部分だけ文字化けしていて(日本語がアンダーバーになっていた)、QuickTimeでは再生できるというなぞっぷり。
仕方がないので、問題のファイルをライブラリからいったん消して、m4pのファイルをもう一度追加したら大丈夫になった。iPodに入っていたファイルも、無音が曲の長さ分発生していたので、気持ち悪かったが……。よかった。

というわけで、色々日本に来るらしいアカペラグループ等々のライブ日程をば。

○
ラトビアのアイドルアカペラグループです。
根性で有給取って、羽田から行けば13kちょっとで行けるみたいです。
いや、有給取ってまで行くのかというのが大きな問題。
11/7(二公演),9との日程です。
関西に近い人は日曜の公演に行けると思うなぁ。名古屋とか。名古屋とか。

○
ドイツからはるばるいらっしゃるいらっしゃるようだ。関東を中心に何件か演奏会をやるらしい。
教会の少年合唱団あがりということで、キングス系？という声も。バンキエーリとかとは違うのかなぁ。
スケジュールは11/26,27,28,29。ちょっと行ってみたい。

○
以前、Rockapellaが来たおされな六本木のビルボードでTake 6がくるらしい。
1/24〜27って、無理だろうなぁ……。色々な意味で。

—-081031追記
どうやら、iGainをm4pにかけると-100%にされて文字化けしてしまっているのがダメらしい。納得。

買ってしまった

Tue, 28 Oct 2008 14:52:46 -0700

/ マランツ・スーパースコープ
ISBN : B000WM8KPI
スコア選択: ※※※※※

糞耳かもしれない自分がちょっと背伸びをして買ってしまった。

いや、いい音だってのはわかるよ。とっても。今までの環境からしたら音の密度が全然違う。トリオのJazzなんか、ライブハウスで聴いているみたいな生々しさ。

ちまたで聴くような高音が刺さる感じもない、、、と思ったらプラネテスのCDでWonderful Lifeを聴いたら刺さった。。。。このプレーヤーでアニソン聴くなと言われそうだが、Outside atmosphereやJupiter highwayを聴きたかっただけなんだ。

というわけで、やっとHD650が本気を出してクラシックやジャズを再生できる環境が整いました。無論、合唱やアカペラも良い感じです。

ちなみに、現在の構成は
SA-15S1→HD53R Ver.8→HD650,HD555,K240S,HFI-700です。
HD555とHFI-700はまだ試してないや。

SINGS 2008 with Steve Dobrogosz

Tue, 28 Oct 2008 14:51:21 -0700

少し遅くなりましたが、に行ってきました。
結論から言うと、とても素晴らしかったです。すべてのステージが、Dobrogoszを愛してやまないんだということがひしひしと伝わってきました。たまに、(女声に)プロが混じっているんじゃないかという場面もあったのですが、どちらかというとそれは曲に浸りすぎてしまいたがが外れたという感じでした。全体的に明るく軽やかな声で日本独特の重さ、しつこさといった要素が徹底的に排除されていました。だからこそ、Dobrogoszの曲にマッチしていたんだとも思いました。

特筆すべきは2st。会場に浮き上がるように一本のライトで演出された氏のピアノでの即興ソロもとても印象的でした。「会場の雰囲気を感じて演奏してください」という言葉がとても現れていました。
氏の曲はピアノなのに歌いたがっているように感じました。特に言葉に対して忠実に、というと変かもしれませんが、言葉のアクセント感、リズム感、響きをピアノで表現しているように受け取りました。合唱曲においても作曲者の意図が良く伝わってきて、良かったと思います。Lord I’m Freeや、Zakuroなど明るく楽しい曲が特に素敵でした。ゴスペルもそこまで乱暴な演奏ではなく(それに比べるとオフィシャルのMP3の何という荒いこと！）、World Youth Choirの様な印象すら受けました。この演奏会のCDが出たら間違いなく買います。というか、音源が欲しいです。

総じて素晴らしい演奏会でした。機会があれば参加してみたいです、SINGS。

うつくしい子ども

Tue, 28 Oct 2008 14:48:47 -0700

石田衣良の「うつくしい子ども」です。

石田衣良 / / 文藝春秋
スコア選択: ★★★★

また石田衣良を掴まされてしまいました(ほめ言葉)

途中で気になって確認したのですが、1999年に書き上げられています。このあたりの時代って、自分が高校生になった頃で結構少年犯罪がどうのという話が取り上げられてしばらくした後というような印象です。
ちなみに、読んでて気持ち悪くなったり胸くそ悪くなったりするので、僕みたいに小説に癒しを求める人にはお勧めできません。主人公は猟奇的殺人犯の兄。そして、もう一人の主人公は新聞記者。二人の視点から、「何故、主人公の弟は犯行に至ったか」を追いかけていきます。
相変わらず石田衣良は、読者をはらはらさせて次を読ませて、カタルシスへと駆け抜けさせるのが得意だなぁと言う印象。しかし、それと平行して犯罪者の家族に向けられる牙を疑似体験させられました。
最近、揚げ足取りのようにマスコミが叩く風潮から、Webでのコメント(2chやブックマークを含む)での追求がなされるフェーズへと移ってきたように感じます。従来の、一辺倒な報道からの情報に比べれば、はてブやブログで得られる多面的な背景は読んでいて考えさせられることが増えましたが、脊髄反射的に正義のコメントを展開する姿はある種滑稽にも思えます。いや、なんか見てると、言いたいことはわかるんだが本末転倒というか、本当に子どもを心配する気持ちを利用した方が弾劾されてしかるべきなのに、反射的な反応は考え物だなと思った次第です。想像力の欠如とかなんとかよく言われている言葉にするとチープなんだけれど、もう少し人に優しい世の中にならないのかなぁ。

閑話休題。センセーショナルな題材(恐らく当時、そして今も)であることに目を奪われてしまうかもしれませんが、そこを描きつつも問いかけられるメッセージが何だったのかを受け止めたいと思います。

でも、二回目は読みたくない本です。食欲がなくなるので……。

3年で辞めた若者はどこへ行ったのか？

Tue, 28 Oct 2008 14:48:41 -0700

城繁幸 / / 筑摩書房
ISBN : 4480064141
スコア選択: ※※

タイトル詐欺。中身は筆者の言いたいことが詰まっていて、その裏付けに様々な人の言葉たちが使われているだけ。Amazonでそのような言葉を読んだが、まさしくその通り。
後書きを買う前に読むべき。そこに筆者の主張が詰まっているから。別に建設的でないとは言わないけれども。

リーマンショックを経た今、投資銀行へつとめている人がどうなったか、もう一度筆者にリポートをお願いしたい。その上で、アメリカ中心のシステムにそった形が良いのかというのをもう一度検証していただきたい。

確かに民主、社会、共産、マスコミ批判はわかりやすいが今更感も。そして、繰り返される昭和→平成の主張は何か論拠が薄い。いつもこの手の本を読んで思うのが、文系の人は何故こんなに転職や残業超過について言及するのが好きなのだろう。(こう考えてしまうのは典型的二本の理系なのかもしれないが)、自分の研究室での経験からすると残業代がでる残業は幸せなのではないかと思う。給料がもらえるんだから。それより多い時間を費やしてただ働きしている理系学生の多さを考えたら、就職して楽になったという事例も結構あるんじゃないかと思う。
是非ともこうした無茶な労働時間を平気でこなすことを要求する日本の理系研究室に対してメスを入れて欲しい。というか、それをやらないと、残業当たり前の感覚は抜けないのではないかと思う。
また、転職のリスクというものは存在しないのだろうか？それを伝えずして転職をオススメするのはあまり感心しない。まだ、勝間和代の転職活動をしても食いっぱぐれない様に運用をって話のほうが親切に聞こえる。

ちなみに、就職率の酷いグラフの比較(2〜8％の差に有意差が見いだせるのだろうか？)や、ベースラインを明らかにしない割合の比較など、ミスリーディングを誘ったり誇張をしている場面が見られるのが残念で仕方ない。
前作はもっと素直に読めたのに。

JPOPサウンドの核心部分が、実は１つのコード進行で出来ていた

Sat, 18 Oct 2008 20:10:00 -0700

をやっと読んだ。というか見た。
なるほどなー、と感心する反面どうもTommorow never knowsにしか聞こえない罠。

まぁ、投稿者の方の主張している理由というのが

「メジャーとマイナーの中間を漂う浮遊感」

というのには、納得です。
割と曲を作っていると、メジャーだかマイナーだかわからないけど、とにかく使いたいコードを使っちまえっていうのはあると思うんですよね。そして、それが耳なじみよければOK、となると良く聴いた曲の進行になってしまいがちになるのも頷けます。

個人的には、民族チックな和音やらメロディのほうが好きなので、ふーんで終わりますが。

楽譜が欲しい

Fri, 10 Oct 2008 20:10:00 -0700

出版されている物を、取り寄せるのは比較的なんとかなるとわかりました。
今欲しいのは、。Dulamanが歌いたいわー。

でも、もっと歌いたいのは未出版のものがほとんど。採譜できる自信がないので、オリジナルの方々に英語で問い合わせてみるしかないのかなぁー……。
でも、SuomiとかSwedishとか無理ぽ……。

しっかし、前から思うのが自分が求めるアカペラ情報って、結構ネットに分散していてまとまってるところないのね。ちょこちょこ集めていくしかないかなぁ。

落語百選　夏

Fri, 10 Oct 2008 14:48:57 -0700

/ 筑摩書房
ISBN : 4480034528
スコア選択: ※※※※※

落語を読むのは(聞くのも含めて)本書が初めてであった。それまでは、何とも言えない距離を感じていたのは事実である。「きっとわからないだろう」とか、「現代の話でも面白いんじゃない」とかいう具合に。元々時代物のお話も得意なほうじゃあなかったのもある。

本書は、そんなことはどうでも良くて楽しめる本である。人々の日常の中から面白いことをちょっと誇張して切り取ってきた、という漢字である。本の中には、誰かを貶めるような話はまずない。最近のメディアから垂れ流されてくる人を小馬鹿にしたような笑いとは一線を画す。というか、本来何かを見下したものは笑いではないのだろう。

閑話休題。とにかく、笑いの中にも人々の息づかいや心配りが感じられて、気楽にしかし楽しく読める。オススメ。

ちいさなちいさな王様

Fri, 10 Oct 2008 14:48:52 -0700

アクセルハッケ / / 講談社
ISBN : 4062083736
スコア選択: ※※※※

話もシュールなら絵もシュール。でも、何故かそれが落ち着く本です。

お話としては、年を重ねるごとに体が小さくなっていき物を忘れてしまう世界の王様が、偉そうに色々なことを主人公に言ってきます。しかし、その王様の一言一言がなんというか思慮に溢れていて、深いのです。

最初ゾーヴァの絵だけを見たときには、シュールだなとしか思わなかったのですが、アクセル・ハッケの文章を読むと納得、いやそれ以上のものをゾーヴァの絵は与えてくれました。プードル救い機の絵は感激です。

勝間和代のビジネス頭を創る7つのフレームワーク力ビジネス思考法の基本と実践

Sun, 05 Oct 2008 05:10:01 -0700

勝間和代 / / ディスカヴァー・トゥエンティワン
ISBN : 4887596391
スコア選択: ※※※※

大分前に読んだので、うろ覚えになっているが一応読了したので書いておく。

話の中身としては、PDCAだとか水平思考力だとか良く聞くような話を体系的にまとめて説明してくれている。著者の本は二冊目だが、説得力を感じるし何より読者がいかにしたら受け入れてくれるのか、という点を強く意識して書かれているため、受け入れやすい。

何点をあげるとしたら、著者の本を色々追っかけてきた人にとっては良いのかもしれないが、そうではない人にとっては「拙著○○を参照されたい」というのはどこの論文だよ、と思ってしまった。これが論文のようなPublicな文章なら比較的後々も入手容易であると考えられるが、本というのは生ものであるので長期的に販売され続けるという前提が成り立つのか疑問に思う。そういう意味からも、他書を見て欲しいというのは、わかるのだが3行で要点を書いて欲しかった。

色々とどういう構造で成り立っているかを分析するのに参考になる点は多いので、おすすめです。

しかし、この本が書かれた頃のはてなは、もうちょっと穏やかだったのでしょうか。最近チェックしだしたので、あまりわからないのですが。色々とおすすめの本などが拾えたので重宝していました。ちょっと前までは。

＊追記
後ろにあった参考文献を今気づいた。これは良い。表紙を付けて載せてあるので書店等でも探しやすい。

HD53R Ver.8を購入

Sun, 05 Oct 2008 05:10:00 -0700

2chではとことん評判のよろしくないC.E.Cのを購入しました。
しかし、JBLのReference410といい、今のマシンの電源といい（ｒｙ

で、購入したきっかけはULTRASONEのHFI-700をROCKとPops用に購入したのですが、その際にフジヤエービックで使われていたアンプがこの子でした。(ちなみに、上流はマランツのだったはず)
そこで、聞き比べたのがiPodとHD53R越しの音とSA7001越しの音。まぁ、当たり前かもしれないけれど一番重みがある音に感じられたのがHD53R越しの音だったわけですね。で、家でもこの環境が良いなぁと思い購入しました。
まぁ、アンプなしからありにしたらそりゃ良くなるわけです。
もう一つの理由が、彼女と一緒にヘッドホンで鑑賞したいと思ったときに、インピーダンス等々の関係で2個ボリュームが調整できる方が良かったわけです。もう生産終了したということでこの子に決定しました。

で、帰ってから自宅のCDPlayer(といってもラジカセみたいな子なんですけど)にはRCAのAUX-InはあってもOutがないことが発覚。現在、tokyostyleのS010から出力して聞いています……。こりゃ次はDACかな。ONKYOのSE-200PCI LTDはなんだかんだでそこそこらしいし。
ちなみに、参考にしてしまったしたのは某ちらしの裏です。んまぁ、自分で納得した上で買ってるからいいんだけどね。

肝心のノイズ周りと音はというと、ノイズは奇跡的にガリノイズもギャングエラーもありませんでした！！すげー。で、現在20時間くらいしかエージングしてないですが、音はS010直やDenDACよりも低域が密度が高くなった気がします。確かに、ロックとかJ-Popを聴くのには良いかな。HFI-700が楽しくなりました。で、合唱やアカペラはというとアカペラ曲は良い感じです。Rajaton素敵。合唱はというとAllegriのMiserereとかちょっとすっきりしすぎかなという印象がぬぐえません。硬質な音と言えばそうなのかも。
しばらくは、この子で頑張っていこうと思います。

パーフェクトブルー読了

Wed, 01 Oct 2008 18:10:00 -0700

宮部みゆき / / 東京創元社
ISBN : 4488411010
スコア選択: ※※※※
最初、恵比寿の有隣堂で何の気なしに付けて貰ったブックカバー。いつもはあまり気にもとめない爽やかすぎる青。店員さんがブックカバーを付けるときに「色と本の指定はありますか？」と聞かれたのですが、店員さんにお任せをしました。
読み終わって納得。これがパーフェクトブルーの色だったのね。

東野圭吾と森博嗣しかミステリーは読んだことなかったのですが、きっとこれが王道なんだろうなという伏線の張り方、回収の仕方。どんどん引き込まれます。最後の結末も(可能性は考えなくもないが)、まさかという展開。でも、読後感がすっきりしないかな。感情移入すればするほど、辛くなってしまう。
読んで損はないとは思いますが二回目を読もうとは思わないです。。

フジヤエービック行ってきました

Sat, 27 Sep 2008 23:09:00 -0700

B'zのUltra treasureがやばすぎる

Sat, 27 Sep 2008 17:09:00 -0700

B’zのUltra treasureの選曲がやばすぎです。

B’z / / VERMILLION RECORDS(J)(M)
ISBN : B001CRGVAS
スコア選択: ※※※※※

選曲が素晴らしすぎる。どうせファン投票で入る曲なんて、しっとりじめじめバラードで埋め尽くされるんだろう、とか高をくくっていたら、違う違う。

まさか、F・E・A・Rが入ってくるとは！Homeもだし！！素晴らしいの一言。ファンなら是非。Ultra pleasureは無くてもいいかもしれんけど、こちらは手元に置いておくべきです。

しかも、一緒に着いてくるライブDVDが熱い！これはDVDまであわせて一つの作品ととらえるしか。ライブ行きたくなってしまいました。

ヘッドホン物色したひ

Sun, 14 Sep 2008 14:52:57 -0700

J-POPやROCKが聞けるヘッドホンが欲しくなってきたので、メモメモ。

最初は、Sennheiserのにしようかと思ったのですが、思った以上に低音がもこもこしてて断念。きっと、電車とかで聞くのにはいいのかもしれないんでしょうけど、それならEP-630やらReference410で十分なんですよね。

で、大須のノムラ無線にて勧められたのが、。最初は、DENONでJ-POP？とか思ったんですが、意外とあうんだなぁ。無難な音という評価はよくありますが、やっぱり全体のバランスが大事なのかなぁと思った次第です。
でも、これを買うことを決定する前にヘッドホンアンプを買うか、GRADOやらbeyer dynamicの子を視聴してみたいなぁと思う次第です。

エンジェル・ハート(27)

Wed, 10 Sep 2008 14:49:13 -0700

北条司 / / 新潮社
ISBN : 4107714209
スコア選択: ※※※※※

やばいなぁ。北条司はこういう泣かせる話描かせたら天下一品だなぁ。

任務故に家族と生き別れた、老人のお話。展開としては何も目新しいことはない。でも、そのべたかもしれないけれども、一つ一つのキャラクターの行動、その描写にぐっと来てしまう。

今回は買って良かった巻だ。売るのかと思うと……。ま、それはそれか。

Luck Stealer (2)

Mon, 08 Sep 2008 14:49:19 -0700

かずはじめ / / 集英社
スコア選択: ★★★

運を盗んで人を殺す。殺人鬼のお話。
シリアスなようでシリアスじゃない展開がもどかしい。なんというか、鬼気迫る感じがほとんどないんだよなぁ、今回。お話を淡々と進めていく感じ。猟奇的な教師も出てきたし、お膳立てはしているはずなのに、迫力というか迫ってくることがない。
なぜだろう。ちょっと残念。

残業ゼロの仕事力読了

Mon, 08 Sep 2008 05:09:00 -0700

吉越浩一郎 / / 日本能率協会マネジメント出版情報事業
ISBN : 4820717138
スコア選択: ※※

著者は幸せな、そして特殊な世界に生きてきたのだと理解。
典型的理系大学院を通ってきた自分には、受け入れられない言葉が多い。彼は一度日本の理系大学院を指弾して欲しい。サービス残業とボランティアでできている、研究室という存在が、日本の理系を残業好きにしている。だって、企業で働く方が楽で金も貰えるんだもの。

“残業をしない方が良いに決まってるでしょ。“それこそ、自明と言わずにロジカルにつめるべき話ではなかろうか。そして、ロジカルシンキングをうたっておきながら、本書の構成の無駄の多いこと。何が本質かぼやけてしまう。同じ様なことをなんどもくどくど書いてある。これが、ロジカルシンキング？

書いてある中身は、参考にしようと思うこともそれなりにあった。長時間労働するより密度を上げろ、というのは素晴らしい。ただ、素晴らしい考え方ではあるものの、前提として役職のある人間にしか通用しないテクニックの連発のようだ。というか、平の自分には関係ないね、と思ってしまう。
なんか、文章からは「俺は実績あるんだぜ」以上のものが感じられず、敵を不必要に作っている気がする。センセーショナルな文章でなぇれば人の心に残らないのだろうか。

正直、本に書いてあることが読者の受け取れる全てなはずなのに、本書以外の経験を主張されてもなんだかなぁという印象。
へー、あなたは凄いんですね。結果も残しましたね、ワンマン社長。

初音ミクのカラオケ曲

Sun, 07 Sep 2008 05:09:00 -0700

JOY SOUNDならなんとかしてくれるはず！と信じて、初音ミクで検索しても二曲しか出なかった。

それも当然のはず。

初音ミクはアーティスト名として登録されていないのだ。普通のJ-POPだと、歌い手の名前で登録するよねー。でも、作曲者の方が中心だからかなぁ。
覚えて次歌いに行くかなぁ。メルトが無いのが残念無念。

風が強く吹いている

Sat, 06 Sep 2008 14:49:29 -0700

三浦しをん / / 新潮社
ISBN : 4104541044
スコア選択: ※※※※※

正直、スポーツものって縁がなかったのです。自分が運動できないから。

でも、それを補ってあまりある心惹かれる文章です。とても、おすすめ。何が良いかというと、読み始めると物語のキャラクターが自分で一人歩きし出すんですね。何か伏線がはってあるというよりも、こいつはこういう行動をとるだろう、という展開です。でも、それがうれしい。

神童のゴールの瞬間がたまりません。思わず朝の通勤で涙してしまいました。

毛嫌いせずに是非読んで欲しいです。少し分厚いですが、逆にそれがトレーニングのつもりで共感できました。

機動戦士ガンダムTHE ORIGIN　16 17

Thu, 04 Sep 2008 14:49:35 -0700

安彦良和 / / 角川書店
ISBN : 4047139874
スコア選択: ※※※※

マクベの散り方が割とあっさり。

オリジナルのTV版では、もう少しねちっこい奴だったと思うが。エノラゲイについての話を引き合いに出した、核爆弾を投げに来た兵士の話には少し残念な気分になった。そこまでピンポイントにする必要はないんではないの？後々の話では核は非常に重要な存在とされているのに、今回は少し軽々しい感じがしました。

安彦良和 / / 角川グループパブリッシング
ISBN : 4047150754
スコア選択: ※※※※

大佐が女たらしなのがわかる瞬間。

みらいのフィアンセが格好良くなってる。素晴らしい。そして、アムロ父って最後に亡くなられたっけ？

基本的に、面白いんだけど、オリジナル版でも問題ないんだよなぁ。

TRY-TONEスペシャルライブ〜　アカペラ夏唄2008　〜

Sun, 31 Aug 2008 14:51:54 -0700

渋谷にあるライブハウス「」にて行われたTRY-TONEのライブに行ってきました。多作というかライブハウス自体が初めての体験だったので、開場時間に少し遅れて行ったらすでにたくさん並んでいました。しかも、周りの方々が「今日はアカペラグループ皆で来ましたー」とか言ってるのを聞いて、一人でやりおるわぁとニヤニヤしていました。さすが、アカペラメインのライブハウスだなぁと。

で、遅れていったからには当然というかライブハウスの規模を舐めていて、友人と離れた席になってしまいました。そうなのかー、35人くらいしか入らないのね。きっついわ。でも、その狭さのおかげか2列目というか2mくらいの近さでメンバーの方々と対面できました。いやはや、浴衣での演奏に感激です。正直、ゆかたは一度着ただけなのですが、歌うのには適さない服だなぁと思っていたので……。しかも、男性陣はちゃんとした下駄で歌っているという！！いやぁ、下駄でリズムをとる青木さんに尊敬の眼差しを送っていました。

曲目は、、、あっという間に通り過ぎてしまったのでキチンと拾い切れてないですが、前回名古屋で聞いたのとは全然違って、新旧色々な曲（今回のためのアレンジも含んだメドレーもあるとか）を楽しめたのが良かったです。「夏」をテーマにした曲で固めていたのですが、どれも素敵な曲でした。実は、あまり全部を拾うほど聞き込んでいなかったのですが、秋田音頭が聞けたのはとても印象的でした。そして、会場と一緒になってソーラン節を歌ったのは、とても盛り上がりました。良くある会場との歌のやりとりを経て、会場のレベルが高いことを認識した多湖兄さんと、会場を二分したメンバーで「ヤーレン」「ソーラン」の応酬が。楽しいわぁ。

男性陣のTokyo Los Angelsの面々による懐メロメドレーは最高に面白かったです。胸がキュンキュンキュンとか真顔でやられるなんて、たまりません（笑）ちなみに、Trio Los Amigosというラテン曲のユニットとして活躍しているみたいなのですが、TLAの略称を募集しているらしいです。会場で考えてたときにはThree Love Affairsという酷い名前しか思い浮かびませんでした。。。名前付けのセンスないのよね。

最後に、青木さんに低音を出すこつを教えていただき、多湖さんの口トランペット講座を立ち聞きして、写真も撮っていただきました。うれしいわー。デジカメ持って行けばよかったかも。

帰りに「冬彦さんを知らないの？」と友人に怒られてしまったのは、ここだけの話（笑）また是非行きたいライブでした。10月にもいっちゃうぜ。

知らなかった、youtubeが貼り付けられるなんて

Sun, 31 Aug 2008 00:08:00 -0700

やっとかよー。テストテスト。

というわけで、某あかぺら村よりThe　Real Groupのアカペラマシーンと教授の歌を転載。

あー、あとで昨日のTRY-TONEのライブのレポをしようかと思います。口トランペットの音の出し方講座を終わった後の観客とメンバーのトークの中で聞けました♪
言葉ではよーかかんですけどね。
また、後ほど。

アキハバラ＠DEEP

Tue, 26 Aug 2008 14:49:40 -0700

石田衣良 / / 文藝春秋
ISBN : 4167174111
スコア選択: ※※※※※

まず、今まで石田衣良を舐めていた。

プロローグで描写される秋葉原は、少し古くさい要素はあるにしろ、素晴らしい。ただの、はやりに乗っただけかと思っていたが、そうでもない。むしろ詳しすぎる。熱収縮チューブなんて一般人しらないよ。

話としては、以前も書いたかもしれないが、キャラクターが非常に生きている。まず、開始直後に事故死してしまうユイさんは言葉が重い。詳細は以前書いた日記を参照して頂きたいが、コンプレックスを感じるすべての人に届いて欲しい。

そして、コンプレックスといえば、ページとタイコの二人が誘拐されたときの取った行動が素晴らしすぎる。普通は、吃音などという要素は憐れみの対象であれ、武器になるということはないだろう。そこで、作者はこれらのWeekPointを武器にかえてしまった。

少しまどろっこしい部分もあるかもしれないが、基本的に勧善懲悪（クルークが善悪かはわからないが）ものであるので、すっきりとした読後感である。秋葉原という単語に反応してしまうデジタル好きなら読んでみると良いかもしれない。

サヨナライツカ

Sun, 24 Aug 2008 14:49:45 -0700

辻仁成 / / 幻冬舎
ISBN : 434440257X
スコア選択: ※※※※※

「人間は死ぬとき、愛されたことを思い出すヒトと愛したことを思い出すヒトにわかれる。私はきっと愛したことを思い出す。」

2部構成の意味が最初はわからなかったのですが、最後まで読んでみて納得。1部は最初、情熱的な浮気の描写に辟易していたのですが、2部の終わりの沓子が亡くなるところですべてが繋がり思わず涙。

良い作品です。

のだめ21巻

Mon, 11 Aug 2008 14:49:56 -0700

二ノ宮知子 / / 講談社
ISBN : 4063407128
スコア選択: ※※※※

衝撃の展開。のだめご乱心。

以下ネタバレ含みます。

なんというか、ついに千秋と一夜を共に過ごしました。どん引きです。で、その翌朝結婚を申し込んでスルーされました。どん引きです。さらに、その後シュトレーゼマンに誑かされます。どん引きです。

でも、続きが気になっちゃいます。

面白いほどよく分かる哲学・思想のすべて

Mon, 11 Aug 2008 14:49:50 -0700

湯浅赳男 / / 日本文芸社
ISBN : 4537255889
スコア選択: ※

これは酷い。哲学思想じゃあないだろう。本書の構成としてはキーワードと重要人物の名前と、その学歴が主となっている。だからなんだと。

まったく何も知らない人ならば、へーと思って読めるのかもしれないが、少しでも知っていると「で、この思想家が言いたかったのは何なの？」という具合に疑問に思ってしまう。後、まったく解説のない単語を「ちなみに」という言い回しで書くのはやめて欲しい。知ってる人はこんな本読まないでしょ。知らない人は意味が分からないでしょ。ロジカルに考えたら、無駄が多すぎる。しかも、どう考えても本質は書いてない。本文と全く同じことを図にしてスペースを稼ぐのも酷い。どこのB4の研究会の予稿第一稿だよ。

筆者の意見なんかや経済の話を読むより、思想家の唱えていることの中身について知りたいんだから。比重おかしいでしょ。

倫理の教科書と一緒に使う山川の単語集なんかの方がよっぽど役に立つ。

Ono Lisa best 2002-2006

Fri, 01 Aug 2008 14:52:09 -0700

小野リサ / / EMIミュージック・ジャパン
スコア選択: ★★★★

どこかで聞いたことある曲も、そうじゃない曲もいろいろつまってます。
ぼーっと聞きたいときにいやされる感じです。

素敵なCDです。でも、電車に乗りながら聞くと寝過ごすので注意（笑）

なるたる

Wed, 30 Jul 2008 14:50:01 -0700

鬼頭莫宏 / / 講談社
ISBN : 4063141861
スコア選択: ※※※※※

ハートフルボッコアニメ、と呼ばれた同名のアニメの原作。グロい。残酷。人は何故ここまで残酷なことが考えつくのだろうか。

でも、その分味があって良い。メッセージというよりもガツンと目を覚まさせてくれる作品。

でも、万人にはお勧めしない。ぼくらのよりハードルが高い。日乃レポートが出たときは、なんと！！！と驚きを隠せなかったが、よくよく考えてみると滅びた後にあそこまで復旧したのはありえないんだろうな。

合唱団お江戸コラリアーず第7回演奏会

Sun, 20 Jul 2008 14:52:15 -0700

良い演奏会でした。男声合唱に対するイメージが良い意味で変化しました。
細々と書いていくとあれなので、簡単に。

1stのVictoriaは、最初のステージとは思えない立ち上がりでした。
柔らかくステージを包み込む和音が広がります。

2stの新しい歌は、初めて良い演奏にありつけた気がします。
この曲は、若さが必要です。それと同時に演奏のレベルとクオリティも求められます。
そう言う意味では、ちょうどいいバランスの上に成り立っていました。心がうきうき踊るステージでした。
で、信長先生がステージにたって挨拶後は、アンコールインターミッションとしてトトロを歌っていました。この間TVでやっていたようで、良かったんじゃないですかね。一人ノリノリ過ぎてヘドバンしてた人が居たのが気になりました（笑）

3st。Tormisがうれしすぎる。この暗い感じがたまんねぇっ！
タダタケの鮪組からThe Drunken Sailorへの小芝居うまいことつないだなという感じでした。
ただ、このステージ重すぎやしませんか（苦笑）

4st。寺嶋陸也氏のピアノが上手すぎる。伴奏として合唱団を引き立てながらも、主張する。
かっこいいねぇ。それまで伴奏がボケボケな感があったのが、急にシャープになったようでした。
「生きる」は、素晴らしいの一言に尽きます。いや、いつも混声だと感情的に、ともすればヒステリックな高ぶりを聞いていたので、落ち着いたというか内面からわき起こる感情に心を打たれました。

概して良い演奏会でした。また行きたい。

演奏曲目の詳細は続きに書きます。

【1st Stage】聖週間の応唱集より　作曲：Tomas Luis de Victoria 　指揮：山脇卓也・Iudas mercator pessimus（恥知らずの商人ユダは）・Tenebrae factae sunt（暗闇となりぬ）・O vos omnes（おお　汝らすべての人よ）

【2nd Stage】男声合唱とピアノのための「新しい歌」(2台ピアノ版) 作曲：信長貴富　指揮：山脇卓也　ピアノ：斎木ユリ須永真美

～ intermission ～「となりのトトロ」編曲：信長貴富

【3rd Stage】海のア・ラ・カルト・Gryning vid havet （海の夜明け）作曲：Hugo Alfven ・Muistse mere laulud （古代の海の歌）作曲：Veljo Tormis ・内なる怪魚シーラカンス作曲：廣瀬量平・鮪組作曲：多田武彦・THE DRUNKEN SAILOR(酔いどれ水夫)　編曲：Robert Sund 　指揮：山脇卓也　村田雅之　ピアノ：村田雅之

【4th Stage】二群の男声合唱とピアノのための「路標のうた」作詩：木島始　作曲：三善晃 -ピアノのための無窮連祷による-「生きる」＊作詩：谷川俊太郎　作曲：三善晃　指揮：栗山文昭(客演)　ピアノ：寺嶋陸也　＊作曲者の許諾のもと、女声版楽譜を使用して演奏いたします。

がばいばあちゃん佐賀から広島へめざせ甲子園

Sun, 20 Jul 2008 14:50:06 -0700

島田洋七 / / 集英社
ISBN : 4087461963
スコア選択: ※※※

一番有名な、がばいばあちゃんを読んでから二冊目として手に取った。でも、どうやらこの本は先に一人で文庫化されていたらしい。そういうときの新規読者のためのわざとらしい説明がたっぷり含まれていた。

こちとら、一冊読んでその中で生きるものがあったから、新しいことがあるのかな、と思って手に取ったこともあって、焼き直しの部分が3，4割程度あるのは残念だった。

初めて読むのなら、ありかもしれない。要点となるエピソードも抜粋されているし、読みやすい。ただ、文章量が薄いのですぐ読めるのがうれしい人でなければ、あまりおすすめしない。

さっとがばいばあちゃんのことを追いかけたい人向け。でも、一作目が一番エピソードに溢れていてよかったかなぁ。

EnsembleNow 第39回定期演奏会＠セシオン杉並

Sat, 19 Jul 2008 14:52:20 -0700

Bustoの作品を聞きたいと思い行ってきました。
といっても、ぼけーっとケーキを食べていたら少し遅れてしまいました(^_;

曲目はを参照してくださればと思います。
Joseph fill Davidは懐かしかった。でも、全体的に内声がとけない感じだったので、
あまりBustoには向いているとは思いませんでした。残念。
自分がやったことがある曲だと、色々粗がわかるよね。
後、宗教曲はそれなりに信仰のある人かそれに準ずる知識を持つ人がやらないと駄目かな、と思いました。
なんというか、薄っぺらく感じてしまうんですよね。特に曲の変わった雰囲気で攻める変態なやつ（Jaakko MäntyjärviとかCayabyabとか）じゃない限りは、そこに存在する空気感みたいなのが必要になってくるんじゃないかと思うわけです。
その源は、何か。世界観の根本は何かってのを考えてしまいました。

ちなみに、Bustoに五柳五酒に……という時点で、予想していたのですが、やはり三善の方が会う団体でした。割とアバウトなんだけどスケール感で攻めるというかんじですね。
久石譲のScarborough Fairの合唱編曲は楽しかったです。歌ってみたい。
そして、Bob ChilcotのEvery time I feel the spiritも良かった。
ノリの良い曲の方があう団体でした。

「残暑」鬼頭莫宏

Sat, 19 Jul 2008 14:50:12 -0700

鬼頭莫宏 / / 小学館
ISBN : 4091885012
スコア選択: ※※※※

なんて爽やかな作品なのだろう。鬼頭の作品とは思えない。でも、その中に何故かもの悲しさが存在する気がしてならない。
氏独特の鬱展開を期待している人には物足りないかもしれないが、氏の独特な世界観が好きな人は良いのかもしれない。この先、この人が描く作品が気になってしまう。

西の魔女が死んだ

Fri, 18 Jul 2008 20:07:00 -0700

梨木香歩 / / 新潮社
ISBN : 4101253323
スコア選択: ※※

「アイ・ノウ」おばあちゃんの人柄の良さが伝わってきます。のんびり読むのにはちょうど良い作品。地の文が主人公の女の子目線なので、そこまで激情にほだされないのが良いのかもしれません。
ただ、その分感情移入もしづらく、色々な謎を残したまま終わってしまった感がぬぐえません。何で流行ってるんだろう。

Rockapella Channel

Wed, 16 Jul 2008 14:52:25 -0700

なるものがありました。
この、プロモが素敵すぎます！

今から楽しみやわぁー。まってろよ、Tokyo billboard！

クピドの悪戯虹玉、おいしいコーヒーの入れ方夢のあとさき

Tue, 15 Jul 2008 14:50:23 -0700

村山由佳 / / 集英社
ISBN : 4087463036
スコア選択: ※※※

ついに、おいしいコーヒーシリーズの完結です。といっても、1stシーズンですが。中身はいつもながらの安心して読める内容となっています。刺激はそこまで強くないです。ただ、いつもながら男性視点の葛藤を女性の作者が描写できる不思議。自分の中にあるドロドロを湧き起こしたい人にはお勧めかもしれません。

終わりにはあまり納得がいかないかもしれませんが、これは2ndシーズンへの布石でしょう。

北崎拓 / / 小学館
ISBN : 4091532012
スコア選択: ※※※※※

生々しい恋愛模様が良いですね。男の欲望とかむき出しで。でも、女の欲望も出ているのが新鮮です。特に、桐生麻美が良い味出してます。噛ませ犬っぽいのにそうでもない。ぼかぁ桐生麻美の方が好きです。こういう恵まれないヒロイン、好きなんだよなぁ。

狼と香辛料（1）

Sun, 13 Jul 2008 14:50:28 -0700

支倉凍砂 / / メディアワークス
ISBN : 4840233020
スコア選択: ※※※※

色々なライトノベルを読んだ結果、自分の趣向に関して得た事実が二つ。

・頭の悪い文章は読む気がしない。

・妙にインテリぶって、非常用漢字や漢字にフリガナふりまくる文章は嫌だ。

そう言う意味ではどちらにも属さず、それでいて話に引き込まれる作品でした。

劇的な刺激はあまりありませんが、手順を踏んで一つずつ進んでいく感じが安心して読めます。世界観がしっかりしているんでしょうね。続きが気になる作品です。

Ris a la malta

Thu, 10 Jul 2008 14:52:31 -0700

に行ってきます。
1ドリンク飲みながらってことは、結構狭めの小屋なんだろうなぁ。今からわくわくですよ。
青木さんのプリチーさをもう一度見ねば！！

にも行きたいのですが、土曜日の1stライブの自由席は完売とな。。。
むぅぅ、やりおるわぁ。

BGM:The Real Group “Substitute For Life”

PRESS　START当選しました

Wed, 09 Jul 2008 14:52:36 -0700

以前言っていたに当選しました。いやっほぅぅぅぅ！

これで、オーチャードホールが堪能できるぜ！ゲーム音楽を生で聴くのは久々なので楽しみですわ。

The Real Group - Real Christmas, Commonly unique

Mon, 07 Jul 2008 14:44:53 -0700

おいおい、書いていたら消えてたよ。
というわけで、書き直しです。

ザ・リアル・グループ / / スパイス・オブ・ライフ
スコア選択: ★★★★

楽しいアカペラグループのCDです。
聞いていて、うきうきするような曲がたくさん詰まっています。

ハーモニーも楽しければ、ノリもいいのです。ライブいきたいわぁ
Telepone Talkingが大好きです。

ザ・リアル・グループ / / スパイス・オブ・ライフ
スコア選択: ★★★★

なじみ深いChristmas Songをアカペラアレンジしたものから、かの国の曲まで。あー、Jul, julってこんな曲だったんだね。のーんびりしたいときに聞くのが良いと思います。
るどるふー、大好きだー

のだめカンタービレ18〜20

Sat, 05 Jul 2008 18:07:01 -0700

二ノ宮知子 / / 講談社
ISBN : 4063406482
スコア選択: ※※※※※

おもすれー。

テルミン演奏するとか、すげーと思うよ。そして、フランクの立ち位置と気持ちの変化が、素朴にいいなぁと思います。

二ノ宮知子 / / 講談社
ISBN : 4063406733
スコア選択: ※※※※※

この巻から、各地のピンクっぷりが振りまかれるのですが、何故だろう。あんまり、いやらしくないのは。

それぞれ目的を持っていて、それに向かって邁進しているのがいいんでしょうね。

妄想の中で、裏軒にてはたらくキヨラは笑えましたけど（笑）

二ノ宮知子 / / 講談社
ISBN : 4063406911
スコア選択: ※※※※※

そして、最新刊。

のだめを取り巻く環境が変わっていきます。いや、周りののだめに対する意識が明らかになっていくというところか。

本人は自分の才能を疑いもしない、のだろうか、自分の実力に気づきもしないのだろうか。とかく周りとの溝を感じてしまうのだめですが、凡人からしてしまうとうらやましい悩みだとしか思わないんですよね。

でも、物語の展開の仕方はさすがといったところ。次が気になります。

三毛猫ホームズの恐怖館

Sat, 05 Jul 2008 18:07:00 -0700

赤川次郎 / / 角川書店
ISBN : 4041497876
スコア選択: ※※

初めての赤川次郎。友人に読みやすいと勧められて読みました。
読みやすいは読みやすいんだけど、印象に残らないというか、子供向けだなぁというのが印象でした。
後、文章が理解しづらい。描写に対して頭をうんうんうなって考えるのはあまりしたくない人間なので、ちと話の流れに飛躍があり理解できない箇所がいっぱいありました。
というか、最後のオチも唐突すぎて伏線たっぷりでスッキリしていない、というのが印象です。

同じ次郎なら、浅田次郎の方が向いてるんだろうなぁ

Rajaton

Sat, 05 Jul 2008 14:45:04 -0700

うひょ、こういう系統のアカペラはたまらんわぁ。
というわけで、という、フィンランドのアカペラグループの紹介です。
フィンランドってケルトだっけ？とか小難しいことはさておいて、でございます。
これは、amazonに直行せねば。
なんというか、民族的な和音がたまりません。確かに、メロディーの進行もケルティックなアーティストを彷彿とさせます。これは良い。

紹介してるブログの方は韓国までThe Real Groupと一緒にRajatonがでるというアカペラ祭りに行かれるそうですが、非常にうらやましい限り。お盆休み長めに取りたいなぁ〜。

新・萌えるヘッドホン読本

Wed, 25 Jun 2008 14:45:09 -0700

ついつい買ってしまいました。
アマゾンギフト券があったので、0円で買ってしまいました。

まだ、全然見てないんですけど、ヘッドホンインプレ本として買ったつもりです。詳しくはきっと後日。
Webで見るヘッドホン娘の絵とか、結構いいなと思うものもあったので受け取ったときは期待していたのですが、表紙を見て違和感。
中を開いて、、、

趣味の合う絵がないかもしれない。

というわけで、右半分のページだけ読もうかと思います。

ぼくらの〜alternative

Sun, 22 Jun 2008 14:44:25 -0700

大樹連司 / / 小学館
ISBN : 4094510753
スコア選択: ※※※※※

ハートフルぼっこな作品を書かせたら天下一品の、鬼頭莫宏の「ぼくらの」をノベライズした作品。その最終巻。
先に言っておくと、鬱漫画のノベライズです。取り扱い注意。
想像の斜め上を行ってくれる展開で、楽しめた。満足。
そして、最後の原作者との対談で「ノベライズに当たって、原作よりも酷い話を目指した」という、作者の言葉に納得。ですよねー。

その小説よりもえぐいという漫画版の最終回にも期待大。

鬼才現る

Sun, 15 Jun 2008 14:44:30 -0700

石田衣良 / / 集英社
ISBN : 4087474763
スコア選択: ※※※※※

日本人にしか書けないんじゃないか、と思わせる設定。

主人公は、幽霊。でも、現実を「生きている」。その「生」の喜びと死の理由を探していく。

読み終わった後に、強烈なショックを受ける本。そういう筋なのか。悲しみというより驚きと言うより、衝撃。

お金の勉強

Sat, 14 Jun 2008 22:06:00 -0700

勝間和代 / / 光文社
ISBN : 433403425X
スコア選択: ※※※※

金融に関する入門書の入門書として買いました。

本当に入り口の所ばかりみたいですが、比較的読みやすくわかりやすく書いてあります。

ただ、筆者の主張というか傾向が含まれているので、もう何冊か読んでみないといけないかなと思います。

ついにiPhone登場

Mon, 09 Jun 2008 14:46:02 -0700

のページが素敵なことになっています。
なんか、欲しくはないとは思いつつも周りが皆欲しい欲しいと言っていると、流されそうになる自分がいます（笑）
触るだけ触ってみようかなぁ。2万円だったら、まぁOKですよね。

二度寝前

Tue, 03 Jun 2008 14:45:20 -0700

9時前に寝てしまい、気が付けば11時。
でも、朝の4時かと思うくらい長い夢を見ていた気がする。苦しい夢だった。

溝口肇 / / バップ
スコア選択: ★★★★★

ドラマやアニメ、Jazzなど様々なアレンジをこなすチェリスト。結構菅野よう子と仕事してることも多いようだ。

そんな氏の、ポップスアレンジのCD。Mr.Lonlyなどどこかで聞いたことのある曲・アレンジがつまっている。

のんびーりしたいときにはお勧め。

/ Telarc
スコア選択: ★★★★

アメリカの作曲家、Barberの「弦楽のためのアダージョ」を中心に選曲されたCD。

というか、本当に聞きたかったのは上記の曲に詞を当てたAgnus Deiであった。

お目当ての二曲は満足のいくものであった。ただ、弦楽のためのアダージョは解釈が違うとここまで違うのか、ってほどテンポが速い。もっとねっとりしてる方が好きなのになぁ。

合唱は、Robert shaw festival singersということでどうかなと思っていたけれど、意外ときっちりと歌われていて満足です。

高屋奈月

Tue, 03 Jun 2008 14:44:42 -0700

胃が凄い荒れ狂っているのがわかります。
紹興酒まずかったorz

高屋奈月 / / 白泉社
ISBN : 459218601X
スコア選択: ※※※

高屋奈月の新しいシリーズ。

うむ、フルバと同じテイスト。というかほぼ同じ臭いが。フルバ好きな人ならOK.ダメならやめとけって感じです。
なんというか、相変わらず陰がある作品だなぁと思います。

なんという努力の人

Sun, 01 Jun 2008 14:45:25 -0700

SUGEEEEEEEEEEEE!

なんというお茶目さん☆

Wed, 21 May 2008 01:05:00 -0700

Mantyjarviさんは、お茶目らしい。

Four Shakespeare Songs (1984)
More Shakespeare Songs (1997)
No More Shakespeare Songs? (2000)

この次は、Even More Shakespeare Songsを書きたいとか言っているとか。
馬鹿だ(笑)

「すべてがFになる」読了

Sat, 17 May 2008 00:05:00 -0700

森博嗣の「すべてがFになる」を読了した。
タイトルの意味も最初はさっぱり分からなかったのだが、読み終わる頃にはなっとく。
なるほどね、と。

僕にミステリーの食わず嫌いを無くし入門となってくれたのが、東野圭吾の「ガリレオ」シリーズならば、更に深くつっこむ機会を与えてくれたのが、この森博嗣である。
元々、学生の頃に自分の大学の先生がミステリーを出している、というので話題になっていたのだが、ミステリーなんて頭使って推理するのがめんどくさい、と思い避けてきていた。

しかし、ガリレオにしろ森博嗣にしろそうなのだが、こんなん想像付かないよというトリックを用意してくる。こちらとしては、それがどういうものなのかを考えることはするのだが、それよりも何が出てくるのかワクワクしてしまう。

シリーズ1冊目なのだが、続きが気になるところである。

そういえばここは物欲ブログだった

Fri, 18 Jan 2008 13:46:07 -0800

というわけで久々にメモ

・ARIA全巻
・Creative EP-630
なんでも非常にコストパフォーマンスの良いカナル型ヘッドホンだとか
・安定したういるすたいさくそふと
Norton360がクソすぎて使えない．VBもいまいちくさいし……

ワイド液晶と液晶テレビ

Sat, 27 Oct 2007 14:46:13 -0700

20インチワイド液晶が3万円で手にはいると聞いて、沸々とほしくなってきた次第です。
20インチワイド液晶テレビが6万円で手に入りそうなのを見て、少しときめくわけですよ。
ビクターってブランド代があまりないので、お安く買えるのが良いですよね。
他社より1万円近く安いのがとても魅力的。

ただ、困るのが来年寮に入ると会社が選べなくなりそうなこと。
決断は焦らず急がねば。

「みんなの合唱」

Mon, 02 Jul 2007 14:45:36 -0700

なんつーサービスがあるようです．

見てみたら，着うたフルで全国大会の曲とかをDLできるようです．すげー．
でも，この料金設定ぼったくりだよな……

ZARDのVocalが亡くなられたなんて……

Mon, 28 May 2007 21:05:00 -0700

高校時代には、良く聞いたものですが……
ご冥福をお祈りいたします。

現在、ほしいものをメモしていきます。
久しぶりに物欲にまみれることになる気がします。

・オーディオケーブル(ミニピン)1m
ダイソーで二股のステレオケーブルを分けるものを買ったので、
ふるーいミニコンポにPCの音とiPodを差し替えることなく聞けるようにしたいです。
ただ、大学生協などで買おうとすると700円くらいするので、
くらいの値段を狙いたいところです。

・FMトランスミッター
秋葉原に先日行ったときに、980円で売っていたのですが
あまりに胡散臭くて買うのをやめてしまいました。
今となっては、あの値段なら人柱にはいいのかも、と思い直して後悔中。
PCやiPodなどにつないで、お風呂ラジオに電波を飛ばしてみたいと思っています。

ただ、実際にはどれがまともなのかがわからないのが難点です。
酷い酷いとは聞くのですが……。
とりあえず、ACでも使えるのだとよいのかもしれないなぁと。

・学習リモコン
というか、リモコソでいいからほしいです。
999円なら買ってみてもよいのかな、と。
TV,DVDプレーヤー、ミニコンポ、5.1chのスピーカー、エアコン
これだけまとめられるとうれしいなぁと。

小物ばかりといえば小物ばかりかもしれないですが、
きちんと狙わないと高くかかってしまうモノばかりなので、近々大須へ行って狙ってこようかと。

—-070529追記
・ケーブルまとめるやつ
前使っていたがどこかへ行ってしまったので、
これをもう一回買い直すか、に切り替えるかが悩みどころ。

・iPod用FMチューナー
なんとなくFMが聞けると幸せかなぁと思っているだけです。
ちょっとお高いんですよね。

USBで聞けるFM/AMラジオ

Thu, 10 May 2007 03:05:00 -0700

こんなものついに登場しました。
価格は手ごろな6980円！

うりきれじゃなかったら、ぽちってたなぁー

これがあれば、ラジオと連動させて、とかやらなくてもすみそうだし。

ナビナビ

Sat, 26 Aug 2006 14:46:29 -0700

ついに、うちの車にもナビがつきました。
カロッツェリアのCYBER NAVIというやつなのですが、
HDDを積んでいるのでCDを入れたら勝手に録音する優れものです。
新しいおもちゃが入った子供状態です。うれしーのよね

夏なので

Fri, 28 Jul 2006 14:46:34 -0700

ノートをたちあげっぱにしておくと，熱で手が低温やけどしそうな今日この頃，いかがお過ごしでしょうか．

とりあえず，なんとか色々ありましたが，少しはマシな方向？に向かってきているようです．
ここにきて，研究テーマを変えて1からやり直しとかは大変ですが．．．

さてはて，この前テレビを見ていたら，
素敵なミュージシャンが出ていたのでまたCDが欲しくなってきましたよ．
という人たちなのですが，
ギターのデュオだそうです．
軽快なアコギでじゃかじゃか，でもメロディック，みたいな感じが良いです．
みたいな感じかな？
インストゥールメンタルがちょっぴり好きなおいちゃんのツボですわ．

DEPAPEPEは，CDの視聴ができるのですが，元気がもらえそうな感じです．
CDかりたーい！
お金があれば買いたいですが，今はW-ZERO3[es]が来るのを控えているので節約モードです．

DS de TV

Fri, 19 May 2006 14:46:40 -0700

なるものがでてるようです。
しっかし、このサイズにこの重さはどうなんだろうなー。
まぁ、以前よりTVはみるようになったとはいえ、そこまで必要ないかなぁ。。。

−−−
そういえば、某SNSで高校時代の先生が参加していることが判明したのですが、何がすごいって、 息子から招待されてたんですよね 。
すごい時代になったもんだわぁー。

国語の時間丸々つぶして自分の高校生の時の大恋愛話をご教授していただいたのが昨日のように思い出されます（笑）

DSLite!

Mon, 01 May 2006 14:46:45 -0700

ついに念願のNintendoDS Liteを購入しました！
先週の金曜日に研究室の秘書さんがおもむろに

「chezouくん、DS買った？栄のポケモンセンターに入荷したらしいんだけど」とか言われるわけですよ。
もう、即購入ですわ。全色ある中から選べるなんて！
とりあえず、紺色なやつを買っていただきました。
ビバ、秘書さんのご友人(笑)

ただ、現在どうぶつの森を買うまでDS用ソフトがありません。
研究室の先輩には「タイの学会に行くから、指さしなんとか買ってくれ」とか言われましたが……。
丁重にお断りしましたｗ。

その間僕使えないですし。

というわけで、今からGEOに行ってきまーす

うひー

Fri, 17 Mar 2006 03:03:00 -0800

全く持って卒論の筆が進みません。卒論締めは月曜午後5時。
間に合うのか俺。

というわけで、某A先輩のブログが熱いことになってるのを尻目に、卒論を書くわけですが、
秋葉原土産に買ったものを色々試したくて仕方がない状況でして、手につかないわけです。
なんてたって、ケースを買ってきたり、キャスター付きのバックを買ってきたりと非常に大荷物でした。
なので、地下鉄では「ザ・迷惑」を実行しておりました。一緒に乗られた方々、すいませんでした。。

今回、秋葉原での戦利品ですが、

・キャスター付きバック　￥６９８0
・PCケース　￥1980
・巻き取り式USBケーブル　￥600
・巻き取り式iPodケーブル　￥600
・外付けHDD160GB(弟への土産)　￥7980
・　￥4800
・IDE to USBケーブル　￥1280

となっております。ケースは本当に馬鹿だったorz
ちなみに、今回最も当たりだったのは、IDE to USBケーブル。
これが非常に便利でいろいろなHDDを漁りだしてはころころ変えて遊んでいました。
昔使っていて壊れてしまったノートのHDDを取り出したら、ウィルスまみれだったのが笑える話。

本当はニンテンドーDSLiteを見つけたら買おうと思っていたのですが、
なんと、定価の二倍近くの￥32000もしやがったのでパスしました。

と、思っていたら先ほど研究室の秘書さんから電話がかかってきて「DSならあるけどLiteがほしいんだよね？」と報告をいただきました。
散々、「Liteの方が断然良いよー」とおっしゃっていたのはあなたではありませんか。
というわけで、じっくりLite待ちです。

ついにｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

Fri, 07 Oct 2005 14:46:55 -0700

○

長年欲しかったものがついに発売されます。
ようやく、これでPCでラジオとりほうだいです。結構NHK-FMをとりたいと思うときはよくあるのですが、なかなかWAVに起こすのは面倒なのででMDに録音していました。
これがあればまさにMDいらず。

しかしネックはおそらく受信状況だろうなぁ。。人柱いないかなぁ

す、すげー一品ですよ

Mon, 03 Oct 2005 14:47:01 -0700

あの一部では有名なほぼ日刊イトイ新聞が、なるものを出すらしいです。

正直、この発想には参った。毎月のカレンダーが紙なのにホワイトボード使用。
これは、サークル室に是非置いておきたい。でも、たぶん喜ぶのはE氏に違いない。
現代美術合戦になること請け合いだ。

WILLCOM新機種ｷﾀ━━━━━━(ﾟ∀ﾟ)━━━━━━ !!!!!

Tue, 27 Sep 2005 14:47:06 -0700

というわけで、が出てきて正直びっくりです。
miniSDからJavaからFlashまで。PDFをPHSで読む必要はあるのでしょうか？でも、論文が読めたら便利だな、とは思いますが。

機種変は高いんだろうなぁ……

高田三郎行ってきました。

Sun, 18 Sep 2005 14:45:41 -0700

今日は、某高田三郎の演奏会に行ってきました。

豊中混声と大久保混声が一緒に聴けるとはとても素敵なチャンスだとばかりにるんるんでいきましたが、 生まれて初めて 600人くらいの合唱団をはじめてみました。
ええ、それはもうきもかったですとも。だって、芸文のコンサートホールに、オケを乗せてさらに4団くらい女声を乗せて、さらに後ろの客席に余った人々を乗せていましたから。
肝心の歌は……、力押し。。。パイプオルガンはおろか、オケまで負けていたのが驚きでした。しかも、何を言っているのかさっぱりわからない。和音も何もあったもんじゃあございません。
やっぱり、合唱団は70人くらいが限界だな、と相方と喋っていました。
東海メールの内なる遠さは、曲が良かったためそこそこ楽しめました。男声だと暴力的に高音が出されないから安心だわぁ。あと、男声合同曲で典礼聖歌を歌っていたときの、テナーソロのおじいちゃんが感動でした。あの年でコンサートホールに栄えるソロってのは正直かっこよかったです。

で、豊中混声はやっぱりうめーなぁ、と思いながら堪能していました。大久保混声もなかなか濃厚なつくりで良かったのですが、豊中のすがすがしいハーモニーは演奏会で一二を争う清涼剤になりました。歌としては大久保混声の方が好みですが。
辻さんの髪の毛は赤が落ちたような茶色でした（ぇ

そんな素敵な演奏会ですが、実は今日の演奏会でオーボエやってたのが高校の同級生でびっくり。まさか、こんなところでつながるとは思いもしませんでした。ちなみに、オケのほうはなかなかお上手でした。練習とか大変なんだろうなぁとか思いながら聞いていましたが、とりあえず、統率された弦が心地よかったです。某M音大のメサイアなんかとはわけがちがいました。
でも、3時に開演で7時過ぎに終わるってのはちょっと大変だったかなぁ、とか。

出演された、なみぃ師はお疲れ様でした。
色々大変だったとは思いますが、楽しめるところも色々あったので良かったです。

ノートの改造

Fri, 09 Sep 2005 14:47:11 -0700

今使っているノート（VAIO PCG-SRX 3E/BD)のバッテリがへたってきました。
充電してももう1分ももちやしません。
ここで、バッテリを買おうとしたんですが、毎度のことながら純正バッテリは高杉なわけです。そこで、純正ではなく噂のROWAのを買おうとかんがえているんですが、なかなか勇気がでません。

バッテリを買えるとなると、HDDやらメモリも増やしたくなってくるのが人情ってもんでして、こうなるともう新しいマシンが欲しくなるという罠。大変だー

バイトで稼いだ3万5千が飛んでいく日も近い。

へっどほん！へっどほん！

Wed, 24 Aug 2005 14:47:16 -0700

いや、厳密に言うとヘッドホンではないのかもしれません。カナル型イヤホンのER-6iです。
てか、色々ネットで調べてる内にこれしかない、という状況にまで来てしまいました。
しかし、研究室の同期曰く、「自分で店に行って聞き比べた方が良いよ」とのこと。確かにその通りだと思うので、明日台風が来なかったら大須に行ってみようと思います。
是非とも合宿までには入手したいところ。

男声合唱

Sun, 21 Aug 2005 14:45:46 -0700

最近、無性に男声合唱がやりたくなってきました。
新年会とかに向けて今から準備すれば曲いっぱいやれないかなぁ……。
男声じゃなくても良いから、一度県のアンコンにでておきたいなぁ、とも思ったり。

男声でやるなら

・カウボーイポップ（信長）
・祝福（木下）
・じょんがら節（松下）

ここら辺がいいなぁ。二個目は、ちゃんと音楽にすると美しいんですよ。ええ。
誰か一緒にやりませんか？（ってここは見てないかorz)

まじめな？電波系Songs

Wed, 17 Aug 2005 02:08:00 -0700

らしいですよ。

**_素数は夢を見ています

明日の夢を歌います。_**

　加藤先生が言うには素数が見る夢とは、
「宇宙が滅びそうになったとき素数さんたちが救ってくれる」
その夢を見ているとのことだそうですが。
　実際にはこれは類体論の夢を見ていると解釈したほうが妥当でしょう。

どうしたらそんな解釈に至れるんでしょうか……。

もう一つ、はすでに出尽くした有名どころですが、分かる人には分かるすごさ。

普通は、
三善晃×宗左近＝縄文連祷などの縄文シリーズ
という連想だと思うんですが、たぶんかけ算じゃないのかもしれません。
＊とかでをしているのかもしれません。

……んなわけないか。

Webカメラ

Sat, 06 Aug 2005 03:08:00 -0700

最近、MSNやらYahooやらSkypeやらを駆使して、あの手この手でボイスチャットやお絵かきチャットしながら友達と勉強をしていたわけですが、
そうなると、無性にほしくなるのが。

TSUKUMOのネットショップで10kで売ってたんですよね。やってみたいー

うらやましかー

Sat, 16 Jul 2005 20:07:00 -0700

昨日は家で勉強をしようとしていたわけですが、行きたかった演奏会があったわけで。
マートラの風景という曲がとても聴きたかったわけですよ。

でもね、いろんなりゆうで勉強する気にならなくてさ……。
こんなことなら、聞きに行けば良かったと。

マイアヒとcayabyab聞いて我慢しますよ。。。

W-SIM

Mon, 11 Jul 2005 14:47:27 -0700

着せ替えPHSですよ、いいですね。発想が面白いですよ。

今は、京ぽんとAUの二台持ちで頑張ってるわけですが、何故かうちだと彼女さんと電話してると通話がしょっちゅう切れるんだな。
まるで走りながら電話してるみたい。困ったorz

VHS内蔵DVDプレーヤー

Wed, 18 May 2005 23:05:00 -0700

最近、無性にほしいのがVHS搭載DVDプレーヤーなのです。
なにせ、いつの間にか壊れてしまったVHSデッキがうちにほったらかしにしてあり、さらにDVDの需要がこのところ高まってきています。両方ともめちゃくちゃ安いプレーヤーにするのもありかとは思いますが、壊れて修理に出しに行くのが面倒なので一体型を買っちゃえという発想です。（なんか矛盾してる気がする）

で、がほしいのですが、、、もうちょっと値段さがらないかなー

WILLCOM

Sat, 23 Apr 2005 14:47:38 -0700

最近、無性にWILLCOMにしたい衝動に駆られています。
今は、AUの一番高いプランを学割で使っているのですが、10kを越えることもしばしば。
しかし、ほとんどの通話は彼女にしているので、WILLCOMにすれば、通話料がほとんどいらないかな、と。
しかも、メールまで定額になってくれたらもう金がかかるのはWebだけ。

一つネックがあるとすれば、Javaアプリとかが使えないことでしょうか。
最近ちょっとさぼっている家計簿とかがつけられなくなるのは多少痛いかなぁ……。

2台同時に持つことも考えておきますか。

う、うるさい……

Sun, 27 Mar 2005 13:47:43 -0800

現在、CPUはCeleronDの320を使っているんですが、最近長時間起動しているとCPUファンがうるさいのなんのって。。。
これを機にCPUファンを変えようかなぁとか思ったりもするんですが、それ以前にケース内のケーブルをもうちょっと整理した方が良いのかなぁとも思うのですよ。リテールのFANはうるさいです。。。

そういえば、ケースファンは一個もついていないのですが、これも一つの原因なのかなぁ……。
なんとかならんもんかねぇ。

すごーい！！

Thu, 03 Mar 2005 13:47:48 -0800

を見て、携帯のカメラのすごさを思い知った。しょせんは付属物とかいってなめてちゃいかんのね。
ちなみに、この写真はA5406CAだそうです。
僕も携帯変えたくなってきました。うちが使ってる携帯はA5401CAなのですが、9と＃のボタンが硬くなってきたのです。いやだなぁー、と思っているとき友達が携帯を変えていたのです。そのA5406CAに。
ポイント2500つかって5kで買ったとかいってたかな？僕は3000ポイントあるので4kくらいでかえるのでしょうか。でも機種変にしたいからどれくらいかかるのだろうか。
個人的には、のころからCASIO使いなので、CASIOしか使う気が起きません。でも、FMチューナーがついて欲しいんだよなぁ。どっちかというとカメラより安くしてくれとか思う人だったりします(^_;

というか、そもそも学割だと途中で機種変できなかったっけかな？

Blog Posts (in Japanese) | Democratizing Data

TikTokで勝手にアカウントが作られ続けるので、Claudeでカナダのprivacy法に則って通報をした

tl;dr

何が起きたか

1回目の対応：3月にTikTokサポートへ

ところが再発

規制当局ルートを2本

（Canada’s Anti-Spam Legislation） /

（Personal Information Protection and Electronic Documents Act） /

フォームの自動ロック問題

Information Centre 経由でリカバリ

Formal complaint の構成

既存の OPC × TikTok の文脈

カナダ居住者へのチェックリスト

雑感

AI時代の転職活動記録

転職活動でやったこと

Claudeを使った企業調査

LLMを使った内省

ジャーナル

エピソードバンク

同時期に転職活動をしている仲間との進捗共有

LayerXで働き始めました

Treasure Dataを退職しました

過去記事

原初のMLチーム（傭兵期）

AudienceチームでのCDP開発（一人一殺時代）

2回目のMLチーム

終わりに

ワークフローテンプレートをskillに埋め込んで、LLMの役割を「生成」から「レンダリング」に変えた話

MLワークフローのLLMによる自動生成の夢

Claude Codeの進化とエージェント用CLI

ワークフロー生成におけるエージェント用CLIの功績

MLワークフローテンプレートのskill化

digdagワークフローのJinja2テンプレート

OpenAPI = agentとの契約書

skill作成 agent VS skill使用 agent

まとめ

Montréalに10年以上ぶりに行った

ボランティアデーでWikipediaの太平洋時間（Pacific Time）の改善をした

ハマりどころ

Pacific Timeは山岳部標準時なのか、そもそもタイムゾーンなのか論争

「Agents SDK+αのTipsを一人で書いていくアドカレ Advent Calendar 2025」を追走した

Oh-my-zshを辞めた

Pages CMSからSveltia CMSに移行した

モチベーション

やったこと

感想

Principal と器用貧乏のあいだ

はじめに

4つのStaff Archetypes

1. Tech Lead

2. Architect

3. Solver

4. Right Hand

自分の仕事をArchetypeで分解する

なぜStaff+のスコープは広がるのか

自分のキャリアとしての振り返り、あるいは高機能雑用の再定義

同じ悩みを持つ人へ

「ちょっとしたことでうまくいく 発達障害の人が上手に働くための本」を読んだ

2025年を振り返って

プライベート

仕事

OSS活動

買ってよかったもの

来年に向けて

AI時代のPrincipal Engineer

1. AIは “frenemy”

2. 必要なのは英語力、コミュ力。次に技術力とキャッチアップできる力

3. AIを自分で使い倒し、AI slop detectorを身に着ける

4. Principalは孤独、AIは良い壁打ち相手。でも気をつけろ

5. AIは996に追い込もうとしてくる

Principal Engineerが読む「スタッフエンジニアの道」

最近の人類のレビュー疲れ

他人を経由したプロンプティング

自己レビューの欠如、あるいは目が滑る問題

クソデカコミット

生成側とレビュー側のインセンティブ構造の違い

コーディングレビューでの向き合い方

1. 生成側がGitHubで他人のコードとしてレビューをする

「ちょっとしたことでうまくいく発達障害の人が上手に働くための本」を読んだ

Kyash (難易度 ★★★★☆ 所要時間約2日)

第8回パーフェクトRuby読書会をはじめる (2014)

第47回ミューザ川崎に戻る (2017)