Всем любителям стартапов... Блять... Это ГЕНИАЛЬНО!!!!!!!! Просто феерично гениально!!!

Нано-технологии, умные дома, умные сервисы.... Зачем это всё... Продавай камни, которые надо бросать в яму!!!! 👍

А как часто дымится ваше "кольцо подвижности"? 😂😂😂😂😂

Сегодня у меня немного праздничное событие. Я наконец-то смог перевести один из своих пет-проектов на HttpClient Symfony с Guzzle + смог настроить МокМодуль для Codeception под все это дело.

Но для начала немного предыстории...

На работе в основном используются Symfony версий 4, 5 и 6. 7-ки пока что нигде еще в продуктах нету. Поэтому там везде в Codeception функциональных тестах используется и прекрасно работает Phiremock. И всё бы было бы отлично, если бы не одно НО...

Написал я новый пет-проект на Symfony 7.2 и Codeception 5.2. Весь функционал написал, пошел писать архитектуру автотестов и тут вдруг неожиданно выясняется, что Phiremock не хочет работать с Symfony 7.2. На текущий момент для него максимальная версия - это 6.4 и чтобы его проапгрейдить до состояния совместимости с Symofny 7.2 нужно перелопатить огромное количество репозиториев, больше 7 (кажется) штук.

Попробовал начать это делать... Ну думаю внесу свой вклад.... Ага.... Конечно.... Как только я дошел до 5 репозитория я начал понимать насколько глубока кроличья нора и какая там круговерть зависимостей начинается... В общем... "Я пыталься насяльнике", но моё время мне дороже...

Было решено попробовать замокать внешние запросы как-то иначе... Начал смотреть и разбирать решения, которые есть в интернете по этому поводу. Пробовал разное, примерял и так и сяк и наперекосяк... Но Guzzle упорно отказывался мокаться...

Окей... Мы не сдаемся... Нам нужны автотесты...

В Symfony есть HttpClient как альтернатива Guzzle. Ну окей, попробуем со штатными либами поиграться... Перевел продукт с Guzzle на HttpClient - это заняло буквально 5 минут... Но вот дальше снова начались танцы с бубном... Сначала Symfony отказывалась брать клиента тестового окружения и уперто подсовывала в сервис боевого клиента HttpClient... Через какое-то время я победил эту проблему... Начал цепляться нужный клиент...

Но дальше пошло совсем веселье... По какой-то причине Symfony каждый раз запуская код из контура автотестов во время запуска теста создавала объект клиента, наполняла его данными ожидаемых запросов и ответов, а потом во время выполнения кода приложения просто создавала объект заново.... 😭😭😭😭😭

Видимо на какое-то время глаз уже замылился и только спустя 2 дня я вспомнил про Singleton!... И это стало моим спасением! Наконец-то! Спустя несколько вечеров мучений ЭТО заработало все в совокупности!!! Каково же было мое счастье!

По итогу все оформил в отдельный Модуль для Codeception. Его можно установить через composer.

https://packagist.org/packages/otezvikentiy/codeception-symfony-http-client-mock

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

И также еще немного скромной радости на сегодня:

У моего JsonRPCApiBundle появился первый контрибутор.
https://packagist.org/packages/otezvikentiy/json-rpc-api
Казалось бы ничего особенного, но чувство приятное.


В общем... Всем добра ))) Поделился с вами радостью 😂😂😂

С опытом понимаешь, что в задаче «могут ли 9 женщин родить ребёнка за месяц» скрывается: 5 из них не женщины; на самом деле срок 3 недели; ребёнок не нужен, а нужен звук детского плача, и пм подумал, что будет проще родить ребёнка для этого.

У нас было два Solution-архитектора, семьдесят пять микросервисов, пять разных очередей, половина кода на Bash и бесконечное множество костылей всех сортов и поколений, а также GraphQL, gRPC, REST и немного legacy SOAP. Не то чтобы это всё было необходимо для MVP, но когда начинаешь коллекционировать технологии, остановиться уже невозможно.

Как решая проблему можно поднасрать и себе и окружающим и при этом только усугубить проблему?

На этот вопрос сегодня ответит один вендор API!

Итак... Задача... Надо сделать API для продавцов на маркетплейсе. Ну казалось бы... Вроде как не какая-то рокетсайнс задача. У тебя есть данные в БД, надо уметь их отдавать по API. Ключевые задачи которые надо решить:
1) аутентификация
2) нагрузки

Если с первой задачей в целом как бы справились, с оговорочками, но как бы ок.... терпимо...
То со второй задачей - справились как бы... с гораздо большими вопросиками...

Задача со стороны продавца: получать данные по заказам и финансовые отчеты. Казалось бы... Должно быть 2 ручки в API, ну ок максимум до 4, которые ты дергаешь с нужными тебе фильтрами и получаешь все необходимые тебе данные.

Как реализовывается эта механика на стороне ЭТОГО вендора.... фух... ну панеслась....
1) ты дергаешь ручку одну ручку, которая возвращает тебе список заказов
2) ты дергаешь вторую ручку, которы возвращает тебе еще один список заказов, но чуть другой
3) ты дергаешь третью ручку, которая возвращает тебе еще отдельный набор данных, которых нет в 1 и 2 пунктах
4) ты вложенными циклами перебираешь это всё и склеиваешь в один массив
5) далее ты дергаешь еще 6 ручек, чтобы получить список штрафов по заказам или убедиться, что их нет
6) далее ты дергаешь еще 3 ручки, чтобы получить список "задач на сборку"
7) далее по каждой из ручек из предыдущего пункта ты дергаешь еще несколько раз отдельную ручку для получения статуса для каждой из "задач на сборку", чтобы получить статус заказа

И вот только выполнив ВСЁ это ты получаешь данные, чтобы собрать информацию о заказах воедино...

Если вы думали, что это все препятствия на пути - то вы заблуждаетесь....

1) каждый из методов имеет свои таймлимиты... например не более 1 запроса В МИНУТУ Карл!!! То есть ты не можешь отправить запрос с фильтром и получить данные - ты должен постранично с лимитом и оффсетом итерироваться со слипами в 1 МИНУТУ. Иначе тебе будет приходить ошибка о превышении количества запросов.

2) есть метод у которого этот лимит не 1 минута, а 10 минут............

3) если вы думали, что везде есть лимит и оффсет и нормальные фильтры по датам - обломитесь... есть метод, в который можно передать дату... НО он отдает данные не за эту дату... а за календарную неделю со среды до среды в пределах которой находится переданная дата... например отправив дату 05 и 09 февраля 2026 года - вы получите одни и те же данные за неделю... а вам надо за месяц.... но лимит у этого метода 1 запрос в 10 минут... НО... Есть дополнительная опция... если не передавать дату - то вам отгрузят ВСЕ данные которые вообще есть за несколько лет.......... Л - Логика... Чтобы снизить нагрузку - надо вшатать лимит и сделать максимально нежизнеспособный фильтр... просто логично до усёру...

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

И это далеко не все прикольные приколы...

Я вот сижу... читаю эту наркоманию.... И мне живо представляется картина как шел процесс проектирования этого API...

- Итак, коллеги, мы собрались на мозговой штурм по вопросу нагрузок! Ваши предложения!
- А давайте сделаем API настолько запутанным, чтобы разрабы бросали дело на полпути и не справлялись!
- А давайте сделаем настолько странные фильтры, чтобы интегироваться было бы максимально больно и сложно и тогда только самые настойчивые смогут это сделать!
- Надо внедрить тайм-лимиты!
- Надо абсолютно всю постраничную выгрузку данных во всех местах сделать по-разному! Не должно быть двух одинаковых мест с постраничной выгрузкой!
- А еще надо сделать так, чтобы не было одного единого очевидного сквозного идентификатора или называть его везде по-разному!
- А давайте еще добавим кучу кодов ошибок, но при этом тексты самих ошибок будут максимально размыты и без конкретики!
- А еще мы напишем документацию без примеров запросов!
- ОТЛИЧНО! Приняты ВСЕ предложения единогласно!

Какие тут стоит сделать выводы:
1) продумывай архитектуру заранее
2) если ты уже попал в архитектурный капкан и понял, что составленная архитектура не вывозит - то нужно ее пересоздать, а не продолжать в ней барахтаться

Получается вместо того, чтобы признать, что да, архитектура кал и порефакторить ее и снизить нагрузку за счет логически правильной архитектуры - делаются все новые и новые непродуманные версии API, которые не решают исходной проблемы, но за то повышают и без того не маленькую нагрузку КРАТНО, а также добавляют компании расходов на железо и поддержку этого мракобесия, а всем пользователям добавляют максимальный уровень геморроя при интеграции. Мда...

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

Мне вот реально очень интересно послушать объяснения лида направления на вопрос "откуда тут взялось столько наркомании откровенной?"

Лучшая картинка про ИИ, которую я видел за сегодня 😂😂😂

клиенты всем нужны - клиенты всегда важны 😂😂😂

Актуальная повесточка 😂😂😂

Нейронки. Мысли по поводу.

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

И да и нет... Но заменят многих...

Объясню как это работает на примере своего опыта. У меня есть корпоратная лицензия на claude code и персональная на max X20 тарифе для своих личных пет-проектов.

Для начала несколько фактов.

1) нейронка лажает! лажает сильно! но не часто! И вот это вот ключевая опасность. Получается так, что ты как бы расслабляешься, доверяешься, у тебя постепенно снижается уровень контроля. А потом в какой-то момент БАЦ - и она тебе делает подставу в виде неправильного знака, пишет вместо плюса - минус. И твоя компания в моменте начинает получать убыток. А ты этот код впервые в глаза видишь, потому что отпустил контроль.
Отсюда рождается правило первое, которое я для себя сформулировал так: ревью кода глазами в 100% случаев вплоть до каждой запятой.

2) когнитивная нагрузка. Если ты наивно полагаешь, что купишь себе тариф пожирнее и будешь курить в потолок пока нейронка работает и это сделает твою работу проще - ты заблуждаешься. Использование нейронки делает работу сложнее. Если ранее ты в расслабленном режиме сидел писал код в своем привычном темпе и за день делал 1-2 задачи в потолке, а иногда и 1 задачу в несколько дней - то сейчас ты начинаешь делать 5-6 задач за день, причем огромных по объему... А тебе еще надо все это валидировать, тестировать и т.д. Твой мозг начинает обрабатывать кратно больше информации. Соответственно к вечеру ты уже не бодрячок, а выжатый лимон.

3) да, много кто из-за этого потеряет работу с большой долей вероятности. В первую очередь это касаться джунов будет, потому что с нынешним уровнем знаний - они попросту не нужны бизнесу. Их заменит с лихвой нейронка за 200 баксов в месяц. Также это 100% зацепит тех, кто работает в направлении стандартизированных решений. Например CMS-ки с большой долей вероятности уйдут в небытие, потому что достаточно просто написать тот же самый функционал за 2 дня и иметь полностью кастомное решение и не зависеть от внешнего вендора. Если раньше CMS предлагали быстрое решение типизированных задач, но с завязками на определенные архитектурные решения и вендоров, и основным преимуществом этого подхода была скорость. То сейчас этого преимущества нет. Берется фреймворк и на нем пишется с нуля все то же самое силами нейронки за неделю максимум. Соответственно в цене будут оставаться опытные разработчики, архитекторы, те кто умеют сводить воедино сложные системы, в состоянии оценивать предлагаемые решения со стороны нейронки, а не в слепую соглашаться со всем что она говорит.

4) не маловажный фактор это "ответственность". Ответственность пока что никто не снимал. А как известно хэдам всегда надо иметь кого-то Ответственного за процесс. Свесить ответственность на нейронку - не получится, она тебе просто скажет "сорян, ты прав, а я ошиблась" + она и сама всегда пишет, что мол "я лишь помощник и меня надо перепроверять". Так что... Либо вы будете принимать ответственность, либо вы будете не нужны.

И это все затронет не только разработку, но и в целом все профессии где можно применять нейронки я полагаю.

Если есть свои мысли по этому поводу - делитесь ))) u r welcome )))