「フリー」を読めばWakameがフリーな理由もわかるはず

Wakameも「フリー」です

Wakameの説明をしているとたまに「Wakameを無料で配布してしまって、御社はどこで儲けるんですか？」という質問をいただくのですが、この書籍「フリー」をご覧いただくとわかるかもしれません。大体この本に書かれているモデルはうちの会社も似た感じなんです。

今年4月にリリースして以来、Wakameは各方面より色々な反響をいただきまして、おかげさまで年度内は殆どがWakame関連のお仕事で埋まりました。
リリース前には社内で何でもフリーにして良いのかと言う議論もあったのですが、僕個人的としてはプロダクトとしてフリーでやっていくことに疑問はありませんでした。 その辺り勘ではなく論理的にきちっと書かれた本が「フリー」なんだと思います。

Wakameは、全社員たった7名のうち、もっと言うとその内数名のプログラマによって生み出されているプロダクトです。そんな弱小集団が取れる戦略はフリーしかないってのも事実なんですよね。

クラウドを実現する技術とか言われたら期待しちゃいます

よーし、これでクラウドを実現しちゃうぞ〜！って本ではない

勝手に期待して読んだ方が悪いのかもしれないけれど、タイトルを見たら誤解しちゃう。クラウドというキーワードの周辺で目立った要素技術をピックアップしている紹介本。
酷評かもしれないけど、この本に書かれているのは要素技術としても本当に導入だけ。実現できるとかありえない。肝とも言えるネットワーク周辺の話が丸々抜けているのが痛い。

でも良いところもあります。プロセッサの仮想化については良くまとまっていますので、ここらを一度振り返ってまとめておきたい人にはお勧め。

あと、どうしても技術用語が5年くらい古いのが気になります。

これさえあればAmazon EC2/S3の活用で困らない！どんな人にもぴったりな本

たまに「Amazon EC2/S3って実際運用してみてどうなの？」と問われることがあります。

これからはそんな質問も減る！そう感じさせる本に出会いました。

最近出たAmazon EC2/S3関連の本の中では最も「運用」についてしっかり書かれている本です。
 

入門から実運用まで、これほど幅広く書かれているにもかかわらず、構成も文章もすっきりまとまっていて無駄がないのも素晴らしいところ。

実際にEC2/S3で動くシステムを作ってトラブルを恐れずに切り込んでいった人の生々しさがエッセンスとして随所に散りばめられており、知っている人が読んでも楽しい。

もし近場のお客様などでEC2/S3に興味を持っていそうな方がいたら、まず迷わずこの本を教えてあげて下さい。

聞きたいこと知りたいことが漏れなく詰まった一冊です。

時にはもっと気合いを入れてTwitterで発言することも大切だから、ブログを併用して解決することにした。

Twitterの危険性

お会いしたことはないのだけれど、小野さんと言う方が「Twitterは気軽にOutput可能にしてしまうため、そこから先を深堀する前に終わることが多いのでは」と言うようなエントリを書かれていた。 ふむふむなるほど、と思ったので僕もエントリしてみる。

僕も最初はアカウントを取って放置しておいたTwitterだったけれど、最近少しずつ使い始めていて、手軽さが気に入っている。 それと同時に、ブログのエントリが減ったのも事実だ。 そろそろ気合いを入れるべき発言をきちんと見極めないとなー、と思う。

気合いを入れて140文字で発言するためにBlogを使う

最近はlivedoor Blogに記事を書いたらTwitterに発言する、という機能がついている。 これを活用するのがよさそうだ。 140文字で発言されるのはブログのタイトルだ。 あたかもTwitterで発言したようにして、そのつぶやきを補ったり深堀したりするためにこの機能が使えそう。

スパコンの研究費は削減せず、むしろ防衛費に振り替えるってのはダメ？

なんだか事業仕分け(笑)が話題になって、スパコン切られそうだとかネットでニュースになっていますね。 あまり軍備としてのコンピュータについて触れている人がいないのでエントリを残してみます。

スパコンは気象予報などのシミュレーション分野では役に立っているのは有名です。 それ以外にも暗号技術の世界では解読に使えるコンピューティング能力の向上が非常に脅威ですから情報戦時代には必要だと思います。 そう言う意味で僕はスパコン開発は手を止めるべきではないと思う。 防衛省に移してでもやるべきだと考えます。

海外から買ってこい！日の丸印に意味は無い！CPUから設計している時代じゃないんだよ！なんて言っている人もいるけれど、上記理由で輸出しないって言われたらおしまいじゃないのかな。
調達が不明瞭だとか言うならならそこを正せばいいし、目標を達成できるとは思わないという意見もあるが、それは削減理由ではなく、むしろ大いにやるべき理由ではないか。 自分で稼いでその金でやれ、と言う意見もあって民間ではごもっともなんだけれど、僕は防衛費的な意味合いを考えると稼ぐためにやる研究ではないと思う。

Wakame 1.0開発者の募集を締め切りました。

Wakame 1.0開発者へのご応募ありがとうございました

おかげさまで2名のご協力者を得て、現在開発スピードが加速しております。
WakameはこれまでEC2上でスケールアウトするオートメーションを実現してきましたが、Wakame 1.0ではこの役割を根本的に捉えなおし、EC2はもちろんのこと、EC2以外のホスティングサービスでもスケールアウトするように改良中です。

もちろんこれにはデータセンタ側でもやるべきことがあります。
Wakame 1.0ではデータセンタで供給すべきスケールアウトのためのインフラからユーザアプリケーションまで垂直に提供できるようになる予定です。
すべての開発者に、開発時から使えるプログラマブルなデータセンタと、運用を楽にするシステムオートメーションを。
お楽しみに。

[Wakame]Wakameの開発にご協力くださる方を探しています

■急募："Wakame 1.0"開発協力者！

株式会社あくしゅでは"Wakame 1.0"の開発者を募集しています！
Wakameは次世代データセンターには欠かせないクラウドコントローラとして、今後大幅に機能拡張していきます。
Rubyでミドルウェアを開発してみたいという意欲あふれる方は是非お問い合わせください。

■仕事内容

1. "Wakame 1.0"の使用目的を拡大するために、ミドルウェア部分の機能拡張を実施
2. "Wakame 1.0"を使いやすくするために、GUIの追加開発を実施
3. "Wakame 1.0"を分かりやすくするために、ドキュメントの整備を実施

上記の内、得意なもの１つ以上をお願いすることになります。

■募集要項

• 下記(A)(B)(C)の知識・技術セットをいずれかお持ちの方
  1. Ruby, 現在のWakame, メッセージング, 並列処理, Xenなどのハイパーバイザの知識
  2. JavaScript, XHTML, Ruby on Rails, http通信(REST), ユーザビリティ, 画面設計の知識
  3. HTML, ドキュメンテーション
• システムの設計が得意で、オブジェクト指向を理解している方
• 人とのコミュニケーションが好きな明るい方
• 期間：2009年11月初旬〜2010年3月下旬

■条件

応募期限は10/26(月)までです。
それ以降10/30(金)までに一度仕事内容や関わり方をミーティング形式でご相談させていただきましてその後、弊社基準で判断してからお見積もりをお願いします。

■一言

設立３年目の若い会社です。
来年からは「世界のクラウドソリューションを」をテーマに事業展開していく予定です。
そのために今後は弊社で開発している"Wakame"を機能拡張し、より高度なプロダクトへと躍進させていきます。
あなたもぜひ、この新しいチャンスに乗ってみませんか？

■連絡先

Twitter: @axsh_co_ltd
E-mail: r_at_axsh_dot_net (_at_と_dot_は適宜文字列を置換してください)

なんでクラウドのデータは消えてしまうん？←節子…それ、クラウドやない

クラウドにデータを預けて大丈夫なのか？という議論がたまにあるけれども、僕はそんな議論をするより、データを預けて大丈夫なものをクラウドと呼べば良いだけなのに、と最近思う。
近頃の「クラウド」という言葉は、技術のコモディティ化が進行していることを良く表した生きているバズワードであって、コンセンサスが有る部分と無い部分を混在させた状態にあるのは間違いない。
僕がこのエントリで言いたいのはそのコンセンサスの中に「データ消失対策が十分に練られたものをクラウドと呼び、そうじゃないものはクラウドと呼べない/呼ばない」という点を追加できないかなぁと言うこと。

今週ちょうど厄介なニュースが飛び込んできた。

ネット史上最大の惨事のひとつ発生―Microsoft Danger、T-MobileのスマートフォンSidekickのユーザーデータのすべてを失う

悲しい事に、このニュースは「クラウドの弱点」だとしてコンセンサスを形作ってしまうかも知れない。はてブではクラウドというタグが付いたり、クラウドにネガティブなコメントもある。
それはそれで良いんだけれども、細かいがどうも釈然としない点がある。
今回はそれを問題にしてみたい。

T-MobileとMicrosoft Dangerが何重にもバックアップを取っていなかったことについて弁解の余地はない。特にSidekickはローカルの端末にデータを記録せず、すべてをクラウドに保管していたのだからなおさらだ。

ネット史上最大の惨事のひとつ発生―Microsoft Danger、T-MobileのスマートフォンSidekickのユーザーデータのすべてを失う

この引用で問題にしたいのはこのDangerのバックアップの仕組みについてではない。もちろんニュースになるような事件はあってはならないし、擁護するつもりはない。ただ、実際にどのような仕組みがあって、どう言った事情が背景にあるのかも良く分からないので、外から推測で指摘できることはない。

僕がこの場で問題にしたいのはこの記事にサラッと書かれた「ローカルなどクラウド以外のコピーを持っていないことは落ち度である」と暗に指摘している点だ。
はて、本当に「ローカルの端末にデータを記録」することがバックアップの防衛ラインとして重要なのだろうか？この発想こそが旧世代的で、いつまで経ってもクラウドにデータを持って行けない元凶であると思う。
そもそも、データストレージ型のクラウドの中で幾重にも防衛ラインが敷かれていれば、ローカルのバックアップなど本来は必要なくできる。そうするのがストレージとしてのクラウドの役目ではないだろうか。
ローカルにある使い古された故障ロットかもしれないHDDにコピーしてバックアップをした！と得意げに叫ぶ方がバックアップをなめているとしか思えない。RAIDで持てばいい？世代バックアップすればいい？メディアへの書き出しもしている？風化・劣化しないように暗室に保存している？違う違う、それは「クラウドが無かった時代にやらなければならなかった事」なんじゃないの？そう言いたい。

ストレージの標準APIに望むこととして、またこんな変な指摘が出てくる。

利用者側でバックアップをローカルや別のクラウドに持っておくなどの柔軟な操作が（実際にユーザーが行わないとしても）可能になっていることが望まれます。

クラウドストレージの標準APIがストレージ団体「SNIA」から提案される

僕は必要ないと思います。

それより、どのようなバックアップ手法をとっているのかが分かるとか、何か数値的な指標が出せる運用を宣言できていればいいんじゃないでしょうか。SLAみたいに。

ネットに必要なのは匿名か実名か

ネット上でも実名で表現を

少なくとも人とのつながりを目的とした利用においては、できる限り実名を明らかにするのが好ましい

上記は勝間さんの提案ですが、個人的にはほぼ反対。どんな場面においても匿名にする自由はあって然るべきです。
既存メディアと同等の信頼を得るために発信される情報は実名にしろなんて話にはならないでしょう。既存メディアだってうまく匿名を使い分けている。新聞記事にだって社名以外のクレジットが無いものがほとんど。芸名で通す芸能人が宗教にも使われている。実名というのが信頼を得たり失ったりする役に立っていない証左ではないだろうか。何かの影響は有るかも知れないけれども。

僕が実名でやりはじめた理由

それが最初の商品だったから、かな。
独立して仕事を始めましたとか言っても、何か売れるものを持っていたわけでもないし、何もないから名前でも出しておくか、ってただそれだけ。
学生時代も山崎という名前だし、前職でももちろん山崎だし、それなりにその名前で名刺を配ってきたりもしていたわけです。
どこぞの一社員として見られるのが大方とは言え、中には社名ではなく僕の名前を見てくださる方もいらっしゃるのではないか…そんな淡い期待があったに過ぎません。ちっぽけな「山崎泰宏」というタグがどこかに付いていたら良いな、と。

そう言う意味では、名前のユニーク性も大切かも知れない。ググると僕以外の「山崎泰宏」が何名か存在する。匿名というか偽名が許されるのであれば、ネット上では少し文字った名前でやっとけば良かったかなーなんてふと思うことがある。

実名で何か良いことあった？

音信不通だった大学時代の友人がメールをくれた以外、実質的には良いことは無いかも。

クラウドって何ですか？と聞かれた時の答えを１つ

最近、色々な人から聞かれるので、専門家ではないけれども僕なりの答えを述べておきます。身も蓋もない表現ですが。

クラウドとはネットワークコンピューティングのコモディティ化が進んだことを表す言葉

いきなりごめんなさいだけど、これに尽きると思います。

クラウドって別に新しい技術ではなく、既存の技術を高度に組み合わせてできたネットワークコンピューティングの体について、そろそろ何か名前付けとかないといちいち面倒だぞ、ってタイミングで出てきた、ズバりピタッとくる「ちょーどいい言葉」なんだろうなと思うんです。

Wakameを世に出してから、色々な方々とお話し合いさせていただきました。
技術的にクラウドを理解しようとする人や、物事の解決へのアプローチ・考え方からクラウドと言う言葉を使う人、ユーザの立場や世の中へのインパクトからクラウドを理解している人、様々な人がクラウドという言葉を使っています。
本当に良くできたバズワードなのです。
今この世の中がどのような技術を使っていて、それらが何を提供しているか何のコンセンサスもないのにクラウドという言葉を便利に使っていて、それなりに意味を通じさせてしまっているわけですね。

元々、"コンピュータ"という言葉そのものも最初は計算する「人」を表していた言葉だそうです。かつての"コンピュータ"は今とは違って、チューリングマシンでありノイマン型であり(おじさんにとっては)IntelでありWindowsでありExcelやWordまで想像させるような言葉ではなかったはず。

これまでも、コンピュータが高度にネットワーク化されたこの現状を、WebサービスだのASPだの色々な言葉が説明しようと試みられたわけだけれど、どこかそれそのものを具体的に言い過ぎている部分と足りていない部分があって、何だかクラウドって言う「間違っていないし、難しくもない抽象的な表現」を引き合いにしたら、それが「現代のコモンセンスで理解できた」と。
そう言う意味で、これを言い出したエリック・シュミット氏は天才を超えた天才だと思う。

クラウドに踊らされるな！昔からあった！我々も主張していた！と言う人々

恥ずかしいから止めた方が良いと思うんだよね…。踊らされるな！って言うと警告めいてはいるけれどもその反面、世間があなたの知識に近づいて来たのを恐れているようにも見えるし、昔からあった！なんて言っても認知されなきゃ無かったのと一緒だろうし、我々も主張していた！って言うと更に悪くて「じゃあ最初からクラウドって言えばいいじゃないか」って話にもなるんじゃないだろうか。

そう言う意味で、やっぱり良くできたバズワードだし、意味が通じるという側面は、ネットワークコンピューティングの複雑な技術がそれなりにコモディティ化した結果なのだと思う。

社内で下期方針を出しました。

社内で下期方針をプレゼン

売上伸ばして行こうという話に始まって、そのために何をすべきか、どこ目指すべきか、各々何をすべきかについて述べた。来年のWakameが進むべき道を描いて下期の成長戦略を企画したレベル。いつものことだが、この戦略もある部分では当り、ある部分では外れるはず。そうやって当たり外れが見えるだけでもマシだろう。

収益をどう上げるかって言う話も当然難しいんだけれど、お金の使いどころって言うのはもっと難しい。ひとまず、会社がどう維持されるのかについての計画があって、使って良いであろう予算と必要そうな経費とを相談しながら決めている。

何となくではあるが、結構独断で決めちゃったりもしたので、今後はきちんとその計画に沿って進めていかなければならない。

あと最近、資本政策やらベンチャーキャピタルについての本を何度も読んでいるので、「何？IPOしようとか思ってるの？」なんてからかわれているのだけれども実は理由は逆で、どうしてみんなIPOを目指すのだろうかと。それについて理解しようと思ったのがきっかけ。

でも読めば読むほどやらない方が良い気がしてくる。まだきちんと理解できていないのが理由なのだろうが、株というのは未だにどうも気持ち悪い代物で…。

そのうち、やりたい人が出てきた時にその理由が理解できないと困るので、もうちょっと粘って読んでみることにします。

[Wakame]Wakame 0.5.0リリースしました！

Wakame 0.5.0のリリースです。1ヶ月半ぶりなのは、Wakameの実案件が複数同時に進んでいてリソースを集中させることが難しく、そんな僕の采配の悪さのせいで開発が当初ここまでと決めたところまでなかなか進んでいません。申し訳ないです。

新機能：Wakame Masterが吹っ飛んでも復帰させられるように！

Wakame Masterの状態をDBに持つようにしたことで、途中で吹っ飛んでもDBに書かれたその状態から再開できるようになっています。今まで完全にオンメモリで動いていたので、そこを全面的にDBへシリアライズするよう書き換えられています。（最初からそう作れよって突っ込みはごもっともです…。）

目標：下期はWakameの開発にもっと力を入れたい！

最近、Wakameのロードマップが公表されていない点や、ドキュメントが不足している点を指摘されます。お問い合わせいただきました皆様本当にありがとうございます。

Wakameのあるべき姿として目指している画はあるものの、実績となる実案件も面白いので、ついついその対応で計画を流動的にしてしまっているだけなのです。プロダクトにご注目くださっている方にはとても申し訳ないと思っております。

下期はWakameと言うプロダクト開発にもっと注力していきたいと考えております。一緒にやってみたい方がいらっしゃいましたら、ぜひご連絡ください。
Wakameは「世界のクラウドソリューションへ」という安直なスローガンを掲げ、アホ臭いと言われようともけっこう真顔でそっち方面を目指しています。良いのか悪いのかもわからない。でも楽しい。

ちなみに、人材紹介系のリクルーティングサービスは絶対に使わない方針なので、その辺よろしくお願いします。＞テレアポの方

Amazon S3を共有ファイルシステムとしてマウントするとスケールアウトする時に便利

s3fsは共有ファイルシステムとして使うと超便利

ポイントは、複数のインスタンスからs3fsで同一バケットをマウントし、共有ディスク化できる、というところ。

ファイルアップロードするとローカルディスクに書き出しちゃう典型的なアプリに便利

結構この手のWebシステムは存在する。例えば、CMSのデザイン変更やブログ記事の写真など、アップロードされたファイルをディスクに書き出すような仕組みのWebシステムがあったとしよう。
そのシステムをそのままスケールアウトすると、アクセスを分散させることになって、毎回アップロード先のサーバが変わってしまう。
大抵の場合、アップロードされたサーバ上のファイルに書き出してしまうわけで、そのまま使うと各サーバのローカルファイルに保存され、他のサーバから参照できなくなってしまう。

NFS無用

できるだけWebシステムを変更せずに先述の状況を改善しようとすると、NFSなどの共有ファイルシステムが有効になってくるわけだが、どうもスケールアウトさせながらNFSの面倒をみるのがうっとおしい。そんなときにこそs3fsが便利なのです。

やってみよう！

早速、半袖先生に試してもらった。仕方なく表示が256Tのストレージになってるけど、理論上も無限のサイズ。さらにインスタンス間で共有できるとなれば、これを使わない手はないでしょう。

注意点

いくつか気になるところを試してもらったんだけど、S3の性質はちゃんと理解した上で使ったほうがいい。通信状況を見ていると大量にあるファイルのlsなんかは本当に悲惨だし、

% cat >> hoge

のようなファイルの追記をはPUTで丸ごとアップロードし直しだ。おそらくログなんか格納したら目も当てられなくなっちゃうだろうなぁ。

ブラック企業っぷりを紹介(続・小企業に勤務時間は必要ない)

前回の記事ではてブをいくつかもらえて、コメントを見ていてなるほどと思った。やはり皆様勤務時間についての考え方はシビアなのだね。ただ、僕もかつては雇われる側だったけれど、どこの会社も大なり小なり問題を抱えながら進んでいるのではないだろうか。社員を雇用してやっと１年経ったばかりだから、丁度いいタイミングなので、もう少し弊社のブラック企業っぷりを反省点として暴露しておこうと思う。

※ただし、これだけは最低限の誤解ないようにと思って言いますが、自己責任で勤務時間を設計できるようにしたことはあくまでも仕事に対する自由度と成果を期待してのことです。 この自由を与えたことにより労使関係が消えてなくなるわけは無く、法律によって定められた従業員の保護を放棄するものではありません。って言うかできない。当たり前だけど。

労働時間の管理は確かにできていない

悔しいけれど、これはその通りで、正直感覚でしか見れていない状況。 メンバーの働き方を見ていると、大体以下の通り。

1. たぶん１日７〜８時間くらい勤務しているのではないかと思う。休憩も思い思いに取っているのだが、このアバウトさは要改善のポイントだろう。
2. たまに在宅でやる人もいる。
3. そして出勤時間は朝８時の人もいれば、夕方４時の人もいる。
4. もちろんお客様とのお約束には合せる前提。
5. 土日は休みだが、人によっては土曜日仕事している人もいるはず。たまにメールが飛んでいる。
6. 年間20日の有給を設置しているものの、これも消化率は悪く、呼び掛けをしないとなかなか休まない状況。ここも要改善。

最近会社内で議論されているのは上記3番太字の部分。みんな自分を最適化するために勤務時間を設定しているんだけれど、労働時間ベースの管理がどうも合わない。会社が早朝出勤を善とするなどどちらかを優遇したり、どちらともつかない折衷案で勤務時間を決めれば、どちらの人間にも不都合なわけだ。

ゆえに勤務時間って本当に決めなければならないのか？要らないんじゃないの？と思っているわけです。

うちは管理できているもんねフフフっていう会社でも、結局実態と合っていない管理をする会社は多い。 結局帰宅後に勉強するよう強要してみたり、社員が労働時間を申告する形式になっていて残業時間のつじつま合わせを自主運用しなきゃいけない雰囲気になっていたりしていて、そっちの方が問題だろう。

成果成果と言うけれど正直それだけで給与は決定できていない

実は全く成果と連動しない基本給が少ないながらも設定してある。あとは家賃補助手当(家賃の半額相当、上限あり)があるくらい。旅費交通費は普通に支給している。言う人に言わせるとこれは本当の「成果主義」ではないかもしれないので、割合が大きいことから「成果中心」と表現した。

そして成果を正しく評価することも正直できていないと思っている。 これは永遠のテーマになると思っていて、今なお自信はない。

しかしひとまずここで言う成果とは何か、どこまでやると成果で、実際どのくらいリターンがあるのかは説明して合意をもらっているつもり。この算出アルゴリズムは社員と決めているんだけど、結局議論しているうちに「とにかくやってみて、数字出すしかないね…」という弱小企業故の悲しい結論に。失注なんかがあるとかなり悲しい空気に包まれます。

ただ、労働時間に対し対価を払うという考えだけは絶対によろしくないと思っている。成果が正しく評価できない以上に、同じ条件下のメンバー２名がいたとして、ダラダラ仕事している人の給料が高くて、サクっと１時間で仕事を終えた人の給料が低くなるというのはどう考えてもおかしいだろう。

生い立ちが制度無しのブラックスタート

社員を雇う環境整備が出来ていないことを理由(←ご指摘の通りこれはイイワケ)に、当初は２名の役員だけで進めていた。 残業なんて関係ない世界で徹夜もあった。 そんな中、偶然社員になりたいと言う人材に出会ったのをきっかけに、それならと急遽社会保険など最低限の仕組みだけは何とか準備。

そういう意味では基本的に社員の労働環境整備は全て後手に回っているのは事実。 せいぜいアーロンチェアとHHKを支給したくらいか。物的な改善しか出来ていない。

これまで「全て自前で勉強して環境整備する」という方針で進めてきたので、行政書士さんや社労士さん、税理士さんなどにお願いすることなくやってきた。本来なら迅速に会社を働きやすいものに仕立てていくところは犠牲にしてきた。そろそろ綻びも出てくるだろうと言うことで、税理士さんだけは付けてみることにした。今後は過去に独学でやった部分の修正をしていくことになるんだろうと思っている。

それから弊社は今フルタイムメンバーが７名しかいない。労使関係で言うと、取締役が4名もいて正社員は3名しかいない。まだ誰が何をどれだけやっているのか把握できない人数ではないと思っている。 「人数が増えたら今の制度ではダメなので変える」という話はメンバーに毎回言うことだが、今の段階では引き続き勤務時間というものを明確に規定しない方向でやってみようと考えている。

VAIO君はあきらめて工人舎の超軽量超小型ネットブックを買いました

工人舎SC3WX06AS購入

修理前にと思って代替機として準備しました。これで４万円切る価格ですよ。最大の特長は以下の通り。

1. 超軽量798g！これでバッテリ込みの重量。
2. 電源アダプタが小さい＆２個も付いてくる！片方は事務所に常設。
3. 回転するタッチパネル液晶！マウス要らない。

外出が多いので、個人的には上記が気に入っていて、あとはOffice 2007(特にパワポ)が動いてくれる+VGA端子もあるので文句無いです。鞄に入れても重さを感じないところは素敵。
もちろん欠点もあります。

1. キーボードが小さすぎる！でもこれは軽量化・小型化とのトレードなので正直目をつぶれます。キータッチは好き。メモを取ったりちょっと編集したり小一時間作業する分には全く問題ない作り。
2. とにかくダサい！起動時に出るギラギラとしていて旧近未来なロゴはいただけない。これは本当にひどい。筐体も「小さい＝カワイイ」を否定できる底力を秘めている。
3. 本体が結構早々に熱くなる。

何にしても前回はちょうどシステムの開発中だったので、キーボードの使いやすさなどを追求した結果VAIO Type-Sになったりした。引き続きこの壊れた原因がまだ分かっていないもののVAIOは修理できる見込みはあるので、その後も開発用途に使っていきたいので、あとは本当に持ち運びだけを意識したPCがあれば外出時のメインマシンとして重宝することにはなると思う。

VAIOが８ヶ月で不調、SonyStyleの対応が重たすぎる

VAIOが壊れた

８ヶ月は最短です。今年1月にType-Tが壊れ、開発の一部実装を担当していたまっただ中、急遽買い替えた法人向けモデルのType-Sだったが、8ヶ月経った最近になってキーボードのShiftが接触不良のような感じになり時々効かなくなるようになった。

仕事では外出で必ずと言っていいほど持ち運んでいたので、壊れやすい境遇ではあったのかも知れない。Shiftが効かないのは色々不便なので、早速サポートに連絡した。

SonyStyleのサポート電話があまりにひどすぎる

最初のうちは、ソフトの不具合なのかハードの故障なのかを見極めたいという趣旨で質問が始まったので了解し、変なソフト入れたんじゃないかとか、リブートしろだの何だの電話で３０分やりとりしていたのだけれども、一向に改善されない。調査要求も次第にエスカレートしてきて、ついにサポートから電話越しに「それではOSの再インストールをしましょう。バックアップしてください。」と切り出された。すごい！やる気だ！

さすがにびっくりです。そんなのやる時間があったらとっくにやっているだろうと思い、代替機もない状況で他に仕事もあるので、修理に出してキーボード取り替えたいだけだと伝える。すると「それでハードのせいじゃなかったら調査費に3,500円とる」と言う案内。高いとか安いじゃなくて、サポート電話の質問や要求に全て答えなきゃならない前提になっている事にガッカリ。質問攻めでオールグリーン、送ってよし！って言う流れ。例外は無いのだろう。

VAIOはこれで３台目で、製品そのものは気に入ってはいたんだけど、うーん。今回初めて法人向けのモデルを買ったのですが、それはそれですぐに対応してくれるワケでもなさそうです。個人で買うのと実質何が違うのかわからない。（サポートの電話の人も良くわかっていないようでした）ノートPCを持ち運ぶ人にとって壊れたときの迅速な対応は結構重要だと思います。

調べてみたら、SonyStyleの対応については別の内容だけれど堀江さんもイラっとしていらっしゃるご様子です。電話長過ぎ。

小企業に勤務時間は必要ない派の意見

最近、社内で色々と語られている問題として「小企業に勤務時間を決める必要はあるか？」という話があります。
いやー、そうか〜、今その議論をしなければならない人数になったと言うことなのか。ちなみに僕は「ルールなんて少ない方が良い」と思っている派で、以下にその理由を３つ書いてみようと思います。

1. 成果中心のワークスタイルに合わない
2. ペナルティの多い会社が魅力的とは思えない
3. 守ったところでそれを評価する意味がない

成果中心のワークスタイルに合わない

なぜならば、メンバーに成果を期待する企業が、メンバーに対してルールをもって律しようとするのはある種の矛盾がある。ルールは成果に対してあまりに大きな足かせであると思う。

ルールが少ないからこそ成果を発揮するためのワークスタイルを設計できる。 自分が成果を出そうと試行錯誤したい時に、会社がそのやり方はダメだと言う必要があるだろうか？

成果を発揮するためには、自分を最適化する必要がある。自分のルールを自分で作らなければならない。これは自分のルールを他人に強要しないことでもあるわけで、善とされるルール、悪とされるルールはあくまでも当人だけの価値観なのだと思う。

だから１日１時間働いて帰ろうが、夕方に出社しようが、周囲と調整した上で自由にやって欲しい。これについて文句を言ったことは無いわ けだが、ただし、成果が上がっていない時には1時間で帰ったことに対して文句を言われることがあるというだけ。最適化のための自分ルールが間違えていると言うことを示している。

ペナルティの多い会社が魅力的とは思えない

社内のルールはただ作っても形骸化を待つだけ。
「守れなかった」→「次こそ守りましょう！」という話を繰り返すことに何の意味もない。チェックを増やそうとか強化しましょうとか言ったところで同じ事。
それを避けるため、今度はどうしても守らせる力学の議論が必要になる。つまり、ペナルティをどう設計し運用するのか、だ。

企業内においてのペナルティというのはすなわち給与・賞与との連動だろう。ただし、昨今は旧産業が新産業の創出を可能にし、より多様化されてきている中で、それなりに「仕事を選択できる時代」にあると思う。
メンバーに給与・賞与をそもそも低く設定している状況下では、これ以上に「選択されなくなる条件を増やす」ことを行うのは得策ではないように思える。

守ったところでそれを評価する意味がない

ルールとは「成果への足かせ」であり「ペナルティとセット」であるとは先述した通りなんだけど、今度は逆にこのルールを守った人をどう評価すれば良いかということにもなる。

足かせを乗り越えるエネルギーで売上があがっていくわけでは決してない。ある者は与えられてしまった足かせを振り払えないまま、その閾値を超えることをあきらめ、ルールに従うことが仕事であるかのように振る舞うようになるだろう。
そんな状況で企業が「成果を出せ」「イノベーションを起こせ」と叫ぶのは矛盾ではなかろうか。こうした事象の一側面が、大企業病の何かと共通している気がしてならない。

ここで言うルールは約束とは違う

そもそもペナルティのあるものは守るべきだと思うが、それって大抵はルールじゃなくて約束に類するものだったりする。お客様とのミーティング、打ち合わせ予定、納期…などなど。

元は勤務時間の議論だが、何でもルール化して従うか否かを善し悪しとするのではなく、個々はもちろん、組織が成果を出すためにどうあるべきなのかという観点で柔軟に考え直すことが大切なんじゃないだろうか。

WebGL始動！

OpenGLとJavaScriptをバインド Webブラウザ向け3D標準規格、「WebGL」は2010年前半登場

実は４年前に全く同じ事考えて少しだけ実装してみたことがあります。
いつか時間ができたらコードを増やしていこうと思っていたのですが、気づいたらすっかり時間が経過していました。

以前も書きましたが、第二のMesaになることを想定していたので、寿命は長くて１年。ブラウザの基本機能として組み込まれたらすぐに置き換えられるだろうと考えていて、あまりモチベーションが沸かなかったのは事実です。結果論ですが実際はこうして４年あったので、ある程度でも実装を進めていたら面白かったのかなとは思います。

[Wakame] Wakame 0.4.2をリリースしました。

Wakame 0.4.2をリリースしました

今回大きく変更されたのは以下の３つ。

1. Wakame masterへのコマンド発行がWeb APIになった
2. Agentが必要ないリソースを定義できるようになった
3. 対応プロダクトが増え、MySQL Slaveの追加をサポートした

特に、最後の対応プロダクトは、以下の４つです。

• MySQL_Slave
• Nginx
• Elastic IP
• Elastic Load Balancer

Elastic IPや、Elastic Load Balancerに対応するためには、そのインスタンス上にAgentがおけないことも考慮しなくてはなりません。そのため、Agentが必要ないリソースを定義できることが重要になります。また、masterへのリクエストがHTTPになったことで、CUIでのコマンド発行だけでなく、将来的にはGUIなどからリクエストを受け付けることも可能になると思っています。

バグレポートなどよろしくお願いいたします。

[Wakame]インフラ勉強会の時に使った資料を公開します（遅すぎ）

インフラエンジニア勉強会#1に参加してきました

こちらの勉強会は、PostgreSQLな人から声をかけていただきまして、発表することになりました。

インフラ勉強会 20090711

View more presentations from Yamazaki Yasuhiro.

資料にある通り僕はインフラエンジニアではなくて、社内では半袖先生とカツオ先生にお任せしちゃったりなんかしている者です。
プログラマだと言うのも何か変で、やっていたのは小3〜大学を卒業するまでの間。最後は音声のストリーム通信プロトコルを書いたり、ゲームエンジン作ったりVRシステムを組んだりしていました。WebシステムはCGIプログラムをC++で無理矢理書いて、そこで知識がストップ。14年もの間、あんなに毎日楽しくコードを書いていたのに、就職を機にいきなり書かなくなった。理由は良く分からない。何でだろう。Javaのせい？

起業した今でも自分が何をすべき人なのかたまに良く分からなくなることがあります。直感的にやりたいことは山ほどあるんだけど、しかし僕は一体何を目指し、どんな人生を…以下、中二病。
まぁいいや。その話はまた今度！

[Wakame]RubyKaigi 2009のLightning Talkに出ました

スライド貼っておきます。フォントはメイリオが明朝になっているので雰囲気がおかしいです。

反省

色々あります。

• 5分でしゃべるにはスライド量が多すぎた
• もう少し言語としてRubyを活用した側面で発表すべきだった

こんなところでしょうか。
特に内容は結構悩んだ末に微妙なものになってしまいました。
そもそも認知度の低いプロダクトであるWakameですから、それが何なのかは言わなければならないと思う反面、もっと深い実装面での話がしたいという思いもありました。
個人的にはユーザモードのThreadモデルがむしろ便利だと思う点や、似たようなプロダクトとしてScalrの実装(php)とかと比較しても面白かったかな〜なんて思っています。
まぁいいや。また今度！

20090717 Ruby Kaigi Lightning Talk

View more presentations from Yamazaki Yasuhiro.

[Wakame]Tokyo2.0で簡単なプレゼンテーションしました

Tokyo2.0に出席しました

もうインチキ英語すらしゃべれないので、日本語で発表しました。ustreamされているとは知らず、最近同僚に教えてもらって気づきました。

内容は、前回AmazonでLightning Talkした時のものとほぼ同じですので、スライド内容も再掲しておきます。

明日はRuby会議のLightning Talkだなー。日本語で詰め込めるようだったので、このスライドとはオモムキを変えて、大部分作り直しました。うまく話せるかしらん。

Lightning Talk Wakame on 9 April 2009

View more presentations from Yamazaki Yasuhiro.

[Wakame]gihyo.jpでWakame第４回目（ひとまず最終回）

そして第４回目（ひとまず最終回）を掲載することができました。よかった。

今回は、Amazon EC2上でデータベースのスケールアウトをしようと言う例で、Wakameを使わずに動かせるスクリプト付きです。コードを見ながら実際に動作させてMySQLレプリケーションするところを試せます。

これまでAmazon EC2でスケールアウトを一例なり紹介した記事が全体的に見ても数少ない気はしていたので、本稿が少しなりとも何かのお役に立てたら幸いです。また、出たてで情報の少ないWakameの0.3と0.4についてフォローアップも出来たのではないかなと思っています。

色々と大変お世話になりました。＞ご担当者様

石川県が子供に携帯持たせちゃダメ宣言

思わず「時代錯誤だ！」と叫んだあなたへ

あちこちでニュースになっているみたいだけど、この見出しだと「子供に携帯持たせたらダメだとか時代錯誤も甚だしい！」とか言う印象を持ってしまうので、原文を当たってみる。

• 過去の議事概要《平成２１年６月定例会》より
  • 議会議案(PDF)

第三十三条の二　県は、青少年による携帯電話端末又はＰ Ｈ Ｓ 端末（ 以下この条において「携帯電話端末等」という。） の適切な利用に関する県民の理解を深めるため、啓発その他の施策の推進に努めるものとする。
２ 保護者は、携帯電話端末等の利用制限に当たり、青少年の年齢、発達段階等を考慮の上、青少年の健全育成に資するよう適切な対応に努めるものとする。
３ 保護者は、特に小学校、中学校、中等教育学校（ 前期課程に限る。） 及び特別支援学校（ 小学部及び中学部に限る。） に在学する者には、防災、防犯その他特別な目的のためにする場合を除き、携帯電話端末等を持たせないよう努めるものとする。
４ 保護者、地域団体、学校関係者その他の青少年の健全育成に携わる者は、相互に連携して、携帯電話端末等の適切な利用に関する取組の促進に努めるものとする。

要するに、防災や防犯など便利な側面は大いに使っていくが、害になる部分を見極めるよう促していきましょうという話。
中学生では害を見極められるほどの資質が無いだろうから、明らかなメリットが無い限り使わない方がいいよね、って読める。
言うほど時代錯誤な感じはしない。

それより気になる…

却下されたみたいだけど、「北朝鮮の核実験に抗議し核兵器廃絶と非核平和を求める意見書」とか「経済危機対策の円滑な実施に関する意見書」とかこの６月に議論してる場合じゃないよ的な議題がとても気になる。

[Wakame]Wakame 0.4.1をリリースしました。

今回は色々と改善作業を行いました。ソースコードはかなり整理されました。

gem化

先週末に6/26(金)にWakame 0.4.1がリリースされました。今回はtarではなくgem化されたので、インストールが簡単になっています。EC2上じゃないと動かないのですが、インストールは出来るでしょうから、ソースコードを見てみよう程度でもお試しいただけますと幸いです。

# gem install wakame

また、各種ジェネレータも追加されました。

# wakame example

これでexampleという名前のディレクトリができ、その中にシステム構成単位のプロジェクトができあがります。Rails風なのはRailsと同じジェネレータを使っているからです。

リソースもジェネレートできます。

# cd ./example
# ./script/generate resource apache_www

プロジェクトの中に、Apacheを利用したAssetサーバの設定がジェネレートされます。あとはコードを見て調整していきましょう。

今後はどんどんジェネレートできるようにしていきます！

最近ではmysqlレプリケーションとpgpool-IIレプリケーションモードでのスケールアウトを確認できているのと、nginx、Elastic Load Balancerにも対応させたいと思っています。7月中には0.4.2あたりに組み込めるのではないかと思っています。

Master-Agent間の役割が少し変更されていたり、もっと目立つ大きな変更があるにはあります。

[Wakame]gihyo.jpでWakame第３回目

やっと、gihyo.jpに第3回目が掲載されました。
遅くなって申し訳ございません。。。

今回は、デモをお試しいただけますので、ぜひチュートリアルとしてやってみてくださいませ。

最近のイベントでの発表予定

※6/29(月) RubyKaigi2009 Lightning Talkを追加

今のところ近々に２つの会議に出席し、Wakameについて簡単にお話させていただく予定です。
お時間のある方はぜひ会場でお声がけいただけますと幸いです。

• 7/11(土) 19:00〜21:00 インフラエンジニア勉強会
• 7/13(月) 19:30〜20:00 Tokyo2.0
• 7/17(金) 17:50〜18:50 RubyKaigi2009 Lightning Talk
  

いやー、本当にイベントが目白押しで楽しいですね。

MySQL SlaveをElastic Load Balancerで振り分ける方法

[Wakame]Rails2.3.2+mysql_replication_adapterでDB負荷分散

MySQLレプリケーションをして増えたSlaveに対し、SQLのReadクエリ分散をしようと思った時、大まかに２つの方法でDB接続する方法が考えられる。

1. アプリケーション側から複数あるReadクエリ分散先のDBを選択する方法
2. アプリケーション側からは決まったIPにReadクエリを投げると、そのIPにあるバランサーがReadクエリ分散先のDBを選択してくれる方法

前者の方法は、動的にMySQLのSlaveを増殖させていくと、それに連動してアプリケーション側が持つSlaveリストを更新しなければならない。
アプリケーションサーバの種類によっては、その後再起動を迫られるものもあるだろうし、DB接続ライブラリが少し賢ければ、オンラインのまま設定の再読込をしてくれるかも知れない。

弊社は基本的にRailsを利用しており、上記の方法を検討してみたが、やはりSlaveリストを更新する方法は複雑でアプリケーションの作りに関わりすぎるという評価になった。

後者の、アプリケーション側からは決まったIPにReadクエリが投げられる場合は、Slaveリストというものは常にそのIPの１エントリ固定となり、更新する必要がなくなる。
接続先の選択はそのIP上にいるバランサーに一任されるからだ。

今回は、このバランサーにElastic Load Balancerが使えるのではないかと言うことで、メンバーに検証をしてもらった(表題のリンク先)。
うまくいけばWakameに任せたいので、その前段階までやってもらったわけだが、これが想定通りきちんと動作しているように見える。

「MySQL SlaveにはElastic Load Balancerが使える」
次はこの結果を受けて、Wakameに取り込んでいく作業が必要そうだ。

[Wakame]gihyo.jpでWakame第２回目

gihyo.jpでWakameの特集第２回目が先週末に公開されています。

ちなみに今日が第３回目の締切日です。
間に合うのか…？！

[Wakame]gihyo.jpでWakameの連載が始まりました。

本日より、技術評論社様の御好意で、gihyo.jpにてWakameの連載を開始いたします。
毎週のペースで6月中の更新となる予定です。

Amazon EC2の活用方法なども説明した連載になる予定ですので、特にWakameをご利用なさらない方でも、お読みいただけるのではないかなと思っております。
ご感想などいただけますと幸いです。