GitHub *

Вы пользуетесь GitHub, пишете код и делаете прочие веселые штуки. Для повышения качества своей работы и оптимизации своего времени используете статический анализатор. И вот вам приходит идея - а почему бы не смотреть на ошибки, которые выдал анализатор, прямо в GitHub? Да и еще, чтобы это красиво выглядело. Что же делать в этом случае? Ответ очень простой. Ваш выбор – SARIF. О том что это такое, как это настроить, и будет рассказано в данной статье. Приятного чтения.

Git - это консольная утилита, для отслеживания и ведения истории изменения файлов, в вашем проекте. Чаще всего его используют для кода, но можно и для других файлов. Например, для картинок - полезно для дизайнеров.

С помощью Git-a вы можете откатить свой проект до более старой версии, сравнивать, анализировать или сливать свои изменения в репозиторий.

Вообще Postgres очень известен и о расширении ltree написано, если немного, то достаточное кол-во публикаций, в том числе и на Хабре тоже, да и сообщество Laravel довольно обширное.

Но как ни странно, я обнаружил полное отсутствие каких-либо библиотек для работы с расширением ltree (от PostgreSQL) под Laravel на GitHub.

Есть некоторые попытки для Yii2, также есть наработки для Symfony (по моему bundle для 2-й, из коробки не работает), и на этом, пожалуй, все.

Это очень грустно, что и послужило поводом написания данной статьи, как наверное и от части, желание поделиться с вами своим опытом работы с древовидными справочниками в Laravel, т.е. как мы работаем с ltree в своих проектах, собственно, почему в итоге мы выделили эти компоненты в GitHub в общий доступ.

На мой взгляд, это очень удобная библиотека, о которой я вам сегодня хочу рассказать. И буду очень рад, если вам она будет полезна.

Этот пост будет полезен двум категориям людей: IT-рекрутерам и начинающим разработчикам, которые хотят научиться писать простенькие программы для решения практических задач.

Задача: известен профиль пользователя на GitHub, необходимо найти email этого пользователя

Решение: один запрос к API GitHub и телеграм-бот, которого мы напишем в этом посте

Идея написать бота пришла ко мне после того, как коллега поделилась со мной этим способом...

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

А если вы, как и я, используете в своих проектах Postgres, то рано или поздно вам потребуются плюшки этой замечательной СУБД, такие как: различного рода индексы и констрейнты, расширения, новые типы и тд...

Сегодня, как вы уже заметили, мы будем говорить про Postgres, про миграции Laravel, как это все вместе подружить, в общем, обо всем том, чего нам не хватает в стандартных миграциях Лары.

Ну а для тех, кто не хочет погружаться в тонкости внутреннего устройства Laravel, может просто скачать пакет, расширяющий возможности миграций Laravel и Postgres по этой ссылке и использовать его в своих проектах.

Но я все же рекомендую не пролистывать, а прочитать все до конца.

Есть такой продвинутый инструмент Scrutinizer CI.

Для OpenSource он абсолютно бесплатный и платный для приватных репозиториев.

Вы о нем слышали, наверное, а если нет, то лично я использую его для анализа кода на различного рода уязвимости, а также в качестве замены статическому анализатору типа Psalm, ну и для покрытия конечно же, т.к. при довольно простой сквозной интеграции с GitHub оно внедряется в ваши PR и можно ревьюить код, наблюдая покрытие по аналогии с Cubertura в GitLab.

Это удобно, но к моему великому удивлению, на хабре, как и в целом на просторах интернета, довольно мало информации о том, как быстро и просто подключить этот крутой инструмент к вашему репозиторию в GitHub, ну а если вы еще и английского не знаете, то картина еще более грустная.

Поэтому я решил поделиться с вами своим опытом интеграции со Scrutinizer CI, рассказать о нюансах и тд...

GitHub Actions — инструмент для автоматизации рутинных действий вашего пакета на GitHub.

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

GitHub предоставляет действительно удобные и рабочие инструменты для этого.

Как же люди любят упрощать сложное и усложнять простое, ну или как я настаивал планшет для работы.

Продолжу выкладывание примеров использования GitHub'а как инструмента обучения.
Рассмотрим версию работы нескольких команд над одним большим проектом с подпроектами.

В данной статье я покажу и расскажу, как можно сгенерировать аватарки как на Github.

Продолжу выкладывание примеров использования GitHub'а как инструмента обучения.
Продолжу вариантом про командную работу. Но рассмотрю ту его версию, когда нет большого числа репозиториев и веток.

В своей статье "Использование GitHub в обучении студентов" я кратко коснулся темы использования GitHub'а именно как инструмента для обучения, а не как темы в обучении. Сейчас хочу попробовать привести примеры нескольких кейсов.

Начну с относительно простого варианта, а в следующих статьях расскажу про другие варианты.

В своей преподавательской практике использую GitHub...

Но для начала давайте представлюсь. Зовут меня Старинин Андрей. И я преподаю программирование, хотя по первому образованию я биолог.

Открываю VS Code и начинаю набирать статью с самого начала. Но вот незадача — формат маркдауна не совсем совместим с имеющимся форматом Хабра. Получается выхода нет и придётся возвращаться к встроенному редактору Хабра;

Или не придется?

В голову пришла идея написать утилиту, которая конвертирует разные форматы маркдаунов друг в друга, например, из формата GitHub в формат Habr;

Такую программу я в итоге и разработал. Теперь не надо копировать статьи в редактор Хабра, чтобы посмотреть как она выглядит, можно продолжать писать в любимом VS Code;

Хотя я и использую множество плагинов VS Code, но мысли о неэффективном процессе написания статей не исчезли. Раз уж я набираю текст в VS Code, то почему бы сразу не делать коммиты контента в гит-репозиторий?

Это дало бы немало новых возможностей, которыми пользуются программисты: версионирование, бекапы на локальные носители или веб-сервисы, правки от редакторов и пользователей. А еще можно внедрить CD/CI;

В итоге, я написал небольшой гайд для разработчиков, как писать техническую документацию в редакторах, используя мою утилиту. Саму утилиту можно посмотреть в моём репозитории на GitHub;

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