надо убедиться, что проблема существует. Каждый сталкивался с поиском отсутствующей черной кошки, потому что клиент не туда посмотрел, использовал не ту версию, ошибка на самом деле возникает в другом компоненте и т.п. И тут очень важно вопроизвести проблему (это пригодится потом, чтобы убедиться, что проблема исправлена)
если есть очевидная версия, то проверяем ее (то, что автор назвал "научным подходом", с гипотезами и экспериментами)
очевидная версия не подтвердилась ("спасибо, наука, за попытку, дальше инженеры сами"), берем инструменты (valgrind, дебаггер и т.п.) и анализируем
находим, удивляемся, как это вообще могло работать и что за олень (как правило сам) это написал
исправляем, пытаемся воспроизвести, хорошо бы еще добавить unit test для этой ситуации, ну на случай регрессов
И еще - статический анализа кода надо делать не тогда, когда ошибка вылезла, а всегда, в идеале - в процессе сборки.
Воздушная подушка не была напечатана на 3D-принтере и добавляется в обувь отдельно
Пожалуй, единственная вещь, которую стоило напечатать - это как раз подошва с воздушной подушкой. Как человек, последние 2 года использующий велоседло, напечатанное на 3D принтере (https://www.specialized.com/us/en/saddle-mirror), могу сказать, что для упругих элементов это просто идеальная технология, она позволяет, используя один кусок материала (то есть без швов), варьировать жесткость.
Эксперты CrowdStrike установили, что за атакой на серверы демократов стояли две хакерских группировки, связанные с российскими спецслужбами. Информацию от CrowdStrike опровергли на следующий же год
В данном примере ревьюер предложил улучшения, которые касаются обработки граничных случаев о чем не предусмотрел разработчик, эти изменения сделали код более эффективным.
Это изменение не дает ничего, код и так вернет 0 для n < 1. А вот проверки на переполнение тут нет, и ревьювер это пропустил. От такого ревью пользы никакой
В чем недостаток? Это известное поведение стандартной бибилиотеки, и в подавляющем большинстве случаев оно вполне приемлемо. Если я пишу какой-нибудь REST, то понимаю, что работа с БД все равно намного медленнее, ну так и какой мне смысл придумывать супербыструю обработку JSONов, если я на этом выиграю в лучшем случае около 1%, зато потеряю в читаемости кода и увеличу возможность сделать ошибку? Вот если мне нужен сервис, который перелопачивает многомегабайтные JSONы и это его основная задача, то тут да, имеет смысл поискать альтернативы стандартной библиотеке и пожертвовать простотой кода. Но как часто такое нужно?
Я имел возможность посмотреть и даже немного пописать софт для летательных аппаратов. Там такие жесткие стандарты кодирования, что NULL (в C нет nullptr, если что) просто не может появиться. И более сурового code review я в жизни не видел. Уверен, что если ошибки были вызваны бортовым софтом (непонятно, о каких катастрофах говорит автор, так что не могу проверить), то это наверняка не были классические сишные проблемы с переполнением буфера или дереференсом NULL'а, а логические ошибки, которые возможны в любом языке.
Не надо передёргивать и нагло вырывать фразу из контекста.
Тогда стоит постараться, чтобы нормально доносить контекст. В данном случае это выглядит как попытка вынести обобщенное суждения о людях, сгруппированных по возрасту, но когда такое же суждение о твоей группе выносит условный представитеть поколения альфа, это почему-то не нравится.
Миллениалы кроют зумеров! Это просто праздник какой-то (для GenX)
По моему опыту, процесс выглядит так:
надо убедиться, что проблема существует. Каждый сталкивался с поиском отсутствующей черной кошки, потому что клиент не туда посмотрел, использовал не ту версию, ошибка на самом деле возникает в другом компоненте и т.п. И тут очень важно вопроизвести проблему (это пригодится потом, чтобы убедиться, что проблема исправлена)
если есть очевидная версия, то проверяем ее (то, что автор назвал "научным подходом", с гипотезами и экспериментами)
очевидная версия не подтвердилась ("спасибо, наука, за попытку, дальше инженеры сами"), берем инструменты (valgrind, дебаггер и т.п.) и анализируем
находим, удивляемся, как это вообще могло работать и что за олень (как правило сам) это написал
исправляем, пытаемся воспроизвести, хорошо бы еще добавить unit test для этой ситуации, ну на случай регрессов
И еще - статический анализа кода надо делать не тогда, когда ошибка вылезла, а всегда, в идеале - в процессе сборки.
Пожалуй, единственная вещь, которую стоило напечатать - это как раз подошва с воздушной подушкой. Как человек, последние 2 года использующий велоседло, напечатанное на 3D принтере (https://www.specialized.com/us/en/saddle-mirror), могу сказать, что для упругих элементов это просто идеальная технология, она позволяет, используя один кусок материала (то есть без швов), варьировать жесткость.
А можно ссылку на опровержение?
Из каких соображений был выбран WAMR, а не wasmtime, например?
Это изменение не дает ничего, код и так вернет 0 для
n < 1. А вот проверки на переполнение тут нет, и ревьювер это пропустил. От такого ревью пользы никакойВ чем недостаток? Это известное поведение стандартной бибилиотеки, и в подавляющем большинстве случаев оно вполне приемлемо.
Если я пишу какой-нибудь REST, то понимаю, что работа с БД все равно намного медленнее, ну так и какой мне смысл придумывать супербыструю обработку JSONов, если я на этом выиграю в лучшем случае около 1%, зато потеряю в читаемости кода и увеличу возможность сделать ошибку?
Вот если мне нужен сервис, который перелопачивает многомегабайтные JSONы и это его основная задача, то тут да, имеет смысл поискать альтернативы стандартной библиотеке и пожертвовать простотой кода. Но как часто такое нужно?
К тому же когда мы десериализуем объект в структуру, используется reflect, а он весьма медленный
сайт у них конечно не очень удобно организован, но при желании найти DEB тоже можно: https://slack.com/downloads/instructions/linux?ddl=1&build=deb
У меня для вас плохие новости...
ага, и домен getbox.ru на продажу выставлен. Непонятно, то ли это толстоватый троллинг, то ли какой-то неизящный скам
Мне кажется, тут просто обязательно надо упомянуть pass (https://www.passwordstore.org/)
Круто, с
defaut-features = falseкомпилится в Wasm и даже работает, спасибо!Таки это, именно в этом и было дело
Мне кажется, этот я тоже пробовал, и он у меня не захотел в wasm32-wasi компилиться, но я еще раз попробую. В любом случае спасибо
А для самого обычно zip нет нормальной pure Rust либы, чтобы можно было спокойно в Wasm скомпилить :(
Я имел возможность посмотреть и даже немного пописать софт для летательных аппаратов. Там такие жесткие стандарты кодирования, что NULL (в C нет nullptr, если что) просто не может появиться. И более сурового code review я в жизни не видел.
Уверен, что если ошибки были вызваны бортовым софтом (непонятно, о каких катастрофах говорит автор, так что не могу проверить), то это наверняка не были классические сишные проблемы с переполнением буфера или дереференсом NULL'а, а логические ошибки, которые возможны в любом языке.
Автор, судя по тексту, отнюдь не бумер, а миллениал (https://ru.wikipedia.org/wiki/Поколение_Y)
Тогда стоит постараться, чтобы нормально доносить контекст. В данном случае это выглядит как попытка вынести обобщенное суждения о людях, сгруппированных по возрасту, но когда такое же суждение о твоей группе выносит условный представитеть поколения альфа, это почему-то не нравится.
С этим полность согласен.
То есть самому относиться презрительно к предыдущему поколению - нормально, а когда к тебе так, то вдруг что-то не нравится?