Обновить
41
Станислав Цаплев@sophist

Пользователь

Отправить сообщение

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

Модель не понимает контекста вашего бизнеса, она просто воспроизводит паттерны, которые «видела» раньше.

Пока не понимает

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

хитроумный

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

Можете воспринимать EvoVer, как CalVer 2.0.0

Как CalVer 2026.01, извините :)

Я и сказал в первом комментарии, что то, что в статье, – конкретика на уровне UI – это антипаттерн для User Story. И в критериях приемки, и в самом требовании.

С какой стороны разбивать яйца добавлять версию -- не принципиальный вопрос. Принципиальный вопрос: на каком уровне версионировать -- на уровне метода, ресурса, модуля или всего API?

А какая разница? Это все равно будет версия метода, а не всего API, только это станет еще и неочевидно

Под способом реализации вы, видимо, понимаете способ реализации в коде. Для этого случая существует такой формат, как пользовательский сценарий (Use Case), и он действительно идеально подходит для разработчика.

Но в статье речь идет о другом формате, о формате User Story. И в нем под способом реализации понимается как раз "как эта штука будет работать", чтобы удовлетворить потребность пользователя.

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

Через какие элементы управления это будет реализовано и в каком порядке будет нужно с ними взаимодействовать -- остается на усмотрение исполнителя. (User Story -- это Agile-артефакт).

Имеете право. Но это не единственно возможный подход: вот, например, другие. А в этой и в этой статьях можно найти описание тонких различий между этими понятиями.

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

С этим не спорю. Я про то, что "ценностью можно лишь наслаждаться". Люди, которые ставят во главу угла что-либо (деньги, интеллект, you name it), не обязательно наслаждаются этим. И наоборот, те, кто наслаждаются, не обязательно видят в этом жизненный ориентир

...инструментом можно пользоваться, а вот ценностью - лишь наслаждаться

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

А эмоции мы не слушаем – это оставьте всяким иррациональным господам и дамам.

По-хорошему, стоит разделять две ортогональных друг другу бинарных оппозиции: рассудок-эмоции и рациональное-иррациональное.

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

А иррациональное + рассудок вот:

Выход есть! Нужно просто найти логичные аргументы какими бы бредовыми они ни были, что у данного поступка есть логичное обоснование.

Дарю идею: 3D-визуализатор карт предметной области / ментальных карт.

1
23 ...

Информация

В рейтинге
Не участвует
Откуда
Ярославль, Ярославская обл., Россия
Дата рождения
Зарегистрирован
Активность

Специализация

Системный аналитик