更新頻度が1年に1回だからその都度忘れてしまうのでメモ。

1) 秘密鍵を生成

openssl コマンドで生成
擬似乱数情報の生成 (md5ダイジェスト値を擬似乱数をして使用)

# ./openssl md5 * > rand.dat

擬似乱数ファイル(ここでは rand.dat)から秘密鍵を生成
トリプルDESを使用、2048bitの秘密鍵(ここでは 2009key.pem を作成

# openssl genrsa -rand rand.dat -des3 2048 > 2009key.pem

パスフレーズを入力するので、忘れないように。

2) 秘密鍵からCSRを生成

作成した秘密鍵(2009key.pem)からCSR(2009csr.pem)を生成する

# openssl req -new -key 2009key.pem -out 2009csr.pem

この時に秘密鍵のパスフレーズを求められる
以下、証明書に登録される情報(ディスティングイッシュネーム情報)を入れる
更新前の証明書と同じ内容にする必要があるので、更新前の証明書を控えておく

• Country(国名): JP
• State(都道府県名): Tokyo
• Locality(市区町村名): Shibuya-ku
• Organizational Name(組織名): ShakeSoul,Inc.
• Organizational Unit(部門名): System1
• Common Name(コモンネーム): www.shakesoul.net
• 以下は入力せずに Enter キーを押して進める
  • Email Address []:
  • A challenge password []:
  • An optional company name []:

CSRが生成される
CSRの内容を発行局へ提出

3) 各ファイルのパーミッション変更と秘密鍵のパスワード削除

• 発行局から送られてきた証明書をコピペするなどしてファイル化する</p>
  • この場合 2009cert.pem とする
• 中間CA証明書が必要な場合はコピペするなどしてファイル化する
  • この場合 CA-cert.pem とする
• 各ファイルのパーミッションを以下のようにする

• rw———- 1 root root 1854 12月 3 11:32 2009cert.pem

• rw———- 1 root root 1696 12月 13 2007 CA-cert.pem

• rw———- 1 root root 887 12月 3 11:24 2009key.pem

• 秘密鍵のパスフレーズを削除する 起動時にパスワード入力を求められないようにするため以下を実行

# openssl rsa -in 2009key.pem -out 2009key.pem

4) 証明書のインストール

• 事前に作成した秘密鍵と証明書を Apache の config ファイルで指定する</p>
  • 例えば、以下にファイルがあるとすると</p>
    • 証明書ファイル: /usr/local/ssl/certs/2009cert.pem
    • 秘密鍵ファイル: /usr/local/ssl/private/2009key.pem
    • 中間CA証明書ファイル: /usr/local/ssl/certs/CA-cert.pem
  • …/conf.d/ssl.conf の中を以下のように書き換える

SSLCertificateFile /usr/local/ssl/certs/2009cert.pem

SSLCertificateKeyFile /usr/local/ssl/private/2009key.pem

SSLCertificateChainFile /usr/local/ssl/certs/CA-cert.pem

5) Apache 再起動

# /etc/rc.d/init.d/httpd restart

tail /var/log/httpd/ssl_error_log がでてなければOK

Mさんは今の会社で一緒になった方。ゲーム会社でプログラマーをしていた経験もあり、自分があまり知らないゲームの世界の観点を持っていた。ちゃんと話すのは初めてだったかも。

• ゲームのようなストーリーと目的を与えた方がユーザはすることがはっきりしてやりやすい</p>
  • 逆にオープンであっても、オープンであることをポリシーとして持っておくのが大事と話した
  • ポリシーがないのは問題
• オンラインゲームは一人で行うよりかはグループを組んで行う方が良い構造になっている
  • その中で上手い/下手がある
  • ここら辺がネットの感覚とは若干違うのかも、ネットは不特定多数がつながりあっている感じ
• コンシューマゲームは発売すると変更できないのでデバックとチェックに時間をかけるもの
• webサービスはライトでちょっと面白いものを作るスタンスが今ちょうどいいのでは
  • それなりのスキルを持った2,3名で作れる
• 今までフリーでやっていたこともあるので、ゲームのコンサルなどお仕事があるので食べていく分には困らないようだ
  • 人脈ある証拠だなぁ
  • ネットワークの質問にも答えたりするんだ、、幅あるなぁ
• 自分が仕掛けた会議が良かったといってくれた
  • 結構大きなエネルギーが必要だったけど、やってよかったと思えた
• 今後、お仕事の話あったら紹介しあいましょう
• 会社のロゴ作りお願いしてしまったw
• まわしているハコを教えてもらった
• satoru.net 教えてもらった

Mさんは自分より若干若い？はず。でも年齢は関係なく個人でやってきたバックグラウンドがある人は会社に属している感覚が薄いし、その人自身の持っているスキルと人脈がはっきり見えるよなぁと思った。

ゲームの世界のつながりは貴重なので、今後ともお付き合いできれば。よろしくお願いします。

今後の自分用のwebを作っていくためにさくらインターネットのレンタルサービスを申し込んだ。容量はそれほどいらないので、500円/月のプラン。しかし、500円って。。。すごい時代だ。これで、PHP,Perl,MySQLが使えるのだから簡単なwebサービスを作るには不自由なし。

さっそくオンラインで申し込んでsshログインしてちょっと覗いてみた。

偶然というか必然というか何か同じ匂いのする仲間2名と同調して、webサービスを作るための表現の場として fhy-works を立ち上げました。

http://www.fhy-works.com

ちなみにここで載せている私のプロフィールは こちら

とにかく面白いと思えるwebサービスを作っていくこと。儲けの観点ではなく、見ている人が をっ！ と思ってくれるようなものを作り出せたらと思ってます。

イメージとしてはシステム的にはあまり重たくなり過ぎず、ライトでシュールな感じを出せたらと思ってます。

仕事というよりかは自分達がライトにチャレンジしていける実験場としてどんどん表現できたらと思います。

アイデア出しもしつつ、メンバーの技術的なお話なんかもアップしていきますので、ご覧いただければ。あと、フィードバックもコメントなどでいただければありがたいです。

溜まったRSSを見つつ、気になった記事を読む。森公美子には興味がないが、iPhoneに対してどんな主張をするのか知りたくてブログのようなサイトを眺める。

なるほど、これは昔の家電を買いに行くような感覚のままなのだろうなと思った。ただ、このスタンスは人に依存しすぎて相対的に足を引っ張ることになるので、数年後には仕事の場面だと相手にされなくなって淘汰されてしまうだろうし、現にネット業界(SIではない)では始まっていることだよなと思い、未来型の仕事のスタイルを軽く模索してしまったりした。

そんなことよりもある日の最後の方で書いてあった「ネットは怖い」という部分には非常に引っかかった。

まだブログがなくまず見るサイトは Yahoo!JAPAN でした。という時代にはネット上での犯罪の可能性が認知され始めだったりして、その危険性から「ネットは怖い」といわれていたかと思う。

しかし、今はブログで個人が発信してそれに対してフィードバックされる環境がある。ネットといっても人対人のコミュニケーションがそこではされている。このケースもそうで、そこで「ネットが怖い」といってしまったら人とコミュニケーションすることをそもそもネガティブに捕らえているので、何もできなくなってしまうのではと思う。それならばネットで何かをすることもしなくていいのではと思った。

確かに自分の意見をオープンにすることはどんな反応があるか分からないリスクはある。最初のうちはそのリスクが重く感じて怖がってしまうときもる。ただ、そのリスクがあったとしても読んだ人がブックマークやスターを付けてくれたらそれは何らか響くものがあったんだと分かる。他人のフィードバックがあって初めて自分の意見が正しいのかが分かる。教えてくれるといったほうが感覚的に近いか。

これが面白さであって、またいろんな人たちがいろんな場面で行っていてお互いにフィードバックしあっている。だから、ネットでの自分の意見も謙虚にさせてくれる。この面白さを感じているからこれからもネットの中で主張することは止めないだろう。

2007年から一人しかいなかったときにいかに時間を巻いて仕事をするか考えつつ、実践してきているノウハウをまとめてみる。

色々意見はあるかも知れないが、本当に時間が限られている中で最高のパフォーマンスを持続させるためにはここまでの割り切りは必要だと思っている。

基本的なやり取りはメールで行う

自分の時間を確保する

対面的なコミュニケーションは最終的な意思確認もしくはメールで意思疎通が困難になってきた時に使う

メールで進められるだけ進める

電話は緊急時以外は使わない

かかってきてもとらない。メールで大抵すむ

定例の会議を設けて空気感が離れないようにする

定期的に短時間で

一人に対しての報告もメーリングリストを使う

1個人へのダイレクトのメールは絶対行わない(意味がないので)

報告すべきは結論と結果のみ

決めきれていないことを出しても意味がない

ドキュメント作成は共通理解をするために効果的なモノのみ極力少なくする

多ければ良いというのは古い、遅い

1日の労働時間は8時間と見積もっておく

だらだらやらない

会議はやることを明確に1時間以上やらないルールを設ける

ムダ話はムダ

勤怠状況はGoogleカレンダーで分かるようにしていちいち行き先の報告はしない

必要があれば見るでしょう

課題、問題への解決策は瞬間的にその場で決める

1週間延ばしてもその間に自体が自然とよくなったためしがない

今まで使っていた自宅PC用のイスは座り心地は良かったのだけど、PCに向かっての作業には向いてないようで長時間座るにも肩がこってしまっていた。会社で使っているイスと比べて座面の奥行きは10cmほど長いので、深く腰掛けることができずに背もたれにもたれかかると、姿勢に無理があり変なところに力が入ってしまっていたようだ。

会社の座面は W45xD40 くらい。自宅での作業効率に関わるのでこれに近いイスを自宅用に買うことにした。条件は以下、

• 座面 W42-48 x D40-45
• 肘付で高さ調節可能
• 背もたれは高すぎず肩より下
• 座面の高さ調節可能
• 座面の厚さがある程度あること

いつもの楽天で見つけたのがこれ。

[rakuten:tailee:10000008:detail]

オフィス用となると急に値段が上がってしまうけど、やっぱり同じようなスペックで安いものは出回っているわけで、うまく見つけられて良かった。

気になる座り心地は低反発座面は最初硬いけど沈み込みすぎずになかなかよいし、肝心の座面は深く腰掛けてもしっかり姿勢を保てるのでかなり集中しやすくなった。

PCと携帯を活用することで手元の道具は減ってきているけど、やっぱり常に使うものは大事だよなぁ。

Google、仮想空間「Lively」の終了を発表　12/31で閉鎖へ という記事を見てその決断の早さにちょっと驚いたが、最終的には Google がこの決断をしてよかったと安心している自分がいた。

Google が Lively をリリースした時は同じような3D仮想空間サービスが次々と生まれて Google もその波に遅れずに乗ってきた。しかし、自分は Google がこのサービスを手がけることにかなりの違和感を持った。

そのときの違和感はなんだったのかも含め考えてみた。

Google の提供しているサービスに対して以下のような印象を持っている。

• Google はコンテンツ自身は提供しない
• サービスはあくまでプラットフォームであって、その上でユーザが利用/活用してデータが蓄積される
• 活動領域は無限で自由に使うことが保障されている
• ユーザは自由で広大なサービスプラットフォーム上でますます活動するようになる

この自由の部分はユーザにコンテンツ部分を任せる完全にオープンなスタンスがあり、ユーザもその自由なフィールドを感じてより活発にサービスを利用する。

そういう意味では Lively はオープンなスタンスを持ってないサービスだったと思う。まず、ユーザができることが限られていた。アバター、部屋、アイテムは用意されているものから選ぶ、若干カスタマイズはできるもののその自由というには非常に狭いカスタマイズにとどまっていた。また、この世界の中で行えることは非常に少なかった。アバターを歩かせて、他のアバターをテキストチャットを行うだけ。移動はワープはできるがその場所を把握するのに歩き回って誰かいないか様子を見て、、、と非常に時間がかかる。効率的に進める工夫もなく非常に機能は限定的。

ユーザが無限に活動できるサービスプラットフォームとはほど遠い。Google 自身がコンテンツを用意する立場になっていたサービスであった時点で、基本スタンスから外れていたのではないかと思う。そういう意味ではアバターのデザインからユーザのお絵かきしたキャラクターを選択できる はてなワールド のほうがよっぽど自由度が高いと思う。

一つ可能性があるとすれば、ユーザ間のコミュニケーションによって生まれる価値がサービスそのものの価値につながって活性化されるようになることだったが、オープンスタンスを貫いていないサービスではその可能性もなくなったということだと思う。

Lively に限らず既存の3D仮想空間サービスはどれもオープンなスタンスが足りない。ユーザへの自由度が非常に少ないと思う。まだまだwebのオープンなスタンスには程遠い。ゲームと異なるネットサービスとしての成長を狙うのであれば、アバターのデザイン、創造物、提供機能などをユーザにゆだね、サービスプラットフォームに徹すること。ゆだねるための仕組み作り、情報発信と情報のキャッチを日常化しなくてはこの新しいジャンルが活性化していくことはないのではないかと思っている。

今年6月にINTEROPと一緒にやっているIMC Tokyo の関係で IPTV Summit というものがあるらしく、IP系のメーカの話も聞けるようなので事前予約をして行ってみた。場所は幕張メッセ。やはり遠い。。。あまりしょっちゅう行く場所ではないな。

IPTV Summit 自体は Inter BEE という放送系の展示会場内の端っこの方にブースを設けてその脇でクラスルームという話を聞ける場を設けていた。思ったよりもかなり小規模。聞いている人たちも20名行かないくらいか。

シスコ、ジュニパー、モトローラの話を聞いたが、放送がIPに載れば彼らの培ってきた得意分野になるし、海外で実績を積んできているようだが日本はさぁこれから、というところか。各社の商品紹介ではなく、ジュニパーは海外のIPTV事情について、モトローラは日本の放送法、著作権法の法律関係の話がメイン。普段触れない側面なのでそれなりの成果はあった。

以下、セッションを聞いたときのメモ。シスコの話はスピーカー曰く「ヨタ話」と言ってしまうほどひどいものだったのでカット。(個人的には相当怒りを感じてますが、ここに載せることでもないのでここまでにします。)

海外の事例に学ぶ収益性の高いIPTVインフラ構築

JuniperNetworks 佐宗大介

• 世界的に展開しているNGN
• 広帯域化の 現象
• 売り上げ単価の 減少
  • ブロードバンドARPU,携帯電話の1分あたりの利用額
• 海外大手通信事業者のチャレンジ
  • ベライゾン マネージドネットワークサービス
  • AT&T IPTV
• マーケットサイズ予測 169%増 2009年予測
  • IPTV加入者予測も同様
• IPTV市場参入の背景
  • 付加価値をつける
  • IP化していろいろなものと融和性が高いだろう
• VoDの役割
  • VoDをやると売り上げが伸びる
  • Concast 2005年に10億のVoDが視聴された 視聴率があがる
  • 解約率が 20-30%減少

事例紹介

• ケーブルTV事業者と通信事業者の戦い激しい
• ベライゾン FiOS 末端まで光
  • $129 ARPU 伸びがすごい
• AT&T
  • 途中まで光そこからvDSL
  • ネットワークを中心に
  • 予測では IPTV のトラフィックが2008年以降伸びるだろうと予測
• イタリア Fastweb
  • 750万世帯をカバー
  • サービス VoD(5000タイトル)、TV を用意
  • freeのチャネルもあり
  • ゲームも手がける
  • Juniper ERX-1440 入れている マルチキャストQoSかけている
• Hong Kong 人口700万人
  • チケット予約をテレビからできる
  • 宅配サービスも出来る
  • 4.5M 800k VoD がコンテンツサーバから ERX-1440 をへてマルチキャスト
• IPTV配信するためには30-50くらいの要素が必要
  • # ニコ動、Youtube ではその要素をできるだけ削減した形態なのでライトに出来ている
• ネットワーク構成的に
  • edge ルータで管理している
  • P2MPによるコンテンツ配信
  • IPのルーティング上に MPLS のパスを張って映像用のルーティングさせていてる
• P2MP パスの切替りが非常に速い
• edge にて階層化した QoS をかける
• 例)3つ目のTVを付かないようにする(輻輳するので)
  • アプリケーションと加入者情報をリンクさせてポリシーを適用する
• TOP100サービスプロバイダでのビジネス実績

IPTVビジネスを加速させるテレビジョン・オン・デマンドソリューション

モトローラ 石原　篤

• テレビジョン・オン・デマンド モトローラで提唱している
• 電気通信役務利用放送法 自前で通信インフラを持たなくても放送可能になった
• ビービーケーブル(ソフトバンク)が2002年7月24日第一号登録 Yahoo!BB IP方式
• RF方式：ファイバを通じて現状のケーブルTVと同じような形態
• IPTVのメリット
  • 既存IP網を使える
  • 放送業者は通信事業を委託することが出来る コンテンツ作りに特化できる
  • IPとしての双方向性のメリット 他アプリケーションとの統合
• IPTVの課題 著作権問題
  • IPマルチキャスト方式は著作権法上は自動公衆送信として通信扱い</p>
    • NHKオンデマンドは権利者に個々に許諾を受けるようなことが必要になった
• 竹中改革の功績
  • 2006/06/06-09/19 2010年までに通信と放送の法体系の見直しを行うことを決めた
  • 新競争促進プログラムという 2009年12月国会に法案提出
• NHKオンデマンド開始は大きな前進 法的な意味からも真の位置づけになるのはこれから2010年
• これまでのIPTV CATVに追いつくことが目標だった 受身的市長の習慣の延長
• これからのIPTV 好きな時間に好きな番組を広げる # オンデマンド性ということでしょ
  • # webで出来ていることと比べると真新しさがないなぁ
• 海外
  • TimeWarner サーバで録画 好きなときに再生
  • BBC オンデマンド再生
  • StarHub オンデマンドテレビ
• オンデマンド広告挿入
  • 早送りできないように強制的に見せる
• Motorola B-1 サーバ
  • オンデマンド、リモートストレージDVR(RSDVR)は法律的にOKと判断された</p>
    • レコーダーがネットワーク上にある # クラウドぽいな
• B-1サーバ
  • 128GBメモリ*10枚 メモリベースで早い
• 民法のオンデマンドは、、、広告があるから これから検討

VMwareがフォーラムをやるというので行ってきた。CTCなどのSIerが行うものも行ってみたけど、自分所のサービス紹介だけで技術的な話がほとんど聞かれなかったので、本家ならばもう少し技術的に参考になる話が聞けるかと思い行ってみた。

Technical Deep のお題がついているものをいくつか事前登録しておいたが、会場に人が多くて立ち見もままならなかったので見るのをやめてしまったものが2つ。残念。。。しかし、事前登録しているのだから部屋の入口で申込書をチェックするくらいして欲しい。誰でも聞けてしまう状況だったし、そもそも定員に対して会場のキャパが合っていたのかも疑問。1セッション45分、資料配布なし、質問タイムなし。

当日の資料は11/26に期間限定で公開された。

以下、聞いたセッションのメモ。

VMware VDI Technical Deep Dive

感想

Technical Deep といっておきながら技術的な話は全くなかったのが残念。全ての時間を仮想サーバの想定スペックから物理的サーバ台数の算出に当てる。個人的にはネットワーク算出方法が24時間平均値を採用している時点でダウトだと思ったので(ピークで見ないと実際さばけなくなるので)、結果の値は信頼性のないものと思っている。

アジェンダ

• 1 検討フェーズ
• 2 設計構築フェーズ
• 3 運用管理フェーズ

用語

• VDI Virtual Desktop Infrastructure
• VDM Virtual Desktop Manager
• VDMクライアント クライアント端末にインストールするVDM接続用プログラム
• テンプレート 仮想デスクトップのテンプレート
• VDI GPO管理用テンプレート グループポリシーを定義するためのテンプレート

サイジングの前に

• サイジングは成功の鍵
• サーバ統合とは異なるアプローチが必要

サイジングのポイント

• サーバでも同じ
• CPU/memory/strage/network
  • CPU 一般平均値 2.79% しかしピーク時を考慮すること
  • 8VM/Core が推奨、それ以上はパフォーマンスが急に悪くなる
  • 市場で売れているのは クアッドコア2ソケットの8CPUもの
• CPU
  • 8コアなので 8*8=64VM/マシン
  • 1物理PCあたり平均130MHz消費とすると 64VM+オーバーヘッドで 1.68GHzくらい
• メモリ
  • メモリシェアなし XP 512M*64VM 32GB
  • メモリシェア機能あり 21.3GB 以上必要
• ネットワーク
  • プレゼンテーション系ネットワーク VDMクライアントがある 画面情報飲み流れる
  • バックエンド系ネットワーク バックエンド系サーバがある
  • その中間に 仮想デスクトップ(ESX)がある
• ライト 50kbps*64、へヴィー 100kbps*64、平均 2kbps*64 = 128kbps
  • # 24時間平均で考えている ピークを見なくてはNGでは？
• ディスク
  • 1LUNあたり32VM とする
  • VMDK(OSとアプリケーション) 10GB*32=320GB
  • vSwap、Suspend/Resume領域、VMログ、領域、などを足す。空き領域15%
  • 合計 820GB
• サイジング例
  • 2Core 4GBメモリ で 500-750ユーザ数さばける
• コスト 100台
  • 初期 1500:1389＄
  • ランニング 196＄/年。588$/3年

仮想環境の管理を自動化するVMwareの最新テクノロジー

感想

運用管理するためのツールの紹介で、結構デモしてくれたりプレゼンテーターの知識も深く面白かった。結局VMwareを入れたとたんに管理も、、となるとこれもまたVMwareで。となってメーカの戦略によって染まってしまうのだぁと思うと、ちょっと警戒してしまった。

• 自動化の最適は拡張性、標準化が抑えられれば</p>
  • # どうも目的が異なるような。。動機付けが弱い
  • 仮想化は自動化に向いている # 仮想化を使う目的があってその上での自動かなので理由付けにならない

vCenter

• オーケストレーションを支えるツール
• VI Client
• Web Access
• VI API

VI API

• Webサービス SOAPとして実装 https/http 通信
• WSDKに記述
• 利用方法 Toolkit がある : Toolkit for windows, Perl Toolkit, SDK
  • サンプルコードなどがある 作りやすくするためのもの
• ESXホストの構成。仮想マシンのプロビジョニングと管理、VMFSの監視
• 出来ないこと ハードウエア監視(CIMでできる)
• VI Client 単体で出来ること = VI API でできること

VI Toolkit for windows

• スクリプトで記述する内容</p>
  • VI Toolkitが提供するスナップインを登録する
  • VCに接続する
  • 管理オブジェクト
• 出来ること 繰り返し作業
• 出来ないこと 一元管理、実行履歴/結果の管理

vCenter Orchestrator

• 汎用性の高いワークフロー定義/実行管理
• コンプライアンスと視認性の実現
• ワークフロー作成 ドラック&ドロップ 線でつなげる ユーザインタラクションも入れられる
• あらかじめ用意されたアクション 400以上用意、ないものは javascript を書けばOK
• web UI の生成 ユーザは生成された web UI 上で作業する
• プラグインとwebサービス外部連携
  • SDK, WMI、ネットワークプロトコル telnet など
• 出来ること 自動化による作業運用コストの軽減
• 開発することに近い

Lifecycle Manager

• vCenter Orchestrator の上で作られたもの
• 日本では未発売 USでは今年発売
• 仮想マシンのライフサイクルを一元管理する
• 承認作業もこの中で行う 承認されないものは作業できない仕組み
• ブラウザ上で行える