クラウド的な社内コミュニケーションを預かる Sysadmin 的な意味で試してみた。
パッと見
- facebook が簡素になったというか twitter が facebook っぽくなったような感じ
- メールアドレスのドメインで参加制限が自動的に掛かる非公開 friendfeed group みたいな感じ
- 全社グループがデフォルトでできて、それ以外に部署やチームなどの group を複数作成できる
- 基本は小さなメッセージのやりとりで、ファイルの添付もできる
- Web UI のほかに AIR アプリとモバイルアプリがある
- ガラケーはたぶん非対応
実は friendfeed で非公開 group を運用してたんだけど、絶対そっちの方が面倒くさい。chatter.com で使える同一ドメイン同士なら chatter.com の方が楽。逆にドメインを越えたチームを作りたければ Google や Zoho など別なものが必要。
よく分かっていないところや不満
- モデレータ権限は与えられるが管理権限は与えられないのだろうか。というか管理できる内容が今ひとつ分かってない。
- 今自分がどの timeline を見ているのか分かりにくい。group の timeline を見ているのか followee の timeline を見ているのか。
- 同時に、どこに post しようとしているのか分かりにくい。group に post にはたぶん慣れが必要。
- アプリはともかく Web UI すごく重い
- AIR アプリは PPC Mac じゃ動かなかった＞＜
まとめ
friendfeed は facebook に飼い殺されてしまったような感じになってしまっているけど、インターフェイスは friendfeed の方がずっと分かりやすい。でも機能的には Chatter.com の方が断然企業ニーズに合ってると思う。
cf. 社内ナレッジの「逆引き辞典」をChatterで実現–日テレ アックスオンのChatter導入奮闘記 - 事例 - ZDNet Japan
[2011-02-15 追記]
chatter.com の検索はもしかしてユーザー名、グループ名、テキストファイルの内容、に制限されているかも。普通のtweet(?)が引っ掛かってこないような気がする。
以前、生の CGI を生の Rack で rackup してみたけど、Sinatra についてはうまく CGI で動かすことができずにいた。でも上のバージョンでは何の苦もなく動いてしまった。いつの間に？
しかも FastCGI も Sinatra Book にあるように面倒なことしなくても Hanlder を切り替えるだけで動いてしまった。なんだこれ！ 楽すぎる！
いよいよ Sinatra でなんか書きたいわけだけど、時間が…っ!!!
例によって twitter ログからサルベージ。ネタが混んでいたので1月29日のネタを2月1日分として書く。
11:10:39 >wtnabe< また ini_get( 'include_path' ) で取れる値が予想しない
ものになって苦しんでいる。なんでぢゃっ。
11:21:57 >wtnabe< どっから出てくるんだろう、この値は
11:25:35 >wtnabe< php -c で ini ファイルを指定する場合、システムデフォ
ルトの php.ini は読まないのか。その中に include_path が書かれ
ていない場合は恐らくコンパイル時に決定する include_path が出て
きてしまうと。
11:26:35 >wtnabe< ということはスクリプトの動作時に include_path にパス
を追加しようにも基準のパスが狂っていてどうにもならない場合があ
ると。
何をしようとしていたかというと、include_path を補正してコマンドラインからテストを動かすための ini ファイルを生成して、それを食わせてテストを動かすということをよくやるのですが、思わぬ値が返ってきて混乱していたのでした。
今にして思うと -c で読み込むべき ini ファイルを指定しているのに、指定していないファイルを読み込んでしまうとしたらそれは明らかにおかしい。当たり前っちゃ当たり前なんだけど、値が空になるのではなく予想外な値が出てきたところで混乱したらしい。
ちなみに help ではこんな感じに書かれている。
$ php --help
Usage: php [options] [-f] <file> [--] [args...]
...
-c <path>|<file> Look for php.ini file in this directory
-n No php.ini file will be used
-d foo[=bar] Define INI entry foo with value 'bar'
あ、ini ファイル名だけでなくディレクトリ名でもイケるのか。
※ おまけで。このときは Linux 上で作業していたのですが、カレントディレクトリの php.ini ファイルがどうしても読み込まれてしまうようなので php.my.ini という名前のファイルを生成するようにしました。でも今、手元の OSX では再現しません。なんなんだろう。マニュアルを読むとカレントディレクトリの方を後で探しに行くはずなので、勝手に読まれることはなさそうなんですけどね…。
石川県産のズワイガニの名称が加能（かのう）ガニに決まっていたそうです。（知らなかった。）そういえば石川県産のズワイガニには越前ガニとか松葉ガニみたいな名前なかったね。
ちなみにカニは面倒なのであまり好きではありません。でもあえて食べるならズワイだなと思います。日本海側に住んでいて冬の海の味覚を愛でない手はない。
WMI関係 （ハニーポッターの部屋）
メモ。scriptmatic は Perl と Python が使えると。Perl か。。。Python か。。。
個人的に気になるところだけピックアップ。
- スキンのナビゲーション部分の設定が楽に
- skin および CSS のファイル名変更
- 1.4.5 用の skin が 1.4.4 以前で動かなくなる
- tDiary テーマ対応（どの程度の対応かはよく分からないけど）
skin の修正時、PHP をベタベタに書かなくてよい部分が増えたのは歓迎。
デザインしなくていいから楽でいいけど、tDiary テーマを Wiki で使うのって HTML の意味的には明らかにおかしいんだよなぁ。PukiWiki くらいのユーザー数が居れば tDiary テーマに従わずに PukiWiki テーマを作りやすくする方向でよかったように思う。将来的にはそうなるかもしれないと期待しておくことにする。
calendar プラグインや diary プラグインを使ったとき（ないけど）に tDiary テーマが最大に生きる、という方向だとスマートかな。
バグフィックスが入ってないような気がするんだけど、1.4.4 → 1.4.5 のアップグレードは問題がなければ無視してよいってことか？ それにしても 0.0.1 の修正にしては影響範囲が大きいような。PHP 本体のようなアップデートのあやうさを感じるのは相変わらずですな。
映画の日ということで映画に行こうとしたら、なんと『ルパン三世カリオストロの城』をルパン誕生35周年のイベントで公開している映画館が！ うわ、『レッドドラゴン』の先行上映に行こうと思っていましたが…、ルパンにしてしまいました。いやーなんかこう、ほのぼのした映画が見たいと思っていたのです。
以前ここに書いたほど簡単じゃないのかも。PukiWiki をその構成のうえで動かしていると、あるパターン（まだ特定できていない）において編集がまったく反映されなくなります。うーん。OpenSA + mb ってのをきっちり build しないとダメなのかしらん。そんなことするならお手軽な OpenSA のメリットが…。うーん。
内部動作としては素の Apache を利用して、WebDAV や SSL が必要な局面を想定してフロントに OpenSA を置く、二段構えの構成にすればいいのか。そんな面倒な思いをするくらいなら、UNIX に移行して一から build する？ まー状況によりけりですかね。