Комментарии 11
В первом задании — этапа бронирования нет, несколько пользователей могут одновременно оплатить один и тот же билет.
Во втором — видимо, что-то подобное же имеется в виду, но там вообще не понятно ничего (как, скажем, вообще проверять доступные ресурсы для создания нового проекта).
P.S. А какое отношение форма люка имеет к спилу дерева? Их реально когда-то делали из цельных торцевых спилов, что ли? Даже круглый деревянный люк сколотить из досок не в пример дешевле и проще.
Во втором — видимо, что-то подобное же имеется в виду, но там вообще не понятно ничего (как, скажем, вообще проверять доступные ресурсы для создания нового проекта).
P.S. А какое отношение форма люка имеет к спилу дерева? Их реально когда-то делали из цельных торцевых спилов, что ли? Даже круглый деревянный люк сколотить из досок не в пример дешевле и проще.
Дана схема, нарисована небрежно (это так и задумано, многие перестают на этом думать, уходя детали и перестают видеть процесс целиком).
Кто-то заморочился на выражении своей мысли.
А я не очень понял, к какому конкретно утверждению в 1 задании относится вопрос «почему?». Почему жульническая?
Ну потому что не соответствует законодательству.
1) Билеты являются бланками строгой отчетности. Их выпуск занимает существенное время и не может пройти в короткий промежуток заказа.
2) Выпуск билета — операция с негарантированным результатом. Поэтому в случае неудачи — вообще не понятно, за что вы с клиента взяли деньги? Да и в случае удачи тоже отчасти этот вопрос остается.
3) Платежные системы обычно печатают и кассовые чеки (электронные). А в чеке должно быть указано, «что купил». А по схеме этой информации вообще не существует на момент оплаты.
И да, правильно выше заметили о необходимости резерва (на глаз с 5го по 14й пункт должен покрываться с резервом и отдельно подумать о таймауте снятия с резерва) — правда резерв можно ставить только на то, что уже существует. А раз билета еще нет — то и резерв на него не поставить.
Можно и без резерва, но тогда с 5 по 14 пункт — должны быть атомарной операцией (условно, будто бы одной транзакцией, которая либо прошла целиком, либо нет).
Ну потому что не соответствует законодательству.
1) Билеты являются бланками строгой отчетности. Их выпуск занимает существенное время и не может пройти в короткий промежуток заказа.
2) Выпуск билета — операция с негарантированным результатом. Поэтому в случае неудачи — вообще не понятно, за что вы с клиента взяли деньги? Да и в случае удачи тоже отчасти этот вопрос остается.
3) Платежные системы обычно печатают и кассовые чеки (электронные). А в чеке должно быть указано, «что купил». А по схеме этой информации вообще не существует на момент оплаты.
И да, правильно выше заметили о необходимости резерва (на глаз с 5го по 14й пункт должен покрываться с резервом и отдельно подумать о таймауте снятия с резерва) — правда резерв можно ставить только на то, что уже существует. А раз билета еще нет — то и резерв на него не поставить.
Можно и без резерва, но тогда с 5 по 14 пункт — должны быть атомарной операцией (условно, будто бы одной транзакцией, которая либо прошла целиком, либо нет).
Не в законодательстве делало, а в том, что приняли деньги не зарезервировав товар (место на концерте). Многие не получат билета, а если ресурсная система кривая, то получат билет, но не войдут в концертный зал.
После такого хватайте деньги и бегите в Гондурас.
Главное в том, что аналитик должен сначала отстраивать базовую конструкцию, а потом наворачивать на нее детали и если он, аналитик, не увидел целиком процесса, и пропущенного шага, то грош ему цена
После такого хватайте деньги и бегите в Гондурас.
Главное в том, что аналитик должен сначала отстраивать базовую конструкцию, а потом наворачивать на нее детали и если он, аналитик, не увидел целиком процесса, и пропущенного шага, то грош ему цена
Кстати, можно придумать и схему без сколь нибудь длительного резерва. В этой схеме сложнооткатываемым шагом является транзакция платежной системы. А вот операция с билетом, как мне кажется, — легко откатывается назад.
Поэтому транзакцию платежной системы тащим в самый низ по схеме (перед визуализацией ставим). Перед ней просим билет у ресурсной системы, если платеж не прошел — то после нее «возвращаем» билет в ресурсную систему.
К недостаткам стоит отнести, что пользователю об ошибке мы говорим в самом конце. Он потратил время на выбор места, а только в самом конце узнает, что не вышло.
К достоинствам — тут очень короткое время резерва, не зависящее от пользователя. А поэтому невозможна атака класса ДОС.
(это когда «особо умный» пользователь открыл вкладок и поставил все ваши билеты в резерв. продать больше вы ничего не можете)
Поэтому транзакцию платежной системы тащим в самый низ по схеме (перед визуализацией ставим). Перед ней просим билет у ресурсной системы, если платеж не прошел — то после нее «возвращаем» билет в ресурсную систему.
К недостаткам стоит отнести, что пользователю об ошибке мы говорим в самом конце. Он потратил время на выбор места, а только в самом конце узнает, что не вышло.
К достоинствам — тут очень короткое время резерва, не зависящее от пользователя. А поэтому невозможна атака класса ДОС.
(это когда «особо умный» пользователь открыл вкладок и поставил все ваши билеты в резерв. продать больше вы ничего не можете)
Вот вам пример — в среде нанимателей кочует задачка на тему: «почему канализационные люки круглые?». Правильный ответ кандидата на должность разработчика: «Круглые, потому, что, т. к. диаметр круга одинаков, то люк круглой формы никогда не провалится в колодец...». Правильный ответ аналитика: «Потому что стволы деревьев на спил круглые».
Вот это прям кошмар-кошмар! Люки круглые, потому что колодцы обычно круглые — удобнее же одинаковые формы такими же накрывать. А колодца круглые — потому что арочная форма бетонного кольца лучше всего противостоит боковому давлению грунта — так сказать, материалоемкость изделия минимальна.
Если Ваши подсказки верны.
То возможность жульничества заложено при разделении дилерской и ресурсной системы.
— подсказка: нарушен базовый принцип
— подсказка: помни про бритву Оккама
То возможность жульничества заложено при разделении дилерской и ресурсной системы.
Вопрос с учетом Вашего заявления:
С учетом закона Уильяма Эшби «Закон необходимого разнообразия»
Который в простой форме принимает вид «п.1 Командир всегда прав.; п.2 Если командир не прав, то смотри пункт 1.»
Получается следующее, если руководитель может определить степень навыков аналитика, то навыки аналитика меньше, в этой области, навыков руководителя. И, соответственно, если перед руководителем проекта, стоит задача, которую он не может решить, то и аналитик, уровень квалификации которого меньше, чем уровень руководителя, не сможет ее решить.
Тогда вопрос, как вам удается определить, что уровень квалификации аналитика позволяет решать возникшие задачи?
Если еще и учесть принцип Питера Лоуренса
В силу своих служебных обязанностей, мне довелось нанимать довольно большое количество аналитиков различного профиля
С учетом закона Уильяма Эшби «Закон необходимого разнообразия»
«управление может быть обеспечено только в том случае, если разнообразие средств управляющего (в данном случае всей системы управления) по крайней мере не меньше, чем разнообразие управляемой им ситуации»
Который в простой форме принимает вид «п.1 Командир всегда прав.; п.2 Если командир не прав, то смотри пункт 1.»
Получается следующее, если руководитель может определить степень навыков аналитика, то навыки аналитика меньше, в этой области, навыков руководителя. И, соответственно, если перед руководителем проекта, стоит задача, которую он не может решить, то и аналитик, уровень квалификации которого меньше, чем уровень руководителя, не сможет ее решить.
Тогда вопрос, как вам удается определить, что уровень квалификации аналитика позволяет решать возникшие задачи?
Если еще и учесть принцип Питера Лоуренса
«В иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности»
У вас все аналитики — старперы, которые ходят на концерты с сидячими местами)))
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Что мы хотим от аналитика