В бытовой логике люди не выигрыш максимизируют, а минимизируют проигрыш.
То есть в ситуации с красно-зеленной кнопкой вероятность потерять миллион 0% в первом случае и 50% во втором. Понятно что выберут большинство людей особенно если нажимают кнопку всего один раз, а не 50 раз в день, как трейдеры.
Минимизация проигрыша не абсолютный закон и зависит от суммы. Если это будет не миллионы, а просто рубли, то многие рискнут одним рублем чтобы получить 50 с вероятностью 50%. Многие и 100₽ рискнут для 50% выиграть 5000. Но у всех есть граница, выше которой выберут красную кнопку. Эта граница зависит не только от соотношения риска и прибыли, но и от непосредственного количества денег, которыми ты готов рисковать.
Нигде и никогда бизнес-пользователи \не читают код. Для пользователя абсолютно неважно в каком методе у вас проверка уникальности.
В реальной жизни будет ключ уникальности в базе, если базу создаете вы сами, то не сделать ключ уникальности - преступление.
Эвенты это неявный вызов, что гораздо хуже, чем явный вызов. Потому что эвенты из вызывающего кода не читаются никак и рано или поздно случится ситуация, когда эвент просто не вызовется.
У вас же UI или WebAPI вызывает в итоге какую-то функцию (контроллер\команда\handler), она свою очередь вызывает репозиторий и выполняет сохранение пользователя. Вот в эту функцию и добавьте проверку уникальности перед тем как добавлять.
Это будет явный вызов, очень читаемый и оптимальный, так как для проверки уникальности можно сделать оптимальный запрос.
Такая реализация не отменяет п2 про уникальность, потому что при всех оптимистичных проверках, не блокируя всю таблицу, можно сделать дубль.
Все что написано подходит для решения любых задач. Можно «алгоритмы» заменить на «паттерны» или «формы для субд» и все написанное будет также верно для них.
ИМХО все это ООП это набор приемов и паттернов, где-то они помогают писать код лучше, а где-то нет. А тут очередная попытка придумать или оправдать какую-то глубинную философию, которая к разработке ПО не сильно нужна.
Открытость самого блокчейна и означает "кто угодно". Вы можете в блокчейн положить зашифрованные данные, тогда "кто угодно" сужается до "тех кому известен ключ", но это уже не имеет никакого отношения к блокчейну. Можно сделать любое хранилище, такое же открытое как блокчейн, и хранящее такие же зашифрованные данные.
Децентрализация в общем смысле значит только то, что у системы нет точки централизации, всё
Это и означает что все пользователи имеют одинаковые права, в том числе по изменению данных. Это одновременно означает, что ни один участник единолично не сможет какие-то данные в блокчейне подменить.
Блокчейн, у которого 80% того, что позволяет плодить новые блоки, сконцентрировано в одних руках теряет все преимущества децентрализации. Так как эти одни руки вполне могут переписать блокчейн, внеся любые свои правки и отменив запись любого участника.
Получается что бокчейн - плохое решение для любых баз данных, где участником может быть кто угодно. Например может быть оправдан блокчейн для банков, чтобы осуществлять межбанковские переводы, но блокчейн для выборов - профанация в чистом виде.
Блокчейн это открытое (то есть кто угодно может посмотреть все данные) и децентрализованное (то есть кто угодно может внести изменение) хранилище. Оба свойства обязательны, нельзя как-то убрать или уменьшить одно из них, чтобы блокчейн оставался оправданным.
Традиционная база данных это централизованное хранилище, которое может быть как открытым, так и ограниченным.
Что нужно от хранилища для паспортов? Однозначно оно не должно быть открытым, иначе множество злоумышленников смогут выдавать себя за других граждан. Поэтому увы, блокчейн тут не подойдет.
Чтобы посчитать проблему стоит тогда начинать сначала, с того сколько заработал бизнес пока эта проблема существовала
Не понимаю зачем, ваш софт как-то влияет на доходы компании? Если нет, то эти сведения вам не нужны. Даже если влияет, то вам все равно необязательно считать в деньгах, посчитайте в количестве заказов\отказов\конверсии или других натуральных величинах.
В большинстве случаев разработка софта формирует расходы, поэтому вы вполне можете посчитать в трудочасах. Если не можете, то проблемы нет или слишком большая неопределенность.
Хотя при этом есть стандарты и законы предписывающие соблюдать их. Только, пока, не в IT
К сожалению вы тут апеллируете к тому, в чем не разбираетесь. Это кстати тоже сигнал для руководителя верхнего уровня, что вы недостаточно понимаете о чем говорите.
Вопрос "что мне\компании это даст" это предложение посчитать проблему\предложение в деньгах или в других единицах, которые легко в деньги конвертировать. В трудозатратах например.
"Удобство" и "улучшение условий труда" это не измеримые величины.
Прочитав вашу статью очередной раз убедился, что если вы не можете объяснит проблему, то вы её недостаточно понимаете.
К сожалению разработка ПО по большей части ведется не здравым смыслом, а модой, или навязанными заблуждениями или желанием добавить строчку в резюме. Руководители высокого уровня это прекрасно понимают задают вам (программистам и непосредственным руководителям) вопросы не потому, что они не понимают, а потому что вы не понимаете.
Это я даже не говорю о том, что любую проблему можно посчитать в сроках и деньгах. Не одним точным значением, это нереально, а в виде вероятностного распределения. Если вы хотите общаться с руководителями высокого уровня, то вам нужно учиться общаться на языке цифр.
Оракл - не поддерживает блокировки, поэтому не умеет делать честную сериализуемость.
insert into t(v) select count(*) from t
С точки зрения концепции сериализуемости, запрос выше, запущенный параллельно во множестве транзакций, должен дать возрастающую последовательность чисел в таблице. Оракл так не умеет, у него будут повторения пропуски или ошибки. Хотя формально Оракл соответствует стандарту и не допускает фантомного чтения. MS SQL, Postgres, MySQL прекрасно справляются с таким запросом и выдают ожидаемый результат.
Я ведь правильно понял, что вся бизнес-логика сводится к двум запросам вида:
update Seats
set ClientId = @clientId
where SessionId = @seesionId and Number = @number and Type = @type
Так?
Для этого точно надо делать три проекта, не считая тестов? В чем преимущество от трех проектов?
Сейчас от обилия кода есть даже ошибки - два запроса на бронирование одного места могут вернуть 200 Ok, но купить место сможет только последний. Если добавятся переходы состояний, то количество таких ошибок увеличится.
Мне кажется не стоит применять слово «измерение» к опросам. «Измерение» предполагает получение объективной метрики, опросы изначально субъективны. Стоит использовать слово «оценка» или «сбор отзывов»
и конкретики мало в статье, разбавили бы примерами из вашей практики - что было, что поменяли, как изменились отзывы.
Когда пример более сложный все остальные способы тоже так себе работают.
zig и отчасти rust
а также, внезапно, C# - Собираем автономную игру на C# в 2 килобайтах / Хабр (habr.com)
Бытовая логика работает не так.
В бытовой логике люди не выигрыш максимизируют, а минимизируют проигрыш.
То есть в ситуации с красно-зеленной кнопкой вероятность потерять миллион 0% в первом случае и 50% во втором. Понятно что выберут большинство людей особенно если нажимают кнопку всего один раз, а не 50 раз в день, как трейдеры.
Минимизация проигрыша не абсолютный закон и зависит от суммы. Если это будет не миллионы, а просто рубли, то многие рискнут одним рублем чтобы получить 50 с вероятностью 50%. Многие и 100₽ рискнут для 50% выиграть 5000. Но у всех есть граница, выше которой выберут красную кнопку. Эта граница зависит не только от соотношения риска и прибыли, но и от непосредственного количества денег, которыми ты готов рисковать.
Нигде и никогда бизнес-пользователи \не читают код. Для пользователя абсолютно неважно в каком методе у вас проверка уникальности.
В реальной жизни будет ключ уникальности в базе, если базу создаете вы сами, то не сделать ключ уникальности - преступление.
Эвенты это неявный вызов, что гораздо хуже, чем явный вызов. Потому что эвенты из вызывающего кода не читаются никак и рано или поздно случится ситуация, когда эвент просто не вызовется.
У вас же UI или WebAPI вызывает в итоге какую-то функцию (контроллер\команда\handler), она свою очередь вызывает репозиторий и выполняет сохранение пользователя. Вот в эту функцию и добавьте проверку уникальности перед тем как добавлять.
Это будет явный вызов, очень читаемый и оптимальный, так как для проверки уникальности можно сделать оптимальный запрос.
Такая реализация не отменяет п2 про уникальность, потому что при всех оптимистичных проверках, не блокируя всю таблицу, можно сделать дубль.
Все что написано подходит для решения любых задач. Можно «алгоритмы» заменить на «паттерны» или «формы для субд» и все написанное будет также верно для них.
ИМХО все это ООП это набор приемов и паттернов, где-то они помогают писать код лучше, а где-то нет. А тут очередная попытка придумать или оправдать какую-то глубинную философию, которая к разработке ПО не сильно нужна.
Как говорится code talks, bullshit walks
Люди не понимают ООП, в том числе автор этой статьи
Наверное лучшая статья на хабре всех времен и народов
Посмотрите на сами запросы, там предикаты джоинов заставляют плакать query planner.
Buzzword driven development
Открытость самого блокчейна и означает "кто угодно". Вы можете в блокчейн положить зашифрованные данные, тогда "кто угодно" сужается до "тех кому известен ключ", но это уже не имеет никакого отношения к блокчейну. Можно сделать любое хранилище, такое же открытое как блокчейн, и хранящее такие же зашифрованные данные.
Это и означает что все пользователи имеют одинаковые права, в том числе по изменению данных. Это одновременно означает, что ни один участник единолично не сможет какие-то данные в блокчейне подменить.
Блокчейн, у которого 80% того, что позволяет плодить новые блоки, сконцентрировано в одних руках теряет все преимущества децентрализации. Так как эти одни руки вполне могут переписать блокчейн, внеся любые свои правки и отменив запись любого участника.
Получается что бокчейн - плохое решение для любых баз данных, где участником может быть кто угодно. Например может быть оправдан блокчейн для банков, чтобы осуществлять межбанковские переводы, но блокчейн для выборов - профанация в чистом виде.
Как это связано?
Блокчейн это открытое (то есть кто угодно может посмотреть все данные) и децентрализованное (то есть кто угодно может внести изменение) хранилище. Оба свойства обязательны, нельзя как-то убрать или уменьшить одно из них, чтобы блокчейн оставался оправданным.
Традиционная база данных это централизованное хранилище, которое может быть как открытым, так и ограниченным.
Что нужно от хранилища для паспортов? Однозначно оно не должно быть открытым, иначе множество злоумышленников смогут выдавать себя за других граждан. Поэтому увы, блокчейн тут не подойдет.
Не понимаю зачем, ваш софт как-то влияет на доходы компании? Если нет, то эти сведения вам не нужны. Даже если влияет, то вам все равно необязательно считать в деньгах, посчитайте в количестве заказов\отказов\конверсии или других натуральных величинах.
В большинстве случаев разработка софта формирует расходы, поэтому вы вполне можете посчитать в трудочасах. Если не можете, то проблемы нет или слишком большая неопределенность.
К сожалению вы тут апеллируете к тому, в чем не разбираетесь. Это кстати тоже сигнал для руководителя верхнего уровня, что вы недостаточно понимаете о чем говорите.
Вопрос "что мне\компании это даст" это предложение посчитать проблему\предложение в деньгах или в других единицах, которые легко в деньги конвертировать. В трудозатратах например.
"Удобство" и "улучшение условий труда" это не измеримые величины.
С в CAP это A в ACID
Прочитав вашу статью очередной раз убедился, что если вы не можете объяснит проблему, то вы её недостаточно понимаете.
К сожалению разработка ПО по большей части ведется не здравым смыслом, а модой, или навязанными заблуждениями или желанием добавить строчку в резюме. Руководители высокого уровня это прекрасно понимают задают вам (программистам и непосредственным руководителям) вопросы не потому, что они не понимают, а потому что вы не понимаете.
Это я даже не говорю о том, что любую проблему можно посчитать в сроках и деньгах. Не одним точным значением, это нереально, а в виде вероятностного распределения. Если вы хотите общаться с руководителями высокого уровня, то вам нужно учиться общаться на языке цифр.
Оракл - не поддерживает блокировки, поэтому не умеет делать честную сериализуемость.
С точки зрения концепции сериализуемости, запрос выше, запущенный параллельно во множестве транзакций, должен дать возрастающую последовательность чисел в таблице. Оракл так не умеет, у него будут повторения пропуски или ошибки. Хотя формально Оракл соответствует стандарту и не допускает фантомного чтения. MS SQL, Postgres, MySQL прекрасно справляются с таким запросом и выдают ожидаемый результат.
Я ведь правильно понял, что вся бизнес-логика сводится к двум запросам вида:
Так?
Для этого точно надо делать три проекта, не считая тестов? В чем преимущество от трех проектов?
Сейчас от обилия кода есть даже ошибки - два запроса на бронирование одного места могут вернуть 200 Ok, но купить место сможет только последний. Если добавятся переходы состояний, то количество таких ошибок увеличится.
Мне кажется не стоит применять слово «измерение» к опросам. «Измерение» предполагает получение объективной метрики, опросы изначально субъективны. Стоит использовать слово «оценка» или «сбор отзывов»
и конкретики мало в статье, разбавили бы примерами из вашей практики - что было, что поменяли, как изменились отзывы.