MovableType

 このサーバーにも試しに入れてみたが、入れ替えるかどうかは思案中。カテゴリ分けできたらいいなあとは前から思っていたから、設定方法がわかれば移行してもいい(多分プラグインが必要)。

 このサーバーなら足りないものがあれば入れることができるから、MySQLにチャレンジしてみるのもいいかもしれない。ま、そんな高機能なものにしなくても、量も速度も全然余裕なんだけどね。

 ただ、このサーバーの弱点として、LAN内からの更新に難がある。ダイナミックドメインと仮想サーバーを併用しているのが直接的な原因で、cgiについての知識が充分ではないのと仮想サーバーを使っているのが根本的な原因。cgiの設定で記述する「場所」が問題なのだ。

 ルーターの外からはdydnsによってIPが確定され問題はない(今、これを読んでいる人の状態だ)。しかし、LAN内からはpanhead.homeip.netというドメインは解決できないのだ。今は、家では192.168.0.xx/~panhead/index.htmlという感じでローカル内のIPアドレスを直打ちして入力している。これがcgiの設定で解決できるのか、ddns+仮想サーバーの限界なのかは分からない。

 後、MTとは関係がないけど、このページの評価ボタンは好きなので、なくしたくないことも移行を阻んでいる。コメントはなかなか付けにくくても、ポチっとするのは抵抗が少ないだろうから。実際に、コメントは付いたことがないけど、ポチは時々押してくれているから。

movabletype

 意外に簡単に設置はできたが課題山積。会社で契約しているレンタルサーバーでは画像を縮小するためのparlモジュールが入っていないから、写真をアップロードして自動的に整理ということは不可能だった。縮小画像を別に用意してもいいが、オリジナルを別にアップロードするのではメリットがないなあ・・

 それ以前に、気付いたこと・・・会社のレンタルサーバーは200Mしかないので、1枚あたり600kbの画像を山のようにアップロードするわけにはいかない。今俺のPC上のマニュアルフォルダはすでに80Mだ。レンタルサーバーには会社紹介のホームページも入っているので、使い切るわけにはいかない。だから、オリジナルのデジカメデータをwebサイト上で一括管理することは不可能だった。前もってに気づけよ>俺

 それと、デフォルトのMTではカテゴリごとのインデックスは作ってくれないらしい。ログインすれば編集メニューでフィルタリングができるが、人に使ってもらうには使えない。というより、操作を教えたり、教えなおしたり、さらに繰り返したり、別の人に教えたり、絶対に忘れるだろうパスワードを覚えておいてやったり、また教えたりするのがいやなだけ。画面上に見えるようにして、「・・・・って書いてあるところをクリックしてください」なら、3回ほど言えばいいからね(それでも3回は覚悟が必要)。

 ということで、ヴィジュアル版マニュアルをMTで作ることは諦めたが、テキストデータベースとしての有効性は確認できたので、業務ログに使ってみるか。これまで、業務ログはFMPを使っていたが、MT化してもいいかもしれない。

 簡単にインストールできたのも下のwebサイトあってのこと。感謝!

Blogの可能性

 今は会社の業務マニュアルをHTMLで記述している。記述というほどのことはなく、HTMLエディタで説明を書き写真を並べるだけだ。それでも文章だけのものよりはるかに分かりやすい。

 しかし、デジカメで撮ったデータを縮小して配置するのが面倒だ。というよりファイルの管理が面倒なのだ。また、一つの業務が複数のカテゴリにまたがっていることも多い。業務ごとにフォルダを作らないとファイルが収集つかなくなるからそうしているが、フォルダをまたがってリンクしているとフォルダを変更できなくなる。階層構造はもちろん、フォルダ名を変えることが致命的なリンクエラーを起こす。

 もちろん、最初から階層構造やフォルダ名、ファイル名のルールを決めて作っていく人には無縁の悩みだが、個人ベースでテストを繰り返しながら作っているときに、サイトの設計図を描いてからファイルを作っていくことは不可能だろう。

 今日ブログサイトを読んでいて、カテゴリや検索があるので、これええやんと思った。やった順番に入力するだけで記録になる。キーワードを複数入れておけばカテゴリ分けなんかしなくてもいいし。本文検索もできるから後で困ることもない。ただオリジナルの写真がでかいので自動的に縮小データを作ってオリジナルにリンクして欲しい。高機能な掲示板か日記スクリプトでもいけるかもしれないがどうかな。まあ、日記と掲示板とブログは機能の選択の違いでしかないが。 

 俺の作るマニュアルが他部署で作るものとリンクされる日がくるとは、今の会社にいる限り、考えにくいが、一人で作っても十分効果はあるだろう。

 とりあえずなじみのCNOTEで試してみるか。

理想

PCとの同期(クレードル・電波・赤外線等)
PCとの同期を使ってのネット接続
PC上のPIMソフト同梱あるいは、一般的なソフトとの同期。(グループウェアとの連携ができればさらに良い)
統合webサービス。
 PC上のPIMとwebサービスとの同期サポート
 PCからのキャリア・メールのメンテナンス
 PIMの公開と共有
 PIM等からの通知機能(新規登録とかカレンダー変更)
 インスタント・メッセージ(webからでもコミュニケーターからでもアクセス可能)
 blogツール(当然、写真・ムービー対応)

 こんなところかなあ。イメージが貧困で既存サービスを使えるようにするだけだが、それだけに投資も少なくて済む。しかし、これ、コミュニケーターである必要はない。今の携帯で十分可能なことばかりだ。

 今でも、j-phoneのサイトでカレンダーサービスはあるが、端末からwebアクセスで確認するだけで、端末のスケジュール機能と同期するわけではない。これでは、確認のたびに課金が発生するので「使えない」。トラフィックを増やす妙案でも使ってもらわなきゃ意味がない。

 上の統合webサービスを実施すれば、端末によるメールの送受信やカレンダー確認のためのパケット量は減るかもしれない。しかし、合計すれば絶対に通信量は増える。それ以上に、キャリアへのロイヤリティもあがる。というより、これにはまってしまえば、他のキャリアへ移行することは困難になるだろう。(それはそれでちょっと困るんだけどね・・・)

 なお、この統合webサービスのアイデアは自由に使ってもいいけど、作るときはキャリア・ローカルなものにせず作って欲しい。メールのweb上での確認は無理としても、インスタント・メッセージや公開PIMは共通フォーマットで願いたい。

 できたら、アイデアを書き込んで欲しくて投稿可能にしますのでよろしくm(_ _)m

コミュニケーター

 コミュニケーターはオタクにとって理想のPDAに近いかもしれない。

 しかし、日本市場で一つ大きな壁が立ちはだかる。キャリアのやる気のなさだ。すでに北米市場で多数のCDMA対応コミュニケーターを出しているAUには技術的な障害はほとんどないと思われる。少なくとも、他のキャリアに比べれば、大幅に楽なはずだ。にもかかわらず出そうとしないのは、そこにメリットを感じていないからだろう。

 端末をキャリアがキャリアブランドで売りサポートをする日本の形態が邪魔をしているのかもしれない。PDAのトラブルは携帯電話の比ではない。普通に使っていてもリセットがかかったり、システムエラーの起こるPDAをケータイショップの売り子にサポートができるはずがない。今のように、「ユーザーの責任で」と未サポート前提でオタクに売るのと、携帯電話と同等の信頼性を要求されるコミュニケーターとではサポートの負担は全く違うだろう。

 また、オタク界では「As is…」や「ユーザー責任」が浸透してきたが、携帯電話ユーザーの大多数にはそれは受け入れられないとの判断だろう。俺もそう思う。というより、個人レベルではかなり認められるようになったし、ユーザー側でそんな端末を避ける選択眼は備わってきていると思う。

 問題は、日米の企業の感性だ。アメリカの企業であれば、こんなコミュニケーターでも便利な点を評価し導入することがありえても、事なかれ判断しかできない日本の企業(とりもなおさず、日本企業で意思決定をしている年齢層の無能のことだ)では、合計でプラスであっても、少しのマイナスがあると全否定するので、受け入れられない。

 あと、キャリアの利害関係もあるかもしれない。コミュニケーターがPCと同期することで、通信の減少を招くことを恐れているかもしれない。カレンダーを確認するだけでパケット通信が発生するほうが、PCとの連携+PCによるネット接続よりキャリアにとって金になる。メールにしても同様だ。

 PCとコミュニケーターの同期で期待するのは、キャリアが期待することの正反対であることが多いのは事実だ。コミュニケーターをクレードルに置いたら、ホットシンクでPCと同期し、PCの常時接続を使って直接webから情報を取得できるということを期待するだろう。

 しかし、一見そうは見えても、ネットワークをうまく使えば、キャリアにとってもユーザーにとってもメリットのある方法が見出せるだろう。キャリアが制限を加えれば、キャリアにとってメリットの大きい通信方法があったとしても使われない。使われなければ投資した費用は全額無駄になる。ユーザーにとっても魅力のある方法を提示することで需要が喚起されれば、やらずほったくりほどの利益率はなくとも回収は可能だから。「使ってもらってなんぼ」のサービス業だという認識を再確認して欲しい。

 では、どんな方法がいいのか・・・

movabletype情報収集

movabletype.orgすべてはここから始まる

milano:日本語化パッチとさぽーとBBSも充実しています。

CHEEBOW(Motokazu Sekine):ロリポップの例ですが、参考になります。

sunouchiさんの有名なサイト。新疆ウイグル自治区の写真もすごい。

SalvageShipはMySQL関連の情報をいただきました。

MovableTypeのインストール記
にはlinuxでのインストール例があります。

マニュアルの日本語版

平田さんのMoblogゲートウェイを感謝して使います。

マニュアル日本語化にも感謝しよう

クレードル

 初めてpalmを見たときにクレードルによるホットシンクに感激した。ザウルスがPCを不要とする方向で多機能化・高価格化しているときにPCとの連携を前提として機能を絞ったpalmのコンセプトとクレードルは一体だった。

 ということは、携帯電話の次の一手はUSBクレードル充電器だ。USBケーブルだけでの充電もいいが、primsのようなパワーサプライも併用して欲しい。でなければ充電時間がかかって仕方がないから。また、PCの電源を入れていないと充電できないのでは本末転倒だしね。

 で、palm desktopのような添付ソフトをつけてホットシンク・バックアップができるようになれば、日本のpalm型PDAは滅ぶだろう。残るのは、次々新しいマシンを買って環境構築自体(時にはトラブルさえ)を楽しむオタクか、物理的に大きな液晶やキーボード入力したい層だけになるのではないだろうか。

 そこをカバーするためにpalmはコミュニケーター化を進めるのだろう。

AUのGPS

 新しいAUのGPSチップの説明で、「端末で処理できる」と言うものがあった。それで分かった。prismのGPSモジュールであれだけ掛かる位置情報の取得がケータイでそんなに高速にできるのか疑問だった。最近のケータイのCPUはprismのものより速い可能性があるので、「prismより速いはずはない」とは言えないけどね。

 これまでの、というか今の端末はケータイから送られてくるデータをもとにサーバーで位置を演算するらしい。端末からの情報と複数の基地局の情報も使えばさらに精度は上がるだろう。それ以前に、基地局の情報から半径10kmくらいには絞れているから捕捉すべき衛星の周波数をサーバーから送ってやれば、GPS端末単体で頑張るより短時間で計算することが可能かもしれない。面白いなあ。

 ということは、新しいGPSチップが搭載されて初めてGPS端末といえるのではないだろうか。今のは、GPS衛星の発信する位置情報電波を受信して、サーバーに送るだけだ。これなら、あんまり端末に負担をかけなくてすむ。掛かるのは、回線使用料だけ(それが狙い?)。

 それにたいして、J-phoneの位置情報は捕捉している基地局の位置でしかないから、同じ位置でも変わってみたり、10km近く離れている基地局のデータだったりする。10kmの誤差のある位置情報では・・・ロードマップを読むときの参考にすら使い難い。しかも、捕捉する基地局は最短距離とは限らないから、市レベルでの移動しかトレースできない。

 そういえば、あまり聞かないが、WCDMA端末の位置情報はどうなんだろう・・・QUALCOMがGPSの特許を押さえているんだろうか・・・?