Вы наверно согласитесь, что переходный процесс, связанный с внедрением новой методики, вряд-ли может быть линейным и гладким если ни кто не собирается внедрять вечность? Поэтому отклонения происходят всегда. Технарям, зачастую, свойственен оптимизм в плане прогнозов, а работать с рисками они не умеют. Скрам-покер при планировании добавляет азарта, т.к. в целом играет на понижение оценок.
Из-за этого недооценки командами объема работ на первых этапах случаются регулярно. На моей практике еще не было случая, чтобы в такой ситуации менеджмент упустил возможность напомнить команде о важности соответствовать своим должностям и выполнять работу к обещанному сроку. Отсюда систематические переработки. У вас иной опыт?
Обученные команды торгуются за комфортные условия круче московских таксистов, и тут уже менджмент теряет всякий интерес к этой методологии.
Решетки на входе в школах уже есть. Охрана на этажах. РКН в Интернете оберегает от педофилов. Теперь глушилки для ЕГЭ. Осталось заборы колючей проволокой обнести (чтобы записки не передавали, а не то что вы подумали). Если задача показать всем еще со школы: «я — государство. что хочу то и делаю. а вы — привыкайте», наверно в этом есть смысл.
Зачем в файле с ресурсами для игры директории и имена файлов, кто там на них будет смотреть? Blizzard в своем известном формате заменяет все это многобуквенное великолепие просто на хеши (логика разработчиков вполне понятна, хоть и бесит чисто по-человечески). ^)
Какие-то готовые решения уже рассматривали? В практическом смысле, задачи эффективного доступа к ресурсам в играх появились давно и многие вопросы уже решены, но там совсем другой порядок компромиссов и сложности.
По идее форматов там 14несколько. В довесок есть всякие особенности представления ссылок, расширенных атрибутов, sparse файлов и т.п. Если поставить себе задачу наступить на грабли при чтении произвольного tar архива — это сделать совсем не сложно)
Правильно-ли я понимаю, что основная задача это архивирование? Возможно, для ваших кейсов больше подойдет обычный ar:
ar -cq out.ar file1.txt file2.txt
tar оптимизирован для бэкапов блочных устройств на летны (tape). Отсюда блоки по 512 байт, что соответствует популярному размеру сектора дисков. Но если основной кейс это распаковка в память, то фича скорее не нужна.
Код, который работает корректно, это не всегда тот, код, который делает то, что нужно, и так как нужно. QA это комплексная проблема, которая решается только в комплексе.
Все заранее известно и разработка сводится к программированию лишь на уроках информатики. На практике приходится иметь дело с большим разнообразием функциональных и не функциональных требований, кроме валидности логики, прежде чем сдавать работу.
И потом, не стоит сбрасывать со счетов банальный человеческий фактор. Два глаза хорошо, а четыре еще лучше. :)
Ну не все так однозначно, тут тоже придется считать. Ведь время, которое потратит разработчик на тестирование, и соответственно не-писание новых нужных бизнесу фич, стоит вполне конкретных денег, которые могут быть больше или меньше затрат на тестировщика и всю эту остальную веселую компанию. Отдельные регрессионные тесты могут выполняться целую вечность, а для запуска других, порой, приходится ждать наступления определенной фазы (нет, не луны, а готовности других компонентов). Как бы то ни было, в порочном круге Software Release Life Cycle всему найдется свое место и свое время.
Если у вас разработчики такие, что пишут только баги, где гарантии, что они напишут тесты, которые хоть что-то тестят? При должном усердии можно и 100% покрытие тестами показать, без единого осмысленного assert.
Пока все это напоминает историю с аналоговыми компьютерами и холодным термоядерным синтезом. Математики мамой клянутся, что давно просекли тему: пять минут страха, кропаль каких-то ярдов денег и, пацаны, вы в доле, все будет в шоколаде!
Но на практике попытки реализации упираются в очередное дурацкое несовершенство физического мира, с его инерционностями, нелинейностями и тому подобными гадостями. Пока еще ни кто не доказал, что физический квантовый мир обладает всеми нужными свойствами, каким его представляет себе модель КК, и из этой затеи выйдет что-то полезное.
Законы нужны ведь не сами по себе. Это система, которую государство предоставляет гражданам для решения споров или поиска защиты. В мире существует несколько принципиально разных правовых систем, которые некорректно сравнивать по каким-то отдельным деталям. Тут важнее конечный результат: в какой мере решение учитывает нюансы вопроса и является объективным.
В Штатах есть две ветви власти: федеральная и окружная (state). Здесь федеральный это не уровень, как скажем в РФ, а именно отдельная ветвь. В поисках защиты вы можете обращаться к любой, где исход сочтете наиболее выгодным для себя (хотя для отдельных кейсов есть свои правила). Решения обязательны к исполнению в любом случае. Пересмотр дела в другой ветви, как правило, невозможен. Поэтому вопрос противоречий не является столь принципиальным.
Гугл подчиняется законам USA и аппелирует к ним же, аргументируя свою позицию. В данном случае федералы сделали официальный запрос данных c аккаунтов, владельцами которых являются резиденты USA. Это ключевой нюанс. Потому, что с нерезидентами таких заморочек нет.
В этом все и дело. Agile как концепция и Scrum как набор конкретных методик и практик это разные вещи. Гибкость состоит не в том, чтобы вгонять коллектив в рамки, которые требует гибкая методика, а возможности выстраивать процесс с учетом специфики проекта и наиболее эффективного использования имеющихся ресурсов.
Вопрос «может в принципе или не может» это уже давно не самый важный вопрос. В принципе этим может заниматься кто угодно, но специально подготовленные люди справляются лучше.
Из-за этого недооценки командами объема работ на первых этапах случаются регулярно. На моей практике еще не было случая, чтобы в такой ситуации менеджмент упустил возможность напомнить команде о важности соответствовать своим должностям и выполнять работу к обещанному сроку. Отсюда систематические переработки. У вас иной опыт?
Обученные команды торгуются за комфортные условия круче московских таксистов, и тут уже менджмент теряет всякий интерес к этой методологии.
14несколько. В довесок есть всякие особенности представления ссылок, расширенных атрибутов, sparse файлов и т.п. Если поставить себе задачу наступить на грабли при чтении произвольного tar архива — это сделать совсем не сложно)tar оптимизирован для бэкапов блочных устройств на летны (tape). Отсюда блоки по 512 байт, что соответствует популярному размеру сектора дисков. Но если основной кейс это распаковка в память, то фича скорее не нужна.
Все заранее известно и разработка сводится к программированию лишь на уроках информатики. На практике приходится иметь дело с большим разнообразием функциональных и не функциональных требований, кроме валидности логики, прежде чем сдавать работу.
И потом, не стоит сбрасывать со счетов банальный человеческий фактор. Два глаза хорошо, а четыре еще лучше. :)
Но на практике попытки реализации упираются в очередное дурацкое несовершенство физического мира, с его инерционностями, нелинейностями и тому подобными гадостями. Пока еще ни кто не доказал, что физический квантовый мир обладает всеми нужными свойствами, каким его представляет себе модель КК, и из этой затеи выйдет что-то полезное.
фронтендерафраера принял :)В Штатах есть две ветви власти: федеральная и окружная (state). Здесь федеральный это не уровень, как скажем в РФ, а именно отдельная ветвь. В поисках защиты вы можете обращаться к любой, где исход сочтете наиболее выгодным для себя (хотя для отдельных кейсов есть свои правила). Решения обязательны к исполнению в любом случае. Пересмотр дела в другой ветви, как правило, невозможен. Поэтому вопрос противоречий не является столь принципиальным.
Вопрос «может в принципе или не может» это уже давно не самый важный вопрос. В принципе этим может заниматься кто угодно, но специально подготовленные люди справляются лучше.