GitHub

Привет, Хабр! Меня зовут Руслан, я — автотестировщик в QA-агентстве «Кавычки». Из этого можно понять, что мы в агентстве занимаемся только тестированием во всех его проявлениях, а меня зовут Руслан. Отлично, идем дальше. Когда какая-то проблема начинает сильно докучать, то даже тестировщики могут что-то создать (ну или сломать это к черту, чтобы не мешало). Это статья как раз про тот случай, когда наша проблема перешла совместимый с жизнью болевой порог, и нам пришлось решить ее с помощью собственной разработки.

Вся наша команда распределена по нескольким странам, поэтому мы не понаслышке знакомы с плюсами и минусами удаленной работы. В какой-то момент минусы начали мешать и соответственно отражаться на качестве тестирования, поэтому мы написали свою мобильную ферму. А из это предложения можно подумать, что мы взяли, сели и написали ее в один прекрасный день, но это не так. Дальше расскажу, как мы к этому пришли, что делали, через что прошли и, конечно, что в итоге получилось. Спойлер: в конце будет ссылка на гит, где лежит наша поделка.

Добрый день, коллеги! Доказывать, что нужно использовать систему контроля версий, уже давно не нужно. И Git занял тут лидирующую позицию, стремительно вытеснив SVN. Но это инструмент, а инструментом нужно уметь пользоваться, чтобы добиться лучших результатов. Как топором, один человек сможет просто срубить дерево а другой из этого дерева сможет сделать великолепную скульптуру. Так и с помощью Git, один человек сможет просто не потерять результаты своего труда за день, а другие смогут организовать совместную работу над проектом нескольких сотен человек. Да так, что о любой строчке кода можно будет и через пять лет сказать, откуда она взялась и для чего нужна.

Постараюсь рассказать для начинающих и не очень разработчиков, как оформлять свои коммиты, чтобы их максимально быстро и без претензий принимали в любые проекты, как опенсорсные так и коммерческие.

В рамках изучения ЯП Golang я решил сделать учебный проект на примере telegram-бота. Для этой цели я взял популярный для создания ботов API

Написав реализацию нужной мне бизнес-логики, у меня возник вопрос: А как же мне его по-быстром собрать и бесплатно развернуть?

Несколько лет назад у меня был опыт создания утилиты на Go, предназначенной для работы в качестве вспомогательного docker контейнера в AWS ECS. И тогда мне понравилась идея, собрать докер из scratch образа без каких-либо базовых образов. Но использовать сервисы AWS для своего pet-проекта я не стал из-за дополнительных хлопот с настройками доступа и ключами безопасности. Я решил попробовать появившуюся не так давно CI/CD автоматизацию github.com/actions

Немного изучив предоставляемые CD автоматизации с хостингом, наиболее немногословным мне показалась автоматизация развертывания на heroku. И хотя опыта с ним я раньше не имел, мне хватило пары минут, чтобы зарегистрировать аккаунт на HEROKU и найти нужный для экшена heroku_api_key

Получился достаточно немногословный конфигурационный файл, бОльшая часть которого была автоматически сгенерирована GitHub Actions

Ревью кода это довольно обыденный процесс. Хотя и не многие могут объяснить, зачем это нужно команде — ревью будто без вопросов необходимо для мифического "хорошего кода". В целом сообразить пару причин, зачем же делать просматривать код коллег довольно просто, но такие причины далеко не всегда имеют весомое подтверждение. И далеко не всегда ревью достигает предполагаемых целей из-за недостаточного качества ревью и вовлечения команды.

Я расскажу про причину зачем вам лично может быть полезно ревью кода сокомандников.

Когда-то пару лет назад на работе ко мне обратился коллега (привет!), который знает мою любовь к автоматизации с довольно нетривиальной просьбой. Нужно было почистить старые репозитории в корпоративной орге Github, но не совсем удалить, а сохранить на "всякий случай". Да и не просто сохранить, а сохранить с git историей. Мы с ним довольно быстро набросали скрипт на баше, который принимал аргументом orgName/projectName. После окончания работы скрипта он пушил код в отдельную ветку, и потом можно было это померджить в основную "ветку-хранилище". Скрипт был написан быстро, задачу решал, но все равно оставалось пара действий, которые надо было сделать "руками". Но в том случае это было нормально, так как требовалось подтверждение на архивирование старого проекта. Еще тогда у меня появилась идея сделать Github Actions workflow, с которым я только познакомился. Но свободного времени на это не было. И вот спустя год-полтора я наконец-то сделал задуманное - так появился на свет Bygone project, который доступен на github.

В прошлый раз мы сделали простой запрос на получение списка репозиториев пользователя. Там был только код и ни чего лишнего. В этот раз попытаемся разобраться с внутренней схемой устройства ГрафКьюЭль.

Пример рабочего кода с комментариями и ничего лишнего!

Познакомиться с PHP фреймворком CodeIgniter 4 достаточно просто.

Нужно потратить вечер, выполняя инструкции из раздела  «Build Your First Application» («Создайте свое первое приложение»). Поскольку документация написана хорошим, технически понятным языком, то в процессе ознакомления с этим и другими разделами возможно получить даже некоторое эстетическое удовольствие.

В прошлом году GitHub без лишнего шума выпустил новую возможность, которую быстро заметили в сообществе пользователей, — файлы README в профилях. По сути, README-файл профиля представляет собой глобальный файл README, связанный с вашим профилем GitHub. Чтобы он появился, нужно создать публичный репозиторий, имя которого совпадает с вашим именем пользователя на GitHub. Например, мое имя пользователя — osteel, поэтому я создал osteel/osteel в качестве такого репозитория.

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

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

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

Можно выделить несколько стадий поиска бага:

• удивление (не знаю как вы, но я каждый раз как в первый раз удивляюсь когда что-то вдруг в моем коде работает не так, как ожидается);

• обвинение всех кругом в баге (коллег по проекту, github, сторонние либы, компилятор), но только не себя;

• смирение с тем, что возможно баг появился из-за меня и поиск бага: анализ выдаваемого результата, локализация ошибки, эксперименты с входными данными; в общем, все, что делает нормальный детектив, только в сфере программирования;

• если причина бага найдена быстро, то я хвалю себя за то, что нашел баг, при этом, я не напоминаю себе, что причиной бага стал тоже я, а не коллеги по проекту, не github, не сторонние либы и не компилятор;

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

Заглядываем под капот, решаем проблемы и баги. Как все устроено и что используется - ответы тут! С вами Алексей и сегодня речь пойдет именно от этом.

В прошлом году GitHub выпустил фичу сканирования кода, которая позволяет разработчикам добавлять проверки безопасности в свою среду CI/CD и в целом в рабочую среду. В этом посте демонстрируются основы использования CodeQL, механизма анализа, лежащего в основе сканирования кода, в связке с GitHub Actions.

Гитхаб экшены, как я познавал ci/cd

   Всем Алоха. Все слышали про ci/cd, про то что он должен быть в каждой компании и то что он упрощает нам жизнь. У всех свой ci/cd. 

   Кто-то предпочитает Jenkins. Особенно если у вас куча микросервисов, команд и процессов, то при помощи Дженкинса можно достаточно гибко настроить ci/cd в компании. Кто-то использует GitLab actions и для каждого репозитория настраивает свои пайплайны и процессы. Достаточно удобно и просто настраиваемый механизм сборки и доставки артефактов на стенды. Не чуть не хуже GitHub actions. Это было открытием для меня что в GitHub появился такой функционал, о котором мы поговорим позже. Ну и конечно всеми «любимый» скриптовый ci/cd. Пачка скриптов, которые нужно выполнить в определенной последовательности чтобы собрать и задеплоить артефакты. Есть ещё так сказать хэнд мэнуал ci/cd. Но это особый вид извращения, с которым не пожелаю столкнуться никому. В котором нужно собрать артефакты у себя на машине и по какому нить ридми выполнять команды в терминале, лазить по ssh смотреть, что все копировалось, перезапускать сервисы и другие развлечения. 

    Передо мной стояла задача спроектировать и написать новый сервер для проекта. Изначально я закидывал джарники на сервак руками, чтобы проверить работоспособность и настроить сервер. Хэнд мэнуал деплой. В какой то момент меня это начало бесить и я задумался об автоматизации этого процесса. Как вы понимаете девопса или того кто шарит в этом у меня под рукой в компании не оказалось. Очень круто, если у вас есть такой человек. У меня был выбор сделать скрипт деплой, чего я искренне не хотел, потому что в целом не любитель копаться в терминале и скриптах, когда этого можно избежать. Поднять дженкинс и настроить там джобы и пайплайны. Вариант оч классный для большой компании, а мне нужен деплой лишь одного сервера, а не тысячи микросервисов. Да и чего таить, знаний как настраивать дженкинс с нуля у меня было чуть меньше чем ноль. 

Здравствуй, читатель. Хотелось бы ненадолго отвлечь твое внимание от новостей и историй данной технической статьей. Поэтому пусть такой "кликбейтный" затравочный заголовок не вводит тебя в заблуждение.

В этой статье я расскажу как сделать параллельную книгу, имея на руках два текста на разных языках. Я написал веб-приложение, которое упрощает процесс выравнивания, превращая сырые тексты в книги и параллельные корпуса. Хочу поделиться с сообществом этим проектом, а также узнать ваше мнение. Технические детали я описывал здесь и здесь, код приложения открытый. Поехали.

Установка

Приложение я оформил в виде docker контейнера, поэтому запустить его у себя на машине не должно составить труда. Также можно запустить приложение из исходников, инструкция есть в репозитории.

Итак, для запуска приложения у себя на компьютере нужно выполнить следующие команды:

docker pull lingtrain/aligner:v4
docker run -v C:\app\data:/app/data -v C:\app\img:/app/static/img -p 80:80 lingtrain/aligner:v4

C:\app\data и C:\app\img — это папки на вашем компьютере.

Контейнер скачается с репозитория Docker Hub и запустится на 80-м порту. Откроем приложение в вашем любимом браузере по адресу localhost.

Сделаем три шага: загрузка, выравнивание, генерация.

Недавно я решил немного привести в порядок несколько своих .NET pet-проектов на GitHub, настроить для них нормальный CI/CD через GitHub Actions и вынести всё в отдельный репозиторий, чтобы все скрипты лежали в одном месте. Для этого пришлось как следует изучить документацию, примеры и существующие GitHub Actions, выложенные в Marketplace.

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

Статья в первую очередь рассчитана на начинающих, тех, кто никогда не использовал GitHub Actions, но хотел бы быстро начать. Тем не менее, даже если у вас уже есть подобный опыт, но вы, например, не использовали ncc, то, возможно, и для вас в ней будет что-то полезное.

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

В ноябре прошлого года более 500 российских технологов присоединились к нашему первому GitHub Meetup на русском языке и сейчас наше комьюнити насчитывает уже больше 1000 человек. Недавно мы открыли Telegram канал. Для нас это большая честь - привлекать такое внимание, и мы всегда будем рады слушать, учить и вдохновлять русскоязычное сообщество на вашем родном языке.

Вот краткое изложение того, о чем мы рассказали на данный момент.

Меня зовут Григорий Горбовской, я работаю в Web-команде департамента по экосистемным продуктам ВКонтакте, занимаюсь разработкой VKUI. 

Хочу вкратце рассказать, как мы написали 8 тестовых веб-приложений, подключили их к моно-репозиторию, автоматизировали аудит через Google Lighthouse с помощью GitHub Actions — и как решали проблемы, с которыми столкнулись.