GitHub *

Как же меня бесят статьи в духе “Как всего за 139 рублей в месяц развернуть свой сайт-визитку на vps”. Какие 139 рублей за сайт-визитку, совсем уже стыд потеряли?!

В этой статье я вам пошагово расскажу и покажу как бесплатно разместить и вести ваш личный сайт (блог, cv, wiki). Вам даже отдельный домен не нужен (всё будет «из коробки»), хотя в последнем шагом мы и его прикрутим. От вас нужны будут базовые знания git и просто уметь работать с markdown.

8 лет назад я исправил опечатку в чужом репозитории, а сейчас регулярно делаю коммиты в проекты, которые использую, и даже вошел в core team библиотеки с 27000 звёзд на GitHub

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

Почти три года назад мы выложили в опенсорс DivKit — наш BDUI‑фреймворк для отрисовки интерфейса приложения из ответа сервера. С его помощью вы можете описать элементы, состояния и анимации на бэкенде. Приложение получит это JSON‑описание и отобразит его.

Мы не перестаём развивать DivKit и за последние месяцы добавили несколько важных функций. О них расскажем в статье.

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

Для этого, на языке программирования Python я начал писать своё CLI‑приложение, которое упрощает работу с консолью. И что из этого вышло?

Сделать перевод этой статьи нас сподвиг, как ни странно, роман Джонатана Свифта «Путешествия Гулливера». Есть там такой примечательный эпизод о борьбе остроконечников и тупоконечников. Аналогия в контексте разработки ПО — это принимающий бесконечный характер спор о преимуществах и недостатках двух инструментов, — OpenAI Codex и GitHub Copilot, — призванных помогать разработчикам. Как нам показалось, эта переводная статья довольно подробно разбирает работу данных инструментов и поможет внести ясность о сферах их применения, особенно для начинающих программистов.

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

Когда я впервые решил создать свой open-source проект, мне казалось, что главное – это хорошая идея и рабочий код. Я взялся за разработку библиотеки для сетевых клиентов и UI-компонентов, вложил в неё два года работы и, наконец, выложил на GitHub. Но вместо успеха меня ждал холодный душ – библиотека получила всего 10 звёздочек.

Тогда я осознал ключевую проблему open-source: одна только идея не работает. Если проект плохо оформлен – его никто не найдёт. Документация и описание –  не менее важны, чем сам код. В следующем проекте я учёл ошибки. Когда правильно оформил проект, он начал находить аудиторию, получать звёзды и фидбек от разработчиков.

Open-source – это не только код, но и способность донести свою работу до других. И эта история дала мне важный урок: если хочешь, чтобы твой проект заметили, помоги людям его понять. А ещё я понял, как важно участвовать в комьюнити и контрибьютить.

Привет, Хабр! Меня зовут Андрей Гетманов, я работаю ML-инженером в Исследовательском центре “Сильный ИИ в промышленности” в ИТМО, а кроме того являюсь энтузиастом open source. В этой статье хочу рассказать о нашей новой разработке ― ИИ-инструменте, который помогает репозиторию стать лучшей версией себя.

Разнообразных «улучшателей» много, но все они фокусируются преимущественно на качестве самого кода. Мы же смотрим шире ― на репозиторий в целом, насколько он понятен стороннему наблюдателю. Инструмент нацелен на наших коллег от науки ― например, биологов и химиков ― которые не обладают опытом коммерческой разработки и соответствующего оформления кода. Он поможет в несколько кликов сделать репозиторий более читаемым и воспроизводимым.

Что происходит, когда GitHub берётся за собственную безопасность? Они пишут код для защиты кода — и активно используют для этого CodeQL. В этой статье команда Product Security Engineering рассказывает, как настроить масштабный автоматический анализ уязвимостей, зачем создавать свои пакеты запросов и как с помощью CodeQL находить ошибки, которые невозможно поймать обычным поиском по коду.

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

Разбираем, как писать масштабируемые и читаемые UI автотесты на Python с использованием паттернов PageObject, PageFactory и PageComponent. Разберем на атомы как устроены эти подходы, когда их применять и чем они отличаются. Всё это — на примере тестового проекта UI Course с CI/CD и наглядными отчетами в Allure.

Всех привествую, меня зовут Денис, я PHP Backend разрботчик

Я выступаю на хакатонах за команду https://жыбийрыр.рф/ и у нас была проблема что не было шаблона с которым мы могли спокойно приходить на хакатоны и не писать один и тот же код из раза в раз

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

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

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

Пытаясь сравнить популярность нескольких технологий разработки ПО, я столкнулся с парадоксом: данные Google Trends и количество GitHub-репозиториев показывали высокую популярность технологий, которые в реальной разработке давно не используются.

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

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

В этой статье разберём процесс написания API автотестов на Python, используя современные best practices. Кроме того, мы настроим их запуск в CI/CD с помощью GitHub Actions и сформируем Allure-отчёт с историей запусков. Цель статьи — не только показать, как писать качественные API автотесты, но и научить запускать их в CI/CD, получая удобные отчёты о результатах.

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

...

В этой статье я делюсь реальным опытом продвижения Open Source проекта на GitHub за 2 года. Мы развенчаем мифы о быстром наборе звезд и узнаем из моего опыта, как я на самом деле привлекал трафик и продвигал проект Wunjo. Поговорим о том, что реально работает для увеличения видимости на GitHub и как маркетологи, разработчики пет-проектов и владельцы продуктов могут применить эти методы для продвижения.

Хабр, привет! Меня зовут Барилко Виталий, я разработчик / директор / главный идеолог программы Управление IT-отделом 8 и работаю в компании Софтонит. Мы разрабатываем ПО для автоматизации ИТ-отделов. Сегодня хочу поговорить про conventional commits и про свой личный опыт работы с коммитами. На самом деле это бездонная тема, о которую сломано много копий. Кто-то пишет и делает коммиты так, кто-то эдак. В посте попробую поразмышлять о том, как делать не надо и о придуманных на этот счет правилах и договоренностях.

Начинающие (а иногда этим грешат и опытные) разработчики, не до конца понимают принципы создания и работы над коммитами в git. Тут имеется ввиду не механика и команды типа “git commit …”, а общие и глобальные вещи. Например:

1. А когда делать коммиты?
2. Что в них писать?
3. Есть ли какие-то общие правила для их создания?
4. Как не надо коммитить?

Если ты начинающий разработчик, то эта статья точно тебе пригодится. А если у тебя огромный опыт и ты думаешь, что тебя уже ничем не удивить, то… Не будем торопиться… Давай проверим?