Скорее всего, они неплохо маскируются под обычный сид, наверняка даже раздают пиратский контент, поэтому, рассуждая теоретически, скорее всего не удастся отличить шпионов от обычных сидов. Поэтому более жизнеспособная стратегия — маскироваться самому.
Но разве классическая модель с $40 за установку и абонентской платой в $20/мес с патчами раз в полгода лучше? Тут хотя бы есть возможность попробовать...
Да какие тут оскорбления, просто метафора очень уж в кассу пришлась.
По правде говоря, эта фраза не столько про "героя" (т.е. того кто спас положение), сколько про его руководство. Или про ситуацию в целом. А для "героя" подобная ситуация, с точки зрения его карьеры — только на пользу. Ведь это — лишнее достижение, за которую премию дадут. Или станет ярким пунктом годового ревью и основанием для повышения. Или даже отличной строчкой в резюме.
С точки зрения же бизнеса как процесса, ситуаций, которые требуют "героизма" всё же лучше избегать. Ведь они увеличивают неопределенность, что ведёт к убыткам.
Как правило, сотрудник тупит на контексте. Он не понимает, с чего начать. Не знает, что в окружении задачи вообще есть, будь то фреймворк или предметная область.
Мой опыт это утверждение не подтверждает. Если сотрудник (здесь и далее имею ввиду исключительно разработчика) "тупит" из-за того что не может (не знает как) начать, то он потеряет пару дней в самом худшем случае. Достаточно просто ежедневно отслеживать прогресс по каждой задаче. Да, тот самый пресловутый скрам дейли митинг сэкономит вам кучу человеко-часов/дней/недель "тупки", потому что если человеку уже второй день нечего объективно сказать по задаче, которая в прогрессе, то у него там затык, надо звать более квалифицированного на помощь.
Гораздо хуже, если он начал кое-как. Использовал неэффективный дизайн, требующий большого количества костылей, или если он (или кто-то другой в цепочке) истолковал постановку задачи неверно. Тогда дневные отчёты выглядят великолепно, код добавляется, документация пишется, даже уточняются мелкие детали. Всё это очень усыпляет внимание контроля. И чаще всего только на завершающих шагах вдруг внезапно выясняется, что делалось совсем не то, что было нужно!.. Поэтому большая часть в лучшем случае летит в помойку, а в худшем — её следы остаются жить в проекте навсегда и конфузят исполнителей следующих задач.
Вообще-то я имел в виду, что иногда даже просто проапгрейдить мажорную версию драйвера монги может стать той ещё занозой в…
Впрочем, даже рассматривая ваш тезис — нам тут пару месяцев назад топы спустили сверху резолюцию, что саппорт монги стоит слишком дорого, поэтому ее заменяют на более дешевое решение. С монгой не совместимое от слова совсем.
Думаю, мы не первые, кому решение спускают сверху. Всего несколько лет назад проприеритарные реляционные базы (читай оракл) массово меняли на открытые и NoSql решения.
Ну и какое решение будет перевести проще — с выделеным слоем доступа к данным или то где каждый класс очень по креативному работает с хранилищем?
Коробочные решения, например, часто расширяют требования до поддержки ещё одной базы данных. А всякие кеши и очереди сообщений и вовсе меняются как перчатки. Мне сложно представить, как это всё отслеживать без слоя доступа к данным в модели ActiveRecord
Так в примере выше, rsync и говорил про high-coupling. Якобы метод который и меняет бизнес-состояние и сам себя в базу пишет (вполне конкретную) — это хороший дизайн.
То есть это не просто Active-Record, а ещё и прибитая гвоздями к конкретной схеме конкретной базе конкретного драйвера.
А в чём проблема смены пароля при многофакторной авторизации? В консистенции смены на всех провайдерах? В рассылке уведомлений всем провайдерам об инвалидации? В том что будет многофазный процесс?
Вроде всё это выглядит решаемо. Я не очень знаком с этой конкретной предметной областью, но в своём опыте не припомню задач, где SRP был бы прямо явным антипаттерном.
Телеметрия и используется для улучшения продукта. Это может для кого-то открытие, но лучший способ улучшить продукт — надо просто понаблюдать что делает пользователь
Можно заказать исследования, где будут приглашать людей за деньги потыкать в разные элементы интерфейса, а затем выявлять где же они тупили. Цена этого исследования будет, естественно, включена в стоимость продукта.
А можно расставить таймеры и трекалки, которые соберут с каждого пользователя немного статистики — на каких элементах управления чаше всего тупят. Или в какие поля ввода водят неправильные данные.
Статья наглядно показывает что получается, когда вместо квалифицированного постановщика задач программистом командуют бухгалтера
Скорее всего, они неплохо маскируются под обычный сид, наверняка даже раздают пиратский контент, поэтому, рассуждая теоретически, скорее всего не удастся отличить шпионов от обычных сидов. Поэтому более жизнеспособная стратегия — маскироваться самому.
Выходит, что антиабузные только если абуза вне российского правового поля
Но разве классическая модель с $40 за установку и абонентской платой в $20/мес с патчами раз в полгода лучше? Тут хотя бы есть возможность попробовать...
А шутка в том, что пользователи, которые не готовы делиться личной информацией, отказались от участия в опросе
Да какие тут оскорбления, просто метафора очень уж в кассу пришлась.
По правде говоря, эта фраза не столько про "героя" (т.е. того кто спас положение), сколько про его руководство. Или про ситуацию в целом. А для "героя" подобная ситуация, с точки зрения его карьеры — только на пользу. Ведь это — лишнее достижение, за которую премию дадут. Или станет ярким пунктом годового ревью и основанием для повышения. Или даже отличной строчкой в резюме.
С точки зрения же бизнеса как процесса, ситуаций, которые требуют "героизма" всё же лучше избегать. Ведь они увеличивают неопределенность, что ведёт к убыткам.
Звучит прямо как слабоумие и отвага.
Мой опыт это утверждение не подтверждает. Если сотрудник (здесь и далее имею ввиду исключительно разработчика) "тупит" из-за того что не может (не знает как) начать, то он потеряет пару дней в самом худшем случае. Достаточно просто ежедневно отслеживать прогресс по каждой задаче. Да, тот самый пресловутый скрам дейли митинг сэкономит вам кучу человеко-часов/дней/недель "тупки", потому что если человеку уже второй день нечего объективно сказать по задаче, которая в прогрессе, то у него там затык, надо звать более квалифицированного на помощь.
Гораздо хуже, если он начал кое-как. Использовал неэффективный дизайн, требующий большого количества костылей, или если он (или кто-то другой в цепочке) истолковал постановку задачи неверно. Тогда дневные отчёты выглядят великолепно, код добавляется, документация пишется, даже уточняются мелкие детали. Всё это очень усыпляет внимание контроля. И чаще всего только на завершающих шагах вдруг внезапно выясняется, что делалось совсем не то, что было нужно!.. Поэтому большая часть в лучшем случае летит в помойку, а в худшем — её следы остаются жить в проекте навсегда и конфузят исполнителей следующих задач.
А я вот понял, что мы просто из разных вселенных.
Вообще-то я имел в виду, что иногда даже просто проапгрейдить мажорную версию драйвера монги может стать той ещё занозой в…
Впрочем, даже рассматривая ваш тезис — нам тут пару месяцев назад топы спустили сверху резолюцию, что саппорт монги стоит слишком дорого, поэтому ее заменяют на более дешевое решение. С монгой не совместимое от слова совсем.
Думаю, мы не первые, кому решение спускают сверху. Всего несколько лет назад проприеритарные реляционные базы (читай оракл) массово меняли на открытые и NoSql решения.
Ну и какое решение будет перевести проще — с выделеным слоем доступа к данным или то где каждый класс очень по креативному работает с хранилищем?
Коробочные решения, например, часто расширяют требования до поддержки ещё одной базы данных. А всякие кеши и очереди сообщений и вовсе меняются как перчатки. Мне сложно представить, как это всё отслеживать без слоя доступа к данным в модели ActiveRecord
Слишком много интеграционных тестов вот и гоняются по 2 часа.
QA "пишет" тесты используя свой инструментарий. Ну например SOA Test.
А в коде разработчика QA делать нечего. Как можно аудировать код, в котором ничего не понимаешь?
Нафиг тогда в такой вселенной нужен тогда QA вообще?
В реальном мире QA не верит разработчику и покрывает требования (а не код) независимо.
Так в примере выше, rsync и говорил про high-coupling. Якобы метод который и меняет бизнес-состояние и сам себя в базу пишет (вполне конкретную) — это хороший дизайн.
То есть это не просто Active-Record, а ещё и прибитая гвоздями к конкретной схеме конкретной базе конкретного драйвера.
Если там в цикле перебирается все строки таблицы вместо запроса с группировкой и/или аггрегацией, то DBA не спасёт.
А в чём проблема смены пароля при многофакторной авторизации? В консистенции смены на всех провайдерах? В рассылке уведомлений всем провайдерам об инвалидации? В том что будет многофазный процесс?
Вроде всё это выглядит решаемо. Я не очень знаком с этой конкретной предметной областью, но в своём опыте не припомню задач, где SRP был бы прямо явным антипаттерном.
Это в какой вселенной QA доверяет разработчику?
Мне тоже матчат 100% но с первого года.
Положить я могу максимум половину федерального годового лимита $19000 / 2 = $9500 для 2019 года
На самом деле $9000, потому что первые $500 они зачисляют за первый отложенный туда доллар
Телеметрия и используется для улучшения продукта. Это может для кого-то открытие, но лучший способ улучшить продукт — надо просто понаблюдать что делает пользователь
Можно заказать исследования, где будут приглашать людей за деньги потыкать в разные элементы интерфейса, а затем выявлять где же они тупили. Цена этого исследования будет, естественно, включена в стоимость продукта.
А можно расставить таймеры и трекалки, которые соберут с каждого пользователя немного статистики — на каких элементах управления чаше всего тупят. Или в какие поля ввода водят неправильные данные.
В цикле TDD рефакторят ДО того, как фича попадёт к QA