卒業と入学

先週末で大学院修士課程を修了しました。科目聴講生時代を含めると2年半通ったことになります。
会社勤めをしながらの大学院であった為、途中半年間の出張もあったりと非常に苦しい時もありましたが、無事乗り切ることができました。何よりもこのような状況を支えてくれた妻に感謝します。

2年間の修士課程から何を得たのかを考えてみると、技術的なことは当然ながら、研究の進め方や考え方・プレゼンテーションといったソフトスキルまで多くのことを得たと実感しています。
自分のスキルを縦軸と横軸で考えると、2年前は縦横どちらも経験相応に伸びていたと思います。但し、複数に伸びている縦軸同士が上手くリンクしていなかったり、横軸の伸びが甘いことから曖昧な知識のもとで何となく進めていた部分がありました。このような状況を打破する為に、もう一度学び直そうと考えました。
結果的に、当初の目的はクリアでき、業務を進めていく中でも自分の様々なスキルが向上していることが日々実感できています。
また、研究として「SNSにおけるプライバシー侵害」をテーマとして、現代社会のプライバシー侵害への考え方、機械による侵害要因分析と検知手法を研究しました。入学前は自分がプライバシー侵害の研究をするとは考えても見なかったですが、今後更なる技術革新が進んでいくなかで本研究テーマは非常に良いテーマであったと思います。当然、1年間の研究からは大きな成果が出せておらず、改善点も多くありますので博士後期課程で同テーマの研究を継続することにしました。
博士課程ではこれまで以上に困難があると推測しますが、3年後に学位が取れるよう研究に邁進していきます。
最後に2年前と同様に博士課程へ進むことに対して、快諾してくれた妻に感謝します。

InfoTalk Summer Workshop 2012(Amazon DynamoDB Hackathon)に行ってきました

InfoTalk Summer Workshop 2012(Amazon DynamoDB Hackathon)に行ってきました。
DynamoDBにさわるのは初めてでしたが、非常に有意義な時間でした。今回はチームに分かれてDynamoDBを使用したアプリを作ったりしました。
このDBの一番の特徴は読み書きのThroughputをコントロール出来る点です。これにより運用コストを低減することが出来ます。
但し、現状はThroughputのダウンが1日1回のみの制限がありますので、注意が必要です。

ハッカソンで作ったものではないですが、DynamoDBがどのように動くのかを確認する為に、
CouchDBに流し込んでいるPythonスクリプトを変更し、DynamoDBに入れ込むようにしてみました。
PythonからDynamoDBを扱う場合は、botoを使用します。なお、本スクリプトを実行前にテーブルは作成済みであることとします。

# -*- coding: utf-8 -*-

import sys
import tweepy
import json
import time
import jsonpickle
from datetime import datetime
import re
import boto

CONSUMER_KEY = 'YOUR CONSUMERKEY'
CONSUMER_SECRET = 'YOUR CONSUMER_SECRET'
ACCESS_TOKEN = 'YOUR ACCESS_TOKEN'
ACCESS_TOKEN_SECRET = 'YOUR ACCESS_TOKEN_SECRET'

auth = tweepy.OAuthHandler(CONSUMER_KEY, CONSUMER_SECRET)
auth.set_access_token(ACCESS_TOKEN, ACCESS_TOKEN_SECRET)

conn = boto.connect_dynamodb()
table = conn.get_table('twitter')
count = 0

class CustomStreamListener(tweepy.StreamListener):

    def on_status(self, status):
        results = {}
        try:
            if re.match(u"[ァ-ヶーぁ-ん]" , status.text): 

                pickled = jsonpickle.encode(status)
                results = json.loads(pickled)
                del results['_api']

                item = table.new_item(
                    hash_key=int(results['id_str']),
                    range_key=20120729,
                    attrs={'user': results['author']['screen_name'],
                           'text': results['text']})

                item.put()
                #print item

        except Exception, e:
            print >> sys.stderr, "Encountered Exception:", e
            pass

    def on_error(self, status_code):
        print >> sys.stderr, "Encountered error with status code:", status_code
        return True

    def on_timeout(self):
        print >> sys.stderr, "Timeout..."
        return True 


streaming_api = tweepy.streaming.Stream(auth, CustomStreamListener(), timeout=60)

try:  # sample(): streaming_api.sample()
    #streaming_api.filter(follow=None, locations=QUERY)
    #streaming_api.filter(follow=None, track=QUERY)
    streaming_api.sample()

except Exception, e:
    print >> sys.stderr, "Error: '%s' '%s'" % (str(datetime.now()), str(e))

finally:
    print >> sys.stderr, "disconnecting..."
    streaming_api.disconnect()

RICOH賞を受賞しました

大学院の有志チームで参加していたRICOH & Java developer challenge2011でRICOH賞をいただきました。
アプリケーション機能は非常にシンプルでしたが、顔認識技術とビジネスモデルとの組み合わせ、アプリケーションとしての完成度が評価されたのではと思います。また、水着の三愛がリコーの傘下といこともあり、画像解析 × ファッションレポート のアプリケーションが受け入れられたのもあるようです。

グランプリの北陸先端技術大学院さんも顔画像技術を使用されており、エンタープライズアプリケーションにおいてもこれらの技術は注目されているのだと感じました。
また、他チームのアイデアや実装は素晴らしく、若い方々の発想力に驚きました。もう少しブラッシュアップすればRICOHからアプリケーションとして出ても良いのではと思われるアプリケーションもあり良い刺激をもらえました。

約8ヶ月ほど、チームで活動をしてきましたが、最後に良い結果が出て良かったです。チームの皆さんありがとうございました。

RICOH & Java Developer Challenge 2011 最終選考 提出しました

大学院の有志メンバと参加しているRICOH & Java Developer Challenge 2011の最終選考に提出できました。
9月末に1次選考(Emulator編)を無事通過し、最終選考へ向けて実機上でMFPアプリケーションを開発してきました。
5月にチームを発足してから半年以上と長期に渡って活動してきましたが、ようやくシンプルながらも面白いモノが完成しました。
このプログラミングコンテストからは技術的な部分のみでなく、チーム活動の進め方という点に関しても多くの得る事あった為、参加して良かったと思います。

最終選考は2012/1/12(木)です。あと、Ustreamでも放送があるそうです。

HTC Flyer買ってきました

夏休みで台湾旅行に行ったので、HTC Flyer wifi versionを買ってきました。
結果的に価格は日本から通販で買うのとほぼ変わらなかったようですが、
これから購入する方の参考になるかもしれません。

台北にはいくつか電気街があり、今回廻ったのは忠孝新生駅の北側にある八徳路電気街となります。
その中でもビル一棟に電気器具や部品、パソコン、周辺機器などを取り扱う店がひしめき合う光華商場に何度か足を運んできました。
台湾におけるFlyerの価格ですが、上記の光華商場内のお店では大体16500NTD ≒ 43395円でした。(但し、中古です)
ここから免税申請を行うと5%が返ってきます。ですので、約41225円程度となりますが、免税申請に関しては自分から切り出して聞かないとスルーされる可能性があります。
また、どのお店も価格交渉があまり効かず、下げてくれても500NTDでした。
#1NTD ≒ 2.63円 (2011/9/17時点)

結局、外の正規HTCショップで購入したのですが、どこのお店も17900NTD ≒ 47077円の設定で、免税申請して44723円といったところです。
あと、現金かカード利用により本体の値段が変わりますので、何かを購入予定の方は予め現金を持って行くと良いです。(現金の方が当然安い)

なお、420グラムと言えども電車内で持ったままの状態では若干重く感じましたが、
iPad程重くもなく、視線も集めにくいので良い機種だと思います。

プログラミングコンテストから在宅勤務を考える

プログラミングコンテストにチームで参加してみて、技術面以外にも勉強になった事が多々ありました。
3/11の地震以降、在宅勤務を導入しようと模索する企業が増えていますが、今回のコンテストから在宅勤務を成功させる為にはルールが必要だと感じたので、在宅勤務を成功させる為の必要条件を考察しました。

なお、私達のチームでは基本的に各自の家で空いている時間を使ってタスクを進め、
コミュニケーションはSkype上でテキスト形式(chat)で行いました。

ある程度チーム単位で動く在宅勤務を成功させる為の最低限必要なルールは以下と纏めました。

  1. 活動時間帯
  2. 在宅勤務の場合、個々が時間を上手く利用出来るようになる一方、
    通常であればすぐにコミュニケーションを取って確認出来ていたような事項が
    すぐに確認出来ないといった弊害が生まれます。
    よって、在宅勤務と言えども、活動時間帯は同じにするのが良いと感じました。

  3. コミュニケーションは密に
  4. ここではテキストベースでコミュニケーションを取るのを前提としていますが、
    相手の顔が見えない分、コミュニケーションロスが頻発します。
    例えば、仕様が全メンバへ伝わりきれていなかったり、ある事項に対してのOK/NG、了承/拒否の返事が無かったり等です。
    コミュニケーションポータルサイトを利用し、全情報はこのサイトを参照するのも良いと思いますが、
    個々が積極的にコミュニケーションを取っていこうとする姿勢がまず重要です。

  5. グレーゾーンに対する対応
  6. タスクを分けて作業している場合、必ずグレーゾーンにあるタスクが発生します。
    これをどちらが取るかは不毛の戦いであり、対面式のプロジェクトでもこれらのタスクは浮いたままになることが多いと思います。
    このようなグレーゾーンタスクをどちらともなく積極的に解消していく事、またそのような気持ちを持つ事が必要です。

  7. 足りない知識や技術
  8. 個々がタスクを進める上で、足りない知識(情報)や技術が必ず出てきます。
    そのような時はまず自分で調べようとする気持ちが大事です。結果的に分からなくても良いと思います。
    その時に改めて他メンバに聞けばよいです。

  9. 同じゴールを描く
  10. 最も大事なのが、全メンバが同じゴールを共有することです。
    対面式のプロジェクトでも、同じベクトルを向く事が重要ですが、在宅形式のプロジェクトでも同様です。
    ゴールが共有出来ていれば、これまで挙げてきた事項を自主的に進めてくれる可能性があります。

対面式プロジェクトであったり、同じ在宅形式のオープンソースソフトウェアプロジェクトであれば、
これらの事項は発生しない、もしくは解消しやすい事だと思います。
(OSSの場合は、技術スキルや向上心が高い・ゴールが共有出来ている等から)
在宅において、誰かが手を抜くということは誰かがフォローするということであり、
誰かに負荷がかかるということでもあります。

今後、在宅勤務を導入していくなかで、様々なルールが定義されていくと思われますが、
最低限上記のルールを個々が認識することで良いスタートがきれると言えます。

RICOH & Java Developer Challenge 2011 提出しました

大学院の有志メンバと参加しているRICOH & Java Developer Challenge 2011でアプリケーション、ドキュメントを無事提出出来ました。
企画段階から入れると約4ヶ月掛けて、進めてきました。大学院や仕事をしながらの作業であった為、
非常に疲れましたが、チームとしてはシンプルながらも当初の案はアプリケーションに落とし込めたと思います。
また、個人としては、Javaに慣れ親しむという目標が達成出来たと思います。

1次予選の結果は今月末です。本選に進めるか分かりませんが、参加して良かったなと感じています。

PyConJP 2011に行ってきました

PyConJP 2011に行ってきました。
会場が現在通っている産業技術大学院であった為、会場学生枠で参加させて頂きました。
200人以上の方が参加していたようです。

以下のセッションに参加しました。

  1. Pythonチュートリアル
  2. 今までPythonは「Perl, Python, PHPのベンチマークを計測しました」をする際に初歩的な部分しか扱った事がありませんでした。
    本セッションに参加するにあたり、Pythonチュートリアル 第2版は一通り目を通してから参加したのですが、テンポよく教えて頂き非常に良かったです。

    Python Tutorial

  3. PythonとMongoDBでWeb開発
  4. 個人的にDBが絡んだ話がやはり楽しいなと感じました。

  5. PyQtではじめるGUIプログラミング
  6. PyQtを使用してデスクトップアプリケーションを作ってみましょうというお話でした。
    自社のDeveloper Network BlogでPyQtを使用して、基幹システムの情報を一覧表示するアプリケーションが
    紹介されていたので、サンプルを作ってみようと思います。

  7. Pythonで1万台のiPhoneを管理する
  8. 最近、スマートフォンやタブレットが浸透し、業務で使用する端末を会社が用意するのではなく、
    個人端末を使用するケースが増えています。
    その際にポイントとなるのが、セキュリティであり、本セッションでは自社システムに接続可能な端末を
    サーバ側から効率的に管理するということでした。同様の製品が多く出ているところから、
    MDM(Mobile Device Management)分野は伸びているのだなと感じました。
    なお、Androidに対するPush通知は時々こけるそうで、その点iPhoneの方が機器管理をする上では
    機能的には進んでいるそうです。

  9. Pythonによる日本語自然言語処理
  10. 入門 自然言語処理
    の12章:Pythonによる日本語自然言語処理に沿った解説でした。

10月頭に少しまとまった時間が取れそうなので、何かアプリケーションを作ってみようと思います。


memcached 設定メモ

memcachedをPHPから使えるようにしたので、設定方法をメモします。

1. memcached install
最初にmemcachedをインストールします。repositoryはremiにしました。

[root@hoge ~]# yum install memcached --enablerepo=remi
Loaded plugins: downloadonly, fastestmirror, priorities
Loading mirror speeds from cached hostfile
 * addons: ftp.nara.wide.ad.jp
 * base: ftp.nara.wide.ad.jp
 * epel: ftp.iij.ad.jp
 * extras: ftp.nara.wide.ad.jp
 * remi: remi-mirror.dedipower.com
 * updates: ftp.nara.wide.ad.jp
Excluding Packages in global exclude list
Finished
303 packages excluded due to repository priority protections
Setting up Install Process
Resolving Dependencies
--> Running transaction check
---> Package memcached.x86_64 0:1.4.5-2.el5.remi set to be updated
--> Finished Dependency Resolution

Dependencies Resolved

==========================================================================================================
 Package                  Arch                  Version                         Repository           Size
==========================================================================================================
Installing:
 memcached                x86_64                1.4.5-2.el5.remi                remi                 73 k

Transaction Summary
==========================================================================================================
Install       1 Package(s)
Upgrade       0 Package(s)

Total download size: 73 k
Is this ok [y/N]: y
Downloading Packages:
memcached-1.4.5-2.el5.remi.x86_64.rpm                                              |  73 kB     00:02
Running rpm_check_debug
Running Transaction Test
Finished Transaction Test
Transaction Test Succeeded
Running Transaction
  Installing     : memcached

Installed:
  memcached.x86_64 0:1.4.5-2.el5.remi

Complete!

完了したら、memcachedを立ち上げたら、telnetでlocalhostのport:11211に接続します。
memcachedのデフォルトportは11211で、接続出来たら stats を実行すると、下記となります。
telnetからquit出来なかった場合hあ、ctrl + ] を実行後にquitします。

[shmachid@hoge ~]$ memcached -u memcached -d
[shmachid@hoge ~]$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
stats
STAT pid 32743
STAT uptime 79
STAT time 1312625362
STAT version 1.4.5
STAT pointer_size 64
STAT rusage_user 0.000000
STAT rusage_system 0.000999
STAT curr_connections 10
STAT total_connections 11
STAT connection_structures 11
STAT cmd_get 0
STAT cmd_set 0
STAT cmd_flush 0
STAT get_hits 0
STAT get_misses 0
STAT delete_misses 0
STAT delete_hits 0
STAT incr_misses 0
STAT incr_hits 0
STAT decr_misses 0
STAT decr_hits 0
STAT cas_misses 0
STAT cas_hits 0
STAT cas_badval 0
STAT auth_cmds 0
STAT auth_errors 0
STAT bytes_read 7
STAT bytes_written 0
STAT limit_maxbytes 67108864
STAT accepting_conns 1
STAT listen_disabled_num 0
STAT threads 4
STAT conn_yields 0
STAT bytes 0
STAT curr_items 0
STAT total_items 0
STAT evictions 0
STAT reclaimed 0
END

続いて、memcachedへデータを入れてみます。
下記では、key:testに対して、value:12345をセットしています。

[shmachid@hoge ~]$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
set test 0 0 5
12345
STORED
get test
VALUE test 0 5
12345
END

2. PHP拡張モジュール install
memcachedは使えるようになったので、次にPHPからmemcachedを使用する為に拡張モジュールをインストールします。
peclには”memcached”もあるようですが、こちらはlibmemcachedの事前インストールが必要となる為、
今回は”memcache”をインストールしました。

[root@hoge ~]# pecl install memcache

PHPからmemcachedに追加出来るか確認します。下記では、key:hogeに対して、value:fugaをセットしています。

<?php

 $memcache_obj = memcache_connect("localhost", 11211);

 $memcache_obj->add('hoge', 'fuga', false, 0);

?>

上記のPHPを実行後、再度telnetで接続してプログラムでセットした値が格納されたかを確認します。

[shmachid@hoge ~]$ telnet localhost 11211
Trying 127.0.0.1...
Connected to localhost.localdomain (127.0.0.1).
Escape character is '^]'.
get hoge
VALUE hoge 0 4
fuga
END

key:hoge に対して、value:fugaが取れましたので、確認OKです。

以上です。

デモの進め方

Being Geek ―ギークであり続けるためのキャリア戦略の中で、『デモ』についての章があったのでメモ書きします。
私はかなり緊張しやすく、伝えたい事が半分程度にしか伝わらない事が多い為、備忘の為に残します。

  • デモとプレゼンテーションは異なる
  • デモは参加者により参加してもらうもの。

  • デモ対象について最も知っているのは自分
  • だから自信を持てば良い。

  • 3つのフェーズ
  • デモをする場合、相手が誰であろうと目的はみんな一緒。
    みんな目的は情報を得る事である。デモをする際は下記の基本ルールを守る。

    1. 背景説明
    2. デモを理解する上で知っておくべき事を伝える

    3. 内容説明
    4. 発見、アイデアの具体的内容を詳しく説明する。

    5. ポイント説明
    6. 発見、アイデアのどこに最も価値があるかをようやくする。
      そして、聞き手に意見を求める。

  • 聞き手のタイプ
    1. 何も言わない人
    2. この手のタイプが最も厄介である。
      打破するには、背景情報や発見に至るまでの物語を長く話すと良い。
      毎回このタイプを想定しておけば、怖いものはない。

    3. 積極的な人
    4. 一見、厄介に感じるが、最もありがたい存在。この手のタイプから建設的な意見が出だすと
      デモは成功していると言える。だが、積極的な人がよく理解出来ていない状況の場合は
      かなりまずい状況と言える。まずは深呼吸をして立て直そう。
      デモ対象について最も知っているのは自分。

    5. 仕切り屋
    6. 仕切り屋は途中(もしくは最初から)で自分のペースに持って行こうとする。
      デモを行う人ではないのに。そんな時は”完全な沈黙”、”デモのテンポを変更する”等を行い、
      自分のペースに引き戻す。また、仕切り屋によって、あらぬ方向へデモが進んでしまう事により
      新たな発見があるかもしれない。(自分が見えていなかった事など)

  • 理想のデモとは、発表者のいらないデモ
  • そんな事は絶対に不可能。理想のデモをどのようにやれば良いとは言えないが、
    結局試行錯誤を重ねていくしかない。

    結局、プレゼンテーションの本(ZENなど)にも同じ事が書いてありますが、
    本番前の練習がモノを言うということでしょうか。


    Comet メモ

    WebSocketを使用したmashupを作るにあたり、以前から知られているCometについては、
    サーバからpushする技術ぐらいにしか理解していなかった為、少し調べてみました。

  • ■ 目的
  • 従来のWebページはクライアントからリクエストがあった時のみ、サーバからレスポンスが返ってくる。
    その際、クライアントからはHTTPコネクションを生成し、サーバからレスポンスが返るとコネクションはクローズする。
    上記の手法でも通常は問題は無いが、リアルタイム性を求められるアプリケーション等の場合は不都合である。
    (例えば、チャットや株価情報など)
    その場合、AJAX等で非同期にサーバへHTTP通信をする手法が考えられるが、
    サーバ/クライアントに負荷が掛かったり、他ユーザからの更新情報をリアルタイムに受け取る事は難しい。
    こうした経緯からCometと呼ばれる概念(Cometは複数の技術の総称)が生まれた。
    なお、Comet, AJAXの名称は共に洗剤から由来している。

  • ■ トランスポート処理手法
    1. ポーリング
    2. サイトあるいはアプリケーションから、更新有無を問い合わせるリクエストを定期的に送信するという非常に単純な仕組み。
      デメリットとして等間隔(例えば、5秒など)でリクエストを送信するが、サーバ側で高負荷になっていた場合も常にリクエストを出し続けてしまう事が起こり得る。この場合、サーバ側に未処理リクエストが溜まり続けてしまう。

    3. ロングポーリング
    4. クライアントからリクエストをサーバに送信し、すぐに返却可能なデータがある場合はすぐにレスポンスを返すが、まだ返却可能なレスポンスデータが存在しない場合は、レスポンスを返さずに未応答リクエストとしてサーバ側で保持する。
      データの用意が出来た段階で、保持していた接続を見つけてレスポンスを返す。
      Meeboで使用されて、有名となった。
      ロングポーリングの発展系として、スマートポーリングと呼ばれる手法がある。
      スマートポーリングはレスポンスデータが返って来なかった場合にリクエスト頻度を下げるポーリング手法である。
      例えば、空レスポンスであったら、次回のリクエスト間隔は1.5倍にするなど。

    5. 永久フレーム
    6. ロングポーリングは永久フレームから生まれた手法である。
      永久フレームとは、非表示のインラインフレーム(iframe)を開き、
      チャンク形式エンコーディングを利用して送信する。
      この方式は非常に大きなドキュメントを段階的にロードする為に考案された。
      但し、IEでは永久フレームを使用した場合、チャンクを受け取る度に「カチッ」という効果音がなってしまう為、
      使用に耐えないものであった。
      そこで登場したのが、GoogleがGoogle Talk考案したhtmlfileというActiveXオブジェクトを用いる手法である。
      この手法により、IE問題はクリアされ永久フレームは有効な手法として広まった。

    7. XHRストリーミング
    8. サーバと通信をする為の最も良い方法はXMLHttpRequestを使用する事である。
      通常、ポーリングやロングポーリングのデータ転送で使用されている。
      XHRストリーミングでは、XHR通信を行った後にreadystateをチェックし続け、
      接続が切れる前に同一コネクションを使用して会話をする。
      現状、最善の手法であるが、いくつかデメリットが存在する。
      通常Webサーバはリクエストを受けるとすぐにレスポンスを返すように最適化されているが、
      ストリーミングでは接続を保持し続ける必要がある為、注意が必要である。
      また、クライアント側においてははXHRストリーミングがパフォーマンス上の問題を引き起こすケースがある。
      ストリーミングのレスポンスがあまりに長く続くと、ブラウザのメモリ消費が過大となり、クラッシュしてしまう。
      解決方法としては、一定数のレスポンス後に一旦レスポンスを終了し、新たにリクエストを生成すれば良い。
      なお、IEではXHRストリーミングを正式サポートしていないので注意が必要である。

  • ■ 今後の動向
  • 前述までのCometを使用したとしても、大量コネクション保持やサポート問題等の為、完全なソリューションではない。
    そこで、HTML5からforkしたWebSocketに期待が集まっている。
    現在策定中のWebSocketはCometのデメリットを補いつつ、リアルタイムアプリケーションを容易に構築出来る可能性を秘めている。

    調査にあたり、続・ハイパフォーマンスWebサイト ―ウェブ高速化のベストプラクティスを参照させてもらいました。


    WMIサービスからクエリ実行

    WindowsのWMIサービスからクエリ実行が出来ます。

    例えば、稼働中のデバイスドライバ一覧を出力する場合、コマンドプロンプトより下記を実行します。
    $ wmic sysdriver where “(state = “Running”)” get name

    上記の結果は、” C:WindowsSystem32Msinfo32.exe”を実行した際と同じ結果となります。
    State=Runningのドライバを確認するとwmicのクエリ実行結果と同一となることが確認出来ます。

    imageをアップロードすると、フルサイズしか選べないのは何故でしょう、、、

    技術サイクルと情報アーキテクトの位置づけ

    大学院で技術サイクルと情報アーキテクトの位置づけを事例と共に考察しました。
    合っているかは分かりません。適当に流してください。。

    1. 技術サイクルとは
    技術または企業が進化・発展する為には技術サイクルが必要不可欠である。
    具体的には以下の流れを繰り返すことで、成長していく。

    1. 技術の不連続性
    2. 1→2の変化には、エバンジェリストが必要

    3. 不安定期
    4. 2→3の変化には、市場創造者が必要

    5. ドミナントデザイン
    6. 3→4の変化には、マネジメントが必要

    7. 安定期
    8. 4→1の変化には、発明・発見者必要

    本考察では、1: ”技術の不連続性”→2: ”不安定期”→3: ”ドミナントデザイン”までの2期で活躍をする、
    エバンジェリストと市場創造者の動きに着目し、今後の技術者の在り方について考察する。

    2. MySQL
    考察時のモデル事例として、MySQLを取り上げる。
    私が初めてMySQLを知ったのは2005年春でバージョンは4.0の頃であった。
    それまでMS SQLServer, DB2といった商用データベース(以下、DB)を使用して、
    アプリケーションを組んでいたが、この頃初めてオープンソースDBに触れた。
    Webサービス構築を通して、すぐにMySQLの虜になってしまった。
    その当時を振り返りながら、MySQLの進化・発展、取り巻く環境の変化を確認していく。

    2.1. MySQLの収益源
    MySQLはオープンソースDBである為、無償で使用可能である。(※厳密にはGPL Version2)
    使用者側でMySQLを使いこなす事が出来れば、追加のコンサルティング費用等は不要である。
    MySQL社では、各種サポート(問題発生時のサポートなど)やサービス(チューニングなど)を提供しており、
    年間売上は$60million – 70million程である。(認知度に対して決して大きくない)

    2.2. ある日本人MySQLコンサルタント
    現在、日本語によるMySQLの本が多数出版されており、中には内部構造を詳細に解説した本や、
    パフォーマンスチューニングのTIPSをふんだんに散りばめられた本もある。
    2005年当時、英語の本は多数出ていたが、日本語によるMySQL本は3冊のみであった。
    但し、内容的に古かったり薄かったりとコンテンツとしては充分とは言えない状況であった。
    自分が担当していたWebサービスのパフォーマンス改善をしていたが、MySQL4.0→4.1→5.0→・・・と、
    バージョンアップする毎にパフォーマンス改善や新機能が盛り込まれていった為、これらの情報収集には苦労していた。
    そんな時「現場で使える MySQL」(著:松信 嘉範さん)という本が出版された。
    今でこそ、この本よりも多くのTIPSが書かれた本は多くあるが、当時としてはこれ以上の本はなく、
    何度も繰り返し読み、また実機で実践をした。
    この頃は既にMySQLはWeb系サービスでかなり使用されており、
    メジャーな存在であったが、まだまだ未完成なデータベースで
    文字コードの問題やストレージエンジンのパフォーマンス問題などの問題があった。
    この本はこういった問題を丁寧に解説+対応方針を示し、他エンジニアも含めて参考にしていた。

    2.3. WebサービスとMySQL
    今日の有名なWeb系サービスでMySQLを使用していないサービスはほぼ無いと思われる。
    前述の2005,6年頃では、YahooやGoogleは大規模に使用をしていたし、
    新鋭サービスとしてはYoutubeや日本ではmixiが大量のアクセス・データを
    どのようなアーキテクチャで捌くかに注目が集まっていた。
    これらのサービスの成功により、MySQLの認知度は一気に上がり、様々なサービスの中核となった。
    LAMPがWebサービスのデファクトスタンダードとして広まったのもこの頃であった。
    一方、エンタープライズ業界ではまだ浸透しきれておらず、現場で使用されるまでに至っていなかった。
    現在はWeb・エンタープライズ共に、多くのMySQLが稼働しており、商用データベースを脅かす存在となっている。

    2.4. SUNによる買収
    2008年2月、SUNによりMySQLは買収された。
    収益はサービス・サポートからで$60million – 70million程であったMySQLを何故買収したのか。
    理由はMySQLを使用する多数のユーザの存在である。
    これらユーザの大多数はSUN以外のサーバを使用しており、
    買収をする事で自社のサーバへ誘導する事が狙いであったと考えられる。

    2.5. SAPの画策
    SAPとMySQLは2003年頃から提携して、次世代DBを開発してきた。
    MySQLをベースとして、SAP用に機能を削ぎ落したDBである。
    このDBではSAP DBと言われ、後にMAX DB, live cacheと言われるデータベースとなった。
    SAPがMySQLと組んだ理由としては、Oracleを打ち負かす為だと考えられる。
    OracleはSAPと競合するERPを保持している為、SAPとしてはOracle DBを使用する事は推奨しない。
    また、TomorrowNowに関連した賠償問題もある。
    現在、SAP ERPのバックエンドで稼働可能なDBとしてSQL Server, DB2, Oracle, MAXDBが選択肢としてあるのだが、
    OracleはERPで競合となるソフトウェアを保持しており競合にあたる為、メリットが無い。
    そこで、メリット/デメリットあるもののライセンス費用がかかる3社ではなく、
    ライセンス費用をかけずにSAPに特化したDBを共同開発可能なMySQLを選択したと考えられる。
    しかし、SAPは2007年9月頃にMySQL社との提携を解除し、次なる道を模索し始めた。
    結果、2010年5月にSybase買収へと進んだと思われる。この買収の狙いはOracleへの対抗である事は明白である。
    また、Sybaseはインメモリ技術を保持していた為、現状のアーキテクチャの流れに足していたとも言える。
    その後、このインメモリを搭載したリアルタイム分析ツール HANAをリリースした。

    2.6. Oracleによる買収
    2009年4月、OracleはSUNを買収した。この買収は最近の流行りである垂直統合システム化への道である。
    自社でハードウェア・ソフトウェア・データベース等を一貫して提供し、
    自社製品によるエコシステムを作り上げて親和性を武器に顧客を囲い込む作戦である。
    前段のSAPによるSybase買収もこの垂直統合システム化を狙ったエコシステム構築の1つの動きである。
    またOracleにはSUN買収にもう1つ狙いがあった。それはMySQLの存在である。
    Webアプリケーションを席巻するMySQLを手にすることで、エンタープライズ側のOracle DB、
    Web側のMySQLを使い分けることが出来る。
    Oracleには更にメリットがあった。ストレージエンジンのInnoDBである。
    MySQLはDBの核となるストレージエンジンを入れ替える事が出来る。
    デフォルトのストレージエンジンはMyISAMであったが、このエンジンはトランザクションをサポートしていない為、
    トランザクションを伴う場合はInnoDBを使用する。
    以前からMySQLの存在が邪魔であったOracleは、2005年10月にInnoDBを保有するInnobase社を買収した。
    これにより、MySQLは自身のソフトウェアの中核ストレージエンジンを奪われる事となる。
    但し、Oracle側で制限をしなかった為、今までと変わらずにInnoDBは使用可能であった。
    但し、SUN買収後のバージョン5.5からはデフォルトストレージエンジンがMyISAM→InnoDBへと変更された。
    Oracle社内では元々あったInnoDBチームと買収したMySQLチームを統合し、開発にスピード間が出てきたとの事である。

    2.7. RDBMSへの刺客
    2009年、RDBMSへの刺客としてkey-value型のデータベースが注目され始めた。
    これはNoSQL(Not Only SQL)と言われる。
    Key-value型の考え方は以前からあり、memcached等によりWebのアプリケーションサーバではよく使用されてきた。
    情報が爆発的に増えていくなかで、Big Dataを効率的に処理する為にkey-value型データベース等のNoSQLに注目が集まっている。当初は、RDBMSが無くなる・・と言った意見もあったが、現状は適材適所でRDBMSとNoSQLを使い分けていくというのが流れである。
    NoSQLの流れに対抗する為に、MySQLではバージョン5.6からmemcachedプロトコルを利用したNoSQLアクセスを提供する予定である。
    NoSQLなDBが今後どのように発展していくかは分からないが、RDBMSと適材適所で使い分ける必要がある。

    2.8. MySQLコアメンバの動き
    冒頭で、日本人のMySQLコンサルタントの話をしたが、今度はMySQLのコアメンバの動きを確認する。
    まず、MySQLの創設者であるMichael “Monty” Wideniusは、MySQLからforkしたMariaDBを開発し始めた。(Mariaは娘の名前)
    このDBは、ストレージエンジン”Maria”をデフォルトエンジンとするDBで、MySQL6.0(リリースされず)で出荷される予定だった機能が盛り込まれている。データベース本体として、MySQLを打ち負かす可能性は低いが、ストレージエンジンの1つの選択肢として使用されていく可能性はある。
     次にMySQLの開発責任者であったBrian Akerは、MySQLからforkしたDrizzleを開発し始めた。
    このDBはクラウド上での使用を想定しており、Webサービスのバックエンドで使用する時に不要と思われる機能を極限まで削ったDBである。
    今後、Cassandra等のNoSQLのライバルとなってくる可能性がある。

    3. 考察
    以上が、ここ数年でMySQLに起こった事象である。
    この個人や企業の様々なアクションを技術サイクルに当て込み考察する。

    3.1. 技術の不連続性 (エバンジェリスト)
    まず、日本人MySQLコンサルタントの松信嘉範さんである。
    彼はMySQLがまだ日本に浸透したとは言えなかった時代にDBマガジン(少し前に廃刊)や
    書籍でMySQLの良さを布教していった。
    彼がいなければ、日本におけるMySQLの成功はなかったかもしれない。

    3.2. 不安定期 (市場創造者)
    市場創造者はいくつかありそうである。以下にまとめた。

    1. SUN
    2.  MySQLを使用しているたくさんのユーザを狙った買収を行い、
       MySQLユーザを自社のサーバへ誘導しようとした。

    3. SAP
    4.  Oracleに勝つ為に、自前のDBを開発しようとしていた。
       また、開発を取りやめ、Sybaseを買収し、最近の流行りの垂直統合化で自社のエコシステムを構築しようとしている。クラウドに関しては、流れに乗り遅れているように感じる。

    5. Oracle
    6.  SUNの買収、MySQLへ対抗する為にInnoBaseの買収と、無駄がないように感じる。
       周囲の競合ベンダを威嚇しながら、買収を繰り返し、垂直統合システムを完成させていっている。だが、これはベンダーロックインとなる為、懸念される可能性もある。(中立的な立場であるPublicSectorがMicrosoftを嫌がり、OpenOfficeへ入れ替えていっているように)

    7. MySQL
    8.  MySQLはWebで圧倒的な強さを見せた。
       これは、Web業界を対象として製品をプッシュしていったからではないだろうか。
       また、Webがオープンソースを利用していくという流れにも乗っていた。
       だが、その他のオープンソースDB御三家(MySQL, PostgreSQL, Firebird)と何が違ったのだろうか。
       特に機能としては、優っているとの見解もあるPostgreSQLは何が足りなかったのか興味がある。

    3.3. ドミナントデザイン (マネジメント)
    ここでの登場人物はいなかったので、割愛する。

    3.4. 安定期 (発明・発見者)
    2人のMySQLの開発者は、新たな道を歩み初めている。
    MontyはMariaDBを始め、BrianAkerはDrizzleを進めている。
    先日、どちらのDBも新バージョンをリリースした為、次のTermである技術の不連続性へ進んでいく。
    彼らはMySQL時代にエバンジェリストを経験し、既に流れを作った経験を持っている。
    これはまさに技術のサイクルでもある。

    3.5. 1技術者として自分が出来る事、取るべき行動
    ここ数年は今後を左右する技術の変遷期にあたると考えている。
    まず、技術者が避けなければならない事として、自分のスキルが陳腐化することである。
    バズワードのように、たくさんの技術が出てきて、1部はメジャーとなり、一部はすぐ消える。
    また、既存の技術であっても消えていく事も充分ありえる。
    よって、業界動向、技術サイクルを見極め、今どこのTermにいるのか、
    エバンジェリストや市場創造者はどこに進もう・進ませようとしているかを冷静に判断しなければならない。
    その上で自分がアーリーアダプターとなり、他者をリードしていけるように心がける。(そうなりたい)
    以前はエンタープライズ業界がIT業界を牽引していた。
    例えば、IBM、Microsoftといったベンダーが新しい技術を産み、市場を創造していった。
    しかし、今はWeb業界がIT業界を牽引している。
    例えば、GoogleがAndroidを開発し、携帯メーカーはそのOSを利用して製品を作る
    (もはや、auのCMはAndroidの機能紹介となっており、au独自の機能はないように感じる)。
    Twitterがブームとなったことにより、Salesforce.のchatterやSAPのマイクロブログツールへと連鎖した。
    このことから、まずはWebに認められるか否かが、ポイントとなると考えられる。
    そのWebを支えているのは技術者である。よって、Webに認められたければ、技術者へ訴え続ける必要がある。
    エグゼクティブを対象としたカンファレンスはかりを開くのではなく、
    技術者を対象とした技術カンファレンスを定期的に開き、技術者を味方につけることである。
    技術者は次の技術サイクルを創出していく可能性を常に秘めている。

    以上。

    プレゼンテーションは難しい

    会社で「Webアーキテクチャ」に関してプレゼンテーションをしてきたのですが、やはりプレゼンは難しいです。
    私はあまり人前で話すのが得意ではない(上手くないの意味)ので、プレゼン前には練習が欠かせないのですが、
    いざ始まると練習の意味がなく、完全にトビます。
    また、今回は興味がない題材だったのか、反応もいまひとつだったなど、反省点がありました。
    今月はあと1回、長い時間のプレゼン機会がありますので、少しでも修正していきたいと思います。
    パブリックスピーカーの告白 ―効果的な講演、プレゼンテーション、講義への心構えと話し方を読んだのですが、
    結論としてはプレゼン前に練習あるのみとのことでした。

    やはり、事前の練習あるのみですかねー。次回までにもう一度読み直します。