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

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

это напрямую на конверсию влияет

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

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

Ах да, у меня юзернеймы уникальные потому что ссылки на профили вида site/u/Vasya123

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

не надо оперировать плохими примерами

Ах да, у меня юзернеймы уникальные потому что ссылки на профили вида site/u/Vasya123

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

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

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

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

проведи как-нибудь соц опрос как много людей этим пользуются

в твоем сучае - да скорее всего это лучший вариант. Но вообще всем пофиг

Посмотрим.. Опрос сделаю через пару месяцев, вернусь ещё, может статистика какая то ещё появится типа сколько зарегистровалось через соц сети а сколько через емейл+пароль

Привет всем! Думаю, что в тему будет вопрос. Нужна БД для аналитики. В данный момент mysql и crateDb уже не вывозят 800кк записей, количество колонок достаточно большое Почему сюда пишу, надо чтобы поддержка php была)) может кто работает с такими объемами данных?

Требуются агригации по 20кк и более данных

Привет всем! Думаю, что в тему будет вопрос. Нужна БД для аналитики. В данный момент mysql и crateDb уже не вывозят 800кк записей, количество колонок достаточно большое Почему сюда пишу, надо чтобы поддержка php была)) может кто работает с такими объемами данных?

зависит от данных

Раньше крэйт вывозил, но раньше и проходиться по 10кк надо было за раз

если там стандартные для аналитики данные, которые всегда требуют агрегации - касандра, инфлуксдб

а теперь тупо памяти не хватает((

time series в influxDB хорошо идут но серьёзную нагрузку не пробовал, хотя должно работать ок

кликхаус?

ок, буду читать

кликхаус отпал в связи с отсутствием возможности удаления и изменения

чтобы база не пухла мы дополняем данные по часам

в месяц залетает порядка 15-20кк данных

и это уже по часу собранные

кликхаус отпал в связи с отсутствием возможности удаления и изменения

воу воу, аналитика ж, зачем удалять/менять?

чтобы база не пухла мы дополняем данные по часам

возьмите базу оптимизированную под time series данные - на ту же касандру не влияет объем данных

а диск штука дешевая

короч надо больше знать о том что вы там храните и что делаете с данными

influxDB, retention policies, continuous queries

influxDB, retention policies, continuous queries

да, или так

чтобы база не пухла мы дополняем данные по часам

в кх немного другой подход, насколько я понял - лучше делать исходную таблицу - лог данных (собственно facts) и потом навешивать materialized views (projections). В таком случае и изменять данные не нужно (посколько обучно аналитические ивенты иммутабельны).

а если правило такое: "Нельзя постить > 3 постов в день с аккаунта", тогда как его проверять? Тоже при помощи БД, в смысле проверять в триггерах и кидать эксепшены?

это уже бизнес-логика

а если правило такое: "Нельзя постить > 3 постов в день с аккаунта", тогда как его проверять? Тоже при помощи БД, в смысле проверять в триггерах и кидать эксепшены?

можно на каждый пост запоминать дату последнего поста и перед постом чекать что все ок. Много вариантов

это уже бизнес-логика

Допустим проверка будет на уровне домена, но в промежутке между закончившейся проверкой и записью в БД может записаться ещё пост, тогда постов в БД будет 4

транзакции в помощь

Допустим проверка будет на уровне домена, но в промежутке между закончившейся проверкой и записью в БД может записаться ещё пост, тогда постов в БД будет 4

можно хоть лок через рэдис делать, вариантов реально куча

в 90% случаев люди даже не будут сильно париться с таким кейсом

транзакции в помощь

ну да, вроде логично, спасибо

можно хоть лок через рэдис делать, вариантов реально куча

к сожалению я не знаком с редисом и вообще с кешированием реально почти незнаком. Вообще-то я и с SQL-то не знаком :D

редис на уровне key\value асилит даже ботинок)

это радует, т.к. я аж целый сапог!

Вообще ещё интересно как это (правило > 3 постов) проверять в коде. Т.к. это вроде как бизнес правило, то проверка должна быть где-то в домене (и тут кстати возникает вопрос - является ли валидация частью домена?). Если делать проверку где-то в методах агрегатов - тогда им нужен будет репозиторий и будет зависимость от репозитория, что по-моему выглядит довольно плохо

я как то не уверен, что "правило > 3 поста" является валидацией

Вообще ещё интересно как это (правило > 3 постов) проверять в коде. Т.к. это вроде как бизнес правило, то проверка должна быть где-то в домене (и тут кстати возникает вопрос - является ли валидация частью домена?). Если делать проверку где-то в методах агрегатов - тогда им нужен будет репозиторий и будет зависимость от репозитория, что по-моему выглядит довольно плохо

вопрос не в том является ли валидация частью домена, а понимаешь ли ты что валидация разной бывает. и какая-то часть домена (проверка инвариантов и прекондишенов) а какая-то часть UI логики

проверка этого правила

я как то не уверен, что "правило > 3 поста" является валидацией

это инвариант

я как то не уверен, что "правило > 3 поста" является валидацией

вот мне тоже кажется, что это правило предметной области

вопрос не в том является ли валидация частью домена, а понимаешь ли ты что валидация разной бывает. и какая-то часть домена (проверка инвариантов и прекондишенов) а какая-то часть UI логики

это вроде бы понятно. По-моему данная проверка является частью домена

инвариант

разберись со значением этого умного слова

Как я понял - это правило предметной области, правда меня смущает то, что есть ещё прекондишены и посткондишены

они тоже правила) просто инварианты это про стэйт а прекондишены и посткондишены про то что на вход приходит и на выход

то есть прекондишены проверяют входные данные, посткондишены - выходные, а инварианты - состояние?

разберись со значением этого умного слова

x2

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

тайпхинты значит - один из вариантов прекондишенов и посткондишенов, правда с ограниченной функциональностью и встроенные в язык?

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

почему не может?

тайпхинты значит - один из вариантов прекондишенов и посткондишенов, правда с ограниченной функциональностью и встроенные в язык?

дэ

почему с ограниченной функциональностью, у тебя тип может быть Apple

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

Вот тут и возникает проблема, как я могу проверить сколько у меня яблок в ящике, если их у меня в ящике на самом деле нет (на загружены из базы)? Или это решается при помощи загрузки яблок через прокси и тогда проверяется, что их не больше 3х?

почему не может?

потому что у ящика такой инвариант

Вот тут и возникает проблема, как я могу проверить сколько у меня яблок в ящике, если их у меня в ящике на самом деле нет (на загружены из базы)? Или это решается при помощи загрузки яблок через прокси и тогда проверяется, что их не больше 3х?

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

ERROR: S client not available

в случае с каким-нибудь active record все похоже но чуть отличается

но это не "валидация входящих данных" это проверка инвариантов, бизнес логика твоя

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

но это не "валидация входящих данных" это проверка инвариантов, бизнес логика твоя

с этим я разобрался, да (ну ладно, мне кажется, что разобрался :D )

но это не "валидация входящих данных" это проверка инвариантов, бизнес логика твоя

инварианты - это правила для состояния объекта?

похоже но это не оно (а может и оно - it depends)

инварианты - это правила для состояния объекта?

да, объекта или системы в целом

но тогда, если будет 1 проверка в валидации и 2 в виде инварианта - данные придётся загружать 2 раза, что выглядит очень плохо с точки зрения производительности

но тогда, если будет 1 проверка в валидации и 2 в виде инварианта - данные придётся загружать 2 раза, что выглядит очень плохо с точки зрения производительности

обычно для проверки входящих данных ничего загружать не надо

тогда при нарушении инварианта кидать эксепшен, обрабатывать его (как и в случае с unique constraint) и показывать пользователю?

ну то есть нарушение инварианта в таком случае не исключительная ситуация а обыденность, раз у тебя для этого красивая сообщенька юзеру есть

просто я не понимаю как это всё соединять с валидацией, т.к. для пользователя это всё просто набор ошибок

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

это больше к вопросу UX

как сделать так что бы кнопки небыло что бы ошибку не надо было показывать

Это вообще никакого отношения к валидации не имеет

Это вообще никакого отношения к валидации не имеет

кнопку не показывать?) тебе не надо ничего валидировать если пользователь ничего не может сделать)

но ответ от сервера-то может содержать и данные результата валидации и данные о нарушении инварианта

может, и что? а еще ответ может содержать как ошибку так и какой-то результат

ты ж из этого трагедию не делаешь

кнопку не показывать?) тебе не надо ничего валидировать если пользователь ничего не может сделать)

Это я к сообщению Артёма о том как объединить валидацию и инварианты. Да никак не надо, разные кейсы имхо

Ребят

Помогите сделать проверку только на цифры

Какой регистр это?

?‍♂️

Какой регистр это?

Верхний

простите, не сдержался...

is_numeric() ф-я

Какой регистр это?

Зависит от архитектуры процессора

отправляй с такими вопросами в @phpGeeksJunior, пускай там спрашивает