Реальные профи в IT с многолетним опытом и насмотренностью всё равно останутся нужны индустрии, кто-то же должен проверять за ИИ
Нужно всего лишь объяснить свою нужность двадцатилетнему HR, который будет проводить скрининг с помощью LLM при вашем трудоустройстве, и на котором вы как специалист с богатым опытом и знаниями провалитесь с большой вероятностью, потому что будете давать не те ответы, что от вас ожидают услышать.
Просто в ЕС не нужно покупать серверы, поскольку сейчас – это полная помойка, вне зависимости будете вы брать через российскую компанию или напрямую. С серверами из стран на другом материке все хорошо, ни с той стороны, ни с этой вопросов ни у кого не возникает.
За одну неделю появились Fable 5.1, Gemini 3.8 Flash, Muse Spark 1.3 и контрольный выстрел от GPT-6 Astra. А предыдущий значимый цикл обновления был всего два месяца назад.
Нет у вас ощущения, что каждая новая модель не настолько "умнее" предыдущей, насколько велико желание эффективных менеджеров попадать в новости с кликбейтными заголовками?
Все делается достаточно просто, во многих случаях не нужны даже документы. Да, это происходит через серые схемы с высоким риском потери средств. Однако риск потерять 10$ на оплате забугорного сервиса не так велик, чтобы ограничивать себя чебурнетом и сидеть переживать, что завтра вы не сможете получить доступ туда, куда вам надо.
Человек, разрабатывающий телеграм-бота, путь даже в конструкторе без навыков программирования, все равно автоматически становится разработчиком. "Не разработчик" не будет делать бота сам, а закажет/купит готовый/попросит сделать друга. Стоит подумать над тем для кого на самом деле ваш продукт, и нет ли проблемы в его позиционировании.
P.S. Нейролендинг не работает, поскольку все причастные к no-code разработке (они в данный момент ваша ЦА) прекрасно распознают, что это генерация. И доверие к вам уже со старта снижается, даже если ваш основной продукт идеален. Поскольку создается ощущение, что можно себе такое же нагениерировать в два промпта (не важно так ли это на самом деле).
Удивительно, что в текущей ситуации компании готовы ругать тех, кто стремится думать и решать задачу самостоятельно и поощрять тех, кто гордо заявляет, что решает задачи не обладая должным уровнем навыков. У меня пока не сходится эта новая реальность с моим обычным мироощущением.
Как нейропоиск относится к нейротекстам? Если я напишу классные тексты, которые отвечают точно на любой вопрос пользователя и прекрасно структурированы, но сделаю это исключительно с помощью нейросети, будет ли такое GEO работать?
А, Customer не просто конфиг, он БЛ может быть еще обвешан, понял. Я обычно отделяю слой регистрации (конфигураторы посттайпов, полей, такс итп), от прочей логики. Тонкие классы, назовем к примеру CustomerInit - отвечают только за регу, переводы подбрасывают, чпу настраивают. То есть дальше в жизни приложения не участвуют, и нет смысла дергать их где-то еще. Бутстрап отдельно от логики.
Выкладывайте тоже куда-нибудь пример, интересно посмотреть как делают другие.
Показалось что здесь подобный подход. Классы монолиты которые отвечают за все про все - наводят осеннюю грусть)
Эти классы редко состоят более чем из 5-7 методов. Создавать на каждый метод отдельный класс - занятие довольно бессмысленное, вы просто получите больше файлов без каких-либо преимуществ. Если класс разрастается, то эту логику следует выносить в отдельный сервис, плагин, библиотеку. Об этом написано в статье:
Решение защитить классы-конфиги типа Customer.php синглтоном от повторного вызова как будь-то бы спорное. Если все эти классы всё равно централизованно находятся автопоиском и инициализируются в private function load($namespace): void не проще ли гарантировать однократную загрузку именно на этом уровне?
Не проще, потому что это не гарантирует однократную загрузку. Сейчас вы физически не можете написать new Customer();, интерпретатор выдаст ошибку. Вы можете обратиться к классу Customer только через метод instance(), возвращающий уже созданный на этапе первого обращения к классу объект.
Невозможно создать объект Customer через new, т.к. его конструктор приватный
А обращаться к классу Customer извне у вас может быть масса причин. Например, поступила задача выдать каждому клиенту рейтинг и обновлять его запросами к внешней CRM. За связь с CRM у вас отвечает отдельный плагин. Внутри этого отдельного плагина вы можете по API получить новый рейтинг для клиента и обновить его примерно так Customer::instance()->updateRating($customerId, $ratingValue); , если бы у вас не было реализации одиночки, вам бы пришлось либо создать статический метод Customer::updateRating(int $customerId, int $ratingValue) и обновлять сервис через него, в этом случае вы не смогли бы обращаться к нестатическим свойствам и методам класса внутри статического. Либо где-то хранить созданный на этапе загрузки приложения объект класса Customer, чтобы к нему обращаться повторно. Так вы бы изобрели что-то вроде обрезанного сервис-контейнера из Laravel, от куда можно извлечь нужный объект. А в конечном счете пришли бы к singleton-объектам внутри этого контейнера, чтобы избежать их дублирования. Потом бы устранили этот DI на минималках, поскольку выяснилось бы, что для вас оптимальным вариантом будет, если все объекты сущностей будут одиночками и вам не нужно дополнительное усложнение в виде их хранилища, достаточно сделать их доступными глобально. Я, по крайней мере, прошел этим путем :)
Ну и сам автопоиск, как по мне, делает зависимости слишком неявными. Я бы подумал о явной загрузке конфигов, которые при необходимости можно отключать не только del. -)
При необходимости отключить любую сущность можно закомментировав вызов $this->init(); внутри метода initInstance() соответствующей сущности.
Про неявность загрузки согласен, но лично мне так удобнее, потому что тех же классов твиков и блоков могут быть десятки и даже сотни. Следить за подключением каждого мне откровенно лень.
К тому же автозагрузка не ломает сознание вордпрессера, ведь в этой CMS и плагины и темы и дроп-ин'ы и все-все-все загружается без явного подключения в коде. В своей реализации вы можете избавиться от автозагрузки и подключать классы вручную, если вам так сподручнее.
Из явных недостатов автозагрузки я столкнулся только с тем, что мне потребовалось несколько раз поменять очередность инициализации разных сущностей. Для этого я добавил в класс IzwpCustomEntities\Core\BaseEntities\CustomFields , от которого наследуются прочие классы сущностей, свойство $loadPriority, где можно задать приоритет инициализации и перекинуть включение части функционала в конец.
Зачем нужно создавать отдельный трейт WithCustomerInfo? Выглядит как будто его функции будут использоваться только в CustomerView
Действительно, если методы будут использоваться только в CustomerView, то следует писать их прямо там без трейта. Я дергал для примера куски кода из разных проектов, в данном случае было два вида клиентов: компании и физлица, часть их полей пересекалась в трейте WithCustomerInfo
Получение acf полей и стандартных данных типа get_the_title и так ведь кэшируется на текущий запрос. Или имеется ввиду случаи, когда перед выводом с данными происходят дополнительные трансформации?
Все так. Кеширование необходимо в случаях, если в методе присутствуют какие-либо дополнительные вычисления. Особенно, если они касаются запросов к базе.
С другой стороны, если внутри метода вызывается что-либо, что может быть переопределено через хук, то мы не можем быть уверены, что оно всегда будет работать быстро. Особенно если проект большой и разработчиков на нем более чем один, или если среди разработчиков есть нейросети. Поэтому кешированием стоит пренебрегать только если вы на 100% уверены, что повторный вызов метода не будет генерировать дополнительных запросов к БД или выполнять что-нибудь ресурсозатратное.
Заголовок поста "Насколько нам нужны высокие технологии в обычной жизни?". В тексте нет ответа на этот вопрос или внятного рассуждения на эту тему.
Обычная жизнь не ограничена установкой китайских камер в подъездах и переклейкой шильдиков на этих же камерах для перепродажи втридорога, чтобы уже централизованно устанавливать их в тех же подъездах. Смысл поста вообще не понятен, возможно я недостаточно погрузился в тему, возможно у автора осеннее обострение.
"как эта система блокировок строится с точки зрения оператора связи" - эта тема куда более интересна, как по мне, особенно если в ней будет меньше политики и больше технической информации.
Хорошо, что вы повеселились во время "разработки" ПО, и поделились этим с нами. Плохо, что в статье от разработчика приложения на техническом ресурсе нет ни одной технической подробности, но есть ссылка на телеграм-канал.
Насколько этот подход отражается положительно на самом студенте? Не будет ли он испытывать недостатка практики в будущем, в котором всю рутинную работу за него делают агенты?
Без нейросетей я сидел бы без картинок или брал бы готовые из интернета. Редко кто будет нанимать иллюстратора, чтобы нарисовать картинку для обложки своего поста в соцсети.
В реальную работу я агентов пока не пускаю. Но факультативно сделал плагин для WordPress для генерации markdown-страниц: https://github.com/IvanZhuck/iz-md-pages
Из того что есть в репозитории моими руками написано строчек 10 максимум. Тем не менее, код рабочий, покрыт модульными тестами и крутится на нескольких больших новостных сайтах в продакшене. Качество кода меня также устраивает. Генерировал с помощью Antigravity CLI.
Все тоже самое я могу написать руками. По сравнению с обычной разработкой получилось раза в два быстрее, но устал от такой работы я в два раза больше и отходил от нее также в два раза больше. Приходилось больше читать кода, чем писать. Агент несколько раз заходил в тупик и еще больше раз выдвал откровенную дичь, на которую я бы купился, если бы ничего в этом не понимал. Другими словами выигрыш в эффективности сомнительный.
Проект некоммерческий и узконаправленный, монетезировать я его не планирую.
P.S. По недостающим компетенциям: нейросети классно закрывают для меня задачи по генерации разных картинок, которые используются в качестве иллюстраций и обложек публикаций.
Нужно всего лишь объяснить свою нужность двадцатилетнему HR, который будет проводить скрининг с помощью LLM при вашем трудоустройстве, и на котором вы как специалист с богатым опытом и знаниями провалитесь с большой вероятностью, потому что будете давать не те ответы, что от вас ожидают услышать.
У тех, кто не увольнялся недавно, зарплаты остались прежними в большинстве случаев
Просто в ЕС не нужно покупать серверы, поскольку сейчас – это полная помойка, вне зависимости будете вы брать через российскую компанию или напрямую. С серверами из стран на другом материке все хорошо, ни с той стороны, ни с этой вопросов ни у кого не возникает.
Нет у вас ощущения, что каждая новая модель не настолько "умнее" предыдущей, насколько велико желание эффективных менеджеров попадать в новости с кликбейтными заголовками?
Все делается достаточно просто, во многих случаях не нужны даже документы. Да, это происходит через серые схемы с высоким риском потери средств. Однако риск потерять 10$ на оплате забугорного сервиса не так велик, чтобы ограничивать себя чебурнетом и сидеть переживать, что завтра вы не сможете получить доступ туда, куда вам надо.
Российские провайдеры просто потеряют часть прибыли, которая уйдет иностранным провайдерам, где российские пользователи будут размещать VPN.
Человек, разрабатывающий телеграм-бота, путь даже в конструкторе без навыков программирования, все равно автоматически становится разработчиком. "Не разработчик" не будет делать бота сам, а закажет/купит готовый/попросит сделать друга. Стоит подумать над тем для кого на самом деле ваш продукт, и нет ли проблемы в его позиционировании.
P.S. Нейролендинг не работает, поскольку все причастные к no-code разработке (они в данный момент ваша ЦА) прекрасно распознают, что это генерация. И доверие к вам уже со старта снижается, даже если ваш основной продукт идеален. Поскольку создается ощущение, что можно себе такое же нагениерировать в два промпта (не важно так ли это на самом деле).
Удивительно, что в текущей ситуации компании готовы ругать тех, кто стремится думать и решать задачу самостоятельно и поощрять тех, кто гордо заявляет, что решает задачи не обладая должным уровнем навыков. У меня пока не сходится эта новая реальность с моим обычным мироощущением.
Как нейропоиск относится к нейротекстам? Если я напишу классные тексты, которые отвечают точно на любой вопрос пользователя и прекрасно структурированы, но сделаю это исключительно с помощью нейросети, будет ли такое GEO работать?
Выкладывайте тоже куда-нибудь пример, интересно посмотреть как делают другие.
Эти классы редко состоят более чем из 5-7 методов. Создавать на каждый метод отдельный класс - занятие довольно бессмысленное, вы просто получите больше файлов без каких-либо преимуществ. Если класс разрастается, то эту логику следует выносить в отдельный сервис, плагин, библиотеку. Об этом написано в статье:
Не проще, потому что это не гарантирует однократную загрузку. Сейчас вы физически не можете написать
new Customer();, интерпретатор выдаст ошибку. Вы можете обратиться к классу Customer только через метод instance(), возвращающий уже созданный на этапе первого обращения к классу объект.А обращаться к классу Customer извне у вас может быть масса причин. Например, поступила задача выдать каждому клиенту рейтинг и обновлять его запросами к внешней CRM. За связь с CRM у вас отвечает отдельный плагин. Внутри этого отдельного плагина вы можете по API получить новый рейтинг для клиента и обновить его примерно так
Customer::instance()->updateRating($customerId, $ratingValue);, если бы у вас не было реализации одиночки, вам бы пришлось либо создать статический методCustomer::updateRating(int $customerId, int $ratingValue)и обновлять сервис через него, в этом случае вы не смогли бы обращаться к нестатическим свойствам и методам класса внутри статического. Либо где-то хранить созданный на этапе загрузки приложения объект класса Customer, чтобы к нему обращаться повторно. Так вы бы изобрели что-то вроде обрезанного сервис-контейнера из Laravel, от куда можно извлечь нужный объект. А в конечном счете пришли бы к singleton-объектам внутри этого контейнера, чтобы избежать их дублирования. Потом бы устранили этот DI на минималках, поскольку выяснилось бы, что для вас оптимальным вариантом будет, если все объекты сущностей будут одиночками и вам не нужно дополнительное усложнение в виде их хранилища, достаточно сделать их доступными глобально. Я, по крайней мере, прошел этим путем :)При необходимости отключить любую сущность можно закомментировав вызов
$this->init();внутри методаinitInstance()соответствующей сущности.Про неявность загрузки согласен, но лично мне так удобнее, потому что тех же классов твиков и блоков могут быть десятки и даже сотни. Следить за подключением каждого мне откровенно лень.
К тому же автозагрузка не ломает сознание вордпрессера, ведь в этой CMS и плагины и темы и дроп-ин'ы и все-все-все загружается без явного подключения в коде. В своей реализации вы можете избавиться от автозагрузки и подключать классы вручную, если вам так сподручнее.
Из явных недостатов автозагрузки я столкнулся только с тем, что мне потребовалось несколько раз поменять очередность инициализации разных сущностей. Для этого я добавил в класс
IzwpCustomEntities\Core\BaseEntities\CustomFields, от которого наследуются прочие классы сущностей, свойство$loadPriority, где можно задать приоритет инициализации и перекинуть включение части функционала в конец.Действительно, если методы будут использоваться только в
CustomerView, то следует писать их прямо там без трейта. Я дергал для примера куски кода из разных проектов, в данном случае было два вида клиентов: компании и физлица, часть их полей пересекалась в трейтеWithCustomerInfoВсе так. Кеширование необходимо в случаях, если в методе присутствуют какие-либо дополнительные вычисления. Особенно, если они касаются запросов к базе.
С другой стороны, если внутри метода вызывается что-либо, что может быть переопределено через хук, то мы не можем быть уверены, что оно всегда будет работать быстро. Особенно если проект большой и разработчиков на нем более чем один, или если среди разработчиков есть нейросети. Поэтому кешированием стоит пренебрегать только если вы на 100% уверены, что повторный вызов метода не будет генерировать дополнительных запросов к БД или выполнять что-нибудь ресурсозатратное.
В каком месте компании измеряли свою эффективность количеством кода? В Индии?
Заголовок поста "Насколько нам нужны высокие технологии в обычной жизни?". В тексте нет ответа на этот вопрос или внятного рассуждения на эту тему.
Обычная жизнь не ограничена установкой китайских камер в подъездах и переклейкой шильдиков на этих же камерах для перепродажи втридорога, чтобы уже централизованно устанавливать их в тех же подъездах. Смысл поста вообще не понятен, возможно я недостаточно погрузился в тему, возможно у автора осеннее обострение.
"как эта система блокировок строится с точки зрения оператора связи" - эта тема куда более интересна, как по мне, особенно если в ней будет меньше политики и больше технической информации.
Из вас получился бы отличный эффективный менеджер!
Хорошо, что вы повеселились во время "разработки" ПО, и поделились этим с нами. Плохо, что в статье от разработчика приложения на техническом ресурсе нет ни одной технической подробности, но есть ссылка на телеграм-канал.
Насколько этот подход отражается положительно на самом студенте? Не будет ли он испытывать недостатка практики в будущем, в котором всю рутинную работу за него делают агенты?
Без нейросетей я сидел бы без картинок или брал бы готовые из интернета. Редко кто будет нанимать иллюстратора, чтобы нарисовать картинку для обложки своего поста в соцсети.
В реальную работу я агентов пока не пускаю. Но факультативно сделал плагин для WordPress для генерации markdown-страниц: https://github.com/IvanZhuck/iz-md-pages
Из того что есть в репозитории моими руками написано строчек 10 максимум. Тем не менее, код рабочий, покрыт модульными тестами и крутится на нескольких больших новостных сайтах в продакшене. Качество кода меня также устраивает. Генерировал с помощью Antigravity CLI.
Все тоже самое я могу написать руками. По сравнению с обычной разработкой получилось раза в два быстрее, но устал от такой работы я в два раза больше и отходил от нее также в два раза больше. Приходилось больше читать кода, чем писать. Агент несколько раз заходил в тупик и еще больше раз выдвал откровенную дичь, на которую я бы купился, если бы ничего в этом не понимал. Другими словами выигрыш в эффективности сомнительный.
Проект некоммерческий и узконаправленный, монетезировать я его не планирую.
P.S. По недостающим компетенциям: нейросети классно закрывают для меня задачи по генерации разных картинок, которые используются в качестве иллюстраций и обложек публикаций.