Free-programming-books: 出版年

作成日 2016年04月22日  ·  15コメント  ·  ソース: EbookFoundation/free-programming-books

誰かがすでにそれを提案したかどうかはわかりませんが、本のタイトルで近くに出版する年の署名についてどう思いますか?

discussion

最も参考になるコメント

年の追跡に関する問題の1つは、リポジトリ内の多くのリソースが定期的に更新されていることです。 リポジトリの目的のために、これはより多くのメンテナンス、情報を最新に保つためのより多くのPRを作成します。 @vhfが取り組んだようなサイドデータベースは、この情報を提供するためのより良い手段かもしれません。 git-tagでトリガーされるメタデータ更新スキームも機能する可能性があります。

そうは言っても、5年(〜10年?)より古いリソースに対してのみ発行年を追加することは有用であり、おそらくそれほど多くの作業ではありません。

全てのコメント15件

アイデアをありがとう。 長所と短所があります。

短所は長所を上回っていると思います。

  • 年は、本に含まれる情報の現在の価値の良い指標であるとは限りません
  • 多くの作業が必要になります
  • リストにすでに含まれている情報にオーバーヘッドを追加します

私はあなたが間違っていると思います。 私にとって、そして私にとってだけでなく、年は情報の現実の非常に良い指標であると確信しています。 2003年に出版された本と2015年に出版された本を見ると、より現代的な情報が含まれているため、2番目の本を選択する可能性が高くなります。

私はこのトピックについて議論することを歓迎します、私は他の意見を喜んで受けます。

年の追跡に関する問題の1つは、リポジトリ内の多くのリソースが定期的に更新されていることです。 リポジトリの目的のために、これはより多くのメンテナンス、情報を最新に保つためのより多くのPRを作成します。 @vhfが取り組んだようなサイドデータベースは、この情報を提供するためのより良い手段かもしれません。 git-tagでトリガーされるメタデータ更新スキームも機能する可能性があります。

そうは言っても、5年(〜10年?)より古いリソースに対してのみ発行年を追加することは有用であり、おそらくそれほど多くの作業ではありません。

私は@aminoughtに同意しますが、 @vhfにも良い点がありました。 その本を出版年までに測定するだけでは意味がありません。

多くの作業が必要になります。

次に、PRを介してコミュニティに任せます。 1冊の本であってもPRを提出するように勧めます。 個人的には、そのようなことは文字通り自由ではないと感じています。 それは時間がかかるか、ほとんどの場合になります。 彼らがリストにふさわしいと思ったので、それは戻り値です。

リストにすでに含まれている情報にオーバーヘッドを追加します

私はこれに同意しません、私たちは今情報が安いことを知っています。 高価なのは理解です。

私のポイント:もう1つの識別子を追加する価値があります。 確かにそれは消費者のニーズに合う識別子を与えるのに役立つからです:smile:。 これは、データベースにもう1つのオプションの列であるマザー名を追加するのと同じです。 現実は、すべての子供が母親の名前を知っているわけではないことを示しています。

これを決定するためのプログラム的な方法を考え出すことができれば、オプションになる可能性があります。 つまり、完璧である必要はありませんが、おそらく50%のケースを正確に自動化する方法があれば、それは良い出発点になるかもしれません。

@aminoughtそれがまさに@vhfが意味するポイントだと思います。おそらく、古い本の方が説明が優れているか、より良い例があります。 それは古いものですが、ソフトウェア言語の大部分にとって、物事を正しく行うためのいくつかの古い方法は、たとえそうでなくても、新しい本と比較して最悪であることを意味するわけではありません。

それでも、現在開発中の人にとっても、発行年を使用することは良い考えであることに同意します。

+1!

私自身学生として、新しいバージョンが必ずしも良いとは限らないので、古いバージョンを選ぶ傾向があります。
役に立つかもしれないコンテンツがいくつかありますが、作者がそう感じなかったため、新しいバージョンには存在しません。

また、そうです、それは多くの仕事を必要とします、しかしそれは人々が彼らの選んだ本を区別して見つけるのを助けると私は感じます。 @eshellmanによって提案されたアイデアが好きです。

私は初心者なので簡単に間違える可能性がありますが、 @eshellmanの途中ルートは完璧に機能します。 おそらく、本当に古い本やリソース(2005年以上、または2000年以上の範囲)の出版年を示して、知識を得るために純粋に現代的な本やリソースが欲しいかどうかを開発者が判断できるようにします。何年にもわたって処理されるか、上記の他の人が言ったように、現代の本にはない洞察を提供する可能性のあるレガシーの本に開かれています。

それは便利ですが、別の観点ではあまり役に立ちません。 リソースが公開された年を示すことは、その情報の観点からその信頼性を検証および推測する可能性がありますが、それでも、新しいエディションとそれ自体の反復で今日まで利用されている他の古いリソースがいくつかあります。

ただし、この状況では、ちょっとした追加になります。

さらにコメントがない限り、明日#2387をマージして、この問題を閉じます。

コメントありがとうございます、皆さん!

刑務所を出たばかりの人を知っています。 私は彼がお金を稼ぐためにJavaScriptを学ぶことができると言った。 彼が理解できる最新の無料の本を使うだけです。 彼は最新のものを簡単に選ぶことができないか、古い資料を学ぶことになるかもしれません。

彼女が彼らの言語を話すならば、仕事の面接官は人をよりよく評価するでしょう。 コンセプトは古いですが、言語は変わります。 より現代的な本はより現代的な言語を持っています。

私のような左から右の人の場合、左の太字のリンク可能な部分だけを読んでいるので、年はオーバーヘッドを追加しません。

本の一部に年がある場合に限り、私は大丈夫です。 それは望ましいことかもしれませんが、年とともに引っ張る義務はありません。

@ dzmitry-lahoda悲しいことに、私はWeb開発の経験があり、今日の開発者の仕事を得る最も簡単な方法のいくつかです。 とにかく、私は言わなければなりません、ウェブ開発はただ仕事をするだけではありません。 ほとんどの場合、JSを使用しますが、魔女自体は非常に深い言語であり、何かがそのように動作する理由を理解するのは困難です。 HTMLとCSS。 新しい本はより良いものを教えてくれると思うかもしれませんが、本当は、古い本はES6、Typescript、そしてこの新しいものを持っていなかったので、よりよく説明する可能性が高いです。 ES6 +でJSを学ぶ場合(Babelなどを使用して)、JSがどのように機能するかを理解することは、古いJSを学び、新しい構文を学ぶよりも難しいでしょう。知る。

これがあなたとあなたの友人に役立つことを願っています:D

このページは役に立ちましたか?
0 / 5 - 0 評価