Evgeniy S

Начать со стилизации ответов без обучения (RAG + примеры из ваших чатов), а уже потом — дообучить компактную модель на тщательно подготовленных парах вопрос → ваш ответ. Можно по апи на клоде например. Деньги понадобятся на токены.

Я остановился на подписке Гитхаба + vsCode
Насчет вайбКодинга. Для того чтобы им заниматься, надо как бы понимать ПОШАГОВО что тебе надо сделать, как это проверять и как отлаживать потом.

Приведу пример - мне надо было накидать к CLI приложению простую админку для удобства + апи чтоб конфиги грузило...
По сути на пайтоне мне нейронка накидала нужную "веб морду" + накидала отдельный исполняемый файл-коннектор который дергал апи, туда -сюда гонял нужное, и потом передавал CLI софту нужные параметры запуска.

Я НЕ умею писать код на Пайтоне. Но ЧИТАЯ его я понимаю что там написано, плюс \ минус. И я пошагово знал какие действия у меня должны выполняться.
Просто потому что у меня куча опыта в ИТ... как то так

Вот в ТАКОМ режиме нейронка отлично всё пишет...

Забей эту ошибку в гугл транслейт раз в англицкий не разумеешь. Ответ прямо в ней написан. ¯\_(ツ)_/¯

Можно, но эффект незначительный. Лучше понижать напряжение и частоту проца.

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

Если ты создашь искусственную нейросеть аналогичной сложности и натренируешь её - она также сможет достаточно быстро "обучаться" для новой задачи.

нужно передать данные во view

<?php
return view('livewire.schedule', [
    'days' => [1, 2, 3, 4]
]) ;

Я бы сделал одну таблицу
application_orders с полями
id, type, name, phone_number, email, message.
type - тип заявки - продукты или звонок

на пхп

на пхп есть два мира - академический и реальный

в академическом мире люди пишут красивый ООП код, классы, интерфейсы и тд. Это же все спрашивают на собеседованиях.
в реальном мире, в реальной работе, зачастую всё ООП заканчивается одними классами, редко трейты, редко интерфейсы, наследование не далее одного потомка. Особенно если уже используешь готовый фреймворк, где за тебя почти все сделано.

php - не лучший язык, что бы на нем писать "полноценные" приложения на пхп. там должна быть какая-то ну очень сложная бизнес-логика.

можно, конечно, нарисовать кучу классов, но это будет "ООП ради ООП"

Полноценного понимания не существует.
Я долго писал в процедурном стиле и долго не мог понять зачем вообще нужны эти классы какие-то.
Всё решалось функциями. С ростом сложности проекта приходилось передавать в функции всё больше и больше аргументов. Когда аргументов стало слишком много, я стал передавать в качестве аргумента массив с переменными.
Функция изменяла значения в этом массиве и возвращала.

Иногда (часто) функция должна была вызвать другую функцию и передать туда этот массив. Количество функций росло, цепочки из них становились всё длиннее и я даже стал путаться в том, какая функция в какой цепочке (трейсе) участвует.
Тогда я стал раскладывать группы функций по разным подключаемым файлам и называл эти файлы так, чтобы по названию понять какой группе переменных они нужны.

А потом я случайно узнал, что эти какие-то непонятные методы, которые "являются поведением объектов класса" (как это обычно объясняют) на самом деле просто функции и есть. И оказалось, что можно не пропихивать массив через них, а наоборот - функции сложить в этот массив. Получилось, что класс это такой "массив" в котором есть не только переменные, но и функции. И эти функции могут видеть все эти переменные, даже если не написать global $var. И это было как раз тем, чего я очень желал и радости моей не было предела.
Кстати, узнал я это, когда забавы ради кодил 2D платформер на C# в Unity.

А взять и прочитать хотя бы соответствующую статью в Википедии - не пробовал?

Свой - Zabbix
Чужой - https://uptimerobot.com/

Многое зависит от особенностей конкретного человека. Я вот, например, с огромным трудом воспринимаю информацию в видеоуроках, а на прошлом месте работал с коллегой, который наоборот гораздо лучше воспринимал новое на слух, он как раз предпочитал видеоуроки.

Выкинуть init()
Сделать __contstruct. В нём принимать key
Выкинуть проверки ключа из кода
Не использовать underscore в названиях функций (вкусовщина, но PSR)
Функцию перевода сделать не статической.
В функции перевода никаких данных из $_GET не вытаскивать. Все параметры только принимать. Если нужно что-то из $_GET, то делать это вне этого класса, не забыв санитайзинг и валидацию
Не использовать устаревший синтаксис array()
Обязательно выставлять таймаут на ответ внешнего сервиса
Обрабатывать ошибки если они произошли во время запроса (если сервер вернул 404, например. Или если он не ответил в таймаут)
json_decode вызывать только с флагом JSON_THROW_ON_ERROR или явно проверять что json распарсился корректно
Код ответа вытаскивать не из json'а, конечно.
Валидировать корректность полученных данных перед возвратом (убедиться что все ожидаемые поля на месте и значения в пределах допустимых)