Все что написано подходит для решения любых задач. Можно «алгоритмы» заменить на «паттерны» или «формы для субд» и все написанное будет также верно для них.
ИМХО все это ООП это набор приемов и паттернов, где-то они помогают писать код лучше, а где-то нет. А тут очередная попытка придумать или оправдать какую-то глубинную философию, которая к разработке ПО не сильно нужна.
Открытость самого блокчейна и означает "кто угодно". Вы можете в блокчейн положить зашифрованные данные, тогда "кто угодно" сужается до "тех кому известен ключ", но это уже не имеет никакого отношения к блокчейну. Можно сделать любое хранилище, такое же открытое как блокчейн, и хранящее такие же зашифрованные данные.
Децентрализация в общем смысле значит только то, что у системы нет точки централизации, всё
Это и означает что все пользователи имеют одинаковые права, в том числе по изменению данных. Это одновременно означает, что ни один участник единолично не сможет какие-то данные в блокчейне подменить.
Блокчейн, у которого 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, но купить место сможет только последний. Если добавятся переходы состояний, то количество таких ошибок увеличится.
Мне кажется не стоит применять слово «измерение» к опросам. «Измерение» предполагает получение объективной метрики, опросы изначально субъективны. Стоит использовать слово «оценка» или «сбор отзывов»
и конкретики мало в статье, разбавили бы примерами из вашей практики - что было, что поменяли, как изменились отзывы.
Простые и стандартизованные бизнес-процессы имеются только в простых и стандартизованных бизнесах. Таких бизнесов с выручкой выше порога упрощенки я не знаю. Все процессы в них сложно подвести под какие-то стандарты.
Казалось бы ваш аргумент про относительно молодой бизнес может иметь место, но ведь и весь "большой" софт существует те же 30 лет. А многие (если быть честным - все) наши крупняки пользовались услугами западных консультантов, которые несут "лучшие практики".
Тем не менее стандартизация существует и нужна. Но не в автоматизации бизнес-процессов, а в методах управленческого учета.
Увеличивать прибыль можно как уменьшением затрат, так и увеличением выручки.
Выручка может увеличиваться за счет: увеличения количества клиентов (автоматизация маркетинга, повышение конверсии), за счет увеличения среднего чека (продажа большего количества товаров или услуг, допродажи), а также за счет увеличения пропускной способности конвейера от контакта до получения денег и отгрузки.
Кроме того, есть такая категория ПО как "управленческое", которое помогает более качественно принимать управленческие решения. Оно само по себе не влияет ни на какие финансовые характеристики компании, но помогает менеджерам меньше тратить и больше зарабатывать. Недавно был пример: внедрение системы прогнозирования платежей помогла понять что в конце года будет большой НДС и менеджеры побежали договариваться отправлять платежи контрагентам, чем сэкономили десятки миллионов налогов.
Это я все к чему: От софта обязательно должен быть экономический эффект. Но до внедрения просчитать его может быть невозможно.
Все что написано подходит для решения любых задач. Можно «алгоритмы» заменить на «паттерны» или «формы для субд» и все написанное будет также верно для них.
ИМХО все это ООП это набор приемов и паттернов, где-то они помогают писать код лучше, а где-то нет. А тут очередная попытка придумать или оправдать какую-то глубинную философию, которая к разработке ПО не сильно нужна.
Как говорится code talks, bullshit walks
Люди не понимают ООП, в том числе автор этой статьи
Наверное лучшая статья на хабре всех времен и народов
Посмотрите на сами запросы, там предикаты джоинов заставляют плакать query planner.
Buzzword driven development
Открытость самого блокчейна и означает "кто угодно". Вы можете в блокчейн положить зашифрованные данные, тогда "кто угодно" сужается до "тех кому известен ключ", но это уже не имеет никакого отношения к блокчейну. Можно сделать любое хранилище, такое же открытое как блокчейн, и хранящее такие же зашифрованные данные.
Это и означает что все пользователи имеют одинаковые права, в том числе по изменению данных. Это одновременно означает, что ни один участник единолично не сможет какие-то данные в блокчейне подменить.
Блокчейн, у которого 80% того, что позволяет плодить новые блоки, сконцентрировано в одних руках теряет все преимущества децентрализации. Так как эти одни руки вполне могут переписать блокчейн, внеся любые свои правки и отменив запись любого участника.
Получается что бокчейн - плохое решение для любых баз данных, где участником может быть кто угодно. Например может быть оправдан блокчейн для банков, чтобы осуществлять межбанковские переводы, но блокчейн для выборов - профанация в чистом виде.
Как это связано?
Блокчейн это открытое (то есть кто угодно может посмотреть все данные) и децентрализованное (то есть кто угодно может внести изменение) хранилище. Оба свойства обязательны, нельзя как-то убрать или уменьшить одно из них, чтобы блокчейн оставался оправданным.
Традиционная база данных это централизованное хранилище, которое может быть как открытым, так и ограниченным.
Что нужно от хранилища для паспортов? Однозначно оно не должно быть открытым, иначе множество злоумышленников смогут выдавать себя за других граждан. Поэтому увы, блокчейн тут не подойдет.
Не понимаю зачем, ваш софт как-то влияет на доходы компании? Если нет, то эти сведения вам не нужны. Даже если влияет, то вам все равно необязательно считать в деньгах, посчитайте в количестве заказов\отказов\конверсии или других натуральных величинах.
В большинстве случаев разработка софта формирует расходы, поэтому вы вполне можете посчитать в трудочасах. Если не можете, то проблемы нет или слишком большая неопределенность.
К сожалению вы тут апеллируете к тому, в чем не разбираетесь. Это кстати тоже сигнал для руководителя верхнего уровня, что вы недостаточно понимаете о чем говорите.
Вопрос "что мне\компании это даст" это предложение посчитать проблему\предложение в деньгах или в других единицах, которые легко в деньги конвертировать. В трудозатратах например.
"Удобство" и "улучшение условий труда" это не измеримые величины.
С в CAP это A в ACID
Прочитав вашу статью очередной раз убедился, что если вы не можете объяснит проблему, то вы её недостаточно понимаете.
К сожалению разработка ПО по большей части ведется не здравым смыслом, а модой, или навязанными заблуждениями или желанием добавить строчку в резюме. Руководители высокого уровня это прекрасно понимают задают вам (программистам и непосредственным руководителям) вопросы не потому, что они не понимают, а потому что вы не понимаете.
Это я даже не говорю о том, что любую проблему можно посчитать в сроках и деньгах. Не одним точным значением, это нереально, а в виде вероятностного распределения. Если вы хотите общаться с руководителями высокого уровня, то вам нужно учиться общаться на языке цифр.
Оракл - не поддерживает блокировки, поэтому не умеет делать честную сериализуемость.
С точки зрения концепции сериализуемости, запрос выше, запущенный параллельно во множестве транзакций, должен дать возрастающую последовательность чисел в таблице. Оракл так не умеет, у него будут повторения пропуски или ошибки. Хотя формально Оракл соответствует стандарту и не допускает фантомного чтения. MS SQL, Postgres, MySQL прекрасно справляются с таким запросом и выдают ожидаемый результат.
Я ведь правильно понял, что вся бизнес-логика сводится к двум запросам вида:
Так?
Для этого точно надо делать три проекта, не считая тестов? В чем преимущество от трех проектов?
Сейчас от обилия кода есть даже ошибки - два запроса на бронирование одного места могут вернуть 200 Ok, но купить место сможет только последний. Если добавятся переходы состояний, то количество таких ошибок увеличится.
Мне кажется не стоит применять слово «измерение» к опросам. «Измерение» предполагает получение объективной метрики, опросы изначально субъективны. Стоит использовать слово «оценка» или «сбор отзывов»
и конкретики мало в статье, разбавили бы примерами из вашей практики - что было, что поменяли, как изменились отзывы.
Простые и стандартизованные бизнес-процессы имеются только в простых и стандартизованных бизнесах. Таких бизнесов с выручкой выше порога упрощенки я не знаю. Все процессы в них сложно подвести под какие-то стандарты.
Казалось бы ваш аргумент про относительно молодой бизнес может иметь место, но ведь и весь "большой" софт существует те же 30 лет. А многие (если быть честным - все) наши крупняки пользовались услугами западных консультантов, которые несут "лучшие практики".
Тем не менее стандартизация существует и нужна. Но не в автоматизации бизнес-процессов, а в методах управленческого учета.
Увеличивать прибыль можно как уменьшением затрат, так и увеличением выручки.
Выручка может увеличиваться за счет: увеличения количества клиентов (автоматизация маркетинга, повышение конверсии), за счет увеличения среднего чека (продажа большего количества товаров или услуг, допродажи), а также за счет увеличения пропускной способности конвейера от контакта до получения денег и отгрузки.
Кроме того, есть такая категория ПО как "управленческое", которое помогает более качественно принимать управленческие решения. Оно само по себе не влияет ни на какие финансовые характеристики компании, но помогает менеджерам меньше тратить и больше зарабатывать. Недавно был пример: внедрение системы прогнозирования платежей помогла понять что в конце года будет большой НДС и менеджеры побежали договариваться отправлять платежи контрагентам, чем сэкономили десятки миллионов налогов.
Это я все к чему: От софта обязательно должен быть экономический эффект. Но до внедрения просчитать его может быть невозможно.
А еще все базы данных переносятся на один сервер в одну физическую базу
Чтобы ускорить сборку С++ нужны микросервисы?