GitHub *

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

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

Enable 2FA now. You'll be able to continue on with your work right after.

Но как обычно, дьявол в деталях. Ведь чтобы добавить аппаратный ключ нужно, чтобы двухфакторная аутентификация была УЖЕ активирована.

И в данном случае фокус с отправкой SMS на левый номер какого нибудь сервиса для временных телефонных номер вряд ли будет хорошей идеей.

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

Привет! Я Александр Омельяненко, Flutter-разработчик в AGIMA. Недавно мне понадобилось быстро настроить CI/CD на Flutter-проекте. Те несколько руководств, что я нашел в интернете по этой теме, были либо с нерабочими примерами, либо запутанные и просто плохого качества. Но всё же какое-то представление я получил. Плюс задал вопросы коллегам. Набивая шишки по пути, я-таки настроил CI/CD на своем проекте. Но мне тогда очень пригодилась бы четкая инструкция. Поэтому я решил написать ее сам по горячим следам. Сегодня делюсь ею с вами и надеюсь, эта инструкция облегчит жизнь тем, кто настраивает CI/CD на Flutter-проекте прямо сейчас.

Привет, хабр! Сегодня я расскажу вам, как создать свой блог на Github Pages, используя hugo!

Хотите создать свой собственный блог, но не хотите привязываться к каким-либо крупным хостинговым решениям или издательским сайтам по подписке? Решение есть!

В этом посте я расскажу, как настроить protolint для проверки .proto файлов на соответствие официальному style guide в GitHub Actions и поделюсь практическим опытом его использования.

В этом посте я поделюсь с вами подробной инструкцией по настройке автоматической проверки обратной совместимости gRPC API с помощью protolock в GitHub Actions.

В этом посте я покажу, как с помощью GitHub Actions легко реализовать генерацию и публикацию gRPC API пакетов в GitHub Packages, в реестрах Apache Maven и npm. Если вы хотите освоить GitHub Packages для своих проектов и научиться генерировать gRPC API для сервисов на Kotlin/Java и gRPC-web клиентов — добро пожаловать под кат.

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

«Какого же размера он должен быть? Бывает ли идеальный размер? Если бы теоретически можно было полностью его контролировать, то насколько большим его нужно делать?»

Вы гуглите, находите множество ресурсов, сайтов и статей наподобие этой, которые анализируют тему и делают примерно такой вывод:

«Слишком маленькое количество строк может не отображать полностью изменения, а чрезмерно большой PR может утомить проверяющих, что усложнит выявление проблем или написание осмысленного отзыва»

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

Однако моя статья будет немного о другом:

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

Пояснение: тем, кто экспериментирует с данными, особенно после прохождения курсов/обучения в сфере данных, приведённое выше может напомнить о фразе «Корреляция не означает причинно-следственной связи». Да, они будут абсолютно правы. Мы попытаемся рассмотреть под разными углами, как эта корреляция варьируется в зависимости от компании, разработчика и общего объёма коммитов кода, а также под другими углами, которые могут помочь нам понять, какие другие значения могут по каким-то причинам отвечать соответствующим паттернам. Однако это «всего лишь» числа и корреляции, они не объясняют своих причин, поэтому любые наши предположения о причинах, скорее, субъективны и не подтверждены научными исследованиями.

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

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

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

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

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

Как настроить GitHub Actions и не заплакать: пошаговая инструкция

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

В статье буду разговаривать о деплое только фронтенда. Про деплой бэкенда расскажу в следующем материале.

В этой статье я хотел бы затронуть тему хранения кода в Git, контроля версий, релизов и в целом как этим всем управлять в команде.

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

Специалист отдела перспективных исследований компании «Криптонит» Игорь Нетай изучил процесс потери точности вычислений и написал библиотеку, доступную на GitHub, которая помогает разработчикам контролировать точность расчётов на каждом этапе вычислений. Данная библиотека особенно актуальна в сфере машинного обучения и анализа (больших) данных, где накопление ошибок может сильно искажать результат.

Работаю я в бюрократизированной конторе с плохими процессами. Текучка тут достаточно большая. Люди приходят и уходят. Менеджмент на уровне дна. В какой-то момент в команду докинули нового разработчика (с неясными целями и задачами). Ну вроде парень умный, вроде что-то делает, вроде не просто так.

Спустя четыре месяца (испытательный закончился) у многих закрались подозрения, что на самом деле парень ничего не делает. Но как доказать это со стороны объективно? Решили посмотреть историю коммитов. Оказалось, он почти не коммитил (последний месяц вообще перестал), а на совещаниях ссал в уши ездил по ушам. Парень продолжил работать на прошлой работе и был преподом на курсах. Такой вот overemployed, с двумя зарплатами по ставке синьора.

Ему предложили перевестись в другой отдел. Менеджеру все сошло с рук. Часть разрабов сидела с лицами «‎а что так можно было?»‎. А я понял, что нельзя так просто взять и посмотреть статистику коммитов.

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

Я не встречал людей, которые любят делать одну и ту же рутинную работу. Большинству из нас хочется автоматизировать подобную деятельность, чтобы скучные и повторяющиеся операции выполняла бездушная машина. В центрах мониторинга информационной безопасности немало таких задач, особенно на первой линии. В этой статье я, Константин Грищенко, руководитель отдела мониторинга безопасности в Positive Technologies и участник открытого сообщества Security Experts Community, расскажу о том, как мы в отделе упрощаем свою работу с помощью инструмента SiemMonkey. Любой желающий может скачать его и установить в браузере.

У нас в ИТ-команде Сравни есть принцип: в любой непонятной ситуации вместо того, чтобы раз за разом решать похожие проблемы, лучше сделать инструмент, который поможет системно решать целый класс таких задач. Шаблонизация, автоматизация занимают важное место у нас в бэклогах. Поэтому эксперименты с Copilot от GitHub и OpenAI, наверное, были для нас неизбежны.

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

Недавно мне потребовалось собрать и развернуть документацию для одного из своих небольших проектов на Python. Написал документацию, собрал Sphinx'ом, дальше собрался заливать на readthedocs.org и обнаружил что без VPN сайт не алё. Более того, почему то и с VPN нормально не получалось импортировать свой проект с GitHub.

Не долго думая, решил изучить ситуацию на "рынке" и нашел неплохую альтернативу - GitHub Pages. Эта статья о том, как я деплоил мультиверсионную документацию на GitHub Pages c помощью GitHub Actions и своими собственными "костылями".

Это 2-ая часть статьи "Как задеплоить монолитный pet проект на Java с 0 и не сойти с ума". Первую часть вы можете найти по ссылке.

В первой части мы успешно добавили свои наработки в репозиторий GitHub, в этой части мы рассмотрим что такое GitHub Actions и как с помощью них добавить свой образ docker контейнера с приложением в хранилище DockerHub.

Привет, Хабр! Я недавно начал свой путь в data science, хочу поделиться реализацией алгоритмов по обработке матриц.

Перерыв в работе заставил меня задуматься над смыслом выражения "Сапожник без сапог". Будучи Java Backend Developer с 3-ех летним стажем я не имею на руках ни одного pet проекта. Конечно, на GitHub у меня есть какие-то мелкие проектики, но они не доведены до конца и кроме того как просто висеть на доске "почета" они больше ничего и не могут. С этой мыслёй я пошел в интернет гуглить "как мне задеплоить свое приложение?".

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