2003-10-31
_ Tokyo Hacking Linux Users Group
bravo 氏の言ってた各自の目的で発散するための Users Group. THLUG が船出。本日スラドで告知。とりあえず irc に参加してみる。
_ Debian Emacs びっくり。
いきなり日本語が書けました。leim/quail を利用して。どうもこれは Debian package 独自に追加している模様。leim や quail そのものは別に特別なものじゃないけど。skk とも違う、クライアントサーバ型じゃない IM ですな。（まだよく分かってないけど。）
_ あ。
tDiary って日ごとのタイトルつけなくてもいいんだ。
_ PukiWiki 1.4 がいよいよリリース？
リリースを統括する人のいない弱さを完全に露呈しちゃってた PukiWiki ですが、どうやらそろそろ今度こそ正式リリースのようです。正直、1.4rc2 以降にあれこれ変わったのですでに私も全貌は理解できていませんが。
なんか上げなくてもいいような気さえしています。。。うーん、こんなんじゃいかんな。
2004-10-31
_ JotSpot beta account 申し込んでみた
wikiを使った「Web向けLotus Notes」に大きな関心 (ITmedia)
個人的には WYSIWYG は Wiki の最大のメリットである手早さと相容れない部分があると思っているんだけど、既存の Wiki のインターフェイスが初心者にとっつくにくいのは事実だし、改良は必要だとは思っている。
ということで WYSIWYG 以外にも工夫があるに違いないと踏んで、実際に体感するために beta account 申し込んでみた。多くの人に使ってもらうことが可能そうならできるだけオープンに検証したいと思っている。
申し込みから利用開始までの流れは自動化されていなかった。対応できるんかいな。
_ 多様な安否情報の提供と digital divide
ちょっとまだまとまりそうにないんだけど。NHKはいったい何がしたかったのかから続く一連のもの（高木浩光＠茨城県つくば市 の日記）を読んで。
NHK やサービス提供者の理解度の低さは問題として指摘すべきだと思う。ただもう一方で問題にしなくちゃいけないのは安否情報をより安全に、より多くのチャンネルで提供できるようにすべき、ということではないのかとも思う。これは前回公共性の高い組織の広報で触れたこととも通じてるんだけど、個人情報の話にする以前に、より多様な安否の確認方法がほしいということである。
例えば携帯。通話は難しいかもしれないが、原理的にはインターネットの方が接続の安定しない状況では有用なはずである。DoCoMo などの特定のベンダーに依らない、安否情報確認システムを国の予算で用意しておくことは技術的にはそれほど難しくないように思う。*1携帯なら端末を特定できるし、比較的安全に安否情報を、かなり1対1に近い形で提供できると思う。*2
ただ別なところに大きな問題がある。デジタルデバイドだ。すべての人間が携帯端末で情報のやり取りを行えるわけではない。普段から使っている人間でなければ緊急時にはまず役に立たない。電話としての利用はなんとかなる、というレベルの人間が緊急時に安否情報の確認をインターネット経由で行うのはかなり困難だろう。
じゃあということで、端末に自治体の防災無線を利用するのはどうだろう？ 防災無線を自治体間、自治体-国間の緊急情報のやりとりだけでなく、市民の安全確認のチャンネルとして使えないかな、ということなんだけど、自分は無線は完全に素人なので、インターネットとの接続など細かい話はまったく分からない。単に「そこにあって双方向に情報のやりとりができるモノ」ということで浮かんだだけだ。たぶん様々な問題はあると思う。安全性という意味では被災地の人間の情報提供はルーズに、被災地外の人間による情報の引き出しに認証を掛ける、という方向である程度確保できると思う。簡単なところでは身分証明書の提示と利用の記録をとる、というところか。ただこの方法は海外からは利用しにくいので、また別なゲートウェイが必要だ。
防災無線だなんて何ゆーとんじゃ、ということであれば、デジタル放送のラジオなんかが使えないだろうか？ デジタル放送と言ってもテレビほどの大電流が必要なわけでなし、電池駆動できるよね？（興味はあるけど確認すらしてない。）これなら一人一人持つことができるし、データのやり取りはある程度可能だと思う。ただここに個人の安否情報を載せるのはどうやるのか想像がつかない。
書き連ねてようやくまとまってきたが、問題は
- 被災者の安否情報をどうやって集積するか
- できるだけ素早く、なおかつ被災者のスキルやデジタルデバイドに影響を受けない方法がよいのではないか
- その預け先はどうやって信用するのか
- 集積しないという選択肢はもちろんアリ。ただその場合は双方にそれなりの資源とスキルが要ると思うのでここではとりあえず無視。
- 集まった安否情報をどうやって配信するのか
- 負荷の集中や単一回線への依存によるストップは避けたい（既存の電話網、携帯電話の通話網の限界に引っ張られたくない）
- 認証の必要のないレベルならできるだけ多くのチャンネルで配信できた方がよいと思う
- 個人情報のレベルでは情報の引き出しに認証を掛けるべきだと思うがどうやって認証を掛けるのか
- もう一つ、認証が必要な情報とそうでない情報に明確な基準が必要
- 国内だけでなく世界的に配信できる必要がある
- 海外在住の日本人に対してだけでなく、国内在住の外国人の家族が利用する場合にも対応できる必要がある
という辺りなんだろうか。なんか抜けありまくりそうな気がするんだけど。まーでもどっちにしろ一度単純化しておかないと抜けの確認もできないし話を展開しにくいし、今回はこのままいこう。
ふと思ったが、ココセコムじゃないけど、こうした安否情報ってビジネスとして成り立たないのかな。例えば家族で契約しておくと海外を含めた遠隔地でもとにかく安否の確認ができるってシステム。そのために Skype とか自前のシステムとかとにかくいろんな方法を確保してできるだけ迅速に確認できるようにサービス提供者は頑張る。誤解を恐れずに言えば安否の確認てのは身内のエゴ的なものでもあるわけで、保険と同じようにビジネスとしてソリューションを提供するってのは十分にアリじゃないだろうか。これは国とかさっきまで展開していたやたらと器のでかい話でもないし、電話やメールによる1対1の確認でもない、alternative な選択肢であり、今回の話の主旨ともなんら矛盾しない。うん、悪くないな。
問題はシステムの構築、運用、維持のコストがでかそうだから最初に国とか器のでかい話を思いついたのであって、これがビジネスとしてペイするレベルならビジネスでも十分な話だ。これなら情報の集積先をどうやって信用するか、なんて辺りもスムーズに解決できる。契約があるんだから話は簡単。
でもなぁ、なんかこう釈然としないのはなんでだろう。視点が公共サービス*3寄りなのは、やはり災害弱者が取り残される可能性がでかいと直感的に感じるからかな。保険もそうだけど、「存在を知らなければ利用できないサービス」ってのは本当の緊急時にどれだけ役に立つのだろうという素朴な疑問が残る。もちろん今の時代に無防備に生きている方が悪いのさという指摘はしごくまっとうだし、少なくとも労働者人口にカウントされている人間はその指摘を噛み締めておく必要があると思う。でも被災者は労働者人口にカウントされる人ばかりじゃないから。そういう人たちをどれだけフォローできるかが公共サービスの価値だと思うんだよな。
2005-10-31
_ Perl も DateTime なのか
Ruby の DateTime クラスと基本的には同じ考え方してんだろうな。便利に違いない。
_ ゼンドジャパンの規約とか
vi の情報がちまちま出てくるのはなんだ、IDE 売る気ないのか？(笑) しかし PEARコーディング規約のあのコメントブロックはやだなぁ。コメントで AA で四角を書くのはやめようよ。phpdoc あんだからそっちから生成すればいいじゃん。
以上、Planet PHP Japan から ゼンド・ジャパン株式会社 技術情報コンテンツ:phpspot開発日誌 を経由して。しかし Planet PHP Japan の、各サイトのタイトルだけおかしいのってなんだろうか。
2006-10-31
_ 旧Mac → Windows 逆Switchで気をつけるべきポイント
声高に言われないだけで、実はこの方向で移行している人はかなりの数に上るはず。とりあえず両刀遣いとして今のところ分かっているポイントをここにメモしておこう。
※ 例によって嘘、間違い、過不足はツッコミよろ、ということで。
- OS の操作性の違いは考えないこととする
- それ言っちゃったらキリないし、普通の人は OS ではなくアプリを使っているので、各種設定方法はともかく「作業」を開始するまでならなんとかなる。
- 両方で動いている大型アプリについても気にしない
- Office, Adobe ものなど
では気にするところはどこかというと。
- 絶対にアップデートさせる
- 温室育ちの Mac 使い*1はセキュリティに鈍感なので、かなり気合いを入れて教育する。そのうえで問答無用で自動更新にしちゃう。自動更新の適用で問題が出たら出たとき考える。（抜けない更新で地雷を踏んだら諦める。）
- ファイル名の制限
- Windows の方がファイル名に使えない文字の制限が多い。文字数の制限は緩和されるが、/ とか ? とか不用意に使っている場合はデータの移行ができないので注意が必要。
- メディアのフォーマットの違い
- Mac フォーマットのものは追加のソフトがない限り読めない。Mac では Windows フォーマットを読めるケースがほとんどなので、あとになってあれもこれも読めないと気づくケースが出てきそう。
- Finder と Explorer での挙動の違い
- いちばんびっくりするのは「上書き」と「入れ替え」の違いかな。まぁこれは Finder より Explorer の方がコンピュータ的には自然だし、恐らく少々の戸惑い程度で克服できるだろう。Windows 使いが見落としがちなのは「ラベル」機能かな？ 個人的には一切使ってないけど、バリバリにラベルやアイコンのカスタマイズをしているケースがよくあるので、それに依存してファイルやフォルダの分類を行っている場合、問題になるはず。
- テキストデータの扱い
- 改行コードと機種依存文字の問題。温室育ちの Mac 使いはこの辺に無頓着なので問題が出やすいかも。改行コードについてはアプリ側で吸収あるいは変換できれば問題ないかもしれないけど。
- メールデータの移行
- EUDORA とか Netscape Mail 使ってます、という場合は特に困らない。やっかいなのは Outlook Express を使っている場合。*2
- アプリのインストール／アンインストールの手順の違い
- Windows は Mac みたいに要らなかったら捨ててくれというわけにはいかないので、あまりスキルはないけどいじるのが好き、というタイプには注意。
- 設定方法が煩雑なのでデフォルトの設定が大事
- 多くの場合、Mac よりも Windows の方が設定変更の際の手順が多い。そこであとからユーザーが設定を変更しなければいけなくなるような状況を極力減らしておくことが肝要。
- Mac 独自ツールへの依存度の確認
- AppleScript バリバリ使ってますとか、grep, sed, awk, Perl など Mac 独自の UI がかぶってるものに強く依存してますとか、そういう場合の対処はかなり面倒。逆にこういうのがない場合の移行はそれなりにスムーズにイケるんじゃなかろうか。個人が個人用に作ってた小物ツールは無視。お仕事で使いたいなら認知されるようにしておかないとあとあと苦労するかもしれませんよ、というだけの話だと思う。*3
どれも個人での逆 Switch ではたいして問題にならないが、数が多いとそれなりの問題になるだろうというところ。特にファイル名やメディアの問題は後手に回ると不必要なコストが発生してしまう。
2007-10-31
_ go-pear.org なんてねぇ！
ドメインごとありゃしねぇ。
site:pear.php.net go-pear - Google 検索
つーことで
が正解。
そーーーーーーーいえば。大昔はこの URL だったような気がしてきましたよ？
つかさ。アナウンスねーの？ アナウンス！ なんか
PEAR :: Doc Bug #12250 :: go-pear.org domain is expired..
こんな報告が上がっているのがついこの間なのでもしかしたら中の人は何か頑張ってて、そのうちしれっとドメインも戻ってくるのかもしれないけど、だからと言って現時点で何のアナウンスもないのってどうなの？ pukiwiki.org がドメイン落としたのはまだ失笑程度で済むけど、Pear がこういうことやってるのはどうなんだ。マニュアルにはしっかり go-pear.org って書いてあるんだからさ。なんか対処してくんないとみんな困るでしょ？
ガッカリだよ！
_ PostgreSQL 8.1 以降、ユーザーとかグループとか言わない
おっつ。
ロールの概念には、"ユーザ"という概念と"グループ"という概念が含まれます。 PostgreSQLバージョン8.1より前まででは、ユーザとグループは異なる種類の実体として扱われていました。しかし、現在ではロールしか存在しません。すべてのロールは、ユーザとして、グループとして、またはその両方として動作することができます。
おっつ。
- LOGIN 属性を持つ ROLE（従来のユーザーに相当）
- LOGIN 属性を持たない ROLE（従来のグループに相当）
という具合に分かれるらしい。
リストアしようとしたら role がないと言われて一瞬 ( ゜д゜) てなたよ。
