Я в каком-то параллельном мире живу. В моей выборке нет никого, кого можно было бы заставить использовать биометрию, даже силой (кроме случаев, когда мы сдаем её банку и государству и т. д.) Так странно… я наверное что-то упускаю. Это 42 пользователя FaceID что ли?
Казалось бы, лид лида должен понять. Но даже я не понимаю, каким образом описанное вами может работать, и не понимаю, как такие очевидные заблуждения оказались настолько живучими. Причем, что интересно, их нет в официальном Scrum Guide. Это инородный обвес, возрастом лет эдак 25, который каким-то образом прилип к процессу разработки и используется раз за разом не по назначению.
Вот прямо сейчас проверил наши "технологические карты": с момента, как разработчик ознакомился с заданием, должно пройти как минимум 5 важнейших этапов перед тем, как я могу попросить его оценить объем работ и его ответ будет иметь смысл.
Я понятия не имею, зачем спрашивать разработчика, который только что прочитал текст задания, о том, что он думает о его сложности и как долго он будет его делать. И тем более - зачем об этом спрашивать его коллегу.
Мне раньше было интересно: когда я нанимал человека из бигтеха, я спрашивал - "а что ты им отвечал на вопрос о стори-поинтах, в момент, когда очевидно, что ответа еще не существует?" Все как один: "Просто говорил разную чепуху, чтобы они отстали и успокоились. Главное - чтобы совпало с коллегой". Ужас…
Да, есть исключения. Если задача настолько примитивная, что текст задачи писать дольше, чем выполнять, то и оценивать её быстрее, чем описывать (это я, конечно, фигурально). Или если вы - R&D подразделение core-команды, у вас реально происходит настоящий коллективный брейншторм, и вам реально нужны относительные единицы измерения почти для всего и почти сразу.
Как эти вредные практики оказались такими живучими…
Даже их создатель (с которым я не согласен) использовал их как инструмент командного планирования. А планирование - это не "раздача задач", это особый вид деятельности, со своим регламентом, со своими артефактами, со своими требованиями к навыкам.
Нельзя просто так созвать митинг, показать команде текст задачи и спросить: “ну что, кто что думает, сколько кошек ставим?”
Я искренне надеюсь, что вы просто неудачно выразились, опустили важные моменты, и на самом деле не делаете "буквально" то, что описано в статье. Иначе - "да прибудет с вашими разработчиками сила", она им понадобится...
Не хочу комментировать по существу статьи - мы все ещё находимся в фазе "энтузиасты продолжают испытывать энтузиазм". Рано.
Но не могу удержаться, чтобы не подсветить вот какой забавный факт…
Подхожу к слабому разработчику, который не вылезает из общения с ИИ целый день. Говорю: "Покажи запрос". Он показывает две куцые строчки.
Спрашиваю: "Слушай, с тобой модель постоянно здоровается и хвалит за отлично поставленный вопрос. У тебя стоимость исходящего токена - 3, а входящего - 15. Предложение, в котором ты попросишь её перестать это делать, кратно короче и дешевле, чем каждый раз платить за вежливые обороты и тратить время на их прочтение. Почему ты этого не делаешь?" Он - опустил глаза, молчит…
И пришла мне вот какая нехорошая мысль: если специалист недостаточно хорош для своей позиции - не поможет уже ничего, ни ИИ, ни боженька за пазухой. Он просто слаб во всем, не готов к профессии.
Наверное, какое-то время можно пользоваться лайфхаком: спрашивать на собеседовании, использует ли разработчик ИИ. Они боятся сказать "нет", потому что это быстро вскрывается. А когда они скажут "да" - просить показать запрос. Поверьте, во многих случаях, это будет акт добровольной передачи вещественного доказательства того, что человек профнепригоден.
Это конечно же шутка, но есть в этой шутке что-то не шуточное, и даже пугающее :)
Полностью поддерживаю. Несколько раз сталкивались с JSON-RPC (работали со stratum протоколом и межсервисным велосипедом), остались только самые положительные впечатления.
Кстати, такое забавное наблюдение: JSON-RPC реализованный слабым разработчиком, намного менее проблемный и более приятный в работе, чем RESTful протокол, реализованный моим лучшим разработчиком.
И побочный эффект: если какая-то команда попробовала оба варианта - потом всегда будет напоминать и просить JSON-RPC, даже если ТЗ предполагает что-то другое.
Спросите любого архитектора - ему, по большому счету, плевать, какие части HTTP протокола его заставят использовать или не использовать. Его задача - управлять сложностью! Он может что-то любить или не любить, но проблем от HTTP он не почувствует. Не стоит себе льстить: HTTP протокол - это не теория струн, он бесконечно проще того, чем архитектор обычно занимается.
Но вот что архитектора действительно волнует - это границы и межкомпонентное взаимодействие. Именно здесь чаще всего рождается лишняя сложность. И если вы предложите разрушить абстракции и аморфно склеить какие-то слои системы, опытный архитектор точно спросит: “Зачем?”. Ведь он знает, что плата высока, и будет безумием добровольно ее заплатить, не получив ничего взамен.
Архитектору плевать, когда люди обсуждают, чему именно они хотят разрешить протечь из транспортного уровня в прикладной уровень (логический уровень взаимодействия систем). И плевать, какой аббревиатуре это будет соответствовать. Важен только сам факт того, что граница нарушена.
Вот вы, например, пытались-пытались вырулить, по крохам собирали участки, где можно уменьшить сложность до удобоваримой. Дописали до раздела обработки ошибок и…
200 OK, на мой взгляд, это как-то очень скучно и сухо… как же промежуточные системы
… и все - транспортный уровень всеми своими кишками протек в приложение. “Скучно ему, видите ли”. Архитектор полностью перепишет эти два слоя, уберёт границу из кода, блокеры из диздока и повысит смету проекта. Какая теперь разница, что именно протекло - можете тащить и все остальное. Урон - нанесен, код - готов, банкет - оплачен.
И проблема с REST именно в этом - вас миллионы. У кого-то протекли коды ошибок, у кого-то глаголы, у кого-то управление кэшами; кто-то тащит родные возможности по управлению идемпотентностью; кто-то боится не быть готовым к мифическим network middleware; кто-то переносит части тела в URL, чтобы найти их в логах; у кого-то протекла аутентификация; кто-то не может работать, если стандартная панель браузера не парсит трафик; кто-то тащит все, для чего есть подсветка синтаксиса в .http файлах; кто-то привык к популярному фреймворку; кто-то не знает свой CDN и готовится ко всему на свете...
И нет никакого смысла писать статьи о том, кто из них более неправ либо менее неправ. Или о том, как нужно изменить аббревиатуру, чтобы было не стыдно.
Как поэтично говорит один из моих знакомых архитекторов: “Если оборона пала, то неважно, что я буду писать в диздок - все равно весь хлеб будет украден, а все девки изнасилованы - это у варваров в крови”.
Спросите, что же делать? Можно ли вообще использовать REST или что-то на него похожее? Конечно, но! Только если это является реальным требованием в техническом задании проекта, с обоснованием в виде твердого намерения использовать те свойства и возможности, которые он предоставляет, и с финансированием последствий. А не мифическое: “а вдруг через 5 лет мы захотим мигать лампочкой в коридоре при неправильном пароле - без изменений в коде”.
Намек начинающим: не переживайте, если вам кажется, что с REST что-то не то, но все вокруг ведут себя как слепые - вы не одиноки, с вами все в порядке. Просто некоторые темы ковырять не принято, чтобы экономить ресурсы, раз уж непоправимый урон уже нанесен. Работайте с тем, что есть, пока не дорастете до уровня принятия решений.
Я в каком-то параллельном мире живу. В моей выборке нет никого, кого можно было бы заставить использовать биометрию, даже силой (кроме случаев, когда мы сдаем её банку и государству и т. д.) Так странно… я наверное что-то упускаю. Это 42 пользователя FaceID что ли?
Казалось бы, лид лида должен понять. Но даже я не понимаю, каким образом описанное вами может работать, и не понимаю, как такие очевидные заблуждения оказались настолько живучими. Причем, что интересно, их нет в официальном Scrum Guide. Это инородный обвес, возрастом лет эдак 25, который каким-то образом прилип к процессу разработки и используется раз за разом не по назначению.
Вот прямо сейчас проверил наши "технологические карты": с момента, как разработчик ознакомился с заданием, должно пройти как минимум 5 важнейших этапов перед тем, как я могу попросить его оценить объем работ и его ответ будет иметь смысл.
Я понятия не имею, зачем спрашивать разработчика, который только что прочитал текст задания, о том, что он думает о его сложности и как долго он будет его делать. И тем более - зачем об этом спрашивать его коллегу.
Мне раньше было интересно: когда я нанимал человека из бигтеха, я спрашивал - "а что ты им отвечал на вопрос о стори-поинтах, в момент, когда очевидно, что ответа еще не существует?" Все как один: "Просто говорил разную чепуху, чтобы они отстали и успокоились. Главное - чтобы совпало с коллегой". Ужас…
Да, есть исключения. Если задача настолько примитивная, что текст задачи писать дольше, чем выполнять, то и оценивать её быстрее, чем описывать (это я, конечно, фигурально). Или если вы - R&D подразделение core-команды, у вас реально происходит настоящий коллективный брейншторм, и вам реально нужны относительные единицы измерения почти для всего и почти сразу.
Как эти вредные практики оказались такими живучими…
Даже их создатель (с которым я не согласен) использовал их как инструмент командного планирования. А планирование - это не "раздача задач", это особый вид деятельности, со своим регламентом, со своими артефактами, со своими требованиями к навыкам.
Нельзя просто так созвать митинг, показать команде текст задачи и спросить: “ну что, кто что думает, сколько кошек ставим?”
Я искренне надеюсь, что вы просто неудачно выразились, опустили важные моменты, и на самом деле не делаете "буквально" то, что описано в статье. Иначе - "да прибудет с вашими разработчиками сила", она им понадобится...
Не хочу комментировать по существу статьи - мы все ещё находимся в фазе "энтузиасты продолжают испытывать энтузиазм". Рано.
Но не могу удержаться, чтобы не подсветить вот какой забавный факт…
Подхожу к слабому разработчику, который не вылезает из общения с ИИ целый день. Говорю: "Покажи запрос". Он показывает две куцые строчки.
Спрашиваю: "Слушай, с тобой модель постоянно здоровается и хвалит за отлично поставленный вопрос. У тебя стоимость исходящего токена - 3, а входящего - 15. Предложение, в котором ты попросишь её перестать это делать, кратно короче и дешевле, чем каждый раз платить за вежливые обороты и тратить время на их прочтение. Почему ты этого не делаешь?" Он - опустил глаза, молчит…
И пришла мне вот какая нехорошая мысль: если специалист недостаточно хорош для своей позиции - не поможет уже ничего, ни ИИ, ни боженька за пазухой. Он просто слаб во всем, не готов к профессии.
Наверное, какое-то время можно пользоваться лайфхаком: спрашивать на собеседовании, использует ли разработчик ИИ. Они боятся сказать "нет", потому что это быстро вскрывается. А когда они скажут "да" - просить показать запрос. Поверьте, во многих случаях, это будет акт добровольной передачи вещественного доказательства того, что человек профнепригоден.
Это конечно же шутка, но есть в этой шутке что-то не шуточное, и даже пугающее :)
Полностью поддерживаю. Несколько раз сталкивались с JSON-RPC (работали со stratum протоколом и межсервисным велосипедом), остались только самые положительные впечатления.
Кстати, такое забавное наблюдение: JSON-RPC реализованный слабым разработчиком, намного менее проблемный и более приятный в работе, чем RESTful протокол, реализованный моим лучшим разработчиком.
И побочный эффект: если какая-то команда попробовала оба варианта - потом всегда будет напоминать и просить JSON-RPC, даже если ТЗ предполагает что-то другое.
Спросите любого архитектора - ему, по большому счету, плевать, какие части HTTP протокола его заставят использовать или не использовать. Его задача - управлять сложностью! Он может что-то любить или не любить, но проблем от HTTP он не почувствует. Не стоит себе льстить: HTTP протокол - это не теория струн, он бесконечно проще того, чем архитектор обычно занимается.
Но вот что архитектора действительно волнует - это границы и межкомпонентное взаимодействие. Именно здесь чаще всего рождается лишняя сложность. И если вы предложите разрушить абстракции и аморфно склеить какие-то слои системы, опытный архитектор точно спросит: “Зачем?”. Ведь он знает, что плата высока, и будет безумием добровольно ее заплатить, не получив ничего взамен.
Архитектору плевать, когда люди обсуждают, чему именно они хотят разрешить протечь из транспортного уровня в прикладной уровень (логический уровень взаимодействия систем). И плевать, какой аббревиатуре это будет соответствовать. Важен только сам факт того, что граница нарушена.
Вот вы, например, пытались-пытались вырулить, по крохам собирали участки, где можно уменьшить сложность до удобоваримой. Дописали до раздела обработки ошибок и…
… и все - транспортный уровень всеми своими кишками протек в приложение. “Скучно ему, видите ли”. Архитектор полностью перепишет эти два слоя, уберёт границу из кода, блокеры из диздока и повысит смету проекта. Какая теперь разница, что именно протекло - можете тащить и все остальное. Урон - нанесен, код - готов, банкет - оплачен.
И проблема с REST именно в этом - вас миллионы. У кого-то протекли коды ошибок, у кого-то глаголы, у кого-то управление кэшами; кто-то тащит родные возможности по управлению идемпотентностью; кто-то боится не быть готовым к мифическим network middleware; кто-то переносит части тела в URL, чтобы найти их в логах; у кого-то протекла аутентификация; кто-то не может работать, если стандартная панель браузера не парсит трафик; кто-то тащит все, для чего есть подсветка синтаксиса в .http файлах; кто-то привык к популярному фреймворку; кто-то не знает свой CDN и готовится ко всему на свете...
И нет никакого смысла писать статьи о том, кто из них более неправ либо менее неправ. Или о том, как нужно изменить аббревиатуру, чтобы было не стыдно.
Как поэтично говорит один из моих знакомых архитекторов: “Если оборона пала, то неважно, что я буду писать в диздок - все равно весь хлеб будет украден, а все девки изнасилованы - это у варваров в крови”.
Спросите, что же делать? Можно ли вообще использовать REST или что-то на него похожее? Конечно, но! Только если это является реальным требованием в техническом задании проекта, с обоснованием в виде твердого намерения использовать те свойства и возможности, которые он предоставляет, и с финансированием последствий. А не мифическое: “а вдруг через 5 лет мы захотим мигать лампочкой в коридоре при неправильном пароле - без изменений в коде”.
Намек начинающим: не переживайте, если вам кажется, что с REST что-то не то, но все вокруг ведут себя как слепые - вы не одиноки, с вами все в порядке. Просто некоторые темы ковырять не принято, чтобы экономить ресурсы, раз уж непоправимый урон уже нанесен. Работайте с тем, что есть, пока не дорастете до уровня принятия решений.