「WEBベースのプロジェクト進捗管理ソフトのお勧めは?」記事へのコメント

Wiki。

[eto (5805)]

やっぱりWikiがいいと思います。全然「プロジェクト進捗管理ソフト」じゃないけど、
それはテキストベースで管理するとして。とりあえずPukiWiki [pukiwiki.org]がおすすめ。

Re:Wiki。

[Anonymous Coward]

完全に履歴を保存できるWikiってどんなのがある？

Re:Wiki。

[Anonymous Coward]

TikiもAsWikiもZWikiもできそうだけど？

Re:Wiki。

[G7 (3009)]

Tikiの履歴管理は、単に過去のVerのファイル(の内容)をそのまま保存するという富豪流なんだけども、
それでも半年くらいがんがん運用してても全履歴ファイルがせいぜい数MBにしかならなかった。GBじゃなく。

今時のHDDのサイズならば、楽勝だってことですね。
テキストって軽いメディアなんだな、と今更ながら感心した次第。
これが有りがちなOffice系ソフトとかだったらと思うと…

＃Tikiの素朴(?)さが好きなのでG7。
＃あとSwikiも(自分で運用したことはないがユーザーとして見る範囲で)良い感じです。

閑話休題。

Re:Wiki。

[Anonymous Coward]

＞テキストって軽いメディアなんだな、と今更ながら感心した次第。
軽くないと思いますよ。
65535
10進数text = 65535 = 5byte
16進数text = 0xffff or ffffh = 6 or 5 byte
Binary = ffff = 2byte
文字列-->バイナリへの変換も必要ないので圧倒的にバイナリのほうが軽いです。
だからＰＣ－９８時代にはデータをbinで持つのは普通でしたね。
当時は「なんでUNIXとかって効率悪いtextでデータ持ってるの？」とか嘲笑してました。
割と最近でも３Ｄのデータをtextで持ってたり。
（floatをbinで持つのとtextで持つのでは大違い）

メンテナンス性がいいとか、
人にわかりやすいとか

Re:UNIXという考え方(Offtopic)

[Anonymous Coward]

>当時は「なんでUNIXとかって効率悪いtextでデータ持ってるの？」とか嘲笑してました。

以下のＷｅｂ頁で詳しい解説がありますです。
http://www1.sphere.ne.jp/smart/unix0308.html
http://www.not-enough.org/abe/manual/comm/about-unix.html

#それにしても、プロジェクト管理もＵＮＩＸ思想に基づいて行うことが出来ればいいのになぁ

Re:UNIXという考え方(Offtopic)

[G7 (3009)]

うーん、Unixの考え方は、漠然というか抽象的な思想こそ悪くないんだけど、
実際の設計という話になると、途端に変というか自己矛盾というか、
つまり「これのどこが(優れた)部品化の実現形態なのだ？」とクビを傾げたくなります。

Unixのやり方だと、「お得意であるはずの部品化手法で、viやEmacsすら部品に分割できない」という問題があります。
http://hpcgi2.nifty.com/guion3/tiki/tiki.cgi?c=v&p=UNIX%A4%C8%A4%A4%A4%A6%B9%CD%A4%A8%CA%FD こんな感じです(笑)。
Unixのアーキテクチャは、部品化とフィルタ化を混同しているというか、
プロセスという仕組みが部品化の「フィルタ化以外の手法」を阻害してるというか、
処理モデルは面倒

Re:UNIXという考え方(Offtopic)

[Anonymous Coward]

いろいろ突っ込みどころが満載でなんともはや・・・。

とりあえず、

>1:プロジェクトの体制を変えようと思ったら、いちいちプロジェクト全体を終了解体しないとならない
>2:親子関係は絶対であり、直接会話していいのは、直上の上司か直下の部下だけ
>3:融通が利かなくて困るんで、結局部下が自分で勝手に全部の仕事

Re:UNIXという考え方(Offtopic)

[G7 (3009)]

>UNIX 的思想とやらを完全に勘違いしているのがよく分かるな。

ここはひとつ、Unixの不名誉(笑)のために、
「どうおかしいのかはっきり書けよ」と煽ってみるテスト(^^;

いや、思想はたしかに悪くないんですよ。思想のサワリの部分は。

でも、だとすると、それこそUnixの実装者が(笑)、その思想とやらを勘違いしてUnixを実装したのではないか？
と穿ちたくなるくらいに、Unixがやってる部品化のアーキテクチャは
限定的な代物(NetworkモデルでUnix Pipe流を再現することは出来るが、逆は無理。つまり表現力の多寡の問題)です。

つまり、控えめに言っても言動不一致ってことになる。
＃ところで、ここでいう「思想」って、後付けじゃなく当初から明示されたものなのでしたっけ？

まあ、30年前の機械の性能じゃ、迂闊にNetworkモデルですって訳にもいかなかったってのも
あるだろうけどね。(でも、その割には既にLispは存在していたようだが…)

逆にいえば、だからこそEmacs※は、OSつーか環境つーかと呼びたくなるような代物に
ならざるを得なかった、ってことかなと。

※Unixerにとってメジャーどころな実例としてEmacs。それはそれとしてそんなEmacsがLispな代物であることは偶然なのか必然なのか…