ステレオスペルマム植替え

ステレオスペルマムの植え替えをしました。

その理由は、

• 成長しすぎて鉢にしていたヴェールヴェールのガラス容器が小さくなったこと
• ガラスに藻が生えて見栄えが良くなくなったこと
• 決め手は、風にあおられて落として割ったこと orz
  

です。

これまではネオコールで育てていましたが、このネオコール、球体のせいか、表面が緻密で根毛の入り込む余地が無いのか、少しも根が定着した感がありません。

根の中心には、ヴェールヴェールであったことを物語るスポンジが見えます。

そして、セラミスで植替え。

二周りぐらい大きなプラ鉢にしたので、バランスが良くなりました。


今後も、しばらくは これで大丈夫そうです。
というのも、一度水切れをしたら、幹の成長点が止まってしまったからです。
代わりに大量に出ている脇芽が成長したらどうなるか分かりませんが。


P.S.

受け皿が有ることからも分かるとおり、穴空き鉢です。
すなわち、穴空き鉢でハイドロカルチャーというちょっと変り種です。


P.S.2

何か虫が湧いています。

羽が生えていないし、顕微鏡で見ると6本足に触角に、お尻から角が2本。
白くて小さいけどアブラムシのようです。
しょうがない農薬でも撒くか...

ヒメモンステラをGet

土曜日にヒメモンステラをGetしました。

例によってセラミス化。

こんな感じです。

唯一の窓空き葉を少し傷つけてしまいましたが、まぁ、このくらいなら大丈夫。
下から、次の窓空き葉も出てきていますし。

天才的手法のおかげで(←サトイモ科が強いだけだろ)、翌日には根付き、吸い上げた水を葉の先端(よく見ると左上も)から滴らせています。
このあたりは、同じサトイモ科のポトスとそっくりです。
手触りもそっくりです。
ヒメなので葉の大きさも。

Google Readerでコメント機能ってShare with noteと何が違うの?

Google Readerでコメントを共有する機能がリリースされました。

Google Readerの記事をShareすると、記事の最後にAdd commentというリンクが追加され、これをクリックすることで利用できます。

実はShare機能は今まで興味が無かったので知りませんでしたが、Share with noteという今回リリースしたコメント機能と類似の機能があるようです。

両者(ここでは便宜的にcommentとnoteと記述)の違いを少しまとめてみました。

comment

• 自分はShared itemsフォルダで見える
  (ポストの下部に列挙される。名前はyou)

• FriendはFrined Shared itemsフォルダで見える(名前は本名)
• Shared itemsのパーマネントリンクからは誰も見れない

note

• 自分はShare itemsフォルダで見える
  (ポストの最上位に噴出しとして現れる。名前はyou)

• FriendはFrined Shared itemsフォルダで見える(名前は本名)
• Shared itemsのパーマネントリンクからは誰でも見れる(名前はニックネーム)

noteよりもcommentのほうが、表示が少し洗練されて、プライバシーが強化されたという感じでしょうか。


ちなみに、Shared itemsのパーマネントリンクでは右側にプロファイルが表示されますが、Friendが見ると本名が、他人が見るとニックネームが見えます。

また、Share with noteでAdd to shared itemsチェックボックスが現れますが、チェックするとそのたびShared itemにコピーが作成されます。
他方でチェックしないと、同様にコピーが作成されますが、これはNotesフォルダからしか見れません。

関連リンク:
グーグル、「Google Reader」に独自のコメントシステムを追加:ニュース - CNET Japan
「Google Reader」，友人とコメントをやり取りできる機能追加：ITpro
GoogleもFriendFeedから開発のヒントをもらうのが好き; Readerが会話機能を導入:TechCrunch Japan

サービス型アプリケーションは本当に危険か?

先のポスト「障害時の自動代替・修復は高度になるほど良い? (Gmail障害と改善方針について思うこと)」で今回の報道について、言いたいこともありますが、それは別の機会にと言いましたが、丁度良いタイミング(?)で［WSJ］ Gmailでまたも障害発生 - ITmedia Newsしてくれました。

と言うことで、今回も、Gmailの障害をダシに、ちょっと違う話を。


どうも一般的に、GoogleのようなサービスやAmazon.com、Salesforce.comなどが提供しているサービスを使うことは、企業にとってリスクを伴うことも判明しつつある(ITmedia)と言って、イタズラに不安を煽る傾向があるようです。

サービスが危険であるという主張の裏にある理由を推測すると、

1. 相手が信じられない (狭義のセキュリティ的に)
   
2. 相手のデータ保護が信じられない (耐久性的に)
   
3. 途中の通信が信じられない (可用性的に)
   

があると思います。

1.はどうでしょうか。
故意または過失により情報漏洩等が発生した場合、社内情報部門と、サービス提供他社でどちらが強く責任を追及されて社会的制裁を受けるかと言うと、明らかにサービス提供他社でしょう。
必然的に、セキュリティ確保に積極的になるのはサービス提供他社になるはずです。

2.はどうかと言うと、
データの耐久性をあげるには、データを冗長化する必要があります。
災害対策ともなると、冗長化した情報の少なくとも1セットは遠隔地に保管する必要があります。
一般的にこの冗長化はハードウェア、通信コスト、運用の人的コスト等、非常にコストがかさみます。
システムの規模が巨大になれば、または、システムの重要度が金融の勘定系のようにクリティカルになれば、これらのコストが見合うかもしれません。 しかし、いくらメールシステムやCRMが重要であると言っても、ユーザ企業がデータの冗長化を徹底するのは困難かもしれません。
それに対して、データの冗長化に関しては規模の経済が生かせるサービス型の方が有利と言えます。

3つの理由のうち、合理性があるのは3.だけでしょう。
システムの構成要素として、過去メール閲覧においてインターネットが追加になります。
構成要素が増えれば、必然的に潜在的な障害ポイントが増えるので可用性の観点では絶対的に不利です。

まとめると、インターネットを利用することによる可用性の低下のデメリットと、他の要因によるメリットを総合的に見て判断すべきでしょう。

個人的には、インターネットを利用することによる可用性の低下を他のメリットが上回るので、積極的にサービス型のアプリケーションを使うべき、と思います。


やや蛇足ですが、メールシステムの可用性について。

今回の2回のGmail障害における障害ポイントはインターネットではなかったので、3.インターネットの可用性の問題には該当しません。
また、メールの場合は元来インターネットからやってくる情報なので、MUAのサービス化に伴うリスクの増大は、MTAを含むメールシステム全体から見ると相対的に少ないものです。
さらに言うなら、メールのようなコミュニケーションツール、すなわち相手あってのシステムの場合、個々のユーザにとってのシステム(MUA/MTA)の可用性が同じなら、起こる障害はみんな同時の方が良いはずです。
自分のシステムだけ元気でも、相手のシステムが不調ならコミュニケーションできないことに代わりがありませんから。
そういう意味でも、多数のユーザが同時に障害に巻き込まれるサービス型の方が有利のはずです(心情的には逆だと思いますが)。



続けて、メールシステムのデータ耐久性(Durability)について。

メールシステムを純粋にコミュニケーションツールとして捉えた場合、可用性が最も重要ですが、今やメールは記録システムになっているでしょう。
この場合、可用性以上にデータ耐久性が重要です。
自社システムのメールサーバ容量の制限から、個人PCのMUAにメールアーカイブを保存している場合と、サービス型のメールMUAを比較した場合のデータ耐久性のどちらが優れているかは、もう説明の必要は無いですよね。

ホワイトデーは雨のち晴れ

今日はホワイトデー。
朝は大雨でしたが、かみさんとランチに出かけたときはあがっていました。
夕方、運動不足解消のため散歩したときには、下のようなきれいな富士山が見えました。

晴れたものの、春なのでかすんでいます。
おかげで何ともやわらかい色の写真が撮れました。
コントラスト検知式のコンデジオートフォーカスまでやわらかくなりましたが。(^^)

Stainlessで同一サイト複数セッション!

興味のある記事を見つけました。

Chromeを超えた? 1タブ1プロセスのブラウザ最新版「Stainless 0.5」 | パソコン | マイコミジャーナル

見出しによると、プロセスがタブごとに分かれていることが売りとなっています。
Web/ブラウザがOSになったとか言われていますが、ある意味OSの備えるべき保護機能を普通に地味に実装したと言えます。

これはこれで興味深いのですが、プロセス云々が非機能であるのに対し、
私が注目したのはこちらです。

Google Chromeを含む他のブラウザにない機能の例としては、異なるタブ／証明書を使い1つのサイトへ同時のログインを可能にする新機能「パラレルセッション機能」と、独自のcookie保管機構が挙げられた。

Webアプリは最近少し触れるようになった初心者ですが、ちょうど興味を持っていたところにこのニュースでした。

なぜこんなことが話題になるかと言うと、一重に、
HTTPは元来ハイパーテキストにおいて単にファイル転送を行うために開発されたため、(中略) ステートレスなプロトコルである(HTTP cookie - Wikipedia)
からですね。
これに対してクッキーが導入されブラウザ(プロトコル)がステートフルになったわけですが、こいつがブラウザグローバル。
すなわち(URLでは区別されるが)ブラウザのウィンドウやタブ間で区別されないと言うことです。(IEには例外があるってほんと?)

これがユーザにどういう影響を及ぼすかと言うと、タブやウィンドウを複数開いても、異なる複数のGoogleアカウントのGmailを同時に読むことが出来ない、と言うことになります。

これに対して不満を持っている人も少なからずいるようです。

例に挙げたGmailの通知機能限定ですがFirefoxの有名なアドオンにtLo : Gmail Managerと言うのがあり、複数アカウントのGmailの着信通知や未読件数表示が可能です。
汎用的には、クッキーのセットをタブごとに変更できるアドオンにNektra.com > CookiePie FireFox/Flock/GNU IceWeasel Extensionがあります。(使ってみたところ今ひとつ安定しませんでしたが)
同時ではありませんが、クッキーのセットお手軽に切り替える類似目的のアドオンにCookieSwap :: Firefox Add-onsなんていうのもあります。
また、先の記事では否定されていたChromeですが、 プライベートブラウジング(incognito)機能は、オープンな私と慎重な私で多重ログインする機能と見ることも出来ます。

まとめると、
Web/ブラウザが一人前のOSになるには、
複数のステートを管理出来ることが重要だが、
これにはブラウザ側が何らかの対処が必要で、
その一つの解がStainlessであり、
その他アドオンも複数あります、
ということのようです。


ところで、これはブラウザだけの問題ではなく、クライアントをクッキー(とSSLセッション)だけで区別しているプロトコルの問題でもあるように思います。
SSL通信路やCookieによる設定等の状態は共有したいが、案件毎にセッションを区別して管理したいとなると、とたんに破綻します(RESTfullに解決する方法はありそうだが)。


これに対して、WebのOS化に熱心なGoogleあたりが何かしてくるような気もしますが...

今後の動きに注目したいと思います。

# Webアプリ初心者への突っ込み歓迎

障害時の自動代替・修復は高度になるほど良い? (Gmail障害と改善方針について思うこと)

先日Gmailに大規模な障害が発生したそうです。
各所でこれについて取り上げていますが、今回はGmailや今回の障害自体の話ではありません。

Googleから2/24にGoogle Appsユーザーに向けてレポートが出されました

Google Apps - Gmail Incident Report February 24, 2009

Additional Details
A few months ago, new software was implemented to optimize data center functionality to make more efficient use of Google's computing resources, as well as to achieve faster system performance for users.
Google's software is designed to allow maintenance work to be done in data centers without affecting users. User traffic thatcould potentially be impacted by a maintenance event is directed towards another instance of the service. On Tuesday, February 24, 2009, an unexpected service disruption occurred during a routine maintenance event in a data center. In this particular case, users were directed towards an alternate data center in preparation for the maintenance tasks, but the new software that optimizes the location of user data had the unexpected side effect of triggering a latent bug in the Gmail code. The bug caused the destination data center to become overloaded when users were directed to it, and which in turn caused multiple downstream overload conditions as user traffic was automatically shifted in response to the failures. Google engineers acted quickly to re-balance load across data centers to restore users' access. This process took some time to complete.

これによると、

1. 数ヶ月前に、性能改善のために新しい地理的最適化ソフトウェアを導入した。
2. Googleのソフトウェアはメンテナンス時にもユーザの影響を回避するための他のデータセンタにリダイレクトされて代替される。
   
3. メンテナンス時に、新しいソフトウェアによる最適化の思わぬ副作用がGmailの潜在バグを顕在化させた。
4. Gmailの潜在バグによって代替先のデータセンタが過負荷になった。
5. これが更に後段の過負荷をもたらした。
   

ということのようです。

2の措置は今回の件とは関係なくずっと以前から行っていたと考えるのがGoogleの環境では自然でしょう。
1に関しては、「思わぬ副作用」とは行っているものの不良とは言っていません。
これに対して、3はGmailの潜在バグと明言しており、これを根本的原因と捕らえているようです。

まとめると、
「新しい最適化の思わぬ副作用がGmailの潜在不良を顕在化させ、Gmailの不良よる過負荷障害が連鎖的に拡大した。」
というところでしょうか。

これを聞いて、2003年北アメリカ大停電を思い出しました。
被害が拡大した原因には諸説あるものの、有力な説に送電管理システムのダウンにより連鎖反応を起こしたためというのがあります。

今回のGmailのケースはこれとそっくりではないでしょうか。

残念ながら、この教訓は今回は生かされなかったようですし、今後も生かされるかどうかが不安です。
というのも、先述のようにGoogleは根本原因をGmailの不良と捕らえ、さらには、基盤の自己修復機能を高度化することを良しとしているように思えるからです。

Googleは今回の問題に対する改善策として、

1. Given the risks associated with maintenance events, we understand that it's a traditional IT practice to limit maintenance events to weekends and evenings. This being said, Google's large distributed global infrastructure makes it impossible to mimic this traditional model because complex maintenance events cannot be completed to fit every user's off-hours. Our goal is therefore to innovate on the technology and process fronts to make our systems as self-healing and self-managing as possible. We feel that we run a very reliable system, but we also believe that there's always room for improvement. To that end, Google engineers work around the clock to make our productionsystems better.

グローバルなインフラであるGoogleは完全にオフラインの間にメンテナンスすることは不可能、と言うことを理由に、自己修復、自己管理技術を革新するとしています。

これには賛同しかねます。
北アメリカ大停電と同様に、今回のGmailの障害も自己修復が障害の連鎖を招き事態を悪化させたのだとしたら、自己修復、自己管理機能を強化することは逆効果かもしれないからです。
(それに、完全にオフラインは無理だとしても休日にすることはできるはずです。)

個人の経験から言える、HA(高可用性)システムのあるべき姿は、

• 自動代替メカニズムはシンプルに
• 自動代替はそれ自身でどこかに歯止を
• 緊急手動停止装置も

というものです。


今回の報道について、言いたいこともありますが、それは別の機会に。