良いgraph-libはありますか？ 私の意見では、これはサーバー側でレンダリングおよびキャッシュできます

何か進展はありますか？

持っているといいでしょう🎉

まだ誰もいない場合は、この機能の作業を開始したいと思います（ええ、 @ lafriks 、私は私のレッスンを学びました、 +1は建設的ではありません😉）。

サーバー側またはクライアント側のレンダリングを決定する方法、使用するチャートライブラリなど、ときどき支援が必要になる可能性があります。
私も基本的にGoを知りませんが、フロントエンドの知識が豊富なので、うまくいくはずです。すべてが初めてです。また、少し前にGiteaのハッキングに飛び込みたかったのです😄

まず、既存のソリューションを分解して、必要なデータと可能なデータ構造を特定しましょう。

GitHub

コントリビューションデータのAPIエンドポイントはhttps://github.com/<owner>/<repo>/graphs/contributors-dataです。

返されるJSONデータは、基本的にオブジェクトのリスト（それぞれが1人の寄稿者を表す）であり、最も少ない寄稿を最初にソートし、最も多くの寄稿を最後にソートします。

[
  { ... }, // User with least contributions
    ...
  { ... }, // User with second most contributions
  { ... }  // User with most contributions
]

構造はここに記載されているものとほぼ同じで、次のようになります。

{
  "author": {
    "id": 12345,
    "login": "octocat",
    "avatar": "https://avatars3.githubusercontent.com/u/12345?s=60&v=4",
    "path": "/octocat",
    "hovercard_url": "/hovercards?user_id=12345"
  },
  "total": 123,
  "weeks": [
    // First week in which the repo existed
    {
      "w": 1391904000,
      "a": 6898,
      "d": 77,
      "c": 10
    },
    // Second week in which the repo existed
    {
      "w": 1392508800,
      "a": 2437,
      "d": 439,
      "c": 6
    },
    ...
    // Current week
    {
      "w": 1538265600,
      "a": 0,
      "d": 0,
      "c": 0
    }
  ]
}

"weeks"配列の各メンバーは、次の属性を持って構成されています。

• w -週の始まり。Unixタイムスタンプとして指定されます。
• a -追加の数
• d -削除の数
• c -コミット数

そのすべての情報は、これらのカードを作成するために使用されます。

大きな貢献度のグラフは、1週間の各ユーザーからの統計n （ 0 <= n <= weeks since the repo exists ）を合計し、各週の累積値をプロットすることで明らかに作成できます。

GitLab

GitLab CEはオープンソースであるため、関連するファイルがあります。

• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/controllers/projects/graphs_controller.rb
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/lib/gitlab/graphs/commits.rb
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/views/projects/graphs/show.html.haml
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/stylesheets/pages/graph.scss
• https://gitlab.com/gitlab-org/gitlab-ce/blob/master/app/assets/javascripts/vue_shared/components/bar_chart.vue

APIエンドポイントはhttps://gitlab.com/<owner>/<repo>/graphs/master?format=jsonです。

返されるJSONデータははるかに単純です。

[
  { ... }, // Latest commit
  { ... }, // Second latest commit
    ...
  { ... }, // First commit
]

配列の各メンバーは1つのコミットを表し、最初に最新のコミット、最後に最初のコミットをソートします。 構造は次のようになります。

{
  "author_name": "Some User",
  "author_email": "[email protected]",
  "date": "2018-10-02"
}

ユーザーが同じ日に複数のコミットを行った場合、コミットごとに1つずつ、同じユーザー情報と日付を持つ重複したエントリが存在するだけです。

ユーザーごとのタイルには、GitHubよりも少ない情報が含まれます。プロットは、1日のコミット数、X軸は時間、Y軸はコミット数を取得することによって行われます。 これは、リポジトリ全体（ユーザー名を無視）と各ユーザー（特定の日に特定のユーザーのすべてのコミットエントリを取得する）の両方に対して行われます。

どちらの場合も、レンダリングはクライアント側で実行されます。これには、ズームを使用して動的なグラフを作成できるという大きな利点があります。

ここでの一般的なワークフローで機能する場合は、この問題に割り当てられても問題ありません。

これについてもう少し考えます。 もちろん建設的なフィードバックは大歓迎です！

UIにページリンクを配置する

それはうまくいくはずです、今のところ何も再構築する必要はありません。

リンクについて言えば、ページはおそらくhttps://git.example.com/<owner>/<repo>/contributorsにあるはずです。これが、そこにある他のすべてのリンクが機能する方法です。

私が好まないもう1つのアイデアは、[アクティビティ]ページに投稿者グラフを配置することです。

私はいくつかのDOM編集を行いました：

アイコンとしてocticon-organizationを選択しましたが、 octicon-graphも機能する可能性があります。

ここで、GiteaのGitHubコントリビューターチャートでCSSをすばやく編集し、画像をマージします。

これは、個々のユーザーごとのグラフを考慮に入れずに、どのように見えるかについての非常に大まかな考えです。

素晴らしく見えます^-^

@linusg素晴らしい！ どうぞ！

@lunny私は今ちょっと混乱しています： @Morlinestは誰ですか、そして彼はこの問題でどのような役割を果たしますか？

それはおそらく間違いであるか、おそらく彼は私と一緒にいくつかの秘密の計画を持っています：D

@linusg @Morlinest :(申し訳ありません。 @ Morlinestが言ったような間違いです。この問題を@linusgに割り当てたいのですが、非メンテナと問題のポスターに割り当てることができないことがわかりました。

わかりました、説明してくれてありがとう：smile：

ああ、だから私は今それをしなければならないでしょう：D

興味のある方への短い注意事項：私はクリスマス休暇中にこれに取り組みたかったのですが、多くの時間を見つけることができませんでした。 基本的なもの（ページ、ルーティングなど）を作成し、引き続き作業する予定です。

どうもありがとう^-^

皆さん、さらに別のアップデートです。 私はそれをこの状態にするために管理しました：

クリックして展開：

！[画像]（https://user-images.githubusercontent.com/19366641/50791201-6f7d9500-12c1-11e9-9a3d-7612c63e6b4a.png）！[画像]（https://user-images.githubusercontent.com/ 19366641 / 50791210-7c9a8400-12c1-11e9-985c-b0dffcbfae3a.png）

！[画像]（https://user-images.githubusercontent.com/19366641/50791412-0cd8c900-12c2-11e9-86e7-5fb4142a5bcc.png）

詳細：

• HTTP APIを介して公開されるデータはなく、グラフはサーバー上のSVGにレンダリングされます（https://github.com/wcharczuk/go-chartを使用）。 これは本当にパフォーマンスが高く、物事をシンプルに保ちます。
• コミット、追加、削除の数による並べ替え
• UIはGitHubに「わずかに」基づいています😄

残っている問題：

• gitea DBにない（リポジトリがインポートされたなどの理由で）コントリビューターは表示されません。 ✅
• より大きなリポジトリでのパフォーマンスの問題。 私がgolangn00bであるだけかもしれません。
• X軸からのAM / PMのものの削除（カスタムフォーマッターを介して簡単に実行できます） ✅
• ユーザーグラフのY軸スケールを修正します。1つのコミットは2つのコミットの半分の高さにする必要があります✅
• 適切なダークテーマのサポート（上記のCSSは開発ツールで調整されました） ✅

可能な機能強化：

• 統計はマスターブランチ（ハードコードされている）用であり、これは簡単に変更してUIコントロールとして公開できます

変更や改善のアイデアを歓迎します-私はこれまでのところ終了しています！ ：smile：しかし、今後のコードレビューを恐れています。

すっごく...ここに行きます！ 今度は外部入力の時間ですので、下の画像をご覧ください。

（GitHubから取得したgiteaレポ）

説明させてください：

• giteaユーザーDBに含まれていないユーザーが表示されますが、プロファイルへのリンクはありません。 統計はユーザー名によって計算されます（各コミットごとに「名前」と「メール」のみが使用可能です）。そのため、GitHubには「不明」、「Unknwon」、「ú闻」がありますが、GitHubには「Unknwon」のみがあります。リポジトリのクローンを作成/インポートすると、同じユーザーがすべて失われます。 私はそれが利用可能な最良の選択肢だと思いますか？

• GitHubは週ごとに統計をコンパイルしますが、私は毎日の統計を使用しました。 これを変更する必要がありますか？

  これが、GitHubのY軸が約150 [1週間あたりのコミット数]で終了し、GiteaのY軸が52 [1日あたりのコミット数]で終了する理由です。 また、Giteaのチャートがより多くの「スパイク」で表示されるようになります。 （補間も利用できません）

• GitHubはマージコミットを統計から除外します。私はこの種のものを実装しませんでした（そして、通常のコミットと区別するのがどれほど難しいかわかりません）。 この機能が必要ですか？

• ユーザーごとのグラフに別の色を使用しますか？

• 他に何を改善できると思いますか？

パフォーマンス：

前回の投稿で指摘したすべての問題を修正し、パフォーマンスの問題に戻りました。 私の開発マシンからのすべての統計：

Giteaブログリポジトリの寄稿者ページの読み込みには1.1秒かかりますが、これはおそらく問題ありません（_ページ：1090msテンプレート：7ms_）

giteaメインレポ用のものは1分14秒かかり、_ページ：74443msテンプレート：47ms_を報告します。 ただし、9年の歴史があり、約7kのコミットがあります。

考えられる改善点：gitearepoの寄稿者ページは最終的に602のユーザーカードになります。GitHubは100でカットオフすると思います。https：//github.com/go-gitea/gitea/graphs/contributorsを参照してください。

あれについてどう思う？

ページにアクセスするたびにコミット履歴全体がトラバースされるため、統計をキャッシュすることで状況を改善することもできます。 それが理にかなっていて、実装がどのように見えるかについての手がかりはありません。

変更されたCSSファイルを表示するには、ServiceWorkerのキャッシュをクリアする必要がありました（通常のキャッシュの更新は機能しません）。 OOTBで動作するように、ここで何をする必要がありますか？

！[画像]（https://user-images.githubusercontent.com/19366641/50845620-95f90a00-136d-11e9-94a1-dfcdbdcf8908.png）！[画像]（https://user-images.githubusercontent.com/ 19366641 / 50845863-28011280-136e-11e9-8a93-a194dde3115c.png）！[画像]（https://user-images.githubusercontent.com/19366641/50846330-2be16480-136f-11e9-8aad-e814157d045f.png）！ [画像]（https://user-images.githubusercontent.com/19366641/50846507-9b575400-136f-11e9-9a6f-97f7a9ec28a1.png）

@linusgお疲れ様でした!!! リポジトリが大きい場合（つまり、1000を超えるコミット）にcronジョブとして機能させるのはどうですか？ 構成に応じて、1日以上実行できます。 トップ100で十分だと思います。そうでない場合は、ページ付けの方が適しています。

@linusg

• 統計はマスターブランチ（ハードコードされている）用であり、これは簡単に変更してUIコントロールとして公開できます

別のオプションを作成する代わりに、デフォルトのブランチオプションを使用できるかもしれません。

この問題は、最近のアクティビティがないため、自動的に古いものとしてマークされています。 今後2週間以内にそれ以上の活動が発生しなければ、閉鎖されます。 貢献していただきありがとうございます。

いいえ、まだこれに取り組んでいます-誰かがstaleラベルを削除する可能性があります！

いいえ、まだこれに取り組んでいます

この機能が間もなく登場することを期待して、これは朗報です。
どこでもチャートやグラフィックデータ表現を見るために誇大宣伝...

この機能が間もなく登場することを期待して、これは朗報です。

すぐに：tm：

時間は間違いなく私にとって問題です...私の基本的に存在しないgolangの知識の次に、ハハ。

私はすべての興奮を見てうれしいです（私も興奮しています、そうでなければこれに取り組むことはありません！）、しかしあなたがこれが十分に速く進歩していないと感じたら（くそー、それは半年以上経っています）、私はすべての変更でPRを行うことができ、他の誰かが手伝うことができますか？

すぐに™️

😅

しかし、皆さんがこれが十分な速さで進歩していないと感じた場合

Naaah ..機能が非常に優れていて機能している場合、機能にかかる時間を気にする人はいますか？

私はすべての変更でPRを行うことができ、他の誰かが手伝うことができますか？

IDK、多分あなたはここGHにあなたのレポを公に投稿することができます。そうすれば他の人があなたのレポをPRしてそれを機能させることができます。
または、公式リポジトリで新しいブランチのPRを開くことができます。そこから、熟練した時間のある人々がフォークして作業し、代わりにブランチがマスターにマージされるのを待つPRを行うことができます...

@linusgあなたが不在のときに誰かがあなたを助けるかもしれないPRを送ってください。

この機能を楽しみにしています。 今は古くなっていますか？ .....ありがとう

ここにさらにニュースはありますか？

PRや支店がここに提出されたことはありますか？

私はそうは思わない。 @linusg

自分の変更をプッシュしたことはないと思います。 私がまだそれらを持っているかどうかさえわかりません-ごめんなさい！