[ Blog in Japanese ] [ Blog in English ]

2008-09-18

未整理

ケータイ・カメラからの関連検索

Sekai Camera という iPhone アプリでは,AR (Augumented Reality) 的な技術をつかって,カメラにうつされたものの情報をかさねて表示するらしい (iPhoneアプリの未来を見せてくれた 「Sekai Camera」). しかし,カメラの映像と付加情報から,そこにうつされているものをきちんと識別するのはむずかしい. Sekai Camera がすぐ実用になることはないだろう. それよりも,カメラの映像をもっと loose な検索にむすびつけていくほうが,すぐに実現できて,おもしろいのではないだろうか?

つづく…

2008-08-12

Wikitecture:要求仕様検討

iPhone による写真投稿の方法

E-mail による写真投稿は携帯の機種をとわず,可能である. つまり,だれでも投稿することができる. 一方,iPhone の柔軟性をいかして,Web や,もっとつかい勝手のよいアプリケーションによって投稿することもかんがえられる. しかし,とくに Web に関しては iPhone にファイル・システムが確立されていないことが障害になる.

つづく…

Wikitecture:要求仕様検討

フィールドからの写真投稿

フィールドでとった写真をすぐにアップロードするには,携帯電話で写真をとり,メイルまたは Web で送信するのがかんたんである. しかし,携帯電話についたカメラの弱点はズームできないことである. 単なるおまけの写真ならばそれでもよいが,建築をうつすときなど,距離や角度が重要な写真をとるのに携帯電話が適切かどうかという問題がある.

つづく…

2008-05-29

Wikitecture:設計仕様検討

PukiWiki ベースの開発計画

PukiWiki のプラグイン機能を使用することによって,およそ要求仕様をみたすことができるとかんがえられる.

つづく…

Wikitecture:要求仕様検討

リスト作成機能

Amazon にはリストマニアという機能がある. それと同様な建築などのリストをつくる機能をいれるとよい. カテゴリーにわけることはできても,それだけでは建築をたばねる機能は十分でないからである.

2008-05-27

Wikitecture:要求仕様検討

TownWiki の (自動) 多言語化

TownWiki の各項目がふくむべき項目つまり名称,設計者,施工者,所在地,建設年,構造,建築面積,建物の写真・動画,説明等,掲示板,リンクのなかで,最後の 3 つ以外は自動翻訳が比較的容易であり,自然だとかんがえられる. したがって,TownWiki を多言語化し,これらの項目は各言語 / 各地域に共通にする,つまりいずれかひとつの言語で入力されたら他の言語に自動的に翻訳するようにすることがかんがえられる.

つづく…

2008-05-26

Wikitecture:要求仕様検討

地図にかわるものとしての 3D グラフィクス

女性には地図が不得意なひとがおおいという. そのため,とくにナビゲーションの際にはつぎのような選択肢がかんがえられる.

つづく…

Wikitecture:設計仕様検討

モノの共通属性としての “生年” と “没年”

建築や店舗にかぎらず,動物やヒトもふくめたモノにはある期間のあいだ存在する. したがって,モノには通常,存在を開始した年と存在が終了する年とがある. ヒトであれば生年と没年である.

つづく…

Wikitecture:要求仕様検討

3 種類のインタフェース,全世代への対応

TownWiki は

  • PC だけでなく
  • 携帯からと
  • テレビからも
アクセスできるべきである. 携帯しかつかわないわかいひとにも対応し,PC や携帯をつかわない高齢者にも対応するためである.

また,携帯に対応するのはモバイル対応という意味もある. 実在のまちの情報をとりこんだ TownWiki はフィールド・アクセスによって,さらにいきる.

Wikitecture:要求仕様検討

Wikitecture か TownWiki か? -- スキーマの複雑さと汎用性

建築だけがもつ属性をデータ・スキーマにとりいれると,建築以外のものを表現するのが困難になって汎用性がうしなわれる. しかし,もともとの Wiki のようにいっさいの属性をとりいれないと,特徴がうしなわれる. 特定の属性に依存する検索機能は実現できなくなる. したがって,データ・スキーマの設計が TownWiki / Wikitecture のおおわくをきめる. しかも,いったんスキーマをきめてシステムを構築すると,あとからそれを変更するのは容易でない.

つづく…

Wikitecture:要求仕様検討

モノとコト

TownWiki (Wikitecture) は,おおきくわければモノとコトとで構成される.

  • 建築やそれに関連する店やグッズはモノであり,
  • 建築に関するイベントはコトである.

モノとコトに対してはことなる表現や属性 (スキーマ) があたえられるべきである.

2008-05-25

Wikitecture:製品調査

Wiki ソフトウェア調査資料

ベースとするべき Wiki ソフトウェアの調査をおこなっている. 調査の進展とともにこの項目の内容を更新する予定である.

つづく…

Wikitecture

Wikitecture のメタファ

TownWiki (Wikitecture) はつぎのようなメタファでとらえることができる.

つづく…

Wikitecture:要求仕様検討

広告/ショップ・リンク機能

Wikitecture の項目からは広告や商品へのリンクをたどることができ,またそれらに関する画像がみられるようにするべきである. ただし,露骨な商業主義は wiki への悪影響があるとかんがえられるので,Wikitecture サイトじたいが商業サイトになるのはさけるべきであろう.

つづく…

Wikitecture:要求仕様検討

検索機能

Wikitecture の検索機能として,キーワード検索,地図検索,年代 (竣工年) 検索などがかんがえられる.

つづく…

Wikitecture:要求仕様検討

ブラウズ機能

Wikitecture におけるブラウズ機能として,つぎのようなものがかんがえられる.

つづく…

Wikitecture:要求仕様検討

登録・更新機能

項目やその要素の登録・更新の方法として,つぎのような方法を用意する必要がある.

つづく…

Wikitecture:要求仕様検討

各項目の内容

Wikitecture の各項目はつぎの要素をふくんでいるべきである: 名称,設計者,施工者,所在地,建設年,構造,建築面積,建物の写真・動画,説明等,掲示板. これらのうち説明等,掲示板,リンクをのぞくと言語によらず共通の項目にする (つまり,ひとつの言語で入力すれば他の言語に自動的に翻訳されるようにする) ことができるとかんがえられる.

つづく…

2008-05-17

MWF:要求仕様検討

ワークフロー機能を実現するサーバの選択

メイル・ワークフローにおいては宛先アドレスによって機能が指定される. このアドレスは機能だけでなく,その機能が存在する (仮想的な) 場所もあわせて指定しているとかんがえられる. すなわち,そのアドレスのドメイン部において指定された場所において,その機能が実現されるべきである. この原則を無視すると,アドレスと機能との対応がくずれて混乱がおこる可能性がある.

つづく…

MWF:要求仕様検討

メンバー間の環境不整合への対応

ひとつのメイル・ワークフローにかかわるメンバー (ひと) のメイル環境は完全にはあわせられないとかんがえるべきである. これは,メイル・クライアントについても,サーバやプロキシについても,いえることである. メイル・ワークフローはこうしたヘテロジニアスな環境のもとでも,ただしく動作しなければならない.

つづく…

2008-05-12

MWF

本質的に分散型のメイル・ワークフロー

ワークフロー・システムは集中型の構成のほうが容易に実現することができる. しかし,メイル・ワークフローはメイル・サーバとメイル・クライアントとのあいだにはいるプロキシによって実現されるため,分散型の構成をとることが必須である. データベースだけはプロキシから分離して集中型の構成にすることも可能だが,プロキシが分散型である以上はその利点がいかせる構成にすることが適当だとかんがえられる.

つづく…

2008-05-10

MWF

多重帰属からくる課題

ひとりのひとが,すくなくともひとつの組織のメイルと個人のメイルとを管理する. 複数の組織に同時に属しているひともいて,そういうひとの数は今後さらに増加するとかんがえられる. 個人のメイルも 1 人だけの組織あるいは家族という組織へのメイルとかんがえれば,いずれも組織への多重帰属の問題だととらえることができる. こういう多重帰属がある状況のもとでメイル・システムやメイル・ワークフローがどうあるべきか,検討しておく必要がある.

つづく…

MWF:要求仕様検討

ユーザのスケジュール管理機能

メイルがスケジュール管理のためにつかわれていることは,よく知られている. Outlook などにはそれを支援するための機能がくみこまれている. しかし,このような機能は十分ではないし,標準化されていないのでメイラーをかえるとつかいつづけることができなくなる. メイル・ワークフローにおいては,より強固な基盤を確立する必要がある.

つづく…

2008-04-28

MWF:設計仕様検討

宛先指定におけるパラメタつきの機能のあつかい

宛先によって機能を指定する際に,パラメタをわたしたいことがある. たとえば添付ファイル名のチェックにおいてはファイル名やプレフィクス,ポストフィクスなどをパラメタとしてわたしたい. こういうときのために,メイルアドレスを機能とパラメタとに分解するしくみをそなえておくのがよいとかんがえられる.

つづく…

MWF:設計仕様検討

メイル・ワークフローにおけるトランザクション ID のあつかい

ワークフローにおいては個々のトランザクションを識別する必要があるが,メイル・ワークフローにおいてその識別子としてなにを使用するかをきめる必要がある.

つづく…

MWF:設計仕様検討

宛先指定によるメイルの手動 / 自動チェック機能の仕様

添付ファイルの自動チェックに関しては 「宛先指定による添付ファイル自動チェック機能の仕様」 に書いたが,ここでは手動チェックもふくめた,よりひろいチェック機能の仕様について検討する.

つづく…

2008-04-27

MWF:設計仕様検討

宛先指定によるメイリング・リスト機能の仕様

QuickML の方法を改良したメイリング・リストの実現に関しては 「QuickML 方式の簡易 “会議室” 管理の応用」 において仕様を検討したが,ここではそこでの選択肢をしぼって,ひとつの仕様にまとめる.

つづく…

MWF:設計仕様検討

宛先指定による添付ファイル自動チェック機能の仕様

メイル誤送信の分析」 に書いたように,重要なメイル誤送信のパターンとして添付ファイルのとりちがえや不足・過剰などがある. これらはメイルを送信する際にチェックすることによってふせぐことができるはずである. そこで,宛先として特定のテンプレートにもとづくメイル・チェック機能を指定することによって,このような誤送信をふせぐ方法について検討する.

つづく…

MWF:製品調査, MWF:設計仕様検討

メイル・システムの機能拡張法

SMTP の使用を前提とするかぎり,メイルサーバまたはメイルプロキシを使用した機能拡張の範囲は比較的かぎられている. Reasonable な方法はメイルの宛先 (RCPT コマンドの指定内容) や送信元 (MAIL コマンドの指定内容) によって動作をきりかえることである. QuickML [Tak 03] [Mas 03] はそういう機能拡張によってメイリング・リストを実現している.

つづく…

2008-04-26

MWF:設計仕様検討

QuickML 方式の簡易 “会議室” 管理の応用

QuickML におけるメイル・アドレスの用法 — 機能実現の手段」 に書いたように,QuickML においてはメイリング・リストをかんたんな方法によって管理することができる. ここではメイリング・リストだけでなく,ひとびとがメッセージをやりとりする場としての “会議室” の管理に対象をひろげて,その応用についてかんがえる.

つづく…

MWF:技術調査

QuickML におけるメイル・アドレスの用法 ― 機能実現の手段

QuickML [Tak 03] [Mas 03] は,メンバーの登録・削除や他のメイリング・リスト管理機能がかんたんなメイルをおくるだけで実現できるプログラムである. QuickML は SMTP サーバとして実現されているため,どんなメイル・クライアントからも使用することができる. SMTP は機能がかぎられているため,単純なメイルの送受信以上の機能を実現しようとすると,“to”, “cc” のような宛先指定をうまくつかう以外に方法はない. QuickML はそれをうまくつかって実現されている.

つづく…

2008-03-29

MWF:実装と実験

SMTP によるメイル検査結果の実時間応答のこころみ

SMTP の弱点」 においてのべたように,SMTP はその応答コードによっては比較的かぎられた情報しかかえすことができない. しかし,応答コードとともにメッセージをかえすことができるため,ある程度は実時間でメイルの内容を検査した結果をかえすことができる. Perl によってプログラムを記述して,実時間応答の実装をこころみた.

つづく…

MWF:製品調査

Qpsmtpd ― Perl で記述された SMTP デーモン

Perl によって記述された SMTP デーモンとして Qsmtpd がある. Sendmail Mailstream Manager と同様に,プラグイン・アーキテクチャをとっていて,容易に機能を拡張することができる. プラグインも Perl によって記述する. スパム対策のためのプラグインが多数,提供されている.

MWF:製品調査

メイルに関する Perl モジュール

CPAN に登録された Perl モジュールのなかには,インターネット・メイルに関するものが多数ある. そのすべてをここであつかうことはできないが,主要なものをサーベイする.

つづく…

MWF:設計仕様検討

メイル・テンプレートの検索

テンプレートの数がすくなければ,Thunderbird の 「テンプレート」 フォルダーのような,メイラーのフォルダにいれておくのがよい. しかし,テンプレートの数がおおいとき,あるいは組織ごとにテンプレートがわかれているようなときは,メイラーには必要最小限のものだけをいれて,他は Web ブラウザなどで検索 (ブラウズ) するようにするのがよい.

つづく…

MWF:設計仕様検討

メイル・テンプレートの用法

メイル・テンプレートは Thunderbird のそれのように,メイルを書くまえにアクセスして,メイルの記述をガイドすることもできる. また,メイルを書いたあと送信前にアクセスして,メイルの形式や内容をチェックすることもできる. 目的によってテンプレートの形式もかわってくる.

MWF:設計仕様検討

メイル・テンプレートの共有

Thunderbird などにおけるテンプレートは個人ごとに管理しなければならない. しかし,コラボレーションのためにテンプレートを使用するばあいは,テンプレートを共有する必要がある. そのためのかんたんな方法はテンプレートに URL をあたえて,HTTP などによってアクセスする方法である.

つづく…

MWF:経験と観察

メイル誤送信の分析

メイル誤送信の原因やそれにどのようなケースがあるかを分析する.

つづく…

MWF:技術調査

SMTP の応答コード

SMTP の基本の応答コード (3 桁の数値) および拡張応答コード (X.X.X) についてのべる. SMTP によってかえせる情報はかぎられている.

つづく…

MWF

SMTP の弱点

SMTP は SMTP サーバが直接メイルボックスにアクセスできるときは送信者にメイルがおくれないという返事をかえすことができるが,メイルをリレーするときには単純に OK という返事をかえす以外のことはほとんどできない. 現在ではメイルに関してウィルス,スパム,誤送信,情報漏洩など,さまざまな課題があるが,これらに関して現在の SMTP の応答によって対処できることはほとんどない.

つづく…

MWF:製品調査

Sendmail Mailstream Manager による誤送信防止

Sendmail Mailstream Manager は着信メイルのウィルス,スパムなどに関する対策と送信メイルによる情報漏洩などに関する対策をあわせてとることができる,サーバ上で動作するメイル・プロキシである. 拡張性が最大のウリである.

つづく…

MWF:製品調査

CipherCraft/Mail の誤送信防止機能

NTT ソフトウェアの CipherCraft/Mail Ver. 4 という製品はクライアント PC 上で動作するメイル・プロキシであり,メイルの暗号化機能とともに誤送信防止機能がウリになっている. 前者を省略した廉価版もある (前者が 100 ユーザあたり 98 万円,後者が 49 万円). メイル送信時に送信者がメイルの内容を再確認するのがおもな機能であり,メイルの内容を自動チェックする高級な機能はない (キーワードをチェックしてスコアを計算する機能はある). この機能に関しては特許出願中だという. 2007 年 11 月に誤送信機能を搭載した最初のリリース (?) が出荷されている.

つづく…

MWF:製品調査

Thunderbird のテンプレート機能の再調査

Thunderbird でどうやってテンプレートをつくる?」 では Thunderbird のテンプレート機能を調査して,うまく動作しないと結論づけた. その後 Thunderbird も改訂されているので,再度,調査をおこなった. バグは減少しているようだが,期待される機能ではないようにみえる.

つづく…

MWF

メイルに関する研究の再開

2007 年 5 月にメイルやワークフローに関する調査研究をおこなって,この研究ノートにメモを書いてきた. その後は休止してきたが,他のテーマの調査研究が一段落したため,再開する.

つづく…

2007-05-25

MWF:製品調査

Thunderbird でどうやってテンプレートをつくる?

Firefox もそうだが,Thunderbird でもあまりつかわれていない機能はデバッグがすすんでいない. メイルのテンプレート機能はワークフロー機能の基礎になる重要かつ便利な機能だが,Thunderbird のそれはうまく動作しない.

つづく…

2007-05-18

MWF:製品調査

“Workflow in the 2007 Microsoft Office System”

David Mann による題記の本 (Apress 刊) を読んでいる. 最近の Windows (Vista/XP) におけるもっともおおきな変化 (進歩?) のひとつは Windows Workflow Foundation (WF) がとりいれられたことだとおもうが,この本はそれが Office 2007 においてどういかされるかを書いている.

つづく…

2007-05-14

MWF:経験と観察

メイルのひながたと添付ファイル

メイルのひながたの用法にテンプレートの利点をのべたが,そこには添付ファイルについては書かなかった. もしテンプレートにおいて添付ファイルをつけることを条件とすることができれば,テンプレートをつかうことが添付わすれ防止にもやくだつ.

つづく…

2007-05-13

MWF:メイルの分類

ドキュメント定義

論文,仕様書などのドキュメント,あるいはメモを定義する. 送信者と受信者とがことなるばあいと,同一のばあいとがある. 同一のときは単純なファイリング,ことなるときは FTP とみなすことができる. ただし,ドキュメントは更新されることがある. つまり,版管理が必要になる.

つづく…

MWF:設計仕様検討

メイル・ワークフローのスケジュール管理

メイル・ワークフローにおいてはつぎのようなシステム・レベルのスケジュール管理機能がもとめられる.

つづく…

MWF:定義

プロジェクトとタスク

メイル・ワークフローの要素を定義する.

つづく…