Интерфейси и nil

Програмиране с Go

Курс във Факултета по Математика и Информатика към СУ

[Проект] Reviewer

  1. Здравейте,

    Идеята ми за проект е следната - платформа, чрез която да се стимулира по-бързото и ефективно code review на Pull Request-и в GitHub.

    Ще изредя някои от ключовите неща, които стремя да постигна:

    • Daily reporter for Pull Requests (configurable, може и да не е всеки ден)
    • Identify stale Pull Requests (among a set of repositories)
    • Enforce Pull Request Label Convention - ще ми трябва, за да мога да анализирам Pull Request-ите коректно (improves Open Source quality)
    • Notification System (regarding stale pull requests, when a pull request is reviewed and ready to be merged)
    • User Reputation System (Peer pressure driven system :D); Achievements?
    • Dashboard UI for each Reviewer installation - Wall of Shame, Merge button, Reference issue, Categorial views (Stale, Frozen, WIP, All)

    Като цяло си го представям като един Go Application, който ще играе ролята на сървър + допълнителен dashboard application. (не съм сигурен дали ще успея с dashboard-а).

    Сървърът периодично (примерно веднъж на час) ще вика GitHub api-тата, за да дърпа информацията и да я запазва в своя база. От своя страна сървъра ще предоставя API-та, които Dashboard application-а да вика. Нуждата от база и това, което може на пръв поглед да изглежда като double mainatanance на данните (въднъж в GitHub server-ите, и после в моя), се поражда поради следните причини:

    • GitHub има rate limit на броя заявки за определен период; това ще се окаже пречка, ако Dashboard-а винаги вика моя сървър, който пък всеки път трябва да прави заявки към GitHub
    • GitHub API-то предоставя много повече информация от нужната за мен

    Идеята за проекта ми се породи от личен опит, когато един екип работи върху множество GitHub repository-та и се случва периодично някои pull request-и, които са готови за review, да не биват разгледани, поради различни причини - натовареност на екип, нужда за пояснение преди да почне review на нещо или някакви други причини. Абе, хората просто забравят от време на време :D. Затова бих искал да направя нещо подобно, което да е постояннен reminder за екипа, че има нещо, което чака за review.

    Основните ползи от реализацията на такава платформа намирам в:

    • По-бързо придвижване на pull request-и;
    • Спазване на добри практики откъм Open Source гледна точка, като се label-ват Pull Request-и по единен и смислен начин;
    • Целия екип постоянно бива информиран за статуса на продукта, чрез ежедневни reminder-и до къде е работата - може всяка сутрин екипите да си отварят този Dashboard, примерно на Daily Standup Meeting-а, и да обсъждат какво трябва да се придвжижи, вместо да се ходи по всяко repository едно по едно.

    Основните пречки и предизвикателства, които виждам в реализацията на платформата е:

    • Messaging механизми - бих искал да се пращат мейли, slack известия или някакви подобни неща. Не съм имал много опит с програмирането на подобно нещо.
    • ORM или plain-vanilla database/sql с евентуално sqlx надграждане - още не съм сигурен кое би било по-подходящо
    • Dashboard-а - не съм много, много на ти с front-end-а
    • 100% ще има и други неща, които просто в момента не съм се сетил

    Някои ресурси и билиотеки, които мисля да използвам:

    Ще се радвам да получва обратна връзка и особено, ако имате съвети за някои от основните проблеми, които виждам. :)

  3. През изминалите дни обмислях промени по концепцията ми за автентикация и метода за намиране на хранилищата от интерес. Ще се опитам да опиша малко по-детайно всички възможности, които смятам да имплементирам.

    Проекта ще се състои от два компонента (два Go application-a):

    1. REST API server - ще предоставя API-та, чрез които клиент би могъл да получи ценна информация за статуса на конкретен Pull Request (или някакво множество). Информацията, която би могла да се извлича от тези API-ита е примерно дали един Pull Request е Work in Progress или пък кои са всички Pull Request-ите, които чакат Review в една организация или множество от хранилища. За да се придобие тази информация, REST API server-а ще извлича тази информация от GitHub API-та. Допълнително, този сървър ще си изгради собствен домейн модел спрямо предоставената информация от GitHub - целта е да може REST API сървъра да предоставя допълнителни услуги чрез API-та чрез агрегиране и анализиране на всички Pull Request-ите, които има на разположение - примерно, да се предоставя информация за всички Pull Request-и, за които някой е възложен да направи review.
    2. Dashboard application - ще представлява server, който ще сервира HTML страници. Това ще бъде графичния компонент, с който крайния потребител ще комуникира. Dashboard-а ще извиква предоставените API-та от REST API server-а, за да визуализира нужната информация.

    Горе накратко описах главните цели на двата компонента. Следват някои допълнителни функционалности, които се надявам да имплементирам:

    • REST API server-а да може да праща email/slack нотификация на конкретно конфигурани периоди за състоянието на Pull Request-и от интерес. Полезно за ситуации като примерно 5 мин преди Daily Standup Meeting, за да може да се разгледат от целия екип по-нагледно. Друг вид нотификации би могло да са такива за напомняне, че си възложен като reviewer на даден Pull Request.
    • Всичко ще е базирано на Label-и сложени по Pull Request-и. Затова мисля че ще е яко, ако успея да вдигна абстракцията едно ниво нагоре, като не се интересувам от конректни Label-и, като Work in Progress, или RequestReview, примерно, а реализирам така REST API server-а, че да може да се наблюдават Pull Request-и по всякакъв вид Label.
    • Сред едно от нещата, които силно бих искал да ми остане време е да имам някаква форма на User reputation system, с която в Dashboard-а да се виждат най-активните/неактивни потребители. Така с лек peer pressure да се стимулират review-тата. Репутация би се градяла на базата на брой review-та, оставени коментари и други критерии.

    Забележки:

    • Dashboard-а ще бъде GitHub application. Ще използвам OAuth Authorization Code grant flow, за да дам право на dashboard-a и за да си извлека token. От token-а ще мога да извлека някаква потребителска информация, за да персонализирам Dashboard-а, а след това за всяка заявка към REST API server-а ще пропагирам този token, за да може да се използва от REST API server-а, когато вика GitHub API-та (съответно token-ите ще ги верифицирам срещу GitHub-ския Authorization server).
    • Причината Dashboard-а да бъде сървърно приложение (да има Go backend), вместо да е прост Front-end application е, защото GitHub предоставя единствено authorization code grant flow, поне до колкото виждам. Това само по себе си изисква да имам сървър.
    • Обмислям използването на Web Hooks с цел постоянна и коректна синхрнизация между базата на REST API server-а, както и GitHub-ската база. Съответно ще слушам за определни събития, например смяна на Label на Pull Request, или Merge-ване на Pull Request.

    Следват сухи примерни мокъпи за това, което си представям за Dashboard-а:

Трябва да сте влезли в системата, за да може да отговаряте на теми.