GitHub *

Вступление

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

Примерный план был такой: приобрести Raspberry PI 3 и экран, подключить его к интернету, написать приложение, повесить на стенку и пользоваться с удовольствием.

В процессе проектирования, я сразу же увидел проблему в процессе разработки – как разрабатывать на домашнем компьютере и автоматически доставлять и запускать написанное приложение на Raspberry Pi, чтобы это не было долгим и мучительным ручным процессом.

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

Статья будет посвящена полному циклу разработки кроссплатформенного десктопного приложения, преимущественно для использования на одноплатном компьютере Raspberry PI 3, а также, речь пойдет о его автоматическом развертывании, с описанием проблем и их решений, которые возникли в процессе разработки. В статье упор сделан на решение проблемы с доставкой, сборкой и запуском приложения на Raspberry Pi.

Выбор технологий для разработки и настройка Raspberry Pi

Для решения поставленных задач, нам потребуется ряд технологий, а именно:

-        Кроссплатформенный фреймворк для работы логики и GUI приложения;

-        ПО для автоматического развертывания приложения;

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

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

В этой статье я расскажу, как мы организовали последовательное автоматическое увеличение номера версии приложения при выполнении коммита в ветку main с помощью Azure DevOps Pipeline.

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

Если вам надо отдать ваш код на ревью, например показать выполнение тестового задания, получить одобрение у коллеги на pull request или попасть на разбор кода в "Android Broadcast", тогда 10 советов из этой статьи помогут вам представить ваш код в максимальной красоте. Это не сделает из вас эксперта, но как минимум улучшит ваши навыки, и позволит достичь получить заветное "Одобрено"

Привет, Хабр! Меня зовут Руслан, я — автотестировщик в 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

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

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

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

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

Познакомиться с 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, то, возможно, и для вас в ней будет что-то полезное.