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

кажется я начал понимать. Ты о том, что можно после добавления третьего яблока (инвариант не больше трёх яблок в ящике) дисеблить/скрывать etc кнопку добавления следующего яблока и тогда не будет необходимости в сообщении пользователю о нарушении инварианта?

Кто нибудь знает как войти в google mail через curl?

Кто нибудь знает как войти в google mail через curl?

у них вроде api есть

через api можно гугл формы пройти на 1000 акках?

для такой автоматизации люто рекомендую nightmarejs

спасибо,а есть примеры nightmarejs?

кажется я начал понимать. Ты о том, что можно после добавления третьего яблока (инвариант не больше трёх яблок в ящике) дисеблить/скрывать etc кнопку добавления следующего яблока и тогда не будет необходимости в сообщении пользователю о нарушении инварианта?

именно. А заодно ты улучшишь UX. не следует давать пользователям делать то, что не будет работать

у тебя есть кнопка, ты на нее нажимаешь и тебе пишет "тебе нельзя жать эту кнопку" а ты такой "ну ахуеть теперь!"

нет кнопки - нет и негативных эмоций связанных с ошибками

главное не дойти до "нет человека - нет проблемы" :D

опять же, по поводу "нет человека нет проблемы"

https://www.youtube.com/watch?v=GRr4xeMn1uU

вот тут хороший пример что people as service это не такая плохая идея

ух ты, greg young, какие-то статьи я видел его, то ли про ES то ли про CQRS, не помню

Парни, короче, есть пакет для работы с RPC интерфейсом. Вся суть - отправка команд и обработка результата. При этом обработка результата может быть простой (тупо вычленить result и вернуть), так и сложной (выдернуть данные из result, вычленить какие то определенные поля, и всякое разное). Так вот, вопрос - как мне разделить сложные и простые запросы, что бы это архитектурно выглядело нормально?

ах да, пакет существует пока только в моей голове

(как бы странно не звучало)

похоже что никто в пятницу вечером не хочет думать :D

ух ты, greg young, какие-то статьи я видел его, то ли про ES то ли про CQRS, не помню

ну он термин CQRS ввел - ему можно на эту тему статьи писать

Парни, короче, есть пакет для работы с RPC интерфейсом. Вся суть - отправка команд и обработка результата. При этом обработка результата может быть простой (тупо вычленить result и вернуть), так и сложной (выдернуть данные из result, вычленить какие то определенные поля, и всякое разное). Так вот, вопрос - как мне разделить сложные и простые запросы, что бы это архитектурно выглядело нормально?

"архитектурно выглядело" - какое значение ты вкладываешь в эту фразу?

с соблюдением DRY, например

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

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

вообще я смутно вижу это все, т.к. впервые сталкиваюсь

похоже что никто в пятницу вечером не хочет думать :D

я думаю у меня недостаточно квалификации, чтобы тебе что-то подсказать дельного. Вообще, когда начинаются разговоры про удалённые вызовы, то у меня возникают ассоциации с bounded context-ами и anti corruption layer-ами, но я так понимаю у тебя не та ситуация, у тебя контекст один и тот же, только на разных машинах. Но типа модель-то всё равно после того как данные пришли надо восстановить Короче фигню сказал :D

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

тогда получится, что у меня половина методов будет магически дергаться через один коллбэк (тупо возвращая результат), а вторая половина будет в виде крупных классов, разбирающих результат...

это норм вообще?)

Он называется value object

Отдельный класс

Ну или dto

Но dto чуть другое

вообще я смутно вижу это все, т.к. впервые сталкиваюсь

введи ограничение - максимум два метода на объект. И попробуй через это ограничение посмотреть на твою систему.

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

второе полезное ограничение - максимум 2 аргумента у метода

(цифры тут реально с потолка, просто что бы было ограничение. В условии ограничений ты начинаешь думать)

не хотите ли добавить в ваши методы флаги? :D

вообще если кто-то хочет побаловаться на выходных и поднять свои скилы декомпозиции и проектирования: https://habr.com/post/206802/

второе полезное ограничение - максимум 2 аргумента у метода

Если 2 необязательных аргумента то не очень, 2 обязательных аргумента так точней

Если 2 необязательных аргумента то не очень, 2 обязательных аргумента так точней

ммм.... пожалуй да

В книге эти цифры видел

Забыл название

ну там обычно 3 пишут - в clean code и у макконала

спасибо :)

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

https://www.youtube.com/watch?v=GRr4xeMn1uU

я уже приготовился слушать заумные и абстрактные объяснения, а там ржака :D

грег веселый чел, один из лучших спикеров. Еще Уди посмотри.

Udi Dahan

тоже знакомое имя

Пытаюсь авторизироваться в фейсбуке из джаваскрипта и мне выдаёт feature not available... Кто-нибудь с этим сталкивался? В гугле пустовато по этому вопросу.

Пытаюсь авторизироваться в фейсбуке из джаваскрипта и мне выдаёт feature not available... Кто-нибудь с этим сталкивался? В гугле пустовато по этому вопросу.

Причем тут php?

Пытаюсь авторизироваться в фейсбуке из джаваскрипта и мне выдаёт feature not available... Кто-нибудь с этим сталкивался? В гугле пустовато по этому вопросу.

тебе сюда https://t.me/js_ru

Не при чём, тупанул. Просто бекенд пишу, а js клиент для теста нарисовал, вот по привычке в пхп чат и написал

нормально ли делать вместо этого: 'web3_clientVersion' => [ 'params' => [...] ] это: 'web3_clientVersion' => [ self::PARAMS_LABEL => [...] ] ?

или совсем наркомания

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

в моем случае будет очень много таких элементов повторяющихся

в моем случае будет очень много таких элементов повторяющихся

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

нормально ли делать вместо этого: 'web3_clientVersion' => [ 'params' => [...] ] это: 'web3_clientVersion' => [ self::PARAMS_LABEL => [...] ] ?

А почему не класс с одним свойством?

чего?

чего?

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

А. Разумно

ну там обычно 3 пишут - в clean code и у макконала

У макконела 5-7

У макконела 5-7

ебать говнокодер

ERROR: S client not available

ебать говнокодер

Макконелл?

ну не тыж

Ну и не ты)

Остаётся только Макконелл

Привет всем. Кто подскажет по frontend, куда капать? Есть список модулей их можно друг с другом соединять, выбирая перед этим два модуля и потом указываешь параметры, вот этот список может меняться и некоторые данные иногда запрашивается у сервака. Как это лучше реализовать?

Привет всем. Кто подскажет по frontend, куда капать? Есть список модулей их можно друг с другом соединять, выбирая перед этим два модуля и потом указываешь параметры, вот этот список может меняться и некоторые данные иногда запрашивается у сервака. Как это лучше реализовать?

формализуй задачу получше

но вообще по хорошему это оффтоп так как тут не та специфика чата

ну там обычно 3 пишут - в clean code и у макконала

3-5 вроде, но больше 3х - много. А После выведения неопределённого количества - вообще слов нет.

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

если у меня таки должно быть сообщение юзеру, то есть инвариант не исключительная ситуация, то как тогда оповестить юзера о том, что он пытается нарушить инвариант (и какой конкретно инвариант)? Ведь для ящика может быть несколько инвариантов, проверяемых в одном методе, а юзеру надо знать какой именно был нарушен. Получается public function putApple(Apple $apple) : bool написать не выйдет. Создавать внутри putApple объект с результатом операции? Возвращать код ошибки?

не, нарушение инварианта это вполне себе исключительная ситуация

> юзеру надо знать какой именно был нарушен. а надо ли? и это надо юзеру знать или тебе?

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

а так его должно устроить что-то типа "Упс, чет пошло не так"

просто в реальности обычно бизнес требует, чтобы сообщение было конкретное

аргумент такой, что пользователь должен знать о правилах домена

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

тогда это не инвариант получается =\ Но и не валидация. Тогда непонятно, что это такое :D

аргумент такой, что пользователь должен знать о правилах домена

нет кнопки - не надо объяснять почему на нее нельзя нажимать

это вопрос как ты проектируешь UI твоего приложения

есть два подхода - классический CRUD где что делать выясняют из пришедших данных и task based ui

последнее сложнее, дороже но удобнее

нет кнопки - не надо объяснять почему на нее нельзя нажимать

тут есть один момент. Обычно сервер не может клиенту сообщить о текущем состоянии модели. Эта проверка будет только при запросе. Например на аккаунте будет 2 пользователя. Один добавит последнее яблоко, а интерфейс второго не обновится. Хотя может это уже тот самый оверинжениринг =\

тут есть один момент. Обычно сервер не может клиенту сообщить о текущем состоянии модели. Эта проверка будет только при запросе. Например на аккаунте будет 2 пользователя. Один добавит последнее яблоко, а интерфейс второго не обновится. Хотя может это уже тот самый оверинжениринг =\

у меня сокеты, мне проще)

сегодня добавить реалтайм обновление данных не оч дорого

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

вот я об этом и думаю

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

как пример - представь себе заказ такси например

не очень себе представляю, если честно :D

тогда это не инвариант получается =\ Но и не валидация. Тогда непонятно, что это такое :D

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

люди часто это путают, скорее всего потому что привыкли валидировать active record модель

ну и опять же загоны выше актуальны когда у тебя task based ui, если у тебя CRUD - там все проще