Всегда описывайте полный вариант. Для тех полей, которые могут не прийти, прописываете дефолтные значения. Прописать дефолты можете как в PHP, так и в атрибутах маппинга полей самой базы.
Про связи между таблицами в базе и их отражение в классах рекомендую смотреть туториалы, потому что там этих связей несколько типов.
Кстати, обязательно объявляйте сами поля в в классах. Это не JavaScript, так как вы делаете делать в PHP не рекомендуется. Если хотите сократить код, лучше используете constructor property promotion
Вам совет: всегда считайте клиент врагом сервера, который постоянно хочет сервер обмануть, прислать вредоносные инъекции, навредить и украсть данные. Ведь это весьма близко к реальности.
Такой образ мыслей сам будет наталкивать вас на верные решения. Например, что все проверки, проводимые на клиенте, всегда нужно дублировать на сервере, и все значения по умолчанию нужно устанавливать именно на сервере.
off, Спасибо! Так и делаем по мере возможности. Правда, не всегда возможно сильно урезать не в ущерб работе.
Конечно, можно что-то тут и там урезать, затянуть пояс потуже, не обращать внимания на swap, и выживать с этим всем.
Однако мы - программисты - такие же мастера, как и все остальные мастера. Ноутбук - это наш инструмент, он нам помогает деньги зарабатывать. На инструменте экономить - делать себе же хуже. И вместо того, чтобы следить за состоянием памяти, наскребая по сусекам капли ресурсов, я бы хотел заниматься делом и иметь хоть какой-то запас ресурсов на всякий случай.
Именно поэтому я рекомендую 16гб минимум. 32 - это тот размер, когда обычному программисту практически вообще не надо думать про память.
Конечно, если бюджет совсем не позволяет, то можно подумать и об Air 8гб, ведь его потом можно хорошо продать и купить себе что-то мощнее. Но если бюджет позволяет, то экономить тут вредно
Алексей Дубровин, Думал вас похвалить, как того самого сына маминой подруги, которому все всегда хватает. А потом посмотрел на жёлтый цвет графика памяти, 7гб swap, и передумал хвалить.
Если график памяти жёлтый, вам уже её сильно не хватает, это вам подсказка на будущее.
Алексей Дубровин, Вопрос далеко не в понтах, а в банальном размере памяти. И Apple специально вставляет эти идиотские 8Гб, которых без swap хватать не будет 100%. И делают они это именно для того, чтобы покупали Pro. Ведь если к Air докинуть по их конским ценам ещё 8Гб, то выгоднее уже будет взять Pro
exxxt4zy, Swap работает везде одинаково, если скорость SSD позволяет. Проблема swap на Маке - это то, что SSD распаян на плате, и если у вас всегда будет работать Swap, то это может очень плохо сказаться на ресурсе SSD. Менять же такой SSD - это страшный геморрой, если вообще получится...
videxerion, Это папка, в которой лежит проект, но самое главное, чтобы в файле go.mod было указано название модуля "module test".
Я добавил в ответ.
Все запуски go run и go build надо делать из корневой директории, где лежит файл go.mod
Слава, В Go 1.22 прокачали пакет http, и теперь для подавляющего большинства проектов не нужен даже сторонний роутер.
Поэтому, настоятельно рекомендую вам не использовать ни какой фреймворк до тех пор, пока он вам прямо позарез не понадобится, и вы сможете чётко и конкретно аргументировать, зачем именно этот фреймворк вам нужен.
Для логов возьмите стандартный пакет slog, фреймворк не нужен.
Конфиги пока просто на самом языке напишите в виде структурок, и берите данные из тех же переменных окружения. А уже потом найдёте что-то более подходящее именно для вас.
Карлиндоу Мэрлифи, Вам тогда надо не сюда, а в древние форумы профессионалов по безопасности, где и обнаруживали проблемы.
У меня подход к безопасности следующий:
- Всегда брать сторонние проверенные решения. Там люди собаку съели на безопасности, не чета мне (и 90% программистам), занимающихся перекладыванием json или данных из форм в базу и обратно через тонкий слой элементарной логики.
- Если я где-то в проверенных источниках услышу, что решение небезопасно, я даже особо вдаваться в подробности не буду, просто прекращу этим пользоваться. Упрямство и завышенный ЧСВ программистов часто приводят к утечкам, о которых потом говорят в новостях.
Поэтому, тут вам и примеров-то никто не даёт, потому что все те, кто зарабатывают деньги при помощи написания кода, уже забыли много лет назад о mysql_escape_string и mysql_query)
Danbka,
1. Это чисто для удобства. Если вы обратите внимание, они основаны на разных базовых образах PHP. Эти образы по-разному оттюнингованы каждый под свою задачу.
php-cli заточен под то, чтобы его запускать и сразу после выполнения скрипта останавливать, он не висит в памяти, вы не мешаете работе вебсервера.
2. Опять же для удобства. Вы можете так настроить образ php-fpm, что он практически не будет отличаться от того, что бежит на проде. А чем меньше отличается образ на локалке от образа на проде, тем меньше у нас ситуаций типа "это же работает на моей машине!". Это меня очень часто выручало. Тем более, когда образы практически не отличаются, тем проще вносить изменения одновременно и на локалке, и на прод. Вы прямо одним взглядом будете видеть отличия.
В общем, это дело вкуса. Если вам не нравится, не используйте.
Единственное, что вам посоветую - использовать мульти-стадийную сборку образов. Т.е. в одном и том же докерфайле сначала используете образ-сборщик на основе php-cli, который сделает composer install, а потом, на следующей стадии, в этом же файле используйте уже образ php-fpm без композера, и просто скопируете внутрь него результат работы первого этапа уже с директорией vendor, прогретым кэшем и т.д. Он будет занимать намного меньше места.
Погуглите обязательно, это очень круто
Vitsliputsli,
К библиотекам у меня больших претензий нет. Они делают, что могут. Проблема в том, что они требуют особого подхода, особого окружения, и не всегда их получится легко интегрировать в уже работающий проект.
Сам чистый PHP до сих пор полностью не подходит под долгоживущие процессы, потому что если вы не будете досконально знать, как работает сборщик мусора, не будете микромэнеджить жизнь каждого созданного объекта, он у вас обязательно потечёт. Поэтому, есть такая практика: перезапускать такие процессы через какое-то определённое время, либо когда размер памяти превысит какое-то пороговое значение, либо просто отталкиваться от количества каких-то логических операций, выполняемых этим процессом. А потом давать процессу SIG_KILL, он будет мягко завершаться и перезапускаться.
Но любой перезапуск потребует и перезапуска соединения с браузером, т.е. надо будет и фронтенд усложнять. И оно нам надо? Только потому, что мы всеми зубами фанатично держимся за PHP?
Я считаю, что нужно выбирать инструмент под задачу, и если есть языки, на которых это реализовать проще и быстрее, то так надо и делать
Дмитрий,
Я о том и написал в первых абзацах. Если использовать Dependency Injection для подключения всех зависимостей, то нам вообще не надо тестировать private методы. А если вдруг стало надо, то лучше задуматься об архитектуре проекта и изменить это...
Использование protected вместо private - это как раз техника на такие вот случаи. Если нам вдруг резко надо будет отнаследоваться с этим методом, то можно будет это сделать вообще без изменений базового класса, что очень приветствуется, когда над проектом работает больше одного человека.
Я большой противник наследования, его использую только в крайних случаях, поэтому лично для меня нет большой разницы между private и protected. А когда как раз вдруг возникает крайняя необходимость в наследовании, то protected тут и выручает.
Vitsliputsli,
Я согласен с вами, что PHP уже другой. Сам прыгаю от счастья последнее время, потому что PHP - это мой кусок хлеба. Но всё равно на нём всё ещё очень просто написать долгоживущий процесс, который будет течь по памяти. Поэтому до сих пор живёт и процветает тот же Swoole и прочие.
Подобные веб-серверы для той же ноды уже проверены годами, заматерели, обросли тоннами качественных туториалов.
И когда вместо того, чтобы решать бизнес-задачу, придётся возиться с утечкой памяти в PHP, будет крайне неприятно.
Полностью поддержу!
Практически везде, где я в своей жизни использовал автоикремент чуть более, чем тупой уникальный упорядоченный ID, я постоянно сталкивался с какими-то проблемами
Про связи между таблицами в базе и их отражение в классах рекомендую смотреть туториалы, потому что там этих связей несколько типов.
Кстати, обязательно объявляйте сами поля в в классах. Это не JavaScript, так как вы делаете делать в PHP не рекомендуется. Если хотите сократить код, лучше используете constructor property promotion