GitHub *

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

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

Привет, Хабр! На связи технический директор MTC RED Денис Макрушин и команда Advanced Research Team: Павел Гусь, Иван Бессарабов и Андрей Сомсиков.

В январе разработчики GitLab нашли в своей системе две критические уязвимости. Из-за ошибок в верификации злоумышленники могут захватывать учётки пользователей и менять содержимое репозиториев. Такой тип атак называется RepoJacking. Мы изучили другой хостинг кода — GitHub — и нашли 1 300 потенциально уязвимых открытых репозиториев. Чем это опасно для разработчиков и их проектов — под катом.

TLRD: zod не подходил в проекте и решили сделать свой builder с помощью ajv в zod-like API. Поскольку гугление не показало никаких вменяемых результатов - было решено сделать свои костыли решения.

Если стало интересно - прошу под кат!

Когда-то давно меня попросили разработать модель динамики полета АСП (авиационного средства поражения) в отечественном ПО, в среде SimInTech, причем разработать не с нуля, а тупо повторив уже созданную ранее модель в Матлабе (с Симулинком), и любезно выложенную в публичный доступ на гитхабе.

Я подумал - почему бы и нет, ведь в Симинтеке есть практически все требуемые блоки, а каких нет, я доработаю по образу и подобию. Без погружения в детали, в конце концов так оно и вышло. Но мне справедливо возразили - а чем докажешь, что твоя модель считает в точности так же, в динамике, как и исходная матлабовская модель?

Всем привет! Меня зовут Роман Аймалетдинов, я андроид разработчик. В этой статье хочу рассказать вам как автоматизировать, хоть и простую, но рутинную работу по созданию и оформлению ваших git-hub pull request через bash скрипт. Это особенно полезно, если у вас монорепозиторий или несколько типов template. Например, отдельные template для bug и для feature или для разных команд. Но не все сразу, сначала разберемся с самими templates, поймем, почему это может быть неудобно и сделаем свой скрипт, который умеет парсить название в человеческое и создавать удобное описание для каждого типа задач. Теперь все по порядку.

Go – отличный язык для создания высокопроизводительных веб-приложений, а высокопроизводительные веб-приложения часто требуют централизованного кэширования.

Стандартом де-факто для централизованного кэширования является Redis, но, популярные сегодня библиотеки Go не поддерживают потоковую передачу данных, эффективных с точки зрения памяти. 

Вместо этого они предлагают []byte API, с которыми вы взаимодействуете следующим образом:

Хочу рассказать о своём новом (хотя существует уже почти 3 года) сайте egaxegax.github.io, после закрытия предыдущего сайта egaxegax.appspot.com на хостинге Google App Engine в начале 2021 года. О нём я писал в статье Cайт на Django-nonrel на платформе Google App Engine для Python. Эта статья рассчитана на тех, кто хочет узнать или получить простой сайт с возможностью добавления и правки контента на основе создания markdown-постов.

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

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

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

Начинаем!

Всем привет! Этой мой первый пост на Habr (да и вообще где либо, за исключением GitHub). Хочу поделиться работой, на реализацию который у меня ушло около месяца, но тем не менее сейчас используя ежедневно и планирую развивать в дальнейшем. Задумка была таковой, что бы донести любой (бесплатный) контент до телевизора используя под рукой только телефон, например, если я еду в метро или нет желания (вставать с дивана) и возможности подойти к компьютеру. На самом деле причина реализации сей творения чуть глубже и проще, под управление я передал дело подбора контента на повседневный вечер супруге. За источник контента отвечает трекер Кинозал, который, к слову, я использую уже 4 года и меня он устраивает во всем.

В работе описана смоделированная ситуация по разработке простого web-приложения на заказ. Для приложения за основу взят фреймворк Ruby on Rails 7 с фреймворком Hotwire и СУБД PostgreSQL. Описание процесса разработки разбито на этапы проектной деятельности, максимально приближенной к жизненному циклу web разработки по методологии Agile. Для максимальной реалистичности в описании упомянуты всевозможные проблемы, которые могут приводить в ступор начинающих Ruby разработчиков. В задачу публикации входит максимальное погружение читателя в процесс разработки. Поэтому работа насыщена ссылками на лучшие образцы методических материалов для экосистемы RoR 7.1 + Hotwire.

Любая реальная разработка сопровождается рядом организационных мероприятий, которые распределяются между разработчиками, аналитиками, тестировщиками и DevOps. В заказных разработках часто всё делает один человек. Вот для таких разработчиков, которые хотят всё знать, и предназначена данная статья. Поэтому здесь вы также найдёте дополнительные сведения об особенностях тестового покрытия fullstack разработки, полноценное решение по документированию Rest API, подробное описание процесса докеризации приложения, и инструкцию по использования GitHub Actions по методологии Continuous Integration.

Недавно столкнулся с лицемерием 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 коррелирует с временем внедрения, полученными комментариями и отказами во внесении изменений, чтобы найти статистически наилучший размер и понять, что на него влияет.»

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

Я уже не раз порывался написать что‑то общее про бранчинг; про некогда распиаренный GitFlow, который запиаривают обратно; про trunk‑based development (умеренно распиаривают), про то, как это увязать с разработкой бэкенда. И вот я затираю очередной забуксовавший черновик своей заметки чтобы всё упростить и не гоняться за чрезмерным обобщением опыта. Давайте я просто поделюсь рецептом, а вы его оцените.

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

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

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

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