電脳ゲリラ兵站基地: 2012

2012/09/24

PFIセミナー「多様化する情報を支える技術」参加メモ

9月21日に開催された、株式会社プリファード・インフラストラクチャー（Preferred Infrastructure(PFI)）主催のセミナーに参加した。タイトルは「多様化する情報を支える技術」。場所は日比谷コンベンションホール。

IT業界の人間をスーツ系とギーク系に分ける風習があるが、集まってたのはそのどちらでもないような感じだったな。多分、研究者が多かった気がする。それも大学所属ではなく企業所属の研究者。まあテーマがテーマだからそうなるのか。

一気に書こうと思ったけど力尽きたわ。とりあえず前編。

＜追記：2013/1/12＞
日が経ちすぎてしまった。もはや後編はない。ただ、日経コンピュータの編集者の「ITに関連する最新の情報はまず経済紙『The Economist』に載る」という報告は面白かった。「クラウド」も「ビッグデータ」もそうだったらしい。ちなみにEconomistがフィーチャーする最新ITワードは「3Dプリンタ」らしい。

基調講演「多様化する情報を支える技術」
講演はPFI代表取締役の西川徹氏。

PFIという会社の社是について。
研究開発には長期的な視点が必要なため、短期での利益を求めがちなベンチャーキャピタルからの融資は受けない。フルスクラッチの受諾開発に拘泥すると社内のリソースがそちらに集中してしまい製品開発ができなくなるため、受諾開発はしない。コンピュータサイエンスの領域は広く、一人で全範囲をカバーすることは不可能。それ故に、社内における技術と人材の多様性を是とする。

ビッグデータ時代のデータには2種類ある。
人が生み出すデータと機械が生み出すデータの2種類だ。
前者はブログ記事やTwitterの書き込みなどの、従来の一般的なビッグデータの文脈において対象となるデータ。後者は、センサーや監視カメラ、GPSやルータといった機械が生成するデータ。これは機械によって自動的に生成されるため、人が生成するデータに比べて量が多く質が低いという特徴を持っている。

「ビッグデータ」という言葉が流行った要因としては、Googleの存在が大きい。Googleが行った分散処理の効率化の試みとその成功は、大規模データ活用の流れを生み出した。

ビッグデータの対象となるデータは多種多様であり、PFIとしてもゲノム情報などを扱うライフサイエンス分野に注目している。

先に挙げた2種類のビッグデータのうち、人が生み出すデータの扱いについては、情報検索技術が有効であると考える。とにかく大量のデータを格納し、検索によってそれを取り出す。データを物理的に格納するレイヤーがあり、そこから個々人に適合したデータ抽出のためのビューとして検索エンジンがあるイメージ。PFIの製品である「Sedue」はこのような利用シーンをサポートしている。

しかし「貯める」「取り出す」では不十分である。「整理」という考えが重要となる。
企業内検索システムにおいては、社員が文書等の情報をアップロードする必要がある。検索エンジンを十分に機能させるためには、それらの情報にラベルやタグといったメタ情報を付与する必要がある。しかしアップロードする際に社員が人手でそれを行うのでは、煩雑さが増し、それ故にアップロードが進まない。必然的に検索エンジンが上手く機能せず、情報共有も上手くいかない。実際、ほとんどの企業内検索エンジンは十分に活用されていない。
このジレンマをテクノロジーを用いて解決することを目指している。そこで使う技術は機械学習だ。アップロードしたいドキュメントをブラウザにドラッグすれば、自動的に分類をサジェストしてくれる機能を現在開発している。

機械が生み出すデータの扱いについて。
近年のデバイスの性能向上により、生成されるデータの量とスピードが爆発的に増加した。これにより、一般的なデータ解析処理に不可欠な「データを貯める」ということが不可能となった。

貯めることが不可能なデータを省スペースで解析するにはどうすればよいか。複合イベント処理（Complex Event Processing：CEP）がその解となる。分散処理のオンライン化、ストリーム化。データを貯めることなく、データが発生したタイミングでリアルタイムに処理する。PFIが開発した「Jubatus」は、そのような利用シーンをサポートする。中央サーバにデータを集めることなく、エッジにあるマシンが機械学習の手法を用い、有用性が一定の閾値を超えたデータのみを別ノードに転送する。

ウェブの発達によって人が生み出す情報が増えた。しかし一方で機械が生み出す情報も増えた。これらはデータの性質も生成のスループットも異なる。故に最適解となる技術も違う。
人が生み出すデータは、格納することは容易だがいかに整理するかが課題となる。機械が生み出すデータは格納すること自体が困難だ。

「ITアーキテクチャはどこへ向かうのか」
講演は統計数理研究所副所長の丸山宏氏。

イアン・エアーズの『その数学が戦略を決める』という本がある。そこでは、勘と経験に支えられたプロフェッショナルの判断を、統計データによる判断が凌駕する事例が書かれている。
データに基づいて立てられたワインの品質を推定するモデルを用いれば、素人でもワインのプロよりも正確に品質についての判断を下すことができる。

大量のデータを見て、それを即座にビッグデータであると判断するのは早計だ。
例えば、あるショッピングサイトのアクセスログは年間で30テラバイトにもなる。このデータを元にどのページがよくアクセスされるかを調べたい。これはビッグデータの問題か？　違う。何故ならこの問題を解くにはランダムサンプリングをすれば十分だからだ。サンプリングをした後、Excelで分析すれば事足りる。

Hadoopのような分散処理でしか解けない問題は意外に少ない。多くのデータは、パソコン1台でも処理できる程度の量か、あるいはHadoopでも間に合わないほどの量である。

因果関係と相関関係は違う。
国立国語研究所が山形県鶴岡市において方言の調査を行っている。ここで得られたデータは、テレビを見る時間が長い人ほど方言の使用率が高いということを示唆しているように見える。しかしテレビは多くの場合共通語が流れており、それを見た人間は共通語を習得するはずで、この結果は直観に反する。
これは因果関係と相関関係を取り違えた例である。高齢者ほどテレビを見る時間が長い。そして同時に、高齢者ほど方言の使用率が高い。そこには相関関係があるだけであり、因果関係はない。

データの理解は、経営の問題である。データから何らかの知見が得られたとしても、経営陣が正しい意思決定ができなければ意味がない。
Googleの検索結果画面には、検索結果（Organic Search）と一緒に検索内容に対応した広告（Paid Search）が表示される。Marriott Hotelというホテルは、Googleに料金を払ってPaid Searchを出していた。しかしある時、Paid Searchに彼らのホテルが表示される際、同時にOrganic Searchにも表示されていることに気付いた。それならばPaid Searchは不要ではないかと試しに2週間Paid Searchを止めてみた。結果、ホテルの予約件数は変わらなかった。
しかし、Marriott Hotelはその後もPaid Searchを出し続けている。これはデータが得られたにもかかわらず意思決定が行われなかった例である。

1980年代は、様々なコンピュータアーキテクチャが提唱された時代だった。
CM-1、SPARC、Transputerといったコンピュータが出現した。
このあたりの動向についてはMark Oskinが「The Revolution Inside the Box」というサーベイを書いている。
しかし90年代に入って、めっきりアーキテクチャの提唱は行われなくなった。
Intelのアーキテクチャが市場を席巻し、ムーアの法則の元に「待っていればIntelがより速いプロセッサを開発してくれる」といった認識が蔓延した。かくして、ハードウェアは隠蔽された。

しかし、今日のビッグデータにおいては、データをどのノードに配置するか、計算をどのノードで行うかが重要となってくる。再びハードウェアを意識しなければならない時代になった。

クラウドの次に来る新しいアーキテクチャは何か？
PFIの岡野原氏が言った言葉が参考になる。Edge-Heavy Data。中央サーバに大量のデータを集めるのではなく、末端のそれぞれのノードに大量のデータがあることを前提としたアーキテクチャ。
機械によって自動で生成される大量のデータには、本質的でない副産物的なデータが多く含まれている。データ量は増えたが、1ビット当たりのデータの価値が下がっている。
これはデータの価値と独立性を重んじ、データセンターに置くことを奨励された我々世代の考え方とは異なる。

2011年には国内に2,010万台のスマートフォンが出荷された。そのそれぞれに10GBのスペースがあるとすれば、全部で200PBのデータが入ることになる。マッキンゼーのレポートによれば、国内のデータ総量は年間400PBらしい。エッジであるスマートフォンに、国内のデータの半分を入れるキャパシティがあることになる。

Edge-Heavy Dataに特化したアーキテクチャを考える必要がある。
複数台の監視カメラに対して、そのすべてのカメラに写っている人物を取得するクエリを投げるとする。この目的を達成するためには、それらのカメラ間においてデータのマッチングが必要となる。カメラ間でサマリ情報を交換する必要がある。

分布表現をファーストクラスオブジェクトとする言語が必要だ。
センサーのデータは分布表現で表される。値がスカラーか分布かを意識しない言語。
コンピュータサイエンスは欠測値のあるデータに対してあまり考えてこなかったように思う。

アーキテクチャの変節点を見極めよう。

「グローバル化する情報処理」
講演はPFIの伊藤敬彦氏。

Sedueにおける多言語処理の話。
多言語処理とは翻訳のことではなく、システムを任意の自然言語で動作させることを言う。

日本企業のグローバル化によって、現地法人を持つ企業を現れてきた。これにより様々な言語で書かれた社内文書を処理の対象とする必要が生じている。既存のシステムの多くは、英語などの単一の言語でしか動かない場合がある。これでは、その言語以外を用いる社員はシステムの恩恵を受けることができない。

この問題を解決するために、PFIでは多言語解析基盤「Screw」を開発した。
単語分割、正規化、固有表現抽出といった様々な言語処理ツールを組み合わせることができる。入力文書の言語を自動同定してその言語に合った言語ツールで処理してくれる。処理結果はJSON形式で出力できる。

ScrewはSedueに同梱して販売する。順次対応言語を増やしていく。
将来的にはScrew単体で販売することを考えている。

2012/08/30

LL Decade 参加メモ（後編）

書こう書こうと思って、1ヶ月近く経過しようとしている・・・
講演についてはすでにvimeoに動画が上がっている。
なので細部の説明は割愛する。個人的な感想のみ。

Language Update Decade

forkは世界を良くする（こともある）
Pythonが変化に遅い。しかしそれは慎重に検討、ドキュメント化されるから。デコレータの導入が議論された際、複数の案をGuido van Rossumが各案のメリデメをまとめてドキュメント化した
言語は黒子。目立たない。C言語のカンファレンスとかはない。でもRubyは言語が前面に出る。それはRubyがコミュニティのシンボルだから。そして楽しいからそれはコミュニティのシンボルになり得る。

プログラミング言語処理系を自作してわかったこと

@Constellationさん無双といった感じ。
「Level5」Ecma262完全準拠のEcmaScript実装系。
やっぱ低レイヤーいじれる人はかっこいいなと思った。

俺たちの継続的hogehogeは始まったばかりだ！

Jenkinsの話ばっかり。
見た目がぶっ飛んでたkyon氏の発表が一番実があった。
コミットの自動化により仕事の進捗のログを取るという発想は良いと思った。

Lightning Talks

憧れが人を成長させる
日本のエンジニアの今後10年の戦略。世界中で使われるソフトを作る、あるいはアーキテクト方面を目指す。
LLプログラマは仕事は速いが始めるのが遅い。
LLプログラマは飽きっぽい。
勉強会は学校のようなもの。卒業する人もいる。たまにそんな人たちが戻ってきて同窓会みたいになる。

2012/08/05

LL Decade 参加メモ（前編）

2012年8月4日、銀座ブロッサムにおいて開催された「LL Decade」に行ってきた。
前回参加したのは2007年の「LL Spirit」だったと思うから、もう5年ぶりになるのか。

プログラムは以下の通り。

開会宣言
基調講演
Language Update Decade
プログラム言語処理系を自作してわかったこと
俺たちの継続的hogehogeは始まったばかりだ！
Lightning Talks
閉会宣言
懇親会＋Lightning Talks

開会宣言は日本Unixユーザー会の法林浩之氏。
眠かったので「赤いストラップの人は写真撮影NG」ということしか覚えていない。

続いてクックパッドの宮川達彦氏による基調講演。
Perlハッカーとして業界内ではあまりにも有名人であるが、現在の所属はRubyを中心に使用すると言われているクックパッド。そのあたりのジレンマ（？）のような話も出るのかと思ったが、そのような言語の差異の問題をむしろポジティブに捉える講演内容だった。

以下、講演内容のメモ。

基調講演（宮川達彦氏）

サンフランシスコは青空が印象的だが、その印象とは裏腹に気温は低く、夏でも20℃弱しかない。先週日本入りしたが、30℃を超える東京は暑くて死にそうだ。

同僚に、今度LightWeight Languageのカンファレンスに出るのだと言ったら、そもそもLightWeight Languageとは何か？　という話になった。コンパイラのあるなしがそれを決めるのか？　それとも別の基準があるのか？　もはやC言語とJava以外はLightWeight Languageと扱ってもいいのではないか？　でもWikipedeiaを見るとむしろC言語がLightWeight Languageに分類されている。省メモリなのが理由らしい。確かにそういう考え方もあるかもしれない。

自分はこう考えている。「少ない能力の消費で開発できる。少ない労力でスゴいことができる言語」。それがLightWeight Language。

LL Decadeということで、この10年で何が変わったかという話をする。その変化は、Code, Community, Cultureという言葉で言い表すことができる。

10年ほど前。伊藤直哉さんと出逢った。お互い所属していた会社は違うが、『BlogHacks』という本を共著で出版した。コードを超えたコラボレーションがこの頃から盛んになったように思う。

Livedoorを退職したとき、SixApartの社長Benが日本に来ていて飲みに行った。求職中である旨を伝えると、レジュメを送るように言われた。しかし就職活動もろくにしたことがなかったのでレジュメの書き方がわからなかった。しょうがないのでCPANのURLを送った。翌日、コードを読んだBenから採用の連絡がきた。

ソフトウェアは人。コードはその人のことを表す。Code = What I really am.
コードには人格が宿る。だからコードを見て自分のことを評価してもらえるのはうれしい。

コミュニティの必要性を感じて、2006年、YAPC::ASIAを開催した。

「polyglot」という単語を最近見かけるようになった。「複数の言語を知っている人」という意味。特定の言語に拘泥せず、色々な言語の動向に対してアンテナを張り、適材適所で選択する人。そのような人は「Polyglot Programmer」と呼ばれる。サイボウズ・ラボの竹迫良範さんが書くような、複数の言語で動くプログラムのことではない（笑）。

Pythonはドキュメントが良い。PEP（Python Enhancement Proposal）という形でドキュメント仕様が整理されている。良いドキュメントの形というものがあらかじめ定められている。
「The Zen of Python」に謳われたPythonの思想は、TMTOWTDI（There's More Than One Way To Do It）を是とするPerlの思想とは相反する。それはそれで良い。ただ使い始めて3ヶ月くらいすると、段々と「なんでこういう書き方ができないんだ」的なウザったさが出てくるが（笑）。

Perlプログラマはモジュールを作ってCPANに上げたがる。
RubyプログラマはDSLでフレームワークを作りたがる。
PythonプログラマはRSTドキュメントを書きたがる。

GitHubの登場が与えた影響は大きい。
GitHubのURLがそのままプログラマとしてのレジュメになる。
GitHubが果たした特に大きな貢献は、forkが持つイメージを変えたこと。GitHubの登場以前にもライセンス上はforkすることが可能だったが、そこにはどこか「分裂」「気に入らない」といったネガティブなイメージがあった。しかしGitHubはそのイメージを変えた。「変えたければ好きなように変えてよい。それには誰の許可も必要ない」という文化を醸成した。
GitHubのおかげでforkはポジティブなものになった。
Forbesもそのことを記事にしている。曰く「GitHubはプログラミングを民主的にした」。
10年前に比べて、環境が良くなった。

PythonにはWSGIというインタフェース規格がある。RubyはこれにインスパイアされてRackを作った。PerlはこのRackを真似てPSGIとPlackを作った。
良いものからアイデアを借りてくるのは良いことだし、コピーするのも良いことだ。Rackを構成するファイルの拡張子を.rbから.pmに変えればほとんどPlackのファイル構成と同じになる。

拙速は巧遅に勝るという言葉がある。
しかし、遅く始めることにもメリットがある。
遅く始めればその分先人の知識を多く見ることができる。遅い方が良いこともある。鍋パーティーに最初から参加すると準備を手伝わされるが、1時間くらい遅れて参加すると良い感じに煮えていたりするのと同じ（笑）。
「The Zen of Python」も同じことを言っている。曰く「Now is better than never. Although never is often better than *right* now.（やらないよりは今やるべき。けど今「すぐ」やるならやんない方がいいこともある）」
（※和訳はPython Japan User's Groupより）

Cross Language Pollination。
Perl、Ruby、Python。そのそれぞれが互いに影響を与え合っている。
RubyコミュニティがPerlコミュニティの動向を観察し、良さそうなものがあればRubyに取り入れている。
RubyGemsの人気モジュールであるmime-typesはCPANのモジュールから影響を受けて作られたものだ。

名前付けは重要。
Perlはネストし過ぎ。「::」が多すぎる。説明的ではあるが冗長でもある。
Pythonは頭か後ろにpyを付ける慣習がある。どっちにつければいいのかわからない。
Rubyの命名規則はカオスで、名前を見ても何がなんだかわからない。
名は体を表すような説明的な名前よりも、クリエイティブな名前の方が逆に解りやすい。現在のPerlにおける3大Webフレームワークである「Catalyst」「Dancer」「Mojolicious」は、説明的な名前ではないが、一度何をやっているものか理解してしまえば、「::」を何個も連結した名前よりもむしろ解りやすい。

今はRubyを書くことが多い。RubyGemsにもモジュールを上げている。

Keep Cross Language.

（※終わり。以下、質疑応答）

【質問】
仕事ではRubyを書くことが多いとのことだったが、今後もPerlには関わり続けるか。

【回答】
Plackをリリースしたときにはすでに仕事ではもっぱらPythonを書いており、Perlは殆ど書いていなかった。ただ、他の言語の良いところをPerlに取り入れていくという視点で、今後もPerlには関わっていく。

【質問】
「この言語にはこれが足りないな」というものはあるか。

【回答】
特段はないが、「PHP Sadness」というサイトが面白い。趣味でPerlを書き、仕事でPHPを書いている人がPHPの気に入らない点をまとめているサイト。

Rubyは綺麗だと思う。Perlと違ってオブジェクト指向が後付けではない。Perlでは素直に書けないことが、Rubyでは綺麗に書ける。Rubyの「手錠をはめられていない感」がいい。

【質問】
近年のVimの台頭に対して、Emacsユーザとして何か思うところはあるか？

【回答】
（※挙手による会場アンケート。VimユーザとEmacsユーザの比率は6対4くらいだった。）
Vimは普通のエディタと比べて明らかにヘンだと思う。閲覧用のモードと編集用のモードが分かれているところとか。
若い人は何故Vimを使うのだろうか。プリインストールされているから？　何かハッカーっぽい感じがするからかもしれない。

【質問】
PHPを使えと会社から言われたらどうするか？

【回答】
そもそも転職するときにPHPを使用している会社を候補に入れないようにしている。
ただ、面白い人と面白い仕事をするのが第一であり、言語選択の優先度はそれに比べれば少し落ちる。

定期的に新しい言語を学ぶべきだと思うが、新しい言語を学ぶにはその言語を使っている会社に就職すると効率がいい。お金をもらいながら勉強することができるから。

【質問】
PHPを使っている会社を避けると言っていたが、PHPを主として使用しているFacebookからオファーが来たとしても断るのか？

【回答】
Facebookからはすでに何度もオファーが来ている。
ただ、FacebookはPHPをただのページ記述言語としか使っていないはず。裏でC++にコンパイルして使っているはず。そういう割り切った使い方はアリかもしれない。

面白い人と面白い仕事をするのが第一であり、PHPが絶対にイヤというわけではない。ただ、現状においては、PHPを使う会社を避けた方が、面白い人と面白い仕事をできる会社に当たる可能性が高くなるからそうしているだけ。

【質問】
JavaScriptについて何かコメントを。

【回答】
jQueryを作ったのはPerlの人。「$」とかにその影響が見て取れる。
自分としてはサーバサイドに興味があるので、あまりJavaScriptの優先度は高くない。ただ、面白いことをしているとは思っている。

【質問】
日本とアメリカの会社の違いについて。

【回答】
国の違いよりも、時期と使うツールによる差が大きい。オープンソースのプロダクトを使用している会社は、自分たちでもオープンソースにコミットしていることがあり、GitHubのアカウントを持っていたりする。そういう会社は、コードを通してその会社の文化を知ることができるので良い。

【質問】
Haskellのような関数型言語について。

【回答】
あまりやったことがないからわからない。
ただ、PSGIはラムダ計算の要素も取り入れていると思う。

2012/07/07

Eclipseのプロジェクト内にローカルのファイルへのショートカットを作成する方法

そんな需要は一般にはないかもしれないが、俺にはあるんだ。

ショートカットを作りたいフォルダを右クリック->[New]->[File]

[<< Advanced]セクションを展開し、[Link to file in the file system]にチェックを入れて、画像ファイルを指定する。[File name]は何でもいいが、拡張子は合わせる必要がある。

ショートカットが追加された。

ちなみに、ファイルシステム上にショートカットファイルが作成されるわけではない。

2012/07/01

VisualStudio2010ExpressでwxWidgetsを使う

Visual C++ 2010 Express Editionをインストールする。
wxWidgets(v2.9.3)をインストールする。

exeを実行すれば、あとはダイアログの指示に従うだけ。
以下、デフォルトの設定どおりC:\wxWidgets-2.9.3にインストールしたものとする。

C:\wxWidgets-2.9.3\build\msw\wx_vc9.slnをVisualStudioから開く。

ソリューションを右クリックし「バッチビルド」を選ぶ。
すべて選択」をクリックしてから「ビルド」を選ぶ。

C:\wxWidgets-2.9.3\samples\minimal\minimal_vc9.vcproj をVisualStudioから開く。
変換ウィザードなるものが起動するので、適当に「次へ」をクリックする。

ビルドして実行すればウィンドウが起動するはず。

以下、注意事項。

VisualStudio2010を使う場合、wxWidgetsのバージョンは2.9.3でなければならない。stableの2.8は使えない。wxWidgetsのwikiにそう書かれている。
バッチビルドはエラーが出るので、実際は何回かやった。やるたびにエラーが減っていくが、最終的にエラーゼロにはならず、エラーも減らないのでもうあきらめた。
最初はネットを見ながらサンプルファイルを手で作成していたがどうしてもビルドが通らなかった。wxWidgets Discussion Forumのスレッドを見るに、wxWidgetsにあらかじめ用意されているサンプルファイルから設定をパクるのが基本らしく、「ビルド通らねぇよ」系の質問に対する回答者が「That's why wx devs recommend to start working with already existing solutions...」と嘆息を漏らしていた。

2012/06/17

ディレクトリ配下のファイルを移動するRubyスクリプト

	require 'fileutils'

	def move_files(source, target, extension = '*')
	Dir::glob(source + '/*.' + extension).each do \|f\|
	FileUtils.mv(f, target)
	end
	end

	# 第3引数を指定しなければ全ファイルを移動する
	move_files('C:/', 'C:/hoge', 'html')

view raw move_files.rb hosted with ❤ by GitHub

2012/06/10

宮藤は私の妹です

ちょっと前にネットで話題になっていたが、Google翻訳で「yoshika is my sister」を英日翻訳すると「宮藤は私の妹です」と訳出される。

『ストライクウィッチーズ』というアニメに宮藤芳佳というキャラがいる。同作にはシスコンの気があるバルクホルンというキャラがいて、彼女は宮藤を自分の妹と重ねて見ているところがある。そういう度を過ぎた「お姉ちゃん」属性がネットでネタにされている。バルクホルンは「芳佳」ではなく「宮藤」と苗字で呼ぶため、「yoshika is my sister」に対する「宮藤は私の妹です」という翻訳は彼女のキャラを正しく反映した訳出になっているということで話題になった。

しかしこれどうやってんだ？　まず大きく分類すると以下の2パターンしかない。

(1) Googleにアニオタがいて、翻訳ルールに個別に手を入れてる。
(2) 翻訳用の言語リソースをネットから自動でかき集めたら勝手にこうなった。

試してみたら「yoshika」と入れた時点でもう「宮藤」と訳出された。ということは(1)説は排除されるような気がする。「yoshika」という名前の人物は実在・非実在関わらず一定数いるはずで、それらがみんな「宮藤」になったら困るだろ。というか俺の祖母も「芳香（多分この字）」なんだよ。試してみたら「yoshika is my grand mother」が「宮藤は私の祖母です」になるじゃないか。誰だよそれ。あれか？　俺の祖母は本当は実の祖母ではなくて「宮藤よしか」という実の祖母が俺の知らないところにいて、Googleはその圧倒的情報量でもってその事実を把握してるってのか？　ってそんなわけないだろ。

そうすると(2)か。このアニメは根強い人気があるので「yoshika」という音は「芳佳」でググられるケースが相対的に多いのだと思う。それを受けて「yoshika」に対する漢字は「芳佳」である確率が高いと判断できる。一方で「宮藤芳佳」という単語とそれがキャラクター名であるというメタデータもGoogle翻訳が使ってるコーパスにはあるだろ。だから「yoshika」→「芳佳」→「宮藤芳佳」→「宮藤」と出来るのはわかる。わかるが、そんなことする必要性がわからん。
コーパスでは「宮藤芳佳」は「芳佳」よりも「宮藤」と呼ばれる文例の方が多いのか？　だとすると翻訳の過程でより「呼ばれやすそう」な呼び方に置換しているということか？　いや、違うな「miyafuji is my sister.」は「芳佳は私の妹です」に訳出された。この推測が正しければ「宮藤は私の妹です」に訳出されないとダメだ。

同じような状態になる名前があるかどうか色々と試してみたが、見当たらない。というかそもそも作中で苗字と名前が同じような頻度で呼ばれるキャラというのがあまり思い当たらない。

Google翻訳は翻訳結果が間違ってた際に任意の値を正解として登録する機能があるが、それで誰かが「yoshika」に対して「宮藤」を登録して、その結果が全体にフィードバックされてるってオチじゃないだろうな？　

なんかそんな気すらしてきた。

2012/05/20

syntax error, unexpected '\n', expecting tCOLON2

c:\Sites\JobChecker>rake db:migrate rake aborted! c:/Sites/JobChecker/db/migrate/20120515111707_create_execute_units.rb:4: syntax error, unexpected '\n', expecting tCOLON2 or '[' or '.' Tasks: TOP => db:migrate (See full trace by running task with --trace)

こんなエラーが出て、なんだと思ったが、

rails generate model execute_unit name:string, comment:string, ...

みたいについうっかりカンマ区切りしてたせいでmigrationファイルにもコンマが混入してたのが原因。「t.string, :name」みたいになっていた。rails generateコマンドのほうでエラーにしといてくれよ。

2012/05/12

telnetでlsコマンドを投げるRubyスクリプト

	# -- encoding: utf-8 --

	require 'net/telnet'

	def get_file_list(address, username, password, dir_path)
	telnet = Net::Telnet.new("Host" => host_address) {\|c\| print c}
	telnet.login(username, password) {\|c\| print c}
	telnet.cmd('cd ' + dir_path) {\|c\| print c}
	telnet.cmd('ls -elR') {\|c\| print c }
	end


	# Main
	address = '1.x.xxx.xxx'
	dir_path = '/hoge/piyo/FUGA/'
	username = 'USERNAME'
	password = 'PASSWORD'

	get_file_list(address, username, password, dir_path)

view raw telnet.rb hosted with ❤ by GitHub

2012/05/03

ディレクトリ内のファイルの情報を取得するRubyスクリプト

	# -- encoding: utf-8 --

	require 'digest/md5'
	require 'find'

	# ディレクトリ配下のすべてのファイルにつき、ディレクトリパスとファイル名、
	# 最終更新日時とMD5チェックサムをハッシュの配列として返す
	def get_files_info(dir_path)
	files_info = []
	Find.find(dir_path) do \|path\|
	file_info = Hash.new
	next if File.directory?(path)
	file_info['file_path'], file_info['file_name'] = File::split(path)
	file_info['last_modified_time'] = File::stat(path).mtime.to_s
	file_info['check_sum'] = Digest::MD5.hexdigest(File.binread(path))
	files_info << file_info
	end
	return files_info
	end


	# Main
	dir_path = 'C:/test'
	infos = get_files_info(dir_path)
	infos.each do \|info\|
	info.each_value do \|v\|
	puts v
	end
	end

view raw get_files_info.rb hosted with ❤ by GitHub

2012/04/07

「依存関係の問題により google-chrome-stable の設定ができません」エラー

Ubuntu11.04にdpkgコマンドでGoogleChromeをインストールしようとしたら以下のようなエラーが表示された。

dpkg: 依存関係の問題により google-chrome-stable の設定ができません:
google-chrome-stable は以下に依存 (depends) します: libnss3-1d (>= 3.12.3) ...しかし:
パッケージ libnss3-1d はまだインストールされていません。
dpkg: google-chrome-stable の処理中にエラーが発生しました (--install):

$sudo aptitude install libnss3-1d 実行してから再度dpkgしたらインストールされた。

2012/01/08

「モバマス」ことアイドルマスターシンデレラガールズについて

モバマスというのは、2011年の12月くらいにMobageでローンチされたゲームのことで、「アイドルマスターシンデレラガールズ」が正式名称。元々「アイドルマスター」という人気コンシューマゲームがあり、それの愛称が「アイマス」だったために、モバゲーと絡ませて「モバマス」と呼ばれているようだ（「モゲマス」とも呼ばれてるらしい）。

さて、モバゲーと言えば、2ch/虹裏界隈では蛇蝎か親の敵の如く嫌われていたはずだった。
しかしこのモバマスの登場で流れが変わりつつあるような気がする。
以下の引用は今日の18時に虹裏に立てられたモバマスのスレからのものだが、これらのコメントは俺の課金式携帯ゲームへの認識を改めさせるものだった。いくらプラットフォームが嫌われていても、そこで提供されているコンテンツ次第でどうにでもなるものなのか？　こういうものこそキラーコンテンツと呼び得るものなのかも知れない。もちろんこれはもはや技術の領域を遠く超えており、マーケティングとデザインの領域の話だ。

やはり世界は技術ではなくマーケティングとデザインによって変革するものなのだなと改めて思った。

＞アイマスやりたさにモバゲー始めた人っているんだろうか？
ここにいる8割はそうだと思う

＞アイマスやりたさにモバゲー始めた人っているんだろうか？
いるさ！ここにな！

＞アイマスやりたさにモバゲー始めた人っているんだろうか？
去年の11月まではモバゲーとか思いっきり馬鹿にしてましたよ俺

＞アイマスやりたさにモバゲー始めた人っているんだろうか？
今までもしもしゲーアンチでした
今では重課金者です

＞皆どのぐらいお金使ったの
PS3本体が買えるくらい

＞皆どのぐらいお金使ったの？
12月からだけど20万ほど

＞皆どのぐらいお金使ったの？
今月は15000円
目的は果たせたしこれくらいの金額じゃ課金したとはいえないレベルだろう

＞皆どのぐらいお金使ったの？
３万くらい
ガチャで金かけるよりスタドリ漁っておけば良かったと
激しく大後悔中

＞完全無課金の衣装の集まらなさ
当たり前だ
本来服はお金で買うもんだぜ

＞このスレで万単位飛んでるのを見ると自制心が蘇る
俺は逆に周りが１０万突っ込んだとかそういうのみると
そこまでいきたくはないけどまだ平気だなと思ってしまう

モバゲースレなんてステマが立ててるって去年まで思ってた
でも始めて見て面白さにビックる！
こりゃみんな熱中するなあと思った次第

二次元裏＠ふたば「モゲマスのお時間」スレ（12/01/08(日)18:22:41）

Bloggerの引用個所のデザインの変更

以下のサイトを参照して、引用の表示方法を変更した。
http://walking-elephant.blogspot.com/2010/11/blockquote.html
http://www.css-lecture.com/log/css/blockquote.html

こんな感じになる。

code complex <> complex code