Стендап Сьогодні 📢 Канал в Telegram @stendap_sogodni

🤖🚫 AI-free content. This post is 100% written by a human, as is everything on my blog. Enjoy!

Пости з тегом #GitHub

22.01.2023

Почав роботу над додатком для швидкого перегляду повідомлень GitHub

В мене робочий день починається з перегляду всіх нових повідомлень GitHub. Таких повідомлень за день накопичується від 25 до 50, тому на весь перегляд уходить до години. З набутою після відпустки ясністю помітив, що велика частка цього часу уходить на навігацію — бо кожний перехід з переліку повідомлень на сторінку пул-реквесту робить повне перезавантаження SPA. При чому частина повідомлень не потребують уваги — наприклад, коли автор зливає PR після того, як я його схвалив. Але все одно доводиться заходити та переглядати, чи не змінилось там що.

Все це можна вирішити з кращим інтерфейсом для списку повідомлень. Моя головна вимога — щоб можна було швидко побачити, що саме змінилося в кожному ПРі після мого останнього перегляду — а потім також швидко прийняти дії. На жаль, нічого подібного не знайшов — хоча буду радий рекомендаціям. Тому вирішив зробити сам.

Поки зміг забрати по API список повідомлень. Концептуальна модель тут заплутана, але головне, що API повертає посилання на відповідний ПР, а також дату останнього перегляду. Тепер треба отримати список подій з ПРу, та обрізати його по даті. Також є API для того, щоб відмітити повідомлення як прочитане — а от чого немає, то відмітки як “зроблене”, щоб прибрати зі списку. Але це не критично.

Як фронтенд обрав Svelte. Мої думки про нього я вже писав. Цього разу ці думки тільки підкріплюються — зі Svelte легше почати працювати над бізнес-логікою, ніж з React. Та й взагалі, виходить, що хоч академічно мені більше подобається React, але для практичної розробки Svelte простіше та приємніше. Принаймні після того, як звикнеш до того, що їх синтаксис, хоча й нагадує JS та HTML, але ж має власні конструкції, які треба знати та помічати - JSX набагато простіше та помітити його легше.

05.02.2023

Відображення змін файлів з PRу з GitHub

Продовжуються мої експерименти з інтерфейсом для перегляду повідомлень для GitHub. Здобув всі необхідні дані, залишилось зробити базовий інтерфейс та цього буде достатньо.

Складнощі виникли з переглядом змінених файлів. Весь PR можна забрати з API у вигляді diff-файлу - для цього треба зробити запит з заголовком Accept: application/vnd.github.diff. Це розповсюджений формат, який легко показати з підсвіткою, наприклад, бібліотекою Prism. Але ж просто показати зміни недостатньо. Для мене необхідно додавати коментарі на окремі змінені рядки — без цього ніякого огляду PRу не вийде. Тому знайшов інший підхід — бібліотеку gitdiff-parser, яка розбирає Diff-файл на файли, фрагменти, та рядки. Далі залишається їх тільки відобразити.

Може виникнути логічне питання — а як сам GitHub відображає сторінку змінених файлів, та чи можна підгледіти там якесь більш зручне API. Але ні, бо на моє розуміння, GitHub використовує Server-Side Rendering, та повертає вже готовий код сторінки. Попри це, як на мене, сторінки PR працюють з неприємними затримками. Саме тому я думаю, що зможу зробити додаток, що буде приємніше, хоч і з меншим набором функцій. Також, навпаки, можна додати такі можливості, за якими зараз доводиться ходити на інші сторінки — наприклад, хотів би бачити blame для змінених рядків, тобто коли та хто їх змінював перед поточним PRом.

Дізнався про обмеження запитів до API GitHub з персональним токеном. А саме, це 5000 запитів на годину. Тобто можна зробити відразу багато — це добре — але потім доведеться довго чекати. Обмеження щедре, та я його знайшов тільки через багаторазове перезавантаження свого додатка, хоч він стягує по декілька різних запитів на кожне з моїх поточних 75 повідомлень. Але, мабуть, краще впровадити якийсь кеш — напевно, у LocalStorage.

14.11.2024

Ефективна робота зі сповіщеннями GitHub

Колись майже два роки тому мене дратував надлишок сповіщень з GitHub, та я навіть намагався зробити для того застосуночок. Погані новини: за весь час, що я витратив на перегляд PRів, такий застосунок не написати.

(Апарт: зі стохастичним трекером я “точно” знаю, скільки це часу. За минулі 9 місяців — близько 30 годин.)

Гарні новини: зі сторінкою сповіщень можна працювати ефективно. Та, якщо в одних обставинах має сенс збирати всі вхідні в один “кошик”, то тут, навпаки, варто розділити. Причому розділити за кількістю уваги, яку PR вимагає. Бо якщо дивитися на всі сповіщення разом, то доведеться кожному приділяти достатньо уваги, щоб нічого не пропустити.

Для цього звертаємо увагу, що на бічній панелі є посилання “Add new filter”. Туди можна окрім вбудованих фільтрів, назбирати власних, за обставинами. Можна або фільтрувати те, що варте уваги, або навпаки — те, що не варте, та масово “відмічати як прочитане”. Ось кілька ідей: