За второй не скажу, но с первым в докерах или типа того постоянно нюансы: их в один контейнер помещать с супервизор или системд или в разные. Чистую статику из пхп-фрейма как веб-серверу давать. Пользовательскую.
Да и вообще, два компонента обычно сложнее в разработке, разворачивание поддержке чем один.
А кто мешает? Я писал такое ещё на PHP3. Открываем сокет слушаем обрабтывае. Да, синхронно, да однопоточно, да память текла во всю тогда… Сейчас со многим лучше. Генераторы вон можно прикрутить
Вроде редкость, когда эйчары или ещё кто приводят человека в команду и говорят "вот ваш новый коллега". Хоть один человек из команды да участвуте в процессе найма. На прошлом проекте так вообще было командное собеседование почти самое финальное, на 40-60 минут, околотехничское, но больше культурное. После обменивались мнениями и голосовали потом брать-не брать
Вот как раз необлачные, классические таргеты интересуют, но с контейнерами желательно. Причём c моделью несколько приложений/сервисов на одном хосте. С поддержкой блю/грин какой-то на уровне, например, конфигов nginx или haproxy. Вернее с возможностью фиксировть что приложение/сервис такой-то ревизии такой-то успешно залито на сервер такой-то в blue "половину" (или на блю-сервер) и сервер уже её обслуживает. Или создавать динамически окружения под фиче-ветку на базе технологий типа виртуальных хостов в веб-серверах. Проблема не создать даже, проблема как-то иметь информацию внутри CI/CD где что развёрнуто в таких сценариях. Как на дашбордах, так и внутри пайплайнов.
С кубером когда работал было хорошо в этом плане. Не идеально, но хорошо ), сейчас на проекте физическое и виртуальное железо в режиме "напихано всё что влезло и немного больше" и очень не хватает такой информации.
Если подробнее интересны кейсы, то могу расписать на выходных.
Скореее по оценкам вероятности. Никакими законами реальности нельзя исключить что фраза "я ел пирожки с друзьями" не описывает акт каннибализма — это физически возможно и время от времени случается.
Его всё равно держать надо, поддерживать, приложение-сервисы адптировать, манифесты-чарты-операторы-что-там-ещё писать, толком не разбираясь как это делать правильно. В общм хороший такой кусок работы, на которого отдельного знающего человека надо брать.
Зачем вы вообще делаете регистрацию вместо кнопки войти через «Тут все подряд исходя из региональной специфики»?
Бизнес хочет. аккаунты соцсетей позже можно привязать и логиниться, и даже если регаться сразу, то проблемы это не решает: сущность юзера в базе всё равно нужна
Бизнес совсем не хочет слияния баз.
Он хочет именно единую базу — явно озвученное желание. Да, можно в UI/API сделать видимость единой базы, чтоб регион был лишь виртуальным или может даже реальным полем юзера, но непонятно зачем, тем более части проблем это всё равно не решит без существенной переработки основной кодовой базы, чтобы обеспечивала, например, уникальность между двумя идентичными таблицами в соседних схемах.
Вам персональные данные не нужны.
Бизнес дал список нужных им данных. Юристы проредили чтобы не высшую степень защиты обеспечивать, а то хотели и медицинские данные спрашивать чтоб таргетировать околомедицинские товары типа треккеров пульса. Но номера паспортов и ИНН нужны по закону в выбранной бизнес-модели.
Офтоп небольшой: купил недавно свой первый айфон для тестирования веб юаев и может мобдев попробовать — 12-й, так ощущение, что не смартфон ака КПК+телефон+камеру купил, а полупрофессиональный фотик с которого позвонить и початиться можно )
Как-то читаешь и ощущение, что фичи по развёртыванию пилятся в основном в расчёте на Кубер, да не один кластер. Грустно, когда других причин поднимать кластер нет, потому что очень дорого поддерживать.
Я про неудобство пользователей, которые регистрируются на разных сайтах одной компании и потом не могут найти свои покупки, например, и скандалят с саппортом, а то и пишут в спортлото и прочим регуляторам
А шардирование же вы притащили в тред, нет? Задача была озвучена как слить базы.
Ещё как связаны, особенно с ПДн в последнее время.
енумы часто текстовые (натуральные ключи) С таким синтаксисом есть гарантии что значения одного типа в енумк и могут быть переданы параметром в функцию с примитивным тайпхинтом string?
Например, участились случаи двойных регистраций пользователей и это создаёт проблемы репутации. Или регулятор потребовал что у одного юрлица должнен быть только один договор на обслуживание с одним физлицом
За второй не скажу, но с первым в докерах или типа того постоянно нюансы: их в один контейнер помещать с супервизор или системд или в разные. Чистую статику из пхп-фрейма как веб-серверу давать. Пользовательскую.
Да и вообще, два компонента обычно сложнее в разработке, разворачивание поддержке чем один.
мониторить просто любые изменения и запускать недостаточно? Слишком часто?
Я очень слабо представляю, что это такое. Не я по понимаю что это что-то вроде RSS ленты только с видео но в чем смысл
Фреймворки и прочее будут на пхп обычно, то есть средний пхп-разработчик может зайти и разобраться в ожидаемом поведение
Хотелось бы все-таки, чтобы -S годился для прода просто как запускальщик index.php условного для микросервисов
Автомасштабирование в кубере или ещ' где настраиваем — полушутка
А кто мешает? Я писал такое ещё на PHP3. Открываем сокет слушаем обрабтывае. Да, синхронно, да однопоточно, да память текла во всю тогда… Сейчас со многим лучше. Генераторы вон можно прикрутить
Да, так. При этом отношения хостов и деплойментов любое, 1..N:1..N )
На выходных прикину
Вроде редкость, когда эйчары или ещё кто приводят человека в команду и говорят "вот ваш новый коллега". Хоть один человек из команды да участвуте в процессе найма. На прошлом проекте так вообще было командное собеседование почти самое финальное, на 40-60 минут, околотехничское, но больше культурное. После обменивались мнениями и голосовали потом брать-не брать
Ого! )
Вот как раз необлачные, классические таргеты интересуют, но с контейнерами желательно. Причём c моделью несколько приложений/сервисов на одном хосте. С поддержкой блю/грин какой-то на уровне, например, конфигов nginx или haproxy. Вернее с возможностью фиксировть что приложение/сервис такой-то ревизии такой-то успешно залито на сервер такой-то в blue "половину" (или на блю-сервер) и сервер уже её обслуживает. Или создавать динамически окружения под фиче-ветку на базе технологий типа виртуальных хостов в веб-серверах. Проблема не создать даже, проблема как-то иметь информацию внутри CI/CD где что развёрнуто в таких сценариях. Как на дашбордах, так и внутри пайплайнов.
С кубером когда работал было хорошо в этом плане. Не идеально, но хорошо ), сейчас на проекте физическое и виртуальное железо в режиме "напихано всё что влезло и немного больше" и очень не хватает такой информации.
Если подробнее интересны кейсы, то могу расписать на выходных.
А потом пишут "потребители выбирают большие телефоны"...
Скореее по оценкам вероятности. Никакими законами реальности нельзя исключить что фраза "я ел пирожки с друзьями" не описывает акт каннибализма — это физически возможно и время от времени случается.
Его всё равно держать надо, поддерживать, приложение-сервисы адптировать, манифесты-чарты-операторы-что-там-ещё писать, толком не разбираясь как это делать правильно. В общм хороший такой кусок работы, на которого отдельного знающего человека надо брать.
Бизнес хочет. аккаунты соцсетей позже можно привязать и логиниться, и даже если регаться сразу, то проблемы это не решает: сущность юзера в базе всё равно нужна
Он хочет именно единую базу — явно озвученное желание. Да, можно в UI/API сделать видимость единой базы, чтоб регион был лишь виртуальным или может даже реальным полем юзера, но непонятно зачем, тем более части проблем это всё равно не решит без существенной переработки основной кодовой базы, чтобы обеспечивала, например, уникальность между двумя идентичными таблицами в соседних схемах.
Бизнес дал список нужных им данных. Юристы проредили чтобы не высшую степень защиты обеспечивать, а то хотели и медицинские данные спрашивать чтоб таргетировать околомедицинские товары типа треккеров пульса. Но номера паспортов и ИНН нужны по закону в выбранной бизнес-модели.
Офтоп небольшой: купил недавно свой первый айфон для тестирования веб юаев и может мобдев попробовать — 12-й, так ощущение, что не смартфон ака КПК+телефон+камеру купил, а полупрофессиональный фотик с которого позвонить и початиться можно )
Как-то читаешь и ощущение, что фичи по развёртыванию пилятся в основном в расчёте на Кубер, да не один кластер. Грустно, когда других причин поднимать кластер нет, потому что очень дорого поддерживать.
Я про неудобство пользователей, которые регистрируются на разных сайтах одной компании и потом не могут найти свои покупки, например, и скандалят с саппортом, а то и пишут в спортлото и прочим регуляторам
А шардирование же вы притащили в тред, нет? Задача была озвучена как слить базы.
Ещё как связаны, особенно с ПДн в последнее время.
енумы часто текстовые (натуральные ключи) С таким синтаксисом есть гарантии что значения одного типа в енумк и могут быть переданы параметром в функцию с примитивным тайпхинтом string?
Например, участились случаи двойных регистраций пользователей и это создаёт проблемы репутации. Или регулятор потребовал что у одного юрлица должнен быть только один договор на обслуживание с одним физлицом
Как в языке, который рассматривают в качестве варианта только для очень специфичных требований?