masskaneko
commented
2 years ago 見つかった Bugs を以下にまとめます。
迷わず簡単に直せそうなもの
- チャプター1. しかない。2 以降は？
- チャプター or 章
Venkatakrishnanは、この時 PayPal に導入したオープンソースプラクティスを次のように挙げています。なまえの後にスペース- 単体テスト :arrow_right: ユニットテスト
- 貢献:arrow_right:コントリビューション
- 英単語の後にスペースがないところがたくさんあるので、一括で直す
- ×プログラマ ○プログラマー 何箇所かあります。
## よりスピーディな開発プロセスこの段落は、人名がカタカナなので、英語に戻すオープンソースソフトウェアの協働的な開発プロセスを促進する GitHub のようなツールを熟知していることが重要です。読点がない期間が長く読みにくいと思いましたPayPal における様々な変化は同時に発生し→PayPalにおいては、様々な変化が同時に発生し、にすると読みやすいと思いました- （ → ( 半角
GitHub コラボレーション全角スペース- 全角語句と半角語句の間に半角スペースを入れ、視認性を向上させます。
多くの電子メールが飛び交いました。電子メールって平成な感じかもしれませんねｗ（って自分が訳したところなんですいません汗）「メール」だけでよさそうそして、コントリビューションは、チームが作成したコードの価値を高めていきました。、が多いかも？詳細については次の2点が参考になります Git for Teamsと Collaborating with Git video。最後に、「です」をつける。または、２つのリンク文字列の間の「と」をはずして文章でなくリンクの羅列にするかどちらか かなと。ダグ・シモンズによると、英語ですかねまた誰かがコードをプッシュすると、自動的にビルドが実行され、そのコードがマージされるのに十分な品質があるか確認されます。ここはプラクティスを列挙する文なので「確認されます」をプラクティスらしい文にしたいところ。コアチームは、より上手に各地域のコラボレーターたちと連携する方法を学べただけでなく、地域のコントリビューターたちへの指導を通じて、モジュール性と理解しやすさを高めるためにコアコードのどこをリファクタリングすればよいかのヒントを得るようになりました。長いので二文に分けてもいいと思いましたその後、レガシーな要素はC++が残りながらも、新規開発についてはJava Springを使って、レガシーな要素は→レガシーな要素として のほうが読みやすいと思いましたJava Spring「JavaのSpringというフレームワーク」のほうがわかりやすいかもしれないと思いました- 【元のマスターブランチに再マージするためのルールと、それを支援する技術があります。】→【元のマスターブランチにマージするためのルールと、それを支援する技術があります。】
- 【単一の組織における見地と制御の範囲内にとどまるという点では、インナーソースは従来のオープンソースとは異なります。】→【単一の組織における見地と制御の範囲内にとどまるという点で、インナーソースは従来のオープンソースとは異なります。】※”は”の削除
- 【これにより組織は部外者にコードが公開されることを恐れることなく、競争の源泉である企業秘密をコードに埋め込むことができ、同時に組織全体にわたる人々によって提供される多様な視点やクリエイティビティの恩恵を受けることができます。】→【これにより組織は、部外者にコードが公開されることを恐れることなく、競争の源泉である企業秘密をコードに埋め込むことができ、同時に組織全体にわたる人々によって提供される多様な視点やクリエイティビティの恩恵を受けることができます。】 ※”、”の追加
Harrell はソフトウェアスタックの上位に行けば行くほど、先頭のスペース削除（一括変換した時に入ってしまったのかと）PayPalがNode.jsを採用するという発表は、多くのプログラマ、特にC++からJavaへの移行が長くて大変だったことを記憶しているプログラマを心配させました。「多くのプログラマを、」のほうが自然かもしれないと思いました別の企業の調査では、新しいコントリビューションは自分のメンテナンスの手間を増やすことになると、プログラマーが心配していました。2, 32, 3 という無効なリンクがある(クロックフォード氏は、非常に人気の高い書籍 JavaScript: The Good Parts の著者であり、オライリーの JavaScript Master Classビデオ の制作者でもあります)。かっこの後に句点を置くのか、中に入れるのか現在、Paypalの新機能開発チームの大半はJavaを利用していますが、その一方で、Node.jsチームが開拓したインナーソースの点が多いですかねまたスタッフが自分自身の学習プロセスを継続できるよう準備するには、基本的に2日間のトレーニングで十分でした。「また」のあとに「、」を入れないと、againのほうの「また」の意味として、ぱっと読んだときにとれてしまって読みにくいと思いましたまた誰かがコードをプッシュすると、自動的にビルドが実行され、そのコードがマージされるのに十分な品質があるか確認されます。また の後に 「、」あってもいいですね。後半は、「十分な品質が保たれているかを確認します」とかの方が自然かと思いました。ある企業がモダンなコード開発において特殊な重要性を持つ地位を築いています。それはGitHubです。私の案：モダンなコード開発において、特殊な重要性を持つ地位を築き上げた企業があります。それは GitHub です。オープンソース開発とアジャイル開発の比較(“The Difference Between Geographically Dispersed Development and Agile Programming”)をここはイタリックにしても良い？これは PayPal が Node.js を採用したときに起こったことです。この文章が段落の初めにあるので、「これ」がさすのがこれまで話した「以上のこと」なのか、これから話す「以下のこと」なのかがわかりにくいと思いました単体テストに重点を置いていることも("継続的なテストと開発")、ここも、ダブルクオテーションは少し不自然…? 本書がどうなっているのかみてみたいです社内プロジェクト用のプライベートな GitHub リポジトリと、オープンソースのコード用のパブリックな GitHub リポジトリがあります。オープンソースのコード用のパブリックな...と、あるのですが一つ前の文からの流れを汲み取ると,,,「オープンソース用に、パブリックなGitHubリポジトリも用意していました」とかも良いかと思いました。信頼されたコミッタートラステッドコミッター- コア・インフラ・チーム → コアインフラチームの方が読みやすいかな
- 【単一の作業現場ではないようなより大きな環境においては、あまり上手くいきません。】→【単一の作業現場ではないより大きな環境においては、あまり上手くいきません。】
- 【特定のリリースで計画されている機能を拡張することの中には、期限を過ぎないように後回しにしなければならないものも含まれているかもしれません。】→【特定のリリースで計画されている機能を拡張すると、期限を過ぎないように後回しにしなければならない機能も含まれているかもしれません。】
Paypal二つ目のpが小文字でした- 企業名の統一 (正式名称で)
ベンカタクリシュナン氏
考慮、議論が必要そうなもの
インナーソースによるプロジェクトマネジメントの魅力○○による魅力という文章が少しもやもやします多くの企業のオブザーバーは、従業員が他チームにコードを提供する事への自信を与えることが、最も重要な文化的変化だと同意しているようです。これは、完全なドキュメンテーションと優れたメンタリングで達成できますが、“多くの企業のオブザーバーは” の表現がわかりにくいですねPayPal が InnerSource を採用するまでの過程には企業としての意志決定の積み重ねがあり「企業としての意思決定の積み重ね」が冗長で、「企業として」がなくても同様に伝わるのでは、とおもいましたスタッフの習慣を、バグに苦情を言うものから修正するものへ変えなければならないと指摘しています。少し口語的にしても良いかもしれません。ただ、その方が一般的に難しいと考えられています。一般的に→通常は のほうが読みやすいと思いました現代のプログラマは、変化が成長につながることを学びます。新しい技術やツールはさておき、文化を変えることで、機敏に行動し、最新のスキルを身につけ続けることができるのです。インナーソースは、これらすべての成果への第一歩です。ここは全文章の最後のしめなので、ポエムっぽくしめても良いかもしれません。このような非公式な情報共有により、ドキュメンテーションや正式な要件の必要性を減らすことができます。正式な要件の意味がわかりませんでした。前後を読んでも。コメントのやりとりは、投稿者にとっても他のプログラマーにとっても、見ながら学習ができる良い教材となります。「見ながら学習ができる」という言い回しは表現的にもっと良くできそうと思いました。「同時に学習できる・・」とか？PayPalのインナーソースは、米国外で働く地域セールスエンジニアから始まりました。一人のエンジニアなのか複数人なのかが気になりました（そのあとの文を読むと「彼らは」なので複数人？）Harrell によると、基本的な情報は社内のメーリングリストでシニアプログラマーに尋ねる代わりに、単に StackOverflow などのサイト (あるいは検索エンジンなど) で検索すれば良いということを Paypal のプログラマーに伝えるのに時間がかかったそうです。ここが Harrell さんの初登場時なのですが説明がありません。ほしいところ。- 英語の原文テキストもあった方が良いかも
その一方で、他のチームの開発者との間で飛び交う緊急のEメールのやり取りで、不十分なドキュメントをカバーしていました。「一方で」とはじまっているが、一方・他方感があまりない気がします技術的にチームがすべきことは、コードをパブリックリポジトリに移動して、社内メンバーからのバグレポートやコードコントリビューションに対して行ってきたことを、社外で行うだけです。すこし機械翻訳みがあるかもしれないです 日本語的には チームは〜〜〜技術的に〜〜〜をするだけでよく、また〜〜〜 といった感じでしょうか社内コードで見るような「部族内知識」から解放され、「部内知識」の方がしっくり来るなと- 「部族」という表現が少し差別的かもしれないと思いました
そのため、小さな変更であっても導入には数週間が必要で、新入社員には6週間のトレーニング期間が必要だったのです。「そのため」とつながっていますが、ぱっと読んでつながりを把握できなかったので追記が必要かもしれません- 【オープンソースでのソフトウェア開発がなぜここまで成功してきたのか】→【オープンソースでのソフトウェア開発がなぜ成功してきたのか】
- 【コードが元々に作られた目的以外の使用にも対応できます。】→【コーが元々に作られた目的以外のにも使用できます。】
- 【オープンソースとインナーソースでは、本番稼働中の障害からの保護のために、変更がチェックインされる際、テストが常に実行されます。】→【本番稼働中の障害からの保護のために、変更がチェックインされる際、テストが常に実行されます。】
多くの企業のオブザーバーは、従業員が他チームにコードを提供する事への自信を与えることが、最も重要な文化的変化だと同意しているようです。- 企業のオブザーバーとは何なのかわかりませんでした。従業員ではない？経営者？株主？
- 同意しているようです → 考えているようです or 納得しているようです の方が自然に思えます
ハレル氏によると、参加者はすぐに、自分たちが新しく、活気があり、エキサイティングな世界に入ったことを実感したといいます。機械翻訳みを感じました。主語と述語がつながっていない？そもそも主語が明確ではない？代替ツールの評価は、必然的にチームごとに採用するツールが異なるという多様性をもたらします... ライブラリを推奨する前にパイロットプロジェクトで試し、代替案をよく比較した上で選択することが求められます。...ここで「代替ツール」「代替案」とあるのですが、 alternative tools をもう少し普段使いそうな単語にできそうかなと思いました。ツール候補 とか。。？Harrell によると、基本的な情報は社内のメーリングリストでシニアプログラマーに尋ねる代わりに、単に StackOverflow などのサイト (あるいは検索エンジンなど) で検索すれば良いということを Paypal のプログラマーに伝えるのに時間がかかったそうです。長い＋機械翻訳みが強い？「Harrellいわく、」のほうが自然かもしれません`多くの企業はオープンソースの技術が単に高品質で無料であるということで魅力的を感じる一方、採用することでオープンソースコミュニティへの継続的な参入につながると考えています。「一方」という言葉の持つ対比感があまりない気がします。「採用することで」→「採用することは」のほうが自然かもしれません`またオープンソースプロジェクトにコントリビュートすることで、会社の知名度が上がり、コミュニティに対するコミットメントを示すことができます。コミットメントが日本語で通じるか怪しいこれは、完全なドキュメンテーションと優れたメンタリングで達成できますが、メンタリングは日本語でいうとなんだろう今では Node.js はかなり成熟した技術になっています。ピークを過ぎ、JavaScript プログラマーは代わりの技術を探していると指摘するコメンテーターもいるほどです。 (このセクションの後半で説明するように、オープンソース技術の変化のペースによって、採用するテクノロジーに関する意思決定が変わります)。しかし、PayPal が Node.js コミュニティに参入したのはコミュニティの初期段階でした。後半の「しかし」は、「ピークを過ぎ」から始まる文章の最後につくbutだったのかもしれないと思いました。「『今では』ピークを過ぎ、JavaScript プログラマーは代わりの技術を探していると指摘するコメンテーターもいるほど『ですが』」のほうが正しいかもしれません。- 商標の確認
- https://www.j-platpat.inpit.go.jp/
- https://www.microsoft.com/en-us/legal/intellectualproperty/trademarks
- Microsoft Windows ↓ Microsoft の Windows にしといてください。ダサいけど
yuhattor
8/9 の会議 でやった Bug Bash でたくさんの Bugs が見つかりました。内容は #jp-contents チャンネルのスレッド にあります。
まずはこの Issue に見つかったことを写し、議論することなく簡単に修正できるものと、そうでないものに分けます。 簡単に修正できるものは1つの Pull Request で一気に修正することを考えています。 議論が必要なものは個々の Issue に分けるかもしれません。
簡単に修正できるものが修正され、別の Issue に分けるものが決まったら、この Issue をクローズします。