アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
私はプログラマです。1040 formに私の職業としてそう書いています -- Ken Thompson
Wiki。 (スコア:4, 興味深い)
それはテキストベースで管理するとして。とりあえずPukiWiki [pukiwiki.org]がおすすめ。
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:3, 興味深い)
それでも半年くらいがんがん運用してても全履歴ファイルがせいぜい数MBにしかならなかった。GBじゃなく。
今時のHDDのサイズならば、楽勝だってことですね。
テキストって軽いメディアなんだな、と今更ながら感心した次第。
これが有りがちなOffice系ソフトとかだったらと思うと…
＃Tikiの素朴(?)さが好きなのでG7。
＃あとSwikiも(自分で運用したことはないがユーザーとして見る範囲で)良い感じです。
閑話休題。
Re:Wiki。 (スコア:-1, 余計なもの)
軽くないと思いますよ。
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) (スコア:1, 参考になる)
以下のＷｅｂ頁で詳しい解説がありますです。
http://www1.sphere.ne.jp/smart/unix0308.html
http://www.not-enough.org/abe/manual/comm/about-unix.html
#それにしても、プロジェクト管理もＵＮＩＸ思想に基づいて行うことが出来ればいいのになぁ
Re:UNIXという考え方(Offtopic) (スコア:1, 参考になる)
実際の設計という話になると、途端に変というか自己矛盾というか、
つまり「これのどこが(優れた)部品化の実現形態なのだ？」とクビを傾げたくなります。
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のアーキテクチャは、部品化とフィルタ化を混同しているというか、
プロセスという仕組みが部品化の「フィルタ化以外の手法」を阻害してるというか、
処理モデルは面倒見るけど状態モデルは面倒見てくれないというか、
そういう面があります。
もうちょっと有名(笑)なリソースを示すなら、 UNIXの落とし穴 [namazu.org]でしょうか。
まあこれはちょっと瑣末な話題に終始してる節があるんですが、
Unixが良好な(=全員が従うことに同意してもおかしくないくらいの)メタアーキテクチャを
提供してない、することから逃避してる、のを暗に示しているのは確かです。
あと、同頁からもリンクされてますが、「Let's Make Unix Not Suck」
(和訳だと Unix をもう少しマシなものにしよう [os-omicron.org]とか)
も参考になります。Unix以外のやり方での部品化について、色々考えることは大事だと思います。
ここに書かれている「コードが再利用されない」ってのは、上記のように、
ある(決してレアケースと言えない)ケースにおいて、Unixは
部品化を「しにくい」アーキテクチャであるせいですね。
閑話休題。話を戻すと、
＞プロジェクト管理もＵＮＩＸ思想に基づいて行うことが出来ればいいのになぁ
そんなことしちゃったら、
1:プロジェクトの体制を変えようと思ったら、いちいちプロジェクト全体を終了解体しないとならない
2:親子関係は絶対であり、直接会話していいのは、直上の上司か直下の部下だけ
3:融通が利かなくて困るんで、結局部下が自分で勝手に全部の仕事をこなす場面が、存外多くなってしまう。
4:上司が辞めたら部下も連座で総辞職
という、使い物にならない管理形態になると想像されます(笑)
ネットワークモデル、しかも起動後の任意個所の着脱も自在、っていう部品化形態でないと21世紀的には駄目だと思う。
プログラム(OS)もプロジェクトも。
＃実行時にComponentの着脱なんて朝飯前なDelphi [nifty.ne.jp]で生活してたので、G7
Re:UNIXという考え方(Offtopic) (スコア:0)
とりあえず、
>1:プロジェクトの体制を変えようと思ったら、いちいちプロジェクト全体を終了解体しないとならない
>2:親子関係は絶対であり、直接会話していいのは、直上の上司か直下の部下だけ
>3:融通が利かなくて困るんで、結局部下が自分で勝手に全部の仕事
Re:UNIXという考え方(Offtopic) (スコア:0, 余計なもの)
ここはひとつ、Unixの不名誉(笑)のために、
「どうおかしいのかはっきり書けよ」と煽ってみるテスト(^^;
いや、思想はたしかに悪くないんですよ。思想のサワリの部分は。
でも、だとすると、それこそUnixの実装者が(笑)、その思想とやらを勘違いしてUnixを実装したのではないか？
と穿ちたくなるくらいに、Unixがやってる部品化のアーキテクチャは
限定的な代物(NetworkモデルでUnix Pipe流を再現することは出来るが、逆は無理。つまり表現力の多寡の問題)です。
つまり、控えめに言っても言動不一致ってことになる。