アカウント名:
パスワード:
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
犯人はmoriwaka -- Anonymous Coward
Wiki。 (スコア:4, 興味深い)
それはテキストベースで管理するとして。とりあえずPukiWiki [pukiwiki.org]がおすすめ。
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:3, 興味深い)
それでも半年くらいがんがん運用してても全履歴ファイルがせいぜい数MBにしかならなかった。GBじゃなく。
今時のHDDのサイズならば、楽勝だってことですね。
テキストって軽いメディアなんだな、と今更ながら感心した次第。
これが有りがちなOffice系ソフトとかだったらと思うと…
＃Tikiの素朴(?)さが好きなのでG7。
＃あとSwikiも(自分で運用したことはないがユーザーとして見る範囲で)良い感じです。
閑話休題。
Wikiを「いろんな」用途に使うのは、とても簡単です。
あの手のソフトの味噌は、それがフリー(?)フォーマットであるという点。
それゆえに「何にでも」使えるんです。使い手のセンス次第で。
ごついツールを導入しても、その「縛り」のきつさに後で苦しむ(しかも後からじゃ止められない罠)可能性も
ないわけじゃないので、「白紙」を自分らの裁量で使うという選択肢も、一応考慮しておくと幸せになるかもです。
Re:Wiki。 (スコア:1)
文字列はどうする気なんだろう？
> 当時は「なんでUNIXとかって効率悪いtextでデータ持ってるの？」とか嘲笑してました。
とりあえず、
この辺 [amazon.co.jp]を読んでもらうしかないかな。
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流を再現することは出来るが、逆は無理。つまり表現力の多寡の問題)です。
つまり、控えめに言っても言動不一致ってことになる。
Re:Wiki。 (スコア:1)
決め打ちの出来る DOS では気にする必要がないのですが。
例えばネットワークの先にある他ホストは 1byte=8bit で無いかもしれない、となるとデータを共通化して実装でどうにかする上でテキストベースも頷けるのではないかと。
コンシューマゲーム機ではさらにメモリ不足の問題があるので、やはりバイナリが向いていますね。
office 系のデータファイルが重い理由は、履歴や高速保存による無最適化などがあると思います。
AC さんの話は当然最適化された上での話なので、バイナリといってもそれが意味するものが異なるのではないでしょうか。
Re:Wiki。 (スコア:1)
最初からコンテンツそのものがテキストならば問題ないわけですよね。
だからテキストという「メディア」は軽いわけです。
あと、そうでない場合にしても「("0xFFFF"と0xffffの比較でいえば)たかが3倍」でしかない、とも言えます。
例えば今自分が持ってるPCのHDDを、自分が書いたり読んだりする文章の生テキスト相当分だけで
埋めることを考えてみてください。はっきり言って一生かかっても無理じゃないかとビビって(笑)います俺。
じゃあなんでHDDとかはこんなに大きくなってしまったんでしょう？
少なくとも「テキストのせい」でないのは確かだと思います。テキスト用なら容量足りてるんですから。
もっと他のもののために、リソースの大部分は食われてるわけです。
あっちのデータたちは、3倍とかいう穏やかな話とは程遠い凄まじさで膨れてしまっているわけで。
逆にいえば3倍程度ですから、随分古い計算機でもテキストな環境はすいすい使ってました。
そういや98note初代でもsedやawkしてたっけ俺。
勿論それなりに遅いんですが、その遅さは、MS Word XPを98note初代で動かす
(そんなことが仮に可能だったとしてCPUパワー換算で)ことの遅さの比じゃないだろうと思います。
＃そういや当時、いちいちtextを経由して動くようなMIDIファイルいじりソフトを作ったことがあるんでG7
＃それこそtextだから遅いのを覚悟したんだけど、動かしたら自分でびっくりするほど速かったんで、「そういう問題じゃない」のを悟った次第。
>だからＰＣ－９８時代にはデータをbinで持つのは普通でしたね。
おかげで、当時のデータを今活用できなくて困り果てることがしばしば有ります(T_T)
>割と最近でも３Ｄのデータをtextで持ってたり。
3Dといえば、川合さんが「ＯＯエンジニアの輪」に出ています。
http://www.ogis-ri.co.jp/otc/hiroba/others/OORing/interview21.html
http://www.shiro.dreamhost.com/scheme/wiliki/wiliki.cgi?Lisp%3aGeometry&l=jp
text云々という話とはちょっと離れますが、無縁というわけでもないと思うんで、URLを示します。
ええ。柔軟性は武器です。
>メモリいっぱいあるし、とか、
>やっぱＧＵＩって便利だよね、とか、
>ＳＴＬって楽だよね、とか、
>そんなこんなの積み重ねで486@30MHz-->Pen4@3GHzになっても
>あいかわらず「重いよ～」って言ってるんだと思います。
あのー。GUIは色々な意味で非テキスト的であり、それどころかバイナリ(笑)的なんですけども…
＃俺としては、STLみたいなコンパイル時処理よりも、実行時処理のほうが旨みが多いと思うんで、まあ。
＃ゲームや組み込みに限って言えばアレですが。
テキストが「一番軽い」ものじゃないのは確かです。
が、テキストよりももっと重いタチの悪いメディアは色々あり、しかも実際我々の身辺に蔓延っている、
ということなんだと思います。
＃さっきも書いたけど、Unixの悪い点は、textだからじゃなく、そのtextの使い方がお洒落じゃない点、だと思う。
Re:Wiki。 (スコア:1)
PC8001上の CP/M 80 で sed や awk をパイプでつないで使っていました。
信ずる者は掬われる。
Re:Wiki。 (スコア:1)
うーん、コンパイル時処理って例えば何を指しています?
Re:Wiki。 (スコア:1)
あう。テンプレートそのものの事を言いたかったらしいです俺。
STLは単にその上に載るものの1つだわな。
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:0)
>軽くないと思いますよ。
ここで言うテキストとは「バイナリとの比較におけるテキスト」のことではなくて、「Wordみたいに付加情報がいっぱいくっついた文書ではなく、文字情報だけのプレーンな文書」を意図しているものと思われ。
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:0)
Re:Wiki。 (スコア:0)