🌿 Про ссылки в коде PHP

Наткнулся в Твиттере X на пост, где говорилось, что PHP поддерживает ссылки прямо в коде. «Что-то странное...» подумал я 🤔

Проверил, действительно работает, интерпретатор не выдаёт каких-либо ошибок:

https://predvoditelev.ru
echo 'Hello!';

Но тут уже подсветка синтаксиса как бы намекает... всё просто ­— это не ошибка и не магия, это метка для оператора goto + комментарий.

goto использовал последний раз, по-моему, ещё во времена, когда писал программы на QBasic, на PHP никогда к нему не прибегал, поэтому и синтаксис в новинку.

На практике это не нужно (никто же не использует goto?), а вот в какой-нибудь викторине по PHP был бы интересный вопрос 🙂

🌿 Про политику NO LLM

В кодексе поведения языка программирования Zig прописана политика «Strict No LLM / No AI»:

• Не использовать LLM для тикетов.

• Не использовать LLM для PR.

• Не использовать LLM для комментариев, включая переводы.

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

😡 Боль

Зачем мне делать ревью кода от агентов или читать полотно текста по обсуждаемому вопросу? Если взялся что-то делать — делай, разбирайся и экономь чужое время, а не подкидывай дополнительной работы.

Иногда доходит до того, что общение сводится к «вот ответ ChatGPT:» и пару экранов текста. Я и сам могу пообщаться с ChatGPT или нагенерить кода, чтобы его поревьювить. Другой разработчик в такой ситуации не нужен.

✅ Как правильно?

Используя LLM, разработчик должен:

• проверить ВЕСЬ код / текст;

• понимать ВСЁ в этом коде / тексте;

• адаптировать код / текст под контекст использования.

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

Безответственное использование LLM неэтично и должно всячески порицаться профессиональным сообществом.

🌿 Про PHPeople

На вопрос «Каких активностей вам не хватает в русскоязычном PHP-сообществе? Чего хотелось видеть чаще, а что лучше и не выпускали бы?», который был задан в рамках опроса PHP-сообщества по итогам 2024 года, вторую строчку после «Оффлайн-мероприятия» занял вариант «Онлайн-контент».

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

🖼 О платформе

PHPeople полностью работает внутри телеграма. Отдельная группа с темами для первого уровня подписки и отдельные группы с темами для каждого автора.

Подключение, оплата, управление подписками осуществляется через телеграм-бота @phpeople_bot.

⭐️ Для подписчиков

Платформа работает по модели двухуровневой подписки.

Первый уровень (обязательно)
150 ₽ / мес.

• Доступ к общему чату: общение с другими подписчиками и всеми авторами.

• Авторский контент — часть контента авторы на своё усмотрение публикуют для первого уровня подписки.

• Сводки по движениям внутри авторских групп.

Второй уровень (опционально)
150 ₽ / мес. за каждого автора

• Доступ к закрытому авторскому контенту.

• Доступ к закрытому чату с конкретным автором и его подписчиками.

⭐️ Для авторов

Возможность монетизировать свой контент и продвигать свои группы в рамках общего чата.

✍️ Авторы

На текущей момент на платформе заявлены 6 авторов:

• Олег Мифле
• Валентин Удальцов
• Алексей Гагарин
• Кирилл Несмеянов
• Дмитрий Дерепко
• Сергей Предводителев

Меня тоже позвали. Пока планирую делать там ранний доступ к заметкам с этого канала (уже доступны пару заметок 😉 ), возможно что-то описывать из процесса разработки Yii3. Ну и можно пообщаться в рамках закрытого чата, если это кому-нибудь нужно 😀

Первое впечатление о PHPeople у меня двоякое, сформулирую мысли и позже сделаю отдельный пост. Но надеюсь, всё получится!

▶️ Стрим про PHPeople

Впервые PHPeople представили сообществу 11 декабря на канале Пых, а 16 декабря в 19:00 пройдёт стрим с организаторами и авторами, которые расскажут о проекте и ответят на возникшие вопросы.

Залетайте на VK Видео или YouTube, где удобнее 🙂

🌿 Про докер и SSL-сертификаты Let's Encrypt в Angie

В начале года я написал статью 📗 Настройка SSL-сертификатов Let's Encrypt в Angie.

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

Решение простое — сделать том для создаваемых сертификатов, чтобы они сохранялись при пересоздании контейнера с Angie.

Добавляем в конфигурацию Angie путь к каталогу для хранения сертификатов и ключей:

acme_client_path /var/project/angie-acme;

И соответствующим образом изменяем compose-файл:

services:
  angie:
    image: docker.angie.software/angie:1.8.0
    # ...
    volumes:
      # ...
      - angie_acme:/var/project/angie-acme

volumes:
  angie_acme:

Статью в блоге обновил. Посетители из поиска будут предупреждены 🙂

🌿 Про события pull_request и pull_request_target в GitHub Actions

В GitHub Actions, системе, обеспечивающей CI/CD на GitHub, есть два очень похожих события, которые запускают рабочие процессы (workflow): pull_request и pull_request_target.

Оба события запускают рабочий процесс при активности в PR (создание, добавление коммита, …). Но между ними есть существенная разница.

⭐️ pull_request

• Использует конфигурацию рабочего процесса (YAML-файл) из ветки PR.
• Запрещает запись в репозиторий, если PR сделан из форка.
• Запрещает доступ к секретам, если PR сделан из форка.

⭐️ pull_request_target

• Использует конфигурацию рабочего процесса из основной ветки репозитория, как правило это master или main (дикость какая 🫤).
• Разрешает запись в репозиторий для PR из форка.
• Разрешает доступ к секретам для PR из форка.

Очевидно, что такое разделение событий сделано в целях безопасности.

При использовании pull_request_target важно убедиться, что предлагаемый в PR код не выполняется, иначе злоумышленник сможет сделать PR и получить доступ к секретам репозитория.

По умолчанию лучше всегда использовать pull_request и только в случаях, когда его возможностей не хватает, аккуратно использовать pull_request_target.

Например, в репозиториях Yii3 в CI для юнит-тестирования и статического анализа используется pull_request, а для рабочего процесса, который запускает Rector и PHP CS Fixer — pull_request_target. В данном случае это безопасно, так как мы не выполняем предлагаемый в PR код, а сами меняем его и делаем коммит с изменениями.

И ещё один момент. Если вы создаёте PR с рабочим процессом, который запускается по pull_request_target, то в рамках этого PR он не выполнится (помним, что pull_request_target берёт конфигурацию из ветки по умолчанию), а вот уже после слияния, будет выполняться в будущих PR.

⭐️ Полезные ссылки

• Документация по GitHub Actions
• Документация по событию pull_request
• Документация по событию pull_request_target
• Серия статей «Keeping your GitHub Actions and workflows secure»

🌿 Про «свои проекты»

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

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

Вот сегодня прочитал в канале Леонида Черненко «Делаем продукт»:

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

Подозреваю, что такая же ситуация практически у всех.

А может и не нужны все эти свои проекты? Это просто навязанное социумом желание успешного успеха? 🙂

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

🌿 Про фиксацию версии инструментов для проверки качества кода

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

На примере Composer в PHP рассмотрим три варианта:

1) Никак не фиксировать — *
2) Фиксировать мажорную версию — ^3
3) Фиксировать конкретную версию — 3.25.1

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

⭐️ Второй вариант с фиксацей только мажорной версии самый распространённый. Но с ним есть проблема: в минорной версии могут внести изменения, которые сломают тесты.

Например, в Infection (фреймворк для мутационного тестирования) в версии 0.30.3 добавили новый мутатор ReturnRemoval, который удаляет выражение return и проверяет — сломались ли тесты. Допустим, в проекте у нас стоит ограничение версии ^0.30 и вчера, когда была актуальной версия 0.30.2, мутационное тестирование успешно проходило, а сегодня, после релиза 0.30.3, CI неприятно засветился красным ❌

⭐️ Вот тут-то нас спасёт третий вариант — фиксируем конкретную версию инструмента и у нас ничего внезапно не сломается. При обновлении версии инструмента будем исправлять и появившиеся проблемы.

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

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

🌿 Про Free Software, Open Source Sofware и FOSS

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

Часто можно встретить термины «Free Software», «OSS» и «FOSS». Все обозначают ПО с открытым исходным кодом, однако есть нюансы 🤓

⭐️ Free Software | Свободное ПО

Понятие «Free Software» было предложено Ричардом Столлманом в 1986 году. В его основе лежит идея свободы использования программы для пользователя. ПО может называться свободным, если даёт своим пользователям все перечисленные возможности:

• свобода 0: выполнение программы в любых целях;
• свобода 1: изучение и изменение программы;
• свобода 2: распространение копий программы;
• свобода 3: распространение изменённых версий программы.

Свободы 1 и 3 подразумевают, что исходный код программы должен быть открыт.

Актуальная версия определения «Free Software» на русском языке доступна на сайте фонда свободного ПО.

⭐️ Open Source Software (OSS) | Открытое ПО

Термин «Open Source Software» (OSS) был предложен в 1998 году Эриком Рэймондом и Брюсом Перенсом после выпуска исходного кода браузера Netscape. В отличие от «свободного ПО», здесь упор делается на технические моменты и практическую пользу. «Открытое ПО» должно соответствовать следующим критериям:

1. Свободное распространение ПО как самостоятельно, так и в составе другого ПО.

2. Доступный исходный код.

3. Разрешение на модификацию ПО и распространение на совместимых условиях.

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

5. Никаких запретов на использование кому-либо.

6. Никаких запретов по сфере использования ПО.

7. Лицензия распространяется на всех, кому поставляется ПО, без необходимости оформления дополнительной лицензии.

8. Лицензия не зависит от того используется ли ПО само по себе или в составе другого ПО.

9. Лицензия не накладывает ограничений на другое ПО, использующее данное ПО.

10. Положения лицензии не должны основываться на какой-либо технологии или интерфейсе взаимодействия.

Актуальная версия определения «Open Source» доступна на сайте некоммерческой организации Open Source Initiative.

⭐️Free and Open Source Software (FOSS) | Свободное и открытое ПО

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

Чтобы не спорить на пустом месте, появился термин FOSS (по одним источникам в конце 1990х, по другим ­­— в начале 2000х годов). FOSS отражает одновременно и идейность свободного ПО и практичность открытого ПО.

#инфопузырь

☕️  Инфопузырь #12 (Декабрь 2025)

Рубрике «Инфопузырь» — 1 год 😎. Это единственная постоянная рубрика в этом канале, посты выходят стабильно раз месяц. В новом году продолжим.

⭐️ Видео

Враг у ворот: Что защитит наш код от ИИ? — доклад Егора Бугаенко на закрытой конференции Банка России об угрозах, которые несёт внедрение ИИ в процесс разработки, и способах защиты от них.

Scaffolder: создаём и обновляем репо за пару минут — стрим Валентина Удальцова об инструменте для создания и поддержки репозитория в актуальном состоянии (CI, лицензия, composer.json и т. д.). Запись доступна в базовой подписке PHPeople.

F87, F88, F89 — философия программиста от Егора Бугаенко. Ответы на вопросы о программировании, архитектуре, менеджменте, политике и жизни программиста.

От промпта к продакшену: системный подход к AI-разработке — доклад Павла Бучнева на 7 сезоне PHP-подлодки о методологии разработки с использованием нейросетей: промт-инжиниринг, контекст-инжиниринг и вот это вот всё. Доступ к записи доклада можно получить на сайте конференции.

Vertical Sliced архитектура — доклад Виталия Кануникова об архитектурном подходе «вертикальные слайсы» и его использовании совместно с другими подходами и шаблонами проектирования.

Vertical Slice Architecture — выступление Джимми Богарда с докладом о нюансах практического применения архитектурного подхода «вертикальные слайсы».

⭐️ Статьи

I can’t recommend Grafana anymore — размышления инженера из Германии о Grafana в части управления продуктом (серьёзных изменений много и происходят они часто).

Что такое свободная программа? — актуальная версия классической статьи Ричарда Столлмана, описывающая в деталях что же такое «свободное ПО».

Почему «открытый исходный текст» не передает понятия «свободная программа» — статья подробно раскрывающая ключевые отличия между «свободным ПО» и «ПО с открытым исходным кодом».

Making GitHub Pages Work With Jekyll 4+ and Any Theme and Plugin — статья рассказывает как собрать сайт для GitHub Pages, используя актуальную версию Jekyll и любые плагины/темы к нему.

Vertical Slice Architecture — статья Джимми Богарда об архитектурном подходе «вертикальные слайсы». Именно Джимми в своё время сформулировал и популяризировал этот термин.

IT-2025: Реквием по здравому смыслу — статья сеньор-разработчика о том, насколько всё плохо в найме, катострофическом снижении эффективности работы программистов, падении качества разрабатываемых продуктов и влиянии ИИ на все эти процессы.

Кричащая архитектура (оригинал) — статья Роберта Мартина от 2011 года о том, что хорошая архитектура должна был основана на сценариях использования, а содержимое папки с исходным кодом должно «кричать» о своём предназначении, а не о деталях реализации.

🌿 Про релиз Yii3

В последние дни 2025 года мы с командой разработчиков Yii3 успели всё-таки доделать лендинг, сделать ещё одно демо-приложение, настроить генератор сайта с документацией, запустить API-документацию, подготовить анонс и сделать релиз 31 декабря, под ёлочку 🎄

Большое событие, результат многолетней разработки. На Yii3 было потрачено огромное количество человекочасов. Yii3 впитал в себя многолетний опыт разработки и практического использования его предшественников — первой и второй версий. Результат, на мой взгляд, вышел классный, мне нравится 🙂

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

Но мои ожидания от всей этой движухи с Open Sourсe, конечно, сильно разошлись с реальностью. Ключевое — «никто никому ничего не должен». Каждый решает свои задачи, которые вообще не факт, что корелируют с целями проекта. Сегодня интерес есть, завтра интереса нет. И это нормально.

За громким «развивается сообществом» скрывается минимальное финансирование через пожертвования, которого, очевидно, не достаточно, чтобы полноценно кто-то работал над фреймворком.

Какое будущее ждёт Yii3: обретёт ли он популярность, будет ли его использовать бизнес или этот фреймворк останется уделом энтузиастов и будет потихоньку умирать?

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

Тем не менее, шансы есть, хоть и не большие. Возможно, удастся выстроить какую-то схему монетизации. Может быть кто-то затащит это в бизнес. А может появятся энтузиасты, которым будет интересно поддерживать и развивать фреймворк. Время покажет ⌛️

🌿 Про владельцев FOSS-проектов

Недавно в чате Yii3 задали вопрос «Yii ­— это китайский фреймворк или русский?». Давайте посмотрим на этот вопрос шире — кого вообще можно назвать владельцем свободного программного обеспечения?

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

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

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

⭐️ Экспертиза — профессиональные компетенции поддерживать и развивать проект. Это ключевое и самое важное.

⭐️ Репутация — пользователи должны доверять проекту, чтобы делать свой выбор в его пользу среди аналогов.

Получается, у кого экспертиза и репутация, тот и владелец. Верно? 😏

PS Если у проекта нет конкурентов, то репутация не важна. Но с плохой репутацией быстрее появятся аналоги.

🌿 Про проблему обновления состояния пакетов

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

• структура папок;
• конфигурация CI;
• конфигурация тестов, статанализа и других инструментов;
• файл лицензии;
• и так далее...

🖼 Yii3 и 💙 Typhoon — яркие примеры подобных проектов.

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

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

Например, в Yii3 это yiisoft/package-template. Мы создаём новый репозиторий на базе шаблона, затем вручную дорабатываем его: прописываем название пакета, указываем необходимые версии зависимостей и так далее.

Обновление же существующих пакетов происходит полностью вручную. Например, поднимая минимальную версию PHP, нужно: изменить зависимость в composer.json, обновить конфигурацию CI, обновить README и т. д.

Но можно пойти другим путём. Перед Новым годом Валентин Удальцов сделал Scaffolder, инструмент для подготовки нового или обновления существующего репозитория в проектах Typhoon и Thesis.

Суть Scaffolder заключается в декларативном описании состояния проекта, к которому инструмент приводит содержимое. Это позволяет автоматизировать обе задачи: и создание нового пакета и обновление существующего.

Мне крайне понравилась эта идея и я решил её «творчески переработать». Что из этого вышло — в следующей заметке 🙂

🎁 PHP Scaffolder Library 0.1

Посмотрев стрим Валентина Удальцова «Scaffolder: создаём и обновляем репо за пару минут» и изучив его Scaffolder, захотел сделать себе так же 🙃

Основная польза Scaffolder — решение проблемы обновления состояния пакетов.

Я выделил и переработал ядро в отдельную библиотеку vjik/scaffolder и сделал шаблон vjik/scaffolder-template, на базе которых уже можно создавать инструменты, заточенные под конкретный проект.

Основные понятия:

• Факт — класс для получения некой информации. Внутри данные можно получить из текущих файлов проекта или запросить напрямую у пользователя.

• Изменение — класс, описывающий некое состояние в проекте. Например, как должен выглядеть composer.json или какой файл лицензии должен быть в корне проекта.

• Параметры — данные, которые используются внутри фактов и/или изменений. Параметры можно задать по умолчанию, передать через командную строку или задать на уровне проекта.

Есть готовый пример — PHPTG Scaffolder, это scaffolder для проекта ❤ PHPTG. Содержимое:

• Change/ — классы PHPTG-специфичных изменений,
• Facts/ — классы PHPTG-специфичных фактов,
• changes.php — список изменений,
• facts.php — список PHPTG-специфичных фактов,
• params.php — параметры по умолчанию,
• run.php — точка входа в приложение,
• scaffolder.php — параметры уровня проекта (инструмент используется и для своего репозитория тоже).

Для удобства использования, заворачиваем наш Scaffolder, настроенный под конкретный проект, в докер-образ (см. Dockerfile) и используем уже его. Пример:

docker run \
  --volume .:/project \
  --user $(id -u):$(id -g) \
  --interactive --tty --rm --init \
  ghcr.io/phptg/scaffolder:latest

Александр Макаров предложил также использовать PHP Scaffolder Library для написания визарда, создающего шаблон приложения Yii3, запросив у пользователя, что именно он хочет видеть (web/API/console, какая БД и т. д.). На первый взгляд, библиотека отлично подходит для этого.

🌿 Про .PHONY в Makefile

В мире PHP, да и не только, привыкли использовать Makefile для описания и выполнения задач. Но это уже побочный эффект, основная цель — описать инструкции для сборки файлов.

По умолчанию make интерпретирует названия команд install, up, down (в терминологии make — цели) как имена файлов и проверяет: если файл с таким именем существует, то ничего выполнено не будет.

install:
    # ...
up:
    # ...
down:
    # ...

Например, если мы создадим файл install, а затем запустим make install, то ничего не произойдёт, а в терминал будет выведено сообщение:

make: 'install' is up to date.

Чтобы make не проверял существования файла, а сразу выполнял команды, существует специальная цель .PHONY (документация), которая описывает цели, для которых проверка отключается. Допускается как в рамках одной .PHONY описать несколько целей, так и использовать несколько .PHONY. Например:

install:
    # ...
.PHONY: install

up:
    # ...
down:
    # ...
.PHONY: up down

.PHONY очень часто можно заметить в Makefile (например, в скаффолдере Пыха). Кто-то добавляет его осознано, чтобы 100% исключить конфликты, у кого-то просто так исторически сложилось.

Но в PHP-проектах практически никогда нет файлов, идентичных названиям целей, поэтому я не вижу смысла добавлять .PHONY в этом случае. Пользы он не принесёт, а Makefile становится из-за него очень «шумным».

Вообще, инструменты надо использовать по назначению. Существует куда более удобный Task, но у make есть одно неоспоримое преимущество — он есть везде. Поэтому для публичных проектов зачастую приходится делать выбор в его пользу 🤷‍♂️

🌿 Про AGENTS.md

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

Можно было бы опиcать всё это в файле README, но лучше выделить отдельно, так как не всё, что должно быть в README, нужно агентам и наоборот, не всё что нужно агентам, нужно показывать в README для пользователей/разработчиков.

Агентов много и чтобы стандартизировать место хранения общего контекста и инструкций придумали файл AGENTS.md и даже сайт сделали. К файлу единственное требование — формат Markdown.

В настоящее время AGENTS.md продвигается фондом Agentic AI, в который входят Anthropic, Google, Microsoft, OpenAI и другие крупные игроки на рынке ИИ-агентов.

🤖 Поддержка агентами

Многие агенты уже сейчас по умолчанию читают файл AGENTS.md, например, Codex, Jules, Cursor и др.

А вот Claude Code читает пока только свой индивидуальный CLAUDE.md и в настройках это изменить нельзя. Тикет на поддержку AGENTS.md висит с 21 августа, ждём-с. В качестве временного решения можно в CLAUDE.md добавить строку:

@AGENTS.md

Благодаря этой инструкции Claude Code подключит файл AGENTS.md и будет использовать его.

⭐️ Использование в проектах

Более 60 000 проектов на GitHub уже используют AGENTS.md. Я ранее использовал только в приватных проектах, но в недавно выпущенной PHP Scaffolder Library впервые добавил AGENTS.md в публичный проект 🙂

🌿 Про ежегодный опрос по PHP

Запущен ежегодный опрос PHP-сообщества по итогам 2025 года. В этот раз подготовкой занимались ребята из Live PHP, за что им спасибо 🙏

Ежегодный опрос, на мой взгляд, крайне полезная вещь. Можно посмотреть чем живёт сообщество. Какие версии PHP, инструменты и фреймворки используются? Какие статьи/видео оказались полезны? Какие источники информации важны для большинства? Без вопросов об ИИ тоже никуда.

По итогам 24 года опрос прошли 1207 разработчиков. Давайте в этом году увеличим это число!

⚡️ Пройти опрос

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

Итоги опроса будут опубликованы на phpcommunity.ru. Результаты предыдущих опросов: 2024, 2023.

🌿 Про SPDX и REUSE

Заметил, что в некоторых репозиториях в файлах встречаются аннотации с префиксом SPDX-, например:

# SPDX-FileCopyrightText: 2024 Carmen Bianca BAKKER <carmenbianca@fsfe.org>
# SPDX-License-Identifier: GPL-3.0-or-later

Стало интересно, что это и зачем 🧐

System Package Data Exchange (SPDX) — открытый стандарт для описания и обмена информацией о ПО в части лицензирования, авторства и интелектуальной собственности.

SPDX включает в себя:

• саму спецификацию;
• список лицензий и однозначных идентификаторов для них;
• инструменты и библиотеки для работы с документами SPDX и списком лицензий SPDX.

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

Машиночитаемость SPDX-формата обеспечивает автоматизацию проверки и управления лицензиями ПО.

Попробовал добавить SPDX и REUSE в свой небольшой проект GitHub Lookup Next ID Utility. Прописал аннотации в github-lookup-next-id, добавил REUSE.toml и лицензию в папку LICENSES. Старый файл лицензии (LICENSE.md в корне) оставил, так как его читает GitHub.

Линтер REUSE (reuse lint) теперь говорит, что проект полностью соответствует спецификации:

# SUMMARY

* Bad licenses: 0
* Deprecated licenses: 0
* Licenses without file extension: 0
* Missing licenses: 0
* Unused licenses: 0
* Used licenses: BSD-3-Clause
* Read errors: 0
* Invalid SPDX License Expressions: 0
* Files with copyright information: 7 / 7
* Files with license information: 7 / 7

Congratulations! Your project is compliant with version 3.3 of the REUSE Specification :-)

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

🖼 Стрим «Обзор релиза Yii3» на CutCode

Данил Шуцкий организовал на канале CutCode стрим про Yii3 и позвал в гости меня и Александра Макарова.

Предварительно план такой:

• обсудим почему Yii3 получился именно таким каким получился и как шла его разработка;

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

• ответим на вопросы зрителей (уже можно задавать в комментариях к анонсу).

▶️ Трансляция

22 января, 19:00 мск
YouTube | VK Видео

Приходите посмотреть/послушать и задать вопросы 🙂

🌿 Про технический видеоконтент

Довольно много полезного авторского контента на технические темы сейчас выходит в формате видео. И мне это не очень нравится 🙂

❌ Время на просмотр

Нужно тратить время на то, чтобы посмотреть видео полностью, даже если часть информации не интересна или уже известна.

Перемотка черевата тем, что можно пропустить что-то важное и/или интересное.

Просмотр на скорости x2 помогает, но не сильно. Это всё равно очень долго в сравнении с просмотром статьи.

❌ Сложно искать информацию

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

Тексты в этом плане гораздо лучше — можно быстро пролистать статью или воспользоваться поиском.

❌ Сложно копировать информацию

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

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

✅ Можно увидеть то, о чем автор и не думал

Но не всё так плохо с видео. У них есть один огромный плюс: можно увидеть то, что автор и не хотел показывать.

• Автор не проговаривает какую-то информацию, подразумевая, что все это знают, но делает это в видео.

• Автор показывает весь процесс в деталях и можно заметить что-то полезное, какие-то приёмы работы.

⭐️ Заключение

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

А что предпочитаете вы — посмотреть видеоролик или прочитать статью?