Я работал в пяти компаниях, в каждой из которых подход к построению "своего" скрама немного различался
И это нормально. Скрам не является методологией, а фреймворк, из которого каждая команда лепит свой процесс конкретной под себя. Раком скрам становится, когда это преподносится как методология, читай, кто-то сверху за всех остальных придумал как им работать. Это так не делается. У каждой команды должна быть свобода делать как им лучше.
Всё равно программы с багами (хотя это отдельный вопрос, но всё-таки связанный)
Вообще никаким местом не связанный. Скрам не был придуман ни для улучшения качества, ни скорости разработки, ни еще чего либо кроме одного - повышения адаптируемости к изменяющимся условиям. Выйдет ли из этого экономия денег, времени - вопрос второй.
В общем, весь ваш пост вообще не про скрам, а про микроменджмент и плохое управление командами в целом. Это будет актуально при любой методологии, любом подходе. Об этом надо писать, а не о скраме. Уйдет скрам, придет другая модная фигня, на которую все кинутся в поисках решения всех их проблем. Это конечно интересно устраивать флешмоб и отказываться работать по скраму, только проблему конкретную это не решает.
Потому что везде менеджеры одинаковые и пытаются контролировать процессы? Да, теория разбивается о практику, что люди не готовы терять ощущение контроля. Скрам то тут при чем?
Так скрам и не просит репортить и конкретно говорит этого не делать как раз. Задача идет - сказать нечего, все ок. Есть блокеры - озвучиваешь. Что-то пошло совсем не так - озвучиваешь, чтобы команда могла скорректировать планы. Вот для этого дейлик и более ни для чего.
Угу, ими и не надо пользоваться. Ниразу не видел их использования. Ни в своих проектах, ни в каких-либо зависимостях, которые смотрел сорцы. Если еще примут пропозал об их удалении из языка, то будет совсем замечательно.
Каких конфликтов? Все внешние символы всегда используют полный квалификатор с указанием имени пакета, что как раз исключает конфликты имен. Есть проблемы только с пакетами с одинаковым именем, для чего есть переименование при импорте.
Так на словах совершенно не ясно, о каких конфликтах речь. Нужен пример. Вот в шарпах могу представить, где символы прям напрямую импортируются обычно и обращаешься к ним так, будто они у тебя локально в неймспейсе лежат.
Вполне стандартная тема для многих языков. Тот же C# шарит все внутри одного неймспейса между файлами. В Go есть одна вещь, которая сильно улучшает читабельность - можно однозначно отличить, откуда символ пришел. Если у него нет идентификатора пакет, то это локальный символ из текущего пакета (опускаем dot-imports, которыми никто не пользуется). Иначе, всегда будет идентификатор пакета и по импортам ясно, откуда он пришел. Теже шарпы или Java читать намного сложнее, потому что при импорте все символы, как правило, доступны напрямую без необходимости писать идентификатор неймспейса. И хер ты без IDE поймешь, откуда взялся тот или иной класс.
Не знаю, где обычно, но обычно как раз все пишется в одном пакете. В отдельный пакет выносятся тесты обычно для так сказать более строго отделения от подробностей реализации (и поэтому очень полезно, что ты не можешь непубличный метод достать. В этом вся фишка), либо по каким-то объективным иным причинам. Например, интеграционный тесты часто туда уносят, т.к. обычно это целая гора никак не связанного с основным приложением кода. Порой еще выносят это в отдельный го модуль, чтобы не тянуть ненужные зависимости в основной бинарь.
А зачем это нужно? Ты либо импортируешь пакет, либо нет. К пакету всегда обращение через его имя, поэтому пофиг, сколько десятков тысяч символов в нем. И читается это всегда однозначно
Конкретно для клаудфлейр раст был выбран совсем не из-за того, что плюсы не справляются. Нджинкс на расте был бы такой же медленный для них. Проблема в его архитектуре. Раст там именно что был выбран как более модный и современный с гарантиями безопасности.
По-моему в C изначально UB именно для этого и было и означало скорее implementation defined поведение. Т.е. язык как бы не при делах, но в конкретных условиях все ок. В те времена C еще можно было считать человекочитаемым ассемблером.
Сейчас же UB предназначено целиком и полностью для оптимизации, чтобы у компилятора была свобода ломать код так, как ему вздумается. Платформа здесь не имеет значения, потому что компилятор не смотрит на то, что в какой-то системе two's complement представление чисел. Для него UB это UB на любой платформе. Собственно, для него вообще платформы конечной не существует - он работает с абстрактной машиной. Поэтому как выше писали, проверка на переполнение будет просто удалена компилятором. Поэтому и версия компилятора может запросто сломать то, что работало раньше, если оно опиралось на UB.
Только вот заказчик не обязан ничего принимать. На испытаниях запросто может оказаться, что интерпретации исполнителя и заказчика расходятся и последний не считает ТЗ выполненным. И дальше только в суд и не факт, что исполнитель еще прав, тк возможно пытается натягивать сову на глобус, чтобы не переделывать ничего. И аджайл тут как раз очень кстати, тк позволит скорректировать реализацию на раннем этапе и прийти на испытания по сути как на формальность, тк заказчика уже все устраивает и он все видел. Интерес тут с обоих сторон есть и на моей практике теже гос заказчики очень желают так работать
Единица измерения в скраме совсем другая - польза бизнесу, а никакая не скорость разработки в вакууме. Можно гордо строчить задачи одна за другой и хвастаться скоростью, но потом окажется, что все эти задачи сделаны в пустую.
Польза от скрама постулируется по сути одна - увеличение пользы для бизнеса за счет коротких циклов разработки и постоянного фидбека. Чтобы как выше пишут не оказалось, что мы год писали что-то очень быстро в отрыве от всех и били рекорды, а потом оказалось, что большая часть сделана впустую. Поэтому да, вот так в лоб нельзя сравнивать.
Почему с первым. В целом система защиты xbox 360 полагалась на eFuse как средство против даунгрейда. Там был счетчик, который при каждом обновлении увеличивался, физически "прожигая" фьюз.
Теоретически да с учетом, что сама ВМ написана на тех же плюсах. На практике, я не могу найти уязвимостей особо в их JITe. Почему так - сложно сказать. Возможно виной тому дизайн байткода, семантика самого языка. Его куда легче верифицировать чем JS, в котором все что угодно на уровне системы типов может твориться.
Другая часть это стандартная библиотека. Тут все очевидно. У Java и .Net она реализована на Java и C# соответственно. Тем самым, практически весь код JDK и .Net Core получает те же гарантии безопасности, что код приложений. Остается лишь относительно маленькая часть на плюсах, которая реализует GC, JIT и вот это все. Javascript и V8 реализация как минимум сделана иначе. Там и стандартная библиотека написана на плюсах и можно найти множество CVE, которые были вызваны именно этим.
Нет, этот вывод как раз таки универсальный. Если погуглить, то примерно такая же статистика есть по Windows, Linux, iOS, macOS, android. И все эти проблемы были бы решены безопасными языками.
куда уж взломщикам понять во что выльется их попытка влезть в эту систему
Взломщикам плевать на компилятор. У них есть готовый бинарь и окружение и под них пишется шеллкод. Если надо, под конкретные версии.
Реальные уязвимости связаны с людьми и логическими ошибками
Реальные уязвимости связаны как раз с тем, что в статье перечислено. Выходы за границы, двойное освобождение, целочисленные переполнения - все это реально эксплуатируется постоянно. Более того, эксплуатируется порой не напрямую, а косвенно из того же Javascript атакуют JIT. И вы еще говорите о невозможности чего-то там взломщиками.
Эту проблему не способен решить никакой язык
Эта проблема полностью решена в GC языках как класс. Она практически полностью решена в Swift за исключением циклических ссылок. Но и они очень редко создают проблемы.
в языке Go нет 'const', при этом все функции принимают всё по (мутабельным) указателям, а менять данные из двух потоков - уб. Невероятно безопасный язык.
Во-первых, в Go не такого понятия как UB и гонки не приводят к UB в том понимании, в котором это заведено в C/C++. Есть строго определенное число возможных исходов. И самое главное, это не приведет к эксплуатируемой уязвимости. Максимум это логическая ошибка или рантайм паника.
Зато двоичный поиск генерирует кэш промахи и сбивает логику префетчинга, а на этом часто весь перформанс и умирает. Подобное надо бенчить на конкретных продовых данных.
В сях массив таки придется весь пройти, чтобы длину получить. И тогда бинарный поиск тут уже будет бесполезен, как и сам факт отсортированности массива.
Для инвалидации in-memory всех инстансов не нужно заводить редисы и прочие pub-sub. Достаточно каждый инстанс посадить на топик без consumer group и пусть каждый читает одни и теже эвенты.
По thundering herd. Есть простое решение в виде библиотеки singleflight и подобной ей механизмов. Пока один запрос выполняется, все остальные стоят и ждут на локе. После разблокировки все получат один и тот же ответ и дальше пойдет раздача из кэша. Можно сделать лок распределенным, но в большинстве случаев не страшно, если будут локальные локи и каждый инстанс пойдет на промахе один раз в основной стор.
По этой же причине отвал был и у xbox 360, и у nvidia чипов.
Помню эти времена и все эти колхозные решения. Реболл это был высший пилотаж. Обычно же в домашних условиях кулер посильнее прикручивался, так называемой метод прижима. Мой 360 в таких условиях прожил еще несколько лет. Сначала да, думали на шарики под bga. Потом уже додумали, что на самом деле проблема в креплении кристалла к подложке. А видео выше дало еще более точный ответ - проблема в компаунде. Тогда не помню, чтобы о такой версии говорили.
И это нормально. Скрам не является методологией, а фреймворк, из которого каждая команда лепит свой процесс конкретной под себя. Раком скрам становится, когда это преподносится как методология, читай, кто-то сверху за всех остальных придумал как им работать. Это так не делается. У каждой команды должна быть свобода делать как им лучше.
Вообще никаким местом не связанный. Скрам не был придуман ни для улучшения качества, ни скорости разработки, ни еще чего либо кроме одного - повышения адаптируемости к изменяющимся условиям. Выйдет ли из этого экономия денег, времени - вопрос второй.
В общем, весь ваш пост вообще не про скрам, а про микроменджмент и плохое управление командами в целом. Это будет актуально при любой методологии, любом подходе. Об этом надо писать, а не о скраме. Уйдет скрам, придет другая модная фигня, на которую все кинутся в поисках решения всех их проблем. Это конечно интересно устраивать флешмоб и отказываться работать по скраму, только проблему конкретную это не решает.
Потому что везде менеджеры одинаковые и пытаются контролировать процессы? Да, теория разбивается о практику, что люди не готовы терять ощущение контроля. Скрам то тут при чем?
Так скрам и не просит репортить и конкретно говорит этого не делать как раз. Задача идет - сказать нечего, все ок. Есть блокеры - озвучиваешь. Что-то пошло совсем не так - озвучиваешь, чтобы команда могла скорректировать планы. Вот для этого дейлик и более ни для чего.
Угу, ими и не надо пользоваться. Ниразу не видел их использования. Ни в своих проектах, ни в каких-либо зависимостях, которые смотрел сорцы. Если еще примут пропозал об их удалении из языка, то будет совсем замечательно.
Каких конфликтов? Все внешние символы всегда используют полный квалификатор с указанием имени пакета, что как раз исключает конфликты имен. Есть проблемы только с пакетами с одинаковым именем, для чего есть переименование при импорте.
Так на словах совершенно не ясно, о каких конфликтах речь. Нужен пример. Вот в шарпах могу представить, где символы прям напрямую импортируются обычно и обращаешься к ним так, будто они у тебя локально в неймспейсе лежат.
Вполне стандартная тема для многих языков. Тот же C# шарит все внутри одного неймспейса между файлами. В Go есть одна вещь, которая сильно улучшает читабельность - можно однозначно отличить, откуда символ пришел. Если у него нет идентификатора пакет, то это локальный символ из текущего пакета (опускаем dot-imports, которыми никто не пользуется). Иначе, всегда будет идентификатор пакета и по импортам ясно, откуда он пришел. Теже шарпы или Java читать намного сложнее, потому что при импорте все символы, как правило, доступны напрямую без необходимости писать идентификатор неймспейса. И хер ты без IDE поймешь, откуда взялся тот или иной класс.
Не знаю, где обычно, но обычно как раз все пишется в одном пакете. В отдельный пакет выносятся тесты обычно для так сказать более строго отделения от подробностей реализации (и поэтому очень полезно, что ты не можешь непубличный метод достать. В этом вся фишка), либо по каким-то объективным иным причинам. Например, интеграционный тесты часто туда уносят, т.к. обычно это целая гора никак не связанного с основным приложением кода. Порой еще выносят это в отдельный го модуль, чтобы не тянуть ненужные зависимости в основной бинарь.
А зачем это нужно? Ты либо импортируешь пакет, либо нет. К пакету всегда обращение через его имя, поэтому пофиг, сколько десятков тысяч символов в нем. И читается это всегда однозначно
Конкретно для клаудфлейр раст был выбран совсем не из-за того, что плюсы не справляются. Нджинкс на расте был бы такой же медленный для них. Проблема в его архитектуре. Раст там именно что был выбран как более модный и современный с гарантиями безопасности.
По-моему в C изначально UB именно для этого и было и означало скорее implementation defined поведение. Т.е. язык как бы не при делах, но в конкретных условиях все ок. В те времена C еще можно было считать человекочитаемым ассемблером.
Сейчас же UB предназначено целиком и полностью для оптимизации, чтобы у компилятора была свобода ломать код так, как ему вздумается. Платформа здесь не имеет значения, потому что компилятор не смотрит на то, что в какой-то системе two's complement представление чисел. Для него UB это UB на любой платформе. Собственно, для него вообще платформы конечной не существует - он работает с абстрактной машиной. Поэтому как выше писали, проверка на переполнение будет просто удалена компилятором. Поэтому и версия компилятора может запросто сломать то, что работало раньше, если оно опиралось на UB.
Что-то мне это напоминает... https://ru.wikipedia.org/wiki/Система_социального_кредита
Только вот заказчик не обязан ничего принимать. На испытаниях запросто может оказаться, что интерпретации исполнителя и заказчика расходятся и последний не считает ТЗ выполненным. И дальше только в суд и не факт, что исполнитель еще прав, тк возможно пытается натягивать сову на глобус, чтобы не переделывать ничего. И аджайл тут как раз очень кстати, тк позволит скорректировать реализацию на раннем этапе и прийти на испытания по сути как на формальность, тк заказчика уже все устраивает и он все видел. Интерес тут с обоих сторон есть и на моей практике теже гос заказчики очень желают так работать
В том числе по этой причине стендап и проводится в одно и тоже время
Единица измерения в скраме совсем другая - польза бизнесу, а никакая не скорость разработки в вакууме. Можно гордо строчить задачи одна за другой и хвастаться скоростью, но потом окажется, что все эти задачи сделаны в пустую.
Польза от скрама постулируется по сути одна - увеличение пользы для бизнеса за счет коротких циклов разработки и постоянного фидбека. Чтобы как выше пишут не оказалось, что мы год писали что-то очень быстро в отрыве от всех и били рекорды, а потом оказалось, что большая часть сделана впустую. Поэтому да, вот так в лоб нельзя сравнивать.
Почему с первым. В целом система защиты xbox 360 полагалась на eFuse как средство против даунгрейда. Там был счетчик, который при каждом обновлении увеличивался, физически "прожигая" фьюз.
Теоретически да с учетом, что сама ВМ написана на тех же плюсах. На практике, я не могу найти уязвимостей особо в их JITe. Почему так - сложно сказать. Возможно виной тому дизайн байткода, семантика самого языка. Его куда легче верифицировать чем JS, в котором все что угодно на уровне системы типов может твориться.
Другая часть это стандартная библиотека. Тут все очевидно. У Java и .Net она реализована на Java и C# соответственно. Тем самым, практически весь код JDK и .Net Core получает те же гарантии безопасности, что код приложений. Остается лишь относительно маленькая часть на плюсах, которая реализует GC, JIT и вот это все. Javascript и V8 реализация как минимум сделана иначе. Там и стандартная библиотека написана на плюсах и можно найти множество CVE, которые были вызваны именно этим.
И что? Для GC циклические ссылки не представляют проблемы. Или вы о чем?
Нет, этот вывод как раз таки универсальный. Если погуглить, то примерно такая же статистика есть по Windows, Linux, iOS, macOS, android. И все эти проблемы были бы решены безопасными языками.
Взломщикам плевать на компилятор. У них есть готовый бинарь и окружение и под них пишется шеллкод. Если надо, под конкретные версии.
Реальные уязвимости связаны как раз с тем, что в статье перечислено. Выходы за границы, двойное освобождение, целочисленные переполнения - все это реально эксплуатируется постоянно. Более того, эксплуатируется порой не напрямую, а косвенно из того же Javascript атакуют JIT. И вы еще говорите о невозможности чего-то там взломщиками.
Эта проблема полностью решена в GC языках как класс. Она практически полностью решена в Swift за исключением циклических ссылок. Но и они очень редко создают проблемы.
Во-первых, в Go не такого понятия как UB и гонки не приводят к UB в том понимании, в котором это заведено в C/C++. Есть строго определенное число возможных исходов. И самое главное, это не приведет к эксплуатируемой уязвимости. Максимум это логическая ошибка или рантайм паника.
Зато двоичный поиск генерирует кэш промахи и сбивает логику префетчинга, а на этом часто весь перформанс и умирает. Подобное надо бенчить на конкретных продовых данных.
В сях массив таки придется весь пройти, чтобы длину получить. И тогда бинарный поиск тут уже будет бесполезен, как и сам факт отсортированности массива.
Для инвалидации in-memory всех инстансов не нужно заводить редисы и прочие pub-sub. Достаточно каждый инстанс посадить на топик без consumer group и пусть каждый читает одни и теже эвенты.
По thundering herd. Есть простое решение в виде библиотеки singleflight и подобной ей механизмов. Пока один запрос выполняется, все остальные стоят и ждут на локе. После разблокировки все получат один и тот же ответ и дальше пойдет раздача из кэша. Можно сделать лок распределенным, но в большинстве случаев не страшно, если будут локальные локи и каждый инстанс пойдет на промахе один раз в основной стор.
По этой же причине отвал был и у xbox 360, и у nvidia чипов.
Помню эти времена и все эти колхозные решения. Реболл это был высший пилотаж. Обычно же в домашних условиях кулер посильнее прикручивался, так называемой метод прижима. Мой 360 в таких условиях прожил еще несколько лет. Сначала да, думали на шарики под bga. Потом уже додумали, что на самом деле проблема в креплении кристалла к подложке. А видео выше дало еще более точный ответ - проблема в компаунде. Тогда не помню, чтобы о такой версии говорили.