Какие mcp сервера посоветуете? Я пока остановился на ctx и firecrawl, остальные кажутся бесполезными :(

Открыл PR в php-src, добавляющий для BackedEnum нативный метод values, потому что часто вижу в проектах создают трейт под это дело
RFC пока не делал, подожду реакции от internals

Если тебе кажется удобной такая фича, поставь пж 👍 на мр 🙂

Пока идет обсуждение моего RFC в пыху, узнал, что array_column может доставать не только колонки массива, как казалось бы, но и свойства объектов:

enum Status: string {
    case Active = 'active';
    case Inactive = 'inactive';
    case Pending = 'pending';
}

// What does self::cases() return?
var_dump(Status::cases());
// array(3) {
//   [0]=> enum(Status::Active)      // <- These are OBJECTS
//   [1]=> enum(Status::Inactive)    // <- Not arrays
//   [2]=> enum(Status::Pending)
// }

// Each case object has public readonly properties:
$case = Status::Active;
echo $case->value;  // "active"  (string - the backing value)

// array_column can extract these properties!
$values = array_column(Status::cases(), 'value');
var_dump($values);
// array(3) {
//   [0]=> string(6) "active"
//   [1]=> string(8) "inactive"
//   [2]=> string(7) "pending"
// }

А вы знали про такое?

Вы знали, что у php-fpm можно получить вот такую статистику работы, в том числе по пуллам?

URL эндпойнта можно менять в конфиге (и в nginx'е обновлять локейшн), а формат можно менять в query параметрах (json/html/text)

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

Дока здесь

Микролайфхак: git mv

Если перемещать файлы обычным mv, git вообще не понимает, что произошло. На примере с картинки он видит это как:

- файл console будто удалили
- новый config/console будто появился из ниоткуда.

История теряет контекст, blame обнуляется, diff выходит огромным

git mv делает то же самое перемещение, но еще и сообщает git'у:
«Это тот же файл, просто теперь он здесь».

И в итоге в diff появляется аккуратное renamed, а не двойной дифф, который занимает весь экран

Справедливости ради шторм так и делает под капотом, а вот при работе в других средах надо иметь ввиду. Ну или сказать llm'ке, чтоб имела ввиду 🙂

Топ видос, как вы считаете? Боюсь представить сколько сил потребовалось чтоб снять его)

Как устроен PHP 🐘: фундаментальное знание для инженеров

В этом видео мы шаг за шагом разберём, как из исходного кода рождается процесс.
Пройдем путь от компиляции к интерпретации, от fork() и execve до php-fpm.

🔹 Подходит тем, кто хочет понять, как реально работает PHP и интерпретируемые языки в Linux.
🔹 Без магии — только системная логика и живая демонстрация в терминале.

Таймкоды:

00:09 Введение.
01:32 Классическая схема. Компилируемые языки.
02:29 Альтернативный подход. Интерпретируемые языки.
04:16 Подведём итог.
04:39 Погружение.
04:54 PHP как язык.
05:19 PHP как интерпретатор.
05:46 SAPI (Server API).
15:28 Ядро (Zend Engine).
16:03 Набор расширений (Extensions).
16:44 Резюме по интерпретатору.
17:38 Практика. Подготовка демонтстрационного стенда.
18:15 CGI и Apache2.
22:19 Принцип запуска программ в терминале.
29:56 Общий принцип работы с вводом и выводом в Unix-подобных системах.
35:39 CLI профиль.
38:54 Возвращаемся к CGI и Apache2.
47:45 Fast CGI.
54:54 Итог.

Хотите на собесе рассказать как ускорили запрос в 60 раз?

Недавно впервые споткнулся об JIT в Postgresql:

Был обычный SELECT по партиционированной таблице на ~390млн строк, причем WHERE по индексам
Но на боевой базе жесть как тормозил
Конечно запустил EXPLAIN ANALYZE, а там JIT занимает 16 секунд (!) из 16.2
Видимо из-за фильтров/кастов/количества партиций планировщик насчитал огромную стоимость запроса, хотя на практике это не подтвердилось

Решается это супер просто - достаточно перед запросом прописать SET jit = off;
После этого запрос стал выполнятся за ~250ms

Кстати, можете интерактивно поизучать план этого запроса вот здесь (но я выкинул из плана 388 партиций из 390)

Сделал видос по сисдизу

Как вам такой формат?
Или собесы по пхп ванлов?)

Замутил репозиторий, демонстрирующий шардирование в стеке PHP, Symfony, Postgresql: https://github.com/savinmikhail/sharding-example

Там есть 2 консольные команды демонстрирующие хэш и directory based шардирование. Соответственно первый вариант полностью прозрачен для приложеньки, а второй вариант - нет, но зато поможет с изоляцией горячих ключей

Координатор - Citus

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

Выложил второй (из планируемых 4х) видос по сисдизу
Заодно сделал репозиторий, демонстрирующий репликацию в стеке Postgresql + PHP (Symfony)
Можете потыкать, он в целом аналогичен примеру с шардированием

Есть относительно популярный вопрос на собесах - про множественное наследование в пхп

Тут есть пожалуй три уровня ответа:

1) Трейты. Это все знают

2) Интерфейсы могут наследовать множество других интерфейсов:

interface Foo extends Bar, Baz

С этим уже мало кто сталкивался

3) Класс наследует константы от интерфейса. Класс может имплементить много интерфейсов. Значит класс может наследовать константы от множества интерфейсов. Получается множественное наследование, но только для констант. При этом если константы будут одинаково называться, пхп не будет решать конфликт, просто кинет фатальную ошибку
Вот пример, чтоб поиграться - https://onlinephp.io/c/9c75c

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

Зарелизил наконец-то ролик про кэш в сисдизе

Если упустил что-то важное, дайте знать 🙂

Новое видео про распределенные транзакции, saga pattern, tcc, 2pc, eventual & strong consistency.
И немного про transactional outbox, но про него будто бы из каждого утюга слышно 🤷‍♂️

Неочевидное поведение variadic + named arguments

Вот люблю пхп и ненавижу одновременно - постоянно стреляет мне в колено

Следите за руками

С 8х версий появились именованные аргументы, и с тех пор я считал, что для variadic аргументов их нельзя применять. Логично же, что имя одно, а аргументов много, не должно работать

Но на собесе недавно мне сказали, что я не прав

Я проверил, и правда, такой код будет работать:

function foo(string ...$values): void
{
    var_dump($values);
}

foo(value1: 'foo', value2: 'bar', abcdf: 'baz');

На экран выведется

[
    'value1' => 'foo',
    'value2' => 'bar',
    'abcdf' => 'baz',
]

То есть применять связку variadic + named arguments можно, но при это само имя для такого параметра может быть абсолютно рандомным (главное чтоб валидным) и оно становится ключом ассоциативного массива внутри.

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

Но! На следующий день наполучал ишуей на тему, что именованные аргументы не работают для variadic.

Думал у меня шизофрения, но оказалось, что не работает именно для встроенных функций (не uiserland):

sprintf(format: $message, values1: $property);

Такой вызов приведет к ошибке:

Fatal error: Uncaught Error: Unknown named parameter $values1

При этом phpstan это не подсвечивает:
https://phpstan.org/r/0e634ee6-0d95-4864-a6f6-badd72141320

Я завел в phpstan ишую на эту тему, и в своем правиле разграничил userland от native функций

Но мейнтейнер пхпстана отметил, что некоторые нативные функции все таки принимают именованные аргументы для variadic

Интересно, как глубока кроличья нора?

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

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