​​#заметка дня

#github #ghpages #tips

При работе с Github Pages мало кто заглядывает дальше раздела quick start. И вот очень зря.

Не претендую на полный список, но есть пара вещей, которые следует понимать всем.

1. Не начинайте названия каталогов и файлов с _ (подчёркивание), . (точка), # (октоторп) и не заканчивайте их ~ (тильда). С тильды, впрочем, начинать тоже не надо. Почему? Потому что гладиолус. Точнее, Jekyll. Именно его используют GH Pages для генерации ваших страниц: https://jekyllrb.com/docs/structure/ Пример с подчёркиванием — наиболее частый, не знаю, откуда взялась мода называть каталоги так. Для сортировки, видимо. Починить это, впрочем, легко — добавьте файл .nojekyll в ваш репозиторий.

2. URL — регистрозависимы. image.jpg и image.JPG — разные файлы. Это нарушает правила обработки URL, но у GH Pages есть право считать по-своему. Причина проста: GitHub должен поддерживать как регистрозависимые файловые системы, так и регистронезависимые. Поэтому постарайтесь придерживаться одного правила в именовании.

Делитесь вашими примерами, дополним заметку.

#фишка дня

Залогиньтесь на GitHub, проследуйте в любой репозиторий и нажмите точку — .. Желательно иметь браузер посвежее.

Просто сообщаю…

#github #feature

#тред дня

Понравилась мне идея сохранять хорошие треды из Твиттера, потому что искать их потом сложно, а ссылаться на них охота.

Сегодня поговорим о код-ревью в треде от Олега Климакова.

Я в чатах всегда рекомендую перед фрилансом попробовать работу в студии или продукте, потому что там обмен опытом происходит максимально быстро. Да, может вы и упрётесь в потолок свой или студии, но зато не будете одни. А код-ревью — как раз один из столпов обмена опытом.

Поехали.

1. Тред про код ревью. Зачем он нужен, как его готовить и как не испытывать эмоции как на картинке.

2. Для начала - зачем это всё?

Если вы работаете в продуктовой компании, то жизненный цикл почти каждого продукта будет соответствовать принципу Парето - 20% времени мы пишем новый код. 80% времени поддерживаем старый.

3. Во время поддержки проекта, мы хотим чтобы все разработчики как можно быстрее вникали в то, что написано. Для этого есть много способов, все они прекрасны и хорошо работают вместе.

4. Способы чтобы иметь хорошо поддерживаемый код:

✅Покрытие тестами
✅Ведение документации
✅Код ревью

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

5. Что даёт код ревью:

➕Проверку кода по многим критериям (неочевидные места, композиция, комментарии)
➕Шаринг знаний о проекте. Не только 1 человек знает что там пишется в другом проекте или части проекта, а все.
➕Шаринг знаний о технологиях. Найти велосипеды и выдать свои

6. Способов поддерживать код «качественным» есть много, но все их нужно правильно готовить. Нужно уметь писать тесты, нужно уметь писать документацию и нужно правильно организовать код ревью

Дальше советы из моей практики. На объективность не претендую.

7.

❌Ревьюить только джунов и новых коллег
✅Ревью проходят все и проводят все

В коде лидов тоже могут быть ошибки. Джуниор разработчики могут подсмотреть какие-то практики, методы, способы из кода сеньора. Это удобнее чем обучать их в переговорках.

8. Если ревью проходят не все, то в вашей команде это будет восприниматься как источник недоверия. Такую атмосферу следует избегать.

9.
❌Обсуждать на код ревью стиль
✅Настроить у себя на проекте инструменты которые автоматически будут исправлять стиль перед коммитом

В JS это eslint и prettier. Не тратьте время своё и коллег на вкусовщину. Договоритесь заранее и пропишите правила. Если спорите - голосуйте.

10.
❌Ничего не проверять
✅Обращать внимание на композицию, магические переменные, оптимизацию (там где это имеет смысл).

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

11.
❌Агрессия, негатив, «токсичное» поведение в комментах
✅Старайтесь отмечать не только негативные стороны, но и хвалить за позитивные.

Комменты должны быть: «Давай попробуем сделать …» «Может попробуем вынести…» а не в духе: «это плохой код» «перепиши» и так далее

12.
❌ Мердж реквест висит без ревью трое суток
✅ Выработать расписание.

Например вы занимаетесь ревью в начале работы и вечером. Исправления проверяете во время перерывов, пока проект билдится например. Хотфиксы, понятно, работают по-другому.

13.
❌ Ревьюеру запускать код и заниматься ручным тестированием.
✅ Разработчик поставляет уже проверенный код

Если ветка планирует вливаться, то она должна быть проверена тем, кто в ней написал. Ревьюер по умолчанию считает, что написанный код работает как надо

#работа #pr #github #twitter

#ссылка дня

Кому тут было надо различных эффектов по наведению мыши? Их есть у меня.

Целый репозиторий всяческих :hover-правил: https://github.com/IanLunn/Hover

Название оригинальное: Hover.css :)

Есть и демо-страница: http://ianlunn.github.io/Hover/

Не могу сказать, что вы найдёте какие-то откровения там, но чекнуть стоит. Эффект завёрнутого уголка довольно забавный. Да и общий подход.

#css #hover #github

#ссылка дня

Даже несколько. Тема дня — доменная зона .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

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

#new #github #codepen #sandbox

P. S. вчерашнее было случайно удалено, но терять не охота.

#репозиторий дня

Все же помнят, что в репозиториях на GitHub можно нажать точку и поковыряться в коде прямо внутри всамделишного VS Code?

Я всё думал, куда же это пойдёт, ведь там особо не разгуляться. Но магия workspaces творит чудеса и вот уже можно предложить установить пару расширений прямо внутри браузерного редактора.

Каких? Ну, например, CodeSwing и CodeTour, чтобы продемонстрировать свою работу. Как в CodePen, да.

Попробуйте прямо тут: https://github.com/lostintangent/rock-paper-scissors

Кажется, это прекрасно.

#vscode #github

#статья дня

Я не так давно писал про инструмент для построения диаграм в Markdown-файлах, Mermaid.

Так вот, в том посте я говорил, что поступило предложение о поддержке Mermaid в GitHub.

И таки да! Завезли: https://github.blog/2022-02-14-include-diagrams-markdown-files-mermaid/

Рендерится, правда, в iframe. С другой стороны, ну и что.

Осталось дождаться пока завезут в GitHub Enterprise.

К слову, в предыдущем посте я не упомянул, что поддержка языков диаграм Mermaid и PlantUML имеется и в продуктах от JetBrains: PhpStorm, WebStorm, IDEA и т. д. Прямо во встроенном плагине Markdown.

#github #diagram #mermaid

#статья дня

С 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 #подстава