バックエンド

オープンソース：それはそれほど怖いことではありません！

以下は、の発売に先立って投稿されました女性開発者のためのApeeScape奨学金。

開発者として、テクノロジーの最新トレンドに遅れずについていくことは刺激的で挑戦的です。毎日、新しい言語、フレームワーク、デバイスが私たちの注目を集め、交流会、フォーラム、チャットでの会話に拍車をかけています。ただし、私たちの開発者コミュニティはツールではなく人で構成されており、その社会政治的側面を探求することは魅力的です（より良い言葉がないため、「ソーシャル」は最近ソーシャルネットワークに関連付けられる傾向があります）。

ApeeScapeでは、最近、女性がオープンソースにどれだけ貢献しているか、そして何が女性の貢献を妨げているのかについて、興味深い会話をしました。問題を調査した。 BreandenBeneschottとBozhidarBatsovとの会話に参加していたので、私は疑問に思いました。ボジダルはGitHubのトップオープンソース貢献者の1人です。ここはどこ？あなたが私の公衆をチェックするなら GitHubアカウント今日の時点で、それは主に私が生徒のためにクラスで使用した小さなテストプロジェクトです。彼らは中途半端で、間違いなく私のスキルや専門知識を代表するものではありません。（これについては私の言葉を信じる必要があります。）誰かがそのアカウントで見つけたものに基づいて私を雇うことを検討したとしたら、私は生計を立てるのに苦労すると思います。それでも、私は20年以上プロの開発者であり、日常の仕事では、覚えているよりも多くのオープンソースソフトウェアを使用しています。時間が経つにつれて、私はLinuxカーネルをハッキングして特定のニーズに合わせて曲げ、購入したすべてのルーターとNASを微調整し、RaspberryPiの待機リストで何ヶ月も辛抱強く待って手に入れました。自家製ドモティクス私はそれが好きです。それでも、これらの調整やテストのいずれも、オープンソースになるために私のGitHubに到達することはありませんでした。また、Tomcatの最初のバージョンの1つでバグを修正したことを除けば、私はオープンソースプロジェクトに貢献したことはありませんでした。好奇心が強いですね。

時間や興味が足りないと思うかもしれませんが、そうではないことはわかっています。私の個人的なプロジェクトに関しては、私がやったことに誰も本当に興味を持ってくれないと思っていたかもしれませんが、ほとんどの場合、誰もが見て後世のために私の作品をそこで公開するというアイデア自体が私をとても怖がらせます。また、GitHubから個人プロジェクトをいつでも破棄できますが、広く利用可能なオープンソースプロジェクトに貢献しようとすると、後戻りすることはありません。コードが十分でない場合はどうなりますか？問題を正しく理解していなかった場合はどうなりますか？プルリクエストが拒否された場合はどうなりますか？人々が私を荒らした場合はどうなりますか？

オープンソースに貢献することはあなたを怖がらせますか？

友人の開発者、ほとんどが女性との簡単な電話で、すぐに私だけがこの問題を抱えているわけではないことを確信しましたが、エンジニアにとっては問題はなく、解決策だけですよね？

オープンソースプロジェクトに貢献することで劇的な違いが生まれる可能性があるため、これは解決すべき重要な問題です。

あなたのキャリアの間に ：多くのクライアントあなたを雇うことを決定する前にあなたの社会的すべてを見ていきます。 GitHubアカウントとLinkedInの履歴書は、FacebookとTwitterのプロファイルとともにリストの一番上にあります。あなたはそれらを賢く使うべきです。
あなたの技術的なスキルのために ：他の開発者によって書かれたコードベース、そして多くの場合非常に優れたコードベースを調べることは、あなたに多くのことを教えてくれます。ひどく書かれたコードベースから意味を引き出す能力は、あなたに同じように挑戦し、教えます。
あなたのソフトスキルのために ：オープンソースソフトウェアは共同プロセスであり、そこにあるほとんどすべての興味深いプロジェクトはチームによって構築されています。誰もが使用するツールを介して他の開発者と協力し、チームに溶け込み、効率的にコミュニケーションすることを学ぶことは、熟練した開発者だけでなく、優れた開発者になるでしょう。
コミュニティのために ：オープンソースプロジェクトに貢献するすべてのビットが重要です。貢献すればするほど良いのですが、翻訳で小さなタイプミスを1つ修正するだけでも、最終製品は良くなります。
あなたのネットワークのために ：何百もの履歴書を企業に送ることができますが、個人的なつながりを持つ同僚がいるほどうまくいきません。オープンソースプロジェクトに積極的に参加することで、人々と出会い、尊敬を集めることができ、評判が高まります。これは、どの専門家にとってもかけがえのないものです。

これは、この恐怖と戦うための私の小さな個人的な旅です。この記事の公開は、旅そのものの一部です。ブログの投稿をブロックされている人や、少しでも投稿することを恐れている人が、最終的にはそれほど怖くないことを理解してくれることを願って書いています。また、オープンソースに貢献したいが、どこから始めればよいのかわからない人を支援することを目的としているので、基本から始めます。

オープンソースソフトウェアとは何ですか？どこにありますか？

オープンソースソフトウェア（略してOSS）は、そのソースコードとともにリリースされたソフトウェアであり、変更および再配布を可能にするライセンスが含まれています。ウェブサイト、メーリングリスト、フクロウなど、どこにでも配信できます。最も一般的なシナリオであり、私たちが関心を持っているシナリオは、コードベースがコラボレーションリポジトリで維持されている場合です。ここではGitHubに焦点を当てていますが、SourceForgeやBitbucketなどの他のオプションもあります。 GitHubは非常に使いやすく、膨大なユーザーベースを持ち、あらゆる種類のコードに使用でき、使用するあらゆる開発環境で使用できます。重要なことに、これは非オープンソースプロジェクトにも広く使用されています。次のクライアントプロジェクトはそこでホストされる可能性が高いので、それをどのように扱うかを知ること自体が有用なスキルです。

コーディング方法がわからない場合はどうなりますか？

これを読んでいるなら、コーディングの方法を学びたいと思うでしょう。あなたはいくつかの無料と有料のウェブサイトで素晴らしいコースを見つけることができます。学習する言語を1つ選択する必要があります。好みがない場合は、JavaScriptを使用してください。 Webブラウザーで開始するために必要なすべてのものがすでにあり、最も広く使用され、市場性のあるスキルの1つです。私の個人的なお気に入りはPythonです。これは、Web開発と科学アプリケーションの両方で使用されています。私も個人的に好きな初心者コースがありますが、 Udacityの「コンピュータサイエンス入門」。学びながらプロジェクトに取り組むハンズオンコースなので、気に入っています。また、Coursera、Khan Academy、PluralSightには他にもいくつかのコースがあります。

Gitがわからない場合はどうなりますか？

前に述べたように、知っている行く重要なので、Gitクラスを受講してください。しばらくGitを使用している場合でも、それを実行してください。実際にGitを研究するまで、Gitについてどれだけ知らないかわかりません。 rebaseが何であるかを自信を持って説明できない場合はそれを行ってくださいコマンドは行います。間違ったリベースがあなたを怖がらせなくても、それをしてください。私は完全に取った Gitパスコードスクールで、しかし再び、あなたはより多くのオプションのために他のサイトを探索することができます。

GitHubでプロジェクトを選択するにはどうすればよいですか？

日常の開発でOSSを使用している可能性があります。使い慣れたフレームワークを選択することは、良い出発点です。あなたはすでに機能とフレームワークの仕組みに精通しています。ソースコードに飛び込むと、より多くのことを学び、そのロジックをさらに明確に理解できるようになります。特に気に入ったテクノロジーやツールがある場合は、それについて言及しているプロジェクト、またはツールのプロジェクト自体を探してください。最後の手段として、GitHub Showcasesでプロジェクトを確認し、興味のあるカテゴリを選択することから始めることができます。

たとえば、GitHubの検索で「Raspberry」をすばやく検索すると、17,000を超えるリポジトリが表示されます。迷子になりやすいので、優れたコミュニティと優れた問題追跡システムを備えたプロジェクトを探してください。プロジェクトを選択するときは、次の数を確認してください。

寄稿者 ：10人を超える貢献者をターゲットにします。これにより、プロジェクトに十分な関心があり、単なる小さなチームの努力ではないことが保証されます。 OSSを初めて使用する場合、またはスキルがあまりない場合は、検索対象を最大50人の貢献者がいるプロジェクトに限定してください。より大きなコミュニティは、より大きなコードベースとより複雑なプロジェクトを意味します。
コミット ：少なくとも1,000のコミットがあり、最新のアクティビティが1週間以内のプロジェクトを探します。 1か月以上非アクティブになっているプロジェクトは、OSSの観点からは古くて古く、おそらくすぐに応答が得られないでしょう。毎日の活動は健全なプロジェクトのしるしです。
問題点 ：問題とは、未解決の問題、報告された、または実装する機能を要求されたバグです。それらはあなたに出発点を与え、プロジェクトへの関心の良い指標です。

また、プロジェクトの主要言語が何であるかを調べます。メインプロジェクトページのトップバーに言語統計が表示されます。議論のトーンを読んで、コメントがどれほど友好的で教育を受けているかを見てください。一部のプロジェクトは積極的なコミュニティで悪名高いため、適切な出発点ではない可能性があります。

私が選んだ ScyllaDB 、列指向データストレージプロジェクト。私はデータに興味を持っているので、パフォーマンスに関連するものなら何でも。私はそれを使ったことがありませんが、そのコードベースに飛び込むことができると期待しています。私が知っているツールを使用する方が簡単かもしれませんが、私はこれを挑戦と新しいことを学ぶ機会としてとらえています。残りの部分については、それは法案に完全に適合します。 18の寄稿者、6.5kのコミット（最新のものは執筆時点で23時間前）、178の未解決の問題があり、アクティブに見えます。

私は今何をしますか？

まず、リポジトリのクローンを作成し、ソフトウェアをマシンにインストールして、その可動部分のアイデアを取得します。次に、問題を読み始めます。準備ができたら、マシンで問題を再現できるかどうかを確認し、ソフトウェアの誤動作の原因の分析を開始します。

もう1つのアプローチは、自分で改善または変更できるものを見つけることです。たとえば、タイプミスやフォントのずれに気づいたかもしれません。私は小さなバグ、特にで使用されている間違った変数名を修正することを選択しましたスクリプトのドキュメント。

小さいように見えますが、間違ったドキュメントはドキュメントがないよりもはるかに悪いです。ユーザーはScyllaDBをインストールし、インストール手順を実行します。ユーザーはそのスクリプトに記述されている内容に盲目的に依存し、フラストレーションの山になってしまいます。これは私の能力にとって完璧であり、それを修正するには、プロセス全体をたどり、コードベースに少し慣れることが必要になります。バグ修正は退屈ですが、プロジェクトへの道を見つけるための素晴らしいスタートです。

フォークの作成

これは些細なことかもしれませんが、現時点では、ScyllaDBプロジェクトの場合、私は誰もいません。監督なしでコードに変更を加えることを許可するのは危険です。私がする必要があるのは、自分のGitHubアカウントに「フォーク」を作成することです。ここは私のScyllaDBフォーク。これは私がすべてのコードにアクセスできる自分の遊び場であり、必要に応じてファイルを変更できます。 ScyllaDBの独自のバージョンを作成し、それを微調整して元の目的とはまったく異なることを実行したい場合は、ここでそれを行うことができます。フォークの作成は簡単です。プロジェクトのメインページに移動し、[フォーク]ボタンをクリックします。まったく怖くない。

バグを修正する時間

次に、コンピューターでコードをテストし、必要な変更を加えます。まず、インストールしたことを確認してください Gitクライアントあなたのマシンで。次に、SSH公開鍵をGitHubに追加し、ssh-agentによって読み込まれていることを確認します。コードをローカルで取得するのは簡単です。 git cloneを使用するだけですメインブランチではなく、フォークを指すコマンド：

git clone [email protected] :acbellini/scylla.git

これで、メインブランチでプロジェクトをテストする必要があったので、コードをローカルでビルドして同じ方法でテストします。参照は相対的であるため、プロジェクトが依存している他のGitHubプロジェクトをフォークする必要があることに注意してください。私の場合、seastar、scylla-ami、scylla-swagger-uiをフォークする必要がありました。

修正する必要のあるバグは比較的単純です。 conf/scylla.yamlのドキュメント3つの構成可能なディレクトリについて言及します。1つはデータファイル用、1つはコミットログ用、もう1つは明らかに未使用で、キャッシュ用です。これらはすべて、デフォルトで$CASSANDRA_HOMEのサブディレクトリになります。

オープンソースコードに飛び込む

コードを詳しく見てみると、デフォルトが異なっていることがわかります。私が始めた問題＃372で述べたように、$CASSANDRA_HOME使用しないでください。いくつかの異なる設定でコードをテストし、構成ファイルから設定を削除し、使用されているディレクトリを確認することで、仮説を検証します。すべてが正しいことを十分に確信したら、変更したファイルを追加、コミット、およびプッシュできます。

git add conf/scylla.yaml git commit -m 'Correct default directories values in conf/scylla.yaml #372' git push

コミットメッセージの前にハッシュが付いた問題番号を導入したことに注意してください。これにより、GitHubにコードを問題自体に自動的にリンクするように指示されます。

注意すべきもう1つの重要な点は、コードを調査したときに、キャッシュ用の3番目のディレクトリが実際には使用されていないことに気付いたことです。一歩踏み込んでこの設定自体を削除したり、使用されていないコメントを追加したりするのは魅力的ですが、それは問題＃372の範囲外であり、これに厳密に関連しないものをコミットするのは誤りです。問題。変更を集中させ、目前のタスクに限定する必要があります。

この時点で、コードは修正され、GitHubのプライベートフォークにあります。ここで怖い部分が出てきます。ScyllaDBの人々に私のコードを受け入れるように頼むのです。これはプルリクエストと呼ばれます。

最後のステップ：プルリクエスト

GitHubのウェブインターフェースから直接プルリクエストを作成するのが好きです。コマンドラインから実行するよりも、直感的でエラーが発生しにくいと思います。プルリクエストを作成するために必要なのは、ブランチ名の横にある小さな緑色のボタンをクリックすることだけです。

GitHubでプルリクエストを作成する

コメントはGitHubによって自動的に計算されたことに注意してください。私のブランチには新しいコミットが1つありますが、フォークを作成してから、メインリポジトリにさらに14のコミットがあるので、左側の緑色のアイコンをクリックします。

プルリクエストを作成する前に変更を比較する

幸い、私の1つのコミットは他の14のコミットと競合しないので、GitHubは私に行ってもいいと通知します。他にコメントやメッセージを追加する必要はありません。コミットメッセージは非常に短いですが、すべてを示しています。コードの変更は何をし、何に関連しているのか。最後のボタンをクリックしてリクエストを確認していると、ほんの数日前にこんなに怖かったのは何だったのだろうか。今、私に向かって咆哮するモンスターはいないし、地獄の炎は燃えているようには見えない。正直、全然怖くありませんでした。万が一、間違えた場合、修正は受け入れられず、それだけになります。

あなたが今チェックするなら問題の詳細、GitHubがこの問題を参照するプルリクエストがあるというメモを自動的に追加したことがわかります。これは、コミットメッセージの＃372の魔法です。これは、他の人がすでに修正されたものを修正するために時間を無駄にすることを回避するのに役立ちます。

オープンソースはそれほど怖いものではありません

オープンソースはそれほど怖いものではありません。

最終メモ

プルリクエストが受け入れられるのを待っています。それが発生すると通知が届きます。これには数日、場合によっては数週間かかることを覚えておいてください。誰かが私のコードを確認し、説明どおりに機能することをテストし、問題を修正し、最終的に、コードの残りの部分の機能に悪影響を与えないことを確認する必要があります（読み取り：新しいバグを作成します）。これにはすべて時間がかかりますので、しばらくお待ちください。最終的に、プルリクエストが受け入れられると、ScyllaDBにはもう1人の貢献者がいて、問題は1つ少なくなり、最初のOSSの貢献があります。さあ、あなたも試してみる時が来ました。結局のところ、それはまったく怖くないです。