# 210 PTT (in Japanese)

第 210 回 PTT のお知らせ

日時: 1995年 7月13日 (木) 18:30 から

場所: お茶の水女子大学理学部 3号館 6F会議室

	地下鉄 銀座線   護国寺駅下車 案内板に従って下さい (10分くらい)
			途中急な坂があります。
	地下鉄 丸の内線 茗荷谷駅下車、春日通りへ出て、
			薬局がある方へ進んで下さい。
	正門の前に出ます。(10分くらい)(共立出版が見えたら反対方向です。)
	構内に入ったら理学部3号館に直行せず、理学部2号館の横にあるドアから
	入ってエレベータで上に上がったのちに連絡通路を使用して会場にいらし
	て下さい。

話者：村野紀代

題目：バージョン更新の可視表示ツール

概要：　ソースファイルや文書ファイルの多くは、変更が起こるとRCS等の機能を用いて、あるいは旧ファイルをとり置く形で、バージョンを更新していく。
　執筆者が複数の場合には、更新した趣旨と内容をメンバーに通知する必要があるが、実際にどの部分をどの様に変更・追加したかを詳細に通知する作業は負担である。
　電子情報では、他のユーザには更新後のファイルも新規ファイルも同様に見え、そのままでは修正や変更の匂いを伝えることはできない。
　そこで、プレーンテキストファイルの背景色を変えて、紙メディアでもとの用紙に変更・追加の切り貼り作業を行なったかのように見ることのできるツールをTCL/TKで作成した。
　具体的には、各バージョンに固有のテキスト背景色を持たせ、最近更新された行ほど明るい色で表示する。マウス操作により紙をめくるように変更前の行をみることができる。また、更新の回数を厚みで表示し、多数回変更されている行を厚く表示する。上記のテキスト全体の様子が把握できるように縮小図を表示する。
　これにより、

	・変更追加箇所の検索を容易にする。
	・バージョン間の比較を容易にする。
	・変更の集中する箇所や変更が多数回起こった箇所を即座に把握すること
	  ができる。
	・従って、情報の不徹底による更新作業の混乱を防ぐことができる。

また、共同作業においては同一バージョンを複数の作業者が更新する場合の競合が問題となる。今後、競合を表示し編集できる機能を付加したいと考える。

食事:今回もありません．

次々回:
1995年 9月 日 (木) 早稲田大(予定)
葉書の残りは     枚です



差出人、幹事:

東京農工大学工学部電子情報工学科　並木美太郎

第 210 回 PTTメモ

日時: 1995年7月13日(木) 18:30〜20:00

場所: お茶の水女子大学 3号館6F

題目: バージョン更新の可視表示ツール

話者: 村野紀代（お茶の水女子大情報科学科）

出席者: 粕川正充, 井上美香, 田中利果, 桧和田美穂, 小野寺光永(お茶大), 馬上博樹, 佐々木崇郎(慶応大), 久野靖(筑波大) , 赤池英夫, 小出洋, 中林清隆, 斉藤正伸, 中村嘉志, 宮岡亜矢子, 前田雄次(電通大), 田中哲朗, 下國治, 小川宏高, 立山義祐(東大), 金東虎(新潟国際情報大), 並木美太郎(農工大), 佐口泰之, 中津利秋 (富士ゼロックス), 和田英一, 以上 24名

質疑応答:

私は社会人学生であり、業務の中で特定エンドユーザ向けのアプリケーション
ソフトや調査報告書の作成を２〜４名のメンバと共同で行なっている。ユーザ
のニーズをユーザ自身に明確にしてもらい、我々が正確に把握するために、プ
ロトタイプをユーザに提示し、それに対するコメントを反映するという、やり
とりを介してシステムや調査書を作り上げていく。従ってバージョンのアップ
が煩雑に起こる。 


執筆者が複数の場合には、更新した趣旨と内容をメンバに通知する必要がある
が、実際にどの部分をどの様に変更・追加したかを詳細に通知する作業は負担
である。


　紙というメディアと電子情報を比較すると、紙が相対的な空間位置で記憶し
やすく、使用した痕跡などから時間的な経過を残すのに比べて、電子情報では
他者には更新後のファイルも新規ファイルも同様に見え、そのままでは修正や
変更の匂いを伝えることはできない。


　そこで、ファイルを重ね合わせ、diffの視覚化を行なうツールをTcl/Tkで作
成した。具体的には、各バージョンに固有のテキスト背景色を持たせ、最近更
新された行ほど明るい色で表示する。マウス操作により紙をめくるように変更
前の行をみることができる。また、更新の回数を厚みで表示し、多数回変更さ
れている行を厚く表示する。上記のテキスト全体の様子が把握できるように縮
小図を表示する。などの機能を持つ。


　これにより、更新作業を支援することができると考える。また、変更の集中
する箇所や変更が多数回起こった箇所を把握することにより、バグの潜在箇所、
機能仕様の不明瞭な箇所、ユーザの重要関心箇所などが発見できるのではない
かと期待している。実験評価は今後の課題である。


　今後は、RCSのディレクトリと接続して重ね合わせを自動表示する機能やネッ
トワーク上での作業者との画面の共有を考えている。


　現状の問題点として、行単位の差分であること、処理時間、画面の占有率が
大きいことがあげられる。





質疑：

       1) 文書構造の解析の必要性
          現状では、大きな段落の移動や組み変えに対応できない。
          行単位のdiffでは限界があり、テキストを構造化して考える必要あり。
       2) バージョンの分岐・派生への対応
          CSCWに発展させるには、解決すべき問題点が多い。
          例えば、バージョンが分岐していった場合にどう対応するか。
       3) 処理時間について
          ・処理方法の考え方--- 行に属性を持たすなどの方法に変える
          ・どれくらいのスパンで使用が起こるものなのか、頻度とスパンの関係
       4) 実験評価について
          定量的評価よりも、実際の使用にたえるものにして実践の中から
          学ぶことのほうが実りが多い。
       5) ニーズについて
          日常の中で、このツールを使用したいと考える場面は確かにあるであろう。
   その他、以下のような情報も頂きました。
        6) rushという Tcl/Tkのコンパイラ有り。
        7) 本ツールはMuleでも実現が可能と考えられる。
           Muleで作成すれば、エディタ機能が強化され実践的になる。
    当日は、貴重な御意見をたくさん頂きありがとうございました。
    大変参考になりました。