アカウント名:
パスワード:
「ソースがドキュメントだ」、「仕様書？なにそれおいしいの」の世界だし。
同感。OpenVPNのように、一部ソースやライブラリは非公開、という例もあるし。
info はおろか、manさえ見たことがない奴なら簡単に言える台詞だ。これでも喰らえ。
$ w3m -dump /usr/share/doc/bash-doc/bash.html | wc -l6145
# はい。読めませんよ普通😫
あるんだ…そういやあるよな当然…感。ドザです。
# 物心ついた頃には ぐぐるあったもんなあ。に近い。ぐぐるの前はhh, winhlp32
w3m: Can't load /usr/share/doc/bash-doc/bash.html
ムムッ、読めない (>_<)
apt-get install bash-doc
読めない子は↑してね。
man bash で日本語版が表示される方は古いので注意。LC_ALL=C man bash で英語版が表示されるよ。
# 読めないこともないけど、ただ、対象読者の要求水準は高め。# 文量以上に、予備知識が多く必要なので、初読みでは、これも、それも、あれも補習という感じになる。Wikipediaがあるから、まあ、どうにかなるとは思う。ただ、コンパイラ（言語処理系）を作ってみようみたいな記事を読んだ経験無い人は、はじめのところ何を言っているのかわからないと思う。（実用的水準のものを作るのではなくて、言語処理の原理（仕組み）を理解していないとね。）もっとも、bashは、そこらの言語と基本設計が違うから、ふつうの言語の知識が通用しないわけだが・・・。
オープンソースだと物によっては仕様書があるのでは。企業が開発を主導してるようなのは特に。あとはやる気がある人が頑張ってるのとか。まあやる気がある人ってのは特定の分野のマニアだったりするのでひたすらプリンタ関連のを書いてたりどマイナーなプロセッサ向けのマイクロコード修正を細々書いてたりするけど。何はともあれ十分な手があればドキュメント不足は起きない。ドキュメントに従った開発がされるかは別。
ご丁寧にGithubに上げる時にコメント全部消してたりとかね……（もしかしたら最初から一切書いてないのかもしれないが）
オープンソースなら一般的に多数の人間の査読が入るので、読みにくければ修正を迫られるか、もしくは勝手にforkして読みやすく修正されるので、仕様書がなくてもなんとかなるんです。
それに対して企業内などで開発される(クローズドな)ソースコードの場合、少数または1人のセンスのみで作られることが多く、本人にしかわからないことが多数残るばかりか、「きちんと動いているんだから修正するな」の意識が大きく、読みやすく直せない場合が多々あります。こういう場合は別途仕様書を起こす必要があります。
>「ソースがドキュメントだ」、「仕様書？なにそれおいしいの」の世界だし。
こんなん、プロジェクトそれぞれによって違うとしか言いようがない。ドキュメントを整備しているところもあれば、無いところもある、あっても古いところもある。どちらかというと、ドキュメントだらけだと思う。
先年のみずほの誤廃棄のように、オープンソースどうこう関係なく、「人間」ってこういうもん（開き直り、逆切れ、物臭）って感じだと思うけど。
より多くのコメントがこの議論にあるかもしれませんが、JavaScriptが有効ではない環境を使用している場合、クラシックなコメントシステム(D1)に設定を変更する必要があります。
アレゲは一日にしてならず -- アレゲ研究家
でも、オープンソースってそんなもんじゃね？ (スコア:1)
「ソースがドキュメントだ」、「仕様書？なにそれおいしいの」の世界だし。
Re: (スコア:0)
同感。
OpenVPNのように、一部ソースやライブラリは非公開、という例もあるし。
Re: (スコア:0)
info はおろか、manさえ見たことがない奴なら簡単に言える台詞だ。
これでも喰らえ。
$ w3m -dump /usr/share/doc/bash-doc/bash.html | wc -l
6145
# はい。読めませんよ普通😫
Re: (スコア:0)
あるんだ…そういやあるよな当然…感。ドザです。
# 物心ついた頃には ぐぐるあったもんなあ。に近い。ぐぐるの前はhh, winhlp32
Re: (スコア:0)
w3m: Can't load /usr/share/doc/bash-doc/bash.html
ムムッ、読めない (>_<)
apt-get install bash-doc
読めない子は↑してね。
man bash で日本語版が表示される方は古いので注意。
LC_ALL=C man bash で英語版が表示されるよ。
# 読めないこともないけど、ただ、対象読者の要求水準は高め。
# 文量以上に、予備知識が多く必要なので、初読みでは、これも、それも、あれも補習という感じになる。Wikipediaがあるから、まあ、どうにかなるとは思う。ただ、コンパイラ（言語処理系）を作ってみようみたいな記事を読んだ経験無い人は、はじめのところ何を言っているのかわからないと思う。（実用的水準のものを作るのではなくて、言語処理の原理（仕組み）を理解していないとね。）もっとも、bashは、そこらの言語と基本設計が違うから、ふつうの言語の知識が通用しないわけだが・・・。
Re: (スコア:0)
オープンソースだと物によっては仕様書があるのでは。
企業が開発を主導してるようなのは特に。
あとはやる気がある人が頑張ってるのとか。まあやる気がある人ってのは特定の分野のマニアだったりするのでひたすらプリンタ関連のを書いてたりどマイナーなプロセッサ向けのマイクロコード修正を細々書いてたりするけど。
何はともあれ十分な手があればドキュメント不足は起きない。ドキュメントに従った開発がされるかは別。
Re: (スコア:0)
ご丁寧にGithubに上げる時にコメント全部消してたりとかね……
（もしかしたら最初から一切書いてないのかもしれないが）
Re: (スコア:0)
オープンソースなら一般的に多数の人間の査読が入るので、読みにくければ修正を迫られるか、
もしくは勝手にforkして読みやすく修正されるので、仕様書がなくてもなんとかなるんです。
それに対して企業内などで開発される(クローズドな)ソースコードの場合、
少数または1人のセンスのみで作られることが多く、本人にしかわからないことが多数残るばかりか、
「きちんと動いているんだから修正するな」の意識が大きく、読みやすく直せない場合が多々あります。
こういう場合は別途仕様書を起こす必要があります。
Re: (スコア:0)
>「ソースがドキュメントだ」、「仕様書？なにそれおいしいの」の世界だし。
こんなん、プロジェクトそれぞれによって違うとしか言いようがない。
ドキュメントを整備しているところもあれば、無いところもある、あっても古いところもある。
どちらかというと、ドキュメントだらけだと思う。
先年のみずほの誤廃棄のように、オープンソースどうこう関係なく、「人間」ってこういうもん（開き直り、逆切れ、物臭）って感じだと思うけど。