「第17回自然科学研究機構シンポジウム」に行ってきた

生佐藤勝彦と生立花隆を見に、というのは半分冗談で、「記憶の脳科学」というテーマが、面白そうだったので。

時間は、朝の10時前から夕方5時半過ぎまで、昼休み以外は休憩もあってないようなもので、聞いているだけでもかなり体力が必要でした。
会場はほぼ満員。高校生大学生がいるのは分かるとして、セカンドライフを満喫してそうな方々までいたのが驚きでした。自分も、年をとっても知的欲求が衰えないようありたいものです。

全体的な感想として、記憶と一言で言っても、短期、長期、種類としてもエピソード記憶など、種類があって、少しずつその機能を明かしていっているのだなあ、と。あるきっかけで劇的に解明されるものではなくて、地道な研究あるのみ、の分野なのかなあ。

話を聞いて、「記憶」に残ったこと（正しいかどうかは分かりません）をダラダラと書いていくと、

記憶とは何か

• 物忘れに関する様々な患者の事例を紹介して、なかなか面白かった。
• 「思い出せない、忘れた」とよく言われるが、記憶は忘れるのではなくて、たくさん覚えすぎていて取り出しにくくなる。
• とっさに記憶を取り出せる方が驚異だ
• 記憶の種類はいろいろある
• 意味記憶 do you know what ~?
• エピソード記憶 do you know remember ~?
• エピソード記憶は、感情と紐づくと記憶に残りやすい(恐怖の記憶、楽しかった記憶)
• 思い出せる最初のエピソード記憶は3歳ごろのことが多い。ちょうど、文章が扱えるようになる時期で、何か相関があるのかもしれない
• アルツハイマーなど記憶障害を持った人との関わり方は「説得より納得させる」、が良い。
• 相手の言っていることが事実と異なっていても、相手の中ではそれが真実なので、説得しようとしても、相手は納得せず、同じことを何度も聞いてくる。
• 逆に納得すると同じことを聞いてこない。

記憶を人為的に作り出す

• 記憶の蓄積の仕方
• セルアセンブリ仮設
• 細胞の集合体で覚える(符号化)
• 学習に活性化した細胞間のシナプス結合が強化され、想起時は強いシナプスで結合した細胞群が活性化する。
• これが2012年頃に実証された
• 人工的な方法で記憶を作り出す
• 発表者の研究成果の説明、だったと思う
• 記憶をゼロから作り出すことはまだ無理だが、二つの独立した記憶を連合させることができた。
• 記憶が連合するときは、それぞれの記憶で痕跡細胞(想起するときに活性化する細胞群)がオーバーラップする、という仮説を元に、人工的にそれぞれの記憶の痕跡細胞群を同時に活性化させることで、独立した記憶を人工的に連合できた。

見る、覚える、思い出す

• 正直あまりよく分かりませんでした・・・
• ニューロンの発火順序を解析して、視覚の物体同定における、神経回路のつながりを調べた、みたいな話だったと思う。
• 解析装置の性能が上がって、こういう厳密な解析ができるようになったんだろうなあ、という感想

近年のコンピュータ将棋の進歩と機械学習

• コンピュータ将棋の話。自分にとって一番馴染みがあるところだけど、他の発表に比べると特異な感じ。
• 2000年代中頃から、現在の強さを支える技術が登場してきた
• 強い理由
• 詰め将棋が強い
• 間違えない　人にとってはそれだけで恐怖
• 読みの深さの進歩
• 探索技術の進歩や、並列探索が可能になった
• 局面の評価能力向上
• 評価関数の作成に機械学習が使われている
• それまでは人手でチューニングしていてあまり良くなかった
• 学習方法
• 指し手の比較による学習
• プロの指し手と指されなかった手を比較し、プロの指し手の方が点数が高くなるように調整する
• 機械学習の効果
• 自然な序中盤になった
• 手作業のときと比べて、評価できる項目の数が増加した
• 将棋が強くなくても、プログラムが作れる。棋譜さえ手に入れれば誰だって……

記憶と脳指紋

• 丁度最近の日経サイエンスでも記事が出ていた
• 脳指紋（brain fingerprint）
• 脳波を使った嘘発見器（本当発見器？）
• P３００という脳波を検知する
• 刺激提示してから約300ms後にPositiveな反応を示す
• 本人は思い出せなくとも、かつて見たものを見せられると自然に発生する、らしい
•  海馬が主要な発生源
• 犯罪調査などに利用できる、かも
• アメリカでは使われている
• 日本では、テレビドラマの題材にも使われているが、実際は及び腰

ワーキングメモリ：脳のメモ帳

• 人間は、多くの場合、記憶に集中すれば良いわけではなく、行動しながら記憶していかなければならない
• 処理（計算）＋保持
• この時活躍するシステムがワーキングメモリ
• ワーキングメモリのモデル
• 短期記憶や長期記憶と、それらを制御する中央実行系（どこを覚えるべきか選択的に注意を制御する、とか）からなる
• 一度に利用できる処理資源は限界
• ワーキングメモリのサイズを測るテスト
• リーディングスパンテスト
• いくつかの文章を読みながら指示された単語を記憶していく
• 若い人なら、平均で三文くらいいけるらしい
• 点数の低い人
• 単語を覚えられないわけではない、注意の制御がうまくできていない（指示にはない余計なものを覚えてしまう）
• 高齢者も、注意の制御が低下する

健忘症と認知症

• エピソード記憶の障害　＝　健忘
• 逆行性健忘症　障害が発生した時より過去を忘れる
• 前行性健忘症　障害が発生した以降、新たに覚えられない
• 健忘症には一時的なものと永続的なものがある
• 一時的なもの　アルコール・・・
• 永続的なもの　脳卒中などで、脳に障害が起こる
• 認知症
• エピソード記憶の障害　＋　それ以外の高次脳機能の障害

シンポジウム

• 立花隆がテレビ番組の裏話をしていたけど、その番組を見ていないので、さっぱり分からず。。。
• 脳トレというのがあるけど、脳にいいかは誰も実証できない（比較実験で、脳トレやった人やらない人を何十年もかけて観察していかないといけないから）。酒飲んでるよりは良いかもしれないけど。
• そう言われりゃ、そりゃそうだろうね。

「qpstudy 2013.01」へ行ってきた

http://atnd.org/event/201301qpstudy
初参加。一度は行ってみたいなあとずっと思っていて、テーマ的にも興味があったので。いきなり登壇者にビールが振る舞われていたので、ここは「酒（と書いてガソリンと読む）でも入れて、言いにくそうなことでもぶっちゃけ言い合おうぜ」って会なのでしょうか？？

テーマはDevOps。ここ数年で言われるようになってバズワード感漂うものでした。
世の中的情報や、企業が宣伝するDevOpsはツール的な話が多いけど、基本は組織、ビジネス、カルチャーに関わる考え方みたいなものらしいとのことです。「Dev側とOps側でどうやって連携して行くか。そしてこのカルチャー、考え方の手段として、Ops側にDev的なツールや方法論で運用管理の効率化を目指しましょう（またはその逆？）」という理解で間違っていないのかな。
だから、今までDevとOpsが良好な関係を保っていたなら、今更DevOpsなんて……、ということになるらしい。

勉強会は登壇者間のパネルディスカッション形式でしたが、あまりにも話が発散しすぎてまとまった感じはしませんでした。もともとまとめる気も無かったらしいですが（てか、ディスカッション形式で話がまとまった事なんて見たこと無いけど）。
とにかく様々な立場の人が居ます。単純にDevとOpsに分かれるものではなく、その中でも自社で全部開発から運用しているところの人や、受託開発をしているSIerの人、開発も運用もそれぞれ別の会社にお願いしてそれらのマネジメントをしている人まで。立場によって状況も考え方も契約形態も異なる以上、一概にDevOpsと言ってもそれに期待する者はそれぞれ異なって、統一的な見解など出せようはずもない、という事みたいです。

でも、DevOpsという言葉が（どの程度の範囲かは知らないけど）脚光を浴びるということは、今のままでのDevとOpsの関係について疑問を感じている人が少なからず居ることは確かだろうと思う。この辺りは誰もが一家言持っていそうです。


問題は境界線で発生すると言っていた方がいましたが、DevとOps以外にも実際はお客さんの立場、営業、企画側の立場も登場してくるし、下手するとDev, Dev間やOps, Ops間でも境界線もあるくらいなので、火種となる境界線は枚挙にいとまがないなあと。DevOpsの考えを突き詰めて行くと、組織や会社のあり方にまで発展するのは自然な流れなのだろう。

個人的には、DevとOpsの両方の理解があって、双方の立場を考慮して決断してくれるマネージャが居てくれるだけでも大分違うのかなあと思います。そんなスーパーマンそんなに居るのかという問題はありますが。
あと、DevがOpsに手を出す、OpsがDevに手を出すには、という話もありましたが、サーバの立て方、プログラム言語を知っている程度ではあまり役に立たないのかなあと思ったりもします（もちろん必要ないとは言わない）。技術とはもっと違った、運用時に気をつける勘所とか、手順作成の考え方とか、開発方法論とか、仕様取り決めの駆け引きとか、そういった、経験とか政治的な知識も必要なのかなあと。DevOpsがカルチャーでマインドだと言う以上、DevがOpsのカルチャーを知る、OpsがDevのカルチャーを知る必要があるのだろうと思う次第です。
うん、確かにスーパーマンだ……。


最近気になることとしては、DevとOpsの連携を密にしたいという流れがある一方で、DevとOpsの分離を明確化したいという流れもある。理由は、会社が違う、部署が違うから責任範囲を明確化したい、収益構造（Dev, Opsのそれぞれどこでコストがかかっているのか）を明確化したい、セキュリティ上の理由、なあなあ開発、運用を無くしたい（非属人化）等があるそうな。
この二つの考え方は相反するのか、両立できるのだろうか、と思ったりします。

以上、取り留めのない感想。

「YAPC::Asia 2012」へ行ってきた

YAPC::Asia 2012へ行ってきました。YAPCは初めてでした。
感想は、Perlユーザ、アツいよ。

以下個人的な感想です。オレオレ脳内変換がまぎれている可能性もあります。

What Dose Your Code Smell Like?

Larry Wall氏のご尊顔を拝見しました。ありがたやありがたや。

タイトルと喋っている内容がだいぶ違う気もしますが、ソーティングを例に、Perl5で書かれたスクリプトをPerl6対応に書き換えていく、という内容でした。

なんかPerl5とPerl6って違う言語じゃん、って感じです。

所々、functional programmingという言葉が聞こえてきて、関数型言語を意識しているようです。もっとも、どの辺りが関数型なのか私にはよく分かりませんが。

Web::Security beyond HTML5

YAPCなのにPerlの話は無く、タイトルにHTML5とあるのにあまり関係ないという。。。

ブラウザにまつわる脆弱性やAjaxの話、そしてモダンなブラウザに含まれている保護機構に関する話でした。ブラウザの挙動も考慮してWebアプリはセキュリティ対策を考えて行く必要がある、との事でした。

Web開発者はかなりの知識を求められるなあと思います。こういう知識を少なくとも一人で片手間でで集めるのは限界があるだろうなあとも。会社にもこういうセキュリティを専門に扱う人達がきっと必要なのだろう。

リアルタイム通知システムの舞台裏

通知システムの構成に関するお話。push通信を実現するのは、notificationサーバの多重化やapplicationサーバとの連携を考えると難しい。Rabbit MQを利用することで、notificationサーバをクラスタリングして、client側からもapplication側からも多重化を意識させないように構成した、というような内容でした。

個人的にはWeb-DBぐらいのシステム構成しか触った事が無いので、新鮮なお話です。

Perl初心者が作った運用サーバ

自作の構成管理ツールToryoのお話。DSLでサーバのあるべき状態を記述して、サーバのセットアップやテストが出来る、というような内容でした。

インストール用のバッチスクリプトをメンテするのが楽か、DSL等の設定ファイルをメンテするのが楽かは、人によりけりな気はします。でも私はこういう仕組みは欲しいなあと思いました。

平均レスポンスタイム50msをPerlで捌く中規模サービスの実装／運用

Best Speaker 第3位をお取りになられたとの事です。技術的な内容もさることながら、アドネットワークの仕組みが興味深かったです。

SSP(Supply Side Platform 広告枠の販売を支援する仕組み？)とDSP(Demand Side Platform 広告主の広告掲載を支援する仕組み？)というのがあって、ページを表示する100ms程度の間に、DSP間で広告枠をオークション(RTB Real Time Bitting)が行われているそうです。

なかなか凄いな、広告業界。期待されるレスポンス時間が〜100msだなんて、比べる対象が違うけど、ソーシャルゲームよりもシビアかも知れないと思ってしまいます。

そんな厳しい制限を守る為に、出来るだけ外部通信しないとか、SSD使うとか、地道な対策が打たれているとの事です。立派なインフラは一日にしてならず、って所でしょうか。

「新しい」を生み出すためのWebアプリ開発とその周辺

Best Speaker 第1位をお取りになられたとの事です。サービスの企画の方法とそれの作り方のお話でした。

企画（何を作ろう？）は、哲学、アイデア、テーマ、コンセプト、デザインが一貫したものを考える必要がある、との事です。これがあればサービスがぶれないし人に説明する時も有効らしいです。この辺りはWebに限らずどんなサービスの企画でも共通する話かなと思います。

あと、実際にアプリを開発する時に、フレームワーク等の選択は、規模を考えて、それに似合ったものを選ぶのが良いらしいです（どんな最新の技術を用いても、対象の規模ではあまり意味が無い、的な事にならないように）。

Perl今昔物語

他の言語系カンファレンスに比べると（少なくともこの前のPyConに比べて）、インフラやプラットフォームに関する発表が多い気がしました。このセッションによると、YAPCでもインフラ系のネタはこの東京でのみ多く、他のところでは多くない、大手Webサービス業者がPerlを利用しているからかも、という話があった。そうなのかも知れません。

世の中的にインフラ運用ツールは何で書かれている場合が多いのでしょうか？大変気になります。

Perlで始める！初めての機械学習の学習

機械学習大盛り上がりらしい。リーダブルコードの本を差し置いて機械学習の本の売れ行きが高いとか。色んなところで（社内外を含めて）勉強会が行われているらしいので、自分も勉強したいなあと思ってます。ただ15000円はなかなか勇気がいります。

初めてのYAPCでした。面白かったです。

あとは、もっと周りの人ともお話し出来るようにならないと。。。

人に話しかけるの苦手なんです。

「PyCon JP 2012」へ行ってきた

PyCon JP 2012へ行ってきました。PyConの前日には、AWS Summitへも少しだけ行っていて、いやあ、今月はイベントが多い。

１日目は全部出て、２日目は午後だけ参加しました。トラックの数が多くて、何を聞いて良いのやら悩みました。
ただ、行ってはみたものの、私のPython力は、たまに個人用ツールとして使っている程度で、また、Webフレームワークとも無縁なので、うまく理解出来なかったセッションも多かったのです。力不足を感じました。もっと通常時にPythonを使える機会を増やせば良いのだろうけど。

Sphinxの話はもっと聞きたかったけど、部屋に人が溢れかえってしまっていたため断念。残念です。
あと、お昼ご飯のサンドイッチがおいしかったです。。。

と，感想を書いてみたけど、何を言いたいのか分からない文章になってしまいました。

HTML5 Conferenceに行ってきた

HTML5 Conference 2012へ行ってきました。参加人数1000人ってとんでもない数だなあ。午後以降はルーム移動の度に、入り口で待つ行列の長さが凄かったです。
会は大変為になるもので、スタッフ皆様に感謝申し上げます。

以下、気になったものを徒然なるままに書きます。

基調講演

• 今後、Webアプリが簡単に拡張、他サービスと連携出来るように、Web Componentって技術、考えが重要になってくるらしい。
• 現時点であまり想像がつかないのだが、おいおい勉強していこうと思う。
• ブラウザに様々なAPIが追加されてきている。あくまで構想レベルだけど、中にはかなりローレベルな通信レイヤーを扱えるAPIもある。幅広いシステムに影響を与えかねず、故にこれまで以上に安心・安全に対する責任が出てくる、とのこと。登壇者がネットワーク系の会議でこの話をしたら、出席者の顔が曇っていったとか......。
• 私も顔が曇る側の世界の人間だから、気持ちは分かる。まだまだアプリ屋とインフラ屋の溝は深い。

HTMLとかCSSとかAPIとか -2012秋編-

• HTML5の後にも新たな機能追加は続き、あくまでHTML5ってある時点のスナップショットらしい。
• ......さて、ついていけるだろうか？
• Custom DOM Elementsってのが検討されていて、カスタム要素をAPI付きで定義出来るらしい。
• なんかライブラリ作ったり使ったりする人だと便利そうかも。

豪華な3Dを扱うAPI: WebGL、そしてThree.js

• WebGLは触ったことあるが、面倒くさいというのは同意。超絶技巧な3D表現を目指すなら、シェーダーを扱うことは必須だろうけど、とりあえず3DってことならThree,jsは便利そう。物理演算と合わせて遊んでみたいのだけど、重い腰がが上がらない。

ブラウザを介した新しいリアルタイムコミュニケーション

• WebRCTの話。ビデオチャットが簡単に出来る（今のところビデオチャットしか出来ない）という話。
• 実際はネットワーク周りの罠に嵌って、使うのは難しい気もする。実際に使用例が分からないが、どれ位使われるだろうか。
• GetUserMediaは普通に面白そう。遊んでみたいが、重い腰が上がらない（汗）。

スペシャルセッション

えっと、頂いてしまいました、一番スペシャルな景品を......。
本当はクイズで2位だったので、別の景品だろうと軽い気持ちで壇下に来てみれば、一位の方が名乗り出なかったため、結果、繰り上げで私が頂いてしまいました。壇上では緊張して、まともな対応が出来ずスタッフの皆様、会場の皆様に申し訳なく思います。ごめんなさい。でも、あまりに予想外だったんです。

私が２位だったのは、きっと半分ぐらいの人が正解することより、早押しでランキングに表示されることに力を入れていた為かとwww。あと、回答はほとんど勘だったので運が良かったことかと（今年の運を使い果たしたかも）。APIとかjavascript系の話が出てたら、もっと酷い点数だったと思う。でも全くヤマ勘でもなく、今までのHTML5とか勉強会等で聞いた話が役に立った部分もあることは確かで、勉強会に参加した甲斐があったとも思います。

何はともあれ、素晴らしい景品ありがとうございます。嬉しい、と同時に、どう使えばいいのだろう......

ターミナル勉強会

人のターミナルの使い方が気になる今日この頃で、ターミナル勉強会へ行ってきました。

•  togetter http://togetter.com/li/278836

誰得（マニアック？）なコマンド、オプションが解説されたり、sshの便利な使い方などが内容でした。

普段定型的なコマンドしか使わない（使えない）ので、珍しいオプションなどが知れて面白かったです。sshの使い方は勉強になりました。

でもって結局最後はmanに聞け、なんだなあ、と。

OS(Linux, Unix, Mac??)によってオプションの意味が変わる場合があるので、両方の環境を使わないと行けない人達に取っては大変なのよねえ〜〜。でも、使い方自体はmanで知らべればいいけど、このコマンドで、こんな使い方も出来る！ということを知っておくのは重要だよね、と思います(でないと調べる気が起こらない)。

あと、devlove主催の勉強会には行ったの初めてでしたけど、結構静かだったなあと。本当はこういう勉強会の方が多いのかも知れないけど。

コンピュータビジョン勉強会ハッカソン

コンピュータビジョン勉強会ハッカソンに行ってきました。
みんな黙々と作業していたので、実質3人しかつぶやいていなかったらしいtogetterはこれ。

自分は、C++版のOpenCVをちゃんと使った事無かったので、C++版を触ってみることにしました。
具体的に実施したのは、http://opencv.jp/のcookbookの画像処理の部分をちょこちょこ覗きつつ、最終的にtemplate matchingの項をほぼ写経してみました。
template matchingの結果(類似度のマップみたいなもの)と、オリジナル画像に一致した場所を表示したもの結合画像はこれを参照にしてます。
下記のコードになります。C++的にこういう書き方が良いのか分かりませんが。

#include <opencv2 core.hpp="" core="">
#include <opencv2 imgproc.hpp="" imgproc="">
#include <opencv2 highgui.hpp="" highgui="">
#include <iostream>

cv::Mat mouseMat;
void onMouse(int event, int x, int y, int flag, void*) {
    if ((x < 0 && mouseMat.size[0] < x) || (y < 0 && mouseMat.size[0] < y)) {
        return;
    }
    switch (event) {
        case cv::EVENT_LBUTTONUP:
            switch (mouseMat.channels()) {
                case 3: {
                    uchar b = mouseMat.at<cv::vec3b>(y,x)[0];
                    uchar g = mouseMat.at<cv::vec3b>(y,x)[1];
                    uchar r = mouseMat.at<cv::vec3b>(y,x)[2];
                    std::cout << "(" << y << "," << x << ")" << int(r) << ":" << int(g) << ":" << int(b) << std::endl;
                    break;
                }
                case 1: {
                    uchar gray = mouseMat.at<uchar>(y,x);
                    std::cout << "(" << y << "," << x << ")" << int(gray) << std::endl;
                    break;
                }
            }
            break;
    }
}

void viewImage(cv::Mat img, std::string title) {
    mouseMat = img;
    cv::namedWindow(title, CV_WND_PROP_AUTOSIZE|CV_WINDOW_FREERATIO);
    cv::imshow(title, img);
    cv::setMouseCallback(title, onMouse, 0);
    while (1) {
        int key = cv::waitKey(0);
        if (key == 27) break;
    }
}

cv::Mat loadimage(std::string name, int flag=1) {
    cv::Mat image = cv::imread(name, flag);
    if (image.empty()) {
        std::cout << "can not open file " << name << std::endl;
        exit(1);
    }
    return image;
}

void templateMatching(std::string searchfile, std::string templatefile, std::string outputfile) {
    cv::Mat searchimg_orig = loadimage(searchfile);
    cv::Mat templateimg_orig = loadimage(templatefile);
    
    cv::Mat searchimg;
    cv::Mat templateimg;
    
    double s_factor = 320.0 / searchimg_orig.cols;
    cv::resize(searchimg_orig, searchimg, cv::Size(), s_factor , s_factor);
    cv::resize(templateimg_orig, templateimg, cv::Size(), s_factor, s_factor);
    
    cv::Mat resultimg;
    cv::matchTemplate(searchimg, templateimg, resultimg, CV_TM_CCORR_NORMED);
    
    cv::Rect answer(0,0,templateimg.cols, templateimg.rows);
    cv::Point max_point;
    double maxValue;
    cv::minMaxLoc(resultimg, NULL, &maxValue, NULL, &max_point);
    answer.x = max_point.x;
    answer.y = max_point.y;
    cv::rectangle(searchimg, answer, cv::Scalar(0,0,255), 3);

    cv::Mat combined_img(cv::Size(searchimg.cols + resultimg.cols, searchimg.rows), CV_8UC3, cv::Scalar(0,0,0));
    cv::Rect roi_rect;
    roi_rect.width = searchimg.cols;
    roi_rect.height = searchimg.rows;
    cv::Mat roi(combined_img, roi_rect);
    searchimg.copyTo(roi);
    roi_rect.x += searchimg.cols;
    cv::Mat resultimg_3c;
    cv::Mat tmp_img;
    cv::convertScaleAbs(resultimg, tmp_img, 255);
    cv::cvtColor(tmp_img, resultimg_3c, CV_GRAY2BGR);
    roi_rect.width = resultimg_3c.cols;
    roi_rect.height = resultimg_3c.rows;
    cv::Mat roi2(combined_img, roi_rect);
    resultimg_3c.copyTo(roi2);
    
    //viewImage(resultimg_3c, "template matching");
    
    cv::imwrite(outputfile, combined_img);
}

int main (int argc, const char * argv[])
{
    if (argc < 3) {
        std::cout << "bad argments" << std::endl;
        exit(1);
    }
    std::string imagefile = argv[1];
    std::string templatefile = argv[2];
    std::string outputfile = argv[3];
    std::cout << "inputfile   :" << imagefile << std::endl;
    std::cout << "tempatefile :" << templatefile << std::endl;
    std::cout << "outputfile  :" << outputfile << std::endl; 
    templateMatching(imagefile, templatefile, outputfile);
}

故あってskytreeの写真が100枚以上あったので、この写真に対して実行してみました（shellなりスクリプトなりでさくっと実行しました）。対象が分かりやすいので、晴れの日の写真はほとんどうまく場所が取得出来ました。
全結果をのせる事はできないので、うまく言ったものと失敗したものを載せておきます。

テンプレート画像

成功したもの

失敗したもの(曇りの時の写真だからしようがないか)

C++版の方がCに比べると書きやすい印象を持ったけど、肝心のC＋＋がちゃんと書けないのよねえ・・・。

HTML5の勉強会に行ってきた

行ってきました。久しぶりに。人気なのでなかなか枠に滑り込めない。。。
テーマは電子書籍。電子書籍には関わってないけど勤め先的には興味がある分野です。
凄い聞きがいのある勉強会でした。

いつも通りのソートも何もしていないざっくりなまとめと感想

• iBook Autherが使ってみたくなりました
• EPUB3のイメージが、HTML+CSS？からXML+HTML+CSSに変わりました。。。なかなか複雑な仕様のようです。リーダを作るってことはWebブラウザを作るってことに等しい気がしてきます。ブラウザベンダーに有利な展開です。
• ↑とPDFやKindleのフォーマットなど百花繚乱な様相を呈してくると、ワンソースマルチユーズの夢を見たくなります。見る側のアプリも大変だけど、作る側のアプリはもっと大変なようです
• 電子書籍は紙媒体のようにきっちりと固まったデザインではなく、デバイス依存になってしまう、と言うことを認めないと、作れない（コストだけがいたずらにかかる）とのこと。さもないと、今後ますますリーダが多種多様化して、Webアプリのブラウザ互換以上に、制作者にとって辛い戦いが待ち構えているような気がしてきました。
• どうしてもレイアウトを崩したくないならEPUBではなくてPDFを使おう、みたいに目的に応じてフォーマットをうまく使い分けていく必要があるようです。
• 電子書籍は、Webの有料化を推し進めたものである、という発想は無かったので新鮮です。
• 生高橋メソッドが見れて良かったですww。
• 以上のことを見てみると、まだまだ電子書籍の普及には長い道のりがありそうです。特に制作側。消費者側は比較的すんなり受け入れそうだけど、制作側の意識改革が必要になってくるのだろうと思いました。書籍と言う言葉に騙されて、単純に紙媒体の延長で考えると痛い目に合いそうです。似て非なるものだと思って、紙媒体だけでも、Webでも出せない、電子書籍特有の付加価値が付けていく必要があるのだなあと思いました。

CROSSと言うイベントに行ってきた

niftyが主催していたCROSSというイベント、IT系の勉強会が沢山集まった会に行ってきました。
そこでデータマイニングCROSSのセッションを聞いてきました。ビックデータとかいう単語が流行って、会社でもやりたい的な話が漏れ聞こえてくるし、最近機械学習の勉強をしたので、気になっていました。

技術的な話というよりは、そもそもデータマイニングってどういうところでどういう風に使われているの？という内容で、パネルディスカッションも エンジニアよりも経営者寄りやマーケティング関係の方が多かった気がします。

色々話を聞いた感じだと、（特に2011年は）Hadoopとか基盤周りの整備が進んで、大規模データが解析出来る環境が整いつつあるけど、それをどう活用するかは今からだ、今後基盤技術の理解が出来る人（エンジニア寄り）とデータを理解出来る人（マーケティング寄り）が歩み寄って、真の（？）データ分析技術者のニーズが増えてくるだろう、と言うことだと思いました。（データ分析技術者が弁護士並みにもてはやされるってのは若干眉唾だけど）

また、データを解析した結果を、クライアントに分かりやすく納得出来る説明も重要、とのこと（解析技術の細かいこと言っても困るしなあ、、、と）。

Hadoopとかを整備して、大量データさえ用意すれば、ビジネスに利益をもたらすような情報が自然と抽出されるわけではない、ってことらしい。まあ当たり前だけど。。。目的を持って解析をしないとね、ってことなのだと思いました。
結局、基礎重要、って話に戻ってくるのだなあ。

odstudy 2011.11 に行ってきた

odstudyという主にドキュメントに関するらしい勉強会に行ってきた。
現在、サーバ・インフラの仕事をしていながら、純粋なそっち系の勉強会に行ったのは実は初めてのような気がする。その世界にも神と呼ばれたり、仙人と呼ばれる方々がいらっしゃるらしい。。。

テーマは「属人化をなくすために」ということで、前半トークセッション（LT）、後半がディスカッション＋その発表でした。まとめとかはtwitterで#odstudyで検索すればそのうち見つかる事でしょう。。。

ディスカッションとその発表が面白く、色々考えさせられました。いくつか覚えている範囲で、勘違いも多々あるかと思いますが。（書いている時点でまだまとめとかが無いので、うろ覚えだけで書いてます）

• 自分はディスカッションに参加したチームの内容だけど、ドキュメントをwikiで管理すると、情報が分散される→情報が何れが最新かとかが分からなくなる→結局人に聞く→属人化orz。を防ぐために、wiki書き方にルールを設けましょう、システム的に制限を加えると効果的（運用部隊に開発出来る人が居ると良いなあ。。。）。全てのドキュメントを同じレベルで運用すると死ぬので、レベル分けして、内容の精査とかもレベルに応じて扱おう、というのが参考になりました。
• ディスカッションの中で、システムの変更にあわせて、システムの監視とかが自動的に追加されるような構成管理があると良いし、ドキュメントも自動で最新に変更されると良いねえ、なんて話も。とんでもなく難しいかと思いますが。
• 属人化を排除した方が良いものもあれば、属人化はそれなりにメリットもある（SPOFが倒れない限りは障害対応が早い、標準化する時間が必要ない、小さい案件なら特に）。
• ドキュメントはどの程度のレベルの人にあわせて書かなければいけないのか？グッド○○○の人でも出来るようにしなければならないのか、運用する側にもそれなりに知識レベルが必要で、属人化は排除し無ければならないが、属グループ化ならそれなりに行けるのでは？
• ドキュメント管理にPDCAサイクルの考え方を導入して、継続的なメンテナンス出来るようにしよう。
• ドキュメントを書く事によって属人化は排除出来ない。あくまで属人化の問題を減らすために行っている。ドキュメントは手順書ではなく、教科書だと思って書け。またドキュメントはあくまで自分のために書くと思えば、モチベーションとかも上がるし、真面目に書く。ドキュメントを書く事自体は（会社的に）評価されないこともあるので開発部隊が運用のためにドキュメントを書こうとしても、モティベーションが上がらない。運用部隊が自分たちのために（ドキュメントが無いと自分たちの仕事が出来ないから）、開発部隊に協力してもらって書いた方が良いのでは？

もうちょっとあったような気がするけど、などなど。色々参考になりました。会社の人達にも共有したいなあ、と思える事も多々。

最後にとてつもなくとりとめの無い個人的感想を、、、

• 人が介在する以上、属人化って言うのは完全排除は無理なのだろうなあ。理想は、工場とかの一通り訓練を受ければ誰でも作業可能な製造ラインなんだろうけど、、、
• でも、その人が倒れた時に最低限の引き継ぎが行えるように、ドキュメントを残しておく事は意義があるし、特に長期間のシステム運用においては立ち上げの時のメンバーと現在運用中のメンバーは大半が入れ替わっていて、その際の引き継ぎコストを下げるためには不可欠だろうなあ。
• 個人的なドキュメントと属人化の問題って、ドキュメントを如何にメンテナンスしていくか？かなあと思っています。
• システム構成が変わってドキュメントも修正する必要があるし、時にはドキュメントのリファクタリングも必要だと思っていますが、特にPDCAのPとDは出来てもC以降が難しい。時間がないとか、現在うまく行っているものを何故あえてメンテナンスして修正する必要があるのか、という心理的不安。さらには、手順はあっても何故その手順になっているのか、なぜこのようなシステム構成なのかと言う歴史的経緯や思想的な部分が、必ずしも残っていなくて（それこそ口答伝承されている程度）、手順を直したくても直す拠り所となるものが無い、とか。
• システム運用においては、属人化は絶対に排除出来ない、その上で、その人が倒れた時に被害を何れだけ最小限に留めるか、という想定で進めた方が良いのだろうなあ。

考え始めると難しいなあ、しかも明確な答えなんて多分無いと分かっているのに。。。

あと、システム運用側以上に属人的になっているのは営業サイドのような気がする。営業倒れたら代わり居なさそう。人とのコミュニケーションが発生する以上、これも仕方ないかなあww。