#статья дня

С 54000 звёзд на GitHub до нуля за одно мгновение?

HTTPie расскажет и покажет, как!

https://httpie.io/blog/stardust

На самом деле, всё до обидного просто: владелец репозитория по-ошибке сделал его приватным.

Мораль? Будьте внимательны.

Впрочем, ребята уже набрали обратно 18000 звёзд. Свежих, с пылу с жару. Что, в общем, хорошо.

Заодно в статье предложены интерфейсы, предполагающие предотвращение подобных ситуаций.

Есть перевод на русский, кстати: https://habr.com/ru/company/skillfactory/blog/662155/

#github #rest #api #httpie #tools

#ссылка дня

Даже несколько. Тема дня — доменная зона .new. Как бы ни было неожиданно, но, переходя по следующим ссылкам, вы создаёте:

pen.new — песочницу в CodePen
gist.new — GitHub Gist
repo.new — репозиторий на GitHub
react.new — React-песочницу в CodeSandBox

...ну и всем давно известные:

docs.new — документ Google Docs
sheets.new — таблицу в Google Sheets

О, я тут нашёл целый их awesome-список: https://github.com/yjose/awesome-new

P. S. Если вам не знакома концепция awesome-списков, это просто тематические сборники интересных репозиториев или просто ссылок, общее их название.

#new #github #codepen #sandbox

#ссылка дня

Даже несколько. Тема дня — доменная зона .new. Как бы ни было неожиданно, но, переходя по следующим ссылкам, вы создаёте:

pen.new — песочницу в CodePen
gist.new — GitHub Gist
repo.new — репозиторий на GitHub
react.new — React-песочницу в CodeSandBox

...ну и всем давно известные:

docs.new — документ Google Docs
sheets.new — таблицу в Google Sheets

О, я тут нашёл целый их awesome-список: https://github.com/yjose/awesome-new

P. S. Если вам не знакома концепция awesome-списков, это просто тематические сборники интересных репозиториев или просто ссылок, общее их название.

#new #github #codepen #sandbox

#заметка дня

Сервис GitHub Pages известен всем. Это один из самых простых способов разместить ваш статичный и не очень сайт в сети. Особенно учитывая, что вы скорее всего на гитхабе свои проекты и держите.

Какие альтернативы помимо классических хостингов, выделенных серверов и конструкторов?

Ну, мне известно две: Netlify Drop и Cloudflare Pages (боже, как оригинально).

Drop отличается потрясающей простотой: дропнули папку с проектом и всё, отсюда и название. Ещё домен можно свой подключить.

А вариант от Cloudflare, помимо прочего, умеет в:

- интеграцию с GitHub
- пресеты для Next.js/11ty и других фреймворков
- всё обычные возможности Cloudflare для доменов
- аналитику
- разграничение доступа через feature-ветки

Запускайте свои проекты не только локально, котаны!

#pages #github #cloudflare #netlify #drop

#фишка дня

Как сделать описания проектов на GitHub более явными и привлечь внимание читателя там, где это необходимо?

Использовать кастомные цитаты!

Пример: https://github.com/HTMLShit/htmlshit.github.io/blob/master/demo.md

Доступные типы: NOTE, TIP, IMPORTANT, WARNING, CAUTION.

Очевидно, это доступно и в управлении проектами на гитхабе. Для небольших задач — очень хорошо, не нужно переходить в Trello.

Пример синтаксиса:

> [!NOTE]
> Заметка о выпуске

Да, к слову, кто не знает, что за Markdown такой, вот: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

Я ссылаюсь на вариант от GitHub, потому что он самый популярный. В комментариях есть ссылка на вариант от GitLab.

А вот, собственно, где это нововведение обсуждалось: https://github.com/orgs/community/discussions/16925

Как вам кастомный маркдаун, котаны? Заходит?

#github #md #note

#инструмент дня

Итак, у вас команда разработчиков. Даже самые опытные из них не то что забывают проверить банальные банальности, но ещё и проверяют PR-ы на похер.

LGTM. Этими буквами выложена дорога в девелоперский ад.

Чтобы это минимизировать, а, заодно, и снизить когнитивную нагрузку на людей, нужно подключать бездушные машины.

Не протестировал ручками? Отказ. Не написал тесты? Отказ. Не добавил номер тачки или ссылку на тред с продактом в слаке? Отказ.

И для этого подойдет вот такой GitHub action: https://github.com/marketplace/actions/pull-request-auto-reviewer

Вырос он из "общественного" проекта все того же Андрея Ситника Slow Reader.

Конечно, чекбоксы не гарантия спасения от ленивых разработчиков. Но это а) напоминание б) взятие ответственности на себя.

#github #action #workflow

#крик дня

Семантическое версионирование? А нахуя?

Видимо, так подумали авторы популярного GitHub-экшена upload-artifact, предназначенного чтобы результат какого-либо необходимого для деплоя процесса выгрузить дальше.

Что они сделали?

Я максимально пытаюсь не материться, но пару недель назад они предупредили в ишью на гитхабе, что перестанут выгружать скрытые файлы (с точкой в начале имени).

Вот: https://github.com/actions/upload-artifact/issues/602

Что это значит? Так-то намерения хорошие: не позволить выгрузить .env и условные .config.json, содержащие секреты. Чтобы эти самые секреты никуда не утекли.

Вот только ребята забыли, что благими намерениями выложена дорога в ад!

Это изменение предназначалось для версии 4, но они с какого-то перепугу решили выполнить его в 3 версии.

НА-ХЕ-РА?! Кому от этого хорошо? Зачем?

Если люди выгружают секреты куда-то случайно — не беда, перезагрузят!

Абсолютно нормально иметь sample-файлы .env.sample, .config.sample и так далее. Что мы и делали, обогащая эти файлы секретами.

Вот что ненормально — так это навязывать свою точку зрения пост-фактум. Ещё и в стабильной версии.

Просто уроды, слов нет. Certified scumbag engineering.

#github #подстава

#фишка дня

Как сделать описания проектов на GitHub более явными и привлечь внимание читателя там, где это необходимо?

Использовать кастомные цитаты!

Пример: https://github.com/HTMLShit/htmlshit.github.io/blob/master/demo.md

Доступные типы: NOTE, TIP, IMPORTANT, WARNING, CAUTION.

Очевидно, это доступно и в управлении проектами на гитхабе. Для небольших задач — очень хорошо, не нужно переходить в Trello.

Пример синтаксиса:

> [!NOTE]
> Заметка о выпуске

Да, к слову, кто не знает, что за Markdown такой, вот: https://docs.github.com/en/get-started/writing-on-github/getting-started-with-writing-and-formatting-on-github/basic-writing-and-formatting-syntax

Я ссылаюсь на вариант от GitHub, потому что он самый популярный. В комментариях есть ссылка на вариант от GitLab.

А вот, собственно, где это нововведение обсуждалось: https://github.com/orgs/community/discussions/16925

Как вам кастомный маркдаун, котаны? Заходит?

#github #md #note #бородач

#статья дня

Ну чо, котаны, есть занятная история с GitHub.

Исследователь Шерон Бризинов решил проверить, что вообще происходит с коммитами, которые мы с вами удаляем через git reset и force push: https://trufflesecurity.com/blog/guest-post-how-i-scanned-all-of-github-s-oops-commits-for-leaked-secrets

Спойлер — никуда они не исчезают.

GitHub продолжает хранить все те ваши коммиты с ключами и секретами бесплатных и не очень API, даже если нам кажется, что мы всё подчистили.

Собственно, идея исследования простая: если коммиты не пропадают, значит, в них вполне могут оставаться секреты — ключи, токены и прочие радости.

Шерон пошёл и просканировал архив GitHub за несколько лет. Нашёл он там немало интересного, включая утечки, которые потом оценили на баг-баунти в 25 тысяч долларов.

Чтобы процесс не был ручным, он вместе с Truffle Security сделал инструмент Force Push Scanner.

Этот сканер вытаскивает пуши, достаёт зависшие коммиты и прогоняет их через TruffleHog, чтобы поймать секреты. Получился вполне практичный open source, которым можно пользоваться прямо сейчас.

Вывод в итоге грустный, но очевидный: удалить коммит — не значит избавиться от проблемы. GitHub всё хранит, и если секрет уже засветился, его надо менять, а не надеяться на «забывчивость» платформы.

Лучше, конечно, не допускать таких ошибок вовсе, но если уж случилось — придётся действовать радикально.

P. S. у этой статьи есть не менее занятная предыстория, которая дополняет общую картину: https://medium.com/@sharon.brizinov/how-i-made-64k-from-deleted-files-a-bug-bounty-story-c5bd3a6f5f9b

#github

#статья дня

GitHub выкатил отличный пост о том, как они ускоряли рендеринг диффов в пулл-реквестах (исконно русские слова) — и внезапно выяснили, что браузеру становится плохо, когда в PR десятки тысяч строк.

Вот ссыль сразу: https://github.blog/engineering/architecture-optimization/the-uphill-climb-of-making-diff-lines-performant/

Главная проблема оказалась в том, что каждая строка diff-а была маленьким React-стартапом: 8–13 компонентов, куча DOM-нод и отдельные event handlers почти на всё подряд.

Старый подход выглядел примерно так:

<DiffLine>
  <LineNumber />
  <SyntaxHighlight>
    <Token />
    <Token />
  </SyntaxHighlight>
</DiffLine>

И конечно же:

<div
  onMouseEnter={...}
  onMouseLeave={...}
  onClick={...}
/>

Когда таких строк 10 000+, Chrome начинает потреблять память не в себя.

А дальше случилось прекрасное: GitHub героически переоткрыл event delegation — технику, которую jQuery нормально объяснял ещё лет 15 назад (не воспринимайте буквально, автоматическая делегация в реакте была и есть). Оказалось, что один обработчик событий на контейнер внезапно быстрее, чем 30 тысяч onMouseEnter на каждую строку. Кто бы мог подумать.

Новый вариант:

<table onMouseMove={handleHover}>
  <tr data-line="42">
    <td>const value = 1;</td>
  </tr>
</table>
function handleHover(e) {
  highlight(e.target.dataset.line)
}

В итоге GitHub выкинул 74% React-компонентов, почти вдвое снизил потребление памяти и ещё удалил пару лишних <code>-тегов из каждой строки, потому что 20 000 ненужных DOM-элементов — это всё ещё 20 000 ненужных DOM-элементов.

Мораль истории максимально простая: abstraction is not free. Иногда один обработчик событий и туповатый плоский код работают лучше, чем архитектура мечты из 400 reusable-компонентов, custom hooks и трёх уровней composition.

#github #react #virtualization