発表は3/12(月)のお昼頃を予定しています。このレポジトリのissueを立てて発表します。
簡単な評価のポイントについても合わせて公開します。

みなさま、お疲れ様でした 😸

最低要件
GitHubのOAuthを用いたログインができる
/gists APIを用いた機能がある
gistの一覧表示ができる
gistを投稿できる

最低要件の gist の一覧表示ができる 。というのは、「自分のGistが一覧表示される」という認識であってますか？

ビルドができない場合は評価対象外とありますが、ツールにより生成されるファイルや依存関係など（iOSであればCocoaPodsによるPodsディレクトリやCarthageによるCarthageディレクトリなど）をプルリクエストに含める必要はありますか？
READMEやMakefile等にビルド手順を記載し審査の際に従ってもらうことは可能でしょうか。

関連して、自分のOAuthクライアントIDやクライアントシークレットをプルリクエストに含めたくない場合、審査の際に審査用のIDやシークレットを用いるなどの対応はありますか？

「コピペと思われるソースコード」というのはどのような基準、厳しさで判定されるのでしょうか？
例えば普段の開発からライブラリのように使っているユーティリティコード（ex. Swiftの便利extensionなど）を手でうつして組み込んだりすることや、設計やライブラリを使ったコーディングをするとき単純なためにサンプルコードと部分的に一致してしまうという場合もコピペと判断されてしまいますか？

git submoduleを使用すると、最上位ディレクトリ内に.gitmodulesができてしまうのですが、これは問題ないでしょうか？

#8 で既に質問されていることでまだ不明な点が出てきたので質問です。
#8 ではあくまでactivity/feeds APIを用い、認証済みユーザのpublic timelineを使用するとのことでしたが実際にAPIを叩いてみると公式ドキュメントの例でいえば

{
  "timeline_url": "https://github.com/timeline",
  "user_url": "https://github.com/{user}",
  "current_user_public_url": "https://github.com/defunkt",
  "_links": {
    "timeline": {
      "href": "https://github.com/timeline",
      "type": "application/atom+xml"
    },
    "user": {
      "href": "https://github.com/{user}",
      "type": "application/atom+xml"
    },
    "current_user_public": {
      "href": "https://github.com/defunkt",
      "type": "application/atom+xml"
    }
  }
}

というようなJSONが返ってきます。これは自分のGitHub APIやURLリクエストに対する認識不足・知識不足であれば申し訳ないのですが、ドキュメントで「認証済みユーザーのpublic timeline」とされている current_user_public_urlもしくは linksの中の current_user_publicは通常のユーザーページのURLのため、これにOAuthでとってきたアクセストークンをクエリーとして与えた https://github.com/defunkt?access_token=ACCESS_TOKENからデータをとってきてもユーザーページのHTMLしか返ってきません。そのためREADMEにあるようなタイムラインの形式に変換するのが非常に困難なように思われます。

この件に関して最低要件は

• HTMLを頑張って解析してページ下のContribution Activityの部分のデータをタイムラインっぽく加工する
• なんらかの方法でこのURLをxmlとして取ってくる
• global public timelineであればXMLで取得できるのでそちらを表示する
• OAuth認証でJSONとしてタイムラインが返ってくるactivity/events APIのList events that a user has receivedを利用する

のいずれの意味で解釈すればよいでしょうか？

現在webコースで開発をしているのですが、OAuth認証の2段階目のPOSTをscript(XMLHttpRequest)から実行するときにCORSに引っかかってしまいます。(テストはChromeで実行しています)

error message :
Failed to load https://github.com/login/oauth/access_token: No 'Access-Control-Allow-Origin' header is present on the requested resource. Origin 'http://localhost:4200' is therefore not allowed access.

(https://github.com/prose/gatekeeper に”GitHubのは、クライアント側のみのアプリケーションでのOAuthのWebアプリケーションフローを実装するのを防ぐことができます。”とありました)

(デバッグツールで見ると、POSTに対するResponseは帰ってきていてその中にはaccess_tokenも入っていました。しかしXMLHttpRequestはエラーになってしまいレスポンスを取得できていません。)

現在はHTMLだけを使ったformからPOSTすることでaccess_token(ファイル)のダウンロードをし、そのファイルに記載されているaccess_tokenを手動で入力しています。
しかし、評価するにしても、手動でファイルを開いて値を入力するのはどうなんだということで改善を考えました。

改善策としては、
①CORSにひっかからないブラウザ(Vivaldiとか)をしようする
②Gatekeeperを使用する(https://github.com/prose/gatekeeper)
③テスト用のサーバーも作成する
というものを模索しました。

しかし、①は実行環境が限られるので評価対象になるのかという疑問、②はそもそもの資料が少なく、もしかしたらサーバー側のプログラムかもしれないという疑問、③はvol.1のissueで「サーバーは必要ない」という回答がありサーバーは作らないほうが良いのかという疑問があります。

そのためwebコースでアプリケーションを作成する際は、HTMLフォームからファイルをダウンロードし手動で入力する、また、ChromeのF12デバッグツールでResponseを直接確認し手動入力するといった実装でも問題がないのか、それともwebコースはサーバーも構築したほうが良いのかお伺いしたく思っています。

ちなみに、access_tokenを用いて実行されるgist取得のAPIなどはクライアントサイドからの実行でも動作できています。

最優秀賞　🎉🎉

iOS

touyouさん(PR)

細かい作り込みが出来ていて、アプリ全体の完成度が高さが突出していました。
Clean ArchitectureをベースにしたReactiveなアーキテクチャの採用、その意図の解説があり素晴らしいです。
今回評価対象にしていませんが、デザインやUI/UXへの拘りも強みだと思います。

Android

itomeさん(PR)

統一されたアプリ設計によって実装がパターン化されていて拡張しやすいと感じました。（設計に合わせたページング処理など）
また、シンプルな実装の中にもUI/UXへのプラスαの部分が含まれているもの良かったです。

優秀賞　🎉

iOS

• akkyieさん(PR)

豊富なツールをしっかりと使いこなしてiOSに限らず開発の熟練を感じました。
機能は最小限なものの実装もしっかり出来ていて完成度が高いです。
全体のアーキテクチャから細かいところまで設計に趣向を凝らすことができれはより 👌

• tomoyamatsuyamaさん(PR)

機能実装は最小限でしたが、ReactiveやSwiftへの理解が十分あり、しっかり実装できていました。
コードの可読性も高く、流れを見やすい点も:ok_woman:

Android

• matsudamperさん(PR)

Kotlin CoroutinesやAAC ViewModelなどのモダンなライブラリやDatabindingなどをうまく使い、実装が良い意味でシンプルだと思いました。

• ShoMasegiさん(PR)

AAC ViewModelやLive Data等のモダンなライブラリを使い、極力Activity / Fragment内に処理を実装しないような作りになっているのが良いと感じました。また、UI/UXへのプラスαの部分が含まれているのも素敵でした！

拡張性、非冗長性を意識した設計の工夫があるとより良かったかもしれませんが、matsudamperさんもShoMasegiさんもよく実装できていました！　:ok_woman:

※ 賞の対象となった皆様、そうでない方含め、後日再度メールにてご連絡を差し上げます。

皆様お疲れ様でした！

Android

最優秀賞

Hunachi

App Bundle対応だったり、責務の切り分け、変更に対する修正箇所を抑えれる、といったマルチモジュール構成によるメリットを見据えた設計になっているところがまず良いと感じました。また、READMEに記載の設計や**がアプリ全体に反映されていて、新しい人が入ってきた際にも迷いが少なくスムーズに実装に入れそうな形になっていると思います。

iOS

最優秀賞

該当者なし

優秀賞

churabou

今回は以下の2点を評価させていただきました。

• レイヤーの責務分けや名前空間を意識した設計を採用することで結果的にスケールしやすい状態になっている
• こだわりを持ったUIの作り込みが出来ている

また、下記の2点を意識することで、よりクオリティの高い成果物になると思います。

• 設計に関して、ReactorKitとRxSwift+MVVMに挑戦している分、使い分けの一貫性がない形となってしまっていたため、どちらかの設計に統一する
• DIを意識したprotocolに関して、実際に利用する際の使い勝手も意識されたprotocolにする

完成度が高い成果物だったと思いますので、今後のさらなるご活躍も期待しております！

Web

最優秀賞

tockn

READMEに記載されている通りにVue.jsでMVVMなアーキテクチャが適切に実装できているのに加え、コンポーネントを独自のルールで役割を分けているのが分かりやすかったです。
またServerはGolangで認証解決を独自で簡潔に実現できていました。
レスポンシブなUIを実現した点も良かったです。

優秀賞

Dragon-taro

役割別にPresentational componentとContainer componentを分けている部分や、フォルダ構成が責務別にしっかりと分けられていたのが好印象でした。
ローディングアニメーションやドラフト機能等も実装しており、UXについても考えられているところが良かったです。

FlyBird-JP

モダンなブラウザで使われることを想定したESModulesベースの実装になっており、トランスパイルを必要としておらずそのままのものを配信する形が独創的で面白かったです。
またUI/UXの部分でページ遷移時のアニメーション等の細やかな作り込みに工夫が感じられました。

※ 賞の対象となった皆様、そうでない方含め、後日再度メールにてご連絡を差し上げます。

皆様お疲れ様でした！

最低要件の『activity/feeds APIを用いたフィードの一覧表示』は、以下のいずれかを一覧表示できれば満たすという捉え方で良いでしょうか？

• GitHub global public timeline
• 特定のユーザーのpublic timeline (特定ユーザーの更新情報)
• 認証済みユーザーのpublic timeline (認証済みユーザーの更新情報)

2つ質問があります。

1. ReactNativeは使っても良いでしょうか？

2. 評価観点1つ目の設計とは具体的に何を指すものでしょうか？

よろしくお願いします。

OAuth認証に用いるサーバも、自分で作成したものを使用するという事ですか？

• Android
• iOS