У Вас серьёзный аргумент. Конечно, частично это так, я привык к своему зоопарку и пытаюсь отбрыкаться от новых экзотических животных. Но в оправдание скажу, что этот зоопарк достался нам в наследство и его архитектуру разрабатывали не мы. Я лишь потратил более 3-х лет, чтобы привести его в нормальное рабочее состояние и выстроить все процессы фактически с нуля. Не только в команде, но и между различными отделами.
Раньше он был гораздо более "зоопаркистей" - это легаси... и легаси очень древнее. С другой стороны - с легаси можно жить, а вот с тех.долгом - весьма сложно. Поэтому пару последних лет у нас ушло на уничтожение сорняков - годами копившийся тех.долг, огромный бэклог багов, очистку авгиевых конюшен в виде огромных пластов "мёртвого кода" и написание сотен страниц технической документации. И это совершенно потрясающий опыт, имеется ввиду - приведение легаси в рабочее состояние. По факту - это наш "бэби" (мой и моей команды), поэтому я и принимаю в штыки любую попытку опять всё вернуть в состояние хаоса.
Я не сказал, что у нас монолит и на PHP и на Python одновременно. У нас ядро на PHP (это монолит, да, но разбит на модули), а на Python основной отдельно стоящий сервис. Взаимодействие между ними через API. Плюс, есть микросервисы для высоконагруженного кода. Я не считаю такой "зоопарк" чем-то необычным - продукту уже 13 лет.
С бизнесом у меня отношения простые - его задача прибыль, но! не в ущерб инженерии, а в остальное ему нос совать не нужно. У меня у самого был свой бизнес, поэтому челом бить перед ним я не собираюсь. Просто очень часто плохую работу отдела продаж пытаются компенсивать за счёт издевательства над разработкой - типа тут результат можно почувствовать гораздо быстрее. В этой плоскости собственно драма и развивается.
Но Вы правы - запретить бизнесу самовыпилиться - никто не может. Я уже начал обновлять резюме.
Ваше предложение абсолютно логично, но я человек, более того - я человек старой закалки. Я не могу плохо работать, это не моё. У меня в команде лозунг: либо мы работаем хорошо, либо.. очень хорошо. Других вариантов нет, кто не согласен - я не держу.
Но Вы правы, пора отпустить ситуацию (за пинок - спасибо). Видимо это мысль - главное, что я вынес из всех коментариев.
Я не написал это в статье, но я пытался это сделать: и объяснял и уговаривал и приводил доказательства. Увы, тяжело логикой переформатировать головы людей, влюблённых в вайб-кодинг. Да им и всё-равно - я уйду, а они останутся.
И почему Вы собственно решили, что он из костылей? И почему Вы обзываетесь на монолиты - монолит это не обязательно зло, если он хорошо отлажен и работает как часы. И потом, часть высоконагруженного кода у нас вынесена в микросервисы, а в остальном - всё ок, работает как по "феншую".
А насчёт бабы-яги, то да - против. А что, всёгда нужно "за", если бизнес так решил?
Спасибо за несколько полезных идей (для меня они были, увы, неочевидны) - начну их сейчас пробовать. Как раз работаю над подобной задачей. Кроме gemma3 пробовали ли Вы использовать что-то другое - Spacy, например?
Спасибо за плагин. У меня вопрос: как в Yii1 установить связь между вызовом метода render() и фалом view. Не могу настроить вот такой вариант: <regexp from="/modules/dashboard/controllers/" to="/modules/dashboard/views/"/>
Функционал действительно полезный, но у меня вопрос: что делать, если я хочу получить от IDE подсказки по полям DTO? У Вас в примерах возвращается только массив. При ручном маппинге это не проблема, так как поля для объекта мы задаём вручную, в как быть с автоматическим маппингом?
Автору респект! Начал чтение. Я сам в данный момент пишу книгу про ИИ (в основном для себя и для друзей + отдельный проект на гитхабе с работающими примерами). Причина простая: хочу разобраться в этой области и рассортировать в голове накопленные за последние 5 лет знания из ИИ, машинного обучение, математики и нейронных сетей.
Согласен, на локалхосте это выглядит довольно надумано.
У нас "немного" нестандартный легаси проект, где On-Prem клиенты получают нашу систему с готовыми преднастройками, включая Redis. Проблема в том, что довольно часто у клиентов резко возрастает объём трафика и данных и поэтому дефолтных настроек для Redis не хватает. Мы пробовали менять конфигурацию Redis на лету по запросу, но это не всегда удобно (и не для всех клиентов возможно). Поэтому я подумал, что опция с кластеризацией может нам помочь снять головную боль (хотя не факт). Пока ещё в списке задач на POC.
"Тем временем уборщица протёрла клавиатуру от пыли..." - у меня на работе невозможно отойти от своего стола попить кофе, без того, чтобы не заблокировать клавиатуру на своём компе. Это MUST в современном мире IT. Новичков, кто попадает к нам в команду предупреждают (конечно, с первого раза никто не "впитывает"), но затем начинают учить (иногда жёстко) до тех пор, пока не вырабатывается рефлекс - встал из-за стола, "залочь" свой комп.
Интересное решение, нужно попробовать. Я у себя эту проблему решил по другому: на каждое созданное TODO программист должен создать задачу в проекте тех.долга, описать там всё, что нужно сделать подробно, предложить направление решения и т.д.
Номер созданной задачи добавляется к коментарию, т.е выходит что-то вроде
TODO: bla-bla... TID:2099
Согласен с автором и по личному опыту знаю, что если сразу не описать задачу, то через несколько лет столкнувшись с обычной тудушкой (когда автор уже уволился), никто уже не понимает зачем она нужна, насколько она критична и что в ней нужно конкретно делать (пару лет жили без неё и всё было нормально)
Спасибо за рекомендацию. Когда-нибудь, лет через... сколько-то... я наверное обновлю эту статью и обязательно подробнее остановлюсь на "рулевых" каждого кризиса. Это конечно увеличит её объём, но думаю она от этого только выиграет.
Что касается бедности... Всё зависит от того, что под этим понимать. Обычно бедным считают человека, у которого все доходы уходят лишь на выживание: еда и жильё. То есть другими словами - без возможности тратить на отдых, качественную медицину, развлечения, поездки за границу, что-то откладывать, инвестировать и т.д.
И да, я не стесняюсь - получается, что большую часть своей жизни я был финансово фактически "бедным", несмотря на 2 высших образования, работу по специальности, собственный ИП бизнес и прочее. Хотя интересно, какими бы глазами я сам из 90-х смотрел бы на себя сегодняшнего?
У Вас серьёзный аргумент. Конечно, частично это так, я привык к своему зоопарку и пытаюсь отбрыкаться от новых экзотических животных. Но в оправдание скажу, что этот зоопарк достался нам в наследство и его архитектуру разрабатывали не мы. Я лишь потратил более 3-х лет, чтобы привести его в нормальное рабочее состояние и выстроить все процессы фактически с нуля. Не только в команде, но и между различными отделами.
Раньше он был гораздо более "зоопаркистей" - это легаси... и легаси очень древнее. С другой стороны - с легаси можно жить, а вот с тех.долгом - весьма сложно. Поэтому пару последних лет у нас ушло на уничтожение сорняков - годами копившийся тех.долг, огромный бэклог багов, очистку авгиевых конюшен в виде огромных пластов "мёртвого кода" и написание сотен страниц технической документации. И это совершенно потрясающий опыт, имеется ввиду - приведение легаси в рабочее состояние. По факту - это наш "бэби" (мой и моей команды), поэтому я и принимаю в штыки любую попытку опять всё вернуть в состояние хаоса.
Я не сказал, что у нас монолит и на PHP и на Python одновременно. У нас ядро на PHP (это монолит, да, но разбит на модули), а на Python основной отдельно стоящий сервис. Взаимодействие между ними через API. Плюс, есть микросервисы для высоконагруженного кода. Я не считаю такой "зоопарк" чем-то необычным - продукту уже 13 лет.
С бизнесом у меня отношения простые - его задача прибыль, но! не в ущерб инженерии, а в остальное ему нос совать не нужно. У меня у самого был свой бизнес, поэтому челом бить перед ним я не собираюсь. Просто очень часто плохую работу отдела продаж пытаются компенсивать за счёт издевательства над разработкой - типа тут результат можно почувствовать гораздо быстрее. В этой плоскости собственно драма и развивается.
Но Вы правы - запретить бизнесу самовыпилиться - никто не может. Я уже начал обновлять резюме.
Ваше предложение абсолютно логично, но я человек, более того - я человек старой закалки. Я не могу плохо работать, это не моё. У меня в команде лозунг: либо мы работаем хорошо, либо.. очень хорошо. Других вариантов нет, кто не согласен - я не держу.
Но Вы правы, пора отпустить ситуацию (за пинок - спасибо). Видимо это мысль - главное, что я вынес из всех коментариев.
Я не написал это в статье, но я пытался это сделать: и объяснял и уговаривал и приводил доказательства. Увы, тяжело логикой переформатировать головы людей, влюблённых в вайб-кодинг. Да им и всё-равно - я уйду, а они останутся.
Да, отгонял эту мысль долго, но похоже нужно начинать готовить почву для следующей станции
И почему Вы собственно решили, что он из костылей? И почему Вы обзываетесь на монолиты - монолит это не обязательно зло, если он хорошо отлажен и работает как часы. И потом, часть высоконагруженного кода у нас вынесена в микросервисы, а в остальном - всё ок, работает как по "феншую".
А насчёт бабы-яги, то да - против. А что, всёгда нужно "за", если бизнес так решил?
Спасибо за несколько полезных идей (для меня они были, увы, неочевидны) - начну их сейчас пробовать. Как раз работаю над подобной задачей. Кроме gemma3 пробовали ли Вы использовать что-то другое - Spacy, например?
Тесты проверяют только то, что их "написали" проверять. Не факт, что они проверяли все негативные сценарии и т.д.
Спасибо за замечание - я попытался дать немного более развёрнутое описание о событиях.
По другому не работает. Это yii1 и у нас своеобразная структура фалов для модулей.
Спасибо, я разобрался в конце-концов. Для модулей в Yii1 нужно добавить отдельную секцию вот так, как в примере. Может кому пригодится.
<files className="\app\controllers\Controller" methodName="render" argumentIndex="0" fileExt="php" relatedTo="file" ><directoryProcessors>
<regexp from="([a-zA-Z]+)Controller\.php" to=""/>
<regexp from="/modules/(.*)/controllers/" to="/modules/$1/views/"/>
</directoryProcessors>
</files>
Спасибо за плагин. У меня вопрос: как в Yii1 установить связь между вызовом метода render() и фалом view.
Не могу настроить вот такой вариант:
<regexp from="/modules/dashboard/controllers/" to="/modules/dashboard/views/"/>
Для обычных контроллеров работает хорошо.
Что делать, если я хочу в качестве DTO получить объект, а не массив?
Функционал действительно полезный, но у меня вопрос: что делать, если я хочу получить от IDE подсказки по полям DTO? У Вас в примерах возвращается только массив. При ручном маппинге это не проблема, так как поля для объекта мы задаём вручную, в как быть с автоматическим маппингом?
Автору респект! Начал чтение. Я сам в данный момент пишу книгу про ИИ (в основном для себя и для друзей + отдельный проект на гитхабе с работающими примерами). Причина простая: хочу разобраться в этой области и рассортировать в голове накопленные за последние 5 лет знания из ИИ, машинного обучение, математики и нейронных сетей.
Согласен, на локалхосте это выглядит довольно надумано.
У нас "немного" нестандартный легаси проект, где On-Prem клиенты получают нашу систему с готовыми преднастройками, включая Redis. Проблема в том, что довольно часто у клиентов резко возрастает объём трафика и данных и поэтому дефолтных настроек для Redis не хватает. Мы пробовали менять конфигурацию Redis на лету по запросу, но это не всегда удобно (и не для всех клиентов возможно). Поэтому я подумал, что опция с кластеризацией может нам помочь снять головную боль (хотя не факт). Пока ещё в списке задач на POC.
Понимаю, что это всего лишь учебный пример, но всё равно
global $database; слегка напряг.А вообще, за идею спасибо. Мне пригодится в текущем проекте.
"Тем временем уборщица протёрла клавиатуру от пыли..." - у меня на работе невозможно отойти от своего стола попить кофе, без того, чтобы не заблокировать клавиатуру на своём компе. Это MUST в современном мире IT. Новичков, кто попадает к нам в команду предупреждают (конечно, с первого раза никто не "впитывает"), но затем начинают учить (иногда жёстко) до тех пор, пока не вырабатывается рефлекс - встал из-за стола, "залочь" свой комп.
Интересное решение, нужно попробовать. Я у себя эту проблему решил по другому: на каждое созданное TODO программист должен создать задачу в проекте тех.долга, описать там всё, что нужно сделать подробно, предложить направление решения и т.д.
Номер созданной задачи добавляется к коментарию, т.е выходит что-то вроде
Согласен с автором и по личному опыту знаю, что если сразу не описать задачу, то через несколько лет столкнувшись с обычной тудушкой (когда автор уже уволился), никто уже не понимает зачем она нужна, насколько она критична и что в ней нужно конкретно делать (пару лет жили без неё и всё было нормально)
Спасибо за рекомендацию. Когда-нибудь, лет через... сколько-то... я наверное обновлю эту статью и обязательно подробнее остановлюсь на "рулевых" каждого кризиса. Это конечно увеличит её объём, но думаю она от этого только выиграет.
Что касается бедности... Всё зависит от того, что под этим понимать. Обычно бедным считают человека, у которого все доходы уходят лишь на выживание: еда и жильё. То есть другими словами - без возможности тратить на отдых, качественную медицину, развлечения, поездки за границу, что-то откладывать, инвестировать и т.д.
И да, я не стесняюсь - получается, что большую часть своей жизни я был финансово фактически "бедным", несмотря на 2 высших образования, работу по специальности, собственный ИП бизнес и прочее. Хотя интересно, какими бы глазами я сам из 90-х смотрел бы на себя сегодняшнего?