Выложил видос с одним из моих старых тех. собесов, который завершился оффером на 300к.

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

Ссылка 👇
https://youtu.be/a58yv8GQiIw

Под предыдущим видео было много комментариев, шо вопросы слишком рандомные и поверхностные, поэтому сделал видос, где большую часть времени (35 минут) мы с интервьюером разбираем бизнес задачу

Мне лично нравятся собесы, где не блиц опрос по 100 темам (как это в ВК, например), а вы решаете одну крупную задачу - будь то рефакторинг кода, system design, или проектирование, как вот здесь

Надеюсь, вам тож такой собес зайдет

Ссылка 👇
https://youtu.be/4qV7G1tR21g

Shared Memory vs Redis: микросекунды против миллисекунд

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

Привычным решением было бы использовать Redis.
Там затраты были бы около 0.10 - 0.12 ms, если не надо открывать TCP соединение заново.
Если надо - то уже около 0.30 ms (тык тык тык).
И это если Redis стоит на локалхосте, иначе затраты могли бы вырасти до 3 порядков

Подход с разделением оперативной памяти в результате испытаний по моему бенчмарку дал 27 µs (~0.03 ms) задержки на передачу данных, что в примерно в 4 раза быстрее, чем Redis с persistent connection

В php оказалось готовое API и для семафоров, и для мьютексов, и для самой shared memory:

<?php

$key = 0xDEADBEEF;
$size = 1024;

$shm = shmop_open($key, 'c', 0666, $size);
$mutex = new SyncMutex('crypto_rate_mutex');

$mutex->lock();
shmop_write($shm, $payload, 0);
$mutex->unlock();

Есть и другие варианты IPC, но показались неподходящими

Как итог, сэкономили около 0.07 ms 😅. В обычном бэкенде и подумать смешно о таких оптимизациях, но в контексте приложений, где счет идет на миллисекунды помноженные на тысячи операций в день - это профит!

Новый видос!
https://youtu.be/rtoLYuXtLGk?si=6Zfrk7go31scHSku

Написал обзор на преимущества zsh над bash, которые я нашел для себя за время использования
Буду рад услышать ваши лайфхаки на эту тему !

А как вы относитесь к graphql?
❤️ - мне нравится, особенно типизация на фронте
💩 - мне не нравится, особенно генерация схемы на бэке
🤔 - что это?

Итак, по результатам опроса 44% респондентов используют AAA pattern при тестировании
Я обычно отделяю части комментариями, хотя кто-то просто пустыми строками, но периодически сам забываю, периодически команда приносит тесты с несколькими act-assert
Поэтому запилил правило для ректора на этот счет, может и вам будет полезно

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

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

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

Благо симфа и здесь легко расширяется, поэтому я быстренько навайбкодил написал бандл, позволяющий смотреть содержимое ответа. Аналогов найти я не смог(
По умолчанию работает для json- и text- подобных mime-типов, и обрезает слишком большие ответы (настраиваемо).

Если разделяете мою боль - велком

Новый тех на канале!
Было 3 задачи: первая это кодревью php кода, 2 другие - проектирование баз данных

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

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

Какие 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)