2009/03/28

サンスベリアが回復 (新株も)

軟腐病(?)で大手術を行ったサンスベリアですが、その後の経過です。

当時、
  1. セラミスの水切れが悪すぎ(保水力がありすぎ)
  2. 土植えで育った根はセラミスの湿度には耐えられない(結局1と同じことを言っている?)
  3. 水も必要とする成長に必要なもう一つの因子である日に当てていない 
という原因仮説のうち特に2、3を疑い、
  1. 透明に腐りが入った部分を乾燥させて枯死させる(腐りが進行しないように)
  2. セラミスに合った根が必要と仮定して、今ある弱った髭根は捨てる覚悟で乾燥
  3. 植えつけたら、秋の残った日差しと気温で新しい根(株)を成長させる
  4. そのための最低限の水をやる
という対策を採りました。

対策1、2として2週間ほど乾かしたので、根はすっかり枯れ落ちて丸裸になりましたが、植替えを行い、対策3として暖房の効いた今の出窓(2重ガラス)に移動しました。
前回は根が定着するまでと思い日陰で腐らせてしまった反省から、植替え直後から窓際です。
10/25

その後は、冬にサンスベリアの葉が部分的に枯死したりもしましたが、
1/14

最近の暖かさもあり大分元気になりました。
部分的に枯れた葉の形はみすぼらしくはなりましたが、根元付近の若い葉からは生命力があふれています。
左の小さな株は買ってきたときに切り離した子株(1枚目の写真のでは右手前)ですが、大きくなったでしょ。

更に新株も出てます。
地下茎を伸ばして新株を作るほど、元気になったんですね。(感無量)

2009/03/20

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

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

その理由は、
  • 成長しすぎて鉢にしていたヴェールヴェールのガラス容器が小さくなったこと
  • ガラスに藻が生えて見栄えが良くなくなったこと
  • 決め手は、風にあおられて落として割ったこと orz
です。
これまではネオコールで育てていましたが、このネオコール、球体のせいか、表面が緻密で根毛の入り込む余地が無いのか、少しも根が定着した感がありません。

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

そして、セラミスで植替え。
二周りぐらい大きなプラ鉢にしたので、バランスが良くなりました。


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


P.S.

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


P.S.2

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

2009/03/18

ヒメモンステラをGet

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

例によってセラミス化。

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

2009/03/15

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

2009/03/14

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

先のポスト「障害時の自動代替・修復は高度になるほど良い? (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を比較した場合のデータ耐久性のどちらが優れているかは、もう説明の必要は無いですよね。

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

    今日はホワイトデー。
    朝は大雨でしたが、かみさんとランチに出かけたときはあがっていました。
    夕方、運動不足解消のため散歩したときには、下のようなきれいな富士山が見えました。
    晴れたものの、春なのでかすんでいます。
    おかげで何ともやわらかい色の写真が撮れました。
    コントラスト検知式のコンデジオートフォーカスまでやわらかくなりましたが。(^^)

    2009/03/08

    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アプリ初心者への突っ込み歓迎