Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?
Эм, в прошлом веке прямо на средней продающейся на 1/8 части суши упаковке было написано русским по белому "в рулоне". Хотя, возможно, в данном случае, скорее всего, речь всё таки о кассетах.
Имеет смысл упомянуть, что iframe нужно реализовывать не абы как, а с соблюдением остальных требований PCI DSS, иначе получится решето. Ну и против атак вроде Evil Proxy Phishing можно применить только аттестацию девайса пользователя (аналог варианта с HSM). Без неё придётся применять только контрмеры различной степени шаманистости.
А как становятся [Chief] solution architect? Из разработки, аналитики, ПМ/ПрМ?
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...
И примерно 10-20 минут затрат на следующую задачу из-за смены контекста, если это не просто "передвинуть" (а если так, то зачем вообще помнить, что надо что-то там передвигать?), а механика отчётности (именно её, судя по скринам, под видом декларированного "наведения порядка", внедрял автор).
На деле же им не нужен был трекер, а нужен был более-менее грамотный руководитель и какая-то концепция (стратегия), что они хотят в целом добиться. Тогда, если бы они решали реальные проблемы, то, может, и без трекера нужный порядок появился бы. К примеру, упоминаются личные чаты - один из способов наведения порядка - запрет личных чатов на уровне компании ("если это было только в личке, то этого не говорилось"). Пресловутые чаты под конкретные бизнес-процессы (техподдержка, запросы и т.п.) - это во многом эрзац-трекер.
А что делать, если в процессе следования по дорожной карте оказывается, что маршрут был проложен неверно (либо команда свернула по нему "не совсем туда"? Т.е. оценка резко увеличивается из-за какой-то ошибки.
По туристской аналогии: при передвижении по сильно пересечённой (горной) местности велика вероятность ошибки. И вы можете в итоге стоять от цели в 10 метрах геометрически, но что бы туда попасть, надо идти ещё пару суток. А всё из-за того, что случайно (в тумане и т.д.) свернули раньше/позже срока.
А если этой ситуации не избежать, то нужна ли вторая оценка (по разбиению работы на этапы) и нужно ли на неё тратить отдельное время? Мы же первоначальную оценку делаем для того что бы понять "съедим ли мы слона хотя бы теоретически". Может, оценку по более мелким этапам работ делать в момент, когда хотя бы по вводным для них всё понятно?
В Atlassian Jira раньше при редактировании описания задачи при нажатии Esc не запрашивалось подтверждения. Это была настоящая боль. Сколько нервов было потрачено из-за потерь введенного текста...
Выход по Esc это хорошо (в частности, то, что Esc в модальных диалогах идентичен нажатию "Отмена"). Но закрывать по этой клавише, например, окно браузера (для чего я чаще всего нажимаю Alt+F4) - это странно.
И при этом для такой частой операции, как закрытие окна, нужно нажимать Alt+F4
А это разве плохо? Хуже, если бы для этого требовалось бы [случайное] нажатие одной кнопки. Как в странных клавиатурах, которые продавались в начале нулевых неопытным пользователям, в которых кнопка выключения была расположена рядом с PgDn.
Переключение языка — вечная боль
К счастью, в X-Window из коробки можно настроить переключение с параметрами: XKBOPTIONS="grp:lctrl_lwin_rctrl_menu,grp:alt_shift_toggle,grp_led:scroll" Т.е. левый Ctrl + Win - английский, правый Ctrl + Menu - русский (ну и переключалка Alt+Shift на всякий случай и для посторонних). И статус отображается индикатором Scroll Lock (если включён, значит активна русская раскладка).
Выше уже указали, что сторипойнты не имеют смысла в отдельности от конкретной команды. Почему бы тогда не сделать оценку прямо в рабочих днях (часах) или в деньгах (если этот аспект прозрачен для команды)? В этом случае в итоге получится прямо коэффициент эффективности. Если при этом ещё ввести соревновательность в стиле "угадай мелодию" и KPI, привязанную к личной эффективности сотрудника, то заодно будет стимул к оптимизации эффективности.
И ещё, получается, что раз в вашем примере в январе была самая эффективная работа, а после ухода сотрудника стала самой неэффективной, то получается, эта эффективность ушла с сотрудником? И руководитель виноват, что не удержал его?
А что, разрабатываемая система потом будет существовать в вакууме? Вот в примерах в статье у нас по два пользователя - конечный пользователь и пользователь-администратор. Когда пытаешься понять, как именно различные пользователи (особенно когда их > 3 категорий) будут участвовать в общем процессе, удобнее описывать это BPMN. Как отметил комментатор ниже, в виде Sequence Diagram такая схема будет нечитаема.
Вообще, странен переход от C4 к Sequence, т.к. последний вид диаграмм описывает процессы, (причём требует очень точного описания, иначе читать невозможно) тогда как C4, судя по его описанию, описывает систему в виде статичных её классов - просто в разном уровне детализации. Например, допустимую последовательность деплоя сервисов (контейнеров) из неё не почерпнуть.
Тогда как Sequence Diagram - это "микроописание" деталей поведения кусков системы. И в случае большого количества акторов, BPMN будет намного понятнее - это будет своего рода Sequence Diagram, "вид сверху" (лишённый, разумеется, визуализации хронологической одновременности параллельных процессов).
Правильно ли я понял, что итог двух лет - это собранная команда по поддержке и доработке запущенного проекта (которая дальше будет жить без участия автора)?
Т.е., в частности, - грейды нужны уже на этап после запуска?
По "текущему раскладу" - я так понял, что грейдапы в созданной команде приветствуются. А есть ли ограничения (в пределах какого-то общего бюджета проекта, по установленным заранее квотам, по готовности заказчика)? Могут ли потенциально при такой схеме получиться оверквалы? Если да, что с ними предполагается делать?
Существенная доля путаницы в этом вопросе - из-за того, что многие воспринимают назначение сроков и планирования - каждый по своему.
Кому-то надо понять, влезет ли задача в доступные ресурсы. Кому-то надо заранее договариваться об условной рекламе на ТВ и т.д. Кто-то боится, что если ошибешься в меньшую сторону, то наругают при не попадании. Кто-то - что накинут ещё задач..
Поэтому решать вопросы планирования не имеет смысла без предварительного формулирования "зачем"
А какого рода алгоритмы сейчас можно делать над FHE? Только комбинации And и Xor? Можно ли скрывать сами алгоритмы от вычислителя? Что насчёт условий или циклов (и соответствующих проблем типа подверженности к timing attack)? Массивы или адресная арифметика?
Эм, в прошлом веке прямо на средней продающейся на 1/8 части суши упаковке было написано русским по белому "в рулоне". Хотя, возможно, в данном случае, скорее всего, речь всё таки о кассетах.
Да, но не только.
Спасибо за ответ - интересный путь!
Имеет смысл упомянуть, что iframe нужно реализовывать не абы как, а с соблюдением остальных требований PCI DSS, иначе получится решето. Ну и против атак вроде Evil Proxy Phishing можно применить только аттестацию девайса пользователя (аналог варианта с HSM). Без неё придётся применять только контрмеры различной степени шаманистости.
А как становятся [Chief] solution architect? Из разработки, аналитики, ПМ/ПрМ?
Если автор по должности инженер, то техдир будет валить на него - типа, не предусмотрел.
Я очень надеюсь, что автор подключился к ним правильно, исключив все логические уязвимости такой схемы. И, например, исключена ситуация, когда его система выключена, горелка не горит, а газ подаётся.
Ремонтник по котлам, который приходил для техобслуживания бытового сказал, что к сожалению, случаи, когда котёл травит окружающих из-за несработки датчика, случаются.
Как бы не случилось и в этом случаи ситуации "ой, а об этом мы не подумали".
Читая подобную статью, да ещё с такой манерой подачи ощущаешь, что уши начинают шевелиться от ужаса. Хочется, что бы в публичных пространствах была маркировка "вы находитесь в зоне, ответственность за которую - в голове современных инженеров". Один делает неотключаемую адекватным путём автоматику (причём, конкретно этим болеют сразу многие из разных стран) на основе показаний датчиков, которые, как оказывается, легко повернуть одновременно на определённый угол. Другие обучают и допускают к работам специалистов, которые могут, даже если разъём не встаёт на своё место, всё же, запихнуть его...
И примерно 10-20 минут затрат на следующую задачу из-за смены контекста, если это не просто "передвинуть" (а если так, то зачем вообще помнить, что надо что-то там передвигать?), а механика отчётности (именно её, судя по скринам, под видом декларированного "наведения порядка", внедрял автор).
На деле же им не нужен был трекер, а нужен был более-менее грамотный руководитель и какая-то концепция (стратегия), что они хотят в целом добиться. Тогда, если бы они решали реальные проблемы, то, может, и без трекера нужный порядок появился бы. К примеру, упоминаются личные чаты - один из способов наведения порядка - запрет личных чатов на уровне компании ("если это было только в личке, то этого не говорилось"). Пресловутые чаты под конкретные бизнес-процессы (техподдержка, запросы и т.п.) - это во многом эрзац-трекер.
А что делать, если в процессе следования по дорожной карте оказывается, что маршрут был проложен неверно (либо команда свернула по нему "не совсем туда"? Т.е. оценка резко увеличивается из-за какой-то ошибки.
По туристской аналогии: при передвижении по сильно пересечённой (горной) местности велика вероятность ошибки. И вы можете в итоге стоять от цели в 10 метрах геометрически, но что бы туда попасть, надо идти ещё пару суток. А всё из-за того, что случайно (в тумане и т.д.) свернули раньше/позже срока.
А если этой ситуации не избежать, то нужна ли вторая оценка (по разбиению работы на этапы) и нужно ли на неё тратить отдельное время? Мы же первоначальную оценку делаем для того что бы понять "съедим ли мы слона хотя бы теоретически". Может, оценку по более мелким этапам работ делать в момент, когда хотя бы по вводным для них всё понятно?
В Atlassian Jira раньше при редактировании описания задачи при нажатии Esc не запрашивалось подтверждения. Это была настоящая боль. Сколько нервов было потрачено из-за потерь введенного текста...
Выход по Esc это хорошо (в частности, то, что Esc в модальных диалогах идентичен нажатию "Отмена"). Но закрывать по этой клавише, например, окно браузера (для чего я чаще всего нажимаю Alt+F4) - это странно.
А это разве плохо? Хуже, если бы для этого требовалось бы [случайное] нажатие одной кнопки. Как в странных клавиатурах, которые продавались в начале нулевых неопытным пользователям, в которых кнопка выключения была расположена рядом с PgDn.
К счастью, в X-Window из коробки можно настроить переключение с параметрами:
XKBOPTIONS="grp:lctrl_lwin_rctrl_menu,grp:alt_shift_toggle,grp_led:scroll"
Т.е. левый Ctrl + Win - английский, правый Ctrl + Menu - русский (ну и переключалка Alt+Shift на всякий случай и для посторонних). И статус отображается индикатором Scroll Lock (если включён, значит активна русская раскладка).
Различные варианты Space Cadet Keyboard периодически появляются. Но зачем? У математиков теперь есть TeX...
Не понимаю всё же, что за поток?
В BPMN должна быть описана обработка всех возможных ошибок?
Поток чего? Это же event-driven процесс. Не "цикл обработки событий" же в стиле дракон-схем рисовать...
Выше уже указали, что сторипойнты не имеют смысла в отдельности от конкретной команды. Почему бы тогда не сделать оценку прямо в рабочих днях (часах) или в деньгах (если этот аспект прозрачен для команды)? В этом случае в итоге получится прямо коэффициент эффективности. Если при этом ещё ввести соревновательность в стиле "угадай мелодию" и KPI, привязанную к личной эффективности сотрудника, то заодно будет стимул к оптимизации эффективности.
И ещё, получается, что раз в вашем примере в январе была самая эффективная работа, а после ухода сотрудника стала самой неэффективной, то получается, эта эффективность ушла с сотрудником? И руководитель виноват, что не удержал его?
Корпус с акриловой боковой стенкой, а не из энтерпрайзной стали. Значит, точно нет Chassis Intrusion Detection. :)
А что, разрабатываемая система потом будет существовать в вакууме? Вот в примерах в статье у нас по два пользователя - конечный пользователь и пользователь-администратор. Когда пытаешься понять, как именно различные пользователи (особенно когда их > 3 категорий) будут участвовать в общем процессе, удобнее описывать это BPMN. Как отметил комментатор ниже, в виде Sequence Diagram такая схема будет нечитаема.
Вообще, странен переход от C4 к Sequence, т.к. последний вид диаграмм описывает процессы, (причём требует очень точного описания, иначе читать невозможно) тогда как C4, судя по его описанию, описывает систему в виде статичных её классов - просто в разном уровне детализации. Например, допустимую последовательность деплоя сервисов (контейнеров) из неё не почерпнуть.
Тогда как Sequence Diagram - это "микроописание" деталей поведения кусков системы. И в случае большого количества акторов, BPMN будет намного понятнее - это будет своего рода Sequence Diagram, "вид сверху" (лишённый, разумеется, визуализации хронологической одновременности параллельных процессов).
Странно, что вы написали этот комментарий не на латыни, французском, английском или эсперанто, смотря какой идеальный мир вы для себя видите.
Спасибо, интересная статья.
Вопросы, для лучшего понимания:
Правильно ли я понял, что итог двух лет - это собранная команда по поддержке и доработке запущенного проекта (которая дальше будет жить без участия автора)?
Т.е., в частности, - грейды нужны уже на этап после запуска?
По "текущему раскладу" - я так понял, что грейдапы в созданной команде приветствуются. А есть ли ограничения (в пределах какого-то общего бюджета проекта, по установленным заранее квотам, по готовности заказчика)? Могут ли потенциально при такой схеме получиться оверквалы? Если да, что с ними предполагается делать?