Может быть ему просто скучно. Обычно люди которые не собираются реально посветить себя служению тому или иному высокому идеалу, ищут либо лекарство от скуки, либо личного благополучия. Автор не особо похож на монаха или харизматичного лидера секты. Поэтому, вероятно просто скучает и пытается лечить хандру фантастикой и шизой. В принципе, вся эта саентология — она примерно для таких случаев и есть. Человек не готов серьёзно окунуться в тот или иной высокий смысловой омут, не готов к подвижничеству, но готов немного пофантазировать. Комфортно и бодрит.
Так-то, если говорить серьёзно, то настоящая эзотерика — это не вот эти все блуждания от Шивы к Иисусу, а, скажем, "Фауст" Гёте. Но "скучающих" это не заинтересует. Кстати, Фауст как раз и начал практиковать вызов духов после того, как убедился в том, что наука не может утолить его страсть к знаниям. Классический сюжет, в общем.
Потому как наука в сегодняшнем понимании — штука весьма ограниченная. Даже если говорить про классической триаде: этике эстетике и гносеологии, то наука, как часть гносеологии — составляет менее трети всех знаний человечества. При том, речь идёт о знаниях, лишенных ценностей и целеполагания. Она ответит на вопросы о том, что возможно (не всегда это будут полные ответы) и о том, как реализовать задуманное. Но на вопрос о том, что сделать, правильно ли это или красиво ли это — наука ответить не может. Иными словами, если представить себе человека, который идеально освоил научный метод, он не сможет и пальцем пошевелить опираясь лишь на науку. Нужно что-то ещё. Эзотерические учения, религия, философия, идеологии, мифы — это как раз то, что даёт человеку систему координат и некое предпочтительное направление движения. Они бывают разные, порой деструктивные, иногда странные. Но так или иначе — все люди используют ту или иную ценностную систему. Порой даже не осознавая этого. Это не вопрос веры даже, это вопрос простого выбора человека своей собственной модели поведения и результатов этого поведения. Можно быть убеждённым атеистом, но в мышлении и поведении руководствоваться, скажем, христианскими ценностями (которые в России часто называют традиционными ценностями). У автора поста тут вот наблюдается некая эклектика восточных учений. Ну, тоже бывает. Не очень понятно, правда, к чему он это написал.
Как мне видится, тестовые задания в принципе дело наверное нормальное. Но зачастую имеют ряд проблем. Одно дело, когда я реально хочу именно в компанию Х, я знаю примерно условия и что меня ждёт. Другое дело, когда речь идёт о незнакомой компании. Получается, я ещё толком не знаю, хочу ли я в эту компанию, а уже должен потратить время, зачастую не малое. Знаю, что некоторые компании даже оплачивают это время. Но это ничего не меняет — всё равно ничего о компании не известно, что там происходит не понятно — как принимать решение о том, что есть смысл вообще тратить время, даже если его оплатят? Дело ведь не в деньгах, а в том, что ничего ещё не решено.
Вообще, это наверное вопрос психологии и стиля. Если компания выставляет какие-то требования, то очевидно, что она получит тех, кто пройдут фильтр. Если компания использует тестовое задание, на которое предполагается потратить несколько часов, а то и дней, то наверное там ищут таких людей, которым это кажется нормальным и которые с этим способны справиться.
Вопрос приёма на работу наверное никак нельзя свести к какому-то универсальному способу. Вполне допускаю, что где-то есть компания, которая ищет программистов, подсовывая им какие-нибудь головоломки или предлагая им, условно, распутать шнур от наушников. Кто-то их идиотами посчитает, а у них может быть в итогу психологическая совместимость высокая будет и они как команда будут хорошо работать. Всяко может быть
Ну, опыт Python 3 в этом смысле не однозначен, мягко говоря. Поломали обратную совместимость и теперь фактически имеется два питона. Возможно, когда-нибудь третий и догонит второго. Но мне кажется, что такой финт очень дорого стоил для питон-сообщества и языка в целом.
Что-то там совсем всё не очевидно, если честно. У меня возникло ощущение, что это работает так, что если отправить повторно файл на загрузку, то он как бы «промотает» уже полученные ранее байты и будет записывать только недостающие. По крайней мере, сейчас попробовал, выглядит это как-то так. То есть, все байты отправляются повторно, но часть из них пропускается и пишутся лишь нужные, что в теории должно быть быстрее, за счёт того, что не нужно будет повторно писать на диск то, что уже есть. Но вот повторная отправка байтов мне как-то не нравится.
С другой стороны, в библиотеке для ноды я вижу такие методы как initiateNewMultipartUpload, что вроде как подразумевает необходимость каких-то дополнительных действий. Но это по какой-то причине не содержится в примерах и документации. То есть, похоже нельзя просто так взять и начать пихать недостающие байты. Причём, я так и не вижу, каким именно способом можно получить размер уже закачанных данных. Метод, который возвращает список незавершенных загрузок почему-то отказывается возвращать размер:
{ key: 'test.bin',
uploadId: '648d7c8a-176b-4d01-9a16-8823edc8ab0b',
initiated: 2017-03-21T13:43:16.134Z,
size: NaN }
Сколько смотрю на все эти файловые хранилища — везде одна проблема — переусложнённый append данных в уже имеющийся файл. Хотя, надо ещё порыться в потрохах. В крайнем случае, наверное можно попробовать подмонтировать эту штуку в виде раздела, хотя мне не очень нравится эта идея.
А можно я вам (автору статьи) пару вопросов задам, раз уж вы тут.
У вас в документации написано:
«The maximum size of a single object is limited to 5TB. putObject transparently uploads objects larger than 5MiB in multiple parts. This allows failed uploads to resume safely by only uploading the missing parts. Uploaded data is carefully verified using MD5SUM signatures.».
Вы не могли бы уточнить, что конкретно будет происходить?
Например, вот ситуация. Приложение получает какой-то файл на 100 мегабайт. То есть, он будет разбит на несколько частей. Допустим, когда 53 мегабайта были вроде как получены, произошел внезапный обрыв соединения. Как будет осуществлено возобновление? Мне нужно будет узнать текущее число загруженных байт и начать просто записывать недостающие? Или что там должно вообще происходить? Как-то не вполне очевидно написано. Как клиент поймёт, какие части ему нужно отправить?
И второе, как можно приблизительно оценить объёмы и количество единиц хранимой информации, которые можно будет эффективно хранить? Пара миллиардов мелких файлов вперемешку с тысячами больших — нормально лягут?
Уже не так важно, какой был бы выбран язык для веба. Грядут времена, когда можно будет писать для него на любом языке. Интересно будет посмотреть, выдержит ли это испытание js. Очень многие люди были вынуждены использовать js не по доброй воле, а в силу безальтернативности. В этом же причина популярности таких штук как node.js или mongodb. Идея использовать один язык для всех случаев — дюже привлекательна (по крайней мере, в вебе). И пока эту универсальность может дать только js. Но wasm может всё сильно переменить. И тогда будет интересно посмотреть на то, как изменится топ популярных языков. Впрочем, js — хорошая штука и его вряд ли просто так выкинут — легаси он себе нажил на десятилетие вперёд. А во многом именно от объёма легаси-кода зависит спрос на рынке труда и соответственно популярность того или иного языка.
В вашем описании прослеживается мысль, что автотесты — это аналог тикета в баг-трекере, а не инструмент, автоматической проверки работоспособности. Не вполне понятно, для чего в принципе это нужно. Это такой способ постановки задачи и контроля исполнения? Это тогда не инструмент контроля качества вообще, а особый подход к управлению и тут вообще не корректно говорить о целях, поскольку цели находятся уже на слое управления. И там могут быть в принципе любые цели, вплоть до самых субъективных.
В этом смысле, я немного хотел бы отойти от менеджмента и понять, что делать с тестами, если на них возложена задача не по контролю известных багов. Для меня они фактически лишены смысла, если на них не возлагать роль автоматической диагностики работоспособности. В этом смысле, мне по существу не нужно полное покрытие всех возможных ветвей кода. Мне нужно убедиться только в том, что тот или иной функционал в принципе работает, при том, с точки зрения конечного пользователя. Какой мне прок от проверки прошлых багов, если они уже исправлены? Чтобы убедиться, не воспроизвелись ли они в новом обновлении? Но в обновлении такой тест может сломаться просто по факту смены логики работы. То есть, он уже не сможет выполнять функцию заслонки от старых багов и при этом не сможет выявить новые. Останется лишь удалить его от безысходности.
Наверное, описанный вами подход вполне оправдан в каких-то условиях, но это выглядит как способ решения довольно узких задач. В моём представлении, более применимы тесты в стиле «может ли пользователь зарегистрироваться». Тест получается более комплексным. Его можно крутить несколько раз, на разных наборах данных, чтобы проверять пограничные условия или ранее известные баги. А просто проверять, что а+б == б+а — это как-то мне не понятно.
Я бы вместо слова "являются" скорее применил бы "должны являться". Но на практике, это далеко не всегда так. В основном, по той простой причине, что в большинстве случаев естественный человеческий язык перевести на строгий однозначный и формализованный язык просто невозможно даже в теории по причине его изначально метафорической природе. Кроме того, зачастую тесты пишутся даже для кода, который написан вообще без ТЗ, просто интуитивно. И эти тесты, как бы они хорошо не покрывали бы код — просто культ карго и дань моде.
Я не являюсь большим специалистом в области автоматического тестирования, но сама идея такого подхода, как описана в статье — мне кажется просто каким-то маркетинговым трюком для коммерческого продукта и не более того. Описанный там подход наверное полезен, для статического анализа кода и выявления в нём потенциальных проблемных мест. Но писать тесты на основе этого анализа — довольно странное занятие, на мой взгляд. От фактических ошибок такие тесты не избавят. Выше я упомянул пример с json-парсерами, которые как ни покрывай, а они всё равно будут в ряде случаев просто не совместимы друг с другом.
Наличие плашки ещё не говорит о полном покрытии. Достаточно просто спросить: 100% от какой суммы случаев? В основном, это всё конечно полезно, но я просто не вижу никаких доказательных способов заявить, что покрыто реально 100%. Чтобы это заявить, нужно сначала доказать, что успешное прохождение этих тестов полностью гарантирует работоспособность кода в 100% случаев. Но зачастую, вместо доказательства используется тот или иной автоматический анализ. Как они работают — отдельный вопрос. В принципе, статья довольно наглядно иллюстрирует некоторые аспекты. И ни о какой доказательности тут речи не идёт. Можно сказать, что такие средства выявляют некоторые проблемные места, но никто не даст гарантии, что они выявляют 100%. Иными словами, они доказывают, что в конкретном месте — возможна ошибка и её нужно покрыть тестом. Но они не доказывают, что кроме найденного — ничего больше нет. То есть, эти 100% — это 100% от найденного, а не от существующего. В принципе, это уже что-то. Но с другой стороны, это реально не правильная формулировка. Это нельзя использовать как доказательство корректности программы. Посмотрите на различные версии json-парсеров. Они все в теории должны делать одно и тоже. А на практике, они отличаются и выходной результат работы одного парсека может не совпасть с результатом работы другого. При этом, оба могут быть покрыты тестами на 100%, поскольку формально оба алгоритма могут быть корректными. Но при попытке обменяться результатом между двумя системами использующими разные партеры — будет ошибка. Кто виноват? Виноват плохой стандарт, который допускает неопределённое поведение. Соответственно, во вселенной просто физически не может быть ни одного парсера, который не содержит ошибок относительно другого парсера. И не имеет значения, какие у них там покрытия.
У меня немного философский вопрос. А как вообще физически можно получить 100% покрытие тестами? Всегда ведь есть некая "серая зона", которая зачастую возникает довольно неожиданно, зависит от окружения, поступающих некорректных данных и так далее. То есть, 100% покрытие тестами — это вообще всегда ложь, каким бы методом не достигалась эта цифра. Но если 100% — всегда ложь, то и любой другой процент — тоже автоматически ложь. 100% — это эталон. Лишившись эталона, мы лишаемся всего, приближающегося к эталону. Я не говорю, что тесты не нужны, но когда кто-то говорит о сколько-то процентном покрытии тестами, это звучит как попытка пустить пыль в глаза. я ещё понимаю, когда есть какое-то жёсткое ТЗ, в котором прописано, условно, какая функция при каких условиях какое значение должна возвращать за какое время. Или что-то подобное. Тогда понятно, что такое 100%. Это когда напротив каждого такого пункта в ТЗ стоит галочка — покрыто тестами. Но и не более. То есть, в этом случае, нельзя говорить о полной корректности программы на любых данных в любых условиях. Любой выход за границы, прописанные в ТЗ — швах. А в условиях, когда тестами покрывается нечто, у чего и ТЗ никогда не было — что они вообще тестируют? Понятно, что часто можно примерно прикинуть, какой результат будет верным. Но часто бывает и так, что формально правильно, а по существу — издевательство.
Если я правильно понял, там говорится про разные кучи, а не про разные аллокаторы. Впрочем, есть и другой момент — там идёт речь о том, как взаимодействуют библиотеки написанные на С/С++. И в этом смысле, у меня есть подозрение, что логика работы может отличаться. В данном случае, было бы разумно поставить под сомнение и то, что написано в документации и то, что написано на стэке. Существует ли воспроизводимый сценарий получить проблему? Если да, то можно было бы поставить какой-то эксперимент и посмотреть, что будет. Если откровенно, то мне вообще не вполне понятно, что именно должно в данном случае пойти не так.
Попробовал вызвать библиотечную версию функции из раста — получил среднее время на уровне 3,5 секунд. То есть, издержки на преобразования достаточно большие. Но мне кажется. что даже если их убрать совсем, то разница между вызовом в рамках раста и по тому или иному интерфейсу всё равно будет раза в два. То есть, будет примерно как в питоне ±. Впрочем, это конечно всё равно привлекательно, поскольку получается, что даже современный весьма хорошо оптимизированный js на порядок медленнее, чем вызываемая раст-функция через все эти обёртки и преобразования.
Пусть они сначала своё API стабилизируют и переведут его на асинхронный режим работы. Они обещали это сделать в будущем. Кроме того, выкинуть-то я её может быть и выкинул бы, но кто мне старые проекты перепишет с ноды и питона на раст?
Тут я как раз описал некоторый такой вариант диффузной миграции. С его помощью можно постепенно наработать некоторый объём нужного мне функционала и как-то попривыкнуть к местным обычаям. А в какой-то момент просто окажется, что всё, что мне нужно — есть в расте и я понимаю как это эффективно использовать. Вот тогда-то можно будет и выкинуть что-то. И то, что-то всё равно останется, просто потому как есть проекты переменчивые, а есть в стиле «Работает — не трогай», которые я годами не обновляю, поскольку просто нет нужды. Зачем их переписывать? Что я с этого получу?
А главное, как я буду объяснять людям, которые работают со мной совместно, что я взял и выкинул ноду? Они-то раста не знают. Подключаемую библиотеку они ещё могут воспринять, а полный отказ от ноды будет означать отказ ещё и от их участия в проекте. К чему такой тоталитаризм?
Правильно ли я понимаю, что это касается вот этой части кода на с++
char * result = adler(url);
info.GetReturnValue().Set(Nan::New<String>(result).ToLocalChecked());
free(result);
То есть, вот этот вот free — вызывать опасно?
Но вроде как тут как раз не должно быть разных аллокаторов именно по причине того, что код вызывается сначала в C++, а уже потом значение передаётся в ноду. А они используют, насколько я понимаю, один и тот же аллокатор. И в документации на этот счёт как раз сказано, что при компиляции в библиотеки всё должно работать корректно.
Dynamic and static libraries, however, will use alloc_system by default. Here Rust is typically a 'guest' in another application or another world where it cannot authoritatively decide what allocator is in use. As a result it resorts back to the standard APIs (e.g. malloc and free) for acquiring and releasing memory.
Короче, говоря, освобождать отданное значение на вызывающей стороне — это должно быть вполне корректным решением.
Откровенно говоря, я ещё не до конца проникся всеми тонкостями работы с типами раста, но конкретно в данном случае, я опирался вот на этот пример: http://jakegoulding.com/rust-ffi-omnibus/string_return/
И именно в этом виде, с *mut оно компилируемая и работает. Если правильнее сделать как-то иначе, то будет любопытно узнать.
Может быть ему просто скучно. Обычно люди которые не собираются реально посветить себя служению тому или иному высокому идеалу, ищут либо лекарство от скуки, либо личного благополучия. Автор не особо похож на монаха или харизматичного лидера секты. Поэтому, вероятно просто скучает и пытается лечить хандру фантастикой и шизой. В принципе, вся эта саентология — она примерно для таких случаев и есть. Человек не готов серьёзно окунуться в тот или иной высокий смысловой омут, не готов к подвижничеству, но готов немного пофантазировать. Комфортно и бодрит.
Так-то, если говорить серьёзно, то настоящая эзотерика — это не вот эти все блуждания от Шивы к Иисусу, а, скажем, "Фауст" Гёте. Но "скучающих" это не заинтересует. Кстати, Фауст как раз и начал практиковать вызов духов после того, как убедился в том, что наука не может утолить его страсть к знаниям. Классический сюжет, в общем.
Потому как наука в сегодняшнем понимании — штука весьма ограниченная. Даже если говорить про классической триаде: этике эстетике и гносеологии, то наука, как часть гносеологии — составляет менее трети всех знаний человечества. При том, речь идёт о знаниях, лишенных ценностей и целеполагания. Она ответит на вопросы о том, что возможно (не всегда это будут полные ответы) и о том, как реализовать задуманное. Но на вопрос о том, что сделать, правильно ли это или красиво ли это — наука ответить не может. Иными словами, если представить себе человека, который идеально освоил научный метод, он не сможет и пальцем пошевелить опираясь лишь на науку. Нужно что-то ещё. Эзотерические учения, религия, философия, идеологии, мифы — это как раз то, что даёт человеку систему координат и некое предпочтительное направление движения. Они бывают разные, порой деструктивные, иногда странные. Но так или иначе — все люди используют ту или иную ценностную систему. Порой даже не осознавая этого. Это не вопрос веры даже, это вопрос простого выбора человека своей собственной модели поведения и результатов этого поведения. Можно быть убеждённым атеистом, но в мышлении и поведении руководствоваться, скажем, христианскими ценностями (которые в России часто называют традиционными ценностями). У автора поста тут вот наблюдается некая эклектика восточных учений. Ну, тоже бывает. Не очень понятно, правда, к чему он это написал.
Как мне видится, тестовые задания в принципе дело наверное нормальное. Но зачастую имеют ряд проблем. Одно дело, когда я реально хочу именно в компанию Х, я знаю примерно условия и что меня ждёт. Другое дело, когда речь идёт о незнакомой компании. Получается, я ещё толком не знаю, хочу ли я в эту компанию, а уже должен потратить время, зачастую не малое. Знаю, что некоторые компании даже оплачивают это время. Но это ничего не меняет — всё равно ничего о компании не известно, что там происходит не понятно — как принимать решение о том, что есть смысл вообще тратить время, даже если его оплатят? Дело ведь не в деньгах, а в том, что ничего ещё не решено.
Вообще, это наверное вопрос психологии и стиля. Если компания выставляет какие-то требования, то очевидно, что она получит тех, кто пройдут фильтр. Если компания использует тестовое задание, на которое предполагается потратить несколько часов, а то и дней, то наверное там ищут таких людей, которым это кажется нормальным и которые с этим способны справиться.
Вопрос приёма на работу наверное никак нельзя свести к какому-то универсальному способу. Вполне допускаю, что где-то есть компания, которая ищет программистов, подсовывая им какие-нибудь головоломки или предлагая им, условно, распутать шнур от наушников. Кто-то их идиотами посчитает, а у них может быть в итогу психологическая совместимость высокая будет и они как команда будут хорошо работать. Всяко может быть
Идеальный сайт, исходя из этих данных, это текстовый файл. Без скриптов, htmlи всего прочего. Но что-то мне подсказывает, это не сработает.
С другой стороны, в библиотеке для ноды я вижу такие методы как initiateNewMultipartUpload, что вроде как подразумевает необходимость каких-то дополнительных действий. Но это по какой-то причине не содержится в примерах и документации. То есть, похоже нельзя просто так взять и начать пихать недостающие байты. Причём, я так и не вижу, каким именно способом можно получить размер уже закачанных данных. Метод, который возвращает список незавершенных загрузок почему-то отказывается возвращать размер:
Сколько смотрю на все эти файловые хранилища — везде одна проблема — переусложнённый append данных в уже имеющийся файл. Хотя, надо ещё порыться в потрохах. В крайнем случае, наверное можно попробовать подмонтировать эту штуку в виде раздела, хотя мне не очень нравится эта идея.
А, это перевод, прошу прощения.
У вас в документации написано:
«The maximum size of a single object is limited to 5TB. putObject transparently uploads objects larger than 5MiB in multiple parts. This allows failed uploads to resume safely by only uploading the missing parts. Uploaded data is carefully verified using MD5SUM signatures.».
Вы не могли бы уточнить, что конкретно будет происходить?
Например, вот ситуация. Приложение получает какой-то файл на 100 мегабайт. То есть, он будет разбит на несколько частей. Допустим, когда 53 мегабайта были вроде как получены, произошел внезапный обрыв соединения. Как будет осуществлено возобновление? Мне нужно будет узнать текущее число загруженных байт и начать просто записывать недостающие? Или что там должно вообще происходить? Как-то не вполне очевидно написано. Как клиент поймёт, какие части ему нужно отправить?
И второе, как можно приблизительно оценить объёмы и количество единиц хранимой информации, которые можно будет эффективно хранить? Пара миллиардов мелких файлов вперемешку с тысячами больших — нормально лягут?
Заранее спасибо!
Уже не так важно, какой был бы выбран язык для веба. Грядут времена, когда можно будет писать для него на любом языке. Интересно будет посмотреть, выдержит ли это испытание js. Очень многие люди были вынуждены использовать js не по доброй воле, а в силу безальтернативности. В этом же причина популярности таких штук как node.js или mongodb. Идея использовать один язык для всех случаев — дюже привлекательна (по крайней мере, в вебе). И пока эту универсальность может дать только js. Но wasm может всё сильно переменить. И тогда будет интересно посмотреть на то, как изменится топ популярных языков. Впрочем, js — хорошая штука и его вряд ли просто так выкинут — легаси он себе нажил на десятилетие вперёд. А во многом именно от объёма легаси-кода зависит спрос на рынке труда и соответственно популярность того или иного языка.
Там есть бенчмарки, которые выглядят… любопытно. Это пожалуй стоит попробовать.
В этом смысле, я немного хотел бы отойти от менеджмента и понять, что делать с тестами, если на них возложена задача не по контролю известных багов. Для меня они фактически лишены смысла, если на них не возлагать роль автоматической диагностики работоспособности. В этом смысле, мне по существу не нужно полное покрытие всех возможных ветвей кода. Мне нужно убедиться только в том, что тот или иной функционал в принципе работает, при том, с точки зрения конечного пользователя. Какой мне прок от проверки прошлых багов, если они уже исправлены? Чтобы убедиться, не воспроизвелись ли они в новом обновлении? Но в обновлении такой тест может сломаться просто по факту смены логики работы. То есть, он уже не сможет выполнять функцию заслонки от старых багов и при этом не сможет выявить новые. Останется лишь удалить его от безысходности.
Наверное, описанный вами подход вполне оправдан в каких-то условиях, но это выглядит как способ решения довольно узких задач. В моём представлении, более применимы тесты в стиле «может ли пользователь зарегистрироваться». Тест получается более комплексным. Его можно крутить несколько раз, на разных наборах данных, чтобы проверять пограничные условия или ранее известные баги. А просто проверять, что а+б == б+а — это как-то мне не понятно.
Я бы вместо слова "являются" скорее применил бы "должны являться". Но на практике, это далеко не всегда так. В основном, по той простой причине, что в большинстве случаев естественный человеческий язык перевести на строгий однозначный и формализованный язык просто невозможно даже в теории по причине его изначально метафорической природе. Кроме того, зачастую тесты пишутся даже для кода, который написан вообще без ТЗ, просто интуитивно. И эти тесты, как бы они хорошо не покрывали бы код — просто культ карго и дань моде.
Я не являюсь большим специалистом в области автоматического тестирования, но сама идея такого подхода, как описана в статье — мне кажется просто каким-то маркетинговым трюком для коммерческого продукта и не более того. Описанный там подход наверное полезен, для статического анализа кода и выявления в нём потенциальных проблемных мест. Но писать тесты на основе этого анализа — довольно странное занятие, на мой взгляд. От фактических ошибок такие тесты не избавят. Выше я упомянул пример с json-парсерами, которые как ни покрывай, а они всё равно будут в ряде случаев просто не совместимы друг с другом.
Наличие плашки ещё не говорит о полном покрытии. Достаточно просто спросить: 100% от какой суммы случаев? В основном, это всё конечно полезно, но я просто не вижу никаких доказательных способов заявить, что покрыто реально 100%. Чтобы это заявить, нужно сначала доказать, что успешное прохождение этих тестов полностью гарантирует работоспособность кода в 100% случаев. Но зачастую, вместо доказательства используется тот или иной автоматический анализ. Как они работают — отдельный вопрос. В принципе, статья довольно наглядно иллюстрирует некоторые аспекты. И ни о какой доказательности тут речи не идёт. Можно сказать, что такие средства выявляют некоторые проблемные места, но никто не даст гарантии, что они выявляют 100%. Иными словами, они доказывают, что в конкретном месте — возможна ошибка и её нужно покрыть тестом. Но они не доказывают, что кроме найденного — ничего больше нет. То есть, эти 100% — это 100% от найденного, а не от существующего. В принципе, это уже что-то. Но с другой стороны, это реально не правильная формулировка. Это нельзя использовать как доказательство корректности программы. Посмотрите на различные версии json-парсеров. Они все в теории должны делать одно и тоже. А на практике, они отличаются и выходной результат работы одного парсека может не совпасть с результатом работы другого. При этом, оба могут быть покрыты тестами на 100%, поскольку формально оба алгоритма могут быть корректными. Но при попытке обменяться результатом между двумя системами использующими разные партеры — будет ошибка. Кто виноват? Виноват плохой стандарт, который допускает неопределённое поведение. Соответственно, во вселенной просто физически не может быть ни одного парсера, который не содержит ошибок относительно другого парсера. И не имеет значения, какие у них там покрытия.
У меня немного философский вопрос. А как вообще физически можно получить 100% покрытие тестами? Всегда ведь есть некая "серая зона", которая зачастую возникает довольно неожиданно, зависит от окружения, поступающих некорректных данных и так далее. То есть, 100% покрытие тестами — это вообще всегда ложь, каким бы методом не достигалась эта цифра. Но если 100% — всегда ложь, то и любой другой процент — тоже автоматически ложь. 100% — это эталон. Лишившись эталона, мы лишаемся всего, приближающегося к эталону. Я не говорю, что тесты не нужны, но когда кто-то говорит о сколько-то процентном покрытии тестами, это звучит как попытка пустить пыль в глаза. я ещё понимаю, когда есть какое-то жёсткое ТЗ, в котором прописано, условно, какая функция при каких условиях какое значение должна возвращать за какое время. Или что-то подобное. Тогда понятно, что такое 100%. Это когда напротив каждого такого пункта в ТЗ стоит галочка — покрыто тестами. Но и не более. То есть, в этом случае, нельзя говорить о полной корректности программы на любых данных в любых условиях. Любой выход за границы, прописанные в ТЗ — швах. А в условиях, когда тестами покрывается нечто, у чего и ТЗ никогда не было — что они вообще тестируют? Понятно, что часто можно примерно прикинуть, какой результат будет верным. Но часто бывает и так, что формально правильно, а по существу — издевательство.
Если я правильно понял, там говорится про разные кучи, а не про разные аллокаторы. Впрочем, есть и другой момент — там идёт речь о том, как взаимодействуют библиотеки написанные на С/С++. И в этом смысле, у меня есть подозрение, что логика работы может отличаться. В данном случае, было бы разумно поставить под сомнение и то, что написано в документации и то, что написано на стэке. Существует ли воспроизводимый сценарий получить проблему? Если да, то можно было бы поставить какой-то эксперимент и посмотреть, что будет. Если откровенно, то мне вообще не вполне понятно, что именно должно в данном случае пойти не так.
Тут я как раз описал некоторый такой вариант диффузной миграции. С его помощью можно постепенно наработать некоторый объём нужного мне функционала и как-то попривыкнуть к местным обычаям. А в какой-то момент просто окажется, что всё, что мне нужно — есть в расте и я понимаю как это эффективно использовать. Вот тогда-то можно будет и выкинуть что-то. И то, что-то всё равно останется, просто потому как есть проекты переменчивые, а есть в стиле «Работает — не трогай», которые я годами не обновляю, поскольку просто нет нужды. Зачем их переписывать? Что я с этого получу?
А главное, как я буду объяснять людям, которые работают со мной совместно, что я взял и выкинул ноду? Они-то раста не знают. Подключаемую библиотеку они ещё могут воспринять, а полный отказ от ноды будет означать отказ ещё и от их участия в проекте. К чему такой тоталитаризм?
То есть, вот этот вот free — вызывать опасно?
Но вроде как тут как раз не должно быть разных аллокаторов именно по причине того, что код вызывается сначала в C++, а уже потом значение передаётся в ноду. А они используют, насколько я понимаю, один и тот же аллокатор. И в документации на этот счёт как раз сказано, что при компиляции в библиотеки всё должно работать корректно.
Короче, говоря, освобождать отданное значение на вызывающей стороне — это должно быть вполне корректным решением.
И именно в этом виде, с *mut оно компилируемая и работает. Если правильнее сделать как-то иначе, то будет любопытно узнать.
-> *mut c_char