Если промоутер не обратил внимания на пункт про конфеты, значит, он мог так же халатно отнестись к важным техническим требованиям, чуть ли не обрушением сцены. Коричневые M&M's были индикатором внимания к деталям.
История хорошая, но как бы намекает, что исполнитель должен бездумно следовать инструкциям. Иногда так нужно. А иногда (особенно, если сроки поджимают и нужно расставлять приоритеты) придется отделать важное от не очень.
Райдер группы это типа тех задание, то есть должно же быть разделение на критические требования и желательные.
Перевод ещё таки страдает. Выбрал En, а часть сообщений остались на русском: метка "Вы", значение "Среднее" на столе, "Ожидание игроков" , ну и "сервис от создателей" внизу.
sqlite сильно пессимизирует и обобщает лет так на 15 😀
Да, блокировки в NFSv3 (которые отдельный протокол NLM, да и сам NFSv3 без сессий) действительно плохо работают вместе с NAT, фаерволами, роумингом wifi со сменой IP адресов, засыпанием ноутбуков. Если таких проблем нет, то даже NFSv3/NLM работает надёжно.
Но современные Linux-ы давно по умолчанию используют NFSv4, в котором блокировки уже часть протокола.
Про Windows faq ссылается на FAT и косяки реализации. Это тоже уже устарело до смешного. Любой современный Windows с NTFS и SMBv3 поддерживает блокировки без каких-либо проблем давно. А с persistent handles клиенты даже перезагрузки сервера переживут.
Верю, скажем, что когда-то были баги в Samba. Но сейчас уже давно ребята из SerNet хорошо работают над Samba. Если только у вас не файловый сервер на каком-то дремучем NAS, то проблем не будет.
Так что сетевые диски точно не нужно запрещать. Предупреждение можно, если хотите 😀
Единственно, если не уже (я не смотрел код), то стоит I/O делать асинхронно, чтобы основной UI не замирал, если вдруг сетевой диск затупил.
Иногда бывает, что вся разработка и любая работа с данными должны быть на специальном сервере. А на вашем компе/ноутбуке только браузер, терминал с ssh, ну и vs code.
есть летучки по утрам, там раздают задачи на день. Менеджеры договариваются между...
(...)
Задачи я не обсуждаю. Мне командуют — я делаю. Надо это кому-то или нет, не моё дело.
то да, итерации тут не нужны. Насколько все довольны ходом разработки -- другой вопрос.
Agile и Scrum предназначены для команд, устроенных так, что команда принимает участие в разборе требований, планировании, декомпозиции и так далее.
Если начальство "вводит скрам", но не меняет ни методы работы, ни тех организацию, то получается фигня. Программисты видят, что в работе ничего не поменялось, но добавили ещё церемоний. Выхлопа нет, стало даже хуже. Делают вывод, что скрам не работает.
Почти всегда можно выбрать юзер-стори, которая либо нужна раньше, либо более рискованна (и нужно начать разбираться раньше).
Задачи, не связанные с основной целью спринта -- легко. Это может быть небольшое улучшение, которое взяли из беклога для заполнения спринта.
Мне кажется, что идея жёсткой цели спринта считается уже не такой важной. Слишком жёсткая формальная рамка, отвлекающая от смысла.
Похожий пример: burndown chart внутри спринта с ежедневным обновлением того, сколько пойнтов осталось. Лет 15 назад это был самый скрам. Сейчас же на это смотрят как на непродуктивную деятельность. Важны завершенные юзер-стори, добавляющие ценность в продукт. В какой именно спринт засчитаны пойнты не так важно, все равно смотрят на среднюю velocity за несколько спринтов.
Сворминг это непонятное мне слово 😀 два человека это уже swarm или нет? Вполне нормально, например, когда команда из 4 человек работает над 2-3 юзер-стори в спринте.
Так ведь Scrum (и Agile вообще) как раз и задумывался как мини водопад!
В Kanban WIP-лимит явно прописан. В Scrum, во-первых, количество задач ограничено емкостью спринта (velocity), а во-вторых, предполагается, что команда фокусируется на важных задачах в спринте, а не бросается работать над всем сразу.
Если же "на QA или продактов сразу вываливается большой объем работы по приёмке", то дело скорей всего в другом. Важный и неотъемлемый принцип Agile -- это автоматическое непрерывное тестирование всего вообще, и это тестирование есть ответственность команды. В идеале, продакт может посмотреть на состояние приемочных тестов (acceptance test) и убедиться, что система работает так, как задумывалась. Много времени это не должно же занимать. QA же должен заниматься тестированием того, что команда не может автоматизировать сама, а не просто проверять работу за программистами.
Понятно, что на практике идеал никогда не достижим, но нельзя недостижимостью идеала оправдывать сваливание в другую крайность, когда команда не делает свою работу.
Предположим, есть рецепт пирога. В нем указаны ингредиенты и последовательность действий.
В некоторых пределах можно менять и соотношения в составе, и порядок действий.
Но если выкинуть важный ингредиент или не поставить в печку, то получится фигня.
Смысл церемоний не в том, чтобы их обязательно проводить и обязательно какой-то определенной длины, а в том, что они задают моменты времени, когда команда останавливается на мгновение и соображает, в правильную сторону ли она двигается, нужные ли задачи решает, приносит ли пользу бизнесу, и так далее.
И статью, похоже, тоже Клод писал 😀
История хорошая, но как бы намекает, что исполнитель должен бездумно следовать инструкциям. Иногда так нужно. А иногда (особенно, если сроки поджимают и нужно расставлять приоритеты) придется отделать важное от не очень.
Райдер группы это типа тех задание, то есть должно же быть разделение на критические требования и желательные.
Перевод ещё таки страдает. Выбрал En, а часть сообщений остались на русском: метка "Вы", значение "Среднее" на столе, "Ожидание игроков" , ну и "сервис от создателей" внизу.
Не знаю, как распространено это заблуждение, но столица штата Вашингтон это город Олимпия, а не Сиэтл.
https://en.wikipedia.org/wiki/Olympia,_Washington
Нет, может быть составным 😀 (не удержался)
sqlite сильно пессимизирует и обобщает лет так на 15 😀
Да, блокировки в NFSv3 (которые отдельный протокол NLM, да и сам NFSv3 без сессий) действительно плохо работают вместе с NAT, фаерволами, роумингом wifi со сменой IP адресов, засыпанием ноутбуков. Если таких проблем нет, то даже NFSv3/NLM работает надёжно.
Но современные Linux-ы давно по умолчанию используют NFSv4, в котором блокировки уже часть протокола.
Про Windows faq ссылается на FAT и косяки реализации. Это тоже уже устарело до смешного. Любой современный Windows с NTFS и SMBv3 поддерживает блокировки без каких-либо проблем давно. А с persistent handles клиенты даже перезагрузки сервера переживут.
Верю, скажем, что когда-то были баги в Samba. Но сейчас уже давно ребята из SerNet хорошо работают над Samba. Если только у вас не файловый сервер на каком-то дремучем NAS, то проблем не будет.
Так что сетевые диски точно не нужно запрещать. Предупреждение можно, если хотите 😀
Единственно, если не уже (я не смотрел код), то стоит I/O делать асинхронно, чтобы основной UI не замирал, если вдруг сетевой диск затупил.
Расскажите, чем вызваны эти опасения.
Интересно, почему переехали на UpNote, а не купили Obsidian Sync?
и даже
Строго говоря, это не обновление ресурса, потому что в ресурсе вряд ли есть поля
opиvalue. Это действия, которые лучше делать через POST.С PUT и PATCH обычно следуют правилу, что результат GET можно отправить в PUT или PATCH.
Но даже в вашем примере (increment через POST) можно защититься от повторного изменение с помощью etag и if-match.
Думаю, они на рынок США нацелены сейчас, а там такая цена может пойти.
Иногда бывает, что вся разработка и любая работа с данными должны быть на специальном сервере. А на вашем компе/ноутбуке только браузер, терминал с ssh, ну и vs code.
Жаль, что ни в статье, ни в программе курса нет ни слова о тестировании. Для сознательных новичков было бы в самый раз.
Хвалят приложение ConjuGato Spanish Verbs, но лично не знаком.
Зависит от организации работы.
Если как написал кто-то в соседнем комментарии
то да, итерации тут не нужны. Насколько все довольны ходом разработки -- другой вопрос.
Agile и Scrum предназначены для команд, устроенных так, что команда принимает участие в разборе требований, планировании, декомпозиции и так далее.
Если начальство "вводит скрам", но не меняет ни методы работы, ни тех организацию, то получается фигня. Программисты видят, что в работе ничего не поменялось, но добавили ещё церемоний. Выхлопа нет, стало даже хуже. Делают вывод, что скрам не работает.
Почти всегда можно выбрать юзер-стори, которая либо нужна раньше, либо более рискованна (и нужно начать разбираться раньше).
Задачи, не связанные с основной целью спринта -- легко. Это может быть небольшое улучшение, которое взяли из беклога для заполнения спринта.
Мне кажется, что идея жёсткой цели спринта считается уже не такой важной. Слишком жёсткая формальная рамка, отвлекающая от смысла.
Похожий пример: burndown chart внутри спринта с ежедневным обновлением того, сколько пойнтов осталось. Лет 15 назад это был самый скрам. Сейчас же на это смотрят как на непродуктивную деятельность. Важны завершенные юзер-стори, добавляющие ценность в продукт. В какой именно спринт засчитаны пойнты не так важно, все равно смотрят на среднюю velocity за несколько спринтов.
Сворминг это непонятное мне слово 😀 два человека это уже swarm или нет? Вполне нормально, например, когда команда из 4 человек работает над 2-3 юзер-стори в спринте.
Так ведь Scrum (и Agile вообще) как раз и задумывался как мини водопад!
В Kanban WIP-лимит явно прописан. В Scrum, во-первых, количество задач ограничено емкостью спринта (velocity), а во-вторых, предполагается, что команда фокусируется на важных задачах в спринте, а не бросается работать над всем сразу.
Если же "на QA или продактов сразу вываливается большой объем работы по приёмке", то дело скорей всего в другом. Важный и неотъемлемый принцип Agile -- это автоматическое непрерывное тестирование всего вообще, и это тестирование есть ответственность команды. В идеале, продакт может посмотреть на состояние приемочных тестов (acceptance test) и убедиться, что система работает так, как задумывалась. Много времени это не должно же занимать. QA же должен заниматься тестированием того, что команда не может автоматизировать сама, а не просто проверять работу за программистами.
Понятно, что на практике идеал никогда не достижим, но нельзя недостижимостью идеала оправдывать сваливание в другую крайность, когда команда не делает свою работу.
Предположим, есть рецепт пирога. В нем указаны ингредиенты и последовательность действий.
В некоторых пределах можно менять и соотношения в составе, и порядок действий.
Но если выкинуть важный ингредиент или не поставить в печку, то получится фигня.
Смысл церемоний не в том, чтобы их обязательно проводить и обязательно какой-то определенной длины, а в том, что они задают моменты времени, когда команда останавливается на мгновение и соображает, в правильную сторону ли она двигается, нужные ли задачи решает, приносит ли пользу бизнесу, и так далее.
Более того, SMB 2, 3, 3.11 считают подписи разными способами.
Для полноты добавлю замечательную статью на английском, которая хорошо дополняет официальную документацию от Microsoft.
https://davenport.sourceforge.net/ntlm.html
В оригинале по ссылке написано:
Revenue это все же выручка, а не прибыль (которая profit).