добродетель, уголовщина или что-то еще — это ответная оценка власти или общества на действие, а не превопрчина. т.е. это уже следствие того, как человек распоряжается свободой.
в принципе, добровольное соглашательство со всеми нормами и отказ от права сомневаться в решения власти — это тоже выбор. если большой государственный файрвол наконец-то будет достроен, такие люди могут считать сей факт и своей заслугой.
с другой стороны, в нашем обществе, слово «свобода», похоже опять начинает что-то значить.
конкуренция это в первую очередь про то, как выживать на рынке, а не прогибаться под хотелки отдельного потребителя.
слово «privacy» на рынке потребительских товаров — как заметил Doktor_Gradus, ни к чему не обязывающий макетинговый слоган. типичный смартфон, под разными предлогами, отправляет о вас больше телеметрии, чем можете себе представить. это ни куда не денется, пока владение информацией дает корпорациям преимущества (мне сложно представить обратную ситуацию, когда больше профита начнет давать неведение).
Человек с подходящим уровнем английского делает эту работу лучше, быстрее и стоит дешевле, чем кодер. Процессы частично параллелятся, что дает выигрыш по срокам.
Это работает лишь для решения небольших типовых задач, при наличии невысоких требований к масштабированию и надежности команд. Когда есть возможность самостоятельно форумулировать критерии качества, готовить и расхлебывать.
В ситуации заказной разработки, крупные заказчики часто отдают наружу лишь отдельные функции в рамках проекта. Нередко QA находится на стороне заказчика, с какими-то своими циклами тестирования и релизов. На выходе требуется не только код, но документация, вместе с инструкциями по развертыванию, тестированию и сопровождению.
Для scrum несложно искать аналогии во всем потому, что тут все занимаются всем понемногу. Проводя аналогии между разными областями, вы начинаете строить обобщения и наделять термины несвойственными им значениями, в результате чего получаются некорректные выводы. Принципиальная разница между разными моделями не в их, кажущихся на первый взгляд, сходствах, а в отличиях.
«Это ваша оценка вряд ли повышает успешность проекта.» В самом деле, для того, чтобы продуктивно торговаться, нужно иметь специфический набор навыков. Такой формат удобен людям с нормальным управленческим образованием, поставленной риторикой и прокаченными софт-скиллами, в большей степени, чем тем, кто умеет программировать компьютеры.
Если подходить к вопросу торга при оценке задач чисто с рыночных позиций, то в условиях свободного рынка, кастомизация продается дороже, а не дешевле типовых решений. Типовые же решения стоят вполне определенные деньги. Затраты снижаются за счет реюзинга, автоматизации и инноваций. Для обмена знаниями между инженерами рулит парное программирование и образовательные программы, а не стресс на глазах заказчика и менеджмента.
Возвращаясь же к нашим наемным работникам, то после «внедрения» scrum, все это и правда классно складывается на оперативных показателях. Как минимум, пока команда не разберется что к чему и соглашается на переработки. Но у этого есть свои побочные эффекты, из-за которых в нормальных компаниях, применяют другие методики управления, а не голимый scrum.
Кстати для тургрупп Scrum может быть применим вот прям сразу, т.к. они обычно однородны и действуют автономно.
В случае современной web-разработки, product increment в виде какого-нибудь банального лендинга может задейстовать целую зондер-команду всяких-разных специалистов. Например:
1. Sales/account manager
2. Business analyst
3. UX/UI designer
4. Frontend developer
5. Backend developer
6. DBA
7. QA
8. DevOps
9. Delivery manager
10. Tech writer
11. SEO engineer
Понятно, что нагрузка на них будет сильно варьироваться по времени. Scrum предлагает решать вопрос за счет совмещения ролей и сокращения штата. Просто в противном случае в рамках этой модели в разное время кому-то придется работать в поте лица, а кому-то — гонять танчики в ожидании коллег. Ведь команда не должна набирать в спринт больше работы, чем способна задеплоить. Вариант имеет право на жизнь, но не панацея же.
Постановка вопроса уже вызывает много вопросов. Но в науке, в отличии от практики, даже отрицательный результат это тоже результат. Хотя уж на совсем очевидные грабли наступать, конечно, не стоит. Пообщайтесь со своим научным консультантом на тему выбранной проблемы, гипотезы и метрик.
Как говорил Ильич: «Недостатки у человека как бы являются продолжением его достоинств. Но если достоинства продолжаются больше, чем надо, обнаруживаются не тогда, когда надо, и не там, где надо, то они являются недостатками».
Scrum, будучи монолитным «framework for managing product development», декларирует слишком много прикольных, но второстепенных, в общем-то, практик. Будучи декларированными эти практики становятся почему-то вдруг важными и при внедрении заставляют менять то, что нормально работает.
Scrum привносит свою систему ценностей и метрик, оптимизация под которые может идти в разрез с целями конкретного проекта, требованиями бизнеса, особенностями задач, спецификой коллективов и т.п.
Scrum предполагает включение и синхронизацию разработки product increment в пределах спринта и команды. Поэтому он плохо подходит для команд с высокой степенью специализации разработчиков, команд, распределенных географически или по времени, при наличии зависимостей от внешних подрядчиков, в ситуации комплексных фич, при наличии контроля качества снаружи, формализованной приемки и т.п… Чтобы обеспечить синхронизацию, процесс вынужден блокироваться, что уже само по себе вызывает кучу вопросов и поводов для менеджерского креатива. Отсюда же и ограничение на размер команд.
Пример специально упрощен для понимания проблемы и мой код сильно запутанней этого. Если бы createPost и addTagToPost лежали в стороннем модуле то мы могли использовать что-нибудь вроде jest для того чтобы перехватить обращения к ним, но в нашем случае это не решение задачи поскольку функции, вызовы которых мы хотели бы перехватить, могут быть скрыты глубоко внутри scope тестируемой функции и не экспортированы наружу.
Почему на этом месте нельзя перестать писать лапшу, и сделать рефакторинг?
зачем? coverage это просто цифра, которая ни чего не говорит о качестве тестов. в пределе, 100% покрытие можно легко получить, написав кучу тестов без единого ассерта.
Для файлов почта не практична. Мало-ли что не то или не туда можно отправить, а если отправишь, то назад уже не вернешь. Есть же диски, с диска хотя бы можно удалить.
)) вообще да — вращаться вместе с телефоном. как, например, обычно поступают, когда используют телефон в качестве навигатора. например, перемещаясь в пространстве, или крутиться на месте, вместе с телефоном, на офисном стуле. :)
интересно попытаться усилить эффект присутствия в групповых видеочатах, позиционируя голоса участников в пространстве — голос ведущего впереди, остальные — по кругу.
Основные вопросы, которые должен был решить REST, связаны с Hypermedia. Поэтому главный упор при выборе компромиссов в данном архитектурном стиле был сделан на решение проблем, касающихся представления.
Что же касается выполнения транзакций, то этот действительно важный и сложный вопрос в REST затронут только чуть (по сложившейся традиции затрагивать действительно важные и сложные вопросы с тем самым с умным видом, как будто и так все понятно).
По теме коммуникации в стиле REST/HTTP есть классная картинка на сайте Webmachine, как вариант описания единичной транзакции с помощью диаграммы — не к столу будет сказано — состояний.
Некоторая часть моментов, с которыми обычно сталкиваются разработчики RESTful приложений на концептуальном уровне, при решении простых задач, метафорически описана в How to GET a Cup of Coffee (ага, «нельзя просто так взять и взять»). Задачи конкуретного обновления (что, в принципе, не такая уж и экзотика для распределенных приложений), с большой вероятностью могут привести к двух- (трех-, рекурсивно-) фазным коммитам. Каково это в реализации для не очень сложного кейса про дебет с кредитом можно посмотреть, например здесь (не совсем REST, но очень близко по составу операций, буквально точностью до синтаксиса).
Конечно, в реальности, так ни кто не делает — это ни в какой бюджет. Всегда есть возможность отойти от канонов, в пользу каких-то упрощений. Как следствие, с момента изобретения, для индустрии вся эта веселуха вокруг RESTful архитектур вылилась в хренову гору человеко-часов, потраченных на разработку «подходящих» имплементаций REST-style со стороны тех кто старался что-то сделать, и гигабайты срачей в комментах со стороны тех кто пытался что-то понять.
В правильно приготовленной коммуникации, состояние транспортного канала не имеет отношения к REST — они находятся на разных уровнях.
Тем не менее, сбои надо обрабатывать.
в принципе, добровольное соглашательство со всеми нормами и отказ от права сомневаться в решения власти — это тоже выбор. если большой государственный файрвол наконец-то будет достроен, такие люди могут считать сей факт и своей заслугой.
с другой стороны, в нашем обществе, слово «свобода», похоже опять начинает что-то значить.
слово «privacy» на рынке потребительских товаров — как заметил Doktor_Gradus, ни к чему не обязывающий макетинговый слоган. типичный смартфон, под разными предлогами, отправляет о вас больше телеметрии, чем можете себе представить. это ни куда не денется, пока владение информацией дает корпорациям преимущества (мне сложно представить обратную ситуацию, когда больше профита начнет давать неведение).
В ситуации заказной разработки, крупные заказчики часто отдают наружу лишь отдельные функции в рамках проекта. Нередко QA находится на стороне заказчика, с какими-то своими циклами тестирования и релизов. На выходе требуется не только код, но документация, вместе с инструкциями по развертыванию, тестированию и сопровождению.
Если подходить к вопросу торга при оценке задач чисто с рыночных позиций, то в условиях свободного рынка, кастомизация продается дороже, а не дешевле типовых решений. Типовые же решения стоят вполне определенные деньги. Затраты снижаются за счет реюзинга, автоматизации и инноваций. Для обмена знаниями между инженерами рулит парное программирование и образовательные программы, а не стресс на глазах заказчика и менеджмента.
Возвращаясь же к нашим наемным работникам, то после «внедрения» scrum, все это и правда классно складывается на оперативных показателях. Как минимум, пока команда не разберется что к чему и соглашается на переработки. Но у этого есть свои побочные эффекты, из-за которых в нормальных компаниях, применяют другие методики управления, а не голимый scrum.
В случае современной web-разработки, product increment в виде какого-нибудь банального лендинга может задейстовать целую зондер-команду всяких-разных специалистов. Например:
1. Sales/account manager
2. Business analyst
3. UX/UI designer
4. Frontend developer
5. Backend developer
6. DBA
7. QA
8. DevOps
9. Delivery manager
10. Tech writer
11. SEO engineer
Понятно, что нагрузка на них будет сильно варьироваться по времени. Scrum предлагает решать вопрос за счет совмещения ролей и сокращения штата. Просто в противном случае в рамках этой модели в разное время кому-то придется работать в поте лица, а кому-то — гонять танчики в ожидании коллег. Ведь команда не должна набирать в спринт больше работы, чем способна задеплоить. Вариант имеет право на жизнь, но не панацея же.
Scrum, будучи монолитным «framework for managing product development», декларирует слишком много прикольных, но второстепенных, в общем-то, практик. Будучи декларированными эти практики становятся почему-то вдруг важными и при внедрении заставляют менять то, что нормально работает.
Scrum привносит свою систему ценностей и метрик, оптимизация под которые может идти в разрез с целями конкретного проекта, требованиями бизнеса, особенностями задач, спецификой коллективов и т.п.
Scrum предполагает включение и синхронизацию разработки product increment в пределах спринта и команды. Поэтому он плохо подходит для команд с высокой степенью специализации разработчиков, команд, распределенных географически или по времени, при наличии зависимостей от внешних подрядчиков, в ситуации комплексных фич, при наличии контроля качества снаружи, формализованной приемки и т.п… Чтобы обеспечить синхронизацию, процесс вынужден блокироваться, что уже само по себе вызывает кучу вопросов и поводов для менеджерского креатива. Отсюда же и ограничение на размер команд.
Почему на этом месте нельзя перестать писать лапшу, и сделать рефакторинг?
интересно попытаться усилить эффект присутствия в групповых видеочатах, позиционируя голоса участников в пространстве — голос ведущего впереди, остальные — по кругу.
Что же касается выполнения транзакций, то этот действительно важный и сложный вопрос в REST затронут только чуть (по сложившейся традиции затрагивать действительно важные и сложные вопросы с тем самым с умным видом, как будто и так все понятно).
По теме коммуникации в стиле REST/HTTP есть классная картинка на сайте Webmachine, как вариант описания единичной транзакции с помощью диаграммы — не к столу будет сказано — состояний.
Некоторая часть моментов, с которыми обычно сталкиваются разработчики RESTful приложений на концептуальном уровне, при решении простых задач, метафорически описана в How to GET a Cup of Coffee (ага, «нельзя просто так взять и взять»). Задачи конкуретного обновления (что, в принципе, не такая уж и экзотика для распределенных приложений), с большой вероятностью могут привести к двух- (трех-, рекурсивно-) фазным коммитам. Каково это в реализации для не очень сложного кейса про дебет с кредитом можно посмотреть, например здесь (не совсем REST, но очень близко по составу операций, буквально точностью до синтаксиса).
Конечно, в реальности, так ни кто не делает — это ни в какой бюджет. Всегда есть возможность отойти от канонов, в пользу каких-то упрощений. Как следствие, с момента изобретения, для индустрии вся эта веселуха вокруг RESTful архитектур вылилась в хренову гору человеко-часов, потраченных на разработку «подходящих» имплементаций REST-style со стороны тех кто старался что-то сделать, и гигабайты срачей в комментах со стороны тех кто пытался что-то понять.
Тем не менее, сбои надо обрабатывать.