Неудачное собеседование на позицию PHP-программиста

Началось всё вполне обычно:

1️⃣ рассказать о себе и увлечениях
2️⃣ немного про опыт (но дослушать почему-то не захотели)
3️⃣ кратко про компанию куда меня приглашают и условия
4️⃣ предупредили о тестовом задании

И тут внезапно выясняется, что
лайвкодинг будет проходить в… Word под запись экрана 😄
Да-да, тот самый Word, в котором обычно составляют различные документы.

В этот момент я понял, что в список сервисов для лайвкодинга смело можно добавить и его.
После этого я, признаться, немного завис.

📄 Задание включало:

• SQL - активные сотрудники и отделы (написать 2 запроса простой с отбором по диапазону возрастов и статусом и с Join и под запросом чтобы посчитать и отсортировать сотрудников по отделам, но без конкретной формулировки какой именно SQL).
Это я признаюсь сделал, однако ощущение ступора и не понимания зачем все остальное меня никак не отпускало, поэтому дальше не стал продолжать.

• PHP - транспонировать матрицу без дополнительного массива

• JS - 2 задания с setTimeout, одно из которых с подвохом

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

PS: Отдельное спасибо коллегам с прошлой работы за возникшее желание поразбирать эти тестовые задания потом вместе )

#php #собеседование #interview #разработка #опыт #it

AI Dev 2025 - мои заметки слушателя

Был на онлайн-конференции 14 октября. Формат понравился - вся информация прямо зашла, много практики. Ниже коротко по каждому докладу и что заберу в ежедневную работу, либо включу в свой план ближайшего внедрения в работу.

Что вынес в целом:
• AI ускоряет рутину, но качество решает контекст и архитектура
• Пайплайны важнее отдельных промптов - фиксируем шаги и метрики
• MCP и агенты - это уже про прод, а не игрушки

По докладам (то что возьму в работу или запланирую)

14:00 - AI Coding без боли
• Контекст как система: Memory Bank, чек-листы, готовые шаблоны
• Делаю свой «стартовый контекст» для проектов: цели, стиль кода, гайд по репо

14:45 - Feedback First
• Не просим «сделай идеально», а ставим цикл: сгенерируй - запусти - оцени - доработай
• Беру на заметку подход, при котором небольшие автотесты сразу в промпте

15:30 - Готовим MCP под задачи
• Свой набор MCP-серверов под домены проще поддерживать, чем «все-в-одном»
• План: вынести интеграции с Git, CI, Jira в отдельные MCP модули

16:15 - Кунг-фу контекст инжиниринга в энтерпрайзе
• RAG без чистых данных - боль. Нужны нормализация, версии, приватность
• Для больших кодовых баз - индекс по файлам, по коммитам и по доменам

17:00 - Как делают инструмент для AI разработки
• Принципы: наблюдаемость, идем от use-case к фиче, чек-лист готовности
• Заберу идею «минимального агента» под 1-2 сценария, а не универсального монстра

17:45 - Роль архитектуры во времена вайбкодинга
• Важно задавать границы,описывать интерфейсы, тесты - иначе ИИ плодит энтропию
• Акцент на портах и адаптерах - меньше утечек деталей внутрь домена
• Описывать будущую архитектуру проекта

18:30 - Панелька про рынок
• Ценятся те, кто умеют ставить задачи ИИ и отвечать за результат
• Рост спроса на инженеров, кто соединяют бизнес, данные и продакшн

Как применю у себя
• Laravel 12 + Vue 3: заведу repo-level контекст и Memory Bank в проекте
• Генерацию кода гоняю через минимальные Pest-тесты (пора переходить с PHPUnit) - цикл обратной связи прямо в промпте
• Выделю MCP для Git, Runner и Документации - один агент под релизные рутины (нужно освоить процесс построения своих MCP серверов, например на базе FastMCP)
• Введу чек-лист «готовности задачи для ИИ» - входные данные, критерии, метрики

Итог
• Конференция дала каркас, как перейти от рутинной и зачастую ручной работы и местами простого авто комплита к воспроизводимым пайплайнам
• Дальше - внедрение по шагам и метрики скорости и качества (тоже предстоит разработать)

Сайт события - https://ai-dev.live

#aidev #ai #developers #laravel #php #vue #rag #mcp #prompting #architecture

Я.Субботник по Go - мой короткий отчёт

О чём были доклады:
• Сеть и ядро. Показали как обходить узкие места на уровне ядра и что это даёт под большой нагрузкой. Я узнал как такие вещи вообще делают и почему важно оставаться в экосистеме Go.
• Сборщик мусора. Разобрали текущий GC и новый Green Tea – на слайдах всё наглядно, как метятся объекты и как происходит очистка. Забавный факт – автор назвал его так просто потому, что любит зелёный чай.
• KV-хранилища. Конкретные кейсы и выгоды использования. Загорелся идеей попробовать YDB в будущих проектах.
• Debug Tree. Как навести порядок в отладке под высокой нагрузкой и даже на проде – шаги операции видно как на ладони.

Немного про людей:
• Кофе-брейк зашёл отлично – познакомился с несколькими людьми, обсудили идеи и наметил для себя как переносить процессы и даже проекты на Go.

Что возьму в работу:
• Продолжу изучать возможности Go
• Поработаю с кэшем и попробую оценить YDB на своих тестах.
• Подумаю над оптимизацией процесса отладки на подобие того, что был показан на субботнике.

Итог:
День получился практичным и живым. Ушёл с понятным списком экспериментов и несколькими новыми контактами.

#Go #конференция #yandex #ЯСубботник #networking #KV #GC #DebugTree #ydb

💡 Совет по Laravel: Получение исходных атрибутов

Аксессоры Laravel позволяют преобразовывать атрибуты модели при их извлечении. Но иногда может потребоваться получить исходное значение. Laravel предоставляет специальный метод для этого: getRawOriginal 🚀

Конкретно данное расширение более не обновляется и недоступно в перечне расширений для Docker Desktop

Как и обещал, публикую текущую версию MCP сервера https://github.com/sleleko/leko-mcp

В планах попробовать вариант реализации на базе Laravel MCP https://laravel.com/docs/12.x/mcp

🗄 MySQL: как мгновенно очистить таблицу на 11 ГБ без боли

Внимание ❗️: предлагаемое ниже решение не для production баз

В одной из баз данных столкнулся с таблицей craft_blitz_elementfieldcaches весом 11 620 МБ, которую нужно было полностью очистить.

Как я определил вес таблиц?

Взвесил таблицы запросом:

SELECT table_name,         ROUND((data_length + index_length) / 1024 / 1024, 2) AS MB FROM information_schema.tables WHERE table_schema = 'roke' ORDER BY MB DESC LIMIT 20;

Получил результат:

+------------------------------------+----------+
| craft_blitz_elementfieldcaches     | 11620.97 |
| craft_elements_sites               |   816.38 |
| craft_blitz_elementcaches          |   707.72 |
| craft_blitz_elementqueries         |    86.27 |
| craft_elements                     |    37.67 |
| craft_changedfields                |    28.67 |
| craft_entries                      |    19.64 |
| craft_redirect_404_log             |    12.50 |
| craft_blitz_elementquerycaches     |     9.03 |
| craft_formie_submissions           |     8.27 |
| craft_searchindex                  |     7.95 |
| craft_revisions                    |     7.55 |
| craft_entries_authors              |     6.55 |
| craft_blitz_caches                 |     4.20 |
| craft_structureelements            |     3.16 |
| craft_redirect_hits                |     1.72 |
| craft_projectconfig                |     1.52 |
| craft_feedme_logs                  |     0.64 |
| craft_redirects                    |     0.52 |
| craft_blitz_elementqueryattributes |     0.42 |
+------------------------------------+----------+
20 rows in set (0.07 sec)

Казалось бы - TRUNCATE и готово. Но не тут-то было:
TRUNCATE на больших InnoDB таблицах может вызвать лавину блокировок и откат транзакций на несколько часов.
Батчевый DELETE - рабочий вариант, но медленный.

Есть элегантный трюк:

-- 1. Создаём пустой клон структуры
CREATE TABLE craft_blitz_elementfieldcaches_new 
  LIKE craft_blitz_elementfieldcaches;

-- 2. Атомарная подмена — занимает миллисекунды
RENAME TABLE 
  craft_blitz_elementfieldcaches     TO craft_blitz_elementfieldcaches_old,
  craft_blitz_elementfieldcaches_new TO craft_blitz_elementfieldcaches;

-- 3. Удаляем старую в фоне — приложение уже не при делах
DROP TABLE craft_blitz_elementfieldcaches_old;

Почему это работает:

RENAME TABLE - атомарная операция.
Приложение моментально переключается на пустую таблицу и продолжает работу.
DROP старой таблицы может идти сколько угодно - он уже никому не мешает.
Если есть внешние ключи - добавь перед rename:

SET FOREIGN_KEY_CHECKS = 0;
-- после rename вернуть = 1

Итог: 11 ГБ "исчезли" за секунды, сервис не заметил ничего.
Этот же приём лежит в основе таких инструментов как pt-online-schema-change и gh-ost.

Примечание: Чтобы в MySQL обновилась информация о весе проблемной таблицы понадобилось дополнительно выполнить

USE craft_db;
ANALYZE craft_blitz_elementfieldcaches;

#mysql #devops #performance #backend #craftcms #blitz_cache #blitz