идентификатором владельца, который может занимать до 1024 байт. Проблема в том, что буфер ответа — всего 112 байт. Итого 1056 байт пишутся в 112-байтный буфер
Вероятно, ещё 32 байта взялись из прочих данных ответа сервера, но без пояснений выглядит либо как ошибка, либо как пропущенная информация.
А вот если бы вы код переписали на JavaScript, то для сайта и wasm бы не потребовался 😀 там же вообще никакой зависимости от консоли нет, судя по быстрому просмотру кода.
А по делу, очень прикольно, спасибо за идею и описанию.
Да, виноват, я их часто использую взаимозаменяемо. Потому что если нет каких-то особенных факторов (отпуск, много багов внезапно, и так далее), то velocity сойдёт за оценку capacity на ближайший спринт. Но может путать, наверное. Главное, чтобы команда понимала, о чем речь идёт.
Если промоутер не обратил внимания на пункт про конфеты, значит, он мог так же халатно отнестись к важным техническим требованиям, чуть ли не обрушением сцены. Коричневые 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 юзер-стори в спринте.
Так ведь если утилита в одном исходном файле, то borrow checker вы даже не заметите.
Вероятно, ещё 32 байта взялись из прочих данных ответа сервера, но без пояснений выглядит либо как ошибка, либо как пропущенная информация.
Вы в начале статьи привели в пример
которые на разработку ориентированы, а потом раз -- и сделали ассистента, который ходит по интернету.
я видел в конце статьи про планы сделать работу с локальными файлами, но все равно это немного другая цель по сравнению с, скажем, Claude.
А вот если бы вы код переписали на JavaScript, то для сайта и wasm бы не потребовался 😀 там же вообще никакой зависимости от консоли нет, судя по быстрому просмотру кода.
А по делу, очень прикольно, спасибо за идею и описанию.
Да, виноват, я их часто использую взаимозаменяемо. Потому что если нет каких-то особенных факторов (отпуск, много багов внезапно, и так далее), то velocity сойдёт за оценку capacity на ближайший спринт. Но может путать, наверное. Главное, чтобы команда понимала, о чем речь идёт.
И статью, похоже, тоже Клод писал 😀
История хорошая, но как бы намекает, что исполнитель должен бездумно следовать инструкциям. Иногда так нужно. А иногда (особенно, если сроки поджимают и нужно расставлять приоритеты) придется отделать важное от не очень.
Райдер группы это типа тех задание, то есть должно же быть разделение на критические требования и желательные.
Перевод ещё таки страдает. Выбрал 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 юзер-стори в спринте.