Зачем нужны дженерики, если можно проще?

elfuegobiz, )))) это очень хороший вопрос, дискуссии о том, какими должны быть дженерики в go ведутся уже далеко не первый год. Последний proposal выглядит примерно как у вас в примере https://go.googlesource.com/proposal/+/refs/heads/...
Может в 1.18 его таки добавят, правда я как-то очень сомневаюсь.

Зачем нужны внешние ключи прописанные в структуре БД (MySQL) - они действительно там нужны?

Если FK нет - как определить, что словарное поле есть в таблице-словаре?

Валидировать данные перед инсертом.

ещё один, проверочный, SELECT, делать, что ли?

Если словарь нельзя ни закэшировать ни вы нести в код - доп. селект вполне норм.

А если FK имеется - то отсутствующее в словаре значение просто не вставится.

Если ваш код отправляет данные на вставку после валидации по хорошему данные должны вставиться.

А какой ещё остался вариант? только вообще не следить за целостностью... или Вы считаете, что это лучше?

Лично я считаю такой вариант - недопустимым. А аргумент - не валидным. Давать доступ к субд клиенту, к которому нет доверия - это путь в никуда. Да, есть green SQL и другие штуки, но тем не менее.

Не говорите ерунды. Не соответствующий ограничению хлам в БД просто не попадёт. С точки зрения клиента это будет вообще выглядеть как физическая невозможность.

Если для вас хламом в БД являются только не целостные записи - это печально.
Что касается вашей уверенности в FK - это дело отключается. Прав на INSERT достаточно, что бы запустить
SET FOREIGN_KEY_CHECKS = 0;
Собсно вся ваша вера в то, что данные останутся целостными базируется на том, что эта команда не будет выполнена.

Зачем нужны внешние ключи прописанные в структуре БД (MySQL) - они действительно там нужны?

Akina,

Ну насчёт "большинства" - оно как-то сомнительно

Приведите пример, когда без FK не обойтись.

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

Следить за целостностью БД со стороны клиента, к которому нет доверия, это шутка такая?

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

Безусловно, с большей частью ошибок можно вполне спокойно бороться транзакциями например.

То есть гораздо выше вероятность, что вместо логически связанной информации в БД обнаружится хаотический хлам.

У вас хвост виляет собакой. Проектирование БД - это труоёмкий и длительный процесс, как разработки, так и поддержки. Если ваша БД - хаотический хлам, то что есть внешние ключи, что нет - она хламом и останется.

Попросили проверить код, на что смотреть нужно?

borisyurinov95, может у вас какая-то прям очень специфическая задача, что подобное необходимо, можете пример привести?

Попросили проверить код, на что смотреть нужно?

borisyurinov95, смотрю с осуждением. Экономия на геттерах - ну очень так себе идея.

Как подключиться один раз к базе?

Vitsliputsli, верно, но потом уже новое подключение прийдется перепробросить в севисы, требующие этот подключение. Собственно в этом моменте и сложность. В случае проброса зависимостей через конструктор - по сути прийдется пересоздать все используемые сервисы. Конкретно в моем случае эта проблема решалась за счет множества фабрик. Потом было принято соглашение: нет подключения - рестартуем воркер полностью.

Как подключиться один раз к базе?

uuuu,

Что такое воркеры?

Это консольные php процессы, для обработки чего-то

(нашел)

Конкретно с тедами - очень не рекоменду играться. Фича безусловно, прикольная, но в продакшне вносит больше минусов, чем плюсов. Лучше запустить несколько отдельных процессов, через supervisor например.

FanatPHP

осталось ещё понять, ради чего городить весь этот огород с пингами, реконнектами

Зависит от способа управления воркерами и соглашений в команде.
В моем случае обработчиков очередей сначала пробывали восстанавливать подключение, а дальше пробрасывать его в сервисы, это путь боли. В результате пришли к следующему паттерну. Перед обработкой каждого сообщения из очереди проверяем подключение к БД, если с ним что-то не так - завершаем процесс, сообщение отправляем на повторную обработку, а уже supervisor перезапускает процесс.

Могут ли взломать Linux сервер?

Владимир Коротенко, как минимум - не совпадающий с сайтом, как максимум - доступный через приватную сеть

Примеры организации grpc кода в go?

https://ru.wikipedia.org/wiki/GRPC#%D0%9F%D1%80%D0...

protobuf - безусловно прикольная штука, но с тулзами для тестирования / дебага далеко не все хорошо, нужно писать свои обвзяки.

Как найти OpenSource проект?

sunukun2020, ваше мнение очень важно для нас (с)

Что использовать для PHP разработки? Vagrant, Ansible или Docker?

batyrmastyr,

1) на хосте кидаете кроны каждого проекта в cron.d, в кронах docker exec container cmd.

когда таких кронов несколько - не вопрос, когда их много - это не удобно, особенно, когда котейнеры поднимаются с опцией `--rm`. Релизный образ может занимать спокойно и 700 и 1000+мб. Это нагрузка по io, как на развертывании контейнера, так и на его сворачивании. Как по мне запустить внутри контейнера cron - на много дешевле.

2) вы предлагаете супервизор поверх другого супервизора (php-fpm, roadrunner и т.д.) или над “php serve.php”?

обычные cli воркера. Для web поднимать супервизором nginx + php-fpm - это не то, что бы плохая идея. Еще могут потребоваться агенты сторонних служб, что тоже вполне допустимо поднимать супервизором.

И дебажить на боевом отдельный процесс как-то так себе затея.

Дебаг в постоянном режиме на проде - это путь в никуда, безусловно.
Тем не менее, бывают ситации, когда это необходимо. Например в 4 утра я предпочту сделать проверку прямо на продакшне, полному циклу релиза, если есть такая возможность.

Что использовать для PHP разработки? Vagrant, Ansible или Docker?

Ромзес Панагиотис,

разве недостаточно просто запустить достаточное количество экземпляров каждый в своем контейнере?

Согласитесь, несколько сотен запущенных процессов в одном контейнере и несколько сотен отдельных контейнеров с одим процессом внутри - несколько отличаются по ресурсам. Причем чем больше воркеров потребуется, тем острее вопрос.
Так же есть отличия в способе управления. Доверить php инженеру управление swarm кластером я бы побоялся. А вот предоставить доступ конкретно к супервизору - вполне нормальное решение.
Так же есть отличия в дебаге, согласитесь, упавший процесс легче дебажить, когда контейнер жив, чем когда контейнер дохнет вместе с ним.

Что использовать для PHP разработки? Vagrant, Ansible или Docker?

Ромзес Панагиотис, Главное без фанатизма))
Пример 1: у вас есть N cron задач. Для каждого поднимать отдельный контейнер - довольно накладно. Вместо этого имеет смысл поднять cron прямо внутри контейнера и уже там ранить ваши задачи.
Пример 2: у вас есть N воркеров. Тут по аналогии, поднимать под каждый контейнер - идея так себе. Вместо этого лучше внутри контейнера поднять supervisor, который уже будет менеджить воркера.

Почему многие программисты не любят javascript?

xxxzsx,

А как справляться с утечками?

так же, как и в любом другом языке)). Следить за используемыми ресурсами и не хранить в памяти то, что вам не надо. Запускать приложение с профайлером, исправлять косяки.

Что делать чтоб сборщик работал так как требуется?

вы со сборщиком не особо что-то сделаете.

В замыканиях мусор не забывать?

угу

Объясните что такое Node.js и как он(-а, -о) работает?

Israfil22, автору надо начать с малого

CMS не видит MySQL в Docker контейнере?

apaicer, если у вас все на одной хост системе - смотрите в сторону линковки и docker-compose.
Если на разных - пробросьте порт мускуля на внутресетевой ip между вашими серверами и подключайтесь конкретно на этот ip

Как стать хакером?

Зачем?))

В каких приложениях Go существенно эффективнее чем Node.js и PHP?

Александр Филиппенко

Насчёт горизонтального масштабирования, не соглашусь, на Го вполне можно писать stateless сервера, и запускать любое количество инстансов.

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

Насчёт скорости разработки, на РНР обычно быстрее, особенно когда можно взять готовый пакет, и он на 100% подходит, но бывает и наоборот.

Далеко не обязательно на 100%. Экосистема php в разы больше, чем у go. Соответственно как возможностей выбора, так и специалистовы больше + они дешевле, как правило.

Alexander Lamdan

Что то я не до конца понял, если мне щас развивать какой то проект скажем который возможно будет нужен компании с большими объемами данных, с крупной обработкой данных с нуля, то язык PHP плох?

Вопрос не правильный. Проект определяет инструменты для его создания.

А по ответам ниже Go не советуют использовать, и как тут быть?

У go - довольно специфическая ниша - это сетевые сервисы. Сайтики на нем писать будет накладно.
Тут по сути тот же ответ. Проект определяет инструменты.

Где найти американские веб студии?

это слишком сложно, не требуйте невозможного от человека

Где описана методика определения уровня скиллов - от джуна до сениора?

Пума Тайланд,

понятное дело в любой методике как и в самогоне надо отсеять хвосты и головы.

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

а зачем такому синьору вакансии? Он сам напрямую клиентам клепает сайты визитки по десять штук в день, получает свои 50 тысяч рублей в день и в ус не дует.

Да хоть по 20 за день, это не важно)) Это как раз "головы и хвосты".