Okinawa.pm #4に参加

概要

2017/04/01（エイプリルフール）の13:00～18:00に，Okinawa.pm の4回目の集まりに参加しました．

日付が日付なので，「エイプリルPerl」というテーマでLT大会が開かれました．

 

第3回目と同じく，琉球大学東口付近の「ララプリモ」というお店の2Fで実施しました．

 

発表したネタについて

「エイプリルPerl」ということで今回はジョークがメインの回になると思ってネタをずっと考えていたのですが，結局当日まで思いつかず，LTの最後まで考えながらネタ作りをすることになりました．

ちょうどなんとなくQuine（自身と同じソースコードを出力するプログラム）で何かネタをやりたいなと思っていたところに，ぺんさん(@tompng)が素晴らしいQuine風自己書き換えプログラムのネタを披露していたので，それの原理を解読して真似してみようというチャレンジをしました．

LT参加者が全員発表を終えるまでの間に乱入するために，とりあえずQuineの書き方を調査．小飼弾さんのページにそれらしい解説ページがありますが，evalを持つ言語はたいてい同じような形でQuineを作ることができるので，そこから改良して「実行するたびにソースコードが進化していく」ようなものを作ってみることにしました（なので，厳密にはクワインではなく，あくまでもクワイン風，ということになります）

 

実行して出力されるコードをまた実行する，ということを繰り返すたびに，「April_Fool」の文字が１文字ずつ書き出されるというネタをなんとか完成させました．

 

gist.github.com

 

感想

あまり真面目ではないネタですが，実行するたびにソースコードが変化（完成）してゆくようなプログラム，というのをどうすれば実現できるのかといったことを考える切っ掛けになったので，個人的にはとても良かったです．

 

MapReduce::Framework::Simple 解説1（自ドメインブログからの転載）

自ドメインのブログからの転載です。2016年10月7日に書かれた記事です。 今後は技術的な内容をはてなブログで書いて行こうかなと思います。

MapReduce::Framework::Simple 解説1

不定期で、自分が作ったモジュールの解説を3回に分けて投稿してみるテスト。

以前、MapReduce::Framework::Simpleというモジュールを作った。

MapReduce::Framework::Simple : GitHub

MapReduce::Framework::Simple : CPAN

httpでリモートのサーバと連携して分散処理を実現するためのモジュールとなっている。

作成動機

CPANにParallel::MapReduceというモジュールがある。 これは、リモートへmapperとなるサブルーチンと処理の対象となるデータをssh経由で送りグリッドコンピューティングなMapReduceを実現するという2008年頃の古いモジュールで、エクスペリメンタルなものだった。

処理をworker（処理を依頼されるリモートのコンピュータ）に投げるときに、master（処理を依頼するコンピュータ）からはsshでパスワードなし公開鍵認証を使いworkerへログインできる状態になっている必要があるため、「気軽に分散処理したい」というケースではなかなか使えない。 その上、プログラムでエラーがあると、ssh接続が強制的に切られ、sshのプロセスが大量に残るということもあった。

もう既にMapReduceよりも使い勝手やパフォーマンスの良いプログラミングモデルがある上に、Hadoopなどのエコシステムが成熟しているわけだが、とりあえず「手っ取り早く環境が作れて、持て余している計算資源でグリッドコンピューティングして計算時間を節約したい。できればperlだけで完結させたい」というコンセプトで、Parallel::MapReduceのようにsshでリモートとつなげるのではなく、普通にhttpで接続するようなお手軽MapReduce環境構築モジュールを作ることにした。

インストール方法

cpanmなどで、MapReduce::Framework::Simpleをインストールすればmaster、worker共に最低限の環境構築は完了する。

 $ cpanm MapReduce::Framework::Simple

使い方

MapReduceの"Hello, World!“としてはワードカウントが取り上げられることが多いが、とりあえず、ランダムに生成した3万個の数字の合計・平均をリモートの3台のコンピュータに計算させてみることにする。

worker側の準備

まずは、workerとして使いたいリモートのサーバ上で、MapReduce::Framework::Simpleをインストールし、以下のコマンドでworkerサーバを起動しておく。

 $ perl -MMapReduce::Framework::Simple -e 'MapReduce::Framework::Simple->new->worker("/your_secret_path");'

最後の方にある"/your_secret_path"は、workerが起動する処理受付用のhttpサーバのパスになるので、他人に推察されにくいパスにすることを推奨する。 また、workerのhttpサーバは既にStarletがインストールされていればそれで起動するようになっており、そうでなければシングルプロセスのPlackで起動する。1つのworkerへ同時に幾つもの処理対象データを投げるような使い方をする場合は、Starletをインストールしておくと良い。

さらに、Starletはインストールしているが敢えてStarletを使いたくない場合は、newの引数に「force_plackup => 1」を与えればPlackで起動させることができる。

 $ perl -MMapReduce::Framework::Simple -e 'MapReduce::Framework::Simple->new(force_plackup => 1)->worker("/your_secret_path");'

masterのプログラム

master側のプログラムでは、処理対象のデータとそれを処理を受付けるworkerのURLを格納した配列リファレンスの配列リファレンス、workerで実行させるサブルーチンのリファレンス（mapperと呼ぶ）、workerから受け取った処理結果をmaster側で集約するサブルーチンのリファレンス（reducerと呼ぶ）の、3つを用意する必要がある。

まずは例題の通り3万個の数値を3台のサーバに分散処理させるため、以下のように配列リファレンスの配列リファレンスを作る。

my $data_map_reduce;
my $remotes = [
    'http://192.168.0.1:5000/eval',
    'http://192.168.0.2:5000/eval',
    'http://192.168.0.3:5000/eval'
    ];
for(0 .. 2){
    my $tmp_data;
    for(1 .. 10000){
        push(@$tmp_data,rand(10000));
    }
    push(@$data_map_reduce,[$tmp_data,$remotes->[$_]]);
}

基本的には、[<処理対象データ>,<workerサーバのURL>]という形の配列リファレンスを配列リファレンスに詰め込んでいく。

次に、mapperとreducerの書き方を見てみる。

# mapper code
my $mapper = sub {
    my $input = shift;
    my $sum = 0;
    my $num = $#$input + 1;
    for(0 .. $#$input){
        $sum += $input->[$_];
    }
    my $avg = $sum / $num;
    return({avg => $avg, sum => $sum, num => $num});
};

# reducer code
my $reducer = sub {
    my $input = shift;
    my $sum = 0;
    my $avg = 0;
    my $total_num = 0;
    for(0 .. $#$input){
        $sum += $input->[$_]->{sum};
        $total_num += $input->[$_]->{num};
    }
    $avg = $sum / $total_num;
    return({avg => $avg, sum => $sum});
};

上記のように、mapper reducerいずれも引数としてデータを配列リファレンスの形で受け取るように作り、 mapperでは平均・合計・レコード数を計算してハッシュリファレンスでreturn、 reducerではハッシュリファレンスの配列リファレンスをloopで回して最終的な平均値と合計を計算している。

無論、このコーディング方法はあくまでも一つの例である。 mapperの引数が必ずしも配列リファレンスの配列リファレンスである必要はなく、引数を一つだけ、返り値も一つだけという形になっていれば良い。 変数をひとつだけにするという約束事のために、リファレンスを使っているということに過ぎない。

mapperのreturnとreducerのinputの関係には注意が必要である。 各workerのreturnは、処理が完了した順番にmaster側の配列にpushされ、そのリファレンスをreducerのinputとして扱うという約束事なっているため、 このサンプルコードのreducerでは入力配列リファレンスのループ処理中のように $input->[$_]->{sum} といった形でmapperからのreturn内容を参照することができる。

最後に、作成したdata,mapper,reducerでMapReduce処理をmap_reduceメソッドで実行させるコードを記述する。

my $result = $mfs->map_reduce(
    $data_map_reduce,
    $mapper,
    $reducer,
    5
    );

print Dumper $result; # 結果確認用

最後の引数はmaster側でforkする引数となる。masterのメモリが許す限り、worker数以上の値を設定しておくと良い。

実行

master側のスクリプトを cal_avg_total.pl という名前で保存したと仮定すると、後は以下のコマンドで実行するだけでよい。

$ perl cal_avg_total.pl

実行すると合計と平均値が出力されるはずである。 正常に実行できなかった場合、workerサーバが起動されているか、URLが正しいかを確認。

まとめ

基本的に、workerの環境構築はMapReduce::Framework::Simpleをインストールするだけで良く、master側はmapperのreturnとreducerのinputの関係に従って処理を書いていくだけでOKだ。 MapReduceな書き方に慣れていない場合はそれなりに時間がかかってしまうが、そのあたりは練度の問題である。

このような方式の分散処理は、単一のサーバでは計算に数分・数時間・数日間もかかる程のデータ量で「高度に並列化された」問題を手っ取り早く高速化させたい場合に有効である。 ただし、数秒で完了するような計算処理では通信オーバーヘッドが原因で逆に遅くなってしまったり、シーケンシャルに処理をしなければならないような「高度に並列化できない問題」ではそもそも分散処理ができなかったりするのでそこはご注意を。 このモジュール自体はその他にも、ウェブスクレイパーを並列に実行したり、バッチジョブを並列に実行したりなどといった使い方も可能ではあるが、そのような用途では普通に単一サーバ内でParallel::ForkManager等を使った方が良い。

次回

今回の例はランダムに生成した数値のsumとavgをMapReduceで計算させるという内容だったが、次回は実践的な使い方を紹介したいと思う。

Okinawa.pm #3に参加

開催概要

2017/01/21（土） 13:00～18:00に、Okinawa.pmとして3回目となる集まりに参加しました。

Okinawa.pm #3 を開催しました！ | Okinawa Perl Mongers

 

今回は「去年 Perl で作ったもの、今年 Perl で作りたいもの」というテーマのトークとなりました。

場所は琉球大学東口近くのララ プリモの2F、シナジールーム。琉大周辺でちょっとした会を開くなら最高の場所かもしれません。

トーク内容まとめ

最初に発表内容をまとめておきます。

  1.  @yasuXS さん： 去年はZabbixからWindowsに対してエージェントレス監視を実現するためにWMIとか使って色々やったというお話。今年は環境構築自動化とかに力を入れていきたいとのお話。
  2.  @aokabin_ さん： 自己紹介（「石高大介」は本名じゃなくて、「意識高い」系の言動を周りからよく指摘されることから付けたあだ名。意識高い = イシキタカイ = イシダカ = 石高）と、Workflowyが便利なのでオススメですというお話。
  3.  @adokoy0001（私）： 去年作ったYCGL::Lite（自分専用モジュール）のこと、MapReduce::Framework::Simpleの使い方とそれをネタにした雑談（B::Deparseとかevalとか、useとrequireの違いとか）。今年は自分専用のラッパーを作ってみたいという感じのお話もしました。
  4.  @AnaTofuZ さん： テーマ通りに、Perlで作ったものを紹介。会場に入ってから発表するまでの間に、Net::Twitterを使ってコマンドラインのTwitterクライアントを作ったとのことで、そのお披露目もやっていただきました。
  5.  @CodeHex さん： 去年はアルバイトで取り組んでいる自然言語処理系の便利ラッパーモジュール Text::Shirasu を作ったお話。今年はPlackのMiddlewareを自分で作って、Mojoliciousの機能を拡張していきたいという抱負を宣言（敢えてMojoliciousのプラグインではなく、Plackのエコシステムに乗っける方向で）。

感想

テーマが新年会的な感じでとても良かったと思います。

各自、自分が去年何をやったのかを振り返るきっかけになったと思いますし、多少は無理矢理にでも今年の目標を作っておいた方がPerlへの愛と情熱を持続させやすくて良いでしょう（至上主義っぽい発想）

今回、参加者は6名でした。Perl関連の集まりに現役の学部生が3名も参加するというのは、なんか凄く嬉しいですね（うまく言語化できない）

YAPC::Asia Tokyo 2015に行ってきた

最後のJPA主催YAPC::Asiaに参加するべく、社長と交渉してYAPC::Asia Tokyoのチケット代＆宿泊費＆旅費を会社支給にしてもらった沖縄在住のadokoy(Twitter: @adokoy0001)でございます。

 

場所はビッグサイトの会議棟（あの逆ピラミッドの中）で、なにげに初めて入るので道に迷いました。

今年は沖縄の知人エンジニアも数名参加していたので、その日のイベントが終わったら近くの居酒屋で二次会というパターンが３日間続きました。

去年のYAPC::Asiaは毎晩貸し切りのバーでエンジニアと交流するチャンスがあったのですが、今年はDay 1の夜だけだったのが個人的には少し残念でした。（沖縄から来た知人と毎晩飲んでいたのですがｗ）

 

ということで、以下、印象に残ったことや学びのあったセッションを備忘録代わりとして書いていきます。

 

Day 0: 前夜祭

今回は２トラックで30分のセッションを3セットという流れ！

つまり合計6つのうち3つは見れない・・・ので、泣く泣く見たいセッションを選びました。ほぼ無限に湧き出る缶ビールを飲みながら前夜祭開始！最高の夏。

うずらさんによるPHPのお話 - "PHP帝国の逆襲！"

PHP有識者のうずらさんが発表中に時折「ｶｼｭｯ ... ｺﾞｷｭｺﾞｷｭ ... ﾌｰ ...」と言いながら進められたPHP7のお話。

PHP5.6から6をすっ飛ばしていきなり7になった理由は割愛！色々と膨大な発表資料が用意されていたようですが、聴衆のご意見により大部分が割愛されてしまいましたｗ

個人的には以下の点に興味を持ったので後で調べてみようと思います。

  • PSR-7の詳細と実戦投入の実績があるオススメ実装等
  • PHP6周辺の事情
  • 各WAFのパフォーマンス

 

 "Perlワンライナー入門"

私はあまり使うことはないのですが、ワンライナー独特の書き方などに興味があったのでちょいと聴講。

-lオプションや-nオプションを使えるようになりたいなと思いました（小並感

あと、String::Trigramをuseしてワンライナーを書けばかなり高度なサーバ管理作業ができるので便利ぽかったです。

 

"我々にできるOSSとそのコミュニティの育てかた"

現在トレジャーデータ所属の@tagomorisさんのお話。

fluentdとか具体的なものではなく、OSS一般でどのようにそのコミュニティを発展させた方が良いのかというお話がメインでした。

いろんな人を巻き込んで良いコミュニティが育つのは、意外にも「公開時点で動きはするが、機能の充実度や完成度は低め」のものだという話は面白かった。たしかに、初めからほぼ完成されていて特に不満のないOSSならばそれを改善しようという欲求が生まれにくく、活発なコミュニティになりにくいところがあると思います。

 

Day 1

オープニングが終わって会場はそのまま、Perlの生みの親 Larry Wall のセッション！

 

"メリークリスマス!"

もちろん私は英語力がないので同時通訳のレシーバーを装備。Larryはホビットの冒険と指輪物語が大好きで、発表内容もそのメタファーがかなり多め。

発表タイトルは"メリークリスマス！"、これはPerl6の正式版をクリスマスにリリースするという宣言でもありました（今年のクリスマスとは言っていない。いや、言った！）

 

"Web由来の組み込みエンジニアの半年間のすべて 〜WebとiOSとBLEとハードウェアデバイスのこと〜"

webエンジニアの方が会社を辞め、ハードウェア製造業を起業した話。

ソフトウェアならばリリースした後に発覚したバグは比較的簡単に対処できますが、ハードウェアを作って出荷するような業態だとそれが難しく、まず工場で生産ラインを作るまでにしっかりとテストをする必要がある、など、意識の違いを感じました。

webエンジニア時代に得られたスキルが工場管理のアプリ作成で役に立った等、かなりいい話が聞けました。

また、電気回路の知識の無さを補うため、その手の業界で働いていたシニアエンジニアを「エンジニアモード」というサービスを使って探し、アドバイザーになってもらったとのこと。そういうアドバイザーをマッチングするサービスがあるなんて初めて知りました。

「本番でarduino使うのは、大学の入学式にお母さんと一緒に行くようなものだよね」という発言が個人的には名言だなと思いました。後半の文を今後積極的に使っていきたいです。

 

Matzさんのセッション

最後までトークタイトルはTDBのまま・・・と思いきや、「Toward Brain-aware Design」というタイトル。Rubyの父、まつもとゆきひろさん。

言語の設計についてのお話と、近年（あいまい）のシェルスクリプト再評価に乗っかったStreemという自作言語（というかフレームワーク的な？）の紹介がありました。

とりあえずRubyで「やらなきゃよかった」という設計がPerlやLispに影響されたものだったというのは納得でしたｗ

また、内部的な振る舞いを決定する型については「プログラマが型による微妙な振る舞いの違いを意識せずに書けるのが理想」「絶対に型は書きたくないでござる！」と言っていました。

工夫すればOSが上手くCPUを使えるように組めるシェルスクリプト・パイプ、そのようなピタゴラスイッチプログラミングを書きやすくするStreemへの期待が高まりました。

 

"Podcastを支える技術、エンジニアのためのWebメディア、そしてCPAN"

ゆーすけべーさんのwada.fm運営のお話。

まずはCDNとかそういう高価なサービスを利用することなどは考えずに、普通に配信しても速度的に意外と大丈夫とのこと。でも.fmドメインが高いのはネックらしいです（ですよねー

Podcastをやるようになってからはマイクにこだわるようになったとのことで、私はさっぱり分からなかったのですが、機材についてかなりマニアックな話が。

質問コーナーで回答した「カラオケボックスだと周りの音楽が入ってくるし、店員さんが勝手に入ってくることもあるからダメ。ちゃんとしたスタジオを借りてやった方がいい」という知見はムダ知識として雑談などに活かせそうでしたｗ

 

"Lightning Talks Day 1"

ライトニングトークで知人の@gongoZさんがトーク！

PHPのregister_globalsという凶悪機能についての割りと真面目で面白いお話でした！

gongo.hatenablog.com

 

PHPほとんど使わないのですが、ヤバさだけはかなり伝わりましたｗ

みなさん、サポートがまもなく切れるので5.4以上に頑張って移行しましょう。

 

 

Day 2

最終日。途中でショルダーバッグをどこかの会場に置き忘れてしまい焦って探しまわった・・・見逃したトークが・・・(T_T)

見つけた人が届けてくださって、クロージング終了直後に受け取ることができました。感謝！

 

"Discover the Microsoft Azure"

Microsoft Azureのデータセンターの様子や、サービス内容の話などなど。

スケールが大きな話が多く、ずっと「おぉ・・・」と呟いておりました。

例えばデータセンターにあるサーバを集約したコンテナ（物理）の話では、そのコンテナ内のマシンの何割かが壊れたらコンテナごと破棄する、とか。大富豪っぽいインフラ運用にも思えますが、考えてみると中身を開けて修理することによるリスク（作業ミス、配線ミスによる障害の拡大）を考えると合理的！

データセンター１つの面積はフットボールコート16面分、ジャンボジェット機が32機入るぐらいの広さ、など・・・。

あと、機械学習関連のサービス、プラットフォームも充実している模様。

ちなみに最近ではAzureでLinux VMの数が増えているようです。

 

"データ分析基盤を支える技術"

 このセッションは絶対に見たかったので早めに会場に入って着席しました。

高速な集計や柔軟な構造を実現するためにKVSやドキュメント指向なデータベースを使うこともありますが、やはりRDBはあらゆる面で便利なので使いたい。でも、データ量が増えるとパフォーマンス、スケーラビリティが悪くなっていく。

ならばパラレルRDBMSを使おう、というお話。

データ分析基板に関する技術を俯瞰するような形で説明がなされていましたが、かなり細かく深い話もあったので個人的に印象に残ったものを箇条書きでまとめます。

  • Schema on WriteとSchema on Readの長所・短所
  • ETLではなくHDFS上にELしておいて目的別にそれぞれTを並列実行
  • MapReduceとTezの説明
  • パラレルRDBMSプラットフォームはAmazon Redshift、Google BigQueryなど
  • 自前でパラレルRDBMSを構築するより、まずはプラットフォームの利用を検討しましょう
  • 可視化ツールはなんだかんだで商用ソフトがスゴイ（Tableauとか）

 

 

まとめ

今回がJPA主催最後のYAPC::Asiaでした。

クロージングで@lestrratさんが「YAPC::Asiaという名前はJPAのものというわけではなく、自由に使っていいものです。」と言っていました。主催は違えど、来年以降もきっとYAPC::Asiaはありますよね！

営業色が薄く「技術に対して純粋である」雰囲気のYAPC、今年も最高でした！

 

YAPC::Asia Tokyo 2014 に行ってきました

YAPCに初めて参加してきました。

知人の@masakystさんが「チケットを買ったけど行けなくなってしまった」ということで、YAPC::Asia Tokyo 2014のチケット（個人スポンサー）を譲り受け参加させて頂くことになりました 、adokoy（Twitter: @adokoy0001) でございます。

たまたま会社の用事で出張する時期と奇跡的に連なっていたので、自腹はほぼゼロという美味しい機会に恵まれました。

また、最終日は地域.pm（地方.pm）ミートアップにYomitan.pmの代表としてスーパーハッカーの皆さんの前でpmの活動や地元のことをちょっとだけアピールしてきました。

とりあえず会場として使っていた"北谷町"のネイティブな発音をアピール出来たので大満足です。

 （読谷はなぜか標準語でもネイティブな発音と同じになっちゃうんですよね）

一人で初参加ということもあってぼっち気味だったのですが、トークスケジュール後の貸し切りバーでは、話しかけてくださる方や酒のアシストもあって、とても充実した時間を過ごすことが出来ました。

 

Day 0 ： 前夜祭

乗り換えの駅で間違って逆方向に行ってしまいましたが、なんとかオープニングに間に合いました。

18:30から開始、@yusukebeさんによるオープニング（ｶﾝﾊﾟｰｲ）

今回の前夜祭はwebアプリが主題で、１名あたり持ち時間10分で休憩挟まずの150分間ぶっ続けトーク。

 

 GeekDojo

@__papix__さんによるGeekDojo開発のお話。

GeekDojoはプログラミング学習をサポートするための、弟子と師匠のマッチングサービス。

papixさんの所属するGaiaXの社内研修として、なんと5週間で開発したとのこと。

その過程で、

・「テストは無いよりマシだからとにかく書く」

・「コマンド一発で色々なことが出来るように作り、属人性を排除」

・「botを使うと便利」

ということの重要性を確認できたそうです。

 

 hrhm.info（MetalTube）

@hondallicaさんによる、ヘヴィメタル動画検索サイトのお話。

元々は自分が使うためだけのサイトだったが、今では95カ国ほどからアクセスがあるとかで、バンドメンバーの移籍などからバンド同士の関連性なども分析できるとのこと。狂気駆動開発。

ちなみに私はヘヴィメタルについて全然詳しくないのですが、パワースピード・メタルの「Helloween」がちょっと好きだったので検索してみると、いい感じで581曲もリストアップされました。便利すぎます。

 

 pplog

@ppworksさんによる、ポエムを残すことができるブログのような何かのお話。

最新の投稿一件だけを表示させるというコンセプトのもと、超絶短期開発（1,2日？）で、まずは作って「自分で使う」。

障害発生時のメンテナンス画面にはツイートを表示しておくという発想が面白かったです。

 

 ゴミ収集カレンダー

 @syachiさんによる、とある自治体のごみ収集関連情報サイト作成のお話。

市のサイトにある伝統的な（？）配布PDFと音声読み上げ用HTMLから正規表現で情報を抽出し、iCal形式で配布するという、社会貢献精神あふれる取り組みでした。

ゴミの種類と回収日をまとめたものを、エリアごとに選択してダウンロードできるようなサイトになっています。gomical.comというドメインがいい味を出していますね。

 

 wri.pe

 @masuidriveさんによるwri.peというメモアプリの紹介。

デスクトップに「なんとか.txt」とかいう名前でメモを残していたりする僕のような人間にオススメのツールでした。

 

 ttyrecからGIFアニメを作る話

@sugyanさんによる、ターミナル操作をgifアニメーション化する便利ツールのお話。

技術系のブログなどでターミナル操作のgifアニメを何度も見かけるようになったと思っていたら、そういう便利ツールがあったんだな～と。

すぎゃーんさんは既存のものをImageMagickの依存なしにgoで作り直したとのこと。さらに、後半ではJavaScriptで全て完結したものを紹介。凄すぎぃ！

 

 GIFMAGAZINEの話

@razokuloverさんによる、GIFMAGAZINEというgif画像投稿サイトのお話。

動画の投稿ではなく、あくまでもgifアニメにこだわりを持つクリエイターのためのサービス。多くの投稿サイトが4MB程度の制限を設けることが多い中、GIFMAGAZINEでは20MBまでアップロードオッケー。

gifもストリーミングできたらいいんですけどね。

 

 togetter

@yositosiさんによる、togetterのお話。

まさかとは思っていたのですが、サービス名はやはりルー大柴の「トゥギャザーしようぜ」というノリから来ているそう。

ヤフーに在籍されていた頃に、特定イベントのハッシュタグ付きツイートをかき集めるための自分専用ツールを作ったところ社内で大好評。それがきっかけになったそうです。

あと、孫正義さんがustでtogetterについて言及したことがあったり、年間4000近くもまとめちゃうスーパーヘヴィーユーザの存在が、サービスを広げる上で大きな役割を担っていたとのこと。

 

 クイズを支える技術

 @debilityさんによるクイズ番組。じゃなくてHTML5のキャンバスとSocket.IOを使ったクイズ番組風余興システムのデモ。

 ブラウザ上でク◯ズダ◯ビーとミ◯オネアを完全再現。

回答者側の回答パネルで、正解だったら色が変わる例のアレも再現されており、色を変える操作等も司会者側からリアルタイムに出来るというSocket.IOの有効活用事例でした。

debilityさんも会場の皆さんも著作権的な部分を気にされていました。

 

 Day 1 (8/29)

本編一日目。

この日も電車の乗り換えをミスったらしく、中目黒駅まで行くはずの電車がなぜか霞ヶ関で終点（電車よくわからない）。オープニングを聞き逃してしまいましたorz

この日のトークスケジュール終了後は、同じ建物内にあるHUBというバーに行きました。

HUBではしばらくぼっちだったのですが、Fukuoka.pmの代表の方が話しかけて下さったり、@charsbarさんや@tokuhiromさんとも結構長い時間（30分以上？）お話することができました。

 

この日のトークから気になったものをピックアップします。

 

「Perl meets Real World ~ ハードウェアと恋に落ちるPerlの使い方 ~」

まこぴーさんのトーク。

PerlからRaspberryPiやArduinoといったモノを動かすお話。

Perlからハードウェアを動かすというあまり馴染みのないテーマだったので凄く興味を惹かれました。

RaspberryPiはLinuxが乗っているのでもちろんPerlは使えるし、ハードウェアの操作も可能とのこと。

Arduinoはいわゆるマイコンなので、非力過ぎてとてもPerlを動かすことは無理。だけどFirmata（フィルマータ）というプロトコルで外部のPCからPerlでArduinoをコントロールすることは可能とのこと。

最後に、Perlでつくられたウェブアプリから、初音ミクにネギを振らせる予定だったのですがうまく動作せず断念。

ハードウェアを操作するためのウェブアプリをPerlで作れるということで、個人的にはかなり衝撃的な内容でした。

 リンク：

Perl meets Real World 〜ハードウェアと恋に落ちるPerlの使い方〜 - YAPC::Asia Tokyo 2014

 

「One layer down below」

yapcasia-talk-one-layer-down-below/index.org at master · gugod/yapcasia-talk-one-layer-down-below · GitHub

@gugodさんによる、booking.comのプロダクトを紹介するセッション。たぶんこのセッションはgihyoさんもまだ記事にしていないようので、ほんの少し解説。

テーマというか、メッセージとしては「もう少し下のレイヤーに手を出すと面白いし、パフォーマンスの改善になるよ」というお話でした。

ちょっと気になったのが、Hijk（ハイク）というhttpクライアント。

pure perlで200行（だったかな？）程度のプログラムだけど、不要な機能を徹底的に削った結果LWPの約13倍速く（curlよりちょっと速い）動作するというもの。

booking.comさんではHijkのような尖ったプロダクトだけではなく、もちろん場合によっては高機能なものも必要に応じて作るそう。specialized vs generalizedのトレードオフ。

最後に、便利なツールがどんどん出てきて「結果だけを知っているが、その原因を知らない」で済む状況になっているが、それに満足せずに掘り下げていくと面白いものが見れる、といったことをおっしゃっていました。

このセッション、トーク自体は英語だったのですが、配られたレシーバを使って同時通訳の日本語で聞けました。英語苦手な私としてはとてもありがたかったです。

しかも発表者の@gugodさんも、スライドのところどころに日本語を入れてくれてて凄い心遣いを感じました。

 

 Day 2 （8/30）

 YAPC::Asia Tokyo 2014の最終日！

この日は地域.pmミートアップに参加。基調講演ではtypesterさんのキャリアについて、貴重なお話が聞けました。

参加者の投票で決めるベストトーク賞はなんとuzullaさんのPHPのお話に！（PerlのカンファレンスでPHP）

YAPC::Asia Tokyo 2014の参加人数は1300人を超え、世界最大のYAPCに。拍手喝采

最終日もHUBで色々な方とお話することができました。結構酔っていたのですが、moznionさんとYAPC::Okinawaやろうぜみたいな話や、雅なperl入門のkaz_hiramatsuさんとPerlへの愛着を語り合ったような記憶があります。

地域.pmミートアップ

この日の13:00からは地域.pmミートアップということで、イベントホールでちょっとだけスピーチさせて頂きました。

 当初の予定は7（+2)のpmでしたが、飛び入り参加+1で10のpmが集結。

有名pmが集まる中で、Yomitan.pmの代表（代理ですが）として、以下の様な内容で過去の活動、次回開催予定、また、野望的なものを語らせて頂きました。

・Yomitan.pmを立ち上げた。まだ非公式pmなので登録したい。

・JAWS-UGとの合同も含めてpmの勉強会としてはこれまでに3回開催

・第一回でplenvの紹介があり、私個人としてはとても勉強になった

・第三回で機械学習ネタで発表したこと

・次回は9月下旬頃を予定。（具体的にはまだ決まっていない）

・勉強会のネタをgithubにテキストとして上げて、教科書的なものを作りたい(野望)

 

すごい人たちの前でのスピーチでしたが、レッドブルを飲みながらのゆるーい進行も相まってそれほど緊張せずに楽しむことができました。

 

全体的な感想

今回初めてYAPCに参加しました。世界中でよく使われているモジュールを作っている方々の顔が拝めるだけでなく、実際にお話できる（割りと気軽に）というのが凄いです。

また、YAPCはあくまでもPerlのカンファレンスですが、実際は言語を問わずPHPやGo、はてはSwiftまでもトークテーマとしてオッケーという柔軟さがあるため、Perlを知らない方が参加しても得られるものが多いのではないかと思います。

最後に、

 

YAPCｻｲｺｰ!!

 

 

 

手書き文字認識とか

 

一年ほど前、訳あって会社で簡単な手書き文字認識の応用アプリの作成を依頼されました。

 

ちょっと調べてみるとzinniaというOSSがあったので試しに使ってみることに。

http://zinnia.sourceforge.net/index-ja.html

 

手書き文字の筆跡、つまりストローク毎の座標変動をS式で取り込み、SVMで識別しやすい特徴空間へ変換しています。zinniaで扱っている特徴空間はこちらを参照。

 

既に紙に書かれた文字を読み取って識別するのではなく、タブレットなどで記入させてそのストロークの情報が完全に保たれている前提で識別。このような方式をオンライン手書き文字認識と呼ぶそうです（OCRなど、前者の方式は「オフライン」と呼称。また、「オンライン学習」とも全く違う概念です。）。

また、zinniaとは別にtomoeという手書き文字認識ソフトで使われている学習済み筆跡データのセットがあり、zinniaは初期状態でその学習モデルを利用することを前提としています。もちろん、ユーザ側で学習用筆跡データ（S式）を用意すれば学習モデルをカスタムすることも可能です。

 

かなり便利だなと思いきや、この学習セットは日本語で使われる大量の文字が登録されているのですが、書き順などを間違えるとなかなか認識してくれないという問題があるのです。

それもそのはず、ひとつの文字の学習に対して一つの筆跡しか登録されていません。

さらに、数字やカタカナひらがななどの文字カテゴリが全て混ざった状態なので「カ（カタカナ）」と「力（ちから）」の区別が付きにくいなどの問題もあります。

 

ということで、数字やアルファベットなどの文字カテゴリ毎に、さらに一つの文字に対して複数のS式フォーマット学習データを作るためのアプリを作成しました。

HW-Collector： https://github.com/adokoy001/HW-Collector

で、コレを使って試しに作成した学習データがこちら

データセット： https://github.com/adokoy001/HWR-Learning-Data-Sets

 

ニッチな用途ですが、お遊び機能として手書き文字認識を使ってみてはいかがでしょうか。

（手書きの文字や記号で、ある機能へのショートカットを実行させたりなどなど・・・）

 

BI（Bussiness Intelligence）ツールについてのメモ

仕事でとある商用BIツールを使う機会があったので、調べたことをメモ。

初めて使ったのでかなり当たり前のことばかり書いてます。

BIツールの目的：

ERPパッケージやPOSなど、企業が管理している売上データなどを分析し、意思決定の支援を行うためのツール。

例えば、チェーン展開している店舗の売上を地域別・商品別・日付別に集計・予測、仕入れや予算の決定に役立てるなど、データウェアハウスと連携した分析を行うことが主な目的。

BIを使う理由：

データの構造

通常の業務でアクセスするデータベースは高速に集計を行うことに適した構造ではないことが多いため、通常はBIツールで分析を行う上で都合の良い構造（スタースキーマ、スノーフレークスキーマなど）へ変換（ETL）し、データウェアハウスへデータを投入する。

「都合の良い構造」と表現したが、これは例えば「日付・地域・売上を持つテーブルをJOINして対象フィールドを関連付けるだけで日付・地域別売上集計表が作成できる」といった形である。通常、売上げデータなどをファクトと呼び、日付や地域等の分析の軸となる項目をディメンションと呼ぶ。

このように、複雑で分析的な用途で都合の良い形へデータ構造を変換し、集計・予測・データマイニングを行うことをOLAPという。

ところでなぜ最初からこのようなスキーマで業務データを構築しないのか？というと、マスターデータ、マスターテーブルの変更、取引データの削除や更新に適さないからである（当たり前ではあるが）。

構造が変わった分、元々のデータ構造で定義されていたリレーションは使えないため貼り直す必要がある。

結果の出力

BIツールを使うメリットとしては結果の出力が容易であるということ。

 「年度ごと、月ごと」などの時間的なディメンション、「地域ごと、商品ごと、購入者年齢ごと」といったディメンションの組み合わせを選ぶだけで、適切な表やグラフを自動的に作ってくれる。

たったこれだけのことではあるが、やはりプログラミングに詳しくない一利用者が簡単に、思い通りにレポートを作成出来るということが最大のメリットのようだ。

 

 

今回はとりあえずここまで。